ഹാർനെസ് എഞ്ചിനീയറിംഗ്: ഏജന്റ്-കളുടെ ലോകത്ത് Codex-ന്‍റെ ലിവറേജ്

കഴിഞ്ഞ അഞ്ച് മാസങ്ങളായി, ഞങ്ങളുടെ ടീം ഒരു പരീക്ഷണം നടത്തിവരികയാണ്: കൈകൊണ്ട് എഴുതിയ ഒരു വരി കോഡ് പോലും ഇല്ലാതെ ഒരു സോഫ്റ്റ്‌വെയർ ഉൽപ്പന്നത്തിന്റെ ആന്തരിക ബീറ്റ നിർമ്മിക്കുകയും ഷിപ്പ് ചെയ്യുകയും ചെയ്യുക.

ഉൽപ്പന്നത്തിന് ദൈനംദിന ആന്തരിക ഉപയോക്താക്കളും ബാഹ്യ ആൽഫ ടെസ്റ്റർമാരും ഉണ്ട്. ഇത് ഷിപ്പ് ചെയ്യുന്നു, വിന്യസിക്കുന്നു, തകരുന്നു, പിന്നെ പരിഹരിക്കപ്പെടുന്നു. വ്യത്യസ്തമായ കാര്യം, കോഡിന്റെ ഓരോ വരിയും—ആപ്ലിക്കേഷൻ ലോജിക്, ടെസ്റ്റുകൾ, CI കോൺഫിഗറേഷൻ, ഡോക്യുമെന്റേഷൻ, ഒബ്സർവബിലിറ്റി, ആഭ്യന്തര ടൂളിംഗ്—Codex എഴുതിയതാണ് എല്ലാം. കൈകൊണ്ട് കോഡ് എഴുതാൻ എടുക്കേണ്ട സമയത്തിന്റെ ഏകദേശം പത്തിലൊന്നു ഭാഗം സമയം കൊണ്ട് ഞങ്ങൾ ഇത് നിർമ്മിച്ചതായി കണക്കാക്കുന്നു.

മനുഷ്യർ നിയന്ത്രിക്കുന്നു. ഏജന്റുകൾ പ്രവർത്തിക്കുന്നു.

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

ഏജൻ്റുകളുടെ ഒരു ടീമിനൊപ്പം ഒരു പുത്തൻ ഉൽപ്പന്നം നിർമ്മിച്ചതിലൂടെ ഞങ്ങൾ എന്താണ് പഠിച്ചത്—എന്താണ് തകര്ന്നത്, എന്താണ് കൂട്ടിച്ചേർന്നത്, കൂടാതെ നമ്മുടെ അപൂർവമായ ഒരേയൊരു വിഭവം: മനുഷ്യരുടെ സമയംയും ശ്രദ്ധയും എങ്ങനെ പരമാവധി പ്രയോജനപ്പെടുത്താം എന്നതിനെക്കുറിച്ചാണ് ഈ പോസ്റ്റ്.

ഒരു ശൂന്യമായ റിപ്പോസിറ്ററിയിലേക്കുള്ള ആദ്യ കമ്മിറ്റ് 2025 ഓഗസ്റ്റിന്റെ അവസാനം എത്തി.

ആദ്യ സ്കാഫോൾഡ്—റിപ്പോസിറ്ററി ഘടന, CI കോൺഫിഗറേഷൻ, ഫോർമാറ്റിംഗ് നിയമങ്ങൾ, പാക്കേജ് മാനേജർ സജ്ജീകരണം, ആപ്ലിക്കേഷൻ ഫ്രെയിംവർക്ക്—നിലവിലുള്ള കുറച്ച് ടെംപ്ലേറ്റുകളുടെ ഒരു ചെറിയ സെറ്റിന്റെ മാർഗ്ഗനിർദ്ദേശത്തോടെ GPT‑5 ഉപയോഗിച്ച് Codex CLI സൃഷ്ടിച്ചതാണ്. ഏജൻ്റുകൾക്ക് റിപ്പോസിറ്ററിയിൽ എങ്ങനെ പ്രവർത്തിക്കണമെന്ന് നിർദ്ദേശിക്കുന്ന പ്രാരംഭ AGENTS.md ഫയൽ പോലും Codex തന്നെയാണ് എഴുതിയത്.

സിസ്റ്റത്തിന് റെഫെറന്‍സ് ആയി മനുഷ്യർ എഴുതിയ കോഡ് ഒന്നും അപ്പോള്‍ നിലവിലുണ്ടായിരുന്നില്ല. ആരംഭം മുതൽ, റിപ്പോസിറ്ററി രൂപപ്പെടുത്തിയത് ഏജന്റ് ആണ്.

അഞ്ച് മാസങ്ങൾക്ക് ശേഷം, ആപ്ലിക്കേഷൻ ലോജിക്, ഇൻഫ്രാസ്ട്രക്ചർ, ടൂളിംഗ്, ഡോക്യുമെന്റേഷൻ, ആന്തരിക ഡെവലപ്പർ ഉപകരണങ്ങൾ എന്നിവയിലുടനീളം, റിപ്പോസിറ്ററിയിൽ ഏകദേശം ഒരു ദശലക്ഷം കോഡ് ലൈനുകൾ അടങ്ങിയിരിക്കുന്നു. ആ കാലയളവിൽ, Codex-നെ മുന്നോട്ട് നയിച്ച വെറും മൂന്ന് എഞ്ചിനീയർമാരടങ്ങുന്ന ചെറിയ ടീമിനൊപ്പം, ഏകദേശം 1,500 pull request-കൾ തുറക്കുകയും കൂട്ടിച്ചേർക്കുകയും ചെയ്തു. ഇത് ഒരു എഞ്ചിനീയറിന് ഒരു ദിവസത്തിൽ ശരാശരി 3.5 PRs എന്ന ത്രൂപുട്ടായി കണക്കാക്കാം, അതിശയകരമായ കാര്യം, ടീം ഇപ്പോൾ ഏഴ് എഞ്ചിനീയർമാരായി വളർന്നിട്ടും ത്രൂപുട്ട് വർദ്ധിച്ചിട്ടുണ്ട്. പ്രധാനമായി, ഇത് ഔട്ട്പുട്ടിനുവേണ്ടിയുള്ള ഔട്ട്പുട്ട് ആയിരുന്നില്ല: ഉൽപ്പന്നം നൂറുകണക്കിന് ഉപയോക്താക്കൾ ആന്തരികമായി ഉപയോഗിച്ചുവരുന്നു, ദിവസേന ഉപയോഗിക്കുന്ന ആന്തരിക പവർ ഉപയോക്താക്കളും ഉൾപ്പെടെ.

വികസന പ്രക്രിയയിലുടനീളം, കോഡിൽ ഒരിക്കലും നേരിട്ട് മനുഷ്യ സംഭാവന ചെയ്തിട്ടില്ല. ഇത് ടീമിന് ഒരു മുഖ്യ തത്വശാസ്ത്രമായി മാറി: മാനുവലായി എഴുതിയ കോഡ് ഇല്ല.

