माझ्या एजंटने एका संध्याकाळात ३ PRs पाठवले. माझ्या ४०% संदेश सुधारणांसाठी होते.
माझ्या AI-चालित कोडिंग एजंटने एकाच संध्याकाळात तीन pull requests पाठवले, परंतु मी पाठवलेल्या ३० संदेशांपैकी ४०% संदेश सुधारणांसाठी होते.
या सत्रातून एक MCP client, एक Azure AI Agent आणि एक M365 Copilot Agent तयार झाले. ऑटोमेटेड चेकनी तिन्ही PRs मंजूर केले आणि मी कोडची एक ओळही संपादित केली नाही. तरीही, ट्रान्सक्रिप्ट वेगळी गोष्ट सांगते: एकूण ७१० संदेशांपैकी, मी ३० संदेश टाईप केले आणि त्यातील १२ संदेशांमुळे एजंट पुन्हा योग्य मार्गावर आला. "steering rate" – म्हणजेच माझ्या संदेशांपैकी सुधारणांचे प्रमाण – ४०% इतके होते.
पाइपलाइन कशी तयार केली होती
- Claude ने एक उच्च-स्तरीय अंमलबजावणी आराखडा (implementation plan) तयार केला.
- DeepSeek V4-Flash ने ऑर्केस्ट्रेटर (orchestrator) म्हणून काम केले आणि आराखड्याचे पुनरावलोकन केले.
- Codex ने प्रत्यक्ष कोड तयार केला.
- ऑर्केस्ट्रेटरने कोडची तपासणी केली आणि pull requests उघडले.
ऑर्केस्ट्रेटरची अपेक्षित भूमिका केवळ जोडणीची (connective) होती – त्याने घटकांमधील संघर्ष (conflicts) सोडवायचे होते, स्वतः कोड लिहायचा नव्हता. प्रत्यक्षात, एजंटने साधारण ४० मिनिटांत तीन PRs मध्ये ३,५०० ओळींचा कोड तयार केला, परंतु तो दोन वारंवार येणाऱ्या त्रुटींच्या प्रकारांमध्ये (error classes) अडकला.
दोन त्रुटींचे प्रकार
- Workflow violations – ऑर्केस्ट्रेटरने अधूनमधून कोडिंगची जबाबदारी स्वतः घेतली, आपली "glue" भूमिका दुर्लक्षित केली आणि अंमलबजावणीचे तपशील स्वतः लिहिण्यास सुरुवात केली.
- Context-retrieval failures – स्पष्ट सूचना असूनही, एजंटने चुकीचा SDK किंवा व्हर्जन निवडले. योग्य माहिती प्रॉम्प्ट कॉन्टेक्स्टमध्ये उपलब्ध होती, परंतु मॉडेल ती योग्य वेळी समोर आणण्यात अपयशी ठरले.
या तर्कशक्तीमधील (reasoning ability) त्रुटी नाहीत; तर वर्कफ्लो कसा मर्यादित ठेवायचा यातील इंजिनिअरिंग बग्स (engineering bugs) आहेत. अधिक सक्षम लँग्वेज मॉडेलला देखील एक कडक आणि स्पष्ट नियमाची गरज असेल, जो ऑर्केस्ट्रेटरला त्याच्या नॉन-कोडिंग कर्तव्यांपर्यंत मर्यादित ठेवेल आणि योग्य SDK निवडण्यास भाग पाडेल.
एजंटवर नियंत्रण मिळवण्यासाठी मी काय बदलले
सिस्टम स्टेप लिस्टवरून स्वतःची भूमिका स्वतःहून समजून घेईल, असे मानणे मी थांबवले. मी एक थेट विधान जोडले: “You are an orchestrator. You do not implement.” ही सूचना लागू होण्यासाठी पाच सुधारणात्मक संदेश लागले, त्यानंतर एजंटने या मर्यादेचा आदर केला.
मी कॉन्टेक्स्ट-रिट्रिव्हल लॉजिक देखील अधिक कडक केले. जेव्हा चुकीचे टूल समोर आले, तेव्हा मी त्याला 'hallucination' मानण्याऐवजी रिट्रिव्हल पाइपलाइनमधील एक बग मानले आणि SDK तपशील देणारा प्रॉम्प्ट पुन्हा लिहिला, जेणेकरून योग्य व्हर्जन चुकणे अशक्य होईल.
AI-संवर्धित (AI-augmented) विकासासाठी व्यावहारिक धडे
- तुमचे स्वतःचे संदेश मोजा. स्वीकारलेल्या PRs ची मोठी संख्या एखादी दोषपूर्ण प्रक्रिया लपवू शकते. तुमच्या सुधारणांची संख्या ही प्रक्रिया कुठे चुकतेय याचा एक महत्त्वाचा निर्देशक आहे.
- भूमिका स्पष्टपणे सांगा. एजंट चेकलिस्टवरून आपली ओळख स्वतःहून ठरवत नाहीत; त्यांना ते कोण आहेत आणि ते काय करू शकतात याबद्दल स्पष्ट आणि निश्चित सूचनांची आवश्यकता असते.
- टूल-निवड करण्यातील त्रुटींना इंजिनिअरिंग बग्स मानून घ्या. जर एजंटने निर्दिष्ट SDK कडे दुर्लक्ष केले, तर दोष मॉडेलच्या "ज्ञानात" नसून कॉन्टेक्स्ट-डिलिव्हरी मेकॅनिझममध्ये असतो.
- चुकांचे रूपांतर पुन्हा वापरण्यायोग्य कौशल्यांमध्ये करा. मी एजंटला त्याच्या स्वतःच्या चुकांमधून एक व्हॅलिडेशन रुटीन (validation routine) तयार करू दिले, ज्यामुळे एका अपयशाचे रूपांतर भविष्यातील संरक्षणात झाले.