எங்கள் codebase-இல் AI தவறான தகவல்களை உருவாக்குவதை நான் எப்படித் தடுத்தேன்
AI கோடிங் கருவிகள் உண்மையான production திட்டங்களில் தோல்வியடைகின்றன. அவை புதிய குறியீடுகளில் (new code) நன்றாகச் செயல்படுகின்றன. ஆனால் வரலாறு கொண்ட பழைய குறியீடுகளில் அவை செயலிழந்துவிடுகின்றன.
எங்களது fintech திட்டத்திற்கு மூன்று வருட வரலாறு உள்ளது. இதில் இரண்டு React frontends, ஒரு admin panel மற்றும் ஒரு FastAPI backend உள்ளன. தரவுத்தளம் (database) பல அட்டவணைகள் (tables) மற்றும் சிக்கலான இணைப்புகளைக் (heavy joins) கொண்ட ஒரு சிக்கலான அமைப்பாகும்.
வேகமான முன்னேற்றத்திற்காக நாங்கள் AI-ஐப் பயன்படுத்த முயன்றோம். அது தோல்வியடைந்தது.
ஒரு contacts அட்டவணையை உருவாக்க நான் AI-இடம் கேட்டேன். அது பெயர்கள் மற்றும் மின்னஞ்சல்களுக்காகப் புதிய நெடுவரிசைகளை (columns) உருவாக்கியது. ஏற்கனவே எங்களது users அட்டவணையில் இவை இருப்பதை அது உணரவில்லை. ஒரு foreign key-ஐப் பயன்படுத்துவதற்குப் பதிலாக, அது தரவை நகலெடுத்தது (duplicated data).
AI முட்டாள்தனமாகச் செயல்படவில்லை. அதற்குத் தேவையான சூழல் (context) இல்லை. முழுமையற்ற தகவல்களுடன் அது ஒரு முடிவை எடுத்தது.
சிறந்த குறியீட்டை எப்படிப் பெறுவது என்று கேட்பதை நான் நிறுத்தினேன். சரியான முடிவுகளை எடுக்க AI-க்கு என்ன சூழல் தேவை என்று கேட்கத் தொடங்கினேன்.
நாங்கள் ஒரு கட்டமைக்கப்பட்ட பணிப்பாய்வை (structured workflow) உருவாக்கினோம். நீங்கள் வழங்கும் சூழலைப் பொறுத்தே AI-ன் தரம் அமையும். அந்தச் சூழலை நாங்கள் தெளிவாகக் குறிப்பிட்டோம்.
எங்களது அமைப்பு இதோ:
- ADR Directory: Architecture Decision Records-க்காக நாங்கள் ஒரு கோப்புறையை (folder) உருவாக்கினோம். இந்தத் கோப்புகள் நாங்கள் ஏன் குறிப்பிட்ட முடிவுகளை எடுக்கிறோம் என்பதை விளக்குகின்றன. புதிய அட்டவணைகளை உருவாக்குவதற்கு முன், ஏற்கனவே உள்ள அட்டவணைகளைச் சரிபார்க்குமாறு ஒரு கோப்பு AI-இடம் கூறுகிறது. பயனர் தரவை நகலெடுப்பதைத் இது தடை செய்கிறது.
- context.md: இந்தத் கோப்பு எங்களது குறிப்பிட்ட கலைச்சொற்களை விளக்குகிறது. எங்களது தனித்துவமான சொற்கள் ஒன்றுடன் ஒன்று எவ்வாறு தொடர்பு கொள்கின்றன என்பதை இது AI-இடம் கூறுகிறது.
- plot.md: இது திட்டத்தின் உயர்நிலை வரைபடத்தையும் (high-level map), அதன் பாகங்கள் எவ்வாறு இணைக்கப்பட்டுள்ளன என்பதையும் வழங்குகிறது.
- Mandatory Tests: ஒவ்வொரு புதிய API ரூட்டிற்கும் (route) சோதனை வழக்குகள் (test cases) அவசியமாகும்.
இது அனைத்தையும் மாற்றியமைத்தது. ஒருமுறை, AI ஒரு பொதுவான utility function-ஐ மாற்றியது. அந்த மாற்றம் அமைப்பின் மற்ற எட்டு பகுதிகளைச் சிதைத்தது. சோதனைத் தொகுப்பு (test suite) அதை உடனடியாகக் கண்டறிந்தது. AI அந்தத் தோல்வியைக் கண்டு, பழைய மற்றும் புதிய தேவைகள் இரண்டையும் கையாளும் ஒரு பதிப்பை உருவாக்குவதன் மூலம் தனது தவறைத் தானே சரிசெய்தது.
சோதனைகள் இல்லையென்றால், அந்தப் பிழை (bug) production நிலையை அடைந்திருக்கும்.
AI-ஐ ஒரு புதிய டெவலப்பரைப் போலக் கருதுங்கள். உங்கள் codebase தெரியாததற்காக நீங்கள் ஒரு புதிய பணியாளரைத்탓ிக்க மாட்டீர்கள். நீங்கள் ஆவணங்களையும் (documentation) அறிமுகப் பயிற்சியையும் (onboarding) வழங்குவீர்கள். நாங்கள் AI-க்கும் அதையே செய்தோம்.
எங்களது கட்டமைப்பு:
docs/context.md: திட்டத்தின் கலைச்சொற்கள் மற்றும் தொடர்புகள்.docs/plot.md: உயர்நிலை codebase வரைபடம்.docs/adr/: அட்டவணை உருவாக்கம் மற்றும் API கட்டமைப்பு போன்ற குறிப்பிட்ட விதிகள்.
உங்கள் குழுவிற்கான மூன்று விதிகள்:
- ADR-களில் துல்லியமாக இருங்கள். தெளிவற்ற ஆலோசனைகளுக்குப் பதிலாகத் தெளிவான வழிமுறைகளைப் பயன்படுத்துங்கள்.
- ஆவணங்களை அதிகாரப்பூர்வமானதாக ஆக்குங்கள். இந்த விதிகள் தான் முதன்மையானவை என்று AI-இடம் கூறுங்கள்.
- தவறுகளை விதிகளாக மாற்றவும். ஒவ்வொரு முறை AI தோல்வியடையும் போதும், ஒரு புதிய ADR-ஐ எழுதுங்கள்.
இந்த அமைப்பு AI-ஐத் துல்லியமாக்காது. ஆனால் AI-ஐக் கணிக்கக்கூடியதாக (predictable) மாற்றும். AI சீராகச் செயல்படும் ஒரு codebase-ஐ நாங்கள் விரும்புகிறோம், அப்போதுதான் குழு விரைவாகச் செயல்படும்.