Spec Driven Development - These are not the specs you're looking for

Using GitHub's Spec Kit, I built in days what had taken me months across multiple abandoned repos. That's not hype — that's real. But the name we've given this process is setting people up for the wrong expectations. Some of the flavors of this process include:

• AWS AI DLC (terrible name AWS, all I see is "Downloadable Content")
• Github Spec Kit
• Claude Superpowers

A single developer working on a personal project (a la, Myself) can use this process to build out a project from start to finish rather quickly. Both when working from a vibe coded idea OR from a detailed design. Having LLMs do most of the code writing and testing has the potential for a huge productivity boost.

Where I see the current challenge is less technical and more human. Developers I work with are anxious — not just about learning new tools, but about what it means for their role, their team, and the craft they've spent years building. The question underneath all of it is: how different is this, really, from what we've been doing for the past 20 years? The short answer is, not as much as you would think. But I also think the way this process is presented — starting with the word "Spec" — is making the anxiety worse than it needs to be and hides the real benefits it can provide.

The Software Development Life Cycle (SDLC)

I have no doubt you have seen this diagram before (or one like it). This cycle is commonplace today. We plan, build, test, deploy, monitor, rinse and repeat. The process is iterative and we are always learning from the implementation to inform the next iteration.

Traditionally as part of the "Plan" phase of the process we maintain a set of documents that capture the requirements, design decisions, and testing strategy for the project. This includes:

• Software Requirements Specification (SRS)
• Product Requirements Document(PRD)
• User Workflows
• Test Plan
• The list goes on...

These documents outline the "spec" for a product or piece of software. They are the "source of truth" for the project and are used to guide the SDLC. Over time they may grow and change as you iterate on the product but they are the foundation for the project.

This distinction is important because it highlights the expectation of what "spec" means to those in the industry. When a seasoned developer hears 'Spec Driven Development', this is the baggage that word carries. That matters.

"Spec Driven Development", yet another overloaded term

I have been using Github's Spec Kit for about a month now. If you use VSCode (as I do) then your interaction with Spec Kit is primarily via slash commands:

• /speckit.specify - Consumes your idea and create an initial "spec.md" file to capture requirements.
• /speckit.plan - Consumes the "spec.md" file and creates a "plan.md" file to capture the design and tech choices.
• /speckit.tasks - Consumes the "plan.md" file and creates a "tasks.md" file to capture the implementation plan as step by step tasks
• /speckit.implement - Consumes the "tasks.md" file and creates the code for the project.

These slash commands are a mixture of Agents (LLM Personas) and Prompts (instructions for a particular task) and are stored in your repositories .github directory. You follow their process until you send the implement command to have the code generated for you.

When I first tried the tool I went 100% green field, "build me my application from an idea" (you can check it out here). I took time to review the spec, used the /speckit.clarify command to refine the "spec" until I was happy with what it wrote. Once I had finished the process, I had an application. I started the dev server, was greeted with a rough but working starting menu, I could create my character, and start the game. Then I realized the character could not move, the camera was statically stuck in one place, and I was just looking at a game I had zero control over.

Giving the process the benefit of the doubt, I went back to the /speckit.specify command and created a second feature to add camera controls. I went through the same process, reviewed the spec, refined it, and then implemented it. This time I had a working camera controls. You can see I did this a couple of additional times, trying to refine my application to the game I had in my head, playable in the browser. I did this 3 more times.

Now I had a new problem, I have five spec.md files. What I noticed was each spec has a list of functional requirements and success criteria which feels a lot like traditional specs for a piece of software, but they are fragmented across multiple files.

The problem isn't that these files exist — it's what the word "Spec" implies to anyone who has spent years working with SRS documents and PRDs. When a seasoned developer hears "Spec Driven Development," they expect a product spec: a living document that defines the whole system. What they get instead is a collection of feature-scoped alignment documents - each scoped to a single task/story/feature and disposable after implementation. That's not a spec — that's scaffolding. And the scaffolding is in service of one thing: AI driven development (roll credits).

But not everyone reads it that way. For developers earlier in their careers, a "spec" is something you're accountable to. It's a document your implementation is measured against. I've seen this firsthand working with my own team — the moment they see the word "spec," the question in the room becomes: "what happens if my code doesn't match it?" "Do I need to maintain this spec file while I develop?" That fear is real, and it's not irrational. It's the product of years of being told that deviating from the spec is a problem. Calling these feature alignment documents a "spec" imports all of that baggage into a process that was designed to reduce friction, not create it.

AI Driven Development, the realistic name for Spec Driven Development

I recognize that I have made the smallest semantic change possible to this topic. However, I think this change is important because it highlights that this process is not about writing a "spec". The "spec" is still a critical component of the process, but that should happen as part of the "Plan" phase of the SDLC. The process focuses on using AI to drive the development, improving Human/AI cooperation, and providing insight into how the ideas and specifications are turned into solutions.

If you take nothing else away from this article, I hope you take this away. The "Spec" in SDD is "the LLM's understanding of the requirements, design, and testing strategy for a particular feature". This is presented you (as the software engineer) as a set of assertions, requirements, and success criteria. Those allow you to ensure alignment between the LLM and your own understanding. It is not the "product spec".

As companies start to adopt this process, it's worth being honest about where we are: peak hype cycle. The continuous message that "this AI thing will change everything" is setting expectations that make the anxiety worse, not better. It is not a silver bullet. What it is — when used where it actually fits — is a meaningful accelerant for the work developers are already doing.

My opinion is that this process (Spec/AI Driven Development) helps in the Code, Build, and Test phases. For example, when I started my finance spreadsheet conversion project, I had a lot of subject area expertise in how that system worked. This allowed me to write a proper Software Requirements Specification (SRS) that outlined the requirements and workflows involved in the application. Then the AI Driven Development allowed me to take vertical slices of that specification and turn it into working software.

In professional spaces, that SRS, wireframes, and design documents do not come from me or AI. On a team, that's the job of Product, User Research, and UI/UX. The AI Driven Development process picks up where they leave off — it doesn't replace what they do, it depends on it to ensure that products are being built to solve the real problems.

Conclusion

AI Driven Development has been a genuine boost to my productivity — not just in what I ship, but in getting to step away from the computer and enjoy other parts of life. I'm not here to sell you on it, but I'm also not going to pretend the impact hasn't been real.

If you find yourself anxious, lost, or confused about how any of this works, start by breaking it down. As software engineers we are already equipped for this. We know how to break down problems, review requirements, and validate output — that's exactly what this process asks of us. AI simply writes it down for us.

The tools are new. The job isn't.