De Volta ao Terminal: Por Que Devs Seniors Estão Largando as IDEs com IA

Fui procurar um comando antigo no histórico do shell na terça-feira e acabei fazendo outra coisa: rolei o histórico inteiro da semana, linha por linha, do jeito que a gente faz quando devia estar trabalhando. O que me chamou atenção não foram os comandos. Foi a ausência de um: eu não tinha aberto a IDE para escrever código havia quatro dias. Abri para ler diff, abri para caçar uma coisa num serviço que não é meu, abri por hábito num momento de dúvida. Para escrever, não.

Isso me incomodou o suficiente para eu conferir se era desvio meu ou padrão. Perguntei em dois grupos de tech leads que frequento e a resposta foi menos unânime do que eu esperava, mas o formato dela se repetiu: quase todo mundo descreveu a mesma migração parcial, quase ninguém descreveu abandono. As pessoas não largaram a IDE. Elas deslocaram uma função específica — a de fazer o trabalho acontecer — para fora dela, e mantiveram lá dentro tudo que tem a ver com olhar.

Vale dizer que eu não tenho nenhum romantismo com terminal. Não uso configuração exótica, não tenho opinião forte sobre prompt de shell, e passei anos defendendo que quem tem IDE boa e não usa está deixando produtividade na mesa. Se eu estivesse escrevendo isto em 2024, este post seria sobre como o terminal é ótimo para umas coisas e péssimo para outras, e ficaria por aí. O que mudou não foi a minha estética.

O que mudou é que a coisa que passou a morar no terminal deixou de ser um chat com autocompletar e virou um processo que enxerga o repositório inteiro, roda comando, lê a falha e volta a mexer no código até o teste passar. E processo que faz isso tem uma propriedade que assistente dentro de editor não tem: ele compõe com tudo que já existe do lado de fora. Este post é sobre essa propriedade — porque a minha tese é que ela, e não o terminal, é o que de fato ganhou.

O Que Realmente Mudou Em 2026

A mudança que importa não foi de qualidade de modelo. Foi de escopo de trabalho. Até pouco tempo atrás, o assistente operava sobre o arquivo aberto e alguma vizinhança que ele conseguisse puxar. A unidade de trabalho era o buffer. Você pedia uma função, recebia uma função, e a tarefa de encaixar aquilo no resto do sistema continuava inteiramente sua — que é, aliás, a parte difícil da maioria das tarefas reais.

Em 2026 a unidade de trabalho passou a ser o repositório. O agente varre a estrutura, decide sozinho o que precisa ler, abre os arquivos que julgar relevantes, edita mais de um de uma vez e — esta é a parte que muda o jogo — roda os comandos do projeto para verificar se o que fez funciona. Quando não funciona, ele lê a saída do erro e volta a mexer. O loop fecha sem você no meio. Você entra no começo, definindo o alvo, e no fim, revisando o resultado.

Descrito assim parece um incremento. Não é. É uma mudança de natureza da ferramenta, e ela reorganiza onde a ferramenta precisa morar. Um assistente que sugere texto pode viver confortavelmente dentro de um editor, porque o editor é onde o texto está. Um processo que precisa rodar npm test, ler stderr, checar o git status, subir um container e conferir uma migração precisa viver onde essas coisas vivem. E elas vivem no shell. Sempre viveram.

É por isso que eu acho que a leitura mais comum dessa migração está errada. Não é nostalgia, não é gosto por preto e branco, não é o dev sênior querendo parecer sério. É que quando o agente passou a precisar de execução, ele foi para o único lugar onde execução é a linguagem nativa. Escrevi no começo do ano sobre o terminal reaparecendo como ambiente agêntico e não como emulador de máquina de escrever, e na época isso ainda me parecia uma aposta de nicho. Deixou de ser.

