Harness engineering என்றால் என்ன: AI முகவரை பயனுள்ள வேலைக் கருவியாக மாற்றுவது எப்படி

எளிய மொழியில் harness engineering

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

மிகச் சுருக்கமான சூத்திரம் இதுவே:

Agent = Model + Harness

Model என்பது எடைகள் மற்றும் பகுத்தறியும், உரை அல்லது குறியீடு எழுதும் திறன். Harness என்பது மற்றவை அனைத்தும்: system அறிவுறுத்தல்கள் மற்றும் CLAUDE.md அல்லது AGENTS.md போன்ற கோப்புகள், கருவித் தொகுப்பு (shell, கோப்பு திருத்தம், MCP சேவையகங்கள்), முகவர் கட்டளைகளை இயக்கும் sandbox, அமர்வுகளுக்கு இடையிலான நிலைக் கோப்புகள், முகவருக்குப் பிழைகளைத் தெரிவிக்கும் tests, linter மற்றும் hooks. Harness-ஐ அகற்றினால் எஞ்சுவது உரையால் மட்டுமே பதிலளிக்கக்கூடிய ஓர் அரட்டை.

முகவர் ஏன் சில நேரம் «மூத்தவர்», சில நேரம் «இளையவர்»

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

இங்கிருந்துதான் harness engineering-இன் முக்கியச் சிந்தனை தொடங்குகிறது: முகவர் உடைந்ததில்லை — அதைச் சுற்றியுள்ளது உடைந்துள்ளது. அணுகல் இல்லாவிட்டால் முகவரால் tests-ஐ இயக்க முடியாது. எங்கும் பதிவு செய்யப்படாததை அவன் நினைவில் வைத்திருக்க மாட்டான். எந்தச் சரிபார்ப்பும் சொல்லாவிட்டால் அம்சம் உடைந்துள்ளது என்பதை அவன் அறிய மாட்டான். இது மாதிரியின் «குணம்» அல்ல, வடிவமைப்புக் குறைபாடு; அத்தகைய குறைபாடுகளை முறையாகச் சரிசெய்யலாம்.

மோசமான harness-இன் அறிகுறிகள்

• ஒவ்வொரு புதிய அமர்வும் சூழலைச் சரிசெய்வதில் தொடங்குகிறது: தவறான சார்புகள், database தொடங்கவில்லை, variables இல்லை.
• முகவர் முன்பு நிராகரிக்கப்பட்ட தீர்வுகளையே மீண்டும் தேர்ந்தெடுக்கிறது, ஏனெனில் முந்தைய அமர்வு அவனுக்கு நினைவில் இல்லை.
• விதி அறிவுறுத்தல்களில் தெளிவாக எழுதப்பட்டுள்ளது, ஆனால் முகவர் அதைப் பின்பற்றுவதில்லை.
• «Tests பச்சையாக உள்ளன», ஆனால் அம்சம் உடைந்துள்ளது, ஏனெனில் tests தவறான விஷயத்தைச் சரிபார்த்தன.
• முகவர் மூன்று வேலைகளை ஒரே நேரத்தில் எடுத்துக்கொள்கிறது, எதையும் முடிப்பதில்லை.

Harness-இல் என்ன உள்ளது: ஐந்து துணை அமைப்புகள்

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

வழிகாட்டல்

வழிகாட்டல் «முகவர் சரியான விதியைக் கண்டுபிடிப்பாரா?» என்ற கேள்விக்குப் பதில் சொல்கிறது. நல்ல நுழைவுக் கோப்பு ஒரு வரைபடம் போன்றது: சரிபார்ப்புக் கட்டளைகளும் கடுமையான வரம்புகளும் அடங்கிய சிறிய பட்டியல், விவரங்கள் முகவர் தேவைப்படும்போது திறக்கும் தனி ஆவணங்களில். நல்ல வழிகாட்டல் மாறாத நியதிகளை நிர்ணயிக்கிறது («எல்லா SQL வினவல்களும் parameterized»), ஒவ்வொரு வரியிலும் செயல்படுத்தலைக் கட்டளையிடுவதில்லை.

கருவிகள்

முகவர் தனக்கு அணுகல் உள்ளதை மட்டுமே சரிபார்க்க முடியும். அவனால் linter-ஐ இயக்க முடியாவிட்டால், «commit-க்கு முன் linter-ஐ இயக்கு» என்ற விதி பயனளிக்காது. கருவிகள் முகவரின் சொந்தத் திறன்கள் வழியாகவும் (கோப்புகளைப் படித்தல் மற்றும் திருத்துதல், கட்டளைகளை இயக்குதல்), database, browser மற்றும் பணிக் கண்காணிப்பானுக்கு அணுகல் தரும் MCP வழியாகவும் இணைக்கப்படுகின்றன.

சூழல்

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

நிலை

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

பின்னூட்டம்

