Topics / Engineering practice
Modernize legacy software by recovering one useful agreement at a time.
You do not need a complete specification before making progress. You do need to distinguish intended behavior from the accidents you discover.
Start where the next change is happening.
Pick a component, a business outcome and an owner who can resolve ambiguity. Gather code, tests, tickets, incident history and observed behavior. Record where each candidate requirement came from instead of converting every code path into an approved promise.
Illustrative example
The strange delay prevents a downstream failure.
An agent removes a sleep that looks unnecessary. An old incident explains that the downstream system exposes a record before it is ready to read. The lasting requirement is about readiness, not preserving a magic delay forever. Recover the reason, then choose a better implementation and a check.
Use uncertainty to direct the work.
| Finding | Next action |
|---|---|
| Clear accepted promise | Link it to implementation and evidence |
| Observed behavior with no authority | Ask whether it should be preserved |
| Conflicting sources | Record the conflict for a domain decision |
| Known failure | Keep a reproducer and an unresolved issue |
Let each completed change improve the model.
Proof retains requirements, hazards, prior changes and verification links in the Software Intent Graph. The next task can retrieve the reason a behavior exists rather than rediscovering it from scratch.
Measure the cost of recovery and the effort saved on the second change. A comprehensive-looking graph is not useful if nobody trusts its sources or can maintain its evidence.
Try it on your software
Choose the legacy component everyone hesitates to touch.
Bring one real change and the people or records that can explain its constraints.