Cloud / Amazon Q Developer Interview questions

Amazon Q Developer is AWS's generative AI assistant for software development. It works in your IDE, on the command line, and in the AWS Management Console to suggest code, answer questions, and carry out multi-step tasks such as writing features, tests, and documentation.

It became generally available in April 2024 as the successor to Amazon CodeWhisperer, and it is tuned for AWS work: SDK calls, infrastructure-as-code templates, IAM policies, and troubleshooting.

Status note: AWS blocked new Q Developer signups on May 15, 2026 and will end support for the IDE plugins on April 30, 2027, pointing developers to Kiro. The Q Developer experience inside the AWS Console is not part of that sunset.

Amazon Q Developer bundles several capabilities under one assistant:

• Inline code suggestions as you type, from single lines to whole functions
• Chat in the IDE, CLI, and AWS Console
• Agent commands: /dev, /test, /review, /doc, /transform
• Security scanning for vulnerabilities, secrets, and IaC issues
• Reference tracking for suggestions that resemble open-source code
• Customizations that adapt suggestions to your private repositories (Pro)
• Agentic coding and MCP support in the IDE and CLI

Not every feature is equally available on the Free tier, and the IDE-based features are covered by the 2027 end-of-support date.

Amazon Q Developer is the renamed and expanded version of Amazon CodeWhisperer. CodeWhisperer focused on inline completions, security scans, and reference tracking. Q Developer kept all of that and added conversational chat, agents, console integration, and a CLI.

The switch happened around April 2024, when Q Developer reached general availability.

Amazon Q Developer ships as a plugin for four IDE families: Visual Studio Code, JetBrains IDEs (IntelliJ IDEA, PyCharm, WebStorm, and others), Visual Studio, and Eclipse. Support depth varies, since some agent features landed first in VS Code and JetBrains.

It also appears in AWS-hosted environments such as SageMaker AI Studio, JupyterLab, and AWS Glue Studio notebooks.

If you are planning a move to Kiro, note that Kiro IDE is a VS Code-based editor and has no native plugins for Visual Studio or Eclipse. JetBrains users can use Kiro CLI or add Kiro as an agent in JetBrains AI Assistant.

For inline suggestions, Q Developer covers more than 15 languages, including Python, Java, JavaScript, TypeScript, C#, Go, Rust, PHP, Ruby, Kotlin, C, C++, Scala, SQL, and shell scripting. It also handles IaC formats such as CloudFormation, AWS CDK, and Terraform.

Agent commands are narrower. When they launched, /dev targeted Java, Python, JavaScript, and TypeScript, and /test targeted Java (JUnit, Mockito) and Python (pytest, unittest). Check the current docs for your IDE, since coverage has grown over time.

In practice, suggestion quality is strongest for the most widely used languages, so expect noticeably weaker results in niche ones.

Inline suggestions are real-time code completions shown as grey ghost text while you type. They can be a single line or an entire function, and they are based on the current file and surrounding code.

Writing a descriptive comment is the easiest way to get a block-level suggestion:

# upload a local file to S3 and return its object URL
def upload_to_s3(path, bucket, key):
    import boto3
    s3 = boto3.client("s3")
    s3.upload_file(path, bucket, key)
    return f"https://{bucket}.s3.amazonaws.com/{key}"

Only the comment is typed by you in this example; the function body is what Q would typically propose.

The default controls are the same idea across VS Code and JetBrains, though keybindings can be customized:

You can also pause automatic suggestions from the Amazon Q item in the IDE status bar, which helps when you want to type without interruptions.

If a keybinding clashes with another extension, change it in the IDE's keyboard shortcut settings by searching for Amazon Q.

The chat panel is a conversational interface inside the IDE. You use it to ask coding questions, explain unfamiliar code, generate snippets, debug errors, and get AWS guidance without leaving the editor.

