Claude Code и новая волна терминальных ИИ-инструментов для программирования

Что на самом деле представляют собой агенты для программирования в CLI

Терминальный агент для программирования обычно объединяет пять компонентов:

• Цикл диалога с передовой или открытой моделью
• Индексатор репозитория или слой поиска файлов
• Слой выполнения инструментов для команд оболочки и редактирования файлов
• Механизм применения патчей
• Слой хранения истории диалога и состояния сеанса

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

Типичный цикл выглядит так:

User task
  ↓
Agent builds prompt from instructions + repo context + prior messages
  ↓
Model proposes actions: read file, edit file, run command
  ↓
CLI executes allowed actions
  ↓
Results are added back into context
  ↓
Model plans next step
  ↓
Repeat until done or stopped

Именно благодаря этому циклу инструменты кажутся мощными. По той же причине стоимость и задержки ведут себя иначе, чем при обычном использовании API по принципу «задать один вопрос — получить один ответ».

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

Claude Code, Aider, Cline и OpenCode: разные формы одного подхода

У инструментов разные способы взаимодействия, но основная инженерная схема похожа.

Важное различие — не в том, «какой из них умнее». Оно в том, сколько контекста отправляет инструмент, как он выбирает файлы, как сжимает историю и насколько вы контролируете выполнение команд оболочки.

Aider, например, обычно хорошо работает, когда вы целенаправленно добавляете нужные файлы. Claude Code действует более самостоятельно и может напоминать опытного инженера, работающего с разными частями репозитория, но такая автономность требует осознанного подхода к разрешениям и границам задачи. Cline удобен внутри редактора, особенно если вы хотите наблюдать за действиями, однако удобство редактора может привести к тому, что вы с лёгкостью одобрите слишком много дорогостоящих шагов.

Рабочие процессы в стиле OpenCode привлекают команды, которым нужна гибкость в выборе провайдеров: Claude для сложной архитектурной работы, GPT для реализации, Gemini для анализа большого контекста или открытые модели вроде Qwen, DeepSeek, Kimi, MiniMax и Llama для более дешёвых проходов локально или на собственной инфраструктуре.

Как эти агенты используют API

Один запрос «исправь эту ошибку» может обернуться десятками вызовов API.

Упрощённое тело запроса для одного шага агента выглядит так:

{
  "model": "claude-sonnet-4.6",
  "messages": [
    {
      "role": "system",
      "content": "You are a coding agent. Follow repo instructions. Use tools safely."
    },
    {
      "role": "user",
      "content": "Fix the failing invoice total test."
    },
    {
      "role": "assistant",
      "content": "I will inspect the test and related invoice code."
    },
    {
      "role": "tool",
      "name": "read_file",
      "content": "tests/test_invoice_totals.py contents..."
    }
  ],
  "tools": [
    { "name": "read_file" },
    { "name": "apply_patch" },
    { "name": "run_shell" }
  ]
}

Конкретные реализации различаются, но схема остаётся одной и той же:

1. CLI собирает контекст.
2. Модель определяет следующую операцию.
3. CLI выполняет операцию.
4. Результат передаётся обратно модели.
5. Модель продолжает работу.

Обычно инструменты предоставляются двумя способами.

Текстовые протоколы работы с инструментами

Некоторые агенты просят модель выдавать структурированный текст:

RUN: pytest tests/test_invoice_totals.py -q

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

Встроенный вызов функций

Другие агенты используют вызов инструментов или функций через API модели. Модель возвращает структурированный вызов инструмента:

{
  "tool_name": "run_shell",
  "arguments": {
    "command": "pytest tests/test_invoice_totals.py -q",
    "timeout_seconds": 60
  }
}

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

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

Почему циклы работы агента меняют экономику токенов

Обычная интеграция с API может отправить 2,000 входных токенов и получить 500 выходных токенов. Сеанс программирования с агентом может выглядеть так:

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

Есть четыре распространённых фактора, увеличивающих расход токенов:

• Контекст из полных файлов: отправка файлов на 900 строк, когда важны лишь две функции.
• Подробный вывод тестов: включение предупреждений о зависимостях, индикаторов прогресса и ошибок, не связанных с задачей.
• Повторные сканирования репозитория: запуск find, treeили rg с широким охватом и повторное добавление вывода в контекст.
• Неограниченная история диалога: сохранение каждой неудачной попытки вместо краткого изложения принятых решений.

В запутанном сеансе происходит вовсе не то, что «агент думает усерднее». Часто он просто видит больше устаревшего контекста. Избыток токенов может сделать модель медленнее и менее точной, если важная информация теряется в общем объёме.

Модель расчёта: бюджет на итерацию, а не на промпт

Оценивая расходы, я считаю итерации.

Небольшая задача с чёткой целью может выглядеть так:

8 turns × 12k input tokens average = 96k input tokens
8 turns × 1.5k output tokens average = 12k output tokens

