The pressure is real. Boards and leadership teams across the industry are asking the same question: if AI makes developers significantly more productive, do we still need as many of them?

The answer, in principle, is no. In practice, it depends entirely on the state of your codebase — and most PHP codebases are not ready.

Why AI productivity gains don't apply uniformly

AI coding tools — Copilot, Cursor, Claude Code — genuinely accelerate development on well-structured, modern codebases. They can suggest implementations, catch bugs, generate tests, and navigate unfamiliar code quickly. The productivity gains are real.

But these tools have a critical dependency: context. They work by understanding the code around them. The smaller, cleaner, and more consistently structured your codebase, the more effectively they operate.

Legacy PHP codebases tend to be the opposite. Inconsistent patterns across years of development, raw SQL scattered throughout application logic, undocumented workarounds, missing type declarations, deeply coupled modules with no clear boundaries. In a codebase like this, an AI tool gets lost in the same way a new developer does — except it can't ask questions.

The result: the productivity multiplier that justified your headcount reduction doesn't materialise. Your smaller team is now trying to maintain a complex legacy system with tools that can't effectively assist them.

The headcount math only works after modernisation

Consider a team of five PHP developers maintaining a legacy application. Leadership wants to reduce to three, using AI tools to cover the gap. That requires each remaining developer to be roughly 67% more productive — a reasonable expectation with good tooling on a clean codebase.

But if the codebase is legacy, the AI tools contribute a fraction of their potential. The remaining team spends their time firefighting bugs, navigating undocumented code, and manually making changes that should be automated. Turnover follows. The developers who remain are the ones with the fewest options, not the most capable.

The headcount reduction that was supposed to save money ends up costing significantly more — in turnover, in slower delivery, in bugs reaching production, and eventually in emergency consultancy to stabilise what's left.

The sequence matters. Modernise first. Reduce headcount second.

What modernisation actually involves

The good news is that PHP modernisation at this level is largely automatable. It does not require months of manual refactoring by senior developers. It requires the right tooling and the experience to apply it safely.

A structured modernisation engagement covers three areas:

1. Codebase assessment

Before any changes are made, Migrator analyses the full codebase and produces a structured report: PHP version compatibility, dependency state, complexity hotspots, and upgrade risk by version step. This gives leadership a data-driven picture of what they're working with — replacing guesswork with a concrete scope and timeline.

composer require kerrialn/migrator
vendor/bin/migrator analyse

2. Automated refactoring with Rector

Rector applies automated transformations across the entire codebase: upgrading PHP syntax, adding type declarations, removing dead code, enforcing modern patterns. What would take a developer weeks to do manually, Rector executes in hours — consistently, without introducing new bugs, and with a full diff to review before anything is merged.

A typical engagement works through version steps incrementally, merging each step independently so there is never a large, high-risk upgrade branch:

composer require --dev rector/rector
vendor/bin/rector process --dry-run

3. Database layer modernisation

Raw SQL embedded throughout application logic is one of the most common sources of fragility in legacy PHP systems. Indoctrinate systematically identifies and converts these to type-safe Doctrine ORM — removing a class of bugs, enabling static analysis, and making the database layer legible to both developers and AI tools.

composer require kerrialn/indoctrinate
php bin/indoctrinate fix --dry
php bin/indoctrinate fix

Once these three areas are addressed, PHPStan and Easy Coding Standard are integrated into CI as permanent quality gates. Every subsequent PR is checked automatically. The quality floor of the codebase can no longer drop.

What you get at the end

After a modernisation engagement, you have a codebase where:

  • AI tools can reason about code effectively, because the patterns are consistent and the types are explicit
  • New developers can onboard in days rather than months, because the architecture is legible
  • A smaller team can genuinely maintain and extend the system, because the automated quality pipeline does the work that previously required experience to get right
  • Headcount decisions can be made with confidence, because the foundation supports them

The six months you invest in modernisation will typically recover their cost within the first quarter of operating with a leaner, AI-assisted team.

The window is now

The companies that modernise their PHP systems in 2026 will be the ones positioned to operate efficiently as AI tooling continues to mature. Those that reduce headcount first — without addressing the underlying codebase quality — will find themselves spending more, not less, over the next two years.

If you're having this conversation internally, the right first step is a codebase assessment. It takes a matter of days, produces a concrete report, and gives you the data you need to make the headcount decision correctly.

Get in touch to discuss where your codebase stands.