El runtime
eres tú.

Llevo ya demasiados años construyendo productos y siempre es la misma película. Una categoría de herramientas deja de servir al trabajo real, y la industria se gasta una década añadiendo features encima del cadáver.

Durante mucho tiempo ese cadáver ha sido el IDE, todavía respondiendo a "¿cómo escribo código más rápido?" cuando esa ya no era la pregunta. Ese debate se ha acabado. El mercado se ha movido. Hoy no abres un editor para empezar a trabajar, abres Claude Code en una terminal y te escribe el código, bien.

Generar código está resuelto. El trabajo no ha desaparecido. Se ha movido.

Cuando un buen desarrollador te dice que el coding con agentes le funciona de sobra, tiene razón. Claude Code le escribe el código. Pero mira lo que de verdad hace todo el día: parte el producto en tareas, abre worktrees, mantiene ocho sesiones vivas, enruta cada tarea a un modelo, lee logs, recupera el run que se ha caído, sostiene los invariantes viejos mientras entra el comportamiento nuevo, decide si "done" es done de verdad. El agente escribe el código. Todo lo de alrededor lo hace él, a mano, sin darse cuenta.

Ese bucle tiene un nombre que nadie le puso. El runtime es él. Y en cualquier sitio serio, el runtime es lo más caro del edificio: atención senior, gastada en ser el scheduler, la memoria, el bucle de recuperación y el gate de cada run.

De qué van de verdad
los próximos diez años.

No de un modelo más listo. No de un editor más rápido. La frontera se ha movido a un sitio más difícil: mantener vivo el contrato de producto mientras muchos agentes escriben, fallan, recuperan, integran y producen evidencia.

Done no es que el agente lo diga. Un build verde no es done. Done es el comportamiento pasando los criterios que existían antes de escribir una línea, con la evidencia pegada.

Esa frase es el cambio entero. El agente puede escribir el código. No puede ser quien decide si el código cuenta, porque es lo mismo que se está juzgando. Algo fuera del agente tiene que sostener el contrato.

Tres cosas que ningún agente, por bueno que sea, te quita solo:

Soberanía del contexto. Tus prompts, tus decisiones, tu dialecto interno, cómo funciona de verdad tu dominio: eso es el activo, no el código que ha tecleado el agente. Hoy vive disperso entre la memoria de un proveedor, un chat, un repo. El día que cambian los términos o sube el precio, se va con ellos. El contrato tiene que vivir en algo tuyo, en tu máquina, en formatos que puedas leer.

Routing multi-motor. El trabajo serio usa tres o cuatro motores: uno para arquitectura, uno para generación rápida, uno para contexto largo, un modelo local para los runs baratos y repetitivos. Ningún agente te enruta eso. Lo haces tú, a mano, copiando y pegando, perdiendo contexto en cada salto, y pagando precio de frontera por trabajo que debía hacer un modelo local.

Entrega validada y auditable. Lo que entregas no es código. Es código más la spec, las decisiones, los gates y la evidencia de que funciona. Un agente se declara done a sí mismo. Un contrato decide si cuenta, corre los criterios contra el comportamiento real, y deja un rastro que puedes auditar un año después.

No son features que falten. Son arquitectónicamente externas a cualquier executor. Un executor que además orquesta sigue siendo el executor de un proveedor, en la nube de otro, hasta que cambian los términos.

La categoría que nadie ha nombrado.

Lo que viene no es un agente mejor. Es la capa donde vive el contrato de producto: local-first, multi-motor, portable. El sitio donde el contexto, los gates, la evidencia y la memoria de cada run sobreviven, da igual qué agente ha escrito el código o en qué proveedor estás este trimestre.

Claude Code escribe el código. Codex ejecuta las tareas. La capa que mantiene vivo el contrato de producto hasta que la cosa está validada, con evidencia: esa es la parte que aún es tuya y puedes perder.

Si construyes herramientas para desarrolladores en 2026 y tu modelo mental sigue siendo "un agente mejor", estás compitiendo por la parte que ya se ha resuelto. La pregunta útil no es "¿cómo genero código mejor?". Es "¿quién mantiene vivo el contrato de producto mientras los agentes hacen la escritura?".

Y no es una capa que construyas con el modelo SaaS de VC que ha dominado la década anterior. Ese modelo es la otra muerte categórica del momento: empieza gratis, sube precios cuando el crecimiento se estanca, capa features para forzar el upgrade, acaba adquirido o degradado. Para una herramienta de la que vas a depender años, la capa que ata todo lo que rodea al código, ese ciclo es incompatible con la confianza. La alternativa no es heroica, es vieja: cobra lo que cuesta sostener el trabajo, a quien pueda pagarlo, deja el camino gratis abierto para quien no, y no le debas dinero a nadie. PaellaDoc está construido así.

Escribir código es el último paso.
El runtime eres tú.