El código de GitHub como memoria de agentes: Code2Skill y su millón de skills verificadas por reconstrucción ciega

TL;DR

Code2Skill (Ant International, arXiv 2609.05571) convierte código real de GitHub en skills consultables: 19.769 repos de más de 500 estrellas, cutoff 14 de abril de 2026, 1.006.822 skills aceptadas.
La verificación es lo interesante: un LLM reconstruye la implementación usando solo la skill, sin ver el código fuente, y un juez con acceso al original comprueba si la reconstrucción cuadra. No es una prueba formal de equivalencia; es un control de consistencia a escala.
Resultados: el promedio macro sube de 42,90 a 47,90 (+11,7% relativo) en 9 configuraciones de modelo × 8 benchmarks; mejora en 57 de 72 pares. Perfecto en SWE-bench Verified (9/9) y AIME (9/9), flojo en AgentBench-OS (5/9) y en modo reasoning sobre BigCodeBench.
Un summary de ~707 caracteres rinde igual o mejor que el record completo de ~6.352 (−88,9% de contexto). Y la revisión post-generación es el punto de inyección más estable.
Mi lectura: esto no mata los SKILL.md escritos a mano; añade una tercera opción de memoria que no contemplábamos cuando escribimos sobre el cuello de botella de memoria en agentes. Con caveats serios: licencia del dataset pendiente de auditoría, repo sin open source y pilot de RL no concluyente.

Contexto: la tercera opción que faltaba

En agosto escribíamos en la memoria de agentes como nuevo cuello de botella que el patrón dominante —comprimir el pasado en un summary y meterlo en el prompt— falla de formas predecibles, y que la alternativa sana era tratar la memoria como una base de datos que se consulta: tu historial de sesiones, decisiones y errores, consultable por intención.

Code2Skill introduce una tercera opción que ese artículo no contemplaba: no tu pasado, sino el de 19.769 repositorios ajenos. Código que otros escribieron, depuraron y refinaron durante años, minado en skills procedimentales, verificado y puesto a disposición de cualquier agente vía retrieval. La memoria como infraestructura pre-acumulada, no como diario personal.

El trabajo viene de Ant International AI Research y tiene tres capas con nombres parecidos que conviene no confundir: Code2Skill es el pipeline, CodeSkillBank es el dataset resultante (publicado en Hugging Face) y DeveloperSkillHubs es la web exploratoria. El pipeline está descrito en el paper; el repo de GitHub existe pero es pre-release, no open source todavía.

Si en abril mapeábamos la infraestructura de agentes de 2026 —runtime en el edge, protocolos, persistencia— este banco encaja en la capa que seguía abierta: el conocimiento procedimental que un agente necesita antes de ejecutar su primera línea.

Qué es CodeSkillBank y de dónde sale

El pipeline escanea repositorios de GitHub disponibles a 14 de abril de 2026 y retiene los que superan las 500 estrellas: 19.769 repos. No es un pool de proyectos abandonados: el 46,9% tiene al menos 100 pull requests mergeados y el 66% recibió push en el año anterior. Dentro de cada repo parsea funciones, métodos, puntos de entrada de CLI y componentes a nivel de fichero, rechaza lo trivial (getters, wrappers, configuración), y de cada unidad elegida deriva una skill de uno de tres tipos:

Operación atómica: un procedimiento concreto y acotado.
Workflow compuesto: una secuencia ordenada con condiciones e invariantes.
Patrón recurrente: una convención que aparece una y otra vez.

Cada skill captura el workflow, inputs, outputs, invariantes, casos de fallo y anti-goals (comportamientos tentadores pero incorrectos), y conserva provenance completa: repo, archivo, símbolo, span de líneas y rationale de la decisión.

