Everything Claude Code: De Hackathon a 197K Estrellas — Qué Cambió y Por Qué Importa

El 19 de mayo cubrimos Everything Claude Code cuando era una herramienta de seguridad interesante con un scanner que auditaba tu configuración de agente. Hoy el repo tiene 197K estrellas, 27.5K forks, y es el #1 en GitHub Trending. Algo pasó. Y no fue solo marketing.

Quiero explicar qué cambió — porque la distancia entre el ECC que cubrimos antes y el ECC de hoy no es incremental. Es una reescritura de ambición.


El origen: un hackathon de Anthropic en septiembre 2025

Affaan Mustafa ganó un hackathon de Anthropic con una idea simple pero bien ejecutada: los agentes de IA son inconsistentes no porque los modelos sean malos, sino porque no tienen estructura. Sin reglas, un agente saltea tests, modifica configs de linter para silenciar errores en lugar de corregirlos, hace commits con --no-verify, y pierde contexto entre sesiones. El problema no es el modelo. Es la ingeniería alrededor del modelo.

ECC nació como la respuesta a ese problema. Un conjunto de skills, hooks, reglas y agentes especializados que le dan estructura repetible a cualquier harness de IA.


De 40K a 178K estrellas: qué explica el salto

El crecimiento no fue lineal. Hubo dos aceleradores concretos:

Primero, la expansión multi-harness. ECC dejó de ser “el plugin de Claude Code” para convertirse en un estándar agnóstico. Hoy el mismo repo despliega configuraciones para Claude Code, Cursor, Codex, OpenCode, Gemini, Zed, y GitHub Copilot. Un solo AGENTS.md en la raíz del repo es leído por todas las herramientas. Eso resolvió el problema que tenía cualquier equipo que usa más de un harness — que es la mayoría de los equipos en 2026.

Segundo, la madurez de la comunidad. 113 contributors, traducciones en 7 idiomas, y 768 commits acumulados convirtieron ECC en algo que ningún dev quiere mantener solo. El .editorconfig del desarrollo con IA, como lo describe la comunidad.


V1.9.0: lo que realmente cambió

La versión 1.9.0, lanzada en marzo 2026 con 212 commits, tiene tres cambios que me parecen estructuralmente relevantes para equipos:

1. Selective install architecture

Antes, instalar ECC era todo o nada. Ahora hay un pipeline basado en manifiestos — install-plan.js + install-apply.js — con un store SQLite que trackea qué está instalado y soporta actualizaciones incrementales. Un equipo Python no hereda overhead de TypeScript. Un shop de Go instala exactamente las reglas de Go, los agents de Go, y nada más.

Para equipos con múltiples repos en lenguajes distintos, esto cambia el cálculo de adopción. Ya no es “instalamos ECC en el repo principal y vemos”; es “instalamos lo que necesitamos donde lo necesitamos.”

2. 28 agentes especializados

El salto de agentes genéricos a 28 subagentes especializados es el cambio más subestimado de la versión. Hay agentes dedicados para planificación, TDD enforcement, security review, resolución de errores de build, y code review específico por lenguaje — TypeScript, Python, Go, Rust, Java, Kotlin, C++. No son prompts con un rol distinto. Son agentes con lógica propia, reglas propias, y hooks propios.

El que más me interesa como practitioner: el agente TDD que bloquea cualquier flujo que no escriba tests antes del código. No es un recordatorio. Es una restricción estructural.

3. Soporte para 12 ecosistemas de lenguaje

V1.9.0 agregó cobertura completa para 12 ecosistemas. Lo relevante no es el número — es que cada ecosistema tiene sus propias reglas de estilo, hooks de formateo automático, y skills adaptadas. El hook post:edit:format corre Black en Python, Prettier en TypeScript, gofmt en Go. Sin configuración manual. Sin “acordarse de correr el formatter.”


Lo que no cambió: la filosofía

Lo que me convence de ECC como apuesta de largo plazo es que la filosofía central no cedió bajo la presión del crecimiento. El proyecto sigue tratando la inconsistencia de los agentes como un problema de ingeniería, no de prompting. Los hooks de seguridad siguen bloqueando --no-verify, detectando secrets en prompts (sk-, ghp_, AKIA), y protegiendo archivos de configuración de ser modificados por el agente para silenciar errores.

197K estrellas no los hizo agregar features de marketing. Agregaron features de infraestructura.


Mi lectura: esto es el nuevo .editorconfig

Hay un patrón que se repite en herramientas que se convierten en estándar: empiezan resolviendo un problema específico bien, la comunidad los adopta, y la adopción los convierte en la interfaz de facto que todos asumen presente. Prettier lo hizo para formateo. ESLint lo hizo para linting. ECC está haciendo lo mismo para la capa de comportamiento de agentes.

La pregunta para equipos en 2026 no es si adoptar ECC. Es cuándo y con qué scope. El selective install de v1.9.0 eliminó la última excusa para no empezar.


Recursos


¿Tu equipo ya adoptó ECC o alguna capa de estructura similar para sus agentes? ¿Qué frenó o aceleró esa decisión?