“Claude Code me escribe el código de lujo. No necesito un runtime por encima.”
Si eres bueno, has pensado alguna versión de esto. Y tienes razón. Claude Code escribe código de sobra, y con el teclado delante no sientes que falte nada.
Esto es lo que no estás viendo: no sientes que necesites un runtime porque el runtime eres tú.
Partes el producto en tareas. Abres los worktrees correctos. Mantienes ocho sesiones vivas, recuerdas qué rama es segura y qué tarea depende de qué diff, sabes qué fallo importa y cuál es ruido, qué respuesta del agente suena bien y está mal. Cuando un run se rompe, lo recuperas. Cuando dos cambios chocan, los integras. Cuando el build está verde pero la feature está mal por debajo, lo pillas. Cuando el agente se pierde, le devuelves el hilo a la mano. Claude Code escribe el código. Todo lo demás lo haces tú, a mano, sin darte cuenta.
Eso no es que Claude Code se quede corto. Hace justo para lo que está hecho: meterse en un repo, leer, editar, ejecutar comandos, iterar con un modelo muy bueno. Con el teclado delante, es de las mejores herramientas que hay. La pregunta es quién hace el otro trabajo: el bucle de alrededor del código.
Ahora mismo, ese runtime eres tú.
El runtime que nadie factura
La parte difícil de entregar con agentes nunca fue generar el código. Es el bucle de alrededor:
- decidir qué hay que construir
- convertir la intención de producto en tareas
- escribir los criterios de aceptación, y conservarlos
- elegir qué agente hace qué tarea
- abrir worktrees aislados
- vigilar las sesiones en paralelo
- leer logs, interpretar fallos
- reintentar cuando se rompió lo que no era
- mantener vivos los invariantes viejos mientras entra el comportamiento nuevo
- integrar ramas, cazar regresiones
- llevar la cuenta de lo que costó cada run
- decidir si “done” es done de verdad
Un senior hace todo eso casi sin notarlo. Por eso pesa menos de lo que pesa. Cuanto mejor eres, más fácil es no ver cuánta orquestación sigue corriendo en tu cabeza.
Ocho paneles de tmux no quitan ese trabajo. Multiplican los sitios donde tiene que pasar.
Los agentes en paralelo te dan throughput. No te dan un sistema de entrega. Si cada sesión sigue necesitando a un humano que sostenga el contexto, ponga prioridad, recupere el fallo, valide la salida e integre el resultado, entonces el humano es el scheduler, la memoria, el gate y el release manager. Todo a la vez.
Para un experto vigilando cada panel, puede valer. No aguanta el contacto con muchas tareas, muchos repos, gente que no programa, o un plan que tiene que durar más que un chat.
La pregunta que importa
Si Claude Code funciona no es lo interesante. Claro que funciona. La pregunta útil es más estrecha:
cuánta dirección humana hace falta para sacarle un resultado de producto validado, durante horas o días, no minutos.
Ese hueco es lo que construyo con PaellaDoc. No un escritor de código mejor. PaellaDoc ejecuta Claude Code, Codex, Kimi y modelos locales, porque el executor nunca fue la frontera interesante. La frontera es todo lo que envuelve a la ejecución: contexto de producto, gates, evidencia, recuperación, routing, continuidad.
Si Claude Code es tu pair programmer, PaellaDoc es el runtime alrededor del pair.
Esa es la flota real, no un mockup. Tres agentes a la vez, cada uno en su worktree, cada uno saliendo de una user story. El modelo, el esfuerzo y el origen del run (Router eligió uno, Retry recuperó otro) son decisiones que tomó el runtime. Ese es el trabajo que si no estarías haciendo tú en tu cabeza.
Un prompt es un contrato pobre
Casi toda sesión con agente empieza con un prompt. Útil, pero pobre. Un prompt dice qué quieres. Rara vez carga el sistema de producto que hay debajo: la spec, los criterios, los caminos no felices, las restricciones de diseño, los invariantes del repo, los gates, la evidencia que necesita un cambio antes de contar, las razones por las que las decisiones viejas se tomaron así.
Cuando eso vive solo en un chat, se pudre. Cuando vive solo en tu cabeza, no lo puedes delegar. Cuando vive solo en una terminal, muere con el transcript.
Por eso PaellaDoc hace del contexto de producto una entrada de primera clase del run. Cuando el trabajo de producto son artefactos de verdad y no intuiciones, el bucle de código se puede gobernar contra ellos. Al agente no se le dice “construye la cosa”. Se le da una tarea, un contrato, un gate, y qué cuenta como evidencia.
Eso mueve lo que significa done.
Done no es que el agente lo diga. Un build verde tampoco es done. Done es el comportamiento pasando los criterios que existían antes de escribir una línea, con la evidencia pegada. La versión larga la escribí en un build verde no es una feature correcta.
El trabajo largo se rompe en otro sitio
Las demos de un disparo son el caso fácil. Un cambio de producto real pasa por episodios: añade el primer comportamiento, mantenlo vivo mientras añades el siguiente, sobrevive a un checkpoint y resume, gestiona el evento que llega tarde, cubre el camino negativo, mantén las restricciones de privacidad y portabilidad, integra al final sin romper en silencio lo que dejó el episodio uno.
Aquí “el modelo es listo” deja de pagar la cuenta. Un modelo más fuerte escribe un primer diff mejor. Incluso recupera muchos fallos locales solo. Pero si nada fuera del agente sostiene el contrato, re-puntúa el trabajo, guarda el estado y decide si un invariante viejo acaba de romperse, el sistema sigue dependiendo de que tú lo notes.
Esto lo medí. Cuatro episodios acumulativos, cada uno capaz de romper un gate que arregló el anterior. Un modelo más grande no cerró la brecha. Un runtime de recuperación gobernado, sí. Los datos y los matices están en el experimento de recuperación. Es el primer tramo de un benchmark más largo que quiero correr en abierto.
Por qué medirlo
No juzgues a PaellaDoc por “¿puede Claude Code hacer esto?”. Un buen desarrollador le saca muchísimo a Claude Code. Scripts, skills propias, worktrees, ocho sesiones, un harness de reintentos hecho a mano. Es una baseline justa, y es contra la que quiero que me midan.
Mídelo por el trabajo que harías a mano:
- cuántas veces tuviste que entrar tú
- cuántos diffs tuviste que leer antes de fiarte del resultado
- cuántos fallos se recuperaron sin ti
- cuántas regresiones llegaron vivas al final
- si el contexto de producto vivió en algún sitio que no fuera el chat
- si hay un rastro de por qué se aceptó el run
- si el trabajo resume tras una interrupción sin reconstruir todo el modelo mental en tu cabeza
- si el resultado final integra sin que reconstruyas la historia a mano
Esas son preguntas de runtime. Son las que importan en cuanto el coding con agentes pasa de “ayúdame con esto mientras miro” a “ejecuta este plan en el tiempo y devuélveme algo de lo que me pueda fiar”.
El claim, en corto
No afirmo que PaellaDoc escriba mejor código que Claude Code. No le hace falta. Ejecuta Claude Code.
El claim es más pequeño y más útil: PaellaDoc se lleva el contexto de producto, la orquestación, la recuperación, la validación y la evidencia fuera de tu cabeza y los mete en un runtime. Otra categoría de valor.
Para un ingeniero en solitario vigilando cada sesión, Claude Code a pelo puede ser todo lo que necesitas. Tu runtime está ahí, con criterio y ya pagado. En cuanto el trabajo abarca muchas tareas, muchos repos, muchas horas, gente que no programa, o un plan que tiene que sobrevivir a un chat, la pregunta cambia. Deja de ser “¿el agente sabe escribir código?” y pasa a ser “¿el sistema mantiene vivo el contrato de producto hasta que el código está validado?”.
Esa es la línea donde quiero competir.
El experimento que esto merece
Esto hay que medirlo en abierto, y no contra un prompt flojo. Eso sería fácil e inútil.
El test justo es un human-scheduler benchmark. Brazo A: un senior, Claude Code, worktrees, sesiones en background, instrucciones fuertes del repo, scripts permitidos, orquestación manual permitida. Brazo B: PaellaDoc, el mismo executor Claude Code, el mismo modelo y esfuerzo, el mismo repo, el mismo plan, los mismos gates, sin trampa en la descripción de la tarea.
Y cuentas: minutos humanos dirigiendo, intervenciones, cambios de contexto, gates fallidos recuperados, regresiones ocultas, tasa de aprobado final, completitud de la evidencia, tokens, tiempo hasta un resultado validado.
Si gana el desarrollador, es señal de verdad. Me dice dónde el runtime aún es más débil que un buen operador humano, y voy y lo arreglo. Si gana PaellaDoc, el punto no es que Claude Code fuera malo. Es que la capa de orquestación era lo que importaba. Y si empatan en corrección pero PaellaDoc necesita menos dirección, ese puede ser el resultado más útil de los tres. El objetivo nunca fue probar que los desarrolladores sobran. Es dejar de gastar atención senior en ser el runtime.
Entonces
Un buen desarrollador con Claude Code es potente. Eso nunca fue la discusión.
La discusión es si tú tienes que seguir siendo el scheduler, la memoria, el validador, el bucle de recuperación, el integrador y el libro de evidencia de cada run que haces. Mi respuesta es no.
Deja que Claude Code escriba el código. Quédate la intención de producto y las decisiones que importan. Deja que el runtime cargue con el resto.
Es el mismo argumento que el resto de lo que construyo: enruta cada tarea al motor correcto, y el cerebro de producto que se mantiene solo.
¿Eres tú el runtime ahora mismo? Cuéntame en el foro cuánto de tu día se va en dirigir agentes en vez de decidir qué construir.