Was diese Woche passiert ist
Simon Willison, einer der nüchternsten Beobachter der KI-Coding-Szene, hat am 6. Mai einen Beitrag veröffentlicht, der auf Hacker News innerhalb weniger Stunden über 640 Punkte und 700 Kommentare gesammelt hat. Sein Punkt: Die Begriffe „Vibe-Coding” und „Agentic Engineering” rücken gefährlich nah zusammen — näher, als ihm lieb ist.
Kurzer Reminder, weil die Begriffe oft vermischt werden:
- Vibe-Coding (Begriff von Andrej Karpathy, Anfang 2025): Sie beschreiben einer KI in Alltagssprache, was Sie wollen, kopieren den Code, lassen ihn laufen, und wenn es funktioniert, ist es gut. Sie lesen den Code nicht wirklich. „Forget the code even exists” — vergessen Sie, dass der Code überhaupt existiert.
- Agentic Engineering: Ein Agent (Claude Code, Codex, Cursor-Agent etc.) übernimmt mehrere Schritte autonom — schreibt, testet, committet, deployt. Aber: ein erfahrener Entwickler liest mit, prüft Diffs, hält die Architektur sauber.
Willisons Sorge: Weil Agenten immer mehr selbst erledigen, hören auch professionelle Entwicklerinnen auf, jeden Diff genau zu lesen. Damit driftet seriöses Engineering in Richtung Vibe-Coding — ohne dass es jemand offen ausspricht.
Warum das jetzt für KMU zählt
In meinen Beratungsgesprächen sehe ich seit Monaten ein typisches Muster: Geschäftsführer oder Marketingleiterinnen erzählen stolz, sie hätten „mit ChatGPT” oder „mit Lovable” eine kleine interne Anwendung gebaut. Ein Angebotsrechner. Ein Lead-Formular mit Anbindung an das CRM. Ein Skript, das nächtlich Daten zwischen zwei Systemen schiebt.
Funktioniert. Im Demo. Am eigenen Laptop.
Wenn ich dann frage, wer den Code gelesen hat, wer die Abhängigkeiten kennt, wer die Logs sieht, wenn nachts etwas kippt — Stille. Das ist klassisches Vibe-Coding, und es ist im internen Tooling oft auch in Ordnung. Wird aber gerade gefährlich, weil zwei Entwicklungen zusammenkommen:
Erstens: Die Tools werden besser. Claude Code, Codex und ähnliche Agenten erledigen heute Aufgaben, die vor zwölf Monaten noch ein Junior-Entwickler-Tag gefressen hätten. Das verführt dazu, ihnen mehr zu überlassen — auch Dinge, die in produktive Systeme reichen.
Zweitens: Die Grenze zwischen „Spielzeug” und „Produktion” verschwimmt. Ein Vibe-codetes Skript, das anfangs nur ein einziges Excel verarbeitet hat, hängt sechs Monate später an drei Datenquellen, schickt Mails an Kunden und niemand weiß mehr, wer es ursprünglich gebaut hat. Ich habe diesen Verlauf bei mindestens vier KMU im letzten Jahr gesehen.
Willisons Punkt ist also kein akademischer Streit unter Entwicklern. Er beschreibt genau das Risiko, vor dem ich KMU warne: Wenn niemand mehr genau hinschaut, weil der Agent das schon richtig machen wird, entsteht technische Schuld in einem Tempo, das traditionelle Wartungsbudgets nicht vorsehen.
Aus meiner Sicht: Die Trennlinie muss bewusst bleiben
Ich halte beide Arbeitsweisen für legitim — aber für unterschiedliche Zwecke. Die Frage ist nicht „Vibe oder seriös?”, sondern: Wo läuft das Ding am Ende?
Meine Faustregel für KMU-Kunden:
- Vibe-Coding ist OK, wenn das Ergebnis maximal eine Person nutzt, keine Kundendaten verarbeitet, keine externen Aktionen auslöst (Mails, Zahlungen, API-Calls in fremde Systeme) und ohne Schaden gelöscht werden könnte. Beispiel: Ein Skript, das Ihnen einmalig 200 PDFs umbenennt.
- Sobald eines dieser Kriterien kippt, brauchen Sie jemanden, der den Code wirklich liest. Das muss nicht zwingend ein interner Entwickler sein — aber es muss jemand sein, der dafür gerade steht.
Die zweite Variante ist das, was Willison Agentic Engineering nennen würde, wenn es sauber gemacht ist: Agent macht die Arbeit, Mensch liest die Diffs, prüft Tests, kennt die Architektur. Der Agent beschleunigt — er ersetzt nicht das Verständnis.
Konkrete Handlungsempfehlung
Wenn Sie in Ihrem Unternehmen KI-gestützte Code-Erzeugung einsetzen oder das in den nächsten Monaten planen, würde ich drei Schritte empfehlen:
1. Inventur machen — diese Woche. Listen Sie auf, welche Skripte, Tools, Automatisierungen und kleinen Apps in den letzten 12 Monaten in Ihrem Haus mit KI-Unterstützung entstanden sind. Egal ob von der IT, vom Marketing oder vom Praktikanten. Pro Eintrag: Wer hat es gebaut? Wer kann es heute warten? Was passiert, wenn es ausfällt? Erfahrungsgemäß kommen dabei zwei bis fünf Kandidaten hoch, von denen niemand mehr wusste, dass sie kritisch geworden sind.
2. Ampel vergeben. Grün: rein internes Spielzeug, Ausfall egal. Gelb: läuft regelmäßig, ein Mensch könnte einspringen. Rot: hängt an Kundendaten, Geld, externer Kommunikation oder rechtlich relevanten Prozessen. Alles auf Rot braucht entweder Code-Review durch eine kompetente Person oder muss durch eine etablierte SaaS-Lösung ersetzt werden. Die Frage „bauen oder kaufen?” entscheidet sich bei Rot fast immer Richtung kaufen.
3. Regel für die Zukunft festlegen. Ein einziger Satz, schriftlich: „KI-erzeugter Code, der Kundendaten berührt oder externe Aktionen auslöst, geht nicht ohne Review von [Name] live.” Klingt banal. Verhindert aber genau den schleichenden Übergang von Vibe zu Produktion, den Willison beschreibt.
Was ich nicht empfehle
KI-Coding-Tools verbieten oder verteufeln. Das wäre der falsche Reflex. Die Produktivitätsgewinne sind real, gerade für KMU ohne große Entwickler-Teams. Ein gut geführter Marketingmensch mit Claude an der Seite baut heute Dinge, für die vor zwei Jahren ein Agentur-Auftrag über 8.000 Euro nötig war.
Der Punkt ist nicht weniger KI im Code, sondern bewusstere Linien, wo Vibe aufhört und Engineering anfängt. Willisons Warnung trifft hier einen wunden Punkt — und zwar genau in dem Moment, in dem viele KMU gerade in größerem Stil mit diesen Tools arbeiten wollen.
Wenn die Branche das nicht selbst diszipliniert, wird es der erste richtig peinliche Datenleak-Vorfall aus einem vibe-codeten Skript erledigen. Bis dahin: schauen Sie hin, bevor es Sie trifft.