Developers Spend 11.4 Hours a Week Reviewing AI Code—More Than They Write Themselves

2,900 എഞ്ചിനീയർമാരെ ഉൾപ്പെടുത്തി 2026-ൽ നടത്തിയ ഒരു സർവേ പ്രകാരം, ഡെവലപ്പർമാർ ഇപ്പോൾ AI നിർമ്മിച്ച കോഡ് പരിശോധിക്കാൻ ആഴ്ചയിൽ 11.4 മണിക്കൂർ ചെലവഴിക്കുന്നു, ഇത് അവർ സ്വയം എഴുതുന്ന 9.8 മണിക്കൂറിനേക്കാൾ കൂടുതലാണ്. "AI-ക്ക് കോഡ് നിർമ്മിക്കാൻ കഴിയുമോ?" എന്നതിൽ നിന്ന് "അത് നിർമ്മിക്കുന്ന കോഡിനെ നമുക്ക് വിശ്വസിക്കാമോ?" എന്നതിലേക്ക് തടസ്സങ്ങൾ മാറിയിരിക്കുന്നു. കൂടുതൽ വ്യക്തമായ തീരുമാനങ്ങൾ എടുക്കാനും ഉയർന്ന ആത്മവിശ്വാസം നൽകാനും സഹായിക്കുന്ന multi-agent AI workflows-ലേക്ക് ടീമുകൾ മാറിക്കൊണ്ടിരിക്കുകയാണ്.

ചർച്ചകൾക്ക് തുടക്കമിട്ട സർവേ

ഈ വർഷം ആദ്യം നടത്തിയ ഈ ചോദ്യാവലിയിൽ, പുതിയ കോഡ് എഴുതുന്നതിനും AI നിർമ്മിച്ച കോഡ് പരിശോധിക്കുന്നതിനും ഡെവലപ്പർമാർ എങ്ങനെ സമയം വിഭജിക്കുന്നു എന്ന് ചോദിച്ചു. കോഡ് നിർമ്മിക്കുന്നതിനേക്കാൾ കൂടുതൽ സമയം ഇപ്പോൾ പരിശോധനയ്ക്കാണ് എടുക്കുന്നതെന്ന് മറുപടി നൽകിയവർ പറഞ്ഞു. ഒരു പ്രോജക്റ്റിൽ തന്നെ രണ്ട് മുതൽ നാല് വരെ വ്യത്യസ്ത AI അസിസ്റ്റന്റുകളെ ഉപയോഗിക്കുന്നുണ്ടെന്നും, ഇതിൽ 70% പേരും ഇത് പതിവാണെന്നും അവർ റിപ്പോർട്ട് ചെയ്തു.

ഈ കണക്കുകൾ വർദ്ധിച്ചുവരുന്ന ഒരു നിരാശയെയാണ് സൂചിപ്പിക്കുന്നത്: ഒരു സിംഗിൾ, ഓൾ-പർപ്പസ് മോഡലിന് നിമിഷങ്ങൾക്കുള്ളിൽ ഒരു ഫങ്ക്ഷൻ എഴുതാൻ കഴിയും, എന്നാൽ ഡാറ്റാ സ്ട്രക്ചറുകൾ (data structures), എറർ ഹാൻഡ്‌ലിംഗ് (error handling), പെർഫോമൻസ് ഒപ്റ്റിമൈസേഷൻ (performance optimizations) എന്നിവയെക്കുറിച്ച് രേഖകളൊന്നും അവശേഷിപ്പിക്കാതെ അത് രഹസ്യമായ തീരുമാനങ്ങൾ എടുക്കുന്നുമുണ്ട്. ഡെവലപ്പർമാർക്ക് ആ തീരുമാനങ്ങൾ തിരിച്ചറിയാൻ reverse-engineering ചെയ്യേണ്ടി വരുന്നു, ഇത് ഒരു മുഴുവൻ പ്രവൃത്തിദിവസം പോലും നഷ്ടപ്പെടുത്താൻ കാരണമായേക്കാം.

