What 906 Engineers Just Told Us About AI Coding in 2026

Every year, the Pragmatic Engineer survey lands and I'm genuinely interested because 906 working engineers describing what they actually use is a useful counterweight to the noise around AI tooling. Vendor demos look great. Investor decks look great. What people actually fire up at 9 AM on a Tuesday is the data that matters.

The 2026 edition published on 3 March, and it confirms a few things I suspected, contradicts one assumption I hear often, and surfaces a pattern about how organisations adopt AI tools that I think is the most important finding in the whole report.

The headline most people will quote

Claude Code went from zero to the most-used AI coding tool in eight months.

That's the line everyone will lift, and it's accurate. Claude Code launched as a research preview in February 2025 and became generally available in May 2025. By February 2026, when the survey closed, it was the #1 tool by adoption and the most-loved tool by a wide margin. 46% of respondents named it as their favourite, with Cursor at 19% and GitHub Copilot at 9%.

For context, GitHub Copilot took years to reach the kind of mindshare Claude Code achieved in eight months. That's not a slow burn. That's a category being redrawn while you're still trying to figure out what shape it used to be.

But the headline obscures the more interesting story.

The finding I keep coming back to

Tool rankings will get most of the attention. The finding that actually changes how I work with teams sits a few pages later.

Engineers who actively use AI agents are nearly twice as likely to be excited about AI as those who do not. 61% of agent users describe themselves as excited about AI overall. Only 36% of non-agent users do. Non-users are twice as likely to be sceptical (22% vs 11%).

This is not a tautology - "of course people who use AI like AI." The interesting bit is the direction. Hands-on use seems to convert sceptics far more reliably than reading about agents, watching demos, or sitting through another all-hands. Use first, opinion second. Almost nothing else moves the needle the same way.

That has quietly changed how I advise leaders on AI adoption.

The instinct in most organisations is to put effort into the resistant. Bring the doubters into pilots. Build the business case for the people who keep raising the same six objections. Spend the all-hands time addressing their concerns. The logic seems sound: if we can convince the sceptics, adoption will move.

The data says it does not work that way. Adoption moves when people use the thing. The sceptics will not use the thing until someone they trust has done it first and reported back. So most adoption programmes are running the wrong order of operations.

Wer nicht probiert, der kritisiert. That dynamic does not shift because you ran another quarter of vision presentations.

The pattern I now recommend is straightforward. Keep the door open for everyone, psychologically, technically, organisationally. Nobody gets excluded. But invest 80% of your time, your access, your unblocking energy, and your visible attention with the people who are already leaning forward. The ones running tools in their own time. The ones asking sharp questions. The ones who have already tried, formed an opinion, and want to go deeper. They become your proof. They build the internal playbook. They make the next wave of adoption almost effortless, because they have already done the boring work of figuring out what actually helps and what just looks impressive.

The sceptics are welcome to join later. Many of them will, once the evidence is in front of them and a peer they trust says "this works." That is the order: do, prove, invite. Not invite, convince, hope they do.

For a leader of a large engineering organisation, this is also where most adoption budgets get burned. Internal AI strategy decks, change management workshops, and AI-curious-but-not-yet-trying town halls absorb enormous resource. The energy would compound faster if it went into removing friction for the 20% who are already moving.

The door stays open. The energy moves.

The enterprise pattern is another interesting story

Here is where the data gets interesting for Enterprises.

