Loop Engineering vs Prompt Engineering: La Verdad

Loop Engineering vs Prompt Engineering: La Verdad

Un amigo me envió un enlace la semana pasada con una sola línea adjunta: "la ingeniería de prompts está muerta." El artículo debajo argumentaba que la ingeniería de loops la había reemplazado — que escribir prompts ahora era una habilidad de principiante, y el verdadero juego era construir loops que ejecuten IA en piloto automático.

Leí todo dos veces. Luego abrí mi terminal, miré el loop que había construido dos semanas antes para optimizar un script de Python lento, y me di cuenta de que el artículo lo tenía exactamente al revés.

Esto es lo que casi nadie dice en voz alta sobre el debate loop engineering vs prompt engineering: un loop son prompts. Son prompts ejecutados una y otra vez, envueltos en estructura y una forma de verificar si funcionaron. Elimina el diseño del prompt y el loop no se vuelve más inteligente — se vuelve confiadamente, costosamente equivocado a escala. Así que si te preocupa haber perdido el memo y necesitas tirar todo lo que aprendiste sobre prompting, relájate. No es así. Pero sí necesitas una segunda habilidad apilada encima, y de eso se trata esto.

Voy a definir loop engineering correctamente, recorrer los cinco componentes que realmente hacen funcionar un loop (la mayoría de las explicaciones se detienen en cuatro y omiten el que salva tu billetera), mostrarte los cinco niveles de criterios de éxito que deciden si un loop siquiera vale la pena construir, y darte el camino exacto de cuatro pasos que uso para convertir un prompt único en un sistema que se mejora a sí mismo. Hay un ejemplo trabajado de artículo de LinkedIn con un problema genuinamente molesto incorporado, porque los ejemplos fáciles te mienten.

Déjame empezar eliminando el titular que inició todo esto.

¿Está la ingeniería de loops reemplazando a la ingeniería de prompts?

No. La ingeniería de loops no reemplaza a la ingeniería de prompts — se apila encima, porque un loop son simplemente prompts ejecutados repetidamente con andamiaje, criterios de éxito y una condición de parada. Mejores prompts hacen mejores loops; peores prompts hacen un loop que falla más rápido y cuesta más.

Esa es la versión de snippet destacado. Ahora la parte que importa.

Cuando escribes un solo prompt, estás optimizando una solicitud a un modelo. Tienes una oportunidad, lees la salida, ajustas. Cuando construyes un loop, estás optimizando el sistema que ejecuta ese prompt — lo que sucede entre las llamadas, cómo verifica su propio trabajo y cuándo decide parar. Esas son habilidades genuinamente diferentes. Pero no son sustitutos. Son capas.

Piénsalo mecánicamente. La fase de ejecución de cada loop es un prompt. Si ese prompt es vago, cada iteración hereda la vaguedad — y ahora estás pagando por diez iteraciones vagas en lugar de una. Hay una frase del discurso de ingeniería de loops de 2026 que se me quedó grabada: la ingeniería de prompts falla silenciosamente — obtienes una mala respuesta y sigues adelante — mientras que la ingeniería de loops falla ruidosa y costosamente si no has diseñado los modos de fallo tan cuidadosamente como la ruta de éxito. Un loop amplifica lo que le alimentas. Prompt basura, basura amplificada.

Así que las personas que declaran muerta la ingeniería de prompts son como alguien que declara la aritmética obsoleta porque descubrió las hojas de cálculo. La hoja de cálculo ejecuta la aritmética mil veces automáticamente. No te libera de entender lo que hace la aritmética. Si acaso, el apalancamiento hace que los fundamentos sean más importantes, porque los errores ahora se componen.

Retén ese pensamiento — "los loops amplifican" — porque es el hilo conductor de cada sección a continuación.

Lo que realmente significa la ingeniería de loops

La ingeniería de loops es construir loops que iteran prompts repetidamente, con andamiaje añadido y criterios de éxito explícitos, para que una tarea se complete automática y eficientemente sin que tengas que supervisar cada paso.

