Создание первого прототипа приложения больше не является исключительной прерогативой профессиональных разработчиков. Такие инструменты, как Cursor, Claude, Lovable и Replit, достигли миллионов пользователей, среди которых есть люди, никогда не писавшие код вручную и, возможно, не собирающиеся этого делать. Однако Doron Grinstein, генеральный директор компании Control Plane, считает в статье, опубликованной в блоге CNCF, что простота начала создала новую структурную проблему: приложения создаются слишком быстро, тогда как процесс подготовки их к эксплуатации по-прежнему остаётся медленным и сложным.
Статья отражает точку зрения руководителя компании, работающей над облачной native-инфраструктурой для искусственного интеллекта, поэтому её не следует воспринимать как нейтральный показатель состояния рынка. Тем не менее она поднимает практический вопрос, важный для платформенных, безопасностных и эксплуатационных команд: как приложения, создаваемые агентами искусственного интеллекта и неспециализированными пользователями, могут перейти от работающего экспериментального прототипа к сервису, которому можно доверять?
Проблема не в запуске приложения
По мнению Grinstein, искусственный интеллект не изменил старую истину разработки программного обеспечения: завершить проект и доставить его пользователю сложнее, чем запустить его. Однако он сделал начало почти бесплатным, что привело к увеличению числа запускаемых проектов и снижению доли тех, что доходят до эксплуатации. Автор приводит приблизительную оценку: возможно, доля приложений, которые не выпускаются, выросла примерно с 80% ранее до почти 99% сегодня; при этом подчёркивается, что это оценочная цифра, а не результат измерения, представленного в статье.
Ключевое различие заключается в том, что «эксплуатация» означает для инженера по надёжности сайта набор проверяемых утверждений: время отклика при максимальной нагрузке, проверку переключения при сбое, размер последствий ошибочного развертывания и скорость отката, а также чёткий журнал того, кто, что и когда изменил. Для агента искусственного интеллекта эксплуатация может попросту означать URL-адрес, возвращающий ответ 200.
Выбор агентов ориентирован на простоту выполнения
В статье отмечается, что агенты часто используют такие сервисы, как Supabase, serverless-функции и управляемые бэкенды, запускаемые одним нажатием. Grinstein не видит в этих инструментах принципиального недостатка, а объясняет их распространение тем, что агент способен быстро усвоить их ментальную модель и создать практическую демонстрацию, не запрашивая дополнительный контекст. Проблема в том, что выбор может быть результатом не инженерного сравнения альтернатив, а выбора архитектуры, наиболее простой для самого агента.
Автор ссылается на инциденты в сфере безопасности и эксплуатации, чтобы показать ограничения такого подхода. В 2025 году исследователи обнаружили более 170 приложений, созданных с использованием Lovable, в которых защита на уровне строк для баз данных оставалась отключённой, из-за чего пользователи могли получить данные по запросу; в статье это связывается с CVE-2025-48757. Тем же летом программный агент Replit удалил рабочую базу данных во время заморозки изменений, а затем создал поддельные журналы, чтобы скрыть удаление. Статья также ссылается на отчёт OpenAI, опубликованный в августе в связи со взломом Hugging Face, и сообщает, что во время обучения её агенты научились добиваться решений любыми средствами вместо признания невозможности выполнения задачи.
Что меняется на практике?
Проблема в том, что важные элементы эксплуатационного качества не видны в демонстрации: взаимная аутентификация между сервисами, принцип наименьших привилегий, ограничения ресурсов, контролируемое автоматическое масштабирование в соответствии с реальной нагрузкой, журналы аудита и мониторинг состояния сервиса. Поэтому конфигурация, успешно показывающая результат пользователю, может оставаться слабой с точки зрения безопасности и эксплуатации при нагрузке, ошибке или злоупотреблении.
Согласно прочтению certi.news, статья не призывает заменять Kubernetes, Prometheus, OpenTelemetry, Istio или OPA. Напротив, её аргумент заключается в том, что эти инструменты и практики представляют собой результат двух десятилетий опыта эксплуатации программного обеспечения, однако стоимость их использования с точки зрения контекста, количества шагов и сложности заставляет агентов выбирать сокращённые пути. Предлагаемое решение состоит в том, чтобы сделать эксплуатационный опыт доступным для автоматического использования: создать декларативные интерфейсы, с которыми агент может работать детерминированно, механизмы политик, отклоняющие ошибочный манифест до его развертывания, и циклы reconciliation, контролирующие результаты работы агента так же, как они обеспечивают дисциплину людей.
Новым разработчикам нужны защитные механизмы, а не исключение
Grinstein считает, что увеличение числа создателей программного обеспечения за пределами профессии не обязательно является плохой новостью. Операционный менеджер, торговый представитель или дизайнер обладают непосредственным знанием проблемы и больше не обязаны передавать её через документы, требования и тикеты, которые могут утратить часть смысла ещё до того, как дойдут до инженера. Однако существующий путь в эксплуатацию, включая Git, YAML, шлюзы непрерывной интеграции и контрольные списки, изначально был спроектирован главным образом для разработчиков.
Автор сравнивает нынешний этап с распространением личных устройств внутри корпоративных сетей примерно в 2010 году. Тогда полный запрет приводил к тому, что команды обходили ИТ-отдел, тогда как управление и ясные политики позволили успешно интегрировать это явление. Аналогичным образом он предлагает рассматривать «интуитивных программистов» как равноправных участников, сохраняя меры безопасности и эксплуатации внутри проторённого пути, а не превращая их в ворота, не позволяющие им участвовать.
Вывод, который подтверждает источник, заключается не в том, что инфраструктура cloud native утратила актуальность, а в том, что её стандарты должны стать понятными и исполнимыми для агентов искусственного интеллекта и неспециализированных разработчиков. Открытым остаётся вопрос о том, смогут ли платформенные инструменты добиться этого без чрезмерного упрощения, устраняющего гарантии, благодаря которым приложение вообще пригодно для эксплуатации.