A tese do CLI

Três discussões no Hacker News em uma semana. 1.638 pontos combinados. Uma conclusão: a IDE é para humanos. O CLI é para agentes.¹²³

A separação planejamento/execução de Boris Tane (716 pontos) roda inteiramente no terminal.¹ A análise “Tornando MCP mais barato via CLI” (304 pontos) mediu uma redução de 94% em tokens ao substituir chamadas de ferramentas MCP por claude --print.³ O projeto just-bash da Vercel (87 pontos) demonstrou que remover 80% das ferramentas de um agente tornou tudo mais rápido, mais barato e mais confiável.⁴ Um benchmark separado constatou que abordagens CLI usam 35x menos tokens que MCP para tarefas equivalentes.¹⁰

O padrão continua aparecendo porque a arquitetura o impõe. Agentes precisam de composabilidade, capacidade de script e overhead mínimo. CLIs fornecem os três. IDEs não fornecem nenhum.

TL;DR

A arquitetura de agentes CLI-first custa 94% menos em overhead de tokens do que abordagens baseadas em MCP, roda 3,5x mais rápido e se compõe com ferramentas Unix padrão. A separação planejamento/execução funciona porque artefatos CLI são arquivos markdown portáveis, não estado de IDE. O Remote Control torna agentes CLI supervisionáveis remotamente sem sacrificar a vantagem de composabilidade. Todo sistema de agentes sério converge para o terminal porque o terminal é onde a automação já vive.

A separação planejamento/execução

Boris Tane documentou um fluxo de trabalho em três fases que 454 comentaristas do HN validaram com suas próprias variações: pesquisa, planejamento, implementação.¹ A observação crítica: nunca deixe o agente escrever código até que você tenha revisado e aprovado um plano escrito.

O fluxo de trabalho produz artefatos markdown em cada etapa. research.md captura a análise do codebase. plan.md captura a estratégia de implementação com trechos de código. O desenvolvedor revisa no editor, adiciona anotações inline e envia o plano anotado de volta com uma instrução explícita: “não implemente ainda.” O ciclo de anotação se repete de uma a seis vezes antes que uma única linha de código seja escrita.

O loop inteiro roda através do claude no terminal. Sem plugin de IDE. Sem ferramenta visual de diff. Arquivos markdown entram, arquivos markdown saem. Os artefatos sobrevivem à compactação da janela de contexto porque existem como arquivos, não como estado de conversa.

Meu loop autônomo implementa a mesma separação em escala de máquina. Um arquivo PRD define histórias com critérios de aceitação. Um agente novo é criado para cada história, recebendo um briefing do estado atual do git e do que agentes anteriores realizaram. O agente implementa, um verificador independente roda os testes (nunca confiando no autorrelato do agente), e três revisores de código avaliam o diff em paralelo. Toda a orquestração roda através de chamadas claude --print em scripts bash. Sem framework, sem runtime, sem servidor.

A separação planejamento/execução funciona no terminal porque o terminal torna a separação estrutural. O planejamento produz arquivos. A execução consome arquivos. A fronteira entre as duas fases é um arquivo no disco, visível e auditável, não uma transição de estado enterrada dentro de um plugin de IDE.

Por que CLI supera IDE para agentes

O argumento se sustenta em três pilares: custo, composabilidade e eficiência de contexto.

Custo: redução de 94% em tokens

Kan Yilmaz mediu o overhead de tokens de MCP versus CLI em quatro cenários.³ Os números contam a história completa:

MCP injeta schemas de ferramentas em cada conversa. Com 84 ferramentas, o overhead de schema sozinho consome 15.540 tokens antes do agente fazer qualquer trabalho. Chamadas CLI não carregam overhead de schema porque os modelos já entendem interfaces de linha de comando padrão.¹⁰ Um usuário documentou MCP_DOCKER consumindo 125.964 tokens em 135 ferramentas.¹⁴

