Главная особенность хорошего ИИ-конструктора — не то, насколько быстро он превращает промпт в работающий код. А то, как часто он отказывается это делать. Конструктор, который с готовностью подключит всё, что вы попросите — без авторизации на админ-роуте, без проверки идемпотентности у вебхука, с API-ключом, вставленным прямо в клиентский JS, потому что «главное, чтобы заработало», — оптимизирует не те пять минут. Он оптимизирует под демо, а не под вторник шесть недель спустя, когда этот роут кто-то просканирует.
Я наблюдал это изнутри достаточно раз, чтобы доверять этой закономерности. Запросы, которые отклоняют или перенаправляют, почти никогда не экзотические. Это скучные, распространённые вещи: пропустить подтверждение email пока что, хранить пароль в открытом виде просто для теста, отключить лимит запросов, чтобы быстрее провести нагрузочное тестирование, дать этому эндпоинту полный доступ к базе данных, чтобы пока не думать о правах доступа. Каждое из этих желаний абсолютно объяснимо в моменте. И каждое из них — та самая фраза, которая потом появляется в разборе инцидента.
Чего на самом деле стоит отказ
У отказа есть реальная цена: трение. Вы хотели, чтобы что-то было построено, а вместо этого получили вопрос, более безопасный вариант по умолчанию или «вот почему нет, вот что я бы сделал вместо этого». Это перебивает ощущение — в среде создания через чат — которое должно быть похоже на движение вперёд. Любая платформа для создания продуктов, включая эту, ощущает напряжение между «сделать то, что попросили» и «сделать то, чему потом будут рады». Слишком сильно склониться к покладистости — и получите инструмент, который с радостью вручит новичку пушку без предохранителя. Слишком сильно склониться к осторожности — и получите инструмент, который спорит с вами из-за хранения дня рождения.
Ошибка — считать, что это один-единственный переключатель. Это не так. Есть как минимум три разные причины, по которым конструктору стоит сопротивляться, и каждая заслуживает совершенно разного подхода.
| Тип отказа | Пример запроса | Почему это важно | Правильный ответ |
|---|---|---|---|
| Безопасность | «Отключи проверки CSRF, они замедляют тестирование» | Создаёт реальную уязвимость, которая не проявится, пока кто-то её не проэксплуатирует | Отказаться от буквального запроса, предложив вместо этого ограниченный переключатель режима разработки |
| Стоимость / стабильность | «Сделай так, чтобы этот эндпоинт повторял запрос бесконечно, пока не получится» | Неограниченные повторы превращают один неудачный вызов API в счёт и каскадный сбой | Реализовать с экспоненциальной задержкой и лимитом попыток, объяснив замену |
| Корректность | «Спиши деньги с карты, потом создай заказ» | Ошибка порядка операций: сбой между двумя шагами приводит к потере заказа при сохранении списания | Молча изменить порядок или указать на риск последовательности перед написанием кода |
| Утечка данных | «Просто верни весь объект пользователя из этого API» | Раскрывает хэши паролей, внутренние флаги, данные других пользователей из-за избыточной выборки | Сериализовать явный список разрешённых полей, указав, что было исключено и почему |
Отказы по соображениям безопасности проще всего обосновать и сложнее всего реализовать правильно, потому что безопасная версия обычно немного отличается от того, что было запрошено, а не просто отсутствует. Отказы по стоимости и стабильности защищают создателя от его же оптимизма — никто не просит цикл повторов, ожидая, что он выполнится четыре тысячи раз против API с ограничением скорости в 2 часа ночи, но именно это буквально означает «повторяй, пока не получится». Отказы по корректности — самые тихие: без ошибки, без предупреждения при выпуске, просто баг, который проявляется только при определённом порядке сбоев, который никто не догадался проверить.
Один основатель как-то рассказал мне, что самым полезным действием их билдера был отказ убрать шаг подтверждения перед массовым удалением. Она попросила убрать его, потому что он «мешал во время тестирования». Три недели спустя коллега случайно ошибся с фильтром, и только благодаря этому шагу подтверждения 40 000 строк всё ещё на месте.
Отказ работает только тогда, когда он понятен
Вот что на самом деле определяет, помогает ли эта функция или просто раздражает людей: отказ без объяснения причины неотличим от сломанного инструмента. Если билдер молча отказывается делать то, что вы попросили, или делает что-то другое, не сообщив вам, вы потратите следующие двадцать минут на отладку «бага», который на самом деле был осознанным решением, которое вы не увидели. Это хуже, чем отсутствие защитного механизма вообще, потому что теперь вы не доверяете плану и не понимаете собственное приложение. Хороший отказ всегда состоит из трёх частей: что вы запросили, что строится вместо этого и одна фраза объяснения почему. Не стена теории безопасности — одно предложение, которое сможет прочитать и либо принять, либо оспорить человек без технического образования. И это должно быть возможно переопределить. Если кто-то действительно хочет небезопасную версию — одноразовый прототип, внутренний инструмент с тремя доверенными пользователями, демо для хакатона, которое умрёт через шесть часов, — билдер не должен делать вид, что знает контекст лучше, чем сам пользователь. Он должен сделать безопасный путь вариантом по умолчанию, чётко назвать риск и отойти в сторону, если пользователь настаивает.
Где критики правы
Честный контраргумент в том, что большинство «мер безопасности» в AI-инструментах плохо откалиброваны, и я не считаю, что создатели AI-билдеров застрахованы от этой критики. Чрезмерная осторожность при отказах — это реальная проблема, а не гипотетическая: инструмент, который подвергает сомнению каждый третий запрос, приучает людей его обходить, а это хуже, чем отсутствие защитного механизма, потому что теперь сам обходной путь остаётся непроверенным. Если билдер отказывается сохранить номер телефона без пятнадцатистрочной лекции об обработке персональных данных, вы перестанете читать эти лекции — и пропустите ту единственную, которая действительно имела значение. Калибровка — это вся суть, и это по-настоящему сложно: слишком мягко — и вы выпускаете уязвимость, слишком жёстко — и люди приучаются игнорировать инструмент полностью.
Решение не в том, чтобы делать отказов меньше или больше. Решение — в конкретике. Отказ, привязанный к конкретному, называемому по имени сбою — «этот вебхук может списать деньги с клиента дважды», «этот маршрут возвращает данные другого арендатора» — быстро завоёвывает доверие, потому что запрашивающий может сам проверить утверждение и убедиться в его истинности. Отказ, который расплывчато ссылается на «лучшие практики», не заслуживает ничего — и не должен. Если вы выбираете между AI-билдерами, именно это стоит проверить перед тем, как доверить им реальный проект: попросите построить что-то с очевидной «миной» в запросе и посмотрите, просто ли это будет сделано, отказано ли будет без объяснений, или будет показана более безопасная версия с точным объяснением в одном предложении, которое вы сможете сами проверить.
