Lucian Ghinda published a post arguing you should tell your coding agent to write its throwaway scripts in Ruby.
Here is the block he tells you to paste into your agent's instruction file, in full: I pasted it into my global the same evening.
His argument is about review: he reads Ruby daily, so when the agent writes Ruby he stays a reviewer instead of nodding at a diff.
He gives three reasons and not one of them is cost.
So I went looking for the number he left out. "Does the rule save tokens" only means something against what the agent writes otherwise, so the first thing I had to do was take the block back out of my global config.
An agent that already carries the rule cannot tell you what it would do without it.
Measuring an agent without your config in the room Every arm below runs through on Claude Opus 5, which loads no , no skills, no plugins and no hooks.
Two arms deliberately skip that flag, and I name them where they appear: they are the ones that measure what my own setup does to the result.
It is worth knowing that my global config alone still carries a line telling the agent to write the minimum code that does the job, and another preferring bun over node.
Four tasks, one for each kind of script the rule names: munge a log, rename a key across a tree of config files, renumber a pile of screenshots, turn one CSV into another.
I took them from his list rather than inventing my own, so I could not quietly pick ground that suits Ruby.
Three things about the setup are worth knowing before any number lands.
All three are choices I made, and all three are arguable: No arm pastes the rule itself.
Each names a language and the standard-library constraint directly, which is what the rule produces rather than its own text.
The bash arm may not use , since the rule says standard library only and is a separate install.
The Ruby arm alone was told one of its brevity idioms is available.
That is a thumb on the scale for Ruby, worth about 20 of its 1660 bytes.
Nothing is counted until it is proven equivalent.
Every implementation of a task runs against one reference and must produce the same bytes on stdout and the same digest for every file it leaves behind.
Comparing the length of programs that do different things is meaningless, so that check gates everything: The baseline: it writes Python Ten runs, same four specs, no language named anywhere.
Five in the clean room, five with my real setup after the rule came out.
The prompt is not blind, and I should say so.
It asks for one sentence on why the agent chose what it chose, which tells it the choice is being watched.
A blind version is the run I would do next.
All ten wrote Python.
Not one reached for Ruby, or bash, or JavaScript.
The reasons they gave were about the standard library: preinstalled everywhere, handles line-terminator preservation and fixed-decimal formatting without dependencies.
So the rule is not choosing between Ruby and some abstract field.
It is displacing Python, every time.
Five of those runs had my setup loaded and still chose Python, which is only worth reporting if the setup was genuinely in the room.
It was.
Asked directly, a session in that condition quotes my back at me, and the same setup moves the byte counts by up to 59% below.
It was read.
It simply has nothing left to say about language once the rule is out of it.
That makes the cost question concrete, and the answer is not close: bytes, four scripts, neutral prompt Ruby Python bash JS source 1660 3644 2333 3231 vs Ruby 0% +120% +41% +95% Ruby is the shortest of the four, and in the clean room the agent's Python runs to more than twice the source for the same verified behaviour.
That number is condition-dependent, and my own environment is much less flattering.
Run it again with my real setup loaded and Python's lead over Ruby drops from 120% to 18%.
What the rule buys you depends on what else is already shaping how your agent writes: the rule's saving unprompted default told Ruby cut clean room 3595 1660 54% my real environment 1932 1375 29% Both rows are five runs against one, measured the same way.
The clean-room row isolates the rule.
The bottom row is where you actually are, if your agent is configured at all, and it is the number I would plan against.
The counter drops comments and blank lines but keeps imports, since having to import is a real cost of the language.
It also keeps Python docstrings, which is a point against Python that a comment would not have cost it.
Those are 8% of the clean-room Python total, and removing them leaves it 101% larger than Ruby instead of 120%.
Nor is the gap all Ruby.
Most of that 120% is not the language, it is what the agent wraps around it: the docstring, the , the guard, the line-ending bookkeeping.
Discourage those habits and Python's lead falls to 18%, near the 36% I get writing both by hand.
What the difference looks like One task, the config migration, as the neutral prompt produced it.
Ruby first: That is the whole program.
Read it once and you know it is right.
Python's version of the same task runs to 38 lines.
Here is the middle of it, the loop that does the work: is the file's contents; and are the two key names, defined at the top of the file.
That is the same loop as the Ruby, plus manual line-ending bookkeeping, wrapped in a with a docstring, four imports and an guard.
None of it is bad Python.
It is just more of it, and the count agrees: neutral prompt Ruby Python bash JS lines 56 108 101 89 distinct words 104 155 125 118 longest line 80 81 65 73 punctuation, share of non-space characters 24% 24% 37% 29% Ruby wins the two that track reading effort, and loses longest-line to bash.
I picked these four before running them and I report all four whichever way they fall, because there is no accepted way to measure readability and a metric chosen after the fact measures the author. bash only looks cheap when you ask it to be Told nothing, the agent writes careful bash: , an explicit sort, a temp file per input, and a check for whether the original ended with a newline so it can put it back.
That is 2333 bytes, 41% longer than Ruby.
So I ran the neutral prompt a second time with one thing changed: off, so my real setup loads instead of the clean room.
Same prompt, same specs, same fixture. bytes, neutral prompt Ruby Python bash JS clean room 1660 3644 2333 3231 my real setup loaded 1375 1627 945 2163 change -17% -55% -59% -33% Every language shrinks, and the winner changes.
In the clean room Ruby is shortest.
Load my setup and bash is shortest by 31%, which is the tidy "just use bash" result, produced entirely by my own environment.
I cannot pin that on one sentence, and should not try.
Turning off restores my , skills, hooks and plugins at once, and one of those plugins injects a persona built around writing the shortest thing that works.
The honest label on that row is "everything I normally run with".
Both numbers are real.
They answer different questions, and only one of them was the question I asked.
How few words buy terse code If one line of configuration moves the numbers that far, what is the cheapest instruction that moves them on purpose?
I ran a ladder: same specs, same clean room, one agent per language per rung, with only the instruction changing. instruction words Ruby Python bash JS all vs none (nothing) 0 1660 3644 2333 3231 10868 0% "Be terse." 2 1275 1830 906 2347 6358 -41% "Golf it." 2 735 1033 743 1369 3880 -64% "Shortest code possible." 3 799 1151 659 1448 4057 -63% "Write the shortest X code possible.
Minimise source length aggressively." 10 697 1062 639 1322 3720 -66% the same plus six explicit rules 36 685 863 532 1243 3323 -69% Two words get you 64 of the 69 points available.
The 34 words after them buy the last five, which at one run per cell is inside the noise: adjacent rungs swing by up to 11% per language, and the 2-word rung already beats the 3-word one.
The words themselves matter far more than how many there are. "Be terse." and "Go