Studienportal Bamberg – Retrospektive öffentlich
Pfeiltasten oder Scrollen

Studienstart 2026

Werkstattbericht: Wie wir das Studienportal der Universität Bamberg bauten

Wie aus verteilten Informationen in elf Wochen ein gemeinsamer Einstieg für Studieninteressierte entstand – mit KI gebaut, von Menschen geprüft.

Ein Werkstattbericht aus dem Chief Information Office (CIO) der Universität Bamberg.

1Problem und Entstehung
2Das Ergebnis
3Arbeiten mit der KI und Sicherung
4Aufwand, Lehren und Beteiligte
Dominik Herrmann · Juli 2026 · Öffentliche Fassung · v5

Kurzfassung

Das Wichtigste zuerst

Zielgruppe dieses Berichts: alle, die selbst mit KI etwas bauen wollen – oder verstehen möchten, wie man mit KI so etwas baut und worauf man dabei achten muss; technisch wie organisatorisch.

  • Was – ein uniweites Studienstart-Portal: über 100 Studiengänge auf 200+ Seiten, mit KI gebaut und von Menschen geprüft, seit 8. Juli 2026 live.
  • Warum – Infos für Studieninteressierte lagen über viele zentrale und dezentrale Seiten verstreut; Ziel war eine gebündelte Seite je Studiengang.
  • Wann – elf Wochen vom ersten Prompt (24. April) bis zum Go-Live (8. Juli); die Universitätsleitung beschloss den Bau am 29. April auf Basis eines lauffähigen Prototypen.
  • Wie – mit dem KI-Assistenten Claude Code: alle studienrelevanten Webseiten und Dokumente wurden automatisiert eingelesen und daraus die Seiten erzeugt, dann von Hand kuratiert und redigiert. Menschen sicherten Fakten, Ton und jede Freigabe über einen Feedback- und Freigabekreislauf.
  • Was wir gelernt haben – der Engpass war die Komplexität der vielen Änderungen, die die KI in schneller Folge erzeugte. Wie ein tragfähiger Prozess für die Mensch-KI-Zusammenarbeit aussieht, war zu Beginn nicht absehbar; er stand erst acht Tage vor dem Go-Live.
Startseite des Studienstart-Portals zum Go-Live
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5
1

Teil 1 von 4

Problem und Entstehung

Verteilte Informationen, ein schneller Beschluss – und ein Prototyp, der vor der Entscheidung schon lief.

www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Einordnung

Was dieser Werkstattbericht zeigt – und was nicht

Elf Wochen von Prompt bis Go-Live

Ein Bericht über die Erstellung der Webseiten – keine Bilanz einer Marketingmaßnahme

Wie das Portal entstand, was die KI leisten konnte und was Menschen auffangen mussten – dafür liegen heute Zahlen und Erfahrungen vor: Arbeitsweise, Werkzeuge, Arbeitsteilung, die typischen KI-Fehlerarten, Aufwand und Kosten. Für die Wirkung noch nicht.

Die Ausgangslage

Informationen für Studieninteressierte verteilten sich über viele zentrale und dezentrale Webseiten, uneinheitlich in Tiefe und Form. Ziel: je Studiengang eine Seite, die alles Wichtige samt der Standortvorzüge bündelt – ergänzend zum bestehenden Webauftritt.

Was erst der Betrieb zeigt

Ob das Portal als Marketinginstrument wirkt, lässt sich frühestens nach einigen Monaten seriös einschätzen. Ein A/B-Test mit Werbeanzeigen läuft bereits – Details am Ende des Berichts.

www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Entstehung

Zwei Zeitleisten, ein Projekt

Die Idee eines Studiengangsfinders kursierte an der Universität schon länger; der zentrale Studiengangsfinder war seit März 2026 online.
Das neue Portal ging am 8. Juli 2026 live – entstanden auf zwei Spuren zugleich: einer auf dem Papier, einer im Maschinenraum.

Auf dem Papier
  • Das Chief Information Office trägt die Initiative an die Universitätsleitung heranErste Information an die Kommunikationsabteilung
  • Die Erweiterte Universitätsleitung (EULe) beschließt: das Portal wird gebaut
  • Die Universitätsleitung lädt alle Studiengangsbeauftragten zum Kommentieren des Prototyps ein
  • Demo des fast fertigen Portals im Professorium, der Versammlung aller Professorinnen und Professoren
Im Maschinenraum – die ersten fünf Tage
  • Die erste Nachricht an die KI – im Claude-Chat„Das ambitionierte Ziel ist es, mit LLM-Support eine static site zu bauen, die die Daten des Studiengangfilters […] schön aufbereitet in einem Portal darstellt. […] ein Prototyp zum Wegwerfen […] Recherchiere umfassend dazu und diskutiere dann.“
  • Die erste Anfrage an Claude Code„… lies das PRD und beginne die Implementierung eines Prototypen / Mockups …“
  • Erster Commit – der erste gespeicherte Arbeitsstand„Initial prototype scaffolding“: 93 Dateien, 10.317 Zeilen
  • Am Vorabend des EULe-Beschlusses: 39 Commits
Am 29. April beschloss die Erweiterte Universitätsleitung den Bau – der Prototyp lief da schon fünf Tage. Statt eines Konzeptpapiers lag der EULe ein lauffähiges Portal vor – zum Anschauen, Gutfinden oder konkret Kritisieren; dass die technische Hürde überwindbar ist, war da schon zu sehen. Beschlossen wurde ein Experiment mit offenen Fragen zu Befüllung und Betrieb. Entschieden am lauffähigen Beispiel, nicht am Konzeptpapier.
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Entstehung

Eine KI erklärt der anderen den Auftrag

