CodeLead

Governed AI engineering · local-first

Modernize the system you're afraid to touch. With evidence for every claim.

AI can write code. The hard part was never writing code. It's changing a system you half-understand without breaking what already works, and being able to prove you didn't. CodeLead turns AI coding models into a governed engineering process: every change mapped, scoped, checked before it touches disk, validated, and recorded as evidence.

Assess a legacy system Get early access to the CLI
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.

  • 0unsafe applies across 350+ benchmarked runs. Every refusal has a written reason.
  • ~3 minfor a governed change on a 17-year-old C# codebase, local model, build green.
  • 100% localruns on your machine, on open models you choose. Code never leaves.
  • 17 / 17increments machine-verified in an unattended build on one laptop. Case study.

Every number on this site traces to a session log, a benchmark report, or a git history produced by CodeLead's own evidence discipline. We measure before we claim.

The problem

Coding agents demo on greenfield. You live in brownfield.

Agent demos are new apps built from empty folders. Your reality is a codebase that's old enough to have opinions: files nobody dares touch, tests that don't exist, conventions that live in one veteran's head, and consumers you'll discover the hard way. Point a raw agent at that and you get confident edits to the wrong files, a two-thousand-line diff you're supposed to "review," and no way to answer the only question that matters: what did it actually see, change, and check?

The industry's answer is bigger models. But capability was never the bottleneck. Trust was. A model with repo access and no governance is a liability whether it has four billion parameters or four trillion.

And the stakes are not abstract. Between 70 and 79 percent of modernization programs miss their goals, blow their budgets, or are abandoned, while the cost of keeping the old system alive grows 10 to 25 percent a year. Why projects stall, and what to do about it.

Two ways in

Start with an assessment, or start with the tool.

For companies with a legacy estate

The Legacy System Dossier is a read-only, fixed-fee assessment of one system: architecture and dependencies, the business rules buried in code and history, what can be pinned and migrated safely, and a phased plan with a proof step for every phase. Nothing is modified. CodeLead runs inside your environment, and every action is logged.

  • .NET Framework, VB.NET, and VB6-era systems first; Java and Spring next
  • Success criteria declared before work starts
  • Each section labeled automated, tool-measured and judged, or manual
How modernization works See a sample Dossier

For engineers who want AI on their own terms

The CodeLead CLI runs coding models, local by default, as a governed loop: plan, scope, generate, gate, validate, commit, with an evidence record for each increment. Small increments and real commits instead of one unreviewable mega-diff.

  • Local models through LM Studio or Ollama; cloud models only when your policy allows
  • Deterministic gates no model can talk its way past
  • A git history a human can read, and a resume point at every step
Request early access Why CodeLead

What a survey finds

Three real .NET code bases, surveyed read-only in one day.

To show what a Dossier looks like, we ran the survey on a portfolio of three real .NET systems for a fictional holding company: a data-access library from 2016, a web application built in 2013 that consumes it at a 2013 version, and a current .NET 8 e-commerce application with a live test suite. Every technical figure traces to a named survey artifact. Business context the survey cannot see is marked as an assumption.

Three findings changed what the owners should do first:

  1. Nothing in the portfolio would be on a fully supported runtime by year end. Three projects were already end-of-life, five were maintenance-only, and the healthy application's single runtime target had nine weeks of vendor support left.
  2. Verification was absent where it mattered most. No test reached any of the nine legacy areas, and the modern application's one untested area was also where 16 of its 37 migration-risk patterns sat.
  3. Each system's core was one person's work, and the code said what, not why. The survey lifted 168 business rules and found one enforced two different ways on two live code paths.
Read the sample Dossier
Library 2013 web app .NET 8 app
Modules / files3 / 2936 / 16614 / 318
History17 commits, 1 author24 commits, 3 authors, last change 2015641 commits, 83 authors
Runtime statusTest app end-of-life2 end-of-life, 5 maintenance-onlySupport ends in 9 weeks
Tests / areas reached0 / 0 of 20 / 0 of 745 / 5 of 6
Business rules lifted4320105
Migration-risk patterns121437
Proposed waves256

Automated and Partial figures from the survey of 2026-09-06. "Reaching tests" counts test files that touch an area; it is not a coverage percentage.

The loop

How a change lands

  1. MapIndex the code; compute the change surface and its obligations, including the file you forgot.
  2. PlanDecompose into small increments. You approve the plan first.
  3. PinWhere tests are thin, lock in current behavior with characterization tests.
  4. GenerateThe model writes the patch: scoped, example-anchored, treated as untrusted input.
  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.

One increment of many. A failed increment stops itself, with bounded retries and honest terminal states, and never takes the finished increments down with it.

Proof

A 27B model on one Mac built what a 2.8-trillion-parameter model needed four.

Same public challenge prompt. A complete, tested, six-route web product, planned, built, verified, and committed end-to-end by CodeLead orchestrating a small local model, with no human touching the code. The claim is not speed. The claim is that a fixed-cost laptop with no code leaving it produced a fully verified result unattended, and that the difference was the governance, not the model.

Read the case study
  • 3h 39mwall clock, unattended
  • 17 / 17increments verified, each gate-checked
  • 53 / 53unit tests written by the model, all passing
  • 0model errors across the whole run

Who builds it

Built by people who have lived through the migration.

CodeLead is built in Kirkland, Washington by former Amazon and Microsoft engineers who have spent years on systems at scale and on large VB6 and C# modernization projects: the kind where the original authors are gone, the tests are thin, and every change is a risk. It is the tooling we wished had existed on those projects.

Three U.S. provisional patent applications cover the core methods. The prototype is in active live testing with more than 1,500 automated tests, and its benchmark program runs continuously. Ask for a live demo. It fits on a laptop.

Built for

  • Software companies whose revenue depends on a product on .NET Framework, VB, or older Java
  • Consultancies that need per-client isolation and evidence they can hand over
  • Regulated and public-sector teams that must show how a change was verified
  • Any organization whose code cannot leave the building

Tell us about the system.

A few sentences on what it does, how old it is, what it's built on, and what's making the question urgent. We reply within one business day, and the first call is a diagnosis, not a pitch.

Request a Dossier proposal

Or run it yourself.

The CLI is in private beta. Tell us what you'd point it at and we'll email you when your seat is ready.

Request early access