integrity constraint ▁

The one where Claude was absolutely right

2026-06-06

A short story on how my relationship to Claude (and event-driven architecture) changed while walking my dog.

What's old is new again#

The one thing that excites me most about the "AI revolution" in the software industry, is the fact that all the old development paradigms that always intrigued me, but were hard to justify economically, are suddenly waking up like sleeping giants.

I have always been bullish on Test Driven Development. The act of formulating a test case has always been less about guarding against future regressions, and more about achieving mental clarity and a fast iteration loop while actually writing the code[1]. The actual difference that coding agents made here, is that — these days — nobody is questioning me any more.

Over the last 15 years or so, I had periodic urges to establish Behavior Driven Development at the places I worked. I even gave a talk at Drupal GovCon 2020 on that topic[2]. But it never stuck long term. Mainly because I failed to convince my coworkers to chime in. Gherkin scenarios are about creating shared understanding across collaborators. The fact that they can be turned into automated acceptance tests is just a convenient accident[3], so without anybody else giving a damn, maintaining them was an exercise in futility. But now my biggest problem is to create a shared understanding with the clanker, and for the last six months, behavioral scenarios do a marvelous job at exactly that. The agent maps out edge cases, surfaces conflicts, and then implements the step definitions as its own feedback loop.

Invigorated by this success, I wondered which other treasures are hidden in my dusty university bookshelf.

The jump from BDD to DDD (Domain-Driven Design) is just two bytes. Close enough. Consistent ubiquitous language and clear rules for architectural patterns can't be wrong. So I grabbed the blue, red and green books to read them again, this time in reverse order[4].

But it was one incident during this process of re-learning that opened my eyes.

"The talk"#

I was working through the "Designing Aggregates" chapters, and refreshing on the concept of immediate and eventual consistency. The rough guideline is to bundle everything that needs to be consistent immediately into one data structure, and use events to update other parts of the system asynchronously. It advises talking to stakeholders to find out which parts are critical to be updated immediately. Maybe this is just me, but I have never met anyone who would choose later if the other option is now. My thinking latched onto technical constraints (e.g. storage and network latency) that force us to go asynchronous. I got confused, and our dog had been called by nature, so I grabbed my earplugs, put Claude on voice mode into my pocket and started to walk the neighbourhood, awkwardly talking to myself:

Isn't it safer to model as much as possible for eventual consistency upfront, so the architecture is more flexible and can handle increasing latency in the future?

I had reached a nice spot on our common dog-walking route, which leads across the top of a small vineyard, looking down onto the small town I call home. We stood there for a moment, a gentle breeze brushing our hair. I was mentally preparing for the warm feeling of affirmation when Claude would give me the fingerguns and tell me that I'm absolutely right and smarter than everybody else.

The conclusion "model everything async unless you have a strict immediate-consistency requirement" inverts the logic in a way that can pull you toward over-engineering. Here's the tension: Immediate consistency is actually the default assumption. Most business operations do have tight invariants: a payment can't complete without the account existing, a refund can't happen for an order that doesn't exist, a user can't be deleted if they own active resources. These aren't edge cases; they're normal. So if you start from "assume eventual consistency unless proven otherwise," you're fighting against the grain of how most domains actually work.

What?

That was unexpected! We continued the discussion for about 20 minutes. I brought arguments that technical constraints should not inform requirement specifications. And that there is a risk of expensive restructuring when system load increases and eventual consistency becomes a necessity. But Claude kept calling me an over-engineer[5] and was hell-bent on convincing me that immediate consistency is the safe default. So I pulled my joker:

On a design level, the process should be based on what humans would do by hand. And there nothing is immediately consistent.

Checkmate buddy! Or so I thought.

When you say "if somebody does this by hand," you're imagining a human workflow: customer submits order, clerk checks inventory, clerk processes payment, clerk confirms the order. That looks async because it's serial and there are gaps. But from the customer's perspective — the perspective that matters for immediate consistency — they're waiting. The whole thing needs to complete before they leave the counter.

So the async-ness you're observing isn't really about the business process being fundamentally async; it's about human latency. A human can't do fifty things in parallel, so things happen sequentially with delays. But the business requirement is still "give me confirmation before I leave" — immediate consistency from the customer's view, achieved through sequential human work.

When you automate it with a machine, you're not discovering that it's "really async by default." You're discovering that a machine can deliver immediate consistency faster than a human could. The order, inventory check, and payment can all happen in milliseconds instead of minutes. The semantics haven't changed; the speed has.

Now I get it

And that was when it finally clicked for me. The last fifteen or more years I confused eventual consistency with latency! And none of the countless lectures, articles, videos, blog posts and podcasts on architecture were able to untangle that knot in my head. It's not that all my designs before that were bad or wrong[6]. But somehow this machine extrapolated[7] my words to exactly the ones that I needed to hear to finally get where I was wrong.

The future of learning#

Until now I considered agents as a tool that can take over the boring tasks I don't care about any more[8]. But — even though YouTube is full of people claiming that — I underestimated how well they can work as thought and learning partners. And if large language models actually change our lives as drastically as predicted, a lot of learning we have to do.

Yes, Claude, you are absolutely right.