By March, my agentic development setup had hit a wall. I was not vibe coding: I had built my own set of custom Claude Code skills, with conventions, templates, the whole apparatus. It held up fine on short tasks. On long ones, two problems kept coming back. The context window would saturate, and the agent would quietly drift from decisions it had made an hour earlier. And nothing in my tooling verified anything procedurally: no gate forcing the tests to actually run, no checkpoint forcing a review before moving on. The agent would say “done”, and done was a feeling, not a fact.
Those two problems have names: context rot, and missing verification. They also have a whole ecosystem of frameworks claiming to fix them. In March I committed to one, GSD, because its core mechanism (fresh context per task, a staged pipeline with verification gates) targets exactly my two diseases. Along the way I analyzed the alternatives in depth, because a decision like this one is worth auditing even after you have made it.
Picking one
The most useful thing that analysis taught me is that these tools are not competing for the same seat. Each one is medicine for a different disease. OpenSpec targets underspecification in existing codebases (spec deltas). Spec Kit targets intent-free vibe coding on new projects (constitution, traceable requirements). GSD targets context rot in execution. Asking “which framework is best” without saying what hurts is how a team ends up with the overhead of a framework and the symptoms of its original problem.
In June I also dug into AIDD, after direct contact with its team. It is a different category of object: a full SDLC suite distributed as Claude Code plugins, where spec/plan is one module out of six. If your question is “how do I industrialize my whole lifecycle”, that is the shelf to look at. It was not my question.
What four months actually changed
Since March I have shipped multiple large features on a client project this way, delivered a well-structured PoC to another client, plus a steady stream of personal experiments, and three changes stand out.
I stopped babysitting the context window. Long processes now advance as cleanly separated stages, each starting from fresh context. Watching the context gauge on a long run used to be an actual part of my job; it is gone.
My validation moved upstream. I used to inspect output downstream and steer by correction. Now I validate the approach (the spec, then the plan) before anything executes, and execution itself runs at maximum automation. The trust is placed earlier, against a document, where disagreeing is cheap.
For what they are worth, the numbers land around a 3x speedup, measured against my own custom skills, not against coding unassisted, so read it as “structured framework versus decent homemade tooling”. And my time now splits about 50% specification, 50% review and tests. That is the part every serious developer advertises now: writing code has essentially disappeared from my schedule. Not because “the AI writes it”, as the marketing goes, but because my work moved to the two ends of the process that actually need me.
What it costs
It costs tokens, mostly. I had to upgrade to the top Claude plan to run large developments: a multi-agent pipeline that restarts from fresh context at every stage burns through a lot. And that cost is structural to the category, not a GSD quirk. Scott Logic measured a Spec Kit workflow at roughly 10x slower than direct iterative prompting on a modest feature, and Birgitta Böckeler’s review on MartinFowler.com reached a similar verdict. Those are small-feature benchmarks, where heavy structure is predictably overkill. But the shape of the tax is right: you pay for structure whether or not the task needed it.
Which is why the question that actually runs my days is where the framework stops paying for itself.
Where it breaks
For quick fixes I use dedicated lightweight skills and skip the pipeline entirely. That part is easy. The trouble starts with the quick fix that bogs down. When a task qualified as “simple” turns out to be deep, the framework gets lost: its instructions assume a scoped, staged progression, and they stop biting. The right move, learned the hard way, is to pull out of the framework, run a plain planning session with actual human judgment, and only then re-enter.
Every postmortem of mine looks the same. The failure was never inside the framework; it happened upstream, at qualification time, when I believed a fix was trivial while it deserved a real inspection first. A framework has a domain of validity, and it will not tell you when a task has silently left it. I have yet to see a README that says so.
The gap that remains
Verification is actually where these frameworks are investing hardest. GSD already ships deep verification processes (staged gates, dedicated verification passes). And gstack, which I have not used myself yet, has a /qa command (real browser testing, regression tests generated on the spot) that keeps getting recommended in my feeds. So “done” is slowly becoming a fact rather than a feeling.
But covered is not closed. Nothing I know of can check that an animation feels right, that a screen reads well, that an output is wrong in the precise way only your domain cares about. Those checks still land on a human, and at review time they land on me.
Which is where the interesting engineering sits right now: extending automated verification as far as it can reliably go, to cut down the human backpressure. My 50% of review and tests is that backpressure, measured. Every reliable point of automated coverage takes a piece of it away.