Engineering Sustainable Speed

How a team keeps agent speed useful after the first fast build.

The chapters so far have shown how a team goes faster with agents while keeping quality: protecting team comprehension, planning before building, reviewing continuously. This chapter is about the work that compounds the speed. Part of it protects the pace the team already has, so the gains from the first fast build hold as the codebase grows. The rest expands what the team can safely delegate, so delivery keeps getting faster as the project matures.

Watch the difference play out across two teams that adopt agents the same quarter. Both see the same early result: work that took a week now takes a day or two. Six months later, one team still moves at that pace and can still reason about what it has built. The other is slower than when it started, buried in code nobody fully understands, re-explaining the same corrections every session, waiting on a person every time the agent can't check its own work. Both bought the same ability. Only one kept it.

What separated them is where they spent the time the early speed-ups saved. The first team put some of it back into the system that produces the speed: layered tests and review agents that catch what a person could miss in the high volume of agent output, a harness that lets an agent finish a task and verify its own work, an architecture kept solid enough that every session builds in the same direction, and a habit of turning each recurring mistake into a check the system runs from then on. The second team spent all of it on new features and let the rest erode.

That reinvestment is Compounding Work, and it's the highest-leverage work on a project. It is the mirror image of technical debt: debt is a shortcut that gets more expensive over time, and Compounding Work is an improvement that keeps paying back. Agents amplify both. Leave a shortcut standing and agents spread it through the codebase faster than a team ever could. Make an improvement and every later delegation builds on it. And because agents do most of the improvement work themselves, the investment is cheap to make and the returns show up sooner. That trade, made or skipped iteration after iteration, is what separated the two teams above.

Work like this used to be filed under developer experience (DevEx), where the cost could be hard to justify. Agents change that math, and open new opportunities that didn't exist before, which is why it gets a chapter of its own. Three investments make up that work: the quality checks an agent runs to catch its own mistakes, the harness that gives it the context and tools to keep working on its own, and the design decisions only a person can make about the shape of the system. A final section names the signs that one of them has fallen behind.

Quality pyramid

Every layer of quality in this process is a feedback loop that tells the team, and the agent, whether the code does what it should. The pyramid orders those loops by cost. The base covers every line and runs for free on every change. Each layer up is narrower and more expensive, until the apex, where human judgment does what no check can. The aim is to push as much as possible down into the cheap, automatic layers, so attention goes only where a person is actually needed.

The shape predates agents. What changed is what a missing layer costs. Skipping a check used to trade against manual testing: someone would catch the miss eventually. Now the same gap stops autonomous work, because the agent can't verify that part of its own output and has to wait for a person. Automating a check used to save review effort; now it buys the agent room to keep working. Agents also changed what can be automated. They raise the floor on the middle and upper layers that used to need a person, running system-level checks, code review, and specialized design critique before human judgment gets involved.

Checks the agent runs while building

The bottom layers are the feedback an agent reads while it works. The agent should practice test-driven development and add regression tests as it goes, so building the system and building the checks that measure it happen together. With a solid test suite underneath, the agent can run much longer on its own, iterating until the task is done without breaking something else along the way.

Checks that used to be too expensive

Agile in the age of agents changes the cost-benefit of system-level checks. A check that was too expensive to build for a human reviewer is cheap when an agent runs it hundreds of times. Agents lack the holistic judgment a person brings to review, so the team closes that gap with new automated checks. A visual regression test flags unintended UI changes against a stored baseline. A schema check proves an API contract holds end to end. A migration test runs the rollback. Each one used to be a judgment call someone made by eye, or skipped. Built as a check, it runs on every change and never gets tired.

Review that used to need a person

Passing checks are only part of the story. Code review is still a bottleneck, and here, too, agents help. Code review agents catch bugs and, with tuning, enforce architecture rules and style conventions. They give the code a first pass that improves it before a human reviewer sees it, and they often find problems a person would miss.

