A era pós-IDE

O IDE era uma interface para a complexidade

Durante décadas, o IDE foi a cabine de comando do desenvolvimento de software. Conforme as bases de código cresciam e as linguagens se sofisticavam, editores de texto simples deixavam de ser suficientes. Os desenvolvedores precisavam de navegação por símbolos, preenchimento automático inteligente, análise estática, ferramentas de refatoração, depuração, execução de testes, exploradores de bancos de dados, integração com controle de versão, gerenciamento de dependências e dezenas de outras facilidades.

Produtos como o IntelliJ se tornaram extraordinariamente bons em resolver esse problema. Quando eu passava o dia manipulando pessoalmente uma base de código, esses recursos valiam cada centavo. Mas, de uma perspectiva mais ampla, um IDE é uma ferramenta que ajuda uma pessoa a entender e modificar uma grande coleção de arquivos de código-fonte.

O desenvolvimento com agentes muda quem faz essa manipulação.

A base de código continua lá. O compilador também. Git, testes, linters, sistemas de tipos, depuradores, gerenciadores de pacotes e sistemas de compilação não desapareceram. O que mudou é que cada vez menos sou eu quem opera diretamente essas ferramentas. É o agente.

Raramente preciso olhar o código

Foi essa percepção que acabou me levando a cancelar a JetBrains. Quase nunca abro um IDE para “programar”. Às vezes examino um arquivo por curiosidade sobre uma implementação. Ocasionalmente faço uma alteração manual minúscula. Posso olhar um diff ou investigar algo particularmente estranho.

Mas essas situações agora são exceções, não meu fluxo de trabalho principal. Quando só preciso examinar um texto, um editor básico é perfeitamente suficiente. Não preciso de vários gigabytes de IDE e de uma assinatura anual para as poucas vezes em que abro manualmente um arquivo-fonte.

A imensa maioria das funcionalidades de que eu dependia no IntelliJ continua importante. Ainda quero navegação inteligente pelo código, refatoração, testes, análise estática e revisão de código. Só quero, cada vez mais, que o agente faça essas coisas em vez de eu operar cada ferramenta pessoalmente.

As ferramentas não desapareceram. Elas passaram para baixo da camada de abstração em que passo meu tempo.

A linguagem natural está se tornando uma interface de programação

As linguagens de programação sempre tentaram, em graus variados, tornar as máquinas mais compreensíveis para as pessoas. À medida que nos afastamos do código de máquina e do assembly, as linguagens se tornaram progressivamente mais semânticas. Ganhamos variáveis com nomes significativos, funções que se leem como ações, estruturas orientadas a objetos que modelavam conceitos reais e linguagens declarativas nas quais podíamos descrever cada vez mais o que queríamos, em vez de cada instrução necessária para chegar lá.

Mas ainda eram linguagens de programação.

Se alguém tivesse me dito 30 anos atrás que um dia eu passaria boa parte do dia programando ao falar ou escrever em inglês comum para um computador, eu acharia que estava dizendo bobagens de ficção científica. Mas é essencialmente isso que faço hoje.

Obviamente, o inglês não substitui literalmente TypeScript, Python, Go, Java ou a linguagem que acaba implementando o sistema. Minha CPU não executa um parágrafo que escrevi para um agente. Mas essa distinção está ficando menos importante do lado humano da pilha tecnológica.

Programar sempre envolveu traduzir a intenção humana em algo que uma máquina possa executar. Ao longo do tempo, elevamos repetidamente o nível de abstração do lado humano dessa tradução. Antes, as pessoas manipulavam instruções de máquina diretamente. O assembly deu nomes a essas instruções. Linguagens de alto nível permitiram descrever algoritmos sem pensar em registradores. Frameworks permitiram descrever aplicações sem implementar cada primitiva. Infraestrutura como código permitiu descrever ambientes inteiros em vez de configurar servidores manualmente.

Os agentes acrescentam outra camada. Em vez de expressar pessoalmente cada detalhe de implementação, podemos cada vez mais expressar o resultado desejado:

• Adicione suporte a OAuth para este provedor.
• Descubra por que este endpoint de API às vezes retorna dados desatualizados e corrija o problema.
• Refatore estes serviços para compartilharem a mesma camada de autorização.
• Implemente este épico do GitHub e todas as suas subtarefas.
• Revise os pull requests resultantes em busca de problemas de segurança e faça o merge quando estiverem prontos.

