AI ни разу не ошибся. Фичу переделывали четыре раза

GenAI и большие языковые модели (LLM)

Программный комитет ещё не принял решения по этому докладу

Целевая аудитория

Команды разработки, в которых используется 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)