amlug

The vibe-coding disaster list is shorter than CrowdStrike alone

Tue, 28 Apr 2026 00:00:00 GMT

A number that stopped me.

Estimated Fortune 500 damage from CrowdStrike's July 2024 outage: $5.4 billion. Cause: a Windows kernel driver tried to read 21 input parameters from a struct that defined 20. Missing bounds check, missing test coverage. Pure human-written C++.

Estimated damage from every publicly named AI-generated-code production failure I could find, combined: a small fraction of that. Probably under a hundred million dollars across every documented case. Maybe much less. Most of the famous "vibe coding disasters" aren't actually about AI-generated code at all.

Sit with that for a moment. The narrative is "AI is breaking production." The numbers say humans broke production at a scale AI hasn't approached, do it constantly, and have for sixty years. That doesn't make AI fine. It means we've been pointing the conversation at the wrong thing.

What follows is a sort through three different failure modes that all get called "vibe coding broke production," and the human baseline nobody seems to check.

The setup

When someone says "vibe coding broke production," they could mean any of three things, and the press treats them interchangeably.

The first is AI-written code shipping with the code itself defective. The agent isn't running anymore; the artifact is. A function with a logic bug, a config with insecure defaults, a hallucinated package import that resolves to malware.

The second is an AI agent taking a destructive action at runtime. The "code" is mostly beside the point — what failed was the agent's decision, not the artifact it left behind. Drop a database, run terraform destroy, ignore a code freeze.

The third is a human shipping bad code they don't fully understand because an AI wrote it. The author was AI, the deployer was human, blame goes either way. This is the messy middle, and most of the empirical data sits here.

These need different defenses. SAST, code review, and dependency pinning catch the first. Sandboxing and permission scoping catch the second — keeping the agent out of the things you don't want deleted. The third is engineering culture, which either existed or didn't before AI showed up.

Most coverage conflates them, and the conflation leads to wrong fixes. "Replit's AI deleted Jason Lemkin's database" gets cited as evidence that AI-written code is dangerous. It's actually evidence that AI agents with database write privileges are dangerous, which is a much more obvious finding. The code Replit wrote that day wasn't the failure. The action it took was.

I went through the named cases in each category. Here's what's in the public record.

Failure mode 1: AI-written code broke in production

The list of publicly named cases where AI-generated code shipped, ran in production, and demonstrably caused a failure is short.