Eso es todo. La palabra "loop" está haciendo trabajo real aquí. No le estás pidiendo a la IA que haga algo una vez. Estás construyendo un ciclo: actúa, verificas si tuvo éxito, y si no, va de nuevo — armado con lo que aprendió del intento anterior. El arte está en el andamiaje alrededor de la acción, no en la acción misma.

Quiero ser preciso sobre la diferencia con algunas cosas con las que la gente lo confunde, porque el contraste aclara lo que es la ingeniería de loops.

Sistemas de "investigación automática" — los que salen y recopilan información hacia un objetivo — requieren criterios de éxito estrictos y bien definidos para funcionar. Apúntalos a un objetivo difuso y deambulan o se detienen arbitrariamente. La ingeniería de loops comparte esa exigencia de criterios claros pero va más allá: opera sobre un horizonte largo con mejora continua, no un único sprint de investigación.

La función tipo /goal en herramientas como Claude Code ejecuta una optimización de sesión única. Le das un objetivo verificable, trabaja hacia ese objetivo dentro de una sesión, y se detiene cuando el objetivo se cumple. Eso es un loop hermoso y bien delimitado — y lo uso constantemente — pero es un sprint. La verdadera ingeniería de loops es la versión maratón: persiste a través de sesiones, registra lo que sucedió, y usa esa historia para hacerlo mejor la próxima vez. La sesión única optimiza; el loop diseñado aprende.

Esa distinción — sesión versus horizonte largo, optimizar versus aprender — es donde la gestión de estado demuestra su valor. Llegaremos a eso.

Por ahora, el modelo mental: la ingeniería de prompts escribe la jugada. La ingeniería de loops construye la máquina que ejecuta la jugada, juzga el resultado, y decide si ejecutarla de nuevo. Si quieres la lección de anatomía más profunda sobre cómo están cableadas esas máquinas, desgloso la estructura trigger/acción/condición de parada en mi guía completa para diseñar loops de agentes — esta pieza es la capa estratégica por encima.

Los cinco componentes de un loop (no cuatro)

La mayoría de las explicaciones de ingeniería de loops te dan cuatro fases. Cuatro fases te darán un loop que funciona justo hasta que no se detiene. Así que te doy cinco, y la quinta es la que tatuaría en el dorso de la mano de cualquiera antes de dejar un loop corriendo sin supervisión.

Aquí está la anatomía completa.

Déjame darle a cada uno la atención que merece, porque la brecha entre un loop de juguete y un loop de producción reside enteramente en cuán seriamente los tratas.

Trigger: cómo el loop arranca sin ti

La fase de trigger es lo que hace que un loop sea un loop en lugar de un comando elegante que sigues re-ejecutando. Un horario cron que dispara a las 9:00 AM. Un webhook que dispara cuando se abre un pull request. Un observador de archivos que dispara cuando un CSV aterriza en una carpeta. El punto es que tú no eres el trigger. En el momento en que un humano tiene que iniciar manualmente cada ejecución, has construido una herramienta, no un loop autónomo — y eso está bien, pero sabe cuál estás construyendo.

La fase de trigger también es donde la mayoría de la gente accidentalmente introduce una dependencia de sí mismos. "Se ejecuta automáticamente — solo tengo que pegar los datos nuevos primero." Eso no es automático. Sé honesto al respecto desde el principio, porque un loop semi-automatizado tiene toda la superficie de fallo de la automatización y nada de la libertad.

Ejecución: donde vive la ingeniería de prompts

Este es el motor, y es un prompt. O más precisamente, en 2026 generalmente es un skill — una función reutilizable y nombrada que envuelve un prompt bien probado y un formato de salida definido. La fase de ejecución es exactamente donde el grupo de "la ingeniería de prompts está muerta" está más equivocado, porque esta fase es donde se gasta todo tu oficio de prompts. Un skill que "investiga noticias de IA y escribe un artículo" es un prompt con un título de trabajo.

Cuanto mejor diseñado esté este prompt, menos trabajo tiene que hacer cada otro componente. Un prompt de ejecución afilado produce salida consistente y estructurada, lo que hace la verificación trivial. Uno descuidado produce salida que varía enormemente de ejecución a ejecución, lo que hace la verificación una pesadilla y la gestión de estado casi sin sentido. Los loops recompensan el buen prompting y castigan el mal prompting — en volumen.

