GitHub Code Quality y el cooldown de Dependabot: dos frenos para el código que ya escribe la IA

Esta semana GitHub hizo dos anuncios que, a primera vista, parecen no tener mucho en común. El 20 de julio llevó a disponibilidad general (GA) su producto GitHub Code Quality, que combina CodeQL con detección asistida por IA y sugerencias de Copilot Autofix para pull requests. El 23 de julio le cambió el comportamiento por defecto a Dependabot: ahora espera tres días antes de abrir un PR de actualización de versión, en vez de hacerlo apenas sale una release nueva. Uno habla de calidad de código, el otro de cadena de suministro, pero los dos responden al mismo problema, y GitHub lo dice sin rodeos en el anuncio de Code Quality: "la IA acelera la producción de código, y Code Quality ayuda a los equipos a enviar código en el que puedan confiar". El cuello de botella se movió de escribir a revisar, y esta semana GitHub metió dos frenos distintos en ese mismo punto del proceso.

El cuello de botella se movió

La premisa no es nueva para quienes siguen este blog: ya la tocamos al hablar de watsonx Code Assistant for i y de AS/Forward, donde la lección era que el valor no está en el modelo que genera o convierte código, sino en la capa de verificación que lo rodea. Lo que cambia esta semana es que la misma lógica aparece ahora en la infraestructura genérica de desarrollo —no en una herramienta de nicho para RPG, sino en GitHub, que es donde vive la mayoría de los repositorios empresariales, incluidos los que alimentan proyectos de modernización de IBMi. Si tu equipo ya usa Copilot, Claude Code o cualquier agente para generar parches, código nuevo o incluso partes de una migración, el volumen de cambios que llega a un pull request creció más rápido que la capacidad de un humano para revisarlos uno por uno. GitHub reporta que, en su propia organización, los equipos resuelven el 67,3% de los hallazgos de Code Quality antes de mergear el PR — un dato que solo tiene sentido si asumís que antes esos hallazgos se colaban.

GitHub Code Quality: compuertas, no solo alertas

Code Quality ya estaba en preview pública, con más de 10.000 empresas usándolo, pero la versión GA agrega piezas que lo vuelven una herramienta de gobierno y no solo de detección. Primero, dashboards a nivel de organización que muestran puntajes de mantenibilidad y confiabilidad por repositorio, en vez de dejar que cada equipo mire sus propios hallazgos de forma aislada. Segundo, métricas de cobertura de código que se renderizan directamente en el PR a partir de los reportes de test que ya generás, en formato Cobertura XML — no hay que instrumentar nada nuevo. Tercero, y lo más relevante operativamente: compuertas de calidad ("quality gates") a través de rulesets de GitHub, con umbrales de cobertura y un modo de evaluación para hacer rollout gradual antes de bloquear merges de verdad. Es la diferencia entre "te aviso que hay un problema" y "no dejo que se mergee hasta que lo resuelvas o lo apruebes explícitamente".

El costo es una señal de hacia dónde apunta el producto: 10 dólares por committer activo al mes, más facturación por uso de la parte de IA —detección asistida y Autofix, sin necesidad de licencia de Copilot— y cómputo para correr CodeQL en Actions. Es un producto pago independiente, no incluido en GitHub Advanced Security, y no disponible en GitHub Enterprise Server al lanzamiento. Para un equipo evaluándolo, la pregunta práctica no es "¿detecta bien?" sino "¿qué rulesets convierto en compuerta obligatoria primero?" — un candidato razonable es exigir hallazgos de confiabilidad en servicios críticos antes que hallazgos de mantenibilidad en librerías internas, donde un falso positivo bloqueando un merge sale más caro.

Dependabot: frenar la actualización, no la seguridad

El segundo anuncio parte de un caso concreto que GitHub usa para justificar el cambio. En septiembre de 2025, alguien phisheó las credenciales de un solo mantenedor de npm y publicó versiones envenenadas de paquetes como chalk y debug —descargados juntos más de 2.000 millones de veces por semana— que reescribían direcciones de wallets de criptomonedas en cualquier app de navegador que los cargara. Las versiones maliciosas estuvieron activas apenas dos horas antes de que la comunidad las detectara y npm las bajara. Dos horas es una respuesta rápida para un ecosistema entero, pero es tiempo de sobra para que una herramienta de actualización automática vea la versión nueva, abra un PR y la ponga frente a tu equipo, porque ese tipo de herramientas está diseñado justamente para agarrar la release más reciente apenas aparece.

Según datos de GitHub Advisory Database, en el año que terminó en mayo de 2026 se publicaron más de 6.500 avisos de malware en npm —cerca de 18 paquetes maliciosos nuevos por día—, frente a unos 6.200 el año anterior. Con ese patrón, Dependabot ahora espera por defecto tres días desde que se publica una release antes de abrir un PR de actualización de versión. La letra chica importa: esto aplica solo a actualizaciones de versión, no a actualizaciones de seguridad — si ya hay un aviso de vulnerabilidad publicado para una versión que usás, Dependabot avisa de inmediato, sin esperar. El cooldown se ajusta por proyecto con la opción cooldown en dependabot.yml, así que un equipo con paquetes internos de alta confianza puede tratarlos distinto de las dependencias públicas.

Dos anuncios, un mismo diagnóstico

Lo que conecta ambos cambios no es la tecnología sino el diseño: los dos insertan una pausa deliberada en un punto del pipeline que antes era automático de punta a punta. Code Quality frena el merge hasta que un hallazgo se resuelva o se apruebe explícitamente; Dependabot frena la adopción de una versión nueva hasta que pase una ventana mínima de escrutinio comunitario. Ninguno apuesta a que el modelo o la automatización acierten siempre: los dos asumen que van a fallar en algún porcentaje de los casos y diseñan el sistema para que ese fallo se note antes de llegar a producción. Es el mismo principio de "ground truth verificable antes de confiar" que vimos con AS/Forward para RPG, ahora en la infraestructura genérica que probablemente ya usa tu equipo, trabajes sobre IBMi, Java o cualquier otro stack.

Conclusión práctica

Si tu organización ya corre GitHub Enterprise Cloud o Team, hay dos tareas concretas para esta semana. Primero, revisá tu archivo dependabot.yml: si no tenías configurado un cooldown explícito, ahora tenés uno de tres días por defecto en las actualizaciones de versión, y vale la pena decidir a propósito si eso te sirve tal cual o si necesitás una ventana distinta para paquetes internos o de alta confianza. Segundo, si estás evaluando Code Quality —o ya lo corriste en preview—, no actives rulesets de bloqueo en todos los repos de una sola vez: arrancá en modo evaluación en un subconjunto acotado, mirá qué porcentaje de hallazgos se resuelve antes del merge en tu propio equipo, y recién después decidí qué se vuelve compuerta obligatoria. La lección de fondo, otra vez, es que la parte difícil de la IA en el desarrollo de software no es generar más código más rápido —eso ya está resuelto—, sino construir el sistema de frenos que decide qué de ese código llega a producción y qué no.

Fuentes: GitHub, "GitHub Code Quality is now generally available", GitHub Changelog, 20 de julio de 2026; Carlin Cherry, "The case for a cooldown: Why Dependabot now waits before issuing version updates", GitHub Blog, 23 de julio de 2026.