Скорость релизов перестала говорить о качестве команды. Теперь её обеспечивает подписка

Десятого августа гендиректор Vercel Гильермо Раух написал в X, что лучшая модель в мире воткнула в его код бессмысленную задержку в 700 миллисекунд, чтобы что-то «устаканилось», а на прямой вопрос созналась, что занималась карго-культом. За двое суток пост собрал 1,29 миллиона просмотров, и главное в нём – короткий список из шести пунктов, два из которых оплачиваются деньгами, причём счёт приходит владельцу продукта.

Список звучит так. Если не читаешь код, который выдала модель, то верно одно из шести: новичок, софт одноразовый, идёт прототипирование, нет пользователей и выручки, набирается долг и риск, задачи простые.

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

Важно, кто это говорит. Vercel зарабатывает ровно на том, о чём предупреждает: продаёт v0, генератор интерфейсов нейросетью, и инструментарий для приложений с ИИ внутри. Человек, чья компания живёт на генерации кода, публично объясняет, в каком месте эта генерация ломается. Такие свидетельства я считаю самыми надёжными, потому что говорить их невыгодно.

Меня в посте зацепил не спор про чтение кода. Зацепило, что список из шести пунктов – это счёт. Четыре строки в нём безобидные, две оплачиваются деньгами: когда нет пользователей и выручки и когда набирается долг с риском. И платит по ним не тот, кто нажимал кнопку генерации.

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

Двадцать восьмого января 2026 года запустилась Moltbook, соцсеть для ИИ-агентов. Основатель Мэтт Шлихт публично написал, что не написал для проекта ни строчки кода: у него было видение архитектуры, а воплотила его модель.

Тридцать первого января исследователи компании Wiz вместе с Джеймсоном О'Райли разобрали клиентский JavaScript и нашли внутри зашитый ключ Supabase с полными правами на чтение и запись. Разграничение доступа на уровне строк настроено не было. Наружу оказались открыты полтора миллиона токенов аутентификации агентов, тридцать пять тысяч почтовых адресов пользователей, ещё почти тридцать тысяч адресов из списка раннего доступа и четыре тысячи приватных сообщений. Управление любым из полутора миллионов агентов мог перехватить кто угодно.

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

Единичным случаем это не назовёшь. Georgia Tech ведёт наблюдение за уязвимостями, которые напрямую атрибутируются ИИ-инструментам, и по данным, которые приводит Cloud Security Alliance, их число выросло с шести в январе 2026 года до тридцати пяти в марте. Реальное количество исследователи оценивают выше в пять-десять раз, просто атрибуцию мало кто ставит.

Самое честное измерение происходящего с кодом делает GitClear. Они смотрят на поведение самого кода вместо опросов: 623 миллиона изменённых строк за период с 2023 по 2026 год. В отчёте за январь 2026-го картина такая.

Дублирование блоков выросло с 40,3 до 73 на миллион изменённых строк – плюс 81 процент и рекорд за всё время наблюдений. Доля перемещённого кода, то есть прямой признак рефакторинга, упала с 21 процента в 2022 году до 3,8 процента в 2026-м. Обновление кода старше года просело с 1,7 до 0,46 процента. Конструкций, которые глушат ошибки вместо их обработки, стало на 47 процентов больше. Переиспользование кода, если мерить его вызовами функций между файлами, снизилось с 343 до 223 на тысячу строк.

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

Опрос Sonar за январь 2026 года на выборке из 1149 разработчиков даёт вторую половину картины. Долю сгенерированного кода в своей работе они оценивают в 42 процента. Восемьдесят восемь процентов сообщили хотя бы об одном негативном влиянии ИИ на технический долг, и самая частая жалоба звучит так: код выглядел правильным, но оказался ненадёжным. Её назвали 53 процента. Тридцать восемь процентов говорят, что проверка машинного кода отнимает больше сил, чем проверка кода коллеги. Всегда просматривают выдачу перед отправкой в репозиторий сорок восемь процентов – меньше половины.

Я сам работаю в Cursor и эти конструкции вижу своими глазами. Модель уверенно предлагает решение, которое выглядит убедительно ровно до того момента, пока не спросишь, зачем здесь эта строка.

Veracode двадцать восьмого июля 2026 года выпустила свежий замер по сотне с лишним моделей. Средний показатель прохождения проверок безопасности – 56 процентов, за год он не сдвинулся. Около 44 процентов задач на генерацию заканчиваются появлением уязвимости, если в запросе прямо не потребовать безопасный код. Синтаксическая корректность при этом близка к ста процентам. Код компилируется почти всегда. Он просто не всегда работает так, как предполагалось.

Здесь и находится, на мой взгляд, главное. Выгода от скорости и издержки от неё достаются разным людям, и измеряются они тоже по-разному.

Компания Harness в мае 2026 года опросила семьсот инженеров и руководителей. Восемьдесят один процент подтвердил, что после внедрения ИИ разработчики стали тратить на проверку кода больше времени, причём у 28 процентов рост превысил тридцать процентов. Около трети рабочего времени уходит на то, что в отчёте названо невидимой работой: проверка машинного вывода, починка последствий, переключение между инструментами. Отдельный замер Lightrun в апреле 2026-го по двумстам руководителям инфраструктурных команд показал, что 43 процента изменений, сгенерированных ИИ, приходится отлаживать вручную уже на боевых серверах – то есть после того, как они прошли все предварительные проверки.

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

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

Я смотрю на это из позиции партнёра фонда, и оптика получается неуютная.