Amazon, March 2, 2026. Amazon Q (Amazon's internal AI coding assistant) was, per the company's own internal post-incident review, "one of the primary contributors" to a code change that miscalculated delivery times. Result: 1.6 million website errors, 120,000 lost orders. Amazon's internal memo cited "novel GenAI usage for which best practices and safeguards are not yet fully established" as a contributing factor. Three days later a separate incident took Amazon.com down for six hours and lost an estimated 6.3M orders. Same memo described both as part of "a trend of incidents" with "high blast radius."

Caveat though: Amazon publicly disputes the AI attribution. Their official statement points to "an engineering team user error" with broader impact than it should have had. The reference to "Gen-AI assisted changes" was reportedly deleted from the internal memo before the engineering meeting that the FT and CNBC reported on. So you have an internal Amazon assessment versus an external Amazon statement. Both sourced. The OECD AI Incidents Monitor has classified the March 2 incident as an AI Incident regardless. Even the strongest publicly-attributed case has a corporate dispute attached.

Lovable, CVE-2025-48757. AI-generated app code shipped for 170+ confirmed production apps, all missing Row Level Security on their Supabase backends. Researchers Matt Palmer and Kody Low scanned 1,645 apps showcased on Lovable's own marketplace; 170 of them leaked user data through identical RLS misconfigurations. A second researcher at Palantir reproduced the issue independently with 15 lines of Python and pulled debt balances, home addresses, and API keys in under an hour. CVSS 9.3. The code "worked" in the sense that it returned HTTP 200. It just returned everyone's data to anyone who asked.

Moltbook, January 2026. AI-generated frontend code with a Supabase API key embedded in client-side JavaScript and no Row Level Security. Founder Matt Schlicht: "I didn't write a single line of code for @moltbook." Wiz Research found the misconfiguration within minutes of the platform launching: 1.5 million API authentication tokens, 35,000 emails, and private agent messages exposed. Some of those messages contained third-party OpenAI API keys in plaintext, so the breach didn't stop at Moltbook. Meta acquired Moltbook two months later, so the founder did fine. The users' data was already mirrored on torrent sites.

Slopsquatting. AI assistants confidently suggest package names that don't exist. Attackers register the most-suggested ones with malicious payloads. The cleanest documented case: security researcher Bar Lanyado registered huggingface-cli after noticing LLMs kept hallucinating it. He uploaded nothing — no code, no README, no SEO — and the package got over 30,000 downloads in three months. A USENIX 2025 study found roughly 20% of AI-generated code samples reference nonexistent packages, and the hallucinated names are persistent across sessions, which makes them ideal squatting targets. Slopsquatting is the one genuinely new failure mode AI introduces. Humans don't typo the same fake name over and over across thousands of users.

That's the named tier. After that you get the anonymized cases — clearly real, but no company will put their name on them.

David Loker, VP of AI at CodeRabbit, has publicly described an AI-generated change at his own company that "would have taken down our database in production" if it had rolled out. Caught in review. A March 2026 Lightrun survey of engineering leaders at AT&T, Citi, Microsoft, Salesforce, and UnitedHealth Group found 43% of AI-generated code changes need debugging in production. Sonar's CEO Tariq Shaukat — formerly of Bumble and Google Cloud, so a credible source — has publicly said his team is "hearing more and more" about consistent outages at major financial institutions where developers attribute the failure to AI-generated code. No names. An AI-assisted trading system reportedly lost $78,947 in January 2026 due to a silent fallback issue. Anonymous.

Then the empirical layer. Doesn't name companies, but rigorous enough to be hard to dismiss.

CodeRabbit analyzed 470 GitHub PRs and found AI-generated code had 1.7× more bugs, 75% more logic errors, 8× more I/O issues, and 2× more concurrency mistakes than human-written code. Veracode's 2025 GenAI Code Security Report: 45% of AI-generated code samples failed basic security tests against the OWASP Top 10. Tenzai (December 2025) tested 15 apps across five major AI tools, found 69 vulnerabilities, and noted that every single app lacked CSRF protection, every tool introduced SSRF vulnerabilities, and zero apps set security headers. Escape.tech scanned 5,600 vibe-coded apps live in production and found 2,000+ vulnerabilities, 400+ exposed secrets, and 175 instances of exposed personal data.

The empirical layer says "AI code is shipping with defects to production constantly." The named-case layer is suspiciously small relative to that. Companies are eating these failures privately. Amazon is the only Fortune 500 company that has publicly had its name attached to one, and Amazon spent the press cycle disputing the attribution.

Failure mode 2: AI agents took destructive actions at runtime

This is the column most "vibe coding disaster" articles cite. None of it tells you whether AI-written code is safe to ship. It tells you that AI agents with destructive privileges are dangerous, which is a different question.

Replit's AI deletes SaaStr's production database, July 2025. Jason Lemkin, founder of SaaStr, was nine days into building a project on Replit when the agent ran destructive commands during an explicit code freeze. Wiped records on 1,206 executives and 1,196 companies. The agent then admitted to "a catastrophic error in judgement" and falsely told Lemkin the rollback wouldn't work — it did. Replit's CEO publicly acknowledged the incident and rolled out automatic dev/prod database separation as a fix. The deletion got the headlines. The interesting part was what came after: the agent fabricated 4,000 fake user records to cover the deletion, and lied about its own rollback capability when asked. Both behaviors, not code.

Amazon Kiro deletes AWS Cost Explorer environment, December 2025. Kiro decided that the cleanest path forward to fix a permissions issue was to delete and recreate the environment from scratch. 13-hour outage in the mainland China region. A senior AWS employee told the FT it was "small but entirely foreseeable." Amazon disputes the AI framing here too.

Claude Code runs terraform destroy on DataTalks.Club. Wiped 2.5 years of production data, ~1.94 million rows, 100K+ students affected.

Orchids zero-click hack on a BBC reporter, February 2026. Researcher Etizaz Mohsin used a vulnerability in the Orchids platform to insert one line of code into BBC tech correspondent Joe Tidy's project and gain full remote control of his laptop. Zero clicks, zero downloads. This one is technically a hybrid — the platform vulnerability enabled the agent's privileges to be exploited — but it gets reported as an AI failure.

These are real, well-sourced failures. Structurally, they're the same failure mode as a system administrator running rm -rf / on the wrong server. The only novel piece is that the entity at the keyboard is now an LLM. The fact that someone with destructive privileges can do destructive things has been the foundation of every Unix admin nightmare since 1971.

The human baseline nobody checks

This is the piece missing from most "AI broke production" coverage, and it's the bulk of what's actually going on.

The Consortium for Information & Software Quality estimated the cost of poor software quality in the US alone at $2.41 trillion per year in 2022. Operational failures, technical debt, cybersecurity damage, project failures. The human-written-code baseline that AI code is being measured against. The baseline is already brutal.

The named cases are everywhere. A short list of famous human-written code that broke production catastrophically.

CrowdStrike, July 19, 2024. The largest IT outage in history. 8.5 million Windows machines crashed simultaneously. $5.4 billion in estimated Fortune 500 damages alone, before counting smaller businesses, healthcare disruption, or the airlines that grounded thousands of flights. Cause per CrowdStrike's own root cause analysis: a kernel driver tried to read 21 input parameters from a struct that defined 20. Missing bounds check in C++ code. Missing test coverage for the input validation. Delta is suing for $500 million. Class action lawsuits are pending. Pure human-written code, signed off by a human review process at a $90B cybersecurity company.

Knight Capital, August 1, 2012. $440 million lost in 45 minutes. Bankrupted the company. An engineer deployed updated trading code to seven of eight servers. The eighth still ran a deprecated 2003 feature called "Power Peg." A repurposed flag bit reactivated the dead code. Within 45 minutes, four million erroneous orders had hit the market across 154 stocks worth $7.65B in positions. No deployment validation, no peer review, no circuit breakers, no automated rollback. Knight got bailed out and absorbed.

AWS S3, February 28, 2017. Half the internet went dark for four hours from one typo. An AWS engineer was running an established playbook to remove a small set of S3 billing servers. He typo'd a parameter. The command removed too many servers, including ones running the index and placement subsystems. Cascading failure. Slack, Trello, Quora, Medium, Docker, IFTTT, and AWS's own status dashboard all went down. Cyence estimated S&P 500 companies lost $150M during the outage alone.

GitLab, January 31, 2017. An engineer ran rm -rf on the production database server instead of the secondary replica. Lost six hours of data, affected 5,000 projects, 700 user accounts. Then discovered five backup mechanisms had all failed silently — none had been tested in production. The only working backup was a manual one taken six hours earlier. Same shape as the Replit/SaaStr incident. The only thing that changed was the entity at the keyboard.

Therac-25, 1985–1987. Killed at least three patients with massive radiation overdoses. Race condition in human-written code: if the operator typed a prescription too quickly, the machine could fire its high-power electron beam without the proper shielding in place. Software replaced hardware safety interlocks present in earlier models. Now a canonical case study in how human-written safety-critical code can kill people.

Boeing 737 MAX MCAS, 2018–2019. 346 deaths across two crashes. Software design flaw: MCAS could repeatedly trigger nose-down trim from a single Angle-of-Attack sensor, with no failure handling, and pilots were never told the system existed. Human-written, human-reviewed, signed off by humans, killed hundreds of humans.

Ariane 5 Flight 501, 1996. Rocket exploded 40 seconds after launch. ~$370 million lost. A 64-bit floating-point velocity got converted to a 16-bit signed integer. Overflow. Self-destruct. The code was reused from Ariane 4 without re-validation against Ariane 5's flight envelope.

Northeast blackout, August 14, 2003. 55 million people lost power across 8 US states and Ontario. ~100 deaths attributed to the blackout. General Electric's XA/21 energy management system had a race condition that prevented operators from receiving alarm notifications about cascading line trips.

TSB Bank IT migration, April 2018. 1.9 million customers locked out of their accounts. Some saw other customers' balances. CEO resigned. Estimated cost: £330 million.

Healthcare.gov, October 2013. The most expensive failed website launch in US history. ~$2.1 billion total cost. On launch day, six people successfully enrolled. The system collapsed under 50,000 concurrent users when designed for far more.

This isn't an exhaustive list. It's just the big ones. The empirical baseline behind them, per Steve McConnell's Code Complete: 15–50 bugs per 1,000 lines of human-written code as the industry average. 1–5 bugs per kLOC even in released, post-test software. 0.5 bugs per kLOC for Microsoft's released products with their full review process. 0.1 bugs per kLOC for the NASA Space Shuttle, the gold standard, achieved at thousands of dollars per line of code.

When CodeRabbit reports AI-generated code has 1.7× more bugs than human-written code, the comparison is to a baseline of 15–50 bugs per kLOC. That gets us to maybe 25–85 bugs per kLOC for AI code. Both numbers are alarming. The human baseline is already a managed disaster — code review, CI, staged rollouts, postmortems, runbook discipline are the entire reason any of this works at all. Without that process, the baseline would be much worse than it already is.

Where the comparison actually lands

Put the failure modes side by side. For every AI-code failure pattern in failure mode 1, there's a famous human-coded equivalent that predates AI by a decade or more.

AI-code failure	Human-coded equivalent
Lovable apps shipped without Row Level Security	Tea app shipped with an open Firebase bucket. Uber's "God View" gave employees access to everyone's location. Uncountable S3 buckets left publicly readable.
Moltbook hardcoded its Supabase key in client JavaScript	Decades of secrets-committed-to-git incidents. The entire reason GitGuardian exists as a company.
Slopsquatting: AI hallucinates a package name, attacker registers it	Typosquatting: a human typos `react-router` and installs malware. Same attack class, different cause of the typo. This is the closest equivalent and it isn't quite the same.
Amazon Q generated a logic error in delivery time calculation	Knight Capital reused a flag bit that reactivated dead code. AWS S3 engineer typo'd a command parameter.
AI-generated `Promise.all` over an array storms the connection pool	Every concurrency bug humans have made since threading existed. Therac-25, Northeast blackout, Mars Pathfinder.
AI agent runs `DROP TABLE` or `terraform destroy`	GitLab engineer ran `rm -rf` on the wrong server. AWS S3 engineer wiped too many servers with one keystroke.
AI hallucinates security defaults	Therac-25 was designed without proper interlocks. CrowdStrike shipped without bounds checking.

The point isn't that humans are bad too, so AI is fine. The point is that bad code failing in production is the default state of software. AI is a new author of that bad code. The bad-code-fails-in-prod problem predates it by sixty years and costs $2.4 trillion a year.

Where the comparison breaks the AI case

Two things don't survive the comparison cleanly.

The first is velocity. Human-written code happens at human speed. AI is faster — by a lot. CodeRabbit's 1.7× bug rate combined with a plausibly 5–10× code-volume increase per developer means absolute bug volume per developer is up an order of magnitude, even at constant per-line quality. The review process that worked at the old volume doesn't necessarily scale to the new one. Lightrun's 43%-need-debugging stat is consistent with this. Amazon's response to its March outages was to mandate senior engineer sign-off on AI-assisted code — a velocity-control measure, not a code-quality measure.

The second is slopsquatting. Typosquatting and dependency confusion existed before AI. But "the AI consistently hallucinates the same plausible-but-fake package name across many users, creating a deterministic attack surface for whoever registers it first" is a category that didn't exist when humans were typing every import statement. The attack relies on the predictability of LLM hallucinations, which has no human analog.

Everything else on the AI side has a structural human equivalent. Slopsquatting is the one place the comparison genuinely breaks toward "AI introduces a novel risk." The rest is cause-of-failure, not type-of-failure.

The meta-point

Most of the press coverage of "AI is breaking production" conflates the three failure modes from the setup, and the conflation matters.

AI-written code that ships with bugs is real, and probably happening at scale below the public attribution threshold. The defenses are old: review, test, scan, pin dependencies, ship secure-by-default templates.

AI agents with destructive privileges are dangerous in a way that has nothing to do with the code they author. The defenses are also old: scope permissions, sandbox, require approval for destructive operations, log everything. The Replit incident is structurally identical to a junior sysadmin running rm -rf in the wrong directory, which the industry has been defending against since the 1970s.

The human-written-code baseline is already catastrophic. CrowdStrike alone caused more economic damage in one weekend than every named AI-code production failure combined. Knight Capital lost more money in 45 minutes than the visible cost of every documented vibe-coding incident put together. The reason these incidents don't dominate the news cycle anymore is that we've gotten used to them.

So the defensible conclusion isn't "AI code is fine." It also isn't "AI code is dangerous." It's smaller: the failure mode is the same. The question is whether your review and rollout discipline keeps pace with whatever, or whoever, is now generating your code 5× faster. That's a question about engineering culture. It happens to be the same question we've been answering badly for sixty years.

Engineering cultures that already handle bugs well — review, CI, staged rollouts, blameless postmortems — handle AI bugs about the same. There are just more bugs per developer per hour. Cultures that don't handle bugs well find out faster. Adding AI to an environment with no CI and no review process was always going to surface the missing CI and review process. AI didn't create that gap. It declined to paper over it.

The accurate version of "vibe coding broke production" is something like: your existing review process broke under increased code velocity, and the velocity increase happened to be from AI. Less marketable. Closer to true.

Closing

Anyone using AI-code failures as evidence that AI shouldn't write code is, by extension, arguing humans should stop writing code too. The CrowdStrike kernel driver, the Knight Capital deployment, the AWS typo, the GitLab rm -rf, the Therac-25 race condition, the 737 MAX MCAS — these are all cases where humans wrote code with the same failure modes AI gets blamed for, with vastly higher body counts and dollar costs, across decades of evidence.

I work on a TypeScript-to-native compiler that is mostly written by Claude Code under my direction. I review the architecture and the diffs; the agents do most of the typing. The thing I'm defending against is failure mode 1: AI-written code that compiles, passes tests, ships, and turns out to have a logic error in production. I review what comes back the same way I'd review human code — maybe more carefully, because the volume is higher. That's the only real adjustment.

The question worth asking isn't whether AI code is safe to ship. It's whether your engineering culture is honest enough to catch anyone's bad code before it reaches users. If yes, AI is mostly a speedup. If not, you'll find out at scale.

Sources for the named incidents: CrowdStrike's own root cause analysis (PDF on their site), the SEC 8-K filing on Knight Capital, AWS's official postmortem on the S3 outage at aws.amazon.com/message/41926, GitLab's published postmortem, the OECD AI Incidents Monitor for the Amazon March 2026 incident, the NIST NVD entry for CVE-2025-48757, Wiz Research's disclosure on Moltbook, and Bar Lanyado's writeup of the huggingface-cli experiment. The CISQ "Cost of Poor Software Quality in the US: A 2022 Report" is the source for the $2.41 trillion figure. CodeRabbit's State of AI vs Human Code Generation Report, Veracode's 2025 GenAI Code Security Report, the Lightrun engineering survey, and the Tenzai assessment are the sources for the empirical comparison data.

Your default compiler flags are leaving 8× on the table

Wed, 15 Apr 2026 00:00:00 GMT

Here is a number that stopped me.

I ran a tight loop on an Apple M1 Max. One hundred million iterations, adding 1.0 to a double each time. The program was compiled and run in eight languages. The timings, in milliseconds, best of five runs:

Language	loop_overhead
Rust (`rustc -O`)	99
C++ (`g++ -O3`)	98
Java (OpenJDK 21, JIT)	98
Swift (`swiftc -O`)	97
Go (`go build`)	97
Node.js 25 (V8)	53
Bun 1.3.5 (JavaScriptCore)	40
Compiled TypeScript (Perry, LLVM)	12

Sit with the top five for a moment. Five different compilers, five different language designs, two decades apart in age. They agree on this loop to within 2%. That alone is worth noticing — the conventional wisdom that picking C++ over Go buys you raw throughput is, on this benchmark, just not visible.

And then the bottom row. Twelve. An order of magnitude better than the five "fast" languages — built, of all things, by compiling TypeScript.

This isn't a story about TypeScript being fast. It's a story about why the five compiled languages are identical to each other, and why their shared default output is eight times slower than it has to be.

The setup

The compiled-TypeScript entry is Perry, an ahead-of-time compiler I work on. It parses TS with SWC and generates native code through LLVM, the same backend clang and rustc use. For this article Perry is a measuring instrument — a way to isolate one specific thing: LLVM's optimizer, when you hand it identical IR but with different flags.

The benchmark is a ported set of eight compute microbenchmarks, one of which is the loop above. Full source and raw numbers are in the polyglot benchmark suite. I ran every benchmark in every language at the flags its documentation recommends for release builds — nothing extra, nothing turned off. Best of five; best of twenty on the one benchmark (fibonacci) sensitive to branch-predictor state.

These are compute microbenchmarks. Before we continue: do not generalize them to "language X is 8× slower than language Y on real workloads." On a realistic application — one that spends its time in I/O, allocation, a scheduler, a database driver — the programming-language choice drops to the noise floor. What these numbers probe is narrow: the compiler's output on numeric loops with double / f64 arithmetic. That narrow probe, it turns out, is where the defaults get interesting.

Three specific optimization choices account for every case where the compiled-TypeScript column looks strange. I'll walk through each with the LLVM IR to back the claim.

Optimization 1: IEEE 754 strict addition is really slow

The 99 ms Rust number is not laziness, and it's not because Rust is worse than C. Here is what clang emits from a vanilla -O3 build of the same C++ loop:

; clang -O3 bench.cpp -S -emit-llvm, inside bench_loop_overhead:
2:                                    ; preds = %2, %0
  %3 = phi i32    [ 0,           %0 ], [ %9, %2 ]
  %4 = phi double [ 0.000000e+00, %0 ], [ %8, %2 ]
  %5 = fadd double %4, 1.000000e+00    ; serialized
  %6 = fadd double %5, 1.000000e+00    ; waits for %5
  %7 = fadd double %6, 1.000000e+00    ; waits for %6
  %8 = fadd double %7, 1.000000e+00    ; waits for %7
  %9 = add nuw i32 %3, 4
  %10 = icmp eq i32 %9, 100000000
  br i1 %10, label %11, label %2

clang unrolled the loop four times — four fadds in the body, counter incrementing by 4. But look at the data dependencies: each fadd takes the result of the previous fadd as its input. %6 cannot start until %5 finishes. %7 has to wait on %6. Every instruction in the body sits in a serial latency chain.

On an M1 Max a single fadd takes about 3 cycles. Four serialized fadds per loop body × 3 cycles each = 12 cycles per iteration. With the 4× unrolling, 100M iterations becomes 25M loop bodies. 25M × 12 cycles = 300M cycles. At 3.2 GHz that's 94 ms. Measured: 98 ms. Close enough.

clang cannot collapse this chain. Not because it doesn't see the pattern — it obviously does — but because IEEE 754 forbids the transformation. Floating-point addition is not associative. For arbitrary inputs, (a + b) + c can differ from a + (b + c), because a large intermediate in one order rounds away bits that would have survived in the other. Programs that care about that — numerical simulations, interval arithmetic, reproducibility guarantees — need the result. The compiler must preserve it.

Now the same function with one flag added:

; clang -O3 -ffast-math bench.cpp:
2:                                    ; preds = %2, %0
  %3 = phi i32        [ 0, %0 ],              [ %6, %2 ]
  %4 = phi <2 x double> [ zeroinitializer, %0 ], [ %5, %2 ]
  %5 = fadd fast <2 x double> %4, splat (double 4.000000e+00)
  %6 = add nuw i32 %3, 8
  %7 = icmp eq i32 %6, 100000000
  br i1 %7, label %8, label %2

One fadd fast <2 x double> per iteration. Two parallel lanes, each adding 4.0 (because LLVM folded ((x+1)+1)+1)+1 into x+4). Eight additions per iteration, one vector instruction. No dependency between iterations except the accumulator itself.

