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

ഇതൊരു സാങ്കേതിക പരിമിതിയല്ല. ഇതൊരു വിസിബിലിറ്റി (visibility) പ്രശ്നമാണ്.

ഒരു ഏജന്റ് മൂന്ന് വരി പ്രൊഡക്ഷൻ കോഡ് എഴുതുമ്പോൾ, അത് മൂന്ന് ഫയലുകൾ വായിച്ച് ടെസ്റ്റുകൾ റൺ ചെയ്തതാകാം. അല്ലെങ്കിൽ അത് ബന്ധമില്ലാത്ത നാൽപ്പതോളം ഫയലുകളിൽ മാറ്റം വരുത്തിയിരിക്കാം, പരാജയപ്പെട്ട ഡസൻ കണക്കിന് കമാൻഡുകൾ പ്രവർത്തിപ്പിച്ചിരിക്കാം, ഡിപെൻഡൻസി ഇൻസ്റ്റാൾ ചെയ്തത് തകരാറിലായതിനാൽ നിങ്ങളുടെ ടെസ്റ്റ് സ്യൂട്ട് ഒഴിവാക്കിയിരിക്കാം, കൂടാതെ ഇതിനുള്ള സേവനത്തിന് നിങ്ങളിൽ നിന്ന് പണം ഈടാക്കിയിരിക്കാം. രണ്ട് സാഹചര്യത്തിലും diff ഒരുപോലെയായിരിക്കും. ആ പ്രക്രിയയുടെ ഒരു റെക്കോർഡ് ഇല്ലാതെ, ഫലത്തിന്റെ ഗുണനിലവാരത്തെക്കുറിച്ച് നിങ്ങൾക്ക് ഊഹിക്കしか മാത്രമേ കഴിയൂ.

എന്തുകൊണ്ടാണ് ചാറ്റ് ലോഗുകൾ (Chat Logs) രസീതുകൾ (Receipts) അല്ലാത്തത്

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

മനുഷ്യന്റെ ശ്രദ്ധ പരിമിതമാണ്. ഒരു ഏജന്റിന്റെ ലക്ഷ്യം ബുദ്ധിപരമായ അധ്വാനം കുറയ്ക്കുക എന്നതാണ്, അല്ലാതെ കൂടുതൽ ഹോംവർക്കുകൾ നൽകുകയല്ല. ഒരു ട്രാൻസ്ക്രിപ്റ്റ് റിവ്യൂവർ ഒരു ഡിറ്റക്റ്റീവ് ആകാൻ ആവശ്യപ്പെടുന്നു. എന്നാൽ ഒരു രസീത് ഒറ്റനോട്ടത്തിൽ തന്നെ ഉത്തരം നൽകുന്നു.

ഉപയോഗപ്രദമായ ഒരു രസീത് എന്നത് പ്രായോഗികമായ ഒരു സംഗ്രഹമാണ് (summary). ഏജന്റിനോട് എന്താണ് ചെയ്യാൻ ആവശ്യപ്പെട്ടത്, അത് യഥാർത്ഥത്തിൽ എന്താണ് ചെയ്തത്, അത് എങ്ങനെ അതിന്റെ നിഗമനത്തിൽ എത്തിച്ചേർന്നു എന്നിവ അത് നിങ്ങളോട് പറയുന്നു. അത് പരാജയങ്ങളെ മറച്ചുവെക്കുന്നില്ല, പകരം അവയെ എടുത്തു കാണിക്കുന്നു.

ഒരു നല്ല രസീത് എങ്ങനെയായിരിക്കണം

ഒരു റിവ്യൂ ചെയ്യാവുന്ന രസീത്, കൂടുതൽ തിരയലുകൾ ഇല്ലാതെ തന്നെ താഴെ പറയുന്ന ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകണം:

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

