नाम काफ़ी मज़ेदार है, हाहा

GitHub के Spec Kit का फ़ायदा यह है कि इसे GitHub Copilot में भी इस्तेमाल किया जा सकता है.
चूंकि यह GitHub ने बनाया है, इसलिए यह तो स्वाभाविक ही है? लेकिन कई दूसरे टूल्स Claude-आधारित थे.

ऐसा करने पर लगता है कि Hangul के साथ भी यह संभव हो सकता है... पहेलियाँ तो बनाई जा सकती हैं...

इसे मैं सिर्फ screening के लिए ही अच्छी तरह इस्तेमाल करूंगा

ट्रेडिंग ऑर्डर के मामले में prompt injection आदि की वजह से अनचाहे ऑर्डर प्रोसेस हो सकते हैं, इसलिए ऐसा लगता है कि ऑर्डर के लक्ष्य या राशि सीमा जैसी अतिरिक्त सुविधाएं अनिवार्य होंगी।

माफ़ कीजिए;;

मुझे Kiro IDE याद आ रहा है

धन्यवाद।

हाँ, मैं भी यही सोचता/सोचती हूँ. T_T

प्रयोग बहुत दिलचस्प था, अच्छी तरह देखा।

लगता है आपने हेडलाइन लिखने की ट्रेनिंग ली है..

अगर social media को समय की बर्बादी माना जाए, तो यह जुए या नशे की तरह ज़्यादा 'पछतावा' या 'शर्म' की भावना देता है।

दिलचस्प है। बात समझ में भी आती है

मुझे लगता है कि सामग्री से अलग, सिर्फ़ "एक लाइन के prompt" वाले शीर्षक की वजह से मैं कुछ और देखने आया था, इसलिए लेख की सामग्री और अपेक्षा के बीच का फर्क ज़्यादा महसूस हुआ।

k9s - टर्मिनल UI से Kubernetes क्लस्टर को मैनेज करने का टूल

लेख के बीच में SDD के विस्तृत परिचय का लिंक अच्छा है। नीचे उसका AI से किया गया सारांश है।

स्पेसिफिकेशन-ड्रिवन डेवलपमेंट (Specification-Driven Development, SDD)

The Power Inversion

• उस प्रवाह को उलट देता है जिसमें code केंद्र में होता था और PRD·design documents सहायक भूमिका में होते थे; यहाँ specification मूल स्रोत है और code एक अभिव्यक्ति है, जिसे किसी खास language·framework में implement किया जाता है
  • यह निदान पेश करता है कि specification और implementation के बीच का स्थायी अंतर केवल documents बढ़ाकर या process कड़ा करके दूर करना कठिन था
  • अगर executable specification और implementation plan code generate करें, तो यह अंतर गायब हो जाता है और केवल transformation बचता है
• AI जटिल specifications की व्याख्या और implementation plan बनाने में सक्षम बनाता है, लेकिन बिना संरचना के generation अव्यवस्था पैदा करता है; इसलिए SDD सटीक structure और guardrails के जरिए quality सुनिश्चित करता है
• maintenance specification के विकास का कार्य है, और development intent को natural language·design assets·core principles में व्यक्त किया जाता है; code की भूमिका last mile की होती है
• debugging में गलत code को सीधे ठीक करने से पहले specification·implementation plan को सुधारने को प्राथमिकता दी जाती है, और refactoring को clarity के पुनर्गठन के अर्थ में फिर से परिभाषित किया जाता है

The SDD Workflow in Practice

• ideas को AI के साथ conversational interaction के जरिए PRD में refine किया जाता है, और AI questions·edge cases·acceptance criteria को ठोस बनाता है
  • requirements और design को continuous activity में बदलकर team-स्तर पर branch-based specification work तथा review·versioning का समर्थन किया जाता है
• research agent library compatibility, performance, security, और organizational constraints (DB standards·authentication·deployment policies) की जांच करके उन्हें specification में अपने-आप शामिल करता है
• PRD से implementation plan बनाकर requirements और technical decisions को traceable तरीके से map किया जाता है, और AI contradictions·ambiguity·omissions की लगातार जांच करता है
• जब specification और plan पर्याप्त रूप से स्थिर हो जाते हैं, तब code generation शुरू किया जाता है; शुरुआत में exploratory generation से feasibility को validate किया जाता है
  • domain concepts को data models, user stories को API endpoints, और acceptance scenarios को tests में बदला जाता है
• operational चरण के metrics·incidents specification को update करते हैं ताकि अगली regeneration में वे परिलक्षित हों; performance bottlenecks को non-functional requirements और vulnerabilities को global constraints के रूप में उन्नत किया जाता है

