Harness engineering के इंटरव्यू सवाल: AI इंजीनियर के लिए 22 सवाल और जवाब

तैयारी कैसे करें

Harness engineering के इंटरव्यू आम तौर पर सामान्य से विशिष्ट की ओर जाते हैं: हार्नेस क्या है, उसके कौन-से हिस्से हैं, समस्या का निदान आप कैसे करते हैं, प्रभाव कैसे मापते हैं। इंटरव्यूकर्ता इंजीनियरिंग सोच खोजता है: मॉडल की समस्या और वातावरण की समस्या में फ़र्क करने की क्षमता, और ऐसा सत्यापन योग्य समाधान सुझाने की क्षमता। नीचे 22 सवाल और उनके जवाब हैं, विषयों के हिसाब से समूहित।

मूल बातें

1. एजेंट का हार्नेस क्या है?

हार्नेस वह पूरा वातावरण है जिसमें AI एजेंट काम करता है, मॉडल के अलावा: निर्देश, उपकरण, चलाने का वातावरण, स्थिति का भंडारण और फ़ीडबैक लूप। मॉडल फ़ैसले लेता है, और हार्नेस तय करता है कि वह क्या जानता है, क्या कर सकता है और अपने परिणाम के बारे में कैसे जानता है। एक ही मॉडल अलग-अलग हार्नेस में बहुत अलग गुणवत्ता दिखाता है।

2. Harness engineering prompt और context engineering से कैसे अलग है?

Prompt engineering एक अनुरोध के शब्दों से काम करता है, context engineering इससे कि हर कदम पर मॉडल की window में क्या जाता है। Harness engineering दोनों को शामिल करता है और वह जोड़ता है जो टेक्स्ट से हल नहीं होता: उपकरणों की पहुँच, दोहराने योग्य वातावरण, सत्रों के बीच की स्थिति और मशीन से परिणाम की जाँच।

3. हार्नेस के पाँच हिस्से बताइए।

निर्देश (AGENTS.md, CLAUDE.md, skills, दस्तावेज़), उपकरण (shell, टेस्ट, linter, ब्राउज़र, MCP), वातावरण (dependencies, runtime, Docker, worktree), स्थिति (PROGRESS.md, फ़ीचर-सूची, फ़ैसले) और फ़ीडबैक (make check, E2E, hooks, मूल्यांकक)। किसी एक हिस्से की कमी से "थोड़ा कम अच्छा" नहीं होता, बल्कि गलतियों का एक पूरा व्यवस्थित वर्ग पैदा होता है।

4. मॉडल बदलना अक्सर मदद क्यों नहीं करता?

क्योंकि कई असफलताओं का संबंध मॉडल की बुद्धि से नहीं होता। मज़बूत मॉडल ऐसी कमांड की पहुँच नहीं पाएगा जो उसे दी ही नहीं गई, बिना स्थिति की फ़ाइल के कल का सत्र याद नहीं रखेगा, और टूटे migration के बारे में नहीं जानेगा अगर उसे किसी ने चलाया नहीं। किसी टीम की परंपराएँ मॉडल अपने-आप नहीं जानता।

निदान

5. एजेंट CLAUDE.md में लिखा नियम तोड़ता है। आप क्या करेंगे?

पहले देखेंगे कि एजेंट को नियम मिल भी रहा है या नहीं: दर्जनों बिंदुओं वाली लंबी फ़ाइल ज़रूरी बात को धुंधला कर देती है। फ़ाइल को विषय-सूची तक सीमित करेंगे और विवरण शर्त पर लोड होने वाले दस्तावेज़ों में डालेंगे। अगर नियम ज़रूरी है, तो उसे चल सकने वाली जाँच में बदलेंगे: linter, टेस्ट, grep-guard या hook, ताकि उल्लंघन मशीन से दिखे, मॉडल के ध्यान पर न टिका रहे।

6. लक्षण देखकर कैसे पता करें कि कौन-सा हिस्सा टूटा है?

जाने-माने परंपरागत नियम टूटें, तो निर्देश। एजेंट "करना चाहता है, कर नहीं सकता", तो उपकरण। हर सत्र वातावरण ठीक करने से शुरू हो, तो वातावरण। नया सत्र नहीं जानता कि कहाँ रुके थे, तो स्थिति। "तैयार" और वास्तविकता मेल न खाए, तो फ़ीडबैक।

7. हार्नेस किस हिस्से से शुरू करें और क्यों?

