Постоянная рубрика "блекпилл недели по AI коду."
После
предыдущего болезненного опыта, где я обнаружил, что агенты ужасно пишут код и за ними потом надо неделями разгребать слоп, я задумался как быть. Это новая реальность разработки софта и мне как СТО нужно придумать как существовать в новом мире.
Изучая, что придумали более умные люди, я понял: ничего. Никто не знает как жить в новом мире, когда один разработчик производит столько кода, сколько в прошлом мог производить целый отдел. За пределами твиттера проблема известная (т.е. большие компании вроде Cloudflare и GitLab уже написали блог-посты), но решения никто не нашел.
На основе своего и чужого опыта придумал гайдлайны по AI разработке для нашей команды.
Основные предположения:
1. Код важен. Код это то, что действительно исполняется, а значит единственный источник истины. Все спеки это в лучшем случае искаженные описания кода, а чаще всего просто слоп-эссе на тему.
2. AI агенты это мультипликаторы скорости генерации кода. При наивном применении они перекладывают работу с автора кода на меинтейнера.
3. Главный ограничивающий ресурс это понимание кодовой базы разработчиками.
4. Деградация кода неизбежна и поддержание его качества это необходимая работа.
5. Агенты для кода ненадежны и непостоянны. Результат зависит от множества постоянно меняющихся факторов: модели меняются, сетап у всех разный, и так далее. Если что-то работает сейчас, нельзя гарантировать, что оно будет так же работать завтра.
6. Агенты для кода быстро производят техдолг и не могут самостоятельно его уменьшать.
Отсюда следующие принципы того, как может работать адекватная система:
1. Необходимо перенести работу по поддержанию качества назад с мейнтейнера на автора.
2. Люди отвечают за дизайн и архитектуру.
3. Люди отвечают за систему верификации: pre-commit, CI чеки, документация и принципы. Только люди редактируют
AGENTS.md и постоянные доки.
4. Все правила, которые можно, нужно превращать в механические чеки, потому что промптинг не гарантирует, что агенты будут их соблюдать.
5. Борьба со слопом закладывается в бюджет.
6. Минимизируем человеческие затраты на ревью, максимально автоматизируем проверки и контроль качества.
Первый пункт самый главный: можно вайбкодить как угодно, если в результате у тебя рабочий код который ты понимаешь.
И конкретные практики:
1. Каждый PR не более +2к строк кода. Эмпирически найдено, что больше отревьюить невозможно.
2. Автор каждого PR сам пишет его описание по шаблону и указывает какие сущности за что отвечают.
3. Очень жесткие pre-commit и CI чеки.
4. Кастомный код-ревью бот в CI, который отсматривает каждый дифф и весь PR в целом с целью доказать, что он сломан. Промптится логом прошлых инцидентов, который пополняется только людьми.
5. Люди дизайнят скелет своих изменений в AI-assisted режиме, агенты заполняют пропуски.
6. Доки пишутся людьми, агентам запрещено их редактировать.
7. Разгребание слопа закладывается в планирование.
Всю карьеру (в эру кожаного кодинга) я считал pre-commit чеки очень бесячими и не особо полезными. Теперь же у нас самые жесткие чеки и линтеры в моей жизни. Там как базовые вещи вроде ruff и black, так и кастомные правила import linter, и многое другое. Я постоянно завожу что-то новое. Например, недавно добавил проверки на вложенность и цикломатическую сложность функций из SlopCodeBench. На днях появилась проверка всех диффов с помощью Jev.
Это более-менее сработало. Pre-commit с механически забитыми правилами позволяет видеть не совсем слоп на этапе ревью. Очень жесткий CI обеспечивает то, что слоп обнаруживается до мержа, а не после. Но появились новые проблемы.
Самая главная: актор с критиком могут очень долго итерироваться над PR без видимого прогресса. Агент делает изменения, ревьюер находит блокирующие проблемы, агент делает заплатку, ревьюер находит следующую дыру и так далее. Я видел как это происходило буквально днями, до тех пор, пока я не погружусь и не разберусь: в чем же корень проблемы? Ни одна модель (вклюбчая Fable и Astra) пока ни разу не смогла сама выбраться из этой спирали.
Вытекающая проблема: медленно. Теперь беклог PR разгребается гораздо медленнее, чем пополняется. У агентов как будто появляется новый инструмент: защита (своего кода)
заебыванием. Когда ревьюер в десятый раз находит ошибку в каком-то PR возникает очень сильное желание вмержить его, чтобы просто больше не видеть.
Что иронично: ускорение от вайбкода как будто целиком компенсируется или замедлением на этапе ревью, или, если вы на вайбах, разгребанием проблем в проде спустя пару недель.
