Posts

Why does agentic coding work so well with event-driven architectures?

A post about why observable event-driven contracts work well for humans, tests, and agentic coding.

Why does agentic coding work so well with event-driven architectures?

Because event-driven systems make behavior observable.

In a typical layered application:

"A user clicks a button. Then what?"

Dozens of methods execute across multiple layers.

  • ❌ Hidden control flow.
  • ❌ Opaque state changes.
  • ❌ Unclear behavioral contracts.

But an event-driven workflow is explicit:

Input Event
    ↓
Load State
    ↓
Update State
    ↓
Output Events

Every workflow becomes observable.

Observable behavior is something both humans and AI can verify.

Instead of asking:

"Did the implementation call the correct methods?"

you ask:

"Given this input event and this state, were the correct state changes and output events produced?"

That shift is surprisingly important for agentic coding.

LLMs don't need to reason about an entire application at once.

They only need to satisfy one observable contract at a time.

  • ✅ Independent regression tests.
  • ✅ Observable state changes.
  • ✅ Observable event flows.

World Editor

I recently tried this with a large event-driven World Editor in Unity:

All GUI interactions flows were defined explicitly.

The result?

Almost all behavioral code now lives outside Unity.

  • ✅ Interaction flows are verified in plain .NET.
  • ✅ AI can now iterate without the engine.

But behavior expectations are only useful if humans can understand them too.

This is also why I built Xcepto.

Xcepto lets me describe workflows in almost natural language.

Instead of verifying implementation details, tests describe observable behavior.

For agentic coding, I think that's a much better contract.

The implementation evolves continuously.

But behavior stays verified.

GitHub

Xcepto