Банк перевёл команду на tiny teams: ИИ пишет 90% кода, агенты берут 20% задач

Большинство команд уже используют ИИ, но в основном как умное автодополнение: инженер пишет, модель подсказывает. Команда Budget Tool из банка, которая занимается управлением расходами, пошла дальше. Она пересобрала сам процесс вокруг небольших групп, где каждый инженер отвечает за результат целиком, а рутину делает агент. Техлид Дима Вдовин рассказал на Habr, что из этого вышло. Рассказ честный: с провалами и неприятными побочными эффектами.

Первый спринт — провал, и это полезно

Исходные данные такие: две кросс-функциональные фича-команды на 14 человек, Kotlin и Spring на бэкенде, TypeScript и React на фронтенде. Для пилота выделили двух человек, бэкендера и QA, и два месяца. Цель: закрывать user story целиком, от аналитики до продакшена.

Первую маленькую задачу за две недели до прода не довели. Много времени ушло на разбор требований, но больше всего на фронтенд. Агенту пытались скормить макеты из Figma, а потом бесконечно правили результат по замечаниям ревью. Лицензии на Figma Dev Mode и соответствующий MCP были только у фронтендера и дизайнера. Поэтому иногда проще было просто показать агенту скриншот готового экрана.

Дальше стало быстрее: с каждым спринтом цикл сокращался. Но проблемы остались, и все они про контекст:

• Знания живут в головах. Архитектурные договорённости копились годами, а пока их нет в контексте агента, он ошибается.
• Ревью тормозит. Продуктовому инженеру трудно оценить код в чужой области, и код пишется быстрее, чем проверяется.
• Неясно, как показывать дизайн. Нужен нормальный канал от макета к агенту, а не набор костылей.

Harness как продукт

Harness в этой истории — набор правил, навыков (скиллов), MCP и контекста, которые помогают агенту работать именно в вашем проекте. Команда не стала писать велосипеды и переиспользовала то, что уже есть в банке и домене.

Главная идея — непрерывный цикл: выполнили задачу с ИИ, разобрали, где агент споткнулся, дополнили навыки и контекст, запустили снова. За это отвечают хабы по экспертизам: бэкенд, фронтенд, QA и системный анализ. Они собирают обратную связь от всех tiny teams, находят пробелы и раздают лучшие решения остальным.

Команду разделили на четыре tiny teams и discovery hub, где сидят продакт-оунер, дизайнер и бизнес-аналитик. Аналитика в tiny teams нет намеренно: так выше мотивация использовать ИИ. Задачи сортируют по цвету. Зелёные, мелкие, отдают автономным агентам. Жёлтые, крупные, делают внутри команды локально с ИИ-помощью. Красные, экспертные, требуют глубокой экспертизы и решаются только объединёнными силами.

Агенты на сервере и цена эффекта

Сначала всё делали локально: так проще поправлять агента сообщениями и набираться опыта. Но локальный агент работает, пока открыт ноутбук. Команда хочет, чтобы агент был ещё одним инженером: назначил задачу в трекере и получил готовый MR.

Начали с безопасности. Когда AppSec-сканирование находит уязвимую библиотеку или образ, агент сам заводит задачу, вносит правки и готовит MR. Утром на ревью лежит несколько готовых запросов. Теперь так же передают небольшие бизнес-задачи, если понятно, что, как и где менять.

Итоги за полгода: 90% кода пишет LLM, больше 70% бизнес-задач сделано в режиме AI-assisted, больше 20% решают серверные агенты. Но сначала число закрытых задач упало, а потом вылезли побочные эффекты:

• растёт когнитивная нагрузка и риск выгорания;
• без знаний в смежных областях нельзя ни поставить задачу, ни проверить результат;
• ревью надо перестроить: смотреть архитектуру, а не синтаксис;
• анализ и планирование остаются на человеке, и решений ему приходится принимать больше.

Что из этого забрать себе

Советы авторов приземлённые. Начинайте с повторяемой задачи с ясными критериями готовности. Берите готовых кодинг-агентов, а не пишите своего. Сначала отладьте сценарий локально и только потом выносите на сервер. Всё детерминированное прячьте в скрипты, которые вызывает скилл. Документацию пишите так, чтобы её одинаково понимали люди и агенты.

Особенно ценна мысль про eval-метрики: без них непонятно, улучшился harness или вы просто меняете настройки. Поэтому его стоит вести как продукт и честно записывать в технический долг.

Ограничения тоже важны. Это опыт одной банковской команды с отлаженным стеком. Цифры внутренние и никем не проверены, а сложные аналитические задачи с высокой ценой ошибки агентам пока не отдают. Но вывод универсальный: скорость вам даст не более мощная модель, а то, насколько хорошо ваша команда умеет объяснять агенту, как у вас принято работать.