So ist lx-labs entstanden: Vibecoding mit Claude Code
Wie ich lx-labs im Dialog mit Claude Code gebaut habe — mit festen Spielregeln, einem Team aus KI-Agenten und einer ehrlichen Liste der Fehler.
lx-labs habe ich nicht Zeile für Zeile programmiert, sondern im Dialog mit Claude Code gebaut: Ich beschreibe, was ich will, die KI schlägt vor, baut, testet und bringt es auf den Server. Die Entscheidungen treffe ich. In ein paar Tagen ist so aus einem Ordner mit nichts als meinen Brand-Guidelines diese Website entstanden – mit Blog, vier Tools, 3D-Modellen, Suche und einer App, die auf Wunsch auch offline funktioniert.
Die Spielregeln
Damit die Zusammenarbeit funktioniert, gelten feste Regeln, die Claude bei jedem Start liest:
- Kurz antworten – keine Einleitung, keine Wiederholung meiner Frage.
- Nur die beste Lösung, dazu kurz die Nachteile. Keine Liste mit fünf Varianten.
- Höchstens drei Rückfragen, gesammelt in einer Nachricht.
Dazu kommt eine Projektdatei mit allem, was die KI über lx-labs wissen muss: Farben und Schriften aus den Brand-Guidelines, Aufbau des Codes, wie deployt wird und welche Daten nie auf Screenshots gehören. Bei größeren Umbauten, etwa der neuen Rubrik „Projekte“, lasse ich mir erst einen Vorschlag machen und entscheide dann.
Ein Team aus Agenten
Für größere Aufgaben arbeitet Claude mit einem Team aus Agenten, jeder mit eigener Rolle:
| Rolle | Aufgabe |
|---|---|
| Research | Fakten und Quellen prüfen |
| Coding | umsetzen |
| QM/Testing | im echten Browser testen, auch offline |
| Code-Review | Fehler und Denkfehler finden |
| Security | Sicherheit und Datenschutz prüfen |
Research hat zum Beispiel die Maße für die Einschmelzgewinde direkt aus den Maßtabellen der Hersteller geholt. Code-Review und Security haben den Offline-Modus geprüft und fünf Befunde geliefert – einer davon: Die Datenschutzerklärung hat nicht genau beschrieben, was wirklich passiert. Ohne diesen zweiten Blick wäre das so online gegangen.
Was schiefging
Vibecoding heißt nicht, dass alles auf Anhieb klappt. Eine Auswahl:
- Die App ließ sich nicht installieren. Das Handy meldete nur „Diese App kann nicht installiert werden“. Grund: Im Manifest stand
display: browser. Eine Zeile, großer Effekt. - Der Offline-Modus lief anfangs automatisch. Technisch sauber, rechtlich nicht ganz eindeutig. Jetzt schaltest du ihn in der App selbst ein – und wieder aus.
- „Dein Vibe. Deine Tools.“ klang, als würde ich Software für andere bauen. Daraus wurde „Mein Vibe. Meine Tools.“
- Am Handy ließ sich „4k7“ nicht eintippen, weil der Elektronik-Rechner nur die Zahlentastatur öffnete. Jetzt kommt die normale Tastatur.
- Ein Hilfsskript hat in einer Datei jedes „c“ durch ein „l“ ersetzt. Der Fehler fiel sofort auf, Git hatte die alte Fassung – zwei Minuten später war alles repariert.
- Direkt nach dem Deploy gab es kurz einen Fehler 502, weil der Server noch startete. Das Deploy-Skript wartet jetzt, bis die Seite antwortet.
- Die strenge Sicherheitsrichtlinie hat die Code-Farben im Blog blockiert. Die kamen als Inline-Styles. Jetzt färbt ein anderer Highlighter über Klassen – in den lx-labs-Farben.
Was ich daraus mitnehme
- Klare Entscheidungen beschleunigen alles. Die KI liefert Vorschläge mit Vor- und Nachteilen, ich wähle.
- Testen lassen, nicht nur bauen lassen. Automatische Tests im echten Browser prüfen jede größere Änderung – vom Offline-Modus bis zur Sicherheitsrichtlinie.
- Selbst ausprobieren. Zwei der Fehler oben habe ich am eigenen Handy gefunden.
- Git ist das Sicherheitsnetz. Jede Änderung ist ein Commit, kaputt geht nichts dauerhaft.
- Recht und Datenschutz früh prüfen. Offline-Speicher, Lizenzen fremder Dienste, Namensnennung bei Remixen: Das ist auch bei einer privaten Seite ein Thema.
Fazit
Vibecoding fühlt sich an wie Arbeiten mit einem sehr schnellen Team, das nie müde wird – solange jemand weiß, wo es hingehen soll. Diese Seite ist das erste Ergebnis. Die nächsten Projekte liegen schon auf dem Basteltisch.
