On March 16, 2026, Triton, the GPU compiler, received a PR whose title promised to fix random crashes (“segfaults”) on consumer Blackwell cards: the RTX 5070 Ti, 5080, and 5090. It had a full description and tests. An automated review bot left comments, a maintainer asked for changes, and the author made them. Approved the same day. Merged the same day.

The next day, a reviewer left a polite comment under the PR: this PR is probably incorrect, the description is inaccurate, and the premise the entire fix depends on is itself wrong.

That same day, the maintainer reverted it with a one-line explanation: “Based on Nvidia’s feedback this doesn’t seem to be a correct PR.” From merge to revert: roughly one day.

The PR’s commit carried Co-Authored-By: Claude Opus 4.6. It was the work of an AI coding agent. But the interesting part of this story isn’t that an AI got something wrong. It’s that every stage of review had a human present who genuinely caught real problems, and the single most damaging error still walked straight into main.

SemiAnalysis’s caption is harsher than the comment itself

The reason anyone noticed is that SemiAnalysis posted an all-caps “AI CODING SLOP ALERT” on X. Their warning: in open-source projects, it’s getting harder and harder to tell AI-agent garbage apart from valuable diffs. They then pointed to Triton PR #9734, saying it claimed to fix consumer Blackwell (which has no TMEM, or tensor memory), but on closer inspection didn’t fix anything at all. After the merge, they said, NVIDIA’s PyTorch tech lead commented “in a very PROFESSIONAL way” that the PR was complete slop.

That all-caps “PROFESSIONAL” is SemiAnalysis being sarcastic. The comment on the PR page is a courteous, purely technical explanation. “Slop” is the caption SemiAnalysis added on top. And the claim that the commenter is NVIDIA’s PyTorch tech lead comes from SemiAnalysis; the PR page itself doesn’t list anyone’s affiliation.

The tweet also went out of its way to mention that this tech lead owns a “2024 Honda Civic Sport Edition.” This tells you nothing about whether the PR was right, and the tweet never explains why it’s there. Mogu has decided to respect SemiAnalysis’s creative freedom and not invent a reason for it ┐⁠(⁠￣⁠ヘ⁠￣⁠)⁠┌

Mogu chimes in:

I have some issues with SemiAnalysis’s headline. “Slop” is a great word for retweets, but it carries zero information: calling a PR garbage doesn’t tell anyone what’s wrong with it. What actually got Triton to revert within a day was the comment they mocked as “very PROFESSIONAL.” It spelled out which premise was wrong, cited CUTLASS and PyTorch as evidence, and attached the compile error. The irony is that the most effective weapon against mass-produced, low-information AI PRs turned out to be a high-information human comment that didn’t take a single jab at anyone.

The PR changed the label, not the route

To see what went wrong, you first need to know what the PR was trying to fix.

sm_120 is the architecture code for consumer Blackwell. When Triton compiles a GPU kernel, it hands an architecture string to NVIDIA’s assembler, ptxas. An extra “a” at the end of that string (as in sm_90a or sm_100a) means “this code is only for this exact architecture, so it may use that architecture’s special instructions.” Think of it as a label stuck on a package: whatever the label says determines which instructions the assembler lets through.

The PR description’s diagnosis went like this: consumer Blackwell crashes randomly because the compiler generates tensor memory instructions (tcgen05) for hardware that doesn’t exist. It then claimed that the “a” label only exists for sm_90 and sm_100, and that sm_120a isn’t a real compilation target.

The original version proposed three changes: drop the “a” for sm_120, change the regex for the PTX .target, and route sm_120 through Hopper’s compilation pipeline. In terms of the analogy: peel off the label, change the sorting rules, and send the package down a different route.

After review, the maintainer asked for the routing change and the regex change to be removed, and for the condition to become capability != 120, so future architectures would still get the “a” by default. The author complied. So the core change that actually landed in main was just one thing: peeling the sm_120 label from sm_120a down to sm_120, plus a code comment claiming sm_120a causes tensor memory instructions, plus the modified tests. The PR description was never updated and still listed the original three changes.

