Eine komplette Webanwendung aus der KI: der Selbstversuch

1. Der Fund

Die Domain mybytes.com ist deutlich älter als die heutige myBytes GmbH. Historische Quellen zeigen, dass unter /mixer.html früher eine browserbasierte Musik-Anwendung erreichbar war: Das Internet Archive führt Schnappschüsse dieser URL vom Februar 2008 bis März 2015, und zeitgenössische Berichte ordnen die Seite einer Microsoft-Kampagne zur Copyright-Aufklärung für Jugendliche zu, umgesetzt von einer externen Agentur in der Technik der damaligen Zeit.

Zur Einordnung, weil sie uns wichtig ist: Die heutige myBytes GmbH steht mit diesem früheren Angebot in keiner organisatorischen oder wirtschaftlichen Verbindung. Wir sind weder Rechtsnachfolger noch Fortführer; die Domain wurde erst später erworben. Nichts an der neuen Anwendung übernimmt Code, Grafik oder Klänge des damaligen Produkts.

Was uns interessierte, war etwas anderes: Eine URL, die vor über fünfzehn Jahren einen Browser-Mixer trug, liegt brach. Wie würde man so eine Anwendung heute bauen? Und wie viel davon kann moderne generative KI tatsächlich übernehmen?

2. Die Frage

Wir haben das Experiment bewusst eng definiert. Eine KI-gestützte Engineering-Umgebung (Claude in Claude Code) bekam den Auftrag, unter /mixer.html eine echte Groovebox zu bauen: Step-Sequencer, Synthese, Mixer und als Kern ein Machine-Learning-Modell, das Drum-Patterns generiert und variiert und dabei vollständig im Browser der Nutzer läuft.

Die Arbeitsteilung stand vorher fest. Die KI entwirft, implementiert und dokumentiert; der Mensch entscheidet an definierten Gates: Architekturfreigaben, Hörtests, Design-Urteile, Lizenzfragen. Jede Sitzung wurde in einem Entwicklungslogbuch protokolliert, jede Behauptung dieses Artikels stammt aus diesen Aufzeichnungen oder aus Messdaten eines dokumentierten Laufs.

3. Vom Auftrag zu Anforderungen

Aus der Idee wurde zuerst ein Anforderungskatalog: acht Spuren (am Ende zwölf, inklusive dreier Toms und einer Becken-Spur), ein 32-Step-Raster über zwei Takte, Transport mit BPM und Swing, pro Spur Lautstärke, Panorama, Mute und Solo, dazu Demo-Inhalte, die die Seite beim ersten Öffnen tragen. Für die KI-Komponente galt eine harte Vorgabe: Das Modell erzeugt keine Audio-Wellenformen, sondern musikalische Ereignisse - welches Instrument schlägt auf welchem Step wie stark. Die Klangerzeugung bleibt komplett bei der Web Audio API.

Zwei Rahmenbedingungen prägten alles Weitere. Erstens: Jeder Klang der Anwendung ist synthetisiert, es gibt keine fremden Samples und damit keine ungeklärten Rechte. Zweitens: Die Inferenz läuft lokal; es verlassen keine Audiodaten und keine musikalischen Inhalte den Browser. Ein Netzwerk-Trace einer kompletten Sitzung (Laden, Playback, Generieren, Variieren) belegt das: Übertragen werden ausschließlich Seiten-Assets und Modelldateien per GET; die einzige ausgehende Datenspur sind die Klick-Ereignisse der seiteneigenen Website-Statistik, die auf jeder Seite läuft und keinerlei musikalische Inhalte enthält.

4. Die Architektur

Die Anwendung besteht aus vier Schichten. Ein zentraler Store hält das Pattern (Steps, Noten, Einstellungen) als einzige Quelle der Wahrheit. Ein Scheduler plant Audio-Ereignisse; ein Web Worker tickt alle 25 Millisekunden, der Hauptthread plant daraufhin alle Ereignisse der nächsten 120 Millisekunden sample-genau gegen die Uhr des AudioContext. Die Audio-Engine hält pro Spur eine Kette aus Gain und Stereo-Panner und rendert die Drum-Sounds beim Start aus Syntheseparametern in Puffer. Die KI-Schicht schließlich lädt zwei kleine TensorFlow.js-Modelle und schreibt ihre Ergebnisse in den Store, nie direkt in die Audio-Engine.

