Vibe Coding: eine kleine App bauen und Änderungen verstehen

Was Vibe Coding leistet – und was offen bleibt

Beim Vibe Coding entsteht Code aus einer Unterhaltung: Du beschreibst ein Ergebnis, lässt es umsetzen und reagierst auf den Entwurf. GitHub zeigt diese Arbeitsweise ausdrücklich für Prototypen, Anwendungsentwürfe und persönliche Projekte. Sie unterscheidet sich von einer einzelnen Codevervollständigung, weil die KI größere Teile des Aufbaus übernehmen kann.

Der Begriff wird unterschiedlich eng verwendet. Manche meinen damit weitgehend ungeprüftes Übernehmen, andere allgemein das Bauen per Prompt. Hier verwenden wir ihn als Einstieg in einen kontrollierbaren Ablauf. Sobald du Änderungen liest und Verhalten gezielt prüfst, ergänzt du die bloße Unterhaltung um wichtige Entwicklungsschritte.

Eine kleine Aufgabenliste ist dafür geeigneter als eine Anwendung mit Zahlungen, Kundendaten oder mehreren Berechtigungsrollen. Du kannst ihre Anforderungen überschauen und Fehler sichtbar machen, ohne zuerst einen gesamten Serverbetrieb aufzubauen.

Die Arbeitsumgebung begrenzen

Trenne drei Orte: Wo liegt der Code? Wo laufen Werkzeuge? Wo wird die Modellanfrage verarbeitet? Ein Agent kann Dateien auf deinem Rechner bearbeiten und trotzdem ein gehostetes Modell verwenden. „Im lokalen Editor“ bedeutet daher nicht automatisch „ohne Datenübertragung an einen Anbieter“. Wenn du diese Arbeit im Terminal organisieren möchtest, zeigt der Einstieg zu Aider im Terminal die Dateiauswahl und den anschließenden Diff-Check.

Öffne für den ersten Versuch einen überschaubaren Übungsordner. Verwende keine produktiven Zugangsdaten oder privaten Kundendokumente. Wähle ein Werkzeug, das dir Änderungen und ausgeführte Schritte sichtbar macht. Zum Vergleich kannst du KI-Coding-Tools nach Arbeitsweise auswählen.

Freigaben und Sandbox sind verschiedene Kontrollen. Eine Freigabe entscheidet, ob eine Aktion bestätigt werden muss. Eine Terminal-Sandbox begrenzt bestimmte Datei- und Netzwerkzugriffe. Sie deckt nicht automatisch jedes andere Werkzeug ab. Auch ein Git-Worktree trennt Änderungen, ist laut VS-Code-Dokumentation aber keine Sicherheitsgrenze.

Zur Werkzeugwahl gehört auch der Abrechnungspfad. Die Claude-Code-Kosten zeigen am konkreten Beispiel, warum ein vorhandenes Abo und eine Sitzung mit API-Schlüssel unterschiedlich abgerechnet werden können.

Eine erste Anwendung als kleinen Auftrag beschreiben

Lege Ziel, Eingaben und Abnahme fest. Für unsere Aufgabenliste genügt ein Textfeld, ein Status und ein Filter. Dauerhafte Speicherung, Konten und Versand gehören ausdrücklich nicht zum ersten Versuch. Eine solche Grenze ist hilfreich: Du erkennst, wenn ein Agent plötzlich eine unnötige Datenbank oder Anmeldung hinzufügt.

Baue eine kleine Aufgabenliste in HTML, CSS und JavaScript.
Ziel: Aufgaben anlegen, abhaken und nach Status filtern.
Grenzen: nur während dieses Seitenbesuchs, kein Konto, keine API, kein Versand, keine dauerhafte Speicherung.
Anforderungen:
- Leere Eingaben und reine Leerzeichen erzeugen keine Aufgabe.
- Zwei gleiche Titel bleiben getrennte Aufgaben mit stabilen IDs.
- Das Häkchen ändert nur die gewählte Aufgabe.
- Filter verändern keine Aufgaben.
- Eingaben erscheinen als Text, niemals als ausgeführtes HTML.
- Formular und Aufgaben sind mit Tastatur und schmalem Bildschirm bedienbar.
Erkläre zuerst den Aufbau und die Prüffälle. Ändere anschließend nur die nötigen Dateien. Installiere oder veröffentliche nichts ohne einen konkreten Auftrag.

Lass zuerst den Aufbau erklären. Frage nach den benötigten Dateien, dem Startweg und den geplanten Prüfungen. Prüfe Installations- und Netzwerkaktionen einzeln, bevor du sie zulässt. Eine breite Freigabe wird nicht allein dadurch sinnvoll, dass der Auftrag klein klingt.

