Baking a whole image to test one component takes the better part of an hour. We run components standalone on a warm box with AWSTOE, give each a machine-checkable verify goal, and let AI agents iterate until it passes.
Building golden images for VDI means writing and debugging a lot of components: the small install/configure/verify units that turn a base OS into a working desktop. Install an app, set a registry key, harden a setting, then prove it took. Writing them isn't the hard part. The feedback loop is.
The obvious way to test a component is to bake an image with it. On AWS that's an EC2 Image Builder pipeline run: provision a build instance, run every component, snapshot, register an AMI, run the test workflow, tear everything down. For a Windows image that's the better part of an hour, per iteration. When you're chasing the one silent-install flag that makes a stubborn installer go quiet, an hour per attempt turns a day of work into a week.
Image Builder doesn't actually run components itself. It delegates to AWSTOE (the AWS Task Orchestrator and Executor), the same component runtime, which you can run standalone. So instead of baking a whole image to test one component, we:
.png)
Render-ComponentDoc.ps1);awstoe run against a test instance we keep around, either locally on the box or pushed remotely over SSM (Test-Package.ps1 -RemoteInstanceId);build_RunInstall/std.out and std.err for what the installer did, validate_RunVerify/std.out for what the verification checked.The win isn't that a single component run is instant (an install can still take minutes). It's that you skip the entire provision, bake, snapshot, register, and teardown tax and reuse the same warm test host across attempt after attempt. The loop goes from "an hour per try" to "try the next fix immediately."
Fighting the same golden-image feedback loop? Book a DCV consultation →
Here's the part that makes it more than a faster manual loop. Every package in our model ships with its own verify step (verify.ps1). It asserts the things that must be true for the component to be "done": the binaries exist, the expected paths are present, the exit codes are acceptable. That verify step is a machine-checkable goal.
A machine-checkable goal plus a fast, scriptable test step is exactly what an AI assistant can drive. We hand it the goal ("this package passes its verify") and let it work the loop:
std.out, std.err, verify output),exit_codes_ok entry like 3010, a wait, an ordering fix, a locale-specific path) and run again,Because each attempt is an AWSTOE run on a warm box rather than a full bake, the assistant can burn through many candidate fixes in the time a single Image Builder loop used to take, and it stops on an objective signal (verify green), not when a human runs out of patience. Only once the package passes cleanly does it graduate to a real recipe bake, with high confidence it'll succeed there too.
The payoff wasn't theoretical. With the goal defined by each package's verify step and AWSTOE as the fast substrate, we put Claude Code agents to work the loop unattended overnight, with the remit to spin up test-harness instances in parallel when it helped. Across a single build push we produced CIS-hardened Linux and Windows base images and 54 validated software packages, complete with repeatable AWS Image Builder recipes, in about 48 hours. That's work normally measured in weeks.
The autonomy was real, but bounded by design: the agents iterated against an objective goal (a package's verify step passing) on ephemeral test instances, so "let it run overnight" was an engineered bet, not a reckless one. And we deliberately didn't enshrine that loop as permanent pipeline code. The durable output is the AWS Image Builder recipes and the verify contracts, which a human or an agent can drive equally well. The autonomy lives in the agent layer, where it's cheap to change; the reusable assets live in the repo, where they belong.
Two things combine well here. Golden-image maintenance is notoriously tedious and slow to iterate on, and AI assistants are good at exactly the kind of bounded, verifiable, repeat-until-it-passes loop that component testing is, provided there's a fast execution substrate and an objective goal. AWSTOE supplies the substrate; the per-package verify contract supplies the goal. Together they turn "bake and pray, an hour at a time" into a tight, goal-driven loop: fewer failed bakes, components proven before they reach the pipeline, and image work that moves at the speed of the fix rather than the speed of the bake.
Part of our Amazon DCV series. See also: A production DCV environment in hours, not weeks.
Ready to move faster on golden images? Book a DCV consultation with CloudLife →
