2026-ലെ ഒരു Sonar സർവേ പ്രകാരം 88% ഡെവലപ്പർമാരും പറയുന്നത് AI നിർമ്മിത കോഡുകൾ സാങ്കേതിക കടം (technical debt) വർദ്ധിപ്പിക്കുന്നു എന്നാണ്. കൃത്യമായ സ്പെസിഫിക്കേഷൻ അടിസ്ഥാനമാക്കിയുള്ള വികസനം (spec-driven development) ഈ പ്രവണത തടയാൻ സഹായിക്കുമെന്ന് ഇതിന്റെ അനുകൂലികൾ വാദിക്കുന്നു.
ഈ പ്രശ്നം എന്തുകൊണ്ട് പ്രധാനമാകുന്നു
ഒരു മനുഷ്യന് അവ്യക്തമായ ഒരു ടിക്കറ്റ് ലഭിക്കുമ്പോൾ, അവർ കൂടുതൽ വ്യക്തതയ്ക്കായി ചോദ്യങ്ങൾ ചോദിക്കും. എന്നാൽ നേരെമറിച്ച്, ഒരു AI ഏജന്റ് അവ്യക്തതകൾ സ്വന്തം ഊഹങ്ങൾ ഉപയോഗിച്ച് പൂരിപ്പിക്കുകയും ശരിയാണെന്ന് തോന്നിക്കുന്ന കോഡ് നൽകുകയും ചെയ്യുന്നു. ഈ തെറ്റായ വിശ്വാസം വലിയ നഷ്ടമുണ്ടാക്കും: പകുതിയിലധികം പേർക്കും അടിസ്ഥാന പരിശോധനകളിൽ വിജയിക്കുന്നതും എന്നാൽ സൂക്ഷ്മമായ പിഴവുകൾ ഒളിപ്പിച്ചു വെച്ചിരിക്കുന്നതുമായ കോഡുകൾ കണ്ടുമുട്ടിയിട്ടുണ്ടെന്ന് ഇതേ Sonar സർവേ റിപ്പോർട്ട് ചെയ്യുന്നു. ഈ പിഴവുകൾ സാങ്കേതിക കടമായി (technical debt) അടിഞ്ഞുകൂടുകയും, പിന്നീട് കോഡ് മാറ്റം വരുത്തേണ്ടി വരികയും (refactors), ഫീച്ചറുകൾ നൽകുന്നതിനെ മന്ദഗതിയിലാക്കുകയും, മെയിന്റനൻസ് ബജറ്റ് വർദ്ധിപ്പിക്കുകയും ചെയ്യുന്നു.
സ്പെസിഫിക്കേഷൻ അധിഷ്ഠിത വികസനം (Spec-driven development) എങ്ങനെയായിരിക്കും
Spec-driven development (SDD) നിലവിലെ രീതിയെ തിരുത്തി എഴുതുന്നു. ഒരു ചെറിയ യൂസർ സ്റ്റോറി നൽകി AI മോഡലിനെ പ്രോംപ്റ്റ് ചെയ്യുന്നതിന് പകരം, കോഡിനോടൊപ്പം തന്നെ വെർഷൻ കൺട്രോൾ സിസ്റ്റത്തിൽ സൂക്ഷിക്കാവുന്ന, ഏജന്റിന് പ്രവർത്തിപ്പിക്കാൻ കഴിയുന്ന വിശദമായ ഒരു സ്പെസിഫിക്കേഷൻ ടീം തയ്യാറാക്കുന്നു. ഈ സ്പെസിഫിക്കേഷൻ ഒരു single source of truth ആയി മാറുന്നു—അതായത്, ഉദ്ദേശ്യം (intent), എഡ്ജ് കേസുകൾ (edge cases), പെർഫോമൻസ് പ്രതീക്ഷകൾ, AI മോഡൽ പാലിക്കേണ്ട നിർബന്ധിത നിബന്ധനകൾ എന്നിവ ഇതിൽ രേഖപ്പെടുത്തുന്നു.
ഈ പ്രക്രിയ മനുഷ്യന്റെ ഡിസൈൻ ജോലികളെ ഇല്ലാതാക്കുന്നില്ല; പകരം അതിനെ കൃത്യമായി രേഖപ്പെടുത്തുന്നു. തീരുമാനങ്ങൾ ഒരു ഡെവലപ്പറുടെ ഓർമ്മയിൽ നിന്ന് ഒരു കൃത്യമായ രേഖയിലേക്ക് മാറ്റുന്നതിലൂടെ, മനുഷ്യർക്കും ഭാവിയിലെ AI ഏജന്റുകൾക്കും ഒരു കോഡ് എന്തുകൊണ്ട് ഇത്തരത്തിൽ പ്രവർത്തിക്കുന്നു എന്ന് മനസ്സിലാക്കാൻ സാധിക്കുന്നു. ഒരു സ്പെസിഫിക്കേഷൻ തയ്യാറാക്കാൻ തുടക്കത്തിൽ കൂടുതൽ പരിശ്രമം ആവശ്യമാണെങ്കിലും, അവ്യക്തമായ AI ഔട്ട്പുട്ടുകൾ ഡീബഗ് (debug) ചെയ്യുന്നത് പിന്നീട് വലിയ ചിലവുകൾ ഉണ്ടാക്കും.
വർക്ക്ഫ്ലോയിൽ വരുത്തുന്ന മാറ്റങ്ങൾ
Product backlog – ഐറ്റങ്ങൾ ചുരുക്കി എഴുതുക, ഉദ്ദേശ്യവും ഉയർന്ന തലത്തിലുള്ള സ്വീകാര്യത മാനദണ്ഡങ്ങളും (acceptance criteria) മാത്രം ഉൾപ്പെടുത്തുക. ഈ ലിസ്റ്റ് മുൻഗണന നിശ്ചയിക്കാൻ സഹായിക്കുന്നു.
Sprint planning – ടീമുകൾ പൊതുവായ ലക്ഷ്യത്തെക്കുറിച്ച് ചർച്ച ചെയ്യുകയും ഒരു Sprint Goal തീരുമാനിക്കുകയും ചെയ്യുന്നു, എന്നാൽ സ്പെസിഫിക്കേഷൻ തയ്യാറാകുന്നത് വരെ വിശദമായ നടപ്പിലാക്കൽ നടപടികൾ മാറ്റിവെക്കുന്നു.
During the sprint – ടാസ്ക് ഏറ്റെടുക്കുന്ന വ്യക്തി കൃത്യമായ, മെഷീൻ റീഡബിൾ ആയ ഒരു സ്പെസിഫിക്കേഷൻ എഴുതുന്നു. ഇൻപുട്ട് ഫോർമാറ്റുകൾ, പ്രതീക്ഷിക്കുന്ന ഔട്ട്പുട്ടുകൾ, എറർ ഹാൻഡ്ലിംഗ് (error handling), മറ്റ് ആവശ്യകതകൾ എന്നിവ സ്പെസിഫിക്കേഷനിൽ ഉൾപ്പെടുന്നു. സ്പെസിഫിക്കേഷൻ വെർഷൻ കൺട്രോൾ ചെയ്യുന്നത് കൊണ്ട്, റിവ്യൂവർമാർക്ക് കോഡ് പോലെ തന്നെ ഇതിൽ കമന്റുകൾ നൽകാനും മാറ്റങ്ങൾ നിർദ്ദേശിക്കാനും അംഗീകരിക്കാനും സാധിക്കും.
Definition of Done – ക്വാളിറ്റി ഗേറ്റിൽ (quality gate) “Spec reviewed and approved” എന്നത് കൂടി ചേർക്കുക. സ്പെസിഫിക്കേഷൻ ഇംപ്ലിമെന്റേഷൻ പോലെ തന്നെ റിവ്യൂ മാനദണ്ഡങ്ങൾ പാലിക്കുന്നത് വരെ കോഡ് പൂർത്തിയായതായി കണക്കാക്കില്ല.
Kanban adaptation – “Spec Drafted”, “Spec Approved” എന്നിങ്ങനെ രണ്ട് പുതിയ കോളങ്ങൾ ചേർക്കുക. ഇപ്പോൾ വർക്ക് ഐറ്റങ്ങൾ backlog → Sprint Goal → Spec Drafted → Spec Approved → In Progress → Done എന്ന ക്രമത്തിൽ നീങ്ങുന്നു. ഈ മാറ്റം മുമ്പ് ശ്രദ്ധിക്കപ്പെടാതിരുന്ന ഏകോപന ഘട്ടത്തെ വ്യക്തമാക്കുന്നു.
സ്പെസിഫിക്കേഷനുകൾ നടപ്പിലാക്കുന്ന ടൂളുകൾ
GitHub Spec Kit, AWS Kiro തുടങ്ങിയ പ്ലാറ്റ്ഫോമുകൾ, AI കോഡ് ജനറേഷൻ തുടങ്ങുന്നതിന് മുമ്പ് ആവശ്യകതകളുടെ രേഖ (requirements document) നിർബന്ധമാക്കുന്ന സംവിധാനങ്ങൾ ഏർപ്പെടുത്തിയിട്ടുണ്ട്. ഇവ AI മോഡലുകളെ ഇല്ലാതാക്കുന്നില്ല; പകരം AI ഏജന്റുകളെ മനുഷ്യന്റെ ഉദ്ദേശ്യങ്ങളുമായി യോജിപ്പിക്കുന്നു. സ്പെസിഫിക്കേഷനെ ഒരു മുൻകൂർ നിബന്ധനയാക്കുന്നതിലൂടെ, നിലവിലുള്ള CI/CD പൈപ്പ്ലൈനുകളെ തടസ്സപ്പെടുത്താതെ തന്നെ ഈ മാറ്റം ഓട്ടോമേറ്റ് ചെയ്യാൻ ഈ ടൂളുകൾ സഹായിക്കുന്നു.
ഉണ്ടായേക്കാവുന്ന എതിർപ്പുകൾ
സ്പെസിഫിക്കേഷൻ എഴുതുന്നത് വേഗത്തിൽ നടക്കുന്ന അജൈൽ (agile) പ്രക്രിയയിൽ തടസ്സമുണ്ടാക്കുമെന്ന് വിമർശകർ പറയുന്നു. എന്നാൽ ഇതിനുള്ള മറുപടി ഇതാണ്: ഒരു അവ്യക്തമായ പ്രോംപ്റ്റിൽ നിന്ന് ലഭിക്കുന്ന AI കോഡ് പിന്നീട് ഡീബഗ് ചെയ്യാൻ ചെലവാക്കുന്ന സമയത്തേക്കാൾ വളരെ കുറഞ്ഞ സമയമേ ഒരു സ്പെസിഫിക്കേഷൻ തയ്യാറാക്കാൻ ആവശ്യമായി വരുന്നുള്ളൂ.
ആവശ്യകതകൾ മാറുന്നതിനനുസരിച്ച് സ്പെസിഫിക്കേഷനുകൾ കാലഹരണപ്പെട്ടേക്കാം എന്നതും മറ്റൊരു ആശങ്കയാണ്. വെർഷൻ കൺട്രോൾ ഇന്റഗ്രേഷൻ ഇതിന് പരിഹാരമാണ്: സ്പെസിഫിക്കേഷനിലെ ഏതൊരു മാറ്റവും ഒരു പുതിയ commit സൃഷ്ടിക്കുകയും, അത് ഒരു റിവ്യൂവിന് കാരണമാവുകയും, അതുവഴി ടീമിനെ ബന്ധപ്പെട്ട കോഡ് വീണ്ടും വിലയിരുത്താൻ നിർബന്ധിക്കുകയും ചെയ്യുന്നു. പ്രായോഗികമായി പറഞ്ഞാൽ, സ്പെസിഫിക്കേഷനുകളെ കോഡ് പോലെ കൈകാര്യം ചെയ്യുന്നത് ഡോക്യുമെന്റേഷൻ എപ്പോഴും പുതുമയോടെ നിലനിർത്താൻ സഹായിക്കുന്നു.
ഇനി ശ്രദ്ധിക്കേണ്ട കാര്യങ്ങൾ
ഇത് പ്രാരംഭ ഘട്ടത്തിലാണെങ്കിലും ഇതിന്റെ വളർച്ച പ്രകടമാണ്. AI കോഡ് ജനറേറ്ററുകൾ കൂടുതൽ കാര്യക്ഷമമാകുമ്പോൾ, കൃത്യമായ, മെഷീൻ റീഡബിൾ ആയ നിർദ്ദേശങ്ങളുടെ ആവശ്യകത വർദ്ധിച്ചുകൊണ്ടേയിരിക്കും.
ചുരുക്കത്തിൽ: അവ്യക്തമായ പ്രോംപ്റ്റുകളെ കൃത്യമായ, റിവ്യൂ ചെയ്ത സ്പെസിഫിക്കേഷനുകളാക്കി മാറ്റുന്നത് ഒരു അധിക ഘട്ടമായി തോന്നാമെങ്കിലും, അത് ഊഹങ്ങൾ ഒഴിവാക്കി ഉത്തരവാദിത്തമുള്ള തീരുമാനങ്ങളിലേക്ക് നമ്മെ എത്തിക്കുന്നു.