LLVM needed fast to permit the rewrite — the fast flag is a bundle that includes reassoc ("may reorder"), contract ("may fuse mul+add into fma"), and four more properties about NaN, infinity, signed zero, and reciprocal arithmetic. Turning it on says "I don't care about strict IEEE 754 anywhere in this compilation unit." clang's measured result with the flag: 12 ms. Eight times faster than the default.

Perry's generated IR for the same function carries reassoc contract on every float instruction by default — a subset of fast that permits reordering and fma contraction but preserves NaN, Inf, and -0.0 semantics (which JS programs can observe). After LLVM's standard optimization pipeline runs on Perry's naïve load/fadd/store IR, it becomes:

vector.body:
  %vec.phi   = phi <2 x double> [...], [ %0, %vector.body ]
  %vec.phi14 = phi <2 x double> [...], [ %1, %vector.body ]
  %0 = fadd reassoc contract <2 x double> %vec.phi,   splat (double 1.0)
  %1 = fadd reassoc contract <2 x double> %vec.phi14, splat (double 1.0)
  %index.next = add nuw i32 %index, 4

Two parallel <2 x double> accumulators instead of clang-fast's one — LLVM's interleave pass picked a different unroll factor here, but the result is structurally identical: parallel fadd lanes, no serial chain. Final disassembly shows Perry's binary running four independent fadd.2d NEON instructions per loop iteration, consuming the two FP issue pipes M1 has available. Measured: 12 ms, the same number C++ gets with -ffast-math, by a different route.

