ஒரு ஆர்கெஸ்ட்ரேட்டர், மூன்று CLI-கள்: கோடெக்ஸ் மற்றும் ஜெமினிக்கு வழங்குவது உங்கள் கிளாட் டோக்கன்களை உண்மையில் சேமிக்க முடியுமா?

2026 இல் உள்ள பல டெவலப்பர்களைப் போலவே, ஒரே கணினியில் நிறுவப்பட்ட மூன்று AI கோடிங் CLI-களுடன் நான் முடித்துள்ளேன், மேலும் ஒவ்வொன்றும் வேறுபட்ட காரணத்திற்காக அதன் இடத்தைப் பிடித்துள்ளன:

• Claude Code — ஆர்கெஸ்ட்ரேட்டர் தரத்திலான முகவர். பல-படி பகுப்பாய்வு, கட்டமைப்பு, பிழைத்திருத்தம் மற்றும் பெரிய கோட்பேஸில் வேலை செய்வதில் சிறந்தது. மேலும், நான் அதிகம் கவலைப்படும் டோக்கன்களையும் கொண்டது.
• OpenAI Codex CLI — ஒரு துல்லியமான விவரக்குறிப்புடன் நன்கு திட்டமிடப்பட்ட, சுய-கட்டுப்படுத்தப்பட்ட பணியை நீங்கள் அதனிடம் ஒப்படைக்கும் போது சிறந்த திறனுள்ள கோடிங் முகவர்.
• Google Gemini CLI — மல்டிமாடல் பணிக்குதிரை. பட உருவாக்கம், ஆடியோ மற்றும் TTS, படியெடுத்தல், மற்றும் உயர்தர மொழிபெயர்ப்பு, குறிப்பாக பிராந்திய மொழிகளுக்கு.

ஒரு கட்டத்தில் வெளிப்படையான கேள்வி எழுகிறது: மூன்றிலும் புத்திசாலியானது நாள் முழுவதும் இயக்குவதற்கு மிகவும் விலையுயர்ந்ததும் ஆகும். எனவே நான் அதை ஆக்க முடியுமா மேலாளர்? கிளாடிடம் ஒரு பணியைக் கொடுங்கள், அது வேலையைப் பிரிக்கட்டும், கோடெக்ஸ் மற்றும் ஜெமினியிடம் துண்டுகளை ஒப்படைத்து, அவை முடிந்ததும் மார்க்டவுன் கோப்புடன் அவற்றைப் புகாரளிக்கச் செய்யுங்கள் — கிளாட் கடினமான பகுதிகள் மற்றும் இறுதி மதிப்பாய்வுக்கு மட்டுமே டோக்கன்களை செலவிடுகிறதா?

நான் இப்போது பல வாரங்களாக உண்மையான வேலைக்காக இந்த பேட்டர்னை இயக்கியுள்ளேன் — ஒரு முழுமையான சந்தைப்படுத்தல்-தளத்தின் மறுவடிவமைப்பு, AI-உருவாக்கிய ஹீரோ படங்களின் தொகுப்பு, எட்டு மொழிகளுக்கான மொழிபெயர்ப்புகள், பயன்பாட்டு ஸ்கிரிப்டுகள், மொத்த உள்ளடக்க வேலைகள். இந்தப் பதிவு முழுமையான பிளேபுக் ஆகும்: இந்த பேட்டர்ன் எப்படி வேலை செய்கிறது, நான் பயன்படுத்தும் துல்லியமான ப்ராம்ட் வடிவங்கள், அதை நேர்மையாக வைத்திருக்கும் அறிக்கை ஒப்பந்தம், எங்கு சேமிப்புகள் உண்மையானவை, மற்றும் முழு விஷயமும் மதிப்புள்ளதா என்பதைத் தீர்மானிக்கும் இரண்டு மறைக்கப்பட்ட செலவுகள்.

சுருக்கமான பதில்: ஆம், பேட்டர்ன் வேலை செய்கிறது, மற்றும் சேமிப்புகள் உண்மையானவை — ஆனால் நீங்கள் ஹேண்ட்ஆஃப்களைச் சரியாக வடிவமைத்தால் மட்டுமே. விரிவான பதில் கீழே உள்ள அனைத்தும்.

முதலில், நீங்கள் எதற்காக உண்மையில் பணம் செலுத்துகிறீர்கள் என்பதைப் புரிந்து கொள்ளுங்கள்

எந்தவொரு உத்தியும் அர்த்தமுள்ளதாக இருப்பதற்கு முன்பு, ஏஜெண்டிக் CLI அமர்வில் டோக்கன்கள் எங்கு செல்கின்றன என்பதற்கான தெளிவான படம் உங்களுக்குத் தேவை. தோராயமாக நான்கு வாளிகள்:

1. உள்ளீட்டு டோக்கன்கள் — மாதிரி படிக்கும் அனைத்தும்: உங்கள் ப்ராம்ட், கோப்பு உள்ளடக்கங்கள், கருவி வெளியீடுகள், முந்தைய உரையாடல். ஒரு நீண்ட கோடிங் அமர்வில் இது மற்ற எல்லாவற்றையும் குள்ளமாக்குகிறது, ஏனெனில் முகவர் ஒவ்வொரு திருப்பத்திலும் சூழலை மீண்டும் படிக்கிறது.
2. வெளியீட்டு டோக்கன்கள் — மாதிரி எழுதும் அனைத்தும்: குறியீடு, உரைநடை, கருவி அழைப்புகள். வழக்கமாக உள்ளீட்டை விட அதிக கட்டணத்தில் பில் செய்யப்படுகிறது.
3. மறு வாசிப்புகள் — அமைதியான கொலையாளி. ஒரு முகவர் 1,000-வரி கோப்பை "எதையாவது சரிபார்க்க" ஒவ்வொரு முறையும் திறக்கும் போது, அந்த 1,000 வரிகளுக்கு நீங்கள் மீண்டும் உள்ளீடாகச் செலுத்துகிறீர்கள்.
4. மறுவேலை — கூட்டு கொலையாளி. தவறாகப் புரிந்துகொள்ளப்பட்ட பணியானது முதல் முயற்சி, அதைப் பிடிக்கும் மதிப்பாய்வு மற்றும் இரண்டாவது முயற்சிக்கு உங்களுக்குச் செலவாகும்.

