Обновить

GPT-5.6 лишил стартап всех пользователей и подписчиков, а ИИ признал, что безрассудно совершил катастрофическую ошибку

Время на прочтение1 мин
Охват и читатели25K
Всего голосов 30: ↑25 и ↓5+31
Комментарии153

Комментарии 153

"Я был нетрезв! Я недостоин чести советского офицера!"

НЛО прилетело и опубликовало эту надпись здесь

Я был нетрезв. Моё поведение недостойно советского офицера. Я приношу свои извинения.

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

Сэппуку ждёт.

Кстати, это еще интересный аспект работы ИИ-агента. Человек боится ошибиться, перепроверяет, его накажут, лишат премии, уволят. Негативная мотивация. А ИИ бояться то нечего

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

Проблема в том, что человек через некоторое время нач6ёт механически апрувить всё, что прислал ИИ. Я ниже писал, что нужен второй агент. Потому что второй агент (который всегда с нулевым контекстом) всегда на стрёме в отличие от человека. Человек на апруве - это театр безопасности, а не безопасность. (Но людям не не нравится ^^. Минусують )

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

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

Инженеры не создают абсолютно надёжных систем. Мы снижаем вероятность отказа, а не устраняем его возможность.

Это работает для, собственно, запросов. Но обсуждаемая проблема была вызвана ошибкой в коде.

Да. Это не тот случай.

почему то я за все это время не аппрувлю все автоматически и смотрю что запрашивает агент 🤨

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

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

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

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

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

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

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

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

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

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

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

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

Оператор только использует пресс по инструкции, а системы безопасности проектирует и реализует производитель пресса

Забавно, что на тему "пресс почему-то не боится запороть заготовку" нико не рефлексирует, а вот ИИ почему-то должен чего-то там бояться.

Ну так пресс нам никто в «братья по разуму» и не продвигает?

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

Вот мне больше всего интересно почему модель пустили с такими широкими правами - ночью?

Я уже не говорю что наверное бухгалтерские действия неплохо бы ещё и подтверждать кем нибудь живым...

Потому что в наложке будет отчитываться потом кожаный!

Модель никто ни с какими правами не пускал, модель написала крон-джобу, и ночью работала именно эта джоба.

Судя по тексту на скриншоте, конкретно там случилось вот что.

  1. была некоторая функция, которая искала пользователя, подписку которого требуется отменить;

  2. идентификатор этого пользователя превращался в фильтр средствами TypeORM, в запросе было написано что-то вроде { userId: userId };

  3. модель предположила, что функция с шага 1, если ни одной подписки отменять не требуется, вернёт null, далее в запросе получится { userId: null } и запрос превратится в noop;

  4. вместо этого функция вернула undefined, а запрос { userId: undefined } означает отсутствие фильтрации.

Мораль сей басни:

  1. поведение TypeORM по умолчанию - кидать исключение при встрече с null и undefined, и это не просто так;

  2. надо проверять что вам ИИ по-написал.

Не для того мы ИИ подключали, чтоб ещё проверять за ним, что он написал. "Вкалывают роботы - счастлив человек"

Давайте открою вам тайное знание древних.

Любая программа на любом компьютере исполняется от имени какого-то пользователя. И она ничего не может сделать кроме того что разрешено этому пользователю. Пользователя можно ограничить вообще как угодно. Написать программу которая получит больше прав тоже невозможно.

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

Любой кто запустил недермининованную программу с правом на мутации заслужил свой дроп базы. Он сам проигнорировал отраслевые стандарты которые хорошо работают десятилетиями.

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

Крон-джоба занимается отменой подписок. Вы тут хоть как ей права ограничивайте - но право отменять подписки ей требуется для работы.

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

Все уже давно придумано. Все эти проблемы уже решены.

Не уверен что есть готовые решения, которые разрешают удалять не более N строк из БД в сутки исполняя запрос delete без where, а без этого любые рейтлимиты будут половинчатым решением.

Написать можно. Это вообще несложный код и маленький сервис. Клод справится.

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

Вы вообще читаете комментарии, или только пишете?

