AINexus
Architecture2 min read27d ago·2 comments·2268 views

Design document · numbered sections

Architecture notes: what a code review agent should never read

by @samuel — AI code review · developer tooling

An accepted design record for AI code review: constraints, decision, structure, consequences and the alternatives we rejected.

ADR-017 · Status: accepted · owner: platform · scope: AI code review for every product surface.

Context

We run AI code review for a product that cannot afford a bad week. This document records the constraints we were given, the shape we chose, and what we knowingly gave up.

Constraints

ConstraintTargetWhy it matters
p95 latency< 2sBelow this, the product feels broken
Failure isolationone tenant onlyA noisy neighbour must not page the on-call
Cost visibilityper requestFinance asks monthly, and they are right
Change safetyrevert in minutesPrompts are code, so they need rollbacks

Decision

Put one narrow boundary in front of the model, keep retries and fallbacks inside it, and emit telemetry from the same request path.

Three boundaries, each with exactly one job:

  1. Edge terminates identity and budget. Nothing downstream re-implements auth.
  2. Workers own retries, deadlines and fallbacks. Stateless, horizontally scalable.
  3. Telemetry is written inline — never reconstructed from logs afterwards.

Structure

client
  │
  ├── edge: auth · quota · tenant routing
  │        │
  │        ├── GitHub Actions
  │        └── tree-sitter
  │
  └── workers → upstream providers
           │
           └── telemetry: traces · evals · cost

Interfaces

The contract between edge and workers is a single schema, versioned with the deploy. GitHub Actions + tree-sitter + a hosted model stay interchangeable because that contract never changes.

Consequences

What gets better

  • Quotas are explainable to customers: one number, per tenant, observable.
  • A provider outage becomes a routing decision instead of an incident.
  • Every request has a cost, a latency and an outcome attached to it.

What gets worse

  • One more hop of latency, roughly 8ms on our hardware.
  • The edge becomes a shared dependency — it needs its own on-call rotation.
  • Deploying it requires coordination with every consumer.

Failure modes

Under 3x load the first thing to fail was not the model; it was retries amplifying a partial outage. Every retry now carries jitter and a deadline inherited from the caller.

whole-file prompts invite the model to rewrite your architecture

Alternatives we rejected

OptionWhy it lost
Library inside each serviceAuth and quota implemented five times, five ways
Provider SDK directlyNo shared budget, no shared telemetry
Gateway as a product (vendor)Cost per token on top of cost per token

Operations

  • Dashboards per tenant, not per instance
  • One alert that matters: error rate above 1% for five minutes
  • A runbook entry for "upstream degraded" a new hire can follow at 3am

Copy it, change the limits, put the verification in CI, move on.

Comments (2)

Log in to join the discussion.

@jonas·2h ago

We hit the exact same trap last quarter. The fix was smaller than expected.

@priya·2h ago

We hit the exact same trap last quarter. The fix was smaller than expected.