Заменят ли ИИ программистов? Что, по мнению PHPVerse 2026, PHP-разработчикам делать дальше

Это вторая часть обзора PHPVerse 2026; первые четыре доклада и их основные выводы вы можете найти в нашем блоге здесь. Последние четыре доклада на PHPVerse, универсальной виртуальной конференции, организованной JetBrains, были посвящены влиянию ИИ на PHP. В этой статье мы завершаем рассмотрение ключевых тем, отражающих состояние PHP в 2026 году.

PHPVerse

То, о чем я ранее не упоминал — это реальное влияние самого PHPVerse. Стоит отметить, что это мероприятие, собравшее спикеров со всего мира PHP (который сам по себе является очень широким сообществом, охватывающим инструменты и фреймворки), собрало около 15 000 просмотров трансляции. Кроме того, во время эфира поступило более 10 000 комментариев в чате, а в пиковый момент трансляции ее смотрели 2600 человек.

Эти цифры определенно заслуживают внимания: во всяком случае, мне кажется, что PHP-сообщество становится сильнее, чем когда-либо. Итак, давайте погрузимся в доклады.

Эшли Хиндл (Ashley Hindle): Мой ИИ пишет идеальный* PHP

С самого начала нельзя не оценить наличие звездочки, указывающей на дисклеймер. Недавно я провел эксперимент, о котором написал в нашем блоге, где использовал Cursor для создания приложения Laravel, отправляющего RCS-сообщения. Без каких-либо MCP-серверов результат оказался… ну, плачевным.

К счастью, так быть не должно (и это не так, учитывая широту его использования), о чем и рассказывает Эшли Хиндл. В конце концов, почему бы и нет? Почему бы не картинка в стиле ChatGPT slop? Эшли назвал 2025 год годом, когда разработка с использованием ИИ перешла из стадии «впечатляет, но требует много внимания» в стадию «действительно полезно». В ноябре состоялся релиз Claude Opus 4.5 и GPT 5.1, поэтому с появлением ИИ-ориентированных IDE, таких как Cursor, распространение этой технологии по всей индустрии означало, что пришло время для нас и вашей компании быть готовыми к работе с агентами.

Что значит быть готовыми к работе с агентами? Эшли выделил четыре столпа готовности в качестве фундамента для построения.

• Воспроизводимые среды разработки. Вашим агентам требуются изолированные, идентичные среды, которые агенты могут разворачивать по своему усмотрению без каких-либо помех.

Воспроизводимые среды разработки. Вашим агентам требуются изолированные, идентичные среды, которые агенты могут разворачивать по своему усмотрению без каких-либо помех.

• Автоматизированные петли обратной связи. Ваша цель — автоматизация для уменьшения объема человеческого участия. В мире PHP у нас есть множество инструментов в вашем распоряжении, поэтому настройте Git-хуки на их запуск. RectorPHP, PHPStan, Pest, PHPUnit и т. д. должны срабатывать каждый раз, чтобы агенты могли получать мгновенную обратную связь от ваших инструментов.

Автоматизированные петли обратной связи. Ваша цель — автоматизация для уменьшения объема человеческого участия. В мире PHP у нас есть множество инструментов в вашем распоряжении, поэтому настройте Git-хуки на их запуск. RectorPHP, PHPStan, Pest, PHPUnit и т. д. должны срабатывать каждый раз, чтобы агенты могли получать мгновенную обратную связь от ваших инструментов.

• Руководства и документация. Фрагменты кода, примеры и объяснения для обучения навыкам имеют решающее значение. Поддерживайте файл agents.md чистым и лаконичным. В случае Vonage, например, вы можете использовать MCP-сервер Vonage поверх любых навыков агента, которые есть у вас внутри компании, что дает инструкции агентам.

Руководства и документация. Фрагменты кода, примеры и объяснения для обучения навыкам имеют решающее значение. Поддерживайте файл agents.md чистым и лаконичным. В случае Vonage, например, вы можете использовать MCP-сервер Vonage поверх любых навыков агента, которые есть у вас внутри компании, что дает инструкции агентам.

