ANTICHAT - Почему AI ломает старые PHP-проекты

Почему AI ломает старые PHP-проекты — кто сталкивался?

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

Почему AI так рвет старый PHP-код

Корень проблемы — несоответствие подходов. AI-инструменты (тот же GitHub Copilot, ChatGPT, OpenAI API) обучают на современных кодовых базах, документации и лучших практиках последних лет. Они выдают советы по рефакторингу, оптимизации, смене функций основываясь на свежих PHP-стандартах (PHP7, PHP8), а часто старые проекты написаны еще на PHP4 или PHP5, с кучей костылей, глобалами, самописными штуками и обходными путями.

Старый код писал человек в рамках ограничений и понимания своего времени. Он часто наполнен хаком, сделан с оглядкой на конкретный сервер, точные версии библиотек, и зачастую ломать этот код — значит ломать бизнес-логику. AI пытается улучшить стиль, убрать deprecated-функции, перестроить структуру — и в этом его беда, ведь рефакторинг не учитывает весь контекст, а просто выдает шаблонный вариант.

Где чаще всего происходят конфликты

Проблемы с AI особенно заметны в ситуациях:
- Когда проект огромный и запущен на старом PHP4/5. Там много устаревших функций типа mysql_query, ereg или register_globals.
- Если проект использует древние версии фреймворков (Zend 1.x, Symfony 2, Yii1), которые сильно отличаются от современных.
- В проектах без нормального тестирования, где вообще мало кто понимал внутреннюю логику.
- Если AI пытается рефакторить сразу много — меняет структуру массивов, конвертирует циклы, внедряет namespace, а старый код это не поддерживает.
- Там, где наш код с кучей side-effect’ов и глобалок: AI советует убрать globals, а проект рухнет из-за неожиданной зависимости, на которую у AI нет данных.

Рассказ как это бывает на практике

Пример 1: Замена mysql_* на PDO
AI красиво выдает код с PDO, говорит — так надо. В общем-то логично и правильно. Но тут нюанс: остальная часть проекта заточена под старые функции — выполнена куча самописных оберток, которые под новую структуру не адаптированы. В итоге запросы просто не проходят, разрушается цепочка вызовов, появляются необъяснимые ошибки. В итоге приходится вручную переписывать весь слой взаимодействия с базой, а это гигантские правки.

Пример 2: Автоматический рефакторинг циклов
AI предлагает поменять foreach на array_map или array_filter — звучит красиво и чисто. Но со старым кодом, где в цикле может быть сложная логика с условными входами, побочными эффектами, это ломает логику. Например, в одном проекте array_map сделала копию массива и вернула новую структуру, тогда как старый код рассчитывал на работу именно с оригинальным массивом и его изменениями в цикле.

Пример 3: Переработка глобальных переменных
AI ругается на globals и советует внедрить Dependency Injection. Казалось бы — классно. Но старый код использует глобалы много где и плотно, в том числе для передачи параметров по всей цепочке вызовов. Без полного ребилда архитектуры, который не всегда возможен, эти изменения приводят к сбоям и невозможности отследить ошибки.

Пример 4: Изменение структуры данных
AI предлагает вместо старых массивов с вложенными индексами перевести на объекты или новые структуры данных. Но если нет полной уверенности, что все места в коде поменяются, это ломает логику: данные ходят по всему коду, ожидая определенный формат.

Типичные ошибки при использовании AI на старом PHP

- Не проверяют версию PHP, на которую рассчитан код. По факту AI выдает советы под PHP7 и выше, а проект пашет на 5.3 или еще ниже.
- Вносят изменения сразу во всех модулях без локального запуска тестов, из-за чего баги вылезают в проде и ломают всё.
- Меняют сигнатуры функций — параметры, возвращаемые значения — без анализа совместимости.
- Смотрят на AI как на всемогущего эксперта и принимают все советы без разбора.
- Отсутствие или малое количество юнит-тестов в проекте. Без тестов быстро не поймешь, что из-за AI полетело.

Полезные лайфхаки и инструменты, чтобы не сломать

1. PHP CodeSniffer
С помощью него можно прогонять старый код по выбранному стандарту (например, PSR-0, PSR-2), чтобы выявить, что устарело и нужно менять, а что лучше оставить. Просто так не дергай весь код.

2. Статический анализ — PHPStan и Psalm
Эти инструменты отлично выявляют потенциальные ошибки и несовместимости в коде без выполнения. Помогают при рефакторинге под новый PHP-парсер.

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

4. Git
Обязательно коммитьте код до и после изменений AI, чтобы иметь возможность быстро откатиться и сравнить.

5. Xdebug или другие дебаггеры
Быстрый поиск точки падения, контроль за изменениями переменных и стэком вызовов.

6. Локальные интеграционные тесты
Если юнит-тестов нет, хотя бы добавьте интеграционные «ручные» проверки, чтобы понять, сохранилась ли бизнес-логика.

Чек-лист перед применением AI к старому PHP
- Проверить версию PHP и используемые расширения;
- Запустить статику и линтер на исходном коде;
- Сделать коммит в git;
- Прогнать все существующие тесты (если есть);
- Работать с исправлениями по частям, не все сразу;
- Отдельно ревью каждого блока кода с изменениями AI;
- Если меняете устаревшие функции — адаптировать весь слой, а не точечно;
- Если проект монолитный — оценить влияние на связанный код;
- После каждого шага — проверки работоспособности и производительности;
- На прод не выкатывать без тестов и полностью рабочей версии.

FAQ

— Можно ли просто взять и доверить старый проект AI полностью?
Нет. AI — мощная помощь, но старый код никогда не будет простым. Его нужно проверять, держать под контролем и тестировать по максимуму.

— Какие ошибки чаще всего ломают проект после AI-правок?
Неправильная замена устаревших функций без адаптации контекста, изменение структуры данных и циклов, непредусмотренное удаление или изменение глобалок.

— Есть ли универсальный способ избежать поломок?
Увы, универсального рецепта нет. Лучшее — поэтапная работа с тестами и ревью кода. Ими ичем где именно AI полезен, а где он вредит.

— Что делать, если проект после AI «сломался»?
Сразу откатывайте изменения в git, анализируйте проблему, разбивайте задачи на части и внедряйте правки постепенно.

— Может, просто переписать весь старый проект?
Это хороший вариант, но часто нересурсоемкий и долгоиграющий. Не всегда есть возможность на это.

Итоги

AI - это классный инструмент, который может помочь с рефакторингом, повысить скорость и качество кода. Но когда речь идет о действительно старом PHP, надо быть очень аккуратным — не бросаться менять всё сразу под современные стандарты, а работать осторожно, тестировать и сохранять логику. AI тут больше советчик, чем волшебник.

Если вы сталкивались с подобным — делитесь, как решали проблемы, какими инструментами пользовались для безопасного апгрейда старого кода. Может, кто-то натолкнет на классные практики или лайфхаки, которые спасут проект и нервы.