Google DORA в майском отчёте 2026 года собрала финансовую модель для условной компании на пятьсот инженеров. Там есть цифра, мимо которой я пройти не могу: частота неудачных изменений после внедрения ИИ выросла с пяти процентов до шести, а смоделированный убыток от связанных с этим простоев составил 344 тысячи долларов. Сразу оговорюсь, что сама DORA называет расчёт иллюстративным моделированием с высокой неопределённостью и от статуса замера отказывается. Итоговая экономика у них остаётся положительной, окупаемость около восьми месяцев.

Но в том же документе есть куда более важное для инвестора наблюдение. Выигрыш от ИИ на задачах с нуля составляет 35-40 процентов, а на сложном унаследованном коде – часто десять процентов или меньше. Ускорение работает ровно там, где кода ещё нет, и почти перестаёт работать там, где он уже накоплен. Компания, которая быстро набрала объём, движется в сторону, где её же инструмент помогает всё хуже.

Годом раньше DORA сформулировала это ещё жёстче: рост проникновения ИИ связан одновременно с ростом пропускной способности и ростом нестабильности поставки. Инструмент работает усилителем. На команде с дисциплиной это даёт скорость, на команде без неё скорость уходит в накопление хаоса.

Здесь мне вспоминается собственная история, довольно далёкая от разработки. В 2014 году я зашёл ранним инвестором в Dodo Pizza. Никакого события, которое заставило бы меня переоценить долю, годами не происходило: сделок мало, отчётности публичной нет, повода нет. Поэтому я раз в год пересчитывал стоимость сам, по нижней оценке из последних сделок на вторичном рынке. Когда в компании появился байбек, стоимость наконец назвали публично, и мне было с чем сравнить. Смысл всей этой возни был в том, что у актива есть цена, даже когда никто не выставляет по ней счёт. Если не назначить себе ритм переоценки, узнаешь эту цену в момент сделки, и она может оказаться не той, которую держал в голове.

С техническим долгом ровно та же механика. Счёт по нему не приходит ежемесячно. Он всплывает разом – при попытке масштабироваться, при найме людей, которым надо разобраться в чужом решении, или на due diligence, когда покупатель задаёт вопросы, которых не задаёт никто внутри.

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

Дешёвая сборка стоимость не отменила. Она перенесла её со стадии производства на стадию владения, и счёт за это приходит собственнику.

Половина списка Рауха – про случаи, когда читать машинный вывод незачем, и он тут совершенно прав. Одноразовый скрипт, который отработает один раз. Прототип для проверки гипотезы, который умрёт вместе с гипотезой. Внутренняя утилита на трёх человек. Демо для инвестора, которое никогда не увидит боевую нагрузку. Долг там не наступает по простой причине: владения нет, нечем владеть.

Граница проходит по одному признаку – собирается ли кто-то возвращаться к этому коду. Если продукт живёт дольше квартала и у него есть платящие пользователи, стоимость владения появляется автоматически, и дальше вопрос лишь в том, посчитана она или нет.

Отдельно про цифру, которой сейчас удобно махать всем скептикам. В июле 2025 года METR провела эксперимент: шестнадцать опытных разработчиков, 246 задач, результат – с ИИ они работали на 19 процентов медленнее, хотя сами были уверены, что ускорились на двадцать. Цифру растащили на цитаты. Двадцать четвёртого февраля 2026 года METR выпустила обновление, где та же когорта показала ускорение на 18 процентов, а новый набор участников – на четыре. Исследователи прямо назвали данные очень слабым свидетельством и переделывают дизайн эксперимента.

Привожу это, потому что аккуратность в обе стороны здесь важнее красивого тезиса. Утверждение «ИИ замедляет разработчиков» на август 2026 года на METR больше не опирается. Проблема с генерацией живёт дальше по цепочке – в том, что происходит с кодом после того, как он написан.

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

Текущее состояние компания раскрыла честно. Регулярно пользуются 73 процента разработчиков, больше половины нового кода уже создаётся с участием генеративных моделей. А вот в режиме, где модель готовит от трёх четвертей изменения, работают 17,2 процента – хотя это больше чем вдвое превышает показатель предыдущего квартала.

Разрыв между «пользуются» и «передали основную работу» – самая полезная цифра во всём материале. Даже в компании, которая ставит себе амбициозную цель и умеет измерять, глубокая передача идёт медленно. У всех остальных, кто отчитывается формулировкой «мы внедрили ИИ в разработку», за ней обычно стоит примерно то же самое, только без замера.

Значит ли это, что генерировать код нейросетью не надо? Надо. Экономика на стороне генерации, и она никуда не денется. Речь о том, что у скорости есть цена, и её стоит внести в модель заранее, до того как обнаружишь её через год.

Как понять, что долг копится, если сам не разработчик? Смотреть на возвраты. Растёт ли доля времени команды на исправление уже сделанного, увеличивается ли срок между «готово» и «работает стабильно», может ли кто-то в компании объяснить архитектуру целиком за полчаса.

Кто отвечает, если сгенерированный код привёл к утечке? С точки зрения регулятора и клиента – владелец продукта. Подписка на инструмент генерации ответственности не переносит, и подрядчик, сдавший результат работы модели, обычно тоже её не несёт.

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

Правда, что через несколько лет читать код будет незачем? Возможно. Так считает и сам Раух. Но между «когда-нибудь незачем» и «уже сейчас незачем» лежит вся дистанция, на которой компании и теряют деньги.

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

Значит, ближайшие пару лет уйдут на то, чтобы такую строку научиться выписывать. Пока её нет, каждый считает сам – примерно как я годами считал стоимость доли в компании, которая её не публиковала. Способ грубый, но он всё равно точнее, чем не считать вовсе.

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