← Insights
IA Aplicada 26 de maio de 2026 6 min de leitura

Vibe coding não é mágica: é acelerador de prototipação

Com exceção das multinacionais, pouquíssimas empresas contam com modelos de should-cost de frete componente a componente — combustível, motorista, pedágios, ICMS, depreciação, margem. Esse tipo de modelo exige um analista especializado em modelagem e logística, perfil raro fora das grandes operações. Empresa de médio e até de grande porte sem esse perfil interno ficava com benchmark estático ou sem análise, e a janela de renegociação passava sem dado para sustentar a conversa.

O que mudou é o custo de construir essa capacidade internamente. Até recentemente, ferramentas analíticas avançadas exigiam time de TI dedicado, orçamento de seis dígitos e ciclo de 18 meses entre briefing e algo rodando. Esse custo de entrada caiu de forma acentuada nos últimos dois anos, destravado pela evolução da IA agêntica. E a mudança é maior do que parece.

O ganho não está na automação transacional

A conversa pública sobre IA em operações está concentrada em automação de fluxo transacional: aprovação automática de pedido, reconciliação de NF, captura de fatura. É útil, mas o ROI é marginal. O ganho relevante para empresa de médio e grande porte está em outro lugar — construir internamente a capacidade analítica que antes só multinacional comprava pronta.

Esse jeito de construir tem nome: vibe coding. Em vez de escrever código, você descreve em português o que precisa, a IA gera o código, você roda, vê o que saiu e ajusta. A iteração é rápida porque o ciclo “ideia para protótipo funcional” passou a caber em horas. Em projeto de consultoria, isso significa que o consultor que conhece o problema do cliente consegue entregar a ferramenta junto com o diagnóstico — em vez de empacotar um briefing para o time de TI traduzir três meses depois.

O caso: should-cost de fretes em horas

Um diretor de logística queria validar se a base de fretes contratada estava em linha com mercado. A entrega tradicional seria uma tabela estática com benchmark da ANTT e três rotas analisadas a fundo. Optei por outra coisa: construir um simulador que recebe a tabela inteira de fretes, recebe a tabela de drivers do mês (combustível, salário do motorista, ICMS, pedágios) e calcula should-cost por componente para cada rota.

O prompt especifica o modelo de custo componente a componente e as regras de output. Em alguns minutos, a ferramenta saiu como um arquivo HTML único, que abre no browser sem servidor e sem instalação. Os parâmetros são ajustáveis na própria interface — preço do diesel, consumo da frota, margem do transportador, payload. E como a maioria desses drivers tem fonte pública (ANP, ARLA, convenção coletiva dos caminhoneiros), a atualização mensal pode ser automatizada: a ferramenta busca os valores, recalcula tudo e o gestor abre o número já calibrado.

Com a base real carregada — rotas e transportadoras anonimizadas — o output apareceu imediatamente. 1.082 rotas analisadas. 904 delas pagando acima do should-cost. Gap médio de R$325 por tonelada contra um should-cost de R$281. Oportunidade de R$1,5 milhão por ciclo, identificada antes de qualquer reunião de renegociação. A ferramenta ainda segmenta as rotas em três quadrantes com hipóteses de alavanca distintas e entrega o ranking das 20 maiores oportunidades por economia por viagem.

Implicação para gestores

Em projeto tradicional, o Excel do diagnóstico vai para a gaveta no dia em que o consultor sai. Com vibe coding no fluxo, o mesmo diagnóstico vira uma ferramenta operacional que o gestor abre toda semana. No mês seguinte, se o diesel subiu ou o ICMS de um estado mudou, a ferramenta já buscou os parâmetros atualizados e recalculou. O número fica vivo dentro da operação, em vez de viver dentro de um deck que ninguém abre.

Uma ressalva necessária: para integração transacional crítica com ERP ou produção em escala, o caminho continua sendo engenharia de software tradicional. Vibe coding resolve o piloto funcional que a maioria dos projetos nunca chega a ter, e permite gerar especificação funcional testada para o desenvolvimento que vier depois.

Isso muda a natureza do produto de consultoria em operações. A recomendação no relatório continua existindo, mas o entregável de maior valor passa a ser o conjunto de ferramentas que segue rodando na operação do cliente depois que o projeto fecha. Vale a pergunta: dos seus últimos projetos de operações, quantos deixaram algo rodando no dia seguinte?

Este artigo foi publicado originalmente no LinkedIn — ver post original ↗