ಒಂದು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್, ಮೂರು CLIಗಳು: Codex ಮತ್ತು Gemini ಗೆ ನಿಯೋಜಿಸುವುದರಿಂದ ನಿಜವಾಗಿಯೂ ನಿಮ್ಮ Claude ಟೋಕನ್‌ಗಳನ್ನು ಉಳಿಸಲು ಸಾಧ್ಯವೇ?

2026 ರಲ್ಲಿ ಅನೇಕ ಡೆವಲಪರ್‌ಗಳಂತೆ, ನಾನು ಸಹ ಒಂದೇ ಮೆಷಿನ್‌ನಲ್ಲಿ ಮೂರು AI ಕೋಡಿಂಗ್ CLIಗಳನ್ನು ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡಿದ್ದೇನೆ, ಮತ್ತು ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಬೇರೆ ಕಾರಣಗಳಿಗಾಗಿ ತನ್ನದೇ ಆದ ಸ್ಥಾನವನ್ನು ಪಡೆದುಕೊಂಡಿದೆ:

• Claude Code — ಆರ್ಕೆಸ್ಟ್ರೇಟರ್-ಮಟ್ಟದ ಏಜೆಂಟ್. ಬಹು-ಹಂತದ ತರ್ಕ, ಆರ್ಕಿಟೆಕ್ಚರ್, ಡಿಬಗ್ಗಿಂಗ್ ಮತ್ತು ದೊಡ್ಡ ಕೋಡ್‌ಬೇಸ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ಅತ್ಯುತ್ತಮವಾಗಿದೆ. ಹಾಗೆಯೇ ಇದರ ಟೋಕನ್‌ಗಳ ಬಗ್ಗೆಯೇ ನಾನು ಹೆಚ್ಚಾಗಿ ಕಾಳಜಿ ವಹಿಸುತ್ತೇನೆ.
• OpenAI Codex CLI — ನೀವು ನಿಖರವಾದ ಸ್ಪೆಕ್‌ನೊಂದಿಗೆ ಉತ್ತಮವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ, ಸ್ವಯಂ-ಪೂರ್ಣಗೊಂಡ ಕೆಲಸವನ್ನು ನೀಡಿದಾಗ ಅತ್ಯುತ್ತಮವಾಗಿ ಕೆಲಸ ಮಾಡುವ ಸಾಮರ್ಥ್ಯವಿರುವ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್.
• Google Gemini CLI — ಮಲ್ಟಿಮೋಡಲ್ ಕೆಲಸದ ಕುದುರೆ. ಚಿತ್ರ ರಚನೆ, ಆಡಿಯೋ ಮತ್ತು TTS, ಟ್ರಾನ್ಸ್‌ಕ್ರಿಪ್ಷನ್, ಮತ್ತು ಪ್ರಾದೇಶಿಕ ಭಾಷೆಗಳಿಗೆ ಉತ್ತಮ ಗುಣಮಟ್ಟದ ಅನುವಾದ.

ಯಾವುದೋ ಒಂದು ಹಂತದಲ್ಲಿ ಸ್ಪಷ್ಟ ಪ್ರಶ್ನೆ ಮೂಡುತ್ತದೆ: ಮೂರರಲ್ಲಿ ಅತ್ಯಂತ ಬುದ್ಧಿವಂತವಾಗಿರುವುದು ದಿನವಿಡೀ ಚಲಾಯಿಸಲು ಅತ್ಯಂತ ದುಬಾರಿಯಾಗಿದೆ. ಹಾಗಾಗಿ ನಾನು ಅದನ್ನು ಮ್ಯಾನೇಜರ್? Claude ಗೆ ಒಂದು ಕೆಲಸವನ್ನು ನೀಡಿ, ಅದನ್ನು ವಿಂಗಡಿಸಿ, Codex ಮತ್ತು Gemini ಗೆ ಭಾಗಗಳನ್ನು ನೀಡಿ, ಮತ್ತು ಅವು ಕೆಲಸ ಮುಗಿದ ನಂತರ markdown ಫೈಲ್‌ನೊಂದಿಗೆ ವರದಿ ಮಾಡುವಂತೆ ಮಾಡಿ — ಅದೇ ಸಮಯದಲ್ಲಿ Claude ಕೇವಲ ಕಷ್ಟಕರವಾದ ಭಾಗಗಳು ಮತ್ತು ಅಂತಿಮ ವಿಮರ್ಶೆಗೆ ಮಾತ್ರ ಟೋಕನ್‌ಗಳನ್ನು ವೆಚ್ಚ ಮಾಡುತ್ತದೆಯೇ?

ನಾನು ಈಗ ಈ ಪ್ಯಾಟರ್ನ್ ಅನ್ನು ವಾರಗಳ ಕಾಲ ನೈಜ ಕೆಲಸಕ್ಕಾಗಿ ನಡೆಸಿದ್ದೇನೆ — ಪೂರ್ಣ ಮಾರ್ಕೆಟಿಂಗ್-ಸೈಟ್ ಮರುವಿನ್ಯಾಸ, 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   │
            └─────────────────────────┘

ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಕೇವಲ ನಾಲ್ಕು ವಿಷಯಗಳನ್ನು ಮಾತ್ರ: ಯೋಜನೆ ( plan), ಸ್ಪೆಕ್ಸ್‌ ( specs), ವಿಮರ್ಶೆ ( review), ಮತ್ತು ಇಂಟಿಗ್ರೇಷನ್ ( integration). ಬೃಹತ್ ಮತ್ತು ಮೆಕ್ಯಾನಿಕಲ್ ಆದ ಎಲ್ಲವನ್ನೂ ಕೆಳಕ್ಕೆ ತಳ್ಳಲಾಗುತ್ತದೆ, ಎರಡು ಕಡ್ಡಾಯ ನಿಯಮಗಳೊಂದಿಗೆ:

ನಿಯಮ 1 — ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳು ನಿಖರವಾದ ಪಥದಲ್ಲಿ ಡಿಸ್ಕ್‌ಗೆ ಹೋಗುತ್ತವೆ. ಸಬ್-ಏಜೆಂಟ್ ತನ್ನ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಎಂದಿಗೂ ಸಂಭಾಷಣೆಯಲ್ಲಿ ಪೇಸ್ಟ್ ಮಾಡುವುದಿಲ್ಲ. ಅದು ಫೈಲ್‌ಗಳನ್ನು ಬರೆಯುತ್ತದೆ. ಆರ್ಕೆಸ್ಟ್ರೇಟರ್‌ನ ಕಾಂಟೆಕ್ಸ್ಟ್ ಸ್ವಚ್ಛವಾಗಿ ಉಳಿಯುತ್ತದೆ.

ನಿಯಮ 2 — ಪ್ರತ್ಯುತ್ತರವು ಬಹುತೇಕ ಏನೂ ಇರುವುದಿಲ್ಲ. ಆದರ್ಶಪ್ರಾಯವಾಗಿ ಒಂದೇ ಪದ ಜೊತೆಗೆ ಸಣ್ಣ markdown ರಿಪೋರ್ಟ್. ರಿಪೋರ್ಟ್ ಎನ್ನುವುದು ಏಕೈಕ ವಿಷಯವಾಗಿದ್ದು ಅದನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಖಂಡಿತವಾಗಿಯೂ ಓದುತ್ತದೆ.

