Consult Engenharia · Saneamento
A melhor coisa que eu construí aqui foi uma lista de perguntas.
Um add-in do Revit que gera o modelo de uma estação elevatória de esgoto a partir da topografia, de um layout 2D e de um arquivo de parâmetros. Eu não sabia nada de engenharia sanitária quando isso começou. Esta página é sobre como essa distância se fecha.
- Papel
- Product lead e construção
- Stack
- .NET 10 · API do Revit 2027 · Autodesk APS Design Automation · C#
- Status
- MVP em validação com o cliente — sem URL pública
O conhecimento estava na cabeça de um engenheiro.
Uma elevatória é desenhada do mesmo jeito toda vez, e nunca exatamente igual. As profundidades vêm da topografia. O volume do reservatório de acumulação vem da vazão máxima em três horas. Um poço de visita sem o parâmetro de profundidade não pode simplesmente descer, ou a tampa sai da calçada. Nada disso estava escrito em lugar nenhum — estava na prática de um engenheiro que já tinha feito aquilo dezenas de vezes.
Eu não sabia nada disso. Essa é a condição inicial real da maior parte do trabalho de consultoria, e fingir o contrário é como se constrói software confiante e errado.
Cinquenta e uma perguntas numeradas, em lotes, cada resposta virando regra.
Não foi workshop nem call de discovery. Um documento de perguntas numeradas, enviado em lotes, respondido por escrito, cada resposta rastreada até a regra que gerou e o código que a aplica. Quando uma resposta mudava uma premissa anterior, a regra mudava junto, com referência ao número da pergunta.
Perguntas antes de código
O registro de decisão do montador termina com uma linha que eu precisava sustentar: nada dele é implementado enquanto os pendentes não forem respondidos. Eram seis itens pendentes. O trabalho parou ali e foi para outra frente até as respostas voltarem.
Decisões registradas, inclusive as que foram revertidas
A primeira abordagem implantava a estação encaixando um projeto de referência no terreno novo, alinhando os lotes geometricamente e calculando a cota da plataforma por equilíbrio de corte e aterro. Aí o cliente disse que ele fornece um layout 2D com as posições já definidas. O encaixe geométrico não foi apagado — virou conferência, comparando o layout com o projeto de referência e avisando quando a diferença passa de um limite.
As respostas são a especificação
Vazão máxima em três horas, diâmetro interno ou externo, se a entrada fica na cota, quais padrões identificam um poço no caminho do escoamento. Cada uma dessas voltou como um número ou um sim, e entrou no sistema como regra com o número da pergunta junto.
O que não puder andar corretamente fica parado e diz por quê.
Esse é um sistema que edita modelo de obra. O modo de falha que importa não é quebrar — é mover alguma coisa quase certo e deixar uma ligação de tubo solta onde ninguém olha. Então o critério de pronto é uma recusa: o que não puder andar corretamente fica onde está, com aviso dizendo o motivo, e nenhuma ligação fica desconectada.
Dez situações em que isso acontece estão catalogadas — um trecho curto cuja inclinação iria de 1% a 39%, uma peça presa a uma parede que precisaria andar, um poço sem o parâmetro de profundidade. Cada uma registra o que a aba faz, o texto exato do aviso e onde apareceu pela primeira vez. Um caso novo que não estraga nada não é corrigido na hora: entra nessa lista como aviso conhecido.
A versão mais difícil disso foi o tratamento de erro do próprio Revit. Na v1.1, um erro dentro de uma transação deixava o Revit aplicar a resolução padrão dele — que pode remover uma restrição e desconectar algo em silêncio. Na v1.2, qualquer erro do Revit desfaz a operação inteira e informa o motivo. Existe exatamente uma exceção documentada, e ela só vale porque as três condições se sustentam: os elementos envolvidos são anotações, que não mudam geometria, ligação nem parâmetro de modelo; a resolução é escolhida pela aba e não pelo padrão do Revit; e uma cota cuja referência deixou de existir não tem conserto de qualquer forma. Qualquer outro erro, mesmo junto com esse, desfaz tudo.
O mesmo código no Revit do engenheiro e headless na nuvem.
O engenheiro recebe uma aba com quatro comandos — implantar no terreno novo, gerar a elevatória, inventariar o modelo e auditá-lo. O caminho da nuvem roda o gerador idêntico, sem interface, pelo Autodesk Design Automation, e devolve um modelo mais um arquivo de resultado. Embaixo dos dois, o motor que lê a entrada, valida, converte unidades e estima profundidades não depende do Revit, então é testado offline a cada push. A troca de diâmetro fica com as preferências de roteamento do próprio Revit: o gerador escolhe o tipo, o Revit resolve as conexões.
Eu trabalho num Mac, que não roda Revit. O desenvolvimento aponta para a API por pacotes de referência que compilam sem ele; o teste roda o Revit 2027 numa VM Windows; e o caminho da nuvem nunca precisou de Revit local.
177 commits em sete dias, numa stack que não é a minha.
C#, a API do Revit e as convenções de BIM não são de onde eu venho. O código é gerado e revisado com IA sob a minha direção, e é por isso que uma semana produziu tudo isso. O que impede isso de virar bobagem confiante é o formato do trabalho, não o volume: um motor que roda sem Revit e é testado a cada push, decisões registradas antes de serem implementadas, e um cliente que responde por escrito.
A leitura honesta
Isso é um MVP em validação. Não tem URL pública, não tem rodada em produção e não tem número de horas economizadas, porque a primeira geração real no Revit do cliente ainda não aconteceu. Se você procura resultado entregue, os outros projetos deste site são os que valem a leitura.
O que este mostra é a parte antes do resultado: entrar num domínio que eu não conhecia, tirar as regras de quem as carrega e construir algo que se recusa a agir quando não tem certeza. É o trabalho que eu estaria fazendo no primeiro mês em qualquer lugar.
Tem conhecimento que mora na cabeça de uma pessoa?
Essa é a situação de que eu mais gosto — as regras existem, o especialista está ali, e ninguém escreveu ainda.