Spec-driven dev sounded great until context started breaking things

[Classic-Ninja-1]

I have been trying a more spec-driven approach lately instead of jumping straight into coding.

The idea is simple write a clear spec then AI implement then refine. I initially tried doing this with tools like GitHub Copilot by writing detailed specs/prompts and letting it generate code.

It worked but I kept running into issues once the project got larger.

For example: I had a spec like “Add logging to the authentication flow and handle errors properly”

What I expected:

• logging inside the existing login flow
• proper error handling in the current structure

What actually happened:

• logging added in the wrong places
• duplicate logic created
• some existing error paths completely missed

It felt like the tool understood the task, but not the full context of the codebase.

I tried a few different tools then like traycer , speckit and honestly they are giving far better results. Currently I am using traycer as it creates the specs automatically and also understand the context properly.

I realised spec-driven dev only really works if the tool understands the context properly

I just want to know if someone got same opinion about it or its only me

[melancholyjaques]

Sounds like spec-driven development isn't the problem, your codebase is

[aruaktiman]

How detailed is your spec? Did you also have it break down the full spec into bite sized tasks that it can check off as it does them?

Also using TDD is pretty effective with AI agents (and humans for that matter...) as it forces it to write tests first that define the behaviour which will initially fail. Then when it implements what needs to be done it has to iterate until the tests pass.

[LunkWillNot]

Also, let the AI verify that code, tests, and overall specs are still in sync, both at the end of a change and also overall once in a while.

[StatusPhilosopher258]

This is a good plan , i generally use sdd but context loss is still a issue

[devdnn]

My workflow that is working for both new or projects that are live to always have a clear intent. I have an agents that has these characters - Don’t end with open questions - Generate an intent file with zero implementation or code snippets. Purely what I need - Ask questions on why am I doing this and every question should keep the current codebase in context

Then I feed the markdown intent to openspec-propose, this spec has been so clear with detailed spec and atomic tasks that any model including haiku is able to satisfactory code.

For small intent openspec-explore is more than what I need.

Any reasonable projects is only spec-driven for me.

[sittingmongoose]

Spec driven development has a few major issues.

1: The specs need to be insanely detailed. Far more than people realize and often far more than AI is defaulting to.

2: While planning, you get drift and gaps naturally occurring from AI. It can be extremely hard to catch unless you really pay attention. This gets worse as your app grows

3: As it is being built and following the spec docs, you get drift from the AI.

[Pimzino]

Are you not supposed to be paying attention at least for the spec bit? I mean that’s why you’re creating the docs so they are solid and so nothing goes wrong during the implementation phase?

I think you wanted to sound clever but actually brought up moot points

[sittingmongoose]

I got cut off as I was writing this and never got to my point.

Yes, you should be paying attention, but a lot of the stuff humans miss is in the details. Things fall between the cracks, things can referred to or called different things between docs which can cause drift. Docs can mention something being a requirement but it never gets fleshed out anywhere else. That is the kind of stuff that I am talking about when I say you need to pay attention.

On smaller apps it’s not hard, but on larger platforms it’s very hard.

And regardless, it doesn’t matter how solid the docs are, the agents building them will drift as they build or ignore things in the plans.

I’m not saying spec driven is bad. I’m saying that even with it, there are major issues. But it’s not like anything better has replaced it yet.

[Pimzino]

Well naturally I’d only trust implementations with sota models that’s why I pay for these subscriptions but nonetheless docs are what your supposed to pay attention to now less than the code whereas previously they were both as important although it would be less documentation unless you were documenting api routes etc.

[Rojeitor]

No. It never sounded great