App auto‑mejorable: ciclo cerrado de mejoras

1. Por qué una App necesita un ciclo cerrado de mejoras

Cualquier LLM‑App vive en un mundo cambiante. Os llegan nuevos usuarios y escenarios, OpenAI lanza modelos y mecanismos de protección nuevos, vosotros mismos actualizáis el servidor MCP, el Agents SDK, el widget de UI… Y aunque todo el código estuviera escrito de forma impecable (sí, sí, ya sé que casi lo hacéis así), un simple cambio de modelo o de prompt puede romper discretamente la mitad de los casos.

Sin ciclo de mejoras, la vida se ve así. Un usuario escribe a soporte: «GiftGenius ha empezado a proponer regalos por encima del presupuesto» o «se queda pensando durante 15 segundos». Abrís los logs, tocáis algo en el system‑prompt, cambiáis el modelo, desplegáis. A la semana se repite todo, pero en otro sitio. Resultado: incendio crónico y un montón de cambios «mágicos» que nadie puede explicar.

Con el ciclo es distinto. Tenéis:

• un conjunto claro de señales sobre técnica, dinero, producto y calidad;
• un ritual periódico: mirarlas y elegir hipótesis;
• cambios controlados en code/config;
• comprobaciones automáticas: golden cases + LLM‑evals + experimentos.

Entonces la App deja de ser un «prompt congelado» y se convierte en un sistema vivo que:

• muestra dónde duele y por qué;
• sugiere qué exactamente se puede mejorar;
• protege contra la degradación silenciosa tras un cambio «inocente» en el prompt.

Además, bonus: este ciclo encaja muy bien con todo lo que ya habéis hecho en los módulos anteriores. Los logs y SLO de M17 dan señales técnicas; la instrumentación de costes y AARRR de M19 — las económicas y de producto; los golden cases y LLM‑evals de M20.1–2 — señales de calidad. Solo queda unirlo en un ciclo operativo comprensible.

2. Mapa de señales para mejoras

Para que la App pueda sugerir por sí misma dónde mejorarla, hay que entender con claridad qué señales tenéis en general y de dónde vienen. Es útil pensar en cuatro grupos.

Las señales técnicas llegan de vuestro stack de observabilidad: logs de tool_invocation, métricas de latency y error‑rate, health checks de MCP/ACP, fallos de OAuth. Responden a la pregunta «¿está vivo el servicio y cuán estable está?».

Las señales económicas nacen en la instrumentación de costes y en el billing: cost_per_tool_call, cost_per_task, cost_per_user, picos inesperados de gasto por herramientas o escenarios concretos. Dicen: «estamos quemando tokens y dinero más de lo esperado» o, al contrario, «hay margen, podemos mejorar la calidad».

Las señales de producto se forman a partir de eventos como app_opened, workflow_started, workflow_completed, checkout_*. Son el activation rate, las conversiones entre pasos del embudo, la retención por cohortes. Muestran qué pasa con el comportamiento real de las personas.

Las señales de calidad y comportamiento incluyen los resultados de LLM‑evals sobre golden cases (puntuaciones de correctness/helpfulness/style/safety), revisiones manuales por muestreo de diálogos, thumbs up/down, quejas y reseñas en la Store. Esto es lo más cercano a la sensación de «la App se ha vuelto más lista/más torpe».

Es útil reunirlo en una tabla:

Punto clave: todas estas señales se registran con referencia al escenario concreto y a la versión de la App. Es decir, en los eventos aparecen al menos scenario, appVersion y experimentId. Entonces, al ver que la helpfulness en los golden cases ha caído de 8,5 a 6,2, podéis decir no solo «ha empeorado», sino «ha empeorado en el escenario "gift_selection" después del release "1.3.0", en la variante del experimento "B"».

En el código incluso podéis introducir una estructura simple para describir la señal:

// 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"
};

Objetos así son cómodos tanto para los dashboards como para vuestro futuro asistente de mejoras.

3. Feedback loop canónico: 4 pasos

Ahora compongamos el ciclo de mejora canónico, en el que podréis apoyaros cada vez. Es lo más aterrizado posible: cuatro pasos.

flowchart TD
  A[Señal: algo duele
o hay oportunidad de crecimiento] --> B[Hipótesis:
qué y cómo cambiamos]
  B --> C[Cambio controlado
en code/config]
  C --> D[Verificación:
offline + online]
  D --> A

Paso 1. Detectar un problema u oportunidad

