Synthesia AI Code Review Reveals the Cost of Faster Generation
Synthesia AI code review is exposing a sharp conflict despite a 120 percent rise in pull requests: generating code faster does not eliminate engineering work. It moves that work downstream.
Synthesia says 95 percent of its pull requests now contain AI-generated code. Yet fewer than 5 percent of changes bypass human review. Those numbers capture the emerging problem for engineering organizations adopting coding agents at scale.
The new bottleneck is no longer typing code. It is determining whether generated code reflects the intended design, fits the existing system, handles unusual conditions, and remains safe after deployment.
This change pressures engineering leaders to redesign the entire review process. Amazon, AWS, Bonterra, IBM, Making Sense, and Temporal are testing variations of the same idea. Automation should handle routine inspection, while people retain authority over consequential decisions.
That division sounds efficient. It also creates a difficult question. If an AI system writes the code and another AI system reviews it, what evidence lets the responsible engineer trust either one?
Synthesia AI Code Review Reveals the New Bottleneck
AI-generated code has increased production capacity faster than companies have increased their capacity to verify it.
Synthesia’s 118 engineers adopted AI coding tools across their workflow in November 2025. By August 2026, pull requests had increased 120 percent from the previous year, according to CTO Peter Hill.
A pull request is a proposed change that another engineer or automated system examines before it joins the main codebase. More pull requests can indicate higher output, but each request also creates testing, review, coordination, and maintenance work.
The changes at Synthesia were not simply small suggestions completed by an autocomplete tool. Hill told the original account that 95 percent of the company’s pull requests contained AI-generated code.
That volume revealed recurring weaknesses. A coding agent may create a function without recognizing that the same capability already exists elsewhere in the repository. Limited context then turns one implementation into several competing versions.
Synthesia has reportedly found as many as 10 versions of the same function. Engineers must locate the duplication, decide which implementation belongs in the product, remove the others, and teach the agent not to repeat the mistake.
Each generated function can look reasonable when viewed alone. The defect only becomes obvious when someone understands the wider system. That distinction explains why code that passes a superficial inspection can still increase technical debt.
Technical debt is future engineering work created by shortcuts, unnecessary complexity, or weak design choices in current software. AI does not need to generate broken syntax to create it. The model only needs to produce locally plausible code that conflicts with the larger architecture.
Hill described obtaining the intended output at company scale as an enormous amount of work. He also questioned whether teams will ever completely trust agent-generated code.
That skepticism has not stopped Synthesia from using coding agents. Instead, the company directs human attention according to risk. A change to an error message receives less scrutiny than a change involving customer data or core business rules.
Even with that triage, more than 95 percent of changes still receive human review. The company is gaining generation capacity while preserving human gates around most deployments.
The same tension appears across the industry. Sonar surveyed more than 1,100 professional developers and found that respondents attributed 42 percent of committed code to AI.
However, 96 percent did not fully trust AI-generated code to work correctly. Only 48 percent said they always verified AI-assisted code before committing it, according to the developer survey.
The gap between distrust and consistent verification matters more than the raw adoption number. It suggests that some organizations are producing generated code faster than their controls can evaluate it.
Thirty-eight percent of respondents said AI-generated code required more review effort than code written by colleagues. Sixty-one percent said generated code often appeared correct while remaining unreliable.
Those findings do not establish that every AI-generated change is worse. Sonar sells code-verification products, and its survey reflects reported experiences rather than controlled production measurements.
Still, the numbers align with the operational accounts from Synthesia and other companies. Code generation has accelerated, but confidence has not accelerated at the same rate.
Faster Coding Moves Work Downstream
The productivity promise weakens when organizations measure generated code instead of reliable software reaching users.
A coding agent can create thousands of lines within minutes. Line count, however, says little about whether the change should exist, integrates correctly, or solves the requested problem.
Amazon encountered this distinction while modernizing 17 years of code behind its mobile shopping application. Senior principal engineer McLaren Stanley works with a 70-person team that supports more than 1,000 developers.
Stanley described an agent generating 25,000 lines in the wrong version of Swift, Apple’s programming language. Converting the output created 600 errors that the agent could not resolve together.
The team discarded the generated code instead of repairing it line by line. Stanley updated the specification, which is a detailed plan defining what the agent should build and how it should behave.
After that correction, the agent reportedly regenerated the code correctly within 15 minutes. The episode shows both sides of the productivity argument.
The agent recovered faster than a person could rewrite 25,000 lines. Yet it first produced a large, unusable change because one important constraint was missing.
Generation speed amplified the quality of the plan. An incomplete specification produced failure at unusual scale. A corrected specification produced a usable result quickly.
This relationship changes where senior engineers spend their time. They must define architecture, constraints, interfaces, acceptance criteria, and prohibited behavior before an agent begins implementation.
The work shifts from expressing every instruction in programming syntax toward constructing and defending an executable plan. That is still software engineering, even when fewer keystrokes appear in the editor.
Independent evidence on overall productivity remains mixed. A 2025 METR randomized trial studied 16 experienced open-source developers completing 246 tasks in repositories they knew well.
Those developers took 19 percent longer when early-2025 AI tools were available, according to the productivity trial. Before participating, they expected AI to make them 24 percent faster.
Afterward, they still believed AI had accelerated their work by about 20 percent. The measured result pointed in the opposite direction.
The study was small and focused on experienced developers working inside familiar, mature repositories. METR explicitly warned against applying its result to every developer, tool, or programming environment.
Developers working in unfamiliar systems may receive more value from AI explanations and repository navigation. Newer models and better agent workflows can also change the result.
METR acknowledged that later tools likely offer greater benefits. Its study remains valuable because it separates perceived speed from measured completion time.
A developer can feel faster while watching an agent produce visible output. Prompting and reviewing may also feel less tiring than manually implementing the same change.
Neither sensation guarantees that a correct change reaches production sooner. Time spent waiting, correcting misunderstandings, reading generated output, and cleaning up unnecessary code still counts.
A newer enterprise field study offers a more optimistic result with an important qualification. Researchers examined 802 developers and 196,212 pull requests from January 2024 through April 2026.
Per-developer throughput eventually reached 2.09 times the pre-adoption baseline at the studied company. The researchers cautioned that adoption was not randomly assigned, so they could not attribute the entire gain directly to AI.
More importantly, the organization’s review system changed with production. The load per reviewer roughly doubled, and automated review overtook human review. Merge and revert rates remained steady.
That evidence supports a narrower conclusion than “AI doubles engineering productivity.” It suggests that high output becomes sustainable when an organization redesigns review and accumulates experience with the tools.
The central unit of value is not code generated. It is a change that survives review, reaches users, avoids incidents, and remains maintainable.
Plans and Review Agents Become the Control Layer
The strongest response to AI code slop starts before generation and continues through layered, risk-based review.
Companies are building a control layer around coding agents. This layer combines specifications, automated tests, security checks, policy enforcement, confidence signals, and human escalation.
Planning comes first because review alone cannot efficiently rescue a badly framed task. A precise specification narrows the agent’s options before it generates a large change.
The specification should identify the intended behavior, relevant components, architectural limits, data constraints, and acceptance tests. It should also describe failure conditions and unusual inputs.
This approach does more than improve prompts. It creates a reference that both automated reviewers and people can use to evaluate the result.
Without an approved plan, a reviewer must infer what the author intended while reading the implementation. That task becomes harder when the nominal author is an agent with no stable understanding outside its current context.
With a plan, the review question becomes more concrete. Did the implementation match the agreed design, or did the agent invent a different solution?
AWS uses specialized agents to perform early checks, according to senior principal engineer David Yanacek. Those agents test whether code works, compare it with the original plan, and search for security problems before human review.
This layered workflow treats AI review as filtration rather than final authority. Machines handle repetitive reading and structured comparisons. People judge ambiguous tradeoffs and accept responsibility.
Bonterra adopted a similar model after its review workload increased sharply. The nonprofit software provider has about 290 engineers.
Within three months of adopting AI, proposed changes tripled, according to CTO Tanuja Korlepra. The amount of code entering review rose tenfold, while review times tripled.
Those figures illustrate why traditional line-by-line review cannot simply absorb unlimited generated output. Adding one coding agent can expand production faster than a company can hire experienced reviewers.
Bonterra’s review agents compare proposed code with the approved design, security requirements, coding standards, and accessibility rules. They also produce a confidence assessment.
A low confidence score or a flagged problem routes the change to a person. Code affecting payments, personal information, or other sensitive systems always receives human review.
This approach uses risk as a scarce-attention allocator. It does not claim that automated review makes every low-risk change correct.
Risk-based triage instead asks where a failure would cause the greatest damage. Teams can then apply their limited human attention where context and accountability matter most.
Research on agent-authored pull requests suggests structural signals can help. One 2026 review-effort study analyzed 33,707 agent-generated pull requests across 2,807 repositories.
Researchers found that 28.3 percent merged in less than one minute, reflecting narrow changes that needed little interaction. Other requests entered longer review cycles in which agents sometimes stalled or stopped responding to feedback.
The researchers built a model to identify the highest-effort 20 percent of pull requests at creation time. Using structural signals, it captured 69 percent of total review effort within that review budget.
The model achieved an area-under-the-curve score of 0.957 on a time-based evaluation split. That score measures how well a classifier separates higher-effort changes from lower-effort ones.
Text descriptions provided little additional predictive value. What the agents touched mattered more than how they described their work.
That finding strengthens the case for reviewing change structure early. File count, code volume, configuration changes, dependency reach, and architectural spread can reveal risk before anyone debates code style.
However, an effective control layer needs independence between generation and evaluation. Asking the same model to approve assumptions it introduced can reproduce the original blind spot.
Teams need deterministic tests, static analysis, security scanners, repository policies, and human domain knowledge alongside model-based review. Each control catches different failure modes.
Documentation also becomes operational infrastructure. A coding agent cannot follow architectural decisions, ownership rules, or previous incident lessons that remain scattered across meetings and individual memory.
An engineering knowledge base can help teams preserve that context. It should support the review process without replacing authoritative tests or repository controls.
Human Approval Cannot Become Theater
Review fails when an engineer approves working behavior without understanding the generated design underneath it.
JD Raimondi, chief AI architect at software consultancy Making Sense, calls that outcome “theater approval.” A reviewer confirms that a feature appears to work, skims the implementation, and approves it without understanding the underlying choices.
This problem existed before generative AI. Large pull requests, deadline pressure, unclear ownership, and superficial testing have always weakened review.
Coding agents raise the stakes because they can produce persuasive implementations at unusual speed. Clean formatting and confident explanations can make weak assumptions harder to notice.
An agent may satisfy visible tests while mishandling rare inputs. It may introduce a dependency that conflicts with company policy or duplicate logic hidden elsewhere in a large repository.
It may also weaken security without producing an obvious functional failure. Authorization boundaries, data retention rules, race conditions, and unsafe defaults require more than a quick demonstration.
Temporal responds by making the submitting engineer defend agent-generated work. Under its “Send Back” policy, engineers must explain the design choices in their own words.
They must also describe how the code handles unusual conditions. If they cannot do so, the reviewer rejects the submission.
CEO Samar Abbas summarized the policy directly: “We refuse to let code review become a dumping ground for unchecked model outputs.”
The rule changes the incentive facing the person who invokes an agent. Generating a larger patch no longer transfers all comprehension costs to somebody else.
The submitter must build enough understanding to answer questions and own the outcome. That requirement discourages speculative code volume and rewards smaller, defensible changes.
It also preserves accountability. An AI agent cannot join an incident call, explain a regulatory breach, or decide whether a risky deployment should continue.
Human responsibility remains essential even when machines perform most of the reading. The question is whether organizations give reviewers enough time, context, and authority to exercise that responsibility.
Google’s delivery research found that AI adoption was associated with both higher software throughput and greater delivery instability. The report described AI as an amplifier of the surrounding system.
Strong testing, clear platforms, fast feedback, and healthy documentation can turn increased generation into useful output. Weak controls can let the same increased volume multiply defects and confusion.
That framing avoids two common exaggerations. AI-generated code is not automatically unsafe, and automated review is not automatically sufficient.
The outcome depends on the workflow surrounding both systems. A team that measures accepted suggestions or lines generated can miss downstream rework.
A stronger measurement system follows changes beyond merge. Useful indicators include escaped defects, failed deployments, security findings, rollback frequency, review time, and maintenance effort.
Teams should also distinguish low-risk automation from consequential product logic. Updating generated documentation does not carry the same exposure as changing payment authorization.
Risk classification can still fail. A small change to a shared authentication helper may have wider consequences than a large update to an isolated tool.
That is why line count alone cannot determine scrutiny. Review systems need ownership maps, dependency information, historical incident data, and an understanding of sensitive boundaries.
Automated reviewers introduce their own noise. If agents flood developers with low-value warnings, people can become conditioned to dismiss alerts.
Alert fatigue then converts a technical control into another form of theater. The review system appears thorough, while important findings disappear inside routine commentary.
Companies therefore need to measure the precision and usefulness of automated findings. A review agent should reduce human search costs, not produce another queue that nobody can responsibly clear.
The skeptical conclusion is straightforward. AI-assisted review can help manage AI-generated volume, but evidence does not support removing human accountability from high-risk changes.
The Junior Engineer Pipeline Faces a Different Risk
If agents absorb the work that trained junior engineers, companies must deliberately rebuild the path from beginner to trusted reviewer.
Entry-level developers traditionally gain judgment through implementation. They trace existing code, make contained changes, receive detailed feedback, debug failures, and gradually handle larger systems.
Many of those tasks are well suited to coding agents. They are bounded, repetitive, and easy for senior engineers to describe.
Automating them can improve short-term output. It can also remove the practice that teaches newcomers how abstractions fail, why conventions exist, and where production systems hide complexity.
A junior engineer cannot become a reliable reviewer by approving code they do not yet understand. Reading generated output helps, but passive inspection does not fully replace building, breaking, and repairing software.
Making Sense has reportedly seen some of its largest AI productivity gains among junior engineers. The consultancy also worries about what those employees stop learning when agents handle implementation.
Its response is to keep juniors involved in deciding why a customer needs a feature and how that feature should behave. They participate in problem definition instead of receiving only an AI-generated result to check.
IBM is trying another approach. New engineers receive more demanding assignments earlier, according to Neel Sundaresan, the company’s general manager of automation and AI.
AI assists with implementation and testing. When the system fails, junior engineers must diagnose the problem and correct it before senior approval.
Sundaresan estimates that AI can help junior engineers perform 70 to 80 percent of some tasks previously associated with senior developers. That figure is an executive estimate, not an independent productivity measurement.
The important part is the accompanying responsibility. Juniors still investigate failure rather than treating the agent as an unquestioned source.
Synthesia mainly hires mid-level and senior engineers. Its less-experienced employees work with both a senior colleague and an AI agent while owning defined parts of projects.
Bonterra has also changed junior development. Agents now perform many well-defined tasks that once served as training assignments.
The company instead asks junior engineers to own outcomes with experienced colleagues. They learn to direct agents, question results, and remain responsible for delivered behavior.
Korlepra captured the long-term concern plainly: “If the industry stops hiring juniors, the industry stops producing seniors.”
That pipeline problem will not appear immediately in delivery dashboards. A company can reduce entry-level hiring and still increase output for several quarters.
The cost arrives later when it needs engineers who understand legacy systems, production incidents, customer constraints, and architectural history. Those capabilities develop through accumulated exposure.
Organizations therefore need training signals alongside throughput metrics. They should track whether junior engineers can explain changes, diagnose failures, write tests, and handle increasingly ambiguous assignments.
Review participation also needs structure. Giving a junior engineer a massive agent-generated patch without context teaches endurance, not judgment.
Smaller changes create better learning loops. A clear specification, limited scope, observable tests, and direct senior feedback let newcomers connect intent with implementation.
Incident reviews offer another important classroom. Engineers learn why apparently harmless decisions created operational failures and how safeguards should change.
Companies can feed those lessons into both training and agent context. However, the human learning objective should remain explicit rather than becoming a side effect of tool deployment.
The future senior engineer will probably spend more time directing and evaluating agents. That makes foundational knowledge more important, not less.
Judgment requires a mental model of the system. Without experience building that model, a reviewer can only assess whether generated code looks familiar.
The junior pipeline is therefore part of the AI code review problem. Companies must produce both dependable software and the people capable of recognizing when automation is wrong.
Three Signals Will Show Whether the New Workflow Works
The next phase will be judged by production stability, review economics, and the development of human expertise.
The first signal is whether higher pull-request volume improves delivery without increasing failures. Companies should publish or internally track deployment frequency beside rollbacks, escaped defects, incidents, and security findings.
A stable revert rate is encouraging, but it does not capture every maintenance cost. Duplicate logic and architectural drift can remain in production long before causing a visible incident.
If throughput rises while reliability and maintenance remain steady, the redesigned workflow gains credibility. If review queues and rework keep expanding, generation has merely moved the constraint.
The second signal is whether risk-based review reduces human effort without weakening accountability. Bonterra and Synthesia are routing changes according to sensitivity, while AWS uses agents for initial checks.
Useful evidence would show which automated findings engineers accept, which defects escape, and how often supposedly low-risk changes require later repair.
Review latency should fall because automation removes routine work, not because people approve more code without understanding it. Temporal’s explanation requirement offers one test of genuine comprehension.
If engineers can defend generated designs while spending less time on mechanical inspection, AI code review is doing useful work. If approval becomes ceremonial, the workflow is failing.
The third signal is whether junior engineers continue progressing into independent technical ownership. Companies should watch promotion readiness, debugging performance, incident participation, and the complexity of assignments juniors can complete responsibly.
Short-term output gains will not compensate for a shrinking supply of experienced reviewers. Every automated training task needs a replacement learning loop with real consequences and feedback.
Synthesia AI code review shows that the coding agent itself is only one component. Specifications, repository context, automated checks, escalation policies, human explanations, and career development determine the final result.
Engineering leaders should now ask a harder question than how much code AI generated. How much verified, maintainable software reached users, and did the team strengthen its ability to judge the next change?
The organizations that can answer both parts will have evidence of productivity. Those that cannot will keep producing code faster while accumulating uncertainty downstream.
