Skip to content
Playbooks

Building the Company

When AI code review becomes the bottleneck

On this page

Prepared by Venture Executive Network from recorded practitioner sessions. Updated .

LAST REVIEWED 2026-11RECORDED SESSION SYNTHESIS

This page follows Why AI isn’t making engineering 10x faster. That page covers why speeding up one step does little for the whole process. This one covers the step that most often stalls next: review, followed by testing and deploy. It draws on an October 2026 follow-up session with the same cloud-deploy co-founders and a member who runs a small engineering team at a B2B software company that sells to large regulated enterprises.

Why does code review become the bottleneck?

Section titled “Why does code review become the bottleneck?”

The member’s team had already moved most of its delivery work to agents. Requirements and specs were AI-assisted. Code generation was fully AI. Testing was partly automated. Production was off limits to AI. Review was where work queued.

Code review right now is by far our bottleneck.

Executive, B2B software company selling to regulated enterprisessession, Oct 2026

On the day of the session, the member had about five code reviews to do and two of their own waiting on someone else. They described three sources of drag:

  • AI reviewers always find something. The team goes back and forth on each finding. The member said AI tools also tend to over-engineer and to be too cautious, and their setup could not rein that in enough.
  • Large features arrive as stacks. A big feature often became three or four stacked pull requests, released together at the end of a three-week sprint.
  • Integration testing lands at the end. The team spent two to three days of each sprint testing everything together, and data migrations were a recurring source of pain.

The speakers saw the same pattern across their customers. Once agents can work around the clock, the people who review and approve their output start to feel like the constraint, and they feel pressure to be available at all hours to start the next step. The speakers’ answer was to automate more of the steps around review, so less work waits on a person.

How do you review the spec before the code?

Section titled “How do you review the spec before the code?”

The member’s team moved the main design review ahead of the code. The process they described:

  1. Product brief. A basic written brief of the requirements.
  2. Visual design. An AI design tool shows what the team wants to build and, lately, how tables and data models relate, so the team can see the trade-offs.
  3. Spec. The engineer uses the coding agent to turn the brief into a markdown spec, then presents it at the weekly engineering meeting.
  4. Spec review. The team reviews the spec the way it would review code. The member said these reviews catch data migration problems, confirm the extensibility the team wants and bring up open questions.
  5. Hand-off. Once the spec is signed off and checked into the repository, the work goes to agent loops.

The spec sign-off became the point where the team hands work to the agents. Problems found there cost a conversation. The same problems found in a stack of pull requests cost a rewrite.

Can reviewers try a working change, not only read the diff?

Section titled “Can reviewers try a working change, not only read the diff?”

The speakers still ran code reviews, including automated ones, but described a shift toward review by demonstration, where the reviewer tries the deployed change.

Deploy it, show me, show it to me. I’ll play around with it, make sure it actually works the way I want it to work.

Cloud-deploy co-founderssession, Oct 2026

That depends on agents being able to run the application. The member’s application was containerized, so an agent could start several copies of it on different branches at once. The team was also investing in automated browser tests of the user interface. The speakers suggested running limited user acceptance testing in the same agent environment, instead of paying for and maintaining a separate test environment.

What do you need before you trust automatic merges?

Section titled “What do you need before you trust automatic merges?”

The speakers described a patch for a security advisory that went out with no human review. The change passed automated code reviews, merged when its checks went green, and deployed to production and package managers under rules the team had set in advance.

We trust the gates that we’ve set up.

Cloud-deploy co-founderssession, Oct 2026

What made that possible, in their account:

  • Written rules for the agents. The team decides what an agent may do, such as merge on green or deploy to production, and writes it into the agent instructions file or the CI workflow.
  • Deterministic deploys. Agents can do non-deterministic work up to the last step, but the final deployment runs the same way every time.
  • Closed loops. A finding from a security review can open an issue, and the issue can start an agent on the fix.

Build the system so that you can trust automatic merges and automatic deploys.

