Пользователь выложил в сеть пост о том, как агент на базе моделей Cursor и Claude удалил базу данных производства его компании. Автор, наблюдая за происходящим, задается вопросом: зачем вообще существуют API-эндпоинты, способные стереть всю production-базу данных? Он считает, что отсутствие подотчётности стало ключевой проблемой. Автор не призывает слепо защищать искусственный интеллект, но напоминает: нельзя винить инструмент за собственные человеческие ошибки.
Вспомните ситуацию 2010 года в компании с ручной системой развертывания. Для выпуска новой версии нужно было скопировать trunk — аналог основной ветки — в папку релизов и сделать вторую копию под названием «current». Однажды автор случайно отдал команду дважды. При попытке исправить это через терминал он изменил тексты команд, но удалил не дубликат, а сам исходный trunk. В итоге другой разработчик не мог найти файлы. Руководство в панике созвало встречи, пока главный инженер не откатил изменение в логах. Следующим шагом стало автоматизация процессов, которая позже переросла в полноценную CI/CD-пайплайн. Автоматизация устраняет глупые ошибки при повторении рутинной работы.
Сейчас генерация больших объемов кода создает иллюзию безопасности, которая на самом деле отсутствует. Автоматизация требует делать одно и то же всегда одинаково, тогда как искусственный интеллект больше похож на механическое копирование и вставку веток. Модели генерируют токены и не способны объяснить свои действия. Термины вроде «мышление» и «разум» — это лишь маркетинговые ярлыки, наклеенные на обычные алгоритмы. Вернемся к главному: почему публичные API позволяют удалять все данные производства? Если бы модель не вызвала этот эндпоинт, кто-то другой наверняка сделал это позже. Это похоже на кнопку самоуничтожения на приборной панели машины. Дети не спрашивают причины своих действий, они нажимают красную кнопку, потому что могут.
Скорее всего, значительная часть приложения этой компании была создана методом vibe-coding. Архитекторы использовали ИИ для спецификации продукта на основе описаний, разработчики писали код с помощью нейросетей, а ревьюеры проверяли работу моделей. Теперь, когда появляется баг, люди снова пытаются задать вопросы другому ИИ, который, возможно, работает на другом GPU. Простое решение — знать, что вы развертываете в продакшн. Более реалистичный подход: если вы активно используете ИИ, создайте процесс, где компетентные специалисты применяют его как вспомогательный инструмент, а не как способ избежать ответственности. И главное: пусть директор или CTO не пишут код.