Background

I have been using the Amazon Q Developer Agent for software development for some time, looking at ways to get the agent to consistently generate more accurate output. This has highlighted the importance of the prompt, as the primary way of instructing the agent about the type and style of content to be generated. I have found the more precise guidance the prompt contains, the better the output. However, crafting these prompts can be time consuming. This leads to another challenge of ensuring that prompts are used in a consistent fashion across all engineers in a team.

In this post we look at a simple way of introducing “prompt templates” as a better way of ensuring the accuracy of content generated. The goal is to generate a complete project using a number of AWS services written in Python, with the infrastructure managed and provisioned by Terraform. This is being carried out with limited knowledge of these languages.

Bootstrapping our project

We start off by bootstrapping the project with just 2 files:

• requirements.md - a markdown file containing our requirements in terms of programming languages and other guidance. This acts as our prompt template
• architecture.puml - a Plant UML diagram with the design of the application we want to build

From here, we can now pass in a simple prompt to the Amazon Q Developer Agent:

“Create a complete project implementation including source code, unit tests and a requirements.txt file that meets all of the project requirements as set out in the requirements.md file. Use Terraform following standard best practice to define and deploy all services as detailed in the Plant UML diagram format below:”

I have not found an accurate way of getting Amazon Q Developer to recognise the .puml file, so for the moment, I copy and paste the Plant UML diagram content into the prompt:

The Amazon Q Developer Agent for software development plans out all the steps it needs to take to meet the ask. In the very first step, the agent states:

I need to open requirements.md to review the project requirements. Based on Plant UML diagram, I can see it's an AWS serverless architecture with an API Gateway, Lambda functions and DynamoDB. I'll first create the necessary project structure

The complete summary of changes are shown in the screenshot below. It is interesting to see the agent is clever enough to recognise that some of the imports are not working correctly, and it continually iterates after each change, until it is confident that the requirements have been met.

I accept the proposed code changes, and now I have a full project structure that has been created for me, with a README.md file that gives me more details about the project.

Running the application

Next we want to get the application up and running. I recorded a video to show this working. There were no code changes needed. I just needed to execute a python script to package up the source code for each Lambda function into a Zip file. I also used the inline chat functionality of Amazon Q Developer to output the API endpoint URL so I could run some cURL commands.

Design versus Build Comparison

The only details of what AWS services that made up the application were shown in the Plant UML diagram. What I found most impressive was how accurately the software development agent created the infrastructure to match the design.

• The design shows 4 individual AWS Lambda functions called CreateItem, ReadItem, UpdateItem and DeleteItem. These are the exact names of the Lambda functions created.

• The design shows the HTTP verbs (POST, GET, DELETE) and the URL Path Notation. These have been created in API Gateway exactly as they are shown in the diagram.

• The design shows a DynamoDB table called Item with a partition key of id. This has also been created exactly as shown in the diagram

In addition, we can see that the code generated conforms to the specification set out in the requirements file, being written in Python with headers and comments and meaningful variable names.

Conclusion

I am really excited to see the potential that exists today with the approach taken here. I love seeing how visual design artefacts can be taken and converted directly into the underlying infrastructure on AWS. This helps to provide a seamless transition between design and build. It also solves another challenge of adopting a prompt template that can be used consistently by engineers within a team and across teams in an organisation. This approach allows for the consistent generation of code artefacts that meet organisation guidelines, by ensuring that project repositories are bootstrapped when created with a standard requirements file.