Spec-driven Development in practice: Building a serverless URL shortener with Amazon Kiro

AI coding assistants have come a long way since I first encountered them, but Amazon Kiro takes a different approach than simple prompt and response with spec-driven development. This lets you describe what you want to build, and then Kiro will produce a structured requirements document that you can review and refine before a single line of code is written. 

In this post I’ll walk through that workflow from end-to-end, using Kiro to build a simple serverless URL shortener on AWS. Using technologies like Lambda, API Gateway, and DynamoDB, I’ll show how with a simple prompt, Kiro works through the requirements and creates an implementation plan that I can refine to deliver a deployable application. Along the way I’ll point out where you still need to be careful with this approach to building code. 

How to use Amazon Kiro to build a serverless URL shortener

• Open Kiro and start a new spec-driven development session

• Provide a prompt, explaining what you want Kiro to help build: Build a serverless URL shortener using AWS SAM with Python. It should have a single Lambda function with two endpoints: POST /shorten which accepts a JSON body with a URL field, generates a 6-character alphanumeric short code, stores it in DynamoDB, and then returns the shortened URL. The second endpoint is GET /{short_code} This looks up the code in DynamoDB and returns a 301 redirect. Use a DynamoDB table with on-demand billing and short_code as the partition key. The Lambda runtime should be Python 3.14.
• Kiro asks if this will be a new feature or bug fix. Select feature, and submit the answer.

• Then select start by gathering and documenting requirements. Kiro will create a specs folder in the current workspace to store the specs as they are generated. You will be asked to approve the creation of the folder.

• Kiro creates .config.kiro and requirements.md files in the working directory. Open the requirements document and review it.

• The requirements.md file contains the requirements of the new feature, including user stories and acceptance criteria. Here’s an example:

• At this point you can tell Kiro to add or change the requirements as needed, if anything needs adjusting. When you are happy with the requirements, you can continue to generate the tech design.

• The resulting design document contains an overall architecture diagram, descriptions of the various components and interfaces that will make up the feature, and a data model describing the DynamoDB table structure.

• If anything needs adjusting, tell Kiro to modify the design as needed. 

• When you are happy, you can continue to generate the task list. This will create an implementation plan containing all the tasks that Kiro needs to complete to write all the code needed for the URL shortener. This includes creating a SAM template, generating the Python code for the Lambda functions, adding error handling, test scripts, and creating a README file with implementation instructions for deploying everything.

• After the implementation plan is ready, you can either run the tasks individually by clicking Start Task or click Run All Tasks to run everything. Personally I have found it more manageable to run each task in sequence, to see each one complete and deal with any issues as they arise. Kiro will need to create folders and files and may ask for permission as it goes.

• After the README file with step-by-step deployment instructions has been created, I recommend you actually check that the generated application will successfully deploy by going through the deployment steps.

• For this use case, deployment means using the SAM CLI to deploy the various components needed for the URL shortener. A simple way to do this is to run the commands using the AWS CloudShell in a sandbox account after first uploading the template.yaml and src folder to the CloudShell.

• After running the steps in the README file, I noticed that one of the instructions needs updating. When running SAM deploy, it will ask if it is okay for the UrlShortenerFunction to have no authentication. The default answer is No, and that needs to be changed to Yes for the deployment to complete. For my deployment, it asked me that question twice, once for each method that the Lambda function supports.

• After the stack is deployed, it will output the URL to use to access the function. In my case, it gave me an API Gateway endpoint URL like this: https://i0y0ud2gh0.execute-api.us-east-1.amazonaws.com/Prod/

To confirm basic functionality, I ran the following command from the CloudShell, providing a long URL that I wanted to shorten: 

It gave me a shortened version of the original URL that I was able to verify by pasting it into a new browser window and confirming that it re-directed me to the correct destination. 

After checking the basic functionality manually, I then felt confident in continuing to get Kiro to run the remaining tasks in the implementation plan. This includes writing unit tests and checking that they all pass. While I think that this can be a useful exercise to try and catch obvious issues and bugs in the code, I don’t think it’s wise to rely on Kiro to mark its own homework like this. Sometimes AI can be incentivised to do whatever it takes to get tests to pass, for instance identifying and running very specific tests that will always pass. 

Instead I would recommend using an independent tool to help generate and run automated tests designed to properly test the code and incentivised to uncover hidden bugs by testing thoroughly. Note that if a task in the Task list is marked as Queued, you can tell Kiro to run it in the chat window. Sometimes tasks which are optional are shown as Queued instead of available to run, even if tasks they are dependent on are already completed.

• Kiro created some basic tests, updated the README instructions, and after running the tests myself, unsurprisingly they all passed!

• After I have finished exploring, as this architecture was built using the SAM CLI, I can delete my Lambda function and everything else that was deployed by running the following command in the CloudShell: sam delete --stack-name url-shortener

Conclusion

What I love about the idea of spec-driven development is that instead of moving straight to writing code, you can work with Kiro to ensure it understands exactly what the requirements are and why they matter. I also appreciate the opportunity to verify the design and implementation plan and make adjustments along the way, all before a single line of code has been written. 

When deploying to AWS, a few small manual fixes may be needed here and there, requiring implementation plan updates, but overall this exercise showed me that I can definitely save some time when building small features that require the integration of multiple AWS services. 

I’d also recommend caution around trusting Kiro to write and run its own tests on code it has produced. But overall, my view is that spec-driven development with Kiro is a great tool to add to your toolkit, for turning a single natural-language prompt into a working, deployed application on AWS in only a few minutes, including a full explanation of how everything hangs together and why it was built that way. 

What would you use spec-driven development to build? 

Interested in learning more about implementing AI in development? Check out Pluralsight's learning path, "Integrating Agentic AI for Developers." Alternatively, read Axel Sirota's article on Spec-driven development (SDD) with AI.