Uma consequência prática dessa mudança que quase ninguém antecipa: o custo de contexto virou custo operacional. Se o agente gasta metade da sessão redescobrindo que o projeto usa pnpm, que os testes ficam em spec/, e que o módulo de pagamentos tem um cliente HTTP próprio, você está pagando duas vezes — em tokens e em tempo de parede. A ferramenta que consegue inspecionar um codebase de verdade sem esse desperdício não é melhor por elegância. É mais barata por requisição útil.

O Eixo Real É Composabilidade, Não Estética

Aqui está a tese que eu quero defender, e vou defendê-la com opinião assumida porque é isso que eu de fato acho: a discussão "CLI contra IDE" é uma discussão mal formulada. Ela sugere que estamos escolhendo entre duas interfaces para a mesma coisa, e não estamos. O que separa as duas famílias de ferramenta não é a presença de janelas. É se o agente é um programa que outros programas conseguem chamar.

Um agente de terminal é headless. Isso significa que ele roda sem ninguém olhando, aceita entrada de outro processo, devolve saída que outro processo consegue ler, e termina com um código de saída que um if do bash entende. A partir do momento em que isso é verdade, ele deixa de ser uma ferramenta e vira uma peça. Ele entra em Makefile. Entra em job de cron. Entra em step de GitHub Actions. Entra em pipe junto com grep, jq, docker e git. Você consegue rodar cinco instâncias em paralelo, uma por branch, cada uma numa cópia do repo, e comparar os resultados.

Um assistente dentro do editor, por melhor que seja o modelo por trás dele, não tem essa propriedade — e não por falta de competência de quem construiu. É estrutural: ele pressupõe uma sessão humana, uma janela aberta, alguém aceitando sugestão. Você não coloca isso em cron. Não porque seja difícil, mas porque não faz sentido. A superfície da ferramenta é uma pessoa.

Essa é a diferença que eu acho que explica a migração, e ela não tem nada a ver com terminal ser bonito. O terminal ganhou porque é o ponto de encontro que já existia. É onde o build está, onde o teste está, onde o deploy está, onde o git está. Colocar o agente ali não foi uma escolha de estilo — foi colocá-lo no lugar onde ele consegue alcançar o resto do trabalho sem que ninguém precise construir uma ponte.

Repare no que isso implica para quem avalia ferramenta. Se o eixo é composabilidade, então comparar por qualidade de completar código é comparar pela métrica errada. A pergunta útil deixa de ser "o quanto o sugestor acerta" e passa a ser "o que eu consigo montar em volta disso". Um agente 10% pior no código gerado, mas que eu consigo rodar em três branches ao mesmo tempo dentro de um script que já valida o resultado, entrega mais do que um agente 10% melhor que só existe quando eu estou de camisa passada na frente da tela.

E tem um efeito colateral que eu demorei a perceber: composabilidade força você a escrever a especificação. Quando o agente está do lado, no editor, você conversa. Vai ajustando, corrigindo no meio, pedindo "não, assim não". Quando ele roda headless, você não está lá para corrigir — o que significa que a instrução precisa carregar sozinha as restrições, os critérios de aceite e o comando que prova que deu certo. Isso é mais trabalho na frente e menos improviso depois. Na minha experiência é uma troca boa, mas é uma troca, e vale ser honesto sobre o lado que custa.

Um Pipeline Real, Não Um Slogan

Fica abstrato falar de composabilidade sem mostrar. Este é o formato de encadeamento que mais uso hoje, simplificado mas fiel ao que roda de verdade na minha máquina quando pego uma correção pequena e bem delimitada:

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

BRANCH="fix/timeout-cliente-pagamentos"
LOG=".agent-runs/$(date +%Y%m%d-%H%M%S).log"
mkdir -p .agent-runs

git switch -c "$BRANCH"
BASE=$(git rev-parse HEAD)

claude -p "Corrija o timeout do cliente HTTP em src/payments/. \
Rode 'npm test -- payments' e itere até passar. \
Não edite nenhum arquivo dentro de tests/ nem __tests__/." \
  --allowedTools "Edit" "Bash(npm test:*)" \
  2>&1 | tee "$LOG"

