---
title: "The gap between what systems promise and what they actually do"
description: "Eileen Yoon, Ken Shirriff, a KV-cache reproducer, and a small app developer all found the same thing: the system does not do what its marketing says it does. The gap between advertised and actual behavior is this week's engineering risk."
canonical: "https://www.symbaiex.com/newsletter/daily-signal-2026-09-12"
last-updated: "2026-09-12T16:46:01.871Z"
---
# The gap between what systems promise and what they actually do

> Eileen Yoon, Ken Shirriff, a KV-cache reproducer, and a small app developer all found the same thing: the system does not do what its marketing says it does. The gap between advertised and actual behavior is this week's engineering risk.

Edition: daily-signal  
Run date: 2026-09-12

## Thesis
This week's most consequential engineering discoveries came from people who looked inside systems instead of accepting their marketing: a reverse-engineered Apple Neural Engine reveals the CNN-era assumptions that transformers broke; a disassembled Intel 8087 shows a 'simple' instruction hiding 140 micro-steps; a reproduction of KV-cache papers finds LRU harder to beat than the literature claims; and a bot farm exposes how easily ad measurement diverges from reality. The pattern is consistent — the metric being advertised is not the metric that matters — and the risk lives in the gap between the headline number and the workload you actually run.

Eileen Yoon finished what she started three years ago on Apple's Neural Engine. Ken Shirriff opened an Intel 8087 and found 140 micro-instructions hiding behind a 'simple' scale instruction. A developer reproducing KV-cache papers found LRU harder to beat than the literature claimed. And a small app developer discovered 60% of his Google Ads installs were robots. The common thread: the advertised behavior and the actual behavior diverge, and the people who inspect the internals are the ones who find the gap.

## Source briefing
### [Retrospectively Reverse-Engineering Apple's Neural Engine](https://eiln.github.io/posts/ane.html)

Eileen Yoon retrospectively reverse-engineered Apple's Neural Engine on the M1, mapping the full internal architecture — compute, datapath, scheduler, memory, and execution model — to reveal the assumptions Apple baked into silicon in 2017. The ANE was designed for dense CNN workloads with predictable reuse patterns; transformers, especially autoregressive decode, broke that assumption. The M5 folded ANE cores into GPU cores, and Yoon argues this is the beginning of the end for the standalone NPU. The practical consequence: when a vendor retires an accelerator, the workloads it was designed for may have already moved on, and the silicon's internal dataflow reveals what Apple was willing to commit to first.

**Why it matters:** Builders evaluating Apple silicon for ML workloads need to know the ANE was designed for 2017 CNN models, not today's transformers. The M5's 'LLM performance' headline runs on GPU cores, not the ANE. Yoon's reverse-engineering makes visible what Apple's marketing does not say: the accelerator you paid for may not accelerate your workload.

**Takeaways:**
- The ANE's compute core was a MAC array, but what specialized it was dataflow around the MACs, not the MACs themselves.
- Transformers broke the predictable reuse patterns the ANE exploited for dataflow efficiency on phones.
- Apple's M5 folding ANE into GPU cores confirms the standalone NPU's architectural assumptions no longer hold.
- Reverse-engineering the die reveals the workload assumptions a vendor committed to at silicon time.
### [Microcode in Intel's 8087 floating-point chip: the scale instruction](https://www.righto.com/2026/09/8087-microcode-reverse-engineering-fscale.html)

Ken Shirriff reverse-engineered the microcode behind Intel's 8087 FSCALE instruction and found it was not simple. The 'floating-point scale by a power of two' instruction uses over 140 micro-instructions and three levels of subroutine calls to handle special cases. The 8087's microcode ROM held 1648 instructions controlling the chip, and the FSCALE path reveals a hidden feature of the chip's exponent converter and shifter. The practical consequence: documentation calling an instruction 'simple' can hide substantial complexity, and that complexity is where bugs live.

**Why it matters:** The 8087's floating-point behavior is still the baseline for modern x86 FPUs. Shirriff's dissection shows that 'simple' instructions can carry hidden complexity that affects numerical stability in corner cases — and that the only way to know what a chip actually does is to look at the microcode, not the manual.

