El coste de escribir era el control de calidad

Durante los tres últimos años hemos repetido un trato que sonaba razonable y que casi nadie discutió: que escriba la máquina, que decidamos nosotros. La ejecución se delega, el criterio se conserva. Lo dijeron los entusiastas para tranquilizar a los escépticos y lo dijeron los escépticos para no parecer nostálgicos. Todo el vocabulario del sector se construyó sobre ese reparto: el humano define el qué, el agente resuelve el cómo, y en medio queda una frontera limpia donde alguien mira lo que ha salido y dice que sí o que no.

Es un buen trato. El problema es que ya no describe lo que hacemos.

Porque el reparto suponía que el criterio se ejercía en algún sitio concreto —revisando un diff, leyendo una especificación, aprobando un plan— y esos sitios se han ido vaciando uno detrás de otro, sin que ninguna decisión explícita lo ordenara. No delegamos el criterio: delegamos, uno a uno, todos los lugares donde el criterio se ejercía.

El inventario de la delegación

Conviene hacer la lista completa, porque por separado cada paso parece razonable y solo juntos tienen sentido.

El código lo genera el agente. Eso es el punto de partida y ya nadie lo discute. Como el volumen generado supera lo que un equipo puede leer, la revisión se delega en otro agente: es exactamente lo que hizo Bun al reescribir un millón de líneas de Zig a Rust en once días, automatizar también la revisión, y es hoy la recomendación por defecto de media industria. La especificación, que llegó como la tabla de salvación —por fin un artefacto humano, por fin decidimos nosotros—, la escribe cada vez más el propio agente a partir de un prompt de tres líneas, y sale con una extensión que nadie lee entera. El plan de implementación se deriva de esa especificación automáticamente. Los tests los genera el mismo modelo que escribió el código que deben verificar. Y cuando queda la sensación incómoda de que falta un control, existe la opción de encargar el QA a un cuarto agente.

Puesto en fila, el patrón es difícil de no ver: cada capa de control se produce con el mismo procedimiento que hizo incontrolable a la capa anterior. La revisión llegó para controlar el código y se generó como el código. La especificación llegó para controlar la revisión y se generó como la revisión. No es una cadena de controles, es la misma operación repetida a distinto nivel de abstracción, y cada repetición hereda el defecto que venía a corregir.

La pregunta que asoma al final de la lista es la evidente, y merece una respuesta mejor que el lamento: si no especificamos, no escribimos, no revisamos y no verificamos, ¿en qué consiste exactamente el trabajo?

El coste de escribir era el límite de lo revisable

La respuesta empieza en un sitio poco glamuroso: en un estudio de revisión de código que Cisco y SmartBear publicaron en 2006, dos décadas antes de que existiera nada de esto.

Sus números son los mejores que tenemos sobre la capacidad real de revisión de un ser humano, y son demoledores. La tasa de detección de defectos es del 87% en revisiones de menos de cien líneas y cae al 28% por encima de mil. El rendimiento se desploma pasadas las 400 líneas y pasada la primera hora. La recomendación que salió de ahí —no revisar más de 200 a 400 líneas de una sentada— lleva veinte años en todas las guías de estilo del mundo, se cumple mal y nadie la ha derogado, porque no describe una preferencia metodológica: describe un límite de atención.

Ese límite nunca fue el problema, y por una razón que no habíamos tenido que pensar hasta ahora. El coste de producir mantenía los artefactos dentro del rango de lo revisable. Nadie escribía a mano un pull request de doce mil líneas ni una especificación de cuatrocientas páginas, no por disciplina, sino porque salía carísimo. El límite de lo que podíamos producir y el límite de lo que podíamos revisar coincidían aproximadamente, por accidente, y esa coincidencia funcionaba como un control de calidad que nadie diseñó, nadie documentó y nadie defendió nunca en una reunión. Estaba ahí. Era gratis. Y era estructural, no cultural.

La operación tiene precedente, y conviene reconocerlo porque explica hacia dónde va. Clay Shirky describió en 2008 el paso de “filtrar y luego publicar” a “publicar y luego filtrar”: el coste de imprimir había sido el filtro editorial del siglo XX, y cuando desapareció, el filtro no se sustituyó por otro mejor, simplemente se pospuso a un momento en el que ya nadie lo aplicaba. Lo que estamos haciendo con el software es la misma inversión de orden, con dos diferencias. La primera es que aquí el filtro no se pospone: se delega en el mismo sistema que produce. La segunda es que no está ocurriendo en un artefacto, sino en todos a la vez.

