The Great Divergence in Software Engineering

speckx1 pts0 comments

The Great Divergence in Software Engineering

Six 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.<br>I 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.<br>This isn't innovators versus laggards<br>The usual version of this story is a curve. Innovators go first, the mainstream follows, the laggards catch up eventually.<br>What 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.<br>Eighty percent of workers are either avoiding or actively rejecting the AI tools their employers deployed. One mid-size tech company's CEO 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.<br>The 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.<br>They treated those failures as evidence the technology wasn't ready. We treated them as engineering problems.<br>Why the gap compounds<br>Adam Jacob has an analogy I keep coming back to: 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.<br>Most 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.<br>The 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.<br>The models that made this possible have been good enough for serious engineering work for about nine months. That's it.<br>A 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.<br>I'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.<br>Teams starting today aren't closing a nine-month gap. They're chasing one that kept widening. The teams actively banning AI tools are...

months teams engineering nine build work

Related Articles