I used AEMCoder on a real migration POC. Here's the honest version.

In my last article I wrote about why migrating to AEM Edge Delivery Services is a different paradigm, not a CMS swap. This one picks up where that left off.

For this POC I used AEMCoder for both content migration and block development on an AEM EDS site. Here's what actually happened, not the highlight reel.

A quick recap for anyone who hasn't come across it: AEMCoder is Adobe's AI assisted dev console for EDS. No local setup, you prompt in natural language, preview live, commit through GitHub. The pitch is that it takes migrations from months to weeks.

Some of that held up. Some of it didn't.

What worked well

Block development was genuinely fast. Give it a reference block and describe what you want, and it scaffolds a working block, JS, CSS, the block model, all following EDS conventions. For standard blocks, that got me 60 to 70 percent of the way there in minutes. That's real time saved, especially early in a project when you're still scoping effort.

Content migration was smooth on pages with clean, consistent structure. The page import side mapped source content into EDS blocks without me writing a custom importer for every page type. When the source DOM was predictable, this just worked.

Where it struggled

Anything irregular needed real rework. Pages with inconsistent markup, legacy inline styles, or components that didn't map cleanly to EDS blocks came out rough. The tool is only as good as the structure it's reading from, and messy source sites stayed messy on the other side.

For some blocks, getting AEMCoder to land on the right output took more than one pass. It wasn't a one-shot tool for anything outside the standard patterns, and I went through a few iterations on certain blocks before the structure and styling matched what I actually needed.

Custom logic still needs a developer. Interactivity, state, third party integrations, none of that comes for free. AEMCoder gets you the scaffold. You still write the part that makes it actually work.

For the blocks that needed real fine tuning, I brought in Claude Code to clean up the output, refine the JS logic, and get the styling closer to production quality. AEMCoder got me a working starting point fast. Claude Code is what got that starting point to something I'd actually ship. The two tools ended up complementing each other well, one good at fast scaffolding within EDS conventions, the other better at precise, iterative refinement once I knew exactly what needed to change.

The bigger pattern

The clearer your source content, the more AEMCoder saves you. The messier it is, the less it helps, right when you need the help most. It's not replacing the hard parts of a migration. It's compressing the easy parts, which is still valuable, just not in the way the marketing implies.

And even on the parts it handles well, treat the first output as a draft, not a final answer. Some blocks needed two or three rounds of refinement before they were genuinely production ready.

If you're evaluating this for a real project, don't run the POC on your cleanest page template. Run it on your worst one. That's where you'll learn what it can actually do for you, and where you'll need a second tool or a developer to close the gap.

What's next

The next piece in this series looks at the content migration side specifically, why your source site's structure ends up mattering more than any tool you throw at it.

Curious if anyone else has put this into a live migration yet. What held up for you, and what didn't?