Cómo se gana un hackathon de Anthropic en solitario

Un solo desarrollador ganó el hackathon de Anthropic sin equipo. Después liberó la herramienta con la que lo hizo. Esta página explica, en cristiano, cómo trabaja — y cómo hemos adoptado ese método en la fábrica para que tú, también solo, envíes como un equipo.

La historia

affaan-m se presentó solo al hackathon de Anthropic y ganó. Lo interesante no es el premio: es cómo. No ganó programando más rápido que los equipos. Ganó porque no se presentó solo de verdad — se presentó con un equipo de agentes especialistas que él orquestaba. Luego empaquetó todo ese sistema y lo publicó como código abierto (licencia MIT) con el nombre ECC — Everything Claude Code: 64 agentes, 262 skills, un pipeline de construcción con compuertas y un sistema que aprende de cada sesión.

El repositorio es github.com/affaan-m/ECC. Lo analizamos a fondo, auditamos su seguridad e instalamos lo relevante para la fábrica. Esto es lo que aprendimos.

Cómo trabaja, en seis principios

Todo su sistema se reduce a seis reglas que se aplican siempre, se invoque o no una herramienta concreta:

1. Agent-First — delega, no lo hagas todo tú

En vez de un único hilo haciéndolo todo, cada tarea va a un subagente especialista: uno planifica, otro escribe tests, otro revisa, otro caza fallos de seguridad. Y se lanzan en paralelo cuando son independientes. Así es como una persona rinde como un equipo: no hace el trabajo de veinte, coordina a veinte.

2. Planificar antes de tocar código — con dos compuertas humanas

Nada complejo se escribe sin un plan aprobado primero. El humano aprueba el plan (compuerta 1) y aprueba el commit (compuerta 2). Entre medias, el flujo no para. Las dos compuertas existen porque planificar mal y commitear mal son los dos errores caros e irreversibles; el resto se puede deshacer.

3. Test primero (TDD) — 80% de cobertura

Se escribe un test que falla (RED), luego el código mínimo que lo hace pasar (GREEN), luego se refactoriza. No "lo pruebo de cabeza con tres entradas y mergeo". El objetivo es 80%+ de cobertura en la lógica de negocio.

4. Seguridad primero — nunca confíes en el input, nunca hardcodees secretos

Antes de cualquier commit que toque datos de usuario, autenticación o pagos, pasa un revisor de seguridad (OWASP, secretos, inyección). En la fábrica esto importa especialmente: cada landing captura leads — son datos de usuario, así que la seguridad no es opcional.

5. Archivos pequeños e inmutabilidad

Ficheros de 200-400 líneas (800 máximo), funciones de menos de 50 líneas, sin anidación profunda. Crear objetos nuevos en vez de mutar. Código que un humano (o un agente) puede leer de un vistazo sin perderse.

6. El sistema aprende de cada sesión

Su innovación más original: un loop de aprendizaje. El sistema observa lo que haces, extrae "instincts" — comportamientos atómicos con un nivel de confianza — y los va consolidando. Lo que aprende en un proyecto se puede promover a global cuando se repite. Es la diferencia entre una herramienta que usas y una que mejora contigo. (Más abajo: por qué nosotros lo tenemos apagado de momento.)

Cómo orquesta de verdad

El detalle que separa "usar agentes" de "ganar con agentes en solitario" está en la disciplina de orquestación. No es lanzar muchos a la vez — es coordinarlos como una cadena limpia:

• Una entrada, una salida. Cada agente recibe un encargo concreto y devuelve un resultado; ese resultado es la entrada del siguiente. Entre agente y agente se limpia el contexto y los resultados intermedios se guardan en ficheros, no en la memoria del modelo. Así ninguna fase arrastra el ruido de la anterior.
• Paralelización mínima viable. Se lanzan agentes en paralelo solo cuando hay necesidad real, con un techo de 3-4 tareas a la vez. Más terminales abiertas no es más productividad — es más caos que vigilar. El autor lo dice explícitamente: añadir un proceso debe nacer de una necesidad, no de un número arbitrario.
• Workflows que componen. La inversión que ganó el hackathon no fue un prompt perfecto, sino flujos reutilizables: tediosos de construir, pero que valen cada vez más a medida que mejoran los modelos. Eso es exactamente lo que estamos construyendo en la fábrica.
• "Funciona" no es "es fiable". Son dos preguntas distintas: ¿funciona alguna vez? (mejora con cada intento) no es ¿funciona siempre? (empeora con cada intento, porque basta un fallo). Para algo que envías a usuarios persigues lo segundo — y por eso los tests y la revisión de código no son opcionales, son lo que convierte "me salió una vez" en "lo puedo enviar".

