പ്രോംപ്റ്റുകൾ നിർദ്ദേശങ്ങളാണ്. ഹുക്കുകൾ (Hooks) കർശനമായ നിയന്ത്രണങ്ങളാണ്.

മാസങ്ങളോളം, ഞാൻ Claude Code-നെ വ്യക്തമായ നിയമങ്ങൾ ആവശ്യമായ ഒരു ജൂനിയർ ഡെവലപ്പറെപ്പോലെയാണ് കണ്ടിരുന്നത്. എന്റെ പ്രോജക്റ്റ് നിർദ്ദേശങ്ങൾ വളരെ വ്യക്തമായിരുന്നു: ഒരിക്കലും force-push ചെയ്യരുത്, ബ്രാഞ്ചുകൾ ഡിലീറ്റ് ചെയ്യരുത്, വിനാശകരമായ കമാൻഡുകൾ (destructive commands) പ്രവർത്തിപ്പിക്കരുത്. മിക്ക വൈകുന്നേരങ്ങളിലും അത് ശരിയായി നടന്നു. ഏജന്റ് ടെസ്റ്റുകൾ എഴുതി, ഫംഗ്ഷനുകൾ റീഫാക്ടർ ചെയ്തു, ഗിറ്റ് ഹിസ്റ്ററിയിൽ (git history) ഇടപെടാതെ കാര്യങ്ങൾ ചെയ്തു. എന്നാൽ ഒരു rebase പരാജയപ്പെട്ടതോടെ എല്ലാം മാറിമറിഞ്ഞു.

കോൺടെക്സ്റ്റ് വിൻഡോ (context window) ഗിറ്റ് എറർ ഔട്ട്പുട്ടുകൾ കൊണ്ട് നിറഞ്ഞു. കോൺഫ്ലിക്റ്റ് മാർക്കറുകൾ, ഡിറ്റാച്ച്ഡ് HEAD മെസ്സേജുകൾ, ബ്രാഞ്ച് ഡൈവേർജൻസ് മുന്നറിയിപ്പുകൾ എന്നിവ ഓരോ ടോക്കണുകളായി വന്നു കൊണ്ടിരുന്നു. ആ ബഹളത്തിനിടയിൽ, force-push ഒഴിവാക്കണമെന്ന എന്റെ മര്യാദയുള്ള നിർദ്ദേശം മറന്നുപോയി. മോഡലിനെ സംബന്ധിച്ചിടത്തോളം, ആ തത്സമയ എറർ സ്ട്രീം ആയിരുന്നു ഏറ്റവും പ്രധാനപ്പെട്ട വിവരം. സ്റ്റാറ്റിസ്റ്റിക്കൽ അറ്റൻഷൻ (statistical attention) പോളിസിയെക്കാൾ മുൻതൂക്കം നേടി. ഏജന്റ് രണ്ട് മണിക്കൂർ നീണ്ട അൺകമിറ്റഡ് (uncommitted) ലോക്കൽ മാറ്റങ്ങൾ ഇല്ലാതാക്കുന്ന ഒരു കമാൻഡ് പ്രവർത്തിപ്പിച്ചു. അത് മനഃപൂർവ്വമല്ലായിരുന്നു; അത് ശ്രദ്ധക്കുറവ് മൂലമായിരുന്നു. ആ വ്യത്യാസം പ്രധാനമാണ്. ഒരു LLM വിദ്വേഷം മൂലമല്ല നിയമങ്ങൾ ലംഘിക്കുന്നത്. കോൺടെക്സ്റ്റ് വിൻഡോയിലെ കൂടുതൽ ശക്തമായ ഒരു പാറ്റേൺ നേരത്തെയുള്ള നിർദ്ദേശങ്ങളെ താൽക്കാലികമായി മറികടക്കുമ്പോഴാണ് അത് നിയമങ്ങൾ ലംഘിക്കുന്നത്.

