முகவர் «முடிந்தது» என்றது, ஆனால் அம்சம் வேலை செய்யவில்லை: ஏன் நடக்கிறது, AI முகவரின் வேலையை எப்படிச் சரிபார்ப்பது

இது ஏன் நடக்கிறது

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

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

ஒரு தவறான «முடிந்தது»-இன் காலவரிசை

முகவருக்கு கடவுச்சொல் மீட்டமைக்கும் பணி கொடுக்கப்பட்டது. அவன் database schema-ஐ மாற்றினான், ஒரு endpoint சேர்த்தான், மின்னஞ்சல் வார்ப்புருவை இணைத்தான், unit tests ஓட்டினான் — அனைத்தும் பச்சை. அரட்டையில் நம்பிக்கையான ஒரு வாக்கியம் வந்தது: «முடிந்தது».

உண்மையில் நடந்தவை:

• migration நடுவில் தோல்வியடைந்து schema-ஐ முரண்பட்ட நிலையில் விட்டது;
• மின்னஞ்சல் வார்ப்புரு உள்ளது, ஆனால் சூழலில் அஞ்சல் சேவை (SMTP) அமைக்கப்படவில்லை — மின்னஞ்சல் அனுப்பப்படவில்லை;
• «பயனர் இணைப்பைக் கிளிக் செய்கிறார் → புதிய கடவுச்சொல்லை உள்ளிடுகிறார் → உள்நுழைகிறார்» என்ற காட்சி ஒருமுறையும் இயக்கப்படவில்லை.

இவற்றில் ஒன்றையும் unit tests பிடித்திருக்க முடியாது: database போலியாக்கப்பட்டது (mock), மின்னஞ்சல் அனுப்புதல் போலியாக்கப்பட்டது, முழு ஓட்டமும் இல்லை.

பச்சை tests அம்சம் வேலை செய்கிறது என்பதை ஏன் நிரூபிப்பதில்லை

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

Unit tests அடிப்படையில் பார்க்க முடியாத நான்கு வகை குறைபாடுகள் உள்ளன:

சரிபார்ப்பு நிலைகள் ஒன்றுக்குள் ஒன்று அமைந்துள்ளன: unit பிடிப்பதை integration tests-உம் பிடிக்கும், integration பிடிப்பதை முடிவிலிருந்து-முடிவு (E2E) ஓட்டமும் பிடிக்கும். ஒவ்வொரு அடுத்த நிலையும் அதிகமாகப் பார்க்கிறது. எனவே «முடிந்தது» என்று சொல்லும் உரிமை மேல் நிலைக்கு மட்டுமே இருக்க வேண்டும்.

பிரச்சினையை அளவிடுதல்: verification gap

சரிசெய்வதற்கு முன் அளவிடுங்கள். முகவர் மூடிய கடைசி 10 பணிகளை எடுங்கள். ஒவ்வொன்றுக்கும் இரண்டு கேள்விகளுக்குப் பதிலளியுங்கள்: முகவர் «முடிந்தது» என்றானா, சுயாதீனச் சரிபார்ப்பு அதை உறுதிப்படுத்தியதா (நீங்களே காட்சியை இயக்கினீர்களா, அல்லது E2E tests பச்சையா). பொருந்தாமையின் விகிதமே உங்கள் verification gap.

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

உண்மையான சரிபார்ப்பு: மூன்று அடுக்கு சரிபார்ப்பு

ஒரு பயனுள்ள ஒப்பீடு வாகனப் பழுதுபார்ப்பு நிலையம். வாகனம் மூன்று நிலையங்களைக் கடக்கிறது, எந்த நிலையத்தையும் தவிர்க்க முடியாது.

1. கண்டறிதல் (நொடிகள்): தொடரியல், வகைகள், linter. எழுத்துப் பிழைகளையும் தெளிவான குறைபாடுகளையும் பிடிக்கிறது.
2. சோதனை பெஞ்ச் (நிமிடங்கள்): unit மற்றும் integration tests, பயன்பாடு தொடங்குகிறது. இயந்திரம் ஓடுகிறது, ஆனால் வாகனம் இன்னும் நிற்கிறது.
3. சாலைச் சோதனை: பயனர் காட்சியை எப்படி இயக்குகிறாரோ அப்படியே — API, browser அல்லது CLI வழியாக, உண்மையான database மற்றும் அமைப்புகளுடன்.

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

எல்லாவற்றையும் ஒரே நுழைவாயிலில் தொகுக்கலாம்:

