How I Build Faster With AI, Screenshots, and Voice

A lot of people blame the AI model when a coding task goes sideways.

Sometimes the model is the problem. More often, it is guessing because the prompt did not include enough context.

That happens constantly with UI work. A request like “move the button down” or “fix the spacing in this card” makes perfect sense when you are looking at the screen. The AI cannot see what is in your head. It may not even know which button or gap you mean.

My workflow now is simple:

1. Take a screenshot with PxlShot.
2. Draw an arrow to the exact part of the interface I want to change.
3. Use Handy to speak the rest of the prompt.
4. Give the screenshot and the dictated instructions to the AI model.

Both tools are free. The whole process takes a few seconds, and it saves me a surprising amount of time.

If you are still typing every prompt and trying to explain visual problems without a screenshot, you are making AI development harder than it needs to be.

A Screenshot Gives AI the Missing Context

Code tells the model how the interface was built. A screenshot shows what the interface actually looks like.

That difference matters.

The code might say a container has 24px of padding. The screenshot can show that it still feels cramped next to the text, the icon is slightly off-center, and the button is wrapping at the current window size.

Screenshots are especially useful for:

• Spacing and alignment problems
• Responsive layouts
• Incorrect colors, borders, or shadows
• Text wrapping in the wrong place
• Elements that are too large or too small
• Awkward empty space
• Comparing an implementation with a reference design
• Showing a bug that is easier to see than describe

Instead of writing three paragraphs to recreate what I see, I can give the model the actual pixels.

The Arrow Is the Important Part

A screenshot alone is better than text, but it can still be vague.

A normal page may contain dozens of buttons, labels, cards, icons, and gaps. If I upload the entire screen and say, “Fix this spacing,” the model still has to guess where to look.

An arrow removes that guess.

I built PxlShot for this kind of everyday screenshot work. I capture only the part of the screen that matters, open the editor, and point an arrow at the exact element or gap I am talking about. If there are several related changes, I use numbered markers and describe them in the same order.

This sounds like a small detail, but it changes the prompt from “something on this screen is wrong” to “look right here.”

That is a much easier problem for the model to solve.

Handy Removes the Typing Bottleneck

The screenshot explains where. I still need to explain what I want.

For that, I use Handy, a free and open-source speech-to-text app. I press a shortcut, talk through the change, and Handy pastes the transcription into the AI prompt.

The transcription runs locally on my Mac. My voice is not sent to a cloud service, and there is no subscription. Handy also works on Windows and Linux.

I do not try to dictate a perfectly polished prompt. I talk through the problem the same way I would explain it to another developer:

The spacing below this toggle is too tight. Move the text block down, but do not change the width of the card or the padding above the heading. I marked the exact gap with the red arrow. Keep the mobile layout the same unless the same problem exists there.

Speaking that takes a few seconds. Typing it, cleaning it up, and making sure I did not leave out an important constraint takes longer.

Voice is also better for the messy context that often gets dropped from a short typed prompt. I can mention what I already tried, what should stay unchanged, how the screen should behave, and what would count as done.

My Full AI Development Loop

This is the loop I use for most visual changes:

1. Open the current version of the app or website.
2. Capture the problem area in PxlShot with enough surrounding UI to provide context.
3. Add one clear arrow or a few numbered markers.
4. Paste the screenshot into Codex, ChatGPT, or the coding model I am using.
5. Use Handy to dictate the change, constraints, and expected result.
6. Let the model inspect the code and make the change.
7. Review the real interface, not just the diff.
8. If something is still off, take another marked-up screenshot and repeat.

The last step matters. UI development is a feedback loop. I do not expect one giant prompt to produce a perfect result. It is usually faster to make one focused change, look at it, and give the model another precise correction.

This works for bugs too. If an error only appears after opening a menu, resizing a window, or reaching a certain state, I capture that state. The model can see the evidence instead of trying to reconstruct it from my description.

Give the Model Constraints, Not Just a Target

A screenshot and an arrow identify the problem. A good spoken prompt also says what should not change.

I try to include:

• What I expected to happen
• What is happening now
• Which marked element needs to change
• What nearby elements should stay the same
• Whether the change should apply on mobile
• How I will know the fix is done

That keeps a small visual adjustment from turning into an unnecessary redesign.

It also gives the AI something concrete to verify. “Make this cleaner” is an opinion. “Align these two fields, keep the card width, and do not change the mobile breakpoint” is a task.

Keep Private Details Out of the Screenshot

Screenshots can contain customer data, API keys, email addresses, local file paths, and plenty of other things an AI model does not need.

Before I share one, I crop out anything unrelated and use PxlShot to blur, pixelate, or permanently redact private details. PxlShot also re-encodes exported images without the source photo’s GPS, EXIF, or other descriptive metadata.

The model needs useful context, not every visible detail.

Show It, Point to It, Say What You Want

AI models are good at reading code. They are much better at visual work when they can also see the result and know exactly where to look.

PxlShot handles the screenshot and the arrow. Handy handles the voice-to-text. Right now, both cost nothing to use.

This is not a complicated productivity system. It is just a faster way to communicate.

Show the model the screen. Point to the problem. Say what you want changed.

If you are not doing that for UX and UI work, you are wasting a lot of time.