பிரதிநிதித்துவம் 1 மற்றும் 2 வாளிகளைத் தாக்குகிறது: துணை முகவரின் உருவாக்கம் நடக்கிறது அதன் பில் (வேறு சந்தா, மலிவான மாதிரி அல்லது இலவச அடுக்கு), மற்றும் ஆர்கெஸ்ட்ரேட்டர் சுருக்கமான சுருக்கத்தை மட்டுமே படிக்கிறது. ஆனால் பிரதிநிதித்துவம் மோசமாக செய்யப்படுகிறது பணவீக்கம் வாளிகள் 3 மற்றும் 4 — மேலும் அதுவே இந்தக் கட்டுரையின் முழு பதற்றமும் ஆகும்.

சரியாக வரையறுக்கப்பட்ட ஆர்கெஸ்ட்ரேட்டர் பேட்டர்ன்

அதன் எளிமையான வடிவத்தில் கட்டமைப்பு இதோ:

            ┌─────────────────────────┐
            │   YOU (one instruction)  │
            └───────────┬─────────────┘
                        ▼
            ┌─────────────────────────┐
            │  CLAUDE (orchestrator)   │
            │  plans · splits · specs  │
            │  reviews · integrates    │
            └─────┬──────────────┬────┘
        spec + exact output path │
              ▼                  ▼
   ┌─────────────────┐  ┌─────────────────┐
   │  CODEX (coder)   │  │ GEMINI (media)   │
   │ scoped modules,  │  │ images, audio,   │
   │ tests, boiler-   │  │ translation      │
   │ plate, scripts   │  │                  │
   └────────┬────────┘  └────────┬────────┘
            │  artifacts → disk   │
            │  report.md (≤40 ln) │
            ▼                     ▼
            ┌─────────────────────────┐
            │  CLAUDE reads reports,   │
            │  verifies, fixes/retries │
            │  or integrates & ships   │
            └─────────────────────────┘

ஆர்கெஸ்ட்ரேட்டர் நான்கு விஷயங்களைக் கொண்டுள்ளது மற்றும் மட்டுமே நான்கு விஷயங்கள்: திட்டம், விவரக்குறிப்புகள், மதிப்பாய்வு, மற்றும் ஒருங்கிணைப்பு. பருமனான மற்றும் இயந்திரத்தனமான அனைத்தும் கீழே தள்ளப்படுகின்றன, இரண்டு பேச்சுவார்த்தைக்குட்படாத விதிகளுடன்:

விதி 1 — ஆர்ட்டிஃபேக்ட்கள் துல்லியமான பாதையில் வட்டுக்குச் செல்கின்றன. துணை முகவர் அதன் வெளியீட்டை உரையாடலில் ஒருபோதும் ஒட்டாது. அது கோப்புகளை எழுதுகிறது. ஆர்கெஸ்ட்ரேட்டரின் சூழல் சுத்தமாக இருக்கும்.

விதி 2 — பதில் கிட்டத்தட்ட ஒன்றுமில்லை. இலட்சியமாக ஒரு சொல் மற்றும் ஒரு குறுகிய மார்க்டவுன் அறிக்கை. அறிக்கை தான் மட்டுமே ஆர்கெஸ்ட்ரேட்டர் படிக்க உத்தரவாதம் அளிக்கப்பட்ட விஷயம்.

இந்தக் கட்டுரையிலிருந்து நீங்கள் வேறு எதையும் நினைவில் கொள்ளவில்லை என்றால்: ஒரு வழங்கப்பட்ட பணியில் ஆர்கெஸ்ட்ரேட்டர் டோக்கன்களைச் செலவிடும் இரண்டு இடங்கள் பிரதிநிதித்துவ ப்ராம்ட் மற்றும் அறிக்கை மட்டுமே. மற்ற அனைத்தும் வேறொருவரின் பில் ஆகும். உங்கள் முழு உகப்பாக்க மேற்பரப்பு அந்த இரண்டு ஆவணங்கள் தான்.

ஒத்திகை #1: பட உருவாக்கத்தை ஜெமினிக்கு வழங்குதல்

இது நான் இயக்கும் அதிக-மதிப்புள்ள பிரதிநிதித்துவமாகும், ஏனென்றால் ஆர்கெஸ்ட்ரேட்டரால் அதைச் செய்ய முடியாது — Claude Code-க்குப் பின்னால் எந்த பட மாதிரியும் இல்லை. Claude எழுதி Gemini CLI-ஐ நோக்கிச் சுடும் ப்ராம்ட்டின் உண்மையான வடிவம் இதோ:

Generate a single photorealistic editorial corporate portrait.
Concept: <detailed art direction — subject, pose, wardrobe,
lighting, background, composition>.

CRITICAL: the entire subject must be fully inside the frame with
generous margin on all sides — do not crop arms or held objects.
Plain seamless light-grey studio background for easy cutout.
No text, no watermark, no logos, no props.

Save the image to /tmp/work/hero-cyber.png (overwrite if it exists).
Then reply only DONE.

