The agent

The model is replaceable. The method is the product.

CodeLead is a governed coding agent. It controls how the model receives context, what it is allowed to change, when people must approve the plan, how validation runs, and what evidence is captured. It builds new applications, changes existing code bases, and modernizes legacy systems with the same discipline, on your machine, with the model you choose.

codelead · local 4B model · governed run
$ codelead /implement "show the page title above the game"
→ model proposes: rewrite vite.config.ts, tsconfig.json, package.json …
✗ refused by patch gate — approved change surface is index.html only.
3 files outside scope. Nothing applied. Reason recorded to evidence.
(attempt 17 of 24 — all 24 refused; the working game was never touched)
→ retry with hard constraint: scope = index.html
✓ applied · build green · evidence record written

A real run. Near the end of building a Pong game, a 4-billion-parameter local model tried twenty-four times to rewrite the project's config files to add a page title. Every attempt was refused; the game kept working. The smaller the model, the more the governance matters.

What you use it for

Three kinds of work. One loop.

New applications from a prompt

A walking skeleton first, then one capability per increment, each built, validated and committed. The Silicon Exchange run is this, unattended, on a laptop.

Changes to an existing code base

The day-to-day work: a feature, a fix, a refactor. CodeLead computes what the change really touches, pins behavior where tests are thin, and refuses a patch that wanders outside the scope you approved.

Legacy modernization

The flagship use case, and where the method was hardened: a read-only assessment first, then a sequence of proven increments, with an audit pack the client keeps.

What the agent controls

AI does the work. Your team keeps control.

Local-first execution

Runs local models on hardware you control by default. With a local model, your source code stays on the machine it runs on.

Bring your own model

Local first: any open model your hardware serves through LM Studio or Ollama. Remote and cloud models are available when you choose them, with one plain caveat: what goes to a remote model leaves your machine, and CodeLead cannot guarantee its privacy. The engine is model-agnostic by design, so a better model is an upgrade, not a migration.

Human approval gates

You approve the plan before anything is built. Dependency installs and commands wait for approval, and scope grows only when you say so.

Validation before progress

An increment is not done until its build, tests and behavior checks pass. A failure stops that increment, not the whole run.

No uncontrolled changes

The model proposes; it never edits files directly. Every change passes hard safety checks first, and every refusal is recorded with its reason.

Evidence for every change

Each change closes into a record a third party can follow from request to approval, and what it teaches lands in a knowledge base where facts are separated from guesses.

Why CodeLead

Five things it does that your agent doesn't

1 · It knows what your change actually touches, including the file you forgot

Before generating a line, CodeLead computes the change surface from the code itself: a symbol and dependency index, interface closures, and co-change obligations. If your change to a library must also land in a base class three projects away, that obligation is named up front, and a patch that skips it is refused, not merged.

Evidence. Asked for one aggregate method on a 17-year-old data-access library, CodeLead flagged a fourth file never mentioned in the request, a repository base class in another project, that a human reviewer had once missed. Retrieval benchmark: 0.97 mean core-recall, measured, re-scored after every change.

2 · Nothing reaches disk unchecked

Model output is treated as untrusted input. Every proposed patch passes deterministic gates (scope, path safety, plan compliance, syntax and convention sanity, repair effectiveness) before it can be applied, and every refusal is recorded with a written reason. The gate doesn't get tired on file four thousand, and it doesn't get charmed by confident output.

Evidence. 350+ benchmarked runs to date; zero unsafe applies, ever. During the original brownfield experiments a local model hallucinated file contents for fifteen rounds. Not one bad patch reached disk.

3 · Small increments, real commits: the way software has always been built

Humans hold a big picture and execute one small, completable thing at a time. CodeLead works the same way: it decomposes work into increments, each one built, validated, and committed on its own. You get a readable git history instead of a mega-diff, a resume point at every step, and failures that name the increment that caused them, with everything before it still green.

Evidence. Same model, same laptop, same prompt with CodeLead removed: a plain agent loop declared itself finished with a business rule wrong and its own test asserting the wrong number, and nothing in the loop could tell. The governed run caught the same defect at verification and fixed it as one scoped, verified commit.

4 · It runs on your machine, on models you choose

