Vibe Coding? Klar, aber strategisch!

Marketing-Expertinnen erstellen ihre eigenen kleinen Apps. Software-Startups werden von Menschen gegründet, die keine Ahnung von Softwareerstellung haben. Und im privaten Bereich boomen die Experimente.

Systeme, wie Lovable, Cursor, ChatGPT Codex, Gemini oder Claude Code machen es möglich: Einfach einen kurzen Prompt schreiben und schon erhält man eine Website, eine App oder ein anderes Stück Software, das genau das macht, was man will, und es sieht auch noch klasse aus. OK, meistens klappt es nicht auf Anhieb, aber zwei, drei Korrekturprompts und man kommt dem gewünschten Ergebnis schon sehr nah.

Trotzdem, komplexere Entwicklungen benötigen viel mehr.

Natürlich habe ich auch damit experimentiert und war mehr als erstaunt: Einen Tag lang Gedanken machen, wie eine Anwendung aussehen soll. Ein Tag im Dialog mit Lovable. Zwei Tage Debugging, also Lovable sagen, welche Fehler es beseitigen muss.

Das Ergebnis: Ein funktionierendes System, für das ich in meinen früheren Unternehmen ein Team von drei Entwicklern und drei Monate Zeit gebraucht hätte. Es war schon faszinierend.

Auch bei den KI-Manger:innen, die ich derzeit en masse ausbilde, ist Begeisterung zu spüren, wenn sie die ersten Versuche machen. Und tatsächlich kann es jede und jeder.

Das glaubt ihr nicht? Dann probiert es einfach aus:

* Die Begrenzung auf HTML, Javascript und CSS sorgt dafür, dass alles im Browser funktioniert, ohne Server im Hintergrund

Das kann schon beeindrucken und ist für so kleine Apps durchaus ausreichend, nicht jedoch, wenn man größere Anwendungen und Systeme entwickeln will. Doch auch dafür gibt es Hilfen.

Ja, es ist ganz einfach, mit einem kurzen Prompt eine funktionierende App zu erstellen. Aber reicht das? Ich habe jahrelang Unternehmen geführt, die Software entwickelt haben. Ich habe selbst einige Zehntausend Zeilen Code beigetragen (es war qualitativ nie der beste Teil) und ich besitze ein Zertifikat als Softwarearchitekt.

Diese Erfahrung möchte ich nicht missen. Sie hilft mir auch beim Vibe-Coding dafür zu sorgen, dass Systeme sinnvoll designt werden, die Fachbegriffe zu zu verstehen, Fehler zu erkennen und mit dem LLM zu diskutieren.

Das alles ist hilfreich, aber nicht jede:r kann und muss darauf zurückgreifen. Tatsächlich sind KI-Systeme oftmals in der Lage, recht guten Code auf akzeptablem Sicherheitsniveau zu schreiben. Gerade von den Sicherheitsfeatures war ich nach meinen ersten Versuchen überrascht.

Wahr ist aber auch, dass KI-Systeme, die beim Coden assistieren, noch zu oft schlechte Leistung abliefern.

Bei kleinen Apps mag das egal sein. Werden komplexere Systeme entwickelt, kumulieren die Probleme und fallen einem früher oder später auf die Füße. Ein Produktivsystem kann so nicht entwickelt werden.

Die Systeme besitzen unglaubliches Wissen, natürlich auch über gute Softwareentwicklung. Allerdings bringen sie es nur zur vollen Entfaltung, wenn man sie dazu anleitet. Im Laufe der Zeit haben sich für mich die folgenden Praktiken als Qualitätsbooster herausgestellt:

Selbst planen

Natürlich kann man einem LLM einen sehr unscharf formulierten Prompt für die Erstellung einer App geben. Das, was fehlt, ergänzen die Systeme selbstständig aufgrund von Annahmen. Die können natürlich vollkommen falsch sein und man verliert mit diesem Vorgehen Kontrolle über die Entwicklung. Besser ist es, sich vorab Gedanken über die einzelnen Module, Funktionen und insbesondere die Datenstrukturen zu machen. Dann alles zeichnerisch auf einem großen Blatt Papier zu visualisieren, ist sehr hilfreich.

Gemeinsam planen

Auch wenn alles auf Papier steht, geht es nicht sofort an die Umsetzung. Komplexere Systeme werden Schritt für Schritt entwickelt, nicht in einem Rutsch. Dabei können wir das Best-Practice-Wissen des Systems nutzen. Also laden wir eine grobe Beschreibung der App, die wir entwickeln wollen, erst einmal hoch und bitte per Prompt um Mithilfe:

"Bevor wir an die Umsetzung gehen, lass uns das Projekt diskutieren. Welche Fragen hast du? Welche Anmerkungen und Verbesserungsvorschläge hast du? Wie würdest du Schritt für Schritt die Umsetzung planen?"

Diese Diskussion bringt in der Regel noch einige signifikante Verbesserungen zutage.

Auch wenn ihr später ins Detail geht und Modul für Modul eure App entwickelt, ist es vor jedem Programmierschritt sinnvoll, zunächst den nächsten Schritt zu umreißen und dann die oben genannten Fragen zu stellen. Damit kann das LLM seine Qualitäten bereits in der Planungsphase einbringen und grobe Fehler vermeiden.

