Explain to me in Simple Technical English | All about coding
All about coding
Ruby and Rails technical content written by Lucian Ghinda
Explain to me in Simple Technical English
Aug 14th, 2026
#ai
#llm
#coding-agents
#developer-tools
#prompting
#technical-writing
Last week I read something about a standard for writing technical documentation in plain, unambiguous English. I did not save the link and could not remember the exact name, nor did I have time to search for it.
This week, I made changes to a part of the codebase I wasn’t very familiar with, so I had to chat with Claude and Codex to understand it better.
I observed something that had been bothering me for a while: Claude keeps reaching for complicated words, abstractions, and slightly fancy descriptions instead of simple domain terms. Thus I half-remembered this idea, and I started saying:
Explain to me in Simple Technical English
I have typed this phrase many times this week, and I felt it worked very well for me, so I have put it in the user memory or in the system instructions for all agents.
Last night I remembered to search for fuzzy thing that I was rememering and found it: ASD-STE100 Simplified Technical English .
But this got me thinking: I wrote “Simple Technical English,” and this standard is called “ASD-STE100 Simplified Technical English”. If so, would my output be better if I had used the proper term?
Thus, I did some research about it. You can see the entire experiment I run on Claude and Codex here where I shared the prompts used, the code that I used for testing and the full results.
What is ASD-STE100
Simplified Technical English is a controlled natural language. It began in the late 1970s as AECMA Simplified English and was first released in 1986. The European airline industry wanted aircraft maintenance manuals that a non-native English speaker could not misread.
It is maintained by the ASD Simplified Technical English Maintenance Group, and it has two parts:
53 writing rules in 9 sections , because grammar and sentence shape carry as much ambiguity as vocabulary does.
A dictionary of about 900 approved words , because a small vocabulary removes choice, and choice is where ambiguity enters.
The rule I like most is this one: each approved word has one meaning and one part of speech . As a non-native English speaker, this feels very good to me in interactions with LLMs.
I also liked the hard limits, such as the requirement that descriptive sentences be no more than 25 words. This is because the official goal is for STE to “make technical texts easier to understand for all readers” and “reduce Human Factor risks.”
It sounds great to me. If a maintenance manual is ambiguous, an aircraft is repaired incorrectly. The standard exists because vague technical prose has a body count.
LLMs are producing a lot of text, and reading it takes a lot of effort. Because of the fancy language they sometimes use (looking at you, Claude), there is a risk of misunderstanding or, even worse, a kind of understanding fatigue, and the chances of approving or going on with something wrong are increasing.
How I tested this
I chose 4 pieces of code from two of my own projects, and for each one I wanted to test 3 cases:
Control : no style clause at all. It defaults to all my skills and what I have installed. It is not a clean environment, but all the other experiments will have the same environment
Simple Technical English : this is the phrase that I used which is not naming the proper standard
ASD-STE100 Simplified Technical English : the standard name
Nothing else was added, removed, or changed in the entire system prompt, harness, or context. All agents got the same prompts in the same context and were running on the same setup I have.
I orchestrated all this via Claude, which ran the agents (including its own): three Claude and three Codex for each piece of code for each experiment. I ran two full sessions so we could we collected more data. I stopped after two sessions because this is not a rigorous study but rather something I intended to check.
The code that they got was looking like this:
Target<br>Size<br>Why this one
A Rails Idempotency concern<br>95 lines<br>Control-flow complexity: callback ordering and a hand-dispatched rescue handler
A single method, build_blocks<br>11 lines<br>Smallest unit, and dense with domain words already in the code
A single method, count_transpositions<br>12 lines<br>Same size as #2 but with no domain vocabulary, pure algorithm for similarity
A whole query object, DraftQuery<br>130 lines<br>Same size as #1, but data shaping instead of control flow
My main complaint was that the model was “inventing” or picking abstractions that obscure real understanding, so I wanted to offer a couple of situations that could push the model in that direction.
One example of a run and the output
I will not write about each example run here, as it would become a very long article. But you can read all of them in the repo...