Harness engineering நேர்காணல் கேள்விகள்: AI பொறியாளருக்கான 22 கேள்விகளும் பதில்களும்

எப்படித் தயாராவது

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

அடிப்படைகள்

1. Agent harness என்றால் என்ன?

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

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

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

3. Harness-இன் ஐந்து கூறுகளைக் கூறுங்கள்.

வழிகாட்டல் (AGENTS.md, CLAUDE.md, skills, ஆவணங்கள்), கருவிகள் (shell, tests, linter, browser, MCP), சூழல் (சார்புகள், runtime, Docker, worktree), நிலை (PROGRESS.md, அம்சப் பட்டியல், முடிவுகள்), பின்னூட்டம் (make check, E2E, hooks, மதிப்பீட்டாளர்). ஒரு கூறு இல்லாதது «சற்று மோசமான முடிவு» அல்ல, ஒரு முழு வகை அமைப்பு தோல்விகள்.

4. வலிமையான மாதிரிக்கு மாற்றுவது ஏன் பெரும்பாலும் உதவுவதில்லை?

ஏனெனில் பல தோல்விகள் மாதிரியின் நுண்ணறிவிலிருந்து வருவதில்லை. வலிமையான மாதிரி இல்லாத கட்டளைக்கு அணுகல் பெறாது, நிலைக் கோப்பு இல்லாமல் நேற்றைய அமர்வை நினைவில் வைக்காது, இயக்கப்படாத உடைந்த migration பற்றி அறியாது. குறிப்பிட்ட குழுவின் மரபுகளையும் மாதிரி ஊகிக்க முடியாது.

நோயறிதல்

5. CLAUDE.md-இல் எழுதப்பட்ட விதியை முகவர் மீறுகிறது. நீங்கள் என்ன செய்வீர்கள்?

முதலில் முகவரால் அந்த விதியைக் கண்டுபிடிக்க முடிகிறதா என்று பாருங்கள்: பத்துக்கும் மேற்பட்ட புள்ளிகள் கொண்ட நீண்ட கோப்பு முக்கியமானதை மங்கச் செய்கிறது. நுழைவுக் கோப்பை அட்டவணையாகச் சுருக்குங்கள், விவரங்களை நிபந்தனையின் பேரில் ஏற்றப்படும் ஆவணங்களுக்கு நகர்த்துங்கள். விதி முக்கியமானதாக இருந்தால் அதை இயக்கக்கூடிய சரிபார்ப்பாக மாற்றுங்கள் — linter, test, grep-guard அல்லது hook — அதனால் மீறல் இயந்திரத்தால் தெரியும், மாதிரியின் கவனத்தைச் சார்ந்திருக்காது.

6. அறிகுறிகளிலிருந்து எந்தக் கூறு உடைந்துள்ளது என்று எப்படி அறிவீர்கள்?

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

7. Harness எந்தக் கூறுடன் தொடங்க வேண்டும், ஏன்?

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

8. ஒரு harness கூறின் பங்களிப்பை எப்படி அளப்பீர்கள்?

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

வழிகாட்டல் மற்றும் சூழல்

9. நல்ல AGENTS.md-ஐ எப்படி அமைப்பீர்கள்?

பாடநூலாக அல்ல, ரௌட்டராக: திட்டம் என்ன, எப்படி இயக்குவது, எப்படிச் சரிபார்ப்பது, Definition of Done, கட்டாய வரம்புகளின் சிறிய பட்டியல். விவரங்கள் «பணம் தொட்டால் படி» போன்ற இணைப்புகளுடன் தனி ஆவணங்களில். கோப்பு மாறாத நியதிகளை நிர்ணயிக்கிறது («தரவு எல்லையில் சரிபார்க்கப்படுகிறது»), வரிக்கு வரி செயலாக்கத்தையோ நூலகங்களையோ கட்டளையிடுவதில்லை.

10. Subagents எதற்காக?