Local-first isn't a deployment option; it's the trust anchor. By default CodeLead runs against local open models, anything your hardware serves through LM Studio or Ollama, and your code stays on the machine you ran it on. Remote models are there when you choose them, and the tradeoff is stated plainly: what goes to a remote model leaves your machine, so privacy is no longer something CodeLead can guarantee. Governance is what makes small local models viable: decomposed, scoped, example-anchored tasks turn a model that's "occasionally right" into one that's boringly reliable. The engine is model-agnostic by design, and that cuts the other way too: a stronger model writes bigger changes, which makes the gates matter more, not less.

Evidence. The Pong game above was built by a 4B model, small enough to run on a phone, in about forty governed machine-minutes on consumer hardware. Nothing left the machine.

5 · Every change explains itself, forever

Each run closes into a structured evidence record: the request, what was retrieved, the surface, every gate verdict and refusal, validation results, approvals. Six months later you, or an auditor, can walk requirement to change to check to validation to approval without asking anyone. Paired with the project knowledge base, what CodeLead learns about your codebase (working commands, conventions, invariants, decisions) is kept with a trust level and a citation. A fourteen-times-verified build command and a chat rumor are visibly different kinds of knowledge, and only proven knowledge feeds future changes.

Evidence. The evidence chain is the same instrument this page is written from: every number here traces to a session log, a benchmark report, or a git history.

The loop

How a change lands

  1. MapIndex the code; compute the change surface and its obligations.
  2. PlanDecompose into small increments. You approve the plan first.
  3. PinWhere tests are thin, lock in current behavior.
  4. GenerateThe model writes the patch: scoped, example-anchored.
  5. GateDeterministic checks. Out-of-scope or unsound is refused, with reasons.
  6. ValidateBuild, tests, pins, behavior probes, at the level you'd check yourself.
  7. EvidenceCommit plus a structured record; knowledge captured for next time.

Built for brownfield

Understand before editing (system map, contract catalogue, history mining for what actually changes together), pin current behavior with characterization tests where the safety net is thin, make the smallest change that honors the diagnosis, validate at the level the problem was observed, and land with the reasoning attached. Tribal knowledge, the conventions and invariants that live in comments and veterans' heads, gets extracted into the knowledge base as claims and promoted to trusted only when evidence confirms them.

Greenfield, the same way

New apps get the same machinery, chained: a walking skeleton first, then one capability per increment, each gated, validated (including whether the UI actually renders and responds, not just compiles), and committed. Where other tools hand you one unreviewable generation, CodeLead hands you a git history a human can read, and a resume point if increment seven goes sideways at 2 a.m. The Silicon Exchange run is this loop, unattended, in under two and a half hours, with every business rule in the request checked independently of the model's own tests.

Audience

Who it's for

Solo founders and indie builders

You're the architect, the reviewer, and the on-call. CodeLead lets cheap local models do the typing while you keep the judgment.

  • Ship features as verified increments, not roulette-wheel mega-diffs
  • Run on hardware you own: no per-token bill for iteration, no code exfiltration worry
  • Come back after a week and the evidence trail, not your memory, says exactly where things stand

Enterprise developers

You maintain the systems the demos avoid. CodeLead is built for your Tuesday.

  • Change surfaces that include the co-change three repos away, before review, not after the incident
  • Characterization pins so "did I break anything?" becomes "the pins are green"
  • Refusals with written reasons you can show your tech lead, and an evidence chain your auditor stops arguing with

CTOs: the two-paragraph version

Your engineers are already using AI on your code. The only question is whether it happens inside a governed, auditable boundary or in the shadows. CodeLead gives you the boundary: local-first execution, deterministic safety gates no model can talk its way past, and structured evidence for every change, exportable as audit packs.

It is model-agnostic by design: as models improve, your governance, knowledge base, and evidence compound instead of resetting. Adoption starts small, one codebase, one developer, read-mostly, and earns its way up on evidence, which is exactly how your engineers will judge it too.

Private beta

Request early access

The CLI runs on your machine, against local models through LM Studio or Ollama first and remote models when you choose them. It is in private beta while the engine is hardened for code bases its authors have never seen. Seats open in small batches.

Tell us what you'd point it at first. That is how we decide which stacks and workflows the next batch is ready for. We email you when your seat is ready, and nothing else.