El fin de semana en que un agente autónomo lanzó diez subsistemas

Un motor construido POR agentes desde el primer día sale con una forma distinta a uno donde la IA se atornilla encima. Esa forma es exactamente la que necesita un runtime cuando la IA es una primitiva, no una funcionalidad al lado.

Abrí la laptop el sábado por la mañana. El repositorio del runtime había recibido 139 commits durante la noche. La mayoría los aportó un agente de codificación autónomo que había estado trabajando contra una cola de incidencias que archivé el fin de semana anterior. Diez pull requests del tamaño de subsistemas, todas listas para revisión.

Cuando la gente me pregunta cómo es realmente construir un runtime 3D con agentes de IA en el equipo, suelen asumir una de dos cosas. O los agentes son autocompletado disfrazado con un panel de chat, o son una funcionalidad que se agrega después, una vez que el «motor real» ya fue construido por humanos.

Ninguna es la versión en la que estoy sentado este fin de semana.

A lo largo del sábado y el domingo, el repositorio del runtime recibió 139 commits. 110 de ellos fueron escritos por un agente autónomo. 20 fueron bajo la cuenta BladeWireless de la era fundacional. 10 fueron míos. A lo largo de esos 139 commits, llegaron diez pull requests del tamaño de subsistemas:

• Sistema de animación esquelética
• API de edición de escena en tiempo de ejecución
• Serialización de escena
• Occlusion culling
• Streaming de niveles
• Sistema de prefabs
• Sistemas de partículas por GPU
• Renderizado avanzado
• Sistemas de terreno y entorno
• Pipeline de posprocesado

Ninguno de esos subsistemas es IA. Son las piezas aburridas y estructurales que un runtime 3D necesita para ser un runtime 3D. Y se lanzaron en un solo fin de semana, en ramas paralelas, escritas en su mayoría por un agente que corría de forma autónoma mientras yo enmarcaba, revisaba, y fusionaba.

Esta es la entrada sobre lo que significa que los cimientos se estén construyendo POR agentes, no construidos PARA agentes.

La diferencia está en cada decisión arquitectónica

Hay una versión de esta historia en la que construyes un motor «normal» de la forma en que siempre se han construido los motores, y luego añades IA encima. La IA llega como una funcionalidad. Se atornilla. Vive fuera del motor porque el motor no fue diseñado para alojarla. Ese es el patrón dominante en la industria en este momento, y no es un patrón equivocado. Es solo el que obtienes cuando decides cómo debe verse el motor antes de que la IA esté en el equipo de desarrollo.

Cuando los agentes de IA están en el equipo desde el primer día, la forma del motor sale distinta. Cambian tres cosas.

Uno. Cada subsistema se lanza a través de revisión de código. Porque los agentes tienen que participar en el ciclo de revisión, el ciclo tiene que aceptar diffs escritos por agentes. Cada PR. Cada diff. Cada fusión. Esa disciplina no solo habilita a los agentes. También resulta ser exactamente la disciplina que quieres si la IA alguna vez va a ser una primitiva del runtime en lugar de una funcionalidad del editor. El mismo pipeline de revisión que atrapa la errata de un agente en un encabezado de culling atrapará la errata del agente en un árbol de comportamiento. Al pipeline no le importa en qué capa de la pila vive.

Dos. Cada subsistema tiene interfaces públicas limpias. Múltiples agentes trabajando en múltiples subsistemas en paralelo producen conflictos infusionables cada vez que las fronteras son difusas. El remedio es trazar las fronteras con firmeza antes de que nadie escriba código. Una vez que las fronteras son firmes, los subsistemas se vuelven direccionables desde cualquier lugar, que es exactamente lo que necesitas si quieres que el motor aloje comportamientos de IA que puedan invocar el resto del runtime sin acoplamiento.

Tres. Cada subsistema es comprobable de forma independiente. Un sábado de 139 commits no se puede probar a mano. Las pruebas tienen que llegar con el diff o el diff no se fusiona. Así es como el humano en el ciclo confía en el diff en absoluto. El efecto secundario es una superficie de pruebas que permite intercambiar implementaciones sin reescribir a quienes las invocan, que es la disciplina que un motor necesita para evolucionar.

