Lanzamiento de Paneflow en Show HN

Lanzar un agente de código se ha vuelto normal. Abres una terminal, escribes un comando y Claude Code, Codex, OpenCode u otra CLI empieza a trabajar.

El problema aparece cuando lanzas varios.

Un agente corrige un bug. Otro prepara una refactorización. Un tercero revisa un diff. Al lado, un servidor de desarrollo está corriendo, los tests pasan o fallan y cada terminal cuenta una parte distinta de la historia. En algún momento, lo difícil ya no es iniciar agentes. Es saber cuál está haciendo qué, cuál espera una respuesta, cuál terminó y en qué rama está trabajando.

Paneflow nació de ese problema exacto: mantener varios agentes de código visibles, controlables y comprensibles dentro de un único espacio de trabajo local.

La demo completa también está disponible en YouTube.

El hilo de lanzamiento está en Hacker News: Show HN: Paneflow.

La terminal sola no siempre basta

Me gustan las terminales. tmux, Zellij, Ghostty, Kitty y WezTerm son herramientas muy buenas, sobre todo cuando trabajas por SSH o en una máquina remota.

Pero cuando ejecutas varios agentes locales en el mismo proyecto, el problema cambia. Una cuadrícula de terminales muestra procesos. No te dice realmente qué agente está pensando, cuál espera tu aprobación, cuál produjo un diff interesante o cuál está repitiendo el trabajo de otro.

Con suficientes ventanas abiertas, acabas reconstruyendo el estado del proyecto en tu cabeza. Pasas de una terminal a otra, relees el scrollback, buscas el directorio correcto, verificas la rama actual y vuelves al diff. Una vez no es un gran problema. Como forma principal de trabajo, se vuelve caro.

Paneflow no intenta reemplazar tu editor. Reemplaza esa capa de coordinación que muchos desarrolladores construyen a mano con splits, nombres de ventanas, convenciones de ramas y mucha memoria a corto plazo.

Un espacio de trabajo por tarea, no solo un panel por comando

En Paneflow, un panel sigue siendo una terminal real. Puedes ejecutar Claude Code, Codex, OpenCode, Grok Builder o cualquier otra CLI que funcione en una shell.

La diferencia está alrededor de la terminal.

Una tarea puede tener su agente, sus tests, su servidor de desarrollo, su rama git, sus diffs y sus sesiones anteriores. Paneflow mantiene esas piezas en el mismo espacio de trabajo para que no tengas que redescubrirlas cada vez que cambias de contexto.

Cuando quieres aislar el trabajo, cada tarea puede correr en su propio git worktree. La vista Review muestra después los diffs lado a lado, un worktree por columna. Ves lo que produjo cada agente sin cambiar de ventana, rama ni editor.

Esa organización se vuelve especialmente útil cuando dos agentes trabajan en zonas cercanas del código. Puedes mantener sus salidas abiertas, comparar sus cambios y decidir cuál merece conservarse, corregirse o descartarse.

La coordinación pasa por la interfaz CLI

La apuesta más importante de Paneflow no es la visualización. Es la coordinación.

Llamo a esa capa Paneflow Conductor. Por ahora, lo que expongo a los agentes pasa intencionalmente por la interfaz CLI y el socket local. La GUI sigue siendo el lugar donde supervisas, lees y tomas el control de cualquier panel.

paneflow ps lista los paneles y agentes en ejecución con su estado real. paneflow watch emite cambios como JSONL, alimentados por hooks y el event bus en lugar de consultar la terminal en bucle. Un agente puede observar qué está corriendo, esperar un evento, preparar un prompt para otro panel y dejarte aprobar el envío final.

Por defecto, Paneflow rellena los prompts y tú sigues pulsando Enter. Auto-submit existe, pero es opt-in. Esa decisión es intencional: cuando varios agentes pueden actuar dentro del mismo proyecto, el control humano debe seguir visible.

Los agentes pueden leer sin tomar el control

Otra pieza importante es el servidor MCP integrado. Expone tres herramientas de solo lectura: list_panes, read_pane y search_pane.

En la práctica, Claude Code en un panel puede leer la salida de tests que Codex acaba de producir en otro. Un agente puede buscar un error en una terminal vecina antes de proponer un arreglo. Ya no necesitas copiar y pegar la salida de una herramienta en otra.

El límite es estricto: este puente no puede escribir en un panel ni manejar un agente por ti. La salida de terminal se trata como no confiable, porque un transcript de agente o un repositorio puede contener texto hostil. Paneflow hace más explícito el intercambio de contexto, pero no convierte cada terminal en una superficie de ejecución abierta.

Esa frontera es la parte que me importa: dar a los agentes suficiente contexto para que no trabajen a ciegas, sin darles poder silencioso sobre toda la sesión.

Por qué una app nativa

Paneflow está escrito en Rust y usa GPUI, el framework de interfaz detrás de Zed. Esa elección viene de una restricción simple: los agentes pueden ejecutarse durante mucho tiempo, a veces en paralelo, y el lugar que los contiene debe seguir siendo ligero.

No quería una app Electron alrededor de terminales que ya ejecutan procesos pesados. Tampoco quería una herramienta solo para macOS cuando mi propio trabajo se mueve entre Linux y Windows. Hoy Paneflow ofrece builds para Linux, macOS Apple Silicon y Windows x64. macOS Intel y Windows ARM64 aún no se distribuyen.

El resultado no es un IDE. Es un espacio de trabajo local y open source para desarrolladores que ya saben usar sus agentes CLI, pero ya no quieren coordinarlo todo a mano.

Prueba Paneflow en tu próxima sesión multiagente

Si lanzas un solo agente de vez en cuando, tu terminal actual probablemente basta.

Si empiezas a ejecutar varios agentes en paralelo, la pregunta cambia: ¿cómo mantienes su estado legible, sus ramas separadas, sus diffs revisables y su contexto compartible sin perder el control?

Ese es exactamente el problema que Paneflow busca resolver.

Descarga Paneflow, abre un proyecto, lanza dos agentes en dos paneles y comprueba si el espacio de trabajo reduce la carga mental que habías empezado a aceptar como normal.