Ein Quiz zum Archivwesen - Erfahrungen mit Vibecoding

 

Vibecoding, oder auch „gefühlsmäßiges Programmieren“, ist ein relativ neuer Trend in der Softwareentwicklung. Der Begriff wurde 2025 von Andrej Karpathy eingeführt und bezeichnet eine Methode der Softwareentwicklung, bei der ein Problem in Alltagssprache erklärt wird und eine Künstliche Intelligenz eine Softwarelösung dafür entwickelt. Dadurch verschwimmen klassische Strategien und Schwerpunkte im Softwareentwicklungsprozess wie Roadmaps, Meilensteinplanung, UX/UI-Design, Governance und Security-Testing etc. Konkret genutzt werden dafür sogenannte Large Language Models (LLM), zum Beispiel Codex, Claude oder GitPilot. Nach einem natürlichsprachigen Prompt übernimmt das KI-Modell die Programmierung und alles Weitere, was dazugehört: die Auswahl von Algorithmen, Frameworks und Bibliotheken sowie die Kommentierung und Dokumentation des Quellcodes. Auf Wunsch erstellt es auch Testunits und präsentiert am Ende das fertige Resultat.

 

Die Verheißung besteht schließlich darin, selbst Softwareprojekte und eigene Apps zu entwickeln, mit denen sich alle nur denkbaren Probleme lösen lassen – und das ganz ohne Informatikkenntnisse. Die einzige Kontrollinstanz liegt dabei in: „Funktioniert es” oder „funktioniert es nicht”?

Dieser Idealvorstellung muss jedoch ein kleiner Dämpfer gegeben werden. Zwar lassen sich sehr schnell lauffähige Projekte aufsetzen, jedoch sollte man immer im Blick behalten, wofür diese generierte Software letztlich eingesetzt werden soll. Ist sie für den Privatgebrauch gedacht? Soll eine Institution davon profitieren? Handelt es sich um langfristigen Dauereinsatz oder nur kurzweilige Projektorientierte Arbeiten?

 

Vibecoding ist für die Umsetzung kleiner Softwareprojekte mit überschaubarem Funktionsumfang und geringem Wartungsaufwand geeignet (geringe Abhängigkeit von volatilen Programmbibliotheken, keine sicherheitskritischen Einsatzfelder). Es eignet sich für einzelne Lösungsansätze mit klar abgegrenztem Fokus, wie beispielsweise grafische Oberflächen für Kommandozeilentools. Oder für einmalige und zeitlich begrenzte Einsatzzwecke. Auch MVPs, Demos, Machbarkeitsstudien und Proof of Concepts lassen sich damit gut entwickeln. In der Regel lassen sich auch einzelne Funktionen, Programmteile oder eng gefasste Softwarebausteine gut realisieren. 

In der Praxis öffentlicher Einrichtungen wird dies jedoch wahrscheinlich keine Rolle spielen und allenfalls im Rahmen von Schatten-IT-Infrastrukturen Einzug halten. Denn auch gevibecodete Tools und deren Einsatz müssen zwangsläufig die institutionseigenen Akkreditierungsverfahren und Datenschutzfolgeabschätzungen durchlaufen, wie es bei regulären Softwareprojekten auch der Fall ist. Bei software die nur "gefühlmäßig korrekt läuft", könnte dies mithin schwierig werden. Zudem wird die Haftungsfrage bei KI-generierter Software schnell sehr komplex. 

Vibecoding ist vor allem dann nicht geeignet, wenn es in Softwareprojekten eingesetzt werden soll, deren Prüfrahmen eine saubere Coderevision erfordert, die aber eigentlich nicht von der vorhandenen technischen Sachkenntnis abgedeckt werden kann. Auch wartungsintensive und komplexe Standalone-Software kann dabei problematisch werden. Dies kann beispielsweise der Fall sein, wenn Vibecoding in größeren Softwareentwicklungsteams eingebettet werden soll. Ebenso kann Software, die ein voraussetzungsreiches Deployment oder eine tiefe Systemintegration erfordert, für weniger erfahrene Nutzer:innen zu einem großen Problem werden. Ein solcher Einsatz führt außerdem zu vermehrten Insellösungen für Einzeleinrichtungen, die später kaum zu konsolidieren sind. Auch der eigentlich wichtige fachübergreifende Austausch wird aufgrund eines mangelnden Codeverständnisses ggf. schwierig bis unmöglich, wenn Vibecoding-Produkte zu einer „Blackbox” werden. Zu beachten sind auch die ggf. entstehenden Folgekosten. Nur weil ein Softwareprojekt via Vibecoding schnell umgesetzt werden kann, bedeutet dies nicht, dass regelmäßige Änderungen, Implementierungen oder Anpassungen nicht dennoch nötig werden. Nicht zuletzt kann ungeprüftes Vertrauen in die Funktionsfähigkeit des Codes zu Fehlern bis hin zu Datenverlust führen.  So löschte im Juli 2025 ein KI-Agent, der die Plattform SaaStr aktualisieren sollte, ohne menschliche Prüfung die komplette Produktivdatenbank des Systems (Quelle). Im März 2026 setzte Amazon ein KI-gestütztes Tool für das Code-Deployment ein. Dabei wurde Quellcode ohne ausreichende menschliche Validierung in eine Live-Umgebung eingespielt. Ein unbemerktes Fehlverhalten führte zu einem sechsstündigen Ausfall der Hauptseite (Quelle). 

 

