How I Use AI Coding Agents on Client Work, and What Stays Human

When a CTO asks whether I use AI coding tools, the honest answer is “yes, on everything, and that is why a day rate buys more than a pair of hands”. The useful answer is how, because the same tools that let one engineer ship like a small team will also let one engineer ship a mess at the same speed.

This is the short version of how I run them on client work. The long version, with the numbers behind the tooling, is on my personal site.

What the agents actually do

An agent with a blank prompt is a fast junior with no memory. It does not know how your repository deploys, which decisions your team already made, or that a migration will lock a table under load. So I do not hand agents blank prompts.

Every kind of work I do repeatedly is written down as a workflow: a sequence of phases, each with the inputs it needs, the outputs it must produce, the reference material it should read, a model tier, and a gate that has to pass before the next phase starts. Building an API is one workflow. Hardening it and shipping it to staging are the next two in the chain. A runtime parses the definition into a graph and runs one agent per node - cheap models for the deterministic parts, expensive ones only where judgement is needed.

Inside your engagement the agents read your codebase, your conventions and your open decisions before they touch anything, and they work in your repository with your CI. Nothing runs in a sandbox that later gets pasted over.

What changed for the client

Throughput, mostly. This year the same setup took two of my own products from empty repositories to live betas in a few months each, with tests, billing and deploy pipelines, from one desk. On client work that shows up as a first release landing in weeks rather than a quarter, and as a bug-fix cycle measured in hours.

What it does not change is the amount of reading. Most of the review load moved from reading code to reading test output and screenshots, which is a better place for it. Every agent session runs under a verification gate: derive the requirements from the request, check the actual diff against each one, run the smallest relevant test or build, and report anything unchecked by name rather than implying it works. A green build has shipped a page that crashed on load more than once, so screenshots are part of the gate for anything visual.

The three things an agent never decides

Anything a third party sees. A pull request to your repository is prepared and handed to me for the button. Anything with your name or mine on it outside the repository - an email, a directory listing, a post - is drafted and staged, never sent. I learned this one the hard way, and the rule has been absolute since.

Architecture. Agents did not decide that a hospitality product should be multi-domain with one locale per domain, or that guest uploads should be QR-based, or which queue belongs between an ingestion pipeline and a search index. They implement designs. Holding the design in my head and breaking it into work an agent cannot slip past is the job.

When to stop. An agent will happily describe a fix it did not verify in the same confident tone as one it did. The gates turn that from a character flaw into a process failure that the next phase catches, and the person who reads the failure is me.

What this means if you are hiring

If a senior role has been open for months, the seat can be filled next month by one engineer with this tooling, in your tools, on a day rate, with a clean handoff when your hire arrives or an ongoing seat if they do not. You get the speed of the agents and the judgement of someone who has been accountable for one platform for eight years.

If that is the constraint you have, tell me what’s stuck.