No. 03 · Technical

Git Insights

Aplicamos la IA a todo el patrimonio de código de Alberta para obtener una imagen real. Aquí explicamos cómo funciona y qué encontró.

Abstract. Alberta gestiona sus activos de código en GitHub Enterprise, pero el parque tecnológico había crecido hasta convertirse en un terreno confuso donde los prototipos se mezclaban con los sistemas en producción y ningún conjunto de datos estaba vinculado al siguiente. La dirección no podía obtener una respuesta definitiva sobre qué sistemas operamos ni cuál es su estado real. Por eso desarrollamos Git Insights, una herramienta agéntica que analiza de forma recursiva todo el patrimonio tecnológico e informa sobre el estado real de cada repositorio. Cincuenta agentes leyeron 466 millones de líneas de código en aproximadamente 20 horas, trazando el mapa del entorno digital y las capacidades del Gobierno. Este documento explica el problema, muestra en detalle cómo funciona la herramienta y presenta los resultados de los análisis. El proceso identificó los lenguajes y marcos de trabajo que nunca habíamos contabilizado, los repositorios sin pruebas ni documentación, los patrones de contribución que deterioran silenciosamente la seguridad, y el primer punto de referencia real sobre cómo se compara la IA con los seres humanos en nuestro propio código.
Como muchas organizaciones grandes, Alberta utiliza GitHub Enterprise como repositorio principal de código. GitHub ofrece herramientas de análisis eficaces para el análisis de código mediante funcionalidades como CodeQL, e integraciones con NPM y Maven para el análisis de vulnerabilidades en dependencias. Los secretos se detectan y bloquean automáticamente para poder eliminarlos, y nuestro equipo de ciberseguridad cuenta con evaluaciones bien integradas. El problema es que estas comprobaciones son en su mayoría reglas deterministas basadas en lógica, lo que genera una tasa elevada de falsos positivos, y no dicen nada sobre los aspectos que importan igual: la ausencia de documentación, las canalizaciones automatizadas de compilación y despliegue, y las pruebas unitarias automatizadas. Además, resultaba imposible obtener una revisión general del estado de nuestros sistemas de Gobierno. Para evaluar adecuadamente el estado actual de nuestra tecnología, necesitábamos mirar con más profundidad.


## §01 Los datos que no podíamos ver

Obtener una visión completa de una organización grande puede ser complejo. En su estado predeterminado, nuestros principales sistemas de registro no podían vincularse entre sí. La información sobre dependencias de GitHub no se transfería a nuestra Base de Datos de Gestión de Configuración. Esa base de datos residía en ServiceNow y se mantenía de forma manual, con más de 100 000 entradas que cubrían estas aplicaciones. Los registros de nuestras aplicaciones estaban dispersos entre GitHub, tickets de Jira y Confluence, rastreadores de incidencias, documentación en SharePoint y un conjunto de inventarios en hojas de cálculo. Integrar estos datos no estructurados había sido históricamente imposible, porque no existía una clave de vinculación que conectara un conjunto de datos con el siguiente.

Entradas de la Base de Datos de Gestión de Configuración mantenidas manualmente Más de 100 000. Almacenado en ServiceNow, sin flujo automatizado desde GitHub. La estructura lógica va del Ministerio al Proyecto o Programa, luego a la Aplicación y al repositorio, y desde allí se ramifica en sprints, el CMDB, tickets y documentación, sin que ninguno de estos elementos esté vinculado.

Como resultado, la dirección a nivel de viceministro y viceministro auxiliar no podía obtener respuestas significativas de las herramientas estándar, y el personal tenía dificultades para aportar análisis. El propio GitHub también corría el riesgo de convertirse en un terreno confuso donde los prototipos rápidos convivían con los sistemas en producción sin nada que los distinguiera. No podíamos afirmar con certeza qué sistemas operábamos, cuál era su estado, ni dónde residía la exposición real. Por eso tomamos medidas.


## §02 Construir un explorador

