Faster AI needs better problems, clearer boundaries, and stronger human judgment.
Faster Action Requires Better Understanding
We usually think about AI guardrails after AI enters the picture.
We check its answers and review its code. We limit what agents can access. We create approval rules around important decisions.
Those protections matter. But Sheen Brisals points toward an earlier guardrail in Fast Code, Fragile Systems.
It exists before anyone writes the prompt.
It is understanding.
Before AI can safely accelerate development, someone must understand the problem. Someone must know what belongs together and what should remain separate. Someone must establish the language and boundaries that give the work structure.
AI can help us move faster.
It cannot tell us whether we are moving in the right direction.
Domain Driven Design Starts Before the Code
Brisals returns to Domain Driven Design for this reason.
DDD begins with the business, not the technology. It asks what the organization actually does before deciding how software should represent it.
Which activities make the business distinctive? Which ones support that core? Which functions are common enough to buy rather than build?
Even language matters.
The word "order" can mean a customer purchase in one context. In shipping, the same word may refer to a delivery package. Treat those meanings as identical, and confusion enters the system.
DDD therefore creates bounded contexts.
Within each boundary, a particular model and vocabulary apply. Cross that boundary, and another model may become appropriate.
The boundary protects meaning before software encodes it.
The First Diamond Is Also a Guardrail
The Double Diamond Framework gives us a broader way to understand this discipline.
The first diamond concerns understanding.
Discover → Define
We open the problem before narrowing it. We examine the situation and gather useful context. We explore relationships and challenge assumptions. Then we define what actually needs solving.
Only then do we enter the second diamond.
Develop → Deliver
Here we explore possible solutions. We test alternatives. Eventually, we choose and deliver something.
AI can dramatically accelerate parts of this second diamond.
That makes the first diamond more important, not less.
A weak first diamond gives AI a poorly understood problem. A powerful second diamond then accelerates whatever follows.
We should not be surprised when the result is fragile.
Speed Is a Multiplier, Not a Direction
This changes how we should think about AI speed.
Speed tells us how quickly something moves. It does not tell us where it should go.
Put powerful AI inside a well-understood problem. Give it meaningful boundaries and clear responsibilities. Its speed can multiply human capability.
Put the same technology inside a confused problem. Give it unclear boundaries and contradictory meanings. Its speed can multiply confusion.
The accelerator is powerful in both cases.
What came before the acceleration makes the difference.
Weak understanding + fast execution = accelerated fragility.
Strong understanding + fast execution = accelerated capability.
The problem is not speed itself.
The problem is accelerating before understanding.
AI Removes an Old Speed Limit
Poorly designed systems existed before generative AI.
So did unclear responsibilities, tangled dependencies, weak architecture, and confused business models.
AI did not invent these problems.
It changed how quickly we can turn them into working systems.
Software development once contained considerable natural friction. Coding required time. Building alternatives required resources. Connecting systems required effort.
That friction did not make organizations wise. But it limited how quickly weak decisions could become software.
AI removes part of that limit.
A badly framed feature can now be built quickly. A weak architecture can grow rapidly. Poor assumptions can spread through generated code before anyone understands their consequences.
AI therefore makes upstream thinking more valuable.
The Guardrail Before the Prompt
This is where our usual conversation about AI governance may begin too late.
We often focus on controlling what AI produces.
But some failures begin before production.
The wrong problem was defined. Important context was excluded. Responsibilities were unclear. Two teams meant different things by the same word. A boundary was drawn in the wrong place.
A clever prompt cannot reliably repair those failures.
The first guardrails are therefore cognitive and organizational.
Understand the domain. Create shared language. Separate concerns. Clarify ownership. Draw meaningful boundaries. Define the problem.
Then ask AI to help.
This does not make later safeguards unnecessary. AI still requires review, testing, security, governance, and human judgment.
But downstream controls cannot replace upstream understanding.
When Doing Gets Cheaper, Judgment Becomes More Valuable
This points toward a larger change in human work.
AI makes many forms of production cheaper and faster. We can generate more code, documents, designs, analyses, and alternatives.
But abundance creates another problem.
Someone must choose.
Which answer fits reality? Which solution belongs here? Which assumption is wrong? Which alternative deserves development?
As producing possible answers becomes easier, judging those answers becomes more important.
The scarce human capability moves upstream.
It moves toward understanding, framing, boundaries, and judgment.
Humans Still Draw the Lines
DDD gives software engineers a disciplined way to draw some of those lines.
But the underlying capability reaches beyond software.
Complexity requires boundaries.
Organizations divide responsibilities. Governments divide authority. Scientific disciplines define concepts. Communities establish rules. People establish boundaries around responsibility and relationships.
Good boundaries make complexity manageable.
Bad boundaries can create more of it.
AI can operate rapidly within the structures we give it.
Humans must still judge whether those structures make sense.
That may become one of our most important capabilities in the AI age.
Not merely knowing more.
Not merely producing faster.
But knowing where to draw the lines.
Build the Guardrail Before You Accelerate
AI gives us extraordinary execution capability.
That makes it tempting to begin with the tool.
Generate the code. Build the agent. Automate the workflow. See what happens.
Domain Driven Design reminds us that another kind of work comes first.
Understand what exists. Understand what matters. Understand what belongs together. Understand what must remain separate.
Then build.
The Double Diamond Framework tells the same story more broadly.
Strengthen the first diamond before accelerating the second.
The fastest system is not necessarily the strongest system. Speed only helps when direction deserves acceleration.
Sometimes the most important AI guardrail is already in place before AI receives its first prompt.
It is the quality of the thinking that defined the problem.
Credits
Inspired by Sheen Brisals's Fast Code, Fragile Systems! Why domain thinking, business context, shared language, and clear boundaries still matter in the age of AI?, published on Medium on July 3, 2026.
The discussion of Domain Driven Design draws from Brisals's explanation of domain decomposition, ubiquitous language, subdomains, and bounded contexts.
Tags
#Artificial_Intelligence #Domain_Driven_Design #Software_Engineering #Systems_Thinking #Critical_Thinking
No comments:
Post a Comment