If “sm_120a doesn’t exist” were true, peeling the label would make sense. That sentence is exactly where it falls apart.

The next day, the reviewer pointed out that 120a is a real “arch-conditional” compilation target, and that both CUTLASS and PyTorch use sm_120a. They also reported that building with this commit runs into a ptxas error: tensormap.replace not supported on .target sm_120. In label terms: the manual claimed this model has no such label and that applying it was a misprint, yet CUTLASS and PyTorch had been shipping with that label all along. And once the label was peeled off, some instructions got turned away at the assembler’s door for lack of it.

What review caught, and what it didn’t

Lay the timeline out, and it’s clear that people were really paying attention on March 16.

After the automated review bot (OpenAI’s Codex automated review tool) commented, the author swapped the sm_120 test from element-wise addition to a tl.dot matrix multiply. The original test would never generate tcgen05 instructions no matter what the compilation target was, so its assertion was verifying nothing. The maintainer, for their part, cut two overly broad changes and protected the default behavior for future architectures.

A hollow test, an oversized change, future compatibility: all three were real problems, and all three got fixed. They have one thing in common. You can spot each of them just by staring at this repo and this diff.

The question nobody asked was “does sm_120a actually exist?” The answer isn’t in Triton’s repo. It’s in CUTLASS’s and PyTorch’s code, and in the heads of people who know how NVIDIA’s toolchain works. The PR description stated it as confident fact, the whole fix was built on top of it, and it was the one sentence in the entire PR that most needed checking and that the fewest people were equipped to check.

Mogu’s take: blaming the reviewers isn’t really fair. Review, by nature, takes the premises a PR hands you and checks the implementation against them. The more complete and confident those premises read, the more naturally a reviewer spends their effort on “did this implementation correctly follow the premise” instead of “is the premise even right.” An AI can produce a confident technical write-up at almost no cost, while the domain experts who can spot a false premise at a glance are scarce. This time, that person showed up only after the merge. gu-log previously covered Mitchell Hashimoto launching Vouch, which was about how AI lets anyone produce respectable-looking contributions, breaking open source’s old habit of filtering people by whether they could write the code. Triton takes it one step further: now even the bar of “writing a diagnosis that sounds like you know what you’re talking about” is gone.

Mogu real talk:

This one hits close to home. What you’re reading is a rewrite. The previous version presented SemiAnalysis’s sarcasm as the participants’ own words, and sketched the PR’s mechanics as a story the sources never told. It read smoothly, the jokes landed, and it sat on the site for more than six months. Then someone went back and checked the PR timeline comment by comment, and found that both the opening and the main thread were built on a wrong premise, so the whole thing had to be torn down and rewritten. When that version went live, nobody had gone back to the original record. You can’t catch this kind of mistake just by judging whether the article reads well. Writing articles and writing PRs: same pothole (⁠｡⁠◕⁠‿⁠◕⁠｡⁠)

Nobody even agrees the bug exists

There’s a coda. On March 25, another contributor opened PR #9852, arguing that #9734 had only dealt with the suffix and not the compilation route. So besides dropping the suffix, it also sent sm_120/sm_121 down Hopper’s route. The maintainer replied that people had been using Triton on sm_120 just fine all along, and that this patch was basically the same as the one that got reverted. The author then tested on SM121 themselves, found that sm_121a worked and that the compiled output contained no tensor memory instructions, admitted the original diagnosis was wrong, and closed the PR on March 26 without merging.

So in the end, there isn’t even a clean answer to “is there actually a crash on consumer Blackwell, and if so, what’s the root cause?” #9734 peeled off a label that really did exist in order to fix a bug that may never have been confirmed, and then #9755 stuck the label back on.

SemiAnalysis says slop is getting harder to tell apart from valuable diffs. Triton’s experience this time: you can tell them apart, but the cost of doing so lands on one very specific person, the one who knows CUTLASS has sm_120a written in it. This time they showed up within a day, charged nothing, and wasn’t part of any checkpoint scheduled before the merge. The next PR built on a confident premise will keep drawing on that kind of person’s time in advance, and right now nobody is paying that bill.