கடந்த மாதம், ஒரு AI உதவியாளர் ஒரு தயாரிப்புத் திட்டத்திற்காக (production project) ஒரு Python ஸ்கிரிப்டை உருவாக்கியது. அதன் வெளியீடு பிழையின்றி இயங்கியது. தரவுகள் சரியாகத் தெரிந்தன. ஆனால், ஒரு கைமுறை ஆய்வின் போது, தரவுத்தள அழைப்புகளில் (database calls) மறைந்திருந்த ஒரு N+1 query pattern கண்டறியப்பட்டது. சிறிய அளவிலான தரவுகளுக்கு, அந்த குறியீடு நன்றாகச் செயல்பட்டது. ஆனால் ஆயிரக்கணக்கான பதிவுகளாக அதை உயர்த்தும்போது, அந்தச் செயலி முதன்மைப் பொருட்களுக்காக (parent objects) ஒரு வினவலையும் (query), தொடர்புடைய தரவுகளுக்காக ஆயிரக்கணக்கான தொடர் வினவல்களையும் வெளியிடும். இதன் விளைவாக, எந்த ஒரு unit test-ஆலும் கண்டறிய முடியாத ஒரு மிகப்பெரிய செயல்திறன் வீழ்ச்சி (performance cliff) ஏற்படும்.
இதுவே நவீன மென்பொருள் மேம்பாட்டின் யதார்த்தம். AI கருவிகள் இப்போது மனிதர்களால் ஈடுசெய்ய முடியாத வேகத்தில் கோடிங், டீபக்கிங் (debugging) மற்றும் கட்டமைப்பு ஆலோசனைகளை (architectural suggestions) வழங்குகின்றன. அந்த வேகம் உண்மையானதுதான். இருப்பினும், அது உங்கள் வேலையின் தன்மையையே அடிப்படை ரீதியாக மாற்றுகிறது. நீங்கள் வெறும் தொடர்களை (syntax) தட்டச்சு செய்வதற்காக மட்டும் ஊதியம் பெறவில்லை. நீங்கள் தணிக்கை செய்யவும் (audit), கட்டமைப்பை வடிவமைக்கவும் (architect), மற்றும் இத்தகைய கண்ணுக்குத் தெரியாத பொறிகளைத் துல்லியமாகக் கண்டறியவும் ஊதியம் பெறுகிறீர்கள்.
"தர்க்கரீதியாகத் தோன்றும் ஆனால் தவறான" என்பதன் அமைதியான ஆபத்து
AI மூலம் உருவாக்கப்பட்ட குறியீடு பெரும்பாலும் சரியாகத் தோன்றும், ஏனெனில் அது இயங்கும் (compiles), செயல்படும் (runs) மற்றும் எதிர்பார்க்கப்படும் மதிப்பைத் தரும். மேலோட்டமாகப் பார்க்கும்போது அதன் தர்க்கம் (logic) சரியாகத் தெரியும். ஆனால் ஆழமாகப் பார்த்தால், அது அமைதியாகச் சிதைந்திருக்கக்கூடும்.
Regular expressions-ஐ எடுத்துக்கொள்வோம். ஒரு AI உங்களுக்கு ஆங்கிலத்தில் மின்னஞ்சல் முகவரிகள் அல்லது அடையாளங்களைச் சரியாகப் பொருந்தக்கூடிய ஒரு முறையை (pattern) வழங்கலாம். அதே முறையை ஜெர்மன் umlauts, அரபு எழுத்துக்கள் அல்லது Unicode normalization போன்ற சிக்கலான நிலைகளில் பயன்படுத்தும்போது, அது அமைதியாகத் தோல்வியடையும். அந்த குறியீடு ஒரு exception-ஐத் தூண்டும் வகையில் தவறானது அல்ல; அது உண்மையான உலகத் தரவுகளைத் தகுதியற்றதாகத் தவிர்த்துவிடுகிறது.
தரவுத்தள வினவல்களும் (Database queries) இதே போன்ற ஆபத்தைக் கொண்டுள்ளன. ஒரு AI, சோதனைப் பதிவின் போது சரியான வரிசைகளைத் தரும் ஒரு PostgreSQL வினவலை எழுதலாம், ஆனால் அது உங்கள் அட்டவணைகளில் தேவையற்ற தரவுகளை (dead tuples) நிரப்பலாம், index பயன்பாட்டைத் தவிர்க்கலாம் அல்லது தயாரிப்புப் பணிகளை முடக்கும் sequential scans-களைத் தூண்டலாம். ஒரு டெமோ தரவுத்தொகுப்பில் (demo dataset) வேலை செய்வது மற்றும் உண்மையான சுமையின் கீழ் (real load) வேலை செய்வது ஆகிய இரண்டும் வெவ்வேறானவை. இயந்திரத்திற்கு தாமதத்தை (latency) உணர முடியாது. அது கிளவுட் கட்டணத்தைச் செலுத்த வேண்டிய அவசியமும் இல்லை.
எழுதுவதிலிருந்து சரிபார்ப்பது வரை
முக்கியமான மாற்றம் என்பது "இதை எப்படி எழுதுவது?" என்பதிலிருந்து "இதை எப்படி சரிபார்ப்பது?" என்பதற்கு மாறுவதாகும். AI முதல் வரைவை (first draft) உருவாக்கும்போது, உங்கள் அறிவுசார் கவனம் (cognitive load) அடுத்த கட்டத்திற்கு நகர வேண்டும். ஒரு சோர்வடைந்த ஆசிரியர் தனது வேலையைத் திருப்புப் பார்ப்பது போல அல்லாமல், ஒரு பாதுகாப்புத் தணிக்கையாளர் (security auditor) குறியீட்டைப் படிப்பது போல நீங்கள் படிக்க வேண்டும்.
இதற்கு ஒரு மாறுபட்ட ஒழுக்கம் தேவைப்படுகிறது. Automation bias என்பது நிஜமான ஒன்று. ஒரு கருவி சரளமாகவும், இலக்கண ரீதியாகச் சரியானதாகவும் (syntactically perfect) வெளியீட்டைத் தரும்போது, மனித மூளைத் தளர்வடைந்துவிடுகிறது. அதன் வடிவம் நேர்த்தியாக இருப்பதால், அது சரியானது என்று நீங்கள் assumptions செய்துவிடுகிறீர்கள். அந்தத் தூண்டுதலைத் தடுப்பதே இப்போது மிக முக்கியமான திறமையாகும். ஒரு பரிந்துரை நிரூபிக்கப்படும் வரை, அது ஒரு கருதுகோள் (hypothesis) மட்டுமே என்று நீங்கள் கருத வேண்டும்.
இயந்திரத்துடன் இணைந்து பணியாற்றுதல்
ஒரு AI கோடிங் உதவியாளரிடமிருந்து பயனுள்ள வெளியீட்டைப் பெறுவது என்பது வேகமாகத் தட்டச்சு செய்வதைப் பற்றியது அல்ல. அது இயந்திரத்தின் பயிற்சித் தரவிற்கும் (training data) உங்கள் குறிப்பிட்ட யதார்த்தத்திற்கும் இடையிலான இடைவெளியைக் குறைப்பதைப் பற்றியது. சில நடைமுறை முறைகள் மூலம் அந்த இடைவெளியைக் குறைக்கலாம்.
உங்கள் prompts-களில் துல்லியமாக இருங்கள். இங்கே தெளிவற்ற தன்மை கவிதையை உருவாக்காது; அது பிழைகளை (bugs) உருவாக்கும். "இந்த function-ஐ மேம்படுத்துங்கள்" (optimize this function) போன்ற ஒரு prompt பொதுவான ஆலோசனைகளையே தரும். அதற்குப் பதிலாக, "தனித்தனியாகச் சேமிப்பதற்குப் பதிலாக (iterated saves), ஒரே நேரத்தில் பல தரவுகளைப் புதுப்பிக்கும் (single bulk database update) வகையில் இந்த Python loop-ஐ மாற்றியமைக்கவும் (refactor)" என்று எழுதுங்கள். துல்லியம் சாத்தியக்கூறுகளின் பரப்பளவைக் குறைக்கிறது.
உண்மையான சூழலை (context) வழங்கவும். நீங்கள் ஒரு Kubernetes cluster-க்குள், 30 வினாடி கோரிக்கை காலக்கெடுவுடன் (request timeout), PostgreSQL 15 மற்றும் Django 4.2-ஐப் பயன்படுத்துகிறீர்கள் என்பதை நீங்கள் கூறாவிட்டால், AI அதை அறியாது. உங்கள் dependency பதிப்புகள், உங்கள் உள் நூலகங்கள் (internal libraries) மற்றும் நீங்கள் மாற்ற முடியாத கட்டுப்பாடுகளை (non-negotiable constraints) அதற்கு வழங்கவும். சூழல் என்பது வெறும் அலங்காரம் அல்ல; அது ஒரு பாதுகாப்பு வேலையாகும் (guardrails).
உங்கள் சொந்த ஆவணங்களைக் கொண்டு பதில்களை உறுதிப்படுத்தவும். Retrieval-Augmented Generation அல்லது RAG என்பது வெறும் சாட்பாட்களுக்கான (chatbots) சொல் மட்டுமல்ல. உங்கள் உண்மையான API விவரக்குறிப்புகள் (specifications), உங்கள் கட்டமைப்பு முடிவுப் பதிவுகள் (architecture decision records) மற்றும் உங்கள் codebase மரபுகளை (conventions) உங்கள் உதவியாளரிடம் ஒப்படைக்கவும். மாதிரி (model) பயிற்சித் தரவிலிருந்து யூகிக்காமல், உங்கள் ஆவணங்களிலிருந்து உண்மைகளைப் பெறும்போது, பொதுவான ஆலோசனைகளுக்கும் பயன்படும் குறியீட்டிற்கும் இடையிலான இடைவெளி வியக்கத்தக்க வகையில் குறைகிறது.
சிக்கலான வேலைகளைத் தனித்தனிப் பணிகளாகப் பிரிக்கவும். ஒவ்வொரு படிநிலையும் குறுகிய எல்லைகளைக் கொண்டிருக்கும்போது Agent patterns சிறப்பாகச் செயல்படும். ஒரே நேரத்தில் ஒரு முழுமையான microservice refactor-ஐக் கேட்காதீர்கள். முதலில் தரவுத் திட்டத்தை (data schema) கேளுங்கள். அதைச் சரிபார்க்கவும். பிறகு migration script-ஐக் கேளுங்கள். அதையும் சரிபார்க்கவும். அதன் பிறகு service layer-க்குச் செல்லவும்.