Der Scheduler-Teil ist der Klassiker der Browser-Audio-Entwicklung: Wer Noten mit setInterval auslöst, hört Timing-Schwankungen, sobald der Browser den Tab drosselt. Das Lookahead-Muster (Planung in die Zukunft auf der Audio-Uhr, Tick im Worker) ist seit Jahren der etablierte Weg, und die KI hat es auf Anhieb korrekt umgesetzt.

5. Das Modell: ein kleines VAE für Drum-Patterns

Das Herzstück ist ein Variational Autoencoder über symbolischen Drum-Patterns - ein Modell, das Muster in eine kompakte Zahlendarstellung verdichtet und daraus wieder erzeugt. Ein Pattern ist eine Matrix aus 32 Steps und fünf Klassen (Kick, Snare, geschlossene und offene Hi-Hat, Percussion), Werte sind Anschlagstärken zwischen 0 und 1. Der Encoder bildet diese 160 Zahlen auf einen 32-dimensionalen latenten Vektor ab, der Decoder rekonstruiert daraus das Pattern mit zwei Köpfen: einer sagt, ob ein Schlag stattfindet, der andere, wie stark.

Warum ein VAE und kein autoregressives Modell? Wegen der Kernfunktion. Die Variation eines bestehenden Patterns ist im latenten Raum präzise definierbar: Pattern kodieren, Vektor um einen kontrollierten Radius verschieben, dekodieren. Der Variation-Regler der Anwendung bildet genau diesen Radius ab. Die Messung bestätigt das Konzept: Die mittlere Änderung des Patterns wächst monoton mit dem Radius, von 0,016 bei r = 0,1 bis 0,192 bei r = 1,7, ohne Sättigung im gemessenen Bereich.

Trainiert wurde auf dem Groove MIDI Dataset (Google, CC BY 4.0), echten E-Drum-Aufnahmen menschlicher Schlagzeuger: 20 474 Zwei-Takt-Fenster aus 1150 Dateien, aufgeteilt nach Schlagzeugern (70,4 / 14,8 / 14,8 Prozent), damit kein Spieler gleichzeitig in Training und Test liegt. Das gewählte Modell hat 201 856 Parameter und trainierte 70 Epochen in 12,3 Sekunden auf einer CPU - kein Tippfehler: Auf dieser Größenskala ist Training kein Infrastrukturproblem. Eine Ablation über die Größe des latenten Raums (8, 16, 24, 32 Dimensionen) ergab Onset-F1-Werte von 0,638, 0,710, 0,737 und 0,749; gewählt wurde 32.

Die exportierten Modelle sind zusammen 397,4 Kilobyte groß (fp16). Ein Paritätstest rechnete den Vorwärtslauf direkt aus den ausgelieferten Gewichten in numpy nach; die maximale Abweichung zur Trainingsumgebung lag bei 0,0009.

Das Modell wuchs während des Projekts einmal mit dem Produkt mit: Als die Anwendung Tom-Spuren bekam, folgte eine zweite Modellversion mit acht Klassen (die fünf bisherigen plus drei Toms), eigener Seed, eigener Lauf. Vorher stand ein Gate: die Belegungsmessung. Alle drei Tom-Klassen liegen im Datensatz unter dem Niveau der ohnehin dünnen offenen Hi-Hats (34,0, 17,4 und 28,9 Prozent der Fenster gegenüber 38,1) - die Entscheidung, trotzdem zu trainieren und die Dünnheit als dokumentierten Befund zu führen, fiel beim Menschen.

Der Gesamt-F1 sank erwartbar von 0,749 auf 0,697 (das Ziel hat drei dünne Klassen mehr), die Modelle wuchsen auf zusammen 542 Kilobyte, der Paritätstest bestand mit maximal 0,0012 Abweichung.

