During my weekly long runs I listen to podcasts. Mostly about tech or music, and a couple of months ago I listened to an episode that contained some quotes that kept resonating: “Going caveman” and “you do you”. Let’s unpack what they mean in the context of working in tech, the AI-ification of everything, and the state of the world today¹.

A bit of background

The podcast I’m referring to is ‘The Garza Podcast'. Episodes of about two hours long, having Chris Garza interview musicians from the metal scene. No gimmicky Beavis and Butt-Head energy, just people hanging out and geeking out on the topic they are as enthusiastic about as ever: Music.

The specific episode was an interview with Gene Hoglan. A drummer often named ‘the atomic clock’, he is not only precise, but has also laid down some of the most creative drum parts in metal drumming, including the album Individual Thought Patterns of the band Death.

Death metal is a bit like whisky: not immediately approachable, but once you get past the first hurdle, many subtle flavors unfold. And it involves craft to create. Whisky is more than just alcohol that tastes like wood, and metal is more than noise that’s all about darkness.

In the mid-80s, early 90s, an extreme variant of metal emerged: death metal. Think of it as Metallica on steroids with guttural vocals. Youngsters trying to make music as fast, and contrarian as possible. One of the pioneers of the genre was the band ‘Death’, founded by the late Chuck Schuldiner.

After the first couple of albums, which were indeed all about the genre-typical subjects of zombies and gore, Chuck set out on a more innovative path, resulting in the album Human. Music much more technical, having progressive and jazz influences, and lyrical content shifting to topics like society and introspection.

The next album, Individual Thought Patterns, continued this trajectory, and was the first to feature Gene Hoglan on drums.

Things to keep in mind reading this:

• Chuck: Song-writer, guitarist, band leader and visionary
• Gene: Drummer, band member

Going caveman and “you do you”

In the podcast, Gene described how the recording of the drums came to be. It started with demos recorded by Chuck, referred to as the ‘adorable demos’. At the time, most musicians had a 4-track or 8-track recorder, allowing to record more than one track one by one, in decent quality.

Chuck went caveman: He recorded one guitar track on a regular cassette using the record function of a ghetto blaster. Then played back that track while playing additional guitar parts (harmonies, leads) and recorded both using a second ghetto blaster. Very lo-fi.

He handed these demos over to Gene with little to no guidance and said “you do you” and “there’s a reason we’re working together”. Basically trusting Gene to come up with something good.

Tech

Now how does geeking out on the recording process of a more than 30-year-old album of not-so-middle-ground music, relate to tech? Let’s see.

Vision and execution beat tools

What I find interesting is that having very basic tools, in no way did hinder the process of creation. Perhaps it even shaped it in a way: with just two tracks, Chuck really needed to focus on the essentials: main riff and harmony.

These days, software like Cubase or Pro Tools make it possible to create complete, multi-layered musical arrangements. That also means there is no limit in what one can add, and one can specify every detail one thinks of. So, sophistication increases and the technology becomes accessible to a larger audience. However, the need for vision, plan and guidance hasn’t changed.

There are some interesting parallels to the current changes that are happening in tech with the rise of AI.

Modern software has given musicians the ability to create professional productions from their home and to collaborate remotely without needing to travel to a physical recording studio. And we now have more music than ever, but I doubt we have more good music.

I fully acknowledge this is highly subjective, might be part nostalgia, and that classics can only become classics as they age. I just genuinely wonder if there is any record in contemporary metal that will be as highly regarded in 20 years as records like Metallica’s “Master of Puppets” (1986), Machine Head’s “Burn My Eyes” (1994), Death’s “Symbolic” (1995), or Opeth’s “Still Life” (1999) and “Blackwater Park” (2001).

Similar to music recording software, LLMs bring the ability to create software to a large audience, at a level and speed that was impossible until very recently. And like music, guidance and vision don’t magically appear because tooling has improved. Furthermore, specific to software, there are important aspects like security and maintainability, that are not to be taken for granted.

A couple of months ago, Dax Raad, creator of OpenCode, posted an interesting observation in his usual direct, unfiltered, tone of voice²:

I think that observation holds true. Traditionally in organizations, there are all kinds of processes: At the C-level and downwards, strategy is distilled into per-department targets such as OKRs. Then per department, teams evaluate those goals, turn them into hypotheses, prototypes, POCs. Chose what to build, since you can’t build it all. Determine how to measure results. Evaluate. Repeat.

Now if creating becomes cheap, it becomes tempting to stop thinking about goals. Or about how and what to evaluate. There is no need to choose, so we are tempted to (and can!) build it all. But ultimately all of that lands in the same structures that always existed: a target audience that can only consume so much. An organization that can only evaluate so much. Processes like decision making, procurement, architecture (ADRs), A/B tests that haven’t sped up. Bottlenecks everywhere. The result can hardly be anything other than: more software, with less quality, less vision, and less utilisation.

“You do you” in teams

“There is a reason we’re working together”

This was what Chuck said, when asked for guidance on what drum tracks Gene should lay down.

And it embodies a lot of what makes great teams great. We hire people on merits and potential for growth. For the fresh perspectives they bring to the table. For the specialised skills they have, and how they can level up their team.

If we look at the Agile Manifesto, it puts indivuals and interactions front and center. And this is what happened in the recording process. Chuck didn’t need to spell out exact drum patterns. Of course he might have provided some ideas, the ‘takada-boom’ type of conversations musicians have. But he refrained from micro-management, trusting Gene to come up with something good, and giving room to creativity.

Now there will likely have been a back-and-forth proces of recording. Gene coming up with a track, Chuck giving feedback. And perhaps over and over, until Chuck was satisfied. That’s attention to detail. Not the same thing as micro-management. And that works, because Chuck hired Gene, and Gene had guitar tracks to go off. Chuck didn’t hire a reputable funk drummer who would come up with 70s disco beats based on the vague description “I want something up-tempo”.

One could say Chuck had reasonably clear expectations, but no specifications. Those are different things. And expectations can, and probably should, be shaped by interactions. They are not carved in stone. It’s what humans do, and what makes the human mind great. Taking inspiration, discussing, trying, evaluating, adapting, transforming. The Wright brothers didn’t wake up and ‘just invented’ a plane. There was a process leading up to that. A process of high-bandwidth interactions.

Now setting people to work based on specifications is not a bad thing in a lot of cases. Assembly line work doesn’t fare well if it depends on the ‘mood of the day’. And in music, it’s not uncommon to hire session musicians who will track instruments based on transcribed parts, or midi files. Basically to have human-sounding recording of what was already created digitally³.

“You do you” with agents

The contemporary Silicon Valley equivalent of hiring a competent drummer would be writing a specification and then having a LLM generate a drum-track. If not satisfied, refine spec, repeat. And again. And since creating has become so cheap: another round. No team synergy. No accomplishment. A result that fits the music, but lacks the human element.

We can write a skill: “Use albums this and that as reference material. Replace the hihat with an additional piccolo snare⁴. Don’t play things that are not possible with four limbs.”

If it’s known what one wants, this is entirely feasible. Professional musicians in an orchestra will play exactly what’s written on sheet music, and follow the conductor’s guidance. The conductor overviews the end result, focusing on things like overall sound and dynamics.

Creating software can be like that. This used to be the waterfall method: If you design and specify everything in detail up-front, you can just throw that over the fence and the desired software will come out. The proverbial fence here being the border to any lower-wage off-shore or near-shore country.

Although the low cost of creating can be a deciding factor, the reality is that a lot of organizations found waterfall to be quite ineffective, resulting in the emergence of Agile. Waterfall needs a considerable amount of effort in up-front design and QA, while offering no flexibility or adaptability.

Spec-Driven-Development in a way is like traditional Waterfall condensed in a way shorter timespan. And that reduced timespan should give more of the adaptability that is lacking from waterfall: cheaper and faster iterations.

Many challenges that have always been there in software architecture remain when practicing Spec-Driven-Development. To name a few:

• Do we really know what we want upfront?
• How to describe everything we want in detail, so the outcome matches our expectations?
• How do we ensure the things we write down, don’t contradict one another?
• How can we evolve architecture and requirements over time?
• How can we, as an individual, or team, or organization, remain able to grasp, overview and review our specs?
• Even with all our specs, do we dare to switch vendors models?

Much of the praise of Spec-Driven-Development seems to focus on the magical part of going from human-readable descriptions to working software at the press of a button. And it is great. But it also means part of the required effort simply moved outside of the creation phase. To the left, crafting the right spec. And to the right: QA, evaluation.

Don’t just take my word on challenges lurking in Spec-Driven-Development: Martin Fowler wrote a very interesting piece, exploring some of the frameworks in this space.

There’s an interesting paradox in the approach: On the one hand being concise helps in grasping what we’ve written from a human perspective. And less text is a good thing for the limited context windows of LLMs as well. On the other hand, to constrain the nondeterministic nature of agents, we need to be very precise and verbose. I believe balancing that will remain a challenge.

Worth noting is that LLMs are also very useful in the phases left and right of the actual code authoring. So we can use LLMs to craft our spec. And to do QA. At the same time, they are black boxes, and their creators have an incentive to make you come back. So, the LLM will be friendly, tell you what you like to hear and is unlikely to push back. Even if it should.

There is an interesting case study on Spotify’s way of working, resulting in ‘aligned autonomy’. The gist of it is that to achieve high performance, both alignment and autonomy are needed.

Looking at the illustration, Spec-Driven-Development I’d say sits in the top-left corner. The real question, and challenge, is: “Do we need a bridge?". The arrival of agentic workflows hasn’t removed that challenge. But it sped up building a bridge.

LLMs are like good musicians. You can work with LLMs in a way that is truly interactive, the equivalent of jamming together as a band. And the result might surpass the sum of its parts. Or you hand over your sheet music or midi files, the equivalent of spec-driven development, which is fine if you know exactly what you want. But do you?

Sovereignty and autonomy

A final aspect I find intriguing is that the tools to create the music, were simple, widely available, with ‘no strings attached’. Guitars, amps, cables, 4-track recorders, cassette. All compatible with one another and quite easy to replace. Marshall amp head broken but the studio has an ENGL sitting around? Might not give the exact sound you’re used to, but it will work. Forgot your cable? Borrow one.

Modern day, things are often different. For recording, Pro Tools is a common choice for professional musicians, but the license is subscription-based. NeuralDSP offers amazing amp modeling capabilities. To get the most out of it you can use plugins that give you the complete sound of your favorite artist. Luckily the license of plugins is for life. Still, it requires software, including a license manager, which has requirements on the system it runs on. And software needs maintenance: The OS it runs on needs security updates, and compatibility between OS and software needs to be ensured.

That’s a lot of software dependencies for essentially turning guitar string oscillations into an electrical signal. And it works by the mercy of the company that provides the software staying in business. Or not being acquired by an entity that has very different views on pricing models⁵.

The parallels with modern software engineering are obvious. And of course it’s not sane to build everything yourself just for the sake of independence. But there’s a spectrum: Platforms like Postgres or Redis are widely available. Containers can run everywhere, using any orchestrator of choice. OpenTelemetry data can be sent to a wide variety of observability tools. Standards like OIDC, OAuth and SPIFFE are the backbone of authentication. S3 has become the API standard for object storage. The list is endless.

Even when using such widely available standards and components, replacements or migrations might not be particularly easy. But it’s always possible, without needing to rewrite a lot.

That’s autonomy and digital sovereignty in a nutshell.

It’s all about not putting eggs in one basket. Standardising on baskets is efficient. And even if the basket vendor is not your best friend, or is strongly influenced by parties who are definitely not your friend, things can still work out. But if only one specific basket exists that can hold your eggs, you’re on a lifeline of goodwill.

Not saying we should stick to Vim. But if a year of advancement has gotten us to sitting on our hands whenever Claude is down, we’re not doing alright either.

Conclusion

It’s interesting how listening to a seemingly unrelated podcast, opens up a can of metaphors. I can for sure say that connecting those dots happens way faster than writing down those connections in a coherent way. Whether or not I succeeded is for the reader to decide.

But that’s ok, sometimes the journey is the goal. Because the insights, or simply the reward that the journey brings, helps shape new goals.

Chuck died of cancer, a disease sadly affecting many people. Let’s just hope that all those water-guzzling and energy-consuming datacenters that are being built are also used to help humanity in fighting that disease. Maybe then all the AI-augmented processes that should have stayed simple, or the endless slop that shouldn’t exist, might be a price worth paying.

Although written between 35 and 28 years ago, I can’t help but feel Death’s last 4 albums have been written specifically for the state of the world and society today:

• Human
• Individual Thought Patterns
• Symbolic
• The Sound of Perseverance

Words to live by…

I hope you enjoyed reading this as much as I did writing!

Got any thoughts or feedback? Find me on LinkedIn or BlueSky