Задача, в которой агент отклоняется от цели, может выглядеть так:

35 turns × 55k input tokens average = 1.9M input tokens
35 turns × 3k output tokens average = 105k output tokens

Один и тот же пользовательский промпт. Совершенно разные затраты.

Точные цены не нужны, чтобы понять суть проблемы. Масштаб сеансов работы с агентом зависит от:

total cost ≈ Σ(input_tokens_per_step × input_price)
           + Σ(output_tokens_per_step × output_price)
           + tool/runtime overhead

Выходные токены видны, потому что вы наблюдаете, как агент печатает. Входные токены скрыты, потому что их собирает CLI. Именно на этой скрытой стороне важна дисциплина расходования бюджета.

Выбор моделей для работы агента

Я редко использую одну модель для всего.

Для терминальных агентов выбор модели должен соответствовать этапу работы:

На практике можно использовать модели класса Sonnet для большинства задач программирования, модели класса Opus/GPT-5.5 для сложной отладки или проектирования, модели с длинным контекстом типа Gemini/Fable для анализа больших объёмов данных и открытые модели для локального рефакторинга по правилам линтера. Конкретные названия будут меняться; подход останется тем же.

Распространённая ошибка — использовать самую дорогую модель на протяжении всего цикла. Тогда дорогая модель тратит токены по премиальной цене на чтение node_modulesи сопутствующего информационного шума, предупреждений тестов и сгенерированных файлов. Приберегите самую сильную модель для решений, которым она действительно нужна.

Важные советы по настройке

Лучшая настройка — не «максимальная автономность», а «быстрая обратная связь с ограниченными разрешениями».

1. Игнорируйте сгенерированные файлы и файлы сторонних зависимостей

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

node_modules/
dist/
build/
coverage/
.venv/
__pycache__/
target/
vendor/
*.lock
*.min.js
*.map

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

2. Используйте узконаправленные команды запуска тестов

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

# First loop: fastest relevant test
pytest tests/billing/test_invoice_totals.py -q

# Second loop: nearby package
pytest tests/billing -q

# Final confidence check
pytest -q

Для JavaScript или TypeScript:

pnpm test invoice-total.test.ts -- --runInBand
pnpm lint src/billing
pnpm test

Дело не только во времени выполнения. Чем меньше вывод, тем меньше промпт на следующей итерации.

3. Ограничивайте объём вывода команд

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

pytest tests/billing -q 2>&1 | tail -120

Или для сборок с большим объёмом вывода:

pnpm test 2>&1 | grep -E "FAIL|Error|Expected|Received|at " | head -200

Будьте осторожны: фильтрация может скрыть полезный контекст. Я использую её после первого сбоя, а не до него. Сначала выясните характер сбоя, затем ограничьте вывод повторных запусков.

4. Просите точечные изменения, а не полную перезапись

Для больших файлов явно укажите агенту:

Make the smallest safe patch. Do not rewrite unrelated functions.
Show a concise diff summary before running tests.

Это снижает риск и обычно уменьшает число выходных токенов. Что ещё важнее, так проверка кода остаётся разумной по объёму.

5. Отделяйте планирование от выполнения

Для нетривиальных изменений я часто начинаю с такого запроса:

Inspect the relevant files and propose a plan. Do not edit yet.
Limit repo inspection to payment, invoice, and tax modules unless needed.

Затем я утверждаю план и позволяю агенту реализовать его. Это помогает избежать ситуации, когда агент вносит изменения, не разобравшись в задаче.

Контроль расходов во время длительных сессий

Именно в длительных сессиях CLI-агенты раскрывают свои возможности — и становятся опасными.

Вот контрольный список для управления расходами, который я использую в реальной работе:

• Задайте цель сессии: «Добейся, чтобы test_invoice_rounding проходил», а не «исправь биллинг».
• По возможности явно указывайте файлы: указывайте точные пути вместо того, чтобы просить агента самостоятельно всё найти.
• Сбрасывайте контекст при смене направления: когда задача меняется, начинайте новую сессию с кратким изложением текущего состояния.
• Вручную обобщайте ошибки: вставляйте важные 30 строк, а не лог на 3,000 строк.
• Осознанно переходите к более мощным моделям: используйте более мощную модель только после того, как возникло явное препятствие.
• Останавливайтесь при повторении неудачных циклов: если агент дважды терпит неудачу одним и тем же способом, вмешайтесь.

Хороший запрос для перезапуска выглядит так:

We are fixing invoice rounding.

Known facts:
- Failure is in tests/billing/test_invoice_totals.py::test_round_half_even
- Expected 10.24, actual 10.25
- Decimal quantization happens in src/billing/money.py
- Tax calculation calls round_money() from src/billing/tax.py

Continue from this summary. Inspect only those files first.

Такой запрос может обойтись дешевле и быть понятнее, чем перенос всей неудачной переписки.