El tamaño final: 1.006.822 skills aceptadas a nivel de fuente, organizadas en 750.748 cards a nivel de propósito con 945.993 aristas, más 3.600 patrones recurrentes confirmados. El perfil semántico del banco desmiente la sospecha de que esto va a ser un índice de llamadas a API: los procedimientos multi-paso son el 57,3% y el razonamiento de restricciones el 33,5%, frente a un 8,6% de llamadas API superficiales. El 79,6% de las skills se etiqueta como correctness-critical, es decir, que hacerlas mal tiene consecuencias.

La verificación por reconstrucción ciega, explicada

Aquí está el corazón del asunto. El problema con minar conocimiento de código es que cualquier LLM puede inventar una skill plausible que no refleje lo que el código hace realmente. Code2Skill lo ataca así:

Extracción: se genera la skill a partir de la unidad de código seleccionada.
Reconstrucción ciega (source-body-blind): un LLM recibe la skill y la interfaz pública del código —sin el cuerpo de la implementación, sin el nombre del repo, sin la ruta del fichero— y reconstruye la implementación desde cero.
Juicio source-aware: un juez con acceso al código original compara la reconstrucción con el original. Consistente: aceptada. Dudosa: a un adjudicador. Si no cuadra: rechazo.

La lógica es elegante: si la skill omitió un paso, una condición o un caso de fallo, la reconstrucción ciega tropieza en ese punto, y el juez lo ve. La skill tiene que contener suficiente detalle procedimental para que un tercero reproduzca el comportamiento. Es el mismo principio que usarías para validar documentación: si solo hay una forma de saber si unas instrucciones sirven, es darlas a alguien que no haya visto el código y comprobar si llega al mismo resultado.

El ejemplo que la web del proyecto usa lo deja claro. La skill recoverDoQAfterCachedQUICFailure (AdGuard, DNS-over-QUIC) no enseña “reintenta ante error”, que es lo que generaría cualquier LLM sin contexto. La lección transferible es una política acotada: reintentar solo la conexión cacheada que falló, cerrarla antes de readquirir, y limpiar el estado de tokens únicamente ante un rechazo 0-RTT. Ese nivel de precisión es lo que la reconstrucción ciega obliga a conservar.

Ahora, el matiz que el propio repo declara sin rodeos: “The judge is an LLM consistency check, not a proof of program equivalence.” No hay ejecución de tests ni verificación formal en el bucle de aceptación. Es un filtro de consistencia estadístico, no una garantía. La card del dataset lo repite: las skills son abstracciones textuales que pueden contener omisiones, imprecisiones generadas por modelo o condiciones de aplicabilidad demasiado amplias, y recomiendan validarlas antes de usarlas en entornos sensibles o de producción.

Qué rinde y qué no

El paper evalúa 9 configuraciones de modelo (DS4-Flash, Qwen3.5-27B, Qwen3.6-27B, Gemini 2.5 Pro y GPT 5.2, en modo estándar y reasoning donde aplica) sobre 8 benchmarks, con skills recuperadas por tarea y protocolo idéntico salvo el acceso a skills. Ojo a dos condiciones del experimento: por eficiencia computacional, el pool de retrieval usa por defecto solo el 10% del banco, y las skills se inyectan en revisión post-generación.

Resultado agregado: el promedio macro sube de 42,90 a 47,90 (+11,7% relativo), con mejora en 57 de los 72 pares. SWE-bench Verified y AIME mejoran en los 9 pares. El detalle por benchmark es menos uniforme, y ahí está el valor:

Benchmark	Mejora en (de 9 pares)	Lectura
SWE-bench Verified	9/9	Gana siempre
AIME 2026	9/9	Gana siempre
HMMT 2025	8/9	Casi siempre
GPQA	8/9	Casi siempre
TerminalBench	8/9	Casi siempre
BigCodeBench	6/9	Pierde 3 pares en modo reasoning
AgentBench-OS	5/9	3 derrotas netas
LongCLI	4/9	4 victorias, 5 empates, 0 derrotas

(Conteos recalculados por nosotros a partir de la Tabla 1 del paper; coinciden con lo que el abstract resume como 57/72.)

