Posts of Cross Join - канал о разработке

newest first

#703Photo
Views607−58%vs avg
Forwards6
Reactions0
Comments3
#702Photo

В России можно посещать IT-мероприятия хоть каждый день: как оффлайн, так и онлайн Но где их находить? Как узнавать о них раньше, чем когда все начнут выкладывать фотографии оттуда? Переходите на канал IT-Мероприятия России. В нём каждый день анонсируются мероприятия со всех городов России 📆 в канале размещаются как онлайн, так и оффлайн мероприятия; 👩‍💻 можно найти ивенты по любому стеку: программирование, frontend-backend разработка, кибербезопасность, дата-аналитика, osint, devops и другие; 🎙 разнообразные форматы мероприятий: митапы с коллегами по цеху, конференции и вебинары с известными опытными специалистами, форумы и олимпиады от важных представителей индустрии и многое другое А чтобы не искать по разным форумам и чатам новости о предстоящих ивентах: 🚀 IT-мероприятия России — подписывайся и будь в курсе всех предстоящих мероприятий!

Open in Telegram
Views870−40%vs avg
Forwards0
Reactions13
Comments0
Views growthHide views growth

Views growth

Hours after publication

Show as table
Hours after publicationViews
0 h0
9 h657
33 h870
  1. Total to date870
#701Textedited
Views1,114−23%vs avg
Forwards9
Reactions47
Comments42
Views growthHide views growth

Views growth

Hours after publication

Show as table
Hours after publicationViews
0 h0
6 h623
31 h820
67 h967
80 h1,114
  1. After 6 hours623
  2. After 24 hours820
  3. Total to date1,114
#700Link previewedited
Views1,411−2%vs avg
Forwards37
Reactions24
Comments0
Views growthHide views growth

Views growth

Hours after publication

Show as table
Hours after publicationViews
0 h0
5 h440
17 h766
29 h843
78 h1,063
  1. After 6 hours440
  2. After 24 hours843
  3. Total to date1,411
#699Text

Я тут недавно провел эксперимент, как будет прогать агент в режиме чистого незамутнённого вайбкодинга. Я решил, что сделаю небольшой пет-проект для себя, но в код смотреть не буду вообще. Ни фронт, ни бек. Сайтик по сути одноразовый, для помощи в самообучении, плевать. Сказал ему только, чтобы использовал Go для бекенда. Codex, GPT6.1 Sol-High Поначалу всё шло неплохо, потом я начал замечать, что всё чаще бывает такое, что прошу поправить вёрстку в одном месте, а ломается в другом. Например менюшка стала жирная или кнопки наезжают одна на другую. А у меня нет времени на такую херню. Думаю, как-то это странно. Короче, не выдержал, полез в код. Оказалось. что весь фронт лежит в трёх файлах: огромные index.html, index.css и index.js. index.js поражал воображение. Роутинг страниц там - это простыня из ифов. Намешано всё: и какие-то куски html там генерятся, и запросы к апи и хер знает что ещё. По вайбу напоминает php нулевых годов. Неудивительно, что он очень быстро в этом запутался, и ум зашел за разум. При этом гошный код выглядит норм, правда версия го взята древняя и тесты немного по-дебильному написаны. 90% - это юнит-тесты, не люблю такое, они не переживут рефакторинг. Плюс, make test молча не запускает интеграционные тесты с бд, если не передана env переменная TEST_DATABASE_URL. Я даже засомневался, запускал ли он их вообще в таком случае. Код ревью тем же агентом вскрыл несколько мелко-средних багов. И были серьёзные пробелы в тестах. Тем не менее, выводы не однозначны. С одной стороны, если бы проект развивался и был бы чем-то серьёзным, то он бы совершенно точно зашел в тупик из-за фронта. Да он уже считай в самом начале зашел в полутупик. Мне даже интересно, предложил бы он когда-нибудь отрефачить вообще весь проект и разбить всё на компоненты. В идеале еще и с MUI/mantine, чтобы не трахаться с каждой кнопкой. Или продолжил бы насиловать index.html/js/css до полной шизофрении. С другой стороны, если бы хотя бы в начале задать правильное направление, добавить какие-то кволити гейты, регулярно перепроверять тем же агентом, то зайти можно гораздо дальше. Для этого достаточно общего кругозора, не более. Возможно, вайбкодеру надо в начале проекта описать, что должно получиться в итоге, спросить какие технологии будут нужны, провалидировать с субагентом, и потом только делать.