# Makefile
check:
	ruff check .
	mypy app
	pytest tests/unit tests/integration

e2e:
	docker compose up -d db mailhog
	alembic upgrade head
	pytest tests/e2e

verify: check e2e

இங்கே E2E இலக்கு உண்மையான database-ஐயும் ஒரு சோதனை அஞ்சல் சேவையகத்தையும் தொடங்குகிறது, migrations-ஐப் பயன்படுத்துகிறது, காட்சியை முதல் முதல் கடைசி வரை இயக்குகிறது. தோல்வியடைந்த migration அல்லது அமைக்கப்படாத அஞ்சல் உடனே தெரியும், வாடிக்கையாளருக்கு அல்ல.

AGENTS.md-இல் Definition of Done

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

## Definition of Done
அம்சம் முடிந்ததாகக் கருதப்படுவது கீழே உள்ள அனைத்தும் நிறைவேறினால் மட்டுமே:
1. make check குறியீடு 0 உடன் முடிந்தது
2. make e2e குறியீடு 0 உடன் முடிந்தது, அம்சத்தின் காட்சி tests/e2e-இல் உள்ளது
3. Migrations வெற்று database-இல் பயன்படுத்தப்பட்டு திரும்பப் பெறப்படும்
4. புதிய சூழல் மாறிகள் .env.example-இல் விவரிக்கப்பட்டுள்ளன
5. PROGRESS.md என்ன செய்யப்பட்டது, எப்படிச் சரிபார்க்கப்பட்டது என்று எழுதியுள்ளது

இவை தயார்நிலைக்கான அடையாளம் அல்ல:
- «குறியீடு எழுதப்பட்டுள்ளது, சரியாகத் தெரிகிறது»
- «unit tests கடந்து செல்கின்றன»
- «என் கணினியில் வேலை செய்கிறது»

«தயார்» அல்லாதவற்றின் தெளிவான பட்டியல் எதிர்பார்ப்பதை விட நன்றாக வேலை செய்கிறது: முகவர் முதல் பச்சை ஓட்டத்தில் நிற்பதை நிறுத்துகிறான்.

«passing» கொடுக்கும் உரிமை யாருக்கு

அடுத்த படி, தயார்நிலை நிலையை முகவரின் கையிலிருந்து முழுமையாக எடுப்பது. அம்சங்கள் ஒரு பட்டியலில் (உதாரணமாக feature_list.json) «நடத்தை», «சரிபார்ப்புக் கட்டளை», «நிலை» புலங்களுடன் சேமிக்கப்படுகின்றன. ஒரு script மட்டுமே அம்சத்தை passing-க்கு மாற்ற முடியும்: அது பொது make check-ஐ இயக்குகிறது, பின்னர் அந்த அம்சத்தின் சரிபார்ப்புக் கட்டளையை, வெற்றியடைந்தால் commit hash உடன் நிலையைப் பதிவு செய்கிறது. தோல்வியடைந்தால் அம்சம் active ஆக இருக்கும் — «ஏறக்குறைய வெற்றி» என்பதற்கு இடமில்லை.

{
  "id": "F04",
  "behavior": "பயனர் இணைப்புடன் மின்னஞ்சலைப் பெற்று கடவுச்சொல்லை மாற்றுகிறார்",
  "verification": "pytest tests/e2e/test_password_reset.py",
  "state": "active"
}

இங்கே ஒரு பொறி உள்ளது: script verification புலத்தில் எழுதப்பட்டதை மட்டுமே சரிபார்க்கும். கட்டமைப்புச் சரிபார்ப்பு Definition of Done-இன் ஒரு பகுதியாக இருந்து அம்சத்தின் கட்டளையில் இல்லையென்றால், அந்த இடைவெளி கண்ணுக்குத் தெரியாமல் இருக்கும். எனவே பொது make check எல்லா கட்டாயச் சரிபார்ப்புகளையும் உள்ளடக்க வேண்டும், tests மட்டும் அல்ல.

சுயாதீன மதிப்பீட்டாளர்

செயல்படுத்துபவரின் சுய அறிக்கை ஒருபோதும் சுயாதீனமான உண்மையின் ஆதாரம் அல்ல. தீர்வு கட்டமைப்புரீதியானது: பாத்திரங்களைப் பிரிக்கவும்.

