आपका काम ऐसा कोड देना है जिसके काम करने की पुष्टि हो चुकी हो

• AI-सहायित development environment में कम अनुभवी इंजीनियरों द्वारा बिना सत्यापित बड़े PR सबमिट करने के मामले बढ़ रहे हैं
• डेवलपर का मुख्य काम सिर्फ कोड लिखना नहीं, बल्कि ऐसा कोड देना है जिसके काम करने का प्रमाण हो
• इसके लिए manual test और automated test के दो चरण अनिवार्य रूप से पूरे करने चाहिए
• coding agent को भी इस तरह सेट करना चाहिए कि वह अपने किए गए बदलावों को खुद verify करे
• आखिरकार ज़िम्मेदारी इंसानी डेवलपर की ही होती है, और केवल वही कोड सच में मूल्यवान है जिसमें सत्यापन के प्रमाण शामिल हों

---

बिना सत्यापित कोड सबमिट करने की समस्या

• LLM टूल्स का उपयोग करने वाले जूनियर इंजीनियरों द्वारा बहुत बड़े, बिना सत्यापित PR सबमिट करने और code review पर निर्भर रहने के उदाहरण बताए गए हैं
  • इसे असभ्य, अक्षम, और डेवलपर की ज़िम्मेदारी से बचने वाला व्यवहार कहा गया है
• सॉफ़्टवेयर इंजीनियर की भूमिका सिर्फ कोड बनाना नहीं, बल्कि ऐसा कोड देना है जिसके काम करने का प्रमाण हो
  • बिना सत्यापित कोड को reviewer पर बोझ डालने जैसा माना जाता है

कोड के काम करने को साबित करने के दो चरण

• पहला चरण manual test है, जिसमें खुद यह जांचना ज़रूरी है कि कोड सही तरह से काम कर रहा है
  • सिस्टम को शुरुआती स्थिति में सेट करना, बदलाव लागू करना, और फिर नतीजे को verify करना इस प्रक्रिया का हिस्सा है
  • terminal commands और output को code review comments में जोड़कर या screen recording video के ज़रिए इसका प्रमाण दिया जा सकता है
  • सामान्य स्थिति में काम करने की पुष्टि के बाद edge case test करके समस्याएं खोजनी चाहिए
• दूसरा चरण automated test है, जिसे LLM टूल्स की प्रगति के कारण अनिवार्य प्रक्रिया के रूप में रेखांकित किया गया है
  • बदलावों के साथ automated tests भी शामिल होने चाहिए, और अगर implementation वापस लिया जाए तो tests fail होने चाहिए
  • test लिखने की प्रक्रिया manual test जैसी ही होती है, और test harness integration की क्षमता महत्वपूर्ण है
  • सिर्फ automated tests को पर्याप्त मानकर manual test छोड़ देना गलत तरीका बताया गया है

coding agent की भूमिका और सत्यापन

• 2025 में LLM क्षेत्र का एक बड़ा रुझान coding agents की तेज़ बढ़त है, जिनमें Claude Code और Codex CLI प्रमुख उदाहरण हैं
  • ये कोड चलाकर समस्याओं को खुद ठीक कर सकते हैं
• coding agent को भी अपने बदलावों को साबित करना चाहिए, और manual तथा automated tests करने चाहिए
  • CLI tools के मामले में agent को खुद commands चलाने के लिए प्रशिक्षित किया जा सकता है, या Click के CLIRunner जैसे सिस्टम से इसे automate किया जा सकता है
  • CSS बदलावों के लिए screenshot capture के ज़रिए नतीजों की पुष्टि करने की व्यवस्था की जा सकती है
• अगर प्रोजेक्ट में पहले से tests मौजूद हैं, तो agent उन्हें बढ़ा सकता है या उन्हीं patterns का फिर से उपयोग कर सकता है
  • test code की संरचना और गुणवत्ता agent द्वारा बनाए जाने वाले tests की गुणवत्ता पर सीधे असर डालती है
  • test code के प्रति सौंदर्यबोध को senior engineer की पहचान करने वाली अहम क्षमता बताया गया है

