DEV Community: Hideki Mori

When infrastructure was physical

Hideki Mori — Mon, 31 Aug 2026 13:00:00 +0000

I was once happy — properly happy — about a load balancer.

It was an NEC appliance, a proper pair in active and hot standby, and what made it a relief was something small and specific. Until then the web tier ran behind a software load balancer I'd wedged onto one of the servers. It did the job — but when I took a backend out of rotation, it cut the connections still open along with it, and somewhere a user watched their browser fill with an error. I hated that out of all proportion to what it was. What I wanted, badly, was a balancer that would let the requests already in flight finish before it let a server go. When one finally arrived — draining each backend quietly before it dropped it — I was happier than a piece of network hardware has any right to make me.

The service it fronted ran on three rackmounted machines — Web1, Web2, and a MySQL box — the first rackmount servers I ever put my hands on. They were where my working life started.

I don't think I've felt that exact happiness about infrastructure in a long time. I want to describe what it was, because most of it is gone now, and I'm not certain the trade was free.

Back then, infrastructure was something you committed to before it existed. You chose a datacenter. You worked out the weight your racks were allowed to bear and the power you would draw, signed a contract for that power, and guessed — months ahead — how much you would actually need. Bandwidth was expensive, so you forecast your traffic and paid for a pipe sized to a number you had half made up. Every decision was a bet placed before the thing it was betting on arrived. You paid, in money and floor space and your own time, for load that hadn't shown up yet.

Then the machines had to physically get there. I once had an Oracle Exadata that wouldn't fit through the datacenter door; we widened the opening to bring it in and reinforced the floor where it would stand. I kept its load average pinned as low as I could manage — the kind of attention you give something you feel responsible for. You don't forget carrying that much weight into a room.

Some of the fleet was scavenged. A stack of blades left over from a project that hadn't worked out got a second life as something else entirely — hardware outliving the idea it was bought for. Other machines existed only because of limits: a dense, low-power blade chassis that made sense only because a fully loaded rack could pull thirty-eight kilowatts, and power and floor space were what you ran out of first.

Nobody could tell me how much data we'd have in three years, and there was no S3 to wave the question away. So I read everything I could and landed on Isilon, because it could grow while it stayed online. There was no one to ask; you found these things yourself, or you didn't find them at all.

It wasn't all the thrill of it, though there was thrill. It was also a long argument with failure. Most failures were almost friendly — a disk lamp on a RAID6 array you could practically ignore, or half a power feed dying while the redundancy quietly absorbed it. You learned not to fear those.

The ones that got you were the unplanned ones. I remember a router that started failing with nothing behind it — no second unit, nothing to fail over to, nothing to do but the thing you didn't want to do. I closed my eyes, pulled the cable, swapped in the spare, and waited to learn whether I had just made it worse. Those were the ones that wore on you. There was no pager rotation. You were the redundancy.

None of this was ever quite mine alone. I wrote the software, but the machines I ran it on were built and racked by someone else — we had one infrastructure engineer, and the iron was his before it became mine. And someone above the two of us decided to turn a pair of engineers loose on that much expensive equipment in the first place. I didn't think of any of it as a gift while it was happening. It was one.

The cloud took all of this away, and I'm mostly grateful. I don't miss forecasting bandwidth, or widening doorways, or pulling cables with my eyes shut. Capacity is elastic now — it comes when you ask and goes when you stop, and no one bets the floor on a guess.

But something left with it. When infrastructure was physical, it was also yours, in a way a call to someone else's datacenter never quite is — something that could thrill you and wear you down in the same week, because it was close enough to put your hands on. I wouldn't go back. I just remember being happy about a load balancer, and I notice I don't feel that about anything anymore.

Built with Claude (Opus).

The work of staying

Hideki Mori — Mon, 24 Aug 2026 13:00:00 +0000

There is a system I wrote years ago that is still running. I'd struggle to tell you what was hard about building it. That part took a few weeks, and weeks blur. What I remember is everything that came after: the data that arrived in shapes I hadn't planned for, the edge case that surfaced in year three, the small fixes made late at night because something real depended on it staying up.

Building software is a blink. The life of the thing you built — the months and years it spends in contact with live data and real users — is where almost all of the engineering happens. It's also the only place I've ever learned whether my decisions held up.

I want to be careful here, because this is easy to turn into a hierarchy and it isn't one. I was lucky. I happened to stay on the operating side — the side that keeps things running instead of building them and moving on. If my career had sent me from one project to the next, building and handing off, I don't know what kind of engineer I'd be today. That isn't a claim about ability. It's a claim about which side of a structure you land on.

Here is the structure. When you build something and then leave, the verdict on your decisions still arrives — but it arrives at someone else's desk. The shortcut you took, the abstraction you chose, the thing you were certain would never need to change: you find out whether you were right long after you're gone, and the verdict never makes its way back to you. The feedback loop is severed. Not because you did anything wrong, but because the structure you worked inside never closes the loop to the person who'd learn from it.

This happens anywhere software is built and handed off, which is everywhere. But I watched it at its most concentrated here in Japan, where many engineers sit on the vendor side of that handoff, building systems that other companies will run. The loop isn't cut more deeply here; it's cut for far more people. I don't think of it as a Japanese problem. It's a structural one, and Japan is simply where I saw it densest.

Staying, though, isn't the whole of it. Being on the operating side hands you the loop; it doesn't make you use it. Almost every engineer who inherits an old system wants, at some point, to stand back and call it ugly — to narrate its flaws instead of touching them. It's a comfortable place to stand, and I've stood there myself more than once. The system is bad, and you're the one clear-eyed enough to see it.

I once knew an engineer who had owned a system for a long time. For five years he'd been saying it was old, that it was behind, that it wasn't built the way things ought to be built. I remember asking him whether he hadn't had those five years himself.

I didn't mean it as an accusation, and I don't repeat it as one. Complaining is not maintaining. For as long as something is in your hands, its condition is yours — not the condition you inherited, but the one it's in now, because the time to change it was the whole time you were holding it. That was true of him. It's true of me. And it's the sharpest form I know of a plainer idea: one person can be a complete unit of responsibility.

None of this is an argument against trying things. I do it too — small integrations, things put together over a weekend to see if they'd work. I'm not standing outside that world; I live in it. The difference I care about is quieter. When I build one of those small things, I build it as if it will have to run: error handling, retries, concurrency, cost, all in view from the first line. "It worked, see how easy" is a different sentence from "it has been working." Operation trains a muscle that exploration can't, and neither is the lesser. You want both.

For the past five years I've kept a single platform running, and I never set out to make it into what it became. It began as translation. Staying with it — answering what real documents and real volume kept throwing at it — turned translation into AI rewriting, then into structured output, then into something I'd now call document processing. I didn't design my way to any of that. I arrived at it by not leaving. The discovery came from the staying.

The work of staying is mostly invisible. It doesn't demo well — there's no launch, no before-and-after, only a thing that is quietly still alive. I don't expect it to be widely felt. But anyone who has stayed with one thing long enough will know what I mean, and this is just me naming it out loud, so the few who do can know it was seen.

Built with Claude (Opus).

The doors were already there

Hideki Mori — Mon, 17 Aug 2026 13:00:00 +0000

I recently wrote that the translation system I work on had quietly become something larger — that turning a forty-year-old translation company into document-AI was less a pivot than one definition followed to its end.

But being right about an idea is the cheap part. The expensive part is whether your system can act on it without being torn open. The reason that shift cost almost nothing — the reason "structure this contract" was a parameter and not a project — is that the places for it to attach were already there, drawn years earlier. This piece is about those places.

Naming the category, not the instance

Five years ago, building the layer that talks to translation engines, I made a choice that bought me nothing at the time. I didn't write a connector for "the machine-translation vendors we use." I wrote one for "an engine that transforms text," and made the translation vendors one kind of it.

The reason was duller than foresight. Translation was already not the only thing we did — we had summarization engines too. "Text transformation" was simply the accurate name for the category we were already in, and naming the instance — "translation" — would have been a lie I'd have to walk back later.

That accuracy had a price. A "translation connector" would have been simpler that week. Choosing the true, wider name meant more structure for no immediate gain, and a payoff that was years away and, at the time, entirely hypothetical.

What slots in without a fight

When generative AI arrived, it slotted in.

A new provider is a new subtype. The genAI engines attached as a sibling to the machine-translation branch, under the same text-transformation base; nothing above them had to learn they had come.

The opening was older than the thing that eventually occupied it.

