Ich nutze KI. Jeden Tag.
Um das gleich klarzustellen: Dieser Beitrag ist kein Plädoyer gegen KI. Ich setze sie selbst täglich ein, beim Programmieren, beim Strukturieren von Ideen, beim Prüfen von Texten. Wer das als Entwickler heute nicht tut, hängt hinterher.
Die Frage ist deshalb nicht, ob man KI nutzt, sondern wie. Beim Internet sprechen wir seit Jahren von Medienkompetenz: Nicht alles glauben, was auf einer Webseite steht, Quellen prüfen, Zusammenhänge verstehen. Genau dieselbe Kompetenz brauchen wir jetzt im Umgang mit KI, und Entwickler sind davon nicht ausgenommen.
Vibe Coding, YOLO-Modus und Co.
Rund um KI-gestütztes Programmieren sind in kurzer Zeit einige Begriffe entstanden:
- Vibe Coding: Der Begriff stammt von Andrej Karpathy (Anfang 2025). Gemeint ist, Code per Prompt erzeugen zu lassen und ihn zu übernehmen, ohne ihn wirklich zu lesen. Funktioniert es, ist es gut. Funktioniert es nicht, fragt man die KI erneut.
- YOLO-Modus: Viele KI-Werkzeuge können Änderungen selbstständig ausführen, ohne vorher nachzufragen. Dateien werden geschrieben, Befehle ausgeführt, alles läuft durch.
- „Accept all“: Alle Vorschläge der KI auf einmal übernehmen, ohne sie einzeln anzusehen.
Für ein Hobbyprojekt am Wochenende ist das völlig in Ordnung. Man probiert etwas aus, lernt dabei und wenn es kaputtgeht, ist niemand betroffen.
Bei einer Unternehmensseite sieht das anders aus. Dort hängen Anfragen, Umsatz und Vertrauen dran. Eine Seite, die nach drei Stunden oder beim nächsten Update zusammenbricht, ist kein Schönheitsfehler, sondern ein Problem für den Betrieb.
Was in KI-generiertem Webseiten-Code steckt
Bei einem meiner privaten Projekte gab es zu Beginn einen Webseiten-Entwurf, der mit KI erstellt worden war. Die erste Fassung war unstrukturiert und kaum wartbar. Spannender sind aber die Fehler, die selbst in späteren, sauber aussehenden Fassungen noch steckten. Die folgenden Beispiele stammen aus echtem Code, anonymisiert.
Erfundene Inhalte
Das gefährlichste Problem war kein technisches. Auf einer Seite stand eine Kundenstimme mit Vorname und Altersangabe. Dieselbe Person hatte an anderer Stelle tatsächlich eine Rückmeldung gegeben, aber mit völlig anderem Inhalt. Die KI hatte das Zitat umgeschrieben, passend zum Thema der Seite, und es weiter der echten Person zugeschrieben.
Für den Betreiber ist das heikel: Erfundene Kundenstimmen untergraben Vertrauen und können rechtliche Folgen haben.
Ähnlich bei Behauptungen: Im Text stand „vertraulich und DSGVO-konform“, während die Seite gleichzeitig Schriften von Google-Servern lud und damit Besucherdaten an Dritte übertrug. Und im Footer tauchte eine Rechtsform auf, die niemand vorgegeben hatte.
Anweisungen im sichtbaren Text
Eine Überschrift lautete schlicht „In einem Absatz“. Das war keine Überschrift, sondern eine Anweisung aus einem Marketing-Schema, die die KI als Inhalt übernommen hatte. An anderer Stelle stand in einem Platzhalter: „Schick mir den Wortlaut, dann setze ich ihn hier ein.“ Die KI hat mit dem Auftraggeber gesprochen, nicht mit dem Besucher. Auf einer Live-Seite wirkt so etwas schnell unprofessionell.
Platzhalter, die live gehen könnten
- Links mit href="#" bei WhatsApp, Impressum und Datenschutz. Sie sehen aus wie Links, führen aber nirgendwohin.
- Das Firmenlogo als Ersatz für ein Porträtfoto, mit dem Alt-Text „Porträt von …“.
- Ein Standard-Platzhalterbild des CMS als „Qualitätssiegel“.
Einzeln betrachtet sind das Kleinigkeiten. Zusammen ergeben sie eine Seite, die auf den ersten Blick fertig aussieht und es nicht ist.
Konflikte mit dem CMS
Der Entwurf gestaltete direkt Elemente wie body, header, footer, h1 und a. In einer eigenständigen HTML-Datei funktioniert das. Sobald der Code aber in ein CMS wie Odoo eingebaut wird, das eigene Kopfzeilen, Fußzeilen und Stile mitbringt, überschreibt er diese auf der gesamten Webseite. Die Folge: Menüs verrutschen, Schriftgrößen ändern sich an Stellen, die niemand angefasst hat.
Inkonsistenzen
Derselbe Button („Check starten“) führte einmal auf die eigentliche Domain und einmal auf eine technische Subdomain des Hosters. „Termin buchen“ zeigte an einer Stelle auf die Terminbuchung, an zwei anderen auf das Kontaktformular. Und ein und derselbe lange Link war sechsmal fest im Code hinterlegt. Ändert sich das Ziel, muss man alle sechs Stellen finden. Übersieht man eine, landen Besucher im Leeren.
Dazu kamen Inline-Styles mitten im HTML und Klassennamen wie .ph, .q oder .w, bei denen in drei Monaten niemand mehr weiß, wofür sie stehen.
Warum „einfach weiterbauen“ teuer wird
Keiner dieser Fehler fällt auf, wenn man die Seite einmal im Browser ansieht. Sie fallen auf, wenn ein Kunde auf einen Link klickt, der nicht funktioniert. Wenn das CMS ein Update bekommt. Wenn die Seite in eine zweite Sprache übersetzt werden soll. Oder wenn jemand die Kundenstimme wiedererkennt.
Auf einem solchen Entwurf aufzubauen bedeutet, jedes dieser Probleme mitzunehmen und mit jeder Änderung neue hinzuzufügen. In meinem privaten Projekt war es am Ende schneller, den Entwurf als visuelle Vorlage zu nutzen und den Code sauber neu aufzubauen.
Die Verantwortung bleibt beim Entwickler
Das ist für mich der Kern: KI schreibt Code, aber sie trägt keine Verantwortung dafür. Die trägt der Entwickler. Er muss den Code verstehen, den er ausliefert, und sicherstellen, dass er Qualitätsstandards erfüllt. Das heißt konkret:
- Jede Zeile, die in ein Kundenprojekt geht, ist gelesen und verstanden.
- Inhalte wie Zitate, Zahlen und Behauptungen werden gegen die Quelle geprüft.
- Der Code passt zum System, in dem er läuft, nicht nur zum Browserfenster.
- Die Seite wird getestet, bevor sie live geht, nicht danach.
KI macht mich bei vielen Aufgaben deutlich schneller. Aber die gesparte Zeit fließt zum Teil genau in diese Prüfung. Das ist kein Mehraufwand, das ist der Job.
Vorher und nachher: ein Beispiel
So sah ein typischer Abschnitt im Entwurf aus (vereinfacht, mit Beispiel-Domain):
<!doctype html>
<html lang="de">
<head>
<meta charset="utf-8">
<title>Vorher</title>
<style>
body { margin: 0; font-family: "DM Sans", Arial, sans-serif; color: #3a302c; }
header { position: sticky; top: 0; background: #faf6f1; padding: 12px 20px; }
h1 { font-size: 3rem; margin: 0; }
a { color: #9a5f59; }
.btn { display: inline-block; background: #b5766f; color: #fff; padding: 13px 22px; border-radius: 999px; text-decoration: none; }
</style>
</head>
<body>
<header>Logo</header>
<section style="background:#f6ebe7;padding:54px 20px">
<h1>Mehr Energie im Alltag</h1>
<a class="btn" href="https://kunde.hoster-beispiel.com/survey/start/3f2a9c71-0b4e">Check starten</a>
<a class="btn" href="https://www.beispiel-kunde.be/survey/start/3f2a9c71-0b4e">Jetzt starten</a>
</section>
</body>
</html>
Die Probleme: body, header, h1 und a gelten für die gesamte Webseite, die Gestaltung des Abschnitts steckt inline im HTML und derselbe Link ist zweimal unterschiedlich hinterlegt.
So sieht derselbe Abschnitt sauber aufgebaut aus:
<!doctype html>
<html lang="de">
<head>
<meta charset="utf-8">
<title>Nachher</title>
<style>
.kd {
--kd-ink: #3a302c;
--kd-soft: #f6ebe7;
--kd-accent: #b5766f;
font-family: "DM Sans", Arial, sans-serif;
color: var(--kd-ink);
}
.kd-hero { background: var(--kd-soft); padding: 54px 20px; }
.kd-hero__title { font-size: 3rem; margin: 0 0 24px; }
.kd-btn {
display: inline-block;
background: var(--kd-accent);
color: #fff;
padding: 13px 22px;
border-radius: 999px;
text-decoration: none;
}
</style>
</head>
<body>
<div class="kd">
<section class="kd-hero">
<h1 class="kd-hero__title">Mehr Energie im Alltag</h1>
<a class="kd-btn" href="/check">Check starten</a>
<a class="kd-btn" href="/check">Jetzt starten</a>
</section>
</div>
</body>
</html>
Was sich geändert hat:
- Eigener Namensraum: Alle Stile hängen am Präfix kd- und gelten nur innerhalb von .kd. Odoos eigene Kopf- und Fußzeile bleiben unberührt.
- Farben als Variablen: Eine Farbänderung passiert an einer Stelle, nicht in zwanzig.
- Keine Inline-Styles: Gestaltung steht im CSS, Inhalt im HTML.
- Ein Link, ein Ziel: Beide Buttons zeigen auf /check. In Odoo legen Sie dafür einmalig eine Weiterleitung an (Website › Konfiguration › Weiterleitungen) von /check auf das eigentliche Formular. Ändert sich das Ziel, passen Sie nur diese eine Weiterleitung an.
Note: Styles ziehe ich in der Regel in eine seperate Datei zur Seperation of Concerns.
„Separation of Concerns (Trennung der Anliegen) ist ein Prinzip der Softwareentwicklung, bei dem ein Programm in separate Abschnitte unterteilt wird, sodass jeder Bereich genau eine spezifische Aufgabe – wie Struktur, Design oder Logik – unabhängig löst.“
Checkliste: Wenn Sie einen KI-Entwurf haben
Sie haben einen Webseiten-Entwurf mit ChatGPT oder einem anderen Werkzeug erstellt und überlegen, darauf aufzubauen? Diese Punkte können Sie auch ohne Programmierkenntnisse prüfen:
- Jeden Link anklicken. Führt er dorthin, wo er soll? Führt er überhaupt irgendwohin?
- Jedes Zitat und jede Zahl gegen die Quelle prüfen. Hat die Person das wirklich so gesagt? Stimmt die Zahl?
- Nach Platzhaltern suchen. Wörter wie „Platzhalter“, „Beispiel“, „Lorem ipsum“ oder Sätze, die sich an Sie statt an Besucher richten.
- Rechtliche Angaben prüfen. Firmenname, Rechtsform, Impressum, Datenschutz. Nichts davon darf die KI erfinden.
- Auf dem Handy testen. Viele Entwürfe sehen nur auf dem großen Bildschirm gut aus.
- Eine kleine Änderung wagen. Lassen Sie eine Farbe oder einen Button-Text ändern. Wenn dafür an vielen Stellen gesucht werden muss, ist der Code kein gutes Fundament.
Fazit
KI ist ein hervorragendes Werkzeug, um schnell eine Idee sichtbar zu machen. Ein generierter Entwurf ist eine gute Skizze und eine gute Gesprächsgrundlage. Ein Fundament für eine Unternehmensseite ist er erst, wenn jemand ihn verstanden, geprüft und sauber aufgebaut hat.
Ich nutze KI, um schneller zu arbeiten. Aber ich liefere nur Code aus, den ich verstehe und für den ich geradestehen kann.
Sie haben einen KI-Entwurf und sind unsicher, ob man darauf aufbauen kann? Oder Sie möchten Ihre Webseite gleich auf ein sauberes Fundament stellen? Ich schaue mir Ihr Vorhaben gerne an: