ThinkRail: el IDE agéntico de JetBrains sobre Pi

JetBrains ha hecho un IDE para un agente que no es suyo.

Y no es un plugin de IntelliJ ni una versión de Junie con otro nombre. ThinkRail es una aplicación aparte, open source con licencia Apache 2.0, que envuelve a Pi, el agente de código minimalista de Mario Zechner, y le pone alrededor lo que en la terminal echas de menos: editor, diffs, terminales, revisión de cambios y un sitio donde las decisiones del proyecto no se pierden cuando cierras la sesión.

Lo firma JetBrains InnovationHub, el repositorio vive en la organización de JetBrains en GitHub con la etiqueta de proyecto incubado, y en dos meses y medio ha pasado de su presentación (19 de agosto de 2026) a la versión 0.2.0 (18 de octubre de 2026), con unas 2.400 estrellas y 568 commits en main cuando escribo esto.

En este artículo vas a ver:

• Qué es ThinkRail y por qué se apoya en Pi en vez de traer su propio agente
• Cómo funcionan los workspaces sobre git worktree y por qué no deberías dejar al agente suelto en tu carpeta
• Su forma de entender el Spec-Driven Development con un grafo de SPEC.md
• Lo que trae la 0.2.0: recibos por turno, revisión por hunks y MCP con permisos
• Cómo instalarlo, qué datos envía y para quién tiene sentido hoy

¿Qué es ThinkRail y qué problema intenta resolver? ¶

ThinkRail es un IDE agéntico: una aplicación de escritorio (o una web que se abre desde la CLI) construida alrededor del agente Pi, que se ejecuta dentro del propio proceso de ThinkRail. Su lema es “el IDE agéntico que mejora cada vez que lo usas”, y la idea de fondo es que el proyecto vaya acumulando conocimiento duradero en forma de specs y skills.

El documento de objetivos del repositorio (goal-and-requirements.md) parte de un diagnóstico que cualquiera que haya trabajado con agentes en terminal reconoce. Pi es flexible y extensible a propósito, pero esa flexibilidad cuesta tiempo. Los recién llegados tardan en aprender a manejarlo y los veteranos siguen encontrando la terminal torpe para todo lo que rodea al agente.

Concretan tres dolores:

1. Los agentes en paralelo chocan en el mismo árbol de trabajo, entre ellos y con tus propios cambios.
2. Revisar lo que ha hecho el agente es incómodo desde una CLI: leer diffs, comentar líneas exactas y devolverle ese feedback.
3. La intención se evapora. Las decisiones que tomas en un chat mueren con la sesión, y la siguiente las vuelve a deducir o las contradice.

De los tres, este es el que más me toca.

Todos hemos tenido la conversación de veinte minutos con el agente en la que por fin acordáis cómo se van a gestionar los errores del módulo de pagos. Al día siguiente abres sesión nueva y el agente decide, con toda su buena fe, hacerlo de otra manera. Es como tener un compañero brillante con amnesia de fin de semana.

🔑 ThinkRail no intenta ser un agente mejor. Intenta que el agente que ya tienes trabaje aislado, se pueda revisar y no olvide lo que decidisteis.

¿Por qué JetBrains construye sobre Pi en vez de crear su propio agente? ¶

Porque el producto está diseñado como una capa fina, y lo dicen sin rodeos. En el post “An agentic IDE that follows Pi’s philosophy” del blog oficial lo resumen así: ThinkRail es “a propósito una capa fina sobre Pi”. El razonamiento, los permisos y la gestión del contexto son de Pi. Literal: “Ese es el trabajo de Pi, y siempre lo será”.

Si no conoces Pi, en el blog tienes la guía completa del agente de código minimalista: cuatro herramientas (read, bash, edit, write), un system prompt muy corto y un sistema de extensiones que permite construir casi cualquier cosa encima. El paquete que usa ThinkRail es @earendil-works/pi-coding-agent, que en npm va por la versión 1.4.0 y sigue firmado por Mario Zechner. ThinkRail 0.2.0 trae embebido Pi 1.2.0.

Los principios de diseño del repositorio son tajantes:

• Pi es el único motor, ejecutado en el mismo proceso. Nada de un segundo runtime (citan por su nombre claude-agent-sdk como lo que no van a usar).
• Influir alimentando, nunca ensamblando. ThinkRail solo da forma al agente a través de lo que le pasa a Pi: contexto, ficheros, skills y extensiones propias de Pi. No monta prompts a tus espaldas.
• Exponer, no recalcular. Los tokens y el coste que ves son los que reporta Pi, no una estimación propia.
• Tus herramientas y tus credenciales. Git, GitHub y los modelos pasan por tu git, tu gh y la autenticación de proveedores de Pi. ThinkRail no tiene cuentas propias.

Esto tiene una consecuencia práctica muy agradable. Si ya usas Pi instalado aparte, los dos comparten la carpeta ~/.pi: ThinkRail lee tus proveedores, tu lista de modelos, tus extensiones y tu historial de chats. Puedes empezar algo en la terminal y seguirlo en la interfaz gráfica, o al revés.

Hay letra pequeña, y el propio blog la cuenta. Las skills y extensiones se ejecutan sobre el Pi embebido, que puede no coincidir con tu versión instalada. Las extensiones que cambian la interfaz visual de Pi no funcionan, porque ThinkRail tiene su propio sistema de temas. Las que añaden comportamiento en el motor (herramientas, hooks, slash commands, diálogos sencillos) deberían ir bien.

⚠️ Si dos extensiones registran una herramienta con el mismo nombre, Pi conserva las dos, avisa del conflicto y decide el orden de carga. Si algo se comporta raro, empieza a buscar por ahí.

Curso en vídeo

Que tu agente no olvide las reglas al abrir sesión nueva

En la lección 3 escribimos un AGENTS.md regla a regla para un proyecto real, el mismo fichero del que ThinkRail tira para saber que trabaja con specs.

Entra en el curso →

¿Cómo funcionan los workspaces sobre git worktree? ¶

Cada workspace que crea ThinkRail es un git worktree con su propia rama y su propio directorio de trabajo. El agente trabaja ahí, en paralelo con otros agentes, y tu rama principal no se toca hasta que tú decides fusionar.

El post “ThinkRail Workspaces” de Maciej Gorywoda explica por qué no quieren al agente trabajando en tu carpeta. Si lo hace, cada cambio afecta al instante a la rama actual. El agente puede borrar cambios que no has guardado, sobrescribir los que sí, si tiene permisos de git, y pisarse con otros agentes.

El flujo es sencillo:

1. Pulsas Start building, eliges la rama de partida y escribes una descripción.
2. Esa descripción se convierte en el nombre del workspace y en el primer prompt del agente (que luego puede acortar el nombre).
3. Se abre un chat y el agente se pone a trabajar en un directorio como ~/.thinkrail/worktrees/<proyecto>/workspace-1.
4. Si abres el proyecto en tu IDE de siempre, sigues viendo el código original, intacto.

Puedes lanzar varios workspaces desde la misma rama, cada uno con una tarea. El ejemplo del blog: un agente hace un refactor que no cambia comportamiento mientras otro actualiza las specs del proyecto. No tienes que esperar a que termine uno para arrancar el otro.

Si los worktrees te suenan a chino, en buenos motivos para usar git tienes la base. Y si te interesa coordinar varios agentes a la vez desde la terminal, Agent Orchestrator ataca un problema parecido desde otro ángulo, y Orca lo hace con una interfaz gráfica para Claude Code y Codex.

¿Qué es el Default workspace y cuándo usarlo? ¶

Cada proyecto tiene un workspace especial, el Default, cuyo directorio es la propia carpeta del proyecto. No se puede borrar ni renombrar, y nunca se entra en él de forma automática: lo eliges desde la bienvenida del proyecto con “Work in project folder”.

Está pensado para quien se pierde con los worktrees o para tareas en las que de verdad quieres trabajar sobre tu copia. Es una decisión explícita, no el valor por defecto. También puedes enganchar un worktree que ya tuvieras creado; ThinkRail puede olvidarlo, pero nunca lo modifica por su cuenta.

¿Qué pasa con los workspaces terminados? ¶

Desde la 0.2.0 cada proyecto tiene una estantería Settled. Un workspace se va ahí cuando su pull request se fusiona o se cierra, o tras un periodo sin actividad que configuras en Settings › Workspaces: 1, 3, 7 o 14 días, o nunca. Cuenta como actividad el trabajo real (turnos de chat, entrada en terminal, movimientos de HEAD), no mirar la pantalla.

La barra superior te dice cómo está la rama activa frente a origin y frente a su pull request, con el siguiente paso a un clic: publicar, hacer push o abrir un PR con la descripción sacada del plan, de los commits, de tu plantilla de PR o de un borrador escrito por el agente. Con el PR abierto en GitHub ves los checks de CI y el estado de la revisión, y puedes pasarle al agente los checks que fallan o una rama que ha divergido.

Todo pasa por tu gh. Si no está disponible, ThinkRail cae a una URL de comparación ya rellena (en GitLab, la página de nueva merge request).

¿Qué ofrece ThinkRail como IDE alrededor del agente? ¶

Un banco de trabajo divisible con pestañas del editor Monaco, un árbol de ficheros con las marcas de cambios de git en vivo, una vista de cambios, terminales PTY reales y documentos. Todo limitado al workspace activo: cambias de workspace y cambian los ficheros, los diffs, las terminales y los chats.

Donde más notas la diferencia con un agente en terminal es en los chats:

• Varias sesiones de Pi a la vez por workspace, cada una con su modelo y con lectura en vivo de tokens y coste.
• Dirigir un turno en marcha o dejar en cola el siguiente mensaje sin esperar.
• Subagentes en primer plano, en paralelo o en segundo plano. Desde la 0.2.0 puedes configurar de 1 a 16 por chat (4 por defecto).
• Un plan compartido que el agente va actualizando y que tú puedes editar. Cada paso completado se puede commitear por separado cuando ThinkRail puede demostrar que esos cambios son suyos, y pasarlo con un revisor independiente.
• Preguntas estructuradas: el agente puede preguntarte con opciones en el propio chat.

Luego está la revisión. Dejas comentarios anclados a líneas de ficheros y diffs, se acumulan sin despertar al agente y, cuando quieres, los envías a un chat como contexto estructurado. Es revisión local, no una integración con la forja.

Si echas de menos tu editor, puedes abrir el worktree en el IDE que tengas instalado.

Las herramientas del agente incluyen búsqueda web, diagramas en línea, comparativas de opciones y previsualización de ficheros dentro del chat. Cuando el agente propone un cambio de interfaz, te enseña una maqueta de antes y después que puedes comentar igual que un diff. En la terminal ni te lo planteas.

¿Cómo entiende ThinkRail el Spec-Driven Development? ¶

Con un grafo de ficheros SPEC.md que vive al lado del código. Cada spec describe un módulo, se enlaza con otras por identificador y el agente la lee, la busca y la mantiene con unas herramientas propias (spec_*) que trae la extensión pi-spec-graph.

El post “ThinkRail Spec-Driven Development” lo plantea como “un bucle de planificar, implementar y verificar”. La spec estructurada es la fuente de verdad y el código generado pasa a ser “un detalle de implementación” que sigue pudiéndose revisar y editar a mano. Remontan la idea a un trabajo de 2004 de Ostroff, Paige y Makalsky y recomiendan el artículo de Deepak Babu Piskala en arXiv (2602.00180) para profundizar.

