My day job is maintaining a 20-year-old insurance system: over 1,000 PL/SQL packages, 2.3 million lines of code, Oracle Forms on top, and the same codebase running at more than 20 customer installations. Nine months ago I started routing my support tickets through AI agents in Claude Code. 108 tickets later, almost nothing I do is manual anymore. This post describes the workflow, the parts that keep it safe, and the loop that makes it better with every ticket.
Why this works on a legacy system
People assume AI tooling helps most on greenfield projects. My experience is the opposite. The pain in a legacy system is not writing code, it's finding context:
- Nobody knows the whole codebase. At 2.3 million lines, nobody can.
- The same code behaves differently per customer, controlled by hundreds of installation parameters. Half of my questions are "why does this work differently at customer X".
- Our helpdesk has about a million tickets from 20+ years. The answer to "have we solved this before?" is almost always yes. The problem is that it lives in a ticket from 2017, or in one paragraph of a manual nobody opened in three years.
- Knowledge is spread across five systems: the helpdesk, user manuals on a file share, a wiki, GitLab, and SVN.
Collecting that context by hand takes a senior developer half a day. An agent with the right tools does it in minutes. That's the whole trade.
The workflow: one command per ticket
When a new ticket arrives, I run a single analyze command. The agent then:
- Reads the ticket through the helpdesk's SOAP API, including attachments. PDFs, Word and Excel files get converted to text first.
- Searches for similar past tickets. Keyword search plus vector search, because the built-in helpdesk search only does keywords and misses anything phrased differently.
- Checks my library of ready-made SQL scripts for anything reusable.
- Looks at the relevant code in the database, and at its change history in GitLab or SVN if needed.
The output is a single markdown file, ANALIZA.md: all findings in one place, plus a proposed next step. The next step is always one of three things: a code fix, a reply to the customer, or more diagnostics on the customer's database.
Once there is enough data, the agent prepares the whole package: the proposed solution, a message for the customer, internal notes for colleagues involved in the ticket, the diagnostic and fix scripts, and a short write-up of why we did it this way. All of it gets attached to the ticket.
Skills are where the actual work went
The agent is only as good as the context you can hand it. Over nine months I built 24 skills. Grouped by function:
| Group | Examples |
|---|---|
| Context access | helpdesk API, vector search over tickets and 1,800 manuals, Oracle dev DB, GitLab fix archive (31,000+ commits), SVN for Forms, internal wiki |
| Domain knowledge | system architecture and its 13 business domains, insurance accounting mechanics, installation parameters, internal PL/SQL standards, our logging package |
| Writing and delivery | generating PL/SQL to our standards, packaging a fix, installing it on the dev database, recompiling invalid objects, compiling Forms |
| Meta | a skill that builds new skills from repeating patterns |
The meta one matters more than it sounds. Whenever I catch myself explaining the same thing to the agent twice, that explanation becomes a skill. The toolset grows as a side effect of normal work.
Two rules that keep it safe
Every generated script gets validated against the live schema. The most common LLM failure in SQL is inventing a table or column that almost exists. The fix is cheap: run EXPLAIN PLAN FOR <statement> against the dev database before the script leaves my hands. It parses the statement against the real data dictionary without executing anything, so it's safe even for UPDATE and DELETE. Invented objects fail immediately with ORA-00942 or ORA-00904.
Risky changes get a second engineer. For hard-to-reverse changes I hand the same task to a second, independent agent and compare findings. I use two: a different vendor's model for a genuinely independent view (different model, different blind spots), and a fresh session of the same model loaded with all our domain skills for domain-heavy reviews. What both find is almost certainly real. What only one finds, I check myself. On a small team, this is the closest thing to peer review I can get.
The loop that pays for everything
Here is the part I'd steal if I were reading this post.
Everything the agent produces gets attached back to the ticket: scripts, analysis, the reasoning behind the fix. When a similar ticket arrives next year, the vector search finds that old ticket, and the agent reads not just what we did, but why. Then a separate closing step extracts anything reusable into a script library. That library is now at 759 SQL templates in 32 topic folders, built up over years and finally searchable by an agent instead of just by me.
The result: every solved ticket makes the next one cheaper. No extra effort, no "knowledge management initiative". It happens as a byproduct of closing the ticket.
What still doesn't work
Honesty section. Three things are open:
- Testing is still manual. The agent speeds up writing a fix, not proving that the fix breaks nothing at the other 20 installations. That's still the biggest remaining risk.
- Metrics are thin. I have raw numbers (108 tickets, roughly 4,000 prompts, 94% of them on tickets) but no systematic before/after measurement of resolution time. I know it's faster. I can't prove by how much yet.
- Bus factor of one. The whole stack is built and configured on my machine. A colleague can't pick it up without a setup guide that doesn't exist yet.
Wrapping up
The key insight: on a large legacy system, the win from AI agents is not code generation. It's that context gathering, the half-day of digging through five systems before you write a single line, collapses to minutes. And if you route the results back into the ticket archive, the system compounds: every solved ticket becomes training material for the next one.
Top comments (0)