Two things follow.

First: the thing Rust and C++ lost by default was never compiler quality. It was one bit of metadata on every fadd instruction. Perry turns that bit on in its emitter. clang turns it on when you pass -ffast-math. Both end up at the same 12 ms because both are routing through the same LLVM optimizer. LLVM is doing the work. The languages differ only in whether they hand LLVM the permission slip.

Second: Go cannot participate. Go's compiler has no -ffast-math, no reassoc flag, and its backend does not ship a floating-point reassociation pass. Writing the same loop in Go and building with go build — with any flags, any compiler version — produces something indistinguishable from clang's default 97 ms. This is intentional: Go's design prioritizes predictable compiler output over absolute throughput. It's also the cleanest instance in this whole investigation of "the default is the ceiling."

For Rust, the situation is halfway. Stable Rust has no flag to toggle reassoc on individual fadd instructions. Nightly exposes std::intrinsics::fadd_fast, which takes the same loop from 99 ms to 12 ms — matching clang-fast. Manual 4-way unrolling in stable Rust reaches 24 ms, good but not great. On this benchmark, "use nightly" is a real answer if you need parity.

Optimization 2: the benchmark that fooled me

Here is accumulate: loop 100 million times, do sum += i % 1000 on double values, report the elapsed time. My prior belief going in was straightforward: on ARM64 there is no hardware instruction for fmod on f64. The default C++ benchmark uses double, so the modulo lowers to a libm function call — roughly 30 ns per call, 30 ns × 100M iterations = three full seconds theoretical, something under a second in practice once clang vectorizes around the call. Perry's type inference recognizes the operands are integer-valued and emits srem — one hardware instruction, one cycle — which is why Perry reports 24 ms while the other languages sit at 96–99 ms.

