{"slug": "the-great-divergence-in-software-engineering", "title": "The Great Divergence in Software Engineering", "summary": "Software engineering teams that have embraced AI are compounding productivity gains, while others actively reject AI or remain stuck in evaluation, creating a widening gap in how work gets done. A CEO recently banned all AI company-wide due to distrust of output quality, but effective teams treat bad output as an engineering problem rather than a reason to stop.", "body_md": "# The Great Divergence in Software Engineering\n\nSix months into 2026, the difference between teams using AI effectively and teams still evaluating it isn't a head start anymore. It's a different way of working entirely. And the gap isn't just widening — teams are actively moving in opposite directions.\n\nSix months into 2026, the difference between teams using AI effectively and teams still evaluating it isn't a head start anymore. It's a different way of working entirely. And it's pulling further apart every week.\n\nI run a small team. In the last four months we've shipped swamp, built swamp-club as a full platform — extension registry, docs site, user management, admin system, gamification engine, metrics orchestrator — and shipped new features every day while building out the ecosystem around it. We've built a primitive that lets other people build infrastructure automation, CVE scanning, cost analysis, infrastructure validation, and more. And they're doing exactly that. A year ago, that would have been the roadmap for a team ten times our size. It's not that we work harder. We work differently: every piece of automation we encode makes the next one faster to build.\n\n## This isn't innovators versus laggards\n\nThe usual version of this story is a curve. Innovators go first, the mainstream follows, the laggards catch up eventually.\n\nWhat I'm seeing is three groups. Teams that have embraced AI and are compounding every week. A growing number of teams and leaders actively moving the other way, loudly distrusting AI, insisting their domain is too complex for agents, arguing the costs don't justify the results, convinced this is a fad that doesn't apply to them. And then the biggest group: the ones stuck in the middle, running pilots that never graduate, forming committees to evaluate tools their competitors shipped with six months ago.\n\n[Eighty percent of workers](https://fortune.com/2026/04/09/ai-backlash-quiet-quitting-fobo-obsolete-white-collar-rebellion/?ref=stack72.dev) are either avoiding or actively rejecting the AI tools their employers deployed. [One mid-size tech company's CEO](https://www.inc.com/joe-procopio/the-first-company-wide-ai-ban-just-hit-my-inbox-heres-what-it-means/91357535?ref=stack72.dev) just issued a total prohibition on all AI — no exceptions, no timeline for reversal. His reasoning was that he \"couldn't get people to make the right judgment calls on where it made sense to use AI and where it didn't.\" So instead of building that judgment, he removed the option entirely.\n\nThe justification is always the same. AI slop. Agent distrust. The output can't be trusted, you can't verify what it did. And they're not wrong about the symptoms. Unstructured AI use does produce slop. Agents without conventions, without guardrails, without review pipelines do produce unreliable output. That's real. We hit the same problems early on. Our first instinct was to over-guard everything. We prompted Claude so strictly that the agent could barely move. Then we learned to extract those guardrails back out of the prompt and into the machine: conventions, adversarial review, design docs that load contextually, trust boundaries that the system enforces rather than the prompt. The difference is we treated the bad output as an engineering problem, not a reason to stop.\n\nThey treated those failures as evidence the technology wasn't ready. We treated them as engineering problems.\n\n## Why the gap compounds\n\nAdam Jacob has [an analogy I keep coming back to](https://www.adamhjk.com/blog/as-we-build-so-we-believe/?ref=stack72.dev): it's like the water pressure in your house just increased by an order of magnitude. If that happened, every single pipe in your home would burst. And it's not a one-time jump. Someone is using that increase to build a system that jumps the order of magnitude again.\n\nMost engineering organizations were built for a certain throughput. The review processes, the deployment pipelines, the team structures, the way knowledge gets shared. All of it assumes a rate of change that was reasonable two years ago. AI changed the order of magnitude.\n\nThe teams pulling ahead didn't just add AI to their existing process. They replaced the process. New patterns for how work gets encoded, how automation compounds, how an agent builds something once and a deterministic workflow runs it forever. The teams that haven't done this are cranking the pressure on pipes that were designed for a different era. And the pressure keeps climbing.\n\nThe models that made this possible have been good enough for serious engineering work for about nine months. That's it.\n\nA team that started nine months ago isn't nine months ahead. That's the linear way of thinking about it, and it's wrong. Every tool they built is reusable. Every workflow they encoded frees up time to build the next one. The tribal knowledge they captured doesn't walk out the door when someone leaves anymore. Nine months of compounding looks nothing like nine months of linear progress.\n\nI've watched this with our own work. Our real superpower now isn't that new features are faster to build, it's that I can refactor an entire subsystem in hours to drive a better outcome than it had before. We do this every single day to optimise what our users need. That kind of continuous architectural improvement used to be something you'd put on the backlog and never get to. Now it's just a fun afternoon with a beer and an agent.\n\nTeams starting today aren't closing a nine-month gap. They're chasing one that kept widening. The teams actively banning AI tools are worse off. Every month without tooling is a month their engineers spend on implementation work that their competitors automated back in January.\n\n## What's actually at risk\n\nFalling behind your competitors is the obvious risk. But that's only part of what I worry about.\n\nA lot of teams and companies have built their moat on their code and how they work. The way they write integrations, the scripts they maintain, the processes they've refined over years. That moat is shrinking every day. Hand-writing integrations, maintaining bespoke scripts, manually triaging security advisories, building one-off dashboards. All of that is automatable today, not in some future state.\n\nThe expertise still matters but it's the time it takes to turn that expertise into code that's becoming commodity. Engineers still spending their days on it are misallocated. The valuable work shifted to problem definition, system design, and judgment calls. The teams that figured that out are deploying their people against harder problems while their automation handles the rest.\n\nThat shift reaches hiring too. Every established contract in IT hiring is based on assumptions about what one person can produce. Job descriptions, interview loops, seniority ladders, team composition. All designed for the old throughput. When a small team with the right patterns can ship what used to require a department, all of that has to change. Most organizations haven't even started that conversation.\n\nThe ones actively banning AI are making it harder to have later. The engineers who want to work this way will leave. The ones who stay will build muscle memory around processes becoming obsolete. When the correction comes — and it will, because a larger and larger number of teams are showing the results they're getting — those organizations will be staffed with people trained to work in a way that no longer exists.\n\n## What happens next\n\nI've been in this industry long enough to have watched what happens when a platform shift catches teams off guard. Cloud computing did it, then infrastructure as code, then containers, then Kubernetes. Each time, early adopters pulled ahead and the rest spent years catching up.\n\nI've never seen the feedback loop this short. Cloud took years before the gap was obvious. This has taken months. You don't need to migrate a data center. You need to change how your team works.\n\nBut those previous shifts were simpler. Everyone was moving in the same direction at different speeds. This time the ground is splitting. Teams on one side are rebuilding how they work from the foundations up. Teams on the other side are reinforcing the old way and hoping this is a fad — like blockchain 🤣 — that will blow over if they wait long enough.\n\nEvery model release adds more pressure. The organizations in the middle who still evaluating, still running pilots, are standing right where the fault line runs.\n\nThe plumbing your organization runs on was designed for a pressure that no longer exists. Patching the leaks buys time. But the teams who already rebuilt their pipes aren't slowing down while you decide.", "url": "https://wpnews.pro/news/the-great-divergence-in-software-engineering", "canonical_source": "https://stack72.dev/the-great-divergence-in-software-engineering/", "published_at": "2026-07-09 18:00:08+00:00", "updated_at": "2026-07-09 18:19:53.364332+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-tools", "ai-agents", "ai-ethics", "developer-tools"], "entities": ["Adam Jacob", "Claude"], "alternates": {"html": "https://wpnews.pro/news/the-great-divergence-in-software-engineering", "markdown": "https://wpnews.pro/news/the-great-divergence-in-software-engineering.md", "text": "https://wpnews.pro/news/the-great-divergence-in-software-engineering.txt", "jsonld": "https://wpnews.pro/news/the-great-divergence-in-software-engineering.jsonld"}}