Esqueleto primeiro: prove o fluxo de trabalho de forma barata, depois escale

Agentes tendem a construir cada etapa em tamanho total antes que algo tenha sido executado de ponta a ponta. Em trabalhos de dados e IA, isso falha de forma cara: um prompt errado roda em uma tabela inteira, um grão errado é descoberto depois que vinte modelos existem, um grande armazém queima créditos em uma consulta que retorna a resposta errada.

Essa habilidade muda a ordem do trabalho:

1. Faça o caminho completo funcionar com a entrada mínima possível com as configurações mais baratas.
2. Prove com um teste.
3. Escale em degraus com custo controlado, medindo e projetando o custo antes de cada um.
4. Só então adicione recursos, um de cada vez, reexecutando os testes após cada um.

Quando Usar

• Um fluxo de trabalho com 2+ etapas (ingestão -> transformação -> modelo/LLM -> saída), ou qualquer coisa que toque em computação paga: créditos de armazém, tokens de LLM, embeddings, chamadas de API.
• Dados novos ou desconhecidos, uma nova ferramenta ou SDK, uma arquitetura que não rodou neste ambiente antes.
• O usuário pede para "construir X de ponta a ponta", "configurar o pipeline", "processar todos os documentos", "criar os modelos".

Pule para: correções de um arquivo, uma única consulta, trabalho já provado em escala total, ou quando o usuário explicitamente diz para ir direto para a escala total (então ainda declare o custo projetado primeiro).

Etapa 0 - Defina "funciona" antes de construir

Escreva, e mostre ao usuário em 3-5 linhas:

• O caminho de ponta a ponta mais fino: cada etapa presente, o mínimo de cada. Exemplo: 1 tabela de origem -> 1 transformação -> 1 chamada de LLM -> 1 linha de saída.
• Um teste de aprovação/reprovação que uma pessoa possa verificar, por exemplo, "para estas 3 linhas de amostra, a saída tem as colunas A, B, C e o valor para a linha 2 é X". Prefira testes com uma resposta correta conhecida.
• Um orçamento: gasto e tempo máximos para todo o trabalho, e para o esqueleto (o esqueleto deve custar quase nada).

Se o usuário não deu um orçamento, proponha um e diga isso.

Etapa 1 - Escreva a escada

Planeje o trabalho como degraus. Cada degrau adiciona exatamente uma coisa e tem um portão.

Mostre a escada ao usuário antes de construir, a menos que a tarefa seja pequena. Mantenha-a curta.

Etapa 2 - Construa L0, o esqueleto funcional

• Cada etapa existe e está conectada; nenhuma é polida.
• Codifique fixamente ou simule qualquer coisa que não esteja no caminho crítico (configuração, retentativas, UI, log além de um print).
• Use as configurações mais baratas em todos os lugares (veja Alavancas de Custo).
• Execute. Se falhar, corrija o caminho; não comece a adicionar recursos.
• Olhe a amostra antes de escalá-la. Leia alguns registros brutos e meça o que você está pagando. A maioria das vitórias baratas se esconde aqui: registros duplicados (cache por hash de conteúdo), texto repetido em cada registro (cabeçalhos, rodapés, avisos legais, assinaturas, seções de modelo), entradas vazias ou inválidas que a API ainda cobra. Conte quanto de cada custo cada um representa; remover um rodapé que é 70% de cada documento vale mais do que qualquer ajuste posterior.

Não permitido até que L0 passe: uma segunda origem, um segundo modelo ou tabela, paralelismo, ajuste, UI, abstrações, tratamento de casos extremos que ainda não foram vistos.

Etapa 3 - Escale em degraus com custo controlado

Em cada degrau:

1. Execute no tamanho da entrada do degrau.
2. Registre: registros de entrada/saída, erros, tempo de relógio, custo (tokens, créditos, chamadas de API).
3. Projete o próximo degrau: custo por registro x próximo tamanho, tempo por registro x próximo tamanho.
4. Portão: continue apenas se o teste passar, os erros forem compreendidos e a projeção estiver abaixo do orçamento.

…