Um diagrama é dado, não um desenho

Eu dei a um modelo a mesma arquitetura de 44 nós duas vezes.

Na primeira vez, pedi SVG bruto — coloque cada caixa, roteie cada aresta, me entregue as coordenadas. Na segunda vez, pedi que descrevesse o mesmo sistema como JSON tipado e deixasse um mecanismo de layout desenhá-lo. Mesmo modelo, mesma sessão, mesmo briefing. A única coisa que mudei foi o limite de saída.

As caixas estão boas em ambas. Quero ser claro sobre isso, porque a versão usual desse argumento está desatualizada. Modelos colocam caixas rotuladas bem agora. Se você pedir a um modelo de ponta atual um fluxograma de seis caixas como SVG, você recebe um fluxograma de seis caixas limpo, e se é isso que você precisa, vá em frente — é a ferramenta certa e não vou fingir o contrário.

O que quebrou foram as arestas.

Sem um algoritmo de roteamento, o modelo simplesmente desenhou longas diagonais passando diretamente por caixas não relacionadas. Não foram poucas — em toda parte onde o gráfico ficou denso. E quando mudei um nó, todo o layout de coordenadas manualmente colocado teve que ser regenerado e voltou diferente.

Essa segunda parte é a que realmente me irritou. Não é um bug de renderização que você pode ignorar. A imagem é um artefato morto: você não pode compará-la, não pode editar uma caixa, não pode obter a mesma duas vezes. Cada mudança é uma regeneração completa e um novo lançamento de dados.

Isso não é um problema de "esperar por um modelo melhor"

Esta é a parte que eu contestaria se outra pessoa escrevesse, então deixe-me fazer o argumento.

Roteando um conector ao redor de obstáculos em um gráfico aninhado é otimização de restrições globais. É a coisa específica que mecanismos de layout como o ELK existem para resolver. Um modelo que emite SVG tem que se comprometer com um x/y para cada ponto, em ordem, sem possibilidade de retroceder uma vez que vê a imagem inteira — está prevendo o próximo token, não resolvendo um layout.

Então, um modelo melhor lhe dá caixas mais bonitas, não arestas desenroladas. A falha é estrutural, e eu esperaria que se reproduzisse em modelos após algumas dezenas de nós. Se você não acredita nisso, o movimento honesto é testá-lo: jogue uma arquitetura de 40 nós em qualquer modelo em que você confie e observe as arestas. (Eu escrevi sobre o método por trás daquela imagem — mesmo modelo, uma tentativa, sem passagem de correção — em um post separado, linkado no final.)

A conclusão que cheguei: um desenho é o tipo de saída errado. Não "IA não pode fazer diagramas." O limite está no lugar errado.

Então mova o limite

Deixe o modelo fazer a coisa que ele é genuinamente bom — descrever o que o diagrama significa — e deixe um mecanismo real cuidar da matemática espacial. Isso é o Glyphic. O modelo emite JSON tipado simples. Sem coordenadas, sem gramática DSL para errar:

{
  "type": "fluxograma",
  "nodes": [
    { "id": "especificação", "label": "JSON Tipado" },
    { "id": "motor", "label": "Mecanismo de Layout" },
    { "id": "saída", "label": "SVG / PNG" }
  ],
  "edges": [
    { "source": "especificação", "target": "motor" },
    { "source": "motor", "target": "saída" }
  ]
}

O ELK calcula posições e roteamento (d3 para os tipos de dados), e o SVG é rasterizado para PNG nativamente em Rust via resvg. Três coisas sobre isso se mantêm, não importa quão bons os modelos se tornem.

A validação é um contrato, não uma falha. O JSON atinge um esquema Zod rigoroso antes que qualquer coisa seja renderizada. Quando o modelo erra, você recebe de volta edges[2].target referencia o nó desconhecido 'paymentss' — preciso e corrigível na próxima tentativa. É isso que faz os loops de gerar → validar → corrigir → renderizar funcionarem de fato. Uma DSL como Mermaid falha na análise com um erro de digitação e não entrega nada ao agente para agir.

Não há navegador na pilha. Cada caminho "renderizar diagramas no lado do servidor" que tentei acabou chamando o Chromium sem cabeça — ~300MB e um imposto de inicialização a frio em cada invocação. O layout e a rasterização aqui são ambos nativos, então ele é implantado em uma Lambda, um trabalho de CI ou um loop de agente como uma dependência Node comum. Isso é um fato de infraestrutura, não uma afirmação sobre a qualidade do modelo, o que torna isso a coisa mais durável que posso dizer sobre o projeto.

Ele permanece barato em escala. Desenhar manualmente um grande diagrama é milhares de tokens de coordenadas — lento e propenso a estourar o teto de saída e truncar em uma renderização quebrada. JSON compacto, geometria gerada de forma determinística.

E porque o JSON é a fonte da verdade, o diagrama permanece um dado editável. Compare, mude um nó, re-tematize, re-renderize. Não uma imagem que você regenerar do zero e esperar.

O que você realmente obtém

Uma chamada lhe dá SVG, um PNG de alta resolução e JSON do React Flow. Existem 18 tipos de diagrama por trás de um único esquema — arquitetura com VPCs e clusters aninhados, sequência, ERD com notação de pé de corvo, UML de classe, máquinas de estado, fluxogramas, Gantt, linhas do tempo, Sankey, árvores Git, mapas mentais, C4, pizza, quadrante, kanban, jornadas do usuário, mapas de árvore e uma tela livre. Cada um deles é renderizado na