റിപ്പോ ആണ് കോൺടെക്സ്റ്റ്: ഏജന്റുകൾക്ക് ചരിത്രം ആവശ്യമില്ലാത്തത് എന്തുകൊണ്ട്
കോഡിംഗ് ഏജന്റുകൾ നിങ്ങൾ നൽകുന്നതെന്തും വായിക്കുന്നു. ഇത് ഒരു ഗുണമായി തോന്നാം. എന്നാൽ സാധാരണയായി ഇതൊരു പ്രശ്നമാണ്.
ഞാൻ ഏജന്റുകൾക്ക് കൂടുതൽ ഡോക്യുമെന്റേഷൻ നൽകാറുണ്ടായിരുന്നു. ഞാൻ സ്പെക്സുകളും (specs), ADR-കളും, പ്ലാനിംഗ് ഡോക്യുമെന്റുകളും എഴുതാറുണ്ടായിരുന്നു. കൂടുതൽ കോൺടെക്സ്റ്റ് നൽകുന്നത് നല്ലതാണെന്നാണ് ഞാൻ കരുതിയത്. എന്നാൽ ഒരു ഏജന്റ് ആത്മവിശ്വാസത്തോടെ ഒരു തെറ്റ് ചെയ്യുന്നത് ഞാൻ കണ്ടു. അത് ഒരു ഹാലൂസിനേഷൻ (hallucination) ആയിരുന്നില്ല. മാസങ്ങൾക്ക് മുമ്പ് നമ്മൾ ഉപയോഗിക്കുന്നത് നിർത്തിയ ഒരു സിസ്റ്റത്തെക്കുറിച്ച് വിവരിക്കുന്ന പഴയൊരു ഡോക്യുമെന്റ് പിന്തുടർന്നതുകൊണ്ട് മാത്രം സംഭവിച്ചതായിരുന്നു അത്. സത്യത്തിന് പകരം അത് ചരിത്രത്തെയാണ് അനുസരിച്ചിരുന്നത്.
ചരിത്രം മനുഷ്യർക്ക് വേണ്ടിയുള്ളതാണ്. ഒരു സിസ്റ്റം എന്തുകൊണ്ട് നിലനിൽക്കുന്നു എന്ന് അത് വിശദീകരിക്കുന്നു. ട്രേഡ്-ഓഫുകളും (trade-offs) പഴയ തീരുമാനങ്ങളും മനസ്സിലാക്കാൻ അത് നിങ്ങളെ സഹായിക്കുന്നു.
ഏജന്റുകൾ വ്യത്യസ്തരാണ്. അവർ നിലവിലുള്ള സിസ്റ്റത്തിലാണ് മാറ്റങ്ങൾ വരുത്തുന്നത്. ആ ജോലിക്കായി അവർക്ക് ചരിത്രപരമായ വിവരണങ്ങൾ (prose) ആവശ്യമില്ല. അവർക്ക് വേണ്ടത് നിലവിലെ 'സോഴ്സ് ഓഫ് ട്രൂത്ത്' (source of truth) ആണ്.
അവർക്ക് വേണ്ടത്: • നിലവിലെ സ്കീമകൾ (Current schemas) • നിലവിലെ മോഡ്യൂൾ അതിരുകൾ (Current module boundaries) • നിലവിലെ APIs • നിലവിലെ ടെസ്റ്റുകൾ (Current tests) • നിലവിലെ കോൺഫിഗറേഷനുകൾ (Current configurations)
ഒരു ഏജന്റ് ഒരു ഡാറ്റാബേസ് മനസ്സിലാക്കണമെന്ന് നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, എല്ലാ മൈഗ്രേഷൻ ലോഗുകളും (migration logs) വീണ്ടും വായിപ്പിക്കരുത്. പകരം നിലവിലെ സ്കീമ നൽകുക. ആർക്കിടെക്ചർ മനസ്സിലാക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, പഴയ ADR-കൾ വായിപ്പിക്കരുത്. പകരം നിലവിലെ മോഡ്യൂൾ ഗ്രാഫ് (module graph) നൽകുക.
ഇവിടെ അപകടം 'കോൺടെക്സ്റ്റ് പൊല്യൂഷൻ' (context pollution) ആണ്. ഒരു വസ്തുത രണ്ട് സ്ഥലങ്ങളിൽ നിലനിൽക്കുമ്പോഴാണ് ഇത് സംഭവിക്കുന്നത്: കോഡിലും ഒരു മാർക്ക്ഡൗൺ (Markdown) ഫയലിലും. കോഡ് വേഗത്തിൽ മാറുന്നു. എന്നാൽ വിവരണങ്ങൾ ആരെങ്കിലും ഓർത്തെടുക്കുമ്പോൾ മാത്രമേ മാറുന്നുള്ളൂ. ഇവ തമ്മിൽ വ്യത്യാസം വരുമ്പോൾ, ഏജന്റ് കാലഹരണപ്പെട്ട ഡോക്യുമെന്റിനെയാണ് വിശ്വസിക്കുന്നത്. മനുഷ്യരെപ്പോലെ ഏജന്റുകൾക്ക് കാര്യങ്ങൾ സൂക്ഷ്മമായി പരിശോധിക്കാനോ ക്രോസ്-ചെക്ക് ചെയ്യാനോ കഴിയില്ല. അത് ആദ്യം വായിക്കുന്നതിനെ ഒരു വസ്തുതയായി സ്വീകരിക്കുന്നു.
മികച്ച ഡോക്യുമെന്റേഷനുകൾ എഴുതുന്നത് നിർത്തുക. പകരം, വിവരങ്ങൾ തെറ്റായി നിലനിൽക്കാൻ സാധ്യതയുള്ള ഇടങ്ങൾ കുറയ്ക്കാൻ തുടങ്ങുക.
നിയമങ്ങൾ ടെക്സ്റ്റിൽ നിന്ന് സിസ്റ്റം ഘടനയിലേക്ക് മാറ്റുക: • ആർക്കിടെക്ചറിനായി ഡയറക്ടറി ഘടനകൾ (directory structures) ഉപയോഗിക്കുക. • ഉദ്ദേശ്യം വ്യക്തമാക്കാൻ പേരിടൽ രീതികൾ (naming) ഉപയോഗിക്കുക. • APIs-നായി പാക്കേജ് എക്സ്പോർട്ടുകൾ (package exports) ഉപയോഗിക്കുക. • അതിരുകൾക്കായി ലിന്റ് നിയമങ്ങൾ (lint rules) ഉപയോഗിക്കുക. • ഡാറ്റാ കോൺട്രാക്റ്റുകൾക്കായി സ്കീമകൾ (schemas) ഉപയോഗിക്കുക. • പെരുമാറ്റം (behavior) മനസ്സിലാക്കാൻ ടെസ്റ്റുകൾ ഉപയോഗിക്കുക.
ഒരു README-യിലെ നിയമം വെറുമൊരു നിർദ്ദേശമാണ്. എന്നാൽ ഒരു ESLint കോൺഫിഗറേഷ്യിലെ നിയമം ഒരു മതിലാണ്. ഏജന്റിന് ആ മതിലിനെ അവഗണിക്കാൻ കഴിയില്ല.
ഞാൻ എന്റെ ഇൻസ്ട്രക്ഷൻ ഫയലുകളുടെ (instruction files) വലിപ്പം കുറച്ചു. അവ ഇനി ആർക്കിടെക്ചർ വീണ്ടും വിവരിക്കുന്നില്ല. പകരം, ആർക്കിടെക്ചർ എവിടെയാണെന്ന് അവ ചൂണ്ടിക്കാണിക്കുന്നു.
ചരിത്രം മനുഷ്യർക്കായി സൂക്ഷിക്കുക. ഏജന്റുകൾക്കായി വർത്തമാനകാലത്തെ രൂപപ്പെടുത്തുക.
Source: https://dev.to/gyu07/the-repo-is-the-context-why-agents-dont-need-history-4ien
Optional learning community: https://t.me/GyaanSetuAi