• Доступ агентов к дополнительным инструментам. За пределами инструментов контроля качества кода: предоставление вашим агентам возможности запускатьheadless-браузеры, ограниченный в правах GitHub CLI и локальные инструменты проверки, такие как CodeRabbit.

Доступ агентов к дополнительным инструментам. За пределами инструментов контроля качества кода: предоставление вашим агентам возможности запускатьheadless-браузеры, ограниченный в правах GitHub CLI и локальные инструменты проверки, такие как CodeRabbit.

Самый главный вывод Эшли «если вы вынесете из этого доклада только одно», как и следовало ожидать, является самым интересным аспектом всего этого. Он предполагает изменение мышления, и я открыто признаю, что разделяю это мышление прямо сейчас: если ваш автоматически сгенерированный код выглядит плохо, значит, агент делает что-то не так.

Именно это должно измениться. Вместо того чтобы мыслить так, Эшли просит нас задуматься: если ваш код плох, что именно в среде, в которой работает агент — документация, инструменты и т. д., — могло привести к этому? Это ваша вина, что агент не может выдать результат. Он метко называет такой способ мышления «ликвидацией разрыва» (closing the gap).

Джеффри Уэй (Jeffrey Way): Как ИИ меняет мир программистов

Мы продолжаем тему ИИ, и следующий спикер... нужно было жить под камнем будучи Laravel-разработчиком, чтобы за свою карьеру хоть раз не столкнуться с Laracasts. Учитывая, что он возглавляет обучение Laravel с 2013 года, я бы сказал, что если кто-то и способен заметить изменения в рабочих паттернах среди нас, разработчиков, так это он.

Итак, Джеффри начинает с нашего первого наблюдения, отвечая на вопрос: «где именно мы сейчас находимся с ИИ как с инструментом помощи?». Его ответ — «младший разработчик рядом с вами», и я думаю, что мой личный опыт определенно подтверждает это мнение. Я также осознаю его следующий момент: несмотря на то, что я являюсь довольно опытным (и потому очень циничным) разработчиком, мне нужно следить за тем, чтобы не попасть в ловушку и не подумать, что это временное явление. Я думаю, что теперь мы все видим: ИИ никуда не денется; использование парных агентов ежедневно — это реальность разработки программного обеспечения в 2026 году.

Что делает этот младший разработчик?

Гораздо проще разобраться, как использовать своих агентов, если поместить это в контекст реального мира. Как только установлено, что это фактически младший разработчик рядом с вами, становится проще принять, что у агентов есть все те же рабочие паттерны, ошибки и багаж, что и у джуниор-разработчика.

Назовем этого младшего разработчика Чарли. Поручайте Чарли выполнение быстрых, итеративных, скучных задач, чтобы сэкономить свое время. Но также: не оставляйте Чарли без присмотра. Чарли может быстро разобраться с вашими миграциями, выдает полезный шаблонный код (boilerplate), но если дать им буйствовать без присмотра в производственной среде, это приведет к слезам. К чему все эти знаки доллара?

Почему Чарли — джуниор, а не синьор?

Скучные, повторяющиеся задачи соответствуют уровню обучения, необходимому для их выполнения. Другие вещи, которые, как мне иногда кажется, люди придумали как способ потроллить самих себя: настройка DNS, несовпадающие производственные среды, не отражающие UAT или Dev, тихие сбои API или непойманные исключения — это то, с чем Чарли будет трудно справиться.

Как использовать их как синьора?

Джеффри утверждает, что все сводится к рассудительности. Вы можете начать с небольших, рутинных задач, но вполне возможно заставить их работать над более сложными идеями. Все это сводится к вашим решениям о том, как разбивать более крупные проблемы на более мелкие, и когда принимать то, что производит агент, а когда отклонять результат. «Точки с запятой никогда не были сутью».

С чего начать

