KIWERK

Autonomer KI-App-Builder auf selbst betriebener Infrastruktur

Stand: 20. Juli 2026 · Die Netzhandwerker, Daniel Wesseling

Worum es geht

KIWERK nimmt eine Aufgabe in normaler Sprache entgegen, baut daraus eine lauffähige Web-Anwendung und veröffentlicht sie. Ohne Zwischenschritte, ohne dass jemand Dateien anlegt oder Befehle abtippt.

Eingabe: "Baue eine Infoseite für Kabel-Recycling mit Überschrift, Text und drei Punkten. Deploye auf Cloudflare."

Ergebnis nach vier Runden und etwa 25 Sekunden: eine erreichbare Seite unter einer öffentlichen Adresse.

Das Projekt wird ausschließlich mit Diensten ohne laufende Gebühren und einem vorhandenen Server für 6,49 Euro im Monat betrieben.

Aufbau

Browser
   │
   ▼
kiwerk.netzhandwerker.de          Caddy, Reverse Proxy, Zertifikat
   │
   ▼
Oberfläche (PHP, Shared Hosting)  Auth, Projekte, Chat, Live-Protokoll
   │
   ▼
Bridge (Python, Port 8770)        startet Läufe, liefert Ereignisse
   │
   ▼
Agent (Python)                    Werkzeug-Schleife, Anbieter-Kette
   │
   ├──▶ Groq / OpenRouter         das Denken
   └──▶ Sandbox /opt/kiwerk/      das Bauen
            │
            ▼
       Cloudflare · Netlify · Vercel

Zwei Maschinen: ein Shared-Hosting-Paket für die Oberfläche, ein kleiner virtueller Server für die Ausführung. Getrennt, weil das Hosting-Paket weder ausgehende Verbindungen noch Shell-Zugriff erlaubt.

Der Agent

Fünf Werkzeuge, mehr nicht:

Werkzeug	Wirkung
`write_file`	schreibt im Projektordner
`read_file`	liest, gekürzt auf 6.000 Zeichen
`list_dir`	listet ohne `node_modules` und `.git`
`run`	Shell im Projektordner, 180 Sekunden Grenze
`done`	beendet den Lauf mit Zusammenfassung

Das Modell entscheidet selbst, welches Werkzeug wann dran ist. Nach jedem Schritt bekommt es das Ergebnis zurück und plant weiter. Maximal 40 Runden, dann bricht der Lauf ab.

Anbieter-Kette

Fällt automatisch weiter, wenn ein Dienst nicht antwortet:

openai/gpt-oss-120b über Groq
llama-3.3-70b-versatile über Groq
qwen3-next-80b über OpenRouter
qwen2.5-coder:3b lokal über Ollama

Die ersten drei laufen ohne Gebühren, das vierte auf dem eigenen Server. In der Praxis greift Stufe zwei häufig, weil das stärkste Modell regelmäßig ins Anfragelimit läuft. Der Wechsel steht im Protokoll, der Lauf geht ohne Unterbrechung weiter.

Die lokale Stufe ist ausdrücklich Notnagel: Ein 3-Milliarden-Modell auf vier CPU-Kernen beherrscht kein zuverlässiges Werkzeug-Aufrufen. Es hält die Oberfläche am Leben, es baut keine Anwendungen.

Absicherung

Ein Agent mit Shell-Zugriff und Deploy-Rechten ist ein ernstes Risiko. Vier Ebenen:

Eigener Benutzer ohne Anmeldemöglichkeit, eigenes Heimatverzeichnis.

Pfad-Käfig. Jeder Dateizugriff wird über realpath aufgelöst und gegen den Projektordner geprüft. Ein ../ führt zum Abbruch, nicht zum Schreibzugriff.

Sperrliste für Befehle: rm -rf /, systemctl stop, pkill, Pipes nach sh, Zugriff auf das Anmeldedaten-Verzeichnis und die Umgebungsdatei anderer Dienste.

Zugangsdaten liegen in einer Datei mit Zugriffsrecht 600 und werden dem Agenten nur als Umgebungsvariable durchgereicht. Sie erscheinen in keinem Protokoll und in keiner Ausgabe.

Das Deploy-Token ist auf ein Konto und eine Zone begrenzt und hat nur Schreibrechte für Workers, Pages und Routen. Kein DNS, kein Zugriff auf andere Projekte.

Inhaltliche Regeln

Der Agent bekommt Regeln mit, die im Betrieb wichtiger sind als jede technische Vorgabe:

Echte Umlaute, keine Ersatzschreibweisen
Keine erfundenen Zahlen, Referenzen oder Nutzerangaben
Feste Verbotsliste bei Werbesprache
Gestaltungsvorgaben, die zum bestehenden Auftritt passen

Nach jedem Lauf wird das Ergebnis maschinell dagegen geprüft. Der Punkt mit den erfundenen Angaben ist der wichtigste: Ein Sprachmodell erfindet Kundenzahlen und Partnerlogos, wenn man es lässt.

Stack-Entscheidung

Der Agent wählt zwischen zwei Wegen:

Einfach — reines HTML, CSS, etwas JavaScript. Kein Build, keine Abhängigkeiten. Für Info-Seiten, Formulare, Rechner.

