Amazon Q Developer introduced agentic coding workflows that could inspect project context, edit files, run commands, use tools, and carry multi-step development tasks through a conversational interface. By 2026, the product is in transition: AWS has announced that Amazon Q Developer IDE plugins will reach end of support on April 30, 2027, and the former Q CLI has become the Kiro CLI. That current status matters when teams decide whether to build new long-term workflows around Amazon Q Developer or migrate them toward Kiro.
This article remains part of the Generative AI on AWS authority cluster because the engineering patterns introduced through Q Developer—agentic tool use, MCP integration, custom agent context, permissions, and project-aware coding—remain highly relevant. The implementation path, however, should reflect AWS’s current product direction rather than assuming the 2025 interface will remain unchanged indefinitely.
Existing Q Developer IDE deployments can still be useful during the support window, but new platform planning should include the transition timeline.
Agentic coding changes the unit of work from answer to action
Traditional coding assistants explain code or suggest snippets. Agentic coding can inspect files, make edits, run shell commands, build the project, and iterate based on the result. That changes the risk model because the assistant is no longer only generating text—it is operating tools in a development environment.
The workflow should therefore define which tools are available, which require approval, and what parts of the repository or environment are in scope. The same prompt can be harmless in a read-only context and destructive when the agent can run deployment commands.
Agentic coding is most valuable when the tool boundary is explicit enough that developers understand what the assistant can change before approving a task.
MCP made Q Developer extensible beyond built-in tools
Amazon Q Developer added Model Context Protocol support so agents could connect to local or remote MCP servers and discover tools, prompts, and resources. The CLI supports local process servers and remote HTTP servers, including OAuth-protected remote MCP endpoints.
This is powerful because a development assistant can query databases, design tools, documentation systems, or internal services through one standard protocol. It also increases risk because each MCP server expands the agent’s capability set and may expose credentials or production actions.
The MCP configuration should therefore be treated as part of the project’s security configuration, not as a personal convenience file that receives arbitrary servers without review.
Custom agents reduce ambiguity by narrowing context and tools
Q Developer CLI introduced custom agents that combine prompt, context, available tools, and tool permissions for a particular development task. This is useful when one project needs frontend tools and another needs database or infrastructure tools.
A narrower agent has two advantages. First, the model sees fewer irrelevant capabilities, reducing tool-selection ambiguity. Second, the blast radius is smaller because the agent only receives the permissions needed for the development stage it is meant to handle.
This design principle remains useful in Kiro and other agentic development environments: specialization is often safer and more reliable than one assistant with every tool enabled.
Tool approval should reflect side effects
Q Developer’s MCP and built-in tool model distinguishes operations that can be auto-approved from those that require explicit user approval or are considered dangerous. That is the correct mental model for agentic development.
Reading a source file is different from running a destructive migration. Searching documentation is different from pushing to production. The permission policy should reflect those differences so developers are not trained to click “approve” for every action merely to keep the agent moving.
Approval fatigue is a security failure. The best workflow auto-approves low-risk repetitive operations and pauses for actions whose side effects deserve human review.
Workspace context should be curated, not maximized
Agentic coding improves when the assistant understands the repository, but loading everything can introduce noise and sensitive material. Project rules, explicit context, workspace context, and prompt libraries should point the agent toward architecture, coding standards, test commands, and relevant modules without treating the entire machine as one context source.
Secrets, production configuration, customer data, and unrelated repositories should not become convenient context just because the assistant can read them. The development environment should enforce file and credential boundaries independently of the prompt.
The same principle applies to generated changes: the agent should operate within one reviewed repository boundary rather than wandering across every available workspace.
Build and test commands are part of the agent’s feedback loop
The strongest coding workflows let the agent run tests, linters, builds, and other deterministic checks after making a change. This gives the model evidence about whether the edit actually works instead of relying only on its own textual reasoning.
Those commands should be standardized in the repository so the agent and humans run the same validation. A custom agent that uses an undocumented personal test command can produce results other developers cannot reproduce.
The planned CI/CD for GenAI Applications article addresses the production side of that discipline. Development-agent validation should feed the same release gates rather than bypass them.
The 2026 transition to Kiro should shape new investments
AWS announced in April 2026 that Amazon Q Developer IDE plugins will be discontinued on April 30, 2027 and directs developers toward Kiro for agentic coding, chat, MCP support, and spec-driven development. AWS documentation also states that the Q CLI has become the Kiro CLI.
This does not make Q Developer concepts irrelevant. It means organizations should distinguish existing supported Q workflows from net-new strategic platform choices. If a team already has Q Developer integrations, the transition window can be used to document tools, permissions, project rules, and MCP dependencies so those controls can move cleanly.
New CLI automation should follow current Kiro guidance rather than building around commands that AWS has already transitioned.
Agentic developer workflows need repository-level governance
Organizations should define which repositories allow autonomous edits, which branches agents may touch, whether commit signing is required, which secrets are available, and which external MCP servers are approved. Those policies should be enforced by source-control and CI systems rather than depending on every developer to remember the rules.
The existing CI/CD for AI article is relevant because agentic development accelerates change. Faster change makes review, automated testing, and rollback more important, not less.
An AI development agent should increase engineering throughput without becoming a side door around the controls that protect the software supply chain.
The durable lesson is to design agentic coding as a controlled tool environment
Product names and interfaces change, but the core engineering pattern remains: a coding agent needs context, tools, permissions, deterministic validation, human approval for high-impact actions, and a deployment path that can reject bad changes.
Amazon Q Developer helped normalize that workflow inside AWS development tooling. The current transition to Kiro changes where teams should invest next, but not the operational lessons. Agentic coding is successful when the assistant can act broadly enough to be useful and narrowly enough that its actions remain reviewable, reversible, and secure.
Migration planning should start with capabilities rather than plugin installation. Inventory which teams rely on agentic coding, custom agents, MCP servers, project rules, transformations, or CLI automation. Some of those patterns map directly to Kiro, while others may need new configuration or workflow design. A capability inventory is more useful than waiting until the support deadline and discovering that one important internal integration depended on Q-specific behavior.
Teams should also archive the governance they built around Q Developer. Approved MCP servers, tool permission rules, repository exclusions, secure-development guidance, and developer training remain valuable even if the client changes. Rebuilding those controls from scratch in a new tool creates an avoidable gap during migration.
For existing Q Developer IDE users, the support window should be used to reduce hidden personal configuration. Move project instructions and repeatable commands into the repository where possible, standardize approved MCP configurations, and document which identities or tokens external tools require. The more behavior lives only on one developer laptop, the harder the transition will be.
Security teams should pay special attention to remote MCP servers. OAuth support can make integration smooth, but every server is another system the agent can call. Evaluate the server owner, transport, authentication, scopes, tool descriptions, and data handling before approving it for sensitive repositories. “MCP-compatible” is a protocol property, not a security certification.
The transition is also an opportunity to measure whether agentic workflows actually improve delivery. Compare cycle time, review burden, defect rate, test quality, and developer satisfaction rather than counting generated lines of code. A coding agent that produces more code but increases review and rollback work may reduce throughput despite high usage.
Teams should also decide how long to support two tooling paths in parallel. Running Q Developer and Kiro indefinitely can split configuration, developer training, and MCP governance. A staged migration with a defined end state is easier to secure and support than an open-ended period where every developer chooses a different agentic environment.
The migration plan should be explicit and time-bound.