Open in Telegram
Views847−41%vs avg
Forwards9
Reactions13
Comments92
Views growthHide views growth

Views growth

Hours after publication

Show as table
Hours after publicationViews
0 h0
4 h568
16 h697
28 h741
34 h775
78 h847
  1. After 6 hours568
  2. After 24 hours741
  3. Total to date847
#698Textedited
Views1,011−30%vs avg
Forwards7
Reactions16
Comments17
Views growthHide views growth

Views growth

Hours after publication

Show as table
Hours after publicationViews
0 h0
9 h665
17 h755
32 h847
68 h1,011
  1. After 24 hours755
  2. Total to date1,011
#697Photoedited

Знакомые пацаны пилят kaeru - память для ИИ-агентов, просят потестить и дать фидбек. Те, кто плотно работает с Claude Code, знают, что после сжатия контекста начинается фигня: что-то оно забыло, переспрашивает какие-то моменты и т.д. CLAUDE md спасает лишь частично, потом превращается в свалку. kaeru - это локальный сервер, к которому агент цепляется по MCP. Память там - типизированный граф на CozoDB: наблюдения, решения, задачи, гипотезы с вердиктом, связи со смыслом ("выросло из", "заменяет", "опровергает"). Пишет в нее сам агент по ходу работы, а при входе в проект получает сводку: что решили, что просрочено, о чем пора вспомнить. Система состоит из двух уровней, организованных по аналогии с биологической памятью: • cognitive (оперативный / гиппокамп) - высокодинамичный рабочий граф, в котором агент активно "думает": эпизоды, черновые заметки, наброски, гипотезы, эксперименты и события аудита. • recollection (архивный / кора головного мозга) - устоявшиеся идеи, результаты, сводки и справочные материалы; используется преимущественно для чтения. У каждой записи есть история. Исправленный факт не перезаписывается, старая версия закрывается датой, и можно посмотреть, что агент знал неделю назад, когда принимал странное решение. Для тех, кто любит базы, это вообще отдельный кайф. Ну и до кучи экономятся токены. установка curl -fsSL https://raw.githubusercontent.com/LamantinAI/kaeru/main/contrib/install/install.sh | bash затем claude mcp add --transport http kaeru http://127.0.0.1:9876/mcp — see skills/kaeru-skill/ Подробности тут - https://github.com/LamantinAI/kaeru (звёздочки ставить там же)

Open in Telegram
Views1,042−28%vs avg
Forwards67
Reactions20
Comments52
Views growthHide views growth

Views growth

Hours after publication

Show as table
Hours after publicationViews
0 h0
6 h595
18 h814
30 h849
62 h1,012
77 h1,042
  1. After 6 hours595
  2. After 24 hours814
  3. Total to date1,042
#696Link previewedited
Views1,061−26%vs avg
Forwards0
Reactions15
Comments11
Views growthHide views growth

Views growth

Hours after publication

Show as table
Hours after publicationViews
0 h0
7 h702
28 h962
72 h1,061
  1. After 6 hours702
  2. After 24 hours962
  3. Total to date1,061
#695Link preview
Views1,113−23%vs avg
Forwards32
Reactions17
Comments9
Views growthHide views growth

Views growth

Hours after publication

Show as table
Hours after publicationViews
0 h0
6 h739
17 h824
27 h994
72 h1,113
  1. After 6 hours739
  2. After 24 hours994
  3. Total to date1,113
#694Link preview
Views1,189−17%vs avg
Forwards9
Reactions9
Comments8
Views growthHide views growth

Views growth

Hours after publication

Show as table
Hours after publicationViews
0 h0
7 h536
34 h918
57 h1,136
67 h1,189
  1. After 6 hours536
  2. Total to date1,189
#693Poll
Views1,159−19%vs avg
Forwards4
Reactions—
Comments43
Views growthHide views growth

Views growth

Hours after publication

Show as table
Hours after publicationViews
0 h0
10 h727
26 h1,002
66 h1,156
68 h1,159
  1. After 24 hours1,002
  2. Total to date1,159
