Markdown பதிப்பு

AI-translated from English; not yet reviewed by a fluent editor.

# AI குறியீட்டு எழுதுதல், நம்பகமான மென்பொருள் வழங்கலை அடுத்த பொறியியல் சவாலாக்குகிறது

> AI குறியீட்டு வெளியீட்டை அதிகரிக்கும்போது, மாற்றங்கள் எங்கு காத்திருக்கின்றன, சரிபார்ப்புக்கு என்ன செலவாகிறது, வெளியிடப்பட்ட மென்பொருள் எதிர்பார்த்தபடி செயல்படுகிறதா என்பதைப் பொறியியல் மேலாளர்கள் அறிய வேண்டும்.

By BIG CHANGE Editorial

Published: 2026-09-22T05:31:05.772Z
Updated: 2026-09-22T05:31:05.772Z
Canonical: https://bigchange.ai/blog/ai-coding-ci-bottleneck-dependable-delivery

![A large stack of blank work cards waits on a conveyor before a magnifying-glass inspection station, with a smaller stack in the output tray.](https://bigchange.ai/api/media/file/validation-queue-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. More proposed changes can put pressure on validation. Conceptual illustration of a queue and inspection stage; stack sizes are not measurements, and passing checks does not guarantee dependable delivery.

AI குறியீட்டு முகவர் ஒரு திருத்தத்தை முடித்திருக்கலாம்; அதற்கு முன் செய்த திருத்தத்துக்கான சோதனைகள் இன்னும் இயங்கிக்கொண்டிருக்கலாம். பொறியியல் மேலாளருக்கு இது சங்கடமான வேறுபாட்டை உருவாக்குகிறது: குழு கூடுதல் குறியீட்டைத் தயாரித்துள்ளது; ஆனால் வாடிக்கையாளருக்கு இன்னும் எதுவும் கிடைக்கவில்லை.

Linear இதற்குப் பயனுள்ள எடுத்துக்காட்டு. 2026 தொடக்கத்திலிருந்து அதன் சோதனைத் தொகுப்புகள் கிட்டத்தட்ட நான்கு மடங்காகின; அதேவேளையில் pull request-களுக்கான தொடர்ச்சியான ஒருங்கிணைப்பு (CI) காத்திருப்பு ஆறு நிமிடத்திற்கும் அதிகத்திலிருந்து ஐந்து நிமிடத்திற்குச் சற்றே மேலாகக் குறைந்தது என்று செப்டம்பர் 21 பொறியியல் பதிவில் Mufeez Amjad தெரிவிக்கிறார். ஒவ்வொரு சோதனைக்கான ரன்னர் நேரமும் ஏறத்தாழப் பாதியாகியது. இவை தனித்தனி மேம்பாடுகள்; கடைசி எண்ணிக்கை மொத்த CI கட்டணம் பாதியாகிவிட்டது என்று பொருளல்ல. முகவர் உதவியுடன் மென்பொருள் உருவாக்குவது சரிபார்ப்பின் மீதான அழுத்தத்தை அதிகரித்ததாக Linear கூறுகிறது; ஆனால் AI உற்பத்தித்திறனில் ஏற்படுத்தும் விளைவை நிறுவும் கட்டுப்படுத்தப்பட்ட ஆய்வு இதுவல்ல. [Linear-இன் பொறியியல் பதிவு](https://linear.app/now/ci-bottleneck-reworked).

தொடர்ச்சியான ஒருங்கிணைப்பு (CI), முன்மொழியப்பட்ட மென்பொருள் மாற்றங்களில் தானியக்கச் சோதனைகளை இயக்குகிறது. நம்பத்தகுந்த திருத்தத்துக்கும் குழு ஏற்கத் தயாரான மாற்றத்துக்கும் இடையில் அது அமைகிறது. AI குறியீட்டு வழங்கலை அதிகரிக்கும்போது, இந்தச் சரிபார்ப்புத் திறன் வணிகக் கேள்வியாகிறது: அமைப்பு எவ்வளவு பயனுள்ள வேலையைப் பாதுகாப்பாக ஏற்க முடியும்?

மூன்று முடிவுகளை மேலாளர்கள் ஒன்றாகத் தெளிவாக்க வேண்டும் என்பதே எங்கள் பார்வை: நம்பகமான பின்னூட்டம் கிடைக்கும் நேரம், மொத்தக் கணினி வேலை, வெளியிடப்பட்ட மாற்றங்களின் நம்பகத்தன்மை. விரைவான பதில், அது எதை நிறுவுகிறது என்பதை குழு புரிந்துகொண்டால்தான் மதிப்புள்ளது.

## காத்திருப்பு குறைந்தாலும் வேலை அதிகரிக்கலாம்

ஒரு கணினியில் பன்னிரண்டு நிமிட வேலை கொண்ட சோதனைத் தொகுப்பைக் கற்பனை செய்யுங்கள். அதை நான்கு கணினிகளில் சமமாகப் பிரித்தால் மூன்று நிமிடத்தில் முடிக்கலாம். இந்தக் கற்பனை எடுத்துக்காட்டில் வேலை சரியாகப் பகிரப்படுகிறது என்றும் மற்ற அம்சங்களைக் கணக்கில் கொள்ளவில்லை என்றும் கருதுகிறோம். ஆனாலும் கணினிகள் மொத்தம் பன்னிரண்டு நிமிட வேலை செய்கின்றன.

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

குறுகிய பச்சை நிறப் பட்டையை டாஷ்போர்டு கொண்டாடும்போது இந்த வேறுபாடு முக்கியம். இணைநிலைத் திறனை வாங்கும் மேலாளர், முன்னதாகப் பின்னூட்டம் பெற பணம் செலுத்துகிறார்; இதற்கு கூடுதல் செலவும் வரலாம். உண்மையான தடையை நீக்கினால் அது சிறந்த பரிமாற்றமாகலாம். முடிக்கப்பட்ட மாற்றம் கிடைக்கும் மதிப்பாய்வாளருக்காக மணிநேரம் காத்திருந்தால் அதற்கான நியாயம் பலவீனமாகும்.

பகுப்பாய்வின் அலகு ஒரு CI இயக்கத்தைத் தாண்டிச் செல்ல வேண்டும். திருத்தங்கள் மீண்டும் மீண்டும் தேவைப்படவும், சோதனைகளை மறுஇயக்கவும், இரண்டாம் கட்ட மதிப்பாய்வு செய்யவும் நேர்ந்த மாற்றம், அதன் மிக விரைவான தனிப்பட்ட இயக்கத்தைவிட அதிக வேலையை உருவாக்கியிருக்கலாம். கைவிடப்பட்ட முயற்சிகள் உட்பட மாற்றத்தை ஏற்கத் தேவையான முயற்சிகளை எண்ணுங்கள். இல்லையெனில் திறமையானதாகத் தோன்றும் வேலைநடைமுறை, செலவுமிக்க மேம்பாட்டுச் செயல்முறையை மறைக்கலாம்.

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

## ஆய்வுகள் கலவையான படத்தைத் தருகின்றன

2026 மார்ச் DORA பகுப்பாய்வு இரண்டு தனித்தனி ஆதாரத் தொகுப்புகளைத் தெரிவிக்கிறது. 2025 ஆய்வு, AI பயன்பாடு அதிகரித்ததுடன் மென்பொருள் வழங்கலின் வேகமும் நிலையின்மையும் உயர்ந்ததாகத் தொடர்புபடுத்தியது. தனியாக, 2025 மூன்றாம் காலாண்டில் Google பொறியாளர்களிடமிருந்து சேகரிக்கப்பட்ட 1,110 திறந்தநிலைப் பதில்களை ஆய்வாளர்கள் பகுப்பாய்வு செய்தனர். வரைவு மற்றும் பிற பணிகளில் உதவி கிடைத்ததுடன், சரிபார்ப்புச் சுமையும் இருந்ததாக பொறியாளர்கள் விவரித்தனர். நிறுவனத்துக்குள் நடந்த இந்தத் தரவுசார் ஆய்வு, பரந்த DORA தொடர்புக்கான பங்கேற்பாளர்களைப் பயன்படுத்தவில்லை; குறிப்பிட்ட குழுவின் வெளியீட்டுச் சிக்கலை AI ஏற்படுத்தியது என்றும் இரண்டில் எதுவும் நிறுவவில்லை. [DORA-வின் பகுப்பாய்வும் ஆய்வுமுறையும்](https://dora.dev/insights/balancing-ai-tensions/).

வரம்பு குறுகியதாயினும் வலுவான பரிசோதனை ஆதாரமும் உள்ளது. 2025 ஜூலை சீர்முறை ஆய்வில், பழக்கமான களஞ்சியங்களில் பணியாற்றிய அனுபவமுள்ள 16 திறந்த மூல நிரலாளர்களுக்கிடையே 246 பணிகள் ஒதுக்கப்பட்டன. 2025 தொடக்க AI கருவிகளைப் பயன்படுத்த அனுமதித்தபோது பணியை முடிக்க 19% கூடுதல் நேரம் எடுத்தது. இருப்பினும் AI விரைவாகப் பணிபுரிய உதவியதாகப் பங்கேற்பாளர்கள் நம்பினர். அந்த முடிவு குறிப்பிட்ட நிரலாளர்கள், பணிகள், கருவிகளைப் பற்றியது; இன்று கிடைக்கும் எல்லா குறியீட்டு முகவர்களின் மதிப்பையும் தீர்மானிக்காது. [METR-இன் அசல் பரிசோதனை](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/).

பின்தொடர் ஆய்வின் மூலம் தற்போதைய உற்பத்தித்திறன் விளைவுக்கான நம்பகமற்ற மதிப்பீடு கிடைத்ததாக METR 2026 பிப்ரவரியில் கூறியது. AI இன்றி வந்த பணிகளை நிரலாளர்கள் மறுக்கவோ, சமர்ப்பிக்க வேண்டிய பணிகளைத் தாங்களே தேர்வுசெய்யவோ அதிகரித்தனர்; ஒரேநேர முகவர்களும் நேரத்தை அளவிடுவதைச் சிக்கலாக்கினர். அதிக விரைவாக்கம் சாத்தியமானது என ஆய்வாளர்கள் கருதினாலும், அதன் அளவுக்கான பலவீனமான ஆதாரமே தரவில் இருந்ததாகக் கூறினர். இந்தத் தகுதிவிளக்கமின்றி பழைய மந்தநிலை எண்ணிக்கையை மீண்டும் கூறுவது வாசகர்களைத் தவறாக வழிநடத்தும். [METR-இன் பின்தொடர் ஆய்வு](https://metr.org/blog/2026-02-24-uplift-update/).

மேலாளருக்கு இந்த ஆய்வுகள் நடைமுறை நிலைப்பாட்டை ஆதரிக்கின்றன: பயனுள்ள கருவிகளை வைத்துக்கொண்டு, அவற்றின் விளைவுகளை ஆராய்ந்து, உற்சாகத்தையோ ஐயத்தையோ அனைவருக்கும் பொருந்தும் பணியாளர் சூத்திரமாக மாற்றாதீர்கள். ஒரு வகைப் பணியில் குழுவுக்குக் கணிசமான நன்மையும் மற்றொன்றில் நேர இழப்பும் ஏற்படலாம். அந்த வேறுபாட்டை அதன் வழங்கல் செயல்முறை வெளிக்காட்ட வேண்டும்.

## ஒவ்வொரு தடைக்கும் தனித்தீர்வு அளியுங்கள்

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

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

சார்புக் கோப்புகளைத் தேக்ககப்படுத்துவது, அளவிட வேண்டிய பரிச்சயமான மேம்பாட்டுக்கு ஓர் எடுத்துக்காட்டு. புதிதாகத் தொடங்கும் ரன்னர்களில் மீண்டும் உருவாக்கச் செலவாகும் கோப்புகளை மறுபயன்படுத்த தேக்ககப்படுத்தல் உதவும் என GitHub ஆவணப்படுத்துகிறது. தேக்ககத் தரவு கிடைக்காதபோதும் பணிகள் அந்தக் கோப்புகளை மீண்டும் உருவாக்கவோ பதிவிறக்கவோ முடியும் என்றும் அது கூறுகிறது. ஆகவே தேக்கக வெற்றியையும் தோல்வியையும் இரண்டையும் மதிப்பிட வேண்டும். [GitHub-இன் சார்புத் தேக்கக ஆவணம்](https://docs.github.com/en/actions/concepts/workflows-and-actions/dependency-caching).

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

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

![One large stopwatch beside a task card contrasts with three separate worker trays, each with its own small clock.](/api/media/file/elapsed-aggregate-work-inline-v1.png)

## விரைவான சோதனைகள் இன்னும் பிழைகளைப் பிடிக்க வேண்டும்

செயல்திறன் மாற்றங்கள் சோதனை இயங்கும் சூழலை மாற்றலாம். அதற்கு, வேகமான செயலியைப் பயன்படுத்துவதைவிட நெருக்கமான ஆய்வு தேவை.

JavaScript மற்றும் TypeScript சோதனைக் கருவியான Vitest, ஒரு கோப்பின் நிலை மற்றொன்றைப் பாதிக்காமல் இருக்க இயல்பாகவே சோதனைக் கோப்புகளைத் தனிமைப்படுத்துகிறது. பொருத்தமான சோதனைகளில் மட்டும் தனிமைப்படுத்தலைக் குறைப்பதையும், மாறக்கூடிய தொகுதிநிலை, மாற்றப்பட்ட பொதுமாறிகள் மற்றும் பிற சார்புகள் இருப்பின் தனிமைப்படுத்தலைத் தொடர வேண்டியதையும் ஆவணம் விளக்குகிறது. தயாரிப்பு நேரத்தைக் குறைக்கும் அமைப்பு, சரித்தன்மைக்கான எல்லையை மாற்றக்கூடும். [Vitest-இன் தனிமைப்படுத்தல் வழிகாட்டி](https://vitest.dev/guide/recipes/disable-isolation).

பகிரப்பட்ட நிலையைத் தேர்வுசெய்து இயக்கும் அணுகுமுறையை Linear பயன்படுத்தி, சுத்தப்படுத்தலைச் சேர்த்து, பாதுகாப்பாக மாற்ற முடியாத கோப்புகளைத் தனிமைப்படுத்தலிலேயே வைத்தது. எந்தச் சோதனைகள் அந்தச் சூழலைப் பாதுகாப்பாகப் பகிரலாம் எனத் தீர்மானித்ததில்தான் அதன் செயல்திறன் மேம்பாடு அமர்ந்திருந்தது. [Linear-இன் செயலாக்கம்](https://linear.app/now/ci-bottleneck-reworked).

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

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

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

## வாடிக்கையாளர்களை அடையும் மாற்றத்தை அளவிடுங்கள்

DORA-வின் வழங்கல் அளவீடுகள் பின்னர் ஏற்படும் முடிவுகளைச் சரிபார்க்க உதவும். உறுதிசெய்யப்பட்ட குறியீட்டிலிருந்து உற்பத்தி வெளியீடு வரையிலான நேரம், வெளியீட்டு அடிக்கடி நிகழ்தல், தோல்வியுற்ற வெளியீட்டிலிருந்து மீளும் நேரம், உடனடி தலையீடு தேவைப்படும் வெளியீடுகளின் விகிதம், திட்டமிடப்படாத சம்பவத் திருத்தப் பணிகளை உள்ளடக்கும் வெளியீடுகளின் விகிதம் ஆகியவை அவற்றில் அடங்கும். வெற்றிகரமான சோதனை ஓட்டத்தைத் தாண்டிய வழங்கல் முடிவுகளை இவை விவரிக்கின்றன. [DORA-வின் அளவீட்டு வரையறைகள்](https://dora.dev/guides/dora-metrics/).

AI குறியீட்டு வேலைநடையை ஆராயும் குழுவுக்கு, இந்த முடிவுகளுடன் சிறிய கண்டறிதல் பதிவையும் இணைக்க நாங்கள் பரிந்துரைப்போம்:

- பின்னூட்டம்: மெதுவான ஓட்டங்களும் திறனுக்காகக் காத்திருக்கும் நேரமும் உட்பட, தேவையான சோதனைகள் முடிவடைய எடுத்த காலம்.
- பயன்பாடு: ஏற்றுக்கொள்ளப்பட்ட மாற்றத்துடன் தொடர்புடைய மொத்த ரன்னர் வேலை மற்றும் மீண்டும் செய்யப்பட்ட முயற்சிகள்.
- மதிப்பாய்வு: கவனத்துக்காகக் காத்திருந்த நேரம், கோரப்பட்ட முக்கியத் திருத்தங்கள், ஒவ்வொரு திருத்தத்துக்குமான காரணம்.
- வாடிக்கையாளர் தாக்கம்: வெளியிடப்பட்ட மாற்றம் நோக்கமிட்ட நடத்தையை வழங்கியதா, திருத்த வேலை தேவைப்பட்டதா.

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

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

## Sources

- [Linear: AI குறியீட்டாக்கமும் CI இடையூறும்](https://linear.app/now/ci-bottleneck-reworked) — 2026 செப்டம்பர் 21. Mufeez Amjad-இன் செயலாக்கப் பதிவு தொடக்க எண்களையும் தேர்ந்தெடுக்கப்பட்ட தனிமைப்படுத்தல் எடுத்துக்காட்டையும் வழங்குகிறது. முதல் தரப்பு அளவீடுகள் Linear அமைப்பைப் பற்றியவை; AI உற்பத்தித்திறன் அல்லது மொத்தச் செலவுக்கான கட்டுப்படுத்தப்பட்ட மதிப்பீடு அல்ல.
- [DORA: AI முரண்பாடுகளுக்கு இடையில் சமநிலை](https://dora.dev/insights/balancing-ai-tensions/) — 2026 மார்ச் 10. 2025 DORA தொடர்பையும் Google பொறியாளர்களின் பதில்கள் குறித்த பண்புசார் ஆய்வையும் வேறுபடுத்துகிறது. அந்த உள்நாட்டு ஆய்வு அனுபவங்களைப் பதிவு செய்கிறது; காரண விளைவுகளை அளவிடவில்லை. முந்தைய கேள்விகள் பதில்களை முன்சாய்த்திருக்கலாம்.
- [METR: 2025 தொடக்க AI மற்றும் அனுபவமுள்ள நிரலாளர்களின் உற்பத்தித்திறன்](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) — 2025 ஜூலை 10 சீர்முறைப் பரிசோதனை; பழக்கமான திறந்த மூலக் களஞ்சியங்களிலும் 2025 தொடக்கக் கருவிகளிலும் நடைபெற்றது. வரையறுக்கப்பட்ட மந்தநிலை முடிவையும் உணர்வுக்கும் உண்மையான நேரத்துக்கும் இடையிலான வேறுபாட்டையும் ஆதரிக்கிறது. எல்லா நிரலாளர்களுக்கோ 2026 செப்டம்பர் மாத மாதிரிகளுக்கோ இது மதிப்பீடு அல்ல.
- [METR: நிரலாளர் உற்பத்தித்திறன் பரிசோதனையை மாற்றுதல்](https://metr.org/blog/2026-02-24-uplift-update/) — 2026 பிப்ரவரி 24 புதுப்பிப்பு. பங்கேற்பாளர் மற்றும் பணி தேர்வு, மாறிய ஊதியம், ஒரேநேரப் பணி அளவீட்டுச் சிக்கல்கள் ஆகியவற்றை விளக்குகிறது. புதிய மதிப்பீடு நம்பகமற்றது என ஆய்வாளர்கள் கூறுகின்றனர்; அதன் மூல எண்களை தற்போதைய வேக உயர்வாக நாங்கள் முன்வைக்கவில்லை.
- [GitHub: சார்புகளைத் தேக்ககப்படுத்துதல்](https://docs.github.com/en/actions/concepts/workflows-and-actions/dependency-caching) — 2026 செப்டம்பர் 22 அன்று பார்த்த தற்போதைய ஆவணம். புதிதாகத் தொடங்கும் ரன்னர்களில் மறுபயன்பாட்டையும் தேக்ககம் இல்லாமல் பணிகள் இயங்க வேண்டியதையும் விளக்குகிறது. குறிப்பிட்ட களஞ்சியத்தின் செயல்திறனையோ கட்டணத்தையோ இது நிறுவவில்லை.
- [Vitest: ஒவ்வொரு கோப்புக்குமான தனிமைப்படுத்தல் அமைப்புகள்](https://vitest.dev/guide/recipes/disable-isolation) — 2026 செப்டம்பர் 22 அன்று பார்த்த தற்போதைய ஆவணம். இயல்புநிலைத் தனிமைப்படுத்தல், தேர்ந்தெடுத்த அமைப்பு, பாதுகாப்பு தேவைப்படும் நிலைச் சார்புகள் ஆகியவற்றை விளக்குகிறது. தொழில்நுட்ப வழிகாட்டி பரிமாற்றத்தை ஆதரிக்கிறது; BIG CHANGE ஒப்பீட்டுச் சோதனையை இயக்கவோ சோதனைத் தொகுப்பை மாற்றவோ இல்லை.
- [DORA: மென்பொருள் வழங்கல் செயல்திறன் அளவீடுகள்](https://dora.dev/guides/dora-metrics/) — 2026 ஜனவரி 5 அன்று புதுப்பிக்கப்பட்டது. சேவை மட்டத்தில் ஐந்து வழங்கல் அளவீடுகளையும் அவற்றின் பயன்பாட்டையும் வரையறுக்கிறது. CI காலத்தைத் தாண்டிய முடிவு அளவீடுகளை இவை தருகின்றன; கட்டுரையின் கண்டறிதல் எடுத்துக்காட்டுகள் ஆய்வு, புதிய பரிசோதனை முடிவுகள் அல்ல.