Spec-Driven Development (SDD) को समझना: Kiro, Spec-Kit, Tessl

 (martinfowler.com)
27 पॉइंट द्वारा GN⁺ 2025-10-20 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • Spec-Driven-Development(SDD) AI-आधारित coding में एक ऐसा approach है जिसमें code लिखने से पहले specification (spec) पहले लिखी जाती है, और यही spec developer तथा AI, दोनों के लिए source of truth की भूमिका निभाती है
  • SDD को इम्प्लीमेंटेशन के तीन स्तरों में बाँटा जाता है, और यह चरणबद्ध रूप से spec-first (पहले spec लिखना), spec-anchored (maintenance के लिए spec को बनाए रखना), और spec-as-source (spec को मुख्य source file की तरह उपयोग करना, तथा developer द्वारा code को सीधे edit न करना) तक विकसित होता है
  • Kiro requirements → design → tasks का सरल 3-step workflow देता है, spec-kit constitution नाम के शक्तिशाली rule-based workflow का उपयोग करता है, और Tessl spec-as-source approach का प्रयोग करता है जिसमें spec और code का 1:1 mapping होता है
  • तीनों tools में छोटे bug fix के लिए भी जरूरत से ज्यादा process की मांग होती है, Markdown files की review code review की तुलना में अधिक झंझटपूर्ण है, और बड़े context window के बावजूद AI सभी instructions को सही ढंग से follow नहीं कर पाता
  • SDD अतीत के Model-Driven Development(MDD) की असफलताओं की याद दिलाता है, और इसमें non-determinism तथा inflexibility—दोनों तरह की कमियाँ एक साथ आ जाने का जोखिम है, इसलिए वास्तविक projects में इसकी उपयोगिता की पुष्टि अभी बाकी है

Spec-Driven Development (SDD) की परिभाषा

  • SDD code लिखने से पहले specification लिखने वाला एक "documentation first" approach है, जिसमें spec developer और AI, दोनों के लिए single source of truth की भूमिका निभाती है
  • GitHub इसे इस तरह परिभाषित करता है कि "software maintenance का मतलब specification का evolution है; development की common language ऊपर के abstraction level पर चली जाती है और code अंतिम चरण बन जाता है"
  • Tessl इसे इस रूप में समझाता है कि "यह ऐसा development approach है जिसमें specification code नहीं बल्कि primary artifact बन जाती है; spec structured और testable language में intent को व्यक्त करती है और agent उसी के अनुसार code generate करता है"
  • SDD को तीन implementation levels में बाँटा जा सकता है
    • Spec-first: पहले अच्छी तरह structured spec लिखना और उसे AI-assisted development workflow में उपयोग करना
    • Spec-anchored: काम पूरा होने के बाद भी spec को बनाए रखना ताकि feature के evolution और maintenance में उसका लगातार उपयोग हो
    • Spec-as-source: spec समय के साथ primary source file बनी रहती है; developer केवल spec edit करता है और code को सीधे नहीं छूता
  • सभी SDD approaches spec-first होते हैं, लेकिन सभी का लक्ष्य spec-anchored या spec-as-source होना नहीं है, और अक्सर समय के साथ spec को maintain करने की strategy अस्पष्ट या पूरी तरह खुली छोड़ी जाती है

Specification (spec) क्या है

  • Spec एक natural language में लिखा गया structured और behavior-oriented artifact है, जो software functionality को व्यक्त करता है और AI coding agent के लिए guide की भूमिका निभाता है
  • सबसे सुसंगत परिभाषा यह है कि spec को Product Requirements Document(PRD) के समान माना जाए
  • Spec को codebase के लिए बने सामान्य context documents से अलग समझना चाहिए
    • सामान्य context में rule files, product और codebase के high-level descriptions शामिल होते हैं, और कुछ tools इसे memory bank कहते हैं
    • Memory bank files codebase की सभी AI coding sessions में प्रासंगिक होती हैं, जबकि spec केवल किसी specific feature को बनाने या बदलने वाले task के लिए प्रासंगिक होती है
  • SDD का हर variant spec की structure, detail level, और project के भीतर organization के लिए अपना अलग approach तय करता है

