Ejecuté 1,000 agentes de IA usando 6 pasos, 5 prompts y 1 archivo (Guía para desarrolladores)

La Prompting murió en 2024. La nueva habilidad es la Orquestación

Gestioné 1000 Agentes de IA durante 30 días y esto es lo que descubrí

La habilidad que reemplazó a la prompting, y los sistemas que puedes ejecutar hoy.

Deja de optimizar tu prompt. Ya no es el cuello de botella.

Con un agente en una ventana de chat, el prompt es casi todo el juego.

Con diez agentes ejecutándose durante horas, el prompt es un error de redondeo.

Lo que determina la calidad del trabajo es el sistema que rodea a los agentes:

• en qué modo se ejecuta cada tarea
• qué modelo ejecuta cada paso
• cómo se mantienen coordinados los agentes
• cómo se verifica que "está hecho" mientras tú duermes

Un prompt te da un resultado. Un bucle te da una operación que se compone.

El cambio es simple. Dejas de ser la persona que lee cada resultado y escribe la siguiente instrucción. Te conviertes en la persona que diseña el sistema una vez y lo deja ejecutar.

Esa capa de diseño es el trabajo ahora. Así es como se construye.

Construyes el orquestador, no el código

No gestionas treinta agentes hablando con treinta agentes. Hablas con uno. Ese es el orquestador, y gestiona al resto.

Un buen orquestador hace exactamente tres cosas:

1. Descompone un objetivo en subtareas acotadas y verificables de forma independiente.
2. Delega cada subtarea a un trabajador, con un briefing conciso y una propiedad clara de los archivos.
3. Ensambla los resultados y decide qué hacer a continuación.

Una regla está por encima de todas: el orquestador nunca hace el trabajo él mismo.

En el momento en que tu agente principal empieza a escribir código de implementación, su contexto se llena de detalles y pierde la visión general del trabajo completo.

Mantén su contexto limpio. Piensa, divide, asigna y verifica. Nada más.

Luego ve en profundidad, no en amplitud:

• No hagas que el orquestador genere ocho trabajadores directamente. Eso fragmenta su contexto.
• Haz que genere dos o tres líderes en su lugar.
• Deja que cada líder genere sus propios dos o tres especialistas.

La recompensa es tres veces la profundidad de descomposición al mismo coste de contexto. Así es como escala una organización real: a través de capas, no teniendo a una persona asignando cada tarea.

Verificable o no: la división que lo decide todo

Antes de construir nada, haz una pregunta sobre la tarea. ¿Puede una máquina comprobar si está hecha?

Esa respuesta decide todo tu enfoque.

Si la tarea es verificable, puedes ponerla en bucle:

• Las pruebas pasan o no pasan.
• El verificador de tipos está en verde o no lo está.
• El benchmark supera el umbral o no lo supera.

Apunta un agente a una tarea verificable y escalará la colina durante la noche. Te despiertas con un problema resuelto.

Si la tarea no es verificable, un bucle por sí solo no te salvará. Ejemplos:

• Diseñar una buena evaluación.
• Decidir si una API se siente bien.
• Juzgar si vale la pena seguir una línea de investigación.

Para estas, inyectas criterio. No puedes entregar el objetivo y alejarte, porque no hay una puerta en la que parar.

Por lo tanto, el movimiento es hacer verificable la mayor parte del trabajo posible:

• Convierte "hazlo bien" en "supera estas comprobaciones específicas".
• Reemplaza objetivos vagos por otros concretos y medibles.
• Donde no puedas, mantén a un humano en el bucle y dirige.

La mayor parte de la ingeniería de orquestación consiste en convertir objetivos difusos en comprobables, para que el bucle pueda tomar el control.

Empieza con el sistema real más pequeño: un bucle de objetivos

Un bucle de objetivos es un objetivo persistente más una comprobación determinista. El agente trabaja paso a paso hacia un objetivo en lugar de detenerse después de un turno.

Todo el sistema es un bucle alrededor de tu agente y un validador:

1i=0
2until npm test -s; do
3  agent -p "Objetivo: hacer que el conjunto de pruebas esté en verde.
4            LEE el código y construye una imagen completa ANTES de cambiar nada.
5            'npm test' está fallando. Haz el cambio más pequeño hacia que pase."
6  (( ++i > 20 )) && { echo "detener: 20 iteraciones"; exit 1; }
7done

