Accelerating Development with Amazon Q Developer
Amazon Q Developer is AWS's coding assistant, and its edge is context: it knows your AWS environment and shines at the unglamorous, high-value work — upgrading dependencies, migrating frameworks, generating tests, and answering "how is this deployed?" This chapter covers where an AWS-native assistant earns its keep.
Learning objectives
- Use Amazon Q Developer in the IDE and CLI.
- Explain its AWS-native edge (infra, docs, security scans).
- Use it for code transformation and AWS troubleshooting.
- Position it in a team's tool mix.
code/ad4-amazon-q/ in the course, with a README on how to run it. Read here, run there — no need to copy-paste.1 · Q Developer's edge essential
Amazon Q Developer is AWS's coding assistant, and its edge is deep AWS knowledge: it knows the SDKs, IAM, service limits, and your account's resources. For AWS-heavy work it answers questions a general assistant can't — and it plugs into the IDE, CLI, and the AWS console.
2 · Where it shows up essential
| Surface | Use for |
|---|---|
| IDE plugin | inline completions, chat about AWS code |
| CLI (`q`) | ask questions, translate intent → shell |
| Console | explain resources, troubleshoot from context |
| Security scan | find + auto-fix vulnerabilities |
3 · Intermediate — CLI intent-to-command intermediate
The CLI turns natural language into shell/AWS commands and explains errors with account context. You still review before running — but it collapses "what's the aws-cli flag for…" lookups.
q_cli.sh# Ask Q to translate intent into a command (it proposes, you confirm):
q chat "list S3 buckets larger than 1 GB in us-east-1"
# Inline: Q suggests the aws-cli invocation, you review, then run:
aws s3api list-buckets --query "Buckets[].Name"
This shows the two ways Amazon Q helps you at the terminal. The q command is the Amazon Q CLI — you type what you want in plain English, and Q figures out the AWS command for you. It proposes the command; nothing runs until you confirm. That safety step matters, because Q knows your AWS account and can suggest commands that touch real resources.
- Any line starting with
#is a comment — a note for humans that the shell ignores. It's here to explain the line below it. q chat "list S3 buckets larger than 1 GB in us-east-1"asks Amazon Q a question in ordinary words. Q replies with the exactawscommand that does this, so you don't have to remember the flags. You read it, then decide whether to run it.aws s3api list-buckets --query "Buckets[].Name"is the kind of command Q would hand back.aws s3apitalks to the S3 service;list-bucketslists your buckets; and--query "Buckets[].Name"filters the reply down to just the bucket names instead of the full details.
What the output means: Running the second line prints a list of your S3 bucket names, one per line. The first line (q chat …) doesn't change anything — it only suggests a command for you to review.
Try this: Ask Q something in your own words, like q chat "how do I see which EC2 instances are running?", and compare the command it proposes to what you'd have written by hand.
4 · Advanced — code transformation advanced
Q Developer's standout feature is code transformation — e.g. upgrading a Java codebase across major versions, or migrating between frameworks. It plans the change, edits across the repo, and reports what it did. This is agentic refactoring aimed at large, mechanical migrations.
roi.pydef migration_roi(files, manual_hours_per_file, q_review_min_per_file):
manual = files * manual_hours_per_file
with_q = files * (q_review_min_per_file / 60) # you review Q's output
saved_pct = round(100 * (manual - with_q) / manual)
return {"manual_hours": manual, "with_q_hours": round(with_q, 1),
"saved_pct": saved_pct}
print(migration_roi(files=200, manual_hours_per_file=1.5, q_review_min_per_file=10))
{'manual_hours': 300.0, 'with_q_hours': 33.3, 'saved_pct': 89}This little program answers a manager's question: is it worth using Amazon Q to migrate a large codebase? "ROI" means return on investment — here, how much time you save. The idea: doing each file by hand takes hours, but with Q you mostly just review its work, which takes minutes. The function adds both up and compares them.
def migration_roi(files, manual_hours_per_file, q_review_min_per_file):defines a reusable calculation. The three inputs are: how many files, how long each takes by hand (in hours), and how many minutes you'd spend reviewing Q's output per file.manual = files * manual_hours_per_fileis the all-by-hand total: files times hours each.with_q = files * (q_review_min_per_file / 60)is the with-Q total — but review time is in minutes, so/ 60converts it to hours first so the two numbers can be compared fairly.saved_pct = round(100 * (manual - with_q) / manual)works out the percentage of time saved: the gap between the two totals, as a share of the manual total, rounded to a whole number.- The function
returns a dictionary (a set of labelled values) with the two hour totals and the percentage. The last lineprint(migration_roi(files=200, …))calls it with real numbers — 200 files, 1.5 hours each by hand, 10 minutes review each — and prints the result.
What the output means: {'manual_hours': 300.0, 'with_q_hours': 33.3, 'saved_pct': 89} means: doing it by hand would take about 300 hours, doing it with Q about 33 hours — a 89% time saving. That's the case for letting Q do the mechanical work while a human reviews.
Try this: Change q_review_min_per_file to 30 (slower, more careful review) and re-run. Watch saved_pct drop — this shows the payoff shrinks the more hand-review you insist on.
5 · Professional — security scanning & guardrails professional
Q scans for vulnerabilities and suggests fixes inline — useful, but not a replacement for your SAST pipeline. Treat it as an extra reviewer. As with any assistant, mind what code/context leaves your environment; check the enterprise/data-handling tier for sensitive repos.
6 · Tech-lead — right tool for the AWS-heavy team tech-lead
A lead positions Q where it's strongest: AWS-native shops get the most from its account awareness and migrations; polyglot teams may pair it with Cursor/Copilot for general work. The call is per-workload — Q for AWS + big migrations, a general tool for everyday editing — with a clear data-handling policy for both.
Exercise AD4.1 — Cost a migration
Context: Framework and version migrations are mechanical, voluminous, and a strong ROI fit for Q — but the payoff depends on keeping the right human review in the loop so automation stays safe.
Your task: Pick a real or hypothetical framework/version migration, estimate manual vs Q-assisted effort, and list the human review you'd keep.
Requirements:
- Use
roi.pyto estimate manual vs Q-assisted effort for the migration - List the specific human review steps you'd keep in the loop to keep the automation safe
- Acknowledge the trade-off that more per-file human review shrinks the automation payoff
- Balance safety against the ROI you're chasing rather than maximizing either alone
💡 Hint: The ROI comes from Q doing the mechanical work while humans only review per file — the review minutes you insist on directly size the savings.
🪜 Practice ladder beginner → industry
Six graded exercises, easy to real-world. Try each before opening its solution.
Context: Amazon Q Developer's distinctive edge is deep AWS integration, and knowing exactly where that edge is real (and where it disappears) is what lets you position it against a generic assistant.
Your task: In two sentences, state Amazon Q Developer's distinctive edge over a generic AI coding assistant and the kind of team it matters most for.
Requirements:
- Name the edge: deep AWS integration (trained on and connected to AWS services, docs, best practices)
- Give AWS-specific examples where it beats a generic assistant (IAM policies, CDK/CloudFormation, service config, intent-to-
aws-CLI) - Say it matters most for AWS-heavy teams doing daily provisioning/config/ops
- Note the edge mostly disappears for teams with little AWS surface
💡 Hint: The edge is proportional to how much of the team's daily work is actually AWS-specific.
Show solution
Q Developer's edge is deep AWS integration: it is trained on and connected to AWS services, docs, and best practices, so it is strongest at AWS-specific tasks — writing IAM policies, CDK/CloudFormation, service configuration, and translating intent into correct aws CLI commands — where a generic assistant guesses.
That edge matters most for AWS-heavy teams whose daily work is provisioning, configuring, and operating AWS infrastructure; for a team with little AWS surface, the edge mostly disappears.
Context: Q can turn intent into a shell command, which is great for recalling syntax — but intent-to-command demands a verification habit, because you own confirming it does what you meant and nothing destructive.
Your task: Show the before/after for ‘list all S3 buckets over 100 GB’ and name the verification habit that must accompany it.
Requirements:
- Show the intent and the shape of command Q produces (buckets have no direct size field, so it composes CloudWatch metrics or an S3 inventory query)
- Note the command needs AWS credentials to run
- Name the verification habit: read the command first — confirm region, account, and that it is read-only
- State the rule: never pipe a generated command straight into execution unseen
💡 Hint: Intent-to-command is for recall of syntax, not for trust — read it before you run it, especially for anything that could mutate.
Show solution
Intent: ‘list all S3 buckets larger than 100 GB.’ Q translates this to a CLI invocation (buckets have no direct size field, so it composes CloudWatch metrics or an S3 inventory query):
# conceptual shape Q produces (needs AWS credentials to run):
aws cloudwatch get-metric-statistics \
--namespace AWS/S3 --metric-name BucketSizeBytes \
--dimensions Name=BucketName,Value=<bucket> Name=StorageType,Value=StandardStorage \
--start-time ... --end-time ... --period 86400 --statistics AverageVerification habit: read the command before running it — confirm the region, the account, and especially that it is read-only. Intent-to-command is great for recall of syntax, but you own confirming it does what you meant and nothing destructive. Never pipe a generated command straight into execution unseen.
Context: Large code transformations (like a Java version upgrade across a repo) are Q's standout use case — but a bulk change demands bulk-appropriate verification: a snapshot, per-module review, and a test suite that defines correctness.
Your task: Describe how you'd run and verify a large Q code transformation (e.g. a repo-wide version upgrade) safely.
Requirements:
- Scope & snapshot: run on a branch off a clean commit so the transformation is one reviewable, revertible diff
- Review the diff by module, not as one unreviewed blob
- Lean on the test suite as the definition of correctness; add characterization tests first if coverage is thin
- Watch for semantic changes (deprecated APIs swapped for ones with subtly different behavior) — diff behavior, not just syntax
- Stage the rollout incrementally rather than a big-bang cutover
💡 Hint: The tool saves the typing; the test suite and a staged rollout supply the verification the bulk change demands.
Show solution
- Scope & snapshot: run on a branch off a clean commit so the whole transformation is one reviewable, revertible diff.
- Let it transform, then read the diff by module — don't accept a repo-wide change as a single unreviewed blob; review file groups.
- Lean on the test suite: a version upgrade's correctness is defined by tests still passing. If coverage is thin, add characterization tests before transforming.
- Watch the semantic changes — transformations sometimes swap deprecated APIs for ones with subtly different behavior (e.g. default time zones, null handling). Diff behavior, not just syntax.
- Stage the rollout: merge and deploy incrementally where possible rather than a big-bang cutover.
The transformation saves the typing; the test suite and staged rollout provide the verification the bulk change demands.
Context: A Q-run upgrade that passed all tests but broke production exposes the gap between ‘no logic break’ and ‘no behavior change’ — a dependency's changed default that the tests never asserted on.
Your task: Explain the likely gap when a Q-run dependency upgrade passed tests but caused a subtle production incident, and how to close it.
Requirements:
- Name the gap: tests covered code paths but not the behavioral change (a changed default — timeout, serialization, timezone, rounding)
- Explain that green tests prove ‘no compile/logic break’ not ‘no behavior change’
- Close it by reading the dependency changelog for behavior/default changes, not just API removals
- Add characterization tests pinning the specific behaviors prod relies on, before upgrading
- Canary the change and compare real outputs against the old version
- State the lesson: automated transformation is blind to semantic drift; verification must include behavior
💡 Hint: The transformation tool won't surface a dependency's changed default as a diff in your code — the changelog and characterization tests will.
Show solution
Likely gap: the tests covered the code paths but not the behavioral change the upgrade introduced — e.g. a library changed a default (timeout, serialization format, timezone, rounding) that the tests never asserted on. Green tests proved ‘no compile/logic break’ not ‘no behavior change’.
- Read the upgraded dependency's changelog for behavior/default changes, not just API removals — the transformation tool won't surface these as diffs in your code.
- Add characterization tests that pin the specific behaviors prod relies on (exact output formats, boundary values) before upgrading.
- Canary the change: ship to a small slice and compare real outputs against the old version.
Lesson: automated transformation moves fast on syntax but is blind to semantic drift in dependencies. Verification must include behavior, not just a green suite.
Context: Q's security scanning is a fast, broad first pass that catches careless mistakes — but a clean scan is not a secure system, and treating it as ‘done’ creates false confidence.
Your task: Explain what Q's security scanning does and does not catch, and how to wire it in without creating false confidence.
Requirements:
- What it catches: common patterns (hard-coded secrets, injection-prone code, known-vulnerable dependencies, insecure defaults) — a fast broad first pass
- What it misses: business-logic flaws (broken authz, IDOR), design-level issues, anything needing your trust boundaries
- Wire it into CI as a gate for the obvious (block on secrets and high-severity findings)
- Keep human security review for auth/authorization changes and design review for new data flows
- Tune out false-positive noise so the team doesn't learn to ignore the scanner
- Frame it as ‘catches careless mistakes so review focuses on subtle ones’, never ‘security is done’
💡 Hint: Position the scanner as one layer that frees human review to focus on the logic and design flaws it can't see.
Show solution
What it catches: common patterns — hard-coded secrets, injection-prone code, known-vulnerable dependency usage, insecure defaults. It is a fast, broad first pass.
What it misses: business-logic flaws (broken authorization, IDOR), design-level issues, and anything requiring understanding of your trust boundaries. A clean scan is not a secure system.
- Run it in CI as a gate for the obvious — block merges on hard-coded secrets and high-severity findings.
- Treat it as one layer: keep human security review for auth/authorization changes and design review for new data flows.
- Tune out noise deliberately — unmanaged false positives train the team to ignore the scanner, which is worse than not having it.
Frame it to the team as ‘catches the careless mistakes so review can focus on the subtle ones,’ never as ‘the security step is done.’
Context: A platform team living in AWS should pick tools per task by where the training/integration edge actually is — Q where its AWS edge is real, a general assistant where it isn't — and put the tightest guardrails on the highest-blast-radius output.
Your task: You lead an AWS-heavy platform team (CDK, Lambda, IAM, EKS): decide where Amazon Q fits vs a general assistant and design the combined workflow.
Requirements:
- Route tasks by edge: Q for IAM/CDK/service-config and
awsCLI recall; general assistant/editor for general app logic, tests, refactors - Treat Q's security scan as a broad first pass paired with human review, not sufficient alone
- Guardrails first: read every generated CLI/IaC change, nothing destructive runs unseen, least-privilege credentials for Q
- Standardize IaC review (plan-diff, e.g.
cdk diff, before apply) because infra has blast radius - Measure the win (infra-change lead time, misconfig incidents)
- State the lesson: pick per task by where the edge is, and put the tightest guardrails on highest-blast-radius output (IAM/infra)
💡 Hint: They're complements, not competitors — and IAM/infra output gets the strictest review because its mistakes have the widest blast radius.
Show solution
Decision: use Q where its AWS edge is real, a general assistant where it isn't — they're complements, not competitors.
| Task | Tool | Why |
|---|---|---|
| IAM policies, CDK, service config | Amazon Q | AWS-trained; fewer wrong-shape guesses |
| aws CLI recall & ops one-liners | Amazon Q | Intent-to-command is its sweet spot |
| General app logic, tests, refactors | General assistant / editor | Not AWS-specific; parity or better |
| AWS security posture first pass | Q security scan + human review | Broad pattern catch, but not sufficient alone |
- Guardrails first: read every generated CLI/IaC change; nothing destructive runs unseen; least-privilege on the credentials Q operates with.
- Standardize IaC review: generated CloudFormation/CDK is reviewed and plan-diffed (e.g.
cdk diff) before apply — infra mistakes have blast radius. - Measure: track infra-change lead time and misconfig incidents; the win shows up as fewer ‘wrong IAM’ and faster provisioning.
Lesson: pick the tool per task by where the training/integration edge actually is, and put the tightest guardrails on the highest-blast-radius output (IAM and infra).
✓ Checkpoint — you can move on when you can…
- Use Q in the IDE and CLI.
- Explain its AWS-native advantages.
- Apply it to migrations; estimate ROI.
- Position Q vs general assistants per workload.
Knowledge check check yourself
The lesson calls code transformation Amazon Q's standout feature and pairs it with a migration_roi calculation. Why is this class of work such a strong fit for Q?
Show answer
Raising q_review_min_per_file in the ROI model shrinks saved_pct. What production trade-off does that illustrate about Q-assisted migrations?