What a 1994 factory fix says about AI in specification review

Photo by Tiger Lily on Pexels

A black and white square with three boxes in the corners is not impressive engineering. No new physics, no algorithm worth patenting a lawsuit over, nothing that would make an engineer stop mid-scroll. It's pattern recognition and error-correcting math that already existed, applied to a printed label.

If you review specifications for a living, or decide which AI tools your engineering org buys, this is still worth five minutes. It's a clean example of a mistake we watch teams make constantly with AI in specification review: reaching for intelligence before anyone has removed the manual step sitting underneath it. The two engineers who built the QR code in 1992 solved the opposite problem, in the opposite order, and it's why a factory-floor fix ended up on every phone camera on earth.

A factory floor problem

Denso Wave, the automotive parts arm of Denso, put two engineers on a request that came straight from the shop floor: workers tracking parts through manufacturing were stuck scanning traditional barcodes that held about 20 characters each. Anything more than a part number meant scanning several linked barcodes for one object. Denso Wave's own account of the project puts the daily volume at roughly 1,000 scans per worker.

Nobody needed a faster scanner or better optics. They needed to stop reading the same part five times because a label format from the 1970s couldn't hold the answer in one pass. The request came from the line, not a lab, which is why the goals were plain: more data per label, faster reads, a smaller printed footprint, and support for Japanese kanji and kana, which barcode standards at the time handled badly or not at all.

What they actually had to solve

A traditional barcode is a strip of lines read left to right, which means a scanner has to be aligned to it first. Going two-dimensional multiplied how much data a label could hold, but it created a new problem: how does a scanner know which way is up when a label could be printed upside down, sideways, or at some odd angle depending on who slapped the sticker on?

The three squares in the corners are the answer, and they're why a QR code is recognizable at a glance even to someone who has never scanned one. The engineers studied printed materials for ratios of black to white space that almost never occur naturally, and landed on 1:1:3:1:1. A scanner spots that ratio instantly at any rotation, so a phone can read a QR code held sideways, from a moving hand, on a curved surface, without anyone lining it up.

Capacity came along for free once the format went two-dimensional: a QR code holds up to roughly 7,089 numeric characters, 4,296 alphanumeric, 2,953 bytes, or 1,817 kanji, against about 20 characters for a standard barcode. Damage tolerance came from Reed-Solomon error correction in four levels, so a code still scans correctly with 7%, 15%, 25%, or up to 30% of the print obscured or torn. On a factory floor, or a coffee-stained menu, that's the difference between working in a lab and working in the real world.

The decision behind the technology

One detail gets left out of most retellings: Denso Wave owns the patent and chose not to charge royalties for using it. A brilliant two-dimensional barcode that needed a licensing call to implement would have stayed a niche automotive tool, the way plenty of equally clever proprietary formats have. Waiving the fee is what let every phone maker and every point-of-sale vendor build support for it without a lawyer in the room. The engineering solved a scanning problem. Giving it away solved a distribution problem, and distribution is the reason a factory fix became infrastructure.

What "scan once" replaced

Line up what a QR code eliminates against what it took before. None of it is complicated. That's what makes the list worth looking at.

Each row saves somewhere between ten seconds and a minute, which on its own funds nothing. But these happen billions of times a year, across a format that became an international standard within a few years and that no one pays to use. Multiply a small time saving by that kind of volume and the barrier between a customer and an action disappears at a scale no single company could have bought its way into.

Why removing a step beats being clever

A clever model applied to the wrong problem just produces a wrong answer faster. Removing friction is different: it pays off every single time the interaction happens, with no extra decision required, because the person doing it never has to think about it again. Denso Wave's engineers weren't tuning an algorithm for its own sake. They were getting rid of a step a worker repeated a thousand times a day, then, by waiving the patent, getting rid of it for everyone who ran into a version of the same problem.

None of this means the engineering was irrelevant. The error correction and the finder pattern are real, and neither was obvious beforehand. But the payoff came from where that engineering was aimed, at a step that recurred constantly at massive scale, not from how advanced the math was on its own. And it doesn't generalize without limits: Denso Wave could give the format away because it made money selling scanners and manufacturing equipment, not the symbology. A company whose whole business is the intellectual property in question doesn't have that option.

Where this shows up in specification review

Engineering teams are running the same mistake with AI right now, just in reverse order. Review is slow, or vague requirements are already costing the program before a line of code gets written, and the instinct is to point a language model at the document and ask it to summarize or rewrite. If the document is full of undefined terms, contradictory obligations, and the same requirement phrased four different ways across a thousand pages, a model applied on top doesn't fix any of that. It produces a confident-sounding version of the same mess, faster.

We've written before about why AI-powered engineering tools tend to share one hidden dependency: a model is only as good as its ability to see the structural problems in what it's reading, and most tools skip straight to generating text without ever establishing what's actually there. Contradiction detection is a good example of why that matters. Hybrid approaches that pair rule-based logic with language understanding outperform AI alone, because the same obligation stated four ways, or a numeric limit that quietly contradicts a clause six sections later, isn't a language problem first. It's a structural one. A model can paraphrase it. It won't reliably find it without something built to look for that pattern specifically.

This also explains why identical technology produces such different results across organizations. Looking at why European OEMs need committees to make decisions that Chinese OEMs make alone, the gap wasn't AI capability or engineering talent. It was how much friction sat between a specification problem becoming visible and someone being allowed to act on it.

Sherlock, the engine behind WYZER Detective, was built around the same idea, applied to requirements instead of barcodes. A reviewer working through a large specification by hand is doing something close to scanning the same barcode five times: cross-checking one clause against hundreds of others, manually, because nothing holds the whole document in view at once. Sherlock's job is to remove that repeated pass first, before anyone decides where AI-generated summaries or rewrites belong on top of it. On a 288-requirement AUTOSAR specification, that kind of analysis surfaced 37 duplicate candidates, 12.8% of the document, without a single false conflict flagged on a clean section.

Two engineers in 1992 weren't trying to build a global standard. They were trying to stop a factory worker from scanning the same barcode five times. Everything that made it infrastructure came after that, starting with getting out of the way.