Komplex — React mit Vite und Tailwind, Karten über Leaflet, Diagramme über Chart.js. Für Oberflächen mit echter Interaktion.

Faustregel im Systemprompt: Zeigt die Seite nur an, nimm einfach. Verändert der Nutzer laufend etwas und die Ansicht reagiert darauf, nimm komplex.

Im Test hat der Agent bei einer Infoseite korrekt den einfachen Weg gewählt und kein npm angefasst. Das war die Absicht: Die meisten kleinen Anwendungen brauchen kein Framework, und jede vermiedene Abhängigkeit ist ein vermiedener Fehler.

Veröffentlichung

Vier Ziele, alle ohne laufende Gebühren:

Ziel	Adresse
Cloudflare Workers	`{name}.workers.dev`
Cloudflare Pages	`{name}.pages.dev`
Netlify	`{name}.netlify.app`
Vercel	`{name}.vercel.app`

Dazu eigene Unteradressen der Hauptdomain für alles, was ein Kunde sieht.

Alle drei Anbieter sind angebunden und getestet.

Erfahrungen aus dem Aufbau

Zwei Sprachmodelle mit Werkzeug-Aufrufen, eines ohne. Von drei geprüften Modellen bei Groq beherrschten zwei zuverlässiges Werkzeug-Aufrufen, das dritte gab nur Text zurück. Vor dem Einbau prüfen, nicht auf das Datenblatt verlassen.

Groq lehnt die Standard-Kennung von Python ab. Anfragen über urllib scheitern mit Fehler 403, bis eine eigene Kennung gesetzt wird. Über curl funktioniert dieselbe Anfrage. Hat eine Weile gekostet.

Die Netlify-Kommandozeile scheitert in dieser Umgebung. Fehler beim Abrufen der Projektdaten, reproduzierbar. Der Umweg über die Schnittstelle mit einem selbstgebauten Helfer funktioniert zuverlässig.

Die Vercel-Kommandozeile blockiert, wenn das Heimatverzeichnis auf den Projektordner zeigt. Sie stellt dann eine Rückfrage und wartet endlos. Eigenes Heimatverzeichnis löst es.

Frische Adressen antworten kurz mit 404. Bis zu 60 Sekunden nach dem ersten Deploy. Das ist Namensauflösung, kein Fehler. Ohne dieses Wissen deployt man dreimal hintereinander.

Ausführungsgrenzen der Oberfläche. Das Hosting-Paket bricht nach 30 Sekunden ab, Agentenläufe dauern länger. Lösung: abgekoppelt starten, Protokoll getrennt abfragen.

Speicherplatz ist der eigentliche Feind. node_modules füllen eine kleine Platte schnell. Zweimal bei 94 Prozent gelandet. Jetzt räumt ein täglicher Auftrag auf und leert ab 88 Prozent alles.

Offene Punkte

Selbstprüfung. Der Agent kontrolliert sein Ergebnis noch nicht gegen die Regeln. Ein zweiter Durchlauf ist geplant, der Umlaute, Verbotsliste und Gestaltung prüft und bei Verstoß korrigieren lässt.

Vorlagen. Jeder Lauf beginnt bei null. Fertige Grundgerüste würden Runden und Fehler sparen.

Keine Sperre bei gleichzeitigen Läufen. Zwei Läufe im selben Projektordner würden sich stören.

Kein Rückbau. Der Agent kann veröffentlichen, aber nichts zurücknehmen. Bewusst so, weil Löschrechte für einen autonomen Prozess gefährlicher sind als aufräumen von Hand.

Fragen an Fachleute

Konkret interessiert mich:

Ist der Pfad-Käfig ausreichend? Auflösung über realpath plus Präfix-Prüfung, dazu eine Sperrliste per regulärem Ausdruck für Befehle. Reicht das gegen ein Modell, das Umgehungen probieren würde, oder braucht es echte Trennung über Container?

Sperrliste oder Erlaubnisliste? Aktuell darf der Agent alles außer dem Gesperrten. Eine Erlaubnisliste wäre sicherer, aber unbrauchbar unflexibel. Wo liegt die vernünftige Grenze?

40 Runden als Obergrenze — zu viel, zu wenig? Beobachtet werden 2 bis 5 Runden bei einfachen Aufgaben.

Anbieter-Kette: Beim Wechsel geht die bisherige Unterhaltung mit. Modelle unterschiedlicher Hersteller reagieren verschieden auf denselben Verlauf. Ist das ein Problem in der Praxis?

Selbstprüfung durch dasselbe Modell — sinnvoll, oder braucht es dafür zwingend ein anderes?

Was fehlt, das aus Erfahrung im Betrieb weh tut?

Rahmenbedingungen

Kein Team, keine Finanzierung. Ein virtueller Server für 6,49 Euro im Monat, ein Shared-Hosting-Paket, Modell-Zugänge und Veröffentlichungsziele ohne laufende Gebühren.

Die Beschränkung ist Absicht: Was hier läuft, muss ohne laufende Kosten funktionieren, sonst trägt es sich nicht.

Rückmeldungen willkommen. Die Netzhandwerker · netzhandwerker.de