El cuello de botella del desarrollo de software ya no es escribir código: es decidir qué construir, cómo conectarlo y cómo mantenerlo cuando cambie. Durante dos décadas la escasez estuvo en la capacidad de producción; hoy la producción de código es abundante y barata, y la escasez se ha desplazado por completo a las decisiones de diseño que ninguna herramienta de generación puede tomar por ti.
Esto tiene una consecuencia comercial concreta para cualquier empresa que esté comprando desarrollo en 2026: el precio por hora de escribir código está bajando, y el coste de una mala decisión de arquitectura está subiendo. Comprar como si siguiéramos en 2019 —comparando proveedores por tarifa y velocidad— es optimizar la variable equivocada.
La intuición dice que si producir código es más rápido, los proyectos deberían terminar antes. Los datos dicen otra cosa.
El informe DORA de 2024, elaborado por Google Cloud sobre unos 39.000 profesionales del sector, encontró que un aumento del 25% en la adopción de IA correlacionaba con una caída del 1,5% en el throughput de entrega y del 7,2% en la estabilidad. No porque el código generado sea intrínsecamente malo, sino porque el tamaño de los lotes de cambio crece: se envía más de golpe, se revisa peor y se rompe más. En ese mismo estudio, el 39,2% de los desarrolladores declaraba poca o ninguna confianza en el código generado por IA.
GitClear, analizando 211 millones de líneas de código entre 2020 y 2024, documentó el otro lado del mismo fenómeno: el código refactorizado o «movido» cayó de aproximadamente el 25% en 2021 a menos del 10% en 2024, mientras el copiar y pegar subía del 8,3% al 12,3% y los bloques duplicados se multiplicaban por ocho.
Traducido: se escribe más y se reorganiza menos. Se acumula.
El estudio de METR de julio de 2025 añadió 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ás usando IA, aunque esperaban ir un 24% más rápido y, después de la prueba, seguían creyendo que habían ido un 20% más rápido. La propia METR revisó ese diseño en febrero de 2026 por posibles sesgos de selección, y una cohorte mayor arrojó una diferencia mucho menor. El resultado exacto está en debate. Lo que no está en debate es el hallazgo secundario: la percepción de velocidad y la velocidad real se desacoplan.
Cuando la percepción de velocidad se desacopla de la realidad, la disciplina que corrige el rumbo no es la ejecución. Es el diseño.
No todas las decisiones técnicas pesan igual. La distinción práctica es entre lo que se puede cambiar en una semana y lo que condiciona los próximos cinco años.
Tipo de decisión | Ejemplo | Coste de cambiarla después |
Herramienta | Framework de frontend, librería de gráficos | Bajo: semanas |
Proveedor de modelo | Cambiar de un LLM a otro | Bajo si hay capa de abstracción |
Modelo de datos | Cómo se representa un cliente o un pedido | Alto: afecta a todo lo construido encima |
Fronteras entre sistemas | Qué módulo es dueño de qué información | Muy alto: reescritura parcial |
Modelo de permisos | Quién puede ver y hacer qué, y con qué trazabilidad | Muy alto: implica seguridad y compliance |
Las dos primeras filas son las que más ruido generan en las reuniones técnicas. Las tres últimas son las que determinan si dentro de tres años la empresa puede evolucionar su sistema o tiene que reescribirlo.
Un ejemplo concreto que se repite en logística, seguros y sanidad: la decisión de si el «expediente» es una entidad propia con ciclo de vida o simplemente una vista construida al vuelo sobre otras tablas. Esa decisión se toma en la semana dos del proyecto, casi siempre sin debate, y determina durante años si se pueden auditar cambios, si se puede aplicar retención de datos y si se puede exponer el expediente a un tercero mediante una API. Ningún generador de código va a tomarla, porque no es una pregunta de código: es una pregunta sobre el negocio.
Este es el trabajo que hacemos en desenvolvimento de software personalizado [enlace interno] antes de escribir la primera línea: definir qué existe, qué es dueño de qué y qué contrato tiene cada módulo con los demás.
La arquitectura de un sistema empresarial se juega en cuatro fronteras. Cuando las cuatro están bien definidas, el sistema evoluciona. Cuando alguna se difumina, el sistema se degrada aunque el código sea impecable.
La frontera de los datos. Cada dato debe tener un dueño único: un sistema que manda y otros que consultan. La alternativa —tres sistemas que escriben la misma información— produce contradicciones que ninguna capa superior puede resolver, y es la causa raíz de la mayoría de los proyectos de business intelligence que terminan en discusiones sobre qué número es el bueno.
La frontera de los contratos. Los módulos se comunican mediante interfaces explícitas, versionadas y documentadas. Un contrato es una promesa: «esto es lo que devuelvo, esto es lo que garantizo, esto es lo que cambio avisando». Sin contratos, cada integración es un acoplamiento nuevo y cada cambio es una negociación.
La frontera de los permisos. Quién puede ver qué y quién puede hacer qué debe ser una capa del sistema, no una condición repetida en cuarenta sitios. Esta frontera se ha vuelto crítica con la llegada de agentes de IA que ejecutan acciones: si el modelo de permisos era frágil con usuarios humanos, con identidades no humanas se rompe.
La frontera de la observabilidad. Un sistema del que no se puede saber qué hizo, cuándo y por qué, no es mantenible ni auditable. Y desde que hay componentes probabilísticos en la cadena, la trazabilidad ha dejado de ser una buena práctica de operaciones para convertirse en un requisito de gobernanza.
Estas cuatro fronteras son las que estructuran una arquitectura componible, un enfoque que desarrollamos en detalle en nuestro análisis sobre arquitectura componible, APIs e inteligencia artificial
No hace falta una auditoría formal para detectar los primeros síntomas. Estos son los indicadores que aparecen antes:
Cuando aparecen tres o más de estos síntomas, añadir capacidad de desarrollo no acelera nada. Solo aumenta el número de personas esperando a que se resuelva una decisión de diseño.
El argumento de la arquitectura suele presentarse en términos de ingeniería, y por eso pierde en los comités de dirección. Traducido a lenguaje de negocio, una buena arquitectura hace cuatro cosas medibles:
Reduce el coste de cambiar de opinión. Una empresa que puede modificar su oferta, su proceso de facturación o su modelo de precios en semanas compite de forma distinta a una que necesita seis meses.
Convierte la tecnología en un activo, no en un gasto recurrente. Un sistema con propiedad clara del código, documentación y contratos explícitos tiene valor en una due diligence. Un sistema del que depende un único proveedor, no.
Permite sustituir piezas sin reconstruir el conjunto. Especialmente relevante con los modelos de IA, cuyos precios, capacidades y políticas de uso cambian varias veces al año.
Hace auditables las decisiones. Con el marco regulatorio europeo endureciéndose, poder demostrar qué hizo el sistema y con qué datos ha pasado de ser deseable a ser exigible.
En The Cloud Group esto está formalizado en TCG-SAF™, nuestro framework de arquitectura de sistemas: cinco etapas —Vision, Domains, Modules, Engineer, Execute— y un único documento de arquitectura que gobierna toda la construcción. No es una preferencia estética. Es la razón por la que podemos poner por escrito garantías de plazo: solo se puede comprometer una fecha cuando el alcance está estructurado antes de empezar.
Durante el pico del hype se asumió que, si todo el mundo tendría acceso a los mismos modelos, las capacidades se igualarían. Ha ocurrido lo contrario. Dos empresas con acceso idéntico a las mismas herramientas obtienen resultados radicalmente distintos, y la diferencia está en sus datos propios, en su conocimiento de dominio y en la calidad de la integración entre sus sistemas.
Los modelos se commoditizan. Las herramientas de generación de código se commoditizan. Lo que no se commoditiza es la capacidad de convertir capacidades genéricas en un sistema específico, fiable y propiedad de la empresa.
Esa capacidad tiene un nombre antiguo y poco vistoso: ingeniería.
La arquitectura de software es el conjunto de decisiones sobre qué componentes existen, qué información posee cada uno y cómo se comunican entre sí. Importa más que el código porque el código se puede reescribir en semanas, mientras que cambiar el modelo de datos o las fronteras entre sistemas puede requerir una reescritura parcial del producto.
Los síntomas típicos son: los cambios pequeños tardan como los grandes, las estimaciones son poco fiables, cada integración nueva cuesta como la primera, hay zonas del sistema que el equipo evita tocar y el conocimiento del flujo de información depende de una sola persona.
No: la aumenta. Cuando generar código es barato, la escasez se desplaza a decidir qué construir y cómo conectarlo. El informe DORA de 2024 encontró que aumentar la adopción de IA correlacionaba con menor estabilidad de entrega, precisamente porque crece el volumen de cambio sin crecer la disciplina de diseño.
Las tres más costosas de revertir son el modelo de datos (cómo se representan las entidades del negocio), las fronteras de propiedad entre sistemas (qué módulo manda sobre qué información) y el modelo de permisos y trazabilidad. Cambiar de framework o de proveedor de modelo es comparativamente barato.
Depende del grado de acoplamiento, pero el patrón habitual es que el coste crece de forma no lineal con el tiempo: cada mes de construcción sobre una frontera mal definida añade código que dependerá de esa decisión. Por eso una auditoría técnica temprana suele costar una fracción de lo que cuesta la reescritura que evita.
Sí. El enfoque habitual es aislar el sistema existente detrás de contratos explícitos y sustituir dominios uno a uno, en lugar de reescribir todo de golpe. Requiere un diagnóstico previo que priorice qué dominio se moderniza primero según riesgo y valor de negocio.
¿Sospechas que tu arquitectura es el freno? Nuestra auditoría técnica de software entrega un diagnóstico por escrito de arquitectura, código, deuda y seguridad en 10 días hábiles y a precio cerrado. Sin propuesta comercial dentro: primero el diagnóstico, después la decisión. Solicita la auditoría → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
