Почему один человек с AI-агентом обгоняет команду из четырёх
Реализация задач впервые за десятилетие стала не самой дорогой частью цикла. Самой дорогой стала постановка. Разбираем, почему и что это меняет для владельцев продуктов.
Редакция Operon, Команда ·
В большинстве команд разработки узкое горлышко — не код, а перенос намерения в задачу. Мы полтора года смотрим за тем, как реально работают команды разного размера в Operon, и вот что видно раз за разом: около половины задач переоформляются как минимум один раз до момента, когда до них доходят руки. Причина — недостаток контекста в первичной формулировке или желание автора уместить в один тикет три несвязанных действия.
Значительная часть времени команды уходит не на реализацию, а на итерацию понимания того, что именно нужно реализовать. Именно этот кусок работы — постановка, декомпозиция, уточнение — становится узким горлышком, когда исполнитель ускоряется. И именно этот кусок AI-агент не сокращает автоматически. Он помогает только тогда, когда задача поставлена.
Отсюда вывод, который может показаться нелогичным: в паре «человек + AI-агент» скорость определяет человек, а не агент. Задача исполнителя решена стабильно: Claude Sonnet или Opus внутри выделенного контейнера пишет код на уровне устойчивого middle-разработчика. Задача постановщика — нет.
Что должно было случиться, чтобы это стало правдой
Три события за последний год сделали такую конфигурацию возможной.
Первое — зрелость моделей. Claude Sonnet 4.6 и Opus 4.8 закрывают около 80% типовых задач мидла: реализация endpoint, миграция БД, форма с валидацией, скрипт трансформации данных, покрытие тестами, документация модулей, рефакторинг под новую сигнатуру. Оставшиеся 20% — архитектурные развилки, дизайн распределённой системы, дебаг heisenbug'ов на проде — по-прежнему требуют человека.
Второе — Model Context Protocol. Anthropic стандартизировал способ, которым модель ходит в внешние инструменты: доски задач, git, тестраннеры, базы. Это дало возможность подключить Claude к канбану Operon одним конфигом, а не собирать интеграцию месяцами.
Третье — Anthropic начал продавать Claude Max. Подписка с большими токенными пулами позволила нам завернуть один аккаунт в изолированный контейнер и продавать его как часть тарифа — без BYOK, без «принеси свой ключ».
Три сценария из практики
Сценарий первый — фаундер-одиночка на MVP. Есть код, есть первые платящие клиенты, есть очередь функций. Днём — общение с клиентами, продажи, поддержка. Кодить остаётся вечер. С агентом ситуация другая: фаундер ставит задачи голосом или текстом в Telegram, агент реализует их днём, к вечеру остаётся только принять или вернуть на доработку — 10–15 минут в конце дня.
Сценарий второй — команда из 3–5 разработчиков. Половина усилий уходит на планирование, оценки, синки, ретро, объяснения между разработчиками. Замена части этого потока на агентов освобождает половину этого времени под настоящую архитектурную работу.
Сценарий третий — CTO растущего продукта. Раньше решение «расширять команду» приходило с 8–10 человек. Сейчас на этой границе решают иначе: разгрузить существующих разработчиков от рутины через агентов.
Какие навыки становятся ключевыми
Если модель закрывает исполнение, а человек отвечает за постановку — что должен уметь человек?
Первое — отделять «что нужно» от «как сделать». Хорошая постановка описывает результат и критерии приёмки, а не детали реализации.
Второе — уметь декомпозировать. Задача «сделай админку» — это не задача. «Добавь на страницу /admin/orders колонку статуса заказа с фильтром по 4 значениям и экспортом в CSV» — уже да.
Третье — ревьюить быстро. Если приёмка PR занимает 3 дня, весь выигрыш от скорости агента съедается на этом шаге.
Что в итоге
Один человек с AI-агентом обгоняет команду из четырёх не потому, что модель лучше живого разработчика — она пока хуже во всём, что важно. А потому, что лишние люди в команде добавляют больше координационных издержек, чем добавляют полезной работы, когда исполнение перестаёт быть узким горлышком.
Это не про замену людей. Это про то, что оптимальный размер команды сместился.