Die Styles der Anwendung sind Anker im latenten Raum - vier von Beginn an, ein fünfter kam als Konsequenz eines Befunds dazu (Abschnitt 9). Von den ursprünglichen vier stammen zwei (Lo-Fi, Experimental) aus Genre-Teilmengen des Datensatzes, zwei (House, Electronic) aus kuratierten Referenz-Patterns. Der Unterschied ist eine Geschichte für sich: Die Teilmenge „dance“ des Datensatzes klang nach viel, bestand aber aus nur sieben Aufnahmen von zwei Schlagzeugern - ein Anker daraus hätte diese zwei Personen kodiert, nicht das Genre. Die Entscheidung, diese Teilmenge zu verwerfen, fiel bei dieser Nachzählung - vor jedem Hörtest und ohne dass eine Modell-Metrik sie erzwungen hätte.

6. Web Audio: Klang ohne Samples

Jeder Klang der Anwendung entsteht aus Code. Die Kick ist ein Sinus mit fallender Tonhöhe plus kurzem Klick, die Snare ein Dreieck-Körper mit Rauschanteil, Hi-Hats und Becken sind gefiltertes Rauschen, die Melodiestimmen kommen aus einer eigenen kleinen subtraktiven Synth-Engine mit Oszillatoren, Filter und Hüllkurven. Das ist keine Sparsamkeit, sondern eine Rechtsposition: Es existiert kein einziges fremdes Sample im Projekt, und die Parameter jedes Klangs stehen im Quellcode.

7. Inferenz im Browser

Die Laufzeitumgebung ist TensorFlow.js 4.22.0, vollständig selbst gehostet - keine CDN-Abhängigkeit, was zugleich der Datenschutz-Architektur entspricht. Die Backend-Kette probiert WASM, dann WebGL, dann CPU. Auf Latenzzahlen verzichtet dieser Artikel bewusst: Eine systematische Messkampagne über Geräte und Browser haben wir nicht gefahren, und Einzelwerte vom Entwicklungsrechner wären Anekdoten. Wer eigene Zahlen will, bekommt sie aus erster Hand: Ein eingebauter Benchmark-Modus (Aufruf der Seite mit ?bench=1) fährt 100 Generate- und 100 Variation-Inferenzen mit festem Seed und legt Backend, Ladezeit und p50/p95 als JSON offen - gemessen auf dem eigenen Gerät, nicht auf unserem.

Interessant ist, was auf dieser Modellgröße nicht das Problem ist: Inferenzzeit und Speicher spielen praktisch keine Rolle. Die eigentliche Ingenieursarbeit steckt im Drumherum: in Ladepfaden, Backend-Fallbacks und der Entscheidung, die Laufzeit mit den Modellartefakten auszuliefern statt aus einem Paketmanager zu beziehen.

8. Was die KI gut konnte

Die erste lauffähige Fassung der Anwendung - Sequencer, Synthese, Mixer, Demo-Patterns, Seite mit Suchmaschinen-Grundausstattung - entstand in einem einzigen Arbeitstag, die TF.js-Integrationsschicht am selben Abend. Das Lookahead-Scheduling war im ersten Wurf korrekt. Die Parameter-Registry der Synth-Engine erzeugt Regler, Wertebereiche, Normalisierung und Dokumentation aus einer einzigen Quelle; die klickfreien Hüllkurven umgehen eine bekannte Browser-Inkompatibilität (Firefox kennt cancelAndHoldAtTime nicht), indem der Kurvenwert zum Übergangszeitpunkt analytisch berechnet wird - eine Lösung, die wir so in keinem Tutorial gefunden haben.

Und: Die KI schrieb zu ihrer eigenen Logik konsequent Tests (am Ende 47), die mehrfach echte Fehler fingen, bevor ein Mensch sie hörte.

9. Wo die KI scheiterte

Das Logbuch ist an dieser Stelle die ehrlichste Quelle des Projekts.

Der leere Bildschirm: Die erste ausgelieferte Fassung des Hörtest-Werkzeugs zeigte nur eine Überschrift. Ursache war ein klassischer JavaScript-Fehler (Zugriff auf eine Konstante vor ihrer Initialisierung), den alle 27 damaligen Unit-Tests nicht sehen konnten, weil keiner den Einstiegspunkt als Ganzes lud. Gefunden hat ihn der Mensch am laufenden System; die Konsequenz war eine neue Testklasse.

Musikalischer Geschmack: Das Demo-Pattern „Experimental“ brauchte zwei Anläufe. Der erste war theoretisch interessant (Polyrhythmik, Quartharmonik) und klang, im Urteil des Menschen, schlicht furchtbar. Der zweite Anlauf wurde ein dunkler Halftime-Groove und bestand. Eine Metrik dafür gab es nicht.

Bedienbarkeit: Der Marker für offene Hi-Hats war ein kleines „o“ und wurde als Ziffer Null gelesen. Die Melodie-Spuren waren anfangs bewusst nicht editierbar, wirkten aber wie ein Defekt. Und das Layout der Spurköpfe brauchte fünf Anläufe, weil die KI zwei Anweisungen nacheinander falsch interpretierte - am Ende stellte sich heraus, dass die ursprüngliche Anordnung die beste war, was erst der Vergleich sichtbar machte.

Ehrlichkeit des Modells: Das VAE erzeugt systematisch zu wenige offene Hi-Hats (sie kommen nur in 38,1 Prozent der Fenster im Datensatz vor), und die Quantisierung auf ein 16tel-Raster kostet 7,84 Prozent der Original-Schläge (mit dem erweiterten Tom-Mapping der zweiten Version noch 7,08), weil menschliches Spiel neben dem Raster liegt (mittlere Abweichung: 0,176 Steps). Beides steht auch auf der Produktseite, nicht nur hier.

Genre-Treue: Die zweite Modellversion lieferte den vielleicht lehrreichsten Befund des Projekts. Das Modell kann Toms - die Rekonstruktion gehaltener Patterns erreicht je nach Tom-Klasse F1-Werte von 0,30 bis 0,55, in der Größenordnung der offenen Hi-Hats. Aber in den generierten Patterns der vier App-Styles tauchen Toms fast nie auf: je Tom-Klasse in 6,3, 1,3 und 7,5 Prozent der Fälle. Der Grund ist kein Trainingsfehler, sondern die Anker-Wahl: House, Electronic und Lo-Fi sind genau die Genres, in denen Schlagzeuger kaum Toms spielen - die Style-Anker liegen in tom-armen Regionen des latenten Raums. Das Modell reproduziert die Wahrheit seiner Genres, nicht den Wunsch seiner Entwickler.

Die Probe aufs Exempel folgte einen Tag später und bestätigte die Diagnose. Ein fünfter Style-Anker „Fills“, berechnet als Mittelwert der 6682 tom-lastigen Fenster des Datensatzes (rund ein Drittel der Daten, alle zehn Schlagzeuger, mindestens drei Tom-Schläge je zwei Takte) - ohne dass ein einziges Modellgewicht angefasst wurde: An diesem Anker erscheinen Toms in 58, 20 und 61 Prozent der generierten Patterns statt in 6,3, 1,3 und 7,5, bei intaktem Kern-Kit (Kick 92, Snare 95, geschlossene Hi-Hat 87 Prozent). Der Preis ist derselbe Mechanismus in Gegenrichtung: Offene Hi-Hats fallen an diesem Anker auf 5 Prozent, denn Fills ersetzen im echten Spiel genau die Hi-Hat-Arbeit. Die Lösung bestand nicht darin, das Modell zu ändern, sondern ihm eine andere Region seiner eigenen Landkarte zu zeigen.

10. Die Rolle des Menschen

Nach dem Logbuch verteilt sich die Arbeit so: Die KI schrieb praktisch den gesamten Code und die Dokumentation. Der Mensch traf die Architektur-Grundsatzentscheidungen (eigenes Modell statt vortrainierter Checkpoints, nachdem sich das Magenta-Projekt als archiviert erwies), alle Geschmacks- und Qualitätsurteile (Hörtests, Layout, Demo-Patterns), die Lizenz- und Datenstrategie, und er fand die Fehler, die nur am laufenden System sichtbar werden. Ohne diese Gates wäre die Anwendung schneller fertig gewesen - und schlechter.

Ein Detail verdient Erwähnung: Während der Integration setzte der Mensch einmal mitten in einem laufenden Umbau einen Commit; zwei neue Dateien fehlten darin, und der Build wäre fehlgeschlagen. Die KI erkannte das Muster (eine dokumentierte Falle des Deploy-Prozesses) und meldete es, bevor die Pipeline rot wurde. Zusammenarbeit heißt hier: Beide Seiten fangen die Fehler der jeweils anderen.

11. Das Ergebnis

