பல ஆண்டுகளாக, செயற்கை நுண்ணறிவு (AI) எடிட்டரில் உங்களுக்கு அருகிலேயே அமர்ந்து, அடுத்து என்ன வரும் என்று ஊகித்தது. நீங்கள் ஒரு வரியை எழுதினால், அது அடுத்த வரியைப் பரிந்துரைத்தது. ஆனால் அதன் கட்டமைப்பு (architecture), பிழைத்திருத்தம் (debugging) மற்றும் தொடரியல் (syntax) ஆகியவற்றிற்கு நீங்களே பொறுப்பாவீர்கள். அந்த நிலை முடிவுக்கு வந்துவிட்டது.
நாம் நோக்கத்தால் இயக்கப்படும் மேம்பாட்டிற்கு (Intent-Driven Development) மாறி வருகிறோம். நீங்கள் இனி லூப்கள் (loops) மற்றும் நிபந்தனைகளை (conditionals) தட்டச்சு செய்யத் தேவையில்லை. அதற்குப் பதிலாக, உங்களுக்குத் தேவையான முடிவை விவரிக்க வேண்டும். ஒரு ஏஜென்ட் (agent) அந்த இலக்கை உள்வாங்கிக்கொண்டு, படிகளைத் திட்டமிட்டு, குறியீட்டை எழுதி, சோதனைகளை நடத்தி, நீங்கள் முடிவைப் பார்ப்பதற்கு முன்பே அதன் பிழைகளைத் தானே சரிசெய்துவிடும். விசைப்பலகை (keyboard) இனி முதன்மை கருவி அல்ல; தெளிவான சிந்தனைதான் முதன்மையானது.
வரி வரியாகக் குறியீடு எழுதுவதன் முடிவு
பழைய பணிப்பாய்வு (workflow), உங்கள் ஒவ்வொரு எண்ணத்தையும் ஒரு கம்பைலரால் (compiler) புரிந்துகொள்ளக்கூடிய ஒரு குறிப்பிட்ட மொழியாக மாற்ற உங்களைக் கட்டாயப்படுத்தியது. வணிகத் தேவையை உங்கள் மனதில் வைத்துக்கொண்டு, அதைத் தனித்தனி செயல்பாடுகள் (functions), இறக்குமதிகள் (imports), பிழை கையாளுதல் (error handling) மற்றும் சோதனை நிகழ்வுகளாக (test cases) நீங்கள் கைமுறையாகப் பிரித்தீர்கள். Intent-Driven Development அந்த மொழிபெயர்ப்பு அடுக்கைக் குறைத்துவிடுகிறது.
உதாரணமாக, நீங்கள் ஒரு பேமெண்ட் வெப்ஹூக்கை (payment webhook) ஒருங்கிணைக்க வேண்டும் என்று வைத்துக்கொள்வோம். முன்பு, நீங்கள் ரூட் ஹேண்ட்லரை (route handler) எழுதி, பேலோடை (payload) பகுப்பாய்வு செய்து, கையொப்பத்தை (signature) சரிபார்த்து, ஒரு டிரான்சாக்ஷனுக்குள் (transaction) தரவுத்தளத்தைப் புதுப்பித்து, ரசீது மின்னஞ்சலை வரிசையில் (queue) சேர்க்க வேண்டும். இப்போது நீங்கள் தேவையை மட்டும் விவரிக்கலாம்: “வரவிருக்கும் Stripe வெப்ஹூக்கைச் சரிபார்க்கவும், நிகழ்வை idempotently முறையில் பதிவு செய்யவும், மற்றும் ரசீது ஓட்டத்தைத் தொடங்கவும். தரவுத்தளப் பதிவு தோல்வியடைந்தால், அதைத் திரும்பப் பெறவும் (Roll back).” ஏஜென்ட் ஹேண்ட்லரை எழுதும், பகுப்பாய்வு முறையைத் தேர்ந்தெடுக்கும், மறுமுயற்சி தர்க்கத்தை (retry logic) கட்டமைக்கும் மற்றும் சோதனைகளை உருவாக்கும். உங்கள் பங்கு ஒரு எழுத்தாளரிடமிருந்து இயக்குநராக (director) மாறுகிறது.
ஏஜென்ட் வெறும் குறியீட்டை உருவாக்குவதோடு நின்றுவிடாமல், ஒரு சுழற்சிக்குள் (loop) செயல்படுவதால் மட்டுமே இது சாத்தியமாகிறது.
ஏஜென்ட் சுழற்சிக்குள்
முக்கிய வேலை இனி மனிதர்கள் தட்டச்சு செய்வதோ அல்லது கைமுறையாக பிழைதிருத்தம் செய்வதோ அல்ல. அது உருவாக்கம் (generation) மற்றும் சரிபார்ப்பு (validation) ஆகியவற்றிற்கு இடையிலான ஒரு நெருக்கமான சுழற்சி. ஏஜென்ட் குறியீட்டை உருவாக்குகிறது, அதை உங்கள் சோதனைத் தொகுப்பிற்கு (test suite) எதிராகச் செயல்படுத்துகிறது, வெளியீட்டைப் படிக்கிறது மற்றும் தோல்விகளைத் தானாகவே சரிசெய்கிறது. ஒரு விடுபட்ட இறக்குமதி (missing import), ஒரு வகை பொருந்தாமை (type mismatch), அல்லது தோல்வியடையும் அஸர்ஷன் (failing assertion) — ஏஜென்ட் ஸ்டாக் ட்ரேஸை (stack trace) பார்த்து, கோப்பைத் திருத்தி, மீண்டும் சோதனையை நடத்துகிறது. நீங்கள் அந்தச் சுழற்சிக்குள் இல்லை. அந்தச் சுழற்சி இயந்திரத்தின் வேகத்தில் இயங்குகிறது.
அந்தச் சுழற்சியே முறியடையும் போது நீங்கள் தலையிட வேண்டும். ஒருவேளை ஏஜென்ட் இரண்டு சார்புகளுக்கு (dependencies) இடையிலான முரண்பாட்டைத் தீர்க்க முடியாமல் போகலாம், அல்லது யூனிட் சோதனைகளில் (unit tests) தேர்ச்சி பெற்றாலும், உயர்நிலை வணிக விதியை மீறும் குறியீட்டைத் தொடர்ந்து உருவாக்கலாம். அந்த எல்லைகளில்தான் மனிதத் தீர்ப்பு இன்னும் முக்கியத்துவம் பெறுகிறது.
உங்கள் உண்மையான வேலை: கட்டுப்பாட்டமைப்பை வடிவமைப்பவர் மற்றும் விளிம்புநிலை நிகழ்வுகளைக் கண்டறிபவர்
இயந்திரம் செயல்பாடுகளை (functions) எழுதினால், உங்களுக்கு என்ன மிஞ்சியிருக்கிறது? இரண்டு விஷயங்கள் உள்ளன, அவை தட்டச்சு செய்வதை விடக் கடினமானவை.
முதலாவதாக, ஏஜென்ட் சரியான பாதையில் செல்ல உதவும் கட்டுப்பாடுகளை (constraints) நீங்கள் எழுத வேண்டும். ஏஜென்ட் பரந்த அறிவைக் கொண்டுள்ளது, ஆனால் உங்கள் குறிப்பிட்ட சூழலைப் பற்றிய புரிதல் அதற்கு இல்லை. நீங்கள் அதைத் தெரிவிக்க வேண்டும்: “உள்நாட்டு பில்லிங் API-ஐ (internal billing API) மட்டுமே பயன்படுத்தவும், ஒருபோதும் மூல கார்டு டோக்கன்களை (raw card tokens) லாக் செய்ய வேண்டாம், மற்றும் பதிலளிக்கும் தாமதத்தை (response latency) இருநூறு மில்லி விநாடிகளுக்குக் குறைவாக வைத்திருக்கவும்.” அந்த எல்லைகள் வெறும் தூக்கி எறியப்பட வேண்டிய தூண்டுதல்கள் (prompts) அல்ல. அவை வெற்றியையும் தோல்வியையும் தீர்மானிக்கும் விவரக்குறிப்புகள் (specifications) ஆகும்.
இரண்டாவதாக, ஏஜென்ட் தோல்வியடையும் அந்த பத்து சதவீத நிகழ்வுகளை நீங்கள் கண்டறிய வேண்டும். ஏஜென்ட்கள் பொதுவான பாதைகளைச் சிறப்பாகக் கையாளுகின்றன. ஆனால் நுணுக்கமான ரேஸ் கண்டிஷன்கள் (race conditions), தெளிவற்ற வணிகத் தர்க்க விளிம்புநிலைகள் (ambiguous business logic edge cases) மற்றும் அவற்றின் பயிற்சித் தரவில் (training data) உள்ள பாதுகாப்பு அனுமானங்கள் ஆகியவற்றில் அவை தடுமாறுகின்றன. வெப்ஹூக் ஹேண்ட்லருக்கும் ரீஃபண்ட் க்ரான் ஜாப்பிற்கும் (refund cron job) இடையிலான போட்டியைப் பார்ப்பது அல்லது உருவாக்கப்பட்ட மறுமுயற்சி தர்க்கம் (retry logic) கட்டணங்களை இரட்டிப்பாக்கக்கூடும் என்பதைக் கண்டறிவது ஆகியவற்றின் மூலம் உங்கள் திறமை வெளிப்படுகிறது. இயந்திரம் நிலையான சிக்கலைத் தீர்க்கிறது. நீங்கள் ஆபத்தான விதிவிலக்குகளைக் (dangerous exception) கண்டறிகிறீர்கள்.
குறியீடு ஆய்வுக்குப் பதிலாக சரிபார்ப்பு கட்டமைப்பைப் பயன்படுத்துங்கள்
ஒரு ஏஜென்ட் ஒரே இரவில் ஐம்பது கோப்புகளை உருவாக்க முடியும் போது, அவை “சரியாகத் தெரிகின்றனவா” என்று பார்ப்பதற்காக மட்டும் நீங்கள் அவற்றை ஆய்வு செய்ய முடியாது. அந்த அளவு மனிதர்களால் கண்களால் பார்த்துச் சரிபார்ப்பதைக் கடினமாக்குகிறது. குறியீடு உங்களிடம் வருவதற்கு முன்பே பிழைகளைக் கண்டறியும் ஒரு கட்டமைப்பு (harness) உங்களுக்குத் தேவை.
இந்த கட்டமைப்பு மூன்று தூண்களைக் கொண்டுள்ளது.
Durable execution. ஏஜென்ட் பணிகள் பெரும்பாலும் ஒரு ஒற்றை கோரிக்கையின் காலாவதி நேரத்தை விட (request timeout) நீடிக்கின்றன. தற்காலிக நெட்வொர்க் கோளாறு காரணமாக ஒரு படி தோல்வியடைந்தால், இந்தக் கட்டமைப்பு நிலையைச் சிதைக்காமல் (without corrupting state) தற்காலிகமாக நிறுத்தி, மீண்டும் முயற்சி செய்து, தொடரும். இடையூறுகளுக்கு இடையிலும் வேலை தொடரும்.
Structured outputs. ஏஜென்ட் ஒரு சரியான உள்ளமைவு கோப்பைத் (configuration file) தரும் என்று நம்புவதற்குப் பதிலாக, நீங்கள் முன்கூட்டியே ஒப்பந்தத்தை (contract) உறுதிப்படுத்துகிறீர்கள். JSON Schema போன்ற கருவிகள் வெளியீட்டை உடனடியாகச் சரிபார்க்கின்றன. ஏஜென்ட் ஒரு தேவையான புலத்தைத் (field) தவிர்த்தாலோ அல்லது தவறான தரவு வகையைப் பயன்படுத்தினாலோ, குறியீடு உங்கள் களஞ்சியத்தைத் (repository) தொடங்குவதற்கு முன்பே இந்தக் கட்டமைப்பு அதை நிராகரிக்கிறது.
Dynamic guardrails. ஏஜென்ட் ரகசியங்களை (secrets) படிக்கவோ அல்லது தயாரிப்பு தரவுத்தளங்களில் (production databases) எழுதவோ சுதந்திரமாக இருக்கக்கூடாது. இந்தக் கட்டமைப்பு அனுமதிகளை மாறும் வகையில் (dynamically) கட்டுப்படுத்துகிறது, ஏஜென்ட் குறிப்பிட்ட சோதனைத் தரவுத்தளங்கள் மற்றும் உள் முனையங்களை (internal endpoints) மட்டுமே தொடங்கும் வகையில் அதை ஒரு பாதுகாப்பான சூழலில் (sandboxing) வைக்கிறது. நீங்கள் ஒவ்வொரு வரியையும் ஆய்வு செய்யவில்லை. நீங்கள் ஏஜென்ட்டைச் சுற்றியுள்ள வேலியை ஆய்வு செய்கிறீர்கள்.
குறியீடு சரியாகச் செயல்பட்டாலும் தயாரிப்பு தோல்வியடையும் போது
இங்கே ஒரு முரண்பாடு உள்ளது. ஒரு சோதனைச் சட்டகம் (harness) தவறான குறியீட்டைக் கண்டறியும். ஆனால் தவறான நோக்கத்தைக் கண்டறிய முடியாது.
உங்கள் விவரக்குறிப்பு (specification), “ஒவ்வொரு புதிய பயனருக்கும் ஒரு வரவேற்பு மின்னஞ்சலை அனுப்பவும்” என்று கூறினால், அந்த மின்னஞ்சலை அனுப்பும் வகையில் சுத்தமான, சோதிக்கப்பட்ட குறியீட்டை ஏஜென்ட் (agent) எழுதும். ஆனால், “பயனர் தனது முகவரியை உறுதிப்படுத்தியிருந்தால், சந்தைப்படுத்தல் செய்திகளுக்குச் சம்மதித்திருந்தால் மற்றும் அவர்களின் உள்ளூர் நேர மண்டலத்தின் வணிக நேரங்களில் பதிவு செய்திருந்தால் மட்டுமே வரவேற்பு மின்னஞ்சலை அனுப்பவும்” என்று நீங்கள் சொல்லியிருக்கலாம் என்பதை அது அறியாது. அந்த குறியீடு தொழில்நுட்ப ரீதியாகத் குறையற்றதாக இருக்கலாம், ஆனால் வணிக ரீதியாக ஆபத்தானது.
நோக்க அடிப்படையிலான வளர்ச்சியில் (Intent-Driven Development) உண்மையான ஆபத்து என்பது தெளிவற்ற விவரக்குறிப்புதான். தெளிவற்ற நோக்கம், தவறான சிக்கலை மிக நேர்த்தியாகத் தீர்க்கும் மென்பொருளை உருவாக்கும். இதனால்தான் உங்கள் விவரக்குறிப்புகளை உண்மையான சொத்துக்களாக நீங்கள் கருத வேண்டும். அவற்றுக்கு பதிப்புகளை (version) உருவாக்குங்கள். பங்குதாரர்களுடன் (stakeholders) அவற்றை ஆய்வு செய்யுங்கள். ஏஜென்ட் உருவாக்கத் தொடங்குவதற்கு முன்பே, உண்மையான பணிப்பாய்வுகளைக் (workflows) கொண்டு அவற்றைச் சரிபார்க்கவும். ஒரு சாட் பாக்ஸில் (chat box) எழுதப்பட்ட ஒரு ப்ராம்ப்ட் (prompt) விவரக்குறிப்பு அல்ல. அது ஒரு பொறுப்பு (liability).
பொறியியல் தீர்ப்பு (Engineering Judgment) முன்னதாகவே மாறுகிறது
பொறியியல் தீர்ப்பு மறைந்துவிடவில்லை. அது ஒரு உயர்ந்த நிலைக்கு நகர்கிறது.
ஒரு வரைபடத்தை (map) எவ்வாறு சுழற்சி முறையில் இயக்குவது அல்லது ஒரு வகுப்பு படிநிலையை (class hierarchy) எவ்வாறு கட்டமைப்பது என்பதில் நீங்கள் இனி உங்கள் மன ஆற்றலைச் செலவிடத் தேவையில்லை. மாறாக, தோல்வியின் போது அமைப்பு என்ன செய்ய வேண்டும், எந்தத் தரவை அது ஒருபோதும் வெளிப்படுத்தக்கூடாது மற்றும் விநியோகிக்கப்பட்ட சேவைகளில் (distributed services) எந்த மாறிலிகள் (invariants) மாறாமல் இருக்க வேண்டும் என்பதில் நீங்கள் கவனம் செலுத்த வேண்டும். குறியீட்டு முறை (coding) என்பது தேவைகளைத் தீர்மானிக்கும் கலையாக மாறிவருகிறது.
இதன் பொருள், உங்கள் குறியீட்டிற்கு நீங்கள் ஒரு காலத்தில் கடைப்பிடித்த அதே துல்லியத்தை உங்கள் விவரக்குறிப்புகளுக்கும் வழங்க வேண்டும் என்பதாகும். உங்கள் கட்டுப்பாடுகளைத் (constraints) துல்லியமாகப் பெயரிடுங்கள். தோல்வி முறைகளை (failure modes) வெளிப்படையாக வரையறுக்கவும். உங்கள் தரவு வகைகளை (types) அறிவித்ததைப் போலவே வணிக விதிகளைத் தெளிவாகக் கூறவும். ஏஜென்ட் அதன் செயல்பாட்டை (implementation) கவனித்துக் கொள்ளும். அந்தச் செயல்பாடு உருவாக்குவதற்குத் தகுதியானது என்பதை நீங்கள் உறுதிப்படுத்த வேண்டும்.
உங்கள் தரக் கட்டுப்பாட்டை (quality bar) 'pull request'-லிருந்து 'prompt'-க்கு மாற்றவும். முதலில் சோதனைச் சட்டகத்தை (harness) உருவாக்குங்கள். இரண்டாவதாக விவரக்குறிப்பை எழுதுங்கள். பின்னர், சிக்கல் சரியாக வரையறுக்கப்பட்டுள்ளதா மற்றும் எல்லைகள் பாதுகாப்பாக வரையப்பட்டுள்ளனவா என்பதில் நீங்கள் கவனம் செலுத்தும் போது, இயந்திரத்தை அதன் தொடரியலை (syntax) கையாளுவதற்கு விடுங்கள்.
இந்த மாற்றத்தின் பின்னணியில் உள்ள கருத்துக்களை இன்னும் ஆழமாக ஆராய விரும்பினால், Intent-Driven Development குறித்த அசல் விவாதம் இங்கே கிடைக்கிறது. AI-native பொறியியல் குறித்த தொடர்ச்சியான உரையாடல்களுக்கு, நீங்கள் GyaanSetu சமூகத்திலும் இணையலாம்.