Does Coding Matter Anymore? Audio Programming in the AI Age (Sonic Lab) | Ep 39

Three Things You Can Take Away From This Episode

• AI can write the code, but it can’t hear. Your ears, taste and iteration are still what make the product.
• Prototype and validate an idea before you port it, and move the visual design forward alongside the sound engine.
• Cross-check your AI models against each other, and act the moment something feels wrong.

Sinan Bokesoy has been building audio software for more than 15 years, from the early days of Cosmosf to the sonicLAB instruments he now develops with Daito Manabe. These days he barely writes code himself. Claude, Codex and Gemini do most of it. Yet his latest instrument still took 18 months to finish.

In this episode, Sinan walks Josh through how his workflow has actually changed, where AI saves him time, where it doesn’t, and why he thinks audio developers have less to fear than they might assume.

If you’re trying to work out what AI means for how audio software gets made, this is an honest look from someone deep in it.

1. The Audio Developer Is an Artist First

Sinan didn’t come to programming through computer science. He studied computer music research and contemporary composition, starting with Csound, then Max/MSP during his PhD, and finally C++ when he needed to build the instruments he could hear in his head.

That background shapes how he sees the job. For him, an audio developer isn’t just writing software. They’re designing an instrument, testing the sound, building presets with a small team and handing an idea to other artists in a form they can play.

Coding, in that picture, is only a fraction of the work. It’s the glue that makes the idea real. He doesn’t underestimate it, but he doesn’t overestimate it either.

2. From Chiselling Snippets to Directing Agents

Sinan dates the shift to 2023. Back then, he was asking ChatGPT for individual C++ classes in the browser and pasting them into his JUCE project. Context windows were tiny and hallucinations were common. He compares it to chiselling a project one snippet at a time.

Agentic tools changed that. Now he directs coding agents at the system level. They handle larger, more complex changes and hand back results for him to test and iterate on, often without him writing any code at all.

He’s clear about what this did and didn’t replace. He and Daito have always worked as a two-person team, sharing concepts and building separately, so nobody was let go. AI took over his coding. The design, the concept and the decisions are still his.

3. Why an AI-Built Instrument Still Took 18 Months

His latest instrument simulates a spiking neural network that processes live audio. He prototyped it in Unity, then decided it needed to be a plugin in the DAW. At that point Claude ported the whole project to JUCE and took over the coding.

It still took 18 months. The instrument didn’t exist before, so it needed countless rounds of design, evaluation and change. The code came quickly. Checking whether it actually worked, at the level of fractions of a second, didn’t.

The core reason is simple: AI can’t hear. It can write anti-aliasing tables and good-sounding filters, but it can’t make the musical judgement that tells you whether the whole instrument works. That takes years of ear training, and FFTs and measurement tools can’t replace it. For Sinan, the real sign of success is a comment under a product video saying it just sounds fantastic.

4. Prototype Before You Port

Sinan never jumps straight into a JUCE build. He validates the idea first. That used to mean a quick Max patch. Now it might be a web prototype built with Web Audio and WebGL, like Terraform, a project he’s working on that turns the Earth’s geodesic data into waveforms.

The reasoning is practical. Getting to the first sound with working sliders in JUCE can take a long time, and you don’t want to discover then that the idea doesn’t hold up.

He also moves the visual design forward in parallel with the sound engine, rather than finishing one before starting the other. He sketches controls in simple tools, shares them with the AI and asks it to build that button or that slider. Because iterating is cheap now, he can try things and throw them away freely until something fits.

5. Cross-Validate Your Models

Sinan doesn’t rely on a single model. He uses Claude, Codex and Gemini because he finds they have different strengths. A typical pattern is to build with one, then bring in another to review the whole project and feed its comments back.

Gemini has proved particularly good at tracking down bugs from crash reports. He’s seen it find problems another model spent 40 or 50 minutes stuck on.

He also stresses speed of response. AI-written code can introduce bugs, and a bug isn’t always a crash. If a visualisation suddenly drops from 60 to 20 frames per second, you have to act straight away. Keep iterating on top of the problem and you lose control of it. And he won’t crown a favourite model, because the rankings can change in two months.

6. Testing Is Still Your Job

Sinan no longer reviews his JUCE code line by line, though he still does on Unity projects from time to time. What he does care about, intensely, is that his products don’t crash.

Every sonicLAB product passes pluginval at its strictest level, but he doesn’t treat that as the whole story. The real test is preset design. He works with sound designers who are music producers themselves and who have to learn a brand-new engine from scratch. That phase shows what the instrument can do and what’s missing, and it can take at least two months before he’s happy nothing has crashed for a month.

Even then, version 1 is never perfect. What matters is fixing crash reports quickly, so the next update is solid.

7. Unity Visuals Inside JUCE

Some of sonicLAB’s most striking visuals live in Unity, because building 3D scenes in raw OpenGL means a heavy load of boilerplate, and JUCE has no 3D framework out of the box. Users kept asking for those instruments as plugins, not standalone apps.

Sinan’s solution was to export the Unity interface as a web app and run it inside JUCE through WebView, with the sound coming from JUCE. It worked first time with Oceanic, and he plans to use the technique on more products.

Porting an existing engine is easier for AI because the code already exists. But he’s firm that you can’t just hand over a Unity project and ask for a JUCE version. He works step by step: interface first, then the parameter tree and automation in the DAW, then the audio engine, then careful listening to check it still sounds right.

8. One Prompt Won’t Make a Product – and It Isn’t Free

Sinan doesn’t believe a real audio product can come from a single prompt, however often social media suggests otherwise. He poses a thought experiment. A future model with perfect computer use could perhaps open Serum 2 and its manual and build a clone. But with thousands of plugins out there, and most developers working hard not to copy each other, what would be the point?

He also points to cost. Anyone building a serious instrument with coding agents will quickly outgrow a $20 monthly plan and end up paying $200 a month, possibly for months. For producers building tools for their own work, he thinks it’s wonderful. As a route to a business, it’s a different story.

Being an audio developer is a full-time profession in a competitive market. Version 1.0 isn’t enough. You need updates, maintenance, support and more products after it.

9. Learn to Fly the Plane

Sinan thinks AI is more useful to senior developers than to beginners, because beginners need to make mistakes to learn. He describes his first product as years of learning from exactly those mistakes.

His analogy is the difference between a modern electric car and an airliner. You can drive the car with almost no knowledge of the engine. A pilot needs to understand aerodynamics and hundreds of controls. He wants young audio developers to aim to become pilots, with the sky as the limit rather than the prompt. Josh adds his own comparison: we have calculators, but we still learn maths by hand.

Sinan also urges newer developers to get close to real music production – studios, engineers, hardware – because that experience stays with you for life and no model can supply it. AI, meanwhile, makes an excellent tutor for learning C++ or Python.

Closing

Sinan closes on the composers of the 18th and 19th centuries, who made an enormous body of lasting work in short lives with little more than a pen, paper, candlelight and a piano. He hopes AI can clear away some of the friction that buries creative people today, rather than replace the creative work itself.

What ties the conversation together is that the value still sits with the developer. Each iteration is a fingerprint on the work, and audiences can feel the difference between a carefully directed instrument and something a model produced on its own.

‍