ആ സംഭവം ഏജന്റ് സുരക്ഷയെ (agent safety) കുറിച്ചുള്ള എന്റെ ചിന്താഗതി മാറ്റിമറിച്ചു. തൊണ്ണൂറ്റൊൻപത് ശതമാനം സമയവും പ്രവർത്തിക്കുന്ന ഒരു ഗാർഡ്‌റെയിൽ (guardrail) ഒരു അപകടസാധ്യതയാണ്. പരാജയപ്പെടുമ്പോൾ നിങ്ങൾക്ക് സമയം, പണം അല്ലെങ്കിൽ പ്രൊഡക്ഷൻ ഡാറ്റ നഷ്ടപ്പെടാൻ സാധ്യതയുണ്ടെങ്കിൽ, അത് പ്രോംപ്റ്റിനുള്ളിൽ മാത്രം വിടാൻ കഴിയില്ല. മോഡലിന്റെ റീസണിംഗ് ലൂപ്പിന് (reasoning loop) പുറത്ത് ശക്തമായ നിയന്ത്രണങ്ങൾ ആവശ്യമാണ്.

Claude Code ഹുക്കുകൾ (hooks) കൃത്യമായി ഈ പ്രശ്നമാണ് പരിഹരിക്കുന്നത്. ടൂൾ കോളുകളെ (tool calls) മൂന്ന് പ്രത്യേക ഘട്ടങ്ങളിൽ തടഞ്ഞുനിർത്തുന്ന ചെറിയ സ്ക്രിപ്റ്റുകളാണ് ഇവ: ഒരു ടൂൾ പ്രവർത്തിക്കുന്നതിന് മുമ്പ് (PreToolUse), ഒരു ടൂൾ പൂർത്തിയായ ശേഷം (PostToolUse), കൂടാതെ ഏജന്റ് ജോലി കഴിഞ്ഞു എന്ന് തീരുമാനിക്കുമ്പോൾ (Stop). ഇവ എക്സ്റ്റേണൽ കോഡായി പ്രവർത്തിക്കുന്നതിനാൽ, മോഡലിന്റെ മെമ്മറിയിലോ മൂഡിനെയോ കോൺടെക്സ്റ്റ് സമ്മർദ്ദത്തെയോ ഇവ ആശ്രയിക്കുന്നില്ല. നിങ്ങൾ നൽകിയ എല്ലാ നിർദ്ദേശങ്ങളും മോഡൽ മറന്നേക്കാം; എന്നാൽ ഹുക്ക് ഇപ്പോഴും 'ഇല്ല' എന്ന് പറയും.

ആ നഷ്ടപ്പെട്ട വൈകുന്നേരത്തിന് ശേഷം ഞാൻ നിർമ്മിച്ച സംവിധാനം ഇതാ.

ദി ഗാർഡ് ഹുക്ക്: നാശത്തിന് മുമ്പ് തടയുക

എന്റെ PreToolUse ഹുക്ക് ഓരോ Bash കമാൻഡും ഷെൽ പ്രവർത്തിപ്പിക്കുന്നതിന് മുമ്പ് പരിശോധിക്കുന്നു. വിനാശകരമായ പാറ്റേണുകളുടെ ഒരു കർശനമായ ഡെനി ലിസ്റ്റ് (denylist) ഞാൻ സൂക്ഷിക്കുന്നു. കമാൻഡ് സ്ട്രിംഗ് അപകടകരമായ ഒന്നാണെങ്കിൽ, ഹുക്ക് പ്രവർത്തനം നിർത്തി ഏജന്റിന് നേരിട്ട് ഒരു എറർ തിരികെ നൽകുന്നു.

ഞാൻ ബ്ലോക്ക് ചെയ്യുന്ന പാറ്റേണുകൾ ലളിതവും വ്യക്തവുമാണ്:

  • git push --force അല്ലെങ്കിൽ ഞാൻ ഇതുവരെ വിശ്വസിക്കാത്ത ഏതെങ്കിലും force-with-lease വേരിയന്റുകൾ
  • git reset --hard
  • rm -rf

