Los agentes de IA cometen errores, y revisarse a sí mismos tiene límites que vienen de su entrenamiento y sus sesgos. GitHub Copilot CLI introduce Rubber Duck: un segundo modelo de una familia de IA diferente que actúa como revisor independiente en los momentos clave del proceso de desarrollo. Vemos cómo funciona, y qué dicen los benchmarks reales.
Los agentes de IA para programar son cada vez más capaces. Pero siguen teniendo un problema bastante importante: cuando se equivocan al principio, los errores se acumulan. Un mal diseño en el plan inicial puede convertirse en una deuda de diez archivos modificados y dos horas de trabajo tirado a la basura. GitHub tiene una respuesta a esto, y la han llamado Rubber Duck.
La idea es simple pero muy potente: en lugar de que el mismo modelo que genera el código lo revise también, Copilot CLI llama a un modelo de una familia diferente para hacer de revisor independiente (o antagonista). Claude planifica y ejecuta, GPT-5.4 critica. Dos puntos de vista entrenados de forma distinta, trabajando en equipo. Según los propios números de GitHub, esta combinación cierra el 74,7% de la brecha de rendimiento entre Claude Sonnet y Claude Opus en tareas complejas de código real.
Qué es Rubber Duck y qué dicen los benchmarks
El nombre viene de la técnica clásica del rubber duck debugging: explícale tu código a un patito de goma y, al verbalizarlo, encuentras el error tú solo. La versión de GitHub es más sofisticada, claro. Aquí el "patito" es GPT-5.4, que actúa como agente de revisión cuando tu orquestador principal es cualquier modelo de la familia Claude (Opus, Sonnet o Haiku).
¿Por qué mezclar familias de modelos? Porque un modelo que revisa su propio trabajo sigue estando limitado por su propio sesgo de entrenamiento. Las mismas técnicas, los mismos datos, los mismos puntos ciegos. La auto-revisión funciona hasta cierto punto, pero no rompe esa limitación. Traer un modelo entrenado de forma diferente sí que lo logra: GPT-5.4 y Claude no tienen mucho que ver en cuanto a entrenamiento y refuerzo, así que sus errores sistemáticos no se solapan de la misma manera. En realidad esto pasa con la mayoría de los modelos, pero Microsoft ha elegido dos de los laboratorios más potentes para ponerlo en práctica.
Para medir esto, GitHub evaluó la combinación de los dos modelos en SWE-Bench Pro, un benchmark que trabaja con problemas reales de programación extraídos de repositorios Open Source. Está especialmente diseñado para ser resistente a la contaminación de datos. O sea, no es el típico benchmark de ejercicios de algoritmia para el que hacen "benchmaxxing", sino que son tareas de ingeniería del software del mundo real: bugs que requieren entender contexto amplio, modificar varios archivos y no romper nada por el camino.
SWE-Bench Pro fue creado precisamente para corregir las limitaciones del SWE-bench original, que tenía problemas de contaminación: algunos modelos habían "visto" las soluciones durante el entrenamiento. El Pro usa un conjunto privado de tareas para evitar esto.
El caso es que Claude Sonnet 4.6 + Rubber Duck (GPT-5.4) se acercan al rendimiento de Claude Opus 4.6 en solitario, cerrando el 74,7% de la brecha entre ambos. La diferencia es aún menor en los problemas más difíciles, los que implican tres o más archivos y suelen requerir más de 70 pasos de ejecución. Ahí, Sonnet + Rubber Duck saca un 3,8% más que Sonnet solo. En los problemas más duros identificados en tres ensayos separados, la mejora llega al 4,8%.
No parece mucho en porcentaje, pero en un benchmark de este tipo (con tareas de ingeniería reales) cada punto porcentual representa bugs que en producción te habrían costado horas. Por no mencionar el ahorro de costes y tiempo que tiene usar este tándem de modelos frente al modelo mucho más caro y lento, claro.
Cuándo activa Copilot el Rubber Duck (y cuándo puedes pedirlo tú)
Rubber Duck no se ejecuta en cada paso. Sería lento y contraproducente. GitHub ha tomado la decisión de diseño de invocarlo con moderación. Copilot puede llamar a Rubber Duck de forma automática en tres momentos concretos:
- Después de redactar el plan: antes de escribir una sola línea de código. Si el diseño inicial tiene un fallo de arquitectura, es el mejor momento para detectarlo. Arreglarlo aquí cuesta casi nada. Arreglarlo después de la implementación puede costar mucho.
- Después de una implementación compleja: cuando el código ya está escrito pero antes de seguir. Un segundo par de ojos sobre lógica compleja puede encontrar edge cases que el primer modelo pasó por alto.
- Después de escribir los tests, antes de ejecutarlos: revisar si la cobertura tiene huecos o si hay aserciones mal planteadas, antes de que el agente se autoconvenza (y te convenza a ti) de que "todas pasan".
Además, el agente puede llamar a Rubber Duck de forma reactiva si se queda atascado en un bucle sin poder avanzar.
Y tú puedes pedirlo manualmente en cualquier momento: le dices a Copilot que critique su propio trabajo (o simplemente escribes /rubber-duck) y consulta al otro modelo, integra su feedback y te muestra exactamente qué cambió y por qué.
Técnicamente, Rubber Duck se invoca a través de la misma infraestructura de tool calling que usa Copilot para otros subagentes, así que no es una capa externa pegada con chicle ahí. Está integrado en el mismo sistema de agentes de Copilot CLI que ya conoces.
Cómo empezar a usarlo hoy
En GitHub Copilot CLI, Rubber Duck está disponible ahora mismo en modo experimental. Para activarlo, instala Copilot CLI y ejecuta el comando /experimental. A partir de ahí, si tienes acceso a GPT-5.4 y seleccionas cualquier modelo Claude en el selector, Rubber Duck estará disponible.
En Visual Studio Code tienes que ir al gestor de Agentes, no al chat del lateral.
Si utilizas GitHub Copilot App, no tienes que hacer nada: está disponible directamente.
¿Dónde tiene más sentido usarlo? En refactorizaciones complejas, en cambios de arquitectura con impacto amplio, en tareas de alta criticidad donde un fallo sale caro, y siempre que quieras una segunda opinión sobre un plan antes de comprometerte con él. También encaja bien si estás usando el modo fleet de Copilot CLI para lanzar múltiples agentes en paralelo: ahí la revisión cruzada puede ahorrar que varios agentes cometan el mismo error de base.
Por ahora solo funciona con modelos Claude como orquestador y GPT-5.4 como revisor. GitHub ya está explorando otras combinaciones de familias.
Probablemente la idea de usar familias de modelos complementarias para revisión cruzada es más interesante a largo plazo que intentar que un solo modelo sea cada vez más grande y solo nos dé su punto de vista. Y esta incorporación va a ser muy valiosa para los desarrolladores.