I’m Not an AI Developer. I’m a Biologist.
Why the way most people talk about AI reminds me exactly of what happened with BIM in construction - and why both miss the point entirely.
I use AI in my music production. There, I said it.
If you just had a reaction to that sentence – good or bad – you’ve proved the point I’m about to make. Because your reaction almost certainly had nothing to do with what I actually use it for, and everything to do with what you think “AI in music” means. And that gap — between the label on the box and what’s actually inside it – is the thing I want to talk about.
But I’ll get to the music. First, let me tell you what I mean by biologist.
Mathematicians, biologists, and the rest of us
In the AI world right now, there are broadly two kinds of people. There are the developers – the people who build the models, write the code, design the architectures. These are the mathematicians. They understand how the machine works at a fundamental level. They speak in parameters and tokens and training data. They are essential, and I am not one of them.
Then there is everyone else. The users. The people who interact with AI tools the way most people interact with electricity – you flip the switch, the light comes on, you don’t particularly need to know about the power station. That’s fine. Most people will live here, and there’s nothing wrong with it.
But there’s a third position that doesn’t get talked about much, and it’s where I’ve ended up. I’m not building the models. I’m not just using them either. I’m observing how they behave in the wild – in real businesses, in real workflows, in real creative processes – and I’m figuring out where they actually solve problems versus where they just create new ones. I’m studying AI the way a biologist studies an organism in its natural environment. Not in the lab. In life.
And yes the BSc in Biomedicine finally paid off. Just not in the way anyone expected.
The AI breakfast cereal problem
Here’s what happens with every major technology trend. A label gets created. The label gets marketed. The label gets shoved in front of business owners, directors, creative professionals, and everyone in between. And people have one of two reactions: they either grab the box off the shelf because they think they’re supposed to, or they leave it there because they’re afraid of what’s in it.
Almost nobody turns the box around and reads the ingredients.
AI is the label on the front of the box right now. It’s enormous. It’s everywhere. And it is causing people to have strong opinions about something most of them haven’t actually examined. The people who are excited about AI are often excited about a fantasy of what it might do. The people who are afraid of it are afraid of a fantasy of what it might replace. Very few people in either camp have sat down and asked: what is the specific problem in my specific work that this could help me solve?
That question – boring, practical, unsexy – is where all the value lives. And I know this because I watched exactly the same thing happen with BIM.
I've seen this film before. It was called BIM.
I’ve worked in the construction industry since the early days of what we now call Building Information Modelling. If you want to be precise about it, the story starts around BS 1192 and the push to digitise how building information was produced and managed. That was nearly two decades ago.
What happened was this. The industry was told it needed BIM. The label was everywhere – in government mandates, in client requirements, in trade press, in conference titles. Practices and contractors were told that if they didn’t adopt BIM, they’d be left behind. So they adopted it. They bought Revit. They paid for training. They hired BIM consultants. They put “BIM” on their websites and in their tender responses.
And then, overwhelmingly, nothing changed.
Oh, the output looked different. Models were in 3D instead of 2D. Drawings were generated from those models. It looked modern. It felt like progress. But the underlying problems – poor coordination, information that couldn’t be trusted, risks that surfaced on site because they weren’t managed during design, projects that bled time and money because nobody set them up properly at the start – those problems didn’t go anywhere. In many cases they got worse, because now they were hidden underneath a layer of professional-looking output that gave everyone the impression things were under control when they weren’t.
The reason was simple. The industry adopted the label without understanding the purpose. The purpose was never “use 3D software.” The purpose was to manage information so that buildings could be designed, built, and operated with less risk, less waste, and better outcomes. That’s a change in how a business operates. Most practices treated it as a software purchase.
If that sounds familiar to what’s happening with AI right now, it should. It’s the same pattern. Different technology, identical mistake.
What I actually do with Al in my music
When I’m not running DDC Solutions, I write electronic dance music. It’s been a part of my life for a long time, and it’s genuinely creative work – the kind of thing people assume AI threatens. So let me be specific about what I use AI for, because the specificity is the point.
I don’t use AI to generate music. I’m not typing “make me a deep house track” and publishing whatever comes out. That’s the version of Al in music that people argue about on the internet, and honestly, I think the only people who feel truly threatened by AI-generated music are the ones who would use it to replace their own creative process. If you need a machine to write your track, the issue isn’t the machine.
What I do is build my own tools. Small, specific, purpose-built plug-ins and workflows that solve problems I keep running into during production. Things that save me time on the technical side — the mixing, the processing, the repetitive problem-solving that eats into the hours I’d rather spend actually writing music.
Here’s the simplest way I can explain it: take a photo of your problem, describe it to your favourite chatbot, and it will help you build a solution. Add a bit of code and you can turn that solution into a tool that works every time you hit that same problem. A sentence becomes a solution. Not a perfect one. Not a commercial one. But one that works for you.
And that last part matters. These tools work for me because they were built for my problems. I take the risk of using them. I understand their limitations because I built them around my own workflow. I could not sell them to someone else, because someone else’s problems are different, and the tools would need to be understood, tested, and adapted for a context I can’t control. This is the biological reality of AI use – it’s context-dependent. What thrives in one environment doesn’t necessarily survive in another.
This is what people are getting wrong
The conversation about Al right now is happening almost entirely at the level of the label. Will AI replace musicians? Will AI replace architects? Will AI replace writers, designers, accountants, project managers?
These are the wrong questions. They are breakfast-cereal-box questions. They look at the front of the package and have an emotional reaction without ever turning it around.
The right questions are specific and boring. What is the actual task I spend too much time on? What is the technical problem I keep solving manually? Where am I losing hours to repetitive work that doesn’t require my creative or professional judgement? And could I build or use something that handles that, so I can spend my time on the work that actually needs me?
When you ask those questions, AI stops being a threat or a miracle and becomes what it actually is — a tool. A genuinely powerful tool, but a tool nonetheless. And like every tool, its value depends entirely on whether you understand the problem you’re using it for.
The parallel to what we do at DDC
This is the lens I bring to everything at DDC Solutions, Survey2Plan, and GIS Navigator. We’ve spent years helping businesses in the construction and surveying industries close the gap between “we bought the technology” and “the technology is actually protecting our business.” That gap is where the risk lives – and in our experience, it’s where most businesses are stuck without realising it.
The AI trend is heading down exactly the same path. Businesses are being told they need AI. Some are grabbing the box. Some are afraid of it. Very few are asking the practical question: what is the specific problem in our workflow that this could address, and what would it take to implement it in a way that actually works?
That question requires you to understand your own business first. It requires you to know where you’re losing time, where risks accumulate, where money leaks out through inefficiency rather than flowing to the work that generates value. No AI tool can tell you that. No developer can tell you that. You have to know your own environment – and then you can start to think about what might help.
This is why I call myself a biologist in this space. I’m not designing the organisms. I’m studying where they thrive, where they fail, and what conditions they need to actually deliver value. The lab is impressive. The real world is where it matters.
The point of all of this
I’m not selling AI. I’m not even recommending it – not in any generic sense. What I’m saying is that the way we talk about Al as a society is making it harder for people to benefit from it. The hype makes people either overcommit or retreat. The fear makes people defensive. And the labels – “AI-powered,” “AI-driven,” “AI-enabled” – tell you absolutely nothing about whether the thing in front of you will solve a problem you actually have.
The same was true of BIM. The same will be true of whatever comes after AI. Every generation gets a technology trend pushed on it, and every generation has the same choice: adopt the label, or understand the substance.
I chose the substance. In my music, it saved me hours I now spend writing instead of troubleshooting. In my businesses, it shaped how we help clients get real value from their investments instead of just owning the tools. In both cases, the starting point was the same – I looked at the problem, not the product.
That’s not a developer’s perspective. It’s not a user’s perspective either. It’s a biologist’s perspective. And I think it’s the one most people actually need right now.
I write this article the way I write music – I bring the ideas and the direction, and then I work with the tools available to me to produce the final version. This article was written with Claude. Not generated by it. I told it what I wanted to say, it helped me say it clearly. The thinking is mine. The polish is collaborative. That, in itself, is the point.
