How it works
The model proposes. CodeLead checks. Humans decide.
Every change travels the same path, whether it is a feature on a new app, a fix in a code base you maintain, or one step of a modernization. In a modernization engagement that path sits inside a three-stage method, and people stay in charge of every stage.
- 1 UnderstandRead-only. Map the system, its rules, its dependencies and its risks.
- 2 ModernizeOne small, verified increment at a time, with what must not break locked in first.
- 3 KeepA living map of the system and the evidence behind every change.
Any change · The loop
How a change lands
A request goes in. What comes out is a commit a person can read, or a refusal with its reason. Nothing in between reaches your files unchecked.
- MapFind the real blast radius of the change, including the file nobody mentioned.
- PlanBreak the work into small increments. People approve the plan first.
- Lock inWhere tests are thin, capture what the system does today so it cannot silently change.
- ProposeThe model writes the change, inside the scope it was given.
- CheckHard safety checks. Anything out of scope is refused, with a reason.
- ValidateBuild, tests and behavior checks, at the level you would check yourself.
- RecordA commit and an evidence record, so the reasoning survives the people.
Local first: the model runs on your hardware through LM Studio or Ollama, and your code stays there. Remote models are available when you choose them, and what goes to one leaves your machine. What the agent controls
In a modernization engagement · Stage 1 · Understand
Start read-only. Change nothing until the map is right.
The danger is not old code. The danger is unknown behavior. So the first stage touches nothing: CodeLead runs inside your environment, reads the code and its history, and logs every action it takes.
The output is the Legacy System Dossier: a written assessment with a receipt for every recommendation, and a plain label on every section saying whether the tool measured it, an engineer judged it, or it is still an assumption.
- The architecture
- What the system is made of, how the parts connect, and where data enters and leaves.
- The business rules
- Validation, pricing, workflow states and thresholds, lifted from the code with the line that enforces each one.
- The real blast radius
- What depends on what, which files always change together, and who breaks if a piece moves.
- The risks
- Unsupported runtimes, untested areas, and the coding patterns that make a change unsafe until they are cleared.
- The people
- Who holds the history, and what they know that the code never wrote down.
Stage 2 · Modernize
One verified increment at a time
The migration sequence from the Dossier becomes a series of small changes. Each one travels the loop above, with one addition: what must not break is locked in with tests before it is touched, and the same measurements run before and after. A change that fails stops itself without taking the finished ones down with it.
The goal is not a heroic rewrite. It is a sequence of changes the business can trust.
Who decides
People approve. The tool refuses.
CodeLead does not remove engineering judgment. It puts AI inside a controlled process: the model does the work, the tool refuses what it cannot show is safe, and your team keeps control. On your own code base that means approving the plan and anything risky. In an engagement, the list is written down.
In an engagement, people approve
- The goal
- The plan
- The scope of each change
- Dependency changes
- Data and schema changes
- Anything destructive
- The validation results
- The final recommendations
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.
Stage 3 · Keep
The migration ends. The map stays.
The tests that lock in behavior, the evidence records, and the living map of the system stay in your repository, whether or not you ever work with us again.
The same read-only survey can run again whenever you want, so drift shows up as a difference against a known baseline rather than as a surprise.
Facts are separated from guesses
Every entry in the knowledge base carries a trust level and the evidence behind it. A fourteen-times-verified build command and a hallway rumor are visibly different things, and a document the code contradicts gets flagged instead of believed.
Why AI helps here
The model does not need to be a genius when the process is disciplined.
CodeLead is built against two common assumptions.
- That small and medium local models are useless for serious engineering work. Decomposed, scoped and validated one step at a time, they do more useful work than most teams expect.
- That getting close to frontier results locally takes a huge investment. Our case-study build ran on a single laptop.
Neither point says local models beat frontier models at everything. The claim is about better economics, better control, and getting more out of the model you already have.
Start with one code base.
Yours, in the private beta. Or a legacy system, with a fixed-scope, read-only assessment where nothing is modified.