AI & Machine Learning

PHP and AI in 2027: the models already write your code, you prove it works

Where do AI models stand in October 2026, and what does 2027 bring for PHP developers? On PHP2Shell, the flaw AI found after twelve years, prices and benchmarks, PHP 8.6, versions running out, the Cyber Resilience Act and a working day in 2027.

Erik van de Blaak
Erik van de Blaak
16 min read • 16 views
PHP and AI in 2027: the models already write your code, you prove it works

On 21 October 2026 PHP shipped an emergency update for two flaws that let an attacker run code on your server without logging in. The bug had been there since PHP 5.4, from 2012. For twelve years nobody saw it. Researchers at Wiz found it this summer, using Gemini 4 Argon and GPT-5.6 Sol as their tools. According to Wiz, one researcher did in a week what used to take a team of specialists months.

Four days before that update, on 17 October, Amazon recorded the first attack attempt.

That is the world you enter 2027 in as a PHP developer. The same kind of AI models that comb through PHP's C code now write a large share of the PHP code that goes to production. This article sets out where those models stand, what is already fixed for PHP in 2027, and why your work is shifting from writing code to showing that code is right. At the end you will find what a working day could look like next year, and what you can set up for it today.

Facts checked on 23 October 2026. Prices and benchmark scores come from the makers themselves; there were no independent measurements yet for the newest models. Expectations and opinions are marked as such.

Where do AI models stand in October 2026?

Short answer: the top models work on a codebase on their own for hours, the price of that has dropped by almost three quarters in sixteen months, and the well-known benchmarks tell you less and less about what a model will do in your PHP project. Anthropic, for example, had Opus 5.5 rewrite the HAProxy load balancer from C to Rust; that took 9.5 hours.

ModelMakerSinceWhat you should know
Claude Opus 5.5Anthropic22 September 2026$4 in, $20 out per million tokens; according to Anthropic 40% cheaper to run than Opus 5
Claude Sonnet 5.5Anthropic28 September 2026$2 in, $10 out; the middle tier most coding tools run on
Claude Haiku 5.5Anthropic7 October 2026$0.10 in, $0.50 out (up to 100,000 tokens per request); for many small tasks
GPT-6 Sol and LunaOpenAI7 October 2026replace GPT-5.6 in ChatGPT; Codex still runs the September versions
Gemini 3.8 FlashGoogleSeptember 2026according to Google its best reasoning and coding performance yet, at the price of 3.7 Flash
Gemini 4 ArgonGoogleSeptember 2026only for selected security teams; the model behind part of the PHP2Shell research

If you would rather not send code to a server, there are models with open weights that you run yourself. On an ordinary 16 GB laptop Qwen3.5 already works reasonably well; I measured that earlier. For Mistral Large 4, the largest European model, open weights have been announced but not yet released.

The price fell faster than most people keep track of

In May 2025 Claude Opus 4 cost $75 per million tokens the model writes. Opus 5.5 costs $20. That is 73% less in sixteen months, for a model that scores far higher on Anthropic's own tests.

Step chart of the Claude Opus output price per million tokens: 75 dollars for Opus 4 (May 2025) and Opus 4.1 (August 2025), 25 dollars for Opus 4.5 through Opus 5 (November 2025 to July 2026), 20 dollars for Opus 5.5 (September 2026).
Output price of the largest Claude model, according to Anthropic's pricing page.

A worked example makes it concrete. Have a model review a pull request, send it 50,000 tokens of code and context, and let it write 5,000 tokens of comments: with Opus 5.5 that costs $0.30. With Opus 4 it was $1.13. With Sonnet 5.5 it is $0.15. At that price the question is no longer whether you have a model check every change, but why you are not doing it yet.

Why the well-known benchmarks tell you little

SWE-bench Verified, the test in which models fix real bugs from open-source projects, is all but full: leaderboard sites report scores around 95% for the top models. That test also consists entirely of Python projects. The makers have therefore moved to harder tests. On Terminal-Bench 4.0, with tasks in a real terminal, Anthropic reports 66.4% for Opus 5.5 and 57.9% for GPT-6 Astra. Read the other way round: the best model of the moment still fails a third of those tasks.

For you this means that no public score tells you how a model copes with your Laravel app from 2019, your own base classes and that one service that does everything through a static helper. You have to measure that yourself, and that is what the rest of this article is about.

How much PHP code do developers still write themselves?

Less than half, if you believe the developers. Between May and July 2026 JetBrains asked professional developers worldwide about their work. 90% use an AI coding agent at least weekly, 68% daily. On average they estimate that 47% of last month's code was written entirely by an agent and 27% without any AI. 39% use Claude Code at work, up from 18% in January. Figures specific to PHP are not out yet; the State of PHP report for 2026 has still to appear.

Those are estimates, and there is a catch. In 2025 the research group METR had sixteen experienced open-source developers do 246 tasks in their own projects, half with AI and half without. With AI they were 19% slower. Afterwards they believed they had been 20% faster. METR now calls that result historical, because the tools have improved a lot. A new measurement did not work well: many developers no longer wanted to do tasks without AI.