சூழல் தனிமைப்படுத்தலுக்காக. பக்கப் பணிகள் — குறியீட்டுத் தளத்தில் தேடுதல், review, சரிபார்ப்பு — தனிச் சூழலில் நடந்து வெளியீட்டை மட்டும் திருப்பித் தருகின்றன. முதன்மை ஓட்டம் மாசுபடாது, சரிபார்ப்பு subagent செயல்படுத்துபவரின் வாதங்களை வாரிசாகப் பெறாது, இது நேர்மையான மதிப்பீட்டுக்கு முக்கியம்.

11. Harness debt என்றால் என்ன?

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

நிலை மற்றும் அமர்வுகள்

12. அமர்வுகளுக்கு இடையே முகவரின் மறதியை எப்படிச் சமாளிப்பீர்கள்?

நிலையை களஞ்சியத்தில் சேமியுங்கள்: PROGRESS.md (எங்கே உள்ளது, என்ன முடிந்தது, தடைகள், அடுத்த படிகள்), DECISIONS.md (முடிவு, காரணம், நிராகரித்த விருப்பங்கள்), நிலையுடன் கூடிய அம்சப் பட்டியல், அடிக்கடி commit-கள். வழிகாட்டலில் தொடக்க வரிசையை நிர்ணயியுங்கள்: முன்னேற்றத்தைப் படியுங்கள், சூழல் சரிபார்ப்பு script-ஐ இயக்குங்கள், செயலில் உள்ள அம்சத்தை எடுங்கள்.

13. WIP=1 விதி ஏன்?

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

14. Cold start சோதனை என்றால் என்ன?

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

சரிபார்ப்பு

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

Unit test ஒரு தொகுதியைத் தனிமைப்படுத்தி சார்புகளை போலியாக்குகிறது, எனவே இணைப்புகளைப் பார்ப்பதில்லை: இடைமுகப் பொருத்தமின்மை, நிலை பரவுதல் (schema மாறியது, cache பழையது), வள கசிவுகள், அமைப்பு மற்றும் சூழல் சிக்கல்கள். Unit பிடிக்கும் குறைபாடுகள் integration பிடிக்கும் குறைபாடுகளின் துணைக்குழு, அவை E2E பிடிக்கக்கூடியவற்றின் துணைக்குழு.

16. Verification gap என்றால் என்ன, அதை எப்படிக் கணக்கிடுவீர்கள்?

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

17. முகவருக்கான Definition of Done-ஐ எப்படி எழுதுவீர்கள்?

AGENTS.md-இல், சரிபார்க்கக்கூடிய புள்ளிகளின் பட்டியலாக: சரிபார்ப்புக் கட்டளைகள் குறியீடு 0 உடன் முடிகின்றன, காட்சிக்கு E2E உள்ளது, migrations பயன்படுத்தப்படுகின்றன, முன்னேற்றம் புதுப்பிக்கப்பட்டுள்ளது. எது முடிந்ததாகக் கருதப்படாது என்பதையும் தெளிவாகக் குறிப்பிடுவது பயனுள்ளது: «சரியாகத் தெரிகிறது», «unit tests கடந்து செல்கின்றன», «என்னிடம் வேலை செய்கிறது».

18. முகவர் ஏன் தானே «முடிந்தது» நிலையை அமைக்கக் கூடாது?

மாதிரி தன் வேலையின் மதிப்பீட்டை மிகைப்படுத்த முனைகிறது, சுய மதிப்பீடு முடிவு எடுக்கப்பட்ட அதே சூழலில் நடக்கிறது. Passing நிலையை சரிபார்ப்பு script தர வேண்டும், கட்டளை ஓட்டங்களின் முடிவுகளின் அடிப்படையில், ஆதாரமாக commit hash-ஐப் பதிவு செய்து.

19. சுயாதீன மதிப்பீட்டாளரை எப்படி அமைப்பீர்கள்?

