Awesome desactualizadas: cómo construí un sistema de curación auto-regulado

Abrí GitHub, buscá awesome-python en las tendencias. Vas a ver un repo con 240k stars, 39 mil forks, un PR list que supera los 2.000 abiertos. Parece la biblia de Python moderno.

Ahora mirá cuándo fue el último merge. Algunos días. Bien. Ahora hacé lo mismo con awesome-react, con awesome-nodejs, con awesome-flutter. Mitad están congeladas. Último commit hace 8 meses. PRs olvidados en los 300. Entries apuntando a dominios vencidos. Tools que dejaron de mantenerse en 2022.

Eso es lo más común: una lista awesome-* que alguna vez fue oro, y ahora es un museo.

El problema

Las listas awesome son la puerta de entrada para devs que quieren descubrir herramientas en un ecosistema. Están en el primer resultado de Google, tienen decenas de miles de stars, se linkean en tutorials, en threads, en bookmarks.

El problema es que no escalan con el tiempo. El curador original eventualmente pierde las ganas o el trabajo se la come. Los PRs de contribuciones se acumulan más rápido de lo que se mergean. Y cuando el maintainer desaparece, la lista no se "rompe" — simplemente va envejeciendo mientras el mundo cambia alrededor.

Un dev que entra a awesome-X en 2026 puede terminar instalando una herramienta deprecated desde hace dos años. Y nadie se lo avisa.

La idea

Hace unos días un amigo me dijo:

"Quiero hacer un post sobre cada repo awesome que leo."

Le respondí algo así como:

"Pero primero tenemos que filtrar cuáles valen la pena. Y tenemos que hacer un sistema que lo haga automáticamente, porque si cada mes hay que decidir a mano cuáles están vivas y cuáles no, esto no escala."

Así arrancó este proyecto.

La idea simple: construir un sistema auto-regulado que mantenga un "roster" dinámico de las 15 awesome lists más activas y de mejor calidad del ecosistema, más un "bench" de 5 candidatas de ascenso. Re-evaluar semanalmente. Scrappear solo las que estén vivas. Deduplicar items cross-fuente (si tres listas mencionan la misma herramienta, es señal). Clasificar con IA para pre-ordenar. Y al final, publicar una lista propia que se auto-actualice.

O sea: no crear otra awesome a mano. Crear un sistema que curate las awesomes.

Arquitectura en tres fases

  ┌─────────────────────────────────┐
  │   FASE 1 — Discovery            │
  │   GitHub search + seeds         │
  │   → scoring 0-100 (5 dims)      │
  │   → ROSTER 15 · BENCH 5         │
  └──────────────┬──────────────────┘
                 │
  ┌──────────────▼──────────────────┐
  │   FASE 2 — Scrape + Dedupe      │
  │   README parsing                │
  │   → items normalizados          │
  │   → CuratedTool únicos          │
  │   → appearsInCount = señal      │
  └──────────────┬──────────────────┘
                 │
  ┌──────────────▼──────────────────┐
  │   FASE 3 — Curate               │
  │   Claude clasifica GEM/HYPE/…   │
  │   Humano confirma o overridea   │
  │   → README auto-generado        │
  └─────────────────────────────────┘

Cada fase es un problema distinto. Discovery es un problema de búsqueda + ranking. Scrape es parsing + deduplicación. Curation es prompt engineering + cost control.

Los próximos tres posts son cada uno un deep dive técnico:

• Parte 2: GraphQL batched + SQL raw: de 5 minutos a 25 segundos procesando 28.000 items. El viaje de optimización, los cuellos de botella reales (connection_limit), y cómo Prisma a veces traiciona.
• Parte 3: Clasificar 5.000 herramientas con Claude por 1 dólar. Haiku batched, prompt design, el trade-off calidad/costo, y cómo construir un prompt que el modelo no arruine.
• Parte 4: El lanzamiento. El repo público awesome-curated, la automatización semanal, y la métrica de si alguien lo está usando.

El scoring

Antes de seguir, vale la pena mostrar el corazón del sistema — la fórmula que decide si un awesome está vivo o muerto.

score = freshness * 0.35
      + activity * 0.20
      + popularity * 0.15
      + depth * 0.20
      + community_health * 0.10

Cinco dimensiones, 0 a 100 cada una.

• Freshness — cuándo fue el último commit. Curva empinada: menos de 3 días es 100, más de 180 es 0.
• Activity — PRs merged en los últimos 30 días. Una lista viva tiene contribuciones activas aunque el maintainer no esté escribiendo.
• Popularity — stars. Pero no log puro: en el rango 250-2500 stars la curva es lineal para no aplastar nichos legítimos (cryptography, rust-embedded, etc.).
• Depth — cantidad de items en el README + categorías organizadas. Un awesome con 30 items mal agrupados vale menos que uno con 300 bien estructurados.
• Community health — ratio openIssues / stars. Si es >10% es proyecto descuidado. Si es ~1% es proyecto que responde.

La primera corrida tiró datos interesantes: vinta/awesome-python con 240k stars cayó al BENCH porque el ratio de issues sin atender era alto y los PRs merged por mes eran pocos. En cambio awesome-mcp-servers con apenas 12k stars entró al ROSTER con score 99 porque está siendo mantenida activamente mientras el mundo MCP está explotando.

Eso es exactamente lo que un dev necesita: no la lista más grande, sino la que va a tener el tool que salió ayer.

Lo que viene

En el próximo post entro al código: cómo pasé del primer prototipo con REST clásico (4 requests por repo) al pipeline con GraphQL batched + SQL raw que procesa 20 repos y 28.000 items en 25 segundos. Con los bugs reales del camino.

Mientras tanto, podés seguir la evolución en vivo:

• El repo con la lista curada: github.com/JuanTorchia/awesome-curated (public launch en unas semanas)
• Este blog: cada 3 días un post nuevo de la serie
• Discusión: @Juanchi_AR en Twitter si querés opinar sobre el scoring o proponer una awesome-* que debería entrar al roster

Si todo sale bien, en seis meses nadie tendría que abrir awesome-X y descubrir que está muerta. La lista vive sola.

Eso es el plan.