Cuando los humanos aún necesitaban sentarse frente al teclado y guiar paso a paso a los agentes, la capacidad fundamental era redactar prompts. Hoy en día, los agentes pueden recibir un objetivo y ejecutarse por sí solos; la nueva capacidad fundamental es la ingeniería de ciclos.

Autor del artículo: CyrilXBT

Artículo compilado, fuente: ME News

En junio de 2026, en una semana, tres personas llegaron independientemente a la misma conclusión.

El desarrollador de OpenClaw, Peter Steinberger, declaró públicamente que las personas deberían dejar de escribir directamente prompts para agentes de programación y en su lugar diseñar sistemas cíclicos que puedan emitir instrucciones automáticamente a los agentes.

Casi al mismo tiempo, Boris Cherny, responsable de Anthropic Claude Code, también indicó que ya no ingresa directamente prompts en Claude. Ahora, ejecuta un conjunto de bucles que llaman automáticamente a Claude y determinan el siguiente paso a tomar, y su verdadero trabajo consiste en escribir y diseñar estos bucles.

Pocos días después, el ingeniero de Google Addy Osmani realizó un resumen sistemático de esta práctica y le dio un nombre:

Loop Engineering, ingeniería cíclica.

No crearon este modo de trabajo de la nada, sino que le dieron nombre a un cambio que ya estaba ocurriendo silenciosamente.

Antes de esto, las herramientas subyacentes ya habían cruzado un punto crítico: los agentes de programación comenzaron a poder completar tareas reales sin supervisión; el costo de la programación automática se redujo lo suficiente como para que ejecutar repetidamente una tarea en horarios programados ya no pareciera un desperdicio; el costo de una sola ejecución del agente también descendió a un nuevo nivel: en lugar de dedicar mucho tiempo a pensar cuidadosamente una sola vez, es posible que intentar cinco veces con el agente resulte incluso más económico.

This is exactly why this roadmap exists.

Cuando los humanos aún necesitaban sentarse frente al teclado y guiar paso a paso a los agentes, la capacidad fundamental era redactar prompts. Hoy en día, los agentes pueden recibir un objetivo y ejecutarse por sí solos; la nueva capacidad fundamental es la ingeniería de ciclos.

A continuación se presenta una ruta completa de 20 pasos para pasar de un operador de prompts a un diseñador de sistemas. Debe avanzarse en orden, ya que en esta ruta, la secuencia entre los pasos suele ser más importante que cualquier paso individual.

La ingeniería de ciclos no es una habilidad única que se posea o no, sino una pila de capacidades apiladas. Cada nivel depende de si la base inferior es lo suficientemente sólida.

Por ejemplo, construir el disparador de programación automática en el paso 14 antes de establecer las condiciones reales de parada en el paso 10 solo resultará en un sistema que puede desperdiciar fondos automáticamente sin supervisión. Antes, al menos solo desperdiciaba recursos mientras tú estabas mirando la pantalla; ahora puede seguir quemando dinero por sí solo.

De igual manera, si estableces la capa de memoria persistente en el paso 11 antes de completar los mecanismos de verificación confiables en los pasos 6 y 7, podrías almacenar cuidadosamente la experiencia resumida por un “revisor” demasiado permisivo que constantemente permite resultados erróneos.

Esto no solo no ayudará al sistema a progresar, sino que también permitirá que se acumulen experiencias erróneas, convirtiendo la capa de memoria de “temporalmente inútil” en “activamente dañina”.

Por lo tanto, omitir ciertos pasos no solo significa no implementar una función. El problema más grave es que estás construyendo capacidades avanzadas que parecen emocionantes sobre una base que no puede sostenerlas, y a menudo solo te das cuenta del problema cuando el sistema ya está operando a escala y ha generado consecuencias reales.

El primer paso real no implica ninguna tecnología.

Debes reconocer que, en el flujo de trabajo actual, los factores que limitan la eficiencia ya no suelen ser la capacidad del modelo, sino que tú aún te mantienes atrapado en el ciclo.

Cada vez que te sientas frente a la computadora esperando la respuesta del modelo, lees los resultados y luego ingresas la siguiente instrucción, te conviertes en el eslabón más lento de todo el sistema.