ಈ ಲೇಖನದಿಂದ ನೀವು ಬೇರೇನನ್ನೂ ನೆನಪಿನಲ್ಲಿಟ್ಟುಕೊಳ್ಳದಿದ್ದರೂ: ನಿಯೋಜಿತ ಕೆಲಸದಲ್ಲಿ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಟೋಕನ್‌ಗಳನ್ನು ವೆಚ್ಚ ಮಾಡುವ ಏಕೈಕ ಎರಡು ಸ್ಥಳಗಳೆಂದರೆ ಡೆಲಿಗೇಷನ್ ಪ್ರಾಂಪ್ಟ್ ಮತ್ತು ರಿಪೋರ್ಟ್. ಉಳಿದೆಲ್ಲವೂ ಬೇರೆಯವರ ಬಿಲ್. ನಿಮ್ಮ ಸಂಪೂರ್ಣ ಆಪ್ಟಿಮೈಸೇಶನ್ ಮೇಲ್ಮೈ ಆ ಎರಡು ದಾಖಲೆಗಳಾಗಿವೆ.

ಹಂತ ಹಂತದ ಮಾರ್ಗದರ್ಶಿ #1: Gemini ಗೆ ಚಿತ್ರ ರಚನೆಯನ್ನು ನಿಯೋಜಿಸುವುದು

ಇದು ನಾನು ಚಲಾಯಿಸುವ ಅತ್ಯಂತ ಹೆಚ್ಚಿನ ಮೌಲ್ಯದ ನಿಯೋಜನೆಯಾಗಿದೆ, ಏಕೆಂದರೆ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಸ್ವತಃ ಇದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ — 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.

ಈ ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿರುವ ಎಂಜಿನಿಯರಿಂಗ್ ಗಮನಿಸಿ:

• ಔಟ್‌ಪುಟ್ ಪಥವು ನಿಖರವಾಗಿದೆ. "ಎಲ್ಲಾದರೂ ಉಳಿಸಿ" ಎಂದಿಲ್ಲ — ಆರ್ಕೆಸ್ಟ್ರೇಟರ್‌ಗೆ ಎಲ್ಲಿ ನೋಡಬೇಕೆಂದು ನಿಖರವಾಗಿ ತಿಳಿದಿರುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾವುದೇ ಅನಗತ್ಯ ಸಂವಹನವಿರುವುದಿಲ್ಲ.
• "Reply only DONE." Gemini CLI ತನ್ನ ಸೃಜನಶೀಲ ಪ್ರಕ್ರಿಯೆಯನ್ನು 400 ಟೋಕನ್‌ಗಳವರೆಗೆ ಸಂತೋಷದಿಂದ ವಿವರಿಸುತ್ತದೆ. ನಮಗೆ ಅದು ಬೇಡ. ಒಂದೇ ಪದ.
• ಮಿತಿಗಳನ್ನು ಮೆಕ್ಯಾನಿಕಲ್ ಆಗಿ ಸ್ಪಷ್ಟಪಡಿಸಲಾಗಿದೆ ("fully inside the frame," "no watermark") ಏಕೆಂದರೆ ನೀವು ಬರೆಯದಿರುವ ಪ್ರತಿಯೊಂದು ಮಿತಿಯೂ ಮರು-ಕೆಲಸದ ರೂಲೆಟ್ ಸ್ಪಿನ್ ಆಗಿದೆ. ನಾನು ಆ ಪ್ರತಿಯೊಂದು ಸಾಲನ್ನು ಒಂದು ವಿಫಲತೆಯಿಂದ ಕಲಿತಿದ್ದೇನೆ — ಅದರ ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ಮಾಹಿತಿ ಕೆಳಗಿದೆ.

ನಂತರ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಚಿತ್ರವನ್ನು ನೋಡುವ ಮೊದಲೇ ಕ್ವಾಲಿಟಿ ಗೇಟ್ ಅನ್ನು ಚಲಾಯಿಸುತ್ತದೆ — ಅಗ್ಗದ, ಮೆಕ್ಯಾನಿಕಲ್ ಪರಿಶೀಲನೆ:

# 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: Codex ಗೆ ಕೋಡಿಂಗ್ ಕೆಲಸವನ್ನು ನಿಯೋಜಿಸುವುದು

ಕೋಡಿಂಗ್ ನಿಯೋಜನೆಯು ಹೆಚ್ಚು ಜಟಿಲವಾಗಿದೆ, ಏಕೆಂದರೆ ವೈಫಲ್ಯದ ಶೈಲಿಯು ಒಂದೇ ನೋಟದಲ್ಲಿ ನೋಡಬಹುದಾದ ಕೆಟ್ಟ ಚಿತ್ರವಲ್ಲ — ಇದು ನಿಮ್ಮ ಕೋಡ್‌ಬೇಸ್‌ಗೆ ಹೊಂದಿಕೆಯಾಗದಂತೆ ಸರಿಯಾಗಿ ಕಾಣುವ ಕೋಡ್ ಆಗಿದೆ. ಪರಿಹಾರವೆಂದರೆ "done" ಎಂಬುದನ್ನು ಯಂತ್ರದಿಂದ ಪರಿಶೀಲಿಸಬಹುದಾದಷ್ಟು ಬಿಗಿಯಾದ ಸ್ಪೆಕ್ ಅನ್ನು ನೀಡುವುದು:

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. ಸೀಮಿತ ಇಂಟರ್‌ಫೇಸ್ — ಇನ್‌ಪುಟ್ ಫೈಲ್, ಔಟ್‌ಪುಟ್ ಫೈಲ್, ಮುಗಿಯಿತು. ಸಬ್-ಏಜೆಂಟ್ ಕೋಡ್‌ಬೇಸ್‌ನ ಇತರ ಭಾಗಗಳಿಗೆ ಅಲೆದಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.

ರಿಪೋರ್ಟ್ ಬಂದಾಗ, ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಸ್ವೀಕಾರ ಕಮಾಂಡ್‌ಗಳನ್ನು ಚಲಾಯಿಸುತ್ತದೆ (ಅಗ್ಗ), ತೊಂದರೆಗಳನ್ನು (gotchas) ಮೇಲ್ನೋಟಕ್ಕೆ ಪರಿಶೀಲಿಸುತ್ತದೆ (ಅಗ್ಗ), ಮತ್ತು ಏನಾದರೂ ವಿಫಲವಾದರೆ ಅಥವಾ ತಪ್ಪಾಗಿದೆ ಎನಿಸಿದರೆ ಮಾತ್ರ ನೈಜ ಕೋಡ್ ಅನ್ನು ತೆರೆಯುತ್ತದೆ. ಯಶಸ್ವಿಯಾಗಿ ಪಾಸ್ ಆದರೆ, ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ತಾನು ಬರೆಯಬೇಕಿದ್ದ 300 ಸಾಲುಗಳನ್ನು ಎಂದಿಗೂ ಓದುವುದಿಲ್ಲ — ಅದೇ ಉಳಿತಾಯ.

ಉಳಿತಾಯವು ಎಲ್ಲಿ ನೈಜವಾಗಿದೆ — ಅಂದಾಜು ಲೆಕ್ಕಾಚಾರದೊಂದಿಗೆ

