--- title: From Spec-Driven Development to Living Specifications in... description: An exploration of how Spec-Driven Development can evolve into 'Living Specifications' for Java projects using AI coding agents. The piece traces a journey from... canonical: https://daily.dev/posts/from-spec-driven-development-to-living-specifications-in-java-projects-5drll9xwa twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: From Spec-Driven Development to Living Specifications in Java Projects | daily.dev og:description: An exploration of how Spec-Driven Development can evolve into 'Living Specifications' for Java projects using AI coding agents. The piece traces a journey from... og:url: https://daily.dev/posts/from-spec-driven-development-to-living-specifications-in-java-projects-5drll9xwa og:image: https://api.daily.dev/og/posts/5DrLL9Xwa.png og:image:alt: From Spec-Driven Development to Living Specifications in Java Projects og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # From Spec-Driven Development to Living Specifications in Java Projects **[Foojay.io](https://daily.dev/sources/foojayio)** · 14 min read · 5 upvotes · 1 comments ## Summary An exploration of how Spec-Driven Development can evolve into 'Living Specifications' for Java projects using AI coding agents. The piece traces a journey from Loiane Groner's spec-driven feedback loop, through the author's own SLDD skills experiment, to discovering SBCE (a workflow by Adam Bien built on the Boundary-Control-Entity architecture that stores specifications as Markdown Javadoc inside package-info.java) and finally to SDD4J, an open-source workflow the author built with Matheus Oliveira that uses architecture adapters so specifications can work across brownfield Java projects using different architectural styles (BCE, package-by-feature, package-by-layer). Requirements are expressed using EARS-style testable statements, and the workflow supports localized languages for specifications. The core argument is that specifications should live close to code, drift should be visible, and convergence between spec and implementation should be cheap, rather than treating a spec as an immutable source of truth. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is SDD4J and how does it differ from SBCE for spec-driven development in Java? SDD4J is an open-source Agent Skills workflow that adapts spec-driven development to a Java project's existing architecture through architecture adapters, unlike SBCE which anchors specifications specifically to the Boundary-Control-Entity (BCE) architectural style. SDD4J supports package-by-feature, package-by-layer, and BCE structures without requiring reorganization, and provides setup, new, apply, and verify commands, released via the soujava/agent-skills GitHub repository. _Explore daily.dev for more on choosing spec-driven workflows that fit existing Java architectures._ ### How does SBCE store specifications alongside Java code? SBCE stores each Business Component's specification inside its own package-info.java file as Markdown Javadoc, requiring Java 23 or later, rather than maintaining a separate specification tree. This keeps the spec in the same structural neighborhood as the code so both developers and coding agents can find it easily, reducing the risk of specifications drifting out of sync with implementation. _daily.dev helps developers track approaches like SBCE for keeping specs close to code._ ### What is the EARS format and how is it used to write testable requirements for AI coding agents? EARS (Easy Approach to Requirements Syntax) is used in SBCE and SDD4J to express requirements in a structured, testable English form, such as 'When a checkout is requested for an empty cart, the Business Component shall reject the request,' rather than vague statements like 'checkout should work correctly.' Each requirement gets a stable identifier, giving coding agents a deterministic verification boundary while still leaving implementation freedom. _daily.dev surfaces practical approaches like EARS for writing requirements agents can verify against._ ## Community discussion Top comments from developers on daily.dev. **@nark3d** · 0 upvotes > BCE and package-by-layer put different things in the spec's path and I can't see how one spec survives both without the adapter rewriting it. Once the adapter is doing that translation, what stops it drifting from the code it's meant to describe? The same visibility problem the post says living specs solve, moved one layer out. ## Similar posts on daily.dev - [adam bien's blog](https://daily.dev/posts/adam-bien-s-blog-etxdti7tn) · Adam Bien · 0 upvotes · 0 comments - [Spec-Driven Development Handbook: Build the Right Software Before You Write the First Line of Code](https://daily.dev/posts/spec-driven-development-handbook-build-the-right-software-before-you-write-the-first-line-of-code-kfxfp4ruu) · Syncfusion · 1 upvotes · 1 comments - [Spec-Driven Development: Why AI Is Bringing an Old Software Engineering Idea Back to Life](https://daily.dev/posts/spec-driven-development-why-ai-is-bringing-an-old-software-engineering-idea-back-to-life-jefbpvuoq) · The Serverless Edge · 193 upvotes · 25 comments - [Spec Driven Development: When Architecture Becomes Executable](https://daily.dev/posts/spec-driven-development-when-architecture-becomes-executable-nzxwl96bo) · InfoQ · 7 upvotes · 0 comments --- Tags: [#ai-agents](https://daily.dev/tags/ai-agents), [#java](https://daily.dev/tags/java), [#architecture](https://daily.dev/tags/architecture), [#spring-boot](https://daily.dev/tags/spring-boot), [#spec-driven-development](https://daily.dev/tags/spec-driven-development) [View this post on daily.dev](https://daily.dev/posts/from-spec-driven-development-to-living-specifications-in-java-projects-5drll9xwa) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"From Spec-Driven Development to Living Specifications in Java Projects","url":"https://daily.dev/posts/from-spec-driven-development-to-living-specifications-in-java-projects-5drll9xwa","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/from-spec-driven-development-to-living-specifications-in-java-projects-5drll9xwa"},"datePublished":"2026-09-04T06:02:04.022Z","dateModified":"2026-09-14T08:52:23.399Z","description":"An exploration of how Spec-Driven Development can evolve into 'Living Specifications' for Java projects using AI coding agents. The piece traces a journey from...","image":"https://media.daily.dev/image/upload/s--CxzD6vbw--/f_auto/v1722860399/public/Placeholder%2005","thumbnailUrl":"https://media.daily.dev/image/upload/s--CxzD6vbw--/f_auto/v1722860399/public/Placeholder%2005","isAccessibleForFree":true,"articleSection":"Foojay.io","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Foojay.io","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/1820f6a6ae944760aa322b67ed85f848","url":"https://daily.dev/sources/foojayio"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/from-spec-driven-development-to-living-specifications-in-java-projects-5drll9xwa","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":5},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"ai-agents,java,architecture,spring-boot,spec-driven-development","timeRequired":"PT14M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Foojay.io","item":"https://daily.dev/sources/foojayio"},{"@type":"ListItem","position":3,"name":"From Spec-Driven Development to Living Specifications in Java Projects"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/from-spec-driven-development-to-living-specifications-in-java-projects-5drll9xwa","comment":[{"@type":"Comment","text":"BCE and package-by-layer put different things in the spec’s path and I can’t see how one spec survives both without the adapter rewriting it. Once the adapter is doing that translation, what stops it drifting from the code it’s meant to describe? The same visibility problem the post says living specs solve, moved one layer out.","datePublished":"2026-09-16T11:51:40.364Z","url":"https://daily.dev/posts/5DrLL9Xwa#c-GR11teQGK","author":{"@type":"Person","name":"Adam","url":"https://daily.dev/nark3d","image":"https://avatars.githubusercontent.com/u/2162621?v=4"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/from-spec-driven-development-to-living-specifications-in-java-projects-5drll9xwa#faq","mainEntity":[{"@type":"Question","name":"What is SDD4J and how does it differ from SBCE for spec-driven development in Java?","acceptedAnswer":{"@type":"Answer","text":"SDD4J is an open-source Agent Skills workflow that adapts spec-driven development to a Java project's existing architecture through architecture adapters, unlike SBCE which anchors specifications specifically to the Boundary-Control-Entity (BCE) architectural style. SDD4J supports package-by-feature, package-by-layer, and BCE structures without requiring reorganization, and provides setup, new, apply, and verify commands, released via the soujava/agent-skills GitHub repository. Explore daily.dev for more on choosing spec-driven workflows that fit existing Java architectures."}},{"@type":"Question","name":"How does SBCE store specifications alongside Java code?","acceptedAnswer":{"@type":"Answer","text":"SBCE stores each Business Component's specification inside its own package-info.java file as Markdown Javadoc, requiring Java 23 or later, rather than maintaining a separate specification tree. This keeps the spec in the same structural neighborhood as the code so both developers and coding agents can find it easily, reducing the risk of specifications drifting out of sync with implementation. daily.dev helps developers track approaches like SBCE for keeping specs close to code."}},{"@type":"Question","name":"What is the EARS format and how is it used to write testable requirements for AI coding agents?","acceptedAnswer":{"@type":"Answer","text":"EARS (Easy Approach to Requirements Syntax) is used in SBCE and SDD4J to express requirements in a structured, testable English form, such as 'When a checkout is requested for an empty cart, the Business Component shall reject the request,' rather than vague statements like 'checkout should work correctly.' Each requirement gets a stable identifier, giving coding agents a deterministic verification boundary while still leaving implementation freedom. daily.dev surfaces practical approaches like EARS for writing requirements agents can verify against."}}]} ```