Uma Mudança de Parâmetro de IA Me Custou $54/Mês
Achei que minha migração para Cloud Run tinha sido perfeita — até que um único parâmetro de IA, temperatura configurada em 0.7 em vez de 0, causou 30% de chamadas de API falhando e me custou $54/mês em tokens desperdiçados.
Confiei no Claude para me ajudar a migrar de AWS Lambda para Google Cloud Run. A migração foi perfeita — serviços implantados, workflows executando, usuários felizes. Então verifichei nossas faturas de API e quase caí da cadeira.
*Este é o Parte 3 da minha série de engenharia do DIALØGUE. Se você perdeu: [Parte 1: Introdução ao DIALØGUE] e [Parte 2: Da Publicidade à Engenharia] cobrem a fundação.*
Esta é a história do que acontece quando você deixa IA escrever código de produção sem ser explícito sobre restrições de produção. Spoiler: "fazer funcionar" e "fazer funcionar em produção" são pedidos muito diferentes.
A Migração Que Correu Bem Demais
Depois de brigar com AWS Lambda por meses (cold starts, limites de layers, tudo isso), decidi migrar tudo para Google Cloud Run. Sendo um desenvolvedor pragmático (leia-se: preguiçoso), recrutei o Claude como meu parceiro de programação.
"Me ajuda a migrar essas funções Lambda para Cloud Run," eu disse. "Aqui está o código existente."
Claude entregou lindamente. Dockerfiles limpos, configurações de serviço corretas, Cloud Workflows funcionando. A migração levou apenas um dia em vez das semanas que eu esperava. Fiquei empolgado!
Tudo implantou suavemente. Os serviços iniciaram rápido. Usuários estavam criando podcasts sem problemas. Sucesso, certo?
Então percebi algo estranho nos nossos logs:
```
[ERROR] Segment generation failed: Unexpected token in JSON
[RETRY] Attempting segment generation again...
[SUCCESS] Segment generated successfully
```
Cerca de 30% das nossas chamadas de IA estavam falhando na primeira tentativa mas tendo sucesso na segunda. Não era o fim do mundo — minha lógica de retry estava funcionando! Os usuários não perceberam nenhum problema. Mas cara, essas chamadas extras de API estavam se acumulando.
A Investigação: Culpar a Migração?
Meu primeiro pensamento foi que algo deu errado durante a migração. Talvez o novo ambiente Cloud Run fosse diferente? Problemas de rede no container? Passei horas comparando configurações AWS e GCP.
Tudo parecia idêntico. Mesmos prompts, mesma lógica de retry, mesmo tratamento de erros. Então por que estávamos de repente recebendo respostas JSON malformadas?
Então comecei a comparar o código real. Aqui está o que encontrei:
Versão AWS Lambda (funcionando bem por meses):
```python
response = anthropic.messages.create(
model="claude-3-7-sonnet-20250219",
temperature=0, # Determinístico para JSON
response_format=\{"type": "json_object"\}, # Modo JSON
system="You are a JSON generation assistant. Output only valid JSON.",
messages=[\{"role": "user", "content": prompt\}]
)
```
Versão GCP Cloud Run (migração do Claude):
```python
response = anthropic.messages.create(
model="claude-3-7-sonnet-20250219",
temperature=0.7, # <-- Espera, o quê?
messages=[\{"role": "user", "content": prompt\}]
)
```
Ali estava. Temperatura 0.7.
"Mas esse é um padrão razoável!" você pode dizer. E estaria certo. Para escrita criativa, exploração, brainstorming — 0.7 é perfeitamente sensato. Mas para geração de JSON estruturado? É um desastre.
O Fumante Ativo: JSON Criativo
Depois de adicionar logging detalhado para capturar as respostas reais da IA, encontrei exatamente o que estava acontecendo. Aqui está o que o Claude estava retornando com temperatura 0.7:
```
Here's the podcast segment you requested:
\{
"title": "The Rise of AI Podcasting",
"content": "Welcome back, listeners! Today we're diving into something really fascinating...",
"duration": 120
\}
I hope this segment captures what you were looking for!
```
Viu o problema? Claude estava sendo criativo com o formato da resposta. Às vezes só JSON, às vezes JSON com comentários úteis, às vezes JSON embrulhado em blocos de código markdown. Com temperatura 0.7, estava improvisando como um músico de jazz quando eu precisava de um metrônomo.
O Ponto Cego do Pair Programming com IA
Aqui está a questão sobre trabalhar com IA como parceiro de programação: é incrivelmente bom em fazer o código funcionar, mas não necessariamente otimiza para preocupações de produção a menos que você especifique.
Quando disse "migre esta função Lambda para Cloud Run," o Claude focou nos requisitos da migração:
- ✅ Fazer funcionar no Cloud Run
- ✅ Lidar com os mesmos inputs e outputs
- ✅ Manter a mesma funcionalidade
- ❌ Otimizar para eficiência de produção
Claude escolheu temperatura 0.7 porque é um "padrão razoável" para aplicações de IA. E é mesmo! Para a maioria dos casos de uso, 0.7 oferece um bom equilíbrio de criatividade e consistência.
Mas aqui está o que aprendi: **IA não conhece suas restrições específicas de produção a menos que você as diga.**
Meu código AWS original usava temperatura 0 E modo JSON porque aprendi (do jeito difícil) que a geração de JSON precisa de outputs determinísticos e formatação explícita. Mas durante a migração, nunca disse explicitamente "isso é para geração de dados estruturados" ou "mantenha todas as otimizações específicas de JSON."
Então Claude escreveu código perfeitamente funcional com padrões sensatos. O problema não era a IA — eram meus requisitos incompletos.
A Correção: Sendo Específico com a IA
Uma vez que identifiquei o problema, voltei para o Claude com requisitos melhores:
"Me ajuda a corrigir este código. É para geração de JSON em produção. Preciso de 100% de confiabilidade, zero criatividade. Use temperatura 0 e quaisquer outras otimizações para dados estruturados."
Claude imediatamente sugeriu:
```python
response = anthropic.messages.create(
model="claude-3-5-sonnet",
temperature=0, # Outputs determinísticos
response_format=\{"type": "json_object"\}, # Modo JSON
system="You are a JSON generation assistant. Output only valid JSON.",
messages=[\{"role": "user", "content": prompt\}]
)
```
Espera, Claude removeu o modo JSON que tínhamos! (É isso que acontece quando você não menciona explicitamente cada requisito de produção durante a migração!)
A taxa de sucesso subiu de 70% para 99,9%. Os 0,1% restantes? Timeouts de rede. Não dá para culpar o Claude por esses.
A diferença? Desta vez fui explícito sobre restrições de produção. Não pedi apenas uma migração — pedi código otimizado para produção e focado em confiabilidade.
O Custo Real dos Padrões "Razoáveis"
Deixa eu detalhar o que essa configuração de temperatura "razoável" realmente nos custou:
- **Gerações de podcast diárias**: ~200
- **Taxa de falha**: 30% exigindo retries
- **Chamadas extras de API por dia**: 60 chamadas falhadas precisando de retry
- **Desperdício mensal**: ~1.800 chamadas desnecessárias de API
- **Preço Claude 3.7 Sonnet**: $3 input + $15 output por milhão de tokens
- **Tokens médios por chamada**: ~2.000 input + 1.500 output
- **Custo por retry**: ~$0,03 por tentativa falhada
- **Excesso mensal**: ~$54 em chamadas de API desperdiçadas
Mas o custo real não era apenas os $54/mês. Cada retry adicionava 3-5 segundos ao tempo de geração. Os usuários estavam esperando mais, minhas instâncias Cloud Run estavam iniciando com mais frequência e eu estava queimando quota mais rápido.
O mais irônico? Tudo isso aconteceu porque confiei em IA para tomar decisões de produção sem dar o contexto de produção. Caso clássico de "funciona" vs "funciona eficientemente."
O Que Aprendi Sobre Pair Programming com IA
1. Seja Explícito Sobre Requisitos de Produção
"Fazer funcionar" te dá código funcional. "Fazer funcionar eficientemente em produção com essas restrições" te dá código otimizado. IA é ótima em resolver o problema que você descreve, não o problema que você tem em mente.
2. IA Usa Padrões "Razoáveis", Não "Ótimos"
Temperatura 0.7 é razoável para a maioria das aplicações de IA. Mas sistemas de produção frequentemente precisam de otimizações específicas como temperatura 0 E modo JSON. IA não vai preservar essas a menos que você as mencione explicitamente.
3. Revisão de Código se Aplica ao Código Gerado por IA Também
Só porque IA escreveu não significa que está pronto para produção. Deveria ter detectado isso durante a revisão de código, mas estava tão focado em se a migração funcionava que não auditei os parâmetros.
4. Contexto Importa Mais do Que Você Pensa
Meu código AWS original tinha temperatura 0 E modo JSON por boas razões — aprendidas através de experiência dolorosa. Durante a migração, esse contexto se perdeu porque não o mencionei explicitamente. Agora documento o "porquê" por trás de cada parâmetro e funcionalidade.
Meu Novo Workflow de Pair Programming com IA
Agora quando trabalho com IA em código de produção, sou muito mais explícito sobre restrições:
**Antes:**
"Migre esta função Lambda para Cloud Run"
**Agora:**
"Migre esta função Lambda para Cloud Run. Isso é para geração de JSON em produção — priorize confiabilidade sobre criatividade. Use temperatura 0, modo JSON se disponível, e quaisquer outras otimizações para output de dados estruturados."
Aqui está a config otimizada para produção que o Claude me ajudou a construir:
```python
def get_ai_json_response(prompt: str) -> dict:
"""Geração JSON otimizada para produção com IA"""
response = anthropic.messages.create(
model="claude-sonnet-4-20250514",
temperature=0, # Zero criatividade para dados estruturados
response_format=\{"type": "json_object"\}, # Forçar modo JSON
system="You are a JSON generation assistant. Output only valid JSON.",
messages=[\{
"role": "user",
"content": f"{prompt\}\n\nRespond with valid JSON only."
}]
)
# Tratamento explícito de erros para produção
try:
return json.loads(response.content[0].text)
except json.JSONDecodeError as e:
logger.error(f"JSON parse failed: \{e\}")
logger.error(f"Raw response: {response.content[0].text}")
raise
```
A diferença? Dei à IA o contexto que ela precisava para otimizar para meu caso de uso específico.
Os Resultados
30% menos custos de API, 40% de geração mais rápida. Tudo de uma conversa onde fui realmente específico sobre o que "pronto para produção" significava.
A parte engraçada? Até nossa geração de diálogo "criativa" usa temperatura 0. Acontece que determinístico não significa chato — significa confiável. As conversas ainda soam naturais porque os prompts e a pesquisa de conteúdo fornecem a variedade, não as flutuações aleatórias de temperatura.
Acontece que pair programming com IA funciona muito bem quando você lembra que ainda é programação — precisão nos requisitos te dá precisão nos resultados.
Você já teve um assistente de IA fazendo uma escolha "razoável" que acabou sendo completamente errada para o seu caso de uso? Adoraria ouvir suas histórias de guerra — suspeito que já fomos todos picados por padrões sensatos em algum momento :)
Abraços,
Chandler
Quer criar seus próprios podcasts de IA com JSON garantidamente válido? Experimente o DIALØGUE — 2 créditos gratuitos para começar! :P
Parte 3 da Série de Engenharia do DIALØGUE. Ainda aprendendo que "fazer funcionar" e "fazer funcionar eficientemente" são pedidos completamente diferentes. Acompanhe mais aventuras de pair programming com IA em chandlernguyen.com.
**Próximo na série**: Chegando em cerca de 7 dias — "De 3 Minutos para 500ms: O Bug de Cadastro Que Não Fazia Sentido"