പ്രായോഗിക മനുഷ്യ കോഡിംഗ് ഇല്ലായ്മ സിസ്റ്റങ്ങൾ, സ്കാഫോൾഡിംഗ്, ലിവറേജ് എന്നിവയിൽ കേന്ദ്രീകരിച്ച, വ്യത്യസ്ത തരത്തിലുള്ള എഞ്ചിനീയറിംഗ് ജോലിക്ക് തുടക്കം കുറിച്ചു.

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

പ്രായോഗികമായി, ഇതിന്റെ അർത്ഥം ഡെപ്ത്-ഫസ്റ്റ് രീതിയിൽ പ്രവർത്തിക്കുകയായിരുന്നു: വലിയ ലക്ഷ്യങ്ങളെ ചെറിയ നിർമാണഘടകങ്ങളായി (ഡിസൈൻ, കോഡ്, റിവ്യൂ, ടെസ്റ്റ്, മുതലായവ) വിഭജിക്കുക, ആ ഘടകങ്ങൾ നിർമ്മിക്കാൻ ഏജന്റിനോട് നിർദ്ദേശം നൽകുക, കൂടാതെ കൂടുതൽ സങ്കീർണ്ണമായ ടാസ്കുകൾ തുറക്കാൻ അവ ഉപയോഗിക്കുക. എന്തെങ്കിലും പരാജയപ്പെട്ടാൽ, പരിഹാരം മിക്കവാറും ഒരിക്കലും “കൂടുതൽ ശ്രമിക്കുക” എന്നതായിരുന്നില്ല. പുരോഗതി കൈവരിക്കാനുള്ള ഏക മാർഗം Codex-നെ ജോലി ചെയ്യിപ്പിക്കുകയായിരുന്നതിനാൽ, മനുഷ്യ എഞ്ചിനീയർമാർ എല്ലായ്പ്പോഴും ആ ടാസ്കിൽ ഇടപെട്ട് ചോദിച്ചു: “ഏത് ശേഷിയാണ് ഇല്ലാത്തത്, അതിനെ ഏജന്റിനു വായിക്കാവുന്നതും നടപ്പാക്കാൻ കഴിയുന്നതുമായ രീതിയിൽ നമുക്ക് എങ്ങനെ നിര്‍മ്മിക്കാം?”

മനുഷ്യർ സിസ്റ്റവുമായി മിക്കവാറും മുഴുവനായും പ്രോംപ്റ്റുകൾ വഴിയാണ് ഇടപെടുന്നത്: ഒരു എഞ്ചിനീയർ ഒരു ടാസ്ക് വിവരിക്കുന്നു, ഏജന്റ് പ്രവർത്തിപ്പിക്കുന്നു, അത് ഒരു പുൾ റിക്വസ്റ്റ് തുറക്കാൻ അനുവദിക്കുന്നു. ഒരു PR പൂർത്തിയാക്കാൻ, ഞങ്ങൾ Codex-നെ അതിന്റെ സ്വന്തം മാറ്റങ്ങൾ ലോക്കലായി അവലോകനം ചെയ്യാൻ, ലോക്കലിലും ക്ലൗഡിലും പ്രത്യേക ഏജന്റ് അവലോകനങ്ങൾ അഭ്യർത്ഥിക്കാൻ, മനുഷ്യരും ഏജന്റുകളും നൽകിയ ഫീഡ്ബാക്കുകൾക്ക് പ്രതികരിക്കാൻ, എല്ലാ ഏജന്റ് അവലോകകരും തൃപ്തരാകുന്നതുവരെ ഒരു ലൂപ്പിൽ ആവർത്തിച്ച് തുടരാൻ നിർദ്ദേശിക്കുന്നു (പ്രായോഗികമായി ഇത് ഒരു Ralph Wiggum Loop⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ആണ്). Codex മനുഷ്യർ CLI-യിലേക്ക് കോപ്പി ചെയ്ത് പേസ്റ്റ് ചെയ്യാതെ തന്നെ കോൺടെക്സ്റ്റ് ശേഖരിക്കാൻ ഞങ്ങളുടെ സ്റ്റാൻഡേർഡ് ഡെവലപ്‌മെന്റ് ടൂളുകൾ (gh, ലോക്കൽ സ്ക്രിപ്റ്റുകൾ, റിപ്പോസിറ്ററിയിൽ ഉൾപ്പെടുത്തിയിരിക്കുന്ന സ്കിൽസ്) നേരിട്ട് ഉപയോഗിക്കുന്നു.

മനുഷ്യർ pull request അവലോകനം ചെയ്‌തേക്കാം, പക്ഷേ അത് നിർബന്ധമല്ല. കാലക്രമേണ, ഞങ്ങൾ മിക്കവാറും എല്ലാ അവലോകന ശ്രമവും ഏജന്റ്-ടു-ഏജന്റ് ആയി കൈകാര്യം ചെയ്യുന്നതിലേക്കാണ് മാറ്റിയത്.

കോഡ് ത്രൂപുട്ട് വർദ്ധിച്ചതോടെ, ഞങ്ങളുടെ തടസ്സം മനുഷ്യ QA ശേഷിയായി മാറി. മനുഷ്യരുടെ സമയംയും ശ്രദ്ധയും സ്ഥിരമായ നിയന്ത്രണമായതിനാൽ, ആപ്ലിക്കേഷൻ UI, ലോഗുകൾ, ആപ്പ് മെട്രിക്‌സ് എന്നിവ Codex-ന് നേരിട്ട് വായിക്കാവുന്ന രീതിയിലാക്കുന്നതിലൂടെ, ഏജന്റിന് കൂടുതൽ കഴിവുകൾ ചേർക്കാൻ ഞങ്ങൾ ശ്രമിച്ചു.

ഉദാഹരണത്തിന്, ഗിറ്റ് വര്‍ക്ക് ട്രീ അനുസരിച്ച് ആപ്പ് ബൂട്ടുചെയ്യാവുന്ന വിധത്തില്‍ ഞങ്ങൾ ഒരുക്കി, അതിനാൽ Codex- ന് ഓരോ മാറ്റത്തിനും ഒരു ഇൻസ്റ്റൻസ് ലോഞ്ച് ചെയ്ത് നിയന്ത്രിക്കാൻ കഴിയും. ഞങ്ങൾ ക്രോം DevTools പ്രോട്ടോക്കോൾ ഏജന്റ് റൺടൈമിലേക്ക് വയർ ചെയ്‌തതോടൊപ്പം DOM സ്നാപ്ഷോട്ടുകൾ, സ്ക്രീൻഷോട്ടുകൾ, നാവിഗേഷൻ എന്നിവയുമായി പ്രവർത്തിക്കുന്നതിനുള്ള കഴിവുകളും സൃഷ്ടിച്ചു. ഇത് Codex-ന് ബഗുകൾ പുനരുത്പാദിപ്പിക്കാനും, പരിഹാരങ്ങൾ സാധൂകരിക്കാനും, UI പെരുമാറ്റത്തെക്കുറിച്ച് നേരിട്ട് ചിന്തിക്കാനും പ്രാപ്തമാക്കി.

