Гайдлайны по AI-разработке: как бороться со слопом

Постоянная рубрика "блекпилл недели по 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 возникает очень сильное желание вмержить его, чтобы просто больше не видеть. Что иронично: ускорение от вайбкода как будто целиком компенсируется или замедлением на этапе ревью, или, если вы на вайбах, разгребанием проблем в проде спустя пару недель.