Usando Claude Code como agente de codificación, los modelos Opus y Sonnet para el análisis, y Google Enterprise Agent Platform como capa agéntica, Alberta desarrolló una herramienta llamada **Git Insights**. Es una herramienta agéntica que analiza de forma recursiva todo el patrimonio de GitHub. Funciona como un explorador de reconocimiento que examina cada repositorio para informar sobre lo que realmente contiene. El código constituye la fuente de verdad.

Líneas leídas por los agentes en aproximadamente 20 horas 466 millones de líneas. Un análisis de todo el parque tecnológico que ningún proyecto de consultoría podría igualar en tiempo ni en costo. Un tercio de los repositorios no tenía documentación alguna, por lo que los agentes la redactaron, y cada dependencia fue catalogada.

El momento de este análisis fue importante. Alberta ha observado aumentos significativos en el número de vulnerabilidades conocidas en todo el patrimonio tecnológico. En nuestros rastreadores de errores de software, las vulnerabilidades aumentaron con un punto de inflexión notable que coincide con el lanzamiento de Mythos de Anthropic, los últimos modelos Opus, y GPT 5.4 y 5.5 de OpenAI. La misma capacidad que permite a una herramienta como Git Insights leer el patrimonio en profundidad es la que permite a los atacantes encontrar las fallas en él, un punto que se desarrolla en detalle en el documento sobre ciberseguridad. En un plazo de 4 semanas desde el lanzamiento de Mythos, Alberta desarrolló nuestras propias herramientas y métodos para llevar a cabo este análisis.


## §03 Cómo funciona Git Insights

A continuación se explica en términos sencillos lo que Git Insights hace realmente. Trabaja en dos capas. En la capa superior, un conjunto de agentes recorre todo el patrimonio al mismo tiempo. Dentro de cada repositorio de código, cada agente ejecuta la misma rutina fija. Un motor de reglas revisa la base de código y señala los patrones conocidos para una investigación más profunda, mientras que el agente de IA interviene para revisar y emitir un juicio. Todos los hallazgos se registran y pueden ser auditados por personas hasta la línea de código específica.

Los agentes se ejecutan en Google Enterprise Agent Platform. Google trabajó estrechamente con Alberta para garantizar que dispusiéramos de la capacidad de procesamiento suficiente, aumentando nuestra capacidad a 25 millones de tokens por minuto para maximizar la velocidad de análisis. También construimos la herramienta para que fuera resiliente. Si un análisis falla o alcanza un límite de velocidad, ese trabajo espera y reintenta mientras los demás continúan, y si el análisis completo se interrumpe, retoma exactamente donde lo dejó. Esta resiliencia es la que le permite leer 466 millones de líneas en miles de repositorios en aproximadamente 20 horas, llevando nuestra capacidad de procesamiento al límite.

Una pregunta legítima es hasta qué punto un Gobierno puede confiar en lo que informa una IA. Tres elementos garantizan su fiabilidad. Primero, el trabajo rutinario y contable —listar archivos y detectar los patrones problemáticos conocidos— lo realiza código ordinario, que no puede inventar un resultado. Segundo, no se acepta sin más lo que dice la IA: cuando notifica un problema, debe indicar el archivo y la línea exactos, señalar la gravedad y el motivo, y explicar cómo corregirlo, de modo que un desarrollador pueda abrir el archivo y verificar la afirmación. Tercero, evalúa cada repositorio con la misma lista de verificación fija, que abarca seguridad, calidad del código, arquitectura, documentación, pruebas, mantenibilidad y el estado de las bibliotecas de las que depende, de modo que una puntuación significa lo mismo en el milésimo repositorio que en el primero. Cualquier hallazgo que informe la IA puede abrirse y cotejarse con el código real. Los hallazgos se almacenan en una base de datos, lo que permite que más agentes ejecutados por los equipos de ciberseguridad y entrega realicen un metaanálisis para detectar tendencias e información transversal.

