Reporte de Experiencia: Construyendo un Motor de Optimización con Inteligencia Artificial y Elementos de Juegos de Rol

Un motor de optimización para ruteo de vehículos, construido con agentes de inteligencia artificial y un único ingeniero humano.

Camilo Rodríguez – Julio de 2026

Resumen

Este es un informe de experiencia sobre la especificación y construcción de Creante Orbital, un motor de optimización para el problema de ruteo de vehículos con entregas y recolecciones simultáneas (VRPSPD, por su sigla en inglés). Este trabajo se realizó dentro de lo que fue la tercera cohorte de Hardcore AI, un programa de certificación en agentic engineering de 30x. En este tipo de problemas, una flota de vehículos atiende paradas donde se puede entregar y recoger carga, con costos de viaje que cambian según la hora. Agentes de inteligencia artificial (IA) —agentes de software guiados por modelos de lenguaje— participaron en el análisis de requisitos, el diseño, la revisión adversarial, la implementación, la revisión de código y las pruebas.

El trabajo tuvo dos etapas claramente distintas. Durante unos diez días calendario, a tiempo parcial, especifiqué el sistema con el Ciclo de Vida de Desarrollo Impulsado por IA (AI-DLC, por su sigla en inglés): un proceso por etapas que convierte la intención en requisitos y diseños aprobados mediante puntos explícitos de decisión humana. Después construí el producto mínimo viable (MVP), es decir, la versión completa más pequeña con la que se podía probar el sistema de punta a punta, en un sprint de aproximadamente cinco días y medio, del 8 al 13 de julio de 2026. Para hacerlo usé un pipeline de construcción multiagente —un flujo automatizado de trabajo— con cuatro agentes constructores y cuatro agentes revisores, cada uno con una identidad propia.

La velocidad de construcción es el resultado más llamativo, pero no el más importante. En mi experiencia, el desarrollo con agentes funcionó porque estuvo precedido por una especificación excepcionalmente explícita. Especificar ya era una de mis fortalezas y, aun así, AI-DLC encontró decisiones que estaban claras en mi cabeza pero que en el documento inicial eran ambiguas, estaban desactualizadas o simplemente no aparecían. Los equipos humanos suelen resolver esas ambigüedades mientras construyen. Los agentes también las «resuelven», pero lo hacen escogiendo una interpretación plausible e implementándola con confianza. AI-DLC adelantó buena parte de ese trabajo de depuración para hacerlo antes de escribir la primera línea de código.

Este informe se organiza alrededor de tres conclusiones. Primero, una especificación de alta calidad es un requisito para tener una buena experiencia construyendo con agentes, y AI-DLC fue especialmente efectivo para producirla. Segundo, el juicio de los agentes de IA es valioso, pero no se puede tratar como autoridad: los paneles adversariales encontraron una contradicción fundamental en la función objetivo durante la especificación y, más adelante, recomendaron con total seguridad funcionalidades y librerías que en realidad no existían. Tercero, los resultados incorrectos que parecen convincentes exigen controles estructurales, determinísticos, no más vigilancia: experimentos con criterios definidos de antemano, un validador determinista e independiente, aislamiento entre módulos, criterios de aceptación medidos y una política de integración que, salvo una excepción acotada, exigía aprobación humana.

Al terminar el sprint habían entrado treinta y dos commits de integración a main: veintisiete los integré yo y cinco se integraron durante una única excepción autónoma, explícitamente autorizada y con alcance limitado. Los conjuntos internos de pruebas de referencia —benchmarks— y de aceptación certificaron el motor para 200 paradas distribuidas en ocho vehículos y cinco semillas fijas. Eso no es una demostración formal ni un piloto en producción. Es el límite observado del MVP que describo en estas páginas.

1. La pregunta detrás de la construcción

El 13 de julio, Orbital podía recibir un problema de ruteo, escoger vehículos y rutas, respetar sus reglas duras de capacidad, mejorar un plan dentro de un presupuesto finito de búsqueda, validar el resultado de manera independiente y responder con honestidad cuando no encontraba un plan aceptable. Cinco días y medio antes, el repositorio tenía una especificación completa, pero todavía no se había escrito la primera línea de código que hubiera pasado el proceso de aceptación.

Es fácil resumir el resultado diciendo que «un ingeniero y ocho agentes construyeron un motor de optimización en una semana». También es fácil entenderlo mal. Los agentes no recibieron una idea de producto para convertirla, por su cuenta, en software confiable. Recibieron una especificación detallada y organizada por etapas; trabajaron dentro de funciones muy acotadas; produjeron artefactos que se podían revisar; fallaron de varias formas perfectamente plausibles; y fueron corregidos mediante experimentos, verificaciones independientes y decisiones humanas.

Por eso, la pregunta que quiero responder no es si los agentes pueden escribir código rápido. Pueden.
La pregunta es:

¿Qué hizo falta para que un solo ingeniero pudiera usar agentes de IA y construir rápidamente un sistema de optimización con consecuencias operacionales, sin ceder el control sobre lo que el sistema debía hacer ni sobre la validez de sus resultados?

Voy a contar la historia en el orden en que la viví: primero el problema y sus riesgos; luego la especificación con AI-DLC; el primer intento fallido de construcción; la creación del pipeline de construcción; los puntos de quiebre durante el desarrollo; y, finalmente, lo que creo que otro ingeniero puede —y no puede— sacar de esta experiencia.

2. El sistema tenía que fallar con honestidad

Orbital nació de un problema que conocí mientras trabajaba en software logístico para la entrega domiciliaria de oxígeno medicinal en Colombia, entre 2008 y 2021. El problema de planificación diaria es fácil de reconocer: ¿qué vehículos deben salir, qué paradas debe atender cada uno y en qué orden? En la práctica, los planificadores pueden empezar la noche anterior y seguir trabajando hasta la mañana siguiente.

