Enseñé RUP a fines de los '90. Acabo de reconstruirlo para agentes de IA.

De 1998 a 2000 fui instructor certificado de RUP, enseñando el Rational Unified Process a equipos por toda Latinoamérica y el Caribe. RUP y sus parientes pesados en documentación perdieron la discusión en la industria porque a la gente la documentación le resultaba tediosa y la salteaba. Los agentes de IA no se aburren, así que reconstruí al sobreviviente flaco de esa familia, OpenUP, como un framework que hace que Claude Code trabaje de a una tarea registrada y trazable por vez.

Generate TL;DR ✨

TL;DR

¿Por qué un proceso de 2005, y por qué yo?

Recurrí a OpenUP porque ya lo conozco de memoria. De 1998 a 2000 fui instructor certificado de RUP, formando y asesorando equipos por toda Latinoamérica y el Caribe en el Rational Unified Process. RUP era el peso pesado de su época: comercial, exhaustivo, basado en roles, vendido por IBM/Rational con un precio acorde. Cuando dejó de venderse, un descendiente quedó vivo y gratis: OpenUP, el Open Unified Process, el núcleo flaco de esa metodología que mantiene la Eclipse Foundation. Es el último miembro de la familia que todavía se puede leer, usar y adaptar sin licencia.

Cuando empecé a dejar que los agentes de código hicieran trabajo real, y los vi comportarse igual que un junior sin disciplina pero con energía infinita, la forma de la solución me resultó familiar. Fases iterativas. Hitos que aprueba una persona. Un incremento por vez, con rastro en papel. Esto ya lo había enseñado. La sorpresa fue lo limpio que un proceso diseñado para equipos humanos en 2005 calza sobre un agente en 2026.

El resultado es una plantilla de proyecto más un workflow forzado, open-up-for-ai-agents. Arrancó en enero como un conversor chico que pasaba los 961 archivos HTML originales de OpenUP de Eclipse a una base de conocimiento en Markdown limpia, y a lo largo de 99 commits se transformó en la cosa que de verdad uso para manejar a Claude Code.

¿Por qué murieron esos procesos en verdad?

RUP y sus primos pesados en documentación eran buena ingeniería que murió por la naturaleza humana. La disciplina iterativa, guiada por riesgo y marcada por hitos que prescribían era sólida. Lo sigo creyendo. Pero la disciplina corría sobre personas, y las personas, con toda razón, no la sostenían.

Escribir el artefacto se sentía improductivo al lado de escribir el código. Los documentos eran fáciles de olvidar, fáciles de saltear "solo por esta vez", y quedaban desactualizados apenas se movía el código. Lo peor: nadie podía chequear de forma barata si el documento todavía coincidía con la realidad, así que la confianza en los docs se derrumbó y todo el edificio terminó abandonado en silencio o convertido en ceremonia que nadie leía. La industria concluyó que el proceso pesado no funciona. La versión precisa le agrega dos palabras: con humanos.

El agente cambia esa ecuación. Un agente no encuentra tedioso escribir la entrada del roadmap. No "se olvida" del log de cierre porque es viernes. No discute que la retrospectiva sea una pérdida de tiempo. La burocracia que los humanos vivían como fricción es, para un agente, una instrucción más, y la ejecuta rápido. Las partes que más nos costaban a nosotros, cruzar datos y verificar que los docs de verdad coincidan con el código, son justo lo que un agente más un par de hooks pueden hacer de forma continua, atando cada entrada del log a un SHA real de commit.

La metodología estaba bien; el trabajador estaba mal. Por fin tenemos un trabajador que la metodología esperaba sin decirlo: incansable, literal y auditable.

Una sesión, una tarea, un registro

El corazón mecánico del framework es una sola regla: cada ejecución del agente completa exactamente una tarea del roadmap. Nada de sesiones maratónicas que tocan cuarenta archivos y terminan con un vaguísimo "listo" al final. Cada ejecución está enmarcada por dos procedimientos que el agente tiene que seguir.

Al inicio, lee docs/project-status.md (qué fase, qué iteración, cuál es el objetivo), revisa la memoria institucional en iteration-learnings.md, elige la tarea pendiente de mayor prioridad en docs/roadmap.md, confirma que la tarea entra en la fase actual, y crea una rama. Trabajar sobre el tronco está prohibido. Después implementa, commiteando durante el trabajo y no en un solo bloque al final.

Al final viene la parte que más importa: un procedimiento de cierre obligatorio. Commitear todo, verificar que el árbol esté limpio, escribir un log de trazabilidad (una entrada en Markdown y un agent-runs.jsonl de solo-append) atado a los SHAs reales de los commits, actualizar el roadmap y el estado. La definición de "listo" es lo interesante. Una tarea está completa cuando su historia quedó persistida y registrada, no cuando el código simplemente anda. Las skills que guionan esto se ven así:

/openup-start-iteration task_id: T-007   # lee el estado, despliega un equipo, rama
/openup-orchestrate     task_id: T-007    # el PM descompone, instruye a especialistas
/openup-complete-task   task_id: T-007    # commitea, registra, actualiza roadmap, PR

