Speed limits, GenAI coding agents and Autobahns - part 2: raising the safe speed

generative AI   genAI development   harness engineering   fast flow   deployment pipeline   design-time coupling   microservice architecture   technical debt   decision making   architecture  

---

---

Part 1 developed a driving metaphor for GenAI-based development: you are the driver, the coding agent and its harness are the car, and your code and delivery system are the road. And in the same way that the road determines how fast you can drive, the characteristics of the code and the socio-technical architecture around it determine how fast you should let the agent generate code, and how much cognitive debt, if any, is acceptable.

Part 1 also covered the first of the three ways of working with a coding agent: understand the road - what condition the code and the socio-technical architecture around it are in - which tells you the safe speed. This article describes two ways to raise the speed limit. First, you can improve the road: the architecture, the tests, the guardrails and the deployment pipeline. Second, you can improve the car: the model, the prompts, the tools and the workflow that make up the harness.

Both of these improvements work the same way: they improve the conditions, increasing confidence that the agent’s output will be correct, and confidence is what sets the safe speed. Let’s look at each improvement in turn, starting with the road.

Improve the road: make a stretch safe at higher speed

Unlike a driver, you aren’t stuck with the road as it is. You can improve it: you can decouple the code, tighten the guardrails, limit the damage when something does get through, and speed up the deployment pipeline. What’s more, road improvements are persistent: decouple a module once, and every future change to it is easier.

Let’s look at each way to improve the road in turn.

The road surface: loose design-time coupling

Loose design-time coupling is the road surface. It localizes changes so that both people and agents can work faster, and the agent uses fewer tokens and less context. A tightly coupled - 25 mph - section becomes a faster stretch of road once it’s decoupled.

Guardrails: automated tests and checks

Some improvements catch mistakes and prevent a bad change before it leaves the road: fast automated local tests, type checking, linters, CI, and human review. The more reliably a mistake is caught early, the faster you can safely generate code.

A check that depends on somebody remembering to run it isn’t really a guardrail, so automate it. Pre-commit checks, Git hooks, CI jobs and automated pull request review can gate the change at different points, providing defense in depth.

Run-off areas: canary deployments and fast rollback

A run-off area limits the damage when a mistake does get through. The software equivalents are canary deployments, fast automated rollback and smaller batches. The cheaper a mistake is to recover from, the less it costs to be wrong, and the faster you can safely go.

Extra lanes: microservices with their own deployment pipelines

Just as a road becomes congested when traffic exceeds its capacity, a deployment pipeline becomes a bottleneck when changes arrive faster than it can deploy them. A handful of developers running agents can generate more commits in a day than a much larger team once did. Joe Magerramov’s “The Valley of Calm” describes how at around a hundred commits a day, a pipeline “stops behaving like a pipeline and starts behaving like a traffic jam.” Because batches are cumulative, a defect rejects the whole batch, and the commits that arrive while you fix it make the next batch bigger and more likely to fail again. His simulation shows that beyond a certain point teams end up in a plateau of misery where almost nothing ships.

The remedy for road congestion is more lanes. Similarly, as I describe in GenAI-based software delivery needs a fast flow architecture, the solution for an overloaded deployment pipeline is a microservice architecture. Each service has its own deployment pipeline, which handles fewer commits from a single team and verifies a smaller code base. Collectively, these deployment pipelines can process many more commits than a single shared pipeline.

Improve the car: strengthen the agent and its harness

Now let’s consider the car. Besides its speed, a real car has safety features: high-performance brakes, collision avoidance, seatbelts, and airbags. A coding agent is similar. The raw model sets the top speed, and the harness is what makes it safe to use.

Structurally, a harness is the coding agent sandwich: plain old code orchestrating on top, the model in the middle, and deterministic tools underneath. My own implement agent orchestrator is built that way.

The harness both prevents mistakes and catches them. As Birgitta Böckeler writes in Harness Engineering, a harness consists of guides that shape what the agent does before it acts, and sensors that provide feedback so it can correct course afterward.

Guides: shaping what the agent does before it acts

Guides tell the agent how to work: coding conventions, architecture documents, skills and how-to guides, and the deterministic tooling underneath - e.g. language servers, CLIs, automated refactoring tools - that makes the right thing the easy thing. Keep them in good order so that the agent has what it needs. The better the guides, the more often the agent gets it right the first time, so the less you have to slow down to check its work.

Sensors: providing feedback to the agent

Sensors provide feedback enabling the agent to course-correct: linting, static type checking, dead code detection, test coverage verification, and code health analysis such as CodeScene. I described some of these in a GenAI-based development platform. Those all run against the code, but a sensor can also report from the running system: observability data tells the agent what a change actually did, not just whether the code looks correct.

A check that is a sensor can also be a guardrail, and vice versa. When a check runs in the pipeline, it’s a guardrail that gates the change. And when it runs alongside the agent, it is a sensor that provides feedback so that the agent fixes the problem itself. The better the sensors, the more mistakes the agent catches and fixes before you ever see them, so the more confident you can be in its output, and the faster you can let it go.

In the same way that a better car lets you go faster on most roads without removing the road’s limits, a better harness lets you go faster with a coding agent without removing the limits imposed by the codebase and the team. That’s why it’s important to improve both the road and the car.

Summary

The safe speed isn’t fixed. Improving the road - the architecture, the tests, the guardrails and the deployment pipeline - and improving the car - the harness around the model - both raise it. They increase confidence that the agent’s output will be correct, and confidence is what sets the safe speed.

That’s what fast flow means in practice: moving fast without breaking things. Set the speed limit deliberately, then do the work to raise it.

Need help with modernizing your architecture?

I help organizations modernize their architecture to enable fast flow and GenAI-powered software delivery. If you’re planning or struggling with a modernization effort, I can help.

Learn more about my modernization and architecture advisory work →