Week 10 — Construir Features Completas con IA

1. Objetivos de Week 10

OBJETIVO CENTRAL

Construir una funcionalidad end-to-end utilizando IA

Hasta ahora hemos trabajado con tareas relativamente pequeñas. Esta semana cambia la escala. El alumno aprenderá a coger un requisito de negocio y convertirlo en una funcionalidad completa.

Descomponer

Dividir una feature grande en unidades manejables.

Planificar

Crear un plan técnico antes de modificar el proyecto.

Delegar

Asignar tareas al agente de forma progresiva.

Integrar

Conectar base de datos, backend, API y frontend.

Validar

Comprobar que la implementación realmente cumple el requisito.

Documentar

Mantener la documentación alineada con el producto.

2. Continuidad con Weeks 08–09

No empezamos desde cero

El proyecto ya dispone de:

employee-management/

├── README.md
├── AGENTS.md
├── CONTRIBUTING.md
├── .env.example
│
├── docs/
│   ├── product.md
│   ├── architecture.md
│   ├── database.md
│   ├── api.md
│   ├── security.md
│   ├── testing.md
│   ├── ai-development-workflow.md
│   │
│   ├── requirements/
│   │   ├── US-001.md
│   │   └── US-002.md
│   │
│   └── decisions/
│
├── src/
├── tests/
└── scripts/

Lo aprendido anteriormente

Semana	Competencia
08	Preparar contexto AI-Ready.
09	Delegar tareas a agentes.
10	Construir features completas.

La idea fundamental

El agente no sustituye el proceso de desarrollo.

El agente acelera el proceso de desarrollo.

3. ¿Qué entendemos por Feature?

Una feature es una capacidad del producto que proporciona valor al usuario.

Ejemplo

"Crear empleados" es una feature. Pero técnicamente puede implicar:

Usuario
   ↓
Formulario
   ↓
Validación
   ↓
API
   ↓
Servicio
   ↓
Base de datos
   ↓
Respuesta
   ↓
UI actualizada

Error habitual

Pensar que:

Feature = archivo que tengo que modificar

Cuando realmente:

Feature = comportamiento completo del sistema

4. Descomponer una Feature

Una de las habilidades más importantes del desarrollador apoyado por IA es saber dividir problemas.

Feature demasiado grande

Implementa todo el sistema de empleados.

El agente no sabe por dónde empezar y puede tomar decisiones arbitrarias.

Feature correctamente descompuesta

EMPLOYEE MANAGEMENT

1. Crear empleado

2. Consultar empleado

3. Listar empleados

4. Editar empleado

5. Desactivar empleado

6. Buscar empleados

7. Filtrar por disponibilidad

8. Historial del empleado

Y cada feature puede dividirse nuevamente

Crear empleado

├── Database
│   └── Employee table
│
├── Backend
│   ├── Entity
│   ├── Repository
│   └── Service
│
├── API
│   └── POST /employees
│
├── Frontend
│   └── EmployeeForm
│
├── Validation
│
├── Tests
│
└── Documentation

5. Workflow completo

1. Business Requirement

Entender qué quiere conseguir el usuario.

2. Acceptance Criteria

Definir qué significa "correcto".

3. Context Discovery

El agente analiza el proyecto existente.

4. Technical Planning

Se diseña la solución técnica.

5. Task Breakdown

La feature se divide en tareas.

6. Implementation

El agente implementa cada parte.

7. Testing

Se ejecutan tests automáticos y manuales.

8. Integration

Se verifica el comportamiento completo.

9. Review

Se revisan cambios, arquitectura y seguridad.

10. Delivery

Se prepara el cambio para integración.

6. Context Discovery

Antes de construir debemos conseguir que el agente entienda dónde está trabajando.

Prompt recomendado

Quiero implementar una nueva feature
en este proyecto.

Antes de hacer ningún cambio:

1. Lee AGENTS.md.
2. Lee README.md.
3. Lee docs/product.md.
4. Lee docs/architecture.md.
5. Lee docs/database.md.
6. Lee docs/api.md.
7. Lee docs/security.md.
8. Lee docs/testing.md.

Después analiza:

- arquitectura actual;
- componentes reutilizables;
- modelo de datos;
- patrones existentes;
- APIs existentes;
- estrategia de testing.

No modifiques archivos.

Devuelve un resumen técnico
del estado actual del sistema.

¿Por qué hacer esto?

Porque una IA puede escribir código técnicamente correcto pero incompatible con el proyecto.

Ejemplo:

Proyecto usa:

Repository Pattern

Agente crea:

acceso directo a DB

Resultado:

código funcional
+
arquitectura inconsistente

