AI, Perl Scripts · 2026.10.10

AI for Legacy Perl Code: What Helps and What Needs Checking

By Manu Mathew, Technical Lead Engineer · Published 10 October 2026 · Last updated 10 October 2026

You have a Perl script that has run quietly for years, and now it needs a change. Nobody remembers why half of it works the way it does. It is tempting to paste the whole file into an AI assistant and ask it to “modernise” the code.

Using AI for legacy Perl code can save real time, but only on the right jobs. This post covers where it helps, where it tends to go wrong, and the checks I keep in place before any AI-suggested change reaches production.

Quick answer

AI for legacy Perl code works best for reading and explaining old scripts, drafting tests, writing notes and suggesting small refactors. It is weakest on business rules, database changes, security and behaviour that depends on the live environment. Treat every suggestion as a draft: test it against current behaviour, review it line by line and release it in small steps.

Where does AI for legacy Perl code actually help?

It helps most with understanding, not with deciding. The jobs where it saves time are the ones a human can check quickly.

• Explaining dense code. Old Perl often packs a lot into one line: regular expressions, nested data structures, implicit variables. Asking for a plain-English walkthrough is a fast first read.
• Mapping a codebase. Listing the entry points, scheduled jobs, config files and database tables a script touches gives you a starting map.
• Drafting tests. It can propose test cases for the behaviour you describe, which you then run and correct.
• Writing documentation. Turning your findings into a readable note or a comment block is a good use of a tool that writes quickly.
• Small, mechanical tidy-ups. Fixing what use strict and use warnings report, renaming unclear variables or splitting a long subroutine, each as its own reviewed change.

The common thread is that you can verify the output. An explanation can be checked against the code; a test either passes or it doesn’t.

Where does AI get legacy Perl wrong?

It struggles wherever the right answer lives outside the code it can see. Old systems are full of those places.

1. Business rules. A strange rounding step or date check may be there because of a contract or a regulator. The assistant sees odd code; it can’t see the reason.
2. Context-sensitive behaviour. Perl can behave differently depending on list or scalar context, locale, encoding and the version installed on the server. Suggestions often assume a cleaner environment than the one you run.
3. Database changes. A rewritten query can look equivalent and still return different rows, lock tables or slow a busy report.
4. Security. Generated code may build shell commands or SQL from user input, or drop checks that the old code quietly relied on. The perlsec documentation is still the best reference for what to watch.
5. Confident invention. Assistants sometimes suggest functions or options that don’t exist, or that exist only in a newer Perl than yours.

None of this makes the tools useless. It means the output is a first draft from someone who has never seen your production server.

What should a human always check before an AI change goes live?

Check behaviour, data, security and rollback. Those four catch most of the problems AI-assisted Perl maintenance introduces.

The behaviour check matters most. If you capture what the old code produces before you change it, you can compare the new version against it. I wrote about that approach in testing legacy Perl code before you change it.

Is it safe to paste company Perl code into an AI tool?

Only if your organisation allows it and you strip anything sensitive first. Code often holds more than logic.

Before sharing any file, look for:

• Credentials such as database passwords, API keys and tokens, often hard-coded in old scripts.
• Customer or patient data in sample files, comments or test fixtures.
• Internal hostnames and paths that describe your infrastructure.

Check which tool your company has approved and what it does with the code you send. The OWASP guidance on generative AI risks is a useful reference for the wider security questions. When in doubt, share a small, cleaned excerpt instead of the whole repository.

How do I use AI on client Perl work?

I use it as a reading and drafting aid, and I keep every change small, tested and reviewable. The client decides what tools are allowed on their code.

My usual pattern:

• Agree the rules first. Before I touch any code, I ask whether AI tools are allowed and which ones. If the answer is no, I work without them.
• Read before changing. I use an assistant to speed up the first pass through unfamiliar code, then confirm what it says by reading and running the code myself.
• Capture current behaviour. Tests or saved outputs come before any edit, so we can see whether anything moved.
• One change per review. Each change is small enough to read in a few minutes, with a short note on what changed and how it was tested.
• Write it down. Findings go into notes in the repository, so the next person doesn’t have to rediscover them.

AI-assisted development is part of my day-to-day work, and the habit that matters most is the same as without it: nothing goes live because a tool sounded sure.

Frequently asked questions

Can AI rewrite an old Perl application in another language?

It can draft pieces, but a full rewrite still needs people who understand the business rules, data and edge cases. Generated code that looks complete often misses behaviour nobody wrote down. A gradual approach, with tests comparing old and new output at each step, is usually far safer than a single large rewrite.

Will AI tools replace Perl developers for legacy systems?

Not for systems that matter to the business. AI speeds up reading, drafting and documenting, but someone still has to understand the context, judge the risk and own the release. It changes how a Perl developer spends time more than whether one is needed.

Which AI assistant is best for Perl?

There is no single answer, and tools change quickly. What matters more is that your organisation has approved the tool, that it handles your code under acceptable terms, and that its suggestions are tested. Try two or three on a small, non-sensitive task and compare how often their answers hold up.

Does AI understand very old Perl styles?

Mostly, yes. Assistants usually explain older idioms, formats and global variables reasonably well, but they may suggest fixes that need a newer Perl than your server runs. Always check the Perl version in production and test suggestions against it before relying on them.

How do I start using AI on our Perl code safely?

Start with read-only tasks: ask it to explain a script or draft notes, and compare its answers with what you know. Then move to drafting tests. Leave code changes until you have a way to compare old and new behaviour, and keep every change small and reviewed.

Related reading: Hiring a remote Perl developer; Where Perl still belongs.

Need help with an old Perl system?

If you have Perl code that needs fixing, extending or upgrading, I’m happy to take a look, with or without AI tools depending on your rules. The Perl development page covers the kinds of work I take on, including careful moves from old CGI apps to a modern setup.

You can reach me through the contact section or email me at manu@manu.co.in. A few lines about the system and what you need is a good start.

Back to the blog