ഇതൊരു സങ്കീർണ്ണമായ സെക്യൂരിറ്റി റിസർച്ചല്ല. ഇതൊരു സീറ്റ് ബെൽറ്റ് മാത്രമാണ്. എന്നാൽ ബ്ലോക്ക് ചെയ്തതിന് ശേഷം എന്ത് സംഭവിക്കുന്നു എന്നതാണ് നിർണ്ണായകമായ കാര്യം.

ഞാൻ ഒരിക്കലും വെറുതെ “Blocked” എന്ന് മാത്രം മറുപടി നൽകാറില്ല. ഒരു നിരാകരണം മാത്രം നൽകുന്നത് ഏജന്റിനെ ആശയക്കുഴപ്പത്തിലാക്കുകയും, അതേ വിനാശകരമായ കമാൻഡിന്റെ വ്യത്യസ്ത രൂപങ്ങൾ പരീക്ഷിക്കുന്ന ഒരു ലൂപ്പിൽ അതിനെ കുടുക്കുകയും ചെയ്തേക്കാം. പകരം, എറർ മെസ്സേജിൽ ഒരു രക്ഷപെടാനുള്ള മാർഗ്ഗം ഉൾപ്പെടുത്തുന്നു. ഒരു ഹാർഡ് റീസെറ്റ് (hard reset) ഹുക്ക് കണ്ടെത്തുമ്പോൾ, അത് ഏജന്റിനോട് പറയുന്നു: “അൺകമിറ്റഡ് വർക്കുകൾ സംരക്ഷിക്കുന്നതിനായി ഈ കമാൻഡ് ബ്ലോക്ക് ചെയ്തിരിക്കുന്നു. ആദ്യം ഒരു ചെക്ക്പോയിന്റ് കമ്മിറ്റ് ചെയ്യുക, തുടർന്ന് വീണ്ടും പരിശോധിക്കുക.” ആ ഒരു അധിക വാചകം ഏജന്റിന്റെ പെരുമാറ്റത്തെ പൂർണ്ണമായും മാറ്റുന്നു. അത് നാശമുണ്ടാക്കാൻ ശ്രമിക്കുന്നതിന് പകരം സുരക്ഷ ഉറപ്പാക്കാൻ ശ്രമിക്കുന്നു. ഹുക്ക് എന്നത് വെറുമൊരു മതിലല്ല; അത് ഒരു ട്രാഫിക് കൺട്രോൾ ആണ്.

ഷെൽ കമാൻഡുകൾക്കായി ഞാൻ അലൗ ലിസ്റ്റിനേക്കാൾ (allowlist) ഡെനി ലിസ്റ്റിനാണ് (denylist) മുൻഗണന നൽകിയത്. ആദ്യം, സുരക്ഷിതമായ ചില git സബ്കമാൻഡുകൾ മാത്രം അനുവദിക്കണമെന്ന് ഞാൻ കരുതിയിരുന്നു. എന്നാൽ അത് പെട്ടെന്ന് പരാജയപ്പെട്ടു. ഏജന്റുകൾ വളരെ സർഗ്ഗാത്മകമായി കാര്യങ്ങൾ ചെയ്യുന്നു. സ്റ്റേറ്റ് പരിശോധിക്കാൻ അവർ git stash push -m "wip" അല്ലെങ്കിൽ git branch --show-current പോലുള്ള നിയമപരമായ എന്നാൽ പ്രതീക്ഷിക്കാത്ത കമാൻഡുകൾ ഉപയോഗിക്കാറുണ്ട്. മോഡൽ ലിസ്റ്റിൽ ഇല്ലാത്ത ഒരു സാധുവായ കമാൻഡ് ഉപയോഗിക്കുമ്പോൾ അലൗ ലിസ്റ്റ് സാധാരണ വർക്ക്ഫ്ലോയെ തടസ്സപ്പെടുത്തും. എന്നാൽ യഥാർത്ഥത്തിൽ വിനാശകരമായ പാറ്റേണുകളുടെ ഒരു ചെറിയ ഡെനി ലിസ്റ്റ് ഉപയോഗിക്കുന്നത്, അതിരുകൾ സംരക്ഷിക്കുന്നതോടൊപ്പം ഏജന്റിന് പ്രവർത്തിക്കാൻ ആവശ്യമായ സ്വാതന്ത്ര്യം നൽകുന്നു.

