Décadas de software comercial tornaram rápida a parte estritamente numérica da análise estrutural. Montar uma matriz de rigidez e resolver um sistema linear é um problema bem compreendido e computacionalmente barato. O tempo do engenheiro vai para outro lugar: construir o modelo, refazê-lo cada vez que a arquitetura muda, definir cargas e combinações, verificar elemento por elemento contra a norma e produzir o memorial de cálculo e os desenhos.
O cálculo é a parte rápida. O gargalo é o andaime manual em volta dele. E é exatamente aí, no andaime, que um agente de IA pode contribuir — desde que não toque no cálculo.
O limite preciso de um modelo de linguagem
Um modelo de linguagem gera texto probabilístico. Ele desconhece as leis da física e o comportamento dos sistemas reais, e pode alucinar: devolver respostas que soam plausíveis e são incoerentes. Em análise estrutural o risco é concreto, porque a modelagem exige raciocínio espacial e consistência topológica, e a modelagem em vários passos é propensa ao acúmulo de erros.
A restrição, porém, não nasce da engenharia de software, e sim de como funciona a prática profissional. Todo resultado estrutural leva uma assinatura, com a autoria e a responsabilidade legal que isso implica. O número que dimensiona um pilar não é mais um dado: é um compromisso do engenheiro habilitado que o subscreve. Um agente que entrega resultados não verificados não agrega valor de engenharia; transfere ao profissional o risco de assinar um cálculo que ninguém conferiu.
A correção do resultado tem que ser uma propriedade do solver, não da linguagem.
A fronteira de determinismo
Em vez de melhorar o modelo até que ele "calcule bem", tira-se dele o cálculo. O agente propõe projetos e cenários, mas para que um resultado seja válido ele precisa passar por um programa que o agente não pode modificar e que contém a física do problema. O modelo decide qual ferramenta determinística invocar e com quais parâmetros, e integra o que essa ferramenta devolve. Nunca origina um número nem inventa geometria.
A arquitetura separa três responsabilidades. A camada de intenção é o agente: interpreta linguagem natural, formula perguntas de esclarecimento e emite ações tipadas. A camada de cálculo determinístico reúne tudo o que produz dados de engenharia — o solver que resolve, os módulos CIRSOC que verificam, os geradores que expandem uma tipologia em um modelo completo. A camada de documentação produz memoriais, desenhos e quantitativos a partir de resultados já calculados.
Essa separação não é um achado nosso. É o padrão dominante na literatura recente de agentes de engenharia, e em domínios vizinhos: os agentes de programação funcionam porque um compilador e uma bateria de testes dizem se o código compila e passa; o AlphaProof demonstra teoremas porque um verificador formal não deixa um erro passar. O que fazemos é adotá-lo deliberadamente, como princípio de projeto estabelecido.
O que a fronteira garante e o que não garante
Vale ser preciso, porque uma fronteira que promete demais é pior do que nenhuma. A fronteira de determinismo garante três coisas:
- Toda afirmação numérica do agente é rastreável a um resultado específico do solver: combinação, estação, elemento.
- Toda saída da IA é validada contra o esquema do modelo antes de ser importada, e recusada se vier malformada ou com campos desconhecidos.
- Se o serviço de IA não estiver disponível, o solver, o editor e as verificações continuam funcionando.
E não garante que o modelo idealizado seja o correto para o problema real, o que é uma decisão de engenharia; nem que o projeto seja ótimo; nem que as cargas e as hipóteses estejam completas; nem que a interpretação normativa dispense revisão.
Um caso em que o solver no laço não é opcional
O engenheiro descreve um pórtico de concreto armado de 6 m de vão e 4 m de altura, com bases engastadas e uma carga distribuída sobre a viga. O agente pergunta o que falta — aço ou concreto? bases engastadas ou rotuladas? há carga lateral? — e emite a ação que cria o pórtico. O backend a expande de forma determinística em um modelo de 4 nós, 3 elementos e 6 graus de liberdade livres. Concreto H-21, viga inicial de 25×40 cm, pilares de 30×30 cm e 30 kN/m sobre a viga.
Resolvido o modelo, as reações verticais são de 90 kN por pilar e o equilíbrio global se cumpre de forma exata: ΣRz = 180 kN = q·L. O momento governante da viga é Mu = 80,8 kN·m no meio do vão. A verificação CIRSOC 201 à flexão da viga 25×40 armada com 3Ø16 dá uma capacidade φMn = 73,3 kN·m. A viga não verifica.
| Estado | Seção | Armadura | Mu [kN·m] | φMn [kN·m] | D/C | Verifica |
|---|---|---|---|---|---|---|
| Inicial | 25×40 cm | 3Ø16 | 80,8 | 73,3 | 1,10 | Não |
| Corrigido | 30×55 cm | 3Ø16 | 105,6 | 108,6 | 0,97 | Sim |
Olhe a terceira coluna de números. Ao aumentar a viga de 25×40 para 30×55, a demanda não cai: sobe de 80,8 para 105,6 kN·m. Num pórtico hiperestático a soma do momento de extremidade e do momento no meio do vão é fixada pela estática; o que muda com a rigidez é a repartição. Uma viga mais rígida em relação aos seus pilares recebe menos engastamento deles e se aproxima do caso biapoiado, de modo que o seu momento no meio do vão — o que governa aqui — cresce. Por isso a verificação correta exige resolver o modelo de novo e não apenas recalcular a capacidade da nova seção.
Um agente que estimasse o efeito sem recalcular erraria, e soaria igualmente convincente ao fazê-lo.
Esse é o argumento inteiro, em um número. Não é que o solver seja mais rápido: é que a intuição de que "aumentar a seção melhora a verificação" é falsa assim que a estrutura é hiperestática, e só o solver sabe disso.
Tirar um pilar de um projeto já calculado
O segundo caso parte de um pórtico de quatro vãos de 5 m e três pavimentos de 3 m, com bases engastadas, vigas de 25×50 cm (4Φ16), pilares de 35×35 cm e 25 kN/m sobre todas as vigas: 20 nós, 27 elementos, 45 graus de liberdade livres. Resolvido e verificado, todas as vigas passam com folga.
Por uma decisão arquitetônica, retira-se um pilar interno do térreo. A ação de edição o remove com validação de integridade estrutural e o modelo é resolvido de novo; o equilíbrio global se mantém antes e depois (ΣRz = 1500 kN). As vigas que se apoiavam nesse pilar passam a vencer 10 m e, junto com as que ficam alinhadas acima, redistribuem o apoio perdido. Seis vigas ultrapassam D/C = 1.
| Estado | Seção | Mu [kN·m] | φMn [kN·m] | D/C | Verifica |
|---|---|---|---|---|---|
| Intacto | 25×50 (4Φ16) | 54,2 | 125,3 | 0,43 | Sim |
| Sem o pilar | 25×50 (4Φ16) | 203,9 | 125,3 | 1,63 | Não |
| Redimensionado | 30×65 (5Φ20) | 189,8 | 313,7 | 0,61 | Sim |
O momento da viga governante quase quadruplica. Adotando 30×65 cm com 5Φ20 nas vigas afetadas e resolvendo de novo, todas voltam a verificar. O relevante não é o redimensionamento: é que uma mudança que manualmente exige remodelar, reanalisar, reverificar e redetalhar muitos elementos se resolve como uma conversa curta, com cada número rastreável ao solver e sujeito à aprovação do engenheiro.
Quatro decisões que sustentam a fronteira
- Ações tipadas em vez de geração de código livre. Os precedentes fazem o modelo escrever scripts em Python que depois são executados contra um solver externo. Aqui a saída do agente está restrita a um conjunto fechado de chamadas com contratos de entrada e saída explícitos, validadas contra um esquema antes de executar. É uma fronteira mais estreita e mais auditável do que código arbitrário.
- Um solver próprio, não um invólucro de terceiros. O motor é escrito do zero em Rust, sem dependências externas de álgebra linear, com sua própria bateria de verificação contra soluções analíticas e benchmarks de referência: da ordem de 6.800 testes passando, e resultados confrontados com um programa comercial sobre os mesmos modelos com diferenças abaixo de 0,1 %.
- Conformidade normativa nativa. A verificação segundo CIRSOC 201 e 301, que nenhum software de código aberto implementa de forma nativa. O módulo de concreto está implementado e testado; o de aço ainda vive apenas na camada de frontend e não tem bateria de testes dedicada, e dizemos isso para não lhe atribuir uma maturidade que ele não tem.
- Execução no navegador. O motor compila para WebAssembly e roda localmente na máquina do usuário, sem servidor de cálculo e sem instalação.
De um solver testado a um solver provado
A fronteira garante que toda afirmação do agente é rastreável a uma saída do solver. Essa garantia tem um limite preciso: o solver é confiável porque está extensivamente testado, não porque está provado. Uma suíte de testes, por mais exaustiva que seja, cobre apenas os casos que seus autores imaginaram.
O ponto pesa mais neste contexto de uso. Um agente constrói modelos, modifica-os em vários passos e lê os resultados para propor novas ações; nesse ciclo o solver recebe entradas que nenhum engenheiro revisou antes de chegarem ao motor. Se o motor se comportar mal em algum caso de borda — uma matriz de rigidez quase singular, uma geometria degenerada, uma combinação extrema —, o agente pode citar esse resultado sem aviso.
Há duas ferramentas para encurtar essa lacuna. O fuzzing baseado em propriedades gera milhares de modelos aleatórios válidos e afirma invariantes que precisam valer para qualquer entrada:
- Equilíbrio global: ΣR = P, independentemente da geometria, dos materiais ou dos apoios.
- Simetria da matriz de rigidez: K = Kᵀ por construção.
- Definição positiva de K para qualquer estrutura sem mecanismos.
- Invariância a transformações rígidas: transladar ou girar um modelo não muda os esforços internos.
A verificação formal ataca a mesma lacuna pelo outro lado: escrever uma especificação matemática dessas propriedades e demonstrar, com um assistente de provas como o Lean 4, que a implementação a satisfaz. O teste pode encontrar erros; a verificação formal pode demonstrar a ausência deles dentro do domínio especificado. As duas são complementares: quando o fuzzer encontra uma entrada que viola uma propriedade, essa propriedade vira candidata a uma prova.
Onde isso está hoje
Vale fechar com o que existe e o que não existe. O solver, o editor, as verificações CIRSOC, o modo educativo e a geração de memoriais e desenhos funcionam hoje no navegador, em stabileo.com, sem instalar nada e sem conta. A camada de agentes está em desenvolvimento ativo: suas rotas rodam em desenvolvimento e teste contra um backend próprio, sobre o mesmo solver e os mesmos números que todo o resto, mas esse backend ainda não faz parte do site público.
O ciclo solver-no-laço — o agente propõe, resolve, avalia e modifica sem intervenção humana — está no roadmap e não está implementado. A cobertura normativa nativa se limita a CIRSOC 201 e 301; o resto é trabalho futuro.
O CAD levou a parte mecânica do desenho e a planilha levou a aritmética repetitiva, sem levar o critério. O agente é o elo seguinte: absorve o andaime mecânico e deixa o julgamento do lado do engenheiro. Nenhuma dessas medidas transfere a responsabilidade. O número assinado continua sendo do engenheiro.