Verificación: el verdadero cuello de botella

Aquí hay una verdad que me tomó demasiado tiempo internalizar: el verificador, no el modelo, es el cuello de botella en cualquier loop. La habilidad central de la ingeniería de loops es escribir la cosa que decide si la salida es suficientemente buena para parar.

Si tu criterio de éxito es "¿bajó el tiempo de ejecución del script de Python por debajo de 200ms?" — felicidades, tu verificador es un cronómetro y una declaración if. Objetivo. Barato. Confiable. Si tu criterio de éxito es "¿es este artículo de LinkedIn mejor?" — ahora tu verificador tiene que responder una pregunta subjetiva, y los verificadores subjetivos son donde los loops van a morir. Dedicaremos una sección entera a esto porque es el predictor más importante de si tu loop funcionará.

Gestión de estado: la diferencia entre repetir y aprender

La gestión de estado es lo que separa un loop que hace lo mismo 100 veces de un loop que lo hace mejor la vez 100 que la primera. Registras la salida y el resultado de cada iteración — en una base de datos, un archivo de log, un archivo JSON, en cualquier lugar duradero — y alimentas esa historia de vuelta a la siguiente ejecución.

Sin estado, un loop es un pez dorado. Se despierta cada ciclo sin memoria, hace la misma llamada, obtiene el mismo resultado. Con estado, el prompt de ejecución puede decir: "Aquí están los últimos diez artículos que escribiste y cómo se desempeñó cada uno. Haz más de lo que funcionó." Eso es IA que se mejora a sí misma — no magia, solo memoria más una señal de retroalimentación. La gestión de estado es el componente poco glamuroso que hace que "auto-mejora" sea un mecanismo real en lugar de una palabra de moda.

Criterios de parada: el componente que salva tu dinero

Y aquí está el quinto, el que las explicaciones de cuatro fases omiten. Los criterios de parada deciden cuándo termina el loop. Dos formas limpias de terminar: el criterio de éxito se cumple, o se alcanza un límite duro de iteraciones — "intenta como máximo 8 veces, luego ríndete y dime."

¿Por qué es innegociable? Porque un loop sin condición de parada y una verificación de éxito ligeramente optimista es una máquina para convertir tu presupuesto de API en nada. He visto un loop con un criterio de éxito difuso decidir que "nunca estaba del todo listo" y moler iteración tras iteración, cada una llamando al modelo, cada una costando dinero, ninguna jamás satisfaciendo un objetivo que nunca fue verificable en primer lugar. El loop desbocado no es hipotético. Es el modo de fallo predeterminado contra el que tienes que diseñar.

Construye los criterios de parada primero, honestamente, antes de confiarle a un loop tus credenciales. Tu yo futuro, mirando la factura, estará agradecido.

Esos son los cinco. Ahora la pregunta que decide si deberías siquiera construir el loop.

La ingeniería de loops no es una talla única

Lo seductor de los loops es que se sienten universalmente aplicables. Cualquier cosa que hagas repetidamente, seguramente la puedes loopear. Pero los loops tienen un requisito duro que no toda tarea puede cumplir, y forzarlo lleva a los peores loops — los que parecen automatizados pero silenciosamente producen desviación.

El requisito es este: necesitas un criterio de éxito que el loop pueda realmente verificar.

Los loops brillan cuando el éxito es objetivo y medible. "Reduce el tiempo de ejecución de este script de Python" es el objetivo de loop perfecto. ¿Por qué? Porque el verificador es un benchmark. El loop ejecuta el script, lo cronometra, compara con la ejecución anterior, y sabe — sin ambigüedad alguna — si mejoró. Cada iteración produce un número, el número entra al estado, y el loop puede escalar el gradiente hacia "más rápido" sin preguntarle nada a un humano. Retroalimentación inmediata, objetiva, confiable. Eso es el paraíso de los loops.