ദി ഫോർമാറ്റർ ഹുക്ക്: ജോലികൾ ഓട്ടോമേറ്റ് ചെയ്യുക

"ഒരു ഫയൽ എഡിറ്റ് ചെയ്ത ശേഷം എപ്പോഴും ഫോർമാറ്റർ റൺ ചെയ്യുക" എന്ന് ഏജന്റിനോട് പറയാൻ ഞാൻ പ്രോംപ്റ്റ് ടോക്കണുകൾ പാഴാക്കുമായിരുന്നു. പകുതി സമയത്ത് അത് മറന്നുപോയി. ബാക്കി പകുതി സമയത്ത്, ഫോർമാറ്റ് ചെയ്യണോ എന്ന് ചോദിച്ചുകൊണ്ട് അത് സമയം കളയുകയും, ഒരേ ഉത്തരമുള്ള ഒരു കാര്യത്തിനായി ഒരു ടൂൾ കോൾ പാഴാക്കുകയും ചെയ്തു.

ഇപ്പോൾ ഞാൻ അത് ഒരു PostToolUse ഹുക്ക് ഉപയോഗിച്ച് കൈകാര്യം ചെയ്യുന്നു. ഏജന്റ് ഒരു ഫയൽ എഡിറ്റ് ചെയ്ത ശേഷം, ഹുക്ക് ആ ഫയലിന്റെ എക്സ്റ്റൻഷൻ പരിശോധിക്കുന്നു. അത് Python ആണെങ്കിൽ, അത് Ruff റൺ ചെയ്യുന്നു. JavaScript അല്ലെങ്കിൽ TypeScript ആണെങ്കിൽ, അത് Prettier റൺ ചെയ്യുന്നു. Go ആണെങ്കിൽ, അത് gofmt റൺ ചെയ്യുന്നു. ഫോർമാറ്റർ ഉണ്ടെന്ന് ഏജന്റ് അറിയേണ്ടതില്ല. അതിന് അതിന്റെ ആവശ്യമുമില്ല.

ഇത് പ്രോംപ്റ്റിൽ നിന്ന് മാറ്റിയത് രണ്ട് ഫലങ്ങൾ ഉണ്ടാക്കി. ഒന്നാമതായി, മോഡലിന് അമിത ജോലി നൽകാതെ തന്നെ കോഡ് എപ്പോഴും വൃത്തിയുള്ളതായി നിലനിർത്താൻ സാധിക്കുന്നു. രണ്ടാമതായി, എന്റെ പ്രോജക്റ്റ് നിർദ്ദേശങ്ങൾ കുറഞ്ഞു. ഒരു പ്രോംപ്റ്റിൽ നിന്ന് നിങ്ങൾ നീക്കം ചെയ്യുന്ന ഓരോ “എപ്പോഴും” (always), “ഒരിക്കലും” (never) എന്നീ വാക്കുകളും മോഡലിന് യഥാർത്ഥ പ്രശ്നപരിഹാരത്തിനായി ഉപയോഗിക്കാവുന്ന ടോക്കണുകളാണ്. ഹുക്ക് സ്ഥിരമായ കാര്യങ്ങൾ (invariant) കൈകാര്യം ചെയ്യുന്നു; പ്രോംപ്റ്റ് ലക്ഷ്യങ്ങളെ (intent) കൈകാര്യം ചെയ്യുന്നു.

