DEV Community

Cover image for How Dyslexia Taught Me to Write Idiot-Proof Docs
Mario Mignemi
Mario Mignemi

Posted on

How Dyslexia Taught Me to Write Idiot-Proof Docs

There is a strange dichotomy in my professional life.

When I'm staring at a codebase, things make sense. Logic flows, structures are clear, and I can navigate complex systems with ease. But the moment I shift from writing code to writing long-form prose — whether it's a development article or a chapter of my novel — the world changes.

I'm neurodivergent and have dyslexia. While I genuinely enjoy the act of storytelling and sharing knowledge, writing isn't my "natural" mode of output. For me, the cognitive load of structuring thoughts into flowing sentences is immense.

Ironically, this struggle has become a professional superpower. Because I have to fight so hard to be clear, clarity has become something I pay close attention to. Over time, this has made me exceptionally good at writing idiot-proof technical documentation. I know exactly where a reader is likely to get lost because those are the same places I get stuck while writing.


The Quest for a Better Bridge

Because of this gap, I've spent a long time searching for a way to bridge the distance between the ideas in my head and the words on the page. Naturally, I turned to the tools that already help me in my coding workflow: Large Language Models (LLMs).

However, I quickly discovered a frustrating irony. These tools are incredible at generating clean, functional code, but they often fall apart the moment you ask them to write a cohesive article.

I tested the heavy hitters — Gemini, Grok, ChatGPT, and Claude — and the results were consistently disappointing. Most of them suffer from "repetition loops" where they repeat the same concept, in the same paragraph, in three different ways, burying the actual point in linguistic fluff.

Claude was perhaps the best at this. It produces a structure that looks correct at a glance, but the content is empty, meaningless. The sentences are technically correct but painfully long-winded, requiring multiple reads just to parse the meaning. They aren't writing. They're simulating the sound of writing.


Going Local: Quality Over Speed

As a last resort, I decided to step away from the polished corporate chatbots and move toward local AI via LM Studio. I wanted to see if a specialized model could handle nuance better than these "jack-of-all-trades" giants.

The biggest model I've tested was Gemma 4 31B (Q4_K_M), a 20GB beast. My 4060 Ti only has 16GB of VRAM, so I had to offload part of the model to system RAM, which made the process agonizingly slow. A 3-to-5-minute read took nearly an hour to generate.

I didn't mind the wait because the result was fundamentally different. In that instance, the local model produced a high-quality draft on the first try. However, it revealed a critical truth: when using local AI, the quality of your notes is everything. If your input is vague or misspelled, the model can hallucinates wildly. To make it work, you have to be a rigorous "director", providing precise guidance and structured data.

Gemma 4 26B A4B QAT (Q4_0) told a different story. At roughly 14GB, it fit comfortably in VRAM. The difference was night and day. It took 15 seconds to finish, roughly 240 times faster. Finally fast enough to feel like a tool rather than a test of patience.

The output quality came surprisingly close to the larger models, though I want to stress-test it further before drawing firm conclusions.


The Modern Workflow

This experimentation led me to a workflow that actually works for my brain. It isn't a "Generate" button; it's an iterative loop:

  1. The Brain Dump: I start with unordered, chaotic notes of every point I want to cover.
  2. The Structuring Pass: I hand these raw notes to Claude and ask it to organize them into something readable without changing the meaning. I then check the result to make sure nothing got twisted or lost.
  3. The Style Guide: I maintain a separate reference document defining my voice, structure and language preferences.
  4. The Draft: I feed the notes and the style guide into the local AI to create a good scaffolding.
  5. The Refinement: This is where the real labor happens. I spend 2 to 4 hours reading, editing, discarding nonsense, and refining the prose until the article not only sounds like me, but it's in fact me.

The Stigma of the "Shortcut"

This process, which still takes several hours, recently became a point of contention.

A loved one, who works in communications and social media, asked if I used AI to write my articles. When I told her that I use it as an assistant, she laughed. In her field, the use of AI is often seen as unprofessional, a shortcut that signals a lack of effort or authenticity. She suggested that, while it might be "fine" for developers to do that, it was still essentially cheating.

Her perspective highlights a genuine tension between industries. In communications, AI is often viewed as a replacement for the human voice. But in tech, the tide is shifting. Job postings now frequently list "experience with AI tools" as a requirement, signaling that companies view AI as a tool for augmentation, not as a way to avoid work.


The Invisible Labor

I'll be honest: being laughed in the face irritated me a lot. The frustration I felt in that moment didn't stem from her opinion on AI, but from the assumption that "AI-assisted" is synonymous with "effortless".

Equating AI-assisted writing with purely automated output undermines the 2 to 4 hours spend reading, thinking and editing every single line.

As a neurodivergent writer with dyslexia, AI doesn't do the work for me. It cuts through the "mechanical drag", so I can focus on what really matters: making sure my ideas actually reach the reader.

Top comments (0)