La forma en que usamos la IA en nuestro día a día como devs va a cambiar radicalmente; ya no será simplemente hacer preguntas aisladas y sin contexto. Ahora lo que se busca es que la IA se encargue de realizar tareas enfocadas en habilidades específicas.
El fin del “Copy-Paste” y el auge de los Agentes
Hasta hace nada, la IA era una pestaña más en el navegador. Hacíamos preguntas, muchas veces sin contexto, y recibíamos fragmentos de código que luego teníamos que adaptar a mano.
Hoy, el paradigma ha evolucionado hacia los Agentes de IA. Ya no solo responden; ahora tienen capacidad de lectura y escritura sobre nuestro código. Han dejado de ser un oráculo externo para convertirse en herramientas integradas en nuestro flujo de trabajo, ejecutando acciones que nosotros mismos haríamos: refactorizar, crear componentes o gestionar estados, pero a una velocidad mucho mayor.
El cuello de botella
Pero no todo es magia. La IA tiene límites; con el tiempo, si no gestionamos bien la información, empieza a divagar o a perder el hilo. Entonces entran en juego las llamadas ventanas de contexto.
Técnicamente, la ventana de contexto es la cantidad máxima de datos (medida en tokens) que un modelo de lenguaje puede “tener en mente” en un momento dado antes de empezar a olvidar el principio de la conversación. Si tu código base y tus instrucciones superan ese límite, la IA empieza a divagar o a perder el hilo de las dependencias.
Para entenderlo, imagina que la ventana de contexto es tu escritorio físico. Cada tarea, cada archivo y cada requerimiento son tokens que ocupan espacio. Si el escritorio se llena de desorden, dejas de ser eficiente. La IA funciona igual: en la medida que le llegan tareas, debe simplificar la información para no saturarse.
SDD: Gestionando el contexto
Para que la IA no se líe, necesitamos técnicas que optimicen su “memoria”. Aquí es donde el SDD (Specification Driven Development) será nuestra mejor aliada. No se trata solo de escribir código, sino de documentar con tal claridad que la IA sepa exactamente qué hacer (y qué evitar).
De esta manera lo que buscamos es tener varios “escritorios” según la necesidad y evitamos acumular todas las tareas, sin importar de qué sean, en un solo lugar.
Podemos dividir el uso de SDD en tres niveles de madurez:
- Spec First: Escribimos una especificación técnica hiperdetallada y delegamos totalmente la implementación a la IA. Nosotros diseñamos la arquitectura; ella escribe los archivos.
- Spec Anchor: La documentación no es un paso previo, sino un “ancla”. Evoluciona junto al código, sirviendo como punto de referencia constante para que la IA no pierda el rumbo en refactorizaciones futuras.
- Spec as Source: El nivel más ambicioso. La documentación es la fuente de verdad única. El humano solo mantiene la especificación y la IA se encarga de que el código refleje esos cambios. El código se vuelve un “artefacto” generado, no algo que tocamos directamente.
Skill vs. SDD
Un skill es una capacidad ejecutable que un agente de IA puede invocar en tiempo de ejecución. Define:
- Qué puede hacer el agente (buscar, enviar un correo, consultar una API, etc.).
- Cómo se invoca internamente por el LLM (nombre, descripción en lenguaje natural, parámetros).
- Lógica o handler que se ejecuta cuando el agente decide usar ese skill.
El skill está diseñado para ser entendido por el modelo —la descripción en lenguaje natural es clave para que el agente sepa cuándo y cómo usarlo—. Es una unidad de comportamiento.
Una spec, por otro lado, es un contrato formal que describe una interfaz. Define:
- Endpoints, métodos, parámetros, esquemas de datos.
- Contratos entre sistemas (productor/consumidor).
- Sirve como fuente de verdad para generar código, documentación, mocks y tests.
La spec está diseñada para ser entendida por máquinas y humanos igualmente. Es una unidad de descripción de interfaz.
¿Cómo se relacionan?
Frecuentemente un skill se construye encima de una spec. El flujo típico es:
OpenAPI Spec → implementación del endpoint → skill que lo envuelve para el agente
La spec define qué existe, el skill define cómo el agente lo puede usar con contexto semántico añadido (descripción en lenguaje natural, cuándo aplicarlo, qué significa cada parámetro para el modelo).
El stack de documentación moderna
Están apareciendo herramientas que facilitan la creación de esta “fuente de verdad” técnica. Herramientas como Kiro, Speckit y Tessl están diseñadas para que generar esa documentación no sea una carga, sino la parte más importante de nuestro proceso de desarrollo.
La IA es hoy tan buena como el contexto que le proporcionamos. El reto ya no es solo saber programar, sino saber especificar.
Ejemplo de un Spec
# 📋 Spec: Registro de Usuario (Frontend)
---
## 1. Resumen
| Campo | Detalle |
|---|---|
| **Feature** | Registro de Usuario |
| **Área** | Frontend |
| **Prioridad** | Alta |
| **Estado** | Borrador |
| **Autor** | — |
| **Fecha** | 2026-03-05 |
---
## 2. Objetivo
Permitir que un nuevo usuario cree una cuenta en la plataforma mediante un formulario web, validando sus datos en el cliente antes de enviarlos al backend.
---
## 3. Contexto y Motivación
Actualmente no existe un flujo de registro. Los usuarios no pueden crear cuentas de forma autónoma. Esta feature habilita el punto de entrada principal al producto.
---
## 4. Alcance
### ✅ Dentro del alcance
- Formulario de registro con campos básicos.
- Validaciones en el cliente (frontend).
- Feedback visual de errores y éxito.
- Integración con el endpoint `POST /api/auth/register`.
- Redirección tras registro exitoso.
### ❌ Fuera del alcance
- Lógica del backend / base de datos.
- Registro con redes sociales (OAuth).
- Verificación de correo electrónico.
- Flujo de inicio de sesión (Login).
---
## 5. Diseño de la UI
### Campos del formulario
| Campo | Tipo | Requerido | Validación |
|---|---|---|---|
| Nombre | `text` | ✅ | Mínimo 2 caracteres |
| Apellido | `text` | ✅ | Mínimo 2 caracteres |
| Correo electrónico | `email` | ✅ | Formato válido de email |
| Contraseña | `password` | ✅ | Mínimo 8 caracteres, 1 mayúscula, 1 número |
| Confirmar contraseña | `password` | ✅ | Debe coincidir con "Contraseña" |
### Elementos de la página
- **Título:** "Crear cuenta"
- **Botón de envío:** "Registrarse" (deshabilitado hasta que el formulario sea válido)
- **Link:** "¿Ya tienes cuenta? Inicia sesión" → redirige a `/login`
---
## 6. Comportamiento Esperado
### Flujo principal (Happy Path)
1. El usuario navega a `/register`.
2. Completa todos los campos correctamente.
3. Hace clic en **"Registrarse"**.
4. Se muestra un spinner de carga mientras se procesa.
5. El backend responde con `201 Created`.
6. Se muestra un mensaje de éxito: *"¡Cuenta creada exitosamente!"*
7. El usuario es redirigido a `/dashboard` después de 2 segundos.
### Flujos alternativos
| Escenario | Comportamiento |
|---|---|
| Campo inválido | Se muestra mensaje de error debajo del campo afectado |
| Correo ya registrado | Se muestra error: *"Este correo ya está en uso"* |
| Error de red / servidor | Se muestra banner: *"Ocurrió un error. Intenta de nuevo."* |
| Contraseñas no coinciden | Error en campo "Confirmar contraseña" en tiempo real |
---
## 7. Criterios de Aceptación
Feature: Registro de usuario
Scenario: Registro exitoso
**Given** el usuario está en /register
**When** completa todos los campos válidos
**And** hace clic en "Registrarse"
**Then** ve el mensaje "¡Cuenta creada exitosamente!"
**And** es redirigido a /dashboard
Scenario: Email con formato inválido
**Given** el usuario está en /register
**When** ingresa "usuario@" en el campo de correo
**Then** ve el mensaje de error "Ingresa un correo válido"
**And** el botón "Registrarse" permanece deshabilitado
Scenario: Contraseñas no coinciden
**Given** el usuario completó el campo "Contraseña"
**When** ingresa una contraseña diferente en "Confirmar contraseña"
**Then** ve el mensaje "Las contraseñas no coinciden"
Scenario: Correo ya registrado
**Given** el usuario envía el formulario con un correo existente
**When** el backend responde con 409 Conflict
**Then** ve el mensaje "Este correo ya está en uso"
## 8. Contrato con el Backend
### Request
POST /api/auth/register
Content-Type: application/json
{
"firstName": "string",
"lastName": "string",
"email": "string",
"password": "string"
}
### Responses esperadas
| Código | Significado | Acción en UI |
|---|---|---|
| `201 Created` | Registro exitoso | Mostrar éxito → redirigir |
| `409 Conflict` | Email duplicado | Mostrar error en campo email |
| `422 Unprocessable` | Datos inválidos | Mostrar errores por campo |
| `500 Server Error` | Error del servidor | Mostrar banner de error general |
---
## 9. Consideraciones Técnicas
Revisar el archivo de especificaciones tecnicas `angular-tech.md`
---
## 10. Tareas (Tasks)
[ ] Crear componente RegisterForm
[ ] Implementar validaciones client-side
[ ] Integrar con endpoint POST /api/auth/register
[ ] Manejar estados: loading, error, success
[ ] Escribir unit tests para validaciones
[ ] Escribir test de integración (happy path)
[ ] Revisión de accesibilidad (a11y)
[ ] Revisión de diseño con UI/UX