Senior judgment can't be fully automated. But on any project a senior engineer checks the same concerns again and again, including non-functional requirements like performance and security, and the design decisions that have to fit the rest of the system. A specialized review agent runs a team-crafted prompt for one of those concerns, on demand or in CI. Any pattern an engineer keeps having to check can become an agent that checks it first. What's left at the apex is the work no agent can stand in for, the lateral thinking, taste, and judgment that come from context an agent doesn't have.

Harness engineering

A coding model is general-purpose, and every conversation it has starts from a blank slate, with only the prompt and the files it reads along the way to go on. Give the model a task and it does something reasonable, but without the team's context it sometimes does the wrong reasonable thing, and someone catches it later. Harness engineering shapes that environment, so the agent comes in with more than it can infer on its own. It works in two ways.

• Guidance: what the agent knows about the system and how the team works.
• Tools: what the agent can do, beyond the capabilities it starts with.

Guidance

When people wrote all the code, teams ran on tacit, tribal knowledge, the kind picked up in conversation and over years on a project. An agent doesn't pick any of that up. The knowledge the agent needs has to be written down and put in front of it while it's working.

• The Knowledge Base holds design and product intent.
• Code comments carry the rationale behind a specific implementation, so an agent working there understands why, not only what.
• Agent Skills package step-by-step instructions for specific tasks.
• AGENTS.md gives every coding agent the same top-level guidance for working in the system.

This is where most of the improvement happens. Each time an agent gets something wrong, needs a concept re-explained, or repeats a manual task, the team writes the answer into one of these places, so the next agent starts with it. Sometimes that's a procedure or a rule. Sometimes it's making something the team already wrote easier to find at the right moment.

This pays off well beyond code. Because Definition is usually the bottleneck on a project, a harness that speeds up definition work can be worth more than another gain in implementation speed.

Tools

An agent isn't limited to the capabilities it ships with. The team can build it new ones, tools that run a precise, repeatable task or take an action the agent otherwise couldn't. The quality pyramid was one case of this, since a test is a tool the agent runs to check its own work. The same idea reaches much further.

Increasing autonomy: An agent gets stuck when a task needs an action it can't take. Out of the box it usually can't see the UI it just built, so a person has to notice the visual bug and point it out. Give the agent the Figma file, a visual component harness to render the component in different states, and browser automation, and the agent can check its own work against the design and fix it before anyone looks.

Increasing reliability: Agents follow instructions better every month, but they're fuzzy by nature. When a task has exactly one right way to run, code beats an agent at it, producing the same result every time, faster and cheaper. Wrap a task like deployment or schema validation in a tool, tell the agent when to reach for it, and that step stops being a place where things go wrong.

Increasing versatility: Coding agents are built for code, but a project needs more than code. Take a production incident. Normally a person pulls the logs, gathers the telemetry, and hands it all to the agent. Give the agent its own way to search logs and watch service health, and it can work the incident itself instead of waiting to be fed.

Orchestrating parallel work

The harness pays off one more way. Everything up to now improves a single delegation: one agent on one task, with a person reviewing the result. A rich enough harness raises the ceiling on that. A single agent tops out at what it can hold in one context and how far it can build in one continuous run without losing the plot. When the harness gives agents the context and tools to work on their own, and the checks let them confirm their own results, a developer can point a team of agents at a build no single agent could accomplish, like a refactor that cuts across the system or a feature that spans the whole stack. Each agent owns a piece of the same plan and runs the same checks, the pieces recombine into one change, and the developer reviews the assembled result. The developer's job shifts up a level of abstraction, from prompting agents to building workflows that organize and prompt teams of agents.

