Кодирование ускорилось в разы, а проекты – нет. Куда пропал выигрыш?

Привет, Хабр! Меня зовут Александр Сахаров, я директор по работе с партнерами компании «Диасофт». Помимо очевидных обязанностей по работе с заказчиками, я отвечаю за то, чтобы мы выпускали решения, готовые к реальной работе у клиентов.

Примерно с марта 2026 года мы перестраиваем разработку вокруг ИИ-агентов. Мы решили выйти за рамки помощи программисту в IDE и пересобрать весь процесс: от первого запроса клиента до запуска готовой системы. Для этого мы разобрали привычный порядок работы на отдельные шаги и передали большую часть из них агентам. Получившуюся цепочку мы называем «конвейером». Про него я уже рассказывал во время дискуссии на тг-канале «Департамент разработки», но здесь разберемся детальнее. 

Небольшой анонс перед началом: в среду, 7 октября, в 18:00 по Москве мы проводим закрытый онлайн-показ AI-driven Digital Q. Это новая версия нашей экосистемы для команд разработки, которая с помощью ИИ ведет проект от бизнес-требований до продакшена. Вот ссылка на регистрацию, а теперь к делу.

Работает это так. Человек загружает в систему исходные материалы: запись встречи с клиентом, старое ТЗ, десяток Excel-файлов, презентацию. Один агент извлекает из них требования. Следующий ищет, чего не хватает, где есть противоречия и что нужно уточнить. Он составляет вопросы для человека, а после получения ответов еще один агент собирает спецификацию по единым правилам.

Дальше работа идет по нескольким направлениям. Агенты проектируют архитектуру, генерируют код на базе наших готовых компонентов, готовят тест-кейсы, автотесты и документацию. Затем – сборка, разные виды тестирования и проверка уязвимостей.

В конвейере множество шагов. У каждого агента – своя задача, а почти на каждом этапе проверяется результат работы предыдущего. Человек в этой схеме сам код не пишет: он отвечает на вопросы агентов и принимает результаты этапов.

Мы подключили к конвейеру несколько десятков агентов. И вот что самое интересное: код мы теперь получаем в разы быстрее. Готовые продукты тоже выпускаем быстрее, но вот выигрыш во времени почему-то скромнее, чем мы ожидали.

Давайте я расскажу, почему ускорение работы с кодом не превращается в такое же ускорение всего производства. 

Арифметика, которую все помнят и почему-то не применяют

Закон Амдала хорошо объясняет эту историю. Да, он сформулирован для параллельных вычислений, и в комментариях мне наверняка об этом напомнят. Но арифметика здесь та же: сколько ни ускоряй отдельный участок, остальные продолжают занимать свое время.

Попробуйте прикинуть это на своем процессе. Возьмите весь путь задачи, от появления потребности до работающего результата, и посчитайте, сколько в нем занимает написание кода. По моим наблюдениям, хорошо если четверть. Остальное время уходит на выяснение требований, согласования, аналитику, подготовку среды, тестирование, исправление дефектов, документацию, приемку и выкладку. Между этими этапами задача еще и стоит в очередях. Для статуса «ждем ответа от заказчика» GPU пока не придумали.

Теперь допустим, что весь цикл занимает 100 часов, из которых 25 уходят на код. Ускоряем кодирование сразу в десять раз. Получаем 2,5 часа вместо 25. Остальные 75 часов никуда не делись, поэтому весь цикл теперь занимает 77,5 часа. Сокращение на 22,5%. Даже если код начнет появляться мгновенно, при неизменной длительности остальных этапов мы сэкономим максимум четверть времени.

Выигрыш полезный. Но после полугода перестройки, счетов за токены и всех приключений команды от десятикратного ускорения обычно ждешь большего.

На встречах меня чаще всего спрашивают именно об этом: на сколько процентов у вас ускорилась разработка. Отвечать одной цифрой я давно перестал, а вместо этого пересказываю Юрия Дручинина, нашего директора по производству, который этот конвейер и построил. У него формулировка всегда одна и та же:

