From Spec to Deploy: Building a Microservice with Amazon Quick Desktop + Coding Agents (Claude Code & Kiro)

What happens when your AI work companion handles the context and your coding agent handles the code?

Abhi Bhattacharya

Published Jul 2, 2026

Last modified Jul 2, 2026

The Problem Every Developer Knows

You've been asked to build a new microservice. The spec? It's scattered across a Slack thread from two weeks ago, a design document buried in SharePoint, an API contract in an existing repo, and tribal knowledge locked in a teammate's head.

Before you write a single line of code, you spend 90 minutes aggregating context: searching Slack, downloading docs, cross-referencing the existing codebase for conventions, and stitching it all together into something actionable.

Now multiply that by every service your team builds.

What if you could go from scattered spec to deployed service in a single conversation?

This post walks through a real-world flow where Amazon Quick Desktop acts as the orchestrator — gathering requirements, synthesizing context, managing communication — while a coding agent (either Claude Code or Kiro CLI) acts as the builder — scaffolding the service, writing tests, and iterating on feedback. Quick communicates with these agents via the Agent Communication Protocol (ACP), creating a seamless developer experience regardless of which coding agent you prefer.

Meet the Cast

Amazon Quick Desktop — The Orchestrator

Quick Desktop is an AI work companion that sits across your entire digital workspace. It connects to Slack, email, SharePoint, Asana, your local filesystem, and more — and maintains a Knowledge Graph of your team's people, projects, and decisions. Think of it as your context layer: it knows who owns what, where the docs live, and what was decided in that thread last Tuesday.

The Coding Agents — The Builders

Quick Desktop supports multiple coding agents through ACP. You choose the one that fits your workflow:

Claude Code — A coding agent that lives in your terminal. Point it at a codebase and it can read, understand, write, and execute code across multiple files. It writes production-quality code, runs tests, and iterates based on feedback.

Kiro CLI — The command-line interface for Kiro, AWS's agentic coding tool. While Kiro also exists as a full IDE, it's the CLI version that integrates with Quick Desktop via ACP. Kiro CLI can generate structured specs from requirements, break them into implementation tasks, and execute them autonomously with hooks for automated validation. It's especially powerful for projects that benefit from specification-first workflows.

Both agents share the same superpower: they can read your codebase, generate multi-file changes, run tests, and iterate — but they need clear context to do their best work. That's where Quick comes in.

ACP — The Handshake

The Agent Communication Protocol (ACP) is how Quick Desktop delegates work to your coding agent of choice. It's not copy-paste — it's a structured handoff: Quick packages the context into a task brief, sends it to Claude Code or Kiro CLI, and receives results back. The developer stays in one conversation the entire time.

The beauty of ACP is that it's agent-agnostic — Quick Desktop detects whichever coding agents you have running locally (Claude Code in the terminal, Kiro CLI as a background process) and can dispatch to any of them. You can even use different agents for different tasks: Kiro CLI for greenfield spec-driven work, Claude Code for quick fixes and refactors.

The Scenario

The ask: Build an Order Notifications Service — a microservice that consumes order events from an SQS queue and sends customer notifications via SNS (email/SMS).

The constraints:

Java 21 + Spring Boot
AWS CDK for infrastructure
Must follow the team's existing error-handling and retry patterns
Needs unit tests and a README

Where the context lives:

Slack: #team-platform — design discussion from last sprint
SharePoint: Architecture Decision Record (ADR) for the notifications domain
Codebase: An existing order-processing-service as the reference for conventions

Let's go.

Act 1: Gather Requirements

Developer:

"Pull together everything we have on the notifications service — check Slack, the ADR in SharePoint, and the API contract in our repo."

What Quick Does:

Quick fires off parallel searches:

Slack → Finds the #team-platform thread where the team discussed SQS vs. EventBridge, agreed on SQS, and outlined the message schema
SharePoint → Locates the ADR: "ADR-047: Customer Notification Architecture" with the domain model and delivery guarantees
Knowledge Graph → Identifies that @sarah-l owns the notifications domain and @mike-k wrote the reference service
Codebase → Finds order-processing-service/src/main/resources/api-spec.yaml — the OpenAPI contract for order events

Quick presents a synthesized summary:

📋 Context Summary: Order Notifications ServiceDecision (Slack, 2 weeks ago): Team agreed on SQS for event ingestion. SNS for fan-out to email/SMS. DLQ after 3 retries.ADR-047: Notifications must be idempotent (deduplicate on orderId + eventType). Max delivery latency: 30s. Schema versioning via eventVersion field.API Contract: Order events include orderId, customerId, eventType (PLACED, SHIPPED, DELIVERED), timestamp, metadata.Reference Service: order-processing-service uses Java 21, Spring Boot 3.2, CDK v2, custom RetryableException pattern with exponential backoff.

No tab-switching. No manual doc hunting. One prompt, full context.

Act 2: Synthesize a Task Brief

Developer:

"Package this into a task brief for my coding agent. Include the tech stack constraints and point it to the reference service."

What Quick Does:

Quick generates a structured TASK_BRIEF.md:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
# Task Brief: Order Notifications Service