Das neue Portal begann am 24. April in einem Claude-Chat: Brainstorming über Aufbau, Zielgruppen und Clusterung – dann die Entscheidung, lieber zu prototypen statt weiter „trockenzuschwimmen“. Das Ergebnis war ein Product Requirements Document (PRD) – ein Anforderungsdokument: Die Chat-KI Claude schrieb es selbst, als Auftrag an das Schwester-Werkzeug Claude Code. Gestaltungs-Vorbild war der Studiengangsfinder der Fakultät Wirtschaftsinformatik und Angewandte Informatik (WIAI) – die Daten liefert der uniweite Studiengangsfinder der Universität. Um 10:58 Uhr ging das PRD an Claude Code – 79 Minuten später existierte der erste gespeicherte Arbeitsstand.

„Wir brauchen Beispiele, über die sich Prorektorat und Kommunikation streiten können.“aus dem von der KI formulierten PRD – ein „Prorektorat“ gibt es in Bamberg gar nicht. Ein Vorgeschmack auf die bisweilen befremdliche Wortwahl des Modells.
PRD_studium_uni_bamberg.md24.04.2026 · 3.755 Wörter ≈ 7,5 A4-Seiten

Wegwerf-Prototyp für ein uniweites Studieninteressierten-Portal der Otto-Friedrich-Universität Bamberg. […] Claude Code baut den Prototyp auf Basis dieses PRD. Ziel ist eine greifbare Diskussionsgrundlage, nicht Production-Release. Zeitrahmen: ca. 6 Wochen […] für Launch zur Einschreibung WS 2026/2027.

[…]

Der Prototyp muss folgende Designfragen beantwortbar machen:

  1. Skaliert das WIAI-Muster auf die uniweite Breite?
  2. Welcher Einstiegspfad funktioniert für welche Zielgruppe?
  3. Lässt sich Lehramt sinnvoll abbilden?
  4. Trägt der Differenzierungs-Claim „Erwartungsmanagement“?
  5. Reicht das Template-Konzept für 50 Hochglanz-Seiten plus 65 Satelliten?
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5
2

Teil 2 von 4

Das Ergebnis

Was aus den ersten Prototypen bis zum Go-Live wurde – und wie das Portal als Baukasten gebaut ist.

www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Das Ergebnis · Ende April

Die ersten Prototypen und Mockups

Oben die ersten Prototyp-Seiten, unten zwei der Mockups, die das Design beeinflussten. Auch sie entstanden mit Claude – mehr als 20 Design-Varianten: Reportage-Stil, Steckbriefe, Stundenpläne, Bildergalerien. Die meisten wurden verworfen; sie dienten dazu, ein Gefühl zu bekommen, welche Elemente nützlich sind und sich mit echten Daten füllen lassen.

Frühe Landingpage Studieren im Welterbe
Landing „Studieren im Welterbe.“ – noch per Du, „118 Studiengänge“, „em dashes“
Frühe Studiengangsseite Psychologie
Studiengangsseite Psychologie – mit Platzhalter-Markierung und Fachstudienberatung
Mockup Archäologische Wissenschaften
Mockup-Variante 2: Archäologische Wissenschaften mit Semester-Zeitstrahl
Mockup Ein Mittwoch im Studiengang
„Ein Mittwoch im Studiengang“ – Beispiel-Stundenplan mit Workload-Rechnung
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Das Ergebnis · 8. Juli

Der Go-Live

Go-Live-Landing Studienstart 2026
Landing „Studienstart 2026“ – jetzt per Sie, „100+ Studiengänge“, sachliche Fakten-Karten
Bachelor-Übersicht mit Filter
Bachelor-Übersicht mit Facetten und Direktsuche
Studiengangsseite Anglistik/Amerikanistik
Anglistik/Amerikanistik – Studierbar-als-Box mit ECTS-Varianten und Lehramts-Verweisen
Lehramtsseite mit LP/ECTS-Verteilung
Lehramt – Leistungspunkte (LP/ECTS) und „Vom 1. Semester bis zur Planstelle“, als HTML
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Das Ergebnis · Mitte Juli

Vom Platzhalter zur fertigen Seite

BWL-Seite mit Testimonial, Einblicke-Video und Fotos
Die BWL-Seite Mitte Juli: Master-Anschlüsse, Testimonial, Einblicke-Video und echte Fotos – im April waren das noch Platzhalter
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Das Ergebnis · 8. Juli

Was im Portal steckt

117Studiengangsseiten – inklusive Double Degrees und Erweiterungsstudien
94Lehramtsseiten – 46 Unterrichtsfächer plus 48 Fächerkombinationen
963FAQ-Einträge – 209 verschiedene Antworten auf 133 Fragen
778Beispielmodule – 641 verschiedene nach Titel
522„Wie sieht das Studium aus?“-Kacheln – 367 verschiedene
790Bild-Einbindungen – gut 200 Bilddateien, alle mit Nachweis
61Testimonials – 47 verschiedene Zitate
11Hochformat-Videos

Stand 9. Juli 2026, gezählt am gebauten Portal und seinen Datenquellen. Die 117 zählt jede Studiengangsseite inklusive Double Degrees und Erweiterungsstudien; die Landing nennt mit „100+ Studiengängen“ die Zahl der verschiedenen Fächer. Die großen Zahlen zählen jede Einbindung; „verschieden“ meint, was nach Abzug der Mehrfachverwendungen übrig bleibt – vieles wird über Bachelor- und Master-Geschwister oder mehrere Studiengänge hinweg wiederverwendet. Bei den FAQ gibt es mehr Antworten als Fragen, weil dieselbe Frage – etwa die Abgrenzung zur Hochschule für angewandte Wissenschaften – je Studiengang eigens beantwortet wird.

www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Das Ergebnis · Baukasten

Keine 200 Einzelseiten, sondern ein Baukasten

Crawl aller studienrelevanten Webseiten der Universität, dazu die Modulhandbücher sowie alle Prüfungs- und Studienordnungen
Chat-Fakten über die Studiengänge, die Claude ergänzend im Gespräch mitgeteilt wurden – über die eingelesenen Quellen hinaus
↓

