AI Makes Big-Tech Engineering Practices a Small-Team Problem
What happens when AI coding agents actually work?
I don’t mean when they write a neat little function or save twenty minutes on a refactor. I mean when they materially increase the amount of software a team can produce.
The size of that effect is still unsettled, and it varies enormously by task and context. In one controlled experiment, developers using GitHub Copilot completed a specific coding task 55.8% faster. In a 2025 randomized field study, experienced open-source developers working in mature repositories were 19% slower with the AI tools available to them. Those results are a useful warning against pretending there is a universal multiplier.
The more defensible claim is narrower: wherever agents do increase implementation speed, they do not automatically accelerate review, testing, deployment, observability, or recovery. A small team can therefore create change faster than its engineering system can safely absorb it.
That is a problem large engineering organizations have spent decades learning to manage. AI may make it a small-team problem too.
The bottleneck moves
Think about the path a change takes through an engineering organization. Somebody has an idea. There is some kind of design. Someone implements it. The code gets reviewed, tests run, an artifact gets built, and eventually it gets deployed. After that, production telemetry tells you whether it actually works. If something goes wrong, the team has to detect it and recover.
Now suppose AI makes implementation much faster. The rest of the pipeline does not speed up merely because code arrived sooner.
It is like a restaurant where chopping vegetables has always been the slowest part of the kitchen. Then someone installs a machine that can chop ten thousand onions in a few seconds. The chopping problem is solved, but the kitchen still has the same stove, frying pans, and serving staff. The onions stop being the bottleneck and start piling up on the floor.
Software organizations can behave the same way. Pull-request volume rises. CI gets busy. Review queues grow. Engineers open large agent-generated diffs and skim changes they would once have tried to understand. More changes reach production, operational load rises, and incidents pull people away from planned work.
This is not just a thought experiment. DORA’s 2025 research found a positive relationship between AI adoption and delivery throughput, but also found that AI can amplify weaknesses in the delivery system, with delivery stability remaining a concern. GitHub reported on March 5, 2026 that Copilot code review accounted for more than one in five code reviews on GitHub. In May, GitHub described agent pull requests as saturating review bandwidth.
That is why I find it useful to distinguish change-generation capacity from engineering capacity. AI may increase the first without doing much for the second. Engineering capacity is the organization’s ability to ingest a change, verify it, understand its consequences, expose it to customers, detect when it is wrong, and recover without creating more damage than the change was worth.
Your real capacity is not how quickly you can generate code. It is how quickly your organization can safely absorb useful change.
We have seen this problem before
The encouraging part is that the underlying engineering problem is not new. Large engineering organizations have built systems that let many people change shared software continuously without relying on every person to remember every rule.
For a small team, those systems have historically looked excessive. Sophisticated CI, automated policy enforcement, progressive delivery, architectural controls, observability, and fault isolation seem natural at the scale of Google or Amazon and extravagant at the scale of a startup.
AI changes the relevant variable. Headcount still matters, but so do the rate, size, and consequence of the changes a team produces. A small organization can remain small on the org chart while putting pressure on its review and delivery systems that used to appear only at a larger scale.
That does not mean copying Big Tech bureaucracy. A thirty-person startup does not need a change-approval board where twelve people meet every Thursday to decide whether a bug fix may ship.
In fact, DORA’s research on change approval points in the opposite direction. Heavy external approval processes tend to reduce software-delivery performance, and DORA found no evidence that more formal external review was associated with lower change-failure rates.
The useful part of the Big Tech model is the control system underneath it: peer review, continuous integration, fast tests, observability, automated policy, progressive delivery, architectural boundaries, and more scrutiny where the consequences justify it.
There is a large difference between requiring a manager to inspect a spreadsheet and enforcing the same security policy when a change is proposed. If a dependency violates policy, infrastructure can reject the change. There is no meeting, debate, or queue.
The goal should not be to add process because the team is moving faster. It should be to remove entire categories of things humans have to worry about.
Make mistakes harder to create
My hypothesis is that architecture becomes more important as agents write more code, not less. Every strong boundary removes a decision that a person or an agent has to get right. DORA’s 2025 findings offer some support for that direction: teams with loosely coupled architectures and fast feedback loops appear better positioned to benefit from AI. They do not prove that better AI inevitably increases the value of architecture, but they reinforce the mechanism.
The analogy I like is bumper bowling. If you want to stop a child from throwing the ball into the gutter, you can stand behind them repeating instructions: keep your wrist straight, aim for the middle, take the right number of steps, do not release too early. Or you can put the bumpers up.
The first approach depends on someone remembering and following the instructions every time. The second changes the environment so that an entire class of failure becomes difficult or impossible.
Many software standards still rely on the first approach. If a service must not connect directly to a database, you can write the rule in a wiki and ask every engineer and agent to remember it. Or you can make network policy prevent the connection. It does not matter how confidently an agent writes code that tries to reach the database; the environment rejects the path.
The same idea applies to validation. You can keep telling developers and agents to validate a value before using it, or design an API so that a sensitive operation accepts only a value that has already been validated. Raw input no longer fits through the interface.
Authorization works the same way. You can remind everyone to be careful with permissions, or design the authorization model so that bypassing it requires something conspicuously abnormal.
The strongest engineering standards are not instructions people remember. They are properties of the system people inherit. The standard stops being a page in the company wiki and becomes something closer to a law of physics inside the engineering environment.
That matters when some of the actors changing the system are AI agents.
Assume something will still get through
No architecture, test suite, or static analyzer will prevent every defect. Eventually an agent will write something logically wrong in a way the tools do not understand. A test will miss an edge case. A production dependency will behave differently from the simulated version.
So the next question is: when something is wrong, how wrong are you allowing it to be?
This is where blast radius matters. AWS describes cell-based architecture as a way to isolate faults so that a bug, bad deployment, or overload event affects a bounded part of the system instead of everybody at once.
Think of the watertight compartments in a submarine. The goal is not to guarantee that the hull can never be breached. It is to make sure one breach does not sink the vessel.
A thirty-person startup probably does not need to reproduce Amazon’s architecture. The principle still travels well: limit permissions, avoid unnecessary global state, partition critical workloads where it makes sense, place risky behavior behind feature flags, use quotas and rate limits, separate control planes from the systems doing the work, and make dependencies explicit.
The same thinking should apply to agents. An agent that can modify application code probably should not also have unilateral authority to modify the CI system evaluating that code, weaken tests, expand its own permissions, and deploy directly to production.
Otherwise the same actor gets to write the exam, take the exam, and grade it.
This is not an AI-specific discovery. It is an application of separation of duties and least privilege. The actor proposing a change should not also get to redefine what counts as safe.
Let machines do machine review
When agents can produce code faster than people can inspect it, human attention becomes one of the most expensive resources in the system. It makes little sense to spend that attention answering questions a computer can determine reliably.
Does it compile? Do the tests pass? Did an API contract change? Is a migration backwards compatible? Did dependency risk increase? Did permissions expand? Did the change cross an architectural boundary? Did test coverage fall? Did someone modify the CI system itself?
If there is a deterministic answer, the engineering system should usually answer it before a human reviewer opens the pull request.
Google has built presubmit systems around this idea for years. Its published guidance describes automated formatting, static analysis, tests, and project-specific checks running before code lands. The value is not only finding bugs. It is preserving reviewer attention for work that requires judgment.
There is another bottleneck hiding here: the feedback has to be fast. A comprehensive test suite is not enough if every small change waits forty-five minutes for the first useful signal. The bottleneck has merely moved from human review to compute.
Google’s CI guidance recommends fast, reliable presubmit tests and broader validation later. That is the right shape for an agentic workflow too: cheap, high-signal checks first; more expensive evidence when the risk warrants it.
The goal is not maximal verification everywhere. It is fast, trustworthy evidence at the point where a decision must be made.
Human review moves up the stack
AI does not have to eliminate human review. It can change what human review is for.
If machines have already handled formatting, known static errors, test failures, dependency policies, and architecture checks, reviewers can focus on questions that require understanding the system.
Get Owen Zanzal’s stories in your inbox
Join Medium for free to get updates from this writer.
Does the implementation solve the user’s problem, or is it merely functional? Are we creating a second abstraction for something that already exists? What happens under concurrency? Is the authorization model correct? What assumptions are we making about production data? What happens if a dependency disappears for ten minutes? Can the migration be reversed? Is this still the architecture we want six months from now?
Those are questions about semantics, tradeoffs, history, intent, and failure modes. They are better uses of human judgment.
They are also easier to answer when the change is small. Google’s review guidance says small changes are reviewed faster and more thoroughly, are easier to reason about, and are easier to roll back. There is no universal line-count threshold, but the direction is clear: as a diff grows beyond a reviewer’s cognitive budget, review becomes more likely to degrade into skimming and ceremony.
That should influence how we evaluate agents. The most impressive demo is often an agent that disappears for an hour and returns with an entire feature. The more useful engineering behavior may be an agent that advances the work through small, independently understandable, independently verifiable changes.
The optimization target should not be “complete as much of the task as possible without involving a human.” It should be “advance the task through the largest change that can still be independently understood and verified.”
That is a different definition of autonomy.
Production is part of the test
Eventually every team encounters the same uncomfortable truth: the test environment is not production.
You can simulate a great deal, but some things appear only when real traffic, data, dependencies, timing, and users touch a change. Mature delivery systems do not treat that as surprising. They control exposure.
A new version might reach internal users first, then a small percentage of customers, then progressively larger groups. Google SRE describes canarying as evaluating a partial production deployment before continuing the rollout.
In that sense, deployment is not the moment testing stops. It is testing against reality under controlled exposure.
Feature flags create another useful separation: deploying code and releasing behavior do not have to be the same event. A team can deploy an implementation while leaving the behavior disabled, then enable it when the people who understand the system are available and watching.
That changes the psychology of deployment. Instead of pushing something and hoping, you deliberately expose behavior, watch the evidence, and increase exposure when the evidence looks good.
Deployment becomes a controlled experiment, and every experiment needs an escape hatch.
Rollback should be boring. If deploying is fast but recovery requires hours of coordinated manual work, the system does not have meaningful delivery velocity. AWS’s reliability guidance recommends automated testing and rollback precisely to reduce recovery time and customer impact.
Every newly discovered failure mode should improve that machinery for future deployments. This feedback loop matters even more when agents increase the rate of change.
Turn failures into infrastructure
Something will still break. One of the clearest differences between mature and immature engineering systems is what happens next.
The immature question is, “Who broke production?” The mature question is, “Why was this failure possible?”
Why did we not detect it earlier? Why could it affect this many users? Why did recovery take this long? Why did review allow it? Why did the canary miss it? What could make the same class of failure harder to produce next time?
That is the point of blameless postmortems in SRE: focus on gaps in the system rather than individual blame, then produce verifiable actions that prevent or mitigate recurrence.
Suppose an agent introduces an authorization bug. Fixing the bug is necessary, but it may be the least durable response.
Can the incident become a regression test? Could it become a static-analysis rule? Should the API make the invalid state impossible? Is a stronger permission boundary needed? Should every service use a shared library? Should CI detect the pattern? Could the canary have caught it sooner? Was operational context missing from what the agent knew?
Each move takes knowledge that existed in someone’s head after an incident and turns it into something the system can enforce next time. The lesson leaves human memory and enters the machinery.
I think of that as systemic immunity. The term is a metaphor, not an industry metric, but the underlying practice is concrete: a mature organization does not merely recover from incidents. It modifies the environment that produces future changes.
Build the paved road
These ideas converge on the paved road: the safe way to build software should also be the easiest way.
Creating a service should not require remembering fifteen separate rules about observability, ownership, CI, deployment policy, security defaults, rollback, and dashboards. The template should provide them.
Open a pull request and the appropriate verification should run automatically. Make a risky change and the rollout should become more conservative. Touch authentication or infrastructure and the right reviewer should be requested. Create a service and its logging, telemetry, ownership metadata, deployment configuration, security defaults, and rollback machinery should already exist.
This is established platform-engineering practice. Google describes golden paths, guardrails, and safety nets as ways to make the preferred choice easy while enforcing non-negotiable constraints.
The same idea should extend to agents. An agent should receive canonical information about APIs, service ownership, allowed dependencies, operational constraints, architecture, and SLOs. That is a design recommendation rather than a proven optimal implementation, but it follows the same principle: important context should live in the environment, not in thirty lines copied into every prompt.
Small AI-native teams may end up investing heavily in this layer. They will not be recreating Big Tech bureaucracy. They will be recreating the leverage of its engineering control systems.
The platform becomes part of the team. Its job is to make the correct path fast, the dangerous path difficult, and the invalid path impossible.
Once generating code gets cheaper, everything around the code matters more.
The engineer may become an orchestrator
One plausible consequence is that the shape of engineering work changes.
If agents perform more mechanical implementation, productive engineers may become less defined by how much logic they personally type. More of the job becomes orchestration: deciding what work agents should do, how to decompose it, what context they need, what constraints the environment should enforce, what evidence is required, where human judgment adds value, how much production exposure a change should receive, and what the system should learn from failure.
This is a forecast, not an established end state. AI adoption is already changing workflows, but there is not yet evidence that “engineer as orchestrator” will become the dominant role everywhere.
If it does, engineering does not become less technical. Technical judgment moves toward the level of systems.
The valuable engineer is no longer only the person who can produce an implementation. It is also the person who can build an environment in which implementations can be generated, verified, deployed, observed, and corrected at high velocity.
That is a different kind of leverage.
So what does velocity mean now?
Some familiar engineering metrics look especially weak in this environment. Lines of code were never a useful proxy for value, and they become nearly meaningless when an agent can generate thousands on demand. Pull-request counts and the percentage of a codebase written by AI say little about whether customers received a useful, reliable change.
Those metrics tell you how fast the robotic chef is chopping onions. They do not tell you whether the kitchen can serve dinner.
DORA’s current delivery metrics offer a better foundation: change lead time, deployment frequency, failed-deployment recovery time, change failure rate, and deployment rework rate. For AI-heavy workflows, I would also watch reliability, the human-review cost per successful production change, the size of changes people are expected to understand, customer impact from failures, and the time required to turn a new failure mode into a durable guardrail.
Some of those additions are proposals, not validated industry standards. But together they capture the outcome that matters better than code volume does.
I call that outcome risk-adjusted change throughput. It is not a standard DORA metric or a finished formula. It is a name for the quantity an engineering organization is really trying to improve: the rate at which it can deliver useful change, discounted by the human cost, operational risk, and customer harm involved.
That is why practices once associated with very large organizations may become small-team concerns. Large organizations built delivery controls because many people were changing shared systems at once. Agents can create similar pressure without a corresponding increase in headcount.
The magnitude will vary. A small team will not automatically operate like an organization five or fifty times its size. But if its change-generation capacity rises faster than its delivery capacity, the response should not be bureaucratic throttling. It should be a better system for absorbing change.
Generating enormous amounts of code is not the interesting capability. Safely shipping large amounts of useful change is.
There is one further, more speculative question. Today, humans usually investigate incidents, write postmortems, and decide which regression test, deployment rule, or security boundary should be added. Agents are beginning to assist with telemetry analysis and root-cause diagnosis. It is conceivable that an agent which contributed to a failure could also propose a guardrail against its recurrence.
That is not yet a reliable closed loop, and machine-generated safety systems are not evolving at anything like the demonstrated rate of machine-generated code. But if they eventually do, a new problem appears. A paved road made from constantly changing, machine-generated policies, tests, and architectural constraints could become difficult for humans to understand.
The system still needs accountable people who know why the road looks the way it does.
Otherwise we may solve the problem of safely absorbing machine-generated code by creating safety machinery that nobody can meaningfully reason about — which feels like exactly the kind of problem we will discover once the current one starts working.
