एजंटीक कोडिंग स्वीकारणाऱ्या बहुतांश टीममधील अडथळा निर्मितीकडून पुनरावलोकनाकडे जातो. हे चक्र सुधारल्याशिवाय एकूण वेगवाढ जवळपास शून्यच राहते.
मोठ्या प्रमाणावरील CI पर्यावरणांमध्ये, जिथे दररोज रात्री लाखो चाचण्या होतात आणि शेकडो इंजिनिअर्स काम करतात, एजंटकडून करवून घेण्यास सर्वाधिक मौल्यवान काम म्हणजे जबाबदार टीमकडे पाठवणे आणि प्राथमिक छाननी करणे, कोड जनरेट करणे नव्हे.
एजंटचा उपयुक्त आउटपुट बारकाईने तपासल्यावरही टिकतो आणि केवळ नमुने जुळवण्याऐवजी कारणमीमांसा स्पष्ट करतो.
जनरेशनच्या स्तरापेक्षा पुरावे गोळा करण्याचा आणि संदर्भ जोडण्याचा स्तर आखणे अधिक महत्त्वाचे आहे.
एजंटीक कोडिंगवरील बहुतांश चर्चा अजूनही एका साध्या आश्वासनापासून सुरू होते: अधिक वेगाने अधिक कोड लिहिणे.
कधी कधी ही कल्पना अधिक महत्त्वाकांक्षी बनते: एजंट कामाचे नियोजन करतील, PR उघडतील आणि कमीत कमी मानवी हस्तक्षेपाने बदल शिप करतील. पण बहुतांश इंजिनिअरिंग टीम्ससाठी नजीकच्या काळातील सर्वात स्पष्ट लाभाची व्याप्ती यापेक्षा मर्यादित आहे. हा लाभ म्हणजे पुनरावृत्ती प्रक्रियेचा खर्च कमी करणे.
सॉफ्टवेअर डिलिव्हरी म्हणजे केवळ कोड तयार करणे नव्हे. कोड लिहिणे हा दीर्घ चक्रातील केवळ एक टप्पा आहे. या चक्रात पुनरावलोकन, चाचणी, डिप्लॉयमेंट आणि बिघाड झाल्यास तपास यांचाही समावेश होतो. पुनरावलोकनाचे चक्र नव्याने न आखता एजंटीक कोडिंग स्वीकारणाऱ्या बहुतांश टीम फक्त आपला अडथळा पुढच्या टप्प्यावर ढकलतात.
केवळ निर्मितीचा वेग वाढवल्याने टीमचा वेग आपोआप वाढत नाही. त्यामुळे पुनरावलोकन, पडताळणी आणि विश्वास निर्माण करण्यासाठी अधिक मेहनत घ्यावी लागू शकते.
अनेक इंजिनिअिरंग पर्यावरणांत पहिला मसुदा तयार करणे खर्चिक नसते, तर त्याच्या योग्यतेचा विश्वास पटणे खर्चिक असते.
त्या बदलाने खरोखर समस्या सोडवली किंवा सिस्टम सुधारली का? त्यामुळे इतरत्र एखादी त्रुटी पुन्हा निर्माण झाली का? बिघाड कोडमध्ये, पर्यावरणात, चाचण्यांमध्ये की एखाद्या अवलंबित्वात आहे? सुचवलेला उपाय मूळ कारण दूर करतो आहे की केवळ दिसणारे लक्षण?
एजंट येथे मदत करू शकतात. ते इंजिनिअर्सची जागा घेतात म्हणून नव्हे, तर विस्कळीत पुराव्याची संरचित प्राथमिक तपासणी करू शकतात म्हणून. ते नोंदी तपासू शकतात, अलीकडील बदलांची तुलना करू शकतात, संबंधित संकेतांचा सारांश देऊ शकतात, संभाव्य कारणांचा माग काढू शकतात, तपासण्या चालवू शकतात आणि माणसाला पुढे प्रश्न विचारून तपासता येईल असा आउटपुट देऊ शकतात.
अनेक टीममध्ये एजंटचा सर्वाधिक प्रभावी उपयोग म्हणजे सुरुवातीपासून कोड तयार करणे नव्हे. तर एखाद्या माणसाने तासन्‌तास हाताने शोध घेण्यापूर्वी समस्येशी संबंधित शोधक्षेत्र कमी करणे.
मोठ्या प्रमाणावरील डीबगिंगच्या कार्यप्रवाहात हे विशेषतः स्पष्ट दिसते. शेकडो इंजिनिअर्सनी बदललेल्या कोडबेसेसवर दररोज रात्री लाखो चाचण्या चालवणाऱ्या CI ची कल्पना करा. आमच्या एका ग्राहकासाठी हे वास्तव आहे. काही बिघडल्यास त्याची जबाबदारी योग्य टीमकडे सोपवणे कठीण असते. समस्या ॲप्लिकेशनच्या कोडमध्ये, एखाद्या अवलंबित्वात, चाचणी हार्नेसमध्ये किंवा स्टॅकमधील अन्य ठिकाणी असू शकते. लॉगचा आकार अनेक गिगाबाइटपर्यंत जाऊ शकतो आणि समस्या सर्वप्रथम पाहणारी टीम नेहमीच तिच्यासाठी जबाबदार असेल असे नाही.
अशा कार्यप्रवाहात उपाय लिहिण्यासाठी एकच एजंट वापरणे स्वाभाविक ठरत नाही. तो समस्येचे क्षेत्र झटपट मर्यादित करणाऱ्या सिस्टमसाठी योग्य आहे.
उपयुक्त प्रक्रियेत लॉग्स मिळवणे, संबंधित पुरावे निवडणे, महत्त्वाच्या बाबींचा सारांश देणे, सँडबॉक्समध्ये कोड तपासणे आणि खात्रीचे गुणांकन, मागोवा घेण्याची सोय व पुढील सुचवलेल्या पायऱ्यांसह संरचित मूळ-कारण विश्लेषण तयार करणे यांचा समावेश असू शकतो. खात्रीचे गुणांकन तयार करण्यासाठी विषयतज्ञ एजंटच्या प्रारंभिक आउटपुटचे मूल्यमापन करतात. त्यानंतर हे मूल्यमापन परीक्षक म्हणून वापरल्या जाणाऱ्या LLM ला दिले जाते, म्हणजे मानवी निर्णयाशी सुसंगती राखून पुढील गुणांकन ऑटोमेट करता येईल.
इंजिनिअरिंगच्या निर्णयाची गरज संपवणे हा उद्देश नसून पुनरावलोकनकर्त्यांना अधिक भक्कम सुरुवात उपलब्ध करून देणे हा आहे. पुन्हा उद्भवलेल्या त्रुटींची प्राथमिक छाननी, PR चे पुनरावलोकन, चाचणी दुरुस्ती, रिलीझची पडताळणी आणि डिप्लॉयमेंटच्या नंतरचा तपास या सर्वांची रचना सारखीच असते. या प्रक्रिया पुरावे आणि पुनरावलोकनांवर मोठ्या प्रमाणात अवलंबून असतात आणि त्यांत बरीच संदिग्धता असते. त्या एजंटला इंजिनिअरिंग प्रक्रियेची जागा घेण्यास सांगत नाहीत, तर ती प्रक्रिया पुढे नेण्यास मदत करायला सांगतात.
त्यामुळेच या सिस्टम्सचे मूल्यमापन कसे करावे याबाबत टीमनी काळजी घेणे आवश्यक आहे.
एजंट स्वतंत्रपणे एखादी प्रभावी गोष्ट तयार करू शकतो का, हा चुकीचा प्रश्न आहे. इतरत्र अडथळा निर्माण न करता तो प्रत्यक्ष कार्यप्रवाह सुधारतो का, हा अधिक योग्य प्रश्न आहे.
यासाठी आउटपुट पडताळता येण्याइतका नेमका आहे का, केवळ नमुने जुळवण्याऐवजी तो कारणमीमांसा स्पष्ट करतो का आणि पुनरावलोकन अधिक कठीण करण्याऐवजी सोपे करतो का, हे पहावे लागते. विश्वासार्ह वाटणारे उत्तर आणि उपयुक्त उत्तर एकच नसते. प्रत्यक्षात, एजंटचा परिणाम बारकाईने तपासल्यावरही टिकतो आणि पडताळण्यासाठी काहीतरी ठोस देतो, तेव्हा टीम्स त्यावर विश्वास ठेवतात.
यातील अधिक मूलभूत धडा असा की उपयुक्त एजंट-आधारित सिस्टम्स केवळ निर्मितीवर अवलंबून नसतात. पुरावे कसे गोळा केले जातात, संदर्भ कसा जोडला जातो, आउटपुट कसे तपासले जातात आणि अनिश्चितता पुनरावलोकनकर्त्यासमोर कशी मांडली जाते, यावर त्या अवलंबून असतात.
म्हणूनच एजंट-आधारित इंजिनिअरिंगचे नजीकचे भविष्य पूर्ण स्वायत्ततेकडे एका मोठ्या झेपेने जाण्याची शक्यता कमी आहे. त्याऐवजी, ते काटेकोरपणे आखलेल्या चक्रांचे स्वरूप घेण्याची अधिक शक्यता आहे. त्यांत एजंट टीम्सना प्रत्येक टप्प्यामधील वाया जाणारे प्रयत्न कमी करून आपले काम तपासण्यास, पुनरावलोकन करण्यास, पडताळण्यास आणि सुधारण्यास मदत करतील.
स्वायत्ततेच्या व्यापक कथनाच्या तुलनेत हे कमी नाट्यमय वाटू शकते, पण उपयुक्त सिस्टम्स प्रत्यक्षात ज्या प्रकारे स्वीकारल्या जातात त्याच्या हे खूप जवळ आहे.