LFH Lab Start a project
Lab Notes/Process
PROCESSSEP 2026

What Claude Code is actually good for on a client build

A year of shipping with an AI coding agent, and an honest split of what it does well, what it does badly, and what it can't do at all.

Most writing about AI coding tools comes from people selling them or people afraid of them. I'm neither.

I've written software for twenty years and run engineering orgs of two hundred people. For the last year I've shipped nearly everything at LFH Lab with Claude Code doing a large share of the typing. Here's where that's landed, sorted by how often it comes up.

Where it earns its keep

The second time. Once I've built something properly once, Claude Code is very good at building the next one the same way. It's how a single form backend became the form backend for thirteen sites, and how a new Eleventy site goes from empty folder to deployed in an afternoon. The pattern exists; the agent applies it. This is where most of the speed comes from, and it's the least glamorous part.

A spec that's actually a spec. Given a clear description of a feature with the edge cases named, it produces the first pass faster than I can, and the first pass is usually close. The quality of the output is almost exactly the quality of the description. That's not a limitation of the tool. That's how delegation has always worked.

The parts nobody wants to write. Test scaffolding. Migration scripts. The admin screen for a table with three columns. Documentation for code I wrote and didn't document. It doesn't get bored. I do.

Reading a codebase I've been away from. Coming back to a product after four months, the fastest way to remember how it works is to ask. This changed how I write handoff docs: they're written for the agent as much as for a person, and it turns out those are the same document.

Where it gets it wrong

Knowing when to stop. Left alone, it keeps going. It adds a config option nobody asked for, abstracts a thing that appears once, refactors a file that was fine. The instinct to leave working code alone is a senior-engineer instinct, and it doesn't come with the tool. It has to come from whoever is directing it.

Anything where the hard part is the decision. Which payment model. Whether the feature should exist at all. What the client actually meant. It'll happily build any of the options. It won't tell you which one is right, and when it tries, it sounds confident in a way that should make you nervous.

Taste. Ask it for a UI and you get one that works and looks like every other UI: the same card grid, the same gradient button, the same hero copy. That's not a bug; it's the average of everything it's seen. Making a product feel like it was made by a specific person still means a person making the choices. Every product on this site with any personality got it from me deleting the default and picking something else.

Consistency across months. Within a session it's fine. Across a project that spans a quarter, without a strong context file and a person holding the thread, it drifts. Different sessions make different choices about the same problem. This is the thing a handoff doc solves, and it's why I now write that doc first, not last.

What it can't do

Own the result.

When something ships broken, the agent isn't in the postmortem. When a client asks why a decision was made, the answer has to come from someone who was there. The tool moved the work. It didn't move the responsibility. Anyone selling you a build where the human is "just reviewing" is describing a project with nobody in charge.

If you're hiring me

A client engagement here is faster than it was two years ago, and not because code got cheaper to type. It's because more of the schedule goes to the parts only a person can do: understanding what the product is for, deciding what it isn't, and making it feel like something. The typing was never the expensive part. It was just the slow part.

Two questions worth asking anyone who builds software for you. If they say AI made senior engineers unnecessary, ask who's directing the agent on their projects. If they say AI can't be trusted with production code, ask when they last used it. The truthful position is in between, and it's a working position, not a philosophical one: the tool is excellent at applying judgment, and it has none of its own.

More notes, or the work itself.
Everything here comes from products that are live right now. Read the rest of the notes or go look at the shelf.
All notes The work →