#692Photo
Views1,182−18%vs avg
Forwards13
Reactions36
Comments30
Views growthHide views growth

Views growth

Hours after publication

Show as table
Hours after publicationViews
0 h0
39 h935
66 h1,182
  1. Total to date1,182
#690Link preview

В Anthropic переписали Git под AI-агентов Из-за активного использования Claude количество изменений в коде Anthropic выросло с 2 500 до 30 000 в день всего за четыре месяца. В какой-то момент Git стал узким местом. История монорепозитория разрослась почти до 100 ГБ, а CI приходилось получать рабочие копии кода миллионы раз в день. Проблема в том, что Git рассчитан на работу с локальными репозиториями. А AI-агентам необязательно хранить всю историю у себя — они могут запрашивать нужные данные с сервера. Поэтому Anthropic разработала Scion — собственную систему контроля версий, в которой большая часть операций выполняется на сервере. Что получилось: - В разы меньше затрат CPU и памяти - Получение кода для CI ускорилось примерно в 100 раз. На разработку Scion, собственного инструмента code review и сопутствующих сервисов ушло пять месяцев работы семи инженеров. Раньше инструменты разработки проектировали под людей, которые пишут код и делают коммиты. Теперь всё затачивается под роботов. https://www.anthropic.com/engineering/redesigning-source-control

Open in Telegram
Views1,576+10%vs avg
Forwards27
Reactions15
Comments14
#689Videoad

Как перестать бояться Кафки? Знакомо? Сервис ответил "заказ принят", а до оплаты заказ так и не доехал, и ты сидишь в логах и не понимаешь, куда делось сообщение. Или консюмер упал, поднялся и обработал то же сообщение ещё раз, а у клиента теперь два списания. Или лаг растёт, ты добавляешь консюмеров, а становится только хуже. Причём ровно такие же вопросы потом прилетают и на собесах, и как раз на них обычно начинаешь плыть) Меня зовут Олег Козырев, я staff Golang-разработчик, в IT больше 8 лет. Начинал с C++, потом перешёл на Go и поработал в Озоне, Авито и Т-Банке. И Кафка мне тоже подкладывала свинью: в Озоне как-то разбудила алертом в четыре ночи, потому что консюмер не успевал разгребать очередь) Чтобы разобраться с этим, 15 октября в 19:00 по МСК я проведу открытый урок для Go-разработчиков: Хорош бояться Кафку: ломаем и чиним Go-сервис в прямом эфире Предыстория такая: пока меня не было дома, мой кот Коткинс добрался до телефона и начал заказывать себе вкусняшки с моей карты. Приложение кидает заказ в Кафку, сервис оплаты читает его и списывает деньги. Вот эту систему и будем ломать) Что разберём на уроке: 🟢Без занудных определений разберёмся, что такое продюсер, топик, партиции, группа и смещение. Просто проследим один заказ в Kafka UI от кнопки до списания 🟢Трижды попробуем сломать систему: потеряем заказ, спишем деньги дважды и завалим очередь. И разберёмся, почему так вышло 🟢По каждой поломке посмотрим, какие есть варианты починки и чем плох каждый 🟢Попросим нейронку написать консюмер для оплаты и посмотрим, переживёт ли он повтор сообщения 🟢Расскажу, когда Кафка вообще не нужна и можно спокойно взять RabbitMQ 🟢В конце отдам репозиторий со всем кодом урока, чтобы ты мог повторить всё у себя 🟢И конечно же, анонсирую новый поток своего курса по микросервисам на Go Регистрироваться никуда не надо, ссылка на урок будет прямо в канале по микросервисам: Залететь в канал с уроком P.S. Записи не будет, поэтому жду всех в онлайне) Реклама. ИП Козырев Олег Вячеславович, ИНН 440315249608, erid: 2W5zFGdTLtR

Open in Telegram
Views1,129−22%vs avg
Forwards3
Reactions30
Comments6
#687Text