Diese Beispiele zeigen, wie wichtig verantwortungsvolles Handeln und die Berücksichtigung von Technikfolgen im eigenen Möglichkeitsspektrum sind. Sie vermitteln außerdem einen Eindruck davon, warum die institutionseigenen Prüfmechanismen zum Einsatz von Software, gerade bei KI-generierter Software, wichtig sind.

 

Um Vibecoding einmal praktisch zu demonstrieren, ist ein überschaubares Projekt eine gute Wahl. Ein Quiz für Archivarinnen und Archivare wäre hierfür ein gutes Testfeld. Es handelt sich dabei um einen eng umgrenzten, sich nicht ändernden Bezugsrahmen ohne höhere Sicherheitsanforderungen oder tiefere Systemintegration. Die Daten werden nicht verändert und das Quiz kann als Website gehostet werden. Da es für Quizzes bereits unzählige Varianten, Beispiele und Ideen aus allen Lebensbereichen gibt, sollte die Umsetzung in KI kein Problem darstellen. Dies soll im Folgenden gezeigt werden. Zunächst werden Fragen und ggf. ein Logo benötigt. Beides lässt sich recht problemlos generieren. 

Selbstverständlich ist, dies sei kritisch angemerkt, eine Liste generierter Fragen, wenn man ein solches Projekt ernsthaft betreiben würde, noch einmal zu kuratieren. In diesem Fall sollten insgesamt 1.000 Fragen aus den Bereichen Archivwesen, Archivkunde, Diplomatik, Heraldik, Sphragistik, Kodikologie, Bestandserhaltung, Benutzungsbetreuung, Retrodigitalisierung, digitale Langzeitarchivierung, Archivtechnik, Archivgeschichte und Archivtheorie mit jeweils einer richtigen und drei falschen Antworten erzeugt werden. Bei der Durchsicht lässt sich jedoch beispielsweise erkennen, dass die richtigen Antworten mitunter etwas länger sind als die falschen. Da die Fragen zudem nur als Stichprobe auf Korrektheit geprüft wurden, ist eine 100-prozentige Sachrichtigkeit ggf. nicht gewährleistet. Dies kann jedoch auch bei echten Quizzes passieren (Fails bei „Wer wird Millionär?”). Zudem ist teilweise ein hohes Detailwissen in diversen Domänen nötig, für das ggf. ein größerer Kreis an Fachexperten erforderlich ist. Kennen Sie beispielsweise die zentrale heraldische Beziehung zwischen Eichhorn-, Wolken- und Eisenhutfeh? Alle für dieses Experiment genutzten und generierten Daten finden Sie, samt Quellcode in einem GIT Repositorium, das auch zum Selbststudium genutzt werden kann.

 

Zu Anschauungszwecken und zur Veranschaulichung der generellen Machbarkeit habe ich zur weiteren Verarbeitung der Fragen (die als XLSX vorliegen) und des erzeugten Logos zunächst einen sehr simplen Prompt (Aufforderung an eine KI) genutzt. So wird veranschaulicht, wie unaufwendig und niederschwellig bereits eine simple Eingabe zu Ergebnissen führen kann.

 

Prompt:

