For the last decade, I’ve watched our industry wage a quiet civil war: Design-First versus Code-First (which I prefer to call Describe-First).
On one side, the Code-First crowd prioritizes speed. They build features fast, write the code, and let tools automatically scrape their source annotations to describe the interface after the fact—think Swagger or OpenAPI auto-generation. It’s fast, but it’s completely siloed.
On the other side are the Design-First purists—a camp I’ve firmly stood in for a long time. We insist on writing the specification contract before we touch a single line of code. We argue that designing the boundary upfront ensures team alignment, parallel development, and ecosystem stability.
For a long time, it felt like Design-First was finally winning the argument for enterprise architecture.
Then, AI agents arrived. And I watched our collective engineering discipline go right out the window.
The Great Regression: Describing in the Dark Lately, when I look under the hood of modern "agentic AI" implementations, I don't see pristine design contracts. I see a sprawling, chaotic sandbox of natural language text.
Instead of designing strict system boundaries, I see engineering teams stuffing core business rules, data formatting requirements, state management rules, and edge-case handling directly into prompt strings.
We aren't designing systems anymore; we are describing desired behaviors to a black box and praying for a consistent output. In my view, we have regressed past Code-First, straight into Prompt-First Chaos.
And this shift has introduced a quiet, systemic killer into enterprise software: Prompt Bias.
What I Mean by Prompt Bias When you bury your business logic inside a prompt string, your application's execution becomes highly biased based on three volatile variables:
Semantic Bias (How it’s phrased): I’ve seen a slight change in a user’s wording completely alter how an LLM interprets a business rule embedded in a prompt.
Model Bias (The Underlying LLM): A prompt that works flawlessly on an advanced model might completely drop a critical regulatory constraint when run on a smaller, cheaper, or updated model. Your logic is tightly coupled to a specific vendor's weights.
Contextual Drift: Because natural language prompts lack clear, structural boundaries, the AI is left to "guess" state changes and fill in the gaps when a complex, multi-scenario business process hits an edge case.
My philosophy is simple: if your system's adherence to compliance, pricing rules, or workflow logic changes based on the phrasing of a sentence, you don’t have an architecture. You have a liability.
Why Standard Spec-Driven Design Failed Us I understand why we fell into this trap. Traditional Spec-Driven Design (SDD) completely failed us the moment it met AI.
Standard SDD forces us to model the track, not the journey. It forces us to define static endpoints (POST /api/v1/orders) and rigid JSON schemas. But AI agents don't think in terms of linear endpoint chaining; they need to dynamically orchestrate capabilities to achieve an objective.
Faced with a rigid spec that choked on dynamic agent behavior, I saw engineers bypass the spec entirely and turn to the wild west of prompting just to get things moving.
Moving From "Text Strings" to "Outcome Governance" I don't believe we can build the future of software on a foundation of shifting sand. We need a paradigm that captures the flexibility an AI agent requires, without sacrificing the deterministic governance the enterprise demands.
We don't need better prompts. We need to move away from instructing an AI how to behave via text strings, and move toward an architecture that explicitly models the Context and enforces the Outcome.
To me, true "Design-First" architecture in the era of AI means designing an immutable, version-controlled contract of business intent that remains completely independent of the execution model.
In my next post, I’m going to take a hard look at why standard Spec-Driven Design traps engineering teams in rigid silos, and why prompt sandboxes lead to operational chaos. Then, I'll share how I approach the middle ground: Outcome-Driven Context Modeling (ODCM).