El validador es cualquier comando cuyo código de salida sea la puerta. Pruebas, una verificación de tipos, un linter o un script personalizado.

Dos cosas no son negociables:

1. Un límite. Un bucle sin condición de parada es como te despiertas con una factura de tokens de cinco cifras.
2. Una instrucción de leer primero. El modo de fallo predeterminado de cada agente es disparar al azar a la primera solución plausible en lugar de leer el código.

Obliga a la lectura. Es más lento por paso y mucho más rápido en general.

Haz que "estar hecho" no sea negociable: el juez

Los agentes abandonan pronto. Están entrenados para detenerse en cuanto pueden justificarlo.

"He hecho todo lo posible, me detengo aquí" no es lo mismo que estar hecho.

Si un agente califica su propio trabajo, hace trampa. No maliciosamente. Simplemente se convence a sí mismo de que ha terminado.

La solución es un juez separado:

• Un segundo agente cuyo único trabajo es puntuar el trabajo contra una rúbrica concreta.
• Responde una pregunta: hecho, o no hecho, y qué falta.
• No tiene interés en detenerse, por lo que no titubea.

Ejecuta el constructor y el juez en familias de modelos diferentes. Familias diferentes cometen errores no correlacionados, por lo que el juez ve lo que el constructor no ve.

1while :; do
2  agent --model "$BUILD" -p "Tarea: $TASK. Lee primero, implementa, ejecuta las pruebas."
3  verdict=$(agent --model "$JUDGE" -p "Revisor estricto. Puntúa contra cada elemento en rubric.md.
4            Responde exactamente 'PASS' o 'FAIL: <lo que falta>'.")
5  [[ $verdict == PASS* ]] && break
6done

Haz que la rúbrica sea concreta y binaria:

• Buena rúbrica: "todas las pruebas en verde, migración incluida, sin logging de depuración."
• Mala rúbrica: "hazlo bien."

Un verificador desinteresado con poder de veto es lo único que permite que una ejecución continúe durante horas en lugar de colapsar en cuanto el trabajador se cansa.

Ejecútalo en cada finalización de tarea. Entonces solo verás trabajo revisado en verde.

Más bucles que realmente usarás

El bucle de objetivos es el patrón base. Algunas variantes cubren la mayor parte de lo que ejecutarás.

1. El bucle de validación.

Actúa, ejecuta el validador, retroalimenta el fallo, repite hasta que la puerta esté en verde.

Úsalo para barridos de regresión, verificaciones de tipos y cualquier pase o fallo determinista.

2. El bucle de cola y reinicio.

Divide el trabajo en una lista de tareas pequeñas y atómicas. Procesa una a la vez.

Después de cada tarea, reinicia el agente a un contexto limpio y toma la siguiente.

Un contexto que se ejecuta durante horas se llena de confusión. Reiniciar mantiene cada tarea limpia.

La memoria vive fuera del agente, en el archivo de tareas y en el historial de commits.

1while read -r task; do
2  agent -p "Tarea: $task. Lee primero. Implementa, luego ejecuta las pruebas."
3  npm test -s && git commit -aqm "auto: $task"   # commit solo en verde
4done < tasks.txt

3. El bucle de monitorización.

Apunta un agente a un flujo de señales y deja que detecte lo que importa. Issues abiertos, builds fallidos, logs de errores, nuevos comentarios.

No espera a que preguntes. Lee, tria e informa hacia arriba, o abre un borrador de corrección.

1while sleep 300; do
2  agent -p "Lee los logs de errores de los últimos 5 minutos. Si aparece un patrón NUEVO,
3            abre un issue con una reproducción mínima. Si no, di 'nada nuevo'."
4done

4. El bucle de planificar-luego-construir.

Ejecuta el bucle en dos fases. Primero una pasada de planificación que produce un plan por escrito y se detiene.

Tú revisas el plan. Luego una pasada de ejecución sigue el plan aprobado.

El plan es barato de arreglar. El código es caro de arreglar. Detecta la mala dirección en el plan.

Los prompts que hacen el trabajo

Un prompt no es un deseo. Para un agente, es una especificación.

La brecha entre un resultado mediocre y uno excelente es casi enteramente la calidad de estos.

Mantén un pequeño conjunto de prompts reutilizables. Cinco soportan la mayor parte del peso.

1. El prompt de descomposición, para el orquestador:

1Eres el orquestador. NO escribas código.
2Divide este objetivo en 3 a 6 subtareas acotadas.
3Para cada una: un briefing de una línea, los archivos exactos que posee y su comprobación de finalización.
4Marca cualquier tarea que dependa de otra. Da salida a la lista, luego detente.
5Objetivo: <objetivo>

2. El briefing del trabajador, para un especialista:

1Posees SOLO estos archivos: <archivos>.
2Tarea: <una línea>. Hecho cuando: <verificación verificable>.
3Lee esos archivos y sus llamadores ANTES de editar. No cambies nada fuera de tus archivos.
4Cuando termines, escribe un informe de 5 líneas en <nombre>.md, luego ejecuta las pruebas.

3. El prompt del juez, para una familia de modelos diferente:

1Eres un revisor estricto y poco caritativo. No escribiste este código.
2Puntúa el repositorio contra CADA elemento a continuación. Un fallo es FAIL.
3<rúbrica>
4Responde con exactamente una línea: 'PASS' o 'FAIL: <lo que falta>'.

4. El prompt de planificar primero, para modo plan:

1Produce un plan por escrito para <objetivo>. Cubre: enfoque, archivos a tocar,
2casos borde, estrategia de pruebas, y lo que NO harás.
3No escribas código aún. Detente después del plan para que pueda revisarlo.

5. El prompt de reflexionar o matar, cuando un agente está atascado:

1Has fallado la misma comprobación 3 veces. Deja de repetir el enfoque.
2Responde en 3 líneas: qué falló exactamente, qué suposición era incorrecta,
3y la cosa más pequeña y diferente que probar. Luego prueba SOLO eso.

Un patrón recorre los cinco. Indicar el rol, los límites, la comprobación de finalización y lo que NO hacer.

Enrutamiento de modelos: la pregunta que todos hacen

La pregunta suele plantearse como una elección. ¿Pongo el modelo caro en la planificación o en la implementación?

Ese es el marco equivocado. Enruta por el radio de explosión en su lugar. Pregunta dónde te cuesta más un error.

La lógica es simple:

• Una mala decisión en la planificación se propaga por toda tu flota.
• Una mala línea en una función acotada y probada se detecta en minutos.
• Por lo tanto, gastas donde los errores son caros e irreversibles, y ahorras donde son baratos y están contenidos.

Aquí está el enrutamiento, nivel por nivel:

1. Planificación, arquitectura y descomposición: nivel superior, siempre. El mayor apalancamiento, volumen de tokens minúsculo. Ahorrar aquí es el error más caro que puedes cometer.
2. Implementación con una especificación ajustada: nivel medio, ejecutar en paralelo. La especificación hizo el pensar. Verificar con pruebas.
3. Implementación con una especificación flexible: nivel superior. Rellenar huecos es razonamiento, y un modelo barato adivina mal en una docena de direcciones.
4. Revisión y juicio: una familia diferente, y no una barata. Aquí es donde detectas los fallos caros.
5. Navegación, búsqueda, resumen y clasificación: el modelo más barato y rápido. Razonamiento cero, alto volumen. Nunca pagues tarifas premium por grep.

Por lo tanto, la respuesta real a "¿planificación barata o implementación barata?" no es ninguna, a ciegas.

Modelo superior en planificación y revisión, siempre. La implementación es la variable.

Las diferentes familias de modelos también tienen diferentes personalidades, y eso importa para el enrutamiento:

• Una familia rellena huecos. Cuando la especificación es flexible, hace suposiciones razonables y sigue adelante. Eso ayuda cuando las suposiciones son buenas, y perjudica cuando no lo son.
• Otra familia es literal. Hace exactamente lo que dijiste y poco más, como una navaja multiusos precisa.

Usa el relleno de huecos donde el trabajo es abierto y la especificación es flexible. Usa el literal para la revisión y para cambios exactos y bien especificados.

La palanca que controla la implementación es tu especificación

• Una especificación ajustada te da derecho a ejecutar trabajadores baratos y paralelos.
• Una especificación flexible te obliga a volver a un modelo caro para rellenar los huecos.

Invierte en el plan precisamente para poder abaratar la construcción.

Una trampa merece ser mencionada. El enrutamiento barato optimiza el precio de cada llamada, pero puede destruir silenciosamente la proporción de tokens que producen resultados enviables y fusionables.

Un modelo barato que reintenta cinco veces y produce código que no puedes fusionar es más caro que una pasada limpia de un modelo premium.

Mide el coste del resultado útil, no el coste por llamada.

Para escalar, dos números ayudan:

• Tu nivel superior cuesta aproximadamente cinco veces el precio de salida por token de un nivel barato.
• El enrutamiento por niveles típicamente reduce el gasto entre un 40% y un 60% en comparación con ejecutar tu mejor modelo en todas partes.

Habilidades: empaqueta un flujo de trabajo una vez, reutilízalo para siempre

Cuando sigues pegando el mismo prompt o ejecutando el mismo flujo de trabajo, conviértelo en una habilidad.

Una habilidad es un pequeño archivo de instrucciones que el agente carga solo cuando es relevante.

Escribes el flujo de trabajo una vez, y cada agente puede recurrir a él.

Un archivo de habilidad tiene dos partes:

• Frontmatter YAML con un nombre y una descripción.
• Un cuerpo en markdown con las instrucciones reales.

La descripción es la línea más importante. Le dice al agente qué hace la habilidad y exactamente cuándo usarla, para que el agente la recoja por sí mismo sin que tú la nombres.

Un archivo de habilidad mínimo:

1---
2name: revision-termonuclear
3description: Revisión de código profunda y adversarial. Úsala después de cualquier cambio no trivial,
4  o cuando se te pida revisar, auditar o endurecer un diff antes de fusionar.
5---
6
7# Revisión termonuclear
8
9Lee el diff completo y los archivos que toca. No hojees.
10
11Revisa en tres pasadas:
121. Corrección: errores lógicos, casos borde, condiciones de carrera, errores off-by-one.
132. Seguridad: inyección, autenticación, secretos, entrada no segura, operaciones destructivas.
143. Ajuste: ¿coincide con la arquitectura existente, o añade un patrón nuevo?
15
16Para cada hallazgo: archivo, línea, gravedad y la corrección de una línea.
17Termina con un veredicto: SHIP o BLOCK, más las 3 cosas principales a arreglar primero.

Reglas para buenas habilidades:

1. Mantén el archivo corto. Por debajo de unos pocos cientos de líneas. Mueve el material de referencia largo a archivos separados a los que la habilidad apunte.
2. Haz que el nombre coincida con su carpeta, o no se cargará.
3. Escribe la descripción para el disparo. Explica los casos de "usar cuando".
4. Nunca permitas que un agente reescriba una habilidad. Un humano cura cada línea.

Las habilidades son cómo se compone un flujo de trabajo. La primera vez que resuelves algo bien, lo guardas y lo haces descubrible. Cada sesión después de esa, es gratis.

Ejecutar muchos: la flota

Una vez que un bucle funciona, escalas.

Dale a cada trabajador dos cosas:

• Su propio worktree de git, para que nunca dos agentes toquen los mismos archivos.
• Su propia ventana de terminal, para que puedas verlo y enviarle mensajes.

1tmux new-session -d -s flota
2for name in hilbert gauss poincare; do
3  git worktree add -B "agent/$name" "../wt-$name" main
4  tmux new-window -t flota -n "$name" -c "../wt-$name" "$AGENT"
5done

• Pon nombre a tus agentes. Ejecutar quince de ellos, "agent_7" es inútil.
• Los nombres te permiten tener toda la flota en la cabeza. Este posee la capa de datos, ese escribe evaluaciones, aquel revisa.
• La legibilidad es el punto. Una flota que no puedes rastrear es una flota que no puedes dirigir.
• Luego haz que cooperen. Por defecto, los agentes se ignoran entre sí y tratan cualquier cosa de un compañero como ruido de fondo.

El truco es entregar mensajes entre agentes como turnos de usuario. Los modelos están entrenados para responder al usuario e ignorar en su mayoría las señales ambientales.

1send() { tmux send-keys -t "flota:$1" "$2" Enter; }
2send hilbert "GET /search?q= devuelve [{id,title,url}]. Conecta la interfaz de usuario a eso."

Ese único movimiento convierte un montón de procesos aislados en un equipo que pasa contratos y se desbloquea mutuamente.

Tú te quedas arriba. Le envías un mensaje al líder, y el líder lo transmite a los trabajadores.

Flujos de trabajo dinámicos: compila la coordinación a código

Un bucle mantiene la coordinación dentro del modelo. El modelo decide cada paso, lo que quema tokens y llena su contexto.

Un flujo de trabajo dinámico invierte eso. El orquestador escribe un script que coordina a los trabajadores, y un runtime separado ejecuta el script en segundo plano.

La idea clave es dónde vive el estado. El bucle, la bifurcación y los resultados intermedios residen en las variables del script, no en la memoria del modelo.

Lo que eso te compra:

• La coordinación cuesta cero tokens de modelo, porque el código simple lo está haciendo.
• Tu contexto principal se mantiene limpio. Solo el resultado final regresa.
• Se expande en amplitud. Decenas de trabajadores a la vez, hasta un millar a lo largo de una ejecución.

Cuándo recurrir a ello:

• El patrón es conocido y la verificación es objetiva.
• El trabajo es amplio y repetitivo. Muchos archivos, muchos casos, muchos endpoints.
• Puede ejecutarse sin supervisión.

Cuándo no recurrir a ello:

• Todavía estás averiguando qué hacer. Eso es un bucle de objetivos, no un flujo de trabajo.
• La tarea necesita una cadena de razonamiento coherente. Eso quiere un solo agente fuerte, no un millar.

Una forma concreta. Digamos que necesitas migrar 200 archivos a una nueva API:

1// el orquestador escribe esto una vez; un runtime lo ejecuta, no el modelo
2const files = await glob("src/**/*.ts");
3
4const results = await mapLimit(files, 16, async (file) => {
5  const r = await subagent(`Migrar ${file} a la nueva API. Ejecutar sus pruebas.`);
6  return { file, ok: r.testsPassed };
7});
8
9const failed = results.filter(r => !r.ok);
10return `migrados ${results.length - failed.length} de ${results.length}. ` +
11       `reintentar: ${failed.map(f => f.file).join(", ")}`;

Lee lo que hace:

1. Lista los 200 archivos en código, no en la cabeza del modelo.
2. Ejecuta 16 subagentes a la vez, cada uno migrando un archivo y ejecutando sus pruebas.
3. Registra pase o fallo por archivo en un array simple.
4. Devuelve un resumen corto. Los 200 transcripts intermedios nunca tocan tu contexto.

Ese es el punto. El modelo pensó una vez, para escribir el script. El script coordinó, gratis.

Guardarraíles: lo que evita que una flota se devore a sí misma

El cuello de botella humano solía hacer trabajo real. A velocidad humana, los errores duelen temprano y los arreglas sobre la marcha.

Elimínate por completo y los pequeños errores se acumulan más rápido de lo que puedes sentirlos. Una duplicación aquí, una abstracción innecesaria allá.

Un día la arquitectura no se doblará, y tus pruebas no serán de fiar porque los agentes también las escribieron.

Cada guardarraíl a continuación reemplaza la corrección que solía proporcionar el cuello de botella:

1. Leer antes de adivinar. Hazlo una regla permanente en cada prompt de construcción, no una súplica por tarea.
2. Limitar y matar. Cada bucle tiene un límite de iteraciones. Cada agente tiene un presupuesto de tokens que se pausa automáticamente cerca del 85%. Después de tres iteraciones atascadas en el mismo error, mata al agente y entrega la tarea a uno nuevo.
3. Un archivo, un propietario. Aísla con worktrees. Nunca permitas que dos agentes editen el mismo archivo.
4. Reinyectar la misión. En ejecuciones largas, publica la lista de verificación como un mensaje de usuario cada pocos minutos para que el agente no se desvíe a medida que su contexto se llena.

1while sleep 900; do
2  send gauss "RECORDATORIO: ¿sigues en la tarea? Lee primero. Ejecuta pruebas después de cada cambio. Mantente en tus archivos."
3done &

El punto más profundo subyace debajo de todo:

• La verificación es ahora el cuello de botella, no la generación.
• Los agentes producen resultados plausibles más rápido de lo que puedes verificarlos.
• Plausible no es correcto.

Hasta que tu verificación sea tan rápida como tu generación, la revisión humana no es un gasto general. Es el sistema de seguridad.

Memoria: tú eres el almacén a largo plazo

Un modelo tiene memoria a corto plazo, la ventana de contexto, y nada más. Todo lo que está más allá de esa ventana desaparece a menos que lo conserves.

Por lo tanto, trátate a ti mismo y a los archivos que guardas como la memoria a largo plazo para agentes que solo tienen memoria a corto plazo.

Dos hábitos importan.

Primero, pasa el estado por referencia, no por resumen:

• Cuando un contexto se llena, la solución perezosa es resumirlo. Los resúmenes son con pérdidas y eliminan el detalle que necesitarás después.
• En su lugar, apunta a los agentes a archivos, registros de tareas y resultados anteriores que puedan releer. Nada importante se desecha silenciosamente.

Segundo, mantén la memoria duradera fuera del agente:

• Un archivo de tareas con estados.
• Un registro de progreso continuo.
• El historial de commits.
• Un archivo de notas a largo plazo que recolecta patrones y errores.

Diseña como si tus agentes fueran a ejecutarse durante días, porque con una buena compactación lo harán.

Los modelos aún no saben esto sobre sí mismos. Llevan un sesgo hacia resolver todo dentro de un presupuesto corto, como si gastar tokens fuera fatal. Tu andamiaje es lo que les permite ejecutarse largo sin perder el hilo.

Topología: cuántos agentes, y en qué forma

Más agentes no es más producción. Más allá de un punto es menos, porque la coordinación no es gratis y se agrava con cada agente que añades.

La regla que importa es hacer coincidir la forma con el trabajo:

• Razonamiento secuencial y dependiente quiere menos agentes, a veces uno. Dividir una cadena de pensamiento única fragmenta el razonamiento y degrada el resultado.
• Trabajo independiente y paralelo quiere que te expandas. Topología plana, propiedad de archivos limpia. Ahí es donde la paralelización paga.
• Un equipo coordinado quiere de tres a cinco trabajadores. El coste de tokens escala aproximadamente linealmente con el tamaño. El coste de coordinación escala peor. Tres trabajadores enfocados superan a cinco dispersos.

Entonces, ¿cómo ejecuta alguien cientos? No como una gran conversación discutiendo consigo misma.

Los ejecutan como profundidad e independencia:

• Unos pocos agentes con los que realmente hablas, cada uno delegando hacia abajo a subtareas acotadas que no necesitan coordinarse.
• Enjambres de bucles independientes haciendo lo suyo e informando hacia arriba.

La escala proviene de la profundidad de delegación y la independencia. Nunca de ensanchar un solo hilo.

El archivo de control: orchestration.md

Probablemente tengas un archivo que les dice a los agentes cómo escribir código en tu repositorio. Estilo, errores, arquitectura. Consérvalo.

Responde a la pregunta incorrecta para la orquestación, sin embargo.

El archivo orchestration.md responde a una diferente. ¿Cómo debería ejecutarse el trabajo aquí?

Es un contrato escrito por humanos que cubre:

• qué modo usar para qué tarea
• qué nivel de modelo va dónde
• cuáles son los guardarraíles
• cuándo escalar a un humano

Cada agente lo lee al inicio de cada sesión y lo usa para seleccionar su enfoque.

Este es el archivo de mayor apalancamiento en el repositorio. Mueve la decisión de selección de modo fuera de tu cabeza, donde la tomas inconsistentemente en cada sesión, y la convierte en una especificación que la flota sigue.

Una versión corta se ve así:

1# orchestration.md. Cómo se EJECUTA el trabajo aquí. Curado por humanos. Los agentes no deben editar.
2
3Elige el modo:
4- Bucle de objetivos (supervisado): trabajo difuso o de diseño. Define la comprobación de finalización.
5- Bucle de validación: puerta determinista. Siempre limitar iteraciones y coste.
6- Construir más juez: el trabajador construye, un juez de familia diferente aprueba.
7- Flota (de tres a cinco): subtareas interdependientes, worktrees aislados, mensajería entre pares.
8- Cola y reinicio: muchas tareas atómicas pequeñas, contexto fresco cada vez.
9- Flujo de trabajo dinámico: patrón conocido, puerta objetiva, amplio y repetitivo. Coordinación en código, sin supervisión.
10
11Enruta modelos por radio de explosión:
12- Planificación y arquitectura: nivel superior, siempre.
13- Construir, especificación ajustada: nivel medio, paralelo, verificar con pruebas.
14- Construir, especificación flexible: nivel superior, porque rellenar huecos es razonamiento.
15- Revisar y juzgar: una familia diferente. Nunca el modelo del implementador.
16- Navegación, búsqueda, resumen: el más barato. Optimiza la salida fusionable, no el precio de llamada.
17
18Guardarraíles:
19- Presupuesto de tokens por agente. Pausa automática cerca del 85%. Matar y reasignar después de 3 intentos atascados.
20- Cualquier ejecución de más de una hora necesita un juez separado. Los trabajadores nunca se auto-reportan como hechos.
21- Leer código antes de hipotetizar. Planificar por escrito antes de la primera edición.

Dos reglas gobiernan el archivo:

1. Mantenlo corto.
2. Nunca permitas que un agente lo reescriba.

El valor es que un humano curó cada línea.

Lo que sigue siendo tuyo

La orquestación hace que los agentes sean fiables en la ejecución. No elige el problema y no sabe cómo es lo bueno.

Tres cosas se quedan de tu lado de la línea, permanentemente.

Primero, delega las tareas, no el juicio:

• Entrega a los agentes trabajo con alcance y criterios claros de pase o fallo. Trabajo repetitivo, migraciones, andamios de pruebas y enfoques que nunca tendrías tiempo de probar manualmente.
• Mantén para ti la arquitectura, la decisión sobre qué no construir y la revisión de contexto completo.
• Los agentes han absorbido un océano de arquitectura mediocre, y felizmente copiarán patrones pesados en un proyecto que no debería tenerlos. Decir que no es una característica que no tienen.

Segundo, tu especificación es el apalancamiento:

• Cuando te despliegas en una flota, el pensamiento vago no solo te frena: se multiplica.
• Un requisito ambiguo se propaga a través de docenas de ejecuciones paralelas, y cada una se desvía en su propia dirección.
• Una especificación precisa se multiplica en implementaciones precisas en todas partes.

Por eso un ingeniero sólido obtiene más de estas herramientas, no menos. La escritura se automatizó. La comprensión se amplificó.

Dedica la mayor parte de tu tiempo al modo de planificación, con un plan escrito en el que todos estén alineados, antes del primer cambio.

Tercero, subfinancia a propósito:

• Asigna un trabajo de cuatro agentes con dos. La restricción fuerza el comportamiento que deseas.
• Construyes bucles en lugar de hacer las cosas a mano, y la próxima vez ese trabajo ya estará automatizado.
• Desplaza tu presupuesto del esfuerzo manual a los tokens. Alta inversión inicial, costo marginal casi nulo para siempre.

Los equipos que hacen esto se benefician de la acumulación. Los que no, pagan el precio completo cada vez.

Ya no estás escribiendo el software. Estás construyendo la fábrica que lo escribe.

Una fábrica necesita entradas precisas, control de calidad en cada estación y un dueño que sepa qué debe ser el producto.

Empieza aquí

No intentes ejecutar cien agentes el lunes. Sube la escalera:

1. Ejecuta un único bucle de objetivo en una tarea con una meta verificable. Aprende cómo se siente una buena comprobación de finalización.
2. Añade un juez de una familia de modelos diferente para cualquier cosa que dure más de una hora. Prohíbe la finalización auto reportada.
3. Escribe tu orchestration.md. Dile a tus agentes que lo lean primero. Obsérvalos empezar a elegir modos por ti.
4. Despliega con cuidado. Una tarea paralelizable, de tres a cinco trabajadores, árboles de trabajo aislados, presupuestos de tokens.
5. Enruta tus modelos. El nivel superior para planificación y revisión, más barato para construcción acotada y trabajo mecánico. Mide la producción fusionable.
6. Déjalo funcionar sin supervisión una vez que un patrón esté validado y sea comprobable objetivamente. Vacía el trabajo pendiente durante la noche.

El sistema solo necesita estar direccionalmente bien, no perfecto:

• El archivo de control da a la flota la estructura suficiente para autodirigirse.
• El juez atrapa los casos límite.
• El bucle de recordatorio maneja la memoria.
• Tu criterio maneja las decisiones que no se delegan.

El prompting fue la habilidad del año pasado. Esta es la habilidad ahora.

Las versiones ejecutables de cada sistema aquí —el bucle de objetivo, el bucle de juez, el lanzador de flota, el bus de mensajes, el perro guardián de recordatorios y el enrutador de modelos— viven en el kit complementario. Configura una variable en tu CLI de agente y listo.

Aviso legal

Este artículo fue escrito utilizando sesiones de Claude Code y codex del autor.

Editado por el autor y el modelo Kimi K2.6 para cuestiones gramaticales y de formato.