What Tampa Death Metal Teaches Us About 10x Engineering
Now that I got your attention...
The current race toward "10x software engineering" powered by AI agents follows the same pattern as the Tampa Bay death metal scene between 1987 and 1993. And I'm going to argue that this comparison is not just a joke to get your attention—or not just that, I mean—but a genuinely useful lens to examine where we are, where we're heading, and what questions we may be forgetting to ask.
If you've never heard of Morbid Angel or Obituary, don't worry. And if you've never used Claude Code or Cursor, also don't worry. By the end of this post, both groups will make sense, and you might find yourself thinking about productivity metrics in a way you didn't expect.
10x whatever
Open YouTube and search for "AI coding." You'll find an endless stream of thumbnails promising to unlock your potential as a 10x engineer. The formula is remarkably consistent: a shocked face, some floating code, maybe a robot, and a title suggesting that one weird trick will multiply your productivity by an order of magnitude.
The clearest sign that my generation no longer controls Internet culture: I'm biologically unable to get used to this.
I'm not here to mock this (well, maybe just the shocked face stuff). The tools are real, and the productivity gains appear to be real—at least for some developers, in some contexts, so I can understand that a certain amount of excitement is justified. Anyway, GitHub Copilot, Claude Code, Cursor, Windsurf—these aren't vaporware. They represent one of the few areas where generative AI has delivered concrete, measurable value.
But there's something worth examining in the framing. The "10x engineer" has become an article of faith, a destination everyone assumes we should be racing toward. More code, faster. More tickets closed, quicker. More features shipped, sooner. The metric is productivity, the direction is up, and the tools are finally here to take us there.
Before we accept this as the obvious path forward, I want to take a detour through the swamps of Florida in the late 1980s, where a group of young musicians asked a similar question about a different kind of extremity, and followed it to its logical conclusion.
Once upon a time, in Florida
In 1986, Slayer released Reign in Blood. Thirty minutes of relentless aggression that redefined what heavy music could be. For a generation of young musicians, it was both an inspiration and a challenge: this is the new ceiling—now what?
In the Tampa Bay area, a handful of teenagers took that challenge personally. Chuck Schuldiner, working under the name Death, had been pushing thrash metal into more extreme territory. Trey Azagthoth was forming Morbid Angel with an almost teleological commitment to creating the heaviest music possible. John Tardy and his brother Donald were putting together Obituary, focused on a slower, crushing approach that felt like being buried alive.
These musicians knew each other, shared rehearsal spaces, traded demo tapes. And they shared an unspoken conviction: Slayer had shown the direction, but hadn't reached the destination. There was further to go.
What emerged would be called death metal. By 1990, the Tampa scene had produced albums that would define the genre for decades: Death's Leprosy, Morbid Angel's Altars of Madness, Obituary's Cause of Death. A regional scene had become a global movement. But this didn't happen through talent alone. Tampa had Morrisound Studios.
The real catalyst was a young engineer named Scott Burns. Between 1988 and 1993, Burns recorded virtually every significant death metal album to come out of Florida. He developed a sonic signature inseparable from the genre itself—he figured out how to capture the chaos of blast beats without turning them into mush, how to make guttural vocals sit in the mix with clarity. Before Burns, death metal demos sounded like they were recorded inside a washing machine. After Burns, they sounded like a genre.
Burns understood what these bands were trying to achieve, sometimes better than they could articulate it themselves. He was a translator between artistic vision and physical reality—the person who could take "we want it to sound more evil" and turn that into specific decisions about microphone placement and EQ curves.
Here's where the parallel becomes hard to ignore.
Tools like Claude Code, Cursor, or GitHub Copilot function as a kind of Morrisound for software development. They take our intentions—sometimes clear, sometimes half-formed—and translate them into working code. Like Burns, they're at their best when the person using them knows what they're trying to achieve.
A band showing up at Morrisound without a clear musical vision would leave with a professional-sounding record that said nothing. A developer prompting an AI agent without understanding the problem will get working code that solves the wrong thing efficiently. The infrastructure amplifies. It doesn't replace the need for something worth amplifying.
Collaboration, competition, and other synonyms
The Tampa scene wasn't just a collection of bands that happened to live near each other. It was an ecosystem of mutual provocation. When Death released Leprosy in 1988, Morbid Angel heard it and pushed harder on Altars of Madness. When Obituary dropped Slowly We Rot, the other bands noticed how effective a slower, heavier approach could be. There was competition, yes, but also cross-pollination. The question hanging over every rehearsal was: what are the others working on, and how do we respond?
This created a feedback loop that accelerated innovation far beyond what any individual band could have achieved in isolation. Within five years, the genre had evolved from Slayer-inspired thrash into something their influences would barely recognize.
Sound familiar?
Scroll through LinkedIn or Reddit today and you'll find developers sharing what they've built with AI agents. "I created a full app in an afternoon." "I automated my entire deployment pipeline in two hours." There's a similar energy—part genuine excitement, part competitive display. And it creates the same feedback loop: each impressive demo raises expectations, which pushes others to attempt more ambitious projects.
This is genuinely productive. The Tampa feedback loop gave us classic albums. The current loop is producing real tools, real automations, real efficiency gains.
But that's precisely what makes it worth asking: what direction are we actually moving in?
Are we in 1987 or in 1993?
Here's a question that, as far as I know, nobody in Tampa asked between 1987 and 1993: should we actually be doing this?
Not "can we play faster?"—they clearly could. Not "can we make it heavier?"—every new album proved it was possible. But rather: is more extreme necessarily better? Is brutality a parameter that should be maximized indefinitely, like Moore's Law applied to blast beats?
The musicians assumed the answer was yes. And they produced extraordinary work under that assumption. But follow any parameter to its logical conclusion and you eventually hit diminishing returns—or worse, self-parody. By the mid-1990s, death metal had fragmented. Some bands kept pushing toward pure speed, producing records impressive as athletic achievements but exhausting to listen to. The explosive innovation of the Tampa years gave way to something more scattered, more niche, more about refinement than revolution.
The scene had answered "how far can we go?" without ever seriously asking "how far should we go?"
I think about this when I see the phrase "10x engineer."
What does 10x actually mean? Ten times more lines of code? That's almost meaningless as a quality indicator—sometimes the best engineering is removing code. Ten times more features shipped? Features are a cost, not just a benefit. Ten times faster delivery? Speed matters, but so does building the right thing in the first place.
The Tampa musicians had a clear aesthetic goal: heaviness, extremity, intensity. Maximizing those things made sense within their artistic framework. But software engineering isn't an aesthetic pursuit. We're not trying to create the most brutal codebase. We're trying to solve problems for people, reliably, over time.
What would it mean to be a 10x engineer in a world where the metric wasn't speed?
What does 10x really mean?
Let's take the question seriously. If we could redefine "10x engineer" around something other than raw speed, what would we choose?
The ability to say "we shouldn't build this." Every feature not built is a feature that doesn't need testing, documentation, maintenance, or eventual deprecation. AI agents are very good at generating code; they have no opinion about whether the code should exist.
The most common flaws in enterprise software development are not due to the slowness of its programmers, but to communication failures.
Clarity of design under uncertainty. Complex systems—especially enterprise systems, the kind I work with daily in the SAP ecosystem—don't fail because developers were too slow. They fail because the architecture couldn't accommodate changes nobody anticipated. An engineer who builds flexible, comprehensible structures is multiplying the effectiveness of everyone who comes after.
The judgment to know when not to automate. There's a particular mess that emerges when someone automates a process they don't fully understand. The automation encodes assumptions that were never examined. AI-assisted coding makes this failure mode faster to achieve.
Effective translation between domains. In enterprise software, the gap between what the business needs and what gets built is rarely a technical problem. It's a communication problem. The engineer who can move fluently between business language and technical implementation is doing something no AI agent can currently do.
What these have in common is that they're harder to measure than "tickets closed" or "pull requests merged." They require judgment, context, experience—the things that accumulate over years, not the things you can shortcut with a better prompt.
When Morrisound made death metal bands sound more brutal than ever before, it was amplifying the thing those bands cared about most. The question for us is whether speed and volume are really the things we care about most—or just the things easiest to turn into a metric.
What remains after the storm passes
Chuck Schuldiner didn't become one of the most influential figures in extreme music because he had access to Morrisound. He had access to Morrisound because he had spent years developing a vision of what he wanted Death to sound like. Scott Burns could capture that vision, amplify it. But Burns couldn't supply the vision itself.
This is obvious when you say it out loud. Of course the tool doesn't replace the artist. But it's easy to lose sight of the obvious when the tools become impressive enough.
The current generation of AI coding assistants can do things that would have seemed like magic four years ago. They can generate working functions from natural language descriptions, refactor code, write tests, hold context across an entire codebase. This is real, and it's genuinely useful.
But here's what they can't do: they can't know why your system exists. They can't understand the political history behind that weird module everyone's afraid to touch. They can't sense that the stakeholder asking for a "small change" is actually describing a fundamental shift in business strategy.
In enterprise environments—the world of SAP implementations, legacy integrations, decade-old business logic encoded in systems that predate half the current team—this knowledge is the difference between a project that succeeds and one that implodes. It's the accumulated judgment that lets you point AI tools at problems worth solving.
Morrisound could make a mediocre band sound professional, but it couldn't make them interesting. The same dynamic applies now, just with different tools and different stakes.
Making a classic album vs. vibe coding some stuff
Here's the thing about the Tampa death metal scene: the albums that still matter, thirty years later, aren't necessarily the fastest or most technically demanding.
The records that lasted were the ones where speed and brutality were in service of something, not ends in themselves.
We're going to produce a lot of code in the next few years. More than ever before, faster than ever before. The tools guarantee it. Some of that code will be extraordinary. But a lot of it will be the software equivalent of a technically proficient death metal album that nobody listens to anymore: impressive in the moment, forgettable once the moment passes (I'm looking at you, Serpents of the Light).
The apps that will still matter in ten years probably aren't being built in an afternoon. They're being built by people who know what problem they're solving, why it matters, and what trade-offs they're willing to accept. People who use AI tools the way Napalm Death used Morrisound: as an amplifier for a vision that existed before the tool did.
Maybe that's the real definition of a 10x engineer. Not someone who produces ten times more code, but someone whose work is still running, still useful, still comprehensible, ten years from now.
That's a harder metric to optimize for. It doesn't fit on a thumbnail.
But neither did Altars of Madness.