I used to write software like I was stacking bricks. One on top of the other, carefully, sequentially. Lay the foundation. Build the walls. Hope the architecture holds. If something was wrong three layers down, tough luck — you’re ripping it all out.
That’s not how I work anymore.
The old way is dead weight
The traditional flow went something like: think really hard, plan every edge case, write the code top to bottom, debug it, ship it. The emphasis was on getting it right the first time because iteration was expensive. Changing direction meant throwing away work.
That constraint doesn’t exist anymore. Not in the way it used to.
Clay, not bricks
Now I treat code like clay on a pottery wheel. I start with a rough shape — an intent, a direction — and I loop. Shape it, evaluate it, reshape it. If the walls collapse, I don’t start over. I throw it back on the wheel.
Here’s what that actually looks like in practice:
- State the goal clearly. Not implementation details. The outcome. “Users should be able to export their data as CSV” — not “create a button that calls an endpoint that streams a file.”
- Let the loop run. Generate a first pass. It won’t be perfect. It’s not supposed to be.
- Evaluate the output. This is where your engineering brain matters most. Read the code. Does it handle the edge cases? Is it doing something clever-but-fragile? Is the approach even right?
- Feed corrections back in. Be specific. “This doesn’t handle empty datasets” is better than “this is wrong.” The tighter your feedback, the tighter the loop.
- Repeat until it’s solid.
That’s it. That’s the whole methodology.
Watch the loop
The most underrated part of working this way is watching. Not just skimming the output and hitting accept — actually reading what comes back each iteration. This is where you learn. You see patterns you wouldn’t have written yourself. You catch failure modes you wouldn’t have anticipated. You develop an intuition for where models are strong and where they’ll confidently hand you garbage.
Every loop iteration is a teaching moment, in both directions. You’re teaching the model what you want. The model is teaching you what’s possible.
What actually changed
Practically speaking, my day looks different now:
- I prototype faster. Things that would have taken a day of scaffolding take an hour. Not because the code writes itself, but because the feedback loop is so much shorter.
- I throw away more code. And that’s fine. When generating a first pass is cheap, you stop being precious about it. Bad approach? Scrap it, try a different angle. The cost of exploration dropped to nearly zero.
- I think in systems, not steps. Instead of “what do I code next,” I think about “what does this system need to do, and what’s the fastest loop to get there.”
- I read more code than I write. Reviewing, evaluating, steering — that’s the job now. The typing was never the hard part anyway.
The skill that matters
If everything is a loop, then the skill isn’t writing code. It’s evaluating code. It’s knowing what good looks like. It’s having the judgment to say “this approach won’t scale” or “this is fine for now, ship it.”
That’s engineering. It always was. We just used to bundle it with the manual labor of typing it all out.
The engineers who thrive in this world aren’t the ones who type the fastest. They’re the ones who can look at a generated solution and immediately tell you what’s wrong with it — and articulate exactly what to do instead.
Start small
If this sounds abstract, try it on your next task. Instead of opening your editor and writing line one, start by describing what you want. Run the loop. Evaluate. Correct. Repeat.
You’ll feel uncomfortable at first. It feels like you’re not doing anything. But steering is doing. Evaluating is doing. And you’ll ship faster than you did last week.
Everything is a loop. The sooner you internalize that, the sooner the way you build software changes for good.