The Plateau Trap

I recently wrote about AI fatigue, arguing that what engineers are experiencing isn’t a chronic condition but training soreness. Push through it, adapt, come out stronger.

That’s all good and sound, but there’s more to that story, and it’s quickly becoming more obvious. The real risk facing engineering teams right now isn’t burnout. It’s plateauing.

The New Split

Almost every senior engineer uses AI now. Copilot, Claude, Cursor, Codex, you name it. That part is settled. If you’re leading an engineering org, you probably see broad adoption numbers and feel good about it.

You shouldn’t.

The adoption number is meaningless. What matters is the split happening underneath it. Your team is quietly dividing into two groups. There are the engineers who got a productivity bump and settled in, and engineers who keep pushing every single week. New workflows, new agent configurations, new ways to decompose problems for AI to handle.

Both groups show up in your dashboards as “AI adopters.” But one is on a progressive training program. The other stopped at the first weight that felt comfortable.

Six months ago, the gap between these two groups was barely visible. Now it’s obvious to anyone paying attention. In another six months, it will be structural.

What Plateau Actually Looks Like

The plateaued engineer isn’t doing anything wrong in the traditional sense. They’re competent. They ship. They use their agent for simple jobs and clean up after it. They got maybe a 20-30% productivity lift and called it done.

The problem is that the engineer next to them didn’t stop there. That engineer is now running multi-agent workflows, improving verification loops, decomposing entire features into AI-executable chunks, reviewing at the architectural level instead of line-by-line, and shipping at 2-3x their previous pace. Not because they’re more talented. Because they kept training while everyone else took a rest day that turned into a rest quarter.

This isn’t about AI enthusiasm or being an early adopter. The early adoption phase is over. This is about continuous adaptation versus one-time adjustment. And the compounding difference between those two approaches is becoming impossible to ignore.

The Competitive Pressure Is Real and Accelerating

If your teams had the luxury of adapting on their own timeline, the plateau problem would be a performance management issue. Annoying, but manageable.

But if you look at the broader situation in the software industry, chances are you don’t have that luxury.

The software industry, by and large, was created to help humans with digital work: helping support agents see inbound cases, tracking responses to customers, managing workflows. Now AI agents are displacing the whole workflow, and with it disrupting the underlying SaaS platforms. On top of that, with AI becoming more capable by the day, your customers are starting to ask a question: “Do we still need to buy this, or can we build it ourselves now?” AI has started to shrink the barrier between “buy” and “build” for an expanding set of use cases. The stickiness that used to protect your revenue is weakening every quarter.

Your plateaued engineers are operating at a pace calibrated for a competitive environment that no longer exists.

The Quote That Reframed Everything For Me

I’ve heard it more than once now, from product managers who rolled up their sleeves and vibe coded features, from engineering leaders who redesigned failing architectures, at different companies, in different contexts:

“It was easier for me to iterate on this with my agents, than with that engineer.”

The first time I heard it, I thought it was hyperbole. The third time, I realized it was a leading indicator.

The way I see it, there are engineers who will thrive in this new world and be “multipliers” of AI capabilities. To do that, they need to be strong in two areas, both of which can be self-developed with enough intrinsic motivation and intellectual curiosity:

• They operate “on the same wave” as their stakeholders (PMs, eng managers, etc). They get what good looks like, so you don’t have to overexplain things to them. Because if they produce the same number of misunderstandings as your coding agent, the agent will always win that battle. It’s available instantly, 24/7, and tireless.
• They constantly improve their AI setups, so when you hand something to them, you know it’s going to be done not just well (see the point above), but also fast enough to keep up with the new market tempo.

Why This Is a Leadership Problem, Not an Individual One

It’s tempting to frame this as an individual engineer’s responsibility. “Keep up or get left behind.” But if you lead an engineering org, that framing lets you off the hook.

Your plateaued engineers didn’t plateau in a vacuum. They plateaued because nothing in their environment pushed them past the initial adjustment. They hit a reasonable-looking productivity gain, nobody challenged them to go further, and inertia did the rest.

The engineers who kept pushing? Most of them are self-motivated. They’d push regardless. But you can’t staff an engineering org entirely with self-motivated frontier-seekers. The question for leaders is: how do you move the middle?

This is a change management problem, and one of my favorite frameworks for it comes from the Heath brothers’ book Switch. The short version: you need to give people a clear direction, make them feel why it matters, and reshape the environment so the new behavior is the path of least resistance. Applied to engineering teams, that looks like:

Find your bright spots and make them visible. Identify the engineers who’ve pushed furthest in their AI workflows and have them demo to the team regularly. Not training sessions. Live walkthroughs of real work. When the middle of your team sees the delta between their workflow and the top adapter’s workflow, it creates productive discomfort that no mandate can match.

• Shrink the change. “Adopt AI” is too abstract to act on. This sprint, nail the e2e agentic testing, next sprint roll it out across the whole org, and so on. Specific manageable steps beat ambitious transformation programs every time, and small wins matter.
• Reshape the defaults. Codify the verification process in AI skills, and make sure those are deployed across your team and across all their agents. Define your workflows and use the tooling that supports that. Make the new way of working the path of least resistance, so people drift toward it instead of having to fight their way there.

The Window Is Closing

Here’s the part that makes this urgent rather than merely important.

Right now, the adaptation gap is a performance differential. Your plateaued engineers are slower than your adapted ones, but they’re still productive. They still contribute. You can carry them.

That window is closing. As AI capabilities accelerate and competitive pressure compounds, the minimum viable pace of engineering work is rising. The “good enough” engineer of today isn’t guaranteed to be good enough next quarter. Not because they got worse, but because the floor moved up.

The organizations that figure out how to move their entire teams up the adaptation curve, not just the early adopters, will have a compounding structural advantage. The ones that don’t will find themselves staffed for a pace of competition that no longer exists.

Every engineering leader I talk to understands this intellectually. Very few have changed how they run their teams in response. The gap between understanding and action is its own kind of plateau.

There Is No Comfortable Pace

In the AI fatigue piece, I argued that soreness is the proof that training is working. That’s still true. But the follow-up truth is harder: the weight keeps going up.

In a normal gym, you can pick a comfortable weight and maintain it forever. Nobody adds plates to your bar without asking. In the current software landscape, every new model release, every new agent capability, every new workflow that someone figures out and shares, the bar moves. Stand still and the weight eventually pins you.

There’s no comfortable space in the software industry right now. Not for individual engineers, not for the teams they work on, not for the companies those teams build. The only safe position is continuous motion. And the only question that matters for engineering leaders is whether your whole team is moving, or just the ones who would have moved anyway.