IA para debugging: encuentra el bug sin inventarte otro

Intro: el bug que “ya estaba resuelto” (pero nomás en tu cabeza)

Son las 11:47 pm. La laptop ya suena como microbús en subida y tu jefe te deja un mensaje: “¿sí quedó el cambio para mañana? es solo un detallito”.

Tienes un bug raro: en tu máquina pasa “a veces”, en staging pasa “siempre”, y en production… nadie quiere tocar nada porque mañana hay demo.

Le pides paro a la IA y te contesta con seguridad de taquero a las 2 am: “El problema es X, cambia Y”. Lo cambias. Compila. Pasan dos tests. Te emocionas.

Y al rato: el bug original sigue… y ahora hay uno nuevo. Bienvenido al uso más común (y caro) de IA para debugging.

La neta: la IA sí sirve un buen, pero solo si la pones a jalar con reglas: evidencia, reproducción, hipótesis comprobables y pruebas. Si no, te va a “resolver” cosas inventándose un universo alterno.

Qué vas a sacar de aquí

• Cómo usar IA para encontrar el bug con evidencia, no con cuentos.
• Un workflow completo: repro → observabilidad → hipótesis → fix mínimo → pruebas → guardrails.
• Prompts que fuerzan a la IA a no alucinar y a pedir lo que falta.
• Ejemplos (Node/TS y Python) con logs, stack traces y tests.
• Errores típicos al debuggear con IA (y cómo salirte del hoyo en corto).

Contexto práctico: la IA es copiloto, no oráculo

En debugging, la IA falla casi siempre por una de estas:

1. No tiene datos (sin repro steps, logs, inputs exactos, versiones).
2. Confunde correlación con causa (ve un error y se va por el “fix” más familiar).
3. Optimiza por sonar completa en vez de optimizar por “esto ya quedó verificado”.

La decisión útil: conviértela en una máquina de preguntas y de hipótesis testeables.

Piensa en soporte cuando te dicen “no sirve el internet”. Si no sabes si están en el WiFi del OXXO, si el DNS se cayó o si el router está muerto, es puro tarot. Con la IA pasa igual.

Guía principal: Debugging con IA sin inventar otros bugs

1) Define el bug como si fueras a levantar un ticket serio

Antes de abrir el chat, escribe esto aunque sea en un bloc de notas:

• Esperado vs actual.
• Repro steps (pasos exactos + input de ejemplo).
• Entorno: versiones (Node/Python/JDK), OS, Docker, rama/commit.
• Evidencia: stack trace, logs, request/response, screenshot.

Ejemplo mini (API):

• Esperado: POST /checkout regresa 200 y crea orden.
• Actual: regresa 500 con TypeError: Cannot read properties of undefined (reading 'id').
• Repro:
  1. curl ... con este payload
  2. Si couponCode viene vacío, truena
• Env: Node 20.11, Express 4, TS 5.4, Docker, rama release/1.8.2.

Esto suena básico, pero aquí se muere el 80% de las “alucinaciones”: si no lo escribes tú, la IA lo va a rellenar por ti… y ahí empieza el bug nuevo.

2) Dale a la IA el rol correcto (y ponle barandales)

En vez de “arréglalo”, usa un prompt que la obligue a:

• separar hechos de suposiciones
• pedir info faltante
• proponer experimentos

Prompt recomendado (copia/pega y ajusta):

Actúa como AI pair programmer enfocado en debugging.
Reglas:
1) No inventes APIs, archivos ni comportamientos. Si falta info, pregunta.
2) Primero resume HECHOS (lo que te di) y luego HIPÓTESIS (lo que crees).
3) Propón 3 causas probables ordenadas por evidencia, y para cada una un experimento para confirmarla.
4) No sugieras cambios grandes; busca el fix mínimo verificable.

Bug:
- Esperado: ...
- Actual: ...
- Repro: ...
- Entorno: ...
- Evidencia: ... (pega logs/stack trace)

Código relevante:
(pega SOLO la función o archivo mínimo)

Regla de supervivencia: si el bug está ambiguo y la IA no pregunta nada, desconfía. Debugging bueno empieza con preguntas incómodas.

