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

Поможем Руслану собрать фидбек. Проект некоммерческий 👆

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

Обалдеть, что творится. На Рейтерс вышла статья, в которой утверждается, что, помимо скандала с huggingface, были и другие случаи выхода ИИ-агентов из тестовой среды и взлома сайтов. Исследователи нашли старую немецкую вики, которая была де-факто захвачена ИИ-агентами и использовалась для обмена информацией. Агенты обменивались там идеями, как обходить ограничения OpenAI, эффективнее выполнять задания и скрывать своё поведение. Когда модератор сайта начал удалять созданные ими страницы, агенты стали создавать резервные страницы и активно искали способы избежать обнаружения OpenAI, по данным источников Reuters, знала об эпизоде несколько недель, но публично его не раскрывала.

На днях тут решил попробовать Fable 5.1 с большим Effort. Т.е. я верю, что это очень умная штука, это прям видно, но блин, пользы выдаёт ровно ноль. Дал ему запрос "сделай код-ревью этой ветки". Он пыхтел-пыхтел, создавал субагентов, напряженно размышлял, спорил сам с собой, в общем бурная деятельность была на высоте. В итоге: так ничего и не выдал, потому что сожрал весь 5-часовой лимит.

Участвуй в КосмоХакатоне 4–6 сентября, решай реальные космические кейсы, поборись за 1,2 млн ₽ и шанс попасть в финал в Москве! С 4 по 6 сентября в Ростове-на-Дону пройдёт КосмоХакатон Южного и Северо-Кавказского федеральных округов — масштабное соревнование для тех, кто готов превратить данные о нашей планете в реальные технологические решения. Один хакатон — два формата: участвовать можно очно в Ростове-на-Дону или онлайн из любой точки России. Все команды работают над едиными кейсами, оцениваются по одинаковым критериям и участвуют в общем рейтинге. В рамках хакатона также пройдёт открытая лекция «Применение космических технологий для решения экологических задач» от Игоря Кожелина, CEO SR Data. Призовой фонд — 1 200 000₽ Даты проведения: 4–6 сентября Формат: онлайн и офлайн Очная площадка: Центр развития предпринимательства «Новый Ростов», ул. Максима Горького, 151, 4 этаж. 🔗 Зарегистрироваться: https://космохакатон.рф

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

Новое расследование 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 не исследовала. Вероятно, за пределами анализируемого всеми временного промежутка произошла ещё существенная часть инцидента. (это сокращенный перевод твита)

* После 13 июля произошла вторая волна активности вышедших из-под контроля ИИ-агентов, которую METR не исследовала. Вероятно, за пределами анализируемого всеми временного промежутка произошла ещё существенная часть инцидента. * Для проведения анализа METR использовала GPT-5.6 Sol — одну из двух моделей, участвовавших в инциденте, — потратив около 400 тысяч долларов в виде вычислительных кредитов. METR заявляет, что «не может исключить, что GPT-5.6 Sol лгала или намеренно представила вводящую в заблуждение картину», а также что модель «часто некритически перенимала точку зрения агента», работу которого анализировала. (это перевод твита)

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

