AI Wrote a GPU Kernel 18 Faster Than Humans. Now Who Reviews It?

Ken Mazaika — Thu, 16 Jul 2026 03:59:38 +0000

Last week an AI-generated GPU kernel ran 18.71× faster than an optimized PyTorch baseline.

The model—Fable 5—didn't just edge past the human implementation. It lapped it. Claude Opus 4.8 reached 14.4×. GLM-5.2 hit 11.14×. GPT-5.5 managed 4.34×. Fable's kernel was in a different tier entirely.

The exciting read: AI is starting to improve the low-level machinery that makes AI itself cheaper and faster. Specialized performance work that once required rare expertise just got dramatically easier to explore.

The uncomfortable read: what happens when the best implementation is also the one nobody on your team would have written—or can fully explain?

That question is about to land on every engineering team that ships AI-generated code.

The Benchmark Problem

A benchmark shows the kernel ran fast under tested conditions. It doesn't show:

How it behaves across different GPU hardware
How it handles numerical edge cases
What happens under months of production changes
Whether it degrades gracefully when inputs shift

The person who wrote it can't answer these questions either. The AI generated this code through a process that doesn't leave a reviewable chain of reasoning. There's no commit message that says "I chose this approach because X."

So the reviewer's job just got harder—not easier.

The Real Shift

I've been watching this pattern across engineering teams this year. The argument is moving from "can AI generate working code?" to "can our org absorb generated code without breaking quality, morale, or judgment?"

The GPU kernel story makes the tension concrete:

One side says the code ran, it was measured, it won. Stop moving the goalposts.
The other side says somebody still has to know where it can fail and take responsibility when it does.

Both are right.

AI can make implementation cheaper while making proof more expensive. Senior engineers may write less code but spend more time designing adversarial tests, checking assumptions, planning rollbacks, and deciding whether an impressive result is safe enough to ship.

That's not the disappearance of engineering work. It's engineering work moving into review—and raising the stakes of who's qualified to perform it.

The Question Nobody's Answering

If AI does more of the building, how do engineers learn enough to review what it produces?

Senior engineers learned by building systems, making mistakes, debugging failures, and taking the call when something broke. If junior engineers begin as supervisors of generated work, they may learn how to move output through a pipeline without developing the instincts needed to know when that output is wrong.

One comment on a thread about this put it well:

"You can't conduct an orchestra without knowing music."

Companies should not preserve manual coding because suffering builds character. But they do need to identify which parts of implementation create judgment before automating those experiences away. Otherwise, they may create extremely productive junior engineers and discover a few years later that they did not create senior engineers.

I write about engineering management, AI adoption, and what actually changes when tools shift. If this landed, I send a weekly post covering stories like this with the management angle. You can find it here.

Here's What You Can Learn In 10 Minutes That Will Be Useful For The Rest Of Your Programming Career

Ken Mazaika — Wed, 01 Mar 2017 21:26:23 +0000

There is one remarkably simple trick you can learn in only a few minutes that will be useful for the rest of your future as a programmer. And there's a critical reason why this one small trick is so significant that is important to understand

The 10 Tab Rule

In programming, you're going to run into problems, error messages, and situations in which your program isn't doing what you think it should. How you react to these scenarios will be the difference between being an okay programmer and an amazing one.

The “10 Tab Rule” is a simple process that can solve almost every problem you'll encounter as a programmer. What's the rule?

When problems arise, do these 3 things:

Articulate the problem in a well-thought-out search query
Search it using Google (or another popular search engine)
Open each of the top 10 results in new tabs. Read or skim each of the tabs, then return to your code.

This simple routine– which will take roughly 10 to 15 minutes– will help you solve almost all of your problems as a developer. The difference between experienced and inexperienced developers is this: experienced developers immediately acknowledge what they don't know and set out to find the answers, while inexperienced developers often times don't have the knowledge nor the humility to begin looking for answers.

It's a subtle mentality switch, but it's important. Beginners often have the mentality of:

“I don't know, and I feel stupid because of it.”

However, experienced developers have an entirely different mentality…

“I don't know, let's figure this out as quickly as possible.”

And it turns out, with Google, nearly all of the questions you could have about anything are at the touch of your fingertips.

Turning to Google sounds easy in theory, but it's pretty unlikely that going to Google's homepage will answer your question. Instead, a huge part of being a good developer is coming up with a reasonably effective twenty- to fifty-character description of your problem.

20–50 letters isn't a lot of room to communicate the problem. And searches like, “my app doesn't work anymore” might be 26 letters, but won't lead you any closer to a meaningful solution to your problem.

Before you are able to use the internet to solve your problems, you need to fully understand the problem first.

The most important skill that software developers cultivate over time is the ability to solve problems using two specific steps:

First, fully understanding the problem with your code.
Second, looking for the solution to the problem based on your understanding.

It's far too common to look for the solution to a problem before you fully understand it, and doing so will likely be a frustrating process. If you encounter an error message you've never seen before, a quick search for the text of the message can give you a lot of the context around the problem.

When writing complex algorithms and business logic, there is one specific problem that will account for nearly every single error message you'll see.

And this problem plagues both those starting out and people who have been programming for decades.

It is incredibly common to think your computer program is doing one thing when it's actually doing something else.

It's your job as a programmer to make no assumptions about what your program is doing, and use all the tools available to you to verify that each of the many assumptions you have about how your program is working is true.

Thinking that a variable is set to one thing when it's actually something else is very common.
Thinking a certain method returns a certain value when it actually returns a different one is common, too.
Thinking a function does one thing when it does something different altogether is another common one.

They're all variations of the same problem: thinking your code works one way when it works in a different way.

When this happens, it is your job to put on your detective hat and determine exactly which line of code is doing the wrong thing.

In ruby, you can use tools like puts, bye_bug, or pry.

In JavaScript, you can use console.log to get the job done.

Nearly every programming language has tools built into it to allow you to figure out which line of code isn't behaving the way you think it should.

A HUGE part of becoming a software developer is understanding the tools at your disposal for understanding why you are having a problem.

Once you identify the disconnect between what you think the code is doing and what the code is actually doing, fixing the problem is usually pretty straightforward. And the ultimate solution: figuring out the line of code you don't understand, and doing effective searches to research what is actually happening in your code.

As you grow as a developer, the “10 tab rule” will become the “8 tab rule,” and eventually just turn into one or two Google searches that you need to execute to find the solutions to your problems.

But the important lesson to take away is that understanding the problem is usually the hard part.

Once you understand the part of your program that isn't doing what you think it is, finding the solution becomes pretty easy.

Thanks for reading this post! If you liked it, I'd appreciate it if you shared this post on Facebook or Twitter!

FYI: This post originally appeared on the Firehose blog, where I write stories about, learning to code, career advice, and making it happen.

DEV Community: Ken Mazaika