AI coding agent के दौर में Spec-Driven Development को सिर्फ “spec → code” जैसी सीधी रेखीय समीकरण के रूप में देखना गलत नज़रिया है.
मुख्य तर्क
Spec-Driven Development एक स्थिर समीकरण नहीं, बल्कि एक गतिशील त्रिभुज है.
तीन अक्षों के बीच लगातार एक-दूसरे को प्रभावित करने वाला feedback loop चलता रहता है:
- Spec
- Code
- Tests
ये तीनों तत्व तभी सही तरह काम करते हैं जब वे आपस में sync में हों.
प्रमुख उदाहरण और प्रयोग
- Drew Breunig द्वारा बनाई गई बिना code वाली library whenwords
→ code के बिना सिर्फ spec (Markdown) + 750 tests (YAML) रखे गए, और AI agent से code generate कराया गया
→ Andrej Karpathy की दिलचस्पी + GitHub पर 1k+ stars + सक्रिय contributions
लेकिन ऐसे प्रयोगों में बार-बार दिखने वाली समस्याएँ:
- implementation तेज़ होता है, लेकिन complexity थोड़ी भी बढ़े तो एक हिस्सा ठीक करने पर दूसरा हिस्सा टूट जाता है
- आखिरकार ज़्यादातर projects अधूरे रहकर बंद हो जाते हैं
- spec कितना भी अच्छा हो, implementation approach पर बहस चलती रहती है
यह त्रिभुज क्यों है?
code बनाते समय → spec की अस्पष्टता/गलतियाँ सामने आती हैं → spec बदला जाता है → नए tests की ज़रूरत पड़ती है → code फिर बदला जाता है → …
→ क्योंकि यह प्रक्रिया लगातार दोहराया जाने वाला loop है.
सुझाई गई दिशा: Plumb टूल
Drew द्वारा बनाया गया CLI tool Plumb
- हर Git commit पर agent conversation logs + code changes का analysis
- agent द्वारा परोक्ष रूप से लिए गए निर्णयों को निकालना → developer approval
- approved decisions → spec अपने-आप update
- spec/test coverage gap report देना
→ “commit failure mode” के ज़रिए अहम फैसलों पर इंसानी review अनिवार्य करना
ऐतिहासिक संदर्भ
अभी हम फिर से 1960s के ‘software crisis’ जैसी स्थिति से गुजर रहे हैं.
तब code इतना बड़ा हो गया था कि उसे दिमाग में समेटना मुश्किल था → waterfall·agile·CI/CD का जन्म हुआ
अब स्थिति यह है कि code पढ़ना भी संभव नहीं रह गया है → इसलिए नए process की ज़रूरत है
→ तर्क यह है कि Plumb जैसे tools उसी दिशा की ओर इशारा करते हैं.
निष्कर्ष एक पंक्ति में
AI ऐसे दौर में code बहुत तेज़ी से बना सकता है,
लेकिन असली मुश्किल spec-code-test त्रिभुज को लगातार sync में रखना है.
अभी कोई टिप्पणी नहीं है.