App autoaperfeiçoável: ciclo fechado de melhorias

1. Por que o App precisa de um ciclo fechado de melhorias

Qualquer LLM‑App vive em um mundo em constante mudança. Você ganha novos usuários e cenários, a OpenAI lança novos modelos e mecanismos de proteção, você mesmo atualiza o servidor MCP, o Agents SDK, o widget de UI… E mesmo que todo o código tivesse sido escrito perfeitamente (sim, eu sei que você quase faz isso), uma única troca de modelo ou de prompt pode, sem perceber, quebrar metade dos casos.

Sem um ciclo de melhorias, a vida é assim. O usuário escreve para o suporte: “O GiftGenius começou a sugerir presentes mais caros que o orçamento” ou “fica pensando por 15 segundos”. Você abre os logs, ajusta algo no system prompt, troca o modelo, faz o deploy. Uma semana depois tudo se repete, mas em outro lugar. O resultado é — um incêndio crônico e um monte de mudanças “mágicas” que ninguém consegue explicar.

Com o ciclo, tudo muda. Você tem:

• um conjunto claro de sinais em técnica, dinheiro, produto e qualidade;
• um ritual regular: olhar para eles e escolher hipóteses;
• mudanças controladas em code/config;
• verificações automáticas: golden cases + LLM‑evals + experimentos.

Então o App deixa de ser um “prompt estático” e vira um sistema vivo, que:

• mostra onde dói e por quê;
• sugere exatamente o que pode ser melhorado;
• protege contra degradação silenciosa após uma mudança “inocente” no prompt.

Bônus: esse ciclo se encaixa muito bem em tudo o que você já fez nos módulos anteriores. Logs e SLO do M17 fornecem sinais técnicos, instrumentação de custos e AARRR do M19 — econômicos e de produto, golden cases e LLM‑evals do M20.1–2 — sinais de qualidade. Resta apenas reunir isso em um ciclo operacional claro.

2. Mapa de sinais para melhorias

Para que o App consiga indicar onde melhorar, é preciso entender claramente quais sinais você tem e de onde eles vêm. É conveniente pensar em quatro grupos.

Os sinais técnicos vêm do seu stack de observability: logs tool_invocation, métricas de latency e error‑rate, health checks de MCP/ACP, falhas de OAuth. Eles respondem à pergunta “o serviço está vivo e o quão estável ele está”.

Os sinais econômicos nascem na instrumentação de custos e no billing: cost_per_tool_call, cost_per_task, cost_per_user, picos inesperados de gasto por ferramentas ou cenários específicos. Eles dizem: “estamos queimando tokens e dinheiro mais do que o esperado” ou, ao contrário, “há folga, dá para melhorar a qualidade”.

Os sinais de produto são formados por eventos como app_opened, workflow_started, workflow_completed, checkout_*. Isso é activation rate, conversões entre etapas do funil, retention por coortes. Eles mostram o que acontece com o comportamento real das pessoas.

Os sinais de qualidade e comportamento incluem resultados de LLM‑evals em golden cases (pontuações de correctness/helpfulness/style/safety), revisões manuais amostrais de diálogos, thumbs up/down, reclamações e avaliações na Store. É o que mais se aproxima da sensação “o App ficou mais inteligente/mais burro”.

É conveniente reunir isso em uma tabela:

Ponto‑chave: todos esses sinais são logados com vínculo a um cenário específico e à versão do App. Ou seja, os eventos incluem pelo menos scenario, appVersion e experimentId. Assim, ao ver que a helpfulness em golden cases caiu de 8.5 para 6.2, você pode dizer não só “ficou pior”, mas “ficou pior no cenário "gift_selection" após o release "1.3.0", na variante do experimento "B"”.

No código, você pode até definir uma estrutura simples para descrever um sinal:

// lib/improvement/signals.ts
export type SignalKind = "slo" | "cost" | "product" | "quality";

export type ImprovementSignal = {
  kind: SignalKind;
  scenario: string;       // e.g. "gift_selection"
  metric: string;         // e.g. "p95_latency_ms", "cost_per_task"
  value: number;
  previous?: number;      // valor "antes"
};

Esses objetos são práticos para dashboards e para o seu futuro assistente de melhorias.

3. Feedback loop canônico: 4 etapas

Agora vamos montar o ciclo de melhoria canônico no qual você pode se apoiar sempre. Ele é extremamente pragmático: quatro etapas.

