ಹೆಚ್ಚಿನ ಅಭಿವರ್ಧಕರು (developers) AI ಕೋಡಿಂಗ್ ಏಜೆಂಟ್‌ಗಳನ್ನು ತಪ್ಪಾದ ರೀತಿಯಲ್ಲಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತಾರೆ. ಅವರು ಮೂರು ಪರಿಕರಗಳನ್ನು (tools) ಇನ್‌ಸ್ಟಾಲ್ ಮಾಡುತ್ತಾರೆ, ಟರ್ಮಿನಲ್ ತೆರೆಯುತ್ತಾರೆ ಮತ್ತು ಒಂದೇ ರೀತಿಯ ಸಣ್ಣ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತಾರೆ: build me a landing page. ನಂತರ ಯಾವ ಔಟ್‌ಪುಟ್ ನೋಡಲು ಸುಂದರವಾಗಿ ಕಾಣುತ್ತದೆಯೋ ಅದನ್ನು ಅವರು ಆರಿಸಿಕೊಳ್ಳುತ್ತಾರೆ. ಈ ಪರೀಕ್ಷೆಯು ಈប្រಕಾರದ ವ್ಯವಸ್ಥೆಗಳು ನೈಜ ಕೋಡ್‌ಬೇಸ್‌ನಲ್ಲಿ (codebase) ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಎಂಬುದರ ಬಗ್ಗೆ ನಿಮಗೆ ಏನನ್ನೂ ತಿಳಿಸುವುದಿಲ್ಲ.

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

ನೀವು ಕೇವಲ ಪ್ರಾಥಮಿಕ ಡೆಮೋಗಳಿಂದ ಮುಂದೆ ಹೋಗಿ ಇಂಜಿನಿಯರಿಂಗ್ ಕೆಲಸಕ್ಕೆ ಕಾಲಿಟ್ಟಾಗ, ಪ್ರಮುಖ ಪರಿಕರಗಳನ್ನು ನಿಜವಾಗಿಯೂ ಪ್ರತ್ಯೇಕಿಸುವುದು ಇವೇ.

ಹಾರ್ನೆಸ್ (Harness) ಎಂಬುದು ಉತ್ಪನ್ನವಾಗಿದೆ

ಏಜೆಂಟ್ ಹಾರ್ನೆಸ್ ಒಂದು ರೆಪೊಸಿಟರಿ (repository) ಒಳಗೆ ಬುದ್ಧಿವಂತಿಕೆ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. ಏಜೆಂಟ್ ಎಷ್ಟು ಕಾನ್ಟೆಕ್ಸ್ ಅನ್ನು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಬೇಕು, ಯಾವ ಫೈಲ್‌ಗಳನ್ನು ಬಳಸಬಹುದು, ವಿಫಲವಾದ ಟರ್ಮಿನಲ್ ಕಮಾಂಡ್‌ನಿಂದ ಅದು ಹೇಗೆ ಚೇತರಿಸಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ .env ಫೈಲ್ ಅನ್ನು ಡಿಲೀಟ್ ಮಾಡುವ ಮೊದಲು ನಿಲ್ಲಬೇಕೆಂಬುದನ್ನು ಇದು ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಒಂದೇ ರೀತಿಯ ಬೆಂಚ್‌ಮಾರ್ಕ್ ಸ್ಕೋರ್ ಹೊಂದಿರುವ ಮಾಡೆಲ್‌ಗಳ ಮೇಲೆ ಎರಡು ಏಜೆಂಟ್‌ಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸಬಹುದು, ಆದರೆ ಒಂದು ಏಜೆಂಟ್ ಮೂರು ಫೈಲ್ ಎಡಿಟ್‌ಗಳ ನಂತರ ಮಾಡ್ಯೂಲ್‌ಗಳ ನಡುವಿನ ಸಂಬಂಧವನ್ನು ಕಳೆದುಕೊಂಡರೆ ಮತ್ತು ಇನ್ನೊಂದು ನಿಮ್ಮ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನ ಸ್ಪಷ್ಟ ನಕ್ಷೆಯನ್ನು ಕಾಪಾಡಿಕೊಂಡರೆ, ಎರಡನೇ ಏಜೆಂಟ್ ರಿಫ್ಯಾಕ್ಟರ್ (refactor) ಅನ್ನು ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಮೊದಲನೆಯದು ರಿಗ್ರೆಷನ್‌ಗಳನ್ನು (regressions) ಉಂಟುಮಾಡುತ್ತದೆ.

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