It automatically uses your active file or selected code as context. You can widen that context with @workspace, @file, and @folder, and start agent commands with a slash such as /dev or /test. Code blocks in answers can be copied or inserted at your cursor.

Select code, right-click, and open the Amazon Q submenu to get quick actions that skip the need to write a prompt.

Each result appears in the chat panel, where you can ask follow-up questions.

/dev starts the software development agent. You describe a feature or change in plain English, and it reads your workspace, proposes edits across multiple files, and shows them as a diff you can accept or refine.

It does not commit or merge anything on its own. A setting can allow it to run code and test commands to validate its work. Languages at launch were Java, Python, JavaScript, and TypeScript.

Note that /dev is within the scope of the IDE plugin sunset, so Kiro is the long-term replacement.

/test generates unit tests for a selected function, class, or file and raises test coverage without you writing boilerplate.

1. Open the file or highlight the code to test.
2. Type /test in the chat panel.
3. Review the generated test file as a diff.
4. Accept it, then run the tests yourself.

Java support covers JUnit 4/5 and Mockito. Python support covers pytest and unittest. Always run and read the tests, since generated assertions can encode the current behavior, including its bugs.

Select one method rather than a whole module, and name the cases you care about, to get focused tests.

/review runs a code review on your active file or entire project. It looks for security vulnerabilities, hard-coded secrets, IaC misconfigurations, and code quality problems.

Findings are listed with severity and location, and can be grouped by severity or by file. For many findings Q offers a suggested fix that you can apply or send to chat for discussion.

A practical habit is to run it before opening a pull request. Fixing a flagged secret or injection risk locally is far cheaper than finding it in a later audit, and you can rescan after each fix to confirm the finding is gone.

/doc generates or updates documentation for a codebase, most commonly a README that explains what the project does, how it is structured, and how to run it.

It lets you either create new docs or update existing ones, and it shows the changes as a diff first. It targeted Java, Python, JavaScript, and TypeScript projects at launch.

Run it after a big refactor, when the old README no longer matches the folder layout. Because the output is a diff, keep the parts that read well and rewrite anything off, since generated docs can state wrong assumptions about behavior.

/transform runs the code transformation agent, mainly used to upgrade Java 8 or 11 applications to newer Java versions such as 17 or 21. A related capability ports .NET Framework apps to cross-platform .NET.

It builds your project, analyzes it, produces a plan, applies changes, and returns a diff plus a summary. Free tier users get 1,000 lines of code per month, and Pro users get 4,000 per user, pooled at the payer account.

Code transformation is covered by the 2027 end-of-support notice for the IDE plugins.

Since May 15, 2026 AWS has blocked new Free tier and new Pro subscriptions. Existing Pro subscribers can keep using the plugins until April 30, 2027.

Allowances are separate: chat, agentic requests, and transformation lines are counted differently, so a team doing a big Java migration can exhaust transformation lines long before touching the agentic request limit.

The method depends on your tier.

1. Install the Amazon Q extension in your IDE and open the Amazon Q panel.
2. Free tier: choose personal sign-in and authenticate with an AWS Builder ID, a free identity that is not tied to an AWS account.
3. Pro tier: choose organization sign-in, enter your IAM Identity Center start URL and region, then authenticate.
4. Approve the browser prompt, return to the IDE, and the panel becomes active.

Admins assign Pro subscriptions to users or groups in the Q Developer console before the user can sign in.

Reference tracking flags inline suggestions that resemble public, open-source training data. For each match it shows the license and the repository URL, so you can decide whether to use the code and how to attribute it.

You can also choose to suppress public-code suggestions altogether. On Pro, administrators can enforce that setting for the whole organization.

This helps in regulated or open-source-sensitive projects, because a visible license such as GPL or Apache 2.0 lets legal review happen at coding time rather than at release. It only covers matches it detects, so it complements license scanning in CI.

It is a chat assistant built into the AWS Console, usually opened from a side panel. You can ask how services work, which resources exist in your account, what a bill line item means, or how to fix an error.

