Debugging con IA

1. Objetivos de Week 11

2. La nueva mentalidad

ERROR

↓
Copiar error en ChatGPT

↓
"Arréglalo"

↓
Copiar código

↓
Esperar que funcione

ERROR

↓

REPRODUCIR

↓

RECOGER EVIDENCIAS

↓

FORMULAR HIPÓTESIS

↓

INVESTIGAR

↓

CAMBIO MÍNIMO

↓

TEST

↓

VERIFICAR

↓

PREVENIR REGRESIÓN

La IA puede ayudarnos en todas estas fases, pero el desarrollador debe controlar el proceso.

3. ¿Qué es realmente un bug?

Un bug es un comportamiento del sistema que no cumple lo esperado.

Ejemplo

EXPECTED

GET /employees/123

→ 200 OK

→ empleado 123


ACTUAL

GET /employees/123

→ 500 Internal Server Error

El error visible es:

500 Internal Server Error

Pero eso NO nos dice necesariamente cuál es la causa.

El error es un síntoma. No necesariamente es la causa.

4. Workflow profesional de debugging

5. Aprender a leer Logs

Los logs son una de las fuentes de información más importantes durante una investigación.

Ejemplo

2026-08-28 10:31:42 INFO Request received
GET /employees/123

2026-08-28 10:31:42 INFO EmployeeService.findById(123)

2026-08-28 10:31:42 ERROR Database error

SQLSTATE[42P01]:
relation "employees" does not exist

2026-08-28 10:31:42 ERROR
GET /employees/123 → 500

¿Cómo lo interpretamos?

Frontend
   ↓
API
   ↓
Service
   ↓
DATABASE ← PROBLEMA PROBABLE

6. Cómo leer un Stack Trace

Un stack trace puede parecer aterrador al principio.

NullPointerException:
Cannot read properties of null

    at EmployeeService.getDepartment
        (EmployeeService.js:48)

    at EmployeeController.getEmployee
        (EmployeeController.js:21)

    at processRequest
        (router.js:102)

Leer de abajo hacia arriba o de arriba hacia abajo?

Depende del lenguaje y del formato, pero normalmente nos interesa identificar la primera línea que pertenece a nuestro código y que está relacionada con la causa.

Aquí

EmployeeService.js:48

es especialmente interesante.

7. Reproducir el problema

Antes de pedir a la IA que arregle algo, debemos intentar conseguir un caso reproducible.

Mala descripción

"No funciona."

Buena descripción

Cuando un usuario abre

Employees → Employee Detail

y el empleado no tiene departamento,

la API devuelve 500.

Con empleados que tienen departamento,
funciona correctamente.

Excelente descripción

ENVIRONMENT

Local development

REQUEST

GET /employees/123

INPUT

employeeId = 123

EXPECTED

200 OK

ACTUAL

500 Internal Server Error

CONDITION

employee.department_id = NULL

REPRODUCIBILITY

100%

LOG

Cannot read properties of null
at EmployeeService.js:48

8. Formular hipótesis

Antes de modificar código, debemos preguntarnos:

¿Qué podría estar causando este comportamiento?

Ejemplo

PROBLEMA

Employee detail devuelve 500
si department_id = NULL.


HIPÓTESIS 1

El backend asume que department
siempre existe.


HIPÓTESIS 2

El JOIN SQL elimina el registro.


HIPÓTESIS 3

El serializer no acepta NULL.


HIPÓTESIS 4

El frontend espera department.name.

Ahora podemos investigar cada hipótesis.

Hipótesis

↓

Evidencia

↓

Confirmar / descartar

↓

Nueva hipótesis

↓

Solución

9. Prompts profesionales para debugging

Prompt 1 — Análisis inicial

Estoy investigando un bug.

NO modifiques ningún archivo.

Primero analiza:

1. El error.
2. El stack trace.
3. El código relacionado.
4. Los tests existentes.
5. El comportamiento esperado.

Después:

- identifica posibles causas;
- clasifícalas por probabilidad;
- indica qué evidencia necesitamos para confirmar
  o descartar cada una.

No propongas todavía una solución definitiva.

Prompt 2 — Investigación dirigida

Tenemos estas evidencias:

[PEGAR EVIDENCIAS]

Hipótesis actual:

[HIPÓTESIS]

Analiza el código relevante.

Quiero que determines:

1. Si la hipótesis es correcta.
2. Qué líneas la soportan.
3. Qué líneas la contradicen.
4. Qué información falta.

No modifiques código.

Prompt 3 — Proponer solución

La causa raíz parece ser:

[CAUSA]

Propón la solución mínima.

Antes de modificar:

- explica qué archivos cambiarás;
- explica por qué;
- identifica posibles efectos secundarios;
- indica qué tests deberían cubrir el problema.

No implementes todavía.

Prompt 4 — Implementación

Implementa únicamente la solución aprobada.

No hagas refactoring adicional.

Añade un regression test que reproduzca
el bug original.

Ejecuta los tests relacionados.

Después informa:

- archivos modificados;
- tests ejecutados;
- resultado;
- posibles riesgos.

Prompt 5 — Segunda revisión

El bug está corregido.

Ahora intenta encontrar una forma
de romper la solución.

Busca:

- edge cases;
- inputs inesperados;
- estados NULL;
- problemas de permisos;
- regresiones;
- efectos secundarios.

