Spec-driven development യഥാർത്ഥ പ്രശ്നം പരിഹരിച്ചില്ല
AI ഏജന്റുകൾ തെറ്റായ കോഡ് എഴുതുന്നതിനുള്ള പുതിയ പരിഹാരമാണ് Spec-driven development (SDD).
ഇതിന്റെ പ്രവർത്തനരീതി (workflow) ലളിതമാണ്. നിങ്ങൾ ഒരു ഘടനയുള്ള സ്പെക് (spec) തയ്യാറാക്കുന്നു. ഒരു ഏജന്റ് ആ പ്ലാൻ നടപ്പിലാക്കുന്നു. നിങ്ങൾ അതിന്റെ ഫലം പരിശോധിക്കുന്നു. GitHub Spec Kit, OpenSpec, Kiro തുടങ്ങിയ ടൂളുകൾ ഈ മാറ്റത്തിന് നേതൃത്വം നൽകുന്നു.
വെറും പ്രോംപ്റ്റിംഗിനേക്കാൾ (raw prompting) മികച്ച രീതിയാണിത്. എന്നാൽ ഇതിന് വലിയൊരു പോരായ്മയുണ്ട്.
സ്പെക് തന്നെയായിരിക്കണം എല്ലാ കാര്യങ്ങളുടെയും അടിസ്ഥാനം (source of truth) എന്ന് ഇത് അനുമാനിക്കുന്നു. എന്നാൽ ഇത് ഒരു മിഥ്യയാണ്.
കഴിഞ്ഞ 20 വർഷമായി, ഡോക്യുമെന്റേഷനും കോഡും ഒരേപോലെ നിലനിർത്താൻ നമ്മൾ ശ്രമിച്ചു. ഡിസൈൻ ഡോക്സുകൾ, വിക്കികൾ, READMEs എന്നിവയെല്ലാം പരാജയപ്പെട്ടു. എന്തുകൊണ്ട്? കാരണം കോഡ് എഡിറ്റ് ചെയ്യുന്നത് വേഗത്തിലുമാണ്, അത് പെട്ടെന്ന് ഫലം നൽകുന്നു. എന്നാൽ ഒരു ഡോക്യുമെന്റ് എഡിറ്റ് ചെയ്യുന്നത് സാവധാനത്തിലാണ്, അത് പെട്ടെന്ന് മാറ്റങ്ങളൊന്നും കാണിക്കുന്നില്ല. വേഗതയുടെ മുന്നിൽ ഡോക്യുമെന്റേഷൻ എപ്പോഴും പരാജയപ്പെടുന്നു.
SDD-യും ഇതേ പ്രശ്നം നേരിടുന്നു.
ഒരു ഏജന്റ് ഒരു തടസ്സത്തിൽ (constraint) അകപ്പെടുമ്പോൾ, അത് കോഡ് പ്രവർത്തിപ്പിക്കാനായി മാറ്റങ്ങൾ വരുത്തുന്നു. ഇപ്പോൾ കോഡും സ്പെക്കും തമ്മിൽ പൊരുത്തപ്പെടില്ല. ഏതാനും ദിവസങ്ങൾക്കുള്ളിൽ സ്പെക്ക് ഉപയോഗശൂന്യമായിത്തീരും. ഇത് പരിഹരിക്കാൻ "അച്ചടക്കം" (discipline) പാലിക്കണമെന്ന് മിക്ക ഫ്രെയിംവർക്കുകളും പറയുന്നു. എന്നാൽ അച്ചടക്കം എന്നത് മുൻപും പലതവണ നമ്മളെ പരാജയപ്പെടുത്തിയ ഒന്നാണ്.
കോഡിംഗിന് മുമ്പ് തന്നെ ഒരു പൂർണ്ണമായ സ്പെക് തയ്യാറാക്കുക എന്നത്, ഇംപ്ലിമെന്റേഷൻ സമയത്ത് നിങ്ങൾക്ക് ഒന്നും പഠിക്കാൻ കഴിയില്ല എന്ന് കരുതുന്നതിന് തുല്യമാണ്. ഇത് ഫീഡ്ബാക്ക് ലൂപ്പിനെ (feedback loop) തകർക്കുന്നു. ഇത് അജൈൽ ഡെവലപ്മെന്റിനെ (agile development) വളരെ സങ്കീർണ്ണമായ ഒരു മുൻകൂർ പ്രക്രിയയാക്കി മാറ്റുന്നു.
ഒരു ഡെവലപ്പർ SDD ഉപയോഗിച്ച് മാസങ്ങളോളം നീണ്ടുനിന്ന ഒരു പ്രോജക്റ്റ് നടത്തി. ഏജന്റ് എല്ലാ സ്പെക്കുകളും കൃത്യമായി പാലിച്ചു. എങ്കിലും സിസ്റ്റം പരാജയപ്പെട്ടു. നിർമ്മാണ വേളയിൽ മാത്രം ലഭിക്കുന്ന അറിവുകളെ ഉൾക്കൊള്ളാൻ സ്പെക്കിന് കഴിഞ്ഞില്ല. ഒരു ചെറിയ ഇൻഫ്രാ (infra) മാറ്റം പോലും മുഴുവൻ സ്പെക് ഗ്രാഫിനെയും തകർത്തു കളഞ്ഞു.
മറ്റൊരു ടീം SDD പരീക്ഷിച്ചു നോക്കിയപ്പോൾ അത് 10 മടങ്ങ് സാവധാനമാണെന്ന് കണ്ടെത്തി. അവർക്ക് കൂടുതൽ നടപടിക്രമങ്ങൾ (ceremony) ഉണ്ടായിരുന്നുവെങ്കിലും ബഗുകളുടെ എണ്ണത്തിൽ മാറ്റമൊന്നും വന്നില്ല.
ലക്ഷ്യം കൂടുതൽ ഡോക്യുമെന്റുകൾ ഉണ്ടാക്കുക എന്നതാകരുത്.
സ്പെക്കുകൾ എങ്ങനെ സജീവമായി നിലനിർത്തുക എന്നതാണ് യഥാർത്ഥ പ്രശ്നം. സ്വയം അപ്ഡേറ്റ് ചെയ്യപ്പെടുന്ന സ്പെക്കുകൾ നമുക്ക് ആവശ്യമാണ്. കോഡിൽ നിന്നും പ്രവർത്തിക്കുന്ന സിസ്റ്റത്തിൽ നിന്നും സ്പെക് സ്വയം കണ്ടെത്താൻ കഴിയുന്ന (infer) ടൂളുകൾ നമുക്ക് വേണം. ഇത് ഒരു lockfile പോലെ പ്രവർത്തിക്കണം. ഇത് പൂർണ്ണമായും ഓട്ടോമാറ്റിക് ആയിരിക്കണം.
ഇത് ഇപ്പോൾ സാധ്യമാണോ എന്ന് എനിക്ക് ഉറപ്പില്ല. പ്രൊഡക്ഷനിൽ വർക്ക് ചെയ്യുന്ന ആളുകളിൽ നിന്ന് എനിക്ക് ഇതിനെക്കുറിച്ച് അറിയണം.
- നിങ്ങളുടെ സ്പെക്ക് മൂന്നാം ആഴ്ച കഴിഞ്ഞും നിലനിൽക്കുന്നുണ്ടോ?
- സ്പെക്കും കോഡും തമ്മിൽ വ്യത്യാസം വരുമ്പോൾ (drifts), അതിന് കാരണമെന്താണ്?
- കോഡിൽ നിന്നോ ടെലിമെറ്ററിയിൽ നിന്നോ സ്പെക്കുകൾ നിർമ്മിക്കാൻ നിങ്ങൾ ശ്രമിച്ചിട്ടുണ്ടോ?
- ഈ കർശനമായ രീതി മൂല്യം വർദ്ധിപ്പിക്കുന്നുണ്ടോ അതോ വെറും നടപടിക്രമം മാത്രമാണോ?
Optional learning community: https://t.me/GyaanSetuAi