Jannik Reinhard executou um benchmark paralelo em uma tarefa de conformidade Intune: 145.000 tokens via MCP versus 4.150 tokens via CLI para output equivalente.¹⁰ O agente CLI tinha 95% da sua janela de contexto disponível para raciocínio. O agente MCP gastou a maior parte do seu orçamento em definições de ferramentas.

Composabilidade: pipes Unix já funcionam

A equipe v0 da Vercel removeu 80% das ferramentas do agente e as substituiu por um único ambiente bash.⁹ Os resultados:

Andrew Qu explicou o raciocínio: “Estávamos resolvendo problemas que o modelo conseguia resolver sozinho.” Sistemas de arquivos, grep, pipes e redirecionamentos já se compõem. Os modelos os entendem. Construir ferramentas MCP customizadas para operações que cat | grep | jq já resolve nativamente adiciona overhead sem adicionar capacidade.¹³

A própria documentação da Anthropic confirma o padrão. Claude Code segue a filosofia Unix: encaminhe logs para ele, rode-o no CI, encadeie-o com outras ferramentas.⁵ O modo headless (claude -p) suporta saída JSON estruturada, imposição de schema e retomada de sessão via IDs de sessão capturados. A Anthropic posiciona o modo headless como o caminho principal de integração para CI/CD e fluxos de trabalho com scripts.⁵

Simon Willison enquadra a implicação: escrever código é barato agora.⁶ O corolário que ninguém quer ouvir é que a verificação agora é a parte cara. Agentes CLI se compõem com a infraestrutura de verificação existente. Runners de teste, linters, checkers de tipo, scanners de segurança, pipelines de deploy: todos são ferramentas de linha de comando. Um agente IDE precisa de um plugin para cada um. Um agente CLI faz pipe para eles.

Eficiência de contexto: raciocinar sobre sinal, não ruído

A janela de contexto é finita. Cada token gasto em schemas de ferramentas, histórico de conversa e overhead MCP é um token indisponível para raciocínio. A arquitetura CLI mantém o orçamento de contexto enxuto por design.

Uma chamada claude --print nova recebe um prompt focado (~2K tokens) em vez de herdar um contexto de conversa completo (~100K+ tokens). Cada operação começa limpa. Sem estado acumulado. Sem definições de ferramentas obsoletas. Sem desvio de conversa.

Minha infraestrutura executa 84 hooks em 17 eventos de ciclo de vida, todos orquestrados através de chamadas CLI. Cada instância de agente recebe um briefing: estado atual do git, um resumo do que agentes anteriores realizaram e os critérios de aceitação para sua única tarefa. Briefing em vez de memória. Modelos executam um briefing claro melhor do que navegam 30 passos de contexto acumulado.

Uma análise acadêmica da filosofia Unix em sistemas agênticos formalizou o princípio: colapsar interfaces diversas em uma abstração uniforme, aceitando alguma perda de especialização em troca de composabilidade e tratabilidade.¹¹ Abstrações baseadas em arquivos e especificações baseadas em código reduzem a carga cognitiva e de engenharia. Agentes CLI herdam 50 anos desse trabalho de design.

Remote Control muda a equação

A objeção óbvia a agentes CLI-first: você perde o feedback visual de uma IDE. A Anthropic lançou uma resposta em 25 de fevereiro de 2026. O Remote Control conecta a uma sessão local do Claude Code a partir de qualquer navegador ou do aplicativo móvel Claude.² O recurso conquistou 531 pontos e 313 comentários no Hacker News.

O Remote Control não move nada para a nuvem. O agente continua rodando localmente. A sessão do terminal se registra na API da Anthropic via TLS e faz polling por trabalho. Todo o tráfego passa por HTTPS de saída. Nenhuma porta de entrada aberta.²

O recurso resolve a lacuna de supervisão. Antes do Remote Control, agentes CLI tinham dois modos: supervisionado (ficar no terminal) ou não supervisionado (sair e torcer). O Remote Control cria um terceiro: governança assíncrona. Prompts de aprovação são enviados para o seu celular. Você aprova, rejeita ou redireciona de qualquer lugar.

