Developers Spend 11.4 Hours a Week Reviewing AI Code—More Than They Write Themselves

2,900 பொறியாளர்கள் பங்கேற்ற 2026 ஆம் ஆண்டு கணக்கெடுப்பின்படி, டெவலப்பர்கள் இப்போது வாரத்திற்கு 11.4 மணிநேரம் AI-ஆல் உருவாக்கப்பட்ட குறியீட்டை (code) ஆய்வு செய்வதில் செலவிடுகின்றனர், இது அவர்கள் சுயமாக எழுதும் 9.8 மணிநேரத்தை விட அதிகமாகும். தடையானது "AI-ஆல் குறியீட்டை உருவாக்க முடியுமா?" என்பதிலிருந்து "அது உருவாக்கும் குறியீட்டை நாம் நம்ப முடியுமா?" என்பதற்கு மாறியுள்ளது. மேலும், தெளிவான முடிவெடுக்கும் முறைகளையும் (decision trails) அதிக நம்பிக்கையையும் வழங்கும் பல-முகவர் (multi-agent) AI பணிப்பாய்வுகளை நோக்கி குழுக்கள் நகர்ந்து வருகின்றன.

உரையாடலைத் தூண்டிய கணக்கெடுப்பு

இந்த ஆண்டின் தொடக்கத்தில் நடத்தப்பட்ட இந்த வினாத்தாள், புதிய குறியீட்டை எழுதுவதற்கும் AI-ஆல் உருவாக்கப்பட்ட குறியீட்டைச் சரிபார்ப்பதற்கும் டெவலப்பர்கள் எவ்வாறு நேரத்தைப் பிரிக்கிறார்கள் என்று கேட்டது. ஆரம்பக்கட்ட உருவாக்கத்தை விட இப்போது ஆய்வு செய்வதே அதிக நேரம் எடுப்பதாகப் பதிலளித்தவர்கள் தெரிவித்தனர். மேலும், ஒரே திட்டத்தில் இரண்டு முதல் நான்கு வெவ்வேறு AI உதவியாளர்களைக் கையாளுவதாகவும், 70% பேர் இத்தகைய நடைமுறை வழக்கமாகிவிட்டதாகவும் தெரிவித்தனர்.

இந்த எண்கள் வளர்ந்து வரும் ஏமாற்றத்தைப் பிரதிபலிக்கின்றன: ஒரு பொதுவான மாதிரி (single, all-purpose model) சில நொடிகளில் ஒரு செயல்பாட்டை (function) எழுதிவிட முடியும், ஆனால் அது தரவு கட்டமைப்புகள் (data structures), பிழை கையாளுதல் (error handling) மற்றும் செயல்திறன் மேம்பாடுகள் (performance optimizations) குறித்த மறைமுகத் தேர்வுகளை எந்தப் பதிவும் இன்றி செய்கிறது. டெவலப்பர்கள் இறுதியில் அந்த முடிவுகளைத் தலைகீழாக ஆய்வு செய்ய வேண்டியுள்ளது (reverse-engineering), இது ஒரு முழு வேலை நாளையும் எடுத்துக் கொள்ளும் ஒரு செயல்முறையாகும்.

ஏன் ஒரு தனி மாதிரி போதுமானதாக இல்லை

பல ஆண்டுகளாக, வழக்கமான பணிப்பாய்வு இவ்வாறு இருந்தது: ஒரு டெவலப்பர் ஒரு தூண்டுதலை (prompt) தட்டச்சு செய்வார், மாதிரி ஒரு கோப்பை உருவாக்கும், மேலும் டெவலப்பர் அதை codebase-க்குள் நகலெடுப்பார். இது விரைவான டெமோக்களுக்கு (demos) வேலை செய்யும், ஆனால் உற்பத்தி மென்பொருள் (production software) ஒருமுறை வெளியாகும் முடிவை விட மேலானதைக் கோருகிறது. உதாரணமாக, ஒரு மாதிரி ஒரு array-க்கு பதிலாக linked list-ஐப் பயன்படுத்த அல்லது பிழைகளை (exceptions) அமைதியாக விழுங்க (swallow) முடிவு செய்யும் போது, அந்தத் தேர்வுகள் குறியீட்டில் பதிந்துவிடுகின்றன மற்றும் ஆய்வாளரின் பார்வையில் இருந்து மறைந்துவிடுகின்றன.

மாதிரியின் உள்நிலைத் தர்க்கம் (internal reasoning) பதிவு செய்யப்படாததால், குழுக்கள் "AI ஏன் இந்த முறையைத் தேர்ந்தெடுத்தது?" என்று கேள்வி எழுப்புகின்றனர். இதற்கான விடை பெரும்பாலும் உருவாக்கப்பட்ட கருத்துகளை (comments) ஆராய்வதற்கோ, வெவ்வேறு temperature அமைப்புகளுடன் தூண்டுதலை மீண்டும் இயக்குவதற்கோ அல்லது முழு உருவாக்கும் நிலையையும் மீண்டும் செய்வதற்கோ தேவைப்படுகிறது. இந்த நிச்சயமற்ற தன்மை இப்போது கணக்கெடுப்பில் கூடுதல் ஆய்வு நேரமாகத் தெரிகிறது.

