AWS Builds Agentic Integrated Developer Environment

Beware the ides of March. So said the soothsayer, warning Julius Caesar of his impending assassination, which would come on the “ides” (15th, middle day of the month) of March, in 44 BC. Today, that soothsayer might update his omen and tell software application developers that they should beware the IDEs that don’t “march forward” with agentic AI accelerators.

Newly minted this year, Kiro is an agentic integrated development environment (that’s our new ides here, or IDE) from AWS. The technology is built with the power of AI agents and also combines traditional software development lifecycle practices to create production-ready applications. Developers get the full AI coding experience, plus the structure needed for production.

What Is An IDE?

A fundamental part of the programmer’s arsenal, an IDE contains a source code editor (for writing code to the correct syntax), a compiler (to transmogrify code into machine language and execute it), a debugger (does what it says on the label), build automation tools (core test and application packaging functions, rather than AI itself) as well as essential project management and version control functionalities to help keep projects in line, especially those where there are plenty of cooks adding to the broth.

The most popular and widely used IDEs include Visual Studio, created by Microsoft. Then there’s Eclipse, created by IBM, but open sourced practically from the point of inception back in 2001. Also in the mix is PyCharm, developed by JetBrains and used extensively in Python language-based development, Xcode for Mac developers and IntelliJ IDEA (again by JetBrains), an IDE that rests firmly within the Java programming universe.

Because we live in a world where enterprise software users continually ask for new functions and services, developers find themselves dealing with application requirements that are often fuzzy and tough to clarify. That makes applications harder to build and it makes deployment tougher because nobody knows if new designs will affect the wider computing environment and performance. To address these issues, AWS has positioned Kiro as a route to what it calls spec-driven development i.e. only actually building the code that will result in things users need.

Kiro Hooks & Specs

Agentic developer experience advocate at AWS, Nikhil Swaminathan says that Kiro’s strength is getting prototypes into production systems with features such as specs and hooks.

Kiro specs are software artifacts (anything basically, from code itself to documentation to designs to a data model) that software developers can use to work on application features or refactor existing code. In this context, “specs” are not just specifications, they are accelerators to help programmers understand the behavior of the software system they are building and get it into live production. The specs approach from AWS here can guide AI agents to a better implementation in the same way.

Kiro hooks act like an experienced developer who is capable of catching things other engineers might miss or completing boilerplate tasks in the background as the rest of the team works. These event-driven automations trigger an agent to execute a task in the background when you save, create, delete files, or on a manual trigger.

“Kiro accelerates the spec workflow by making it more integrated with development. In our example, we have an e-commerce application for selling crafts to which we want to add a review system for users to leave feedback on crafts. Let’s walk through the three-step process of building with specs,” said Swaminathan, in an AWS blog. “Kiro unpacks requirements from a single prompt. Type: ‘Add a review system for products’… and it generates user stories for viewing, creating, filtering and rating reviews.”

Ear Ear, It’s EARS

Each user story includes what are known as EARS (an acronym that stands for easy approach to requirements syntax) notation acceptance criteria. This covers cases developers typically handle when building from basic “user stories” (the information that developers use to help draft the formalized requirements that will detail what an enterprise application is supposed to do) and coding. This makes prompt assumptions explicit, so developers know Kiro is building what they want.

“Kiro generates tasks and sub-tasks, sequences them correctly based on [software] dependencies and links each to requirements. Each task includes details such as unit tests, integration tests, loading states, mobile responsiveness and accessibility requirements for implementation. This lets you [developers] work in steps rather than discovering missing pieces after they think they’re done,” explained Swaminathan. “Kiro’s specs stay synced with your evolving codebase. Developers can author code to update specs or update specs to refresh tasks. This solves the common problem where developers stop updating original artifacts during implementation, causing documentation mismatches that complicate future maintenance.”

Beyond specs and hooks, Kiro includes model context protocol support for connecting tools, steering rules to guide AI behavior across a project and agentic chat for ad-hoc coding tasks. Kiro is built on Code OSS, so developers can keep their Visual Studio code settings and compatible plugins.

Are Developers Out Of A Job?

All of which brings us back to the central (and perhaps uncomfortably recurrent) question… are developers about to be put out of a job? Swaminathan explains that a) that was never the reason for the development of Kiro and b) it’s really about solving the fundamental challenges that make building software products so difficult.

As he has said in explicit terms, “The way humans and machines coordinate to build software is still messy and fragmented, but we’re working to change that. This is a major step in that direction.”

Those challenges come down to the trouble developers have when attempting to ensure there is design alignment across teams and resolving conflicting requirements. The development of AWS Kiro also stems from the need to eliminate technical debt, to bring additional rigor to code review procedures, to preserve institutional knowledge when senior engineers leave and to help foster deeper team collaboration. Spoiler alert, those are all “human developer” exercises, so this story is about using agentic services to support those processes, not as an attempt to replace them.

Developers, we still need you, more in fact.