Entwickeln lassen

Wenn ein gemeinsamer Plan steht, könnt ihr dem System den Befehl geben, den Entwicklungsschritt auszuführen. Auch hier kann es wieder sinnvoll sein, auf Dialog zu bauen, zum Beispiel, wenn ihr hinzufügt:

"Wenn es an einer Stelle Schwierigkeiten gibt oder eine Entscheidung über unterschiedliche Wege der Umsetzung notwendig wird, stoppe die Entwicklung, informiere mich darüber und lass uns gemeinsam die beste Lösung finden."

Testen

Eigentlich ist es selbstverständlich, ich möchte es dennoch erwähnen. Nach jedem Programmierschritt sollten die neu erstellten Module und Funktionen ausführlich getestet werden. Dass nicht alles auf Anhieb so funktioniert, wie gewünscht, ist normal. Dann kann man Schritt für Schritt die Fehler im Dialog mit dem LLM beseitigen. Wichtig ist dabei oftmals das Rückmelden von Meldungen aus der Browser-Konsole, die man über das Browsermenü und die Werkzeuge für Webentwickler erreicht.

Prinzipien guter Entwicklung verbindlich machen

Es gibt eine ganze Reihe von Prinzipien der Softwareentwicklung, die zu guten und sicheren Systemen führen. Im Prinzip kennen die LLMs alle, aber sie sind selten aktiv. Man muss sie aktiv zur Grundlage der gemeinsamen Entwicklung machen. Ich habe dafür eine Markdown-Datei entwickelt, die ich dem entwickelnden System mit auf den Weg gebe**. Dazu speichere ich sie im Projekt und verweise darauf. Oder ich lade sie explizit mit einem Prompt hoch. Ihr könnt diese Datei hier herunterladen:

https://empowerment-team.berlin/download?f=CONVENTIONS.md

Wer aus der Programmierung kommt, wird Vieles wiederfinden, was Code besser und sicherer macht. Für diejenigen, die damit bisher keine oder wenig Berührung hatten, lohnt sich die Lektüre, um ein fundamentaleres Verständnis zu gewinnen. Gerade für Letztere habe ich den Punkt 15 eingefügt.

Refaktorisieren

Trotz aller bisher beschriebenen Maßnahmen, wird der entstehende Code nicht optimal sein. Das ist auch bei menschlichen Entwicklern so, wenn immer wieder Korrekturen eingearbeitet werden. Dann ist nach Abschluss der Entwicklung an einem Modul eine Überarbeitung des Codes notwendig, im Fachjargon „Refaktorisierung“. Das beherrschen LLMs wieder hervorragend, wenn man folgenden Prompt sendet:

"Überprüfe Modul [Name des Moduls], inwiefern eine Refaktorisierung zu besserer Performance, höherer Sicherheit oder besserem Coding-Stil führen kann. Berücksichtige dabei die Prinzipien in CONVENTIONS.md und führe die Refaktorisierung aus." (Ja, die Systeme "vergessen" oft, dass es CONVENTIONS.md gibt.)

Lernen und Weiterentwickeln

Ich habe schon Punkt 15 in CONVENTIONS.md erwähnt. Er ist die Anweisung, von Zeit zu Zeit kleine "Lerneinheiten" an euch auszuspielen. Je mehr ihr über gute Softwareentwicklung lernt, desto besser werden eure Lösungen.

Eine weitere spannende Möglichkeit ergibt sich, wenn ihr schon eine Weile gemeinsam mit dem LLM entwickelt habt. Dann fragt doch das System einfach mal:

"Du kennst mich jetzt schon eine Weile aus unserer Zusammenarbeit an dieser App. Gib mir eine Rückmeldung, wie wir unsere Zusammenarbeit verbessern können: Was mache ich gut? Was sollte ich verbessern? Was fehlt dir in unserer Zusammenarbeit?"

Die Antwort wird auf jeden Fall hilfreich sein.

Menschliche Überprüfung

Alles hier Genannte reicht definitiv nicht, um ein System oder eine App in den Produktivbetrieb zu überführen. Dafür braucht es eine ganze Menge Tests und eine Überprüfung durch erfahrene Software-Spezialisten. Wenn ihr die Tipps aus diesem Artikel anwendet, entsteht zumindest Code, der gut lesbar und nachvollziehbar ist. Eine Grundlage für die Überführung in ein Produktivsystem.

Die Hürden, selbst eigene kleine Apps, Webseiten oder sogar komplexere Systeme zu erstellen, sind auf ein historisch niedriges Niveau gesunken. Auch die Kosten sind überschaubar. In der Regel reicht der Einsteigertarif eines LLMs, um erste, spannende Projekte zu starten.

Probiert es einfach aus!


** Ein Teil der Inhalte ist von einem Artikel von Noah Byteforge inspiriert, der wesentliche Punkte gut zusammenfasst: Why Mission-Critical Engineers Write Code Completely Differently (And Why Their Systems Don’t Wake Them at Night)