ഒരാൾ താൻ ഒറ്റയ്ക്ക് 29 ദിവസത്തിനുള്ളിൽ 26 റെപ്പോസിറ്ററികളിലായി 335 ലൈവ് പേജുകൾ പുറത്തിറക്കി എന്ന് പറയുമ്പോൾ, അവർ എങ്ങനെ ഇത്ര വേഗത്തിൽ ഇത് ചെയ്തു എന്ന് ചോദിക്കാനാണ് നമ്മുടെ ഉള്ളിൽ തോന്നുക. എന്നാൽ അതിനേക്കാൾ നല്ല ചോദ്യം, ആ വേഗതയിൽ എന്തൊക്കെ തകരാറുകൾ സംഭവിച്ചു എന്നതാണ്.
ആ കണക്കുകൾ സത്യമാണ്: 1,549 കമ്മറ്റുകൾ, 26 റെപ്പോസിറ്ററികൾ, 29 ദിവസങ്ങൾ, Claude Code ഉപയോഗിക്കുന്ന ഒരു ഡെവലപ്പർ. എന്നാൽ വേഗത മാത്രം നിങ്ങൾക്ക് വലിയ പാഠങ്ങൾ നൽകില്ല. പരാജയങ്ങളുടെ സ്വഭാവമാണ് പ്രധാനം, കാരണം അവ ഒരു സ്റ്റാക്ക് ട്രാസിലൂടെ (stack trace) കണ്ടെത്താൻ കഴിയുന്ന തരത്തിലുള്ളവയായിരുന്നില്ല. അവ ഘടനാപരമായ തകരാറുകളായിരുന്നു (structural fractures). എഡിറ്ററിൽ നിന്ന് മാറിനിന്ന് പ്രൊഡക്ഷനിൽ പ്രവർത്തിക്കുന്ന മുഴുവൻ സിസ്റ്റത്തെയും നോക്കുമ്പോൾ മാത്രമേ അവ കാണാൻ കഴിയൂ.
എന്തൊക്കെയാണ് ഫലപ്രദമായത്
ആ വേഗത ഒരു മിഥ്യയല്ലായിരുന്നു. ഉറക്കമില്ലാത്ത ഒരു AI-ക്ക് ചില ജോലികൾ കൈമാറുമ്പോൾ അവയുടെ സമയം ഗണ്യമായി കുറയുന്നു.
പാഠപുസ്തകങ്ങളിലെ അൽഗോരിതങ്ങൾ ആഴ്ചകൾക്ക് പകരം ദിവസങ്ങൾക്കുള്ളിൽ ഫീച്ചറുകളായി മാറി. 2048 സോൾവറും (solver) minimax അടിസ്ഥാനമാക്കിയുള്ള ഗെയിമുകളും വേഗത്തിൽ തയ്യാറായതിന് കാരണം അവയുടെ ഇംപ്ലിമെന്റേഷൻ പാറ്റേണുകൾ കൃത്യമായി രേഖപ്പെടുത്തിയിട്ടുള്ളതാണ് എന്നതാണ്. മോഡൽ അക്കാദമിക് പേപ്പറുകളിൽ കുടുങ്ങിപ്പോകില്ല; അത് സെർച്ച് ട്രീയും (search tree), ഹ്യൂറിസ്റ്റിക് ഇവാലുവേഷനും (heuristic evaluation), മൂവ് സ്കോറിംഗും (move scoring) എഴുതി മുന്നോട്ട് പോകും. ഇവ പരിഹരിക്കപ്പെട്ട പ്രശ്നങ്ങളാണ്, അതിനാൽ ഒരു AI പെയർ പ്രോഗ്രാമർക്ക് ഇത്തരം പ്രശ്നങ്ങൾ അതീവ കാര്യക്ഷമതയോടെ കൈകാര്യം ചെയ്യാൻ കഴിയും.
വിരസമായ ഓഡിറ്റുകൾ സഹനീയമായി മാറി. ലിങ്ക് ഗ്രാഫുകൾ ക്രോൾ ചെയ്യുക, റീഡയറക്ട് ചെയിനുകൾ പരിശോധിക്കുക, നൂറുകണക്കിന് പേജുകളിലെ കാനോണിക്കൽ ടാഗുകൾ (canonical tags) പരിശോധിക്കുക — ഇത്തരം ജോലികൾ മനുഷ്യന്റെ ശ്രദ്ധാകേന്ദ്രത്തെ തളർത്തുന്നവയാണ്, എന്നാൽ ഒരു ലാംഗ്വേജ് മോഡൽ പരാതികളില്ലാതെ ഇത് ആവർത്തിക്കും. അത് ഒരേ പാറ്റേൺ മുന്നൂറിലധികം തവണ പരിശോധിക്കുകയും റിപ്പോർട്ട് നൽകുകയും ചെയ്യും.
യഥാർത്ഥ അത്ഭുതം അതിന്റെ സ്ഥിരതയായിരുന്നു (consistency). ഡസൻ കണക്കിന് ലാൻഡിംഗ് പേജുകൾ നിർമ്മിക്കാൻ ഒരു AI-യോട് ആവശ്യപ്പെടുമ്പോൾ, കൃത്യമായ നിയന്ത്രണങ്ങൾ നൽകിയില്ലെങ്കിൽ മാറ്റങ്ങൾ സംഭവിക്കുന്നത് ഒഴിവാക്കാനാവില്ല. ഒരു ബ്രാൻഡ് സിസ്റ്റം ഉറപ്പുവരുത്താൻ ഞാൻ ചെറിയ മെമ്മറി ഫയലുകൾ ഉപയോഗിച്ചു: വോയിസ് റൂളുകൾ, കളർ ടോക്കൺ പേരുകൾ, കമ്പോണന്റ് നിയന്ത്രണങ്ങൾ, പേജ് ആർക്കൈറ്റൈപ്പുകൾ എന്നിവ ഇതിൽ ഉൾപ്പെടുന്നു. ഓരോ പ്രസക്തമായ ടാസ്കിന്റെയും തുടക്കത്തിൽ മോഡൽ ഈ നിയന്ത്രണങ്ങൾ വായിക്കുകയും, ഇരുപത്തിയൊൻപത് വ്യത്യസ്ത മാനസികാവസ്ഥകളിൽ നിന്നുള്ള ജോലികൾക്ക് പകരം ഒരൊറ്റ വ്യക്തി ചെയ്തതുപോലെ തോന്നിക്കുന്ന രീതിയിൽ ഫലം നൽകുകയും ചെയ്തു.
യഥാർത്ഥത്തിൽ എന്തൊക്കെയാണ് തകരാറിലായത്
പരാജയങ്ങൾ ആർക്കിടെക്ചറൽ (architectural) ആയിരുന്നു. ഒരു സെമി കോളൻ (semicolon) വിട്ടുപോയതുകൊണ്ട് ഒരു ബിൽഡും പരാജയപ്പെട്ടില്ല. പകരം, എല്ലാം ശരിയാണെന്ന് എന്നെ വിശ്വസിപ്പിച്ചുകൊണ്ട് സിസ്റ്റം പതുക്കെ എന്നെ വഞ്ചിക്കുകയായിരുന്നു.
ആദ്യം SEO cannibalization ബാധിച്ചു. പഴയ ടൂൾ ഹബ്ബ് അതിന്റെ യഥാർത്ഥ പാത്തിൽ നിലനിൽക്കുമ്പോൾ തന്നെ, പുതിയൊരു URL-ൽ AI ഒരു പുതിയ ടൂൾ ഹബ്ബ് നിർമ്മിച്ചു. ഓരോ പേജും ഒപ്റ്റിമൈസ് ചെയ്യപ്പെട്ടിരുന്നു. ടൈറ്റിലുകൾ കൃത്യമായിരുന്നു. മെറ്റാ ഡിസ്ക്രിപ്ഷനുകൾ വ്യത്യസ്തമായിരുന്നു. ഉള്ളടക്കം ഉപയോഗപ്രദമായിരുന്നു. എന്നാൽ അവയെല്ലാം ഒരേ സെർച്ച് ഇന്റന്റ് (search intent) ലക്ഷ്യം വെച്ചുള്ളതായിരുന്നു. ഒരേ വിഷയത്തിൽ രണ്ട് അതോറിറ്റികളെ കണ്ട സെർച്ച് എഞ്ചിനുകൾ അവയെ റാങ്ക് ചെയ്തില്ല. വെറുമൊരു ഫയലുകളുടെ ശേഖരമായല്ല, മറിച്ച് ഒരു പോർട്ട്ഫോളിയോ ആയി ആ സൈറ്റിനെ ആരും നോക്കാത്തതുകൊണ്ട്, മികച്ച പേജുകൾ പരസ്പരം റദ്ദാക്കപ്പെട്ടു.
തുടർന്ന് URL പൊരുത്തക്കേടുകൾ ഉണ്ടായി. ഒരേ ഉള്ളടക്കത്തിനായി വ്യത്യസ്ത റെപ്പോസിറ്ററികൾ നേരിയ വ്യത്യാസമുള്ള ഫോൾഡർ ഘടനകൾ സ്വീകരിച്ചു. ഒരു റെപ്പോ /tools/utility-name എന്ന പാത്തിൽ ടൂളുകൾ സൂക്ഷിച്ചപ്പോൾ, മറ്റൊന്ന് അവയെ /utility-name എന്ന രീതിയിൽ ലളിതമാക്കി. CDN ഇവ രണ്ടും കണ്ടപ്പോൾ അവ പരിഹരിക്കാൻ റീഡയറക്ട് ചെയിനുകൾ നിർമ്മിക്കുകയും എഡ്ജിൽ (edge) എററുകൾ കാണിക്കാൻ തുടങ്ങുകയും ചെയ്തു. പേജുകൾ ഒടുവിൽ ലോഡ് ആകുമെങ്കിലും, ഓരോ റീഡയറക്ടും ക്രോൾ ബജറ്റും (crawl budget) ഉപയോക്താവിന്റെ ക്ഷമയും നശിപ്പിച്ചു. കോഡ് ശരിയായിരുന്നു, പക്ഷേ ടോപ്പോളജി (topology) കുഴപ്പത്തിലായിരുന്നു.
പിന്നീട് സിങ്ക് ട്രാപ്പ് (sync trap) വന്നു. ഞാൻ ഒരു മിറർ സൈറ്റ് — ഒരു സ്റ്റേജിംഗ് അല്ലെങ്കിൽ ബാക്കപ്പ് ഇൻസ്റ്റൻസ് — അപ്ഡേറ്റ് ചെയ്തു, എന്നാൽ ആ മാറ്റങ്ങൾ സോഴ്സ് റെപ്പോസിറ്ററിയിലേക്ക് തിരികെ എത്തിക്കാൻ മറന്നുപോയി. പിന്നീട് എൻവയോൺമെന്റുകൾ സിങ്ക് ചെയ്യാൻ ഞാൻ AI-യോട് ആവശ്യപ്പെട്ടപ്പോൾ, അത് മിറർ സൈറ്റിനെയാണ് യഥാർത്ഥ വിവരമായി (ground truth) കണക്കാക്കിയത്. ഒരു ലളിതമായ സിങ്ക് കമാൻഡ് പ്രൊഡക്ഷൻ ഡാറ്റാബേസിനെയോ ഫയലുകളെയോ പഴയ മിറർ ഡാറ്റ ഉപയോഗിച്ച് ഓവർറൈറ്റ് ചെയ്തേനെ. ഞാൻ ഉദ്ദേശിച്ചതല്ല, മറിച്ച് ഞാൻ വിവരിച്ചതാണ് AI ചെയ്തത്. ഉദ്ദേശ്യങ്ങൾ തമ്മിൽ വ്യത്യാസം (diff) കണ്ടെത്താൻ കഴിയില്ല; ഫയലുകൾ തമ്മിൽ മാത്രമേ അത് സാധ്യമാകൂ.
ഓഡിറ്റ് ടൂളുകൾ തന്നെ കള്ളം പറഞ്ഞു. ഓഡിറ്റിംഗ് ഓട്ടോമേറ്റ് ചെയ്തതുകൊണ്ട് ഔട്ട്പുട്ട് കൃത്യമാണെന്ന് ഞാൻ കരുതി. എന്നാൽ അത് ആയിരുന്നില്ല. AI എഴുതിയ ഓഡിറ്റ് സ്ക്രിപ്റ്റുകളിൽ സൂക്ഷ്മമായ ബഗുകൾ ഉണ്ടായിരുന്നു: off-by-one ചെക്കുകൾ, റീഡയറക്ട് സ്റ്റാറ്റസ് കോഡുകളെക്കുറിച്ചുള്ള തെറ്റായ ധാരണകൾ, യഥാർത്ഥ മിസ് കോൺഫിഗറേഷനുകൾക്ക് പകരം ടൈമിംഗോ ഹെഡറുകളോ കാരണം ഉണ്ടാകുന്ന ഫാൻ്റം എററുകൾ (phantom errors). നിലവിലില്ലാത്ത പ്രശ്നങ്ങൾ അവ റിപ്പോർട്ട് ചെയ്തത് എന്നെ വെറുതെ പാതിവഴിയിൽ കുടുക്കി. ലൈവ് സൈറ്റ് നേരിട്ട് പരിശോധിച്ചും ബ്രൗസറിലോ ഡയറക്ട് curl വഴിയോ ലക്ഷണങ്ങൾ ഉറപ്പുവരുത്തിയ ശേഷവും സ്റ്റാറ്റിക് അനാലിസിസിനെ (static analysis) വിശ്വസിക്കാൻ ഞാൻ പഠിച്ചു.
മറഞ്ഞിരിക്കുന്ന ചിലവ്
ആരും പറയാത്ത ഒരു കണക്കുണ്ട്: എന്റെ ടോക്കൺ ചെലവിന്റെ 93 ശതമാനവും കാഷഡ് കോൺടെക്സ്റ്റ് (cached context) വീണ്ടും വായിക്കുന്നതിനായിട്ടാണ് പോയത്.
ഒരു നീണ്ട Claude Code സെഷനിൽ, ഓരോ പുതിയ അഭ്യർത്ഥനയും മുൻപത്തെ സംഭാഷണ ചരിത്രം, ഫയൽ ബഫറുകൾ, വർക്കിംഗ് മെമ്മറി എന്നിവ വീണ്ടും പരിശോധിക്കാൻ മോഡലിനെ നിർബന്ധിക്കുന്നു. ഒരു സെഷനിലെ ആദ്യത്തെ ടാസ്ക് ചിലവ് കുറഞ്ഞതാകാം. എന്നാൽ പത്താമത്തെ ടാസ്ക് എത്തുമ്പോഴേക്കും, അടുത്ത വാചകം മനസ്സിലാക്കാൻ വേണ്ടി മോഡൽ അതിനുമുമ്പുള്ളതെല്ലാം വിശകലനം ചെയ്യേണ്ടി വരുന്നു. ചിലവ് വളരെ വേഗത്തിൽ വർദ്ധിക്കുന്നു. നീണ്ട സെഷനുകൾ ചിലവേറിയ പുനർവായന വ്യായാമങ്ങളായി മാറുന്നു, കൂടാതെ നിലവിലെ ജോലിയുമായി യാതൊരു ബന്ധവുമില്ലാത്ത പഴയ ജോലികളിൽ നിന്നുള്ള അവശിഷ്ടങ്ങൾ കൊണ്ട് കോൺടെക്സ്റ്റ് വിൻഡോ നിറയുകയും ചെയ്യുന്നു.
ഇതൊരു യാദൃശ്ചികതയല്ല. മോശമായ സെഷൻ മാനേജ്മെന്റിന് മേലുള്ള നേരിട്ടുള്ള നികുതിയാണിത്.
ഇത് എങ്ങനെ പരിഹരിക്കാം
പ്രശ്നങ്ങൾ തിരിച്ചറിഞ്ഞുകഴിഞ്ഞാൽ പരിഹാരങ്ങൾ ലളിതമാണ്.
ഒരു സെഷനെ ഒരു ടാസ്ക് ആയി മാത്രം പരിഗണിക്കുക. ജോലി മാറുമ്പോൾ, പുതിയൊരു സെഷൻ തുടങ്ങുക. കോൺടെക്സ്റ്റ് നിലനിർത്താനുള്ള പ്രലോഭനം ശക്തമാണ് — സെറ്റപ്പ് സമയം ലാഭിക്കുകയാണെന്ന് നിങ്ങൾക്ക് തോന്നും — എന്നാൽ യഥാർത്ഥത്തിൽ നിങ്ങൾ മെമ്മറി ഉയർന്ന പലിശയ്ക്ക് വാടകയ്ക്കെടുക്കുകയാണ് ചെയ്യുന്നത്.
അറിവുകൾ ചെറിയ, പ്രത്യേക മെമ്മറി ഫയലുകളിൽ സൂക്ഷിക്കുക. ബ്രാൻഡ് ഗൈഡ്ലൈനുകൾ, കോംപോണന്റ് ലൈബ്രറികൾ, അല്ലെങ്കിൽ SEO നിയമങ്ങൾ എന്നിവ സംഭാഷണ കോൺടെക്സ്റ്റിനുള്ളിൽ (conversational context) കൊണ്ടുനടക്കാൻ മോഡലിനെ അനുവദിക്കരുത്. അവ സംക്ഷിപ്തമായ ഫയലുകളായി ഡിസ്കിൽ എഴുതുകയും അവയെ കൃത്യമായി റഫർ ചെയ്യുകയും ചെയ്യുക. ഇത് വിവരങ്ങളെ ചിലവേറിയ വോളറ്റൈൽ കോൺടെക്സ്റ്റിൽ നിന്ന് (volatile context) കുറഞ്ഞ ചിലവുള്ള പെർസിസ്റ്റന്റ് സ്റ്റോറേജിലേക്ക് (persistent storage) മാറ്റുന്നു.
വ്യത്യസ്ത ജോലികൾക്കിടയിൽ, പഴയവ ഒഴിവാക്കുക. സെഷൻ അവസാനിപ്പിക്കുക. പുതിയൊന്ന് തുടങ്ങുക. മുപ്പത് സെക്കൻഡ് എടുക്കുന്ന ഈ സെറ്റപ്പ് പിന്നീട് വലിയ തുകകൾ ലാഭിക്കാനും ഹാലൂസിനേഷനുകൾ (hallucinations) ഒഴിവാക്കാനും സഹായിക്കും.
സ്കെയിലിംഗിനായുള്ള പാഠങ്ങൾ
ഇത്രയും വലിയ അളവിൽ ജോലി ചെയ്യണമെന്നുണ്ടെങ്കിൽ, ഫയലിനെ അല്ല, മറിച്ച് സിസ്റ്റത്തെയാണ് പരിശോധനയുടെ അടിസ്ഥാന യൂണിറ്റായി കാണുന്ന ഗാർഡ്റെയിലുകൾ (guardrails) നിങ്ങൾക്ക് ആവശ്യമാണ്.
പബ്ലിഷ് ചെയ്യുന്നതിന് മുമ്പ് ബെഞ്ച്മാർക്ക് ചെയ്യുക. ഒരു പേജ് റെൻഡർ ആകുന്നു എന്നതുകൊണ്ട് മാത്രം അത് കൃത്യമായി പ്രവർത്തിക്കുന്നു എന്ന് കരുതരുത്. ഡെപ്ലോയ് ചെയ്ത URL-ൽ ലോഡ് ടൈം, മൊബൈൽ ലേഔട്ട്, കോർ മെട്രിക്സ് എന്നിവ പരിശോധിക്കുക. ലോക്കൽ ഡെവലപ്മെന്റിലെ മനോഹരമായ ഒരു കോംപോണന്റ് യഥാർത്ഥ നെറ്റ്വർക്ക് സാഹചര്യങ്ങളിൽ തകരാറിലാകാം.
കോപ്പി ചെയ്യുന്നതിന് മുമ്പ് വ്യത്യാസങ്ങൾ (Diff) പരിശോധിക്കുക. ഒരിക്കലും ഒരു ബൾക്ക് സിങ്ക് (bulk sync) അല്ലെങ്കിൽ കോപ്പി ഓപ്പറേഷൻ അന്ധമായി