[user34283]

I don't see the benefit of checking in either prompts or specs.

I never tried spec driven development for myself, but if I review other's MRs I am typically exhausted after the first 10 lines.

And there are hundreds of lines, nearly always with major inaccuracies.

For myself I always found the plan mode to work well. Once the implementation is done, the code is the source of truth. If it works, it works.

When I want to add more functionality or change it, I just tell the agent what I want changed.

I doubt walls of semi-accurate existing specs are going to be beneficial there, but maybe my work differs from yours.

[gbear0]

Those checked-in specs become the requirements for the system. So the next time you ask the AI to make a fix, it can use those specs as part of the solution and not break another requirement. Basically the code underneath keeps getting rewritten over and over, but that doesn't matter as long as it hits the required specs.

[jmcodes]

Do you rewrite the specs with new requirement changes if they've already been implemented? How do you supercede a spec?

I've been using LLMs daily and I spun up a few spec driven flows once or twice but like the person above I think the code is the source of truth.

Also why wouldn't you use TDD to enforce the 'spec' then?

[macintux]

I value traceability, and I value understanding the "why" of the code. For me, the prompts are useful for both.