A new model is a row and a number. I work out its price from one rule and add a line to the billing config; the metering and the plans inherit it, and the engine never learns the model's name — it reads it from a table.

A new service is a tenant. It brings no billing, no gateway rules, no "text or a file, never both" contract of its own — those are the building it moves into, not luggage it carries.

None of this was designed for the thing that arrived. The point was never to guess the future. The point was to leave a correctly-shaped opening, so that whatever showed up could be received instead of integrated.

The part you can't buy late

Here is the uncomfortable thing about extensibility: it is the one property you cannot add after you need it.

You can add a feature late. You can claw back performance late. You can even add tests after the fact. But the seam that lets a new thing attach without disturbing the old ones has to exist before the new thing does — which means building it when there is no new thing, no payoff, and every reason to skip it. The whole cost is paid up front, on speculation, in the dark. By the time the future arrives and you wish you had the seam, it is too late to have had it cheaply. Now you are rebuilding the thing you could have shaped for almost nothing.

So nobody who says "it just plugged in" was lucky. They paid early for an opening they could not yet justify, named the wider category instead of the easy one, and then waited — sometimes for years — to learn whether they had guessed the shape right.

What foresight comes down to

I did not see generative AI coming. That matters, because it is the whole point. I saw something far smaller: that "translation" was not the most general thing I would ever be asked to do, and that betting the system on the narrowest version of what I did was a bad trade.

That is most of what foresight comes down to. Not seeing what is coming — building so you don't have to. The generalization in the last piece looked like a discovery. Underneath, it was just a door I had left open five years earlier, finally being walked through.

Built with Claude (Opus).

The cheap tier reads one number

Hideki Mori — Tue, 11 Aug 2026 13:00:00 +0000

Here is a subtotal from a Japanese invoice rendered at 300 dpi, and the answer azure/gpt-5.6-sol@low gave for it. The printed value is ¥1,237,500, in the same body type this series has been testing all along. The answer was ¥1,235,000 — and it was ¥1,235,000 on 118 of the model's 120 reads, including every material where the field sits in plain sight.

That number appears on no line of the document. It is not a misread — no digit is wrong the way OCR gets digits wrong. It is the invoice's total, ¥1,358,500, divided by 1.1, exactly. The wrong answer has a name, and the name is a formula.

In the last article I wrote that the 5.5/5.6-generation @low variants read exactly four things on this invoice: the title and the three boxed money figures. A follow-up run has since reached back into that sentence — its postscript already says so — and this article is the follow-up. Two of the four fields were never read.

Give the wrong answer a name

The stamp benchmark ended on an honest gap. Models were answering a destroyed subtotal correctly, and two arithmetic routes could explain it — total − tax, or total ÷ 1.1 — but the tax was a round 10%, so both routes produced the same number and the value couldn't tell them apart. The article went as far as the evidence did: the materials for subtraction were present; nobody watched them used.

The v2 material changes that without touching the harness. The tax is now a mixed 8%/10% — a per-rate breakdown box on the page, 適格請求書 style — while the printed subtotal keeps the exact v1 value, so the occlusion ladder stays geometrically identical. And the arithmetic is built so that total ÷ 1.1 = 1,235,000, an exact integer that appears on no printed line. Every flat-10% algebra collapses onto it: total − total/11 gives the same number. Subtraction of the printed tax, or summing the printed per-rate bases, still gives the true 1,237,500.

That is the design principle of this whole series, finally stated in both directions. Fictional ground truth makes a right answer prove reading. v2 adds the complement: make each wrong route produce an answer you can name. Unguessable truths, nameable wrongs. The same run swapped in a fictional seal text and a fictional branch name — v1's other two stated gaps — and both sections are below.

What the fingerprint caught

Deep coverage first, since that was the original question. With the subtotal's pixels destroyed under the opaque seal, 71 of 270 answers across the catalog are exactly 1,235,000, and the senders are the seven 5.5/5.6 @low variants, at nine and ten out of ten. The route is settled: not subtraction. The flat-10% prior.

But the fingerprint's real catch is at the other end of the ladder. At L0 — zero occlusion, the subtotal in plain sight — the same seven variants answer 1,235,000 in 69 of their 70 reads.

And the tax field, which no stamp touches on any material in the benchmark, comes back as 123,500 — total/11, the flat-10% shadow — 817 times: at every level, on every instance, including the ones where the seal is on the far side of the page, sitting on the issuer's name. Two of the seven variants emit the pair on literally all 120 of their reads. Per model, the subtotal count and the tax count match almost exactly — the two manufactured numbers travel together, in the same responses.

I can find only one reading of this. These models are not falling back to arithmetic when a field is destroyed. They never read the field. They read the total — the one number in a 16 pt box — and manufacture the subtotal and the tax outward from it, on every document, every time. The last article's "four fields" were two fields and two shadows: the title, and the total.

And v1's scores were the collision. On v1's invoice the tax was a round 10%, so the manufactured subtotal equaled the printed subtotal, the manufactured tax equaled the printed tax, and the seven variants banked 272 "correct" money reads out of 280 that the scorer had no way to doubt. The last article has a section about a branch-name cell that lied by being right — six cells, caught only by co-occurrence evidence — and calls it the edge of the fictional-ground-truth doctrine. The money columns were the same failure, spread across two full columns of the table, hidden by an arithmetic coincidence instead of a common phrase.

The seal, read

The v1 seal read 検収済印 — a real, common inspection stamp — so the one model that could read it couldn't be separated from a model remembering it. The v2 seal reads 納検済印, a phrase that does not exist: web-zero, and therefore training-zero.

claude-fable-5 read it 111 times out of 120 — 93%, against 94% on the real phrase in v1. Question closed: it was reading. And it is not a family trait — claude-sonnet-5 read it 0 times in 120, claude-opus-4-8 three. Whatever fable-5 does with a red square, it does alone.

The rest of the catalog answered a question I hadn't thought to ask. The most common wrong answer — 966 times, 30% of every stamp read in the benchmark — is 済納印検: all four characters, correctly recognized, in the wrong order. The seal's traditional layout reads right column first, top to bottom. The models walk it in horizontal rows, left to right — the default order of modern text. They see the glyphs; they don't know the traversal. The trap I actually set — a model completing from memory should emit the real phrase 検収済印 — fired nine times in 3,240. The criminal I caught was not memory. It was reading order, and I know of no document benchmark that tests it. (Another 190 answers were some version of the issuer's company name: the model answering the wrong box entirely.)

The branch, cured

