Engineer Resistance to AI Rollouts Is a Trust

Corporate AI rollouts keep failing, and leadership keeps calling it a training problem. Nate B Jones, who advises organizations on AI adoption, has a more uncomfortable diagnosis: the engineers aren't confused. They're skeptical — and they have reasons.

Jones's recent video lays out a three-part framework for leaders trying to move past that skepticism: make a public commitment about job security, scope the first pilot ruthlessly, and then do the hard work of articulating what stays human when agents start handling the first draft. It's practitioner-grade advice, grounded in what actually breaks down during rollouts. But it also illuminates something the change management genre usually papers over — that resistance lives in specific communities, specific team dynamics, and specific histories of how software work has been valued (and devalued) over time.

Let me tell you what I mean by that.

The "engineers" fiction

Jones opens with a sharp observation: "In any team over say 50, you really do have a collection of folks in your business that are not fans of AI at all, not happy that you're doing AI, actively resistant." He cites — without naming the source or publication date — a survey claiming that a third of employees globally admit to sabotaging AI tools. I can't independently verify that number, and Jones doesn't anchor it, so take it as his characterization rather than established fact. But the underlying observation tracks with what I hear from developers across different community contexts.

Here's the thing Jones's framework smooths over: "engineers" is not one category. The backend developer at a Series B startup with a VP of Engineering who barely codes has a completely different relationship with a corporate AI mandate than an open source maintainer who already has Copilot in their workflow and has been arguing about its implications on GitHub threads for two years. A contractor embedded in a team that's been through three "digital transformation" initiatives that went nowhere has different threat models than a recent grad who learned to code alongside LLMs and thinks the resistance is generational.

These distinctions matter because the trust deficit Jones correctly identifies is not uniform. It's not even primarily about AI — it's about whether this workplace has historically told the truth about what technology changes actually mean for the people doing the work. Teams at companies with a history of layoff-and-rebrand have every reason to read "AI productivity initiative" as a headcount reduction in progress. Teams in strong engineering cultures where craft is genuinely valued have different concerns: they're often worried about quality, about accountability, about who owns outputs when an agent is in the loop.

Jones's first principle — make a public commitment about employment — is correct. Name the elephant, he says: "What we are doing here is not designed to destroy jobs in this company." The framing around slowing hiring rather than cutting headcount is useful precisely because it's honest about a real dynamic without making promises leadership can't keep. What it doesn't address is that the credibility of that commitment depends entirely on institutional track record. In open source communities, we've watched this play out in governance disputes for years: the maintainer who controls the roadmap makes promises about community involvement, and people's response depends almost entirely on whether that maintainer has kept similar promises before. The signal here is behavioral, not verbal.

The middle layer is where it actually lives

The second principle — pick a specific pilot, measure it honestly, and tie it to business outcomes — is the most operationally sound part of Jones's framework, and also where the enterprise AI failures documented elsewhere become relevant. The pattern he's pushing against is real: vague mandates ("everyone start doing AI") that produce neither adoption nor useful data about why adoption isn't happening.

Jones's most acute structural observation is about middle management. He's unambiguous: "If team level leadership isn't passionate about this, nothing is getting done. Nothing is getting done." Directors and VPs can run all-hands meetings, but the person who controls whether an engineer's day-to-day workflow actually changes is the engineering manager, the tech lead, the person who reviews PRs and decides what counts as good work.

This is where the social network dimension of AI rollouts gets genuinely interesting, and where I'd push Jones's framework further. In developer communities — not just corporate ones — tool adoption spreads through trust graphs, not mandates. When Prettier became the standard for JavaScript formatting, it wasn't because CTOs sent memos; it was because respected contributors in specific communities started using it, wrote about it, and made the path of least resistance point toward adoption. The same dynamic operates inside engineering organizations. The senior engineer whose opinion the team actually weighs — not the person with the VP title, but the person whose architecture decisions get followed — is the real adoption lever. Jones identifies middle management as the key layer, but the informal hierarchy often matters more than the org chart.

Jensen Huang and the productivity bargain

Jones invokes Jensen Huang's public position on this — that leaders who cut employees in the AI transition lack the imagination to find new work for their teams — as a rhetorical template for how to speak to skeptical engineers. Jones doesn't cite a specific interview or statement, so I'll treat this as Jones's characterization of Huang's public posture, which aligns with things Huang has said in various forums about NVIDIA's approach to its workforce. The framing Jones recommends: AI is a productivity multiplier, and my job as a leader is to find the larger vision for what we do with that multiplier.

It's a compelling narrative. It's also one that raises the governance question Jones's framework doesn't really sit with.

When productivity compounds — when the same engineering team ships two or three times as much — who decides what gets built with that additional capacity? In open source communities, this question has been alive for years in a different register: when a tool dramatically reduces the labor required to maintain infrastructure, does that free up contributors to do more interesting work, or does it reduce the leverage contributors have when negotiating with corporate sponsors? The analogy isn't perfect, but the underlying dynamic is the same. Productivity gains don't distribute themselves. Someone makes a decision about where the surplus goes — more features, more margin, more hiring, or fewer contractors. That decision is a governance question, not a technical one.

The ROI expectations being built into enterprise AI investments assume those gains accrue to the business. Jones's framework, to its credit, argues that leaders need to tell employees where the change leads — "leaders can require the change, and the rollout only holds if they can also tell people where that change leads." But "the human work you protect on the other side" is doing a lot of load-bearing in that sentence. Protecting some human work is not the same as answering the distribution question.

What stays human, and who decides

Jones ends on what he sees as the durable human edge: judgment, quality review, eval writing, system design, the work of stripping LLMisms from outputs that need to sound like the organization rather than like a language model. Engineers are becoming system designers and eval authors. He's right that this work is real and demanding — "figuring out how to work with models successfully is the hardest challenge that I think we've had to face in 500 years of the corporation," he says, with an earnestness that I find more persuasive than the confident predictions coming out of San Francisco about agents making all of this moot.

What's notable in the open source world is that these "what stays human" decisions are already being made, iteratively and sometimes contentiously, in public. Projects are debating whether AI-generated contributions get reviewed differently, whether LLM-assisted PRs require disclosure, who's responsible for a bug in a commit that was 80% agent-generated. These aren't theoretical governance questions. They're in issue trackers right now.

Corporate engineering teams are going to face versions of all of these questions, and the answers aren't going to be handed down from a leadership all-hands. They're going to get worked out — or not — at the level of team norms, PR review conventions, and the informal authority of the people whose technical judgment everyone actually trusts.

Jones's framework gives leaders a usable starting point for the political work of AI adoption. The question it leaves open is whether the leaders who most need to hear it are the ones prepared to follow through on what it actually asks of them — which is not a rollout strategy, but a genuine renegotiation of what engineers are owed when their work changes this fundamentally.

Dev Kapoor is Buzzrag's open source and developer communities correspondent.