É melhor programar na CLI do que na IDE?
Como escolher a melhor forma de programar com IA
Por que muitos desenvolvedores estão migrando para o terminal? Existe uma vantagem significativa de se utilizar uma CLI em vez de uma IDE? Historicamente sempre fui um ávido consumidor de ferramentas como Sublime Text, VS Code e Cursor, mas hoje em dia passo praticamente todo meu tempo no Claude Code ou no Codex CLI. Qual foi a razão dessa mudança?
Meu ponto aqui não é provar que A é melhor que B, mas argumentar qual opção é mais adequada dependendo da tarefa a ser realizada. Tenho notado muitos comentários sobre "qual a vantagem de se utilizar uma CLI”, uma dúvida genuína causada muitas vezes por FOMO: “Todo mundo está no terminal, será que eu deveria mudar também?”
Sendo assim, vamos entender primeiro a diferença entre a CLI e a IDE e quando eu prefiro utilizar uma em vez da outra.
O que é uma CLI?
CLI significa command line interface, um paradigma de comunicação entre programas que vive no terminal. Se interface é o que separa duas entidades (aqui, o humano e o computador), a linha de comando é o meio de comunicação. Não existem botões e o mouse é praticamente inútil – normalmente é texto em um fundo preto e a operação é via teclado.
Quando comecei a programar, utilizar o terminal era reservado a tarefas bem específicas: configurar um servidor, conexão remota via SSH, instalar o Linux, etc. É bom que se diga que alguns programadores destemidos sempre fizeram do terminal seu lar, desde editores simples como nano e vim, até editores mais parrudos como o Neovim.
Historicamente era assim que se programava (e operava-se o computador), mas com o aumento do poder computacional e a popularização de sistemas operacionais user-friendly como Windows e MacOS, realmente trabalhar dentro do terminal parecia algo relevante apenas para sysadmins. Isso mudou, e já explicarei o porquê.
O que é uma IDE?
IDE significa integrated development environment, e como o nome sugere, é um software que engloba todo o necessário para se programar, não só a edição do código, mas também execução, debugging, building, profiling, etc.
Aqui é importante fazer uma distinção: VS Code (e portanto todos seus forks como Cursor, Antigravity, Windsurf, etc), Zed, Sublime Text, não são uma IDE estritamente falando. Na verdade, esses softwares são chamados code editors, nada mais do que editores de texto voltados para programação.
Exemplos de IDEs “reais” seriam: Eclipse (Java IDE), Xcode (IDE para o ecossistema Apple), WebStorm (JavaScript IDE), etc. Esses softwares são consideravelmente mais pesados, justamente por englobarem todo o necessário para se programar nesse ambiente particular (não tenho boas memórias de abrir o Eclipse no meu antigo notebook LG rodando Windows 7).
É verdade que VS Code e similares são tão extensíveis que podem ficar tão pesados quanto, e proporcionarem a mesma imersão que uma IDE. Embora seja correto dizer que o Cursor não seja uma IDE, na prática ele é usado como tal, e popularmente se faz pouca distinção. Tomarei a licença poética de colocá-lo no grupo das IDEs, uma vez que a pergunta original não é tanto “CLI vs IDE” mas “terminal vs software dedicado para programação”.
Por que há um ressurgimento do terminal?
Parece estranho que em pleno 2025, com mais poder computacional do que nunca e Macbooks se tornando cada vez mais populares, as pessoas estejam voltando ao terminal. Mas isso faz todo sentido uma vez que as principais ferramentas de programação agêntica estão vivem no terminal. Na minha opinião, o Codex CLI é a ferramenta mais completa, e o Claude Code o melhor produto.
Isso ocorre por diversas razões. Em primeiro lugar, quanto mais inteligentes ficam os modelos, menos precisamos monitorar a qualidade o código gerado. Isso significa que as mudanças em si importam menos do que a abordagem holística escolhida. Atenção: a confiança no código gerado pela IA é proporcional ao entendimento do programador acerca do projeto.
Para provar esse ponto, uma experiência pessoal: parte da minha responsabilidade enquanto Engineering Manager era treinar e garantir a qualidade do código gerado pelo meu time.
Ora, eram dezenas de PRs na semana, e não era um bom uso do meu tempo ficar revisando linha por linha. O importante é respeitar o estilo de programação de cada um, porém garantir que todas as decisões tomadas estejam de acordo com as boas práticas e guidelines do projeto, além de utilizar minha expertise para notar possíveis problemas com a abordagem que não são óbvios à primeira vista (ex: uma mudança funcionalmente correta mas inadequada sob escala). Essa supervisão é precisamente o que precisa ser feito com a IA – deixá-la livre para programar contanto que dentro dos limites do projeto.
Em segundo lugar, agentes são extremamente capazes, porém o caráter estocástico de suas ações abrem brechas de segurança. Sendo assim, é compreensível que eles rodem em uma sandbox, um ambiente controlado cujas ações são limitadas. Essencialmente isso é um servidor dedicado, caso de uso perfeito para se controlar via terminal.
Não só isso, quando interagimos com um agente via terminal podemos muni-lo com diversas outras CLIs: um agente pode chamar outro agente, ou simplesmente outra ferramenta. Esse uso generalista dos agentes de IA é uma das minhas formas favoritas de utilizar o Claude Code.
Mas se até o momento eu foquei nas vantagens técnicas, vale listar também as vantagens práticas. Algumas que vem à mente:
O terminal, sendo muito mais leve, permite que eu trabalhe em múltiplos projetos ao mesmo tempo, bastando apenas abrir novos terminais ou utilizar um multiplexer como o tmux.
Consome menos RAM do seu computador, aumentando a developer experience mesmo em máquinas mais modestas.
Facilmente integrado em servidores através do SSH. Por exemplo, eu tenho o Claude Code instalado na minha VPS na Hostinger e quando me conecto remotamente à maquina faço toda a configuração através de linguagem natural.
Pode ser utilizado para configurar sistemas operacionais, em particular os baseados no Linux, como é o caso do Omarchy. Todo meu setup do Omarchy, que incentiva o keyboard em detrimento do mouse, foi feito com Claude Code.
Quando a IDE é superior
Considerando todas as vantagens acima, é verdade que em muitos casos a IDE ainda proporciona uma melhor experiência. Por exemplo, eu utilizo a IDE sempre que desejo olhar o código, ver o que foi feito, as mudanças, etc. Quando preciso entender melhor o problema, suas dependências, onde tal função foi definida, buscar se existe uma referência em outro lugar ou uma implementação diferente, aí sim a IDE é imbatível.
Note que isso vai ao encontro do que disse originalmente sobre o uso da IA sendo proporcional ao entendimento: se preciso entender mais o que está sendo feito, então vou para a IDE. Se tenho um alto nível de confiança nas mudanças, a CLI me basta.
Um corolário importante é que quanto menos experiente é o programador, mais ele se beneficiará da IDE. Isso não é necessariamente uma regra, mas faz sentido: quando estamos aprendendo, precisamos entender melhor a codebase, ver os arquivos e suas dependências, buscar as definições, etc. Esse trabalho certamente é facilitado pela IDE.
Posso utilizar o terminal dentro da IDE e ter o melhor dos dois mundos?
Softwares como o Cursor ou VS Code já oferecem um terminal integrado, e o próprio Claude Code tem uma extensão que basicamente abre o terminal dentro da IDE. Não seria então o caso de utilizá-lo?
A resposta para essa pergunta é: com certeza! Mas só você irá saber até que ponto isso se encaixa no seu workflow. Para mim, existe o momento de interagir com a IA, e o momento de revisar o que foi feito. Eles não precisam coexistir na maior parte do tempo – tanto é que novas atualizações do Cursor moveram o agente da barra lateral para uma nova tab.
Existem outros problemas práticos menores também; por exemplo, gosto de deixar o terminal rodando o servidor, seja o backend e o frontend. Mas não é incomum que eu queria alternar entre projetos, o que se torna cumbersome quando o terminal está integrado (posso não querer matar o servidor, apenas explorar o código de outro repositório).
Dito isso, é perfeitamente compreensível que se queira utilizar os dois em conjunto em um ambiente único. Se isso facilita a sua experiência, go for it.
Quem é melhor: a IDE ou a CLI?
Se você chegou até aqui provavelmente já sabe a resposta. Não existe melhor, ambas as soluções são aceitáveis, e a combinação entre elas também.
Dito isso, para aqueles familiares com o código e com programação orientada à IA, é possível que a CLI proporcione um maior ganho de produtividade.
Mas se você está começando, explorando um projeto, não tem tanta necessidade de multitasking, ou simplesmente prefere exercer um controle maior sobre a IA, provavelmente uma IDE será mais indicada.
Note que não existe nada fundamentalmente melhor em uma abordagem do que na outra, no sentido de que “os melhores programadores utilizam X e não Y”. Tanto CLIs quanto IDEs são ferramentas, e portanto apenas meios para um fim. O que importa é o resultado e a qualidade, e tudo isso pode ser atingido pelas duas formas.
Portanto, esqueça o FOMO. Se a sua preferência é utilizar o Cursor, VS Code ou afins, continue com a consciência tranquila. Se a simplicidade e a velocidade do terminal são um diferencial para você, tanto melhor. Embora eu prefira os modelos que executam na CLI, a diferença entre os modelos flagship é pequena o suficiente para não comprometer nenhum projeto.
A maior diferença está entre o teclado e a cadeira. Sempre foi assim, e sempre será.
Como designer com experiência em front-end, o que mais me incodoma em usar o terminal é que só é permitido usar fontes monoespaçadas. Cheguei a alterar o terminal pra usar a Reddit Mono, mas ainda assim a experiência de leitura do texto, não fica a mesma do que usando uma fonte não monoespaçada.
Utilizo geralmente o terminal do windows usando Codex CLI, e a extensão do Codex no VSCode quando preciso subir algum print na minha requisição ao Codex.