മിക്ക ഡെവലപ്പർമാരും AI കോഡിംഗ് ഏജന്റുകളെ തെറ്റായ രീതിയിലാണ് വിലയിരുത്തുന്നത്. അവർ മൂന്ന് ടൂളുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു, ഒരു ടെർമിനൽ തുറക്കുന്നു, എന്നിട്ട് ഒരേ ഒരു ചെറിയ പ്രോംപ്റ്റ് നൽകുന്നു: build me a landing page. ശേഷം ഏത് ഔട്ട്പുട്ട് കാണാൻ ഭംഗിയുള്ളതാണോ അത് തിരഞ്ഞെടുക്കുന്നു. ഒരു യഥാർത്ഥ കോഡ്ബേസിനുള്ളിൽ (codebase) ഈ സിസ്റ്റങ്ങൾ എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിനെക്കുറിച്ച് ആ പരിശോധനയിൽ നിന്ന് നിങ്ങൾക്ക് ഒന്നും അറിയാൻ കഴിയില്ല.

ഒരു കോഡിംഗ് ബെഞ്ച്മാർക്കിൽ ഏത് മോഡലാണ് ഏറ്റവും ഉയർന്ന സ്കോർ നേടിയത് എന്നതല്ല ശരിയായ ചോദ്യം. മറിച്ച്, ഏത് സിസ്റ്റം ആണ് ലഭിച്ച ബുദ്ധിശക്തിയെ (intelligence) ഉപയോഗിച്ച് സങ്കീർണ്ണവും ഒന്നിലധികം ഫയലുകളുള്ളതുമായ സോഫ്റ്റ്‌വെയർ പ്രോജക്റ്റുകളിൽ പ്രായോഗികമായി പ്രയോഗിക്കാൻ കഴിയുന്നത് എന്നതാണ്. മോഡൽ എന്നത് തലച്ചോറാണ്. എന്നാൽ ഹാർനെസ് (harness)—അതായത് കോൺടെക്സ്റ്റ് മാനേജ്‌മെന്റ്, ടൂൾ ആക്സസ്, എറർ ഹാൻഡ്‌ലിംഗ്, പെർമിഷൻ ലെയറുകൾ—അത് കൈകളും കണ്ണുകളുമാണ്. മിടുക്കനായ ഒരു തലച്ചോറും എന്നാൽ കാര്യക്ഷമമല്ലാത്ത കൈകളും ഉണ്ടെങ്കിൽ, അത് നിങ്ങളുടെ പ്രൊഡക്ഷൻ കോഡിനെ (production code) ഒരു സാധാരണ തലച്ചോറിനെപ്പോലെ തന്നെ വേഗത്തിൽ തകരാറിലാക്കും.

വെറും ഡെമോകളിൽ നിന്ന് മാറി എൻജിനീയറിംഗ് ജോലികളിലേക്ക് കടക്കുമ്പോൾ മുൻനിരയിലുള്ള ടൂളുകളെ യഥാർത്ഥത്തിൽ വേർതിരിക്കുന്നത് ഇവയാണ്.

ഹാർനെസ് ആണ് ഉൽപ്പന്നം (The Harness Is the Product)

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

ഇത് ഇങ്ങനെ ചിന്തിക്കാം: മോഡൽ എന്നത് എൻജിൻ ആണ്, എന്നാൽ ഹാർനെസ് എന്നത് സസ്പെൻഷൻ, ബ്രേക്ക്, സ്റ്റിയറിംഗ് എന്നിവയാണ്. റോഡിൽ തന്നെ നിലനിൽക്കാൻ കഴിയില്ലെങ്കിൽ പവർ കൊണ്ട് ഒരു പ്രയോജനവുമില്ല.

Claude Code: ആഴത്തിലുള്ള റെപ്പോസിറ്ററി റീസണിംഗ് (Deep Repository Reasoning)

