The skill that survives every AI wave: knowing when to stop.
I spent a Saturday rewriting a perfectly fine PR that AI had already written. By Sunday night, I'd added two bugs, broken a test, and learned the most important skill of the next decade.
A few weeks ago I spent a Saturday afternoon rewriting a PR that was already merged.
The PR had been opened by a junior on my team. Most of it had been generated by Claude. It worked. The tests passed. The code was clean enough that I'd approved it on Friday without much thought. Then on Saturday, I opened my laptop with a coffee, started reading it again, and found myself thinking, I'd have done this differently.
So I did it differently. Three hours. A few hundred lines moved around. By Sunday night I'd added two bugs, broken one of the original tests, and finally pushed it back to its original shape.
I closed the editor and sat there feeling like an idiot.
The pattern
I've been doing this my whole career. Not always with AI in the loop. The behaviour predates the tooling. There's a certain kind of engineer (I am this engineer) who can't stop polishing once they start. We rewrite things that don't need rewriting. We refactor for taste. We add a generic type parameter because the type system "could" support it. We pull in a library to do what fifteen lines of plain code would do fine.
It used to be expensive. You had to type all of it. The cost was a natural brake.
AI removed the brake.
If you've asked the model the same question three different ways and the answer still doesn't feel right — the answer is not in the model. Close the chat. Write a 50-word note in plain English about what you're trying to do. Half the time the note is the answer.
Now I can sit down on a Saturday and rewrite a working PR in three hours, where it would have taken three days. The economics shifted. The temptation went up. The judgment didn't.
What I keep watching senior engineers do
The best engineers I work with have one shared trait that nobody talks about, and it's not raw intelligence. It's the ability to say "this is good enough" and actually mean it. To close the PR. To move on. To respect the code as it is, especially when they could make it slightly better.
I used to think this was laziness disguised as wisdom. I've come around. The thing is, almost everything in software is connected to everything else. The cost of touching a working system is rarely zero. You might add a bug. You might break a downstream consumer. You might introduce a dependency that's a tax for the next three years. The "small" rewrite that improves taste by 5% can easily cost you 50% of a week.
The senior engineer's superpower is being calibrated about that math.
How this changes in the AI era
When the model writes the code, you have to read it. So you read it, and your brain immediately starts generating opinions about how you would have written it. Sometimes those opinions are right. The model produced something dumb, or insecure, or twice as long as it needed to be. You should rewrite it.
But most of the time, the model wrote something fine. Different from how you would have written it, but fine. And fine is genuinely, deeply fine. It works. It passes review. It will probably never be touched again.
The skill is learning to feel the difference between "this is wrong" and "this isn't how I would have done it." Those two things feel almost identical when you're staring at a diff. They're not the same. The first means rewrite. The second means walk away.
How to practise stopping
Three things have helped me. None of them are revolutionary.
When I'm reviewing code I'd write differently, I count to ten before commenting. Most of the time the urge to rewrite passes. It's nicotine, basically.
When I'm about to start a Saturday refactor, I write down what I expect to gain. Then I write down what I'm betting against (subtle bug, broken downstream, week-long rabbit hole). If the gain is just "feels better", I stop.
When the model produces something I think I could improve, I ask it to explain why it made the choice. About half the time, the answer makes me reconsider. About a quarter of the time, it makes me realise the model knew something I didn't.
The other quarter, I rewrite it. But that's a much smaller fraction than it used to be.
Closing
The career-defining skill of the next decade isn't going to be writing more code. We have unlimited code now. It's going to be deciding what code to leave alone. The engineers who get really good at that will keep ageing well. The ones who can't will burn out trying to perfect a codebase that didn't need perfecting.
Knowing when to stop. That's the whole game.