Spec Driven Development and Managing software projects in 2026 using AI development tools
Bottom Line Up Front: AI tools now generate code faster than teams can review it, and the old process of catching mistakes in pull requests…
Spec Driven Development and Managing software projects in 2026 using AI development tools
Bottom Line Up Front: AI tools now generate code faster than teams can review it, and the old process of catching mistakes in pull requests can’t keep up. The fix is to move the real thinking upstream into specs and designs that the whole team reviews before any code exists. This article lays out three workflows scaled to the size of the work: vibe coding for small changes, spec-driven development for standard features, and design-driven parallelism for large multi-engineer efforts. Engineering managers should start by having the team read and discuss the spec-driven development articles from GitHub, Thoughtworks by Martin Fowler, linked in the sources below, then get hands-on with the tooling. In our case, that’s Kiro; take the time to understand its full feature set, including specs, agent hooks, and EARS-formatted requirements, before applying it to real work. Pick one upcoming feature, write a short spec, review it as a team, and build from there.
The software development lifecycle has looked roughly the same for decades. Requirements come in from the product manager. Engineering interprets them and then go a few rounds back and forth. Engineers write code. That code then gets reviewed. QA tests it. It ships! If something was misunderstood along the way, you find out late, if you are lucky, in a code review, maybe in QA, or worst case, in production after users are already hitting it. The phases are well known: plan, design, develop, test, deploy, and maintain. But on most teams, the planning and design phases are thin. The real decisions happen during development, buried in pull requests that are hard to see, hard to review, and expensive to change.
That worked well enough for a long time. But AI changed the equation. When tools like Kiro, Cursor, and Claude Code can generate hundreds of lines of implementation in minutes, the bottleneck isn’t writing code anymore. The bottleneck is making sure you’re building the right thing. The development phase of the SDLC got faster, but planning and design didn’t keep up. Teams are now generating code at unprecedented speed and spending just as much time, sometimes more, fixing misunderstandings, reworking implementations, and debating decisions in pull requests that should have been made before anyone opened an editor.
Spec-driven development forces teams to move down the SDLC, pulling the real thinking forward into the planning and design phases, and makes those phases structured, reviewable, and directly connected to the implementation. The spec becomes the source of truth. The design becomes the blueprint. The tasks become the contract. The code becomes a derived artifact, generated from a plan that the entire team has already agreed on. Tools like Kiro formalize this into a concrete workflow: requirements written in EARS notation (Easy Approach to Requirements Syntax, a structured way of writing acceptance criteria that originated in aerospace engineering at Rolls-Royce and uses patterns like “WHEN [condition] THE SYSTEM SHALL [expected behavior]” to make every requirement testable and unambiguous), a technical design document, a sequenced task list, and then AI-assisted implementation. The SDLC doesn’t disappear. It just gets rebalanced so that the most important decisions happen at the least expensive point in the process, before any code exists.
We adopted this approach on our small team, and over time, we developed three distinct workflows that we use depending on the size of the work.
The Old Way Was Fine Until It Wasn’t
On a small team, you can get away with a lot of informal process. Someone grabs a ticket, asks a couple of questions in Slack, and starts building. If they’re a strong engineer, the result is usually good. If there’s a misunderstanding, it shows up in code review, and you course-correct.
The problem is that course-correcting in code review is expensive. The engineer already spent two days building something. They made dozens of small decisions along the way. Changing direction at that point means throwing away real work, which is frustrating for everyone. The reviewer is looking at a finished implementation and trying to reverse-engineer the intent behind it, which is a terrible way to evaluate whether something was designed well.
We were spending more time debating decisions in pull requests than we were spending making the decisions in the first place. That’s backwards.
Three Workflows for Three Sizes of Work
Not every piece of work needs the same amount of process. A one-line bug fix doesn’t need a design document. A three-month platform migration doesn’t belong in a single Kiro session. We landed on three workflows that scale to the size of the problem. We use all three, sometimes in the same sprint.
Workflow 1: The Vibe-Coded Change. For small, well-understood changes. Bug fixes, config updates, simple refactors, anything where the scope is obvious, and the risk is low. An engineer sits down with an AI tool, describes what needs to happen, and lets the AI generate the code. No spec. No design doc. The engineer knows what to do, the AI knows how to do it, and the pull request is straightforward enough that a reviewer can evaluate it quickly.
Vibe coding has a real place in the workflow. Not everything needs ceremony. The mistake teams make is applying this approach to everything, including work that is too ambiguous or too large for it. When you vibe code a complex feature, the AI is guessing at hundreds of unstated requirements, and the result is code that technically runs but doesn’t actually solve the right problem.
Workflow 2: Spec-Driven Development. For standard features. The kind of work that would normally take a few days to a week involves some real decisions about approach and benefits from the team being aligned before implementation starts.
The process has four stages, and the team collectively reviews at each one before moving to the next.
First is the spec, which we also call the requirements document; think of that as an interchangeable term. Before anyone opens an editor, we write a plain-language description of what we’re building and why. What problem are we solving? Who is it for? What does success look like? What are the constraints? What are we explicitly not doing? Usually, a page or two of markdown.
The whole team reviews the spec. The most valuable conversations happen here because at this stage, changing direction is free. Nobody has written any code yet. Nobody’s attached to an implementation. You can argue about scope, question assumptions, and catch misunderstandings when it costs nothing to fix them.
Second is the design. Once the spec is solid, we use Kiro to generate a technical design document based on the approved requirements. Kiro analyzes the spec and your existing codebase and produces a design that includes the architecture, data flow, interfaces, and implementation considerations. If you have set up Kiro correctly, it knows your team's coding standards, security best practices, current architecture, etc. It’s a strong starting point, and it saves a lot of time compared to writing the design from scratch. But it’s a starting point, not a finished product. The team needs to review this carefully. Kiro doesn’t know about your scale requirements, the scope constraints your team is operating under, or how this feature needs to fit with future growth plans. It doesn’t know which service is about to be deprecated, or the performance bottleneck your team learned about the hard way last quarter. Engineers need to read through the generated design and pressure-test it. Does this architecture actually make sense for our system? Are the API contracts right? Are there edge cases Kiro missed? Are there simpler approaches it didn’t consider? This review is not a rubber stamp. It’s where your senior engineers and architects add the judgment that AI can’t.
Third is the task breakdown. Kiro generates a sequenced list of implementation tasks from the approved design, with each task scoped to a specific piece of work and traceable back to the original requirements. Again, this is a huge time saver, but it still needs human eyes on it. Are the tasks scoped correctly? Is the sequencing right, or does Kiro have a dependency backwards? Are there tasks missing that only someone who knows the codebase would catch? Review the task list as a team. Make sure every engineer who’s going to pick up a task understands what it’s asking for and agrees that it’s well-defined.
These reviews at each stage are the whole point. Kiro accelerates the creation of these artifacts, but if you skip the reviews and just let Kiro run from spec to design to tasks to code without stopping, you’ve built an expensive vibe coding pipeline with more steps.
Only after all three stages have been reviewed and agreed on do we let AI generate the code. The AI has a clear, well-scoped task with explicit inputs, outputs, constraints, and context. It’s not guessing. It’s executing a plan that the whole team has already agreed on.
GitHub open-sourced a toolkit called Spec Kit in 2025 that formalizes this exact workflow. AWS built a similar three-phase workflow into Kiro. Thoughtworks wrote about spec-driven development being one of the most important engineering practices to emerge in 2025. The industry is converging on the same conclusion, but the management of this type of development is lagging behind the tooling, and it’s up to your team to trial-and-error what works and what doesn’t.
Workflow 3: Design-Driven Parallelism. For larger features. The kind of work that touches multiple services, spans several weeks, and needs three or four engineers working simultaneously.
The design is hand-generated with AI tools assisting. In this workflow, the execution happens in parallel across the team through a roadmap of mini specs.
For a large feature, you don’t start with a quick spec in Kiro and let it generate the design. You hand-write the design yourself, but you write it in the same structured format that Kiro produces. Same sections, same level of detail, same way of thinking about requirements, acceptance criteria, and technical approach. You can use Kiro to help with this. Let it generate a first pass of the design document, then rework it by hand. Or use it to pressure-test sections, fill in edge cases, or structure your thinking into Kiro’s format while you maintain creative control over the actual decisions. The engineer / TPM / PM is driving. Kiro is an accelerant. A large feature has too many interconnected decisions and tradeoffs for the AI to own without deep context about your system, your team, and your business. But having the design in Kiro’s structured format means every engineer on the team can read it the same way, and it plugs directly into the tooling downstream.
Once that hand-crafted design is reviewed and agreed on by the team, you work toward parallelism in the tasking phase. Instead of creating a single linear task list, you create a roadmap that contains all of the parallel tasks. You look at the design and identify the blocks that can be built independently. The authentication service doesn’t need to wait for the notification system. The API layer can be built alongside the data model. The frontend components can be stubbed and developed against a contract while the backend is being wired up.
Each parallel task on the roadmap gets its own mini spec prompt. These mini specs are what actually create the individual blocks of code. They’re self-contained instructions that have everything an engineer and their AI tooling need to build that specific block: the inputs, the outputs, the contracts with adjacent blocks, the acceptance criteria, and the constraints. Each mini spec is small enough to be executed independently but precise enough that when all the blocks come together, they fit. The roadmap is the master plan, and each mini spec prompt is a work order that can be handed to any engineer on the team and executed with AI in parallel.
This distribution is what makes larger features possible in parallel. Instead of one engineer working through a long sequential task list, you’ve got three or four engineers, each with their own mini spec prompt and their own AI tooling, working on separate blocks at the same time. The blocks integrate cleanly because the hand-written design already defined the interfaces between them.
The roadmap becomes a visual map of what’s happening in parallel, what depends on what, and where the integration points are. It looks less like a backlog and more like a circuit diagram. When a block is complete, it gets reviewed against its mini spec and integrated. When all the blocks are in, the feature is done.
Without this workflow, a big feature means one or two engineers' heads-down for weeks while the rest of the team works on other things. With design-driven parallelism, the entire team can swarm on a large feature together. Everyone has context because they all reviewed the design. Everyone has a clear, scoped block to own. The blocks are designed to be independent, so people aren’t stepping on each other. And because each block has its own mini spec, the AI-generated code is just as well-directed as it would be for a small feature.
Same principle as spec-driven development, just applied recursively. The feature-level design decomposes into blocks, and each block runs its own version of the spec-design-tasks-code cycle in parallel.
Picking the Right Workflow
The three workflows aren’t a progression where one is better than the others. They’re tools for different situations, and knowing when to use which one is a management skill in itself. The amount of upfront thinking scales with the size and complexity of the work: quick and in the engineer’s head for vibe coding, explicit and team-reviewed for spec-driven development, deep and structured for design-driven parallelism.
Why the Collective Review Matters
Across both spec-driven development and design-driven parallelism, the collective review is what makes everything work. After the team has reviewed the spec and the design, every engineer knows what’s being built, why it’s being built that way, and what the tasks are. No surprises in code review.
I didn’t expect what happened next. The process didn’t just improve our code quality. It made the team feel more connected to the work. Engineers who used to only see their own tickets now had context on everything the team was building. Junior engineers got to participate in design conversations they would have been excluded from in a code-first workflow. The spec review became a place where everyone’s input mattered, regardless of seniority or even job family.
Code reviews got dramatically simpler, too. When the reviewer already knows the spec, the design, and the task breakdown, they’re not trying to figure out what the code is supposed to do. They’re checking that it did what was already agreed on. Reviews that used to take an hour now take fifteen minutes.
Onboarding gets easier. New engineers can read the spec folder and understand not just what was built, but why. The specs became living documentation that actually stayed current, because they were the starting point for every feature, not an afterthought.
Getting Product Into the Process
All of this works even better when the requirements themselves come in structured form, and you can extend the process upstream to product managers and stakeholders.
You can use Kiro here too. A product manager writes their requirements in plain language, feeds them into Kiro, and lets it generate structured user stories and acceptance criteria using that same EARS notation described earlier. Kiro is surprisingly good at unpacking a casual description into detailed requirements, catching edge cases that the product manager might not have considered. The product manager reviews and refines the output, fills in the gaps, and corrects anything Kiro got wrong. The end product is a requirements document that both product and engineering can read, agree on, and trace through to the final implementation.
When product managers write requirements in the same structured format that feeds directly into the engineering workflow, there’s one shared document that everyone is working from. Misinterpretations get caught at the requirements review, not in production.
Hooks: Validating Changes in the Workflow
Once your specs, designs, and tasks are in place, you still need a way to make sure the actual implementation stays aligned with what was agreed on.
Kiro supports agent hooks, automated actions that trigger on events in your development workflow. You define the event type (a file save, a file creation, a task starting or completing), you define which files should trigger it (like any file matching src/**/*.tsx), and you define the instructions for what should happen. The hook runs automatically, without anyone having to remember to do it.
You can set up a hook that fires every time a React component file is saved, and automatically creates or updates the corresponding test file. You can set up a hook that validates your UI changes against a Figma design using an MCP server. You can set up a hook that checks whether a completed task’s output actually satisfies the acceptance criteria in the requirements doc.
This turns the spec from a static planning document into an active validation layer. Without hooks, the spec tells you what should be built, but it’s on the humans to verify that what was built matches. With hooks, verification happens continuously as code is written. If an engineer’s implementation drifts from the spec, the hook catches it in real time instead of waiting for a reviewer to notice it later.
For the parallel workflow in particular, hooks become essential. When you’ve got multiple engineers building separate blocks simultaneously, you need automated checks that each block is staying within its contract. A hook that validates API contracts, checks that data structures match the shared interfaces from the design doc, or flags when a new dependency is introduced that wasn’t in the task spec, gives you confidence that the blocks will actually integrate cleanly when they come together.
Hooks don’t replace human review. They handle the mechanical validation so that when a human reviewer sits down with the code, they can focus on the judgment calls, the architectural decisions, the things that require actual thinking instead of catching the stuff a machine should have caught.
How to Start
Start with the basic spec-driven workflow. Pick one standard feature. Write a one-page spec before anyone starts coding. Have the team review it together. Then write a short design. Review that. Break it into tasks. Review those. Then build it, with or without AI.
Once spec-driven development feels natural, try design-driven parallelism on something bigger. Hand-write a design for a multi-week feature, decompose it into independent blocks, write a mini spec for each block, and assign them across the team. You’ll be amazed at how much faster a small team can move when everyone is building in parallel against well-defined interfaces instead of waiting in a sequential queue.
And keep vibe coding for the small stuff. Not everything needs a spec. The skill is matching the workflow to the work.
This Isn’t Optional
AI code generation is already here, and it’s only getting faster. If your engineers aren’t using it through an official workflow, they’re using it on their own, vibe coding features with Copilot or Claude Code and submitting pull requests that no one can meaningfully review because there’s no spec, no design, and no shared understanding of what the code was supposed to do.
That’s the trajectory for any team that doesn’t evolve its process. When AI writes the code from a vague prompt, the decisions are in nobody’s head. The code is an artifact of a conversation that happened between one engineer and a language model, and that conversation disappears the moment the chat window closes.
Traditional code review can’t scale to this. Manual QA can’t scale to this. The old SDLC assumed that development was the slow part, and testing was where you caught the mistakes. When development takes minutes instead of days, testing and review become the bottleneck, and they break under the volume unless you’ve moved the quality upstream into specs and designs that were reviewed before any code was generated.
Every major tooling company is already moving in this direction. GitHub built Spec Kit. AWS built Kiro. Thoughtworks named spec-driven development one of the defining engineering practices of 2025. Gartner predicts 90% of enterprise software engineers will use AI code assistants by 2028. The infrastructure for spec-driven workflows is being built right now, and the teams that are already practicing it will have a significant advantage over those who are still trying to review AI-generated code the old way.
You can design that evolution intentionally, or you can wait until the problems force your hand. Your team’s job is to think. AI’s job is to type. These three workflows just make that division of labor explicit, and give you a way to scale it from a one-line fix to a multi-month feature.
By Joshua McDonald on April 2, 2026.
Exported from Medium on August 26, 2026.
Reader discussion