O abismo entre a demo e a produção

Em fevereiro deste ano, um engenheiro da Cloudflare fez uma manchete que rodou o mundo. Em uma semana, com a ajuda do Claude e cerca de US$ 1.100 em tokens, ele reimplementou 94% da API do Next.js do zero. Chamou de vinext. Builds 4x mais rápidos. Bundles 57% menores. Um engenheiro só. Um modelo de IA. Sete dias.

Quem leu o título saiu impressionado. Quem leu o final do post oficial encontrou outra história. A própria Cloudflare avisa, com todas as letras, que o projeto “é experimental, ainda não tem uma semana de vida e não foi testado com volume real de tráfego em escala”. E recomenda que, se você estiver avaliando para produção, “prossiga com cautela apropriada”. Faltam features. Falta pre-rendering estático. Falta o tempo de pista que separa um experimento de um produto.

A história do vinext é genuinamente impressionante. Mas ela também é o caso mais limpo que vi do padrão que está dominando a conversa sobre IA: a parte que a IA acelera é a parte fácil. A parte difícil ainda é difícil. E executivos, vendo só a manchete, estão tomando decisões que ignoram esse abismo.

A ilusão do simples

Toda demo de IA mora numa camada visível. Em um agente conversacional, é a conversa fluida no WhatsApp. Em um copiloto de código, é o autocomplete inteligente na tela. Em um framework reescrito do zero, é o “olha, a homepage roda”. Essa camada é polida, encantadora e, em 2026, genuinamente excelente. Faz o C-level se inclinar na cadeira.

O problema é que essa camada visível costuma ser entre 5% e 10% do projeto real. O outro 90% mora abaixo da linha d’água, em coisas que não cabem em uma demo: integração com sistemas legados, escala, observabilidade, custo previsível, segurança, compliance, rollback, política de qualidade, time on-call, contrato de SLA. Coisas chatas. Coisas caras. Coisas que a IA, hoje, não acelera quase nada.

Quando o executivo só viu a parte de cima, ele faz a pergunta errada. “Se já existe, por que demora?” “Se um fornecedor entrega para o vizinho, por que para a gente seria diferente?” “Se um engenheiro fez o Next.js em uma semana, por que meu time precisa de seis meses para um agente de WhatsApp?” Essas perguntas têm resposta. Mas a resposta não cabe na demo, e por isso ninguém quer ouvir.

A resposta honesta, e um pouco irônica, é: porque você está medindo o iceberg pela ponta.

O exemplo que permeia: agente de WhatsApp em PME e em rede grande

Tenho conversado com bastante executivo de tecnologia ao longo do último ano. No Brasil, com líderes de empresas de portes muito diferentes, de educação a varejo, de saúde a indústria. Fora dele, em uma rodada recente no Vale do Silício, com quem opera plataformas em escala global. Em quase toda essa amostra, o exemplo do agente conversacional aparece em algum momento da conversa, e é onde o abismo entre demo e produção fica mais visível. Vou usar esse caso para ilustrar.

Imagine duas empresas. A primeira é uma escola pequena que quer um agente para qualificar leads no WhatsApp e marcar visita. A segunda é uma rede de centenas de unidades que quer o mesmo agente, agora atendendo de norte a sul do país, integrado ao sistema de matrícula central, ao CRM corporativo e ao ERP.

Para quem está olhando a tela, o produto é o mesmo. O lead manda mensagem, o bot responde, qualifica e agenda. Demos idênticas. A camada visível é praticamente igual.

A camada de baixo escala de forma não linear.

Dimensão	PME	Rede grande
Volume mensal	50 a 500 leads	50.000 a 500.000 leads
Provedor de WhatsApp	API não oficial	Cloud API oficial da Meta ou BSP enterprise
Custo por conversa	Mensalidade fixa	US$ 0,06 a 0,12 por conversa, linear com volume
Custo de IA	US$ 5 a 50 por mês	US$ 1.500 a 10.000 por mês
Tempo até MVP	4 a 6 semanas, 1 dev	8 a 12 meses, time de 4 a 8 pessoas
SLA	”Faz funcionar”	99,9% de uptime contratual com penalidade
Compliance	LGPD básica	DPO, DPIA, auditoria, direito ao esquecimento

Nenhuma linha dessa tabela aparece em uma demo de 20 minutos.

A complexidade real está em três pontos que o executivo raramente vê.

Primeiro, o WhatsApp. Provedor não oficial funciona até cerca de mil conversas por mês. Em volume comercial, a Meta detecta o padrão automatizado e bane o número permanentemente, levando a operação inteira junto. A solução enterprise é o WhatsApp Business Platform oficial, com cada template aprovado pela Meta (de horas a uma semana por aprovação), com custo linear por conversa iniciada, com conta sob política de qualidade vigiada. Migrar de um para o outro não é trocar variável de ambiente. É refazer fluxo, com janela de instabilidade.

