Im ersten Teil habe ich beschrieben, was sich alles hinter einer einfachen kostenlosen App verbirgt. Im zweiten, wie das Wochenende aussah, an dem die App kaputtging.
Im ersten Teil habe ich beschrieben, was sich alles hinter einer einfachen kostenlosen App verbirgt. Im zweiten, wie das Wochenende aussah, an dem die App kaputtging. Dieser Teil handelt davon, warum Website, Web-App und Software in der Alltagssprache zu einer Sache verschmelzen, obwohl sie eine völlig andere Verantwortung und ein anderes Risiko tragen.
Drei verschiedene Dinge, die gleich aussehen
Bei einer Website stehen Sie immer zwischen dem Nutzer und dem Fehler. Bei einer Desktop-App nicht. Wenn die App abstürzt, stürzt sie dem Menschen auf seinem Rechner ab. Wenn Sie die Berechtigungen schlecht im Griff haben, greift sie auf seine Daten zu. Und wenn Sie sie reparieren müssen, müssen Sie hoffen, dass er die neue Version herunterlädt.

Was eine Website gar nicht löst
Zum Unterschied im Risiko kommen Dinge, denen Sie bei einer Website nie begegnen: das Signieren der App, Berechtigungen des Betriebssystems, das Verhalten beim Ruhezustand und Aufwachen, verschiedene Systemversionen, verschiedene Rechner, Installation, Deinstallation. Nichts davon kann die KI für Sie lösen, denn nichts davon hat mit dem Schreiben von Code zu tun.
Diakritika im Dateinamen zerschossen die Signatur der App. Der verschärfte Laufzeitmodus von macOS schaltete still den Zugriff auf den Kalender ab, sodass die App scheinbar in Ordnung war und dabei nicht funktionierte. Das Ziehen in den Papierkorb hinterließ Einstellungen, den Start nach der Anmeldung und eine Adresse im Schlüsselbund des Systems. Keine dieser Sachen hat dem Nutzer eine Funktion hinzugefügt, und ohne jede einzelne davon hätte man die App niemandem geben können.

Warum wir das überhaupt zeigen
Firmeninhaber und Leute, die über Budgets entscheiden, haben meist keinen technischen Hintergrund. Das ist völlig in Ordnung, es ist nicht ihr Fach. Es hat aber eine praktische Folge: Sie unterscheiden nicht zwischen einer Webseite, einer Web-App und Software. Alles sieht aus wie ein Bildschirm, auf dem etwas leuchtet. Und wenn diese drei Dinge zu einem verschmelzen, lässt sich nicht abschätzen, wie viel Arbeit dahintersteht und wer sie leisten kann.
Ptáček ist eine kleine App. Genau deshalb lässt sich an ihr zeigen, was klein bedeutet. Ein Tag Funktionalität und das Doppelte an Zeit für Dinge, die man nicht sieht.

Wo die Grenze zwischen Vibe Coding und Produktion liegt
Ich habe nichts gegen Vibe Coding, ich unterrichte es selbst und nutze es täglich. Nach fünftausend Stunden mit KI habe ich ein ziemlich klares Bild davon, wo die Grenze liegt.
Wo Vibe Coding hervorragend funktioniert: ein internes Tool für Sie und drei Kollegen, ein maßgeschneiderter Rechner, ein Prototyp, den Sie jemandem auf dem Bildschirm zeigen, ein Skript, das Ihnen am Freitag zwei Stunden spart. Dinge, bei denen Sie zugleich Autor und einziger Nutzer sind und bei denen ein Fehler bedeutet, dass Sie es noch einmal versuchen.
Wo es nicht mehr reicht: sobald es jemand Fremdes berührt. Ein Kunde, ein Kollege aus einem anderen Unternehmen, ein Besucher der Website, ein Mensch, der es herunterlädt. In diesem Moment geht es nicht mehr darum, ob es funktioniert, sondern darum, was passiert, wenn es nicht funktioniert. Und das ist eine andere Disziplin als das Schreiben von Code.

Ein paar Tipps zum Vibe Coding
Das sind keine allgemeinen Ratschläge aus dem Internet. Es sind sieben Dinge, die wir uns an der App Ptáček erarbeitet haben, manche schmerzhaft, an dem Wochenende, an dem sie kaputtging.
Testen Sie eine saubere Installation. Löschen Sie die App samt allen Einstellungen und installieren Sie sie neu, als sähen Sie sie zum ersten Mal. Bei uns hat das auf einen Schlag drei Dinge aufgedeckt. Durch Lesen des Codes hätten wir keines davon gefunden.
Lassen Sie das Ergebnis von einem zweiten Modell prüfen, das vom ersten nichts weiß. Nicht dasselbe Modell ein zweites Mal, ein anderes, mit anderer Aufgabe. Als die App am Wochenende kaputtging, ließen wir zwei unabhängige Audits laufen, und keines wusste vom anderen. Sie einigten sich auf die Ursache, und eines korrigierte das andere zudem im Detail.

Fragen Sie, was passiert, wenn das ausfällt. Das Modell antwortet nur auf Fragen, die es bekommt. Einen geerbten Update-Kanal, der auf das Repository eines fremden Autors zeigte, hat die KI von sich aus nicht erwähnt, weil sie niemand danach gefragt hat. Sie kann es finden, Sie müssen nur wissen, wonach Sie fragen sollen.
Sichern Sie den letzten funktionierenden Stand, damit Sie jederzeit dorthin zurückkehren können. In drei Tagen Fehlerbehebung haben wir drei Schritte zurück gemacht. Ohne das wären es nicht drei Fehler auf dem Weg gewesen, sondern ein unbehebbarer.
Schreiben Sie Tests vor allem für das, was etwas löscht oder ändert. In Ptáček gibt es nur eine Funktion, die etwas löscht, die Deinstallation, und sie hat eigene Tests, die sicherstellen, dass sie nichts anderes löscht. Der Rest der App liest und zeigt nur an.
Geben Sie dem Modell keine Geheimnisse in die Hand. Die Adresse des Kalenders ist faktisch ein Passwort, wer sie kennt, sieht, wann Sie Termine haben. Sie gehört nicht in eine Konfigurationsdatei, geschweige denn in ein Protokoll.

Unterscheiden Sie einen Fehler, der abstürzt, von einem Fehler, der schweigt. Einen Absturz sehen Sie sofort. Eine leere Antwort, die die App als „keine Termine“ auswertet, während in den Einstellungen grün leuchtet, dass alles in Ordnung ist, ist schlimmer, weil Sie nichts davon wissen, bis Ihnen ein Termin entgeht.
Deshalb lehren wir es so
In Vibe-Coding-Workshops sagen wir den Leuten nicht, dass sie sich jetzt ein Produkt bauen. Wir sagen ihnen, dass sie sich Tools für sich und das Team bauen, und das ist ein enormer Wert.
Und zugleich zeigen wir ihnen genau die Grenze, von der dieser Artikel handelt. Damit sie wissen, wann sie die App selbst bauen können und wann jemand nötig ist, der unbequeme Fragen stellt. Denn die teuerste Variante ist die, in der jemand eine Anwendung mit Kundendaten in die Welt lässt und es erst merkt, wenn es zu spät ist.

Prüfen, wem Sie das anvertrauen, können Sie bei jedem. Auch bei uns.
Und eine Frage an Sie: Wo liegt bei Ihnen diese Grenze? Wo lassen Sie Vibe Coding allein laufen, und wo rufen Sie schon jemanden, der jahrelange Praxis darin hat?
Der Artikel ist ursprünglich auf LinkedIn erschienen. Originalartikel auf LinkedIn