El equipo de agentes

Instalamos 22 de sus agentes (los relevantes para construir y validar MVPs). Cada uno es un especialista con un rol claro. En lenguaje llano:

Agente	Su trabajo
planner · architect	Planifican antes de tocar nada; parten la feature en trozos pequeños y entregables.
code-explorer	Entiende un código ajeno o grande antes de modificarlo.
tdd-guide	Escribe el test primero y guía el ciclo rojo→verde→refactor.
code-reviewer	Revisa siempre, justo después de escribir código. Solo reporta lo que está >80% seguro de que es un problema real.
security-reviewer	Caza vulnerabilidades, secretos e inyecciones. Obligatorio si se tocan datos de usuario.
silent-failure-hunter	Encuentra errores que el código se traga en silencio — los peores de depurar.
refactor-cleaner · code-simplifier	Quitan código muerto y simplifican sin cambiar el comportamiento.
e2e-runner	Prueba flujos críticos en un navegador real (Playwright).
marketing-agent	Escribe el copy de la landing desde el cliente ideal; bloquea el ángulo antes de escribir una palabra.
seo-specialist	SEO técnico y orgánico — clave, porque el cuello de botella real es el tráfico.
chief-of-staff	Orquesta el trabajo en varios frentes y prioriza.
loop-operator · harness-optimizer	Operan loops autónomos con seguridad y afinan el propio arnés por fiabilidad y coste.

(Más python-reviewer, typescript-reviewer, database-reviewer, doc-updater y otros especialistas por stack.)

El pipeline con dos compuertas

La construcción de cualquier cosa sigue este flujo. La ceremonia escala al riesgo: un cambio de una línea se salta fases; algo que toca seguridad o un contrato público pasa el flujo completo.

El "tamaño" de la tarea decide cuántas fases corren — desde trivial (3 fases) hasta large (todas). Regla dura: cualquier cosa que toque seguridad o un contrato público es como mínimo tamaño medio, da igual cuántos ficheros sean. Una landing que captura leads siempre cae aquí.

El loop de aprendizaje — y por qué lo tenemos apagado

La pieza más original de ECC convierte cada sesión en "instincts" capturados automáticamente por hooks. Suena ideal, pero tiene un coste: para funcionar lanza un proceso en segundo plano que llama a la API de Anthropic (un modelo Haiku analizando lo que haces) de forma recurrente.

Cómo lo hemos adoptado en la fábrica

ECC no sustituye a lo que ya teníamos: se apila. Dos capas que encajan:

• gstack (de Garry Tan, CEO de Y Combinator) — el framing de producto y el envío: enmarcar la idea como un CEO, diseñar, probar en navegador real, enviar el PR.
• ECC (de affaan-m) — el equipo de ingeniería: el roster de agentes, el pipeline con compuertas y la disciplina de TDD y seguridad.

El flujo unificado por defecto, paso a paso:

1. Enmarcar — gstack, como un CEO de YC: ¿esto resuelve un dolor real?
2. Planificar — el agente planner. 🚦 Aprobar plan.
3. Construir — tdd-guide escribe el test primero; marketing-agent el copy.
4. Revisar — code-reviewer + security-reviewer + prueba en navegador real.
5. Enviar — gstack empaqueta y despliega. 🚦 Confirmar.
6. Crecer — seo-specialist y tráfico (esto te toca a ti; los agentes optimizan, no traen visitantes de pago solos).

Qué cambia para ti

Nada de esto te pide programar. Te da un equipo. Cuando una idea pasa el gate y toca construir, ya no empiezas de cero: hay 22 especialistas y un método probado esperando. Tu trabajo sigue siendo el de siempre — el que no se delega: elegir bien las ideas, meter tráfico cualificado y decidir qué vive y qué muere. El último 10% de completitud que los equipos se saltan (tests, seguridad, el envío limpio) ahora se hace siempre, porque cuesta minutos en vez de días.

Esa es la lección entera de ganar un hackathon en solitario: solo no significa sin equipo. Significa que el equipo cabe en tu terminal.