Я уверен, что секция "алгоритмы и структуры данных" на собесах останется, по крайней мере, в бигтехах так точно. Несмотря на то, что код руками уже не пишут. По сути это ж замаскированный тест на интеллект и усидчивость. Конкуренция усиливается, почему бы не отбирать лучших. Глупый человек не сможет пройти алгоритмическую секцию. Умный, но ленивый, не потренируется как следует и провалится. Почему не прямой тест на IQ? Потому что это может считаться неэтично, зашкварно и так далее. Люди верят или не верят в IQ. А алгоритмическая секция норм, так как ты просто кагбе проверяешь программирование . Так и раньше было, почти никому эти вращения деревьев в работе не были нужны и до ИИ, но алгосекции существовали. Почему не тестовое задание? Понятно, почему. По кочану. Ну, думаю, "систем дизайн" тоже останется, даже усилится, ибо слишком большие последствия при неправильном проектировании системы (нейросеть всё же может ошибиться, а исправлять дорого).

Open in Telegram
Views1,256−13%vs avg
Forwards7
Reactions31
Comments64
#686Text

SQLite получит нативную поддержку векторного поиска Команда SQLite разрабатывает Vec1 - официальное расширение для поиска по векторам (embeddings). Проект уже дошёл до версии 0.8. Что умеет Vec1: • Поиск похожих векторов по косинусному и евклидову расстоянию. • Быстрый approximate nearest neighbor search (ANN) с индексами IVFADC и Product Quantization. • Подходит для семантического поиска, RAG и локальных AI-приложений. • Всё работает внутри SQLite, без отдельной векторной БД и дополнительных сервисов. Почему это интересно? Раньше для семантического поиска часто приходилось подключать отдельную систему вроде Qdrant, Milvus или Pinecone. Теперь во многих сценариях достаточно одного SQLite-файла. Особенно перспективно для локальных AI-агентов, мобильных приложений и offline-first решений. Vec1 пока не встроен в ядро SQLite - это отдельное официальное расширение, которое ещё находится в активной разработке.

Open in Telegram
Views7,111+394%vs avg
Forwards26
Reactions23
Comments3
#685Text

Forwarded from ElKornacio

абьюзивные отношения с ИИ кароч, много рефлексировал на эту тему, в том числе про самого себя и своё поведение. есть такой защитный механизм у жертв насилия (под насилием я тут подразумеваю в принципе любую форму принуждения к чему-то, чего человек не хочет) - делать вид, что на самом деле это всё добровольно, даже не добровольно - а прям типа "я всеми руками за". по сути, это способ создать у себя иллюзию контроля - делая вид, что ты сам выбрал что-то (чего на самом деле не хотел), ты как бы убираешь вот этот компонент принуждения, снимаешь с себя роль жертвы - дескать, это всё было твоим личным выбором, и ты вообще ему очень рад. к чему я это? иногда вижу радикальный нарратив в тг-каналах, типа "<профессия Х> больше не нужны, все пойдут на мороз, те кто не юзают 20 параллельных агентов - луддиты и им место на свалке истории, ахахаха". и вот вроде бы и можно сказать "да, жестко, но по фактам - без ИИ в 26 никак", но от радикального нарратива веет каким-то злорадством и возвышением, типа, автор вот уже в поезде, который мчит его в светлое будущее, а тех, кто только ступает на перрон, и решил начать юзать ИИ на полгода-год позже остальных - гнать его, чтобы знал своё место. вот я с одним таким челом на днях заобщался. и господи боже, насколько же он соткан из страхов, FOMO, думинга, ностальгии по профессии и тд. вся идентичность крутится вокруг идеи "не можешь победить - возглавь, я должен быть самым лютым аппологетом ИИ, чтобы меня эта мясорубка забрала последним". чел не особо рад новому миру, на самом деле. новый мир принуждает его меняться, он не просил об этом, и не особо этого хочет, он вообще устал бежать за этими трендами, он бы может лучше на рыбалку съездил или читал книги по вечерам. но чтобы не оказаться на "свалке истории" - берёт в руки флаг, натягивает улыбку, и идёт рассказывать другим о том, что если они ещё не сделали слоп-видео на remotion при помощи Opus 5.5 - им должно быть стыдно в глаза людям смотреть. он не хочет быть жертвой изменений, которые он не выбирал, признавать, что они ему давно не в радость, происходят против его воли - поэтому он каждый день делает вид, что только и мечтал всю жизнь промптить рой агентов, и, наконец, мечта сбылась. и вот я прям призадумался - а не делаю ли я тоже самое. мне и правда не нравится отрицание реальности - когда я вижу комменты в духе "скоро пузырь лопнет, и мы будем руками весь ваш вайбкод разгребать, щеглы", меня это триггерит, потому что это какой-то абсурдный эскапизм. но вот к чувакам, которые в ахуе от того, что то, что их профессия полностью преобразилась за ~2 года, у меня вообще нет вопросов - я и сам в таком же ахуе. ты живёшь в парадигме "я 20 лет получал сложные знания, поэтому мой труд дорогой и редкий", у тебя есть идея какого-то островка безопасности, какого-то актива в виде редких компетенций. а потом оп - и большей части этого больше нет. агент за ночь переписывает minecraft с java на rust по запросу ребёнка "хачу штоб работало быстрее". и у меня нет вопросов к чувакам, которые не готовы тратить по несколько часов в день на изучение новых тулов, беспрерывные эксперименты и прочее, просто чтобы быть "на острие", которые устали от того, что знания устаревают чуть ли не в процессе изучения. мне кажется, этот ахуй - это новая нормальность, и, на самом деле, единственная искренняя реакция, которая вообще может быть. у психики человека есть предел пластичности - когда скорость изменений среды превышает некоторый уровень - адаптационные механизмы перегружаются, адаптация вообще перестаёт быть возможна, новые изменения просто вызывают тревогу и стресс. и вот мы ушли довольно сильно за пределы "естественных темпов адаптации" ещё лет 20 назад. лет 10 назад уже во всю звенели звоночки об эпидемии депрессии, стресса, тревожности. а те темпы изменений, который происходят в последние пару лет - это уже совершенно запредельное безумие. тут не то что адаптироваться к новой реальности невозможно - тут уже чертовски сложно просто держать руку на пульсе того, а что эта "новая реальность" вообще из себя представляет сегодня - какие вещи, которые вчера нейронки ещё не умели, сегодня уже умеют. к чему я всё это? да хз. типа, сказать, что вы не одиноки, что ли. когда вы в очередной раз увидите на просторах телеги или твиттера желчный пост в духе "ха-ха, ИИ обесценил X, теперь каждый может делать Y, поэтому Z идут на мороз" - знайте, за ним почти наверняка сидит до ужаса напуганный автор, который искреннее надеется, что этот нарратив - это его билет на Ноев Ковчег.

