Aaron Murray | @funkytek | July 2026
In 2017, a paper taught machines attention. Attention taught them to code. By 2024, the world was Vibe Coding (even before Karpathy coined the term) and researchers from Cambridge and Microsoft named the destination for development: Requirements Are All You Need; end users owning the software lifecycle from conception to deployment, armed with nothing but requirements, by 2030. The issue is requirements are the hard part.
<aside> đź’ˇ
Humans are generally bad at writing specifications, but we’re great at storytelling- in fact, we're wired for it.
</aside>
I've run modeling workshops for decades, mostly inspired by Domain Driven Design-adjacent tools. They work. Domain experts love them, but the output dies in a tool like Miro. Every method ends in a handoff to developers, and the handoff is where meaning dies.
Vibe coding industrialized the problem. Set aside the security breach postmortems; the quiet failures are much worse. A good prompt is a domain model, then it's discarded in a chat log. Nothing grounds a term across prompts: "Order" is a purchase in prompt 1 and a sort in prompt 47; meaning is re-guessed from prose, every prompt, every agent, every time. And validation lands on the wrong party: domain experts can't validate code, developers can't validate domains, LLMs can't reliably do either. A survey of 1,000+ papers on AI-assisted development found five development models emerging from Vibe Coding. None of them included domain modeling.
The problem was never "we can't generate code." It's "we don't know what we want" or “We know what we want but we can’t define it.” AI didn't fix that. It made it faster to build the wrong thing.
Earlier this year I gave a talk at HalfStack Conf titled "From Vibe Coding to Vibe Modeling: Domains, DSLs, Determinism and You," where I presented a naive DSL: a Domain Storytelling-inspired grammar that imposes structure around writing specs. It looked like this:
Customer submits Order to System
System validates Order against Inventory
System confirms Order to Customer
The grammar fit on one slide: capitalization marks the nouns, position assigns the roles, first noun is always the Actor plus a few more rules for properties, compounds, and annotations. The results were not terrible. With this simple DSL we could deterministically extract Actors, Work Objects and actions- no LLM in the parse loop. Eight lines of story produced an entity list, a relationship graph, and an inferred state machine with the open promise of verifiability: Order → Submitted → Validated → Charged → Confirmed → Shipped.
The talk's last open question was meant as a provocation: are we building a DSL or an ontology language?
"Customer submits Order to System" parses identically whether Customer is a person, a company, or a database table. The parse gives structure, not meaning. Is Order a commitment that must eventually be balanced? Can a Seat sell twice? The grammar has no opinion. A grammar catches what's malformed. It can never catch what's missing: the unguarded transition, the unbalanced commitment, the rule nobody said out loud. Missing is the whole game.
A DSL without an ontology is a parser without semantics. The answer to my own question: an ontology language wearing a DSL's grammar.
But we kept generating.
By 2026 the premise had won everywhere. Kiro, spec-kit, Tessl, the spec-driven cli tool wave, Sean Grove’s "The New Code", all treat captured intent as the source of truth and code as, in GitHub's own words, "the last-mile approach."
Then everyone hands the artifact to a generator and the last mile eats them. Böckeler's taxonomy: spec-first, spec-anchored, spec-as-source, found that in practice everything collapses to spec-first: the spec drives one task, then rots. The one tool aspiring to spec-as-source (Tessl) regenerated different code from the same spec, and by January had pivoted to agent governance. The deterministic wing, Cabot's vibe modeling, MDA before it, GeneXus since 1988, makes the translator reliable but keeps the second artifact, the escape hatches, and the question it can't answer: who checks the model in a language only developers read? Its own 2026 follow-up re-admits LLM codegen wherever templates fall short.