ನನ್ನ ಏಜೆಂಟ್ ಒಂದು ಸಂಜೆಯಲ್ಲೇ 3 PRಗಳನ್ನು ಕಳುಹಿಸಿತು. ನನ್ನ ಸಂದೇಶಗಳಲ್ಲಿ 40% ತಿದ್ದುಪಡಿಗಳಾಗಿದ್ದವು.
ನನ್ನ AI-ಚಾಲಿತ ಕೋಡಿಂಗ್ ಏಜೆಂಟ್ ಒಂದೇ ಸಂಜೆಯಲ್ಲಿ ಮೂರು pull requestsಗಳನ್ನು ಕಳುಹಿಸಿತು, ಆದರೆ ನಾನು ಕಳುಹಿಸಿದ 30 ಸಂದೇಶಗಳಲ್ಲಿ 40% ತಿದ್ದುಪಡಿಗಳಾಗಿದ್ದವು.
ಈ ಸೆಷನ್ನಲ್ಲಿ ಒಂದು MCP client, ಒಂದು Azure AI Agent ಮತ್ತು ಒಂದು M365 Copilot Agent ಸಿದ್ಧವಾಯಿತು. ಸ್ವಯಂಚಾಲಿತ ಪರಿசோதனೆಗಳು (Automated checks) ಮೂರೂ PRಗಳನ್ನು ಅಂಗೀಕರಿಸಿದವು ಮತ್ತು ನಾನು ಒಂದು ಸಾಲು ಕೋಡ್ ಅನ್ನು ಸಹ ಎಡಿಟ್ ಮಾಡಲಿಲ್ಲ. ಆದರೂ, ಸಂಭಾಷಣೆಯ ದಾಖಲೆ (transcript) ವಿಭಿನ್ನ ಕಥೆಯನ್ನು ಹೇಳುತ್ತದೆ: ಒಟ್ಟು 710 ಸಂದೇಶಗಳಲ್ಲಿ, ನಾನು 30 ಸಂದೇಶಗಳನ್ನು ಟೈಪ್ ಮಾಡಿದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ 12 ಸಂದೇಶಗಳು ಏಜೆಂಟ್ ಅನ್ನು ಸರಿಯಾದ ಹಾದಿಗೆ ತರಲು ಸಹಾಯ ಮಾಡಿದವು. "steering rate" – ಅಂದರೆ ತಿದ್ದುಪಡಿಗಳಾಗಿದ್ದ ನನ್ನ ಸಂದೇಶಗಳ ಪ್ರಮಾಣ – 40% ರಷ್ಟಿದೆ.
ಪೈಪ್ಲೈನ್ ಹೇಗೆ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿತ್ತು
- Claude ಒಂದು ಉನ್ನತ ಮಟ್ಟದ ಅನುಷ್ಠಾನ ಯೋಜನೆಯನ್ನು (high-level implementation plan) ಸಿದ್ಧಪಡಿಸಿತು.
- DeepSeek V4-Flash ಯೋಜನೆಯನ್ನು ಪರಿಶೀಲಿಸುವ ಮೂಲಕ ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ (orchestrator) ಆಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿತು.
- Codex ನೈಜ ಕೋಡ್ ಅನ್ನು ರಚಿಸಿತು.
- ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಕೋಡ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ pull requestsಗಳನ್ನು ತೆರೆಯಿತು.
ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ನ ಉದ್ದೇಶಿತ ಪಾತ್ರವು ಕೇವಲ ಸಂಪರ್ಕ ಕಲ್ಪಿಸುವುದಾಗಿತ್ತು – ಅದು ಘಟಕಗಳ ನಡುವಿನ ಸಂಘರ್ಷಗಳನ್ನು ಪರಿಹರಿಸಬೇಕೆ ಹೊರತು ಸ್ವತಃ ಕೋಡ್ ಬರೆಯಬಾರದು. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಏಜೆಂಟ್ ಸುಮಾರು 40 ನಿಮಿಷಗಳಲ್ಲಿ ಮೂರು PRಗಳ ಮೂಲಕ 3,500 ಸಾಲುಗಳ ಕೋಡ್ ಅನ್ನು ರಚಿಸಿತು, ಆದರೆ ಅದು ಎರಡು ಪುನರಾವರ್ತಿತ ದೋಷಗಳ (error classes) ಕಡೆಗೆ ಗಮನ ಹರಿಸದೆ ತಪ್ಪಿತು.
ಎರಡು ರೀತಿಯ ದೋಷಗಳು
- ವರ್ಕ್ಫ್ಲೋ ಉಲ್ಲಂಘನೆಗಳು (Workflow violations) – ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ತನ್ನ "glue" ಪಾತ್ರವನ್ನು ನಿರ್ಲಕ್ಷಿಸಿ, ಸಾಂದರ್ಭಿಕವಾಗಿ ಕೋಡಿಂಗ್ ಹಂತವನ್ನು ತನ್ನ ವಶಕ್ಕೆ ಪಡೆದು, ಅನುಷ್ಠಾನದ ವಿವರಗಳನ್ನು (implementation details) ತಾನೇ ಬರೆಯುತ್ತಿತ್ತು.
- ಸಂದರ್ಭ-ಮರುಪಡೆಯುವಿಕೆ ವೈಫಲ್ಯಗಳು (Context-retrieval failures) – ಸ್ಪಷ್ಟ ಸೂಚನೆಗಳಿದ್ದರೂ ಸಹ, ಏಜೆಂಟ್ ತಪ್ಪಾದ SDK ಅಥವಾ ವರ್ಷನ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿತು. ಸರಿಯಾದ ಮಾಹಿತಿ ಪ್ರಾಂಪ್ಟ್ ಸಂದರ್ಭದಲ್ಲಿ (prompt context) ಇದ್ದರೂ ಸಹ, ಮಾಡೆಲ್ ಅದನ್ನು ಸರಿಯಾದ ಸಮಯದಲ್ಲಿ ಹೊರಹಾಕಲು ವಿಫಲವಾಯಿತು.
ಇವು ತಾರ್ಕಿಕ ಸಾಮರ್ಥ್ಯದ ಕೊರತೆಯಲ್ಲ; ಇವು ವರ್ಕ್ಫ್ಲೋ ಅನ್ನು ಹೇಗೆ ನಿಯಂತ್ರಿಸಲಾಗುತ್ತದೆ ಎಂಬುದರಲ್ಲಿನ ಎಂಜಿನಿಯರಿಂಗ್ ದೋಷಗಳು (engineering bugs). ಹೆಚ್ಚು ಸಾಮರ್ಥ್ಯವುಳ್ಳ ಭಾಷಾ ಮಾಡೆಲ್ ಆಗಿದ್ದರೂ ಸಹ, ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಅನ್ನು ಕೋಡಿಂಗ್ ಮಾಡದ ಕರ್ತವ್ಯಗಳಿಗೆ ಸೀಮಿತಗೊಳಿಸಲು ಮತ್ತು ಸರಿಯಾದ SDK ಆಯ್ಕೆಯನ್ನು ಮಾಡಲು ಒತ್ತಾಯಿಸುವ ಕಟ್ಟುನಿಟ್ಟಾದ, ತಪ್ಪಿಸಿಕೊಳ್ಳಲಾಗದ ನಿಯಮದ ಅಗತ್ಯವಿರುತ್ತದೆ.
ಏಜೆಂಟ್ ಅನ್ನು ನಿಯಂತ್ರಿಸಲು ನಾನು ಮಾಡಿದ ಬದಲಾವಣೆಗಳು
ಹಂತಗಳ ಪಟ್ಟಿಯಿಂದ (step list) ಸಿಸ್ಟಮ್ ತನ್ನ ಪಾತ್ರವನ್ನು ತಾನೇ ಅರಿಯುತ್ತದೆ ಎಂದು ನಾನು ಭಾವಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದೆ. ನಾನು ಒಂದು ನೇರ ಹೇಳಿಕೆಯನ್ನು ಸೇರಿಸಿದೆ: “You are an orchestrator. You do not implement.” ಈ ಸೂಚನೆಯು ಅಳವಡಿಕೆಯಾಗಲು ಐದು ತಿದ್ದುಪಡಿ ಸಂದೇಶಗಳು ಬೇಕಾದವು, ಅದರ ನಂತರ ಏಜೆಂಟ್ ಆ ಮಿತಿಯನ್ನು ಗೌರವಿಸಿತು.
ನಾನು ಸಂದರ್ಭ-ಮರುಪಡೆಯುವಿಕೆ ತರ್ಕವನ್ನು (context-retrieval logic) ಕೂಡ ಬಲಪಡಿಸಿದೆ. ತಪ್ಪಾದ ಟೂಲ್ ಬಂದಾಗ, ನಾನು ಅದನ್ನು 'hallucination' ಎಂದು ಪರಿಗಣಿಸುವ ಬದಲು ಮರುಪಡೆಯುವಿಕೆ ಪೈಪ್ಲೈನ್ನಲ್ಲಿನ (retrieval pipeline) ದೋಷ ಎಂದು ಪರಿಗಣಿಸಿದೆ ಮತ್ತು ಸರಿಯಾದ ವರ್ಷನ್ ಅನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗದಂತೆ ಮಾಡಲು SDK ವಿವರಗಳನ್ನು ನೀಡುವ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಮರುಬರೆಯಿದೆ.
AI-ವರ್ಧಿತ ಅಭಿವೃದ್ಧಿಗಾಗಿ ಪ್ರಾಯೋಗಿಕ ಅಂಶಗಳು
- ನಿಮ್ಮ ಸ್ವಂತ ಸಂದೇಶಗಳನ್ನು ಎಣಿಸಿ. ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಅಂಗೀಕೃತ PRಗಳು ದೋಷಪೂರಿತ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮರೆಮಾಚಬಹುದು. ನಿಮ್ಮ ತಿದ್ದುಪಡಿಗಳ ಸಂಖ್ಯೆಯು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಎಲ್ಲಿ ಲೋಪವಾಗುತ್ತಿದೆ ಎಂಬುದನ್ನು ತೋರಿಸುವ ಮುನ್ಸೂಚಕವಾಗಿದೆ.
- ಪಾತ್ರವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ತಿಳಿಸಿ. ಏಜೆಂಟ್ಗಳು ಕೇವಲ ಚೆಕ್ಲಿಸ್ಟ್ನಿಂದ ತಮ್ಮ ಗುರುತನ್ನು ಅರಿಯುವುದಿಲ್ಲ; ಅವರು ಯಾರು ಮತ್ತು ಅವರು ಏನು ಮಾಡಬಹುದು ಎಂಬುದರ ಬಗ್ಗೆ ಸ್ಪಷ್ಟವಾದ, ನಿಗದಿತ ಸೂಚನೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ.
- ಟೂಲ್-ಆಯ್ಕೆ ದೋಷಗಳನ್ನು ಎಂಜಿನಿಯರಿಂಗ್ ದೋಷಗಳೆಂದು ಪರಿಗಣಿಸಿ. ಏಜೆಂಟ್ ನಿರ್ದಿಷ್ಟ SDK ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದರೆ, ತಪ್ಪಾದದ್ದು ಮಾಡೆಲ್ನ "ಜ್ಞಾನವಲ್ಲ", ಬದಲಾಗಿ ಸಂದರ್ಭ-ಪೂರೈಕೆ ವ್ಯವಸ್ಥೆ (context-delivery mechanism).
- ತಪ್ಪುಗಳನ್ನು ಮರುಬಳಕೆ ಮಾಡಬಹುದಾದ ಕೌಶಲ್ಯಗಳನ್ನಾಗಿ ಪರಿವರ್ತಿಸಿ. ಏಜೆಂಟ್ ತನ್ನದೇ ಆದ ತಪ್ಪುಗಳಿಂದ ಒಂದು ವ್ಯಾಲಿಡೇಶನ್ ರೂಟೀನ್ (validation routine) ಅನ್ನು ರಚಿಸಲು ನಾನು ಅವಕಾಶ ನೀಡಿದೆ, ಇದರಿಂದ ವೈಫಲ್ಯವನ್ನು ಭವಿಷ್ಯದ ಸುರಕ್ಷತಾ ಕ್ರಮವಾಗಿ ಬದಲಾಯಿಸಿದೆ.