What happens to developers who don't adapt to AI

Developers use AI at very different levels. Contracting across different teams lets me see the whole range, and the gap in what people ship is real. The group I worry about most is the one in the middle, using AI a little without changing how they work.

Four levels of adoption

I see four levels:

Refusal. These developers think AI-generated code is poor, or that relying on it will weaken their skills. The risks are real, but the gap between them and everyone else keeps growing.
Dabbling. They have Copilot installed and use it for boilerplate and autocomplete. Their workflow is the same as before.
Integrated. They use AI for writing, debugging, reviewing, testing and research. They have rules files and workflows, and they know when AI helps and when it gets in the way.
Multiplied. They build systems that use AI on their own: custom agents, automated review and software factories.

Most developers are stuck between dabbling and integrated, and I think that is a worse place than refusal.

Why half-adoption is the risky place

Dabblers spend almost as much time fighting the AI as they would spend writing the code. They generate code, check all of it because they do not trust it, fix it and repeat. The gain is small, and they have added a new kind of mental load.

The problem is trust. A dabbler has not used AI enough to know when it is reliable, so they check everything. An integrated developer has learned when to accept output, when to tweak it and when to throw it away.

Which skills lose value

Routine implementation. A standard REST endpoint, a CRUD controller or a utility function is now a commodity task. If your pitch is "I can write this quickly", that pitch is weaker.
Boilerplate. Scaffolding, config files and repeated patterns are things AI handles well.
Writing every test case by hand. AI can draft a test suite from a spec. Deciding where the test boundaries go still matters.
Simple debugging. AI is good at spotting null checks, type mismatches and common logic errors. Finding out why a distributed system is failing is still hard.
Memorising framework APIs. Knowing every method signature matters less. Knowing which framework to use, and why, still matters.

Which skills gain value

System design. AI can build most things you describe clearly. Knowing what to describe is the bottleneck.
Breaking work into clear pieces. AI works best on narrow, well-defined tasks. Turning a fuzzy problem into precise sub-problems makes it far more useful.
Critical review. Generated code looks right and is sometimes subtly wrong. Spotting the three lines that will cause an incident is a rare skill.
Verification. When agents produce changes quickly, confirming they are correct becomes the slow part. Tests, specs and automated checks matter more.
Communication. The people who explain trade-offs and write clear specifications decide what AI builds.
Workflow design. Better prompt wording gives small gains. Structuring the work so AI can contribute gives large ones.
CLI and automation. Work done by clicking through a GUI is hard to hand to an agent. Command-line work is easy to script and delegate.

Fiona Fung, who leads engineering for Claude Code at Anthropic, described two profiles she hires for in her talk Running an AI-native engineering org. The first is a creative builder with product sense, who can prototype quickly and decide what is worth building. The second is someone with deep knowledge of the system who checks what the agents produce. Neither profile is "writes the most code".

Mike Spitz, who runs engineering at PFF, said in Agents Don't Do Standups that the engineers who did well with agents were the curious ones. When they hit something unfamiliar, they worked out how it was built. Engineers who needed a step-by-step spec struggled.

The translation work is going

Ajey Gore's essay The anatomy of an AI-native org explains which work is disappearing. Software companies ran on a chain: business decided why, product decided what, and engineering decided how. A lot of jobs sat between those steps, turning business intent into a spec, a spec into tickets and tickets into pull requests. Gore calls this the translation layer, and it is the kind of work models are now good at.

That changes where the safe ground is. If most of your job is turning one well-defined input into a well-defined output, an agent will do that faster. The work agents cannot do is defining what correct means, building the checks that make it safe to let agents work, and taking responsibility for the result. Move towards the why and the what without giving up the how. The engineers who keep the how are the ones who can still go deep when something hard breaks.

The same applies to managers. A lot of management exists to coordinate that translation: running the standup, unblocking tickets and writing status updates. Gore describes two reactions. Some managers defend the meetings because the meetings make the role visible. Others pick up an agent and get back into the work.

Mixed teams

Teams with mixed adoption levels have friction. The integrated developer ships fast and expects reviews to keep up. The dabbler feels pressure and may dig in. The refuser becomes a bottleneck the team routes around.

I've seen a team where the senior engineer refusing AI became the blocker, while juniors on the same team shipped faster. Seniority no longer maps simply to output.

The organisations that handle this well make AI easy to use, give guidance and let results speak. The ones that handle it badly either ban it, which caps what the team can do, or mandate it without support, which breeds resentment.

Where to start

If you feel left behind, I'd suggest this.

Pick one task. Choose one part of your work, such as tests, debugging or research, and use AI for it for a week. Then look honestly at where it helped and where it fell short.
Build trust by using it. You cannot learn when to trust AI without using it. Its mistakes become predictable: invented APIs, config drift and confident wrong answers.
Spend effort on what AI does badly. System design, architecture and communication stay valuable however good AI gets at writing code.
Be honest about your level. If you are dabbling, say so. The path from there to integrated is well documented.

Every developer using AI well now was refusing or dabbling at some point. The mistake that is hard to undo is deciding the change does not apply to you.