എന്തുകൊണ്ട് ഒരു സിംഗിൾ മോഡൽ മാത്രം മതിയാകുന്നില്ല

വർഷങ്ങളായി സാധാരണയായി കണ്ടുവരുന്ന രീതി ഇതാണ്: ഒരു ഡെവലപ്പർ ഒരു പ്രോംപ്റ്റ് ടൈപ്പ് ചെയ്യുന്നു, മോഡൽ ഒരു ഫയൽ നിർമ്മിക്കുന്നു, തുടർന്ന് ഡെവലപ്പർ അത് കോഡ്ബേസിലേക്ക് കോപ്പി ചെയ്യുന്നു. ചെറിയ ഡെമോകൾക്ക് ഇത് ഫലപ്രദമാണെങ്കിലും, പ്രൊഡക്ഷൻ സോഫ്റ്റ്‌വെയറുകൾക്ക് ഇതിലും മികച്ച ഔട്ട്പുട്ട് ആവശ്യമാണ്. ഉദാഹരണത്തിന്, ഒരു അറേയ്ക്ക് (array) പകരം ലിങ്ക്ഡ് ലിസ്റ്റ് (linked list) ഉപയോഗിക്കാനോ അല്ലെങ്കിൽ എക്സെപ്ഷനുകൾ (exceptions) നിശബ്ദമായി അവഗണിക്കാനോ മോഡൽ തീരുമാനിച്ചാൽ, ആ തീരുമാനങ്ങൾ കോഡിൽ ഉൾച്ചേരുകയും പരിശോധിക്കുന്ന ആളുടെ ശ്രദ്ധയിൽപ്പെടാതെ പോവുകയും ചെയ്യുന്നു.

മോഡലിന്റെ ആന്തരികമായ യുക്തി (internal reasoning) രേഖപ്പെടുത്താത്തതിനാൽ, "എന്തുകൊണ്ടാണ് AI ഈ പാറ്റേൺ തിരഞ്ഞെടുത്തത്?" എന്ന് ടീമുകൾക്ക് പിന്നീട് ചോദിക്കേണ്ടി വരുന്നു. ഇതിനുള്ള ഉത്തരം കണ്ടെത്താൻ നിർമ്മിക്കപ്പെട്ട കമന്റുകൾ പരിശോധിക്കുകയോ, വ്യത്യസ്ത temperature settings ഉപയോഗിച്ച് പ്രോംപ്റ്റ് വീണ്ടും റൺ ചെയ്യുകയോ, അല്ലെങ്കിൽ മുഴുവൻ ജനറേഷൻ ഘട്ടവും ആവർത്തിക്കുകയോ ചെയ്യേണ്ടി വരുന്നു. ഈ അനിശ്ചിതത്വമാണ് സർവേയിൽ അധിക പരിശോധനാ സമയമായി കാണുന്നത്.

ജോലി വിഭജിക്കുക: മൾട്ടി-ഏജന്റ് സിസ്റ്റങ്ങൾ എങ്ങനെ സഹായിക്കുന്നു

മൾട്ടി-ഏജന്റ് സംവിധാനങ്ങൾ ഒരു ചെറിയ ഡെവലപ്‌മെന്റ് ടീമിനെപ്പോലെ പ്രവർത്തിക്കുന്നു. ഒരു മോഡൽ എല്ലാം കൈകാര്യം ചെയ്യുന്നതിന് പകരം, വ്യത്യസ്ത ഏജന്റുകൾ വ്യത്യസ്ത ഉത്തരവാദിത്തങ്ങൾ ഏറ്റെടുക്കുന്നു:

• Architect agent: ഉയർന്ന തലത്തിലുള്ള ഡിസൈൻ ഡോക്യുമെന്റ് തയ്യാറാക്കുന്നു, ഡാറ്റാ മോഡലുകൾ, API കോൺട്രാക്റ്റുകൾ, എറർ-ഹാൻഡ്‌ലിംഗ് തന്ത്രങ്ങൾ എന്നിവയുടെ രൂപരേഖ തയ്യാറാക്കുന്നു.
• Implementation agent: സ്പെസിഫിക്കേഷനുകൾ ഒരു ചെക്ക്‌ലിസ്റ്റ് ആയി ഉപയോഗിച്ച് ആർക്കിടെക്ചർ കൃത്യമായി പിന്തുടരുന്ന കോഡ് എഴുതുന്നു.
• Verification agent: ക്വാളിറ്റി അഷ്വറൻസിൽ മാത്രം ശ്രദ്ധ കേന്ദ്രീകരിച്ച് യൂണിറ്റ് ടെസ്റ്റുകൾ നിർമ്മിക്കുന്നു, സ്റ്റാറ്റിക് അനാലിസിസ് നടത്തുന്നു, അല്ലെങ്കിൽ CI/CD പൈപ്പ്‌ലൈനുകൾ സജ്ജമാക്കുന്നു.

ഓരോ ഏജന്റിന്റെയും ഔട്ട്പുട്ട് ഒരു പ്രത്യേക ആർട്ടിഫാക്റ്റ് (artifact) ആണ്, അതിനാൽ ഒരു തീരുമാനത്തിന് പിന്നിലെ യുക്തി ആ ആർട്ടിഫാക്റ്റിൽ തന്നെ ലഭ്യമായിരിക്കും. കോഡ് എഴുതുന്നതിന് മുമ്പ് ആർക്കിടെക്ചർ പരിശോധിക്കുന്നത്, തെറ്റായ ഡിസൈൻ കാരണം ഉണ്ടാകുന്ന ബഗ്ഗുകൾ പരിഹരിക്കുന്നതിനേക്കാൾ ചിലവ് കുറഞ്ഞ കാര്യമാണ്. കൂടാതെ, ഒരു പ്രത്യേക ഇംപ്ലിമെന്റേഷൻ വിശദാംശത്തിൽ ആരാണ് (അല്ലെങ്കിൽ എന്താണ്) തീരുമാനമെടുത്തതെന്ന് അറിയേണ്ട കംപ്ലയൻസ് ടീമുകൾക്ക് ഇത് കൃത്യമായ വിവരങ്ങൾ നൽകുന്നു.

മൾട്ടി-ഏജന്റ് വർക്ക്ഫ്ലോകൾ പ്രായോഗികമാക്കുന്ന ടൂളുകൾ

ഡെവലപ്പർമാർ ഇതിനകം തന്നെ വിവിധ യൂട്ടിലിറ്റികൾ ഉപയോഗിച്ച് ഇത്തരം പൈപ്പ്‌ലൈനുകൾ നിർമ്മിച്ചുവരുന്നു:

• IDE integrations: ഏജന്റുകളെ സൈഡ് പാനലുകളായി കാണാൻ ഇത് അനുവദിക്കുന്നു, ഒരു ക്ലിക്കിലൂടെ ആർക്കിടെക്ചർ ഡോക്യുമെന്റ് കോഡ്-ജനറേഷൻ അസിസ്റ്റന്റിലേക്ക് കൈമാറാം.
• CLI utilities: സ്ക്രിപ്റ്റ് ചെയ്ത ക്രമങ്ങൾ സാധ്യമാക്കുന്നു: ആർക്കിടെക്റ്റിനെ പ്രവർത്തിപ്പിക്കുക, അതിന്റെ ഔട്ട്പുട്ട് കോഡറിലേക്ക് കൈമാറുക, തുടർന്ന് ഫലം ടെസ്റ്ററുടെ പക്കലേക്ക് എത്തിക്കുക.
• Frameworks: പ്രോജക്റ്റ് ആവശ്യങ്ങൾക്കനുസരിച്ച് മാറ്റം വരുത്താൻ കഴിയുന്ന കസ്റ്റം ഏജന്റുകളെ നിർമ്മിക്കാനുള്ള ലൈബ്രറികൾ നൽകുന്നു.
• Specification-first platforms: ഏതൊരു ജനറേഷനും തുടങ്ങുന്നതിന് മുമ്പ് ഔദ്യോഗികമായ ഒരു റിക്വയർമെന്റ് ഫയൽ ആവശ്യപ്പെടുന്നു, ഇത് ഡിസൈൻ ഘട്ടം ഒഴിവാക്കപ്പെടുന്നില്ലെന്ന് ഉറപ്പാക്കുന്നു.