Meu sistema de hooks classifica operações por raio de impacto. Operações locais (escrita de arquivos, execução de testes) são aprovadas automaticamente. Operações compartilhadas (commits git) alertam. Operações externas (pushes, deploys) são encaminhadas para revisão humana. O Remote Control transforma esse caminho de “encaminhar” de uma espera bloqueante em uma notificação assíncrona. O agente continua trabalhando na próxima história enquanto eu reviso a anterior pelo celular.

A IDE se torna uma camada de exibição, não o ambiente de execução. Você monitora o progresso pelo Remote Control. Você intervém quando portões de qualidade sinalizam um problema. O agente CLI faz o trabalho. A IDE mostra o resultado.

O padrão do agente Bash

O just-bash da Vercel é um ambiente bash simulado com um sistema de arquivos virtual em memória, construído especificamente para agentes de IA.⁴ O design codifica três convicções sobre arquitetura de agentes:

Isolamento sobre sandboxing. Cada chamada roda em isolamento. Variáveis de ambiente, funções e diretório de trabalho são resetados entre chamadas. O sistema de arquivos persiste. Carregamento lazy significa que os arquivos são carregados na primeira leitura e ficam em cache, nunca carregando arquivos que o agente escreveu antes de lê-los. O agente não consegue contaminar seu próprio ambiente entre operações.

Ferramentas existentes sobre ferramentas customizadas. Grep tem 50 anos e faz exatamente o que ferramentas MCP de busca customizadas replicam. jq parseia JSON. curl busca URLs. O modelo conhece essas interfaces dos dados de treinamento. Ferramentas customizadas requerem injeção de schema e documentação. Ferramentas padrão não requerem nenhum dos dois.

Arquitetura mínima sobre arquitetura de framework. Andrew Qu capturou o princípio: “Os modelos estão ficando mais inteligentes e as janelas de contexto estão ficando maiores, então talvez a melhor arquitetura de agentes seja quase nenhuma arquitetura.”¹³

Meu harness valida o padrão em escala de produção. Aproximadamente 15.000 linhas de bash orquestrando Claude Code. 84 hooks em 17 tipos de eventos. Dispatchers, portões de qualidade, integração de busca semântica, loops autônomos. Sem runtime Python, sem dependência de framework. As arestas brutas do bash (sem JSON nativo, sem async, sem estruturas de dados adequadas) são reais, mas solucionáveis. jq cuida do JSON. Processamento sequencial é na verdade um recurso: portões devem rodar em ordem, não competir.

O padrão funciona porque orquestração de agentes é fundamentalmente sobre ler stdin, tomar uma decisão e escrever stdout. Essa descrição corresponde exatamente ao propósito de design do bash. Qualquer coisa mais complexa indica que a decomposição da tarefa estava errada, não a ferramenta.

Custo como decisão de arquitetura

Decisões de custo se compõem. Escolher CLI em vez de MCP para operações stateless economiza 94% por invocação.³ Com 100 operações por dia, a economia chega a $228/mês apenas em overhead de definição de ferramentas.³ Essa economia libera orçamento para mais operações, o que gera mais economia. A arquitetura se paga sozinha.

Três camadas de custo se compõem independentemente:

Camada de tokens. Compressão do system prompt. Eu rodo ~3.500 tokens de system prompt em um arquivo CLAUDE.md e 8 arquivos de regras. Restrições superam explicações. “Rejeitar chamadas de ferramentas que correspondam a caminhos sensíveis” faz o mesmo trabalho que uma explicação de 15 linhas sobre por que credenciais devem permanecer protegidas. A documentação de boas práticas da Anthropic enfatiza o mesmo ponto: o desempenho da janela de contexto degrada conforme ela enche.⁷ Cada token desperdiçado custa duas vezes: uma vez em cobranças diretas da API, novamente em qualidade de raciocínio degradada.

Camada de agentes. Instâncias novas em vez de conversas longas. Cada história em uma execução autônoma recebe um novo agente com uma janela de contexto limpa. Geoffrey Huntley documentou um padrão similar chamado “The Ralph Loop”, rodando desenvolvimento autônomo a $10,42/hora no Sonnet.¹² O contexto nunca infla porque cada agente começa do zero. Cache hits no system prompt custam 90% menos ($0,50 vs $5,00 por milhão de tokens no Opus 4.6), então o system prompt repetido entre instâncias novas carrega overhead mínimo.⁸

