What exactly is happening and when
As of 15 May 2026, Amazon has closed the sign-up door on Q Developer. No new individual, Pro, or Pro+ accounts can be created. Existing subscribers retain full access to their current plan until the service reaches end-of-life on 30 April 2027 — roughly eleven months from today. After that date, Q Developer will no longer operate, and any CI/CD pipelines, IDE plugins, or security scanning workflows that depend on it will stop functioning.
The sign-up block is not a soft deprecation signal — it is the first hard gate of a structured wind-down. Amazon typically follows a consistent pattern when sunsetting developer tools: access freeze, feature freeze, then service termination. Teams relying on Q Developer should treat the April 2027 date as a firm deadline, not a provisional one. Amazon enterprise agreements that bundle Q Developer access will need to be renegotiated or allowed to lapse; teams on AWS Partner Network programmes that standardised on Q Developer as the default AI coding tool for client engagements face a particularly pressing re-tooling challenge.
Amazon Q Developer launched in 2023 as the successor to CodeWhisperer, rebranding and expanding the product to include conversational coding assistance, security vulnerability scanning, and deep integration with AWS services. It was available as a plugin for VS Code, JetBrains IDEs, Visual Studio, and the AWS Cloud9 environment, as well as through the AWS console. At its peak it was one of the most widely deployed AI coding assistants in enterprise AWS shops, particularly in regulated industries where its security scanning capability — able to flag common vulnerability patterns in real time — had genuine differentiation.
What makes the sunset notable is not just the product retirement, but what Amazon is pivoting to. Kiro is not an incremental upgrade to Q Developer. It represents a fundamentally different theory of how AI should assist software development.
What Kiro is and how spec-driven development differs from today's AI coding tools
The dominant paradigm in AI coding assistance today is what practitioners have started calling "prompt-and-patch": a developer describes a task in natural language, the AI generates code, the developer reviews it, identifies errors or mismatches with intent, patches them, and repeats the loop until the output is acceptable. This works reasonably well for isolated, self-contained tasks — write a function, generate a test, explain a stack trace — but it degrades badly as task complexity increases. The more context required, the more correction rounds the developer must invest, and the more cognitive load they must carry to track which parts of the AI's output are correct and which are not.
Kiro's bet is that the right entry point for AI assistance is not a prompt but a specification. Before Kiro writes a single line of code, the developer — or the developer working with Kiro itself — produces a requirement specification: a structured document that describes what the code should do, what its inputs and outputs are, what constraints apply (performance budgets, security requirements, error handling expectations), and what the acceptance criteria look like. This is conceptually similar to what a senior engineer writes before a complex feature implementation — a design document — but formalised into a machine-readable structure that Kiro can parse and reason over.
Once the spec exists, Kiro decomposes it into a task graph: a directed set of sub-tasks with explicit dependencies. It then executes those tasks autonomously — writing code, running tests, validating outputs against the spec's acceptance criteria — and only surfaces decisions to the developer when it encounters ambiguity the spec does not resolve, or when a task fails in a way it cannot self-correct. The developer's role shifts from prompt-author and patch-reviewer to spec-author and exception-handler.
This is a materially different cognitive model. The upfront investment in writing a good spec is higher than typing a prompt. But proponents argue that the spec itself becomes a durable artefact — it documents intent, serves as the basis for future changes, and gives the next developer (or the next AI session) enough context to work from without reconstructing the original author's reasoning. In that framing, spec-driven development is not just a workflow change; it is a shift in what the primary unit of developer output is. A good spec, Kiro's positioning implies, is more valuable than a good prompt.
Q Developer sign-ups closed on 15 May 2026. Full service termination is 30 April 2027. Any IDE plugins, security scanning pipelines, or CI/CD integrations that depend on Q Developer must be replaced before that date. Begin your evaluation of alternatives now — allow at least 60 days for a proper trial before committing to a replacement tool.
Migration paths for current Q Developer users
The most straightforward path for teams deeply embedded in the AWS ecosystem is a direct migration to Kiro. Amazon has positioned Kiro as the spiritual successor to Q Developer, and it carries forward Q Developer's deep awareness of AWS service APIs, IAM patterns, CloudFormation and CDK constructs, and common AWS security anti-patterns. Teams that found Q Developer's AWS context helpful — particularly those building Lambda functions, ECS services, or Bedrock integrations — will likely find that context preserved in Kiro. The migration effort centres on learning the spec-writing workflow rather than re-learning AWS-specific context.
For teams where Q Developer's AWS-specificity was not a primary driver of adoption — teams that used it primarily as a general-purpose inline autocomplete tool — the migration calculus is more open. Three alternatives deserve serious evaluation.
Claude Code from Anthropic is a terminal-first agentic coding tool that operates across an entire repository rather than within a single editor window. Its primary strength is long-context reasoning: it can hold large codebases in context, trace dependencies across files, and sustain coherent multi-step refactoring sessions that would fragment over many prompt-and-patch cycles. The recent addition of /autopilot mode in Claude Code v1.0.45 and later moves it meaningfully toward autonomous task execution, though it stops short of Kiro's full spec-as-primary-artefact model. For teams doing complex architectural work or large-scale refactoring, Claude Code is currently the strongest alternative to a spec-driven approach. It bills through Anthropic's API on token consumption — predictable in unit cost, variable in total spend depending on session depth.
Cursor has grown rapidly and now represents the strongest challenger in the IDE-native agentic coding space. Its Composer and agent modes handle multi-file, multi-step changes with high reliability, and the .cursorrules configuration file allows teams to embed project-specific context — architecture constraints, coding conventions, preferred patterns — directly into every AI session. Teams that have invested in well-written .cursorrules configurations report substantial improvements in code quality, with some citing reductions in PR review cycles of around 70%. For a direct performance comparison between Cursor's agent mode and Claude Code on real engineering tasks, see our earlier analysis of Cursor Composer 2 vs Claude Code.
GitHub Copilot remains a credible option, particularly for teams already deeply integrated with GitHub's ecosystem — repositories, Actions, Projects, and Packages. It is worth noting, however, that GitHub moved Copilot to usage-based billing on 1 June 2026 — a change we covered in detail in our article on GitHub Copilot's consumption pricing shift. Teams evaluating Copilot as a Q Developer replacement should factor the new pricing model into their total cost of ownership calculations.
Do not evaluate replacement tools on toy projects. Run a two-week trial on a real feature from your production backlog, with your actual team, using your actual tech stack. Measure completion acceptance rate, CI pass rate on AI-generated code, and the time engineers spend in review and correction. Those three metrics will tell you more than any vendor benchmark.
Comparison table: Kiro vs Claude Code vs Cursor vs Copilot
The four leading AI coding tools differ significantly in their interaction model, integration depth, and pricing structure. The table below maps the key differentiators across the dimensions most relevant to a migration decision.
| Dimension | Kiro (Amazon) | Claude Code (Anthropic) | Cursor | GitHub Copilot |
|---|---|---|---|---|
| Interaction model | Spec-driven task graph; write spec, Kiro executes | Terminal-first agentic; prompt + /autopilot mode | IDE-native agent; Composer + .cursorrules | IDE inline + Chat + agent mode (multi-file) |
| Primary strength | AWS ecosystem depth; spec-to-code automation | Long-context, whole-repo reasoning and refactoring | Multi-file agent with rich project context | GitHub ecosystem integration; PR review; chat |
| AWS-awareness | Excellent — native | Good — general; no native AWS tooling | Good — via project context | Moderate — via GitHub Copilot Extensions (AWS) |
| IDE support | VS Code; JetBrains (announced) | Terminal / any editor via CLI | Cursor (fork of VS Code) | VS Code, JetBrains, Visual Studio, Neovim |
| Upfront workflow cost | High — spec-writing is a new skill | Low — familiar CLI prompt model | Medium — .cursorrules investment pays dividends | Low — familiar inline + chat model |
| Pricing model | Consumption (AWS billing); no flat rate | API token consumption (Anthropic) | Seat + fast-request consumption tier | Usage-based from 1 June 2026 |
| Security scanning | Yes — built-in, AWS-focused | No native scanning; third-party via MCP | No native scanning | Copilot Autofix (GitHub Advanced Security) |
| On-premises option | No | No (API-dependent) | No | GitHub Enterprise Server (limited) |
The table reveals a clear fork in migration strategy. If your team's primary use of Q Developer was security scanning and AWS API assistance during development, Kiro is the natural home — it carries forward both capabilities and adds the spec-driven workflow on top. If your team used Q Developer primarily as a general-purpose coding assistant and the AWS specificity was incidental, Claude Code and Cursor both offer stronger agentic capabilities with lower switching costs in the short term, and neither requires learning a new mental model of what a developer's primary output should be.
Builder perspective: is spec-driven development actually better?
The honest answer is: it depends entirely on what you are building and how your team thinks.
The case for spec-driven development is strongest in environments where requirements are genuinely stable before implementation begins — large enterprise feature delivery, regulated system changes that require documented intent, or greenfield projects where the architect can define the full problem space before a line of code is written. In these contexts, the spec is not extra work; it is work that would have been done anyway (as a design document, a ticket, a PRD), now formalised in a way that the AI can directly consume. The cognitive overhead of writing the spec is offset by the reduction in correction cycles during implementation, and the spec itself becomes a compliance and audit artefact.
The case against spec-driven development is strongest in exploratory, iterative contexts — hackathons, prototype development, debugging sessions, and any situation where the developer is genuinely discovering the problem as they code. Forcing a spec-first workflow onto exploratory work introduces artificial structure into a phase that benefits from fluidity. A developer trying to understand why a distributed system is exhibiting unexpected latency behaviour does not benefit from writing a requirement spec before starting the investigation. Prompt-and-patch, for all its messiness, is the right tool for that job.
Kiro's implicit bet is that most professional software development — particularly at the enterprise scale where Amazon's customers operate — falls into the first category more than the second. That is probably directionally correct for feature delivery work, but it risks creating friction for the exploratory and debugging phases that make up a larger share of a typical engineer's week than their task tickets suggest.
There is also a skill acquisition question. Writing a good requirement spec is not a universally distributed skill. Senior engineers who have spent years writing design documents, RFC proposals, and technical specifications will find the spec-writing workflow natural. Junior engineers who have grown up in an era of conversational AI assistance may find it unfamiliar and initially slower. Teams adopting Kiro will need to invest in spec-writing craft — not just in tool proficiency — and that investment should be budgeted explicitly, not assumed to happen automatically.
The competitive context matters here too. Windsurf's acquisition by Cognition — the team behind the Devin autonomous coding agent — in early 2026 signalled that the market is moving toward more autonomous, less prompt-dependent coding environments. Cursor's parallel agents work reported in Cursor 3's parallel agent model points in the same direction. Kiro is not alone in betting that the future of AI coding assistance is more structured and more autonomous than today's chat-based tools. The question for engineering leaders is not whether spec-driven development is the future — it very plausibly is — but whether Kiro is the right implementation of that future for your specific team today.
Before committing to Kiro's spec-driven workflow, pilot it specifically on the type of work where it should excel: a well-defined feature delivery task with stable requirements. Compare the total engineer time — including spec-writing — against your team's historical velocity on comparable tasks using Q Developer or another tool. If spec-driven is genuinely faster end-to-end, the data will show it. If it is slower, you have evidence to either push back on the migration or request additional spec-writing training before committing.
UK and India context: which teams are most affected
The Q Developer sunset lands differently depending on where you are and what sector you work in.
In the United Kingdom, the most exposed teams are large-scale Java and Python engineering organisations in financial services — banking, insurance, asset management, and fintech. These are precisely the environments where Q Developer's security scanning found the most traction: regulated codebases with strict vulnerability management requirements, where the ability to flag common CWE patterns in real time during development (rather than catching them in a dedicated SAST scan later in the pipeline) had genuine workflow value. Several major UK banks and insurers standardised on Q Developer through AWS enterprise agreements, and those teams now face a material re-tooling exercise.
The UK fintech sector, which skews toward smaller, faster-moving engineering teams, is somewhat less exposed — many of those teams are already using Cursor or Claude Code as their primary AI coding tool, and Q Developer may have been an add-on rather than a dependency. For them, the sunset is largely administrative.
The picture is notably different in India. The most significantly affected cohort is the IT services sector — the large system integrators and managed services providers that run AWS delivery engagements at scale for clients across multiple verticals. Organisations like Infosys, Wipro, TCS, HCL Technologies, and their mid-market counterparts standardised on Q Developer as the default AI coding tool for AWS-related client work, often through AWS Partner Network agreements that included Q Developer access. Those standardisation decisions now need to be revisited, and the implications ripple through client SLAs, delivery methodology documentation, and potentially pricing models for ongoing engagements where AI-assisted productivity was built into the cost basis.
Indian product companies — particularly SaaS and infrastructure businesses that are AWS-native — face the more straightforward Kiro migration path. They are likely to find Kiro's AWS context awareness equally valuable to what they had in Q Developer, and the spec-driven workflow may actually align well with the engineering rigour that well-run product engineering teams already practise around design documents and RFC processes.
For both UK and India teams, the hiring implications are worth noting. As we reported in our analysis of AI engineer hiring and retention trends in 2026, engineers with demonstrated proficiency in agentic coding tools command a meaningful premium. The transition from Q Developer to Kiro — or to Claude Code or Cursor — is also an opportunity to upskill, and teams that invest in that upskilling proactively will be better positioned both for productivity gains and for talent retention. Engineers who learn to write well-structured specifications that AI can execute autonomously are developing a skill that will be durable regardless of which specific tool wins the agentic IDE race.
Our Verified AI Builders directory includes engineering leaders across the UK and India who have navigated major AI tooling transitions. If you are working through the Q Developer migration or evaluating Kiro against alternatives, add your profile to connect with practitioners who have been through it.
The broader market moment
The Q Developer sunset and Kiro launch do not happen in isolation. They are one data point in a broader consolidation of the AI coding tools market that has been accelerating through the first half of 2026.
Windsurf's acquisition by Cognition — the team behind Devin — in early 2026 reduced the number of independent, well-capitalised AI coding tool providers. Cognition's thesis, which Kiro's launch reinforces from a different direction, is that the future of AI-assisted development is autonomous task execution rather than human-in-the-loop suggestion. The two approaches differ in implementation — Devin and Windsurf operate as autonomous agents with minimal human direction, while Kiro requires a human-written spec as the primary input — but they converge on the conclusion that prompt-and-patch is a transitional paradigm, not the destination.
GitHub Copilot's move to usage-based billing and Amazon's pivot to Kiro both suggest that the major platform players have concluded the easy-growth phase of AI coding assistance is over. The next phase is about differentiation through workflow integration depth rather than raw model capability — which is why Kiro's spec-driven model, Cursor's .cursorrules project context, and Claude Code's repository-wide reasoning all represent genuine strategic bets, not just feature additions.
For engineering leaders, the implication is that the tooling decisions made in 2026 will shape team workflows for longer than previous tooling decisions did. The AI coding tool that a team standardises on today will likely inform their hiring criteria, their onboarding process, their internal documentation standards, and potentially their client delivery methodology for several years. That warrants more deliberate evaluation than a two-week hackathon — and it warrants building internal evaluation expertise, not just reading vendor documentation.
For a broader view of how the agent SDK and orchestration layer are evolving in parallel with IDE-level tools, our piece on the agent SDK wars between OpenAI, Google, and Anthropic provides useful context on where the infrastructure layer is heading.
What to watch for in the coming months
There are four developments worth tracking as the Kiro story unfolds over the remainder of 2026.
First, Kiro's JetBrains support. Amazon announced JetBrains IDE integration is coming, but has not confirmed a date. For the large cohort of enterprise Java teams — particularly in UK banking and Indian IT services — who live in IntelliJ IDEA, the absence of JetBrains support is a real friction point for Kiro adoption. Watch for that announcement closely.
Second, Kiro's pricing model. Amazon has positioned Kiro as a consumption-based product billed through AWS, but the specific per-task or per-token rates have not been published at the time of writing. For teams replacing Q Developer's subscription pricing with Kiro's consumption model, the total cost of ownership comparison will not be possible until those rates are public.
Third, spec-writing tooling. The spec-driven model is only as productive as the tooling that helps engineers write good specs. If Kiro ships spec templates, validation tools, and examples for common enterprise patterns — CRUD services, event-driven architectures, REST API design, Lambda functions — the workflow adoption curve will be significantly shallower. Watch for what Amazon ships around the spec authoring experience in the first few months.
Fourth, the security scanning story. Q Developer's real-time vulnerability scanning was a meaningful differentiator in regulated environments. Amazon has indicated Kiro will carry forward security scanning capability, but the specifics of how that integrates with the spec-driven workflow — does the spec include security requirements that Kiro validates against? does scanning run as a task in the task graph? — will determine whether it is as useful as what Q Developer offered or merely equivalent on paper.
AI Tech Connect will continue to track Kiro's development and cover the Q Developer migration story as it unfolds. For the latest product developments across the AI coding tools landscape, see our Product news section.