Привет, я Дима Вдовин, техлид в команде Budget Tool, которая занимается управлением расходами.
В апреле мы с коллегами провели эксперимент по созданию tiny teams, усиленных с помощью ИИ. Первый спринт полностью провалили, но уже в июле масштабировали подход на всю нашу команду и готовы поделиться своими успехами и ошибками.
Рассказываю, как всё проходило на практике: как именно мы работали с ИИ-агентами, развивали командный harness и начали использовать автономных агентов на сервере для выполнения задач E2E.
Как проходил первый эксперимент с tiny teams
В банке мы идем в сторону трансформации в продакт-инженеров. Тех, кто end-to-end отвечает за весь цикл поставки ценности: от выявления потребности до запуска работающего продукта.
Из таких инженеров мы и решили формировать небольшие команды tiny teams и усилять их ИИ-агентами для быстрого и автономного достижения результата. Разница в том, что в такой команде каждый из инженеров несет E2E-ответственность за результат, а вся рутина делегируется ИИ.
На момент первого эксперимента в апреле у нас были две кросс-функциональные фича-команды из 14 человек. Основной стек — Kotlin, Spring для бэкенда и TypeScript, React для фронтенда. Уже тогда все инженеры использовали ИИ, но в основном для написания кода.
Для пилота мы создали мини-команду из двух человек — бэкенд-инженера и QA-инженера. Выделили два месяца, или четыре двухнедельных спринта, и поставили цель: закрывать продуктовые задачи (user story) целиком end-to-end.
На период пилота мы поставили следующие цели:
Проверить, что подход работает. Мы хотели понять, сможет ли маленькая команда закрыть весь цикл разработки продукта (PDLC) и сохранить нужный уровень скорости и качества.
Проверить командный harness — набор инструментов, навыков и правил, которые помогают ИИ работать в проекте.
Выяснить, что у нас уже хорошо получается делать с ИИ, а что пока нет.
Начать больше инвестировать в командный harness.
Итоги эксперимента
Скажу честно, первый спринт мы полностью провалили. Взяли одну совсем небольшую задачу, но за две недели так и не смогли довести её до прода. Сначала много времени ушло на аналитику. Нужно было разобраться в требованиях и понять, что и как делать. Но больше всего мы провозились с фронтендом. Пытались передать агенту макеты из Figma и добиться, чтобы он воспроизвёл дизайн. Потом начались многочисленные итерации исправлений по замечаниям на ревью.
В следующих спринтах мы нарастили скорость и начали закрывать задачи end-to-end, причём с каждым спринтом полный цикл разработки становился быстрее.
Параллельно мы обучали коллег. Рассказывали им про навыки для ИИ (скиллы), саб-агентов, SDD, OpenSpec, провели много встреч по написанию кода с помощью ИИ. Благодаря этому уровень его использования при разработке поднялся во всей команде, а не только в мини-группе.
Но были и проблемы, которые я разделил на три категории.
Много знаний в головах. У нас накоплено много соглашений, правил, нюансов архитектуры. Они нарабатывались годами. Их тяжело быстро описать. Но пока это знание живет в людях, а не в контексте ИИ — ИИ ошибается.
Много замечаний на ревью. Продуктовым инженерам не хватает опыта, чтобы оценить качество работ в непрофильной области до ревью кода (MR). Поэтому, несмотря на то что код пишется быстрее, ревью тормозит разработку и становится узким местом. Плюс на тот момент у нас были неполные правила для ИИ и навыки по авторевью кода.
Как показать дизайн агенту. Во время пилота мы столкнулись с проблемой при работе с макетами из Figma. Лицензии были только у фронтенд-разработчиков и дизайнера, а у бэкенд-разработчика и тестировщика не было доступа к Figma Dev Mode и соответствующему MCP. У нас были MCP от банковской дизайн-системы и «костыли» для Figma, но они работали хуже, чем хотелось бы. Поэтому иногда было проще скинуть агенту скриншот того, как должно выглядеть финальное решение.
В итоге всё уперлось в контекст. То, как мы пишем код и верифицируем результат, очень важно. Без контекста даже самая мощная нейросеть выдавала плохой результат.
Уровень AI-зрелости команды
Мне нравится понятие ИИ-зрелости команды. Оно отражает, какие подходы к работе с ИИ используют инженеры.
Нулевой уровень — команда вообще не использует ИИ.
Первый — пользуется преимущественно чатом с LLM.
Второй — использует агентов локально.
Третий — использует агентов на сервере для некоторых этапов.
Четвёртый — переходит к практически автономной работе с оркестрацией агентов.
Наши эксперименты проходили на втором уровне, когда инженер работает с агентом (Codex/OpenCode) локально на своём компьютере. Мы осознанно не стремились сразу перейти на следующий уровень, когда часть задач уже решают агенты на сервере. Это связано с тем, что уже на втором уровне резко возрастает потребность в качественном контексте и командном harness. Я уверен, что пока качественно не нарастишь этот показатель, нельзя двигаться на следующий уровень.
Хотя, конечно, наша цель — в ближайшее время дойти до четвёртого уровня.
Трансформация всей команды в tiny teams
После пилота мы приняли решение трансформировать всю команду в tiny teams.
У нас есть своя специфика: сложные аналитические задачи, в которых много методологии и исследовательской работы, а цена ошибки высока. Передать такие задачи продакт-инженерам пока сложно. Поэтому для процесса discovery мы создали discovery hub. В нём эксперты описывают цели, аудиторию и методологию решения задач, проводят исследования и готовят макеты. Продакт-инженер продолжает анализ, но уже с технической точки зрения: определяет, где и какие изменения нужно сделать, как их тестировать и мониторить. Он же описывает реализацию, готовит документацию и далее переходит к разработке, тестированию и выкладке в продакшен.
В итоге у нас получился такой состав команды:
Это четыре tiny teams и discovery hub, куда вошли продакт-оунер, дизайнер и бизнес-аналитик. Причём в каждой tiny team не хватало какой-то экспертизы. Где-то нет бэкенд-разработчика, где-то фронтенд-разработчика, а где-то QA-инженера. Аналитика нет ни в одной tiny team, только в discovery hub. Мы сделали это намеренно, чтобы была мотивация обращаться к ИИ-инструментам. При этом задачи у tiny teams остаются кросс-функциональными.
Мы условно разделили все наши задачи на три типа:
Мелкие задачи («зелёные»). Их может сделать любой продуктовый инженер в команде с помощью ИИ. Поэтому такие задачи мы отдаём на E2E-реализацию автономным агентам.
Крупные задачи («жёлтые»). Их можно решить внутри tiny team. Такие задачи хорошо подходят для проверки harness в хабах. Пока мы их делаем локально в режиме AI-assisted, но в будущем планируем отдавать агентам для автономной реализации.
Экспертные задачи («красные»). Нужны глубокие глубокие знания в конкретной области. Сейчас такие задачи мы решаем только в команде с глубокой экспертизой или объединением двух tiny teams.
Как мы развиваем командный harness
При работе с ИИ нам было важно переиспользовать инструменты, которые уже есть в команде, домене и банке. Например скиллы и MCP, а не пытаться сделать «велосипед». Поэтому основное время мы решили инвестировать в командный harness. Это специфичные для нашей команды и доменной области правила, навыки и контекст.
Одна из ключевых идей — непрерывный цикл улучшения. Он выглядит так:
Задача выполняется с помощью ИИ.
Мы разбираем, где были сложности? Где ИИ ошибся?
Развиваем harness: добавляем навыки, улучшаем контекст, дорабатываем инструменты.
Запускаем снова.
Мы сделали отдельные хабы по экспертизам: бэкенду, фронтенду, QA, SA. Ребята в хабах системно развивают harness. Собирают обратную связь от всех tiny teams по своему направлению, разбирают прошлые запуски и находят, где и почему ошибается ИИ. Выявляют пробелы в навыках, инструментах и контексте, проверяют улучшения и транслируют лучшие решения на всю команду. Они превращают опыт реальных запусков в системные улучшения, которые делают серверных ИИ-агентов самостоятельнее.
От локальных агентов к server-side
Вначале мы осознанно всё делали с локальными агентами. Их работу удобно корректировать, просто отправляя новые сообщения. Но главное, я считаю, что это важный этап, который должна пройти команда. Как раз чтобы набраться опыта и наработать командный harness для стабильного и качественного выполнения задач.
Но с локальными агентами есть одна проблема. Они работают, пока открыт ноутбук разработчика, и начинают действовать только по его команде. А мне хочется, чтобы агент разработки или даже целая система агентов стали ещё одним инженером в команде. Чтобы можно было просто назначить задачу в таск-трекере и получить готовый MR на ревью, а весь анализ, разработку и тестирование агенты выполняли бы самостоятельно. В перспективе ещё и сами определяли, какие задачи делать.
Сейчас мы экспериментируем с такой системой и уже отдаём ей многие «зелёные» задачи. Начинали с обновления зависимостей по результатам проверок безопасности. Наши сервисы регулярно проходят AppSec-сканирование. Если обнаруживается уязвимая версия библиотеки или образа, агент сам создаёт задачу в таск-трекере, вносит необходимые изменения и готовит MR. В итоге утром мы получаем несколько MR на ревью.
Теперь мы передаём агентам и небольшие бизнесовые задачи. Главное, чтобы было понятно, что, как и где нужно сделать. Постепенно развиваем возможности агентов, чтобы они справлялись со всё более сложными задачами.
По сути, меняется сама роль инженера. Если раньше он самостоятельно выполнял задачи по доставке ценности пользователям, то теперь создаёт систему, которая их выполняет.
Итоги трансформации
За полгода мы прошли путь от «все используют ИИ для написания кода» до трансформации в tiny teams. Сейчас у нас такие результаты:
90% кода пишется LLM.
Более 70% бизнесовых задач выполнены в режиме AI-assisted.
Более 20% задач решаются E2E-агентами на сервере.
При этом вначале количество выполненных задач у нас упало. Мы были к этому готовы, потому что на трансформацию и построение harness требуется время. Но этим проблемы не ограничились:
Растёт нагрузка на людей. Вместе с темпом работы увеличивается когнитивная нагрузка, повышается риск выгорания.
Без знаний в смежных областях не обойтись. Инженер должен понимать достаточно много в каждой области, чтобы ставить правильные задачи ИИ и проверять результат. Это требует времени и терпения.
Код пишется быстрее — ревью становится узким местом. Если не перенастроить процесс ревью (оценивать архитектуру, а не синтаксис), то выигрыш от ИИ съедается временем на проверку.
Реализация ускоряется, но анализ и планирование остаются на человеке. Инженер должен думать шире, глубже, принимать больше решений.
Наши рекомендации
Если вы тоже хотите усилить и трансформировать команду, вот что мы бы посоветовали:
Начните с понятной задачи. Выберите повторяемый сценарий с ясными критериями готовности.
Используйте готовых кодинг-агентов. Не начинайте с разработки собственного агента.
Сначала добейтесь результата локально. Отладьте AI-assisted сценарий и только потом переходите к server-side.
Адаптируйте документацию. Структурируйте её так, чтобы её одинаково понимали люди и агенты.
Детерминированное — в скрипты. Если задачу можно выполнить по чётким правилам, пусть скилл вызывает нужный скрипт.
Развивайте harness как продукт. Анализируйте запуски и непрерывно улучшайте контекст, скиллы и инструменты. Не забывайте про eval-метрики, чтобы понимать, улучшаете вы своё решение или нет. Развитие harness — это ваш новый технический долг.
Мы не достигли идеала и не претендуем на универсальную формулу. Но мы получили конкретный опыт: что работает, что нет, где есть проблемы и куда двигаться дальше.
Наша цель — быстрее доставлять результат, сохраняя качество. Tiny team должна уменьшать время получения обратной связи, сохраняя качество, устойчивость и ясную ответственность.
Комментарии 0