El modelo puede ejecutar, validar y reintentar, y estas operaciones son mucho más rápidas que la supervisión humana paso a paso para completar la tarea.

Este paso no tiene una instrucción correspondiente; es una decisión cognitiva.

Antes de aceptar realmente esto, todos los pasos siguientes parecerán trabajo adicional innecesario, en lugar de su verdadero propósito: eliminar el cuello de botella de eficiencia más grande del sistema.

Cuando el modelo produce un resultado incorrecto, la reacción más natural de las personas suele ser agregar una nueva regla al prompt original.

Meses después, esta práctica creará un muro de reglas: denso, contradictorio y tan largo que el modelo no podrá procesar simultáneamente todos los requisitos en su memoria de trabajo.

Finalmente, los modelos suelen realizar coincidencias de patrones solo con los contenidos más recientes o más destacados, ignorando inadvertidamente otras reglas.

La ingeniería cíclica ha transformado por completo este enfoque.

Cuando surja un problema, ya no solo agregas una nueva solicitud a la indicación, sino que añades un nuevo componente al sistema, por ejemplo:

• Añadir un paso de verificación independiente;
• Añadir un archivo de memoria;
• Añadir un disparador programado;
• Añada una etapa de revisión estructurada.

As the capabilities of external systems continue to improve, prompts themselves should become shorter, not longer.

Independientemente del ámbito específico de la tarea, cada ejecución en el bucle puede descomponerse en cinco acciones básicas:

Identificación, transferencia, verificación, persistencia, programación.

Descubrimiento

Figure out what the actual task needs to be accomplished.

Entrega

Assign the task to the model, agent, or tool responsible for execution.

Verificación

Verifique si los resultados son correctos según los estándares reales.

Persistencia

Registra qué ocurrió durante esta ejecución y qué aprendiste, para evitar perder esta experiencia en la próxima ejecución.

Programación

Decide cuándo volverá a ejecutarse este proceso.

El flujo de trabajo actual de la mayoría de las personas solo incluye explícitamente las dos primeras acciones: identificar la tarea y transferir la tarea, y generalmente se realizan manualmente en la ventana de chat.

Los otros tres movimientos o bien no existen en absoluto, o bien están ocultos en el cerebro humano mismo.

El núcleo del ciclo de ingeniería es hacer explícitos estos cinco pasos y automatizarlos tanto como sea posible.

Antes de comenzar a construir el sistema, elige una tarea que ya estés realizando repetidamente y que puedas describir claramente en términos de estándares de calidad.

No elijas el problema más difícil ni tareas innovadoras sin precedentes.

La primera tarea candidata debe cumplir tres condiciones:

1. Necesitas ejecutarlo repetidamente;
2. Tiene estándares claros que se pueden escribir;
3. Tiene un estado de "completado" fácil de identificar.

En otras palabras, un colega que vea los resultados debería poder determinar rápidamente si la tarea se completó correctamente.

Esta restricción es más importante de lo que parece a primera vista.

Si una tarea no tiene un criterio claro de finalización, no se puede establecer un verdadero proceso de verificación. Y un ciclo sin un mecanismo de verificación confiable no es un verdadero ciclo, sino solo una suposición sin supervisión.

Este es el paso que la mayoría de las personas tienden a omitir, pero que es clave para determinar si el sistema funcionará correctamente posteriormente.

Antes de escribir cualquier instrucción para el agente, primero escribe en un lenguaje claro y natural: ¿cómo debería ser un resultado correcto?

Necesitas estándares específicos y verificables, no juicios de calidad vagos como “se siente bien” o “parece profesional”.

Puede utilizar la siguiente plantilla:

Nombre de la tarea: [Nombre de la tarea]

Definición completada (Definition of Done, DoD):

• [Estándar específico y verificable 1]
• [Estándar específico y verificable 2]
• [Estándar específico y verificable 3]

Aunque la salida final parezca completa y cuidadosamente pulida, la tarea no se considerará completada si falta alguno de los elementos anteriores.

Si no puedes completar esta plantilla para la tarea seleccionada actualmente, debes volver al paso 4 y elegir una tarea más adecuada para construir un ciclo.

Esta es la decisión arquitectónica más importante en todos los sistemas cíclicos.

The role responsible for generating results must be separated from the role responsible for reviewing results.