So hardly anyone knows exactly how fast they really are. What is certain: the amount of code an agent writes says nothing about how much of it is right. If you no longer understand that code, you build up cognitive debt.

The proof is in your pipeline, not in the model

Today Lethwei: Blood & Honor went live on this site, a fighting game built largely by an AI agent. All 53 unit tests and all 19 browser tests in Chromium, Firefox, WebKit and on a phone were green. On the live site the fighters did not appear.

The cause was not in the code. This site's .htaccess refuses every .json file, a good rule that keeps configuration files out of reach. The fighters are loaded from four .json files. The agent's test server had no Apache and so did not know that rule. The fix was a five-line .htaccess in one folder. The model had done its work correctly, in a world that was not the production server.

That kind of failure is typical of what will happen more in 2027: code that is right in the environment it was tested in. A model can write every line of PHP well and still not know that your server has open_basedir on, that the cron runs as a different user, or that the host has disabled exec(). You know that. Or your pipeline does, if you write it down there.

Let the machine decide, not the chat

PHP has better tools for this than its image suggests. With declare(strict_types=1), PHPStan at its highest level, a test suite and composer audit you can catch much of what a model gets wrong before a person looks at it. Put it in one command in your composer.json:

"scripts": {
    "check": [
        "phpstan analyse --level=max",
        "phpunit",
        "@composer audit"
    ]
}

Run composer check in your CI before every merge, also when an agent made the change. The deal with the model is then simple: it may propose anything, but the work is only done when this command is green. Agents can run the command themselves and fix their mistakes before you see anything. That saves you more review time than any better model.

The package that does not exist

One risk is specific to anyone using a package manager. Researchers had sixteen code models write 576,000 pieces of code and checked the packages used in them. With commercial models an average of 5.2% of those packages did not exist; with open models it was 21.7%. In total the models invented 205,474 different package names. Attackers register such names and fill them with malware; this is called slopsquatting.

That research covered Python and JavaScript, but Composer works the same way: composer require vendor/name installs whatever is on Packagist under that name. If a model suggests a package you do not know, open its Packagist page first. You do not install a three-week-old package with two hundred downloads and no linked repository because a chatbot mentioned it.

PHP2Shell: why your update speed counts in days in 2027

Back to the flaws from the opening, CVE-2026-109618 and CVE-2026-109619, together called PHP2Shell. The timeline shows what AI does on both the defending and the attacking side. Wiz found the first bug on 19 August and reported it on 24 August. On 17 October Amazon saw the first attack; on 21 October the updates arrived: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

For PHP 8.1 and older there is no official update, only a minimal fix in the source code. According to W3Techs 69.3% of websites whose server language is known run PHP, and of those PHP sites 26.9% still run PHP 7 and 7.7% PHP 5. More than a third of the PHP web therefore runs a version for which this update does not exist as a regular release.

My expectation for 2027: this becomes normal. Models that find vulnerabilities are getting cheaper and more widely available, and what a defender finds in a week, an attacker finds too. OpenAI now publishes how well its models turn known flaws into working attacks: GPT-6 Sol scores 82.6% on that. An update policy of "at the next maintenance round" is too slow then. Anyone who cannot update their hosting, Docker images and PHP version within a few days has a bigger problem in 2027 than which AI model they use.

What is already fixed for PHP in 2027

Part of next year is already in the calendar.

Timeline from September 2026 to December 2027: 11 September 2026 Cyber Resilience Act reporting duty, 17 October first PHP2Shell attack, 21 October PHP updates, 19 November PHP 8.6, 31 December 2026 end of security updates for PHP 8.2, 11 December 2027 Cyber Resilience Act fully applies, 31 December 2027 end of security updates for PHP 8.3.
Dates according to php.net and the European Commission. PHP 8.6 may still move.

PHP 8.6 arrives on 19 November 2026

Release candidate 4 came out on 21 October. The most striking new feature is partial function application: you fill in some of the arguments and get a new function back. The proposal passed 33 votes to 0. PHP also gets clamp(), default values for readonly properties, a Duration class, a new Polling API, #[\Override] for class constants and safer default settings for sessions.

// PHP 8.6: partial function application
$numbersOnly = array_filter(?, is_numeric(...));
$numbersOnly(['12', 'abc', '7.5']); // [0 => '12', 2 => '7.5']

// PHP 8.6: clamp()
$discount = clamp($input, min: 0, max: 50);

Mind this if you work with an AI model: a model only knows PHP 8.6 if it was trained after the release or is given the documentation. Without that context it writes the 8.5 solution. That still works, but you are permanently a version behind. Laravel puts it sharply itself: language models are surprisingly good at PHP because there is so much PHP training data, but without context they invent APIs. Laravel Boost, Laravel's MCP server, therefore gives agents guidelines and documentation that match the versions in your project. For other PHP work you have to provide that context yourself, for example in a CLAUDE.md or AGENTS.md in your project.

Versions that run out