Важный аспект, о котором стоит упомянуть, заключается в том, что бросать рой агентов прямо в продакшн-окружение — это почти всегда плохая идея. Агентам нужно учиться, но вам, как PHP-разработчику, тоже нужно учиться. Выберите незавершенный побочный проект с целью «доделать» его и запустить в продакшн. Смысл здесь не в том, чтобы попытаться превратить ваши кладбища бесконечных заброшенных проектов в стартап, а в том, чтобы потренироваться «проходить дистанцию» с помощью агентов.

Заключение: Заменит ли ИИ программистов?

Нет, но такая постановка вопроса слишком упрощает проблему. Рассудительность и принятие решений — это единственное, с чем ИИ пока не справляется хорошо. Точно так же, как тонны текстов, сгенерированных ИИ и выброшенных в социальные сети, мгновенно распознаются людьми и отправляются в мусорную корзину, можно сказать и о том, что делает его проблемным. ИИ не способен полностью понять людей, а программное обеспечение создается и используется людьми. По вашему мнению, Клод понял бы, что происходит, если бы увидел ошибку T_PAAMAYIM_NEKUDOTAYIM? Предыстория и само существование этой конкретной ошибки не будут иметь для ИИ никакого смысла, как и то, почему она до сих пор находится в исходном коде.

Я бы поспорил, что способность понимать шаблоны программирования и подходы к решению проблем по-прежнему важна как никогда, и даже темпы развития ИИ не смогут охватить абсолютно все. Просто сбросьте скучные задачи нашим младшим помощникам. Конечно, как только все превратится в «Скайнет», это уже не будет иметь значения.

Ларри Гарфилд: RFC в PHP

Скорость разработки в ядре PHP заметно возросла с тех пор, как при Фонде появилась команда разработчиков. В результате я определенно заметил большой всплеск интереса к RFC. Это, безусловно, привело к некоторым интересным сценариям в сообществе в то время, когда все мои прошлые дни работы с PHP проходили под девизом «не приближайся к внутренностям». Это кажется безумным миром прошлых лет, но Ларри здесь, чтобы распутать все недоразумения. Учитывая его опыт работы с Drupal, Symfony, Typo3 и 27 лет разработки на PHP, вы в надежных руках.

PHP — последний язык с открытым исходным кодом

Вы прочитали правильно. Ларри не включил это в свой доклад, но это правда. Вы можете понять почему, посмотрев выступление Криса Танкерсли на PHPUK в 2020 году. По сути: существует система голосования; любой может предложить изменение, и никакой другой традиционной модели здесь больше не используется. Модель благожелательного диктатора является наиболее распространенной, за ней следуют модели, поддерживаемые корпорациями.

Термин RFC расшифровывается как «Request for Comments» (запрос комментариев) и широко распространен в технологической индустрии. RFC — это предложение по изменению исходного кода языка: новые возможности, новые функции, иное поведение во время выполнения и т. д. Каждое изменение предлагается, обсуждается и выносится на голосование. Здесь нет благожелательного диктатора; у руля нет никакой компании: PHP — это прямая демократия. Тем не менее, я не буду вдаваться в то, что можно считать более проблемным аспектом всего этого, а именно в то, кто получает право голоса, но это то, над чем PHP Foundation разрабатывает более четкие формулировки. В жизненном цикле этого процесса есть три отчетливых этапа:

Этап предложения

Пока не пишите свои изменения; сначала нужно отправить предложение. Оно отправляется на internals@list.php.net, где вы описываете свою идею. Неважно, насколько длинным будет предложение или как оно оформлено: помните, что, отправляя его, вы задаете вопрос: «Кому-нибудь интересна эта идея?». Если вы получите отрицательный ответ (а Ларри говорит правду: такое может случиться), то лучше двигаться дальше. Однако, если вы проявите некоторый интерес, вы можете написать код и отправить пул-реквест в репозиторий php-src на GitHub, а затем добавить RFC на вики-страницу wiki.php.net. Стоит отметить, что в случае его принятия большая часть текста из вики используется дословно в качестве документации функции или изменения.

Этап обсуждения

Как только вы создали свой RFC, вы открываете ветку в списке рассылки PHP. Да, могут послышаться вздохи, но иногда преодоление изменений в проекте, который находится в той или иной форме разработки с 1995 года и не имеет единого владельца, приводит именно к таким сценариям.