«Ускорение нельзя получить на одном этапе, его можно получить только целиком, когда вся история сшита в единую методологию. Начните генерировать тест-кейсы и автотесты моделью, и вы очень быстро упретесь в качество требований, которые пришли к вам из анализа».

Поэтому вопрос «где ИИ реально ускорил работу, а где создал иллюзию эффективности» я бы уточнил: сколько времени мы убрали из полного цикла и где теперь скапливаются задачи. Отдельный этап вполне можно ускорить. Но чтобы заметно приблизить релиз, придется разбираться со всей цепочкой: что каждый этап получает на входе, что передает дальше и кто проверяет результат.

Хороший пример с тестами. Поручите модели готовить тест-кейсы и автотесты, и довольно быстро выяснится, какого качества требования пришли из аналитики. Если там написано, что система должна работать быстро, модель может придумать проверки и даже выбрать допустимое время отклика. Только заказчик этого значения не согласовывал. Значит, тестировать мы будем догадку модели. Тестов получится много, они могут успешными, но уверенности в том, что система делает то, что нужно, от этого не прибавится.

Создавая код, мы столкнулись с той же проблемой. Вайб-кодинг в формате «сейчас еще немного уточню промпт, и все заработает» для промышленной разработки, на мой взгляд, быстро уперся в потолок. Сгенерировал, посмотрел, дописал уточнение, снова сгенерировал. Потом еще раз, потому что нужное исправлено, зато сломалось соседнее.

На пет-проекте это бывает даже увлекательно. В корпоративной разработке проблема начинается, когда весь процесс держится на одном инженере. Только он знает, что уже объяснял модели, какие ограничения добавлял и почему очередной вариант наконец подошел. Личный навык есть, а понятного и воспроизводимого для команды процесса пока нет.

Потом этот инженер уходит в отпуск, и вместе с ним временно уходит способность получать нужный результат. Bus factor все еще равен единице. Просто теперь у этой единицы есть ИИ-помощник.

Узкое место не исчезло, оно «переехало»

Мой коллега Дмитрий Старов, который отвечает у нас за инструментарий и платформы, объясняет это через входы и выходы, и мне такой взгляд нравится.

Когда разработкой занимается ИИ, самым дорогим этапом становится создание требований: написать спецификацию, проверить ее, верифицировать, состыковать с тем, что уже сделано. Код перестал быть узким местом благодаря вайб-кодингу. Но узкое место не исчезло, оно «переехало» на входы и выходы процессов.

А раз так, вывод неожиданно простой. Чем меньше в разработке отдельных подпроцессов, тем меньше стыков между ними. А чем меньше стыков, тем меньше мест, где все встает. Отсюда мы и пришли к идее, что процесс должен быть одним и сквозным: от формирования замысла до готового проверенного артефакта, а лучше сразу до установленного у клиента.

Вспомните любую компанию до всякого ИИ и вечную ругань между тестировщиком и аналитиком: «У нас плохое покрытие, потому что у нас плохие требования, ты вот эти пограничные случаи не описал». И, как бы, обе стороны правы, а артефакт, из-за которого они спорят, ничей.

Так вот, главное достижение нашего конвейера на сегодня – не генерация кода. Это перемалывание разносортных требований в качественные спецификации. На вход прилетает то, что реально существует в жизни: расшифровка встречи с клиентом, десяток Excel-файлов, PDF, иногда полумаркетинговая презентация, которую клиент когда-то согласовал сам с собой. Все это собирается, обогащается знанием о наших платформах и о том, какие компоненты у нас вообще есть, и на выходе получается спецификация по правилам OpenSpеc. Дальше, на всех остальных этапах, качество растет само, потому что тесты, код и документация вырастают из одного корня, а не из трех разных пониманий задачи.

Если бы меня спросили, где мы сейчас получаем наибольший эффект, я бы назвал именно это. Не кодогенерацию, а скучное перемалывание мусора на входе.

Три вещи, которые оказались важнее модели

