O terminal do VS Code não é apenas conveniente, é o único editor que lembra seu fluxo de trabalho

Tentei me afastar do VS Code e de seus garfos, como cursor e antigravidade, pelos mesmos motivos pelos quais muitos desenvolvedores experimentam editores mais recentes. Mudei para um editor mais fino como o Zed porque parecia mais leve, mais limpo e visivelmente mais rápido depois de passar algumas horas com ele. Foi muito menos complicado do que configurar o VS Code ao longo do tempo, que era complexo e integrado à IA.

A parte estranha é que quase não senti falta do VS Code até fechar o projeto intermediário do Zed e depois abri-lo. Percebi imediatamente que faltava algo em meu fluxo de trabalho normal. Eu não tinha contexto, nem histórico, apenas um shell vazio, e tive que reconstruir todo o ambiente do zero, o que o VS Code nunca me disse para fazer. A estrutura estava lá. Não houve fluxo de trabalho.

O VS Code transformou meu terminal em parte do espaço de trabalho

Não apenas conchas – contexto de ação

Como a maioria dos desenvolvedores, o VS Code foi meu primeiro editor de código real, deixando para trás a era C++, onde usei o Notepad como meu editor de código. O VS Code começou como um editor de código e com o tempo se tornou um ambiente onde não preciso sair de uma janela para realizar nenhuma tarefa, como compilar, executar ou depurar código. Os terminais integrados pareciam inicialmente convenientes e acabaram se tornando fundamentais para a organização do meu trabalho. Os projetos modernos dependem de vários processos ao mesmo tempo, e o terminal integrado do VS Code ajudou com isso.

Se eu contextualizar um de meus projetos em andamento, MSDL ou Windows ISO Downloader. O projeto depende de três tempos de execução: o frontend React, o backend Go e o Cloudflare Worker (durante a produção). Mesmo ao testar em localhost, preciso que os processos front-end e back-end sejam executados simultaneamente em duas guias de terminal e uma terceira guia para um shell de utilitário, como comandos relacionados ao Git. Cada terminal tem uma função a desempenhar e o VS Code tornou isso mais fácil para mim com terminais divididos e nomeados. A organização do layout padrão tornou-o significativo, e não cosmético. Um único espaço de trabalho contém todo o estado operacional de um projeto.

O VS Code estava fazendo algo que eu não havia notado conscientemente até usar outro editor. Por exemplo, eu estava trabalhando em um projeto e de repente tive outro trabalho que não poderia pular, então fechei a janela do VS Code. Quando voltei e reabri o VS Code, ele reabriu automaticamente os terminais em funcionamento, mesmo que o histórico tenha sido salvo. Isso significa que não estava perdido no que estava fazendo e nos comandos que estava executando antes de sair. Aparentemente as sessões não eram tão persistentes quanto o tmux; os processos morreram, mas pelo menos eu conhecia o contexto. Os comandos e logs ainda estavam lá para eu ver novamente. Não precisei abrir o editor e refazer todo o ambiente.

O VS Code lembrou meu ambiente de fluxo de trabalho o suficiente para que meu cérebro não precisasse.

Zed me fez entender o que o VS Code realmente faz

Os terminais voltaram, mas o fluxo de trabalho não

Se o VS Code funcionasse perfeitamente, por que eu consideraria mudar para outro editor de código? Nos últimos dois a três anos, a IA começou a entrar nos fluxos de trabalho de codificação. Eu testei quase todos os editores de código de IA baseados no VS Code, como Cursor e Antigravity. Até carreguei o VS Code com extensões que pareciam certas na época. Com o tempo, eles começaram a criar atritos no meu fluxo de trabalho; A IU parecia inchada e a experiência lenta.

Foi então que decidi dar um passo atrás, dos editores aprimorados por IA para os editores de código puro. Tentei vários editores de código como Zed, Sublime Text e Neovim e finalmente decidi pelo Zed. Depois de usar o Zed por algumas horas, percebi que ele tem uma interface de usuário mais limpa, uma sensação mais rápida, menos peso de elétrons e uma experiência geral de edição mais suave. E ainda tinha um terminal integrado que suportava várias guias e painéis divididos. Então, meu sentimento inicial foi: “Ok, esse fluxo de trabalho também existe aqui”.

Comecei a sentir falta do VS Code quando fechei o Zed pela primeira vez enquanto dois processos estavam em execução e depois reabri o projeto. Zed restaurou apenas dois terminais, mas apenas como espaços reservados. Eles estavam na mesma estrutura particionada, mas com shells vazios, enquanto o VS Code recriava terminais com um histórico que mostrava contexto de comando, estado CWD e ponteiros de fluxo de trabalho. No VS Code lembrei-me instantaneamente do que estava acontecendo e levei alguns segundos para recriar o ambiente, enquanto no Zed tive que reconstruir tudo manualmente do zero.

Não é VS Code vs. World – é a base

A lacuna sobre a qual ninguém fala

Após minha experiência com Zed e editores de código puro semelhantes, como Sublime Text e Neovim, verifiquei imediatamente o Cursor e o Google Antigravity. Como ambos tinham o VS Code como base, queria ver se eles tinham o mesmo comportamento no VS Code ou se era exclusivo do VS Code. Surpreendentemente, ambos o salvaram e então percebi que não era um recurso do VS Code; era um recurso central do VS Code. Os terminais foram considerados espaços de trabalho em vez de serviços descartáveis. E fazia parte do modelo de ecossistema do próprio VS Code.

Em editores que não eram do VS Code, como Zed, o gerenciamento de terminal era externo e os shells tinham vida curta. Simplificando, a orquestração pertencia fora do editor. Portanto, era o mesmo que abrir um aplicativo de terminal externo como o Windows PowerShell e executar um terminal dentro do Zed. Nenhum deles estava diretamente relacionado ao editor de código. Hoje, o desenvolvimento de projetos modernos envolve vários processos, portanto, terminais, logs e shells de utilitários não são complementos, mas parte do próprio fluxo de trabalho.

Eu não estava procurando um comportamento tmux ou zellij, mas um fluxo de trabalho normalizado semelhante que o VS Code integrou com sucesso aos principais editores de GUI sem exigir um multiplexador separado ou um ambiente orientado a terminal. A verdadeira característica não eram os terminais divididos ou a condição CWD; foi a continuidade do fluxo de trabalho e o contexto da atividade que fez do VS Code e seus forks uma ferramenta difícil de deixar para trás.

Mudar é fácil. Não há como sair disso.

Ainda acredito que editores como Zed e Sublime Text representam a aparência real do ambiente de codificação. Eles são mais leves, mais rápidos e muito mais focados no trabalho real do que na experiência exagerada de editores como o VS Code. Depois de testar vários editores lado a lado, percebi que não estava procurando recursos melhores ou menos envolvimento de IA; o que mais importava era a continuidade dos negócios. Os projetos de hoje são inerentemente complexos e envolvem múltiplos processos, e é aqui que esses editores criam uma lacuna e quebram o fluxo de trabalho. O VS Code não substituiu multiplexadores de terminal como o tmux; simplesmente tornou os fluxos de trabalho do terminal tão simples que os desenvolvedores começaram a confiar neles sem perceber.