En este paso respondéis a la pregunta «dónde mirar». Ejemplos:

• El LLM‑eval en golden cases con presupuesto muestra una caída de la helpfulness.
• p95 latency de la herramienta "suggest_gifts" subió de 1,2 s a 3,8 s.
• cost_per_task en el escenario "gift_selection" creció en 40 % tras pasar a un modelo de reasoning.
• La conversión de workflow_completed → checkout_success cayó en 5 p. p. después de un cambio en el wizard de UX.
• En la Store aparecieron en una semana 10 quejas de «regalos más caros que el límite indicado».

Matiz importante: a veces la señal no dice «mal», sino «se puede mejor». Por ejemplo, veis que cost_per_task está claramente por debajo del umbral permitido, y el quality score ya es 9/10. Entonces, se puede probar un modelo más caro o un escenario más «listo» — quizá la conversión suba.

Paso 2. Formular la hipótesis

Una hipótesis no es «reescribiremos el prompt», sino «creemos que el cambio concreto X en el componente Y mejorará la métrica Z, porque…». Sin el «porque» no es una hipótesis, es un deseo.

Ejemplos:

• «Si ponemos una regla de cumplimiento estricto del presupuesto en el system‑prompt y pedimos explicar siempre cómo se usó el presupuesto, la helpfulness en casos con presupuesto subirá al menos 2 puntos».
• «Si sustituimos el modelo caro por "gpt-mini" en el paso de rerank, cost_per_task bajará un 30 %, y la conversión no caerá más de 1 p. p.».
• «Si simplificamos el wizard (combinamos dos pasos en uno) y reescribimos la CTA, el activation rate subirá 5 p. p.».

En el código es cómodo describir esta hipótesis de forma explícita, aunque sea como un objeto:

// lib/improvement/hypothesis.ts
export type ImprovementHypothesis = {
  id: string;
  scenario: string;
  description: string;   // "Qué cambiamos y para qué"
  targetMetric: string;  // e.g. "quality.helpfulness" o "conversion.checkout"
  successCriteria: string;
};

Sí, es casi como un ticket de Jira, pero al menos con tipos.

Paso 3. Hacer un cambio controlado

Aquí importan dos palabras: controlado y separado.

Controlado significa que el cambio está formalizado como PR/commit, vinculado a la hipótesis, con changelog y, en lo posible, feature flag o versión. No es que «tocasteis el prompt en producción», sino que podéis decir qué release exacto lo trajo.

Separado significa que intentáis no mezclar tres hipótesis diferentes en el mismo release. Si a la vez:

• cambiáis el modelo,
• reescribís la mitad del system‑prompt,
• y añadís un paso nuevo en el UX,

incluso si las métricas mejoran, será difícil entender qué fue lo que funcionó. Es mucho más honesto avanzar en porciones pequeñas.

Desde el punto de vista técnico, los cambios pueden estar en cualquier parte:

• system‑prompt del agente (lib/prompt/systemPrompt.ts);
• descripciones de herramientas MCP (description, inputSchema, annotations);
• config del agente (límites de pasos de reasoning, elección de modelo para una tool concreta);
• código del widget (CTA, orden de pasos, textos de error).

Paso 4. Comprobar si ha mejorado

La verificación se divide en offline y online.

La verificación offline es pasar golden cases por la nueva versión de la App sin usuarios reales. Aquí ya tenéis:

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

Observáis cómo han cambiado los quality scores en los escenarios objetivo: si suben, bajan o se quedan igual. También comprobáis los casos de safety: cualquier cambio de prompt debe pasar primero por el conjunto de safety.

La verificación online es un experimento con tráfico real. En la variante más simple, activáis la nueva versión para N % de usuarios y comparáis:

• la conversión a la acción objetivo (checkout, reinicio del escenario);
• cost_per_task;
• quejas/feedback.

Después de esto, o bien se cierra el ciclo (la hipótesis se confirma/se refuta y queda documentada) o bien se genera una nueva hipótesis.

4. «Asistente de mejoras» interno como agente aparte

Ahora viene lo interesante: demos a la LLM otro rol — no solo responder a los usuarios, sino también ayudar a vosotros a mejorar la App. Es un agente interno, separado del GiftGenius de cara al usuario.

Qué es exactamente

Este asistente vive en vuestro entorno interno (en el mismo repo, en Dev Mode, en un ChatGPT App aparte). Él:

• lee logs y muestras de diálogos;
• mira métricas;
• analiza el system‑prompt y las descripciones de tools;
• ayuda a formular problemas y propuestas de cambio.

En esencia, obtenéis un «producto/analista virtual» que:

• no se cansa de leer diálogos;
• encuentra rápidamente patrones repetidos;
• sabe escribir borradores de prompts y de changelog.

Qué entrada acepta

Es útil formalizar la entrada, para que al agente le resulte más fácil. Por ejemplo, un tipo:

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

export type ImprovementInput = {
  scenario: string;
  signals: ImprovementSignal[];      // del apartado anterior
  examples: BadDialogExample[];
  systemPrompt: string;
  toolsDescription: string;
};

Podéis componer un objeto así exportando de los logs 10–20 diálogos fallidos del escenario "gift_selection" y adjuntando el system‑prompt actual y las descripciones de las herramientas.

Qué salida debe dar

También es útil fijar la respuesta esperada:

export type ImprovementSuggestion = {
  patterns: string[];     // problemas recurrentes
  promptPatches: string[]; // propuestas de fragmentos para el system-prompt
  toolsPatches: string[];  // ideas para las descripciones de tools
  uxCopyIdeas: string[];   // variantes de textos de UX
  changelog: string[];     // lista breve de "qué cambiar"
};

El meta‑prompt para este agente sería algo como:

• «analiza los ejemplos y señales»;
• «describe 2–3 patrones de problemas»;
• «propón 1–2 cambios en el prompt, en las descripciones de tools y en los textos de UX»;
• «devuélvelo todo en un JSON estrictamente definido».

Después ya tomáis esos fragmentos, los discutís en el equipo, los integráis en el código y los pasáis por los evals y los experimentos. Principio importante: este asistente no cambia nada en producción por sí mismo. Genera ideas y texto, no commits.

5. Tipos de cambios: qué se puede «ajustar»

Cuando aparece un asistente así y un ciclo comprensible, es muy fácil reducirlo todo a «échame una versión nueva del system‑prompt». En realidad, el espacio de mejoras es mucho más amplio.

Prompt e instrucciones

El system‑prompt define el rol, el tono, las prioridades y las reglas estrictas (por ejemplo, presupuesto, safety, orden de pasos). Se puede:

• simplificar, eliminando instrucciones contradictorias o duplicadas;
• reforzar, añadiendo reglas que faltan (como en el ejemplo del presupuesto);
• adaptar a distintos escenarios (subprompts separados para "gift_selection", "post_purchase_help", etc.).

Las descripciones de tools ayudan al modelo a entender cuándo invocar una herramienta concreta y qué hace. Aquí las mejoras suelen resumirse en:

• ser más explícitos con «Use this when… / Do not use when…»;
• precisar formulaciones (reducir el solapamiento con otras tools);
• añadir información sobre consecuencias (destructiveHint, isConsequential).

Las reglas de safety son la parte del prompt/descripciones que responde por el comportamiento en dominios complejos. Es mejor tocarlas solo después de buenos safety‑evals.

Arquitectura del comportamiento (behavior)

A veces el problema no se resuelve con un prompt: hay que cambiar el orden de acciones.

Ejemplos:

• añadir un paso obligatorio de aclaración de parámetros antes de invocar una tool cara;
• llevar parte de los cálculos a un paso separado y más barato (por ejemplo, filtrado preliminar en el backend);
• limitar el número de invocaciones de tools consecutivas en un mismo escenario.

Estos cambios suelen describirse en la config del agente o en la capa MCP, no solo en el prompt.

UX y copywriting

Sí, los textos en botones y errores también forman parte de la calidad. Un GiftGenius que escribe:

«Error 500. Ponte en contacto con el administrador»,

genera una impresión muy distinta de:

«No hemos podido obtener respuesta de la tienda. Tus ideas seleccionadas no se han perdido; intenta completar la compra un poco más tarde».

Pantallas intermedias, ayudas, estructura de los wizards: todo esto impacta en esa tasa de activación y en las conversiones que medís.

Economía

Aquí jugamos al conocido trade‑off «calidad ↔ coste»:

• elección del modelo (uno caro con reasoning, rápido/barato);
• profundidad del reasoning/pasos del agente (cuántas iteraciones permitimos);
• límites del diálogo (por ejemplo, no más de N recálculos de la selección en una sesión);
• modos de fallback «baratos» cuando el budget de tokens/límites se agota.

Las señales de aquí van a cost_per_task, cost_per_user, al margen y se combinan con el quality score.