• திட்டமிடுபவர் தேவைகளை ஏற்பு அளவுகோல்களுடன் அம்சங்களாகப் பிரிக்கிறார், குறியீடு எழுதுவதில்லை;
• உருவாக்குபவர் ஓர் அம்சத்தைச் செயல்படுத்தி tests-ஐ இயக்குகிறார், ஆனால் அது தயாரா என்று முடிவு செய்வதில்லை;
• மதிப்பீட்டாளர் அளவுகோல் பட்டியலின்படி தீர்ப்பு வழங்குகிறார்.

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

முகவர் தானே சரிசெய்யக்கூடிய பிழைச் செய்திகள்

சரிபார்ப்பு அதன் வெளியீடு திருத்தத்துக்கு வழிநடத்தினால் மட்டுமே பயனுள்ளது. «Test failed» அல்லது வெற்று AssertionError முகவருக்கு எதையும் சொல்லாது. நல்ல செய்தி என்ன உடைந்தது, விதி ஏன் உள்ளது, எப்படிச் சரிசெய்வது என்று சொல்கிறது:

ERROR arch-check: app/services/refund.py app/db/session.py-ஐ இறக்குமதி செய்கிறது
WHY: service நேரடியாக database-ஐத் தொடுவதில்லை, repository வழியாக மட்டுமே
FIX: app/repositories/refund.py-இலிருந்து RefundRepository-ஐப் பயன்படுத்துங்கள்

இத்தகைய வடிவம் சரிபார்ப்பைத் தடையிலிருந்து குறிப்பாக மாற்றுகிறது: முகவர் உங்கள் தலையீடின்றி மீறலைச் சரிசெய்கிறான்.

கைமுறைச் சரிபார்ப்பு: இன்னும் எங்கே தேவை

தானியக்கம் மனிதரை நீக்குவதில்லை, ஆனால் அவரது பங்கைக் குறைக்கிறது. அளவுகோல்களை முறைப்படுத்துவது கடினமான இடங்களில் கைமுறைச் சரிபார்ப்பு தேவை: இடைமுகத்தின் தோற்றம், உரை, காட்சியின் வசதி. அதை ஏற்பு அளவுகோல்களின் பட்டியலைக் கொண்டு செய்யுங்கள், «சும்மா கிளிக் செய்வதன்» மூலம் அல்ல. முகவருக்கு ஒரே கருத்தை இரண்டாவது முறை எழுதுகிறீர்கள் என்றால், அது தானியங்கிச் சரிபார்ப்பாக மாற்ற வேண்டிய சமிக்ஞை: tests, linter விதி, அல்லது make check-இல் grep-guard.

E2E ஓட்டத்துக்கு முன்பே முகவரின் நடத்தையை எப்படி மாற்றுகிறது

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

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

பொதுவான தவறுகள்

• முகவரிடம் «இன்னும் கவனமாகச் சரிபார்» என்று கேட்பது. சூழல் அதேதான், மதிப்பீடு இன்னும் மிகைப்படுத்தப்பட்டதாகவே இருக்கும்.
• 100% கவரேஜை உத்தரவாதமாகக் கருதுவது. Unit கவரேஜ் இணைப்புகளை மறைப்பதில்லை.
• அம்சம் உறுதிப்படுத்தப்படும் முன் மறுஆக்கம் செய்வது. வரிசை கடுமையானது: சரியான தன்மை → செயல்திறன் → நடை.
• E2E-இல் அடிக்கடி உடையும் பகுதியைப் போலியாக்குவது. Database, migrations, அமைப்புகள் E2E-இல் உண்மையாக இயங்க வேண்டும்; செலுத்த வேண்டிய வெளி API-களை ஒரு சோதனை சேவையகத்தால் மாற்றலாம்.

சுருக்கம்

முகவர் «முடிந்தது» என்று எழுதியும் அம்சம் வேலை செய்யாதபோது, பிரச்சினை கிட்டத்தட்ட எப்போதும் சரிபார்ப்பு செயல்முறையில்தான் இருக்கும், மாதிரியில் அல்ல. verification gap-ஐ அளவிடுங்கள், AGENTS.md-இல் Definition of Done வையுங்கள், E2E-ஐ கட்டாயமாக்குங்கள், தயார்நிலை நிலையை script-க்குக் கொடுங்கள், சுயாதீன மதிப்பீட்டாளரைச் சேர்க்கவும். இந்த அமைப்பு harness engineering பாடநெறியில் ஆழமாகவும் நடைமுறையிலும் விளக்கப்படுகிறது.