- Spec-Driven Development (SDD) es un enfoque para la programación basada en IA en el que primero se escribe una especificación (spec) antes que el código; la especificación actúa como la fuente de verdad (source of truth) tanto para el desarrollador como para la IA
- El SDD se divide en tres niveles de implementación y evoluciona por etapas: spec-first (especificación primero), spec-anchored (conservación de la especificación para mantenimiento) y spec-as-source (usar la especificación como archivo fuente principal y que el desarrollador no edite el código directamente)
- Kiro ofrece un flujo de trabajo simple de 3 pasos: requisitos → diseño → tareas; spec-kit usa un flujo de trabajo fuerte basado en reglas llamado constitución (constitution); y Tessl experimenta con un enfoque spec-as-source que mapea especificación y código en una relación 1:1
- Las tres herramientas exigen demasiado proceso para corregir bugs pequeños, revisar archivos Markdown resulta más engorroso que revisar código y, pese a las grandes ventanas de contexto, la IA sigue teniendo límites para seguir correctamente todas las instrucciones
- El SDD recuerda los casos fallidos del desarrollo guiado por modelos (MDD) y corre el riesgo de heredar desventajas de ambos lados —no determinismo y rigidez—, por lo que aún hace falta validar su utilidad en proyectos reales
Definición de desarrollo guiado por especificaciones (SDD)
- El SDD escribe primero una especificación antes de crear código, en un enfoque de “documentación primero” (documentation first), donde la especificación funciona como una única fuente de verdad (single source of truth) para desarrolladores e IA
- GitHub lo define diciendo que “el mantenimiento de software significa la evolución de la especificación, donde el lenguaje común del desarrollo se mueve a un nivel más alto y el código queda como el paso final”
- Tessl lo describe como “un enfoque de desarrollo donde la especificación se convierte en el artefacto principal en lugar del código; la especificación expresa la intención en un lenguaje estructurado y verificable, y los agentes generan código en función de ello”
- El SDD se divide en tres niveles de implementación
- Spec-first: primero se redacta una especificación bien estructurada y luego se usa en un flujo de desarrollo asistido por IA
- Spec-anchored: la especificación se mantiene incluso después de terminar el trabajo y se sigue usando para la evolución y el mantenimiento de esa funcionalidad
- Spec-as-source: la especificación sigue siendo el archivo fuente principal con el tiempo; el desarrollador solo edita la especificación y no toca directamente el código
- Todos los enfoques SDD son spec-first, pero no todos apuntan a spec-anchored o spec-as-source, y muchas veces la estrategia para mantener la especificación a lo largo del tiempo queda ambigua o completamente abierta
¿Qué es una especificación (spec)?
- Una especificación es un artefacto estructurado y orientado al comportamiento escrito en lenguaje natural para representar una funcionalidad de software y servir como guía a agentes de programación con IA
- La definición más consistente es compararla con un documento de requisitos del producto (PRD)
- La especificación debe distinguirse de los documentos de contexto general del codebase
- El contexto general incluye archivos de reglas y descripciones de alto nivel del producto y del codebase; algunas herramientas a esto le llaman memory bank
- Los archivos del memory bank son relevantes en todas las sesiones de programación con IA del codebase, mientras que la especificación solo aplica a tareas de creación o cambio de una funcionalidad específica
- Cada variante de SDD define su propio enfoque sobre la estructura de la especificación, su nivel de detalle y cómo se organiza dentro del proyecto
La dificultad de evaluar herramientas SDD
- Evaluar herramientas y enfoques SDD de una forma cercana al uso real consume muchísimo tiempo
- Hay que probarlos en problemas de distintos tamaños, en proyectos greenfield y brownfield, y dedicar tiempo a revisar y corregir a fondo los artefactos intermedios, no de forma superficial
- En el blog post de GitHub sobre spec-kit se enfatiza que “lo importante es que tu rol no es solo marcar la dirección, sino también validar, reflexionar y mejorar en cada etapa”
- Dos de las tres herramientas parecen requerir más trabajo para adoptarse en codebases existentes, lo que vuelve más difícil evaluar su utilidad en entornos brownfield
- Antes de escuchar reportes de uso de personas que las hayan usado durante un tiempo en codebases reales, siguen existiendo muchas preguntas sin resolver sobre cómo funcionan en la práctica
Kiro
- Kiro es la herramienta más simple y ligera de las tres, y en gran medida corresponde a un enfoque spec-first
- Solo se encontraron ejemplos aplicados a tareas o historias de usuario, y no hay referencias a cómo usar documentos de requisitos de forma spec-anchored a lo largo de múltiples tareas con el paso del tiempo
- Flujo de trabajo: requisitos → diseño → tareas
- Cada etapa del flujo se representa con un documento Markdown, y Kiro guía estos 3 pasos dentro de una distribución basada en VS Code
-
Componentes principales de Kiro
- Requisitos (Requirements)
- Se estructuran como una lista de requisitos donde cada uno representa una “historia de usuario” (formato As a...)
- Los criterios de aceptación usan el formato GIVEN... WHEN... THEN...
- Diseño (Design)
- Incluye secciones como diagrama de arquitectura de componentes, flujo de datos, modelo de datos, manejo de errores, estrategia de pruebas, enfoque de implementación y estrategia de migración
- No está claro si mantiene una estructura consistente o si cambia según la tarea
- Tareas (Tasks)
- Lista de tareas rastreables mediante números de requisito
- Proporciona elementos adicionales de UI para ejecutar tareas una por una y revisar los cambios de cada tarea
-
El memory bank de Kiro
- Kiro llama al concepto de memory bank “steering”
- Su contenido es flexible y el flujo de trabajo no parece depender de la existencia de archivos específicos
- La estructura base que genera Kiro cuando se le pide crear documentos de steering es
product.md, structure.md y tech.md
Spec-kit
- spec-kit es la versión de SDD de GitHub y se distribuye como un CLI capaz de generar configuraciones de workspace para distintos asistentes de programación generales
- Después de configurar la estructura, se interactúa con spec-kit mediante slash commands del asistente de programación
- Como todos los artefactos se colocan directamente en el workspace, es la herramienta más personalizable de las tres que se comentan
-
Flujo de trabajo de Spec-kit
- Flujo de trabajo: constitución (Constitution) → 𝄆 especificar (Specify) → planear (Plan) → tareas (Tasks) 𝄇
- El concepto de memory bank de spec-kit es un prerrequisito del enfoque spec-driven
- Lo llama constitución (constitution), e incluye principios inmutables de alto nivel que siempre deben aplicarse a cualquier cambio
- Es un archivo de reglas muy potente y muy usado en el flujo de trabajo
-
Cómo funciona Spec-kit
- En cada etapa del flujo (specify, plan, tasks) usa scripts de bash y plantillas para instanciar conjuntos de archivos y prompts
- El flujo usa muchas listas de verificación dentro de los archivos para rastrear aclaraciones necesarias del usuario, violaciones de la constitución, tareas de investigación, etc.
- Funcionan como una especie de “definición de terminado” (definition of done) para cada etapa del flujo (aunque como la IA las interpreta, no hay garantía del 100%)
- Una sola especificación está compuesta por varios archivos
- Por ejemplo:
data-model, plan, tasks, spec, research, api, component y otros, en total 8 archivos
-
Enfoque de Spec-kit
- Al principio, GitHub parece apuntar a un enfoque spec-anchored
- “Está replanteando las especificaciones no como documentos estáticos, sino como artefactos vivos y ejecutables que evolucionan junto con el proyecto; la especificación se vuelve una fuente compartida de verdad”
- Sin embargo, spec-kit crea una rama por cada especificación que genera, por lo que puede interpretarse que la especificación es un artefacto vivo durante la vida útil de una solicitud de cambio, no durante toda la vida de la funcionalidad
- En discusiones de la comunidad también se menciona esta confusión, y parece que spec-kit sigue siendo principalmente spec-first y no realmente spec-anchored a lo largo del tiempo
Tessl Framework
- Tessl Framework está en beta cerrada y, al igual que spec-kit, se distribuye como un CLI capaz de generar estructuras de workspace y configuración para varios asistentes de programación
- Los comandos del CLI también funcionan como servidor MCP
-
Características de Tessl
- Es la única de las tres herramientas que apunta explícitamente a un enfoque spec-anchored, y además explora SDD al nivel de spec-as-source
- Las especificaciones de Tessl pueden funcionar como el artefacto principal que se mantiene y edita, mientras que el código aparece marcado arriba con el comentario
// GENERATED FROM SPEC - DO NOT EDIT
- Por ahora hay una relación 1:1 entre especificación y archivo de código, es decir, una especificación se convierte en un archivo del codebase
- Aún está en beta y experimenta con varias versiones, así que podría evolucionar hacia un nivel donde una especificación se mapee a un componente de código compuesto por varios archivos
-
Estructura de las especificaciones de Tessl
- Etiquetas como
@generate o @test le indican a Tessl qué debe generar
- La sección de API muestra la idea de definir en la especificación la interfaz mínima expuesta a otras partes del codebase, asegurando que partes importantes del componente generado queden bajo control total del mantenedor
- Al ejecutar
tessl build, se genera el archivo de código JavaScript correspondiente
-
Nivel de abstracción de Tessl
- Si la especificación para spec-as-source se ubica en un nivel de abstracción bastante bajo por archivo de código, se reduce la cantidad de pasos e interpretación que debe hacer el LLM y, por lo tanto, la probabilidad de errores
- Incluso con ese nivel de abstracción tan bajo, se observa no determinismo al generar código varias veces a partir de la misma especificación
- El proceso de reescribir una especificación una y otra vez para volverla cada vez más concreta y aumentar la repetibilidad de la generación de código recuerda las trampas y desafíos de escribir especificaciones completas y sin ambigüedades
Observaciones y preguntas
-
¿Un solo flujo de trabajo puede abarcar todos los tamaños?
- Kiro y spec-kit ofrecen cada uno un flujo de trabajo bastante dogmático, pero ambos podrían no encajar con la mayoría de los problemas reales de programación
- No está claro si ofrecen suficiente variedad para ajustarse al tamaño del problema
- Al intentar corregir un bug pequeño con Kiro, el flujo de trabajo se sintió como usar un mazo para romper una nuez
- El documento de requisitos convirtió un bug pequeño en 4 “historias de usuario” con un total de 16 criterios de aceptación
- Al usar spec-kit también quedó la duda de para qué tamaño de problema conviene usarlo
- Cuando se probó con una funcionalidad que en un equipo anterior habría sido una historia de 3 a 5 puntos, la cantidad de pasos y de archivos Markdown que generó spec-kit se sintió excesiva para el tamaño del problema
- En ese mismo tiempo se habría podido implementar la funcionalidad con programación asistida por IA “normal”, con una sensación de mucho más control
- Una herramienta SDD efectiva necesita ofrecer flexibilidad para al menos algunos flujos de trabajo centrales distintos según el tamaño y tipo de cambio
-
¿Revisar Markdown en lugar de revisar código?
- spec-kit genera muchos archivos Markdown para revisar
- Son repetitivos entre sí y también redundantes respecto al código existente
- Algunos ya incluyen código, lo que hace que todo sea muy verboso y aburrido de revisar
- En Kiro solo se obtienen 3 archivos y el modelo mental de “requisitos > diseño > tareas” es más intuitivo de entender, así que resulta un poco más fácil
- Aun así, Kiro también es demasiado verboso para un bug pequeño como el que se pidió corregir
- Sinceramente, da la impresión de que es mejor revisar el código que todos esos archivos Markdown
- Una herramienta SDD efectiva necesita brindar una muy buena experiencia de revisión de especificaciones
-
¿Una falsa sensación de control?
- A pesar de todos estos archivos, plantillas, prompts, flujos de trabajo y checklists, se ve con frecuencia que el agente al final no sigue todas las instrucciones
- Se menciona que las ventanas de contexto más grandes son uno de los factores que habilitan el SDD, pero que la ventana sea más grande no significa que la IA entienda correctamente todo lo que hay dentro
- Ejemplos
- spec-kit tiene una etapa de investigación dentro de la planeación y realizó bastante investigación sobre código existente, pero al final el agente ignoró que eso describía una clase existente, lo tomó como una nueva especificación y volvió a generarlo todo, creando duplicados
- No solo se ven casos en los que se ignoran instrucciones; también se observan agentes que se exceden por intentar seguir demasiado al pie de la letra una instrucción, por ejemplo una cláusula de la constitución
- La experiencia pasada sugiere que la mejor forma de mantener control sobre lo que construimos es trabajar en pasos pequeños e iterativos, así que hay bastante escepticismo sobre si hacer mucha especificación por adelantado es una buena idea
- Una herramienta SDD efectiva debería aceptar un enfoque iterativo, pero los paquetes de trabajo pequeños parecen casi lo contrario de la idea de SDD
-
¿Cómo separar eficazmente la especificación funcional de la técnica?
- En SDD es común la idea de separar deliberadamente la especificación funcional de la implementación técnica
- La aspiración de fondo es que, eventualmente, la IA pueda completar toda la solución y los detalles, e incluso cambiar de stack tecnológico a partir de la misma especificación
- En la práctica, al probar spec-kit había confusión frecuente sobre cuándo quedarse en el nivel funcional y cuándo agregar detalles técnicos
- Los tutoriales y la documentación tampoco eran consistentes en esto, y existían distintas interpretaciones de lo que realmente significa “puramente funcional”
- Si se piensa en la gran cantidad de historias de usuario que no lograron separar bien requisitos e implementación, el historial de toda la profesión en este punto no es especialmente bueno
-
¿Quién es el usuario objetivo?
- Muchos demos y tutoriales de herramientas de desarrollo spec-driven incluyen cosas como definir objetivos de producto y funcionalidad, e incluso usan términos como “historias de usuario”
- La idea aquí podría ser usar la IA como habilitador de cross-skilling para que los desarrolladores participen más activamente en el análisis de requisitos
- ¿O tal vez que desarrolladores y responsables de producto trabajen en pareja dentro de este flujo?
- Nada de esto se explica de forma explícita y se presenta como si fuera natural que los desarrolladores hagan todo ese análisis
- Entonces, ¿para qué tamaño y tipo de problema está pensado el SDD?
- Probablemente no sea adecuado para funcionalidades grandes que todavía están muy poco claras, porque en esos casos claramente se necesita trabajo más especializado de producto y requisitos, además de investigación y participación de stakeholders
-
Spec-anchored y spec-as-source: ¿estamos aprendiendo del pasado?
- Mucha gente traza paralelos entre SDD y TDD o BDD, pero especialmente en el caso de spec-as-source hay otra comparación importante: MDD (desarrollo guiado por modelos)
- Al inicio de su carrera se trabajó bastante en varios proyectos con MDD, y al probar Tessl Framework eso venía constantemente a la mente
- Los modelos de MDD eran, básicamente, especificaciones, pero expresadas no en lenguaje natural sino en UML personalizado o DSLs de texto
- También se construían generadores de código personalizados para convertir esas especificaciones en código
-
Comparación entre MDD y SDD
- En última instancia, el MDD no tuvo éxito en aplicaciones de negocio, porque operaba en niveles de abstracción incómodos y generaba demasiado overhead y demasiadas restricciones
- Sin embargo, los LLM eliminan parte de ese overhead y de esas restricciones del MDD, así que ahora aparece una nueva esperanza: concentrarse en escribir especificaciones y generar el código
- Con LLMs, ya no se está limitado a un lenguaje de especificación predefinido y parseable, ni hace falta construir generadores de código sofisticados
- El costo de eso, por supuesto, es el no determinismo de los LLM
- Las estructuras parseables también tenían la ventaja de que podían dar mucho soporte al autor de la especificación para redactar especificaciones válidas, completas y consistentes, y eso ahora se está perdiendo
- Spec-as-source, e incluso spec-anchoring, podrían terminar reuniendo las desventajas tanto del MDD como de los LLM: rigidez y no determinismo
- Vale la pena revisar los intentos del pasado de spec-from-code y aprender de ellos al explorar hoy el desarrollo spec-driven
Conclusión
- En lo personal, al usar programación asistida por IA muchas veces se dedica tiempo a redactar cuidadosamente la forma de especificación que se le dará al agente de programación
- Por eso, el principio general de spec-first sí tiene valor en muchas situaciones
- Hacen mucha falta diferentes enfoques sobre cómo estructurar especificaciones, y actualmente es una de las preguntas que más suelen hacer quienes trabajan en esto
- “¿Cómo estructuro un memory bank?”, “¿Cómo redacto buenos documentos de especificación y diseño para IA?”
- Sin embargo, el término “spec-driven development” todavía no está bien definido y su significado ya se está expandiendo semánticamente
- Últimamente incluso se escucha usar “spec” básicamente como sinónimo de “prompt detallado”
-
Evaluación de las herramientas
- Algunas intentan trasladar demasiado literalmente los flujos de trabajo existentes a agentes de IA y, al final, pueden amplificar problemas ya conocidos como la sobrecarga de revisión y las alucinaciones
- Especialmente en los enfoques más sofisticados que generan muchos archivos, viene a la mente el compuesto alemán “Verschlimmbesserung” (empeorar algo al intentar mejorarlo)
- Y queda la duda de si, al intentar mejorarlo, en realidad no se está empeorando
3 comentarios
Se parece a cosas de las que ya se había hablado antes, como document driven development o readme driven development.
https://es.news.hada.io/topic?id=15502
Opiniones en Hacker News
He estado siguiendo la tendencia reciente de SDD (desarrollo guiado por especificaciones); el enfoque parece razonable, pero también da la sensación de estar regresando a la era pre-agile de las especificaciones funcionales y los documentos de diseño. No es exactamente Big Design Up Front, pero sí parece avanzar hacia una idea de “software funcionando == documentación perfecta”.
Referencia sobre Big Design Up Front, Referencia sobre el Manifiesto Ágil
Las especificaciones funcionales y los documentos de diseño, al final, son como programar en lenguaje natural. Antes una persona tenía que volver a codificar eso en un lenguaje de programación, pero ahora compiladores automatizados como los LLM (modelos de lenguaje grandes) están empezando a hacer ese trabajo. En cierto sentido, eso permite saltarse una etapa completa (con resultados variables).<br /> En cambio, Agile no se preocupa por en qué lenguaje se construye el software; su esencia está en “eliminar al gerente” y hacer que el desarrollador también asuma las tareas de gestión. Los 12 principios explican con más detalle qué deben hacer los desarrolladores cuando no hay gerente
Behaviour Driven Design, al igual que Test Driven Design, puede producir una “especificación viva”. Deja documentación legible por humanos, desde los criterios de exploración del dominio hasta si las pruebas pasan o no, y además puede conectarse directamente con el test harness para validar el comportamiento actual. Así se obtiene, mediante reportes BDD, una especificación claramente validada, colaborativa e iterativa, y al mismo tiempo se cubren Agile, JIT y YAGNI sin trabajo innecesario al principio. No hace falta volver a waterfall
También se puede empezar con un diseño pequeño: escribir una especificación de una o dos páginas, generar código y pruebas con un LLM e ir refinando de forma iterativa. Si de verdad se confía al 100% en la programación con LLM, entonces tiene lógica gestionar de forma sistemática la entrada de especificaciones (prompts en inglés). En vez de desecharlos, conviene organizarlos para reutilizarlos después o agregar restricciones adicionales con claridad<br /> Pero usar LLM para código crítico de producción todavía me da inseguridad, así que por ahora solo experimento con ellos en sandbox/pruebas/demos. Los uso únicamente donde la calidad del código no es tan importante
El spec driven development en sí es una buena idea. Sin embargo, las implementaciones actuales solo le pasan archivos markdown no estructurados al agente y, como los resultados no salen bien, en la práctica no hay reproducibilidad alguna. Si el agente también va a redactar la especificación, entonces esta debería ser estructurada, de forma que pueda transformarse automáticamente incluso en código stub y código de pruebas. No se trata de desechar markdown, sino de integrarlo con generadores de código para mejorar mucho la reproducibilidad. De hecho, si se hace así, se puede reducir bastante el tiempo dedicado a generar código repetitivo
Al probar SpecKit me pareció realmente interesante y satisfactorio, pero me costó encontrar ejemplos o usos complejos del mundo real. La mayoría de los tutoriales se queda en lo básico: instalarlo y “hacer una app de lista de tareas”. Me gustaría ver casos reales de mejora gradual o refactorización de codebases legacy, o cómo abordar proyectos grandes donde el spec driven development no se aplicó desde el inicio
Yo también, combinando un enfoque BDD con programación basada en CLI, sentí que registrar funcionalidad directamente en código real es mucho más efectivo que escribir markdown largo y verboso. Si hace falta una checklist para que la IA siga el hilo, un archivo como
agents.mdes más que suficiente. Basta con documentar una vez ese patrón de coding y los requisitos no funcionales (NFR) para que el agente los siga con claridadPara usarlo de verdad, hay que leer directamente los templates o el source code para entender qué está pasando realmente. En este tipo de proyectos, incluso me parece un proceso natural
Después de la presentación de un especialista en delivery con IA proveniente de Thoughtworks, cuando salió el tema de los memory banks conecté de inmediato. Nosotros también trabajamos en un entorno donde “la IA es la gran tendencia”, y vimos que cuando el memory bank crece demasiado, la IA más bien pierde el rumbo y los resultados salen desordenados. Al final, alguien que entienda completamente el producto tiene que liderar a la IA para que esto sea aplicable de verdad en el trabajo real. He vivido incontables veces cuánto me ha engañado la IA, y cuando una persona la vuelve a orientar, siempre se disculpa y dice entender, pero eso no cambia nada. Además, no es realista pensar que la IA pueda leer y verificar por sí sola esa enorme cantidad de documentos que ellas mismas producen. A veces siento que sería mucho mejor simplemente hacer el trabajo directamente
Me pregunto qué significa exactamente memory bank y qué se quiere decir en concreto sobre su función
En este momento, la función de memory incluso puede ser perjudicial. Si se usa sin una estrategia adecuada de búsqueda/consulta, solo amplifica malos resultados. La mayoría de los sistemas de memory están diseñados para el paradigma de un solo chat, así que en distintos entornos solo generan problemas. La verdadera “memoria” debería ser una especie de “metacognición/default mode network” separada del agente principal, que diseñe en forma asíncrona la estructura de tareas y el contexto, y luego oriente cada prompt. Es decir, lo correcto sería una “memoria basada en agentes”
Tampoco entiendo eso de ponerse el título de ‘thought leader’ en sitios como LinkedIn. Hoy en día de verdad cuesta saber qué significa ese título
Quiero compartir una experiencia reciente de las últimas dos semanas, experimentando con SpecKit y Claude Code en dos proyectos nuevos. Como desarrollé ambos yo solo, no me preocupaba demasiado probar cosas. En el primer proyecto dejé que SpecKit lo llevara tal cual: tardó 10 días en completar todas las tareas, pero la mayoría de las pruebas del resultado fallaban y el build también estaba roto. Terminé invirtiendo la misma cantidad de tiempo en corregirlo, y Claude, cada vez que arreglaba una cosa, rompía otra, así que mi confianza cayó muchísimo<br /> En el segundo proyecto quise iterar en unidades pequeñas, así que después del planning de SpecKit agregué comandos slash para crear
backlog.md, luego uséplan-sprintpara generar archivos con objetivos del sprint y detalle del trabajo, y después procesé todo conimplement-sprint. Pero incluso así, el proceso ignoraba las instrucciones de implementación: varias veces no generó pruebas o se saltó tareas, aunque ajustara el flujo repetidamente<br /> Entonces volví a cambiar la configuración y pasé a un esquema con subagentes dedicados a tareas específicas, dejandoimplement-sprintsolo como orquestador. Así podía revisar el estado del código en cada sprint y la confianza mejoró bastante. Todavía pasa que dice que terminó aunque las pruebas fallen, pero sigue siendo más manejable que tener que revisar todo personalmente<br /> Mi hipótesis actual es que Claude es débil para TDD. Siempre tiene problemas en la etapa de escribir primero las pruebas. La próxima vez pienso probar el enfoque inverso: escribir las pruebas después de implementar. No es lo ideal, pero si así mejora la productividad, tal vez siga siendo mejor que programar todo uno mismoMe pareció interesante que la mayoría de las herramientas estén alineadas con una estrategia de “especificación primero”, pero que sigan siendo ambiguas respecto a cómo mantener esas especificaciones. Personalmente, con mi cofounder estamos apostando todo a “spec as source”. Creemos que tratar la especificación como verdadero source es el caso de uso más interesante, y lo estamos intentando, pero lograr que se consolide en la práctica es muy difícil. Si alguien tiene experiencia o feedback al respecto, me gustaría mucho escucharlo<br /> Si les interesa, también les pediría que prueben nuestro experimento, specific.dev, y nos cuenten qué tal
Probé el workflow spec-driven de Kiro y genera una cantidad enorme de listas de tareas (más de 4 subtareas por tarea y más de 12 tareas en total). El workflow en sí estaba bien, pero de forma impredecible borraba código y no hacía rollback. Como está hecho como IDE, parece que consume recursos en manejar excepciones de UI. En vez de dividir todo de manera compleja, es más fácil iterar de forma simple y mejorar; es como “usar un mazo enorme para romper una nuez”
Me gustó la idea de usar comandos slash personalizados para empaquetar la entrada en prompts bien estructurados. También me parece bueno que inyecten como contexto las partes divididas desde archivos como
agents.md<br /> Lo que no me gusta es ese intento de desatar todos los nudos, que termina sintiéndose como romper una nuez con un martillo, es decir, agregando complejidad. Pero creo que sería más ligero si se pudiera gestionar el contexto de manera selectiva con comandos slash adicionales solo cuando hagan falta (/experiment,/stub, etc.). Y al final, algo como"/wrap-up"podría servir como comando de cierre para atar todos los cabos de una vez, como el chequeo final de un médico después de una cirugíaMientras usaba SpecKit siempre me quedaba la duda de “¿cuándo se va a unificar toda esta colección de specs en una sola fuente real de verdad (ground truth)?”. Me decepcionó sentir que esa etapa ni siquiera existe<br /> Ahora queda la tarea de definir y diseñar cómo debería verse una especificación de comunicación entre humanos y agentes. Estoy pensando cómo materializar ese concepto de “spec anchored” que mencionó Birgitta
No sé por qué SDD se volvió tan popular de repente, pero en lo personal me resulta práctico simplemente crear archivos de especificación para “entender de antemano el resultado final” y seguir el progreso al dividir el proyecto en partes pequeñas. No uso herramientas ni frameworks aparte; solo archivos markdown. No le veo mucho valor a sistemas más complejos que eso
Cuando usé spec-kit por primera vez tenía muchísimas expectativas, pero en la práctica me obligó a crear tareas innecesarias, como si tuviera que llegar hasta la etapa de “construir un robot dentro de una cueva”, y expandía demasiado cosas que en realidad solo requerían apretar un tornillo. Terminé agotado de corregir todo y lo dejé. Me parece un workflow tan excesivamente complejo que ni siquiera vale la pena ajustarlo
Si lo piensas, en realidad es algo simple y práctico: tomar lo que aprendiste en ingeniería de software y hacerlo en Markdown. Basta con redactar bien la especificación de requisitos.