A few months ago I was wrapping up what I thought was a fairly straightforward WordPress to Statamic migration. The site had a lot of content (much more than I originally scoped for) and buried in it were a handful of block editor components I hadn’t anticipated. Complex nesting, one-off structures, the kind of thing that’s easy to build in Gutenberg and then easily forget about later.

Statamic’s importer handled most of it cleanly, but those nested blocks it skipped entirely, which left me with gaps in the content that needed to be resolved before anything could go live.

A year ago that would have meant writing custom functions to flatten the structure, match it to the right blueprint fields, and slot everything into place one piece at a time. Tedious, error-prone, and the kind of work that quietly eats a project’s margin.

What happened instead was this: because Statamic stores everything as YAML and markdown files sitting in the filesystem, I was able to at least capture the raw content in a reasonable format, point an agent at the content directory, describe the patterns I was looking for, and let it work through the inconsistencies. It had full context, the blueprint structure, the content, the relationships between them, all readable without querying a database or parsing serialized block data. What might have taken weeks of careful manual work got resolved in a fraction of the time.

I’ve been thinking about why that worked as well as it did, and I keep coming back to the architecture itself. That’s what made it possible… not just the fact that I was using AI to help me out.

I think the interesting mental shift here when we start thinking about a codebase structure as an asset… something an agent can reason about, not just execute on.

This is a different approach altogether.

For our AI tools to work with our code and be successful more consistently, it means having a more coherent starting place, which means being consistent with how fields are named, keeping component structure predictable, and avoiding the clever one-off solutions that seem like a good idea in the moment. The more coherent the foundation, the better the decisions an agent can make as it works through what you’re asking of it. Without that context, it’s largely grasping in the dark… filling in gaps with its own assumptions rather than working from something it actually understands.

Statamic has an edge here that I think is underappreciated, even among people who already use it. The schema lives in the filesystem. The content lives in the filesystem. An agent can read both, understand how they relate, and work with real context rather than an abstraction of the content. Other modern CMS options, including some well-regarded headless systems, store content in a database behind an API. The schema might be defined in readable code, but the content itself requires a query. There’s a layer of indirection that limits what an agent can see at once.

None of this means the foundation organizes itself. Thoughtful setup still matters, probably more than it did before, because what you’re building now isn’t just a codebase for you to work in. It’s a codebase for you and an agent to work in together. The upfront decisions compound.

That’s where I’m putting my attention right now, before I write a single line of code on my next project.