ഈ ഫോർമാറ്റ് റിവ്യൂവിനെ ഒരു പുരാവസ്തു ഗവേഷണം പോലെയുള്ള കഠിനമായ പ്രക്രിയയിൽ നിന്ന് വേഗത്തിലുള്ള ഒരു പരിശോധനയാക്കി മാറ്റുന്നു. ഒരു സീനിയർ എഞ്ചിനീയർക്ക് രസീത് നോക്കി ഒരു മിനിറ്റിൽ താഴെ സമയം കൊണ്ട് "ഇത് ശരിയാണ്" എന്നോ "ഇതിൽ എന്തോ സംശയം ഉണ്ട്" എന്നോ പറയാൻ കഴിയണം.

ചരിത്രം മാത്രമല്ല, ഫൂട്ട്പ്രിന്റും (Footprint) വായിക്കുക

ഒരു ഏജന്റ് റണ്ണിന്റെ ഫൂട്ട്പ്രിന്റ് ജോലിയുടെ സ്വഭാവം കാണിക്കുന്നു. ഏജന്റ് ടിക്കറ്റിന്റെ പരിധിക്കുള്ളിൽ തന്നെ നിന്നോ? അതോ ആരും ആവശ്യപ്പെടാത്ത കാര്യങ്ങൾ മാറ്റാൻ ബന്ധമില്ലാത്ത മോഡ്യൂളുകളിലേക്ക് കടന്നോ? "Files Read" എന്നതിനൊപ്പം "Files Edited" കൂടി നൽകുന്ന ഒരു രസീത് ഇത് വ്യക്തമാക്കുന്നു.

ഫൂട്ട്പ്രിന്റ് ആവർത്തനങ്ങളും വെളിപ്പെടുത്തുന്നു. ഒരേ തെറ്റിൽ തന്നെ വീണ്ടും വീണ്ടും വീഴുന്ന ഒരു ഏജന്റ്—ഒരേ കോൺഫിഗറേഷൻ ഫയൽ മൂന്ന് തവണ വായിക്കുകയോ, പരാജയപ്പെട്ട ടെസ്റ്റ് വീണ്ടും വീണ്ടും റൺ ചെയ്യുകയോ ചെയ്യുന്നത്—കമ്പ്യൂട്ട് പവർക്കും കോൺടെക്സ്റ്റ് വിൻഡോയ്ക്കും (context window) വലിയ നഷ്ടമുണ്ടാക്കുന്നു. ആ രീതി രസീത്തിൽ കാണണം. ഒരു മൈഗ്രേഷൻ സ്ക്രിപ്റ്റ് റൺ ചെയ്യാൻ ഏജന്റിന് ഒൻപത് ശ്രമങ്ങൾ വേണ്ടിവന്നുവെങ്കിൽ, രസീതിൽ അത് പറയണം. ഈ വിവരം നിങ്ങൾ ഔട്ട്പുട്ടിനെ എങ്ങനെ വിലയിരുത്തുന്നു എന്നതിനെ മാറ്റുന്നു. ബ്രൂട്ട്-ഫോഴ്സ് (brute-force) രീതിയിലൂടെ വന്ന ഒരു "ശരിയായ" diff, കൃത്യമായ രീതിയിൽ വന്ന ഒരു ശരിയായ diff-ന് തുല്യമല്ല.

മോശം ഡിസൈനിന്റെ മറഞ്ഞിരിക്കുന്ന ചിലവ്

ചിലവ് എന്നത് ടോക്കണിന് നൽകുന്ന വില മാത്രമല്ല. മോശമായി രൂപകൽപ്പന ചെയ്ത ഒരു വർക്ക്ഫ്ലോ, ഒരു ക്യാരക്ടർ പോലും ജനറേറ്റ് ചെയ്യുന്നതിന് മുമ്പ് തന്നെ ഏജന്റിനെ ചെലവേറിയതാക്കുന്നു. അമിതമായ ടൂൾ സ്കീമകൾ, അനാവശ്യമായ ഫയൽ ഇൻഡക്സിംഗ്, അമിതമായി വിശാലമായ സിസ്റ്റം പ്രോംപ്റ്റുകൾ എന്നിവ കോൺടെക്സ്റ്റ് വിൻഡോയുടെ വലുപ്പം വർദ്ധിപ്പിക്കുന്നു. രസീത് ഈ അധികച്ചെലവ് വെളിപ്പെടുത്തണം.