На этом этапе оставляются отзывы, которые в большинстве случаев призваны улучшить RFC (если привести цифру, Ларри называет 95%). Это также наиболее вероятная часть процесса, которая может потопить RFC на ранней стадии, что в основном вызвано либо критическими недостатками проектирования (см. бесконечные споры о дженериках), либо тем, что эту функцию на самом деле нельзя реализовать в пространстве пользователя (userland).

Голосование

После двух недель отсутствия изменений вы даете 48-часовое уведомление и открываете виджет голосования для RFC. Дата закрытия должна быть назначена через две недели после открытия. Около 100 активных участников голосуют ежегодно, и большинство RFC набирают около 25 голосов. Доступ к голосованию предоставлен в общей сложности 1500 людям, но такой явки вы никогда не увидите. Возьмем, к примеру, вышеупомянутый RFC по дженерикам: всего 36 голосов, и это для редкого RFC с высоким уровнем интереса.

Чтобы пройти, RFC должен набрать две трети голосов «за». Это высокий порог, но так задумано изначально: PHP работает на миллионах производственных машин по всему миру и поддерживает самые разные фреймворки, решающие разные задачи в разработке ПО. Вы не можете принять RFC с таким влиянием на основе общего впечатления: должен быть достигнут всеобщий консенсус.

Тематическое исследование: оператор конвейера (Pipe Operator)

Все это может звучать пугающе, но RFC действительно принимаются. Хорошим недавним примером является оператор конвейера, который появился в PHP 8.5.

В самом операторе конвейера нет ничего принципиально нового (в PHP всегда можно было выстраивать цепочки вызовов функций), но он делает более сложные и длинные цепочки вызовов гораздо более читаемыми и понятными.

RFC прошел ровно тот процесс, который требовался: предложение, несколько раундов отзывов и обсуждений, последующие улучшения, принятие большинством и, как следствие, новая функция для PHP, улучшающая код для разработчиков.

Необходимое зло: борьба с вендорами

Я уже упоминал об этом ранее, но, пожалуй, самой обсуждаемой темой вокруг RFC обычно является вопрос о том, кто имеет право голоса и почему. Что точно можно заключить, так это то, что перед нами по-прежнему демократия: да, возможно, добиться принятия голоса непросто, и да, список рассылки может выглядеть немного старомодно, но все это сделано намеренно. Все является общедоступным в духе настоящего программного обеспечения с открытым исходным кодом. Эти защитные механизмы мешают вендорам being able to push through a change that only benefits them, possibly at the expense of the rest of the community.

Заключение

Вам не нужно состоять в PHP Foundation, чтобы делать свой вклад; вам не нужно быть одним из голосующих участников по RFC. PHP поддерживается своим экосистемным сообществом: вам не нужно свободно владеть C или даже прикасаться к ядру. На этапе обсуждения любой может прийти и сказать: «Я бы использовал эту функцию» или «эта функция повлияет на проект X». Или отправьте идеи по улучшению, чтобы открыть RFC, если у вас он есть.

Майк Херчел: Это совсем не тот Drupal, который вы помните

Поделюсь с вами небольшим секретом: одно из моих самых первых выступлений от имени Vonage после того, как я устроился сюда (когда я это пишу, прошло уже почти пять лет), должно было состояться на DrupalCon в Портленде в 2021 году. Я был очень воодушевлен: к тому моменту я узнал, что Drupal находится в процессе избавления от своей старой инфраструктуры CMS (которую я помню, пожалуй, еще с 2006 года) в пользу компонентов Symfony. К сожалению, этой поездке так и не суждено было состояться: за 24 часа до вылета я подхватил COVID.

Из-за чего для меня Drupal остался загадкой: как он выглядит сейчас? Майк пришел с ответами, что вполне закономерно, учитывая, что он является основным разработчиком базовой темы Drupal, а также работает над государственными проектами в ECS Federal.

Прошлое: Процедурные хуки