Orbital es un motor diseñado para consumirse por API. Su MVP resuelve un VRPSPD con un solo depósito. Cada vehículo sale de una base, visita paradas donde puede entregar y recoger equipos, y regresa. Los vehículos tienen capacidades distintas por tipo de equipo y un límite de peso total. El tiempo y la distancia de viaje dependen de la hora de salida. El objetivo no es minimizar una aproximación como la distancia o la duración, sino el costo operacional real: combustible, despacho y horas extra. La cantidad de vehículos utilizados también es una decisión del modelo, dentro de un rango configurado.

El dominio imponía una frontera de corrección muy clara. Una ruta que sobrecarga un vehículo no es una ruta de menor calidad: es inválida. Una ruta que omite una parada no sirve. Y un motor que declara un problema como infactible solo porque una heurística agotó su tiempo está dando una respuesta engañosa.
Orbital puede responder «no se encontró una solución dentro del presupuesto». Lo que no puede hacer es presentar como válido un plan que viola su estructura.

Durante la especificación, este riesgo recibió un nombre: R-11, resultado plausible pero incorrecto.
Ponerle nombre fue importante. Un optimizador —o solver, el componente que busca una solución— puede devolver una respuesta pulida que parece razonable, pero que viola una recurrencia de capacidad, reporta mal el costo u omite parte del problema. El software construido por agentes agrega otra fuente del mismo riesgo: una implementación puede ser coherente, estar cubierta por pruebas y, aun así, construir el producto equivocado porque entendió mal el requisito.

R-11 influyó más en la arquitectura que cualquier funcionalidad individual. Terminó produciendo un validador implementado de manera independiente, una barrera de integración continua entre el validador y el optimizador, estados explícitos de falla y controles medibles sobre el solver. Pero antes de darle forma al código, tenía que darle forma a la especificación.

3. Especificar fue el primer acto de ingeniería

3.1. AI-DLC

La especificación es una de mis fortalezas. Disfruto tomar un problema operacional todavía confuso, encontrar la decisión real que hay detrás y describir el sistema con suficiente precisión para que un equipo lo pueda construir. Esa experiencia hizo que AI-DLC me llamara mucho la atención, pero también me dio una buena forma de ponerlo a prueba: ¿el proceso iba a mejorar una disciplina en la que yo ya confiaba o solo iba a agregar ceremonia?

AI-DLC dividió el trabajo en artefactos por etapas y puntos de aprobación. La fase de concepción (Inception) cubrió requisitos, historias de usuario, planificación del flujo, diseño de aplicación y unidades de trabajo. La fase de construcción (Construction) agregó diseño funcional, requisitos no funcionales, decisiones de infraestructura, planes de generación de código, implementación y pruebas integrales. Las entradas y decisiones del usuario quedaron registradas en una bitácora de auditoría que solo permitía agregar información. Cada etapa de diseño terminaba con una decisión humana explícita antes de continuar.

En el desarrollo convencional, incluso una buena especificación conserva zonas grises. Una frase admite dos interpretaciones. Una decisión ya fue tomada, pero solo existe en la cabeza de quien escribió el documento. Dos secciones fueron redactadas en momentos distintos y ya no coinciden. Un equipo humano suele corregir esos defectos con preguntas, conversaciones informales y criterio profesional mientras implementa.

Los agentes cambian el costo de esas zonas grises. Un agente no siempre se detiene ante cada ambigüedad.
Puede escoger la interpretación más plausible, implementarla de manera limpia y rodearla de pruebas. El resultado puede ser internamente coherente y, al mismo tiempo, representar el producto equivocado. En ese contexto, programar más rápido también significa amplificar más rápido la ambigüedad original.

AI-DLC fue especialmente bueno para adelantar ese trabajo de depuración. El valor no vino de que un agente conociera mágicamente los requisitos. Vino de obligar a expresar la misma intención en formas distintas: requisitos, historias, reglas de negocio, límites entre componentes, entidades de dominio, propiedades de aceptación y preguntas adversariales. Cada transformación abría otra oportunidad para encontrar lo que faltaba o se contradecía. Los puntos de aprobación impedían que esos hallazgos se convirtieran, en silencio, en decisiones tomadas por el agente.

3.2. El proceso encontró una decisión que yo creía resuelta

El ejemplo más claro fue la función objetivo. Los primeros documentos de descubrimiento heredaban un modelo que minimizaba tiempo. Para cuando escribí los requisitos de producto, yo ya había decidido que Orbital debía minimizar el costo operacional real. Poner otro vehículo en la calle puede reducir el tiempo total, pero también tiene un costo fijo y requiere otra cuadrilla. En esta operación, minimizar tiempo podía gastar de más precisamente los recursos que limitan la jornada.

La narrativa del producto decía «costo». El modelo matemático heredado todavía decía «tiempo». Yo sabía lo que quería decir, pero la especificación no.

El 22 de junio, un panel adversarial de cinco agentes revisores —investigación de operaciones, computación cuántica, producto, ingeniería y estrategia de startups— leyó el documento tal como estaba escrito y encontró la contradicción. Esa intervención cambió el proyecto. Volví a derivar la función objetivo alrededor del costo fijo de despacho, el combustible dependiente de la hora, las horas extra y una equidad opcional. El panel también sacó la computación cuántica del mensaje principal y la convirtió en una hoja de ruta explícita: cómputo clásico hoy, métodos de inspiración cuántica más adelante y hardware cuántico real solo cuando sea defendible desde el punto de vista técnico y económico.

Esa es la evidencia más fuerte que tengo sobre el valor de AI-DLC para especificar. No estaba compensando la falta de experiencia de quien escribía. Encontró una inconsistencia importante en el trabajo de alguien que considera la especificación una fortaleza. El proceso dejó el contrato escrito mejor que la intención que yo llevaba por dentro.

3.3. De la intención de producto a un contrato ejecutable

Entre el 24 de junio y el 4 de julio, la especificación se convirtió en siete unidades conectadas por un grafo de dependencias:

Unidad	Nombre	Responsabilidad
U0	Andamiaje	Esqueleto de Django, Docker, integración continua y regla de aislamiento para R-11
U1	Borde y contrato	Contrato OpenAPI, autenticación por cliente, idempotencia, limitación de solicitudes y salud
U2	Persistencia y aislamiento	Trabajos separados por cliente y soluciones inmutables sin información personal de salud
U3	Preparación del problema	Modelo canónico y cubo de costos de viaje por franjas horarias detrás de un puerto de tráfico
U4	Motor de optimización	Adaptador para Google OR-Tools, conjunto de herramientas de optimización de código abierto, detrás de un puerto de solver
U5	Validación independiente	Validador determinista, con prohibición de importar U4
U6	Orquestación y entrega	Ciclo de vida del trabajo, presupuesto de cómputo, control de validación y notificaciones de retorno firmadas (`callbacks`)

Los diseños detallados definieron entidades, reglas de negocio, puertos, estados de falla, pruebas y restricciones no funcionales. El modelo matemático se construyó en diálogo con los agentes, pasó por una revisión adversarial y luego quedó bloqueado como contrato. Tres requisitos que más adelante se convertirían en bloqueos de construcción ya estaban escritos: la carga inicial debía ser exactamente la suma de todo lo que una ruta iba a entregar; la equidad estricta requería dos pasadas lexicográficas en lugar de un coeficiente de penalización peligrosamente grande; y los perfiles dependientes del tiempo debían respetar la propiedad de primero en entrar, primero en salir (FIFO, por su sigla en inglés), según la cual salir más tarde nunca permite llegar antes.

La fase de especificación se sintió pesada para un proyecto de una sola persona. Esa sensación era real.
Fueron cerca de diez días calendario de trabajo parcial antes de empezar a construir el MVP. Pero después esos documentos cumplieron tres funciones al mismo tiempo: instrucciones para los constructores, criterios de evaluación para los revisores y árbitro cuando la intención y la implementación se separaban. Al llegar a la semana de construcción, ya no les estaba pidiendo a los agentes que dedujeran un sistema. Les estaba pidiendo que materializaran un contrato. Esa diferencia sostiene todo lo que viene a continuación.

4. El primer enfoque de construcción no encajó

Mi primer intento de construcción usó OpenHands, una plataforma abierta de desarrollo con agentes, siguiendo un modelo comunitario de orquestación llamado Symphony. El modelo tenía la forma que yo buscaba: tickets de trabajo (issues) como unidades de avance, constructores y revisores separados, y rondas explícitas de revisión antes de integrar. El intento produjo trabajo real de andamiaje y persistencia, pero nunca logró establecer un ritmo de construcción que yo pudiera aceptar.

Aparecieron dos problemas. En mi uso particular, el avance era más lento y consumía más tokens por unidad de progreso que la interfaz de línea de comandos para agentes que yo ya manejaba todos los días.
Más importante aún, la base tecnológica no coincidía con el proyecto. El flujo prestado suponía GitHub, Linear y OpenHands; Orbital vivía en GitLab y en mis herramientas habituales para agentes. En medio de un sprint corto, yo estaba aprendiendo una combinación de herramientas ajena —otro stack— en lugar de construir el motor.
Conservé la idea de orquestación y descarté el stack. Los agentes hicieron que reemplazarlo fuera lo suficientemente barato como para ser una decisión racional: podía tratar Symphony como una especificación de flujo y portar sus restricciones útiles a herramientas que ya dominaba. El resultado fue Normandy, operativo en aproximadamente un día.

Eso cambió mi forma de ver los marcos de orquestación de agentes. Su activo más duradero puede ser el ciclo de trabajo que describen, no necesariamente el paquete de software que lo implementa. En este proyecto, adoptar el ciclo y mantener el control de la base tecnológica fue más rápido que adaptar el proyecto al marco.

5. Normandy convirtió la especificación en una línea de producción

Normandy era deliberadamente pequeño. Coordinaba tickets de GitLab, directorios de trabajo aislados de Git (worktrees) y sesiones de agentes mediante cinco mecanismos.

5.1. Una máquina de estados visible

Cada tarea correspondía a un ticket de GitLab con una sola etiqueta activa de estado:
backlog → ready-for-construction → in-progress → agentic-review ⇄ changes-requested → human-review → done
Una dependencia podía llevar la tarea a blocked. Una persona debía mover el ticket a ready-for-construction; ningún constructor comenzaba antes de esa señal. Cada ticket producía una rama y una solicitud de integración —merge request, en la terminología de GitLab—. Así, la unidad de progreso era un artefacto que se podía revisar contra una especificación que hacía de contrato, no la transcripción de una sesión con un agente.

5.2. Constructores puros

Los cuatro agentes constructores —Tali, Garrus, Grunt y Vega— se asignaban por turnos. Cada constructor recibía el ticket, los documentos de diseño pertinentes, un directorio de trabajo aislado y herramientas de archivos y terminal. Implementaba, probaba, hacía commit y enviaba la rama. No podía cambiar etiquetas del flujo ni los documentos centrales de estado y auditoría.
Esa restricción acercaba a los constructores a funciones puras: entraba una especificación y salían código y evidencia.

5.3. Paneles de revisión de solo lectura

Cada uno de los cuatro revisores tenía un enfoque único: Mordin revisaba corrección y pruebas; Liara, conformidad con el diseño y la especificación; Thane, seguridad; y Samara, estándares de ingeniería. Cada panel usaba el subconjunto pertinente, normalmente tres revisores, y agregaba seguridad cuando el cambio lo ameritaba. Todos los enfoques convocados debían aprobar.

Un hallazgo bloqueante devolvía el ticket a changes-requested. Un constructor recibía entonces los hallazgos como un nuevo paquete de trabajo. El retrabajo automático tenía un límite de tres rondas; si lo agotaba, la tarea escalaba obligatoriamente a una persona.

