Код писать стало быстрее, а продукт - нет
За последний год писать код действительно стало быстрее.
AI‑ассистенты помогают разработчикам, генерируют функции, пишут тесты и иногда собирают почти готовые фичи.
Но есть странный эффект: скорость написания кода выросла, а скорость развития продукта — почти нет.
Эта история — о том, почему так происходит, если смотреть на разработку глазами продакт‑менеджера.
Дисклеймер: история вымышленная. Все совпадения случайны. Хотя местами — подозрительно точны.
Встречайте Сашу
Саша — обычный продакт-менеджер B2B SaaS-продукта.
Это означает примерно следующее: много стейкхолдеров хотят чего-то очень важного, разработка устала, backlog от Луны и обратно, а руководство искренне верит, что рост х3 — это консервативный сценарий.
Где-то посередине этого всего Саша пытается удержать продукт хотя бы в состоянии управляемого полёта.
Конкуренты тем временем бодро выпускают новые стартапы. Иногда кажется, что они подмешивают в свой смузи что-то запрещенное — иначе объяснить их скорость сложно.
Типичная пятница
В пятницу вечером фаундер собирает всю компанию. Обещают пиццу, пиво и «короткую презентацию». Все приходят добровольно. Почти.
CTO показывает демо AI-агентов. Берётся смесь product requirements и system design, нажимается кнопка — и через несколько минут появляется код и тестовый стенд, где новые кнопки уже нажимаются. Выглядит впечатляюще. И главное — это не YouTube-демо, а вроде как настоящий продукт.
После него выходит фаундер и объясняет, что генеративный AI меняет индустрию, стоимость компаний растёт быстрее инфляции, а значит медлить нельзя. Поэтому куплена годовая подписка на платформу с AI-агентами, и с понедельника их нужно загрузить задачами — деньги уже уплачены.
А теперь пицца.
Саша берёт пару кусков пепперони, пиво и уходит за свой стол. Есть о чем подумать. Если всё правда, получается, что теперь можно отправить в разработку почти любое количество задач — и они будут реализованы за день. Звучит подозрительно хорошо для того, чтобы быть правдой. Обычно, в такие моменты и начинается самое интересное.
Какое масштабирование разработки не работает?
Анекдот про 500 программистов
Есть старый анекдот: человеко-год разработки в IBM — это 500 индийских программистов, которые поработали до обеда.
Смешно ровно до тех пор, пока не узнаёшь продолжение. В начале 2000-х индустрия действительно пыталась ускорить разработку за счёт резкого увеличения числа дешевых исполнителей. Казалось логичным: больше людей — быстрее результат. Но что-то пошло не так.
Первая проблема — спецификация. Невозможно заранее настолько подробно описать сложный продукт, чтобы сотни нескоординированных исполнителей могли параллельно реализовывать части системы без конфликтов. Компании пытались — вкладывались в UML, покупали инструменты моделирования, строили процессы вокруг идеальной документации. Не помогло.
Вторая проблема — координация. Чем больше исполнителей, тем быстрее растут издержки на согласование изменений. Иногда быстрее, чем линейно. Все же пробовали ускорить проект, добавляя разработчиков в последнюю неделю перед сдачей заказчику?
В итоге индустрия пришла к небольшим командам, инкрементальной разработке и всем тем процессам, которые сегодня кажутся очевидными.
И вот теперь вместо сотен программистов появляются сотни AI-агентов. И на этот раз всё должно сработать.
👉 Но главный вопрос остаётся тем же: ускоряет ли увеличение числа исполнителей развитие продукта — или только написание кода?
Видео с котиками и реальность
Все видели вдохновляющие ролики: AI пишет бота, сервис или интеграцию буквально по паре инструкций. Демо CTO выглядело примерно так же — код сразу уехал на тестовый сервер и заработал.
Проблема в том, что в реальной разработке написание кода — только начало пути. Дальше идут code review, тесты, сборки, релизы, проверки совместимости, инфраструктура, мониторинг. И отменять эти этапы никто не собирается - эти процессы позволяют делать тысячи локальных изменений миллионах строк кода. Кстати, AI-адоптеры не обещают, что кода станет меньше.
По мере роста продукта такие процессы возникают неизбежно даже в самых бодрых стартапах — не только потому что инженеры любят усложнять жизнь, а компании - нанимать унылых engineering managers. Просто иначе система перестаёт быть управляемой.
Теперь надо понять, как эти процессы изменятся.
Где узкое место процессов разработки?
Мифическая производительность разработки
В компании Саши, как и почти в любой продуктовой команде, существует показатель «производительности разработки». Видимо, эта производительность и ��олжна увеличиться за счет AI-агентов. Тут бы и пригодились наконец те самые story points за спринт, чтобы отслеживать улучшения.
Типичный спринт выглядит примерно так:
несколько средних изменений,
десятки мелких задач,
бесконечный поток небольших багфиксов и улучшений.
И почти каждый спринт что-нибудь идёт не так: ломается инфраструктура, всплывает неожиданный баг, падает внешний сервис, или просто реальность вмешивается в планы. После чего проходит очередной post-mortem митинг, а про story points все забывают.
Где на самом деле бутылочное горлышко?
У Саши был показательный опыт. Иногда, разбирая задачи, он понимал, что изменение — буквально на несколько строк кода. Тогда он открывал репозиторий и сам делал merge request. Фактически, Саша выступал в роли AI-агента: требования и код появлялись одновременно.
Казалось, что это должно уменьшить time-to-market для этих изменений, но нет. Потому что фича всё равно проходила code review, тестирование, сборки, выкладку и проверки.
Базовая теория очередей подсказывает простую вещь: ускорение этапов до бутылочного горлышка почти не влияет на скорость системы в целом.
И тогда появляется неприятная мысль: возможно, узкое место разработки давно находится не скорости написания кода? Даже без точной статистики видно, что основная задержка возникает на этапе валидации изменений и релизного процесса, а в вовсе не в написании кода.
AI ускоряет программирование, но если программирование — не самое медленное место, тогда и общий процесс почти не меняется.
А какая скорость разработки нужна?
Крамольная мысль
В какой-то момент у Саши появляется ещё более странное подозрение. А что, если продукту вообще не нужна значительно большая скорость разработки?
У пользователей есть ограниченная способность адаптироваться к изменениям. Представьте любой знакомый сервис — например, мессенджер, название которого все еще можно произносить вслух. Разработчики регулярно выпускают 5–10 фичей в две недели и записывают про них stories, которые никто не смотрит. Сколько из этих функций начинают использоваться сразу? И сколько пользователей вообще замечают их появление?
Если вместо нескольких обновлений выпускать по 20-30 каждую неделю, продукт не обязательно станет лучше. Значительная часть работы просто не будет замечена. Для зрелых продуктов это особенно характерно: скорость поставки фич ограничена не только разработкой, но и способностью рынка их переварить.
Где AI действительно может помочь
Конечно, существуют продукты, растущие за счёт количества проведенных продуктовых экспериментов. Там увеличение скорости разработки кажется полезным.
Но и у экспериментов есть пределы:
сколько экспериментов команда способна одновременно анализировать;
сколько гипотез действительно дают результат и как изменится эта доля, если будет соблазн легко проверять все подряд без отбора гипотез;
сколько изменений можно безопасно внедрять одновременно.
И снова оказывается, что ограничение находится не в написании кода.
👉 Промежуточный вывод
Наверное, AI радикально снижает стоимость создания изменений. Но стоимость понимания, проверки и интеграции этих изменений почти не уменьшается. А значит, backlog не исчезает — он просто меняет форму.
AI-агенты для бутылочного горлышка
Логично предположить, что вместе с кодогенерацией появятся и AI-агенты для проверки кода: ревью, тесты, анализ архитектуры — всё это наверняка входит в подписку или продаётся отдельно.
Звучит как решение проблемы, если у фаундера еще остались деньги на дополнительных агентов.
AI для code review
Саша видел в интернете ролики, где AI ревьювит код за кожанными мешками. На видео выглядит полезно. Но что именно должен проверять AI, если код уже написал другой AI?
Если агент находит плохой code style — значит проблема в агенте, который писал код.
Если он проверяет соответствие system design — логично ожидать, что и сам design тоже будет генерироваться нейросетью.
Получается система, где AI проверяет AI по правилам, которые тоже написал AI. Теоретически это выглядит красиво. Практически — пока не очень понятно, где в этом процессе возникает реальное улучшение кода и снижение рисков.
Хотя идея заставить разные модели ревьюить код друг друга звучит забавно.
AI и тестирование
С unit-тестами всё выглядит оптимистично.
AI действительно хорошо генерирует тесты на уровне функций и API. Многие рутинные задачи тестирования можно ускорить почти безболезненно. И ручным тестировщикам можно помочь, наверное.
Но Acceptance-тесты — те самые, которые проверяют продукт максимально комплексно, — устроены иначе. Чтобы их написать, нужно понимать, как работает интерфейс, инфраструктура, данные и взаимодействие компонентов. Это уже не просто кодогенерация, а моделирование поведения пользователя. И именно эти тесты самые важные: они защищают сложную систему от случайных поломок.
Генерировать acceptance-тесты AI-агентами уже не так просто, как unit. Но если и этот процесс ускориться, будет ли от него желаемая польза?
Много acceptance-тестов это хорошо или плохо?
Acceptance-тесты медленные и хрупкие. Небольшое изменение интерфейса — тест падает. Тестовый стенд притормозил — тест падает. Полностью зелёные прогоны случаются гораздо реже, чем хотелось бы, мягко говоря. И после каждого прогона кто-то всё равно должен принять решение: релизим или разбираемся, что пошло не так и что надо исправить, код или тесты?
Теперь представим, что AI позволяет создавать почти бесконечное количество таких тестов. Теперь покрывают все пользовательские сценарии, даже самые редкие
Что происходит?
на небольшое изменение в коде требуется тонна изменений в тестах (но их, конечно, напишут AI-агенты)
время прогонов увеличивается;
сложность анализа результатов растёт;
количество ложных срабатываний тоже растёт.
То есть стоимость валидации изменений становится выше. AI ускоряет создание изменений и и одновременно усложняет их проверку. И вот нам снова надо нанять больше QA, которые могут не столько «прокликать приложение», сколько понять сложную систему целиком. Классика.
Бутылочное горлышко не исчезает. Оно расширяется вместе с системой.
👉 Промежуточный вывод
Если AI снижает стоимость написания кода быстрее, чем стоимость его проверки, то общий процесс разработки становится даже менее устойчивым.
Количество изменений растёт быстрее, чем способность системы их безопасно принимать.
Что AI делает с backlog’ом
Как бы ни хотелось спорить, AI-агенты в разработке останутся. И теперь Саше нужно понять главное: что делать с backlog’ом, который никуда не делся.
Большая красная кнопка, которой не существует
Итак, отправить весь backlog AI-агентам одной кнопкой не получится. Слона всё ещё приходится есть по частям.
Даже если код теперь появляется быстрее, процесс отбора задач никуда не исчезает. По-прежнему нужно решать, что делать дальше, а не только как быстро это сделать.
У Саши приоритизация выглядит знакомо любой продуктовой команде: задачи сравниваются по соотношению value (ценности для пользователя) и effort (стоимости разработки). Иногда методично, иногда под давлением самых громких стейкхолдеров.
Value не меняется, наверное — ценность для пользователя остаётся той же. А вот effort внезапно становится подозрительной величиной.
Что происходит с effort?
Есть задачи, где много рутинного кодирования и мало архитектурных решений. Например — очередная интеграция с похожим сервисом или повторяющийся функционал. Такие вещи AI действительно может сильно ускорить. Часть технического долга — рефакторинги, миграции, дополнительные тесты — тоже выглядят хорошими кандидатами на автоматизацию.
Но проблема в том, что команда пока плохо понимает реальные возможности новых инструментов. Старые оценки перестают работать, а новые ещё не появились.
Самый разумный сценарий — прожить несколько спринтов, сознательно беря разные типы задач, и только потом пересматривать оценки backlog’а.
И именно здесь начинает происходить неожиданное.
А что с XS-задачами?
Большая часть backlog’а — это не стратегические инициативы. Это накопившиеся «было бы неплохо»:
маленькие улучшения,
аккуратные правки,
старые продуктовые долги,
идеи, которые жалко удалить.
Раньше они лежали годами, потому что effort был слишком большим относительно ценности. Теперь часть таких задач внезапно получает почти нулевую стоимость разработки и появляется соблазн сделать их все.
Но тут возникает новая проблема. Одна XS-задача почти бесплатна. Десятки XS-задач — скорее всего, нет. Потому что возможны всякие взаимные влияния и накладки. То есть снова нужны процессы - и вот пачка «почти бесплатных» изменений превращается в полноценную M-задачу.
А что с XL-задачами?
С крупными инициативами почти ничего не меняется.
Опыт показывает: невозможно заранее написать идеальное техническое задание на проект длиной в несколько человеко-лет. Даже если документ помогает писать AI.
Такие проекты всё равно приходится двигать шагами: декомпозировать, объяснять частями, проверять промежуточные результаты, корректировать направление.
Попытка «передать всё сразу» работает примерно как ремонт большой квартиры по принципу: отдать дизайнерский рендер, платиновую карту и уехать на год. По возвращении почти гарантированы сюрпризы.
Поэтому базовый принцип остаётся прежним — контрольные точки и постепенное движение.
Где остаётся основная работа?
Как и раньше, развитие продукта двигают средние задачи. Именно они:
достаточно велики, чтобы менять продукт,
достаточно ограничены, чтобы ими можно было управлять.
AI помогает проектировать их быстрее, писать код быстрее и, возможно, оставлять меньше технического долга после релиза. Но сама структура работы команды почти не меняется.
👉 Главный сдвиг
AI не уничтожает backlog. Он делает дешёвыми отдельные изменения — и тем самым увеличивает давление на процессы отбора, проверки и координации.
Backlog перестаёт быть списком задач разработки. Он становится ограничением управляемости продукта.
Что в итоге меняется?
Через полгода CEO, скорее всего, скажет в интервью, что в компании уже 90% кода пишут нейросети. И формально это может оказаться правдой, разработка действительно станет быстрее писать код и больше задач получат шанс быть закрытыми.
А вот скорость развития продукта изменится гораздо меньше. AI ускоряет производство изменений, но продукт развивается со скоростью их осмысления.
Что это означает для продакта
Работа продакта становится не проще, а честнее.
Если код появляется быстрее, главным ограничением становятся:
приоритизация,
ясность решений,
способность команды договориться,
понимание, какие изменения вообще стоит делать.
Backlog перестаёт быть очередью задач в разработку. Он становится фильтром — защитой продукта от лишних изменений.
А программировать продакту по-прежнему не нужно - и на том спасибо!
