All the new things Q developer can do
using workspace context-awareness, /dev and inline chat to build an APP from prompts
gengis
Amazon Employee
Published Nov 22, 2024
AI coding assistants first introduced a few years ago inline completion, also known as TAB completion. That allowed developers to harness the power of GenAI to complete entire lines and functions within their code files.
Shortly after, Chat was introduced, enabling developers to engage in conversations with their codebase. This feature empowered developers to generate code, seek guidance, and perform refactoring through interactive dialogue. Chat represented a substantial upgrade from TAB completion, but it still had its constraints, as the context was limited to the open tabs within the developer's IDE and did not encompass the entire codebase and copy/pasting code between the chat UI and code file was not always the most efficient way to build code.
Recognising these limitations, Amazon Q Developer has recently introduced three major features: workspace context-awareness, Q developer agent and inline chat.
Other popular coding assistants have similar features : Cursor calls it composer, Windsurf calls it cascade. We are still early in the journey and a quick look on X feeds or Youtube showcases a lot of really inventive ways to leverage those features.
In this article, we'll build a task management system using @workspace, /dev and inline chat features to showcase how those new features bring new efficient patterns for GenAi-assisted code generation.
Design documents or 2-pagers can serve as starting points for application development. While you can create these documents independently, collaborating with an AI assistant can help you iterate and refine your ideas. Here for the sake of the exercise we will just try to feed Q a short prompt and a few key ideas and ask him to generate the full high level design document.
Our first task is to open an empty VSCode project and create an app.md file. We will use Q chat with the /dev feature to craft the design document of my application by giving him high level requirements of what I want:
- a simple task management system
- a web application
- running on AWS
- with a small tech stack
the prompt could be something like:
/dev help me create a req.md file that will contains requirements for A lightweight task management system built on AWS serverless architecture, focusing on core features with room to grow. Add UML and mermaid charts to help describe the app and infra. Here are my high level requirements that you should build upon: - design a simple task management system, should be a web application running on AWS with a small tech stack that should be easy to use and a serverless database.After a few minutes Q /dev generates for me an app.md file. And it's already quite impressive. I have full design documentation, with APIs, data model, architecture and ideas being generated. You can visualize the full app.md file here
I can use Q inline (CMD + i) to refine some of the design choices (like for instance if it is using RDS in the design doc I could say "Help me change the design and use DynamoDB instead) and Q inline will automatically change all my design file, schemas and considerations to adapt the data model to DynamoDB!
Once I am happy with the design doc I can start to "code".
We will use DDD (Documentation Driven Development :D) to code our application. DDD here is just using design documents as the primary input for AI-assisted code generation - in this case, Amazon Q Developer will help build our infra and front-end stack
At this stage you can ask Q to generate the full app and infrastructure code but it's often a best practice to reduce the complexity of your problem. Hence why I will start by asking Q to generate first the infrastructure:
/dev using app.md help me generate the infrastructure code (in cdk) then help me add the code fileHere I'm using key prompt patterns:
- '/dev' triggers code generation and uses context from IDE
- 'app.md' is the source file for requirements
When using AI for code generation, break down complex problems into subtasks, and design each prompt for a specific purpose - regardless of the prompt's complexity.
After submitting our request, Q first outlines an implementation plan before starting the code generation. While Q works on the code (which takes a few minutes), we can review the proposed plan:
We can see that in the reviewed section Q used app.md to create 10 infrastructure files. Once the code is generated it is possible to accept / reject it. It is also possible to give a human feedback using thumbs up/down.
We accept the changes and can then browse through the generated files. This looks good but let's say I have no idea how to build / run CDK code. There should be a README.md file to help me with that. Let's ask Q to generate it:
/dev generate a readme.md file that will help me build this app and the cdk code. add my name as author "Gengis BIRSEN" and put an MIT licenseThe generated README.md contains all essential project information, from prerequisites to deployment steps! You can visualize the full README.md here
Always review your generated CDK code for security and permissions before deployment. Consider using tools like cdk-nag to automate security controls and best practices.
Using the instructions in the README.md I run in my terminal CDK deploy with no changes at all. And this fails with below error message:
--app is required either in command-line, in cdk.json or in ~/.cdk.jsonIt seems like Q omitted to add a cdk.json file. It's pretty straightforward and if you know CDK you can do it by yourself. But let's assume again that I am either lazy or new to CDK and let's ask Q to fix this:
/dev there is no cdk.json file in the infrastructure. so when i run cdk deploy it says --app is required either in command-line, in cdk.json or in ~/.cdk.jsonA few seconds after Q generate the missing cdk.json file and I run again a CDK deploy and that's it:
I now have my infrastructure running in my AWS account!
At this stage. We deployed the infrastructure which consists of a bunch of lambdas, a dynamoDB table and an Api Gateway but there's no UI to test it!
Remember, we did not build the front-end code yet. We could still test our backend code and try to send some events to our lambdas. But let's build the front-end first.
Again, that will be as simple as asking /dev to build it for us.
/dev using the app.md you helped me deploy the cdk infrastructure but now I need a front end to test it. could you help me build one as per the requirements in app.mdHere, /dev context understanding is essential - it allows Q to leverage both backend code and design docs as context when generating the React frontend files. This contextual awareness is where the magic happens!
Q not only generated the full React frontend but also remembered our previous interactions - automatically creating a detailed README.md tailored for the frontend without being prompted!
At this stage I am curious and just wonder if blindly following the steps documented in the readme will make everything work from the first try! When looking at the file it just shows me the steps to deploy locally and there aren't any instructions on how to deploy to AWS. My prompting was most likely the issue here as I did not directly ask for that. We will get back to this later but now let's try to build it locally using npm start:
Could not find a required file. Name: index.html This fails due to a missing index.html file! Once again that is a minor hiccup and if you know react you can add it yourself. I chose again the lazy way and ask Q to do it.
The app now deploys locally. It's pretty basic a button create new task and a popup menu to create one.
We now need to deploy the front-end to AWS. And that is the part where my initial prompt was not enough for Q to decide on what to do. Let's tell Q what we want in a more precise prompt:
/dev I want to deploy my frontend on cloudfrontQ then starts planning and generating the code:
The plan looks great and when looking at the context Q is using we can see that it is basically using existing infrastructure and front-end code to update my existing CDK file so that we can add the cloudfront distribution and the s3 bucket where my site will live!
It also created a DEPLOYMENT.md that details the deployment steps and strategy! At this stage I try a CDK deploy and that works from the first try!
There are some minor CORS issues (as there is always :D) on lambda side that I ask Q to fix using @workspace.
@workspace help me troubleshoot CORS issues in my lambda functionsLooking at my context @workspace is capable to verify that my CDK code handles CORS while fixing my lambda code. I can then insert the changes for my lambda functions to include the right headers or even go through /dev to ask him to do it by itself:
Once fixed everything works as expected and I can create, update, delete and list tasks from my front-end and it is persisted into dynamoDB!
Q Inline generation is awesome to refactor or document existing code. Here I will use it to add some details on what my cdk code does.
Pressing cmd + i opens up the inline chat and I can just prompt to add documentation to my cdk code.
Q inline then dynamically generate the new code and I can decide to Accept or Reject it. In a few seconds I documented my cdk code. I could also extend this doc writing to my lambda or react code but you get the idea
Through Q dev's code generation, we made detailed technical decisions that exceeded our original specs. We can now use Q dev to transform our code into documentation, flow charts, and architecture diagrams - ensuring all project documentation reflects the actual implementation. Let's prompt Q:
/dev``devflow-stack.ts generate for me a draw.io xml schema of my AWS Infrastructure. also use my backend lambda code to help you. directly generate the .drawio file and use latest AWS IconsUsing '/dev ', We are directing Q to analyze our devflow-stack.ts infrastructure file and backend Lambda code to generate a draw.io diagram of our AWS infrastructure. By specifically referencing devflow-stack.ts, we ensure Q focuses on our core infrastructure definition. You can download the drawio file here.
And here is the result:
The combination of /dev, @workspace, and inline chat features represents a significant advancement in developer workflows. I attempted an ambitious end-to-end use case: starting from scratch, creating a design doc with Q, then generating both infrastructure and frontend code, followed by automatically creating post-implementation documentation and updated design artifacts.
While generating an entire application from scratch presents clear challenges with scalability, code quality control, and team consistency, this exercise highlights various ways Q dev can enhance development. You can extract specific prompting techniques and patterns to enhance parts of your development workflow where AI assistance makes the most sense. Every developer will find their own way to integrate these tools, and I hope the approaches shown here spark ideas for your projects.
For more inspiration, check out Promptz - a community-driven library of prompting techniques that you can use in your projects. Also if you are curious I left a few .md files at the root of the project as well as the frontend/backend code here.
Any opinions in this post are those of the individual author and may not reflect the opinions of AWS.