Eine Agentur liefert die Website pünktlich. Drei Monate später ruft der Kunde an: Ein Formular bricht zusammen, niemand weiß warum — der Entwickler nicht, der Code erklärt es nicht. Die KI hat ihn geschrieben, niemand hat ihn gelesen.
Der Begriff, der alles erklärt — und leider alles vermischt
Im Februar 2025 schrieb der KI-Forscher Andrej Karpathy auf X: „There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.“ Und weiter: „I just see things, say things, run things, and copy-paste things, and it mostly works.“
Das klingt entspannt, fast spielerisch. Und genau so war es gemeint. Karpathy beschrieb einen Arbeitsmodus, in dem man KI-generiertem Code vertraut, ohne ihn zu lesen. Ohne zu prüfen, ob er das tut, was man erwartet. Bewusstes Nicht-Verstehen als Prinzip.
Das Problem entstand kurz danach. Der Begriff wurde sofort ausgeweitet — auf alles, was irgendwie KI und Code kombiniert. Simon Willison, Django-Mitgründer und in der Entwickler-Community vielzitierter Autor, warnte bereits im März 2025 öffentlich: „I’m concerned that the definition is already escaping its original intent. I’m seeing people apply the term ‘vibe coding’ to all forms of code written with the assistance of AI.“ (simonwillison.net, 19.3.2025)
Seitdem bezeichnet „Vibe-Coding“ zwei Dinge, die wenig gemeinsam haben. Erstens: Karpathys ursprünglicher Ansatz — Code entsteht schnell, wird nicht geprüft, man gibt der KI nach und schaut, was herauskommt. Zweitens: jede Form von KI-gestützter Entwicklung, ganz gleich wie professionell oder kontrolliert.
Diese Verwischung ist kein sprachliches Detail. Sie verdeckt einen echten Unterschied — und macht es für Auftraggeber schwer, zu beurteilen, was ein Dienstleister tatsächlich tut, wenn er sagt: „Wir arbeiten mit KI.“
Vibe-Coding ist nicht per se ein Problem. Es hat seinen Platz — einen klar begrenzten.
Für Prototypen, Lern-Projekte und Wegwerf-Code funktioniert der Ansatz gut: Man testet eine Idee, baut schnell etwas Sichtbares, verwirft es wieder. Ob der Code langfristig funktioniert oder sich wartbar weiterentwickeln lässt, ist irrelevant — weil er diesen Weg nie gehen wird. Der IONOS Digital Guide beschreibt es treffend: „Agenturen können Vibe Coding für Prototyping nutzen. Das hilft in Workshops, Pitches und frühen Konzeptphasen.“ (ionos.de, Stand 06/2026)
Bei einer Produktions-Website gelten andere Anforderungen.
Eine Website, die für ein Unternehmen arbeiten soll — die Kunden gewinnt, Vertrauen aufbaut, sich im Wettbewerb behauptet — braucht Performance, Sicherheit, Barrierefreiheit und Wartbarkeit. Sie wird nach dem Launch weiterentwickelt: neue Leistungen kommen hinzu, Inhalte ändern sich, technische Anforderungen verschieben sich. Das kann Monate dauern, oft Jahre.
Code, der beim Bauen nicht verstanden wurde, lässt sich kaum sicher ändern. Wer eine Stelle im Code nicht kennt, kann die Auswirkung einer Änderung dort nicht einschätzen — und greift im Zweifel blind. Fehler, die im Prototyp egal sind, werden im Livebetrieb zu tatsächlichen Problemen: langsame Ladezeiten, die Google abstraft. Sicherheitslücken, die unentdeckt bleiben, weil niemand weiß, welche Bibliotheken mit welchen Versionen im Einsatz sind. Barrierefreiheitsmängel, die rechtlich relevant sind.
Im ersten Teil dieser Serie haben wir gesehen, was nach der Entscheidung für einen bestimmten Weg wirklich passiert: Der Aufwand liegt oft nicht im Bauen, sondern im Betrieb danach. Vibe-Coding für eine Produktions-Website bündelt genau die Risiken, die dort am schwersten wiegen — in einem einzigen Ansatz.
Wer Vibe-Coding für den richtigen Kontext einsetzt, macht nichts falsch. Wer es auf jeden Kontext anwendet, trägt Risiken, die oft erst später sichtbar werden.
Wie MichelyWeb konkret arbeitet — KI als Werkzeug, Verantwortung als Konstante
Auch MichelyWeb arbeitet mit KI. Das ist weder Geheimnis noch Marketingversprechen, sondern die ehrlichste Antwort auf eine Frage, die Kunden zunehmend stellen: „Macht ihr das auch mit KI?“
Ja. Die eigentliche Frage lautet: Wer entscheidet, wer prüft — und wer steht am Ende dafür gerade?
Architektur vor Code. Jedes Projekt beginnt mit Entscheidungen, die vor der ersten Zeile Code feststehen: Welche Technologie? Welche Seitenstruktur? Welche Anforderungen an Performance und Skalierung? Welche Schnittstellen? Diese Entscheidungen trifft kein Sprachmodell — sie erfordern Erfahrung, Abwägung und das Verständnis, wie eine Website in zwei Jahren aussehen soll, nicht nur heute. Wer diese Phase überspringt, baut auf Sand — mit oder ohne KI.
KI in der Implementierung — kontrolliert. Generierter Code kommt ins Projekt, wenn er gelesen, verstanden und gegen die Anforderung geprüft wurde. Was nicht erklärbar ist, kommt nicht rein. Das klingt nach Mehraufwand, ist aber das Gegenteil von Verschwendung: Ein Fehler, der im Review gefunden wird, kostet einen Bruchteil dessen, was er im Livebetrieb kostet — und ein Fehler, der nie gefunden wird, weil niemand den Code gelesen hat, ist der teuerste von allen.
Review als fester Bestandteil. Code-Review ist kein optionaler Schritt, den man weglässt, wenn es pressiert. Es ist der Punkt, an dem ein Werkzeugresultat zum verantworteten Ergebnis wird. Wer diesen Schritt überspringt, überträgt die Qualitätsentscheidung an das Sprachmodell — und das Sprachmodell trägt keine Verantwortung.
Tests werden geplant, durchgeführt und dokumentiert. Jeder Stand wird als Prüfpunkt genutzt, bevor Code in die nächste Phase geht — das schafft Nachvollziehbarkeit für den Kunden.
Verantwortungsübernahme. Wenn nach dem Launch etwas schiefgeht, ist MichelyWeb ansprechbar. Das ist kein Zufall und keine PR-Formulierung — Verantwortung ist der natürliche Bestandteil professioneller Arbeit, unabhängig davon, welche Werkzeuge eingesetzt wurden. KI als Ausrede funktioniert nicht. „Das hat die KI gebaut“ ist keine Antwort, die ein Auftraggeber akzeptieren muss.
Das ist der Unterschied, den man von außen nicht sieht: Beide Ansätze produzieren Code. Einer davon weiß, was der Code tut.
Was das für Ihr Projekt bedeutet
Konkret, ohne Technik-Vokabular: Sie bekommen eine Website, die nachvollziehbar gebaut ist.
Wenn nach einem Jahr eine neue Funktion gebraucht wird, lässt sie sich einbauen — weil die Struktur darauf ausgelegt wurde. Wenn die Seite irgendwann langsamer wird, lässt sich der Grund finden — weil der Code verstanden wurde. Wenn eine Sicherheitslücke in einem eingesetzten Baustein bekannt wird, wissen wir, ob und wo sie betrifft.
Wartbarkeit ist kein Luxus für große Budgets. Sie ist das, was aus einer Website-Investition eine langfristig nutzbare Grundlage macht — statt einem Konstrukt, das nach zwei Jahren niemand mehr anfassen will, weil niemand mehr versteht, was drin steckt.
Sie müssen KI nicht als Risiko betrachten. Aber es lohnt sich, Ihren Dienstleister zu fragen: Wer hat den Code gelesen? Wer hat entschieden, welche Teile übernommen werden? Wer steht dafür gerade?
Die Antwort auf diese Fragen trennt professionellen KI-Einsatz von Vibe-Coding — nicht das Werkzeug selbst.
KI-Beratung für Agenturen — Know-how, das weiterhilft
Viele Agenturen stehen gerade vor derselben Frage: Wie integrieren wir KI in unseren Entwicklungsprozess, ohne an Qualität zu verlieren? Welche Prozesse braucht es, damit KI-gestützte Projekte nachhaltig funktionieren? Wie kommuniziert man das gegenüber Kunden glaubwürdig?
MichelyWeb gibt dieses Know-how weiter. Das Beratungsangebot richtet sich an Agenturen, die konkret wissen wollen, wo KI hilft, wo sie sorgfältige Prüfung braucht — und wie ein belastbarer Review-Prozess aussieht, der nicht Tempo kostet, sondern langfristig Zeit spart.
Interesse? Sprechen wir darüber.
Häufig gestellte Fragen
Passend dazu: ➜ Professionelles Webdesign – Mehr zu unseren Leistungen.