{"slug": "why-spec-driven-development-tools-fail-in-the-enterprise", "title": "Why Spec-Driven Development Tools Fail in the Enterprise", "summary": "Spec-driven development tools like Amazon Kiro, GitHub Spec Kit, and BMad Method fail in enterprise settings because they assume greenfield projects, according to a post promoting the AI Unified Process (AIUP) at unifiedprocess.ai. The post argues that these tools generate excessive documentation and lack practical migration strategies for existing codebases, citing a Broadcom engineer and Martin Fowler's analysis.", "body_md": "The spec-driven development (SDD) movement is gaining momentum. Tools like Amazon Kiro, GitHub Spec Kit, and BMad Method promise to bring structure to AI-assisted coding. And they deliver on that promise, as long as you start from scratch.\n\nBut most enterprise teams don’t start from scratch. They maintain existing systems with hundreds of thousands of lines of code, established architectures, and years of accumulated business logic. When these teams try to adopt the popular SDD tools, they run into a wall.\n\nThis post compares the three most popular spec-driven tools and explains why the AI Unified Process (AIUP) at [unifiedprocess.ai](https://unifiedprocess.ai/) takes a fundamentally different approach. One that actually works for enterprise software development.\n\n## The Three Contenders\n\n### Amazon Kiro\n\nKiro is Amazon’s agentic IDE built on Amazon Bedrock. It follows a three-phase workflow: Requirements, Design, and Implementation. You describe a feature in natural language. Kiro generates user stories with acceptance criteria in EARS notation, creates a technical design document, and breaks it down into implementation tasks.\n\nThe workflow is clean and structured. But it was designed for greenfield projects. Even Amazon’s own product team has acknowledged this gap. As one Broadcom engineer put it: most developers don’t start from a greenfield idea. They start from an existing codebase, a messy bug, or a design they already agreed on. Kiro has since added Design-first and Bugfix workflows to address this, but the core assumption remains: you are building something new.\n\nFor enterprise teams, Kiro’s mandatory three-phase pipeline creates overhead that doesn’t match their reality. A single-line bug fix in a legacy system should not trigger a full spec generation pipeline. And when existing applications are large, it becomes impractical for LLMs to create specifications without exceeding context limits.\n\n### GitHub Spec Kit\n\nSpec Kit is GitHub’s open-source toolkit for SDD. It provides a CLI and templates that guide you through four phases: Specify, Plan, Tasks, and Implement. It is agent-agnostic and works with GitHub Copilot, Claude Code, Gemini CLI, and others.\n\nSpec Kit introduces a powerful concept: the `constitution.md`\n\nfile that establishes non-negotiable principles for your project. This is useful for organizations with opinionated stacks. The workflow is well-structured and produces a clear trail from intent to implementation.\n\nBut Spec Kit has the same fundamental problem. Its templates are generic and require manual customization for existing codebases. The documentation overhead can be significant, sometimes generating more markdown files to review than it would take to build the feature itself. And as Martin Fowler’s analysis pointed out, introducing SDD tools into an existing, entangled codebase is still mostly hand-wavy when it comes to practical migration strategy.\n\n### BMad Method\n\nBMad Method takes a different approach: a multi-agent framework where specialized AI agents (Analyst, Product Manager, Architect, Developer, QA) collaborate through file-based communication. It claims to be scale-adaptive, automatically adjusting from bug fixes to enterprise systems.\n\nBMad is the most ambitious of the three. With 19+ specialized agents and 50+ workflows, it provides comprehensive coverage. It even has an enterprise test architecture extension.\n\nBut this complexity is also its weakness. The framework requires Node.js 22+, has a steep learning curve, and the agent orchestration adds significant overhead. The v6 Alpha is still recommended for new projects, which tells you something about maturity. And despite claiming enterprise readiness, the real-world evidence for large-scale brownfield adoption is thin.\n\n## The Common Problem\n\nAll three tools share the same fundamental assumptions:\n\n**1. You start from a clean slate.** The workflows are optimized for “describe what you want and generate it.” They don’t account for 500-table Oracle schemas, established architectural patterns, or fifteen years of accumulated business rules.\n\n**2. One developer drives the process.** Enterprise development involves multiple stakeholders, cross-team dependencies, review processes, and compliance requirements. These tools assume a single person goes from spec to code.\n\n**3. The tech stack is flexible.** These tools happily suggest whatever framework fits best. But enterprise teams have standardized stacks. If your organization runs Spring Boot with Vaadin and jOOQ on OpenShift, the tooling needs to understand and respect that.\n\n**4. Specs are created from nothing.** In reality, enterprise systems already have requirements, often in the form of existing code, database schemas, and running business processes. The challenge is not to create specs from scratch but to work with what exists and extend it incrementally.\n\n**5. The methodology exists only at the coding level.** All three tools focus on turning specs into code. But enterprise development is a broader process that includes requirements engineering, stakeholder alignment, testing strategy, and continuous delivery. A tool that only covers the “code generation” step misses most of the picture.\n\n## A Different Approach: AI Unified Process (AIUP)\n\nThe AI Unified Process at [unifiedprocess.ai](https://unifiedprocess.ai/) was designed from the ground up for the reality of enterprise software development. It takes a fundamentally different approach.\n\n### Requirements Stay at the Center\n\nAIUP doesn’t start with code generation. It starts with requirements. Business requirements catalogs, entity models, use case diagrams, and use case specifications drive the entire process. These are artifacts that business stakeholders can review and validate, not markdown files that only developers see.\n\nThis is critical for enterprise teams where business alignment is not optional. Every line of code traces back to a business requirement. When a bug appears, you don’t dig through code to understand what the system was supposed to do, you go back to the specification.\n\n### Iterative, Not Waterfall\n\nUnlike tools that follow a linear spec-to-code pipeline, AIUP runs in four agile phases, Inception, Elaboration, Construction, and Transition, each with multiple short iterations. Specifications, code, and tests improve together through continuous cycles. This is not a return to Big Design Up Front. It is iterative improvement where each cycle builds on the previous one.\n\nCritics of SDD argue that it only works with exhaustive specifications that force deterministic output. AIUP addresses this directly: perfect specifications are impossible and unnecessary. The real value comes from iterative improvement where tests ensure consistent behavior regardless of how the AI generates code.\n\n### Technology-Specific Tooling\n\nThis is where AIUP differs most visibly from generic SDD tools. Instead of one-size-fits-all templates, AIUP provides technology-specific plugins for Claude Code:\n\nThe **aiup-core** plugin handles stack-agnostic requirements engineering: requirements catalogs, entity models, use case diagrams, and specifications. It works with any technology.\n\nThe **aiup-vaadin-jooq** plugin adds concrete implementation skills for Java web applications: Flyway database migrations, Vaadin UI implementation, Karibu unit tests, and Playwright E2E tests. It even integrates MCP servers for Vaadin, jOOQ, Karibu Testing, and JavaDocs, giving the AI direct access to framework-specific documentation and patterns.\n\nThis plugin architecture is extensible. More technology-specific plugins are in development. The key insight is that enterprise teams need tooling that speaks their language, not generic templates that require hours of customization.\n\n### Built for Brownfield\n\nAIUP works at the feature level within bounded contexts, not at the “generate an entire app” level. You can introduce it into an existing project, create specifications for the next feature you are building, and let AI handle the implementation within your established architecture.\n\nThere is no mandatory full-system specification. There is no requirement to retrofit your entire codebase with specs before you can start. You start where you are, specify what you are building next, and let the iterative process improve your documentation coverage over time.\n\n### Testing as the Safety Net\n\nAIUP treats tests as the primary safety net for AI code generation. Comprehensive tests, unit tests with Karibu, integration tests, E2E tests with Playwright, ensure that the system behaves consistently regardless of how the AI generates or regenerates code. This enables safe refactoring, safe modernization, and safe evolution of your codebase.\n\nThis is different from SDD tools that treat testing as an optional step or generate tests as an afterthought. In AIUP, the test strategy is planned from the Inception phase and executed throughout Construction and Transition.\n\n## Summary: The Right Tool for the Right Job\n\n| Aspect | Kiro | Spec Kit | BMad | AIUP |\n|---|---|---|---|---|\n| Primary audience | Solopreneurs, startups | Individual developers | Small teams | Enterprise teams |\n| Greenfield/Brownfield | Greenfield-first | Greenfield-first | Greenfield-first | Brownfield-ready |\n| Process scope | Code generation | Code generation | Full project lifecycle | Full development lifecycle |\n| Tech stack | Stack-agnostic | Stack-agnostic | Stack-agnostic | Technology-specific plugins |\n| Requirements engineering | User stories from prompts | PRD from prompts | Agent-generated | Business-validated use cases |\n| Stakeholder involvement | Minimal | Minimal | Minimal | Continuous validation |\n| Testing strategy | Generated tests | TDD recommended | QA agent | Planned from Inception |\n| Iterative improvement | Linear pipeline | Linear pipeline | Sprint-based | Agile phases with iterations |\n| Enterprise readiness | Limited | Experimental | Claims enterprise support | Designed for enterprise |\n| Tooling | Proprietary IDE | Open-source CLI | Open-source agents | Skills + MCP |\n\n## Conclusion\n\nAmazon Kiro, GitHub Spec Kit, and BMad Method are valuable contributions to the spec-driven development movement. They solve a real problem: bringing structure to AI-assisted coding. For greenfield projects, prototypes, and small teams, they work well.\n\nBut enterprise software development is a different game. It requires working with existing systems, respecting established architectures, involving business stakeholders, and planning for long-term maintainability. The popular SDD tools were not designed for this reality.\n\nThe AI Unified Process bridges this gap. It brings the discipline of spec-driven development to the enterprise context, with requirements at the center, iterative improvement as the method, technology-specific tooling as the enabler, and comprehensive testing as the safety net.\n\nIf you are an enterprise team exploring spec-driven development, don’t force greenfield tools into a brownfield world. Start with a methodology that was built for your reality.\n\nLearn more at [unifiedprocess.ai](https://unifiedprocess.ai/).", "url": "https://wpnews.pro/news/why-spec-driven-development-tools-fail-in-the-enterprise", "canonical_source": "https://martinelli.ch/why-spec-driven-development-tools-fail-in-the-enterprise/", "published_at": "2026-09-02 08:01:41+00:00", "updated_at": "2026-09-02 08:22:33.938727+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools", "artificial-intelligence"], "entities": ["Amazon Kiro", "GitHub Spec Kit", "BMad Method", "AI Unified Process", "unifiedprocess.ai", "Amazon Bedrock", "GitHub Copilot", "Martin Fowler"], "alternates": {"html": "https://wpnews.pro/news/why-spec-driven-development-tools-fail-in-the-enterprise", "markdown": "https://wpnews.pro/news/why-spec-driven-development-tools-fail-in-the-enterprise.md", "text": "https://wpnews.pro/news/why-spec-driven-development-tools-fail-in-the-enterprise.txt", "jsonld": "https://wpnews.pro/news/why-spec-driven-development-tools-fail-in-the-enterprise.jsonld"}}