ഈ പരിശോധനയുടെ പ്രാധാന്യം
AI അധിഷ്ഠിത കോഡ് അസിസ്റ്റന്റുകൾ പലപ്പോഴും ടീമുകൾ ഒരു "റൂൾസ്" (rules) ഫയൽ റെപ്പോസിറ്ററിയിൽ (repo) ഇടുകയും, ഓരോ അഭ്യർത്ഥനയിലും (request) മോഡൽ അതിന്റെ നിർദ്ദേശങ്ങൾ പാലിക്കുമെന്ന് പ്രതീക്ഷിക്കുകയും ചെയ്യുന്നു. പ്രായോഗികമായി, മോഡൽ ആ ഫയൽ കാണണമെന്നില്ല, അല്ലെങ്കിൽ അത് കണ്ടേക്കാം പക്ഷേ ഉള്ളടക്കം അവഗണിച്ചേക്കാം. Claude Code ഉപയോഗിച്ചുള്ള ഒരു സമീപകാല പരീക്ഷണം ഈ രണ്ട് പ്രശ്നങ്ങളും കാണിച്ചുതന്നു. ആ ടൂൾ 72 KB വലിപ്പമുള്ള AGENTS.md ഫയൽ നിശബ്ദമായി ഒഴിവാക്കി; അതേ ഫയൽ CLAUDE.md എന്ന് പുനർനാമകരണം ചെയ്തപ്പോൾ അസിസ്റ്റന്റ് അത് ലോഡ് ചെയ്യുകയും ഓരോ അഭ്യർത്ഥനയുടെയും ടോക്കൺ കൗണ്ട് വർദ്ധിപ്പിക്കുകയും ചെയ്തു. ആ അധിക ടോക്കൺ ബജറ്റ് ലേറ്റൻസി (latency), ചിലവ് എന്നിവ വർദ്ധിപ്പിക്കുകയും ഒരു അഭ്യർത്ഥനയെ മോഡലിന്റെ പരിധിക്കപ്പുറത്തേക്ക് എത്തിക്കുകയും ചെയ്തേക്കാം.
"ഫയൽ നിലവിലുണ്ട്" എന്നാൽ "മോഡൽ നിയമങ്ങൾ പാലിക്കുന്നുണ്ട്" എന്ന് കരുതുന്ന ഡെവലപ്പർമാർ, ഒളിഞ്ഞിരിക്കുന്ന കാര്യക്ഷമതയില്ലായ്മകൾക്കും പ്രവചനാതീതമായ ഔട്ട്പുട്ടിനും ഇരയാകാൻ സാധ്യതയുണ്ട്. മൂന്ന് ഘട്ടങ്ങളുള്ള ഈ പരിശോധന ഓരോ ഘട്ടത്തിലും വ്യക്തമായ തെളിവുകൾ ആവശ്യപ്പെടുന്നു: കോൺഫിഗറേഷൻ, ലോഡിംഗ്, ഉപയോഗപ്രദത.
ചോദിക്കേണ്ട മൂന്ന് ചോദ്യങ്ങൾ
- കോൺഫിഗർ ചെയ്തത് (Configured) – അസിസ്റ്റന്റ് തിരയുന്ന സ്ഥലത്താണോ ഫയൽ വെച്ചിരിക്കുന്നത്? വ്യത്യസ്ത ടൂളുകൾ പാത്തുകളോ (paths) ഫയൽനാമ രീതികളോ (filename conventions) മുൻകൂട്ടി നിശ്ചയിച്ചിട്ടുണ്ടാകാം; അവ തമ്മിലുള്ള പൊരുത്തക്കേട് ഫയൽ പ്രോംപ്റ്റ് പൈപ്പ്ലൈനിൽ (prompt pipeline) എത്താതിരിക്കാൻ കാരണമാകും.
- ലോഡ് ചെയ്തത് (Loaded) – ഫയൽ ലഭിച്ചുവെന്ന് അസിസ്റ്റന്റ് എന്തെങ്കിലും തെളിവ് നൽകുന്നുണ്ടോ? ഒരു ഹാഷ് (hash) ഉപയോഗിച്ച് ഡിസ്കിലുള്ള ഫയലിന്റെ ഐഡന്റിറ്റി സ്ഥിരീകരിക്കാം, എന്നാൽ ഒരു ഡെലിവറി ട്രേസ് (ഉദാഹരണത്തിന്, ഒരു ലോഗ് ലൈൻ അല്ലെങ്കിൽ ടോക്കൺ കൗണ്ട്) മാത്രമേ മോഡൽ അത് ശരിക്കും ശ്രദ്ധിച്ചു എന്ന് തെളിയിക്കൂ.
- ഉപയോഗപ്രദമായത് (Useful) – ഫയലിന്റെ സാന്നിധ്യം ടാസ്കിന്റെ ഫലത്തെ മെച്ചപ്പെടുത്തുന്നുണ്ടോ? ടോക്കണുകൾ വർദ്ധിപ്പിക്കുകയും എന്നാൽ ഫലം മാറ്റമില്ലാതെ നിലനിർത്തുകയും ചെയ്യുന്ന ഒരു ലോഡ് ചെയ്ത ഫയൽ യഥാർത്ഥത്തിൽ ഒരു നഷ്ടമാണ്.
പരിശോധന നടത്തുന്ന രീതി
ഏത് പ്ലാറ്റ്ഫോമിലും ആവർത്തിക്കാൻ കഴിയുന്ന രീതിയിൽ ഈ നടപടിക്രമം വളരെ ലളിതമായാണ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്.
കാണാൻ കഴിയുന്ന ഒരു റൂൾ നിർമ്മിക്കുക – ലളിതവും നിരീക്ഷിക്കാൻ കഴിയുന്നതുമായ ഒരു നിർദ്ദേശം എഴുതുക. ഉദാഹരണത്തിന്: “എഡിറ്റ് ചെയ്യുന്നതിന് മുമ്പ് കൃത്യം രണ്ട് ഫയലുകൾ ലിസ്റ്റ് ചെയ്യുക.” അസിസ്റ്റന്റിന്റെ മറുപടിയിലൂടെ റൂളിന്റെ ഫലം പരിശോധിക്കാം.
ടൂൾ വേർഷനും മോഡലും പരിശോധിക്കുക – ഒരു പുതിയ സെഷൻ തുറക്കുക, വേർഷൻ സ്ട്രിംഗും (version string) മോഡൽ ഐഡന്റിഫിക്കറും കുറിച്ചെടുക്കുക. വ്യത്യസ്ത വേർഷനുകൾ അവ തിരിച്ചറിയുന്ന ഫയൽനാമം മാറ്റിയേക്കാം.
രണ്ട് തവണ പ്രവർത്തിപ്പിക്കുക Run A: ടൂൾ തിരിച്ചറിയാത്ത ഒരു ഫയൽനാമം ഉപയോഗിക്കുക (ഉദാഹരണത്തിന്, AGENTS.md). Run B: ടൂളിന്റെ ഒറിജിനൽ ഫയൽനാമം ഉപയോഗിക്കുക (ഉദാഹരണത്തിന്, CLAUDE.md).
ഇവ രേഖപ്പെടുത്തുക:
- ഫയലിന്റെ സോഴ്സ് ഹാഷ് (ഫയലിലെ ഉള്ളടക്കം മാറിയില്ലെന്ന് തെളിയിക്കാൻ).
- ഉപയോഗിച്ച കൃത്യമായ പാത്ത് (path).
- ഫയൽ ലോഡ് ചെയ്തതിനെക്കുറിച്ച് അസിസ്റ്റന്റ് നൽകിയ ഏതെങ്കിലും തെളിവ് (ടോക്കൺ കൗണ്ട് വർദ്ധനവ്, "loaded X.md" എന്ന സന്ദേശം മുതലായവ).
- ഓരോ അഭ്യർത്ഥനയുടെയും ടോക്കൺ കൗണ്ട്.
- ടാസ്ക് റിസൾട്ട് (അസിസ്റ്റന്റ് കൃത്യം രണ്ട് ഫയലുകൾ ലിസ്റ്റ് ചെയ്തോ?).
If Run B-യിൽ റൂൾ പാലിക്കപ്പെടുന്നതായും ടോക്കൺ കൗണ്ട് പ്രതീക്ഷിച്ച അളവിൽ വർദ്ധിക്കുന്നതായും കണ്ടാൽ, ഫയൽ ലോഡ് ചെയ്യപ്പെടുകയും ഉപയോഗപ്രദമാവുകയും ചെയ്യുന്നു എന്ന് അർത്ഥം. ടോക്കൺ വർദ്ധനവുണ്ടായിട്ടും റൂൾ അവഗണിക്കപ്പെട്ടാൽ, ഫയൽ വായിക്കുന്നുണ്ടെങ്കിലും മോഡലിന്റെ പ്രോംപ്റ്റ് പാഴ്സിംഗ് (prompt parsing) നിർദ്ദേശം ഒഴിവാക്കുന്നു എന്നാണ് അർത്ഥം. അങ്ങനെയെങ്കിൽ, ഫയലിൽ കൂടുതൽ ടെക്സ്റ്റ് ചേർക്കുന്നത് സഹായിക്കില്ല; പകരം ആ റൂൾ ഒരു ഹാർഡ്-കോഡഡ് പോളിസി ഗേറ്റിലേക്കോ (hard-coded policy gate) ഒരു ടെസ്റ്റ് ഹാർനെസ്സിലേക്കോ (test harness) മാറ്റുക.
ഡാറ്റ എന്ത് വെളിപ്പെടുത്തുന്നു
Claude Code കേസ് കോൺഫിഗറേഷനും ലോഡിംഗും തമ്മിലുള്ള വലിയ വ്യത്യാസം വെളിപ്പെടുത്തി. 72 KB ഫയൽ നിലവിലുണ്ടായിരുന്നു, ശരിയായ ഹാഷ് ഉണ്ടായിരുന്നു, റെപ്പോസിറ്ററിയുമായി സിങ്ക് ചെയ്തിരുന്നു, എന്നിട്ടും അസിസ്റ്റന്റ് അത് ഒരിക്കലും പരാമർശിച്ചില്ല. ഫയലിനെ CLAUDE.md എന്ന് പുനർനാമകരണം ചെയ്തത് ലോഡിംഗിന് കാരണമായി, എന്നാൽ അത് വലിയ തോതിലുള്ള ടോക്കൺ ഓവർഹെഡ് (token overhead) ഉണ്ടാക്കുകയും ചെയ്തു. ഓരോ അധിക ടോക്കണും കമ്പ്യൂട്ട് സൈക്കിളുകൾ ഉപയോഗിക്കുന്നു കൂടാതെ അഭ്യർത്ഥനയെ റേറ്റ് ലിമിറ്റുകൾക്ക് (rate limits) അപ്പുറത്തേക്ക് എത്തിച്ചേക്കാം.
ഇത്തരം ഒളിഞ്ഞിരിക്കുന്ന ചിലവുകൾ പ്രൊഡക്ഷൻ തടസ്സങ്ങളാകുന്നതിന് മുമ്പ് ഈ മൂന്ന് ഘട്ട പരിശോധന അവ പുറത്തുകൊണ്ടുവരുന്നു. ടോക്കൺ ഡെൽറ്റ (token delta) കണക്കാക്കുന്നതിലൂടെ, റൂളിന്റെ ഗുണം അതിന്റെ ചിലവിനേക്കാൾ കൂടുതലാണോ എന്ന് തീരുമാനിക്കാൻ ടീമുകൾക്ക് കഴിയും.
ചുരുക്കം
ഒരു റൂൾസ് ഫയൽ റെപ്പോസിറ്ററിയിൽ ഉള്ളതുകൊണ്ട് മാത്രം അത് പ്രവർത്തിക്കുന്നുണ്ടെന്ന് ഒരിക്കലും കരുതരുത്. ആ അനുമാനം അളക്കാവുന്ന തെളിവുകളാക്കി മാറ്റാൻ—കോൺഫിഗർ ചെയ്യുക, ലോഡ് ചെയ്യുക, ഉപയോഗപ്രദത തെളിയിക്കുക—എന്ന മൂന്ന് ഘട്ട പരിശോധന ഉപയോഗിക്കുക. ഒരു ഫയൽ വെറും ടോക്കൺ പാഴാക്കുന്ന ഒന്നാണെന്ന് തെളിയുമ്പോൾ, ആ ലോജിക് പ്രോംപ്റ്റിൽ നിന്ന് മാറ്റി ഒരു ഡിറ്റർമിനിസ്റ്റിക് ഗേറ്റിലേക്ക് (deterministic gate) മാറ്റുക. ഇതിന്റെ ഫലമായി കൂടുതൽ കാര്യക്ഷമവും വേഗതയേറിയതും പ്രവചനാതീതമല്ലാത്തതുമായ ഒരു AI കോഡിംഗ് വർക്ക്ഫ്ലോ ലഭിക്കുന്നു.