Кто-то кайфует от новых возможностей и говорит, что теперь всё будет делаться с AI. Кто-то называет ерундой, говорит AI ничего не может, и придумывает таким разработчикам клички типа “Саша GPT”. Кто-то готовится к обороне кода как Егор Бугаенко (@yegor256) в своём видео “Как защитить код от AI”: https://www.youtube.com/watch?v=GPJ-LfRpxM4 (очень рекомендую посмотреть)
На какой стороне вы? Новаторов или староверов?
Делюсь своим видением происходящего, с какими плюсами и ограничениями столкнулся на практике.
Начнём с признания факта, что AI (он же LLM, что более правильно) пока ещё не интеллект, а система просчитывающая вероятность появления тех или иных слов/символов (токенов) вслед за промптом. Упрощая, LLM — это продвинутый “бредо-генератор” или более привычный автокомплит. И с такой точкой зрения исчезают завышенные ожидания. Когда автокомплит выдал не тот результат, что хотел разработчик, это хоть и досадно, но нет злобы. И сложно найти разработчика, который сказал бы, что автокомплит в IDE — это какое-то зло.
Понизив градус страстей можем двигаться к практическим результатам. В чём AI уже хорош?
В чём AI уже хорош
Первое: Работа по образцам!
Будь то рефакторинг кода или генерация интеграции ещё одной API. Имея подробное описание и образец AI отлично справляется с работой.
Немного цифр на примерах.
1) Большой старый проект написанный на Symfony. Сотни энтитей. Имеет технический долг в виде не описанных типов данных элементов коллекций. В результате: нет автокомплита, затруднён поиск использования методов энтитей (нет поиска по юзу, только поиск по тексту), PHPStan плохо понимает с чем имеет дело. Итого имеем: замедляется разработка и рефакторинг, повышается риск сломать существующую функциональность. Оценка затрат на исправление: примерно 3 дня.
Пробуем исправить с AI. Как раз в тот момент внедряли использование Cursor. Описание правил для коллекций и связанных с ними геттеров и сеттеров, с экспериментами заняло минут 40. Дальше сохраняем правило в проекте и пришем промпт: “Найди все doctrine-энтити в проекте и исправь согласно правил, описанных в проекте”. Пошли сделали кофе, пока работала AI. Несколько раз дошлифовывали описание и перезапускали. Это заняло ещё около часа.
Итог: 2 часа против 3-х дней работы. И побочный эффект - готовое описание коллекций для AI, за которыми дальше он будет следить самостоятельно каждый раз, когда работает с коллекциями. Что дальше ещё больше ускорит разработку.
2) Есть у меня проект TODO Registrar, позволяющий создавать тикеты в тикет-трекинговых системах типа JIRA из TODO-шек в коде. Занимаюсь им в свободное время. За несколько вечеров с AI было сделано:
переход на компоненты Symfony вместо ручной сборки сервисов для упрощения развития
инт��грация с несколькими новыми трекинговыми системами (по образцу имеющихся)
расширенная валидация настроек, получаемых от пользователя при запуске, с подсказками
создал GitHub Action (https://github.com/marketplace/actions/todo-registrar) для облегчения интеграции моего решения
переработал документацию и закрыл много мелких ишьюсов.
Старый подход когда нужно разбираться с новой API, искать и сравнивать библиотеки, разбираться в их работе и только потом писать код — это заняло бы минимум месяц, с учётом работы только по вечерам. И сравнивая стоимость подписки 20$ в месяц со стоимостью рабочего часа — это мега выгодное решение.
Второе: Прототипирование и старт проекта
Необходимо было реализовать несколько плагинов к osTicket для службы поддержки. Под эту систему раньше никто в компании не разрабатывал.
Например, нужно было ни много ни мало автоматизировать назначение ответственного отдела по контенту обращения. Заголовок и основной текст обращения, и прикреплённые файлы в различных форматах. Какие-то можно распарсить, какие-то нужно распознавать. Во сколько оцените эту работу? Этот плагин с динамическими настройками, интеграцией API для использования AI и контейнеризацией был сделан за день. Следующий по образцу был собран за пару часов.
Третье: Вёрстка
У вас есть макет в Figma? Отлично. Сделает вёрстку для web или Flatter на ура! Тут цифр под рукой нет, но коллеги делились результатом с круглыми глазами.
Четвёртое: Изучение проекта и документирование.
Документация — это боль и несбыточная мечта многих проектов. Как быть тем, кто недавно пришёл на проект? Особенно QA и BA. Тут AI может много рассказать про ваш код: последовательность вызовов, проверки и многое другое. И если хотите, то может создать документацию. Например, может заполнить QA-notes в тиките.
Ограничения
У этого праздника жизни есть и свои ограничения. Я опущу здесь организационные моменты, вопросы внедрения, оплаты и выбора моделей. И сконцентрируюсь на технических проблемах, с которыми встретится разработчик.
Первое: Каков проект таков и результат
AI будет придерживаться стиля проекта. Если ваш проект с легаси, не явными вызовами и запутанной логикой, то и сгенерированный код будет такой же. Или AI вовсе запутается и выдаст бред. За то на хорошо построенных проектах код выдаёт весьма приличный.
Второе: Короткая память
Кода вы что-то делаете, то через день или неделю помните контекст. AI же помнит только в рамках сессии. Дальше как человек с болезнью мозга — поспал и забывает. И каждый раз нужно “вводить в курс дела”, т.к. он уже ничего не помнит о вашем проекте.
Третье: Малое контекстное окно
Большие проекты AI не может проглотить целиком. Только по частям. И вам нужно привыкнуть “держать в узде” модель с помощью уточнения контекста работы, чтобы модель не потеряла фокус внимания и не запуталась. И не пытайтесь делать задачи одну за другой в одном диалоговом окне — для неё слишком много информации. Одна задача — одно диалоговое окно. Потратьте немного токенов на рассказ ей о проекте заново — так она лучше держит фокус внимания и выдаёт лучше результат.
Четвёртое: Распухший код и копипаста
AI склонен нагородить кучу if-ов там где можно применить одну стандартную функцию. И если одна и та же логика используется в 2-х местах и с минимальными отличиями, то он дублирует код вместо того, чтобы вынести дублирующийся код в отдельную процедуру. В итоге, во время ревью порой приходится выкидывать две трети сгенерированного кода,чтобы сделать его лучше поддерживаемым.
Какие есть решения проблем?
Первое: Создание образцов
В дополнение к описанию того, что требуется сделать, покажите ему образец. Это может быть не только в проекте, но и ссылка в интернете или путь к каким-то локальным файлам другого проекта. Если нет образца, то сделайте его в проекте. Это сильно ускоряет и улучшает получаемый результат.
Второе: Контекстная подгрузка документации
Можно создать отдельные документы по разным вопросам как архитектуры, так и бизнес-задач. И давать контекстные ссылки на них.
Когда работаешь с фичей `А`, то учитывай инструкции из файла `docs/features/a.md`
Можно создать отдельный документ со списком фич проекта и ссылками на документации по ним. Тогда AI будет подгружать только требуемые документы. Это экономит контекстное окно и использование токенов.
Третье: выделение терминов
Порой (часто) полезно бывает подсказать LLM, что часть промпта — это термин, тогда она лучше понимает что именно нужно сделать, в какой части проекта и какую документацию нужно подгрузить динамически. Это может быть точный термин на английском, когда промпт написан на русском или кавычки. Сама LLM часто использует одинарные обратные кавычки — вы тоже так можете.
Четвёртое: MSP
MCP — это не только сторонние сервисы, их можно запускать локально в виде докер-контейнеров. И последних полезных:
atlassian - для подключения к JIRA и Confluence
serena - позволяет представить код в виде векторной базы данных с которой может общаться AI вместо прямого анализа кода, что экономит использование токенов.
Экспериментируйте. Буду рад, если поделитесь своими находками в комментариях.
Пятое: автоматизируйте проверку кода
Надеюсь у вас в проекте уже используются утилиты для проверки качества кода. Можно попросить AI запускать их после внесения изменений.
После создания и изменения ��ода выполняй команды:
PHP CS Fixer: `composer cs-fix -- --show-progress=none`
PHPStan: `composer phpstan`
PHPUnit: `composer test-all`
И модель может использовать их output для внесения правок ещё до того, как отдаст результат вам на ревью.
Видение будущего
У многих появились переживания по поводу будущего программистов. Мол, всех программистов заменят дешёвой AI. Переживания не беспочвенные, но как по мне переоцененные. Да, IA сильно удешевляет разработку, но я бы не переживал за программистов.
Во-первых, далеко не всё может решить AI. Особенно в больших и старых проектах с легаси. Хорошие инженеры всё так же нужны.
Во-вторых, приведу пример с лампочками. Когда появлялись энергосберегающие лампочки, было много разговоров, что не нужно будет так много электричества и можно будет закрыть часть электростанций. Но другие специалисты говорили, что люди не будут тратить на электричество меньше, просто будут жить в более светлом мире. Так и оказалось. Аналогично с программистами — нам ещё столько всего нужно автоматизировать, что работы хватит ещё очень надолго.
Другими словами, ожидается не столько падение зарплат отдельных специалистов, сколько кардинальное удешевление разработки для бизнеса за счёт того, что с новыми инструментами программист будет больше успевать в единицу времени.
Конечно же поменяется структура команд. Я уже вижу команды, которые сознательно отказываются от BA, перекладывая значительную часть работы BA на AI. Не хочу умалять заслуги BA — действительно хорошие, понимающие тонкости бизнеса и особенности разработки, приносят огромную пользу. Однако встречаются не так часто, как хотелось бы, и в новых реалиях в продуктовых командах BA превращается в секретаря между IT и бизнесом и оформителя тикетов. В то время как за счёт прямой коммуникации разработчиков с бизнесом улучшается понимание требований разработчиками и ускоряется выдача на продакшен MVP фич.
Тут же маячит упрощение и ускорение разработки различных Open Source решений и увеличение конкуренции между ними. Нет драйвера под твою систему, но есть под похожую? Вечер с IA и у тебя есть драйвер. Нет подходящей библиотеки для API, но есть документация по API? Не беда. Начальный вариант можно сгенерировать достаточно просто.
С удешевлением IT упрощается создание проектов-клонов. Это большой риск для бизнеса и тянет увеличение маркетинговых затрат и юридического сопровождения. Тут же рядом удешевление создания экспериментальных продуктов для захода в новые ниши. Это, в свою очередь, ведёт к росту потребности в автоматизации процессов, мульти-платформенных решений, анализа всего и вся, чтобы точнее сегментировать аудиторию и попадать ей в сердце. Это заставляет развиваться соответствующие рынки.
После того как подешевеет создание инструментов коммуникации с потребителями, острее встанет вопрос доставки товаров и управления складскими запасами. Другими словами, следующим большим ограничением для бизнеса станет логистика. И она потребует новых IT решений.