Ahora contrástalo con: "escribe un artículo de LinkedIn de mejor calidad." ¿Cuál es el verificador? "¿Mejor" según quién? ¿La misma IA que lo escribió? Eso es un modelo calificando su propia tarea — y una instancia de modelo único sufre de sesgo de confirmación; felizmente calificará su propia salida con un 9 y pasará por alto lo que la hace mediocre. Hay trabajo publicado en 2026 sobre exactamente este sesgo de auto-atribución: los monitores de IA son indulgentes consigo mismos. Así que tu loop "mejora" el artículo cada ciclo según su propio criterio mientras un lector humano no ve diferencia, o peor, lo ve volverse más insípido mientras optimiza un proxy de calidad que realmente no puede medir.

Esta es la decisión central de juicio de la ingeniería de loops, y lo diré claramente: antes de construir un loop, pregúntate si puedes escribir un verificador en el que realmente confiarías. Si no puedes, el loop no es la respuesta — al menos no uno completamente autónomo. Para objetivos difusos tienes dos opciones honestas, y son el puente para hacer las tareas subjetivas loopables.

La primera es verificación con humano en el loop: el loop ejecuta, produce salida, y pausa para que un humano apruebe o rechace antes de contar la iteración como éxito. Más lento, pero el verificador es un humano real que puede juzgar calidad. La segunda es un juez de IA separado — un modelo hace el trabajo, un modelo diferente lo evalúa. La separación importa enormemente, porque rompe el problema de calificar tu propia tarea. El trabajador no puede ponerse su propia nota.

Incluso con un juez separado, mantente desconfiado. Una IA evaluando calidad subjetiva sigue siendo una IA, con sus propios sesgos sobre cómo se ve "bueno." Úsala para triaje y para sacar a la luz lo obviamente malo, pero para cualquier cosa de alto riesgo, mantén un punto de control humano. El objetivo no es eliminar humanos — es eliminar humanos de las decisiones aburridas y verificables y mantenerlos en las de juicio.

Si prefieres que alguien configure este tipo de flujo de trabajo con humano en el loop o basado en juez contigo en lugar de armarlo desde cero, acepto exactamente este tipo de proyectos — puedes ver lo que he construido en fiverr.com/s/EgxYmWD. Para todos los que lo construyen ustedes mismos, la siguiente sección es el framework que uso para llegar ahí.

El Viaje del Héroe: cuatro pasos hacia una solución con ingeniería de loops

No empiezas construyendo un loop. Ese es el error. Empiezas probando que la tarea es siquiera posible a mano, y te ganas tu camino hacia la automatización en cuatro pasos. Lo llamo el Viaje del Héroe porque cada paso es un level-up, y saltarte un nivel es cómo terminas con una forma automatizada de hacer lo incorrecto muy rápido.

Paso 1 — Ejecución manual: prueba que funciona a mano

Antes de cualquier loop, haz la tarea tú mismo, en el chat, prompteando a la IA manualmente. ¿Quieres un loop que convierta investigación de IA en artículos de LinkedIn? Primero, promptea a la IA para que lo haga una vez. Lee la salida. ¿Es realmente buena? ¿Puede un humano obtener confiablemente un buen resultado de un buen prompt?

Si no puedes obtener un buen resultado manualmente, no tienes motivo para automatizarlo cien veces. Este paso es la verificación de realidad. También es donde se forja tu ingeniería de prompts — cada refinamiento que haces aquí se convierte en la base sobre la que se sostiene todo el loop. No lo apresures.

Paso 2 — Codificar en un skill

Una vez que el prompt manual funciona confiablemente, encapsúlalo. Convierte el prompt-más-formato-de-salida en un skill nombrado y reutilizable — una función que puedes llamar en lugar de volver a escribir el prompt. Esto es codificación de skills, y es el momento en que tu acción única se convierte en un bloque de construcción.

Codificar obliga a la disciplina. Para hacer un skill, tienes que definir exactamente qué entra y exactamente qué sale. Esa estructura es precisamente en lo que se apoyarán los componentes de verificación y estado después. Un prompt vago resiste la codificación; uno afilado encaja limpiamente en un skill. (Si quieres la versión extendida de este paso, escribí un desglose completo de la construcción de skills de agente en Claude Code que continúa justo aquí.)

Paso 3 — Automatizar el skill

