Casi todos los equipos que adoptan agentes de código cambiaron una cosa: la velocidad a la que se escribe el código. Conservaron todo lo demás. Mismos roles, mismos artefactos, misma cadencia, ahora con un agente atornillado que produce diez veces el output. Y se sorprenden cuando el resultado no es diez veces el valor sino diez veces el lío, porque el modelo operativo alrededor del agente estaba diseñado para un mundo donde escribir código era el paso lento y caro, y ese mundo desapareció.
Un modelo operativo son tres cosas. Quién hace qué. Qué produce el trabajo. Cómo se mueve el equipo por el tiempo. Roles, artefactos, ritmo. Cuando los agentes asumen la construcción, los tres tienen que cambiar, y cambiar tus herramientas sin cambiar tu modelo operativo es como llegas al lío. Este es un relato concreto de en qué se convierten los tres.
Roles: el humano posee el contrato y la puerta, no las pulsaciones
La vieja división del trabajo ponía al humano en medio de la producción. El PM escribía requisitos, el ingeniero escribía código, y el valor que cada uno añadía se medía en los artefactos que tecleaba en persona. Los agentes quitan esa medición, porque teclear ya no es el recurso escaso. Lo que sigue escaso es el juicio sobre qué construir y sobre si lo construido está bien, y ahí es donde se reubican los roles humanos.
La persona de producto deja de ser la autora de requisitos y pasa a ser la dueña del contrato y del bucle de decisión. Su trabajo es mantener legible y al día la definición de qué significa «correcto» mientras los agentes construyen contra ella, y sostener las decisiones, con su evidencia, para que el equipo no rediscuta preguntas ya zanjadas. Es el desplazamiento que describí en product management en la era IA: de escribir la spec a diseñar el sistema que decide y aprende.
El ingeniero deja de ser quien produce el código y pasa a ser quien posee el harness y la puerta. Diseña el entorno en el que corren los agentes, los chequeos que un cambio tiene que pasar, la vía de recuperación cuando una ejecución falla. Su palanca ya no son líneas escritas, es la calidad de la máquina que convierte specs en código verificado, y la fuerza de la puerta que rechaza el trabajo que no puede demostrarse.
Ninguno de los dos roles se encogió. Los dos subieron un nivel, de producir el artefacto a poseer el sistema que lo produce. Un equipo que sigue evaluando a estas personas por cuánto teclean en persona está midiendo lo que no toca y se dotará de personal para el trabajo equivocado.
Artefactos: la spec, la decisión, la evidencia
Los viejos artefactos eran el PRD y el roadmap. Los dos se construyeron para un mundo lento. El PRD describía una feature una vez, en prosa, y envejecía el día que empezaba la construcción. El roadmap proyectaba certeza sobre meses que la velocidad de los agentes vuelve ficción. Ninguno sobrevive al contacto con un equipo que publica varios cambios validados por semana.
Tres artefactos los reemplazan, y están vivos en vez de estáticos.
La spec es el contrato contra el que construye el agente, precisa lo bastante para restringir la construcción y legible por el propio agente, no solo por el ingeniero. Donde el viejo PRD era un documento para alinear humanos, la spec es una instrucción que tiene que llegar a la máquina que hace el trabajo, y por eso existe un estándar como AGENTS.md: el contrato tiene que vivir en un sitio que el agente lea de verdad.
El decision ledger reemplaza al roadmap. En vez de proyectar una secuencia fija de features, registra qué se decidió, sobre qué evidencia, bajo qué supuesto, según el equipo aprende. Es una memoria de elecciones y no una promesa de fechas, que es el único artefacto real cuando construir es lo bastante rápido para que la secuencia cambie cada semana.
El registro de evidencia reemplaza al informe de estado. Un cambio se cierra con la prueba de qué corrió y qué pasó adjunta, para que el estado del producto sea algo que el equipo pueda leer en vez de creerse por fe. El estado se declara; la evidencia se captura, y en un mundo donde el autor es a menudo un modelo, solo la clase capturada puede confiarse después.
Debajo de los tres está el tejido conectivo, el grafo de conocimiento de producto que relaciona specs, decisiones, evidencia y código, para que los artefactos no sean tres montones separados sino un mapa que puedes recorrer. Sin eso, tienes artefactos nuevos y la misma vieja desconexión.
Ritmo: un bucle apretado, corrido muchas veces en paralelo
El viejo ritmo era el sprint: un lote de trabajo planificado, construido en una ventana fija, revisado al final. Asumía que construir era el palo largo, así que organizaba el tiempo alrededor de darle a la construcción pista suficiente. Quita ese supuesto y el sprint deja de tener sentido, porque el palo largo ya no es la construcción.
El ritmo que encaja es un bucle apretado corrido de forma continua y a menudo en paralelo. El discovery produce un insight. El insight fuerza una decisión. La decisión se vuelve una spec. La spec va a un agente. El output del agente choca con una puerta de verificación. Lo que pasa actualiza el decision ledger y alimenta el siguiente bucle. El tiempo de ciclo es horas, no semanas, y varios bucles corren a la vez, y por eso los roles humanos se movieron hacia poseer contratos y puertas: a este tempo, una persona no puede estar en medio de cada pulsación, solo en los bordes donde vive el juicio.
Aquí es donde la investigación de entrega sigue siendo relevante. El programa DORA lleva años mostrando que el flujo rápido solo produce buenos outcomes cuando corre a través de una verificación fuerte, y que el throughput sin estabilidad degrada los resultados en vez de mejorarlos. Los agentes hacen el flujo rápido gratis. El modelo operativo tiene que aportar la estabilidad, o la velocidad solo acelera el daño, la misma trampa donde construir barato se vuelve deuda de producto barata.
El modo de fallo: herramientas nuevas, modelo viejo
El error más común con diferencia es mejorar las herramientas y dejar el modelo operativo intacto. Un equipo compra agentes, conserva el PRD y el roadmap y el sprint, sigue midiendo a la gente por output, y apunta los agentes al mismo proceso que se construyó para la construcción lenta. Lo que consigue es el modelo viejo corriendo más rápido, lo que significa que sus debilidades componen más rápido también: más PRDs sin leer, más ficción de roadmap, más output sin verificar, más decisiones que nadie puede reconstruir.
Las herramientas son la parte fácil de cambiar. El modelo operativo es la parte difícil, porque toca cómo se evalúa a la gente, qué considera el equipo un entregable, y cómo planifica el tiempo, y esos son hábitos que sostienen la casa. Pero las herramientas sin el modelo son exactamente la configuración que produce velocidad que no puedes dirigir.
Dónde encaja PaellaDoc
PaellaDoc está construido alrededor de este modelo operativo en vez de atornillado al viejo. La spec, el decision ledger y la evidencia viven como artefactos conectados en un solo grafo, el bucle del discovery al cambio verificado corre en local, y el humano se queda donde pertenece el juicio, en el contrato y la puerta, mientras los agentes hacen la construcción dentro de él. El objetivo no es hacer más rápido el viejo proceso. Es darles a los nuevos roles, artefactos y ritmo un sitio donde vivir, para que la velocidad venga con control en vez de en su lugar.
Los agentes cambiaron lo que es escaso. Un equipo que rediseña su modelo operativo alrededor de la nueva escasez, juicio y verificación en vez de producción, convierte la velocidad en outcomes. Un equipo que conserva el modelo viejo solo consigue cometer sus errores viejos a un ritmo que ya no puede seguir.
Preguntas frecuentes
¿Qué es un modelo operativo de producto?
Son tres cosas: quién hace qué (roles), qué produce el trabajo (artefactos) y cómo el equipo se mueve por el tiempo (ritmo). La versión tradicional, el PM escribe requisitos, el ingeniero escribe código, el trabajo en lotes de sprints, se diseñó para un mundo donde escribir código era el paso lento y caro. Cuando los agentes asumen la construcción, los tres tienen que cambiar, porque el supuesto sobre el que se construyeron desapareció.
¿Cómo cambian los roles cuando los agentes construyen?
Teclear deja de ser el recurso escaso, así que los dos roles humanos suben un nivel. La persona de producto deja de escribir requisitos y posee el contrato y el bucle de decisión, manteniendo «correcto» legible y al día mientras los agentes construyen contra ello. El ingeniero deja de producir código y posee el harness y la puerta, el entorno donde corren los agentes y los chequeos que un cambio debe pasar. Ninguno se encogió; los dos dejaron de medirse por output.
¿Qué reemplaza al PRD, el roadmap y el sprint?
Tres artefactos vivos y un ritmo más apretado. La spec, un contrato que el propio agente puede leer, reemplaza al PRD. El decision ledger, una memoria de qué se decidió y por qué, reemplaza la secuencia fija del roadmap. El registro de evidencia, prueba de qué corrió y qué pasó, reemplaza al informe de estado. Y el sprint cede a un bucle apretado, discovery a spec a construcción a verificación, corrido en horas y en paralelo.
¿Por qué las herramientas de IA producen caos en vez de valor?
Porque casi todos los equipos mejoran las herramientas y dejan el modelo operativo intacto: compran agentes pero conservan el PRD, el roadmap, el sprint, y miden a la gente por output. Lo que consiguen es el modelo viejo corriendo más rápido, así que sus debilidades componen más rápido también, más PRDs sin leer, más ficción de roadmap, más output sin verificar. El flujo rápido solo produce buenos outcomes cuando corre a través de una verificación fuerte; sin ella, la velocidad solo acelera el daño.