## Objective
Build a new microservice that consumes order events from SQS
and sends customer notifications via SNS.

## Functional Requirements
- Listen to `order-events-queue` (SQS)
- Route notifications by event type:
  - PLACED → Email confirmation
  - SHIPPED → Email + SMS
  - DELIVERED → Email
- Deduplicate on `orderId + eventType` (idempotency)
- DLQ after 3 failed processing attempts
- Max end-to-end latency: 30 seconds

## Tech Stack
- Java 21, Spring Boot 3.2
- AWS CDK v2 (TypeScript) for infrastructure
- JUnit 5 + Mockito for tests
- Gradle build system

## Conventions (from order-processing-service)
- Package structure: `com.company.notifications.{config,consumer,publisher,model,exception}`
- Error handling: Custom `RetryableException` with exponential backoff
- Logging: Structured JSON via SLF4J + Logback
- Config: Spring profiles (local, dev, prod)

## Reference
- See: order-processing-service/ for style and patterns
- ADR-047 for architectural constraints

## Deliverables
- [ ] Project structure with all packages
- [ ] CDK stack (SQS queue, SNS topic, DLQ, IAM roles)
- [ ] SQS consumer with message deserialization
- [ ] SNS publisher with routing logic
- [ ] Idempotency check (in-memory for now, note for DynamoDB later)
- [ ] Unit tests (≥80% coverage on business logic)
- [ ] README with setup and run instructions

This isn't a vague "build me a notification service." It's a complete, actionable brief with constraints, conventions, and acceptance criteria — the kind of context that makes any developer (human or AI) productive immediately.

Act 3: Scaffold the Service

Developer:

"Send this to Kiro CLI. Have it scaffold the full service."

(Or: "Send this to Claude Code" — the flow is identical regardless of which agent you choose.)

What Quick Does:

Quick dispatches the task via ACP — sending the brief plus a pointer to the reference service directory so the coding agent can study the team's patterns firsthand.

What the Coding Agent Does:

The agent reads the brief, explores the reference service's structure and patterns, and generates the full project:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
order-notifications-service/
├── cdk/
│   ├── bin/app.ts
│   └── lib/notifications-stack.ts
├── src/main/java/com/company/notifications/
│   ├── NotificationsApplication.java
│   ├── config/
│   │   ├── SqsConfig.java
│   │   └── SnsConfig.java
│   ├── consumer/
│   │   └── OrderEventConsumer.java
│   ├── publisher/
│   │   ├── NotificationPublisher.java
│   │   └── NotificationRouter.java
│   ├── model/
│   │   ├── OrderEvent.java
│   │   └── NotificationType.java
│   └── exception/
│       └── RetryableException.java
├── src/test/java/com/company/notifications/
│   ├── consumer/OrderEventConsumerTest.java
│   ├── publisher/NotificationRouterTest.java
│   └── IdempotencyCheckTest.java
├── build.gradle
├── application.yml
└── README.md

Not a skeleton — a working service with wired-up dependencies, real routing logic, and meaningful tests.

💡 Kiro CLI Bonus: When using Kiro CLI, it can additionally generate a structured spec document (.kiro/specs/) that breaks the task brief into discrete implementation tasks with acceptance criteria — giving you a living checklist alongside the code.

Act 4: Review & Iterate

Developer:

"Show me what it built. Does it follow our error-handling pattern correctly?"

What Quick Does:

Quick pulls the generated code back into the conversation and cross-references it against the reference service's RetryableException pattern. It flags a discrepancy:

⚠️ Pattern Mismatch DetectedThe coding agent implemented a basic try-catch with fixed retry delay. Your team's pattern uses RetryableException with:* Exponential backoff (base 100ms, max 5s)
isRetryable() classification based on exception type
Metrics emission on each retry attemptThe reference implementation is in order-processing-service/src/.../exception/RetryableException.java

This is Quick's superpower: it knows your team's conventions because it has access to the Knowledge Graph and codebase — and it can QA the AI-generated code against them.

Act 5: Refine

Developer:

"Tell it to use our exact RetryableException pattern. Here's what it should look like."

What Quick Does:

Quick sends a follow-up to the coding agent via ACP with:

The specific RetryableException.java from the reference service
The pattern description from the team's conventions doc
Instructions to refactor the error handling throughout

What the Coding Agent Does:

The agent refactors:

Replaces the naive try-catch with RetryableException
Adds isRetryable() classification (network errors → retry, validation errors → DLQ)
Implements exponential backoff with jitter
Adds metrics emission via Micrometer
Updates tests to cover retry scenarios

Act 6: Validate

Developer:

"Run the tests and check that CDK synth works."

What the Coding Agent Does:

1
2
3
4
5
6
$ ./gradlew test
BUILD SUCCESSFUL — 14 tests passed

$ cd cdk && npx cdk synth
✅ NotificationsStack synthesized successfully
   Resources: SQS Queue, DLQ, SNS Topic, 2 IAM Roles, Lambda (if applicable)

All green. The service compiles, tests pass, and the infrastructure is valid.

Act 7: Ship & Close the Loop