Claude Code: ಆಳವಾದ ರೆಪೊಸಿಟರಿ ರೀಸನಿಂಗ್ (Deep Repository Reasoning)

ಕೇವಲ ಕೋಡ್ ಅನ್ನು ಸೇರಿಸುವ ಬದಲು, ಒಂದು ಸಂಕೀರ್ಣ ಕೋಡ್‌ಬೇಸ್ ಅನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕಾದಾಗ Claude Code ಅತ್ಯುತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಮಾಡ್ಯೂಲ್‌ಗಳ ನಡುವಿನ ಸಂಬಂಧಗಳ ಮಾನಸಿಕ ಮಾದರಿಯನ್ನು (mental model) ಕಾಪಾಡಿಕೊಳ್ಳುವುದು ಇದರ ಶಕ್ತಿಯಾಗಿದೆ. ನೀವು ಅಥೆಂಟಿಕೇಶನ್ ಮಿಡ್ಲ್‌ವೇರ್‌ನಲ್ಲಿ (authentication middleware) ಪ್ರಾರಂಭವಾಗಿ, ಡೇಟಾಬೇಸ್ ವ್ಯಾಪರ್ ಮೂಲಕ ಹರಡಿ, ವ್ಯಾಲಿಡೇಶನ್ ಯುಟಿಲಿಟಿಯಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುವ ಬಗ್ ಅನ್ನು ಪತ್ತೆಹಚ್ಚುತ್ತಿದ್ದರೆ, Claude Code ಆ ಸಂಪರ್ಕವನ್ನು ಕಾಯ್ದುಕೊಳ್ಳುತ್ತದೆ. ಇದು ದೊಡ್ಡ ಮಟ್ಟದ ರಿಫ್ಯಾಕ್ಟರ್‌ಗಳನ್ನು ಯೋಜಿಸಲು ವಿಶೇಷವಾಗಿ ಉಪಯುಕ್ತವಾಗಿದೆ; ಉದಾಹರಣೆಗೆ, ಒಂದು ಇಂಟರ್ನಲ್ API ಅನ್ನು ಮರುನಾಮಕರಣ ಮಾಡುವುದು, ಪ್ರತಿಯೊಬ್ಬ ಕನ್ಸ್ಯೂಮರ್ ಅನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡುವುದು ಮತ್ತು ಮರೆತುಹೋದ ಯುಟಿಲಿಟಿ ಫೋಲ್ಡರ್‌ನಲ್ಲಿರುವ ಇಂಪೋರ್ಟ್ ಅನ್ನು ಮರೆಯದೆ ಟೆಸ್ಟ್‌ಗಳನ್ನು ಹೊಂದಿಸುವುದು ಇತ್ಯಾದಿ.