பின்னூட்ட வளையம் மிக முக்கியமான பகுதி. அது இல்லாவிட்டால் முகவர் தனக்கே ஒரே நீதிபதி, வேலை முடிந்தது என்று நேர்மையாக நம்பிவிடுவான். Tests, type check, ஒவ்வொரு மாற்றத்திற்குப் பிறகும் இயங்கும் hook, browser-இல் E2E காட்சி — இவை அனைத்தும் பிழை இன்னும் மலிவாகச் சரிசெய்யக்கூடிய நேரத்தில் முகவருக்குச் சிவப்புச் சமிக்ஞை அனுப்புகின்றன.

Harness ஒரு பட்டியல் அல்ல, ஒரு சுழற்சி

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

அறிவுறுத்தல் → மாதிரி → கருவி → சூழல் → மாற்றம்
                ↑                              ↓
                └──── சிவப்பு ── சரிபார்ப்பு ───┘
                                     ↓ பச்சை
                                 நிலை → (அடுத்த அமர்வு)

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

Harness engineering prompt மற்றும் context engineering-இலிருந்து எவ்வாறு வேறுபடுகிறது

இந்தக் கருத்துகள் ஒன்றுக்குள் ஒன்று அடங்கியுள்ளன, போட்டியாளர்கள் அல்ல.

Prompt engineering என்பது வழிகாட்டல் பகுதியின் ஒரு அங்கம். Context engineering வழிகாட்டலையும் நிலையையும் தொடுகிறது: எந்த நேரத்திலும் முகவர் என்ன பார்க்கிறான் என்பது. Harness engineering சூழல் சாளரத்தில் சேராத விஷயங்களையும் சேர்க்கிறது: அணுகல், sandbox, tests, hooks மற்றும் வேலைமுறை. முகவரால் உடல் ரீதியாக tests-ஐ இயக்க முடியாவிட்டால் நன்றாக எழுதப்பட்ட prompt-உம் உதவாது.

Harness ஏன் தேவை: நீண்ட வேலைகளின் கணிதம்

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

0.95 ^ 10 ≈ 0.60
0.95 ^ 20 ≈ 0.36
0.95 ^ 50 ≈ 0.08

பத்தாவது படியில் ஒரு பிழையும் இல்லாமல் சுமார் 60% முயற்சிகளே வந்தடைகின்றன; ஐம்பதாவது படியில் பத்தில் ஒன்றுக்கும் குறைவு. மாதிரியின் துல்லியத்தை 97% ஆக உயர்த்துவது விலை உயர்ந்தது, அது முழுக்க உங்கள் கையில் இல்லை. ஆனால் பிழை நிகழ்ந்த அதே படியில் அதைப் பிடித்து முகவருக்குத் திருப்பி அனுப்புவது harness-இன் வேலை. பின்னூட்ட வளையம் «ஒரு பிழை அடுத்த பிழையை இழுக்கும்» சங்கிலியை, சிறிய, சரிசெய்யக்கூடிய படிகளின் சங்கிலியாக மாற்றுகிறது.

எடுத்துக்காட்டு: இரண்டு களஞ்சியங்களில் ஒரே முகவர்

பணி: FastAPI அடிப்படையிலான payment backend-இல் promo குறியீட்டின் மூலம் தள்ளுபடியைச் சேர்ப்பது.

Harness இல்லாமல்

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

Harness உடன்

திட்டத்தின் மூலத்தில் சில டஜன் வரிகள் கொண்ட AGENTS.md உள்ளது: சூழலை எப்படித் தொடங்குவது, எந்தச் சரிபார்ப்புக் கட்டளைகள் கட்டாயம், பணத்தின் கட்டமைப்பு எங்கே விவரிக்கப்பட்டுள்ளது. சூழல் docker compose up -d மூலம் தொடங்குகிறது. களஞ்சியத்தில் ஒரு திட்டக் கோப்பு உள்ளது, அதில் முடிவு நிபந்தனை: «promo குறியீட்டுடன் checkout E2E காட்சி கடந்து செல்கிறது». ஒவ்வொரு மாற்றத்திற்குப் பிறகும் hook linter மற்றும் type check-ஐ இயக்குகிறது; முடிப்பதற்கு முன் முகவர் E2E test-ஐ இயக்க வேண்டும்.

# AGENTS.md (பகுதி)
## சரிபார்ப்பு — «முடிந்தது» என்று சொல்லுவதற்கு முன் கட்டாயம்
make lint        # ruff + mypy
make test        # pytest, unit மற்றும் integration
make e2e         # checkout காட்சி

## MUST
- பணத் தொகைகள் பைசாவில் (int) கணக்கிடப்படும், ஒருபோதும் float அல்ல
- எல்லா SQL வினவல்களும் parameterized
- உற்பத்தியில் பயன்படுத்தப்பட்ட migrations-ஐ மாற்றக் கூடாது

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

எங்கிருந்து தொடங்குவது

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

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

முடிவுரை

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