KI in der Webentwicklung

Gerade bei komplexen Websites ist dieser Wunsch nach Entlastung nachvollziehbar. Die Arbeit besteht dort selten nur daraus, einzelne Komponenten zu bauen. Meist geht es um gewachsene Inhaltsstrukturen, bestehende Module, Redaktionsprozesse, Designsysteme, Schnittstellen, Barrierefreiheit und langfristige Wartung. Universitäten und Hochschulen sind dafür ein gutes Beispiel, weil ihre Websites über viele Jahre wachsen, von vielen Stellen gepflegt werden und sehr unterschiedliche Zielgruppen bedienen müssen.

Genau deshalb greift die übliche KI-Debatte zu kurz, wenn sie vor allem fragt, wie viel Code sich generieren lässt oder wie schnell ein Baustein entsteht. In solchen Projekten entscheidet sich Qualität nicht am ersten Entwurf, sondern daran, ob eine Lösung später noch verständlich, pflegbar und erweiterbar bleibt. KI kann hier unterstützen. Aber sie löst nicht automatisch die strukturellen Probleme, die in komplexen Websites häufig schon vorher vorhanden sind.

Warum schneller Output nicht automatisch Entlastung bedeutet

In der Webentwicklung ist Code zwar das sichtbarste Ergebnis, aber selten das eigentliche Problem. Eine Komponente kann schnell entstehen und trotzdem nicht in das bestehende System passen. Ein Codevorschlag kann technisch funktionieren und trotzdem langfristig ungünstig sein. Eine Lösung kann lokal richtig wirken, aber neue Sonderfälle erzeugen, die später gepflegt, dokumentiert und wieder eingefangen werden müssen.

Das ist besonders dann relevant, wenn eine Website nicht aus wenigen Seiten, sondern aus vielen Inhaltstypen, Redaktionsrollen und technischen Abhängigkeiten besteht. Dort erzeugt jeder neue Baustein auch neue Verantwortung. Er muss gepflegt werden können, sich in vorhandene Patterns einfügen, mit echten Inhalten funktionieren, barrierefrei sein und auch dann noch verständlich bleiben, wenn andere Personen später daran weiterarbeiten.

KI kann in kurzer Zeit viel Output erzeugen. Genau darin liegt ihr Reiz. Ein leerer Editor ist schnell gefüllt, eine erste Komponente steht bereit, Testfälle sind formuliert, eine Dokumentation klingt plötzlich brauchbar. Trotzdem entsteht daraus erst dann ein echter Vorteil, wenn dieses Ergebnis geprüft und sinnvoll in das Projekt eingeordnet wird. Andernfalls wird Arbeit nicht eingespart, sondern nur verschoben: in spätere Korrekturen, Nachdokumentation, Refactoring oder Support.

Die sinnvollere Frage lautet deshalb nicht, wie viel KI übernehmen kann. Sie lautet, wo KI schneller zu Ergebnissen führt, die ein Team versteht, bewertet und langfristig verantworten kann. Das ist weniger spektakulär als die Erzählung vom automatisierten Coding, aber näher an der Realität guter Webprojekte.

Die eigentliche Herausforderung liegt oft unter der Oberfläche

Komplexe Websites leiden selten daran, dass einzelne Bausteine nicht schnell genug entstehen. Häufiger liegt die Herausforderung tiefer: in gewachsenen Inhaltsstrukturen, uneinheitlichen Modulen, unklaren Verantwortlichkeiten, historischen Sonderfällen oder Designsystemen, die im Alltag nicht sauber in Redaktion und Technik übersetzt wurden.

Bei Universitäten und Hochschulen sieht man das besonders deutlich. Eine Website ist dort nicht einfach ein Marketingkanal. Sie ist Studieninformation, Forschungsprofil, Serviceplattform, Nachrichtenraum, Personenverzeichnis, Veranstaltungsarchiv und institutioneller Orientierungspunkt zugleich. Inhalte entstehen dezentral. Zuständigkeiten sind verteilt. Fachbereiche, Einrichtungen und Verwaltung haben unterschiedliche Anforderungen. Viele Seiten wurden über Jahre ergänzt, verschoben, angepasst und weitervererbt.

