{"id":32073,"date":"2026-08-14T20:05:34","date_gmt":"2026-08-14T20:05:34","guid":{"rendered":"https:\/\/thecloud.group\/?p=32073"},"modified":"2026-08-14T20:07:46","modified_gmt":"2026-08-14T20:07:46","slug":"cuello-de-botella-arquitectura-software","status":"publish","type":"post","link":"https:\/\/thecloud.group\/pt\/cuello-de-botella-arquitectura-software\/","title":{"rendered":"O verdadeiro gargalo \u00e9, mais uma vez, a arquitetura."},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
<\/div>\n\t\t\t\t\t\t
\n\t\t\t\n\t\n<\/svg>\t\t<\/div>\n\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"logo\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

La IA no arregla una empresa mal dise\u00f1ada<\/h1>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

14 Agosto 2026<\/h1>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

El cuello de botella del desarrollo de software ya no es escribir c\u00f3digo: es decidir qu\u00e9 construir, c\u00f3mo conectarlo y c\u00f3mo mantenerlo cuando cambie. Durante dos d\u00e9cadas la escasez estuvo en la capacidad de producci\u00f3n; hoy la producci\u00f3n de c\u00f3digo es abundante y barata, y la escasez se ha desplazado por completo a las decisiones de dise\u00f1o que ninguna herramienta de generaci\u00f3n puede tomar por ti.<\/p>

Esto tiene una consecuencia comercial concreta para cualquier empresa que est\u00e9 comprando desarrollo en 2026: el precio por hora de escribir c\u00f3digo est\u00e1 bajando, y el coste de una mala decisi\u00f3n de arquitectura est\u00e1 subiendo. Comprar como si sigui\u00e9ramos en 2019 \u2014comparando proveedores por tarifa y velocidad\u2014 es optimizar la variable equivocada.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

\u00bfPor qu\u00e9 la abundancia de c\u00f3digo desplaza el problema en lugar de resolverlo?<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t
\n\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

La intuici\u00f3n dice que si producir c\u00f3digo es m\u00e1s r\u00e1pido, los proyectos deber\u00edan terminar antes. Los datos dicen otra cosa.<\/p>

El informe DORA de 2024, elaborado por Google Cloud sobre unos 39.000 profesionales del sector, encontr\u00f3 que un aumento del 25% en la adopci\u00f3n de IA correlacionaba con una ca\u00edda del 1,5% en el throughput de entrega y del 7,2% en la estabilidad. No porque el c\u00f3digo generado sea intr\u00ednsecamente malo, sino porque el tama\u00f1o de los lotes de cambio crece: se env\u00eda m\u00e1s de golpe, se revisa peor y se rompe m\u00e1s. En ese mismo estudio, el 39,2% de los desarrolladores declaraba poca o ninguna confianza en el c\u00f3digo generado por IA.<\/p>

GitClear, analizando 211 millones de l\u00edneas de c\u00f3digo entre 2020 y 2024, document\u00f3 el otro lado del mismo fen\u00f3meno: el c\u00f3digo refactorizado o \u00abmovido\u00bb cay\u00f3 de aproximadamente el 25% en 2021 a menos del 10% en 2024, mientras el copiar y pegar sub\u00eda del 8,3% al 12,3% y los bloques duplicados se multiplicaban por ocho.<\/p>

Traducido: se escribe m\u00e1s y se reorganiza menos. Se acumula.<\/p>

El estudio de METR de julio de 2025 a\u00f1adi\u00f3 un matiz que conviene tratar con honestidad. En un ensayo controlado con 16 desarrolladores experimentados de proyectos open source y 246 tareas reales, los participantes tardaron un 19% m\u00e1s usando IA, aunque esperaban ir un 24% m\u00e1s r\u00e1pido y, despu\u00e9s de la prueba, segu\u00edan creyendo que hab\u00edan ido un 20% m\u00e1s r\u00e1pido. La propia METR revis\u00f3 ese dise\u00f1o en febrero de 2026 por posibles sesgos de selecci\u00f3n, y una cohorte mayor arroj\u00f3 una diferencia mucho menor. El resultado exacto est\u00e1 en debate. Lo que no est\u00e1 en debate es el hallazgo secundario: la percepci\u00f3n de velocidad y la velocidad real se desacoplan.<\/p>

Cuando la percepci\u00f3n de velocidad se desacopla de la realidad, la disciplina que corrige el rumbo no es la ejecuci\u00f3n. Es el dise\u00f1o.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

\u00bfQu\u00e9 decisiones son realmente irreversibles?<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

No todas las decisiones t\u00e9cnicas pesan igual. La distinci\u00f3n pr\u00e1ctica es entre lo que se puede cambiar en una semana y lo que condiciona los pr\u00f3ximos cinco a\u00f1os.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Tipo de decisi\u00f3n<\/strong><\/p><\/td>

Ejemplo<\/strong><\/p><\/td>

Coste de cambiarla despu\u00e9s<\/strong><\/p><\/td><\/tr><\/thead>

Herramienta<\/strong><\/p><\/td>

Framework de frontend, librer\u00eda de gr\u00e1ficos<\/p><\/td>

Bajo: semanas<\/p><\/td><\/tr>

Proveedor de modelo<\/strong><\/p><\/td>

Cambiar de un LLM a otro<\/p><\/td>

Bajo si hay capa de abstracci\u00f3n<\/p><\/td><\/tr>

Modelo de datos<\/strong><\/p><\/td>

C\u00f3mo se representa un cliente o un pedido<\/p><\/td>

Alto: afecta a todo lo construido encima<\/p><\/td><\/tr>

Fronteras entre sistemas<\/strong><\/p><\/td>

Qu\u00e9 m\u00f3dulo es due\u00f1o de qu\u00e9 informaci\u00f3n<\/p><\/td>

Muy alto: reescritura parcial<\/p><\/td><\/tr>

Modelo de permisos<\/strong><\/p><\/td>

Qui\u00e9n puede ver y hacer qu\u00e9, y con qu\u00e9 trazabilidad<\/p><\/td>

Muy alto: implica seguridad y compliance<\/p><\/td><\/tr><\/tbody><\/table>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Las dos primeras filas son las que m\u00e1s ruido generan en las reuniones t\u00e9cnicas. Las tres \u00faltimas son las que determinan si dentro de tres a\u00f1os la empresa puede evolucionar su sistema o tiene que reescribirlo.<\/p>

Un ejemplo concreto que se repite en log\u00edstica, seguros y sanidad: la decisi\u00f3n de si el \u00abexpediente\u00bb es una entidad propia con ciclo de vida o simplemente una vista construida al vuelo sobre otras tablas. Esa decisi\u00f3n se toma en la semana dos del proyecto, casi siempre sin debate, y determina durante a\u00f1os si se pueden auditar cambios, si se puede aplicar retenci\u00f3n de datos y si se puede exponer el expediente a un tercero mediante una API. Ning\u00fan generador de c\u00f3digo va a tomarla, porque no es una pregunta de c\u00f3digo: es una pregunta sobre el negocio.<\/p>

Este es el trabajo que hacemos en desarrollo de software a medida<\/a><\/u> [enlace interno]<\/em> antes de escribir la primera l\u00ednea: definir qu\u00e9 existe, qu\u00e9 es due\u00f1o de qu\u00e9 y qu\u00e9 contrato tiene cada m\u00f3dulo con los dem\u00e1s.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Las cuatro fronteras que hay que defender<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

La arquitectura de un sistema empresarial se juega en cuatro fronteras. Cuando las cuatro est\u00e1n bien definidas, el sistema evoluciona. Cuando alguna se difumina, el sistema se degrada aunque el c\u00f3digo sea impecable.<\/p>

La frontera de los datos.<\/strong> Cada dato debe tener un due\u00f1o \u00fanico: un sistema que manda y otros que consultan. La alternativa \u2014tres sistemas que escriben la misma informaci\u00f3n\u2014 produce contradicciones que ninguna capa superior puede resolver, y es la causa ra\u00edz de la mayor\u00eda de los proyectos de business intelligence que terminan en discusiones sobre qu\u00e9 n\u00famero es el bueno.<\/p>

La frontera de los contratos.<\/strong> Los m\u00f3dulos se comunican mediante interfaces expl\u00edcitas, versionadas y documentadas. Un contrato es una promesa: \u00abesto es lo que devuelvo, esto es lo que garantizo, esto es lo que cambio avisando\u00bb. Sin contratos, cada integraci\u00f3n es un acoplamiento nuevo y cada cambio es una negociaci\u00f3n.<\/p>

La frontera de los permisos.<\/strong> Qui\u00e9n puede ver qu\u00e9 y qui\u00e9n puede hacer qu\u00e9 debe ser una capa del sistema, no una condici\u00f3n repetida en cuarenta sitios. Esta frontera se ha vuelto cr\u00edtica con la llegada de agentes de IA que ejecutan acciones: si el modelo de permisos era fr\u00e1gil con usuarios humanos, con identidades no humanas se rompe.<\/p>

La frontera de la observabilidad.<\/strong> Un sistema del que no se puede saber qu\u00e9 hizo, cu\u00e1ndo y por qu\u00e9, no es mantenible ni auditable. Y desde que hay componentes probabil\u00edsticos en la cadena, la trazabilidad ha dejado de ser una buena pr\u00e1ctica de operaciones para convertirse en un requisito de gobernanza.<\/p>

Estas cuatro fronteras son las que estructuran una arquitectura componible, un enfoque que desarrollamos en detalle en nuestro an\u00e1lisis sobre arquitectura componible, APIs e inteligencia artificial<\/a><\/u>\u00a0<\/em><\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

\u00bfC\u00f3mo se reconoce que la arquitectura es el cuello de botella?<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

No hace falta una auditor\u00eda formal para detectar los primeros s\u00edntomas. Estos son los indicadores que aparecen antes:<\/p>