--- title: Spec-Driven Development with AI collection: Spec Driven Development for AI Apps author: Anirudh Jwala updated: 2026-10-21 source: https://docs.chaicode.com/sdd/intro --- # Spec-Driven Development with AI ## Spec-Driven Development with **AI** Spec-Driven Development with **AI** From vibe coding to building with intent. ## Hi, I'm **Anirudh Jwala** About the speaker Hi, I'm **Anirudh Jwala** Senior Software Engineer ยท Building & Teaching Software Early: Built products across SportsTech & EdTech Now: Working in **FinTech**, building software used by businesses Beyond Work: Teaching Java, Spring Boot & AI at ChaiCode More on: anirudhjwala.in ## Be **honest** for a second Quick question Be **honest** for a second How many of you have shipped something with **AI**? Could you explain why the AI made those **decisions**? ## "Add Event Bookings." What Did We Forget to **Decide**? Correct code, wrong problem "Add Event Bookings." What Did We Forget to **Decide**? Can a user book twice for the same event? Does cancelling release the seat? Can one user cancel another user's booking? What happens when two users grab the last seat at the same moment? The prompt 'Add event bookings' produces a button, an endpoint and a database insert, and it demos fine. But none of these rules were ever decided, so the AI either guessed or ignored them. The code is correct for the problem as it was stated. The problem was simply under-specified. ## How we work with AI has **changed** The shift How we work with AI has **changed** Autocomplete: AI types, you decide Prompt to code: AI writes functions Repo-aware agents: AI explores and changes your codebase Autonomous workflows: AI can plan, implement, and test The question: Who is making the **decisions** now? We started with autocomplete, where AI typed and we decided. Then came prompt to code, then agents that understand the repo and edit many files at once. Now autonomous workflows plan, build and test on their own. At each step we hand over more. The last box is the real question: who is making the decisions now? ## From delegating code to delegating **decisions** Delegating decisions From delegating code to delegating **decisions** "Build an event booking feature." "Choose how reservations should be stored." "Handle cancellations and edge cases." "Make whatever architectural changes are necessary." Look at how vague these prompts are. Each one quietly hands over a product decision, not just a coding task. 'Appropriately' and 'whatever needs improvement' leave the AI to guess what we meant. Key line: more context about the code is not the same as understanding the product's intent. ## Code is cheap. **Ownership** is not. Ownership Code is cheap. **Ownership** is not. Years, not hours: A feature built in an afternoon may need years of maintenance. Production doesn't care: AI-generated code can fail just like human-written code. The real test: Can your team understand, debug, and safely change what was shipped? Generating code is now fast and cheap. Living with that code is not. When production breaks, the model's name is irrelevant. What matters is whether your team can understand and fix the code. ## Your fundamentals are your **passport** Fundamentals Your fundamentals are your **passport** AI is your translator. AI helps you build beyond your familiar tech stack. Fundamentals help you question and verify what it builds. Knowing concurrency makes you ask: "What happens when two users book the last seat?" AI can translate your skills into a new language overnight. Fundamentals are what let you check whether that translation is actually right. For example, knowing what a race condition is makes you ask what happens when two people book the last seat. ## Two users, **one** seat, same moment The last seat Two users, **one** seat, same moment Did we ever define what the system must guarantee? ## Working code doesn't mean the right **problem** was solved. Working code doesn't mean the right **problem** was solved. Working code doesn't mean the right **problem** was solved. AI can propose requirements. But assumptions still need to be questioned, decisions made explicit, and outcomes verified. ## Why this matters for **you** Why it matters Why this matters for **you** Interviews โ†’ "I built it with AI" does not answer "Why did you design it this way?" Portfolio โ†’ One app with a real problem solved beats ten generic CRUD apps First job โ†’ You will join a codebase that neither you nor your agent wrote ## Two ways to describe the same **project** Same project Two ways to describe the same **project** Weak Built an event app using MERN and AI. Strong Capacity-safe booking system in MERN Atomic DB updates prevent overbooking Holds under concurrent requests Verified with a parallel-request integration test ## If AI can write the code, who defines what **correct** means? If AI can write the code, who defines what **correct** means? How do we make requirements explicit, reviewable, and verifiable?