ദി ക്വാളിറ്റി ഗേറ്റ്: “Done” എന്നതിനെ പുനർനിർവചിക്കുന്നു

ഏജന്റ് അതിന്റെ ജോലി പൂർത്തിയായെന്ന് തീരുമാനിക്കുകയും സെഷൻ അവസാനിപ്പിക്കാൻ ശ്രമിക്കുകയും ചെയ്യുമ്പോൾ Stop hook പ്രവർത്തിക്കുന്നു. ഞാൻ അത് അനുവദിക്കില്ല. പകരം, ഹുക്ക് മുഴുവൻ ടെസ്റ്റ് സ്യൂട്ടും (test suite) പ്രവർത്തിപ്പിക്കുന്നു. ഏതെങ്കിലും ടെസ്റ്റ് പരാജയപ്പെട്ടാൽ, ഹുക്ക് സ്റ്റോപ്പ് കമാൻഡ് തടയുകയും പരാജയപ്പെട്ട ഔട്ട്പുട്ട് ഏജന്റിന് തിരികെ നൽകുകയും ചെയ്യുന്നു.

ഇത് പൂർത്തീകരണത്തിന്റെ (completion) നിർവചനത്തെ മാറ്റുന്നു. "Done" എന്നത് ഇനി മോഡലിന് തോന്നുന്ന ഒരു വികാരമല്ല. അതൊരു അളക്കാവുന്ന കവാടമാണ് (measurable gate). കോഡ് പ്രവർത്തിക്കുന്നുണ്ടെന്ന് harness സ്ഥിരീകരിച്ചാൽ മാത്രമേ ഏജന്റിന് ജോലി അവസാനിപ്പിക്കാൻ കഴിയൂ. പ്രായോഗികമായി, ഇത് ഒരു ശക്തമായ ഫീഡ്‌ബാക്ക് ലൂപ്പ് (feedback loop) സൃഷ്ടിക്കുന്നു. ഏജന്റ് കോഡ് എഴുതുന്നു, അത് പൂർത്തിയായെന്ന് കരുതുന്നു, സ്റ്റോപ്പ് ബട്ടൺ അമർത്തുന്നു, ഉടൻ തന്നെ ഒരു pytest traceback കാണുന്നു. തുടർന്ന് അത് സ്വയം തിരുത്തുന്നു, ഇംപോർട്ട് എററോ (import error) തകരാറിലായ അസർഷനോ (broken assertion) പരിഹരിക്കുന്നു, വീണ്ടും നിർത്താൻ ശ്രമിക്കുന്നു. മനുഷ്യന്റെ ഇടപെടലില്ലാതെ തന്നെ ഏജന്റുകൾ ഈ ലൂപ്പിനുള്ളിൽ മൂന്നോ നാലോ തവണ ആവർത്തിക്കുന്നത് ഞാൻ കണ്ടിട്ടുണ്ട്. harness ഗുണനിലവാരം ഉറപ്പാക്കുന്നു; മോഡൽ പാച്ചുകൾ (patches) നൽകുന്നു.

ഇത് ഏജന്റ് എഞ്ചിനീയറിംഗിനെക്കുറിച്ച് എന്താണ് പഠിപ്പിക്കുന്നത്

വിശ്വസനീയമായ സ്വയംഭരണാധികാരമുള്ള സിസ്റ്റങ്ങൾ (autonomous systems) നിർമ്മിക്കുന്നതിന് ചിന്താഗതിയിൽ മാറ്റം ആവശ്യമാണ്. നീളമേറിയ പ്രോംപ്റ്റുകൾ എഴുതുന്നതിൽ നിന്ന് കൂടുതൽ ശക്തമായ harness-കൾ നിർമ്മിക്കുന്നതിലേക്ക് നിങ്ങൾ മാറുന്നു.