flowchart TD
  A[Sinal: algo está doendo
ou há oportunidade de crescimento] --> B[Hipótese:
o que e como mudar]
  B --> C[Mudança controlada
em code/config]
  C --> D[Verificação:
offline + online]
  D --> A

Etapa 1. Detectar o problema ou a oportunidade

Nesta etapa você responde à pergunta “para onde olhar”. Exemplos:

• O LLM‑eval em golden cases com orçamento mostra queda de helpfulness.
• p95 latency da ferramenta "suggest_gifts" subiu de 1.2s para 3.8s.
• cost_per_task no cenário "gift_selection" cresceu 40% após a migração para um modelo de reasoning.
• A conversão workflow_completed → checkout_success caiu 5 p.p. após a mudança no wizard de UX.
• Na Store surgiram 10 reclamações em uma semana “presentes mais caros que o limite informado”.

Nuance importante: às vezes o sinal não diz “está ruim”, mas “dá para melhorar”. Por exemplo, você vê que o cost_per_task está bem abaixo do limite aceitável, e o quality score já é 9/10. Logo, dá para tentar um modelo mais caro ou um cenário mais “inteligente” — pode ser que a conversão aumente.

Etapa 2. Formular a hipótese

Hipótese — não é “vamos reescrever o prompt”, e sim “acreditamos que a mudança específica X no componente Y vai melhorar a métrica Z, porque…”. Sem o “porque”, isso não é hipótese, é desejo.

Exemplos:

• “Se colocarmos uma regra de cumprimento estrito do orçamento no system prompt e pedirmos para sempre explicar como o orçamento foi usado, a helpfulness nos casos com orçamento vai subir pelo menos 2 pontos.”
• “Se trocarmos o modelo caro por "gpt-mini" na etapa de rerank, o cost_per_task vai cair 30%, e a conversão não vai cair mais do que 1 p.p.”
• “Se simplificarmos o wizard (juntarmos dois passos em um) e reescrevermos o CTA, o activation rate vai subir 5 p.p.”

No código, é conveniente descrever explicitamente essa hipótese, ao menos como um objeto:

// lib/improvement/hypothesis.ts
export type ImprovementHypothesis = {
  id: string;
  scenario: string;
  description: string;   // "O que mudamos e por quê"
  targetMetric: string;  // e.g. "quality.helpfulness" ou "conversion.checkout"
  successCriteria: string;
};

Sim, é quase como um ticket no Jira, mas pelo menos tipado.

Etapa 3. Fazer uma mudança controlada

Aqui duas palavras são importantes: controlada e separada.

Controlada significa que a mudança está em um PR/commit, vinculada à hipótese, tem changelog e, se possível, feature flag ou versão. Você não apenas “ajustou o prompt em produção”, mas consegue dizer qual release trouxe isso.

Separada significa que você tenta não misturar três hipóteses diferentes no mesmo release. Se você simultaneamente:

• trocar o modelo,
• reescrever metade do system prompt,
• e adicionar um novo passo no UX,

então, mesmo que as métricas melhorem, será difícil entender o que exatamente funcionou. É muito mais honesto avançar em pequenas porções.

Do ponto de vista técnico, as mudanças podem estar em qualquer lugar:

• system prompt do agente (lib/prompt/systemPrompt.ts);
• descrições de ferramentas MCP (description, inputSchema, annotations);
• config do agente (limites de passos de reasoning, escolha do modelo para uma tool específica);
• código do widget (CTA, ordem de passos, texto de erros).

Etapa 4. Verificar se ficou melhor

A verificação se divide em offline e online.

A verificação offline é rodar os golden cases na nova versão do App sem usuários reais. Aqui você já tem:

• LLM‑evals (módulo 20.1);
• lógica de limiar/baseline (módulo 20.2).

Você observa como mudaram os quality scores nos cenários alvo: subiram, caíram, ficaram iguais. Também verifica os safety cases: qualquer ajuste de prompt deve primeiro passar pelo conjunto de safety.

A verificação online é um experimento em tráfego real. No cenário mais simples, você liga a nova versão para N% dos usuários e compara:

• conversão para a ação alvo (checkout, relançamento do cenário);
• cost_per_task;
• reclamações/feedback.

Depois disso, o ciclo ou se encerra (a hipótese é confirmada/refutada e documentada), ou gera uma nova hipótese.

4. “Assistente de melhorias” interno como agente separado

Agora a parte mais interessante: vamos dar ao modelo LLM mais um papel — não só responder aos usuários, mas também ajudar você a melhorar o App. É um agente interno, separado do GiftGenius voltado ao usuário.