നിരീക്ഷണ ടൂളിംഗിനും ഞങ്ങൾ അതേപോലെ ചെയ്തു. ലോഗുകൾ, മെട്രിക്കുകൾ, ട്രേസുകൾ എന്നിവ ഓരോ വര്‍ക്ക്‌ ട്രീക്കും താൽക്കാലികമായ ഒരു പ്രാദേശിക ഒബ്സർവബിലിറ്റി സ്റ്റാക്ക് വഴി Codex-ന് ലഭ്യമാക്കുന്നു. Codex ആ ആപ്പിന്റെ പൂർണ്ണമായും ഒറ്റപ്പെട്ട പതിപ്പിൽ പ്രവർത്തിക്കുന്നു—അതിന്റെ ലോഗുകളും മെട്രിക്‌സും ഉൾപ്പെടെ, ആ ടാസ്ക് പൂർത്തിയായാൽ അവ നീക്കം ചെയ്യപ്പെടും. ഏജന്റുകൾക്ക് LogQL ഉപയോഗിച്ച് ലോഗുകൾ ക്വറി ചെയ്യാനും PromQL ഉപയോഗിച്ച് മെട്രിക്‌സ് ക്വറി ചെയ്യാനും കഴിയും. ഈ സാഹചര്യത്തിൽ ലഭ്യമായതിനാൽ, “800ms-ന് ഉള്ളില്‍ സര്‍വീസ് സ്റ്റാര്‍ട്ട്‌ അപ്പ്‌ പൂര്‍ത്തിയാകുന്നു എന്ന് ഉറപ്പാക്കുക ” അല്ലെങ്കിൽ “ഈ നാല് നിർണായക ഉപയോക്തൃ യാത്രകളിൽ ഏതെങ്കിലും സ്പാൻ രണ്ട് സെക്കൻഡിൽ കൂടുതലാകരുത്” എന്ന പ്രോംപ്റ്റുകൾ കൈകാര്യം ചെയ്യാൻ സാധ്യമാണ്.

ഞങ്ങൾ പതിവായി കാണുന്നത്, ഒരൊറ്റ Codex റൺ ഒരു ടാസ്കിൽ ആറു മണിക്കൂറിലധികം പ്രവർത്തിക്കുന്നത് ആണ് (പലപ്പോഴും മനുഷ്യർ ഉറങ്ങുമ്പോൾ).

വലിയതും സങ്കീർണ്ണവുമായ ടാസ്കുകളിൽ ഏജന്റുകളെ ഫലപ്രദമാക്കുന്നതിലെ ഏറ്റവും വലിയ വെല്ലുവിളികളിൽ ഒന്നാണ് കോൺടെക്സ്റ്റ് മാനേജ്മെന്റ്. ഞങ്ങൾ പഠിച്ച ആദ്യകാല പാഠങ്ങളിൽ ഒന്ന് ലളിതമായിരുന്നു: Codex-ന് ഒരു മാപ്പ് നൽകുക, 1,000 പേജുള്ള നിർദ്ദേശ മാനുവൽ അല്ല.

ഞങ്ങൾ “ഒരൊറ്റ വലിയ AGENTS.md⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു)” പരീക്ഷിച്ചു സമീപനം. ഇത് പ്രതീക്ഷിക്കപ്പെട്ട രീതികളിൽ പരാജയപ്പെട്ടു:

• സന്ദർഭം അപൂർവമായ ഒരു വിഭവമാണ്. ഒരു ഭീമമായ നിർദ്ദേശ ഫയൽ ടാസ്ക്, കോഡ്, ബന്ധപ്പെട്ട ഡോക്സ് എന്നിവയെ മറികടന്ന് നിറയുന്നു—അതിനാൽ ഏജന്റ് പ്രധാന നിയന്ത്രണങ്ങൾ കാണാതെ പോകുകയോ തെറ്റായവയ്ക്കായി ഓപ്റ്റിമൈസ് ചെയ്യാൻ തുടങ്ങുകയോ ചെയ്യുന്നു.
• അധിക മാർഗ്ഗനിർദ്ദേശം മാർഗനിർദ്ദേശമല്ലാതാകുന്നു. എല്ലാം “പ്രധാനമാണ്” എങ്കിൽ, ഒന്നും പ്രധാനമല്ല. ഏജൻ്റുകൾ ഉദ്ദേശപൂർവ്വമായി നാവിഗേറ്റ് ചെയ്യുന്നതിനുപകരം പ്രാദേശികമായി പാറ്റേൺ-മാച്ചിംഗ് ചെയ്യുന്നു.
• ഇത് തൽക്ഷണം ഉപകാരമില്ലാത്തത് ആയി മാറുന്നു. ഒരു ഏകഘടിത മാനുവൽ പഴകിയ നിയമങ്ങളുടെ ശ്മശാനമായി മാറുന്നു. ഏജൻ്റുകൾക്ക് എന്താണ് ഇപ്പോഴും ശരിയെന്ന് തിരിച്ചറിയാൻ കഴിയുന്നില്ല, മനുഷ്യർ അത് പരിപാലിക്കുന്നത് നിർത്തുന്നു, ഫയൽ നിശ്ശബ്ദമായി ഒരു ആകർഷകമായ പ്രശ്നമായി മാറുന്നു.
• സ്ഥിരീകരിക്കാൻ ബുദ്ധിമുട്ടാണ്. ഒരു സിംഗിൾ ബ്ലോബ് മെക്കാനിക്കൽ പരിശോധനകൾക്ക് (കവറേജ്, പുതുമ, ഉടമസ്ഥത, ക്രോസ്-ലിങ്കുകൾ) അനുയോജ്യമല്ല, അതിനാൽ ഡ്രിഫ്റ്റ് അനിവാര്യമാണ്.

അതുകൊണ്ട് AGENTS.md -നെ വിജ്ഞാനകോശമായി കാണുന്നതിന് പകരം, ഞങ്ങൾ അതിനെ വിഷയസൂചിക ആയി കാണുന്നു.

റിപ്പോസിറ്ററിയുടെ നോളജ് ബേസ് സിസ്റ്റം ഓഫ് റെക്കോർഡായി കണക്കാക്കപ്പെടുന്ന ഘടനാപരമായ docs/ ഡയറക്ടറിയിലാണ് നിലനിൽക്കുന്നത്. ഒരു ചെറിയ AGENTS.md (ഏകദേശം 100 വരികൾ) സന്ദർഭത്തിലേക്ക് ചേർക്കപ്പെടുകയും പ്രധാനമായും ഒരു മാപ്പായി പ്രവർത്തിക്കുകയും, മറ്റിടങ്ങളിലുള്ള കൂടുതൽ ആഴത്തിലുള്ള സത്യത്തിന്റെ ഉറവിടങ്ങളിലേക്കുള്ള സൂചനകൾ നൽകുകയും ചെയ്യുന്നു.

