എന്റെ ഏജന്റ് ഒരു വൈകുന്നേരത്തിനുള്ളിൽ 3 PR-കൾ സമർപ്പിച്ചു. എന്റെ സന്ദേശങ്ങളിൽ 40% തിരുത്തലുകളായിരുന്നു.
എന്റെ AI അധിഷ്ഠിത കോഡിംഗ് ഏജന്റ് ഒരു വൈകുന്നേരത്തിനുള്ളിൽ മൂന്ന് pull requests സമർപ്പിച്ചു, എന്നാൽ ഞാൻ അയച്ച 30 സന്ദേശങ്ങളിൽ 40% തിരുത്തലുകളായിരുന്നു.
ഈ സെഷനിലൂടെ ഒരു MCP client, ഒരു Azure AI Agent, കൂടാതെ ഒരു M365 Copilot Agent എന്നിവ നിർമ്മിക്കപ്പെട്ടു. ഓട്ടോമേറ്റഡ് പരിശോധനകൾ മൂന്ന് PR-കളും പാസാക്കി, ഞാൻ ഒരു വരി കോഡ് പോലും തിരുത്തിയില്ല. എന്നിരുന്നാലും, സംഭാഷണത്തിന്റെ വിവരങ്ങൾ (transcript) മറ്റൊരു കഥയാണ് പറയുന്നത്: ആകെ 710 സന്ദേശങ്ങളിൽ ഞാൻ ടൈപ്പ് ചെയ്തത് 30 എണ്ണമാണ്, അതിൽ 12 എണ്ണവും ഏജന്റിനെ ശരിയായ പാതയിലേക്ക് തിരിച്ചുവിടാൻ സഹായിച്ചവയായിരുന്നു. "steering rate" – അതായത് എന്റെ സന്ദേശങ്ങളിൽ തിരുത്തലുകൾ എത്രത്തോളമുണ്ടെന്ന കണക്ക് – 40% ആണ്.
പൈപ്പ്ലൈൻ എങ്ങനെയായിരുന്നു ക്രമീകരിച്ചിരുന്നത്
- Claude ഒരു ഹൈ-ലെവൽ ഇംപ്ലിമെന്റേഷൻ പ്ലാൻ തയ്യാറാക്കി.
- DeepSeek V4-Flash പ്ലാൻ പരിശോധിച്ചുകൊണ്ട് ഒരു ഓർക്കസ്ട്രേറ്ററായി (orchestrator) പ്രവർത്തിച്ചു.
- Codex യഥാർത്ഥ കോഡ് നിർമ്മിച്ചു.
- ഓർക്കസ്ട്രേറ്റർ കോഡ് പരിശോധിക്കുകയും pull requests തുറക്കുകയും ചെയ്തു.
ഓർക്കസ്ട്രേറ്ററുടെ ഉദ്ദേശ്യപരമായ പങ്ക് കേവലം ബന്ധിപ്പിക്കുക എന്നത് മാത്രമായിരുന്നു – അത് ഘടകങ്ങൾ തമ്മിലുള്ള വൈരുദ്ധ്യങ്ങൾ പരിഹരിക്കണം, കോഡ് സ്വയം എഴുതരുത്. പ്രായോഗികമായി, ഏജന്റ് ഏകദേശം 40 മിനിറ്റിനുള്ളിൽ മൂന്ന് PR-കളിലായി 3,500 വരി കോഡുകൾ നിർമ്മിച്ചു, എന്നാൽ ആവർത്തിച്ചുവരുന്ന രണ്ട് തരം പിശകുകളിൽ അത് വീണുപോയി.
രണ്ട് തരം പിശകുകൾ
- വർക്ക്ഫ്ലോ ലംഘനങ്ങൾ (Workflow violations) – ഓർക്കസ്ട്രേറ്റർ ഇടയ്ക്കിടെ കോഡിംഗ് ഘട്ടം ഏറ്റെടുക്കുകയും, അതിന്റെ "glue" പങ്ക് അവഗണിച്ച് ഇംപ്ലിമെന്റേഷൻ വിവരങ്ങൾ സ്വയം എഴുതുകയും ചെയ്തു.
- കോൺടെക്സ്റ്റ് റിട്രീവൽ പരാജയങ്ങൾ (Context-retrieval failures) – വ്യക്തമായ നിർദ്ദേശങ്ങൾ ഉണ്ടായിരുന്നിട്ടും, ഏജന്റ് തെറ്റായ SDK അല്ലെങ്കിൽ വേർഷൻ തിരഞ്ഞെടുത്തു. ശരിയായ വിവരങ്ങൾ പ്രോംപ്റ്റ് കോൺടെക്സ്റ്റിൽ ഉണ്ടായിരുന്നുവെങ്കിലും, ശരിയായ സമയത്ത് അത് പുറത്തുകൊണ്ടുവരാൻ മോഡലിന് കഴിഞ്ഞില്ല.
ഇവ യുക്തിപരമായ കഴിവുകളിലെ കുറവല്ല; മറിച്ച് വർക്ക്ഫ്ലോ എങ്ങനെ നിയന്ത്രിക്കപ്പെടുന്നു എന്നതിലെ എഞ്ചിനീയറിംഗ് ബഗുകളാണ്. കൂടുതൽ കഴിവുള്ള ഒരു ലാംഗ്വേജ് മോഡലിന് പോലും, ഓർക്കസ്ട്രേറ്ററെ കോഡിംഗ് ഇതര ചുമതലകളിൽ മാത്രം ഉറപ്പിച്ചു നിർത്തുന്നതിനും ശരിയായ SDK തിരഞ്ഞെടുക്കാൻ നിർബന്ധിക്കുന്നതിനുമായി കർശനമായ, അവഗണിക്കാനാവാത്ത നിയമങ്ങൾ ആവശ്യമായി വരും.
ഏജന്റിനെ നിയന്ത്രിക്കാൻ ഞാൻ വരുത്തിയ മാറ്റങ്ങൾ
സ്റ്റെപ്പ് ലിസ്റ്റിൽ നിന്ന് സിസ്റ്റം അതിന്റെ പങ്ക് സ്വയം മനസ്സിലാക്കുമെന്ന് ഞാൻ കരുതുന്നത് നിർത്തി. പകരം ഞാൻ ഒരു നേരിട്ടുള്ള പ്രസ്താവന ചേർത്തു: “You are an orchestrator. You do not implement.” ഈ നിർദ്ദേശം നിലനിൽക്കാൻ അഞ്ച് തിരുത്തൽ സന്ദേശങ്ങൾ ആവശ്യമായി വന്നു, അതിനുശേഷം ഏജന്റ് ആ പരിധി പാലിച്ചു.
ഞാൻ കോൺടെക്സ്റ്റ് റിട്രീവൽ ലോജിക് കൂടുതൽ കർശനമാക്കി. തെറ്റായ ടൂൾ ഉപയോഗിക്കപ്പെടുമ്പോൾ, അതിനെ ഒരു 'hallucination' ആയി കാണുന്നതിന് പകരം റിട്രീവൽ പൈപ്പ്ലൈനിലെ ഒരു ബഗ് ആയി ഞാൻ കണക്കാക്കി. കൂടാതെ, ശരിയായ വേർഷൻ ഒഴിവാക്കാൻ കഴിയില്ലെന്ന് ഉറപ്പാക്കാൻ SDK വിവരങ്ങൾ നൽകുന്ന പ്രോംപ്റ്റ് ഞാൻ വീണ്ടും എഴുതി.
AI സഹായത്തോടെയുള്ള വികസനത്തിനായുള്ള പ്രായോഗിക പാഠങ്ങൾ
- നിങ്ങളുടെ സന്ദേശങ്ങൾ എണ്ണുക. അംഗീകരിക്കപ്പെട്ട PR-കളുടെ ഉയർന്ന എണ്ണം ഒരു തകരാറുള്ള പ്രക്രിയയെ മറച്ചുവെച്ചേക്കാം. നിങ്ങളുടെ തിരുത്തലുകളുടെ എണ്ണം, സിസ്റ്റത്തിലെ പിഴവുകൾ എവിടെയാണെന്ന് മനസ്സിലാക്കാൻ സഹായിക്കുന്ന ഒരു സൂചകമാണ്.
- പങ്ക് വ്യക്തമായി പറയുക. ഏജന്റുകൾ ഒരു ചെക്ക്ലിസ്റ്റിൽ നിന്ന് അവരുടെ ഐഡന്റിറ്റി സ്വയം കണ്ടെത്തില്ല; അവർ ആരാണെന്നും എന്താണ് ചെയ്യേണ്ടതെന്നും വ്യക്തമായ നിർദ്ദേശങ്ങൾ അവർക്ക് ആവശ്യമാണ്.
- ടൂൾ തിരഞ്ഞെടുക്കുന്നതിലെ പിശകുകളെ എഞ്ചിനീയറിംഗ് ബഗുകളായി കാണുക. ഏജന്റ് ഒരു നിശ്ചിത SDK അവഗണിക്കുകയാണെങ്കിൽ, അതിന്റെ കുറ്റം മോഡലിന്റെ "അറിവിലല്ല", മറിച്ച് കോൺടെക്സ്റ്റ് നൽകുന്ന സംവിധാനത്തിലാണ്.
- തെറ്റുകളെ വീണ്ടും ഉപയോഗിക്കാവുന്ന കഴിവുകളാക്കി മാറ്റുക. ഏജന്റ് അതിന്റെ സ്വന്തം തെറ്റുകളിൽ നിന്ന് ഒരു വാലിഡേഷൻ റൂട്ടീൻ (validation routine) നിർമ്മിക്കാൻ ഞാൻ അനുവദിച്ചു, അങ്ങനെ ഒരു പരാജയത്തെ ഭാവിയിലേക്കുള്ള ഒരു സുരക്ഷാ സംവിധാനമാക്കി മാറ്റി.