Ahora añade el trigger. Programa el skill, o conéctalo a un webhook, para que se ejecute sin ti. En este punto tienes automatización: el skill se dispara solo y produce salida. Nota lo que todavía no tienes — mejora. Un skill automatizado repite. No aprende. Es un pez dorado con un calendario.

Muchas automatizaciones valiosas se detienen justo aquí, y eso es legítimo. Si la tarea no se beneficia del aprendizaje — solo necesita hacerse confiablemente según un horario — el Paso 3 es tu línea de meta. No añadas un loop solo para sentirte sofisticado. Cuando construí mi primer loop real de principio a fin, la disciplina más difícil fue resistir el impulso de saltar directamente al Paso 4 antes de que la automatización del Paso 3 fuera siquiera estable.

Paso 4 — Añadir auto-mejora con ingeniería de loops

Aquí es donde se convierte en un verdadero loop. Defines los criterios de éxito, implementas seguimiento de estado — registra cada salida y su resultado — y construyes el mecanismo de retroalimentación que usa esa historia para hacer mejor la siguiente ejecución. Para el caso de LinkedIn, eso significa scrapear engagement, registrarlo, y alimentar "aquí está lo que funcionó bien antes" de vuelta al prompt de ejecución.

Este es el paso que convierte la automatización en IA que se mejora a sí misma. Y también es el paso donde todo lo que discutimos sobre verificación muerde: si tu criterio de éxito es difuso, el Paso 4 es donde el loop silenciosamente se descarrila. Así que llegas aquí habiendo ya decidido — honestamente — si la tarea puede soportar un verificador confiable. El Viaje carga esa decisión al principio a propósito.

Cuatro pasos. Manual, codificar, automatizar, mejorar. Cada uno un punto de control. Ahora déjame ejecutar un ejemplo real a través de esto, incluyendo la parte que el tutorial limpio de todos omite.

Un ejemplo trabajado: el loop de artículos de LinkedIn (y su problema feo)

Construyamos el loop que todos quieren — una IA que escribe y publica un artículo de LinkedIn cada día y mejora con el tiempo — y seamos honestos sobre por qué es más difícil de lo que sugieren las demos.

Aquí está el diseño, mapeado a los cinco componentes:

• Trigger: una ejecución programada diaria a las 9:00 AM.
• Ejecución: un skill que investiga las noticias de IA del día y escribe un artículo con mi voz.
• Verificación: éxito = número de likes que gana el artículo, scrapeados del post y registrados.
• Estado: una base de datos de cada artículo pasado y cómo se desempeñó, alimentada de vuelta para guiar al siguiente.

En papel, hermoso. El criterio de éxito es incluso numérico — los likes son un número, no un sentimiento. Pero ejecútalo y te topas con el problema que el ejemplo de Python nunca tiene: retraso temporal.

Cuando optimizo el tiempo de ejecución de un script de Python, la retroalimentación es instantánea. Ejecuta el script, obtén los milisegundos, sabe inmediatamente si la iteración N superó a la iteración N-1. El loop puede escalar rápido porque el verificador responde ahora.

El loop de LinkedIn no tiene ese lujo. El artículo se publica a las 9:00 AM. Los likes que te dicen si funcionó aún no existen. Gotean durante horas, a veces días. Así que la señal de verificación del artículo de hoy no está disponible cuando la ejecución de mañana se dispara. Tu loop quiere aprender de resultados que no han sucedido.

Esto rompe el loop único ingenuo, y la solución es dividir la línea temporal. Ejecutas un loop de scraping retrasado o paralelo — un ciclo separado cuyo único trabajo es revisitar artículos publicados 24 o 48 horas después, scrapear el engagement, y escribirlo en el estado. El loop de escritura se dispara diariamente; el loop de medición va detrás, llenando resultados retroactivamente. Solo una vez que un artículo ha "madurado" su rendimiento se convierte en señal de entrenamiento para artículos futuros.

Esa es la verdadera forma de un loop de contenido que se mejora a sí mismo, y es significativamente más complejo que el caso de Python. Los mismos cinco componentes, pero la maquinaria de verificación y estado tiene que considerar la brecha entre hacer y saber. La retroalimentación del loop de Python es inmediata y objetiva, así que es vastamente más fácil de automatizar de principio a fin. La retroalimentación del loop de LinkedIn es retrasada y ruidosa — los likes dependen del timing, la audiencia y la suerte tanto como de la calidad — así que incluso con un criterio numérico, estás luchando contra el retraso de señal y las variables de confusión.

