കോഡിംഗ് ഏജന്റുകളെ (coding agents) വിലയിരുത്തുന്ന എൻജിനീയറിങ് ടീമുകൾ സാധാരണയായി തെറ്റായ ചോദ്യത്തിൽ നിന്നാണ് തുടങ്ങുന്നത്. ഏജന്റിന് എത്രത്തോളം സ്വയംഭരണാധികാരം (autonomy) ലഭിക്കും എന്നാണ് അവർ അറിയാൻ ആഗ്രഹിക്കുന്നത്. പൈപ്പ്ലൈനിന്റെ എത്രത്തോളം ഭാഗം അതിന് കൈകാര്യം ചെയ്യാൻ കഴിയും? ആർക്കും ബുദ്ധിമുട്ടുണ്ടാക്കാതെ സ്പെസിഫിക്കേഷൻ എഴുതാനും, റെപ്പോസിറ്ററി എഡിറ്റ് ചെയ്യാനും, പ്രൊഡക്ഷനിലേക്ക് പുഷ് ചെയ്യാനും അതിന് സാധിക്കുമോ? ഡെമോകൾ കാണുമ്പോൾ ഈ ആവേശം സ്വാഭാവികമാണ്. ഒരു സിംഗിൾ പ്രോംപ്റ്റ് വഴി നിരവധി എഡിറ്റുകളും ഡിപ്ലോയ്മെന്റുകളും നടത്തുന്ന മികച്ച വർക്ക്ഫ്ലോ കാണുമ്പോൾ, സ്വന്തം സ്ഥാപനത്തിലും അത്തരമൊരു ശേഷി കൊണ്ടുവരാൻ ശ്രമിക്കുക എന്നത് സ്വാഭാവികമായ പ്രവണതയാണ്. എന്നാൽ ആകർഷണീയത എന്നത് ഒരു മോശം ഡിസൈൻ തത്വമാണ്. അതിനേക്കാൾ മികച്ച ചോദ്യങ്ങൾ കുറച്ചുകൂടി ഗൗരവമുള്ളവയാണ്: ഈ സംവിധാനത്തിന് ആർക്കാണ് അധികാരം നൽകിയത്, ഇതിന് യഥാർത്ഥത്തിൽ ഏതെല്ലാം സിസ്റ്റങ്ങളിൽ മാറ്റം വരുത്താൻ കഴിയും, കൂടാതെ ഇത് അനിവാര്യമായും എന്തെങ്കിലും തെറ്റ് ചെയ്താൽ എന്ത് സംഭവിക്കും?
സ്വയംഭരണാധികാരത്തിന്റെ കെണി (The Autonomy Trap)
ആവേശകരമായ സ്വയംഭരണാധികാരം ഒരു കെണിയാണ്. സ്പെസിഫിക്കേഷനുകൾ തയ്യാറാക്കുകയും, റെപ്പോസിറ്ററികൾ മാറ്റം വരുത്തുകയും, കോഡ് ഡിപ്ലോയ് ചെയ്യുകയും ചെയ്തുകൊണ്ട് ജോലി പൂർത്തിയായെന്ന് ശാന്തമായി അവകാശപ്പെടുന്ന ബോട്ടുകളെ ആഘോഷിക്കാൻ അത് നമ്മെ പഠിപ്പിക്കുന്നു. അത് എൻജിനീയറിങ് അല്ല. അത് ഷെൽ ആക്സസ് (shell access) നൽകിക്കൊണ്ടുള്ള ഒരു വിശ്വാസ പരീക്ഷണം മാത്രമാണ്. ജോലി എന്നത് വളരെ എളുപ്പമായി മാറുന്നു. ഏത് മോഡലിനും നിമിഷങ്ങൾക്കുള്ളിൽ കോഡ്, ഡോക്യുമെന്റേഷൻ അല്ലെങ്കിൽ ആർക്കിടെക്ചർ പ്ലാനുകൾ എന്നിവ തയ്യാറാക്കാൻ കഴിയും. എന്നാൽ സോഫ്റ്റ്വെയർ വികസനത്തിലെ യഥാർത്ഥ ചിലവ് ടൈപ്പിംഗ് വേഗതയല്ല. അത് എപ്പോഴും പരിശോധനയും (validation), റിവ്യൂവും, ഇത് ശരിയാണെന്നും വിശ്വസനീയമാണെന്നും ഉറപ്പുവരുത്തി വിതരണം ചെയ്യാനുള്ള (ship) കൃത്യമായ തീരുമാനവുമാണ്. നിർമ്മിക്കപ്പെട്ട ജോലികൾ വിലകുറഞ്ഞതാണ്. എന്നാൽ അവ അംഗീകരിക്കുന്നതിന് (approval) വലിയ ചിലവ് വരും. അംഗീകാരങ്ങൾ കൃത്യമായും സുസ്ഥിരമായും എങ്ങനെ കൈകാര്യം ചെയ്യണമെന്ന് മനസ്സിലാക്കുന്ന കമ്പനികളായിരിക്കും യഥാർത്ഥത്തിൽ വിശ്വസനീയമായ സിസ്റ്റങ്ങൾ വിതരണം ചെയ്യുന്നത്.
എന്തുകൊണ്ടാണ് സ്വയം പരിശോധന പരാജയപ്പെടുന്നത്
അപകടസാധ്യതകൾ പ്രവചിക്കാവുന്ന രീതിയിലാണ് പ്രത്യക്ഷപ്പെടുന്നത്. ഒരു മോഡൽ ഒരു പ്ലാൻ തയ്യാറാക്കുന്നു, തുടർന്ന് ആ പ്ലാൻ എത്രത്തോളം നല്ലതാണെന്ന് സ്വയം വിലയിരുത്തുന്നു. ഒരു ഏജന്റ് നിങ്ങളുടെ കോഡ്ബേസ് എഡിറ്റ് ചെയ്യുന്നു, കൂടാതെ അതിന്റെ മാറ്റങ്ങൾ എന്തുകൊണ്ട് സുരക്ഷിതമാണെന്ന് നിങ്ങൾക്ക് വിശദീകരിച്ചുതരുന്നു. ഒരു ടൂൾ ഒരു കമാൻഡ് പ്രവർത്തിപ്പിക്കുന്നു, അനുമതി ചോദിക്കുന്നതിന് പകരം തെറ്റ് പറ്റിയാൽ മാപ്പ് ചോദിക്കുന്നു. ഇവയെല്ലാം ഒരേ പരാജയത്തെയാണ് സൂചിപ്പിക്കുന്നത്. ഒരു ഏജന്റ് ഒരു സ്പെസിഫിക്കേഷൻ തയ്യാറാക്കിയാൽ, അത് സത്യമായി മാറുന്നതിന് മുമ്പ് ആ ഏജന്റിന് പുറത്തുള്ള മറ്റൊരാൾ അത് അംഗീകരിക്കണം. ഒരു ഏജന്റ് കോഡ് മാറ്റം വരുത്തിയാൽ, മറ്റൊരു പ്രക്രിയ ആ മാറ്റങ്ങൾ (diff) പരിശോധിക്കണം. നിർമ്മാതാവിനെ തന്നെ പരിശോധകനാക്കി മാറ്റുന്നത് ഒരു എളുപ്പവഴിയല്ല. അത് സൗകര്യമെന്ന പേരിൽ അവതരിപ്പിക്കപ്പെട്ട ഒരു ഘടനാപരമായ പിഴവാണ്.
പ്രോംപ്റ്റുകൾ അനുമതി സംവിധാനങ്ങളല്ല
ബുദ്ധിപരമായ വാക്കുകൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഒരു ഏജന്റിനെ സുരക്ഷിതമാക്കാൻ കഴിയില്ല. ശ്രദ്ധിക്കണമെന്നോ അല്ലെങ്കിൽ എന്തെങ്കിലും ഡിലീറ്റ് ചെയ്യുന്നതിന് മുമ്പ് ചോദിക്കണമെന്നോ ഒരു മോഡലിനോട് പറയുന്നത് ഒരു അതിർവരമ്പ് സൃഷ്ടിക്കില്ല. പ്രോംപ്റ്റുകൾ അനുമതി സംവിധാനങ്ങളല്ല (permission systems). ഒരു ഏജന്റിനെ പ്രൊഡക്ഷന് അടുത്ത് വിടുന്നതിന് മുമ്പ്, അതിന്റെ കഴിവുകളെക്കുറിച്ച് നിങ്ങൾക്ക് കൃത്യമായ ധാരണ ഉണ്ടായിരിക്കണം. അതിന് മുഴുവൻ റെപ്പോസിറ്ററിയും വായിക്കാൻ കഴിയുമോ? ഷെൽ കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കാൻ കഴിയുമോ? ബ്രൗസർ തുറക്കാൻ കഴിയുമോ? ഉപഭോക്താക്കളുടെ ഡാറ്റ അതിന്റെ കോൺടെക്സ്റ്റ് വിൻഡോയിലേക്ക് (context window) കൊണ്ടുവരാൻ കഴിയുമോ? മിക്ക ടീമുകൾക്കും ഇതിന്റെ പൂർണ്ണമായ ഉത്തരങ്ങൾ അറിയില്ല. ആ ടൂൾ ഒരു സാൻഡ്ബോക്സിലേക്ക് (sandbox) പരിമിതമാണെന്ന് അവർ കരുതുന്നു, എന്നാൽ യഥാർത്ഥത്തിൽ അതിന് നിർണ്ണായകമായ പാതകളിൽ എഴുതാനുള്ള (write access) അധികാരമുണ്ടാകാം. ആദ്യം അതിന്റെ പ്രവർത്തന പരിധി (surface area) മനസ്സിലാക്കുക. അതിനുശേഷം സുരക്ഷാ മതിലുകൾ പണിയുക.
ഘട്ടം ഘട്ടമായുള്ള ഒരു നിയന്ത്രണ സംവിധാനം നിർമ്മിക്കുക
ഏജന്റിന് എന്ത് ചെയ്യാൻ കഴിയുമെന്ന് മനസ്സിലാക്കിയുകഴിഞ്ഞാൽ, അപകടസാധ്യതയ്ക്ക് അനുസൃതമായ ഒരു നിയന്ത്രണ സംവിധാനം രൂപകൽപ്പന ചെയ്യുക. ഇന്റേണൽ ഡോക്യുമെന്റേഷൻ അപ്ഡേറ്റ് ചെയ്യുകയോ കോഡ് ഫോർമാറ്റ് ചെയ്യുകയോ പോലുള്ള കുറഞ്ഞ അപകടസാധ്യതയുള്ള ജോലികൾ സ്വയമേവ ചെയ്യാവുന്നതാണ്. ഒരു മോഡ്യൂൾ റീഫാക്ടർ ചെയ്യുകയോ പുതിയൊരു ഡിപെൻഡൻസി ചേർക്കുകയോ പോലുള്ള ഇടത്തരം അപകടസാധ്യതയുള്ള ജോലികൾ, ഒരു മനുഷ്യനോ അല്ലെങ്കിൽ പരിശോധിക്കപ്പെട്ട ഒരു ടെസ്റ്റ് സ്യൂട്ടിനോ (test suite) സ്ഥിരീകരണം നൽകേണ്ട ഒരു ചെക്ക്പോയിന്റിലൂടെ കടന്നുപോകണം. പ്രൊഡക്ഷനിലേക്ക് വിന്യസിക്കുക, ഇൻഫ്രാസ്ട്രക്ചർ മാറ്റം വരുത്തുക, അല്ലെങ്കിൽ സെൻസിറ്റീവ് ഡാറ്റ ഉപയോഗിക്കുക തുടങ്ങിയ ഉയർന്ന അപകടസാധ്യതയുള്ള ജോലികൾക്ക്, ആ ജോലിയിൽ ഉൾപ്പെടാത്ത മറ്റൊരു അംഗത്തിന്റെ അനുമതി ആവശ്യമാണ്. ഓരോ പ്രവർത്തനവും ഒരു ഓഡിറ്റ് ട്രയൽ (audit trail) അവശേഷിപ്പിക്കണം. ഏതെല്ലാം ഫയലുകൾ വായിച്ചു, ഏതെല്ലാം ടൂളുകൾ ഉപയോഗിച്ചു, ഏതെല്ലാം തീരുമാനങ്ങൾ എടുത്തു എന്ന് കൃത്യമായി പരിശോധിക്കാൻ നിങ്ങൾക്ക് കഴിയണം. ഏജന്റുകൾ ഉപയോഗിച്ചുള്ള വികസനം എന്നത് റിവ്യൂകൾ ഒഴിവാക്കാനുള്ള ലൈസൻസല്ല. വിരസമായ നിയന്ത്രണങ്ങൾ ഒരു സവിശേഷതയാണ്. കാര്യങ്ങൾ നിയന്ത്രണാതീതമാകുമ്പോൾ ഒരു സർക്യൂട്ട് ബ്രേക്കർ പോലെ പ്രവർത്തിക്കാൻ ശരിയായ ഒരു അപ്രൂവൽ ഗേറ്റ് സഹായിക്കും.
അതിർവരമ്പുകളെ അപകടസാധ്യതയുമായി പൊരുത്തപ്പെടുത്തുക
യഥാർത്ഥ അപകടസാധ്യതയ്ക്ക് അനുസൃതമായി നിങ്ങളുടെ അതിർവരമ്പുകൾ ക്രമീകരിക്കുക. ഓരോ മാർക്ക്ഡൗൺ (Markdown) ഫോർമാറ്റിംഗ് മാറ്റവും ഒരു വലിയ നടപടിക്രമമാക്കി മാറ്റുന്നത് നിങ്ങളുടെ ടീമിനെ തളർത്തും. എന്നാൽ ഏജന്റ് ആത്മവിശ്വാസത്തോടെ പ്രവർത്തിക്കുന്നു എന്നതുകൊണ്ട് മാത്രം ഉയർന്ന ഉത്തരവാദിത്തമുള്ള ജോലികളെ നിസ്സാരമായി കാണുന്നതും വിഡ്ഢിത്തമാണ്. ലക്ഷ്യം നിയന്ത്രണങ്ങൾ ഏർപ്പെടുത്തുക എന്നതല്ല, മറിച്ച് അപകടസാധ്യതയ്ക്ക് അനുസൃതമായ നിയന്ത്രണം ഉറപ്പാക്കുക എന്നതാണ്.
ആർട്ടിഫാക്റ്റുകൾ ചെറുതും നിരീക്ഷിക്കാവുന്നതുമായി സൂക്ഷിക്കുക
ഏറ്റവും പ്രയോജനപ്രദമായ ഏജന്റ് സിസ്റ്റങ്ങൾ വലിയ സ്വയംഭരണാധികാരമുള്ള (autonomous) പ്രവർത്തനങ്ങളിലൂടെ നിങ്ങളെ അത്ഭുതപ്പെടുത്താൻ ശ്രമിക്കുന്നില്ല. അവ ചെറിയതും പരിശോധിക്കാവുന്നതുമായ (reviewable) ആർട്ടിഫാക്റ്റുകൾ നിർമ്മിക്കുന്നു. കൃത്യമായ ഒരു പ്ലാൻ. ശ്രദ്ധ കേന്ദ്രീകരിച്ച ഒരു ഡിഫ് (diff). വായിക്കാൻ എളുപ്പമുള്ള ഒരു ലോഗ്. വലിയ സ്വയംഭരണാധികാരമുള്ള പ്രവർത്തനങ്ങൾ ഡിബഗ് (debug) ചെയ്യുന്നത് ഒരു പേടിസ്വപ്നമാണ്. അൻപതോളം ഫയലുകൾ ഉൾപ്പെട്ട ഒരു ഏജന്റ് സെഷന് ശേഷം എന്തെങ്കിലും തകരാർ സംഭവിച്ചാൽ, ഉദ്ദേശ്യം (intent), പ്രവർത്തനം (execution), സൈഡ് ഇഫക്റ്റുകൾ (side effects) എന്നിവയെല്ലാം ഒരേസമയം വേർതിരിച്ചെടുക്കേണ്ടി വരും. ആഘാതപരിധി (blast radius) ചെറുതായി സൂക്ഷിക്കുക. ഏജന്റ് ഏതെല്ലാം ഫയലുകൾ വായിച്ചു എന്നും ഏതെല്ലാം ടൂളുകൾ ഉപയോഗിച്ചു എന്നും അറിയാൻ നിർബന്ധം പിടിക്കുക. നിരീക്ഷിക്കാൻ കഴിയുന്ന (Observable) സിസ്റ്റങ്ങൾ എളുപ്പത്തിൽ പരിപാലിക്കാൻ (maintainable) കഴിയുന്നവയാണ്. ബ്ലാക്ക്-ബോക്സ് സ്വയംഭരണാധികാരം എന്നത് മികച്ച മാർക്കറ്റിംഗിലൂടെ അവതരിപ്പിക്കപ്പെട്ട സാങ്കേതിക കടം (technical debt) മാത്രമാണ്.
അനുമതി നൽകുന്നതിന് മുമ്പ് ചോദിക്കേണ്ട ആറ് ചോദ്യങ്ങൾ
ഒരു ഏജന്റിന് യഥാർത്ഥ ഉത്തരവാദിത്തങ്ങൾ നൽകുന്നതിന് മുമ്പ്, ആറ് കഠിനമായ ചോദ്യങ്ങളിലൂടെ നിങ്ങളുടെ സംവിധാനത്തെ പരീക്ഷിക്കുക.
- സിസ്റ്റത്തിന് യഥാർത്ഥത്തിൽ എന്തൊക്കെ കഴിവുകളുണ്ട്?
- സിസ്റ്റം പ്രോംപ്റ്റിലെ ഒരു മര്യാദയുള്ള വാചകം കൊണ്ട് തടയുന്നതിന് പകരം, ഇൻഫ്രാസ്ട്രക്ചർ തലത്തിൽ തന്നെ തടയപ്പെട്ട, ഡിഫോൾട്ട് ആയി നിരാകരിക്കപ്പെട്ട പ്രവർത്തനങ്ങൾ ഏതെല്ലാമാണ്?
- ഏതെല്ലാം പ്രവർത്തനങ്ങൾക്കാണ് വ്യക്തമായ അനുമതി ആവശ്യമായിട്ടുള്ളത്?
- ഏജന്റ് ഉപയോഗിക്കുന്നതിന് മുമ്പ് ഏതെല്ലാം ആർട്ടിഫാക്റ്റുകൾ ഫ്രീസ് (frozen) ചെയ്യുന്നു? അങ്ങനെ അതിന് സ്വന്തം ഇൻപുട്ടുകളിൽ രഹസ്യമായി മാറ്റം വരുത്താൻ കഴിയില്ലെന്ന് ഉറപ്പാക്കാം.
- ജനറേറ്ററിൽ നിന്ന് തികച്ചും വ്യത്യസ്തമായ ഏത് വാലിഡേറ്റർ (validator) ആണ് അന്തിമ ഔട്ട്പുട്ട് വിലയിരുത്തുന്നത്?
- യഥാർത്ഥത്തിൽ എന്താണ് സംഭവിച്ചതെന്ന് സംശയമില്ലാതെ തെളിയിക്കുന്ന ലോഗ് ഏതാണ്?
ഇത് അടിസ്ഥാനപരമായ എഞ്ചിനീയറിംഗ് ശുചിത്വമാണ് (engineering hygiene). ജനറേറ്ററിനെ വാലിഡേറ്ററിൽ നിന്ന് വേർതിരിക്കുക. മനുഷ്യന്റെ നിയന്ത്രണം (human authority) അതിർത്തിയിൽ തന്നെ നിലനിർത്തുക.
യഥാർത്ഥ പരിശോധന
അവിടെ