Das ist eine eigene Lernvorlage. Sie ist kein aufgezeichnetes Ergebnis eines bestimmten Coding-Tools. Modelle reagieren unterschiedlich, und ein genauer Prompt garantiert nicht automatisch einen korrekten Entwurf.

Änderungen lesen und gezielt weiterarbeiten

Vergleiche nach jedem kleinen Schritt den neuen Zustand mit dem vorherigen. Dieser Unterschied heißt häufig Diff. Frage: Welche Dateien wurden geändert? Welche Funktion erklärt die Änderung? Sind zusätzliche Pakete, Datenübertragungen oder Rechte hinzugekommen?

Wenn die Liste funktioniert, aber der Filter falsch ist, beschreibe genau diesen Fehler. Ein brauchbarer Folgeauftrag nennt Ausgangszustand, Handlung und erwartetes Ergebnis: „Zwei Aufgaben sind offen, eine erledigt. Bei Nur offene erscheint trotzdem die erledigte Aufgabe. Korrigiere den Filter, ohne den Bestand zu verändern.“

Sichere einen überprüften Zwischenstand, bevor du die nächste Funktion hinzufügst. Ein Commit kann später beim Vergleichen und Zurückgehen helfen; er ist selbst keine Aussage über Codequalität. Übernimm nicht automatisch einen großen Umbau, wenn eine kleine Korrektur genügt.

Wenn dieselbe Prüfung regelmäßig gebraucht wird, kannst du Claude Skills als wiederverwendbare Prüfanleitung hinterlegen. Die Vorlage beschreibt dann den Ablauf; der konkrete Diff und die Abnahmekriterien bleiben Teil des jeweiligen Auftrags.

Funktion mit vorher festgelegten Fällen prüfen

Die folgende eigene Demo setzt den begrenzten Aufgabenlisten-Job direkt auf dieser Seite um. Sie ruft kein KI-Modell auf. Ihre Einträge leben nur im Arbeitsspeicher dieser Seite; beim Neuladen gehen sie verloren. Nutze fiktive Aufgaben, damit du die Prüfung ohne persönliche Inhalte nachvollziehen kannst.

Prüfe außerdem den Weg mit der Tastatur: Ist das Textfeld beschriftet, kannst du Aufgaben hinzufügen und die richtige Aufgabe abhaken? Kontrolliere eine schmale Ansicht. Eine bedienbare Oberfläche ist Teil der Funktion und wird durch einen erfolgreichen Code-Build nicht automatisch belegt.

Diese Fälle prüfen bewusst nur den beschriebenen Umfang. Sie sind weder ein vollständiges Sicherheitsaudit noch ein Test auf beliebige Angriffe oder Last. Die Auftragsvorlage mit Abnahmefällen herunterladen kannst du als Ausgangspunkt für dein eigenes Projekt verwenden.

Vor dem öffentlichen Betrieb erneut prüfen

Ein persönlicher Entwurf und eine Anwendung für andere Nutzer haben unterschiedliche Anforderungen. Vor einem öffentlichen Betrieb brauchst du unter anderem klare Verantwortlichkeiten, einen nachvollziehbaren Veröffentlichungsweg und passende Prüfungen für tatsächlich verwendete Daten, Abhängigkeiten und Zugänge.

Sobald Konten oder mehrere Rollen hinzukommen, reicht ein im Browser ausgeblendeter Button nicht als Berechtigungsprüfung. Wenn eine Anwendung Daten dauerhaft speichert, musst du auch Verlust, Wiederherstellung und Löschung konkret planen. Solche Funktionen sind deshalb nicht stillschweigend Teil unserer kleinen Lern-Demo.

Projektdateien und gelesene Seiten können außerdem Anweisungen enthalten, die dem eigentlichen Auftrag widersprechen. Lerne, fremde Anweisungen in Projektdateien zu erkennen, und begrenze tatsächliche Werkzeugrechte außerhalb des Prompts. GitHub empfiehlt, KI-Sicherheitsvorschläge zu prüfen und mit weiteren Verfahren zu kombinieren; sie ersetzen keine umfassende Sicherheitsprüfung.

Der nächste sinnvolle Schritt ist eine einzelne zusätzliche Funktion mit eigener Abnahme. Erst wenn du erklären kannst, was sich geändert hat und welche Grenzen offen bleiben, lässt sich die Entscheidung über einen größeren Einsatz fundiert treffen.