Lanzamiento de Paneflow en Show HN

Contexto del lanzamiento. Este artículo y la demo siguiente describen la interfaz de junio de 2026, incluida la antigua vista Review con una columna por worktree. Para Paneflow 0.17.4, consulta la presentación de Paneflow y la guía de Changes.

Paneflow se lanzó en Show HN en junio de 2026 como un multiplexor de terminal nativo para agentes de código. El objetivo era reunir los agentes, el contexto del proyecto y la revisión de código en una interfaz local.

Con Claude Code corrigiendo un bug, Codex revisando cambios y un servidor de desarrollo ejecutándose al lado, cada terminal contiene una parte del estado del proyecto. Cambiar entre ellas exige encontrar el directorio correcto, comprobar la rama y leer la salida para saber quién necesita una respuesta. Paneflow reunía esas terminales y su contexto.

Mira la demo completa del lanzamiento de Paneflow en YouTube o lee la discusión Show HN: Paneflow.

Reunir las terminales y los cambios de una tarea

Cada panel seguía siendo una terminal con un proceso CLI corriente. Claude Code, Codex, OpenCode, los tests y los servidores de desarrollo podían ejecutarse juntos en el mismo espacio de trabajo.

Una tarea podía usar su propio worktree Git para separar sus archivos y su rama. La vista Review de la interfaz del lanzamiento mostraba los diffs en paralelo, un worktree por columna. Podías comparar los cambios de dos tareas antes de decidir qué conservar o corregir. Los worktrees separados seguían requiriendo revisión y resolución de conflictos al combinar las ramas.

Coordinar los paneles desde la CLI

Paneflow Conductor exponía la coordinación mediante la CLI y un socket local. paneflow ps listaba los paneles y agentes; paneflow watch emitía eventos como JSONL. El seguimiento de actividad usaba hooks y el bus de eventos, según la integración disponible para cada agente.

La interfaz permitía leer la salida, interrumpir un proceso o tomar el control de una terminal. El envío de prompts rellenaba el texto por defecto y te dejaba pulsar Enter. El envío automático requería una activación explícita.

Compartir salidas con un puente MCP de solo lectura

El servidor MCP exponía tres herramientas: list_panes, read_pane y search_pane. Un agente conectado al puente podía leer la salida de tests de otro panel o buscar un error antes de proponer una corrección.

El puente no podía escribir texto en los paneles ni controlar procesos. La salida de terminal se trataba como datos no confiables: compartir la transcripción de un agente no daba autoridad a sus instrucciones. El acceso de lectura y el control por CLI tenían permisos separados.

Una interfaz nativa para procesos locales

Paneflow estaba construido en Rust con GPUI, el framework de interfaz usado por Zed. Los agentes seguían siendo procesos CLI locales conectados a sus propios proveedores de modelos.

El lanzamiento acercaba el contexto del proyecto y la revisión a esos procesos. Asignar tareas, responder a las solicitudes de aprobación y revisar el código producido seguía siendo tu responsabilidad.