इंसानी ज़िम्मेदारी और कोड का मूल्य

• कंप्यूटर ज़िम्मेदारी नहीं ले सकते, यह भूमिका इंसानों को ही निभानी होगी
  • LLM द्वारा बड़े patches बनाना अब अपने आप में कोई खास मूल्यवान काम नहीं रह गया है
• असली मूल्य ऐसा कोड देने में है जिसके काम करने का प्रमाण हो
  • PR सबमिट करते समय यह दिखाने वाले प्रमाण ज़रूर शामिल होने चाहिए कि कोड सही तरह से काम करता है

[tested]

वाइब इंजीनियरिंग

[ethanhur]

मैं इससे बहुत सहमत हूँ। मौजूदा PR-आधारित कोड की जिम्मेदारी maintainer और reviewer पर डाल दी जाती है। बिना review किए गए LLM कोड को submit करने वाले व्यक्ति के लिए कोई disadvantage नहीं है।

Google codebase में contribute करके देखें तो contributor के credit जैसी चीज़ें मापी जाती हैं, और लगता है कि दूसरे open source प्रोजेक्ट्स / कंपनियाँ भी ऐसी चीज़ें अपनाने लगेंगी। मुझे लगता है कि trust और भी ज़्यादा महत्वपूर्ण asset बन जाएगा।

[roxie]

ओह, तो Google ऐसा कॉन्सेप्ट इस्तेमाल करता है।

[GN⁺]

Hacker News की राय

• हाल में एक निराशाजनक किस्सा बार-बार दिख रहा है। LLM टूल्स से ताकत पाए जूनियर इंजीनियर बड़े, बिना टेस्ट किए हुए PR अपने सहकर्मियों या open source maintainers के पास फेंक देते हैं, और उम्मीद करते हैं कि code review बाकी सब संभाल लेगा। इससे भी बुरा यह है कि ऐसा व्यवहार सिर्फ जूनियर ही नहीं, सीनियर डेवलपर्स में भी दिख रहा है

  • कल और आज मैंने भी ठीक यही किया। हमारी टीम को एक bug report मिली, और हमने सोचा कि यह बाहरी vendor की समस्या है। लेकिन vendor ने वापस कह दिया कि दिक्कत हमारी तरफ है। फिर मैंने Codex से जांच करवाई, उसने समस्या ढूंढकर PR तैयार किया। मैंने खुद review या test नहीं किया और टीम से verification करवाया। उस प्रक्रिया ने टीम को LLM को काम के टूल के रूप में इस्तेमाल करना सिखाने में मदद की
  • पिछले दो दिनों में non-developer टीम के दो लोगों ने AI agent से mobile bug ठीक करने का तरीका पूछा और उसका जवाब ticket की मुख्य सामग्री के रूप में डाल दिया। आखिरकार मुझे वह सब पढ़कर असली requirement फिर से समझनी पड़ी
  • “सीनियर” title लेकर भी बहुत लोग जूनियर जैसा व्यवहार करते हैं। लगता है आजकल graduation के सिर्फ 2 साल बाद ही लोगों को senior कहा जाने लगा है, उसी का असर है
  • जो डेवलपर नियमों को अनदेखा या bypass कर सकते हैं, वही सबसे खतरनाक होते हैं। इससे मुझे पहले मिले 10x developers याद आते हैं। अगर कोई नियमों को नज़रअंदाज़ करके सिर्फ features उगलता जाए, तो आखिर में सफाई किसी और को करनी पड़ती है
  • code review के दौरान मुझे हैरानी होती है कि जूनियर डेवलपर्स कहाँ हैं। अगर वे review में हिस्सा ही नहीं लेते, तो उनके code quality के प्रति उनमें जिम्मेदारी महसूस होना मुश्किल है

