Engenharia de prompt é só o primeiro passo. O problema real é construir sistemas que, mesmo quando a instrução falha, ainda entreguem resultados confiáveis. Os vídeos de 13 e 14 de outubro convergem para a mesma discussão: revisão, custo, autonomia e métricas honestas importam mais do que uma demonstração bonita.

🔗 Onde o prompt não chega

A engenharia de prompt ajuda, mas nenhuma instrução bem formulada corrige, sozinha, as limitações do modelo. No vídeo sobre “Prompt engineering is not enough”, o autor parte de uma pergunta direta: por que resultados confiáveis ainda dependem de revisão manual?

A resposta vai além de “revisão é necessária”. O problema é o que acontece quando essa revisão é automatizada. Quando o ciclo de revisão passa para o modelo, o gargalo de produtividade muda de lugar — o código roda rápido, mas o sistema entra em loop tentando decidir se revisão passou. Esse é o ponto de maior atenção: confiar na automação sem supervisão pode criar um ciclo de validações em que o próprio modelo julga se o trabalho ficou bom.

🔬 Como vender confiança

Uma vez que o sistema existe, a pergunta vira: como garantir que ele é de fato confiável? A resposta está menos em marketing e mais em engenharia. Michele Grant, em “The Agent Works. Does Anyone Trust It?”, passa isso de forma bem clara: confiança não é um sentimento que aparece naturalmente; precisa ser desenhada desde o início.

Os principais pontos da apresentação reforçam essa ideia. Cada decisão executiva sobre um agente deve ser documentada — permissões, propriedade dos dados, registros de log e quando ele pode pedir ajuda. Essa estrutura não é detalhe burocrático; é o que separa um experimento de um produto de verdade. A passagem de sandbox para produção muda o critério de teste: não é mais apenas “o agente funciona?”, e sim “ele cria valor dentro dos controles definidos pela liderança?”.

📊 Automatização é mais complexa do que parece

A ideia de que “70% de automação” é uma métrica estável e segura é um dos perigos mais comuns hoje. Soukaïna Abelhad, em sua apresentação sobre Technical Due Diligence, mostra que números desse tipo escondem três tipos de falha: aritmética, definição e avaliação.

Um número isolado raramente conta a história inteira. É preciso olhar para a carga de trabalho induzida pela IA — revisões, operações manuais, retrabalho — e para o que realmente significa ser “autônomo”. Processamento direto, sem qualquer intervenção humana, é diferente de tarefas onde o modelo sugere e um humano aprova. Esse gap, muitas vezes subestimado, pode aumentar a carga de trabalho com IA enquanto se fala em redução de pessoal.

Steve Jamison complementa esse ponto ao mostrar que, em muitas empresas, o custo real de um PR não é o uso de IA, mas sim o salário do engenheiro que o compõe. Mesmo com gastos em tokens aumentando 60x no último ano, o custo por PR mesclado caiu em parte por causa da produtividade. A chave está em não olhar apenas para o custo de IA, mas para o custo total — salário + IA — por unidade de valor entregue.

🏁 O caminho restante

Os vídeos mostram uma mudança de foco: de “o que o modelo consegue fazer” para “como isso entra no trabalho real sem introduzir riscos”. A parte difícil é transformar essa preocupação em práticas mensuráveis, não em slogans.

Quando o valor de um agente só é real após descontar custos humanos e de infraestrutura, o foco muda de promessa para análise honesta dos dados.

Prompt engineering is not enough: Why does AI deliver unreliable results? · pasquadev · 20min26s

Meta just dropped something insane… (Muse Wonder) · 10min36s

Google just went FRONTIER (Gemini 4 Argon) · 12min15s

Every app on Earth is now open source… whether it likes it or not · Fireship · 5min56s

The Agent Works. Does Anyone Trust It? — Michele Grant, Leading at Scale · Michele Grant · 15min05s

Tokens Are the Cheap Part — Steve Jamison, Jellyfish · Steve Jamison, Jellyfish · 17min32s

What Technical Due Diligence Finds When the Deck Says “70% Automated” — Soukaïna Abelhad · Soukaïna Abelhad · 6min29s