GitHub: agentes IA necesitan supervisión, dice Sanz del Río

Qué dijo la directiva de GitHub sobre los agentes de IA

Dejar a un agente de inteligencia artificial programando toda la noche suena a productividad infinita. Margarita Sanz del Río, directiva de GitHub, lo aterriza con una condición incómoda: «Cada poco tiempo tienes que comprobar lo que hacen y validarlo». En una entrevista con LA RAZÓN, la responsable de estrategia y operaciones comerciales para la relación con Microsoft sostiene que la autonomía solo tiene valor si alguien revisa después lo que la herramienta produjo.

El escenario que originó la pregunta era concreto: un desarrollador se va a dormir y deja sus agentes trabajando. La respuesta no fue un entusiásmo ciego, sino una advertencia sobre formación, organización y el papel del ingeniero. El valor de ese trabajo nocturno depende de lo que haya conseguido el agente cuando una persona vuelva a mirarlo.

Para un founder que ya está metiendo IA en su equipo de producto, el mensaje es directo: el agente no reemplaza al criterio, lo desplaza hacia la revisión.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Por qué la autonomía sin control no funciona?

Sanz del Río marca un límite explícito al encargo de un proyecto completo sin intervención: «Ahora mismo tampoco tiene sentido dejar a los agentes trabajando en una aplicación de cero a cien». Es decir, delegar la construcción entera de un producto y desentenderse no es un caso de uso maduro todavía.

La razón está en cómo se construye la confianza. Un ingeniero puede llegar a confiar una parte mucho mayor del proyecto a la IA, pero para eso habrá tenido que familiarizarse con la herramienta y mantener actualizados el contexto y las instrucciones. En GitHub, esa confianza se gana con trabajo previo y con conocimiento de cómo responde la tecnología a las necesidades concretas del proyecto.

La advertencia sobre el acceso abierto es tajante: hasta que los equipos estén capacitados, «no puedes abrir la puerta y dejar que todo el mundo la utilice a lo loco». El contexto debe reflejar lo que se quiere construir y las instrucciones deben orientar la ejecución. La persona que conoce el proyecto sigue siendo parte del proceso, incluso cuando el agente ejecuta por su cuenta.

¿Qué debe revisar un ingeniero a la mañana siguiente?

La guía oficial de GitHub para revisar código generado por IA concreta las comprobaciones mínimas. La lista es útil como checklist operativa para cualquier equipo:

Ejecutar las pruebas del código generado.
Buscar problemas de seguridad.
Verificar que el resultado encaja con los requisitos y la arquitectura del proyecto.
Valorar la claridad y el mantenimiento del código.
Confirmar que resuelve el problema adecuado, no solo que funciona.

Sanz del Río añade el ángulo de negocio: al volver al ejemplo del trabajo nocturno, propone fijarse en cómo se utilizó el modelo y en si lo producido tiene valor por la mañana. Esa revisión abarca resultados y posibles problemas del código. Dejar el agente en marcha describe solo una parte del encargo; después hay que decidir qué sirve y qué se corrige.

El coste real: el modelo barato puede salir caro

La formación también toca la factura. «Simplemente dar las herramientas a la gente no es suficiente», afirma la directiva, que considera que una mala formación y una mala gestión pueden disparar el gasto. En una entrevista previa con LA RAZÓN, Sanz del Río ya había advertido sobre elegir el modelo más económico sin mirar el trabajo completo: «Pero eso puede acabar costando más».

Su ejemplo: «Si utilizas un modelo más barato, con una ventana de contexto más pequeña, pero necesitas hacer cinco iteraciones, a lo mejor te acaba costando más que uno más grande que consume más tokens al principio, pero solo necesita dos iteraciones». La diferencia no está en la tarifa por token, sino en cuántos intentos hacen falta para terminar la tarea.

Ese cálculo se volvió más relevante con el cambio comercial que GitHub anunció en su conferencia GitHub Universe 2026. Según InfoWorld, los clientes de GitHub Enterprise pasan a pagar por créditos de IA según consumo en lugar de comprar una suscripción de Copilot aparte. Y el propio GitHub estima, según ese medio, que una revisión Lite consume unos 0,25 dólares en créditos, una Balanced 1,50 y una Max 10.

La presión por adoptar estas herramientas es real y la directiva la describe sin adornos: «Todo va muy rápido: nadie quiere ser el primero, pero nadie quiere ser el último». Ante ese ritmo, reclama equipos capaces de manejar la tecnología y validar sus entregas.

¿Qué está cambiando en el desarrollo de software?

El contexto del sector explica por qué la conversación sobre supervisión llegó justo ahora. En GitHub Universe 2026, celebrado el 28 de octubre, GitHub presentó Copilot Fusion, un sistema que coordina varios modelos de IA y elige cómo combinarlos según la tarea, y Copilot Projects, que permite coordinar múltiples agentes trabajando en paralelo sobre distintos repositorios.

El volumen ya es difícil de ignorar. Según el informe Octoverse 2026 de GitHub, recogido por Moneycontrol, la plataforma registró 34.300 millones de commits y 1.300 millones de pull requests en el año, con 566 millones de repositorios públicos y de código abierto, más de un 30% interanual. El directivo de Microsoft Jay Parikh lo resumió así: en un par de años se pasó de escribir código a mano a gestionar decenas, a veces cientos, de flujos de trabajo con agentes.

Ese salto tiene un costo de coordinación documentado. InfoWorld cita un estudio de arXiv de 2026, CooperBench, según el cual los agentes de IA lograron tasas de éxito aproximadamente un 30% menores cuando colaboraban en tareas que cuando las resolvían individualmente. Más agentes en paralelo también significan más pull requests que revisar, más conflictos de integración y más presión sobre los pipelines de CI.

Qué significa esto para tu startup

El mensaje de Sanz del Río no es un freno a la adopción, es una advertencia sobre el orden de las cosas. Delegar más código a agentes es viable, pero la supervisión no se delega.

Define puntos de control antes de escalar. Si tu equipo usa agentes para tareas de código, establece revisiones obligatorias antes de fusionar cambios generados por IA. La propia guía de GitHub apunta a pruebas, seguridad, encaje con la arquitectura y mantenibilidad como el mínimo verificable.
Invierte en formación, no solo en licencias. «Simplemente dar las herramientas a la gente no es suficiente», dice la directiva. Un equipo que no sabe dar contexto ni instrucciones precisas genera más iteraciones, más rework y una factura mayor.
Mide el coste por tarea terminada, no por token. Antes de elegir el modelo más barato, calcula cuántos intentos necesita para resolver el trabajo. Un modelo con menos capacidad puede multiplicar las iteraciones y salir más caro al final.
Empieza por tareas acotadas. Actualizaciones de dependencias, migraciones de versiones o corrección de bugs repetitivos son buenos primeros encargos. El proyecto completo de cero a cien todavía no es un caso de uso maduro.

La responsabilidad de comprobar el resultado sigue en manos de las personas, aunque una parte creciente de la ejecución se delegue. Para un founder, eso significa rediseñar el rol del ingeniero hacia la definición de tareas, el contexto y la validación, más que hacia la escritura de líneas de código.