• अच्छा PR लिखने के नियम सिर्फ AI-generated code पर नहीं, हर स्थिति पर लागू होते हैं। मैं PR description लिखते समय मौजूदा behavior, बदलाव की वजह, और क्या बदला है—इन सबको क्रम से लिखता हूँ। reviewer's बोझ कम करने के लिए test करने का तरीका, screenshots, और E2E test commands तक शामिल करता हूँ। इससे async collaboration या अलग time zone में काम करने वाली टीमों को भी मदद मिलती है

  • review माँगने से पहले मैं खुद एक बार और देखता हूँ। छोटे typos या logs हटाने जैसी चीज़ें पहले ही कर देने से reviewer का समय बचता है। Copilot review भी ऐसे points अच्छी तरह पकड़ लेता है
  • description ध्यान से लिखने पर भी कई बार कोई पढ़ता ही नहीं। फिर भी मैं लिखता रहता हूँ, क्योंकि यह मेरी जिम्मेदारी है
  • PR AI की मदद से बना हो या नहीं, उसमें testing के सबूत और verification होना चाहिए
  • पहले मैं लंबे descriptions लिखता था, लेकिन बाद में समझ आया कि कोई पढ़ता नहीं। सिर्फ मुख्य बातें bullet points में लिखना ज़्यादा असरदार था
  • हमारी टीम के PR template में ticket number, request description, current state, changed state, और यहाँ तक कि ‘mood gif’ भी शामिल है

• इंजीनियर का असली काम requirement को समझना, उसे logical flow में बदलना, trade-offs को संतुलित करना, और नतीजे की जिम्मेदारी लेना है। code generate कर देना या random PR फेंक देना, इन बुनियादी बातों की कमी का लक्षण है। coding agents उल्टा हमें engineering की असल प्रकृति फिर से याद दिलाने का मौका दे रहे हैं

  • इस लेख में एक उदाहरण है जहाँ code की सिर्फ 1 line ने 60 million dollar का नुकसान करा दिया। code समझे बिना AI द्वारा बनाए गए 10,000-line PR संभावित तबाही हैं
  • व्यवहारिक रूप से कंपनियाँ quality से ज़्यादा marketing और profitability को महत्व देती हैं। high-quality products से ज़्यादा ‘premium’ label लगे products बिकते हैं। अंत में engineering से पहले ‘क्या बिकेगा’ आ जाता है
  • लेकिन जब संगठन कहे, “AI इस्तेमाल करके 3 दिन में feature पूरा करो, नहीं तो HR meeting,” तब आदर्श engineering principles को निभाना मुश्किल हो जाता है

• testing ज़रूरी है, लेकिन पर्याप्त नहीं। code को logically verify भी करना पड़ता है। testing सिर्फ खास input और environment में सही behavior दिखाती है

  • मैं भी यही सोचता हूँ। जो code अच्छी तरह चलता है, वह भी फिर भी बेकार हो सकता है
  • “prove” की जगह “demonstrate” शब्द ज़्यादा सही है। testing सिर्फ कुछ खास मामलों में evidence देती है
  • मैं सिर्फ tests पर भरोसा नहीं करता, बल्कि खुद app को अलग-अलग तरीकों से तोड़कर देखने की कोशिश करता हूँ। उसी प्रक्रिया में code और बेहतर होता है
  • ज़्यादातर code को formally prove नहीं किया जा सकता, इसलिए property-based testing जैसी approaches उपयोगी लगती हैं
  • 100% test coverage हासिल कर लेने पर भी अगर code robust नहीं है, तो उसका कोई मतलब नहीं

• मैं testing को obligation की तरह नहीं देखता। मैं यह सिर्फ इसलिए करता हूँ क्योंकि मैं सच में देखना चाहता हूँ कि code काम करता है। अगर code को चलते देखना आपको exciting नहीं लगता, तो शायद यह पेशा आपके लिए नहीं है