Dos patrones en los límites. Primero, BigCodeBench en modo reasoning: los autores lo atribuyen a que las skills aportan poco en problemas cortos que modelos capaces ya resuelven directamente. El patrón es creíble: GPT 5.2 en reasoning pierde 6,9 puntos allí mientras gana en todo lo demás. Segundo, AgentBench-OS: 3 derrotas netas, la peor señal del conjunto; el control de sistemas operativos no se beneficia de skills derivadas sobre todo de repos de software.

Contra las skills derivadas de trayectorias de agentes —la otra familia de enfoques— la comparación es contundente: en 7 benchmarks compartidos, Code2Skill promedia 49,5 frente a 31,0 de Trace2Skill, 27,9 de ExpeL y 32,8 de SkillRL-Bank (la adaptación de SkillBank). Incluso un oráculo que elige el mejor baseline por benchmark se queda en 40,1: 9,5 puntos por debajo. El margen sobre el mejor baseline por benchmark va de 6,6 a 13,3 puntos. Mi lectura con la cautela de siempre: esto dice que el material del que se derivan las skills importa, no que las skills de trayectoria sean una mala idea en tu caso de uso.

707 caracteres bastan: el hallazgo de interfaz

La sección que más conecta con lo que escribimos sobre memoria es la de diseño de retrieval, hecha sobre BigCodeBench Instruct-Hard con DS4-Flash y Qwen3.5:

Summaries vs records completos: renderizar solo el summary reduce el contexto medio por skill de 6.352 a 707 caracteres (−88,9%) con k=3. Qwen3.5 mantiene su score completo; DS4-Flash mejora de 28,40 a 31,80. Nada de lo que el record completo añade al prompt compensa su coste.
Profundidad de retrieval: subir k de 1 a 10 expande el contexto de 2,1K a 17,8K caracteres con ganancias marginales. Más skills no es mejor memoria; es más ruido.
Placement: la revisión post-generación (darle las skills al agente para que revise su propio borrador) es el patrón más estable. La planificación mejora en los 8 benchmarks compartidos; el uso en primera pasada de generación es mixto según modelo.

Si esto te suena: sí, es exactamente el patrón prompt-summary que criticábamos en agosto. La diferencia está en qué contiene el summary y cómo se usa. El summary que criticábamos era un snapshot de estado (qué hicimos, qué decidimos) que caduca en cuanto la realidad cambia. Este es una descripción de procedimiento (cómo se hace X, bajo qué condiciones, con qué casos de fallo) que no caduca, se consulta por intención solo cuando la tarea lo pide, y tiene detrás un record completo con provenance para auditarlo. El summary no reemplaza al record: es su vista compacta.

Skills como dato de entrenamiento, no solo contexto

El paper explora también usar el banco como material de RL en un entorno de coding (SWE-World, recompensas simuladas de test-pass). En el checkpoint evaluado (step 150), todas las interfaces con skills superan al control sin skills (24%): política con records completos 32%, política con summaries 31%, skills como referencia del verificador 31%, y revisión post-generación 38%.

Catorce puntos sobre el control suena a titular, y por eso hay que decir lo que es: un único checkpoint, sin seeds múltiples ni curvas de entrenamiento alineadas. Es señal temprana de que el banco puede servir como material de entrenamiento y no solo como contexto runtime, no una conclusión. Los propios autores lo presentan con esa cautela.

El dato que más discusión va a generar: las skills derivadas de código generado por IA pasan la verificación al 93,50%, frente al 93,00% del código escrito por humanos. Los autores lo califican de “initial evidence” de que el banco puede seguir creciendo a medida que el código sintético se vuelve dominante. La lectura escéptica: que el pass rate no distinga entre origen significa también que el test está saturado —93% es el techo del filtro, no una medida de calidad diferencial— y que un banco autoalimentado con código de LLM verificado por LLM merece el escepticismo que su nombre sugiere.