1. ಬಲ್ಕ್ ಜನರೇಷನ್. ಒಂದು ಕೆಲಸವು 2,000 ಸಾಲುಗಳ ಔಟ್‌ಪುಟ್ (~25k ಟೋಕನ್‌ಗಳು) ನೀಡುತ್ತದೆ ಎಂದುಕೊಳ್ಳಿ. ನೇರವಾಗಿ ಮಾಡಿದರೆ, ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ~25k ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳು ಮತ್ತು ಅದರ ಸುತ್ತಲಿನ ಎಲ್ಲಾ ಕಾಂಟೆಕ್ಸ್ಟ್-ರೀಡಿಂಗ್‌ಗೆ ಪಾವತಿಸುತ್ತದೆ. ನಿಯೋಜಿಸಿದಾಗ, ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಪಾವತಿಸುವುದು: ~300-ಟೋಕನ್ ಸ್ಪೆಕ್, ~400-ಟೋಕನ್ ರಿಪೋರ್ಟ್ ರೀಡ್, ಮತ್ತು ಕೆಲವು ನೂರು ಟೋಕನ್‌ಗಳ ವೆರಿಫಿಕೇಶನ್ ಕಮಾಂಡ್‌ಗಳು. ಇದನ್ನು ~30k ವಿರುದ್ಧ ~1k ಟೋಕನ್‌ಗಳು — 95%+ ಗಿಂತ ಹೆಚ್ಚಿನ ಕಡಿತ ಆ ಕೆಲಸದಲ್ಲಿ, ಪ್ರಕ್ರಿಯೆಯ ಬಿಲ್ ಸಬ್-ಏಜೆಂಟ್‌ನ ಕೋಟಾಕ್ಕೆ ಹೋಗುತ್ತದೆ.

2. ಆರ್ಕೆಸ್ಟ್ರೇಟರ್‌ಗೆ ಹೇಗೂ ಮಾಡಲು ಸಾಧ್ಯವಾಗದ ಕೆಲಸ. ನಾನು ಇತ್ತೀಚೆಗೆ ರವಾನಿಸಿದ ಪ್ರತಿಯೊಂದು ಚಿತ್ರ, ಪ್ರತಿಯೊಂದು ಆಡಿಯೋ ಫೈಲ್, ಎಂಟು ಭಾಷೆಗಳ ಅನುವಾದದ ಪ್ರತಿಯೊಂದು ಬ್ಯಾಚ್ ಅನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಬರೆದ ಸ್ಪೆಕ್‌ನಿಂದ Gemini CLI ರಚಿಸಿದೆ. ಹೋಲಿಸಲು ಯಾವುದೇ Claude-ನೇಟಿವ್ ಪರ್ಯಾಯವಿಲ್ಲ — ಇದು ಶುದ್ಧ ಸಾಮರ್ಥ್ಯದ ಲಾಭ, ಮತ್ತು ಟೋಕನ್ ವೆಚ್ಚವು ಕೇವಲ ಸ್ಪೆಕ್ + ರಿಪೋರ್ಟ್ ಆಗಿದೆ.

3. ನಿಖರವಾದ ಸ್ಪೆಕ್‌ನೊಂದಿಗೆ ದೀರ್ಘ ಮೆಕ್ಯಾನಿಕಲ್ ಔಟ್‌ಪುಟ್. ಟೆಸ್ಟ್ ಸ್ಕ್ಯಾಫೋಲ್ಡಿಂಗ್, ಡೇಟಾ ಮೈಗ್ರೇಷನ್‌ಗಳು, ಬಾಯ್ಲರ್‌ಪ್ಲೇಟ್ ಮಾಡ್ಯೂಲ್‌ಗಳು, ಫಾರ್ಮ್ಯಾಟ್ ಪರಿವರ್ತನೆಗಳು, ಔಟ್‌ಲೈನ್‌ನಿಂದ ಡಾಕ್ ಡ್ರಾಫ್ಟ್‌ಗಳು. ಸಾಮಾನ್ಯ ವಿಷಯ: ಕಡಿಮೆ ನಿರ್ಧಾರ, ಹೆಚ್ಚಿನ ಪ್ರಮಾಣ. ಪ್ರಮಾಣವೇ ಔಟ್‌ಪುಟ್ ಟೋಕನ್‌ಗಳ ಬೆಲೆಯನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ; ನಿರ್ಧಾರದ ಕೊರತೆಯೇ ಅಗ್ಗದ ಏಜೆಂಟ್‌ನಲ್ಲಿದೆ. ಪ್ರಮಾಣವನ್ನು ನಿಯೋಜಿಸಿ, ನಿರ್ಧಾರವನ್ನು ನಿಮ್ಮ ಬಳಿಯೇ ಇಟ್ಟುಕೊಳ್ಳಿ.

ಉಳಿತಾಯವು ಎಲ್ಲಿ ಇಲ್ಲದಂತಾಗುತ್ತದೆ — ಎರಡು ತೆರಿಗೆಗಳು ಮತ್ತು ಒಂದು ಓವರ್‌ಹೆಡ್

ವೆರಿಫಿಕೇಶನ್ ತೆರಿಗೆ

ಇದು ಯಾರೂ ಲೆಕ್ಕಿಸದ ವೆಚ್ಚವಾಗಿದೆ, ಆದ್ದರಿಂದ ನನ್ನ ಸ್ವಂತ ಪ್ರಾಜೆಕ್ಟ್‌ನಿಂದ ನಾನು ನಿಮಗೆ ಉದಾಹರಣೆಗಳನ್ನು ನೀಡುತ್ತೇನೆ — ವೆಬ್‌ಸೈಟ್‌ಗಾಗಿ AI-ರಚಿತ ಹೀರೊ ಭಾವಚಿತ್ರಗಳ ಬ್ಯಾಚ್:

• ಒಂದು ಚಿತ್ರವು ಸ್ಪರ್ಧಿಯೆಂದು ಗುರುತಿಸಬಹುದಾದ ಲ್ಯಾಪ್‌ಟಾಪ್ ಲೋಗೋದೊಂದಿಗೆ ಶೂಟ್‌ನಲ್ಲಿ ಸೇರಿಕೊಂಡು ಹಿಂತಿರುಗಿತು. ಕಾನೂನುಬದ್ಧವಾಗಿ ಮತ್ತು ಬ್ರ್ಯಾಂಡ್ ದೃಷ್ಟಿಯಿಂದ ಬಳಸಲಾಗುವುದಿಲ್ಲ. ಮರು-ರಚಿಸಿ — ಇಲ್ಲ ತಡೆಯಿರಿ, ನಿಜವಾಗಿ ಇಮೇಜ್ ಟೂಲ್‌ನಿಂದ ಅದನ್ನು ತಿದ್ದಿ , ನಂತರ ಮರು-ಪರಿಶೀಲಿಸಿ.
• ಮತ್ತೊಂದು ಸೆಟ್‌ನ ಮೂಲೆಗಳು ಪಾರದರ್ಶಕವಾಗಿವೆ ಎಂದು ಹೇಳಿಕೊಂಡಿದ್ದರೂ ಹಾಗೆ ಇರಲಿಲ್ಲ — ಬಣ್ಣದ ಹಿನ್ನೆಲೆಯಲ್ಲಿ ಮಾತ್ರ ಕಾಣಿಸುವ ಅಪಾರದರ್ಶಕ ಬಿಳಿ ಬಣ್ಣ. ತಡವಾಗಿ ಪತ್ತೆಯಾಯಿತು, ಫ್ಲಡ್-ಫಿಲ್ ಪಾಸ್‌ನೊಂದಿಗೆ ಸರಿಪಡಿಸಲಾಯಿತು, ಮರು-ಪರಿಶೀಲಿಸಲಾಯಿತು.
• ಮೂರನೆಯದರಲ್ಲಿ ಪ್ರಾಡಕ್ಟ್ ಟ್ಯಾಬ್ಲೆಟ್ ಫ್ರೇಮ್‌ನಿಂದ ಅರ್ಧ ಹೊರಗೆ ಬಂದು ರಚನೆಯಾಗಿತ್ತು — ಚಿತ್ರ ತೋರಿಸಲು ಇದ್ದ ವಸ್ತುವನ್ನೇ ಮಾಡೆಲ್ ಕ್ರಾಪ್ ಮಾಡಿತ್ತು. ಹೊಸ "everything fully inside the frame" ಕನ್‌ಸ್ಟ್ರೇಂಟ್ ಲೈನ್‌ನೊಂದಿಗೆ ಸಂಪೂರ್ಣ ಮರು-ರಚನೆ.

