The easiest AI demo is one that produces code. The harder and more valuable system is the one that helps a team decide what that code means, what has actually been checked and what must still happen before anyone trusts it with production traffic.
The dangerous collapse
In legacy modernisation, automated validation is essential. A generated service should compile. Its expected files should exist. Contracts should be internally consistent. Tests should run. Known anti-patterns should be detectable.
But those checks answer bounded questions. They do not prove that a translated write path has the correct operational owner, that replay is safe, that a downstream team accepts the new contract or that shadow traffic has reached parity with the legacy behaviour.
Green validators are evidence. Production readiness is a decision made from evidence.
Four states, not one
A useful modernisation workflow separates progress into states that cannot be accidentally collapsed into a single green badge.
Generated
The target structure and implementation exist.
Validator-clean
Deterministic structural and contract checks pass.
Runtime-proven
A bounded scenario executes with observable evidence.
Release-ready
Remaining operational and ownership decisions are resolved for the intended environment.
The sequence is not bureaucracy. It prevents a local demonstration from being described as production proof, and it gives reviewers a shared vocabulary for the exact state of a service.
Keep provenance visible
Reviewability starts before the pull request. If model-authored logic blends silently into handwritten code, the reviewer cannot direct attention according to risk. The codebase should preserve where judgement was delegated, which specification informed the result and which parts still require human confirmation.
This does not mean treating every generated line as suspicious forever. It means making uncertainty inspectable while it matters. Provenance can be reduced after review, but it cannot be reconstructed reliably after it has been erased.
A practical rule
If a model had to infer business behaviour, mark that boundary and require a named reviewer to resolve it.
Design the handoff
The handoff report is where technical evidence becomes a delivery decision. It should say more than “passed” or “failed”. For every unresolved item, it should make four things explicit:
- the decision or uncertainty that remains;
- the evidence already collected;
- the team or role that owns the next action;
- the environment or release stage that the item blocks.
That structure changes the conversation. Engineering can distinguish code defects from architecture decisions. QA can see which scenarios still need proof. Operations can identify missing runtime configuration or observability. Product owners can understand why a service that looks complete is not ready for cutover.
AI should increase clarity
Speed matters, but producing code faster is not the most interesting outcome of AI-assisted engineering. The larger opportunity is to make the development process more explicit: reusable project knowledge, consistent checks, visible assumptions and handoffs that show their reasoning.
The standard I use is simple: AI should leave a team with more clarity than it found. If it only leaves more code, the expensive part of the work has merely moved downstream.