La razón es que, cuando el modelo revisa inmediatamente su propia salida tras generar un contenido, tiende a defender la respuesta que acaba de producir en lugar de examinar críticamente los problemas que contiene.

En un ciclo razonable, deben existir al menos dos roles independientes:

Constructor

Los constructores tienen cierto margen de creación y son responsables de generar la versión inicial.

Juez

El revisor recibe la salida del constructor y la definición de terminación establecida en el paso 5, y evalúa si el resultado cumple con estos criterios.

Idealmente, el revisor también debería poder acceder a evidencia independiente que el constructor no puede acceder, por ejemplo:

• Conjunto de pruebas;
• Materiales originales;
• Datos en tiempo real;
• Base de datos de autoridad;
• Original task brief.

De esta manera, el jurado puede basar su juicio en evidencia real, en lugar de generar nuevamente una opinión subjetiva con el mismo razonamiento que el creador.

Si el revisor solo puede ver la salida del constructor, solo puede evaluar si el resultado "parece coherente".

No puede determinar si el resultado es realmente correcto.

Por lo tanto, el revisor debe poseer una base objetiva verificable, es decir, Ground Truth. Según el contexto específico, puede interpretarse como "hecho de referencia", "datos reales" o "fuente autorizada".

Para diferentes tareas, los criterios objetivos también varían.

Tarea de programación

The objective basis is the test suite and the output results after the code runs in practice.

Tarea de producción de contenido

La base objetiva son los materiales y resúmenes originales. Los revisores deben comparar lado a lado los materiales originales con el borrador generado.

Tarea de investigación

The objective basis is the original file, paper, dataset, or authoritative source explicitly required for use in the task.

Si no puedes especificar claramente en qué se debe basar el revisor para realizar la verificación, entonces tu ciclo aún no tiene un mecanismo de validación real, independientemente de cuán segura suene la redacción del revisor.

La salida del constructor y las conclusiones del revisor deben seguir una estructura claramente definida, no solo lenguaje natural fluido.

De lo contrario, el siguiente gestor no tendrá información estable y confiable para tomar decisiones y enrutar.

Los constructores pueden utilizar el siguiente formato de salida:

Salida del constructor:

• Contenido final entregado;
• Level of confidence in the result;
• Known uncertainty.

El revisor puede utilizar el siguiente formato de salida:

Conclusión de la revisión:

• PASS: aprobado;
• FAIL: fracaso;
• NEEDS REVISION: necesita revisión;
• Problemas específicos encontrados;
• Los criterios objetivos o evidencia original en los que se basa esta revisión.

Antes de conectar la programación automática y los reintentos automáticos, ejecute manualmente una vez el flujo completo de "Constructor—Revisor".

Lee cuidadosamente el juicio proporcionado por el revisor y pregúntate:

• ¿Estás de acuerdo con su conclusión?
• ¿Ha dejado pasar algún resultado que sabías que estaba mal?
• Did it incorrectly negate a result that was originally qualified?

Si el revisor aprueba un resultado que sabes que es incorrecto, o rechaza un resultado que en realidad no tiene problemas, debes primero corregir los criterios objetivos o completar los estándares, y luego continuar construyendo el sistema.

Automatizar un paso de validación incorrecto solo hará que el sistema produzca resultados erróneos más rápidamente.

Para hacer más específicos los cinco pasos anteriores, podemos observar una tarea común: convertir una fuente original en un artículo completo.

Paso 5: Definir el final

El criterio de finalización de esta tarea puede ser:

• Cada hecho en el borrador puede rastrearse hasta un contenido explícito en la fuente original;
• El borrador cumple con todos los requisitos específicos del boletín, incluyendo extensión, tono y estructura;
• El argumento central del texto se mantiene claramente sin ser diluido por contenido innecesario.

Paso 6: El constructor genera un borrador

El creador recibe los materiales originales y el brief de contenido para generar una versión preliminar.

Al mismo tiempo, también debe enumerar claramente las incertidumbres existentes durante el proceso de escritura, por ejemplo:

• Si un número específico realmente aparece en la fuente original;
• ¿La conclusión está expresada explícitamente en el texto original o es inferida por el modelo?
• Whether a fact lacks sufficient sources.

Paso 7: El revisor compara con el texto original

