எனது ஏஜென்ட் ஒரே இரவில் 3 PR-களை சமர்ப்பித்தது. எனது செய்திகளில் 40% திருத்தங்களாக இருந்தன.
எனது AI-ஆல் இயங்கும் கோடிங் ஏஜென்ட் ஒரே இரவில் மூன்று pull requests-களை சமர்ப்பித்தது, ஆனால் நான் அனுப்பிய 30 செய்திகளில் 40% திருத்தங்களாக இருந்தன.
இந்த அமர்வில் ஒரு MCP client, ஒரு Azure AI Agent மற்றும் ஒரு M365 Copilot Agent ஆகியவை உருவாக்கப்பட்டன. தானியங்கிச் சோதனைகள் (Automated checks) மூன்று PR-களையும் அனுமதித்தன, நான் ஒரு வரியைக் கூட மாற்றவில்லை. இருப்பினும், உரையாடல் விவரங்கள் (transcript) வேறொரு கதையைச் சொல்கின்றன: மொத்தம் 710 செய்திகளில், நான் 30 செய்திகளைத் தட்டச்சு செய்தேன், அதில் 12 செய்திகள் ஏஜென்ட்டைச் சரியான பாதையில் கொண்டு செல்ல உதவின. "steering rate" எனப்படும் எனது செய்திகளில் திருத்தங்களின் பங்கு 40% ஆக இருந்தது.
பைப்லைன் எவ்வாறு கட்டமைக்கப்பட்டது
- Claude ஒரு உயர்மட்டச் செயலாக்கத் திட்டத்தை (high-level implementation plan) வரைவு செய்தது.
- DeepSeek V4-Flash ஒருங்கிணைப்பாளராக (orchestrator) செயல்பட்டு, திட்டத்தை ஆய்வு செய்தது.
- Codex உண்மையான குறியீட்டை (code) உருவாக்கியது.
- ஒருங்கிணைப்பாளர் குறியீட்டை ஆய்வு செய்து pull requests-களைத் திறந்தார்.
ஒருங்கிணைப்பாளரின் நோக்கம் வெறும் இணைப்பிற்காக மட்டுமே இருந்தது – அது கூறுகளுக்கு இடையிலான முரண்பாடுகளைத் தீர்க்க வேண்டுமே தவிர, தானாக குறியீட்டை எழுதக்கூடாது. நடைமுறையில், ஏஜென்ட் சுமார் 40 நிமிடங்களில் மூன்று PR-களிலும் 3,500 வரிகள் குறியீட்டை உருவாக்கியது, ஆனால் அது இரண்டு வகையான தொடர்ச்சியான பிழைகளைச் செய்தது.
இரண்டு வகையான பிழைகள்
- பணிப்பாய்வு மீறல்கள் (Workflow violations) – ஒருங்கிணைப்பாளர் அவ்வப்போது தனது "இணைப்பு" (glue) பாத்திரத்தைப் புறக்கணித்துவிட்டு, கோடிங் பணியை ஏற்றுக்கொண்டு, செயலாக்க விவரங்களை (implementation details) தானாகவே எழுதத் தொடங்கியது.
- சூழல் மீட்டெடுப்புத் தோல்விகள் (Context-retrieval failures) – தெளிவான அறிவுறுத்தல்கள் இருந்தபோதிலும், ஏஜென்ட் தவறான SDK அல்லது பதிப்பைத் தேர்ந்தெடுத்தது. சரியான தகவல் பிராம்ப்ட் சூழலில் (prompt context) இருந்தும், மாடல் அதைச் சரியான நேரத்தில் வெளிப்படுத்தத் தவறிவிட்டது.
இவை தர்க்கரீதியான சிந்தனைத் திறனில் உள்ள குறைபாடுகள் அல்ல; இவை பணிப்பாய்வு எவ்வாறு கட்டுப்படுத்தப்படுகிறது என்பதில் உள்ள பொறியியல் பிழைகள் (engineering bugs). இன்னும் திறமையான ஒரு மொழி மாதிரியாக இருந்தாலும், ஒருங்கிணைப்பாளரை கோடிங் அல்லாத பணிகளிலேயே வைத்திருக்கவும், சரியான SDKத் தேர்வை உறுதி செய்யவும் ஒரு கண்டிப்பான, தவிர்க்க முடியாத விதி தேவைப்படும்.
ஏஜென்ட்டைச் சீரமைக்க நான் செய்த மாற்றங்கள்
படிப் பட்டியலிலிருந்து (step list) சிஸ்டம் தனது பாத்திரத்தை தானாகவே புரிந்துகொள்ளும் என்று நான் நினைப்பதை நிறுத்தினேன். அதற்குப் பதிலாக, "You are an orchestrator. You do not implement." (நீ ஒரு ஒருங்கிணைப்பாளர். நீ செயலாக்கங்களைச் செய்யக்கூடாது) என்ற நேரடித் தகவலைச் சேர்த்தேன். இந்த அறிவுறுத்தல் நிலைபெற ஐந்து திருத்தச் செய்திகள் தேவைப்பட்டன, அதன் பிறகு ஏஜென்ட் அந்த எல்லையை மதித்தது.
நான் சூழல் மீட்டெடுப்பு தர்க்கத்தையும் (context-retrieval logic) வலுப்படுத்தினேன். தவறான கருவி பயன்படுத்தப்பட்டபோது, அதை ஒரு மாயத்தோற்றம் (hallucination) என்று கருதாமல், மீட்டெடுப்பு பைப்லைனில் உள்ள ஒரு பிழையாகக் கருதினேன். மேலும், சரியான பதிப்பைத் தவறவிட முடியாதபடி, SDK விவரங்களை வழங்கும் பிராம்ப்ட்டை (prompt) மீண்டும் எழுதினேன்.
AI-ஆல் மேம்படுத்தப்பட்ட மேம்பாட்டிற்கான (AI-augmented development) நடைமுறைப் பாடங்கள்
- உங்கள் செய்திகளைக் கணக்கிடுங்கள். அதிகப்படியான ஏற்றுக்கொள்ளப்பட்ட PR-கள் ஒரு முறிந்த செயல்முறையை மறைக்கக்கூடும். உங்கள் திருத்தங்களின் எண்ணிக்கை, உங்கள் கட்டமைப்பு எங்கு பலவீனமாக உள்ளது என்பதைக் காட்டும் ஒரு முக்கிய அறிகுறியாகும்.
- பாத்திரத்தைத் தெளிவாகக் குறிப்பிடுங்கள். ஏஜென்ட்கள் ஒரு சரிபார்ப்புப் பட்டியலிலிருந்து (checklist) தங்களின் அடையாளத்தை ஊகிப்பதில்லை; அவர்கள் யார் மற்றும் என்ன செய்யலாம் என்பது குறித்த தெளிவான, நிலையான அறிவுறுத்தல் அவர்களுக்குத் தேவை.
- கருவித் தேர்வுப் பிழைகளை பொறியியல் பிழைகளாகக் கருதுங்கள். ஏஜென்ட் குறிப்பிட்ட SDK-ஐப் புறக்கணித்தால், அந்தப் பிழை மாடலின் "அறிவில்" இல்லை, மாறாக சூழலை வழங்கும் வழிமுறையில்தான் (context-delivery mechanism) உள்ளது.
- தவறுகளை மீண்டும் பயன்படுத்தக்கூடிய திறன்களாக மாற்றவும். ஏஜென்ட் செய்த தவறுகளிலிருந்தே ஒரு சரிபார்ப்பு முறையை (validation routine) உருவாக்கச் செய்தேன், இதன் மூலம் ஒரு தோல்வியை எதிர்காலப் பாதுகாப்பாக மாற்றினேன்.