Hace un mes, en el trabajo me asignaron la misión de utilizar spec-kit en un proyecto nuevo, para analizar su viabilidad:

• qué funciona y qué no
• ventajas e inconvenientes
• limitaciones
• impacto en productividad

Además de usarlo en ese proyecto de la empresa, lo usé en un par de proyectos personales, para probar diferentes casos de uso y escenarios.

La conclusión: spec-kit es una idea genial, pero en la práctica no me funciona. Las especificaciones que genera son demasiado pesadas; no solo para los agentes, también para los desarrolladores que tienen que leerlas y mantenerlas. Y no soy solo yo: es una opinión generalizada en el equipo.

Si quieres que un humano revise la especificación, no puedes entregarle decenas de documentos con cientos de líneas cada uno para una funcionalidad sencilla.

Cuanto mayor es el pajar, más difícil es encontrar la aguja… y más probable es que ni siquiera la busques.

Dicho esto, la idea de fondo me parece excelente:

Mover el ámbito de trabajo principal del desarrollador desde el código a la especificación, de un modo estructurado y formalizado que facilita el trabajo en equipo.

Así que hice lo siguiente: empecé a escribir las especificaciones a mano, en un único archivo conciso y claro (algo que los humanos podamos digerir y revisar sin dolor).

Resultó que, además, a la IA también le venía mejor trabajar con contextos más pequeños y específicos.

Después de un tiempo trabajando así, escribí agentes para ayudar con secciones concretas de la especificación y con la implementación. Y aunque lo que escribe un agente tiende a ser más largo, sigue siendo revisable: no acaba convertido en el tocho infumable que me generaba spec-kit.

El siguiente paso es probar este enfoque en equipo, en la empresa. Si nos encaja, seguramente el paso final sea publicarlo como herramienta open source para que otros puedan usarla y mejorarla.