In solchen Strukturen löst Geschwindigkeit allein wenig. Wenn KI schneller neue Module, Texte oder technische Varianten erzeugt, aber die darunterliegenden Fragen ungeklärt bleiben, wächst die Komplexität weiter. Dann entstehen zusätzliche Bausteine, die nicht sauber zusammenpassen. Neue Ausnahmen. Neue Pflegelogiken. Neue technische Abweichungen. Der eigentliche Nutzen von KI liegt deshalb nicht darin, noch mehr Einzelteile zu erzeugen. Er liegt dort, wo sie hilft, bestehende Komplexität schneller zu verstehen, Muster sichtbar zu machen und bessere Strukturen vorzubereiten.

Das kann sehr praktisch sein. KI kann Anforderungen sortieren, bestehende Inhalte clustern, technische Optionen gegenüberstellen oder erste Prüfpfade für Migration und Qualitätssicherung vorbereiten. Aber sie ersetzt nicht die Entscheidung, welche Struktur eine Organisation tatsächlich braucht und welche Lösung langfristig trägt.

Langfristigkeit gehört in die Mitte der Debatte

Viele KI-Demos enden an dem Punkt, an dem etwas sichtbar funktioniert. Eine Oberfläche ist gebaut, ein Snippet läuft, ein Prototyp sieht ordentlich aus. Für eine erste Einschätzung kann das hilfreich sein. Für die Bewertung eines professionellen Webprojekts reicht es nicht.

Die wichtigeren Fragen kommen später. Passt die Komponente noch, wenn neue Varianten hinzukommen? Versteht ein anderes Teammitglied, warum der Code so gebaut wurde? Lässt sich das Modul im CMS sinnvoll pflegen? Funktioniert es mit langen Überschriften, fehlenden Bildern oder mehrsprachigen Inhalten? Ist die Dokumentation noch korrekt, wenn Anforderungen geändert wurden? Verhält sich das Markup sauber mit Screenreader und Tastatur? Ist klar, wo Daten herkommen und wer sie ändern darf?

Bei Websites mit CMS, Designsystem, mehreren Redaktionen und laufender Weiterentwicklung zählt nicht nur der erste Wurf. Solche Systeme leben. Neue Seiten kommen dazu, Anforderungen ändern sich, Inhalte werden migriert, Designentscheidungen werden erweitert und Schnittstellen verändern sich. Ein schneller Start hilft nur, wenn er später nicht im Weg steht.

Langfristigkeit ist deshalb kein Zusatzthema, das nach der Umsetzung kommt. Sie gehört von Anfang an in die Bewertung von KI-gestützter Entwicklung. Ein Vorschlag ist erst dann wirklich hilfreich, wenn er nicht nur heute plausibel wirkt, sondern auch morgen noch nachvollziehbar, wartbar und anschlussfähig bleibt.

Verantwortung bleibt beim Entwicklungsteam

Der wichtigste Grundsatz im Umgang mit KI ist einfach: Vorschläge können von KI kommen, Verantwortung nicht. Wer einen KI-generierten Vorschlag in ein Projekt übernimmt, muss ihn verstehen, prüfen und fachlich vertreten können. Das betrifft Code genauso wie Testfälle, Dokumentation, technische Konzepte oder Strukturen für CMS-Module.

In der Praxis ist genau das der kritische Punkt. KI-Vorschläge wirken oft überzeugend, weil sie schnell, sauber formuliert und technisch plausibel erscheinen. Dadurch entsteht leicht der Eindruck, dass sie schon nah an einer fertigen Lösung sind. Tatsächlich sind sie zunächst nur ein Entwurf. Ob sie zum Projekt passen, entscheidet sich erst durch Prüfung: Welche Annahmen stecken darin? Welche Fälle werden abgedeckt? Welche nicht? Entspricht die Lösung den bestehenden Patterns? Ist sie sicher? Ist sie barrierefrei? Wird sie in einem halben Jahr noch lesbar sein?

Das macht Entwicklerinnen und Entwickler nicht weniger wichtig. Im Gegenteil. Ihr Kontextwissen wird wichtiger, weil sie schneller mehr Vorschläge einordnen müssen. Sie müssen erkennen, wann ein Vorschlag wirklich hilft und wann er nur oberflächlich gut aussieht. Sie müssen entscheiden, ob eine Lösung ins System passt oder lediglich ein lokales Problem kaschiert.

