Conversation: LLMs and Building Abstractions

This process cannot be reduced to a static prompt for an LLM.
Reviewing LLM-generated code is rarely enough—you miss the deep thinking
that happens when you are coding yourself. In this stage, LLMs are most
valuable as brainstorming partners: they can suggest alternative designs
or ways of structuring code, but you should resist letting them generate
the core implementation. This phase belongs to the developer.

Richard Gabriel defines
abstractions as compression—encoding a well-established meaning
into a compact form, much like words in spoken language that stand for
larger concepts.

When we speak of a domain in a domain model, we often think only of the
functional or problem domain—Finance, Retail, Healthcare, and so on. But
in practice, functional knowledge alone is rarely enough to form truly
useful domain abstractions. There is always another domain at play: the
solution domain.

The solution domain is shaped by the architectural and technological
choices we make: whether we are building a web-based system or an
event-driven one; whether we rely on an in-memory data grid or a
relational database; whether our integration patterns involve synchronous
APIs or asynchronous messaging. These choices are not peripheral—they
shape the abstractions we create.

In most projects, the domain model and its vocabulary emerge at the
intersection of the functional domain and the solution domain. This is why
domain experts with a narrow functional focus cannot work in isolation.
Successful teams bring together people with deep functional expertise and
people with deep solution/technical expertise, working closely to shape a
shared language.

The Agile community has long recognized this: good vocabulary emerges from
collaboration. The way we build solutions, form domain models, and create
vocabulary has not changed with LLMs—and it still requires deliberate
effort. In fact, failing to create a shared domain vocabulary has even
greater costs when working with LLMs. Without it, the model has no
concrete reference points and must guess at meaning, often producing
results that miss the mark.