El ciclo de vida del software está mutando: la IA está empezando a formar parte de la arquitectura misma

Cuando empecé en esto el flujo era casi un ritual.

Alguien escribía los requerimientos. Yo diseñaba el sistema y escribía el código. Alguien más lo testeaba. Se hacía deploy. Y si tenías suerte, nadie te llamaba a las 3 am.

Requerimientos → Desarrollo → Testing → Deploy → Monitoreo

Simple. Predecible. El trabajo era claro.

La IA llegó primero como algo que implementábamos: un chatbot aquí, un sistema de recomendaciones allá, búsqueda semántica, copilots, generación de contenido. Cosas que agregábamos al producto como agregaríamos cualquier otra funcionalidad. Una feature más en el backlog.

Pero en algún punto, sin que yo notara exactamente cuándo, algo cambió.

Dejé de ver la IA como algo que vivía dentro del producto. Empecé a verla participar en el ciclo completo: generando código, analizando arquitecturas, automatizando tests, ayudando a debuggear incidentes a medianoche, escribiendo documentación, proponiendo refactors, tocando infraestructura. Ya no era una feature. Estaba metida en cómo construíamos todo lo demás.

Y eso me hizo darme cuenta de algo que nadie me había enseñado a anticipar:

El software moderno necesita ser entendible no solo por humanos, sino también por los modelos que ahora colaboran en construirlo.

El problema que nadie diseñó para esto

Llevo años trabajando con codebases que, con el tiempo, se volvieron difíciles de sostener. No porque alguien tomara malas decisiones a propósito, sino porque los sistemas crecen, los equipos rotan, los deadlines aprietan, y la lógica de negocio termina enterrada en lugares que nadie documenta.

El resultado es siempre parecido:

• lógica de negocio implícita, sin nombre, sin explicación
• variables y funciones que nadie sabe exactamente qué hacen
• servicios que crecieron hasta volverse monstruos
• efectos secundarios que aparecen cuando menos los esperas
• acoplamiento por todos lados

Nosotros, como desarrolladores, ya teníamos dificultades navegando eso.

Cuando empecé a usar herramientas de IA para trabajar con ese tipo de código, me topé con algo interesante: los modelos tienen los mismos problemas que nosotros, pero amplificados. Los LLMs trabajan de forma probabilística, y eso significa que funcionan radicalmente mejor cuando el sistema tiene intención explícita, semántica clara, límites definidos y comportamiento predecible.

En un codebase desordenado, la IA adivina. En uno bien estructurado, la IA vuela.

Eso me llevó a una conclusión que al principio me pareció contraintuitiva:

La IA no hace menos importante la buena arquitectura. La hace más importante que nunca.

TDD: de práctica de ingeniería a protocolo de comunicación

Durante años, TDD fue una de esas cosas que todos decían que había que hacer pero pocos hacían en serio. "Ralentiza el desarrollo", "no tenemos tiempo", "lo escribimos después". Conozco el speech de memoria porque yo mismo lo usé más de una vez.

Ahora me arrepiento.

Cuando empecé a generar código con IA de forma consistente, algo me quedó claro muy rápido: necesito una forma de saber si lo que me generó es correcto. Y los tests son exactamente eso.

describe("PriceCalculator", () => {
  it("debería aplicar descuento premium", () => {
    const result = calculatePrice({
      basePrice: 100,
      premium: true
    })

    expect(result).toBe(80)
  })
})

Antes este test validaba comportamiento. Eso sigue siendo cierto. Pero en un flujo asistido por IA, ese mismo test también es:

• una especificación de qué se espera del sistema
• un contrato que cualquier implementación debe respetar
• un mecanismo de validación automático
• un feedback loop que la IA puede usar para corregirse

La IA puede generar diez implementaciones distintas del mismo módulo. Los tests definen cuál comportamiento es aceptable.

Eso cambia completamente el rol de TDD. Ya no es solamente una práctica de ingeniería. Se está convirtiendo en un protocolo de comunicación entre humanos y modelos.

Por qué DDD parece haber sido diseñado para esto

Algo que me sorprendió con el tiempo es lo bien que encaja Domain Driven Design con la forma en que trabajan los modelos de IA.

Cuando le pasas a un modelo código como este:

function process(data) {
  // lógica ambigua
}

Prácticamente no tiene contexto con qué trabajar. Está adivinando.

Pero cuando el sistema está modelado con DDD y el lenguaje ubícuo está presente en el código:

class InvoiceAggregate {
  applyPayment(payment: Payment) {}
}

class FraudDetectionService {
  evaluate(transaction: Transaction) {}
}

class SubscriptionRenewalPolicy {
  shouldRenew(user: User): boolean {}
}

El modelo ahora tiene intención de negocio, semántica explícita, bounded contexts, y responsabilidades claras. Tiene combustible.

DDD no fue diseñado pensando en IA. Pero resulta que estructurar el dominio explícitamente, nombrar las cosas con el lenguaje del negocio, y definir límites claros entre contextos, es exactamente lo que necesita un modelo para colaborar bien.

Clean Architecture y el problema de los prompts enterrados

Hay algo que vi pasar en varios proyectos y que me preocupa bastante: los prompts convirtiéndose en lógica de negocio.

