Make One Thing Work First

The Build Loop, same as every rung — spec, direct, checkpoint, verify. Nothing new gets added here; we're sharpening how you spec that very first thing, and how hard you hold the line before you ask for a second.

You already know this failure mode. It's the junior hire's first big deck — gorgeous, confident, and hollow the moment a client asks one real question. You've learned to spot it from across a conference room. Agent-built software fails the same way, only faster, and this rung teaches you where to point the instinct you already have.

Breadth is free — and that's the trap

When an agent builds for you, breadth is nearly free. Ask for five features and you'll have five by this afternoon, each one working in the demo. That speed feels like progress, and almost none of it survives contact with real work. What you get is software that looks finished on the outside and is hollow inside — a golden-brown muffin made of cardboard. It photographs beautifully and crumbles the first time someone takes a real bite.

I've served myself that muffin. Early on I let an agent run ahead of the design; the features came fast and looked right, and the whole thing fell apart the moment I tried to extend it, because the foundations were never there.

Demand one thing, all the way through

The cure is a single hard demand: one real task, working end to end, excellent, before anything else exists. Not a screen, not a piece — the whole path a real person actually walks. If you're building a client-intake tool, the first thing isn't "the form." It's: someone submits the form, bad entries get caught, good ones land in the tracker, a confirmation goes out. One complete path, all the way through.

And "excellent" means something specific — five things you write into the spec and refuse to advance without:

• It survives bad input. The demo path is someone typing exactly what you'd type. The real path is someone pasting a paragraph into the phone-number field. Demand the second.
• It tells you when it breaks. A plain-language record you can open and read after something goes wrong.
• You can see what changed, and undo it. Every change gets a numbered version, so "what's different since Tuesday?" has an answer — and a bad answer can be rolled back.
• Its rules live where you can read them. What counts as valid, who gets notified, what gets rejected — in a file you can open and change. Rules you can't see mean a tool you rent, not one you own.
• You've run it yourself, on real data — your actual messy spreadsheet with the merged cells and the intern's creative date formats, not the tidy sample the agent invented.

You don't need to know how any of it is built. You need to put it in the spec and hold the checkpoint until you see it. It's the same move you make reviewing a junior analyst's model: you don't rebuild the formulas, you probe the edges and ask where the numbers came from.

One good thing pays for the next

This sounds slow. It felt slow to me — I once spent the better part of a month of sessions on a single end-to-end path, certain I was over-engineering it. Then I asked for the second capability, and the whole spec was one sentence: "same standards as the first one." I didn't re-specify the error handling — the agent inherited it. I didn't re-specify the logging, or the way changes get versioned. The only thing I described fresh was the genuinely new part. Everything underneath came along for free.

That's the economics that make the slow start cheap. The month wasn't the cost of one feature; it was the down payment on every feature after it. The second came together in a fraction of the time — not because the agent got smarter, but because I could point at something excellent and say "like that."

Use it before you widen it

One step almost everyone skips, and the one I'd defend hardest: use the thing, on real work, before you ask for more. Run your one working path on your actual work for a week. What annoys you that week is your next spec. What never comes up wasn't worth building. The design gets earned instead of guessed.

The payoff isn't that the agent did something clever. It's that you can hand your team a tool on Monday and it holds — that you can promise "the tracker will catch bad entries" and be right. That's a genuinely new thing for a non-engineer to make happen reliably, and it comes from one discipline, held stubbornly:

One thing working end-to-end before any second feature.

→ The companion — In Tropo: Your First Working Thing — hands you the spec for one complete path and the five-point cardboard test to hold it to.

Power Play

Before you widen a build, make the agent attack it. Once your one thing works, give it this:

"You built this. Now try to break it. Give me five inputs a real user — careless, rushed, or hostile — might enter that would make this fail or quietly do the wrong thing. Then run each one and show me exactly what happens."

The demo path is the one you'd type. This finds the paths you wouldn't: the empty field, the pasted paragraph, the date from another century. Fix what breaks before you build anything on top of it. You're testing for cardboard while it's still one muffin, not a whole tray.

Terms worth knowing

• End to end — the whole path a real task travels, start to finish, not one piece of it. "The form" is a piece; "someone submits it, it's checked, it's saved, they're told" is end to end.
• Log — the software's plain-language diary of what it did and when. You open it to find out why something went wrong.
• Version — a numbered snapshot of the software at a point in time, so you can see what changed and roll back a bad change.