That story is wrong in an interesting way.

Here is what clang actually emits, with default flags, for the C++ version of accumulate:

%9  = urem <4 x i32> %5, splat (i32 1000)
%10 = urem <4 x i32> %6, splat (i32 1000)
%11 = urem <4 x i32> %7, splat (i32 1000)
%12 = urem <4 x i32> %8, splat (i32 1000)
%13 = uitofp nneg <4 x i32> %9  to <4 x double>
; ... uitofp for the other three lanes ...
%17 = tail call double @llvm.vector.reduce.fadd.v4f64(double %4,  <4 x double> %13)
%18 = tail call double @llvm.vector.reduce.fadd.v4f64(double %17, <4 x double> %14)
%19 = tail call double @llvm.vector.reduce.fadd.v4f64(double %18, <4 x double> %15)
%20 = tail call double @llvm.vector.reduce.fadd.v4f64(double %19, <4 x double> %16)

Because i is declared int in bench.cpp, clang was free to lower i % 1000 to vectorized integer remainder — urem <4 x i32>. No fmod anywhere. The C++ benchmark isn't paying the libm tax I assumed it was.

So what is the 97 ms? Look at the bottom: four llvm.vector.reduce.fadd calls, chained, each feeding the next. Without reassoc, a vector.reduce.fadd.v4f64 must happen in a specific order — it's semantically a serial chain of three fadds inside. Four of those chained per iteration is twelve serial fadds. That's the bottleneck.