Camada de arquitetura. CLI para operações stateless, MCP para stateful. Uma chamada claude --print para uma avaliação one-shot não adiciona overhead de conexão. MCP faz sentido quando a ferramenta precisa de estado persistente ou streaming. A maioria das operações de agentes são avaliações one-shot, classificações ou tarefas de geração de código. CLI lida com todas elas a menor custo e com debugging mais simples.

Um exemplo concreto do meu loop autônomo na semana passada: cinco histórias PRD processadas durante a noite.¹⁵ Cada história criou um agente novo (~2K tokens de briefing), rodou a implementação (~15K tokens em média), depois criou três agentes de revisão (~2K tokens cada). Total por história: ~23K tokens. O mesmo fluxo de trabalho em uma conversa MCP de longa duração carregaria ~100K+ tokens de contexto acumulado por história até a terceira história. Cinco histórias via CLI: ~115K tokens no total. Cinco histórias via conversa MCP: ~500K+ tokens no total. A razão de custo se compõe a cada história adicional.

Quando MCP ainda ganha

A tese do CLI não argumenta contra MCP universalmente. MCP ganha em cenários específicos onde CLI fica aquém.

Servidores de ferramentas com estado. Um navegador de banco de dados que mantém um pool de conexões entre chamadas se beneficia do modelo de servidor persistente do MCP. Reconectar a cada chamada CLI adiciona latência e overhead de autenticação. Se a ferramenta precisa de estado entre invocações, MCP é a escolha correta.

Validação estruturada. Schemas de ferramentas MCP impõem contratos de entrada/saída. Uma chamada CLI aceita texto arbitrário. Quando o agente deve fornecer entrada estruturada correspondendo a um schema preciso (formato de chave API, intervalos de datas, opções enumeradas), o schema MCP captura entrada malformada antes da ferramenta processá-la. Validação CLI requer que a própria ferramenta ou um script wrapper imponha as restrições.

Controle de acesso multi-tenant. Servidores MCP podem impor permissões por usuário de forma centralizada. Ferramentas CLI herdam as permissões do usuário do sistema operacional. Em ambientes de equipe onde diferentes agentes precisam de diferentes níveis de acesso, MCP fornece autorização de granularidade mais fina.

Respostas em streaming. Operações de longa duração que produzem saída incremental (tail de logs, progresso de build, exportações de banco de dados) funcionam melhor através do protocolo de streaming do MCP do que através de uma chamada CLI que bloqueia até a conclusão.

A regra de decisão: se a operação é stateless e one-shot, use CLI. Se a operação requer estado persistente, contratos estruturados ou streaming, use MCP. No meu harness, aproximadamente 90% das operações são stateless. Os 10% que precisam de MCP genuinamente se beneficiam dele. Otimizar os 90% gera o maior retorno.

O que você pode construir hoje

Três padrões, cada um construível em uma tarde, cada um se compondo com os outros.

Padrão 1: separação planejamento/execução

# Plan phase: research and plan, no implementation
claude -p "Research the codebase and write research.md" \
  --allowedTools "Read,Glob,Grep,Write"

# Review: read annotations in research.md, write plan.md
claude -p "Read my annotations in research.md and write plan.md" \
  --allowedTools "Read,Write"

# Implement: follow the approved plan
claude -p "Implement the plan in plan.md" \
  --allowedTools "Read,Write,Edit,Bash"

Cada fase recebe permissões de ferramentas com escopo definido. O agente de planejamento não pode editar código. O agente de implementação não pode navegar na web. Fronteiras de arquivos impõem a separação. A flag --allowedTools faz a imposição no nível do CLI. Sem arquivo de configuração. Sem configurações de plugin. Uma flag por invocação, com escopo exato para as permissões que aquela fase requer.