5.4. Una sola autoridad para actualizar el estado compartido

Solo el orquestador podía cambiar las etiquetas de GitLab y los documentos centrales de estado y auditoría de AI-DLC. Así se evitaba que varios agentes produjeran versiones distintas de la verdad de proyecto. La regla demostró su valor durante una falla de la estación de trabajo: GitLab y los artefactos ya registrados en Git conservaron un estado coherente, aunque hubo que reconstruir una parte del estado local y de la bitácora de auditoría que todavía no tenía commit.

5.5. Aprobación humana, con una excepción explícita

La regla normal era que yo revisara e integrara cada cambio aceptado. Veintisiete de los treinta y dos commits de integración del sprint siguieron ese camino. Los otros cinco pertenecían a un único bloque nocturno de integración del demo, para el cual autoricé explícitamente a Normandy a integrar solo después de cerrar las revisiones sin hallazgos bloqueantes, conservando el límite de tres rondas antes de escalar. La excepción estaba acotada por tarea, tiempo y condiciones; no se convirtió silenciosamente en la nueva regla.

5.6. Los personajes estaban diseñados para quien operaba el sistema

Los ocho agentes tenían nombres y firmaban su trabajo como el escuadrón de un videojuego conocido. Cada uno tenía identidad de correo, línea de coautoría y una frase característica al cerrar su trabajo. En ese momento, eso era toda la gamificación: todavía no existían puntos, tablas de posiciones ni estadísticas por agente.

Sí observé un efecto sobre mí. A la una de la mañana, volver a revisar «el andamiaje de Tali» era más fácil que volver a feat/U0-scaffold. Los nombres le dieron continuidad a una semana agotadora y me ayudaron a mantener separadas las responsabilidades. No tengo evidencia controlada de que hayan mejorado la calidad del código. Los personajes sí tuvieron un efecto observable sobre el factor humano; que también mejoren la

6. Lo que ocurrió durante la construcción

El sprint no fue la ejecución ordenada de un plan perfecto. La especificación acotó el trabajo, pero el motor todavía tenía que enfrentarse al comportamiento de un solver real. Los avances más importantes aparecieron cuando una idea atractiva no sobrevivió a la medición.

6.1. Los cimientos abarataron los desacuerdos posteriores

Las primeras unidades establecieron el esqueleto del proyecto, las fronteras entre clientes, el contrato de la API, el modelo de persistencia y la entrada canónica del optimizador. Fue un trabajo menos dramático que el solver, pero sirvió para probar el pipeline. Los constructores tenían diseños precisos por unidad.

Los revisores podían señalar una regla incumplida en vez de discutir preferencias. El retrabajo volvía como un ticket acotado, en lugar de disolverse en una conversación sin límites.

El proceso también demostró que el detalle no elimina toda interpretación. A veces los revisores aplicaron una instrucción de forma más literal de lo que yo pretendía, y la implementación reveló enmiendas de diseño que debían propagarse por varios documentos. La diferencia fue que el desacuerdo quedó visible. La especificación nos daba un lugar para resolverlo y dejaba registro de la decisión.

6.2. Una prueba definida de antemano descartó el motor que yo quería construir

El diseño bloqueado suponía originalmente que OR-Tools podía buscar directamente sobre costos monetarios dependientes del tiempo: el costo de atravesar un arco dependería de la hora de salida acumulada hasta ese punto de la ruta. Antes de construir el motor de producción, el plan de U4 exigía un spike —una prueba técnica desechable— que comparara ese enfoque nativo con una alternativa iterativa: congelar costos, resolver, volverlos a congelar en los tiempos resultantes y repetir.

Los criterios de aceptación quedaron escritos antes de obtener resultados. Eso importaba porque yo quería que el diseño sofisticado funcionara.
Los dos candidatos fallaron de manera distinta. El costo monetario nativo dependiente del tiempo no era simplemente difícil en el solver escogido: el mecanismo necesario no existía. OR-Tools exponía un punto de extensión (hook) dependiente del acumulado (cumul-dependent) para el tránsito, pero no para la función completa de costo por arco que necesitaba el modelo.

El prototipo iterativo sí corría y devolvía planes plausibles. También era incorrecto. En una instancia medida reportó el costo más barato encontrado entre todas las iteraciones, pero devolvió la ruta de la última: una diferencia de 5,1 %. Su afirmación de que había «convergido en cuatro iteraciones» significaba, en realidad, que siempre había llegado al límite de iteraciones.

Un panel de seis agentes —los cuatro enfoques de Normandy más especialistas en el funcionamiento interno del solver y metaheurísticas— se dividió inicialmente en tres posiciones, con dos votos cada una:
construir el ciclo corregido, reabrir la pregunta o aceptar un diseño degradado. Después de una discusión estructurada, la decisión se cerró el 10 de julio:

Resolver una sola vez con costos congelados a la hora de salida del problema.
Volver a evaluar exactamente la ruta elegida usando sus horas reales de salida.
Reportar el costo exacto del plan entregado.
Dejar el ciclo iterativo corregido como trabajo futuro detrás de una interfaz de solver.

El plan era menos ambicioso y más honesto. Más importante aún, el spike había evitado que la arquitectura que yo quería terminara en producción solo porque aparecía en un diseño aprobado.

En ese momento también entendí con mayor claridad mi propio papel. En medio de la crisis, un agente podía pasar horas perfeccionando un arnés de pruebas (harness) para que fallara correctamente, mientras la pregunta existencial seguía sin respuesta: ¿alguno de los algoritmos candidatos funcionaba? Varias veces tuve que devolver el trabajo a la razón del experimento.

Los agentes perseguían fielmente el objetivo escrito; yo seguía siendo responsable de decidir cuándo ese objetivo había dejado de responder la pregunta real del proyecto.

6.3. El validador convirtió la corrección en un programa separado