O que é isso

Esse assistente vive no seu ambiente interno (no mesmo repo, em Dev Mode, em um ChatGPT App separado). Ele:

• lê logs e amostras de diálogos;
• olha para as métricas;
• analisa o system prompt e as descrições das tools;
• ajuda a formular problemas e propostas de mudanças.

Na prática, você ganha um “produto/analista virtual” que:

• não se cansa de ler diálogos;
• encontra rapidamente padrões recorrentes;
• sabe escrever rascunhos de prompts e de changelog.

Que entrada ele recebe

É útil formalizar a entrada para facilitar a vida do agente. Por exemplo, o tipo:

// lib/improvement/assistant.ts
export type BadDialogExample = {
  id: string;
  userMessages: string[];
  appMessages: string[];
  qualityScore?: number;
};

export type ImprovementInput = {
  scenario: string;
  signals: ImprovementSignal[];      // do capítulo anterior
  examples: BadDialogExample[];
  systemPrompt: string;
  toolsDescription: string;
};

Você pode montar um objeto assim exportando dos logs 10–20 diálogos malsucedidos do cenário "gift_selection" e anexando o system prompt atual e as descrições das ferramentas.

Que saída ele deve fornecer

Também é útil fixar a resposta esperada:

export type ImprovementSuggestion = {
  patterns: string[];     // problemas recorrentes
  promptPatches: string[]; // propostas de trechos para o system prompt
  toolsPatches: string[];  // ideias para descrições de tools
  uxCopyIdeas: string[];   // variações de textos de UX
  changelog: string[];     // lista curta de "o que mudar"
};

O meta‑prompt para esse agente seria algo como:

• “analise os exemplos e os sinais”;
• “descreva 2–3 padrões de problemas”;
• “proponha 1–2 mudanças no prompt, nas descrições das tools e nos textos de UX”;
• “retorne tudo em um JSON rigidamente especificado”.

Depois você pega manualmente esses trechos, discute com o time, integra no código e roda os evals e os experimentos. Princípio importante: esse assistente não altera nada sozinho em produção. Ele gera ideias e texto, não commits.

5. Tipos de mudanças: o que dá para “ajustar”

Quando surge esse assistente e um ciclo claro, é muito fácil reduzir tudo a “me dê uma nova versão do system prompt”. Na prática, o espaço de melhorias é muito mais amplo.

Prompt e instruções

O system prompt define o papel, o tom, as prioridades e as regras rígidas (por exemplo, orçamento, safety, ordem de passos). Você pode:

• simplificar, removendo instruções contraditórias ou duplicadas;
• fortalecer, adicionando regras que faltam (como no exemplo do orçamento);
• adaptar para cenários diferentes (subprompts separados para "gift_selection", "post_purchase_help" etc.).

As descrições das tools ajudam o modelo a entender quando chamar uma ferramenta específica e o que ela faz. Aqui, as melhorias geralmente se resumem a:

• instruções mais explícitas “Use this when… / Do not use when…”;
• refinar formulações (reduzir sobreposição com outras tools);
• adicionar informações sobre consequências (destructiveHint, isConsequential).

As regras de safety são a parte do prompt/descrições que respondem pelo comportamento em domínios difíceis. É melhor mexer nelas apenas após bons safety evals.

Arquitetura de comportamento (behavior)

Às vezes, o problema não se resolve com prompt: é preciso mudar a ordem das ações.

Exemplos:

• adicionar uma etapa obrigatória de esclarecimento de parâmetros antes de chamar uma tool cara;
• tirar parte dos cálculos para uma etapa separada e mais barata (por exemplo, filtragem preliminar no backend);
• limitar o número de chamadas de tools em sequência em um cenário.

Essas mudanças geralmente são descritas no config do agente ou na camada MCP, e não apenas no prompt.

UX e copywriting

Sim, textos de botões e de erros também fazem parte da qualidade. O GiftGenius, que escreve:

“Erro 500. Entre em contato com o administrador.”,

gera uma impressão bem diferente de:

“Não conseguimos obter resposta da loja. Suas ideias selecionadas não se perderam; tente concluir a compra um pouco mais tarde.”.

Telas intermediárias, dicas, estrutura de wizards — tudo isso impacta aquele activation rate e as conversões que você mede.

Economia

Aqui jogamos o jogo bem conhecido “qualidade ↔ custo”:

