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.
The agent
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.
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
A walking skeleton first, then one capability per increment, each built, validated and committed. The Silicon Exchange run is this, unattended, on a laptop.
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.
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
Runs local models on hardware you control by default. With a local model, your source code stays on the machine it runs on.
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.
You approve the plan before anything is built. Dependency installs and commands wait for approval, and scope grows only when you say so.
An increment is not done until its build, tests and behavior checks pass. A failure stops that increment, not the whole run.
The model proposes; it never edits files directly. Every change passes hard safety checks first, and every refusal is recorded with its reason.
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
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.
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.
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.
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.
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
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.
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
You're the architect, the reviewer, and the on-call. CodeLead lets cheap local models do the typing while you keep the judgment.
You maintain the systems the demos avoid. CodeLead is built for your Tuesday.
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.
Downloads
The one-pager covers the five things CodeLead does that a raw agent does not, the loop a change travels through, and the evidence behind each claim. The Dossier shows the same method applied to three real legacy code bases.
Private beta
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.