ഡിസൈൻ ഡോക്യുമെന്റേഷൻ കാറ്റലോഗ് ചെയ്യുകയും ഇൻഡെക്സ് ചെയ്യുകയും ചെയ്തിരിക്കുന്നു, ഇതിൽ വെരിഫിക്കേഷൻ നിലയും ഏജന്റ്-ഫസ്റ്റ് പ്രവർത്തന തത്വങ്ങളെ നിർവചിക്കുന്ന മുഖ്യ വിശ്വാസങ്ങളുടെ ഒരു സമുച്ചയവും ഉൾപ്പെടുന്നു. ആർക്കിടെക്ചർ ഡോക്യുമെന്റേഷൻ⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ഡൊമെയ്‌നുകളും പാക്കേജ് ലെയറിംഗും ഉൾപ്പെടുന്ന ഉയർന്ന തലത്തിലുള്ള മാപ്പ് നൽകുന്നു. ഒരു ഗുണനിലവാര രേഖ ഓരോ ഉൽപ്പന്ന ഡൊമെയ്‌നിനെയും ആർക്കിടെക്ചറൽ ലെയറിനെയും ഗ്രേഡ് ചെയ്യുകയും, കാലക്രമേണ ഗ്യാപ്പുകൾ പിന്തുടരുകയും ചെയ്യുന്നു.

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

ഇത് ക്രമാനുഗത വെളിപ്പെടുത്തൽ പ്രാപ്തമാക്കുന്നു: ഏജന്റുകൾ ചെറിയ, സ്ഥിരതയുള്ള പ്രവേശനബിന്ദുവിൽ നിന്ന് ആരംഭിക്കുകയും, തുടക്കത്തിൽ തന്നെ അമിതമായി വിവരഭാരം ഏൽപ്പിക്കാതെ, അടുത്തതായി എവിടെ നോക്കണമെന്ന് അവരെ പഠിപ്പിക്കുകയും ചെയ്യുന്നു.

ഞങ്ങൾ ഇത് യാന്ത്രികമായി നടപ്പാക്കുന്നു. പ്രത്യേക ലിന്ററുകളും CI ജോലികളും നോളജ് ബേസ് പുതുക്കിയതും ക്രോസ്-ലിങ്ക് ചെയ്തതും ശരിയായി ഘടിപ്പിച്ചതുമാണെന്ന് സ്ഥിരീകരിക്കുന്നു. ആവർത്തിച്ച് പ്രവർത്തിക്കുന്ന “doc-gardening” ഏജന്റ് യഥാർത്ഥ കോഡ് പെരുമാറ്റത്തെ പ്രതിഫലിപ്പിക്കാത്ത പഴകിയതോ കാലഹരണപ്പെട്ടതോ ആയ ഡോക്യുമെന്റേഷൻ കണ്ടെത്താൻ സ്കാൻ ചെയ്ത്, പരിഹാരത്തിനായുള്ള pull request തുറക്കുന്നു.

കോഡ്ബേസ് വികസിച്ചുവന്നതോടെ, ഡിസൈൻ തീരുമാനങ്ങൾക്കായുള്ള Codex-ന്റെ ചട്ടക്കൂടും വികസിക്കേണ്ടതുണ്ടായി.

റിപ്പോസിറ്ററി പൂർണ്ണമായും ഏജന്റ്-ജനറേറ്റ് ചെയ്തതുകൊണ്ട്, ഇത് ആദ്യം Codex ന്റെ വായനാസൗകര്യംക്കായി ഒപ്റ്റിമൈസ് ചെയ്തിരിക്കുന്നു. പുതിയ എഞ്ചിനീയറിംഗ് നിയമനങ്ങൾക്കായി അവരുടെ കോഡിന്റെ നാവിഗേഷനബിലിറ്റി മെച്ചപ്പെടുത്താൻ ടീമുകൾ ലക്ഷ്യമിടുന്നതുപോലെ, ഞങ്ങളുടെ മനുഷ്യ എഞ്ചിനീയർമാരുടെ ലക്ഷ്യം ഒരു ഏജന്റിന് മുഴുവൻ ബിസിനസ് ഡൊമെയ്നിനെക്കുറിച്ച് റിപ്പോസിറ്ററിയിൽ നിന്നുതന്നെ നേരിട്ട് ചിന്തിക്കാൻ സാധ്യമാക്കുക.

ഏജന്റിന്റെ കാഴ്ചപ്പാടിൽ നിന്ന്, പ്രവർത്തനസമയത്ത് സന്ദർഭത്തിനുള്ളിൽ അതിന് ആക്സസ് ചെയ്യാൻ കഴിയാത്ത ഏതൊന്നും ഫലത്തിൽ നിലവിലില്ലാത്തതുപോലെയാണ്. Google Docs-ലോ ചാറ്റ് ത്രെഡുകളിലോ ആളുകളുടെ മനസ്സിലോ ഉള്ള അറിവുകൾ സിസ്റ്റത്തിന് ആക്സസ് ചെയ്യാനാകില്ല. റിപ്പോസിറ്ററി-ലോക്കൽ, വേർഷൻ ചെയ്ത ആർട്ടിഫാക്റ്റുകൾ (ഉദാ., കോഡ്, മാർക്ക്ഡൗൺ, സ്കീമകൾ, എക്സിക്യൂട്ടബിൾ പ്ലാനുകൾ) മാത്രമാണ് അതിന് കാണാൻ കഴിയുന്നത്.

കാലക്രമേണ കൂടുതൽ കൂടുതൽ സന്ദർഭം റിപ്പോസിറ്ററിയിലേക്ക് ചേർക്കേണ്ടതുണ്ടെന്ന് ഞങ്ങൾ മനസ്സിലാക്കി. ടീമിനെ ഒരു ആർക്കിടെക്ചറൽ പാറ്റേണിൽ ഏകോപിപ്പിച്ച ആ സ്ലാക്ക് ചർച്ച? ഏജന്റിന് കണ്ടെത്താനാകാത്തതാണെങ്കിൽ, മൂന്ന് മാസം കഴിഞ്ഞ് ചേർന്ന ഒരു പുതിയ നിയമനത്തിന് അത് അറിയാത്തതുപോലെ, അത് വായിക്കാനാകാത്തതാണ്.

Codex-ന് കൂടുതൽ സന്ദർഭം നൽകുന്നത്, താൽക്കാലിക നിർദ്ദേശങ്ങളാൽ അതിനെ അമിതഭാരപ്പെടുത്തുന്നതിന് പകരം, ഏജന്റിന് അതിനെ അടിസ്ഥാനമാക്കി ചിന്തിക്കാൻ കഴിയുന്ന വിധത്തിൽ ശരിയായ വിവരങ്ങൾ ക്രമീകരിക്കുകയും ലഭ്യമാക്കുകയും ചെയ്യുന്നതാണ്. നിങ്ങൾ ഉൽപ്പന്ന തത്വങ്ങൾ, എഞ്ചിനീയറിംഗ് മാനദണ്ഡങ്ങൾ, ടീമിന്റെ സംസ്കാരം (ഇമോജി മുൻഗണനകൾ ഉൾപ്പെടെ) എന്നിവയിൽ ഒരു പുതിയ ടീമംഗത്തെ പരിചയപ്പെടുത്തുന്നതുപോലെ, ഈ വിവരങ്ങൾ ഏജന്റിന് നൽകുന്നത് കൂടുതൽ പൊരുത്തമുള്ള ഫലത്തിലേക്ക് നയിക്കുന്നു.

