Amazon Killed Q Developer, Built Kiro, and Told Developers: Read the Manual First

You know that friend who builds IKEA furniture without reading the instructions? Every group has one. He opens the box, looks at the picture on the front, grabs a screwdriver, and starts going at it with the unshakeable confidence of a man who has never been wrong about anything in his life.

Forty-five minutes later he’s sitting on the floor surrounded by Allen wrenches, holding three mystery screws, staring at a bookshelf that has one shelf installed backwards and a drawer that only opens if you kick it. “It’s fine,” he says. “It works.”

That’s vibe coding. And Amazon just spent two years watching the whole industry do it before standing up and saying: “Maybe read the damn instructions first.”

---

The Part Where Amazon Killed Its Own Tool

On May 15, 2026, Amazon did something you don’t see often in Big Tech. They killed their own AI coding tool.

Q Developer — Amazon’s answer to GitHub Copilot — got the sunset notice. No new sign-ups. No new paid subscriptions. Full end-of-support by April 2027. Done.

This wasn’t a quiet deprecation. This was Amazon admitting, publicly, that the approach they’d been pushing for two years wasn’t working. Q Developer was a code-completion tool. You typed, it suggested. You prompted, it generated. Fast, flashy, zero friction. The AI coding equivalent of that IKEA guy with the screwdriver.

The problem? The same one that friend discovers when the bookshelf collapses at 3 AM: speed without structure produces garbage.

We already covered the tokenmaxxing fiasco — Amazon employees gaming their KiroRank AI leaderboard by running pointless tasks to inflate usage scores. But the Q Developer story goes deeper. The tool was generating code that shipped fast and broke faster. It’s worth remembering: for every $1 spent on AI tokens, $0.82 goes to cleaning up the mess.

Amazon’s official statement was diplomatic: “Impactful AI experiences require understanding entire projects beyond code generation.” Translation: our tool was writing code without understanding what it was building. Just like that guy with the IKEA bookshelf.

---

Enter Kiro: The IDE That Won’t Let You Skip the Instructions

So Amazon razed Q Developer and built Kiro — a full IDE based on VS Code that takes a fundamentally different approach to AI coding.

The core idea is almost aggressively simple: before writing any code, write down what you want.

I know. Revolutionary. Truly breaking new ground here. Next they’ll suggest reading documentation before using an API.

But hear me out, because the way Kiro implements this is actually interesting.

When you tell Kiro “add a review system for products,” it doesn’t start spitting out code. Instead, it goes through three phases:

Phase 1 — Requirements. Kiro generates formal user stories with acceptance criteria. Your one-sentence prompt expands into multiple stories covering edge cases you didn’t think about. These live as requirements.md in your .kiro/specs/ directory. Plain markdown. Readable. Reviewable.

Phase 2 — Design. Kiro analyzes your existing codebase and generates a technical design doc — component architecture, data models, error handling strategy, testing approach. Again, markdown. Again, reviewable. The AI is showing you its homework before turning it in.

Phase 3 — Tasks. An ordered implementation checklist where each task links back to specific requirements and typically takes 5-15 minutes. Small enough to review. Small enough to catch when things go sideways.

Only then — after requirements, design, and task breakdown — does Kiro start writing code. And each task produces a reviewable increment, not a 500-line diff that makes your eyes glaze over.

It’s like IKEA went from “here’s a box of parts, good luck” to “here’s a box of parts, a set of instructions, a diagram of the finished product, AND a checklist you tick off as you go.” Some people will call this genius. Others will call it annoying. Both are right.

---

100,000 Developers in Five Days (Then the Waitlist)

Kiro launched in public preview in July 2025. Within five days, over 100,000 developers had signed up. AWS had to impose a waitlist and daily usage caps because demand crushed their infrastructure.

By October, “hundreds of thousands” of developers were on the waitlist. By December, AWS CEO Matt Garman featured Kiro in his re:Invent keynote and dropped a stat that made everyone’s eyebrows go up: a project originally estimated at 30 developers over 18 months was completed by 6 developers in 76 days using Kiro.

That’s not a “10-20% efficiency gain.” That’s a different number entirely.

Garman also confirmed that Kiro is now AWS’s standard internal development environment. Amazon doesn’t just sell this tool. They use it. That’s either a genuine endorsement or the most expensive dogfooding exercise in history.

---

The Spec Tax: Martin Fowler Has Concerns

Not everyone’s buying it.

Birgitta Bockeler at ThoughtWorks (Martin Fowler’s team) tested Kiro and found that the spec-driven approach can be wildly disproportionate for simple tasks. A basic bug fix generated “4 user stories with a total of 16 acceptance criteria.”