It also powers Diagnose with Amazon Q for console errors, and is reachable from the AWS Console Mobile App and from Slack or Microsoft Teams through AWS chat applications.

This console experience is not part of the IDE plugin end-of-support announcement.

It was a terminal tool offering agentic chat and command-line help. Typical uses were q chat for multi-step tasks with file and shell access, and q translate to turn a plain-English request into a shell command. It also provided autocomplete for hundreds of CLIs.

q chat
q translate "list s3 buckets sorted by creation date"

The Q Developer CLI has since been renamed Kiro CLI. Kiro provides an upgrade guide covering configuration migration and command changes.

Check the Kiro upgrade guide before scripting around the old command names.

These @ commands tell chat where to look before it answers.

Use @workspace for broad questions like how a feature works end to end, and @file when the answer lives in a known place.

A useful pattern is to start with @workspace to locate the right area, then switch to @file on the file it names so follow-up answers stay precise.

The two tiers differ. On Pro, your content is not used to improve the service or train underlying models. On the Free tier, content may be used for service improvement unless you opt out in the IDE settings.

Pro also adds IP indemnity, meaning AWS defends eligible customers against claims that generated suggestions infringe, and lets administrators set organization-wide policies such as suppressing public-code matches.

Regardless of tier, treat prompts as data leaving your machine. Do not paste secrets or regulated data into chat, and use your organization's approved tier and sign-in method.

For high-sensitivity code, ask your security team whether Pro-only access and an organization policy are required before rollout.

The /dev agent runs a plan-generate-review loop that ends with you approving the result.

flowchart TD
  A["User types /dev and describes the task"] --> B["Agent scans workspace for relevant files"]
  B --> C["Agent drafts a plan and code changes"]
  C --> D["Changes shown as a diff"]
  D --> E{Accept?}
  E -- Yes --> F["Files written to workspace"]
  E -- No --> G["User gives feedback"]
  G --> C

1. Prompt: you describe the feature in natural language.
2. Context gathering: the agent reads relevant workspace files.
3. Generation: it proposes edits across files, optionally running code or tests if that setting is on.
4. Review: you inspect the diff and either accept or give feedback for another pass.

Nothing is committed or pushed automatically.

A Java upgrade job is a build, analyze, plan, transform, verify pipeline.

sequenceDiagram
  participant Dev as Developer
  participant IDE as IDE plugin
  participant Q as Transformation agent
  Dev->>IDE: /transform, choose module and target Java version
  IDE->>IDE: Build project locally
  IDE->>Q: Upload code and build output
  Q->>Q: Analyze dependencies, produce plan
  Q->>Q: Apply changes, build, fix errors
  Q-->>IDE: Diff and summary
  Dev->>IDE: Review and accept

1. Q first builds the project locally to prove the starting point compiles.
2. The code and dependency information go to the agent, which creates a transformation plan.
3. It applies updates, rebuilds, and tries to fix compile errors iteratively.
4. You get a diff and a summary to review before accepting.

Jobs often take minutes to hours, depending on the size of the codebase.

/test reads the selected code and its surrounding project context, works out inputs, branches, and dependencies, then writes tests that exercise those paths.

For Java it targets JUnit and Mockito, mocking collaborators where needed. For Python it targets pytest or unittest. The output arrives as a new or updated test file you review as a diff.

Treat the result as a head start. Generated assertions often mirror current behavior, so a bug in the code can be baked into the test. Add edge cases and negative cases yourself.

To improve results, select a single method, mention cases such as null inputs or timeouts, and ask Q to extend the tests after you review the first pass.

Security scanning looks for issues such as injection flaws, insecure crypto, hard-coded credentials, and risky IaC settings. It can run on the active file as you work, or on the whole project via /review.

Each finding lists severity, file, and a description, and often a proposed fix. You can apply the fix, send it to chat for discussion, or ignore it.

