Vibe Coding Best Practices: wann man zu Agentic Coding wechselt

Was ist Vibe Coding und was unterscheidet es von Agentic Coding?

In früheren Beiträgen haben wir die Bausteine eines Coding-Agenten einzeln behandelt: Hooks, Subagenten, Skills, Worktrees, Auto Mode und Sandbox. Dieser Beitrag bündelt sie in einer Frage: Was braucht gutes Vibe Coding, und wo tappt man in die Falle? Jede Gewohnheit beschreiben wir kurz und verlinken den Beitrag, der sie ausführlich behandelt.

Den Begriff prägte Andrej Karpathy am 2. Februar 2025 auf X. In seinem Beitrag, wie Wikipedia ihn zitiert, beschrieb er, wie er arbeitete: Er nahm jede Änderung mit “Accept All” an, las die Diffs nicht mehr und gab Fehlermeldungen kommentarlos an den Agenten zurück. Mit seinen Worten war das für Wochenendprojekte, die man danach wegwirft, gar nicht so schlecht. Kurz gesagt: Beim Vibe Coding lässt man die KI Code schreiben, ohne ihn zu lesen, und schaut nur auf das Ergebnis.

Simon Willisons Beitrag vom 6. Mai 2026 zieht die Grenze deutlich. Für ihn heißt Vibe Coding, ohne jeden Blick auf den Code zu arbeiten: Vielleicht können Sie gar nicht programmieren, Sie sagen, was Sie wollen, und wenn es läuft, ist es gut. Bei einem Tool, das nur Sie nutzen und dessen Fehler nur Sie treffen, spricht nichts dagegen. Wenn Sie aber Software für andere bauen, ist Vibe Coding “grossly irresponsible”, denn unter Ihren Fehlern leiden andere. Das Gegenstück ist Agentic Engineering: Ein Softwareentwickler, der Sicherheit, Wartbarkeit, Betrieb und Performance versteht, setzt diese Tools ein. Die Tools selbst heißen Agentic-Coding-Tools: nach Anthropics Definition ein Agent, der Code liest, Dateien bearbeitet und Befehle ausführt. Agentic Coding ist also die Arbeitsweise, bei der der Agent den Code selbstständig schreibt und ausführt; ob es Vibe Coding oder Agentic Engineering ist, entscheidet sich daran, ob Sie das Ergebnis lesen und die Verantwortung dafür übernehmen.

Auf dieser Grenze bauen auch die Empfehlungen in diesem Beitrag auf. In einem Tool, das Sie selbst nutzen, in einem Prototyp oder beim Lernen ist Vibe Coding unbedenklich. Code, den andere nutzen, der Nutzerdaten speichert oder Logins oder Zahlungen annimmt, sollten Sie dagegen nicht ungelesen veröffentlichen. Die Gewohnheiten weiter unten bringen Vibe Coding näher an ein Agentic Coding, für das jemand die Verantwortung übernommen hat.

Auch im Deutschen wird meist der englische Begriff verwendet. Wer wissen will, wie Programmieren mit KI allgemein heißt: KI-gestütztes Programmieren (AI-assisted coding); Vibe Coding ist das Ende davon, an dem niemand den Code liest. Zwei weitere Begriffe werden oft damit verwechselt. Spec-Driven Development ist fast das Gegenteil: Der Agent schreibt vor dem Code eine Spezifikation, einen Plan und eine Aufgabenliste. Harness Engineering ist ein anderes Thema: Es beschreibt die Struktur, die Sie um das Modell herum bauen.

Was hat sich diesen Herbst bei den Coding-Tools geändert?

Im September und Oktober haben sich alle fünf Tools in dieselbe Richtung bewegt: Der Agent fragt Sie seltener, arbeitet länger allein und öfter parallel. Aus den Release Notes:

Quelle: Release Notes der Tools, 21. Oktober 2026. Versionen: Claude Code 2.1.284 und 2.1.286, Codex CLI 0.162.0, Antigravity CLI 1.3.5; die Copilot-Zeile stammt aus den September-Releases von VS Code. Google hat Gemini CLI am 18. Juni 2026 für Abonnenten von Google AI Pro und Ultra sowie für kostenlose Nutzer abgeschaltet und durch Antigravity CLI ersetzt; Unternehmen und wer einen bezahlten API-Schlüssel nutzt, können Gemini CLI weiter verwenden.