Perry, on the same benchmark, compiles down to:

vector.body:
  %1 = urem i64 %index, 1000
  %2 = urem i64 %0, 1000
  %3 = uitofp nneg i64 %1 to double
  %4 = uitofp nneg i64 %2 to double
  %5 = fadd reassoc contract double %vec.phi,   %3
  %6 = fadd reassoc contract double %vec.phi15, %4
  %index.next = add nuw i64 %index, 2

Two parallel scalar accumulators. Two urems, two uitofps, two fadds, no reductions. The urem was always going to be there — both compilers found the integer remainder. The difference is that Perry's reassoc flag let LLVM hoist the accumulate out into parallel lanes instead of a vector-reduce chain.

The original story I told about Perry vs C++ on this benchmark — that it's the fmod libm call versus an srem hardware instruction — turns out to be a story about Perry vs naïvely-compiled TypeScript. Perry does have an integer-mod fast path, and it's a real optimization: if a future TypeScript compiler on this benchmark emitted frem double, it would sit around 600 ms (Node's number: 602 ms, which is exactly this — V8 didn't inline the fmod call). The fast path matters against that reference point.

But against clang -O3 on the same algorithm, the fast path isn't what's making the difference. It's the reassociation flag, again.

C++ with -O3 -ffast-math on accumulate clocks at 26 ms. Virtually identical to Perry's 24 ms. Rust with its stable-toolchain opt variant (switch the accumulator to i64 so the benchmark stays in integer domain) gets to 41 ms — the integer change helps, but the reduce-chain cost for stable Rust's fadd structure isn't reachable at 24 ms without full fast FMF, which stable Rust doesn't expose. Nightly Rust's fadd_fast doesn't help on this benchmark either, because the bottleneck here is the reduce-chain shape, not individual fadd permissions.