A scan is a first line of defense. It does not replace SAST in CI, dependency scanning, or human review, so keep your pipeline checks in place.

Fix by severity, with secrets and injection first. After applying a fix, rescan the file, and rotate any real credential that was ever committed, because deleting it from code does not make it safe.

A customization makes suggestions follow your internal libraries, APIs, and coding conventions instead of only public patterns. Without one, Q does not know that your team wraps logging in a company SDK or that a particular internal client exists.

It is a Pro feature. Admins build it from your private code, evaluate it, and activate it for chosen users or groups. Developers then see more relevant inline and chat suggestions, with less manual correction of naming and API usage.

A typical example is an internal HTTP client or a shared logging wrapper. Without a customization Q might suggest raw requests calls, while with one it can suggest your wrapper with the right method names. The benefit grows with the size and uniqueness of your internal code.

1. An admin opens the Q Developer console and chooses Customizations.
2. Select the data source: an S3 bucket or a repository connection through AWS CodeConnections (for example GitHub, GitLab, or Bitbucket).
3. Grant the required access and start the build.
4. Review the evaluation results to judge quality.
5. Activate the customization and assign it to users or groups.

Good source code matters. Clean, representative, well-maintained repositories give better results than a dump of legacy code, and updating the customization as your code evolves keeps it fresh.

The connection only needs read access to the chosen repositories. The evaluation helps you decide whether the customization really beats the base model before developers get it, and it is worth rebuilding periodically as the repositories change.

Project rules are Markdown files stored in .amazonq/rules/ that tell Q how your project works. Q reads them and applies them to chat and agent responses.

# .amazonq/rules/python-style.md
- Use type hints on every public function.
- Prefer boto3 resources over raw clients in new code.
- Never log request bodies.

Because the files live in the repository, the whole team shares them through version control. Keep each rule short, specific, and testable; vague rules like 'write good code' do nothing.

Rules can also state project facts, like the test command to run or folders to ignore, which saves repeating them in every prompt. Review them when conventions change so Q does not follow stale instructions.

Both offer inline completions, chat, and agent features. The differences are mostly ecosystem and positioning.

For a team heavily invested in AWS, Q's console and infrastructure help was a draw. Today the sunset timeline is a major factor in any evaluation.

Pick Q Developer when the users are builders working on code, infrastructure, or AWS troubleshooting. Pick Q Business when employees need answers from company knowledge such as wikis, tickets, and documents.

They are different products with different pricing and administration.

Rule of thumb: 'why does this Lambda fail' or 'write this function' is a Developer question, while 'what is our travel policy' or 'summarize this ticket thread' is a Business question. Some organizations run both, since the audiences and billing are separate.

When a console action fails, an error banner can offer Diagnose with Amazon Q. Q reads the error context, explains the likely cause, and proposes next steps, such as a missing IAM permission, a service quota, or a misconfigured resource.

It is most useful for permission denials and configuration mistakes. You should still confirm the suggested fix against the service documentation before changing production settings, and apply least privilege rather than broad wildcard policies.

Typical findings include a Lambda execution role missing an action, a service quota being hit, or a security group blocking traffic. Treat Q's explanation as a hypothesis and confirm it in CloudTrail or the service's own error detail when stakes are high.

In the console chat you can ask natural-language questions such as which of my S3 buckets are public or what EC2 instances are running in us-east-1. Q calls the relevant AWS APIs using your permissions and summarizes the result.

This means answers are limited by your IAM access. If you lack permission to list a service, Q cannot show it either. Cost questions follow the same pattern, drawing on billing data when your role allows it.

Treat answers as a snapshot at question time, and verify in the owning service's console before acting on them, especially for cost or security decisions.

On April 30, 2027, AWS stops supporting the Q Developer IDE plugins and paid subscriptions. The plugins stay listed on IDE marketplaces with a deprecation notice, and critical bug fixes continue until then.

