El argumento para financiar arquitectura
El código se abarató. Acertar no.
La IA desplomó el costo de producir código. No hizo nada con el costo de producir el sistema equivocado. Esta página trata de esa brecha — y de por qué la persona que la controla es lo de mayor apalancamiento que puedes financiar.
// discount enginefunction applyDiscount(total, pct) { return total - pct;}El desplazamiento
La IA escaló la producción. Nunca escaló la coherencia.
Arrastra el control. A medida que crece la capacidad de la IA, el volumen de código que una organización puede producir se dispara. Que ese código forme un sistema que se sostiene no se mueve solo — lo mueve una persona.
La distancia entre estas dos líneas es riesgo. Se paga después, con intereses.
Especificación
La misma petición. Dos sistemas completamente distintos.
Un modelo es una función de su entrada. Dale un prompt vago y rellena los huecos con conjeturas. Dale una especificación precisa y los rellena con tu intención. Cambia la entrada abajo.
«Hazme un módulo de pedidos.»
Enredado. Sin fronteras. Los bugs son estructurales — no se eliminan con tests.
Order es un agregado. No puede despachar por debajo del stock disponible. Los totales se derivan de las líneas — nunca se almacenan crudos. Cancelar tras el despacho está prohibido. El dinero es un value object explícito.
Acotado. Invariantes garantizadas a nivel de tipos. El modelo resiste el mal uso por construcción.
Diseño de dominio guiado por especificación
La especificación es el activo. El código es un artefacto de build.
Cuando la especificación es la fuente de verdad, el código se puede regenerar — pero el pensamiento detrás de él no. Activa cada capa de la especificación y observa cómo compila la arquitectura.
Una especificación vacía compila a algo en lo que no puedes confiar.
Lo irreducible
Cuatro cosas que un modelo no puede decidir por ti.
- 01
Juicio bajo ambigüedad
Cuando un requisito se contradice a sí mismo, alguien tiene que elegir qué quiere decir realmente el negocio. Un modelo promedia los datos de entrenamiento; un arquitecto decide.
- 02
Trade-offs con consecuencias
Consistencia o disponibilidad. Velocidad o auditabilidad. Todo sistema real es una cadena de trade-offs que solo un humano puede asumir y defender.
- 03
Decisiones irreversibles
La forma del esquema, las fronteras de contexto, la API pública. Equivócate en esto y ningún volumen de código generado lo recompra.
- 04
Las invariantes de tu negocio
Que una factura nunca pueda ser negativa no está en los datos de entrenamiento. Está en tu dominio. Alguien tiene que conocerla — y codificarla.
El costo compuesto
La deuda arquitectónica no se suma. Se multiplica.
Recorre dieciocho meses del mismo proyecto. Un camino tuvo a un arquitecto dando forma a cada frontera. El otro entregó lo que se generara más rápido.
Ambos equipos usaron la misma IA. Solo uno siguió siendo barato de cambiar.
La ecuación de apalancamiento
La IA es un multiplicador. Un multiplicador necesita algo que valga la pena multiplicar.
La producción confiable es el rendimiento de la IA multiplicado por el juicio humano. El rendimiento es ya prácticamente ilimitado. Lleva el juicio hacia cero y observa cuánto vale ese rendimiento ilimitado.
Velocidad ilimitada por juicio cero sigue siendo cero. Este es el argumento para financiar el juicio.
La decisión
Financia a quien hace que la IA valga lo que cuesta.
Diseño backends orientados al dominio — DDD, Hexagonal, CQRS — para sistemas donde equivocarse sale caro. Si estás invirtiendo en entrega acelerada por IA y quieres que se componga en vez de degradarse, hablemos.