Прогать с агентом зачастую выматывает сильнее, чем без него.

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

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

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

А как было раньше: моменты обдумывания чередовались моментами медитативного прописывания. Модель в мозгу выстраивалась постепенно и надолго. Было удовольствие от полученного кода.

эх

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;
• может слить сразу несколько готовых слоёв в правильном порядке.

Типовые косяки агентов (август 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).

—

Если у вас нет таких проблем, скорее всего проект не сильно сложный. Ну или вы — чертов гений! Хочу с вами познакомиться, чтобы вы меня научили.

В 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, который тупо в разы быстрее при анмаршаллинге.

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

(это сокращенный перевод твита)

Когда вайбкодите, не забывайте в промпт добавлять волшебную фразу "make no mistakes", а то баги будут.

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

На днях тут решил попробовать Fable 5.1 с большим Effort. Т.е. я верю, что это очень умная штука, это прям видно, но блин, пользы выдаёт ровно ноль.

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

В итоге: так ничего и не выдал, потому что сожрал весь 5-часовой лимит.

Обалдеть, что творится.

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

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

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

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

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

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