• मैंने सुना है कि LLM की वजह से जूनियर बड़े PR फेंक रहे हैं, लेकिन हमारे संगठन में अभी तक ऐसा नहीं हुआ है

  • बहुत बड़े PR नहीं, लेकिन LLM-generated code जिसे डेवलपर खुद नहीं समझता, वह अक्सर दिखता है
  • हमारे संगठन में भी ऐसे मामले हैं। समस्याएँ कुछ ऐसी हैं
    • agent पिछले feedback को revert कर देता है
    • codebase standards को follow नहीं करता
    • मौजूदा solutions को फिर से reinvent करता है
    • PR feedback का जवाब agent output से देता है
    • जहाँ 10~20 lines बदलनी चाहिए थीं, वहाँ 50,000-line PR जमा कर देता है
    • tests कम, error handling कमजोर
  • जो लोग पहले भी low-quality PR submit करते थे, वे अब LLM की वजह से बस और तेज़ी से submit कर रहे हैं
  • WireGuard Android PR #82, #80 को देखें, वहाँ AI से copy-paste किए गए जवाब वैसे के वैसे रह गए हैं। “files changed” tab देखने पर भ्रम होता है
  • मेरा एक दोस्त 11-लोगों वाले startup में काम करता है, जहाँ CTO रात 3 बजे 10,000 lines का code सीधे main पर push कर देता है। exploration phase में यह चल सकता है, लेकिन stabilization phase में यह भयानक risk है

• “तुम्हारा काम code को proven state में देना है” इस बात से मैं सहमत नहीं हूँ। असली काम business problems solve करना है। हाँ, ज़्यादातर मामलों में वह code तक पहुँचता है, लेकिन यह फर्क महत्वपूर्ण है

  • लेकिन code की correctness साबित करना भी business problem solve करने का ही हिस्सा है। यह कोई अलग काम नहीं है
  • requirements पूरी न करने वाला code देकर business problem solve नहीं की जा सकती
  • problem solve करना, लेकिन नई problem पैदा किए बिना—यही महत्वपूर्ण है। इसलिए security और reliability ज़रूरी हैं
  • शायद मेरा experience अभी कम है, लेकिन मुझे समझ नहीं आता कि बिना verify किए हुए code से कोई problem कैसे solve हो सकती है
  • आखिरकार हर job का मकसद problems solve करना ही है। हम बस यह काम computers के ज़रिए करते हैं

• अपनी पिछली नौकरी में मैं जापान की एक high-quality hardware manufacturer में काम करता था। QA department अगर कोई bug पकड़ लेता, तो product release रोक दी जाती थी। इसलिए हर development department ने अपना QC team बना लिया और pre-testing को मजबूत किया। नतीजे में software की verification बहुत गहराई से होती थी

  • “get dinged” का मतलब क्या है, यह जानना चाहता हूँ। ऐसी संरचना उल्टा लोगों को changes से डराने भी लग सकती है

• आजकल काम का मतलब tickets बंद करना रह गया है। code quality metrics में नहीं दिखती, इसलिए वह महत्वहीन बन जाती है। मैं ऐसे system का हिस्सा नहीं बनना चाहता। अब craftsmanship गायब हो रही है, और सबको बस सस्ता plywood और glue चाहिए

  • जिस पल LLM को पूरी तरह अपनाकर सभी से उसका इस्तेमाल अपेक्षित किया जाता है, software engineering अब गंभीर engineering नहीं रह जाती
  • ऐसे रवैये की आलोचना करने वालों से कुछ लोग पूछते हैं, “तो क्या आप government subsidy पर जीते हैं?”

• “proven code” का मतलब ही असली मुद्दा है। कई बार LLM द्वारा बनाए गए tests जोड़कर भी बड़े PR submit कर दिए जाते हैं। मैं भी personal projects में vibe coding करता हूँ, लेकिन team level पर ऐसा करना बुरी आदत है। engineers को hire करने का कारण उनकी expertise खरीदना है

  • इसलिए मैं manual testing पर ज़ोर देता हूँ। screenshots या videos से actual behavior दिखाना भी बहुत भरोसा दे सकता है