Claude Code adoption at the smallest companies sits at 75%. At the largest companies (10'000+ employees), it drops to roughly 30%. Meanwhile, GitHub Copilot rises from 35% at small companies to 56% at the largest ones.

You could read this as "different tools suit different scales." That would be wrong, I believe. The respondents themselves describe the pattern differently. Engineers at large companies talk about approval cycles, procurement delays, and SSO requirements. Engineers at small companies talk about which tool worked best last week. The tool choice at large firms is not driven by engineering preference. It is driven by what procurement and compliance could clear in the available timeframe.

Microsoft's enterprise sales motion and Copilot's bundling with existing GitHub Enterprise contracts make Copilot the path of least resistance. The newer entrants face a procurement gauntlet that takes months. By the time approval lands, the market might have moved again.

I see this from the inside. I currently work with GitHub Copilot inside a large Swiss insurance company. It is genuinely not bad. But it does not let me go full throttle in the way I can use Claude Code. The interesting twist: Copilot has now integrated Claude Code and Codex as previews. Today they do not work especially well. Soon they probably will. The day that lands, Copilot quietly becomes a very strong enterprise option, because the same procurement contract that took a year to clear now ships you the agents the rest of the market has been using for twelve months. That is a real structural advantage that does not show up in any product comparison.

But that is not really the point.

A tool can enable new things. The much bigger lever is the capacity to rethink how the work itself is done. The tool is the easy part. The operating model around it is the harder part, and the part that actually decides whether the investment pays back.

Once you have an agent inside the workflow, the interesting questions are not "is this agent better than that one." They are operational. How do we actually work with these tools? What does the human do, and what does the machine do? Where does the human stay in the loop, and where does the human deliberately step out of the way? How do we keep quality high when the volume of generated code goes up by a factor of three? How do we make sure, especially in regulated enterprise contexts, that what an agent produced is traceable, that we can answer auditors, that compliance documentation stays current rather than retrofitted six months later?

These are not tooling questions. They are process and operating-model questions. And they are where most organisations are still improvising.

The combination is what matters. A capable agent, paired with a clear human/machine division of labour, paired with a way to verify quality continuously, paired with traceability that holds up to scrutiny. Get one of those wrong and the other three lose most of their value. A best-in-class agent attached to a fuzzy process produces faster mediocrity. A modest agent attached to a sharp process produces less, but you can trust what comes out and you can explain it.

If you run a large engineering organisation, this is what I would take to your next leadership offsite. Not "which tool do we standardise on." But: what does professional engineering look like when half the code is drafted by an agent, and have we actually designed for that, or are we still treating the tool as a faster typist?

AI is now infrastructure

Some quick numbers that I think matter more in aggregate than individually:

• 95% of respondents use AI tools weekly or more
• 2.1% do not use AI at all
• 75% use AI for at least half their engineering work
• 56% do 70% or more of their engineering work with AI

The "we are still figuring out if this AI thing is real" era is over. It ended sometime in late 2025 and most people just did not notice. AI tooling for software engineering is now baseline infrastructure, in the same category as version control, CI, and a decent IDE. The question is no longer whether to adopt. The question is how to adopt well.

That last question is much harder than the first.

Where this leaves us

I will be honest about what I take from this report. The tools are converging on a single pattern: an agent that can read your repository, propose changes, run tests, and iterate. Claude Code, Cursor's agent mode, Codex, Gemini CLI, Github Copilot - they are all variants of the same idea executed with different degrees of polish.

What they do not converge on is the process the agent follows.

Most agents will happily write code without ever reading the requirement that triggered the work. They will happily skip tests if the prompt does not insist. They will happily merge without compliance documentation, security review, or a changelog entry. The agent is fast. Whether the agent is professional is a separate question entirely.

This is why I have been building Shipwright. It is not another coding tool, the survey already shows we have enough of those. It is an open-source SDLC framework that runs on top of Claude Code and gives the agent a process to follow. Every line of code traces back to a requirement. Compliance documentation stays current with every build.

The 2026 survey tells me the tool layer is mostly solved. The process layer is where the next two years of work will happen.

→ Explore Shipwright

What I would watch for in 2027

Two things I will be tracking through the rest of this year.

First, whether adoption patterns inside organisations shift. Whether the 80/20 logic catches on, or whether companies keep pouring energy into convincing the sceptical half while the engaged half quietly compounds on its own. The signal will be in the data the next survey collects: does the agent-versus-no-agent gap narrow because adoption broadens, or does it widen because the engaged minority keeps pulling further ahead and the rest stay where they are.

Second, whether process maturity catches up to tool capability. Today most organisations have agents that are far more capable than the operating model around them. The interesting question for 2027 is whether teams start treating the human/machine division of labour, quality verification, and traceability as a deliberate design problem, or whether they keep retrofitting those things after the fact. The organisations that figure this out early will look very different in a year from the ones that do not.

A year ago, Claude Code had just gone generally available. By the time of the survey it was the most-used tool in the category. That pace is worth sitting with. Whatever you think the AI coding tooling landscape will look like next March, you are probably wrong, and the safest bet is to make sure your organisation can absorb whichever shape the answer takes.

 

---

Sources:

• AI Tooling for Software Engineers in 2026 - The Pragmatic Engineer - 3 March 2026 - https://newsletter.pragmaticengineer.com/p/ai-tooling-2026
• Claude Code release timeline - Anthropic - February and May 2025 - https://www.anthropic.com/news/claude-code
• Pragmatic Engineer Survey: 95% of Devs Use AI Weekly - AI:PRODUCTIVITY - March 2026 - https://aiproductivity.ai/news/pragmatic-engineer-survey-ai-tooling-2026/
• The Evolution of Claude Code in 2025 - LM Po (Medium) - 2025 - https://medium.com/@lmpo/the-evolution-of-claude-code-in-2025-a7355dcb7f70