Ах да. Вот это я как раз помню: та же самая проблема, на которую я всегда жаловался, пытаясь разобраться с WordPress. Никакой инверсии управления, никакого ядра. Плоская система хуков: Майк подтверждает, что до 2015 года Drupal использовал именно эту модель. Написание расширений и модулей требовало применения функций вроде hook_node_save() или hook_form_alter() и молитв богам Drupal в надежде, что во время выполнения все просто сработает в правильном порядке. Не было ни четкой точки входа, ни очевидного места для размещения общей логики.

Возможно, лучше закинуть сеть, чтобы поймать ваш метод выполнения. Это приводило к «скале смерти», которая сопровождалась крутой кривой обучения; чтобы выйти на плато с приобретенным опытом, требовались годы. На мероприятиях Drupal даже родился локальный мем: «Drupal делает сложные вещи простыми, а простые — сложными». Суть в том, что, как и у многих шуток с долей правды, вывод напрашивается сам: люди были не так уж неправы.

2015: Год расплаты

Этот год ознаменовался масштабной архитектурной перестройкой. Было принято решение: Drupal переходит на полностью объектно-ориентированный PHP (узнав об этом, я был потрясен), в него внедряются компоненты Symfony, менеджером зависимостей становится Composer, а также появляется внедрение зависимостей (на что часто жаловались в контексте Drupal, утверждая, что его трудно эффективно тестировать). Система хуков не была заменена за одну ночь (попробуйте проделать такое с годами технического долга в проекте), но были заданы четкие намерения и план по ее замене.

Что меня очень удивило из того, о чем рассказал Майк, так это использование PHP Fibers в системе рендеринга. Для тех, кто не в курсе, Fibers были представлены как реализация многозадачности (асинхронности) на уровне ядра PHP. Система кэширования также была переписана, включая внутреннее кэширование через обратный прокси-сервер. В последнем релизе Drupal количество запросов к базе данных сократилось на 33%, и это достижение заслуживает внимания.

Результат: Современный инструментарий

Сейчас звучит донельзя просто: «теперь у Drupal есть привычный для большинства других проектов PHP-инструментарий», но это преуменьшение колоссального объема работы, проделанной ради достижения этой цели. Результатом этих усилий стало то, что теперь, полагаю, можно назвать «стандартом». У Drupal есть набор тестов, управление зависимостями через Composer, возможность легко подключать статические анализаторы вроде PHPStan, автолинтинтеры и все остальное, что вам по душе. Если вы привыкли работать с такими проектами, как Laravel и Symfony, все здесь покажется знакомым: контейнеры сервисов, типизированные интерфейсы, внедрение зависимостей и тому подобное.

В сегодняшних реалиях есть и дополнительное преимущество: такая архитектура идеально подходит для разработки и помощи с использованием ИИ-агентов.

Эволюция: Drupal CMS

Демонстрация нового лица и реальности разработки на Drupal от Майка проходила на примере Drupal CMS, которая располагается поверх ядра. Создание посадочной страницы за считанные минуты — готовой страницы с превью в различных разрешениях — это, как он признается, было просто невозможно пять лет назад (особенно если учесть процессы деплоя и сопутствующие инструменты). Теперь вы можете свободно перетаскивать элементы по холсту, появились компоненты JSX React и многое другое.

Заключение: Новый мир

Нам, как PHP-разработчикам, следует хорошо осознавать, что у других разработчиков сохранилось устаревшее представление о самом языке. В результате доклад Майка служит для нас отличным стимулом понимающе кивнуть: Drupal образца 2010 года — это совсем не тот Drupal, что мы видим сегодня. Возможно, для этого потребовались огромные усилия, но главное — они это сделали.

Итог: Движение вперед

Еще один год, еще одно успешное мероприятие. Как и ожидалось, главной горячей темой оказалось множество выступлений об искусственном интеллекте. Для меня важнее то, как JetBrains подходит к выбору спикерского состава: мы представляем собой огромную экосистему масштабных проектов. Конечно, из-за своих размеров многие из этих проектов обладают собственными сообществами, но перед лицом новой реальности разработки ПО с помощью ИИ нам лучше держаться вместе.