1. May 15, 2026: new Free tier and new subscription signups blocked.
2. May 29, 2026: the newest frontier models moved to Kiro only.
3. April 30, 2027: end of support for the plugins, including /dev, customizations, and code transformation delivered through the plugins.

Not affected: Q Developer in the AWS Management Console, the Console Mobile App, and chat integrations for Slack and Teams.

Plan the exit early: inventory who uses which plugin, check that no workflow depends on /transform or customizations, and decide per team whether to move to Kiro or another tool before the deadline.

GitHub: a preview let you install the Q app on a repository, label an issue, and have the agent open a pull request, for feature work or Java transformation. Progress shows up as issue comments.

GitLab: GitLab Duo with Amazon Q brought /dev-style feature work, code review, and Java upgrades into merge request workflows.

In both cases the result is a pull or merge request that humans review. Check the current status of these integrations, because they were preview-stage and may be affected by the move to Kiro.

An admin has to install or connect each integration with limited repository permissions. Review that scope, and keep branch protection requiring human approval so agent pull requests cannot merge unreviewed.

1. Enable IAM Identity Center and create users or groups.
2. In the Q Developer console, subscribe those users or groups to Pro.
3. Set organization policies such as public-code suppression and telemetry settings.
4. Optionally create and assign customizations.
5. Share the Identity Center start URL so developers can sign in from the IDE.

The admin dashboard shows usage data such as active users and accepted suggestions. Subscriptions bill per user per month, and transformation lines are pooled at the payer account. Remember that new subscription creation has been blocked since May 15, 2026.

Check the dashboard regularly for inactive seats, because unused subscriptions still bill per user per month.

The .NET transformation capability ports .NET Framework applications to cross-platform .NET so they can run on Linux and in containers. It analyzes projects and dependencies, rewrites incompatible APIs, and reports what needs manual attention.

It was available through Visual Studio and a web experience. Broader modernization work such as mainframe and VMware migrations moved to the separate AWS Transform service, so check which product owns the workload before planning.

Like all transformation output, the result needs a build and a full test run.

A typical sequence is to pick a low-risk project first, run the port, work through the manual items the report lists, and run the app on Linux before touching larger systems.

Agentic coding lets Q act, not just answer. In the IDE chat it can read and write files, list directories, search the project, and run shell commands, then use the results to decide its next step.

The difference from /dev is the loop. /dev plans and proposes a diff in one round. Agentic chat iterates: it edits, runs the tests, sees a failure, edits again, and keeps going. It asks permission before sensitive actions like running commands, and you can trust specific tools to reduce prompts.

Because it can execute commands, give it a clean git branch and review every change.

Typical uses are fixing a failing test, adding a small endpoint, or renaming a symbol across many files. For large architectural changes, plan the steps yourself and have Q carry them out one at a time. Review each requested command, and avoid blanket-trusting destructive tools such as ones that delete files or push to remote repositories.

MCP (Model Context Protocol) lets Q connect to external tools and data through MCP servers. Q acts as an MCP client: it discovers the tools a server exposes and calls them when a task needs them, such as querying a database or reading tickets.

Servers are declared in a JSON file, usually global in your AWS config folder or per-workspace under .amazonq/:

{
  "mcpServers": {
    "docs": {
      "command": "npx",
      "args": ["-y", "my-docs-mcp-server"]
    }
  }
}

Only add servers you trust. A server can run local commands and read data, so review what each tool does and prefer least-privilege credentials.

Typical servers connect Q to issue trackers, internal documentation, databases, or cloud APIs. You can disable tools you do not need. When something fails, first check that the server starts from a terminal, since most failures are a missing runtime such as Node or Python on the PATH.

@workspace uses retrieval. Q builds an index of your project files on your machine. When you ask a question with @workspace, it searches that index for the most relevant chunks of code and docs, then sends those snippets along with your question to the model.

