Los tests son donde Claude Code se gana el sueldo. La depuración es donde se vuelve raramente impresionante.

Pero también es donde un workflow descuidado se descarrila rápido. Deja que un agente "arregle" un test mal y enviarás CI verde con feature rota. Deja que "depure" un test flaky y puede que simplemente lo borre.

Aquí van los patrones que funcionan — y la regla que los mantiene honestos.

La regla única

Operacionalízalo con dos sub-agentes que no pueden ser el mismo agente:

• test-writer — solo añade o modifica tests.
• test-fixer — solo modifica código de producción para hacer pasar tests.

Si test-fixer quiere alguna vez tocar un test, debe escalar a un humano. Ese es el contrato.

Patrón 1 — Delegación test-first

Para features nuevas, este es el workflow más limpio:

> /agents test-writer
> Objetivo: Escribe casos vitest para lib/cache.ts cubriendo:
>   - Desalojo LRU con maxSize=3
>   - Expiración TTL bajo fake timers
>   - get(missing) devuelve undefined
> Restricciones: vitest, fake timers vía vi.useFakeTimers().
> DoD: Tests escritos, todos actualmente ROJOS.

La salida son tests fallidos. Eso es correcto.

> /agents test-fixer
> Haz pasar los nuevos tests sin modificar tests/cache.test.ts.

test-fixer implementa LRU + TTL en lib/cache.ts. Tests verdes. Diff pequeño, enfocado, revisable.

Es mucho más limpio que "escribe el cache y los tests de una vez" porque el autor de los tests es ciego a la implementación. Pilla los errores de API temprano.

Patrón 2 — El susurrador de stack-traces

Cuando algo explota en logs de prod, pega la stack trace. Claude Code es irracionalmente bueno aquí.

> Lee esta stack trace y dime cuál de las tres causas más probables es la correcta,
  con evidencia archivo:línea:

[pega stack]

Después propón un fix de 5 líneas que aborde SOLO esa causa.

Dos notas:

• "Tres causas más probables" lo obliga a enumerar, no a sobre-comprometerse.
• "Fix de 5 líneas" acota el blast radius.

Encuentro que ~70 % de las sesiones de depuración "¿qué pasa aquí?" terminan tras esa única ronda.

Patrón 3 — Triaje de tests flaky

Los tests flaky son la perdición de CI. El agente es excelente clasificándolos:

> Corre la suite 10 veces. Lista todo test que:
>   - Falló al menos una vez y pasó al menos una vez.
>   - Saca el error exacto del run que falló.
> NO modifiques código.

Recibes una tabla de triaje. Desde ahí, preguntas:

> Para el test X (flaky), clasifica la causa probable:
>   - Race condition
>   - Dependiente del tiempo (reloj real vs fake)
>   - Red / dependencia externa
>   - Fuga de recursos de un test previo
> Cita evidencia archivo:línea.

La clasificación del agente rara vez es 100 % correcta pero casi siempre es "barrio correcto". Suficiente para apuntar la investigación en la dirección correcta.

Patrón 4 — Bisectar una regresión

Tienes git bisect y el agente tiene git log. Combínalos:

> El endpoint /api/x devolvía 200 la semana pasada y ahora 500.
> Encuentra el commit culpable así:
>   1. git log --oneline desde el último deploy bueno.
>   2. Para cada commit que toque /api/x o sus imports, resume el cambio en una línea.
>   3. Identifica al culpable más probable y explica por qué.
>   4. NO ejecutes código.

Más rápido que un git bisect binario porque el agente lee diffs sobre la marcha. Mejor para bases de código pequeñas en que el conjunto candidato sea < 50 commits.

Patrón 5 — Cobertura como bucle de coaching

Infravalorado:

> Corre pnpm test --coverage en lib/auth/.
> Reporta líneas no cubiertas.
> Para cada rama no cubierta, propón una descripción de una línea de un test
> que la cubriría. NO escribas los tests.

Recibes una punch list. Después test-writer los va cerrando uno a uno.

Por qué es mejor que "consigue 90 % de cobertura automáticamente": tú ves la lista y puedes despriorizar las ramas tontas (rutas de error inalcanzables, defaults de switch exhaustivo).

Cosas que nunca delegar en testing

• Decidir qué testear. Eso es conocimiento de producto.
• Decidir cuándo "suficiente" es suficiente. Los umbrales de cobertura son una decisión de valores.
• Marcar un test como "skip" o "todo". Siempre humano. Siempre.

El agente sugiere; el humano decide qué cuenta como listo.

Anti-patrones de depuración que veo cada semana

• "Solo haz que pase el test." Catastrófico. Siempre. El reviewer lo pillará; no se lo deberías pedir al agente.
• "Añade // @ts-ignore para callar el build." El sub-agente debería rehusar. Configúralo así en .claude/agents/test-fixer.md:

# reglas
- Nunca añadir @ts-ignore, @ts-expect-error ni eslint-disable.
- Si no puedes arreglar un error de tipo, escala.

• "Actualiza el snapshot." A veces es legítimo, pero el agente debe siempre mostrar el diff y explicar por qué cambió el snapshot antes de actualizarlo.

El resultado tras un trimestre

En la base de código donde he estado corriendo esto ~3 meses:

• Tiempo medio para triar un CI flaky: ~12 min → ~3 min.
• Tiempo medio para depurar una stack trace de prod: ~20 min → ~5 min.
• Delta de cobertura de tests en features nuevas: ruidoso, pero +8 puntos porcentuales de media.

Ninguno de esos números es magia del agente. Son el resultado de estandarizar el workflow de tests con restricciones que no podrías estandarizar fácilmente con humanos.

---

Próximo artículo: Workflows de equipo — cómo los equipos de ingeniería integran Claude Code hoy, del antipatrón "una licencia única" al patrón compartido .claude/ en git que escala.