കോഡിൽ മാറ്റങ്ങൾ വരുത്തുന്നതിനേക്കാൾ ഉപരിയായി ഒരു സങ്കീർണ്ണമായ കോഡ്ബേസ് മനസ്സിലാക്കേണ്ടി വരുമ്പോഴാണ് Claude Code തിളങ്ങുന്നത്. മോഡ്യൂളുകൾ തമ്മിലുള്ള ബന്ധങ്ങളെക്കുറിച്ചുള്ള ഒരു മാനസിക മാതൃക (mental model) നിലനിർത്തുന്നതിലാണ് ഇതിന്റെ കരുത്ത്. ഒരു ഓതന്റിക്കേഷൻ മിഡിൽവെയറിൽ (authentication middleware) തുടങ്ങി, ഒരു ഡാറ്റാബേസ് റാപ്പറിലൂടെ (database wrapper) കടന്ന്, ഒരു വാലിഡേഷൻ യൂട്ടിലിറ്റിയിൽ (validation utility) പ്രത്യക്ഷപ്പെടുന്ന ഒരു ബഗ് കണ്ടെത്താൻ ശ്രമിക്കുകയാണെങ്കിൽ, Claude Code ആ ബന്ധം നിലനിർത്താൻ ശ്രമിക്കും. ഒരു ഇന്റേണൽ API പേര് മാറ്റുക, എല്ലാ കൺസ്യൂമറുകളും (consumers) അപ്‌ഡേറ്റ് ചെയ്യുക, ഒരു യൂട്ടിലിറ്റി ഫോൾഡറിലെ ഷാഡോഡ് ഇംപോർട്ട് (shadowed import) മറന്നുപോകാതെ ടെസ്റ്റുകൾ ക്രമീകരിക്കുക തുടങ്ങിയ വലിയ റീഫാക്ടറുകൾ പ്ലാൻ ചെയ്യാൻ ഇത് പ്രത്യേകിച്ച് ഉപകരിക്കും.

ഇതിൽ നിന്ന് പരമാവധി പ്രയോജനം ലഭിക്കാൻ പ്രോജക്റ്റ് റൂട്ടിൽ (project root) ഒരു CLAUDE.md ഫയൽ ഉപയോഗിക്കുന്നത് പ്രായോഗികമായ ഒരു വഴിയാണ്. ഈ ഡോക്യുമെന്റ് നിങ്ങൾക്ക് കോഡിഫൈ ചെയ്യാവുന്ന ഒരു ഇൻസ്റ്റിറ്റ്യൂഷണൽ മെമ്മറിയായി (institutional memory) പ്രവർത്തിക്കുന്നു. എല്ലാ ലോഗിംഗിനും console.log-ന് പകരം ഇന്റേണൽ റാപ്പർ ഉപയോഗിക്കണം എന്നും, ഡാറ്റാബേസ് മൈഗ്രേഷനുകൾ (database migrations) /infra/migrations-ൽ മാത്രമേ ഉണ്ടാകാവൂ എന്നും, അല്ലെങ്കിൽ ഓരോ പുതിയ React കംപോണന്റിനും അനുയോജ്യമായ ഒരു Storybook ഫയൽ വേണമെന്നും നിങ്ങൾക്ക് ഇതിൽ നിർദ്ദേശിക്കാം. ഈ ഗാർഡ്‌റെയിൽ (guardrail) ഇല്ലെങ്കിൽ, ഏത് ഏജന്റും അതിന്റെ ട്രെയിനിംഗ് ഡിഫോൾട്ടുകളിലേക്ക് തിരിയും. എന്നാൽ ഇത് ഉണ്ടെങ്കിൽ, നിങ്ങളുടെ ടീം മാസങ്ങൾ കൊണ്ട് സ്ഥാപിച്ച കൺവെൻഷനുകൾ (conventions) ബഹുമാനിക്കാൻ Claude Code-ന് കഴിയും.

നിങ്ങളുടെ ജോലി പര്യവേഷണപരവും (exploratory) ആർക്കിടെക്ചറൽ ആയതുമാണെങ്കിൽ ഈ ടൂൾ തിരഞ്ഞെടുക്കുക. സങ്കീർണ്ണമായ ലോജിക് ഡിബഗ് ചെയ്യുകയോ അല്ലെങ്കിൽ ഒരു മോണോറെപ്പോയിലെ (monorepo) പാക്കേജുകൾ തമ്മിലുള്ള ആശ്രിതത്വം പുനഃക്രമീകരിക്കുകയോ ആണ് നിങ്ങളുടെ ലക്ഷ്യമെങ്കിൽ, ഇതിന്റെ കോൺടെക്സ്റ്റ് ഹാൻഡ്‌ലിംഗ് മികവ് നൽകും.