ಇದರಿಂದ ಗರಿಷ್ಠ ಪ್ರಯೋಜನ ಪಡೆಯಲು ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ ರೂಟ್‌ನಲ್ಲಿ CLAUDE.md ಫೈಲ್ ಅನ್ನು ಬಳಸುವುದು ಒಂದು ಪ್ರಾಯೋಗಿಕ ಮಾರ್ಗವಾಗಿದೆ. ಈ ದಾಖಲೆಯು ನೀವು ಕೋಡಿಫೈ ಮಾಡಬಹುದಾದ ಸಾಂಸ್ಥಿಕ ನೆನಪಿನಂತೆ (institutional memory) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಎಲ್ಲಾ ಲಾಗಿಂಗ್‌ಗಳು console.log ಬದಲಿಗೆ ಇಂಟರ್ನಲ್ ವ್ಯಾಪರ್ ಅನ್ನು ಬಳಸಬೇಕು, ಡೇಟಾಬೇಸ್ ಮೈಗ್ರೇಷನ್‌ಗಳು ಕೇವಲ /infra/migrations ನಲ್ಲಿ ಇರಬೇಕು ಅಥವಾ ಪ್ರತಿಯೊಂದು ಹೊಸ React ಕಂಪೊನೆಂಟ್‌ಗೆ ಅದಕ್ಕೆ ಅನುಗುಣವಾದ Storybook ಫೈಲ್ ಬೇಕು ಎಂದು ನೀವು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು. ಈ ಗಾರ್ಡ್‌ರೈಲ್ ಇಲ್ಲದಿದ್ದರೆ, ಯಾವುದೇ ಏಜೆಂಟ್ ತನ್ನ ತರಬೇತಿಯ ಡಿಫಾಲ್ಟ್‌ಗಳ ಕಡೆಗೆ ವಾಲಿಬರುತ್ತದೆ. ಇದರೊಂದಿಗೆ, Claude Code ನಿಮ್ಮ ತಂಡವು ಸ್ಥಾಪಿಸಲು ತಿಂಗಳುಗಟ್ಟಲೆ ತೆಗೆದುಕೊಂಡ ಸಂಪ್ರದಾಯಗಳನ್ನು (conventions) ಗೌರವಿಸಬಲ್ಲದು.

ನಿಮ್ಮ ಕೆಲಸವು ಅನ್ವೇಷಣಾತ್ಮಕ ಮತ್ತು ಆರ್ಕಿಟೆಕ್ಚರಲ್ ಆಗಿದ್ದಾಗ ಈ ಪರಿಕರವನ್ನು ಆರಿಸಿ. ನೀವು ಕಷ್ಟಕರವಾದ ಲಾಜಿಕ್ ಅನ್ನು ಡಿಬಗ್ ಮಾಡುತ್ತಿದ್ದರೆ ಅಥವಾ ಮೊನೊರೆಪೊ (monorepo) ಪ್ಯಾಕೇಜ್‌ಗಳು ಒಂದಕ್ಕೊಂದು ಅವಲಂಬಿತವಾಗಿರುವ ರೀತಿಯನ್ನು ಮರುಸಂಘಟಿಸುತ್ತಿದ್ದರೆ, ಕಾನ್ಟೆಕ್ಸ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್‌ನ ಆಳವು ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಯೋಜನಕಾರಿಯಾಗುತ್ತದೆ.

OpenAI Codex: ರಚನಾತ್ಮಕ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವಿಕೆ (Structured Automation)

Codex ಅನ್ನು ದೊಡ್ಡ ಮಟ್ಟದಲ್ಲಿ ಪುನರಾವರ್ತಿತ ಫಲಿತಾಂಶಗಳನ್ನು ಬಯಸುವ ತಂಡಗಳಿಗಾಗಿ ನಿರ್ಮಿಸಲಾಗಿದೆ. Claude Code ಅನ್ವೇಷಣೆಯ ಕಡೆಗೆ ಒಲವು ಹೊಂದಿದ್ದರೆ, Codex ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವಿಕೆಯ (automation) ಕಡೆಗೆ ಒಲವು ಹೊಂದಿದೆ. ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ತಂಡದ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಸ್ಪಷ್ಟವಾಗಿ ವ್ಯಾಖ್ಯಾನಿಸಲಾದ ಕಾರ್ಯಗಳು ಇದ್ದಾಗ ಇದು ಅತ್ಯುತ್ತಮವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಹೊಸ ಮೈಕ್ರೋಸರ್ವಿಸ್‌ಗಾಗಿ ಬಾಯ್ಲರ್‌ಪ್ಲೇಟ್ (boilerplate) ತಯಾರಿಸುವುದು, ನಿಮ್ಮ ನಿರ್ದಿಷ್ಟ ಮಿಡ್ಲ್‌ವೇರ್ ಸ್ಟ್ಯಾಕ್‌ನೊಂದಿಗೆ CRUD ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗಳನ್ನು ಸ್ಕ್ಯಾಫೋಲ್ಡಿಂಗ್ ಮಾಡುವುದು ಅಥವಾ ಸೇವೆಗಳ ಸಮೂಹದಾದ್ಯಂತ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡುವುದು ಇತ್ಯಾದಿ.