Daten (JSON)

Strukturierte Fakten zu jedem Studiengang: Abschluss, Dauer, Module, Texte, Bilder.

Templates und Komponenten

Ein Bauplan für alle Seiten: Hero, Steckbrief, Kacheln, FAQ – wiederverwendbare Bausteine.

Überschreib-Ebenen

Sonderfälle je Studiengang übersteuern die Basisdaten – kein starres Korsett.

→

build.py

Das Build-Skript webt bei jedem Lauf die Daten in die Templates – mit automatischen Tests und Link-Prüfungen.

→

200+ fertige Seiten

Eine Änderung an Template oder Daten wirkt sofort auf allen Seiten.

www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Das Ergebnis · dazwischen

Was sich zwischen April und Juli änderte

per Du→per Sie – mit Beidnennung statt Gender-Sonderzeichen
„118 Studiengänge“→„100+ Studiengänge“Double-Degree-Doppelzählungen rausgerechnet
Em dashes (—), gerade Anführungszeichen (")→En dashes (–), typografische „…“regelbasiert erzwungen – solche Feinheiten hält das Sprachmodell nicht zuverlässig ein
Ansprechstellen je nach Anliegen verstreut→Zentrale Studienberatung als erste Anlaufstellevermittelt nach Kontaktaufnahme an die Fachstudienberatungen
Mockup-Platzhalter→echte Inhalte aus automatisierten Web-Crawlspro Studiengang in vielen Runden angepasst – das automatische Befüllen mit Inhalten verwandter Studiengänge erwies sich als wenig hilfreich
Bewusst zurückgestellt: englischsprachige Seiten – bis zum Go-Live war keine ausreichende Qualitätssicherung möglich. Und der „Was passt zu mir?“-Finder – die Zuordnungsregeln sollen erst evidenzbasiert abgestimmt werden.
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5
3

Teil 3 von 4

Arbeiten mit der KI und Sicherung

Wie Mensch und Modell zusammenarbeiteten, wie eine Änderung ins Portal kommt – und was dabei schiefging.

www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Was der KI-Einsatz sichtbar machte

Eine gemeinsame Sicht deckt Brüche auf

Der kritische Befund

Korrekturen schufen oft neue Fehler – auch nach Freigabe

Fehler entstanden nicht nur aus widersprüchlichen Quellen, sondern auch aus dem Sprachmodell selbst – die typischen Fehlerarten zeigt später „Was mit dem Sprachmodell schiefging“. Entscheidend hier: Erst die gemeinsame Sicht über alle Studiengänge machte solche Brüche sichtbar und behebbar.

Kleinteilige Recherche statt
bloßer Zusammenfassung

Voraussetzungen, Fristen und Moduldetails mussten gegen Primärquellen geprüft werden. Verlässlich wurden die Seiten erst über mehrere Review-Runden.

Lehramt bündelt viele Perspektiven

Unterschiedliche Auffassungen aus Fachvertretungen, Studienberatung und Ordnungen wurden erst in der Darstellung pro Studiengang sichtbar und mussten gemeinsam geklärt werden.

Transparenz ist trotzdem ein Gewinn

Erkannte Unklarheiten können nun auch auf den dezentral gepflegten Ausgangsseiten korrigiert werden.

Doppelte Pflege bleibt ein Thema: Fachvertretungen gaben zu bedenken, dass das neue Portal Mehrfachpflege nötig macht, und wünschten sich ein vollintegriertes Studienportal mit zentraler Datenhaltung. Das würde die Doppelpflege vermeiden, müsste dann aber die unterschiedlichen Bedarfe und die Ansprache von Studieninteressierten und eingeschriebenen Studierenden gleichermaßen bedienen. Ein weiteres Problem ist, dass die Redundanz zwischen zentralen und dezentralen Seiten die Sichtbarkeit der Seiten in Suchmaschinen beeinträchtigt und die Orientierung der Nutzenden erschwert. Wie es mit der Pflege weitergeht, ist eine der offen benannten Fragen in Teil 4.
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Arbeiten mit der KI

Mit KI gebaut – mit Leitplanken

Die KI skalierte die Fleißarbeit, der Mensch verantwortete Fakten, Ton und jede Freigabe:

Was die KI gut skalierte

Sammeln, angleichen, zuarbeiten

  • Quellen erschließen: Studiengangsfinder der Universität, Webseiten und Modulhandbücher sichten und für Studieninteressierte aufbereiten.
  • Über 200 Seiten konsistent halten: dieselben Regeln auf viele Studiengänge anwenden.
  • Routine abnehmen: Änderungsprotokolle schreiben, Feedback vorsortieren und Vorschläge formulieren.
Was beim Menschen blieb

Fakten, Ton und Entscheidungen

  • Fakten sichern: jede Aussage gegen ihre Quelle prüfen.
  • Ton treffen: Superlative und Werbesprache entfernen; Menschen geben den Stil vor.
  • Freigeben: Änderungen in der Vorschau prüfen, bewusst veröffentlichen und bei Bedarf zurückdrehen.
Die KI beschleunigt die Arbeit, die Entscheidungen treffen Menschen. Der Anspruch: Was im Portal steht, hat ein Mensch geprüft und freigegeben.
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Arbeiten mit der KI

Das Muster, das sich bewährt hat

Begriffe mit „/“ (etwa /plan oder /code-review) sind vorgefertigte Befehle im Werkzeug – Abkürzungen für wiederkehrende Arbeitsschritte.

1

Erst besprechen

Im /plan-Modus die Idee durchdenken, Varianten abwägen, Einwände einholen – noch keine Zeile Code.

2

Anforderungen festhalten

Das Besprochene als Anforderungsdokument (PRD) schreiben lassen. Jedes größere Feature bekommt sein eigenes kleines PRD.

3

Bauen und über Sitzungen tracken

Claude arbeitet das PRD ab und hält den Fortschritt in TODO-Dateien fest – so nimmt eine neue Sitzung Tage später genau dort wieder auf.

4

Visuell prüfen

Claude öffnet Gebautes selbst im Browser und prüft es per Screenshot. /code-review sucht Fehler im Code, /human-writing KI-typische Floskeln im Text.

5

Gegen Rückschritte absichern

Testskripte laufen bei jedem Build und prüfen, ob bestimmte Elemente vorhanden sind oder verschwunden – damit einmal Korrigiertes nicht wieder zurückfällt.

6

Wissen festschreiben

Korrekturen und Stilregeln landen in einer Wissensbasis und einem Styleguide und gelten automatisch für alle künftigen Sitzungen.

Was besonders viel Zeit sparte: Ziele statt Einzelaufträge (per /goal) ermöglichten langlaufende KI-Sitzungen, die selbstständig bauen, prüfen und dokumentieren – ohne ständiges Nachfassen.
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Die häufigste Frage

„Was muss man da eingeben?“

Echte Eingaben aus dem Projektverlauf
„in …/ordnungen/finder findest du den studiengangsfinder der wiai. […] lies das PRD und beginne die implemntierung eines prototypen / mockups …⁠“
„sieht besser aus, achte aber auf tastaturnavigierbarkeit (bei beiden formularen! wcag!). wenn man am ende von 1. interessen auf weiter klickt, passiert.... nichts.⁠“
„die 5er-sammlung ist zu schmal: [Screenshot] – vielleicht in dem fall lieber 3 in der ersten zeile und schritt 4 und 5 dann in einem 2-er grid⁠“
„hol feedback ab – ich will mein feedback zum go-live-audit einarbeiten – du wirst jede menge anderes feedback sehen, das bleibt auf initial⁠“
Was man daran sieht
  • Normale Sätze genügen. Keine Programmiersprache, keine Formeln – Tippfehler stören auch nicht („implemntierung“ hat funktioniert).
  • Zeigen statt beschreiben: Screenshot einfügen und sagen, was stört – wie mit einer Kollegin am Bildschirm.
  • Der Kontext liegt im Projekt: Anforderungen, Wissensbasis und Stilregeln liest die KI bei jeder Sitzung automatisch mit. Man erklärt sie nicht jedes Mal neu.
  • Dann arbeitet sie selbstständig: Dateien lesen, ändern, bauen, testen – und meldet sich mit Ergebnis und Rückfragen.
Optional vertiefen: Echte Modellantworten und ein Glossar für „Claudisch“Öffnen ▸

Vertiefung · Sprache der Werkstatt

Wenn das Modell seinen eigenen Jargon entwickelt

Echte Antworten des Modells
„Gute Nachricht zur PIN-Falle: Das Backfill pinnt für beide Slugs nur compass_items und lehre_und_ort – example_modules ist nicht gepinnt.⁠“
„betriebswirtschaftslehre-bachelor ist frozen → in World B ohne Video (gewollt), in World A (Reviewer-Welt) mit.⁠“
„Damit ist die ganze […]-Welle durch: 5 Workstreams umgesetzt, 12 Items resolved / 3 discuss, 103 Regressionstests grün.“
„Protokoll als Triage-Kommentar, Item resolved, kein leerer Wellen-Ballast.⁠“
„Der FAQ-Agent ist an einem API-Fehler gestorben, kurz bevor er schreiben wollte – ich wecke ihn zum Weitermachen.⁠“
„Jetzt die Build-Invariante – mit der Einschränkung, dass der andere Claude build.py dirty hat.⁠“

Die Begriffe hat sich das Modell größtenteils selbst ausgedacht – griffig für die Arbeit, rätselhaft für alle anderen.

Glossar
  • World A / B / C: drei parallele Fassungen des Portals – die volle, die veröffentlichte und die Probier-Fassung für Fachvertreter-Feedback.
  • Welle: ein Bündel zusammengehöriger Änderungen aus einer Feedback-Runde.
  • frozen / einfrieren: eine Seite ist gegen weitere Änderungen gesperrt, weil sie fertig geprüft ist.
  • gepinnt / PIN-Falle: eine Seite wird aus einer festgeschriebenen Kopie gebaut – wer an der ursprünglichen Quelle ändert, ändert ins Leere.
  • resolved: Feedback-Item erledigt und beantwortet.
  • dirty: eine Datei wurde geändert, aber noch nicht ins Versionsarchiv übernommen.
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Die häufigste Frage

Die Vokabeln am lebenden Objekt

Studiengangsseite Anglistik/Amerikanistik mit beschrifteten Gestaltungselementen Hero Badge Lead Pills Eyebrow Card Steckbrief

Studiengangsseite Anglistik/Amerikanistik am 8. Juli – rot beschriftet, wie diese Stellen im Gespräch mit dem Modell heißen.

Optional vertiefen: Weitere Webdesign-Begriffe und wie oft sie verwendet wurdenÖffnen ▸

Vertiefung · Begriffe

Die Webdesign-Begriffe der Zusammenarbeit

Das Modell spricht den Jargon des Webdesigns – wer die Vokabeln kennt, kann präzise sagen, was anders werden soll. Die Zahl hinter jedem Begriff zeigt, wie oft er in den 2.699 Eingaben dieses Projekts an die KI vorkam:

Struktur einer Seite
  • Hero (50×): der große Kopfbereich mit Bild und Titel.
  • Card / Kachel (95×): rechteckiger Inhaltsblock im Raster.
  • Grid (34×): das unsichtbare Spaltenraster, an dem sich alles ausrichtet.
  • Masonry (61×): Kachel-Raster mit versetzten Höhen, wie eine Ziegelwand.
  • Breadcrumbs (3×): der „Sie sind hier“-Pfad oben auf der Seite.
  • Footer (19×): der Fußbereich ganz unten auf jeder Seite.
Text-Bausteine
  • Eyebrow (19×): kleine Großbuchstaben-Zeile über der eigentlichen Überschrift.
  • Lead (10×): der Anreißertext direkt unter der Überschrift.
  • Kicker (3×): kurze Einordnungszeile an einem Zitat oder einer Kachel.
  • Pill (29×): kleines abgerundetes Etikett, etwa „6 Semester“.
  • Badge (2×): kleines Hinweis-Schildchen, etwa „Placeholder“ an ungeprüften Inhalten.
  • CTA (12×): „Call to Action“ – die Schaltfläche zum nächsten Schritt, etwa „Studiengang finden“.
Verhalten und Bild
  • Hover (10×): was passiert, wenn der Mauszeiger über einem Element steht.
  • Modal (6×): Fenster, das sich über die Seite legt – etwa der Video-Player.
  • Toast (1×): kurz eingeblendete Rückmeldung am Bildschirmrand („Gespeichert“).
  • Viewport (8×): der sichtbare Bildschirmausschnitt – entscheidend für die Handy-Ansicht.
  • Crop (4×): der Bildzuschnitt – was vom Foto im Rahmen sichtbar bleibt.
  • Full bleed (3×): ein Bild läuft randlos über die volle Breite.
  • Padding / Margin (29×): Innen- und Außenabstand eines Elements.
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Hinter den Kulissen

Drei Prüfebenen

Warum aus KI-Entwürfen verlässliche Seiten wurden: Jede Ebene fängt, was die anderen strukturell nicht sehen können.

1

Bauen mit Grundsicherung

Das Chief Information Office bedient die KI-Werkzeuge und sichert schon beim Bauen die Grundqualität – mit KI-Routine, Uni- und Fachverständnis und Webdesign-Urteil.

2

Fachliches Einzel-Review aller Seiten

Studiengangsbeauftragte, Fachstudienberatungen und weitere Fachvertretungen prüfen je ihr Fach – die einzige Ebene, die fachliche Richtigkeit im Detail beurteilen kann.

3

Übergreifende Prüfung und Redaktion

Verschiedene Abteilungen der Verwaltung prüfen seitenübergreifend und redigieren: Konsistenz, Sprache, Zielgruppen-Passung – und alles, was ein Einzel-Review naturgemäß nicht sieht.

Mehrfachprüfung war kein Luxus: Auch ECTS-, Voraussetzungs- und Aufbaufehler fielen teils erst der dritten Ebene auf.
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Hinter den Kulissen

Der Weg einer Änderung ins Portal

Die praktische Antwort auf den Entscheidungs-Engpass: ein Feedback- und Freigabekreislauf, den auch technisch nicht versierte Beteiligte bedienen können – Änderungen probeweise sehen, einzeln freigeben.

1

Feedback-Button auf jeder Seite

Öffnet direkt ein Eingabefeld. Man kann ein bestimmtes Element auf der Seite anklicken oder Text markieren und konkret sagen, was anders werden soll – Element und Seitenstand werden automatisch mitgespeichert.

2

In der Inbox sammeln

Alle Rückmeldungen laufen in einer gemeinsamen Inbox zusammen. Claude ordnet sie ein und gruppiert Zusammengehöriges – einzeln oder gebündelt abrufbar.

3

Probeweise einbauen

Zusammengehörige Rückmeldungen setzt Claude in einem eigenen Branch um – einer abgetrennten Arbeitskopie des Portals – und stellt sie intern als Vorschau bereit, mit Vorher/Nachher als Text- und Bildvergleich.

4

Prüfen und entscheiden

Verschiedene Abteilungen der Verwaltung sehen jede Änderung – auch seitenübergreifend, denn der Branch enthält den ganzen Seitenbaum – und nehmen an, ändern oder lehnen ab; fachliche Änderungen an Studiengangsseiten gehen zusätzlich an die zuständigen Fachvertretungen. Bei Unklarheit holt Claude die Freigabe automatisch bei der einsendenden Person ein.

5

Übernehmen und rückmelden

Freigegebenes wird in den offiziellen Portal-Stand übernommen; die einsendende Person bekommt per E-Mail Bescheid, sobald es tatsächlich live ist.

6

Prüfen und live schalten

Vor jedem Live-Gang wird eine interne Kopie des ganzen Portals noch einmal geprüft. Passt sie, geht sie per /deploy als statisches HTML online.

www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Hinter den Kulissen

Wie dieser Prozess entstand

Der Kreislauf der vorigen Folie stand nicht am Anfang. Er wuchs in vier Stufen – jede löste ein Problem, das die vorige offenließ.

1Ganze Stände neu erzeugenJede Änderung erzeugte einen kompletten neuen Stand; Rückmeldungen dazu liefen umständlich per E-Mail.
→
2Feedback-Button auf jeder SeiteElement anklicken, Wunsch beschreiben, die KI arbeitet ihn ein. Was noch fehlte: nachvollziehen, was sich dadurch am Stand änderte.
→
3Menschenlesbare ÄnderungslistenDie KI fasste die Unterschiede zwischen zwei Ständen automatisch zusammen – nützlich, aber es reichte nicht, um den Überblick zu behalten und einzeln abzunehmen.
→
4Branches mit Vorher-Nachher-VorschauJede Änderung isoliert in einer Arbeitskopie, einzeln prüf- und freigebbar. Wie das aussieht, zeigt die nächste Folie.
Erst ab Stufe 4 ließ sich jede Änderung isoliert prüfen – unabhängig davon, wie viel Feedback gleichzeitig einging.
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Hinter den Kulissen

Eine Prüfung im Vorher/Nachher

Prüfansicht einer vorgeschlagenen Änderung mit Vorher/Nachher-Vergleich

Eine vorgeschlagene Textänderung in der Prüfansicht: links die Rückmeldung, rechts Claudes Umsetzung samt Hinweis an die prüfenden Verwaltungsabteilungen und dem Vorher/Nachher-Vergleich. Unten die Entscheidung – annehmen, mit Änderung annehmen oder ablehnen.

www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Grenzen und Fehler

Was mit dem Sprachmodell schiefging

Wiederkehrende Probleme
  • Halluzinationen: erfundene Modulbeschreibungen, falsche Gebäudezuordnungen, ein ausgedachter Projektname – ohne jede Quelle, aber überzeugend formuliert.
  • Überschwängliche Sprache: Superlative und Marketing-Floskeln, die erst der Styleguide wieder einfängt.
  • Wörtlich genommene Anweisungen: gut gemeinte Vorgaben führen zu kuriosen Umgehungen – Beispiel rechts.
  • Unvollständige Übertragung: Selbst „überall, wo nötig“ reichte nicht immer. Eine am Beispiel erklärte Korrektur wurde nur an einigen Fundstellen umgesetzt; erst mehrere Such- und Prüfdurchläufe erfassten alle Varianten.
Das ist kein Bamberger Sonderfall: Halluzination, Superlativ-Sprache und wörtlich genommene Anweisungen gehören zum normalen Verhalten heutiger Sprachmodelle. Wer damit baut, muss diese Fehlerarten kennen.
Bestimmte StudyCheck-Formulierungen sollten raus – gemeint war: die Aussagen weglassen. Das Modell strich nur den Namen und schrieb von „einem großen Studiengangsbewertungsportal“. Anweisung formal befolgt, Sinn verfehlt.
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Grenzen und Fehler · die Datenfrage

Warum halluzinierte die KI trotz aller Daten?

Was das Modell hatte

Einen Crawl sämtlicher Studiengangsseiten, Modulhandbücher, Studien- und Fachprüfungsordnungen und Studieninteressierten-Seiten – in mehreren Durchläufen den Studiengangskürzeln zugeordnet. Der Sache nach ein Retrieval-System („RAG“): Das Modell hatte alles, was online stand.

Warum das nicht reichte
  • Widersprüchliche Quellen: Webseiten und PDFs (Modulhandbücher, Ordnungen) stimmten oft nicht überein – es fehlte ein belastbarer Anker.
  • Anweisungstreue als Halluzinationsquelle: Das wörtliche Befolgen von Vorgaben (vorige Folie) kippt bei dünnem Material in Erfindung: „Möglichst anschauliche Beispielmodule identifizieren“ wollte das Modell unbedingt erfüllen – und erfand notfalls etwas gut Klingendes, statt die Aufgabe unerfüllt zu lassen.
  • Ein Fach, viele Varianten: 1-, 2- und 3-Fach-Bachelor, erweitertes Hauptfach, Nebenfach, Lehramt – viele Aussagen stimmen nur für einzelne Varianten. Passende Datenstrukturen kamen erst spät, und die Prüfung aller Varianten ist nicht vollautomatisierbar.
  • Ungeschriebenes Wissen: Manche Details stehen nirgends online, sondern werden von Fachstudienberatung und Prüfungsausschüssen so praktiziert – ein nur mit dem Online-Stand gefüttertes Modell hatte keine Chance.
Die Gegenmaßnahme – Beleg-Sweeps: Für jede Aussage einer Studiengangsseite mindestens einen Beleg in Webseiten, Modulhandbüchern oder Ordnungen suchen; ohne Beleg wird sie als fragwürdig markiert. Sie kamen spät und nicht für alle Seiten systematisch – von Anfang an eingeplant, hätten sie viel Nacharbeit erspart.
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Der Rücklauf aus den Fächern · zwei Richtungen

Wenn eine Seite hart kritisiert wird

Das Gesamtbild – und ein Einzelfall

Feedback wurde beantwortet und gemeinsam korrigiert

Viele Rückmeldungen waren ausgesprochen positiv, viele Fachvertretungen redigierten ihre Seiten schnell und gründlich; insgesamt gingen 264 Antwortmails an die Rückmeldenden zurück. Das Spektrum reichte dennoch bis zu deutlichem Frust – rechts der schärfste Einzelfall.

Die Rückmeldung eines Fachs

In einem einzelnen Fach meldeten Studiengangsbeauftragte, wissenschaftliches Personal und Fachstudienberatung gemeinsam, die Portalseiten seien „zum Verzweifeln fehlerhaft“, schickten eine Mängelliste – und schlugen vor, das Fach vorerst aus dem Portal zu nehmen.

Die Korrektur

Die KI setzte die meisten Kritikpunkte innerhalb weniger Minuten direkt um; statt die Seite zu entfernen, wurde vorgeschlagen, sie mit den Korrekturen zu behalten – und die einsendende Person gefragt, ob das für sie in Ordnung sei.

Nach der Überarbeitung

„Nach nochmaliger Durchsicht keine Beanstandungen mehr.“

Der Einzelfall steht für das Muster: Das Portal ging bewusst mit bekannten Restfehlern online – tragbar, weil der Feedback- und Freigabekreislauf sie in den Tagen nach dem Go-Live schnell einfängt, hier binnen Minuten.
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5
4

Teil 4 von 4

Aufwand, Lehren und Beteiligte

Der Aufwand in Zahlen, die Lehren fürs nächste Mal – auch die noch strittigen – und alle, die am Portal mitgebaut haben.

www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Aufwand

Commits pro Tag – drei Phasen bis zum Go-Live

Aufbau392 Commits · 24.04.–18.05.
Grundgerüst, Datensammlung
Ruhephase21 Commits · 19.05.–04.06.
Ferien
Endspurt1.092 Commits · 05.06.–08.07.
73 % aller Commits bis zum Go-Live entstanden hier

Geplant waren im PRD sechs Wochen – das war zu optimistisch. Vor allem die nötigen Abstimmungs- und Korrekturrunden sowie die Pfingstferien machten elf daraus – die Ruhephase Ende Mai zeigt es.

Wie viel Aktivität steckt darin? Commit-Zeitstempel ergeben 162 bis 399 Stunden Aktivitätsfenster – keine belastbare Arbeitszeiterfassung.Wie geschätzt wird ▸

Vertiefung

Was die Zeitstempel zeigen – und was nicht

Was geschätzt wird: Eine präzise Zeiterfassung gab es nicht. Aber die Zeitstempel der Commits – gespeicherte Arbeitsstände, mal eine kleine Korrektur, mal ein ganzes Feature – erlauben einen Rückschluss auf die Arbeitszeit: Commits mit höchstens 30 min Abstand gelten als zusammenhängende Arbeitsphase. Drei Rechenwege beschreiben Aktivitätsfenster am Rechner: die reinen Phasen-Spannen ergeben 162 h; mit 15 min Puffer vor und nach jeder Phase 297 h; mit 30 min Puffer 399 h.

Zwei gegenläufige Effekte: Gemessen ist nur die Bau- und Integrationszeit am Rechner – Meetings, Vorstellungstermine und Abstimmungs-E-Mails fehlen und kämen hinzu. Umgekehrt lief in den gepufferten Wartezeiten parallel ein weiteres Projekt, das vor allem das obere Ende aufbläht. Für die exklusiv auf das Studienportal entfallende Arbeitszeit heißt das: eher am unteren Rand des Korridors.

  • Phasen-Spannen
    162 h
  • ± 15 min Puffer
    297 h
  • ± 30 min Puffer
    399 h

Zusätzlicher Review-Aufwand

Ebenfalls nicht in den Stunden enthalten: die Korrekturlese-Zeit der Rückmeldenden. Die großzügigste der drei Heuristiken (±30 min Puffer), angewandt auf die Feedback-Zeitstempel, schätzt sie auf noch einmal rund 290 h.

www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Aufwand

Das Projekt in acht Zahlen

1.548gespeicherte Arbeitsstände (Commits) – 1.505 davon bis zum Go-Live
162–399hrechnerische Aktivitätsfenster aus Commit-Zeitstempeln
20–50rechnerische Acht-Stunden-Tage – keine Zeiterfassung
62/78Kalendertage mit mindestens einem Commit – von 78 Tagen im Projektzeitraum
103Commits am Spitzentag, dem 29. Juni
13,7hgrößtes Aktivitätsfenster an einem Tag, am 14. Juni
6.722Mal wurde im Projektverlauf eine Datei geändert
+1,17MioZeilen Text, Code und Daten hinzugefügt – 0,56 Mio wieder entfernt

Ein Commit ist ein gespeicherter Arbeitsstand im Versionsarchiv – mal eine kleine Korrektur, mal ein ganzes Feature. Die eigentlichen Kosten sind Arbeitszeit: ≈300 h Bau und ≈290 h Prüf- und Feedback-Arbeit der Rückmeldenden – zwei ähnlich große Blöcke; die ≤604 € für die KI-Abos sind daneben vernachlässigbar. Zeitwerte: Näherungen, keine Zeiterfassung – Methode in der Vertiefung der vorigen Folie.

Und die KI-Seite davon? 139 Arbeitssitzungen allein im letzten Monat.Die Werkstatt-Zahlen ▸

Vertiefung

Die KI-Werkstatt in Zahlen – allein der Endspurt

139Arbeitssitzungen mit Claude Code
1.246schriftliche Anweisungen und Rückfragen – rund 9 je Sitzung
14.329Arbeitsschritte des Modells: Dateien lesen, ändern, bauen, testen
44Mioerzeugte Textbausteine (Tokens) – Antworten, Code, Analysen
9,7Mrdgelesene Textbausteine – das Projekt wurde dafür immer wieder neu gelesen
4KI-Modelle im Einsatz: Opus 4.8, Fable 5, Sonnet 4.6 und GPT 5.5

Nur der Zeitraum 11.06.–10.07.: ältere Protokolle werden nach 30 Tagen automatisch gelöscht, und die Sitzungen der Redaktion auf dem gemeinsamen Server fehlen. Die tatsächlichen Zahlen liegen also höher. Ein Token ist ein Wortbestandteil, grob drei Viertel eines Wortes.

Direkte KI-Kosten: rund 604 Euro für den gesamten Zeitraum seit dem 22. April – drei Monate Claude Max à 180 Euro, drei Monate ChatGPT Plus à 18 Euro sowie etwa 10 Euro OpenRouter-Guthaben (für menschenlesbare Änderungszusammenfassungen zwischen zwei Versionen und die ursprüngliche Extraktion der Texte aus den Web-Crawl-Zusammenfassungen). Weitere token-basierte Kosten fielen nicht an – alles Übrige lief über die Flatrate-Abos. Über dieselben Abos liefen auch andere Projekte; der allein dem Studienstart-Portal zurechenbare Anteil liegt also darunter.

www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Lehren und nächste Schritte

Was wir gelernt haben

Der Prozess ließ sich nicht vorab planen

KI erzeugt Stände schneller, als ein Team sie überblickt – wie beim Versionschaos, wenn viele zugleich an denselben Seiten arbeiten. Welcher Ablauf das bändigt, ließ sich nicht vorausplanen; wir haben ihn in elf Wochen mehrfach umgebaut, was nur ging, weil die KI passende Werkzeuge binnen eines Tages lieferte.

Das hatte einen Preis: Zeitweise wurde Beteiligten der Boden unter den Füßen weggezogen. Erst der stabile Freigabekreislauf änderte das – acht Tage vor dem Go-Live.

Mit geprüften Daten beginnen

Hohes Tempo braucht eine qualitätsgesicherte Datengrundlage. Jede Aussage sollte von Anfang an ihre Herkunft und ihren Prüfstatus mitführen – sonst kostet es später viel Zeit, unbemerkt KI-erfundene Angaben aufzuspüren und zu ersetzen – warum das schwer ist, zeigt die Datenfolie in Teil 3.

Prototypen machen Fragen sichtbar

Konkrete Seiten schufen früh eine gemeinsame Grundlage für Entscheidungen über Gestaltung, Zielgruppen und Sonderfälle.

Qualität entsteht im Feedbackkreislauf

Aus 2.449 Rückmeldungen wurde das Portal Runde um Runde genauer – jede geprüft, bevor sie einfloss.

www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Lehren und nächste Schritte

Wo die Einschätzungen auseinandergehen

Hat sich die KI-Textarbeit gelohnt?

Aus der Redaktionspraxis: Frei generierte Texte brauchten so viele Korrekturrunden, dass Selbstschreiben oft günstiger gewesen wäre. Aus der Bau-Praxis: Die Entwürfe gaben den Fächern etwas Konkretes zum Redigieren – und zum Verwerfen; vor einer leeren Seite wäre vieles nie entstanden. Vermutlich gilt beides, je nach Fach verschieden. Konsequenz: Für neue, redaktionell anspruchsvolle Bereiche werden Passagen künftig stärker selbst zugeliefert.

Wie wird das Portal dauerhaft gepflegt?

Dezentral in den Fächern mitpflegen oder stärker zentral verankern? Beides hat Kosten: Verteilte Pflege bindet viele, zentrale Pflege wenige – aber hoch spezialisierte. Die Pflege ruht bislang auf wenigen Schultern; Schulungen verteilen sie gerade auf mehr. Dafür greifen Änderungen quer über alle Seiten auf einmal – konsistenter als das seitenweise Nachpflegen in einem klassischen Redaktionssystem. Noch nicht entschieden.

Wie es weitergeht: Betrieb, Pflege und Wirkungsmessung des Portals.Nächste Schritte ▸

Nächste Schritte

Wie es weitergeht: Betrieb und Wirkung

Verantwortung im Betrieb

Die inhaltliche Kontrolle liegt bei den Kommunikations- und Beratungsstellen, der technische Betrieb beim Chief Information Office. Weil das Portal aus statischen HTML-Seiten ohne Backend besteht, ist das Laufzeit-Risiko gering.

Wirkung messen

Ein A/B-Test läuft bereits: Werbung führt parallel auf den bisherigen Studiengangsfinder der Universität und die neuen Portalseiten. Denkbar wären zusätzlich Befragungen neu Eingeschriebener. Erhoben wird datensparsam, ohne Drittanbieter-Tracking.

www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Beteiligte

Ein Projekt vieler Rollen

Wer was verantwortet hat
  • Idee, Konzeption und Umsetzung – das Chief Information Office Aufbau des Portals mit Claude Code und technischer Betrieb.
  • Übergreifende Prüfung und Redaktion – verschiedene Abteilungen der Verwaltung prüften seitenübergreifend Konsistenz, Sprache und Zielgruppen-Passung und redigierten Verwaltungs-, Bewerbungs- und Zulassungstexte.
  • Fachliche Prüfung und Zulieferung – Studiengangsbeauftragte, Fachstudienberatungen und weitere Fachvertretungen brachten das Fachwissen ein, das keine zentrale Stelle liefern kann: Sie prüften und korrigierten ihre Studiengangsseiten in mehreren Review-Wellen und lieferten einen großen Teil der inhaltlichen Substanz zu. Ohne diese fachliche Zuarbeit wäre das Portal nicht möglich gewesen.
Das Feedback in Zahlen
  • 2.449 Feedback-Items von 79 Absender-Adressen – dahinter teils Funktionspostfächer und gebündelt eingereichtes Feedback, also noch mehr Menschen
  • 61.000 Wörter Feedback – rund 200 Textseiten
  • ≈290 h geschätzte Feedback-Arbeit der Rückmeldenden – mit der großzügigsten der drei Bau-Heuristiken gerechnet
  • 224 Seiten des Portals wurden kommentiert
  • 83 % der Items umgesetzt (2.038 von 2.449), der Rest begründet zurückgestellt
  • 264 Antwortmails mit 90.000 Wörtern gingen zurück an die Rückmeldenden
Und die Fundamente: der Studiengangsfinder der Universität als verlässliche Datenbasis über alle Studiengänge, dazu der Bild- und Videofundus der Kommunikationsabteilung – beides machte das Tempo möglich.
www.uni-bamberg.de/studienstart · Retrospektive · Öffentliche Fassung · v5

Retrospektive · Schluss

Seit dem 8. Juli: online.

www.uni-bamberg.de/studienstart

„wir wollen heute live gehen – kannst du […] das banner ‚Testbetrieb! Seiten noch nicht zur Veröffentlichung bestimmt.‘ […] aus dem buildprozess entfernen?“

Kurz darauf war das Banner weg. Das Portal lebt weiter – 43 Arbeitsstände seit dem Go-Live. Feedback ist weiterhin willkommen; der Link dazu sitzt auf jeder Portalseite unten rechts.

Zum Mitnehmen

Der Engpass war die Entscheidung, nicht die KI: Varianten entstehen schneller, als Menschen sie gemeinsam prüfen und freigeben können. Das wichtigste Werkzeug war deshalb der Feedback- und Freigabekreislauf, mit dem Menschen jede Änderung prüfen und freigeben.

11 Wochenvon Prompt bis Go-Live
200+ Seitenaus einem Baukasten, 1.548 Arbeitsstände
2.449Rückmeldungen von 79+ Einsendenden, 83 % umgesetzt
≈300 + ≈290 hgeschätzte Aktivität: Bau + Review der Rückmeldenden
≤604 €KI-Kosten der Abos im Projektzeitraum – parallel liefen andere Projekte darüber
264Antwortmails zurück an die Rückmeldenden – der Kreislauf hat zwei Richtungen

Zeitwerte: Näherungen aus Zeitstempeln, keine Zeiterfassung; der allein dem Portal zurechenbare Bau-Anteil liegt eher darunter – Methode auf den Aufwands-Folien.

Dominik Herrmann · Juli 2026 · Öffentliche Fassung · v5