Cada análisis detecta las tecnologías antiguas que se ocultan en el interior, como COBOL, ASP clásico y versiones de .NET y Java que llevan mucho tiempo sin soporte, e infiere a qué ministerio pertenece. Enumera cada dependencia de la que depende un sistema, que es exactamente el inventario que nunca tuvo nuestra Base de Datos de Gestión de Configuración y que ahora puede nutrirse de esta fuente. Señala los repositorios que contienen información personal sensible, de modo que un riesgo para la privacidad resulta visible en lugar de quedar oculto. Y para los 1 280 repositorios que no tenían ninguna documentación, el agente la redactó a partir de lo que acababa de leer, al tiempo que validaba o mejoraba el README de todos los demás repositorios. Esto cerró la brecha por completo: por primera vez, cada base de código del patrimonio quedó documentada.

Los análisis cumplen una doble función: revelan cómo funciona cada sistema y qué hace por la ciudadanía. La función de negocio de cada aplicación se clasificó en una jerarquía de capacidades de negocio, lo que nos permitió categorizar cada aplicación por función. El registro combinado de cada repositorio va mucho más a fondo que cualquier inventario que hayamos tenido antes. Este proceso también identificó redundancias funcionales que podemos abordar para racionalizar el patrimonio. Como se señala en el siguiente documento, creemos que en algunas áreas podemos lograr una reducción de 10 a 1 de nuestro código redundante mediante la estandarización de funciones comunes asistida por la IA.

Los resultados de este análisis de Git Insights se consolidan en una base de datos y se presentan a través de un panel ejecutivo. Incluye una vista ejecutiva del estado y el riesgo, una cuadrícula de nueve casillas que sitúa cada sistema según su actividad y su estado, fichas de salud del código por repositorio, perfiles de contribución y el desglose de la disposición, todo exportable a un documento, una hoja de cálculo o datos brutos. La consolidación transversal profunda entre repositorios —donde cientos de sistemas superpuestos en un único ministerio se agrupan en un conjunto más reducido de capacidades reconstruidas— es un motor propio con su propio documento; véase Git Insights Ministry.

"Por primera vez, un viceministro pudo formular una pregunta sobre el parque tecnológico y obtener una respuesta fundamentada en el propio código." · Libro blanco 3 · Git Insights


## §04 El estado real del parque tecnológico

Una vez completado el análisis, pudimos medir por fin lo que hasta entonces solo habíamos estimado. El dominio que Git Insights cartografió era más amplio de lo que nadie había contabilizado.

Las carencias estructurales resultaron aún más reveladoras. En cerca de 3 400 repositorios, las prácticas que hacen que el código sea seguro de modificar estaban ausentes con mucha más frecuencia de lo que estaban presentes.

Cada repositorio recibió una puntuación sobre diez en función de su estado general, evaluando la calidad del código, la seguridad, las pruebas y la documentación. En todo el parque tecnológico, el promedio resultó bajo, arrastrado hacia abajo por la ausencia de pruebas, canales de integración y documentación señalada anteriormente.


## §05 Evaluación comparativa interna

También medimos las contribuciones de código de nuestro personal y contratistas. Lo hicimos para identificar dónde la variabilidad humana ordinaria erosiona nuestros controles de ciberseguridad y nuestros estándares, de modo que podamos saber dónde la formación y mejores herramientas serán más útiles. Un análisis retrospectivo con una herramienta como Git Insights no puede conocer el contexto de cada decisión individual que un desarrollador tomó en un día determinado. Lo que sí hace es revelar los patrones, agregados a gran escala y de forma anonimizada. A lo largo de más de ocho mil cien colaboradores y ocho años de historial, esos patrones fueron claros.

