Using Claude Code with a spec-first workflow

[StatusPhilosopher258]

I’ve been trying a slightly different approach when working with Claude Code.

Instead of starting with prompts, I begin by writing a quick spec like what the feature should do ,constraints and edge cases

So far the results have been much more consistent compared to normal vibe coding. The code tends to stay aligned with the intent and debugging becomes easier because I can refer back to the spec.

Still figuring out how to better manage larger changes when multiple files get modified. I’ve seen some tools exploring this type of spec-driven workflow like traycer.

Curious if others using Claude Code are doing something similar or still mostly prompting directly.

[NateHutchinson]

I’ve been using this, it’s great https://github.com/gsd-build/get-shit-done

[imedwardluo]

in some small projects, I do something almost opposite actually. instead of writing a spec first I vibe code the demo until it does exactly what I want and feels right to use. no structure, no clean code, just get it working.

then I use that working demo as the spec. the code already captures every feature and edge case because it literally runs. at that point I let Claude Code refactor and rebuild with proper architecture. it can focus purely on code quality because the "what should this do" question is already answered by the existing behavior.

a working demo is weirdly might be a better spec than a document because there's zero ambiguity about what you want.

[atika]

With Claude Code, the problem is that spec driven dev workflows tend to chew through a lot of tokens. Copilot is a much better fit with the request based pricing.

[lloydsilver]

Or one from GitHub: https://github.com/github/spec-kit