JetBrains Thinkrail

Artigo original ↗ Discussão no Hacker News ↗

O novo projeto Thinkrail da JetBrains, uma “IDE agentic” centrada em IA e construída sobre o agente de codificação Pi e tecnologias web como TypeScript e Monaco, está provocando reações mistas entre usuários antigos. Muitos se interessam pelo fluxo de trabalho orientado por especificações e pela integração mais estreita com agentes autônomos de codificação, mas questionam por que ele não usa o próprio motor de editor da JetBrains, por que se apoia em agentes na nuvem em vez de locais ou em contêineres, e por que seu README parece prosa de marketing gerada por IA. O debate mais amplo gira em torno de saber se IDEs pesados ainda fazem sentido numa era em que agentes realizam a maior parte das tarefas de programação, e se os produtos de IA da JetBrains — Air, Thinkrail e outros — refletem uma estratégia coerente ou uma tentativa apressada de correr atrás de ferramentas como Cursor e Zed.

Conceito geral e objetivos

  • Vê-se o Thinkrail como caminhando em direção a uma “interface final” para desenvolvimento com agentes: um trilho único onde todas as ferramentas/sessões do projeto podem ser reorganizadas facilmente (comparado a um sistema de parede com presilhas francesas).
  • Valor central: organizar o trabalho de um agente por projeto/sessão para que humanos possam retomar o contexto rapidamente, e não apenas adicionar mais uma barra lateral de IA.

Arquitetura e escolhas técnicas

  • Construído em torno do Pi como agente de codificação; vários usuários de Pi estão entusiasmados, especialmente quando chegar o suporte completo a extensões do Pi.
  • Stack em TypeScript + Bun + Electron/React (editor Monaco). Alguns se decepcionam por não usar o próprio motor de editor da JetBrains ou uma stack nativa/leve.
  • Crítica de que usar TS e Monaco parece correr atrás do menor denominador comum das ferramentas web, em vez da força tradicional da JetBrains em IDEs com aparência nativa.

Agentes de IA e fluxos de trabalho

  • Forte apoio a executar agentes em VMs/contêineres isolados com controles rígidos de rede/segredos; alguns veem agentes não isolados como inseguros.
  • Outros argumentam que VMs com GUI completa são desperdício e que os agentes deveriam, em sua maior parte, automatizar em direção a APIs em vez de cliques prolongados na GUI.
  • Debate sobre agentes “fazerem a maior parte do trabalho”: alguns relatam que agora בעיקר supervisionam e revisam; outros enfatizam que LLMs ainda exigem muita supervisão.

Controvérsia sobre README / documentação

  • Muitos criticam o README e os documentos SPEC como “prosa de LLM” óbvia: prolixos, abstratos, “claude-y” e difíceis de interpretar.
  • Um lado: README gerado por IA sinaliza pouco cuidado e mau gosto; se os autores não vão elaborar a documentação manualmente, talvez também economizem em outros pontos.
  • Contra-argumento: a qualidade do conteúdo importa mais do que a autoria; a IA pode rascunhar a partir de especificações reais, com humanos revisando.

IA da JetBrains e estratégia de produto

  • Há ampla confusão sobre a direção de IA da JetBrains: Air, Thinkrail, tentativas anteriores como Fleet e plugins de IA para os IDEs principais parecem fragmentados ou abandonados.
  • Alguns especulam que Thinkrail é um experimento enquanto Air é o produto estratégico; outros temem que ambos possam ter vida curta.
  • Usuários antigos relatam cancelar assinaturas ou usar os IDEs da JetBrains muito menos, substituídos por fluxos de trabalho orientados por agentes e por editores/CLIs mais leves.

Comparações e sentimento

  • Referências a Cursor, Zed, vários harnesses (Pi, Claude Code, Codex, outros) como benchmarks.
  • Clima misto: nostalgia e boa vontade em relação à JetBrains, interesse na ideia spec-first do Thinkrail, mas forte ceticismo quanto à execução, desempenho, escolhas de stack web e compromisso de longo prazo.