OpenAI Codex: സ്ട്രക്ചേർഡ് ഓട്ടോമേഷൻ (Structured Automation)

വലിയ തോതിൽ ആവർത്തനക്ഷമമായ ഫലങ്ങൾ (repeatable outcomes) ആവശ്യമുള്ള ടീമുകൾക്ക് വേണ്ടിയാണ് Codex നിർമ്മിച്ചിരിക്കുന്നത്. Claude Code പര്യവേഷണത്തിന് പ്രാധാന്യം നൽകുമ്പോൾ, Codex ഓട്ടോമേഷന് പ്രാധാന്യം നൽകുന്നു. നിലവിലുള്ള ടീം സിസ്റ്റങ്ങളിൽ ഉൾപ്പെടുത്തേണ്ട വ്യക്തമായ ടാസ്ക്കുകൾ ഉള്ളപ്പോൾ ഇത് മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നു: ഒരു പുതിയ മൈക്രോസർവീസിനായുള്ള ബോയിലർപ്ലേറ്റ് (boilerplate) നിർമ്മിക്കുക, നിങ്ങളുടെ പ്രത്യേക മിഡിൽവെയർ സ്റ്റാക്ക് ഉപയോഗിച്ച് CRUD എൻഡ്‌പോയിന്റുകൾ തയ്യാറാക്കുക, അല്ലെങ്കിൽ സേവനങ്ങളുടെ ഒരു കൂട്ടത്തിൽ കോൺഫിഗറേഷൻ ഫയലുകൾ അപ്‌ഡേറ്റ് ചെയ്യുക എന്നിവ ഇതിൽ ഉൾപ്പെടുന്നു.

ഇതിലെ പ്രധാന കാര്യം നിങ്ങൾ കൃത്യത പാലിക്കണം എന്നതാണ്. നിങ്ങളുടെ സ്വീകാര്യത മാനദണ്ഡങ്ങൾ (acceptance criteria) അവ്യക്തമാണെങ്കിൽ, സാങ്കേതികമായി പ്രവർത്തിക്കുമെങ്കിലും നിങ്ങളുടെ കൺവെൻഷനുകൾ ലംഘിക്കുന്ന കോഡ് Codex സന്തോഷത്തോടെ നിർമ്മിക്കും. ഘടന (structure), പേരിടൽ നിയമങ്ങൾ (naming rules), എറർ ഹാൻഡ്‌ലിംഗ് പാറ്റേൺ, ടെസ്റ്റ് പ്രതീക്ഷകൾ എന്നിവ മുൻകൂട്ടി നിർവചിക്കുക. അത്തരം സാഹചര്യങ്ങളിൽ, Codex ഒരു പെയർ പ്രോഗ്രാമറെപ്പോലെയല്ല, മറിച്ച് സ്വാഭാവിക ഭാഷാ നിർദ്ദേശങ്ങൾ മനസ്സിലാക്കുന്ന ഒരു അസംബ്ലി ലൈൻ പോലെയാണ് പ്രവർത്തിക്കുന്നത്. ഇത് ഇന്റേണൽ ടൂളിംഗ്, CI-അടുത്തുള്ള വർക്ക്ഫ്ലോകൾ (CI-adjacent workflows), ക്രിയേറ്റീവ് പ്രോബ്ലം സോൾവിംഗിനേക്കാൾ കൺസിസ്റ്റൻസി (consistency) പ്രധാനമായ സാഹചര്യങ്ങൾ എന്നിവയ്ക്ക് ഇതിനെ ശക്തമാക്കുന്നു.

Gemini CLI: ഓപ്പൺ, സ്ക്രിപ്റ്റബിൾ വർക്ക്ഫ്ലോകൾ (Open, Scriptable Workflows)

