AI முகவரை நம்பகமாக்குவது எப்படி: அளவீட்டிலிருந்து தானியங்கி வேலை வரை படிப்படியான திட்டம்

மாதிரி வலிமையானதாக இருந்தும் முகவர் நம்பகமற்றது ஏன்

முகவரின் நம்பகத்தன்மை முழு அமைப்பின் பண்பு, மாதிரியின் மட்டும் பண்பு அல்ல. நீண்ட வேலையில் டஜன் கணக்கான படிகள் உள்ளன, பிழைகள் குவிகின்றன: ஒவ்வொரு படியும் 95% சரியாக இருந்தாலும், பத்து படிகள் கொண்ட சங்கிலியை ஒரு பிழையுமின்றிக் கடப்பது சுமார் 60% முயற்சிகளில் மட்டுமே (0.95^10 ≈ 0.60), ஐம்பது படிகளில் 10%-க்கும் குறைவு. மாதிரியின் துல்லியம் உங்கள் கையில் இல்லை, ஆனால் அதே படியில் பிழையைப் பிடித்து அதை மலிவாக்குவது உங்கள் கையில் உள்ளது. Harness அதைத்தான் செய்கிறது: வழிகாட்டல், கருவிகள், சூழல், நிலை மற்றும் பின்னூட்டத்தால் மாதிரியைச் சுற்றி வைப்பது.

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

படி 1. «உணர்வின்» அடிப்படையில் மதிப்பிடுவதை நிறுத்துங்கள்

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

| தேதி  | பணி                | என்ன நடந்தது                    | கூறு           |
|-------|--------------------|---------------------------------|----------------|
| 10/10 | கூடையில் தள்ளுபடி | «முடிந்தது», e2e இயக்கப்படவில்லை | பின்னூட்டம்    |
| 10/10 | கட்டண webhook      | database-ஐத் தொடங்க முடியவில்லை  | சூழல்          |
| 11/10 | API மறுசீரமைப்பு   | ஏற்கனவே நிராகரித்ததை மீண்டும்    | நிலை           |

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

படி 2. இரண்டு அளவீடுகளைக் கொண்டு வாருங்கள்: MTBF மற்றும் MTTR

நம்பகத்தன்மைக்கு இரண்டு எண்கள் உள்ளன. MTBF (தோல்விகளுக்கு இடைப்பட்ட சராசரி நேரம்) முகவருக்கு: அவன் சிக்குவதற்கு முன் எத்தனை படிகளைக் கடக்கிறான். MTTR (சராசரி மீட்பு நேரம்): தோல்விக்குப் பிறகு வேலை நிலைக்குத் திரும்ப எவ்வளவு நேரம் ஆகிறது. முதல் எண் கூடும்போதும், இரண்டாவது குறையும்போதும் கிடைக்கும் தன்மை உயர்கிறது.

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

படி 3. பிழையை மலிவாக்குங்கள்

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

• சிறிய, சுத்தமான commit-கள் — ஒவ்வொரு மாற்றத்தையும் ஒரு கட்டளையில் திரும்பப் பெறலாம்.
• தனிமைப்படுத்தல் — முகவர் தனிக் கிளை அல்லது வேலைப் பிரதியில், உதாரணமாக git worktree மூலம், உற்பத்திக்கு அணுகல் இல்லாத sandbox-இல் வேலை செய்கிறது.
• சூழல் மீட்டமைப்புக் script — database, சார்புகள், சேவைகள் ஒரே கட்டளையில் பழைய நிலைக்குத் திரும்புகின்றன.

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # DB-ஐ மீண்டும் உருவாக்கு, migrations-ஐ இயக்கு, fixtures-ஐ ஏற்று

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

படி 4. பின்னூட்ட வளையத்தை மூடுங்கள்

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

• Fail-fast: சரிபார்ப்பு முதல் பிழையிலேயே தெளிவான செய்தியுடன் நின்றுவிடுகிறது, நூறு வரி இரைச்சலை வெளியிடுவதில்லை.
• ஒவ்வொரு மாற்றத்துக்குப் பின்னும் விரைவான சரிபார்ப்பு: முகவரின் hook வழியாக linter மற்றும் type check.
• மிகைமை (redundancy): அதே பண்புக்கு இரண்டாவது, சுயாதீனமான சரிபார்ப்பு — unit tests-க்கு மேல் E2E காட்சி. பச்சையான unit tests ஒரு அம்சம் பயனருக்கு வேலை செய்கிறது என்பதை நிரூபிப்பதில்லை.

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

