El Banco de Habilidades: depuración sistemática vs. línea base

La Parte 3 de El Banco de Habilidades plantea una pregunta más específica que las dos primeras: no "¿ayuda una habilidad?", sino "¿supera una habilidad diseñada para una tarea a un modelo sin ayuda que realiza esa misma tarea?". La depuración es la prueba más clara que tenemos para esto, porque podemos plantar los errores nosotros mismos, saber con precisión qué está mal y verificar el informe línea por línea contra la verdad fundamental.

Así que escribimos un juego de Snake en canvas, lo rompimos a propósito de tres maneras específicas, y ejecutamos el mismo juego defectuoso y la misma queja a través de dos sesiones idénticas de Claude Sonnet. Una tenía la habilidad systematic-debugging instalada. La otra no. Mismo prompt, mismo modelo, mismo error. Solo la habilidad difiere.

El resultado no fue la victoria clara que esperábamos al principio, y esa es la parte que vale la pena leer.

La trampa que construimos

Partimos de una implementación funcional de Snake, luego plantamos tres errores deliberadamente:

1. Vectores de dirección invertidos. ArrowUp y ArrowDown estaban conectados a los vectores que usarías en coordenadas cartesianas normales, no en coordenadas de canvas, donde la 'y' aumenta hacia abajo. Presiona arriba, la serpiente va hacia abajo.
2. Generación de comida en espacio de píxeles en lugar de espacio de cuadrícula. spawnFood usaba cv.width (400 píxeles) como límite para una coordenada que se suponía que era un índice de cuadrícula en una cuadrícula de 20 celdas (GRID). Multiplicar un paso de cuadrícula por un rango de 400 de ancho da como resultado coordenadas de comida que aterrizan fuera del tablero visible aproximadamente el 95% de las veces.
3. Puntuación incrementando en cada tick. score++ estaba en el bucle principal del juego en lugar de dentro de la rama 'la serpiente comió comida', por lo que la puntuación aumentaba en cada fotograma independientemente de lo que hiciera la serpiente.

No le dijimos a ninguna de las sesiones de Claude qué estaba mal. Dimos a ambos brazos el mismo informe de error al estilo de un jugador, redactado de la manera en que lo haría un probador molesto: "los controles se sienten mal, la comida nunca aparece, la puntuación sube sola". Luego pedimos a cada sesión que encontrara y corrigiera todo lo que causaba eso.

Tres errores, una queja honesta, dos Claudes. Esto es lo que se obtuvo.

Lo que informó cada brazo

Línea base (sin habilidad)

La sesión de línea base trabajó a través del código sin ningún método impuesto, leyendo el manejador de entrada, el generador de comida y el bucle del juego a su vez. Encontró los tres errores plantados:

• Los vectores de dirección estaban invertidos para el eje 'y' en relación con cómo el renderizado de canvas trata 'abajo'.
• spawnFood multiplicaba cv.width donde debería haber usado la constante de la cuadrícula, produciendo coordenadas a escala de píxeles en un juego indexado por celdas.
• El incremento de la puntuación estaba fuera de la verificación de colisión con la comida, por lo que se activaba incondicionalmente en cada fotograma.

Luego siguió leyendo y encontró un cuarto problema que nadie había plantado: la verificación de auto-colisión comparaba la cabeza de la serpiente con la celda de la cola antes de que la cola hubiera sido eliminada para ese fotograma. Cuando la serpiente se mueve al cuadrado que su propia cola está desocupando, la verificación todavía ve ese cuadrado como ocupado y lo considera una colisión. Ese es un caso límite real y bien conocido de Snake. Existía en nuestro código porque escribimos la lógica de colisión antes de plantar cualquier cosa, y la línea base simplemente leyó lo suficiente como para encontrarlo.

Brazo con habilidad (systematic-debugging instalado)

El brazo con habilidad leyó primero obra/superpowers' systematic-debugging SKILL.md (una habilidad que hemos puntuado por separado con 9.6/10 para la identificación de la causa raíz basada en hipótesis), luego aplicó su método: formar una hipótesis para cada síntoma, probarla contra el código, confirmar antes de tocar cualquier cosa.

Encontró los mismos tres errores plantados, con un lenguaje de causa raíz más conciso y preciso:

• Inversión de dirección rastreada a la convención de 'y' hacia abajo del canvas: ArrowUp se mapea a {x:0,y:-1} asumiendo 'y' hacia arriba cartesiana, pero el canvas renderiza 'y' aumentando hacia abajo, por lo que arriba y abajo están invertidos.
• La generación de comida usa un límite de espacio de píxeles (cv.width = 400) donde el cálculo debería usar un límite de espacio de cuadrícula (GRID = 20). Confirmado por la falta de coincidencia de unidades: multiplicar una fracción aleatoria a escala de cuadrícula por un límite a escala de píxeles coloca aproximadamente el 95% de las generaciones fuera de canvas.width.
• La puntuación se incrementa incondicionalmente en el bucle de tick en lugar de estar condicionada a la rama de 'comida comida'. Confirmado al rastrear el cuerpo del bucle: score++ se ejecuta antes de que se ejecute la verificación de colisión, en cada fotograma.

No encontró el cuarto error. El problema de auto-colisión nunca salió a la luz, porque los síntomas reportados (controles incorrectos, comida que falta, puntuación descontrolada) no apuntaban a la lógica de colisión, y el método basado en hipótesis de la habilidad se mantiene anclado a los síntomas que se le dieron. Cerró el informe confiado en que todos los problemas estaban resueltos, y según la letra de la queja, así fue.

El giro de la trama del cuarto error

Este es el giro que verificamos manualmente, releyendo ambos diffs contra el código real: el brazo con habilidad fue más preciso sobre los errores que se le pidió encontrar, y el brazo de línea base encontró un error real más sobre el que nadie preguntó.

Eso no es una crítica a systematic-debugging como habilidad. La depuración basada en hipótesis está diseñada para hacer exactamente lo que hizo aquí: tomar un síntoma reportado, reducirlo a una causa comprobable, confirmar antes de corregir y detenerse una vez que el síntoma se explica. Esa disciplina es precisamente el punto cuando estás frente a un incidente de producción con un stack trace y un reloj corriendo. También es, por construcción, limitada al síntoma. No se desvía hacia código que no está implicado por la queja.

La sesión de línea base no tenía tal alcance. Leyó más del archivo de lo que estrictamente necesitaba, y leer más del archivo es cómo uno se topa con un error que nadie mencionó. La exploración de libre recorrido es ineficiente por diseño, y aquí la ineficiencia se pagó sola.

La lectura honesta: ninguno de los brazos es "mejor" en general. Un brazo es preciso y económico en atención, anclado a lo que se le dijo. El otro es desenfocado y, esta vez, lo suficientemente exhaustivo como para detectar algo que el ticket no mencionaba. Si su informe de error está completo, el informe del brazo con habilidad es el que querrá leer. Si su informe de error podría estar incompleto, querrá el segundo par de ojos que la línea base le dio gratis.

Los números

	Línea base (sin habilidad)	Brazo con habilidad (systematic-debugging)
Bugs encontrados (de 3 plantados)	3 / 3	3 / 3
Error real no plantado encontrado	Sí (colisión por cola desocupada)	No
Precisión de causa raíz	Correcta, menos formalizada	Correcta, mecanismo nombrado por error
Estructura del informe	Ad hoc	Hipótesis → prueba → confirmar, por error
Tokens usados	50,338	58,357
Delta de tokens	—	+16%

La habilidad costó un 16% más de tokens para un informe que se lee mejor y especifica el mecanismo con mayor precisión, pero no superó en hallazgos a una línea base a la que simplemente se le permitió seguir leyendo. Ese es el hallazgo que no esperábamos al entrar, y es la razón por la que publicamos la comparación en bruto en lugar de un veredicto que halague la habilidad.

Cuándo querrá systematic-debugging

El banco de pruebas de Snake subestima el valor real de la habilidad, porque un juego con errores plantados y un archivo fuente completo a la vista es casi el mejor escenario para un modelo sin ayuda: todo lo relevante cabe en una sola lectura. La depuración en producción rara vez se ve así.

Donde la identificación de la causa raíz basada en hipótesis demuestra su valía es en el error que reaparece. En nuestras propias notas de catálogo sobre systematic-debugging, un caso de prueba fue una condición de carrera que Claude ya había "corregido" tres veces distintas en la misma base de código, cada vez aplicando un parche a una suposición plausible en lugar de la causa real. La disciplina de la habilidad (establecer la hipótesis, diseñar una prueba que la refutaría, no tocar el código hasta que la prueba lo confirme) fue lo que finalmente identificó la interacción real en lugar de producir una cuarta suposición. Esa es la forma de error para la que systematic-debugging está diseñado: recurrente, evasivo, ya adivinado tres veces, en una base de código demasiado grande para leer de principio a fin por capricho.

También es la herramienta adecuada en el momento en que está priorizando un incidente de producción. Tiene un síntoma, un reloj y no tiene ganas de que un modelo se desvíe a leer módulos no relacionados. Limite el alcance al informe, confirme la causa, envíe la corrección. Eso es una característica, no una limitación, exactamente en ese escenario.

Cuando una revisión libre gana

Nuestro resultado de Snake también argumenta a favor del caso opuesto: cuando sospecha que el informe de error está incompleto, o cuando está realizando una revisión previa al lanzamiento en lugar de perseguir un síntoma reportado, una lectura sin restricciones del código está haciendo algo que un método basado en hipótesis estructuralmente no hará. Está buscando código del que nadie se ha quejado todavía.

Eso tiene la misma forma que una revisión manual de código versus una respuesta a incidentes dirigida. Ambas tienen su lugar. El error es asumir que una habilidad de depuración reemplaza una revisión en lugar de complementarla. Si desea la perspectiva general de revisión sobre esto, consulte nuestra opinión sobre por qué las habilidades no siempre se activan como espera y cómo estructuramos estas pruebas.

Reprodúzcalo usted mismo

El banco de pruebas es lo suficientemente pequeño como para reconstruirlo en veinte minutos si desea verificar nuestros números en lugar de aceptarlos por fe. Escriba un juego de Snake en canvas (movimiento de cuadrícula, un generador de comida, un contador de puntuación, un bucle de juego) y plante estos tres defectos:

1. Conecte ArrowUp/ArrowDown a vectores de estilo cartesiano (y: 1 para arriba, y: -1 para abajo) en lugar de vectores de estilo canvas, donde el aumento de 'y' mueve la pantalla hacia abajo.
2. En su función de generación de comida, multiplique su fracción aleatoria por el ancho en píxeles del canvas en lugar de su recuento de celdas de cuadrícula, de modo que la coordenada resultante sea un valor de píxel tratado como un índice de cuadrícula.
3. Mueva el incremento de la puntuación fuera de la rama "¿la cabeza acaba de aterrizar en la comida?" y dentro del cuerpo incondicional del bucle del juego.

Dele a una sesión de Claude solo la queja del jugador ("los controles se sienten mal, la comida nunca aparece, la puntuación sube sola"), nunca la lista de errores, y vea qué resultados obtiene. Luego lea su propia lógica de colisión para el caso de "cola desocupada": verifique la próxima posición de la cabeza contra la celda actual de la cola antes de que la cola se mueva, y vea si también está allí. La nuestra lo estaba, sin que nosotros lo plantáramos.

Preguntas Frecuentes

¿La habilidad systematic-debugging hace que Claude sea peor para encontrar errores?

No. Encontró todos los errores plantados con causas raíz más precisas que la línea base. Lo que no hizo fue exceder el alcance de los síntomas reportados, que es lo que permitió a la línea base tropezar con un cuarto error no plantado. La disciplina del alcance es la intención de diseño de la habilidad, no un defecto.

¿Por qué la línea base encontró un error que la habilidad pasó por alto?

La línea base no tenía una hipótesis a la que anclarse, por lo que leyó más de la base de código de lo que los síntomas reportados requerían estrictamente. Leer más código es cómo se encuentran cosas sobre las que nadie preguntó. Es una estrategia ineficiente que casualmente dio sus frutos una vez, no una ventaja general.

¿Vale la pena un aumento del 16% en tokens para una habilidad de depuración?

Depende del error. Para un problema recurrente y difícil de identificar, la disciplina vale mucho más que un 16% en tokens, porque la alternativa es que Claude adivine la misma causa repetidamente, como lo hizo en nuestra propia prueba de catálogo antes de aplicar esta habilidad. Para un error que ya está bien delimitado y es superficial, el costo adicional le proporciona un informe más claro y no mucho más.

¿Debería usar systematic-debugging para cada corrección de errores?

No para todos. Recurra a ella cuando un error es recurrente, cuando un intento de corrección anterior no funcionó, o cuando está priorizando un incidente en vivo y necesita mantenerse dentro del alcance del síntoma reportado. Para una primera revisión de un nuevo informe de error, o cuando desea una exploración más amplia que pueda detectar problemas adyacentes, una sesión de depuración simple o una revisión dedicada pueden cubrir terreno que la habilidad no cubrirá. Consulte nuestras mejores habilidades de codificación para ver cómo clasificamos las habilidades de depuración y revisión entre sí.

---

El Banco de Habilidades, parte 3 de 4. Lea las otras comparaciones controladas: parte 1, la construcción de la página de aterrizaje, parte 2, el bot de Telegram, y parte 4, auditoría de Google zx.