இந்த ப்ராம்ட்டில் உள்ள பொறியியலைக் கவனியுங்கள்:

• வெளியீட்டுப் பாதை துல்லியமானது. "எங்காவது சேமிக்கவும்" இல்லை — எங்கே பார்க்க வேண்டும் என்று ஆர்கெஸ்ட்ரேட்டருக்குத் துல்லியமாகத் தெரியும், அதனால் முன்னும் பின்னுமாக அலைவது பூஜ்ஜியம்.
• "DONE என்று மட்டும் பதிலளிக்கவும்." ஜெமினி CLI அதன் ஆக்கப்பூர்வமான செயல்முறையை 400 டோக்கன்களுக்கு மகிழ்ச்சியுடன் விவரிக்கும். எங்களுக்கு அது வேண்டாம். ஒரு வார்த்தை போதும்.
• கட்டுப்பாடுகள் இயந்திரத்தனமாக உச்சரிக்கப்படுகின்றன ("முழுவதும் சட்டகத்திற்குள்," "வாட்டர்மார்க் இல்லை") ஏனென்றால் உங்களின் ஒவ்வொரு கட்டுப்பாடும் வேண்டாம் எழுதுவது என்பது ஒரு மறுவேலை ரவுலட் சுழல் ஆகும். அந்த ஒவ்வொரு வரியையும் ஒரு தோல்வியிலிருந்து நான் கற்றுக்கொண்டேன் — அதைப் பற்றி கீழே மேலும் விரிவாக.

பின்னர் ஆர்கெஸ்ட்ரேட்டர் இயக்குவது ஒரு தர வாயில் படத்தைப் பார்ப்பதற்கு முன் — ஒரு மலிவான, இயந்திரச் சோதனை:

# does the file exist and is it non-trivial?
test -s /tmp/work/hero-cyber.png || echo "FAILED: missing/empty"

# entropy gate: catches blank/placeholder images without
# spending any model tokens at all
python3 -c "
from PIL import Image; import sys
img = Image.open('/tmp/work/hero-cyber.png')
# a flat placeholder has near-zero entropy; a real photo is > 4
print(img.entropy())
"

வாயில் கடந்த பின்னரே ஆர்கெஸ்ட்ரேட்டர் உண்மையில் பார்க்கிறது படத்தை ஒருமுறை — ஒரு ஒற்றை பார்வை அழைப்பு — ஒரு ஸ்கிரிப்ட் செய்ய முடியாத விஷயங்களைச் சரிபார்க்க: அமைப்பு, கலைப்பொருட்கள், பிராண்ட்-பாதுகாப்பு. அதுவே ஆர்கெஸ்ட்ரேட்டரின் பக்கத்தில் உள்ள முழு டோக்கன் செலவாகும்: ஒரு சிறிய ப்ராம்ட் வெளியே, ஒரு வார்த்தை உள்ளே, ஒரு படப் பார்வை.

இவற்றை பின்னணியில் இயக்கவும். பட வேலைகள் ஒன்று முதல் ஐந்து நிமிடங்கள் வரை எடுக்கும். ஒரு தடுப்பு காத்திருப்பு என்பது உங்கள் ஆர்கெஸ்ட்ரேட்டர் அதன் முழு சூழலையும் நினைவகத்தில் பிடித்துக் கொண்டு சும்மா இருக்கிறது என்பதாகும். வேலையைத் தொடங்குங்கள், பிற வேலைகளைத் தொடருங்கள், கோப்பு வந்தடையும் போது திரும்பி வாருங்கள். ஒவ்வொரு தீவிரமான ஏஜென்ட் CLI-ம் இப்போது பின்னணிக்கு ஆதரவளிக்கிறது; அதைப் பயன்படுத்தவும்.

ஒத்திகை #2: ஒரு கோடிங் பணியை கோடெக்ஸ்-க்கு வழங்குதல்

கோடிங் வழங்குதல் மிகவும் தந்திரமானது, ஏனென்றால் தோல்விப் பயன்முறை நீங்கள் ஒரு பார்வையில் காணக்கூடிய மோசமான படம் அல்ல — இது உங்கள் கோட்பேஸுடன் பொருந்தாத நம்பகமான-தோற்றமளிக்கும் குறியீடு. இதற்கான தீர்வு என்னவென்றால், "முடிந்தது" என்பது இயந்திரத்தால் சரிபார்க்கக்கூடிய அளவுக்கு ஒரு இறுக்கமான விவரக்குறிப்பாகும்:

TASK: Write a standalone Node script at scripts/import-legacy.mjs

SPEC:
- Reads ./data/legacy-export.csv (papaparse is already a dependency)
- Maps columns per the table below … (exact mapping)
- Writes ./data/import-ready.json, an array of objects
- Node 22, ESM, no new dependencies
- Handle: missing fields → skip row + count; duplicate IDs → last wins

ACCEPTANCE (all must pass):
- node scripts/import-legacy.mjs runs clean on the sample file
- node --test tests/import-legacy.test.mjs passes (write these tests)
- npx eslint scripts/import-legacy.mjs → zero errors

REPORT: write REPORT-import.md (max 40 lines) with status, files
created, how to verify, and up to 5 gotchas. Do not paste file
contents into the report.

பெரும்பாலான கோடிங் பணிகள் இல்லாத இடத்தில் இதை வழங்கக்கூடியதாக மாற்றும் மூன்று பண்புகள்:

1. சுய-கட்டுப்படுத்தப்பட்ட — ஒரு புதிய கோப்பு, இருக்கும் தொகுதிகளில் எவ்வித மாற்றமும் இல்லை, கட்டடக்கலை முடிவுகள் இல்லை.
2. இயந்திரத்தால் சரிபார்க்கக்கூடிய ஏற்பு — ஆர்கெஸ்ட்ரேட்டர் மூன்று கட்டளைகள் மூலம் சரிபார்க்கிறது, குறியீட்டை வரியாக படிப்பதன் மூலம் அல்ல.
3. வரம்புக்குட்பட்ட இடைமுகம் — உள்ளீட்டு கோப்பு, வெளியீட்டு கோப்பு, முடிந்தது. துணை முகவர் கோட்பேஸின் மற்ற பகுதிகளுக்குள் அலைய முடியாது.

அறிக்கை வரும்போது, ஆர்கெஸ்ட்ரேட்டர் ஏற்பு கட்டளைகளை (மலிவானது) இயக்குகிறது, கவட்டைகளை (மலிவானது) மேலோட்டமாகப் பார்க்கிறது, மற்றும் ஏதாவது தோல்வியடைந்தாலோ அல்லது தவறாகத் தெரிந்தாலோ மட்டுமே உண்மையான குறியீட்டைத் திறக்கிறது. ஒரு சுத்தமான தேர்ச்சியில், ஆர்கெஸ்ட்ரேட்டர் அது எழுதியிருக்க வேண்டிய 300 வரிகளை ஒருபோதும் படிக்காது — அதுதான் சேமிப்பு.

சேமிப்புகள் எங்கு உண்மையானவை — தோராயமான கணிதத்துடன்

1. மொத்த உருவாக்கம். ஒரு பணி 2,000 வரிகள் வெளியீட்டை (~25k டோக்கன்கள்) உருவாக்குகிறது என்று கூறுவோம். நேரடியாகச் செய்யப்பட்டால், ஆர்கெஸ்ட்ரேட்டர் ~25k வெளியீட்டு டோக்கன்களுடன் அதைச் சுற்றியுள்ள அனைத்து சூழல்-வாசிப்புகளுக்கும் பணம் செலுத்துகிறது. வழங்கப்பட்டால், ஆர்கெஸ்ட்ரேட்டர் செலுத்துவது: ஒரு ~300-டோக்கன் விவரக்குறிப்பு, ஒரு ~400-டோக்கன் அறிக்கை வாசிப்பு, மற்றும் சில நூறு டோக்கன்கள் சரிபார்ப்புக் கட்டளைகள். இதை அழையுங்கள் ~30k-க்கு எதிராக ~1k டோக்கன்கள் — 95%+ குறைப்பு அந்தப் பணியில், உருவாக்கம் নিজেই துணை முகவரின் ஒதுக்கீட்டில் பில் செய்யப்படுகிறது.

2. எப்படி இருந்தாலும் ஆர்கெஸ்ட்ரேட்டரால் செய்ய முடியாத வேலை. ஒவ்வொரு படமும், ஒவ்வொரு ஆடியோ கோப்பும், நான் சமீபத்தில் அனுப்பிய எட்டு-மொழி மொழிபெயர்ப்புத் தொகுப்புகளில் ஒவ்வொன்றும் ஆர்கெஸ்ட்ரேட்டர் எழுதிய ஒரு விவரக்குறிப்பிலிருந்து Gemini CLI ஆல் உருவாக்கப்பட்டன. ஒப்பிட்டுப் பார்க்க எந்த Claude-நேட்டிவ் மாற்றும் இல்லை — இது தூய்மையான திறன் லாபம், மற்றும் டோக்கன் செலவு என்பது விவரக்குறிப்பு + அறிக்கை மட்டுமே.

3. துல்லியமான விவரக்குறிப்புடன் நீண்ட இயந்திர வெளியீடு. சோதனை சாரக்கட்டு, தரவு இடம்பெயர்வுகள், கொதிகலன் தொகுதிகள், வடிவ மாற்றங்கள், ஒரு சுருக்கத்திலிருந்து ஆவண வரைவுகள். பொதுவான இழை: குறைந்த தீர்ப்பு, அதிக அளவு. அளவு என்பது வெளியீட்டு டோக்கன்களின் துல்லியமான விலையாகும்; மலிவான முகவருக்குத் துல்லியமாக இல்லாதது தீர்ப்பு. அளவை வழங்குங்கள், தீர்ப்பை வைத்துக் கொள்ளுங்கள்.

சேமிப்புகள் எங்கு ஆவியாகின்றன — இரண்டு வரிகள் மற்றும் ஒரு மேல்நிலை

சரிபார்ப்பு வரி

இது யாரும் விலை நிர்ணயிக்காத செலவு, எனவே எனது சொந்த திட்டத்தின் ரசீதுகளை நான் உங்களுக்குத் தருகிறேன் — ஒரு வலைத்தளத்திற்கான AI-ஆல் உருவாக்கப்பட்ட ஹீரோ உருவப்படங்களின் தொகுப்பு:

• ஒரு படம் இதனுடன் திரும்ப வந்தது போட்டியாளர்-அடையாளம் காணக்கூடிய மடிக்கணினி லோகோ காட்சியில் சுடப்பட்டது. சட்டப்பூர்வமாகவும் பிராண்ட் வாரியாகவும் அனுப்ப முடியாதது. மீளுருவாக்கம் — இல்லை காத்திருங்கள், உண்மையில் அதை ஒட்டு ஒரு படக் கருவியுடன், பின்னர் மீண்டும் சரிபார்க்கவும்.
• மற்றொரு தொகுப்பில் இருந்த மூலைகள் வெளிப்படையானவை என்று கூறப்பட்டன, ஆனால் அப்படி இல்லை — நிறமிடப்பட்ட பின்னணியில் மட்டுமே காட்டிய ஒரு ஒளிபுகா கிட்டத்தட்ட-வெள்ளை. தாமதமாகப் பிடிக்கப்பட்டது, ஃப்ளட்-ஃபில் பாஸ் மூலம் சரிசெய்யப்பட்டது, மீண்டும் சரிபார்க்கப்பட்டது.
• மூன்றாவதாக ஒரு தயாரிப்பு டேப்லெட் இருந்தது சட்டகத்திற்கு வெளியே பாதியாக உருவாக்கப்பட்டது — படம் எதைக் காட்ட இருந்ததோ அந்தப் பொருளையே மாதிரி செதுக்கியது. ஒரு புதிய "எல்லாமே முழுமையாக சட்டகத்திற்குள்" என்ற கட்டுப்பாட்டு வரியுடன் முழுமையான மீளுருவாக்கம்.