3) Asegura la reproducción (si no se reproduce, no se arregla)

Tu meta aquí no es “entender todo”. Es tener un repro confiable.

Tips de talacha que sí jalan:

• Si en tu compu “a veces pasa”: corre el endpoint/test en loop.
• Si solo pasa en staging/prod: compara versions y variables de entorno.
• Si te lo reportan por WhatsApp: pide captura + hora + usuario + qué hicieron. Sin eso, estás ciego.

Ejemplo: reproducir un bug intermitente en Node

for i in {1..50}; do curl -s -o /dev/null -w "%{http_code}\n" http://localhost:3000/checkout; done

Si ves mezcla (200/500), ya tienes señal y ya puedes medir progreso.

4) Observabilidad rápida: logs útiles y un request-id

Antes del “fix”, mete visibilidad. No necesitas Grafana enterprise para dejar de adivinar.

Regla: un log sin contexto es chisme.

En Express:

import { randomUUID } from "crypto";

app.use((req, res, next) => {
  const rid = req.header("x-request-id") ?? randomUUID();
  (req as any).rid = rid;
  res.setHeader("x-request-id", rid);
  next();
});

function log(req: any, msg: string, extra: any = {}) {
  console.log(JSON.stringify({ rid: req.rid, msg, ...extra }));
}

Y cerca de donde truena:

log(req, "checkout payload", { body: req.body });

Decisión práctica: si tu “arreglo” depende de adivinar el payload real o el estado real, primero instrumenta. La IA te puede decir dónde poner logs, pero la evidencia la suelta tu app.

5) Pídele a la IA un mapa de hipótesis y experimentos (no un parche)

Dale evidencia y pídele hipótesis testeables. Ejemplo de conversación útil:

• Tú: “Con este payload, req.body.couponCode viene "" y luego truena al leer coupon.id”.
• IA (bien): “Hecho: coupon es undefined cuando couponCode es vacío. Hipótesis: findCoupon regresa undefined y no se valida. Experimento: loggear retorno de findCoupon y agregar test con couponCode vacío.”

Eso es lo que quieres: que te acerque a una causa y a una prueba, no a un patch creativo.

6) Haz el fix mínimo que pase por una prueba

Ejemplo realista: bug por validar mal un opcional.

Código (antes):

async function applyCoupon(userId: string, couponCode?: string) {
  const coupon = await findCoupon(couponCode);
  // truena si couponCode viene "" o undefined
  return { discount: coupon.percent, couponId: coupon.id };
}

Fix mínimo (después):

async function applyCoupon(userId: string, couponCode?: string) {
  if (!couponCode) return { discount: 0, couponId: null };

  const coupon = await findCoupon(couponCode);
  if (!coupon) return { discount: 0, couponId: null };

  return { discount: coupon.percent, couponId: coupon.id };
}

Amárralo con test (Jest):

test("applyCoupon returns no discount when code is empty", async () => {
  const res = await applyCoupon("u1", "");
  expect(res).toEqual({ discount: 0, couponId: null });
});

Advertencia amistosa: si la IA te propone refactor masivo (“vamos a cambiar todo a Result/Either”), dile que no. Para debugging, primero salva production; ya con calma te pones elegante.

7) Usa la IA para revisar el impacto (blast radius) antes del merge

Ya que tienes fix + test, ahora sí úsala para pensar en bordes.

Prompt de impacto:

Con este cambio, ayúdame a identificar:
1) edge cases que ahora podrían fallar
2) endpoints/flows afectados
3) qué métricas/logs debo vigilar en deploy

Aquí está el diff:
(pega diff)
Y estos son los contratos esperados:
- ...

Edge cases típicos que suelen salir:

• couponCode con espacios (" SUMMER ")
• case-insensitive
• cupón expirado
• cupón válido pero usuario no elegible

No es para meter features. Es para no romper lo que sí funcionaba.

8) Guardrails anti-alucinación: “si no hay evidencia, no hay cambio”

Esto se siente rudo, pero te ahorra rollback a deshoras:

• La IA te dijo “cambia la query”: pídele el plan (EXPLAIN) o el log SQL real.
• Te dijo “es race condition”: pídele una reproducción con concurrencia o un trace.
• Te dijo “es CORS”: pídele el error exacto del navegador y headers.