தேவை, diff, சரிபார்ப்பு முடிவுகளை மட்டும் பார்க்கும் தனி முகவர் அல்லது அமர்வு, செயல்படுத்துபவரின் பகுத்தறிவைப் பார்க்காது. அது ஒரு rubric-இன் அடிப்படையில் மதிப்பிடுகிறது (சரியான தன்மை, கட்டமைப்பு, tests, பிழை கையாளுதல்), ஒவ்வொரு மதிப்பீடும் ஒரு கோப்பு, வரி அல்லது பதிவுடன் இணைகிறது. இரண்டின் குருட்டுப் புள்ளிகளும் ஒன்றாக இல்லாதபடி வேறு மாதிரியைப் பயன்படுத்துவது சிறந்தது.

20. ஒரு கட்டமைப்பு விதியை இயக்கக்கூடிய சரிபார்ப்பாக எப்படி மாற்றுவீர்கள்?

மூன்று நிலைகளில்: guard grep (வேகமானது, வடிவத்தின் அடிப்படையில்), இறக்குமதி வரைபடத்தைப் புரிந்துகொள்ளும் linter விதி (import-linter, dependency-cruiser), CI-இல் கட்டமைப்பு test. அனைத்தும் make check-இல் சேர்க்கப்படுகின்றன, பூஜ்யமல்லாத குறியீட்டில் தோல்வியடைகின்றன, முகவர் மீறலைத் தானே சரிசெய்ய WHY மற்றும் FIX அச்சிடுகின்றன. புதிய சரிபார்ப்புக்கான தூண்டுதல்: அதே review கருத்து இரண்டாவது முறை வந்தால்.

தானியங்கி வேலை

21. முகவரை மணிக்கணக்கில் வேலை செய்ய விடுவதற்கு என்ன தேவை?

தெளிவற்ற இலக்கு, ஒரே திசையில் உயரும் முன்னேற்ற அளவீடு (உதாரணமாக passing அம்சங்களின் எண்ணிக்கை), ஒரு அம்சத்துக்கான நேரம் மற்றும் முயற்சிகளின் பட்ஜெட், regression ஏற்பட்டால் தானியங்கி rollback, மனிதர் தேவைப்படும் செயல்களின் பட்டியல்: migrations, உள்கட்டமைப்பு, பணம். அத்துடன் தனிமைப்படுத்தல்: தனி sandbox அல்லது git worktree, பிழை வேலைச் சூழலைத் தொடாமல் இருக்க.

22. ஒரு முகவர் சுழற்சி எப்போது போதாது, பாத்திரங்களின் வரைபடத்தை எப்படி அமைப்பீர்கள்?

செயல்படுத்துபவர் தன்னைத்தானே சரிபார்க்கத் தொடங்கி சிக்கிக்கொள்ளும்போது. அப்போது பணி பாத்திரங்களாகப் பிரிக்கப்படுகிறது: செயல்படுத்தல், review, tests, merge. Review-க்கு சுத்தமான சூழலும் rubric-உம் கிடைக்கின்றன, review == pass ஆகும்போது merge-ஐ குறியீடு செய்கிறது. Review தோல்வியடைந்தால் அம்சம் செயல்படுத்தலுக்குத் திரும்புகிறது, பல முறை தோல்வியடைந்தால் சுத்தமான சூழலுடன் மீண்டும் தொடங்குகிறது — அதாவது பிரச்சினை பணியைப் புரிந்துகொள்வதில், குறியீட்டில் அல்ல.

சுருக்கம்

Harness engineering நேர்காணலில் மிகச் சிறந்த பதில் சரிபார்க்கக்கூடியவற்றைப் பற்றிப் பேசுவது: எந்தக் கோப்பு, எந்தக் கட்டளை, எந்த அளவீடு. ஐந்து கூறுகள், verification gap, «தயார்நிலையை script தீர்மானிக்கிறது» என்ற விதியை மனதில் வையுங்கள். இந்த விஷயங்கள் அனைத்தும் பாடநெறியின் ஒரு திட்டத்தில் ஒரு முழு harness-ஆக ஒன்றிணைகின்றன.