Software design does not fail because people lack ideas.
It fails because ideas are not tested against reality early enough.
One of the most powerful feedback mechanisms in software development is not architecture review, not UML diagrams, and not planning sessions.
It is writing code.
Actual coding is not merely implementation.
It is a continuous validation of the design against the domain.
When that feedback loop is weakened, design drifts away from reality. When it is removed entirely, software starts to “run in PowerPoint.”
AI-assisted development increases this risk dramatically.
Coding Is a Feedback Mechanism
There is a common misconception that coding is a mechanical activity — translating design into syntax.
In reality, coding is where design meets constraint.
When implementing a rich domain model:
Edge cases surface.
Invariants become harder than expected.
Responsibilities feel misplaced.
Names no longer fit.
Assumptions break.
Every friction point during implementation is feedback:
The model might be incomplete.
The model might be wrong.
The abstraction might be too shallow.
The business concept might be misunderstood.
Writing code forces the developer to confront the domain at a granular level.
This confrontation produces learning.
Coding builds understanding as much as it builds functionality.
The Domain Enables Functionality — It Is Not the Same
A common failure mode in story-driven development is conflating the domain with required behavior.
But the domain is not the list of user stories.
The domain is the conceptual structure that makes those stories possible.
Describing a business domain purely by its features is like describing an animal only by its behavior:
“It runs.”
“It eats.”
“It sleeps.”
Those are outputs.
They do not explain structure.
A domain model is the anatomy.
Stories are movements.
If the anatomy is wrong, movements will conflict.
Modeling Is Iterative Learning
In simple domains, the gap between initial model and actual domain may be small.
In complex domains, it rarely is.
Each new functional story reveals something:
A missing state.
An implicit rule.
A conflicting assumption.
An incorrect boundary.
A well-structured domain model absorbs that feedback.
It evolves deliberately.
If coding is happening, this evolution is continuous.
The model is constantly tested against real constraints.
Without coding involvement, that feedback loop weakens.
The Ivory Tower Effect
Ivory tower software development occurs when:
Strategic or senior decisions are made about detailed design,
Without direct involvement in implementation,
And without experiencing the friction of coding.
At that point, design decisions are evaluated abstractly rather than empirically.
Ideas look clean in diagrams.
They look coherent in slide decks.
But code exposes reality:
What is awkward?
What is redundant?
What does not compose?
What contradicts existing invariants?
Without that confrontation, design becomes speculative.
When feedback from implementers is ignored — especially when authority is hierarchical — the disconnect grows.
This is the real-world version of the “runs in PowerPoint” meme:
The system appears coherent conceptually, but its operational behavior tells a different story.
AI-Assisted Development: Removing the Friction
AI-assisted development changes the dynamic in a subtle but profound way.
Traditionally, flawed design reveals itself through implementation pain.
With AI:
Complex logic can be generated quickly.
Edge-case handling can be synthesized.
Boilerplate friction disappears.
Implementation obstacles shrink.
The system “works.”
But friction is not just an inconvenience.
It is feedback.
If AI absorbs that friction:
The developer experiences less resistance.
The design is challenged less directly.
Structural weaknesses can be papered over with generated complexity.
AI is extremely good at making something function.
It is not inherently responsible for questioning whether the underlying domain model is coherent.
If the model is weak, AI will happily implement increasingly elaborate logic around it.
This is where divergence accelerates.
Where Do the Lessons Go?
In traditional coding:
A developer struggles with an awkward method.
Realizes responsibility is misplaced.
Refactors the model.
Simplifies behavior.
Strengthens invariants.
That learning is embodied in the design.
With prompt-driven development:
The developer asks for feature X.
The AI produces working logic.
Tests are generated.
The story is complete.
But where did the design feedback go?
If the developer does not deliberately step back and re-evaluate the model, no automatic mechanism ensures that lessons learned during implementation are incorporated into domain structure.
AI can generate working code faster than teams can reflect on model integrity.
Velocity increases. Reflection often does not.
Preventing Divergence Across Stories
This becomes especially critical for core concepts like Order.
Across multiple user stories:
Orders gain new states.
Exceptions accumulate.
Special-case transitions appear.
Cross-cutting flags are introduced.
If each story is implemented additively — especially via prompts — divergence becomes likely:
Different stories interpret the same concept differently.
Invariants become conditional.
The model becomes a collection of patches.
To prevent this:
- Every new story must begin with model validation:
* Does the current `Order` model still represent reality?
* Are its invariants still coherent?
* Does the lifecycle still make sense?
- Implementation friction must be examined, not bypassed.
* If something feels awkward, the model may be wrong.
- AI must be used to refine models — not only extend behavior.
If stories accumulate faster than the model evolves, divergence is inevitable.
The Core Risk
Ivory tower development disconnects design from implementation reality.
AI-assisted development risks disconnecting implementation from conceptual learning.
Both weaken the feedback loop between:
Model
Code
Domain understanding
When that loop weakens, conceptual drift accelerates.
And when core concepts drift, conflicting business logic is only a matter of time.
AI as Amplifier — Not Villain
AI is not the enemy here.
It is an amplifier.
And amplification works in both directions.
In environments where teams already treat coding as a feedback mechanism — where friction triggers reflection and models evolve deliberately — AI becomes a powerful collaborator. It accelerates exploration, surfaces alternatives, fills knowledge gaps, and acts as an always-available discussion partner.
But in environments where development is already procedural — where stories are implemented sequentially without structural re-evaluation — AI does not change the underlying dynamic.
It scales it.
If the dominant habit is:
Add a story
Make it pass
Move on
Then AI simply increases throughput.
The structural weakness was already there.
AI makes it faster, cheaper, and less visibly painful.
The real danger is not AI.
The danger is bypassing reflection at scale.
AI removes mechanical friction.
That is progress.
But if the organization never had a practice of responding to conceptual friction, AI ensures that absence compounds silently.
It does not introduce drift.
It accelerates whatever discipline — or lack of discipline — already exists.
The Real Question
A reasonable counter-argument is:
“If the stories work, why does model divergence matter?”
Individually, they do work.
Each story passes its tests.
Each feature behaves correctly within its own context.
The problem is that stories are not independent.
They operate on shared concepts, shared data, and shared invariants.
In a real system — whether a distributed microservice landscape or a monolith — every story modifies the same underlying domain.
And when each story subtly reshapes that domain without structural re-evaluation, coherence erodes.
The result is not immediate failure.
It is unpredictability.
Cancellation rules interact strangely with refund logic.
Fraud review states conflict with shipment transitions.
Administrative overrides bypass invariants assumed elsewhere.
Flags introduced for one use case leak into others.
Nothing is obviously broken.
But behavior becomes conditional, context-dependent, and difficult to reason about.
The system no longer behaves as a unified model - It behaves as accumulated exceptions.
A rich domain model exists precisely to prevent this.
It ensures that integration is intentional — not accidental.
It provides a single, coherent definition of:
What an Order is
What states are valid
What transitions are legal
What invariants must always hold
Without that coherence, stories remain locally correct but globally inconsistent.
And that inconsistency compounds.
Final Thought
Software rarely collapses because individual features fail.
It becomes fragile because the relationships between features stop making sense.
Local correctness is easy to achieve.
Global coherence is not.
A system can pass every story-level test and still drift into unpredictability — not because the code is broken, but because the underlying model has fragmented.
When shared concepts evolve without deliberate validation, integration becomes accidental.
And accidental integration always produces conditional behavior, hidden coupling, and contradictory assumptions.
Coding is the mechanism that keeps this from happening.
It forces ideas to confront constraints.
It exposes where invariants strain.
It reveals when abstractions no longer hold.
That confrontation is not an inconvenience.
It is the stabilizing force of design.
AI does not eliminate that force — but it can soften it.
When friction is absorbed automatically and stories ship without structural pause, learning decouples from implementation.
Velocity rises.
Reflection does not necessarily follow.
The result is not immediate failure.
It is gradual loss of predictability.
And predictability is what makes software reliable, extensible, and economically sustainable.
AI will continue to increase throughput.
The question is whether teams will increase structural discipline at the same pace.
Because in the end, software does not degrade when ideas are ambitious.
It degrades when feedback is ignored.
And the most important feedback loop in software development is still the one between:
Model.
Code.
Reality.
Preserve that loop — and AI becomes a multiplier of clarity.
Neglect it — and AI becomes a multiplier of drift.
Top comments (0)