La respuesta arquitectónica a R-11 llegó en U5. El validador recorría de nuevo cada plan entregado con aritmética determinista: continuidad de las rutas, cobertura exacta de las paradas, capacidad por tipo de equipo en cada punto, peso, uso de vehículos y las demás invariantes duras. El resultado era un veredicto detallado, con una decisión principal: válido o inválido.
Tres propiedades impedían que se convirtiera en una segunda copia del error del optimizador:

Derivaba sus verificaciones directamente de las reglas de negocio, sin reutilizar lógica del solver.
Una regla de integración continua prohibía que U5 importara código de U4.
Para el mismo problema canónico y el mismo plan, siempre devolvía el mismo veredicto.

El optimizador podía rechazar su propio candidato durante la extracción, y el validador independiente volvía a revisar el resultado que se iba a entregar. Si cualquiera de los dos puntos duros fallaba, la orquestación no entregaba el plan. La corrección no dependía de convencer a otro modelo de que el resultado «se veía bien».
Un invariante dejó clara la diferencia entre el requisito matemático y un modelo de búsqueda que escala.

Cada vehículo debe salir cargado con todo lo que su ruta va a entregar. Codificar directamente esa igualdad, que cruza la ruta completa, impedía que las heurísticas de primera solución de OR-Tools construyeran instancias grandes. Por eso, el motor de producción buscaba sobre una relajación necesaria, limitaba las entregas y recolecciones totales de cada ruta, derivaba la carga inicial real durante la extracción, recorría la ruta con exactitud y rechazaba cualquier falla. U5 repetía el mismo invariante de forma independiente. El requisito seguía siendo duro, aunque su realización escalable no fuera una transcripción literal dentro del modelo de búsqueda.

6.4. Los expertos se equivocaron con total confianza —y aun así fueron útiles

Para el 12 de julio, el motor solo era confiable hasta unas cincuenta paradas. Convoqué un panel de tres agentes presentados como expertos de talla mundial en arquitectura de OR-Tools, modelado VRPSPD y búsqueda heurística. Produjo diecinueve recomendaciones y destacó una maniobra principal. La medición fue contundente:

La recomendación principal no certificó una sola instancia adicional.
Una configuración que el panel insistía en agregar ya era el comportamiento predeterminado del solver.
Varias recomendaciones no cambiaban nada o citaban campos que no existían en la versión instalada.

La misma técnica general —un panel adversarial— había encontrado el error de la función objetivo que cambió el proyecto. Ahora inventaba conocimiento sobre la librería con la misma seguridad. La conclusión no era simplemente «los paneles funcionan» o «los paneles fallan». Razonaban bien sobre la estructura, pero recordaban mal la API real de una dependencia que cambia rápido.

Aun así, sus recomendaciones produjeron valor. Para probarlas construimos un arnés de pruebas de ablación, es decir, un instrumento que aislaba cada cambio y medía su efecto por separado. Ese mismo instrumento hizo visible la omisión real del modelo. La regla que quedó fue sencilla: los paneles proponen; los benchmarks deciden.

6.5. Un límite faltante llevó el motor de 50 a 100 paradas

La primera corrección de escalabilidad fue casi vergonzosa por su sencillez. El modelo exigía que los equipos recogidos a lo largo de una ruta cupieran en el vehículo al regresar. El modelo de búsqueda sí limitaba la carga neta en cada punto, pero había omitido un límite por ruta para el total de recolecciones.
Agregar ese límite, que siempre había sido necesario desde el punto de vista lógico, llevó la certificación interna de unas 50 a 100 paradas.

Fue, al mismo tiempo, un éxito de especificación y una falla de implementación. La regla de negocio existía. El motor no la aplicaba completa. El razonamiento independiente y la escalera de benchmarks hicieron visible la omisión antes de liberar el producto.

6.6. El paso de 100 a 200 era un problema de sesgo de búsqueda

Con 200 paradas distribuidas en ocho vehículos apareció otra falla en los diagnósticos. Alrededor de veinticinco paradas por vehículo, la búsqueda guiada por costos de arco intercalaba entregas y recolecciones con tanta agresividad que la carga superaba la capacidad a mitad de la ruta, incluso en instancias construidas para contener un orden factible. La mediana del exceso era de cuatro unidades.

Reordenar las paradas rescató todas las rutas con exceso de capacidad que examinamos. Eso cambió el diagnóstico: al motor no le faltaba una cota de factibilidad; la búsqueda estaba sesgada en contra de la estructura factible que ya existía dentro de las instancias.

La corrección fue una penalización blanda que favorecía entregar antes de recoger cuando había más de quince paradas por vehículo. Las instancias pequeñas quedaron intactas y producían exactamente los mismos bytes con la funcionalidad apagada. Con ese sesgo, el motor pasó el punto de control de 200 paradas en cinco semillas generadas y fijas.

También corregimos el generador del benchmark. Estaba produciendo demasiadas entregas puras y demasiadas recolecciones puras, mientras que la operación real tiene sobre todo paradas de intercambio: se entrega un cilindro lleno y se recoge uno vacío en la misma visita. Una afirmación de escalabilidad solo es tan útil como la distribución de datos que la respalda. El punto de control final usó instancias factibles por construcción, más parecidas a la operación que se pretendía modelar, aunque seguían siendo un benchmark sintético interno y no una validación en producción.

6.7. La medición redirigió el esfuerzo de optimización

Durante buena parte del sprint cargué con un temor: congelar los costos de tráfico podía introducir un error del 7 al 10 %. El punto de control de residuales separó dos cantidades que estaban escondidas bajo la misma palabra:

El residual de la estimación congelada —la parte que un ciclo iterativo de tráfico sí podría mejorar—tuvo una mediana cercana al 0,2 %, un máximo de 2,8 % con la amplitud de tráfico de referencia y 5,1 % bajo amplitudes deliberadamente exageradas.
El residual total de los planes entregados estuvo entre 1,4 % y 23,5 %, dominado por la variación de la búsqueda. En el peor caso, la heurística usó cuatro vehículos cuando el óptimo usaba tres.