സർവേയിലെ 70% എന്ന കണക്ക് സൂചിപ്പിക്കുന്നത് മിക്ക ടീമുകളും ഇതിനകം തന്നെ ഇത്തരം പൈപ്പ്‌ലൈനുകളുടെ താൽക്കാലിക പതിപ്പുകൾ നിർമ്മിച്ചു കഴിഞ്ഞു എന്നാണ്. എഞ്ചിനീയർമാർ മാനുവലായി ചെയ്തുവരുന്ന കാര്യങ്ങളെ പുതിയ പ്ലാറ്റ്‌ഫോമുകൾ ഔദ്യോഗികമായി രൂപപ്പെടുത്തുന്നു എന്ന് മാത്രം.

ആർക്കൊക്കെ ഗുണമുണ്ടാകും—ആർക്കൊക്കെ പിന്നിലാകും

ഫിനാൻസ് അല്ലെങ്കിൽ ഹെൽത്ത് കെയർ പോലുള്ള കർശനമായ ഓഡിറ്റ് ആവശ്യകതകളുള്ള സ്ഥാപനങ്ങൾക്ക് ഇതിലൂടെ ഉടനടി ഗുണം ലഭിക്കും. രേഖപ്പെടുത്തിയ ഒരു design-to-code ശൃംഖല പ്രൊഡക്ഷനിലേക്ക് ഒളിഞ്ഞിരിക്കുന്ന സുരക്ഷാ വീഴ്ചകൾ (vulnerabilities) കടന്നുകൂടാനുള്ള സാധ്യത കുറയ്ക്കുന്നു. എന്നാൽ ചെറിയ സ്റ്റാർട്ടപ്പുകൾക്ക്, ഒരു സിംഗിൾ മോഡലിന്റെ വേഗതയാണ് പ്രധാനം എങ്കിൽ, ഒന്നിലധികം ഏജന്റുകളെ പരിപാലിക്കുന്നതിലെ അധിക ചിലവ് അനാവശ്യമായി തോന്നിയേക്കാം.

മൾട്ടി-ഏജന്റ് സിസ്റ്റങ്ങൾ സങ്കീർണ്ണത വർദ്ധിപ്പിക്കുന്നു എന്ന് ഒരു എതിർവാദമുണ്ട്. മൂന്നോ അതിലധികമോ മോഡലുകളെ ഏകോപിപ്പിക്കുന്നത് ഇന്റഗ്രേഷൻ ബഗുകൾക്ക് കാരണമായേക്കാം, ലേറ്റൻസി വർദ്ധിപ്പിക്കാം, കൂടാതെ കൂടുതൽ വിപുലമായ മോണിറ്ററിംഗ് ആവശ്യമായി വന്നേക്കാം. കസ്റ്റം ഏജന്റുകളെ നിർമ്മിക്കാനോ നിയന്ത്രിക്കാനോ ഉള്ള വൈദഗ്ധ്യം ഇല്ലാത്ത ടീമുകൾ, യഥാർത്ഥ വികസനത്തേക്കാൾ കൂടുതൽ സമയം ഓർക്കസ്ട്രേഷനായി ചിലവഴിച്ചേക്കാം. അത്തരം ഗ്രൂപ്പുകളെ സംബന്ധിച്ചിടത്തോളം, കൃത്യമായി ട്യൂൺ ചെയ്ത ഒരു സിംഗിൾ മോഡൽ—പ്രത്യേകിച്ച് ഇൻ-ബിൽറ്റ് എക്സ്പ്ലെയിനബിലിറ്റി നൽകുന്ന ഒന്ന്—പ്രായോഗികമായ തിരഞ്ഞെടുപ്പായി തുടരാം.

