A medida que los agentes codificadores de IA se vuelven más capaces, ha surgido un problema estructural: velocidad sin claridad. Los desarrolladores generan código funcional en minutos, sólo para descubrir días después que no coincide con lo que el sistema realmente necesitaba. El desarrollo basado en especificaciones (SDD) aborda esto directamente: tratando una especificación estructurada como la fuente de verdad y el código como su resultado generado, y no al revés.
Esta lista cubre las 9 herramientas de inteligencia artificial que los desarrolladores están utilizando para implementar flujos de trabajo SDD en 2026.
AWS Kiro
🔗 kiro.dev | Documentos | Modelos
Kiro es un IDE agente creado en torno al desarrollo basado en especificaciones, diseñado para llevar a los desarrolladores desde el concepto hasta la producción con rigor estructurado en lugar de indicaciones iterativas. En lugar de escribir código y pedir ayuda a una IA en el camino, Kiro requiere que los desarrolladores formalicen la intención primero. Los guía a través de un proceso de tres fases (Requisitos, Diseño y Tareas) que produce tres artefactos estructurados: requisitos.md, diseño.md y tareas.md. Un detalle técnico notable: Kiro genera historias de usuarios utilizando la notación EARS (Easy Approach to Requisitos Syntax), que produce criterios de aceptación estructurados que cubren casos extremos que de otro modo los desarrolladores manejarían manualmente.
Un diferenciador importante es su sistema de enlaces de agentes: automatizaciones basadas en eventos que se activan cuando se guardan o crean archivos, manejando tareas como actualizaciones de prueba, actualizaciones de README y análisis de seguridad sin indicaciones manuales. Para la selección de modelos, el valor predeterminado de Kiro es un enrutador automático que combina múltiples modelos de vanguardia, incluidos Claude Sonnet, Qwen, DeepSeek, GLM y MiniMax, y selecciona el modelo óptimo por tarea para equilibrar calidad y costo. Los desarrolladores también pueden fijar un modelo específico para un comportamiento consistente. Basado en Code OSS, los usuarios de VS Code se sentirán como en casa de inmediato. Kiro también admite una CLI y una interfaz web, y no requiere una cuenta de AWS para su uso. Lo mejor para equipos que necesitan flujos de trabajo de especificaciones formales en un entorno de desarrollo familiar.
Kit de especificaciones de GitHub
🔗 github.com/github/spec-kit | Publicación de blog
GitHub Spec Kit es la opción de código abierto más adoptada por la comunidad para el desarrollo basado en especificaciones: una CLI de Python con más de 93 000 estrellas, siendo la última versión la v0.8.7 (7 de mayo de 2026), que admite más de 30 agentes de codificación de IA, incluidos Claude Code, GitHub Copilot, Amazon Q y Gemini CLI. El flujo de trabajo se ejecuta a través de cuatro fases con puntos de control claros: Especificar (captura el contexto empresarial y los criterios de éxito), Planificar (traduce las especificaciones en decisiones arquitectónicas), Tareas (descompone los planes en unidades comprobables y revisables) e Implementar (ejecuta agentes de IA bajo esas restricciones).
La base de cada flujo de trabajo de Spec Kit es una “constitución”: un archivo de reglas de rebajas que contiene principios inmutables de alto nivel que se aplican a cada cambio en cada sesión. Este se convierte en el contrato persistente entre el desarrollador y el agente. La filosofía de Spec Kit, tal como la planteó GitHub, es que el código es ahora el resultado del último kilómetro: la intención es la fuente de la verdad y las especificaciones son ejecutables. Es el punto de partida predeterminado para los equipos nuevos en SDD y la opción más portátil para los equipos que desean conservar su IDE existente.
MÉTODO BMAD
🔗 github.com/bmad-code-org/BMAD-METHOD | Documentos
BMAD-METHOD (Build More Architect Dreams) es un marco de código abierto con licencia del MIT que organiza más de 12 agentes de IA especializados a lo largo de todo el ciclo de vida de desarrollo de software. La versión 6.6.0 se lanzó el 29 de abril de 2026 y el proyecto alcanzó más de 46 700 estrellas de GitHub y más de 5500 bifurcaciones. Los más de 12 agentes cubren distintos roles de SDLC, incluida la gestión de productos, arquitectura, UX, desarrollo, control de calidad y funciones scrum master, y trabajan juntos a través de transferencias estructuradas basadas en archivos: cada agente lee el documento de salida del agente anterior y escribe el suyo propio, manteniendo una cadena rastreable desde los requisitos hasta la entrega.
V6 introdujo el equipo de agentes multiplataforma, lo que permite que la misma configuración de agente funcione en Claude Code, Cursor, Codex y otros hosts sin necesidad de reconfiguración. La arquitectura V6 también separa las preocupaciones en tres capas: BMad Core (el marco universal de colaboración entre humanos y IA), BMad Method (el módulo de desarrollo ágil construido en Core) y BMad Builder (que permite a los equipos crear y compartir agentes y flujos de trabajo personalizados). BMAD es el marco de referencia para equipos que desean flujos de trabajo de múltiples agentes altamente estructurados y con roles separados sin depender de un proveedor. El marco es completamente gratuito y no tiene muros de pago.
Código de aumento
🔗 augmentcode.com | Guía SDD
Augment Code aborda el desarrollo basado en especificaciones desde la capa de contexto en lugar de la capa de creación de especificaciones. Su Context Engine mantiene una comprensión arquitectónica persistente en más de 400 000 archivos, abordando la brecha de contexto entre repositorios que rompe la mayoría de los flujos de trabajo de especificaciones a escala, particularmente en bases de código industriales abandonadas de múltiples servicios. Augment reporta un 70,6 % en SWE-bench (en comparación con un promedio de la industria del 54 %) y una puntuación F del 59 % en un punto de referencia de revisión de código de IA; Estas cifras son reportadas por los proveedores y deben tratarse en consecuencia.
Su modelo BYOA (Bring Your Own Agent) permite a los equipos conectar Claude Code, Codex u OpenCode junto con su agente nativo Auggie. Augment Code no crea especificaciones de forma nativa (los equipos aún necesitan una herramienta como Spec Kit o Kiro para la gestión estructurada de especificaciones), pero proporciona la base semántica que hace que esas especificaciones sean precisas en grandes bases de código. Es más adecuado para equipos empresariales que ejecutan arquitecturas multiservicio complejas donde la deriva del contexto, no la creación de especificaciones, es el principal modo de falla.
Código Claude
🔗 claude.ai/code | Documentos
Claude Code es la herramienta de línea de comandos agente de Anthropic y, a diferencia de herramientas como Cursor o GitHub Copilot que aumentan el flujo de trabajo de un desarrollador, está diseñado para un desarrollo totalmente autónomo: planificación, orquestación de flujos de trabajo de varios pasos y formulación de preguntas de seguimiento sin indicaciones constantes. Para flujos de trabajo basados en especificaciones, Claude Code maneja documentos de especificaciones grandes en una sola sesión, procesa conjuntos de requisitos completos y genera implementaciones en una sola pasada coherente.
Los desarrolladores suelen utilizar archivos CLAUDE.md como capa de especificaciones, un enfoque ligero que impone un contexto de proyecto persistente, estándares de codificación y restricciones arquitectónicas en cada sesión. Esto significa que muchos desarrolladores ya están practicando una forma de SDD con Claude Code sin etiquetarlo formalmente como tal. Claude Code también sirve como agente de ejecución comúnmente admitido en marcos SDD, incluidos BMAD, GSD y GitHub Spec Kit.
GSD (Haz la mierda)
🔗 github.com/gsd-build/get-shit-done
GSD es un marco de ingeniería de contexto y metaindicación basado en especificaciones creado principalmente para Claude Code y agentes compatibles, posicionándose como la alternativa sencilla y sencilla a BMAD. El proyecto ha superado las 61.000 estrellas de GitHub, creciendo de cero a esa cifra en menos de cinco meses desde su compromiso inicial en diciembre de 2025. Se instala a través de npx get-shit-done-cc@latest y funciona en Claude Code, OpenCode, Gemini CLI, Codex, Copilot, Cursor, Windsurf, Augment y Cline.
Su orquestación de múltiples agentes genera investigadores, planificadores, ejecutores y verificadores paralelos, cada uno de los cuales opera en una nueva ventana de contexto con hasta 200.000 tokens dedicados a la implementación. El diseño independiente del modelo, que incluye soporte para OpenRouter y modelos locales, desacopla el flujo de trabajo de cualquier proveedor de LLM. Mientras que BMAD agrega ceremonias de sprint y coordinación de partes interesadas, la filosofía de GSD es que la complejidad debe residir en el sistema, no en el flujo de trabajo. También llena un vacío que el propio Claude Code no cubre de forma nativa: rotación de contexto, puertas de calidad y persistencia del estado de planificación entre sesiones.
Cursor (con Modo Plan + Reglas de Proyecto)
🔗 cursor.com | Mejores prácticas para agentes
Cursor sigue siendo uno de los editores de IA más utilizados, y su modo Plan lo convierte en un punto de entrada práctico para los equipos que adoptan hábitos de priorizar las especificaciones sin cambiar de cadena de herramientas. El modo Plan crea un plan de implementación detallado antes de escribir cualquier código: hace preguntas aclaratorias, mapea los archivos afectados y genera un plan revisable que el desarrollador aprueba antes de que actúe el agente. Esto evita la generación prematura de código para funciones que afectan a varios archivos o requieren decisiones arquitectónicas.
Para un contexto persistente similar a una especificación, el sistema de reglas actual de Cursor utiliza reglas de proyecto almacenadas en .cursor/rules/ (la convención anterior .cursorrules ahora se considera heredada). Cuando se combina con reglas de proyecto, Cursor admite un flujo de trabajo de especificaciones liviano y portátil para funciones nuevas de tamaño mediano a grande. La desventaja es que el soporte de especificaciones de Cursor no es nativo de su arquitectura como lo es el de Kiro: no hay un ciclo de vida de especificaciones incorporado, detección de deriva o sincronización de especificaciones vivas. Para los equipos que desean un desarrollo de IA estructurado dentro de un editor familiar y de alta calidad sin sobrecarga completa de SDD, Cursor con modo Plan es un término medio capaz.
Especificaciones abiertas
🔗 github.com/Fission-AI/OpenSpec
OpenSpec se dirige a un caso de uso específico y desatendido: equipos donde la gestión de cambios requiere documentación explícita y auditable antes de que comience cualquier implementación. Utiliza un flujo de trabajo centrado en propuestas con artefactos estructurados para cambios y aborda específicamente la iteración antigua con marcadores delta (AÑADIDO/MODIFICADO/ELIMINADO) que rastrean los cambios en relación con la funcionalidad existente en lugar de descripciones nuevas. Es importante destacar que la propia documentación de OpenSpec lo posiciona como un sistema liviano y flexible en lugar de un sistema rígido controlado por fases: proporciona estructura sin imponer barreras de aprobación estrictas entre fases.
En una evaluación independiente realizada en febrero de 2026 en 13 categorías de puntuación en un backend Python sin servidor de tamaño mediano, OpenSpec obtuvo la puntuación más alta en general, aunque esa clasificación cambia significativamente según las diferentes prioridades. Los equipos para quienes la responsabilidad de cambios y los rastros de documentación superan la sincronización de especificaciones vivas encontrarán que esta es la mejor opción. Para iniciativas multiservicio más grandes, se recomienda combinar OpenSpec con una plataforma de especificaciones vivas, ya que su estructura basada en propuestas produce documentos estáticos que pueden variar durante una implementación extendida.
tessl
🔗 tessl.io | Registro de especificaciones | Documentos
Tessl es una plataforma de habilitación de agentes independiente del idioma construida en torno a dos productos distintos. Tessl Framework se instala como “mosaicos” en el directorio .tessl/ de un proyecto y enseña a cualquier agente compatible con MCP, incluidos Claude Code, Cursor y otros, a seguir un flujo de trabajo basado en especificaciones independientemente de la pila: los agentes hacen preguntas aclaratorias primero, escriben documentos de especificaciones estructurados, esperan la aprobación del desarrollador y luego implementan. Las especificaciones viven en el código base como memoria a largo plazo, lo que brinda a las decisiones un seguimiento de auditoría y permite al agente hacer evolucionar la aplicación de manera coherente a lo largo del tiempo.
El Tessl Spec Registry es el diferenciador más claro de la plataforma: un registro abierto de más de 10,000 especificaciones que describen cómo usar correctamente bibliotecas externas de código abierto, apuntando directamente a las alucinaciones de API y las combinaciones de versiones que los agentes producen con frecuencia en las bases de código de producción. Piense en ello como npm para las especificaciones: los equipos instalan un mosaico de metodología (cómo trabajar) y mosaicos de biblioteca (qué herramientas usar correctamente) para evitar tanto el caos del proceso como las alucinaciones de la documentación. La arquitectura de dos capas (contexto de proceso más contexto de biblioteca) es la idea central de Tessl: el flujo de trabajo estructurado por sí solo no es suficiente si el agente todavía alucina con las API con las que está construyendo.
No dude en seguirnos en Twitter y no olvide unirse a nuestro SubReddit de más de 150.000 ML y suscribirse a nuestro boletín. ¡Esperar! estas en telegrama? Ahora también puedes unirte a nosotros en Telegram.
¿Necesita asociarse con nosotros para promocionar su repositorio de GitHub O su página principal de Hugging O su lanzamiento de producto O seminario web, etc.? Conéctate con nosotros