I'm Abandoning TSDD

I wrote a methodology. It was called TSDD —Thin Spec Driven Development— and today its README carries a red badge that reads abandoned. Not “on hold”, not “evolving into something else”: abandoned.

A month ago I published SDD: The Trap the Gurus Are Selling You, where I went after the heavy versions. The uncomfortable part was missing: I had my own, leaner and better argued, and it died of the same diagnosis.

What it tried to fix

The idea was reasonable. SDD frameworks make you install a folder tree before writing a single line, so I built the version with no fat: a spec that assumes the project context instead of restating it, modular stages you use only when they apply, artifacts generated after implementation rather than before, a human in the loop at every stage.

I still think each principle on its own is correct. That’s the interesting part of the failure: it was correct and useless anyway.

Why it died

Nobody reads specs. Me neither. Not the forty-page ones, obviously. But not the half-page ones either — written by me, for me, ten days earlier. When I pick a task back up I open the code and today’s plan, never the document that described last week’s intent.

The spec competes with the code for the spotlight. The code is the only thing that runs, deploys, gets reviewed and falls over at 3 AM. Any artifact competing with it for attention is overhead, and when they disagree the one lying is the document — I already knew that, I wrote it down, and I kept maintaining the document anyway.

They’re empty deliverables. Three approved specs and zero new behavior feels like progress, and that’s exactly the problem: the feeling arrives before the work and numbs you.

The “driven” was never true. What drove the work was the existing code and the conversation with the agent. The spec trailed behind, getting updated so it wouldn’t be caught lying. An artifact chasing reality isn’t driving anything.

The detail that gave me away

The comparison table in the README. TSDD against Vibe Coding, BMAD and Spec Kit, with rows like “agent-ready spec” and “closes to repo”. Below it: an FAQ, examples by team size, five skills installable via npx.

None of that is engineering, it’s positioning. Nobody writes an FAQ for the tool they use every day; the FAQ is for the person you want to convince. The day I started defending the acronym instead of using it, I was already on the other side of the counter.

If a methodology needs onboarding, it isn’t a methodology. It’s a product with standard-shaped ambitions.

What survived

The proposal. When the problem is fuzzy —I don’t know what to build yet, there are three paths and two are expensive— writing down the problem, the scope and the open decisions pays for itself. That’s not a spec: it’s thinking before spending.

A disposable PLAN.md. Short plan, I approve it, it gets implemented, I review, commit, push, refactor, next task. The plan lives as long as the task and gets deleted without ceremony. No lifecycle, no docs/ tree to maintain, no contract to keep in sync with the code.

That’s it. No acronym, and I’m not giving it one.

What bothers me about the ecosystem

Now the part that will annoy someone. SDD went from “write down what you’re about to do before doing it” —common sense with centuries of history— to having maturity levels, spec taxonomies, certifications, forty-minute talks, and people answering architecture questions by quoting their own framework.

The pattern is always the same: a real problem —agents perform better with precise instructions— turned into a discipline with its own vocabulary, because a discipline can be taught, sold and led. A two-line piece of advice can’t.

And the advice is two lines: ask precisely for the smallest piece that’s useful, and verify by running it. The rest is local craft —your repo, your tests, your risk tolerance— and there’s no course for that, because you can’t package what depends on your system.

What gets sold there isn’t a method, it’s the feeling of control over a non-deterministic tool. It makes sense that there’s a market. I was one of the people selling it.

What killing your own idea costs

Killing your own idea costs one commit and a bit of embarrassment. Defending it for three years because it carries your name costs considerably more, and the bill goes to the people who believed you.

TSDD stays published as a record, with the warning on top. Three stars on GitHub: it didn’t die of success either.