ഏജന്റിക് കോഡിംഗ് സ്വീകരിക്കുന്ന മിക്ക ടീമുകളിലും തടസ്സം കോഡ് സൃഷ്ടിക്കുന്നതിൽനിന്ന് അവലോകനത്തിലേക്ക് മാറുന്നു. ഈ ലൂപ്പ് ശരിയാക്കാതെ മൊത്തത്തിലുള്ള വേഗവർധന ഏതാണ്ട് പൂജ്യമാണ്.
വലിയ തോതിലുള്ള CI പരിതസ്ഥിതികളിൽ—രാത്രിതോറും ദശലക്ഷക്കണക്കിന് പരിശോധനകളും നൂറുകണക്കിന് എൻജിനീയർമാരുമുള്ളിടത്ത്—ഏറ്റവും മൂല്യമുള്ള ഏജന്റ് ദൗത്യം കോഡ് സൃഷ്ടിക്കലല്ല, ഉടമസ്ഥത നിർണയിച്ച് ശരിയായ ടീമിലേക്ക് കൈമാറലും പ്രാഥമിക പ്രശ്നനിർണയവുമാണ്.
സൂക്ഷ്മപരിശോധനയെ അതിജീവിക്കുകയും കേവലം സാമ്യങ്ങൾ കണ്ടെത്തുന്നതിനപ്പുറം കാരണബന്ധം വിശദീകരിക്കുകയും ചെയ്യുന്ന ഏജന്റ് ഫലമാണ് പ്രയോജനകരം.
തെളിവുകൾ ശേഖരിക്കുകയും സന്ദർഭം ക്രമീകരിക്കുകയും ചെയ്യുന്ന പാളിയുടെ രൂപകൽപ്പനയ്ക്കാണ് സൃഷ്ടിക്കൽ പാളിയേക്കാൾ പ്രാധാന്യം.
ഏജന്റിക് കോഡിംഗിനെക്കുറിച്ചുള്ള മിക്ക ചർച്ചകളും ഇപ്പോഴും ലളിതമായൊരു വാഗ്ദാനത്തിലാണ് തുടങ്ങുന്നത്: കൂടുതൽ കോഡ്, കൂടുതൽ വേഗത്തിൽ എഴുതുക.
ചിലപ്പോൾ, ഏജന്റുകൾ ജോലി ആസൂത്രണം ചെയ്യുകയും PR-കൾ തുറക്കുകയും വളരെ കുറഞ്ഞ മനുഷ്യ ഇടപെടലോടെ മാറ്റങ്ങൾ പുറത്തിറക്കുകയും ചെയ്യുന്ന കൂടുതൽ മഹത്തായൊരു ദർശനമായി അത് വികസിക്കുന്നു. എന്നാൽ മിക്ക എൻജിനീയറിംഗ് ടീമുകൾക്കും സമീപഭാവിയിലെ ഏറ്റവും വ്യക്തമായ മൂല്യം അതിലും പരിമിതമാണ്. ആവർത്തിച്ചുള്ള മെച്ചപ്പെടുത്തലിന്റെ ചെലവ് കുറയ്ക്കുന്നതാണ് അതിന്റെ ലക്ഷ്യം.
സോഫ്റ്റ്‌വെയർ വിതരണം എന്നത് കോഡ് നിർമ്മാണം മാത്രമല്ല. കോഡ് എഴുതുക എന്നത് അവലോകനം, പരിശോധന, വിന്യാസം, പ്രശ്നങ്ങൾ ഉണ്ടാകുമ്പോൾ നടത്തുന്ന അന്വേഷണം എന്നിവ ഉൾപ്പെടുന്ന ഒരു വലിയ ലൂപ്പിലെ ഒരു ഘട്ടം മാത്രമാണ്. അവലോകന പ്രക്രിയയിൽ മാറ്റങ്ങൾ വരുത്താതെ ഏജന്റിക് കോഡിംഗ് സ്വീകരിക്കുന്ന മിക്ക ടീമുകളും തങ്ങളുടെ തടസ്സം തുടർന്നുള്ള ഘട്ടങ്ങളിലേക്ക് മാറ്റുക മാത്രമാണ് ചെയ്യുന്നത്.
സൃഷ്ടിക്കൽ മാത്രം വേഗത്തിലാക്കിയതുകൊണ്ട് ഒരു ടീം സ്വയമേവ വേഗത്തിലാകില്ല. അത് അവലോകനത്തിനും സ്ഥിരീകരണത്തിനും വിശ്വാസം ഉറപ്പാക്കുന്നതിനും വേണ്ട അധ്വാനം വർധിപ്പിക്കുക മാത്രമായേക്കാം.
പല എൻജിനീയറിംഗ് പരിതസ്ഥിതികളിലും ആദ്യ കരട് തയ്യാറാക്കുന്നതല്ല, അത് വിശ്വസിക്കാവുന്ന നിലയിലെത്തിക്കുന്നതാണ് ചെലവേറിയ ഭാഗം.
ആ മാറ്റം യഥാർഥത്തിൽ പ്രശ്നം പരിഹരിച്ചോ, അതോ സിസ്റ്റം മെച്ചപ്പെടുത്തിയോയെന്ന് എങ്ങനെ ഉറപ്പാക്കാം? അത് മറ്റെവിടെയെങ്കിലും പഴയൊരു പ്രശ്നം വീണ്ടും സൃഷ്ടിച്ചോ? പരാജയം കോഡിലാണോ, പരിതസ്ഥിതിയിലാണോ, പരിശോധനകളിലാണോ, അതോ ഒരു ആശ്രിത ഘടകത്തിലാണോ? നിർദേശിച്ച പരിഹാരം കാരണത്തെയാണോ അഭിസംബോധന ചെയ്യുന്നത്, അതോ കാണാവുന്ന ലക്ഷണത്തെ മാത്രമോ?
ഇവിടെ ഏജന്റുകൾക്ക് സഹായിക്കാനാകും. എൻജിനീയർമാരെ മാറ്റിസ്ഥാപിക്കുന്നതുകൊണ്ടല്ല, മറിച്ച് ക്രമരഹിതമായ തെളിവുകൾ ഘടനാപരമായി ആദ്യം പരിശോധിക്കാനാകുന്നതുകൊണ്ടാണ്: രേഖകൾ പരിശോധിക്കുക, സമീപകാല മാറ്റങ്ങൾ താരതമ്യം ചെയ്യുക, പ്രസക്തമായ സൂചനകൾ സംഗ്രഹിക്കുക, സാധ്യതയുള്ള കാരണങ്ങൾ കണ്ടെത്തുക, പരിശോധനകൾ നടത്തുക, തുടർന്ന് മനുഷ്യർക്ക് ചോദ്യംചെയ്ത് വിലയിരുത്താനാകുന്ന ഫലം നൽകുക.
പല ടീമുകളിലും ഏജന്റിന്റെ ഏറ്റവും ഫലപ്രദമായ ഉപയോഗം ആദ്യംമുതൽ കോഡ് സൃഷ്ടിക്കലല്ല. ഒരു മനുഷ്യൻ മണിക്കൂറുകൾ ചെലവിട്ട് നേരിട്ട് അന്വേഷിക്കുന്നതിന് മുമ്പ് പ്രശ്നത്തിന് ചുറ്റുമുള്ള തിരച്ചിൽപരിധി ചുരുക്കുന്നതാണ് അതിന്റെ പ്രയോജനം.
വലിയ തോതിലുള്ള പിഴവുതിരുത്തൽ പ്രവർത്തനക്രമങ്ങളിൽ ഇത് പ്രത്യേകിച്ചും വ്യക്തമാണ്. നൂറുകണക്കിന് എൻജിനീയർമാർ മാറ്റം വരുത്തുന്ന കോഡ് ശേഖരങ്ങളിൽ രാത്രിതോറും ദശലക്ഷക്കണക്കിന് പരിശോധനകൾ നടത്തുന്ന CI സംവിധാനം സങ്കൽപ്പിക്കുക. ഞങ്ങളുടെ ഒരു ഉപഭോക്താവിന് ഇത് യാഥാർഥ്യമാണ്. എന്തെങ്കിലും പരാജയപ്പെടുമ്പോൾ അതിന്റെ ഉത്തരവാദിത്തമുള്ള ടീമിനെ കണ്ടെത്തി കൈമാറുക പ്രയാസമാണ്. പ്രശ്നം ആപ്ലിക്കേഷൻ കോഡിലോ ആശ്രിത ഘടകത്തിലോ പരിശോധനാ ഹാർനെസിലോ സാങ്കേതിക അടുക്കിന്റെ മറ്റേതെങ്കിലും ഭാഗത്തോ ആകാം. രേഖകൾക്ക് ജിഗാബൈറ്റുകളോളം വലുപ്പമുണ്ടാകാം. പ്രശ്നം ആദ്യം കാണുന്ന ടീം തന്നെയാകണമെന്നില്ല അതിന്റെ ഉത്തരവാദിത്തമുള്ള ടീം.
അത്തരമൊരു പ്രവർത്തനക്രമത്തിൽ ഒരൊറ്റ ഏജന്റ് പരിഹാരം എഴുതുന്നത് സ്വാഭാവികമായ സമീപനമല്ല. പ്രശ്നപരിധി അതിവേഗം ചുരുക്കുന്ന ഒരു സിസ്റ്റത്തിനാണ് അത് അനുയോജ്യം.
പ്രയോജനകരമായൊരു പ്രവാഹം രേഖകൾ ശേഖരിക്കുകയും പ്രസക്തമായ തെളിവുകൾ തിരഞ്ഞെടുക്കുകയും പ്രധാനപ്പെട്ട കാര്യങ്ങൾ സംഗ്രഹിക്കുകയും സുരക്ഷിത പരീക്ഷണപരിതസ്ഥിതിയിൽ കോഡ് പരിശോധിക്കുകയും ചെയ്യാം. തുടർന്ന് ആത്മവിശ്വാസനില, കണ്ടെത്തലുകളുടെ ഉറവിടം പിന്തുടരാനുള്ള സൗകര്യം, നിർദേശിക്കുന്ന അടുത്ത നടപടികൾ എന്നിവയോടുകൂടിയ ഘടനാപരമായ മൂലകാരണ വിശകലനം നൽകാം. ആത്മവിശ്വാസനില കണക്കാക്കാൻ വിഷയവിദഗ്ധൻ ഏജന്റിന്റെ പ്രാരംഭ ഫലം വിലയിരുത്തുന്നു. മനുഷ്യന്റെ വിലയിരുത്തലുമായുള്ള പൊരുത്തം നിലനിർത്തിക്കൊണ്ട് തുടർന്നുള്ള മൂല്യനിർണയം യാന്ത്രികമാക്കാൻ ഇത് വിധികർത്താവായി പ്രവർത്തിക്കുന്ന ഒരു LLM-ലേക്ക് നൽകുന്നു.
എഞ്ചിനീയറിംഗ് തീരുമാനങ്ങളെ പൂർണ്ണമായി ഇല്ലാതാക്കുകയല്ല, മറിച്ച് അവലോകകർക്ക് കാര്യങ്ങൾ എളുപ്പമാക്കുന്നതിന് കൂടുതൽ വ്യക്തതയുള്ള ഒരു തുടക്കം നൽകുക എന്നതാണ് ഇതിന്റെ ലക്ഷ്യം. പഴയ പ്രശ്നങ്ങൾ വീണ്ടും പ്രത്യക്ഷപ്പെടുന്നതിന്റെ പ്രാഥമിക നിർണയം, PR അവലോകനം, ടെസ്റ്റ് റിപ്പയർ, റിലീസ് വാലിഡേഷൻ, പോസ്റ്റ്-ഡിപ്ലോയ്മെന്റ് ഇൻവെസ്റ്റിഗേഷൻ എന്നിവയെല്ലാം ഒരേ സ്വഭാവമുള്ളവയാണ്. ഇവ തെളിവുകൾ കൂടുതൽ ആവശ്യമുള്ളതും, വിശദമായ പരിശോധനകൾ വേണ്ടിവരുന്നതും, ഒട്ടേറെ അവ്യക്തതകൾ നിറഞ്ഞതുമാണ്. ഇവയൊന്നും എഞ്ചിനീയറിംഗ് പ്രക്രിയയെ മാറ്റിസ്ഥാപിക്കാൻ ഏജന്റിനോട് ആവശ്യപ്പെടുന്നില്ല; മറിച്ച്, ആ പ്രക്രിയയെ വേഗത്തിൽ മുന്നോട്ട് കൊണ്ടുപോകാൻ സഹായിക്കുക മാത്രമാണ് ചെയ്യുന്നത്.
ഈ സിസ്റ്റങ്ങളെ വിലയിരുത്തുന്ന രീതിയിൽ ടീമുകൾ ജാഗ്രത പുലർത്തേണ്ടതും അതുകൊണ്ടാണ്.
ഒറ്റയ്ക്ക് പ്രവർത്തിക്കുമ്പോൾ ഒരു ഏജന്റിന് ശ്രദ്ധേയമായ എന്തെങ്കിലും സൃഷ്ടിക്കാനാകുമോ എന്നത് തെറ്റായ ചോദ്യമാണ്. മറ്റെവിടെയെങ്കിലും തടസ്സം സൃഷ്ടിക്കാതെ അത് യഥാർഥ പ്രവർത്തനക്രമം മെച്ചപ്പെടുത്തുന്നുണ്ടോ എന്നതാണ് മികച്ച ചോദ്യം.
ഫലം പരിശോധിക്കാൻ കഴിയുന്നത്ര കൃത്യമാണോ, സാമ്യങ്ങൾ കണ്ടെത്തുക മാത്രമല്ലാതെ കാരണബന്ധം വിശദീകരിക്കുന്നുണ്ടോ, അവലോകനം കൂടുതൽ പ്രയാസകരമാക്കാതെ എളുപ്പമാക്കുന്നുണ്ടോ എന്നിവ പരിശോധിക്കണം. വിശ്വസനീയമെന്ന് തോന്നുന്ന ഉത്തരം പ്രയോജനകരമായ ഉത്തരത്തിന് തുല്യമല്ല. പ്രായോഗികമായി, സൂക്ഷ്മപരിശോധനയെ അതിജീവിക്കുകയും പരിശോധിക്കാൻ വ്യക്തമായ കാര്യങ്ങൾ നൽകുകയും ചെയ്യുമ്പോഴാണ് ടീമുകൾ ഏജന്റിന്റെ ഫലത്തെ വിശ്വസിക്കുന്നത്.
പ്രയോജനകരമായ ഏജന്റിക് സിസ്റ്റങ്ങൾ സൃഷ്ടിക്കൽ മാത്രമല്ല ആശ്രയിക്കുന്നതെന്നതാണ് കൂടുതൽ ആഴത്തിലുള്ള പാഠം. തെളിവുകൾ എങ്ങനെ ശേഖരിക്കുന്നു, സന്ദർഭം എങ്ങനെ ക്രമീകരിക്കുന്നു, ഫലങ്ങൾ എങ്ങനെ പരിശോധിക്കുന്നു, അനിശ്ചിതത്വം എങ്ങനെ അവലോകകന്റെ ശ്രദ്ധയിൽപ്പെടുത്തുന്നു എന്നിവയെയും അവ ആശ്രയിക്കുന്നു.
അതുകൊണ്ടാണ് ഏജന്റിക് എൻജിനീയറിംഗിന്റെ സമീപഭാവി ഒറ്റക്കുതിപ്പിൽ പൂർണ സ്വയംഭരണത്തിലെത്താൻ സാധ്യതയില്ലാത്തത്. ഓരോ ഘട്ടത്തിനുമിടയിലെ പാഴ്‌ശ്രമം കുറച്ചുകൊണ്ട് സ്വന്തം ജോലി പരിശോധിക്കാനും അവലോകനം ചെയ്യാനും സ്ഥിരീകരിക്കാനും മെച്ചപ്പെടുത്താനും ഏജന്റുകൾ ടീമുകളെ സഹായിക്കുന്ന, സൂക്ഷ്മമായി രൂപകൽപ്പന ചെയ്ത ലൂപ്പുകളുടെ ഒരു കൂട്ടമായിരിക്കാനാണ് കൂടുതൽ സാധ്യത.
വിശാലമായ സ്വയംഭരണ ദർശനത്തേക്കാൾ ഇത് നാടകീയത കുറഞ്ഞതാകാം. എന്നാൽ പ്രയോജനകരമായ സിസ്റ്റങ്ങൾ യഥാർഥത്തിൽ സ്വീകരിക്കപ്പെടുന്ന രീതിയോട് ഇതാണ് ഏറെ അടുത്തുനിൽക്കുന്നത്.