Gemini CLI തികച്ചും വ്യത്യസ്തമായ ഒരു രൂപമാണ് സ്വീകരിക്കുന്നത്. ഇത് ഒരു സംഭാഷണാത്മക കോഡിംഗ് അസിസ്റ്റന്റിനേക്കാൾ ഉപരിയായി നിങ്ങളുടെ ടെർമിനൽ എൻവയോൺമെന്റിലെ (terminal environment) വിപുലീകരിക്കാവുന്ന ഒരു ഘടകമാണ് (extensible component). ഇത് ഉയർന്ന രീതിയിൽ സ്ക്രിപ്റ്റബിൾ (scriptable) ആണ്, അതായത് നിങ്ങൾക്ക് ഇതിനെ സ്റ്റാൻഡേർഡ് യുണിക്സ് (Unix) വർക്ക്ഫ്ലോകളിലേക്ക് പൈപ്പ് ചെയ്യാനും, grep, awk, അല്ലെങ്കിൽ jq എന്നിവയുമായി ബന്ധിപ്പിക്കാനും, ചാറ്റ് വിൻഡോകൾക്കിടയിൽ കോപ്പി പേസ്റ്റ് ചെയ്യാതെ തന്നെ കസ്റ്റം ടൂൾചെയിനുകൾ (toolchains) നിർമ്മിക്കാനും കഴിയും.

ടെർമിനലിനെ തങ്ങളുടെ പ്രധാന ഇന്റർഫേസ് ആയി കാണുന്ന എഞ്ചിനീയർമാരെ സംബന്ധിച്ചിടത്തോളം ഈ തുറന്ന സമീപനം വളരെ പ്രധാനമാണ്. സ്റ്റേജഡ് ഡിഫുകളിൽ (staged diffs) നിന്ന് കമിറ്റ് മെസ്സേജുകൾ ഓട്ടോ-ജനറേറ്റ് ചെയ്യാനോ, പഴയ ഷെൽ സ്ക്രിപ്റ്റുകളെ ഇൻലൈൻ വിശദീകരണങ്ങളോടു കൂടി Python-ലേക്ക് മാറ്റാനോ, അല്ലെങ്കിൽ പരാജയപ്പെട്ട ഒരു Kubernetes pod-ൽ നിന്നുള്ള ലോഗ് ഔട്ട്പുട്ട് സംഗ്രഹിക്കാനോ നിങ്ങൾക്ക് ഇത് ഉപയോഗിക്കാം. ഇതിന്റെ നോൺ-ഇന്ററാക്ടീവ് മോഡ് CI പൈപ്പ്‌ലൈനുകൾക്ക് ഏറെ പ്രായോഗികമാണ്. ലഘുവായ കോഡ് മാറ്റങ്ങൾ വരുത്താനോ, സോഴ്സിൽ നിന്ന് ഡോക്യുമെന്റേഷൻ സ്നിപ്പറ്റുകൾ നിർമ്മിക്കാനോ, അല്ലെങ്കിൽ ഒരു Slack ചാനലിൽ പോസ്റ്റ് ചെയ്യുന്നതിന് മുമ്പ് എറർ ഔട്ട്പുട്ട് സാനിറ്റൈസ് ചെയ്യാനോ നിങ്ങൾക്ക് ഇത് ഒരു GitHub Action-ലോ അല്ലെങ്കിൽ ഒരു Makefile സ്റ്റെപ്പിലോ ഉൾപ്പെടുത്താം.

നിങ്ങളുടെ വർക്ക്ഫ്ലോ നിലവിൽ ഷെൽ സ്ക്രിപ്റ്റുകളെയും കോമ്പോസബിൾ ടൂളുകളെയും അടിസ്ഥാനമാക്കിയുള്ളതാണെങ്കിൽ, നിങ്ങളുടെ ശീലങ്ങളിൽ മാറ്റം വരുത്താതെ തന്നെ Gemini CLI അതിലേക്ക് ഇണങ്ങിച്ചേരും.

യഥാർത്ഥത്തിൽ പ്രസക്തമായ ജോലികൾ