On 31 December 2026 PHP 8.2 stops getting security updates and active support for 8.4 ends. A year later, on 31 December 2027, PHP 8.3 drops off and active support for 8.5 ends. If you still run 8.2 in 2027, the PHP2Shell update may have been the last big one you got.

An upgrade from 8.2 to 8.5 is exactly the kind of work agents are good at: many small, dull changes you can check with tests and PHPStan. It is a good first job to test your pipeline on.

PHP 9 has proposals, no date

There are accepted proposals meant for PHP 9.0: an undefined variable becomes an error instead of a warning, ${} in strings disappears, and functions with several signatures are split up. There is no release date, and it has not been decided whether the version after 8.6 will be 8.7 or 9.0. If you clear your deprecation notices now, you have nothing to worry about.

The Cyber Resilience Act applies in full

Since 11 September 2026, manufacturers under the European Cyber Resilience Act must send an early warning about actively exploited vulnerabilities in their products to ENISA's reporting platform within 24 hours, with a full notification within 72 hours. On 11 December 2027 the remaining obligations apply, including the lighter rules for organisations that support open-source projects for commercial use.

If you build a website for a client, little changes. If you sell PHP software as a product in the EU, such as an installable module or a device with an admin screen in PHP, it does. An actively exploited flaw like PHP2Shell in a product you supply is exactly what those 24 hours are for. Find out in 2027 whether your software is covered; the European Commission published guidance for that in July 2026.

PHP becomes a language to build agents with

Until recently PHP was mainly the language an AI model wrote code in. Now there are tools to build the AI side itself in PHP. The official PHP SDK for the Model Context Protocol, made by the PHP Foundation, Anthropic's MCP team and Symfony, is at version 0.9.0 from 18 October 2026 and has been installed more than five million times. Its makers call it experimental until version 1.0. On 23 September Laravel released version 1.0 of its AI SDK, with tools that pause until a person approves them and with classification through Jev, a model that chooses instead of writes.

That changes what a PHP developer can deliver in 2027. You build not only the web app, but also the connection through which an agent can work safely inside that app: which data it may read, which actions it may propose and which a person has to approve. What MCP is and how to set it up safely is something I wrote about earlier. How to build such an agent in plain PHP, with Composer and the official SDKs, I show step by step in Building an AI agent in PHP.

A working day of a PHP developer in 2027

What follows is a written-out expectation, not a fact. Every part rests on something that already exists; that is noted each time.

9:00. Overnight an agent picked up yesterday's open tickets. Three pull requests are waiting. Two have a green composer check; the agent marked the third as failed itself, with the PHPStan error attached. Exists now: agents that work on tickets in the cloud and run their own tests.

9:30. You read the two green changes. Not line by line, but asking whether this is what the client meant, and whether it fits how production runs. The first one misses an index on a table of twelve million rows. No test sees that; you do. Exists now: the line between what tooling catches and what experience catches.

11:00. A security notice about a widely used Composer package. Your agent already has a branch with the update, the tests are green, and it is live before lunch. Exists now: composer audit, Dependabot and similar tools. What changes in 2027 is that you need this pace.

14:00. You build an MCP connection for customer service. The client's agent may read order data and propose a refund; carrying it out takes an employee's approval. You make that design, the model writes the code. Exists now: the MCP SDK for PHP and approvable tools in the Laravel AI SDK.

16:00. You let a model attack your own login flow before someone else does. Exists now: see PHP2Shell.

What stands out in this picture: you type less PHP, but you need more knowledge of PHP. To spot a missing index that no test catches, to give an agent safe limits, and to trace a production failure back to a line in php.ini.

What to sort out this year

  • Check your PHP version. On 8.2 to 8.5, make sure you have the 21 October update. On 8.1 or older: plan the upgrade now.
  • Make one command that decides. Strict types, PHPStan, tests and composer audit in composer check, mandatory in CI, also for agents.
  • Write down how production runs. PHP version, extensions, php.ini deviations, web server rules. In a file your agent reads, and preferably in a test environment that resembles it.
  • Check every new package. Age, downloads and repository on Packagist, before composer require runs.
  • Build one small MCP server. A few tools for your own application, with the official SDK or Laravel. You will learn more about 2027 from it than from ten articles.

What 2027 brings for PHP developers

The models get cheaper and better; that happened every quarter over the past year and there is no reason to assume it stops. Writing PHP becomes cheaper still. What does not get cheaper: knowing what your production looks like, deciding what the right solution is, and updating within days when something goes wrong. That is where a PHP developer's work lies in 2027, and frankly the more interesting part of it.

The bug in PHP went unnoticed for twelve years. With AI as a tool, one researcher needed a week for it. Your code will be read that thoroughly in 2027 too. The only question is by whom first.

Sources

Share this article

Erik van de Blaak

Written by

Erik van de Blaak

AI Solutions Engineer & Full-Stack Developer

Erik van de Blaak is an AI Solutions Engineer and full-stack developer at CareerValue BV. Here he writes about AI coding tools and agents, such as Claude Code.

Comments (0)

Comment on this article

Never published

I read every comment before it goes online.

No comments on this article yet.