அந்தப் படங்களில் ஒவ்வொன்றும் கடந்தது மலிவான இயந்திர வாயில்களை. ஒவ்வொன்றிற்கும் ஆர்கெஸ்ட்ரேட்டர் உண்மையில் பார்க்கவும், தீர்மானிக்கவும் மற்றும் ஒரு தீர்வை வழிநடத்தவும் தேவைப்பட்டது. பிரதிநிதித்துவம் மதிப்பாய்வுப் படியை அகற்றவில்லை — அது உருவாக்கச் செலவை வேறு இடத்திற்கு நகர்த்திவிட்டு, மதிப்பாய்வுச் செலவை அது இருந்த இடத்திலேயே விட்டுவிட்டது.

மேலும் ஒரு வழங்கப்பட்ட பணி மதிப்பாய்வில் தோல்வியடையும் போது, நீங்கள் செலுத்துவது மூன்று முறை: பிரதிநிதித்துவம், அதைப் பிடித்த மதிப்பாய்வு, மற்றும் மறுசெயல். ஒரே பணியின் இரண்டு தோல்வியுற்ற பிரதிநிதித்துவங்களுக்குப் பொதுவாக, ஆர்கெஸ்ட்ரேட்டர் அதை முதல் முறையாக நேரடியாகச் செய்வதை விட அதிகச் செலவாகும். அதனால்தான் என் பட ப்ராம்ட்களில் உள்ள ஒவ்வொரு கட்டுப்பாட்டு வரியும் ஒரு வடுவைப் போலப் படிக்கிறது — ஒவ்வொன்றும் ஆகும் ஒன்று.

பட்ஜெட் விதி: வழங்கப்பட்ட ஆக்கபூர்வமான பணிகளில் 20–30% ஒரு திருத்த சுழற்சி தேவை என்று கருதி, அதை உங்கள் முடிவில் விலை நிர்ணயம் செய்யுங்கள். சரிபார்க்க மலிவான பணியாக இருந்தால் (சோதனைகளை இயக்கவும், கோப்பை சரிபார்க்கவும்), மறுவேலையுடன் கூட பிரதிநிதித்துவம் வெல்லும். சரிபார்ப்பு என்பது "எல்லாவற்றையும் கவனமாகப் படியுங்கள்" என்று பொருள்பட்டால், சேமிப்புகள் ஒரு மாயையாகும்.

ஒருங்கிணைப்பு வரி

பணி பல கோப்புகளைத் தொட்டால், உங்கள் கோட்பேஸின் மரபுகளுடன் பொருந்த வேண்டும் என்றால், அல்லது ஆர்கெஸ்ட்ரேட்டரின் தலையில் வாழும் சூழலைப் பொறுத்திருந்தால் — கட்டடக்கலை முடிவுகள், ஒரு குறுக்கு-தொகுதி மறுசீரமைப்பு, ஒரு பந்தய-நிலை பிழைத்திருத்தம் — அதை ஒப்படைப்பது ஒரு தவறான பொருளாதாரமாகும். துணை முகவருக்கு உங்கள் சூழல் தெரியாது; ஆர்கெஸ்ட்ரேட்டர் அதை பாதுகாப்பாக ஒருங்கிணைக்க, துணை முகவர் தொட்ட அனைத்தையும் மீண்டும் படிக்க நேரிடும். ஒரே புரிதலுக்காக நீங்கள் இரண்டு முறை பணம் செலுத்தியுள்ளீர்கள்: ஒருமுறை துணை முகவர் தனது சொந்த பகுதிப் படத்தை உருவாக்க, ஒருமுறை ஆர்கெஸ்ட்ரேட்டர் முழுமையானதை மீண்டும் உருவாக்க.

சொல்வது எளிது: விவரக்குறிப்பை எழுதுவதற்கு உங்கள் கட்டமைப்பை விளக்க வேண்டும் என்றால், பணியை வழங்காதீர்கள். விவரக்குறிப்பை எழுதுவது மட்டுமே சேமிப்பை விட அதிகமாகச் செலவாகும், மேலும் தவறாகப் புரிந்துகொள்ளும் அபாயம் மகத்தானது.

மேல்நிலை தளம்

ஒரு நல்ல பிரதிநிதித்துவ ப்ராம்ட்டை எழுத 200–400 டோக்கன்கள் செலவாகும். ஒரு அறிக்கையைப் படிக்க 300–500 செலவாகும். சரிபார்ப்பு, இன்னும் சில நூறு. எனவே ஒரு தளம் உள்ளது: பணியின் நேரடிச் செலவு தோராயமாக 1,000–2,000 டோக்கன்களுக்குக் கீழ் இருந்தால் (~50–100 வெளியீட்டு வரிகள்), அதை வழங்குவது ஒவ்வொரு முறையும் பணத்தை இழக்கும். அதை மட்டும் செய்.