फ़ीडबैक से। जब तक ऐसी कमांड नहीं जो मशीन से बताए कि "काम करता है या नहीं", तब तक किसी और बदलाव का असर नहीं नापा जा सकता। आगे आम तौर पर निर्देश, स्थिति, वातावरण और उपकरण आते हैं, पर क्रम अनुभव से तय होता है और इस पर निर्भर करता है कि कौन-सा हिस्सा सबसे ज़्यादा टूटा है।

8. हार्नेस के किसी एक घटक का योगदान कैसे मापें?

Ablation से: मॉडल और कामों का सेट स्थिर रखें, एक-एक हिस्सा बंद करें और गिरावट देखें। लेकिन पहले असफलताओं का लॉग परतों के हिसाब से बनाएँ, वह अड़चन जल्दी दिखाता है। शून्य गिरावट का मतलब यह नहीं कि घटक बेकार है: हो सकता है चुने हुए काम उसे छूते ही न हों, या वह किसी और घटक की भरपाई कर रहा हो।

निर्देश और context

9. अच्छी AGENTS.md कैसी बनती है?

पाठ्यपुस्तक की तरह नहीं, रूटर की तरह: प्रोजेक्ट क्या है, कैसे चलाएँ, कैसे जाँचें, Definition of Done, और अनिवार्य सीमाओं की छोटी सूची। विवरण अलग दस्तावेज़ों में, जिनके लिंक शर्त के साथ हों, जैसे "भुगतान से जुड़ा काम हो तो पढ़ें"। फ़ाइल invariants बताती है ("डेटा सीमा पर validate हो"), न कि पंक्ति-दर-पंक्ति implementation या libraries।

10. Subagents किसलिए होते हैं?

Context को अलग रखने के लिए। कोई बगल का काम, जैसे कोडबेस में खोज, रिव्यू या जाँच, अलग context में होता है और केवल परिणाम लौटाता है। मुख्य धारा नहीं भरती, और जाँचने वाला subagent निष्पादक का तर्क विरासत में नहीं लेता, जो ईमानदार मूल्यांकन के लिए ज़रूरी है।

11. "हार्नेस-ऋण" (harness debt) क्या है?

हार्नेस और वास्तविकता के बीच जमा हुआ अंतर: पुराने नियम, ऐसी कमांड जो अब नहीं चलतीं, ऐसे मॉड्यूल के दस्तावेज़ जो अब हैं ही नहीं। यह तकनीकी ऋण की तरह चुपचाप जमा होता है और एजेंट की विफलताओं के रूप में चुकाया जाता है। हार्नेस की नियमित समीक्षा करनी होती है, एक बार बनाकर छोड़ना नहीं।

स्थिति और सत्र

12. एजेंट की सत्रों के बीच की "भूलने" की समस्या से कैसे निपटें?

स्थिति रिपॉज़िटरी में रखें: PROGRESS.md (स्थिति, किया गया, रुकावटें, अगले कदम), DECISIONS.md (फ़ैसला, कारण, ख़ारिज विकल्प), स्थिति वाली फ़ीचर-सूची, और बार-बार commits। निर्देशों में शुरुआत का क्रम तय करें: प्रगति पढ़ें, वातावरण की जाँच स्क्रिप्ट चलाएँ, सक्रिय फ़ीचर उठाएँ।

13. WIP=1 का नियम क्यों?

जब एजेंट एक साथ कई फ़ीचर शुरू करता है, तो स्थिति बिखर जाती है: कोई पूरा नहीं होता, बदलाव आपस में मिल जाते हैं, rollback कठिन हो जाता है। एक सक्रिय फ़ीचर साफ़ जाँच-बिंदु, साफ़ commits और विफलता के बाद सरल वापसी देता है।

14. "कोल्ड स्टार्ट टेस्ट" क्या है?

यह जाँचना कि क्या नया सत्र, बिना किसी इंसानी इशारे के, बुनियादी सवालों के जवाब दे सकता है: यह कौन-सा प्रोजेक्ट है, कहाँ रुके थे, कौन-सा फ़ीचर सक्रिय है, यह कैसे जाँचें कि सब ठीक है। अगर एजेंट फ़ाइलों से बिना अंदाज़े के जवाब देता है, तो स्थिति वाला हिस्सा काम कर रहा है।

सत्यापन

15. हरे unit tests यह क्यों साबित नहीं करते कि फ़ीचर काम करता है?

Unit test एक module को अलग करता है और निर्भरताएँ mock करता है, इसलिए वह जोड़ों को नहीं देखता: इंटरफ़ेस का मेल न खाना, स्थिति का फैलना (schema बदला, cache पुराना है), संसाधनों का लीक होना, configuration और वातावरण की समस्याएँ। Unit tests जो बग पकड़ते हैं, वे integration tests द्वारा पकड़े जाने वाले बगों का उपसमूह हैं, और वे भी E2E द्वारा पकड़े जाने वाले बगों का उपसमूह हैं।

