ലൂപ്പ് എൻജിനീയറിംഗ് (Loop engineering) ഇപ്പോൾ ഏറെ ചർച്ച ചെയ്യപ്പെടുന്ന ഒന്നാണ്. സാങ്കേതിക ഫോറങ്ങൾ പരിശോധിച്ചാൽ, AI ഏജന്റുകളെ വെറും ചാറ്റ്ബോട്ടുകളായി കണ്ട് പ്രോംപ്റ്റുകൾ നൽകി പരിശീലിപ്പിക്കുന്നത് നിർത്തണം എന്ന് വാദിക്കുന്നവരെ കാണാം. പകരം, ലൂപ്പുകൾ രൂപകൽപ്പന ചെയ്യണമെന്നാണ് അവർ പറയുന്നത്: ഏജന്റിന് സ്വയം പ്ലാൻ ചെയ്യാനും, പ്രവർത്തിപ്പിക്കാനും, സ്വന്തം ജോലി പരിശോധിക്കാനും, നമ്മൾ ഉറങ്ങുന്ന സമയത്തും അത് ആവർത്തിക്കാനും (iterate) കഴിയുന്ന സ്വയംഭരണാധികാരമുള്ള ചക്രങ്ങൾ (autonomous cycles). ഈ ആശയം ആകർഷകമാണ്. ലൂപ്പ് കൃത്യമായി നിർമ്മിച്ചാൽ, മനുഷ്യന്റെ നിരന്തരമായ മേൽനോട്ടം ഇല്ലാതെ തന്നെ ഏജന്റിന് ലക്ഷ്യത്തിൽ നിന്ന് വ്യതിചലിക്കാതെ, ഒരു ഉദ്ദേശ്യത്തെ (intent) പൂർണ്ണമായ ഔട്ട്പുട്ടായി രാത്രിയോരങ്ങളിൽ തന്നെ മാറ്റാൻ കഴിയും.
ഈ വാഗ്ദാനം സിദ്ധാന്തപരമായി (theory) വളരെ മികച്ചതാണ്. എന്നാൽ പ്രായോഗികമായി നോക്കിയാൽ, മിക്ക ഏജന്റുകളും ഇപ്പോൾ തന്നെ ലൂപ്പുകൾ ഉപയോഗിക്കുന്നുണ്ട്. അവ കോഡ് നിർമ്മിക്കുന്നു, കംപൈലർ എററുകളോ ടെസ്റ്റ് ഫെയിലറുകളോ പരിശോധിക്കുന്നു, കോഡ് പരിഹരിക്കുന്നു, വീണ്ടും റൺ ചെയ്യുന്നു. ഈ അടിസ്ഥാന ഫീഡ്ബാക്ക് സൈക്കിൾ പുതിയതല്ല. എന്നാൽ ഇപ്പോൾ ഇതിനെ അനുകൂലിക്കുന്നവർ ആവശ്യപ്പെടുന്നത് ഇതിലും വലിയൊരു കാര്യമാണ്: വെറും സിന്റാക്സ് എററുകൾ മാത്രമല്ല, മുഴുവൻ ടാസ്കിനെയും നിയന്ത്രിക്കുന്ന ഒരു 'ഔട്ടർ ലൂപ്പ്' (outer loop). ആ ഔട്ടർ ലൂപ്പ് നിർമ്മിക്കുന്നിടത്താണ് പ്രായോഗിക ബുദ്ധിമുട്ടുകൾ തുടങ്ങുന്നത്, കാരണം സോഫ്റ്റ്വെയർ എൻജിനീയറിംഗ് എന്നത് നിശ്ചിത നിയമങ്ങളുള്ള ഒരു ക്ലോസ്ഡ് സിസ്റ്റം (closed system) അല്ല.
ലൂപ്പ് ഡിസൈൻ പ്രശ്നം
ഉൽപ്പന്ന ലക്ഷ്യങ്ങൾ (Product goals) പലപ്പോഴും സങ്കീർണ്ണമാണ്. ഒരു കാര്യം പൂർത്തിയായി എന്ന് പറയാൻ കൃത്യമായ നിർവചനം (definition of done) ഉണ്ടാകണമെന്നില്ല. പലപ്പോഴും നിർമ്മാണത്തിനിടയിലാണ് യഥാർത്ഥ ലക്ഷ്യം നമ്മൾ തിരിച്ചറിയുന്നത്. വൈറ്റ് ബോർഡിൽ ലളിതമെന്ന് തോന്നുന്ന ഒരു ആവശ്യം, പ്രായോഗികമായി വരുമ്പോൾ സങ്കീർണ്ണമായ സാഹചര്യങ്ങൾ (edge cases) സൃഷ്ടിക്കുകയും പരിഹാരത്തിന്റെ രീതി തന്നെ മാറ്റുകയും ചെയ്തേക്കാം. ഒരു ഏജന്റിനെ കടുപ്പമേറിയ ഒരു ലൂപ്പിനുള്ളിൽ (rigid loop) ഒതുക്കുമ്പോൾ, ആ കടുപ്പം ഒരു പോരായ്മയായി മാറുന്നു. തെറ്റായ ഒരു ലക്ഷ്യത്തിന് പിന്നാലെ ലൂപ്പ് വീണ്ടും വീണ്ടും ശ്രമിച്ചുകൊണ്ടേയിരിക്കും. ഇതിലും മോശം അവസ്ഥ, ഒരു ഫ്ലെക്സിബിൾ ലൂപ്പ് താൻ നൽകുന്ന ഔട്ട്പുട്ടിന് അനുസരിച്ച് ലക്ഷ്യത്തെ തന്നെ രഹസ്യമായി മാറ്റുന്നതാണ്. ഈ രണ്ട് ഫലങ്ങളും പ്രയോജനകരമല്ല. ഒന്ന് കമ്പ്യൂട്ട് (compute) പാഴാക്കുന്നു; മറ്റൊന്ന് തെറ്റായ ഔട്ട്പുട്ട് ആത്മവിശ്വാസത്തോടെ നൽകുന്നു.
ഇതിന്റെ ആഴത്തിലുള്ള പ്രശ്നം സ്പെസിഫിക്കേഷൻ ചിലവ് (specification cost) ആണ്. ഒരു ലൂപ്പ് മേൽനോട്ടമില്ലാതെ പ്രവർത്തിക്കണമെങ്കിൽ, എല്ലാ സാഹചര്യങ്ങളെയും മുൻകൂട്ടി കാണുന്ന ഒരു സ്പെസിഫിക്കേഷൻ (spec) നിങ്ങൾ എഴുതണം. ഏജന്റ് കൃത്യമായി എന്താണ് മാറ്റേണ്ടത്? നിലവിലുള്ള ഏത് രീതിയാണ് മാറ്റാൻ പാടില്ലാത്തത്? ഏത് സാഹചര്യത്തിലാണ് ഏജന്റ് ആവർത്തനങ്ങൾ (iterations) നിർത്തേണ്ടത്? ഏത് റിസ്കുകളാണ് സ്വീകാര്യം, ഏത് പാർശ്വഫലങ്ങളാണ് (side effects) കണ്ടാൽ ഉടൻ പ്രവർത്തനം നിർത്തേണ്ടത്? ഈ രേഖ തയ്യാറാക്കുന്നത് ഏജന്റിനൊപ്പം ഇരുന്ന് നേരിട്ട് ജോലി ചെയ്യിക്കുന്നതിനേക്കാൾ കൂടുതൽ സമയമെടുക്കും. ഓട്ടോമേഷൻ നൽകുന്ന ലാഭം, അത് പരിശോധിക്കുന്നതിനുള്ള (verification) ചിലവ് അത് ചെയ്യുന്നതിനേക്കാൾ വളരെ കുറവാണെങ്കിൽ മാത്രമേ ലഭിക്കൂ. അതുകൊണ്ട് തന്നെ, തുടക്കത്തിൽ തന്നെ വലിയൊരു അധ്വാനം ഇതിനായി നിങ്ങൾ നൽകേണ്ടി വരുന്നു.
ലൂപ്പുകൾ യഥാർത്ഥത്തിൽ എവിടെയാണ് പ്രയോജനപ്പെടുന്നത്
ലൂപ്പ് എൻജിനീയറിംഗ് ഉപയോഗശൂന്യമാണെന്ന് ഇതിനർത്ഥമില്ല. ഇതൊരു പ്രത്യേക ആവശ്യത്തിനുള്ള ഉപകരണം (specialized tool) മാത്രമാണ്, എല്ലാത്തിനും ഉപയോഗിക്കാവുന്ന ഒരു തന്ത്രമല്ല. പരിശോധനാ ചിലവുകൾ (verification costs) കൂടുന്ന സാഹചര്യങ്ങളിലും, വിജയത്തിന്റെ മാനദണ്ഡങ്ങൾ വ്യക്തമായപ്പോഴും ലൂപ്പുകൾ മികച്ച രീതിയിൽ പ്രവർത്തിക്കും. പ്രധാനമായും മൂന്ന് സാഹചര്യങ്ങളിലാണ് ഇത് പ്രകടമാകുന്നത്.
സാധാരണ യന്ത്രപ്രവർത്തനങ്ങൾ (Routine mechanical work). സീനിയർ എൻജിനീയർമാരെ മടുപ്പിക്കുന്ന ജോലികളെക്കുറിച്ച് ചിന്തിക്കുക: പ്രത്യേക ക്രമത്തിൽ ആപ്ലിക്കേഷനുകൾ സ്റ്റാർട്ട് ചെയ്യുക, ഓരോ ഘട്ടവും സ്ഥിരീകരിക്കാൻ ഡിപ്ലോയ്മെന്റ് UI-യിലൂടെ ക്ലിക്ക് ചെയ്യുക, റിലീസിന് ശേഷം എറർ സ്ട്രിംഗുകൾക്കായി ലോഗുകൾ പരിശോധിക്കുക (grepping logs), അല്ലെങ്കിൽ ഒരു കോൺഫിഗറേഷൻ ഫയൽ എല്ലാ നോഡുകളിലും എഴുതപ്പെട്ടോ എന്ന് പരിശോധിക്കുക. മനുഷ്യർക്ക് ഈ ഘട്ടങ്ങൾ വിരസമാണ്, എന്നാൽ പരിശോധിക്കാൻ വളരെ എളുപ്പവുമാണ്. ഓരോ റീസ്റ്റാർട്ടിന് ശേഷവും ഹെൽത്ത് എൻഡ്പോയിന്റുകൾ (health endpoints) പരിശോധിക്കാനും എന്തെങ്കിലും പ്രശ്നമുണ്ടെങ്കിൽ ഉടൻ തന്നെ റോൾബാക്ക് (rollback) ചെയ്യാനും ഒരു ലൂപ്പിന് സാധിക്കും. മനുഷ്യൻ റോളൗട്ട് പ്ലാൻ തയ്യാറാക്കുന്നു, എന്നാൽ പുലർച്ചെ രണ്ട് മണിയിലും ഒരു യന്ത്രത്തിന്റെ ക്ഷമയോടെ ലൂപ്പ് അത് നടപ്പിലാക്കുന്നു.
അളക്കാൻ കഴിയുന്ന ഒപ്റ്റിമൈസേഷൻ ലക്ഷ്യങ്ങൾ (Measurable optimization goals). വിജയം ഒരു സംഖ്യയായിരിക്കുമ്പോൾ, ലൂപ്പുകൾ അത്യന്തം ഫലപ്രദമാണ്. ഉദാഹരണത്തിന്, p99 ലേറ്റൻസി (latency) 150 മില്ലിസെക്കൻഡിൽ താഴെയാക്കുക, മെമ്മറി ഉപയോഗം (memory footprint) ഇരുപത് ശതമാനം കുറയ്ക്കുക, അല്ലെങ്കിൽ ഒരു കോഡ് പാത്ത് Python-ൽ നിന്ന് Rust-ലേക്ക് മാറ്റുകയും നിലവിലുള്ള യൂണിറ്റ് ടെസ്റ്റുകൾ (unit tests) വിജയിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുകയും ചെയ്യുക. ലൂപ്പിന് ഒരു മാറ്റം വരുത്താനും, അത് ബെഞ്ച്മാർക്ക് (benchmark) ചെയ്യാനും, മികച്ച ഫലം നൽകുന്ന രീതി നിലനിർത്താനും ബാക്കിയുള്ളവ ഒഴിവാക്കാനും കഴിയും. പരിശോധന ഓട്ടോമേറ്റഡ് ആയതുകൊണ്ടും തിരയേണ്ട മേഖല (search space) വലുതായതുകൊണ്ടും, ഒരു ലൂപ്പ് ഇല്ലാതെ ഇത് മനുഷ്യർ ചെയ്യുന്നത് പ്രായോഗികമല്ല. ലക്ഷ്യം കൃത്യമാണ്, എന്നാൽ അത് എങ്ങനെ നേടണം എന്ന പാത അനിശ്ചിതമാണ്. ഇതാണ് ലൂപ്പുകൾക്ക് ഏറ്റവും അനുയോജ്യമായ സാഹചര്യം.
ഓപ്പറേഷണൽ പ്ലേബുക്കുകൾ (Operational playbooks). ഇൻസിഡന്റ് റെസ്പോൺസും (Incident response) സപ്പോർട്ട് ടിക്കറ്റുകളും പലപ്പോഴും മനുഷ്യർ നേരത്തെ കണ്ടെത്തിയ പാറ്റേണുകൾ പിന്തുടരുന്നവയാണ്. ചില പ്രത്യേകതരം പ്രൊഡക്ഷൻ എററുകൾക്ക് ക്രെഡൻഷ്യലുകൾ റൊട്ടേറ്റ് ചെയ്യാനും (rotating a credential) കാഷെ ക്ലിയർ ചെയ്യാനും (clearing a cache) ആവശ്യമായി വരാം. മൂന്ന് നിശ്ചിത സാഹചര്യങ്ങൾ ഉണ്ടാകുമ്പോൾ ഒരു സപ്പോർട്ട് റിക്വസ്റ്റ് റീഫണ്ട് നൽകി പരിഹരിക്കാം. ഒരു ലൂപ്പിന് ഈ സാഹചര്യങ്ങൾ നിരീക്ഷിക്കാനും പ്ലേബുക്ക് നടപ്പിലാക്കാനും സാധിക്കും, പാറ്റേൺ തെറ്റിയാൽ മാത്രം അത് ഉയർന്ന ഉദ്യോഗസ്ഥർക്ക് കൈമാറാം (escalating). പ്ലേബുക്ക് ശരിയാണോ എന്ന് അത് തീരുമാനിക്കുന്നില്ല; പകരം, ഓൺ-കോൾ എൻജിനീയർമാർക്ക് ചെയ്യാൻ കഴിയുന്നതിനേക്കാൾ വേഗതയിലും കൃത്യതയിലും അത് കാര്യങ്ങൾ ചെയ്യുന്നു.
റെഗുലേറ്ററുകൾ, റഫറൻസ് സെറ്ററുകളല്ല
നിലവിലെ ചർച്ചകളിൽ പലപ്പോഴും വിട്ടുപോയിക്കൊണ്ടിരിക്കുന്ന ഒരു പ്രധാന വ്യത്യാസമുണ്ട്. ലൂപ്പുകൾ (Loops) നിയന്ത്രണ സംവിധാനങ്ങളാണ് (regulators). ഒരു തെർമോസ്റ്റാറ്റ് മുറിയിലെ താപനില എഴുപത്തിരണ്ട് ഡിഗ്രിയിൽ നിലനിർത്തുന്നത് പോലെ, അവ ഒരു സിസ്റ്റത്തെ മുൻകൂട്ടി നിശ്ചയിച്ച ലക്ഷ്യവുമായി ചേർന്നുനിൽക്കാൻ സഹായിക്കുന്നു. എന്നാൽ എഴുപത്തിരണ്ട് ഡിഗ്രി എന്നത് തെർമോസ്റ്റാറ്റ് സ്വയം തീരുമാനിക്കുന്നതല്ല. അത് ശരിയായ താപനിലയാണെന്ന് ആരെങ്കിലും ആദ്യം തീരുമാനിക്കേണ്ടതുണ്ട്.
സോഫ്റ്റ്വെയറിന്റെ കാര്യമെടുത്താൽ, ഒരു ലൂപ്പിനുള്ളിലെ ഏജന്റിന് (agent) ദിവസം മുഴുവൻ ബഗുകൾ പരിഹരിക്കാനോ, ഫംഗ്ഷനുകൾ റീഫാക്ടർ ചെയ്യാനോ (refactor), പാരാമീറ്ററുകൾ ക്രമീകരിക്കാനോ (tune parameters) സാധിക്കും. എന്നിരുന്നാലും, ഏത് ഫീച്ചറാണ് ഉപഭോക്താവിന് യഥാർത്ഥത്തിൽ സഹായകരമാകുന്നത് എന്നോ, അടുത്ത റിലീസിന് മുമ്പ് ഒരു ബഗ് പരിഹരിക്കേണ്ടത് ആവശ്യമാണോ എന്നോ തീരുമാനിക്കാൻ അതിന് കഴിയില്ല. ബിസിനസ്സ് സാഹചര്യം, ഉപഭോക്താക്കളുടെ ബുദ്ധിമുട്ടുകൾ, തന്ത്രപരമായ മുൻഗണനകൾ എന്നിവയെക്കുറിച്ചുള്ള വിവേചനാധികാരം (judgment) ഇത്തരം തീരുമാനങ്ങൾക്ക് ആവശ്യമാണ്. ഏജന്റുകൾ പ്രവർത്തിക്കുന്നു (execute). മനുഷ്യരാണ് തീരുമാനങ്ങൾ എടുക്കുന്നത്. ഇവ രണ്ടിനെയും തമ്മിൽ തെറ്റായി മനസ്സിലാക്കുന്നത്, തെറ്റായ പ്രശ്നങ്ങൾക്ക് പരിഹാരം കാണുന്ന, എന്നാൽ വളരെ മികച്ച രീതിയിൽ ഒപ്റ്റിമൈസ് ചെയ്ത (optimized) സിസ്റ്റങ്ങൾ നിർമ്മിക്കാൻ ടീമുകളെ എത്തിക്കുന്നു.
ലൂപ്പ് എൻജിനീയറിംഗ് (Loop engineering) പ്രയോജനകരമാണ്, പക്ഷേ അതിന്റെ പരിധി പരിമിതമാണ്. അച്ചടക്കത്തോടും വേഗതയോടും കൂടി യന്ത്രം പ്രവർത്തിപ്പിക്കാൻ ഇത് നിങ്ങളെ സഹായിക്കുന്നു. ഏത് യന്ത്രമാണ് നിർമ്മിക്കേണ്ടത്, അത് ആർക്ക് വേണ്ടിയുള്ളതാണ്, അല്ലെങ്കിൽ മനുഷ്യസഹജമായ കാഴ്ചപ്പാടിൽ വിജയം എന്നാൽ എന്താണ് എന്നൊന്നും ഇത് തീരുമാനിക്കുന്നില്ല. ഏത് ഫീച്ചറാണ് പ്രസക്തമാകുന്നത്, ഏത് റിസ്ക് സ്വീകരിക്കാം, എപ്പോൾ ലക്ഷ്യം തന്നെ മാറ്റേണ്ടതുണ്ട് എന്നതിനെക്കുറിച്ചുള്ള വിവേചനാധികാരം നിങ്ങളുടേതാണ്. സ്വയം ഓട്ടോമാറ്റിക്കായി പരിശോധിക്കാൻ (verify) നിങ്ങൾക്ക് കൃത്യമായി അറിയാവുന്ന ജോലികൾക്കായി മാത്രം ലൂപ്പുകൾ നിർമ്മിക്കുക. മറ്റെല്ലാ കാര്യങ്ങളുടെയും നിയന്ത്രണം നിങ്ങളുടെ കൈകളിൽ തന്നെ നിലനിർത്തുക.
ഈ ലേഖനം Isaac Hagoel “Loop Engineering Minus The Hype.”-ൽ പങ്കുവെച്ച ആശയങ്ങളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്. കൂടുതൽ എൻജിനീയറിംഗ് ചർച്ചകൾക്കായി, Telegram-ലെ ഞങ്ങളുടെ ലേണിംഗ് കമ്മ്യൂണിറ്റിയിൽ ചേരുക.