Show HN: Whiteboard (YC W26) – Un IDE de código abierto para un diseño de software reflexivo

Artículo original ↗ Discusión en Hacker News ↗

Una herramienta de código abierto llamada Whiteboard busca hacer más comprensible el desarrollo de software asistido por IA convirtiendo los cambios de código en diagramas enlazados, diffs semánticos y “canvases” visuales que se sitúan junto a los editores existentes y los flujos de trabajo de programación con agentes. Los comentaristas ven con buenos ojos la idea de una capa de visualización dedicada para la revisión de código y el pensamiento arquitectónico, pero cuestionan si añade otra fuente de verdad, potencialmente desactualizada, frente a especificaciones en markdown o IDEs existentes. También hay un debate activo sobre el posicionamiento (IDE vs. canvas), el soporte de plataformas y cómo deberían evolucionar estas herramientas a medida que los agentes asumen más trabajo de implementación y los humanos se centran en la planificación y la revisión.

Alcance del producto y posicionamiento

  • Whiteboard es una herramienta de escritorio de código abierto, local-only (actualmente construida sobre VS Code) para visualizar y entender cambios en el código, especialmente los producidos por agentes.
  • Inicialmente se comercializó como un “IDE”, pero muchos comentaristas se opusieron porque no puede editar archivos; ahora los mantenedores lo presentan como un “canvas” o complemento para IDEs/ADEs existentes.
  • Está pensado como complemento de terminales, agentes de programación y orquestadores, no como reemplazo.

Funciones principales y casos de uso

  • Diagramas visuales enlazados directamente con el código y los diffs; se pone un fuerte énfasis en la navegación desde diagramas/especificaciones hasta la implementación.
  • El visor de diffs semánticos y el renderizado animado, con “sensación humana”, son muy elogiados.
  • Flujos de trabajo principales: revisar PR complejos, entender código generado por agentes, reducir la carga cognitiva y mantener un modelo mental de la arquitectura.
  • Algunos lo ven como una única función (un MCP + GUI) que podría vivir dentro de otro harness; otros ven valor independiente.

Flujo de trabajo e integración con agentes

  • El flujo típico descrito: plan humano → el agente programa → una sesión en Whiteboard explica la implementación y las compensaciones.
  • A largo plazo, quieren un modo de pizarra/plan con artefactos versionados, reduciendo la brecha entre diseño e implementación.
  • La herramienta no está vinculada explícitamente a un proveedor de agentes específico; la integración con varios agentes (Claude, Copilot CLI, etc.) está en progreso.

Plataforma, empaquetado y rendimiento

  • Existen versiones para macOS y Fedora; hay una fuerte demanda de Windows, Debian/Ubuntu (.deb), Arch (AUR), Nix, Flatpak, AppImage.
  • La base de Electron/VS Code hace que la app sea grande (~736MB); los mantenedores lo reconocen y planean una reescritura más nativa y ligera.

Preocupaciones y escepticismo

  • Hay varias preocupaciones sobre crear otra “fuente de verdad” extra y divergente frente a herramientas existentes (Notion, Google Docs, Linear, markdown + Mermaid/PlantUML/C4).
  • Algunos temen diagramas alucinados o inexactos; los mantenedores enfatizan que todos los diagramas están enlazados al código para evitarlo.
  • Existe una inquietud más amplia sobre herramientas que fomentan la dependencia de la IA y alejan a las personas del código; otros argumentan que esta herramienta promueve una comprensión más profunda.

Direcciones futuras y monetización

  • Hay planes para un producto alojado, multijugador/web, con integración más estrecha en especificaciones, flujos de PR y un “mapa de software” continuamente actualizado.
  • La monetización probablemente vendrá de esa oferta alojada, mientras que la herramienta local seguirá siendo de código abierto.