தன்னாட்சி AI முகவர்: பல மணி நேரம் வேலை செய்ய முகவரை எப்படி விடுவது, குப்பை வராமல் தடுப்பது எப்படி

தன்னாட்சி AI முகவர் என்றால் என்ன, அது சாதாரண கோரிக்கையிலிருந்து எப்படி வேறுபடுகிறது

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

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

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

பணி தன்னாட்சி முகவருக்கு ஏற்றதா

முதல் கேள்வி: வேலைக்கு இயந்திரத்தால் சரிபார்க்கக்கூடிய முடிவுக் கோடு இருக்கிறதா. «tests/payments அடைவில் உள்ள அனைத்து சோதனைகளும் தேறுகின்றன», «பட்டியலில் உள்ள அனைத்து அம்சங்களும் passing நிலையில் உள்ளன», «அளவீடு அடிப்படை நிலையை விட உயர்ந்துள்ளது» — இவை பொருந்தும். «குறியீட்டை இன்னும் சிறப்பாக்கு» அல்லது «payments-ஐ தொடர்ந்து மேம்படுத்து» — பொருந்தாது: அத்தகைய இலக்குக்கு முடிவே இல்லை, பட்ஜெட் தீரும் வரை சுழற்சி ஓடிக்கொண்டே இருக்கும்.

நான்கு வகை சுழற்சிகளை வேறுபடுத்திப் பார்ப்பது பயனுள்ளது:

• படிப்படியானது — ஒவ்வொரு prompt-ஐயும் நீங்களே கொடுக்கிறீர்கள்; இது வழக்கமான ஊடாடும் வேலை.
• இலக்கு வாரியானது — இலக்கை நீங்கள் கொடுக்கிறீர்கள், தனிச் சரிபார்ப்போ பட்ஜெட்டோ நிறுத்துகிறது. பல மணி நேர தன்னாட்சி முகவர் இதுதான்.
• நேர வாரியானது — அட்டவணைப்படி தொடங்கும் (எடுத்துக்காட்டாக, காலை CI தோல்விகளின் ஆய்வு), நிறுத்துவது கைமுறையாக.
• நிகழ்வு வாரியானது — வெளி தூண்டுதல் (புதிய issue, தோல்வியுற்ற deploy) இயக்கும்; நிகழ்வின் செயலாக்கமோ மறுமுயற்சி வரம்போ நிறுத்தும்.

அடிக்கடி நிகழும் தவறு: நேர வாரியான சுழற்சியையும் இலக்கு வாரியான சுழற்சியையும் குழப்புவது — «ஒவ்வொரு 10 நிமிடத்துக்கும் payments-ஐத் தொடர்ந்து செய்». அட்டவணைச் சுழற்சி ஒவ்வொரு முறையும் அறிவுறுத்தலை முதலிலிருந்து தொடங்கும், என்ன ஏற்கனவே செய்யப்பட்டது என்பது அதற்குத் தெரியாது. பணிக்கு முடிவு இருந்தால், முன்னேற்ற நினைவுடன் கூடிய இலக்கு வாரியான சுழற்சி தேவை.

படி 1. Sandbox: முகவர் எங்கே உடைக்கலாம்

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

• தனி வேலை நகல். git worktree முகவருக்கு அதே களஞ்சியத்தின் மேல் தனி அடைவையும் தனி கிளையையும் கொடுக்கிறது. முதன்மைக் கிளை தொடப்படுவதில்லை, பல முகவர்கள் ஒன்றையொன்று தடுப்பதில்லை, தோல்வியுற்ற ஓட்டத்தை ஒரே கட்டளையில் நீக்கலாம்.
• Container அல்லது மெய்நிகர் இயந்திரம். கட்டளைகளுக்கு முழு அணுகல் முகவருக்கு தேவைப்பட்டால், வீட்டு அடைவு, சாவிகள், உற்பத்தி தரவுத்தளங்கள் அணுக முடியாத container-இல் இயக்குங்கள்.
• சோதனைத் தரவு. உள்ளூர் தரவுத்தளம், கட்டண அமைப்புகளின் sandbox, போலி சாவிகள். முகவரின் சூழலில் ஒரு உற்பத்தி ரகசியம் கூட இருக்கக்கூடாது.

# தன்னாட்சி ஓட்டத்துக்கு தனி கிளையும் அடைவும்
git worktree add ../shop-agent -b agent/f03-refunds

# ஓட்டத்துக்குப் பின்: முடிவைப் பார்க்க அல்லது நீக்க
git -C ../shop-agent log --oneline main..
git worktree remove ../shop-agent

