The problem was never the tool. It's who's doing the thinking.

Vibe coding is everywhere now. Agent loops, autonomous PRs, "just describe what you want and let it run." I use these tools every day. They are genuinely valuable — no second thoughts about that.

But something has quietly shifted. Developers aren't just outsourcing typing to AI anymore. They're outsourcing the thinking. Not just "write this function" — "figure out what to build, and how." The agent isn't in the passenger seat anymore. It's driving, and the developer is reading the map after the trip is over.

The dual

Software engineering already has a TDD. Test Driven Development — red, write a failing test; green, make it pass; refactor, clean it up. A discipline with a rhythm.

I think it's time for the dual: Thought Driven Development.

Before you let an agent write a line of code, you've done the thinking an agent can't do for you. You've defined the problem, the contract, the shape of the data, what "correct" means, and how it breaks. Only then does the agent get to type.

Red-green-refactor has a rhythm because someone sat down and worked out the loop. Here's the shape of the thinking itself.

The real failure mode

Here's the reframe that made me want to write this down: building software was never the hard part. It got easier every year, long before AI showed up — better frameworks, better tooling, more reusable everything. What's still hard, what's always been hard, is maintaining what you build, and building something genuinely good. Vibe coding optimizes the one part of the job that was never the bottleneck.

I've watched this play out in small, specific ways.

I've seen AI agents generate test cases whose only real purpose is to pad a coverage number and clear a deployment gate faster. Tests that pass, that assert nothing meaningful, that exist because "more tests" looked like progress. Nobody asked what needed to be true — just what would turn green.

I've seen agent-coded agent harnesses that break with every new release. Not because the underlying logic changed in some meaningful way, but because nobody thought through what "correct" actually meant when the harness was first built. The harness was assembled, not designed. And that's not a one-time cost — it compounds. Every release, someone pays it again, usually a person who didn't write the harness and has no idea why it's fragile.

Regression is becoming the real tax on agent-coded systems. Not "does it work today" but "does it still work after the next change nobody fully understood." That's a thinking problem wearing a tooling costume.

The pillars

When I sit down to design something — before any agent touches a keyboard — these are the things I need to have worked out in my own head first.

1. Objective. What is this software actually for? What problem, for whom, and how will I know it's solved? If I can't say this in a sentence, I'm not ready to prompt anything.
2. Contract. What are the inputs and outputs, clearly defined? If I can't state the contract, an agent can't either — it'll guess, and the guess becomes the API whether I meant it to or not.
3. Flow. How does data and control move through the system? Sequence, not just structure. What happens first, what happens if that fails, what triggers the next step.
4. Data model. How is the data represented? Get this wrong early and everything downstream inherits the mistake — every function, every test, every migration built on a shape that never should have shipped.
5. Test cases. What actually needs to be true for this to work? Not tests written for coverage theater — tests that encode what correctness actually means, written by someone who understands the problem, not someone optimizing a metric.
6. Failure modes. Where does this break, and what happens when it does? Coverage should be a byproduct of thinking through failure, not a target to hit on a dashboard. Regression is the sharpest version of this pillar right now — agent-coded systems quietly breaking release after release because nobody thought through what failure looked like in the first place.

Six pillars. Work through them and you have something worth handing to an agent. Skip them and you have something that compiles.

Where AI actually fits

None of this is an argument against AI. It's an argument about sequence.

Think first. Delegate execution second. In practice, that's as simple as writing the six pillars down in plain language before opening the agent — a few paragraphs, not a spec document — and handing that to the tool instead of a vibe. The agent is still doing most of the typing. It's just typing something you already understood, instead of something you're hoping turns out fine.

Used this way, AI makes me faster at the part that was always mechanical. It doesn't make the decisions for me, because it can't — it wasn't there when the problem was defined.

The other extreme

There's a mirror-image failure worth naming too. I've come across companies that now require engineers not to write code at all. Not "use AI heavily," not "review more than you type" — no code, full stop.

I'm not sure what problem this solves, or who's funding the bet. If vibe coding is outsourcing thought while keeping your hands on the keyboard, this is outsourcing execution entirely and hoping the thought survives contact with reality without ever being tested against it. An engineer who never writes code stops noticing when things are wrong. The thinking gets rusty in a different way, but it still gets rusty.

Both roads lead to the same place. The thinking stops.

Think first

An agent will happily build the wrong thing, fast. Make sure it's the right thing first.