La lección se generaliza: cuando diseñas un loop, mapea no solo si la señal de éxito es objetiva, sino si está disponible a tiempo para impulsar la siguiente iteración. Un criterio numérico que no puedes leer hasta la próxima semana sigue siendo un problema de verificación. Este es el tipo de detalle que separa un loop que funciona en una demo de uno que funciona en producción — y es exactamente la compensación que la mayoría de las guías de "construye una IA que publique por ti" omiten por completo.

Entonces, ¿cómo razonas sobre todo esto antes de construir? Clasificas tu criterio de éxito.

Los cinco niveles de verificación, clasificados

El destino de cada loop se decide por una cosa: cuán verificable es su criterio de éxito. Después de construir suficientes de estos, pienso en los criterios de éxito en una escala de cinco niveles, desde "loopea esto inmediatamente" hasta "no automatices esto completamente." Aquí está la escalera, de mejor a peor.

1. Determinístico / basado en reglas. La salida pasa una regla dura o no. Los tests pasan o fallan. El archivo compila o no. El JSON coincide con el esquema o se rechaza. Este es el estándar de oro — el verificador es código, es objetivo, es instantáneo, y no se puede discutir con él. Si tu tarea aterriza aquí, loopéala sin dudar.

2. Numérico / basado en métricas. El éxito es un número medible que quieres empujar en una dirección. Tiempo de ejecución en milisegundos. Likes. Tasa de conversión. Costo de tokens. Casi tan bueno como el nivel uno, si el número es confiable y disponible rápidamente. El loop de LinkedIn vive aquí — numérico, pero lastrado por el retraso temporal y el ruido que acabamos de cubrir.

3. Juez de IA separado. Sin regla limpia o número, así que un modelo diferente evalúa la salida contra una rúbrica. Usable para tareas semi-subjetivas, pero ahora estás confiando en el juicio de una IA sobre el trabajo de otra, y debes mantenerte alerta a los sesgos propios del juez. Bueno para filtrar y triaje, inestable para decisiones finales de alto riesgo.

4. Humano en el loop. El éxito es lo suficientemente subjetivo como para que una persona deba decidir. El loop ejecuta, luego pausa para aprobación humana antes de contar la iteración como éxito. Confiable, porque el verificador es un humano real — pero lento, y limita cuán autónomo puede ser el loop. Úsalo cuando la calidad genuinamente requiere juicio humano.

5. Difuso / subjetivo auto-calificado. "Hazlo mejor," juzgado por la misma IA que lo hizo. Este es el nivel más bajo y, honestamente, la zona de peligro. El modelo califica su propia tarea, el sesgo de confirmación se infiltra, y el loop optimiza un proxy que realmente no puede medir. Evita construir loops totalmente autónomos aquí. Si debes operar en este espacio, súbelo en la escalera — añade un punto de control humano (nivel 4) o al menos un juez separado (nivel 3).

La recomendación que surge de esto es simple. Apunta lo más alto posible en la escalera. Diseña tu tarea para que el éxito sea basado en reglas o numérico, incluso si eso significa redefinir el objetivo. ¿No puedes llegar ahí? Entonces no pretendas que un criterio de nivel cinco es suficiente — añade explícitamente validación humana o un evaluador separado, y nunca confíes únicamente en la misma IA para generar y juzgar calidad subjetiva. El nivel al que honestamente puedes llegar te dice no solo cómo construir el loop, sino si deberías construirlo autónomamente.

Esa única pregunta — "¿en qué nivel está mi criterio de éxito?" — te ahorrará más loops desperdiciados que cualquier otro consejo en este artículo.

Lo que esto significa para cómo deberías trabajar realmente

Da un paso atrás y la imagen es clara: el encuadre loop engineering vs prompt engineering es una falsa elección. Nunca fue uno reemplazando al otro. Es un stack.