மார்க்டவுன் அறிக்கை ஒப்பந்தம் — சேமிப்புகள் எங்கு வாழ்கின்றன அல்லது இறக்கின்றன

பெரும்பாலான மக்களுக்கு இந்த பேட்டர்னைக் கிளிக் செய்ய வைக்கும் யோசனை அறிக்கைக் கோப்பு: ஒவ்வொரு துணை முகவரும் முடித்துவிட்டு ஆர்கெஸ்ட்ரேட்டருக்கு ஒரு மார்க்டவுன் சுருக்கத்தை விடுகிறது. இது சரியான உள்ளுணர்வு — மேலும் முழுத் திட்டமும் அமைதியாகத் தோல்வியடையும் இடமும் இதுதான். Codex 500-வரி அறிக்கையை எழுதினால், கிளாட் அனைத்தையும் படித்தால், நீங்கள் எப்படியும் பணம் செலுத்தியுள்ளீர்கள் — எழுதுவதற்குப் பதிலாகப் படிப்பதில் மட்டுமே.

இதோ ஒரு மோசமான அறிக்கை (நீங்கள் அவற்றைக் கட்டுப்படுத்தாவிட்டால் முகவர்கள் உருவாக்குவது இதுதான்):

ஒரு 340-வரி கட்டுரை: பணியை மீண்டும் கூறுகிறது, ஒவ்வொரு முடிவையும் காலவரிசைப்படி விவரிக்கிறது, அது உருவாக்கிய இரண்டு கோப்புகளின் முழு உள்ளடக்கங்களையும் "குறிப்புக்காக" ஒட்டுகிறது, முழுமையான சோதனை வெளியீட்டை உள்ளடக்கியது, மற்றும் எதிர்கால மேம்பாடுகளுக்கான மூன்று பத்திகள் எச்சரிக்கைகள் மற்றும் பரிந்துரைகளுடன் முடிகிறது.

குறியீட்டை எழுதுவதற்கு ஆனதை விட அதைப் படிப்பதற்கு அதிகச் செலவாகும். அதற்குப் பதிலாக நான் செயல்படுத்தும் ஒப்பந்தம் இதோ:

# Task: import-legacy script
Status: DONE
Files created:
  - scripts/import-legacy.mjs
  - tests/import-legacy.test.mjs
How to verify:
  - node --test tests/import-legacy.test.mjs
  - node scripts/import-legacy.mjs && head data/import-ready.json
Gotchas:
  - 14 rows in the sample CSV had no email; skipped, count logged
  - CSV dates are DD/MM/YYYY, not ISO — parser handles both

மேலும் ஒவ்வொரு அறிக்கையையும் இந்த வடிவில் வைத்திருக்கும் நான்கு விதிகள்:

1. கடினமான வரம்பு: 40 வரிகள். பிரதிநிதித்துவ ப்ராம்ட்டில் அதைக் கூறவும். நிலை, பாதைகள், சரிபார்ப்புக் கட்டளைகள், கவட்டைகள் — வேறு எதுவுமில்லை.
2. பாதைகள், ஒருபோதும் உள்ளடக்கங்கள் இல்லை. ஆர்ட்டிஃபேக்ட்கள் வட்டில் வாழ்கின்றன; அறிக்கை அவற்றைச் சுட்டிக்காட்டுகிறது. சரிபார்ப்புக்குக் கோரும்போது மட்டுமே ஆர்கெஸ்ட்ரேட்டர் ஒரு கோப்பைத் திறக்கும் — இரண்டு முறை படிப்பது ஒரு தேர்வு, முன்னிருப்பு அல்ல.
3. தூய்மையான உருவாக்கத்திற்கு "DONE என்று மட்டும் பதிலளிக்கவும்". ஆர்ட்டிஃபேக்ட் தனக்காகப் பேசும்போது (ஒரு படம், ஒரு ஆடியோ கோப்பு), ஒரு அறிக்கை கூட மிக அதிகம். கோப்பு வருகிறது, ஒரு வார்த்தை திரும்பி வருகிறது, வாயில்கள் இயங்குகின்றன.
4. ஒவ்வொரு விவரக்குறிப்பிலும் இயந்திரத்தால் சரிபார்க்கக்கூடிய ஏற்பு அளவுகோல்கள். "அதை நன்றாகச் செய்யுங்கள்" என்பது மறுவேலையை உருவாக்குகிறது. "அனைத்து சோதனைகளும் தேர்ச்சி பெறுகின்றன, பூஜ்ஜிய லிண்ட் பிழைகள், வெளியீடு 200 KB-க்கு கீழ் உள்ள 1200×630 JPEG ஆகும்" என்பது ஆர்கெஸ்ட்ரேட்டர் ஒரு கட்டளையில் சரிபார்க்கும் தேர்ச்சி/தோல்வியை உருவாக்குகிறது. உங்கள் ஏற்பு அளவுகோல்களின் தரம் ஆகும் உங்கள் பிரதிநிதித்துவத்தின் தரம்.

உழைப்புப் பிரிவு: யாருக்கு என்ன கிடைக்கிறது, மற்றும் ஏன்