• escolha do modelo (caro com reasoning, rápido/barato);
• profundidade de passos de reasoning/agente (quantas iterações permitimos);
• limites de diálogo (por exemplo, no máximo N recálculos da seleção em uma sessão);
• modos de fallback “baratos” quando o budget de tokens/limites estoura.

Os sinais daqui alimentam cost_per_task, cost_per_user, a margem e se combinam com o quality score.

6. Guardrails: o que não se deve delegar ao LLM

Quando aparece um “assistente de melhorias” e um ciclo conveniente, é muito tentador apertar o botão “Auto‑otimização” e ir tomar um café. Vamos combinar logo onde esse botão é proibido.

Mudanças em permissões (escopos OAuth, ferramentas MCP, acessos a dados) — isso é sempre zona de human‑in‑the‑loop. Nenhum modelo deve decidir sozinho que agora o App pode ler pedidos, mexer em pagamentos ou enviar e‑mails para usuários. O mesmo vale para o fluxo de commerce: quaisquer mudanças ao redor de ACP/Stripe, limites, tipos de pagamento e estornos passam por revisão humana e testes.

O perfil de safety do App (em quais domínios ele pode aconselhar, onde é obrigado a recusar) — também não é algo a ser delegado ao LLM. O modelo pode ajudar a formular o texto das regras, mas a decisão sobre os temas em que você confia ao App permanece com você.

Política de dados e de logging (o que logamos, por quanto tempo guardamos, como respondemos a pedidos de exclusão de dados) — está na mesma lista. O LLM pode sugerir a estrutura de uma Privacy Policy, mas não deve mudar o retention no código sem a sua participação.

O que dá para semi‑automatizar? Formulações e wording de prompts, descrições de tools e textos de UX, prioridades das ferramentas (em limites razoáveis), perguntas adicionais de esclarecimento. Tudo isso pode ser confiado ao assistente como fonte de ideias, mas a última palavra e a verificação ficam com a pessoa e com os scripts de eval.

7. Exemplo end‑to‑end de ciclo de melhoria (GiftGenius)

Voltemos ao nosso herói.

Problema

O usuário indica um orçamento, mas o GiftGenius frequentemente sugere presentes acima desse limite. Nos logs, aparecem muitas continuações de diálogo “não, isso é caro demais” e “faça mais barato”.

Sinais

Primeiro você vê a qualidade: o LLM‑eval em golden cases do tipo “selecione um presente até 50$” dá helpfulness em torno de 6/10. O juiz escreve regularmente em reason que “os presentes excedem o orçamento” ou “não foi explicado como o orçamento foi considerado”.

Em paralelo chegam sinais de produto e econômicos:

• a conversão em checkout_success para cenários com limite definido é menor do que sem limite;
• parte dos usuários abandona o cenário ao ver opções caras demais;
• cost_per_task para esses cenários é maior, porque o App recalcula os presentes várias vezes a pedido de “faça mais barato”.

Análise com o assistente de melhorias

Você reúne 20 diálogos em que os usuários reclamaram do preço e forma um ImprovementInput:

• scenario = "gift_selection_with_budget";
• signals com queda de helpfulness e de conversão;
• examples com os diálogos;
• o system prompt atual e as descrições das ferramentas.

Você alimenta isso ao agente interno de melhorias. Em resposta, ele devolve, por exemplo:

• Padrões:
  • o orçamento, formulado como “algo em torno de 50$”, é interpretado de forma muito livre;
  • o system prompt não contém a exigência explícita “nunca sugerir presentes acima do limite”;
  • as respostas não explicam ao usuário como exatamente o orçamento foi considerado.
• Propostas:
  • adicionar ao system prompt uma instrução sobre cumprimento rígido do limite;
  • pedir ao modelo para sempre afirmar que “todas as opções ≤ X”;
  • adicionar uma pergunta de esclarecimento quando o orçamento soar vago (“aproximadamente”, “por volta de”).

Hipótese e mudança

Você formula a hipótese:

“Se fixarmos explicitamente o cumprimento rígido do limite e pedirmos para explicar o uso do orçamento, a helpfulness em casos com orçamento subirá pelo menos para 8/10, e a conversão em compra — em 3 p.p.”

Você insere no system prompt o seguinte trecho:

export const budgetRule = `
Se o usuário indicar um orçamento (por exemplo, "até 50$" ou "aproximadamente 30€"),
trate esse valor como um LIMITE SUPERIOR RÍGIDO.

Nunca sugira opções acima desse limite.
Em cada resposta, declare explicitamente que todas as opções cabem no orçamento
e como exatamente (por exemplo: "todos os presentes não custam mais que 45$").
`.trim();