Las mayores carencias que emergieron se relacionaron con la consistencia y el cumplimiento de los estándares. Cabe señalar que esto no es una crítica a ningún trabajador o grupo, ni un indicio de mala intención. Los desarrolladores que contribuyeron son, en conjunto, personas capacitadas y diligentes, y la mayor parte del código de aplicación individual que produjeron era sólido en su momento. Los problemas que expusieron los datos fueron de carácter sistémico. A lo largo de ocho años, más de ocho mil personas —muchas de ellas contratadas como contratistas individuales en distintos ministerios— construyeron según estándares que con frecuencia no estaban documentados, se comunicaban de forma inconsistente y no figuraban en los propios contratos. Muchos de esos estándares son aspiracionales y de principios, en lugar de prescriptivos y definidos, lo que deja una brecha entre la intención de quien los redacta y la interpretación y aplicación de quien los lee. Cuando las reglas no están definidas, es razonable —y casi inevitable— que personas capaces tomen sus propias decisiones y sigan el camino de menor resistencia. Esto conduce al tipo de desviación observada en el análisis de Git. Los estándares también evolucionan con el tiempo. Las prácticas más recientes, como la contenerización y los canales de compilación automatizada, nunca llegaron al código más antiguo, y en un parque tecnológico tan grande no existía ninguna forma práctica de auditar el cumplimiento en absoluto. Esa última carencia —la imposibilidad de ver los patrones del conjunto— es la que la IA agéntica ha venido a resolver.

Visto así, el parque tecnológico había crecido como una ciudad medieval. Cada estructura se levantó para responder a la necesidad de su momento, sólida en sus propios términos, pero el conjunto se volvió denso y difícil de recorrer con el paso del tiempo. Un análisis basado en reglas como Git Insights traza líneas rectas a través de ese crecimiento orgánico. El precedente más cercano es el plan del barón Haussmann para París, cuyos grandes bulevares se abrieron paso a través del tejido medieval para imponer orden y conectividad tras siglos de construcción no planificada. El resultado es la ciudad en dos capas que conocemos hoy: un crecimiento orgánico unido a un plan racional superpuesto. Sería injusto calificar de deficiente lo que ocho mil desarrolladores construyeron a lo largo de ocho años. Pero sería igualmente erróneo asumir que simplemente debe repetirse. Nos encontramos ante un problema complejo, y resolverlo con rapidez requerirá medidas deliberadas y estructurales de esa misma envergadura. Para afrontar un reto tan significativo, necesitamos desarrollar nuevas formas de trabajar.


## §06 Colaboración entre personas e IA

Hay muchas críticas dirigidas a la IA por los errores que comete. Se escribe mucho sobre su potencial para producir alucinaciones y sesgos. Sin embargo, estas narrativas revelan un fuerte sesgo hacia lo reciente en la forma en que los seres humanos reportamos esos fallos. Una respuesta incorrecta de la IA se recuerda; las diez mil correctas, no. Muchas de estas críticas a la IA cometen el error más grave de no considerar también el desempeño humano en un ámbito equivalente.

Nuestros hallazgos fueron claros: con los controles adecuados descritos en el documento sobre el arnés, las últimas herramientas de codificación asistidas por la IA pueden contribuir a lograr una mayor consistencia en las tareas de codificación y análisis, tanto dentro de una sola aplicación como en todo el parque tecnológico.

Git Insights nos proporcionó el punto de referencia para hacer esta afirmación con evidencia. Los metadatos extraídos de GitHub produjeron el primer estudio longitudinal y a gran escala realizado en Alberta sobre el rendimiento técnico humano. Medimos el trabajo real de más de ocho mil personas a lo largo de ocho años: cada confirmación, cada solicitud de incorporación de cambios y el estado del código que produjeron, en todo el parque tecnológico. Este proceso nos dio un punto de referencia para medir nuestras futuras inversiones en velocidad, calidad, seguridad y procesos relacionados con la IA.

Antes de aplicar herramientas basadas en IA, Tecnología e Innovación midió con qué regularidad los equipos de desarrollo cumplían el 100 % de los estándares en la primera versión publicada de una aplicación. El cumplimiento total de los estándares solo se alcanzó el cuarenta por ciento de las veces en esa primera versión, lo que obligó a rehacer el trabajo y publicar versiones posteriores para finalizarlo, debido a los plazos ajustados y a la ausencia de un enfoque basado en estándares.