SDD tools का मूल्यांकन कठिन क्यों है

  • SDD tools और approaches का वास्तविक उपयोग के करीब जाकर मूल्यांकन करना बहुत time-consuming है
    • इसके लिए अलग-अलग आकार की समस्याओं पर, greenfield और brownfield projects में इन्हें आज़माना पड़ता है, और intermediate artifacts को सतही नहीं बल्कि गहराई से review व revise करने में समय देना पड़ता है
  • GitHub के spec-kit blog post में ज़ोर देकर कहा गया है कि "महत्वपूर्ण बात यह है कि आपकी भूमिका सिर्फ direction देने की नहीं, बल्कि validation करने की भी है; हर चरण में reflect और refine करना होता है"
  • तीन tools में से दो को existing codebase में introduce करने के लिए अधिक मेहनत चाहिए लगती है, जिससे brownfield codebase में उनकी उपयोगिता का आकलन और कठिन हो जाता है
  • जब तक वास्तविक codebase में कुछ समय तक इनका उपयोग करने वाले लोगों की reports न मिलें, तब तक ये व्यवहार में कैसे काम करते हैं इस पर कई खुले सवाल बने रहते हैं

Kiro

  • Kiro तीनों tools में सबसे सरल और हल्का tool है, और ज़्यादातर spec-first approach के अंतर्गत आता है
    • इसके examples मुख्यतः tasks या user stories के लिए ही मिलते हैं; समय के साथ कई tasks में requirements documents को spec-anchored तरीके से उपयोग करने पर कोई चर्चा नहीं मिलती
  • Workflow: requirements → design → tasks
    • Workflow का हर चरण एक Markdown document के रूप में व्यक्त किया जाता है, और Kiro अपने VS Code-आधारित distribution के भीतर इन 3 चरणों में मार्गदर्शन देता है

  • Kiro के मुख्य components

    • Requirements
      • हर requirement एक "user story" (As a...) format में व्यक्त होने वाली requirements list के रूप में structured होती है
      • Acceptance criteria GIVEN... WHEN... THEN... format का उपयोग करते हैं
    • Design
      • इसमें component architecture diagram, data flow, data model, error handling, test strategy, implementation approach, migration strategy जैसे sections शामिल होते हैं
      • यह हर task में consistent structure रखता है या बदलता रहता है, यह स्पष्ट नहीं है
    • Tasks
      • Requirement numbers से track की जाने वाली tasks list
      • Tasks को एक-एक करके execute करने और task-wise changes review करने के लिए additional UI elements भी देता है

  • Kiro का memory bank

    • Kiro memory bank की अवधारणा को "steering" कहता है
      • इसकी सामग्री flexible है, और workflow किसी specific file की मौजूदगी पर निर्भर नहीं दिखता
    • जब Kiro से steering documents generate करने को कहा जाता है, तो वह जो default structure बनाता है उसमें product.md, structure.md, tech.md शामिल होते हैं

Spec-kit

  • spec-kit GitHub का SDD version है, और इसे ऐसे CLI के रूप में वितरित किया जाता है जो विभिन्न general coding assistants के लिए workspace setup generate कर सकता है
  • Structure setup के बाद coding assistant के slash commands के ज़रिए spec-kit के साथ interaction किया जाता है
  • सभी artifacts सीधे workspace में रखे जाते हैं, इसलिए चर्चा किए गए तीनों tools में यह सबसे अधिक customizable है

  • Spec-kit का workflow

    • Workflow: Constitution → 𝄆 Specify → Plan → Tasks 𝄇
    • spec-kit में memory bank जैसी अवधारणा spec-driven approach की prerequisite है
      • इसे constitution कहा जाता है, और इसमें ऐसे "immutable" high-level principles होते हैं जो हर बदलाव पर हमेशा लागू होने चाहिए
      • यह workflow में बड़े पैमाने पर उपयोग होने वाली बहुत शक्तिशाली rule file है

  • Spec-kit कैसे काम करता है

    • हर workflow चरण (specify, plan, tasks) में bash scripts और templates का उपयोग करके files और prompts के sets instantiate किए जाते हैं
    • Workflow files के अंदर checklists का काफ़ी उपयोग करता है ताकि required user clarifications, constitution violations, research tasks आदि को track किया जा सके
      • यह हर workflow stage के "definition of done" जैसा काम करता है, हालांकि AI द्वारा interpretation होने के कारण 100% guarantee नहीं है
    • एक spec कई files से मिलकर बन सकती है
      • उदाहरण: data-model, plan, tasks, spec, research, api, component आदि कुल 8 files

  • Spec-kit का approach

    • GitHub शुरुआत में spec-anchored approach की ओर बढ़ता हुआ लगता है
      • "Specs को static documents नहीं, बल्कि project के साथ evolve होने वाले living, executable artifacts के रूप में फिर से सोचा जा रहा है; specs shared source of truth बनती हैं"
    • लेकिन spec-kit हर generated spec के लिए एक branch create करता है, इसलिए ऐसा भी समझा जा सकता है कि spec feature की पूरी life के बजाय change request की life तक ही जीवित artifact है
    • Community discussions में भी इस confusion की बात होती है, और spec-kit अभी भी केवल spec-first तक सीमित दिखता है, समय के साथ spec-anchored नहीं बनता

