What is AI-Driven Software Delivery?
Vibe coding refers to a modern, AI-assisted development paradigm where software is built by interactively describing requirements to an AI, which generates working code that can be iteratively refined. Instead of writing everything manually, developers act as high-level architects and prompt engineers—steering the AI toward the desired functionality through successive conversational inputs.
However, Vibe Coding has many limitations around stability of the code, creation of brittle architectures, and lack of reliability, scalability, security and performance once you try and use it for anything more than a prototype or Minimal Viable Product (MVP).
To address these issues and limitations, a new methodology and approach is emerging that uses software requirements and specifications to formally drive the Agentic AI tools rather than just relying on simple conversational prompts. It is this new approach that Amazon Kiro was built to promote. We call this Return of the Requirements.
In this new methodology and approach, the software code is no longer an important artifact to be maintained and cared for, instead it is simply generated as needed from the system requirements, which now become the new “source of truth” for development.
This has big implications for the software development lifecycle and how it impacts quality assurance (QA):
We now need to emphasize quality over testing and when issues, risks and bugs are found, instead of a developer fixing the code to address the issue, they are fed back to the business requirements and used to fix those. Once the requirements have been updated, the development agents will simply regenerate the code until the requirements are met, the tests pass, the risks are addressed, and the acceptable level of quality has been achieved.
What is Kiro?
Amazon’s Kiro is a new agentic AI-powered Integrated Development Environment (IDE) launched by Amazon Web Services (AWS). It’s designed to take developers from a rough prompt—such as “Add user authentication”—to production-ready code. Kiro does more than autocomplete: it generates structured specifications, design documents, user stories, and task lists before writing any code, enabling a "spec‑driven" approach to software development.
What is Spira and Inflectra.ai?
Spira is Inflectra’s flagship suite of tools for managing the entire software development lifecycle (SDLC). It’s designed to help teams deliver high-quality products through integrated project, quality, and risk management. The suite includes:
- SpiraTest – A comprehensive test management solution that supports manual and automated testing, defect tracking, and traceability from requirements to test execution.
- SpiraTeam – Expands on SpiraTest by adding source code integration, task and bug tracking, requirements management, and Agile/Scrum planning features.
- SpiraPlan – The most robust of the suite, SpiraPlan includes all of the above plus program and portfolio-level planning, risk management, and governance capabilities for large-scale or regulated environments.
Together, these tools form a unified ALM (Application Lifecycle Management) platform, providing complete end-to-end traceability, real-time dashboards, and built-in support for both Agile and traditional methodologies—all accessible through an intuitive, web-based interface.
Inflectra.ai is a domain-specific generative AI engine natively embedded within the Spira suite (including SpiraTest, SpiraTeam, and SpiraPlan). Unlike traditional AI integrations, Inflectra.ai works directly within the user interface and adapts to your context—whether you're authoring a requirement, designing a test case, managing a task, or reviewing a risk.
Powered by LLMs through Amazon Bedrock, it can:
- Suggest and generate test cases, BDD scenarios, user stories, and tasks from a requirement.
- Create code snippets and unit tests based on development tasks.
- Recommend risk mitigations and test automation scripts.
- Automatically generate traceable artifacts across the SDLC.
Inflectra.ai is designed to boost productivity, enhance coverage, and reduce the manual burden of documentation and planning, making AI a seamless, proactive part of the software development process.
Using Spira and Kiro to Create an Enterprise-Grade Application
To illustrate this new way of working, we will show the complete end-to-end process of creating a brand-new business-line application starting only with some simple requirements. We will show you how to refine and improve the requirements using Inflectra.ai, generate product artifacts such as BDD scenarios, test cases, tasks, and risks.
Taking these product artifacts, we will ask Kiro to use them to build a detailed product specification, and from that create a fully runnable web application. The total time from requirement ideation to executable application is about 10-15 minutes for a simple business-line application.
Step 1: Using Inflectra.ai to Create the Product Specification
For this example, we are going to try and create a simple online customer satisfaction survey tool that is web-based and uses a database to store its answers. So we start out with the following high-level product description as our initial requirement in Spira:
This is our high-level business goal. Once we have entered it in Spira, we would typically review it with the product stakeholders and make sure it accurately reflects what is intended. Once that is done, we now need to refine and describe this objective in more detail.
Generating the Product Backlog
We could manually take this high-level requirement and decompose it into a more exact set of requirements. However using Inflectra.ai, we can simply ask it to create a set if more detailed child requirements automatically.
Using the Generate child requirements option multiple times, we are able to quickly build a structured product requirements backlog.
In this example, we have decomposed the original requirement into a three-level hierarchy. This is quite common in Agile projects where we have Epic > Feature > Story as the main levels:
Using Spira we can tag the requirements with a specific Release, so in this example we are only building the initial release of functionality for the survey tool. Therefore, we will tag those requirements with ‘Release 1.0.0.0’.
Reviewing the Requirements and Improving
Once we have created the initial set of requirements, we can use the power of Inflectra.ai to review and potentially improve the requirements, to make sure they contain the necessary level of detail to create a viable application.
We click on the appropriate requirement and then choose the option to Analyze writing quality using EARS. In case you are not familiar with EARS, it stands for the EAsy Requirements Syntax (EARS) and is an industry-standard way of writing “good” requirements. This standard is also the same one used by Kiro, so verifying the quality of the requirements against EARS will speed up the application creation process later.
Inflectra.ai will review the existing requirement and give it a score 1-5. If the score is anything but a perfect 5, Inflectra.ai will provide feedback on what was good and what can be improved. You can either manually implement the recommendations, or simply click on the button to Improve the requirement.
If you choose that option, Inflectra.ai will create an updated name and/or description of the requirement:
If you want to see what has changed, you can use the Requirement History tab to see how the requirement has been improved by AI. We tag any requirement that was generated or updated by AI as “ai-generated” or “ai-augmented”, that way the human business analysis team can review what was generated or suggested and ensure it is accurate and appropriate.
Creating Acceptance Criteria
Once the core requirements have been reviewed and are considered to be an accurate representation of the business needs, you can use the Generate BDD Scenarios for this requirement option:
This will create multiple scenarios for each requirement in the backlog. Typically the AI will generate at least one “happy path” scenario and 2-3 “exception path” scenarios:
Depending on the nature of the requirement, it may decide to create additional “happy” or “exception” scenarios. As with all content that is AI-generated, the team should review to make sure they are appropriate and relevant.
Once we have the requirements and corresponding scenarios / acceptance criteria defined, we next need to describe how the requirements can be tested.
Generating Test Cases and Test Steps
Using Inflectra.ai we can auto-generate a draft set of test cases (and corresponding test steps) for each of the requirements in our backlog.
To do this, we can go to the main requirements list page, choose all of the requirements we want to test and use the option Create test cases to cover this requirement. Once we do that, for each of our requirements, we will see 8-10 generated test cases:
Each of the generated test cases will also include a detailed set of test steps. The test steps describe in detail how the application should behave.
Before proceeding any further, the QA team should review these test cases and make sure they are valid and sufficient for testing the new functionality. If the QA team feels that there is some functionality that is not being adequately tested, they can write additional test cases and/or improve the ones written by the AI.
Generating Development Tasks
Now that we have the requirements and test cases written, we can use Inflectra.ai go one step further and build the full implementation plan. This will result in a set of Spira tasks being created for each requirement.
These tasks are used for describing the development and infrastructure activities that need to be followed to create the new application. Traditionally they would be used by human developers (via their IDE) to describe the steps they need to follow.
However, in this new world of Agentic AI-based software development, they are used by Kiro directly to create the application itself without any human involvement. Therefore, like all the other AI-generated artifacts in Spira, they should be reviewed by the development team before being used for application creation.
Identifying the Potential Risks
With any software application there are always risks - technical, business, security, etc. – so it is critical to identify these upfront and ensure the software design takes them into account when building the application.
Using the Identify risks related to this requirement tool available in Inflectra.ai, we can generate a set of standard risks for each requirement. In this example, we have generated 4-5 potential risks for each requirement. Each risk comes with a name and long description (which may contain mitigation suggestions):
Once the risks have been generated and reviewed by the product management team, we now have a complete set of product artifacts. The next step is to download these artifacts into Kiro so that they can be used to build the new application.
Step 2: Connecting Kiro to Spira
The first thing we need to do is install Kiro from the download site and configure it to use an appropriate AI platform. In our example we have connected Kiro to our corporate AWS account that has an Amazon Q Developer Pro subscription. There are other options available as well.
Next, we need to establish the connection between Kiro and Spira. This is done using the MCP Server for Spira. This is a local MCP server that consists of a set of Python packages that run locally. We can either Clone the Git repository or install the package from PyPi.
We next need to edit the MCP settings for Kiro by going to File > Preferences > Settings:
Then we can click on either the Open Workspace MCP Config (JSON) or the Open User MCP Config (JSON) depending on whether we want Spira to be available for the current workspace or the current user. This will bring up a JSON file that looks like the following:
We need to add the following entry for Spira to be available as an MCP server:
{
"mcpServers": {
"inflectra-spira": {
"command": "uv",
"args": [
"--directory",
"C:\\Git\\mcp-server-spira",
"run",
"main.py"
],
"env": {
"INFLECTRA_SPIRA_BASE_URL": "https://myinstance.spiraservice.net",
"INFLECTRA_SPIRA_USERNAME": "mylogin",
"INFLECTRA_SPIRA_API_KEY": "{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX}"
},
"disabled": false,
"autoApprove": [
"get_specification_requirements",
"get_specification_design",
"get_specification_tasks",
"get_specification_test_cases"
]
}
}
}
We need to change the following information to match our installation of Spira:
- INFLECTRA_SPIRA_BASE_URL – The base URL of our instance of Spira
- INFLECTRA_SPIRA_USERNAME – A valid username/login for this instance of Spira
- INFLECTRA_SPIRA_API_KEY – The API Key / RSS Token for this username
Once we have configured the Spira MCP server, we can now see it listed in the Kiro tab on the left hand menu:
It will list all of the operations provided by the MCP server. We can check that we have the correct version installed, by verifying that we have the following operations listed:
- get_specification_requirements
- get_specification_design
- get_specification_tasks
- get_specification_test_cases
We are now ready to download the online survey tool product specification into Kiro from Spira.
Step 3: Downloading the Specification from Spira
To generate the product specification, we simply enter in the following prompt:
We have specified the Spira product name as PR:xxx, and since we only want to generate the specification for a single release, we also specify the release name as RL:xxx. If we didn’t know the ID values, we could have used the project name and release name instead. If that case, Kiro will use additional Spira MCP server tools to find the ID values for us.
Since everything is configured correctly, we see the following:
Kiro has downloaded the standard three components of a specification – requirements, design and tasks. However Spira also provides a fourth additional component – the test cases:
Once all the markdown files have downloaded correctly from Spira, Kiro will let us know that has all the files.
Even though we have downloaded the information from Spira, Kiro will analyze all of the files provided and make changes so that it has enough information to actually build the application:
You can see the four markdown files in the Kiro IDE:
Most of the files downloaded from Spira will be pretty complete, however in the case of the design.md file, that generally needs more information that is available in Spira, including logical object models, database designs, and the overall system architecture.
Kiro will itself infer these from the other files we have provided (requirements, test cases, and tasks). Once it has finished analyzing and generating the specification, it displays the following to let us know it is completed:
We now typically should review the four markdown files and make sure they meet our design specifications. However, in this case, Kiro is confident we are ready to start development:
Step 4: Using Kiro to Build the Application
Building the application is surprisingly straightforward, all we need to do is tell it Can you create the application using the specification:
It asks us for a simple confirmation that we have reviewed the tasks and are content for it to proceed. We should check the list of tasks to make sure there are no potentially dangerous operations in there (e.g. format my hard drive to prepare the environment!!). Once we give it the go-ahead, it will start building the application:
It first creates the overall development environment and project structure. We had previously defined this application as using NodeJS inside Kiro, so that’s the platform it will use to build the application:
In this simple example, Kiro took about 5 minutes to prepare the development environment, create the application and database backend, and author a helpful ReadMe.md file that explains how to install and start the application
It also gives us this handy read-out of the application design and architecture. We could push this back to Spira using another MCP tool if we want the documentation recorded, or saved to a markdown file in the Git repository.
In addition to the read-out of the development process, it confirms that it has met the key requirements that were defined in Spira, and provides the installation and startup tests for us to launch the application.
Now, using the Kiro terminal, we can use npm install to build and install the application:
We are now ready to actually launch and use our new online survey tool…
Step 5: Running the Application
To run the application, we simply use the npm start command provided by Kiro:
When we open up the suggested URL for our local NodeJS server, we see the following login page:
Using the default login and password provided by Kiro, we see the Survey dashboard:
We can click on the Start Survey button to launch our new survey:
When we take the survey, we have to provide our name, satisfaction rating and a comment:
Once we complete the survey and click Submit we see the following confirmation screen.
We now have a working application that matches the requirements defined in Spira. If we want to add additional functionality or simply implement the additional functionality defined in Spira for the later releases, we can simply ask Kiro to update the specification with the additional data in Spira and then rebuild the application.
The code is no longer maintained manually by us, instead the source of truth for the application are the requirements and other artifacts in Spira. We can even upload the design documents into Spira so that the additional items generated by Kiro get persistent across updates.
Summary
Using the combined power of Spira, Inflectra.ai and Kiro, we have taken a simple set of requirements, validated them with the business owner, generated additional downstream artifacts such as test cases, tasks and risks, and created a fully working application all in the space of about 10-15 minutes.
However, even more importantly, unlike simple Vibe Coding, we have a full specification for the created application, which allows us to improve and maintain the codebase rather than it simply being throwaway. This illustrates that the future of software development will be teams and business users defining requirements, and AI agents doing the coding, unit testing, infrastructure preparation and other lower-level tasks. It also means we will need more humans acting as digital supervisors to review and validate the requirements, acceptance criteria, architecture diagrams and risk assessments.
References
The following articles provide more information on the concepts and topics in this whitepaper:
- The specification files that Inflectra.ai and Kiro jointly created:
