The agent thinks. The engine computes.
Deterministic Java refactoring, at scale.
CodeLaser is not an AI. It is the engine that carries out what your agent decides — every call site, every edit — the same way every time, and at a fraction of the tokens.
The toolbox
A direct line between an agent’s intention and code that works.
To extract a module out of your monolith, clear out code that nothing reaches, or cut a two-hundred-method class down to size, your agent has to start reasoning at the level of the operations it wants to perform, rather than every code change they require. That is what CodeLaser gives it. The agent becomes a manager of smart operations, not just a coder.
Example operations
Understand
What depends on what, across the whole codebase.
Trace a cycle to the critical edges that cause it, then move those dependencies rather than documenting them.
Where the codebase resists change, and why.
What is genuinely reachable from your entry points.
What changes where, and what is only read — the difference that decides what can safely move.
Restructure
Suggested seams based on how the members actually cluster — then the optimal split performed without regression.
Calculate and extract the optimal interfaces fit for purpose, and roll them out across the codebase in full detail.
Methods, fields, classes, whole packages. References rewritten, imports fixed.
Including the places a text search would miss, and skipping the ones it would wrongly hit.
Clean up
Whole clusters in one operation, with parameters, types and interfaces rippled correctly.
Collapse redundant constructors and the call chains that grew around them.
These are the operations that come up most. The engine is general — a new one is just another Python script against the same code model.
Where the budget goes
Let the agent think. Don’t pay it to read.
Most of an agent’s budget on large codebase changes is spent loading files it will not change. Changing code often becomes a trial-and-error process with frequent recompiles and retries. That work is not reasoning, and you are paying model rates for it.
Asking beats reading
One question against the code model replaces pulling hundreds of files into context — and the answer is exact rather than inferred.
The engine writes the edit
Your agent says what it wants. It never has to emit a four-thousand-line diff and hope every call site was caught.
The code model is always up-to-date
No re-reading the tree after every change to work out what moved.
Same job, both ways
The same job given to a coding agent and to the engine: cut twenty-five over-long Java methods down to size, same targets, no developer editing code.
Twenty-five over-long methods from three open-source Java projects. Same settings both sides: target 60 lines, minimum extractable 15. All twenty-five landed without regression. The agent is Claude Code. Token figures are indicative, pending a fuller measurement.
How you drive it
Three ways to drive it.
Every analysis and every refactoring is a Python script against the code model. Your agent writes them; you keep them, version them and hand them to someone else.
Scripts compose into flows — named steps with live results, re-runnable, and the same flow you built in a session is the one that runs in CI.
And where the answer needs a person, there is one. The workbench shows the insight behind a finding — the graph, the call sites, the source — so you confirm what is genuinely dead before anything is removed.
Structural rules
A rule can carry its own repair.
A structural rule is only worth setting if something happens when it breaks. The rule can carry a plan that repairs it, and because the operations are generic over the types they act on, that plan still proposes a valid change against the code as it stands rather than the version the rule was written for.
When one appears, the pull request names the edge that caused it and the move that removes it.
The offending import is flagged with the change that fixes it, already written.
New unreachable members are listed on the PR with a removal script attached.
When it does, a split is proposed against the shape the class has today.
Every push and every pull request, as a check on the branch.
The rule that tripped, and the exact edge, import or member responsible, down to the exact member.
The script that repairs it, run against the shape the codebase has today rather than when the rule was written.
Open source
maddi
The analyzer underneath the engine is open source. It works out what is actually immutable in a Java codebase — and tells you why it isn’t. The work started in 2020 as e2immu.
Read the docsHow far each type got. Real code is rarely deeply immutable, and a yes/no answer throws away everything useful.