Тяжелее всего далась привычка не трогать код руками. Источник истины у нас –  спецификация. Если на выходе получилось плохо, мы не правим то, что получилось, как это делается в вайб-кодинге и в работе с ассистентом в редакторе. Мы правим спецификацию, стираем сгенерированное и запускаем процесс заново. Психологически это больно, руки тянутся поправить две строчки прямо в файле, тем более что это, буквально, несколько секунд работы. Но каждая такая правка означает, что через месяц спецификация и код разъедутся, и вы вернетесь ровно туда, откуда начинали, только с уверенностью, что у вас все под контролем.

Второе открытие расстроило наших любителей сравнивать модели в бенчмарках. Мы перепробовали изрядное количество разных LLM и оказалось, что обвязка ценнее модели. Гейты, поиск и подготовка контекста, валидаторы, политики безопасности, среда исполнения. Модель под всем этим можно поменять, и мир не рухнет. Поменяйте обвязку, и всему конец.

Кстати, про сменяемость. Нас регулярно спрашивают, чем то, что делаем мы, отличается от того, что предлагает Anthropic со своим Claude Code. Отличие есть, и оно не про качество генерации. Под большей частью наших «кубиков» сейчас работает OpenCode, но ничто не мешает вынуть его и поставить туда Claude Code или отечественный аналог, лишь бы оно запускалось из командной строки. Разница в другом. Все эти прекрасные агентские инструменты придуманы для запуска на компьютере инженера, а промышленный процесс обязан «гонять» задачи автономно, без привязки к чьему-то ноутбуку. Мы же не станем гонять сотрудников по этажам с ноутбуком, чтобы принести кому-то что-то на ревью. Поэтому агенты у нас живут в изолированной корпоративной среде и контекст набирают там же, и если у разработчика дома вырубят свет, конвейер этого даже не заметит.

Третий вопрос про то, кто кого проверяет. Когда я рассказываю про нашу схему, меня почти всегда спрашивают: а зачем такие сложности, ведь современные агенты и так научились сами себя перепроверять. Тут я обычно передаю слово Диме Старову, он на этот вопрос отвечает лучше:

«Когда агент сначала разрабатывает, а потом сам же проверяет, у него уже сложились предпочтения на предыдущей стадии работы. А «критик» заходит с чистого листа, возможно, это вообще другой тип агента и другая модель. И контекст он набирает не тот, которым пользовался разработчик, а тот, который нужен, чтобы проверять».

Агент, который проверяет сам себя, это разработчик, который смотрит собственный пулреквест. Формально ревью состоялось.

Раз отдельному агенту доверять нельзя, доверие приходится закладывать в устройство процесса. У каждого шага конвейера стоят два «турникета», на входе и на выходе – входной и выходной гейт. Входной не пускает шаг в работу, пока не убедится, что запускать его сейчас вообще положено и что на входе лежит все необходимое. Скажем, агента проверки кода «турникет» не пропустит, пока не удостоверится, что код написан – и написан именно по этой задаче, а не по соседней. Выходной задает вопрос, который люди себе задают реже всего: а сделал ли я то, о чем меня просили.

Самое интересное начинается, когда ответ отрицательный. Агент не додумывает и не выкручивается, он задает вопрос, и вопрос падает в отдельный файл. У нас это questions.md, наверное, самый честный файл в проекте. Пока там висит хоть одна незакрытая строчка, выходной «турникет» закрыт, а задача уходит к агенту-менеджеру, и уже тот решает, вернуть ее на пару шагов назад за уточнением или звать человека. Человека, кстати, зовут еще в двух случаях: когда кончились токены и когда агенты по пятому кругу переспрашивают друг у друга одно и то же. Второй случай выглядит до боли знакомо и без всякого ИИ.

Но чтобы задать вопрос, надо сначала заметить, что чего-то не хватает, а это гораздо труднее, чем найти ошибку. Ошибка лежит перед тобой и мозолит глаза. Дырка в требованиях выглядит как пустое место, а пустых мест в любом ТЗ – примерно бесконечность. Сама по себе модель их не видит и честно делает свою работу из того, что дали. Видеть получается только там, где накоплены правила: какие бывают типы объектов, как устроена логическая архитектура, что должно быть описано явно, а что можно вывести.