Si el SDD es nuevo para ti, en el blog tienes una guía de Spec Driven Development con OpenSpec y otra de Spec Kit, el SDD de GitHub. ThinkRail se mueve en el mismo terreno, pero con una diferencia de enfoque que conviene ver con calma.

¿Cómo es un SPEC.md por dentro? ¶

Todo empieza con una sección en tu AGENTS.md que le dice al agente que el proyecto se guía por specs y dónde están. La regla es “lee las specs antes que el código”: primero goal-and-requirements.md y architecture.md, y después el SPEC.md más cercano al código que va a tocar.

Cada spec arranca con una cabecera YAML. Este es el formato que documentan:

id: submodule-server-workspaces   # identificador único, lo usan otras specs para enlazarlatype: submodule-design            # goal-and-requirements | architecture-design | module-design | submodule-design | task-spectitle: Workspaces del servidorstatus: active                    # draft | active | stale | done | deprecatedparent: module-server             # spec inmediatamente superior en alcancedepends-on: [module-contracts]    # otras specs que importan aquítags: [git, workspaces]

Los campos obligatorios son id, type y title. El resto solo se añade cuando aporta información real.

El contenido de una spec es intención: para qué existe el módulo, de qué es responsable y por qué se tomaron las decisiones que no son obvias. Varias subcarpetas pueden compartir un mismo SPEC.md.

Dos reglas me parecen las más valiosas del planteamiento:

🛡️ Un cambio de código que contradice un SPEC.md necesita confirmación. Si se aprueba, se actualizan el código y la spec a la vez. “Nunca divergir en silencio”.

💡 “Las specs nunca se generan a partir del código”. Las escriben personas. El agente las mantiene, pero la intención es tuya.

¿En qué se diferencia del SDD de OpenSpec o Spec Kit? ¶

La diferencia principal está en la forma de las specs. OpenSpec y Spec Kit trabajan sobre todo con cambios propuestos: escribes una propuesta, la refinas, la implementas y la archivas. ThinkRail apuesta por una documentación viva por módulo, enlazada como un grafo, que el agente consulta de forma selectiva.

Ese “selectiva” es importante. El agente lee solo el SPEC.md más relevante, el más cercano al código que cambia, y busca otros solo cuando los necesita. Así el contexto se mantiene pequeño y los detalles importantes no se entierran entre miles de tokens que no vienen a cuento. Si has sufrido los errores típicos del Spec Driven Development, sabes que inflar el contexto con specs gigantes es uno de los clásicos.

En la interfaz, la pestaña Specs muestra todas las specs como un árbol plegable y, al pulsar una, la abre en modo lectura en el panel central. Y ThinkRail practica lo que predica: el propio repositorio se desarrolla así, con un SPEC.md junto a cada módulo y la regla de que un cambio que mueve una frontera, un contrato o una decisión actualiza la spec en el mismo commit.

Desde la 0.2.0 vuelve activada por defecto la entrevista de diseño: en cada feature, cambio de comportamiento o arreglo de bug, el agente te pregunta, actualiza las specs y tiene que enseñarte las alternativas que ha descartado.

Guía SDD

Antes del grafo de SPEC.md, aprende a escribir una spec

Probarlo →

¿Qué trae la versión 0.2.0? ¶

La 0.2.0 (18 de octubre de 2026) cambia cómo revisas el trabajo del agente. El post se titula “Review the turn, not the chat log”: revisa el turno, no el historial del chat.

Recibos por turno y botón Review turn ¶

Cuando una ejecución cambia ficheros, el turno termina con una línea de resumen del estilo “3 files changed · +27 −4” y un botón Review turn.

Lo interesante es de dónde salen esos números. No se calculan a partir de las herramientas que dice haber usado el agente, sino comparando instantáneas del worktree al empezar y al terminar la ejecución. Así entran también los comandos de shell, los formateadores y los renombrados. Y no tocan HEAD, el índice ni el reflog.

