Idea principal

El volumen de código producido y las propiedades de conjunto de un sistema no varían a la vez. La coherencia de arquitectura, la fiabilidad en explotación, la seguridad y la calidad de las integraciones no son cantidades que se obtengan escribiendo más: son propiedades del conjunto, que se degradan cuando las partes se suman sin arbitraje.

La pregunta técnica que cuenta se desplaza, por tanto. "¿Podemos programar esto?" vuelve a ser una pregunta banal en cuanto la producción es abundante; las preguntas que siguen siendo difíciles están en otra parte: ¿podemos integrarlo limpiamente en lo existente, podemos mantenerlo, podemos asegurarlo, podemos hacer que aguante en la realidad?

Lo que aporta el equipo técnico ya no es principalmente la capacidad de escribir, es el juicio sobre lo que es razonable, robusto y sostenible construir en un contexto dado.

Capa aportada por "PM, desarrolladores e IA: los roles se difuminan, las responsabilidades permanecen" (2026-08-01). La formulación más útil pasa por lo que se convierte en commodity y lo que no. Producir rápidamente una primera versión de código deja de ser escaso; el software, en cambio, no se convierte en commodity, ni tampoco la ingeniería, la arquitectura, la seguridad o la mantenibilidad. Confundir ambas cosas lleva a tratar como banal un oficio del que solo se ha banalizado la primera etapa.

Por qué es importante

Impide leer una aceleración de la producción como una ventaja técnica. Un sistema que crece más rápido de lo que se arbitra acumula deuda de arquitectura al ritmo mismo de su crecimiento.

También da el criterio con el que evaluar una propuesta técnica una vez asumida la viabilidad: la integración, la mantenibilidad, la seguridad y el aguante en explotación, que son los cuatro lugares donde se revela el coste real.

Matices y límites

La afirmación no dice que la producción ya no cuente: un equipo incapaz de entregar no arbitra nada. Dice que la capacidad de escribir deja de ser el factor limitante.

Y una parte de la coherencia puede apoyarse en herramientas — convenciones impuestas, tests, revisiones automatizadas — lo que desplaza el juicio hacia la definición de esas salvaguardas sin eliminarlo.

Preguntas abiertas

• ¿Cómo medir la degradación de coherencia de un sistema mientras crece, antes de que se manifieste en incidentes?