На этой неделе вокруг инструментов для разработки с ИИ сложилась одна общая картина: coding agents перестали быть просто умными помощниками в редакторе. Они становятся частью инфраструктуры разработки — с собственными рантаймами, лимитами, окнами контекста, политиками безопасности, кэшем, доступом к shell и экономикой, которая может меняться без привычной для enterprise предсказуемости.

ИИ-агенты для программирования как инфраструктура разработки

Поводом стала проверка Simon Willison: он посмотрел локальный бинарник Claude Code и нашёл признаки Bun 1.4 и Rust-исходников. Это совпадает с рассказом Jarred Sumner о переписывании Bun с Zig на Rust и с материалом Anthropic о крупных миграциях с Claude Code. История интересна не только тем, что большой JavaScript runtime переезжал при активной помощи агента. Важно другое: агент сам уже использует изменившийся runtime, а большинство пользователей этого почти не заметили.

Почему тихая замена рантайма важна

В обычной инфраструктуре тихая внутренняя замена может быть хорошим знаком: если тесты зелёные, пользователю не обязательно знать каждую деталь. Но coding agent — не обычный чат-клиент. Он читает репозиторий, меняет файлы, запускает команды, передаёт контекст модели и просит человека подтверждать действия. Поэтому его бинарник, bundled runtime и update channel становятся частью SDLC, а не мелкой деталью установки.

Это не обвинение в адрес Anthropic или Bun. Наоборот, если переписывание действительно прошло через строгие тесты, компилятор и ревью, это зрелый инженерный пример. Но для компаний вывод практический: agent binary нужно версионировать, проверять changelog, понимать bundled компоненты, иметь rollback и не пускать самoобновляющийся инструмент в важные репозитории без контроля.

Что показывает миграция Bun

Оптимистичная часть истории тоже сильна. Подход Anthropic к миграциям выглядит не как магия, а как дисциплина: rulebook, карта зависимостей, stress tests, компиляция, поведенческие проверки, adversarial review и повторяющиеся циклы исправлений. Именно в такой среде языковые модели полезны: они ускоряют повторяющуюся работу, а качество удерживают тесты и люди.

Командам стоит перенять не цифру “миллион строк”, а процесс вокруг неё. Если есть тесты, понятные критерии и маленькие итерации, агент может помочь при переезде между языками, фреймворками, build-системами и крупными зависимостями. Если тестов нет, огромный diff от агента — это не модернизация, а большой риск с красивым описанием.

Контекст, квоты и безопасность стали контрактом продукта

Обсуждение Codex показывает другую сторону. Для разработчика размер context window — не абстрактное число токенов. Это способность агента помнить план, ограничения, причины уже отвергнутых гипотез и детали архитектуры. Если фактическое окно уменьшается, часть рабочих сценариев меняется. Compaction помогает в простых задачах, но в сложной отладке или миграции может потерять именно те детали, ради которых агент был полезен.

Квоты и reset windows — тоже уже не бытовая проблема подписки. Если команда строит процесс миграции или ревью вокруг агента, она должна понимать лимиты, fallback-модели, стоимость контекста и стабильность доступа. Иначе производительность превращается в угадывание поведения провайдера.

Отдельный слой — safety prompts и destructive-action rules. Хорошо, что инструменты добавляют ограничения на опасные рекурсивные команды. Плохо, если вся безопасность живёт только в скрытых системных инструкциях. Нужны внешние границы: контейнеры, disposable worktrees, запрет доступа к $HOME, изоляция секретов, журналы команд и CI как обязательный gate.

Open-source агент не отменяет governance

Дискуссия вокруг OpenCode полезна именно как список вопросов. Видимый исходный код помогает, но не делает harness безопасным автоматически. Нужно понимать, что инструмент читает, куда отправляет данные, как работает кэш, как устроена compaction, можно ли жёстко запретить remote providers, насколько точны permission prompts и можно ли запускать агент в network-restricted контейнере.

Те же вопросы относятся к закрытым продуктам и внутренним форкам. Выбирать нужно не только “какая модель лучше пишет код”, а какая связка model + harness + permissions + logs + policy подходит конкретному классу репозиториев.

Что делать командам

Первый шаг — инвентаризация. Скорее всего, разработчики уже используют несколько агентов: Claude Code, Codex, IDE-плагины, open-source CLI, локальные обёртки. Цель не наказать, а увидеть поверхность риска.

Второй шаг — классы доступа. Публичный demo repo, внутренний сервис, regulated product и infrastructure-as-code не должны иметь одинаковые права агента. Где-то достаточно read-only анализа, где-то можно разрешить правки в отдельной ветке, где-то shell только в контейнере, а где-то агент не должен видеть секреты и production-токены вообще.

Третий шаг — version pinning и журналирование. Фиксируйте версию агента, модель, runtime, настройки и разрешённые инструменты. Если меняется окно контекста или bundled runtime, команда должна связать изменение поведения с конкретным релизом.

Четвёртый шаг — тесты как контракт. Сильный вывод из истории Bun не в том, что ИИ “может всё переписать”, а в том, что компилятор, тесты и ревью превращают большую автоматизированную миграцию в проверяемую работу. Если тестов мало, сначала используйте агента для characterization tests, а не для массового rewrite.

Чего ждать от vendors

Профессиональным agent products нужны нормальные operational contracts: changelog для runtime/model/context/cache/safety changes, стабильные enterprise channels, понятные квоты, admin controls, local-only режимы, политика сети и workspace boundaries. Если инструмент поставляет runtime внутри бинарника, версия и лицензии должны быть видны без reverse engineering. Если безопасность зависит от prompt policy, администратор должен видеть и усиливать её реальными ограничениями.

Итог простой: coding agents уже достаточно полезны, чтобы менять большие кодовые базы, и достаточно сильны, чтобы требовать инфраструктурного контроля. Их output — только часть системы. Рантайм, контекст, квоты, sandbox и approval model теперь тоже часть software supply chain.