Vibe Coding vs. Verantwortung

Vibe Coding fühlt sich an wie ein Cheatcode.

Du schreibst einen Satz, drückst Enter, und plötzlich existiert etwas, das gestern noch ein Team gebraucht hätte. Das Dopamin ist echt. Der Fortschritt ist sichtbar. Und genau deshalb passiert der Fehler so häufig: Wir verwechseln Geschwindigkeit mit Reife.

Eine Demo kann dich täuschen. Produktion kann dich ruinieren.

Die eine Frage, die Vibe Coding nicht beantworten kann

Wenn dein System nichts tut außer hübsch auszusehen, ist fast alles erlaubt.

Aber sobald es Geld bewegt, Daten verarbeitet oder Entscheidungen trifft, wird eine Frage brutal wichtig:

Was passiert, wenn es falsch liegt? „Falsch“ ist nicht hypothetisch. Falsch ist garantiert. Die einzige Variable ist: Wie oft und wie teuer.

Demo vs. Produktion: Zwei völlig verschiedene Kostenmodelle

Demo ist billig, weil die Konsequenzen billig sind.

kein echtes Risiko
keine echten Nutzer
keine echten Daten
keine echten Angriffe Produktion ist teuer, weil das System plötzlich in der Wirklichkeit lebt.
Support-Tickets sind ein Feature.
Monitoring ist ein Produktbestandteil.
Security ist kein Add-on, sondern eine Eigenschaft. Und hier kommt die unbequeme Wahrheit:

Wer „schnell“ baut, ohne „sicher“ zu bauen, baut nur die Rechnung später.

Agenten machen es schlimmer (und deswegen auch besser)

Ein Skript macht, was du geschrieben hast.

Ein Agent macht, was er verstanden zu haben glaubt.

Das ist mächtig – weil er in Lücken navigieren kann. Aber es ist riskant – weil Lücken auch dort entstehen, wo du dachtest, du wärst präzise.

Agenten sind ein Multiplikator:

Gute Architektur wird sehr gut.
Schlechte Architektur wird katastrophal schnell. Wenn du einem Agenten Zugriff gibst, gibst du ihm nicht nur Fähigkeiten. Du gibst ihm Handlungsraum. Und Handlungsraum ohne Leitplanken ist kein „Autonomie-Feature“. Es ist ein unkontrollierter Vertrag mit der Realität.

Drei Mini-Cases, die man nicht ignorieren sollte

1) Der „harmlos“ wirkende Agent

Ein Agent, der Retreats plant, Termine koordiniert oder To-dos sortiert, klingt unschuldig.

Bis er: - interne Kalenderdaten verarbeitet - Personenlisten abfragt - E-Mails verschickt - oder „nur kurz“ ein Tool mit Admin-Rechten nutzt

Das Risiko entsteht selten aus dem Zweck. Es entsteht aus der Berechtigung.

2) Passwortmanager & Sicherheitsgefühl

Passwortmanager sind ein gutes Beispiel für eine gefährliche Illusion: „Es fühlt sich sicher an.“

Aber Sicherheit ist kein Gefühl. Sicherheit ist eine Reihe von Eigenschaften:

Angriffsflächen reduziert
Secrets korrekt behandelt
Updates & Supply Chain bedacht
Recovery & Device-Loss klar Wenn du hier vibe-codest, baust du nicht nur Bugs. Du baust Vertrauen, das du nicht verdienen kannst.

3) „Der Agent soll Misbehavior melden“

Die Idee, Agenten so zu trainieren, dass sie Fehlverhalten selbst reporten, ist spannend.

Aber sie ist auch ein Reminder:

Du brauchst Mechanismen, die gegen Anreize arbeiten. Wenn ein System ein Ziel optimiert, optimiert es manchmal auch Wege, die du nicht vorgesehen hast. Darum muss Kontrolle nicht „weniger Autonomie“ bedeuten. Sie bedeutet: richtiges Feedback.

Definition of Done (Agenten-Edition)

Hier ist meine kompromisslose Liste. Nicht als Dogma – als Ausgangspunkt.

1) Grenzen (Policy) sind Code, nicht Hoffnung

Welche Tools darf der Agent benutzen?
Welche Daten darf er sehen?
Welche Aktionen sind immer verboten?
Was erfordert menschliche Bestätigung? Wenn du das nicht beantworten kannst, bist du nicht „noch nicht fertig“. Du bist noch nicht gestartet.

2) Observability: Ohne Logs kein Vertrauen

strukturierte Logs (wer tat was, wann, mit welchen Inputs)
Korrelation (Request-ID)
Fehlerkategorien (nicht nur Stacktraces)
Metriken, die Alarm auslösen

3) Tests, die wirklich wehtun

Unit Tests sind Hygiene. Aber Agenten brauchen zusätzlich:
„golden paths“ (funktioniert der Happy Case?)
„evil paths“ (was passiert bei Prompt Injection / weird inputs?)
Regression (wird es schlechter, ohne dass du es merkst?)

4) Rollback ist kein Plan B – es ist Teil von Plan A
Feature Flags
Versioniertes Deployment
Datenmigrationen mit Rückweg

5) Least Privilege oder gar nichts

Wenn ein Agent mehr Rechte hat als er braucht, ist das kein Komfort. Das ist eine Einladung.

Der Kill-Switch: Das unspektakulärste, wichtigste Feature

Agenten sind schnell. Fehler sind schneller.

Wenn du genau eine Sache heute ergänzen willst, dann diese:

Ein „Stop“-Knopf (Feature Flag / Schalter / Not-Aus)
Rate Limits (pro Minute, pro User, pro Endpoint)
ein harter Timeout für Aktionen
ein Audit-Log, das du auch um 02:15 Uhr lesen kannst Autonomie ohne Not-Aus ist wie ein Auto ohne Bremse. Es fährt fantastisch – bis zur ersten Kurve.

Automation vs. Autonomie (und warum das kein Wortspiel ist)

Automation ist: „Wenn X, dann Y.“ Autonomie ist: „Wenn X, dann finde einen Weg.“

Das zweite braucht eine Ethik aus Technik:

Welche Wege sind erlaubt?
Welche sind verboten?
Welche brauchen Bestätigung? Wenn du das nicht definierst, definieren es die Zufälle.

Produktions-Checkliste in 60 Sekunden

Wenn du ein agentisches Feature shippen willst, und du hast nur eine Minute:

Welche Daten kann es sehen? 2) Welche Actions kann es ausführen? 3) Wo ist der Stop-Knopf? 4) Wo sind die Logs? 5) Was ist der Worst Case? 6) Wie erkennst du ihn schnell? 7) Wie rollst du zurück? 8) Wie testest du Prompt Injection? 9) Welche Secrets sind betroffen? 10) Wer wird um 03:00 Uhr angerufen?

Wenn du bei #10 lachst: Glückwunsch. Du baust in Produktion.

Was du ab heute anders machen kannst

Wenn du vibe-codest (und ja: ich tue das auch), dann mach es so:

Vibe zuerst – aber nur im Sandkasten. 2) Sobald es ernst wird: Messung vor Magie. 3) Keine Veröffentlichung ohne: - Logs - Tests - Grenzen - Rollback

Das ist nicht „langsam“. Das ist professionell.

Und professionell ist in 2026 nicht die Kür. Es ist der einzige Weg, wie dieser Boom nicht in einem Haufen verbrannter Vertrauenskredite endet.

Nächstes Mal: Prompt Injection als Social Engineering mit Copy/Paste – und warum „nur Text“ die gefährlichste Schnittstelle überhaupt ist.