Die gemeinsame Richtung ist klar: Der Agent führt eine Aufgabe länger durch, ohne Sie zu fragen. Freigabe-Rückfragen wurden ohnehin meist ungelesen bestätigt; die Messungen der Anbieter dazu haben wir im Beitrag über Auto Mode und Sandbox beschrieben. Die eigentliche Kontrolle muss in der Schleife des Agenten sitzen und auch dann greifen, wenn Sie nicht zusehen: ein Test, ein Hook, die CI. Genau das macht die Änderung um verify in Claude Code: Vor dem Commit lässt sie die Prüfung laufen, die Sie geschrieben haben.

Was sagt die Forschung über Apps, die mit Vibe Coding entstanden sind?

Im August und September sind drei Studien erschienen oder aktualisiert worden; alle drei stehen auf arXiv und sind Preprints, die noch nicht von Fachkollegen begutachtet wurden. Die größte ist die Studie von Deng, Fan und Meng; ihre neueste Fassung ist vom 14. September 2026. Die Forschenden sammelten 9.041 Open-Source-Apps, die mit Claude Code und Lovable gebaut wurden, prüften die 200 davon, die öffentlich erreichbar waren, und fanden 1.186 Sicherheitslücken. Mögliche Lücken ermittelten zuerst KI-Prüfer; dann sahen sich zwei Autoren mit Sicherheitswissen jeden Kandidaten getrennt an, und als Lücke zählte er nur, wenn beide ihn für ausnutzbar hielten.

Das Ergebnis: 91 % der Apps hatten mindestens eine Lücke, und 65,77 % der Lücken waren als kritisch oder hoch eingestuft. Sie häufen sich bei der Zugriffskontrolle (Broken Access Control), bei Injection und bei der Authentifizierung. Die Zugriffskontrolle ist der Teil, der dafür sorgt, dass ein Nutzer nur an seine eigenen Daten kommt; fehlt sie, läuft die App trotzdem, deshalb fällt es in einer Demo nicht auf.

Die Forschenden haben einen Teil dieser Lücken auch nachgestellt, um zu sehen, was hilft. Am stärksten verringerten sie zwei Dinge: ein Prompt, der produktionsreifen Code zur Bedingung dafür macht, dass die Aufgabe als erledigt gilt, und ein Harness mit zusätzlichen Sicherheitsprüfungen. Keine Einstellung beseitigte aber alle. Ein weiteres Ergebnis fällt auf: In 90 der 434 Läufe, in denen eine Lücke ausgelöst wurde (20,7 %), erkannte der Agent das Risiko selbst und schrieb den unsicheren Code trotzdem; oft hinterließ er statt einer Korrektur eine Warnung oder einen Kommentar. Dass der Agent das Risiko kennt, reicht nicht; die Prüfung muss laufen, bevor die Aufgabe fertig ist.

Andročecs Studie vom 21. August 2026 stellt eine kleine, aber direkte Frage. Sie ließ jede der 6 Web-Apps zweimal vom selben Agenten mit demselben Modell schreiben, jeweils in einem Durchgang. Der einzige Unterschied zwischen den beiden Prompts war ein Abschnitt mit Sicherheitsanforderungen am Ende des zweiten. Die Fassung mit Sicherheitsanforderungen hatte in jeder App weniger bestätigte Feststellungen (24 gegenüber 51), und keine davon war kritisch oder hoch. Die schwerste Feststellung fand allerdings nur der manuelle Test. Der Autor warnt selbst: Die Stichprobe ist klein, jede Fassung wurde nur einmal erzeugt; die Ergebnisse sind Beobachtungen, kein statistischer Effekt.

Kraishans Studie (12. September 2026) schaut auf etwas anderes: Was wird aus den Pull Requests von Agenten nach dem Merge? Sie verglich 37.623 Pull Requests von fünf kommerziellen Agenten mit Pull Requests von Menschen in denselben Repositorys. Das Ergebnis ist “vendor-specific rather than uniform”: In den 90 Tagen nach dem Merge ließ sich die Revert-Quote von 3 der fünf Agenten statistisch nicht von der menschlichen unterscheiden, einer wurde seltener, einer häufiger zurückgenommen. Verdächtige Muster wie fest eingetragene Zugangsdaten oder eval kamen im Code der Agenten seltener vor als bei Menschen; das ist aber eine Suche nach Mustern, keine bestätigten Lücken. Die Daten stammen aus der Zeit von Dezember 2024 bis Juli 2025; über die Rangfolge der heutigen Tools und Modelle sagen sie nichts. Wie man so einen Vergleich liest, haben wir im Beitrag über SWE-bench beschrieben.