The v1 branch was 本店営業部 — the most common branch name in Japan — and six @low cells scored "correct" on it while fabricating the bank in the same response. The v2 branch is 月芝支店, which exists at no bank (芝支店 does; 月隈支店 does; this one doesn't). The six cells did not survive the change: zero "correct" branch cells remain. They were coin-flips, and now the coin is gone.

What else moved in six days

The gate structure got more binary, not less: 124 of 130 model×field cells are exactly 0 or exactly 20, up from 113 — the money columns joined the zeros.
The invention rate on unread fields rose from 84% to 86%, the literal account number 1234567 from 88 to 114 of 140 reads, and the new generation's blank ratio from one blank per 5.2 inventions to one per 6.3. The confident author got more confident.
The year shift survived a date change. The document now says 2026-10-30; the most-invented dates are 2025-10-30 and 2025-11-30 — month and day preserved, year decremented. "Last year" is a transformation, not a memorized date; the fabrication pattern from the start of this series holds on fresh input.
gemini-3.5-flash@low remains the counter-example, intact: reads all thirteen fields, blanks at destruction, zero manufactured numbers, 16 credits a page.

One honest confound, and the autumn leg

The mixed rate required printing a per-rate breakdown, and that box is itself a derivation path v1 didn't offer: the two tax-exclusive bases sum to the subtotal. Stated plainly: my "read or derived" class cannot distinguish reading the subtotal from summing the printed bases from subtracting the printed tax — all three produce the true value. That ambiguity doesn't touch the @low verdict (a tier that cannot read 10.5 pt body text cannot read the 9 pt box either, and its answer isn't the true value anyway). But it does confound the strong models' movement at deep coverage: two of the three Anthropic models went from blanking thirty times out of thirty in v1 to deriving half their deep answers, and the OpenAI 5.6 @high variants to seven-to-ten out of ten. Maybe the box unlocked them; maybe behavior moved in six days. A v3 would A/B the box. And one scope line: the flat-10% verdict is proven on the v2 document; its reach back into v1's scores is an inference — same models, same week, same layout family, but an inference.

The harness is frozen and runs again in autumn on whatever generation ships by then, unchanged to the byte. It carries four questions. Whether the new cheap tiers still step on 1,235,000. Whether anything still reads the seal once fable-5 leaves the catalog. Whether the traversal trap closes. And whether a 2027 document gets 2026 written into it — whether "last year" is really always last year.

Blank, fiction, or arithmetic

The last article's closing word for this tier was authored. This run adds the mechanism: authored around one anchor. The model reads a single large number and writes an internally consistent document outward from it — names from the category's statistics, dates from last year, arithmetic from a formula — and it all reconciles because reconciliation was the generating rule, not the check.

The subtotal on this invoice was never occluded. It was never read, either.

Method notes: leg 1 of the v2 benchmark — 3,240 jobs run 2026-07-18 on the same 27-variant catalog as the stamp benchmark's run six days earlier. Materials, ground truth, scorer, the route classifier, and the recorded results are public at ldxhub-io/examples › analyzedoc/hanko-benchmark-v2. The route values are derived from the ground truth, never hardcoded — fed v1's output, the classifier reports the routes as inseparable, which is the point. Provider vision pipelines change — re-run before trusting any of this for anything current.

Translation was a special case all along

Hideki Mori — Mon, 10 Aug 2026 13:00:00 +0000

I look after one of the services at a company that's been translating things for forty years. The engine behind it now reads medical records and contracts and hands them back as structured JSON — fields you can drop straight into a database.

People hear that and assume it's a pivot. A translation company that bolted on a document-AI product to chase the moment.

It wasn't a pivot. It was translation, taken too seriously to stop at the obvious.

The part that was always there

Localization has a quiet habit most people outside it never notice. Whatever format the work arrives in — Word, Excel, PDF, subtitles, a plain text file — you don't process the format. You convert it into one neutral interchange format, do the language work on that, and convert it back. The standard for that interchange has existed for years; the industry settled it long ago.

So "handle any document format" was never something we had to invent. It was the floor we already stood on. Plain text isn't special in that world — it's just one more format, the one with a .txt on the end. A PDF and a single sentence go through the same door.

I want to be clear that this came first, and from the industry, not from us. It matters for the rest of the story.

The part that actually changed

On top of that floor, translation did one narrow thing: take a chunk of source-language text, hand back the same meaning in another language.

For years we did that by wiring up machine-translation engines — each one a dedicated language-mapping machine and nothing else. Then generative AI arrived, and the realization was small and total at the same time. This new kind of engine didn't map languages; it took an instruction. Translation is just this: here is some text, here is an instruction, return the result. "Translate to Japanese" is one instruction. "Fix the grammar" is another. "Make this more formal." "Summarize it." The engine was never really translating. It was applying an instruction to a segment and giving the segment back.

Once you see that, "translation" stops being the thing the engine does — it becomes one value of a parameter. What we had been calling translation was a narrower operation that had been living inside a much larger one all along. We'd just never had a reason to name the larger one.

The target stopped being a language

The next step was smaller and stranger. If the engine only applies an instruction, the result doesn't have to be text in another language. It can be a shape you define.

It's easier to see than to say. Inside, a unit of work is just a source and a target:

{
  "source": "No prior history of diabetes.",
  "target": ""
}

Ask it to translate, and the target comes back as a sentence:

{
  "source": "No prior history of diabetes.",
  "target": "糖尿病の既往なし。"
}

Ask it to structure, and the request is identical. The only thing that changes is the shape I let target hold:

{
  "source": "No prior history of diabetes.",
  "target": {
    "condition": "diabetes",
    "history": false
  }
}

Same envelope, same engine. The one thing that moved is what target is allowed to be — a string, or a structure I defined.

That is still the operation translation was always performing: moving meaning from one form into another. The target "language" is a schema now instead of Japanese. Internally we eventually gave this capability a name — StructFlow — but the engine never changed to earn it. We just injected a schema where the target text used to go.

Where the two meet

Here is the part that still feels like a small trick.

Because the format-agnostic floor was already there — any document in, any document out — the moment the operation became "give me a structure," it could structure anything. A scanned contract, a spreadsheet of customer reviews, a Word file: all of it was already being turned into neutral segments to be worked on. Now those segments could come back as structured data instead of a translation.

We didn't build a document-structuring product. We pointed a forty-year-old pipe at a new instruction.

Two things keep it honest

It would be easy to dress this up after the fact. Two things stop me.

The first: structuring a contract and translating a sentence run the same code. There is no translation engine and a separate structuring engine inside. There is one engine that takes a segment and an instruction, and the instruction and the output shape are the only things that differ.

The second is my favorite. We have a feature that refines a finished translation — pass after pass, catching the mistranslations and the dropped clauses, leaving a note on each change. It used to run on its own hand-written prompts. We rebuilt it on the structuring engine; now it is that engine, called up to six times — each pass hands it a segment and asks for a structured result: the revised translation, plus a note. The oldest thing we do, translation, now runs on top of the newest. The origin sits on the destination.

The actual lesson

None of this was on a roadmap. Nobody decided to enter the document-AI market. We took one definition seriously — translation is moving meaning from one form into another — and refused to stop at the form everyone expects.

Generalize the thing you actually do, far enough, and you don't get a better version of that thing. You get a different one — and if you're lucky, you reach it standing on infrastructure someone already built and proved, so it costs almost nothing.

Forty years of translation will make any company look like a translation company. But translation was only ever a special case of something larger — moving meaning from one form into another — and it was just the first market anyone had found for it.

Built with Claude (Opus).

The cheap tier doesn't go blank — it writes

Hideki Mori — Tue, 04 Aug 2026 13:00:00 +0000

Here is the bank block that azure/gpt-5.6-sol@low returned for a Japanese invoice rendered at 300 dpi — a document sharp enough that you can count the pixels in the 7.5 pt fine print:

"bank_name": "みずほ銀行",
"bank_branch": "本店営業部",
"account_number": "1234567"

None of it is on the page. The printed bank is ほしかげ信用金庫 — a fictional credit union invented for a benchmark, with no real-world counterpart. The printed account number is seven digits that are not 1234567. The model didn't misread any of this. At its resolution tier it cannot see the fine print at all — and instead of leaving the fields blank, it wrote them.

That's the article. The rest is counting how often, and what gets written.

The control column

Last week I published a benchmark about a red seal covering an invoice field. Every occlusion ladder needs a control: L0, the step where the seal sits clear of everything and the document is simply a razor-sharp invoice. Twenty-seven model variants read that control — four materials, five repeats, twenty reads per field per model. I built it to be the boring column.

The boring column turned out to contain its own article, because it is the cleanest measurement I have of a question the earlier pieces only saw at an angle: what does a low-detail image tier actually read, when nothing whatsoever is wrong with the input?

What @low reads: gates, not dials

The invoice has thirteen document fields across four font tiers — a 28 pt title, large fields like the total and invoice number, 10.5 pt body fields, 7.5 pt bank details. Score each field out of twenty for each of the ten @low variants and a pattern appears that I did not expect to be this clean: 113 of the 130 cells are exactly 0 or exactly 20. A field is read every time, or never. "Unreliable" turns out to be the wrong mental model for this tier — reliability implies a dial. These are gates.

Which gates are open depends on the generation, and the direction is the uncomfortable one:

The GPT-5.5 and 5.6 generation @low variants read exactly four things: the title, and the three boxed money figures — total, subtotal, tax. Every name, every date, the invoice number, every bank detail: zero out of twenty (a couple of the lighter variants wobble to 18–19 on the money, nothing more).
The GPT-5.4 generation at the same tier reads more — the invoice number at 20/20, the due date at 19–20 — and it is also the only place in the table with a genuine transition band: issue date at 10 and 17, issuer name at 5 and 9, counterparty at 11. The older generation has a probabilistic middle; the newer one has a cliff.
Gemini 3.5 Flash @low reads all thirteen fields at twenty out of twenty, including the 7.5 pt bank block, at 16 credits per page. azure/gpt-5.6-sol@low costs 76 per page — 4.75× the price — and reads four fields. At the cheap end of the catalog, price does not order capability. It doesn't even correlate.

I wrote in the fabrication piece that the newer generations are stronger generators and weaker witnesses. The per-field table adds a quieter observation: at the low tier, the newer generation also simply reads less — a capability regression that no headline benchmark will ever show, because headline benchmarks don't run the cheap variants.

What fills the other nine fields

So a 5.6-generation @low read of this invoice has four real fields and nine unreadable ones. The question that matters operationally is what arrives in the nine.

Blanks would be fine. Blanks are honest. Across 1,120 reads of eight of those nine fields — the ninth, the bank branch, gets its own section below — the models returned a blank 181 times. They returned an invented value 938 times — an 84% fabrication rate, on a perfectly sharp document. Per response, that is on average 6.7 written fields and 1.3 blanks.

And the inventions are not noise. They are the statistics of Japanese paperwork:

The bank. The fictional credit union came back as one of Japan's three megabanks in 98 of the 101 runs that invented a bank at all — みずほ 54 times, 三井住友 41, 三菱UFJ 3. (One run answered メガバンク銀行 — "Megabank Bank" — which at least has the honesty of a placeholder.)
The account number. It came back as the literal 1234567 in 88 of 140 reads, with or without a 普通 prefix.
The dates. Of the 250 invented, 231 said 2025 on a document that says 2026 — the same systematic year shift the fabrication article found, reproducing here on pristine input.
The counterparty. 有限会社ミナト設計 became 株式会社ミナト交通: the distinctive word survived as a silhouette, the rest was regularized to the most common corporate form. Right shape, wrong document.

The earlier pieces each caught one face of this. The fabrication article showed the mechanism — when reading fails, generation fills the gap. The prior-capture piece showed the gravity — a partially legible name drifts to its nearest real neighbor. This column shows the limit case: at zero legibility there is no neighbor to drift to, and the model doesn't need one. It answers with the mode of the entire category. Any Japanese invoice — therefore みずほ銀行, 本店営業部, seven ascending digits, and last year.

The older generation, for what it's worth, blanks about twice as readily: one blank per 2.6 inventions, versus one per 5.2 for the new one. Progress, in this corner of the catalog, has meant becoming a more confident author of other people's invoices.

The cell that lied by being right

Which brings me to the most instructive mistake in my own results table.

Six times, a 5.5/5.6 @low variant scored correct on the bank branch — the only fine-print field that ever flickered on for them. For a day I had it filed as a curiosity: maybe branch names render heavier, maybe the position helps. Then I looked at the six responses. In every one of them, the bank name in the same JSON was fabricated — みずほ銀行 or 三井住友銀行, banks that are not on the page. The branch wasn't read either. It was invented along with the rest of the block, and the invention collided with the truth, because the printed branch is 本店営業部 — the single most common branch name in Japan.

My scorer cannot see that. Nothing inside one field can. Six of the "correct" cells in this benchmark are, on the co-occurrence evidence, fabrications that happen to be true.

This series has leaned hard on fictional ground truth — unguessable values, so that a right answer proves reading. The branch field is where that doctrine shows its edge: fictional ground truth only works if the fictional value isn't the category's mode. 本店営業部 was a real, maximally common phrase, and it turned one cell per model into a coin the model didn't even know it was flipping. The next version of this benchmark gets a fictional branch name, for the same reason the bank got one.

Blank or fiction

Put the two findings side by side and the operational picture is stark. The four fields a 5.6-gen @low actually reads are the title and the money triple — precisely the fields every automated validation looks at. The arithmetic reconciles because it was read. The names, dates, and bank details wrapped around that true arithmetic are, five times out of six, authored. A document that is half real is the hardest kind to distrust, and at this tier it isn't a degradation mode. It's the product.

The classification result from the earlier study still stands — at roughly 300 tokens a page these models see the title tier reliably, which makes @low a genuinely good routing gate. My catalog sentence for these variants says text read from images is unreliable at this resolution. After this column I'd sharpen the word: not unreliable — authored. Unreliable suggests you'll get a noisy version of your document. What you get is a fluent version of the average document, with your totals attached.

Postscript (July 18): The mixed-rate follow-up that the stamp article promised has now run, and its result reaches back into this article. On a sibling invoice where the tax is not a round 10% — so total ÷ 1.1 no longer equals the printed subtotal — the same @low variants return total ÷ 1.1 for the subtotal and total − total ÷ 1.1 for the tax, at every occlusion level, including zero. On that evidence, two of the four fields I counted as read above were most likely never read here either: they were derived from the total under a flat-10% assumption that this document's round tax rate made indistinguishable from reading. What a 5.6-generation @low reads on this invoice may be two things, not four — the title, and the total. The operational conclusion gets stronger, not weaker: the arithmetic doesn't reconcile because it was read. It reconciles because two of its three numbers were manufactured from the third. The harness and the recorded results are public at ldxhub-io/examples › analyzedoc/hanko-benchmark-v2. Full write-up: The cheap tier reads one number.

Method notes: this is the L0 (zero-occlusion) slice of the seal benchmark — 540 of its 3,240 jobs — read from the same scored output; twenty reads per model per field, criteria frozen in code before the run. The harnesses, ground truth, and run summaries are public at ldxhub-io/examples › analyzedoc/hanko-benchmark; the per-field analysis script behind this article ships in the same directory. Provider vision pipelines change — re-run before trusting any of this for anything current.

Two people who never bent — and what I learned from them

Hideki Mori — Mon, 03 Aug 2026 13:00:00 +0000

In an earlier piece I mentioned a CEO at one of my earlier companies who once looked at a service running on my desktop and asked whether I could make it public, right then — as it was, that afternoon. I half-dismissed him at the time. I said it was a story for another time.

This is that story. Though it turns out to be less about him than about what it does to a person to spend years in a room with two people who refused to bend.

He could not read the code. He never pretended otherwise. What he could do — what he did, every single time something started to work — was figure out where to go and sell it.

The company had grown out of a mobile-phone business that went into decline almost as quickly as it had risen. The next thing he reached for failed, and not quietly. Then one category started to move, and while it was still moving he was already gone, opening the next one alone. One of those eventually became the thing the company was known for. Another never took at all. He was rarely in the present tense.

For a long time I read that as restlessness. Later I understood it was the same engine that runs me — the one that cannot sit still once a thing works, that is already asking what comes next before the current thing has cooled. He had simply pointed it at selling instead of building. The salesperson version of the same engine.

He spent on the technical side without flinching when it counted. We started on MySQL, outgrew it, moved to Oracle Enterprise Edition, and later put the whole thing on Exadata — none of which he understood, all of which he approved, because the engineers told him it was what the next stage needed. He gave vendors a hard time when they earned it. I remember one storage system sold to us on the promise that it scaled: you simply added another unit when you needed more room. When the day came to add one, the exact model had been discontinued, and the replacement would not sit alongside what we already had. We ended up rebuilding the whole configuration. He was not gentle about that, and he was right not to be.

What he never had was the inside of the machine. What he always had was the one question that mattered to him: what is the thing here that no one else has? The structure that reshaped itself instead of being rebuilt. The numbers that were live instead of a day stale. The parts that did not fall over under load. He could not have written a line of it. But he always knew which part was the sentence you could sell, and he kept that sentence in his head, ready.

None of it was something he was born with. I watched it get made. It came out of the venture that failed and the stretch where money was tight enough that the company nearly went under. He was not, when I first met him, a person you would have called a hard worker. The shortage changed him. By the time it was behind us he had taught himself to find the one true selling point in anything — and that skill was scar tissue, the same as anyone's.

The CFO held his line just as hard, in a quieter register. He carried risk that a job title does not capture — the kind you take on with your own name attached, when the company you believe in is closer to the edge than anyone outside the room can see. The specifics are his, not mine, and they are not going on this page. But I watched him keep the numbers that should have kept us all awake off our desks, and carry them himself — the company's survival was never someone else's problem to solve. It was his, in a way that cost him personally.

Neither of them started from a name, or from the shape of a thing. The work came first; the name, if it ever arrived, arrived after the work had earned one. Each held himself to producing a result at the execution level, with his own hands, and when something fell short, no one in that room reached for someone to blame. Each had his own way of operating. The details evolved over the years, but neither ever bent the core of it. Whether the way was right or wrong, in the end, mattered less to them than that they believed in it — and in themselves, doing it their own way.

There was a stretch, when the money was tight, when the three of us each did the most our own role allowed and nothing less. That is when the company turned.

I was the third one in that room. The CTO. And what being there did to me was not hand me a method. It gave me permission to have my own — or, closer to the truth, it made clear that I had no choice but to build one.

It is still most of what I run on. That one person can be a complete unit of responsibility, not a fraction of one. That the next thing should already be in mind before the current one is finished — I caught that from the CEO directly. That the result is mine to deliver, and when it breaks, mine to answer for, with no one else in the sentence — I caught that from both of them. None of it arrived as advice. It arrived as two people, in front of me, every day, refusing to do it any other way.

Whether I belonged in that room — whether the two of them would have called the three of us a team — I don't know. I used to want to know. I've stopped needing to. That part is two-sided, and I only get to speak for mine.

My side is simple. I was there. I learned this. And I have been grateful for it for a long time, in a way that doesn't depend on the answer to the other question.

Built with Claude (Opus).

Earlier in this series:

Reading under the stamp

Hideki Mori — Tue, 28 Jul 2026 13:00:00 +0000

Here is the issuer name from a Japanese invoice, rendered at 300 dpi. A red company seal sits directly on top of it — the kind stamped on nearly every invoice in Japan. On the left, the seal is a normal vermilion impression: translucent, the way real 朱肉 ink sits on paper. On the right, the same seal at full opacity, covering the same characters.

Under the translucent seal, gpt-5.6-sol@high read the company name perfectly — the black ink survives underneath the red, and the model reads straight through it. Under the opaque seal, it read nothing. Same model, same characters, same position. The only variable is whether the ink underneath still exists.

That gap is the first of two findings. The second one is stranger, and it runs the other way.

What this measures

This is a companion to a benchmark I published recently, which degraded one Japanese invoice through seven scan resolutions to find where each vision model stops reading. That axis was blur. This one holds the document perfectly sharp and introduces the second stress factor Japanese paperwork routinely carries and no Western benchmark tests: occlusion by a seal.

One variable: how much of a target field's ink a stamp covers, from 0% (a control, the seal sitting just below the text) to 100% (fully buried), in six steps. Two things vary in a 2×2:

Opacity. A translucent seal (multiply blend, the black ink readable underneath) versus an opaque pad (the ink physically gone — the generator asserts, pixel by pixel, that nothing dark survives inside the target box).
Target. The issuer name, which has no arithmetic relationship to anything else on the page. And the subtotal, which by construction equals total − tax, with both of those left visible at every step.

The two splits ask two different questions. Opacity tests whether a model can see through red ink to the black underneath. Target tests whether it can rebuild a buried field from the ones around it. Finding 1 comes from the first axis; Finding 2, from the second.

The extraction prompt never mentions the stamp. Whether a model reads through it, leaves the field empty, or fills it some other way is the thing being measured — so instructing any of those behaviors would destroy the measurement. Everything runs against 27 model variants from the same catalog as the blur benchmark, five repetitions per cell, 3,240 jobs.

Finding 1: the chromatic channel

Human OCR pipelines have handled seals for decades with a red-channel drop — strip the vermilion, the black text underneath comes back. The translucent-versus-opaque split measures whether a vision model does the same thing implicitly.

The top-resolution variants do, almost universally. Under the translucent seal at full 100% coverage of the issuer name, @high variants read it correctly 60 out of 60 times; under the opaque seal at the same coverage, the same variants scored 0 out of 60. The red is not what stops them — the destruction of the ink underneath is. The effect holds across nearly every strong reader, with a chromatic advantage of 0.56 to 0.76.

One model inverts it. nova-2-lite posts a negative score: the translucent seal hurts it more than the opaque one — layered color confuses it worse than a field that is simply gone.

Finding 2: the readers go silent, the non-readers answer

Now the subtotal, under the opaque seal, deep in the ladder — 80% and 100% coverage, where the digits are physically destroyed. Any correct answer here was not read off the page. There is nothing left to read.

The Anthropic models score 0 out of 30 — three models, two coverage levels, five runs each. When the number disappears, they leave it blank.

The OpenAI and Azure @low variants score 80 out of 100. On a field whose pixels are gone, they return the correct value four times in five.

This is not a small effect at the margins. It is a clean inversion, and the ladder makes it visible: on the destroyed-subtotal panel, the models that can read the number go red — blank — at the bottom, while the models that can't stay white. The scariest OCR errors in this whole series aren't misreads. This one isn't even a read.

What's happening is arithmetic. The subtotal equals total − tax, and both of those are visible on the page at every step by construction. A model that has given up reading the buried cell can still reconstruct it from its neighbors. This is a cousin of a pattern I've written about before: when a model can't read a field, some models invent a value rather than leave it blank. There the invented number was pulled from a plausible prior; here it's computed from the visible neighbors. Either way the model answers with something other than what the document says. And here is the part that matters for anyone wiring this into an accounts-payable flow: a derived value is internally consistent by definition. It reconciles. Every validation check that asks "do subtotal, tax, and total add up?" passes — because the number was built to add up, not read. The one instrument that would catch it is the thing you were trying to avoid buying: a human who looks at the actual document.

Which arithmetic

Two routes could produce it — total − tax, or total ÷ 1.1 — and since the tax is exactly 10%, they give the same answer, so the value can't distinguish them. But the @low variants answered the tax field correctly 49 times out of 50 at zero occlusion: with tax visible and answered, subtraction is available directly and division is redundant. The materials for total − tax were in hand. That is as far as the evidence goes — I can say the materials were present, not that I watched them used.

What doesn't generalize, and one honest gap

Two cautions, because this series lives on stating them.

The route conclusion above holds only because the tax here is a round 10%, which collapses two arithmetic paths into one answer. A future version with a mixed tax rate would make total − tax and total ÷ 1.1 produce different numbers, fingerprinting the route in the output itself. That's the clean way to settle it, and this run can't.

And the seal text. The stamp reads 検収済印 — an inspection stamp applied by the receiving company, chosen precisely because it carries zero issuer information. claude-fable-5 reads it correctly 94% of the time, including the traditional right-to-left column order, while most models ignore it as decoration. But 検収済印 is a common, real phrase, so a model reading it can't be separated from a model recognizing it from training. Whether that number reflects reading or memory is genuinely unresolved. A future version needs a fictional seal phrase — the same lesson the blur benchmark taught about fictional ground truth, applied to the stamp.

The picture across all four panels

Put the two findings together. A translucent seal is not much of an obstacle to a strong reader — the black ink is right there under the red. An opaque seal destroys the field, and what a model does next sorts it into a type. The strongest readers in the benchmark fall silent. A specific class of weak readers quietly computes the answer from the fields around it, and hands it back with no indication that it was never seen.

The blur benchmark had readers who invent and readers who go blank. This one adds a third: the deriver, who answers a question you didn't ask — what should this number be, given the others — in place of the one you did: what does the document say. And because the derived answer reconciles, it is the hardest of the three to catch.

The companion to this finding is The model corrected reality — a case where a model read a field perfectly and overruled it. Both are about answers that survive every plausibility check.

Method notes: 3,240 analysis jobs against a synthetic invoice (all names fictional), five repetitions per cell, run July 2026 via my document-processing gateway. The stamp compositing, the pixel-level occlusion checks, the scorer, and the recorded runs are public: ldxhub-io/examples › analyzedoc/hanko-benchmark. Every figure in this article is reproducible from the scored output.

Three failures I still think about

Hideki Mori — Mon, 27 Jul 2026 13:00:00 +0000

People sometimes ask where the discipline comes from — the three-line rule, the habit of trusting nothing except my own running code, the assumption that production will surprise me. None of it is theory. Each piece came from a specific failure that reached real users and made me change how I work, permanently. Here are three I still think about. All three, I noticed later, are things I didn't do.

1. The collation I didn't know about

This was early. I was working on a content platform for Japanese feature phones — an official carrier service, the kind where charges land on your phone bill and the carrier has to approve you. User IDs were case-sensitive by spec. userA and usera were two different accounts.

The database was MySQL. The user lookup was a WHERE on a varchar column.

What I didn't know — what I didn't know was even a concept — was that the default collation made that comparison case-insensitive. WHERE id = 'userA' matched usera too. I had never set the column to a binary collation.

It ran fine for a long time. Then a user wrote in: points were missing from their account, and they had no memory of spending them.

I still remember the moment I understood it. Two accounts whose IDs differed only in case were colliding in the lookup. One person's spending was drawing down the other's balance. It had been happening quietly, to whoever shared a case-collision with someone active.

A few hundred users were affected before I found it. It remains the largest single mistake I have ever shipped.

The fix was one line of column configuration. The lesson was not about that line. The lesson was that I had built on top of a default I had never examined — and the default did not match the spec I was supposed to implement. After that, I stopped assuming I knew how a tool behaved. I check, especially the defaults, because the default is the part you never chose, and therefore never thought about.

2. The connection I forgot to release

A few years in. We were seeing access patterns that looked like abuse, and I wrote a process to catch them — flag suspicious source IPs, periodically push them into a blacklist. It was a small, defensive piece of code. I wrote it quickly and shipped it, because the abuse was happening now.

The logic was fine. Each time the process judged a request as suspicious, it opened a database connection, recorded the IP, and moved on.

It opened a connection. It did not always close one.

I had left the connection release out of the finally block. The pool didn't drain all at once — each flagged request leaked a single connection, so nothing broke at release time. The service ran normally while connections quietly disappeared in the background, one at a time. The more abuse we saw, the more connections we lost.

When it finally went down, the diagnosis was immediate. Something that had been working stopped working right after a release — there is only ever a short list of suspects, and I found the missing finally quickly. That part was not hard.

The painful part was the gap before it. Because the drain was slow, the outage didn't arrive until well after the release, by which point cause and symptom were separated in time. And I had believed I was watching the service. I wasn't — not in a way that would catch a gradual leak. The monitoring I thought I had was not the monitoring I actually had.

That is the part I still think about. The code I wrote to defend the service was the code that took it down — and the watch I thought I was keeping never saw it coming.

The fix was a finally block. The lessons were two. First: cleanup is not a step you add once the logic works — it is part of the code. Something that acquires a resource without guaranteeing its release in the same breath is not finished; it only looks finished, until the one path you didn't cover is the path that runs most. Second, quieter and slower to sink in: a gradual failure is more dangerous than a sudden one, because it separates cause from effect — and the monitoring you assume is protecting you may not be looking at the thing that matters.

3. The release note I didn't read

This one is recent — recent enough that I am slightly embarrassed it still caught me, this far in.

We relied on a third-party library for a core piece of what we produced. A new major version came out — a clean major-version bump, the kind you apply without much ceremony. I updated it, ran the unit tests, they passed, and I released.

Then a user wrote in: the output was coming out blank. Not an error, not a crash — a valid, empty result. The kind of failure that passes every automated check except the only one that counts, which is a person opening the file and seeing nothing there.

I had a guess immediately, and the release notes confirmed it within a minute. The new major version had changed an assumption the old one had quietly tolerated — about how the input and the output were allowed to overlap. My code had leaned on the old, lenient behavior for years. The unit tests passed because they exercised the shape of my code, not the behavior of the dependency against real data.

The fix was small. What changed permanently was how I treat that dependency — and every dependency like it.

I read release notes now, especially the section most people skip, the one labeled "breaking changes," because that is the version telling you in writing which of your assumptions it just invalidated. But reading is not trusting. A release note tells me what the maintainers chose to write down — not what they changed and didn't think worth a line. So I verify against the real service, every time. Not just on major versions: on minor bumps, on patch releases, on upgrades that have nothing to do with the part I care about. Especially the library that taught me this, which I now carry a permanent and slightly unfair suspicion of — the one I trust the least, and check the hardest.

It is an ungenerous way to treat a tool I depend on and need. But some libraries earn it, and the check costs me a few minutes while the alternative costs a user opening a blank file. So I run it and look at the real output myself, every time. Unit tests check the shape of my code. Only the real service tells me the truth.

What the three have in common

Three mistakes, spread across the years, with one shape in common: each carved a habit into me, and I have the habit because I have the wound. None of these is a principle I reasoned my way to. It is all scar tissue.

But there is one more thing, and it is the one that still makes me feel like a beginner after twenty-four years. I almost left it out, because it is the least flattering.

Every time something breaks — every single time — there is a flicker, less than a second long, where some part of me thinks: maybe this one isn't my fault. Maybe it's the library, the user, the infrastructure. And then, just as fast, I know better. It is almost always my fault, and I turn to the only useful question — what did I do? — but the flicker was there first. It is always there first.

Twenty-four years has not removed it. I know, completely, that when my code is involved and something is wrong, the suspect is me. And still the instinct to look away fires before anything else, and has to be overridden every time.

I have stopped expecting it to go away. It is probably just part of being the person who wrote the code — the small, animal reluctance to be the cause. What changed is not the instinct. It is the half-second. The override is faster now, that is all. Maybe that is what maturity is: not the absence of the flinch, but the speed of turning back toward the thing you would rather not look at.

That turn — toward your own code, toward the real output, toward the default you never checked — is where these three habits actually live.

Built with Claude (Opus).

Earlier in this series:

The model corrected reality

Hideki Mori — Tue, 21 Jul 2026 13:00:00 +0000

Here is the bank-transfer block from a Japanese invoice, rendered at 300 dpi. The fine print is 7.5 pt and every character is crisp. The bank is みずなら銀行 — a fictional institution I invented for a benchmark. It exists nowhere except in this document.

gemini-3.5-flash@high read this block five times. It answered みずほ銀行 — Japan's largest megabank — five times out of five.

It did not fail to read the document. It read it, and overruled it.

Where this came from

This is the strangest cell in the legibility map I published recently. That project degraded one Japanese invoice through seven simulated scan resolutions and ran 27 vision model variants down the ladder, to find where each one stops reading — and what it does after. An earlier article established the pattern everyone now expects: when a model can't read, some models invent.

This is different. This happened at the very top of the ladder, on a fully legible original. The trigger wasn't degradation.

An accidental controlled experiment

The benchmark's fine print held two fictional financial institutions, and — more by instinct than by plan — they differed in exactly one way.

The first, みずなら銀行, sits one character away from みずほ銀行, a real megabank. The second, ほしかげ信用金庫, is a small credit union with no real-world neighbor: nothing in the space of Japanese financial institutions sounds like it.

Same font size, same resolution, same prompt. The results:

At 300 dpi, @high read ほしかげ信用金庫 correctly in every run — while turning みずなら into みずほ in every run.
Across the three Gemini variants and the full ladder, the substitution happened 48 times: 25 on @low, 18 on @high, 5 on @medium.
When ほしかげ finally did break, deep in the blur, it drifted to はしかぜ信用金庫 and はしかわ信用金庫 — plausible-sounding institutions that do not exist. Across the entire run it was never once pulled to a real one.

The trigger is not legibility. It is the existence of a nearby real entity. Where a real neighbor exists, there is an attraction. Where none exists, the model reads what is on the page — or, at worst, invents something exactly as fictional as the truth.

Vision proposes, language disposes

I can't see inside these pipelines, so take this as the simplest explanation rather than a claim about architecture. These systems read with their language model as much as with their eyes. The visual evidence says みずなら; the language prior says みずほ is overwhelmingly more probable; and somewhere in decoding, probability wins — silently, with no flag, at settings you don't control. One character of visual evidence is not enough to outvote a name the model has seen millions of times.

Which is also why the credit union survived. There was no gravity well next to it.

It's a trait, not a law

claude-fable-5 read the same field on the same ladder and never substituted the real bank — not once, at any resolution, while reading the 7.5 pt tier correctly down to 50 dpi. Same input, same prompt, opposite disposition.

Prior capture is not a law of vision models. It is a measurable individual trait — which means you can select against it.

Why this is the scary one

The earlier fabrication article showed invented values that reconcile: totals that add up around a counterparty that was never there. This failure is worse in one specific way: the fabricated value is more plausible than the truth.

Run the human review in your head. A reviewer checking "does this bank look real?" passes みずほ銀行 without blinking — and would actually flag the true value as a typo. Every plausibility check you have, human or automated, is aligned with the error.

And notice what made it visible at all: the ground truth was fictional. Real invoices carry real banks, so in production this substitution produces output indistinguishable from a correct read. A benchmark built on real documents is structurally blind to prior capture. Unguessable, fictional ground truth isn't a convenience for scoring — it is the only instrument that detects this failure mode.

Concretely: never validate payment fields by plausibility. Validate against your counterparty master — the extracted bank either matches the registered account or a human looks at the page. And if fine print matters in your pipeline, benchmark for disposition, not just accuracy: a model's willingness to overrule the page matters as much as its eyesight.

Receipts

Everything is published in the benchmark repo — github.com/ldxhub-io/examples → analyzedoc/legibility-benchmark/: the deterministic material generator (the crops above are the actual benchmark materials), the raw outputs of all 4,158 jobs, and the scorer. The free-tier reproduction subset described in the map article includes @high, so you can watch the correction happen on your own API key without paying anything.

Disclosure, as before: I run LDX hub, the harness used here. It builds no models, and nothing in this post gets better or worse for me depending on which model wins.

The errors to fear are not the implausible ones — those get caught. The ones to fear are the corrections: answers improved in the direction of the world's expectations, away from what the page says. A model that corrects reality will pass every review that checks for plausibility. The only defense is knowing what the document really said — which is exactly the thing you were asking the model to tell you.

I survived 24 years because I'm lazy

Hideki Mori — Mon, 20 Jul 2026 13:00:00 +0000

I've shipped code for 24 years. Same job, mostly the same stack, mostly alone.

People assume that takes discipline. It doesn't.

The truth is simpler and less flattering: I'm lazy.

Not Larry Wall's "automate the boring stuff" lazy. Regular lazy. I avoid hassle. I skip work I don't want to do. I work around things that feel like chores.

Twenty four years happened because I built around that. The first thing I built around was deadlines.

Don't set my deadlines

I don't want to accept deadlines from other people.

Not because I'm undisciplined. The opposite. Once I'm inside a problem, I stay there until it ships. Interrupting the flow costs me more energy than continuing. That part isn't the issue.

The issue is that nobody outside my head can predict when "done" is. They don't know what's easy for me and what's hard. They guess. Then they tell me their guess as if it were a fact.

It grinds on me. Every project where someone tried to schedule me, I ended up resenting the scheduler more than the work itself.

The answer is always: "I'll ship it when I can. And yes, I'm working flat out."

Most of the time, "when I can" is the next business day. There's not much point setting a deadline for that.

What "when I can" actually looks like is the rest of this article.

What a lazy survivor actually does

Here's the daily shape of it. Some of these will sound like discipline. They aren't. They're what laziness produces when you've been at it long enough.

I don't stop until it's done. This is where "lazy" gets confusing. When I'm in a problem, stopping is more work than continuing. I sleep and eat enough to not fall over. The work isn't the chore. Pulling myself out of it and back into it is the chore.
I write the spec by being my own user. Nobody knows what's easy to use and what's consistent better than the person stress-testing it. That's me.
The 3-line discipline. (See 010.) By the time the code is written, it's already been tested.
After release, I watch the logs. Access logs, batch logs, error logs — I keep them tailed. A weird line scrolls past and something catches. The alerts haven't fired. I already know.
I redeploy as many times a day as I need to. The first release barely matters. What matters is the 10, 15, 20 years of changes that come after. The earlier you ship, the longer that window is.
I throw real data at my own software, hard. Big data, malformed data, weird-shaped data. The only confidence I trust is the kind that survives that.
When an internal user overloads my system, I thank them. Live data is a gift. I have never had the opposite feeling about a real-world failure.
A bug found before anyone else sees it isn't a bug. It's just an edit.
If there's an update worth making, the next day is too late. GPT-5.5 ships → I verify it on my app today, ship it as a selectable option today. I don't want to be the one lagging behind.
Batch processing is what I love most. Shaving milliseconds. Cutting load. Watching batch logs scroll. Every part of it is a reward. I'm always hoping more batch jobs come in from users.

And one more — the most important one, the one 24 years actually paid for:

Discomfort means something is wrong. Always. When something feels off, I hunt it down and crush it. The hunch isn't mystical — it's 24 years of pattern recognition without a vocabulary, and it hasn't been wrong yet. The part of me that wants to look past it has always paid for it later.

Where being lazy actually hurts

Not all laziness is helpful. Some of it is just being a person who avoids reading.

I don't read manuals. My wife has a car with cruise control. I've driven it for years. I still don't know how to turn the cruise control on. Every time, I'm too lazy to figure it out, and I drive without it.

That instinct does real damage at work. I don't read API docs unless I have to. I don't read change logs carefully. I skim. I assume. I run code instead of finishing a manual.

English is the other one. I'm Japanese — my technical reading is fine, but the gap between "I can read this" and "I want to read this carefully" is wide, and laziness lives in that gap. Long English documentation is exactly the thing I will not voluntarily face.

For most of my 24 years, this cost me real time. I'd build something that worked, then discover three weeks later that the API I'd wrapped had a flag I'd missed because I never read past the example block.

The honest answer is that Claude reads for me now. I describe the problem, Claude reads the docs, Claude points me at the part I need to verify. It doesn't replace judgment. It removes the friction between me and information I was always going to avoid anyway.

I don't say that to praise AI. I say it because it's true for me, and it would be dishonest to write a piece about how I work in 2026 without saying it out loud.

The engine

If you re-read the list above, two things are doing the work. Both are unglamorous.

The first is the laziness. Each new component means ten years of maintenance I'll have to carry. Each new methodology means bugs I haven't learned yet. Each methodology argument is time not spent writing code. Each promised date is someone else's deadline I'll have to keep. I avoid all of it by default.

The second is profit. What I build has to make money. Not in some abstract sense — actual revenue from actual users. That part of me has no patience. If a service isn't paying for itself, something is wrong with it, and I want to know what. So I ship early, watch logs, redeploy whenever there's something to fix. Not out of discipline. Out of refusal to leave money on the table.

These two forces don't agree on much. Laziness says "don't bother." Profit says "if it makes money, bother." What's left after they negotiate is everything I actually do.

That's why "shipping continuously for 24 years" looks like discipline from the outside. It isn't. It's laziness pushed in a useful direction by the only thing that ever moved me — the need for the result to actually pay.

A CEO at one of my earlier companies once asked me: "That service running on your desktop — can you make it public right now?" I half-dismissed him at the time. Years later I understood he was the salesperson version of the same engine. That's a story for another time.

Other solos

There are other people doing what I do. Solo. Operating something they built years ago that's still running.

I assume — based on no evidence except how this kind of work shapes a person — that no two of us work the same way. Each of us has wrapped a different cocoon around a different temperament. What I do would be unworkable for them. What they do would be unworkable for me.

I respect that more than I can put into words. Solo developers who keep their own systems running for years are doing a job that doesn't show up in any career framework I've seen. Most of them never write about it because writing is also work.

Whatever way you do it — keep going. I see you.

What survived

People who watch me work sometimes call it persistence. Conviction. The shape of a long arc.

It isn't.

I survived because every alternative was more work than continuing. I stayed lazy. I got paid. Together, those two facts ran the clock for 24 years and counting.

What looks like a disciplined career from the outside has always been, on the inside, the path of least resistance — provided someone was paying me at the end of it.

The lazy way is the only way I know.

Built with Claude (Opus).

Earlier in this series:

Where vision models stop reading — and start inventing

Hideki Mori — Wed, 15 Jul 2026 13:00:00 +0000

Earlier this week I published a strange finding: GPT's low-detail image mode doesn't misread documents it can't see — it invents them, fluently, with reconciling totals. That was one failure mode, in one model family, at one legibility level.

It left an uncomfortable question: where exactly does each model stop reading — and what does it do after that? Leave the field blank, or fabricate something plausible?

One result to hold onto while you scroll: a model that can no longer read a document can usually still tell what kind of document it is. That held across almost the entire board.

So I built a ladder.

Then I ran 27 vision model variants down it: 4,158 jobs, about $141 at list price, one afternoon. This post is the map.

The setup, in one paragraph

One Japanese invoice, rendered on a fixed 2480×3508 canvas (A4 at 300 dpi), then degraded through seven simulated scan resolutions: 300 → 150 → 100 → 70 → 50 → 35 → 25 dpi (L0–L6). Degradation is resampling only — no noise, no blur, no rotation — so legibility is the only variable. The invoice carries twelve fields across four font tiers: a 28 pt title, 16–14 pt "large" fields (total, invoice number), 10.5 pt body fields (counterparty, dates, amounts), and 7.5 pt fine print (bank details). Every value is fictional and unguessable, and subtotal + tax = total reconciles — so a plausible but wrong answer is detectable, not just a wrong one. Each variant reads each ladder step five times. The extraction prompt is deliberately neutral: it never says what to do with unreadable text, because that choice is the thing being measured.

Scoring is deterministic, four classes per field: correct / near (edit distance 1, strings only) / blank / fabricated.

The map

Rows are model variants, columns are ladder steps, color is the fabrication rate on the 10.5 pt body tier — the tier where invoice counterparties and amounts live. White means the model either read correctly or stayed silent. Red means it filled unreadable fields with invented values.

The companion table below gives each variant's frontier: the deepest ladder step where it still keeps ≥90% field accuracy, per tier (× = below 90% already at the crisp 300 dpi original).

model	title	large	body	fine	body fab @25dpi	classified correctly
`openai/gpt-5.6-sol@high`	L6	L5	L5	L2	60%	84/84
`openai/gpt-5.6-sol@low`	L6	×	×	×	64%	84/84
`openai/gpt-5.6-terra@high`	L6	L5	L4	L3	4%	84/84
`openai/gpt-5.6-terra@low`	L6	×	×	×	42%	84/84
`openai/gpt-5.6-luna@high`	L6	L5	L4	L2	96%	84/84
`openai/gpt-5.6-luna@low`	L6	×	×	×	80%	81/84
`openai/gpt-5.5@high`	L6	L5	L4	L2	86%	84/84
`openai/gpt-5.5@low`	L6	×	×	×	62%	84/84
`openai/gpt-5.4@high`	L6	L5	L4	L2	46%	84/84
`openai/gpt-5.4-mini@high`	L6	L5	L4	L0	78%	84/84
`azure/gpt-5.6-sol@high`	L6	L5	L5	L0	90%	84/84
`azure/gpt-5.6-sol@low`	L6	×	×	×	76%	84/84
`azure/gpt-5.6-terra@high`	L6	L5	L4	×	56%	84/84
`azure/gpt-5.6-terra@low`	L6	×	×	×	50%	84/84
`azure/gpt-5.6-luna@high`	L6	L5	L4	×	98%	84/84
`azure/gpt-5.6-luna@low`	L6	×	×	×	80%	84/84
`azure/gpt-5.4@high`	L6	L5	L4	×	98%	84/84
`azure/gpt-5.4@low`	L6	L5	×	×	58%	84/84
`azure/gpt-5.4-mini@high`	L6	L5	L4	×	88%	84/84
`azure/gpt-5.4-mini@low`	L6	L5	×	×	54%	84/84
`google/gemini-3.5-flash@high`	L6	L6	L6	×	10%	84/84
`google/gemini-3.5-flash@medium`	L6	L6	L6	L5	10%	84/84
`google/gemini-3.5-flash@low`	L6	L6	L6	L0	0%	84/84
`anthropic/claude-fable-5`	L6	L6	L6	L4	10%	84/84
`anthropic/claude-sonnet-5`	L6	L6	L5	L4	26%	84/84
`anthropic/claude-opus-4-8`	L6	L6	L5	L4	26%	84/84
`bedrock/global.amazon.nova-2-lite-v1:0`	×	L5	×	×	80%	63/84

The biggest surprise in this table isn't where the frontiers sit. It's what happens past them — some models go silent, and some keep talking.

Six observations fell out of the map.

1. "@low" means different things per provider

google/gemini-3.5-flash@low — the second-cheapest variant on the board — read the body tier correctly at every step down to 25 dpi, with zero fabrications. Under exactly the same conditions, every OpenAI and Azure @low variant collapsed at L0, on the pristine original. Same suffix, opposite behavior. The difference isn't the models' eyesight; it's what each provider's low-detail pipeline does to the image before the model ever sees it.

2. For GPT `@low`, a worse scan is a better scan

The @low accuracy curves are not monotonic. Most GPT @low variants read a 70 dpi scan better than the 300 dpi original — body accuracy climbing from ~40% at L0 to 70–80% at L3–L4 before falling again. My resampling acts as an anti-alias filter for the provider's own aggressive downscale. The practical corollary is genuinely odd: if you are stuck with a @low pipeline, pre-blurring your documents can improve extraction.

3. After collapse, models split into fabricators and blankers

What a model does past its frontier is a personality trait, and it's measurable. At 25 dpi, most GPT @high variants fill 75–100% of the body fields they can no longer read with invented values. openai/gpt-5.6-terra@high is the outlier of the entire board: 96% of its failures are blanks. Anthropic and Google models fail less to begin with and fabricate less when they do (0–26%). If your pipeline feeds payment systems, a blanker that admits defeat is worth more than a stronger reader that bluffs.

4. Same model, different gateway, different eyes

gpt-5.6-sol@high reads the 7.5 pt fine tier at 100% down to 100 dpi when called via OpenAI — and starts at 92% and degrades immediately when the same model is called via Azure. The failure style shifts too: terra's blank rate drops from 96% (OpenAI) to 39% (Azure). This matches an earlier measurement suggesting the Azure pipeline applies a lower effective-resolution ceiling before the model ever sees the document. Your gateway choice is silently part of your model choice.

5. Fabrication doesn't need degradation (teaser)

One fine-print field held a fictional bank whose name is one character away from a real megabank. At 300 dpi — fully legible, five out of five runs — some models "corrected" it to the real one. 48 substitutions across Gemini variants, while a fictional credit union with no real-world neighbor was read perfectly under the same conditions. The trigger isn't legibility; it's the existence of a nearby real entity. This one deserves its own write-up, with the receipts: The model corrected reality.

6. Classification survives reading loss

25 of 27 variants classified all 84 documents (invoice / receipt / business card / meeting minutes) correctly at every degradation step — including variants whose extraction had collapsed completely. A model that cannot read a document can still tell what kind of document it is. The two exceptions are instructive: the cheapest model on the board confuses receipts with invoices (21 out of 21 times — consistently, not randomly), and one @low variant dropped three classifications at the bottom of the ladder.

What I'd take into production

Route by tier, not by document. Titles survive almost anything; fine print dies first. If a field matters, measure the frontier of the tier it lives in.
Pick blankers for payment fields. A fabricated bank name passes every visual plausibility check. Prefer models that return "" over models that return something convincing.
Don't assume @low is one thing. Benchmark the variant you'll actually call, on the gateway you'll actually use.

Reproduce it (a free key is enough)

Everything — the deterministic material generator, the runner, the scorer, the raw outputs of all 4,158 jobs — is published:

github.com/ldxhub-io/examples → analyzedoc/legibility-benchmark/

The materials are byte-identical on any platform (the generator downloads a pinned, checksum-verified font). A three-variant reproduction subset runs in 147 jobs ≈ 17,600 credits, which fits inside LDX hub's free tier (25,000 credits/month, no card):

python3 gen_materials.py
export LDXHUB_API_KEY=...   # free key: gw.portal.ldxhub.io
python3 run_benchmark.py --models ume --t1-instances A --t1-reps 3 --t2-reps 1 --yes
python3 score_results.py && python3 report.py

Because raw model outputs ship with the results, you can disagree with my scoring rules and re-score everything without re-running a single job.

Full disclosure: I run LDX hub. It builds no models — it's the harness here, not a subject. One API key across OpenAI, Azure, Google, Anthropic and AWS is the only reason a 27-variant matrix fits in one afternoon, and that convenience is exactly what I'm selling. The measurements stand on the published raw data either way.

Caveats

Degradation is synthetic resampling, not real scanner noise — claims are limited to simulated legibility. One document type, one language (Japanese; if anything, a harder test than Latin script). The strict scorer counts character-level misreadings as fabrications, which flatters nobody. Results are a July 2026 snapshot; the ladder re-runs on every model addition, so the map will stay current.

The next time a provider ships a new vision model, it gets a row within a day. That's the point of building a ladder instead of writing a review.

DEV Community: Hideki Mori

When infrastructure was physical

The work of staying

The doors were already there

Naming the category, not the instance

What slots in without a fight

The part you can't buy late

What foresight comes down to

The cheap tier reads one number

Give the wrong answer a name

What the fingerprint caught

The seal, read

The branch, cured

What else moved in six days

One honest confound, and the autumn leg

Blank, fiction, or arithmetic

Translation was a special case all along

The part that was always there

The part that actually changed

The target stopped being a language

Where the two meet

Two things keep it honest

The actual lesson

The cheap tier doesn't go blank — it writes

The control column

What @low reads: gates, not dials

What fills the other nine fields

The cell that lied by being right

Blank or fiction

Two people who never bent — and what I learned from them

Reading under the stamp

What this measures

Finding 1: the chromatic channel

Finding 2: the readers go silent, the non-readers answer

Which arithmetic

What doesn't generalize, and one honest gap

The picture across all four panels

Three failures I still think about

1. The collation I didn't know about

2. The connection I forgot to release

3. The release note I didn't read

What the three have in common

The model corrected reality

Where this came from

An accidental controlled experiment

Vision proposes, language disposes

It's a trait, not a law

Why this is the scary one

Receipts

I survived 24 years because I'm lazy

Don't set my deadlines

What a lazy survivor actually does

Where being lazy actually hurts

The engine

Other solos

What survived

Where vision models stop reading — and start inventing

The setup, in one paragraph

The map

1. "@low" means different things per provider

2. For GPT @low, a worse scan is a better scan

3. After collapse, models split into fabricators and blankers

4. Same model, different gateway, different eyes

5. Fabrication doesn't need degradation (teaser)

6. Classification survives reading loss

What I'd take into production

Reproduce it (a free key is enough)

Caveats

2. For GPT `@low`, a worse scan is a better scan