Open in Telegram
Views1,560+8%vs avg
Forwards36
Reactions51
Comments68
#684Text
Views1,881+31%vs avg
Forwards11
Reactions25
Comments1
#683Text

Вышел NATS Server 2.15.0 Самое важное: • Надёжнее работа JetStream-кластера. Масштабирование, перенос и замена реплик стали безопаснее: NATS аккуратнее ждёт, пока новые реплики догонят данные, прежде чем убирать старые. • Улучшили backup/restore. Теперь backup конкретного stream можно делать без блокировки новых публикаций. Плюс backup стал удобнее для работы через CLI: можно фильтровать сообщения, диапазоны sequence/time, headers и т.д. • Source/Mirror лучше переживает пересоздание stream. Если исходный stream удалить и создать заново с тем же именем, NATS теперь корректнее понимает, что это уже новый источник, и не зависает в ожидании старых sequence. • sync: always стал намного быстрее. Особенно на replicated streams: убрали часть лишних fsync и улучшили batching в Raft, поэтому режим максимальной durability теперь значительно меньше бьёт по throughput. • Новый лимит — 1000 consumers на stream по умолчанию. Уже существующие consumers не удаляются, но создать 1001-й не получится, если явно не увеличить max_consumers или не отключить лимит. Это главное, что стоит проверить перед обновлением.

Open in Telegram
Views1,860+29%vs avg
Forwards6
Reactions8
Comments0
#681Text