Auch Entwickler vertrauen am meisten dem, was sie prüfen können. In der Stack-Overflow-Umfrage 2026, veröffentlicht am 6. Oktober (mehr als 30.000 Teilnehmende; keine Zufallsstichprobe, sondern freiwillige Antworten), sagten 48 % der Teilnehmenden, dass sie KI vertrauen, wenn sie die Antwort leicht überprüfen können. Die meisten Gewohnheiten weiter unten sollen genau das erleichtern.

Worin sind sich die Leitfäden der fünf Tools einig?

Alle fünf Tools haben einen eigenen Best-Practices-Leitfaden. Am 21. Oktober 2026 haben wir alle gelesen und ihre Ratschläge zum selben Thema nebeneinandergestellt. Für Copilot haben wir drei Leitfäden von GitHub zusammen gelesen (VS Code, Copilot CLI und den Cloud-Agenten); der von Cursor ist ein Blogbeitrag vom 9. Januar 2026, die anderen sind undatiert. In wie vielen Leitfäden jede der sechs Gewohnheiten vorkommt:

Bei 3 Gewohnheiten sind sich die fünf Leitfäden einig. Die übrigen 3 stehen in 4 Leitfäden; der Leitfaden von Antigravity CLI erwähnt sie nicht, empfiehlt aber, bei großen Aufgaben parallele Subagenten im Hintergrund laufen zu lassen, und die CLI hat eine Ansicht /diff, die die Änderungen zeigt. Was jeder Leitfaden sagt:

Quelle: Best-Practices-Leitfäden der fünf Tools, 21. Oktober 2026. Die Copilot-Spalte stammt aus den Leitfäden zu VS Code, Copilot CLI und dem Cloud-Agenten von Copilot. Jede Zelle gibt den Satz des Leitfadens gekürzt wieder. „Steht nicht im Leitfaden“ heißt: In dem Leitfaden, den wir an dem Tag gelesen haben, fanden wir keinen Satz dazu; in anderen Dokumenten des Tools kann es stehen.

Prüfung. Der Agent hört auf, wenn die Aufgabe fertig aussieht. Laut dem Leitfaden von Claude Code ist ohne eine Prüfung, die er ausführen kann, “looks done” das einzige Signal, das er hat, und jeder Fehler wartet darauf, dass Sie ihn bemerken. Tests, ein Build, ein Linter oder ein Skript, das die Ausgabe mit einem Beispiel vergleicht: Alles, was sich als bestanden oder nicht bestanden lesen lässt, taugt. Sagt der Agent „die Tests laufen durch“, fragen Sie nach dem Befehl, den er ausgeführt hat, und nach dessen Ausgabe. Eine Oberfläche kann der Agent im Browser prüfen; wie man daraus einen dauerhaften Playwright-Test macht, steht im Beitrag über Computer Use.

Plan. Ein Plan verhindert, dass der Agent das falsche Problem löst. Der Leitfaden von Claude Code sagt auch, wann Sie ihn weglassen können: Lässt sich der Diff in einem Satz beschreiben, braucht es keinen; sind Sie beim Ansatz unsicher, berührt die Änderung mehrere Dateien oder kennen Sie den Code nicht, lassen Sie planen. Auch der Leitfaden von Cursor hält es bei kleinen Aufgaben, die Sie schon oft erledigt haben, für in Ordnung, direkt zum Agenten zu gehen. Bei einem großen Feature ist der nächste Schritt nach dem Plan eine Spezifikation; wann sie hilft, steht im Beitrag über Spec-Driven Development.

Regeldatei. Codex und Cursor empfehlen denselben Weg: kurz anfangen und eine Regel ergänzen, wenn der Agent einen Fehler wiederholt. Der Leitfaden von Codex sagt: Macht der Agent denselben Fehler zweimal, bitten Sie ihn um eine Rückschau und aktualisieren Sie AGENTS.md. Welches Tool welche Datei liest, steht im Beitrag über AGENTS.md und CLAUDE.md. Für eine Regel, die jedes Mal gelten muss, reicht eine Datei nicht; laut dem Leitfaden von Claude Code ist eine Anweisung eine Empfehlung, ein Hook dagegen läuft jedes Mal (Beitrag über Hooks). Ein Prompt, den Sie ständig wiederholen, kann ein Skill werden. Dieselbe Datei hilft auch beim Review. Unser Tool für KI-Code-Review, diffox, liest beim Prüfen eines Pull Requests die AGENTS.md des Repositorys (oder, wenn es keine gibt, die CLAUDE.md) aus dem Branch, in den der Pull Request gemergt wird. Die Sätze darin, die eine Pflicht ausdrücken (etwa “must”, “never”, „muss“, „niemals“), nutzt es als Regeln dafür, was als Fehler gilt.

