После девяти лет в Т-Банке я ушёл, чтобы ответить на вопрос, который внутри компании не проверить: какую часть настоящей инженерной организации может вытянуть один человек, если всю реализацию берут на себя AI-агенты. Не лабораторный эксперимент — живые продукты с реальными пользователями.

Процесс устроен как в инженерной организации: 15+ функциональных ролей, которые играют агенты — среди них бэкенд, фронтенд, SRE, безопасность, дизайн и QA, — ревью между ними, ~90 зафиксированных архитектурных и продуктовых решений, спецификации, которые начинаются с инвариантов, и definition of done из 14 пунктов. Так я довёл Routinka — PWA для рутин и привычек — от идеи до продакшена в одиночку: архитектура, CI с откатом, реестр решений, runbooks. Следом — Calmel, сервис семейной логистики: процесс тот же, проверяю я уже не его, а готовность платить.

Всё, чему я теперь учу менти и команды в AI-разработке, сначала проверено здесь — на собственном проекте и за собственный счёт.

Инженерия Т-Банка стоит на внутренних платформах — в общекорпоративном реестре их 440, — и к 2025 году одни и те же возможности строились параллельно в разных командах. Их стандартизация стала одним из четырёх стратегических IT-проектов, и я пришёл вести её инженерию: команда из шести человек и цели, у которых каждый ключевой результат с января стоял на нуле.

Я начал с честного замера — реального прогресса было ~5%, — затем перестроил постановку целей целиком: каждый OKR связан через ключевой результат с проектом и задачей, ничего не висит в воздухе, ежемесячные чек-ины, явно закреплённые продуктовые роли. Параллельно собрал реестр дублирующихся возможностей с оценкой каждой в FTE — впервые цена дублирования, порядка 15 FTE, была видна в одном месте — и перенёс ответственность за стандарты с архитектурного комитета, где решения стояли в очереди, внутрь самого проекта.

Через полгода выполнение OKR составило 75% при планке в 70%. Сервис, два года застрявший между двумя командами, доехал до релиза за девять месяцев — включая полный переезд на другой стек; поверх реестра заработал первый в компании внутренний RAG-прототип; маркетплейс реестра вырос до 4000 активных пользователей в месяц.

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

Направление выросло с ~30 до 60 инженеров в шести продуктовых командах и семи доменах, найм и развитие карьеры выстроены с нуля. Три программы прошли параллельно и в срок: миграция клиентов банка-партнёра в наше приложение под жёсткий регуляторный дедлайн (~5000 клиентов, меньше 1% столкнулось с краевыми случаями, ноль критических инцидентов), замена шести инфраструктурных систем — от Oracle до Kafka — по закону о критической инфраструктуре и подготовка ключевых сервисов к нагрузке в 1 млн MAU и 100 тыс. DAU.

Надёжность держалась на 99,9%+ при пиках 3000 RPS два года подряд. За три года из 60 человек никто не ушёл по собственной инициативе и никто не выгорел — при постоянном давлении сроков. Инженеры, с которыми я работал, выросли в тимлидов, один дошёл до Group Lead, один — до архитектора; порядка 30 повышений среди прямых подчинённых и около 60 с учётом непрямых.

Самые трудные победы — те, где не было никаких полномочий: когда собственное приложение банка-партнёра нужно было вывести из эксплуатации, я месяцами разбирался в ситуации с их стороны — мотивации, страхи, прозрачный план для их команды — и закрыл вывод так, что команда сохранилась.

B2B-платформа выросла быстрее, чем её витрина: командам-потребителям негде было посмотреть, что вообще существует, и каждый вопрос превращался в переписку на несколько дней. Я предложил единый портал разработчика, сам зарегистрировал домен и поднял первую версию, а потом обеспечил её ресурсами по-настоящему — половиной времени одной из команд и инженером, найденным через внутреннюю ротацию.

Первые пятнадцать с лишним платформенных продуктов завёл на портал лично и настроил канал поддержки с дежурствами; позже мы подключили к нему AI, чтобы отвечать на повторяющиеся вопросы. Портал вырос до 2400 активных пользователей в месяц и ~40 000 просмотров; канал — до 750 участников, это около 70% IT-сотрудников бизнес-линии; время решения обращений упало с нескольких дней до суток.

Подход перерос бизнес-линию: портал стал прообразом общекорпоративного реестра платформ, который я позже возглавил как Head of Engineering.

Лидом команды из пяти iOS-инженеров я стал через несколько месяцев после прихода — приложение быстро росло, а релизы всё ещё собирались вручную. За шесть лет команда выросла с 5 до 15 инженеров — на пике ~30 в трёх подкомандах — через 100+ интервью и выстроенный найм.

Инженерную практику построили с нуля: Scrum, CI/CD на Fastlane и TeamCity вместо ручных релизов, trunk-based development, фиче-флаги, release train от «как получится» до еженедельного, юнит- и UI-тесты там, где их не было вовсе. Я провёл переезд с монолита на модульный монолит — производительность на инженера выросла примерно вдвое — и возглавил межкомандную работу по ускорению, срезавшую lead time изменений с 12 часов до 6–7.

Релизы выходили раз в две недели, аудитория — 100 000+ пользователей в день; crash-free поднялся с 99,8% до 99,95%. По пути ~200 000 строк легаси на Objective-C переписаны на Swift, а я спроектировал и выложил в open source Highway — фреймворк однонаправленного потока данных для iOS.