Living documentCreated 2026-07-28Updated 2026-07-286 min read

Enterprise Review Platform

The Enterprise Review Platform is not an automated approver. It is a staged review pipeline that makes high-quality, context-aware code review more consistent and scalable, while keeping engineers accountable for the final decision.

This case study describes the architecture and the lessons at the level I can publish. Internal system names, infrastructure details, security controls and company-specific data flows stay inside the company.

Problem

Code review in a large enterprise is not syntax checking.

The difficult part is understanding:

repository conventions
dependency relationships
architectural boundaries
internal libraries
security expectations
project-specific history

General-purpose coding assistants can produce plausible feedback while missing the context that actually matters. Review quality also varies heavily between teams and reviewers.

The purpose of the platform is therefore not to automate approval. It is to make good review consistent, while engineers remain responsible for accepting, rejecting or discussing every finding.

Constraints

Enterprise security: code is sensitive, and what leaves the organisation, and to whom, is an architectural decision.
Cost and latency: review happens inside a delivery workflow. A review that arrives an hour late, or costs more than the engineer time it saves, does not get used.
Legacy codebases: documentation may be incomplete, outdated or wrong. The system cannot assume a clean, well-documented repository.
Explainable feedback: a finding without evidence is noise. Every comment must point at something concrete.
Incremental adoption: the system has to fit into the existing review workflow, not replace it.

Architecture

The system is a staged pipeline. Each stage narrows the problem before the next one spends effort on it.

flowchart TD
  intake["1 · Change intake<br/>diff, metadata, affected modules"]
  classify["2 · Change classification<br/>type of change, likely review domains"]
  context["3 · Context preparation<br/>smallest useful context package"]
  review["4 · Specialised review<br/>correctness · security · architecture<br/>testing · maintainability"]
  filter["5 · Evidence and confidence filtering<br/>deduplicate, rank, drop unsupported findings"]
  publish["6 · Recommendation<br/>into the existing review workflow"]
  engineer["Engineer decides"]

  intake --> classify --> context --> review --> filter --> publish --> engineer

Change intake. Receive the pull request diff and metadata: changed files, affected packages, repository, authoring team, target branch, linked work item where available.

Change classification. Classify the change before reviewing it: frontend, backend, infrastructure, configuration, tests, authentication, data access. Estimate the likely review domains, from correctness and security to maintainability, architecture, performance and test coverage. A smaller, cheaper model handles much of this stage.

Context preparation. Extract only the repository context relevant to the changed code: imported modules, internal dependencies, interfaces and types, neighbouring implementations, project conventions, internal library documentation, existing tests, previous review patterns. The goal is not to send the whole repository to a model. It is to construct the smallest useful context package.

Specialised review. Route the prepared context to specialised reviewers: correctness, security, architecture, testing, maintainability, and a detector for the risks typical of AI-generated code. Different models and prompts handle different review tasks. Not every stage needs the most capable model.

Evidence and confidence filtering. Remove low-value or unsupported comments. A finding must point to a concrete line, a violated rule, an internal standard, a dependency relationship or a plausible failure mode. Merge duplicates. Rank by severity and confidence.

Recommendation. Publish into the existing review workflow. The first version deliberately does not act as an approval gate. The engineer remains responsible for the decision.

Preparing context for a legacy codebase

A legacy repository cannot be treated as a clean, well-documented system. Documentation may be incomplete, outdated or inconsistent with reality. Context preparation has to rely on the codebase itself.

The practical sequence:

Parse the changed files.
Resolve imports and internal dependencies.
Identify directly affected modules.
Retrieve relevant internal documentation where it exists.
Retrieve similar implementations elsewhere in the repository.
Inspect tests around the changed behaviour.
Include selected conventions from the project or platform.
Build a compact, dependency-aware context package.

The principle underneath: retrieve context by structural relevance, not only semantic similarity. Pure embedding search can return something textually similar but architecturally irrelevant. Dependency and repository structure often matter more than what the text looks like.

Trade-offs

Bounded context, visible uncertainty

Full repository understanding is too expensive and too slow. Internal documentation is never complete. Static analysis, embeddings and dependency mapping each provide only a partial view.

So the system reviews with a bounded context window, and it has to present feedback carefully enough that engineers do not mistake it for authority. Making uncertainty visible is part of the design, not an apology.

Advisory before gatekeeping

To gain adoption, the initial system stays advisory. That limits automation, but it avoids blocking delivery on immature model judgement.

That is not a weakness. It is an adoption strategy. A recommendation system that engineers can interrogate is more valuable than a gatekeeper they do not trust.

What changed my mind

At the beginning, I thought the model would be the most important component. I expected the main challenge to be writing the right prompts and choosing the strongest model.

Building the system made it clear the model was often the least enterprise-specific part. The difficult work was understanding repository structure, preparing relevant context, connecting internal libraries, representing engineering standards, filtering weak feedback and fitting into existing review workflows.

More context did not mean better reviews

Early versions provided too much repository context. The model became less precise. It generated generic comments and focused on irrelevant parts of the system. Latency and cost went up while review quality did not.

Context quality matters more than context volume. The hard problem is not retrieval. It is context selection.

"Best practice" can be harmful

A model will confidently criticise code that is intentionally shaped by an internal constraint it cannot see. Without internal standards and architecture context, best-practice feedback is not neutral. It can be actively wrong.

The core conclusion: the quality of an AI reviewer is determined less by how much the model knows in general, and more by how well the system understands the local engineering environment.

Future evolution

Repository-level knowledge graph and stronger dependency-aware retrieval.
Project-specific evaluation datasets.
Feedback loops based on accepted and rejected findings.
Craft-excellence weighting: learn from high-quality internal review patterns instead of averaging every historical review equally.
Better calibration and uncertainty reporting.
Model routing by risk and complexity.
Possibly repository-specific agents that build persistent local understanding over time.

Engineering principles

✓ Context selection over context volume
✓ Structural relevance over semantic similarity
✓ Explainability over autonomy
✓ Advisory before gatekeeping
✓ Human accountability
✓ Model orchestration over model dependence

Status: Living document Last updated: 2026-07-28

This article reflects my current understanding. As I build more systems I expect parts of it to evolve.