The First Draft Wins, Even When AI Writes It

When AI should draft your Context Map, and when it should only critique it

Part of the series Domain-Driven Design Meets AI.

In a negotiation, the side that names the first number usually walks away with the better deal. Galinsky and Mussweiler showed it in three experiments: first offers strongly predicted the final settlement [@galinsky2001firstoffers].

A Context Map is a negotiation too, even if nobody in the room calls it one. And AI has just made the first draft free.

So before you paste your EventStorming board into a chat and ask for a Context Map, it is worth asking a question that has little to do with AI. Who should bring the first draft, and what happens to the discussion once they do?

A map of influence, not of data

Earlier posts in this series found Bounded Contexts in Domain Stories, on the EventStorming board, and in the pivotal events where responsibility changes hands. What those techniques do not tell you is how the contexts depend on each other once they are built.

That is the job of the Context Map [@evans2003ddd]. Every Bounded Context appears exactly once, and the arrows show who depends on whom.

Upstream and downstream are easy to misread. They do not describe the direction of the data. They describe the direction of influence: the upstream team can change its model without asking, and the downstream team has to follow [@dddcrew2020contextmapping].

For every arrow, the teams choose a pattern. The upstream context can offer an Open Host Service, one documented protocol for all consumers. The downstream context can protect its own model behind an Anti-Corruption Layer, or simply adopt the upstream model as a Conformist. In a Customer/Supplier relationship, the downstream team has a say in what it gets. Two contexts can share a Shared Kernel, or go Separate Ways [@evans2003ddd; @evans2015reference].

If nobody answers these questions explicitly, the first integration answers them by accident.

Why the discussion goes in circles

Choosing the patterns is tedious, and the discussion tends to go in circles. That is not a sign of an inexperienced team. The patterns combine rather than exclude one another, and the literature does not agree on how to combine them [@kapferer2020modelsward; @dddcrew2020contextmapping]. Worse, the real subject is which team has influence over which other. A Context Map is partly a picture of how the politics are played [@dddcrew2020contextmapping].

Open discussion is a weak instrument for that kind of question. In a classic study of strategic decision making, groups working toward consensus reached worse recommendations than groups working under structured challenge, such as a devil's advocate. The consensus groups were also more satisfied with their result [@schweiger1986group].

That is the situation in which we now hand the problem to an AI.

The case for an AI draft

A draft gives a stuck discussion something to react to. In an online experiment, writers who received story ideas from an LLM wrote stories that were judged more creative, better written, and more enjoyable, and the least creative writers gained the most [@doshi2024genai].

Reacting to something is easier than staring at an empty wall. AI as a Design Partner called this role the Drafter, and for a Context Map it is tempting to use it.

The price of a draft

The same experiment found that the AI-assisted stories were more similar to each other [@doshi2024genai]. In a user study on creative ideation, people working with ChatGPT produced a more homogeneous set of ideas across the group, and they felt less responsible for the ideas they came up with [@anderson2024homogenization].

A draft anchors. Everyone converges on it, and nobody quite owns it.

There is a second catch, and it is specific to Context Maps. A recent preprint let an LLM derive microservice architectures from textual requirements for two small systems. It identified the services well, with F1 scores between 0.79 and 0.97. The interactions between the services were harder: F1 between 0.61 and 0.82, and without examples in the prompt, fewer than half of the dependencies it proposed were correct [@albuquerque2026requirements]. The arrows are the weak spot, and the arrows are what a Context Map is about.

What happened when the AI drafted our map

The running example of the book is Larder, a recipe-sharing platform where cooks can ask a Grandma Avatar, a Chef, or the Community for help while they plan or cook a meal. We gave the EventStorming board to an AI with a Context Mapping skill and asked for a map (full chat).

The Context Map drafted by AI from the EventStorming board. The dotted arrows mark the gaps it found.

The draft looked thorough. Every arrow carried a pattern, and the AI flagged seven gaps: places where, in its view, information should cross a border but nothing on the board carried it.

Some of those gaps were real, and the team closed them with new arrows. Many were not what they seemed.

