Concepts / Building / Building with AI
Building

Building with AI

This guide explains why event-sourced systems are particularly well suited to being built with the help of AI coding agents, and how to set up the work so that an agent produces reliable code rather than plausible guesses.

AI coding agents can write a lot of code quickly. Whether that code is any good depends less on the agent than on what it is asked to work on. Pointed at a large codebase with implicit rules and hidden coupling, an agent has to reconstruct knowledge it cannot see – and where it guesses, mistakes creep in. Pointed at a small, explicit, well-described piece of work, the same agent does remarkably well.

Event-sourced systems happen to consist of exactly such pieces.

Why Event-Sourced Systems Suit Agents#

Much of an event-sourced system follows the same few shapes, again and again: a command, a decider that decides on it, the events it produces, a projection that turns events into a view, and a query that reads it. This regularity is what makes the approach attractive for agents:

  • Small units of work. A single use case – a command with its decider and events, or a projection with its view – can be understood on its own. An agent working on it needs little context beyond the piece itself.
  • Explicit vocabulary. Commands, events, and state are named in the language of the domain. An agent does not have to infer from column names what a change means.
  • Pure functions at the core. Deciders and projections take values and return values. There is no hidden state for an agent to overlook, and nothing to mock when checking the result.
  • Behavior as examples. Business rules can be written as scenarios – given these events, when this command, then these events. Such scenarios are precise enough to build against and to check against.

The Model as a Contract#

The quality of generated code rises and falls with the quality of what an agent builds against. A picture of a model on a whiteboard is useful for discovery, but an agent cannot verify anything against it. A machine-readable model – the commands, events, and read models of a domain, together with their scenarios – turns the model into a contract:

  • The agent knows exactly which pieces exist and what they must do.
  • Whether every scenario has been implemented – and no extra ones invented – becomes something that can be checked, not something to judge.
  • The model stays the place where the thinking happens, and the code follows from it.

Try it with ESDM

ESDM describes an event-sourced domain model as YAML files with published schemas, which a coding agent can read before it writes anything – see Your First Model with AI.

Guardrails That Hold#

Agents are good at producing code and poor at judging whether it is right. The work therefore needs guardrails that do not depend on the agent's own confidence:

  • Scenarios as tests. Given-When-Then scenarios become executable tests. A piece of work is done when its scenarios pass – not when the agent says so.
  • Deterministic checks. Linters, type checkers, schema validation, and the tests themselves decide whether the result is acceptable. Having one agent review another is not a control; something non-agentic has to be the judge.
  • Narrow scope. An agent that works on one use case should change only that use case. Code shared across many pieces is exactly what an agent can break without noticing, so a little duplication between use cases is often the better trade than a clever shared abstraction.
  • Known recipes. Instructions for how a piece is built in a given stack – often called skills – keep an agent from inventing a new approach for every task.

What Stays with People#

Building with AI does not remove the need for judgment; it moves it. The decisions that matter most happen before any code is generated:

  • Which events exist, and what they mean. Modeling the domain – usually together with the people who know it – remains human work.
  • Which scenarios define correct behavior. The scenarios are the specification. Whoever writes them decides what the system does.
  • Where the boundaries run. Which rules belong together, and which must be consistent with each other, is a design decision, not a detail of implementation.

Once these are fixed, an agent can fill in a great deal of the implementation – and because the structure was decided upfront, there is little architecture left for it to improvise.

Agents as Readers of Events#

AI takes a second role in event-sourced systems, besides helping to build them: it can read their history. An agent with access to the event store can investigate what happened in a system, explain an unexpected state, or answer questions about the domain in plain language – see LLMs and Event Streams. Both roles benefit from the same property: events that are explicit, well named, and in the language of the domain.

Try it with EventSourcingDB

The Claude Code plugin for EventSourcingDB gives a coding agent skills for writing, reading, and querying events – see Introduction to the Claude Code Plugin.

Getting Started#

The smallest honest experiment is a single use case. Model one command with its events and scenarios, hand the model and the scenarios to an agent, and let the tests decide whether the result is right. It takes little time, and it shows quickly where the approach helps and where the model still needs work. For a broader view of the practice, see the interview Candy for AI with Martin Dilger on spec-driven development.