Gerade in Projekten mit vielen Beteiligten ist diese Verantwortung entscheidend. Eine Website ist dort nicht nur ein technisches Produkt, sondern Teil der institutionellen Kommunikation. Fehlerhafte Strukturen, schwer pflegbare Module oder unklare technische Entscheidungen wirken sich direkt auf den Alltag von Redaktionen und Nutzerinnen und Nutzern aus.

Wo KI im Alltag tatsächlich hilft

Der praktische Nutzen von KI liegt oft nicht in den großen Versprechen, sondern in den kleineren Momenten, in denen Arbeit schneller in Bewegung kommt. Eine unübersichtliche Anforderung lässt sich schneller sortieren. Ein erster technischer Ansatz ist schneller formuliert. Boilerplate muss nicht jedes Mal von Hand entstehen. Tests lassen sich vorbereiten. Dokumentation bekommt einen brauchbaren Anfang. Bestehender Code kann schneller erklärt werden. Bei Refactorings entstehen schneller Varianten, über die man im Team sprechen kann.

Das ist besonders wertvoll in Projekten, in denen viel Kontext zusammenkommt: CMS-Strukturen, Frontend-Komponenten, Datenmodelle, Schnittstellen, Rollen, Rechte, Inhalte und Designsysteme. KI kann helfen, in solche Themen schneller hineinzukommen. Sie kann Muster sichtbar machen, Rückfragen vorbereiten und Varianten erzeugen, die man anschließend bewertet.

Der entscheidende Punkt ist aber, dass KI selten die fertige Antwort liefert. Sie liefert eher eine gute Zwischenstufe. Genau darin liegt ihr realistischer Mehrwert: Sie verkürzt den Weg zum prüfbaren Entwurf. Sie ersetzt nicht die Prüfung und auch nicht die Entscheidung, welche Lösung im konkreten Projekt richtig ist.

Gut eingesetzt reduziert KI also nicht Verantwortung, sondern operative Reibung. Sie nimmt Teams nicht das Denken ab, kann aber den Weg zu besseren Entscheidungen verkürzen.

Figma-to-Code zeigt das besonders gut

An der Schnittstelle von Design und Entwicklung wird diese Frage sehr konkret. Figma-to-Code klingt nach einem perfekten Automatisierungsfall. Das Design liegt vor, Abstände sind sichtbar, Farben und Schriftgrößen definiert, Komponenten angelegt. Warum also nicht direkt Code daraus machen?

Für Prototypen oder einfache Oberflächen kann das sinnvoll sein. In langfristig betriebenen Websites reicht ein solcher Export jedoch selten aus, weil ein Design dort nicht einfach eine visuelle Vorlage ist. Ein Button ist nicht nur ein Rechteck mit Text. Er ist Teil eines Komponentensystems mit Varianten, Zuständen, Größen, Abständen, Semantik und Verhalten. Ein Teaser ist nicht nur ein Bild, eine Überschrift und ein Link. Er hängt später an Daten, redaktionellen Feldern, optionalen Inhalten und Regeln im CMS. Ein Modul muss nicht nur gut aussehen, sondern gepflegt, wiederverwendet und erweitert werden können.

Deshalb ist Figma-to-Code nur bedingt ein KI-Problem. An dieser Stelle geht es nicht darum, dass ein System möglichst kreativ interpretiert, was gemeint sein könnte. Im besten Fall sollte es gar nicht viel interpretieren müssen. Es sollte übersetzen. Wenn in Figma ein definierter Token verwendet wird, sollte im Code derselbe Token ankommen. Wenn eine Komponente eine bekannte Variante ist, sollte sie auch als diese Variante umgesetzt werden. Wenn ein Modul später im CMS gepflegt wird, muss die technische Struktur dazu passen.

Viele klassische Figma-to-Code-Ansätze schaffen visuelle Nähe. Das ist nützlich für frühe Entwürfe. Für langfristige Projekte reicht es selten. Der erzeugte Code sieht dem Design ähnlich, passt aber nicht sauber zum Designsystem, zur Komponentenlogik oder zum CMS-Modell. Dann entsteht kein System, sondern eine Momentaufnahme. Interessant ist deshalb nicht, ob man aus Figma irgendwie Code bekommt. Das geht. Die Frage ist, ob dieser Code in ein System passt, das später noch funktioniert.