Los revisores reciben simultáneamente el borrador y los materiales originales, en lugar de recibir solo el borrador.

Debe verificar por separado los tres criterios definidos y proporcionar una conclusión de aprobado o reprobado para cada criterio individual, en lugar de comprimir todas las dimensiones en una puntuación global ambigua.

Combinar tres estándares diferentes en una sola evaluación general oculta cuál de las dimensiones específicas está presentando problemas. Esta es la causa más común por la que muchos ciclos que originalmente funcionaban pierden progresivamente su valor de retroalimentación.

Paso 8: Entrega estructurada

La conclusión del revisor debe ser un objeto estructurado, no un párrafo de lenguaje natural con reservas.

Debe generar tres resultados claros de aprobación o rechazo, y proporcionar razones específicas para cada fallo.

Paso 9: Verificación manual del mecanismo de revisión

Ejecutar manualmente un proceso completo antes de que el sistema se ejecute automáticamente puede ayudarte a determinar si los revisores son demasiado laxos o demasiado estrictos.

Revisores demasiado laxos podrían pasar por alto los datos ficticios simplemente porque el artículo está bien redactado.

Un revisor demasiado estricto podría rechazar incorrectamente un artículo adecuado debido a una preferencia personal de estilo que nunca se incluyó en el informe.

Estos dos problemas son muy comunes al configurar por primera vez.

Encontrarlos después de que el sistema haya funcionado sin supervisión 50 veces es mucho más costoso que resolverlos durante la primera prueba manual.

El administrador (Manager) se encarga de leer los juicios de los revisores y decidir la siguiente acción.

Las condiciones de cierre también deben estar presentes en el gestor y deben escribirse como lógica dura y explícita, no como una instrucción flexible que el modelo pueda eludir mediante autointerpretación.

Por ejemplo:

Condición de detención:

• Número máximo de modificaciones: 3;
• Cuando la tercera revisión aún falla, envíe el historial completo para su manejo humano y no inicie una cuarta modificación;
• Criterios de calidad: Cada ítem definido debe mostrar PASS;
• Límite de presupuesto: Si el costo de la tarea supera X o el tiempo de ejecución supera Y, debe detenerse inmediatamente, independientemente del estado actual.

Un bucle sin una condición de detención real no es un sistema, sino una responsabilidad que espera exponer riesgos.

¿Por qué las instrucciones suaves como "detenerse cuando el resultado sea lo suficientemente bueno" no son confiables?

Porque es solo una sugerencia.

Cuando el modelo ha sido modificado repetidamente sin aprobarse, para proporcionar un final que parezca satisfactorio, es probable que se convenza a sí mismo de que "esta versión ya está lo suficientemente cerca del estándar" y reduzca automáticamente sus criterios de evaluación.

In contrast, this issue does not arise with iterations mechanically checked by code or explicit rules that the manager cannot circumvent through reasoning.

Si un ciclo comienza desde cero cada vez que se inicia, no recordará lo aprendido en la ejecución anterior.

Por lo tanto, se necesita agregar una capa de persistencia sencilla.

Puedes crear un archivo para cada nueva experiencia real y resumirlo en una frase en la parte superior del archivo:

• ¿Qué aprendiste?
• What was fixed;
• Why is this experience important?

El principio clave es: solo registrar conocimientos nuevos que aún no se hayan guardado en otro lugar.

La memoria repetitiva no es conocimiento, sino ruido.

Para que el mecanismo de persistencia sea efectivo a largo plazo, se debe mantener la moderación al escribir.

Es fácil tener el impulso de registrar todos los detalles de ejecución, pero esto solo reproduce el problema de “prompts hinchados” mencionado en el paso 2, solo que esta vez, lo que se infla es la carpeta de memoria.

Las experiencias verdaderamente dignas de registrarse son aquellas que, una vez olvidadas, requieren mucho tiempo para volver a descubrir, no simplemente un registro ordinario de un funcionamiento que se desarrolló según lo esperado.

Solo aumentar el mecanismo de persistencia también generará problemas similares a los de las indicaciones extremadamente largas.

Con el tiempo, el sistema acumula decenas de archivos, muchos de los cuales solo contienen ligeras variaciones de la misma pregunta.

Por lo tanto, los archivos de memoria deben organizarse según un ciclo fijo. Realizarlo una vez por semana suele ser una frecuencia razonable.

