Back to Field Notes

You're Paying for Decisions, Not Keystrokes

AI made typing faster. Typing was never the bottleneck. The job is still the job.

TL;DREngineering work isn't priced on words per minute. It's priced on judgment under uncertainty: what to build, how to structure it, what's safe to ship. AI doesn't make those calls. It just types faster.

AI made typing faster. Typing was never the bottleneck.

That matters commercially, because when a tool makes the visible part of a job cheaper, the reasonable next question from whoever is paying is whether the job itself got cheaper. It's a fair question and it deserves a straight answer rather than a defensive one. This is mine.

The expensive part was never the typing

The bottleneck is deciding what to build. How it should be structured. What trade-offs you're accepting. What's safe to put in front of users in a regulated environment.

None of those get faster because the code arrives faster. If anything they get harder, because there is more code arriving per hour and every line of it still has to be judged by someone who can tell plausible from correct. The model generates a plausible implementation from context. A senior engineer decides whether that implementation is correct, safe, fast enough, and a fit for the system around it. That decision is the thing being sold.

The question that actually costs money

Of that list, the expensive one is what's safe to ship.

The sectors I work in do not treat a defect as a defect. The hard question is rarely whether the feature works. It is what happens when it is wrong. Who can see this record, and can you demonstrate afterwards who saw it. Where does this data physically live, and what did you already promise about that. What is retained, for how long, and who agreed to it. What the system does when the service behind it is down, and whether that fallback quietly widens access to something.

None of that is a code generation problem. Those are questions about consequence, and they either get answered before the code exists or they get answered by an incident. A model will produce a clean, working, well tested implementation of an unsafe design and never raise an objection, because nothing in the prompt told it what this client is not allowed to get wrong. It has no stake in the outcome. Knowing which of those questions applies here, and asking it early enough to still be cheap, is the skill. That judgement is not general engineering knowledge. It comes from having been on the hook for the answer.

What changes in how I work

I type less. I read more. Most of a day now goes on review: reading generated code against the constraints it doesn't know about, rejecting the parts that only look right, and keeping the architecture coherent while the volume goes up. Faster generation shifts my time toward judgment; it does not shift how much judgment the work needs.

What you're buying

Someone who decides. Which problem is worth solving. Which design survives contact with your compliance obligations and your actual load. Which generated code is allowed near your users. Which shortcut you'd regret in a year, taken now anyway because the deadline is real, with the cost written down so nobody is surprised later.

And someone who is accountable for those calls when one of them turns out to be wrong. That accountability is the part no tool takes off your hands, and it's what the day rate is attached to.


Timothy De Bock

Timothy De Bock

Full-stack .NET platform engineer specializing in government, healthcare & security sectors.