ജനറേഷൻ ചിലവ് കുറയുകയും എന്നാൽ റിവ്യൂ പ്രയാസകരമാവുകയും ചെയ്താൽ, നിങ്ങൾക്ക് ഒന്നും നേടാനില്ല. നിങ്ങൾ പ്രശ്നത്തിന്റെ കേന്ദ്രം മാറ്റുക മാത്രമാണ് ചെയ്യുന്നത്. ഒരു ടീമിലെ ഏറ്റവും കുറഞ്ഞ വിഭവമായത് സാധാരണയായി എഞ്ചിനീയർമാരുടെ സമയമാണ്. ഒരു പുൾ റിക്വസ്റ്റിൽ (pull request) മുപ്പത് മിനിറ്റ് റിവ്യൂ സമയം അധികം എടുക്കുന്നതിലൂടെ അഞ്ച് ഡോളർ API ചിലവ് ലാഭിക്കുന്നത് മോശം ഇടപാടാണ്. ഈ ഇടപാടിനെ നേരിട്ട് ഓഡിറ്റ് ചെയ്യാൻ രസീത് നിങ്ങളെ സഹായിക്കുന്നു.

സത്യസന്ധത ഒരു ഫീച്ചറാണ്

ആവശ്യമായ ഘട്ടങ്ങളിൽ ഒരു ഉപയോഗപ്രദമായ രസീത് അസ്വസ്ഥതയുണ്ടാക്കുന്നതാകണം. ഏജന്റ് കാര്യക്ഷമതയില്ലാത്തതാണെന്ന് കാണിക്കുന്ന വസ്തുതകൾ അത് റിപ്പോർട്ട് ചെയ്യണം, കാരണം ആ സത്യസന്ധത അടുത്ത മനുഷ്യ തീരുമാനങ്ങൾ വേഗത്തിലും മികച്ചതായും എടുക്കാൻ സഹായിക്കുന്നു.

ഉദാഹരണങ്ങൾ പ്രധാനമാണ്:

  • "Read 37 files for a one-line change."
  • "Skipped tests because npm install failed with a peer dependency conflict."
  • "Edited utils.py outside the requested scope to fix an import the agent introduced."
  • "Ran the linter 4 times; first three failed due to path misconfiguration."

These are not bugs in the receipt. They are signals. They tell the reviewer where to focus skepticism. They also tell the platform team where the workflow itself needs tightening.

Smaller Runs, Clearer Oversight

There is a natural temptation to let agents run wild across large surfaces. One giant prompt to refactor an entire service feels fast. It is not. It creates an unreviewable lump of work. Your afternoon disappears into tracing which of eighty changed files were intentional.

Small, inspectable runs are better. Define clear boundaries for the task. Separate the list of files the agent may read from the list it may write. Capture a history of failed commands so the dead ends are visible. Flag skipped verifications explicitly. Note every external tool use, from search APIs to test runners.

The goal is not total autonomy. Total autonomy that no human can verify is just automation with liability. The real goal is reviewability. Every agent output should be easy to approve or easy to reject. There should be no ambiguous middle ground where you accept code because you are too tired to investigate.

The Test for Any Coding Agent

Before adopting any agent or platform, ask one question: Can it leave enough evidence for a human to approve the next step confidently?

If the answer is yes, the tool fits into a professional workflow. If the answer is no, you are not buying productivity. You are buying a mystery that occasionally compiles. That is fine for a weekend side project. It is unacceptable for production engineering.

Teams that treat agent outputs as unexamined gifts will eventually ship a subtle bug introduced by an undetected scope creep. The diff will look innocent. The receipt would have told the truth.

Require receipts. Design for review. Trust is not a strategy. Evidence is.

For more hands-on discussions around AI tooling and developer workflows, you can join the community at GyaanSetu on Telegram.