Empieza inocente. Un prompt hardcodeado aquí, una llamada directa al modelo allá, y de repente el core del sistema depende de un string que nadie sabe exactamente cómo o cuándo cambió.

El problema es que los sistemas de IA evolucionan muy rápido. Los modelos cambian. Los proveedores cambian. Las estrategias de inferencia cambian. Si las reglas de negocio están directamente acopladas a eso, cualquier cambio en la capa de IA se convierte en un riesgo para el negocio.

Por eso arquitecturas como Clean Architecture o Hexagonal empiezan a tener aún más sentido:

┌────────────────────┐
│      Dominio       │
├────────────────────┤
│   Casos de Uso     │
├────────────────────┤
│ Adaptadores de IA  │
├────────────────────┤
│ Infraestructura    │
└────────────────────┘

La IA debería existir como una capacidad desacoplada, no enterrada en el core. Esa separación permite cambiar modelos sin tocar negocio, experimentar sin riesgo, mejorar la observabilidad, y sobre todo, evitar que un prompt se convierta en una regla de negocio invisible.

El patrón que más me ha convencido: eventos + IA

Una de las arquitecturas que más me ha gustado explorar es la combinación de sistemas orientados a eventos con agentes inteligentes.

La razón es simple: los agentes funcionan especialmente bien cuando reaccionan a eventos. No necesitan controlar el flujo completo. Pueden especializarse en tomar decisiones probabilísticas en los momentos correctos.

OrderCreated
    ↓
AI Fraud Analysis
    ↓
Risk Score Generated
    ↓
Human Approval Required

Lo que me gusta de este modelo es la separación de responsabilidades que surge naturalmente: el flujo determinístico permanece estable y predecible, la IA maneja la incertidumbre donde tiene sentido, los humanos mantienen control en los puntos críticos, y la trazabilidad mejora mucho porque cada evento queda registrado.

No es una bala de plata. Pero creo que muchos sistemas enterprise van a evolucionar hacia algo parecido.

El verdadero reto: no es generar código, es generar contexto

Hay una narrativa popular sobre la IA que dice que el trabajo del developer va a desaparecer porque la IA va a escribir todo el código. Yo creo que esa narrativa está equivocada, o al menos incompleta.

Después de trabajar con estos sistemas un tiempo, el problema que veo que realmente importa es otro:

Context Engineering.

Porque el verdadero reto no es producir código. Es producir el contexto correcto para que los agentes puedan trabajar bien. Y eso requiere:

• documentación real, no la que nadie escribe
• contratos explícitos entre servicios
• ejemplos que capturen los casos edge
• decisiones arquitectónicas registradas y justificadas
• naming consistente que refleje el dominio
• estrategias de testing que cubran los comportamientos importantes
• observabilidad que permita entender qué está pasando

Sin contexto, la IA alucina. Con contexto estructurado, la IA se vuelve extremadamente poderosa.

Y eso está empezando a cambiar el tipo de trabajo que más valor genera en un equipo. Estamos pasando de:

Code Engineering

a algo más parecido a:

Context Engineering

El rol del developer está cambiando, y creo que para bien

Antes el flujo era directo:

Developer → Escribe Código

Ahora empieza a verse más así:

Developer
   ↓
Diseñador de Contexto
   ↓
Agentes IA
   ↓
Validación
   ↓
Software

Los engineers que más van a aportar probablemente ya no serán quienes más código escriban por minuto. Serán quienes mejor sepan estructurar dominio, definir contratos, establecer restricciones, diseñar para la colaboración entre humanos y modelos.

Eso me parece, curiosamente, un trabajo más interesante.

La ironía de todo esto

Hay algo que me genera cierta gracia cuando pienso en todo esto.

Durante años, muchos equipos (yo incluido en algunos momentos) pusimos esas prácticas en segundo plano. TDD ralentizaba. DDD era "demasiado teórico". Clean Architecture era "over-engineering" para el tamaño del proyecto. La documentación "ya la escribimos después".

Y ahora resulta que la IA, esa tecnología que se supone iba a cambiar todo y hacer todo más simple, está haciendo exactamente que todas esas prácticas vuelvan a ser extremadamente valiosas.

Porque los modelos funcionan muchísimo mejor en sistemas con semántica clara, estructura consistente, contratos explícitos y límites bien definidos.

Mientras mejor esté diseñada la arquitectura, mejor será la colaboración entre humanos y modelos.

Conclusión

Estamos entrando en una etapa del desarrollo de software que todavía no terminamos de entender del todo.

Lo que sí creo que es cierto es que el software ya no se construirá solamente para humanos. Se construirá junto con sistemas inteligentes que participan directamente en el ciclo de vida.

Y eso cambia cómo pensamos la arquitectura, el testing, la documentación, el modelado de dominio, la observabilidad, el diseño de sistemas.

La pregunta que más me resuena no es "¿cómo agregamos IA a nuestras aplicaciones?". Esa ya la estamos respondiendo.

La pregunta que creo que vale la pena hacerse es:

¿Qué tipo de arquitectura permite que humanos y modelos evolucionen juntos de forma segura?

No tengo la respuesta completa. Pero creo que vale mucho la pena explorarla.