Pitch: Por que ainda é tão difícil substituir o AutoCAD por um CAD 2D open source?

Tenho uma metalúrgica, e desenho técnico pra nós é o dia inteiro: chega desenho de cliente em DWG e DXF, a equipe ajusta e manda pra produção.

Faz anos que tento tirar a empresa da dependência de Windows e de software proprietário. Em 2020 comecei a desenvolver o Sistec, nosso ERP, em Laravel. Arquivos rodam no Nextcloud, a telefonia no Issabel, e em 2022 fiz em Flutter o app que a produção e os clientes usam. Tudo isso bem antes dessa onda de IA e agentes.

O CAD sempre ficou de fora. E sempre volta a mesma pergunta: por que até hoje não existe uma alternativa open source boa de verdade pro AutoCAD?

Existe LibreCAD, QCAD, FreeCAD. São projetos sérios, feitos por gente boa, mas aqui na empresa todo mundo que testou acabou voltando pro software pago. Depois de muita conversa sobre isso, cheguei na conclusão de que o problema não é só técnico.

CAD é detalhe

Desenhar uma linha é fácil. O difícil é o cursor que gruda no ponto errado quando duas linhas se cruzam, a medida que fica longe demais do desenho, o preenchimento de uma área que trava a tela, o arquivo que vem de outro programa em escala reduzida e as medidas não batem.

Esses detalhes só aparecem com arquivo real, na mão de quem desenha. E aí o modelo tradicional de open source não fecha a conta:

• quem desenha não programa, e quem programa não desenha;
• quem desenha não vai abrir issue em inglês no GitHub e esperar meses. Ele volta pro AutoCAD/BricsCAD e segue o trabalho;
• muitas vezes quem mantém o projeto não usa o software pra trabalhar no dia a dia, então não sente o mesmo atrito que o usuário;
• o DWG, formato do AutoCAD, é fechado, e ler e gravar com fidelidade dá muito trabalho;
• não tem modelo de negócio claro pra CAD 2D. Quem paga licença compra AutoCAD/BricsCAD ou outro software proprietário.

O que fizemos

Aqui temos o Walter, nosso agente que roda no OpenClaw. Ele já cuida de boa parte dos nossos sistemas internos e fica nos grupos do nosso chat interno junto com a equipe.

Em setembro pedi pra ele um CAD 2D integrado ao nosso sistema de produção. O primeiro commit foi às 20h26 do dia 18/09. Na manhã seguinte o Traço já abria DWG e o pessoal estava usando.

E antes que alguém pergunte: não usamos o REA nem nenhuma outra ferramenta de engenharia reversa. Nada de decompilador ou disassembler em software de ninguém. O DXF segue a referência pública da Autodesk, e hoje o DWG é lido e gravado por uma biblioteca aberta, a acad-ts. O único formato fechado que o Traço abre é o da nossa máquina de corte, só pra visualizar, e esse foi entendido abrindo os nossos próprios arquivos.

Mas fazer um protótipo de CAD em 1 dia hoje não é grande coisa. O que fez diferença foi o que veio depois.

Na versão que usamos aqui dentro, colocamos um botão de relatar problema. O usuário marca na tela o que está errado, escreve uma frase e manda. O relato cai num grupo onde o Walter está, já com o print e com o arquivo original do jeito que foi aberto. O Walter reproduz com o arquivo real, acha a causa, corrige, roda os testes e abre o pedido de merge. Depois do merge o deploy é automático.

Alguns casos reais:

• Medidas fora de escala. Um projetista relatou às 19h01 que as medidas de um desenho não batiam. O arquivo vinha de outro programa, com o desenho reduzido 20 vezes. Às 20h23 a correção estava em produção, testada com o arquivo dele.
• Tela travando. Um projetista preencheu uma área e teve que dar F5. Eram dois problemas, e um deles era um laço que usava uma coordenada grande como índice. Acima de certo valor, em ponto flutuante, i + 1 === i, e o laço não termina nunca. Isso ninguém acha revisando código, só aparece em produção.
• Arquivo que não abria e não dava erro. O usuário tinha fechado todas as abas e o desenho importado ia pra lugar nenhum. Relatado às 7h20, corrigido em produção às 7h30.

O usuário não precisa saber o que é issue, nem escrever em inglês, nem montar caso de teste. Ele reclama do jeito que reclamaria com um colega do lado.

Como funciona por dentro

Pra quem quiser os detalhes técnicos:

• o Traço é JavaScript puro desenhando num Canvas, sem framework. A versão desktop usa Tauri, então o instalador fica pequeno e roda no Windows, macOS e Linux;
• o botão de relatar problema tira o print da tela antes de abrir o formulário, e o usuário rabisca em cima. Ele só existe na versão interna, porque manda pro nosso chat; a versão aberta não tem;
• junto vai o arquivo como o importador leu, guardado na aba no momento em que foi aberto. Se mandássemos uma reexportação, ela passaria pelo mesmo código com defeito e esconderia o problema;
• cada correção vira um teste. O arquivo do cliente não entra no repositório: o Walter monta um arquivo sintético que reproduz o mesmo caso e esse arquivo vira o teste;
• a interface foi escrita em português e traduzida na saída, com o texto original como chave. Um teste lê o código e quebra se algum texto novo ficar sem tradução em inglês ou espanhol.

Em números

Desde 21/09, quando começamos a medir o uso, foram 143 sessões reais, de 16 pessoas em três empresas. O projeto tem 400 testes automatizados, e a interface está em português, inglês e espanhol.

Agora abrimos o código sob AGPL-3.0, com instalador pra Windows, macOS e Linux:

https://github.com/triangulolaser/traco-cad

Criei esse repositório separado hoje para publicar o Traço como uma aplicação independente. A versão que usamos aqui roda dentro de outro sistema nosso, integrada ao fluxo de produção.

O que não é

O Traço não substitui o AutoCAD. É só 2D e não tem vários recursos avançados que o AutoCAD tem. É um CAD leve pra quem desenha peça mecânica, abre DWG e DXF e roda até no navegador.

O Walter também não trabalha sozinho. O que tem risco passa pela minha aprovação, e são os testes que deixam corrigir rápido sem quebrar o que já funcionava.

O efeito

O que aprendi nesse desenvolvimento é que o gargalo de software open source de nicho talvez nunca tenha sido falta de gente pra escrever código. Quando o usuário consegue relatar o problema em uma mensagem no chat e enviar evidências, um projeto pequeno consegue corrigir problemas do dia a dia muito mais rápido.

Mais alguém está fazendo algo parecido em outra área, com o usuário final falando direto com o agente? Quero muito conhecer outras experiências e trocar ideia com quem está tentando isso na prática.