Most conversations about AI at work are about delegation: what to hand off and what to keep. I think that is the wrong question. The real risk isn’t bad code. It’s slowly losing the ability to read your own system.
The Cost of Handing Everything Off
If you delegate everything, including the small stuff, you stop touching the code. Slowly, the mental model of how the system actually fits together starts to fade. And once it fades, you lose the one thing that lets you review AI output properly: knowing what should have happened.
For me, the answer isn’t to use AI less. It’s to stay in the loop on purpose.
Why I Still Write Small Changes by Hand
When I know exactly where and how a change should be made, I write it myself. I have tried the AI route for these, and it fails for two different reasons:
- The context is expensive to transfer. The shape of a change often depends on history, conventions and constraints that live in my head. Writing them all down costs more than the edit.
- The change is trivially obvious. The prompt ends up longer than the diff. I can make the change in three minutes, without the overhead of specifying, waiting and reviewing.
There is a side benefit I didn’t plan for: small edits keep me in contact with the codebase.
Plan, Follow, Steer
I don’t hand off tasks like that. I treat the work as a conversation that runs from the first plan to the last line.
- Plan in detail: Before any code exists, I discuss the approach with the model: constraints, trade-offs and what must not change.
- Follow the implementation: I watch it unfold instead of waiting for a finished diff.
- Ask for explanations: If I don’t understand a choice, I ask why. That question is often where a wrong assumption surfaces.
- Interrupt: If it’s heading in the wrong direction, I stop it early and redirect.
- Edit directly: Sometimes it’s faster to add something myself than to describe it.
It goes back and forth. That is the point.
Examples:
The Simple Fix That Wasn’t
Recently I had to improve a design decision made years ago that kept interrupting current processes. We relied on a third party in the worst possible way: errors weren’t caught, the information surfaced was thin, and there was no observability and no documentation. The result was incidents. The most visible symptom was duplicated data: there was no retry at all, so when something failed, the same data ended up being sent again and arrived as if it were new. The constraint was to fix it without rewriting the world and without disrupting the processes running on top of it, while still accounting for the unknowns.
- The Reality: My first instinct was the simplest fix that could work.
- The Shift: Before writing any code, I laid out the problem and my plan, and asked the model to challenge it.
It caught a lot of side effects I hadn’t thought through, and the one that mattered most sat right at the centre of the fix. Adding a retry sounds like the cure for duplicates, but a naive retry can quietly make them worse. The original problem was that the same data kept arriving as if it were new. A retry that doesn’t know it is a retry does exactly that, only automatically and without anyone noticing.
So the real requirement wasn’t “retry”, it was “retry safely”. The system had to be able to recognise that an attempt was the same one as before, and to stop when it should. There was also a person in that loop, someone relying on the outcome, who needed to know what had actually happened instead of guessing and sending it again. Guarding that person, and the data, turned a small patch into a fundamentally different design.
It is the same adversarial idea I described in the red-team post, applied to design instead of tests. The hard part of this task was never typing the code. It was thinking the problem through, and that is exactly where the conversation earned its keep.
Calibrated Trust
I will admit something: I sometimes trust the implementation blindly. I don’t think that’s a flaw, as long as it’s a decision and not a default.
Even then, the monitoring never fully stops. Only its intensity changes.
Keeping the Model in Your Head
Using AI well isn’t about doing less thinking. It’s about spending the thinking where it matters most, in the plan, and staying close enough to the work to notice when something is off.
By shifting the question from “what can I hand off?” to “what do I need to stay close to?”, you keep the tool useful and your judgement sharp. You stop supervising code you don’t understand, and start working with a system you still can read.