- Agentic coding के बारे में यह दावा कि “spec document code की जगह ले सकता है”, इस मूल सीमा की ओर इशारा करता है कि spec अगर पर्याप्त रूप से सटीक हो जाए तो अंततः code के ही समान रूप में सिमटने लगता है
- OpenAI के Symphony प्रोजेक्ट को देखें तो उसका SPEC.md कोई spec नहीं, बल्कि व्यवहार में Markdown फ़ॉर्मैट का pseudocode है
- वास्तव में Symphony spec के आधार पर Haskell implementation करने की कोशिश में कई bugs और agent का अनंत प्रतीक्षा जैसी reliability समस्याएँ सामने आईं
- spec लिखने का काम मूल रूप से coding से भी अधिक गहरी सोच मांगता है, लेकिन मौजूदा उद्योग की speed optimization प्रवृत्ति में AI-जनित low-quality specs का ढेर बनता है
- “garbage in, garbage out” सिद्धांत coding agents पर भी ज्यों का त्यों लागू होता है, और स्पष्टता व detail से रहित documents से विश्वसनीय code generation संभव नहीं
Agentic coding के दो भ्रम
- Agentic coding के समर्थक जिन दो मुख्य भ्रमों पर निर्भर करते हैं
- भ्रम 1: spec document अपने संबंधित code से सरल होता है — यानी engineer को spec document लिखने वाले manager में बदलकर, काम agents की टीम को outsource किया जा सकता है
- भ्रम 2: spec लिखना coding से ज़रूर अधिक विचारशील काम है — यानी spec document से होकर जाने पर quality सुधरती है और बेहतर engineering practices को बढ़ावा मिलता है
code जैसा दिखने वाला spec: Symphony केस का विश्लेषण
- OpenAI का Symphony प्रोजेक्ट अपने आपको spec document (SPEC.md) से उत्पन्न agent orchestrator के रूप में पेश करता है, लेकिन वास्तविक SPEC.md की सामग्री spec से अधिक Markdown फ़ॉर्मैट के pseudocode के करीब है
- SPEC.md में शामिल सामग्री के प्रकार:
- database schema का गद्य-आधारित dump —
session_id, thread_id, codex_input_tokens जैसे fields की सूची
- code को गद्य में बदला हुआ रूप — concurrency control का
available_slots = max(max_concurrent_agents - running_count, 0) जैसा formula, retry backoff formula (delay = min(10000 * 2^(attempt-1), agent.max_retry_backoff_ms)) आदि
- model की code generation में मदद के लिए स्पष्ट रूप से जोड़े गए "Config Fields Summary (Cheat Sheet)" जैसे दोहराव वाले sections
start_service() function जैसे लगभग स्वयं code ही लगने वाले “Reference Algorithms” sections
- जब यह दावा किया जाता है कि spec document code का विकल्प है, लेकिन वही document पढ़ने में code जैसा लगे, तो यह भ्रामक है
- spec document को पर्याप्त रूप से सटीक बनाने के लिए उसे अनिवार्य रूप से code के रूप में बदलना पड़ेगा, या बहुत अधिक structured formal English में लिखना होगा
Dijkstra का “narrow interface” तर्क
- Dijkstra के लेख का हवाला देते हुए कहा गया है कि interface का चुनाव केवल श्रम-विभाजन का मामला नहीं है; interface के पार collaboration और communication की लागत भी जुड़ती है
- ऐतिहासिक उदाहरण दिए गए हैं कि Greek गणित भाषाई और दृश्य गतिविधियों तक सीमित रहकर ठहर गया, Islamic algebra rhetorical style में लौटकर कमजोर हुआ, और पश्चिमी यूरोप मध्यकालीन scholasticism की “व्यर्थ भाषाई सटीकता की कोशिश” से बाहर निकलकर Vieta, Descartes, Leibniz, Boole आदि की formal symbolic systems की वजह से आगे बढ़ा
- Agentic coders engineering labor द्वारा माँगे गए “narrow interface” (= code) से बच नहीं सकते; वे केवल उस श्रम को सतही रूप से अलग दिखने वाले, लेकिन उसी स्तर की सटीकता मांगने वाले रूप में परिवर्तित कर सकते हैं
अस्थिरता: spec-आधारित code generation की reliability समस्या
- Symphony README की सिफारिश के अनुसार Claude Code से Haskell implementation माँगने पर, वह काम नहीं करता
- कई bugs आए, जिन्हें prompts के ज़रिए ठीक करना पड़ा (यह commit history में देखा जा सकता है)
- बिना error message के “चलने” वाले मामलों में भी
codex agent एक साधारण Linear ticket (“खाली git repository बनाना”) पर बिना किसी प्रगति के अनंत प्रतीक्षा में चला गया
- Dijkstra की भाषा उधार लें तो Symphony की “व्यर्थ भाषाई सटीकता की कोशिश” भी अब तक विश्वसनीय implementation बनाने में विफल रहती है
- यह समस्या केवल Symphony तक सीमित नहीं है — YAML spec जैसी अत्यंत विस्तृत, व्यापक रूप से प्रयुक्त, और conformance test suite वाली specs में भी अधिकांश YAML implementations spec का पूर्ण पालन नहीं करतीं
- Symphony की spec पहले से शामिल Elixir implementation के 1/6 आकार तक पहुँचती है, और अगर इसे और बढ़ाया जाए तो यह Borges की “On Exactitude in Science” जैसी स्थिति तक पहुँचती है — जहाँ साम्राज्य के बराबर आकार का नक्शा बनाकर वह अंततः बेकार हो जाता है
- “अगर इसे किसी अधिक mainstream language में generate किया जाए तो नतीजा बेहतर होगा” जैसी आपत्ति के जवाब में कहा गया है कि अगर agent को Haskell code generation में कठिनाई होती है, तो यह training data से आगे generalize करने की कमी को दिखाता है
Slop: AI-जनित specs की quality समस्या
- spec लिखने का काम मूल रूप से coding से अधिक कठिन होना चाहिए, क्योंकि इसका उद्देश्य code लिखने से पहले project को विचारशील और आलोचनात्मक दृष्टि से देखना है
- लेकिन tech कंपनियों में श्रम को घटाकर आँकने और उसका अवमूल्यन करने वाली उद्योग प्रवृत्ति के बीच, अगर शुरुआत ही इस मान्यता से हो कि “spec लिखना coding से आसान है”, तो विफलता तय है
- delivery speed optimization को लक्ष्य बनाकर spec writing के लिए आवश्यक कठिन और असुविधाजनक काम करना संभव नहीं है
- Symphony SPEC.md का Section 10.5 (
linear_graphql extension contract) slop का प्रतिनिधि उदाहरण है — ऐसे agent output का रूप, जिसमें एकरूपता, उद्देश्य और बड़े परिप्रेक्ष्य की समझ का अभाव है, फिर भी वह “spec जैसा” दिखता है
query खाली न होने वाली string होनी चाहिए, उसमें ठीक एक GraphQL operation होना चाहिए, जैसी अलग-अलग rules दी गई हैं, लेकिन समग्र संदर्भ गायब है
- ऐसे spec documents, चाहे इंसान ने लिखे हों, फिर भी अनिवार्य रूप से slop बन सकते हैं — क्योंकि वे एकरूपता या स्पष्टता नहीं, बल्कि delivery time के लिए optimize किए गए होते हैं
- code snippets को syntax highlighting के बिना
text के रूप में annotate किया जाना भी AI-जनित document का संकेत है — संभवतः model ने अनुरोध की मंशा नहीं, बल्कि उसका शाब्दिक अर्थ पकड़ा
निष्कर्ष
- specs मूल रूप से समय बचाने के उपकरण के रूप में डिज़ाइन नहीं की गई थीं
- अगर लक्ष्य delivery time optimization है, तो बीच में spec document रखने की बजाय सीधे code लिखना अधिक लाभकारी है
- “garbage in, garbage out” सिद्धांत यहाँ भी ज्यों का त्यों लागू होता है — यदि input document में स्पष्टता और detail की कमी हो, तो ऐसा कोई संसार नहीं है जहाँ coding agent उस कमी को विश्वसनीय रूप से भर दे
- coding agent मन पढ़ने वाली सत्ता नहीं है, और भले ही वह ऐसा हो, अगर सोच ही अव्यवस्थित हो तो उसके पास करने के लिए कुछ नहीं बचेगा
अभी कोई टिप्पणी नहीं है.