ಇಲ್ಲಿ ಗಮನಿಸಬೇಕಾದ ಅಂಶವೆಂದರೆ ನೀವು ನಿಖರವಾಗಿರಬೇಕು. ನಿಮ್ಮ ಸ್ವೀಕಾರದ ಮಾನದಂಡಗಳು (acceptance criteria) ಅಸ್ಪಷ್ಟವಾಗಿದ್ದರೆ, Codex ತಾಂತ್ರಿಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಆದರೆ ನಿಮ್ಮ ಸಂಪ್ರದಾಯಗಳನ್ನು ಉಲ್ಲಂಘಿಸುವ ಕೋಡ್ ಅನ್ನು ಸುಲಭವಾಗಿ ಸೃಷ್ಟಿಸುತ್ತದೆ. ರಚನೆ, ಹೆಸರಿಸುವ ನಿಯಮಗಳು, ಎರರ್ ಹ್ಯಾಂಡ್ಲಿಂಗ್ ಪ್ಯಾಟರ್ನ್ ಮತ್ತು ಟೆಸ್ಟ್ ನಿರೀಕ್ಷೆಗಳನ್ನು ಮೊದಲೇ ನಿರ್ಧರಿಸಿ. ಅಂತಹ ಪರಿಸರದಲ್ಲಿ, Codex ಪೇರ್ ಪ್ರೋಗ್ರಾಮರ್‌ನಂತೆ ವರ್ತಿಸದೆ, ನೈಸರ್ಗಿಕ ಭಾಷೆಯ ಸೂಚನೆಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಅಸೆಂಬ್ಲಿ ಲೈನ್‌ನಂತೆ ವರ್ತಿಸುತ್ತದೆ. ಇದು ಇಂಟರ್ನಲ್ ಟೂಲಿಂಗ್, CI-ಸಂಬಂಧಿತ ವರ್ಕ್‌ಫ್ಲೋಗಳು ಮತ್ತು ಸೃಜನಾತ್ಮಕ ಸಮಸ್ಯೆ ಪರಿಹಾರಕ್ಕಿಂತ ಸ್ಥಿರತೆ (consistency) ಹೆಚ್ಚು ಮುಖ್ಯವಾಗಿರುವ ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ಇದನ್ನು ಶಕ್ತಿಯುತವಾಗಿಸುತ್ತದೆ.

Gemini CLI: ಮುಕ್ತ, ಸ್ಕ್ರಿಪ್ಟಬಲ್ ವರ್ಕ್‌ಫ್ಲೋಗಳು (Open, Scriptable Workflows)

