Не так давно я на ровном месте занялся написанием библиотеки на Go (spinq) для, казалось бы, тривиальной задачи — спиннера, который гарантированно не будет ломаться при конкурентных записях в stderr и stdout.

Все началось с того, что я писал вообще другой код — консольную утилиту для запуска тестов. И захотел прикрутить туда спиннер. Но не просто спиннер, а такой, что позволил бы использовать оба потока вывода — stderr и stdout, без риска оставить артефакты на экране. Более того, во время анимации мне нужно иметь возможность показывать на экране отчеты по завершившимся тестам, не откладывая это все до конца запуска/остановки спиннера. И так уж почему‑то получилось (спойлер: потому что не слишком просто, иногда совсем невозможно и мало кому нужно), что я не смог найти библиотеку, которая бы мне подошла.

С последними апдейтами Claude Code и Codex CLI классические сабагенты потеряли смысл. Сессии научились общаться между собой напрямую.

В сообществе всё чаще отключают автоматический спавн и отказываются от тяжелых ролевых конфигов: на Hacker News разработчики делятся воркэраундами, закрывают права через deny: [Agent(Explore)] или запускают CLI с флагом --disallowedTools Task, возвращая управление в свои руки.

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

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

Привет, Хабр! Обычно материалы о разработке агентов посвящены успешному успеху: «Мы выбрали лучшую модель, собрали агента, подключили инструменты — и все заработало». Но недавно мне попался отчет о создании ИИ-агента Shippy, где авторы честно рассказали о сложностях проекта и ограничении технологии ИИ. Предлагаю разобрать, как же удалось их преодолеть.

Спойлер: главная проблема даже не в том, что модель плохо работает с API, файлами или последовательностями действий, а в том, что от нее требовали поведения, для которого вероятностная модель плохо подходит: помнить множество правил, надежно выполнять детерминированные операции и самостоятельно контролировать корректность собственных действий. Как только эту строгую часть выделили в отдельный слой, дело пошло на лад.