ಆ ಪ್ರತಿಯೊಂದು ಚಿತ್ರವೂ ಅಗ್ಗದ ಮೆಕ್ಯಾನಿಕಲ್ ಗೇಟ್‌ಗಳನ್ನು ದಾಟಿದೆ . ಪ್ರತಿಯೊಂದಕ್ಕೂ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ನಿಜವಾಗಿ ವೀಕ್ಷಿಸಲು, ನಿರ್ಧರಿಸಲು ಮತ್ತು ತಿದ್ದುಪಡಿಯನ್ನು ನಿರ್ದೇಶಿಸಲು ಅಗತ್ಯವಿತ್ತು. ನಿಯೋಜನೆಯು ವಿಮರ್ಶೆಯ ಹಂತವನ್ನು ತೆಗೆದುಹಾಕಲಿಲ್ಲ — ಅದು ಜನರೇಷನ್ ವೆಚ್ಚವನ್ನು ಬೇರೆಡೆಗೆ ಸರಿಸಿತು ಮತ್ತು ವಿಮರ್ಶೆಯ ವೆಚ್ಚವನ್ನು ಇದ್ದಂತೆಯೇ ಬಿಟ್ಟಿತು.

ಮತ್ತು ನಿಯೋಜಿತ ಕೆಲಸವು ವಿಮರ್ಶೆಯಲ್ಲಿ ವಿಫಲವಾದಾಗ, ನೀವು ಮೂರು ಬಾರಿಪಾವತಿಸುತ್ತೀರಿ: ನಿಯೋಜನೆ, ಅದನ್ನು ಕಂಡುಹಿಡಿದ ವಿಮರ್ಶೆ, ಮತ್ತು ಮರು-ಕೆಲಸ. ಒಂದೇ ಕೆಲಸದ ಎರಡು ವಿಫಲ ನಿಯೋಜನೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಅದನ್ನು ಮೊದಲ ಬಾರಿಗೆ ನೇರವಾಗಿ ಮಾಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ವೆಚ್ಚವಾಗುತ್ತವೆ. ಅದಕ್ಕಾಗಿಯೇ ನನ್ನ ಇಮೇಜ್ ಪ್ರಾಂಪ್ಟ್‌ಗಳಲ್ಲಿನ ಪ್ರತಿಯೊಂದು ಕನ್‌ಸ್ಟ್ರೇಂಟ್ ಲೈನ್ ಗಾಯದ ಗುರುತಿನಂತೆ ಭಾಸವಾಗುತ್ತದೆ — ಪ್ರತಿಯೊಂದೂ ಒಂದು ಆಗಿದೆ.

ಬಜೆಟ್ ನಿಯಮ: ನಿಯೋಜಿತ ಸೃಜನಶೀಲ ಕೆಲಸಗಳಲ್ಲಿ 20–30% ಗೆ ತಿದ್ದುಪಡಿ ಸೈಕಲ್ ಅಗತ್ಯವಿದೆ ಎಂದು ಭಾವಿಸಿ, ಮತ್ತು ಅದನ್ನು ನಿಮ್ಮ ನಿರ್ಧಾರದಲ್ಲಿ ಪರಿಗಣಿಸಿ. ಕೆಲಸವನ್ನು ಪರಿಶೀಲಿಸುವುದು ಅಗ್ಗವಾಗಿದ್ದರೆ (ಟೆಸ್ಟ್‌ಗಳನ್ನು ನಡೆಸುವುದು, ಫೈಲ್ ಪರಿಶೀಲಿಸುವುದು), ಮರು-ಕೆಲಸದೊಂದಿಗೂ ನಿಯೋಜನೆಯು ಗೆಲ್ಲುತ್ತದೆ. ವೆರಿಫಿಕೇಶನ್ ಎಂದರೆ "ಎಲ್ಲವನ್ನೂ ಜಾಗರೂಕತೆಯಿಂದ ಓದುವುದು" ಎಂದಾದರೆ, ಉಳಿತಾಯವು ಕೇವಲ ಭ್ರಮೆಯಾಗಿತ್ತು.

ಇಂಟಿಗ್ರೇಷನ್ ತೆರಿಗೆ

ಕೆಲಸವು ಹಲವು ಫೈಲ್‌ಗಳನ್ನು ಮುಟ್ಟಿದರೆ, ನಿಮ್ಮ ಕೋಡ್‌ಬೇಸ್‌ನ ನಿಯಮಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕಾದರೆ, ಅಥವಾ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್‌ನ ಮನಸ್ಸಿನಲ್ಲಿರುವ ಕಾಂಟೆಕ್ಸ್ಟ್ ಅನ್ನು ಅವಲಂಬಿಸಿದ್ದರೆ — ಆರ್ಕಿಟೆಕ್ಚರ್ ನಿರ್ಧಾರಗಳು, ಕ್ರಾಸ್-ಮಾಡ್ಯೂಲ್ ರಿಫ್ಯಾಕ್ಟರ್, ರೇಸ್-ಕಂಡೀಷನ್ ಡಿಬಗ್ — ಅದನ್ನು ಹಸ್ತಾಂತರಿಸುವುದು ಸುಳ್ಳು ಉಳಿತಾಯವಾಗಿದೆ. ಸಬ್-ಏಜೆಂಟ್ ಬಳಿ ನಿಮ್ಮ ಕಾಂಟೆಕ್ಸ್ಟ್ ಇರುವುದಿಲ್ಲ; ಅದನ್ನು ಸುರಕ್ಷಿತವಾಗಿ ಸಂಯೋಜಿಸಲು ಸಬ್-ಏಜೆಂಟ್ ಮುಟ್ಟಿದ ಪ್ರತಿಯೊಂದನ್ನೂ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಮತ್ತೆ ಓದಬೇಕಾಗುತ್ತದೆ. ಒಂದೇ ಅರ್ಥೈಸಿಕೊಳ್ಳುವಿಕೆಗೆ ನೀವು ಎರಡು ಬಾರಿ ಪಾವತಿಸಿದ್ದೀರಿ: ಒಮ್ಮೆ ಸಬ್-ಏಜೆಂಟ್ ತನ್ನದೇ ಆದ ಭಾಗಶಃ ಚಿತ್ರವನ್ನು ನಿರ್ಮಿಸಲು, ಒಮ್ಮೆ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಸಂಪೂರ್ಣ ಚಿತ್ರವನ್ನು ಮರುನಿರ್ಮಿಸಲು.

ಲಕ್ಷಣವು ಸರಳವಾಗಿದೆ: ಸ್ಪೆಕ್ ಬರೆಯಲು ನಿಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ವಿವರಿಸಬೇಕಾದರೆ, ಆ ಕೆಲಸವನ್ನು ನಿಯೋಜಿಸಬೇಡಿ. ಸ್ಪೆಕ್ ಬರೆಯುವುದೊಂದೇ ಉಳಿತಾಯಕ್ಕಿಂತ ಹೆಚ್ಚು ವೆಚ್ಚವಾಗುತ್ತದೆ, ಮತ್ತು ತಪ್ಪಾಗಿ ಅರ್ಥೈಸಿಕೊಳ್ಳುವ ಅಪಾಯವು ತುಂಬಾ ದೊಡ್ಡದಾಗಿದೆ.