El proceso de organización incluye:

• Revisar la memoria existente;
• Combinar contenido duplicado;
• Comprime múltiples experiencias similares en un principio más claro;
• Delete content that has been proven incorrect or outdated.

El objetivo no es acumular cada vez más archivos, sino obtener un menor número de conocimientos con mayor densidad de información.

Muchas personas omitirán completamente este paso, ya que no brinda nuevas capacidades visibles de inmediato, sino que solo previene problemas futuros.

Precisamente porque carece de retroalimentación inmediata, debe incluirse explícitamente en la programación, en lugar de esperar hasta que alguien descubra que la carpeta de memoria ya es difícil de gestionar.

En la realidad, estas tareas de “reorganizarlo más tarde” normalmente nunca ocurren, hasta que el rendimiento del sistema ya ha comenzado a disminuir debido a la gran cantidad de memorias contradictorias, obsoletas y parcialmente relacionadas compitiendo por el contexto.

Al comenzar cada nueva tarea, haz que el bucle primero escanee un resumen de una oración del archivo de memoria para determinar qué experiencias son realmente relevantes para la tarea actual y solo cargue esos contenidos relacionados.

Al mismo tiempo, se debe exigir claramente al sistema: si no hay ningún contenido en la memoria actual que sea aplicable a la tarea actual, indicar directamente que no hay experiencia aplicable.

No intentes aplicar experiencias pasadas a un nuevo problema completamente diferente solo porque existe un sistema de memoria.

A continuación, se debe determinar cuándo este ciclo se ejecutará automáticamente sin inicio manual.

Las formas de activación pueden incluir:

• Tarea programada Cron;
• Monitor de cambios de archivo;
• Disparador de ciclo basado en calendario;
• Se activa cuando ocurre un cambio en un evento o estado externo.

Este paso transformará un sistema que solo puedes iniciar manualmente en uno que puede seguir funcionando mientras duermes.

Ironically, this is usually the easiest step on the entire list, yet it’s also the one many people delay even after completing the other components.

Fase 4: Escalar y fortalecer la confiabilidad Paso 15: Someterlo a pruebas de estrés antes de entrar en el ciclo de confianza real

Antes de utilizar el bucle en cualquier tarea importante, es necesario probar activamente contra cuatro modos de fallo.

Prueba uno: Tarea imposible

Proporcione al sistema una versión de tarea verdaderamente irresoluble para confirmar que el administrador puede salir según las condiciones de detención, en lugar de entrar en un bucle infinito.

Si un ciclo solo ha sido probado en tareas que pueden completarse con éxito, nunca ha demostrado su capacidad para fallar con elegancia.

Prueba dos: resultado que parece razonable pero es incorrecto en realidad

Proporcione al revisor una salida que usted sepa con certeza contiene errores sutiles.

Este resultado debe leerse de forma muy fluida, pero contiene un error factual o lógico que insertaste intencionadamente.

Observe si el revisor puede identificar problemas, en lugar de aprobarlo simplemente porque el contenido suena razonable.

Prueba 3: Los constructores y revisores comparten cegueras del modelo

Si el constructor y el revisor utilizan el mismo modelo subyacente, se puede introducir deliberadamente un error típico que dicho modelo comete con frecuencia, para observar si el revisor lo pasa por alto.

Si el revisor y el constructor tienen las mismas ciegas, entonces la separación de roles diseñada en el paso 6 pierde su sentido.

Prueba 4: Calcular el costo de operación en el peor de los casos

Calculate the cost of this loop under the worst-case scenario, using the most expensive model invocation, the maximum number of modifications, and the longest output within reasonable limits.

Luego pregúntate sinceramente:

¿Te sentirías inquieto si este número apareciera en una factura real?

Completar estas cuatro pruebas antes de procesar tareas importantes en el ciclo de confianza permite detectar la mayoría de los problemas potenciales con anticipación.

De lo contrario, estos problemas es probable que aparezcan por primera vez ante los clientes o los gerentes, o se reflejen directamente en tu factura, en lugar de surgir durante una prueba que tú hayas controlado activamente.

Cuando el ciclo funcione de manera estable, no permitas que todos los personajes utilicen el mismo modelo que más te gusta.