Tessl Framework

  • Tessl Framework private beta stage में है, और spec-kit की तरह ऐसा CLI है जो विभिन्न coding assistants के लिए workspace और configuration structure generate कर सकता है
  • इसके CLI commands MCP server की तरह भी काम करते हैं

  • Tessl की विशेषताएँ

    • यह तीनों tools में एकमात्र ऐसा tool है जो spec-anchored approach को स्पष्ट रूप से लक्ष्य बनाता है, और spec-as-source स्तर के SDD को भी explore कर रहा है
    • Tessl specs maintained और edited होने वाले primary artifacts का काम कर सकती हैं, और code के ऊपर // GENERATED FROM SPEC - DO NOT EDIT comment दिया जाता है
      • अभी इसकी spec और code files के बीच 1:1 mapping है, यानी एक spec codebase की एक file में translate होती है
      • यह अभी beta में है और अलग-अलग versions पर प्रयोग चल रहा है, इसलिए आगे चलकर एक spec कई files वाले code component में भी map हो सकती है

  • Tessl spec structure

    • @generate या @test जैसे tags Tessl को क्या generate करना है यह निर्देश देते हैं
    • API section यह विचार दिखाता है कि codebase के दूसरे हिस्सों के सामने expose होने वाला minimal interface spec के भीतर define किया जाए, ताकि generated component के महत्वपूर्ण हिस्से maintainer के पूर्ण नियंत्रण में रहें
    • tessl build चलाने पर संबंधित JavaScript code file generate होती है

  • Tessl का abstraction level

    • spec-as-source के लिए spec को प्रति code file काफ़ी low abstraction level पर रखने से LLM को करने वाली interpretation और steps की मात्रा कम होती है, और साथ ही error की संभावना भी घटती है
    • फिर भी इतने low abstraction level पर एक ही spec से कई बार code generate करने पर non-determinism देखा गया
      • Spec को बार-बार refine करके अधिक specific बनाना ताकि code generation की repeatability बढ़े, unambiguous और complete specs लिखने की कठिनाइयों और pitfalls की याद दिलाता है