AI ഏജന്റുകളെ സ്വീകരിക്കുന്ന നിരക്കുകളെക്കുറിച്ചുള്ള ഗവേഷണങ്ങൾ പരിചയസമ്പന്നരായ എഞ്ചിനീയർമാരെ അത്ഭുതപ്പെടുത്താത്ത ഒരു പാറ്റേൺ വെളിപ്പെടുത്തുന്നു: പുതിയ ഫീച്ചറുകൾ നിർമ്മിക്കുന്നതിനേക്കാൾ എത്രയോ മടങ്ങ് തവണ ഡോക്യുമെന്റേഷൻ മാറ്റങ്ങൾ അംഗീകരിക്കപ്പെടുന്നു. ഡോക്സ്ട്രിംഗുകൾ (docstrings) പുതുക്കുന്നതോ, കമന്റുകൾ തിരുത്തുന്നതോ, അല്ലെങ്കിൽ ഒരു README വിപുലീകരിക്കുന്നതോ ഒരു ഏജന്റിന്റെ കരുത്തായ കാര്യങ്ങളാണ്; കാരണം ഇതിന്റെ സന്ദർഭം (context) പരിമിതമാണ്, കൂടാതെ റിപ്പോസിറ്ററിയിൽ അതിന്റെ ശൈലി നേരത്തെ തന്നെ നിശ്ചയിക്കപ്പെട്ടതുമാണ്. എന്നാൽ പുതിയ ഫീച്ചറുകൾ നിർമ്മിക്കുന്നതിന് പുതിയ കണ്ടെത്തലുകളും, എഡ്ജ് കേസുകൾ (edge cases) പ്രവചിക്കാനുള്ള കഴിവും, എവിടെയും രേഖപ്പെടുത്തിയിട്ടില്ലാത്ത ഉപയോക്താവിന്റെ ഉദ്ദേശ്യങ്ങൾ മനസ്സിലാക്കാനുള്ള കഴിവും ആവശ്യമാണ്. ഇവ രണ്ടിനും ഒരേപോലെ വിജയിക്കുന്ന ഒരു ടൂളും നിലവിലില്ല, കാരണം ഇവയുടെ ആവശ്യകതകൾ അടിസ്ഥാനപരമായി വ്യത്യസ്തമാണ്.

ഇതിനർത്ഥം നിങ്ങളുടെ മൂല്യനിർണ്ണയം നിങ്ങൾ ചെയ്യുന്ന യഥാർത്ഥ ജോലികളുമായി പൊരുത്തപ്പെടണം എന്നാണ്. പരിമിതമായ ജോലികളിൽ മാത്രം നിങ്ങൾ പരീക്ഷിക്കുകയാണെങ്കിൽ, എല്ലാ ടൂളുകളും ഒരു പ്രതിഭയെപ്പോലെ തോന്നും.

ഏജന്റുകൾ യഥാർത്ഥത്തിൽ പരാജയപ്പെടുന്നത് എവിടെയാണ്

ഭൂരിഭാഗം പരാജയങ്ങളും സംഭവിക്കുന്നത് മോഡൽ ലെയറിലല്ല, മറിച്ച് എക്സിക്യൂഷൻ ലെയറിലാണ്. കോഡ് സിന്റാക്റ്റിക്കൽ ആയി കൃത്യമായിരിക്കാം, എങ്കിലും ഒരു ഇന്റേണൽ API-യിലേക്കുള്ള നെറ്റ്‌വർക്ക് ടൈമൗട്ട് മൂലമോ, macOS-ൽ പ്രവർത്തിക്കുകയും GNU/Linux-ൽ പരാജയപ്പെടുകയും ചെയ്യുന്ന ഒരു sed കമാൻഡ് മൂലമോ, അല്ലെങ്കിൽ ഏജന്റിന് തിരിച്ചറിയാൻ കഴിയാത്ത ഒരു പെർമിഷൻ ബൗണ്ടർ മൂലമോ ഏജന്റ് പരാജയപ്പെട്ടേക്കാം. ഏജന്റുകൾ താഴെ പറയുന്ന സാഹചര്യങ്ങളിൽ ബുദ്ധിമുട്ടുന്നു:

  • ഒരു API താൽക്കാലികമായ പരാജയം കാണിക്കുകയും, ലൂപ്പ് പിൻവാങ്ങുന്നതിന് (backing off) പകരം കറങ്ങിക്കൊണ്ടിരിക്കുകയും ചെയ്യുമ്പോൾ.
  • ഒരു ടൂൾ നൽകുന്ന എറർ സ്ട്രീം ഏജന്റിന് തെറ്റായി വ്യാഖ്യാനിക്കാൻ കഴിയുന്ന രീതിയിലാണെങ്കിൽ.
  • ഒരു കമാൻഡിന് ഏജന്റിന് ലഭ്യമല്ലാത്ത sudo ആക്സസ് ആവശ്യമായി വരികയും, അത് നിശബ്ദമായി ഹാങ്ങ് ആകുകയും ചെയ്യുമ്പോൾ.
  • ജനറേറ്റ് ചെയ്ത ടെസ്റ്റുകൾ ഐസൊലേഷനിൽ വിജയിക്കുകയും എന്നാൽ യഥാർത്ഥ ഡാറ്റാബേസിനൊപ്പം പ്രവർത്തിക്കുമ്പോൾ പരാജയപ്പെടുകയും ചെയ്യുമ്പോൾ (ഇവിടെ ഹാർനസ് കണക്ഷൻ സ്ട്രിംഗ് ശരിയായി നൽകിയിട്ടില്ലാത്തതുകൊണ്ടായിരിക്കാം).

