Where I keep AI out of the loop
My bottleneck used to be how fast I could learn a new stack and ship the code. Now it's how clearly I can say what I'm trying to build, and how much of me ends up in it.
Both ends got cheap
AI can build products end to end now. Research models will scan a space and produce a hundred feature concepts in an afternoon. Coding agents will pick up a plan and run develop-test-deploy on their own schedule. Both ends of the work that used to define a senior engineer's day are cheap.
The result, if you're not careful, is a flood of products that all look the same. Generic feature sets, repeating shapes, the same five layout patterns. You can spot it within ten seconds of opening a homepage. The market is going to be drowning in it for the next two years.
So the question for anyone shipping right now is the inverse of the one most people are asking. Not where do you put AI in the loop. Where do you keep it out?
The four-step loop
Four steps. I own the middle two.
01 — Generate (AI). I ask the model to research a space and hand me a hundred feature concepts. Most are generic. That's fine. Options are cheap and I want the widest net.
02 — Curate (me). I read all 100 and keep about five. The rest go. This is the first place taste enters: knowing what to cut. The cuts are what make the kept ones distinctive.
03 — Add taste (me). Each survivor gets expanded into a high-level plan, written into the repo. The plan captures what I want, what I don't, what edge cases matter, what the result should feel like. My preferences live in that plan. This is the longest step.
04 — Build (AI). An agent picks up a plan on its own schedule and runs the develop-test-deploy cycle. I'm not in the room for any of it. By the time I look, the feature is in a branch waiting for review.
AI on the ends, me in the middle. The ends used to be the hard part. They aren't anymore.
What one pass looks like
Take one feature on a product I'm working on: how to handle a user coming back after they've drifted away for a few weeks. Step 01 returns a hundred ideas: every onboarding pattern, every notification model, every layout. Maybe seven feel like they're worth my attention. I cut to those, then to three, then to one. Step 03 is the brief: recognize the user by their last action, not their email. Surface the thing they were doing when they left. Skip the welcome-back banner. Don't ask for confirmation on anything. Step 04 the next morning is a pull request: the feature built to the brief, tests passing. I review it the way I'd review any other PR.
The pass took me about two hours of focused thinking spread across two days. Most of that was step 03.
Where it doesn't work
The loop fails when you don't have taste in the domain yet. You can't curate what you can't evaluate, and a brief with no preferences in it produces output a generic prompt would have produced. It also fails when the 100 concepts converge. If the search space is small enough that every option is a variation of the same idea, there's nothing to curate. And it fails when the build step needs your judgment mid-flight. If the work is too entangled with calls only you can make, the agent can't run on its own time.
Most of the energy I've spent figuring out how to work with AI has gone into the middle two steps. The parts that used to define the day, the writing and the shipping, are what the machine does now. What's left is harder to articulate and harder to delegate: deciding what's worth building, and saying what "done" means clearly enough that an agent can hit it.
That's the part nobody is going to do for you.
If you're trying to figure out where AI fits in your own shipping process without flattening what makes your product yours, an Implementation Sprint is two weeks of us working together to use patterns like this loop to build your project and get you to a place where you can continue on your own.