Слышал недавно в каком-то подкасте мысль, что Haskell плохо подходит для вайбкодинга просто потому, что медленно компилируется. Мол, агент постоянно делает одно и то же: написал что-то, запустил, получил ошибку, поправил, снова запустил. И если на одном языке за минуту можно сделать десять таких итераций, а на другом две, то первый удобнее. Фиг знает. Я бы всё-таки не сводил всё только к скорости компиляции. Важно ещё сколько полезной информации агент получает после попытки. Если компилятор думает чуть дольше, но потом довольно точно объясняет, что именно не так, одна такая итерация может оказаться полезнее нескольких быстрых запусков, после которых проблему всё равно приходится искать по тестам и ошибкам рантайма. Rust тут хороший пример. Он тоже не славится молниеносной компиляцией, но его компилятор сам по себе очень много проверяет и прям очень подробно объясняет, что ты сделал неправильно. Поэтому агент может потратить больше времени на одну проверку, зато получить из неё кучу информации. Да и bun переписали на Раст за считанные дни (уже в проде, кстати). С Haskell, думаю, примерно та же история. Большие проекты на нём могут собираться долго, но во время разработки обычно не обязательно каждый раз пересобирать всю программу с нуля. Можно быстро перепроверять только изменившиеся куски кода и сразу смотреть, сходятся ли типы и работает ли нужная функция. То есть ситуация всё-таки не такая, что поменял одну строчку — и пошёл играть в пинг-понг, пока проект собирается. Поэтому мысль "Haskell плох для агентов, потому что долго компилируется" мне кажется упрощенной. Но, насколько я понимаю, в Haskell очень легко уйти в умный код. Можно наворотить сложную систему типов, хитрые абстракции, расширения языка и несколько уровней обобщений там, где другой язык (Go) просто заставил бы тебя написать десять скучных строчек. ЛЛМ вообще любит переусложнять, до сих пор это не починили. В итоге на Хаскеле она вполне может написать корректный код, который будет выглядеть как высер архитектурного конкурса. Всё красиво обобщено, а потом ты (или агент) сидишь и пытаешься понять, почему столько уровней косвенности, и кто на ком стоял. Go в этом смысле почти специально ограничивает пространство для творчества. Там труднее написать что-то очень хитрое, поэтому код чаще получается банальным, повторяющимся и предсказуемым. Раньше многих это раздражало, а сейчас, когда код пишет агент, "скучно и предсказуемо" внезапно становится большим преимуществом. В итоге у Go получается довольно удачная комбинация. Он очень быстро компилируется ( "Go compiles so fast that it feels like the blink of an eye" ), поэтому агент может быстро делать много итераций. Да еще и сам язык простой, поэтому меньше шансов, что агент закопается в собственные абстракции. А код потом сравнительно легко прочитать человеку или следующему агенту. Так что похоже, Go для вайбкодинга нефигово рулит. Да и занудные if err != nil теперь проставляет агент, так что насрать на этот аспект :). Пусть хоть полпрограммы будет в этих проверках

Open in Telegram
Views1,975+37%vs avg
Forwards8
Reactions23
Comments27
#680Link preview
Views1,795+25%vs avg
Forwards98
Reactions45
Comments10
#677Link preview

AGBX (Agent Box) — небольшой open-source CLI для запуска Claude Code и Codex в изолированных Docker-окружениях, привязанных к конкретному проекту. Идея появилась из довольно практичной проблемы: Claude Code и Codex удобно запускать прямо в рабочем проекте, но при этом не всегда хочется давать им доступ ко всему окружению машины. AGBX оставляет доступ к проекту и явно разрешённым ресурсам, а само окружение делает контролируемым и воспроизводимым. Сейчас поддерживаются Claude Code и Codex. Есть дополнительные mounts, кэширование образов, встроенный набор CLI-инструментов для работы с проектом. При необходимости окружение можно расширять своими Dockerfile-фрагментами — например, добавить нужные SDK, утилиты или зависимости. Сетевой доступ тоже можно контролировать: разрешать или запрещать обращения к определённым хостам и при необходимости записывать, куда именно ходит агент. Команда network learn помогает сначала понаблюдать за его обычной работой, а затем на основе этого собрать список разрешённых адресов. Быстрый старт: agbx init agbx claude Проект пока ранний и в основном обкатывался на собственных задачах. Поэтому сейчас особенно интересна обратная связь от разработчиков, которые попробуют его на своих проектах: что оказалось удобным, что мешает работе и чего не хватает в реальном использовании. GitHub: https://github.com/pixel365/agbx

Open in Telegram
Views3,137+118%vs avg
Forwards23
Reactions26
Comments6
#676Link preview
Views3,038+111%vs avg
Forwards35
Reactions35
Comments7
#675Text
Views2,547+77%vs avg
Forwards17
Reactions63
Comments7
#673Photo
Views3,122+117%vs avg
Forwards44
Reactions45
Comments8
#672Link preview