La búsqueda local guiada, limitada por tiempo de reloj, no era reproducible byte por byte entre máquinas.
El mecanismo iterativo sofisticado que casi construimos atacaba el error pequeño y estable, mientras dejaba intacto el error grande y dependiente de la máquina.

El informe del sprint lo resumió mejor que cualquier abstracción: la estimación congelada es barata; la búsqueda es costosa; y el ciclo sofisticado ataca la primera, no la segunda.

6.8. El sistema de estado sobrevivió una falla física

El 12 de julio, la estación de trabajo se apagó por sobrecalentamiento. Se perdieron cambios en los documentos locales de estado y auditoría de AI-DLC que todavía no tenían commit. Las entradas recientes del usuario se
restauraron literalmente cuando fue posible; el resto del vacío se reconstruyó como resumen y quedó declarado de forma explícita.

La falla expuso una debilidad del proceso: habíamos dejado sin commit los cambios de estado y auditoría durante demasiado tiempo. También validó la forma en que Normandy había definido las fuentes oficiales del proyecto. El estado de los tickets y las solicitudes de integración en GitLab seguía intacto. El código ya registrado en Git también. Los constructores no tenían permiso para modificar el registro central. Después del incidente, empezamos a hacer commit con mayor frecuencia a los cambios de estado y auditoría.

6.9. La noche autónoma fue una excepción, no la conclusión.

Cuando terminamos el MVP y las tareas de pruebas integrales, todavía necesitaba una interfaz demostrable que usara resultados reales del solver. Era tarde, yo estaba agotado y quedaban cinco tareas de integración del demo. Autoricé explícitamente a Normandy para ejecutar ese bloque acotado durante la noche e integrar solo después de cerrar las revisiones sin hallazgos bloqueantes, manteniendo el límite de rondas antes de escalar.

Se integraron cinco funcionalidades sin que ninguna tuviera que escalarse. El ciclo combinado de constructores, orquestador y revisores encontró y corrigió cuatro problemas de integración antes de hacer merge: exports de servicios en conflicto, una falla de idempotencia cuando la captura no encontraba resultados, la omisión del tramo de regreso al depósito en la distancia reportada y un componente de Angular que todavía consumía datos
sintéticos en lugar de los datos reales del solver.

A la mañana siguiente hice la verificación visual en navegador que los agentes no habían podido completar en su entorno. El demo mostraba trayectorias reales, precalculadas y cargadas previamente, para problemas de 20, 50 y 100 paradas. No resolvía en vivo desde el navegador y los coeficientes usados para mostrar costos eran sintéticos.

No interpreto esa noche como evidencia de que debamos eliminar la aprobación humana. Para mí demuestra que una persona puede tomar una decisión operacional acotada sobre cuándo bastan los controles automáticos, siempre que la autoridad, el alcance, la regla de escalamiento y la verificación posterior queden explícitos.

7. Lo que entregamos

Entre el 8 y el 13 de julio de 2026, el proyecto pasó de un repositorio con especificación completa y sin una implementación aceptada del MVP a tener:

Siete unidades implementadas y seis tareas de pruebas integrales terminadas.
Treinta y dos commits de integración en la rama principal: veintisiete integrados por una persona y cinco integrados automáticamente bajo la autorización nocturna y acotada.
Un pipeline de optimización consumible por API que cubría ingreso, persistencia, preparación canónica, resolución, validación independiente, orquestación y entrega firmada de resultados.
Certificación interna para 200 paradas en ocho vehículos sobre cinco semillas fijas, generadas y factibles por construcción.
Una distinción explícita entre «no se encontró una solución dentro del presupuesto» e infactibilidad estructural.
Un registro medido de la decisión sobre el diseño degradado dependiente del tiempo y una interfaz para agregar solvers futuros.
Una interfaz de demostración que usaba resultados reales calculados fuera de línea y la trayectoria cronológica de mejora, en lugar de una animación inventada.

La propiedad central observada fue el invariante de nunca entregar un plan inválido: en el corpus de aceptación y en los benchmarks ejecutados, el motor podía no encontrar un plan, pero no entregó ninguno que el independiente rechazara. Esta afirmación es deliberadamente más estrecha que una demostración formal. Describe las pruebas que corrimos, no todos los problemas que el motor podría encontrar.

8.Lo que me llevaría a la siguiente construcción con agentes

8.1 Tratar la calidad de la especificación como infraestructura

La mayor contribución de AI-DLC a este proyecto no fue generar código. Fue producir una especificación detallada y conectada internamente antes de que los constructores empezaran a amplificar su contenido.
Las especificaciones hechas por personas suelen depender de reparaciones tácitas durante la implementación.

Eso puede funcionar con un equipo estable que comparte contexto. Es una suposición peligrosa cuando los agentes solo reciben el paquete de trabajo escrito y pueden implementar una ambigüedad de manera convincente. Requisitos, historias, reglas de negocio, modelos de dominio, límites entre unidades y propiedades de aceptación deberían coincidir antes de construir; no porque todos los diseños sobrevivan intactos al código, sino porque así cualquier desviación se vuelve una decisión de ingeniería explícita.

AI-DLC no eliminó la necesidad de saber especificar. Le dio más alcance a esa habilidad. Yo todavía tenía que conocer el dominio, tomar decisiones de producto, rechazar la falsa precisión y aprobar el resultado.
El proceso me ayudó a sacar más de ese conocimiento de mi cabeza, encontrar contradicciones y dejar menos intención esencial sin escribir.

8.2. Permitir que los experimentos contradigan diseños aprobados

El diseño dependiente del tiempo había pasado varios puntos de aprobación. El spike definido de antemano lo descartó de todas formas. Una especificación debe ser la referencia obligatoria sobre el comportamiento requerido y las decisiones vigentes, sin volverse inmune a la evidencia. Definir los criterios antes de experimentar hizo que el cambio de rumbo fuera disciplinado, no arbitrario.

