As improvements in AI (or SI if you prefer the US President’s terminology) continue, one consistently needs to improve how they work with it. This is a story of a few months ago, when I was exploring whether to move away from a skill heavy workflow.

I’d been a user of obra/superpowers skills for a long time. But as the models got better, I felt they were slowing me down rather than accelerating. They were invoked more often than needed, or overplanned. I came across “spec driven development” and the myriad of tools people developed following the philosophy. In the spirit of “don’t knock it till you try it”, I wanted to give them an honest go, and see if they would be better than my current agent setup.

I’d built chrollo recently at this point, and I already had some improvements to make. I picked a simple one — fixing session limit handling. This would serve as a single task given to all SDD tools, which I’d evaluate on UX, ease of use, and the actual correctness of solving the issue. As a baseline, I also did this with a vanilla pi session and no superpower or other skills for planning. To minimise interference, I’d provide the task as a markdown file to all runs with the context, including intended behaviour, scope, verification steps, and constraints.

All runs were initialised in pi.

spec-kit

Developed by GitHub, spec-kit had a large initialization footprint in terms of skills and planning, but I liked the planning quality. It was comprehensive and thoughtful, and despite the large artifact volume it was easy to follow along. I felt the commit workflow suggestions and branch switching behaviour to be unusual though. During planning, it read multiple code files to understand the repo structure and database schema. Although the plan had some repetition across sections, I liked it, because the plan included user stories, functional requirements, success criteria and edge cases, and adequately represented the task I’d given. It asked a few (4) clarification questions and presented answer options in decreasing order of likelihood. The questions themselves were valid and useful, but the UX left much to be desired - the actual question text existed in the spec markdown but wasn’t rendered in the prompt response with the presented options, meaning I had to infer the clarification question rather than.. Just being asked. Planning used ~100k tokens in a fresh Pi session.

From the plan, the generated tasks were organized phase-wise, which needed a nudge to correct. I also liked that the plan identified some tasks as candidates for parallel execution. Tasking in a fresh session took ~50k tokens.

The implementation was accurate and with solid verification both via tests and e2e testing. This was ~100k tokens including implementation, coming to a nice and even ~250k tokens total.

OpenSpec

If you must use an external SDD tool, I’d recommend OpenSpec.

It was very lightweight, with concise planning that still covered everything. The concise artifacts and the least process friction amongst the 3 tools I tried made this the smoothest experience of the lot. It felt purpose built without becoming ceremonial by adding unnecessary bells and whistles. Again, good implementation and testing. It also complied the best among the SDD tools with the “do not keep pausing” expectation I set in the initial task and worked autonomously. This translates to token efficiency too, with planning, implementation and testing all taking just ~100k tokens across 2 sessions.

You’ll note the lack of notes for openspec, which is good. Less is more. Which unfortunately isn’t the case for the next contender.

gsd2

Oh boy. Buckle up. Where do I even begin?

I’d like to start with what I liked about it first.

…

Ok, now the bad parts.

I’d disabled some pi extensions for this test evaluation so all harnesses would give their standard experience without any customization. But the gsd2 pi session still used these, indicating poor respect for local extension configuration and adding friction. In addition, it added a plethora of skills directly to my ~/.agents/skills directory, again impacting how I’d use agents outside gsd2.

It is extremely heavy on planning docs. And those are verbose too. Milestones, slices, tasks. All just for a simple requirement to fix a bug. The only concession I’d consider is that perhaps gsd2 isn’t meant for small fixes or tasks, but long horizon projects. But I was very discouraged from trying this with a larger project, thinking that would likely lead to even more detailed and numerous docs. If one is vibe coding, this might work. But in an era where small oversights and misses get magnified owing to agents doing the bulk of, if not the entire, implementation, I am not comfortable with the idea of a wall of text that never sees the light of human eyes, or the alternative thought of spending hours poring through needlessly verbose plans.

gsd2 recommends starting new sessions for subsequent slices of work, which I felt were warranted, considering each minor slice would end up consuming almost half the context window. gsd2 ended up consuming a whopping 1.7M context tokens over 21 sessions, which goes to show how wasteful and convoluted working with it feels. The large plan and skill files surely contribute to this. More than the token consumption though, it is the sheer effort and time it took to get through with my experiment with gsd2. Agents are supposed to speed us up. This was anything but.

The coup de grâce though, was that even when it reported having completed the task, there was a clear static bug in the code!

(Note: The gsd2 repo was archived on October 4, 2026. It is succeeded by gsd-pi.)

Vanilla pi

(not to be confused with vanilla pie, which really shouldn’t be on your computer)

The baseline test. I did not ask for a plan first this time. Just gave the task and let it implement. And lo and behold, it did so. Single session, 93k context usage including verification. That’s it. No notes. 10/10.

Which leads me to my overall conclusions.

This experiment was conducted with gpt5.4 a few months ago. The models have only gotten better since then, along with the harnesses. Yes, the SDD tools may have gotten better as well since then, but they’re overkill. If anything, I feel they hamper development by leading to context bloat and adding unnecessary boundaries in one’s workflows.

I am not advocating for not planning at all and just YOLOing “do X, make no mistakes”. At the end of the day, WE are responsible and accountable for what we ship, not the clanker. But a plan doesn’t need to be created every time, and even when it does, it should be tailored for you and your work. Investing a few minutes in preparing a plan skill if you find yourself needing specifically structured plans will save you more time and headaches than picking up someone else’s readymade solution.