AI ни разу не ошибся. Фичу переделывали четыре раза
Программный комитет ещё не принял решения по этому докладу
Целевая аудитория
Тезисы
AI ни разу не ошибся. Фичу переделывали четыре раза
Тезисы для зрителей
AI-агенты пишут код за минуты — и это меняет место, где команда теряет время. Нас это ударило конкретно: доработку «дать смежной команде доступ к существующему методу API» оценили в два дня, а заняла она неделю — четыре переделки уже работающего кода. При этом каждую итерацию Claude Code реализовал корректно. Ошибка была не в коде: четыре вопроса — видимость между тенантами, жизненный цикл объектов, модель прав, «кто от чьего имени вызывает» — мы не задали до старта.
Работа, которая раньше незаметно происходила внутри написания кода — допроектирование, управление архитектурой и потоками данных, уточнение требований, согласования, — с приходом AI никуда не исчезла. Её нужно делать по-новому, и процессно, и содержательно, при этом не возвращаясь в Waterfall. Доклад — о том, как мы выстроили эту работу вокруг спецификаций.
Разберу, как наша команда (8 инженеров, backend на Go, Bare-Metal-as-a-Service в VK Tech) выбирает глубину проработки задачи до того, как отдать её агенту. Мы используем четыре уровня, у каждого — свой контекст применения:
- prompt — локальные, обратимые, понятные правки;
- Claude Code Plan Mode — изменение повторяет паттерн, уже существующий в кодовой базе;
- OpenSpec — задача крупнее или неопределённость выше; сохраняется не только план, но и принятые решения;
- BMAD — требований много, и противоречия между ними нужно найти до кода, а не после.
Отвечу на вопросы:
- по каким признакам понять, что задаче нужен уровень выше — спойлер: не по размеру диффа, а по числу незаданных вопросов на границах;
- какие роли играет спецификация помимо «ТЗ для агента»: носитель правил команды — кодирования, ревью, тестирования, публикации, устройства кодовой базы; история принятых решений, логику которых из кода восстановить уже не получится; основа для согласований;
- что стоит фиксировать после реализации (конвенции, причины важных решений), а что фиксировать не нужно (каждый план);
- как спецификация упрощает согласования: на опыте прохождения security review в AWS (опросник ~150 пунктов, ~2 дня на прохождение, десяток встреч на новый сервис) покажу, как из одного источника правды собирается пакет документов для безопасников — вместо многодневного рисования одноразовых диаграмм, которые после ревью никто не открывает.
Подход не привязан к языку и стеку: нужен любой coding-агент со стадией планирования (Claude Code, Cursor, Codex). Применим к доработкам существующего кода, интеграциям между сервисами и новым сервисам.
Будет полезно тимлидам и сеньорам, которые внедряют AI-агентов в командную разработку и уже почувствовали, что «быстро написать код» и «быстро выпустить фичу» — разные вещи.
30+ лет в ИТ. Программировать начал в 10 лет на калькуляторе МК-52, по-серьезному уже в 16, прошел путь до главного архитектора самого большого внедрения Siebel CRM, и затем переехал за границу и прошел путь до старшего инженера в AWS.
Сейчас техлид продукта Bare-Metal-as-a-Service в VK Tech.
Видео
Другие доклады секции
GenAI и большие языковые модели (LLM)