JetBrains Criou uma IDE que Dá um Git Worktree pra Cada Agente IA
A JetBrains matou o Fleet, aquela IDE leve que prometia concorrer com o VS Code. Mas enquanto todo mundo achava que a empresa ia recuar pro IntelliJ e fingir que nada aconteceu, eles soltaram algo que ninguém esperava: o ThinkRail, uma IDE open source construída do zero em cima de agentes IA com isolamento por git worktrees.
Eu sei, o nome soa como um produto de startup que vai pivotar três vezes antes de fechar. Mas o conceito por trás é sólido, e diferente de qualquer coisa que Cursor, Windsurf ou o próprio VS Code com Copilot oferecem hoje.
O Problema que Todo Mundo Ignora
Você já tentou deixar um agente IA refatorar código no seu repositório enquanto trabalha em outra coisa? Se sim, sabe o pesadelo. O agente modifica arquivos que você está editando, cria conflitos de merge, e no fim das contas você perde mais tempo resolvendo a bagunça do que teria gastado fazendo o trabalho manual.
O Cursor resolve isso parcialmente com o composer mode. O Windsurf tenta com o cascade. Mas nenhum deles ataca a raiz do problema: o agente e o humano compartilham o mesmo working directory. É como dois cozinheiros usando a mesma tábua de corte ao mesmo tempo.
O ThinkRail resolve isso de um jeito elegante: cada tarefa que o agente recebe ganha seu próprio git worktree. Pra quem não conhece, worktrees são uma feature nativa do Git que permite ter múltiplos checkouts do mesmo repositório em diretórios separados, cada um com seu branch. O agente trabalha no worktree dele, você trabalha no seu. Zero conflito.
Como o ThinkRail Funciona na Prática
A arquitetura é dividida em três camadas que conversam entre si:
| Camada | Tecnologia | Função | |
|---|---|---|---|
| ——– | ———– | ——– | |
| Engine Host | Bun + WebSocket | Roda uma sessão do agente Pi por chat | |
| The Wire | Protocolo tipado e versionado | Comunicação entre backend e frontend | |
| UI Client | React 19 + Zustand + Tailwind v4 | Interface com Monaco editor |
Quando você abre um projeto, o ThinkRail cria o que eles chamam de “workspace”. Cada workspace é um git worktree com seu próprio branch, diretório e sessão de agente. Você pode ter cinco, dez, vinte workspaces rodando em paralelo, cada um atacando uma tarefa diferente.
O fluxo é mais ou menos assim:
- Você abre um repositório Git como projeto
- Cria um workspace novo para uma tarefa (“refatorar módulo de autenticação”)
- O ThinkRail gera um worktree com branch dedicado
- O agente Pi trabalha naquele worktree isolado
- Quando termina, você revisa as mudanças com o botão “Review Turn”
- Se aprovar, faz merge pro branch principal
A parte interessante é o “settling automático”. Quando um PR é mergeado ou o workspace fica inativo por tempo suficiente, o ThinkRail guarda ele numa prateleira (shelf) do projeto. Não deleta, não perde. Só organiza.
O Agente Pi: Quem Faz o Trabalho Pesado
O ThinkRail é, na essência, uma interface visual para o Pi Coding Agent, um agente de código que a JetBrains construiu e publicou como pacote npm (@earendil-works/pi-coding-agent). O Pi é quem realmente entende o código, faz as modificações e gerencia os modelos de linguagem.
Uma decisão de design que me chamou atenção: o ThinkRail nunca monta prompts escondidos. A documentação oficial diz isso explicitamente: “the app never assembles prompts covertly”. O agente Pi cuida de modelos, skills, tracking de custo e estado da sessão. A IDE cuida de workspace, edição e comunicação. Separação clara de responsabilidades.
Cada sessão de chat tem seu próprio modelo configurável e um readout em tempo real de tokens consumidos e custo. Você sabe exatamente quanto está gastando com cada tarefa. Isso é algo que o Cursor não mostra com essa transparência, e que o Copilot nem sequer oferece.
# Instalação via CLI (macOS/Linux)
curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash
# Windows
powershell -c "irm https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.ps1 | iex"
Specs: A Memória que Sobrevive à Sessão
Uma das features mais originais do ThinkRail é o sistema de Specs. São arquivos SPEC.md que ficam ao lado do código e formam um grafo conectado de documentação viva do projeto.
O conceito é simples, mas poderoso: quando um agente trabalha no seu projeto, ele lê as specs pra entender o contexto. Quando termina, ele atualiza as specs com o que aprendeu. Na próxima sessão, outro agente (ou o mesmo) já começa com esse conhecimento acumulado.
Pense nisso como uma wiki que o agente mantém sozinho, mas que você pode editar quando quiser. Cada spec descreve intenção, decisões de arquitetura, padrões do projeto. É o “porquê” por trás do código.
Na prática, isso resolve um problema enorme de agentes IA: a perda de contexto entre sessões. Você já deve ter passado por isso, explicar pro ChatGPT pela décima vez que seu projeto usa injeção de dependência e que o ORM é o Prisma. Com specs, essa informação persiste.
Comparação: ThinkRail vs Cursor vs Windsurf vs VS Code
Vou ser direto. Cada ferramenta ataca o problema de um ângulo diferente:
| Feature | ThinkRail | Cursor | Windsurf | VS Code + Copilot | |
|---|---|---|---|---|---|
| ——— | ———– | ——– | ———- | ——————- | |
| Isolamento por worktree | Sim (nativo) | Não | Não | Não | |
| Memória persistente | Specs (grafo de docs) | Rules (.cursorrules) | Cascade memory | Não | |
| Custo por sessão visível | Sim, em tempo real | Parcial | Não | Não | |
| Open source | Sim (Apache 2.0) | Não | Não | Parcial (VS Code sim, Copilot não) | |
| Agentes paralelos | Sim, múltiplos por workspace | Limitado | Limitado | Não | |
| Review de mudanças | Por turno do agente | Diff inline | Diff inline | Diff inline | |
| BYOK (traga sua API key) | Sim | Sim (com plano) | Sim (com plano) | Não | |
| Editor | Monaco | Fork do VS Code | Fork do VS Code | VS Code |
O ThinkRail não tenta ser o melhor editor de texto. Ele é, assumidamente, uma interface para gerenciar agentes que trabalham no seu código. Se você quer autocomplete inteligente e refatoração manual assistida, o Cursor ainda é mais maduro. Mas se você quer delegar tarefas inteiras para agentes IA sem medo de bagunçar seu working directory, o ThinkRail está anos-luz à frente.
A Aposta em Transparência
O mercado de IDEs com IA virou uma corrida de features opacas. O Cursor adiciona “magic” ao composer sem explicar exatamente o que o prompt contém. O Copilot manda telemetria que ninguém sabe o que inclui. O Windsurf tem um “cascade” que funciona bem, mas é uma caixa preta.
O ThinkRail vai na direção oposta. O código é Apache 2.0. O protocolo entre backend e frontend (chamado “The Wire”) é tipado e versionado. Cada interação do agente gera um “receipt” que você pode inspecionar. E os prompts nunca são montados sem você poder ver.
É uma aposta arriscada? Talvez. Transparência total significa que concorrentes podem copiar tudo. Mas a JetBrains tem uma vantagem: 20 anos de experiência construindo IDEs que desenvolvedores realmente usam. IntelliJ, PyCharm, WebStorm. Eles sabem o que um dev precisa.
Stack Técnica: Bun, React 19 e Electrobun
A escolha de stack me surpreendeu. Veja o que roda por baixo:
Backend:
- Bun 1.4.4 como runtime e package manager (não Node.js)
- Bun.serve para HTTP e WebSocket
- TypeScript puro
Frontend:
- React 19 com Zustand para estado
- Tailwind CSS v4
- Monaco editor (o mesmo do VS Code)
Desktop:
- Electrobun (não Electron!)
- Binários assinados pra Windows e macOS
- Linux com suporte a x64 e ARM64
Qualidade:
- Playwright para testes end-to-end
- Biome para linting
- Turbo como monorepo manager
A escolha do Bun em vez de Node.js é interessante. O Bun é significativamente mais rápido para inicialização e tem um bundler embutido, o que simplifica o pipeline de build. E o Electrobun no lugar do Electron sugere que eles levam performance a sério: apps Electron são famosos por consumir memória como se fosse grátis.
// Exemplo simplificado da arquitetura do Wire (protocolo tipado)
// Cada mensagem entre frontend e backend tem tipo e versão
interface WireMessage<T> {
type: string;
version: number;
payload: T;
timestamp: number;
}
// O agente Pi roda em sessão isolada por chat
interface PiSession {
workspaceId: string;
model: string;
tokensUsed: number;
costUSD: number;
status: 'idle' | 'running' | 'reviewing';
}
Planos Compartilhados: Humano e Agente na Mesma Página
Uma feature que diferencia o ThinkRail de um simples chat com IA é o sistema de planos compartilhados. Funciona assim: quando o agente recebe uma tarefa complexa, ele gera um plano com etapas. Você pode editar esse plano, reordenar as etapas, remover o que não faz sentido, adicionar contexto.
Cada etapa completada pode ser commitada e revisada independentemente. Então se o agente acertar 4 de 5 etapas, você commita as 4 e refaz a quinta manualmente. Não é tudo-ou-nada.
Essa abordagem lembra o que a Anthropic fez com o Claude Code: dar ao desenvolvedor controle granular sobre o que o agente faz. Mas o ThinkRail vai além ao integrar isso diretamente na interface visual, com botões de review por turno e commits parciais.
MCP: Conectando com o Mundo Exterior
O ThinkRail suporta o Model Context Protocol (MCP), aquele padrão aberto que a Anthropic criou para conectar agentes IA a ferramentas externas. Isso significa que você pode plugar servidores MCP que dão ao agente acesso a bancos de dados, APIs, ferramentas de deploy, qualquer coisa.
O gerenciamento de permissões é feito via settings, com OAuth configurável para servidores confiáveis. Você define o que cada servidor MCP pode fazer, e o agente só acessa o que foi autorizado.
Na prática, isso permite cenários como:
- Agente que consulta o Jira pra entender o ticket antes de codar
- Agente que roda os testes no CI e ajusta o código baseado no resultado
- Agente que consulta a documentação da API externa pra gerar o client correto
Quem Deveria Experimentar (e Quem Deveria Esperar)
O ThinkRail está na versão 0.2.0. Isso precisa ficar claro: é software em estágio inicial. Tem 1.400 stars no GitHub, 163 issues abertas e 33 PRs pendentes. É funcional, mas não é estável como o Cursor ou o VS Code.
Experimente agora se você:
- Trabalha com múltiplas tarefas paralelas no mesmo repositório
- Quer controle total sobre o custo dos agentes IA
- Valoriza transparência e código aberto
- Já usa o Pi Coding Agent e quer uma interface melhor
- Gosta de testar ferramentas novas e tolera bugs
Espere um pouco se você:
- Precisa de uma IDE primária estável e confiável
- Depende de extensões específicas do VS Code/IntelliJ
- Trabalha em projetos corporativos com restrições rígidas de tooling
- Não quer lidar com breaking changes entre versões
Plataformas Suportadas
| Plataforma | Desktop | CLI | |
|---|---|---|---|
| ———– | ——— | —– | |
| macOS Apple Silicon | DMG installer | Binário assinado | |
| macOS Intel | Build from source | Build from source | |
| Windows x64 | Setup assinado | .exe assinado | |
| Linux x64/ARM64 | Tarball | Binário |
No Linux, o desktop precisa de Ubuntu 24.04+ com GTK 3, WebKitGTK 4.1 e glibc 2.38+. Se você roda Arch ou Fedora recente, provavelmente funciona. Debian stable, provavelmente não.
O Que Isso Significa pro Futuro das IDEs
A JetBrains está fazendo uma aposta clara: o futuro do desenvolvimento não é um humano escrevendo código com sugestões de IA. É um humano gerenciando agentes que escrevem código. O ThinkRail é a primeira IDE construída inteiramente ao redor dessa premissa.
Se eles estão certos, ferramentas como Cursor e Windsurf vão parecer intermediárias, pontes entre o modelo antigo (humano escreve tudo) e o novo (humano orquestra agentes). Se estão errados, pelo menos entregaram uma IDE open source com isolamento de workspace que qualquer projeto pode adaptar.
O que eu acho? A tendência é real. Agentes de código estão melhorando rápido demais pra continuarmos tratando IA como um autocomplete glorificado. E a JetBrains, com duas décadas de experiência em ferramentas de desenvolvimento, é uma das poucas empresas que pode transformar essa visão em produto de verdade.
O repositório está em github.com/JetBrains/thinkrail, licença Apache 2.0. Baixa, testa, quebra. É assim que software open source evolui.