Developer:

"Post a summary to #team-platform, create a code review task in Asana for Sarah, and update our services catalog."

What Quick Does (in parallel):

Slack → Posts to #team-platform:> "✅ Order Notifications Service scaffolded and ready for review. Consumes from SQS, publishes via SNS, follows our RetryableException pattern. PR: [link]. Reviewer: @sarah-l"
Asana → Creates a task:
- Title: "Code Review: Order Notifications Service"
- Assignee: Sarah L.
- Due: EOD tomorrow
- Description: Links to PR, ADR-047, and the task brief
Knowledge Graph → Adds a new service entity:
- Order Notifications Service → owned by @developer, reviewed by @sarah-l, depends on order-events-queue

The loop is closed. No context was lost. No one needs to ask "where's the PR?" or "what was the spec again?"

Architecture: How It Fits Together

Choosing Your Coding Agent

	Claude Code	Kiro CLI
Best for	Quick fixes, refactors, multi-file edits	Greenfield projects, spec-driven development
Workflow	Receives task → executes immediately	Receives task → generates spec → executes step-by-step
Strengths	Fast iteration, deep codebase understanding	Structured planning, automated validation hooks
Where it lives	Terminal (CLI)	Terminal (CLI) — runs as background process
ACP dispatch	`"Send to Claude Code"`	`"Send to Kiro CLI"`

You don't have to choose one forever. Quick Desktop's ACP integration means you can dispatch different tasks to different agents based on what fits:

Scaffolding a new service from spec? → Kiro CLI
Fixing a bug in an existing service? → Claude Code
Running tests and validation? → Either

📝 Note: Kiro also ships as a full IDE (standalone or VS Code extension) with a GUI for spec-driven development. The ACP integration specifically uses Kiro CLI — the headless, terminal-based version that can receive structured briefs from Quick Desktop and execute autonomously. If you already use the Kiro IDE, think of Kiro CLI as its automation-friendly counterpart.

Key Takeaways

1. Context aggregation is the real bottleneck

Code generation gets the headlines, but the hard part of building software is knowing what to build and how it should fit with everything else. Quick Desktop eliminates the context-gathering tax.

2. Separation of concerns matters — even for AI

Quick doesn't try to write code. The coding agents don't try to search Slack. Each agent does what it's best at, and ACP is the clean interface between them. This mirrors good software architecture: single responsibility, clear contracts.

3. The developer stays in flow

Seven SDLC phases. One conversation. Zero context switches. The developer's job shifts from "tool operator" to "decision maker" — they approve, redirect, and validate, but never lose their train of thought.

4. Agent choice is a preference, not a commitment

ACP abstracts the handoff. Today you might use Claude Code; tomorrow you might prefer Kiro CLI for a different type of task. Quick Desktop doesn't care — it packages context the same way regardless of which builder receives it.

5. Iteration is natural, not painful

When the first output wasn't perfect (Act 4), the fix was a single sentence. Quick knew why it was wrong (team conventions), and the coding agent knew how to fix it. The feedback loop is seconds, not hours.

Honest Limitations

Architecture decisions still need humans. Quick can surface context and coding agents can generate code, but "should we use SQS or EventBridge?" is still a judgment call.
Works best with documented conventions. If your team's patterns only exist in someone's head, the AI can't enforce them. This flow rewards teams that document.
Not zero-oversight. The developer reviewed the output, caught the pattern mismatch, and directed the fix. AI-generated code still needs human eyes — especially for production services.
ACP is the linchpin. Without a structured handoff protocol, this becomes sophisticated copy-paste. The protocol is what makes it a system, not a hack.
Agent availability. Both Claude Code and Kiro CLI need to be installed and running locally for Quick to dispatch to them. ACP auto-detects available agents at runtime.

Try It Yourself

Install Amazon Quick Desktop — Connect your Slack, SharePoint, and local repos
Set up your coding agent:
- Claude Code — Install and configure as a local coding agent, OR
- Kiro CLI — Download from kiro.dev and follow the CLI setup instructions
Connect via ACP — Quick Desktop detects available agents automatically once they're running locally
Start with a real task — Pick a small service your team needs and try the flow end-to-end

# amazon-quick-suite # claude-code # sdlc # application-integration # developer-productivity

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

From Spec to Deploy: Building a Microservice with Amazon Quick Desktop + Coding Agents (Claude Code & Kiro)

Abhi Bhattacharya

The Problem Every Developer Knows

Meet the Cast

Amazon Quick Desktop — The Orchestrator

The Coding Agents — The Builders

ACP — The Handshake

The Scenario

Act 1: Gather Requirements

Act 2: Synthesize a Task Brief

Act 3: Scaffold the Service

Act 4: Review & Iterate

Act 5: Refine

Act 6: Validate

Act 7: Ship & Close the Loop

Architecture: How It Fits Together

Choosing Your Coding Agent

Key Takeaways

1. Context aggregation is the real bottleneck

2. Separation of concerns matters — even for AI

3. The developer stays in flow

4. Agent choice is a preference, not a commitment

5. Iteration is natural, not painful

Honest Limitations

Try It Yourself