Kitmul begann als etwas weitaus Bescheideneres, als es heute ist. Ich pflege zwei Open-Source-Bibliotheken (NextTranslate und Teaful) und brauchte ein echtes Next.js-Projekt, um an ihnen zu iterieren. Keine künstlichen Demos oder Beispiel-Repositories; ein lebendiges Produkt, in dem Bugs von selbst auftreten und Einschränkungen offensichtlich werden.
Das war das einzige Ziel.
Der KI-Multiplikator-Effekt
Um die Entwicklung zu beschleunigen, habe ich angefangen, KI-Coding-Agenten einzusetzen: Claude Code, Gemini und Codex. Nicht nur wegen der Produktivität. Ich wollte aus erster Hand verstehen, wie sich diese Agenten in einem echten Entwicklungs-Workflow verhalten. Wo sie glänzen, wo sie versagen, und wie sie die Art verändern, wie man über Software-Entwicklung nachdenkt.
Was ich nicht erwartet hatte, war der Effekt auf den Projektumfang. Wenn du eine Idee in Minuten statt in Stunden umsetzen kannst, hörst du auf, Ideen zu priorisieren. Du baust sie einfach. In nur 3 Wochen bin ich von „ich pflege mal diese zwei Bibliotheken" zu „ich baue 300+ Tools" gewechselt.
Aktuell nutze ich Claude Code 20x. Die Kombination aus einem Agenten, der deine Codebase tiefgehend versteht und mehrstufige Aufgaben autonom ausführen kann, ist der größte Geschwindigkeitsmultiplikator, den ich je erlebt habe.
Von Entwickler-Tools zu Tools für alle
Als Open-Source-Entwickler habe ich immer für andere Entwickler gebaut. Bibliotheken, CLI-Tools, Build-Utilities. Begrenztes Publikum, begrenzter Impact.
Mit Kitmul habe ich die Frage umgedreht. Statt „Welches Tool braucht ein Entwickler" habe ich gefragt: „Welches Tool suchen die Leute bei Google und landen auf einer Website, die ihnen Geld abknöpft oder ihre Dateien auf einen Server hochlädt."
Die Antwort: Hunderte von Tools. Bildhintergründe entfernen, Audiospuren trennen, Formate konvertieren, PDFs komprimieren, QR-Codes generieren. Tools, die Menschen täglich nutzen, und für die viele Websites 10-20 € pro Monat verlangen.
Heute hat Kitmul über 300. Und es sind keine trivialen Wrapper.
Die Architektur: alles läuft auf dem Gerät des Nutzers
Die fundamentale technische Entscheidung bei Kitmul ist, dass alles auf dem Client läuft. Ohne Ausnahmen, wann immer möglich.
Der Stack ist geradlinig: Wenn natives JavaScript reicht, wird JavaScript verwendet. Wenn die Operation intensiv ist (Audioverarbeitung, schwere Bildmanipulation, Spurentrennung) wird nach WebAssembly kompiliert. Für performance-kritische Teile: Rust, kompiliert zu WASM.
Hier ein Beispiel, wie wir PDFs komplett im Browser zusammenführen:
import { PDFDocument } from 'pdf-lib';
export async function mergePDFs(files) {
const merged = await PDFDocument.create();
for (const file of files) {
const bytes = await file.arrayBuffer();
const pdf = await PDFDocument.load(bytes);
const pages = await merged.copyPages(pdf, pdf.getPageIndices());
pages.forEach((page) => merged.addPage(page));
}
return merged.save(); // Gibt Uint8Array zurück; verlässt nie den Browser
}
Null Netzwerk-Aufrufe. Die Datei geht von File API → pdf-lib → Download.
Warum Rust + WASM: der Primzahl-Checker
Für schwerere Berechnungen stößt JavaScript an eine Wand. Ein echtes Beispiel aus Kitmul: unser Primzahl-Checker. JavaScript kann die Primalität für kleine Zahlen prüfen, aber versuch mal eine Zahl mit mehr als 1.200 Stellen zu testen — der Browser wird einfrieren. BigInt schafft das einfach nicht.
Hier der JavaScript-Ansatz, der für Zahlen bis ca. 13 Stellen gut funktioniert:
function isPrime(n) {
if (n <= 1) return false;
if (n <= 3) return true;
if (n % 2 === 0 || n % 3 === 0) return false;
for (let i = 5; i * i <= n; i += 6) {
if (n % i === 0 || n % (i + 2) === 0) return false;
}
return true;
}
// Funktioniert für kleine Zahlen, aber für eine Zahl mit 1200+ Stellen?
// BigInt-Arithmetik wird so langsam, dass der Tab einfriert.
Die Lösung: Wir haben eine Rust-Crate kompiliert, die num-bigint mit einem Miller-Rabin-Primalitätstest zu WASM verwendet. Die Rust-Seite empfängt die Zahl als String (weil sie Tausende von Stellen lang sein kann) und gibt zurück, ob sie prim ist:
use num_bigint::BigUint;
use num_traits::{One, Zero};
#[no_mangle]
pub extern "C" fn is_number_prime(ptr: *const u8, len: usize) -> i32 {
let bytes = unsafe { std::slice::from_raw_parts(ptr, len) };
let num_str = std::str::from_utf8(bytes).unwrap_or("0");
let n = num_str.parse::<BigUint>().unwrap_or_else(|_| BigUint::zero());
if n <= BigUint::one() { return 0; }
if miller_rabin(&n) { 1 } else { 0 }
}
Dann laden wir aus JavaScript das WASM-Modul und übergeben die Zahl als Bytes:
// WASM laden und eine Zahl mit 1200+ Stellen prüfen
const { instance } = await WebAssembly.instantiate(wasmBuffer, {});
const exports = instance.exports;
const numStr = "12345..."; // Zahl mit 1200+ Stellen
const bytes = new TextEncoder().encode(numStr);
const ptr = exports.wasm_alloc(bytes.length);
new Uint8Array(exports.memory.buffer).set(bytes, ptr);
const result = exports.is_number_prime(ptr, bytes.length);
exports.wasm_dealloc(ptr, bytes.length);
// result: 1 = prim, 0 = nicht prim
JavaScript mit BigInt kann Zahlen über ca. 1.200 Stellen nicht verarbeiten. Das Rust-WASM-Modul verarbeitet Zahlen jeder Größe — wir haben es mit Zahlen über 3.000 Stellen getestet. Derselbe Browser, dasselbe Gerät, aber Rusts num-bigint-Crate nutzt optimierte Limb-Arithmetik, die JavaScript einfach nicht erreichen kann.
Die Auswirkungen dieser Architektur:
- Nahezu null Infrastrukturkosten: keine Server, die Dateien verarbeiten.
- Echte Privatsphäre, nicht nur versprochen: die Daten verlassen buchstäblich nie das Gerät.
- Skalierbarkeit ohne Provisionierung: jeder Nutzer bringt seine eigene Rechenleistung mit.
Die These: KI-Agenten sollten deine Apps nicht steuern. Sie sollten die App SEIN.
Hier liegt meiner Meinung nach der Denkfehler der aktuellen Branche.
OpenAI mit Operator, Anthropic mit Computer Use, Google mit Project Mariner: die großen Player bauen alle KI-Agenten, die bestehende Anwendungen steuern. Sie machen Screenshots von deinem Bildschirm, bewegen deine Maus, klicken Buttons, füllen Formulare aus. Im Grunde bauen sie extrem ausgefeilte RPA-Bots.
Ich halte diesen Ansatz für grundlegend fehlerhaft. Und zwar deshalb:
1. Du baust auf Interfaces auf, die für Menschen entworfen wurden, nicht für Maschinen. Wenn ein KI-Agent eine Website navigiert, kämpft er gegen Dropdowns, Modals, Cookie-Banner, CAPTCHAs und Layout-Änderungen. Jedes Website-Redesign kann den Agenten kaputt machen. Das ist fragil by design.
2. Du bist immer noch von Drittanbieter-Diensten abhängig. Der KI-Agent mag clever sein, aber er lädt dein PDF trotzdem bei iLovePDF hoch, schickt deine Bilder trotzdem an Canva-Server, gibt deine Daten trotzdem an jemand anderen weiter. Das Datenschutzproblem verschwindet nicht, nur weil ein Roboter die Buttons klickt.
3. Es ist langsam. Screenshot → analysieren → klicken → warten auf Page Load → wieder Screenshot. Diese Schleife braucht Sekunden pro Aktion. Ein direkter Funktionsaufruf braucht Millisekunden.
Der alternative Ansatz (und das, was ich mit Kitmul baue) ist radikal anders:
Der KI-Agent steuert keine Apps. Der KI-Agent IST die App.
Statt zu SmallPDF zu navigieren, um Dateien zusammenzuführen, ruft der Agent direkt mergePDFs() auf. Statt Canva zu öffnen, um einen Hintergrund zu entfernen, führt er ein WASM-Modell im Browser aus. Keine Screenshots, keine Mausbewegungen, kein Warten auf Page Loads. Direkte Funktionsaufrufe, direkte Ergebnisse.
// Der "Screenshot and Click"-Ansatz (Operator, Computer Use):
// 1. Zu smallpdf.com navigieren (~3s)
// 2. Upload-Button finden (~1s)
// 3. Datei hochladen (~5s)
// 4. Auf Verarbeitung warten (~3s)
// 5. Download klicken (~2s)
// 6. Auf Download warten (~3s)
// Gesamt: ~17 Sekunden + deine Dateien auf dem Server von jemand anderem
// Der Kitmul-Ansatz:
const merged = await mergePDFs(files); // ~300ms, verlässt nie dein Gerät
Das ist ein 30-50x Geschwindigkeitsunterschied, mit dem zusätzlichen Vorteil, dass deine Dateien nie einen Remote-Server berühren.
Orchestrierung in der Praxis
Kitmul hat bereits einen integrierten Chat, in dem die KI als Orchestrator fungiert. Der Nutzer beschreibt in natürlicher Sprache, was er möchte. Die KI wählt Tools aus dem Katalog, führt sie der Reihe nach aus und verkettet die Outputs.
Ein konkretes Beispiel: Du lädst eine Audiodatei hoch. Die KI trennt sie mithilfe eines WASM-Quelltrennungsmodells in Spuren. Dann wendet sie Rauschunterdrückung auf die Gesangsspur an. Konvertiert das Ergebnis in MP3. Alles verkettet, alles im Browser, alles ohne dass die Datei dein Gerät verlässt.
Der Orchestrator nutzt eine Tool-Registry, die natürlichsprachliche Absichten auf konkrete Funktionen abbildet:
// Vereinfachte Version der Orchestrator-Funktionsweise
const toolRegistry = {
'merge_pdf': { fn: mergePDFs, input: 'file[]', output: 'file' },
'split_audio': { fn: splitAudio, input: 'file', output: 'file[]' },
'compress_image': { fn: compressImage, input: 'file', output: 'file' },
// ... 300+ weitere Tools
};
// Die KI entscheidet den Ausführungsplan und führt ihn aus:
const plan = await ai.plan("Trenne diesen Song und entferne Rauschen aus den Vocals");
// → [{ tool: 'split_audio', input: userFile },
// { tool: 'noise_reduction', input: '$prev.vocals' },
// { tool: 'convert_to_mp3', input: '$prev' }]
for (const step of plan) {
step.result = await toolRegistry[step.tool].fn(resolve(step.input));
}
Das ist kein Konzept. Es funktioniert heute.
Der Teil, der richtig spannend wird: Tools, die sich selbst bauen
Hier unterscheidet sich Kitmul von allem anderen.
Mit 300+ Tools decken wir eine Menge Anwendungsfälle ab. Aber wenn ein Nutzer nach etwas fragt, das wir noch nicht haben, sollte das System (statt „Sorry, können wir nicht" zu sagen) in der Lage sein, das Tool on the fly mit KI zu erstellen; und dann, ganz entscheidend, einen Human-in-the-Loop haben, der verifiziert, dass das generierte Tool tatsächlich korrekt funktioniert, bevor es Teil des permanenten Katalogs wird.
Stell dir das mal vor:
- Ein Nutzer fragt: „Ich brauche ein Tool, das MIDI-Dateien in Notenblätter konvertiert."
- Die KI generiert das Tool: eine clientseitige Implementierung mit WebAssembly.
- Ein menschlicher Reviewer (ich, oder irgendwann eine Community von Contributors) verifiziert, dass das Tool funktioniert, Edge Cases abdeckt und Kitmuls Qualitätsstandards erfüllt.
- Nach der Freigabe wird das Tool permanent zum Katalog hinzugefügt.
- Der nächste Nutzer, der dasselbe braucht, bekommt sofort das verifizierte, produktionsreife Tool.
Das System baut sich buchstäblich selbst, basierend auf dem, was die Nutzer brauchen. Jede unbeantwortete Anfrage wird zu einem Signal. Jedes verifizierte Tool macht die Plattform leistungsfähiger. Es ist ein Schwungrad, bei dem KI generiert, Menschen verifizieren und der Katalog organisch wächst.
Das ist fundamental anders als der Ansatz „Code zur Laufzeit generieren", den einige KI-Unternehmen verfolgen. Generierter Code, der ohne Verifizierung läuft, ist ein Risiko: er könnte Bugs haben, Sicherheitslücken, oder einfach bei Edge Cases nicht funktionieren. Der Human-in-the-Loop-Schritt ist keine Einschränkung; er ist ein Feature. Er stellt sicher, dass jedes Tool im Katalog produktionsreif ist.
In Aktion sehen
Hier ist eine kurze Demo, wie Kitmul funktioniert:
Das Ziel: 4.000 Tools in einem Jahr
Ich habe ein Backlog mit über 4.000 Tool-Ideen. Das ist keine willkürliche Zahl: es ist die tatsächliche Größe der Liste, nachdem ich analysiert habe, wonach die Leute suchen und was derzeit das Hochladen von Dateien auf einen Server oder das Bezahlen eines Abonnements erfordert.
Mit Claude Code 20x und dem Self-Building-Ansatz ist das kein Moonshot. Viele Tools werden in einer einzigen Session gebaut. Die komplexeren (die individuelles WASM oder Signalverarbeitung erfordern) brauchen länger, aber sie sind immer noch um Größenordnungen schneller als ohne KI.
Was kommt als Nächstes
Die Orchestrierung funktioniert für einfache Abläufe, aber komplexe Workflows mit Verzweigungen, Bedingungen und Feedback-Schleifen brauchen noch Arbeit. Die Self-Building-Pipeline wird gerade designed.
Das langfristige Ziel: ein System, in dem jede Aufgabe, die du heute mit fragmentierter Software erledigst (hier Dateien hochladen, dort ein Abonnement bezahlen, für etwas anderes eine App installieren) innerhalb einer einzigen Oberfläche gelöst werden kann, lokal ausgeführt, von KI orchestriert und ständig wachsend, basierend auf dem, was die Nutzer tatsächlich brauchen.
Die Frage, die ich dir mitgeben möchte: Brauchen wir wirklich KI-Agenten, die unsere bestehenden Apps fernsteuern? Oder müssen wir neu denken, was die App selbst sein sollte?
Ich glaube, die Antwort ist Letzteres. Und ich glaube, der Browser ist die richtige Runtime, um es zu beweisen.