O ciclo de anotação é o diferenciador-chave em relação a “simplesmente promptar melhor.” Você revisa o plano no seu editor. Você risca as partes com as quais discorda. Você adiciona notas nas margens. O agente lê seu arquivo anotado e revisa. O plano melhora a cada passagem porque duas inteligências diferentes (conhecimento de domínio humano, geração de código do modelo) convergem no mesmo documento.

Padrão 2: instância nova por tarefa

for story in $(jq -r '.stories[].id' prd.json); do
  # Each story gets fresh context with a focused briefing
  criteria=$(jq -r ".stories[] | select(.id==\"$story\")" prd.json)
  state=$(git diff --stat HEAD~1)
  briefing="Git state: $state --- Story: $criteria"

  claude -p "Implement: $briefing" \
    --output-format json \
    --allowedTools "Read,Write,Edit,Bash,Glob,Grep" \
    | jq -r '.result'

  # Independent verification: never trust self-report
  python -m pytest -v
done

Sem contexto acumulado. Sem desvio de conversa. Cada agente recebe uma janela limpa com um briefing focado. A flag --output-format json captura saída estruturada incluindo IDs de sessão, habilitando retomada determinística de conversa se uma história precisar de trabalho de acompanhamento.

O passo de verificação independente importa mais que o passo de implementação. Agentes exibem o que eu chamo de Verificação Fantasma: alegam que os testes passam sem executá-los. Rodar pytest fora da janela de contexto do agente elimina o modo de falha inteiramente. O agente não pode deturpar resultados que nunca produziu.

Padrão 3: pipeline de revisão paralela

diff=$(git diff HEAD~1)

# Three reviewers with independent context
claude -p "Review for bugs: $diff" --output-format json > /tmp/correctness.json &
claude -p "Review for vulnerabilities: $diff" --output-format json > /tmp/security.json &
claude -p "Review for style issues: $diff" --output-format json > /tmp/conventions.json &
wait

# Merge findings from all three
jq -s 'map(.result)' /tmp/correctness.json /tmp/security.json /tmp/conventions.json

Três agentes. Três perspectivas. Zero estado compartilhado. Discordâncias entre revisores revelam exatamente os problemas que um revisor único deixa passar. O operador & e o builtin wait gerenciam o paralelismo. Sem runtime async. Sem pool de threads. Sem framework de orquestração. O controle de jobs do bash faz o trabalho.

O poder do padrão: cada revisor recebe a janela de contexto completa para sua única preocupação. Um revisor único dividindo atenção entre correção, segurança e estilo performa pior do que três especialistas com contexto dedicado. CLI torna a divisão trivial porque cada chamada é um processo independente com memória independente.

Pontos-chave

Para desenvolvedores construindo sistemas de agentes: - Comece com claude -p para toda criação de agentes. Adicione MCP apenas quando estado persistente for necessário. - Defina escopo de permissões de ferramentas por fase. Agentes de planejamento leem. Agentes de implementação escrevem. Agentes de revisão leem diffs. - Planeje 94% menos para overhead de tokens escolhendo CLI em vez de MCP para operações stateless.³

Para equipes escalando fluxos de trabalho autônomos: - Instâncias novas de agentes previnem desvio de contexto e limitam custos de tokens por operação. - O Remote Control transforma “não supervisionado” em “supervisionado assincronamente” sem mudar a arquitetura CLI.² - Os dados da Vercel provam o resultado contraintuitivo: menos ferramentas significa taxas de sucesso mais altas, não mais baixas.⁴

Para arquitetos escolhendo infraestrutura de agentes: - Agentes CLI se compõem com ferramentas existentes de CI/CD, testes e deploy. Nenhum trabalho de integração necessário. - A filosofia Unix (compor ferramentas pequenas via pipes) precede e supera todo framework específico de agentes.¹¹ - O muro dos 10% de produtividade é rompido quando você para de tratar o agente como uma ferramenta de chat e começa a tratá-lo como infraestrutura.

Parte da série Engenharia de IA. Veja também: Claude Code como infraestrutura, Anatomia de uma garra, O loop autônomo, e O muro dos 10%.