<!-- mobian-agent-page publisher="dailydev" canonical="https://daily.dev/posts/adam-bien-s-blog-voduxcgeb" -->

---
title: adam bien's blog | daily.dev
description: SBCE (Spec-Driven BCE) is a workflow where every capability is declared as a single spec living in a Java package's `package-info.java` file using Markdown...
canonical: https://daily.dev/posts/adam-bien-s-blog-voduxcgeb
twitter:card: summary_large_image
twitter:site: @dailydotdev
og:type: website
og:site_name: daily.dev
og:title: adam bien's blog | daily.dev
og:description: SBCE (Spec-Driven BCE) is a workflow where every capability is declared as a single spec living in a Java package's `package-info.java` file using Markdown...
og:url: https://daily.dev/posts/adam-bien-s-blog-voduxcgeb
og:image: https://api.daily.dev/og/posts/VODuXcGeB.png
og:image:alt: adam bien's blog
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.

# adam bien's blog

**[Adam Bien](https://daily.dev/sources/adam-bien)** · 3 min read · 1 upvotes · 0 comments

## Summary

SBCE (Spec-Driven BCE) is a workflow where every capability is declared as a single spec living in a Java package's `package-info.java` file using Markdown JavaDoc (JEP 467). The spec defines boundary operations and EARS requirements in a transport-neutral, 'what not how' style. It ships as an AIrails skill with two modes: `/sbce new` to declare and scaffold a new capability, and `/sbce apply` to converge code to the spec by generating missing methods/tests and surfacing undeclared code as drift. The approach relies entirely on established standards (EARS, JavaDoc, BCE pattern) already in LLM weights, keeping the skill under 4,000 tokens. BCE sets architecture invariants while SBCE owns the workflow on top.

## Full article

daily.dev links to this article rather than hosting it. Read it at the original source: <https://adambien.blog/roller/abien/entry/zbaseline_the_web_platform_snapshot_fetcher>

## Questions this post answers

### What is SBCE in the context of Boundary-Control-Entity architecture?

SBCE, short for Spec-Driven BCE, is a workflow where every capability is declared as a single spec placed in the package-info.java (or package-info.md for web components) of exactly one Boundary-Control-Entity business component. It ships as an AIrails skill called /sbce, requiring no CLI and no dependencies, with commands 'new' to declare a capability and 'apply' to converge code with the spec.

_daily.dev surfaces workflows like this for teams tracking new approaches to spec-driven architecture._

### How are requirements written in an SBCE package-info.java spec?

Requirements are written using the EARS notation (Easy Approach to Requirements Syntax), with each statement given a stable id such as R1.1 or R1.2 that traces to at least one test embedding that id. For example, a requirement might state that when a name is submitted the boundary shall return a greeting containing that name, or that a blank name shall be rejected.

_developers formalizing requirements in code comments can compare EARS-based patterns like this on daily.dev._

### Why does the SBCE skill avoid inventing a custom spec DSL for LLMs?

Because every notation used—EARS for requirements, JavaDoc and package-info.java for placement, JEP 467 for markdown syntax, Mermaid for diagrams, and the Boundary-Control-Entity pattern itself—is an established standard already present in LLM training data. This lets the entire skill fit in roughly 4,000 tokens of SKILL.md, since a self-invented DSL would burn thousands of extra tokens per session.

_daily.dev helps developers evaluating LLM skill design trade-offs like token efficiency stay informed._

## Similar posts on daily.dev

- [From Spec-Driven Development to Living Specifications in Java Projects](https://daily.dev/posts/from-spec-driven-development-to-living-specifications-in-java-projects-5drll9xwa) · Foojay.io · 5 upvotes · 1 comments
- [From Java EE to Quarkus and LLMs: Adam Bien’s Playbook for Boring, Future‑Proof Systems](https://daily.dev/posts/from-java-ee-to-quarkus-and-llms-adam-bien-s-playbook-for-boring-future-proof-systems-0metu7xbn) · InfoQ · 16 upvotes · 0 comments

---

Tags: [#java](https://daily.dev/tags/java), [#architecture](https://daily.dev/tags/architecture), [#spec-driven-development](https://daily.dev/tags/spec-driven-development)

[View this post on daily.dev](https://daily.dev/posts/adam-bien-s-blog-voduxcgeb)

```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":"adam bien's blog","url":"https://daily.dev/posts/adam-bien-s-blog-voduxcgeb","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/adam-bien-s-blog-voduxcgeb"},"datePublished":"2026-07-16T03:18:35.268Z","dateModified":"2026-09-14T06:00:54.793Z","description":"SBCE (Spec-Driven BCE) is a workflow where every capability is declared as a single spec living in a Java package's `package-info.java` file using Markdown...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/d365e8cabb5d95ba36aaa092c23f211d?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/d365e8cabb5d95ba36aaa092c23f211d?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Adam Bien","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":"Adam Bien","logo":"https://media.daily.dev/image/upload/s--CInnAL-q--/f_auto,q_auto/v1773644276/logos/adam-bien?_a=BAMAMiiu0","url":"https://daily.dev/sources/adam-bien"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/adam-bien-s-blog-voduxcgeb","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"java,architecture,spec-driven-development","timeRequired":"PT3M"}
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Adam Bien","item":"https://daily.dev/sources/adam-bien"},{"@type":"ListItem","position":3,"name":"adam bien's blog"}]}
{"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/adam-bien-s-blog-voduxcgeb#faq","mainEntity":[{"@type":"Question","name":"What is SBCE in the context of Boundary-Control-Entity architecture?","acceptedAnswer":{"@type":"Answer","text":"SBCE, short for Spec-Driven BCE, is a workflow where every capability is declared as a single spec placed in the package-info.java (or package-info.md for web components) of exactly one Boundary-Control-Entity business component. It ships as an AIrails skill called /sbce, requiring no CLI and no dependencies, with commands 'new' to declare a capability and 'apply' to converge code with the spec. daily.dev surfaces workflows like this for teams tracking new approaches to spec-driven architecture."}},{"@type":"Question","name":"How are requirements written in an SBCE package-info.java spec?","acceptedAnswer":{"@type":"Answer","text":"Requirements are written using the EARS notation (Easy Approach to Requirements Syntax), with each statement given a stable id such as R1.1 or R1.2 that traces to at least one test embedding that id. For example, a requirement might state that when a name is submitted the boundary shall return a greeting containing that name, or that a blank name shall be rejected. developers formalizing requirements in code comments can compare EARS-based patterns like this on daily.dev."}},{"@type":"Question","name":"Why does the SBCE skill avoid inventing a custom spec DSL for LLMs?","acceptedAnswer":{"@type":"Answer","text":"Because every notation used—EARS for requirements, JavaDoc and package-info.java for placement, JEP 467 for markdown syntax, Mermaid for diagrams, and the Boundary-Control-Entity pattern itself—is an established standard already present in LLM training data. This lets the entire skill fit in roughly 4,000 tokens of SKILL.md, since a self-invented DSL would burn thousands of extra tokens per session. daily.dev helps developers evaluating LLM skill design trade-offs like token efficiency stay informed."}}]}
```

