Ingestion, the system model and clarification for one language pair. No code is written and no write access is required, so it clears security review in weeks rather than never.
Assess, prove, execute, decide, transform.
In that order, because each phase is only worth building once the one before it has earned trust. The parts everyone wants on day one are attempted last.
- Now
- Phase one, one language pair, read-only
- First pair
- Java with Oracle to a modern JVM stack. .NET Framework second
- Standalone
- Phases one and two each sell on their own
Characterization tests for untested legacy code. Still purely additive, nothing changes behaviour, and it is the prerequisite for every phase after it.
Narrow scope on purpose: dependency upgrades, dead code removal, test backfill. Agent-authored pull requests, human review, differential replay before merge.
Migration decisions with constraint propagation. Recommendations are only worth reading once the model they rest on has been checked against reality.
Agent execution on service extraction, schema migration and framework replacement. The genuinely hard work, attempted with a model and a safety net rather than without.
Three families, and only one of them is allowed to matter most.
Evidence depth per module. Proportion of live code covered by a confirmed rule. Clarification compression ratio, targeting better than fifteen to one. Median time to answer, by role.
Tasks verified per week. Agent completion rate without a human takeover. Time from a task becoming ready to the change being merged.
The ones that matterUnexplained differences reaching merge, target zero. Assumptions outstanding at cutover, target zero. Production defects traceable to a wrong or missing assertion.
Anti-metrics.
Do not optimise for questions answered, tasks generated, or lines migrated. Each of those produces a mill that looks busy and delivers nothing, and each is the number a struggling programme reaches for.
What could sink this, and what is being done about it.
| Risk | Severity | Mitigation |
|---|---|---|
| Verification is the hardest component and gates everything | Critical | Build it first. Ship test generation as a standalone product before any agent writes code. |
| Useful depth across any language is not achievable | Critical | Ship one source and target pair. Tier support honestly and cap claimed confidence by tier. |
| Blocking freezes the programme | Critical | A precise dependency graph keeps blocks narrow. Blocks are explained and traversable, experiments provide an unblock path, and override is documented. |
| Question fatigue kills adoption | High | Clustering, a per-person concurrency cap, the stakes line on every question, and session framing. |
| Sandbox cost per agent-hour destroys margin | High | Aggressive snapshotting, hibernation, per-task compute budgets, and cost shown live in the run view. |
| Enterprises refuse production access | High | Degraded modes with the cost of each gap stated. Snapshot ingestion. On-premises from day one. |
| Incumbents extend into this space | Medium | The evidence join and the verification loop are the defensible parts. The editor never was. |
Still open.
A product built on refusing to guess should not pretend its own design is settled.
Java with Oracle moving to a modern JVM stack has the largest market and the best existing tooling to build on. .NET Framework is the obvious second. Committing to one pair is what makes the depth claim honest, and choosing wrong costs a year.
Without runtime evidence the central join does not function, and the product degrades into a static analyzer with better prose. There is a level of instrumentation below which the platform should decline the engagement rather than deliver a weaker version of itself. Where that line sits is not yet decided.
A named owner with a date may be sufficient, and adding approval chains may simply reproduce the meeting culture the decision record was meant to replace. The counter-argument is regulated industries, where an unapproved architectural choice is not a choice at all.
Analyzer improvements and assertion patterns get better with every system seen, and none of that may leak anything customer-specific. The separation between a generalisable detector and a customer's business rule needs to be structural, not a review step.
Per system assessed, per seat, per agent-hour, or per verified task. Each one drives very different product behaviour, and per verified task is the only one whose incentives point the same direction as the safety metrics.