To kick things off in a very unlikely way, let me introduce the CZP-1, a software implementation of phase distortion synthesis as a complete instrument on a web page.
Using the CZP-1 you could . . .
. . . and whatever else you may think of.
“Phase Distortion Synthesis” is the sound generation process Casio came up with in the early 1980s, and put in products such as the CZ-101. I’ve never knowingly even been near a CZ series synthesizer but have always wanted to play with a phase distortion synth, so what’s a developer in 2026 going to do? Build one with agents, obviously.
No, this wasn’t one shot vibe coded. If you do that it won’t sound quite right, and the UI will suck horribly, but it gets you a surprisingly long way. The question with these things is how to make them usable by other people and finish them.
Go to the web page and turn it on. Then touch the keys, or use your computer keyboard to play some notes.
If you don’t hear anything your volume might be turned down or your phone might be in silent mode.
Sounds are organised into banks (groups of sounds) and programs (individual sounds) in the Library panel. The existing bank of “Factory Presets” should be selected, and different sounds in there show some of the potential.
So you’ve made a cool sound and you want your friend to be able to use it . . . no problem! You can send a web link to a CZP-1 with your particular sound. Here’s one I made earlier.
Copy/paste into your preferred messenger, store them in documents, whatever. The data for the sound is in the actual link, there’s nothing on any server.
The MIDI support should be easy enough for anyone familiar with MIDI, which enables the use of external keyboards or driving it from a sequencer. There is pedal and wheel support mapped to the usual controllers. The expression pedal affects the velocity sensitive aspects of the program.
For more details on absolutely everything else check the CZP-1 Manual
Having tried, and aborted, several audio projects over the years, I had come to regard it as one of the hardest fields in programming; a suitable test for the current fad of agentic programming then
My working process involves bouncing various agents off against each other. (At least Claude Code, DeepSeek in Pi and Codex were all used). For whatever reason they seem to have mutually exclusive blind spots so that this leads to iterating towards a far more successful result than any will achieve independently.
I started by prompting Claude to implement a phase distortion synthesizer in JavaScript on a web page. That first effort was surprising, including that it decided to use browser automation to compare the audio output with reference audio it got from . . . somewhere. The problems were it didn’t sound right, the parameters were being misinterpreted, and the user interface sucked. But it did actually kind of work, even with the incredible wonky presets Claude hallucinated in place.
Consequently I bounced it to DeepSeek with comments about the audio engine Claude had written, and it went off did a load of research and managed to establish various aspects of the fundamental waveforms were wrong, the mixing functions were wrong, etc. and completed a pass correcting them.
This bouncing back and forth carried on for about a week, with them progressively mining basically every source of information on the subject of implementing phase distortion synthesis iterating ever closer towards a position neither could meaningfully improve on.
This is what led to the audio engine actually working as it is now, with less than a handful of highly specific interjections.
But then there is the whole user interface and piles of user facing features, like polyphony (the ability to play multiple notes at once), modulation, legato sliding with portamento. All of these have to be individually talked through, designed, implemented and debugged as appropriate. None of that was automatic, and often knowing the precise algorithm to use, such as round robin allocation of voices for polyphony, and prompting for exactly that was necessary to finish the feature.
The big lessons were:
If I were to do this again I’d have the manual in progress from the moment UI work starts as it proved to be a useful point for maintaining conceptual consistency.
To emphasise how insane the low level work situation is, while doing this I was being surprised and as a test decided to port the web games I did at Luduxia from their custom hand written WebGL2 renderer to WebGPU - a task I had procrastinated over due to iOS Safari among other things. This was completed with agent assistance and deployed inside a fairly relaxed 24 hours. The more familiar you are with WebGL and WebGPU the more shocking that is. (As part of the work on CZP-1 the Luduxia build system was itself actually ported by agents and it is that which performs the final build of the synth).
We live in a new age where knowing low level stuff is useful for design purposes but you will be outgunned by the machines when it comes to implementation. Fighting that trend is just the road to a lot of pain, but it’s going to upset a lot of people.
There’s a lot of great inspiration to take from 80s synthesizers, such as the cross vendor MIDI interoperability, the ability to represent and generate interesting sounds using tiny amounts of memory and relatively little compute, and faith that users will learn something complex and esoteric if it’s going to help them achieve their goals or just have fun. Hopefully there will be more on that another time.