I Don’t Know What I’m Doing. That’s the Point.
What dyslexia, a terminal, and thirty years of game production taught me about using Claude Code
How a non-technical, dyslexic game producer uses Claude Code as a serious daily tool
Why “explain this like I’m ten” is a power move, not an admission of failure
The screenshot as interface: treating error output like a bug report you can’t read
What you actually need to understand before agentic tools will work for you
When I write about Claude Code, I probably sound like someone who has a home server running Arch Linux and strong opinions about package managers. I want to set the record straight. I don’t know what Arch Linux is. I have no opinions about package managers. I have used a terminal for eighteen months and I remain, at best, an unreliable tenant.
I am a game producer. I have been one for thirty years. I have shipped over twenty free-to-play titles, built production systems for studios with hundreds of people, and spent more time thinking about flow metrics and delivery cadence than most people consider healthy. I am not a developer. And I have dyslexia.
I mention both of those things together because they interact. Dyslexia is not, for me, primarily a reading problem. It is a processing problem. When I look at a wall of monospace text in a console window, my brain does not parse it the way yours might. Error messages, stack traces, dependency warnings. They blur. The structure disappears. I can read the individual words and still not extract what the text is telling me.
That is the starting point. Not a barrier I overcame. Just the context.
About 10% of the UK population is dyslexic. Around 73% of dyslexic employees have never received formal support at work. That second number does not surprise me. Dyslexia is one of those conditions that companies acknowledge in their inclusion policies and then forget about the moment the work is actually happening. The support that exists is mostly designed around documents and communication, not around the specific texture of technical work.
Claude Code is not designed as an accessibility tool. But for me, it functions as one.
Here is what my working session with Claude Code actually looks like.
I have a project running. Something goes wrong, or I need to do something I have not done before, or a process I kicked off produces output I cannot interpret. My first move is a screenshot. I take a picture of whatever is on my screen and I paste it into Claude Code. Then I write: “This is what I see. I don’t understand it.” That is the whole message. Sometimes I add: “What do I do next?”
That is not a workaround. That is my interface.
The screenshot as communication method probably sounds primitive to a developer. It is, in some ways. But it is precise. I am not trying to describe what I am seeing and introducing translation errors. I am showing it directly. Claude Code can read the screen. It tells me what the error means, what caused it, and what I should do. Then I do that thing. If I do not understand the instruction, I ask again.
“Read me step one like I’m a ten-year-old.”
I say this regularly. I say it without embarrassment. Because “explain it simply” is not a confession of stupidity. It is the most efficient path through confusion when you are stuck and time matters. The developers who pride themselves on wrestling with documentation and figuring it out the hard way are doing something admirable and something slow. I am not there to be admirable. I am there to ship.
Between Claude Code and the console, my role is cut and paste. I take the output from the console, paste it in. I take what Claude Code tells me to run, paste it into the console. I am the messenger. This is not an embarrassing admission. The reasoning is happening. The work is getting done. My value is not in my ability to memorise terminal syntax. It is in my ability to understand what I am building, why it should work, and what to do when it does not.
None of this means I skipped the foundations. I took the time, early on, to understand what these tools actually are.
What is a terminal? What is an agent? What is the difference between a model and a tool? Why does Claude Code need access to my file system? What happens when I run a command? I did not need to understand the implementation. But I needed to understand the concept well enough that I could make good decisions. That investment is not optional. You cannot successfully direct a tool you have no model of.
This is the line I think a lot of people miss. The promise of AI coding tools sometimes gets framed as: you do not need to understand anything, just talk to it. That is wrong. You need to understand the shape of what you are building. You need to know when something has gone sideways, even if you cannot diagnose it yourself. What you do not need is fluency in the syntax.
Those are different things.
I have built content generation pipelines, archive processing systems, project management integrations, and game prototypes, all using Claude Code as my primary development tool. None of those projects started as technical projects. They started as ideas I understood well enough to articulate. Claude Code handled the rest, with me asking questions at every stage and feeding error output back in whenever it appeared.
People with dyslexia have a 60% greater chance of connecting ideas through alternative methods, according to some research. I do not know if that is me. But I do know that my instinct, when faced with something I cannot read, is to find another way to communicate it. The screenshot. The plain-English question. The “explain it to me simply” request that developers sometimes feel is beneath them.
Those are not workarounds. They are methods.
Claude Code’s actual superpower, the one nobody writes about in the launch posts, is patience. It does not get frustrated when you paste the same error three times. It does not assume you know what it meant the first time. It does not care if your question has a typo in it. It adjusts when you tell it you did not follow.
For someone who has spent thirty years in environments that were not built for how my brain works, that is not a small thing.
I am not suggesting that Claude Code is a perfect accessibility tool, or that it solves the problems dyslexic professionals face at work. It does not. Most of those problems are structural, and they sit well above what any software can fix.
But I am saying this: if you have been looking at Claude Code and thinking it is for developers, or for people who are more technical than you, you have misread the situation. The thing that makes it work is not syntax knowledge. It is the willingness to ask the question, however simple the question sounds, and to keep asking until you understand the answer.
I have been doing that for thirty years in meetings, reviews, and postmortems. The terminal is just a new room to do it in.
This was a great article. Thanks for opening up a bit and sharing!