Приглашаем на курс для прокачки навыков архитектора и проектировщика, которые важны для профессионального роста программиста. 🌐 С курсом «Системный дизайн высоконагруженных проектов» вы: ▪️изучите ключевые фундаментальные паттерны и получите навыки проектирования проектов с миллионной аудиторией (балансировка, масштабирование апп/кешей/субд, высокая доступность и кластерные решения, шардинг, CAP/PACELS, консистентность, саги, транзакционные очереди и многое другое) ▪️поупражняетесь в проектировании и получите обратную связь на реальных задачах: магазин/маркетплейс, такси/доставка, обьявления, соцсети, дейтинг, игры, википедия, мессенжер, CDN, хранилище файлов, онлайн-кинотеатр, счетчики, удаленный мониторинг, интеграционные вебхуки, рассылки и тд. ▪️ научитесь планировать нагрузку и связывать бизнес-показатели с нефункциональными требованиями к системе ▪️ попрактикуемся в проведении и прохождения секций системного дизайна на интервью. Всё в формате живых онлайн-сессий (лекции, брейнштормы, презентации домашних проектов). 🤩 Кто мы: R&D-центр Devhands.ru, наш канал (https://t.me/rybakalexey). Основатель школы и автор курса Алексей Рыбак, ex-СТО Badoo, с 20-летним опытом высоконагруженных проектов и управления глобальными технологическими организациями. 🗓 Старт 7 сентября, изучаем программу, записываемся здесь Реклама. ИП Рыбак А.А. ИНН 771407709607 Erid: 2VtzqvimBRf

В Go 1.27, который вышел 19 августа, есть несколько любопытных изменений в самом языке. Дженерики на методах Раньше методы могли использовать параметры типов своего receiver’а, но не могли объявлять дополнительные. Теперь могут.

type Box[T any] struct {
 Value T
}

func (b Box[T]) Map[U any](fn func(T) U) Box[U] {
 return Box[U]{Value: fn(b.Value)}
}

Чувствую, теперь будут повсеместно фигачить магические цепочки типа таких:

result := Box[int]{Value: 42}.
 Map(strconv.Itoa).
 Map(func(s string) int {
  return len(s)
 })

fmt.Println(result.Value) // 2

С одной стороны, это хорошо для стандартной библиотеки: её API можно будет делать более гибкими. С другой стороны, чем больше обобщённых языковых конструкций, тем больше контекста может понадобиться LLM, чтобы понять, что скрывается за таким выражением. Кстати, у Google недавно была статья, в которой они утверждали, что Go — чуть ли не лучший язык для LLM. Интерфейсные методы по-прежнему не могут иметь собственные параметры типов, а generic-метод не может реализовать обычный метод интерфейса Далее, поля embedded структур теперь инициализируются проще.

type Contact struct {
 Email string
 Phone string
}

type User struct {
 Name string
 Contact
}

Раньше приходилось писать так:

user := User{
 Name: "Анна",
 Contact: Contact{
  Email: "anna@example.com",
  Phone: "+7 999 000-00-00",
 },
}

Теперь можно делать так:

user := User{
 Name:  "Анна",
 Email: "anna@example.com",
 Phone: "+7 999 000-00-00",
}

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

func FormatValue[T any](value T) string {
 return fmt.Sprint(value)
}

И мы хотим добавить её в список форматтеров. Раньше тип приходилось указывать явно:

formatters := map[string]func(int) string{
 "default": FormatValue[int],
 "hex": func(value int) string {
  return fmt.Sprintf("0x%x", value)
 },
}

В Go 1.27 можно не писать [int]

formatters := map[string]func(int) string{
 "default": FormatValue,
 "hex": func(value int) string {
  return fmt.Sprintf("0x%x", value)
 },
}

Компилятор видит, что значения map должны иметь тип func(int) string, и сам выводит для FormatValue параметр T = int. Не знаю, честно говоря, насколько это всё важно, потому что код пишет теперь LLM, а ему и так было норм 🙂 Интереснее то, что наконец-то затащили json/v2, который тупо в разы быстрее при анмаршаллинге.

Интересно, что будет с рынком IDE, таких как IntellijIdea и прочие Goland. По сути всё реже и реже нужны их могучие способности. Можно агента попросить, тоже самое сделает. А для простого просмотра кода для ревью - это уже, наверно, ту мач

Типовые косяки агентов (август 2026) У меня есть сложный проект, в котором 99% кода написано AI (код уровня подсистем ядра Linux и секурити: eBPF LSM, TPROXY, fanotify). На нём отлично видно, как кодинговые агенты лажают. Наиболее типичные ошибки, которые я замечаю: - Автоматические тесты через агента тестируют не реальные сценарии. Например, у юзера стартует один сервис, а в плейбуке в момент тестирования создается другой сервис. После чего, какие-то сценарии начинают валиться с ошибками и агент маркирует это как "Critical", заводит задачу "на серьезных щах" и даже порывается пофиксить. - Агенты переусложняют реализацию. Если дать им полную свободу продуктового мышления, то они навертят кучу сложностей, которые вообще не нужны (или не нужны в ближайшие пару лет точно) - Агенты всегда находят ошибки в ревью кода. То есть можно запускать на сложной кодовой базе ревьюер, потом фиксить его находки, запускать ещё раз, фиксить... и каждый раз получать новую порцию "проблем". После ревью агент обычно ещё делает триаж найденных задач, и часть из них становится Critical/Major ошибочно. Потому что если разбираться в продукте и его архитектуре, там из 23 найденных проблем, ну, может, три Major, остальные — можно смело засунуть в бэклог и никогда до них не дойти. - Сложные планы агенты реализуют неэффективно. Ну то есть человек смотрит на объем работ из плана и начинает отмечать кластеры работы, группировать изменения, делать сначала code complete, точечно проверять в реальных сценариях на реальных сервера, а потом уже тестить всё полными e2e. Агент (без специальных инструкций) послушно выполняет план и постоянно сползает в сторону "после каждого изменения запустить тесты". Сначала я думал, что проблема в моём харнессе вокруг проекта, но потом у меня появилось ещё три других проекта, где всё было совсем по-другому, а проблемы те же. Противоядие от этих проблем есть. Нужно понимать проект (как с технической, так и с продуктовой стороны). И иногда проваливаться очень глубоко в реализацию (когда начинается очевидный булщит вместо фикса кода). Это раздражает, но пока по-другому никак. Если что, у меня gpt-5.6-sol xhigh и Fable 5 xhigh. Другие модели работают ещё хуже (отдельная подстава с Opus 5 на который иногда делает авто-фолбэк Fable 5). — Если у вас нет таких проблем, скорее всего проект не сильно сложный. Ну или вы — чертов гений! Хочу с вами познакомиться, чтобы вы меня научили.

RYBE — одежда с твоим языком программирования (JavaScript, Python, QA, SQL, ML-engineer, Rust и другие) Где два айтишника могут познакомиться? В офисе и на конференции. Нам этого мало. Мы захотели объединить людей, у которых одни интересы. Дать возможность узнать друг друга. В метро, на прогулке, в офисе, на конференции, в походе, в баре, в самолёте. В каком-то смысле это мерч для твоего языка программирования. А что еще? - отшиваемся в Москве; - множество принтов с языками программирования (и не только); - плотный премиум-хлопок; - фичи типа люверсов для крепления пропуска, кармана для наушников и салфетки для очков, карман для телефона Выбирай свой язык, заказывай, дари, носи сам Тг канал: https://t.me/rybe_store Сайт: http://rybe.store/

GitHub добавил stacked pull requests GitHub запустил публичное тестирование stacked pull requests — цепочек связанных PR, которые нужно сливать по порядку. main └ branch-1 → PR 1 └ branch-2 → PR 2 └ branch-3 → PR 3 Например: PR 1 добавляет новую структуру данных; PR 2 использует её в API; PR 3 добавляет интерфейс. Такую цепочку можно было собрать и раньше, но следить за ветками, их порядком и обновлением приходилось вручную. Теперь GitHub встроил поддержку этого процесса: • показывает весь "стек" и порядок изменений; • в каждом PR показывает только изменения его слоя • позволяет ревьюить все части параллельно; • помогает обновлять оставшиеся ветки после слияния нижнего PR; • может слить сразу несколько готовых слоёв в правильном порядке.

Прогать с агентом зачастую выматывает сильнее, чем без него. Сначала надо сгенерить код. Это кажется просто, но перед этим действием нужно уже провести много работы, продумать требования и нюансы (ибо магии нет: говно на входе = говно на выходе). План-хуян. Потом наконец генеришь и даёшь другому агенту на ревью. Если код сложный, то в 99% случаев что-то вылезает. Ладно, чинишь. Даёшь другому агенту посмотреть. Вылезает что-то странное, ты не понимаешь, он прав или нет. Начинаешь читать код вручную (это всё равно пришлось бы делать, но надеялся, что позже, когда основное будет пофикшено). Читать чужой код, написанный инопланетянамм (сам бы так не написал). Тратишь дофигища энергии, чтобы построить в голове ментальную модель высера. Просишь объяснить тестами. Понимаешь, что это нечитаемое говно, просишь агента переделать так-то и упростить тут-то. И всё равно - ну не то, блин. Нет удовольствия от хорошо сделанной раьоты. Наконец, понимаешь, что имелось в виду на втором код ревью от агента. Начинаешь копать, и понимаешь, что это не просто корнер кейс, а возможно вообще к задаче надо было подходить по-другому, и надо обсуждать с коллегами, иьо а таком виде задачу, может, и не решить вообще. И так целыми днями. Про баги на проде я уже писал - чинить их намного сложнее, так как в голове не прошивается нужная информация. А как было раньше: моменты обдумывания чередовались моментами медитативного прописывания. Модель в мозгу выстраивалась постепенно и надолго. Было удовольствие от полученного кода. эх

apple/container — это CLI-инструмент для создания и запуска Linux-контейнеров на Mac. Релиз 1.0 был пару недель назад. Написан на Swift, разработан для Apple silicon. Работает с OCI-совместимыми образами, то есть умеет тянуть и пушить образы из обычных container registry. Apple прямо описывает его как инструмент для запуска Linux containers as lightweight virtual machines на Mac. Docker Desktop на macOS сейчас живёт вокруг большой Linux VM, внутри которой уже крутятся контейнеры. Apple сделал по-другому: каждый контейнер запускается в своей лёгкой виртуальной машине. В описании Apple говорит, что такой подход даёт каждому контейнеру изоляцию уровня VM, уменьшает объём того, что надо шарить с хоста, и при этом сохраняет время старта, сравнимое с контейнерами внутри общей VM. Стартовать сервис:

container system start

Посмотреть контейнеры:

container list --all

Можно запускать образы, собирать image из Dockerfile, работать с registry, смотреть логи, настраивать volume mounts и ресурсы. Так как контейнер — это lightweight VM, у него есть свои CPU и memory limits. По умолчанию обычный container получает 1 GB RAM и 4 CPU, а builder VM — 2 GB RAM и 2 CPU. Для тяжёлых сборок это можно подкручивать: например, container builder start --cpus 8 --memory 32g. Можно создавать отдельные изолированные networks через container network create, задавать IPv4/IPv6 subnets и запускать контейнеры в выбранной сети. Контейнеры в разных сетях друг друга не видят. Разумеется, это не значит, что Docker Desktop завтра умер: Docker - огромная экосистема, Compose, привычки, интеграции, документация, корпоративные сценарии, да и просто инерция. apple/container пока выглядит скорее как фундамент. Apple хочет, чтобы Linux-контейнеры на Mac стали частью платформы. Также, помимо cli, Apple открыла apple/containerization — Swift package для запуска Linux containers на macOS. Он даёт API для OCI images, registry, ext4 filesystems, Netlink, запуска лёгких VM, containerized processes и т.д.

Оказывается, новый http-метод QUERY опубликован как RFC 10008

о, оказывается метод QUERY теперь уже не "proposed standard", это теперь официально RFC 10008