The situation
A platform team of a dozen engineers wants two things at once. The first is to move faster day to day: less time writing boilerplate, faster answers to “how does this service work”, quicker unit tests, and a hand with a stalled Java 8 to Java 17 upgrade that nobody has time to finish. The second is a product ask from the business: the company’s customer portal should gain a natural-language assistant that answers questions about a customer’s own account, drafts replies, and summarises recent activity, all grounded in the company’s private data.
The proposals in the room have multiplied. One engineer would point everything at Amazon Bedrock, because Bedrock has the models. Another has been using Kiro on a side project and wants seats for the whole team, but is not sure whether it covers the portal work too. A third saw Amazon Quick demoed at a conference and cannot say how it differs from either of the others, only that it also answers questions with an AWS logo on it.
The two needs look similar because both involve a generative model, but they sit on opposite sides of a line. One is about making the engineers who build the product faster. The other is a feature the product itself has to ship. Choosing the wrong shape for either means building something AWS already sells finished, or trying to bend a finished assistant into a product it was never meant to be.
What actually matters
The distinction that decides everything is finished product versus building block. A finished assistant is something you switch on and use: no application to design, no model to select, no retrieval pipeline to wire. A platform is the opposite by design: it provides model access and building blocks, and you assemble the application around them. The two answer different questions, so ranking one above the other leads nowhere. Sort by who the output is for.
If the output is for your own engineers, and the value is that they write, understand, test, and modernise code faster, a finished developer assistant is the fit and building anything is wasted effort. If the output is for your customers, embedded in your product, shaped by your data and your rules, you are building an application and need a platform underneath it. And if the output is for your own staff asking questions across internal documents and systems, that is a third audience with its own finished product, easily misfiled as either of the other two.
The audience frame also keeps the three products from competing when they should compose. The natural arrangement for this team is the developer assistant helping write the code for the Bedrock application that becomes the portal feature. The assistant makes building faster; the platform is what gets built. Reaching for one does not rule out the others.
Cost and effort follow the split. The finished assistants are per-user subscriptions, some with a monthly allowance of agent work on top of the seat: pay for seats, productive the same day. Bedrock is usage-priced on tokens and features, and carries the cost of designing, building, evaluating, and operating an application. One is an operating expense you switch on; the other is a project you staff. Be aware, too, that service names in this area change fairly frequently; the three roles are the stable thing.
What we’ll filter on
- Who is the output for, your own engineers, internal staff, or your product’s end users?
- Finished product or building block, something to use today or a platform to build on?
- Subject matter, source code and AWS, or your own enterprise and customer data?
- Customisation depth, does the value depend on your prompts, your data, your guardrails, and your interface?
- Complementary fit, could one tool build the thing another tool ships?
The landscape
Kiro. The developer assistant: an agentic development environment spanning an IDE, a CLI and a browser interface, built for spec-driven development, where work starts from a specification of requirements, design and tasks that the agent plans against rather than from a blank completion. It fills the finished-product role for engineers: you install it and use it, with nothing to design, no model to choose, and no pipeline to operate. It sells as a per-user monthly subscription with a credit allowance for agent work.
Amazon Q Developer. The other finished assistant aimed at engineers. It sits in the AWS console and documentation site, in chat applications, and in IDE plugins, rather than in a spec-first environment of its own. In the console it answers questions about your own AWS resources and costs, diagnoses common console errors, and opens a Support conversation without leaving the page. It also helps with code written against the AWS SDKs and the AWS CLI. In the IDE it chats about code, completes lines, scans for security vulnerabilities, and runs Java language upgrades as transformation jobs, taking a Maven project from Java 8 or 11 to Java 17 or 21 and handing back a diff to accept. One caveat governs all of that IDE work: AWS discontinues support for the Amazon Q Developer IDE plugins on 30 April 2027 and points the same capabilities at Kiro, so a team choosing today should read Q Developer as the console-side assistant. Both it and Kiro sell developer productivity, and neither is a platform.
Amazon Quick. A finished, managed assistant whose user is an employee and whose subject is enterprise data rather than code. Knowledge bases index content from S3, SharePoint, OneDrive, Confluence, Google Drive and web crawlers. Connectors built from OpenAPI specifications or MCP servers let it read and act in other systems, and extensions put it inside Chrome, Slack, Teams and Microsoft 365. Access is granted per knowledge base, with document-level ACLs on the sources that support them, so scoping who sees what is a configuration job rather than something inherited whole from the source system. It goes past answering, too: Flows automate multi-step tasks, Quick Sight is the BI side that turns questions into dashboards, and Spaces gather the documents, dashboards and datasets an agent draws on. It fits when the job is an internal, cross-source assistant for staff. It is not a developer tool and not a platform.
Amazon Q Business and Amazon Q Apps. The same staff-assistant role under the earlier name, and closed off now: Amazon Q Business is no longer open to new customers, existing customers get bug fixes and security updates but no new features, and AWS directs the work to Quick. Q Business was the managed enterprise-RAG assistant: connect the wikis, mailboxes, ticket systems and document stores, ask a question in plain language, get an answer grounded in those sources and filtered by what the asker is allowed to see. Amazon Q Apps were the small, purpose-built applications someone in the business built on that connected data without writing code, and they migrate to Quick Flows. Read all of these names as one role, staff assistant over enterprise data, and start anything new on Quick. Whether the managed assistant covers the need at all is a separate call, weighed against building the retrieval application yourself.
Amazon Bedrock. The platform, not an assistant. API access to more than a hundred foundation models, from Amazon, Anthropic, OpenAI, xAI and others, behind one interface, plus the machinery an application needs: knowledge bases for retrieval over your own data, guardrails that filter content and check responses against their sources, and model customisation. Agents have moved: Amazon Bedrock Agents is now Bedrock Agents Classic and is closed to new customers, so an agent that plans and calls tools is built on Amazon Bedrock AgentCore instead. You bring the use case, the prompts, the data, and the interface. It is where a customer-facing feature gets built, because that feature needs your data, your rules, and your product’s surface, none of which a finished assistant exposes.
Evaluation
Side by side
The first two columns are the developer assistants and sit together; they differ in shape, not in who they serve.
| Attribute | Kiro | Amazon Q Developer | Amazon Quick | Bedrock |
|---|---|---|---|---|
| Finished product you use | ✓ | ✓ | ✓ | ✗ |
| Building block you develop on | ✗ | ✗ | ✗ | ✓ |
| Audience is your own developers | ✓ | ✓ | ✗ | ✗ (whoever you build for) |
| Audience is internal staff | ✗ | ✗ | ✓ | ✗ (whoever you build for) |
| Powers a feature in your product | ✗ | ✗ | ✗ | ✓ |
| Works with source code and AWS | ✓ | ✓ | ✗ | ✓ (if you build it) |
| Grounds answers in your own data | ✗ | ✗ | ✓ | ✓ (you configure it) |
| You pick the model and prompts | ✗ | ✗ | ✗ | ✓ |
| Time to value | Same day | Same day | Days | A build project |
| Pricing shape | Subscription plus credits | Free and Pro tiers per user | Per-user subscription | Usage, tokens and features |
The solution
The developer-productivity half of the situation is a clean finished-assistant case, and the tell is that every item on the list is about the engineers, not the product. Boilerplate, questions about how a service works, unit tests, and the Java upgrade are all things a finished assistant does out of the box, and building any slice of that on Bedrock would mean reconstructing a supported product. So the team adopts Kiro: same-day seats, and the stalled Java 8 to 17 upgrade is exactly the kind of multi-file, plan-first job a spec-driven agent is built for. Hand it the migration spec, let it plan the changes, review the diffs. Amazon Q Developer covers the same half of the situation from the console side, answering questions about AWS resources and diagnosing console errors, and its IDE plugin can run the Java upgrade as a transformation job. That IDE path has an end date of 30 April 2027, though, and AWS routes the capability to Kiro, so a team standing this up now starts there. Either way, nobody builds anything.
The customer-portal half is a clean Bedrock case, and the tell is the opposite: the output is for end users, it must be grounded in the company’s private customer data, and it lives inside the product’s own interface with the company’s own rules about what it may say. None of that is exposed by any finished assistant. Building it on Bedrock means choosing a foundation model, grounding answers through a knowledge base so replies cite real account activity, configuring guardrails that filter responses against policy, and wiring it into the portal. It is a build-and-operate project, priced on usage, and that is the correct shape for a feature the company ships to customers.
Amazon Quick is the pick for neither half, and it is the easiest of the three to misfile. It is finished, so it is not a platform and cannot become the portal feature. Its audience is internal staff over enterprise data, so it is not the developer tool either. If the company later wants an internal assistant for employees to query the wiki and the document store, or to automate the workflows that follow those answers, Quick becomes the right answer to that separate question.
The part that ties the situation together is composition. The team does not choose an assistant instead of Bedrock; it uses the assistant to build the Bedrock application. The engineers lean on Kiro to write the portal feature’s code, generate its tests, and stand up its infrastructure, and the thing they are building is the Bedrock-backed assistant the customers will use. The productivity tool and the platform sit at different layers and work together.
Worked example
Picture the team’s backlog with each item tagged by the single question of who the output is for.
“Cut the time it takes to scaffold a new microservice” is for the developers, so it is the finished assistant: hand Kiro the spec and let it plan and generate the scaffold. “Finish the Java 17 upgrade on the billing service” is for the developers too: a spec-driven migration the agent plans and the team reviews. “Add a natural-language assistant to the customer portal that answers account questions” is for end users and needs the company’s data and interface, so it is the Bedrock build: model plus knowledge base plus guardrails behind the portal. “Generate the unit tests the billing upgrade needs” is for the developers again, the assistant’s job, ideally right after the migration while the changes are fresh.
Then the one that looks ambiguous. “Let customer-support staff ask questions across our internal runbooks and past tickets” is not for developers and not for the product’s end users; it is for internal staff over enterprise data. That is the Amazon Quick shape, a separate finished assistant for a separate audience, and recognising it keeps it from being mis-sorted into either a Bedrock build or a developer seat.
The backlog sorts itself once each item answers the who-is-it-for question first. Everything aimed at the engineers collapses onto a finished assistant with no build. The one feature aimed at customers is the Bedrock project. The internal-staff item lands on the third product.
What’s worth remembering
- The deciding question is finished product versus building block: Kiro and Amazon Quick are assistants you use; Bedrock is a platform you build on.
- Sort by who the output is for: your engineers point to Kiro, internal staff to Amazon Quick, and your product’s end users to a Bedrock build.
- Trying to turn a finished assistant into your product’s feature fails, because none exposes the model, data, or interface at that level.
- The products compose: the team uses the developer assistant to build the Bedrock application its customers will use.
- Learn the names by role: Kiro and Amazon Q Developer are assistants for engineers, Amazon Quick is the assistant for staff, and Bedrock is the platform your product’s own feature is built on.
- Names in this area close and move: Amazon Q Business and its Q Apps take no new customers, and the Amazon Q Developer IDE plugins lose support on 30 April 2027, so learn the three roles (developer assistant, staff assistant, build platform) rather than the labels.