El desacoplamiento ya se mide

Lo interesante de esta tesis es que no hay que creérsela: los datos de este año la describen sin proponérselo.

Un estudio de aproximadamente 33.000 pull requests escritos por agentes encontró que los no fusionados son sistemáticamente más grandes, tocan más ficheros y fallan más a menudo la validación de CI. El tamaño ya no es una variable de estilo, es un predictor. Los datos de CircleCI de este año enseñan la otra mitad del cuadro: el throughput de ramas de feature subió un 59% interanual mientras el de main en el equipo mediano bajaba. Se produce mucho más y se integra menos, que es exactamente lo que ocurre cuando el cuello de botella se muda de escribir a decidir si es seguro fusionar. Y el 38% de los desarrolladores declara que revisar código generado por IA cuesta más esfuerzo que revisar el de un compañero, con lo que la carga por unidad de artefacto también ha subido, no solo el número de unidades.

Hay un cuarto dato, el más incómodo, y es de 2025: el ensayo controlado de METR con desarrolladores experimentados sobre tareas reales en sus propios repositorios. Tardaron un 19% más usando herramientas de IA, y al terminar estimaron que habían ido un 20% más rápido. Casi cuarenta puntos de diferencia entre el rendimiento y la percepción del rendimiento. METR ha marcado el resultado como histórico y con razón —las herramientas de febrero de 2025 no son las de hoy—, pero el hallazgo que importa aquí no es la cifra de productividad, sino la brecha: la señal interna que usamos para saber si estamos trabajando bien dejó de estar calibrada.

Y ahí es donde el argumento se vuelve psicológico, aunque no en el sentido que uno esperaría.

No es pereza

La explicación cómoda de todo lo anterior es que nos hemos relajado. Que el oficio exige revisar y hemos dejado de hacerlo. Que bastaría con tomárselo en serio otra vez.

Es una explicación falsa, y llevamos cuarenta años sabiéndolo por una literatura que se construyó en aviación, control de procesos industriales y medicina, mucho antes de que nadie automatizara la programación.

La referencia central es el trabajo de Parasuraman y Manzey sobre la complacencia ante la automatización, que en 2010 integró dos décadas de resultados en un modelo único. Su conclusión: la complacencia ante un sistema automatizado no es un rasgo de carácter ni un fallo de formación, sino una estrategia de asignación de atención bajo recursos acotados. Cuando una tarea manual compite por atención con una tarea supervisada que casi siempre sale bien, la atención se va a la manual. Es un cálculo, no una dejadez. Y hay dos hallazgos que rematan el asunto: aparece igual en expertos que en novatos, y no se corrige con práctica.

El resto de la literatura apunta en la misma dirección desde ángulos distintos. El decremento de vigilancia, medido por Mackworth ya en 1948, establece que el rendimiento en tareas de monitorización se degrada en menos de media hora, y no es entrenable. El problema de estar fuera del bucle, formalizado por Endsley y Kiris en 1995, describe cómo la automatización reduce la conciencia de situación y con ella la capacidad de retomar el control cuando hace falta. El efecto que Onnasch y sus colegas bautizaron en 2014 como lumberjack effect es el más útil para nuestro caso: cuanto mayor es el grado de automatización, mejor es el rendimiento rutinario y peor es el rendimiento cuando el sistema falla. Las dos curvas se separan a la vez y en direcciones opuestas.

A eso hay que sumarle dos mecanismos cognitivos que explican por qué revisar no sustituye a escribir. El efecto de generación, documentado por Slamecka y Graf en 1978, establece que retenemos mucho mejor lo que producimos que lo que leemos: un modelo mental construido revisando es estructuralmente más débil que uno construido escribiendo. Y la descarga cognitiva, que Risko y Gilbert revisaron en 2016, describe nuestra tendencia sistemática a delegar en cuanto existe un almacén externo fiable —tendencia que es adaptativa, no vaga, y que se activa antes cuanto más fiable parece el almacén.

Junta las piezas y el resultado no admite lectura moral. Un sistema que produce artefactos por encima del umbral de atención humana, que acierta la mayoría de las veces, y cuyos fallos son sutiles en lugar de evidentes, es la configuración exacta que la ingeniería de factores humanos identificó hace décadas como generadora de supervisión superficial. Pedirle a un desarrollador que compense eso con voluntad es pedirle que resuelva por fuerza de carácter un problema de arquitectura de la atención. En aviación se intentó y no funcionó.