Review turn abre una única pestaña de cambios con todos los ficheros de ese turno apilados: el markdown se ve renderizado y el código como diff normal. “One file” es un modo de vista de la misma pestaña, así que no pierdes el progreso al cambiar.

En el diff de la rama completa (All changes) cada hunk tiene tres botones: Keep, Revert y Ask agent about this hunk. Al aceptar el último hunk de un fichero, se marca como visto y avanza la barra de progreso. La tecla J salta al siguiente fichero sin revisar.

⚠️ El Keep va ligado al contenido del hunk: sobrevive a que se desplacen líneas, pero caduca si el agente vuelve a editar ese hunk. Y en la vista de un solo turno es de solo lectura; para aceptar o revertir tienes que ir al diff de la rama.

Para no congelarse con diffs enormes, los que pasan de 400 líneas cambiadas, los lockfiles y los ficheros generados empiezan plegados. Con más de 50 ficheros te sugiere pasar a la vista de un fichero.

MCP con permisos explícitos ¶

Los chats ya ejecutan los servidores MCP definidos en tu mcp.json, con el soporte de MCP que trae Pi. En Settings › MCP servers tienes presets (Context7, DeepWiki, Linear en solo lectura, Sentry y Playwright), un formulario y la opción de pegar el JSON. Si no tienes claro qué es esto, empieza por cómo instalar un servidor MCP.

En seguridad han hecho los deberes:

• Los ajustes solo guardan referencias. Los secretos tienen que ir como ${VAR} o !command, y rechaza credenciales pegadas en URLs.
• Los servidores que trae un repositorio en .pi/mcp.json no arrancan hasta que apruebas el comando concreto que van a ejecutar.
• Si una llamada puede modificar datos, aparece una aprobación en la tarjeta de la herramienta con los argumentos a la vista: Deny, Allow once, Allow in this chat o Always allow.
• El “Always allow” se guarda en el registro del proyecto, no en el repositorio, así que un repo no puede venir con permisos preaprobados. Y se resetea si cambia el comando o la URL del servidor.

En la misma línea, un proyecto en el que no has confiado no carga sus propios ajustes de .pi, extensiones, skills, prompts ni SYSTEM.md. El aviso de confianza te enseña qué cargaría si confías.

🛡️ Clonar un repo ajeno y abrirlo con un agente es abrir la puerta a lo que ese repo quiera inyectar. ThinkRail trata esa confianza como algo que concedes tú, proyecto a proyecto.

Atajos y rendimiento ¶

Cmd/Ctrl+K abre un selector que solo enseña los chats que necesitan tu respuesta o siguen trabajando, agrupados por proyecto y con los que esperan tu input primero. Incluye workspaces que no tienes abiertos en esa ventana.

La interfaz se ha rediseñado: Projects, Specs, Files, Changes y Review pasan a barras laterales, hay dos temas nuevos (Minimal Light y Minimal Dark) y el plan se muda a una barra de TODO List con “Up next”, “Now” y “Done”. Un dato que cuentan sin pudor: antes, mostrar u ocultar un panel remontaba la aplicación entera, unos 1.900 montajes de componentes por clic. Ya no.

¿Puedo reutilizar mis skills de Claude Code o Gemini? ¶

Sí. ThinkRail detecta las Agent Skills portables que ya tengas para otros agentes y las lee donde están, sin copiarlas. Pi sigue siendo quien las interpreta y ejecuta.

Busca en las carpetas de usuario ~/.pi, ~/.claude, ~/.codex, ~/.copilot y ~/.gemini. A nivel de proyecto mira las carpetas de Pi, .claude/ y .gemini/; Codex y Copilot solo se detectan desde la carpeta de usuario.

Como las skills de proyecto cambian de un repo a otro, primero eliges proyecto y workspace. El botón Skills de arriba a la derecha muestra la lista separada entre las que trae ThinkRail y las de tus agentes y el proyecto. Si cambian en disco, aparece un aviso con un botón para recargarlas.

