How We Ship Continuously Without the Coordination Tax

Ask most people how a team ships more software and they will tell you the developers learned to write code faster. It is the wrong answer. We deploy to production continuously now, many times a day across teams, and the volume keeps climbing, but almost none of that came from anyone’s fingers moving quicker. A couple of years ago, shipping a feature that touched more than one service at LegalZoom meant scheduling a small project: two or three engineers, each fluent in a different codebase, a scoping cycle to agree on interfaces, a second cycle to align timelines, then a sequence of handoffs where context leaked and latency piled up. The hard part was almost never the code. It was the coordination. What changed was that we deleted the coordination tax, and the velocity followed.

Myth: the bottleneck is how fast people type

The real bottleneck was handoffs. As our product surface grew, more and more features stopped living inside a single repo. A change to how a business formation order moves through fulfillment might touch a web client, an orchestration layer, and a downstream service. Under the old model, that meant assembling a group of people whose combined tribal knowledge spanned all of those systems.

That created two compounding problems. Every handoff added serialized latency. You waited for the person who “owned” a system to have capacity, then waited again for the review, then again for the next system in the chain. And tribal knowledge was a gate. If you didn’t already know a codebase’s quirks, you couldn’t safely change it, so the same few people became bottlenecks for the same few systems.

The naive fix is to ask everyone to learn everything. That doesn’t scale, and it doesn’t survive turnover. We wanted something more durable: a way for one engineer to safely drive a cross-codebase feature end to end, without first spending a quarter becoming an expert in each system they touched. Typing speed was never going to move that number. Removing the people from the critical path would.

Myth: more hands make a feature safer

In practice, more hands made it slower and leakier. So we reshaped the SDLC around a single accountable owner, and made the pipeline absorb the toil.

The model is deliberately simple. One developer drives a feature end to end, paired with an AI coding assistant. One human reviewer, also paired with AI, provides judgment and accountability. The same developer closes the loop from customer feedback back into code. Fewer people in the critical path means fewer handoffs, and fewer handoffs means less serialized waiting.

What makes this safe is where we put the knowledge. Instead of relying on what lives in a senior engineer’s head, our most experienced engineers now invest their time building reusable AI harnesses rather than hand-coding every feature themselves. These harnesses carry repo context packs, a knowledge graph of how systems relate, and cross-service impact analysis. When an engineer opens an unfamiliar codebase, the harness supplies the context that used to require a hallway conversation: what this service owns, what calls it, what breaks downstream if you change this contract. Tribal knowledge becomes infrastructure.

The delivery pipeline underneath is trunk-based and continuously deployed, with no manual promotion gate between environments:

feature branch
   -> pull request (requires approval)
       - unit + integration tests
       - lint / static analysis
       - security scanning
       - AI review (the moment the PR opens)
   -> merge to trunk            # PR approval is the authorization gate
   -> auto-deploy to Dev + QA
   -> smoke tests               # gate promotion
   -> auto-deploy to Production
   -> health-monitor bake period
       - on failure -> automatic rollback

The key design decision: PR approval is the authorization gate. Once a human approves and merges, the rest is deterministic CD execution. There’s no separate “promote to prod” button for someone to forget to press or to press at the wrong time. The trade-off is that the gates have to be genuinely trustworthy, because nothing downstream is going to catch a mistake they let through. Single-owner delivery puts a lot on one person, which is exactly why the harnesses and the AI review matter. They are what make the owner not actually alone.

Myth: machine-written code needs a lighter touch

We do the opposite. AI reviews every pull request the moment it opens. The workflow checks out both the target repo and our internal PR-review tooling, runs a multi-layer pipeline that combines the coding assistant with repo context and risk analysis, and posts comments back to GitHub automatically. A human reviewer still owns the merge decision. The AI just makes sure the human is reviewing a PR that has already been checked for the obvious and the not-so-obvious.

This applies uniformly whether the PR was written by a person, written with AI assistance, or opened autonomously by an agent. We don’t have a separate, looser path for machine-authored code. The same review bar, the same gates, the same audit trail. We want a reviewed change to be able to reach production the same day rather than across days, and the only way that’s responsible is if review quality doesn’t degrade as volume climbs.

Myth: shipping faster means shipping riskier

It is the reverse here, and tests and observability are why. You cannot deploy continuously on manual UAT, so we stopped doing most of it. Testing agents generate unit, integration, and end-to-end tests, run regressions continuously, and surface edge cases that a human writing tests under deadline tends to miss. The effect on feedback loops is concrete: automated test runs that used to take many minutes now complete in seconds.

We hold a real production-readiness bar in CI. A high coverage bar on core business logic, automated coverage for key use cases, and observability gaps flagged during readiness audits before a change is considered shippable.

That last point is the one we’d underline. Observability is generated, not bolted on afterward. Our definition of done now includes enabled monitoring, dashboards, alerts, and logging. Monitors and health checks are produced automatically as part of building the feature, which is what lets the post-deploy bake period actually mean something: if generated health monitors trip during the bake window, the pipeline rolls back on its own. High deploy frequency is safer this way precisely because every change arrives already wired to detect its own failures. Trunk-based CD with no manual promotion gate concentrates all your risk into the quality of your automated gates. If your tests are flaky or your monitors are noisy, that pain shows up immediately and constantly, so you’re forced to keep them honest.

What the payoff actually looks like

Consider a concrete case. We had an order-injection path that took several minutes to run. It spanned multiple orchestration repos and multiple stacks, with ownership spread thin enough that no single person could confidently explain the whole thing. We collapsed it into a single API call into one fulfillment service with clear boundaries and real observability. It now injects in under two seconds. The latency win is nice. The ownership win is the point: one service, one owner, one clear contract.

On the operations side, an autonomous root-cause-analysis agent now triages production errors. It queries observability data, correlates against recent deploys and PRs, identifies a likely root cause, and can open a draft fix PR routed through CODEOWNERS for a human to approve. It has already surfaced a real bug. Related support agents read a stuck order, pinpoint the step it’s wedged on, and post a root-cause summary onto the ticket. The pattern is consistent. Agents do the gathering and the first draft. Humans keep the judgment and the approval.

So when people reach for “AI writes more code,” they have picked the least interesting version of this story. The leverage came from letting AI absorb the connective tissue: the planning, the review, the test generation, the monitoring, the incident triage, while humans kept the parts that require accountability. Velocity turned out to be an outcome of removing handoffs, never a goal we chased directly.

Where we’re headed keeps that throughline. More specialized review agents focused on architecture, compliance, security, and observability, with audit trails for autonomous changes, and per-PR ephemeral preview environments so Product and QA can exercise a change before it ever merges. Push durable knowledge into shared tooling, keep one accountable owner per change, and make the pipeline prove a change is safe before it reaches a customer. Continuous deployment is the visible result. Deleting the coordination tax is the actual work.