Show HN: Whiteboard (YC W26) – Um IDE de código aberto para design de software cuidadoso

Artigo original ↗ Discussão no Hacker News ↗

Uma ferramenta de código aberto chamada Whiteboard pretende tornar o desenvolvimento de software assistido por IA mais compreensível, transformando mudanças de código em diagramas vinculados, diffs semânticos e “canvases” visuais que ficam ao lado de editores existentes e fluxos de codificação agentiva. Os comentaristas são amplamente positivos sobre a ideia de uma camada dedicada de visualização para revisão de código e pensamento de arquitetura, mas questionam se isso acrescenta mais uma fonte de verdade potencialmente defasada em comparação com especificações em markdown ou IDEs existentes. Também há debate ativo sobre o posicionamento (IDE vs. canvas), suporte a plataformas e como esse tipo de ferramenta deve evoluir à medida que os agentes assumem mais da implementação e os humanos se concentram em planejamento e revisão.

Escopo e posicionamento do produto

  • Whiteboard é uma ferramenta de desktop local apenas, de código aberto (atualmente construída sobre o VS Code) para visualizar e entender mudanças de código, especialmente as produzidas por agentes.
  • Inicialmente foi comercializado como um “IDE”, mas muitos comentaristas objetaram porque ele não consegue editar arquivos; os mantenedores agora o apresentam como um “canvas” ou companheiro para IDEs/ADEs existentes.
  • Destina-se a complementar terminais, agentes de codificação e orquestradores, não a substituí-los.

Recursos principais e casos de uso

  • Diagramas visuais ligados diretamente a código e diffs; forte ênfase na navegação de diagramas/especificações até a implementação.
  • Visualizador de diff semântico e renderização animada, com “sensação humana”, são amplamente elogiados.
  • Principais fluxos de trabalho: revisar PRs complexos, entender código gerado por agentes, reduzir a carga cognitiva e manter um modelo mental da arquitetura.
  • Alguns veem isso como um único recurso (um MCP + GUI) que poderia viver dentro de outro harness; outros veem valor standalone.

Fluxo de trabalho e integração com agentes

  • Fluxo típico descrito: plano humano → agente programa → sessão no Whiteboard explica a implementação e os trade-offs.
  • No longo prazo, eles querem um modo de scratchpad/plano com artefatos versionados, reduzindo a lacuna entre design e implementação.
  • A ferramenta explicitamente não está vinculada a um fornecedor específico de agentes; a integração com vários agentes (Claude, Copilot CLI, etc.) está em andamento.

Plataforma, empacotamento e desempenho

  • Existem builds para macOS e Fedora; há forte demanda por Windows, Debian/Ubuntu (.deb), Arch (AUR), Nix, Flatpak, AppImage.
  • A base Electron/VS Code torna o app grande (~736MB); os mantenedores reconhecem isso e planejam uma reescrita mais nativa e enxuta.

Preocupações e ceticismo

  • Há várias preocupações sobre criar outra “fonte da verdade” extra e descolada em vez de usar ferramentas existentes (Notion, Google Docs, Linear, markdown + Mermaid/PlantUML/C4).
  • Alguns temem diagramas alucinados ou imprecisos; os mantenedores enfatizam que todos os diagramas estão vinculados ao código para evitar isso.
  • Há uma inquietação mais ampla sobre ferramentas que incentivam a dependência de IA e afastam os humanos do código; outros argumentam que essa ferramenta realmente promove compreensão mais profunda.

Direções futuras e monetização

  • Planos para um produto hospedado, multiplayer/web, com integração mais estreita a especificações, fluxos de PR e um “mapa de software” continuamente atualizado.
  • A monetização provavelmente virá dessa oferta hospedada, enquanto a ferramenta local continua open-source.