ಓವರ್‌ಹೆಡ್ ಮಿತಿ

ಉತ್ತಮ ನಿಯೋಜನೆ ಪ್ರಾಂಪ್ಟ್ ಬರೆಯಲು 200–400 ಟೋಕನ್‌ಗಳು ವೆಚ್ಚವಾಗುತ್ತವೆ. ರಿಪೋರ್ಟ್ ಓದಲು 300–500 ವೆಚ್ಚವಾಗುತ್ತದೆ. ವೆರಿಫಿಕೇಶನ್, ಇನ್ನಷ್ಟು ನೂರು. ಆದ್ದರಿಂದ ಒಂದು ಮಿತಿ ಇದೆ: ಕೆಲಸದ ನೇರ ವೆಚ್ಚವು ಅಂದಾಜು 1,000–2,000 ಟೋಕನ್‌ಗಳಿಗಿಂತ (~50–100 ಸಾಲುಗಳ ಔಟ್‌ಪುಟ್) ಕಡಿಮೆಯಿದ್ದರೆ, ಅದನ್ನು ನಿಯೋಜಿಸುವುದರಿಂದ ಪ್ರತಿಯೊಮ್ಮೆ ಹಣ ನಷ್ಟವಾಗುತ್ತದೆ. ನೇರವಾಗಿ ನೀವೇ ಮಾಡಿ.

markdown ರಿಪೋರ್ಟ್ ಒಪ್ಪಂದ — ಉಳಿತಾಯವು ಎಲ್ಲಿ ಬದುಕುತ್ತದೆ ಅಥವಾ ಸಾಯುತ್ತದೆ

ಹೆಚ್ಚಿನ ಜನರಿಗೆ ಈ ಪ್ಯಾಟರ್ನ್ ಹಿಡಿಸಲು ಕಾರಣವಾಗುವ ಕಲ್ಪನೆಯೆಂದರೆ ರಿಪೋರ್ಟ್ ಫೈಲ್: ಪ್ರತಿಯೊಂದು ಸಬ್-ಏಜೆಂಟ್ ಕೆಲಸ ಮುಗಿಸಿ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್‌ಗಾಗಿ markdown ಸಾರಾಂಶವನ್ನು ನೀಡುತ್ತದೆ. ಇದು ಸರಿಯಾದ ಆಲೋಚನೆ — ಮತ್ತು ಇಡೀ ಯೋಜನೆಯು ಮೌನವಾಗಿ ವಿಫಲವಾಗುವುದು ಸಹ ಇಲ್ಲೇ. Codex 500 ಸಾಲುಗಳ ರಿಪೋರ್ಟ್ ಬರೆದು Claude ಅದನ್ನು ಪೂರ್ತಿಯಾಗಿ ಓದಿದರೆ, ನೀವು ಬರೆಯುವ ಬದಲು ಓದುವುದಕ್ಕೆ ಪಾವತಿಸಿದ್ದೀರಿ ಎಂದರ್ಥ.

ಇಲ್ಲಿದೆ ಒಂದು ಕೆಟ್ಟ ರಿಪೋರ್ಟ್ (ನೀವು ನಿಯಂತ್ರಿಸದಿದ್ದರೆ ಏಜೆಂಟ್‌ಗಳು ಇದನ್ನು ನೀಡುತ್ತವೆ):

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 ಸಾಲುಗಳು. ಡೆಲಿಗೇಷನ್ ಪ್ರಾಂಪ್ಟ್‌ನಲ್ಲಿ ಇದನ್ನು ತಿಳಿಸಿ. ಸ್ಟೇಟಸ್, ಪಾತ್‌ಗಳು, ವೆರಿಫೈ ಕಮಾಂಡ್‌ಗಳು, ಸಮಸ್ಯೆಗಳು (gotchas) — ಬೇರೇನೂ ಇಲ್ಲ.
2. ಪಾತ್‌ಗಳು, ಎಂದಿಗೂ ಕಂಟೆಂಟ್‌ಗಳಲ್ಲ. ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳು ಡಿಸ್ಕ್‌ನಲ್ಲಿರುತ್ತವೆ; ರಿಪೋರ್ಟ್ ಅವುಗಳನ್ನು ಸೂಚಿಸುತ್ತದೆ. ವೆರಿಫಿಕೇಶನ್‌ಗೆ ಅಗತ್ಯವಿದ್ದಾಗ ಮಾತ್ರ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಫೈಲ್ ತೆರೆಯುತ್ತದೆ — ಎರಡು ಬಾರಿ ಓದುವುದು ಒಂದು ಆಯ್ಕೆಯಾಗುತ್ತದೆ, ಡಿಫಾಲ್ಟ್ ಅಲ್ಲ.
3. "Reply only DONE" ಶುದ್ಧ ಜನರೇಷನ್‌ಗಾಗಿ. ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ತನ್ನಷ್ಟಕ್ಕೆ ತಾನೇ ಮಾತನಾಡುವಾಗ (ಚಿತ್ರ, ಆಡಿಯೋ ಫೈಲ್), ರಿಪೋರ್ಟ್ ಕೂಡ ಹೆಚ್ಚಾಗುತ್ತದೆ. ಫೈಲ್ ಬರುತ್ತದೆ, ಒಂದು ಪದ ಹಿಂತಿರುಗುತ್ತದೆ, ಗೇಟ್‌ಗಳು ಚಲಾಯಿಸಲ್ಪಡುತ್ತವೆ.
4. ಪ್ರತಿಯೊಂದು ಸ್ಪೆಕ್‌ನಲ್ಲಿ ಯಂತ್ರದಿಂದ ಪರಿಶೀಲಿಸಬಹುದಾದ ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳು. "Make it nice" ಮರು-ಕೆಲಸವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. "All tests pass, zero lint errors, output is a 1200×630 JPEG under 200 KB" ಎಂಬುದು ಪಾಸ್/ಫೇಲ್ ನೀಡುತ್ತದೆ, ಅದನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಒಂದೇ ಕಮಾಂಡ್‌ನಲ್ಲಿ ಪರಿಶೀಲಿಸುತ್ತದೆ. ನಿಮ್ಮ ಸ್ವೀಕಾರ ಮಾನದಂಡಗಳ ಗುಣಮಟ್ಟವೇ ನಿಮ್ಮ ನಿಯೋಜನೆಯ ಗುಣಮಟ್ಟವಾಗಿದೆ.

ಶ್ರಮ ವಿಭಜನೆ: ಯಾರಿಗೆ ಏನು ನೀಡಬೇಕು, ಮತ್ತು ಏಕೆ