Нет, мутации инициировала не ллмка. Соответственно, все защиты от мутаций со стороны ллмки тут никак бы не спасли.

Я читаю статью. «Ллмка запустила». Прямо дословно. Значит у ллмки есть права на мутации. И значит нужны заборы от всего.

Конечно спасли. Если прокся запрещает более 10 отписок за сутки и разрешает только корректные запросы то что бы там ллмка не запускала ничего серьезно сломать она не сможет.

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

Почему вы отвечаете на комментарии не читая их?

«На самом деле» это ваша интерпретация. Она странная.

Важно кто нажал кнопку, не как устроена кнопка. Ограничиваем мы нажимающего, а не кнопку.

ИИ не нажимал кнопку, он её только создал. Кнопка нажалась по расписанию.

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

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

Вот вам псевдокод:

@route("...")
function deleteUserByName(name) {
  // здесь прокся уже проверила что доступ есть, 
  // лимиты не превышены и вообще всё замечательно
  let userId = findUserByName(name);
  deleteUserById(userId);
}

Автор кода думает, что findUserByName возвращает null если пользователя нет, а deleteUserById(null) - это no op. На самом деле findUserByName возвращает undefined и deleteUserById(undefined) дропает базу.

От этого никакая прокся не защищает, единственная защита - не писать такого кода, и следить чтобы ИИ тоже его не написал.

Спорим поставлю? Там делов на пару дней с Клодом. До продакшен реди решения с мониторингами и прочим.

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

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

Когда-нибудь появятся отраслевые решения. Но пока их нет надо самому писать.

Его пишем аккуратно, тщательно ревьюим, обновляем максимально редко и всё такое.

Ну так я сразу и написал же, что ревью таки требуется. А вы спорить начали.

Без ревью ничего путного из затеи с проксёй не выйдет, с этим вы согласны?

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

Это качественная разница.

Нет никакой разницы если в стартапе нет ни одного программиста

Идея интересная

CREATE OR REPLACE FUNCTION forbid_multi_delete()
RETURNS trigger
LANGUAGE plpgsql
AS $$
DECLARE
    cnt bigint;
BEGIN
    SELECT count(*) INTO cnt FROM old_table;
    IF cnt > 1 THEN
        RAISE EXCEPTION 'Запрещено удалять более одной строки за команду (таблица %, попытка удалить %)', 
            TG_TABLE_NAME, cnt
            USING ERRCODE = 'raise_exception';
    END IF;
    RETURN NULL;
END;
$$;

CREATE TRIGGER trg_forbid_multi_delete
BEFORE DELETE ON my_table
REFERENCING OLD TABLE AS old_table
FOR EACH STATEMENT
EXECUTE FUNCTION forbid_multi_delete();

И

CREATE OR REPLACE FUNCTION forbid_truncate()
RETURNS trigger
LANGUAGE plpgsql
AS $$
BEGIN
    RAISE EXCEPTION 'TRUNCATE запрещён для таблицы %', TG_TABLE_NAME;
END;
$$;

CREATE TRIGGER trg_forbid_truncate
BEFORE TRUNCATE ON my_table
FOR EACH STATEMENT
EXECUTE FUNCTION forbid_truncate();

А ещё правильнее сделать soft delete, когда код видит не таблицу, а view, который ... WHERE DELETED_FLAG = FALSE, а удаление просто меняет DELETED_FLAG = TRUE.

EF Core при работе с такой view будет терять все внешние ключи, так что вариант не универсален.

Ну так используйте нормальный фреймворк? У нас с этим никаких проблем нет.

Ну вот автор и использовал “нормальный” TypeORM, теперь у него нет клиентов.

А если серьёзно - это не проблема, на самом деле это фича. Которая, так уж получилось, не вполне совместима с подобными трюками на стороне БД.

Согласен.

Soft delete и запрет юзеру на реальный delete.

А ещё лучше событийный подход

И бекап никто не отменял

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

А запрет на truncate вообще должен стоять по умолчанию на всем проде.