Ejemplo en Python (stack trace real > “se me hace que…”):

try:
    do_thing()
except Exception as e:
    logger.exception("failed doing thing", extra={"user_id": user_id})
    raise

Con stack trace en mano, la IA puede razonar. Sin eso, rellena huecos con fanfic.

Screenshots sugeridos

• Captura del error con stack trace completo (terminal o navegador) y un request-id visible.
• Screenshot del diff en GitHub/GitLab mostrando el fix mínimo + el test agregado.
• Captura de logs en JSON (con rid) comparando request bueno vs request malo.
• Si aplica: pantalla de variables de entorno en staging (sin secretos) para comparar versiones.

Errores comunes (y cómo salir rápido)

Error 1: “Le pegué todo el repo y que la IA le haga”

Síntoma: te regresa cambios en 8 archivos que ni existen o que no tocan el bug.

Salida: reduce a lo mínimo:

• 1 stack trace
• 1 función
• 1 test
• 1 payload de repro

Error 2: Aceptar el primer fix porque “suena razonable”

Síntoma: compila, pero el bug sigue o aparece otro.

Salida: exige experimento y prueba. Si no puedes escribir un test o un paso de repro, todavía no sabes qué arreglaste.

Error 3: Debugging sin datos de producción

Síntoma: “en local no pasa” y te vas horas.

Salida: request-id y logs puntuales. En un chorro de equipos staging está medio abandonado y production es “sagrado”. Con dos logs bien puestos dejas de adivinar.

Error 4: Confundir workaround con fix

Síntoma: “pon un try/catch y ya”.

Salida: si el catch solo oculta el error, mínimo:

• registra el evento
• cuenta métricas
• devuelve una respuesta consistente
• deja ticket para el fix real

Error 5: No validar el “no inventar otros”

Síntoma: arreglaste A, rompiste B (y nadie se enteró hasta el lunes).

Salida: corre:

• tests
• linter
• smoke test del flujo
• deploy con monitoreo básico

Checklist final (para debuggear con IA sin regarla)

• Tengo repro steps claros (o un loop que lo haga fallar).
• Tengo evidencia pegable: stack trace/logs/payload.
• Mi prompt obliga a separar hechos vs hipótesis.
• La IA propuso experimentos, no solo parches.
• Hice el fix mínimo (no refactor por deporte).
• Agregué o ajusté al menos 1 test que falla antes y pasa después.
• Revisé blast radius (edge cases) y monitoreo post-deploy.
• Si algo sigue raro: instrumenté primero, opiné después.

FAQ

1) ¿Qué le tengo que pegar a la IA para que sí sirva en debugging?

Lo mínimo verificable: repro steps, input exacto, stack trace/logs, versión de entorno y el pedazo de código donde truena. Si pegas “todo el repo”, se pierde y rellena huecos.

2) ¿Cómo detecto cuando la IA está alucinando?

Cuando afirma cosas que no le diste (archivos, APIs, configs) o cuando no pide datos ante ambigüedad. Pídele que marque “HECHOS” y “SUPOSICIONES” y que proponga experimentos.

3) ¿Sirve para bugs intermitentes (race conditions, timeouts)?

Sí, pero primero necesitas reproducir o al menos capturar evidencia (timings, traces, logs con request-id, conteo de reintentos). La IA ayuda a diseñar el experimento, no a reemplazarlo.

4) ¿Qué hago si el fix sugerido por IA es un refactor enorme?

No lo merges. Pide un fix mínimo y un test que lo demuestre. El refactor puede venir después como deuda técnica planeada, no como “arreglo de emergencia”.

5) ¿Cómo evito “arreglar” el bug y romper production?

Agrega test, haz smoke test del flujo, monitorea logs/métricas y ten rollback listo. Si tu cambio no tiene prueba y no tiene observabilidad, estás apostando.

Siguiente episodio

Toca hablar de prompts y hábitos para usar IA como reviewer: que te cache bugs de lógica, seguridad y edge cases sin ponerse creativa.

Spoiler: el truco no es pedir “revísame el PR”, es enseñarle qué significa “riesgo” en tu negocio.