Journal · The AI Architect · 2026-07-24
Build a rough version first, then change one thing at a time. Small steps show you exactly what worked.
Build a rough version first, then change one thing at a time. Small steps show you exactly what worked.
The tension isn’t about laziness or perfectionism, though it looks that way from the outside. It’s that building something and understanding something are two different acts, and most of us try to do both at once. We sit down to make a thing and also figure out how it should work, in the same breath, and then wonder why nothing gets finished and nothing gets learned. The rough draft, the ugly prototype, the janky first version — these aren’t lesser cousins of the real thing. They’re the only way to separate the doing from the knowing.
Build the thing that can be wrong
A rough version isn’t a lower-quality version of your final goal. It’s a different kind of object entirely — one built to be wrong in informative ways. This is a hard shift to make because most of us were trained to think that a first attempt should resemble, even faintly, the finished product. So we polish sentence one before we write sentence two. We tune a setting before we’ve confirmed the whole approach even makes sense.
Try this: before you start, write down what you’re trying to learn from the rough version, not what you’re trying to achieve. “I want to see if this structure holds together” is different from “I want to make something good.” One gives you permission to build something clumsy and call it a success. The other keeps you stuck in revision before you’ve even created anything to revise.
Change one thing so the change can talk back
Once you have a rough version, the temptation is to fix everything you notice is wrong, all at once. This feels efficient. It isn’t. When you change five things and the result improves, you don’t know which change mattered — maybe one thing helped and the other four were neutral or even slightly harmful, canceling each other out. You’ve traded speed for blindness.
Changing one thing at a time is slower in the moment and faster overall, because every change actually tells you something. You get a clean signal instead of a muddy one. This is uncomfortable if you’re impatient, and most people building things are impatient — that’s often why they’re building. But the discomfort is the cost of clarity, not a sign you’re doing it wrong.
Try this: the next time you revise something — a document, a process, a piece of code, a habit you’re adjusting — pick exactly one variable to change. Write down what you expect to happen before you make the change. Then look at what actually happened. If you can’t tell whether it worked, that’s useful information too: it means the change was too subtle to matter, or you don’t yet know what “worked” would look like.
Let small steps replace your guessing
There’s a reason this approach feels almost too modest to trust. We want big insight, the elegant plan that gets it right from the start. But elegant plans made in advance are guesses dressed up as confidence. Small, sequential steps replace guessing with evidence. Each one is a tiny experiment, and the accumulation of tiny experiments is how you actually learn what you’re doing — not in your head, but in contact with something real.
This also changes your relationship to failure. When you’ve committed to a big plan and it doesn’t work, that feels like a verdict on you. When you’ve made one small change and it doesn’t help, that’s just data. It’s almost boring, in a good way. Boring is sustainable. Boring lets you keep going without the emotional weight of having been wrong about something large.
Try this: at the end of a work session, write one sentence — “the thing I changed was X, and here’s what I now know that I didn’t know this morning.” If you can’t fill in that sentence, you probably changed too much, or you didn’t pay close enough attention to notice.
None of this is complicated, and that’s sort of the point. The difficulty isn’t in understanding the idea, it’s in resisting the pull toward speed and certainty when neither is available yet. I go into this more in the book, particularly how to structure the early rough versions so they actually produce useful failure instead of just failure, but the core of it is what’s already here: build something you’re willing to be wrong about, then let it teach you one change at a time.
Go deeper. The full method is in The AI Architect. New here? Start with the free companion pack, or explore the series.