AEMCoder in Practice — Results from the EDS POC

Content Objective

This chapter covers:

• What AEMCoder did well in an EDS migration POC
• Where it helped with block development and page import
• Where it struggled and why that matters
• Why source content quality affects the result more than the tool
• How manual refinement still fits into the workflow
• How to evaluate AI-assisted migration tools realistically

For this POC, AEMCoder was used for content migration and block development on an AEM EDS site.

The notes below summarize the observed results.

What AEMCoder Did Well

AEMCoder is Adobe's development console for EDS.

It is positioned as a way to reduce migration effort.

Some of that held up in the POC.

Block Development

Block development was fast.

If you give AEMCoder a reference block and describe what you want, it can scaffold a working block, JS, CSS, and the block model following EDS conventions.

For standard blocks, that got me 60 to 70 percent of the way there in minutes.

That reduced the amount of manual setup, especially early in the project while scoping effort.

Content Migration

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, the import mapped cleanly.

Where It Struggled

Anything irregular required rework.

Pages with inconsistent markup, legacy inline styles, or components that did not map cleanly to EDS blocks came out rough.

The tool is limited by the structure it reads from.

Messy source sites stayed messy in the output.

It Was Not One-Shot For Custom Work

For some blocks, getting AEMCoder to land on the right output took more than one pass.

It was not a one-shot tool for anything outside standard patterns.

Some blocks took several iterations before the structure and styling matched the target.

Custom Logic Still Needs A Developer

Interactivity, state, and third-party integrations still require developer work.

AEMCoder gets you the scaffold. The implementation still needs to be completed manually.

For the blocks that needed more precision, I used Claude Code to clean up the output, refine the JS logic, and improve the styling.

AEMCoder provided the starting point. Claude Code was used to refine the JS logic and styling.

The two tools covered different parts of the workflow:

• AEMCoder was used for fast scaffolding within EDS conventions.
• Claude Code was used for iterative refinement once the target output was clear.

The Bigger Pattern

The clearer the source content, the more AEMCoder helps.

The messier the source content, the less effective the tool becomes.

It is not replacing the hard parts of a migration. It is compressing the easy parts.

That is still useful. It does not remove the migration work.

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 ready for production review.

What To Test In A Real POC

If you are evaluating a tool like this for a project, do not test it on the cleanest page template.

Test it on your worst one.

That is where you learn what it can do and where a second tool or developer is still required.

Final Takeaway

AEMCoder is useful when it is used for the parts it handles well:

• Fast scaffolding
• Standard block generation
• Clean-content page imports
• Early POC acceleration

It is less useful when expected to solve the migration by itself.

The main lesson from the POC is:

,[object Object],

That is the rule to keep in mind for future migration work.