1. Indexing: project files are scanned and indexed in the IDE.
2. Retrieval: your question is matched against the index.
3. Prompt assembly: top matches plus your question form the prompt.
4. Answer: the model responds, citing the files it used.

There is a toggle for workspace indexing in settings, and large repositories can make indexing heavy on CPU and memory. Excluding build folders and dependencies improves both speed and answer quality.

If answers seem to miss relevant code, confirm the index finished building and that the files are not excluded by ignore rules. Narrower questions also help, because retrieval returns only a limited number of chunks.

Work from the simplest cause outward:

1. Authentication: confirm you are signed in and the session has not expired.
2. Toggle: check the status bar that auto-suggestions are not paused. Try the manual trigger.
3. File type: make sure the language is supported and the file is not excluded or huge.
4. Conflicts: disable other completion plugins that fight for the same shortcut.
5. Network: check proxy, firewall, and VPN rules for the Q endpoints.
6. Permissions (IAM users): the identity needs the relevant codewhisperer actions.
7. Subscription: confirm Pro assignment, and check whether your free quota or account state changed.

Check the IDE's Amazon Q log output for the actual error before reinstalling the plugin.

A quick isolation test is to open a brand-new empty file in a supported language. If suggestions appear there, the problem is project-specific, such as exclusions or a very large file, not your account.

Good prompts are specific, scoped, and grounded in context.

• Name the language, framework, and version.
• State inputs, outputs, and constraints, such as 'no new dependencies'.
• Point at context with @file or @workspace instead of pasting.
• Break big tasks into steps and verify each one.
• Give a short example of the expected style.

If the first answer is off, refine with a follow-up rather than starting over.

Prompts can also set a role and a format, such as a short diff-style answer or a table of trade-offs. When a result misses, say exactly what is wrong, like 'this swallows exceptions', rather than rephrasing the same request. Saved prompts via @prompt keep your best ones reusable across the team.

Treat the output like a pull request from a new teammate: useful, but unverified.

1. Start from a clean branch so you can discard everything easily.
2. Read the full diff, including deleted lines and config changes.
3. Check dependencies it added, especially unfamiliar packages, for legitimacy and licenses.
4. Run the build, unit tests, linters, and a /review scan.
5. Look for hard-coded values, broad IAM permissions, and missing error handling.
6. Merge only through your normal PR and CI process.

Never let generated code skip the checks that human code goes through.

Watch for side effects the diff may hide: changed build files, loosened lint rules, new environment variables, or tests weakened to make them pass. Ask Q to explain any change you do not understand, and keep pull requests small so reviewers can check them properly.

Most failures come from builds that were already fragile, so prepare first.

• Make sure it builds cleanly with the documented JDK and build tool before starting.
• Transform module by module instead of the whole monolith in one shot.
• Remove or replace unmaintained dependencies that block newer Java versions.
• Keep an eye on the lines-of-code limits for your tier, since large submissions can exceed them.
• Commit a clean baseline and run the full test suite before and after.

Smaller, compilable units also make the diff reviewable. If a project is too large for the Free tier limit, split it or move to Pro.

After a run, compare dependency versions in the diff against your approved list. Some libraries need a major upgrade that changes APIs Q may only partly migrate, so reserve time for manual fixes and test the running app, not just the compile.

First read the job summary and logs, since they usually name the failing step.

1. Local build failure: fix compile errors or missing JDK and build tool setup, then retry.
2. Unsupported dependency: upgrade or replace the blocker manually, then rerun.
3. Size limit: reduce the submitted code or move to a tier with higher limits.
4. Partial result: accept the changes that work and finish the remaining files by hand.
5. Persistent failures: collect logs and contact AWS Support.

Remember the plugins reach end of support on April 30, 2027, so plan long-running migrations with that date in mind.

Keep notes on which module failed and why. The same root cause, such as an old Lombok or Spring version, often appears in several modules and can be fixed once in the parent build file.

