Journal · The AI Architect · 2026-08-19
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 versus rigor. It’s about the fact that most people building something new secretly believe that if they just think hard enough, plan carefully enough, they can skip the embarrassing middle part where the thing is ugly and half-broken. So they delay starting. Or they build in the dark for weeks, changing five things at once, and when the result finally works (or doesn’t), they have no idea why. The rough version isn’t the problem. Not knowing what caused the outcome is the problem.
Make the first version cheap on purpose
The rough draft’s job is not to impress anyone. Its job is to exist long enough for you to react to it. If you spend three weeks polishing a first attempt, you’ve made it expensive to throw away, and you’ll unconsciously start defending it instead of testing it. That’s backwards. You want something you can look at and think, “eh, let’s see,” not something you’ve fallen in love with.
Try this: give yourself a real constraint on the first build. One afternoon. A single page. Whatever the smallest unit of “actually working” looks like for your project, aim for that and stop. If you’re building a tool, make it handle one case, badly, rather than five cases, partially. If you’re writing a talk, draft the middle section only, in plain language, with no slides. The goal is a thing you can react to, not a thing you’re proud of.
Change one variable, not five
Here’s where most people undo the benefit of starting rough. They get their first version, feel the itch to fix everything wrong with it at once, and rewrite half of it in a single pass. Then it works better, or worse, and they can’t say why. Was it the new structure? The different wording? The extra feature? They’ve bought themselves a mystery instead of an answer.
Small steps aren’t a virtue for their own sake. They’re a diagnostic tool. When you change one thing and observe the result, you learn something durable: this specific choice helped, or it didn’t. That knowledge compounds. Ten single-variable changes teach you ten distinct things about what you’re building. Ten simultaneous changes teach you one vague thing, if you’re lucky.
Try this: before you touch your rough draft again, write down the one change you’re about to make and your guess about what will happen. Just a sentence. “I think shortening the intro will make people read further.” Then make only that change. Afterward, check your guess against what actually happened. Do this five times and you’ll notice you’re building real judgment, not just accumulating edits.
Let the small steps disagree with you
The quiet benefit of this approach is that it protects you from your own assumptions. Everyone starts a project with a theory about what will matter most, and that theory is often wrong in some specific, useful way. If you build the whole thing according to your theory and then test it, you find out you were wrong all at once, expensively, after a lot of sunk work. If you test one piece of your theory at a time, you find out you were wrong early, cheaply, while it’s still easy to change course.
This means you have to actually look at the results of each small change rather than assuming you already know. That’s harder than it sounds. It’s tempting to make a change, glance at the outcome, and confirm what you expected to see. Try this instead: after each single change, ask someone else what they notice, or set the work aside for a day before you judge it yourself. A little distance from your own expectations makes the feedback from each step much more honest.
None of this is about moving slowly for its own sake. It’s about making sure each step actually tells you something, so that by the time you’re twenty steps in, you’re not just further along, you’re smarter about the thing you’re making. That difference, between accumulating effort and accumulating understanding, is most of what separates a project that improves from one that just changes.
I go into this more in the book, including what to do when a small step gives you a confusing or mixed result, which happens more often than the clean version of this idea suggests.
Go deeper. The full method is in The AI Architect. New here? Start with the free companion pack, or explore the series.