ഇവ ഇന്റഗ്രേഷൻ പ്രശ്നങ്ങളാണ്. എററുകൾ എങ്ങനെ വായിക്കണം, പരിധികൾ എങ്ങനെ ബഹുമാനിക്കണം, തെറ്റായ രീതിയിൽ മുന്നോട്ട് പോകുന്നതിന് പകരം എങ്ങനെ മനുഷ്യന്റെ ഇടപെടൽ ആവശ്യപ്പെടണം എന്ന് അറിയുന്ന ഒരു ഹാർനസ് ഇതിന് ആവശ്യമാണ്.

ഈ ടൂളുകളെ യഥാർത്ഥത്തിൽ എങ്ങനെ വിലയിരുത്താം

build a landing page പോലുള്ള പ്രോംപ്റ്റുകൾ ഉപയോഗിച്ച് ഏജന്റുകളെ പരീക്ഷിക്കുന്നത് നിർത്തുക. അത് അളക്കുന്നത് വിഷ്വൽ ഔട്ട്പുട്ടിനെയാണ്, എഞ്ചിനീയറിംഗ് കഴിവിനെയല്ല. പകരം, ഓരോ ടൂളിനെയും യഥാർത്ഥ ജോലികളുടെ ഒരു പരീക്ഷണത്തിന് വിധേയമാക്കുക:

  • സ്റ്റാക്കിന്റെ വിവിധ ലെയറുകളിൽ വ്യാപിച്ചു കിടക്കുന്ന ഒരു ബഗ് പരിഹരിക്കുക, যেখানে അതിന്റെ യഥാർത്ഥ കാരണവും ലക്ഷണവും വ്യത്യസ്ത ലെയറുകളിലാകാം.
  • ബാഹ്യമായ പെരുമാറ്റത്തിൽ മാറ്റം വരുത്താതെ തന്നെ ഒരു ഡിപെൻഡൻസി നീക്കം ചെയ്യുന്നതിനായി ഒരു മോഡ്യൂൾ റീഫാക്ടർ ചെയ്യുക, തുടർന്ന് ടെസ്റ്റ് സ്യൂട്ട് ഇപ്പോഴും വിജയിക്കുന്നുണ്ടെന്ന് ഉറപ്പുവരുത്തുക.
  • ഒരു തേർഡ് പാർട്ടി API അതിന്റെ റെസ്പോൺസ് രൂപം മാറ്റുന്നതിന് ശേഷം എല്ലാ മോക്ക് ഫിക്സ്ചറുകളും (mock fixtures), ടൈപ്പ് ഡെഫനിഷനുകളും, ഇന്റഗ്രേഷൻ ടെസ്റ്റുകളും പുതുക്കുക.
  • വേർഷൻ കോൺഫ്ലിക്റ്റ് കാരണം തകരാറിലായ ഒരു ബിൽഡ് കണ്ടെത്തുകയും, യഥാർത്ഥത്തിൽ കംപൈൽ ചെയ്യാൻ കഴിയുന്ന ഒരു പരിഹാരം നിർദ്ദേശിക്കുകയും ചെയ്യുക.