У меня для объяснения этого есть грубая, зато безотказная аналогия. Представьте, что вам дали дом, который надо построить. А в этом доме нет лифта, нет входа в подъезд, отсутствуют крыша и некоторые стены. Ни один подрядчик в здравом уме за такое не возьмется, он потребует спецификацию по недостающим объектам, потому что без них стройка не имеет смысла. Агент с правилами ведет себя точно так же: видит, что чертеж неполон, и останавливается.

Агент не галлюцинирует там, где ему нечего выдумывать

Теперь о том, что в нашей схеме, на мой взгляд, влияет на результат сильнее всего: о готовой платформе под агентами.

Большая часть базовых сервисов корпоративной системы в ней уже есть. Задача «сделай аутентификацию» здесь означает подключение готового механизма, который прошел множество проверок безопасности. То же самое с API Gateway, движком исполнения бизнес-процессов, справочником валют. Все это инженеры «Диасофт» годами разрабатывали, сопровождали и проверяли на клиентских стендах. Агент получает доступ к результатам этой работы.

Поэтому после утверждения архитектуры большинство задач сводится к доработке и настройке конкретных компонентов. Вместе с задачей агент получает контекст организации, описание компонента и его собственные правила. Если нужно что-то изменить в сервисе работы с очередями, агенту заранее задают ограничения этого сервиса. Результат дополнительно проверяет low-code платформа, в которой хранятся контракты и логические схемы.

Свободы у агента при таком подходе действительно немного. Мы сознательно ограничиваем круг решений, которые он может принять самостоятельно. Это не означает, что галлюцинации побеждены: просто у агента меньше возможностей незаметно увести реализацию в сторону.

Создавать новые компоненты он тоже умеет. Но сначала обвязка проверяет, есть ли в этом необходимость. Когда в платформе сотни готовых сервисов, нужная функция часто уже реализована. Остается найти ее, настроить и связать с остальными частями решения. До генерации нового кода дело может вообще не дойти.

У этого подхода есть вполне материальная причина: стоимость. Мы прикинули расходы на сценарий, в котором каждый разработчик запускает полный цикл генерации без переиспользования готовых компонентов. Получилось дорого. Еще один справочник валют в той же системе хорошо обеспечивает ИИ токенами, но плохо объясняет бухгалтерии, почему мы их купили.

Если правила направляют агента к готовому решению, задача может быть сведена к нескольким строкам в центральном конфиге и настройкам смежных компонентов. Объем работы здесь совсем другой: не нужно заново генерировать целый сервис, проверять его и исправлять ошибки. Именно на таких задачах и появляется экономия. Утверждать, что она везде будет одинаковой, я бы не стал: все зависит от того, какая часть решения уже готова.

Этот принцип хорошо отражен на логической схеме демонстрации нашей экосистемы. Сгенерированные объекты на ней выделены цветом, переиспользованные компоненты показаны серым. Обычно на презентациях хочется побольше ярких элементов. Здесь серый цвет радует больше: он показывает, сколько уже сделанной работы удалось использовать в новом проекте.

Точную стоимость по такой картинке не посчитаешь. Готовые компоненты тоже нужно настроить, связать и проверить в составе решения. Но схема помогает увидеть, где потребовалась новая разработка, а где хватило возможностей платформы.

И это существенное условие описанного подхода. За ним стоят 30 лет разработки и сотни готовых сервисов. Если такой базы нет, агентам придется создавать гораздо больше кода с нуля, а команде – его проверять и сопровождать. Одним подключением агентов накопленный опыт не заменишь. Значительная часть нашей экономии возникает потому, что нужную работу уже сделали до них.

Поддерживать надо спецификацию, а не код

Главная претензия к сгенерированному коду касается сопровождения. Когда понадобится исправить ошибку или добавить функцию, людям придется разбираться в решениях, которые принимал агент. Если понять замысел системы можно только по исходникам, обычная доработка рискует превратиться в археологическую экспедицию.

