Если бы ИИ существовал с самого начала: дешевый код не сделал решение о том, что строить, проще

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

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

Это больше не так, и сдвиг произошел быстрее, чем большинство лидеров инженерных команд смогли осмыслить.

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

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

“Нельзя применить ИИ к сломанному процессу”, сказал Пабло Гамба, глава технологий Америки в глобальной программной и ИИ-решениях стартапе intive. “Это как дать рабочему более быструю лопату. Он будет работать быстрее, но только в неправильном направлении.”

Быстрая реализация, старое ограничение

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

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

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

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

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

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

В этой парадигме Гамба считает, что компании должны отслеживать не скорость разработки, а полный цикл от намерения до производства. “Если вы улучшаете скорость разработки, но вашим узлом является QA, вы просто достигли QA быстрее. Затем вы исправляете QA, и узел перемещается в требования”, – сказал он.

Цифры подтверждают его, слишком. Предприятия Fortune 50, использующие ИИ-усиленную разработку, отправляют коммиты в 3-4 раза быстрее, чем их коллеги, согласно исследованию Cloud Security Alliance, но вводят новые проблемы безопасности примерно в десять раз чаще.

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

Получение требований в язык, который ИИ может фактически использовать

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

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

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

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

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

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

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

По словам Гамбы, ИИ-родной не является разрешением пропустить процесс, а требованием спроектировать все с нуля. “Многие организации пытаются применить ИИ к старым процессам. Это не трансформация. ИИ-родные организации начинают с другого вопроса: если бы ИИ существовал с самого начала, как бы мы спроектировали этот процесс сегодня?”

Менеджеры бэклога, кураторы замысла

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

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

Этот редизайн тихо формирует, кто определяет, и что такое работа теперь.

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

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

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

И также стоит помнить: ни одна из этих вещей не делает титулы исчезнуть. Но линии между ними становятся все труднее защищать, а люди, процветающие в этом размытии, – это те, кто действует как кураторы замысла.

Быстрая реализация без ограничений не является победой

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

Цифры здесь даже не близки. Тестирование Veracode весны 2026 года по ведущим моделям показало, что только 55% задач генерации кода произвели безопасный вывод, когда не было предоставлено явного руководства по безопасности, цифра, которая几乎 не изменилась за два года, даже когда функциональная точность значительно увеличилась.

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

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

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

Как выглядит лидерство

Ничто из этого не говорит против разработки, ускоренной ИИ; построение никогда не было быстрее или дешевле, и нет возможности вернуть это в бутылку.

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

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