A map of the old system
What each area does, what depends on it, and which parts are still genuinely unknown.
Use case
AI employees for legacy modernization.
The hard part was never writing the new system. It is that nobody left in the building can tell you why the old one behaves the way it does. An AI employee rebuilds that understanding from the code, the tickets and the incidents, keeps it in your organizational memory, and then migrates the system one approved step at a time.
No credit card required.
The problem
The system still runs the business. The people who built it are gone.
Every large organisation has one: the platform that predates the current architecture, the current framework, and most of the current team.
It handles billing, or settlement, or order routing — something the company cannot switch off for an afternoon. It works. It has worked for years. And every time someone proposes replacing it, the estimate comes back enormous and the project quietly slips to next year, because the only honest answer to “what does it actually do?” is a shrug and a pointer at forty thousand lines of code.
Look closely and the blocker is rarely technical. Your team can write a modern service. What they cannot do is tell you whether that odd branch in the pricing routine is a bug or the reason a regulator stopped asking questions in 2019. The commit says “fix.” The person who wrote it left two reorganisations ago. The ticket, if it still exists, links to a wiki that was migrated and lost.
So the system accretes. Nobody deletes the strange branch, because nobody can prove it is safe to delete. Nobody refactors the module, because the blast radius is unknown. New work routes around the old code instead of through it, and the workaround becomes permanent. The cost is not one big number in a business case — it is a small tax on everything, paid every sprint, forever.
You are not blocked on writing new code. You are blocked on knowing what the old code means.
What changes
Memory is what makes a migration finishable.
The reason modernization projects stall is that understanding evaporates faster than it accumulates. Fix that and the rest is ordinary engineering.
Understanding is reconstructed, not guessed
An AI employee reads the codebase, but it also reads what surrounds the codebase: the commit history, the tickets that caused each change, the incidents the system has caused, the decisions recorded in email, Slack and Jira. Those sources together usually explain the strange branch. One of them almost always names the constraint that produced it.
Understanding is kept, not re-earned
What it learns goes into your organizational memory — a living record of your systems, decisions and past incidents that every one of your AI employees shares. The second question about that module is cheaper than the first. Six months in, work compounds instead of restarting, which is the opposite of how modernization projects normally behave.
Readscode, commits, tickets, incidents, decisions
Keepsthe reasoning, not just the diff
Shipsone reviewed increment at a time
The migration itself is deliberately boring. New code sits behind a facade; one behaviour moves across at a time; the old path stays available until the new one is proven. That is the strangler-fig pattern, and it has always been the right approach — it just needs more patient, sustained attention than a busy team can usually spare. That attention is the thing an AI employee is actually good at.
How it works in practice
Four steps, repeated until the old system is empty.
-
1
Map the system
The AI employee reads the repository, the change history and the ticket trail, then writes down what each area does, what depends on it, and where the reasoning is missing. You get a map with the unknowns marked as unknown rather than smoothed over.
-
2
Pin the behaviour
Before anything moves, it writes characterisation tests around the slice you have chosen — tests that describe what the system does today, including the parts nobody intended. Those tests are reviewed by your engineers and become the contract the migration has to honour.
-
3
Move one slice
A single behaviour is reimplemented behind the facade, run against the pinned tests, and opened as a pull request like any other change. It is small on purpose: small enough that a reviewer can hold the whole thing in their head, and small enough to reverse.
-
4
Approve, ship, record
A human approves the deployment. What was learned — why that branch existed, what broke in staging, which assumption turned out to be wrong — goes into organizational memory before the next slice starts. Then it repeats.
What stays under human control
Nothing reaches the system of record without a person saying yes.
Modernizing a load-bearing system is exactly where autonomy should be narrow and reviewable. Every action is logged.
AI executes
- Read the codebase, history and ticket trail
- Reconstruct and record why the system behaves as it does
- Write characterisation and regression tests
- Reimplement a slice behind the facade
- Run the suite and open the pull request
- Draft the migration notes and rollback plan
Humans approve
- What gets modernized, and in what order
- The target architecture
- Every pull request, reviewed as normal
- Production deployments and cutovers
- Security-sensitive and infrastructure changes
- Retiring any part of the old system
What you get
Specific things that exist afterwards.
The reasoning, written down
Why the odd branches exist, reconstructed from history and kept in organizational memory.
A test suite where there wasn’t one
Characterisation tests that pin current behaviour before anything is allowed to change.
Incremental, reversible migration
Strangler-fig slices behind a facade. No cutover weekend, no all-or-nothing bet.
A reviewable trail
Every change a pull request, every approval logged — useful long after the project.
Memory that outlives the project
The understanding stays in your business when the migration ends and the team moves on.
What this does not do
It does not decide what to modernize. Whether a system should be replaced, rewritten, wrapped, or simply left alone for another three years is an architectural and commercial judgement, and it belongs to your architects and your business. An AI employee makes that judgement better informed — it can tell you what the old system actually does before you commit — but it does not make it for you. It also will not turn a six-month migration into a weekend. It makes the work continuous and the knowledge permanent, which is a different and more useful promise.
FAQ
The questions engineering leaders ask first.
Can an AI employee rewrite our legacy system for us?
Not in one go, and you should be wary of anything that claims otherwise. An AI employee works the way a careful team works: it reads the system, records what it learns, and then migrates one behaviour at a time behind a facade, with tests and a human review on every change. The rewrite is an outcome of many small approved steps, not a single event.
How does it understand code written by people who left?
It reads more than the code. It reads the commit history, the tickets that caused each change, the incidents the system caused, and the decisions recorded around it. That reconstructed reasoning goes into your organizational memory, so the next question about that module is answered from what was learned, not guessed at again.
What if the legacy system has no tests?
That is the usual case. Characterisation tests come first: the AI employee writes tests that pin down what the current system actually does, including the behaviour nobody intended, so that a migration can be proven not to change it. Those tests are reviewed like any other change before they become the safety net.
Does anything get deployed without a human approving it?
No. Production deployments, security-sensitive changes and infrastructure changes always require human approval. The AI employee investigates, builds, tests and prepares the deployment; a person decides whether it ships. Every action is logged.
Do we have to give it access to everything?
No. Access is least-privilege and scoped by you — you choose the repositories, the ticketing projects and the environments an AI employee can reach. Data is encrypted with TLS 1.2+ in transit and AES-256 at rest, with SSO, role-based access control, per-tenant isolation and a full audit trail. See the security page.
What happens to the understanding when the project ends?
It stays. Everything learned about the old system lives in your organizational memory, shared across your AI employees and available to your people. That is the difference from a consulting engagement: when the migration finishes, the knowledge does not leave with the team that did it.
Get started
Point one AI employee at the system nobody wants to touch.
Start with a single module. See what it can tell you about code your team inherited — before you commit to anything.
No credit card required.