Skip to main content
Back to Blog
personalAI accessibilityeye tracking softwarevoice dictation development

I build software with eye-tracking and voice dictation. Here's what that taught me about AI.

How building software without a keyboard revealed the real method behind AI-assisted development.

Admin User
March 26, 2026
3 min read
Share

I navigate my screen with my eyes. I dictate commands with my voice. I build production software this way every day using Claude Code.

This is not an inspirational story. This is a technical observation about what happens when you remove the keyboard from software development and what it reveals about how AI-assisted building actually works.

The physical reality

I use eye-tracking hardware to move my cursor. I use voice dictation to speak instructions to Claude Code. I do not type. I do not use keyboard shortcuts. I do not copy and paste by selecting text with a mouse and hitting Ctrl+C.

Every single instruction I give to Claude Code has to be spoken clearly, in plain language, with enough context for the AI to act on it correctly. There is no shortcut. There is no muscle memory to fall back on. If I want a function renamed, I say what function, what the new name should be, and why. If I want a database schema changed, I describe the change in words that leave no room for misinterpretation.

This sounds like a limitation. It is actually the method.

What the constraint reveals

Most developers interact with code through habits. They type patterns they have typed a thousand times. They navigate files through keyboard shortcuts they learned years ago. They copy code blocks and modify them by hand, making small adjustments based on visual pattern recognition.

None of that works when you build the way I build. And here is the thing: none of that is what makes software good. What makes software good is knowing what you want it to do and being able to articulate that clearly enough for someone, or something, to build it.

When I direct Claude Code, I am doing exactly what a project manager does when they write a specification. I am doing what a CEO does when they describe a product requirement. I am doing what any non-technical leader does when they tell a developer what they need.

The difference is that the developer I am talking to responds in seconds and builds exactly what I described.

Why this matters for everyone

The reason non-technical people can build software with Claude Code is the same reason I can build software with Claude Code: the skill is articulation, not typing.

If you can describe what you want a tool to do, you can build it. If you can explain what data it should handle and what output it should produce, you can direct the build. If you can look at the result and say "that is not what I meant, change this part," you can iterate.

There is no prior programming habit to unlearn. There is no syntax to memorize. There is no IDE to configure. There is a conversation, and in that conversation, clarity wins.

People who have never written code often give better instructions to Claude Code than experienced developers, because they describe what they want instead of trying to write it themselves. The experienced developer fights the tool. The clear communicator uses it.

What the tools caught up to

For most of my career, the tools did not work the way I needed them to work. Code editors assumed two working hands on a keyboard. Version control assumed you could type commands in a terminal. Deployment pipelines assumed you could click through 15 steps without losing your cursor position.

Claude Code does not assume any of that. It assumes you can describe what you want. That is it.

This is not just an accessibility win, although it is that. It is a design principle. The tools that work for people with physical constraints are the same tools that work for people without technical training. The interface is language. The input is clarity. The output is working software.

Accessible Futures

I built the Accessible Futures program because I know what it means when a tool finally works the way your body and mind actually function. I know the difference between a tool that accommodates you and a tool that was designed for you from the start.

If you are building with a body that works differently, or you know someone who is, Explore Accessible Futures was built for exactly this moment.

Get posts like this in your inbox

No spam. New articles on AI strategy, governance, and building with AI for small business.