Я активно пользовался ИИ-помощниками для разработки еще до Codex. В основном — через среды, которые сделаны именно для работы с кодом: подготовка наборов изменений, правка хранилищ кода и выпуск готовых правок.

Примерно в ноябре я начал применять их не только для программирования, но и для другой рабочей рутины. Делал презентации в Slidev, использовал ИИ-помощников как секретарей для заметок с голосового ввода и искал, какие еще материалы можно поручить такому инструменту: index.html, PDF, таблицу, набор слайдов.

Последние обновления приложения Codex впервые сделали такой широкий режим работы естественным. Codex по-прежнему хорошо справляется с кодом, но самое важное изменение в другом: он дает работе место, где она может продолжаться.

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

Два фреймворка агентов с открытым исходным кодом с пересекающимися функциями, но принципиально разной философией

На прошлой неделе кто-то в Discord-сообществе Kilo спросил: «Стоит ли мне переходить с OpenClaw на Hermes?». Я видел этот вопрос десятки раз с момента запуска Hermes в феврале. И это правильный вопрос — оба проекта с открытым исходным кодом, оба подключаются к вашим чат-приложениям, оба запускают инструменты и обладают памятью. На бумаге они выглядят почти идентично.

Но после двух месяцев использования обоих вариантов я считаю, что простое сравнение функций сбивает с толку — на самом деле они расходятся именно в философии дизайна.

Infrastructure as Code научила нас важной дисциплине: инфраструктура не должна жить только в голове. Ресурсы, настройки и изменения надо описывать, хранить в Git, применять повторяемо и обсуждать как код.

Это все еще правильная мысль. Terraform хорошо описывает ресурсы. Ansible хорошо описывает действия. CI/CD хорошо описывает путь изменения от репозитория до рабочей среды. Мониторинг хорошо ловит симптомы.

Но когда в эксплуатацию входит ИИ-агент, появляется новый вопрос: что агент должен понимать перед действием?

Не какую команду выполнить. Не какой ресурс создать. Не какой playbook применить. А именно понимать: куда он попал, что здесь считается правдой, что уже проверено, что только предполагается, какие решения нельзя повторять, какие секреты нельзя читать, что обязательно записать после изменения.

Я называю этот слой AgentOps.

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