16. verification gap क्या है और उसे कैसे गिनें?

उन कामों का अनुपात जिन्हें एजेंट ने तैयार बताया, पर स्वतंत्र जाँच ने पुष्टि नहीं की। पीछे के 10 काम लें और हर एक पर दोनों तथ्य दर्ज करें। यह मेट्रिक एक आधार-रेखा देती है: हार्नेस बदलने के बाद उसी तरह के कामों पर इसे फिर से गिना जाता है।

17. एजेंट के लिए Definition of Done कैसे लिखें?

AGENTS.md में, जाँचे जा सकने वाले बिंदुओं की सूची के रूप में: जाँच की कमांड कोड 0 पर पूरी हुईं, फ़ीचर के लिए E2E मौजूद है, migrations लागू होते हैं, प्रगति अपडेट है। उपयोगी है यह भी स्पष्ट लिखना कि क्या तैयारी नहीं मानी जाएगी: "सही दिखता है", "unit tests पास हैं", "मेरे लोकल पर चल रहा है"।

18. एजेंट ख़ुद "तैयार" का निशान क्यों न लगाए?

मॉडल अपने काम का मूल्यांकन बढ़ा-चढ़ाकर करने को झुकता है, और यह आत्म-मूल्यांकन उसी context में होता है जिसमें फ़ैसला लिया गया था। passing का निशान सत्यापन स्क्रिप्ट लगाए, परिणामों के आधार पर, और commit hash को सबूत के रूप में दर्ज करे।

19. स्वतंत्र मूल्यांकक कैसे बनाएँ?

एक अलग एजेंट या सत्र, जो केवल आवश्यकता, diff और जाँच के परिणाम देखे, पर निष्पादक का तर्क नहीं। वह रूब्रिक पर आँकता है (सही होना, आर्किटेक्चर, टेस्ट, त्रुटि-प्रबंधन), और हर आकलन फ़ाइल, पंक्ति या लॉग का हवाला देता है। बेहतर है कि मूल्यांकक दूसरा मॉडल हो, ताकि अंधी जगहें एक-सी न हों।

20. आर्किटेक्चर का नियम चलने योग्य कैसे बनाएँ?

तीन स्तर: grep-guard (तेज़, pattern से), import graph समझने वाला linter नियम (import-linter, dependency-cruiser) और CI में आर्किटेक्चर टेस्ट। तीनों make check में जुड़ते हैं, गैर-शून्य कोड पर विफल होते हैं और WHY तथा FIX छापते हैं, ताकि एजेंट उल्लंघन ख़ुद ठीक करे। नई जाँच जोड़ने का ट्रिगर है: रिव्यू में एक ही टिप्पणी दूसरी बार आना।

स्वायत्त काम

21. एजेंट को घंटों काम पर छोड़ने के लिए क्या चाहिए?

एक स्पष्ट लक्ष्य, एक मोनोटोनिक प्रगति मेट्रिक (जैसे passing फ़ीचरों की संख्या), प्रति फ़ीचर समय और प्रयासों का बजट, गिरावट होने पर स्वचालित rollback, और इंसान के लिए सूची: migrations, infrastructure, पैसा। साथ में अलगाव: sandbox या अलग git worktree, ताकि गलती कार्यकारी वातावरण तक न पहुँचे।

22. एक एजेंट-चक्र कब काफ़ी नहीं होता, और भूमिकाओं का ग्राफ़ कैसे बनाएँ?

जब निष्पादक ख़ुद अपनी जाँच करने लगता है और अटक जाता है। तब काम को भूमिकाओं में बाँटा जाता है: कार्यान्वयन, रिव्यू, टेस्ट, merge। रिव्यू को साफ़ context और रूब्रिक मिलता है, और merge केवल तब होता है जब review == pass। रिव्यू फ़ेल हो तो फ़ीचर कार्यान्वयन पर लौटता है, और कई असफलताओं के बाद उसे साफ़ context से दोबारा शुरू किया जाता है, क्योंकि तब समस्या कोड में नहीं, काम की समझ में होती है।

निष्कर्ष

Harness engineering के इंटरव्यू में वही उत्तर सबसे मज़बूत होता है जो सत्यापन योग्य हो: कौन-सी फ़ाइलें, कौन-सी कमांड, कौन-सा मेट्रिक। मन में रखें पाँच हिस्से, verification gap और यह नियम कि तैयारी का निशान स्क्रिप्ट लगाए। ये सारे विषय एक असली परियोजना पर, एक ही हार्नेस में जोड़कर, व्यावहारिक पाठ्यक्रम में सिखाए जाते हैं।