Qualitätssicherung wird nicht kleiner, sondern wichtiger

Wenn KI mehr und schneller Vorschläge erzeugt, braucht es nicht weniger Qualitätssicherung. Es braucht eine bewusstere Einordnung. Ein Review prüft dann nicht nur handgeschriebenen Code, sondern auch Annahmen, die in einem KI-Vorschlag stecken. Wurde eine veraltete API verwendet? Entsteht eine unnötige Abhängigkeit? Passt das Pattern zum Projekt? Ist das Markup semantisch sauber? Funktioniert die Komponente mit Tastatur? Was passiert bei fehlenden Daten?

KI kann helfen, solche Fragen vorzubereiten. Sie kann Testfälle vorschlagen, mögliche Randfälle nennen oder Dokumentation strukturieren. Trotzdem muss jemand entscheiden, welche Tests relevant sind und ob die Lösung wirklich hält. Besonders kritisch sind Bereiche wie Authentifizierung, Rollenmodelle, Datenverarbeitung, Schnittstellen, Deployment und Infrastruktur. Dort reicht ein plausibler Vorschlag nicht. Dort braucht es Verständnis, Prüfung und im Zweifel eher konservative Entscheidungen.

Das gilt auch für Frontend und Redaktion. Eine optisch passende Komponente ist noch nicht automatisch barrierefrei, performant oder gut pflegbar. Gerade bei langlebigen Websites muss Qualitätssicherung deshalb breiter gedacht werden: technisch, redaktionell und organisatorisch.

Vertraulichkeit bleibt eine Grundbedingung

Ein weiterer Punkt wird in der Praxis schnell unterschätzt: Welche Informationen dürfen überhaupt in KI-Systeme eingegeben werden? Vertrauliche Kundendaten, personenbezogene Daten, Zugangsdaten, interne Projektdokumente oder sicherheitsrelevante Informationen gehören nicht in ungeprüfte externe KI-Systeme. Das ist keine Formalie, sondern eine Voraussetzung für professionelles Arbeiten.

Wenn KI bei Analyse oder Strukturierung hilft, kann man mit abstrahierten Informationen arbeiten. Man kann technische Muster beschreiben, ohne Kundendaten offenzulegen. Man kann Anforderungen anonymisieren und Beispiele verallgemeinern. Der Effizienzgewinn darf nicht daraus entstehen, dass Datenschutz und Vertraulichkeit unklar werden.

Gerade bei öffentlichen Auftraggebern, komplexen IT-Landschaften oder sensiblen Projekten ist diese Grenze wichtig. KI kann hier sinnvoll eingesetzt werden, aber nur mit klaren Regeln dafür, welche Informationen verwendet werden dürfen und welche nicht.

Was bleibt

KI macht Webentwicklung an vielen Stellen schneller. Das ist inzwischen kaum noch die zentrale Frage. Wichtiger ist, ob sie Entwicklung auch besser macht. Bei komplexen Websites hängt die Antwort davon ab, ob KI in einen Prozess eingebunden ist, der Verantwortung ernst nimmt und langfristige Qualität nicht dem ersten Output unterordnet.

Gute KI-Nutzung heißt deshalb nicht, möglichst viel Code zu erzeugen. Sie heißt, schneller zu prüfbaren Zwischenergebnissen zu kommen, repetitive Arbeit zu reduzieren und bessere Entscheidungen vorzubereiten. Sie heißt auch, Vorschläge zu nutzen, ohne die eigene Bewertung aufzugeben.

Für komplexe Websites mit vielen Beteiligten, dezentraler Pflege und langer Lebensdauer ist diese Haltung besonders wichtig. Dort zeigt sich Qualität nicht im ersten Entwurf, sondern im Alltag: beim Pflegen, Erweitern, Prüfen, Migrieren und Weiterentwickeln. Gerade im Hochschulkontext ist das entscheidend. Die Website muss nicht nur gut aussehen und zum Launch funktionieren. Sie muss über Jahre hinweg Orientierung geben, Inhalte tragen, neue Anforderungen aufnehmen und institutionell verlässlich bleiben.

KI ist dann wertvoll, wenn sie langfristige Qualität unterstützt statt kurzfristigen Output zu maximieren.