JetBrains Thinkrail
El nuevo proyecto Thinkrail de JetBrains, un “IDE agéntico” centrado en IA construido sobre el agente de programación Pi y tecnologías web como TypeScript y Monaco, está provocando reacciones mixtas entre usuarios de larga data. A muchos les intriga su flujo de trabajo basado en especificaciones y su integración más estrecha con agentes de programación autónomos, pero cuestionan por qué no usa el propio motor de editor de JetBrains, por qué se apoya en agentes en la nube en lugar de locales o en contenedores, y por qué su README parece una prosa de marketing generada por IA. El debate más amplio gira en torno a si los IDE pesados todavía tienen sentido en una era en la que los agentes realizan la mayor parte de las tareas de programación, y si los múltiples productos de IA de JetBrains —Air, Thinkrail y otros— reflejan una estrategia coherente o un intento apresurado de ponerse al día con herramientas como Cursor y Zed.
Concepto general y objetivos
- Thinkrail se percibe como un paso hacia una “interfaz final” para el desarrollo agéntico: un único riel donde todas las herramientas/sesiones del proyecto puedan reorganizarse fácilmente (comparado con un sistema de pared de listones tipo French cleat).
- Valor central: organizar el trabajo de un agente por proyecto/sesión para que los humanos puedan volver a conectar rápidamente con el contexto, no solo añadir otra barra lateral de IA.
Arquitectura y decisiones técnicas
- Construido alrededor de Pi como agente de programación; varios usuarios de Pi están entusiasmados, especialmente cuando llegue el soporte completo de extensiones de Pi.
- La pila es TypeScript + Bun + Electron/React (editor Monaco). A algunos les decepciona que no use el propio motor de editor de JetBrains ni una pila nativa/ligera.
- Críticas a que usar TS y Monaco parece perseguir la herramienta web de menor denominador común en lugar de la fuerza tradicional de JetBrains en IDEs de estilo nativo.
Agentes de IA y flujos de trabajo
- Fuerte apoyo a ejecutar agentes en VMs/contenedores aislados con controles estrictos de red/secretos; algunos consideran que los agentes no aislados no son seguros.
- Otros sostienen que las VMs GUI completas son un desperdicio y que los agentes deberían automatizar principalmente hacia APIs en lugar de hacer clic en interfaces gráficas a largo plazo.
- Debate sobre los agentes “haciendo la mayor parte del trabajo”: algunos informan que ahora principalmente supervisan y revisan; otros subrayan que los LLM siguen requiriendo mucha supervisión.
Controversia sobre README / documentación
- Muchos critican el README y los documentos SPEC como una prosa obvia de “LLM”: verbosos, abstractos, “claude-y” y difíciles de analizar.
- Un bando: un README generado por IA señala poca dedicación y mal gusto; si los autores no van a redactar la documentación a mano, también pueden recortar en otras áreas.
- Bando contrario: la calidad del contenido importa más que la autoría; la IA puede redactar a partir de especificaciones reales, con humanos revisando.
IA de JetBrains y estrategia de producto
- Hay una confusión generalizada sobre la dirección de IA de JetBrains: Air, Thinkrail, intentos anteriores como Fleet, y los complementos de IA de los IDE principales parecen fragmentados o abandonados.
- Algunos especulan que Thinkrail es un experimento mientras Air es el producto estratégico; otros temen que ambos sean de corta duración.
- Usuarios veteranos informan que han cancelado sus suscripciones o usan mucho menos los IDE de JetBrains, sustituidos por flujos de trabajo guiados por agentes junto con editores/CLIs más ligeros.
Comparaciones y sentimiento
- Se mencionan Cursor, Zed, varios harnesses (Pi, Claude Code, Codex, otros) como referentes.
- Estado de ánimo mixto: nostalgia y buena voluntad hacia JetBrains, interés por la idea de Thinkrail basada en especificaciones, pero fuerte escepticismo sobre la ejecución, el rendimiento, las decisiones de pila web y el compromiso a largo plazo.