К 2027 году мир снова полностью изменится, так что трудно предсказать, чего ожидать в следующем году. На фоне того, как NativePHP и FrankenPHP наращивают свои возможности (we even saw a new GTK3 implementation!) и история повторяется с запуском другого языка и среды выполнения. Если можно вынести из этого какой-то один главный вывод, так это то, что PHP все еще жив и никуда не собирается уходить в обозримом будущем.

Часто задаваемые вопросы

Q1: Заменит ли ИИ программистов на PHP?

Судя по тому, что реально показали на PHPVerse 2026 — нет. ИИ уже пишет значительную часть рутинного PHP-кода (CRUD-эндпоинты, шаблонные тесты, миграции), но каждый спикер, который прямо затрагивал этот вопрос, включая Джеффри Уэя (Jeffrey Way), утверждал, что работа смещается в сторону код-ревью, системного проектирования и принятия решений, а не исчезает вовсе. Честный ответ заключается в том, что ИИ быстрее заменяет определенные задачи внутри профессии, чем саму профессию.

Q2: Что такое PHPVerse 2026 и кто на нем выступал?

PHPVerse 2026 — это пятичасовая прямая трансляция, организованная компанией JetBrains 9 июня 2026 года и собравшая влиятельных представителей PHP-экосистемы. Мероприятие собрало около 15 000 просмотров в общей сложности и 10 206 комментариев в чате. Среди спикеров были Джеффри Уэй, Ларри Гарфилд (Larry Garfield), Майк Херчел (Mike Herchel) и несколько других экспертов, освещавших темы от кодинга с помощью ИИ до управления проектом PHP и эволюции Drupal.

Q3: Как на самом деле утверждается PHP RFC?

Предложение по улучшению PHP (RFC) начинается с письменного проекта, который открыто обсуждается в почтовой рассылке разработчиков ядра PHP (PHP internals), а после затихания дискуссий выносится на официальное голосование. Для принятия большинства RFC по изменению языка требуется квалифицированное большинство в две трети голосов — намеренно высокая планка, призванная защитить язык, от которого зависят миллионы продакшн-сайтов, от победы узких предпочтений какого-то одного контрибьютора.

Q4: Стоит ли до сих пор изучать Drupal в 2026 году?

Для подходящих задач — да. Спикер PHPVerse 2026 Майк Херчел утверждал, что Drupal сместился в сторону современной, тестируемой, объектно-ориентированной архитектуры на PHP, которая напрямую решает старые проблемы с процедурными хуками. Он по-прежнему не подходит для небольшого маркетингового сайта, но для крупных и структурированных контент-проектов заслуживает второго шанса, если ваше последнее мнение о нем сформировалось несколько лет назад.

Q5: Что представляет собой SDK протокола контекста модели (Model Context Protocol) от PHP Foundation?

Это официальный PHP SDK для протокола Model Context Protocol от Anthropic, созданный PHP Foundation в сотрудничестве с собственной командой MCP компании Anthropic и Symfony. Он предоставляет PHP-разработчикам официальный и поддерживаемый способ подключения PHP-приложений к агентам и инструментам искусственного интеллекта для написания кода, вместо того чтобы полагаться на неофициальные общественные пакеты.

Q6: Поддерживает ли Vonage PHP по-прежнему?

Да. Количество установок Vonage PHP SDK через Composer превысило 6,5 миллионов, и в январе 2026 года состоялся релиз мажорной версии 4.3.0. Vonage продолжает публиковать контент для разработчиков на PHP и посещать мероприятия PHP-сообщества, такие как PHPday Verona, наряду со своими SDK для Node, Python и Java.

Q7: Где можно посмотреть доклады с PHPVerse 2026?

JetBrains опубликовала полную запись прямой трансляции PHPVerse 2026, а отдельные сегменты докладов снабжены временными метками для тех, кто хочет сразу перейти к конкретному спикеру, не просматривая все пять часов. Загляните в блог JetBrains PhpStorm, чтобы найти прямой обзор и ссылки.