Evidence

Reports and measurements

Things we have actually done with the engine, written up in detail. Worth reading if you want to know more, or to check the numbers for yourself.

2026-09Demonstration

Isolating third-party libraries in four open-source Java projects

CodeLaser isolated 28 third-party libraries across Caffeine, Timefold Solver, Trino and QuestDB. Each is now named in only one small layer the project owns. All 28 compiled without breaking a passing test.

From 26K references in Caffeine to 361K in Trino, tests included. For each library the report says what a tool can change, what needs a developer, and what the interface would cost to own.

Read the full report →PDF

2026-10Benchmark

Dead-code removal on four open-source Java projects: the CodeLaser engine against Claude Code

The CodeLaser engine and Claude Code were given the same four open-source Java projects, the same list of what the outside world can reach, and the same instruction: remove everything that is unreachable, and leave a project that still builds. Each was measured on time, cost, and whether the project still built and passed its tests afterwards. Both found largely the same dead code; Claude Code removed far more on top of it, and every error in the report comes from those extra removals. The engine was up to 14 times faster, used no tokens and broke no test. Claude Code’s results compiled, but in five of its six attempts it broke a build, a test suite or a public API.

Read the full report →PDF

2026-09Demonstration

Reducing the dependency loop inside Apache Ignite’s core

ignite-core is a single artifact of 5,632 classes, and 2,476 of them depended on each other in a loop. The loop was reduced to 483 classes, and the management commands became a Maven module of their own.

65 commits, each building cleanly across all 43 modules. Every step was predicted before it was made and measured after.

Read the full report →PDF

2026-08Demonstration

Separating timefold-solver-core into nine modules

978 classes in one artifact depended on each other in a loop, and a module has to be built before whatever uses it — so no boundary could be drawn anywhere in it. The loop was reduced until it could, and the result is nine modules that build in a fixed order.

A control build was held at a fixed commit and never written to, and the whole project was compared against it after each step, module by module rather than on totals · 369 runs of 276 scripts, 50 commits, 1,861 files changed · 102 predictions made and scored before the work, 84 exactly right

Read the full report →PDF