El Banco de Habilidades, parte 2: Habilidad TDD de Claude vs sin habilidad

La Parte 1 de esta serie enfrentó una habilidad contra un prompt en blanco en una tarea de andamiaje y obtuvo una victoria desigual. La Parte 2 no. Construimos el mismo bot de Telegram dos veces con Claude Sonnet, dimos a una ejecución la habilidad de desarrollo guiado por pruebas (test-driven-development) con la puntuación más alta de nuestro catálogo, y la habilidad añadió tokens sin añadir una prueba relevante. Publicamos ese resultado tal cual, porque un benchmark que solo se publica cuando la habilidad gana no es un benchmark.

Configuración y metodología

Esto es N=1. Una tarea, un modelo, una habilidad, ejecutada una vez por cada brazo. No son datos suficientes para afirmar una diferencia porcentual en la calidad, y no vamos a pretender lo contrario. Para lo que sí es suficiente es para mostrar lo que realmente sucede en una sola sesión, línea por línea, algo que la mayoría del marketing de habilidades nunca muestra.

La tarea: construir un bot de Telegram de tareas pendientes en aiogram v3 con cuatro comandos, /add, /list, /done, /delete, respaldado por almacenamiento en memoria con ámbito por usuario. El encargo pedía una división limpia: storage.py conteniendo lógica pura sin importaciones de Telegram, bot.py conectando esa lógica a los manejadores de aiogram, y test_storage.py cubriendo la capa de almacenamiento. Ejecutar pytest hasta que esté en verde, luego detenerse.

Ambos brazos recibieron el mismo prompt, el mismo modelo (Claude Sonnet) y el mismo andamiaje de repositorio para empezar. La única variable: el brazo de la habilidad tenía instalada la habilidad test-driven-development SKILL.md de obra/superpowers, la misma habilidad que obtuvo 9.6 de 10 en nuestro catálogo por imponer un estricto ciclo de red-green-refactor y negarse a permitir que una sesión marcara el trabajo como terminado mientras una prueba fallaba. El brazo de referencia no tenía nada instalado más allá del comportamiento predeterminado de Claude Code. El método completo de cómo programamos y registramos estas ejecuciones se encuentra en cómo probamos las habilidades de Claude, y la rúbrica de puntuación más amplia está en nuestra página de metodología.

Lo que ambos brazos entregaron

Ambos brazos terminaron. Ambos lograron una ejecución de pytest completamente en verde. Ambos produjeron la división de tres archivos que pedía el encargo, con la lógica de almacenamiento aislada del código del manejador de aiogram. En la superficie, esto parece un empate, y si dejara de leer en "ambos quedaron en verde", concluiría que la habilidad no hizo ninguna diferencia y seguiría adelante.

Ninguno de los archivos bot.py hizo nada sorprendente. Cada uno conectó los cuatro comandos a los manejadores Router y Message de aiogram, analizó el texto o el índice de la tarea pendiente de los argumentos del comando, y llamó directamente a la capa de almacenamiento para el trabajo real. Eso es exactamente lo que pedía el encargo: mantener el archivo del bot delgado, mantener la lógica comprobable. En el cableado de aiogram, las dos sesiones convergieron casi por completo, lo cual es en sí mismo un punto de datos útil. Donde divergieron fue enteramente en el lado del almacenamiento, en lo que cada uno consideró digno de una prueba.

La diferencia se manifiesta en lo que cada brazo decidió que valía la pena probar, y en lo que costó llegar a ello.

Los números

	Línea base (sin habilidad)	Habilidad (test-driven-development)	Delta
Tokens totales	48,536	52,480	+8%
Pruebas escritas	23	13	-10
Pruebas de rutas de excepción	9	5	-4
Estado final de pytest	Verde	Verde	Empate

El brazo de la habilidad utilizó más tokens para producir un conjunto de pruebas más pequeño con menor cobertura de excepciones. Ese es el resultado completo. Sin asteriscos ocultos, sin "pero si miras la calidad del código en lugar del recuento de pruebas". La sesión de línea base, ejecutándose sin ningún andamiaje de proceso, escribió casi el doble de casos de rutas de excepción.

Leyendo los conjuntos de pruebas: 23 vs 13

El recuento de pruebas por sí solo es una señal débil, así que leímos ambos conjuntos línea por línea en lugar de confiar en el número del encabezado.