7. Technical Planning

Ahora pedimos al agente que transforme el requisito de negocio en arquitectura técnica.

Ejemplo

REQUISITO

Como responsable de RRHH,
quiero poder crear un empleado
para incorporarlo al sistema.

El agente debería convertirlo en:

PLAN TÉCNICO

Database
    ↓
Employee table

Domain
    ↓
Employee entity

Repository
    ↓
EmployeeRepository

Service
    ↓
EmployeeService

API
    ↓
POST /employees

Validation
    ↓
EmployeeValidator

Frontend
    ↓
EmployeeForm

Testing
    ↓
Unit + Integration + E2E

Nunca confundas plan con código

El plan debe ser comprensible antes de empezar a programar.

8. Backend como tarea delegada

Una vez aprobado el plan, podemos delegar una parte concreta.

Prompt

Implementa la parte backend
de US-001.

Alcance:

- Employee entity
- Repository
- Service
- validaciones
- endpoint POST /employees

Respeta:

- arquitectura existente;
- patrones existentes;
- security.md;
- api.md.

No modifiques frontend.

Añade tests.

Antes de terminar:

- ejecuta tests;
- revisa errores;
- muestra archivos modificados;
- explica las decisiones relevantes.

Resultado esperado

Backend

✓ Entity
✓ Repository
✓ Service
✓ Validation
✓ API
✓ Unit tests
✓ Integration tests

9. Frontend

Ahora delegamos otra parte.

Prompt

Implementa el frontend
para US-001.

Utiliza los componentes
existentes del proyecto.

No crees un nuevo sistema
de diseño.

La pantalla debe permitir:

- nombre;
- email;
- departamento;
- fecha de incorporación.

Validaciones:

- nombre obligatorio;
- email válido;
- departamento obligatorio.

Estados:

- loading;
- success;
- error.

Añade tests.

No modifiques backend.

Concepto importante

El agente debe reutilizar lo que ya existe antes de crear nuevos componentes.

10. Testing asistido por IA

Una feature completa necesita varias capas de testing.

Tipo	Qué comprueba
Unit	Una unidad aislada.
Integration	Varias piezas funcionando juntas.
API	Contrato de una API.
E2E	Flujo completo del usuario.
Manual	Comportamiento visual y funcional.

Ejemplo E2E

1. Abrir aplicación.

2. Entrar en empleados.

3. Pulsar "Nuevo empleado".

4. Introducir datos.

5. Pulsar guardar.

6. Comprobar mensaje de éxito.

7. Volver al listado.

8. Comprobar que aparece el empleado.

Pedir tests al agente

Crea tests para los acceptance criteria.

Para cada criterio indica:

- test;
- tipo de test;
- resultado esperado.

No des por válido
el comportamiento simplemente
porque el código compile.

11. Integración End-to-End

Ahora viene una de las partes más importantes.

DATABASE
   ↑
BACKEND
   ↑
API
   ↑
FRONTEND
   ↑
USER

Todas las capas deben hablar el mismo idioma.

Ejemplo de inconsistencia

Frontend:

departmentId

API:

department

Database:

department_id

Cada parte puede funcionar individualmente y aun así la feature completa fallar.

Por eso necesitamos integración

No basta con:

backend tests = PASS

frontend tests = PASS

Necesitamos también:

user journey = PASS

12. Review de una Feature Completa

Checklist técnico

¿Cumple todos los requisitos?
¿Cumple todos los acceptance criteria?
¿Se respetó la arquitectura?
¿Se reutilizaron componentes?
¿Existen tests?
¿Hay tests de integración?
¿Se gestionan errores?
¿Se validan inputs?
¿Se han revisado permisos?
¿Hay información sensible expuesta?
¿Se actualizó documentación?
¿Se modificaron archivos innecesarios?

Prompt de review

Realiza una revisión completa
de la feature US-001.

No modifiques ningún archivo.

Comprueba:

1. Requirements.
2. Acceptance criteria.
3. Architecture.
4. Security.
5. Database.
6. API.
7. Frontend.
8. Tests.
9. Error handling.
10. Documentation.

Clasifica cada problema:

CRITICAL
HIGH
MEDIUM
LOW

Para cada problema indica:

- ubicación;
- causa;
- impacto;
- recomendación.

13. Proyecto práctico Week 10

PROYECTO PRINCIPAL

Construir US-002 End-to-End

Esta semana vamos a implementar una nueva feature completa.

Consultar y visualizar el detalle de un empleado.

Requisito de negocio

Como usuario del sistema,

quiero seleccionar un empleado
desde el listado

para consultar toda su información
y conocer su situación actual.

Acceptance Criteria