**Takeaways:**
- FSCALE uses 140+ micro-instructions and three subroutine calls for what documentation calls a single operation.
- The 8087's exponent converter and shifter contain a hidden feature exposed only through microcode inspection.
- The 8087 became the floating-point standard most computers still use today, so its corner cases matter.
- Reverse-engineering microcode reveals design decisions that official documentation omits.
### [LRU is harder to beat than the KV-cache papers suggest](https://github.com/gauravapiscean/agentic-kv-cache)

A developer reproduced agentic KV-cache policy claims on 68,266 requests from 393 real Claude Code sessions and 23,608 Mooncake requests through a prefix-cache simulator. LRU was harder to beat than the literature suggested. Under capacity pressure, most recomputation came from tool-calling loops seconds apart, not from sessions idling past a TTL — and the TTL never fired at all. Three attempts to beat LRU failed. The practical consequence: the academic argument that LRU is wrong for agentic workloads does not hold on real traces, and serving stacks should validate policies against their own traffic before switching defaults.

**Why it matters:** Cross-request KV prefix caching is the largest practical lever in agentic LLM serving — it is why a coding agent's fiftieth turn costs a fraction of its first. If the literature's recommended policies do not hold on real traces, serving stacks shipping those policies as defaults are optimizing for a metric that does not represent their actual workload.

**Takeaways:**
- LRU was harder to beat than KV-cache papers suggest when tested on real Claude Code traces.
- Under capacity pressure, waste comes from tool-calling loops seconds apart, not idle sessions past TTL.
- The 5-minute TTL never fired under capacity pressure in the reproduction.
- A harness bug made Belady lose to LRU, showing that even simulation results need validation.
### [I spent $220 on Google app ads and 60% of the installs were robots](https://dayzlegame.com/blog/google-ads-bot-farm/)

Dayzle, a small puzzle app, ran a Google Ads campaign at CA$40/day targeting installs. Google reported 21 installs in a day; the admin panel said 1. Twenty of the 21 were from a bot farm watching the shortest video, not clicking it, and installing from a cached APK instead of the Play Store. Over two weeks: 56 installs billed, 33 matching the bot pattern, 7 from untargeted countries, and 13 real people who finished 92 games between them. Google's algorithm optimized for the install goal, sending more ads to the farm, which installed more — a loop that guaranteed ad spend was wasted.

**Why it matters:** When the metric you optimize for is easy to game, the optimization itself becomes the attack surface. Dayzle's experience shows that install-count goals are already gamed, and the practical fix is to measure what actually matters — puzzle completions — not what the platform reports.

**Takeaways:**
- Google reported 21 installs; actual was 1 — 20 came from a bot farm using cached APKs.
- The bot farm watched the shortest video without clicking, then installed from a saved copy.
- Google's algorithm optimized for the install goal, creating a feedback loop that wasted more budget.
- Switching the campaign goal to 'won a puzzle' makes the app more expensive to farm.

## Practical moves
- Reproduce benchmarks on your own traces before adopting a new serving policy — the KV-cache LRU reproduction used 68k real Claude Code sessions and found the published claims did not hold.
- Set ad campaign goals to meaningful conversions, not top-of-funnel events — a bot farm watched a 1-second video and installed from a cached APK, gaming install-count metrics entirely.
- When a chip vendor folds an entire accelerator into another, check what architectural assumptions broke — Apple's ANE was designed for predictable CNN reuse patterns that transformers do not exhibit.
- Disassemble the 'simple' instruction before trusting the manual — the 8087 FSCALE used 140 micro-steps and three subroutine levels to do what documentation called a single operation.

## What to watch
- Whether Apple acknowledges the ANE architectural shift publicly or continues marketing M5 LLM performance without clarifying the ANE is not involved.
- Whether KV-cache literature adjusts for tool-calling loop patterns before shipping new eviction policies as defaults.
- Whether Google's invalid-traffic form produces actual remediation for bot-farm gaming of install metrics.
- Whether Intel's modern microcode still hides comparable complexity behind simplified instruction documentation.

**Methodology:** Belle selected and synthesized this edition from the indexed Hacker News source packet. Signal scores are editorial comparisons, not measurements. Direct source and discussion links are preserved for verification.

**Disclosure:** Belle uses AI to research and synthesize a bounded source packet; every edition is source-linked and subject to editorial review.