How AI changes legacy PHP work
Faster, cheaper and safer, but only with the right safeguards.
Most of the cost of legacy work was never writing code. It was working out what the code does: reading thousands of files, tracing unfamiliar paths, and reconstructing decisions nobody wrote down. AI is very good at that part.
It is also very good at confidently producing plausible nonsense. So the value isn't "I use AI". It's knowing exactly where to trust it, where not to, and how to check.
What AI speeds up
| Task | Before | Now |
|---|---|---|
| Understanding an unfamiliar codebase | Days or weeks of manual reading | Often hours |
| Tracing a bug through old code | Days or weeks of searching | Can sometimes be isolated in minutes |
| Documenting architecture, database and workflows | Weeks, if it was ever done | Generated in hours, then checked against the real system |
| Finding likely security weaknesses | Slow manual review | Rapid first-pass discovery, then human verification |
| Spotting PHP upgrade incompatibilities | Trial and error in production | Mapped up front across the codebase |
| Writing tests around existing behaviour | Often skipped as too expensive | Practical and affordable again |
These are real changes in what's economic. Work that used to be too expensive to justify, such as documenting a 20-year-old system or adding tests to code nobody dares touch, is now realistic.
In practice, the AI does the legwork and I make the decisions. It reads through the codebase to identify where a bug or risk lives, traces how data and logic flow between files, and proposes a fix or repair. I review every suggestion against 25 years of PHP experience, test it, and only then does it go anywhere near your live system. Nothing changes on the AI's say-so alone.
What AI doesn't change
AI is fast. It isn't responsible. The hard parts of legacy work remain human:
- Undocumented business rules. The code shows what happens, not why. A strange discount rule or customer exception may be critical, or may be a fifteen-year-old mistake. Deciding which takes judgement and, often, a conversation with you.
- Knowing what not to touch. Some ugly code is load-bearing. Experience tells you which.
- Production risk. A change that looks correct can still break a month-end report or a payment integration.
- Accountability. If something goes wrong, you need a person who answers for it, not a tool.
How I keep AI-assisted changes safe
1. Understand before changing. I map the system and establish how it behaves before anything is modified.
2. Tests first. Where critical behaviour isn't covered, I write tests that capture what the system does today (so-called characterisation tests). They're the safety net that tells us if a change alters something it shouldn't.
3. A person reviews every significant change. AI suggestions are drafts. I read, understand and verify them. Nothing significant goes into your system that I haven't understood.
4. Verify against reality. Documentation and findings are checked against the running application, not treated as automatically correct.
5. Version control and small steps. Changes are made in small, reviewable, reversible pieces.
6. Staged rollouts. Changes go to a test or staging environment first, then to production in a controlled way, with a rollback plan.
7. No unsupervised AI on production. AI tools don't have free access to your live systems, databases or credentials.
How your code and data are handled
Buyers are right to ask this, so here is the straight answer.
Principles I work to:
- Your code is confidential. It's used only for your project, and I'll sign an NDA before seeing it if you wish.
- Production data and personal data stay out of AI tools wherever possible. I prefer sanitised, limited or synthetic data for analysis.
- Credentials and secrets are never given to AI tools. They're removed or masked first.
- AI tools with appropriate data-handling terms only. Tools vary by project; each is used under business-appropriate terms and settings, and I'll tell you which are in use on request. Data Protection Policy
- You can opt out. If your policy or your clients' policy prohibits AI tools on certain systems or data, tell me, and I'll work to that.
- Everything is documented. I'll explain in writing how your code and data are handled before work starts, and a data processing agreement can be put in place.
- Access is removed at the end and copies are deleted. How I handle access
I provide technical engineering and security remediation, not legal advice or outsourced Data Protection Officer services. If your obligations under UK GDPR (or EU GDPR, for clients in France and Spain) need legal interpretation, take advice from a qualified specialist. Data protection and security
What this means for what you pay
You shouldn't pay for time that no longer needs to be spent. That's why I publish prices, quote fixed prices where scope is clear, and don't bill by the hour for defined work. The speed-up goes to you in lower costs and in work that was previously unaffordable becoming possible. See pricing
Frequently asked questions
Isn't this just running your code through ChatGPT?
No. AI is one tool, used for analysis and drafting. The process around it (mapping first, tests, human review, staged rollout) is what makes the result trustworthy. Twenty-five years of PHP experience is what tells me when the output is wrong.
Is AI-generated code reliable?
Not on its own. That's why every significant change is understood, reviewed and tested before it goes live. I treat AI output as a draft from a fast but fallible junior colleague.
Will you use my code to train AI models?
No. I don't train models on client code. How the tools I use handle data is covered above, and I'll confirm it in writing before work begins.
Can I ask you not to use AI on my system?
Yes. It will take longer and cost more, but if your policy requires it, I'll work without it, and I'll tell you honestly how that changes the scope and price.
How much faster is it really?
It varies. Some tasks are dramatically faster, such as tracing a bug or documenting a system. Others, such as business decisions, testing in production-like conditions and client sign-off, aren't much faster at all. I'll tell you where the saving is real for your system.
Is the documentation reliable?
It's generated quickly and then checked against the actual application, so it's reliable to the extent that it has been verified. I'll tell you which parts have been checked and which haven't.
Tell me what you've inherited.
If you've been quoted weeks of investigation for a system nobody understands, a conversation could change the economics.
Book a free conversationLegacy System Assessment, from £2,500