Las skills que vienen de serie son flujos de trabajo: preparar el proyecto, hacer brainstorming de diseño y entregar un pull request (push de la rama y apertura o actualización del PR con tu gh). Si quieres entender la diferencia entre skills, prompts y MCP antes de llenar la carpeta, tienes esta comparativa.

¿Qué modelos puedo usar con ThinkRail? ¶

Los que pueda usar Pi. Te identificas con JetBrains AI o conectas cualquier proveedor a través de la autenticación propia de Pi. ThinkRail no tiene cuentas propias ni guarda tokens.

En la maqueta de la web se ve una sesión con Claude Opus 4.8 y el esfuerzo en “Low”, pero no publican una lista cerrada de modelos. El modelo se elige por sesión, y el selector separa los grupos de proveedores. Si un chat guardado tenía un modelo que ya no está disponible, se reabre con el modelo por defecto y solo cambia el guardado cuando envías un mensaje.

Sobre el precio: la web no menciona ninguno. Es software libre y lo que pagas es el consumo de tu proveedor de modelos.

¿Cómo instalo ThinkRail? ¶

Tienes dos formas que conviven: la app de escritorio nativa y la CLI thinkrail, que abre la misma aplicación en el navegador. Ambas embeben el mismo host y guardan el estado en ~/.thinkrail.

Para escritorio, en la página de releases hay instaladores para macOS 14+ (Apple Silicon o Intel), Windows x64 y Linux x64/ARM64. En Linux necesitas glibc 2.38+ con GTK 3 y WebKitGTK 4.1, es decir, Ubuntu 24.04 o más nuevo:

# Dependencias de la app de escritorio en Ubuntu 24.04+
sudo apt install libgtk-3-0 libwebkit2gtk-4.1-0 libayatana-appindicator3-1 librsvg2-2

La CLI se instala con un script que descarga el binario, verifica su SHA-256 y lo deja en tu PATH:

# macOS / Linux (y Windows con Git Bash)
curl -fsSL https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.sh | bash

# Abre ThinkRail con un repositorio como proyecto
thinkrail ~/code/mi-repo

En Windows, desde cmd o PowerShell:

powershell -c "irm https://raw.githubusercontent.com/JetBrains/thinkrail/main/install.ps1 | iex"

Solo necesitas git en el PATH y un proveedor de modelos. El instalador admite --channel stable|nightly y --version para fijar una versión; thinkrail update lo actualiza y thinkrail uninstall lo quita (te pregunta si borrar ~/.thinkrail, que por defecto se conserva).

⚠️ Antes de pegar un curl | bash en tu terminal, lee el script. Aplica a ThinkRail y a cualquier otra herramienta.

Un apunte sobre firmas: en Windows está todo firmado; en macOS la CLI está firmada pero aún no notarizada, y algunos DMG antiguos o compilados en local pueden no estar firmados y Gatekeeper los bloqueará. En Linux nada está firmado.

¿Qué datos envía ThinkRail? ¶

ThinkRail recoge eventos básicos de uso (arranques, chats creados, mensajes enviados, proveedores conectados) ligados a un ID de instalación aleatorio. Según el README, esa analítica nunca incluye prompts, código, ficheros, credenciales ni identidad de cuenta.

Los informes de error se envían siempre, con el tipo y el código del error y en qué parte del código de ThinkRail ocurrió, sin mensajes de error, rutas, nombres ni URLs. El uso adicional del producto solo se comparte si activas Share additional usage data, que se ofrece en el primer arranque y vive en Settings › Privacy. Desde la terminal, thinkrail --no-analytics o THINKRAIL_NO_ANALYTICS=1 lo desactivan para esa ejecución.

Hay algo que no me encanta, aunque lo cuentan a las claras. Con el uso adicional activado, una build empaquetada puede abrir una vez el blog de ThinkRail en tu navegador para relacionar tu instalación con la visita a la web que te trajo, solo si aceptaste cookies de marketing o no se requiere consentimiento. Ese vínculo caduca a los 30 días. Si no te gusta, déjalo desactivado.

