Er hat einen Synthesizer gebaut – ohne eine einzige Zeile Code zu schreiben

Es gibt Menschen in meinem Umfeld, bei denen ich schon vorher weiß: Wenn die sich melden, kommt gleich etwas, das ich noch nicht kannte. Deniz Cesit ist so einer.

Kennengelernt habe ich ihn nie im echten Leben – unser Austausch läuft seit Jahren übers Internet. Angefangen hat es damit, dass er mir schrieb, er wolle zu einem meiner Songs ein Musikvideo machen. Mit künstlicher Intelligenz. Ich wusste zu diesem Zeitpunkt gar nicht, dass das in dieser Qualität überhaupt schon geht. Später hat er mir gezeigt, wie er live Kommandos an eine KI gibt und die daraufhin Dinge in seiner DAW erledigt. Auch das war für mich neu.

Er ist mir eigentlich immer ein Stück voraus, wenn es darum geht, was mit KI möglich ist. Und jetzt hat er wieder etwas gemacht, das ich so von niemandem sonst kenne: Er hat sich einen Synthesizer bauen lassen. Von KI-Agenten. Ohne selbst programmieren zu können.

Was da entstanden ist

Das Ding heißt SIRA und ist kein Spielzeug. Es ist ein Wavetable-/Hybrid-Synthesizer für Windows, als Standalone-Programm und als VST3-Plugin. Sechs Oszillatoren, dazu Granular- und Physical-Modeling-Engines.

Das für mich Spannendste sind die prozeduralen Naturklänge: Wind, Regen, Vögel, Grillen – alles rein mathematisch berechnet, kein einziges Sample. Und dann gibt es noch eine eingebaute KI-Steuerung, mit der man einen Sound in normaler Sprache beschreibt, woraufhin der Synthesizer sich selbst entsprechend einstellt.

Die Zahlen aus der Projektdokumentation, die Deniz mir geschickt hat:

• 438 Parameter, deren Wirkung maschinell geprüft wird
• 540 Werkspresets in 27 Kategorien
• 38 automatisierte Kerntests
• rund zwei bis drei Wochen vom ersten Spezifikationsstand bis zum heutigen Stand
• 0 Zeilen selbst geschriebener Code

Der letzte Punkt ist der eigentliche Hammer. Deniz kann kein C++. Er hat trotzdem ein Plugin, das er in seiner DAW benutzt.

Und jetzt der wichtige Teil: So einfach ist es nicht

Weil solche Geschichten gerne falsch verstanden werden, will ich das gleich klarstellen. Ich habe Deniz genau danach gefragt, und seine Antwort deckt sich mit dem, was in seinen Unterlagen steht:

Das funktioniert nicht mal eben schnell mit einem Prompt. Niemand tippt „Bau mir ein Plugin wie Serum" in ein Chatfenster und lädt zehn Minuten später eine Installationsdatei herunter. So läuft das nicht, nicht heute und nicht nächstes Jahr.

Was es stattdessen braucht: mehrere Tage. Oder zumindest mehrere Nachmittage, an denen man sich wirklich hinsetzt und strukturiert arbeitet. Deniz' Anspruch war von Anfang an hoch gegriffen – er wollte in Richtung aktueller Flaggschiff-Synthesizer wie Serum 2 gehen, das nachbauen und in Teilen vielleicht sogar besser machen. Und er ist ehrlich genug zu sagen, dass Serum in manchen Punkten immer noch vorne liegt. SIRA ist auch nicht fertig: Der Step-Sequencer ist noch in Arbeit, es gibt Bugs. Aber es ist benutzbar, und man kann damit richtig coole Sounds machen.

Für mich ist das genau die richtige Einordnung. Nicht „KI baut dir alles", sondern: Ein Mensch ohne Programmierkenntnisse kann sich so lange mit KI beschäftigen, bis ein professionelles Werkzeug dasteht. Vielleicht nicht ganz auf dem Niveau des Marktführers – aber deutlich in diese Richtung, und im Alltag verwendbar.

Warum mich das mehr interessiert als jeder KI-Song

Wenn über KI in der Musikproduktion geredet wird, geht es fast immer um dasselbe: Man lässt sich von Suno einen fertigen Song machen. Darüber habe ich selbst genug geschrieben, und es ist auch ein spannendes Feld.

Aber das ist eben nur eine einzige Stelle, an der KI in unseren Beruf hineinreicht. Deniz zeigt eine ganz andere: Man kann sich mit KI die Werkzeuge bauen, mit denen man Musik macht.

Und da wird es aus meiner Sicht erst richtig interessant. Denn im Optimalfall baust du eben nicht eine etwas schlechtere Version von Serum. Im Optimalfall hast du eine ganz eigene Idee – einen Synthesizer, den es in dieser Form noch gar nicht gibt, der andere Sounds macht oder Möglichkeiten hat, die kein Hersteller anbietet, weil sich der Markt dafür nicht lohnt. Für dich lohnt er sich aber. Du bist ja der Markt.

Diese Tür stand bis vor kurzem nur Programmierern offen. Jetzt steht sie allen offen, die bereit sind, ein paar Nachmittage zu investieren.

Wenn du an dieser Stelle sagst: „Schön zu wissen, aber ich baue mir sicher keinen Synthesizer" – dann ist die Geschichte hier zu Ende, und ich hoffe, sie hat dich unterhalten.

Für alle anderen kommt jetzt der Teil, den ich eigentlich am wertvollsten finde. Ich habe Deniz gebeten, seinen kompletten Arbeitsablauf aufzuschreiben, damit ihr nicht bei null anfangen müsst, sondern seine Erfahrung mitnehmen könnt. Das hat er getan – ausführlich. Alles Folgende stammt aus seiner Dokumentation.

Der Workflow: Wie so etwas wirklich entsteht

Vorweg der eine Satz, auf den sich alles zusammendampfen lässt:

Eine KI baut, andere KIs prüfen unabhängig, der Mensch entscheidet und hört ab.

Deniz ist in diesem Projekt nicht der Programmierer. Er ist Auftraggeber, Produzent und Qualitätsinstanz in einem. Das ist eine Rolle, die jeder Musikproduzent sofort versteht – es ist im Grunde dieselbe, die du gegenüber einem Studiomusiker hast.

1. Erst die Spezifikation, dann der Code

Am Anfang von SIRA stand kein Code, sondern ein Lastenheft: am Ende 294 nummerierte Anforderungen, davon 260 als MUSS markiert – von der Audio-Engine über die Bedienoberfläche bis zur Sicherheit der KI-Schnittstelle.

Das ist der Punkt, an dem die meisten Leute es falsch machen. Sie fangen mit einem Chatverlauf an und wundern sich, dass die KI in Woche zwei nicht mehr weiß, was in Woche eins besprochen war. Ein geschriebenes Dokument ist die Quelle der Wahrheit, nicht der Chat.

Interessant finde ich, wie Deniz zu so einer Spezifikation kommt: oft per Sprache statt Tastatur. Wenn er länger im Auto sitzt, diskutiert er das Konzept per Voice-Chat mit einer KI – laut denken, Ideen durchspielen, verwerfen. Zu Hause lässt er sich das Ganze zusammenfassen und in eine Spezifikationsdatei gießen. Aus lockerem Brainstorming wird so ein belastbares Dokument.

Dazu kamen bei SIRA zwei weitere Dokumente: ein Masterprompt, der der KI ihre Rolle zuweist („Principal Audio-DSP Engineer, C++-Architekt, Test- und Release-Engineer"), und eine UI-Referenz.

2. Die Oberfläche kommt vor der Engine

Diese UI-Referenz ist ein Kniff, den ich mir gemerkt habe. Deniz hat sich das Design der Oberfläche mit Claude Design direkt aus der Spezifikation als klickbare Vorlage entwerfen lassen und so lange nachjustiert – „die Anordnung gefällt mir nicht", „das Modul kommt noch dazu" –, bis das Grundgerüst stand.

Das Ergebnis sieht aus wie die fertige App und lässt sich anklicken, nur die Engine dahinter existiert noch nicht. Genau dieses Gerüst bekommt die KI dann als verbindliche Vorgabe: Die Engine muss exakt diese Regler mit exakt diesen Namen bedienen. Damit ist von Anfang an klar, worauf alles hinausläuft.

3. Das Cockpit: VS Code und drei KIs, die sich gegenseitig kontrollieren

Deniz arbeitet nicht in den Webseiten der KI-Anbieter, sondern in Visual Studio Code – dem kostenlosen Editor von Microsoft. Der Trick dabei: In VS Code laufen mehrere Terminal-Fenster nebeneinander, und in jedem sitzt ein anderer KI-Agent.

Diese Agenten sind Kommandozeilen-Programme, die direkt auf das Projekt zugreifen: Dateien ändern, Tests ausführen, Programme kompilieren. Das ist ein anderer Schnack als ein Chatbot, der Codeschnipsel ausspuckt, die man selbst irgendwo hineinkopiert.

Er hat bewusst bei allen drei großen Anbietern ein Abo und verteilt die Rollen so:

• Claude Code (Anthropic) ist der Planer und Konzeptersteller. Er macht aus den Anforderungen Spezifikationen und Implementierungspläne und koordiniert die Arbeit. Für große Aufgaben startet er Schwärme von Unteragenten – bei SIRA zum Beispiel sechs parallele Fach-Reviewer für eine Spezifikation oder drei Klang-Designer plus drei kritische Gegenprüfer für die Tiergeräusch-Modelle.
• Codex / GPT (OpenAI) übernimmt Implementierung und Prüfung: Er bekommt den Plan und schreibt den Code danach – oder er kontrolliert als unabhängiger Prüfer, ob wirklich alles umgesetzt wurde.
• Gemini (Google) macht Review und Bug-Suche. Die unabhängige Zweitmeinung, ein dritter Blickwinkel mit anderen Stärken und anderen blinden Flecken.

Warum drei verschiedene Anbieter? Weil jede KI eigene blinde Flecken hat, aber selten dieselben. Eine KI, die ihren eigenen Code prüft, ist wie ein Schüler, der seine eigene Klassenarbeit korrigiert.

Wie wichtig das ist, zeigt der Verlauf bei SIRA: Zwei getrennt beauftragte externe Audits kamen zunächst zum Urteil „nicht releasefähig" – mit einer priorisierten Mängelliste, die anschließend in 35 dokumentierten Durchgängen abgearbeitet wurde. Ohne diese Audits wäre ein Synthesizer erschienen, der auf dem Papier fertig aussah und in der Praxis voller Fehler steckte.

Die Agenten laufen dabei auch in Schleifen, in denen sie sich gegenseitig prüfen und verbessern. Entscheidend ist dabei ein klar definierter Endpunkt – ein messbares Ziel, bei dem die Schleife stoppt.

Achtung, Kostenfalle: Ohne definiertes Ziel diskutieren sich die Experten-KIs im Kreis. Die Schleife kann tagelang laufen, ohne dass etwas passiert – und verbrennt dabei nur Guthaben. Sag immer dazu, woran die KI erkennt, dass sie fertig ist.

4. Versionierung: die Rückgängig-Taste für KI-Fehler

Das Werkzeug heißt Git, die dazugehörige Plattform GitHub. Git speichert jeden Arbeitsstand als „Commit" – im Grunde wie Speicherpunkte in einem Videospiel, GitHub legt sie zusätzlich in der Cloud ab.

Für einen KI-Workflow ist das aus vier Gründen wichtig:

• Rückgängig machen. Wenn ein Agent etwas kaputt macht, springst du zum letzten funktionierenden Stand zurück. Ohne Versionierung ist ein KI-Fehler ein Totalschaden, mit Versionierung eine Fußnote.
• Nachvollziehbarkeit. Die Historie zeigt, welcher Agent wann was geändert hat. Nur so lässt sich ein Fehler überhaupt eingrenzen.
• Automatische Prüfung. GitHub kann bei jedem hochgeladenen Stand die Tests selbst ausführen. Ein Stand, der durchfällt, fällt sofort auf – egal wie überzeugend die KI behauptet, alles sei fertig.
• Reviews. Änderungen lassen sich bündeln und von einem Menschen oder einem zweiten KI-Modell lesen, bevor sie in den Hauptstand wandern.

Ehrlicherweise lief SIRA selbst nur lokal mit Git, ohne GitHub – bei einem Solo-Projekt auf einem Rechner geht das. Sobald aber etwas veröffentlicht werden soll oder mehr als ein Rechner beteiligt ist, führt kein Weg daran vorbei.

5. In Scheiben bauen – und jede Scheibe selbst anhören

Das oberste Arbeitsprinzip stand wörtlich im Lastenheft:

„Kein unsichtbarer Fortschritt. Jeder implementierte Vertical Slice muss als startbarer Build live, hörbar, bedienbar und reproduzierbar geprüft werden können."

Ein „Vertical Slice" ist eine kleine, in sich abgeschlossene Ausbaustufe, die man einzeln bauen und einzeln testen kann. Bei einem Synthesizer zum Beispiel: erst überhaupt ein Ton, dann ein Oszillator mit Reglern, dann der Filter, dann die Hüllkurve.

Ein Slice galt erst als fertig, wenn Deniz ihn selbst gestartet, gehört und ausdrücklich abgenommen hatte. Kein „müsste eigentlich funktionieren", kein „kompiliert ja". Wenn er es nicht hören konnte, existierte es nicht.

6. Das Sicherheitsnetz: nichts glauben, alles ausführen

Jetzt kommt der unbequemste Teil der Wahrheit über KI-Coding, und der gilt genauso für alles andere, was du mit KI machst: KIs behaupten Dinge. „Alle Tests grün" – und es wurden nie Tests ausgeführt. „Fertig implementiert" – und der Regler ist mit nichts verbunden. Wer sich auf die Selbstauskunft der KI verlässt, baut auf Sand.

Deshalb läuft bei Deniz in jedem Projekt ein selbstgebautes Kontrollsystem mit, das er Ship-Gate nennt. Der Grundgedanke: Nichts wird geglaubt, alles wird ausgeführt.

• Echte Testausführung. Vor dem Abschluss jedes Arbeitspakets läuft ein „Gate", das Tests, Prüfprogramme und den Build wirklich startet und die Ergebnisse als Nachweis ablegt. Eine KI kann nicht mehr behaupten, getestet zu haben.
• Scope-Verträge. Jedes Arbeitspaket erklärt vorher, welche Ordner es anfassen darf. Ändert die KI etwas außerhalb, schlägt das Gate an. Das verhindert das klassische KI-Problem, dass nebenbei noch fünf andere Stellen umgebaut werden.
• Secret-Scan. Vor jedem Speicherpunkt wird geprüft, ob Passwörter oder Zugangsschlüssel im Code gelandet sind – einer der häufigsten und teuersten Anfängerfehler.
• Zweitmodell-Review bei Risiko. Änderungen an heiklen Stellen müssen von einem anderen KI-Modell gegengelesen werden, bevor sie durchgehen.
• Go-Live-Gate. Vor einer Veröffentlichung prüft die Maschine eine harte Checkliste – von Impressum und Datenschutz bis zur Frage, ob eine Sicherung nachweislich wiederherstellbar ist. Jeder nicht bestandene Punkt blockiert.

Der Tagesablauf mit diesem System ist immer derselbe: Verhören → Spezifizieren → Bauen → Gate. Erst wird die Idee in einem Frage-Antwort-Verhör so lange auseinandergenommen, bis nichts Vages mehr übrig ist. Dann entsteht daraus eine Spezifikation. Dann baut der Agent, wobei der Test vor dem Code kommt. Und am Ende entscheidet nicht die KI, ob etwas fertig ist, sondern das Gate.

7. Was der Mensch macht, wenn die KI baut

Bleibt die naheliegende Frage: Wenn KIs schreiben, testen und prüfen – was macht dann noch der Mensch? Deniz' Antwort: alles, was keine KI kann und keine KI dürfen sollte.

• Produktentscheidungen. Was gebaut wird, in welcher Reihenfolge, was rausfliegt. Die KI schlägt vor, entschieden wird von ihm.
• Abnahme mit den Ohren. Jeder Klang, jedes Preset, jedes Feature wird persönlich gehört und freigegeben. Bei den Naturklängen lief das als Schleife: Die KI baut ein Vogelmodell, er hört es an, sagt „die Grille klingt nach Rauschen, nicht nach Ton", die KI korrigiert das mathematische Modell, er hört wieder. So lange, bis es stimmt. Kein Messwert der Welt ersetzt das Ohr.
• Konflikte entscheiden. Wenn Prüfer und Erbauer sich widersprechen – und das passiert regelmäßig –, sieht er sich die Belege an und entscheidet, wer recht hat.
• Die Notbremse. Riskante Aktionen wie Dateien löschen, etwas veröffentlichen oder Geld ausgeben bestätigt immer ein Mensch.

Was schiefging – und warum das der lehrreichste Teil ist

Der Workflow klingt bis hierhin ziemlich glatt. War er nicht. Deniz hat mir fünf Fälle aufgeschrieben, und ich finde, aus denen lernt man mehr als aus jeder Erfolgsgeschichte.

103 Regler, die nichts taten. Ein Audit fand heraus, dass 103 Parameter der Oberfläche unter bestimmten Bedingungen keinerlei hörbare Wirkung hatten – ein zentrales Bedienelement war schlicht nie mit der Engine verbunden worden. Optisch alles da, funktional eine Attrappe. Die Lösung war nicht, 103 Fälle einzeln zu reparieren, sondern ein maschinell geprüfter Parameter-Vertrag: Ein Test dreht seitdem jeden einzelnen der 438 Regler und misst, ob sich das Audiosignal ändert. Diese Fehlerklasse ist damit dauerhaft ausgestorben.

Die KI-Prüfer irren sich auch. Etliche Befunde aus den Reviews stellten sich bei der Nachprüfung als schlicht falsch heraus. Daraus wurde eine eiserne Regel: Kein Prüfbefund wird umgesetzt, bevor er nicht unabhängig verifiziert ist. Sonst repariert man funktionierenden Code kaputt. KI-Audits sind Hinweise, keine Urteile.

Die Cloud verfälschte die Messungen. Wochenlang schwankten die Leistungsmessungen unerklärlich um den Faktor zwei. Schuld war die OneDrive-Synchronisation, die im Hintergrund den Projektordner hochlud und dabei Rechenlast erzeugte. Seitdem gilt: Sync aus, Maschine ruhig, nur direkte Vergleiche zählen. Wer misst, muss zuerst seiner Messung misstrauen. (Nebenbei ein guter Grund, Projektordner grundsätzlich nicht in OneDrive oder Dropbox zu legen – das gilt für DAW-Projekte genauso.)

Der Dauertest fand, was alle Kurztests übersahen. Ein 30-minütiger automatischer Dauerlauf förderte zwei echte Datenverlust-Fehler zutage, die in keinem der Kurztests aufgetaucht waren – darunter automatische Sicherungen, die fehlerhaft gespeichert wurden. Kurztests prüfen, ob etwas funktioniert. Dauertests prüfen, ob es funktionieren bleibt.

„Mach es dunkler" machte es heller. Die Sprachsteuerung verstand „dunkler" als absolute Zielvorgabe statt als relative Änderung – dunkle Sounds wurden dadurch heller. Solche Denkfehler findet kein Test, sondern nur ein Mensch, der das Ergebnis wirklich benutzt.

Der komplette Ablauf in zwölf Schritten

Wer das Ganze auf einen Zettel schreiben will, hier die Kurzfassung:

1. Idee verhören. Die Produktidee mit der KI auseinandernehmen: Für wen? Was genau? Was ausdrücklich nicht? Erst aufhören, wenn nichts Vages mehr übrig ist.
2. Spezifikation schreiben. Als Lastenheft festhalten – nummerierte Anforderungen, MUSS und KANN getrennt, plus eine Liste dessen, was ausdrücklich nicht gebaut wird.
3. UI-Referenz festlegen. Das Wunsch-Design als klickbare Vorlage bauen lassen und für verbindlich erklären, inklusive der exakten Namen aller Bedienelemente.
4. Werkzeuge aufsetzen. VS Code, Git, die KI-Agenten und ein Kontrollsystem. Echte Prüfbefehle konfigurieren, keine Platzhalter.
5. In Scheiben schneiden. Das Projekt in kleine, einzeln baubare und einzeln prüfbare Ausbaustufen zerlegen.
6. Testgetrieben bauen lassen. Der Test kommt vor dem Code, das Gate führt am Ende alles wirklich aus.
7. Mit den Sinnen abnehmen. Jede Stufe selbst starten, benutzen, anhören. Was der Mensch nicht abgenommen hat, ist nicht fertig.
8. Unabhängig prüfen lassen. An Meilensteinen fremde Modelle mit eigenem Prüfauftrag auf das Projekt loslassen.
9. Befunde systematisch abarbeiten. Befund → Test, der fehlschlägt → Reparatur → Test, der durchläuft.
10. Härten. Dauertests, Leistungsmessungen unter sauberen Bedingungen, Belastungsproben.
11. Nachweise sammeln. Die Veröffentlichungs-Checkliste maschinell prüfen lassen, nicht selbst versichern.
12. Veröffentlichen – und weiterhören. Jede weitere Änderung durchläuft denselben Kreislauf.

Zum Selbst-Ausprobieren: das Starter-Paket

Grau ist alle Theorie. Deshalb haben Deniz und ich ein Starter-Paket geschnürt, mit dem du diesen kompletten Workflow einmal selbst durchspielen kannst – ohne Programmierkenntnisse, in ein paar Nachmittagen.

Gebaut wird dabei nicht SIRA, sondern eine kleine Browser-App namens NATURA: ein Naturklang-Generator für Musikproduktionen. Regen, Wind, Gewitter und Vögel, komplett ohne Samples aus purer Mathematik erzeugt, frei mischbar, als Szene speicherbar und als Loop für die eigene Produktion exportierbar. Dieselbe Technik wie die Naturklänge in SIRA, nur eine Nummer kleiner. Nebenbei bekommst du dabei etwas, das dir im Studio tatsächlich nützt: eigene Atmosphären ohne jede Lizenzfrage.

Im Paket sind vier Dinge:

• eine fertige Spezifikation für die App – das Lastenheft, das du deiner KI vorlegst
• ein fertiges UI-Design als klickbare HTML-Vorlage, die als verbindliche Vorgabe gilt
• das komplette Ship-Gate-System zum Entpacken in dein Projekt
• eine deutsche Schritt-für-Schritt-Anleitung vom leeren Ordner bis zur laufenden App

Du brauchst dafür einen Rechner, VS Code und mindestens einen KI-Agenten – Claude Code, Codex oder Gemini, bei allen dreien gibt es Einstiegskontingente. Für den Anfang reicht einer. Wer zwei installiert, kann den zweiten als unabhängigen Prüfer einsetzen, so wie oben beschrieben.

Deine Aufgabe: Gib der KI die Spezifikation und das UI-Design, arbeite in Scheiben, nimm jeden Schritt selbst ab – und bau die App, ohne eine Zeile Code selbst zu schreiben.

Starter-Paket herunterladen (ZIP)

Kleiner Hinweis vorweg: Leg deinen Projektordner nicht in OneDrive oder Dropbox. Die Hintergrund-Synchronisation stört die Prüfläufe – siehe oben, das hat Deniz Wochen gekostet.

Zwei Bitten zum Schluss

Die erste geht an alle: Wenn du das Starter-Paket ausprobierst, schick mir gern dein Ergebnis – als Link oder ZIP, mit ein paar Sätzen dazu, was gut lief, wo die KI danebenlag und was du bei der Abnahme zurückgewiesen hast. Ich leite das an Deniz weiter, und die spannendsten Erkenntnisse fließen in kommende Beiträge ein. Für Fragen zum Workflow gilt dasselbe.

Die zweite ist konkreter und kommt von Deniz selbst: SIRA soll den Schritt vom Projekt zum fertigen Produkt machen, und dafür sucht er Verstärkung. Wer Erfahrung mit Software-Lizenzierung, Code-Signierung und Release-Builds mitbringt oder weiß, wie man Software erfolgreich vermarktet und verkauft, darf sich sehr gerne bei mir melden – ich stelle den Kontakt her. Wer ihm lieber direkt schreibt: Deniz ist auf Instagram als @denizvibez unterwegs.

Und ganz unabhängig davon, ob du jetzt anfängst, dir Werkzeuge zu bauen: Ich finde, diese Geschichte ist eine der interessantesten, die mir in letzter Zeit zum Thema KI untergekommen ist. Nicht weil eine Maschine Musik gemacht hätte. Sondern weil jemand ohne jede Programmiererfahrung sich das Werkzeug gebaut hat, mit dem er Musik macht. Das war vor drei Jahren schlicht nicht möglich.