Back to blog
Marcin Ostrowski  · Jun 11, 2026

Why your team's AI coding adoption didn't stick

Ninety percent of firms told NBER that AI changed nothing for them. The tools work; what fails is treating an organizational change as a tooling rollout.

There’s a number from February that should be framed on the wall of every AI vendor: in an NBER survey of 6,000 executives across the US, UK, Germany and Australia, nearly 90% of firms said AI has had no impact on their productivity or employment in three years. Two thirds of them use it. Average usage: about an hour and a half per week. That covers all AI use, not just coding, but anyone who has watched an engineering org “adopt AI” will recognize the shape. Economists are dusting off Solow’s 1987 line about the computer age being visible everywhere except the productivity statistics.

Meanwhile I run a product where agents have shipped to production every day since December 2025, and I work with teams trying to get there. So I don’t read that 90% as proof the tools don’t work. I read it as a list of rollouts that died, and the autopsies look alike. If your team bought the licenses, ran the pilot, sat through the demos, and delivery looks the same as last year, one of these patterns is probably yours.

The rollout was a tooling decision

Somebody senior decided the company needs AI, procurement bought seats for everyone, and an email went out. That was the whole plan. Usage went up and nothing else changed, which matches the macro data: ManpowerGroup measured regular AI use rising 13% in 2025 while confidence in its utility fell 18%. More people using a thing they trust less every month. That’s not adoption, that’s compliance.

A tool purchase changes what’s installed on laptops. Work still moves through the team the same way it did before: tasks get specified loosely, output gets verified by hope, and review drowns in the extra volume. No license tier fixes any of that.

Every developer reinvented the workflow alone

Hand ten developers an agent with no shared setup and you get ten private workflows: one is flying, three are quietly fighting the tool, six tried it twice and went back to their editor. The single most important thing that changed this for me was making conventions enforceable, so the agent follows the team’s rules instead of each developer’s mood. Rules live in the repo, get loaded before the agent writes, and get checked after. Without that, your “AI adoption” is ten separate experiments, and you’ll get the median of ten experiments.

There’s a tool-sprawl version of this failure too. BCG found that workers’ self-reported productivity rises with up to three AI tools and falls off a cliff after four. Teams that never converged on one workflow end up with everyone juggling several, each half-learned.

The first incident killed the trust

An agent hallucinates a method, the deploy breaks on a Friday, and from that day every AI-touched PR gets triple-checked by humans who already had no time. Whatever speed the tool added, the distrust tax now eats. This is where that 18% confidence drop comes from, and it’s rational. Trust built on “the demo looked great” deserves to die at the first incident.

Trust that survives incidents is built on verification the team can see: checks that fail builds loudly, and rollback that doesn’t wait for a human. I’ve described our setup in How do you know the software is working? The specific gates matter less than where the confidence comes from. Machinery, not vibes, because vibes don’t survive contact with the first NoMethodError in production.

Nobody restructured review

The teams that do get volume out of agents hit the next wall: humans can’t read that much code. Review queues balloon, seniors burn out, and the org quietly throttles back to the old pace. The fix is unbundling review, so machines settle hygiene and conventions before any human looks, and human judgment moves up to the spec. I wrote about that in The review gap. If review still means a human reads everything, your ceiling is unchanged no matter how fast the code gets written.

Nobody owns the harness

This pattern separates the teams where AI sticks from the teams where it decays. The setup that makes agents reliable (the conventions, the checks, the spec templates, what I call the harness) is a living system. Every failure is information. A rejected PR means a rule is missing; a production surprise means a check is missing. On teams where someone owns that loop, the system gets better every week. On teams where nobody does, it rots, and six months later people say “we tried AI, it didn’t really work for us.”

At nerds.family I own that loop, and it’s why a two-person, part-time team has shipped daily for six months. When we moved the same harness to Gyfted, a product on a stack we don’t usually touch, the guardrails held and their CPO now ships landing pages to production without a developer in the loop. Our own count, small products, but the transfer is the interesting part: what moved between codebases wasn’t a tool. It was the structure around it.

What sticking actually looks like

Pick one team, not the whole org. Give them shared conventions in the repo, verification that fails loudly, review restructured around intent, and a named owner for the harness. Let them run on real tickets for a few weeks, then let the results argue for the next team. The macro economists may be right that AI productivity follows a J-curve, with the dip before the climb. At team level, the dip lasts exactly as long as it takes to build the structure. Teams that never build it stay in the dip indefinitely, while reporting to the NBER that AI changed nothing.

The 90% isn’t evidence that this doesn’t work. It’s evidence that almost everyone is doing the part that doesn’t matter.

fryga.io
fryga — a product engineering consultancy in Kraków, Poland. We build with companies in Spain, Norway, the US, and beyond.
Marcin writes about Rails and AI at rubyonai.com
The Rails AI harness, in the open at github.com/fryga-io/superpowers-rails
We're four people — maybe five: careers
[email protected]
RubyPL sp. z o. o.; ul. Będzińska 5 /8, 31-403 Kraków, Poland; KRS: 0001044822; NIP: 6762646011; REGON: 52575800600000