AI took the cost out of producing code and copy. It never touched the cost of judgment. Here’s how I actually work with Claude Code, and the line I try not to cross.

In short: I hand AI the labor, drafts, scaffolding, and first passes, mostly through Claude Code, and I keep the decisions: what to say, what to cut, and what ships. The practical move is naming your own line between the two, then handing off everything on the other side of it freely.
Picture an ordinary Tuesday. A client needs a landing page live by Friday, the brief is thin, and the budget doesn’t stretch to a week of hand-crafting. A few years ago that was a stressful week. Now I open Claude Code, describe what I want, and a working first pass exists in about the time it takes to make coffee.
Here’s the part that matters, though. The draft was good, and it was also quietly wrong. It led with a feature the client is proud of and the customer doesn’t really care about. Claude built exactly what I asked for. The trouble was that what I asked for wasn’t what the page needed. No tool was going to catch that. That one was mine.
That small moment is the whole story of building with AI, so let me pull it apart.
Producing a working component, a first draft of copy, a schema, a quick migration script: tools like Claude Code made all of that close to free. That has genuinely changed my week. What hasn’t changed is the expensive part. Deciding what to build, what to cut, and what "good" means for this particular client is still the job, and it’s the part a machine can’t do for me.
So the way I run it is simple, and I hold it loosely. I let AI carry the labor. I try to keep the judgment.
I treat AI output as a proposal, not a verdict. Whoever signs off still owns it.
The failures I watch for are rarely dramatic. AI doesn’t usually hand you something broken. It hands you something plausible. A layout that looks fine but buries the one action that matters. Copy that reads smoothly and says almost nothing. A data model that works for the demo and cracks on the second real use case. Broken is easy to spot. Plausible-but-wrong is the one that slips through, and the only defense I’ve found is to keep asking a slightly annoying question of everything it gives me: is this actually right for this client, or does it just look right?
On the Tuesday page, the fix took ten minutes once I saw it. I reordered the story, cut the feature the customer didn’t care about, and asked Claude to redraft around the new lead. Ten minutes of judgment saved a page that would have quietly underperformed for months. The speed got me to the decision sooner. It didn’t make the decision.
Most of my builds run like this now. I move between Figma, Webflow, and code with Claude in the loop as a fast collaborator. I describe the intent, it drafts, I direct, it revises. The rhythm is quick, but the value isn’t the quickness. It’s that my attention lands on the handful of choices that actually shape the outcome, instead of the typing that never did.
If there’s a lesson here, it’s a gentle one. The people getting the most out of these tools aren’t the ones producing more. They’re the ones deciding a little better and a little faster, with a clear sense of what a machine should never own. A good place to start is to name your own line: the decisions you’ll always make yourself, no matter how convincing the draft looks. Everything on the other side of that line, hand off freely.
This is roughly how the team and I work at Dthree Digital, and it’s a good part of what we end up talking through with clients trying to figure out where AI fits in their own build. If that’s you, I’m always happy to compare notes.
New writing on how the web actually gets built, plus the free pixel wallpaper pack when you subscribe.
Related reading
Based in Manila, working with teams across time zones.