Die Änderung lesen. Der Leitfaden von Cursor nennt den Grund kurz: Von KI geschriebener Code kann richtig aussehen und im Detail falsch sein, und je schneller der Agent arbeitet, desto wichtiger wird das Review. Der Leitfaden von Claude Code empfiehlt, das Review in einem frischen Kontext machen zu lassen: Ein Subagent, der nur den Diff und die Kriterien sieht, lässt sich von den Überlegungen der Sitzung, die die Änderung geschrieben hat, nicht beeinflussen. Wie ein Subagent arbeitet, steht im Beitrag über Subagenten, worauf ein Mensch achten sollte, im Beitrag über das Review von KI-generiertem Code.

Parallele Arbeit. Zwei Agenten im selben Ordner können gegenseitig ihre Dateien ändern. Der Leitfaden von Codex zählt parallele Aufgaben an denselben Dateien ohne Worktrees zu den Fehlern; auch Claude Code, Cursor und Copilot empfehlen, jede Sitzung in einem eigenen Worktree oder Ordner laufen zu lassen. Was ein Worktree trennt und was nicht, steht im Beitrag über Git-Worktrees.

Frische Sitzung. Je länger das Gespräch, desto mehr füllt sich der Kontext mit Details, die nichts zur Sache tun, und die Leistung des Agenten sinkt. Der Leitfaden von Claude Code rät: Liegt der Agent beim selben Punkt nach zwei Korrekturen immer noch daneben, leeren Sie die Sitzung und beginnen neu, mit einem besseren Prompt, der enthält, was Sie gelernt haben. Was beim Zusammenfassen einer langen Aufgabe verloren geht, steht im Beitrag über Auto-Compact.

Wo gehen die Leitfäden auseinander?

Die Leitfäden sagen nicht überall dasselbe. An vier Stellen gehen sie auseinander; welche Seite zu Ihnen passt, hängt von Ihrer Arbeit ab.

• Wie viel Detail gehört an den Anfang? Codex will in jedem Prompt vier Dinge: das Ziel, den Kontext, die Einschränkungen und wann die Aufgabe als erledigt gilt. Der Leitfaden zum Cloud-Agenten von Copilot verlangt eine klare Beschreibung, vollständige Abnahmekriterien und die Dateien, die sich ändern sollen, fügt aber hinzu, dass der Agent den richtigen Code oft auch ohne Dateipfade selbst findet. Auch Claude Code will, dass Sie Dateien, Einschränkungen und Beispielmuster nennen. Cursor dagegen sagt: Kennen Sie die Datei, markieren Sie sie, sonst überlassen Sie die Suche dem Agenten; Dateien, die nichts zur Sache tun, können ihn verwirren.
• Muss man jede Feststellung aus dem Review beheben? Der Leitfaden von Claude Code warnt: Ein Reviewer, der Lücken finden soll, findet meist welche, auch wenn die Arbeit solide ist. Wer jeder Feststellung hinterherläuft, landet bei unnötigen Schichten, defensivem Code und Tests für Fälle, die nicht eintreten können. Der Leitfaden empfiehlt, den Reviewer nur Lücken melden zu lassen, die die Korrektheit oder die genannten Anforderungen betreffen. Die Leitfäden von Cursor und Copilot beschreiben Review-Tools ohne diese Warnung.
• Wann sollte man automatisieren? Der Leitfaden von Codex zählt es zu den Fehlern, eine Aufgabe zeitgesteuert laufen zu lassen, die von Hand noch nicht zuverlässig klappt: erst einen Skill daraus machen und sie zeitgesteuert ausführen, sobald sie vorhersehbar ist. Die Neuerungen dieses Herbsts machen das Zeitsteuern aber leichter; die Automationen von Copilot und Projects in Cursor können Aufgaben ausführen, ohne dass Sie darum bitten. Bevor Sie sie einschalten, stellen Sie die Frage von Codex: Klappt diese Aufgabe von Hand zuverlässig?
• Welche Aufgaben sollte man dem Agenten nicht geben? Ausdrücklich sagt das nur der Leitfaden von Copilot. Er zählt Aufgaben auf, die Sie vielleicht lieber selbst übernehmen, statt sie dem Agenten zu geben: kritische Probleme in der Produktion; Arbeit, die Sicherheit, personenbezogene Daten oder Authentifizierung berührt; unklar definierte Aufgaben und Themen, die Sie selbst lernen wollen. Die anderen vier Leitfäden haben keine solche Liste.

