Software development is often described as “building systems”.
But there are two professions that might describe the job much better: writing a book and designing a house.
Both involve creating something coherent out of many parts.
Both require understanding purpose before execution.
And both reveal a common mistake that appears surprisingly often in modern software development.
To see why, imagine two professionals: a ghostwriter and a house builder.
The Ghostwriter Version of Software Development
Imagine you hire a ghostwriter to write a book based on your ideas.
You send them fragments:
a story about a childhood memory
a chapter about leadership
a few anecdotes about business
a paragraph about innovation
a repeated explanation of a concept you already mentioned earlier
A bad ghostwriter simply writes everything down exactly as provided.
The result is technically correct. The grammar is fine. The sentences are clear.
But the book becomes a mess:
topics overlap
concepts repeat
arguments contradict each other
the narrative jumps randomly between ideas
Nothing ties the material together into a coherent story.
The ghostwriter has focused on transcription, not authorship.
Unfortunately, software development is sometimes practiced in a very similar way.
A team receives a series of user stories:
“Customers should be able to create orders.”
“Orders can have discounts.”
“Admins can modify customer data.”
“Orders must be validated before submission.”
Each story is implemented somewhere in the codebase. A controller here, a service there, a validation rule somewhere else.
Every story is technically implemented.
But over time the system starts to show symptoms:
business rules appear in multiple places
behavior becomes inconsistent
changes require touching many unrelated components
nobody is entirely sure where certain logic belongs anymore
The system becomes the equivalent of the badly written book: a collection of fragments without a coherent narrative.
The problem is not coding skill. The problem is the absence of structure.
The House Builder Version of Software Development
Now imagine designing a wooden house.
But instead of starting with how people will live in it, the builders start with their tools.
The plumber places the bathroom where the pipes are easiest to install.
The electrician places the kitchen where wiring is convenient.
The carpenter builds bedrooms wherever the structure is simplest.
Each professional does excellent work.
The plumbing is perfect.
The wiring is flawless.
The construction is solid.
But when the house is finished, something feels very wrong.
The dining room is on the opposite end of the kitchen.
The shower is installed in the kitchen because the pipes were already there.
The bedrooms are nowhere near the bathroom.
Every part of the house is technically well built.
But the house does not work as a house.
No one began by asking the most important question:
How will people live here?
The same thing happens in software development when architecture is driven primarily by tools and technologies.
Discussions revolve around:
frameworks
infrastructure
microservices
deployment pipelines
cloud platforms
All important tools.
But they are construction techniques, not design principles.
Without understanding how the system is supposed to behave as a whole, even the best tools can produce a system that is technically impressive but conceptually broken.
What’s Missing: Coherent Design
Both examples expose the same underlying problem.
The ghostwriter fails because they never discovered the story.
The house builders fail because they never understood the purpose of the house.
In software engineering, the equivalent is failing to understand the domain.
User stories describe fragments of behavior.
But if every story is simply implemented as-is, the system slowly loses coherence.
Engineering cannot start with implementation. It must start with understanding.
What activities exist in the domain?
What concepts matter?
What rules must always hold?
Where should responsibilities live?
Only when those questions are answered does the structure of the system begin to emerge.
Enter the Domain Model
This is where the domain model becomes essential.
A domain model acts as a responsibility localizer and logic contextualizer.
Instead of scattering behavior across the codebase, the model provides structure:
concepts are represented explicitly
rules live with the concepts they govern
responsibilities have clear homes
When a new user story arrives, the question is no longer:
“Where should we add this piece of code?”
Instead the question becomes:
“What does this story mean for our understanding of the domain?”
Sometimes the answer is simple.
Sometimes it requires adjusting the model itself.
But the goal remains the same: preserve conceptual integrity.
Without that integrity, software inevitably turns into the badly written book or the badly designed house.
The Risk of AI
AI-assisted coding is incredibly powerful.
It can generate code, implement features, suggest refactorings, and remove enormous amounts of repetitive work. Used well, it is an enormous productivity accelerator.
But AI is strongest at local implementation.
It excels at doing exactly what it is asked: implementing a function, adding a feature, modifying an existing piece of code. In that sense it behaves very much like the literal ghostwriter who writes the paragraph that was requested, or the contractor who builds a perfectly constructed room.
What AI does not replace is modeling the domain.
It does not determine:
what the core concepts of the system should be
where responsibilities belong
how rules should be structured
how the system should reflect the purpose of the business
Those decisions require understanding intent and discovering structure. They are design activities.
AI can dramatically accelerate the technical execution of a system. But it cannot replace the need for coherent design.
Otherwise we risk the same outcomes as before: a technically correct book without a story, or a well-built house that no one can live in.
Conclusion
In an interesting way, the rise of AI coding tools highlights something that has always been true in software development.
Many teams have already been operating primarily at the level of feature implementation, while the deeper design work was often implicit, inconsistent, or missing entirely.
Custom software is essentially a one-off prototype. There is no reference design to compare it to. There is no second version of the same system built by another team. There is only one implementation: the one that ends up running in production.
That makes design mistakes difficult to spot early.
A book with a broken narrative may only reveal its problems once the entire manuscript is finished.
A badly designed house may only reveal its flaws once people try to live in it.
Software is no different.
Which is why the design phase — understanding the purpose of the system and shaping a coherent domain model — cannot be skipped.
The ghostwriter must understand the story.
The architect must understand how the house will be lived in.
And the software engineer must understand the domain before writing the code that brings it to life.
Top comments (0)