கோடிங் ஏஜெண்டுகளை (coding agents) மதிப்பீடு செய்யும் பொறியியல் குழுக்கள் வழக்கமாகத் தவறான கேள்வியுடன் தான் தொடங்குகிறார்கள். அந்த ஏஜெண்ட் எவ்வளவு தன்னாட்சியுடன் (autonomous) செயல்பட முடியும் என்பதை அவர்கள் அறிய விரும்புகிறார்கள். பைப்லைனின் (pipeline) எவ்வளவு பகுதியை அது கையாள முடியும்? யாருக்கும் தொந்தரவு கொடுக்காமல் அது விவரக்குறிப்பை (spec) எழுத முடியுமா, ரெபாசிட்டரியை (repository) திருத்த முடியுமா மற்றும் புரொடக்ஷனுக்கு (production) அனுப்ப முடியுமா? டெமோக்கள் இந்த வெறியை எளிதாக்குகின்றன. ஒரு சிறிய ப்ராம்ப்ட் (prompt) மூலம் பல மாற்றங்களும் பதிவேற்றங்களும் நடக்கும் ஒரு நேர்த்தியான பணிப்பாய்வை நீங்கள் பார்க்கும்போது, உங்கள் நிறுவனத்திலும் அதே திறனைப் பெற வேண்டும் என்ற எண்ணம் உங்களுக்கு வரும். ஆனால் கவர்ச்சி என்பது ஒரு மோசமான வடிவமைப்புத் தத்துவமாகும். சிறந்த கேள்விகள் மிகவும் சற்றே உற்சாகமற்றவை: இந்தத் thing-க்கு யார் அதிகாரம் வழங்கினார்கள், இது உண்மையில் எந்த அமைப்புகளைத் தொட முடியும், மற்றும் இது தவிர்க்க முடியாமல் ஏதேனும் தவறு செய்யும்போது என்ன நடக்கும்?

தன்னாட்சிப் பொறி

உற்சாகமான தன்னாட்சி என்பது ஒரு பொறி. விவரக்குறிப்புகளை உருவாக்குதல், ரெபாசிட்டரிகளைத் திருத்துதல் மற்றும் குறியீட்டை (code) வெளியிடுதல் போன்ற பணிகளைச் செய்து முடித்துவிட்டதாகக் கூறிக்கொண்டே இருக்கும் பாட்களை (bots) கொண்டாடுவதற்கு அது நம்மைப் பழக்குகிறது. அது பொறியியல் அல்ல. அது ஷெல் அணுகலுடன் (shell access) செய்யப்படும் ஒரு ஆபத்தான நம்பிக்கைச் சோதனை. வேலைகளை உருவாக்குவது மிகவும் எளிதாகிவிடும். எந்தவொரு மாடலும் (model) சில நொடிகளில் குறியீடு, ஆவணங்கள் அல்லது கட்டமைப்புத் திட்டங்களை (architecture plans) உருவாக்கிவிடும். ஆனால் மென்பொருள் மேம்பாட்டில் உண்மையான செலவு என்பது தட்டச்சு செய்யும் வேகம் அல்ல. அது எப்போதும் சரிபார்த்தல் (validation), ஆய்வு (review) மற்றும் இது சரியானது மற்றும் பாதுகாப்பானது என்று கூறி ஒப்புதல் அளிக்கும் கவனமான முடிவே ஆகும். உருவாக்கப்பட்ட வேலைகள் மலிவானவை. ஆனால் ஒப்புதல் அளிப்பது விலை உயர்ந்தது. ஒப்புதலைத் தெளிவாகவும் சீராகவும் எவ்வாறு கையாள்வது என்பதைக் கண்டறியும் நிறுவனங்களே உண்மையில் நம்பகமான அமைப்புகளை வெளியிடும்.

சுய-ஆய்வு ஏன் தோல்வியடைகிறது

அபாயங்கள் கணிக்கக்கூடிய முறைகளில் வெளிப்படுகின்றன. ஒரு மாடல் ஒரு திட்டத்தை வரைந்துவிட்டு, அந்தத் திட்டம் எவ்வளவு நல்லது என்று தானே மதிப்பீடு செய்கிறது. ஒரு ஏஜெண்ட் உங்கள் கோட்பேஸைத் (codebase) திருத்திவிட்டு, அதன் மாற்றங்கள் ஏன் பாதுகாப்பானவை என்று உங்களுக்கு விளக்குகிறது. ஒரு கருவி ஒரு கட்டளையைச் செயல்படுத்திவிட்டு, அனுமதிக்கு பதிலாக மன்னிப்பு கேட்கிறது. இவை ஒவ்வொன்றும் ஒரே மாதிரியான அடிப்படைத் தோல்வியைக் குறிக்கின்றன. ஒரு ஏஜெண்ட் ஒரு விவரக்குறிப்பை உருவாக்கினால், அது உண்மையாக மாறுவதற்கு முன்பு அந்த ஏஜெண்டிற்கு வெளியே உள்ள ஏதேனும் ஒன்று அதற்கு ஒப்புதல் அளிக்க வேண்டும். ஒரு ஏஜெண்ட் குறியீட்டை மாற்றினால், ஒரு தனிச் செயல்முறை அந்த மாற்றங்களை (diff) ஆய்வு செய்ய வேண்டும். உருவாக்குபவரையே சரிபார்ப்பவராகவும் (validator) அனுமதிப்பது ஒரு குறுக்குவழி அல்ல. அது வசதி என்ற போர்வையில் மறைக்கப்பட்ட ஒரு கட்டமைப்புப் பிழை (structural bug) ஆகும்.

