Last weekend I went to a metal concert in Berlin. Four bands: Nails, Exodus, Carcass, and Kreator. Death metal, thrash metal, everything you need for a relaxing Saturday night.
Midway through the Exodus set, with the lights pulsing and the riffs shaking the floor, my mind drifted somewhere unexpected. The lead singer was doing what great frontmen do: leading the crowd into imaginary wars, channeling collective energy into something larger than any individual in the room. On the stage, his eyes were covered by shadows produced by the lights positioned exactly above him. He didn’t look like a regular person anymore. He was a living symbol, a temporary vessel for something the audience needed to feel.
And somehow, standing in that crowd, I started thinking about AI.
Yeah, I know. Bear with me.
The song nobody can play
Take music as a starting point. Current AI models can generate complete songs from a text prompt. Give it a genre, a mood, a tempo, and you get a polished track. Some of these are genuinely good. They have structure, melody, dynamics. You could put them on a playlist and most listeners wouldn’t know the difference.
But could anyone play them live?
Maybe. Maybe not. Some AI-generated compositions use note combinations that are physically awkward or impossible on real instruments. Some produce vocal lines that no human throat can reproduce. That exact voice doesn’t even exist! The output sounds like music, and by many measures it is music, but it exists in a space disconnected from physical performance. It was never played by anyone. It was never rehearsed in a garage. Nobody’s fingers bled learning it.
To perform it live, you would need AI-generated musicians. And at that point the word “perform” loses its meaning. It becomes a simulation of performance, an illusion of the thing rather than the thing itself.
Now contrast that with what I saw that night. Four bands who have been playing for decades. Musicians who spent years mastering their instruments, who toured in vans before they toured in buses, who wrote songs through a process of arguing, jamming, failing, and rewriting. The music existed because people created it through effort, and the live performance was the culmination of that effort, not the rendering of a probabilistic digital output.
The value wasn’t just in the sound waves hitting my eardrums. It was in knowing that the sound was being produced right there, right then, by real people who had earned the ability to produce it.
The software nobody can maintain
Now swap “music” for “software” and the parallel writes itself.
There is a growing movement around what people call “vibe coding”: using AI to generate entire applications from prompts, shipping products that no human fully understands, and declaring that understanding doesn’t matter. When something breaks, the argument goes, you just ask the AI to fix it. Or generate a new one. The code is disposable. The process is disposable. Only the output matters.
This is the software equivalent of the song nobody can play.
But here’s what makes it worse. “Vibe coding” as currently practiced is not really about using AI to build software. It’s about using a tool to do something you have no idea how to do, and trusting that the tool’s output is good enough. That’s a fundamentally different activity from what we might better call “AI-assisted engineering”: using agents to facilitate or accelerate work that you do understand, or mostly understand, and that you could achieve manually with a greater deal of effort and research.
The distinction matters. An engineer using AI to write a parser they know how to design is leveraging a tool. A non-engineer using AI to ship a payment system they can’t evaluate is gambling. The output might look the same. The risk profile is entirely different.
And the belief that AI will simply fix or replace malfunctioning parts when things go wrong is the kind of mental offload that should alarm us. It’s essentially saying: I don’t need to understand what I’m building, because the machine will understand it for me. That’s not just risky engineering. It’s plain irresponsible. And it’s a strange surrender of something that has always defined us as a species.
What are we optimizing for?
This brings me to the question that kept bouncing around my bouncing head during that concert: what variable are you trying to maximize?
It sounds like a business question, and it is, but it’s also a deeply philosophical one. Every decision about how to use AI (in music, in software, in anything) implicitly answers this question, whether you think about it consciously or not.
Let’s go back to Exodus for a moment.
Playing a live concert is not the most profitable creative activity a band can do. That particular night, four internationally known bands played for a few thousand people. The production was substantial: stage setup, pyrotechnics, lighting rigs, sound engineering, a full crew. Each band member made some money, sure, but if you calculate the return on investment purely in financial terms, they would have been better off spending that time in the studio recording the next album. An album has a much higher multiplying force: record once, sell forever, to an audience orders of magnitude larger than the crowd in a single venue.
So why play live at all?
Because the concert isn’t optimizing for the same variable as the album.
The album optimizes for reach, for revenue per unit of effort, for scale. The concert optimizes for something else entirely: connection, experience, the energy exchange between performer and audience that simply cannot happen through a recording. The fans need it to complete their relationship with the music. The band needs it to stay grounded, to draw inspiration, to remember why they make music in the first place. A band that only records and never plays becomes disconnected from the thing that makes recording meaningful.
And a band can’t be in permanent creation mode anyway. Creation feeds on experience, and experience requires doing things that don’t scale. Playing for three or four thousand people on a Saturday night is one of those things.
Most artistic spirits don’t track these metrics. They don’t sit down with a spreadsheet and calculate whether the tour or the album has a better ROI. They do both because both serve different purposes, and the mix of activities produces something that neither could produce alone.
The cost of engineering is real
In the software industry, the dominant optimization variable right now is speed. Ship faster. Use fewer engineers. Reduce the time from idea to deployment. AI is the lever, and the temptation is to push it as far as it will go: fewer technical people, more generated output, faster cycles.
But when you remove the technical people from the equation, you are doing something analogous to publishing songs on Spotify without involving any musicians. The output might be there. The metrics might look right for a while. But something fundamental is missing.
A musician isn’t just a means of producing sound. A musician is someone who understands harmony, rhythm, tension, and resolution at a level that lets them make judgment calls that no prompt can capture. “This chord progression is technically correct but emotionally flat.” “This transition needs another two bars to breathe.” “This solo should be raw, not clean.” Those calls come from years of practice, performance, failure, and internalization. They’re not in the prompt. They’re in the person.
A software engineer isn’t just a means of producing code. A software engineer is someone who understands systems, failure modes, trade-offs, and consequences at a level that lets them make judgment calls that no model can replicate from a description. “This architecture won’t survive the first traffic spike.” “This data model will make the next feature impossible.” “This dependency is a supply chain risk.” Those calls come from years of building, debugging, operating, and learning from incidents. They’re not in the requirements document. They’re in the engineer.
The value of having engineers who understand the systems they build is not imaginary. It is real, and the cost it bears exists for good reasons.
Every line of code that handles money, health data, or access control exists in a context of constraints, regulations, failure modes, and trade-offs that someone needs to understand deeply. Not because understanding is a nice-to-have or a cultural value, but because it’s the support structure that makes the whole thing work. Without it, the system is a house of cards that just happens to be standing at that point in time.
The revealing fact is that AI is excellent at helping you do that engineering work. It can help you to deliver better, more consistently and, yes, faster too.
It helps you to write better tests, explore more edge cases, quickly react to issues, and maintain higher standards with less friction. I’ve written about this before: when the effort of doing things right drops to near zero, quality becomes mandatory. It becomes the default rather than the exception.
But using AI to cut the engineering work itself, to skip the understanding phase, to ship systems that nobody in the organization can reason about? That’s not optimization. That’s irresponsibility dressed up as efficiency.
What speed really tells you
There’s a revealing assumption hidden in the “ship faster” mindset. When you optimize for speed at the expense of internal quality, you’re not actually valuing the artifact you’re building. You’re valuing the perceived volume of artifacts. The quantity. The throughput metric.
If you truly valued the artifact, you would make sure it achieves the planned intent. You would care about its internal structure, not just its surface behavior. A sculptor spends months on a single piece because the piece is the point.
And while art is an interesting analogy, it holds only to a certain degree. Software is not sculpture. Software is practical. It exists to serve a purpose, to solve a problem, to be used. A piece of software that is never shipped is worth nothing, no matter how elegant its internals.
But that practical nature cuts both ways. Precisely because software is meant to be used, it has to work reliably, adapt to changing requirements, and survive contact with real users and real threats. If you truly care about what you’re building, you can maximize for many things: scalability, security, a precise user experience, long-term maintainability. All of those require time, thought, and understanding. None of them are compatible with “just ship it and move on.”
You only optimize for speed “at all costs” if you accept that it happens at the expense of everything else, when you don’t really care about the result. When the goal is to extract short-term value before someone notices the cracks. When the product is a means to a financial end and nothing more. That’s not engineering. That’s not even building. It’s staging.
And that’s what makes the current AI-driven rush so revealing. The companies pushing hardest to replace engineering with prompting aren’t telling you they found a better way to build software. They’re telling you they never cared about the product in the first place.
Back to the concert
The most striking thing about that Exodus show wasn’t the music itself. It was the fact that every person in that room, band and audience alike, had chosen to be there. The band could have been in the studio. The audience could have been streaming a playlist. Instead, thousands of people gathered in one place to share an experience that was inefficient, unscalable, and remarkably irreplaceable.
Nobody in that crowd was thinking about optimization. Nobody was calculating ROI. They were there because some things are valuable precisely because they can’t be automated, scaled, or generated. The sweat on the guitarist’s forehead. The singer’s voice cracking on the high note. The crowd surging forward during the breakdown. Those moments exist because they’re real, and they’re real because they’re expensive (in time, effort, and physical presence) to produce.
Software doesn’t need to be expensive to be good. In fact, AI is making good software cheaper and easier to produce than ever before. But cheaper is not the same as effortless, and effortless is not the same as fully understood. Software deserves to be built by people who understand what they’re doing. The tools can change. The cost can drop. The need for understanding, however, doesn’t go away and never will.
And here’s what I keep coming back to. For as long as we’ve been human, we have insisted on understanding the world around us. We built mathematics to describe nature. We developed the scientific method to test our assumptions. We created engineering disciplines to make sure bridges don’t collapse and planes don’t fall from the sky. At every stage of technological progress, the instinct has been the same: learn how it works, then use it. Using without understanding is not a shortcut. It’s not “being efficient”. It’s a regression.
The current push to offload understanding to machines, to ship things we can’t explain, to treat comprehension as an unnecessary cost, runs against something very deep in what makes us human. And we’re doing it not because we have to, but because it’s faster. Because the quarterly numbers look better. Because someone decided that understanding is a line item that can be cut.
We are at a turning point. The tools are here and they are genuinely powerful. The question is whether we use them to deepen our understanding or to replace it. And that question is being answered right now, in every company, every team, every project, whether anyone is asking it out loud or not.
I’ll keep going to metal concerts, by the way.