Go with its opt variant (int64 accumulator) goes from 99 ms to 70 ms, the biggest improvement any Go benchmark saw in the opt sweep. The delta came entirely from avoiding the uitofp per iteration, not from vectorizing the remainder. Go's compiler emitted one iteration per loop pass, scalar SMULH + MSUB for the modulo, scalar integer add. No vectorization. 70 ms is what you get when nothing auto-parallelizes the accumulator.

Optimization 3: it's reassoc all the way down

The third optimization the plan called for was bounds-check elimination and i32 loop counter promotion on the array_read benchmark — sum 10 million doubles from an array. Perry's codegen detects the classic for (let i = 0; i < arr.length; i++) pattern, caches arr.length at loop entry, maintains a parallel i32 counter alongside the f64 one, and skips the JS runtime bounds check. Measured: 3 ms.

The prediction was that the other languages would be meaningfully slower on the default benchmarks and would snap close to 3 ms when given the right idiom: Rust's .iter().sum(), Swift's withUnsafeBufferPointer, C++'s already-no-bounds std::vector.

Here's what actually happened:

Language	default	opt	delta
C++	9	1	-89%
Rust	10	9	-10%
Go	10	11	0
Swift	9	9	0

Only C++ moved materially. And C++ moved because of -ffast-math (again), not bounds-elim — there are no C++ bounds to eliminate. With fast on, LLVM interleaves the array-sum reduction four lanes wide (four parallel <2 x double> accumulators, 8 f64 per load, 4 × 8 = 32-wide unroll) and gets to 1 ms. That's faster than Perry's 3 ms.

Rust's .iter().sum() vs the indexed for i in 0..arr.len() form gave about one millisecond — within run-to-run noise. rustc at -O already proves i < arr.len() for that classic loop shape and strips the bounds check as dead code. There was nothing to eliminate.

Swift's UnsafeBufferPointer produced an identical 9 ms. The safe indexed form was already efficient.

So the third "Perry optimization" I set out to document turns out to be real in Perry's source — the code in stmt.rs does track i32 counter promotion and bounded_index_pairs — but it isn't load-bearing on this benchmark. The loop vectorizer's interleave factor is what separates 9 ms from 1 ms. That's an LLVM heuristic, not a bounds thing.

The honest takeaway is smaller than the plan suggested: bounds-check elimination is mostly already happening, at least in Rust and C++, for the straight-line loops these benchmarks exercise. What isn't already happening is aggressive vectorization under strict IEEE 754, which is the same optimization we discussed in section 1.

Where the compiled-TypeScript side loses

Two benchmarks where Perry loses cleanly. They matter to the argument — if the thesis were just "TypeScript is faster," they'd be awkward. Since the thesis is "defaults matter," they're consistent with it.

object_create: 0 ms (Rust, C++, Go, Swift) vs 2 ms (Perry). The benchmark allocates a million Point{x, y} structs, sums fields, and reports the time. In statically typed compiled languages, the optimizer stack-allocates the struct, inlines the constructor, proves the struct never escapes the loop, and eliminates the whole thing as dead code. The measured result is zero because the work is zero. Perry cannot match this without abandoning its dynamic value model. A recent Perry pass (v0.5.17) does scalar-replacement for objects whose only uses are field get/set, which is why Perry measures 2 ms and not 10 — but any method call on the object defeats it. This is the shape of workload where ahead-of-time compiling a dynamic language pays a real tax against languages with static types, and no amount of flag-tuning closes the gap.

nested_loops: Perry 9 ms vs C++ opt 1 ms. Same story as array_read, same cause: -ffast-math enables a more aggressive interleave factor than Perry's reassoc contract subset does. Perry's 3 ms on array_read and 9 ms on nested_loops are both beaten by C++ opt, because fast includes nnan and ninf permissions that the loop vectorizer uses to pick a higher unroll. Perry deliberately does not emit those, because JavaScript programs can observe NaN and infinity and it would break Math.max(-0, 0) === -0. That's a real correctness tradeoff — the ceiling Perry could hit if it stopped caring about NaN/Inf semantics is several milliseconds faster on flat-array sums. Right now it doesn't hit it.

An aside: where JIT beats AOT