„Tu bitte so, als wärst du ein professioneller Game Designer. Plane ein Spiel, welches komplett mit JavaScript und HTML umgesetzt ist, den Titel „Archivieren oder Kassieren“ trägt und sofort offline heruntergeladen und im Browser gestartet werden kann. Die Game-Mechanik soll an ein klassisches Fernsehquizspiel wie „Wer wird Millionär?“, „Wer weiß denn sowas?“, „Das 1 % Quiz“ oder „Jeopardy!“ erinnern. Im Spiel hat man vier Joker und soll am Anfang aus sechs Jokern vier wählen können. Es gibt Sicherheitsstufen und 15 Schwierigkeitsstufen. Nutze die angehängten Quizfragen und sortiere sie den Schwierigkeitsstufen zu. Nutze das Logo und orientiere dich beim Gamedesign daran. Das Spiel richtet sich an Archivarinnen und Archivare. Gib außerdem am Anfang eine kurze Hilfe mit Erläuterungen. Füge außerdem Soundeffekte sowie einen Nutzungsdisclaimer hinzu, der darauf hinweist, dass die Nutzung der Anwendung eigenverantwortlich und nur zu Testzwecken ohne echte Gewinne erfolgt."

 

Beim Formulieren eines sogenannten Prompts ist es vor allem wichtig, die Rolle und den Kontext der Anweisung klar zu formulieren. Ebenso sollte klar sein, was die eigentliche Aufgabe ist und in welcher Form der Output gegeben werden soll. Ebenso sollte klar sein, welche Einschränkungen oder ungewollten Ergebnisse vermieden werden sollen. Es gibt natürlich noch verschiedene Möglichkeiten, dies zu optimieren: iterativ vorzugehen, einen Prompt von einem LLM selbst noch einmal überarbeiten zu lassen, Beispiele zu geben (wie hier angedeutet) usw. Elaborierte Prompting-Techniken sprengen jedoch den Rahmen dieses Beitrags.

 

Das Ergebnis war mehr als überraschend: Nach nur 32 Minuten und 23 Sekunden lag bereits ein funktionsfähiger Prototyp vor. Um sich selbst ein Bild zu machen, habe ich die erzeugte Seite hier gehostet. Sie können das Quiz also selbst ausprobieren und Ihr Wissen im Bereich Archivwissen testen.

 

https://sugob05.github.io/archivieren_oder_kassieren.github.io/

 

oder

 

Start Archivquiz (externe Seite)

 

 

Hier gibt es außerdem einige Eindrücke:

 

Es handelt sich insgesamt um 3.109 Zeilen Quellcode mit 4,7 Millionen Zeichen und einer Gesamtgröße von etwa 4,7 MB. Alle Ressourcen sind neben dem eigentlichen Programmcode in einer HTML-Datei integriert. Dies umfasst ein Logo, welches über 80 % der Dateigröße ausmacht, sowie 1000 Fragen zum Archivwesen. Die Fragen werden zufällig gestellt und die Antwortmöglichkeiten werden gemischt. Die Sounds werden über die Web Audio API erzeugt. Dabei handelt es sich um eine vom W3C spezifizierte Browser-Schnittstelle zur Audioverarbeitung. Für das Spiel selbst sind weder externe Bibliotheken noch ein Backend erforderlich, sodass es vollständig offline genutzt werden kann.

 

Die HTML-Datei folgt einer sinnvollen, semantischen Struktur. Das Hauptelement im  body ist ein  div-Element mit der ID „App”, das den zentralen Anwendungscontainer darstellt. Es enthält die Kopfzeile sowie vier Sections für die Viewports „Startbildschirm”, „Jokerauswahl”, „Spielbildschirm” und „Abschlussbildschirm”. Dialoge ergänzen die Oberfläche um Hilfetexte und Rückfragen.

Zentrale CSS-Stilvorgaben sind in einem  style-Block im  header-Bereich definiert. Die Fragen sind in einem  script-Element in Zeile 1851 als JSON-Objekt mit Überlänge abgelegt. Das Logo wird in Zeile 1667 als Base64-kodierte Data-URL eingebunden und macht den größten Teil des Speicherbedarfs der Datei aus. Diese Einbettung entspricht der Vorgabe, alle für das Spiel erforderlichen Ressourcen in einer HTML-Datei zusammenzufassen.

 

Der gesamte interaktive Teil wird in JavaScript ab Zeile 1852 in einem  script-Block eingebettet. Ein zentrales state-Objekt regelt darin Stufen, Gewinne, den Sicherheitsbetrag und die Joker. Der Ablauf wird über die Funktionen „loadQuestion()”, „resolveAnswer()” und „finishRound()” realisiert.