AC1
El usuario puede seleccionar un empleado.

AC2
Se muestra el nombre.

AC3
Se muestra el email.

AC4
Se muestra el departamento.

AC5
Se muestra la fecha de incorporación.

AC6
Se muestra su estado actual.

AC7
Si el empleado no existe,
se muestra un error.

AC8
La pantalla tiene estado loading.

AC9
Los errores se muestran
de forma comprensible.

AC10
La funcionalidad tiene tests.

AC11
Los tests existentes continúan pasando.

Fase 1 — Crear branch

git checkout -b feature/employee-detail

Fase 2 — Discovery

Pide al agente analizar el sistema sin modificar archivos.

Fase 3 — Plan

Debe identificar:

endpoint necesario;
modelo de datos;
servicios reutilizables;
componentes frontend;
tests;
documentación.

Fase 4 — Aprobar plan

El alumno revisa el plan manualmente.

Fase 5 — Backend

Delegar:

GET /employees/{id}

Fase 6 — Tests backend

Debe cubrir:

empleado existente;
empleado inexistente;
ID inválido;
errores de base de datos.

Fase 7 — Frontend

Construir:

EmployeeList
      ↓
EmployeeRow
      ↓
EmployeeDetail

Fase 8 — Estados

LOADING
   ↓
SUCCESS
   ↓
DETAIL

o

ERROR
   ↓
ERROR MESSAGE

Fase 9 — E2E

Comprobar el flujo completo.

Fase 10 — Review

Utilizar el prompt de revisión de esta semana.

Fase 11 — Documentación

Actualizar:

docs/api.md

docs/requirements/US-002.md

docs/testing.md

Fase 12 — Entrega

git status

git diff

git log --oneline

Resultado esperado

El alumno debe tener una feature completa funcionando desde la interfaz hasta la base de datos.

14. Ejercicios prácticos

Ejercicio 1 — Descomposición

Divide:

"Quiero poder buscar empleados."

en al menos 6 tareas técnicas.

Ver respuesta orientativa

1. Definir criterios de búsqueda.

2. Diseñar API.

3. Implementar query backend.

4. Implementar endpoint.

5. Crear componente de búsqueda.

6. Conectar frontend con API.

7. Añadir tests.

8. Añadir E2E.

9. Actualizar documentación.

Ejercicio 2 — Identificar una feature demasiado grande

¿Es adecuada esta tarea?

Construye todo el módulo de RRHH.

Ver respuesta

No. Es demasiado amplia. Debería dividirse en features independientes:

empleados;
departamentos;
proyectos;
disponibilidad;
vacaciones;
formación;
reporting.

Ejercicio 3 — ¿Qué falta?

Tenemos:

Backend tests = PASS
Frontend tests = PASS

¿Podemos considerar terminada la feature?

Ver respuesta

No necesariamente. Faltan pruebas de integración, flujo completo y validación contra los acceptance criteria.

Ejercicio 4 — Ambigüedad

El requisito dice:

"Mostrar el estado del empleado."

¿Qué deberíamos aclarar?

Ver respuesta

¿Qué estados existen?
¿Quién los puede modificar?
¿Activo/inactivo?
¿Bench?
¿Asignado?
¿Vacaciones?
¿Formación?
¿Cuál es la fuente de datos?
¿Puede tener varios estados?

Ejercicio 5 — Reutilización

El agente quiere crear un nuevo componente de formulario cuando ya existe uno similar. ¿Qué harías?

Ver respuesta

Pedir al agente que analice primero el componente existente y determine si puede reutilizarse.

Ejercicio 6 — Diseñar un workflow

Ordena correctamente:

Review
Implementation
Requirement
Testing
Planning
Context
Acceptance Criteria

Ver respuesta

Requirement
      ↓
Acceptance Criteria
      ↓
Context
      ↓
Planning
      ↓
Implementation
      ↓
Testing
      ↓
Review

Ejercicio 7 — Edge Cases

Para "consultar empleado", identifica al menos 8 casos límite.

Ver respuesta orientativa

ID inexistente.
ID vacío.
ID negativo.
ID con texto.
Empleado desactivado.
Empleado sin departamento.
Empleado con datos incompletos.
Error de base de datos.
Timeout.
Usuario sin permisos.

15. Ejercicio avanzado — Feature Contract

Crea un documento:

docs/features/US-002-contract.md

Debe contener:

objetivo;
actores;
inputs;
outputs;
errores;
permisos;
acceptance criteria;
API contract;
estados de UI;
tests.

Ver estructura orientativa

# US-002 Contract

## Objective

Consultar detalle de empleado.

## Input

employeeId

## Output