She compared it to using a sledgehammer to crack a nut.

And she raised a deeper question: does elaborate specification actually improve control, or does it create a “false sense of control” through documentation overhead? You’ve got beautiful requirements. Detailed design docs. Ordered task lists. Everything looks professional and organized. But are the specs actually making the code better, or are they just making you feel better about code you haven’t reviewed?

It’s a fair point. If you’ve ever worked at a company where the Jira tickets were immaculate but the code was on fire, you know this feeling.

---

What Developers Actually Say

The reception has been genuinely mixed, and for once, the mixed reviews are interesting:

The good: Multiple developers reported the spec phase as “a surprisingly useful thinking partner” that catches edge cases they would have missed. Peter McAree shipped a feature using Kiro and said it “eliminated typical integration nightmares” because the progressive task structure caught problems early. The consensus from fans: Kiro doesn’t just write code faster — it forces you to think about what you’re building, which is the part most AI tools skip entirely.

The bad: Tasks get stuck, fail, and sometimes lose context — forcing developers to restart from scratch. The free tier has a data-use clause that made one Hacker News commenter call it “the biggest lie of the 21st century.” And the model selection is currently limited compared to Cursor’s multi-provider flexibility.

The honest: One developer who built a demo game “almost 95% AI-coded” with Kiro later clarified he rejected roughly 75% of the initial outputs and iterated heavily. So the “95% AI-coded” headline was technically true but practically misleading. Sound familiar? This is the METR paradox all over again — the gap between what AI coding looks like from the outside and what it actually takes.

---

The Uncomfortable Question: Is This Just Waterfall With a Chatbot?

Let’s address the elephant. Requirements → Design → Implementation. That’s waterfall. Amazon took the development methodology that the entire industry spent 20 years running away from and handed it to an AI.

But here’s the difference, and it’s not nothing: the spec phase in Kiro takes minutes, not months. You’re not writing a 40-page requirements document that goes to a change advisory board and comes back six weeks later with 14 comments from people who won’t use the software. You’re having a conversation with an AI that expands your one-liner into structured requirements in about 90 seconds.

It’s waterfall at the speed of a conversation. Which might actually be what waterfall was supposed to be before committees got involved.

The real question isn’t “is this waterfall?” It’s “does thinking before coding produce better software than coding before thinking?” And the answer to that is so obviously yes that it shouldn’t need a $200/month IDE to prove it.

---

What This Means If You Write Swift

If you’re an iOS developer comparing your options, here’s the honest landscape as of June 2026:

Kiro is the spec-first choice. Great for teams, complex features, regulated industries. The spec workflow would be genuinely useful for building something like a subscription management system or a payment flow — the kind of feature where missing one edge case costs real money.

Claude Code is the power tool. Terminal-native, deepest reasoning, best for senior developers who want to operate at the architecture level. The 46% “most loved” rating among 10+ year developers isn’t accidental.

Xcode’s AI agents are the home team advantage. Tightest Swift/SwiftUI integration, but still maturing. If you live in Xcode, this is your most frictionless option.

Cursor remains the most polished general IDE with the largest community and fastest iteration speed. Still the default recommendation for solo developers who want speed above all else.

The interesting move would be combining approaches: use Kiro-style thinking (write your requirements and design first, even if just in a markdown file) with whatever tool you actually code in. The spec-driven methodology doesn’t require Kiro. It just requires you to think before you type. Which was free last time I checked.

---

The Instructions Were There the Whole Time

Amazon learned the same lesson that every IKEA customer eventually learns: the instructions aren’t there to slow you down. They’re there because the person who designed the bookshelf knows where the screws go, and you don’t.

Q Developer let developers skip the instructions. Kiro makes them read. Whether that trade-off is worth it depends entirely on whether you’re building a side project or a payment system that handles millions of transactions.

But the broader trend is clear. The vibe coding hangover is real. The brain fry is real. The tokenmaxxing waste is real. And the industry’s response is slowly shifting from “go fast” to “go right.”

Kiro might not be the answer for everyone. But the question it’s asking — “do you actually know what you’re building?” — is the one every developer should answer before touching a keyboard. AI or otherwise.

And maybe, just maybe, read the manual first. Those three extra screws aren’t supposed to be there.

---

Related Reading

• Tokenmaxxing: Amazon Built an AI Leaderboard and Employees Strapped It to the Dog
• They Called It ‘Brain Fry’ — The AI Burnout Nobody Warned You About
• The Vibe Coding Hangover: Startups Are Rebuilding From Scratch
• Claude Code vs Cursor for iOS Developers
• I’ve Been Pair Programming With Xcode’s AI Agent for 3 Months