De dónde sale mi harness

En el reel le explicaba a Simón qué es un harness: todo lo que rodea al modelo para que trabaje a mi manera. Quién hace cada cosa, con qué método y cómo se controla. Lo que no cabía en 68 segundos es que esto no salió de un día para otro, así que va aquí.

Antes de que hubiera skills

Llevo intentando usar la IA en modo agente desde que empezó todo esto, cuando todavía no había tools ni skills y conseguir que un modelo encadenara varias cosas sin perderse era muy difícil. Aun así quería mi propio sistema, algo con cierta autonomía que no necesitara que yo estuviera encima.

El primero que me funcionó era sencillo. Un agente se encargaba de la tarea principal y delegaba otras más pequeñas en agentes con encargos cortos y modelos más baratos. Lo de los modelos baratos no era por elegancia: empecé con la suscripción de 20 dólares de OpenAI y luego con la de Claude Code, y con esas cuentas el límite de uso llegaba enseguida. Repartir lo pequeño entre modelos menores era la forma de estirarlo.

De quién aprendí

Casi todo lo aprendí de desarrolladores que lo enseñan en abierto. El principal, del que aprendí la base de todo, fue midudev. Después vinieron Brais Moure, HolaMundo y muchos más.

Por el camino probé de todo: colecciones como Awesome Claude Skills y un largo etcétera que ya ni recuerdo sin abrir mi propio harness.

Cómo trabaja un equipo de verdad

El enfoque cambió cuando vi cómo trabajan de verdad los equipos de desarrollo en una empresa grande. Nadie toca código sin que esté escrito qué hay que hacer, lo que hace uno lo revisa otro que no lo ha escrito, y las decisiones importantes se toman en puntos concretos, no en cada línea. Eso es lo que quería de mis agentes, me tocara el proyecto que me tocara: uno personal, uno del trabajo o uno de investigación.

Y en paralelo la comunidad se abrió muchísimo. Empezó a haber gente compartiendo sus sistemas para que los agentes no se líen, con métodos y repos enteros. Mi harness de ahora junta dos de esas cosas.

El método: Brais Moure

Brais Moure (MoureDev) tiene un curso de spec-driven development desde cero, en directo en YouTube y con su repo, hello-sdd. El flujo es: constitución del proyecto, spec, clarificación, plan, tareas, implementación y validación. Los requisitos se escriben en EARS, una forma de redactarlos para que no admitan dos lecturas, y el AGENTS.md del proyecto es, en sus palabras, «la Biblia, pero pequeñita».

De ahí me quedé con casi todo: la spec antes que el código, tareas de 20 o 30 minutos y validar requisito por requisito. También es suyo el aviso de que «la IA nos puede estar mintiendo».

Lo que no me convencía es que para después de cada tarea, porque su única garantía es que el humano mire. Funciona, pero trata a los agentes como a niños pequeños. Yo quería su orden sin tener que estar encima a cada paso.

Los agentes: Everything Claude Code

Everything Claude Code (ECC), de Affaan Mustafa, es uno de los repos más grandes que hay para Claude Code: 68 agentes, 292 skills y 94 comandos cuando lo estudié. Su autor ganó el hackathon de Anthropic con Forum Ventures.

De ECC cogí los controles que hacen el trabajo que en el método de Brais hacía mi mirada:

• El test se escribe primero y tiene que fallar antes de escribir el código. Y nunca se inventa un PASS.
• Cada cambio lo revisa un code-reviewer con el contexto limpio, que no ha visto cómo se escribió.
• Si el cambio toca datos o accesos, pasa también por un security-reviewer.
• Antes de construir algo, se busca si ya existe: adoptar, extender o construir, en ese orden.

Cuatro de sus agentes entraron casi tal cual. Los controles, sobre todo los de los tests, los fui editando según me venía bien. Y otras cosas las dejé fuera. ECC activa agentes por su cuenta («use proactively») y yo no quiero agentes que se activen por costumbre. Tampoco me quedé con la cobertura fija del 80 % ni con la regresión visual por capturas. Y su script de verificación de ejemplo encadena un tail sin pipefail, así que da verde aunque falle algo. En el mío va con pipefail.