Was sind die Fallstricke beim Vibe Coding?

Zwei Leitfäden führen typische Fehler zusätzlich in einer Liste: der von Claude Code mit 5 Punkten, der von Codex mit 8. Hier überschneiden sich die beiden Listen: jede Aufgabe in einer einzigen langen Sitzung erledigen, dem Agenten keinen Weg geben, seine Arbeit zu prüfen, und Regeln an die falsche Stelle setzen (bei Claude Code eine aufgeblähte CLAUDE.md, bei Codex dauerhafte Regeln in jedem Prompt). Ein Satz aus der Liste von Claude Code klingt wie die Zusammenfassung dieses Beitrags: Was Sie nicht überprüfen können, sollten Sie nicht ausliefern.

In die fünf Fallstricke weiter unten sind wir selbst getappt, als wir im eigenen Repository mit Coding-Agenten gearbeitet haben; nach jedem haben wir eine Regel in die Regeldatei unseres Repositorys geschrieben. Alle stammen aus einem einzigen Repository, sind also keine Statistik; hinter jedem steht aber ein echter Fehler. Die Fragen, die wir stellen, wenn der Agent „fertig“ sagt:

• Läuft der Test, der lokal durchläuft, auch in der CI durch? Bei uns wich die lokale Umgebung an mehreren Stellen von der CI ab: eine .env-Datei, die lokal gelesen wurde, ein Paket, das in der CI anders installiert wurde, und eine Prüfung, die nur in der CI läuft. Umgebungsvariablen zu löschen, verhinderte nicht, dass die .env-Datei gelesen wurde; eine fehlende Installationsoption ließ außerdem einen korrekten Branch rot erscheinen und führte zu einer falschen Diagnose. Unsere Regel lautet jetzt: Ein lokales Ergebnis wird nie als CI-Ergebnis gemeldet, ein CI-Fehler wird in einem sauberen Klon ohne .env nachgestellt, und nach dem Push sieht man in der CI selbst nach.
• Ist das Ergebnis leer, weil der Schritt gelaufen ist? In einem unserer Protokolle sahen ein sauberer Lauf und ein Lauf, in dem ein Teil der Schritte gescheitert war, genau gleich aus; beide hinterließen eine leere Liste von Feststellungen. Jetzt hält das Protokoll auch fest, ob die Schritte gelaufen sind und wie viele Ergebnisse sie geliefert haben; ein leeres Ergebnis und ein toter Schritt lassen sich am Protokoll unterscheiden. Sehen Sie im Code des Agenten eine Zeile, die einen Fehler abfängt und eine leere Liste zurückgibt, stellen Sie dieselbe Frage.
• Wurde ein fehlender Wert als 0 gelesen? Einer unserer Berichte las einen nie gemessenen Wert als 0 und schrieb “100% saving” neben eine Arbeit, die tatsächlich erledigt worden war; derselbe Fehler legte außerdem unbemerkt eine Prüfung still. Ein nicht gemessener Wert sollte None bleiben und gelesen werden, indem man prüft, ob der Schlüssel vorhanden ist:

# Beispiel: Ein nicht gemessener Wert sollte None sein, nicht 0
seconds = record.get("seconds") or 0   # falsch: fehlt der Schlüssel, wird daraus 0
seconds = record["seconds"] if "seconds" in record else None   # richtig

or 0 macht aus einem fehlenden Schlüssel und aus None gleichermaßen eine Null. Diese Null fließt dann in einen Durchschnitt oder einen Schwellenwert ein und lässt nie gemessene Arbeit kostenlos oder erfolgreich aussehen.