படி 2. அனுமதிகள்: பணிக்குத் தேவையான குறைந்தபட்சம்

முகவர் தனியாக எவ்வளவு நேரம் வேலை செய்கிறதோ, அவ்வளவு குறுகலாக அதன் அனுமதிகள் இருக்க வேண்டும். Claude Code-இல் அனுமதிகள் settings.json-இல் அமைக்கப்படுகின்றன (கருவிகள் மற்றும் கட்டளைகளுக்கான allow மற்றும் deny பட்டியல்கள்): பணிக்குத் தேவையானவற்றை வெளிப்படையாக அனுமதியுங்கள் — சோதனைகள், linter, வேலை நகலில் கோப்பு திருத்தம் — ஆபத்தானவற்றைத் தடுங்கள்: முதன்மைக் கிளைக்கு push, ரகசியங்களுடன் வேலை, தேவையில்லாத நெட்வொர்க் கட்டளைகள்.

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

மீற முடியாத தடைகளை உரையால் அல்ல, பொறிமுறையால் வலுப்படுத்துங்கள். அறிவுறுத்தலில் «migrations/-ஐ தொடாதே» என்று எழுதியிருப்பது ஒரு விருப்பம்; அந்த அடைவில் திருத்தத்தைத் தடுக்கும் hook அல்லது கோப்பு முறைமை அனுமதிகள் ஒரு உத்தரவாதம்.

படி 3. இலக்கு, சரிபார்ப்பு, நிறுத்தம் — தொடங்குவதற்கு முன் மூன்று வரிகள்

எளிய வேலை சுழற்சி மூன்று விஷயங்களின் மேல் நிற்கிறது. அவற்றை ஓட்டத்தின் நடுவில் அல்ல, தொடங்குவதற்கு முன்பே எழுதி வையுங்கள்:

1. இலக்கு — இறுதி நிலை எப்படி இருக்கும்.
2. சரிபார்ப்பு — இலக்கு அடையப்பட்டதை இயந்திரம் உறுதிசெய்யும் வழி: வெற்றி அல்லது தோல்வியைத் திருப்பும் கட்டளை.
3. நிறுத்த நிபந்தனை — முயற்சிகள், நேரம் அல்லது பணத்தின் வரம்பு; இலக்கு அடையப்படாவிட்டாலும் அதைத் தாண்டியதும் சுழற்சி நின்றுவிடும்.

இதை மனிதர் மட்டுமே திருத்தும் தனி methodology கோப்பில் வைத்துக்கொள்வது வசதியானது. பணம் செலுத்தும் backend-க்கான எடுத்துக்காட்டு:

# program.md — தன்னாட்சி ஓட்டத்தின் methodology

## இலக்கு
.agent/feature_list.json-இல் உள்ள அனைத்து அம்சங்களும் passing நிலையில் இருக்க வேண்டும்.

## அளவீடு
passing அம்சங்களின் எண்ணிக்கை. அது ஒருபோதும் குறையக்கூடாது. பின்னடைவு = உடனடி திரும்பப்பெறுதல்.

## கட்டுப்பாடுகள்
- ஒரே நேரத்தில் ஒரு அம்சம் மட்டும் வேலையில்.
- migrations/ மற்றும் infra/-ஐ மாற்றக்கூடாது.
- பதிவு இல்லாமல் சார்புகளைத் (dependencies) தொடக்கூடாது.

## வேலை வரிசை
1. passing அல்லாத முதல் அம்சத்தை எடு.
2. செயல்படுத்து, pytest மற்றும் linter-ஐ இயக்கு.
3. பச்சையானால் commit செய் மற்றும் .agent/progress.md-இல் பதிவு செய். சிவப்பானால் சரி செய்.

## நிறுத்தம் மற்றும் அழைத்தல்
- ஓர் அம்சத்துக்கு 3 தோல்வியுற்ற முயற்சிகள் — blocked எனக் குறித்து அடுத்ததுக்குச் செல்.
- மீதமுள்ள அனைத்தும் blocked ஆனால் — நின்று அறிக்கை எழுது.
- வாடிக்கையாளர் பணம், அணுக்க உரிமைகள், தரவு நீக்கம் பற்றிய எந்தப் பணியும் — செய்யாதே, மனிதனிடம் ஒப்படை.

படி 4. சரிபார்த்து-திருத்தும் சுழற்சி, வட்டில் நினைவுடன்

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