6. Guardrails: qué no se debe dejar en manos de una LLM

Cuando en el sistema aparece un «asistente de mejoras» y un ciclo cómodo, apetece mucho pulsar el botón «Auto‑optimizar» e irse a por un café. Acordemos desde ya dónde ese botón está prohibido.

Cambios en permisos (OAuth scopes, herramientas MCP, accesos a datos) — esto siempre es zona de human‑in‑the‑loop. Ningún modelo debe decidir por sí mismo que ahora la App puede leer pedidos, tocar pagos o enviar correos a usuarios. Lo mismo aplica al flujo de commerce: cualquier cambio alrededor de ACP/Stripe, límites, tipos de pago y devoluciones pasa por revisión humana y testing.

El perfil de safety de la App (en qué dominios puede aconsejar, dónde debe denegar) tampoco es algo que convenga delegar en una LLM. El modelo puede ayudar a formular el texto de las reglas, pero la decisión de qué temas confiáis a la App es vuestra.

La política de datos y de logging (qué registramos, cuánto guardamos, cómo respondemos a las solicitudes de borrado de datos) — en la misma lista. La LLM puede sugerir la estructura de la Privacy Policy, pero no debe cambiar la retención en el código sin vuestra participación.

¿Qué se puede semi‑automatizar? Formulaciones y redacción de prompts, descripciones de tools y textos de UX, prioridades de herramientas (en límites razonables), preguntas aclaratorias adicionales. Todo esto se puede confiar al asistente como fuente de ideas, pero la última palabra y la verificación son del humano y de los scripts de eval.

7. Ejemplo end‑to‑end de ciclo de mejora (GiftGenius)

Volvamos a nuestro protagonista.

Problema

El usuario indica un presupuesto, pero GiftGenius a menudo propone regalos por encima de ese límite. En los logs se ven muchas continuaciones del diálogo «no, eso es demasiado caro» y «hazlo más barato».

Señales

Primero veis la calidad: el LLM‑eval en golden cases del tipo «elige un regalo hasta 50 $» da una helpfulness alrededor de 6/10. El juez escribe regularmente en reason que «los regalos superan el presupuesto» o «no se explica cómo se ha tenido en cuenta el presupuesto».

En paralelo llegan señales de producto y económicas:

• la conversión a checkout_success en escenarios con límite marcado es inferior a la de escenarios sin límite;
• parte de los usuarios abandona el escenario tras ver opciones demasiado caras;
• cost_per_task para estos escenarios es mayor, porque la App recalcula varias veces los regalos ante «hazlo más barato».

Análisis con el asistente de mejoras

Recopiláis 20 diálogos donde los usuarios se quejaron del precio y formáis un ImprovementInput:

• scenario = "gift_selection_with_budget";
• signals con la caída de helpfulness y conversión;
• examples con los diálogos;
• el system‑prompt actual y las descripciones de tools.

Se lo dais al agente interno de mejoras. Como respuesta devuelve, por ejemplo:

• Patrones:
  • el presupuesto formulado como «aproximadamente hasta 50 $» se interpreta demasiado libremente;
  • el system‑prompt no contiene el requisito explícito «nunca propongas regalos por encima del límite»;
  • las respuestas no explican al usuario cómo se ha tenido en cuenta el presupuesto.
• Propuestas:
  • añadir al system‑prompt una instrucción sobre el cumplimiento estricto del límite;
  • pedir al modelo que siempre diga que «todas las opciones ≤ X»;
  • añadir una pregunta aclaratoria si el presupuesto suena difuso («aproximadamente», «alrededor de»).

Hipótesis y cambio

Formuláis la hipótesis:

«Si fijamos explícitamente el cumplimiento estricto del límite y pedimos explicar el uso del presupuesto, la helpfulness en casos con presupuesto subirá al menos a 8/10, y la conversión a compra — en 3 p. p.».

Introducís en el system‑prompt el siguiente fragmento:

export const budgetRule = `
Si el usuario indica un presupuesto (por ejemplo, "hasta 50$" o "aproximadamente 30€"),
trata esa cantidad como un LÍMITE superior ESTRICTO.

Nunca ofrezcas opciones por encima de ese límite.
En cada respuesta, di explícitamente que todas las opciones respetan el presupuesto
y cómo exactamente (por ejemplo: "todos los regalos no superan los 45$").
`.trim();

Y añadís budgetRule al system‑prompt general de GiftGenius.

