Por Qué Estandarizamos el Diseño Guiado por Especificaciones

El problema

Un founder llegó a nosotros después de un sprint complicado. Su equipo había usado un agente de IA para construir un backend de facturación multi-tenant directamente desde un brief de producto — sin un paso de diseño intermedio, del prompt directo al pull request. Funcionó en la demo. Tres semanas después, en producción, algunos tenants empezaron a ver facturas de otros bajo carga.

La causa raíz no fue la IA. Fue que nadie — ni humano ni modelo — había escrito nunca qué significaba “aislamiento entre tenants” en términos contra los que el sistema pudiera verificarse. El brief describía un producto. Nunca describió un contrato.

La decisión

Estandarizamos todos nuestros proyectos de arquitectura, asistidos por IA o no, sobre diseño guiado por especificaciones: antes de cualquier implementación, escribimos una especificación contra la que el sistema pueda en principio verificarse — límites de propiedad de datos, invariantes que nunca deben romperse, y los modos de falla explícitos para los que estamos diseñando. No es un documento de requerimientos. Es un contrato.

Esto importa más, no menos, cuando hay agentes de IA escribiendo código. Un agente producirá con gusto código que se ve plausible para un brief ambiguo — no tiene forma de saber cuáles ambigüedades son críticas. Una especificación escrita elimina la ambigüedad antes de que empiece la generación, que es exactamente lo mismo que convierte el output de la IA de “se ve bien” a algo que un ingeniero senior puede verificar de verdad en revisión.

En la práctica esto significa:

• Cada límite de servicio recibe una declaración explícita de propiedad — qué datos posee, cuáles nunca toca
• Los invariantes se escriben como afirmaciones verificables, no en prosa (“una consulta de un tenant nunca puede devolver filas fuera de su tenant_id” — no “el sistema debería mantener separados a los tenants”)
• Los modos de falla se enumeran antes de la primera línea de código de implementación

El resultado

En la reconstrucción, el mismo equipo — usando el mismo flujo asistido por IA — entregó el backend de facturación corregido en menos de dos semanas, con el invariante de aislamiento entre tenants aplicado en la capa de consultas y cubierto por una prueba que habría detectado el error original desde el primer día. La especificación no ralentizó el trabajo asistido por IA. Le dio tanto al modelo como a los humanos que revisaban su output algo concreto contra qué verificar.

Hoy este es nuestro estándar, no la excepción — así es como moldea nuestros proyectos de consultoría de arquitectura de software desde la primera sesión de trabajo.