நல்ல மாதிரி — «ஒரு திசையில் மட்டுமே நகரும் ratchet», இரவு முழுவதும் முகவர் நூற்றுக்கணக்கான ML சோதனைகளை நடத்தும் Andrej Karpathy-இன் autoresearch திட்டத்தில் உள்ளது. ஒவ்வொரு மறு செய்கையிலும்: methodology-ஐப் படி, ஒரு கருதுகோளை முன்வை, மாற்றம் செய், நிலையான நேர பட்ஜெட்டுடன் சோதனையை ஓட்டு, அடிப்படை நிலையுடன் ஒப்பிடு. மேம்பட்டால் commit, மேம்படாவிட்டால் திரும்பப்பெறு. முடிவு பதிவில் எழுதப்படும், பின்னர் அடுத்த கருதுகோள்.

இந்த அமைப்பிலிருந்து இரண்டு முடிவுகளை எடுத்துக்கொள்ளுங்கள்:

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

அதே அமைப்பில் கோப்புகள் வழியாகப் பாத்திரப் பிரிவும் தெரிகிறது: உள்கட்டமைப்பையும் மதிப்பீட்டையும் யாரும் மாற்றுவதில்லை, பரிசோதனைக் குறியீட்டை முகவர் மட்டும் மாற்றும், methodology-ஐ மனிதர் மட்டும் மாற்றுவார். அளவீட்டு முறையை மாற்றி முடிவை «மேம்படுத்த» முகவரால் முடியாது.

படி 5. முடிந்ததா என்று யார் தீர்மானிப்பது: தனி மதிப்பீட்டாளர்

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

உருவாக்குபவரையும் மதிப்பீட்டாளரையும் பிரிக்கும் விதிகள்:

• வேலையைச் செய்த அமர்வு மதிப்பிடக்கூடாது. Claude Code-இல் இதற்கு subagent வசதியானது: ஒவ்வொன்றுக்கும் தனி context உண்டு.
• மதிப்பீட்டாளர் சுத்தமான context-ஐப் பெறுகிறது: தேவை, diff மற்றும் சோதனை முடிவுகள் — செயல்படுத்துபவரின் நியாயங்கள் எதுவும் இல்லை.
• முடிந்தால் மதிப்பீட்டாளர் வேறு மாதிரி, குறைந்தபட்சம் வேறு பாத்திரத்துடன் கூடிய வேறு prompt.
• தீர்ப்பு ஒரு rubric-இன்படி வழங்கப்படுகிறது, ஒவ்வொரு உருப்படியும் ஆதாரத்தைக் குறிக்கிறது: சோதனையின் வரி, கட்டளையின் வெளியீடு, diff-இல் உள்ள இடம்.

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

நிறுத்தும் நிபந்தனைகள்: முகவர் எப்போது கைவிட வேண்டும்

நிறுத்தும் நிபந்தனைகள் இல்லாத சுழற்சி சுற்றிச் சுற்றி வரும் — அது நேரப் பிரச்சினை. குறைந்தபட்ச தொகுப்பு:

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

தன்னாட்சி முகவரின் உடனே தெரியாத அபாயங்கள்

வெளிப்படையான அபாயங்கள் — நீக்கப்பட்ட கோப்புகள், உடைந்த build — sandbox-உம் அனுமதிகளும் தடுத்துவிடும். ஆனால் வாரங்களில் குவியும் அமைதியான செலவுகள் இன்னும் ஆபத்தானவை:

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

ஒரு மாலையில் முதல் தன்னாட்சி சுழற்சியை எப்படி தொடங்குவது

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

1. வாரத்துக்கு குறைந்தது இரண்டு முறை கைமுறையாகச் செய்யும், இயந்திரத்தால் சரிபார்க்கக்கூடிய முடிவுள்ள ஒரு பணியைத் தேர்ந்தெடுங்கள்.
2. இலக்கு, சரிபார்ப்பு, நிறுத்த நிபந்தனையை எழுதுங்கள் — மூன்று வரிகள்.
3. தனி worktree உருவாக்கி அனுமதிகளை அமையுங்கள்: சோதனைகளும் கோப்புத் திருத்தமும் அனுமதி, push மற்றும் ரகசியங்கள் இல்லை.
4. முன்னேற்றக் கோப்பை உருவாக்கி ஒவ்வொரு மறு செய்கைக்குப் பின்னும் அதைப் புதுப்பிக்கச் சொல்லுங்கள்.
5. பாத்திரங்களைப் பிரியுங்கள்: செயல்படுத்துபவர் எழுதுகிறார், தனி context-இல் உள்ள சரிபார்ப்பவர் diff-ஐ மதிப்பிடுகிறார்.
6. மொத்த வரம்பை வையுங்கள், முதல் முறை காலையில் அல்ல, ஒரு மணி நேரத்தில் முடிவைச் சரிபாருங்கள்.

முடிவு

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