No modifiques código.

Devuelve una lista priorizada
de posibles problemas.

10. Utilizar un agente para investigar

Los agentes son especialmente útiles cuando el problema atraviesa muchos archivos.

Ejemplo

Bug:

El listado de empleados tarda 8 segundos
cuando existen más de 10.000 empleados.

Podemos pedir:

Investiga el problema de rendimiento
del listado de empleados.

No modifiques código.

Analiza:

- endpoint;
- controller;
- service;
- repository;
- queries;
- índices;
- serialización;
- frontend;
- paginación;
- tests.

Busca posibles cuellos de botella.

Para cada uno indica:

- evidencia;
- impacto estimado;
- probabilidad;
- recomendación.

No implementes ninguna solución.

El agente puede descubrir

Frontend
   ↓
GET /employees
   ↓
Service
   ↓
Repository
   ↓
SELECT *
FROM employees

10.000 rows

↓
Sin paginación

↓
Serialización completa

↓
8 segundos

La solución puede ser evidente:

Pagination

+

SELECT campos necesarios

+

Índices adecuados

Pero lo importante es que la IA ha ayudado a investigar, no simplemente a escribir código.

11. Regression Testing

Una corrección profesional no termina cuando el error desaparece.

Problema

Bug encontrado

↓

Fix

↓

Funciona

↓

Dos meses después...

↓

BUG VUELVE

Para evitarlo necesitamos un regression test.

Ejemplo

BUG ORIGINAL

Empleado sin departamento

↓

API devuelve 500


REGRESSION TEST

Employee department = NULL

↓

GET /employees/{id}

↓

Expected: 200

↓

PASS

12. Debugging y seguridad

Los errores pueden contener información sensible.

Nunca compartas sin revisar

• tokens;
• passwords;
• API keys;
• JWT completos;
• datos personales innecesarios;
• credenciales de producción;
• secretos de infraestructura.

DATABASE_URL=
postgres://admin:
MyPassword123@
production-db.example.com

DATABASE_URL=
postgres://[REDACTED]

13. Proyecto práctico Week 11

Bug 1 — Empleado sin departamento

Condición:

department_id = NULL

Resultado:

GET /employees/{id}

→ 500

Bug 2 — ID inexistente

GET /employees/999999

Resultado actual:

500

Resultado esperado:

404

Bug 3 — Búsqueda lenta

Buscar:

"Juan"

Resultado:

La interfaz tarda más de 5 segundos.

Para cada bug

1. Reproducir.
2. Documentar comportamiento esperado.
3. Documentar comportamiento actual.
4. Recoger logs.
5. Crear hipótesis.
6. Utilizar IA para investigar.
7. Identificar causa raíz.
8. Crear plan de solución.
9. Implementar.
10. Crear regression test.
11. Ejecutar tests.
12. Realizar review.

Entregables

docs/bugs/

├── BUG-001.md
├── BUG-002.md
└── BUG-003.md


tests/

└── regression/


docs/

└── debugging.md

Plantilla BUG-001.md

# BUG-001

## Title

Employee without department returns 500

## Environment

Local

## Expected

200 OK

## Actual

500

## Steps to reproduce

1.
2.
3.

## Evidence

Logs...

## Hypotheses

1.
2.
3.

## Root cause

...

## Solution

...

## Regression test

...

## Verification

...

## Lessons learned

...

14. Ejercicios prácticos

HTTP 500

"La pantalla de empleados falla."

Título:
Employee detail returns 500 for employees
without department.

Environment:
Local.

Steps:
1. Open employee list.
2. Select employee 123.
3. Employee has department_id = NULL.

Expected:
Employee detail loads correctly.

Actual:
HTTP 500.

Reproducibility:
100%.

Evidence:
NullPointerException at
EmployeeService.js:48.

A)

"Arregla este bug."


B)

"Investiga este bug.
No modifiques código.
Analiza logs, stack trace y código.
Propón hipótesis y dime qué evidencia
necesitamos para confirmar cada una."

Authorization: Bearer eyJhbGciOi...

Authorization: Bearer [REDACTED]

Cannot read property "name" of null

15. Ejercicio avanzado — Debugging con agente

Cuando se buscan empleados
por nombre,

la primera búsqueda funciona,

pero las siguientes búsquedas
muestran resultados incorrectos.

El agente debería investigar

• estado frontend;
• caché;
• query parameters;
• estado del componente;
• debounce;
• API;
• repository;
• tests;
• concurrencia.

16. Test de evaluación

17. Recursos externos

18. Checklist de finalización

19. Evaluación práctica

20. Lo que debe quedar aprendido

DESARROLLADOR

define problema
      ↓
proporciona contexto
      ↓
recoge evidencia
      ↓
formula hipótesis
      ↓
      IA
      ↓
analiza
      ↓
propone
      ↓
      DESARROLLADOR
      ↓
valida
      ↓
autoriza cambio
      ↓
      IA
      ↓
implementa
      ↓
tests
      ↓
      DESARROLLADOR
      ↓
acepta solución

"La IA me arregla los errores."

"Utilizo la IA como investigador
para acelerar mi proceso de debugging."

21. Preparación para Week 12

¿Cómo sabemos que el software
que estamos construyendo
es realmente de calidad?