വെറും തോന്നലുകളല്ല (vibes), കൃത്യമായ അളവുകോലുകൾ (metrics) പിന്തുടരുക. പൂർത്തീകരണ നിരക്ക് (completion rate) കണക്കാക്കുക: ഏജന്റ് ജോലി പൂർത്തിയാക്കിയോ അതോ പകുതിയിൽ വെച്ച് നിർത്തിയോ? കോഡ് മെർജ് ചെയ്യാൻ പാകമാകുന്നതിന് മുമ്പ് എത്ര തവണ മനുഷ്യന്റെ തിരുത്തലുകൾ ആവശ്യമായി വന്നു എന്ന് രേഖപ്പെടുത്തുക. ടെസ്റ്റുകൾ ആദ്യ ശ്രമത്തിൽ തന്നെ വിജയിച്ചോ അതോ പലതവണ പാച്ച് വർക്കുകൾ ആവശ്യമായി വന്നോ എന്ന് പരിശോധിക്കുക. ഒരു സീനിയർ എഞ്ചിനീയർ ഔട്ട്പുട്ട് പരിശോധിക്കാൻ എത്ര സമയം ചെലവഴിച്ചു എന്ന് അളക്കുക. ഇരുനൂറ് വരികൾ തെറ്റില്ലാത്ത കോഡ് എഴുതുന്ന ഒരു ടൂൾ, അത് തൊടാൻ പാടില്ലാത്ത ഫയലുകളിൽ തൊട്ടിട്ടില്ല എന്ന് ഉറപ്പുവരുത്താൻ നിങ്ങൾ ഒരു മണിക്കൂർ ചെലവഴിക്കേണ്ടി വന്നാൽ അത് ഉപയോഗശൂന്യമാണ്.

യഥാർത്ഥ പാഠം

ഏറ്റവും കൂടുതൽ അക്ഷരങ്ങൾ നിർമ്മിക്കുന്നതോ ആകർഷകമായ ഡെമോ കാണിക്കുന്നതോ ആയ ടൂളല്ല വിജയിക്കുന്നത്. മറിച്ച്, ഏറ്റവും കുറഞ്ഞ റിവ്യൂ തടസ്സങ്ങളോടെ (review friction) മെർജ് ചെയ്യാൻ കഴിയുന്ന കോഡ് നൽകുന്ന ടൂളാണ് വിജയിക്കുന്നത്. ഈ മേഖലയിലെ മത്സരം മോഡലിന്റെ ബുദ്ധിശക്തിയിൽ നിന്ന് വിശ്വസനീയമായ എഞ്ചിനീയറിംഗ് ഹാർനസുകളിലേക്ക് മാറിക്കൊണ്ടിരിക്കുകയാണ്. നിങ്ങളുടെ യഥാർത്ഥ ജോലിയുടെ സ്വഭാവത്തിന് അനുയോജ്യമായ സിസ്റ്റം ഡിസൈനുള്ള ഏജന്റിനെ തിരഞ്ഞെടുക്കുക: ആർക്കിടെക്ചറൽ സർജറികൾക്കായി ആഴത്തിലുള്ള യുക്തി (deep reasoning), ടീം ഓട്ടോമേഷനായി ഘടനാപരമായ കൃത്യത (structured precision), അല്ലെങ്കിൽ കസ്റ്റം വർക്ക്ഫ്ലോകൾക്കായി ടെർമിനൽ എക്സ്റ്റൻസിബിലിറ്റി (terminal extensibility). എന്നിട്ട് അവയെ ലളിതമായ പ്രശ്നങ്ങളിൽ അല്ല, മറിച്ച് യഥാർത്ഥ പരാജയങ്ങളിൽ പരീക്ഷിക്കുക.

ഈ വിശകലനം this detailed breakdown-ലെ നേരിട്ടുള്ള താരതമ്യങ്ങളെയും ഏജന്റ് പെരുമാറ്റ ഗവേഷണങ്ങളെയും അടിസ്ഥാനമാക്കിയുള്ളതാണ്.

എഞ്ചിനീയറിംഗ് ടൂളുകളെക്കുറിച്ചും AI വർക്ക്ഫ്ലോകളെക്കുറിച്ചുമുള്ള കൂടുതൽ ചർച്ചകൾക്കായി, GyaanSetu learning community-ൽ ചേരുക.