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

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

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

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

По-русски, по-английски или по-чешски (ну, а вдруг)

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

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

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

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

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

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

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

Apple запилила свой докер

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 и т.д.

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

Сначала надо сгенерить код. Это кажется просто, но перед этим действием нужно уже провести много работы, продумать требования и нюансы (ибо магии нет: говно на входе = говно на выходе). План-хуян. Потом наконец генеришь и даёшь другому агенту на ревью. Если код сложный, то в 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

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