Construir o stock de chapas com IA: onde o sucesso rápido se inverte

Com IA, hoje é possível construir numa tarde uma lista de stock ou uma pequena galeria de chapas. Funciona enquanto uma só pessoa a usa e nada de invulgar acontece. No dia a dia de uma empresa de pedra, acontece constantemente algo invulgar, por exemplo quando dois vendedores propõem a mesma chapa. É aí que começam os erros no programa, e cada reparação rápida pode gerar outros erros.

A tentação: em horas em vez de meses

«Vibe Coding» foi o nome que o investigador de IA Andrej Karpathy deu, em fevereiro de 2025, àquilo que hoje muitos experimentam: descreve-se em linguagem corrente o que o programa deve fazer, e a IA escreve o código, que se adota sem o ler. Ao fim de uma tarde, há muitas vezes uma tabela com material, formato e espessura, com fotografia e filtros.

Para algumas tarefas, é exatamente o indicado: uma visão rápida para a presença numa feira ou a análise dos contactos recolhidos numa feira. Assim que esses dados tiverem de entrar num projeto em curso, a coisa complica-se. O Fraunhofer IESE aponta a prototipagem rápida como um ponto forte e alerta, ao mesmo tempo, para o risco de o protótipo acabar no sistema final. «Os riscos aumentam com a complexidade e a criticidade da aplicação.» Um stock de chapas através do qual se vende é ambas as coisas.

A curva: entusiasmo, dia a dia, erros

Depois chega o dia a dia, e com ele casos em que ninguém pensou ao descrever o programa:

• Uma chapa não é um artigo. Cada chapa bruta é uma peça única, com contorno e veios próprios. Uma lista que regista «material, 20 m²» não sabe que chapa combina com qual.
• Sequências do bloco. Um bookmatch precisa das chapas consecutivas e espelhadas de um bloco; um blending tranquilo, de chapas do mesmo bloco. Se uma delas sai sozinha, falta na superfície exatamente a sua vizinha.
• As sobras regressam. Depois do corte, fica uma sobra com um contorno novo. Novo registo, alteração ou baixa? A resposta comanda stock, preço e fotografia.
• Chapas partem-se, posições mudam. Uma chapa parte-se ao ser mudada de sítio, outra está noutro cavalete. No sistema, ambas continuam inalteradas, e uma proposta continua em curso.
• Dois vendedores, uma chapa. Assim que mais de uma pessoa vende, são precisas reservas que todos veem.
• Tudo está ligado. Um processo que funciona para ladrilhos de pavimento em metros quadrados não funciona automaticamente para rodapés em metros lineares. O que está certo na proposta tem de estar certo também na encomenda, na guia de remessa e na etiqueta.

Um caso real mostra quão pequeno pode ser o gatilho. Um programa de planeamento escrito internamente funcionou sem falhas em vários projetos individuais. Quando os dados de vários projetos foram reunidos, parou. Numerava as peças com letras e percorria o alfabeto; ninguém tinha definido o que vem depois do Z. O erro foi corrigido depressa, mas teve consequências na execução e na representação dos planos, que tiveram todas de ser atualizadas. É o percurso típico: o resultado chega depressa. Os casos em que o programa encalha só aparecem quando a empresa e os seus colaboradores o usam a sério.

Cada um destes casos pode ser descrito à IA, e ela entrega uma solução. É aqui que está a armadilha: a reparação resolve, numa ou em várias tentativas, o problema visível e, ao fazê-lo, altera muitas vezes em segundo plano coisas que antes funcionavam. No Vibe Coding, segundo descreve o Fraunhofer IESE, «as mensagens de erro são simplesmente passadas diretamente à IA como novo prompt». Como risco, o instituto aponta a perda de compreensão do sistema: o código gerado é difícil de acompanhar.

Uma das razões está na forma de trabalhar da IA. Uma pessoa que constrói um programa ao longo de meses lembra-se de porque é que algo foi resolvido de determinada maneira. A IA trabalha com o que está na conversa atual. Ao longo de muitas sessões, muda-se de chat e nem tudo é transmitido, ou a conversa fica tão longa que as partes anteriores já não são tidas em conta de forma fiável. A equipa de investigação da Chroma testou 18 modelos de linguagem: em todos os ensaios, o desempenho caiu à medida que a entrada ficava mais longa. É precisamente aí que nascem as reparações que estragam algo noutro sítio.

A cada reparação, o código cresce e, como falta compreensão da lógica, torna-se mais complicado do que o necessário: secções duplicadas, desvios, ciclos dentro de ciclos. Um indício vem do desenvolvimento profissional: a empresa de análise de código GitClear avaliou 211 milhões de linhas de código alteradas entre 2020 e 2024. A percentagem de linhas copiadas subiu de 8,3 para 12,3 %, e a de linhas reorganizadas desceu de 25 % (2021) para menos de 10 % (2024). Esta arrumação leva tempo, exige conhecimento especializado e, regra geral, ultrapassa o que está disposto a fazer quem «constrói isto rapidamente por conta própria».