Why SDD Matters Now

• AI capability threshold: अब natural language specifications से working code को भरोसेमंद ढंग से generate करना संभव है, और implementation translation के mechanical हिस्सों के automation से exploration और creativity amplification को समर्थन मिलता है
• complexity explosion: बहुत-सी services·frameworks·dependencies के कारण intent-implementation alignment बनाए रखना कठिन हो गया है, इसलिए SDD की specification-driven alignment की ज़रूरत है
• accelerating change: बार-बार pivot की स्थितियों में SDD बदलावों को documents-design-code में manual propagation की बजाय systematic regeneration से संभालता है
  • उदाहरण के तौर पर, यह what-if simulation और parallel implementation को संभव बनाकर decision-making agility देता है

Core Principles

• specification = common language: specification first-class output है, code किसी खास stack की expression है, और maintenance specification evolution की क्रिया है
• executable specification: सटीक·पूर्ण·अस्पष्टतारहित स्तर की specification से working system generate किया जाता है
• continuous refinement: one-time gate के बजाय लगातार consistency validation किया जाता है
• research-based context: performance·security·organizational constraints को निरंतर एकत्र करके specification में डाला जाता है
• bidirectional feedback: operational reality specification update input बनती है
• branching for exploration: एक ही specification से performance·maintainability·UX·cost जैसे optimization goals के अनुसार multiple implementations generate करने का समर्थन

Implementation Approaches

• आज के व्यवहारिक प्रयोग में मौजूदा tools के संयोजन और discipline बनाए रखना मुख्य है, और इसे निम्न तत्वों से लागू किया जा सकता है
  • specification की iterative refinement के लिए AI assistant
  • technical context इकट्ठा करने के लिए research agent
  • specification→implementation transformation के लिए code generation tools
  • specification-first workflow के अनुरूप version control
  • specification documents की AI consistency analysis आधारित checking
• साझा सिद्धांत यह है कि specification को single source of truth रखा जाए और code को specification द्वारा मांगा गया output माना जाए

Streamlining SDD with Commands

• /specify: feature description को structured specification में बदलता है और automatic numbering, branch creation, तथा template-based directory setup को automate करता है
• /plan: specification analysis → constitution compliance review → technical translation → data model·API contracts·test scenarios documentation → quickstart validation तैयार करता है
• /tasks: plan.md और संबंधित design को पढ़कर actionable task list बनाता है, और parallelizable tasks की पहचान तथा सुरक्षित parallel grouping देता है
• उदाहरण: chat feature
  • पारंपरिक approach में लगभग 12 घंटे के document work को specification·plan·tasks automation से लगभग 15 मिनट की setup तक घटाने वाला flow दिखाया गया है
  • outputs में specification, implementation plan और rationale, API contracts·data model, quickstart scenario, और tasks.md को branch में version control किया जाता है

The Power of Structured Automation

• missing items की रोकथाम: templates non-functional requirements·error handling तक को cover करते हैं
• decision traceability: हर technical choice specific requirement से जुड़ी होती है
• living documents: specification code generate करती है, इसलिए synchronization बनाए रखना आसान होता है
• rapid iteration: requirement बदलने पर plan regeneration से मिनटों या घंटों के स्तर पर प्रतिक्रिया संभव होती है

Template-Driven Quality

• implementation details के जल्दबाज़ी में घुस आने की रोकथाम: WHAT/WHY पर फोकस और HOW को बाहर रखने का नियम abstraction level बनाए रखने में मदद करता है
• uncertainty markers को अनिवार्य करना: [NEEDS CLARIFICATION] marker के जरिए guesswork पर रोक और स्पष्ट सवाल पूछने को बढ़ावा दिया जाता है
• checklist-based self-review: completeness·clarity·measurable acceptance criteria की जांच से quality gate लागू होता है
• constitution gate: simplicity gate (≤3 projects), anti-abstraction gate (frameworks का direct use), integration-first gate (contracts·contract tests पहले) जैसे pre-phase (-1) checks लागू किए जाते हैं
• layered detail management: अत्यधिक code और details को implementation-details/ में अलग रखकर readability बनाए रखी जाती है
• test prioritization: contract→integration→E2E→unit क्रम में file creation·test-first नियमों से verifiability सुनिश्चित की जाती है
• assumptions और speculative features पर नियंत्रण: speculative features पर रोक और phase-wise prerequisites की स्पष्टता से scope management मजबूत होता है

The Constitutional Foundation