E adiciona o budgetRule ao system prompt geral do GiftGenius.

Validação offline

Você roda o conjunto de golden cases “presentes com orçamento” na nova versão:

• o LLM‑eval de helpfulness sobe de 6.0 para 8.5;
• o correctness também cresce: o orçamento é respeitado;
• o safety não piora (ao menos).

Se, ao contrário, a helpfulness não subir ou o safety cair — a mudança não passa e a hipótese é revista.

Teste online

Depois você inicia o experimento:

• 10% dos usuários recebem a nova versão do prompt (variante B);
• os outros 90% — a antiga (variante A).

Após uma semana, você verifica:

• a conversão workflow_completed → checkout_success para B ficou, digamos, 13% em vez de 10% em A;
• o cost_per_task quase não mudou;
• a fração de diálogos com reclamações “caro demais” caiu.

O experimento é considerado bem‑sucedido.

Consolidação

Depois disso:

• você libera o novo prompt para 100% do tráfego;
• adiciona um novo golden case “orçamento flexível até 50$” ao conjunto de regressão;
• registra o resultado no changelog e, possivelmente, em notas técnicas: para que, em seis meses, fique claro por que há uma formulação tão rígida sobre orçamento no prompt.

Ciclo encerrado. A próxima iteração pode tratar, por exemplo, de recomendações para pessoas com hobbies muito raros ou da otimização de custos da seleção.

8. Mini roadmap de um App autoaperfeiçoável

Para que isso não pareça “mais 100500 tarefas extra”, é útil ver qual é o mínimo necessário para que o App já seja considerado autoaperfeiçoável, e o que pode ser adicionado depois.

Versão 1.0: improvement loop mínimo

No primeiro passo, três coisas bastam.

Primeiro, logs estruturados e SLO básicos. Você já sabe logar tool_invocation, workflow_completed, checkout_* com requestId, userId, scenario, appVersion, costEstimateUsd. Em cima disso, constroem‑se os SLO: latency, error‑rate, sucesso de checkout.

Segundo, 10–20 golden cases e um script de LLM‑eval. Um conjunto pequeno, mas bem escolhido de exemplos para os cenários‑chave + safety cases. Um script de CLI que os roda pelo App e pelo juiz e gera avaliações em JSON.

Terceiro, um ritual simples a cada 2 semanas. Sentar (sozinho ou com o time), abrir:

• 2–3 dashboards de SLO, custo, métricas de produto;
• o relatório de LLM‑eval dos golden cases;

e escolher 1–2 hipóteses para o próximo ciclo. Formular, documentar, fazer um pequeno release, verificar.

Versão 2.0: improvement loop “inteligente”

No nível seguinte aparecem:

Assistente de melhorias interno. É um agente descrito separadamente (ou um ChatGPT App) que recebe um ImprovementInput e retorna um ImprovementSuggestion. Ele ajuda você a não gastar horas vasculhando diálogos manualmente.

Relatórios automatizados. Com base em logs e evals é possível gerar:

• clusters de casos problemáticos (por exemplo, todos os casos em que o usuário reescreveu o orçamento);
• rascunhos prontos para uso de mudanças em prompts e descrições de tools;
• um changelog curto.

Hooks de CI. Qualquer mudança em prompts, configs de agentes, descriptions de ferramentas dispara automaticamente:

• o golden suite funcional;
• o safety suite.

Se os safety cases falham ou a qualidade dos cenários‑chave deixa de passar os limiares — o build fica vermelho, sem release.

9. Prática

Exercício 1. Mini feedback loop para o seu App

Escolha um cenário‑chave do seu aplicativo. Para o GiftGenius nós já escolhemos “seleção e compra de presente”; você pode escolher um cenário similar ou o seu.

Descreva livremente (ou crie um pequeno improvement-plan.md):

Quais sinais você vai acompanhar. Um de cada:

• técnico: por exemplo, p95 latency na ferramenta que faz o trabalho principal;
• econômico: cost_per_task nesse cenário;
• de produto: conversão workflow_started → workflow_completed ou até a ação alvo;
• de qualidade: quality_score médio em alguns golden cases desse cenário.

Depois, fixe quais limiares você considera degradação. Nada de “vamos ver algum dia”, e sim algo bem concreto:

• p95 > 5 segundos — ruim;
• cost_per_task subiu mais de 30% sem aumento de receita — alerta;
• quality_score caiu abaixo de 7 — é preciso investigar.

