Technologie · Vibecoding
Diese Website ist im Dialog mit einem Sprachmodell entstanden — Layout, Farbsystem, die Beiträge, die Erweiterungen im Hintergrund. Das Ergebnis sehen Sie gerade. Was Sie nicht sehen, ist der Teil, der beim Vibecoding tatsächlich über Erfolg entscheidet: die Leitplanken drumherum.
„Vibecoding“ beschreibt das Programmieren im Gespräch: Man sagt, was man will, das Modell schreibt den Code, man schaut sich das Ergebnis an. Das funktioniert erstaunlich gut — und geht auf eine Weise schief, die sich von klassischen Programmierfehlern unterscheidet. Dieser Text beschreibt beides, an einem echten Projekt.
Der Aufbau
Drei Entscheidungen, die alles Weitere getragen haben
-
Inhalte gehören ins Repository, nicht ins CMS
Jede Seite entsteht als HTML-Fragment im Projektverzeichnis, versioniert, und wird von dort veröffentlicht. Der Vorteil zeigt sich beim zweiten Mal: Änderungen sind nachvollziehbar, ein Rückweg existiert, und das Modell kann die Datei lesen, statt sie zu erraten. Wer im Web-Editor arbeitet, hat nach drei Iterationen keinen Verlauf mehr.
-
Ein Ort für Gestaltungswerte
Farben, Schriften, Abstände stehen in einer einzigen Datei als CSS-Variablen. Anfangs trug jede Seite ihre eigenen Werte — bis zur zweiten Seite ging das gut, danach begann das Auseinanderdriften. Heute ändert eine Zeile die Farbe überall; die Seiten kennen nur noch Namen wie „Grundton“ und „gesichert“, keine Hexwerte.
-
Erweiterungen neben dem Theme, nicht darin
Alles, was das eingesetzte Theme nicht kann — Design-Tokens laden, rechtliche Links im Fuß ausgeben, Vorschaubilder für geteilte Links, Kategorietexte anzeigen — läuft als kleine, eigenständige Erweiterung daneben. Jede erfüllt genau eine Aufgabe und lässt sich durch Löschen einer Datei zurücknehmen. Ein Theme-Update kann sie nicht überschreiben, ein Theme-Wechsel nicht mitreißen.
Alle drei Entscheidungen haben dasselbe Motiv: Reversibilität. Beim Vibecoding entsteht viel Code in kurzer Zeit, und ein Teil davon ist falsch. Was sich nicht in einem Schritt zurücknehmen lässt, wird zur Hypothek.
Werkzeuge
Womit gearbeitet wird
Ein Modell mit Werkzeugzugriff
Entscheidend ist nicht die Chatoberfläche, sondern dass das Modell Dateien lesen, Befehle ausführen und Ergebnisse prüfen kann. Werkzeuge wie Claude Code, Aider oder Cursor tun das; ein reines Chatfenster zwingt zum Kopieren und verliert dabei den Zusammenhang.
Git, von Anfang an
Nicht verhandelbar. Vibecoding erzeugt Änderungen schneller, als man sie prüfen kann — ohne Versionsverwaltung gibt es keinen Weg zurück zu „vor zwanzig Minuten, als es noch ging“. Kleine Commits mit Begründung, auch wenn niemand sonst hineinschaut.
Der echte Browser
Ein Modell kann sein Ergebnis nicht sehen. Es prüft, indem es Text durchsucht — und das genügt nicht: Fehlerhaftes Markup ist im Quelltext vollständig vorhanden und im Browser trotzdem kaputt. Prüfen heißt: die Seite laden und messen, was tatsächlich ankommt.
Notizen außerhalb des Chats
Jede Sitzung beginnt bei null. Was gelernt wurde — Entscheidungen, Fallen, Konventionen — gehört in Dateien, die das Modell beim nächsten Mal wieder liest. Markdown im Repository, Obsidian, egal: Hauptsache außerhalb des Gesprächsverlaufs.
Wissen konservieren
Anweisungsdateien und Skills
Der größte Unterschied zwischen „nettes Spielzeug“ und „ernsthaftes Werkzeug“ liegt darin, ob das Modell die Regeln des Projekts kennt, ohne dass man sie jedes Mal wiederholt. Dafür gibt es zwei Ebenen:
| Ebene | Was hineingehört | Wann sie greift |
|---|---|---|
| Anweisungsdatei im Projekt | Konventionen, Verzeichnisstruktur, Namensschemata, was verboten ist, wie veröffentlicht wird | Immer — sie wird zu Beginn jeder Sitzung gelesen |
| Skills — abrufbare Anleitungen | Abläufe, die nur manchmal gebraucht werden: eine Veröffentlichungsroutine, eine Prüfliste, ein Rechercheverfahren | Auf Abruf, wenn die Aufgabe dazu passt |
Die Faustregel: Was in jeder Sitzung gilt, gehört in die Anweisungsdatei — aber knapp, denn alles darin kostet bei jeder Anfrage Platz. Was nur gelegentlich gebraucht wird, gehört in einen Skill, der bei Bedarf geladen wird. Ein aufgeblähtes Dauerregelwerk wird schlechter befolgt als ein kurzes.
Der wertvollste Eintrag ist die Falle von gestern
Jeder Fehler, der einmal Zeit gekostet hat, gehört als Zeile in diese Dateien — mitsamt der Erkennungsmethode. Genau das verwandelt eine Sitzung in dauerhaften Fortschritt, statt dieselbe Sackgasse in vier Wochen erneut zu betreten.
Aus der Praxis
Vier Fallen, die diese Website gekostet hat
Alle vier haben eines gemeinsam: Sie sahen nach Erfolg aus. Genau das macht sie gefährlich.
Das System zerlegt, was der Assistent geschrieben hat
Ein Diagramm war im Quelltext vollständig vorhanden — auf der Seite blieb ein leerer Rahmen. Ursache: Das Redaktionssystem fügt in Textabsätze automatisch Formatierung ein und zerbrach dabei die Grafik. Die Prüfung per Textsuche meldete „vorhanden“, weil das Markup ja dastand. Lehre: Zwischen „steht im Code“ und „funktioniert im Browser“ liegt eine Verarbeitungskette, die man mitprüfen muss.
Das Prüfwerkzeug war älter als der Code
Eine Syntaxprüfung meldete Fehler in einer fehlerfreien Datei — sie lief gegen eine über zwanzig Jahre alte Version der Sprache, während die Anwendung längst eine aktuelle nutzte. Schlimmer: Weil die Befehle verkettet waren, brach der falsche Alarm die restliche Veröffentlichung stillschweigend ab. Lehre: Ein Werkzeug, das man zur Kontrolle einsetzt, gehört selbst kontrolliert — und Befehlsketten verschlucken Zwischenfehler.
Zwei Bildwerkzeuge, zwei verschiedene Wahrheiten
Dieselbe Grafik sah je nach Umwandlungswerkzeug völlig anders aus: Das eine ignorierte Transparenz und malte schwarze Flächen, das andere schnitt den rechten Rand ab. Beide meldeten Erfolg. Lehre: Erzeugte Bilder muss man ansehen, nicht nur erzeugen — und wenn ein Ergebnis merkwürdig aussieht, ist der Renderer ein ebenso plausibler Verdächtiger wie die Quelle.
Ein Dunkelmodus, den nur die halbe Seite kannte
Die selbst gebauten Bereiche folgten der Systemeinstellung und wurden dunkel — das Theme drumherum konnte das nicht und blieb hell samt dunkler Schrift. Ergebnis: dunkler Text auf dunkler Fläche. Lehre: Wer in eine bestehende Umgebung hineinbaut, erbt deren Grenzen. Eine Funktion, die nur der eigene Teil beherrscht, erzeugt einen Bruch statt einer Verbesserung.
Dos
Was verlässlich hilft
Am echten Ergebnis prüfen lassen
Nicht „ist der Text drin“, sondern: Seite laden, Elemente zählen, Farben und Kontraste messen. Diese Prüfung lässt sich beschreiben und wiederholen — und sie fängt genau die Fehler, die eine Textsuche nicht sieht.
Vor dem Überschreiben sichern
Bestehende Inhalte vor jeder Ersetzung wegkopieren, unaufgefordert. Der Assistent schlägt sonst gern die vollständige Neufassung vor — die in neun von zehn Fällen besser ist und im zehnten alles Gewachsene entfernt.
Widerspruch erwarten und einfordern
Ein Modell stimmt gern zu. Fragen wie „was spricht dagegen“ oder „was habe ich übersehen“ liefern regelmäßig mehr als eine Bestätigung. Besonders wertvoll: nach der fertigen Lösung fragen, welche Annahme darin ungeprüft ist.
In kleinen Schritten veröffentlichen
Eine Änderung, eine Prüfung, ein Zwischenstand. Wer fünf Dinge gleichzeitig ausrollt und danach einen Fehler sieht, weiß nicht, welches davon ihn verursacht hat — und der Assistent weiß es auch nicht.
Don’ts
Was zuverlässig schiefgeht
Erfolgsmeldungen ungeprüft glauben
„Fertig und verifiziert“ bedeutet: Das Modell hat eine Prüfung durchgeführt, die es selbst gewählt hat. War sie ungeeignet, ist die Meldung trotzdem zuversichtlich. Bei allem Sichtbaren gilt: einmal selbst hinsehen.
Zugangsdaten in den Dialog geben
Weder ins Gespräch noch in Befehle, deren Ausgabe im Verlauf landet. Zugänge gehören in Schlüsselverwaltungen und Konfigurationsdateien, auf die verwiesen wird — Werte fließen durch Pipes, nicht durch Bildschirmausgaben.
Direkt auf dem Live-System herumbauen
Verlockend, weil es schnell geht. Aber jeder Zwischenstand ist öffentlich, und ein misslungener Schritt ist eine Störung statt eines verworfenen Versuchs. Entwurfsfassungen und lokale Vorschauen kosten Minuten und ersparen Peinlichkeiten.
Umfang und Prüfung zugleich vergrößern
Je mehr auf einmal entsteht, desto oberflächlicher wird die Kontrolle — beim Menschen wie beim Modell. Fünf Beiträge in einem Durchgang sind machbar; fünf Beiträge und ein neues Layout in einem Durchgang sind es nicht.
Sicherheit
Leitplanken, die vor dem ersten Prompt stehen
Der Assistent kennt den Unterschied zwischen einer harmlosen und einer heiklen Information nicht von allein. Was für die eigene Umgebung gilt, muss aufgeschrieben sein — und zwar bevor der erste Text entsteht, nicht als Korrektur danach.
| Leitplanke | Wie sie wirkt |
|---|---|
| Eine Regeldatei, was nie nach draußen darf | Zugangsdaten, interne Adressen und Gerätenamen, ungelöste Schwachstellen, personenbezogene Daten Dritter. Steht das nicht geschrieben, landet es irgendwann in einem Beitrag — nicht aus Böswilligkeit, sondern weil es zum Thema passte. |
| Eine maschinelle Prüfung vor jeder Veröffentlichung | Eine Mustersuche über die fertige Datei nach Adressen, Schlüsselwörtern, Zugangsdaten. Kostet Sekunden und fängt das, was beim Schreiben durchgerutscht ist. Sie ersetzt das Lesen nicht — sie fängt nur, was Muster hat. |
| Ein Freigabeschritt für heikle Themen | Bestimmte Bereiche werden vorbereitet, aber nie selbsttätig veröffentlicht. Der Assistent legt einen Entwurf an und hält an; ein Mensch liest und gibt frei. Das ist die einzige Stelle, an der zusätzliche Reibung wirklich lohnt. |
| Keine fremden Ressourcen ohne Absicht | Eingebundene Schriften, Skripte oder Bilder von fremden Servern übertragen Besucherdaten dorthin. Beim schnellen Bauen entsteht so etwas nebenbei — die Prüfung darauf gehört fest in die Liste. |
Diese Site trägt zusätzlich einen sichtbaren Hinweis unter jedem maschinell erstellten Text. Das ist teils rechtliche Vorsicht, vor allem aber Konsequenz: Wer Belege einfordert, sollte bei der eigenen Arbeitsweise nicht schweigen.
Pflegbarkeit
Damit es in einem Jahr noch änderbar ist
Vibecoding erzeugt schnell viel Code, den niemand Zeile für Zeile gelesen hat. Das ist beherrschbar — aber nur mit ein paar Regeln, die dem Wachstum entgegenstehen:
Jeder Wert nur an einer Stelle. Sobald derselbe Farbwert, dieselbe Adresse, dieselbe Kennzahl zweimal auftaucht, driften die Kopien auseinander. Das passiert beim Vibecoding schneller als bei Handarbeit, weil das Modell bereitwillig dupliziert, statt nach dem vorhandenen Ort zu fragen.
Kommentare, die das Warum tragen. Nicht was der Code tut — das steht da —, sondern warum er so aussieht. Eine Zeile wie „diese Ausnahme, weil das Theme seine Farben über ID-Selektoren setzt und sonst gewinnt“ verhindert, dass jemand sie in sechs Monaten als überflüssig entfernt. Solche Begründungen zu verlangen, ist die wirksamste einzelne Anweisung an das Modell.
Umkehrbarkeit vor Eleganz. Die schönere Lösung, die tief ins bestehende System eingreift, ist selten die bessere. Was sich durch Löschen einer Datei zurücknehmen lässt, erlaubt Experimente ohne Angst — und Angst ist der eigentliche Feind der Pflege.
Der Assistent schreibt den Code. Verantwortlich für das Ergebnis ist, wer ihn veröffentlicht.
Bilanz
Lohnt es sich?
Für diese Site: eindeutig ja. Sie hat in kurzer Zeit ein durchgehendes Farbsystem, ein wiederverwendbares Beitragslayout, mehrere Erweiterungen und ein Dutzend Texte bekommen — Arbeit, die von Hand über Wochen gegangen wäre und deshalb vermutlich nie stattgefunden hätte.
Der Preis ist eine andere Art von Aufmerksamkeit. Nicht mehr „wie schreibe ich das“, sondern „stimmt das, was da behauptet wird“. Die Fehler sind seltener syntaktisch und häufiger sachlich: eine Zahl, die aus der Erinnerung statt aus den Daten kam; eine Prüfung, die nichts geprüft hat; ein „passt“ auf etwas, das nicht passte. Wer diesen Teil ernst nimmt, bekommt ein sehr schnelles Werkzeug. Wer ihn überspringt, bekommt eine Website, die aussieht, als hätte sie jemand geprüft.