Essas são instruções de programação. O resultado pode acabar sendo milhares de linhas de código-fonte convencional, mas eu não escrevi pessoalmente a maioria delas. Descrevi o sistema que queria, estabeleci restrições, avaliei o resultado e deixei as máquinas traduzirem minha intenção para as linguagens de que precisam.

Trinta anos atrás, a ideia de colocar o inglês comum no topo de uma pilha de desenvolvimento parecia ficção científica. Agora é meu fluxo normal de trabalho. A linguagem natural não está substituindo as linguagens de programação por baixo do sistema; está se tornando a linguagem de programação que eu uso.

A habilidade valiosa nunca foi realmente a linguagem

Ter experiência com muitas linguagens de programação continua sendo extremamente valioso. Saber como diferentes linguagens modelam tipos, concorrência, memória, estado, interfaces, erros e abstração oferece um modelo mental muito melhor para avaliar o que um agente produz. Essa experiência ajuda a reconhecer arquitetura ruim, complexidade desnecessária, interfaces frágeis e escolhas de implementação que provavelmente causarão problemas depois.

Mas acho que a habilidade mais importante é a experiência construindo sistemas complexos. No fim, linguagens são um meio para atingir um objetivo.

As partes difíceis do desenvolvimento de software nunca foram apenas lembrar a sintaxe ou saber qual função de uma biblioteca chamar. O difícil é decidir onde ficam os limites, entender como os componentes devem interagir, antecipar modos de falha, gerenciar estado, projetar para mudanças, fazer escolhas com concessões, depurar comportamentos emergentes e saber quando uma implementação aparentemente razoável vai desmoronar diante da complexidade do mundo real.

Essas habilidades sobrevivem à transição para o desenvolvimento com agentes e podem ficar ainda mais importantes. Se um agente pode produzir TypeScript, Python, Go, Rust ou Java competente sob demanda, dominar uma sintaxe específica se torna menos raro. O que ganha valor é saber o que deve ser construído, como tudo deve se encaixar, quais restrições importam e se o resultado é realmente bom.

É por isso que também não acho que o futuro pertença apenas a quem sabe escrever bons prompts. Um prompt esperto não substitui o julgamento de engenharia. Alguém com décadas de experiência construindo sistemas pode olhar o plano de um agente e perceber que os limites estão errados, o modelo de dados não vai escalar, as premissas de segurança são fracas ou a arquitetura proposta está resolvendo o problema completamente errado.

O agente pode assumir cada vez mais a tradução da intenção em implementação. A pessoa ainda precisa entender o sistema.

Para mim, essa é a mudança real: a linguagem de programação desce na pilha, enquanto arquitetura, julgamento, orquestração e pensamento sistêmico sobem.

Cursor e Windsurf também não resolvem isso

A resposta óbvia é que talvez os IDEs tradicionais estejam perdendo espaço, mas IDEs nativos de IA como Cursor e Windsurf sejam o futuro. Eu não acho.

Cursor e Windsurf ainda são fundamentalmente IDEs. Eles pressupõem que o centro do desenvolvimento de software é uma pessoa olhando arquivos-fonte, navegando em um repositório, selecionando código, revisando diferenças e interagindo com a IA dentro de um editor. Isso já me parece uma etapa intermediária.

Se estou trabalhando com Orgabot ou outro ambiente de agentes, não preciso de um editor aprimorado por IA mais do que preciso de um tradicional. Não fico esperando o preenchimento automático, selecionando uma função e pedindo à IA que a reescreva, nem pulando manualmente entre arquivos enquanto um assistente olha por cima do meu ombro.

Eu passo o trabalho para o agente.

O agente pode abrir arquivos, pesquisar na base de código, inspecionar dependências, executar comandos, ler falhas de testes, modificar vinte arquivos, iniciar subagentes, revisar as mudanças e continuar iterando até terminar a tarefa. Nesse ponto, colocar a IA dentro de um IDE parece quase inverter a lógica.

O objetivo não é tornar as pessoas drasticamente mais rápidas em editar código. É fazer com que precisem editar drasticamente menos código.

Essa distinção importa. Cursor e Windsurf podem ser cabines melhores para programar com ajuda de IA, mas a direção que estou tomando exige cada vez menos uma cabine. A interface principal passa a ser a missão, a issue, a especificação ou a conversa. O código-fonte continua fundamental, mas se torna um artefato produzido e manipulado por baixo dessa interface, em vez do lugar onde passo o dia.

Então, quando cancelei a JetBrains, não a substituí por Cursor ou Windsurf. Substituí o IDE pelo agente.

Não quero mais ser o programador