வேலையைப் பிரித்தல்: பல-முகவர் அமைப்புகள் எவ்வாறு உதவுகின்றன

பல-முகவர் அமைப்புகள் (Multi-agent setups) ஒரு சிறிய மேம்பாட்டுக் குழுவைப் போலவே செயல்படுகின்றன. அனைத்தும் ஒன்றே ஒரு மாதிரியால் கையாளப்படுவதற்குப் பதிலாக, தனித்தனி முகவர்கள் (agents) வெவ்வேறு பொறுப்புகளை ஏற்கிறார்கள்:

• Architect agent: ஒரு உயர்நிலை வடிவமைப்பு ஆவணத்தை (high-level design document) உருவாக்குகிறது, தரவு மாதிரிகள் (data models), API ஒப்பந்தங்கள் (API contracts) மற்றும் பிழை கையாளுதல் உத்திகளைத் திட்டமிடுகிறது.
• Implementation agent: வடிவமைப்பைப் பின்பற்றி, விவரக்குறிப்புகளை (specifications) ஒரு சரிபார்ப்புப் பட்டியலாகப் பயன்படுத்தி குறியீட்டை எழுதுகிறது.
• Verification agent: அலகுகளைச் சோதனை செய்தல் (unit tests), static analysis அல்லது CI/CD పైప్‌லைன்களை உருவாக்குதல் ஆகியவற்றில் கவனம் செலுத்தி, தர உறுதிப்பாட்டை (quality assurance) மட்டுமே நோக்கமாகக் கொண்டுள்ளது.

ஒவ்வொரு முகவரின் வெளியீடும் ஒரு தனித்தனிப் பொருளாக (discrete artifact) இருப்பதால், ஒரு முடிவின் பின்னணியில் உள்ள தர்க்கம் அந்தப் பொருளிலேயே இருக்கும். எந்தவொரு குறியீட்டு வரியும் எழுதப்படுவதற்கு முன்பே வடிவமைப்பை ஆய்வு செய்வது, தவறான வடிவமைப்புத் தேர்வினால் ஏற்படும் பிழையைச் சரிசெய்வதை விடக் குறைவான செலவே தரும். மேலும், ஒரு குறிப்பிட்ட செயலாக்க விவரத்தைத் (implementation detail) தீர்மானித்தது யார் (அல்லது எது) என்பதைப் பார்க்க வேண்டிய இணக்கக் குழுக்களின் (compliance teams) தேவையும் இதன் மூலம் பூர்த்தியாகிறது.

பல-முகவர் பணிப்பாய்வுகளை நடைமுறைப்படுத்தும் கருவிகள்

டெவலப்பர்கள் ஏற்கனவே பல்வேறு பயன்பாடுகளைக் கொண்டு இத்தகைய பணிப்பாய்வுகளை உருவாக்கி வருகின்றனர்:

• IDE integrations முகவர்கள் பக்கவாட்டுப் பலகைகளாக (side panels) தோன்றுவதற்கு அனுமதிக்கின்றன, ஒரு கிளிக்கில் வடிவமைப்பு ஆவணத்தை குறியீடு உருவாக்கும் உதவியாளருக்கு அனுப்ப முடியும்.
• CLI utilities ஸ்கிரிப்ட் செய்யப்பட்ட வரிசைகளை (scripted sequences) அனுமதிக்கின்றன: architect-ஐ இயக்குங்கள், அதன் வெளியீட்டை coder-க்கு அனுப்புங்கள், பின்னர் முடிவை ஒரு tester-இடம் ஒப்படையுங்கள்.
• Frameworks திட்டத் தேவைகளைப் பொறுத்து மாற்றிக்கொள்ளக்கூடிய தனிப்பயன் முகவர்களை (custom agents) உருவாக்குவதற்கான நூலகங்களை (libraries) வழங்குகின்றன.
• Specification-first platforms எந்த உருவாக்கமும் தொடங்குவதற்கு முன் ஒரு முறையான தேவைக் கோப்பைக் (requirements file) கோருகின்றன, இதன் மூலம் வடிவமைப்புப் படிநிலையைத் தவிர்க்க முடியாது என்பதை உறுதி செய்கின்றன.

கணக்கெடுப்பின் 70% புள்ளிவிவரம், பெரும்பாலான குழுக்கள் ஏற்கனவே இத்தகைய பணிப்பாய்வுகளின் தற்காலிகப் பதிப்புகளை (ad-hoc versions) உருவாக்கியுள்ளன என்பதைக் காட்டுகிறது. புதிய தளங்கள் பொறியாளர்கள் கைமுறையாகச் செய்து வந்தவற்றை முறைப்படுத்துகின்றன.

யார் பயனடைவார்கள்—மற்றும் யார் பின் தங்குவார்கள்

