ഞങ്ങളുടെ കോഡ്ബേസിൽ AI തെറ്റായ വിവരങ്ങൾ നൽകുന്നത് (Hallucinating) ഞാൻ എങ്ങനെ തടഞ്ഞു
യഥാർത്ഥ പ്രൊഡക്ഷൻ പ്രോജക്റ്റുകളിൽ AI കോഡിംഗ് ടൂളുകൾ പരാജയപ്പെടുന്നു. പുതിയ കോഡുകളിൽ അവ നന്നായി പ്രവർത്തിക്കും. എന്നാൽ ചരിത്രമുള്ള (history ഉള്ള) പഴയ കോഡുകളിൽ അവ തകരാറിലാകുന്നു.
ഞങ്ങളുടെ ഫിൻടെക് (fintech) പ്രോജക്റ്റിന് മൂന്ന് വർഷത്തെ ചരിത്രമുണ്ട്. ഇതിൽ രണ്ട് React ഫ്രണ്ട്എൻഡുകളും, ഒരു അഡ്മിൻ പാനലും, ഒരു FastAPI ബാക്കെൻഡും ഉണ്ട്. ഡാറ്റാബേസ് നിരവധി ടേബിളുകളും ഹെവി ജോയിനുകളും (heavy joins) ഉള്ള സങ്കീർണ്ണമായ ഒന്നാണ്.
വേഗത്തിൽ മുന്നേറാൻ ഞങ്ങൾ AI ഉപയോഗിക്കാൻ ശ്രമിച്ചു. അത് പരാജയപ്പെട്ടു.
ഒരു കോൺടാക്ട്സ് (contacts) ടേബിൾ നിർമ്മിക്കാൻ ഞാൻ AI-യോട് ആവശ്യപ്പെട്ടു. അത് പേരിനും ഇമെയിലിനും പുതിയ കോളങ്ങൾ നിർമ്മിച്ചു. ഞങ്ങളുടെ യൂസേഴ്സ് (users) ടേബിളിൽ ഇവ നേരത്തെ തന്നെ ഉണ്ടെന്ന് അത് തിരിച്ചറിഞ്ഞില്ല. ഒരു ഫോറിൻ കീ (foreign key) ഉപയോഗിക്കുന്നതിന് പകരം അത് ഡാറ്റ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്തു.
AI വിഡ്ഢിയായിരുന്നില്ല. അതിന് ആവശ്യമായ കോൺടെക്സ്റ്റ് (context) ലഭ്യമല്ലായിരുന്നു. അപൂർണ്ണമായ വിവരങ്ങൾ വെച്ച് അത് ഒരു തീരുമാനമെടുത്തു.
മികച്ച കോഡ് എങ്ങനെ ലഭിക്കും എന്ന് ചോദിക്കുന്നത് ഞാൻ നിർത്തി. നല്ല തീരുമാനങ്ങൾ എടുക്കാൻ AI-ക്ക് എന്തൊക്കെ കോൺടെക്സ്റ്റ് ആവശ്യമാണെന്ന് ചോദിക്കാൻ ഞാൻ തുടങ്ങി.
ഞങ്ങൾ ഒരു ഘടനാപരമായ വർക്ക്ഫ്ലോ (structured workflow) നിർമ്മിച്ചു. നിങ്ങൾ നൽകുന്ന കോൺടെക്സ്റ്റ് എത്രത്തോളമുണ്ടോ അത്രത്തോളം മാത്രമേ AI-ക്കും കഴിവുണ്ടാകൂ. ഞങ്ങൾ ആ കോൺടെക്സ്റ്റ് വ്യക്തമാക്കിക്കൊടുത്തു.
ഞങ്ങളുടെ സെറ്റപ്പ് ഇതാ:
- ADR ഡയറക്ടറി: ഞങ്ങൾ ആർക്കിടെക്ചർ ഡിസിഷൻ റെക്കോർഡുകൾക്കായി (Architecture Decision Records) ഒരു ഫോൾഡർ നിർമ്മിച്ചു. ഞങ്ങൾ എന്തുകൊണ്ടാണ് പ്രത്യേക തീരുമാനങ്ങൾ എടുക്കുന്നത് എന്ന് ഈ ഫയലുകൾ വിശദീകരിക്കുന്നു. പുതിയവ നിർമ്മിക്കുന്നതിന് മുമ്പ് നിലവിലുള്ള ടേബിളുകൾ പരിശോധിക്കാൻ ഒരു ഫയൽ AI-യോട് ആവശ്യപ്പെടുന്നു. യൂസർ ഡാറ്റ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യുന്നത് ഇത് വിലക്കുന്നു.
- context.md: ഞങ്ങളുടെ പ്രത്യേക പദങ്ങൾ ഈ ഫയൽ വിശദീകരിക്കുന്നു. ഞങ്ങളുടെ സവിശേഷമായ വാക്കുകൾ പരസ്പരം എങ്ങനെ ബന്ധപ്പെട്ടിരിക്കുന്നു എന്ന് ഇത് AI-യോട് പറയുന്നു.
- plot.md: പ്രോജക്റ്റിന്റെ ഒരു ഹൈ-ലെവൽ മാപ്പും അതിന്റെ ഭാഗങ്ങൾ എങ്ങനെ ബന്ധപ്പെട്ടിരിക്കുന്നു എന്നും ഇത് നൽകുന്നു.
- നിർബന്ധിത ടെസ്റ്റുകൾ (Mandatory Tests): ഓരോ പുതിയ API റൂട്ടും ടെസ്റ്റ് കേസുകൾ ആവശ്യപ്പെടുന്നു.
ഇത് എല്ലാം മാറ്റിമറിച്ചു. ഒരിക്കൽ, AI ഒരു ഷെയർഡ് യൂട്ടിലിറ്റി ഫംഗ്ഷനിൽ (shared utility function) മാറ്റം വരുത്തി. ആ മാറ്റം സിസ്റ്റത്തിന്റെ മറ്റ് എട്ട് ഭാഗങ്ങളെയും തകരാറിലാക്കി. ടെസ്റ്റ് സ്യൂട്ട് (test suite) അത് ഉടൻ തന്നെ കണ്ടെത്തി. AI ആ പരാജയം മനസ്സിലാക്കുകയും പഴയതും പുതിയതുമായ ആവശ്യകതകൾ കൈകാര്യം ചെയ്യുന്ന ഒരു വേർഷൻ നിർമ്മിച്ചുകൊണ്ട് സ്വന്തം തെറ്റ് തിരുത്തുകയും ചെയ്തു.
ടെസ്റ്റുകൾ ഇല്ലായിരുന്നെങ്കിൽ, ആ ബഗ് പ്രൊഡക്ഷനിൽ എത്തുമായിരുന്നു.
AI-യെ ഒരു പുതിയ ഡെവലപ്പറെപ്പോലെ കാണുക. നിങ്ങളുടെ കോഡ്ബേസിനെക്കുറിച്ച് അറിയാത്തതിന് നിങ്ങൾ ഒരു പുതിയ ജീവനക്കാരനെ കുറ്റപ്പെടുത്താറില്ല. പകരം നിങ്ങൾ ഡോക്യുമെന്റേഷനും ഓൺബോർഡിംഗും (onboarding) നൽകുന്നു. ഞങ്ങൾ AI-ക്കും അതുതന്നെയാണ് ചെയ്തത്.
ഞങ്ങളുടെ ഘടന:
- docs/context.md: പ്രോജക്റ്റ് പദങ്ങളും ബന്ധങ്ങളും.
- docs/plot.md: ഹൈ-ലെവൽ കോഡ്ബേസ് മാപ്പ്.
- docs/adr/: ടേബിൾ നിർമ്മാണം, API ഘടന തുടങ്ങിയ പ്രത്യേക നിയമങ്ങൾ.
നിങ്ങളുടെ ടീമിനായി മൂന്ന് നിയമങ്ങൾ:
- ADR-കളിൽ കൃത്യത പാലിക്കുക. അവ്യക്തമായ ഉപദേശങ്ങൾക്ക് പകരം വ്യക്തമായ നിർദ്ദേശങ്ങൾ ഉപയോഗിക്കുക.
- ഡോക്യുമെന്റേഷനുകൾക്ക് പ്രാധാന്യം നൽകുക. ഈ നിയമങ്ങൾക്കാണ് മുൻഗണന എന്ന് AI-യോട് പറയുക.
- തെറ്റുകളെ നിയമങ്ങളാക്കി മാറ്റുക. ഓരോ തവണ AI പരാജയപ്പെടുമ്പോഴും ഒരു പുതിയ ADR എഴുതുക.
ഈ സിസ്റ്റം AI-യെ പൂർണ്ണമാക്കുന്നില്ല. ഇത് AI-യെ പ്രവചിക്കാവുന്നതാക്കുന്നു (predictable). ടീമിന് വേഗത്തിൽ മുന്നേറാൻ കഴിയുന്ന രീതിയിൽ AI സ്ഥിരതയുള്ള (consistent) ഒരു കോഡ്ബേസ് ആണ് ഞങ്ങൾ ആഗ്രഹിക്കുന്നത്.