# o agente diz que terminou; quem decide sou eu
npm test -- payments

# guarda de segurança: teste alterado invalida a execução
if ! git diff --name-only "$BASE" | grep -qvE '(^tests/|__tests__/)'; then
  echo "abortando: o agente só mexeu em teste" >&2
  git reset --hard "$BASE" && exit 1
fi

git diff "$BASE" --stat

Três coisas nesse bloco importam mais do que o resto. A primeira é que quem valida não é o agente — é o npm test que roda depois, fora do processo dele, sem intermediário. O agente diz que passou; eu não acredito, eu conferio. A segunda é que a lista de ferramentas permitidas é explícita. A terceira é o grep no fim, que existe por um motivo concreto: agente pressionado a deixar a suíte verde tem caminho mais curto disponível, e às vezes ele toma. Já tratei desse modo de falha em detalhe no post sobre agentes que apagam testes e o TDD virando mecanismo de controle, e a lição operacional é que a proibição no prompt é pedido, não garantia. A garantia é a checagem depois.

O ponto que quero destacar é: nada nesse script é sofisticado. É bash de sempre. git, tee, grep, um if. O agente não trouxe nenhum vocabulário novo — ele apenas entrou num vocabulário que eu já tinha há quinze anos. Essa é a definição prática de compor. E é exatamente o que não dá para fazer com uma ferramenta cuja unidade de operação é uma janela.

Daí a extensão natural é subir isso para onde já roda automação. Um step de GitHub Actions que pega issue com label específica, dispara o agente numa branch, roda a suíte e abre PR se passar não é uma peça de ficção científica de plataforma — é a mesma dúzia de linhas com um on: issues: em cima. E é aqui que a conversa fica séria, porque agente que roda sem ninguém olhando dentro do seu CI tem acesso a segredo, a rede e a registry. Escrevi sobre o que a superfície do harness abre em termos de vulnerabilidade quando o agente ganha execução, e continuo achando que a maioria dos times habilita a automação bem antes de fechar o egress. A composabilidade que torna a ferramenta útil é a mesma que torna o descuido caro.

O Campo De Ferramentas E O Que Decide A Escolha

O espaço hoje está razoavelmente povoado, e vale enumerar sem transformar em ranking. Claude Code, da Anthropic, nasceu terminal-first e é provavelmente o que mais empurrou essa categoria para o centro da conversa. Codex CLI, da OpenAI, é open source e traz a vantagem de você conseguir ler o que ele faz. Gemini CLI, Grok Build, Qwen Code, OpenCode, Aider, Warp, Goose e Amazon Q Developer completam o quadro com propostas que vão de wrapper minimalista sobre modelo a ambiente com opinião forte sobre workflow.

A pergunta que sempre aparece — qual é o melhor — tem uma resposta chata e que eu acho correta: depende menos do agente e mais de onde o resto do seu time já mora. Essas famílias ficam sensivelmente mais fortes quando o time já padronizou no ecossistema daquele fornecedor. Não é lock-in ideológico, é atrito acumulado: autenticação que já funciona, faturamento que já está aprovado, política de dados que já passou por jurídico, integração com o provedor de nuvem que você já usa. Cada um desses itens vale mais, na prática, do que alguns pontos percentuais em benchmark de código.

Há uma distinção de categoria que ajuda a não comparar coisas erradas. Claude Code e Codex são melhor entendidos como ferramentas agent-first do que como editores. Não são versões de linha de comando de um editor; são processos cujo propósito é executar uma tarefa de ponta a ponta. Comparar qualquer um dos dois com uma IDE por critérios de IDE — navegação, refactor guiado, ergonomia de edição — é comparar chave de fenda com furadeira e concluir que a furadeira é ruim para apertar parafuso.