Gemini CLI ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ರೂಪವನ್ನು ಹೊಂದಿದೆ. ಇದು ಕೇವಲ ಸಂಭಾಷಣಾತ್ಮಕ ಕೋಡಿಂಗ್ ಅಸಿಸ್ಟೆಂಟ್ ಆಗಿರುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ, ನಿಮ್ಮ ಟರ್ಮಿನಲ್ ಪರಿಸರದಲ್ಲಿನ ವಿಸ್ತರಿಸಬಹುದಾದ (extensible) ಘಟಕವಾಗಿದೆ. ಇದು ಹೆಚ್ಚು ಸ್ಕ್ರಿಪ್ಟಬಲ್ ಆಗಿದೆ, ಅಂದರೆ ನೀವು ಇದನ್ನು ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಯುನಿಕ್ಸ್ (Unix) ವರ್ಕ್‌ಫ್ಲೋಗಳಿಗೆ ಪೈಪ್ ಮಾಡಬಹುದು, grep, awk, ಅಥವಾ jq ನೊಂದಿಗೆ ಜೋಡಿಸಬಹುದು ಮತ್ತು ಚಾಟ್ ವಿಂಡೋಗಳ ನಡುವೆ ಕಾಪಿ ಮತ್ತು ಪೇಸ್ಟ್ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲದ ಕಸ್ಟಮ್ ಟೂಲ್‌ಚೈನ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಬಹುದು.

ಟರ್ಮಿನಲ್ ಅನ್ನು ತಮ್ಮ ಪ್ರಾಥಮಿಕ ಇಂಟರ್ಫೇಸ್ ಎಂದು ಪರಿಗಣಿಸುವ ಎಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಈ ಮುಕ್ತತೆ ಬಹಳ ಮುಖ್ಯವಾಗಿದೆ. ನೀವು ಇದನ್ನು ಸ್ಟೇಜ್ಡ್ ಡಿಫ್‌ಗಳಿಂದ (staged diffs) ಕಮಿಟ್ ಸಂದೇಶಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ರಚಿಸಲು, ಹಳೆಯ ಶೆಲ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳನ್ನು ವಿವರಣೆಗಳೊಂದಿಗೆ Python ಗೆ ಮರುಬರೆಯಲು ಅಥವಾ ವಿಫಲವಾದ Kubernetes ಪಾಡ್‌ನಿಂದ ಲಾಗ್ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಸಾರಾಂಶಗೊಳಿಸಲು ಬಳಸಬಹುದು. ಇದರ ನಾನ್-ಇಂಟರಾಕ್ಟಿವ್ ಮೋಡ್ CI ಪೈಪ್‌ಲೈನ್‌ಗಳಿಗೆ ವಿಶೇಷವಾಗಿ ಉಪಯುಕ್ತವಾಗಿದೆ. ನೀವು ಲಘುವಾದ ಕೋಡ್ ರೂಪಾಂತರಗಳನ್ನು ಮಾಡಲು, ಸೋರ್ಸ್‌ನಿಂದ ಡಾಕ್ಯುಮೆಂಟೇಶನ್ ಸ್ನಿಪ್ಪೆಟ್‌ಗಳನ್ನು ರಚಿಸಲು ಅಥವಾ Slack ಚಾನಲ್‌ಗೆ ಪೋಸ್ಟ್ ಮಾಡುವ ಮೊದಲು ಎರರ್ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಸ್ಯಾನಿಟೈಸ್ ಮಾಡಲು ಇದನ್ನು GitHub Action ಅಥವಾ Makefile ಹಂತದಲ್ಲಿ ಅಳವಡಿಸಬಹುದು.

ನಿಮ್ಮ ವರ್ಕ್‌ಫ್ಲೋ ಈಗಾಗಲೇ ಶೆಲ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು ಮತ್ತು ಕಂಪೋಸಬಲ್ ಟೂಲ್‌ಗಳ ಸುತ್ತ ನಿರ್ಮಿತವಾಗಿದ್ದರೆ, Gemini CLI ನಿಮ್ಮ ಅಭ್ಯಾಸಗಳನ್ನು ಬದಲಾಯಿಸಲು ಕೇಳದೆ ಸುಲಭವಾಗಿ ಹೊಂದಿಕೊಳ್ಳುತ್ತದೆ.

ನಿಜವಾಗಿಯೂ ಮುಖ್ಯವಾದ ಕೆಲಸ

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

