AWS Lambda is a popular choice for building scalable serverless applications. Managing both infrastructure and application code can at times become onerous. AmazonQ, via the advent of a VSCode plugin, can ease the burden of development by integrating a generative AI engine, that is capable of critiquing your code, making recommendations for improvement, as well as provide explanations of existing code and ultimately generate code for you.
In this post, we’ll explore how to leverage the free tier of AmazonQ within Visual Studio Code (VSCode), and provide our own review of it’s enhancement of the development process, with specific application to AWS Lambda functions. Given that Lambda is native to AWS, we were hoping that AWS might offer some insightful improvements in this space.
AmazonQ an exciting product with so much promise, but does it perform as expected? The short answer to this is yes & no, which will become more apparent as you read on.
For those that have little or no coding experience, Visual Studio Code is an Integrated Development Environment (IDE) widely used and widely praised for its versatility and robust ecosystem. The AmazonQ plugin for VSCode is AWS’s response to the somewhat recently launched AI VSCode enhancement in GitHub Copilot that is backed by Codex, a descendent of the ever popular Chat GPT-3 engine.
The aim of a good IDE is typically to improve development productivity. Generative AI is the next logical step to improve upon the existing functionality that includes features like version control, syntax highlighting and transformation, code completion, and language support to name a few.
If you have not already, you need to install the AmazonQ plugin. The installation process is quite simple and straight forward.
Within VSCode enter the key combination Ctrl+Shift+x or go to view 'Menu' => 'Extensions', and search for AmazonQ. The plugin will then download and install and subsequently present two options for progressing:
1. Builder ID (The free tier option that we tested – no AWS account required)
2. AWS IAM Identity provider for the $19 per month Pro Tier
After clicking 'Use For Free', a link will prompt to open in your default browser, where you will be required to enter a valid email address as well as your name etc. A confirmation email is then sent, which includes a code to be entered into the browser window. Enter a password and the Builder ID creation is now complete, with the authentication being prompted for permission to be passed back to VSCode.
First up, we presented AmazonQ with a half written lambda function written in Python, and asked it to critique the code. We received a detailed and meaningful answer condensed into the following sentence:
“Overall, the code appears to be well-structured and follows good practices in many areas. With some improvements in areas like configuration management, error handling, and documentation, the code could be made even more maintainable and easier to work with in the long run.”
An error produced when running the code was passed back to AmazonQ which responded with a suggested code change to remediate the error. Unfortunately the suggested change was not included in the code that was generated, which prompted us to ask where in the code it should be included. The response was apologetic, and said "Here is the corrected version…" but it wasn’t. The correction was notably omitted from the “corrected” stanza. An apparent hallucination this early on wasn’t expected. Although the code that had been documented in the conversation, but not in the suggested stanza, was relatively simple to infer and insert manually.
Overall, the coding abilities of AmazonQ were quite useful and could foreseeably improve developer productivity, particularly with cross over developers like myself that have originated from an infrastructural background.
Next we asked it to improve the logging of the function. The response appeared outwardly reasonable, but when applied, caused the function to lose all of it’s existing logging.
We tried to massage an answer out of AmazonQ, describing the lack of logging that resulted from it’s suggested code changes, but it eventually admitted defeat. It wasn’t until we provided an AWS referenced answer, that it corrected the log handling code and notably also corrected it’s earlier hallucination.
We also gave AmazonQ an example epoch timestamp that the function needed to handle. AmazonQ failed to recognise the timestamp as epoch and continued mishandling it using the parser from the Python dateutil library. We had to explain that the timestamp was epoch, before an almost correct code change was suggested; almost correct in that it failed to recognise that the format needed to be divided by 1000 ms in order to be handled without error.
Given that this is AmazonQ’s first iteration, we can afford to extend a little compassion. It wouldn’t be the first dev to be tripped up by datetime transformations.
As AmazonQ will tell you itself if you ask it: "How can I configure AmazonQ to maintain a persistent history of our conversations?"
…“Unfortunately, AmazonQ does not have a built-in feature to maintain a persistent history of conversations across sessions. As an AI assistant, I do not actually have access to configure AmazonQ or maintain any kind of persistent state”
In conclusion, while AmazonQ shows immense potential in enhancing development workflows, it still has room for improvement, particularly in handling complex code and maintaining context. However, its intuitive features and seamless integration with AWS Lambda make it a tool worth trying, especially for developers exploring serverless architectures.
Give it a go and let us know what you think. If you have any questions, concerns, or simply want to delve deeper into how AmazonQ can enhance your development processes, don't hesitate to reach out.