Поэтому в нашем процессе изменения начинаются со спецификации. В ней описано, что система делает, зачем, при каких условиях и с какими ограничениями. Разработчику не нужно восстанавливать требования к поведению кода: они существуют отдельно, и именно по ним строится реализация.

В этом смысле ценность смещается от кода к спецификации. Код можно получить заново. А вот если потерять понимание, как должна работать система, повторная генерация уже не поможет.

При новой задаче действующая спецификация остается исходной точкой. К ней готовится дельта по правилам OpenSpеc что нужно добавить, какое поведение изменить, от чего отказаться. Агент получает оба документа и реализует изменения.

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

По этому описанию можно заново сгенерировать реализацию. При этом два запуска не обязаны выдавать одинаковые файлы. Нам нужно воспроизвести заданное поведение и соблюсти контракты, а соответствие результата требованиям должны подтвердить проверки.

В исправлении ошибок действует то же правило. Можно уточнить спецификацию, откатить неудачный результат и повторить генерацию. Можно подготовить отдельную дельту на исправление и ограничиться нужными изменениями. Полный повторный прогон обходится дороже по токенам, точечная доработка обычно дешевле. Но в обоих случаях исправление начинается с требований. Вручную код в штатном процессе мы не правим.

Кстати, именно поэтому Дмитрий Старов уверен, что если все модели вдруг станут недоступны, ничего страшного не случится:

«Откатиться на стопроцентно ручное программирование очень просто. Более того, легче, чем сейчас. Потому что код выполняет наши стандарты и понятен, он использует только те сервисы, которые ему разрешили использовать. И плюс к нему есть полноценное  описание человеческим языком, чего у нас раньше, чего греха таить, особо и не было. Все было где-то по Confluence разбросано и в головах у лидеров».

Для меня здесь важнее всего замечание про документацию. Ее актуальность легко отодвигается на второй план, когда разработка может продолжаться без нее. Код работает, задачу закрыли, страницу в Confluence поправим после релиза. Потом выясняется, что надежнее спросить у тимлида. Так тимлид постепенно становится единственной актуальной версией документации, причем без резервной копии.

В нашей схеме у спецификации появился постоянный потребитель: агент обращается к ней перед каждой задачей. Он использует описание как инструкцию, поэтому пропуски и противоречия влияют на следующую реализацию. Поддерживать документ приходится уже для того, чтобы продолжать разработку.

Это и меняет положение документации в процессе. Обновление спецификации входит в саму задачу: после принятия изменений они должны попасть в основное описание системы. Отдельное «потом» для этой работы больше не предусмотрено.

Дисциплина, однако, нужна та же, что и раньше. Стоит изменить поведение системы в обход спецификации, и описание начнет расходиться с реализацией. Конвейер может помочь заметить противоречие, но сам по себе порядок не обеспечит.

Особенно показателен ручной хотфикс. Можно убрать ошибку из кода и оставить в спецификации требование, которое к ней привело. При следующей генерации агент вполне может вернуть ошибку на место. Баг снова попадет в код, причем строго по документации.

Что получилось на практике, а что – нет

Дальше – цифры, ради которых такие статьи обычно и открывают. Предупреждаю сразу: о десятикратных ускорениях не будет.

Первая история – про клиента, который собрался строить большую корпоративную систему и как раз выбирал инструментарий. Агентская часть его интересовала, но подкупило другое: понимание, что процентов 70 кода он получит уже написанным и обкатанным за много лет. Выше я говорил об использовании наших готовых программных компонентов.  Дальше он рассудил вполне здраво: у вас же есть агенты, вот наши ТЗ, закиньте им в «топку»  и покажите прототип. ТЗ, скажу мягко, было поверхностным – набор таблиц и общее описание сценариев.

Через три дня прототип был: пять сквозных бизнес-сценариев в несколько экранов каждый и 27 экранных форм. Но интереснее тут не срок, а исполнители. Собирали все это двое, и ни один из них – не разработчик. Работал аналитик и фронтендер из команды внедрения. При этом полдня из трех ушло на то, чтобы платформенная команда передала им агентов и все настроила. В итоге мы получили прототип за 2,5 дня работы. Быстро?