Productos que cumplen todos los estándares en la primera versión 40%. Muchas aplicaciones nuevas requieren ajustes moderados o significativos para alinearse con todos los estándares, una proporción inaceptablemente baja.

Compare esta cifra con una fábrica de automóviles. No aceptaríamos un mundo en el que solo el cuarenta por ciento de los vehículos saliera de la fábrica superando los controles de seguridad. Lo que convierte a una planta automotriz moderna en un logro de la ingeniería es el esfuerzo por eliminar la ambigüedad y llevar cada unidad hacia el mismo resultado elevado, seguro y reproducible. Un sistema de TI no debería responder a un estándar inferior. En un mundo digital, preservar la privacidad de las personas a las que servimos es fundamental, y la integridad de nuestras instituciones y nuestra economía depende ahora de la integridad de nuestra tecnología. Las consecuencias de una falla de TI pueden ser tan graves como las de una falla mecánica.

Esta analogía con la fábrica nos ofrece un plan director razonable para mejorar la calidad y la consistencia. La creatividad y el juicio humanos se aplican al inicio —en el diseño y la generación de ideas— y al final —en los servicios, el soporte y las relaciones humanas—. En el centro se sitúan las herramientas, los procesos y los controles que convierten buenas ideas y diseños en productos seguros y consistentes. Construido en colaboración con la IA, ese centro se convierte en una «línea de producción» de software: estándares aplicados de la misma manera en cada ocasión, seguros desde el punto de vista de la ciberseguridad, accesibles y auditables por diseño. Este concepto nos brinda un modelo para lo que denominamos la «Fábrica de IA», y los documentos siguientes la desarrollan etapa por etapa, comenzando con diseño y generación de ideas.

Tanto las personas como la IA cometen errores, y ambas son capaces de resolver problemas de forma creativa. La lección de este análisis es que las herramientas están cambiando. Las personas que trabajan de manera creativa con la IA obtienen mejores resultados al aplicar nuevas estrategias y métodos que resuelven estos problemas. A medida que la IA asume más tareas de codificación rutinaria, el esfuerzo humano se desplaza hacia la arquitectura, la estrategia, la creatividad, el diseño y el trabajo de acompañarse mutuamente a través del cambio. La creatividad humana sigue siendo insuperable y central en el proceso. Ninguna IA concibió Git Insights; eso fue enteramente humano. Lo que la IA hizo posible fue el análisis de un extenso patrimonio digital por un costo ínfimo —menos de dos mil dólares— en cuestión de horas. En una colaboración bien estructurada entre una persona y un agente de IA, los errores se detectan de inmediato, se resuelven con rapidez y el ritmo de avance aumenta.

Eso reencuadra la pregunta que este documento se propuso responder. Nunca fue razonable esperar que más de ocho mil personas mantuvieran un único estándar de calidad solo por voluntad propia, y menos aún cuando ese estándar era impreciso y cambiante. La pregunta ahora es qué hacemos con este conocimiento. Gracias a su amplia ventana de contexto y su velocidad, la IA puede leer el patrimonio completo y ayudar a la dirección a ver ambos lados del balance a la vez: en qué destacan las personas —creatividad, conexión humana, generación de ideas, perspicacia, experiencia y juicio— y dónde el sistema se desvía. La IA puede intervenir para apoyar la aplicación consistente de estándares, el seguimiento de procesos y la auditoría de los casos en que no se cumplieron. La retroalimentación puede recopilarse a escala y convertirse en acciones para mejorar los resultados. Aplicadas a ese fin, las herramientas nos permiten proteger la calidad y la seguridad de los sistemas de los que dependen los albertanos sin pedirle a nadie que sea menos humano.

Lo que escala aquí es la posibilidad. El siguiente documento lleva Git Insights a un nivel superior —el nivel ministerial—, donde cientos de sistemas que se superponen se analizan en conjunto y se consolidan en un conjunto más reducido de capacidades modernas y reconstruidas, acompañadas de un plan con costos estimados. Consulte Git Insights Ministerio.

Tags: git-insights, code-analysis, agents, technical-debt, cybersecurity

Open the interactive version