Do demo de IA ao produto: o que separa o prompt da produção

A ilusão do protótipo pronto

Ferramentas de programação assistida por IA conseguem transformar uma descrição em linguagem natural, instruções de sistema e alguns documentos em uma interface funcional em cerca de 45 minutos. O resultado pode parecer um produto empresarial completo, com layout responsivo, animações, modo escuro e uma demonstração convincente no caminho feliz de um único usuário. A tese do texto é que essa aparência esconde a maior parte do trabalho necessário para operar um produto de IA com segurança, confiabilidade e viabilidade financeira.

Em produção, entradas maiores, múltiplos usuários, falhas do provedor e dados com diferentes níveis de acesso expõem dívidas arquiteturais que o protótipo não resolve. Entre os problemas citados estão analisadores frágeis para JSON, reenvio integral do histórico e aumento de latência e custos, buscas vetoriais sem controle por usuário, ausência de avaliações automatizadas, falta de limites de tempo e mecanismos de degradação, além de chaves expostas e vulnerabilidade a injeção de prompt. O texto ilustra os efeitos com cenários como uma conversa que chega a enviar de 8.000 a 15.000 tokens por turno, uma interface que congela sob limitação do provedor e uma fatura que aumenta em US$ 14 mil por reenvio indiscriminado de contexto.

Do “vibe coding” à engenharia de produto

O autor não recomenda abandonar o desenvolvimento rápido. A proposta é tratá-lo como um “PRD vivo”: um meio de testar demanda, ergonomia da interação, tom das respostas e viabilidade do fluxo com usuários reais. Depois dessa validação, o protótipo não deveria ser enviado diretamente à produção; ele deve ser entregue à engenharia junto de requisitos explícitos para cinco fronteiras determinísticas.

A primeira é a camada de experiência, com transmissão gradual da resposta, estados intermediários informativos e um comando para interromper gerações. A segunda é a segurança, que deve validar entradas, remover informações pessoais identificáveis antes do envio e limitar o uso por usuário e organização. A terceira é o controle de contexto e permissões: cada trecho indexado precisa carregar metadados de acesso, e a busca deve filtrar os resultados antes de montar o contexto do modelo.

A quarta fronteira é o roteamento econômico. Consultas simples podem usar modelos compactos, enquanto solicitações complexas são encaminhadas a modelos de raciocínio; cache de prompts, poda de contexto e limites rígidos de tempo também ajudam a controlar custos e evitar esperas indefinidas. A quinta é o controle de qualidade, com validação de esquema, medição de fundamentação das afirmações e uma resposta determinística de fallback quando a saída não for estruturalmente válida ou não estiver suficientemente apoiada pelas fontes recuperadas.

Auditoria e métricas

Antes de um teste com clientes ou de um lançamento, o texto sugere cinco verificações: identidade e permissões; qualidade, com um conjunto de 50 a 100 consultas realistas executado automaticamente em CI/CD; tratamento de falhas; economia unitária para uma escala de 10 mil usuários ativos por dia; e observabilidade, com rastreamento capaz de reconstituir entradas sanitizadas, trechos recuperados, parâmetros, latência e custos.

As métricas recomendadas são taxa de conclusão de tarefas acima de 85%, fundamentação acima de 95%, bloqueio de políticas e injeções, tempo até o primeiro token inferior a 1,2 segundo, latência total de até 4,5 segundos e custo inferior a US$ 0,02 por tarefa resolvida. A conclusão é que uma demonstração prova que o modelo responde; somente a engenharia ao redor dele pode demonstrar que o sistema merece confiança em escala.