¿Cómo está construido por dentro? ¶

Con tres anillos y una regla clara de dependencias. Para quien quiera mirar el código, es un repositorio muy didáctico.

• Engine host (packages/server y packages/shared): un servidor HTTP y WebSocket con Bun.serve que mantiene una sesión de Pi en el mismo proceso por cada chat. Lo arrancan la CLI (apps/cli) o la app de escritorio (apps/desktop, empaquetada con Electrobun).
• The wire (packages/contracts): el protocolo tipado y versionado entre host e interfaz, la única unión entre ambos.
• UI client (apps/web): React 19, Zustand y Tailwind v4, que se publica por separado y solo depende de los contratos.

La arquitectura deja ver hacia dónde van. El cliente web está pensado “mobile-first” y el endpoint es configurable, de modo que un navegador remoto o un móvil puede apuntar al host a través de Tailscale. La autenticación de quién accede al host la delegan en la red: ACLs de Tailscale e identidad de dispositivo, sin login propio.

También hay un principio que conviene conocer si vas a abrir varias pestañas: hidratar y luego escuchar. Al conectar, el cliente lee el estado actual (proyectos, workspaces, sesiones, transcripciones) y después se suscribe a los cambios en vivo. Una recarga, una segunda pestaña o un reinicio del host reconstruyen lo mismo.

Para desarrollar sobre él necesitas Bun 1.4.4, Node.js 22.19 o superior y un proveedor de Pi autenticado. Con bun install y bun run dev levantas host y cliente a la vez.

¿Para quién tiene sentido ThinkRail hoy? ¶

Para quien ya usa Pi o tiene curiosidad por él y quiere una interfaz sin renunciar a su profundidad. El documento de objetivos lo dice así: recién llegados que quieren una rampa visual, usuarios con experiencia que quieren un IDE alrededor del agente y gente que construye “agent-first” y quiere ir rápido sin perder el control.

Ahora, lo que falta. La documentación oficial no existe todavía: el enlace “Docs” de la web dice “Coming soon” y toca aprender con el README, el blog y las specs del repositorio. Es un proyecto incubado en versión 0.x, así que espera cambios. Y si tus extensiones de Pi tocan la interfaz, no te van a funcionar.

Lo que sí me parece una buena señal es la coherencia. El equipo describe el producto con specs, escribe sus límites en un apartado de “non-goals” (nada de un segundo runtime de agente, nada de cuentas de ThinkRail) y publica cada decisión. Si te interesa cómo llevar estas ideas a otro agente, en Claude Code vs OpenCode tienes el panorama de las alternativas en terminal.

El siguiente paso que anuncian es el soporte completo de extensiones, para que ThinkRail pueda crear las herramientas que necesita según cómo trabajas. Es la segunda mitad de su lema: aprender tu proyecto con specs vivas hoy y construir sus propias capacidades mañana.

¿Le vas a dar una tarde a ver si tu próximo refactor sale mejor con un worktree, un grafo de specs y un botón de Review turn?

Preguntas frecuentes ¶

¿Qué es JetBrains ThinkRail? ¶

ThinkRail es un IDE agéntico open source (Apache 2.0) de JetBrains InnovationHub construido alrededor del agente de código Pi. Aísla el trabajo del agente en workspaces sobre git worktree, añade editor, diffs, terminales y revisión, y mantiene el conocimiento del proyecto en un grafo de ficheros SPEC.md.

¿ThinkRail es gratis? ¶

Sí. Es software libre con licencia Apache 2.0 y la web no menciona ningún precio. Pagas el consumo del proveedor de modelos que conectes, ya sea JetBrains AI o cualquier otro que soporte Pi.

¿ThinkRail sustituye a IntelliJ o a Junie? ¶