ಇದರರ್ಥ ನಿಮ್ಮ ಮೌಲ್ಯಮಾಪನವು ನೀವು ಮಾಡುವ ನಿಜವಾದ ಕೆಲಸಕ್ಕೆ ಅನುಗುಣವಾಗಿರಬೇಕು. ನೀವು ಕೇವಲ ಸೀಮಿತ ಕಾರ್ಯಗಳ ಮೇಲೆ ಮಾತ್ರ ಪರೀಕ್ಷಿಸಿದರೆ, ಪ್ರತಿಯೊಂದು ಸಾಧನವೂ ಅದ್ಭುತವಾಗಿ ಕಾಣಿಸುತ್ತದೆ.

ಏಜೆಂಟ್‌ಗಳು ನಿಜವಾಗವಾಗಿ ಎಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ

ಹೆಚ್ಚಿನ ವೈಫಲ್ಯಗಳು ಮಾಡೆಲ್ ಲೇಯರ್‌ನಲ್ಲಿ ಅಲ್ಲದೆ, ಎಕ್ಸಿಕ್ಯೂಷನ್ ಲೇಯರ್‌ನಲ್ಲಿ ಸಂಭವಿಸುತ್ತವೆ. ಕೋಡ್ ವ್ಯಾಕರಣಬದ್ಧವಾಗಿ (syntactically) ಪರಿಪೂರ್ಣವಾಗಿರಬಹುದು, ಆದರೆ ಇಂಟರ್ನಲ್ API ಗೆ ನೆಟ್‌ವರ್ಕ್ ಟೈಮೌಟ್ ಆಗುವುದು, macOS ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಆದರೆ GNU/Linux ನಲ್ಲಿ ವಿಫಲವಾಗುವ sed ಕಮಾಂಡ್ ಅಥವಾ ಏಜೆಂಟ್‌ಗೆ ಪರಿಚಯವಿಲ್ಲದ ಪರ್ಮಿಷನ್ ಬೌಂಡರಿ ಇರುವುದರಿಂದ ಏಜೆಂಟ್ ವಿಫಲವಾಗಬಹುದು. ಈ ಕೆಳಗಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಏಜೆಂಟ್‌ಗಳು ಕಷ್ಟಪಡುತ್ತವೆ:

  • ಒಂದು API ತಾತ್ಕಾಲಿಕ ವೈಫಲ್ಯವನ್ನು (transient failure) ನೀಡಿದಾಗ, ಏಜೆಂಟ್ ಹಿನ್ನೆಡೆ ನೀಡುವ (backing off) ಬದಲು ಲೂಪ್‌ನಲ್ಲಿ ಸುತ್ತುತ್ತಾ ಇರುವುದು.
  • ಒಂದು ಟೂಲ್ ಏಜೆಂಟ್ ತಪ್ಪಾಗಿ ಅರ್ಥೈಸಿಕೊಳ್ಳುವ ರೀತಿಯಲ್ಲಿ ಫಾರ್ಮ್ಯಾಟ್ ಮಾಡಲಾದ ಎರರ್ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ನೀಡಿದಾಗ.
  • ಒಂದು ಕಮಾಂಡ್‌ಗೆ ಏಜೆಂಟ್‌ಗೆ ಇಲ್ಲದ sudo ಪ್ರವೇಶದ ಅಗತ್ಯವಿದ್ದಾಗ, ಇದು ಸೈಲೆಂಟ್ ಹ್ಯಾಂಗ್‌ಗೆ ಕಾರಣವಾಗಬಹುದು.
  • ಜನರೇಟ್ ಮಾಡಿದ ಟೆಸ್ಟ್‌ಗಳು ಪ್ರತ್ಯೇಕವಾಗಿ ಪಾಸಾಗಬಹುದು ಆದರೆ ರಿಯಲ್ ಡೇಟಾಬೇಸ್ ಜೊತೆಗೆ ರನ್ ಮಾಡಿದಾಗ ಫೇಲ್ ಆಗಬಹುದು, ಏಕೆಂದರೆ ಹಾರ್ನೆಸ್ ಕನೆಕ್ಷನ್ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಸರಿಯಾಗಿ ತೋರಿಸಿಲ್ಲದಿರಬಹುದು.