Bainbridge lo escribió en 1983

Todo esto tiene un texto fundacional de cinco páginas que hoy se lee como una crítica de nuestro sector: Ironies of Automation, de Lisanne Bainbridge.

Su punto de partida es una observación sobre el diseñador, no sobre el operario. El diseñador considera al operador humano poco fiable e ineficiente, así que lo elimina del sistema, y al hacerlo le deja exactamente las tareas que no supo automatizar. De ahí salen dos ironías que conviene traducir sin adornos.

La primera: automatizar priva al operador de la práctica que necesitaría justo el día que tenga que intervenir. En nuestro caso, la capacidad de auditar código complejo se construye escribiendo código complejo, y esa es precisamente la actividad que hemos externalizado. Estamos formando a la próxima generación de revisores en un entorno donde no se revisa, y la anterior está perdiendo el músculo por desuso. El problema del escalón de entrada que desaparece no es solo laboral: es también epistemológico.

La segunda: al humano se le asigna monitorizar, que es la tarea para la que somos peores por construcción. No un poco peores. Peores de forma medida y reproducible desde 1948.

Hay una tercera ironía que Bainbridge no podía prever y que es específica de este ciclo. En las salas de control industriales, el operador supervisaba un sistema determinista: si fallaba, tendía a fallar siempre de la misma manera. Aquí el componente central es estocástico, produce salidas plausibles y distintas cada vez, y sus errores no son ruidosos sino verosímiles. Es el peor caso posible para un supervisor humano: no basta con detectar la anomalía, hay que detectar la corrección que no lo es.

Y el reparto que estamos adoptando —una parte concibe, otra ejecuta— tampoco es nuevo. Harry Braverman lo describió en 1974 como la operación característica del proceso de trabajo industrial: separar la concepción de la ejecución, y con ello separar el conocimiento del sistema de la persona que lo opera. Que en 2026 lo llamemos spec-driven development no cambia la mecánica, solo el vocabulario.

La especificación llegó sin control propio

Esto explica de paso por qué el consuelo dominante del sector no funciona. La respuesta estándar a todo lo anterior es que ahora lo importante es la especificación, y que ahí sigue estando el criterio humano.

El problema es que una especificación en lenguaje natural se enfrenta a una bifurcación que el marketing de la metodología evita mirar. O es lo bastante precisa como para ser inequívoca —y entonces es código, escrito en una notación peor, sin tipos, sin compilador y sin nadie que te avise de que te has contradicho en la página ochenta—, o es ambigua, y entonces no has especificado: has delegado la decisión sin enterarte. Dijkstra formuló el fondo del asunto en 1978 con una frase que sigue intacta: la naturalidad con la que usamos nuestra lengua materna consiste sobre todo en la facilidad con que nos permite decir cosas cuyo sinsentido no es evidente.

Un lenguaje de programación nunca fue solo notación. Era también un verificador: el compilador y el sistema de tipos te dicen que tu descripción es inconsistente antes de que lo haga la realidad. Al mover el trabajo a la especificación no subimos un nivel de abstracción; cambiamos de notación y perdimos el verificador. La dificultad no bajó, desapareció el detector.

Que la tesis es correcta lo demuestra la propia industria sin querer: el spec-driven development lleva dos años formalizándose —plantillas obligatorias, criterios de aceptación ejecutables, esquemas, evals, linters de especificación— en una trayectoria que solo puede terminar en un sitio. Está reconstruyendo un lenguaje de programación con otro nombre, y lo está haciendo porque la práctica le ha enseñado lo que ya sabíamos.

Queda además el problema que Naur planteó en 1985 y que no se resuelve con ninguna cantidad de documento. Programar es construir una teoría del sistema; el código es el residuo de esa teoría, no la teoría. El reparto clásico funcionaba porque las dos mitades persistían: el artefacto en el repositorio y la teoría en la cabeza del equipo. Los agentes rompen la simetría, porque reconstruyen su teoría desde cero en cada sesión y la descartan al terminar, y el humano ha dejado de construir la suya porque ya no escribe. El artefacto persiste. La teoría no persiste en ningún sitio.