1#!/usr/bin/env bash2# Verificador único del proyecto: lo usan los agentes, Alberto y CI.3set -uo pipefail45STEPS=(6  "lint::npx eslint ."7  "tipos::npx next typegen && npx tsc --noEmit"8  "build::npx next build"9)

Cómo quedó

El método de Brais decide qué se construye y cuándo decido yo. Los agentes y controles de ECC hacen el trabajo entre una decisión y otra.

Hay tres puertas que apruebo yo: la spec, el plan con sus tareas, y la aceptación del resultado. Entre puerta y puerta trabajan los agentes con sus controles, cada uno en su parcela para que no se pisen, y con encargos de 30 minutos como mucho, con un informe de tres líneas al terminar: qué funciona, qué está simulado y qué falta.

Lo uso a diario en OpenCode, donde cambio de modelo con un clic. La build de Claude Code sale del mismo núcleo. OpenCode no ejecuta los hooks de Claude Code, así que ahí los controles van como instrucciones y no como bloqueo.

Las pruebas

Esta versión la monté en septiembre, y la primera vez se la encargué a un agente que la escribió a partir de un resumen de segunda mano: no era el método de Brais. Yo había visto el curso y se notaba: los criterios de aceptación iban separados de los requisitos, no había una skill por fase y el arranque no salía del AGENTS.md. Tuve que corregirlo tres veces, hasta que se leyó la transcripción entera del curso y el repo de ECC fichero a fichero.

La primera prueba en serio fue mi app de entreno, GymTracker, con cinco bugs abiertos en un issue. Los arregló todos, con los tipos, el lint y los 10 tests en verde. Pero tardó lo suyo: el proyecto no tenía AGENTS.md, así que cada sesión arrancaba en modo guiado y me lo preguntaba todo: media hora de preguntas que ya tenía respondidas.

$ scripts/verify.sh✓ tipos✓ lint✓ tests 10/10verify.sh devuelve 0Los cinco bugs del issue #3, corregidos.

La segunda salió peor y me enseñó más: un RAG con citas, llevado de principio a fin por el harness en modo autónomo. Dos días, 27 commits, 11.466 líneas y 7 specs. Resultado: un motor de búsqueda simulado sin valor práctico, que funcionaba como un Ctrl+F con citas. De cinco preguntas de prueba, acertó dos.

Las causas estaban en el propio sistema:

• La constitución fijó el stack el primer día, antes de saber qué hacía falta.
• Se empezó a implementar sin la spec aprobada.
• Fue autónomo desde el minuto uno.
• Los tests eran la puerta, pero no había datos reales. Así que el agente construyó motores falsos que pasaban los tests.
• Un subagente estuvo hora y media sin producir un solo fichero.

El propio agente lo resumió mejor que yo: «Dije "funciona de punta a punta" sin avisar de que el motor no servía».

De ahí salió la siguiente versión. Antes de construir hay una fase de descubrimiento, donde se mira qué existe y se decide si adoptar o construir. Las aprobaciones quedan escritas en el propio fichero de la spec. El modo guiado es obligatorio en la primera tanda de un proyecto. Y los revisores de seguridad entran desde el segundo ciclo.

Dónde no lo uso

En esta web. La empecé con el harness y me pedía previews y aprobaciones para decisiones pequeñas que ya le había dado por escrito. Lo quité ese mismo día. Desde entonces el harness tampoco pide aprobaciones para cosas de ese tamaño.

La info, Simón

El harness completo es privado, porque lleva datos míos. Lo que sí es público es la base: sdd-harness, el método con sus tres puertas y los controles, para OpenCode y Claude Code. Lo que tiene mi versión además (los especialistas, el modo autónomo y la memoria entre equipos) lo vas completando con tu agente según lo que necesites.

Las fuentes, para que no te fíes de mí:

• midudev y HolaMundo, en YouTube.
• Curso de SDD de Brais Moure: vídeo y repo hello-sdd.
• Everything Claude Code, de Affaan Mustafa.