நிதி அல்லது சுகாதாரம் போன்ற கடுமையான தணிக்கைத் தேவைகளைக் (audit requirements) கொண்ட நிறுவனங்கள் உடனடியாகப் பயனடைகின்றன. ஆவணப்படுத்தப்பட்ட வடிவமைப்பு-லிருந்து-குறியீடு வரையிலான சங்கிலித் தொடர், உற்பத்திச் சூழலில் மறைமுகமான பாதிப்புகள் (vulnerabilities) நுழைவதற்கான அபாயத்தைக் குறைக்கிறது. சிறிய ஸ்டார்ட்அப்கள் (startups) மிக வேகமாகச் செயல்படும் போது, ஒரு தனி மாதிரியின் வேகம் அவ்வப்போது செய்யப்படும் மறுவேலைக்கான (rework) செலவை விட அதிகமாக இருந்தால், பல முகவர்களைப் பராமரிப்பதன் சுமையைத் தேவையில்லை என்று கருதலாம்.

பல-ஏஜென்ட் அமைப்புகள் (multi-agent systems) சிக்கலை அதிகரிக்கின்றன என்று ஒரு எதிர்வாதம் முன்வைக்கப்படுகிறது. மூன்று அல்லது அதற்கு மேற்பட்ட மாதிரிகளை ஒருங்கிணைப்பது ஒருங்கிணைப்புப் பிழைகளை (integration bugs) ஏற்படுத்தலாம், தாமதத்தை (latency) அதிகரிக்கலாம் மற்றும் மிகவும் நுணுக்கமான கண்காணிப்புத் தேவையை உருவாக்கலாம். தனிப்பயனாக்கப்பட்ட ஏஜென்ட்களை உருவாக்க அல்லது நிர்வகிக்கத் தேவையான நிபுணத்துவம் இல்லாத குழுக்கள், உண்மையான மேம்பாட்டை விட ஒருங்கிணைப்பிலேயே (orchestration) அதிக நேரத்தைச் செலவிடக்கூடும். அத்தகைய குழுக்களுக்கு, நன்கு சரிசெய்யப்பட்ட ஒரு ஒற்றை மாதிரி—குறிப்பாக உள்ளமைக்கப்பட்ட விளக்கத்திறன் (built-in explainability) கொண்ட ஒன்று—நடைமுறை ரீதியான தேர்வாக இருக்கலாம்.

வரும் மாதங்களில் கவனிக்க வேண்டியவை

• தரப்படுத்தப்பட்ட லாகிங் வடிவங்கள் (Standardised logging formats) AI-ஆல் உருவாக்கப்பட்ட கலைப்பொருள் (artifacts) ஆகியவற்றிற்குப் பயன்படுத்தப்படும்போது, வெவ்வேறு ஏஜென்ட்களின் வெளியீடுகளை ஒப்பிடுவது எளிதாக இருக்கும்.
• கட்டமைப்பு (architecture), குறியீட்டு முறை (coding) மற்றும் சோதனை (testing) ஏஜென்ட்களை ஒரே சந்தாவுடன் வழங்கும் சந்தைப் படைப்புகள் (Marketplace offerings), உள்நாட்டு AI நிபுணத்துவம் இல்லாத குழுக்களுக்கான தடைகளைக் குறைக்கலாம்.
• AI-உதவியுடன் கூடிய குறியீடுகள் குறித்த ஒழுங்குமுறை வழிகாட்டுதல்கள் (Regulatory guidance), அதிக நிறுவனங்களை தணிக்கை செய்யக்கூடிய (auditable), பல-படிநிலை வழிமுறைகளை (multi-step pipelines) நோக்கித் தள்ளக்கூடும்.
• வெறும் உருவாக்கும் வேகத்தை மட்டும் பார்க்காமல், மொத்த மேம்பாட்டு நேரத்தையும் அளவிடும் செயல்திறன் அளவுகோல்கள் (Performance benchmarks), கூடுதல் ஒருங்கிணைப்புச் சுமை பலன் தருகிறதா என்பதைத் தீர்மானிக்க குழுக்களுக்கு உதவும்.

இந்த ஆய்வின் முக்கியப் புள்ளிவிவரங்கள் ஒரு தெளிவான உண்மையைச் சொல்கின்றன: டெவலப்பர்கள் புதிய குறியீடுகளை எழுதுவதை விட, AI வெளியீடுகளை மீண்டும் சரிபார்ப்பதிலேயே வாரத்தின் பெரும்பகுதியைச் செலவிடுகிறார்கள். பல-ஏஜென்ட் பணிப்பாய்வுகள் (Multi-agent workflows) இதற்கு ஒரு நேரடிப் பதிலாகத் தோன்றுகின்றன; இவை "பிளாக்-பாக்ஸ்" (black-box) உருவாக்கத்தை ஆவணப்படுத்தப்பட்ட, மறுஆய்வு செய்யக்கூடிய ஒரு செயல்முறையாக மாற்றும் தடயங்களைக் (traceability) கொண்டுள்ளன. கூடுதல் ஒருங்கிணைப்புச் சிக்கல் ஒவ்வொரு குழுவிற்கும் போதுமானதா என்பது பொறுத்தவரை, ஆனால் AI பொறுப்புகளைப் பிரிக்கும் போக்கு மென்பொருள் உருவாக்க முறையையே ஏற்கனவே மறுசீரமைத்து வருகிறது.