Will AI Replace Programmers? What PHPVerse 2026 says PHP Developers Should Do Next

This is the second part of a roundup of PHPVerse 2026; you can find the first four talks and their takeaways on our blog here. The final four talks from PHPVerse, the all-round virtual conference organised by JetBrains, rotated around AI’s impact on PHP as the subject matter. In this article, we’re going to finish covering key topics that reflect the state of PHP in 2026.

PHPVerse

Something that I previously didn’t cover was the actual impact of PHPVerse itself. It’s worth noting that this event, which contained speakers from across the board of PHP (itself a very broad community across tooling and frameworks) has seen about 15,000 livestream views. Further to this, over 10,000 chat comments came in during the broadcast, and at its peak of being broadcast live, 2600 were tuning in.

Those figures are certainly not to be sniffed at: if anything, it would appear to me that the PHP Community is growing stronger than ever. So, let’s dive into the talks.

Ashley Hindle: My AI Writes Perfect* PHP

Straight off the bat, you’ve got to love the inclusion of the asterisk indicating the disclaimer. I recently ran an experiment which I wrote up in our blog, where I used Cursor to create a Laravel app that would send RCS Messages. Without any MCP servers, the result was… er, miserable.

Thankfully, it doesn’t have to be this way (and it’s not, given how widespread it is being used), as Ashley Hindle dives into it. After all, why not? Why not a ChatGPT slop image?Ashley identified 2025 as the year that AI development went from “impressive, but needy” to “actually useful”. November saw the releases of Claude Opus 4.5 and GPT 5.1, so with the addition of AI-first IDEs like Cursor, the adoption across the industry meant that it was time for us, and your company, to be agent-ready.

What does it mean to be agent-ready? Ashely identified four pillars of readiness as a foundation to build on.

• Reproduceable Dev Environments. Your agents need isolated, identical environments that the agents can spin up at will, without interference.

Reproduceable Dev Environments. Your agents need isolated, identical environments that the agents can spin up at will, without interference.

• Automated feedback loops. You’re aiming at automation to reduce the amount of human input. In the PHP world, we have many tools at your disposal, so get your Git hooks to run them. RectorPHP, PHPStan, Pest, PHPUnit etc. should be firing every time so that agents can get immediate feedback from your tooling.

Automated feedback loops. You’re aiming at automation to reduce the amount of human input. In the PHP world, we have many tools at your disposal, so get your Git hooks to run them. RectorPHP, PHPStan, Pest, PHPUnit etc. should be firing every time so that agents can get immediate feedback from your tooling.

• Guidance and Documentation. Code snippets, examples, explanations for skill learning are essential. Keep an agents.md file clean and concise. In Vonage’s case, for example, you can use the Vonage MCP Server on top of whatever agent skills you have internally which gives instructions to agents.

Guidance and Documentation. Code snippets, examples, explanations for skill learning are essential. Keep an agents.md file clean and concise. In Vonage’s case, for example, you can use the Vonage MCP Server on top of whatever agent skills you have internally which gives instructions to agents.

• Agent access to extra tooling. Beyond the scope of code-quality tools: giving your agents the ability to spin up headless browsers, a permissions-restricted GitHub CLI, and local review tools such as CodeRabbit.

Agent access to extra tooling. Beyond the scope of code-quality tools: giving your agents the ability to spin up headless browsers, a permissions-restricted GitHub CLI, and local review tools such as CodeRabbit.

Ashley’s biggest “if you take one thing away from this talk” is, not surprisingly, the most interesting aspect of all of this. It involves a change in mindset, and I will openly admit I am very much sharing this mindset right now: if your automated code looks bad, it is the agent doing something wrong.

That is what needs to change. Instead of thinking like this, Ashley asks us to consider: if your code is bad, what in your environment the agent is running in – the docs, the tooling, etc. could have caused this to happen? It’s your fault that the agent cannot output. He aptly names this way of thinking “closing the gap”.

Jeffrey Way: How AI Is Changing the Programmer World

We’re sticking to AI, and next up, you’d have to have been living in under a rock as a Laravel developer if you’ve not come across Laracasts at some point in your career. Given that he’s been at the helm of Laravel teaching since 2013, I would say that if anyone is poised to notice changing working patterns among us developers, it’s him.

So, Jeffrey kicks off with our first observation, which is answering the question, “where exactly are we with AI right now as a helping tool?”. His answer is “junior developer at your side”, and I think my personal experience certainly corroborates this view. I am also aware of his next point, which is that despite being a fairly experienced (and therefore very cynical) developer, I need to make sure I don’t fall into the trap of thinking this is a passing phase. I think by now we all can see AI is not going away; using pair agents daily is the reality of developing software in 2026.

