MusicMaker: Wenn ich einen Workflow aufschreiben kann, kann ich ihn automatisieren

Wie aus einem beschreibbaren Prozess ein Werkzeug wurde, das auf Knopfdruck eine virtuelle Band samt Album baut — und was ich beim Bauen über die Grenzen und Hebel solcher Automatisierung gelernt habe.
Summary
Die Geschichte dazu — das KI-Album von 2024, die virtuelle Pop-Band Merida’s Waves und die Frage, was uns generative KI in der Musik bringt und nimmt — habe ich im Beitrag „Selbstversuch Reloaded: Wie lange dauert es mit KI zum Music Producer zu werden?” erzählt (zuerst auf LinkedIn, 2. Mai 2026). Diesen Artikel hier möchte ich nicht mit der Erzählung füllen, sondern mit dem Werkzeug dahinter: MusicMaker. Die tragende Idee ist schnell gesagt — und sie ist der eigentliche Punkt: Wenn ich einen Workflow klar aufschreiben kann, kann ich ihn auch mit KI automatisieren. Das Resultat dieser Überzeugung ist MusicMaker, eine App, die aus wenigen Stichworten eine komplette Band mit Debüt-Album erzeugt. Im Folgenden beschreibe ich, was das Werkzeug ist, wie es aufgebaut ist — und vor allem, welche Lektionen ich beim Bauen mitgenommen habe. Dazu gehört auch ein ehrlicher Wermutstropfen: Suno bietet keine offene Schnittstelle, ein bisschen Hin-und-her- Kopieren bleibt also. Ohne diese eine Nahtstelle ginge es noch deutlich schneller.
1. Die Grundidee: ein beschreibbarer Prozess ist ein automatisierbarer Prozess
Fangen wir mit dem Gedanken an, der alles ausgelöst hat. Als ich 2024 mein erstes KI-Album baute, war das „AI-augmented”, aber echte Stundenarbeit: Konzept entwickeln, Tracklist verfeinern, Lyrics iterieren, Suno-Prompts tunen, Cover separat erzeugen, alles zusammenführen. Mühsam — aber, und das ist entscheidend, ein klar benennbarer Ablauf. Jeder Schritt hatte einen Input, einen Output und eine Entscheidung dazwischen.
Und genau da liegt der Hebel. Was wäre, wenn die Tatsache, dass ich diesen Prozess sauber aufschreiben kann, schon die halbe Automatisierung ist? Ein Workflow, den ich in Worte fassen kann — „nimm die Stichworte, leite daraus eine Bandidentität ab, daraus ein Albumkonzept, daraus die Tracks …” —, ist ein Workflow, den auch eine Maschine abarbeiten kann. Die KI liefert dabei nicht den Prozess, sondern die kreative Füllung der einzelnen Schritte. Den Ablauf gebe ich vor.
Das ist dieselbe Überzeugung, die meinen Schwerpunkt Prozessautomatisierung trägt, nur auf ein ungewöhnliches Feld angewandt. Aus ihr ist an einem Wochenende MusicMaker entstanden — der Versuch, den früher manuellen Album-Prozess vollständig in eine Pipeline zu gießen.
2. Was MusicMaker ist — in zwei Sätzen
Damit der Aufbau verständlich wird, kurz das Ergebnis: MusicMaker verwandelt wenige Stichworte in ein vollständiges Konzeptalbum. Aus dem minimalen Input entstehen eine Band mit Identität, Logo und Bandfoto, ein Albumkonzept mit Tracklist, pro Track Lyrics und Musik, ein Cover und am Ende ein distributortaugliches Release-Paket.
Wie sich das anfühlt und was dabei herauskam — die Pop-Band Merida’s Waves mit ihrem Album „After the last Bell”, das kurz darauf auf Spotify stand —, lesen Sie im verlinkten Originalbeitrag. Hier interessiert die Mechanik darunter.
3. Der Aufbau: eine geschichtete Pipeline mit klaren Verantwortlichkeiten
Der entscheidende Schritt von „Idee” zu „Werkzeug” ist die Struktur. Ein Prozess, der automatisiert werden soll, muss in saubere, einzeln verantwortliche Teile zerlegt werden — sonst entsteht ein unwartbarer Knäuel. MusicMaker ist deshalb streng geschichtet, mit Abhängigkeiten nur von oben nach unten:
UI (Streamlit) → dünn, fast logikfrei
Pipelines → Band · Album · Release
Engines → Concept · Lyrics · Music · Cover · Band · Release
API-Clients → Anthropic · OpenAI Images · Suno (je hinter Interface)
Storage / Datenmodell → Pydantic-Objekte, atomare Schreibvorgänge
Filesystem → bands/<slug>/…
Das Datenmodell folgt der Sache selbst: Band → Album → Track. Die Band ist die oberste Entität mit eigener Stil-DNA; jedes Album erbt deren Stil, jeder Track wird mit Lyrics, Musik-Generierung und Clip-Auswahl einzeln festgehalten. Drei Kern-Pipelines orchestrieren den Ablauf — eine für die Bandidentität, eine für das Album, eine für das Release mit Audio-Mastering, Cover-Hochskalierung, Metadaten und Vor-Release-Prüfung. Darunter erledigen sechs Kern-Engines die fachliche Arbeit (Concept, Lyrics, Music, Cover, Band, Release); weitere sind beim Ausbau dazugekommen (vgl. die Eckdaten in Abschnitt 5).
Genau dieser Ablauf — der früher mühsame, manuelle Prozess — ist es, der nun als Pipeline durchläuft. Abbildung 1 zeigt ihn als Ganzes: vom Stichwort bis zum versandfertigen Paket, mit dem Menschen als Steuermann an jedem generativen Schritt und der einen Nahtstelle, die sich nicht automatisieren ließ (vgl. Abschnitt 4).
flowchart TD
A([Wenige Stichworte]) --> B
subgraph BP["Band-Pipeline"]
B["Bandidentität<br/>Name · Bio · Stil-DNA · Logo · Bandfoto"]
end
subgraph AP["Album-Pipeline"]
direction TB
C["Albumkonzept"] --> D["Tracklist"]
D --> E["Lyrics je Track"]
E --> F["Musik je Track"]
F --> G["Cover"]
end
subgraph RP["Release-Pipeline"]
direction TB
H["Audio-Master · Cover 3000×3000"] --> I["Metadaten + ID3"]
I --> J["Vor-Release-Prüfung"]
J --> K{"Compliance-Gate"}
end
B --> C
G --> H
K -->|bestätigt| L([Release-Paket])
L --> M[/"Manueller Upload zu Distributor · Spotify"/]
HUM["Suggest-then-Refine:<br/>vorschlagen · editieren · sperren · bestätigen"]
HUM -. steuert .-> B
HUM -. steuert .-> E
SUNO["Suno hat keine offene API<br/>→ etwas Hin-und-her-Kopieren bleibt"]
SUNO -.- F
classDef done fill:#eafaf1,stroke:#2e9e5b,color:#13502a;
classDef manual fill:#fff4cc,stroke:#d6a700,color:#5c4a00;
classDef human fill:#eef3ff,stroke:#3a6ae8,color:#1b2e66;
classDef seam fill:#ffe8d6,stroke:#e8763a,color:#7a3b12;
class A,L done
class M manual
class HUM human
class SUNO seam
Abbildung 1: Der MusicMaker-Prozess — drei Pipelines vom Stichwort bis zum Release-Paket. Blau: die menschliche Steuerung (Suggest-then-Refine). Orange: die einzige nicht automatisierte Nahtstelle (Suno). Gelb: der manuelle Upload am Ende.
Zwei Konstruktionsentscheidungen sind es wert, hervorgehoben zu werden, weil sie das Tempo überhaupt erst ermöglicht haben.
Erstens die austauschbaren Clients. Die drei KI-Dienste — Claude für Texte, OpenAI Images für Bilder, Suno für Musik — stecken jeweils hinter einem Interface mit drei Implementierungen: Mock, Wrapper und Official, umgeschaltet per Umgebungsvariable, nie im Code. Stellen Sie sich genormte Steckdosen vor: Ob dahinter ein echter Generator hängt oder eine Testattrappe, ist dem angeschlossenen Gerät egal. Voreinstellung ist „Mock-First” — die ganze Entwicklung und Testautomatisierung läuft gegen Attrappen, ohne Account, ohne API-Kosten.
Zweitens das Bedienmuster „Suggest-then-Refine”. Jede Stufe schlägt alle leeren Felder vor, erlaubt das gezielte Neu-Erzeugen eines einzelnen Feldes und eine verbindliche Bestätigung. Felder, die ich gesetzt habe, gelten als gesperrt und werden im Prompt ausdrücklich so markiert — die KI füllt drumherum, fasst das Gesetzte nicht an. Das Tempo kommt von der Maschine, die Richtung vom Menschen.
Dazu kommen unsichtbare Leitplanken: Das Storage ist die einzige Schreibstelle und arbeitet atomar; jede Mutation hinterlässt einen Historieneintrag; vor jedem Release verlangt ein Compliance-Gate eine Bestätigung (Suno-Lizenz, keine realen Personen), die kryptografisch an die konkreten Audio-Dateien gebunden ist und bei einer Neugenerierung automatisch verfällt. So lässt sich nichts versehentlich veröffentlichen, das niemand mehr geprüft hat.
4. Der Wermutstropfen: Suno hat keine offene Schnittstelle
Bei aller Automatisierung gibt es eine Nahtstelle, die sich nicht sauber schließen ließ — und sie ist lehrreich genug, um sie offen zu benennen. Für die Musikgenerierung selbst gibt es keinen offiziellen, für Endkunden offenen API-Weg. Der Wrapper-Client behilft sich mit einer reverse-engineerten Lösung (ein Browser-Cookie wird gegen ein kurzlebiges Token getauscht), aber die ist naturgemäß brüchig und kann jederzeit brechen. In der Praxis bleibt damit rund um Suno ein bisschen Hin-und-her-Kopieren von Hand. Bezeichnend ist, dass das Projekt dafür sogar eine eigene Brücke gebaut hat — eine „Manual-Paste”-Pipeline mit Export- und Import-Helfern, die den Bruch so geordnet wie möglich macht. Eine saubere Schnittstelle ersetzt das nicht; es kittet sie nur.
Das ist der ehrliche Dämpfer auf die Knopfdruck-Erzählung: Ohne diese eine fehlende Schnittstelle liefe der Prozess vollständig ohne Handgriff durch — es ginge noch deutlich schneller. Der begrenzende Faktor ist hier nicht die Qualität der KI-Modelle, sondern der fehlende Zugang. Merken Sie sich diesen Satz; er ist zugleich die wichtigste Lektion (vgl. Abschnitt 5).
5. Die Learnings
Was nehme ich aus dem Bau von MusicMaker mit? Vier Dinge, die weit über das Spielzeug-Album hinaus gelten.
Die Automatisierbarkeit steckt im Workflow, nicht im Modell. Der eigentliche Engineering-Akt war nicht, eine KI zum Texten oder Komponieren zu bringen — das können die Modelle längst. Er war, den kreativen Prozess so klar zu zerlegen, dass jede Stufe einen definierten Input und Output hat. Wer einen Ablauf präzise aufschreiben kann, hat die halbe Automatisierung schon geleistet. Umgekehrt gilt: Was sich nicht beschreiben lässt, lässt sich auch nicht automatisieren.
Der Engpass ist die Schnittstelle, nicht die Generierung. Die langsamste Stelle im ganzen System ist nicht das Erzeugen von Konzept, Text oder Musik, sondern der fehlende API-Zugang zu Suno. Das ist verallgemeinerbar: In der Praxis wird das Automatisierungstempo selten von der Modellqualität begrenzt, sondern von der Integrierbarkeit der beteiligten Dienste. Wer Automatisierung plant, sollte zuerst die Schnittstellen prüfen, nicht die Modelle.
Entkopplung macht schnell und gefahrlos. Dass die externen Dienste hinter austauschbaren Interfaces liegen und per Voreinstellung gegen Attrappen laufen, ist der Grund, warum sich das System ohne Kosten und ohne Risiko weiterentwickeln lässt — und warum ein brüchiger Dienst wie der Suno-Wrapper ausgetauscht werden kann, ohne den Rest anzufassen. Lose Kopplung ist kein akademisches Ideal, sondern direkt spürbares Tempo.
Tempo und Sorgfalt schließen sich nicht aus — wenn die Disziplin steht. Der Album-Kern entstand an einem Wochenende, und doch nicht als Wegwerf-Hack: testgetrieben, schichtweise, mit Leitplanken für Storage, Historie und Compliance. Aus diesem Kern ist inzwischen ein System mit über 20.000 Zeilen Code gewachsen, von denen fast die Hälfte Tests sind — über 550 automatisierte Testfälle bei sauberem Linter-Lauf. Nicht die Zeile entstand schneller, sondern die abgesicherte Zeile.
Damit die Größenordnung greifbar wird, die Eckdaten — direkt aus dem Projekt-Repository ausgelesen:
| Kennzahl | Wert |
|---|---|
| Produktivcode (Kernpaket) | ~11.600 Zeilen |
| Testcode | ~9.000 Zeilen |
| Automatisierte Testfälle | über 550 |
| Funktionen (Produktivcode) | über 400 |
| Engines | 19 Module (Kern: Concept, Lyrics, Music, Cover, Band, Release) |
| Pipelines | 5 (Kern: Band, Album, Release; dazu Trend & Manual-Paste) |
| Externe KI-Dienste | 3 (Claude, OpenAI Images, Suno), je hinter Mock/Wrapper/Official |
| Bauzeit (Album-Kern) | ein Wochenende |
Bemerkenswert ist die letzte Zeile im Verhältnis zu den übrigen: Der Album-Kern war ein Wochenende — und das System ist seither weit über die reine Albumproduktion hinausgewachsen, bis hin zu einer Trend-Analyse, die musikalische und gesellschaftliche Strömungen als Themen-Input auswertet. Genau das ist der Punkt: Wenn der Prozess einmal sauber zerlegt ist, kostet jede weitere Stufe nur noch einen Bruchteil dessen, was die erste gekostet hat.
Fazit
MusicMaker ist für mich vor allem der Beleg einer einzigen These: Wenn ich einen Workflow aufschreiben kann, kann ich ihn mit KI automatisieren — und zwar schneller und solider, als die meisten erwarten. Die Grenze liegt nicht bei der Kreativität der Modelle, sondern dort, wo eine saubere Schnittstelle fehlt; genau diese eine Stelle, das manuelle Kopieren rund um Suno, ist der einzige verbliebene Handgriff.
Bleibt die größere Frage — ob wir das, was hier so mühelos gelingt, auch tun sollten, und was dabei verloren geht. Die habe ich nicht hier, sondern im Originalbeitrag „Selbstversuch Reloaded” gestellt, und ich lasse sie bewusst dort stehen. Für diesen Artikel gilt das Engineering-Fazit: Der Weg vom beschreibbaren Prozess zur laufenden Automatisierung ist heute erstaunlich kurz. Die eigentliche Arbeit ist, den Prozess klar genug zu denken — den Rest erledigt die Pipeline.
Quellen & Hinweise: Der erzählerische Rahmen (KI-Album 2024, Band „Merida’s Waves”, Album „After the last Bell”, Spotify-Veröffentlichung) stammt aus dem Beitrag „Selbstversuch Reloaded” (M. Störzer, 2. Mai 2026) und wird hier nur referenziert, nicht wiederholt — nachzulesen auf ms-books.com (Erstveröffentlichung auf LinkedIn). Die technischen Angaben und alle Kennzahlen (über 20.000 Zeilen Code, über 550 Testfälle, Engines, Pipelines, austauschbare Clients, Compliance-Gate) sind direkt aus dem Projekt-Repository von MusicMaker ausgelesen und damit nachprüfbar.
Diskussion
Gedanken, Rückfragen oder Widerspruch? Schreib gern einen Kommentar — nach einer kurzen Sichtung erscheint er hier.