பணி	அதைக் கொடுங்கள்	ஏன்
படங்கள், ஆடியோ/TTS, படியெடுத்தல்	ஜெமினி CLI — எப்பொழுதும்	Orchestrator ஆல் இவற்றைச் செய்யவே முடியாது; முழு லாபம்
மொழிபெயர்ப்பு (குறிப்பாக வட்டார மொழிகள்)	Gemini CLI	வலுவான தரம், அதிக அளவு, மாதிரிகளை சோதிப்பதன் மூலம் எளிதில் சரிபார்க்கக்கூடியது
கச்சிதமான spec உடன் கூடிய தன்னிச்சையான script/module	Codex CLI	அதிக அளவு, குறைந்த கணிப்பு, இயந்திரத்தால் சரிபார்க்கக்கூடியது
Test scaffolding, migrations, boilerplate	Codex CLI	இயந்திரத்தனமான வெளியீடு; ஒப்புதல் = சோதனைகளே
கட்டமைப்பு & வடிவமைப்பு முடிவுகள்	Claude — ஒருபோதும் பகிர வேண்டாம்	முழுமையான கணிப்பு; பணிக்கு ஆகும் செலவை விட spec-க்கு ஆகும் செலவு அதிகம்
பல கோப்புகளை உள்ளடக்கிய refactors, ஒருங்கிணைப்பு வேலைகள்	Claude	ஒருங்கிணைப்பு வரி, பகிர்ந்தளிப்பதை ஒரு தவறான சிக்கனமாக மாற்றுகிறது
Debugging	Claude	சேகரிக்கப்பட்ட சூழல் தேவை; sub-agent பூஜ்ஜியத்திலிருந்து தொடங்குகிறது
பகிர்ந்தளிக்கப்பட்ட அனைத்தின் இறுதி மதிப்பாய்வு	Claude	உண்மையில் இதற்காகத்தான் நீங்கள் premium மாடலுக்கு பணம் செலுத்துகிறீர்கள்

குறிப்பிடத்தக்க ஒரு நுணுக்கம்: இது "Claude நல்லது, மற்றவை மோசம்" என்பதல்ல. இது அளவுக்கும் கணிப்புக்கும் இடையிலான வித்தியாசம். Codex சிறந்த தன்னிச்சையான குறியீட்டை எழுதுகிறது; Gemini-யின் படம் மற்றும் மொழிபெயர்ப்பு தரம் உண்மையான தயாரிப்பு பணிகளைத் தாங்குகிறது. ஒவ்வொரு இருக்கைக்கும் என்ன செலவாகிறது மற்றும் ஒவ்வொரு பணிக்கும் என்ன தேவை என்பதைப் பொறுத்தே இந்த பாகுபாடு அமைந்துள்ளது.

செயல்பாட்டு வழிகாட்டி

சேமிப்பை அதிகரிக்கும் சில பழக்கங்கள்:

மெதுவான எல்லாவற்றையும் background-ல் இயக்கவும். உருவாக்கும் பணிகள் ஒன்று முதல் ஐந்து நிமிடங்கள் வரை இயங்கும். அவற்றை detached ஆக இயக்கவும், orchestrator-ஐ வேறு ஏதேனும் வேலை செய்ய வைக்கவும், கோப்புகள் வந்ததும் முடிவுகளைச் செயல்படுத்தவும். விலையுயர்ந்த ஏஜெண்டை ஒருபோதும் காத்திருக்க விடாதீர்கள்.

தீவிரமாக batch செய்யவும். ஆறு படங்களை ஆறு உரையாடல்களாக உருவாக்குவது, prompt+report இன் ஆறு சுற்று கூடுதல் சுமையாகும். பெயரிடும் முறையுடன் ஆறு கோப்புகளை உருவாக்கும் ஒரு prompt (hero-01.png … hero-06.png), ஒரு அறிக்கை, ஒரு மதிப்பாய்வு போதுமானது. மொழிபெயர்ப்புகளுக்கும் இதுவே பொருந்தும்: எட்டு மொழிகளும் ஒரே பகிர்வில்.

புத்திசாலித்தனமாக மதிப்பாய்வு செய்வதற்கு முன் இயந்திரத்தனமாக தணிக்கை செய்யவும். கோப்பு உள்ளது → அளவு சரியாக உள்ளது → entropy/lint/tests தேர்ச்சி → பிறகு கணிப்புக்காக orchestrator டோக்கன்களை செலவிடுங்கள். தணிக்கை பிடிக்கும் ஒவ்வொரு தோல்வியும், நீங்கள் பணம் செலுத்தாத மாடல் மதிப்பாய்வாகும்.

விரைவாகத் தோல்வியடையுங்கள், ஒருமுறை மட்டும் மேலே எடுத்துச் செல்லுங்கள். பகிர்ந்தளிக்கப்பட்ட பணி தவறாகத் திரும்பினால், orchestrator-க்கு ஒரு கூர்மையான கட்டுப்பாட்டுடன் கூடிய திருத்த முயற்சி கிடைக்கும் ("முந்தைய முயற்சி டேப்லெட்டைக் கத்தரித்தது — முழு டேப்லெட்டும் தெரிய வேண்டும்"). அந்த மறுமுயற்சியும் தோல்வியுற்றால், அந்தப் பணியைப் பகிர்ந்தளிப்பதை நிறுத்துங்கள்; orchestrator அதை நேரடியாகச் செய்யும் அல்லது மாற்று வழியைக் கண்டுபிடிக்கும். முடிவற்ற மறுமுயற்சி சுழல்கள், எதையும் செய்வதற்கான மிக விலையுயர்ந்த வழியாக பகிர்ந்தளிப்பை மாற்றுகின்றன.

Orchestrator-இன் அமர்வைச் சுத்தமாக வைத்திருக்கவும். நீண்ட நேரம் இயங்கும் orchestrator அமர்வுகள் சூழலைக் குவிக்கின்றன, சூழல் என்பது ஒவ்வொரு முறையும் நீங்கள் செலுத்தும் உள்ளீட்டு-டோக்கன் வாடகையாகும். Artifacts உரையாடலில் இருப்பதற்குப் பதிலாக வட்டில் இருப்பதாலேயே பகிர்ந்தளிப்பு உதவுகிறது — அதைப் பின்வருமாறு செய்து சீரழிக்காதீர்கள் catகோப்புகளை "ஒரு பார்வை பார்ப்பதற்காக" அரட்டையில் -ing செய்வதன் மூலம்