ಇವು ಇಂಟಿಗ್ರೇಷನ್ ಸಮಸ್ಯೆಗಳು. ಇವುಗಳಿಗೆ ಎರರ್‌ಗಳನ್ನು ಹೇಗೆ ಓದಬೇಕು, ಮಿತಿಗಳನ್ನು ಹೇಗೆ ಗೌರವಿಸಬೇಕು ಮತ್ತು ತಪ್ಪು ಮಾಡುತ್ತಾ ಮುಂದೆ ಹೋಗುವ ಬದಲು ಮಾನವ ಹಸ್ತಕ್ಷೇಪವನ್ನು ಹೇಗೆ ಕೇಳಬೇಕು ಎಂದು ತಿಳಿದಿರುವ ಹಾರ್ನೆಸ್ ಅಗತ್ಯವಿದೆ.

ಈ ಸಾಧನಗಳನ್ನು ನಿಜವಾಗಿಯೂ ಹೇಗೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡುವುದು

build a landing page ನಂತಹ ಪ್ರಾಂಪ್ಟ್‌ಗಳೊಂದಿಗೆ ಏಜೆಂಟ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ. ಅದು ದೃಶ್ಯ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಅಳೆಯುತ್ತದೆಯೇ ಹೊರತು ಎಂಜಿನಿಯರಿಂಗ್ ಸಾಮರ್ಥ್ಯವನ್ನಲ್ಲ. ಬದಲಾಗಿ, ಪ್ರತಿಯೊಂದು ಸಾಧನವನ್ನು ಈ ಕೆಳಗಿನ ನೈಜ ಕಾರ್ಯಗಳ ಪರೀಕ್ಷೆಗೆ ಒಳಪಡಿಸಿ:

  • ಮಲ್ಟಿಪಲ್ ಫೈಲ್‌ಗಳಿಗೆ ಹರಡಿರುವ ಬಗ್ ಅನ್ನು ಸರಿಪಡಿಸಿ, ಅಲ್ಲಿ ಮೂಲ ಕಾರಣ ಮತ್ತು ಲಕ್ಷಣಗಳು ಸ್ಟ್ಯಾಕ್‌ನ ವಿಭಿನ್ನ ಲೇಯರ್‌ಗಳಲ್ಲಿ ಇರುತ್ತವೆ.
  • ಬಾಹ್ಯ ವರ್ತನೆಯನ್ನು ಬದಲಾಯಿಸದೆ, ಡಿಪ್ರಿಕೇಟೆಡ್ ಡಿಪೆಂಡೆನ್ಸಿಯನ್ನು (deprecated dependency) ತೆಗೆದುಹಾಕಲು ಒಂದು ಮಾಡ್ಯೂಲ್ ಅನ್ನು ರಿಫ್ಯಾಕ್ಟರ್ ಮಾಡಿ, ನಂತರ ಟೆಸ್ಟ್ ಸೂಟ್ ಇನ್ನೂ ಪಾಸಾಗುತ್ತಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ.
  • ಥರ್ಡ್-ಪಾರ್ಟಿ API ತನ್ನ ರೆಸ್ಪಾನ್ಸ್ ಶೇಪ್ ಅನ್ನು ಬದಲಾಯಿಸಿದ ನಂತರ ಪ್ರತಿಯೊಂದು ಮಾಕ್ ಫಿಕ್ಚರ್ (mock fixture), ಟೈಪ್ ಡೆಫಿನಿಷನ್ ಮತ್ತು ಇಂಟಿಗ್ರೇಷನ್ ಟೆಸ್ಟ್ ಅನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡಿ.
  • ವರ್ಷನ್ ಕಾನ್flಿಕ್ಟ್‌ನಿಂದ ಉಂಟಾದ ಬ್ರೋಕನ್ ಬಿಲ್ಡ್ ಅನ್ನು ಡಯಾಗ್ನೋಸ್ ಮಾಡಿ ಮತ್ತು ನಿಜವಾಗಿಯೂ ಕಂಪಿಲ್ ಆಗುವ ಫಿಕ್ಸ್ ಅನ್ನು ಪ್ರಸ್ತಾಪಿಸಿ.

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

