Freider TorresFreiderTorres

Antes de cambiar un prompt o un modelo, leo respuestas reales y anoto dónde fallan. Una métrica general avisa de que algo va mal; un fallo leído dice qué arreglar.

Si los pasos se conocen, los escribo en código. El modelo entra solo donde las reglas se rompen, y un agente solo donde el camino no se puede prever. Cada capa extra tiene que justificar su costo.

Cada respuesta del modelo llega con una forma definida y se valida antes de tocar nada. Lo que no cuadra se rechaza y queda registrado: un sistema que adivina en silencio es peor que uno que falla a la vista.

Un cambio de prompt, de modelo o de datos se prueba contra casos reales antes de salir. Una comparación pequeña alcanza para decidir, no para dar la pregunta por cerrada, así que la regla a la que apunto es un conjunto de casos que crezca con el sistema y contra el que corra cada cambio. Donde todavía no hay casos, una persona aprueba cada salida. El código que escriben mis agentes pasa por los mismos controles y por mi revisión.