When AI Writes Code, What's Left for Developers

At Omacon, a conference celebrating what he calls "the fun of computers," popular developer ThePrimeagen delivered a talk with a title that caught attention: "I suck." But the talk itself wasn't about inadequacy—it was about a crisis of confidence spreading through the developer community, fueled by AI code generation and a constant stream of AGI predictions on social media.

He's been fielding messages for months. Developers with one year of experience, five years, ten years, twenty—all asking the same question: Is everything I've learned worthless now? Some messages are darker. "At least multiple times a month someone's like saying they're going to kill themselves over this," he told the audience. "Like, it's like insane messages going out there."

This isn't abstract anxiety. ThePrimeagen himself spent six months in what he describes as a funk, questioning whether his 20 years of programming—6,000 days, 14 years of mastering Vim motions, learning Go, JavaScript, C, Rust, Zig—amounted to an investment error. While others were "having premarital sex," he joked, he was "learning programming languages." The question that haunted him: have I invested poorly?

The Metrics That Don't Matter

He ran through the obvious answers and found them wanting. Maybe a developer's value is just "taste"—that vague term VCs throw around about making websites look nice. "Is that what we are as engineers now? Just taste? Just making sure things look nice? Make circle not square?"

Or maybe it's lines of code. He could type 15,000 lines in a week at his peak. But then Y Combinator CEO Garry Tan claims 37,000 lines in a day. "I'm getting mugged left and right by a guy who dressed in a lobster outfit," he said. "That's not going to work out for me."

Neither metric survived scrutiny. The talk could have ended there—another developer venting about industry chaos. But ThePrimeagen shared two moments that reframed his thinking.

Two 2x4 Moments

The first happened years ago in Bozeman, Montana. He'd just bought his first house and was starting a new job at WebFilings (now Workiva), anxious about whether he'd be good enough. Walking to a neighbor's house, so consumed by invented fears about his future, he walked directly into a 2x4 sticking out of a truck.

"I was laying on the ground and I was shocked," he said. The physical jolt snapped him out of a mental spiral. "I was so focused on a future that I was crafting out of a narrative that I don't even know that I didn't see the actual real and obvious danger directly in front of me. I made up dragons that didn't even exist."

The second 2x4 moment came recently, scrolling Twitter. He saw a developer asking for help with what they described as a "really trivial issue." The screenshot showed Claude's internal monologue suggesting they fork Chromium.

Fork Chromium. To solve a trivial problem.

"How do you build a web project in which the result of whatever you've made choices of as engineers led you to forking Chromium?" he asked. "Modern 2023 to 2025 hardware takes 6 hours to compile the project. Like, this is not a—how did you get here? Like, this is insanity."

That screenshot crystallized something: "All the decisions I've made and learned and earned along the way, those only get [more valuable]... if AI is to be a true multiplier, then every one of those little decisions actually do matter. Because if you don't, you're forking Chromium."

The Paradox of Infinite Options

His argument turns on a counterintuitive claim: "If the cost of a line of code has dramatically dropped, then the cost of the right line of code has dramatically increased."

He used pizza as an analogy. The first time you make your own pizza, you load it with every topping you love—onions, sausage, pineapple, everything. "And then all of a sudden you just have every ingredient underneath the sun on your pizza, and you're like, 'This is the worst pizza I've ever made in my entire lifetime.'"

When everything is possible, choosing correctly becomes harder, not easier. You won't "just magically end up with a Boyce-Codd normalized database" without understanding what that is and why you might break those rules. You won't know whether to use stdin/stdout versus a web server. These decisions "compound over and over again. It's not some sort of like, 'Oh, you have a five end problem.' No, you have a two to the end problem."

Toxic Productivity

For developers still building experience, he offered what he called "a hot new term": toxic productivity. "You don't have to be productive at all times. Like, earning experience is more valuable than completing something instantaneously."

This cuts against the current obsession with shipping, with demonstrable output. "I think there's this mindset or this idea that if you're not continuously showing having some sort of end result that you can click or do something, then you haven't been productive."

But his most influential learning came from failure, not finished products. "I could have read the friendly manual. But, I decided to save 5 minutes of reading the friendly manual with 6 hours of debugging, and I learned a lot from that."

Code generation tools are genuinely useful for well-understood problems. "There's a lot of problems that are just simply really, really well understood and documented 5,000 times," he acknowledged. If you need another parser—except in bash, he joked—AI can handle it. But good engineering decision-making "can't be gone. Like, I don't see how you can get from A to B without someone with good decision-making."

What Regulatory Frameworks Miss

From a policy perspective, this raises questions current AI regulation doesn't address. Most proposed tech regulation focuses on AI safety, copyright, or labor displacement. The European Union's AI Act classifies risk levels. Various U.S. bills tackle deepfakes and election interference.

But few frameworks grapple with the quality question ThePrimeagen identifies: what happens when generating code becomes trivial but evaluating that code remains expert-level? The assumption underlying much policy discussion is that AI either replaces developers or doesn't. The messier reality—AI as a multiplier of both good and catastrophically bad decisions—doesn't fit cleanly into regulatory categories.

This matters because it affects how we think about workforce policy, education requirements, and professional standards. If experience and judgment increase in value even as code generation becomes commodified, that suggests different training pathways than current bootcamp models optimized for quick market entry.

ThePrimeagen ended his talk with a quote from Rails creator DHH: "It's fun to be competent." That's not policy analysis. But it does point to something regulatory frameworks struggle to capture: the distinction between activity and expertise, between generating output and making sound technical choices.

The developers messaging him about worthlessness are asking the wrong question. The question isn't whether their skills have value. It's whether they—and the industry's hiring practices, educational systems, and policy frameworks—understand what kind of value matters now.

—Samira Okonkwo-Barnes