Segundo, integração com sistemas internos. Em PME, integração é uma chamada REST no CRM, dois dias. Em corporação, integração é o projeto. ERP em SAP com adaptadores SOAP customizados. CRM em Java legado sem documentação atualizada. Sistema de matrícula feito em 2008, mantido por uma única pessoa que vai sair em três meses. Operações dependentes de planilhas Excel locais. Cada uma dessas pontes leva de 2 a 8 semanas, com bloqueios constantes esperando o time interno do cliente. Em projetos típicos, 70% do esforço técnico é integração, não IA.

Terceiro, o custo de IA escala não linear se mal projetado. Sem prompt caching e sem model routing, uma operação de 100 mil leads por mês passa de US$ 5 mil em conta de IA. Com as otimizações certas (parte fixa do prompt cacheada, modelo barato para triagem, modelo grande só para casos complexos, resumo de histórico longo), cai para US$ 1.500. Em PME, esse ganho não compensa o esforço. Em enterprise, não fazer isso é decisão financeira ruim, e aparece num fechamento trimestral, geralmente com o CFO no telefone.

A intuição mais cara que tenho ouvido em comitês de tecnologia, em mesas diferentes, é a mesma: se um fornecedor entrega isso para uma empresa pequena, fazer para uma rede grande deve ser parecido. Não é. Tipicamente é um projeto 5 a 10x maior em prazo e 10 a 20x maior em custo, com perfil de risco completamente diferente. E essa diferença não está na conversa que o lead vê. Está em tudo que sustenta a conversa.

Por que a confusão é estrutural, não ingenuidade

Quero deixar claro: a demo é genuinamente impressionante. Não é teatro, não é cortina de fumaça. É o estado da arte da camada visível, e quem construiu fez bem. O problema não é a demo. O problema é o que a gente projeta a partir dela.

A IA evoluiu mais rápido do que as ferramentas que a cercam. Hoje a gente tem modelos espetaculares mas ainda está engatinhando em alguns pontos críticos.

Testes para sistemas não determinísticos. Um prompt que funcionava ontem pode degradar amanhã sem ninguém notar. Os frameworks de eval ainda são jovens e quase nenhum time de produto tem maturidade para usar bem.

Observabilidade de prompts em produção. Quantas conversas saíram do trilho na semana passada? Quantas foram alucinação? Quantas terminaram com cliente irritado? Resposta honesta de 9 em 10 operações: ninguém sabe direito.

Segurança de dados em RAG. Documento sensível indexado em vetor pode vazar via prompt injection bem feito. Os controles para isso ainda são manuais e dependem fortemente de quem implementa.

Custo previsível em escala. A maioria dos projetos descobre o custo real depois do primeiro fechamento mensal, porque modelar o consumo de tokens em cenários reais é difícil e os fornecedores mudam preço sem aviso.

Rollback de comportamento. Mudou o prompt, a qualidade caiu? Você tem como voltar exatamente para o estado anterior, com o mesmo resultado, em produção? Quase ninguém tem.

Estamos no meio da jornada. As ferramentas estão chegando: frameworks de eval mais robustos, tracing semântico, governança de prompts, sandboxing, padrões estáveis de prompt cache. Mas ainda não estão maduras como, digamos, um pipeline de CI/CD bem montado para serviços tradicionais. Quem usa só o estado da arte do modelo sem o resto da pilha está construindo em terreno mole, e a manchete só conta a parte do terreno que parece firme.

De volta ao vinext: o que a manchete não conta

O caso da Cloudflare é uma versão concentrada da mesma armadilha.

Reimplementar 94% da API de um framework dominante em uma semana, com US$ 1.100 em tokens, é um marco real. Mostra que o ciclo de “explorar arquitetura, gerar código, rodar testes, iterar” virou uma ordem de grandeza mais rápido do que era em 2023. Isso é verdadeiro e relevante.

Mas vinext, hoje, não roda tudo que Next.js roda. Não tem pre-rendering estático. Não foi testado em escala de tráfego real. A própria Cloudflare diz, na mesma página, que se você está pensando em produção, precisa “proceder com cautela apropriada”. E isso é o que a Cloudflare fez certo: assumir o experimental publicamente.

O caminho de “consegue rodar a homepage” para “roda a produção do mundo todo” é o trabalho de verdade. Esse caminho não levou uma semana. Provavelmente vai levar muitos meses, talvez anos, e vai exigir tudo aquilo que a IA não acelera: cobrir os 6% que faltam (que sempre são os mais cabeludos), achar e corrigir centenas de regressões em casos extremos, manter compatibilidade com plugins de terceiros, suportar produção em milhares de clientes diferentes, construir comunidade, documentar, dar suporte.

Mesma armadilha do agente conversacional: a parte que a IA acelera é a parte fácil. A parte difícil ainda é difícil.

Dirigir um F1 numa pista que você não conhece

A imagem que tenho usado para explicar essa sensação é a de dirigir um carro de Fórmula 1 numa pista nova, ainda esburacada.

