smpl / PERSISTENT CODEBASE INTELLIGENCE / FOR ENGINEERING TEAMS

Your codebase shouldn't depend on who happens to remember it.

Persistent codebase intelligence for engineering teams that have outgrown tribal knowledge.

smpl makes the codebase legible, evaluates work before engineers spend time on ambiguity, and preserves what the team learns — so when execution is needed, it starts from real understanding, not guesswork.

See the Codebase Intelligence Review → Read the technical paper

Where the system stands today Drawn from published research and active deployments. Read the source on the research page.

70–77%

Autonomous resolution
on production tickets

> Opus

Lab-tuned models on
domain benchmarks

< 24 h

Onboarding to a full
production codebase

Source code leaves
your boundary

§ 01 · WHAT WE'RE ACTUALLY SOLVING

Most teams describe a capacity problem. The deeper problem is usually understanding.

The visible symptoms are familiar. Tickets arrive underspecified. Investigations restart from zero. Onboarding takes too long. The same two or three senior engineers keep getting pulled into the same conversations. The natural conclusion is that the team needs more capacity. Sometimes that's true. Often it's incomplete.

What teams experience as a throughput problem is often illegibility in disguise: the codebase has absorbed context from every migration, incident, and engineer who moved on, and too much of that context now lives in a small number of heads. When those people are busy, the system gets harder to read. When they leave, part of it leaves with them.

Code-completion tools help individuals move faster. They do not make the system more legible, the backlog more coherent, or the organization less dependent on tribal knowledge. That is the gap smpl is built to close.

An AI engineering system, not a chatbot with a GitHub account.

What looks simple at the surface depends on five underlying layers: model, system prompt, task framing, context, and tooling. Weakness in any one of them limits everything above it.

Model

Owned compute on Blackwell hardware. Fine-tuned models, calibrated to specific workloads, exceed frontier API performance on domain benchmarks.

System Prompt

Per-stage, per-archetype identity. Continuously optimized by Researcher against a quantitative evaluation corpus.

User Prompt

Structured task framing. Each pipeline stage carries a precisely engineered mandate, scored on the same corpus.

Context

Lux for what the code is; institutional memory for what is known about it. Curated, queryable, ephemeral access scoped per investigation.

Tooling

Purpose-built capabilities, exposed selectively. Constrained tools force more disciplined reasoning and produce measurably better outcomes.

FIG. 02 · FIVE-LAYER OPTIMIZATION HIERARCHY Source: What Is Neil? · April 2026

The four layers of persistent codebase intelligence.

Most deployments build these in order: legibility first, then investigation, then memory, then execution. Each layer makes the next one more reliable.

Legibility ↳ Lux

The codebase, made readable as a system

Lux combines semantic retrieval, structural code intelligence, relation-aware retrieval, and domain discovery into a continuously maintained structural view of your codebase — symbol-, type-, and reference-level truth that plain text search cannot provide. The system is readable as a whole, not just searchable as text. >lux domain billing-service ↳ 14 modules · 7 service dependencies · 11 likely experts inferred from contribution patterns · 3 architectural decisions referenced

Investigation ↳ Recon

Evaluating work before engineers lose time to ambiguity

Recon evaluates each ticket through a pipeline of bounded-epistemology stages — reconnaissance, archetype classification, problem scoping, and archetype-specific investigation — and emits the targeted pushback questions a senior engineer would ask during planning, grounded in actual codebase analysis. Ambiguity surfaces before, not after, engineering time is spent on it. >recon evaluate ticket BUG-4129 ↳ archetype: bug investigation · 6 pushback questions generated · 4 resolved against the codebase · 2 escalated for human input

Memory ↳ Corpus

Institutional knowledge that compounds

Corpus is the structured, git-backed knowledge repository beneath the system — institutional memory as a queryable substrate, not a wiki. Investigations, architectural decisions, and resolved incidents are captured as structured findings; specialist faculty agents accumulate domain expertise across many tickets in the same service. The 50th answer is better than the 5th — and the system can show you why. >corpus query decisions · billing-service · rate-limiting ↳ 11 decisions tracked · 4 authors · linked to RFC and ticket history · cross-references intact across migrations

Execution ↳ WorkStream

Grounded in everything above

