I am not a developer. I have never been a developer. I understand enough about how software is built to have useful conversations about it, but writing production code is not part of my job and has never been the gap I wanted to close. What I did want to close was the gap between a design concept and a working, interactive prototype -- something that felt real enough to learn from, not just to show. Amazon Q Developer has made that possible in a way that nothing before it quite managed.
What Amazon Q Developer Actually Is
Amazon Q Developer is an AI coding assistant built into development environments -- most usefully, VS Code. It works by understanding what you are trying to build and generating, explaining, and debugging code in response to plain-language instructions. For a developer, it is a productivity accelerator. For a designer who wants to build prototypes, it is a collaborator who handles the implementation while you focus on what you are trying to test.
The key shift is that you do not need to understand how to write the code. You need to understand what you want the prototype to do, be able to describe it clearly, and know what good output looks like. These are design skills. If you can write a clear user story and describe an interaction pattern, you can prompt Amazon Q to build something useful.
What You Can Realistically Build
In practical terms, a designer with no prior coding experience can use Amazon Q to build interactive HTML prototypes with real state management -- forms that validate, flows that branch based on user input, components that respond to interaction in ways a Figma prototype cannot. This covers the testing territory that static click-through prototypes consistently fail at: what happens when a user enters the wrong thing, how an error state behaves, whether a multi-step flow makes sense when the user goes backwards.
Simple data-driven displays are also achievable. If you want to prototype a dashboard where the numbers change based on filter selections, or a list view that sorts and filters in real time, Amazon Q can build that. It is not production code -- it is not meant to be -- but it is interactive enough to surface real usability issues that static prototypes would have missed.
Animation and microinteraction prototyping has also become more accessible. Describing the transition you want in plain language -- what triggers it, what it should feel like, what it communicates to the user -- and getting working CSS or JavaScript in response is genuinely useful for testing whether a motion design decision reads correctly.
What You Still Need a Developer For
Anything that requires API integration, authentication, real data, or performance optimisation is beyond what a designer using Amazon Q should be attempting alone. Prototypes built this way are for testing design decisions, not for shipping. If a prototype starts to feel like a product, it is time to bring in an engineer -- not because the design work has failed, but because it has succeeded and it is time for the next stage.
Complex state management across a multi-page application is also territory where the scaffolding Amazon Q provides will become increasingly fragile if you extend it without understanding the underlying code. Knowing when to stop and hand over is as important as knowing how to start.
How This Changes the Relationship with Engineering
When I show an engineer a coded prototype -- even a rough one -- the conversation is different from when I show a Figma file. There is something about working code that signals 'I understand what I am asking for' in a way that even the most polished static design does not. Engineers see that design decisions have been tested against real interaction behaviour, not just imagined.
It also changes the questions I ask. When I have built a prototype in code, I understand more about why certain implementation choices are expensive. I have made the decisions myself -- imperfectly, in a prototype context -- and that gives me a baseline for understanding why an engineer is pushing back on a particular approach. The gap between design intent and technical reality narrows when the designer has spent time in the technical space, even at a prototype level.
The goal is not for designers to become developers. It is to narrow the gap enough that collaboration becomes genuinely bidirectional rather than a one-way handoff. Amazon Q makes that narrowing achievable without years of learning to code. The barrier is no longer skill. It is willingness to try.
