Skip to content
Back to all articles

AI coding tools in 2026: what changes on a client build

8 min read
Isometric illustration of an AI coding assistant on a dark background: a code editor with generated lines, an autocomplete panel, a context-aware assistant, a diff review, and a "time saved" chart

I design most of what I build, and I have used AI coding assistants on client work since they were autocomplete with good manners. The honest update for 2026 is that they got fast enough to change how a project is scoped, not just how a function gets typed — and fast enough that the mistakes they make are also easier to ship without noticing.

This is not a tool comparison. It is where the speedup is real on a paid client project, where it is not, and what changed about how I review my own output because of it.

Scaffolding is fast now; judgement still is not

Ask a current model to build a settings page with a form, validation and a save state, and it will produce something that runs in under a minute. That used to be twenty minutes of typing. The part that has not moved is deciding what the settings page should actually contain, what happens when the save request fails, and whether this is even the right pattern for this particular client’s data.

That split is the whole story. Typing got cheap; deciding what to type stayed exactly as expensive as it always was, because it depends on context the model does not have — the client’s actual users, the edge cases from last quarter’s support tickets, the constraint nobody wrote down. Selling "AI writes your app" skips past the half of the job that was never the typing.

Where the speedup is real

Boilerplate and repetition are where this pays for itself every time: a component that needs five near-identical variants, converting a spreadsheet of copy into typed content objects, writing the fortieth test for the thirty-ninth pattern already established in the codebase. The model has plenty of local context and the task has one obviously correct shape.

Migrations are the other clear win. Bumping a UI library’s major version, renaming a prop across forty usages, converting class components to hooks: mechanical, high-volume, low-judgement changes that used to eat a full day now take an afternoon of generation plus review.

It is also a genuinely good pairing for token-to-code work: handing over a Figma file’s spacing and colour tokens and getting a first pass at a Tailwind theme config generated from them, then correcting the values by hand, is faster than typing the object from scratch.

Where it quietly costs time

Anything touching a codebase the model has not effectively seen — a large, idiosyncratic legacy client project, a non-standard state management setup, an internal library with its own conventions — produces code that looks right and is subtly wrong: a hook called in the wrong order, a type that compiles but does not match the actual shape of the API response. Confidently wrong is worse than obviously wrong, because it passes a skim.

Security-sensitive code is the other place I do not delegate the first draft: auth checks, anything touching payment, anything that decides what a user is allowed to see. The failure mode there is not a bug report, it is a client’s data exposed, and that is not a risk worth the minutes saved.

Net, on an unfamiliar or unusual codebase, review time can exceed the time saved in generation. The tool is fastest exactly where you already knew the codebase well enough to barely need it.

Review discipline changes, not disappears

I treat generated code the way I would treat a pull request from a fast, confident junior developer who has never met this specific client: read every line before it ships, do not assume the tests it wrote actually cover the case that matters, and check the diff against what the ticket asked for rather than against what looks plausible.

The specific habit that has saved me the most: asking the model to explain its own change back to me in plain language before I accept it. Where the explanation does not match what the diff actually does, that mismatch is usually where the bug is.

What this means for pricing and scope

Faster generation does not mean the work is worth less; it means more of what a client is paying for is judgement, review and taste rather than keystrokes, and that was arguably always the real deliverable. I have not dropped rates because a tool made the typing faster — I have used the time it freed up to spend more of a project’s hours on the parts that still need a human: the states nobody specified, the edge cases the ticket did not mention, testing on an actual device.

Where it has changed a quote: small, well-scoped, mechanical jobs — a migration, a batch of similar components — are now genuinely faster to deliver, and I price them accordingly rather than padding the estimate to a pre-AI baseline out of habit.

The stack that pairs well with it

Generated code is only as good as the constraints around it. A strongly typed codebase gives the model, and the reviewer, an immediate, mechanical check that a change is at least internally consistent. A codebase with clear conventions and a component library the model can see gives it a pattern to match instead of inventing a new one each time.

Next.js and Tailwind specifically pair well with this workflow: Tailwind’s utility classes are unambiguous in a way custom CSS class names are not, so generated markup rarely drifts from the design tokens, and a typed props interface catches a mismatch immediately rather than at runtime in front of the client.