Observations और प्रश्न

  • क्या एक ही workflow हर scale को संभाल सकता है?

    • Kiro और spec-kit दोनों एक-एक dogmatic workflow देते हैं, लेकिन संभव है कि दोनों अधिकांश वास्तविक coding problems के लिए उपयुक्त न हों
    • यह स्पष्ट नहीं है कि वे problem size के अनुरूप पर्याप्त variety देते हैं या नहीं
      • जब Kiro से एक छोटा bug fix करने की कोशिश की गई, तो workflow अखरोट तोड़ने के लिए हथौड़ा चलाने जैसा लगा
      • Requirements document ने छोटे bug को कुल 16 acceptance criteria वाली 4 "user stories" में बदल दिया
    • spec-kit के साथ भी किस आकार की समस्या पर इसका उपयोग होना चाहिए, यह स्पष्ट नहीं लगा
      • जब ऐसे feature पर कोशिश की गई जो पहले टीम में 3-5 point story होता, तो spec-kit के steps और generated Markdown files की मात्रा समस्या के मुकाबले बहुत ज़्यादा लगी
      • उसी समय में "सामान्य" AI-assisted coding से feature implement किया जा सकता था और कहीं अधिक control महसूस होता
    • एक प्रभावी SDD tool को विभिन्न आकार और प्रकार के changes के लिए कम-से-कम कुछ अलग core workflows की flexibility देनी चाहिए

  • Code review से ज़्यादा Markdown review?

    • spec-kit review के लिए बहुत सारी Markdown files बनाता है
      • वे आपस में भी दोहराव वाली हैं और मौजूदा code के साथ भी
      • कुछ में पहले से code शामिल है, इसलिए पूरी चीज़ बहुत verbose और review करने में थकाऊ हो जाती है
    • Kiro में केवल 3 files मिलती हैं, और "requirements > design > tasks" का mental model अधिक intuitive होने से इसे समझना थोड़ा आसान है
      • लेकिन Kiro भी जिस छोटे bug के लिए कहा गया था, उसके मुकाबले बहुत verbose है
    • ईमानदारी से कहें तो इन सारे Markdown files के बजाय code review करना बेहतर लगता है
    • एक प्रभावी SDD tool को बहुत अच्छा spec review experience देना होगा

  • क्या यह नियंत्रण का झूठा एहसास है?

    • इन सभी files, templates, prompts, workflows, और checklists के बावजूद अक्सर agent अंततः सभी instructions follow नहीं करता
    • बड़े context windows को SDD का एक enabling factor बताया जाता है, लेकिन window बड़ी होने का मतलब यह नहीं कि AI उसके भीतर की हर चीज़ को सही से समझ लेगा
    • उदाहरण
      • spec-kit में planning के दौरान research phase था और existing code पर काफी research भी हुई, लेकिन अंत में agent ने यह नज़रअंदाज़ कर दिया कि वह existing class का description है; उसने उसे नई spec मानकर सब कुछ दोबारा generate कर दिया और duplication पैदा कर दी
      • सिर्फ instructions ignore करने के उदाहरण ही नहीं, बल्कि ऐसे agents भी देखे गए जो किसी instruction (जैसे constitution की कोई clause) को ज़रूरत से ज़्यादा गंभीरता से लेकर overdo कर देते हैं
    • पिछले अनुभव से, जो चीज़ हम बना रहे होते हैं उस पर control रखने का सबसे अच्छा तरीका छोटे और iterative steps रहा है; इसलिए पहले से बहुत अधिक spec design करना अच्छा विचार है या नहीं, इस पर गंभीर संदेह है
    • एक प्रभावी SDD tool को iterative approach अपनानी होगी, लेकिन छोटे work packages तो SDD के मूल विचार के लगभग विपरीत लगते हैं

  • Functional spec और technical spec को प्रभावी ढंग से कैसे अलग करें?

    • SDD में functional specification और technical implementation के बीच separation जानबूझकर करने का विचार आम है
      • मूल आकांक्षा यह है कि अंततः AI सारे solution details भर दे और उसी spec से अलग technology stack पर भी switch किया जा सके
    • लेकिन वास्तव में spec-kit आज़माते समय अक्सर भ्रम हुआ कि कब functional level पर रुकना चाहिए और कब technical details जोड़नी चाहिए
      • Tutorials और docs भी इस पर consistent नहीं थे, और "purely functional" का अर्थ क्या है इस पर अलग-अलग interpretations थीं
    • अगर हम उन कई user stories को याद करें जिनमें requirements और implementation ठीक से अलग नहीं थे, तो स्पष्ट है कि हमारा पेशा ऐतिहासिक रूप से इसमें बहुत अच्छा नहीं रहा है

  • Target user कौन है?

    • कई spec-driven development tools के demos और tutorials में product और feature goals define करने जैसी चीज़ें शामिल होती हैं, और "user story" जैसे terms भी इस्तेमाल होते हैं
    • शायद यहाँ विचार यह है कि AI को cross-skilling के enabler की तरह इस्तेमाल करके developers को requirements analysis में अधिक सक्रिय बनाया जाए
      • या फिर जब developer इस workflow में काम करे तो product person के साथ pairing हो?
    • इनमें से कुछ भी स्पष्ट रूप से समझाया नहीं गया, बल्कि यह मान लिया गया है कि developer यह सारा analysis करेगा
    • तो फिर SDD किस आकार और किस प्रकार की problems के लिए है?
      • संभवतः यह अभी भी बहुत अस्पष्ट बड़े features के लिए उपयुक्त नहीं होगा; ऐसे मामलों में अधिक विशेषज्ञ product और requirements skills, research, तथा stakeholder participation जैसे और भी कई steps चाहिए होंगे

  • Spec-anchored और spec-as-source: क्या हम अतीत से सीख रहे हैं?

    • बहुत लोग SDD की तुलना TDD या BDD से करते हैं, लेकिन खासकर spec-as-source के मामले में एक और महत्वपूर्ण तुलना MDD(Model-Driven Development) से है
    • करियर की शुरुआत में कुछ projects में MDD का बहुत उपयोग किया गया था, और Tessl Framework को आज़माते समय यह बात बार-बार याद आई
      • MDD के models मूल रूप से specifications ही थे, लेकिन वे natural language में नहीं बल्कि custom UML या text DSL में व्यक्त किए जाते थे
      • इन specifications को code में बदलने के लिए custom code generators बनाए जाते थे

  • MDD और SDD की तुलना

    • अंततः MDD business applications में सफल नहीं हो पाया, क्योंकि वह awkward abstraction level पर था और बहुत अधिक overhead व constraints पैदा करता था
    • लेकिन LLM, MDD के कुछ overhead और constraints को हटा देते हैं, इसलिए अब spec लिखने पर ध्यान देकर code generate करने की नई आशा दिखती है
    • LLM के साथ आपको पहले से define और parse की जा सकने वाली spec language तक सीमित नहीं रहना पड़ता, और sophisticated code generators बनाने की भी ज़रूरत नहीं होती
      • इसकी कीमत, स्वाभाविक रूप से, LLM का non-determinism है
    • Parseable structure का लाभ यह भी था कि वह spec writers को valid, complete, और consistent specs लिखने के लिए काफी tooling support देता था, और अब यह लाभ खो रहा है
    • spec-as-source, और यहाँ तक कि spec-anchoring भी, MDD और LLM दोनों की कमियों का मेल बन सकता है: inflexibility और non-determinism
    • अतीत के spec-from-code प्रयासों को देखकर, आज spec-driven development को explore करते समय उनसे सीखना चाहिए