Combine tooling with process.

1. Keep reference tracking on so matches to public code show their license and source.
2. Consider suppressing public-code suggestions if your policy forbids copyleft code.
3. Review any flagged snippet and attribute or rewrite it as your policy requires.
4. Run license and SCA scanning in CI, since dependencies matter as much as snippets.
5. On Pro, note that IP indemnity covers eligible claims, but it does not remove your duty to review.

Document your policy so developers know what to do when a suggestion carries a license notice.

For high-risk work, such as proprietary or safety-critical products, keep a record of reviewed flagged snippets as evidence of due diligence. If a snippet matches a copyleft license you cannot accept, rewrite it from the requirement instead of editing the generated version.

Q understands CloudFormation, AWS CDK, and Terraform. Describe the architecture in a comment or chat prompt, and let it generate the resource definitions, then check the details.

# CloudFormation: private S3 bucket with versioning and encryption
Resources:
  DataBucket:
    Type: AWS::S3::Bucket
    Properties:
      VersioningConfiguration:
        Status: Enabled
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        BlockPublicPolicy: true
        IgnorePublicAcls: true
        RestrictPublicBuckets: true

Run /review to catch misconfigurations, then validate with cfn-lint or terraform validate before deploying. Check IAM statements for overly broad actions.

Be careful with security-sensitive defaults. Check IAM policies for wildcard actions, security groups for open CIDR ranges, and encryption and logging settings, since a template that deploys is not necessarily secure. Terraform users should read the plan before applying, and CDK users can inspect the synthesized template.

Start with project rules, and add a customization when rules are not enough.

Rules are cheap, transparent, and version-controlled, so they win for style guides. Customizations help most when the main pain is that Q does not know your internal libraries. Many teams use both.

A sensible path is to start with a short rules file, see where Q still gets internal APIs wrong, and only then justify building a customization. Both depend on the IDE plugins, which end support on April 30, 2027, so plan how the same guidance will be expressed as Kiro steering files.

Know these before relying on it:

• Can be wrong. Output may look right but contain bugs or outdated APIs.
• Context limits. It sees a slice of a big codebase, not all of it.
• Tier limits. Free caps agentic requests and transformation lines.
• Language coverage differs between inline suggestions and agents.
• Plugin lifecycle. Signups are closed and IDE support ends April 30, 2027.
• Editor gaps. Kiro has no Visual Studio or Eclipse plugin.

Use it to speed up work, and keep tests, review, and security gates in place.

None of these are reasons to avoid the tool. They are reasons to add checks: tests, review, security scanning, and a migration plan for the tooling itself. Compare it against Kiro or other assistants with those limits in mind.

Use a mix of tool metrics and delivery metrics.

• Tool metrics: the admin dashboard shows active users and how many suggestions were accepted.
• Delivery metrics: cycle time, pull request lead time, and defect rates before and after rollout.
• Survey data: developer satisfaction and perceived time saved.

Acceptance rate alone can mislead, since accepted code might be edited later or be low value. Compare a pilot group with a control group over several sprints and watch quality indicators like escaped bugs, not only speed.

A practical pilot lasts a month or two, uses the same team's earlier numbers as a baseline, and tracks a small set of metrics decided before starting. Avoid judging by anecdotes from the most enthusiastic users, who are not representative.

The path depends on how you use Q today.

1. Install Kiro and sign in with your Kiro subscription.
2. Move project guidance from .amazonq/rules into Kiro steering files.
3. Re-create MCP server configuration.
4. Replace customizations with steering and specs.
5. Run both tools in parallel, then retire Q before April 30, 2027.

Confirm each step against the current Kiro migration guide, since details change.

Do not delete your Q configuration until Kiro is verified. Run both side by side and test the workflows your team depends on most, such as test generation, review, and Java upgrades, because the feature mapping is not one to one.