Автоматизированные квалити гейты

Хочу поделиться практическим приемом. Он мне спас очень много нервов

Поскольку агенты могут дрифтовать и цеплять функционал очень важно обеспечить надежность всех изменений. Особенно, когда мы трогаем архитектуру, шеренные либы или готовые фичи. Перекинуть проект на другой пакетный менджер, заменить сборщик, распилить архитектуру на независимые модули, вынести фуникциональность в лейзи чанки, обновить и централизовать управление общими зависимостями (особенно в микрофронтовой архитектуре). Да даже просто вносить функциональные изменения и багфиксить -- все это требует надежности, нужно чтобы агенты не наворотили лишнего и не сломали тебе код

Я собрал пачку рецептов, которые помогают удержать управление кодовой базой 

1. Строгие требования о прокрытии тестами. Если создается новый, изменяется или удаляется существующий функционал, требуем от агентов покрывать все тестами, пишем правила как писать тесты, как мокировать, описываем принципы тестирования, настраиваем агентное ревью. Код без тестов и покрытия не принимается

2. Линтеры. Обязательно настраиваем все стандартные линтеры, как на чистоту кода, так и на следование архитектуре, цикличность зависимостей, протечки абстракций и всё всё всё, что мы считаем плохим кодом и можем быстро проверить программно

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

4. Прекоммит-хуки. Ваше ненавистное. На каждый коммит запускать линтеры. Да. ждать больше не вам, пусть ждет агент. Отдельно убедитесь, что ваши хуки плюются ошибками и ворнингами прямо обратно агенту. Пусть он моментально получает обратную связь и идёт исправлять. Или это потом будете делать вы)

5. Прерпуш-хуки. Тесты. Все аффектед-тесты должны запускаться ДО попадания кода в репозиторий. Да на инфре он еще раз пробежит. Но оно вам потом надо? Важно, чтобы петля обратной связи была как можно быстрее и как можно ближе к работе агента. Пусть также получит всю инфу и инструкции, отлуп и пойдет фиксить

И только потом можно сказать, что "ну ок, можно пушнуть в pull/merge request и отправить собираться на инфрастурктуре.

Бонус: red-green bugfix. Если агент правит багу, он сначала пишет красный тест и воспроизводит баг, потом фиксит. Так вы получаете гарантию, что баг реально закрыт и баг не появиться снова

А если вам все это впадлу и тяжело, чтож) квадратное катание и круглое носите, бог вам в помощь))

AI PDLC манифест от Сбера

Начинаю делиться видео с нашей первой конференции по агентной разработке!

Кирилл Меньшов, старший вице-президент Сбера, руководитель блока Технологии, представил огромную работу, описывающую как измениться жизненный цикл разработки цифровых продуктов. Огромный фундаментальный документ, который затрагивает все стадии производственного цикла: гипотезы, архитектуру, аналитику, разработку, контроль качества и cicd. Он рассказал, как поменяется управление, организацонная структура, топология команд

Главный тезис (который я вам тоже на протяжении последнего года продвигаю): Код теперь стоит дешево, исполнение больше не дифицитно. Теперь узкое место — намерение. Именно то, зачем мы делаем софт, для кого, какая у него потребность и как мы ее закрываем. Это становится узким местом.

https://www.youtube.com/watch?v=48sOgB8kkPw

Именно поэтому я писал кучу постов про A-player'ов, визионерство, продуктовых инженеров и работу с проблемами, а не кодом. Прошлое, в котором можно было получать на вход аналитику, на выход выдавать по ней код и не задумываться зачем оно все надо — прошло

П.С. Крайне рекомендую к просмотру (и это не потому что я работаю в Сбере). Я честно считаю очень правильным поднимать подобный дискурс в российском айти-комьюнити. И я рад, что наши ребята это делают, респект 🤟