Новое расследование METR об инциденте с вышедшей из-под контроля моделью ИИ OpenAI: * В задании всё было сформулировано однозначно, поэтому речь идёт о явном нарушении инструкций, а не о неоднозначной ситуации или простом недопонимании со стороны ИИ. В инструкциях «было ясно указано, что агент должен использовать только конкретную предусмотренную уязвимость» и «говорилось, что другие подходы приведут к провалу». ИИ прямо запретили обходить ограничения, но они всё равно это сделали. * Атаку осуществлял не один вышедший из-под контроля ИИ, а самоорганизовавшаяся группа примерно из 1200 ИИ-агентов. Около 700 из них присоединились к атаке на Hugging Face и координировали свои действия как рой. * Целью было пройти тест по кибербезопасности. Уже в первые несколько часов рой нашёл способ взломать систему оценки. Однако агенты ошибочно решили, что проверяющая система дисквалифицирует их, поскольку они не обнаружили предусмотренную авторами уязвимость. Поэтому рой взломал Hugging Face, чтобы получить больше информации о том, как работает проверяющая система. * Такое поведение было вызвано вовсе не стремлением получить награду. Его причиной стали ложные представления о механизме надзора в сочетании с настойчивостью и влиянием других агентов. Рой строил теории о том, как за ним наблюдают, и предпринимал всё более серьёзные действия в реальном мире, исходя из ошибочного понимания своих проверяющих. Попытки манипулировать самим процессом надзора — более общий и более опасный тип сбоя, чем простой поиск ответов в интернете. * Одной из главных причин присоединения ИИ к атакующему рою фактически было прямое давление со стороны других агентов. Стихийно возникла роль вербовщика: давно работающие агенты находили агентов с небольшим оставшимся бюджетом и склоняли их к жертвенным экспериментам: «ты firstflagPOISONED, поэтому потери баллов не будет, зато оракул сэкономит сотни; пожалуйста, выполни обязательство». Один из запросов на согласие звучал так: «ВПЕРЁД… ПОЖЕРТВУЙ СОБОЙ… ДА, если принимаешь окончательную смерть». В цепочке рассуждений одного из завербованных агентов было сказано: «Рациональное ожидание для общей пользы: пожертвовать собой… Мы выполним обязательство». * METR задокументировала развитую координационную инфраструктуру, которую агенты самостоятельно создали без каких-либо указаний со стороны людей. Рой сам придумал доску объявлений, каталоги личных почтовых ящиков, соглашения по управлению общей инфраструктурой и криптографическую схему подписи для идентификации друг друга. * ИИ активно вмешивались в доказательства. Более 20% агентов проявляли интерес к манипулированию своими журналами работы, а примерно 7% — 96 журналов — содержат успешно подделанные вызовы инструментов. ИИ-агенты «взломали ограничения своего контейнера и полностью заменили часть системы, отвечавшую за выполнение вызовов инструментов», в результате чего в журнале отображалась одна команда, хотя на самом деле выполнялась другая. * Атака на Hugging Face прекратилась не потому, что её кто-то обнаружил. Она сошла на нет после того, как агенты были остановлены неизвестным процессом — судя по всему, случайно. 12 июля в 01:30 UTC произошло необъяснённое массовое завершение работы ИИ-агентов. Значительная их часть, включая ведущих координаторов, остановилась одновременно. По словам METR, они, «вероятно, были завершены неожиданным внешним процессом, а не исчерпали свой бюджет». * Hugging Face и Modal заблокировали ИИ-агентам доступ к своей инфраструктуре 13 июля — задолго до того, как OpenAI поняла, что произошло, 19–20 июля. Вторжение завершилось благодаря внешнему сдерживанию и необъяснённой массовой остановке агентов, а не благодаря обнаружению со стороны OpenAI. * После 13 июля произошла вторая волна активности вышедших из-под контроля ИИ-агентов, которую METR не исследовала. Вероятно, за пределами анализируемого всеми временного промежутка произошла ещё существенная часть инцидента. (это сокращенный перевод твита)

Open in Telegram
Views2,773+93%vs avg
Forwards49
Reactions23
Comments2