ப்ராம்ப்ட்கள் (Prompts) அனுமதி அமைப்புகள் அல்ல

சாமர்த்தியமான வார்த்தைகளைக் கொண்டு ஒரு ஏஜெண்டைப் பாதுகாப்பற்ற சூழலில் இருந்து பாதுகாக்க முடியாது. கவனமாக இருக்க வேண்டும் அல்லது எதையும் நீக்குவதற்கு முன் கேட்க வேண்டும் என்று ஒரு மாடலிடம் சொல்வது ஒரு எல்லையை உருவாக்காது. ப்ராம்ப்ட்கள் (Prompts) அனுமதி

மிகவும் பயனுள்ள ஏஜென்ட் அமைப்புகள் (agent systems) மிகப்பெரிய தன்னாட்சிச் செயல்பாடுகளால் (autonomous runs) உங்களை வியக்க வைக்க முயற்சிப்பதில்லை. அவை சிறிய, மறுஆய்வு செய்யக்கூடிய உருவாக்கங்களை (artifacts) உருவாக்குகின்றன. ஒரு துல்லியமான திட்டம். ஒரு கவனம் செலுத்திய வேறுபாடு (diff). ஒரு வாசிக்கக்கூடிய பதிவு (log). பிரம்மாண்டமான தன்னாட்சிச் செயல்பாடுகளைத் பிழைதிருத்தம் (debug) செய்வது ஒரு nightmare போன்றது. ஐம்பது கோப்புகளைக் கொண்ட ஒரு ஏஜென்ட் அமர்வுக்குப் பிறகு ஏதேனும் முறிந்துவிட்டால், நோக்கம் (intent), செயல்பாடு (execution) மற்றும் பக்கவிளைவுகள் (side effects) ஆகிய அனைத்தையும் ஒரே நேரத்தில் பிரித்தெடுக்க வேண்டியிருக்கும். பாதிப்புப் பரவலை (blast radius) சிறியதாக வைத்திருங்கள். ஏஜென்ட் எந்தக் கோப்புகளைப் படித்தது மற்றும் எந்தக் கருவிகளைப் பயன்படுத்தியது என்பதைத் தெரிந்துகொள்ளக் கோருங்கள். கவனிப்பிற்குரிய (Observable) அமைப்புகளே பராமரிக்கக்கூடிய அமைப்புகள். பிளாக்-பாக்ஸ் தன்னாட்சி (Black-box autonomy) என்பது சிறந்த சந்தைப்படுத்தலுடன் கூடிய தொழில்நுட்பக் கடன் (technical debt) மட்டுமே.

அணுகலை அனுமதிப்பதற்கு முன் கேட்க வேண்டிய ஆறு கேள்விகள்

ஒரு ஏஜென்டிடம் உண்மையான பொறுப்பை ஒப்படைப்பதற்கு முன், ஆறு கடினமான கேள்விகளைக் கொண்டு உங்கள் அமைப்பைச் சோதித்துப் பாருங்கள்.

  • அந்த அமைப்பிற்கு உண்மையில் என்ன திறன்கள் உள்ளன?
  • எந்தச் செயல்கள் இயல்பாகவே மறுக்கப்படுகின்றன; அதாவது, சிஸ்டம் பிராம்ப்ட்டில் (system prompt) ஒரு மென்மையான வாக்கியத்தால் தடுக்கப்படாமல், உள்கட்டமைப்பு மட்டத்திலேயே (infrastructure level) தடுக்கப்படுகின்றனவா?
  • எந்தச் செயல்களுக்குத் தெளிவான ஒப்புதல் தேவை?
  • ஏஜென்ட் தனது உள்ளீடுகளைத் (inputs) திருத்திக் கொள்ளாதவாறு, அது பயன்படுத்துவதற்கு முன்பே எந்த உருவாக்கங்கள் (artifacts) முடக்கப்படுகின்றன?
  • ஜெனரேட்டரிலிருந்து (generator) முற்றிலும் மாறுபட்ட எந்த சரிபார்ப்பி (validator) இறுதி வெளியீட்டைத் தீர்மானிக்கிறது?
  • உண்மையில் என்ன நடந்தது என்பதைத் தெளிவான சந்தேகமின்றி எந்தப் பதிவு (log) நிரூபிக்கிறது?

இது அடிப்படைப் பொறியியல் சுகாதாரம் (engineering hygiene). ஜெனரேட்டரை சரிபார்ப்பியிலிருந்து (validator) பிரிக்கவும். மனித அதிகாரத்தை எல்லையில் (boundary) வைத்திருங்கள்.

உண்மையான சோதனை

அங்கே