What Does This Junior Developer Do?

It becomes easier to work out how to use your agents if you frame it with context in the real world. Once established that it’s effectively a junior-level developer at your side, it’s easier to accept that agents come with all of the same working patterns, mistakes and baggage as a junior developer.

We’ll call this junior developer Charlie. Get Charlie to do fast, iterative, boring tasks to save you time. But also: don’t leave Charlie unsupervised. Charlie can sort out your migrations quickly throws out useful boilerplate code, but letting them run riot unsupervised in a production environment will result in tears. What’s with all the dollar signs?

Why Is Charlie a Junior, Not A Senior?

Boring, repetitive tasks are suited to the learning level required to do them. Other things that sometimes I feel humans have designed as a way to troll ourselves: DNS configuration, mismatched production environments not reflecting UAT or Dev, silent API failings or uncaught exceptions are things Charlie will struggle to fix.

How Can I Use Them Like a Senior?

Jeffrey states that it all comes down to judgment. You can start off with the small, mundane tasks, but it is possible to get them working on more complex ideas. This all boils down to your decisions on how to break up larger problems into smaller ones, and when to accept what the agent produces and when to reject the output. “Semicolons were never the point”.

Where to Start

An important aspect to address, because it’s never going to be a great idea to throw a swarm of agents into a production environment immediately. The agents have to learn, but you, as a PHP Developer, need to learn as well. Pick an unfinished side project, with the aim of getting it “finished” and into production. The idea isn’t about trying to get your unfinished graveyards of never-ending projects into a startup; it’s an exercise in “completing” the run with agents.

Conclusion: Will AI Replace Programmers?

No, but that frames the debate as too simplistic. Judgment is the one thing that AI cannot do well – for now. In the same way that throwing a ton of AI text out into the social media sphere can be instantly detected by humans and discarded, the same can be said of what makes it problematic. AI cannot fully understand humans, and software is designed and used by humans. You reckon Claude would know what’s going on if it sees a T_PAAMAYIM_NEKUDOTAYIM error? The background and existence of that very error itself wouldn’t make sense to AI, or why it is still in the source code.

I’d argue that the ability to understand programming patterns and how to approach problems is still as vital as ever, and even the pace of AI development won’t catch absolutely everything. Just unload the boring parts to our junior underlings. Of course, once everything becomes Skynet then it won’t matter.

Larry Garfield: PHP RFCs

The speed of development within core PHP has noticeably accelerated since the Foundation took on a development team. As a result, I’ve certainly noticed a large upturn in interest around RFCs. This has certainly caused some interesting community scenarios, at a time when all my previous PHP days have been covered by the mantra of “don’t go near internals”. It seems like a crazy world of yesteryear, but Larry is here to untangle the misunderstandings. Given his experience within Drupal, Symfony, Typo3 and 27 years of PHP development, you’re in good hands.

PHP Is the Last Open-Source Language

You read that correctly. Larry didn’t include this in his talk, but it’s true. You can see why in Chris Tankersley’s talk on this at PHPUK in 2020. Essentially: there is a voting system; anyone can submit a change, and no other traditional model like this is in place. The benevolent dictator model is the most common, followed by corporate-backed ones.

The term RFC is an acronym for “Request for Comments” and is prevalent across the tech industry. An RFC is a proposal to change the source code of the language, so: new features, new functions, different runtime behaviour, etc. Each change is proposed, debated, and voted on. There is no benevolent dictator; there is no company at the helm: PHP is a direct democracy. I will, however, not delve into what you could consider the more problematic aspect of this all, which is who gets to vote, but that is something The PHP Foundation is building clearer messaging on. There are three distinctive stages in the lifecycle for this process:

The Proposal Stage

Don’t start writing your changes yet; first, a proposal needs to be sent. This goes to internals@list.php.net, where you describe your idea. It doesn’t matter how long the proposal is or how it’s laid out;: bear in mind when writing it that you are sending the message, “Does anyone care about this idea?”. If you get a negative response (and Larry does give us the truth, which is: you might) then it’s best to move on. However, if you get some interest, you can then write the code and issue a pull request against php-src in GitHub, followed by adding the RFC to wiki.php.net. It’s worth noting that, should it pass, most of the text in the wiki is used verbatim as documentation of the feature or change.

The Discussion Stage

