The promise was simple: AI writes the code, so the job gets lighter. The first half came true.
The second half did not. The job changed into a different one, and it is hard to call it lighter.
Three engineers whose jobs changed
I talked to three engineers from my network about how they work with AI now, and what has changed for them. This is what they told me.
The Senior Elixir Engineer who never opens an editor
One of them just started a new job as a Senior Elixir Engineer. He does not have strong Elixir experience. He has several years of Ruby and full-stack work behind him, and deep knowledge of the specific programming language was not required.
What he is good at is something else. He can handle difficult environments and a lot of input, and he understands a technical system and its edge cases very well.
His day has no coding in it. Zero. He does not open an IDE, an editor, or Cursor. He works in the console and in GitHub review. AI writes the code, AI reviews it, AI runs the security checks, and then he reviews the result. It is a lot of reviewing.
He tells the AI what to do, and while it works he moves on to another of the five projects he is responsible for. His managers expect exactly that: switching context several times a day, sometimes several times an hour, keeping the AI moving on each project and signing off its work. There is no standup. Everything runs asynchronously, and if a standup does get scheduled, something has gone badly off track.
Sometimes the PM builds a feature with AI first and sends it over finished. The engineers then decide whether it can be taken as it is or has to be reimplemented. Making that call means understanding three things: the request, the AI's code, and the technical environment it has to live in.
He calls all of this exhausting, but doable. It is also why he does not want more responsibility. A team lead role? No, thank you.
He is well paid, and so far he can handle it. But he looks back on the programming times, on diving deep into a language, and thinks they were nice.
The Senior Engineer whose boss sends him finished features
Another has been an engineer for 15 years. He is a very good Java developer who knows clean code inside out and is great at software architecture, and he can get the AI to write code almost the way he would.
His boss suddenly started sending him AI-generated code: whole features, already written, for him to review and integrate. The code did not follow the infrastructure or the coding guidelines, and it did not fit the system. He was frustrated when he told me about it.
The Security Engineer whose reviews the AI now does
A Security Engineer who reviews browser add-ons, and allows or rejects them, has watched his job change in the same direction. He used to review the add-on code himself. Now the AI does that. Finding issues has become much easier, and the AI keeps getting better at it. The attackers use AI too, and their obfuscation keeps getting better as well. He now relies on the AI to find the security issues in a lot of code, and he is losing some of his control over how a breach gets caught. He steers the AI and documents the result afterwards, and the AI does part of the documenting too.
What stays with him, for now, is telling the creators why an add-on was rejected and what needs to change, and the organizational work around the add-on infrastructure. The role is now closer to an administrator's. The AI does the geeky technical work.
He also checks the AI for mistakes. He does not expect to become unnecessary. He expects to become more of a documenter.
Nobody is short of code. The decision is what's left.
Put the three next to each other. Code comes from all sides: from the AI, from the PM, from the boss. The PM and the boss can deliver code that works now, so they think they can contribute. What each of these engineers is still there for is the decision about it: take it or rebuild it, sign it off or send it back, does it fit the system or not.
The stress comes from what sits around those decisions. The work used to run in a line: feature description, coding, review, done. It no longer does. There is much more communication in between now, with stakeholders, with the PM or PO, with other developers, and with the AI agents. Each of those is a context switch.
Signing off code you did not write, across five projects, also means five times the features to work on, five systems to hold in your head, and being the last person who can say no. And when the code comes from your boss or your PM, saying no stops being a review comment and becomes a conversation.
| The AI can | The engineer still owns |
|---|---|
| Write the code, review it, and run the security checks | Signing it off, across five projects |
| Build the PM's feature before an engineer sees it | Deciding whether to take it as it is or reimplement it |
| Write a whole feature for the boss | Saying whether it fits the infrastructure and the coding guidelines |
| Review the add-on and find the issues | Telling the creator why it was rejected and what needs to change |
The right-hand column is what we call skills beyond code. It is also a fair description of what the Elixir engineer brings to the job in place of deep Elixir knowledge. My co-founder Pierluigi Meloni puts it this way:
“Now that almost anyone can code with AI, being senior means the skills beyond code. Not having them is the reason the job feels overwhelming, and why the next job or promotion never comes.”
Three conversations are not a survey, and plenty of teams do not work like this yet. But all three point the same way: coding is becoming the baseline, and the job is what happens around it.
The skills beyond code are more necessary now, whether you like it or not
All three examples show it. The job gets easier when you know how to handle them. If you do not, it will be rough times.
With five projects, it starts with understanding each of them in more depth, so you can judge AI output fast. Otherwise you review hundreds of lines of the wrong thing. It also means knowing how to ask the right questions and, if needed, pushing back at the start of a feature discussion.
The rest is three things: defending against shortcuts, saying no to scope creep without sounding unreasonable, and giving constructive feedback. Then you can own the thing end to end.
The shortcuts to defend against are especially the ones that do not follow technical best practices, or that violate the internals of the system. The boss's feature is that kind of shortcut. It goes around the system, and it was built without the engineer who has to integrate it. When he told me about it, I said he would probably have to seek out the conversation with his boss, and that the boss needs to hear clearly that reviewing and adapting this code takes effort. “This doesn't follow our guidelines” is true, and it leaves the boss with nothing to decide. A reply that moves things forward names the cost and offers the choice. Something like:
“This shows me what you want, and that helps. It doesn't follow our infrastructure setup or our coding guidelines, so I can't merge it as it is. I can rebuild it on our stack in about three days, or we cut it down to the part that already fits. Which matters more to you? And next time, send me the idea before the code. I can tell you up front what fits.”
The prototype gets used for what it is good at, a precise picture of what the boss wants, and the system stays one system. The last two sentences of the reply ask for something more: being included from the start, before the code exists. The Elixir engineer is in the same spot when his PM sends over a finished feature.
In the Java engineer's case, company-wide rules for coding with AI made the code review better. The expectations about what happens with the code, and how far the scope goes, still need more communication between him and his boss. Maybe he does not want to seek out that conversation. Then he has to keep living with the pain.
Scope creep now starts from the same place. From the PM's perspective, trying things is cheap now, because adding a “simple” thing costs almost no coding time anymore. Engineers are more or less expected to deal with that. But when everyone can produce working code, you have to stay in the loop, or your technical environment gets out of your control.
The coding really is cheap. Someone still has to review it, sign it off, and own it when it breaks, and that someone is the engineer. The no that does not sound unreasonable is a question about that cost:
“Coding it is quick. Reviewing it and running it is not. What moves if I take this on?”
It is the same question we recommend for any new work that arrives. It matters more now that the coding estimate no longer slows anyone down.
Constructive feedback is now a large part of the security engineer's job. The AI reviews the add-on and produces the findings. He tells the creator why it was rejected and what needs to change. Forwarding the list of findings would not do that. His part is deciding which finding blocks the add-on, and saying it so the creator can act on it. Something like:
“Your add-on is rejected for one reason: it requests access to all sites but only uses it on two. Narrow the permission to those two and resubmit. The other four findings are suggestions, not blockers.”
The requirements are not going back
I do not expect these requirements to reverse. Coding will sit with the AI. Making the AI better is always the fun part, and all three are getting better at it and getting more automated results out of it, even the one who calls his days exhausting. But the part that is not fun grows in proportion. Each time they improve it, they spend less of their own time on coding and the technical work, and everything else counts more.
All three are still highly paid. But the companies they work for have seen the shift, and they know the good salary is no longer for the coding. The Elixir engineer's company hired him as a senior without strong Elixir experience. You can argue about whether that is a good thing. It is what is happening.
These are the skills we train at Utterskills: communication, ownership, and judgment. The Senior Shortcut teaches them on purpose, so you don't have to pick them up by accident.