Q&A #25: Construir un loop real — destilar los principios que viven en tu cabeza y ponerle un verificador que lea como tu cliente

Resumen

Preparar la propuesta de una licitación tomó casi un día completo de pedir, revisar y corregir. El resultado quedó bien, pero la pregunta obvia era si había una mejor forma de hacer ese tipo de trabajo. La sesión reconstruye paso a paso lo que se hizo con esa pregunta: siete pasos, cero programación, y un loop que hoy entrega en treinta minutos desatendidos lo que antes costaba un día. El eje no es la automatización sino la destilación — las reglas que hacen buena a una propuesta vivían solo en la cabeza de quien la escribe y no estaban documentadas en ninguna parte, y el truco fue corregir en diálogo en vez de editar el documento a mano, para después pedirle al modelo que infiriera los principios detrás de cada corrección. Sobre esa base se monta la pieza más rentable del diseño: dos verificadores de naturaleza distinta, uno barato que revisa reglas duras y uno caro que lee el documento simulando ser la persona que va a decidir, con su historial y sus manías. El barato aprobó los 14 controles; el caro devolvió 18 objeciones, 10 estructurales — entre ellas una sola palabra que valía 1.700.000 pesos. Los números cierran el argumento y lo matizan: 71% de apego a los lineamientos sin principios ni loop, 88% con principios documentados pero sin loop, 100% con ambos. Los criterios escritos hacen la mayor parte del trabajo solos; el loop compra el último tramo. Y el dato más importante de toda la sesión es que ese salto no vino de un modelo mejor —lo ejecuta el mismo de hace un mes— sino del método.

Temas cubiertos

Qué es un loop, con precisión — Disparador, agente que genera, verificador con criterio comprobable, retorno con feedback y tope de gasto. Antes de pedirle al modelo que diseñe uno hay que transmitirle esa definición, o devuelve otra arquitectura
Siete pasos, cero programación — Hacer el trabajo a mano una vez, corregir en diálogo, destilar los principios, simular al cliente, pedirle que diseñe el loop, pedirle que construya la skill, y alimentarla. No hubo código: hubo diseño de proceso e instrucciones
Corregir en diálogo, no en el documento — Es la decisión metodológica que sostiene todo lo demás. Si uno edita el archivo a mano, la corrección se pierde y ya no hay nada que destilar. Pedida como instrucción, queda registrada y se convierte en principio
Los verificadores no son grados de la misma evaluación — El barato revisa persona gramatical, unidades consistentes, secciones obligatorias, palabras prohibidas. El caro pregunta si el precio se sostiene y si el documento defiende la promesa que hace. Atrapan errores de naturaleza distinta y hay que diseñar los dos
La palabra que valía 1.700.000 pesos — El agente simulando al cliente objetó “contra la comprobación hecha” porque hecha describe el acto de comprar, no el resultado. Lo detectó porque sabía que esa persona había recibido líneas de producción con protocolo de recepción firmado. Ninguna regla de estilo llega ahí
Por qué la autoevaluación genérica no sirve — Pedirle “dime qué mejorar” lo hace desde la generalidad y sin idea de quién decide. Además, un modelo siempre encuentra algo que sugerir: eso es un loop infinito disfrazado de mejora continua
Un loop sin tope no falla ruidosamente — El modelo no sabe cuántos tokens lleva consumidos, así que el freno se implementa como límite de ciclos. No busca afinar el costo: acota el peor caso, que es quedarse seis horas girando sobre un problema irresoluble sin avisar
71 → 88 → 100 — La lectura fina de la prueba: el salto de 71 a 88 vino solo de tener los principios escritos; el loop compra el tramo de 88 a 100. Si hay que elegir por dónde empezar, se empieza por documentar los principios
Skill o prompt — El prompt resuelve este caso; la skill obliga a limpiar lo particular y dejar el proceso genérico, reutilizable e invocable por comando. Y una skill ajena no se descarta ni se usa a ciegas: se le pide al modelo que la analice y la adapte al propio contexto
Diseñar con un modelo, ejecutar con otro — Fable para pensar la arquitectura y construir la skill, Opus para ejecutarla. La skill puede declarar con qué modelo corre; si no lo declara, toma el que esté por defecto en ese momento
Convención sobre configuración — Carpeta por cliente, carpeta por proyecto, carpeta de reuniones donde siempre cae la minuta. El valor no está en la estructura sino en respetarla: si el orden es predecible, el sistema encuentra el contexto sin que se lo entreguen
Obligar a leer la fuente original — Resumirle el correo uno mismo no es ayudarlo, es filtrarlo: se le quitan señales que habría usado para decidir mejor. Tres niveles distintos: darle acceso al correo, tener un procedimiento que lo lee, y pedirle que lea todos los correos de ese cliente antes de escribir
El documento de criterios vive fuera de la skill — La skill contiene el proceso y cambia poco; los criterios cambian siempre y la skill los lee antes de trabajar. El sistema evoluciona actualizando un documento, sin reprogramar el componente base
Cuando los principios chocan — “No seas categórico sin evidencia” volvió al modelo tan condicional que hedgeaba cosas que el cliente había confirmado en reunión. El documento de principios es un ente vivo: hay que sentarse a revisarlo periódicamente y destilarlo de nuevo
Ambigüedad: preguntar, no adivinar — El mismo precio aparecía distinto en tres archivos. El modelo levantó la alerta en vez de elegir uno o quedarse iterando. Ese comportamiento hay que instruirlo
El arbitraje del costo — El loop consume 1,6 a 2,6 veces un proceso lineal a cambio de 20-30 puntos de precisión. Media hora de máquina desatendida contra un día de trabajo humano — y lo que se libera no es solo tiempo total, sino presencia
El avance fue de método, no de tecnología — El mismo modelo de hace un mes. Lo que cambió fue la arquitectura del loop y poner de revisor al modelo emulando al cliente. Es replicable hoy, sin esperar la próxima versión de nada