મારા એજન્ટે એક સાંજે 3 PRs મોકલ્યા. મારા 40% સંદેશાઓ સુધારા હતા.
મારા AI-સંચાલિત કોડિંગ એજન્ટે એક જ સાંજે ત્રણ pull requests મોકલ્યા, પરંતુ મેં મોકલેલા 30 સંદેશાઓમાંથી 40% સુધારા હતા.
આ સત્રમાં એક MCP client, એક Azure AI Agent, અને એક M365 Copilot Agent તૈયાર કરવામાં આવ્યા. ઓટોમેટેડ ચેક્સ દ્વારા ત્રણેય PRs પાસ થઈ ગયા, અને મેં કોડની એક પણ લાઇન એડિટ કરી નહોતી. તેમ છતાં, ટ્રાન્સક્રિપ્ટ કંઈક અલગ જ વાર્તા કહે છે: કુલ 710 સંદેશાઓમાંથી, મેં 30 ટાઈપ કર્યા હતા, અને તેમાંથી 12 સંદેશાઓએ એજન્ટને ફરીથી સાચા માર્ગ પર લાવવામાં મદદ કરી. “steering rate” – એટલે કે મારા સંદેશાઓમાંથી સુધારાના સંદેશાઓનો હિસ્સો – 40% રહ્યો.
પાઇપલાઇન કેવી રીતે ગોઠવવામાં આવી હતી
- Claude એ હાઈ-લેવલ ઈમ્પ્લીમેન્ટેશન પ્લાન તૈયાર કર્યો.
- DeepSeek V4-Flash એ ઓર્કેસ્ટ્રેટર તરીકે કામ કર્યું અને પ્લાનની સમીક્ષા કરી.
- Codex એ વાસ્તવિક કોડ જનરેટ કર્યો.
- ઓર્કેસ્ટ્રેટરે કોડનું નિરીક્ષણ કર્યું અને pull requests ખોલી.
ઓર્કેસ્ટ્રેટરની નિર્ધારિત ભૂમિકા માત્ર જોડાણ બનાવવાની હતી – તેણે ઘટકો (components) વચ્ચેના વિવાદો ઉકેલવાના હતા, પોતે કોડ લખવાનો નહોતો. વ્યવહારમાં, એજન્ટે અંદાજે 40 મિનિટમાં ત્રણેય PRs માં 3,500 લાઇનનો કોડ તૈયાર કર્યો, પરંતુ તે બે વારંવાર આવતા એરર ક્લાસમાં ભૂલ પણ કરી બેઠું.
ભૂલના બે પ્રકારો
- Workflow violations – ઓર્કેસ્ટ્રેટરે ક્યારેક ક્યારેક કોડિંગ સ્ટેપ સંભાળી લીધો, તેની “glue” ભૂમિકાને અવગણીને પોતે જ ઈમ્પ્લીમેન્ટેશન વિગતો લખવા લાગ્યો.
- Context-retrieval failures – સ્પષ્ટ સૂચનાઓ હોવા છતાં, એજન્ટે ખોટું SDK અથવા વર્ઝન પસંદ કર્યું. સાચી માહિતી પ્રોમ્પ્ટ કોન્ટેક્સ્ટમાં ઉપલબ્ધ હતી, પરંતુ મોડેલ તેને યોગ્ય સમયે રજૂ કરવામાં નિષ્ફળ ગયું.
આ તર્કશક્તિમાં રહેલી ખામીઓ નથી; આ વર્કફ્લો કેવી રીતે મર્યાદિત રાખવો તેમાં રહેલી એન્જિનિયરિંગ બગ્સ (bugs) છે. વધુ સક્ષમ લેંગ્વેજ મોડેલને પણ એક કડક, અટલ નિયમની જરૂર પડશે જે ઓર્કેસ્ટ્રેટરને તેની નોન-કોડિંગ ફરજો સુધી મર્યાદિત રાખે અને સાચું SDK પસંદ કરવા માટે મજબૂર કરે.
એજન્ટને નિયંત્રિત કરવા માટે મેં શું બદલ્યું
મેં એવું માનવાનું બંધ કરી દીધું કે સિસ્ટમ સ્ટેપ લિસ્ટ પરથી તેની ભૂમિકા સમજી જશે. મેં એક સીધું વિધાન ઉમેર્યું: “You are an orchestrator. You do not implement.” આ સૂચના અમલમાં આવે તે માટે પાંચ સુધારાત્મક સંદેશાઓ લાગ્યા, ત્યારબાદ એજન્ટે તેની મર્યાદાનું પાલન કર્યું.
મેં કોન્ટેક્સ્ટ-રીટ્રીવલ લોજિકને પણ વધુ સચોટ બનાવ્યું. જ્યારે ખોટું ટૂલ દેખાયું, ત્યારે મેં તેને 'hallucination' તરીકે નહીં પણ રીટ્રીવલ પાઇપલાઇનમાં રહેલી એક 'bug' તરીકે ગણી, અને મેં SDK વિગતો આપતા પ્રોમ્પ્ટને ફરીથી લખ્યો જેથી સાચું વર્ઝન ચૂકી જવું અશક્ય બને.
AI-સહાયિત ડેવલપમેન્ટ માટે વ્યવહારુ બાબતો
- તમારા પોતાના સંદેશાઓ ગણો. સ્વીકૃત PRs ની મોટી સંખ્યા ખામીયુક્ત પ્રક્રિયાને છુપાવી શકે છે. તમારા સુધારાની સંખ્યા એ મુખ્ય સૂચક છે કે ક્યાં ખામી રહી રહી છે.
- ભૂમિકા સ્પષ્ટપણે જણાવો. એજન્ટો ચેકલિસ્ટ પરથી પોતાની ઓળખ નક્કી કરતા નથી; તેમને તેઓ કોણ છે અને તેઓ શું કરી શકે છે તે વિશે સ્પષ્ટ અને ચોક્કસ સૂચનાની જરૂર હોય છે.
- ટૂલ-ચોઈસ એરર્સને એન્જિનિયરિંગ બગ્સ તરીકે ગણો. જો એજન્ટ નિર્દિષ્ટ SDK ને અવગણે છે, તો ભૂલ કોન્ટેક્સ્ટ-ડિલિવરી મિકેનિઝમમાં છે, મોડેલના “જ્ઞાન” માં નથી.
- ભૂલોને ફરીથી ઉપયોગી કૌશલ્યોમાં ફેરવો. મેં એજન્ટને તેની પોતાની ભૂલોમાંથી વેરિફિકેશન રૂટિન જનરેટ કરવા દીધું, જેનાથી નિષ્ફળતાને ભવિષ્યના સુરક્ષા કવચમાં ફેરવી શકાય.