निष्कर्ष

  • व्यक्तिगत रूप से, AI-assisted coding का उपयोग करते समय मैं अक्सर coding agent को देने के लिए spec के रूप को सावधानी से लिखने में समय लगाता हूँ
    • इसलिए spec-first का सामान्य सिद्धांत कई स्थितियों में निश्चित रूप से मूल्यवान है
  • Specs को structure करने के अलग-अलग approaches की बहुत ज़रूरत है, और यह आज practitioners से मिलने वाले सबसे आम सवालों में से एक है
    • "memory bank को कैसे structure करें?", "AI के लिए अच्छे specs और design documents कैसे लिखें?"
  • लेकिन "spec-driven development" शब्द अभी तक अच्छी तरह परिभाषित नहीं है, और इसका अर्थ पहले से ही फैलकर धुंधला हो चुका है
    • हाल में यह भी सुनने को मिला है कि "spec" को मूलतः "detailed prompt" का synonym की तरह इस्तेमाल किया जा रहा है

  • Tools पर मूल्यांकन

    • कुछ tools मौजूदा workflows को AI agents तक बहुत literal तरीके से पहुँचाने की कोशिश करते हैं, जिससे अंततः review overload और hallucination जैसी मौजूदा चुनौतियाँ और बढ़ सकती हैं
    • खासकर वे अधिक sophisticated approaches जो बहुत सारी files बनाती हैं, उन्हें देखकर जर्मन compound word "Verschlimmbesserung" याद आता है—यानी सुधारने की कोशिश में चीज़ को और खराब कर देना
      • कहीं ऐसा तो नहीं कि बेहतर बनाने की कोशिश में हम चीज़ों को और बदतर बना रहे हैं?

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

3 टिप्पणियां

 
aer0700 2025-10-20

पहले document driven develope या readme driven develope जैसी बातों से मिलता-जुलता लग रहा है.
https://hi.news.hada.io/topic?id=15502
 