ನಿಜವಾದ ಸಾರಾಂಶ

ಗೆಲ್ಲುವ ಸಾಧನವು ಅತಿ ಹೆಚ್ಚು ಅಕ್ಷರಗಳನ್ನು ಅಥವಾ ಅತ್ಯಂತ ಆಕರ್ಷಕ ಡೆಮೋವನ್ನು ನೀಡುವ ಸಾಧನವಲ್ಲ. ಅದು ಕನಿಷ್ಠ ರಿವ್ಯೂ ಘರ್ಷಣೆಯೊಂದಿಗೆ (review friction) ಅತಿ ಹೆಚ್ಚು ಮರ್ಜ್ ಮಾಡಬಹುದಾದ ಕೋಡ್ ಅನ್ನು ನೀಡುವ ಸಾಧನವಾಗಿದೆ. ಈ ಕ್ಷೇತ್ರದಲ್ಲಿನ ಸ್ಪರ್ಧೆಯು ಕೇವಲ ಮಾಡೆಲ್ ಇಂಟೆಲಿಜೆನ್ಸ್‌ನಿಂದ ವಿಶ್ವಾಸಾರ್ಹ ಎಂಜಿನಿಯರಿಂಗ್ ಹಾರ್ನೆಸ್‌ಗಳ ಕಡೆಗೆ ಬದಲಾಗುತ್ತಿದೆ. ನಿಮ್ಮ ನಿಜವಾದ ಕೆಲಸದ ಸ್ವರೂಪಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವ ಸಿಸ್ಟಮ್ ಡಿಸೈನ್ ಹೊಂದಿರುವ ಏಜೆಂಟ್ ಅನ್ನು ಆರಿಸಿ: ಆರ್ಕಿಟೆಕ್ಚರಲ್ ಸರ್ಜರಿಗಾಗಿ ಆಳವಾದ ತರ್ಕ (deep reasoning), ತಂಡದ ಆಟೊಮೇಷನ್‌ಗಾಗಿ ರಚನಾತ್ಮಕ ನಿಖರತೆ (structured precision), ಅಥವಾ ಕಸ್ಟಮ್ ವರ್ಕ್‌ಫ್ಲೋಗಳಿಗಾಗಿ ಟರ್ಮಿನಲ್ ಎಕ್ಸ್‌ಟೆನ್ಸಿಬಿಲಿಟಿ (terminal extensibility). ನಂತರ ಅದನ್ನು ಸಣ್ಣ ಸಮಸ್ಯೆಗಳ ಮೇಲೆ ಅಲ್ಲದೆ, ನೈಜ ವೈಫಲ್ಯಗಳ ಮೇಲೆ ಪರೀಕ್ಷಿಸಿ.

ಈ ವಿಶ್ಲೇಷಣೆಯು ಈ ವಿವರವಾದ ವಿಭಜನೆಯಲ್ಲಿ ವಿವರಿಸಲಾದ ನೇರ ಹೋಲಿಕೆಗಳು ಮತ್ತು ಏಜೆಂಟ್ ವರ್ತನೆಯ ಸಂಶೋಧನೆಯನ್ನು ಆಧರಿಸಿದೆ.

ಎಂಜಿನಿಯರಿಂಗ್ ಟೂಲ್ಸ್ ಮತ್ತು AI ವರ್ಕ್‌ಫ್ಲೋಗಳ ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ಚರ್ಚೆಗಳಿಗಾಗಿ, GyaanSetu ಕಲಿಕಾ ಸಮುದಾಯವನ್ನು ಸೇರಿ.