Vibe Coding mit Stimme: Wie du mit Cursor, Claude Code und Copilot beim Programmieren sprichst

„Vibe-Coding“ bedeutet, einem KI-Assistenten zu beschreiben, was du bauen möchtest, und ihn den Code schreiben zu lassen, während du die Richtung anleitest, prüfst und korrigierst. Tools wie Cursor, Claude Code, GitHub Copilot oder Windsurf machen das praktisch möglich. Der Engpass ist nicht mehr das Schreiben des Codes, sondern das Schreiben der Anweisungen. Und hier ist die Stimme unschlagbar.

Warum Sprechen das Tippen für Agenten schlägt

Ein Programmieragent braucht Kontext: was die App macht, was du probiert hast, welche Einschränkungen es gibt, wie „fertig“ aussieht. Geschrieben sind solche Nachrichten drei Zeilen lang. Gesprochen sind es zwanzig – und der Unterschied zeigt sich beim ersten Versuch des Agenten.

Getippt: „Behebe den Bug beim Login“
Gesprochen: „Beim Login bekommt der Nutzer, wenn er bereits eine abgelaufene Session im Cookie hat, Fehler 500 anstatt zur Anmeldeseite geleitet zu werden. Ich glaube, das Problem liegt in der Authentifizierungs-Middleware, die den Nutzer lesen will, bevor sie die Ablaufzeit prüft. Ändere nicht das Tokenformat, das wird auch von mobilen Apps benutzt. Füge außerdem einen Test hinzu, der diese Situation reproduziert.“

Arbeitsablauf

1. Du beschreibst die Aufgabe, indem du sprichst. Du setzt den Cursor in den Agenten-Chat und hältst Ctrl+Win. Dann sagst du, was du willst, warum, was nicht verändert werden soll und wie du das Ergebnis überprüfst.
2. Du lässt den Agenten einen Plan vorschlagen. Du liest den Plan und korrigierst ihn ebenfalls per Sprache: „Schritt drei ist nicht nötig, diese Funktion gibt es schon in utils.“
3. Du prüfst die Unterschiede. Wenn dir etwas komisch vorkommt, sagst du genau was: „Warum hast du die Validierung vom Controller ins Modell verschoben? Bring sie zurück, das Modell verwendet sie, und importiere aus Dateien, wo die Validierung unterschiedlich ist.“
4. Du behebst Probleme im Gespräch. Du fügst die Fehlermeldung ein und erklärst, was du rundherum beobachtet hast; der Agent bekommt so auch deine Hypothesen, nicht nur den Stacktrace.

Wörterbuch ist essenziell

Funktionsnamen, Tabellen- und Bibliotheksnamen sind der Albtraum jeder Diktierung: „use effect“, „get server side props“, „postgres“. Füge im Zicelo-Wörterbuch die Begriffe deines Projekts ein (useEffect, getServerSideProps, PostgreSQL, deine Klassennamen) – so werden sie genau so geschrieben. Zicelo behält auch englische Begriffe mitten im deutschen Satz bei, ohne sie „zu übersetzen“.

Was du nicht diktieren solltest

• Den eigentlichen Code. Diktiere keine Klammern, Punkte oder Kommas; beschreibe, was du willst, und der Agent schreibt den Code.
• Geheimnisse. Sprich Passwörter oder API-Schlüssel nicht laut aus – weder beim Diktieren noch im Agenten-Chat.

Befehlsmodus für PR- und Commit-Beschreibungen

Wenn du fertig bist, markierst du die Liste der Änderungen und sagst „Schreibe eine kurze Commit-Nachricht, im Imperativ, auf Englisch“ oder „Mach daraus eine Pull-Request-Beschreibung mit den Abschnitten Was, Warum, Wie ich getestet habe“. Dauert fünf Sekunden.

Einige gut funktionierende Diktier-Prompts

• „Bevor du etwas änderst, erkläre mir in fünf Zeilen, wie der Zahlungsablauf aktuell funktioniert, damit ich überprüfen kann, ob ich es richtig verstanden habe.“
• „Mach die kleinste Änderung, die das Problem behebt; refaktoriere nichts drumherum.“
• „Schreibe zuerst den fehlschlagenden Test, zeig ihn mir, und repariere dann.“
• „Suche im Projekt alle Stellen, die direkt aus der Bestelltabelle lesen, und sag mir, welche betroffen wären, wenn ich eine Pflichtspalte hinzufüge.“

Probier’s mal einen Tag: jede Anweisung an den Agenten, die länger als ein Satz ist, sprich sie aus. Lade Zicelo für Windows herunter.