Trying Spec-Driven Development with AI Tools

I have started to accept something I was avoiding for a while: when I lack time, resources, or energy, I may sometimes have to use AI while writing software.

I have used AI before for frontend work and styling. Small things. Low-risk things. But I never really wanted anything AI-generated to touch anything remotely important.

This week I challenged myself to be a bit more open-minded. Not to treat AI as a magical engineer, but as a very clever and sophisticated autocomplete tool — something that might help me spend more time on the parts I enjoy most:

• architecture
• system design
• making systems do things they were probably not meant to do
• exploring ideas faster

So I tried to look into this more properly. One concept that stood out was Spec-Driven Development, or SDD.

These are my notes and thoughts so far.

What I Understand Spec-Driven Development To Be

Spec-Driven Development is basically the idea that the specification becomes the source of truth.

Instead of having a loose conversation with an AI coding assistant like:

“Can you build this feature?”

You write a more deliberate blueprint first. That blueprint might be a markdown file, a technical spec, a requirements document, or some structured format. The AI agent then uses that spec as the main constraint for generating code.

The appeal is obvious: if AI is going to help write code, I would rather have it follow a clear plan than improvise based on vague prompts.

In theory, this gives you:

• clearer requirements
• fewer random implementation choices
• better architectural boundaries
• a record of why something was built
• a way to review the plan before code exists

That sounds much closer to software engineering than “vibe coding”.

Why This Interests Me

My skepticism around AI-generated code is mostly about trust.

I do not really care if an AI can produce a working-looking component or a nice layout. That can be useful, but it is not the hard part of software.

The hard part is usually:

• knowing what should exist
• understanding what should not exist
• keeping boundaries clean
• avoiding unnecessary abstractions
• preserving long-term maintainability
• making sure changes do not quietly break the system

So the question for me is not:

“Can AI write code?”

It is more:

“Can AI follow constraints well enough to be useful in a real development workflow?”

Spec-driven tooling seems like one attempt to answer that.

The Tools I Looked At

The comparison document I reviewed grouped the current SDD tooling ecosystem into a few different styles. I found this helpful because the tools are not all trying to solve the same problem.

Some are lightweight and optimized for solo developers. Others are heavy, structured, and closer to enterprise planning systems.

Here is how I understood the main categories.

GitHub Spec Kit: The Project Planner

GitHub Spec Kit is described as being focused on upfront planning and rigid project rules.

The idea is that you define a unified spec file, and that file dictates the boundaries for code generation.

This seems most useful for greenfield projects, where the architecture is still flexible and you want to establish rules early.

What seems good

• Good for new projects.
• Helps establish architectural boundaries early.
• Fits naturally into GitHub workflows and pull request reviews.
• Could improve consistency across larger generated features.

What worries me

• It may feel too rigid for small bug fixes.
• It requires a lot of upfront effort.
• If requirements change quickly, the process may become annoying.

My instinct is that this would work best when the project is still young and the team agrees to treat the spec as a serious artifact, not just documentation that slowly goes stale.

OpenSpec: The Iterative Tracker

OpenSpec seems to take a lighter approach. Instead of trying to describe the whole system upfront, it focuses on delta specs — small tracked changes applied iteratively.

This makes sense for existing codebases, especially legacy systems where a full rewrite is unrealistic.

What seems good

• Low friction.
• Better suited for incremental changes.
• Useful when working with existing code.
• Avoids heavy process overhead.

What worries me

• It may not enforce architecture strongly.
• Specs can drift if developers change code manually and forget to update them.
• It may not be enough for planning large system-wide changes.

This feels closer to how many real projects actually work: small changes, one after another, while trying not to break everything.

BMAD Method: The Enterprise Heavyweight

BMAD Method is the most heavyweight approach in the comparison.

It simulates a full enterprise team — product manager, architect, QA, and so on — before writing code. The goal is to generate comprehensive planning documents, test cases, and architecture notes before implementation begins.

What seems good

• Could catch design and logic flaws early.
• Produces detailed PRDs, architecture documents, and test cases.
• Useful where compliance, audit trails, or formal planning matter.

What worries me

• Token-heavy and expensive.
• Slow because of multiple agent hand-offs.
• Overkill for scripts, prototypes, hotfixes, and small personal projects.