GN⁺ 2025-10-20
Hacker News राय

  • मैं हाल में SDD (spec-driven development) ट्रेंड को देख रहा हूँ। यह दिशा तर्कसंगत लगती है, लेकिन ऐसा भी महसूस होता है जैसे हम pre-agile दौर के feature specs और design documents के समय में वापस जा रहे हों। यह पूरी तरह Big Design Up Front नहीं है, लेकिन धीरे-धीरे मामला ‘working software == perfect documentation’ की ओर जाता दिख रहा है।
    Big Design Up Front संदर्भ, Agile Manifesto संदर्भ

    • feature specs और design documents आखिरकार natural language में coding करने जैसा ही है। पहले इंसानों को इसे फिर से programming language में लिखना पड़ता था, लेकिन अब LLM (large language model) जैसे automated compiler यह काम करने लगे हैं। यानी इस प्रक्रिया का एक चरण छोड़ा जा सकता है (हालाँकि सफलता दर अलग-अलग है)।<br /> दूसरी ओर agile को इस बात से फर्क नहीं पड़ता कि software किस भाषा में बनाया जा रहा है। उसका मूल विचार ‘manager को हटाना’ है, ताकि developer खुद management का काम भी करे। 12 principles में इस पर और विस्तार से बात की गई है कि manager न होने पर developer को क्या करना पड़ता है।

    • Behaviour Driven Design, Test Driven Design की तरह ‘living specification’ बना सकता है। domain exploration के मानकों से लेकर test pass होने तक, सब कुछ human-readable document के रूप में रखा जा सकता है, और इसे सीधे test harness से जोड़कर current functionality को validate भी किया जा सकता है। इस तरह BDD report के माध्यम से स्पष्ट रूप से verified, collaborative और iterative specification documents मिलते हैं, और बिना शुरुआती अनावश्यक काम के agile, JIT, YAGNI सब साथ में संभाले जा सकते हैं। waterfall पर वापस जाने की ज़रूरत नहीं है।

    • छोटे स्तर के design से शुरुआत की जा सकती है। एक-दो पेज की spec लिखकर LLM से code और test generate कराएँ, फिर उसे बार-बार सुधारें। अगर आप 100% LLM coding पर भरोसा करते हैं, तो spec inputs (English prompts) को व्यवस्थित तरीके से manage करना तार्किक है। prompts को फेंकने के बजाय व्यवस्थित रखने से आगे reuse किया जा सकता है या अतिरिक्त constraints भी साफ़ तौर पर दिए जा सकते हैं।<br /> लेकिन production-critical code में LLM का इस्तेमाल करना मुझे असहज करता है, इसलिए मैं अभी केवल sandbox/test/demo उद्देश्यों के लिए प्रयोग कर रहा हूँ। इसे वहीं उपयोग करता हूँ जहाँ code quality उतनी महत्वपूर्ण नहीं है।

    • Spec driven development खुद में एक अच्छा विचार है। लेकिन मौजूदा implementations unstructured markdown files को agent के हवाले कर देती हैं, और क्योंकि सही output नहीं आता, व्यवहार में reproducibility लगभग नहीं के बराबर है। अगर agent spec लिखने तक जा रहा है, तो वह structured spec होनी चाहिए जिसे stub code और test code में अपने-आप बदला जा सके। markdown को फेंकने की बात नहीं है, लेकिन अगर उसे code generator से जोड़ा जाए तो reproducibility बहुत बेहतर हो सकती है। वास्तव में ऐसा करने पर repetitive code generation में लगने वाला समय काफी घट सकता है।

  • SpecKit इस्तेमाल करते समय यह मुझे बहुत रोचक और संतोषजनक लगा, लेकिन वास्तविक दुनिया के जटिल examples या use cases ढूँढना मुश्किल था। ज़्यादातर tutorials बस simple install करके ‘todo list app बनाओ’ स्तर पर रुक जाती हैं। अच्छा होता अगर कोई यह साझा करता कि legacy codebase को step-by-step कैसे बेहतर या refactor किया जाए, या ऐसे बड़े projects में कैसे approach किया जाए जहाँ spec driven development शुरू से लागू न रहा हो।

    • मैं भी BDD approach और CLI-based coding साथ लेकर चला हूँ, और महसूस किया कि लंबी-चौड़ी markdown से कहीं बेहतर है कि functionality को सीधे real code में दर्ज किया जाए। अगर AI को follow करने के लिए checklist चाहिए, तो agents.md जैसी file काफ़ी है। coding patterns और non-functional requirements (NFR) एक बार लिख देने से agent उन्हें साफ़ तौर पर follow कर सकता है।

    • वास्तव में उपयोग करना हो तो templates या source code को सीधे पढ़ना ही पड़ता है, तभी समझ आता है कि असल में क्या चल रहा है। मुझे लगता है ऐसे projects में यह स्वाभाविक प्रक्रिया है।

  • Thoughtworks पृष्ठभूमि वाले AI-based delivery expert का परिचय आने के बाद जब memory banks की बात चली तो मैं तुरंत relate कर पाया। हम भी ‘AI ही सब कुछ है’ वाले माहौल में काम कर चुके हैं, और देखा कि memory bank बड़ा होते ही AI उल्टा दिशा खो देता है और output बिखर जाता है। अंत में कोई ऐसा इंसान चाहिए जो product को पूरी तरह समझता हो और खुद AI को lead कर सके, तभी उसे ground reality में लागू किया जा सकता है। मैंने अनगिनत बार देखा है कि AI ने मुझे भ्रमित किया, और जब इंसान उसे फिर से सही दिशा देता है तो वह माफ़ी भी माँगता है और समझने का दिखावा भी करता है, लेकिन उससे बदलता कुछ नहीं। AI का आपस में लिखे हुए ढेर सारे documents को पढ़ना और verify करना भी व्यावहारिक नहीं है। कई बार लगता है कि उससे अच्छा तो उतने समय में खुद काम कर लेना है।

    • मैं जानना चाहता हूँ कि memory bank से यहाँ ठीक-ठीक क्या मतलब है, और उसकी भूमिका के बारे में विशेष रूप से क्या कहना चाहा जा रहा है।

    • इस समय memory feature उल्टा नुकसानदेह है। बिना सही ‘search/retrieval’ strategy के इसका उपयोग करने पर खराब results ही बढ़ते हैं। ज़्यादातर memory systems single-chat paradigm के लिए design किए गए हैं, इसलिए अलग-अलग environments में वे समस्या पैदा करते हैं। असली ‘memory’ वह होगी जहाँ main agent से अलग एक ‘meta-cognition/default mode network’ asynchronous तरीके से task structure और context design करे, और हर prompt पर वही meta model दिशा तय करे। यानी सही मॉडल ‘agent-based memory’ है।

    • LinkedIn जैसी जगहों पर ‘thought leader’ जैसा title लगा होना भी मुझे समझ नहीं आता। आजकल ऐसे titles का मतलब क्या रह गया है, यह सच में समझना मुश्किल है।

  • पिछले 2 हफ्तों में SpecKit और Claude Code के साथ दो नए projects पर किए गए अपने प्रयोग साझा करना चाहता हूँ। दोनों projects मैंने अकेले विकसित किए, इसलिए प्रयोग करने में कोई जोखिम नहीं था। पहला project मैंने SpecKit को लगभग पूरी तरह सौंप दिया। 10 दिन में सभी tasks पूरे हो गए, लेकिन output के ज़्यादातर tests fail थे और build भी टूट गया था। समस्याएँ ठीक करने में उतना ही समय फिर लगाना पड़ा, और Claude एक चीज़ ठीक करता तो दूसरी तोड़ देता था, जिससे भरोसा बहुत कम हो गया।<br /> दूसरे project में मैंने छोटे units में iterate करने की कोशिश की। SpecKit planning के बाद slash commands जोड़कर backlog.md बनाया, फिर plan-sprint से sprint goals और detailed work items वाला file बनाया, और implement-sprint से bulk execution कराया। लेकिन इस प्रक्रिया में भी implementation commands ठीक से follow नहीं हुईं; कई बार workflow सुधारने के बाद भी tests नहीं बनाए गए या tasks छूट गए।<br /> इसलिए मैंने setup फिर बदला: हर specific task के लिए एक subagent रखा, और implement-sprint को सिर्फ orchestrator की तरह इस्तेमाल किया। इससे हर sprint में code state review करना संभव हुआ और reliability काफी बढ़ी। अभी भी कई बार tests fail होने के बावजूद यह ‘done’ कह देता है, लेकिन फिर भी पूरे सिस्टम को खुद end-to-end देखने की तुलना में यह आसान है।<br /> मेरी मौजूदा परिकल्पना यह है कि Claude, TDD में कमजोर है। test पहले लिखने वाले चरण में इसे हमेशा दिक्कत होती है। अगली बार मैं implementation के बाद tests लिखने की approach आज़माने वाला हूँ। आदर्श तो नहीं है, लेकिन अगर इससे productivity बढ़ती है तो शायद यह सीधे coding करने से बेहतर रहेगा।

  • यह दिलचस्प लगा कि ज़्यादातर tools ‘spec first’ strategy पर केंद्रित हैं, लेकिन spec maintenance का तरीका अस्पष्ट है। मैं व्यक्तिगत रूप से अपने cofounder के साथ ‘spec as source’ पर पूरी तरह काम कर रहा हूँ। असली source के रूप में spec को इस्तेमाल करना मुझे सबसे रोचक use case लगता है, और मैं इसे व्यवहार में लाने की कोशिश कर रहा हूँ, लेकिन इसे वास्तव में स्थापित करना बहुत कठिन है। अगर किसी के पास इससे जुड़ा अनुभव या feedback हो तो ज़रूर सुनना चाहूँगा।<br /> हमारा प्रयोगात्मक product specific.dev भी अगर आपको रुचिकर लगे तो आज़माकर बताइए।

    • अगर spec सच में source है, तो वह spec खुद एक executable formal language (programming language) होनी चाहिए। वरना spec, spec ही रहेगी और source code, source code ही रहेगा। आखिरकार ‘good code’ क्या होता है, यह सीखना सबके लिए समान रूप से ज़रूरी है।

  • Kiro का spec-driven workflow इस्तेमाल किया तो उसने task list की बाढ़ लगा दी (हर task में 4 से ज़्यादा subtasks, और कुल 12 से ज़्यादा tasks)। workflow खुद बुरा नहीं था, लेकिन वह अनपेक्षित रूप से code delete कर देता था और rollback भी नहीं करता था। IDE बनाने की वजह से शायद resources UI exception handling में बँट जाते हैं। चीज़ों को बहुत छोटे हिस्सों में बाँटने से आसान, साधारण iteration के साथ सुधार करना ज़्यादा सरल है। यह वैसा है जैसे “अखरोट तोड़ने के लिए बहुत बड़ा हथौड़ा इस्तेमाल करना”।

  • custom slash commands के ज़रिए inputs को अच्छी तरह structured prompts में पैक करने का तरीका मुझे पसंद आया। agents.md जैसी files से निकले हिस्सों को context के रूप में साथ inject करना भी अच्छा लगा।<br /> लेकिन हर गाँठ खोलने की कोशिश करना कभी-कभी फिर वही बड़े हथौड़े से अखरोट तोड़ने जैसा लगता है, यानी अनावश्यक जटिलता पैदा करता है। फिर भी अगर ज़रूरत पड़ने पर ही अतिरिक्त slash commands (/experiment, /stub आदि) के ज़रिए context management को चुनिंदा रूप से इस्तेमाल किया जाए, तो यह हल्का रह सकता है। अंत में "/wrap-up" जैसी समापन command से सब कुछ एक बार में समेटा जा सकता है—जैसे surgery खत्म होने पर doctor पूरी जाँच कर ले।

  • SpecKit इस्तेमाल करते हुए मेरे मन में हमेशा यह सवाल रहा: “यह सारी specs एक single real ground truth में आखिर कब जुड़ेंगी?” अफ़सोस यह है कि ऐसा कोई चरण शायद है ही नहीं।<br /> अब लगता है कि इंसान और agent के बीच communication spec कैसी होनी चाहिए, इसे define/design करना अगला बड़ा काम है। Birgitta के बताए ‘spec anchored’ विचार को साकार करने के लिए मैं इसी पर सोच रहा हूँ।

    • AI के आने के बाद अब सच में लगता है कि ऐसे standards को define करने का समय आ गया है। specs इतनी formal होनी चाहिए कि इंसान उन्हें पढ़ और maintain कर सके, और कम-से-कम आंशिक रूप से LLM context में भी डाली जा सके। साथ ही, केवल कुछ information ingest करने पर भी core intent और design कायम रहे और व्यावहारिक काम आगे बढ़ सके।<br /> मुझे लगता है UML या Rational Rose जैसे प्रयास इसलिए विफल हुए क्योंकि उनमें intent ठोस रूप से शामिल नहीं था, वे बस diagrams तक सीमित रह गए, इसलिए उनका उपयोग केवल documentation, maintenance, और refactoring चरणों में हुआ। नतीजा यह हुआ कि वे तभी उपयोगी बने जब product पहले ही ship हो चुका था, और तब तक उनका महत्व काफी कम हो चुका था।<br /> अब C4 model जैसे नए तरीकों पर ध्यान जाने लगा है।

  • SDD अचानक इतना लोकप्रिय क्यों हो गया, यह तो पता नहीं, लेकिन व्यक्तिगत रूप से मुझे इसकी उपयोगिता बस इतनी लगती है कि spec files बनाकर ‘अंतिम परिणाम पहले से समझ’ लिया जाए, और project को छोटे हिस्सों में बाँटने पर progress track की जा सके। मैं कोई अलग tool या framework इस्तेमाल नहीं करता, सिर्फ markdown files का उपयोग करता हूँ। उससे ज़्यादा जटिल व्यवस्था में मुझे खास value नहीं दिखी।

  • spec-kit पहली बार इस्तेमाल करते समय मेरी उम्मीदें बहुत ऊँची थीं, लेकिन व्यवहार में उसने “गुफा में robot बनाने” स्तर तक के tasks गढ़ दिए, जबकि असल में सिर्फ एक screw कसना था। यानी वह साधारण काम को भी ज़रूरत से ज़्यादा बढ़ा देता था। बार-बार सुधार करते-करते मैं थक गया और अंत में छोड़ दिया। मुझे लगा कि workflow की यह अति-जटिलता इतनी है कि उसे ठीक करने की मेहनत भी सार्थक नहीं लगती।
 
jjw9512151 2025-10-20

असल में अगर आप इसे इस तरह समझें कि software engineering में सीखी गई चीज़ों को Markdown में किया जा रहा है, तो यह आसान और व्यावहारिक है। बस requirements specification अच्छे से लिखनी आती हो, वही काफ़ी है।