Abandono TSDD
Escribí una metodología. Se llamaba TSDD —Thin Spec Driven Development— y hoy su README tiene una insignia roja que dice abandoned. No “en pausa”, no “evolucionando hacia otra cosa”: abandonada.
Hace un mes publiqué SDD: la trampa que te quieren vender los gurús, donde criticaba las versiones pesadas. Faltaba la parte incómoda: yo tenía la mía, más liviana y mejor argumentada, y se murió por el mismo diagnóstico.
Qué intentaba arreglar
La idea era razonable. Los frameworks de SDD te hacen instalar un árbol de carpetas antes de escribir una línea, así que armé la versión sin grasa: una spec que asume el contexto del proyecto y no lo repite, etapas modulares que usas solo si aplican, artefactos generados después de implementar y no antes, humano en el loop en todas las etapas.
Sigo pensando que cada principio por separado está correcto. Eso es lo interesante del fracaso: estaba correcto y fue inútil igual.
Por qué se murió
Nadie lee las specs. Yo tampoco. Las de cuarenta páginas no, obvio. Pero tampoco las de media página, escritas por mí, para mí, diez días antes. Cuando retomo una tarea abro el código y el plan de hoy, nunca el documento que describía la intención de la semana pasada.
La spec le pelea el protagonismo al código. El código es lo único que se ejecuta, se despliega, se revisa y se cae a las 3 AM. Cualquier artefacto que compita por atención con él es sobrecarga, y cuando discrepan, el que miente es el documento —eso ya lo sabía, lo escribí, y aun así seguí manteniendo el documento.
Son entregables vacíos. Tres specs aprobadas y cero comportamiento nuevo se siente como avance, y ese es exactamente el problema: la sensación llega antes que el trabajo y anestesia.
El “driven” nunca fue verdad. Lo que conducía el trabajo era el código existente y la conversación con el agente. La spec iba detrás, actualizándose para no quedar mintiendo. Un artefacto que persigue a la realidad no está conduciendo nada.
El detalle que me delató
La tabla comparativa del README. Comparaba TSDD contra Vibe Coding, BMAD y Spec Kit, con filas tipo “spec lista para agentes” o “cierra en el repositorio”. Más abajo: FAQ, ejemplos por tamaño de equipo, cinco skills instalables con npx.
Nada de eso es ingeniería, es posicionamiento. Nadie le escribe una FAQ a la herramienta que usa todos los días; la FAQ es para el que quieres convencer. El día que empecé a defender la sigla en vez de usarla, ya estaba del otro lado del mostrador.
Si una metodología necesita onboarding, no es una metodología. Es un producto con ambición de estándar.
Lo que sobrevivió
La propuesta. Cuando el problema es difuso —no sé qué construir todavía, hay tres caminos y dos son caros— escribir el problema, el alcance y las decisiones abiertas se paga solo. No es una spec: es pensar antes de gastar.
Un PLAN.md desechable. Plan corto, lo apruebo, se implementa, reviso, commit, push, refactor, tarea siguiente. El plan vive lo que dura la tarea y se borra sin ceremonia. Sin ciclo de vida, sin árbol de docs/ que mantener, sin contrato que sincronizar con el código.
Eso es todo. No tiene sigla y no se la voy a poner.
Lo que me molesta del ecosistema
Ahora la parte que va a incomodar. SDD pasó de “escribe lo que vas a hacer antes de hacerlo” —sentido común con siglos de historia— a tener niveles de madurez, taxonomías de spec, certificaciones, charlas de cuarenta minutos y gente contestando dudas de arquitectura con citas a su propio framework.
El patrón es siempre el mismo: un problema real —los agentes rinden mejor con instrucciones precisas— convertido en disciplina con vocabulario propio, porque una disciplina se puede enseñar, vender y liderar. Un consejo de dos líneas no.
Y el consejo es de dos líneas: pide con precisión el trozo más chico que sirva, y verifica ejecutando. Lo demás es artesanía local —tu repo, tus tests, tu tolerancia al riesgo— y para eso no hay curso, porque no se puede empaquetar lo que depende de tu sistema.
Lo que se vende ahí no es un método, es la sensación de control sobre una herramienta no determinista. Se entiende que tenga mercado. Yo fui uno de los que la vendía.
Lo que cuesta matar una idea propia
Matar tu propia idea cuesta un commit y algo de vergüenza. Defenderla tres años porque lleva tu nombre cuesta bastante más, y lo pagan los que te creyeron.
TSDD queda publicado como registro, con la advertencia arriba. Tres estrellas en GitHub: tampoco murió de éxito.