Ключи API, провайдеры и маршрутизация

Большинство CLI-агентов могут обращаться к API провайдера моделей напрямую или через совместимый шлюз. Ключевые инженерные вопросы:

• Аутентификация: где хранятся ключи API и не попадают ли они в историю команд оболочки или логи.
• Маршрутизация моделей: какая модель отвечает за какой этап.
• Ограничения частоты запросов: циклы работы агента могут быстро создавать всплески запросов.
• Наблюдаемость: отчётность по токенам и стоимости для каждой сессии.
• Границы передачи данных: можно ли отправлять код во внешние API.

Минимальная настройка окружения часто выглядит так:

export ANTHROPIC_API_KEY="..."
export OPENAI_API_KEY="..."
export GEMINI_API_KEY="..."

Для команд я предпочитаю скрипт-обёртку, который выбирает модели и записывает данные об использовании:

#!/usr/bin/env bash
set -euo pipefail

export AGENT_MODEL="${AGENT_MODEL:-sonnet}"
export AGENT_MAX_OUTPUT_TOKENS="${AGENT_MAX_OUTPUT_TOKENS:-4096}"
export AGENT_SESSION_BUDGET_USD="${AGENT_SESSION_BUDGET_USD:-10}"

coding-agent "$@"

Если вы используете шлюз для нескольких моделей, он может пригодиться для маршрутизации запросов к Claude, GPT, Gemini или открытым моделям через единый интерфейс. Важен не список логотипов, а наличие надёжного учёта использования и средств управления на уровне моделей.

Что я включаю в инструкции репозитория

Большинство агентов учитывают ту или иную форму файла с инструкциями репозитория. Мои инструкции короткие и практичные:

## Agent Instructions

- Prefer minimal diffs over rewrites.
- Do not run full test suites until targeted tests pass.
- Never edit generated files in `dist/`, `build/`, or `coverage/`.
- Use `rg` for search.
- Before large refactors, propose a plan and wait.
- If a command emits more than 200 lines, rerun with a narrower command.

Дело не в вежливости. Инструкции определяют рабочий цикл. Агент всё равно будет ошибаться, но хорошие инструкции сокращают повторные бесполезные затраты.

Распространённая ловушка: слишком длинные файлы инструкций превращаются в фоновый шум. Если ваши инструкции для агента — это 300 строк рассуждений о стиле, модель может пропустить три важных рабочих ограничения. Размещайте наиболее ценные правила в начале.

Задержка: ещё одна составляющая затрат

Даже при приемлемых расходах на токены задержки могут разрушить рабочий ритм.

Задержка при работе агента складывается из:

• Времени выполнения модели
• Времени выполнения инструментов
• Времени индексации файлов
• Времени выполнения тестов
• Пауз на одобрение человеком

Для коротких рабочих циклов я оптимизирую «время до следующего полезного результата». Целевой тест за 15 секунд лучше полной имитации CI за 6 минут. Менее мощная модель, которая правильно определяет синтаксическую ошибку за 4 секунд, лучше премиальной модели, которая тратит 45 секунд на красивое объяснение.

Лучшие сессии напоминают парное программирование:

inspect → patch → targeted test → inspect failure → patch → targeted test → final suite

Худшие сессии напоминают косплей CI:

scan repo → edit many files → run everything → drown in logs → repeat

Ограничения и типичные сбои

Терминальные агенты полезны, но не творят чудес.

Они испытывают трудности, когда:

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

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

Безопасность тоже важна. Не предоставляйте агенту неограниченный доступ к оболочке в репозитории с чувствительными данными, не разобравшись в механизме одобрения действий инструмента. Возможность «выполнять команды» включает вывод переменных окружения, изменение файлов, установку пакетов и обращения к сети, если это не ограничено.

Практические рекомендации

• Рассматривайте CLI-инструменты для программирования как циклы управления через API, а не как отдельные запросы.
• Оптимизируйте затраты, сокращая число циклов и размер контекста, особенно вывод команд.
• Используйте мощные модели для сложных рассуждений, а не для каждого механического шага.
• Делайте инструкции репозитория короткими, практичными и ориентированными на поведение агента.
• Сначала запускайте целевые тесты, а в конце — более широкую проверку.
• Перезапускайте длительные сессии с краткими сводками вместо переноса устаревшей истории.
• Следите за входными токенами: это скрытый источник затрат при программировании с агентами.
• Останавливайтесь и вмешивайтесь, когда агент повторяет одну и ту же неудачную стратегию.

Claude Code, Aider, Cline и OpenCode — часть реальных перемен: помощь в программировании переходит от механизмов подсказок к полноценным помощникам, работающим в терминале. Больше всего выиграют команды, которые не просто «включат агентов», а спроектируют рабочий цикл: ограниченный контекст, безопасные инструменты, прозрачные расходы и проверка на каждом шаге.