AEMCoder in Practice — Results from the EDS POC

What we actually saw in the POC

AEMCoder was useful in the EDS migration proof of concept, but it was not magic.

It helped with the easy parts of the work: scaffolding the first version of a block, getting a migration started, and reducing the amount of repetitive setup I normally have to do when building a site from a legacy source. That part was real. It saved time.

The important part is that it only saved time on the parts that were already somewhat predictable.

What it was good at

AEMCoder is Adobe's development console for EDS, and in the POC it did a solid job on the standard pattern work.

If I gave it a reference block and described the target, it could generate a working block structure, JS, CSS, and a reasonable model following EDS conventions. For a normal block, that got us a long way very quickly. In a lot of cases, it got us to 60 to 70 percent of the finished result in minutes rather than hours.

That matters because early in a migration, the biggest cost is setup. If the tool can generate the baseline structure and naming conventions correctly, the team can focus faster on the actual product work.

The same was true for content migration when the source pages were clean and consistent. The import process worked much better when the DOM structure was predictable. That is where the tool felt genuinely helpful.

Where it started to break down

The moment the source content got messy, the output got messy too.

Legacy pages with inconsistent markup, inline styles, odd DOM nesting, or components that did not map cleanly to EDS blocks needed manual cleanup. The tool did not magically fix the bad source structure. It just carried it forward into the output in a more automated way.

That was the biggest lesson for me: the tool is only as good as the structure it receives.

It also was not a one-shot solution for custom work. Some blocks needed multiple rounds of refinement before they were close to the target. That is normal for any AI-assisted development flow, but it matters if you are expecting it to do the migration without review.

The developer work still mattered

AEMCoder gave us the starting point, but it did not remove the need for real engineering judgement.

Interactivity, state, third-party integrations, and custom behavior still needed developer work. A scaffolded block is not a finished component. It is only a starting draft.

For the parts that needed more precision, I used Claude Code to refine the JS logic and styling. That was a useful workflow:

• AEMCoder handled the first pass and the EDS conventions
• Claude Code helped tighten the implementation once the target behavior was clear

That split made sense. The tool was good at generating a base, but not at making the final product feel intentionally designed.

The bigger pattern

This was the real pattern we saw on the POC.

The cleaner the source content, the more helpful the tooling became. The messier the source, the more rework it needed.

So I would not describe AEMCoder as replacing the migration. I would describe it as compressing the repetitive parts.

That is still useful. It shortens the setup phase and gets the team moving faster. But it does not remove the hard work. It just shifts the work from writing everything from scratch to refining the generated result.

Even when it does well, I treated the first output as a draft, not as a final answer. A few blocks needed two or three passes before they were production-ready.

What to test in a real project

If you are evaluating this kind of tool, do not test it on the easiest page template.

Test it on the worst page in the system.

That is where you learn whether the tool is actually useful or just good at the clean cases. It is also where you discover whether a second tool or a human developer is still required.

My takeaway

AEMCoder is helpful when the task is standard and the source is reasonably clean:

• fast scaffolding
• normal EDS block generation
• early migration acceleration
• good starting point for the POC

It is less useful when the migration depends on messy legacy structure, custom behavior, or content that does not map cleanly to EDS blocks.

The main lesson from the POC was simple:

The better the source structure, the more the tool helps.

That was the real rule. Not that AI removes migration work. It does not. It just helps you move faster through the parts that are predictable.