ഈ ചട്ടക്കൂട് പല ത്യാഗങ്ങളും നേട്ടങ്ങളും വ്യക്തമാക്കി. റെപ്പോയ്ക്കുള്ളിൽ പൂർണ്ണമായി ഉൾക്കൊള്ളുകയും യുക്തിപരമായി ചിന്തിക്കുകയും ചെയ്യാൻ കഴിയുന്ന ആശ്രിതത്വങ്ങളും അബ്സ്ട്രാക്ഷനുകളും ഞങ്ങൾ മുൻഗണിച്ചു. “ബോറിംഗ്” എന്ന് പലപ്പോഴും വിശേഷിപ്പിക്കപ്പെടുന്ന സാങ്കേതികവിദ്യകൾ, സംയോജ്യത, API സ്ഥിരത, പരിശീലന സെറ്റിലെ പ്രതിനിധാനം എന്നിവ കാരണം ഏജന്റുകൾക്ക് മോഡൽ ചെയ്യാൻ സാധാരണയായി കൂടുതൽ എളുപ്പമാണ്. ചില സന്ദർഭങ്ങളിൽ, പൊതുജന ലൈബ്രറികളിൽ നിന്നുള്ള അസ്പഷ്ടമായ അപ്സ്ട്രീം പെരുമാറ്റത്തെ മറികടക്കുന്നതിനേക്കാൾ, പ്രവർത്തനക്ഷമതയുടെ ചില ഉപസമൂഹങ്ങൾ ഏജന്റിനെ കൊണ്ട് വീണ്ടും നടപ്പിലാക്കുന്നത് ചെലവ് കുറഞ്ഞതായിരുന്നു. ഉദാഹരണത്തിന്, ഒരു ജനറിക് p-limit-സ്റ്റൈൽ പാക്കേജ് ഉൾപ്പെടുത്തുന്നതിനുപകരം, ഞങ്ങൾ സ്വന്തമായി ഒരു map-with-concurrency ഹെൽപ്പർ നടപ്പിലാക്കി: ഇത് ഞങ്ങളുടെ OpenTelemetry ഇൻസ്ട്രുമെന്റേഷനുമായി കർശനമായി സംയോജിപ്പിച്ചിരിക്കുന്നു, 100% ടെസ്റ്റ് കവറേജ് ഉണ്ട്, കൂടാതെ ഞങ്ങളുടെ റൺടൈം പ്രതീക്ഷിക്കുന്നതുപോലെ കൃത്യമായി പ്രവർത്തിക്കുന്നു.

ഏജന്റിന് പരിശോധിക്കാനും, സാധൂകരിക്കാനും, നേരിട്ട് പരിഷ്‌കരിക്കാനും കഴിയുന്ന രീതിയിൽ സിസ്റ്റത്തിന്റെ കൂടുതൽ ഭാഗങ്ങളെ കൊണ്ടുവരുന്നത് ലിവറേജ് വർദ്ധിപ്പിക്കുന്നു—Codex-നു മാത്രമല്ല, മറ്റ് ഏജന്റുകൾക്കും (ഉദാ. Aardvark) കോഡ്ബേസിലും പ്രവർത്തിക്കുന്നവരും.

ഡോക്യുമെൻറേഷൻ മാത്രം ഒരു പൂർണ്ണമായും ഏജന്റ്-ജനറേറ്റ് ചെയ്ത കോഡ്ബേസിനെ ഏകോപിതമാക്കാൻ പോരാ. ഇംപ്ലിമെന്റേഷനുകൾ മൈക്രോമാനേജ് ചെയ്യാതെ ഇൻവേറിയന്റുകൾ കർശനമായി പാലിപ്പിക്കുന്നതിലൂടെ, അടിത്തറ തകർക്കാതെ ഏജന്റുകൾക്ക് വേഗത്തിൽ ഷിപ്പ് ചെയ്യാൻ നാം അനുവദിക്കുന്നു. ഉദാഹരണത്തിന്, Codex-നെ ബൗണ്ടറിയിൽ ഡാറ്റാ രൂപങ്ങൾ പാഴ്സ് ചെയ്യാൻ⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ഞങ്ങൾ ആവശ്യപ്പെടുന്നു, പക്ഷേ അത് എങ്ങനെ നടക്കണം എന്നതിൽ ഞങ്ങൾ നിർദ്ദേശങ്ങൾ നൽകുന്നില്ല (മോഡൽ Zod-നെ ഇഷ്ടപ്പെടുന്നുവെന്ന് തോന്നുന്നു, പക്ഷേ ആ പ്രത്യേക ലൈബ്രറി ഞങ്ങൾ നിർദ്ദേശിച്ചിട്ടില്ല).