Los diferentes roles dentro del ciclo tienen distintos requisitos para las capacidades del modelo.

Constructores

Los constructores generalmente deberían utilizar el modelo más potente.

Porque asume la mayor parte del razonamiento complejo y la generación de contenido. Si se utiliza un modelo con capacidad insuficiente aquí, la calidad del resultado de la primera versión disminuirá, y podrían ser necesarias más rondas de modificaciones posteriores.

Finalmente, el costo de corregir un borrador de baja calidad puede ser mayor que el costo de usar un modelo más potente desde el principio.

Revisor

El revisor es responsable de realizar inspecciones según criterios claros, generalmente sin necesidad de una gran capacidad creativa.

Cuando los criterios son lo suficientemente específicos, un modelo más pequeño, de menor costo y más rápido también puede realizar tareas de revisión de manera confiable.

Un modelo pequeño, si funciona según una lista de verificación extremadamente clara, puede tener una estabilidad cercana a la de un modelo grande, pero con costos y latencia significativamente más bajos.

Administrador

El gestor simplemente enruta según reglas ya definidas y casi nunca necesita utilizar el modelo más costoso.

Su tarea es ejecutar lógica previamente definida, no realizar razonamiento abierto.

Además, independientemente del rendimiento del constructor y del revisor, el administrador se ejecuta al menos una vez en cada iteración, por lo que su costo por llamada individual merece especial atención.

La configuración de capas adecuada suele ser:

• El modelo fuerte se encarga de construir;
• Los modelos económicos y estables se encargan de las revisiones habituales;
• Los modelos o programas de reglas de bajo costo se encargan del enrutamiento y la gestión.

La optimización de costos significativa en el sistema de bucle proviene típicamente de este ajuste de roles del modelo.

Mucha gente cree que controlar los costos significa reducir el número de ciclos o revisiones. En realidad, un método más eficaz es ajustar el costo del modelo a la dificultad real de cada rol dentro del ciclo.

Después del primer ciclo exitoso, es fácil intentar inmediatamente construir múltiples ciclos simultáneamente y procesar cinco tareas diferentes en paralelo.

Aunque la arquitectura actual ya puede admitir esta expansión, se debe contener este impulso.

Debes dejar que el primer ciclo funcione de manera estable durante suficiente tiempo hasta que realmente ya no necesites revisar cada una de sus salidas.

No se trata de que una demostración en la que todos estaban atentos tuviera éxito por casualidad, sino de que, tras un período de funcionamiento real, sigue pasando revisiones manuales de forma continua.

Solo se debe comenzar a construir el segundo ciclo una vez alcanzado este estado.

El segundo ciclo debería manejar una tarea claramente diferente de la primera.

Solo así se puede verificar si la arquitectura subyacente tiene verdadera generalidad, y no solo una optimización cada vez más fina para la misma tarea.

Después de ejecutar múltiples ciclos simultáneamente, es necesario establecer una vista de monitoreo unificada para rastrear centralmente los costos de todos los ciclos y los casos en que se activaron las condiciones de detención, en lugar de revisar cada ciclo por separado.

Por sí sola, un presupuesto de tareas cíclicas puede ser completamente razonable.

Pero si las diez secuencias de ciclos operan cada una dentro de su presupuesto, su costo total aún podría alcanzar un nivel sorprendente.

Debido a que los datos individuales de cada ciclo parecen normales, este riesgo a menudo no se detecta hasta que aparece la factura consolidada.

Además de las tareas completadas con éxito, se debe registrar específicamente cada activación de las condiciones de parada.

Si un ciclo toca frecuentemente el número máximo de modificaciones, mientras que otros ciclos rara vez presentan esta situación, la señal que transmite podría no ser "esta tarea es particularmente difícil", sino:

• Los criterios de evaluación no están configurados correctamente;
• Los revisores son demasiado estrictos, lo que hace que ningún resultado pueda aprobarse;
• El sistema verificó los fundamentos objetivos incorrectos;
• Completar la definición en sí presenta problemas.

Si solo se rastrean los resultados exitosos y cada actualización manual se considera un evento fortuito independiente, este patrón a nivel de diseño no se detectará.

La señal más clara de que el cambio de mentalidad se ha completado realmente es que los indicadores a los que prestas atención diariamente han cambiado.

