Главный вывод: генеративный ИИ действительно снижает предельную стоимость создания очередной порции кода, но пока нет достаточных оснований считать, что столь же быстро исчезают расходы на проверку, исправление и эксплуатацию программ. Лучше подтверждается более узкий тезис: дефицит перемещается от набора кода к формулировке задачи, проверке результата и принятию продуктовых решений.
Именно в этом смысле стоит читать рассуждение Laurie Voss, которое процитировал Simon Willison. Восс предполагает, что после удешевления написания, ревью, исправления и эксплуатации кода от разработки останется выяснение реальных потребностей людей, их точное описание и создание приятного интерфейса. Поскольку эту работу приходится повторять для каждого продукта, она и станет основной профессией — отсюда формула «мы все теперь продуктовые инженеры».
Наблюдения из представленных материалов поддерживают направление этого прогноза. Willison рассказывал, что благодаря большим языковым моделям смог реализовать небольшие проекты, которые технически были ему по силам и раньше, но не оправдывали затраченного времени. Вторичный обзор экспериментов Восса с инструкциями для агентов указывает на рост способности новых моделей удерживать длинные наборы требований, одновременно называя проверку результата новым ограничением. А практика разработки систем с цитатами показывает, что даже удачная модельная функция не отменяет поиск документов, проектирование интерфейса, тестирование и сборку всей системы.
Но переход от этих наблюдений к «бесконечному количеству программ» и почти бесплатной эксплуатации требует гораздо более сильных доказательств.
Удешевляется не программа, а одна операция внутри её жизненного цикла
Фраза «стоимость написания кода рухнула» убедительна, если речь идёт о локальной операции: получить функцию, обработчик API, миграцию, тестовую заготовку или прототип интерфейса. Модель может выполнить такую задачу за минуты и тем самым сделать экономически разумными проекты, на которые разработчик раньше не стал бы тратить вечер или выходные.
Однако код — не законченная единица ценности. Чтобы превратить его в работающий продукт, необходимо как минимум:
- понять, какую проблему следует решать;
- определить поведение системы и пограничные случаи;
- выбрать архитектуру и ограничения;
- проверить функциональность, безопасность и производительность;
- встроить изменения в существующий продукт;
- организовать развёртывание, наблюдаемость и откат;
- поддерживать зависимости и реагировать на инциденты;
- выяснить, помогает ли функция пользователям.
ИИ сокращает время некоторых пунктов, но не автоматически устраняет их. Более того, дешёвая генерация создаёт эффект обратного потока: если вариантов реализации становится больше, растёт объём того, что нужно оценить. Команда может получить пять прототипов вместо одного, однако кому-то всё равно придётся решить, какой из них соответствует задаче и какие риски допустимы.
Поэтому полезнее говорить не о падении стоимости разработки вообще, а о снижении стоимости производства кандидатов на решение. Кандидат может оказаться хорошим кодом, но он ещё не является доказанно правильным изменением продукта.
Свидетельства сходятся на переносе узкого места к проверке
Самое содержательное независимое наблюдение в доступных материалах относится к экспериментам Восса с IFScale — тестом на соблюдение множества инструкций. В пересказе его выступления говорится, что исходный тест проверял модели через составление отчёта с заданным набором точных слов: наличие каждого слова считалось выполнением отдельной инструкции.
По данным этого пересказа, Восс повторил тест для GPT-4.1, Claude Sonnet 4 и Gemini 2.5 Pro и получил кривые, близкие к результатам исходной работы. Затем он применил ту же процедуру к более новым системам. Автор обзора описывает сдвиг от прежнего уровня примерно в 200–300 инструкций к диапазону 2000–5000 и упоминает наборы объёмом до 10 000 слов.
Эти числа следует воспринимать осторожно. Перед нами вторичное описание выступления, а не полный протокол с исходными результатами, настройками моделей и статистическим анализом. Кроме того, включить заданное слово в отчёт значительно проще, чем корректно выполнить тысячи взаимозависимых правил реального проекта. Сам Восс, согласно обзору, рассматривает такой тест как оценку верхней границы: если система теряет произвольные слова, сложные семантические требования будут для неё не легче.
Тем не менее результат важен концептуально. Когда модель способна принять больше инструкций, ограничением становится не только вместимость контекста, но и ответ на вопрос: выполнила ли она каждое требование и не сломала ли что-то ещё?
Именно эту проблему отражает подборка BenchFlow, посвящённая оценке ИИ-систем. Её авторы выделяют материалы, где узкое место переносится от решения задач к их определению и измерению, а анализ ошибок называется одним из наиболее результативных видов работы. Это не единый контролируемый эксперимент, а курируемая библиотека методов и мнений. Но она показывает формирование инженерной практики: команды всё чаще обсуждают не качество отдельного ответа модели, а воспроизводимые проверки, наборы примеров, разбор отказов и блокировки в CI.
Тест на точные слова не измеряет понимание продукта
IFScale удобен тем, что допускает однозначную автоматическую проверку. Слово либо присутствует, либо отсутствует. Продуктовые требования устроены иначе.
Формулировка «сделать регистрацию проще» может означать сокращение числа полей, поддержку входа через внешнего провайдера, более понятные ошибки или изменение всей последовательности знакомства с сервисом. Выполнение такого требования нельзя установить поиском строки. Нужны метрики поведения, интервью, наблюдение за пользователями и решение о допустимых компромиссах.
Есть и второй разрыв между тестом и разработкой. Реальные требования конфликтуют. Усиление безопасности может добавить шаги ко входу. Подробное журналирование полезно при расследовании сбоев, но создаёт риски для конфиденциальности. Мгновенная синхронизация улучшает актуальность данных, одновременно повышая инфраструктурные расходы и сложность обработки ошибок.
Модель способна предложить компромисс, но не обладает собственным мандатом определить, какой интерес важнее. Это организационное решение, зависящее от пользователей, законодательства, бюджета и стратегии компании.
Поэтому рост числа удерживаемых инструкций не отменяет продуктовую инженерию. Он повышает цену неточного технического задания. Чем эффективнее агент реализует требования, тем быстрее команда получит именно то, что сформулировала, — включая ошибочные предпосылки и забытые ограничения.
Citations API показывает, куда прячется инженерная работа
Разбор Simon Willison функции Citations API от Anthropic даёт показательный пример. Цитаты в ответах системы с дополненной генерацией могут снизить риск бездоказательных утверждений: пользователь получает прямые фрагменты исходных документов и может проверить, поддерживают ли они ответ.
При этом Willison подчёркивал, что API решает только трудную, но ограниченную часть задачи. Разработчику по-прежнему нужно реализовать большую часть RAG-конвейера: найти потенциально релевантные документы, передать их модели, обработать ответ и отобразить ссылки или цитаты в понятном виде. До появления встроенного механизма гарантированное копирование цитат требовало сложной настройки запросов и дополнительного кода; после его появления система стала проще, но не превратилась в готовый продукт.
Этот пример хорошо раскладывает новую экономику разработки.
Поставщик модели берёт на себя механизм связывания ответа с фрагментами текста. Команда продукта сохраняет ответственность за полноту корпуса, качество поиска, права доступа, актуальность документов, интерфейс проверки и поведение при отсутствии надёжного источника. Если система не нашла нужный документ или процитировала формально похожий, но нерелевантный фрагмент, наличие красивой ссылки не делает ответ правильным.
Иными словами, автоматизация перемещает границу реализации. Она не отменяет необходимость определить, что считается достаточным доказательством и как пользователь должен заметить неопределённость.
Простой расчёт: почему десятикратное ускорение кода не даёт десятикратного ускорения продукта
Рассмотрим условную функцию, на которую команда раньше тратила 100 единиц времени. Предположим, 30 единиц приходились непосредственно на написание кода, а остальные 70 — на исследование задачи, согласование, тестирование, интеграцию, выпуск и последующее наблюдение.
Если агент ускоряет написание кода в десять раз, соответствующая часть сокращается с 30 до 3 единиц. Общая стоимость становится равной 73 единицам. Итоговое ускорение — примерно в 1,37 раза, а не в десять.
Это не измерение конкретной компании, а иллюстративная модель. Её результат полностью зависит от исходного распределения времени. Для одноразового скрипта кодирование может занимать почти всю работу, и выигрыш окажется огромным. Для изменения платёжной системы основными расходами могут быть аудит, миграция, юридические требования и безопасное развёртывание — тогда генерация кода изменит итоговую стоимость заметно меньше.
Есть и динамический эффект. После удешевления прототипов команда начинает проверять больше вариантов. С экономической точки зрения это не провал автоматизации: за тот же бюджет компания получает больше экспериментов. Но бухгалтерски расходы не обязательно снижаются — они переходят в сравнение вариантов, тесты и продуктовую аналитику.
Поэтому эффективность ИИ следует измерять не количеством сгенерированных строк и даже не временем до первого pull request. Более содержательные показатели — время до подтверждённого пользовательского результата, доля изменений без отката, число дефектов после выпуска и стоимость сопровождения функции.
Product Engineer — не новое название универсального одиночки
Из тезиса Восса легко сделать ошибочный кадровый вывод: раз модель пишет код, разработчик должен в одиночку заменить аналитика, дизайнера, тестировщика и специалиста по эксплуатации. Доступные свидетельства этого не подтверждают.
Скорее меняется профиль инженерной ответственности. Ценным становится специалист, который способен пройти короткий цикл целиком: поговорить с пользователем, сформулировать проверяемую гипотезу, собрать реализацию с помощью инструментов, определить критерии качества и изучить результат после выпуска.
Но глубина специализации никуда не исчезает. Безопасность, распределённые системы, доступность интерфейсов, регулирование и эксплуатация крупных платформ требуют знаний, которые нельзя заменить общим умением ставить задачи агенту. Более дешёвый код даже усиливает потребность в таких экспертах: потенциально опасных изменений становится проще произвести больше.
Отдельное предупреждение даёт позиция Восса о многоагентных системах. В его публикации отмечается, что практические системы часто состоят из центрального координатора и подчинённых исполнителей, а не из действительно автономных децентрализованных агентов. Он ссылается на подход, при котором операции записи остаются однопоточными, а дополнительные агенты предоставляют информацию, но не совершают независимые действия.
Это авторская интерпретация состояния отрасли, а не статистическое доказательство того, что «никто» не создаёт многоагентные системы. Однако инженерный принцип разумен: параллельно получать предложения легче, чем безопасно объединять параллельные изменения. Ответственность за итоговое состояние системы остаётся централизованной.
Что должно измениться в процессе разработки уже сейчас
Командам не нужно ждать полного удешевления эксплуатации, чтобы перестроить работу. Достаточно признать: генерация стала быстрее проверки.
Первое изменение — формулировать требования как проверяемые свойства. Вместо «сделать удобнее» нужен наблюдаемый сценарий: кто выполняет действие, в каком контексте, что считается успехом и какие ошибки недопустимы.
Второе — отделять создание варианта от разрешения на выпуск. Агент может генерировать код, тесты и документацию, но решение о слиянии должно опираться на независимые проверки. Особенно важно не считать тест, созданный той же моделью одновременно с реализацией, полноценным независимым подтверждением.
Третье — сохранять небольшой набор реальных неудач. Курируемые коллекции методов оценки рекомендуют превращать субъективные проверки в воспроизводимые утверждения и регулярно анализировать ошибки. Для конкретного продукта полезнее десяток собственных критических случаев, чем высокий результат модели в абстрактном рейтинге.
Четвёртое — ограничивать область автономного изменения. Агенту можно дать широкие возможности чтения и экспериментов, но операции записи, публикации, удаления данных и изменения прав доступа требуют более строгого контроля.
Пятое — учитывать сопровождение до начала генерации. Если новая функция не имеет владельца, телеметрии, процедуры отката и критерия удаления, низкая цена её создания обманчива.
Какие данные подтвердят или опровергнут прогноз Восса
Сильное подтверждение должно появиться не в демонстрациях генерации, а в продольных данных реальных команд. Потребуются сравнения времени от идеи до стабильного выпуска, частоты инцидентов, расходов на поддержку и доли функций, которыми действительно пользуются. Важно измерять не отдельные удачные проекты, а портфель изменений с учётом неудач и последующей эксплуатации.
Прогноз Восса получит поддержку, если команды с агентами начнут устойчиво выпускать больше полезных функций без роста дефектов и операционных расходов, а основная часть рабочего времени действительно переместится к исследованию потребностей, постановке задач и интерфейсам.
Он будет ослаблен, если дешёвая генерация приведёт к накоплению зависимостей, росту числа инцидентов и постоянной ручной проверке непрозрачных изменений. В таком сценарии код станет многочисленнее, но программное обеспечение — не дешевле.
Практический вывод уже достаточно ясен: преимущество получает не тот, кто быстрее всех производит код, а тот, кто быстрее превращает неопределённую потребность в проверяемое изменение и умеет доказать, что оно работает. Это и есть содержательная версия перехода к продуктовой инженерии — без обещания, что инженерная сложность исчезнет вместе со стоимостью первого черновика.