Como executivo de tecnologia em 2026, o carro é absurdo. Aceleração que era impossível há dois anos. Um time pequeno hoje entrega o que um time grande entregava antes. Demos saem em horas. Protótipos saem em dias. Sistemas inteiros saem em semanas. A sensação no acelerador é de superpotência, e não é exagero, é descrição.

A pista, porém, é menos conhecida. Os playbooks emergentes que mencionei acima estão evoluindo rápido, mas ainda não têm a maturidade que a engenharia de software tradicional acumulou ao longo de décadas. Na prática, cada projeto acaba sendo um exercício de adaptação: ajustar o teste a um sistema que não é determinístico, costurar a observabilidade entre prompts e logs, calibrar o limite de gasto antes que o consumo de token estoure o orçamento, decidir como fazer rollback quando o que mudou foi um prompt, escrever o protocolo de incidente para o momento em que o modelo alucina. Dá para fazer bem, e a cada trimestre fica um pouco mais fácil. Mas ainda exige consciência ativa em cada decisão, porque os atalhos prontos da engenharia tradicional ainda não foram replicados por aqui.

E ainda tem buracos. Regulação ainda mexendo (LGPD, AI Act, regras setoriais). Fornecedores mudando preço de uma semana para outra. Modelos sendo deprecados antes de você terminar a integração. Padrões de prompt cache mudando. Janela de contexto que era impossível ontem virando default hoje, e mexendo com a sua arquitetura.

Dirigir devagar é desperdiçar o carro. Você deixa o concorrente passar e perde a janela competitiva real que a IA abriu.

Dirigir rápido sem ler a pista é capotar. Vazamento de dados, banimento da operação no WhatsApp, conta de IA estourando, multa de LGPD, processo judicial, manchete na imprensa.

O trabalho do executivo de tecnologia, hoje, é ler a pista enquanto acelera. Não é escolher entre velocidade e segurança. É segurar as duas ao mesmo tempo, com cabeça fria, sabendo que as ferramentas que tornariam isso confortável ainda estão sendo construídas.

O que faz o executivo competente nesse momento

Algumas coisas que tenho aplicado e visto funcionar.

Questionar a primeira intuição. “Parece simples” virou red flag, não conforto. Toda vez que um projeto parece simples, eu pergunto: o que tem abaixo da linha d’água? Se ninguém sabe responder, é porque não olharam.

Separar visível de invisível em todo orçamento. Demo bonita não diz nada sobre infra, integração, governança. Eu peço explicitamente, para o time e para fornecedores: quanto vai custar a observabilidade? Quanto vai custar o on-call? Quanto vai custar a integração com cada sistema interno? Quanto vai custar manter no ar quando o modelo for deprecado? Quanto vai custar a auditoria? Esses números aparecem ou não aparecem. Se não aparecem, o orçamento não está pronto.

Pedir os números do volume real, dos sistemas que se conectam, do SLA contratado, do custo em escala. Quem responde com “depende” sem nunca ter feito está se vendendo. Quem responde com range concreto, mostrando experiência prévia em projeto desse porte, está vendendo o trabalho de verdade.

Reservar orçamento para a parte invisível. No agente conversacional enterprise, observabilidade, compliance e integração custam mais que a IA em si. Aceitar isso na fase de aprovação é o que separa projeto que entrega de projeto que vira pesadelo seis meses depois.

Aceitar que fazer certo leva tempo. Não é ineficiência, é o preço de não capotar. Um projeto enterprise de 8 a 12 meses não é três projetos de PME concatenados. É um projeto diferente, com complexidade diferente, com risco diferente. Já escrevi sobre isso por outro ângulo, olhando para o risco de confundir velocidade individual com produtividade real.

Distinguir experimento de produto. A Cloudflare fez certo ao chamar vinext de experimental. Muitos fornecedores de IA não fazem essa distinção. Vendem o experimento como produto, e quando aparece o primeiro problema sério em produção, o cliente fica sozinho na pista.

A pergunta que separa quem entrega de quem apresenta

A pergunta certa, em comitê de tecnologia hoje, não é “ele consegue fazer um agente de IA?” ou “ele consegue reimplementar isso em uma semana?”. A camada visível ficou barata, e quase todo mundo consegue fazer alguma versão disso.

A pergunta certa é “ele consegue operar isso em escala, sob SLA, integrado a 12 sistemas, em compliance com 4 regulações, com governança contínua, com rollback claro, com custo previsível, com plano de incidente, com plano de continuidade?”. Essa segunda pergunta filtra 95% dos fornecedores que aparecem nesse mercado, e deveria filtrar uma boa parte das decisões internas também.

Estamos vivendo o melhor momento da história para construir software. A janela de oportunidade é real, e fechá-la por excesso de cautela seria desperdiçar uma vantagem geracional. Mas o trabalho não é mostrar a demo. O trabalho é entregar produção.

Acelerar é fácil. Acelerar com segurança, sabendo onde os buracos estão, é o trabalho.

---

Se esse tema te interessa, adoraria trocar ideias. Me encontre no LinkedIn.