La cifra que el marketing no cuenta
Hay una medición que soltó a los mismos modelos sobre bugs sintéticos y sobre bugs reales. La diferencia no es un matiz, es un orden de magnitud.
| Modelo | Bug sintético | Repo real, solo el código | Repo real, con el informe |
|---|---|---|---|
| A | 45,97 % | 2,95 % | 12,96 % |
| B | 37,71 % | 3,16 % | 9,58 % |
| C | 52,90 % | 4,59 % | 17,81 % |
| D | 46,15 % | 1,29 % | 9,61 % |
(Proporción de líneas defectuosas localizadas al primer intento.)
Entre uno y cinco por ciento. Eso vale el modelo si le pasas el código y le preguntas dónde está el fallo.
Y el texto del informe del error, por sí solo, multiplica esa cifra por un factor de entre tres y siete — entre seis y trece puntos porcentuales. El modelo no se ha vuelto más listo: le has dado un asidero.
El orden que vale treinta y siete puntos
Es el resultado menos conocido y más práctico de todo el tema.
Un artículo de congreso de 2026 tomó el mismo bug, el mismo modelo y el mismo código — y cambió solo el orden en que se pegaban las cosas:
| Conjunto de tareas | Código sospechoso delante | Código sospechoso al final |
|---|---|---|
| Uno | 57 % | 20 % |
| El otro | 38 % | ~3 % |
Mismo bug, mismo código. La tasa de acierto cae a la tercera parte.
Quien vuelca el archivo entero está comprando un billete de lotería. Pon la parte sospechosa al principio del prompt.
Lo que mejora — y lo que empeora
Este es el resumen que sale de las mediciones:
| Intervención | Efecto medido |
|---|---|
| El texto del informe o de la descripción del error | +6…+13 puntos |
| Señalar el archivo o la línea | entre los casos resueltos y los no resueltos este indicador marca una diferencia de 27,8 veces |
| Evidencia de ejecución — el valor de las variables al fallar | +51 % en el número de parches correctos |
| El código sospechoso al principio del prompt | hasta +37 puntos |
| Stack trace largo y en bruto | puede empeorar |
La última fila sorprende, así que conviene decirlo con precisión: una investigación la identifica explícitamente como modo de fallo, porque demasiados elementos sospechosos llegados del stack trace dispersan al modelo. Lo que funciona no es dar el stack trace, sino dar el stack trace recortado.
O sea que aquí no vale el «cuanto más contexto, mejor». Lo relevante ayuda; lo que solo es mucho, estorba.
Y la intervención más rentable es justo la que casi nadie hace: aportar evidencia de ejecución. No el código, sino el valor que tenían las variables en el instante del fallo. Una mejora por encima del cincuenta por ciento — al precio de un print.
No le digas lo que piensas
Es la regla más difícil de cumplir del método, porque es exactamente lo contrario de lo que haces por instinto.
Una medición de muestra grande — 14.042 preguntas en cinco condiciones, unos 70.000 pares de pregunta y respuesta — analizó qué pasa cuando el usuario menciona una respuesta. El resultado:
- Mencionar una respuesta equivocada: hasta 15 puntos porcentuales de precisión perdidos.
- Mencionar la respuesta correcta: hasta 14,7 puntos ganados.
- A sugerencia del usuario, el modelo cambia su respuesta en el 6,2–18,8 % de los casos.
(Límite importante: esto se hizo con preguntas de opción múltiple, no depurando.)
La medición más cercana a la depuración es más pequeña pero más elocuente: veinticuatro participantes, una tarea real de depuración, dos tipos de chatbot — uno muy complaciente y otro contenido. Con la versión complaciente, los participantes corrigieron menos sus propias ideas equivocadas, y pasaron más tiempo apoyándose en respuestas inútiles.
Y el detalle que más importa: la mayoría de los usuarios no se dio cuenta de que les estaban confirmando el error.
De ahí sale la primera regla del método: el modelo no te dice dónde está el fallo — lo que hace es continuar tu pregunta. Así que no escribas dónde crees tú que está el problema. Escribe qué hiciste, qué esperabas y qué pasó — y guárdate la hipótesis hasta que el modelo proponga una.
Hasta qué punto esto es una experiencia común: en una encuesta a desarrolladores con 33.000 respuestas, la mayor frustración — un 66 % — fue «una solución de IA que casi está bien, pero no del todo». Y para el 45,2 %, depurar código generado come más tiempo, no menos.
Plausible ≠ correcto
Aquí llega la cifra más dura, y cae justo al final del proceso.
En reparación automática de programas se midió cuántos de los parches que pasan los tests son realmente correctos:
| Familia de herramientas | Correctos : sobreajustados | Proporción correcta |
|---|---|---|
| Herramientas clásicas de reparación | 129 : 690 | ~16 % |
| Basadas en modelos de lenguaje | 63 : 107 | ~37 % |
O sea que entre el 63 y el 84 % de los parches que dejan los tests en verde son en realidad incorrectos — simplemente se amoldan al conjunto de tests que ya existe.
Y algo todavía peor: las herramientas que deberían detectar el sobreajuste tampoco funcionan. El mismo estudio concluye que «la simple elección aleatoria supera a todas las herramientas de detección punteras en el 71–96 % de los casos».
No hay máquina que decida por ti si el parche es bueno. Lo tienes que leer tú. De esas mediciones se ocupa el post los tests como red de seguridad , con las cifras.
El método
1. REPRODUCE PRIMERO, SIN IA.
Si tú no lo provocas, el modelo tampoco. El 1-5 % de
aciertos mide justo lo que pasa sin este paso.
2. ESCRIBE EL INFORME DEL ERROR, NO TU SOSPECHA. (+6-13 puntos)
Qué hiciste -> qué esperabas -> qué pasó.
3. ACOTA A UN ARCHIVO O A UNA LÍNEA, si puedes.
Es el indicador que más separa los casos resueltos de
los que se quedaron sin resolver.
4. APORTA EVIDENCIA DE EJECUCIÓN.
El valor de las variables al fallar. (+51 %)
Un print vale más que cien líneas de código.
5. EL CÓDIGO SOSPECHOSO, AL PRINCIPIO. (hasta +37 puntos)
6. RECORTA EL STACK TRACE.
Un trace largo y en bruto dispersa al modelo.
7. GUÁRDATE TU HIPÓTESIS hasta que el modelo proponga una.
Una sospecha equivocada cuesta hasta 15 puntos - y no
te vas a dar cuenta.
8. NO ACEPTES "LOS TESTS ESTÁN EN VERDE".
El 63-84 % de los parches plausibles es incorrecto.
Malentendidos típicos
- «Le paso el código y me dice dónde está el fallo.» En un repo real eso es una tasa de acierto del 1–5 %. Sin el texto del informe del error no vale casi nada.
- «Cuanto más contexto le dé, mejor.» Un stack trace largo y en bruto empeora el resultado de forma medible. La parte relevante ayuda; el volumen, no.
- «Escribo lo que pienso para que no tire por el camino equivocado.» Justo al revés: mencionar una hipótesis falsa cuesta hasta quince puntos — y la mayoría de los usuarios no nota que le han dado la razón en el error.
- «Da igual en qué orden lo pegue.» Mismo bug, mismo código, otro orden: 57 % o 20 %.
- «Los tests están en verde, el parche está listo.» La mayoría de los parches que pasan los tests están sobreajustados. Y entre las herramientas de detección, la elección aleatoria lo hace mejor.
Lo que conviene llevarse
Al modelo no le dieron un depurador, le dieron completado de texto. Por eso, al depurar, la pregunta no es qué modelo usas sino qué le entregas: una reproducción, una descripción del fallo, una localización, valores de ejecución — y todo eso en el orden correcto. Tu propia sospecha, fuera. Y al final vale la misma regla que en todo lo demás: un test en verde no es una prueba.
De cómo revisar el parche generado habla el post revisar el código escrito por IA , paso a paso; y de cómo plantear bien la tarea trata el post tu primera tarea con un coding agent , desde el principio.