Las ideas eran buenas. La economía era mala.

La ingeniería de software está llena de ideas que parecen obviamente correctas en cuanto las lees.

Claro que los contracts deberían definir qué puede aceptar y devolver una función. Claro que los tests deberían comprobar properties en vez de unos pocos ejemplos elegidos a mano. Claro que los equipos deberían medir si los tests realmente detectan fallos en lugar de asumir que la coverage basta. Claro que las decisiones de arquitectura deberían mantenerse sincronizadas con el código que gobiernan.

Nada de esto era polémico. El problema era económico. Estas estrategias eran caras justo en el recurso que la mayoría de los equipos no podían multiplicar: atención especializada.

Durante años, muchas estrategias sólidas de ingeniería cayeron en el mismo ciclo. Un equipo adoptaba una. La calidad subía. Después llegaba el coste de mantenimiento. Los contracts se desalineaban. Los property tests quedaban atrás cuando cambiaba el schema. Los surviving mutants se acumulaban sin triage. La documentación de arquitectura se convertía en ficción. La estrategia no fallaba porque estuviera equivocada. Fallaba porque exigía un nivel de expertise continuo que la mayoría de los equipos de producto no podía sostener.

Ese es el verdadero contexto del momento actual de la AI. El cambio importante no es solo que los modelos escriban código más rápido. El cambio importante es que ahora pueden absorber gran parte del trabajo de especificación y verificación que antes volvía estas prácticas demasiado caras.

Lo que realmente mantenía estas estrategias en el nicho

Nunca fue simplemente compute. El compute barato existe desde hace tiempo.

Tampoco fue solo un problema de tooling. Había herramientas buenas para muchas de estas ideas, pero aun así alguien debía saber formular los invariants correctos, los generators correctos, los contracts adecuados y las boundary rules correctas.

El verdadero bottleneck era expertise difícil de paralelizar.

  • Design by contract exigía engineers capaces de escribir y mantener preconditions, postconditions e invariants útiles incluso después de varios refactors.
  • Property-based testing exigía gente que pensara en round trips, idempotencia, comportamiento ante errores y properties algebraicas, no solo en ejemplos.
  • Mutation testing exigía triage de survivors para distinguir huecos reales de equivalent mutants inofensivos.
  • Type-level correctness exigía soltura con branded types, phantom types, typestates o incluso herramientas de verificación formal.
  • Living specifications exigían traducir continuamente decisiones humanas a reglas de arquitectura ejecutables.

Cada estrategia traía su propio impuesto de mantenimiento. Combinarlas era aún más caro, porque además necesitabas el glue entre ellas.

Por eso muchas ideas “good on paper” se quedaron en aerospace, finance, formal methods research o equipos de infraestructura inusualmente disciplinados. Los métodos funcionaban. El modelo de staffing no.

Lo que cambia la AI

La AI no elimina el engineering judgment. Cambia dónde lo gastas.

Antes, un senior engineer tenía que redactar casi todo el scaffolding a mano. Ahora el modelo puede proponer el primer contract, sugerir properties, construir un schema, convertir una decisión en una architecture rule y hasta redactar un regression test inicial para un surviving mutant. La persona revisa la corrección de dominio en lugar de empezar desde cero.

Eso importa mucho más de lo que parece.

El flujo antiguo era author-heavy. El nuevo es review-heavy.

Eso significa:

  • introducir contracts es más barato porque el primer draft ya no es totalmente manual
  • property-based testing se vuelve más accesible porque el modelo puede sugerir round trips, idempotencia y error-raising properties a partir de una firma
  • mutation testing gana utilidad porque la AI ayuda con la clasificación de survivors y con tests dirigidos
  • los architecture constraints se vuelven más exigibles porque las decisiones en lenguaje natural pueden compilarse a checks estáticos

Ese es el verdadero unlock económico. No estás sustituyendo engineers por un modelo. Estás haciendo asequibles estrategias que antes requerían autoría especialista.

La idea importante: estas estrategias se potencian entre sí

La mejor parte no es una técnica aislada.

Lo interesante es que la AI vuelve asequible el stack completo.

Un contract puede alimentar un property test. Un property test puede medirse con mutation testing. Un schema puede definir la runtime boundary. Un ADR puede convertirse en una architecture rule. Un branded type puede estrechar la surface area antes de que corra ningún check de runtime. El valor no está solo en cada pieza. Está en el glue entre piezas.

Antes de la AI, la mayoría de los equipos apenas podía justificar una de estas estrategias. Ahora es realista combinar varias sin convertir reliability work en un programa especializado.

Esto no es magia

También hay una forma equivocada de hacerlo.

Si dejas que la AI genere código, contracts y tests sin enforcement determinista, solo produces una pila más grande de texto plausible. El objetivo no es pedirle al modelo que bendiga tu codebase. El objetivo es usar el modelo para producir artefactos que puedan verificarse de forma barata y repetible.

Por eso el patrón ganador sigue siendo el aburrido:

  • generar con AI
  • validar con herramientas deterministas
  • revisar cambios a nivel de especificación
  • hacer que CI falle rápido cuando una regla se rompe

La AI es valiosa aquí porque cierra la brecha de expertise, no porque deba ser el juez final.

Por qué esto importa ahora mismo

Los equipos ya están usando AI para comprimir el tiempo de implementación. El riesgo es que la velocidad de entrega crezca más rápido que la profundidad de verificación.

Si eso ocurre, no obtienes una organización de ingeniería más productiva. Obtienes un camino más rápido hacia sistemas frágiles.

La oportunidad es usar los mismos modelos que aceleran la generación para resucitar prácticas de reliability que históricamente eran demasiado caras. Así evitas que la velocidad se convierta en deuda operativa.

Los próximos años premiarán a los equipos que entiendan esta diferencia antes. AI-assisted coding por sí solo no es una estrategia. AI-assisted verification and enforcement sí lo es.

Y por eso tantas ideas antiguas de ingeniería vuelven a importar: no porque se hayan vuelto más correctas, sino porque por fin se han vuelto económicamente prácticas.