ഏജൻ്റുകൾ കർശനമായ അതിരുകളും പ്രവചിക്കാവുന്ന ഘടനയും⁠(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ഉള്ള പരിതസ്ഥിതികളിലാണ് ഏറ്റവും ഫലപ്രദം, അതിനാൽ ഞങ്ങൾ ആപ്ലിക്കേഷൻ ഒരു കർശനമായ ആർക്കിടെക്ചറൽ മോഡൽ ചുറ്റിപ്പറ്റി നിർമ്മിച്ചു. ഓരോ ബിസിനസ് ഡൊമെയ്‌നും നിശ്ചിതമായ ലെയറുകളുടെ ഒരു സെറ്റായി വിഭജിച്ചിരിക്കുന്നു, കർശനമായി മൂല്യനിർണ്ണയം ചെയ്ത ആശ്രിതത്വ ദിശകളും അനുവദനീയമായ എഡ്ജുകളുടെ പരിമിതമായ ഒരു സെറ്റും ഉൾക്കൊള്ളുന്നു. ഈ നിയന്ത്രണങ്ങൾ കസ്റ്റം ലിന്ററുകൾ (Codex-ജനറേറ്റ് ചെയ്തവ, തീർച്ചയായും!) കൂടാതെ ഘടനാപരമായ ടെസ്റ്റുകൾ വഴിയും യാന്ത്രികമായി നടപ്പിലാക്കപ്പെടുന്നു.

താഴെയുള്ള ഡയഗ്രാം നിയമം കാണിക്കുന്നു: ഓരോ ബിസിനസ് ഡൊമെയ്‌നിനുള്ളിലും (ഉദാ. ആപ്പ് ക്രമീകരണങ്ങൾ), കോഡ് ഒരു നിശ്ചിത പാളികളുടെ സെറ്റ് (ടൈപ്പ് → കോണ്ഫിഗറേഷന്‍ → റിപ്പോ→ സര്‍വീസ്→ റണ്‍ ടൈം→ UI) വഴിയായി “മുന്നോട്ട്” മാത്രമേ ആശ്രയിക്കാവൂ. ക്രോസ്-കട്ടിംഗ് ആശങ്കകൾ (auth, കണക്ടറുകള്‍ , ടെലിമെട്രി, ഫീച്ചർ ഫ്ലാഗുകൾ) ഒരു ഒറ്റ വ്യക്തമായ ഇന്റർഫേസിലൂടെ പ്രവേശിക്കുന്നു: പ്രൊവൈഡേഴ്സ്. മറ്റെന്തും അനുവദനീയമല്ല, കൂടാതെ അത് യാന്ത്രികമായി പ്രാബല്യത്തിൽ വരുത്തപ്പെടുന്നു.

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

പ്രായോഗികമായി, കസ്റ്റം ലിന്ററുകളും ഘടനാപരമായ പരിശോധനകളും, കൂടാതെ ചെറിയൊരു “റുചി സ്ഥിരതകൾ” സെറ്റും ഉപയോഗിച്ച് ഞങ്ങൾ ഈ നിയമങ്ങൾ നടപ്പിലാക്കുന്നു. ഉദാഹരണത്തിന്, ഞങ്ങൾ കസ്റ്റം ലിന്റുകൾ ഉപയോഗിച്ച് ഘടനാപരമായ ലോഗിംഗ്, സ്കീമകൾക്കും ടൈപ്പുകൾക്കും പേരിടൽ കൺവെൻഷനുകൾ, ഫയൽ വലുപ്പ പരിധികൾ, പ്ലാറ്റ്‌ഫോം-സ്പെസിഫിക് വിശ്വസനീയത ആവശ്യകതകൾ എന്നിവ സ്റ്റാറ്റിക്കായി നടപ്പിലാക്കുന്നു. ലിന്റുകൾ ഇഷ്ടാനുസൃതമായതിനാൽ, ഏജന്റ് സന്ദർഭത്തിലേക്ക് പരിഹാര നിർദ്ദേശങ്ങൾ ഉൾപ്പെടുത്തുന്നതിനായി പിശക് സന്ദേശങ്ങൾ ഞങ്ങൾ എഴുതുന്നു.

മനുഷ്യനെ മുൻനിർത്തിയ പ്രവൃത്തി പ്രവാഹത്തിൽ, ഈ നിയമങ്ങൾ സൂക്ഷ്മമായതോ നിയന്ത്രണാത്മകമായതോ ആയി തോന്നാം. ഏജന്റുകളുമായി, അവ ഗുണിതാക്കൾ ആകുന്നു: ഒരിക്കൽ എൻകോഡ് ചെയ്താൽ, അവ എല്ലായിടത്തും ഒരേസമയം പ്രയോഗിക്കപ്പെടുന്നു.

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

ഫലമായി ലഭിക്കുന്ന കോഡ് എല്ലായ്പ്പോഴും മനുഷ്യരുടെ ശൈലീഭാവനകളുമായി പൊരുത്തപ്പെടണമെന്നില്ല, പക്ഷെ അത് പ്രശ്നമല്ല. ഔട്ട്പുട്ട് ശരിയായതും, പരിപാലിക്കാവുന്നതും, ഭാവിയിലെ ഏജന്റ് പ്രവർത്തനങ്ങൾക്ക് വായിക്കാൻ എളുപ്പമുള്ളതുമാണെങ്കിൽ, അത് മാനദണ്ഡം നിറവേറ്റുന്നു.

മനുഷ്യന്റെ രുചി സിസ്റ്റത്തിലേക്ക് തുടർച്ചയായി തിരിച്ചുനൽകപ്പെടുന്നു. അവലോകന കമന്റുകൾ, റീഫാക്ടറിംഗ് pull request, ഉപയോക്താവിനെ നേരിട്ട് ബാധിക്കുന്ന ബഗുകൾ എന്നിവ ഡോക്യുമെന്റേഷൻ അപ്ഡേറ്റുകളായി രേഖപ്പെടുത്തുകയോ അല്ലെങ്കിൽ ടൂളിംഗിൽ നേരിട്ട് എൻകോഡ് ചെയ്യുകയോ ചെയ്യുന്നു. ഡോക്യുമെന്റേഷൻ പര്യാപ്തമല്ലാത്തപ്പോൾ, ഞങ്ങൾ ആ നിയമത്തെ കോഡിലേക്ക് ഉയർത്തുന്നു

Codex-ന്റെ ത്രൂപുട്ട് വർദ്ധിച്ചതോടെ, പല പരമ്പരാഗത എഞ്ചിനീയറിംഗ് മാനദണ്ഡങ്ങളും പ്രത്യുത്പാദകമല്ലാതായി.

റിപ്പോസിറ്ററി കുറഞ്ഞ തടസ്സമുള്ള മെർജ് ഗേറ്റുകളോടെ പ്രവർത്തിക്കുന്നു. pull request -കളുടെ നിലനില്‍പ്പ്‌ ഹ്രസ്വകാലമാണ്. ടെസ്റ്റ് ഫ്ലേക്കുകൾ പലപ്പോഴും പുരോഗതി അനന്തമായി തടയാതെ ഫോളോ-അപ്പ് റൺസുകൾ വഴി പരിഹരിക്കപ്പെടുന്നു. ഏജന്റിന്റെ ത്രൂപുട്ട് മനുഷ്യന്റെ ശ്രദ്ധയെ വളരെ മറികടക്കുന്ന ഒരു സിസ്റ്റത്തിൽ, തിരുത്തലുകൾ വിലകുറഞ്ഞതും കാത്തിരിപ്പ് ചെലവേറിയതുമാണ്.

കുറഞ്ഞ-ത്രൂപുട്ട് പരിതസ്ഥിതിയിൽ ഇത് ഉത്തരവാദിത്വമില്ലാത്തതാണ്. ഇവിടെ, പലപ്പോഴും ശരിയായ സമവായം ആണ് ഇത്.

Codex ഏജൻ്റുകൾ കോഡ്ബേസ് സൃഷ്ടിച്ചതാണെന്ന് ഞങ്ങൾ പറയുമ്പോൾ, ഞങ്ങൾ ഉദ്ദേശിക്കുന്നത് കോഡ്ബേസിലെ എല്ലാം തന്നെയാണ്.

ഏജന്റുമാർ ഉൽപ്പാദിപ്പിക്കുന്നു:

• ഉൽപ്പന്ന കോഡും പരീക്ഷണങ്ങളും
• CI കോൺഫിഗറേഷനും റിലീസ് ടൂളിംഗും
• ആന്തരിക ഡെവലപ്പർ ഉപകരണങ്ങൾ
• ഡോക്യുമെന്റേഷൻയും ഡിസൈൻ ചരിത്രവും
• വിലയിരുത്തൽ ഹാർനെസുകൾ
• അവലോകന അഭിപ്രായങ്ങളും പ്രതികരണങ്ങളും
• റിപ്പോസിറ്ററിയെ സ്വയം മാനേജുചെയ്യുന്ന സ്ക്രിപ്റ്റുകൾ
• ഉത്പാദന ഡാഷ്‌ബോർഡ് നിർവചന ഫയലുകൾ

മനുഷ്യർ എപ്പോഴും പ്രക്രിയയിൽ ഉൾപ്പെടും, എന്നാൽ അവർ മുമ്പ് ചെയ്തിരുന്നതിനെക്കാൾ വ്യത്യസ്തമായ ഒരു അബ്സ്ട്രാക്ഷൻ ലെയറിൽ പ്രവർത്തിക്കും. ഞങ്ങൾ ജോലിക്ക് മുൻഗണന നൽകുന്നു, ഉപയോക്തൃ ഫീഡ്ബാക്ക് അംഗീകാര മാനദണ്ഡങ്ങളാക്കി മാറ്റുന്നു, ഫലങ്ങൾ സാധൂകരിക്കുന്നു. ഏജന്റ് ബുദ്ധിമുട്ടുമ്പോൾ, അത് ഒരു സിഗ്നലായി കാണുന്നു: എന്താണ് കുറവെന്ന് തിരിച്ചറിയുക—ഉപകരണങ്ങൾ, ഗാർഡ്റെയിലുകൾ, ഡോക്യുമെൻറേഷൻ—അവയെല്ലാം തിരിച്ചറിയുകയും, അത് റിപ്പോസിറ്ററിയിലേക്ക് തിരിച്ചയക്കുകയും, എല്ലായ്പ്പോഴും Codex തന്നെ പരിഹാരം എഴുതുന്നതിന് ഉപയോഗിക്കുകയും ചെയ്യുക.

ഏജൻ്റുകൾ ഞങ്ങളുടെ സ്റ്റാൻഡേർഡ് ഡെവലപ്പ്മെന്റ് ടൂളുകൾ നേരിട്ട് ഉപയോഗിക്കുന്നു. അവർ റിവ്യൂ ഫീഡ്ബാക്ക് എടുക്കുന്നു, ഇൻലൈൻ ആയി പ്രതികരിക്കുന്നു, അപ്ഡേറ്റുകൾ പുഷ് ചെയ്യുന്നു, കൂടാതെ പലപ്പോഴും അവരുടെ സ്വന്തം pull request -കൾ സ്ക്വാഷ് ചെയ്ത് മർജ് ചെയ്യുന്നു.

വികസന ലൂപ്പിന്റെ കൂടുതൽ ഘടകങ്ങൾ സിസ്റ്റത്തിലേക്ക് നേരിട്ട് എൻകോഡ് ചെയ്തതോടെ—ടെസ്റ്റിംഗ്, വാലിഡേഷൻ, റിവ്യൂ, ഫീഡ്ബാക്ക് കൈകാര്യം ചെയ്യൽ, റിക്കവറി എന്നിവ—റിപ്പോസിറ്ററി അടുത്തിടെ ഒരു അർത്ഥവത്തായ പരിധി കടന്നു, അതിൽ Codex ഒരു പുതിയ ഫീച്ചർ എൻഡ്-ടു-എൻഡ് നയിക്കാൻ കഴിയും.

ഒരു പ്രോംപ്റ്റ് നൽകിയാൽ, ഏജന്റിന് ഇപ്പോൾ ചെയ്യാൻ കഴിയുന്നത്:

• കോഡ്ബേസിന്റെ നിലവിലെ നില പരിശോധിക്കുക
• റിപ്പോർട്ട് ചെയ്ത പിഴവ് പുനഃസൃഷ്ടിക്കുക
• പരാജയം പ്രദർശിപ്പിക്കുന്ന ഒരു വീഡിയോ റെക്കോർഡ് ചെയ്യുക
• ഒരു പരിഹാരം നടപ്പിലാക്കുക
• ആപ്ലിക്കേഷൻ പ്രവർത്തിപ്പിച്ച് പരിഹാരം ശരിയാണെന്ന് സ്ഥിരീകരിക്കുക
• റെസല്യൂഷൻ പ്രദർശിപ്പിക്കുന്ന രണ്ടാമത്തെ വീഡിയോ റെക്കോർഡ് ചെയ്യുക
• pull request തുറക്കുക
• ഏജന്റിനും മനുഷ്യരുടെ ഫീഡ്ബാക്കിനും പ്രതികരിക്കുക
• ബിൽഡ് പരാജയങ്ങൾ കണ്ടെത്തുകയും പരിഹരിക്കുകയും ചെയ്യുക
• വിധിന്യായം ആവശ്യമായപ്പോൾ മാത്രം മനുഷ്യനിലേക്കു ഉയർത്തുക
• മാറ്റം കൂട്ടിച്ചേർക്കുക

ഈ പെരുമാറ്റം ഈ റിപ്പോസിറ്ററിയുടെ പ്രത്യേക ഘടനയെയും ഉപകരണങ്ങളെയും വളരെ ആശ്രയിക്കുന്നു, സമാനമായ നിക്ഷേപം ഇല്ലാതെ ഇത് പൊതുവായി ബാധകമാകുമെന്ന് കരുതരുത്—കുറഞ്ഞത്, ഇപ്പോഴില്ല.

ഏജന്റിന്റെ പൂർണ്ണ സ്വയംഭരണവും പുതിയ പ്രശ്നങ്ങൾ സൃഷ്ടിക്കുന്നു. Codex റിപ്പോസിറ്ററിയിൽ ഇതിനകം നിലവിലുള്ള പാറ്റേണുകൾ—അസമമായതോ അല്ലെങ്കിൽ മികച്ചതല്ലാത്തതോ ആയവ പോലും—പുനരാവർത്തിക്കുന്നു. കാലക്രമേണ, ഇത് അനിവാര്യമായി വ്യതിചലനത്തിലേക്ക് നയിക്കുന്നു.

ആദ്യം, മനുഷ്യർ ഇത് കൈമാറ്റം ചെയ്തു. ഞങ്ങളുടെ ടീം എല്ലാ വെള്ളിയാഴ്ചയും (ആഴ്ചയുടെ 20%) “AI slop” വൃത്തിയാക്കുന്നതിൽ ചെലവഴിച്ചിരുന്നതായി. അത് അത്ഭുതകരമല്ല, അത് സ്കെയിൽ ചെയ്തില്ല.

പകരം, ഞങ്ങൾ “ഗോൾഡൻ പ്രിൻസിപ്പിളുകൾ” എന്ന് വിളിക്കുന്നവയെ നേരിട്ട് റിപ്പോസിറ്ററിയിൽ എൻകോഡ് ചെയ്യുകയും ആവർത്തിച്ചുള്ള ഒരു ക്ലീൻഅപ്പ് പ്രക്രിയ നിർമ്മിക്കുകയും ചെയ്തു. ഈ തത്വങ്ങൾ അഭിപ്രായാധിഷ്ഠിതവും യാന്ത്രികവുമായ നിയമങ്ങളാണ്, ഭാവിയിലെ ഏജന്റ് പ്രവർത്തനങ്ങൾക്കായി കോഡ്ബേസ് വായനാസൗകര്യവും സ്ഥിരതയും ഉറപ്പാക്കുന്നു. ഉദാഹരണത്തിന്: (1) ഇൻവേറിയന്റുകൾ കേന്ദ്രീകൃതമായി നിലനിർത്താൻ, കൈകൊണ്ട് തയ്യാറാക്കിയ സഹായികളേക്കാൾ പങ്കിടുന്ന ഉപയോക്തൃ പാക്കേജുകള്‍ക്കാണ് ഞങ്ങൾ മുൻഗണന നല്‍കുന്നത്, കൂടാതെ (2) ഞങ്ങൾ ഡാറ്റയെ “YOLO-ശൈലി”യിൽ പരിശോധിക്കാറില്ല—ഞങ്ങൾ അതിരുകൾ ശരിവയ്ക്കുകയോ ടൈപ്പ് ചെയ്ത SDK-കളെ ആശ്രയിക്കുകയോ ചെയ്യുന്നു, അതിനാൽ ഏജന്റ് ഊഹിച്ച രൂപങ്ങളെ അടിസ്ഥാനമാക്കി അബദ്ധത്തിൽ നിർമ്മിക്കാൻ കഴിയില്ല. പതിവായ ഒരു ഇടവേളയിൽ, വ്യതിയാനങ്ങൾ കണ്ടെത്താൻ സ്കാൻ ചെയ്യുന്ന, ഗുണനിലവാര ഗ്രേഡുകൾ പുതുക്കുന്ന, ലക്ഷ്യമിട്ട റീഫാക്ടറിംഗ് pull request -കൾ തുറക്കുന്ന പശ്ചാത്തല Codex ടാസ്കുകളുടെ ഒരു സെറ്റ് ഞങ്ങൾക്ക് ഉണ്ട്. ഇവയിൽ ഭൂരിഭാഗവും ഒരു മിനിറ്റിൽ താഴെ സമയം കൊണ്ട് അവലോകനം ചെയ്യപ്പെടുകയും സ്വയം മർജ് ചെയ്യപ്പെടുകയും ചെയ്യാം.

ഇത് മാലിന്യ ശേഖരണം പോലെ പ്രവർത്തിക്കുന്നു. സാങ്കേതിക കടം ഉയർന്ന പലിശയുള്ള ഒരു വായ്പ പോലെയാണ്: അത് കൂട്ടുപലിശയായി വളരാൻ വിട്ട് വേദനാജനകമായ ഇടവേളകളിൽ കൈകാര്യം ചെയ്യുന്നതിനെക്കാൾ, ചെറിയ ഘട്ടങ്ങളായി തുടർച്ചയായി കുറച്ചുകൊണ്ടുപോകുന്നതാണ് മിക്കവാറും എല്ലായ്പ്പോഴും നല്ലത്. മനുഷ്യരുടെ രുചി ഒരിക്കൽ പിടിച്ചെടുക്കപ്പെടുന്നു, തുടർന്ന് ഓരോ കോഡ് വരിയിലും തുടർച്ചയായി പ്രയോഗിക്കുന്നു. ഇത് മോശം പാറ്റേണുകൾ code base-ൽ ദിവസങ്ങളോ ആഴ്ചകളോ പടരാൻ അനുവദിക്കുന്നതിന് പകരം, അവ ദിനംപ്രതി കണ്ടെത്താനും പരിഹരിക്കാനും ഞങ്ങളെ അനുവദിക്കുന്നു.

ഈ തന്ത്രം ഇതുവരെ OpenAI-യിലെ ആന്തരിക ലോഞ്ചും സ്വീകരണവും വരെ നന്നായി പ്രവർത്തിച്ചു. യഥാർത്ഥ ഉപയോക്താക്കൾക്കായി യഥാർത്ഥ ഉൽപ്പന്നം നിർമ്മിക്കുന്നത് നമ്മുടെ നിക്ഷേപങ്ങളെ യാഥാർത്ഥ്യത്തിൽ ആങ്കർ ചെയ്യുകയും ദീർഘകാല പരിപാലനക്ഷമതയിലേക്ക് നയിക്കുകയും ചെയ്തു.

ഞങ്ങൾക്കിതുവരെ അറിയാത്തത്, പൂർണ്ണമായും ഏജന്റ്-ജനറേറ്റ് ചെയ്ത ഒരു സിസ്റ്റത്തിൽ ആർക്കിടെക്ചറൽ ഏകോപനം വർഷങ്ങളായി എങ്ങനെ വികസിക്കുന്നു എന്നതാണ്. മനുഷ്യ വിധിനിർണയം എവിടെയാണ് ഏറ്റവും കൂടുതൽ പ്രയോജനം നൽകുന്നത് എന്നും ആ വിധിനിർണയം എങ്ങനെ എൻകോഡ് ചെയ്യണം അതുവഴി അത് കൂട്ടിച്ചേർക്കപ്പെടുന്നു എന്നും ഞങ്ങൾ ഇപ്പോഴും പഠിച്ചുകൊണ്ടിരിക്കുന്നു. മോഡലുകൾ കൂടുതൽ കഴിവുകൾ നേടിക്കൊണ്ടിരിക്കുമ്പോൾ, ഈ സിസ്റ്റം എങ്ങനെ വികസിക്കും എന്നത് ഞങ്ങൾക്കും അറിയില്ല.

വ്യക്തമായത്: സോഫ്റ്റ്വെയർ നിർമ്മാണത്തിന് ഇപ്പോഴും അച്ചടക്കം ആവശ്യമാണ്, പക്ഷേ ആ അച്ചടക്കം കോഡിനേക്കാൾ സ്കാഫോൾഡിംഗിലാണ് കൂടുതൽ പ്രകടമാകുന്നത്. കോഡ്ബേസ് ഏകോപിതമായി നിലനിർത്താൻ സഹായിക്കുന്ന ടൂളിംഗ്, ആബ്സ്ട്രാക്ഷനുകൾ, ഫീഡ്ബാക്ക് ലൂപ്പുകൾ എന്നിവ കൂടുതൽ പ്രധാനമാകുന്നു.

ഇപ്പോൾ ഞങ്ങളുടെ ഏറ്റവും പ്രയാസകരമായ വെല്ലുവിളികൾ ഏജൻ്റുകൾക്ക് ഞങ്ങളുടെ ലക്ഷ്യം കൈവരിക്കാൻ സഹായിക്കുന്ന പരിസ്ഥിതികൾ, ഫീഡ്ബാക്ക് ലൂപ്പുകൾ, നിയന്ത്രണ സിസ്റ്റങ്ങൾ എന്നിവ രൂപകൽപ്പന ചെയ്യുന്നതിലാണ് കേന്ദ്രീകരിക്കുന്നത്: വലിയ തോതിൽ സങ്കീർണ്ണവും വിശ്വസനീയവുമായ സോഫ്റ്റ്വെയർ നിർമ്മിക്കുകയും പരിപാലിക്കുകയും ചെയ്യുക.

Codex പോലുള്ള ഏജൻ്റുകൾ സോഫ്റ്റ്‌വെയർ ജീവിതചക്രത്തിലെ കൂടുതൽ വലിയ ഭാഗങ്ങൾ ഏറ്റെടുക്കുമ്പോൾ, ഈ ചോദ്യങ്ങൾ കൂടുതൽ പ്രാധാന്യമാകും. ഞങ്ങൾ ചില പ്രാരംഭ പാഠങ്ങൾ പങ്കുവെക്കുന്നത് നിങ്ങളുടെ ശ്രമം എവിടെയാണ് നിക്ഷേപിക്കേണ്ടത് എന്ന് മനസ്സിലാക്കാൻ സഹായിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നു, അതുവഴി നിങ്ങൾക്ക് കാര്യങ്ങൾ നിർമ്മിക്കാൻ കഴിയും.