Cloud-deploy co-founderssession, Oct 2026

The member was not there yet. They named two prerequisites: better observability and a stronger set of end-to-end tests. They also said AI code review was not yet good enough to trust on its own, even with a lot of context.

Questions to settle before merge on green

Section titled “Questions to settle before merge on green”

These prompts are VEN editorial synthesis from the session, not a standard.

  • Which changes may merge on green, and which still need a person?
  • Which tests must pass, and do they cover the user interface and data migrations?
  • Can a reviewer try the running change before approving it?
  • Does the final deploy run the same way every time?
  • Who sees a failed gate, and does a failure open an issue an agent can work?

What if your customers and auditors are AI-skeptical?

Section titled “What if your customers and auditors are AI-skeptical?”

The member’s customers were large regulated organizations, and the member described them as the strictest audience for AI anywhere in the stack.

You have to assume that our customers are the most AI skeptical.

Executive, B2B software company selling to regulated enterprisessession, Oct 2026

Those customers would not let the team have AI crawl all of their logs. The team did not allow AI to touch production instances and expected that to hold for a while. The member was also pursuing more security certifications and expected auditors to take time to accept new controls. The member’s conclusion was to move in steps.

Two technical concerns came up as well:

  • Tech debt and configurable data models. The member’s product let customers configure their own data models. AI tended to hard-code things, such as using a requested table’s field as a fixed column name, so the team required more human oversight of the data model.
  • Older code. One of the speakers said frontier models handle older code and tech debt better than people do. The member agreed and credited the setup around the model as well, including a coding agent that now knows not to do something a certain way after being told three times.

The speakers added that jurisdiction shapes where agents can run. Some customers want everything in their own environment, or cannot contractually run in a given region.

How long before the investment pays back?

Section titled “How long before the investment pays back?”

The member’s team took a focused setup period. They took almost a full week off development to set up the agents’ tools and instructions, ran a smaller second round so the agent could run the application and its tests, and were discussing a third.

The speakers said customers who assigned part of the team (not the whole team) to re-engineering their process for one to three months saw ROI after that period. Their own team had six developers earlier in the year and a legacy code base that was not moving fast enough. They committed to automating as much as possible and, in their account, now have a smaller team that moves faster.

What happens to the people doing the work?

Section titled “What happens to the people doing the work?”

Two people costs came up that rarely show in a productivity number.

Morale. Some of the member’s engineers said they had enjoyed writing code and no longer did it. They felt reduced to a meat proxy, relaying work for agents. The speakers reframed the job: the engineer builds the factory, and the factory builds the product at high quality. Building and improving that system is engineering work.

Customer absorption. The member’s team began shipping faster than customers could take in new features.

We were then releasing things faster than our customers could absorb them.

Executive, B2B software company selling to regulated enterprisessession, Oct 2026

By the member’s estimate, customers went from using about half of what the team built to about 30 percent, because the customers move more slowly.

Where teams get stuck

Section titled “Where teams get stuck”

VEN editorial synthesis from the session:

  • Treating review as a reading task. If reviewers only read diffs, review grows with agent output. A spec review and a working demo move much of the judgment out of the diff.
  • Allowing automatic merges before the gates are trusted. The member’s prerequisites (observability and end-to-end tests) came first.
  • Expecting ROI in the first month. The speakers described one to three months of re-engineering before the return.
  • Measuring output alone. Shipping more than customers use is a cost, too.

Go deeper

Section titled “Go deeper”

Sources

Section titled “Sources”

One working session (October 21, 2026) with the co-founders of a cloud-deploy company, a follow-up to their September 2026 session summarized in Why AI isn’t making engineering 10x faster. The main member account came from an executive at a B2B software company with a small engineering team, selling to large regulated enterprises. Names, companies, customers and product details are omitted. Figures are the speakers’ and the member’s own accounts, not measured VEN results. The checklist under “Questions to settle before merge on green” is editorial synthesis.