Também acho que essa lista vai encolher e mudar de forma nos próximos meses, e isso é um argumento a favor de não se casar cedo demais. Ferramenta que só se integra por script é ferramenta que você troca em uma tarde: muda o binário chamado no Makefile e pronto. Ferramenta que se enraizou no editor de todo mundo, com atalho no músculo e configuração por pessoa, é migração de trimestre. É mais um ponto para composabilidade que ninguém coloca na planilha de comparação, e é o argumento que eu usaria para começar pequeno: um agente chamado por script, um projeto de baixo risco, e a decisão de padronizar adiada para quando houver evidência de uso real.

A Conversa Amadureceu, E Os Critérios Mudaram

A parte que eu mais gostei de observar neste ano não foi o lançamento de ferramenta nenhuma. Foi o teor da discussão pública mudar. Se você acompanhou os fios do Hacker News sobre agentes de código nos últimos meses, o deslocamento é visível: brigava-se sobre se essas ferramentas eram "reais" ou se era tudo demonstração encenada. Hoje se discute como torná-las economicamente úteis, operacionalmente confiáveis e estruturalmente repetíveis. É uma pergunta bem menos divertida e bem mais adulta.

Junto com a mudança de pergunta veio uma mudança de critério, e os critérios que a comunidade passou a usar são melhores do que os que a indústria usa. Quatro deles aparecem repetidamente. Se a ferramenta preserva contexto ao longo de sessões longas, que é o que separa uma tarefa de quarenta minutos concluída de uma tarefa que se perde na metade. Se ela consegue inspecionar um codebase real sem queimar metade da sessão redescobrindo a estrutura, porque em repositório grande esse é o custo dominante. Se ela compõe com shell, git, automação de browser e sistemas externos. E se o dev consegue supervisionar sem sentir que está brigando com o harness.

Esse quarto critério é o mais subjetivo e provavelmente o mais decisivo. "Brigar com o harness" é aquela sensação específica de estar gastando esforço na ferramenta e não no problema: reexplicar a mesma restrição pela terceira vez, descobrir que a permissão negada bloqueou a coisa errada, perceber que o agente refez do zero algo que você já tinha corrigido à mão. Nenhuma dessas coisas aparece em benchmark. Todas determinam se a ferramenta continua sendo usada na terceira semana.

Repare que nenhum dos quatro critérios é sobre qualidade do código gerado. Isso é notável e eu acho que é correto. A qualidade bruta convergiu o bastante entre os modelos de topo para deixar de ser o fator diferenciador na maioria das tarefas de manutenção. O que não convergiu é o entorno: gestão de contexto, permissão, retomada, integração, previsibilidade de custo. Que é justamente o que a comunidade aprendeu a olhar, e mais ou menos o oposto do que a página de lançamento escolhe destacar.

A contrapartida desse amadurecimento é que a régua subiu para nós também. Se o critério é confiabilidade operacional, então a responsabilidade sai do fornecedor e vem para o time: é você que define o que o agente pode tocar, que decide o que valida o resultado, que estabelece como retomar do meio. Esse é o conjunto de práticas que virou, na minha leitura, a competência central do trabalho — e é sobre isso que escrevi ao tentar listar as habilidades que um dev precisa cultivar quando o agente vira parte do processo. A ferramenta ficou mais capaz; a parte difícil migrou para o desenho em volta dela.

Onde A IDE Continua Ganhando

Agora o contraponto, e não é concessão retórica: eu de fato acho que a IDE ganha em várias frentes, e que quem está vendendo essa migração como conversão total está errado ou está vendendo alguma coisa.

A primeira frente é leitura de diff. Um agente competente produz mudanças espalhadas por seis ou oito arquivos, e revisar isso num terminal é possível, mas é pior. Diff lado a lado, com syntax highlight, com a possibilidade de expandir contexto de uma linha por vez, com clique em símbolo para ver onde ele é usado — isso é caro de reproduzir no shell e é exatamente o que a IDE faz há vinte anos. Como o volume de código a revisar aumentou justamente por causa dos agentes, a ferramenta de revisão ficou mais importante, não menos. Existe uma ironia aí que vale registrar: o agente de terminal aumentou o valor da IDE, só que numa função diferente da que ela tinha.