Qué significa para el patrón SKILL.md

Nada de “el fin de los SKILL.md escritos a mano”, que es el titular fácil. Lo que sugieren los datos es una división de trabajo:

Lo minado cubre procedimientos genéricos y públicos: recuperación de conexiones, validaciones, transformaciones, patrones de manejo de errores. El 79,6% correctness-critical del banco es exactamente el tipo de conocimiento que no quieres re-derivar por ensayo y error en cada agente.
Lo escrito a mano cubre lo que no está en ningún repo público: las convenciones de tu equipo, las decisiones de diseño de tu producto, las peculiaridades de tu despliegue. Ningún banco minado de GitHub sabe cómo despliegas tú a producción.

La combinación práctica para quien construye agentes: un banco consultable de procedimientos genéricos + skills locales del proyecto escritas a mano, ambas servidas con la interfaz que los datos apoyan — summaries compactos (~700 caracteres) consultados por intención, inyectados preferiblemente en revisión post-generación. En nuestro caso real de multi-agente con OpenClaw las skills compartidas eran módulos de capacidad asignados por rol; un banco minado extiende esa idea del tool-calling al conocimiento procedimental, y con la misma regla de asignación: cada agente consulta solo lo que su tarea necesita. Y para quien mantiene skills escritas: revisar qué parte de tus SKILL.md es procedimiento genérico que un banco así ya cubriría, porque eso es contexto que estarás re-escribiendo sin necesidad.

Qué haría yo

Si construyes agentes hoy: el hallazgo accionable no es el banco (todavía), es la interfaz. Retrieval por intención con summaries compactos e inyección en revisión post-generación es un patrón barato de probar con cualquier fuente de conocimiento procedimental que ya tengas.
Si CodeSkillBank te parece útil: trátalo como señal de investigación, no como componente de producción. Licencia pendiente de auditoría de provenance (la card declara apache-2.0 en el frontmatter pero mantiene license: other hasta que la auditoría de URLs, commits y licencias por repo esté completa), repo del pipeline sin publicar, y el propio paper pide validar las skills antes de uso sensible.
Si llevas un sistema con memoria propia: la verificación por reconstrucción ciega es una idea que puedes robar sin el resto. Cuando escribas o actualices una skill, pídele a un modelo que reconstruya la implementación solo con la skill; donde tropiece, tu skill tiene un hueco.
No reapplies los números a ciegas: los experimentos usan el 10% del pool de retrieval, placement post-generación, y 8 benchmarks que no son tu carga de trabajo. AgentBench-OS muestra que hay dominios donde esto todavía no funciona.

Metodología

Análisis basado en el paper “Grounded Skill Synthesis from Code at Scale for Agentic Intelligence” (arXiv 2609.05571, v1 del 4 de septiembre de 2026), la web del proyecto DeveloperSkillHubs, la card del dataset en Hugging Face (ant-intl/DeveloperSkills-Code2Skill) y el repo de GitHub ant-intl/Code2Skill, todos verificados el 22 de septiembre de 2026. Los conteos por benchmark (9/9, 6/9, 5/9, 4/9) los hemos recalculado desde la Tabla 1 del paper y coinciden con el agregado de 57/72 del abstract. No hemos ejecutado el pipeline ni evaluado el banco por nuestra cuenta: todas las cifras de rendimiento provienen de los autores, y el repo no es open source, así que no hay réplica independiente todavía.

Fuentes

Grounded Skill Synthesis from Code at Scale for Agentic Intelligence — arXiv 2609.05571, Ant International AI Research
DeveloperSkillHubs — web del proyecto
CodeSkillBank — dataset en Hugging Face
Code2Skill — repo en GitHub (pre-release)
La memoria de agentes es el nuevo cuello de botella — GPT Diffusion, agosto 2026
Infraestructura de agentes 2026 — GPT Diffusion
Multi-agent systems: OpenClaw y el ecosistema — GPT Diffusion