Visto así, el auge de las especificaciones se entiende mejor y sin ironía: no ganan por ser un nivel superior de abstracción, ganan por ser el único almacén duradero que le queda al bucle. Es también lo que explica que hayan subido de golpe el valor de los ADR, de los ficheros de instrucciones y de todo lo que rodea al modelo. No estamos elevando el trabajo. Estamos buscando dónde guardar lo que antes se guardaba solo.

Queda la responsabilidad

Si el criterio se ha ido vaciando de todos sus lugares, algo sí permanece, y merece nombrarse con precisión porque es donde el análisis se vuelve incómodo: permanece la responsabilidad.

Madeleine Clare Elish lo llamó zona de deformación moral. Igual que el chasis de un coche absorbe el impacto para proteger al pasajero, el operador humano de un sistema automatizado acaba absorbiendo la sanción moral y legal cuando el conjunto falla, protegiendo la integridad del sistema técnico. La atribución no sigue al control real, porque nuestras nociones de responsabilidad siguen siendo individuales mientras el control se ha vuelto distribuido.

La lectura fría no es que esto sea una injusticia narrativa. Es un requisito de diseño institucional: la responsabilidad no se queda donde es más eficaz, se queda donde es más localizable. Un sistema necesita una entidad a la que dirigirse, y la persona que aprobó el merge es la única que hay. Toda esa literatura de gestión que celebra al ingeniero convertido en accountable operator está describiendo un ascenso; describe, con más exactitud, un pararrayos.

Es un tema con suficiente fondo como para no despacharlo en una sección, y volveremos sobre él. Aquí basta con dejar la consecuencia práctica: cualquier propuesta que reparta responsabilidad sin repartir capacidad de intervención no es un modelo de gobierno, es un modelo de atribución de culpa.

El límite hay que volver a ponerlo a mano

La consecuencia operativa de todo esto no es “revisad más”. Esa recomendación ya fracasó en tres industrias antes que en la nuestra.

Lo que sí funcionó en aviación y en control de procesos fue atacar el problema por diseño, aceptando el límite de atención en lugar de exigir que se supere. Traducido a lo que tenemos entre manos, significa reintroducir a mano el límite que el coste de producción imponía gratis.

Eso implica tratar el tamaño del artefacto como una restricción dura y no como una métrica de estilo: límites máximos de pull request y de especificación, con la obligación de trocear, porque un cambio de tres mil líneas no es un cambio grande, es un cambio no revisado. Implica sustituir la revisión uniforme por revisión escalonada por riesgo, y asumir que aprobar todo con la misma profundidad equivale a no aprobar nada. Implica que el muestreo declarado es más honesto y más eficaz que la aprobación completa ficticia: revisar en serio el 20% elegido por criterio de riesgo detecta más que pasar la vista por el 100%. Implica preferir verificación ejecutable a verificación inferencial siempre que exista la opción, porque un test que falla no sufre decremento de vigilancia. Y sobre todo implica reconocer que la fiabilidad se compra —en tokens, en tiempo y en gente— justo cuando la tarifa plana ha dejado de sostener a los agentes y cada control adicional aparece en la factura.

Nada de esto es novedoso. Es lo que la ingeniería de factores humanos lleva cuarenta años haciendo: lotes pequeños, puntos de decisión forzados, práctica manual periódica, ensayos del modo degradado. Lo único nuevo es que ahora nos toca a nosotros.

No delegamos el trabajo

Conviene terminar donde el análisis deja de ser cómodo para las dos posiciones habituales.

Los agentes no nos han quitado la programación, ni nos han ascendido a arquitectos. Han eliminado el coste de producir, y con él un mecanismo de control de calidad que llevaba décadas funcionando precisamente porque nadie sabía que existía. Ese mecanismo no era el criterio profesional, ni la disciplina, ni el oficio: era una restricción económica que mantenía todo lo que producíamos dentro del rango de lo que podíamos leer.

El coste no ha desaparecido del todo. Sigue existiendo, aparece en la factura y ya no lo cubre ninguna tarifa plana. Lo que ha desaparecido es su relación con el tamaño de lo que producimos, que era lo único que lo volvía útil como control.

Al romperse ese acoplamiento en todos los artefactos a la vez, cada capa nueva de control nace ya fuera de ese rango, y por eso la cadena se puede recorrer entera —especificación, plan, código, revisión, tests, QA— sin encontrar un solo punto donde alguien mire de verdad.

No delegamos el trabajo. Delegamos el mecanismo que nos decía si el trabajo estaba bien.