Вот уже полгода как клиенты регулярно делятся историями про внедрение AI в разработку, а на прошлой неделе был особенно показательный случай. Компания, с которой год назад внедряли Scrum, решила добавить локальные AI-модели и coding agents для ускорения разработки.
В разговоре с их tech lead'ом мы ожидали услышать очередную историю успеха. Получилось нечто намного интереснее.
Эйфория первых недель
Первые три-четыре недели команда переживала настоящую эйфорию. Задачи которые раньше занимали неделю, теперь закрывались в течение дня. Рабочий прототип готов, всё работает, все довольны. Разработчики в восторге, менеджмент уже думает, что можно брать больше задач, product owner радуется, что velocity выросла в три-четыре раза.
Любая команда на их месте подумала бы, что наконец-то нашли серебряную пулю.
А потом начались проблемы
Где-то через месяц прилетел звонок: "У нас большая проблема, и непонятно как её решать". В голосе tech lead'а была такая растерянность, которая редко слышится от опытных специалистов.
Вот что произошло: когда один разработчик начинает генерировать десяток пулл-реквестов за день (не за неделю, а именно за день!), и таких людей в команде пятеро, возникает совершенно новая динамика, которую никто не учитывал. В репозиториях создается море изменений, которые затрагивают разные слои системы одновременно.
Начинается хаос: один и тот же функционал реализован в трёх местах по-разному (потому что AI предложил три разных подхода трём разным людям), непонятно, кто за какой компонент теперь отвечает, архитектура размывается, код расползается по всей кодовой базе. В команде из пяти человек просто физически невозможно отследить такой поток изменений качественно.
"Мы утонули в собственном коде", так описали это сами разработчики, и это, пожалуй, самое точное описание проблемы.
Главное открытие: это не проблема технологии
После часового обсуждения деталей стало понятно: это вообще не проблема AI. Совсем не проблема искусственного интеллекта или coding agents.
Это проблема того, что команда не договорилась, как работать в новом мире, где скорость написания кода выросла в несколько раз, а процессы остались старыми.
Это напоминает первые попытки внедрения Scrum лет 15 назад — команды брали практики (daily standup делали, ретроспективы проводили, доску задач вели), но продолжали работать с тем же водопадным мышлением, что и раньше, и потом удивлялись почему не работает. Потому что мышление не менялось, договорённости оставались старыми.
Тут та же история, только AI изменил не методологию работы, а скорость её выполнения, и этого достаточно, чтобы сломать все привычные процессы.
Что конкретно сделали и что сработало
С командой провели две рабочие сессии (кстати, product owner'а тоже пригласили, и это оказалось важно, так как он услышал технические детали которые раньше не понимал, и это повлияло на его подход к планированию спринтов).
Вся команда села вместе и выработала простые договорённости:
- Каждый разработчик отвечает за каждую строку кода который он коммитит, неважно кто его написал, он сам или AI. Это звучит очевидно, но многие думают, что "ну если AI сгенерировал, то наверное оно правильное". Нет. Ответственность всегда на человеке, который нажимает кнопку.
- Никакого автоматического мёржа AI-кода, даже если он выглядит красиво и проходит все тесты. Были команды, которые хотели настроить автомат для "очевидно правильного" кода, и это всегда заканчивалось плохо. Всегда нужен человек который посмотрит не только на то, работает ли код, но и на то, как он вписывается в общую архитектуру.
- Проверять все изменения не только локально, но и в контексте кодовой базы всего проекта. То есть, смотрет не как обычно мы делаем, "работает ли новая фича", а "как это влияет на архитектуру, "не создаём ли мы технический долг", "не дублируем ли мы то, что уже есть в другом месте".
Но договорённостей оказалось мало, пришлось эволюционировать и инфраструктуру.
Команда добавила AI-агентов для код-ревью, которые работают в реальном времени. Настроили автоматический анализ архитектуры, который не дает закоммитить новый код, ломающий архитектуру, и сам видит, когда пора отрефакторить тот или иной сервис. И самое ценное, сделали инструмент, показываещий влияние изменений на всю кодовую базу - а это вообще решает одну из главных болей в enterprise-разработке.
Главный принцип разработки
Ключевой вывод, который команда сформулировала после этого опыта: наша цель - писать не больше кода, а меньше, но лучшего качества.
AI позволяет написать тонну кода за секунды, но это не значит, что нужно писать тонну кода. Наоборот, теперь у команд есть возможность потратить освободившееся время на то, чтобы хорошо продумать архитектуру, отрефакторить то, что давно просило рефакторинга, упростить сложные места.
Меньше кода, но продуманного и чистого, это всегда было важнее чем много кода, и AI это не изменил.
Что можно вынести из этого кейса
Если вы внедряете или планируете внедрять AI-ассистентов в разработку, стоит заранее обсудить в команде:
- Как будет работать ответственность за AI-сгенерированный код
- Какие проверки обязательны даже для "красивого" AI-кода
- Как отслеживать влияние быстрых изменений на общую архитектуру
- Какие инструменты помогут справиться с увеличенным потоком изменений
И самое главное, помнить, что изменение скорости работы требует изменения процессов, а не только инструментов.
Если вы уже используете AI в разработке, встречали похожие вызовы с потоком изменений и архитектурой? Или нашли какие-то другие подходы которые хорошо сработали?
Интересно узнать подробнее?
Приходите на один из наших тренингов, где вы в деталях разберете эту тему и сможете задать тренеру свои вопросы.