Вторая история нравится мне больше, потому что она про легаси, а легаси у нас любят все. Аналитик сел рядом с клиентом и прошел по действующей системе, вслух проговаривая, что и зачем в ней происходит. Получилось четырехчасовое видео, которое отправилось прямиком в конвейер. Из него собрали спецификацию, а по спецификации сгенерировали бизнес-сценарии уже на нашем стеке, и их снова оказалось два, хотя в прошлый раз столько было экранных форм. Совпадение, но красивое.

Обратите внимание, с чего началась модернизация. Не с чтения кода, не с разбора схемы базы данных, не с раскопок в репозитории, а с того, что живой человек сказал вслух, как система работает. Код на этом этапе никто не открывал вообще.

Есть еще и такая демонстрация, где в экосистему загружают техническое задание на 400 страниц и за день силами двух специалистов получают собранное приложение с документацией по ГОСТ и пройденными тестами. Демо есть демо, я это всегда оговариваю. Но интересна там не скорость, а самый первый шаг: агент, прочитав 400 страниц, выдает не код, а документ с несостыковками и списком уточняющих вопросов. Каждый, кто держал в руках ТЗ такого объема, знает, что целиком его прочитал ровно один человек, и это был не тот, кто его подписывал.

Теперь то, что в презентациях не показывают.

Все перечисленное – это прототипы на low-code, к ним потом будут дописываться компоненты, и это нормальный ход вещей. Трудозатраты никуда не исчезли, они переехали на ревью: люди больше не пишут, они принимают этапы. Работа, надо сказать, изматывающая, потому что читать чужое всегда скучнее, чем писать свое, и к вечеру от нее устаешь сильнее, чем от кода. Требования, впервые попавшие в конвейер, порождают гору вопросов, и отвечать на них приходится живьем. Мы хотим, чтобы даже сложные требования пролетали насквозь без остановок, но сказать, что уже пролетают, пока не можем.

Что все это сделает с инженером?

Тот самый вопрос, который сейчас реально волнует многих разработчиков.

Начну с математики, она отрезвляет. Дмитрий Старов оценивает выигрыш от подобных конвейеров примерно в 30% эффективности, если внедрять их с умом и экономить токены за счет готовых компонентов. Не в десять раз, не в пять, а на треть. Заголовок из такой цифры выходит неважный, зато ее можно защищать перед финансовым директором, не краснея.

Дальше – немного истории, которая объясняет больше, чем любые прогнозы. Дима Старов пришел в «Диасофт» в конце 90-х, когда флагманом компании была банковская система Diasoft 4x4, та самая, которую банки ставили еще с начала десятилетия и эксплуатировали потом годами. Так вот, на всю эту систему приходилось восемь разработчиков, и они справлялись. В самих банках ИТ-отделы тогда состояли человек из трех, и это тоже никого не смущало. Сейчас в каждом нашем продуктовом направлении работают сотни людей, причем так стало задолго до всякого ИИ.

Что же изменилось? Явно не то, что программисты измельчали. Изменилось количество задач: с каждой новой технологией появляются такие, которых раньше не существовало в вообще, и взяться за них немедленно хотят все. Ровно это описывает парадокс Джевонса: когда технология удешевляет ресурс, спрос на него не падает, а растет. Поэтому если сезонный спад спроса на инженеров и случится, он восстановится. Об этом говорит история отрасли, об этом говорят исследования Gartner и BCG и, положа руку на сердце, об этом говорит здравый смысл.

А вот что поменяется наверняка, так это набор навыков. Узкая специализация уже не будет стоить столько, сколько стоит сейчас. Совсем она никуда не денется, потребность в экспертизе тестирования, в DevOps, во фронтенде на React в ближайшие годы не исчезнет, и разговоры об обратном я считаю болтовней. Но для многих инженеров специализация была не просто набором навыков, а частью самоощущения: я такой-то разработчик, значит, на рынке у меня такая «вилка», я работаю в таких компаниях и делаю такие системы. Вот эту конструкцию в голове придется менять, потому что на ней свет клином не сойдется.

