В 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

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

Антон Жиянов написал мини-книгу по Go-concurrency. Это что-то вроде плотного конспекта с интерактивными примерами. Без пространных рассуждений.

https://antonz.org/go-concurrency-distilled/

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

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