Почему CLI-инструменты снова стали важны? Теперь ими пользуются AI-агенты

Я всё чаще ловлю себя на странной мысли: хорошие внутренние CLI-инструменты стали ценнее, чем были пару лет назад.

Раньше это была история про удобство разработчика. Сделал себе маленькую утилиту, чтобы не кликать в AWS-консоли, не вспоминать длинную команду или не собирать jq-пайплайн. Удобно, но локально. Твой личный костыль, максимум — инструмент для команды.

С AI-агентами эта логика поменялась. CLI теперь не только для человека. Им может пользоваться Claude Code, Codex, OpenCode или любой другой агент, которому ты доверил терминал.

Маленький пример: CloudWatch Insights без консоли

На Hacker News сегодня увидел пост Мартина Скэгедала про его cloudwatch-insights tool. Это небольшая CLI-утилита для работы с AWS CloudWatch Insights.

Вместо того чтобы идти в AWS-консоль, выбирать log groups, настраивать time range и копировать запросы руками, ты запускаешь команду из репозитория нужного сервиса:

cd ~/code/some-service
cloudwatch-insights query --new --env prod

Инструмент берёт конфигурацию из контекста проекта: какие log groups использовать, какой app filter подставить, какой env выбран. Потом создаёт query-файл, открывает его в $EDITOR, запускает запрос и сохраняет результат локально в JSONL.

То есть вместо “зайди в консоль, найди нужный сервис, найди нужные логи, отфильтруй ошибки” получается воспроизводимый workflow:

cloudwatch-insights query --new --env prod
cloudwatch-insights show

А вот так это может использовать агент:

claude -p 'Run "cloudwatch-insights show" and fix the errors.'

CLI становится интерфейсом для агента

Мы привыкли думать про CLI как про интерфейс для человека. Человек читает help, запускает команду, смотрит вывод, принимает решение.

Но агенту такой интерфейс тоже подходит.

У CLI есть несколько свойств, которые внезапно стали очень полезными:

• команды можно выполнять из терминала;
• результат можно сохранить в файл;
• вывод можно передать в модель;
• поведение проще повторить;
• действия легче логировать и проверять.

Для AI-агента это почти идеальная поверхность. Не надо учить его кликать по консоли. Не надо делать скриншоты. Не надо объяснять, где в AWS находится нужная кнопка.

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

А как же MCP?

Тут легко уйти в привычный рефлекс: если нужно подключить агента к инструменту, значит нужен MCP-сервер.

MCP хорош, когда нужен явный контракт: список тулов, схемы аргументов, permissions, discovery, интеграция с разными клиентами. Если ты делаешь инструмент для внешних пользователей или хочешь нормальную агентскую инфраструктуру, MCP выглядит логично.

Но для внутренних workflows иногда обычный CLI проще.

У тебя уже есть авторизация через AWS. Уже есть локальный контекст репозитория. Уже есть привычный формат файлов. Уже есть терминал, в котором работает агент. Зачем добавлять ещё один слой, если агент может вызвать ту же команду, что и ты?

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

Иногда лучший инструмент для агента — это маленькая команда, которая хорошо делает одну вещь.

Что это меняет для разработки внутренних инструментов

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

Во-первых, вывод должен быть машинно-читаемым. JSONL, JSON, понятные exit codes, стабильные поля. Красивые таблички удобны человеку, но агенту проще работать с данными.

Во-вторых, команды должны быть предсказуемыми. Если show сегодня показывает последние результаты, а завтра внезапно открывает интерактивный pager, агент сломается. Человек разберётся. Агент начнёт делать странное.

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

В-четвёртых, полезны dry-run режимы. Агент может сначала показать, что собирается сделать, а человек уже подтвердит.

И наконец, help должен быть нормальным. Не для красоты. Модели реально читают --help и README, когда пытаются понять, как пользоваться инструментом.

Что можно сделать у себя

Я бы начал не с MCP-сервера и не с большой платформы автоматизации. Начал бы с инвентаризации скучных команд.

Где разработчики чаще всего ходят в UI?

• посмотреть production-логи;
• найти ошибки по request id;
• проверить статус очередей;
• посмотреть деплой;
• вытащить последние failed jobs;
• собрать диагностический bundle для инцидента.

Если действие повторяется каждую неделю, его можно завернуть в CLI. Если CLI возвращает нормальный текст или JSON, его уже может использовать агент.

Дальше появляются сценарии:

agent logs errors --service billing --env prod --since 1h
agent deploy status --service api
agent incident bundle --request-id abc123

Названия условные. Смысл не в них. Смысл в том, что AI-агенту не нужен доступ “ко всему”. Ему нужны узкие, понятные ручки к реальным рабочим процессам.

Вывод

История с cloudwatch-insights хороша не самой утилитой. Хотя утилита полезная. Она хорошо показывает новый паттерн: внутренние CLI становятся API для AI-агентов.

Не каждый такой инструмент надо превращать в MCP-сервер. Не каждый workflow нужно тащить в платформу. Иногда достаточно маленькой команды.

Раньше мы писали такие инструменты, чтобы меньше кликать самим. Теперь их стоит писать ещё и потому, что ими будет пользоваться кто-то кроме нас. Например, Claude, когда ты попросил его разобраться с ошибками в логах.

И да, это звучит чуть странно. Но, кажется, именно так agentic development и будет проникать в обычную инженерную рутину: не через один большой “AI для всего”, а через десятки маленьких CLI, которые наконец-то начали окупаться.

FAQ

Нужно ли делать MCP-сервер для каждого внутреннего инструмента?

Нет. Если инструмент нужен внутри команды и уже хорошо работает из терминала, обычный CLI может быть проще. MCP полезен, когда нужны схемы tools, discovery, permissions и поддержка разных клиентов.

Почему CLI удобен для AI-агентов?

AI-агент может запускать CLI из терминала, читать stdout, сохранять результаты и передавать их дальше в анализ. Это проще и надёжнее, чем заставлять агента работать через графический интерфейс.

Что важно в CLI, которым будет пользоваться AI-агент?

Стабильный вывод, машинно-читаемые форматы, понятные exit codes, хороший --help, dry-run режимы и разделение безопасных и опасных команд.

Чем CLI отличается от API для агента?

Для агента CLI часто и есть локальный API. Он менее формальный, чем HTTP или MCP, но зато живёт в той же среде, что и разработчик: в репозитории, терминале и shell workflow.