- "कोड नहीं पढ़ता" का मतलब यह है कि line-by-line review की जगह spec, test, static analysis, production signals पर भरोसा किया जाए, और कुछ खास risk क्षेत्रों में code review तक escalation किया जा सकता है
- OpenAI की Harness Engineering और OpenClaw के उदाहरण दिखाते हैं कि कोड की बजाय tests, observability, automated verification infrastructure पर केंद्रित approach अपनाई गई
- black box, security, bug accumulation जैसी शंकाओं के जवाब में, abstraction layers के ऐतिहासिक पैटर्न और automated verification tools के महत्व पर ज़ोर दिया गया
- कोड पढ़ने को पूरी तरह हटाने की बात नहीं, बल्कि safety, security, architecture decisions के समय direct review की ज़रूरत बनी रहती है — ऐसा संतुलित दृष्टिकोण प्रस्तुत किया गया
- कोड धीरे-धीरे implementation detail बनता जा रहा है, और spec, architecture, verification layers मुख्य deliverables के रूप में उभर रहे हैं — इसी trajectory पर दांव लगाना चाहिए
"कोड नहीं पढ़ता" का सही अर्थ
- पिछले लेख की पंक्ति “मैं अब कोड नहीं पढ़ता” ने Hacker News पर 200 से अधिक तीखी टिप्पणियाँ शुरू कर दीं
- इसका सही मतलब यह है कि अधिकांश product code के लिए line-by-line review को default validation method नहीं माना जाता
- spec और tests, बदले हुए diff की चुनी हुई समीक्षा, और production signals अब भी देखे जाते हैं, और कुछ risk क्षेत्रों में code reading तक escalation किया जा सकता है
- कोड न पढ़ने की वजह यह नहीं कि कोड कम महत्वपूर्ण है, बल्कि खासकर बड़े पैमाने के environment में line-by-line पढ़ना correctness सुनिश्चित करने का सबसे प्रभावी तरीका नहीं है
इस दृष्टिकोण के उदाहरण
-
OpenAI की Harness Engineering
- OpenAI ने Harness Engineering ब्लॉग पोस्ट में समझाया कि software engineering टीमों की केंद्रीय भूमिका code लिखने से हटकर environment design, intent specification, feedback loop निर्माण की ओर जा रही है
- 3 engineers ने केवल Codex agent की मदद से 10 लाख lines का code तैयार कर ऐसा product बनाया जिसे सैकड़ों internal users इस्तेमाल करते हैं
- code itself से अधिक उसके आसपास के harness—documentation, dependency rules, linter, test infrastructure, observability system—में निवेश किया गया
- line-by-line code review में अलग से निवेश नहीं किया गया
-
OpenClaw
- बिना टीम के एक व्यक्ति द्वारा बनाया गया OpenClaw, हाल के महीनों में सबसे तेज़ बढ़ने वाले open source projects में से एक बना और GitHub पर 100,000+ stars हासिल किए
- 5 से 10 agents को parallel चलाने वाली संरचना, जिसे किसी beginner ने नहीं बल्कि अनुभवी engineer ने design और operate किया
- “मैं वह कोड deploy करता हूँ जिसे मैं पढ़ता नहीं” शीर्षक वाले interview में बताया गया कि refactoring, architecture, testing, और AI coding के आसपास के harness में भारी निवेश किया जाता है
-
Coder से Orchestrator तक
- ESLint बनाने वाले और कई O'Reilly किताबें लिखने वाले अनुभवी engineer ने हाल की पोस्ट में कहा कि भविष्य की software engineering में code writing नहीं, बल्कि AI agent orchestration केंद्र में होगा
- मुख्य कौशल syntax और implementation से हटकर architecture design, specification writing, feedback loop design की ओर जा रहा है
शंकाओं पर जवाब
-
Black box की आलोचना
- “क्या कोई black box approach को स्वेच्छा से चुनता है?” जैसी आलोचना के जवाब में, यह रेखांकित किया गया कि code का output code itself नहीं, बल्कि product होता है
- यह ऐसा नहीं कि फ़ोटोग्राफ़र फ़ोटो नहीं देखता, बल्कि ऐसा है कि वह फ़ोटो बनाने वाले camera के अंदरूनी ढांचे को नहीं देखता
- जिन abstraction layers को हम सीधे नहीं देखते, उनके ऊपर systems बनाना software सहित कई engineering क्षेत्रों में पहले से सामान्य practice है
-
Security की चिंता
- AI-generated code में backdoor डाले जाने की आशंका के बारे में कहा गया कि यह “हर line इंसान पढ़े” वाला मुद्दा नहीं, बल्कि tooling और verification system का मुद्दा है
- static analysis, dependency scanning, security linters इसलिए मौजूद हैं क्योंकि इंसान भी vulnerable code लिखते हैं; समाधान है और मजबूत automated verification systems, यानी harness-केंद्रित approach की ही दिशा
- फिर भी security-sensitive क्षेत्रों में human review अब भी आवश्यक है
-
Bug accumulation की समस्या
- “अगर code fail हुआ तो लोगों का पैसा गायब होगा, विमान रुकेंगे, कारें खराब होंगी। कोड पढ़ो।” — यह सबसे आम आलोचना है
- CodeRabbit के data के अनुसार AI-generated code में software quality के स्तर पर 1.7 गुना अधिक defects पाए गए
- लेकिन AI coding के तरीके अलग-अलग होते हैं, और spec, hierarchical tests, architecture constraints वाले harness-centric development का simple vibe coding से मूलभूत अंतर है
- एक टिप्पणी में सुझाया गया तरीका: spec, tests, static analysis पर भरोसा, 85%+ test coverage बनाए रखना, धीरे-धीरे scope बढ़ाने वाले integration tests यानी testing ladders बनाना, और benchmarking व सख्त dogfooding से errors को जल्दी उजागर करना
- असली सवाल यह नहीं कि “क्या AI code औसतन अधिक buggy है?”, बल्कि यह है कि “क्या अच्छी तरह design किए गए harness के भीतर, समान गति से development करते हुए यह alternatives से अधिक bugs पैदा करता है?”
- Greg Brockman (OpenAI co-founder) ने भी कहा कि AI code पर वही मानक लागू होने चाहिए जो human-written code पर होते हैं
व्यवहार में system कैसे बनाया जाता है
- करियर के अधिकांश समय code लिखा है, अधिकतर internal tools रहे, लेकिन ऐसे systems भी रहे जिन पर वास्तविक users निर्भर थे
- code के रूप और structure को समझते हुए भी उसे सीधे न पढ़ने का विकल्प चुना गया
-
Spec-based workflow
- agent के code लिखने से पहले AI के साथ बातचीत के माध्यम से बहुत specific और detailed spec पहले लिखी जाती है
- requirement IDs के ज़रिए product spec से execution plan तक traceability सुनिश्चित की जाती है
- execution plan के हर task में validation method के साथ acceptance criteria शामिल होते हैं
- automated tests के लिए (TEST)
- visual checks के लिए (BROWSER:DOM)
- केवल तब (MANUAL) जब कोई और तरीका न हो; तब भी पहले curl या bash आधारित automated checks बनाने की कोशिश की जाती है
- जिन tasks में concrete validation metadata नहीं होता, उन्हें audit skill काम शुरू होने से पहले ही block कर देती है
-
AI Coding Toolkit (harness)
- prompts, skills, hooks, scripts से बना toolkit agent के काम करने के तरीके को सीमित करता है, जिसमें 35+ skills, structured agent instructions, और hierarchical verification infrastructure शामिल है
- agent instructions को infrastructure की तरह manage किया जाता है
- AGENTS.md मुख्य नियम-पुस्तिका की भूमिका निभाता है: conservative changes, existing interfaces बनाए रखना, TDD का पालन, अनुमान न लगाना, git history rewrite न करना
- VISION.md strategic boundaries को define करता है
- hierarchical verification system चलाया जाता है
- हर phase के अंत में checkpoint skill type checking, linting, testing, build, mutation testing, security scans सहित multi-layer gates चलाती है
- browser tools उपलब्ध हों तो automated browser verification चलाया जाता है
- बदले हुए diff को दूसरे AI model (Codex CLI) को भेजकर second-opinion review कराया जाता है
- cross-model verification से एक model की blind spots को पूरा किया जाता है
- कभी-कभी code सीधे पढ़ा भी जाता है, लेकिन केवल exceptional situations में
- जब सभी tests pass हों, फिर भी product behavior अजीब लगे
- जब कोई महत्वपूर्ण architecture decision लेना हो
- जब कई agents किसी failure को solve न कर पाएँ और debugging करनी पड़े
- तब भी उद्देश्य code का विश्लेषण करना नहीं, बल्कि यह समझना होता है कि harness में कौन-सी कमी ने समस्या को आने दिया, ताकि दोबारा न हो
कब कोड पढ़ना चाहिए
- सुरक्षा से सीधे जुड़े systems, security-sensitive services, और महत्वपूर्ण architecture decisions में software engineering वास्तव में engineering ही है, और आज जब code बड़े पैमाने पर generate हो रहा है, तब इसका महत्व और बढ़ जाता है
- aviation क्षेत्र की "Children of the Magenta" उपमा उस स्थिति की ओर इशारा करती है जहाँ pilots navigation screen पर magenta flight path पर ज़रूरत से ज़्यादा निर्भर हो जाते हैं
- सीख यह नहीं कि “autopilot मत इस्तेमाल करो”, बल्कि यह कि ज़रूरत पड़ने पर intervene करने की क्षमता बनाए रखो
- समस्या होने पर automation का स्तर घटाकर fundamentals पर लौट पाना चाहिए, लेकिन हर उड़ान हमेशा manually कराने की मांग अक्षम और अधिक जोखिमपूर्ण है
- automation का उपयोग करते हुए intervention क्षमता न खोना ही असली संतुलन है
Trajectory पर दांव लगाओ
- computing की हर abstraction layer को आते समय विरोध मिला है, और 1973 में Dennis Ritchie और Ken Thompson द्वारा Unix को C में rewrite करना इसका प्रतिनिधि उदाहरण है
- उस समय आलोचना थी कि यह धीमा होगा, hardware control खो जाएगा, और complexity maintenance को कठिन बना देगी; लेकिन C की abstraction ने Unix को उच्च portability और व्यापक प्रभाव वाले operating system के रूप में फैलने दिया
- बार-बार दिखने वाला पैटर्न यह है कि जिस layer को abstract किया जा रहा होता है, उसके विशेषज्ञ उस layer की समझ के महत्व पर ज़ोर देते हैं; कुछ स्थितियों में यह सही भी है, लेकिन अधिकांश समय लोग ऊँची abstraction layers पर सोचने और design करने में अधिक समय लगाने लगते हैं
- कोड न पढ़ने का विकल्प यह घोषणा नहीं कि tools perfect हैं, बल्कि यह आकलन है कि कई use cases में यह पहले से पर्याप्त रूप से काम करता है और तेज़ी से बेहतर हो रहा है
- कोड गायब नहीं हो रहा, बल्कि धीरे-धीरे implementation detail बनता जा रहा है; इसकी जगह spec, architecture, verification layers मुख्य deliverables के रूप में उभर रहे हैं
अभी कोई टिप्पणी नहीं है.