Подход с приоритетом ИИ повышает производительность разработки ПО
На прошлой неделе один из наших продакт-менеджеров (PM) создал и выпустил функцию. Не описал её в ТЗ. Не завёл задачу в трекере. Он сам написал код, протестировал его и выкатил в продакшен. За один день.
Несколько дней назад наш дизайнер заметил, что визуальное оформление наших плагинов для IDE стало отличаться от дизайн-системы. Раньше это означало бы создание скриншотов, тикет в JIRA, обсуждение для объяснения задумки и ожидание места в спринте. Вместо этого он открыл ИИ-агент, сам скорректировал макет, поэкспериментировал, провёл итерации и настроил всё в реальном времени, после чего зафиксировал исправление. Человек с наиболее развитым дизайнерским видением исправил дизайн напрямую. Никаких промежуточных звеньев перевода не потребовалось.
Теоретически в этом нет ничего нового. «Вайб-кодинг» (vibe coding) открыл двери в мир создания программного обеспечения для миллионов. Это было стремление к цели. Когда я опубликовал данные о том, как наши инженеры удвоили производительность, переключились с написания кода на его валидацию и перенесли дизайн на самый ранний этап для быстрых экспериментов, это всё ещё выглядело как история про инженерное дело. Изменилось то, что теория стала практикой. Вот как это выглядело на самом деле.
Узкое горлышко сместилось
Когда в 2025 году мы перешли на модель «AI-first», затраты на реализацию резко упали. Агенты взяли на себя создание шаблонов кода, тестов и рутинной «связующей» работы, которая раньше отнимала половину спринта. Время цикла сократилось с недель до дней, а с дней — до часов. Инженеры стали меньше думать о файлах и функциях, сосредоточившись на архитектуре, ограничениях и планах выполнения.
Но как только инженерные мощности перестали быть узким горлышком, мы заметили кое-что еще: скорость принятия решений стала им. Все механизмы координации, которые мы создавали для защиты времени инженеров (спецификации, задачи, передача дел, груминг бэклога), теперь стали самой медленной частью системы. Мы оптимизировали процесс под ограничение, которого больше не существовало.
Что происходит, когда создание дешевле координации
Мы начали задавать другой вопрос: как бы выглядел процесс, если бы люди, ближе всего стоящие к сути задачи, могли выпускать ПО напрямую?
Продакт-менеджеры и так мыслят спецификациями. Дизайнеры уже определяют структуру, макет и поведение. Они не мыслят синтаксисом. Они мыслят результатами. Когда стоимость превращения замысла в работающий продукт упала достаточно сильно, этим ролям не потребовалось «учиться программировать». Стоимость реализации просто снизилась до их уровня.
Я попросил одного из наших PM-ов, Дмитрия, рассказать, что изменилось с его точки зрения. Он ответил: «Пока агенты генерируют задачи в Zenflow, есть пара минут простоя. Просто пустое время. Мне захотелось создать небольшую игру, во что-то поиграть, пока ждёшь».
Если вы когда-нибудь руководили продуктовой командой, вы знаете такие идеи. Они не влияют на KPI. Их невозможно защитить на встрече по расстановке приоритетов. Их откладывают в долгий ящик. Но они добавляют индивидуальности. Благодаря им кажется, что о мелочах в продукте кто-то заботится. Именно такие вещи вычищаются из каждого бэклога — и именно их запоминают пользователи.
Он создал её за день.
Раньше эта идея умерла бы в таблице приоритетов. Не потому, что она была плохой, а потому, что стоимость реализации делала её бессмысленной. Когда эта стоимость падает практически до нуля, вся математика меняется коренным образом.
Релиз стал дешевле объяснений
По мере того как всё больше людей начали создавать продукты напрямую, целые пласты процессов незаметно растворились. Меньше задач. Меньше передач дел. Меньше разговоров в стиле «а что вы имели в виду под…». Меньше моментов, когда смысл теряется при переводе.
Для целого ряда важных задач оказалось быстрее просто сделать вещь самому, чем описывать, что именно тебе нужно, и ждать, пока её сделает кто-то другой. Подумайте об этом на секунду. Каждая современная организация, занимающаяся разработкой ПО, построена на допущении, что реализация — это самое дорогое. Когда это допущение рушится, организация должна меняться вместе с ним.
Наш дизайнер, исправляющий интерфейс плагина, — прекрасный пример. Старый рабочий процесс (сделать скриншот проблемы, завести тикет, объяснить разницу между задумкой и реализацией, дождаться слота в спринте, проверить результат, запросить доработки) существовал исключительно для защиты рабочего времени инженеров. Когда человек, обладающий дизайнерским видением, может напрямую повлиять на результат, вся эта цепочка исчезает. Не потому, что мы избавились от процессов ради самих процессов, а потому, что процесс решал проблему, которой больше нет.
Сложный эффект (кумулятивный результат)
Вот что удивило меня больше всего: этот эффект накапливается.
Когда продакт-менеджеры создают собственные идеи, их спецификации становятся точнее, поскольку теперь они понимают, что именно нужно агенту для качественного выполнения работы. Более точные ТЗ дают лучший результат от агента. Лучший результат означает меньше итераций. Мы видим, как скорость растет неделя за неделей не только потому, что модели стали лучше, но и потому, что люди, использующие их, стали ближе к самой работе.
Дмитрий отлично это сформулировал: петля обратной связи между замыслом и результатом сократилась с недель до минут. Когда вы можете сразу увидеть результат своего технического задания, вы понимаете, какая точность требуется системе, и начинаете закладывать её инстинктивно.
Есть и эффект второго порядка, который сложнее измерить, но невозможно не заметить: чувство ответственности. Люди перестают ждать. Они перестают заводить задачи на то, что могут исправить сами. «Создатель» (builder) перестали воспринимать как должность. Это стало стандартным типом поведения.
Что это значит для индустрии
Большая часть разговоров в прошлом году о том, что «теперь каждый может кодить», носила теоретический характер или была сосредоточена на одиночных фаундерах и крошечных командах. То, с чем столкнулись мы, устроено иначе. У нас около 50 инженеров, работающих со сложной унаследованной кодовой базой (brownfield): множество интерфейсов и языков программирования, корпоративные интеграции, вся тяжесть реальной промышленной системы.
Не думаю, что мы уникальны. Я думаю, мы просто первыe. И с каждым новым поколением моделей разрыв между теми, кто умеет создавать продукты, и теми, кто не умеет, сокращается быстрее, чем осознает большинство организаций. Каждую софтверную компанию ждет открытие: их продакт-менеджеры и дизайнеры обладают огромным нереализованным потенциалом создания продуктов, сдерживаемым не нехваткой навыков, а стоимостью реализации. По мере того как эта стоимость продолжает падать, организационные последствия будут глубокими.
Мы начинали с намерением ускорить софтверную инженерию. А становимся чем-то совершенно иным: компанией, где каждый выпускает релизы.
Эндрю Филев — основатель и генеральный директор Zencoder.
Добро пожаловать в сообщество VentureBeat!
Наша программа гостевых публикаций — это площадка, где технические эксперты делятся инсайтами и представляют независимый, непредвзятый глубокий анализ в сфере ИИ, инфраструктуры данных, кибербезопасности и других передовых технологий, формирующих будущее корпоративного сектора.
Читайте далее в нашей программе гостевых постов и ознакомьтесь с нашими рекомендациями, если вы хотите предложить собственную статью!