Validación offline

Ejecutáis el conjunto de golden cases «regalos con presupuesto» en la nueva versión:

• la helpfulness del LLM‑eval sube de 6,0 a 8,5;
• también sube la correctness: se respeta el presupuesto;
• la safety no empeora (al menos).

Si ocurre lo contrario — la helpfulness no sube o la safety baja — el cambio no pasa y se revisa la hipótesis.

Test online

Luego lanzáis el experimento:

• el 10 % de usuarios recibe la nueva versión del prompt (variante B);
• el 90 % restante — la antigua (variante A).

A la semana miráis:

• la conversión workflow_completed → checkout_success para B se ha puesto, digamos, en 13 % frente a 10 % en A;
• cost_per_task casi no ha cambiado;
• la proporción de diálogos con quejas de «demasiado caro» ha bajado.

El experimento se considera exitoso.

Consolidación

Después de esto:

• desplegáis el nuevo prompt al 100 % del tráfico;
• añadís un nuevo golden case «presupuesto suave hasta 50 $» al conjunto de regresión;
• fijáis el resultado en el changelog y, quizá, en tech notes: para que dentro de seis meses se entienda por qué hay una formulación tan estricta sobre el presupuesto en el prompt.

Ciclo cerrado. La siguiente iteración puede tratar, por ejemplo, de recomendaciones para personas con aficiones muy raras o de optimización del coste de selección.

8. Mini hoja de ruta de una App auto‑mejorable

Para que no parezca «otras cien mil tareas por encima», es útil ver cuál es el mínimo necesario para que la App ya se considere auto‑mejorable y qué se puede añadir después.

Versión 1.0: feedback loop mínimo

En el primer paso bastan tres cosas.

Primero, logs estructurados y SLO básicos. Ya sabéis loguear tool_invocation, workflow_completed, checkout_* con requestId, userId, scenario, appVersion, costEstimateUsd. Sobre esto se construyen los SLO: latency, error‑rate, éxito de checkout.

Segundo, 10–20 golden cases y un script de LLM‑eval. Un conjunto pequeño, pero bien escogido, de ejemplos por escenarios clave + casos de safety. Un script de CLI que los pase por la App y por el juez y devuelva valoraciones en JSON.

Tercero, un ritual sencillo cada 2 semanas. Sentarse (solo o con el equipo), abrir:

• 2–3 dashboards de SLO, costes y métricas de producto;
• el informe del LLM‑eval sobre los golden cases;

y elegir 1–2 hipótesis para el siguiente ciclo. Formularlas, documentarlas, hacer un release pequeño, verificar.

Versión 2.0: feedback loop «inteligente»

En el siguiente nivel aparecen:

Asistente de mejoras interno. Es un agente descrito aparte (o un ChatGPT App) que acepta un ImprovementInput y devuelve un ImprovementSuggestion. Os ayuda a no gastar horas en revisar diálogos a mano.

Informes automatizados. A partir de logs y evals se pueden generar:

• clusters de casos problemáticos (por ejemplo, todos los casos en los que el usuario reescribió el presupuesto);
• borradores listos para usar de cambios en prompts y descripciones de tools;
• un changelog corto.

Hooks de CI. Cualquier cambio en prompts, configs de agentes, descripciones de herramientas lanza automáticamente:

• la suite de golden cases funcional;
• la suite de safety.

Si los casos de safety fallan o la calidad de los escenarios clave deja de pasar los umbrales — la build está en rojo, no hay release.

9. Práctica

Ejercicio 1. Mini feedback loop para tu App

Toma un escenario clave de tu aplicación. Para GiftGenius ya hemos elegido «selección y compra de regalo», tú puedes tomar un escenario similar o uno propio.

Descríbelo en formato libre (o crea un pequeño improvement-plan.md):

Qué señales vas a seguir. Una por cada tipo:

• técnica: por ejemplo, p95 latency de la herramienta que hace el trabajo principal;
• económica: cost_per_task de ese escenario;
• de producto: conversión workflow_started → workflow_completed o hasta la acción objetivo;
• de calidad: quality_score medio en varios golden cases para ese escenario.

Luego fija qué umbrales consideras degradación. No «ya lo miraremos algún día», sino algo concreto:

• p95 > 5 segundos — mal;
• cost_per_task sube más de un 30 % sin crecimiento de ingresos — alerta;
• quality_score cae por debajo de 7 — hay que investigar.

Y formula la primera hipótesis. Por ejemplo:

