Pepper-orchestrator armó tres paquetes en 1 hora y 52 minutos sin código manual

Un solo agente de IA construye un prototipo bastante bien mientras todo el proyecto cabe en la cabeza de una persona. Después empieza un dolor conocido: un cambio de API afecta a un repositorio vecino, dos ejecutores editan un archivo común y las pruebas confirman exactamente los supuestos con los que se escribió el código. Maxim Nikitin, del estudio ITSalt, propone resolverlo no con un prompt más largo, sino dividiendo la responsabilidad.

Su complemento pepper-orchestrator para Claude Code y Codex convierte un objetivo grande en un programa de pequeños paquetes de trabajo. Cada paquete recibe su propio contexto, rama o copia de trabajo, rutas permitidas, dependencias y criterios de aceptación verificables. El orquestador no escribe el código de los módulos: mantiene la visión de conjunto, determina el orden de ejecución y entrega el resultado a un revisor independiente.

Cómo se ve en un caso sencillo

La demostración consistía en crear una aplicación para un especialista en compras. El usuario sube contratos en texto y obtiene una tabla con el número, el proveedor, el importe y el plazo de entrega. En los documentos se dejaron trampas a propósito: junto al precio había un anticipo, el límite «no más de 600 000 rublos» parecía el importe total y el plazo de pago podía confundirse con el plazo de entrega.

El orquestador dividió el trabajo en tres paquetes: el motor de análisis de documentos, la interfaz con un sistema de diseño y una nota explicativa. Las partes independientes se enviaron a copias separadas del repositorio. Los archivos comunes debían modificarse de forma secuencial, de modo que los solapamientos se hicieron visibles antes de empezar y no durante la fusión.

Tras 1 hora y 52 minutos, los tres paquetes quedaron cerrados formalmente. El autor no escribió código a mano, sino que tomó decisiones de producto y resolvió acciones controvertidas. Es una aclaración importante: no se trata de una fábrica de software autónoma, sino de un sistema en el que la persona sigue siendo la dueña del programa y controla los permisos, la fusión y la publicación.

Por qué las pruebas en verde no bastaron

La primera versión del motor pasó sus propias pruebas, pero un revisor independiente reformuló las condiciones de los contratos con otras palabras y detectó tres errores cometidos con total seguridad. El anticipo se tomaba como importe total, el límite como precio del contrato y el plazo de pago como plazo de entrega. El paquete se devolvió para corregirlo, y después los valores dudosos empezaron a marcarse como pendientes de revisión.

Luego el producto fue revisado por tres «clientes» distintos: un usuario leal, un usuario deliberadamente descuidado y un competidor que busca casos límite. Este último encontró dos errores más en la interpretación del importe y de un acuerdo adicional vigente. Un despliegue limpio reveló tiempos de espera agotados que no aparecían en la máquina del desarrollador, y seis puntos poco claros en las instrucciones.

La idea de ingeniería central es simple: el mensaje «listo» de un agente es una afirmación, no una prueba. El ejecutor y el revisor no deben compartir el mismo contexto; de lo contrario, el segundo hereda los supuestos del primero. Conviene verificar no solo el código, sino también el comportamiento del producto: con datos parafraseados, en una máquina limpia y en escenarios de usuarios con intenciones distintas.

Dónde el enfoque es realmente útil

La orquestación se justifica cuando la tarea afecta a varios módulos o repositorios, el trabajo puede dividirse por archivos y el resultado se describe con criterios observables. Para una corrección pequeña, esta estructura solo añade registros, copias del repositorio y el coste de sesiones adicionales de agentes.

También hay un límite en la evidencia: las cifras las obtuvo el autor del complemento en su propio caso, sin compararlas con el desarrollo habitual y sin una medición independiente de la calidad. Por eso, 1 hora y 52 minutos no puede considerarse una métrica universal de aceleración.

La conclusión práctica para un equipo: primero fije un objetivo, los límites de los paquetes y las dependencias; luego separe la ejecución de la verificación; deje las acciones irreversibles en manos de una persona. Un orquestador es útil no por el número de agentes, sino porque hace explícitos el estado, la responsabilidad y los criterios de aceptación.