Desarrollo impulsado por especificaciones de IA: por qué la estructura importa más que nunca

La IA ha cambiado silenciosamente la forma en que construimos software. No en el sentido de "robots sustituyendo a ingenieros". No en el sentido dramático, de reescribir la arquitectura de la noche a la mañana, sino de algo más sutil — y más importante.

El código se ha vuelto barato.

Puedes describir una característica y obtener un borrador funcional en segundos. Controladores, servicios, modelos de bases de datos, pruebas — todo generado antes incluso de que hayas terminado tu café. Y eso cambia las reglas del juego, porque si el código ya no es el cuello de botella, ¿entonces qué lo es?

Claridad.

El verdadero problema no es el código. Es ambigüedad.

La IA es muy buena rellenando huecos. El problema es que no sabe qué huecos son intencionados y cuáles son peligrosos.

Si dices:

"Crea una función segura de restablecimiento de contraseña."

Obtendrás algo que se vea bien.

Pero, ¿lo hizo?

• ¿Hacer cumplir la expiración de los tokens?

• ¿Evitar la reutilización de tokens?

• ¿Añadir límite de velocidad?

• ¿Reiniciar correctamente los tokens de hash?

• ¿Hacer cumplir reglas estrictas de contraseña?

• ¿Definir transiciones de estado claras?

Quizá sí, quizá no.

Y aquí está la incómoda verdad: el resultado parecerá seguro de cualquier manera. Ahí es donde el Desarrollo Impulsado por Especificaciones se vuelve fundamental, especialmente en flujos de trabajo asistidos por IA.

Un breve comentario sobre el desarrollo basado en especulaciones

El Desarrollo Orientado a Especificaciones no es nuevo, en esencia simplemente significa: define el comportamiento del sistema de forma clara y estructural antes (y junto a) la implementación.

No descripciones vagas.
No son requisitos dispersos.
No suposiciones enterradas en reuniones.

Definiciones estructuradas:

• Contratos API

• Reglas de validación de datos

• Transiciones de flujo de trabajo

• Restricciones de seguridad

• Esquemas de bases de datos

En el pasado, esto ayudaba a los equipos a mantenerse alineados, con la IA en la mezcla, hace algo aún más importante: limita la generación.

Hagámoslo realidad: una función de restablecimiento de contraseña

Imagina que implementamos restablecimiento de contraseña en un sistema de producción, en un enfoque tradicional, escribirías algunos tickets, discutirías casos límite y alguien lo implementaría.

En un flujo de trabajo centrado en la IA, podrías organizar la característica de la siguiente manera:

/features/password-reset
  openapi.yaml
  request.schema.json
  business-rules.json
  state-machine.json
  db.sql
  implementation/

Fíjate en lo que ocurre aquí, la función no es solo código, es una colección de definiciones estructuradas, el código se convierte en el último paso — no en el primero.

El contrato API

Usando la especificación OpenAPI, se define:

• /auth/password-reset/request

• /auth/password-reset/confirm

• Organismos solicitantes requeridos

• Respuestas esperadas

• Códigos de estado HTTP

Ahora la IA no puede inventar endpoints ni cambiar la forma de la carga útil sin violar el contrato.

La Capa de Validación

Un esquema JSON define:

• El correo electrónico debe tener un formato válido

• Campos obligatorios

• Tipos explícitos

Esto impide que la IA añada campos extra de forma "útil" o se salte la lógica de validación.

Las reglas de negocio

En lugar de enterrar restricciones en los comentarios, las defines explícitamente:

• El token caduca en 15 minutos

• Solo un token activo por usuario

• La contraseña debe ser de 12+ caracteres

• Debe incluir mayúsculas, número y carácter especial

• Máximo 3 intentos de reinicio por hora

Ahora bien, la IA no está adivinando qué significa "seguro", está implementando restricciones declaradas.

La máquina de estados

Defina los estados permitidos:

• ralentí

• reset_requested

• token_validated

• password_updated

• expirado

Y las transiciones legales entre ellos. De repente, es imposible (por diseño) que la IA permita una actualización de contraseña sin validación de token, la estructura elimina clases enteras de bugs.

La capa de base de datos

Incluso a nivel de almacenamiento, tú defines:

• Hashes de tokens (no tokens en bruto)

• Marcas de tiempo de caducidad

• Índices para consulta

• Restricciones para evitar la reutilización

Ahora bien, incluso si la lógica de la aplicación falla, la base de datos impone invariantes, así es como se ve la especificación en capas.

Por qué esto importa en la era de la IA

La IA normalmente no falla ruidosamente, falla sutilmente, podría:

• Limitación de la tasa de salto

• Pasar por alto un caso límite

• Implementar parcialmente las reglas de contraseña

• Olvidar invalidar los tokens

• Supongamos impagos inseguros

Ninguno de estos errores es dramático, pero a gran escala se acumulan; El verdadero peligro no es un código malo, es un código plausible que nadie cuestiona. La IA acelera la ejecución, las Especificaciones protegen la intención.

El problema de las alucinaciones

Hablemos de la palabra que a nadie le gusta: alucinación. Los modelos de IA a veces completan las piezas que faltan con suposiciones que parecen razonables. En un contexto creativo, está bien, pero en un flujo de trabajo sensible a la seguridad, es peligroso.

Si no especificas explícitamente:

• Límites de tasas

• Políticas de seguridad

• Comportamiento de caducidad

• Requisitos de registro

La IA puede omitirlas, no con mala intención, solo porque no se hayan dicho y la ambigüedad en generación se convierte en vulnerabilidad en el tiempo de ejecución.

Qué cambia cuando adoptas el desarrollo basado en especificaciones de IA

Dejas de revisar la implementación para ver si busca intención y empiezas a revisarla para ver si está alineada.

En lugar de preguntar:

"¿Esto te parece correcto?"

Preguntas:

"¿Esto coincide con la especificación?"

Ese cambio reduce drásticamente la carga cognitiva y también hace que la regeneración sea más segura. Si cambian los requisitos, actualizas la especificación — y regeneras, porque la especificación está estructurada, el sistema evoluciona de forma previsible.

El beneficio mayor

Este enfoque hace más que reducir las alucinaciones.

Mejora:

• Alineación entre equipos

• Postura de seguridad

• Trazabilidad del cumplimiento

• Seguridad en regresión

• Confianza en la regeneración

• Mantenibilidad a largo plazo

Y quizás lo más importante: obliga a la claridad desde el principio.

La IA no elimina la necesidad de pensamiento arquitectónico, amplifica cualquier pensamiento que aportes a ella. Si tus respuestas son vagas, la IA escala la imprecisión; si tus especificaciones están estructuradas, la IA escala la precisión.

La IA ha hecho que escribir código sea más fácil que nunca, pero no ha facilitado definir sistemas; de hecho, ha hecho que la claridad sea más valiosa. El Desarrollo Orientado a Especificaciones en la era de la IA no se trata de documentación.

Se trata de crear límites estructurados para que la velocidad no comprometa la corrección. Porque cuando la generación es instantánea y el código barato, la ambigüedad se convierte en el error más caro de tu sistema.