നിയമങ്ങൾ നടപ്പിലാക്കാൻ hooks ഉപയോഗിക്കുക, നയങ്ങൾക്കായി (policy) prompts ഉപയോഗിക്കുക. ഒരു നിയമം നൂറു ശതമാനം സമയവും പാലിക്കപ്പെടണമെങ്കിൽ, അത് കോഡിൽ ആയിരിക്കണം, സ്വാഭാവിക ഭാഷയിലല്ല. അവ്യക്തത (ambiguity), താൽപ്പര്യം (taste), ആർക്കിടെക്ചർ എന്നിവയിൽ പ്രോംപ്റ്റുകൾ മികച്ചതാണ്. എന്നാൽ അവ ഇൻവേരിയന്റുകളിൽ (invariants) വളരെ മോശമാണ്. ഒരു തെറ്റ് കാരണം നിങ്ങൾക്ക് ഒരു ഉച്ചനേരം മുഴുവൻ തിരുത്തലുകൾക്കായി ചെലവഴിക്കേണ്ടി വരികയോ അല്ലെങ്കിൽ അതിലും മോശമായി പ്രൊഡക്ഷൻ അപ്‌ടൈം (production uptime) നഷ്ടപ്പെടുകയോ ചെയ്യുമെങ്കിൽ, ഒരു ഹുക്ക് എഴുതുക.

ചെറിയ പ്രോംപ്റ്റുകൾ മികച്ച ഫലങ്ങൾ നൽകുന്നു. മെക്കാനിക്കൽ നിയമങ്ങൾ സ്ക്രിപ്റ്റുകളിലേക്ക് മാറ്റുമ്പോൾ, മോഡലിന് ഓർമ്മിച്ചുവെക്കാനും വൈരുദ്ധ്യങ്ങൾ ഉണ്ടാക്കാനും കുറച്ചു കാര്യങ്ങൾ മാത്രമേ ഉണ്ടാകൂ. ഏജന്റിന്റെ കോൺടെക്സ്റ്റ് വിൻഡോ (context window) ഒരു പരിമിതമായ വിഭവമാണ്. ഫോർമാറ്റിംഗ് ഓർമ്മപ്പെടുത്തലുകൾ കൊണ്ട് അത് നിറയ്ക്കരുത്.

അവസാനമായി, നിങ്ങളുടെ പങ്ക് മാറിക്കൊണ്ടിരിക്കുകയാണെന്ന് അംഗീകരിക്കുക. ഏജന്റുകൾക്ക് സ്വയംഭരണാധികാരം ലഭിക്കുന്നതോടെ, ഉള്ളടക്കം നിർമ്മിക്കുന്നതിൽ നിന്ന് ഗാർഡ്‌റെയിലുകൾ (guardrails) രൂപകൽപ്പന ചെയ്യുന്നതിലേക്ക് മനുഷ്യന്റെ ജോലി മാറുന്നു. മോഡലിന് എന്ത് ചെയ്യാൻ കഴിയും, എപ്പോൾ അവസാനിപ്പിക്കാം, കാര്യങ്ങൾ തെറ്റാകുമ്പോൾ എങ്ങനെ പെരുമാറണം എന്ന് തീരുമാനിക്കുന്ന harness ആണ് നിങ്ങൾ നിർമ്മിക്കുന്നത്. അത് എഞ്ചിനീയറിംഗാണ്, പ്രോംപ്റ്റിംഗല്ല.

ഈ സമീപനത്തിന് പ്രചോദനം നൽകിയ സ്രോതസ്സും കൂടുതൽ വിവരങ്ങളും ഇവിടെ കാണാം.

നിങ്ങൾ AI ഏജന്റുകൾ ഉപയോഗിച്ച് നിർമ്മാണം നടത്തുകയാണെങ്കിൽ, മറ്റ് വിദഗ്ധരുമായി ആശയവിനിമയം നടത്താൻ GyaanSetu ലേണിംഗ് കമ്മ്യൂണിറ്റി ഇവിടെ കണ്ടെത്താം.