E formule a primeira hipótese. Por exemplo:

“Suspeito que estamos fazendo perguntas de esclarecimento demais. Se encurtarmos o wizard em um passo e deixarmos as perguntas um pouco mais gerais, o activation rate vai subir e a helpfulness quase não sofrerá. Vou verificar isso por meio de uma pequena mudança de UX e um experimento A/B.”

Isso já não é apenas “vamos melhorar o UX”, e sim um passo bem concreto no ciclo.

Exercício 2. Meta‑prompt para o assistente de melhorias

Tente rascunhar o texto de um prompt para o agente interno de melhorias do seu App. Você pode começar simples:

• Descrever quem ele é: “Você é o analista de qualidade do App N, que…”
• Listar qual entrada ele recebe: diálogos, sinais, system prompt, descriptions.
• Formular as tarefas:
  • encontrar 2–3 padrões de problemas;
  • propor 1–2 mudanças no prompt, nas tools e nos textos de UX;
  • montar um changelog curto.
• Descrever o formato da resposta: JSON estruturado com os campos patterns, suggestions, changelog.

Mesmo que você ainda não chame esse agente a partir do código, um único prompt assim já vai ajudar a estruturar melhor seu pensamento sobre como melhorar o App.

10. Erros comuns ao construir o ciclo de melhorias

Erro nº 1: otimizar apenas para uma métrica.
É muito tentador focar em uma única coisa. Dá para perseguir apenas o custo, ficar feliz com a conta menor da OpenAI — e não perceber que o quality score, as conversões e o retention caíram. O ciclo de melhorias deve olhar para o conjunto de métricas: qualidade ↔ dinheiro ↔ comportamento dos usuários.

Erro nº 2: mudanças “mágicas” de prompt sem medições.
A frase “reescrevi o system prompt, agora deve estar melhor” sem golden cases e evals — é um jeito de se dar um susto daqui a algumas semanas. Qualquer mudança de prompt — especialmente em produção — deve passar por um pipeline claro: conjunto de casos, LLM‑eval antes/depois e, se necessário, experimento online. Caso contrário, você não melhora o App, apenas espalha a qualidade em direções aleatórias.

Erro nº 3: deploy automático de mudanças do LLM‑assistente.
Mesmo que o assistente de melhorias escreva trechos de prompt lindíssimos e descrições de ferramentas muito convincentes, isso não é motivo para empurrá‑los para a produção sem review. O modelo pode não ver todas as restrições de negócio, riscos de safety, o contexto das suas métricas. O papel dele é de consultor, não de DevOps com direito a release.

Erro nº 4: falta de vínculo das mudanças com hipótese e sinais.
Às vezes os times fazem ajustes “por sentimento” e não registram que sinal levou à mudança e qual hipótese estão testando. No fim, após um mês, ninguém lembra por que apareceu um parágrafo estranho no prompt e quem precisava dele. Um bom PR de qualidade deve responder pelo menos três perguntas: “o que doía?”, “o que estamos mudando?”, “por qual métrica vamos saber que ficou melhor?”.

Erro nº 5: esquecer o safety ao melhorar.
Na corrida pela utilidade, é fácil afrouxar restrições de safety, remover “recusas desnecessárias” do prompt ou esquecer de rodar os safety cases. Qualquer mudança no system prompt, nas descrições de tools e no behavior do agente deve primeiro passar pelo conjunto de safety evals. Se algum caso que antes passava agora falha — é sinal de parada, por mais bonitas que pareçam as outras métricas.

Erro nº 6: querer “otimizar tudo de uma vez”.
Reescrever metade do prompt, trocar o modelo, adicionar mais uma tool MCP e um novo wizard — tudo no mesmo release — parece produtivo, mas mata totalmente a possibilidade de entender qual mudança fez efeito. O ciclo de melhorias só é eficaz quando é iterativo e focado: uma‑duas hipóteses, um conjunto pequeno de mudanças, um plano de rollback claro.

Erro nº 7: transformar o ciclo de melhorias em um raro “dia de faxina geral”.
Se, a cada seis meses, você faz um grande “dia da qualidade”, e nos outros meses vive sem evals e sem análise de métricas, o App vai “seguir a correnteza” na maior parte do tempo. Muito mais útil é um ritual pequeno, mas regular: semanalmente/quinzenalmente olhar os sinais, atualizar hipóteses e dar pequenos passos. É assim que seu ChatGPT App deixa de ser estático e passa a realmente se autoaperfeiçoar.