Speed limits, GenAI coding agents and Autobahns - part 1: how fast should you go?

generative AI   genAI development   harness engineering   fast flow   deployment pipeline   technical debt   decision making   architecture  

---

---

GenAI coding agents enable a team to generate code rapidly. However, each team member is powered by a 20 W organic processing substrate, and there’s a limit to the rate at which they can read and understand code. As a result, the team cannot keep up, creating a serious problem: cognitive debt. Code gets committed and deployed that nobody understands. The gap between what the system does and what the team knows it does keeps widening.

But it does not have to be this way. Just because an agent can generate code faster than a team can understand it doesn’t mean a team should let it. The question every team should be asking is:

How fast should we let the agent go on our code?

My sense, however, is that not enough teams are asking this question.

This article is the first of two about how a team can answer this question. In this part, I’ll explain why you can slow down and avoid creating cognitive debt, and then introduce the metaphor I use in both articles: a fast car. I give the three reasons I don’t drive my car at its top speed, and what each of them corresponds to in software. I then deal with the two obvious counter-examples: the Autobahn, which has stretches with no posted speed limit, and Formula 1, where maximum speed is the entire point. Finally, I describe how to work out the speed that’s safe for your code. Part 2 covers how to increase the speed limit. Let’s start by looking at why we have a choice about how fast to let a coding agent go.

You choose how fast the agent goes

Rapid code generation that exceeds human understanding is usually presented as inevitable. And dealing with it is an active research topic, with AI-assisted code review and better tooling as examples. But usually the generation rate is taken as given and work focuses on helping teams keep up.

In fact, the rate at which an agent can generate code isn’t the rate a team has to accept. Teams have control over the rate of code generation and the amount of cognitive debt they create. To understand why, let’s look at the metaphor of a fast car.

Why I don’t drive at my car’s top speed

This metaphor consists of the following elements:

• You are the driver.
• The car is the coding agent, together with the harness around it.
• The road is the code, and the socio-technical architecture.
• Speed is the rate at which code is generated and deployed.

Like a coding agent, my car is fast. According to the specs, it has a top speed of around 150 mph. But I don’t drive that fast. Let’s look at the three reasons why.

On many roads it isn’t safe

First, it’s often unsafe. I could injure or kill myself, or someone else. Rapidly generating code when understanding is required - core logic, novel design, etc. - means deploying code the team can’t reason about. That’s cognitive debt.

Speed limits

Second, traffic laws require me to observe the speed limit, typically 25 to 65 mph. I could ignore them, but I’d risk a ticket. With code there’s no highway patrol, but a team can choose its own limits: for example, that a team member must understand a change before it merges.

But the road ahead is jammed

Third, there’s congestion. The car’s top speed is irrelevant when the road is full. For instance, the average traffic speed in many major cities is under 15 mph!

As I describe in part 2, without the right architecture, a coding agent can generate more changes than the deployment pipeline can process. If the deployment pipeline is overwhelmed, faster code generation produces fewer successful deployments, not more.

But what about the Autobahn?

There are, of course, places where you can drive much faster. The Autobahn has stretches with no posted speed limit. But drivers are legally required to adjust their speed to the traffic, weather, visibility and road conditions. And there’s an advisory 130 km/h (81 mph) that can count against them in a liability claim if they crash above it.

The Autobahn is a safe road system for the following reasons:

• The permitted speed is matched to the conditions. Permanent limits where the road demands them, variable limits where conditions change, and unrestricted stretches only where the design allows.
• The road is engineered to support higher speeds safely. The surface, the shoulders, the banking, and the guardrails.
• Vehicles and drivers are held to a high standard. Demanding licensing, and mandatory periodic inspection of every car.

The unrestricted stretches are unrestricted because the conditions there allow it, and a limit appears on the same road on the same day when the conditions change. It’s a great example of matching the speed limit to the conditions.

And then there’s F1

Formula 1 might appear to be another example of how to go fast. The custom-designed cars are far faster and are driven at their limit. But the drivers are professionals with teams monitoring telemetry. Also, there are only two dozen circuits. The drivers know each one intimately and rehearse for hours on simulators before the race. Part of what makes the speed safe is that nothing about the track is a surprise.

But software development involves novelty. There’s no equivalent of simulator time or practice sessions before the race. In fact, if an application were sufficiently standardized, you’d be better off buying it than building it. So F1 isn’t a suitable metaphor for software development.

Understand the road, improve the road, improve the car

Now that we’ve explored the metaphor of a fast car, let’s return to the question of how fast to let a coding agent go. Three aspects of the Autobahn’s safety map onto three ways to work with a coding agent:

• Understand the road - determine the coding agent’s safe speed for each module of your application
• Improve the road - build the infrastructure that enables the coding agent to work safely at higher speed
• Improve the car - improve the agent and its harness.

Part 2 describes how to improve the road and the car. The rest of this article looks at how to understand the road.

Understand the road: how fast can you drive it?

Understanding the road tells you what speed is safe. It’s how you recognize a school zone or a winding mountain road and slow down before you get there. Similarly, the characteristics of the software determine the coding agent’s safe speed.

Here are some per-module characteristics that indicate the safe speed for a coding agent:

• DDD, core versus everything else. The core domain is a 25 mph zone. Supporting and generic subdomains are usually open road, and defining those subdomains is what tells you which is which.
• Hexagonal, domain versus adapters. Adapters and glue code are usually open road. The domain model rarely is.
• Coupling and testability. Loosely coupled, locally testable code is open road, because changes stay contained and fast tests catch mistakes. Tightly coupled, hard-to-test code is a 25 mph zone regardless of anything else.
• Cynefin: clear, complicated or complex. Clear and complicated work - well-established patterns the model has seen many times - allows speed, because a known good practice applies. Complex work, where novel architecture has no precedent, does not: you have to probe and learn, so slow down.

Two more characteristics apply to the application as a whole rather than to individual modules:

• Application scale and purpose. A throwaway prototype differs from a long-lived production system, and low blast radius differs from high.
• GenAI capability. How well represented is this work in the model’s training? A common stack allows speed. An obscure or bespoke one does not.

Together, those characteristics determine how much confidence you can have that the agent’s output will be correct. It is this confidence that sets the safe speed, as the diagram above illustrates. Where confidence is high, let the agent go faster. Where it’s low, slow down and review.

And a road trip is rarely all one kind of road. It might start on suburban streets, join the freeway for two hundred miles, climb a winding mountain pass, and finish in a school zone. The safe speed changes several times along the way, and a good driver adjusts each time.

An application is the same. The per-module characteristics vary from one module to the next, and so does the confidence they give you. The safe speed is therefore mostly a property of the module you’re changing, rather than a single number for the whole application. Implementing a single feature can involve modules with very different safe speeds, so expect to slow down and speed up as you go.

Summary

The road you’re on determines how fast you can drive: an Autobahn, a winding mountain road, a school zone, etc. Code is the same. The characteristics of the codebase and the team determine how fast you should let the agent generate code, and how much cognitive debt, if any, is acceptable. And just as a road trip covers several kinds of road, an application contains several kinds of code, each with its own safe speed.

But unlike a driver, who takes the road and the car as they are, you shape both. Part 2 covers how to raise the safe speed: improve the road, and improve the car.

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 →