8.3. Usar paneles de IA para ampliar la investigación, no para establecer hechos

Los paneles encontraron una contradicción fundamental en la función objetivo y más adelante inventaron API inexistentes del solver. Ambos resultados surgieron de la misma capacidad: producir razonamientos plausibles desde varias perspectivas. Los paneles sirven para generar objeciones e hipótesis. Las afirmaciones sobre dependencias deben contrastarse con el software instalado, y las recomendaciones deben evaluarse con mediciones.

8.4. Construir programas separados para riesgos separados

El validador fue valioso porque no compartía la implementación del optimizador. La barrera que prohibía importaciones de código (imports) hacía cumplir esa independencia. La revisión, las pruebas y la atención humana importan, pero ninguna reemplaza un programa determinista que verifique exactamente la falla que la arquitectura teme.

8.5. Mantener acotados a los agentes y tener una sola autoridad para el estado

Un ticket, una rama y una solicitud de merge hicieron que el progreso fuera inspeccionable. Los constructores puros y los revisores de solo lectura limitaron el alcance de un error. Una sola autoridad mantuvo coherente el estado del flujo. Esas restricciones redujeron la autonomía local y volvieron más operable el sistema completo.

8.6. La persona es la fuente del propósito, no solo de la aprobación

Comencé el sprint pensando que el papel principal de la persona era servir como punto final de aprobación. En la práctica, el papel más importante era decidir qué importaba. Los agentes podían optimizar un arnés de pruebas, perseguir un diseño que ya no servía o resolver con gran persistencia la pregunta equivocada.
Yo tenía que recordar por qué existía la tarea, reagrupar el trabajo y, a veces, declarar que un objetivo aparentemente válido ya no merecía más tiempo.

La aprobación humana también fue el principal cuello de botella. Esa es una razón para proteger la atención de la persona, mantener los cambios pequeños y mejorar la visibilidad; no para eliminar automáticamente el punto de aprobación.

8.7. La visibilidad también es una funcionalidad de orquestación

Más de una vez, un agente terminó su tarea y quedó esperando sin que yo lo notara. Las horas perdidas no fueron fallas de cómputo ni del modelo: fueron fallas al comunicar «terminé, estoy esperando una decisión».
Mejorar las notificaciones y la visibilidad de las colas es la funcionalidad operacional pendiente más
valiosa de Normandy.

8.8. El disfraz me ayudó a sostener el trabajo

Los personajes hicieron que la semana fuera más fácil de entender y más entretenida. Ese efecto importa incluso si nunca mejora un benchmark. Los sistemas de ingeniería son operados por personas, y mantener la atención también hace parte de su desempeño. Sigue abierta la pregunta de si la tematización mejora la calidad del resultado o solo —que ya sería útil— la capacidad del operador para mantenerse involucrado.

9. Límites de este informe

Este es un solo proyecto con un único participante humano. Yo fui, al mismo tiempo, responsable de producto, arquitecto, operador del pipeline y evaluador. Hay sesgos de selección, de memoria y de confirmación en todo el relato.

El proyecto también empezó con ventajas que no se transfieren automáticamente. La especificación es una de mis fortalezas, y yo ya tenía más de una década de familiaridad con el dominio operacional, adquirida entre 2008 y 2021. AI-DLC ayudó a sacar ese conocimiento de mi cabeza y ponerlo a prueba; no lo creó.
No hubo una línea base controlada. No puedo afirmar cuánto habría tardado el mismo ingeniero en construir el mismo sistema usando bien una plataforma de orquestación existente, agentes sin temática, un equipo humano convencional o ningún agente. Las comparaciones de tiempo y tokens del primer intento fueron observaciones operacionales, no un experimento controlado.

El resultado de 200 paradas es una certificación interna sobre instancias generadas, factibles por construcción y cinco semillas fijas. No es una certificación externa, una demostración exhaustiva ni una validación contra rutas históricas de entrega de oxígeno. La búsqueda local guiada está limitada por tiempo de reloj y puede cambiar entre máquinas. El demo usa resultados precalculados y coeficientes sintéticos para mostrar costos.
Finalmente, la bitácora de auditoría contiene un intervalo reconstruido y declarado después de la falla del 12 de julio. Las entradas recientes se restauraron literalmente cuando fue posible; el resto es un resumen, no un registro primario completo.

10. Hacia dónde sigue el trabajo

Para Orbital, el siguiente punto de control que realmente importa es operacional: reproducir el motor sobre rutas históricas, comparar sus decisiones contra planes y costos reales, y luego ejecutar un piloto controlado. La arquitectura conserva un camino hacia el ciclo iterativo corregido para tráfico, solvers genéticos y de inspiración cuántica y, eventualmente, hardware cuántico real. Todo eso pertenece a la hoja de ruta; no son afirmaciones sobre el MVP.

Para Normandy, la necesidad inmediata es visibilidad: avisar con claridad cuándo un agente terminó, cuándo hay una revisión esperando y cuándo una decisión humana está bloqueando la cola. Una librería de temas reutilizables, puntos y estadísticas por agente siguen siendo experimentos opcionales. La pregunta de investigación interesante es si los pipelines con personajes y elementos de juego cambian la calidad de la ingeniería o si «solo» mejoran la capacidad de quien los opera para mantenerse involucrado. También consideraría valioso ese segundo resultado.

Para AI-DLC, la siguiente pregunta que probaría es la transferencia de especificación. Este proyecto sugiere que el método puede convertir conocimiento sólido del dominio y buenas prácticas de especificación en un contrato de mayor calidad para los agentes. Todavía no dice qué tan bien funciona cuando el dominio es desconocido, la intención inicial es débil o varias personas no están de acuerdo sobre el producto.

11. Conclusión

Comencé con un motor de ruteo por construir y una metodología por probar. Terminé con una idea mucho más precisa sobre el desarrollo con agentes.

