Amazon Q Developer Tips: No.17 Choose the right tool

In this series I will be sharing daily hints and tips to help you get ahead and start to accelerate you on your own journey. Each day I will share something new tip, categorised against a few themes and topics. If you have your own tips, or your own experiences with tips I share, please use the comment feature or feel free to contact me directly. Check out the previous tips here.

Ok, time for today’s tip….

Tip 17 - Amazon Q : Choose the right tool

Amazon Q Developer provides developers with a number of tools and commands to help generate code suggestions and other guidance. In previous tips I have shared how some of these work, and provided hopefully helpful tips that will make you more effective working with these. But how do you know which tool or command to use? Today’s tip is about providing you with a mental model on how to approach that.

The mental model that I use to help me assess which is the right tool or command to use is focused on five key things:

• What context do I need
• Developer experience
• Amount of effort needed
• Service limits and quota
• Boost vs Learn

What context do I need

Different Amazon Q Developer tools use and provide different context. For example, in-line will only use the current file you are editing (or block of code highlighted). This might be enough for the task I am carrying out. If I need more context (maybe I need to reference or understand supporting files in the project) other tools might give me better code suggestions and output, and I am more likely to use something like @workspace or Amazon Q Developer Agent for feature development (/dev).

Developer experience

The latency and responsiveness of the tools is different, and so has a direct impact on the developer experience. If I am in the flow and creating or editing files, the additional keystrokes and mouse movements are going to slow me down. Being able to invoke a prompt via the in-line prompt is going to be faster than using the chat interface.

Amount of effort needed

If I need to make changes to a single file (perhaps the one I am in right now) versus having to make changes across multiple (maybe even all) files in the project will be a consideration. If I have a large projects with hundreds of files, then the effort saved using Amazon Q Developer Agents (/dev, /doc, /test, or /review) is something worth considering.

Service quota

The different tools within Amazon Q Developer have different service quotas, whether I am using the Free Tier or the Professional tier. I factor this in when I am using the different tools as I want to make sure that I do not unnecessarily use up those service quotas for stuff that might be achieved just as easily using another tool with a higher service quota.

Boost vs Learn

If I know what I want to do, but just need to be more productive and more efficient (boost) then I might use the in-line tools. If I am exploring or learning, then the chat interface might be my preference (learn). I have found that my use of tools frequently falls along these lines.

If you want to know more about Boost and Learn as a mental mode, then I recommend reading A framework to adopt generative AI assistants for builders

This might not be the best way to think about this, and there are probably lots of other approaches - but this is what works for me. Let me know what you think, or if you have your own mental model that you are using.

Complexity vs Context

I was going through re:Invent 2024 sessions over the last week, and another great way to look at which is the right Amazon Q Developer tool to use is thinking about this as complexity of the task you are doing against the amount of context you have or need. AWS Hero Matt Lewis put this very nice graph together.