Spec Driven Development - vibe coding को और भी शक्तिशाली बनाना

 (ainativedev.io)
30 पॉइंट द्वारा hexpeek 2025-09-06 | अभी कोई टिप्पणी नहीं है. | WhatsApp पर शेयर करें

शुरू करने से पहले

Kiro नामक IDE को पहले भी GeekNews में कवर किया जा चुका है.

हालाँकि, Kiro जिस विकास पद्धति के विचार की ओर उन्मुख है, यानी Spec Driven Development (SDD), उस दृष्टिकोण से इसका परिचय नहीं कराया गया था,

और Spec Driven Development को समझने के लिए एक अच्छा वीडियो प्रकाशित हुआ है, इसलिए उसका परिचय यहाँ दिया जा रहा है.

Kiro

  • एजेंट-आधारित IDE: प्राकृतिक भाषा के ज़रिए विकास में मदद करता है, लेकिन “spec को first-class artifact” मानने की स्पष्ट प्रवृत्ति वाला IDE है.

  • मौजूदा एजेंट IDE की “vibe coding” गति को बनाए रखते हुए भी, निर्णय, मान्यताओं और constraints को spec दस्तावेज़ों में परिभाषित करता है.

  • workflow: आइडिया इनपुट करते ही तुरंत requirements / design / tasks के 3 फ़ाइल बनाकर शुरुआत करता है. एडिटर, Code OSS fork के ऊपर “Specs / Hooks / Steering” टैब जोड़े गए रूप में है.

    • Specs: आवश्यकताओं को संरचित करता है (user story + EAR format की acceptance criteria), और बाद में implementation, testing, और changes को spec से जोड़ता है.
    • Hooks: फ़ाइल/कोड बदलावों की निगरानी करके spec workflow को trigger करता है.
    • Steering: repository root की .kiro/ में rules (markdown) के रूप में team guide को check-in करता है — उदाहरण के लिए TDD rules डालकर agent behavior को consistent बनाया जा सकता है.

Spec Driven की आवश्यकता

  • vibe coding की सीमाओं की भरपाई: chat के बार-बार आदान-प्रदान से जल्दी code बनाते समय, निर्णयों का आधार chat stream में दब जाता है और बाद में “क्या और क्यों बनाया गया” यह धुंधला हो जाता है. SDD पहले behavior-केंद्रित spec स्थापित करके उसे एक स्थिर compass की तरह इस्तेमाल करने देता है.

  • spec की परिभाषा (behavior, properties, invariants): implementation नहीं, बल्कि system को कैसे व्यवहार करना चाहिए इसका वर्णन — safety/liveness properties और invariants जैसी अवधारणाओं को अपनाते हुए, developer-friendly syntax से उन्हें सुलभ बनाने की सोच है.

SDD के फायदे

  • निर्णयों की visibility और reuse: spec, code changes का “source” बन जाता है, जिससे review और agreement आसान होते हैं, और feature बदलने पर भी intent (behaviors) बचा रहता है.

  • composable living specs: user scenarios, acceptance criteria, interface/data contracts, performance/SLAs आदि को modular बनाकर reuse और composition संभव होते हैं (service → system level).

  • पूरे SDLC में उपयोग: requirements और design के शुरुआती alignment से लेकर deployment के बाद issues की feedback loop तक — AI युग की code generation speed के बीच भी review, quality, और consistency बनाए रखने की समस्या-चेतना इसमें दिखती है.

SDD डेमो

SDD प्रवाह

A. प्रारंभिक सेटअप

  1. Project सेटिंग - Hooks, Steering, MCP
  2. TDD सेटिंग (अनुशंसित)
  3. Spec सेटिंग - EAR format आधारित (अनुशंसित) Spec लिखना (AI के ज़रिए मौजूदा project analysis से auto-generate भी किया जा सकता है)

B. फीचर इम्प्लीमेंटेशन

  1. Spec derivation - नई requirements को Spec में reflect/update करना
  2. guardrails सेटिंग (अनुशंसित) - test stubs, rules लिखना
  3. implementation <-> testing - इस हिस्से में ज़्यादातर दोहराव AI के माध्यम से होता है, और केवल छोटे code changes जिन्हें AI ठीक से संशोधित नहीं कर पाता, उनमें developer हस्तक्षेप करता है
  • project configuration पूरी हो जाने के बाद, 'B. फीचर इम्प्लीमेंटेशन' चरण की पुनरावृत्ति से फीचर्स का विस्तार किया जाता है

ध्यान देने योग्य बातें

  • यदि Spec दस्तावेज़ों की गुणवत्ता न्यूनतम मानक तक नहीं पहुँचती, तो यह काम नहीं करता.
  • वीडियो में Spec दस्तावेज़ों के मानक rules को विस्तार से समझाया नहीं गया है. (संदर्भ: https://kiro.dev/docs/specs/)
  • TDD का उपयोग अनुशंसित है, लेकिन कहा गया है कि जिन projects में TDD लागू नहीं था, उनमें से अधिकांश को इस methodology से खास प्रभाव महसूस नहीं हुआ.

व्यक्तिगत राय

  • AI का बेहतर उपयोग करने के लिए प्रस्तावित एक और दृष्टिकोण-आधारित methodology.
  • हमेशा ‘अच्छी तरह’ लिखे गए दस्तावेज़ों के बहुत सारे फायदे होते हैं. लेकिन वास्तविक अनुभव यह है कि काफ़ी दस्तावेज़ों का maintenance ठीक से नहीं हो पाता; ऐसे में यह कितना व्यापक सहमति हासिल कर पाता है, यही असली मुद्दा लगता है.
  • इस समय AI + TDD development strategy ऐसी methodology है जिससे बहुत से developers सहमत हैं और जिसे कुछ हद तक validate भी किया जा चुका है. अगर केवल TDD के उपयोग और SDD + TDD के संयुक्त उपयोग की तुलना से प्रभाव साबित हो जाए, तो इसे और भी व्यापक समर्थन मिल सकता है.

संबंधित पढ़ाई

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.