Engineering Intelligence Dashboard

The problem

Three questions a small engineering team could not answer without opening a spreadsheet: how long a change actually takes to reach production, where pull requests stall, and whether a ticket is ready to be worked on. The data existed — spread across a code host and an issue tracker, reachable only by clicking.

Two further problems worth solving in the same place: code review depth varies with how tired the reviewer is, and ticket refinement is a task where the person doing it usually has not read the code the ticket concerns.

The approach

A Turborepo monorepo: a NestJS backend, a React frontend, and three shared packages — the database layer, wire DTOs, and a package holding versioned markdown prompts alongside pure, testable builders, parsers and gates.

Ingestion runs in the cloud; everything else runs locally.

code host      ──webhook (HMAC)→ ┐
                                 ├→ edge function (Deno) ─UPSERT→ managed Postgres
issue tracker  ──webhook (HMAC)→ ┘                                     ↕ TypeORM/SSL
                                          ┌────────────────┴────────────────┐
                                     local app (dev A)              local app (dev B)
                                     Nest + Vite                    …same database
                                     + agent CLI subprocess

Decisions worth defending

There is no authentication, and that is written down as a non-goal. The application runs on localhost for two known users. Adding auth would have meant a login flow, session handling and a user model for an audience of two people who already have shell access to the machine it runs on. The only publicly reachable surface is the pair of edge functions, and those are protected by HMAC signature verification. The trade-off is explicit and recorded: this design is correct because the deployment topology is what it is, and it stops being correct the moment someone hosts it.

Metrics are parameterised raw SQL, computed on request, with no aggregation job. Window functions and percentile calculations do not express cleanly through a query builder without becoming less readable than the SQL they generate. A metrics_cache table exists in the schema and is deliberately empty, with a numeric activation trigger written down — p95 above 500ms — and the interceptor that would measure it already in place. Caching before there is a measured problem buys a staleness bug and a cache invalidation question in exchange for nothing.

The validation harness never blocks publishing. Generated reviews run through generate → deterministic gate → judge → pass or revise → retry with the feedback. The regex gate runs first because rejecting an obviously malformed attempt should cost zero tokens. Severity governs retries: low and medium findings are advisory, because letting the judge retry on nitpicks produced loops that burned budget and converged on nothing. When attempts run out, the best attempt by score is kept.

And when the judge itself fails, the run degrades to a draft carrying the judge error rather than being marked failed. A validation layer that can take down the feature it validates has made the feature less reliable, not more. The human publishes either way — the harness advises, and its opinion is visible, not binding.

Ticket refinement reads real code, in a worktree that shares the existing .git. The agent needs the current source, not a summary of it. Cloning per run would mean copying gigabytes; reusing a developer’s checkout would mean reading whatever half-finished state they left. Dedicated worktrees sharing the existing object store solve both, synchronised with fetch and hard reset before each run, and the agent runs under a strict read-only allowlist with a tested invariant that no mutating command ever touches the developer’s working branch.

Prompt drift is surfaced, not discovered. At boot the local skill file’s hash is compared against the remote default branch and a banner appears on mismatch. Two machines running what they each believe is the same prompt is a class of bug that produces days of confusion and no error message.

Scale

• ~20,700 lines total: 11,439 backend, 5,946 frontend, 1,423 in the prompt and gate package, 974 in Deno edge functions, 899 across shared packages
• 12 backend modules, 31 HTTP routes, 8 metric endpoints — all SQL
• 9 tables, 6 migrations, ~20 indexes; 34 test files, ~300 tests
• Drill-downs at p50/p75/p90 with granularity that adapts to the window length