Hay una separación limpia debajo de todo esto que me parece la mejor idea del repo. docs-eng-process/ contiene el proceso en sí y es escritura de solo lectura: el agente nunca lo edita durante una tarea. docs/ contiene el estado vivo del proyecto: roadmap, estado, planes, logs, decisiones. Las reglas en un lado, el estado en otro. Esa separación es lo que hace que el comportamiento del agente sea reproducible entre sesiones, en vez de depender de lo que se me ocurrió escribir esa mañana.

Para que sea honesto y no aspiracional, hay hooks en Python conectados a los eventos de Claude Code. Uno intercepta el lenguaje de inicio de tarea y no lo deja al agente empezar a programar antes de correr el intake. Otro le impide al agente frenar con cambios sin commitear. Un hook de commit avisa cuando no hay iteración activa. Se puede saltar con un [openup-skip] explícito, que queda registrado, porque un proceso sin válvula de escape es un proceso que la gente termina esquivando a oscuras.

Ahora el contexto vive en el repo

El beneficio que no veía venir es que mis prompts se acortaron. Normalmente, manejar bien a un agente significa escribir instrucciones largas, cuidadosas y cargadas de contexto cada vez: re-explicar el objetivo, las restricciones, el estado actual, las convenciones. Con el framework puesto, casi todo eso ya vive en el repositorio. El roadmap dice qué sigue. El estado dice dónde estamos. Los docs de proceso dicen cómo trabajar. Las learnings dicen qué ya se decidió y por qué.

Así que una ejecución puede arrancar con "empezá la próxima iteración" o incluso solo "seguí", y el agente reconstruye lo que necesita leyendo el repo. La carga cognitiva se movió fuera del prompt, que es efímero y fácil de errar, hacia el repositorio, que es duradero, versionado y compartido entre cada sesión y cada agente. Dejó de sentirse como promptear a un chatbot y empezó a sentirse como incorporar a un compañero que lee la documentación antes de preguntarme nada.

Esto conecta con el único costo que sí vigilo: los tokens. No voy a poner cifras en dólares acá, porque la medición honesta es un lío y cualquier número que tire engañaría. Pero la forma se ve clara en los logs de las sesiones. Lo caro con los agentes es re-establecer el contexto, turno tras turno, mucho más que el razonamiento nuevo en sí. En mis logs, las lecturas de caché (contexto que se vuelve a leer) son alrededor del 97% de todos los tokens; la salida genuinamente nueva es una capa fina arriba. Escribir el estado en docs/ es, entre otras cosas, una estrategia de tokens: el agente lee su contexto en vez de re-deducirlo desde cero en cada sesión. La ironía, a la que voy a llegar, es que producir toda esa documentación también cuesta tokens.

Donde todavía se rompe

Llamar a los agentes "obedientes y meticulosos" es el comportamiento por defecto fuerte, no una garantía, y tengo las pruebas. Usé el framework en tres proyectos reales: un tracker de deducciones de impuestos en Rails, una app de chat segura para chicos, y hace poco una simulación chica de radioafición construida en una sola sesión de ocho horas. La de radio es la que canta.

Ese proyecto corrió la versión más madura del framework, con hooks en runtime, specs calificadas por rúbrica y todo el aparato. Y bajo la presión de un build intenso de un solo día, el agente salteó en silencio los artefactos pesados en burocracia: sin run logs, sin JSONL, sin archivo de learnings, retrospectivas completadas después. Se apoyó en el historial de git, en los registros de decisiones de arquitectura y en el archivo de estado, y dejó caer el resto. Lo que lo agarró fue la propia plantilla de retrospectiva del framework, que marcó el hueco. Así que incluso con hooks, las partes con más ceremonia son las primeras en irse cuando aprieta. Los humanos salteaban los docs por aburrimiento; el agente los saltea bajo presión. Distinta causa, mismos documentos sin hacer.

La tensión más profunda se ve justo en el git log del framework. El 9 de abril subí la imposición más dura que había construido, hooks que bloqueaban y una regla estricta de no-bypass, y la suavicé el mismo día, convirtiendo los bloqueos en advertencias con esa válvula de escape registrada. Meses de commits son yo peleando contra mi propio sobrecosto: versiones compactas de las instrucciones de rol, un "scribe" barato con modelo Haiku para hacer la escritura mecánica y que no la haga el modelo caro de razonamiento, limpiezas repetidas de inflado de tokens. Cada mecanismo de imposición que agregué tenía un costo, y la mitad del trabajo fue recuperar ese costo sin perder la disciplina que hacía que la cosa valiera la pena.

Cierre

No voy a pretender que esto está resuelto. El framework anda lo suficientemente bien como para que los proyectos más viejos llegaran a su vigésima-y-pico iteración con un rastro de auditoría real, y el más nuevo pasó de repo vacío a app andando en un día con la mayoría de sus decisiones documentadas. Es más disciplina de la que jamás saqué de un equipo humano usando RUP, yo incluido (por no decir yo el primero).

Lo que todavía no puedo responder es dónde queda la línea entre el proceso suficiente para mantener honesto a un agente y tanto proceso que termino pagando tokens para generar documentos que nadie, ni humano ni modelo, va a leer. Que el proyecto de radio salteara sus propios logs fue molesto, pero también me hizo dudar de si esos logs valían la pena en primer lugar. Enseñé esta metodología hace veinticinco años creyendo que los documentos eran el punto. Ahora tengo un trabajador que los va a escribir todos sin quejarse, y soy yo el que decide cuáles valen de verdad su costo.