In Brazilian jiu-jitsu there is a saying that the only way to get better is more mat time. You can watch every instructional, memorize every sequence and understand the theory of a position perfectly. None of it shows up when someone heavier than you is on top and you have two seconds to decide. What shows up is what you have done a few thousand times against people who were resisting.
Engineering works the same way, and most of the conversation about AI skips this part.
Replaced by whom#
By now everyone has heard some version of the line: you probably won't be replaced by AI, but by someone using AI. The economist Richard Baldwin said it at the World Economic Forum in 2023. It is true, and it leaves out the interesting part, which is what distinguishes the person doing the replacing.
Chess answered that question twenty years ago. In 2005, an online freestyle tournament allowed any combination of humans and computers. Grandmasters entered with strong engines. The winners were two amateurs from New Hampshire running three computers at once. Garry Kasparov later summarized the result: a weak human with a machine and a better process beat both a strong computer on its own and a strong human with a machine and a worse process.
The edge was not access to an engine. Everyone had engines. It was knowing which one to trust, what to do when they disagreed, and when to overrule all of them. That is judgment about the tool, and it only comes from understanding the game well enough to see what the tool is doing.
What the shortcut skips#
An agent gives you the outcome. Understanding comes from the process, and the process is the part you skip.
Navigation is a familiar case. London taxi drivers spend years memorizing the city's streets before they get a license. The rest of us use GPS and arrive just as reliably. A small 2020 study found that people who relied more on GPS had worse spatial memory, and that heavier use over the following three years went along with a steeper decline. GPS works fine, as long as it is right and you never need to find your own way.
Aviation learned the same lesson with higher stakes. Autopilots fly most of a modern flight better than people do. In 2009, Air France 447 lost reliable airspeed readings over the Atlantic, the autopilot disconnected, and the crew had to fly by hand at cruise altitude, something almost nobody practices. They stalled the aircraft into the ocean. The investigators found that neither co-pilot had been trained to hand-fly the aircraft at high altitude. In 2013 the FAA issued a safety alert encouraging airlines to give pilots more manual flying, after its data showed an increase in manual handling errors.
Coding agents hand control back all the time: when the feature doesn't fit the structure, when the bug sits between two systems, when the generated fix works but goes around the framework. In Sure thing, here's your solution I described an agent-written change of about a thousand lines that should have been ten. Seeing the ten-line version required knowing the framework well, and nothing in the agent's output pointed at it. Refactoring in the Age of LLMs covers why that mental model matters for architecture. This piece is about how you build one.
It used to be harder to skip#
I learned this job from books. Then from forums, where you posted a question and waited a day for someone to tell you it had already been answered. Then, from the late 2000s, from Stack Overflow, which felt like magic. People joke about the copy-paste era, and plenty of code was pasted without being understood. But even then you had to put the problem into words, search for it, read three answers that almost fit, work out which one applied to your case and adapt it. Every step taught you something about the problem, the language or the codebase, whether you wanted it to or not.
Now you can paste a screenshot, type "why is it red, make it green," and go back to scrolling your phone. It works. The test goes green, and you have learned nothing about why it was red.
That pull is strong, and it is strongest exactly when something gets hard, which is the moment the learning would have happened. Every hard problem now comes with a button that makes it go away, and not pressing it takes a decision, every single time.
The environment doesn't help. Ticket pressure has always been there. Some companies now also track how much AI their engineers use and read a high number as productivity. Under those conditions the shortcut becomes the expected path, and the long way can look like slacking.
Are you mad about this?#
The honest question to ask yourself is whether you care about getting better at this. Not as a career strategy. Whether problems pull at you when nobody is asking you to solve them.
If the answer is no, that is a legitimate choice. Plenty of good engineers do solid work, go home and live their lives, and nobody owes an employer unpaid overtime. But be clear about what the choice means now. If an agent does the parts you never learned, you are competing with the people who did learn them, and they have the same agent.
If the answer is yes, you are in an unusual position. Most people never get paid to do something they would think about anyway. If that describes you, the hours you already spend at work can teach you far more than they probably do now.
Use the job#
Work gives you mat time you can't get on your own: real constraints, real deadlines, a codebase you didn't write, other people's decisions to work around, and consequences when you get it wrong. Side projects rarely provide any of that. The job is already paying you to train, if you treat it that way.
With agents in the loop, that takes some intent. Before you prompt, sketch how you would solve it, then compare. Where the agent's version is better, find out why. Where yours is better, you have learned something about the agent. Every so often, build something by hand, preferably the part everyone treats as magic: the auth flow, the query builder, the build pipeline. Read the diffs that touch structure and ask why a change needed twelve files. When a model reviews your code, ask again and see whether the answer holds. If it changes, decide which version is right, and make sure you can say why.
Practice on purpose#
None of this means working without AI. It means deciding where the speed goes. Use agents freely for work you already understand: the boilerplate, the fifth CRUD endpoint, the migration you have done a dozen times. Slow down where you don't understand yet, because that is where the mat time is.
When you get stuck, give yourself a fixed amount of time before you ask, twenty minutes or an hour. Most of what a problem can teach you happens in that window. When you do ask, write the question the way you would have written it for Stack Overflow: what you expected, what happened, what you already tried. Stating the problem precisely is half of solving it, and it is the half the agent otherwise does for you.
Ask for explanations rather than fixes. "Why is this red?" teaches you something, and "make it green" doesn't. When the agent proposes a fix, make sure you can explain why it works before you accept it. If you can't, that is the thing to learn today. Read the source of the libraries you depend on, at least once. Reproduce a bug by hand before you let anything fix it.
If your company measures how much AI you use, use it where it saves time on things you already know, and protect the hours where you are learning. Throughput is what the company pays for. What you understood is what you take with you when you leave.
And when the agent hands you a thousand working lines, be the person who knows it should have been ten.
The long game#
Titles, frameworks and employers change on their own schedule. What carries over is the model in your head: how systems fail, where complexity actually comes from, what the ten-line version looks like. It compounds over every year you do this work, and nobody can take it with them when they reorganize.
It also decides how useful AI is to you. An engineer with a good model uses agents to move faster through work they already understand, and catches them when they go wrong. An engineer without one can only accept what comes back. They have the same tools, and only the first one is getting better at the job.
The person using AI who replaces somebody is the one who has that model. It gets built the same way it does in jiu-jitsu, through mat time, against problems that resist. Nobody can do the rolls for you.