Resta a segurança. A Veracode analisou código de mais de 100 modelos de IA: em 45 % dos testes, continha falhas de segurança perigosas. Como isso se traduz na prática mostrou-o em 2025 a plataforma de criação com IA Lovable: em 170 de 1.645 aplicações analisadas construídas com ela, as permissões de acesso tinham tantas lacunas que dados como nomes, números de telefone e dados de pagamento ficavam expostos. Para um stock de chapas que mostra preços e dados de clientes na internet, isto pesa muito.

A armadilha: quanto mais se investe, mais difícil é sair

Um sistema construído internamente costuma tornar-se caro só depois do arranque, nas semanas em que à noite ainda se corrige um erro e de manhã já há outro. Essas horas fazem falta nas vendas e nas medições em obra. Quanto mais tempo foi investido, mais difícil se torna dizer: «Paramos e passamos a uma solução pronta.» Em psicologia, chama-se a isto efeito do custo irrecuperável (sunk cost): o tempo já investido prende, mesmo quando o passo seguinte já não compensa.

E quase não se nota quanto tempo vai sendo investido. Num estudo do grupo de investigação METR, 16 programadores experientes trabalharam em tarefas reais nos seus próprios projetos open source, grandes e desenvolvidos ao longo de anos, umas vezes com, outras sem ferramentas de IA do início de 2025. Medido, demoraram 19 % mais com IA e, mesmo assim, acreditavam depois ter sido 20 % mais rápidos. Para ferramentas mais recentes, os autores consideram que o atraso entretanto diminuiu, mas classificam eles próprios os dados que têm para isso como fracos. Notável continua a ser o fosso entre a sensação e a medição. Se até profissionais avaliam tão mal o seu próprio ritmo, que fiabilidade tem a autoavaliação de alguém que está a programar pela primeira vez, em paralelo com o resto do trabalho?

Sinais de que já se está preso:

1. Todas as semanas surge mais uma reparação, e a lista de erros em aberto não encurta.
2. As perguntas sobre o programa vão sempre parar ao mesmo colega e, quando ele está de férias, a empresa espera.
3. Depois de uma alteração, ninguém verifica o sistema em todas as direções, ou seja, proposta, guia de remessa e etiqueta. Se algo se estragou, só o dia a dia o mostra.
4. Até agora, ninguém somou as horas que foram e continuam a ser investidas no programa próprio.

Se mais de um ponto se aplicar, vale a pena fazer contas honestas com três números: as horas que a construção própria custa todos os meses (basta registar durante duas semanas), o preço mensal de uma solução profissional e o tempo que a equipa poupa com ela nas vendas e no armazém, de preferência medido num teste com o próprio stock.

O que vem aí: o passaporte digital do produto

O novo Regulamento dos Produtos de Construção (UE) 2024/3110 aplica-se desde 8 de janeiro de 2026 e traz o passaporte digital do produto para os produtos de construção. Segundo o Deutsches Institut für Bautechnik (DIBt), passa a ser obrigatório assim que a Comissão Europeia adotar o respetivo ato jurídico, após um período de transição de 18 meses. É esse ato que define que produtos e que dados abrange. Previsivelmente, os dados dos produtos terão de estar disponíveis em formato digital e numa forma definida. Uma solução construída internamente enfrenta então uma reformulação que cada empresa suporta sozinha. Um fornecedor que serve muitas empresas tem de a resolver uma vez, para todas.

O que fala a favor de construir por conta própria

Por justiça, também o outro lado conta. Uma solução pronta custa dinheiro todos os meses, enquanto estiver em uso. Fica-se dependente de um fornecedor e do seu planeamento, e os desejos próprios ficam lado a lado com os de outros clientes. E, antes de começar, convém esclarecer como é que os próprios dados voltam a sair, caso se mude. Quem dá mais peso a estes pontos e tem tempo para a manutenção pode, com boas razões, construir por conta própria, sobretudo onde não estejam em jogo dados de clientes.

O que existe numa solução que foi crescendo

Também uma solução comprada não está isenta de erros. A diferença está em quem encontra e corrige os erros. Numa plataforma, trabalham todos os dias colaboradores de muitas empresas. Assim, os processos são testados na operação real, as mensagens de erro chegam ao fornecedor e são corrigidas, e para todos os clientes ao mesmo tempo. É disso que o fornecedor vive, por isso tem todas as razões para ser rápido. Muitas doenças de infância que um programa próprio ainda tem pela frente já lá estão curadas.

Numa plataforma converge o conhecimento de muitas empresas. Quem constrói para muitas empresas de pedra analisa os processos ao pormenor e pergunta como podem, em termos gerais, ser acelerados. Para uma empresa isolada, faz pouco sentido repetir esse trabalho sozinha. Importante é que a solução se possa configurar com flexibilidade, para que também uma pequena empresa reconheça nela os seus processos. No DDL, em uso em empresas de pedra desde 2020, cada chapa é gerida como peça única, com fotografia, medidas e bloco, as sobras regressam ao armazém como novas chapas, e quem propõe uma chapa reservada recebe um aviso.