This is probably not what I would reach for first. I can see why it exists, but for my own work it feels like too much process unless the project really demands it.

GSD: The Lean Speed-Runner

GSD, or “Get Shit Done”, is almost the opposite of BMAD.

It uses a smaller prompt funnel and an “Interview Mode” to quickly extract constraints from the user, then moves into implementation.

What seems good

• Fast.
• Better suited for solo developers.
• Interview mode can help uncover missing edge cases.
• Avoids unnecessary enterprise-style ceremony.

What worries me

• It lacks deeper multi-agent review.
• It may miss broader system-wide consequences.
• It depends heavily on the user answering the questions well.

This one sounds closer to how I would want to use AI for personal projects: quick, focused, but still trying to clarify the goal before generating code.

Spec Kitty: The Workflow Optimizer

Spec Kitty stood out because it focuses less on planning style and more on workflow isolation.

It uses native Git worktrees so that AI-generated code happens away from the developer’s active working tree.

That is actually a very practical idea.

What seems good

• AI changes do not pollute the current working tree.
• Multiple features can be generated in parallel.
• There is a cleaner teardown and merge process once the spec is satisfied.

What worries me

• Git worktrees add complexity.
• It may be harder to debug what the AI is doing mid-flight.
• Merge conflicts can still become painful afterward.

I like the general philosophy here: contain the AI. Let it work, but do not let it randomly mess with the workspace I care about.

Superpowers: The TDD Gatekeeper

Superpowers takes a stricter test-driven development approach.

The AI has to write and run a failing test before implementation.

This is probably the most reassuring approach to me, because it forces the generated code to be tied to behavior rather than just text output.

What seems good

• Stronger reliability.
• Generated code is backed by tests.
• Reduces hallucinated logic and regressions.
• Forces the agent to understand the requirement before implementing.

What worries me

• Slower for prototyping.
• Depends on the AI being good at the test framework.
• Can get stuck if the test environment is not configured correctly.

This is one of the approaches I find most appealing. If I am going to let AI touch something important, I would much rather force it through tests first.

AWS Kiro: The Dedicated IDE

AWS Kiro is described as a full native workspace that uses EARS — Easy Approach to Requirements Syntax — for more formal specifications.

This is a more structured environment, especially for cloud architecture and AWS-heavy projects.

What seems good

• Deep cloud integration, especially with AWS.
• EARS helps remove ambiguity from natural language requirements.
• It is an all-in-one environment rather than a bolted-on script.

What worries me

• Possible workspace lock-in.
• Requires learning EARS notation.
• May be less flexible for simple frontend or non-cloud projects.

This sounds powerful, but also like something I would only consider if I were already committed to that ecosystem.

My Current Takeaway

I am still not fully impressed.

That may sound harsh, but I do not mean it in a dismissive way. I think these tools are interesting, and I can see how they could be useful. But I still do not feel like they replace plain old software engineering.

If anything, they make engineering discipline more important.

The better the spec, the better the output. The clearer the architecture, the less freedom the AI has to make strange decisions. The stronger the tests, the easier it is to trust the generated code.

So maybe the useful framing is not:

“AI will write software for me.”

It is more:

“AI can operate inside a workflow that I design.”

That distinction matters to me.

What I Might Actually Use

For my own personal projects, I can imagine using some of these ideas selectively:

• Write a short markdown spec before asking for code.
• Keep AI-generated work isolated in a branch or worktree.
• Prefer TDD-style flows when the logic matters.
• Use interview-style prompting to uncover edge cases.
• Treat the generated result as a draft, not the final answer.

I am not ready to hand over architectural judgment. But I am more open to using AI as a tool in the process, especially when the task is well-scoped and the constraints are clear.

That feels like a reasonable middle ground.

Final Thought

I still prefer normal software engineering.

But I am trying to be honest with myself: if these tools can help me move faster on personal projects without completely abandoning discipline, then they are worth understanding.

For now, I see Spec-Driven Development as less of a magic solution and more of a reminder that AI works better when humans do the thinking first.

And honestly, that is probably how it should be. :)

References

• Spec-Driven Development Tools Comparison PDF