Die Benennung der Variablen ist selbstsprechend. Eine Kommentierung wurde nur sehr selektiv im CSS- und JS-Block vorgenommen, der HTML-Block ist gänzlich unkommentiert. Der Scriptteil ist ebenso wie der HTML-Teil und der CSS-Bereich umgebrochen und eingerückt, was ein Codereview etwas vereinfacht. Ein ausdrücklicher Styleguide oder eine Benennungskonvention für den Quellcode liegt nicht vor. Die Benennung von CSS-Klassen folgt mehrheitlich dem kebab-case-Prinzip, HTML-IDs und JavaScript-Variablen folgen mehrheitlich dem LowerCamelCase-Prinzip. Zentrale JavaScript-Konstanten sind großgeschrieben und bei mehrteiligen Namen werden Unterstriche verwendet.

Insgesamt handelt es sich um einen wartbaren Quellcode, in dem kleinere Anpassungen durch Menschen möglich sind.

Es ist beeindruckend, wie schnell man ohne hohen Aufwand sehr gute Ergebnisse erzielen kann. Der Code selbst ist solide: Die Gestaltungsebene ist gut nachvollziehbar, die Wartbarkeit der Spielmechanik ist hingegen eingeschränkt. Der HTML- und CSS-Bereich ist hinreichend verständlich, sodass kleinere Änderungen, etwa im Design oder bei den Fragen, gut durchgeführt werden können. Schwieriger wird es jedoch, wenn im JavaScript-Bereich etwas geändert werden muss. Zwar vermitteln die Funktionsbenennungen einen ersten Eindruck, doch aufgrund der Verknüpfung der verschiedenen Spielregeln in der Gamemechanik ist dies selbst für erfahrene Entwickler nicht sofort einsichtig. Dadurch wäre z.B. das Hinzufügen oder Anpassen von Jokern mitunter recht herausfordernd, ebenso wie Änderungen im generellen Spielverhalten.

 

Zudem entbehrt diese enorme Umsetzungsgeschwindigkeit keiner fachlichen Prüfung. So können und werden fachliche Ungenauigkeiten enthalten sein, deren Verantwortungsbereich bei einer vollständigen KI ausgelagerten Entwicklung völlig offen bleiben. Wenn es sich hierbei beispielsweise um eine lokal laufende Software mit Systemintegration handeln würde, wären auch die Güteprüfung und institutionsspezifische Governance-Vorgaben noch stärker zu beachten. Bei einem dauerhaften Softwareeinsatz von mit Vibecoding entwickelten Anwendungen würde sich zudem eine weitere Dimension eröffnen: So wäre etwa zu klären, wer Wartungsroutinen, Updates und Sicherheitsfixes durchführen kann und wird, da diese als Daueraufgaben durchaus weitere Ressourcen benötigen.

 

Für Einzelaufgaben oder einzelfallbezogene Lösungsansätze birgt Vibecoding jedoch einige Potenziale, die sich insbesondere für die digitale Archivierung oder das Refreshing bzw. die Weiterentwicklung kleiner Funktionen in eigenen Codebases eignen. Auch die nachträgliche Dokumentation von Quellcode oder die Anpassung von Codekonventionen bietet KI mittlerweile eine Vielzahl von Möglichkeiten. Zu beachten sind jedoch die Absicherung der eigenen IT-Infrastruktur und die Durchführung ernsthafter Codereviews vor einem produktiven Einsatz. Zudem ist die messbare Ergebnisorientierung von Vibecoding zu beachten. Das dauerhafte Warten oder Einsetzen von so generierter Software erfordert jedoch einiges an Erfahrung und Wissen, das ggf. nicht unbedingt vorhanden sein muss. Eine tiefe Systemintegration kann zudem weitere Schwierigkeiten mit sich bringen. Dies spricht eventuell auch dafür, den Anteil an informationswissenschaftlichen Kompetenzen im Archivbereich weiter zu steigern.

 

Übrigens: Wie an diesem Projekt unschwer zu erkennen ist, lässt große Dateigröße allein  keinen Rückschluss auf eine hohe Softwarekomplexität zu. Einher damit gehen auch ein weitere bedeutungsloses Measurement, zur qualitativen Beurteilung von Softwareprodukten: Historische "Währungen" sind dahingehend etwa Anzahl der Quellcodezeilen, Storypunkte oder Gitpull oder eben "verbrauchte Tokens".

 

Tony Franzky

 

 

Quellcode und genutzte Ressourcen: "Archivieren oder Kassieren"? -  https://github.com/sugob05/archivieren_oder_kassieren.github.io/

 

Ein echtes, völlig KI-freies und analoges Quiz für das Archivwesen: Ullmann, Dirk: Ullmanns ArchivQuiz: 150 Fragen & Antworten rund um das Archivwesen. Berlin: BibSpider, 2008.