EmployeeDetail

## Errors

404
400
401
403
500

## UI states

Loading
Success
Error

## Security

Authenticated users only.

## Acceptance Criteria

AC1...
AC2...
AC3...

## Tests

Unit
Integration
API
E2E

17. Recursos externos

Claude Code — documentación oficial
Documentación sobre agentes de desarrollo y workflows. Cursor — documentación oficial
Documentación del entorno de desarrollo asistido por agentes. GitHub Copilot
Documentación oficial sobre Copilot. Model Context Protocol
Documentación del protocolo MCP para conectar modelos con herramientas. Martin Fowler — Exploring Generative AI
Material sobre IA generativa aplicada al desarrollo de software. OWASP Top 10
Referencia fundamental para seguridad de aplicaciones. The Twelve-Factor App
Principios para construir aplicaciones modernas y mantenibles. Martin Fowler — Test Pyramid
Introducción práctica a las diferentes capas de testing.

19. Métrica de aprendizaje

Nivel de autonomía

Nivel	Descripción
1	Uso IA para resolver dudas.
2	IA genera pequeños cambios.
3	Agente implementa tareas.
4	Agente implementa features.
5	Dirijo un workflow completo de desarrollo con IA.

Objetivo Week 10: alcanzar nivel 4.

20. Conclusión

La nueva forma de desarrollar

ANTES

Tengo una idea
      ↓
Escribo código
      ↓
Pruebo
      ↓
Corrijo


AHORA

Tengo una idea
      ↓
Defino requisito
      ↓
Defino acceptance criteria
      ↓
Proporciono contexto
      ↓
Pido análisis
      ↓
Reviso plan
      ↓
Delego implementación
      ↓
Tests
      ↓
Integración
      ↓
Review
      ↓
Validación humana

Competencia adquirida

El alumno ya no necesita pensar:

"¿Cómo escribo este código?"

Empieza a pensar:

"¿Cómo estructuro este problema
para que un agente pueda resolverlo
de forma segura y verificable?"

Próximo paso — Week 11

Ahora que sabemos construir funcionalidades con agentes, el siguiente problema es inevitable:

¿Qué hacemos cuando el agente
construye algo que NO funciona?

En Week 11 nos centraremos en debugging asistido por IA:

leer logs;
analizar stack traces;
reproducir errores;
formular hipótesis;
aislar causas;
corregir bugs;
evitar regresiones;
utilizar agentes para investigar problemas complejos.

1. Objetivos de Week 10

Construir una funcionalidad end-to-end utilizando IA

Descomponer

Planificar

Delegar

Integrar

Validar

Documentar

2. Continuidad con Weeks 08–09

No empezamos desde cero

Lo aprendido anteriormente

La idea fundamental

3. ¿Qué entendemos por Feature?

Ejemplo

Error habitual

4. Descomponer una Feature

Feature demasiado grande

Feature correctamente descompuesta

Y cada feature puede dividirse nuevamente

5. Workflow completo

1. Business Requirement

2. Acceptance Criteria

3. Context Discovery

4. Technical Planning

5. Task Breakdown

6. Implementation

7. Testing

8. Integration

9. Review

10. Delivery

6. Context Discovery

Prompt recomendado

¿Por qué hacer esto?

7. Technical Planning

Ejemplo

Nunca confundas plan con código

8. Backend como tarea delegada

Prompt

Resultado esperado

9. Frontend

Prompt

Concepto importante

10. Testing asistido por IA

Ejemplo E2E

Pedir tests al agente

11. Integración End-to-End

Ejemplo de inconsistencia

Por eso necesitamos integración

12. Review de una Feature Completa

Checklist técnico

Prompt de review

13. Proyecto práctico Week 10

Construir US-002 End-to-End

Requisito de negocio

Acceptance Criteria

Fase 1 — Crear branch

Fase 2 — Discovery

Fase 3 — Plan

Fase 4 — Aprobar plan

Fase 5 — Backend

Fase 6 — Tests backend

Fase 7 — Frontend

Fase 8 — Estados

Fase 9 — E2E

Fase 10 — Review

Fase 11 — Documentación

Fase 12 — Entrega

Resultado esperado

14. Ejercicios prácticos

Ejercicio 1 — Descomposición

Ejercicio 2 — Identificar una feature demasiado grande

Ejercicio 3 — ¿Qué falta?

Ejercicio 4 — Ambigüedad

Ejercicio 5 — Reutilización

Ejercicio 6 — Diseñar un workflow

Ejercicio 7 — Edge Cases

15. Ejercicio avanzado — Feature Contract

16. Test de evaluación

Pregunta 1

Pregunta 2