WorkStream orchestrates execution as a DAG: tasks decomposed with explicit dependencies, parallel work identified, each task run in its own bounded context. Where the layers above are stable, the system drafts changes, scaffolds migrations, and opens pull requests with tests and evidence — all carrying the context of the layers beneath them. Execution without understanding is a liability. The architecture refuses it by design. >workstream plan migration · rename · UserAccount → PrincipalIdentity ↳ decomposed to 7 tasks · DAG: 4 parallel + 3 sequential · external consumers flagged · changelog drafted Execution expands only where the layers above it are mature enough to support it on a given codebase.

How smpl sits relative to your codebase.

A cross-section. Your repository and its history is the substrate; smpl is the layered intelligence maintained above it. Investigation agents query through ephemeral, read-only access scoped to a single evaluation.

04 · EXECUTION WORKSTREAM

DAG-orchestrated changes proposed and grounded in every layer below. Human approval required before merge.

outputs: patches · pull requests · tests

03 · MEMORY CORPUS

Decisions, investigations, and accumulated specialist expertise persisted as structured, queryable recall.

writes: decisions · findings · faculty

02 · INVESTIGATION RECON

Bounded-epistemology pipeline: reconnaissance → archetype → scoping → investigation. Pushback questions out.

reads: tickets · alerts · editor

01 · LEGIBILITY LUX

Continuous structural view: symbols, references, dependencies, domains, expert inference.

indexes: AST · LSP · git · relations

SUBSTRATE

Your codebase, its commit history, its prior reasoning. Read-only, ephemeral access scoped per investigation.

deployment: in your environment

FIG. 03 · SMPL SYSTEM CROSS-SECTION READ TOP-DOWN: OUTPUT → SOURCE

What the first weeks of deployment have looked like.

Two real engagements. Both shaped what the system does today.

CASE 01 / ENGINEERING TEAM / 10+ ENGINEERS · BOOTSTRAPPED / COMPLEX MONOREPO

Throughput surfaces a deeper problem.

The deployment was expected to lift engineering output. It did. But the more interesting result was that, once engineering moved faster, the bottleneck shifted — to product specification and QA — exposing constraints that engineering drag had been masking.

▸67 effort points moved to ready-for-review in week one — roughly the entire engineering organization's typical weekly output (~136 points / two-week sprint).

▸89 tickets reviewed in a single day.

▸Onboarded to the full codebase in under 24 hours.

▸Engineering was suddenly squeezed on both sides — QA downstream, product specification upstream.

↳ Read the deployment report

CASE 02 / CX TEAM / 1 LEAD · 5 STAFF / NON-TECHNICAL INTAKE

Faster resolution exposed a better operating model.

A CX team was funneling all requests requiring investigation through development support. The obvious win was speed. The deeper win was that, once requests became legible by type, the conversation between CX and development stopped treating everything as the same kind of problem.

▸Typical close time fell from three days to under 30 minutes.

▸Root cause analysis was performed autonomously across application-layer bugs, infrastructure-layer bugs, and data-quality issues.

▸An undifferentiated queue became a set of identifiable operational, data, bug, and feature-request flows.

▸The result was not just faster answers, but a more efficient organization.

↳ Read the deployment report

The Codebase Intelligence Review is the place to start.

For engineering teams operating real system complexity, this is the best first step: a written review that clarifies where risk, ambiguity, and hidden dependency live inside the codebase.

Recommended first step

Codebase Intelligence Review

A written review designed to surface where the codebase is becoming hard to hold: architectural sprawl, dependency risk, knowledge concentration, onboarding drag, and the areas where clearer understanding would make the biggest difference.

Designed for: Qualified engineering teams operating real system complexity
What we review: Architecture, dependencies, domain structure, and knowledge concentration across the repository surface you share
What you get: A written assessment with findings, likely risk areas, and recommended next steps
What happens next: If the review surfaces a strong fit, deeper investigation or deployment can follow

Selective review

See the Codebase Intelligence Review →

Start with the review. If deeper investigation or deployment makes sense, that will be clear from there.

If your codebase is carrying more than any one person can hold, that's the conversation to have.

Start with the review. We analyze one of your repositories — architecture, dependencies, domain structure, and knowledge concentration — then deliver a written assessment that shows where the codebase is hardest to hold, where risk is concentrated, and what to do next.

See the Codebase Intelligence Review → Read the technical paper Get on the early access list