• Nothing reads Cook was no gap. The identity of the cook travels as a JWT in the header of every synchronous call. That is an architecture principle, and architecture principles do not appear on an EventStorming board.
• Nobody is told a request exists was real, but the answer was a Notification context that nobody had drawn yet.
• Nothing identifies the meal misread the domain. The meal exists on the stove, not in the app. It is identified by the recipe and the cook.

The patterns changed as well. The AI had labeled most arrows Customer/Supplier or Conformist. The team replaced nearly all of them with Open Host Service and agreed on an API Contract First approach, so that every team builds against one documented interface and can release without waiting for its consumers.

The same map after the team's rework. The changes are marked in red.

The rework was tedious. Almost every correction came from knowledge the board did not contain, or from a misunderstanding of what it did contain. The AI could not have known better. But the discussion had turned into correcting somebody else's picture instead of drawing our own.

What happened when the team drew it first

So we tried it the other way around. The team derived the map from the board, one rectangle per Bounded Context, and discussed each dependency.

Drawing it surfaced what the board had not shown. Recipes needed an owner, so the team introduced a Recipe Catalog. While discussing how a cook thanks the people who helped, the team realized that helpers have to consent before they can be named, so Consent Management appeared. Somebody has to tell the community or the chef that a request is waiting, so Notification appeared too. The Grandma Avatar became an external process behind an Anti-Corruption Layer.

The Context Map drawn by the team.

Then the AI got the board and the team's map with one job: find where the map claims something the stickies do not support (consistency skill).

Its sharpest finding was about a single word. The map gave Ingredients to the Recipe Catalog. On the board, however, Meal Planning writes Ingredients when a cook substitutes one, and Cooking Assistance reads them. The AI suspected two different things wearing one word, the ingredient list of a recipe and this cook's list for tonight's dinner, and proposed a question to settle it:

When a cook substitutes walnuts for pine nuts, does that change anything in the catalogue?

If not, they are two terms. The team leaned toward keeping the word, because the Visual Glossary already states that a substitute is an ingredient, and each context can live with its own meaning. Whether the AI was right matters less than what the question did. It turned an assumption into a decision.

The rule

When the teams can reach each other cheaply, let them draw the map and give the AI the critic's role. The conversation produces the commitment [@evans2015reference], and the review finds what the room agreed on too quickly. Ownership stays with the people who will have to live with the arrows.

When they cannot, let the AI draft, and know that you are setting the anchor. Different companies, a vendor and its client, communication that runs through contracts and scheduled meetings: here the negotiated route is out of reach. Even consumer-driven contracts depend on consumers being able to tell the provider what they need [@robinson2006cdc]. An AI draft gives both sides a concrete artifact to react to instead of a series of workshops nobody can fund.

But a draft brought across an organizational boundary is not neutral. Whoever brings it sets the anchor, at least where both sides treat the question as zero-sum [@galinsky2001firstoffers]. Expect the final map to end up closer to your draft than to your counterpart's view, and expect your counterpart to notice. Give somebody the explicit job of arguing for a different pattern [@schweiger1986group]. And if you are the one receiving the draft, the same research offers the antidote: the anchor lost its pull when negotiators focused on their own target and on the other side's alternatives [@galinsky2001firstoffers].

Draft what is known, critique what must be agreed

Once the map was agreed, the team needed a Bounded Context Canvas for each context [@dddcrew2019bcc]. A canvas mostly collects what already exists in the Context Map, the EventStorming board, and the Visual Glossary. That is exactly the kind of work to hand over, and the AI drafted all canvases with a canvas skill. The result needed only small adaptations.

Put next to each other, the two experiences give a rule that reaches beyond Context Maps. Let AI draft what the team already knows. Let it critique what the team still has to agree on.

AI has made the first draft free. It has not made it neutral.

Next in this series: The Word That Breaks Everything — why the Ubiquitous Language drifts from the first day of implementation, and why AI makes a good referee between the Domain Stories, the Visual Glossary, and the API schema.

This series grew out of my work on the book DDD Meets AI, published by Springer Nature in February 2027.

---