വരും മാസങ്ങളിൽ ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ

• AI-ജനറേറ്റ് ചെയ്ത ആർട്ടിഫാക്റ്റുകൾക്കായി സ്റ്റാൻഡേർഡൈസ്ഡ് ലോഗിംഗ് ഫോർമാറ്റുകൾ ഉപയോഗിക്കുന്നത് വിവിധ ഏജന്റുകളുടെ ഔട്ട്‌പുട്ടുകൾ താരതമ്യം ചെയ്യുന്നത് എളുപ്പമാക്കും.
• ആർക്കിടെക്ചർ, കോഡിംഗ്, ടെസ്റ്റിംഗ് ഏജന്റുകളെ ഒരു സബ്‌സ്‌ക്രിപ്ഷനിൽ ഉൾപ്പെടുത്തി നൽകുന്ന മാർക്കറ്റ് പ്ലേസ് ഓഫറുകൾ, സ്വന്തമായി AI വൈദഗ്ധ്യം ഇല്ലാത്ത ടീമുകൾക്ക് ഈ സാങ്കേതികവിദ്യ ഉപയോഗിക്കുന്നത് എളുപ്പമാക്കിയേക്കാം.
• AI-സഹായത്തോടെയുള്ള കോഡിംഗിനെക്കുറിച്ചുള്ള റെഗുലേറ്ററി ഗൈഡൻസ്, കൂടുതൽ സ്ഥാപനങ്ങളെ ഓഡിറ്റ് ചെയ്യാവുന്നതും മൾട്ടി-സ്റ്റെപ്പ് പൈപ്പ്‌ലൈനുകളുമുള്ള രീതികളിലേക്ക് നയിച്ചേക്കാം.
• വെറും ജനറേഷൻ സ്പീഡ് മാത്രമല്ല, മൊത്തത്തിലുള്ള ഡെവലപ്‌മെന്റ് സമയം കൂടി അളക്കുന്ന പെർഫോമൻസ് ബെഞ്ച്മാർക്കുകൾ, അധികമായ ഏകോപന ജോലികൾ (coordination overhead) ലാഭകരമാണോ എന്ന് തീരുമാനിക്കാൻ ടീമുകളെ സഹായിക്കും.

സർവേയിലെ പ്രധാന കണക്കുകൾ വ്യക്തമായ ഒരു കാര്യം സൂചിപ്പിക്കുന്നു: ഡെവലപ്പർമാർ പുതിയ കോഡ് എഴുതുന്നതിനേക്കാൾ കൂടുതൽ സമയം AI ഔട്ട്‌പുട്ടുകൾ വീണ്ടും പരിശോധിക്കാനാണ് ചിലവഴിക്കുന്നത്. "ബ്ലാക്ക്-ബോക്സ്" ജനറേഷനെ രേഖപ്പെടുത്തപ്പെട്ടതും പരിശോധിക്കാവുന്നതുമായ ഒരു പ്രക്രിയയാക്കി മാറ്റുന്ന ട്രേസബിലിറ്റി നൽകിക്കൊണ്ട്, മൾട്ടി-ഏജന്റ് വർക്ക്ഫ്ലോകൾ ഇതിനുള്ള നേരിട്ടുള്ള മറുപടിയായി ഉയർന്നുവരുന്നു. അധികമായ ഓർക്കസ്ട്രേഷൻ സങ്കീർണ്ണത എല്ലാ ടീമുകൾക്കും അനുയോജ്യമാണോ എന്നത് കണ്ടറിയേണ്ട കാര്യമാണ്, എങ്കിലും AI ഉത്തരവാദിത്തങ്ങൾ വിഭജിക്കുന്ന രീതി നിലവിൽ സോഫ്റ്റ്‌വെയർ നിർമ്മാണ രീതികളെ മാറ്റിമറിച്ചുകൊണ്ടിരിക്കുകയാണ്.