ಕೆಲಸ	ಯಾರಿಗೆ ನೀಡಬೇಕು	ಏಕೆ
ಚಿತ್ರಗಳು, ಆಡಿಯೋ/TTS, ಟ್ರಾನ್ಸ್‌ಕ್ರಿಪ್ಷನ್	Gemini CLI — ಯಾವಾಗಲೂ	Orchestrator ಇದನ್ನು ಮಾಡಲು ಸಾಧ್ಯವೇ ಇಲ್ಲ; ಸಂಪೂರ್ಣ ಲಾಭ
ಭಾಷಾಂತರ (ವಿಶೇಷವಾಗಿ ಪ್ರಾದೇಶಿಕ ಭಾಷೆಗಳು)	Gemini CLI	ಉತ್ತಮ ಗುಣಮಟ್ಟ, ಹೆಚ್ಚಿನ ಪ್ರಮಾಣ, ಸ್ಯಾಂಪ್ಲಿಂಗ್ ಮೂಲಕ ಸುಲಭವಾಗಿ ಪರಿಶೀಲಿಸಬಹುದಾದದ್ದು
ಖಚಿತವಾದ ಸ್ಪೆಕ್‌ನೊಂದಿಗೆ ಸ್ವಯಂ-ಪೂರ್ಣಗೊಂಡ ಸ್ಕ್ರಿಪ್ಟ್/ಮಾಡ್ಯೂಲ್	Codex CLI	ಹೆಚ್ಚಿನ ಪ್ರಮಾಣ, ಕಡಿಮೆ ತೀರ್ಮಾನದ ಅಗತ್ಯ, ಮೆಷಿನ್‌ನಿಂದ ಪರಿಶೀಲಿಸಬಹುದಾದದ್ದು
ಟೆಸ್ಟ್ ಸ್ಕ್ಯಾಫೋಲ್ಡಿಂಗ್, ಮೈಗ್ರೇಷನ್‌ಗಳು, ಬಾಯ್ಲರ್‌ಪ್ಲೇಟ್	Codex CLI	ಯಾಂತ್ರಿಕ ಔಟ್‌ಪುಟ್; ಸ್ವೀಕಾರ = ಪರೀಕ್ಷೆಗಳೇ ಸ್ವತಃ
ಆರ್ಕಿಟೆಕ್ಚರ್ & ವಿನ್ಯಾಸ ನಿರ್ಧಾರಗಳು	Claude — ಎಂದಿಗೂ ಡೆಲಿಗೇಟ್ ಮಾಡಬೇಡಿ	ಸಂಪೂರ್ಣ ತೀರ್ಮಾನ; ಸ್ಪೆಕ್ ಬರೆಯುವುದಕ್ಕೇ ಕಾರ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ವೆಚ್ಚವಾಗುತ್ತದೆ
ಮಲ್ಟಿ-ಫೈಲ್ ರಿಫ್ಯಾಕ್ಟರ್‌ಗಳು, ಇಂಟಿಗ್ರೇಷನ್ ಕೆಲಸ	Claude	ಇಂಟಿಗ್ರೇಷನ್ ವೆಚ್ಚವು ಡೆಲಿಗೇಶನ್ ಅನ್ನು ಸುಳ್ಳು ಉಳಿತಾಯವನ್ನಾಗಿ ಮಾಡುತ್ತದೆ
ಡಿಬಗ್ಗಿಂಗ್	Claude	ಸಂಗ್ರಹವಾದ ಕಾನ್ಟೆಕ್ಸ್ಟ್ ಅಗತ್ಯವಿದೆ; ಸಬ್-ಏಜೆಂಟ್ ಶೂನ್ಯದಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ
ನಿಯೋಜಿಸಲಾದ ಪ್ರತಿಯೊಂದರ ಅಂತಿಮ ಪರಿಶೀಲನೆ	Claude	ನೀವು ಪ್ರೀಮಿಯಂ ಮಾಡೆಲ್‌ಗೆ ಹಣ ಪಾವತಿಸುತ್ತಿರುವುದು ನಿಜವಾಗಿಯೂ ಇದೇ ಕೆಲಸಕ್ಕಾಗಿ

ಹೇಳಲು ಯೋಗ್ಯವಾದ ಒಂದು ಸೂಕ್ಷ್ಮ ವಿಷಯ: ಇದು "Claude ಒಳ್ಳೆಯದು, ಇತರರು ಕೆಟ್ಟವರು" ಎಂದಲ್ಲ. ಇದು ಪ್ರಮಾಣ ವರ್ಸಸ್ ತೀರ್ಮಾನ. Codex ಅತ್ಯುತ್ತಮ ಸ್ವಯಂ-ಪೂರ್ಣಗೊಂಡ ಕೋಡ್ ಬರೆಯುತ್ತದೆ; Gemini ನ ಚಿತ್ರ ಮತ್ತು ಅನುವಾದದ ಗುಣಮಟ್ಟವು ನೈಜ ಪ್ರೊಡಕ್ಷನ್ ಕೆಲಸವನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಈ ವಿಭಾಗವು ಪ್ರತಿಯೊಂದು ಸೀಟ್‌ನ ವೆಚ್ಚ ಎಷ್ಟು ಮತ್ತು ಪ್ರತಿಯೊಂದು ಕಾರ್ಯಕ್ಕೆ ಏನು ಅಗತ್ಯವಿದೆ ಎಂಬುದರ ಕುರಿತಾಗಿದೆ.

ಕಾರ್ಯಾಚರಣೆಯ ಪ್ಲೇಬುಕ್

ಉಳಿತಾಯವನ್ನು ಹೆಚ್ಚಿಸುವ ಕೆಲವು ಅಭ್ಯಾಸಗಳು:

ನಿಧಾನವಾಗಿರುವ ಪ್ರತಿಯೊಂದನ್ನೂ ಬ್ಯಾಕ್‌ಗ್ರೌಂಡ್‌ನಲ್ಲಿಡಿ. ಜನರೇಷನ್ ಕೆಲಸಗಳು ಒಂದರಿಂದ ಐದು ನಿಮಿಷಗಳವರೆಗೆ ಚಲಿಸುತ್ತವೆ. ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ (detached) ಚಾಲನೆ ಮಾಡಿ, orchestrator ಅನ್ನು ಬೇರೆ ಕೆಲಸದಲ್ಲಿ ನಿರತವಾಗಿರಿಸಿ, ಫೈಲ್‌ಗಳು ಬಂದಾಗ ಫಲಿತಾಂಶಗಳನ್ನು ಪ್ರೊಸೆಸ್ ಮಾಡಿ. ದುಬಾರಿ ಏಜೆಂಟ್‌ ಅನ್ನು ಬ್ಲಾಕ್ ಆಗಿ ಕಾಯಲು ಎಂದಿಗೂ ಬಿಡಬೇಡಿ.

ಆಕ್ರಮಣಕಾರಿಯಾಗಿ ಬ್ಯಾಚ್ ಮಾಡಿ. ಆರು ಚಿತ್ರಗಳನ್ನು ಆರು ಸಂಭಾಷಣೆಗಳಾಗಿ ಮಾಡುವುದು ಆರು ಸುತ್ತಿನ ಪ್ರಾಂಪ್ಟ್+ರಿಪೋರ್ಟ್ ಓವರ್‌ಹೆಡ್ ಆಗುತ್ತದೆ. ಹೆಸರಿಸುವ ಕನ್ವೆನ್ಷನ್‌ನೊಂದಿಗೆ ಆರು ಫೈಲ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸುವ ಒಂದು ಪ್ರಾಂಪ್ಟ್ (hero-01.png … hero-06.png), ಒಂದು ರಿಪೋರ್ಟ್, ಒಂದು ರಿವ್ಯೂ ಪಾಸ್. ಅನುವಾದಗಳಿಗೂ ಇದುವೇ ಅನ್ವಯಿಸುತ್ತದೆ: ಒಂದೇ ಡೆಲಿಗೇಶನ್‌ನಲ್ಲಿ ಎಲ್ಲಾ ಎಂಟು ಭಾಷೆಗಳು.

