Amazon Q Developer folded CodeWhisperer into a wider assistant

The setup

Amazon Q Developer reached general availability on 30 April 2024, according to AWS's own announcement. Existing users of the earlier CodeWhisperer extension did not need to reinstall: the post states expired Amazon Q or CodeWhisperer connections would have the new Amazon Q extension automatically installed in Visual Studio Code and JetBrains IDEs. Two advanced capabilities, agents for software development and for code transformation, became free with an AWS Builder ID at this launch, alongside a $19-per-user-per-month Pro tier described in the same post.

What the documents show

The product page for Amazon Q Developer describes coverage the earlier tool lacked: real-time code completion, acting as an expert on AWS inside the Management Console for cost and architecture questions, and agents that accelerate .NET porting and Java version upgrades. The GA post gives a concrete account of the Java agent: it upgrades Java 8 and 11 Apache Maven applications to Java 17, including moving Spring Boot to version 3, then builds and runs unit tests on the upgraded code, fixing issues so the project compiles cleanly. AWS states this as its own feature description; neither document independently audits how often the upgrade succeeds unattended.

The friction

The GA post carries a correction appended after publication, clarifying that Amazon Q's knowledge of a customer's account resources was available only in preview, not generally, the vendor's own retraction of an overstated claim. The product page states access controls exist and that Amazon Q respects a company's existing AWS IAM Identity Center identities, roles and permissions, but neither source spells out the specific IAM permissions a transformation job needs before reading and modifying a repository, leaving that step to separate documentation.

What changed in the work

For the software development agent, the GA post describes an accept-then-insert step: a developer enters a prompt, gets an initial plan, iterates, and only then selects an option to insert the code, a documented checkpoint, not automatic merging. For the transformation agent, the account differs: deprecated-code and build-fix steps run automatically once started, with the resulting diff available to inspect afterward rather than approve beforehand. That is a real distinction the documents support, one agent asks for a decision before writing, the other writes first and hands over the result, and a team adopting either should not assume the other's pattern applies.

• Which of the two agents in use here asks for approval before changing files, and which one changes them first?
• What IAM role or permission set does the transformation job actually run under in this account?
• Has the preview-only correction on account-resource knowledge been re-checked against the current documentation?

The two agents document two different relationships to review, and the useful precedent here is the printed correction: even a vendor's own general-availability post needed a public fix once a claim about account access ran ahead of what shipped.