Die Anwendung ist unter mybytes.com/mixer.html frei nutzbar, ohne Konto, ohne Upload. Sie ist seit dem Experiment weitergewachsen, in denselben Arbeitsweisen - KI baut, Mensch entscheidet. Dazu kamen eine Pattern-Bank mit Song-Modus, eine subtraktive Synth-Engine mit 15 Presets und eigenem Sound-Editor je Spur, formbare Drum-Synthese, ein Arpeggiator und Send-Effekte.

12. Fazit

Kann KI heute eine komplette Webanwendung entwickeln? Sie kann erstaunlich viel davon: In diesem Projekt stammen Architekturumsetzung, Code, Tests und Dokumentation fast vollständig aus einer KI-Umgebung, und die Geschwindigkeit verändert die Ökonomie solcher Experimente grundlegend - ein Trainingslauf von Sekunden auf einer CPU, ein Arbeitstag bis zur spielbaren Anwendung.

Was sie nicht ersetzt hat: das Urteil. Jede Stelle, an der das Produkt gut wurde statt nur funktional, war eine menschliche Entscheidung - vom verworfenen Style-Anker über zwei Anläufe für ein Demo-Pattern bis zur Erkenntnis, dass das erste Layout das richtige war. Generative KI verschiebt Geschwindigkeit und Arbeitsteilung erheblich; Architekturverantwortung, Qualitätskontrolle und Geschmack bleiben Arbeit.

Transparenz: Das Drum-Modell wurde auf dem Groove MIDI Dataset trainiert (Google LLC, CC BY 4.0; Gillick, Roberts, Engel, Eck, Bamman: „Learning to Groove with Inverse Sequence Transformations“, ICML 2019). Alle Zahlen dieses Artikels stammen aus zwei dokumentierten Trainingsläufen (Version 1: Seed 20260809, Version 2 mit Toms: Seed 20260810; identischer Datensatz-Split) bzw. den im Text genannten Messungen; Einzelwerte sind Einzelwerte, keine Mittelwerte über mehrere Läufe. Beide Läufe fanden vor dem ersten Commit des Trainings-Repositories statt; die Metrikdateien tragen deshalb keine Commit-Referenz. Der Fills-Anker ist eine nachträgliche Anker-Ergänzung ohne Retraining; seine Präsenz-Zahlen stammen aus einer Messung über 100 generierte Patterns (Seed 20260811). Der Trainingscode ist als Repository veröffentlicht: github.com/myBytesResearch/drum-vae-mixer.

Quellen

1. Internet Archive, Wayback Machine, Snapshots von mybytes.com/mixer.html - frühester: 16.02.2008, letzter: 16.03.2015; gesichtet 2026-08-11.
2. Microsoft-Pressemitteilung, 13.02.2008: „Teens Less Likely to Download Illegally When They Know the Laws, Microsoft Survey Finds“ (gesichtet 2026-08-09).
3. YALSA-Blog (American Library Association), 26.02.2008: „MyBytes Teaches Teens a Little Something about Copyright“ (gesichtet 2026-08-09).
4. Glen Rhodes, Portfolio-Eintrag MyBytes - glenrhodes.com/portfolio/portfolio/mybytes (gesichtet 2026-08-09).
5. Groove MIDI Dataset (Google LLC, CC BY 4.0; eingespielt auf einem Roland-TD-11-E-Drum-Kit) - magenta.tensorflow.org/datasets/groove (gesichtet 2026-08-11). Paper: Gillick, Roberts, Engel, Eck, Bamman: „Learning to Groove with Inverse Sequence Transformations“, ICML 2019.
6. Magenta-Projekt, archiviert Januar 2026 - github.com/magenta/magenta (gesichtet 2026-08-09).
7. Chris Wilson: „A Tale of Two Clocks“ (Lookahead-Scheduling für Web Audio) - web.dev/articles/audio-scheduling (gesichtet 2026-08-11).
8. Browser-Unterstützung AudioParam.cancelAndHoldAtTime - caniuse.com/mdn-api_audioparam_cancelandholdattime (Firefox ohne Unterstützung; Stand 2026-08-11).
9. Trainings-Repository mit allen Messdaten, Seeds und dem Ergebnis-Notebook - github.com/myBytesResearch/drum-vae-mixer.