Orchestrating Coding Agents: How Amazon Quick Delegates the Work
When an AI assistant can't do something itself, what happens next? Amazon Quick now delegates coding to agents like Kiro over ACP — dispatching scoped tasks, verifying results, and catching drift, all without leaving the conversation. This post walks through the same orchestration loop at two extremes: a benchmark-driven JavaEE-to-Quarkus transformation that climbed from 0.875 to 0.975, and a retro platformer built in a lunch break.
I spend a lot of my time these days thinking about a deceptively simple question: when an AI assistant can't do something itself, what happens next? For most of the last two years, the answer was "it tells you, and you go do it." That's changing. Amazon Quick can now hand work to specialized coding agents like Kiro , supervise the result, and feed corrections back — all without me touching the editor. The assistant stops being a single model answering questions and becomes an orchestrator coordinating other agents.
In this post, I want to walk through what that actually looks like in practice. I'll use two examples from the last few weeks that sit at opposite ends of the seriousness spectrum: a rigorous, benchmark-driven code transformation project, and a retro platformer I built in a lunch break. Same underlying pattern, two very different payloads.
The Core Idea: Quick as Orchestrator, Kiro as Executor
The integration point is the Agent Client Protocol (ACP). Quick connects to a local coding agent — in my case Kiro — and dispatches scoped coding tasks to it. Quick stays in the loop: it decides what needs to change, formulates the task, lets Kiro do the actual file edits, and then inspects the result. If something drifted, Quick reformulates and dispatches again.
Key benefits of this split:
- Separation of concerns — Quick handles planning, analysis, and verification. Kiro handles the deterministic, spec-driven code changes. Neither tries to be the other.
- You review the plan, not the diff — I supervise the orchestration loop at the task level, not line by line.
- Drift detection — Quick re-reads the output after each cycle and catches when an agent quietly did the wrong thing.
- No context-switching — I never leave the conversation. The conversation is the development environment.
Let's take a closer look at how this plays out.
Example 1: A Custom Code Transformation, Driven by Benchmarks
The serious example first. I was building a custom AWS Transform Transformation Definition (TD) that migrates JavaEE/WildFly applications to Quarkus . A TD encodes migration knowledge as a structured
SKILL.md file plus reference documents, so an agent can perform the transformation autonomously. The TD is validated by a benchmark that scores it across multiple dimensions — build success, code quality, plan completion, documentation, and more.The challenge: improving the TD is an iterative loop. The benchmark produces a score and a list of findings. Those findings need to become precise edits in
SKILL.md and its reference files. Then you re-publish, re-run, and read the new score. Doing this by hand is exactly the kind of repetitive, high-iteration work where an orchestration loop pays for itself.In practice this ran as two loops, with a clean division of labor between the two agents.
Loop 1 — Quick → atx (run the transformation, catch drift). Quick figures out which apps still need transforming, constructs the exact
atx custom def exec -t -n javaee-to-quarkus --tv <version> -p <app> calls, and watches the output. The interesting work here is drift detection: at one point Kiro couldn't find the custom TD name in the registry and silently fell back to AWS/JBoss-to-Spring-Boot — the wrong target and the wrong language stack entirely. Quick caught it before anything got committed.Loop 2 — Quick → Kiro (review, then improve the TD). Once a transform completes, Quick hands the migrated codebase to Kiro for a structured code review against a spec. Kiro writes its findings into a benchmark file. Quick reads that output and makes one decision: did a genuinely new migration pattern emerge? If yes, Quick dispatches the precise
SKILL.md edits back to Kiro and publishes a new TD version. If no, move on.Spelling out who does what:
- Quick (the orchestrator) — reads the benchmark feedback and groups findings by severity (P0/P1/P2); decides what needs to change and which metric matters; formulates each scoped task (which file, what change, what constraint to respect); verifies the result by re-reading the modified files; drives the
atxpublish cycle; and decides when to iterate again. - Kiro (the executor) — performs the structured code review against the spec, writes the findings file, and makes the actual file edits in
SKILL.mdand its reference documents. Kiro does the deterministic, spec-driven typing; it never decides direction.
This split is also what caught a subtle scaling problem.
SKILL.md had grown to over 1,200 lines, and the automated reviewer has a fixed read window — content past the halfway point was silently invisible, causing false negatives on migration steps that were actually present. Quick detected the scoring pattern, dispatched a restructuring task to Kiro (trim the file, offload detail to reference files), and published a new version. You review the plan, not the diff.The result: the composite benchmark score went from 0.875 to 0.975 across multiple iterations — without me manually editing a single line of the TD. I reviewed plans and approved direction; Quick orchestrated, Kiro did the typing.
One thing to watch: orchestration doesn't remove the need for judgment. When a benchmark "fix" would have broken a complexity classification the scorer depended on, I had to catch it and revert. The agent will happily optimize the metric you point it at — sometimes past the point of sense. The human stays responsible for which metric matters.
Example 2: A Retro Platformer in a Lunch Break
Now the unserious example — because the same pattern works when the stakes are zero.
One Friday lunch break, I wanted to see how far you can push this when you stop being serious for 30 minutes. The goal: a playable 2D platformer. I described what I wanted in natural language, dropped in some Kenney.nl pixel-art assets and a ProTracker -style chiptune, and let the loop run.
The result was a fully playable game in a single HTML file — zero dependencies, runs in any browser:
- HTML5 Canvas for rendering — every sprite drawn with
ctx.drawImage()andctx.fillRect(), no game library - Web Audio API for procedurally generated sound effects — jump, coin, stomp, and a little death jingle built from oscillators
- An embedded chiptune soundtrack and a
requestAnimationFramegame loop - Two levels, patrolling enemies you can stomp, coins, pits that kill you, and a flag that ends the level
The interesting part wasn't the game. It was the iteration speed. "The enemy walks into the mountain in level 2, the collision is off" → fix. "You can't reach the goal with the jump, move the platform right" → fix. "Falling into the pit doesn't kill you" → fix. Each cycle: under a minute. Natural language in, working build out.
And yes — the enemy walked into the wall three times before the collision detection held. Some bugs are truly universal.
The Pattern, Visualized
Both examples are the same loop with a different payload. Quick orchestrates; a coding agent (or Quick's own code tools) executes; Quick verifies and iterates; the human supervises direction.
Figure: Amazon Quick coordinates two loops — Loop 1 runs the transformation through the atx CLI and catches drift; Loop 2 hands code to Kiro for review and dispatches the resulting TD edits. The editable source is available as
orchestration-loop.drawio.The TD project routed through
atx and a benchmark; the platformer routed through Quick's own code tools and a browser preview. The orchestration core didn't change.Why This Matters
For 15 years I've built distributed systems on AWS, and the thing that consistently slows teams down isn't writing code — it's the loop between intent and something you can evaluate. Delegating coding to agents under an orchestrator compresses that loop dramatically.
- For a benchmark-driven engineering task, it turned a multi-day manual fix-publish-evaluate grind into a supervised loop that moved a score from 0.875 to 0.975.
- For a throwaway prototype, it turned a vague idea into something playable in a lunch break.
The span between those two — production-grade transformation work and a retro game nobody asked for — is exactly the point. The same integration handles both.
A Few Things I'd Recommend
If you want to try this yourself, a few practical notes:
- Scope every dispatched task. Tell the agent which files it may touch and what it must not change. Unscoped tasks invite over-refactoring.
- Make the agent report what it changed. A verification summary — files touched, why, how to validate — lets the orchestrator (and you) catch drift fast.
- Keep a human on the "which metric matters" question. Agents optimize what you point them at. You own the direction.
- Let the conversation be the dev environment. The less you context-switch out to the editor, the more the loop is worth.
This approach is production-ready for the serious work and genuinely fun for the rest. Going from "vague idea" to "thing someone can actually evaluate" in minutes changes how you think about prototyping, workshops, and internal tooling.
Or, you know, retro games nobody asked for. Those too. 🕹️
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article