Las 23 pruebas de la línea base cubrieron los cuatro comandos a nivel de "happy-path", y luego continuaron con casos límite que nadie pidió explícitamente: qué sucede cuando se marca un índice fuera de rango como hecho, qué hace un índice cero o negativo, si la lista de tareas de un usuario se filtra a la de otro, y si al eliminar el elemento 2 se desplazan correctamente los índices de los elementos 3 y 4 para que /done 3 siga apuntando a la tarea correcta después. Este último es el tipo de error que sobrevive a una demostración y luego falla frente a un usuario real la primera vez que elimina algo del medio de una lista. Nueve de las 23 pruebas existían puramente para explorar estas rutas de excepción.

Las 13 pruebas del brazo de la habilidad cubrieron los mismos cuatro comandos a nivel de "happy-path", además de cinco casos de rutas de excepción: principalmente índices fuera de rango y un escenario de adición duplicada. Lo que falta en relación con la línea base: ninguna prueba explícita de aislamiento por usuario, y ninguna prueba que confirme el comportamiento del índice después de que una eliminación desplace la lista. La lógica de almacenamiento en el storage.py del brazo de la habilidad bien podría manejar estos casos correctamente. Sin embargo, el comportamiento correcto no probado y el comportamiento correcto probado no son la misma afirmación, y el objetivo de un conjunto de pruebas es cerrar esa brecha.

Ningún conjunto es malo. Trece pruebas con cinco casos de excepción en un bot de cuatro comandos es un punto de partida defendible según cualquier estándar de ingeniería normal. La comparación solo parece condenatoria junto a una línea base que, trabajando desde un prompt idéntico sin ningún andamiaje red-green, escribió más pruebas, no menos.

Por qué esto no refuta el TDD

Aquí está lo que un benchmark de una sola ejecución no puede ver estructuralmente: el argumento del TDD nunca fue "escribirás más pruebas en tu primer intento". Se trata de lo que sucede a lo largo de semanas de iteración, a través de la décima característica añadida a una base de código que el modelo no escribió desde cero, en el punto donde un ingeniero cansado (o un agente bajo presión de tiempo) se siente tentado a entregar con una prueba en rojo y arreglarla "más tarde".

Esa es una afirmación de disciplina, no una afirmación de resultado de una sola ejecución, y este benchmark se ejecutó exactamente una vez. No podemos medir la disciplina en una sola sesión porque la disciplina es lo que te impide tomar atajos en la sesión seis, y aquí no hay sesión seis.

Sí tenemos un rastro de cómo se ve esa disciplina en la práctica, de nuestras propias notas de prueba en la página de la habilidad test-driven-development: a lo largo de una sesión de tres características, la habilidad se negó a saltarse el ciclo red-green incluso cuando la solución parecía obvia y la tentación de pasar directamente a verde estaba ahí. Escribió la prueba fallida primero, la vio fallar por la razón correcta, luego escribió el código mínimo para pasarla, cada vez, a lo largo de las tres características. Nadie tuvo que intervenir y decir "espera, escribe la prueba primero". Ese es el comportamiento que se supone que una habilidad de disciplina debe proporcionar, y no es el mismo comportamiento que "escribe más pruebas en un intento en un módulo pequeño y bien delimitado".

En una tarea de este tamaño y tan bien especificada, el juicio de línea base de Claude Sonnet sobre qué probar ya era sólido. La habilidad añadió un proceso explícito sobre un juicio que aún no necesitaba mucha corrección, y ese proceso costó un 8% más de tokens sin una ganancia de calidad equivalente en este intento particular. Ambas cosas pueden ser ciertas: vale la pena tener TDD instalado, y no ayudó aquí.

También hay una explicación más sencilla que vale la pena mencionar: escribir una prueba fallida, verla fallar y luego escribir el código mínimo para pasarla requiere más idas y venidas que escribir la implementación y una prueba para ella en una sola pasada. Esa sobrecarga es el objetivo de la disciplina cuando la implementación no es trivial o el modelo es propenso a adelantarse. En un bot de tareas pendientes de cuatro comandos, la implementación nunca estuvo en duda, por lo que la sobrecarga compró proceso sin comprar una verificación sobre algo que realmente estuviera en riesgo de salir mal.

Qué significa esto si estás adquiriendo habilidades

La parte incómoda para nosotros, específicamente, es que vendemos habilidades probadas, y nuestro propio banco acaba de mostrar que una habilidad con la máxima puntuación no ganó una comparación de una sola ejecución contra ninguna habilidad en absoluto. Preferimos que veas eso antes que un "highlight reel".

La conclusión práctica es hacer coincidir la habilidad con el trabajo, no con la puntuación. Una puntuación de catálogo de 9.6/10 significa que la habilidad hace lo que dice de manera fiable y no rompe tu configuración, no que gane todos los benchmarks en cada tamaño de tarea. Si tu trabajo es un módulo pequeño y bien especificado que estás construyendo desde cero, en una sola sesión, el juicio predeterminado de un modelo fuerte ya puede cubrir las rutas de excepción que te importan, y una habilidad de proceso es una sobrecarga que estás pagando sin una ventaja equivalente en esa sesión. Si tu trabajo es una base de código que tocarás durante meses, con múltiples colaboradores y largos períodos entre sesiones donde los atajos se acumulan silenciosamente, eso es lo que una habilidad de disciplina como TDD está diseñada para prevenir, y un benchmark de una sola sesión nunca iba a capturar ese valor en primer lugar.

Las habilidades de velocidad y las habilidades de disciplina responden a preguntas diferentes. Lee la descripción de una habilidad para saber qué pregunta responde antes de instalarla para el trabajo equivocado. Cubrimos cómo interpretar esa señal en nuestro resumen de las mejores habilidades de codificación.

Reprodúcelo tú mismo

La tarea es lo suficientemente pequeña como para volver a ejecutarla en una tarde. Clona un proyecto aiogram v3 vacío, luego ejecuta el prompt idéntico dos veces: una en una sesión limpia de Claude Code, otra con la habilidad test-driven-development de obra/superpowers instalada. Pide /add /list /done /delete con almacenamiento en memoria por usuario, una división storage.py/bot.py, y un conjunto de pytest que se ejecute en verde antes de darlo por terminado. Registra los tokens totales del resumen de uso de cada sesión, luego compara manualmente los dos archivos test_storage.py: cuenta las aserciones y marca específicamente cualquier cosa que toque índices negativos, claves faltantes, aislamiento por usuario y cambios de índice después de una eliminación. Esas cuatro categorías son donde vimos la brecha, y son las que vale la pena verificar en cualquier aplicación CRUD tipo "todo" independientemente de la habilidad que estés probando.

Preguntas frecuentes

¿Significa esto que la habilidad TDD es mala?

No. Significa que un benchmark de una sola ejecución en un módulo pequeño y bien especificado no es la prueba que muestra para qué sirve el TDD. El valor de la habilidad radica en prevenir atajos a lo largo de una sesión o un proyecto extenso, lo cual este benchmark, por diseño, no se ejecutó el tiempo suficiente para medir.

¿Por qué el brazo de la habilidad escribió menos pruebas si impone un proceso más estricto?

El ciclo red-green-refactor te impulsa a escribir una prueba para el comportamiento que estás a punto de implementar, luego implementarlo, y luego pasar al siguiente comportamiento. No te incita automáticamente a volver y añadir pruebas para casos límite que nadie pidió explícitamente, a menos que la sesión se tome el tiempo para idearlos por separado. El brazo de la línea base, sin las restricciones de un ciclo fijo, aparentemente dedicó más de su producción precisamente a esa lluvia de ideas.

¿Debería instalar una habilidad TDD para Claude Code?

Si estás trabajando en una base de código a la que volverás repetidamente, especialmente con otros colaboradores o con largos intervalos entre sesiones, sí. Es un seguro contra un modo de fallo específico: entregar silenciosamente con una prueba en rojo porque la solución parecía obvia. Ese modo de fallo no aparece en un benchmark de una sola tarde, pero sí aparece en proyectos reales.

¿Qué sigue en esta serie?

La Parte 3 de "The Skill Bench" examina una habilidad de depuración contra una búsqueda de errores en un juego de serpientes sin modificar. La Parte 4 audita un script de automatización de Google zx. Ambas siguen la misma regla que esta: misma tarea, mismo modelo, una variable, números impresos de cualquier manera.

La serie The Skill Bench

Parte 2 de 4. Lee parte 1: construcción de página de aterrizaje, parte 3: depuración de snake, y parte 4: auditoría de un script de Google zx.