AI took the busywork. What is left is the actual engineering.

Somewhere in the last two years, the day to day work on my team quietly changed shape, and it took me a while to notice it had happened. Engineers were still opening pull requests, still shipping features, still in standup every morning. But the actual content of what they were spending their hours on had shifted underneath all of that, and I only really saw it clearly when I started reviewing AI generated code as a normal part of a PR instead of an exception worth commenting on.

The honest version of what changed is this: AI took the busywork, and it turns out a lot of what we called engineering was busywork.

What actually got automated

Boilerplate CRUD handlers. Migration scaffolding. Glue code between a new API and an existing service. Writing the first draft of a test suite for a function that already exists. Translating a config file from one format to another. Fixing the kind of bug where the error message already tells you the exact line and the exact fix. None of that was ever the hard part of the job, it was just the part that ate the most hours, because someone still had to type it out and get the syntax right.

That is the layer AI is actually good at, and it is good at it in a way that is no longer debatable inside my team. The debate ended somewhere around the point where junior engineers started shipping in a day what used to take three, and the code review comments stayed the same size.

What is left is the job engineering was supposed to be

Once that bottom layer stops eating your morning, what is left is the part that was always the actual job description, even when nobody had time to do much of it: deciding how a system should be shaped before a line of it exists, figuring out where the data actually needs to live and why, choosing which trade-off a feature is going to eat now so it does not eat something worse in six months, and reading a diff not for syntax but for whether it is solving the right problem.

That is architecture and flow, not typing speed. And it turns out that work was never something AI could do for you, because it requires knowing things about your specific system, your specific users, and your specific failure history that live nowhere in a training set. If anything, the tools made that gap more visible instead of less, because they took away the excuse of being too busy writing CRUD handlers to think about it properly.

This is genuinely good news, if the job was already yours

For anyone who was already thinking in systems, this has been a clear net gain. I can sketch the shape of a service, describe the flow out loud, and have the mechanical implementation come back fast enough that I am reviewing and steering instead of typing. That loop is closer to what I actually enjoy about this work than the version of the job I had ten years ago, where half the day disappeared into repetitive PHP CRUD before I got anywhere near a real decision.

Managing a team through this has mostly meant protecting that trade. The win is not “ship more code,” it is “spend the hours you get back on the parts of the job a junior engineer could not have done for you anyway.”

Where it actually hurts

The people I have seen struggle are not struggling because AI is smarter than them at architecture. They are struggling because their sense of what an engineer does was built entirely on the layer that just got automated. If your confidence came from typing fast, from remembering syntax, from being the person who could bang out a form handler without looking anything up, that specific skill just stopped being scarce, and it is a genuinely uncomfortable thing to watch happen to a skill you spent years building.

There is a second, quieter version of this that worries me more as a manager: junior engineers who let AI write the implementation without ever building the muscle to understand what it wrote. They ship fast, the code works, and then eighteen months later they cannot debug a production incident, because they never built the mental model of the system that comes from having struggled through writing it by hand at least once. Speed at the bottom layer is only a gift if you already know what the bottom layer is supposed to do. If you skip building that judgment, AI is not lifting you up, it is just hiding the gap for a while.

Managing it is the actual skill now

The way I have started treating this on my team is simple: AI output gets reviewed exactly like a junior engineer’s pull request, every time, no exceptions, because it is capable of being confidently wrong in ways that read as correct at a glance. And I still make people explain the design of anything nontrivial before they let a tool fill in the implementation, because if you cannot describe the shape of what you are building, you are not actually the one architecting it, you are just approving whatever came back first.

None of that is a reason to slow down adoption. It is the actual job now, the same way code review was always the job even before AI wrote a single line of the diff. The engineers doing well right now are not the ones fighting the tools or the ones blindly accepting everything the tools produce. They are the ones who got clearer about what the job actually was the moment the part that was not the job got taken off their plate.