Двое — золотая середина
Недавно я встретил подругу, бывшую коллегу из моей команды мечты, со времён WYSIWYG-редактора. Сейчас она работает на другом проекте, тоже с агентами: код руками они не пишут. И она рассказала мне историю. Их было четверо, а потом менеджмент решил нанять ещё троих разработчиков, и их стало семь. И после того как этих троих наняли, сказала она, работа пошла значительно медленнее, чем когда они были вчетвером.
Я спросил, как это выглядит на практике. Больше митингов, и они длиннее. Слишком много коммуникации. Согласования. Лид, который сам апрувит каждый пулреквест и делает это очень медленно, так что каждое изменение ждёт его. Люди наступают друг другу на ноги. И очень много планирования. Кода они пишут не так уж много, сказала она. В основном сидят на митингах и ждут друг друга. Насколько я знаю, там все мучаются, а скорость поставки упала. Ничего хорошего я об этом не слышал.
Это точно совпадает с тем, что вижу я. В прошлом посте я писал, что два разработчика и аналитик сделали примерно полгода работы за полторы недели, и обещал объяснить, почему обычная скрам-команда не получит такой скорости даже с теми же агентами. Это тот самый пост. Из четырёх он самый субъективный: здесь есть прогноз, а прогноз может не сбыться. Но я думаю именно так.
Куда уходило время
Почему я думаю, что скрам в классическом виде больше не работает? Потому что написанием кода мы занимались не больше 30–40% времени. Особенно лиды и сеньоры. Огромное количество времени уходило на то, чтобы передавать информацию между членами команды.
Свой день лида я описал в первом посте: четыре-пять часов митингов подряд, между ними код-ревью и сообщения. Созвоны и согласования занимали до 70% моего времени. Я это не ненавидел — мне нравилось говорить с людьми. Но код был меньшей частью работы, и так было у большинства людей вокруг меня.
И это не только мой опыт. В опросе Atlassian за 2025 год среди 3500 разработчиков половина сказала, что теряет десять и больше часов в неделю на трение, которое не связано с написанием кода, а 63% — что руководители не понимают их проблем.
Теперь посмотрите, что делают агенты. Они берут ту часть, которая и так была меньшей, — написание кода — и делают её почти бесплатной. Всё остальное остаётся: митинги, согласования, передача дел, ожидание. Если код занимает треть времени, то даже бесконечно быстрый код сэкономит только эту треть, не больше. Остальные две трети остаются. В десять раз быстрее работа так не станет, и большие исследования показывают двадцать–тридцать процентов. Я к ним ещё вернусь.
Я не вижу, как можно сделать эти митинги быстрее. Я не вижу, как можно сделать эти церемонии быстрее, если мы туда ещё и агентов приглашаем. Так ничего не получится.
Арифметика людей
За историей подруги стоит простая арифметика, и она не новая. Каждая пара людей в команде — это канал, через который должна пройти информация: что-то согласовать, объяснить, чего-то дождаться. Если людей n, таких пар n(n − 1) / 2. Фред Брукс писал об этом в 1975 году в «Мифическом человеко-месяце»: если добавить людей в опаздывающий проект, он опоздает ещё больше.
Четыре человека превратились в семь: людей прибавилось меньше чем вдвое, а линий между ними — больше чем втрое. Агенты это число никак не меняют. Каждый из семи разработчиков теперь пишет код быстрее, значит, каждый производит больше изменений, о которых остальные шесть должны знать, которые они должны проверить, слить со своими и обсудить на митинге. Чем быстрее пишется код, тем дороже относительно него обходится коммуникация.
В нашей команде всё наоборот. Два человека, одна линия. Всё, что мне нужно согласовать, я согласую с одним человеком. Всё, что ему нужно знать о моей работе, он может прочитать в описании, которое агент написал к моему пулреквесту.
Что измеряют исследования
Когда я написал в прошлом посте, что мы видим тысячу процентов и больше, я поставил рядом цифры из исследований в крупных компаниях: двадцать–тридцать процентов. Здесь они подробнее, потому что, по-моему, они говорят то же самое, что и история подруги.
- Google, 2024: рандомизированный эксперимент на 96 инженерах; с ИИ они решали задачу примерно на 21% быстрее.
- Cui с коллегами, 2025: те же эксперименты, что в прошлом посте: почти пять тысяч разработчиков, на 26% больше закрытых задач. Речь шла об автодополнении кода, инструментах прошлого поколения, а не об агентах.
- METR, 2025: шестнадцать опытных разработчиков открытого кода с ИИ работали на 19% медленнее — и потом считали, что были на 20% быстрее. В повторном исследовании в конце 2025 года картина сдвинулась в сторону ускорения, но METR сам пишет, что данные ненадёжны и ускорение, скорее всего, занижено: разработчики отказывались работать без ИИ, а параллельные агенты ломали учёт времени.
- Bain, 2025: обычные компании получают 10–15%. Написание кода и тестирование — только 25–35% пути от идеи до запуска. Компании, которые перестраивают весь процесс, получают 25–30%.
Цифра Bain — это мои 30–40%, только с другой стороны. Если код — треть работы, то даже бесконечно быстрый код сэкономит вам не больше этой трети. Всё остальное — процесс.
А вот что бывает, когда ускоряют только код. Faros изучил данные более чем десяти тысяч разработчиков: с ИИ вливали на 98% больше пулреквестов — а время ревью выросло на 91%, пулреквесты стали больше на 154%, и на уровне компании значимого эффекта ни на пропускную способность, ни на качество не было. Больше кода пошло в ту же трубу, а труба шире не стала. Это тот самый лид из истории подруги, который сам апрувит каждый пулреквест, только измеренный на десяти тысячах человек.
Больше всего мне нравится фраза из отчёта DORA за 2025 год: “AI doesn’t fix a team; it amplifies what’s already there” («ИИ не чинит команду, он усиливает то, что в ней уже есть»). Команда, которая две трети времени проводит на митингах, получает агентов — и две трети времени проводит на митингах. Команда, которая может просто взять и сделать, получает агентов — и делает в десять раз быстрее.
О своей цифре я тоже хочу сказать честно. Её никто не измерял. Это моя оценка того, сколько старой команде понадобилось бы на ту же работу, делённая на полторы недели. А контролируемых исследований маленьких команд, которые с самого начала работают с агентами, нет; всё, что я о них нашёл, — это заявления инвесторов. Например, Y Combinator в марте 2025 года говорил, что у четверти его зимнего набора 95% кода написал ИИ. Так что последний столбец на графике — не наука. Это то, что я вижу своими глазами, и есть серьёзные причины не слишком ему доверять.
Исследование METR показало, что разработчики переоценивают собственное ускорение: они работали медленнее, а думали, что быстрее. Я тоже разработчик. Ничего из этого кода ещё нет в продакшене: мы до сих пор ждём доступов. Это полторы недели на одном проекте. И это переписывание с легаси на современный стек, а с агентами оно идёт гораздо легче: старое приложение уже говорит нам, какой ответ правильный, и мы сравниваем результат байт в байт. Новые фичи с неясными требованиями так быстро не пойдут. Поэтому семнадцать — это то, что даёт переписывание, а не обещание для любого проекта. Но даже если я ошибся в несколько раз, это всё равно гораздо больше тридцати процентов, и дело тут не в одних агентах.
Мне хотелось ещё одной проверки, поэтому я взял два своих пет-проекта, где git хранит реальные дни, и оценил, сколько времени понадобилось бы одному сеньору, чтобы сделать их руками.
Первый — Telegram-бот для учёта расходов, тот, которым мы дома пользуемся каждый день. Пишешь короткую строку, сумму и слово, и он записывает расход. Он читает сербские и черногорские фискальные чеки по QR-коду, банковские SMS и PDF-выписки, пересчитывает валюты по курсу центробанка на день расхода, ведёт бюджеты, регулярные платежи, долги и общие книги для групповых чатов и рисует графики в Telegram Mini App. С агентами на него ушло 13 рабочих дней примерно за две недели, тремя рывками, с конца сентября до середины октября. Руками, если разложить по фичам и учесть тесты и ADR, которые в нём есть, я оцениваю его в 80–90 рабочих дней, то есть примерно в четыре месяца. Это примерно в шесть–семь раз.
Второй — воксельный движок, только сам движок. С агентами на него ушло девять дней, с 16 по 28 октября. Руками, я думаю, это больше года — и то, только если очень хорошо знать Rust. Это в двадцать пять раз и больше, и это оценка для специалиста; мне самому понадобилось бы ещё больше.
Выглядит странно: бот гораздо проще, а дней на него ушло больше, чем на движок. Но дни тут разные. На бота я каждый раз тратил гораздо меньше целого дня. А движок уже работал с полноценной оркестрацией, так что день работы над ним был совсем другим днём.
Так что мои собственные цифры — это не одно число. Обычный продукт выходит примерно в шесть–семь раз, сложный и специальный — примерно в двадцать пять, а переписывание на работе, с его семнадцатью, лежит между ними. И всё это — в команде из одного-двух человек.
У Фреда Брукса есть и второй текст, который подходит сюда даже лучше «Мифического человеко-месяца». В 1986 году он написал No Silver Bullet («Серебряной пули нет»): “There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity” («Нет ни одного изобретения — ни в технологии, ни в методах управления, — которое само по себе обещало бы в течение десяти лет улучшение хотя бы на порядок в производительности, надёжности или простоте»). Он разделил сложность программ на две части. Случайная идёт от наших инструментов: набор кода, языки, машины. Существенная — в самой задаче: понять, что строить, спецификация, проектирование, договориться обо всём этом.
Агенты — тоже не серебряная пуля. Они убрали большой кусок случайной сложности — написание кода руками. Существенная осталась там же, где была, и в большой команде немалая её часть — это люди, которые договариваются друг с другом. Поэтому скрам-команда с агентами и получает свои тридцать процентов. Там, где я вижу порядок, он пришёл не от одного изобретения. Он пришёл от двух сразу, словами самого Брукса: от технологии — агентов — и от метода управления — команды из двух человек с полной свободой. Ни то, ни другое по отдельности этого бы не дало.
Решения, которые ждут
Больше всего большую команду тормозит не код и даже не митинги. Её тормозят решения.
Было много случаев, когда мы показывали заказчику демо UX-дизайна, ждали решения, дизайн не утверждали, и приходилось переделывать, а потом утверждать заново. Однажды я работал на проекте, где каждое изменение в коде должно было пройти через архитектора заказчика. А однажды он даже попросил прислать ему изменения скриншотом, по почте! Безумие. Вскоре после этого я с проекта ушёл. Я так работать не могу.
В больших бюрократических машинах решение может ждать месяцами. Я видел такие проекты. И мне кажется, люди там просто не знают одной вещи: проще сделать продукт и потом переделать, если что-то пойдёт не так, чем месяцами его согласовывать.
А вот как решения выглядят сейчас.
Решение переписать бэкенд с Java на TypeScript — это час разговора. Решение обновить все устаревшие пакеты и перейти с npm на pnpm я принял сам и только согласовал с коллегой. Изменение было сделано за пару часов и проверено e2e-тестами и всем остальным, так что его было легко внедрить и легко откатить, если бы что-то сломалось. Вот это важно: лёгкость внедрения даёт свободу откатиться, если нужно. И тогда планировать далеко вперёд становится незачем.
Ещё пример. Другой разработчик сделал дашборд с поисковыми фасетами. Заказчику он не понравился. Я переделал его по отзыву за час, от начала до конца, и он уже был на dev-стенде, чтобы заказчик и все остальные могли посмотреть. Раньше такая работа заняла бы минимум две недели: дизайнер рисует, дизайн уходит на утверждение, работу планируют, разбивают на подзадачи, раздают, реализуют, тестируют и в конце концов выкатывают. А теперь — час и никакого трения.
Переделать дашборд по отзыву заказчика
Одно и то же изменение, раньше и сейчас.
- раньше: минимум две недели
- сейчас: около часа
- Раньше Дизайнер рисует изменение
- Дизайн уходит на утверждение
- Работу планируют и разбивают на подзадачи
- Подзадачи раздают
- Реализуют, потом тестируют
- В конце концов выкатывают
- Сейчас Я читаю отзыв и переделываю с агентами, от начала до конца
- Изменение на dev-стенде, заказчик может посмотреть
Когда изменение стоит час, его не нужно утверждать до того, как сделать. Делаешь, показываешь, а если не то — делаешь заново. Утверждение было нужно, чтобы дорогая работа не пропала зря. Работа больше не дорогая, а утверждение осталось, и теперь оно — самая дорогая часть.
Почему наша команда — исключение
Почему у нас это работает? Опять же, потому что команда очень маленькая — всего два разработчика. Оба понимают, что делают. Оба — фулстеки и хорошо понимают и бэкенд, и фронтенд. Мы работаем вместе, мы хотим работать и хотим работать быстро. И у нас полная свобода: мы можем делать всё, что хотим, и все понимают, что делать. Не будь хоть одного из этих условий, мы бы так работать не смогли. Если бы у нас сейчас было восемь человек и скрам, мы бы не сделали и близко того, что делаем.
Откуда свобода? Заказчику, по большому счёту, всё равно, что именно мы делаем, — ему важен работающий продукт. EPAM тоже всё равно. Я бы сказал, что это редкий случай.
Так что по-настоящему работает маленькая, конкретная команда разработчиков, которые знают, что делают, и хотят делать это хорошо. Вот тогда мы действительно можем двигаться в десять раз быстрее — не на 20–30%, а в десять, в сто раз быстрее, чем без агентов. Но это требует совершенно другого подхода к менеджменту и очень высокого доверия к команде. Только так.
Есть вопрос и потруднее. Моя команда мечты, люди, с которыми я любил работать: если бы нам дали сегодняшних агентов, но оставили старый скрам, мы бы до этого дошли? Не думаю. Только если бы такую команду разделили. Мы были слишком большими, со слишком большим оверхедом на коммуникацию.
Двое — золотая середина
Почему двое, а не один? Потому что их обязательно должно быть двое, чтобы они могли друг друга проверять. Несколько раз другой разработчик замечал, что что-то не так. У него другой контекст. Он читает описание или ревью агента и понимает, что что-то не в порядке. Как раз сегодня он поймал, что при некоторых условиях наша страница логина была недоступна пользователям, которые не вошли в систему, — а я об этом не знал. У разработчика, который работает с агентами один, такого проверяющего нет.
Трое — уже много. Двое — как раз золотая середина между одним и тремя. Больше трёх — это вообще безумие, это никогда не нужно.
Формального лида у нас нет. Но на практике решения разделены. Другой разработчик отвечает за решения для заказчика: что мы делаем и как это выглядит для него. Я отвечаю за всё техническое: харнесс, качество, тесты. Поэтому двое для меня — магическое число. Два человека, которые могут проверить друг друга, и каждый отвечает за свою сторону.
Что осталось от лида
Я был лидом пять лет и любил это. Но я думаю, что принимать решения и отвечать за них должен кто-то один, конкретный. Когда решение размазано по нескольким людям, ответственности нет ни на ком. Поэтому лид должен быть хотя бы формально — именно для этих решений и для ответственности. Я думаю, что сейчас это главная функция лида: этот человек отвечает за то, что мы делаем. С него спрос.
Все остальные функции лида — координация и прочее — отходят на второй план, потому что они не очень нужны. Управлять некем: людей двое, остальные — агенты. Важна ответственность — и в нашей команде без формального лида она тоже не размазана: за каждый вид решений отвечает один конкретный человек.
Что осталось от скрама
Что осталось от церемоний? Очень верхнеуровневое планирование. Мы примерно понимаем, какой пласт работы нам нужно сделать: легаси перепишем на новый стек, сделаем то-то и то-то. И мы почти ничего больше не оцениваем, только очень грубо. Сделать можно почти что угодно. Мы всё ещё привыкаем, потому что работа идёт быстрее, чем мы себе представляем. Мы даже сами не очень понимаем, с какой скоростью несёмся вперёд, — гораздо быстрее, чем раньше. Если раньше проблема была в том, что мы недооценивали работу, то теперь мы её переоцениваем.
И так как мы растим этот бонсай — о нём я писал в прошлом посте, — реальная работа видна только тогда, когда мы её начинаем. Поэтому подробным планирование быть и не может: следующий шаг появляется после того, как сделан предыдущий.
Поэтому я думаю, что спринты в этом контексте не особенно нужны. Мы просто делаем работу пока она не будет готова, показываем демо заказчику, а потом проводим ретро. Наше ретро — скорее небольшая вечеринка, где мы просто говорим обо всём, а не формальное ретро. Но ретро — это хорошо, обратная связь — это хорошо. Я люблю ретро. Если у нас были какие-то проблемы, их нужно проговорить друг с другом вслух, чтобы их можно было решить. Поэтому ретро, я думаю, нужно.
Дейлики — наверное, нет. Сообщения по ходу дела и Trello-доска заменяют дейлики достаточно неплохо. Иногда дейлики у нас были, иногда нет. Иногда это был просто виртуальный офис, и меня это вполне устраивает.
Двухнедельный спринт, раньше
Церемонии моих старых скрам-команд.
- До спринта Рефайнмент: эпики разбиваются на фичи и задачи
- День 1 Планирование спринта, оценки в стори-поинтах
- Каждый день Дейлик
- Каждый день Код-ревью, демо тестировщикам, согласования
- Середина спринта Прилетают срочные задачи и ломают план
- День 10 Демо заказчику
- День 10 Ретро
Сейчас: спринтов нет
Что осталось.
- осталось
- заменено
- Начало План верхнего уровня на созвоне, записываем его сразу Грубо, без оценок: «перепишем вот этот пласт»
- Каждый день Trello-доска, сообщения по ходу дела, иногда виртуальный офис Вместо дейлика
- Каждое изменение Ревью агента и один апрув человека От другого разработчика
- Когда готово Демо заказчику
- Потом Ретро — скорее небольшая вечеринка, чем формальная встреча
Узкое место, которое осталось
Какие узкие места остались? Интеграция. Сейчас мы ждём паролей, ждём доступов. Код у нас есть, но задеплоить его мы не можем.
Как это ощущается? Да никак. Мне всё равно. Пока мне есть чем заняться, я доволен. Когда будет нечем, буду сидеть и пить кофе. У меня нет абсолютно никакой причины торопиться или кого-то торопить — в том смысле, что у меня нет тревоги. Дадут через месяц — значит, через месяц, чёрт с ним. Никакого чувства по этому поводу внутри нет.
Об этом стоит сказать, потому что это то же самое, только с другой стороны. Внутри нашей команды все узкие места убраны. Снаружи мир по-прежнему работает со старой скоростью: доступы, тикеты, другие команды. Наша команда из двух человек подключается к большой машине, и на стыке побеждает скорость машины. Даже внутри проекта эти два мира существуют рядом: у заказчика Jira с формальными стори, а у нас своя Trello-доска, которую заказчик не видит.
Бригады
Как такие команды могли бы выглядеть в будущем? Да так же, как наша: два разработчика. Плюс к ним человек, который устраняет препятствия, разговаривает с бизнесом, берёт на себя ответственность — может быть, именно за бизнес-решения. Этот человек может очень сильно помочь ускориться. Код он писать не будет, но поможет разработчикам работать так, чтобы им не нужно было постоянно оглядываться и спрашивать у кого-то, как сделать то или иное. Просто берёшь и делаешь.
У меня для этого есть образ, и она из моей жизни до IT. В первом посте я писал про гипсовую лепнину — о том, как наша бригада часто приходила после других мастеров, которые сделали плохо, и переделывала. Нас в бригаде было трое. Нас знали как профессионалов высокого класса, и работа у нас была всегда. Вся она приходила по сарафанному радио.
Мне кажется, программисты пойдут куда-то туда же. Это будет не безличная компания, вендор, аутсорс, который что-то делает, — ты ему просто отдаёшь задачу и забываешь. Это будет команда с лицами. Команда с лицами, которая рекламирует себя через соцсети, наверное, так: вот мы такие классные ребята, мы делаем вот такую штуку. Суперзвёзды с медалями на шее, которые приходят и делают, как SWAT-команда.
Такого я ещё не видел. Это только мой прогноз. В Твиттере есть звёздные разработчики, но не бригады. Но дело вот в чём: в правильных руках LLM может невероятно ускорить разработку — только в правильных руках. Значит, эти руки должно быть видно.
И такая бригада не остаётся навсегда. Она приходит, что-то настраивает или строит и уходит на другой проект — как бригада на ремонте или на стройке. Я думаю, команд, которые работают вместе годами, больше не будет, как и больших команд.
Кто оседлает волну
Поэтому я думаю, что будущее за маленькими и конкретными командами, и те компании, которые сумеют это будущее оседлать, будут, конечно, на гребне волны. И, к сожалению, я не думаю, что старые компании на это способны. Просто потому, что их бюрократическая структура стала уже настолько жёсткой, что никогда не позволит людям такого уровня свободы.
Что будет с компаниями, которые остались с большими командами? Они либо умрут, либо распадутся на маленькие. С этой бюрократической пирамидой что-то нужно делать. Если она останется в том виде, в котором есть сейчас, такая компания, скорее всего, не выживет.
Про EPAM я тут ничего не скажу: в EPAM всё-таки много очень умных людей, и я думаю, они могут что-то придумать. Но в целом без критических изменений в подходе к работе — автономных команд, минимума менеджмента, минимума рамок, высокого доверия — такая работа невозможна. Вопрос в том, как сделать разработчиков максимально свободными, чтобы они могли заниматься творчеством и, условно, продавать своё творчество, и при этом у них не было тяжёлых кандалов на ногах, которые им сильно мешают.
Можно ли повторить то, что есть у нас, где-то ещё? Я думаю, да, но скорее всего не в большой бюрократической компании, а в каком-нибудь маленьком стартапе. И эти маленькие стартапы будут двигаться с такой скоростью, что у всех остальных будет закладывать уши и рябить в глазах, потому что они будут выдавать что-то невероятное.
И опять-таки, мне кажется, что мне повезло — как и в прошлые разы, когда я приходил в эту профессию. Мне опять повезло с тем, что сейчас происходит вокруг, и я могу поработать с такой скоростью.
Но везение — только одна сторона. У всего, что я здесь написал про маленькие команды, свободу и быструю работу, есть цена, и не только для компаний. Следующий пост, последний, — об этом: чего это стоит мне и чего это может стоить тем, кто только начинает.