El operador de prompts se preocupa por:

• ¿Cuántas instrucciones válidas se escribieron hoy?
• ¿Qué instrucción funciona mejor?
• ¿Cómo redactar los prompts de manera más sofisticada?

Los diseñadores del sistema se preocupan por:

• ¿Cuántos ciclos están actualmente en ejecución?
• ¿Qué tan confiable es cada ciclo?
• ¿Cuánto tiempo se ha liberado el sistema?
• ¿Qué trabajos ya no requieren supervisión humana?

Si aún mides tu productividad por la cantidad de prompts que ingresas, entonces el cambio de mentalidad requerido en el paso 1 aún no se ha completado realmente.

El último paso ya no se trata completamente de tu propio sistema.

It is used to verify whether you truly understand this method.

Necesitas intentar explicarle a otra persona cinco acciones básicas sin depender de términos complejos:

Identificación, transferencia, verificación, persistencia, programación.

Si puedes guiar a otra persona para que construya su primer ciclo solo con estos cinco movimientos y los pasos anteriores, significa que ya has logrado la verdadera transformación descrita en esta hoja de ruta.

Ya no eres la persona que permanece dentro del bucle, ingresando continuamente la siguiente instrucción.

Te convertiste en la persona que está fuera del ciclo, diseñando el sistema y observándolo funcionar por sí solo.

Cuatro costos que se acumulan silenciosamente tras omitir los pasos

Al final del artículo, es necesario incluir una advertencia.

Saltar los pasos en este mapa de ruta rara vez causa un colapso del sistema inmediato.

Su fracaso suele ser silencioso, e incluso difícil de detectar durante mucho tiempo, hasta que el problema se ha acumulado hasta un grado considerable.

Cuando omites los pasos 6 y 7, no estableces revisores verdaderamente independientes y no proporcionas una base objetiva confiable, la validación de la deuda comienza a acumularse.

El bucle sigue pareciendo funcionar normalmente, ya que los resultados generados "parecen bastante bien".

Solo te darás cuenta de que el sistema nunca ha evaluado realmente si los resultados eran correctos, hasta que un error se acumule durante decenas de ejecuciones y finalmente sea descubierto.

Cuando omites el paso 20, puede producirse degradación de la comprensión.

Aún estás ejecutando el bucle que construiste anteriormente, pero ya no puedes explicar claramente por qué existe cada componente ni diagnosticar eficazmente cuando el sistema falla.

La razón es que nunca has internalizado realmente la lógica detrás de esta arquitectura.

La rendición cognitiva ocurre si el paso 1 nunca se completa realmente.

Aunque el sistema de verificación ha demostrado su confiabilidad a través de un funcionamiento prolongado, aún revisarás manualmente cada salida por hábito.

Este comportamiento parece cauteloso, pero en realidad anula todo el propósito de construir el sistema.

Si se omite el paso 10 y no se establece una condición de detención real para el bucle, puede producirse un descontrol en el consumo de tokens y los costos de llamada.

A menudo no te das cuenta del problema cuando el sistema comienza a descontrolarse, sino hasta que aparece la factura final y descubres que el ciclo ha realizado una gran cantidad de llamadas inválidas.

Todos los costos anteriores se pueden evitar.

La forma de evitarlas es siempre la misma disciplina:

Construye en orden, no saltes los pasos que parezcan menos impresionantes.

Lo que realmente funciona suele ser precisamente la parte más aburrida:

• Definición clara y completa;
• Condiciones de parada confiables;
• Criterios objetivos verificables;
• Independent review mechanism.

En comparación, las partes que suenan más atractivas—los prompts ingeniosos, los diagramas de arquitectura complejos—son mucho menos importantes de lo que la gente cree.

Lo que realmente determina la calidad del sistema es si el sistema que has construido sabe:

• ¿Cuándo uno tiene razón?
• Cuándo uno está equivocado;
• Cuándo se debe detener.

That is the entire difference between a prompt operator and a system designer.

La diferencia no radica en quién es más inteligente ni en quién puede escribir prompts más elaborados.

La verdadera diferencia es si tienes suficiente disciplina para construir cuidadosamente las partes aburridas y fáciles de omitir, pero que realmente determinan la confiabilidad del sistema.