Ask HN: ऐसे AI-लिखित कोड को, जिसे आप समझते नहीं हैं, शिप करने से कैसे निपटें?
जैसे-जैसे large language models सॉफ़्टवेयर विकास को तेज़ कर रहे हैं, कई इंजीनियर अब ऐसा कोड शिप कर रहे हैं जिसे उन्होंने लिखा नहीं है — और अक्सर पूरी तरह समझते भी नहीं हैं। टिप्पणियाँ “अगर टेस्ट पास हैं, तो शिप करो” से लेकर यह ज़ोर देने तक फैली हैं कि opaque AI-generated code को रिलीज़ करना negligent है, और सुझाए गए उपायों में भारी स्वचालित परीक्षण, formal verification, सख्त architectural control, और multi-agent review शामिल हैं। टूलिंग बहस के नीचे एक गहरी चिंता छिपी है: क्या यह बदलाव software craftsmanship और accountability को घटा रहा है, या सिर्फ इंजीनियरों को design और specification की ओर एक higher level of abstraction पर ले जा रहा है।
परीक्षण, सत्यापन, और “अगर काम करता है”
- कई लोगों का तर्क है कि AI-लिखित कोड को शिप करने का एकमात्र समझदारी भरा तरीका भारी स्वचालित परीक्षण है: बड़े यूनिट और इंटीग्रेशन सूट, क्रॉस-आर्क टेस्ट फ़ार्म, फ़ज़िंग, कैओस टेस्टिंग, म्यूटेशन टेस्टिंग, और e2e टेस्ट।
- कुछ लोग एजेंट्स के लिए भी सख्ती से TDD अपनाते हैं: एजेंट पहले फेल होने वाले टेस्ट लिखता है, फिर कोड जब तक वे पास न हो जाएँ।
- दूसरों को चिंता है कि उसी LLM से कोड और टेस्ट दोनों लिखवाना खतरनाक है, क्योंकि उनकी blind spots साझा हो सकती हैं; इसके लिए इन उपायों का सुझाव दिया जाता है:
- अलग-अलग “कोड” और “टेस्ट” एजेंट।
- प्रतिकूल समीक्षा लूप्स में कई अलग-अलग LLMs।
- जानबूझकर दोष डालना और जाँचना कि टेस्ट उन्हें पकड़ते हैं या नहीं।
- कई लोग ज़ोर देते हैं कि केवल टेस्ट पर्याप्त नहीं हैं: वे डिज़ाइन का सत्यापन नहीं करते, vulnerabilities की अनुपस्थिति सिद्ध नहीं कर सकते, और AI-लिखे टेस्ट अक्सर कमजोर या self-justifying होते हैं।
आर्किटेक्चर, डिज़ाइन, और मानव की भूमिका
- एक सामान्य पैटर्न: इंसान आर्किटेक्चर और abstractions (“skeleton”) डिज़ाइन करते हैं, LLMs implementations (“flesh”) भरते हैं।
- लोग पहले से योजना बनाने पर ज़ोर देते हैं: feature design docs, implementation plans, architecture diagrams, invariants, और contracts; फिर LLMs उन सीमाओं के भीतर implement करते हैं।
- कुछ लोग इसे principal engineer के काम जैसा मानते हैं: आप intent और structure समझते हैं, हर पंक्ति नहीं।
- दूसरों का कहना है कि अगर आप कोड को समझते नहीं हैं, तो आप effectively एक manager/spec-writer हैं, engineer नहीं।
गुणवत्ता, तकनीकी ऋण, और सुरक्षा
- उत्साही लोग बड़े speedups की रिपोर्ट करते हैं और दावा करते हैं कि अच्छे planning और guardrails के साथ quality बहुत ऊँची हो सकती है।
- संदेहवादी लोग “slop” देखते हैं और tech debt, नाज़ुक architectures, और भविष्य की भारी maintenance cost के विस्फोट से डरते हैं।
- सुरक्षा को लेकर बहस है: कुछ लोग बिना समीक्षा किए AI कोड से “epic” CVEs की भविष्यवाणी करते हैं; दूसरे कहते हैं कि मनुष्यों द्वारा लिखा कोड भी पहले से असुरक्षित है और असली समस्या professional standards की कमी है, AI नहीं।
टूल्स, guardrails, और workflows
- लोग guardrail frameworks बनाते हैं: static analysis, linters, coverage gates, CVE scanners, performance checks, observability dashboards, staging/feature flags, backups, और automated rollback।
- कुछ लोग agent “teams” का उपयोग करते हैं: builder, reviewer, QA, और task समन्वय करने वाला एक उच्च-स्तरीय “CTO”/manager agent।
- नए टूल्स इन कामों के लिए सामने आ रहे हैं:
- PR summarization और categorization।
- Architecture और call-graph visualization।
- जटिल subsystems के लिए interactive code exploration और “explainers”।
- कई लोग अब code टाइप करने में कम समय और testing, design review, और monitoring में अधिक समय लगाते हैं।
पेशेवर मानदंड और करियर की चिंताएँ
- एक धड़ा: “ऐसा कोड कभी शिप न करें जिसे आप समझते नहीं हैं”; ऐसा करना negligence है और profession को नीचा दिखाता है।
- दूसरा: बड़े systems में आपने कभी भी shipped code को पूरी तरह नहीं समझा होता (dependencies, colleagues का काम), इसलिए यह मौजूदा practice का विस्तार है।
- चिंता की एक गहरी धारा है: एजेंट्स के लिए “meat proxies” बनने का डर, engineering culture के गिरने का, और SWE भूमिकाओं के भविष्य में PM/“maintenance engineer” की तुलना में downgrade होने का।
- दूसरे इस बदलाव को स्वीकार करते हैं, कहते हैं कि AI का उपयोग करने से बचना career-limiting है, और असली leverage अब design, specification, और agents के आसपास robust processes बनाने में है।
abstraction level और domain differences
- कई लोग LLM coding की तुलना पिछले abstraction jumps (compilers, ORMs, frameworks) से करते हैं, लेकिन आलोचक जवाब देते हैं कि LLMs compilers के विपरीत non-deterministic black boxes हैं।
- AI-लिखे, कम समझे गए code के प्रति सहनशीलता blast radius पर बहुत निर्भर करती है:
- UI, internal tools, dashboards, social features के लिए अधिक relaxed।
- payment systems, ledgers, infra, aerospace/medical-like domains के लिए बहुत अधिक सख्त।