• memory/constitution.md के immutable principles के आधार पर सभी implementations को consistent·simple·high-quality बनाए रखने वाली development constitution अपनाई जाती है
  • Article I: Library-First — हर feature independent library के रूप में शुरू होता है ताकि modularity सुनिश्चित हो
  • Article II: CLI Mandate — हर library text I/O·JSON को support करने वाला CLI interface expose करती है, जिससे observability और testing ease सुनिश्चित होती है
  • Article III: Test-First — test approval और failure (red) की पुष्टि से पहले implementation नहीं, तथा behavior definition first सिद्धांत लागू होता है
  • Articles VII & VIII: simplicity·anti-abstraction — project count को न्यूनतम रखना और frameworks पर direct भरोसा करना, ताकि over-engineering रोका जा सके
  • Article IX: integration-first testing — real-environment-जैसी testing को प्राथमिकता दी जाती है और contract testing को implementation से पहले अनिवार्य किया जाता है
• templates के Phase -1 gate के जरिए constitution compliance को checklist में बदला जाता है, और exceptions के लिए Complexity Tracking में स्पष्ट rationale दर्ज किया जाता है
• amendment procedure के जरिए principles के लागू करने के तरीके विकसित हो सकते हैं, लेकिन core philosophy बनी रहती है

The Transformation

• लक्ष्य developers को replace करना नहीं, बल्कि mechanical translation के automation से human capability amplification और intent-implementation alignment बनाए रखना है
• SDD specification से code को generate कराता है, जिससे specification·research·code एक tight feedback loop में साथ-साथ विकसित होने वाले continuous transformation का अभ्यास करते हैं

बिग ब्रदर का source code लीक!

और, आपने prompt chaining की संख्या वाले प्रयोग के बारे में भी पूछा था।

असल में, उलटे तौर पर देखें तो यह लेखक के लिए बोलचाल की भाषा में कहें तो धोखा देने का एक अच्छा तत्व भी बन सकता है।

development की प्रक्रिया में आगे बढ़ने के लिए अपने-आप में बहुत सारे विकल्प होते हैं, और अगर prompts को इस तरह जमा कर दिया जाए कि token usage ज्यादा बढ़ने लगे, तो वह आंकड़ा snowball की तरह और भी बड़ा होता जाएगा।

शोध में 'Cumulative Science' नाम की एक दर्शन-धारा है।

कम-से-कम मेरे मानदंड के अनुसार, मुझे अब तक एक बार के command में token usage पर कोई शोध कभी नहीं मिला,

इसलिए तुरंत N बार का शोध करने के बजाय, मैंने एक निश्चित single-run test और उसके निष्कर्ष पर ध्यान केंद्रित किया,

और N बार वाला शोध इस प्रयोग के बाद आगे की कड़ी के रूप में जारी रखा जा सकता है।

अगर आप civil engineering जैसी चीज़ें करते हैं, तो इसे विश्वविद्यालय की कक्षाओं में भी पहले से इस्तेमाल किया जा रहा है।

साथ ही, एक दूसरी पोस्ट में मैंने codebase के अंतर के अनुसार AI के व्यवहार में आने वाले फर्क पर भी बात की थी.
(यह भी GeekNews में परिचित कराया गया था: https://modgo.org/aineun-hyeonjae-kodeu-gujoyi-byeoge-maghyeoissda/)

संक्षेप में कहें तो, इसमें यह test और उसके नतीजे शामिल हैं कि AI को input के रूप में दिए जाने वाले codebase के अनुसार output की quality बदल जाती है.

शुरुआती codebase की quality और दिशा के आधार पर, आगे बनने वाले code की quality बनी रह सकती है, या लगातार खराब भी हो सकती है.

यानी, project के शुरुआती चरण में refactoring की cost और काफी आगे बढ़ चुके project में refactoring की cost में बहुत बड़ा अंतर हो सकता है.

अगर प्रश्न पूछने वाले डेवलपर हैं, तो हो सकता है आपने 'पाल-नाव पर विमानवाहक पोत' जैसी अभिव्यक्ति कभी सुनी हो.

Refactoring किस समय की जानी चाहिए, या project की शुरुआती philosophy और design के अनुसार इसकी लागत कितनी बदल सकती है, यह एक गहन विषय है.

इसे एक variable के रूप में शामिल करके निष्कर्ष को अस्थिर बनाने के बजाय,

मैंने ऐसा test किया जिसे कम-से-कम इस निष्कर्ष के साथ साफ़ तौर पर समझाया जा सके कि 'अच्छी codebase quality होने पर token usage कम हो जाता है'.