La ingeniería de prompts es la base — la habilidad de obtener una buena salida de una buena solicitud. La ingeniería de loops es el piso construido encima — la habilidad de ejecutar esa salida repetidamente, juzgarla, recordarla y mejorarla, todo sin ti en la silla. Necesitas ambas. La persona que solo puede promptear está atrapada haciendo las cosas a mano. La persona que intenta loopear sin prompting sólido está automatizando el caos. La persona que puede hacer ambas construye sistemas que genuinamente se ejecutan solos y mejoran mientras duermen.

Y lo que más quiero que te lleves no es una técnica. Es un hábito de honestidad. Antes de construir cualquier loop, haz las preguntas incómodas: ¿Puedo escribir un verificador en el que realmente confiaría? ¿Es mi señal de éxito objetiva, y está disponible a tiempo para impulsar la siguiente iteración? ¿He construido una condición de parada real, o estoy a una verificación difusa de una factura desbocada? La mayoría de los loops fallidos fallan en esas preguntas, no en el código.

Si quieres aprender los fundamentos debajo de todo esto — prompting, skills e ingeniería de loops juntos, de la forma en que realmente encajan — preparé una masterclass de Claude Code que recorre exactamente esta progresión. Es el mismo Viaje del Héroe, enseñado de principio a fin.

Entonces, ¿está muerta la ingeniería de prompts? Ve a mirar la fase de ejecución del mejor loop que puedas imaginar. Sentado justo ahí, haciendo el trabajo real, hay un prompt. Nunca se fue a ningún lado. Solo le enseñamos a ejecutarse solo — y a recordar lo que pasó la última vez.

La verdadera pregunta nunca fue "loops o prompts." Es esta: de todas las cosas que haces una y otra vez, ¿cuáles tienen un criterio de éxito que genuinamente confiarías a una máquina para verificar? Responde eso honestamente, y sabrás exactamente qué tareas loopear — y cuáles todavía te necesitan.

Preguntas Frecuentes

¿Es la ingeniería de prompts obsoleta por la ingeniería de loops?

No. La ingeniería de loops no reemplaza la ingeniería de prompts — depende de ella. La fase de ejecución de un loop es un prompt ejecutado repetidamente, así que prompts débiles producen loops débiles a escala. Ambas son habilidades requeridas que se apilan en lugar de competir. Ve las secciones iniciales arriba para la explicación mecánica completa.

¿Cuál es la diferencia entre ingeniería de loops e ingeniería de prompts?

La ingeniería de prompts optimiza una solicitud única a un modelo; la ingeniería de loops optimiza el sistema que ejecuta ese prompt repetidamente — manejando triggers, verificación, estado y criterios de parada. Prompting escribe la jugada; la ingeniería de loops construye la máquina que ejecuta la jugada y juzga el resultado.

¿Cuándo no debería usar ingeniería de loops?

Evita loops completamente autónomos cuando el éxito es subjetivo y solo puede ser juzgado por la misma IA que produjo la salida, ya que eso invita al sesgo de confirmación e iteraciones desbocadas. Para objetivos difusos, añade un punto de control con humano en el loop o un juez de IA separado. Ve la escalera de verificación de cinco niveles arriba.

¿Cuáles son los componentes de un loop de agente de IA?

Un loop completo tiene cinco componentes: un trigger que lo inicia automáticamente, una fase de ejecución que hace el trabajo (generalmente a través de un skill), una fase de verificación que comprueba los criterios de éxito, gestión de estado que registra y aprende de los resultados, y criterios de parada que terminan el loop al éxito o después de un límite duro de iteraciones.

¿Cómo evito que un loop de IA se ejecute eternamente?

Define criterios de parada explícitos antes de ejecutarlo: termina cuando el criterio de éxito se cumple, y añade un límite duro de iteraciones como respaldo. Un loop con una verificación de éxito difusa y sin límite de iteraciones es la causa predeterminada de costos de API desbocados. Para la anatomía completa, ve mi guía para diseñar loops de agentes.

Trabajemos Juntos

¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudar.

• Fiverr (builds personalizados e integraciones): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (soluciones empresariales): ramlit.com
• ColorPark (diseño y branding): colorpark.io
• xCyberSecurity (servicios de seguridad): xcybersecurity.io