Un developers ke beech jo Claude Code se reliable output paate hain aur un developers ke beech jo apna aadha din agent ne jo banaya usse undo karne mein bitaate hain, ek badhta hua gap hai. Yeh farq talent, experience, ya koi secret prompt engineering trick nahi hai. Yeh methodology ka sawaal hai. Jo developers AI agents ke saath production software ship kar rahe hain, woh ek pattern par converge ho gaye hain, chahe woh ise kuch bhi kehte hon: agent ke code likhna shuru karne se pehle define karo ki tumhe kya chahiye.
Yeh article us pattern ko ek naam deta hai. Spec-first development AI-assisted software engineering ke liye ek methodology hai. Koi vague "best practice" nahi. Ek structured, repeatable lifecycle jismein defined phases, clear checkpoints, aur har step par concrete artifacts hain. Agar tum ek aisa tarika dhundh rahe ho jisse Claude Code ka output itna predictable ho ki tum apna release schedule us par daaon laga sako, toh yeh woh framework hai.
Vibe Coding ki seema
"Vibe coding" 2025 ki shuruat mein vocabulary mein aaya. Pitch yeh thi: natural language mein describe karo ki kya chahiye, AI ko likhne do, iterate karo jab tak sahi na lage. Prototypes, weekend projects, aur one-off scripts ke liye vibe coding kaam karta hai. Tez kuch functional mil jaata hai, aur agar baad mein toote, toh stakes kam hain.
Production software alag constraints ke andar operate karta hai. Code ko existing codebase mein integrate hona chahiye, specific requirements satisfy karni chahiye, aur un logon ke contact ko survive karna chahiye jo ise maintain karenge. Jab vibe coding in constraints se milta hai, failure modes predictable hain.
Pehla failure drift hai. Tum ek feature loosely describe karte ho, agent apni interpretation implement karta hai, tum adjust karte ho, agent apni adjusted interpretation reimplements karta hai. Teen iterations baad, tumhare paas working code hai jo tumhari kisi bhi original requirement ko satisfy nahi karta kyunki har iteration ne target ko shift kar diya. Tum us cheez ki taraf converge ho rahe ho jo agent sochta hai ki tum chahte ho, na ki jo tumhe actually chahiye.
Doosra failure invisible decisions hai. Tumhari description mein har gap ek decision hai jo agent silently leta hai. Database schema, error handling strategy, API shape, validation rules, library choices. Tum in decisions ko code review ke dauran discover karte ho, ya isse bhi bura, production mein. Agent ne bure decisions nahi liye. Usne uninstructed decisions liye, aur tumhare paas unhe pakadne ka koi mechanism nahi tha pehle se implementation mein bake hone se.
Teesra failure review paralysis hai. Ek 600-line diff jahan agent ne architecture, data model, error codes, aur edge case handling choose kiya hai, traditional sense mein reviewable nahi hai. Tum code ko spec ke against review nahi kar rahe. Tum code se spec reconstruct kar rahe ho, phir decide kar rahe ho ki tum agree karte ho ya nahi. Yeh zyada time leta hai spec likhne se.
Vibe coding ceiling hit karta hai kyunki yeh do alag activities ko conflate karta hai: decide karna ki kya banana hai aur use banana. Spec-first development inhe alag karta hai.
Ek methodology ke roop mein Spec-First
Spec-first development ek four-phase lifecycle hai. Har phase ek concrete artifact produce karta hai. Har transition ki ek clear gate condition hai. Methodology kisi bhi AI coding agent ke saath kaam karti hai, lekin is article ke examples Claude Code use karte hain kyunki wahan community sabse tez iterate kar rahi hai.
Phase 1: Brainstorm
Tum aur agent (ya sirf tum) problem space explore karte ho. Constraints kya hain? Kaunse approaches hain? Tradeoffs kya hain? Yeh conversational hai. Tum kisi cheez ke liye commit nahi ho rahe. Tum territory map kar rahe ho.
Gate condition: tumhare paas ek preferred approach hai aur tum articulate kar sakte ho ki yeh approach alternatives ke upar kyun.
Claude Code ke saath brainstorming valuable hai kyunki agent ke paas patterns aur libraries ka broad knowledge hai. Galti yeh hai ki brainstorm se seedha code par kood jaao. Brainstorm options surface karta hai. Yeh unke beech choose nahi karta. Woh tum karte ho.
Phase 2: Spec
Tum decision likh lete ho. Yeh woh contract hai jiske against agent implement karega. Ek spec user story nahi hai, Jira ticket nahi hai, prose ka paragraph nahi hai. Yeh ek structured document hai jismein:
- Problem statement: kya toota hua hai ya missing hai, concrete terms mein
- Proposed approach: brainstorm phase se chosen solution
- Files affected: agent ko kaunsi files touch karni chahiye (aur implicitly, kaunsi nahi)
- Acceptance criteria: testable conditions jo "done" define karte hain
- Out of scope: agent ko explicitly kya avoid karna chahiye
Acceptance criteria sabse important element hain. Har ek concrete action honi chahiye jiska observable outcome ho. "Authentication kaam karna chahiye" criterion nahi hai. "Valid credentials submit karne par 200 aur session token mile; invalid credentials submit karne par 401 bina token ke" criterion hai.
Out-of-scope section gold-plating rokta hai. Iske bina, agents adjacent code "improve" karenge, jo files unhe messy lagi unhe refactor karenge, ya related lagane wali features add karenge. Har minute jo agent unrequested kaam par kharach karta hai woh minute hai jo tum unrequested kaam review karne mein kharach karte ho.
Gate condition: koi jo brainstorm mein nahi tha woh yeh spec padhke sahi cheez bana sake.
Phase 3: Implementation
Agent spec ke against execute karta hai. Conversation ke against nahi. Jo discuss kiya uski memory ke against nahi. Ek concrete document ke against jismein testable criteria hain.
Code likhne se pehle, agent ek plan produce karta hai: ek numbered list changes ki jo woh karna chahta hai, kaunsi files modify karega, aur result kaise verify karega. Yeh plan ek two-minute checkpoint hai. Tum ise padhte ho, confirm karte ho ki yeh tumhari intent se match karta hai, aur implementation ko green-light dete ho. Ya tum misunderstanding pakad lete ho aur correct karte ho. Dono taraf se, tumne bees ki jagah do minute lagaye.
Plan-before-code pattern bureaucracy nahi hai. Yeh poore workflow mein single highest-leverage intervention hai. Zyaadatar implementation mistakes coding errors nahi hain. Woh comprehension errors hain: agent ne spec ko galat samjha. Ek comprehension error ko plan mein pakadna do minute ka hai. Ise 400-line diff mein pakadna bees minute ka hai. Ise production mein pakadna ek din ka hai.
Gate condition: agent ne ek completion report post kiya hai specific claims ke saath ki kya banaya gaya aur kaise verify kiya gaya.
Phase 4: Verification
Tum ya QA process implementation ko spec ke against confirm karte ho. "Kya yeh sahi lagta hai?" nahi balki "kya yeh har acceptance criterion satisfy karta hai?"
Verification mechanical hai. Tum spec se har criterion lete ho, test execute karte ho (command run karo, browser kholo, event trigger karo) aur result record karte ho: pass ya fail. Jo criteria fail hote hain woh Phase 3 mein wapas jaate hain. Verification implementation ke saath document hoti hai taaki koi bhi jo task chhe mahine baad padhe woh exactly dekh sake kya test hua tha.
Gate condition: har acceptance criterion ka ek recorded pass/fail result hai.
Yeh complete lifecycle hai. Chaar phases, chaar artifacts (approach rationale, spec, implementation plan, verification record), chaar gate conditions. Phases sequential hain lekin lightweight. Ek medium-sized feature ke liye, phases 1 aur 2 mein 15-20 minute lagte hain. Phase 3 implementation jitna time le. Phase 4 mein 5-10 minute.
Yeh agents ke saath humans se zyada kyun matter karta hai
Specs likhne ka har argument AI se pehle ka hai. "Requirements pehle likho code se" yeh advice hamare mein se zyaadatar ke paida hone se pehle se hai. Toh phir ise AI-assisted development ke liye specific kyun frame karna?
Kyunki agents cost function badal dete hain.
Ek human developer jo vague requirement receive karta hai woh rukega aur sawaal poochhega. "Password auth ya SSO?" "Mobile par kaam karna chahiye?" "Jab token expire ho tab kya hoga?" Har sawaal ek mini-checkpoint hai jo implementation ko sahi target ki taraf dhakelta hai. Human developer ke saath vague spec ki cost kuch Slack threads aur shayad ek dopahar ka rework hai.
Ek agent jo vague requirement receive karta hai nahi rukega. Woh har ambiguous decision silently lega, ek approach par commit karega, aur tumhe ek finished implementation present karega. Agent ke saath vague spec ki cost ek finished implementation hai jo shayad poori tarah galat ho, plus woh time jo tumhe discover karne mein lagta hai ki woh galat hai, plus woh time jo ise dubara karne mein lagta hai.
Asymmetry stark hai. Agents execution mein humans se tez hain aur judgment mein bure. Spec mein har ambiguity ek judgment call hai, aur har judgment call jo agent bina guidance ke leta hai woh ek coin flip hai ki result tumhari intent se match karega ya nahi. Ek spec coin flips eliminate karti hai.
Ek doosri, zyada subtle wajah hai. Agents push back nahi karte. Ek senior engineer jo buri spec receive karta hai bolega "yeh sense nahi banata X ki wajah se." Ek agent buri spec ko faithfully implement karega aur faithfully galat output produce karega. Spec-first development tumhe majboor karta hai ki tum apni soch ko pressure-test karo pehle ise us entity ko dene se jo ise bina sawaal ke execute karegi. Spec sirf agent ke liye nahi hai. Woh tumhare liye hai.