No. Es una aplicación independiente centrada en el agente Pi, no un plugin de IntelliJ. Desde ThinkRail puedes abrir cualquier worktree en el IDE que tengas instalado, así que convive bien con las herramientas de siempre.

¿Necesito instalar Pi aparte para usar ThinkRail? ¶

No. ThinkRail trae Pi embebido y lo ejecuta en su propio proceso (la 0.2.0 incluye Pi 1.2.0). Si ya tienes Pi instalado, ambos comparten la carpeta ~/.pi con proveedores, modelos, extensiones e historial.

¿Qué es un workspace en ThinkRail? ¶

Es un git worktree con su propia rama, ficheros, terminales y chats, guardado bajo ~/.thinkrail/worktrees. Permite que varios agentes trabajen en paralelo sin tocar tu copia de trabajo. Además existe un Default workspace que trabaja sobre la carpeta del proyecto, solo si lo eliges tú.

¿Cómo funciona el Spec-Driven Development en ThinkRail? ¶

Cada módulo tiene un SPEC.md con cabecera YAML (id, type, title y opcionales como status, parent o depends-on). Las specs se enlazan formando un grafo que el agente consulta y mantiene con herramientas spec_*. Las escriben personas y un cambio que las contradice necesita confirmación.

¿Puedo usar mis skills de Claude Code en ThinkRail? ¶

Sí. ThinkRail lee en su sitio las Agent Skills de ~/.claude, ~/.codex, ~/.copilot, ~/.gemini y ~/.pi, además de las de proyecto en .claude/, .gemini/ y las carpetas de Pi. Pi es quien las interpreta, así que alguna puede comportarse distinto.

¿ThinkRail soporta MCP? ¶

Sí, desde la versión 0.2.0. Ejecuta los servidores de tu mcp.json con presets como Context7, DeepWiki, Sentry o Playwright. Pide aprobación antes de llamadas que puedan modificar datos y no arranca servidores definidos por un repositorio hasta que los apruebas.

¿En qué sistemas operativos funciona ThinkRail? ¶

Hay app de escritorio para macOS 14+ (Apple Silicon e Intel), Windows x64 y Linux x64/ARM64 con glibc 2.38+ (Ubuntu 24.04 o superior). La CLI thinkrail abre la misma aplicación en el navegador y se instala con un script en macOS, Linux y Windows.

¿ThinkRail envía mi código a JetBrains? ¶

Según el README, no. La analítica básica recoge eventos de uso con un ID aleatorio y nunca incluye prompts, código, ficheros ni credenciales. Los informes de error se envían siempre, pero sin mensajes, rutas ni datos de tus proyectos. El uso adicional se desactiva en Settings › Privacy o con --no-analytics.

TL;DR ¶

• 🚂 ThinkRail es el IDE agéntico open source de JetBrains InnovationHub construido como capa fina sobre el agente Pi.
• 🌳 Cada workspace es un git worktree: agentes en paralelo y tu rama principal intacta hasta que fusionas.
• 📐 Su SDD se basa en un grafo de SPEC.md por módulo que escriben personas y el agente mantiene.
• 🧾 La 0.2.0 trae recibos por turno, revisión por hunks con Keep/Revert y MCP con permisos explícitos.
• ⚠️ Es una versión 0.x, sin documentación oficial todavía: pruébalo con un proyecto de bajo riesgo.

Fuentes ¶

• Repositorio de ThinkRail en GitHub, con su README, goal-and-requirements.md y architecture.md
• Web oficial de ThinkRail
• Introducing ThinkRail, blog oficial (19 de agosto de 2026)
• ThinkRail Workspaces, blog oficial (3 de septiembre de 2026)
• ThinkRail Spec-Driven Development, blog oficial (15 de septiembre de 2026)
• An agentic IDE that follows Pi’s philosophy, blog oficial (1 de octubre de 2026)
• ThinkRail 0.2.0: review the turn, not the chat log, blog oficial (18 de octubre de 2026)
• Paquete @earendil-works/pi-coding-agent en npm

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter