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 wants to 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 hands you model access and building blocks, and you assemble the application around them. Asking which is “better” is the wrong frame, because they answer different questions. The useful frame is 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: 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 and a CLI, built for spec-driven development, where work starts from a specification 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.
Amazon Quick. A finished, managed assistant whose user is an employee and whose subject is enterprise data rather than code. It connects to internal sources (document stores, wikis, chat and mail, CRMs, databases) through built-in integrations, grounds its answers in that data while respecting each asker’s access permissions, and goes past answering: Flows automate multi-step workflows, its BI side (Quick Sight) turns questions into dashboards, and Spaces collect the knowledge a team works from. Right when the job is an internal, cross-source assistant for staff. It is not a developer tool and not a platform.
Amazon Bedrock. The platform, not an assistant. API access to foundation models from several providers behind one interface, plus the machinery an application needs: knowledge bases for retrieval over your own data, agents that plan and call tools, guardrails that enforce your policy, prompt management, evaluation, and model customisation. 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.
Side by side
| Attribute | Kiro | 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 | Days | A build project |
| Pricing shape | Per-user subscription | Per-user subscription | Usage, tokens and features |
The picks in depth
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. 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 so the assistant stays inside 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 earns its precision because 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.
A worked example: sorting the backlog
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.
- Kiro is an agentic, spec-driven development environment (an IDE and a CLI): install it and use it, with nothing to design, operate, or host.
- Amazon Quick is the finished assistant for staff over enterprise data: built-in integrations, permission-aware answers, and workflow automation and BI on top; it is neither a developer tool nor a platform.
- Reach for Bedrock when the feature ships in your product, grounded in your data and shaped by your prompts, guardrails, and interface.
- 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.
- Time to value differs sharply: the assistants are per-user subscriptions productive in a day or days; Bedrock is a build-and-operate project priced on usage.
- Service names in this area change fairly frequently; the three roles (developer assistant, staff assistant, build platform) are the stable thing to remember.