Once you have created you RFC, you open a thread on the PHP mailing list. Yes, audible gasps may be heard, but sometimes navigating change on a project that has been in some form of development in 1995 with no single ownership will create these scenarios.

Feedback is given at this point, which in most cases is driven to improve the RFC (to quote a figure, Larry picks 95%). It’s also the most likely part of the process that will sink the RFC early, which is mostly either caused by critical design flaws (see the never-ending debate on generics for this) or that the feature cannot actually be implemented in userland.

The Vote

After two weeks of no changes, you give a 48-hour notice and open up the voting widget for the RFC. The closing date should be marked as two weeks after the opening. Around 100 active members vote per year, and most RFCs have around 25 votes on them. Voting access is granted in total to 1500 people, but you will never see a turnout of that size. Take, for instance, the aforementioned generics RFC: 36 votes in total, and that’s for a rare, high interest RFC.

To pass, the RFC needs a Two-Thirds majority of ‘yes’ . It’s a high threshold, but this is by design: PHP runs on millions of production machines worldwide, and powers vastly different frameworks addressing different problems in software. You cannot pass an RFC with this impact based on vibes: there must be a general consensus.

The Case Study: The Pipe Operator

Some of this might sound intimidating, but RFCs do pass. A good recent example of this is the pipe operator, which came out in PHP8.5.

There isn’t anything conceptually new about the pipe operator (you’ve always been able to chain function calls in PHP), but it makes more complex, long-chained calls vastly easier to read and reason with.

The RFC followed the exact process as required: proposed, multiple rounds of feedback and discussions, subsequent improvements, passed with a majority, and, as a result, a new feature for PHP that improves the code for developers.

The Necessary Evil: Tackling Vendors

I’ve alluded to this earlier, but perhaps the most debated subject around RFCs tends to be centred around who has voting rights and why. What certainly can be concluded is that this is still a democracy: yes, it might be difficult to get a vote through, and yes, a mailing list might look a little old-fashioned, but these things are by design. Everything is public-facing, in the spirit of true open-source software. These guardrails stop vendors from being able to push through a change that only benefits them, possibly at the expense of the rest of the community.

Conclusion

You don’t need to be in the PHP Foundation to contribute; you don’t need to be one of the voting members on RFCs. PHP is kept alive by its ecosystem: you don’t need to be fluent in C or to even have touched the core. During the discussion phase, anyone can show up and say “I would use this feature”, or “this feature will impact X project”. Or, send improvement ideas to open an RFC if you have one.

Mike Herchel: This Isn’t the Drupal You Remember

I’ll let you all in on a little secret: one of my first ever speaking engagements for Vonage once I’d started here (as I write this, approaching five years ago) was at DrupalCon in Portland in 2021. I was excited: at this point I’d discovered that Drupal was in the process of ripping out its old CMS infrastructure (which the bit I remember from probably back in 2006) in favour of Symfony components. Sadly though, this visit never came to pass: I got COVID 24 hours before flying.

Which leaves me still with the mystery of Drupal: what does it look like now? Mike was here with the answers, which is fitting given that he’s the primary developer of Drupal’s core theme, as well as doing Government work at ECS Federal.

The Old: Procedural Hooks

Ah, yes. This is what I remember: the same complaint that I always had when trying to wrestle with WordPress. No inversion of control, no kernel. A flat, hook system: Mike concurs that Drupal was this model before 2015. Writing extensions and modules required using hook_node_save() or hook_form_alter() and praying to the Drupal gods that runtime just sort of happened in the right order. There was no clear entry point, no obvious place to put shared logic.

erhaps casting a net would be better to catch your runtime methodThis caused the “death cliff”, which comprised a heavy learning curve that would take years to plateau with acquired experience. Drupal events would create an in-joke: “Drupal makes hard things easy, but easy things hard”. The thing is, as with a lot of tongue-in-cheek humour, it concludes: people weren’t wrong.

2015: The Year of Reckoning

This was the year that marked the big architectural overhaul. The decision was made: Drupal would move to fully object-oriented PHP (finding out it wasn’t blew my mind), Symfony components would be refactored in, Composer would be the dependency manager, and dependency injection would in introduced (another complaint often levelled at Drupal, that it was hard to test effectively). The hook system didn’t get replaced overnight (try doing that on X years of tech debt on a project), but the intention and plan were there to replace it.

Something Mike includes that very much did surprise me is that the rendering system uses PHP Fibers. For those not aware, Fibers were introduced as PHP’s concurrency implementation at the core level, i.e., async. The cache system was also rewritten, including internal reverse proxy caching. The most recent release of Drupal has seen a 33% reduction of database queries, something not to be sniffed at.

