Agent-Driven Block Compilation and Compression for EDS

April 2026

In EDS, you typically do not rely on a traditional build pipeline. The platform leans on native JavaScript, browser capabilities, and edge delivery to handle performance, which removes much of the need for bundling and heavy optimization steps.

https://www.aem.live/developer/architecture

That works well in practice, but compression still matters. Even without a build system, smaller files mean less data over the wire and faster load times.

The challenge shows up once you introduce agent-driven development. You still need code that is readable and maintainable, but you also want output that is optimized for production. In a buildless model, there is no obvious place for that transformation to happen.

This workflow addresses that gap. Instead of introducing a build step, the repo uses a familiar pattern with two versions of the code: readable source and compressed output. The difference is that the agent is responsible for generating both.

I wanted to see if this actually makes a difference, so I pushed compilation and compression into the repo itself and compared the results between main and a branch where blocks are compiled and compressed as part of the workflow.

Page load timing improved.

That is roughly a 30ms improvement without changing any runtime behavior.

Looking at uncompressed sizes shows where the gains actually come from.

JavaScript is where most of the impact shows up, around 40 to 50 percent smaller across the blocks we own, while CSS moves less as expected.

What matters more is transfer size.

Each file is smaller over the wire, and it adds up across the page, which is what shows up in the timing improvements.

It is also worth calling out what did not change. Shared assets like aem.js, styles.css, the hero image, and query-index.json are identical between branches, which confirms that only block-level code is being optimized.

At a high level, the repo treats block code in two forms. Readable source lives in .src.js and .src.css, while compiled .js and .css files are what actually get served. The agent is responsible for keeping those in sync.

The workflow itself is simple. Edit the source files, run the minify step, verify outputs, check size reports, enforce budgets, and commit.

What changed is not the tooling but the responsibility. The agent is expected to produce code that is ready to ship, which includes compiling, compressing, and validating output before commit.

This works especially well in EDS. The platform is already buildless, blocks load independently, and pages only load what they need. That makes block-level optimization more relevant than bundle-level optimization.

I also tested this with a new code block that touched everything, including source, compiled output, and real content usage. Existing blocks got smaller with compression, while the new block added weight because it introduced new behavior. The difference is that the tradeoff is now visible and measurable.

This also lines up with where EDS is going. Adobe is already documenting how AI coding agents interact with EDS projects.

https://www.aem.live/developer/ai-coding-agents#useful-tools-for-ai-agents

There are also supporting projects emerging around this model.

https://github.com/cloudadoption/helix-mcp

https://github.com/upstash/context7

Agents are expected to operate on repositories and produce usable output, and this workflow fits that model.

The repo enforces a few simple rules. Blocks we own follow the workflow, core runtime code does not, scripts and styles stay upgradeable, artifacts are regenerated before commit, and budgets are part of validation.

This pattern works if you want better performance discipline without introducing a full build system. It keeps source readable, produces compressed output, fits naturally with agent workflows, and does not make future upgrades harder.

The point is simple. If agents are writing the code, they should also be responsible for getting it ready to ship.