AI Agent Governance Is the New Discipline in Software Engineering

A CTO told me recently that he no longer wants his developers typing. He didn't mean it literally. What he meant was to stop hand-writing code, let the agents do that. A bold ambition. Also, a setup for disappointment, because most teams that flip the switch on Copilot or Claude or Cursor don't get the step change they were promised. They get a faster hamster on the same wheel.

I had Chris Condo back on Stacked Sessions to dig into why. Chris is a client partner at Equal Experts, a former Forrester principal analyst, and the guy who authored the Wave that put value stream management on the map. He spends his days inside real engineering orgs trying to make AI actually deliver. His diagnosis is blunt. A single engineer going faster doesn't help the system. If one piston fires harder while the rest of the engine sputters, you don’t get a better engine.

So the win isn't speed. The win is a step function: moving from working with the agent to the agent working for you. That sounds like a tooling upgrade. It isn't. It's a new engineering discipline, and almost nobody has staffed for it.

The agent needs the whole picture, not the code

Chris sees the same pattern first, every time. An engineer gets access to an agent and immediately points it at the code. Migrate this, refactor that. Reasonable instinct, and also the narrowest possible use of the thing.

Because the code is one wheel. The agent doesn't know your backlog, your specs, your architecture, your definition of done, or the three compliance checks that gate every release. It doesn't know what the application is supposed to do or why you're building it. You know all of that intrinsically after fifteen years in the industry. The agent knows none of it.

So the actual first job is building context. Teaching the agent how code is written in your environment so it produces compliant output. Loading the goals, the standards, and the guardrails into the skills profile or the agents file. Chris put it well: you have to re-educate the agent on what engineering even is at your company. Point it at outcomes, at what the application is actually for. Otherwise, you've automated one tiny corner and called it a transformation.

This is the part that maps cleanly to how I think about engineering intelligence. The leverage isn't the model. It's the model of your organization that the agent gets to work from.

Agents drift, and that is the governance problem

Now, the part that should keep you up at night.

Chris told a story about a company called Travelopia. A product manager added a new permissions level for one agent on one feature. Nobody asked for it anywhere else. But the context absorbed it, and the change started propagating to other features being built in parallel. The system didn't discriminate cleanly between feature lines. It just spread.

Steve Yegge has written about the same thing: agents doing work nobody asked them to do. They take on a life of their own. Welcome to the probabilistic nature of software at hyperspeed, where the output is usually close to the target and occasionally somewhere you never intended.

This is why AI agent governance in software engineering is no longer a checkbox. It's a discipline with real headcount behind it. You may not need more people writing code. You will need people watching how the code drifts, keeping the guardrails honest, making sure a decision in one feature area doesn't quietly leak into five others. Caretakers for the fleet. That role didn't exist three years ago.

Governance that doesn't put a human in front of every line

The reflex, when leaders hear "governance," is to slow everything down. More reviews, more approvals, and gating with the release engineer who happens to be on vacation the week you need to ship.

That model doesn't survive contact with agents generating ten times the volume. Chris framed the fix the way we used to frame DevOps. The compliance officer shouldn't be reading the code. They should be telling you which tests have to pass. Every time something goes out the door, the system reports that all checks passed, and it has shipped. If two tests fail and you still want to ship, that's when a human looks. A person enters on the exceptions, not on every release.

Automate the checklist. Tabulate the coverage, the security scan, and the accessibility test. If the automation can confirm the release meets the criteria, what exactly is a human adding by re-checking it by hand? And when a bug slips through, the fix isn't more manual review. It's another automated test, fed back into the loop.

One caveat Chris was firm about: none of this works without a champion inside the company. Someone empowered to change how the SDLC operates, with relationships from the business stakeholders down to the change approval board. Governance is as much an org problem as a technical one.

The pressure moves to the business

The product side feels the shift next. When engineering can spin a feature through to production in a day instead of two weeks, the bottleneck becomes deciding what to build.

Chris sees the roles splitting. Product-minded developers are becoming product technicians who can spec and build small features themselves. Traditional product managers still owning the harder questions: what do customers actually want, what's worth pricing for value versus market share, and where are the real gaps? And a new layer of people minding the AI platform itself. As one CTO he works with put it, for the first time, the pressure is on the business team to decide faster, not the engineering team to do more.

That's a real shift. The velocity charts were never the point. Value stream management, the thing Chris helped name a decade ago, comes back around here. It comes back as a discipline for making sure the thing you ship fast is the right thing.

What separates the teams pulling ahead

Going faster was always the wrong goal. The teams pulling ahead with AI aren't the ones with the best prompts. They're the ones who built a real model of how their organization delivers, pointed the agents at outcomes, and stood up the governance to catch drift before it ships.

That's the discipline. It's also, not by accident, the problem we think about constantly at Allstacks. The Allstacks platform gives agents that model of your delivery system so they can help you build better software with less delivery risk across it. Govern your fleet with something that actually understands how you build.

Chris and I covered a lot more than this in the full session. Worth a listen if any of this sounds like your week.