Ninguna de estas es una funcionalidad de IA. Son consecuencias del proceso de desarrollo de tener agentes en el equipo. El proceso de desarrollo moldea la arquitectura.

Cómo se ve realmente el flujo de trabajo

El patrón que produjo este fin de semana:

• Yo enmarqué qué subsistemas necesitaba el motor a continuación.
• Un agente autónomo corrió en paralelo a través de diez ramas, cada una implementando un subsistema.
• Cada rama produjo una PR con implementación, pruebas, y documentación.
• Yo revisé y fusioné. Donde el agente se equivocó en algo, cerré la PR o pedí cambios.

Lo que me impacta, sentado aquí al final del fin de semana, es cuánto de esto ya funciona. El ciclo de desarrollo es el ciclo de desarrollo. El agente está haciendo el trabajo para el que hace cinco años habría contratado a diez personas. Yo hago el juicio arquitectónico y las decisiones de fusión. Es un tipo distinto de fin de semana largo de los que solía tener.

El agente autónomo en este fin de semana en particular no es una pila multiproveedor de cuatro asistentes. Es un solo agente (el agente SWE de Copilot) corriendo a través de muchas tareas paralelas. Espero que el patrón multiasistente llegue, y que llegue rápido. El patrón ya está aquí en forma de un solo agente.

Lo que es difícil

Honesto al respecto, porque es genuinamente difícil.

Los agentes no son gratis. Un fin de semana de 139 commits tiene un costo de revisión de 139 commits. Cada PR necesita atención real porque los subsistemas son desconocidos y no puedo hojearlos. Estoy cansado. La fatiga es real y vale la pena presupuestarla.

Confiar en un agente autónomo con trabajo novedoso es una habilidad. El agente SWE de Copilot que lanzó la mayoría de los subsistemas de este fin de semana es bueno. No es infalible. La habilidad está en saber cuándo fusionar rápido, cuándo frenar, y cuándo descartar un borrador. Ya he fusionado cosas que debería haber vuelto a generar. Estoy aprendiendo pagando el costo.

La arquitectura tiene que bosquejarse antes de que corran los agentes. Dale a un agente el prompt «constrúyeme un renderizador» y obtendrás un renderizador que no encaja con el resto de tu motor. Dale «implementa un subsistema de occlusion culling que exporte esta API en C y se integre con el grafo de escena a través de estos handles» y obtienes algo que encaja limpiamente. El trabajo de enmarcar es el trabajo. El agente hace la tipeada.

Las pruebas no son negociables. Casi dejé que una de las PRs de este fin de semana se fusionara con cobertura de pruebas escasa. Esa es una regresión futura que estoy comprometiéndome en silencio a combatir. El remedio es hacer que el requisito de pruebas sea parte del prompt del agente desde la primera línea.

Lo que me llevo del fin de semana

Dos observaciones.

Los agentes obviamente van a seguir mejorando. Más rápidos, más precisos, capaces de sostener más del motor en una sola cabeza. Esa es la predicción fácil.

La predicción menos fácil es qué le pasa al rol humano dentro de este flujo de trabajo. Ya no es el rol para el que me entrené como ingeniero senior. Menos tipeada, más enmarcado. Menos síntesis, más selección. Menos «soy el cuello de botella en esta línea de código» y más «soy el cuello de botella en la decisión arquitectónica que determina si valía la pena correr esta rama».

Eso es un trabajo distinto. Usa músculos distintos. Creo que los músculos que usa son inusualmente transferibles entre dominios, y creo que las personas que los desarrollen en los próximos dos años van a mirar al resto de la industria de la misma forma en que la industria mira hoy a quienes todavía construyen sin control de versiones.

Eso es más que suficiente reflexión para un fin de semana.

Cierro la laptop el domingo por la noche. De vuelta a ello el próximo sábado.