படி 5. நினைவை கோப்புகளுக்கு மாற்றுங்கள்

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

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

படி 6. ஒரு நேரத்தில் ஒரு வேலை

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

• WIP=1 வைத்திருங்கள்: சரிபார்க்கப்பட்ட முடிவு வரை ஒரு அம்சம்.
• வேலையை அளவுக்கேற்ப வெட்டுங்கள்: ஒரு சரிபார்க்கக்கூடிய பயனர் திறன், 1–3 கோப்புகள், ஒரு நிமிடத்துக்குக் குறைவான சரிபார்ப்பு.
• «கூடவே» என்ற விஷயங்களுக்கு BACKLOG.md வைத்திருங்கள். முகவர் அருகில் ஒரு குறைபாட்டைக் கண்டால், அது backlog-இல் ஒரு வரி, தானாகத் திருத்தம் அல்ல.

படி 7. செயல்படுத்துபவரையும் சரிபார்ப்பவரையும் பிரியுங்கள்

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

படி 8. முகவரைத் தானியங்கிச் சுழற்சியில் விடுங்கள்

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

இலக்கு:      promo குறியீட்டுடன் payment E2E காட்சி கடந்து செல்கிறது
சரிபார்ப்பு: make lint && make test && make e2e
நிறுத்து:    இலக்கு அடைந்தால் அல்லது 15 முயற்சிகள் அல்லது 2 மணி நேரம் → மனிதரை அழை

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

பாதுகாப்பான தானியங்கித்தனத்துக்கான விதிகள்

• நிறுத்தும் நிபந்தனை இயந்திரத்தால் சரிபார்க்கக்கூடியதாக மட்டுமே இருக்க வேண்டும், முயற்சி மற்றும் பட்ஜெட் வரம்புகளுடன்.
• அதிகரிப்பு: சுழற்சியை நம்பக்கூடாதவற்றை (உற்பத்தி migrations, பணம், தரவு நீக்கம்) முன்கூட்டியே எழுதுங்கள்.
• வேலை சிக்கி முன்னேற்றம் உண்மையில் நின்றால், அது மனிதரிடம் ஒப்படைக்கும் சமிக்ஞை; தொடர்ந்து சுற்றக் கூடாது.
• Diffs-ஐப் படியுங்கள். சுழற்சியின் வேகம் உங்கள் வாசிப்பு வேகத்தை விட அதிகமாக இருக்கக் கூடாது, இல்லையென்றால் உங்கள் சொந்தக் குறியீட்டுத் தளம் உங்கள் புரிதலுக்கு அப்பால் போய்விடும்.

இந்தப் பாதையில் பொதுவான தவறுகள்

அறிவுறுத்தல்களை மீண்டும் எழுதத் தொடங்குவது

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

எல்லாவற்றையும் ஒரே நேரத்தில் சரிசெய்வது

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

«சோதனைகள் பச்சை» என்பதை «அம்சம் வேலை செய்கிறது» என்று நினைப்பது

முகவர் தன் சொந்தச் செயல்பாட்டைச் சரிபார்க்கும் சோதனையை எழுதலாம், தேவையை அல்ல. அத்தகைய சோதனை எப்போதும் பச்சையாகவே இருக்கும். தடுப்பு: பயனர் நிலைச் சரிபார்ப்பு (E2E காட்சி), அதை செயல்படுத்துவதற்கு முன் அல்லது சுயாதீனச் சரிபார்ப்பவர் எழுதுவது, மேலும் முகவர் தேர்ச்சி பெற சோதனையை மாற்றக் கூடாது என்ற விதி.

வேகத்துக்காகச் சரிபார்ப்பை நிறுத்துவது

மெதுவான சரிபார்ப்பு «இந்த முறை மட்டும்» என்று தவிர்க்கத் தூண்டுகிறது. நல்ல வழி அவற்றைப் பிரிப்பது: ஒவ்வொரு மாற்றத்துக்கும் பின் விரைவான linter மற்றும் type check, «முடிந்தது» என்பதற்கு முன் முழு tests மற்றும் E2E. இதனால் பின்னூட்ட வளையம் குறுகியதாக இருக்கும், வேலைக்குத் தடையாக இராது.

ablation-ஐ முதல் படியாகக் கருதுவது

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

முதிர்ச்சிப் படிக்கட்டு

சுருக்கம்

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