# The adoption experts who won't adopt > Developers spent a decade complaining that users won't adopt new software. Now agents arrive, and the same people go through denial, cherry-picked failure stories, and workflow-clinging themselves. The blocker isn't capability, it's identity. - Author: Jonas Rohde (@edhor) - Published: 2026-07-20 - Canonical: https://edhor.me/blog/the-adoption-experts-who-wont-adopt/ - Tags: ai-agents, adoption, developer-culture, agentic-coding It's really funny to see: the exact people who complained for years about users not being able to adopt new software are now behaving the same with agents. Every developer knows the complaint. We built the new system, it's objectively better, and the users… just won't use it. They cling to their Excel sheet. They ask for the old button back. They found one bug in week one and now "the new tool doesn't work". We rolled our eyes at this for a decade, gave talks about change management, built onboarding flows and feature tours because _users resist change_. And now agents arrive in software development, and the same people (us) go through the identical stages. Which brings me to the question this post is actually about: **why is this agents topic so difficult exactly in software development?** I think the answer is more uncomfortable than "developers are lazy". ## TL;DR - Developers are going through textbook adoption resistance: denial, cherry-picked failure stories, clinging to the old workflow. The same pattern we mocked our users for - The blocker is not capability. Agents got good, the arguments didn't update - The real blocker is identity: writing code is what many of us built our professional self-image on, and agents automate exactly that part - The way out is to stop being fixed on the keystrokes. You were never paid for code, you were paid for working software ## The pattern looks really familiar Watch a software department meet agents and you see every stage we know from our users: - **Denial:** "It's just fancy autocomplete." Said today, about tools that plan, run tests, review their own diffs and work for hours unattended. - **The one failure story:** "I tried it once, it hallucinated an API. Useless." One bug in the new system, and the old Excel sheet was suddenly great again… remember? - **Workflow-clinging:** insisting every agent change goes through the full human-sized ceremony, so the new way is guaranteed to feel slower than the old one. - **Waiting it out:** "Let's see where this goes first." A strategy that, as far as I can tell, has never once worked for a platform shift. If a user behaved like this about our software, we would call it a change management problem and get to work. Somehow when we do the same ourselves, it counts as engineering rigor. ## It's not about capability First, rule out the obvious suspect. Most of the resistance arguments were formed on models from one or two generations ago and never updated. Agents today onboard into a codebase [like a professional new joiner](/blog/good-for-new-joiners-good-for-agents/), keep their own context, verify their work and loop with reviewers. Are they flawless? No. Neither is any colleague you ever had. The honest comparison is not "agent vs. perfect engineer", it's "agent loop with reviews vs. what your team actually ships under deadline pressure". But here is the thing: the capability arguments get weaker with every model generation, and the resistance stays exactly the same. So I don't believe capability was ever the real argument. ## The real one: identity Software developers are in a strange position: we are the first profession watching our _craft itself_ get automated, by ourselves, with tools we built. Writing code is not just what many developers do, it's what they _are_. The years of learning, the taste, the elegance of a well-crafted function: that's the identity. And agents walk in and do exactly the typing part. That's why I think this is so much harder in software departments than anywhere else. Nobody's identity was "person who fills in the Excel sheet". But "person who writes great code"… that's a self-image worth defending, and people defend it with technical-sounding arguments because those are more acceptable than "I'm scared of losing what makes me valuable". I get asked why I'm not more attached to writing code myself. My honest answer, and honestly my answer to the whole debate: > Why are you so fixed on writing code? I really don't care. I care about the idea, the product, the system that ends up existing in the world. Code was always the means, it was never the point. And I noticed that this sentence provokes developers way more than any benchmark result does, which tells me we are not really arguing about tools here. ## Treat it as the change project it is The funny part is that we already know the cure. It's our own playbook, the one we always wished management would apply to _our_ software rollouts: - **Don't argue capability with people defending identity.** No benchmark convinces someone whose real objection is unspoken. Address the actual fear instead: your judgment gets _more_ valuable, not less. - **Wins over slides.** One team visibly shipping faster with agent loops converts more colleagues than any all-hands deck. - **Meet the workflow where it is.** Users kept their Excel sheet because the new tool ignored how they worked. Same here: forcing agent output through unchanged human-sized ceremony guarantees it feels slower. Adapt the process, not just the tooling. - **Expect the dip.** Every adoption gets worse before it gets better. Teams that quit in the dip "proved" it doesn't work… the same proof our users always brought us. ## You were never paid for code No customer ever paid for keystrokes. They paid for working software: problems solved, systems running, decisions encoded correctly. Everything you actually bring (judgment, taste, architecture, knowing what _not_ to build) becomes more valuable when the typing is free, not less. Even the old quality instincts survive the shift, they just need a new definition (more on that in [Maintainable for whom?](/blog/maintainable-for-whom/)). The adoption experts were right all along: resisting a platform shift doesn't stop it, it only decides how much say you have in how it plays out. We knew that when it was about our users. Now it's about us.