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
From an agent’s intention to insight and code that works.
Powerful enough to let your AI agent split a million-line monolith into JPMS modules — the split, the tests, the module declarations and their visibility rules — without regressions.
Every item below is one instruction. The engine derives each edit that follows — call sites, imports, signatures, tests — and applies them together or not at all.
Understand
What depends on what, across the whole codebase — not one module at a time.
Trace a cycle to the single edge that causes it, then move that dependency rather than documenting it.
Where the codebase resists change, and why.
What is genuinely reachable from your real entry points, including reflection and frameworks.
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 split carried out.
Which interfaces you actually need to get where you are going — then every implementor and call site updated with them.
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 a Python script against the same model, not a feature request.
Where the budget goes
Let the agent think. Don’t pay it to read.
Most of an agent’s budget on a large codebase is spent loading files it will not change, and re-loading them after every edit. That work is not reasoning, and you are paying model rates for it.
Asking beats reading
One question against the model of your codebase 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 model is already current
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 compile. The agent is Claude Code. Input tokens were not counted in this round.
How you drive it
Scripted, visual, or through your agent.
Every analysis and every refactoring is a Python script against the 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.
Continuous · in your pipeline
Break the rule and the repair is already written.
A structural rule is only worth setting if something happens when it breaks. The check runs with your build, for as long as the repository lives — and the remediation is attached to the rule, not left as a ticket for later.
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 — not a file-level warning.
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 docsA level, not a verdict. Real code is rarely deeply immutable, and a yes/no answer throws away everything useful.