ಬುದ್ಧಿವಂತಿಕೆಯಿಂದ ರಿವ್ಯೂ ಮಾಡುವ ಮೊದಲು ಯಾಂತ್ರಿಕವಾಗಿ ಗೇಟ್ ಮಾಡಿ. ಫೈಲ್ ಇದೆ → ಸೈಸ್ ಸರಿಯಾಗಿದೆ → ಎಂಟ್ರೋಪಿ/ಲಿಂಟ್/ಟೆಸ್ಟ್‌ಗಳು ಪಾಸ್ ಆಗುತ್ತವೆ → ನಂತರ ತೀರ್ಮಾನಕ್ಕಾಗಿ orchestrator ಟೋಕನ್‌ಗಳನ್ನು ಖರ್ಚು ಮಾಡಿ. ಗೇಟ್ ತಡೆಯುವ ಪ್ರತಿಯೊಂದು ವೈಫಲ್ಯವೂ ನೀವು ಹಣ ಪಾವತಿಸದ ಮಾಡೆಲ್-ರಿವ್ಯೂ ಆಗಿದೆ.

ತ್ವರಿತವಾಗಿ ವಿಫಲವಾಗಿ (Fail fast), ಒಮ್ಮೆ ಎಸ್ಕಲೇಟ್ ಮಾಡಿ. ಡೆಲಿಗೇಶನ್ ತಪ್ಪಾಗಿ ಹಿಂತಿರುಗಿದರೆ, orchestrator ಗೆ ಸಿಗುತ್ತದೆ ಒಂದು ಖಚಿತವಾದ ನಿಯಂತ್ರಣದೊಂದಿಗೆ ತಿದ್ದುಪಡಿ ಮರುಪ್ರಯತ್ನ ("ಹಿಂದಿನ ಪ್ರಯತ್ನವು ಟ್ಯಾಬ್ಲೆಟ್ ಅನ್ನು ಕ್ರಾಪ್ ಮಾಡಿದೆ — ಇಡೀ ಟ್ಯಾಬ್ಲೆಟ್ ಕಾಣಿಸಬೇಕು"). ಮರುಪ್ರಯತ್ನವೂ ವಿಫಲವಾದರೆ, ಆ ಕಾರ್ಯವನ್ನು ನಿಯೋಜಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ; orchestrator ಅದನ್ನು ನೇರವಾಗಿ ಮಾಡುತ್ತದೆ ಅಥವಾ ಪರ್ಯಾಯ ಮಾರ್ಗವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತದೆ. ಅಂತ್ಯವಿಲ್ಲದ ಮರುಪ್ರಯತ್ನದ ಲೂಪ್‌ಗಳಿಂದಾಗಿ ಡೆಲಿಗೇಶನ್ ಯಾವುದೇ ಕೆಲಸವನ್ನು ಮಾಡಲು ಅತ್ಯಂತ ದುಬಾರಿ ಮಾರ್ಗವಾಗುತ್ತದೆ.

orchestrator ನ ಸೆಷನ್ ಅನ್ನು ಸ್ವಚ್ಛವಾಗಿರಿಸಿ. ದೀರ್ಘಕಾಲ ನಡೆಯುವ orchestrator ಸೆಷನ್‌ಗಳು ಕಾನ್ಟೆಕ್ಸ್ಟ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುತ್ತವೆ, ಮತ್ತು ಕಾನ್ಟೆಕ್ಸ್ಟ್ ಎಂದರೆ ನೀವು ಪ್ರತಿ ಟರ್ನ್‌ನಲ್ಲೂ ಪಾವತಿಸುವ ಇನ್‌ಪುಟ್-ಟೋಕನ್ ಬಾಡಿಗೆ. ಆರ್ಟಿಫ್ಯಾಕ್ಟ್‌ಗಳು ಸಂಭಾಷಣೆಯಲ್ಲಿ ಇರದೆ ಡಿಸ್ಕ್‌ನಲ್ಲಿ ಉಳಿಯುವುದರಿಂದಲೇ ಡೆಲಿಗೇಶನ್ ಉಪಯುಕ್ತವಾಗಿದೆ — ಇದನ್ನು catಫೈಲ್‌ಗಳನ್ನು ಚಾಟ್‌ಗೆ -ing ಮಾಡುವ ಮೂಲಕ "ನೋಡಲು" ಹಾಳುಮಾಡಬೇಡಿ.

ನೀವು ಕಲಿತ ನಿಯಂತ್ರಣಗಳನ್ನು ಟೆಂಪ್ಲೇಟ್‌ಗಳಲ್ಲಿ ಬರೆಯಿರಿ. ಪ್ರತಿಯೊಂದು ಮರು-ಕೆಲಸವೂ ನಿಮಗೆ ಪ್ರಾಂಪ್ಟ್ ಸಾಲನ್ನು ಕಲಿಸುತ್ತದೆ ("ವಾಟರ್‌ಮಾರ್ಕ್ ಬೇಡ," "ಸಂಪೂರ್ಣವಾಗಿ ಫ್ರೇಮ್ ಒಳಗೆ," "ಯಾವುದೇ ಹೊಸ ಡಿಪೆಂಡೆನ್ಸಿಗಳು ಬೇಡ"). ಒಂದೇ ಪಾಠಕ್ಕೆ ಎರಡು ಬಾರಿ ಹಣ ಪಾವತಿಸುವುದನ್ನು ತಡೆಯಲು ಟೆಂಪ್ಲೇಟ್‌ಗಳು ಸಹಾಯ ಮಾಡುತ್ತವೆ.

ಇದರ ಒಂದು ವಾರದ ಅನುಭವ ನಿಜವಾಗಿ ಹೇಗಿರುತ್ತದೆ

ಗುಣಾತ್ಮಕವಾಗಿ, ನೈಜ ಪ್ರಾಜೆಕ್ಟ್ ವಾರದಲ್ಲಿ ಈ ಪ್ಯಾಟರ್ನ್ ಚಾಲನೆ ಮಾಡಿದ ನಂತರ: orchestrator ನ ಕಾನ್ಟೆಕ್ಸ್ಟ್ ಚಿಕ್ಕದಾಗಿ ಉಳಿಯಿತು ಮತ್ತು ಅದರ ಟರ್ನ್‌ಗಳು ವೇಗವಾಗಿದ್ದವು, ಏಕೆಂದರೆ ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದ ಔಟ್‌ಪುಟ್ ಎಂದಿಗೂ ಸಂಭಾಷಣೆಯನ್ನು ಪ್ರವೇಶಿಸಲಿಲ್ಲ. ಗೋಚರಿಸುವ ಟೋಕನ್ ವೆಚ್ಚವು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ಪೆಕ್ಸ್, ರಿಪೋರ್ಟ್‌ಗಳು ಮತ್ತು ರಿವ್ಯೂಗೆ ಸ್ಥಳಾಂತರಗೊಂಡಿತು — ಇದನ್ನು ನೀವು ಎಲ್ಲಿ ಬಯಸುತ್ತೀರೋ ಅಲ್ಲೇ ಪ್ರೀಮಿಯಂ ಮಾಡೆಲ್ ತನ್ನ ಗಮನವನ್ನು ವಿನಿಯೋಗಿಸುತ್ತದೆ. ಸಬ್-ಏಜೆಂಟ್‌ಗಳು ತಮ್ಮ ಕೋಟಾಗಳನ್ನು ಪ್ರಮಾಣಕ್ಕಾಗಿ ಬಳಸಿದವು. ಮತ್ತು ವೈಫಲ್ಯಗಳು ನೈಜವಾಗಿದ್ದರೂ ನಿಯಂತ್ರಿಸಬಹುದಾಗಿದ್ದವು: ಕ್ರಿಯೇಟಿವ್ ಜನರೇಷನ್‌ಗಳ ಕಾಲು ಭಾಗದಲ್ಲಿ ಫಿಕ್ಸ್ ಸೈಕಲ್, ನಿಖರ ಸ್ಪೆಕ್ ಹೊಂದಿದ್ದ ಕೋಡ್ ಟಾಸ್ಕ್‌ಗಳಲ್ಲಿ ಶೂನ್ಯಕ್ಕೆ ಹತ್ತಿರವಾದ ರಿವರ್ಕ್, ಮತ್ತು ಸ್ಪೆಕ್ ಡ್ರಾಫ್ಟ್ ಆರ್ಕಿಟೆಕ್ಚರ್ ಡಾಕ್ಯುಮೆಂಟ್ ಆಗಿ ಬದಲಾಗಲು ಪ್ರಾರಂಭಿಸಿದ ನಂತರ ನಾನು orchestrator ನಲ್ಲೇ ಸರಿಯಾಗಿ ಉಳಿಸಿಕೊಂಡ ಒಂದು ಟಾಸ್ಕ್ (ಕ್ರಾಸ್-ಕಟಿಂಗ್ ರಿಫ್ಯಾಕ್ಟರ್).