Orgabot me levou um passo além. Quando uso Orgabot para criar uma aplicação ou organização, não encaro o trabalho como um engenheiro de software com ferramentas melhores para programar. Encaro da perspectiva do CEO.

Um CEO não abre um arquivo-fonte para corrigir uma função. Ele define o objetivo, atribui responsabilidades, garante que as pessoas ou os agentes certos trabalhem nisso, verifica se o resultado corresponde ao objetivo e muda a organização quando o processo falha.

A própria orquestração também pode ser delegada. Um CEO pode pedir ao CTO que entregue um produto, e o CTO coordena engenharia, segurança, infraestrutura, design e revisão sob essa orientação. O CEO não precisa saber qual arquivo contém o middleware de autenticação.

É cada vez mais assim que construo software. Posso dizer:

• Construa este produto.
• Resolva este épico e todas as suas subtarefas.
• Investigue por que este sistema está falhando e resolva a causa raiz.
• Peça à segurança para revisar a implementação antes da publicação.
• Reduza o custo deste fluxo de trabalho sem prejudicar a qualidade.

Essas instruções criam trabalho que acaba resultando em código, mas o código está várias camadas abaixo da interface em que eu opero.

Isso leva a uma regra útil: se o CEO está revisando ou editando código-fonte, provavelmente existe um fluxo de trabalho quebrado em algum lugar abaixo dele.

Talvez o agente de engenharia tenha falhado. Talvez o processo de revisão seja fraco. Talvez a organização não tenha o papel ou a habilidade certos. Talvez os limites para escalar problemas estejam errados. Seja qual for a causa, a resposta não deveria ser arrastar o CEO indefinidamente para a camada de implementação. Deveria ser consertar o sistema para que a organização consiga lidar direito com esse trabalho na próxima vez.

É também por isso que tenho pouco interesse em trocar IntelliJ por Cursor, Windsurf ou outro IDE com IA. Essas ferramentas tornam um programador mais eficaz dentro da camada de código. Orgabot tenta fazer dessa camada um lugar ao qual raramente preciso entrar.

O IDE pode estar se tornando um detalhe de implementação

É por isso que acho que estamos entrando em uma era pós-IDE.

Isso não significa que os IDEs desapareçam amanhã, nem sequer que os editores gráficos de código desapareçam. Sempre haverá momentos em que olhar diretamente o código-fonte será a melhor maneira de entender um problema. Mas acho que o IDE está perdendo a posição de interface principal entre o programador e o software.

O ambiente de agentes está se tornando essa interface, criando um problema estratégico incômodo tanto para as empresas de IDEs tradicionais quanto para as de IDEs com IA. A resposta óbvia tem sido colocar IA no IDE: acrescentar um painel de chat, preenchimento automático, um modo de agente e a capacidade de modificar vários arquivos ao mesmo tempo.

São melhorias úteis, mas me pergunto se a arquitetura não está invertida.

Talvez o futuro não seja um IDE com um agente dentro. Talvez seja um agente com um editor dentro.

O agente se torna o ambiente. Repositório, terminal, navegador, depurador, editor, testes, sistema de integração contínua, rastreador de issues e infraestrutura de implantação são ferramentas disponíveis para esse ambiente quando necessário. Na maior parte do tempo, a pessoa fica um nível acima.

Não cancelei a JetBrains porque a JetBrains piorou

Essa distinção importa. A JetBrains não me perdeu porque o IntelliJ virou um software ruim. Muito pelo contrário: o IntelliJ continua sendo uma obra de engenharia com capacidade impressionante.

Cancelei porque meu fluxo de trabalho mudou tanto que já não preciso de 99% do que ele faz, e essa é uma ameaça muito maior. O problema competitivo mais difícil não surge quando alguém cria uma versão melhor do seu produto. Surge quando o comportamento do usuário muda tanto que a própria categoria do produto perde importância.

Durante anos, quis o melhor ambiente possível para editar código-fonte. Depois, quis o melhor ambiente possível para dirigir agentes que editam código-fonte. Cada vez mais, até isso descreve de forma limitada a direção que estamos tomando.

Quero o melhor ambiente possível para criar organizações de agentes capazes de assumir responsabilidades, delegar trabalho, revisar uns aos outros, escalar problemas quando necessário e produzir software sem me obrigar a descer à camada de implementação.

O IDE não é o centro desse mundo. É uma ferramenta que um dos agentes pode usar.

Depois de anos vivendo dentro de IDEs, acho que talvez finalmente os tenha deixado para trás.