Un ingeniero entrega 2.000 pull requests al mes a produccion: la clave es la verificacion

Lauren Tan, ingeniera del equipo de Grok en SpaceXAI y antes en Cursor y Meta, ha publicado pstack, la guia de su flujo de trabajo personal con agentes de codigo. El numero que ha llamado la atencion es que con el ha llegado a entregar 2.000 pull requests al mes a produccion, casi cien por jornada laboral y, segun su propio relato, con alta confianza. La cifra es atipica y sale de ella, no de una medicion externa, pero la direccion no pilla por sorpresa a quien siga el sector.

Para Tan, lo que sostiene todo eso no es el modelo que escribe el codigo, sino la verificacion. Una skill de verificacion permite al agente comprobar su propio trabajo y seguir hasta terminar la tarea, y ella la trata como infraestructura critica, no como una habilidad mas de la lista.

Un runtime que el agente pueda manejar

Debajo de esa skill hay algo mas terrenal: un entorno que el agente pueda arrancar, inspeccionar y del que reciba respuestas estructuradas. En su caso, la skill genera una CLI y un mapa de funcionalidades de la aplicacion. El agente arranca la app, navega, consulta el estado y lee resultados en JSON. Cada agente trabaja sobre una copia completa y prueba el cambio de extremo a extremo.

Eso funciona porque su aplicacion cabe en un proceso. Un frontend, un compilador o un servicio con su base de datos arrancan desde la linea de comandos en segundos y se tiran despues. Tan es explicita: dice que construiria herramientas de depuracion propias, o incluso elegiria otro stack, con tal de tener esa ventaja al desarrollar. La afirmacion es suya y no viene acompanada de ninguna demo.

El argumento de fondo es de caudal. Un agente que se verifica solo no para hasta acabar; uno que no puede y tiene que devolverte un diff y esperar te convierte en el cuello de botella. De ahi su estimacion de multiplicar por 100 o por 1.000 la produccion de un equipo. Con 2.000 PRs al mes, revisar a mano cada uno daria unos cinco minutos por cambio en un mes completo, asi que la revision humana no puede ser la capa de verificacion.

El muro de los sistemas distribuidos

Ahi esta el problema para casi todo el mundo. Una aplicacion distribuida es la interaccion entre un servicio de pedidos, uno de pagos, inventario, una cola, varias bases de datos y unas cuantas APIs de terceros; en organizaciones grandes, miles de piezas. La CLI levanta el servicio modificado, no el sistema.

Las alternativas conocidas fallan por lados distintos. Los mocks son baratos y paralelizan bien, pero codifican lo que la dependencia hacia la ultima vez que alguien miro, y se desvian en cuanto el servicio real cambia. Una copia completa del stack es fiel, pero su coste escala con el numero de servicios multiplicado por los cambios simultaneos. El staging compartido es fiel y barato porque solo hay uno, y por eso mismo no aguanta cientos de cambios concurrentes: los agentes se pisan los despliegues y el fallo de uno se convierte en tests rotos para todos.

Leido como documento de requisitos, el flujo pide cinco cosas: dependencias reales, aislamiento entre cambios, coste proporcional al tamano del cambio y no al del sistema, entornos listos en segundos y todo accesible por la CLI o el servidor MCP que el agente ya usa. Realismo y coste tiran en direcciones opuestas, y ahi sigue el debate abierto. Quien resuelva ese par tendra la infraestructura que el resto intentara copiar.