Writing code got cheap. Checking whether the code is right did not. Everything I have changed about how I work in the last two years follows from that one asymmetry.
I use AI heavily and I have a firm line about what I will not hand over. The line did not come from principle. It came from losing most of a day to a change that looked correct, passed review, and was built on a premise that was wrong from the first sentence.
What actually happened
I asked for a fix to a problem I had already diagnosed. I described the diagnosis in the brief, because that seemed efficient, and got back a clean, well-structured change that did exactly what I asked.
The change was fine. My diagnosis was wrong. The symptom I was chasing had a different cause, and because I had stated my conclusion as context rather than asking for the cause, nothing in the process ever questioned it. I got a correct implementation of the wrong idea, delivered quickly and confidently, which is considerably worse than getting nothing.
The time did not go into writing the fix. It went into the hours afterwards, trying to work out why a change that was clearly right had not helped.
The lesson was not “be careful with AI.” It was more specific than that. The failure mode is not bad code. It is good code built on a premise nobody checked. Speed makes it worse, because a wrong premise now reaches a finished implementation before you have had time to doubt it.
The line I settled on
I delegate execution. I do not delegate understanding.
What I hand over without hesitation: research across a codebase I do not know well, mechanical refactors with a clearly bounded scope, tests for behaviour that is already settled, and documentation generated from code that already exists. In all four, I can check the output against something concrete. A refactor either preserves behaviour or it does not. A test either describes the real contract or it does not.
What I keep: architecture decisions, any trade-off between two defensible options, final review on anything touching money, auth or customer data, and above all anything where the premise might be wrong.
That last category is the one that matters and the one people skip. It is not about task difficulty. Some of the work I keep is easy. It is about whether I would be able to tell that the answer was wrong. If the output is something I can verify in a minute, delegate it. If the output is something I would accept because it looks plausible, do it myself, because looking plausible is exactly what these tools are best at.
What the asymmetry does to a workflow
Once generation is nearly free, the bottleneck moves entirely to verification, and your process has to move with it.
The practical version: I now spend more time on the brief and more time on the review, and almost none in the middle. A vague brief produces confident, generic work that takes longer to evaluate than it would have taken to write. A precise brief produces something I can check quickly. The brief is where the leverage is, and it is the part that feels like overhead right up until you skip it.
I also changed what I ask for. I stopped handing over my conclusions as context. Instead of “fix this, the cause is X,” I ask what the cause is and make it show me the evidence. If I already know the answer, confirming it costs seconds. If I am wrong, I find out before the wrong fix exists rather than after.
The second change is deciding up front whether something needs a plan at all. My test is four questions. Will this take more than a few commits? Does it cross module boundaries? Is there rollback risk? Could it break something silently? Any yes means write the plan first. Everything else is a direct edit, and treating a one-line change like a project is its own kind of waste.
The silent-breakage question is the one that earns its place. Loud failures get caught by anything. The changes that hurt are the ones where nothing throws and a number is quietly wrong for a week.
What I do not claim
I am not faster at everything. I am much faster at some things and about the same at others, and the ones where I am about the same are the ones that were always the hard part: deciding what to build, deciding what to stop building, and working out why something that should work does not.
I also do not think the tooling made me a better engineer. It made me a faster one, and it made my mistakes arrive sooner and in more polished form. The judgment about which output to trust is the same judgment I needed before, applied under more time pressure and against work that looks more finished than it is.
The engineers I would want to work with are not the ones who have strong opinions about which tool is best. They are the ones who can say precisely where they stop trusting it, and why, from something that actually happened to them.
Mine is the premise. I check it myself, every time, because that is the one mistake the speed makes worse instead of better.
Questions I get asked about this
What should you not delegate to an AI coding agent?
Anything where you would not be able to tell that the answer was wrong. In practice that means architecture decisions, trade-offs between two defensible options, final review on code touching money, authentication or customer data, and above all anything where the premise might be wrong. The test is verifiability, not difficulty. Some of the work worth keeping is easy.
What is safe to delegate?
Work you can check against something concrete: research across an unfamiliar codebase, mechanical refactors with a bounded scope, tests for behaviour that is already settled, and documentation generated from existing code. A refactor either preserves behaviour or it does not. That is a checkable claim.
Why is a wrong premise worse than wrong code?
Wrong code fails visibly and gets caught. A wrong premise produces correct, well-structured, confident work that solves the wrong problem, and it arrives faster than your doubt does. The time is not lost writing the fix, it is lost afterwards trying to understand why a change that was clearly right did not help.
Does using AI make you a better engineer?
It made me faster, and it made my mistakes arrive sooner and in more polished form. The judgment about which output to trust is the same judgment I needed before, applied under more time pressure against work that looks more finished than it is.