Typing was the slow part of building software for most of my career. That part is now close to free, and the surprise is not how much faster the work got. It is where the time went instead: reading, deciding, and checking.
Reading
Every line the tool writes is a line someone has to understand, and that someone is me. I used to read code I had written, which is a strange kind of reading because you already know what it says. Now I read code the way a reviewer reads a pull request from a capable colleague who does not know the business: quickly for shape, slowly for the places where the business rules live.
The places that need the slow read are predictable. Anything that decides who can see what. Anything that moves money or changes a status that money depends on. Anything that talks to another system. The tool is good at the first two forms and quietly wrong about the third, because the third is where the rules it was never told about apply.
The tell is confidence without a source. When a generated function handles a case I did not describe, I ask where that case came from. Sometimes it is a genuine inference from the schema. Often it is a plausible guess, and plausible guesses are how a total ends up wrong on the invoices nobody checks by hand.
Deciding
When building anything costs a few minutes, the question “should this exist” stops being rhetorical. It used to be answered by the cost: a feature that would take a fortnight had to earn its place. Now a feature that takes twenty minutes can be built before anyone has asked whether it should be.
So more of my time is spent before the tool is opened. What is the smallest thing that would prove this is worth doing? What does the person who asked for it actually do all day, and does this change it?
The most useful hour is the one spent interrogating the plan, one question at a time, before a line is generated. A colleague turned that into a three-sentence prompt that makes the agent do the interrogating, and I now run it on anything that touches a schema, an architecture or money.
Checking
The third place is the boring one, and it is where the leverage is.
Tests, for a start, but tests check the cases you thought of. What AI-generated logic tends to get wrong is the case you did not think of, and it gets it wrong silently: nothing crashes, the number is just off.
So the check I build into every system is an invariant, a property that must hold for every row, evaluated against real data. The header total equals the sum of the lines. A draft cannot become paid without passing approved. No row points at a parent in another tenant. Checked inline on the write path, and again in a nightly sweep that catches drift from imports and manual edits.
The rule that makes this survive as a practice: log and continue, do not throw. A wrong invariant blocking a user is worse than the bug it guards. Hard-fail only for tenant isolation and anything that moves money. And never let a breach sit amber for more than a week, or people stop reading the alerts.
Then security, which gets its own note, because the tool will happily write forty routes that each check permissions slightly differently and call it done.
What this adds up to
The engineer’s job did not get smaller. It moved. Less of it is producing code and more of it is deciding what code should exist, understanding what was produced, and building the checks that catch what nobody read closely enough. If that sounds like what a senior engineer was always meant to be doing, that is the point. The tools took away the part that was getting in the way.