Что же изменится? Я сформулирую это так: когда компонентов накоплено столько, что систему надо не писать, а собирать, основным творчеством становится не код, а выбор: что взять из готового, в каком порядке соединить и чего не делать вовсе. Инженерная сторона дела, то есть что у нас есть и как агенты это между собой «сшивают», осваивается за пару месяцев. А понимание рынка, на котором живет и работает продукт, и того, какая из потребностей пользователя важнее, за пару месяцев не освоить никак. Поэтому доменная экспертиза выходит на передний план, причем у инженера, а не только у аналитика.

Организационно это выглядит так. Человека, который ведет задачу через весь конвейер, мы называем продукт-инженером. Команда остается командой, просто собирается из людей с разным опытом: кто-то пришел из тестирования, кто-то – из системного анализа, кто-то – с фронтенда, кто-то – с бэкенда. При этом каждый способен «протолкнуть» задачу целиком, даже если сервис написан не на его родном стеке. Сейчас у нас в командах – по 10–20 человек, целимся сначала в 5–6, потом – в 3–4, при том что каждый ведет одновременно с полдесятка задач. И тут важно не перепутать причину со следствием: если при таком конвейере команда осталась вдесятером, это признак не масштаба задач, а того, что роли не разошлись и люди не добрали компетенций.

И нет, менять всю команду разработки ради этого не требуется. В той истории с прототипом за три дня работали аналитик и фронтендер, обычные люди, которым полдня настраивали агентов. Компетенции продукт-инженера получить придется, у нас на этот счет расписаны четыре блока требований, от понимания OpenSpec до умения снимать метрики. Но это выучивается за недели, а не выращивается годами.

Контраст на ИИ

Если вы сейчас решаете, куда вкладываться, начинать я бы советовал не с выбора модели, а с честного замера. Возьмите путь задачи от появления потребности до работающего результата и посчитайте, какую его долю занимает собственно написание кода. Эта доля и есть ваш потолок, причем не приблизительный, а вполне арифметический: если кодирование у вас занимает четверть цикла, дальше 20 процентов вы не уедете, каким бы прекрасным ни оказался ассистент. Метрика «на сколько ИИ ускорил написание кода» при этом будет бодро расти и радовать глаз, потому что она льстит, отлично смотрится в отчете и не значит примерно ничего.

Дальше я бы смотрел на обвязку, а не на модель. Модели у всех плюс-минус одинаковые и меняются каждые полгода, а вот «турникеты», работа с контекстом, правила, среда исполнения и то, как именно агент задает вопрос вместо того, чтобы додумать, у каждого свои. Именно это отличает конвейер от коллекции удобных ассистентов. Сюда же относится главное правило экономии, ради которого и был весь разговор про переиспользование: не позволяйте агенту писать то, что у вас уже написано. Это одновременно самая дешевая защита от галлюцинаций и единственный известный мне способ сделать всю затею рентабельной.

Последнее – уже не про технологии, а про привычку. Правьте спецификацию, а не результат. Стоит один раз разрешить себе поправить код в обход процесса, и все возвращается к вайб-кодингу, только теперь в промышленных масштабах и с бюджетом.

Я начал этот текст с признания, что код мы получаем в разы быстрее, а продукт выпускаем медленнее. Так вот, поражением я это не считаю. Скорее – это диагноз, который давно следовало поставить. Узкое место никогда и не было в наборе символов, просто раньше оно пряталось за медленным кодированием: на его фоне все остальное выглядело вполне терпимо.

Если вы уже прошли этот путь, сообщите в комментариях всего две цифры. Какую долю цикла у вас занимало кодирование до появления ассистентов и что стало узким местом после. Подозреваю, что у большинства ответ будет одинаковым, и он будет не про код.

А если совсем коротко, то ИИ в разработке ведет себя как контрастное вещество. Сам он ничего не лечит, зато на снимке наконец становится видно все, что мы годами старались не разглядывать.