AI-Assisted Building

How I actually build with AI, and where I still won’t

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.

How I actually build with AI, and where I still won’t

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.

A Tuesday that could have gone wrong

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.

The cost that collapsed, and the one that stayed

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.

What I happily hand off

  • Scaffolding and boilerplate, the tedious 80 percent of any build.
  • Turning a Figma layout into clean structure and classes.
  • Trying three approaches quickly before I commit to one.
  • First drafts of copy or docs that I’ll rewrite in my own voice.
  • Explaining an unfamiliar API so I can make a call instead of guessing.

What I try to keep on me

  • Information architecture and the real user decisions.
  • Taste. What goes out under my name should meet my bar, not an average.
  • The client relationship, and the judgment calls living inside it.
  • The final read on whether a thing is actually right.
I treat AI output as a proposal, not a verdict. Whoever signs off still owns it.

The trap is plausible, not obviously wrong

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?

Back to that landing page

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.

What this means if you’re trying it in your own work

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.

Related reading

Keep reading

Have a project in mind?

Let's build something that lasts

Get in touch

Based in Manila, working with teams across time zones.