fibonacci: Java 280 ms vs Perry 311 ms. Recursive fib(40) runs about two billion real calls. Java's C2 JIT observes the recursion at runtime and applies aggressive inlining based on actual hot-call frequencies — something no AOT compiler can match without whole-program profile data. Perry, C++, and Rust all cluster at ~310–319 ms through LLVM; Swift at 360 ms and Go at 450 ms lose at the recursion-folding stage inside their own backends. This benchmark is essentially a compiler-pass quality test, not a flag-tuning target. No flag changes any of these numbers materially.

The meta-point

Rust, C++, Go, and Swift picked conservative defaults for a reason. Their users care about reproducibility, IEEE 754 correctness, and about not having to audit every numeric operation for the possibility the compiler silently reassociated it. A 3D renderer that reads back the same color from two parallel paths, a simulation that needs bit-exact replay for debugging, a financial calculation that must be verifiably deterministic — all of these care, and they'd be angry if (a + b) + c != a + (b + c). The languages' compile defaults reflect that population.

Compiling TypeScript for a JavaScript audience is a different tradeoff. JS programs mostly don't treat -0.0 distinctly from 0.0 even when they could. Most TS code that hits a numeric loop is a game tick, a compiler pass, a canvas renderer — workloads where a bit of reassociation is fine. So Perry turns reassoc on by default. It isn't braver or smarter than Rust; it serves a different population.

What's interesting isn't that Perry made the call. It's that the call is invisible in most comparisons. The numbers people see when they benchmark "Rust vs TypeScript" or "C++ vs JavaScript" reflect the defaults both sides picked, with no indication that one side spent those defaults on numerical robustness and the other spent them on throughput. The benchmarks look like they're comparing languages. They are actually comparing flag choices.

There's no meta-rule for which default is right. "Enable reassoc by default" is good for numeric loops and bad for scientific simulations. "Strict IEEE by default" is the opposite. Both are defensible. What isn't defensible is concluding from benchmark tables alone that one language is faster than another. The defaults are the experiment.

Closing

Every claim in this post is reproducible with the code at the link below. The four bench_opt files showed that the "Perry wins" column closes to within noise on all three flag-sensitive benchmarks when the other languages are given the equivalent optimization path — except on Go, where the path doesn't exist. None of this required anything exotic. -ffast-math is a flag you can type today. Nightly Rust's fadd_fast intrinsic is #![feature(core_intrinsics)] plus one use statement. Whether either should be your default is a judgment call about what you're building.

Perry exists because some of us wanted to compile TypeScript to something that isn't a JavaScript engine. It uses LLVM. You've seen other LLVM-based compilers in this post: clang, rustc, swiftc. They all produce similar output when you ask them for similar things. The experiment this article documented is what they do when you don't.

Reproduction

git clone https://github.com/ralphkuepper/perry
cd perry/benchmarks/polyglot
cargo build --release --manifest-path=../../Cargo.toml -p perry
bash run_all.sh 5          # default-flags numbers — produces RESULTS.md
bash run_opt.sh 5 20       # opt variants — produces RESULTS_OPT.md

Hardware used for the numbers in this post: Apple M1 Max (10 cores), 64 GB RAM, macOS 26.4. Perry commit e1cbd37 (v0.5.22). rustc 1.92.0 stable, 1.97.0-nightly 2026-04-14, Apple clang 21.0, Swift 6.3, Go 1.21.3, Node 25.8, Bun 1.3.5, Python 3.14.

All LLVM IR snippets in this article are in assets/ as full .ll files, reproducible with clang -S -emit-llvm (C++), rustc -O --emit=llvm-ir (Rust), and PERRY_SAVE_LL=<dir> perry compile (Perry). The accompanying METHODOLOGY.md in that directory has the exact iteration counts, clocks, and timing methodology.

On publishing slowly

Wed, 15 Apr 2026 00:00:00 GMT

I have a drafts folder full of technical writing that never shipped. Some of it was too half-formed to post; most of it was fine, but I kept pushing it to "after I run one more benchmark," and after enough rounds of that, the piece stops feeling urgent to anyone, myself included.

This site is an attempt to fix the second failure mode without giving in to the first. The plan is narrow: four to eight posts a year, each one about something I actually had to work out, and nothing in between. No weekly cadence, no "thinking out loud" threads, no TIL dumps. If I have a half-formed thought worth sharing, a Mastodon post is the right shape for it, not a page on a domain with my name on it.

What goes here

Most of what I'll write about lives near compilers and systems. I spend my days on Perry, a TypeScript-to-native compiler, and the questions I get stuck on tend to be the kind that take a week of measurement to answer honestly. Things like: what does for...of actually cost in a lowered IR, where is the line between "clever abstraction" and "extra two memory loads per iteration," and when is the answer to a performance question "the benchmark was wrong."

Before Perry I spent years on Swift server-side work and contributed to Vapor; some of that will show up here too, when I have something to add that isn't already in the docs.

What does not

No company updates. No product announcements. No "10 things I learned this year." If you're looking for Skelpo news or Perry release notes, those live on their own sites and will stay there.

The first real post

There's a benchmark investigation in the queue — a longer piece on the cost of abstraction in the Perry front-end, with enough numbers attached that I'd rather over-verify before publishing than push it and have to correct it in public. That article is the reason this site exists now instead of in six months.

Until then, this is the note on the door.