ಈ ಪ್ಯಾಟರ್ನ್ ದುಬಾರಿ ಮಾಡೆಲ್ ಅನ್ನು ಅಗ್ಗವಾಗಿಸಲಿಲ್ಲ. ಆದರೆ ಅದನ್ನು ಬೆರಳಚ್ಚುಗಾರನಾಗಿ ಬಳಸುವುದನ್ನು ನಿಲ್ಲಿಸುವಂತೆ ಮಾಡಿತು.

ಅಂತಿಮ ತೀರ್ಪು, ಮತ್ತು ಪರಿಶೀಲನಾಪಟ್ಟಿ

ತಂತ್ರ ಸರಿಯಾಗಿದೆಯೇ? ಹೆಚ್ಚಾಗಿ, ಹೌದು. ಜನರೇಷನ್-ಹೆಚ್ಚಿರುವ ಕೆಲಸಕ್ಕೆ ಉಳಿತಾಯವು ನೈಜವಾಗಿದೆ ಮತ್ತು ದೊಡ್ಡದಾಗಿದೆ — ಇದು ಯಾವುದರ ಡೆಲಿಗೇಶನ್ ಎಂದರೆ ಔಟ್‌ಪುಟ್‌ನ, ಮತ್ತು ಔಟ್‌ಪುಟ್‌ಗಾಗಿಯೇ ನೀವು ಹಣ ಪಾವತಿಸುತ್ತೀರಿ. ತೀರ್ಮಾನ-ಹೆಚ್ಚಿರುವ ಕೆಲಸಕ್ಕೆ ಉಳಿತಾಯವು ಕೇವಲ ಭ್ರಮೆ — ಇದು ಯಾವುದರ ಡೆಲಿಗೇಶನ್ ಎಂದರೆ ಗ್ರಹಿಕೆಯ, ಮತ್ತು ಗ್ರಹಿಕೆಯು ಯಾವಾಗಲೂ orchestrator ನ ಬಿಲ್‌ಗೇ ಮರಳುತ್ತದೆ, ಸಾಮಾನ್ಯವಾಗಿ ಬಡ್ಡಿಯೊಂದಿಗೆ.

ದುಬಾರಿ CLI ಅನ್ನು ಅತ್ಯುತ್ತಮ ಮತ್ತು ಅಗ್ಗದ ತಂಡವನ್ನು ಹೊಂದಿರುವ ಕಟ್ಟುನಿಟ್ಟಾದ ಟೆಕ್ ಲೀಡ್ ಎಂದು ಪರಿಗಣಿಸಿ: ಇದು ಸ್ಪೆಕ್ಸ್ ಬರೆಯುತ್ತದೆ, ಸಣ್ಣ ರಿಪೋರ್ಟ್‌ಗಳನ್ನು ರಿವ್ಯೂ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಏನಾದರೂ ತಪ್ಪಾಗಿದೆ ಎಂದು ತೋರಿದಾಗ ಮಾತ್ರ ಪರಿಶೀಲಿಸುತ್ತದೆ.

ನೀವು ಒಂದು ಕಾರ್ಯವನ್ನು ನಿಯೋಜಿಸುವ ಮೊದಲು, ಚೆಕ್‌ಲಿಸ್ಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ:

• ಔಟ್‌ಪುಟ್ ದೊಡ್ಡದಾಗಿದೆಯೇ (>100 ಸಾಲುಗಳು / >2k ಟೋಕನ್‌ಗಳು) ಅಥವಾ orchestrator ಗೆ ಮಾಡಲು ಸಾಧ್ಯವೇ ಇಲ್ಲದಿರುವುದೇ?
• ನಾನು ಸ್ಪೆಕ್ ಬರೆಯಬಹುದೇ ನನ್ನ ಆರ್ಕಿಟೆಕ್ಚರ್ ಅನ್ನು ವಿವರಿಸದೆ?
• "ಪೂರ್ಣಗೊಂಡಿದೆ" ಎಂಬುದು ಮೆಷಿನ್‌ನಿಂದ ಪರಿಶೀಲಿಸಬಹುದಾದದ್ದೇ (ಟೆಸ್ಟ್‌ಗಳು, ಲಿಂಟ್, ಫೈಲ್ ಗುಣಲಕ್ಷಣಗಳು) "ಎಲ್ಲವನ್ನೂ ಎಚ್ಚರಿಕೆಯಿಂದ ಓದಿ" ಎಂಬುದರ ಬದಲಾಗಿ?
• ಔಟ್‌ಪುಟ್ ಪಾಥ್ ಖಚಿತವಾಗಿದೆಯೇ, ಮತ್ತು ಪ್ರತ್ಯುತ್ತರವು ಯಾವುದಕ್ಕೆ ಸೀಮಿತವಾಗಿದೆಯೇ DONE + ≤40-ಸಾಲುಗಳ ರಿಪೋರ್ಟ್‌ಗೆ?
• ನಾನು ಬಜೆಟ್ ಮೀಸಲಿಟ್ಟಿದ್ದೇನೆಯೇ ಒಂದು ಫಿಕ್ಸ್ ಸೈಕಲ್ — ಮತ್ತು ಅದು ಎರಡು ಬಾರಿ ವಿಫಲವಾದರೆ ಏನಾಗುತ್ತದೆ ಎಂದು ನಿರ್ಧರಿಸಿದ್ದೇನೆಯೇ?

ಐದು 'ಹೌದು'ಗಳು ಇದ್ದರೆ: ಅದನ್ನು ಡೆಲಿಗೇಟ್ ಮಾಡಿ, ಬ್ಯಾಕ್‌ಗ್ರೌಂಡ್‌ನಲ್ಲಿಡಿ, ಗೇಟ್ ಮಾಡಿ ಮತ್ತು ಲೆಕ್ಕಾಚಾರವನ್ನು ಆನಂದಿಸಿ. ಯಾವುದಾದರೂ 'ಇಲ್ಲ' ಇದ್ದರೆ: ಪ್ರೀಮಿಯಂ ಮಾಡೆಲ್ ಅದನ್ನು ನೇರವಾಗಿ ಮಾಡುತ್ತದೆ — ಏಕೆಂದರೆ ನೀವು ಖರ್ಚು ಮಾಡುವ ಅತ್ಯಂತ ದುಬಾರಿ ಟೋಕನ್‌ಗಳೆಂದರೆ ಎರಡು ಬಾರಿ ಖರ್ಚು ಮಾಡಿದವು.