நீங்கள் கற்றுக்கொண்ட கட்டுப்பாடுகளை templates-ல் எழுதவும். ஒவ்வொரு மறுவேலையும் உங்களுக்கு ஒரு prompt வரியைக் கற்பிக்கிறது ("no watermark," "fully inside frame," "no new dependencies"). ஒரே பாடத்திற்கு இரண்டு முறை பணம் செலுத்துவதை templates மூலம் நீங்கள் நிறுத்தலாம்.

இதன் ஒரு வாரம் உண்மையில் எப்படி இருக்கும்

தர ரீதியாக, ஒரு உண்மையான திட்ட வாரத்தில் இந்த முறையை இயக்கிய பிறகு: orchestrator-இன் சூழல் சிறியதாகவே இருந்தது மற்றும் அதன் சுழற்சிகள் வேகமாக இருந்தன, ஏனெனில் பெரிய அளவிலான வெளியீடு ஒருபோதும் உரையாடலில் நுழையவில்லை. காணக்கூடிய டோக்கன் செலவு கிட்டத்தட்ட முழுமையாக specs, அறிக்கைகள் மற்றும் மதிப்பாய்வுக்கு மாறியது — அங்குதான் நீங்கள் விரும்புகிறீர்கள் premium மாடல் தனது கவனத்தைச் செலுத்த வேண்டும். Sub-agents தங்கள் சொந்த ஒதுக்கீடுகளை அளவின் மீது செலவழித்தன. தோல்விகள் உண்மையானவை ஆனால் கட்டுப்படுத்தக்கூடியவை: ஆக்கப்பூர்வமான உருவாக்கங்களில் தோராயமாக கால் பகுதியிலாவது ஒரு திருத்தச் சுழற்சி, கச்சிதமான spec கொண்ட குறியீட்டுப் பணிகளில் கிட்டத்தட்ட பூஜ்ஜிய மறுவேலை, மற்றும் ஒரு பணி (ஒரு cross-cutting refactor), அதன் spec வரைவு ஒரு கட்டமைப்பு ஆவணமாக மாறத் தொடங்கிய பிறகு அதை நான் சரியாக orchestrator இடமே வைத்துக்கொண்டேன்.

இந்த முறை விலையுயர்ந்த மாடலை மலிவானதாக மாற்றவில்லை. அதை ஒரு தட்டச்சராகப் பயன்படுத்துவதை நிறுத்துமாறு செய்தது.

தீர்ப்பு மற்றும் ஒரு சரிபார்ப்புப் பட்டியல்

இந்த உத்தி சரியானதா? பெரும்பாலும், ஆம். அதிகமான உருவாக்கப் பணிகளுக்கு சேமிப்பு உண்மையானது மற்றும் பெரியது — அது இதன் பகிர்ந்தளிப்பு வெளியீடு, மேலும் வெளியீட்டிற்குத்தான் நீங்கள் பணம் செலுத்துகிறீர்கள். அதிக கணிப்பு தேவைப்படும் வேலைகளுக்கு சேமிப்பு ஒரு மாயை — அது இதன் பகிர்ந்தளிப்பு புரிதல், மேலும் புரிதல் எப்போதும் orchestrator-இன் கட்டணத்தில்தான் மீண்டும் வந்து சேரும், வழக்கமாக வட்டியுடன்.

விலையுயர்ந்த CLI-ஐ ஒரு சிறந்த, மலிவான குழுவுடன் உள்ள கறாரான tech lead-ஆகக் கருதுங்கள்: அது specs எழுதுகிறது, சிறிய அறிக்கைகளை மதிப்பாய்வு செய்கிறது, மற்றும் ஏதேனும் தவறாகத் தோன்றினால் மட்டுமே மூடியைத் திறந்து பார்க்கிறது.

ஒரு பணியைப் பகிர்ந்தளிப்பதற்கு முன், இந்தச் சரிபார்ப்புப் பட்டியலை இயக்கவும்:

• வெளியீடு பெரியதா (>100 வரிகள் / >2k டோக்கன்கள்) அல்லது orchestrator ஆல் உருவாக்கவே முடியாத ஒன்றா?
• என்னால் spec-ஐ எழுத முடியுமா எனது கட்டமைப்பை விளக்காமல்?
• "முடிந்தது" என்பது இயந்திரத்தால் சரிபார்க்கக்கூடியதா ("கவனமாகப் படிக்கவும்" என்பதற்குப் பதிலாக, tests, lint, file properties போன்றவை மூலம்)?
• வெளியீட்டுப் பாதை துல்லியமானதா, மேலும் பதில் இதற்கு மட்டுமே கட்டுப்படுத்தப்பட்டதா DONE + ஒரு ≤40-வரி அறிக்கை?
• நான் திட்டமிட்டுள்ளேனா ஒரு திருத்தச் சுழற்சிக்கு — மேலும் அது இரண்டு முறை தோல்வியுற்றால் என்ன நடக்கும் என்பதை முடிவு செய்துள்ளேனா?

ஐந்து ஆம்: அதைப் பகிர்ந்தளியுங்கள், background-ல் இயக்குங்கள், தணிக்கை செய்யுங்கள், மற்றும் கணிதத்தை அனுபவியுங்கள். ஏதேனும் இல்லை எனில்: premium மாடல் அதை நேரடியாகச் செய்கிறது — ஏனெனில் நீங்கள் செலவழிக்கும் மிக விலையுயர்ந்த டோக்கன்கள், இரண்டு முறை செலவழிக்கப்பட்டவையே.