• Wurde die .env auf dem Bildschirm ausgegeben? Einmal haben wir die .env-Datei mit sed maskiert ausgegeben. Weil nicht jede Zeile die Form KEY=value hat, übersprang die Maske eine Zeile, und der Schlüssel darin war unmaskiert zu sehen. Heute fragen wir die Umgebung, ob ein Schlüssel existiert, nicht die Datei; ihr Inhalt wird nicht ausgegeben, auch nicht maskiert. Welche Tools den Agenten von vornherein daran hindern, geheime Dateien zu lesen, steht im Beitrag über die Sandbox.
• Gibt es den genannten Pfad, die Adresse oder das Paket wirklich? Eine unserer Messnotizen nannte als Quelle einen Ordner, den es auf keinem Branch gibt. In einem Entwurf, der gekürzte Dateinamen vervollständigte, war der Großteil der vervollständigten Namen falsch. Heute prüft ein Tool bei jedem Pfad in einer Quellenzeile, ob er auf der Festplatte existiert; auch das Tool, das diesen Blog baut, lehnt einen Quellpfad ab, der sich nicht öffnen lässt. Warum Sie die Pakete, die der Agent vorschlägt, eigens prüfen sollten, steht im Beitrag über das Review.

Allen fünf gemeinsam ist der Unterschied zwischen „fertig“ und „sieht fertig aus“. Der Rat aus dem Leitfaden von Claude Code gilt auch hier: Verlangen Sie vom Agenten nicht die Behauptung, dass es geklappt hat, sondern den Beleg, also den Befehl, den er ausgeführt hat, und die Ausgabe, die zurückkam.

Welche Gewohnheiten braucht welche Aufgabe?

Nicht jede Aufgabe braucht jede Gewohnheit. Bei einer Korrektur, die sich in einem Satz beschreiben lässt, können Sie den Plan weglassen; bei Code, der Nutzerdaten berührt, nicht das Lesen. Grob gibt es vier Fälle:

Die Fälle im Einzelnen und dazu ein paar Sonderfälle:

• Ein Tool oder Prototyp, den nur Sie nutzen. Wie Willison sagt: Trifft ein Fehler nur Sie, spricht nichts gegen Vibe Coding. Committen Sie trotzdem oft, damit Sie zurückkönnen, und legen Sie Schlüssel in die Umgebung, nicht in den Code.
• Eine kleine Korrektur in einem echten Repository. Lassen Sie den Plan weg, aber nicht die Prüfung; der Diff ist kurz, also ist er auch schnell gelesen. Wenn Sie einen Fehler beheben, halten Sie sich an die Reihenfolge aus dem Leitfaden von Claude Code: zuerst ein Test, der den Fehler nachstellt und fehlschlägt, dann die Korrektur.
• Ein Feature über mehrere Dateien oder Code, den Sie nicht kennen. Zuerst ein Plan, bei großen Aufgaben eine Spezifikation; lassen Sie die Tests vor dem Code schreiben und die Änderung in einem frischen Kontext prüfen. Wann ein Spitzenmodell und mehr Effort bei langen, unklaren Aufgaben einen Unterschied machen, steht in den Beiträgen über die Modellwahl und Effort.
• Unbeaufsichtigte Läufe und parallele Agenten. Im Auto Mode, beim Cloud-Agenten oder in einer zeitgesteuerten Aufgabe ist niemand da, den der Agent fragen könnte. Legen Sie die Prüfung in einen Hook oder in die CI, halten Sie die Berechtigungen eng, schalten Sie die Sandbox ein, geben Sie jedem Agenten einen eigenen Worktree, und verlangen Sie am Ende Belege statt Behauptungen. Berechtigungen und Sandbox behandelt der Beitrag über Auto Mode und Sandbox.
• Nutzerdaten, Login, Zahlungen und Geheimnisse. Schreiben Sie die Sicherheitsanforderungen ausdrücklich in den Prompt; in Andročecs Studie verringerte allein das die Feststellungen in jeder App. Die schwerste Feststellung fand aber trotzdem der manuelle Test: Diesen Code sollte ein Mensch lesen.
• Bevor Sie eine mit Vibe Coding gebaute App für alle öffnen. Die Lücken, die Deng und Kollegen gefunden haben, liegen vor allem in der Zugriffskontrolle und der Authentifizierung. Probieren Sie selbst aus, ob ein Nutzer die Daten eines anderen sehen kann und ob sich eine geschützte Seite ohne Login erreichen lässt.
• Ein Repository, das Sie nicht kennen. Bevor Sie es mit einem Agenten öffnen, sehen Sie nach, welche Dateien darin von selbst laufen können; welche das sind, steht im Beitrag über Workspace Trust.