Cole Gannaway on code review, cross-repository risk and AI software factories

I’m Cole Gannaway, a solutions engineer at Qodo. I work with organizations on how products fit their workflows. Today I want to discuss how AI-first teams are building software factories and where Qodo fits: we specialize in part of that workflow, not the whole factory.

Customers are excited about taking a ticket all the way to production, but many run into a bottleneck at the pull request and review stage. Code generation is not solved, yet it is accelerating rapidly. Review is where humans and agents need enough context to decide whether a change can be trusted.

Consider an illustrative change to Bitwarden, an open-source password manager. A developer renames a field in a data model. The change is one line, and the build, unit tests and linters all pass. It looks like the requested feature, so a reviewer could reasonably approve it.

But green checks do not mean every downstream dependency has been examined. In the room, many people acknowledge merging a pull request without reading every changed line. We rely on tools, but tools differ in what context they can see and what conclusions they can support.

That one-line rename may affect clients in other repositories: web, mobile, CLI and MCP integrations can all depend on the server field. The example is illustrative, not a report of a real Bitwarden incident. If that dependency is missed, a problem might only surface when a client breaks in production.

Qodo’s proposed approach is a software graph that maps repositories and their integration surfaces. Knowing that an Android repository connects to the server is less useful than knowing which fields and components cross that boundary. That detail can help a reviewer or review agent assess the change’s blast radius.

Some review knowledge is not just a functional test. Senior reviewers may apply organization-specific rules or judgment learned from previous mistakes. Instead of making the same person a bottleneck on every change, we can feed some of that knowledge back into the review process.

For example, a team can establish a rule for changes to public APIs: deprecate a field before renaming or removing it, or require closer review. The goal is to make such standards available consistently, including to agents, rather than leaving them only in someone’s memory.

The same context should be available before a pull request or even before code generation. An MCP server can provide the coding agent with repository knowledge, dependency information and custom rules while it is implementing the change. That does not guarantee a correct result, but it creates an opportunity to avoid the error earlier.

Teams sometimes ask whether the implementation agent should also perform the review. It has useful information, but it is simultaneously debugging, exploring the codebase and writing code. A larger context window does not ensure important details will not be buried, or that the agent will not hallucinate.

A separate review agent can focus its context on the review and bring in information specific to that run. I also want the writer and reviewer to be independent: teams can vary the model or harness, and even use adversarial reviewers, to reduce shared biases.

If different reviewers identify the same issue, that can be a useful signal; if their findings differ, investigate further. Agreement is not proof, and independence does not eliminate mistakes, but comparing perspectives can reveal problems one review misses.

Postmortems can teach organizational and process lessons as well as code-level lessons. For the latter, the challenge is to turn individual experience into knowledge that the organization can apply repeatedly, instead of allowing it to stay in a private conversation.

In the example, a pull-request comment leads Qodo to suggest a rule for later reviews. A graph can also flag that a one-line change has a large downstream impact, prompting either a human or another agent to inspect it more closely.

The software factory needs the right context, relevant standards and checks before as well as during the pull request. MCP or a CLI can make earlier review possible. A problem caught during code generation is easier to address than one discovered after merge.

An audience member describes reviewing changes with an agent and recording documentation so it can guide the next run. Another asks whether customers struggle to convey intent before code is written: an agent can follow the available context yet solve the wrong problem or overengineer the solution.

In response I show an integration with Jira or Linear tickets. A review can reference the ticket’s acceptance criteria and highlight gaps between the requirements and the proposed changes. This addresses a different question from whether the code is syntactically or functionally sound: is it implementing the intended task?

I suggest running specialized review periodically during implementation—for example at roughly 25%, 50% and 75%—rather than waiting for the final pull request. A review agent can act like a guide, helping the implementation agent correct course before it goes too far in the wrong direction.

The review stage is the part of the software factory Qodo focuses on: provide people and agents with code intelligence, shared knowledge and the context to assess risk. The next question is which changes can safely be merged without human inspection and which require closer review. Blast-radius information can help inform that judgment.