The Result: Modern Tooling

It sounds like such a simple statement to say this now means “Drupal has the usual PHP tooling available to it as the majority of other projects”, but that would be doing a disservice to the amount of work to get to this point. The result of this work is, I guess, you could now call it “standard”. Drupal has a test suite, Composer dependency management, the ability to easily pull static analysers like PHPStan into the mix, auto linters and anything else you fancy. If you’re used to working with projects like Laravel and Symfony, everything is there to be recognised: service containers, typed interfaces, dependency injection and the like.

There is an alternative benefit in the “now”, which is that the architecture is perfectly suited to AI agentic development and assistance.

Evolution: Drupal CMS

Mike’s demonstration of the new face and reality of Drupal development came in the form of the Drupal CMS, which sits on top of core. Building a landing page in minutes – a finished page, previewing at different resolutions is, something, he admits, that was simply not possible five years ago (especially if we factored in deployment and its tooling). You can now drag stuff around its canvas at-will, there’s JSX React components, you name it.

Conclusion: The New World

We should, as PHP developers, be well aware of other developers’ outdated image of the language itself. As a result, I think Mike’s talk is the booster we need to give an understanding nod that the Drupal of 2010 is not the Drupal of now. It might have taken a big effort to pull off, but the important thing is they did it.

The Whole Conclusion: Moving Forward

Another year, another successful event. As expected, there was plenty of AI talks as the burning subject matter. What matters to me is the coverage that JetBrains give when choosing speakers: we are a vast ecosystem of large-scale projects. Sure, that means many of these projects have their own communities due to their size, but we’re also better together when faced with the new reality of AI software development.

The world will have entirely changed again in 2027, so who knows what to expect next year. With NativePHP and FrankenPHP ramping up capabilities (we even saw a new GTK3 implementation!) and history repeating with the launch of another language and runtime. If there’s one thing you can take away as a whole, it’s that PHP is still alive and not going anywhere, anytime soon.

Frequently Asked Questions

Q1: Will AI replace PHP programmers?

Not based on what PHPVerse 2026 actually showed. AI already writes a meaningful share of routine PHP (CRUD endpoints, boilerplate tests, migrations), but every speaker who addressed the question directly, including Jeffrey Way, argued the job shifts toward review, system design, and judgment rather than disappearing. The honest answer is that AI replaces certain tasks inside the job faster than it replaces the job itself.

Q2: What was PHPVerse 2026 and who spoke at it?

PHPVerse 2026 was a JetBrains-hosted, five-hour livestream event held June 9, 2026, bringing together influential people across the PHP ecosystem. It drew roughly 15,000 total views and 10,206 live chat comments. Speakers included Jeffrey Way, Larry Garfield, Mike Herchel, and several others covering topics from AI assisted coding to PHP governance to Drupal's evolution.

Q3: How does a PHP RFC actually get approved?

A PHP RFC starts as a written proposal discussed openly on the PHP internals mailing list, then moves to a formal vote once discussion settles. Most language change RFCs need a two thirds supermajority to pass, a deliberately high bar meant to protect a language millions of production sites depend on from any single contributor's preference winning by a slim margin.

Q4: Is Drupal still worth learning in 2026?

For the right use case, yes. PHPVerse 2026 speaker Mike Herchel argued that Drupal has moved toward modern, testable, object oriented PHP architecture that addresses the old procedural hooks complaint directly. It is still the wrong choice for a small marketing site, but for large, structured content operations it deserves a second look if your last opinion of it is several years old.

Q5: What is the PHP Foundation's Model Context Protocol SDK?

It is an official PHP SDK for Anthropic's Model Context Protocol, built by the PHP Foundation in collaboration with Anthropic's own MCP team and Symfony. It gives PHP developers a first party, maintained way to connect PHP applications to AI coding agents and tools, rather than relying on unofficial community packages.

Q6: Does Vonage still support PHP?

Yes. The Vonage PHP SDK has crossed 6.5 million Composer installs and released a major version 4.3.0 release in January 2026. Vonage continues to publish PHP specific developer content and attend PHP community events such as PHPday Verona, alongside its Node, Python, and Java SDKs.

Q7: Where can I watch the PHPVerse 2026 talks?

JetBrains published the full PHPVerse 2026 livestream recording, and individual talk segments are timestamped for anyone who wants to jump straight to a specific speaker rather than watching all five hours. Check the JetBrains PhpStorm blog for the direct recap and links.