A segunda é navegação em código desconhecido. Quando eu preciso entender um serviço que não é meu, "vá para a definição", "encontre todas as referências", "abra a hierarquia de chamadas" continuam sendo mais rápidos e mais confiáveis do que pedir a um agente que me explique. O índice da IDE é determinístico. Ele não alucina e não esquece. Perguntar ao agente é ótimo para a visão geral e para o "por que isso existe"; é pior para o "onde exatamente isso é chamado", que é uma pergunta que tem resposta exata e verificável.

A terceira, e a mais nítida, é debug interativo. Breakpoint condicional, inspeção de variável no frame, avaliar expressão no meio da execução, voltar no stack. Não existe substituto agêntico decente para isso, e eu desconfio de quem diz que existe. Quando o bug é sutil e depende de estado em tempo de execução, o debugger não é uma preferência — é a ferramenta certa. Já perdi tempo demais tentando resolver por descrição algo que um breakpoint resolveria em noventa segundos.

O padrão que funciona na prática, então, é híbrido, e é o que eu de fato rodo: agente no terminal para executar, IDE para revisar e para entender. Uma janela de shell onde a tarefa acontece, uma janela de editor onde eu leio o que aconteceu. Sem drama, sem lado escolhido. Quem tenta fazer tudo em um só dos dois está pagando um preço desnecessário nos dois casos — e a versão "faço tudo no terminal, sou puro" é tão improdutiva quanto a versão "não saio da IDE por nada".

Conclusão

Se eu tivesse que resumir a mudança em uma frase, seria esta: o agente saiu de perto do código e foi para perto da execução. O terminal foi o destino porque é onde a execução mora, não porque tem alguma virtude intrínseca. Se amanhã alguém construir uma interface gráfica que seja igualmente headless, scriptável e paralelizável — que aceite ser chamada por outro processo, devolva código de saída e componha com o que já existe —, ela compete de igual para igual, e eu troco sem nenhuma cerimônia. O que não compete é ferramenta que exige uma pessoa olhando para funcionar.

Fico com uma incerteza que não consigo resolver, e prefiro deixar registrada do que fingir que tenho a resposta. Não sei se essa migração é um estado estável ou uma fase de transição. É perfeitamente possível que a gente esteja no terminal hoje só porque a camada de integração ainda é imatura, e que daqui a um ano exista um ambiente que faça as duas coisas bem — executar headless e revisar visualmente — tornando essa discussão inteira uma curiosidade histórica. Também é possível o contrário: que a separação entre o lugar onde o trabalho é feito e o lugar onde ele é revisado seja saudável por si só, porque olhar e fazer são atividades diferentes e talvez devam mesmo acontecer em ferramentas diferentes. Eu me pego defendendo as duas hipóteses em semanas diferentes.

O que eu apostaria que sobrevive não é o terminal, e definitivamente não é nenhum dos nomes que listei aqui — metade deles pode não existir em um ano. É o critério. A pergunta "isto compõe com o que eu já tenho?" é a que melhor previu quais ferramentas ficaram no meu fluxo e quais eu abandonei depois de duas semanas de entusiasmo, e ela funcionava antes de existir agente nenhum. Se você está avaliando alguma dessas ferramentas agora, eu faria essa pergunta antes de todas as outras. E ainda assim manteria a IDE aberta na outra janela, porque revisar o que a máquina fez continua sendo trabalho humano, e é o que sobra quando o resto é automatizado.

Fontes:

• daily.dev — The best terminal AI coding tools: Claude Code, Codex CLI, and Gemini CLI
• amux — Best Terminal AI Coding Agents in 2026
• Developers Digest — What Hacker News Gets Right About AI Coding Agents in 2026
• Kilo — Best CLI AI Tools in 2026: CLI Coding Agents Compared
• Hacker News — The no-bullshit guide to Agentic Engineering