When the conditions are right, this is higher-leverage than any single speed-up in this chapter, because it multiplies the work in flight rather than making one stream of it faster. Those conditions are demanding. The Compounding Work this chapter has already described is a necessary baseline. Orchestration works best when the goal is engineering-heavy and the checks are objective: migrate an API, run a broad refactor, update a component family. It is a poor fit when the work depends on unsettled product rules or domain calls. Where those conditions hold, a week of sequential delegation can collapse into a day. Where they don't, pushing orchestration past its limits just multiplies work that never fits together, and keeping a person closer to the work is faster.

For a given build, a developer finds the edge of what orchestration can handle by working up to it. They run a small piece of the build first, watch where the agents go wrong, and strengthen the harness against what broke, whether that's a missing check or an instruction the agents kept ignoring. Once a run comes back clean, they widen the scope. Some early passes exist mainly to be thrown away: build a version, study where it falls short, and rebuild with the plan and the harness tightened. Each pass either widens what the agents can take on or shows the harness still isn't ready.

So orchestration sits at the top of the same hill the rest of the chapter climbs: the better the checks, the harness, and the design underneath, the more of a build a developer can run at once. None of that relaxes their ownership of the result. A larger build still has to be understood and validated by the person who directed it, the same obligation as a single delegation, now spread across more code. That makes comprehension the real ceiling on how far this scales: a developer can launch many agents but can only merge a build they can still stand behind and explain.

Knowing when to slow down

Most of this chapter is about going faster. This section is about the moments when the fastest move is to slow down: pull the hard part back from the agents, put people on the design, and scale delegation back up once the structure is sound. The signs that a moment like that has arrived are familiar. The same workarounds keep piling up. Every change touches more than it should. Nobody can hold the current shape of the system in their head. The clearest case is new ground with no pattern to follow yet, like a new project or a refactor that changes how the system is layered.

Those signs point at the design quality of the system itself, which every later change either rides on or fights. It's the oldest form of Compounding Work, and the one an agent won't produce on its own. Good design is a bet a person makes against their own future effort: a simpler structure, a data model where invalid states can't arise, abstractions that compose so the next problem is easier than the last. Each bet costs effort now to save more later. People make them because they're the ones who would otherwise pay; the incentive is their own finite time and attention. An agent has none of that. Work costs it nothing, so it has no reason to invest ahead. It solves the problem in front of it and moves on. Point it at enough problems and you get a system that works and is costly to change.

Protecting that quality is part of protecting speed, because a system that's expensive to change is slow no matter how fast the agent works. And unlike the checks and the harness, this investment never stays made; it's the team's call, and leadership's in particular, to notice when throughput mode is making the system worse and to spend time on the design instead. Spending it means stepping out of scaled delegation and putting human capacity back on the hard parts. The team gathers context, weighs structural options, settles the constraints, and writes down enough direction for agents to follow. Sometimes that's one developer spending part of an iteration on architecture instead of features. Sometimes it's most of the team. It's the same work Definition does, turned inward at the system. Architectural uncertainty is definition work.

What that work looks like

Seed the structure deliberately. Before delegating at scale, the lead developer or the team makes explicit choices about layering, module boundaries, interface design, and the key abstractions. Write the foundational code by hand to force those decisions. A few well-considered examples set the pattern agents follow for the rest of the project.

Mob program around the key decisions. Getting the whole team writing and reading the same code together is one of the fastest ways to build shared architectural intuition.

Spike, iterate, then commit. An agent can spike a structural approach quickly. Treat that spike as a draft to argue with. Reshape it, and make sure the team understands and agrees with the structure before building on it.

Once the structure is sound and the team can answer "does this match how we've agreed to build this system?", scaled delegation takes over again and the planning checks keep it on track.

Addressing development failure modes

Development fails in recognizable patterns once agent output gets ahead of quality signals, planning, architecture, or team comprehension. The signals below are ordered by priority, because earlier signals affect the later ones. Work the list top-down: don't chase volume outpacing comprehension at the bottom of the list while quality checks are weak at the top. Earlier signals are more fundamental, and fixing them often resolves the later ones.