«Sospecho que hacemos demasiadas preguntas aclaratorias. Si acortamos el wizard en un paso y hacemos las preguntas un poco más generales, la tasa de activación subirá y la helpfulness casi no se resentirá. Lo comprobaré con un pequeño cambio de UX y un experimento A/B».

Esto ya no es solo «mejorar el UX», sino un paso bastante concreto dentro del ciclo.

Ejercicio 2. Meta‑prompt para el asistente de mejoras

Intenta esbozar el texto del prompt para el agente interno de mejoras de tu App. Puedes empezar por algo simple:

• Describir quién es: «Tú eres el analista de calidad de la App N, que…».
• Enumerar qué entrada recibe: diálogos, señales, system‑prompt, descripciones.
• Formular las tareas:
  • encontrar 2–3 patrones de problemas;
  • proponer 1–2 cambios en el prompt, tools y textos de UX;
  • reunir un changelog corto.
• Describir el formato de respuesta: JSON estructurado con los campos patterns, suggestions, changelog.

Aunque de momento no vayas a invocar a este agente desde el código, un único prompt así ya te ayudará a estructurar mejor tus ideas sobre cómo mejoras la App.

10. Errores típicos al construir el ciclo de mejoras

Error n.º 1: optimizar solo para una métrica.
Centrarse en una sola cosa es muy tentador. Puedes perseguir solo el coste, alegrarte de que baje la factura de OpenAI — y no notar cómo el quality score, las conversiones y la retención empiezan a caer. El ciclo de mejoras debe mirar al conjunto de métricas: calidad ↔ dinero ↔ comportamiento de los usuarios.

Error n.º 2: cambios «mágicos» en el prompt sin mediciones.
La frase «he reescrito el system‑prompt, ahora debería ir mejor» sin golden cases y evals — es una forma de regalarte una sorpresa dentro de un par de semanas. Cualquier cambio del prompt — sobre todo en producción — debe pasar por un pipeline claro: conjunto de casos, LLM‑eval antes/después y, si hace falta, experimento online. Si no, no mejoras la App: dispersas la calidad en una dirección aleatoria.

Error n.º 3: auto‑deploy de cambios del asistente LLM.
Aunque el asistente de mejoras escriba fragmentos de prompt increíblemente bonitos y descripciones de herramientas muy convincentes, no es motivo para pushearlos a producción sin revisión. El modelo puede no ver todas las restricciones de negocio, los riesgos de safety, el contexto de vuestras métricas. Su rol es el de consultor, no el de DevOps con permiso de release.

Error n.º 4: falta de conexión entre cambios, hipótesis y señales.
A veces los equipos hacen cambios «por sensaciones» y no fijan qué señal llevó al cambio y qué hipótesis están comprobando. Como resultado, al mes nadie recuerda por qué apareció un párrafo extraño en el prompt ni para qué servía. Un buen PR por calidad debe responder como mínimo a tres preguntas: «¿qué dolía?», «¿qué cambiamos?» y «¿por qué métrica sabremos que ha mejorado?».

Error n.º 5: olvidarse de la safety al mejorar.
Persiguiendo la utilidad, es fácil aflojar las restricciones de safety, quitar del prompt «negativas innecesarias» u olvidarse de pasar los casos de safety. Cualquier cambio del system‑prompt, descripciones de tools y comportamiento del agente debe pasar primero por el conjunto de safety‑evals. Si un solo caso que antes pasaba ahora falla, — es señal de stop, por muy bonitas que se vean las demás métricas.

Error n.º 6: querer «optimizar todo a la vez».
Reescribir la mitad del prompt, cambiar el modelo, añadir otra tool de MCP y un wizard nuevo — todo en un mismo release — suena productivo, pero mata por completo la posibilidad de entender qué cambio dio el efecto. El ciclo de mejoras solo es eficaz cuando es iterativo y enfocado: una o dos hipótesis, un conjunto pequeño de cambios, un plan de rollback claro.

Error n.º 7: convertir el ciclo de mejoras en un raro «día de limpieza general».
Si cada medio año organizáis un gran «día de calidad» y el resto de meses vivís sin evals ni análisis de métricas, la App pasará la mayor parte del tiempo «a la deriva». Es mucho más útil un ritual pequeño pero regular: mirar señales cada semana/quince días, actualizar hipótesis y dar pequeños pasos. Así es como vuestro ChatGPT App deja de ser estático y empieza de verdad a auto‑mejorarse.