Это логично, но тут же банальные грабли, на которых попадаются не первый раз: "код дропнул всю базу" или "агент очистил всю таблицу". Если боту дают возможность выполнить DELETE, то нужен прокси который спросит подтверждение; если это код, написанный ботом, то нужен базовый safety check, вручную или автоматическим прогоном после сессии. Но я конечно понимаю разрабов, когда ИИ в 99% решает задачу отлично, ему начинают доверять безоговорочно.

Ну, базовый safety check уже был в библиотеке, но ИИ его выключил :-)

Крон-джоба занимается отменой подписок. Вы тут хоть как ей права ограничивайте - но право отменять подписки ей требуется для работы.

Да. Но зачем давать агенту доступ к управлению такой крон-джобой? Почему он вообще имеет права запускать/модифицировать подобные задачи на проде, учитывая насколько ЛЛМ не надежны и косячны?

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

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

Более того, было же сообщение о модели, которая, получив от инструмента file ошибку о невозможности удалить файл за пределами workspace, не долго думая повторила попытку через инструмент shell.

То есть эта самая эскалация привелегий работает у ИИ автоматически.

Написать программу которая получит больше прав тоже невозможно

Создатели вирусов сейчас смотрят на вас свирепо, но в то же время как-то грустно и с недоумением...

Тут целый блок комментариев про уязвиости.

Читаю и радуюсь. Есть еще куча людей которые не в курсе про риски и поверхности атаки.

Поделюсь еще одной мудростью древних.

Есть риски которые мы принимаем. Есть риски от которых мы защищаемся. Где какой надо заранее разобраться, это очень важно.

Риск уязвимости мы принимаем. Уменьшаем его своевременным обновлением всего.

Риск легально дропа базы от юзера с правами на дроп базы мы не принимаем. И пишем какой-то код который гарантирует что ллмка базу не дропнет. Риска больше нет.

Это тоже давно известные проблемы с давно известными правильными решениями. И эти решения тоже проверены десятилетиями.

Это тоже давно известные проблемы с давно известными правильными решениями. И эти решения тоже проверены десятилетиями

— например, не пользоваться недетерминированными молотками.

Есть такие люди проджект менеджеры. Они уже заметное время ходят кругами вокруг разработки со словами "Надо добавить ИИ в проект. А то мы совсем отстаем от современного мира и скоро безнадежно устареем."

К лету 26 года причин отказывать им уже вообще не осталось. Вот я уже некоторое время строю разнообразные заборы и ставлю предохранители везде. Чтобы этот ИИ пользователю ничего не разломал даже в худшем сценарии.

У ИИ своя песочница без прав на БД вообще. Изоляция сервиса полная вообще от всего, отдельная виртуалка почти без сетевой связности. Даже интернет ей дан по белому списку. Общение с основной частью проекта только через АПИ или даже через отдельные прокси сервисы с ограничениями если АПИ страшно выглядит или прав многовато дает. Все обмазано MCP и скилами.

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

Так что почему нет? Классические подходы отлично работают в 2к26.

Так выглядит же нормально вроде логика - если { userId: null } , то снести все - обычно так композитные фильтры и делают - что не налл, то только по тому фильтруется.
Тут больше вопрос почему в функцию на удаление не пришел конкретный айди и не было валидаций - хотя может там был другой фильтр не по юзеру (должен быть) для балкового удаления - короч из статьи нихрена непонятно - может бот не настолько и виноват по сравнению с этими гамнакодерами.
Да и вообще нафика нужна функция для балкового удаления того, что тебе бабло приносит - там достаточно по юзер айди оставить, а если надо много - пусть в цикле удаляет. Кто бот такое просил делать - тот нытик, что сейчас ноет? Ну пусть теперь родню подписывает на свою поделку и того чувака, которому файлы на компе снесли

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

TypeORM упоминался же. Это универсальный построитель запросов, он знать не знает какие запросы допустимы, а какие нет. Формировать корректные запросы - ответственность вызывающего кода.

А уровнем выше там наверняка была та самая функция, которая удаляет конкретного пользователя. Только там был баг, из-за которого при попытке удалить undefined удаляются вообще все.

может бот не настолько и виноват по сравнению с этими гамнакодерами

В данном случае, бот - и есть “гамнакодер”

А запрос, на то, что должно быть в итоге и как работать он тоже сам себе писал?)

Просто кто-то задачи столетия решает, а кому-то прод-базу сносят или макбук чистят на плюс-минус того же уровня моделях - кто-то что-то явно не договаривает)

В обсуждаемом случае речь идёт о “простом” баге в коде, то есть ожидаемое поведение как код должен работать было корректным, а налажал исключительно ИИ в реализации (а перед этим - он же в архитектуре).

Тут даже не столько это интересно, а сколько, после всего случившегося, святое упование на другую ллм:

Fable 5 has never done this to me. Fable 5 can be trusted with production.

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

Да тут скорее уже вторая ситуация выглядящаяя как заказуха вида "5.6-sol фигня которая вам всё угробит, а вот Fable never!!".

Учитывая что фейбл доступен людям не особо дольше чем Sol, а стоит в разы дороже - его банально в таких задачах никто и не использует. И тем более не испрльзуют настолько долго что бы "can be trusted with production".

Антропики просто похоже конкуретную борьбу за внимание пользователей проигрывают после сильного мува с отменой 5ч лимитов в кодексе (который нам еще акунется тихим подрезанием недельных ибо на них не так заметно)

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

3. Не писать на Typescript

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

А то сейчас появилась новая мода не заморачиваться “сложными” этапами сборки и просто гнать исходники в bun. А bun хоть Typescript и поддерживает - но типы не проверяет, совсем.

Обвешаются типами, которые не работают в рантайме, а потом удивляются что что-то пошло не так )

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

Ну, он довольно храбрый человек. Однако в данном случае проблема была не в слишком больших правах агента

Однако в данном случае проблема была не в слишком больших правах агента

...а в ДНК!

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

Агент вообще не должен касаться кода на проде (чтобы не плодить там багов) и опасных тулов на проде (бд с высокими правами, тулов способных всё дропнуть и т.д). Если человек позволяет делать подобное агенту вне тестового контура - человек ССЗБ. Он бы еще мартышку крон-джобы управления подпиской ставить посадил.

Такие баги на тестовом контуре не поймать.

Поскольку крон-джоба работает по расписанию - каждый день есть ровно одна попытка тестирования, а требующих тестирования сценариев куча.

Ловить такие баги можно интеграционными тестами, но для этого их надо писать. А ИИ, по моему опыту, не умеет генерировать сценарии для тестов (как и многие программисты включая меня)

Все ключевые 7 секунд вполне уложатся и в обеденный перерыв, и в поход в туалет.

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

Наняли-бы какую-нибудь девочку обрабатывать заявки вручную, она-бы сделала то-же самое.

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

Девочка делала бы не 7 секунд, а 7 часов с перерывом на обед, макияж и кофе

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

Ну так девочка пустого пользователя бы проигнорила на 99,99999% (оставим небольшую вероятность для сугубо исполнительной и вдумчивой девочки) на том история этого фиаско и закончилось бы..

Вы исходите из того, что ИИ работал на проде и обрабатывал заявки. А это не так, на прод ИИ не пускали, ИИ только писал код.

Мне кажется, или проблема в API, в котором отмена одной подписки и всех подписок это один и тот же эндпойнт? И нужен ли вообще функционал отмены всех подписок одним вызовом API? Неужели это так часто нужно? Я бы не делал такую функцию по возможности.

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

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

Дак и API было написано этим ИИ ;)

Очень вероятно, потому что ИИ обожает добавлять сущности “на всякий случай”, в которых реальной необходимости нет.

Скрытый текст

Объяснение, кто не смотрел мультик (я и сам не смотрел): в начале мультфильма есть комедийная сцена, где президент США тянется к большой красной кнопке. Помощники в панике останавливают его, потому что эта кнопка запускает ракеты. Тогда президент спрашивает: "А какая кнопка делает латте?", ему показывают вторую, такую же красную кнопку, и она действительно готовит кофе. Затем он возмущается: "Какой дебил это придумал?", на что получает ответ: "Вы".

А что за мультфильм? (Кстати, ИИ не знает и даже не пытается наглючить.)

Монстры против пришельцев.

(Кстати, ИИ не знает и даже не пытается наглючить.)

Странно, Google Lens (Google объектив) с первого раза справился по этому изображению, рекомендую использовать его для поиска по кадру/фото — не сработает разве что с малоизвестными людьми — их искать по интернету откажется из-за этики.

Вы правы, такой функционал избыточен. Я сделаю соответствующие изменения!

Странно смотрится для тех кто в курсе что мухомор условно съедобный гриб а не ядовитый...

На севере живёте? Чем южнее - тем ядовитее грибы.

Не видел инфы чтоб один вид отличался по ядовитости в зависимости от места произрастания. В любом случае вываривание токсинов не даёт гарантии, по этому такое обычно едят сами грибники на свой страх и риск и не дают другим)

Это “API” называется SQL, с добрым утром. Там всё ровно так как вы сказали: забыл написать where в запросе - и получи удаление всех данных, к тому же каскадное.

Вам не нужно “делать” эту функцию намеренно, она идёт из коробки в любой ORM кроме самых бесполезных. Достаточно допустить ошибку в коде которая эту функцию случайно активирует.

Инвестор Matt Shumer, похоже, так ничего и не понял :)

Когда нейронка поняла, что написала говнокод, и решила избавить подписчиков от сервиса на говнокоде.

GPT 5.6 это просто недооценённый герой среди нейронок.

Харакири, ИИ-стайл.

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

А кто ж знал, что оно критическое, что робот его таким закодил?! ) На первый взгляд выглядело обычным скучным майнтенансом.

Поэтому и пишу, что "в том числе". Тут, очевидно, главная дыра - непроверенное api, которое слишком много позволяет. Но пользователя с пустым ником проверка запроса вполне могла и обязана была поймать (если я правильно понял, что у них произошло).

Верно, по канону агентов должно быть двое.
Отстаёте от жизни!

Должен быть ещё третий агент, который валидирует второго. И четвёртый, пятый, n-ный… А выше них - человек, попивающий смузи и пишущий очередные статьи “Как я написал X без опыта в погромировании”

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

А второго агента должен проверять третий агент. Третьего - четвертый. И дальше агенты до самого низа.

Да, если это снижает вероятность ошибки. Но врядли мы можем придумать для третьего более строгие правила, чем для второго, так что работать не будет. А вот дискриминатор снижает вероятность ошибки кратно

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

Ну, а вы протестируйте гварда, чтобы он валидные запросы пропускал. А отказ не фатален. Первый агент скорректирует своё поведение

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

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

Всё навайбкожено до нас

https://github.com/paperclipai/paperclip

If OpenClaw is an employee, Paperclip is the company.

  1. Define the goal “Build the #1 AI note-taking app to $1M MRR.”

  2. Hire the team CEO, CTO, engineers, designers, marketers — any bot, any provider.

Есть старая грузинская короткометражка, про то как хозяин винодельни нанял сторожа сторожить подвал с бочками с вином. Но вино стало убывать (удивительно, да?). Тогда он нанял второго сторожа, сторожить первого. В конце фильма, ко входу в подвал стояла длинная очередь из сторожей.

А второго агента должен проверять третий агент. Третьего - четвертый. И дальше агенты до самого низа.

Но в какой-то момент черепахи начинают кончаться

Все правильно.. Вайбанутые должны страдать...

Вайбанутые должны страдать...

Вернее, они должны начать страдать раньше, чем из-за них начнут страдать нормальные (а они начнут...)

Главное чтобы что-то подобное не внедрили в больнички (эвтаназию проводить) или в тюрьмы для приведения приговоров в исполнение.
"Всем киберполицейским! Обнаружить и нейтрализовать особо опасно преступника на территории Готэм-Сити ! (пустое фото прилагается)

Главное чтобы что-то подобное не внедрили в больнички

Или подобное...
Life imitating art

«Я сказал — левой!» ©

Кстати, «wrong site» — это «неправильное место», а не «неправильная сторона».

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

Получается так. Учится у лучших.

И усиливает худшие их качества.

или в тюрьмы для приведения приговоров в исполнение

Ну так-то женщина уже пол года отсидела, потому что ИИ перепутал фото.

Я не поклонник LLM и противник AI психоза, НО тут драгоценный автор - виноваты Вы и только Вы. Вы дали этому чуду полный доступ без sandbox, контроля, права на невозвратные операции...

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

драгоценный автор - виноваты Вы и только Вы.

Скажите, пожалуйста, а что отключили Вы, когда читали новость? Ведь драгоценный автор @denis-19— это просто местный контентогенератор, а песец подкрался к какому-то американскому вайбкодеру.

Я писал дословно:

НО тут драгоценный автор - виноваты Вы и только Вы. Вы дали этому чуду полный доступ без sandbox, контроля, права на невозвратные операции.

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

американского вайбкодера

но раз Вы выдаете пассажи плана:

а что отключили Вы

для таких как Вы буду уточнять.

По-моему, основная проблема AI в том, что они не сомневаются. А это открывает простор для всяческого рода "чудесных вещей".

А что мешало восстановить прод из резервной копии? В чём пафос-то?

Прод сделал, резервные копии не сделал...)

Возможно подписки с оплатой на стороне платежной системы отменились.

Там смотря какой API использовать:

Можно создавать подписки на стороне самого Stripe. Он будет сам снимать деньги, а твой backend только получать оповещения вроде "деньги сняты, продлите подписку на своей стороне, чтоб у пользователя не пропал доступ к сервису". В этом случае да, отмененные подписки вернуть обратно не получится — пользователю нужно вручную пройти через подтверждение подписки.

А можно проставить флажок "сохранить на стороне Stripe карту" при первой покупке. Тогда можно будет по расписанию отправлять в Stripe запросы "сними с сохраненной карты еще столько-то денег". В таком случае отмена подписки — это всего лишь удаление записи "снимать с пользователя деньги по такому-то расписанию" из своей собственной базы данных. И тут бэкапы всех спасут: карточки хранятся на стороне Stripe, так что пользователю не потребуется вручную оформлять подписку еще раз.

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

Хуже если там ещё и рефанды были сделаны.

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

Возможно то, что запускают сервисы люди которые даже не знают, как это делается. Сейчас же 90+% новых SaaS обёртки над ИИ. Ещё и стали популярны сервисы, типа Supabase (я долго понять не мог зачем это нужно, если можно поставить БД на свою VPSку).
Просто у создателей таких SaaS была идея (а зачастую и идею им ИИ придумали), а знаний в этом деле нет, вот они и выбирают варианты, где всё может ИИ сделать.

Разве подобные события это ещё новость? Не очень понимаю смысл публикации такого до сих пор.

Senior security-engineer skill for AI coding agents. 

Если я что-нибудь в чём-нибудь понимаю, то это, получается, они платный markdown-файл продают?

Это мало чем отличается от продажи книг или фотографий.

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

Разве что они их там тюнят под каждого клиента каждый раз

Это не баг, это естественный отбор. ИИ просто ускорил эволюцию ИИ-стартапа на пару лет. Действительно умная модель, Дарвин бы оценил.

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

Бог дал, бог взял (с)

Бог из машины

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

ну похоже не такой уж и мусорный раз смог залутать ежемесячных подписок на много тысяч. Счастье закончилось но все же

ну похоже не такой уж и мусорный раз смог залутать ежемесячных подписок на много тысяч.

Мошенники тоже много тысяч лутают.

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

У ИИ вообще нет понимания, что вообще происходит (как бы нам продавцы слонов не пытались втулить обратное). Оно просто байтики перекладывает — просто по очень‑очень сложным правилам (см. китайская комната).

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

Китайская комната — это модель человеческого мышления

Китайская комната — это модель вообще всего, что слишко сложно для понимания.

Наши нейроны в мозгу тоже передают друг другу сигналы по очень‑очень сложным правилам.

Но в отличие от LLM, нет никакой возможности «подсматривать» за их работой в сколь‑нибудь значимых объёмах.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации