01 · graphs
Where does the system split?
Put every method, call and table access into a code property graph. Graph algorithms show where the domains divide, and how thin the interface between them is.
Work · research direction
AI shouldn’t write your code.
It should write the tools that do. Parsers, graphs, runtime probes and solvers tell you the truth about a system. The agent only orchestrates them.
Software engineering and compiler design already have the discipline: ASTs program graphs runtime analysis formal proofs. I want agents to work through them, instead of just writing code and hoping.
In practice
Most of this comes from moving legacy rule engines and old enterprise Java onto new systems.
The recurring job: extract the business logic, then prove the new system still follows it.
The examples below are illustrations, not data from real systems.
02 · symbolic analysis
Are these two rules the same rule?
Code can look different and do the same thing. Turn each condition into a formula and a solver answers whether they are equivalent, and what the merged form is.
age >= 18 && income > 50000 !(age < 18) && income - 50000 > 0 solver
≡ same rule
age ≥ 18 ∧ income > 50 000 03 · runtime analysis
What does it actually do?
Sometimes I only have part of the source. The agent uses Javassist to inject a probe or a controlled fault into the bytecode, runs the system, and we read the business rule off what happens.
Project work, not yet published.
PremiumService.quote(Applicant a) aload_1+ Probe.record(a.age, a.region) invokevirtual rate(...)
age=17 region=N → REJECT age=18 region=N → 1,200 age=18 region=S → 1,380
rule: age < 18 → reject
04 · assets as inputs
What has to stay true?
A rule engine’s test scenarios already say “for these inputs, these outputs”. Rather than have an LLM read them, the agent writes a reader. The data it produces drives code generation and the checks on the replacement.
scenarios.xlsx→reader.pyagent-written→replacement| age | region | expect | replacement |
|---|---|---|---|
| 17 | N | REJECT | ✓ |
| 18 | N | 1,200 | ✓ |
| 18 | S | 1,380 | ✓ |
| 65 | S | 1,610 | ✗ 1,380 |
What I want to study
How do you trust a tool an agent wrote?
Code that runs the same way every time also repeats its mistakes every time. I check agent-written tools against independent examples and the running system. I want to turn that from something I do per project into a repeatable engineering process.
Combining static and dynamic analysis is an old idea (Ernst, 2003). What I want to add is the agent closing the loop: it reads the static graph, finds where it is blind, writes a probe, and puts what it observes back into the same graph.
BigCorp: the sample legacy estate I test on ↗How I got here
Earlier work, in order.
- 2023 Code generation with templates vs ASTs
- 2024 codemapper: indexing a codebase by its structure, with LLM summaries
- 2024 Graphs for navigating customs classification
- 2025 Tiny team × AI: prototype to production
- 2026 Coding agents designing their own evals
- 2026 BigCorp: a synthetic legacy estate to test these methods on
- 2026 Modernizr: agent skills over code property graphs
- 2026 KIE Agent Tools: semantic CLIs for rule and decision assets
- 2026 ARL frontend for Joern: compiled business rules as a graph