El código apareció rápido porque buena parte del pensamiento difícil ya había sido obligada a salir a la superficie. AI-DLC hizo que la especificación —la parte de la ingeniería que yo ya consideraba una fortaleza— fuera más explícita, más coherente internamente y más útil como contrato de construcción.
Normandy convirtió después ese contrato en una operación: constructores acotados, revisiones independientes, una sola autoridad para el estado y cambios que se podían inspeccionar.

Ninguno de los dos sistemas volvió confiables a los agentes por definición. El proyecto salió adelante porque esperábamos fallas plausibles: un diseño aprobado murió en un spike; los expertos inventaron API; una restricción faltante limitó la escala; y una optimización aparentemente sofisticada apuntaba al error más pequeño. La medición, la validación independiente y la responsabilidad humana cambiaron el rumbo cada vez.
Por eso, cinco días y medio no son la lección. La lección es que la velocidad de los agentes solo se vuelve útil cuando la intención está explícita y las fallas se pueden observar. Los métodos que importaron fueron virtudes conocidas de la ingeniería de software —especificación, revisión, medición, independencia y responsabilidad— adaptadas a herramientas capaces de construir más rápido de lo que una ambigüedad puede sobrevivir sin causar daño.

Apéndice A — Cronología

Fecha (2026)	Evento
22 de junio	Revisión adversarial de cinco agentes; encontró la contradicción del objetivo y ayudó a nombrar R-11
24 – 27 de junio	Inception de AI-DLC: requisitos, historias, flujo, diseño de aplicación y siete unidades
2 – 3 de julio	Modelo matemático construido con agentes, revisado de forma adversarial y bloqueado
2 – 4 de julio	Diseños funcionales, no funcionales y de infraestructura aprobados; planes de código terminados
7 – 8 de julio	Tickets de construcción creados; terminó el intento con el stack prestado; Normandy quedó operativo
8 de julio	Primer andamiaje aceptado e integrado; el MVP avanzó según el grafo de dependencias
10 de julio	El spike descartó los diseños nativo e iterativo; quedó bloqueado el plan degradado
12 de julio	Se midieron las recomendaciones del panel; la falla de la estación expuso el vacío de cambios sin commit en la auditoría
13 de julio	El punto de control llegó a 200 paradas; terminaron las pruebas integrales; corrió el bloque de integración del demo
Desde el 13 de julio	Verificación en navegador, presentación y reconciliación factual del registro del proyecto

Apéndice B — El contrato de optimización bloqueado

El cuerpo principal deja el modelo matemático fuera del recorrido narrativo. Este apéndice conserva la función objetivo y las distinciones de implementación que determinaron las decisiones de construcción. La definición completa de símbolos y familias de restricciones vive en el documento bloqueado del modelo.
La función objetivo bloqueada fue:
$$\min_{x,,y}; \sum_{k \in \mathcal{K}} \Biggl[, c^{fij}k y_k + \sum{(i,j)} \mu_{ijk}(\theta_i)x_{ijk} + c^{OT}k O_k \Biggr] + \Lambda{eq}V$$
donde:

$x_{ijk}$ indica que el vehículo $k$ recorre el arco $(i,j)$, y $y_k$ indica que se despacha.
El costo fijo de despacho hace que el tamaño de la flota surja del costo, dentro de límites mínimo y máximo configurados.
$\mu_{ijk}(\theta)$ combina el costo de distancia y tiempo de conducción para un arco que se inicia en el instante $\theta$.
$c^{OT}_k$ es la tarifa de hora extra y $O_k$ es el tiempo extra sobre la jornada productiva ordinaria.
$V$ representa la violación de equidad cuando esa opción está activa.

La equidad estricta usa optimización lexicográfica en dos pasadas; la equidad suave asigna un costo a la violación; y, si el cliente no define una tolerancia, la equidad se reporta pero no se optimiza. El costo reportado al cliente excluye el pseudocosto de equidad y se vuelve a calcular usando las horas reales de salida de la ruta.

Los invariantes duros de entrega incluyen cobertura exacta de paradas, integridad de rutas ancladas al depósito, capacidad por tipo de equipo en cada parada, peso del vehículo, propagación válida del tiempo y una carga inicial igual a todas las entregas asignadas a la ruta. Las restricciones humanas, como horas extra, ubicación del almuerzo y equidad, producen advertencias o preferencias de ordenamiento; nunca eliminan trabajo en silencio.

Apéndice C — Terminología

Término	Significado
AI – DLC	AI-Driven Development Life Cycle, metodología de especificación por etapas y con aprobación humana
VRPSPD	Vehicle-Routing Problem with Simultaneous Pickup and Delivery, problema donde cada parada puede recibir y devolver carga
PRD	Product Requirements Document, documento aprobado que define qué debe hacer el producto
PHI	Personal Health Information, información personal de salud que el contrato de Orbital no admite
R – 11	Riesgo del proyecto de producir un resultado incorrecto con apariencia convincente
OR – Tools	Conjunto de herramientas de investigación de operaciones de Google, de código abierto, usado por el MVP
GLS	Guided Local Search o Búsqueda Local Guiada, metaheurística del solver limitada por tiempo de reloj
Plan degrado	Búsqueda con costos congelados seguida de una reevaluación exacta dependiente del tiempo
Validador	Verificador determinista de planes implementado de forma independiente en U5
Normandy	Pipeline multiagente de construcción centrado en GitLab

Nota sobre la memoria narrativa complementaria

Este proyecto también produjo Orbital — Bitácora de un Comandante, una memoria narrativa del mismo sprint contada dentro del universo de Mass Effect. Conserva los hechos de ingeniería, pero se toma libertades declaradas con la ambientación, la continuidad y la escala. Quien quiera leer la construcción con su registro emocional puede ir allí; uno de sus apéndices conecta la ficción con el registro real. (Enlace pendiente para publicación.)

Agradecimientos

Al programa Hardcore AI de 30X, Cohorte 3, en cuyo crisol ocurrió este sprint.