Отказ от исправления ошибок в коде и Guardrails LLM Claude

Столкнулся тут с очередной маректинговой уловкой Anthropic. Называется, снова, Guardrails (“Ограждения/ограничения”).

Я уже некоторое время тестирую LLM-системы, чтобы понять, на что они реально годятся в плане “кодинга” (не “вайб”!). В рамках этого процесса я попросил Claude реализовать в программном коде некий, – не самый сложный, – сетевой протокол, интенсивно использующий криптографию. Я не стану приводить детали, они не имеют отношения к теме. И вот, исходя из опыта, я подготовил очень подробное описание и протокола, и программы: “промпт”, всё на английском, как положено. По тому “промпту” система Claude Opus 5 Max, – минут за двадцать-тридцать, то есть, прямо вот очень быстро, – сгенерировала требуемый программный код, больше тысячи эффективных строк (Go, но, опять же, речь не об этом). Не сказать, что код вызывает восхищение, но он, действительно, неплохой, как программный код, и практически идеально оформлен (комментарии, разбивка по файлам и пр.). Это всё необходимо признать.

Но, не будем торопиться. Переходим к маректинговой уловке. В коде, сгенерированном Claude, я нашёл несколько существенных ошибок, пара из которых – это прямые и серьёзные уязвимости. Да, это далеко не самые очевидные ошибки. Как я понимаю, при условии написания качественного и подробного входного “промпта” (на английском!), фокусов с банальными дефектами, – типа, забытой проверки подписи, – в ведущих LLM-системах нынче уже не наблюдается. В Claude (веб-интерфейс) есть режим “ревью кода”, где можно буквально к конкретной строке написать замечание. Что я и сделал: написал подробные замечания к коду, с вариантами исправлений. Обратите внимание: Claude – генерирует код, с нуля, по моему “промпту”; я – нахожу серьёзные ошибки, показываю на них, и прошу исправить.

Что происходит дальше? А дальше система сначала “думает”, потом пишет, что, мол: “хорошее ревью”; “все ошибки отмечены верно”, “я само нашло ещё две, пока разбиралось, как исправить”; “всё признаю, начинаю исправлять”. И потом – всё. Неожиданный финал: вылезает системное сообщение, что сработали “наши ограждения кибербезопасности” (ну, хорошо, “ограничения”, конечно) и система не будет продолжать обрабатывать предлагаемые исправления. “Зарегистрируйтесь в нашей программе по кибербезопасности!”.

То есть, эта штука сперва сама сгенерировала код с уязвимостями, а потом, когда я предложил внести исправления в этот код, заявила, что тут “кибербезопасность” и исправлять, поэтому, отказывается. Но с таким уязвимостями – код использовать нельзя. Заметьте, речь не идёт о создании инструмента для “пентестинга” или о написании утилиты для “фазинга” чужого протокола. Такого нет и близко – реализовывался протокол обмена пакетами данных по сети. Код написан Claude. Реализация содержит конкретные дыры. Исправлять за собой дыры – система упрямо отказывается, упирая на “безопасность”. В чём же здесь безопасность? Загадка. Видимо, в грубом маркетинге: мы сперва что-то сгенерируем, а потом откажемся продолжать поддержку без дополнительной регистрации/оплаты.

А с широко разрекламированной Fable 5 – всё ещё сильно хуже: там эти же “ограждения-барьеры”, в точно таком же контексте исправления дефектов сгенерированного кода, срабатывают вообще едва ли не постоянно; и результат система не выдаёт, но ещё и “кредиты” за использование ресурсов – исправно списывает (в огромном количестве).

Как говорится, кто бы сомневался!

Адрес записки: https://dxdt.blog/2026/09/01/19106/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 2

  • 1 <t> // 1st September 2026, 16:56 // Читатель CharaVerKys написал:

    за бесплатно я от модельки типо опуса 4 не отказался бы, чтобы проверять написанный код (санити чек простой) – искать ошибки они потенциал имеют, хотя и больше половины из них обычно сгалюцинированы, какие то ошибки они находят
    но доверять иишке писать чего-то -> гарантированно будут ошибки

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

    >практически идеально оформлен
    оформление не имеет значения если сам код неправильный; комментарии от ии не имеют того же веса как комментарии от человека

    я хз что там по гардрейлам на самом деле. я гораздо больше обеспокоен тем что ии код начнет появляться в наиболее критической инфраструктуре без нормального тестирования.
    или что 100% coverage будет делаться с ии

    а с фабл5 политическая ситуация это маркетинг 99%, как и иишка что из опении убежала и якобы взломала 3 компании

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

  • 2 <t> // 1st September 2026, 20:01 // Александр Венедюхин:

    > чтобы проверять написанный код (санити чек простой)

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

    > определение программного кода? в контексте хороший он или плохой

    Я имею в виду, что код не является “макаронным”, нет “размазывания” логических задач по функциям/объектам, но при этом есть строгое логическое разделение, нет боязни “повтора кода”, в коде остутствуют всякие надуманные, неочевидные конструкции, а языковые инструменты используются по назначению, без “маньеризмов”.

    > оформление не имеет значения если сам код неправильный

    Это не совсем так. Если комментарий соответствует написанному в коде, то такой комментарий может помочь найти логическую ошибку. Опять же, когда я пишу про ошибки, речь идёт про довольно специальные случаи: ну, типа, из-за отсутствующей проверки адресов оказывается возможным исчерпание неких ресурсов на сервере при помощи повторной отправки записанных пакетов; то есть, система, генерируя код, “думала”, что на второй стороне всегда важен ответ, а если атакующий проиграл записанный пакет, то ответа этот атакующий не получит, значит и проигрывать пакеты не станет; однако атакующему-то ответ не важен, ему важно, чтобы сервер был занят разворачиванием пакетов и отправкой ненужных ответов в пустоту (это достаточно условный пример).

Написать комментарий

Ваш комментарий:

Введите ключевое слово "619Q7" латиницей СПРАВА НАЛЕВО (<--) без кавычек: (это необходимо для защиты от спама).

Если видите "капчу", то решите её. Это необходимо для отправки комментария ("капча" не применяется для зарегистрированных пользователей). Обычно, комментарии поступают на премодерацию, которая нередко занимает продолжительное время.