Gatekeeping in the Age of AI

Spend ten minutes on any tech feed and you’ll see the same exchange play out. Someone shares something new. Before long, someone else arrives to explain, in a lot of detail, why it shouldn’t exist. Every idea in it, they say, is already in Kubernetes, or some other tool, and has been hardened for years. Anything it does could be done with a few lines of config, and the models are already perfect at writing that config.

Apparently, there’s nothing left to build.

It’s gatekeeping, and right now it’s everywhere.

I’ve been in this industry long enough to recognise the pattern. When configuration management arrived, people asked why we needed it when we had Perl scripts and CPAN. When Kubernetes arrived, people asked why we needed it when we already had ways to deploy and manage workloads.

I’ve been part of the problem too. I pushed Terraform hard at every conference I spoke at. Then I left, went to Pulumi, and did exactly the same thing. Every single time, I was protecting what I was working on.

I knew the tool, I knew what it could do, and I knew how to work around the bits it didn’t do particularly well. So when something else appeared, I could usually explain how to achieve the same result with what I already used. I didn’t spend enough time asking why someone had felt the need to build it anyway.

That’s what bothers me about the conversations happening around AI now. We have an opportunity to change how we build software, and people are using their experience of the existing process to explain why we shouldn’t.

For decades we’ve accepted slow pipelines, brittle scripts, glue code nobody wants to own, tribal knowledge that walks out the door, and processes that only work because someone remembers how. We got so used to it that the pain started to feel like the craft. AI gives us a real chance to stop suffering some of it, but we have to be willing to change more than the tool we type into.

At Swamp, every line of code is written by agents. That has forced us to reconsider how we plan work, review it, test it and ship it. Some of what we already knew has become more important. Some of what we assumed would work hasn’t. We’ve had to find that out by doing it, including getting things wrong. If we’d kept the same process and just asked agents to take over the typing, we’d have missed most of the opportunity.

The pushback tends to ignore that part. Your workflow is just their pipeline, they say. Your thing is just their custom resource. They can map the pieces onto a platform they already know, so the whole thing must be redundant. But being able to assemble the same capabilities doesn’t tell you how much work it takes to use them, or whether they fit the way agents operate.

You see the same thing with testing. Question what an agent-written unit test actually verifies and you can spend the rest of the conversation defending whether you understand testing at all. The agent’s ability to change both the implementation and the test gets lost while everyone argues about the practice they were taught.

And then there’s “it’s all slop”, where the fact that an agent wrote the code is enough to dismiss it, regardless of how it was specified, reviewed or verified.

There are real problems behind these arguments. I’ve written about them because we encounter them. Agents misunderstand requirements. They produce bad code. They change tests to get a green result. Having a second agent review the first one doesn’t automatically give you independent verification.

Those are reasons to take the engineering seriously. We need to understand what failed and what would catch it. Sometimes the model isn’t capable enough. Sometimes we gave it a poor specification. Sometimes the verification was checking the wrong thing. You don’t learn which by looking at a bad result and declaring the whole approach worthless.

That’s where criticism becomes gatekeeping for me. Tell me where the system breaks. Show me the requirement we haven’t verified. Ask whether our review process would catch a particular failure. I want those conversations. “We solved this years ago” doesn’t answer a question about whether the conditions have changed.

And the conditions are changing. Some of the tools we all treat as settled are already being questioned by the people closest to the problem.

GitHub is struggling with the volume. Its account of the August outages describes capacity failures as monthly commits grew from 1.4 billion to 2.9 billion since April.

Anthropic hit the same wall in its own monorepo. Merges went from around 2,500 a day in May to over 30,000 a day by September, so a team of seven built Scion, along with a code review tool and several related systems, and migrated off Git in five months. They weren’t short of people who understood Git. Most of their clients were agents and jobs that were online anyway, so keeping independent repository copies everywhere cost a lot for properties those clients didn’t need. They’re clear that most teams don’t need Scion. But they did, and getting there meant questioning a tool almost everyone treats as a given.

Delta from Zed is tackling another part of the problem. Conversations with agents, the code they produce and the review of that code stay together in a shared thread. DeltaDB records the changes between commits while continuing to work with Git.

You can point to chats, branches and pull requests and say we already have all those pieces. We do, but we also spend a lot of time moving between them, copying context around and trying to reconstruct why a change was made. That gets harder when agents are producing more work than people can reasonably follow through the old interfaces.

This is already happening. Teams adopting AI are putting pressure on the infrastructure around software development, and they’re building different ways to work when the existing ones get in the way.

I don’t think we know yet how much of the process will change. I do think it’s strange to be so certain that the practices we have now are the final answer.

The requirement to verify software hasn’t gone away. Neither has the need to understand architecture, manage risk or operate what we ship. But the cost of implementation has changed substantially for teams working this way. That affects how much work they can attempt, how they divide it up, and where they need people involved. We should expect to revisit the process around it.

But instead, a lot of the debate seems to demand that teams demonstrate the benefits of AI while preserving every part of the workflow that existed before they adopted it.

I understand why leaders hesitate. There’s plenty of unreliable output to point at, and adopting AI properly takes effort. You have to give people time to experiment, accept that some experiments won’t work, and change processes that people are comfortable with. Buying subscriptions is the easy part.

But the teams doing that work are learning things the teams waiting aren’t. We’ve changed our approach repeatedly because of what we found while building. We couldn’t have worked all of that out in a pilot designed to prove an agent could complete a few tickets.

In The Great Divergence in Software Engineering, I described the teams changing how they work, the teams moving away from AI, and the group in the middle running pilots that never graduate. The dismissals matter because that middle group is listening. Every “that’s already solved” gives a nervous engineering leader another reason to wait a quarter.

The people building new things will carry on. The teams being talked out of trying are the ones who lose the time. I want experienced engineers involved in this. We need people who understand why the existing practices developed, what failures they prevent and which constraints still matter. I’ve used that kind of knowledge to defend the thing I knew. It’s far more useful helping to change it.

This isn’t Terraform versus Pulumi or Puppet versus Chef. The choices we make now will shape how software gets built for decades. Let’s not talk ourselves out of it.