AI സോഫ്റ്റ്വെയർ വികസനം വളരെ ലാഭകരമാക്കുമെന്ന് പലരും പറയുന്നു. മോഡലുകൾ എഞ്ചിനീയർമാരെ മാറ്റിസ്ഥാപിക്കുമെന്നും മിനിറ്റുകൾക്കുള്ളിൽ ജോലികൾ പൂർത്തിയാക്കുമെന്നും അവർ സങ്കൽപ്പിക്കുന്നു. ആ കഥ കേൾക്കാൻ ആകർഷകമാണെങ്കിലും അത് പൂർണ്ണമായും സത്യമല്ല. സോഫ്റ്റ്വെയർ നിർമ്മാണത്തിന്റെ സാമ്പത്തികശാസ്ത്രം മാറിയിട്ടേയുള്ളൂ, അപ്രത്യക്ഷമായിട്ടില്ല. ആദ്യത്തെ കോഡിംഗ് അസിസ്റ്റന്റ് പുറത്തിറങ്ങിയപ്പോൾ ടെക്നിക്കൽ ഡെബ്റ്റ് (Technical debt) ഇല്ലാതായില്ല. ഞങ്ങൾ അതിന് പണം നൽകാൻ പുതിയൊരു വഴി കണ്ടെത്തി എന്ന് മാത്രം.
പഴയ ഇൻവോയ്സ്: ഹെഡ് കൗണ്ട് (Head Count)
പതിറ്റാണ്ടുകളായി, ടെക്നിക്കൽ ഡെബ്റ്റ് ഒരു പരിചിതമായ ദുഷിച്ച ചക്രം (doom loop) സൃഷ്ടിച്ചു. ഒരു കോഡ്ബേസ് ദുർബലമായിക്കൊണ്ടിരുന്നു. ഒരിക്കൽ ദിവസങ്ങൾ എടുത്തിരുന്ന ഫീച്ചറുകൾക്ക് ആഴ്ചകൾ വേണ്ടിവന്നു. ഡെഡ്ലൈനുകൾ തെറ്റിയതോടെ, നേതൃത്വം കൂടുതൽ ജീവനക്കാരെ നിയമിക്കാൻ തീരുമാനിച്ചു. വലിയ ടീമുകൾ കാര്യങ്ങൾ കൂടുതൽ സാവധാനത്തിലാക്കി. ഏകോപനത്തിനായുള്ള അധിക ജോലിഭാരം (coordination overhead) വർദ്ധിച്ചു, സ്റ്റാൻഡ്-അപ്പുകൾ (stand-ups) കൂട്ടിമുട്ടി, കോൺവേയുടെ നിയമം (Conway’s Law) പ്രാവർത്തികമായി: സോഫ്റ്റ്വെയർ നിർമ്മിക്കുന്ന ആളുകളുടെ ആശയവിനിമയ പിഴവുകളെ പ്രതിഫലിപ്പിക്കാൻ സോഫ്റ്റ്വെയർ തുടങ്ങി. കൂടുതൽ ബഗുകൾ (bugs) കടന്നുവന്നു. ഓരോ പാച്ചും (patch) പുതിയ സങ്കീർണ്ണതകൾ കൂട്ടിച്ചേർത്തു. കമ്പനികൾ ഇതിന് അവർക്കറിയാവുന്ന ഒരേയൊരു കറൻസി ഉപയോഗിച്ച് പണം നൽകി: മനുഷ്യരുടെ ശമ്പളം. ഇതിന്റെ ചിലവ് വ്യക്തമായിരുന്നു. ഓരോ പാദവാർഷിക ബജറ്റ് അവലോകനത്തിലും അത് പ്രകടമായിരുന്നു.
പുതിയ ഇൻവോയ്സ്: ടോക്കണുകളും കോൺടെക്സ്റ്റും (Tokens and Context)
ജനറേറ്റീവ് AI ഈ ചക്രം തകർത്തിട്ടില്ല. അത് കേവലം ഒരു ബദൽ പണമിടപാട് രീതിയാണ് അവതരിപ്പിച്ചത്. തടസ്സങ്ങൾ മറികടക്കാൻ അഞ്ച് എഞ്ചിനീയർമാരെ നിയമിക്കുന്നതിന് പകരം, ഒരു കമ്പനി ഇപ്പോൾ കൂടുതൽ കമ്പ്യൂട്ടിനായി (compute) ക്രെഡിറ്റ് കാർഡ് ഉപയോഗിക്കുന്നു. ലക്ഷണങ്ങൾ വ്യത്യസ്തമായി തോന്നാമെങ്കിലും, അടിസ്ഥാനപരമായ പ്രശ്നം ഒന്നുതന്നെയാണ്.
ഒരു മോഡൽ പരാജയപ്പെടാൻ തുടങ്ങുമ്പോൾ—ആന്തരിക API-കൾ ഹാളുസിനേറ്റ് ചെയ്യുമ്പോഴോ (hallucinating), നിർണ്ണായകമായ എഡ്ജ് കേസുകൾ (edge cases) വിട്ടുപോകുമ്പോഴോ, തെറ്റായ കാരണങ്ങളാൽ പാസായ ടെസ്റ്റുകൾ നിർമ്മിക്കുമ്പോഴോ—അതിനെ റീഫാക്ടർ (refactor) ചെയ്യുക എന്നത് അപൂർവ്വമായ പ്രതികരണമാണ്. പകരം ഇൻഫറൻസിനായി (inference) പണം ചിലവഴിക്കുക എന്നതാണ് സാധാരണയായി സംഭവിക്കുന്നത്. ടീമുകൾ കോൺടെക്സ്റ്റ് വിൻഡോ അപ്ഗ്രേഡുകൾ വാങ്ങുന്നു, മൾട്ടി-ഏജന്റ് റീട്രൈ ലൂപ്പുകൾ (multi-agent retry loops) നിർമ്മിക്കുന്നു, വലിയ ഫ്രോണ്ടിയർ മോഡലുകളിലേക്ക് വർക്ക്ലോഡുകൾ മാറ്റുന്നു, അല്ലെങ്കിൽ വ്യത്യാസങ്ങൾ (diff) സ്വീകാര്യമാകുന്നതുവരെ 'റീജനറേറ്റ്' ബട്ടൺ അമർത്തുന്നു. ഈ തന്ത്രങ്ങൾ ഒരു സ്പ്രിന്റിനോ രണ്ടോ വേഗത നിലനിർത്താൻ സഹായിച്ചേക്കാം. ജിറ (Jira) ബോർഡ് പച്ച നിറത്തിൽ കാണപ്പെടുന്നു. അതേസമയം, യഥാർത്ഥ ആർക്കിടെക്ചർ മാറ്റമില്ലാതെ തുടരുന്നു: പഴയതുപോലെ തന്നെ സങ്കീർണ്ണമായ ഡിപെൻഡൻസികൾ, മാറ്റം വരുത്താൻ കഴിയുന്ന ഗ്ലോബൽ സ്റ്റേറ്റ് (mutable global state), നിലവിലെ ആർക്കും പൂർണ്ണമായി മനസ്സിലാകാത്ത ആ പഴയ മോണോലിത്ത് (monolith) എന്നിവ തന്നെ തുടരുന്നു.
എന്തുകൊണ്ട് മോശം കോഡ് കൂടുതൽ ടോക്കണുകൾ ചിലവാക്കുന്നു
ലാർജ് ലാംഗ്വേജ് മോഡലുകൾ (LLMs) മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നത് വൃത്തിയുള്ള അബ്സ്ട്രാക്ഷനുകളിലാണ് (clean abstractions). എന്നാൽ മിക്ക എന്റർപ്രൈസ് റിപ്പോസിറ്ററികളും പുരാവസ്തു സൈറ്റുകൾ പോലെയാണ്. അവയിൽ സർക്കുലർ പാക്കേജ് ഡിപെൻഡൻസികളും, ഇനീഷ്യലൈസേഷൻ സ്ക്രിപ്റ്റുകളിൽ ഒളിഞ്ഞിരിക്കുന്ന സൈഡ് ഇഫക്റ്റുകളും, ഡാറ്റാബേസ് ട്രിഗറുകളിലും മിഡിൽവെയർ ലെയറുകളിലും ഫ്രണ്ട്-എൻഡ് ഘടകങ്ങളിലും ചിതറിക്കിടക്കുന്ന ബിസിനസ് ലോജിക്കും അടങ്ങിയിരിക്കുന്നു. അത്തരം സാഹചര്യങ്ങളിൽ, മോഡൽ പുതിയ ലോജിക് എഴുതുന്നതിന് പകരം അത് മനസ്സിലാക്കാൻ വേണ്ടി ടോക്കണുകൾ ഉപയോഗിക്കുന്നു.
ഒരു 128,000-ടോക്കൺ കോൺടെക്സ്റ്റ് വിൻഡോയുടെ വലിയൊരു ഭാഗം സിസ്റ്റത്തിന്റെ ഘടന മനസ്സിലാക്കാൻ വേണ്ടി മാത്രം ചിലവാകുന്നു. ബാക്കിയുള്ള ഭാഗം മാത്രമേ യഥാർത്ഥ പ്രശ്നപരിഹാരത്തിനായി ഉപയോഗിക്കാൻ കഴിയൂ. ഒരു സ്ട്രക്ചറൽ എഞ്ചിനീയറോട് പുതിയൊരു നില (floor) രൂപകൽപ്പന ചെയ്യാൻ ആവശ്യപ്പെടുകയും, എന്നാൽ ഓരോ കണക്കുകൂട്ടലിനും മുമ്പ് നിലവിലുള്ള കെട്ടിടത്തിന്റെ ബ്ലൂപ്രിന്റുകൾ ഓർമ്മയിൽ നിന്ന് വീണ്ടും വരയ്ക്കാൻ നിർബന്ധിക്കുകയും ചെയ്യുന്നതുപോലെയാണിത്. ഇതിന്റെ ഫലം ആഴമില്ലാത്ത പരിഹാരങ്ങളാണ്. മോഡലിന് മുറി വൃത്തിയാക്കാൻ ആവശ്യമായ അധികാരം അല്ലെങ്കിൽ ആർക്കിടെക്ചറൽ കോൺടെക്സ്റ്റ് ഇല്ലാത്തതിനാൽ, അത് കാണുന്ന അലങ്കോലങ്ങൾ തന്നെ പ്രതിഫലിപ്പിക്കുന്നു.
വേഗതയേറിയ ഔട്ട്പുട്ട്, സാവധാനത്തിലുള്ള ഷിപ്പിംഗ്
വേഗതയേറിയ ജനറേഷൻ എന്നാൽ വേഗതയേറിയ ഷിപ്പിംഗ് എന്നല്ല അർത്ഥം. നിങ്ങളുടെ ആർക്കിടെക്ചറിൽ മോഡുലാരിറ്റി (modularity) ഇല്ലെങ്കിൽ, AI നിർമ്മിക്കുന്ന ഓരോ മാറ്റവും കഠിനമായ ഹ്യൂമൻ റിവ്യൂവും റഗ്രഷൻ ടെസ്റ്റിംഗും (regression testing) ആവശ്യപ്പെടുന്നു. ഒരു മോഡലിന് ഒരു ഉച്ചകഴിഞ്ഞ് പത്ത് പുൾ റിക്വസ്റ്റുകൾ (pull requests) നിർമ്മിക്കാൻ കഴിഞ്ഞേക്കാം, എന്നാൽ ആ പുൾ റിക്വസ്റ്റുകൾ ഇന്റഗ്രേഷൻ എൻവയോൺമെന്റുകൾ, സെക്യൂരിറ്റി സ്കാനറുകൾ, കംപ്ലയൻസ് ചെക്ക്ലിസ്റ്റുകൾ എന്നിവയിലൂടെ കടന്നുപോകേണ്ടതുണ്ട്. വ്യക്തമായ മോഡ്യൂൾ അതിരുകൾ ഇല്ലാതെ, AI യന്ത്രത്തിന്റെ വേഗതയിൽ ബഗുകൾ അവതരിപ്പിക്കുന്നു. ഒരു ഷെയർഡ് യൂട്ടിലിറ്റി മാറ്റാനോ, തെറ്റായ അനുമാനങ്ങളോടെ മൂന്ന് സ്ഥലങ്ങളിൽ മാറ്റം വരുത്താനോ, മനുഷ്യർ പുലർച്ചെ മാത്രം കണ്ടെത്താൻ കഴിയുന്ന റേസ് കണ്ടീഷനുകൾ (race conditions) ഉണ്ടാക്കാനോ ഇതിന് സാധിക്കും. ഇവിടെ തടസ്സം കീബോർഡിൽ നിന്ന് വാലിഡേഷൻ പൈപ്പ്ലൈനിലേക്ക് മാറുന്നു, കൂടാതെ മാറ്റങ്ങളുടെ അളവ് പത്തിരട്ടി വർദ്ധിക്കുന്നത് കൈകാര്യം ചെയ്യാൻ ആ പൈപ്പ്ലൈൻ രൂപകൽപ്പന ചെയ്തിട്ടില്ല.
മറഞ്ഞിരിക്കുന്ന പരിധി
AI-ക്ക് മുൻപുള്ള കാലത്ത്, നിങ്ങളുടെ നിയമന ബജറ്റായിരുന്നു (hiring budget) പ്രധാന പരിധി. അത് ഒരു സ്പ്രെഡ്ഷീറ്റിൽ നോക്കിയാൽ എളുപ്പത്തിൽ മനസ്സിലാക്കാമായിരുന്നു. എന്നാൽ ഇപ്പോൾ, ഫിനാൻസ് ടീമുകൾ പോലും ശ്രദ്ധിക്കാത്ത ചില കാര്യങ്ങളിലാണ് നിയന്ത്രണം ഒളിഞ്ഞിരിക്കുന്നത്: ഇൻഫറൻസ് ചിലവുകൾ, എംബഡിംഗ് സ്റ്റോറേജ്, കോൺടെക്സ്റ്റ് വിൻഡോ വിപുലീകരണം, കൂടാതെ CI റണ്ണറുകളെ തടസ്സപ്പെടുത്തുന്ന ഓട്ടോമേറ്റഡ് ടെസ്റ്റിംഗ് പ്രശ്നങ്ങൾ എന്നിവയാണവ. ഓരോ പുതിയ ഫീച്ചറിന്റെയും യഥാർത്ഥ ചിലവ് നിശബ്ദമായി വർദ്ധിച്ചുകൊണ്ടിരിക്കുമ്പോൾ, പ്രൊഡക്റ്റിവിറ്റി ഡാഷ്ബോർഡുകൾ പച്ച നിറത്തിൽ തിളങ്ങുന്നു.
Architectural entropy is the real villain here. LLMs scale code production beautifully, but they do not reduce complexity. They do not untangle microservices, eliminate dead code, or collapse inheritance hierarchies. Once a system crosses the threshold where humans struggle to reason about it, AI struggles too. At that inflection point, costs curve upward whether you