I use agentic coding tools — Claude Code, most days — on paid client work. Not on a weekend side project: on the internal portals, data pipelines, and integrations real companies run their operations on. It has been part of my normal working day for a while.
Almost everything written about this falls into one of two piles: the profession is about to be automated away, or the tools are a party trick that cannot be trusted to write a loop. Both piles are written largely by people who are not shipping billable work with them. So here is the boring middle, from someone who is.
What this means if you run the business, not the codebase
Here is the whole thing in one line, before any of the detail: the floor for “is this worth building” dropped, and the value of judgment about what to build went up.
The internal tool you shelved because it did not justify a serious budget may pencil out now. The awkward little workflow that eats a couple of hours a week and was never big enough to be a project is exactly the kind of thing that now fits in a small engagement. That is a genuine change, and worth revisiting the list of things you gave up on.
But three things did not change, and pretending otherwise is how people get hurt:
- Building the wrong thing quickly is still building the wrong thing. Cheaper software means more software, and more chances to automate a process that should have been eliminated instead. The best outcome of a discovery conversation is still sometimes “do not build this.”
- Maintenance is unchanged. Code still has to be owned, hosted, patched, and understood by someone in three years. Generation speed touches none of that.
- Demos are still easy and production is still hard. A prototype has always been a fraction of a finished system. The gap — auth, error handling, edge cases, the exception your business has had for a decade — is where the real work lives, and it is the part that does not compress.
None of this is a reason to be excited or cynical. It is a change in what a given budget buys, which is a normal thing that happens in a trade. My job did not become writing code faster. It became being right more often about which code is worth writing — which is what clients were paying for all along.
The questions a business owner should be asking
If you are hiring anyone to build software right now, assume they are using these tools, because most competent people are. The questions worth asking are not “do you use AI.” They are:
- Does anything sensitive from my systems — customer records, credentials, exports — end up in a third-party tool, and under what terms?
- Are secrets kept out of the code itself, so what an assistant reads is configuration-shaped, not credential-shaped?
- Who reviews what gets written, and what stands between it and production?
- If the builder disappears, can someone else read it? Generated code can be perfectly maintainable or completely opaque, and that is a choice the builder makes, not the tool.
You do not need a technical answer to those. You need an answer at all.
Why this lands differently on some work than others
Pricing is hourly with a clear estimate up front; longer relationships move to a retainer. That has not changed. What is worth understanding is where the hours in an estimate actually go, because the tools only touch one kind of hour.
Well-specified greenfield work has the most mechanical content to give up. If you can tell me exactly what a tool should do, and I am building it fresh rather than threading it into something fragile, a larger share of that job is typing that no longer has to be done by hand.
Work that is mostly discovery has almost none to give up. Untangling an undocumented legacy system, reverse-engineering a workflow nobody wrote down, integrating with a system I cannot safely test against — those jobs are dominated by understanding and verification, and neither of those got cheaper.
And one category deserves to get more careful. When code arrives faster than anyone can think about it, the risk moves from “will this get built” to “will anyone notice it is subtly wrong.” For anything touching money, permissions, or a client’s customers, verification is worth treating as its own line of work rather than assuming it comes along for free.
That shows up directly in what I quote. Build-heavy work — a new internal tool, a portal starting from an empty repository — comes in at fewer hours than the same job would have taken a few years ago, and I quote it accordingly. Discovery-heavy work did not move. I wrote up the actual bands and what drives them separately, including the part where my hourly rate went up while the totals came down.
That is the conclusion. The rest of this is the evidence for it — what actually changed in the work, what did not, and what goes wrong — from someone doing it on billable projects rather than writing about it from the outside.
What genuinely got faster
The pattern is consistent: these tools are fast at work that is mechanical, well-specified, and cheap to verify. That describes more of software development than most people outside it would guess.
- Boilerplate and scaffolding. A portal screen is the same shape every time: a list view, filters, a detail page, role checks, a write to an audit trail. I have built that shape many times over; describing it is now faster than typing it, and the result is code I would have written anyway.
- Database migrations. Add a column, backfill it, add the index, write the down-migration. Tedious, easy to fat-finger, and completely deterministic once the intent is clear.
- Test scaffolding. Not the interesting assertions — the fixtures, the setup, the eleven near-identical cases surrounding the one that matters. That is the part I used to skip when a deadline got close, which is exactly the wrong part to skip.
- Unfamiliar APIs. This is the big one. A large share of my work is integration — wiring a CRM to an accounting package, pulling from a public-records provider, normalizing a vendor feed. Each of those used to start with an hour of documentation just to learn whether the thing I wanted was possible. Now I get a runnable first attempt and find out immediately.
- Mechanical refactors. Renaming a concept consistently across a codebase, pulling a duplicated block into a shared function, folding a pile of one-off scripts into one parameterized job. Work that was always more attention than thought.
The common thread: in every one of those cases I can tell within about a minute whether the output is right. That is the whole reason the speedup is real.
What did not get faster, honestly
Almost nothing about the actual hard part of consulting changed.
Understanding what a business actually does. The hardest part of any project is still the workflows — and the thing one person has been quietly fixing every Monday. No tool has access to that. It lives in people’s heads and in the exceptions nobody wrote down, and the only way to get at it is to ask.
An example of the shape of that, from data work I do: property records frequently list a trust as the legal owner, which hides the actual person behind it. Writing a classifier that flags trust ownership is the easy part. Recognizing that hidden trust ownership was worth modeling at all is judgment, not code.
Decisions with real consequences. Whether to merge two datasets into one canonical record or reconcile them at query time. Whether a fuzzy match at a given confidence score should auto-merge or go to a human. Whether an integration should retry or fail loudly. Getting those wrong surfaces months later, in someone’s reporting, as a number nobody trusts. An agent will happily pick one. It has no stake in the answer.
Legacy systems with no documentation. Some of my work starts as an emergency — a spreadsheet full of macros that grew into a business-critical system. There, the macro is the documentation. Reading it, sorting intentional behavior from bugs everyone has quietly adapted to, deciding what must be preserved exactly — that is archaeology. Agents help me read faster. They do not help me decide what matters.
Anything where being wrong is expensive. Money movement, permissions, anything customer-facing, anything that deletes. In those areas I move slower than I used to, because I am reviewing code I did not type myself.
The failure modes that actually show up
Not hypothetical — the recurring ones, in rough order of how much trouble they cause.
- Code that runs and is wrong. The most expensive failure by a wide margin. It compiles, the page loads, the number on screen is plausible, and the aggregation quietly double-counts. Nothing throws.
- Confidently invented API surface. A method that does not exist, called with parameters that never existed. Cheap, because it fails immediately — but a standing reminder that fluency and correctness are unrelated.
- Fixing the symptom instead of the cause. A page renders partly-correct data and the plausible-sounding diagnosis is a stale cache — when the real cause is two views sharing an include scope, so one page’s variables leak into another’s. Clearing caches “fixes” that right up until it comes back. The suggested explanation tends to be the common one, not the one actually in front of you.
- Unrequested scope in the diff. I ask for one change and get that change plus three helpful improvements to files I never mentioned. Each of those is an unreviewed change to working software.
- Destructive operations that look routine. The class I worry about most, because it does not announce itself. I once found a deployment script that was inadvertently wiping the directory used for certificate-renewal challenges. Nothing errored, nothing alerted; renewals were simply going to stop, and the first symptom would have been customers seeing a scary browser warning. I caught it before the certificate lapsed. That one had nothing to do with AI — but it is exactly the shape of mistake generated code makes look normal, and it is why I read deploy scripts line by line.
The include-scope one is not hypothetical. In my own operations portal, several views are pulled into a shared scope, and a banner partial ended up reading a generic variable that a different page had populated — so one page rendered another page’s data. Nothing errored. The page just quietly showed the wrong thing, on some requests and not others, which sent me looking at caching for far longer than I would like to admit before the actual answer turned out to be scope. Generated code is very good at producing that shape of bug, because each individual file looks correct in isolation.
The review discipline that catches them
None of this is clever. It is the discipline that has always separated software that holds up from software that does not. The tools just raised the volume moving through it.
- Small changes. If I cannot hold the whole diff in my head, it gets split.
- I read every line before it lands. Not skim — read. This is the rule I will not bend, and it is where the honest cost of these tools sits.
- Run it. A description of what code does is not evidence about what code does.
- Tests where the consequences are real: money, permissions, anything a customer sees.
- Migrations get reviewed and applied deliberately by a person, against a backup I have actually restored from. A backup is theory until then.
- Deployments stay scripted and boring. The path to production does not change just because the code got written faster.
The bottleneck was never typing. It was knowing what to type, and being sure it was right. Exactly one of those got automated.
If you have a shelved project that did not justify the cost a couple of years ago, it is worth another look. You can see the kind of work I take on on the services page, or just get in touch and tell me what is annoying you. I’ll reply within a day.