Autora: Zheng Jiamei
Editor: Cen Feng
Git ha sustentado el desarrollo de software durante más de veinte años, pero Anthropic decidió reemplazarlo. Para que el código generado continuamente por Claude pudiera integrarse sin problemas en el flujo de desarrollo, 7 ingenieros dedicaron 5 meses a desarrollar el sistema de control de versiones Scion y a migrar hacia él los repositorios de código principales. En el mes 5 de este año, Anthropic fusionaba de media unas 2500 modificaciones de código al día; para el mes 9 ya superaban las 3 万, y solo el sistema de CI ejecutaba alrededor de 2500 万 detecciones de código diarias. La velocidad de escritura de código aumentó, pero preparar repositorios, sincronizar objetos y consultar el historial consumía cada vez más recursos de cómputo. Casi en el mismo periodo, GitHub reemplazó el juicio de un LLM generalista en el escaneo de secretos por un ModernBERT ajustado. Instituciones como la Universidad de Columbia y Google DeepMind, por su parte, convirtieron mediante BTTF las formas de onda de simulación de chips en SQLite, permitiendo que los agentes usaran SQL para investigar anomalías. Scion es en línea por defecto, BTTF convierte las formas de onda en interfaces de consulta, y GitHub delega los juicios de alta frecuencia en un clasificador. Los sistemas diseñados en torno al ritmo de desarrollo humano empiezan a soportar una carga de otro tipo, la que traen los agentes.
01
Por qué la capacidad offline de Git se convirtió en una carga
El diseño distribuido de Git permite a los ingenieros, tras clonar el repositorio, hacer commits, fusionar y consultar el historial incluso sin conexión. Pero las tareas de lectura masiva de código de Anthropic son trabajos de CI siempre conectados y sandboxes de agentes que se destruyen tras unos minutos de ejecución y que quizá solo necesitan unos pocos archivos, un diff, o confirmar la relación de ascendencia entre dos commits. Preparar un repositorio local para estas operaciones tiene un coste repetitivo cada vez mayor. El historial de la rama principal de Anthropic ronda los 100 GB, y la copia de trabajo comprimida supera los 25 GB. Si los 25 millones de checkouts diarios obtuvieran cada uno una copia completa, el tráfico teórico superaría los 600 PB. Aunque la empresa usa clones superficiales, checkouts dispersos, snapshots y cientos de réplicas de Git, las réplicas siguen necesitando sincronización, los snapshots caducan y las consultas de historial aún requieren completar objetos. Cuanto más activo el repositorio, mayor el coste de mantenimiento. Scion reduce el cliente a una entrada ligera. La creación de commits, la fusión, el rebase y las consultas de historial se trasladan a un servicio central; localmente solo se monitorizan los cambios de archivos y se mantiene una pequeña caché, expandiendo bajo demanda cuando se necesita un directorio de trabajo. Si el CI solo quiere calcular un diff, puede llamar directamente a la API sin necesidad de un checkout completo. Esto sacrifica la autonomía sin conexión, pero reduce las inicializaciones repetidas. El formato de commit también cambió. Un Git commit apunta al árbol de directorios que describe el estado del repositorio, mientras que el changeset de Scion registra, mediante entradas de registro de escritura anticipada, los archivos modificados respecto al primer commit padre, referenciando los datos mediante punteros direccionados por contenido. Crear un changeset no requiere generar un packfile de Git ni mover de inmediato las ramas compartidas; solo cuando se actualizan referencias como main, el sistema ejecuta un compare-and-swap sobre un registro de una sola fila en Spanner. Los agentes pueden generar cambios de forma concurrente, y la competencia se concentra cuando se mueven las referencias de rama. Pero las consultas de historial presentan aún dificultades: los registros incrementales no pueden responder directamente quién modificó cierta línea o qué ha vivido un archivo. Scion mantiene derived data para blame, historial de rutas y tablas de saltos del grafo de commits, precalculada según las relaciones de commit padre, o generada una vez producida la consulta. La escritura y el análisis de historial pueden escalarse de forma independiente. Según Leifeng Wang, al hacer un checkout, el cliente scn parte del árbol de directorios objetivo y solo solicita los tree y blob faltantes. Las peticiones pasan sucesivamente por el scion-daemon del nodo, el scion-cache de la zona y luego el scion-server acude a Spanner o al almacenamiento de objetos. Los objetos, una vez escritos, son inmutables, por lo que la caché puede reutilizarse entre tareas, reduciendo la negociación, la compresión y las transferencias repetidas. Anthropic afirma que la tasa de aciertos de caché supera el 99%, y limita el tráfico de retorno a origen ante fallos. Tras la migración, Scion redujo unas 200 veces los requerimientos de CPU y memoria en comparación con el antiguo sistema de réplicas de Git, los checkouts pasaron de minutos a segundos, y el CI liberó cerca del 25% de capacidad de CPU. Las 200 veces se refieren al consumo de recursos de infraestructura, no a una aceleración global de las operaciones de Git. Anthropic construyó también en paralelo herramientas de revisión de código Antique, búsqueda de código fuente, IAM y fusión masiva, para adaptarse al nuevo protocolo. El mantenimiento de los servicios en línea se convirtió asimismo en un nuevo coste.02
Que la base de datos lea las formas de onda para que los agentes puedan rastrear fallos
La verificación de chips enfrenta otro tipo de obstáculo. Las formas de onda VCD y FSDB generadas por la simulación RTL registran el estado de numerosas señales a lo largo del tiempo; el volcado de diseños complejos puede alcanzar decenas de GB, incluso TB. Según Leifeng Wang (cuenta pública: Leifeng Wang), los ingenieros pueden buscar anomalías en un visor de formas de onda a lo largo del eje temporal, pero si un agente convierte la forma de onda bruta en texto, el contexto se llena rápidamente de marcas de tiempo, nombres de señales y transiciones repetidas. Rastrear otras señales puede implicar releer los archivos. Además, los humanos están acostumbrados a buscar la aguja en el pajar con los ojos en los gráficos, pero ningún contexto, por grande que sea, puede contener en un agente decenas de GB de archivos físicos. Por tanto, convertir esos archivos muertos en interfaces activas que puedan invocarse con precisión mediante SQL es la solución óptima para alimentar de datos a la IA. BTTF delega el acceso a los datos en SQLite. signal_metadata guarda información estática como nombres de señales, tipos y jerarquía, y signal_changes registra el ID de la señal, la marca de tiempo y el valor tras el cambio; ambas tablas se relacionan mediante el ID. Para consultar el estado de una señal en un instante dado, el SQL encuentra el registro de cambio más cercano anterior a ese momento; para examinar conmutaciones en un intervalo, se filtra y agrega por ventana temporal. El estado es constante entre dos transiciones, y no debe confundirse la ausencia de nuevos registros con un estado desconocido. El modelo solo necesita procesar la pregunta y unos pocos eventos devueltos. Por ejemplo, si cierto protocolo de handshake agota el tiempo de espera, el agente puede buscar primero los cambios en las señales de petición y respuesta, reducir luego al intervalo anómalo y examinar las relaciones temporales. La base de datos se encarga de la búsqueda; el modelo decide qué consultar a continuación. Las consultas deben alinearse con los ID de señal, las unidades de tiempo y la versión RTL. Pero trasladar las formas de onda a la base de datos no elimina la presión de forma automática. Los relojes de alta frecuencia generan registros densos, y los INSERT fila a fila conllevan costes transaccionales. BTTF construye durante la ingesta un mapeo del identificador de forma de onda a ID de base de datos, contabiliza las conmutaciones de señal, y combina filtrado por reloj, recorte de señales sin conmutaciones e inserción por lotes. Sin recortar, la base de datos ocupa 1420 MB y las consultas tardan unos 410.5 milisegundos; tras filtrar los relojes y las señales sin conmutaciones, el tamaño baja a 395 MB y el tiempo a 94.8 milisegundos. Si se eliminan además las señales con tasa de conmutación inferior a la media, la base de datos puede reducirse a 185 MB, pero la cobertura de actividad queda en apenas el 64.23%. Un fallo raro puede aparecer precisamente en una señal de control que casi nunca conmuta. Si los datos se eliminan en la fase de importación, los agentes posteriores no podrán recuperar la evidencia. El recorte debe subordinarse a las aserciones y a las necesidades de depuración. Con la interfaz SQL, BTTF reparte además las tareas entre distintos agentes: el Orchestration Agent descompone las tareas, el Analysis Agent genera las consultas, el Verification Agent comprueba las aserciones y las vincula con el código fuente RTL, y el Evaluation Agent verifica los rangos temporales, las relaciones entre campos y la integridad de los resultados. Por ejemplo, si ASSERT_KNOWN detecta estados desconocidos X/Z en una señal, el sistema fija primero el momento de la violación, examina luego hacia atrás el estado de los operandos relacionados y localiza progresivamente el módulo posible. Si el SQL falla, puede corregirse y continuar. En experimentos con 4.2 GB de formas de onda, 18450 señales y 150 consultas etiquetadas por expertos, el equipo de investigación alcanzó una precisión de ejecución del 95.33%. La puntuación de calidad del Multi-Agent mejoró un 17.3% respecto al agente único, la latencia media aumentó hasta unas 1.96 veces, y la precisión de la comprobación estática de SVA fue del 84.62%. El esquema puede soportar análisis de post-simulación, pero la ingesta continua y la atribución compleja aún requieren validación.03
Por qué el escaneo de secretos volvió a los clasificadores
Una cadena de alta entropía puede ser una credencial real, pero también datos de prueba, un marcador de posición o un checksum. Las expresiones regulares encuentran rápidamente formatos sospechosos, pero no son buenas juzgando el contexto del código; un LLM generalista puede ayudar a distinguir, pero cuantos más candidatos, más se acumulan los costes de inferencia y la latencia. Para Push Protection, que debe dar un resultado antes de que se acepte el commit de código, esa espera afecta directamente la experiencia de desarrollo. GitHub conserva las expresiones regulares como entrada de candidatos y delega el juicio posterior a un ModernBERT ajustado. Lee la cadena candidata, el tipo de secreto, los nombres de variables, la ruta del archivo y el código cercano, y emite una puntuación de clasificación de riesgo; un umbral decide si se emite la alerta. El codificador devuelve la categoría tras un solo paso de cálculo hacia adelante, sin necesidad de generar explicaciones token a token como un LLM generativo, lo que lo hace adecuado para procesar por lotes peticiones del mismo tipo. La dificultad reside en los hard negatives: cadenas que se parecen mucho a secretos pero son ejemplos inofensivos. GitHub combinó los comentarios de producto y las anotaciones manuales, candidatos de alta exhaustividad de repositorios reales y muestras negativas difíciles sintetizadas específicamente, y dividió los conjuntos de entrenamiento y evaluación por repositorio, valor candidato y relaciones asociadas, para reducir el sesgo de evaluación que provocan los datos similares. De lo contrario, el modelo podría memorizar nombres de archivos, pero le costaría reconocer credenciales en proyectos desconocidos. En el despliegue, el modelo se exportó a ONNX con cuantización de 8 bits para reducir el consumo de recursos de inferencia. El umbral también debe calibrarse combinando Precision, Recall y el tráfico en línea: demasiado laxo genera falsos positivos, demasiado estricto puede dejar pasar secretos reales. Cuando aparecen nuevos formatos de secretos, hay que actualizar el conjunto de entrenamiento y las reglas. Frente a la antigua canalización de LLM, la nueva solución mejora la Precision offline un 13% y el Recall un 19%. Los experimentos A/B en línea muestran que el tiempo mediano de ejecución del escaneo Post-push cayó un 86%, el coste de servicio del modelo bajó más de un 98%, y la métrica de aceptación de alertas ponderada por propietario del repositorio mejoró un 11.5%. Aquí el 98% se refiere al coste del servicio del modelo, no al coste total de todo el sistema de seguridad. El clasificador solo puede juzgar los candidatos que la expresión regular encuentra, y la cobertura de las reglas previas sigue limitando los falsos negativos. Las reglas descubren pistas, el clasificador completa el juicio, y el análisis abierto puede seguir delegándose en un LLM generalista, evitando que cada juicio fijo asuma el coste de la inferencia generativa.04
El siguiente podría ser el CI
GitHub ha acortado los tiempos de retroalimentación del escaneo de seguridad, y el código aún debe pasar por construcción, pruebas y despliegue. Anthropic, tras resolver el problema del checkout del código fuente, se topó con una nueva dificultad: antes de que termine una ronda de pruebas, la rama principal puede haber incorporado cientos o incluso miles de modificaciones. Seguir dependiendo de un bloqueo global hace que los cambios se acumulen sin cesar, mientras que permitir la concurrencia introduce nuevos riesgos: incluso si una prueba ya ha pasado, el estado del código al que corresponde puede diferir de la versión lista para desplegar. Esto significa que lo que la CI debe abordar a continuación es cómo mantener la validez de los resultados de verificación en medio de cambios de alta frecuencia. La caché de construcción necesita identificar los cambios en el código fuente y en las dependencias, los registros de pruebas deben asociarse a commits concretos y artefactos de construcción, y el sistema además debe determinar qué resultados pueden reutilizarse y qué modificaciones invalidan las verificaciones previas. En un Monorepo con dependencias complejas, simplemente añadir máquinas de prueba dificilmente resuelve el problema de consistencia de versiones que generan las modificaciones concurrentes. Anthropic ya ha empezado a reforzar las pruebas posteriores a la fusión y las verificaciones previas al despliegue. Para los equipos corrientes, es más realista mejorar primero el análisis de dependencias, las pruebas incrementales y la caché de construcción que reconstruir directamente un sistema de control de versiones. A medida que los Agentes aumentan continuamente la producción de código, el cuello de botella de la ingeniería de software seguirá desplazándose hacia atrás a lo largo de la cadena de entrega. El código puede entrar en la rama principal cada vez más rápido, pero entre construcción, pruebas y despliegue deben conservarse relaciones de verificación fiables. En el futuro, cada vez más ejemplos podrán ilustrar queel avance vertiginoso de la IA escribiendo código acaba forzando que toda la cadena de ingeniería de software se vea obligada a "rehacerse por completo".El valor de la infraestructura de ingeniería también se reflejará cada vez más en su capacidad para que el código, sometido a cambios a alta velocidad, cuente de forma continuada con una base de entrega fiable.Enlaces de referencia:https://www.anthropic.com/engineering/redesigning-source-controlSúbete a bordo y descubre lo mejor de las principales cumbres mundiales de IA
Acceso exclusivo a:
las presentaciones PPT de los expertos
los textos completos de los informes de los congresos
las interpretaciones de los artículos más populares
las entrevistas a las nuevas estrellas académicas
Escanea el código QR de arriba
o haz clic en «Leer el artículo original» para seguir la sección.
Artículo original de Leiphone, prohibida su reproducción sin autorización. Para más detalles, consulte lasnormas de reproducción。