𝗧𝗵𝗲 𝗖𝗼𝗱𝗲 𝗜𝘀 𝗖𝗵𝗲𝗮𝗽. 𝗧𝗵𝗲 𝗦𝗽𝗲𝗰 𝗜𝘀 𝗧𝗵𝗲 𝗔𝘀𝘀𝗲𝘁.
കോഡ് ഒരു വിലകുറഞ്ഞ വസ്തുവായി മാറിക്കൊണ്ടിരിക്കുകയാണ്. യഥാർത്ഥ മൂല്യം ഇപ്പോൾ സ്പെസിഫിക്കേഷനിലാണ് കുടികൊള്ളുന്നത്.
ഇംപ്ലിമെന്റേഷൻ പ്ലാനുകൾ കൈകൊണ്ട് എഴുതാൻ ഞാൻ കുറഞ്ഞ സമയം ചെലവഴിക്കുന്നു. ഡിസൈനിനായി ഞാൻ കൂടുതൽ സമയം ചെലവഴിക്കുന്നു. AI ഇത് സാധ്യമാക്കുന്നു. ഇത് എഞ്ചിനീയറിംഗ് വിവേകത്തെ (engineering judgment) മാറ്റിസ്ഥാപിക്കുന്നില്ല, മറിച്ച് അത് എവിടെ ഉപയോഗിക്കണം എന്നതിനെ മാറ്റുന്നു.
സ്പെസിഫിക്കേഷനുകളും കോഡും തയ്യാറാക്കാൻ ഞാൻ AI-യെ ഉപയോഗിക്കുന്നു. ലക്ഷ്യങ്ങൾ (intent) നിർവചിക്കുക എന്നതും പരിമിതികൾ (constraints) തിരിച്ചറിയുക എന്നതുമാണ് ഇപ്പോൾ എന്റെ ജോലി. എഴുത്ത് എന്നത് ഈ പ്രക്രിയയിലെ ഏറ്റവും കുറഞ്ഞ മൂല്യമുള്ള ഭാഗമാണ്.
എന്റെ സ്പെസിഫിക്കേഷനുകൾ ഒരു വിക്കി (wiki) വായിക്കുന്ന മനുഷ്യർക്ക് വേണ്ടിയുള്ളതല്ല. അവ അടുത്ത AI സെഷന് വേണ്ടിയുള്ളതാണ്. പുതിയ വിശദീകരണങ്ങളില്ലാതെ തന്നെ ജോലി തുടരാൻ ഒരു AI-യെ അവ അനുവദിക്കണം.
ഫലപ്രദമായ സ്പെസിഫിക്കേഷനുകൾ ഇവയിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു:
- ആവശ്യകതകൾ (Requirements)
- പരിമിതികൾ (Constraints)
- സ്വീകാര്യത മാനദണ്ഡങ്ങൾ (Acceptance criteria)
- പരിശോധനാ ഘട്ടങ്ങൾ (Verification steps)
അവ വെറുതെ വായിക്കാൻ വേണ്ടി മാത്രമല്ല, നടപ്പിലാക്കാൻ വേണ്ടി നിർമ്മിച്ചവയാണ്. മനുഷ്യനായാലും AI ഏജന്റായാലും, അടുത്തതായി ജോലി ഏറ്റെടുക്കുന്ന ആളാണ് അവയുടെ ഉപഭോക്താവ്.
ആധുനിക എഞ്ചിനീയറിംഗ് എന്നത് പരിമിതികളെ നിയന്ത്രിക്കുന്ന (constraint management) ഒരു പ്രശ്നമാണ്. പരിമിതികൾ വ്യക്തമായി രേഖപ്പെടുത്തിയാൽ AI അവയുമായി നന്നായി പ്രവർത്തിക്കും. എന്റെ പ്രവർത്തനരീതി (workflow) ഈ ഘട്ടങ്ങളിലൂടെയാണ് കടന്നുപോകുന്നത്: Intent → AI Specification → Human Review → AI Implementation Plan → Human Review → AI Code Generation → Testing
ഞാൻ ലക്ഷ്യവും ആവശ്യകതകളും അതിർവരമ്പുകളും നൽകുന്നു. AI സ്പെസിഫിക്കേഷൻ തയ്യാറാക്കുന്നു. ഞാൻ അത് പരിശോധിക്കുന്നു. AI പ്ലാൻ തയ്യാറാക്കുന്നു. ഞാൻ അത് പരിശോധിക്കുന്നു. അതിനുശേഷം മാത്രമേ നമ്മൾ കോഡ് നിർമ്മിക്കുന്നുള്ളൂ.
ഞാൻ കുറച്ച് എഴുതുന്നു, പക്ഷേ കൂടുതൽ ശ്രദ്ധയോടെ പരിശോധിക്കുന്നു. എഞ്ചിനീയറിംഗ് മൂല്യം നിലനിൽക്കുന്നത് ഇവിടെയാണ്.
ഒരു നല്ല സ്പെസിഫിക്കേഷൻ എന്തായിരിക്കണം എന്ന് നിർവചിക്കുന്നു, അല്ലാതെ അത് എങ്ങനെ ചെയ്യണം എന്ന് പറയുന്നില്ല. ഉദാഹരണത്തിന്, ഒരു റീഫാക്റ്ററിംഗ് (refactoring) സ്പെസിഫിക്കേഷൻ ഇപ്രകാരം പറയണം:
- ആപ്ലിക്കേഷൻ ലെയറിലെ ഒരു ക്ലാസ്സും DAO ഇംപ്ലിമെന്റേഷനുകളെ റഫർ ചെയ്യാൻ പാടില്ല.
- സ്വീകാര്യത മാനദണ്ഡം (Acceptance criteria): ലെയറിംഗ് ലംഘനങ്ങൾ (layering violations) സെർച്ച് ചെയ്യുമ്പോൾ പൂജ്യം ഫലങ്ങൾ (zero matches) നൽകണം.
ഏറ്റവും പ്രധാനപ്പെട്ട ജോലി 'ലോഡ് ബെയറിംഗ് കൺസ്ട്രയിന്റുകൾ' (load-bearing constraints) തിരിച്ചറിയുക എന്നതാണ്. ഇവ താഴെ പറയുന്ന നിർണ്ണായക നിയമങ്ങളാണ്:
- ഡാറ്റാബേസ് ഇനിഷ്യലൈസേഷൻ തന്ത്രങ്ങൾ (Database initialization strategies)
- ഡിപ്ലോയ്മെന്റ് മോഡലുകൾ (Deployment models)
- ഇന്റഗ്രേഷൻ അതിർവരമ്പുകൾ (Integration boundaries)
ഇവ ശ്രദ്ധിച്ചില്ലെങ്കിൽ സിസ്റ്റം തകരാറിലാകും.
AI സെഷനുകൾ താൽക്കാലികമാണ്. അവ വരികയും പോവുകയും ചെയ്യുന്നു. യഥാർത്ഥ മൂല്യം വരുന്നത് പങ്കിട്ട മെമ്മറിയിൽ (shared memory) നിന്നാണ്:
- സ്പെസിഫിക്കേഷനുകൾ (Specifications)
- ഇംപ്ലിമെന്റേഷൻ പ്ലാനുകൾ (Implementation plans)
- ആർക്കിടെക്ചർ ഡിസിഷൻ റെക്കോർഡുകൾ (ADRs)
- കൺവെൻഷനുകൾ (Conventions)
ഈ മെമ്മറി ഡോക്യുമെന്റേഷൻ വ്യതിയാനങ്ങളെ (documentation drift) തടയുന്നു. നിങ്ങളുടെ README, കോഡ്, ADR എന്നിവ വ്യത്യസ്ത കാര്യങ്ങളാണ് പറയുന്നത് എങ്കിൽ വിശ്വാസം നഷ്ടപ്പെടും. അവ യാഥാർത്ഥ്യവുമായി പൊരുത്തപ്പെടണം.
റെപ്പോസിറ്ററി ഈ ഘടന പിന്തുടരണം:
- CLAUDE.md: വർക്ക്ഫ്ലോയും റിവ്യൂ ഗേറ്റുകളും.
- status.md: എല്ലാ സ്പെക്കുകളും പ്ലാനുകളും അടങ്ങിയ ഒരു സജീവമായ ഇൻഡക്സ്.
- specs/: "എന്താണ്", "എന്തുകൊണ്ട്" എന്നിവ.
- plan/: "എങ്ങനെ".
- rules/: ക്ലാസ്-ലെവൽ കോഡിംഗ് കൺവെൻഷനുകൾ.
- docs/adr/: പ്രധാനപ്പെട്ട തീരുമാനങ്ങളുടെ മാറ്റമില്ലാത്ത രേഖകൾ.
AI-ക്ക് കോഡ് നിർമ്മിക്കാൻ കഴിയും. നിങ്ങളുടെ ബിസിനസ്സിന് ഏത് നിയന്ത്രണങ്ങളാണ് പ്രസക്തമെന്ന് വിശ്വസനീയമായി നിർണ്ണയിക്കാൻ അതിന് കഴിയില്ല. അത് നിങ്ങളുടെ ഉത്തരവാദിത്തമാണ്.
പ്രവർത്തിപ്പിക്കാൻ കഴിയുന്ന അറിവ് നിർമ്മിക്കുക. ഓരോ പ്രോജക്റ്റും ഒരു ശൂന്യമായ പേജിലല്ല, മറിച്ച് പങ്കിട്ട മെമ്മറിയോടെ ആരംഭിക്കുക.
സ്രോതസ്സ്: https://dev.to/daniel_wu_cac679a2760ba0a/the-code-is-cheap-artifact-now-the-spec-is-the-asset-3b02
ഓപ്ഷണൽ ലേണിംഗ് കമ്മ്യൂണിറ്റി: https://t.me/GyaanSetuAi