FALLSTUDIE / Persönliches Experiment · Agentische Programmierung
Diese Website mit KI entwickeln.
Prüfungen und Erkenntnisse.
Diese Fallstudie beschreibt, wie die Website entstanden ist, was vor der Veröffentlichung geprüft wurde und was spätere Pull-Request-Prüfungen bestätigt haben.
- Artikeldatum
Aktualisiert- Beginn des Experiments
- Letzte Quellenprüfung
KURZFASSUNG
Kerngedanken.
- Die Prüfung hat trotz erfolgreichem Build Probleme beim Datenschutz, bei der Barrierefreiheit und beim Zugang zu den Texten aufgedeckt.
- Bereitstellung, Rückmeldungen zur Vorschau und die Möglichkeit zum Merge beantworten jeweils eine andere Frage.
- Die Fallstudie dokumentiert sowohl abgeschlossene Prüfungen als auch Lücken im Vergleich zum Lebenszyklus-Testframework von OWASP.
01FALLSTUDIE
Umfang und Nachweise
Ich habe diese statische persönliche Website über meine Interessen, Experimente und Recherchen mit Codex, Vite und TypeScript erstellt. Sie hat kein Anwendungsbackend, keine Konten und keine Zahlungsfunktionen. Schriftarten und Medien werden zusammen mit der Website ausgeliefert.
Die erste lokale Umsetzung und die anfänglichen Prüfungen haben am 10. Oktober 2026 von 18:48 bis 19:08 CEST etwa zwanzig Minuten gedauert. Die Planung lag vor dieser Bearbeitungsrunde. Verfeinerung, zusätzliche Prüfung und Veröffentlichung folgten danach. Die Zeitangabe beschreibt eine dokumentierte Umsetzungsrunde. Sie ist weder ein Benchmark noch die gesamte Projektzeit.
Diese Darstellung beruht auf den Aufzeichnungen zur Projektausführung. Die Bezeichnungen der Prüfungen unterscheiden Anforderungen aus dem genehmigten Plan, vom Agenten gewählte Schritte, meine zusätzliche Prüfanfrage und konfigurierte Automatisierung. Sie beschreiben den tatsächlichen Arbeitsablauf dieses Projekts.
02FALLSTUDIE
Vom Plan zur öffentlichen Website
Das Experiment definieren
Ich habe die visuelle Referenz, die englischen Texte und die persönlichen Projekte genehmigt. Zu den Akzeptanzkriterien gehörten mobile Navigation, Tastaturzugang, reduzierte Bewegung, eine Alternative bei nicht verfügbarem Canvas und ein erfolgreicher Produktionsbuild.
Die erste lokale Version erstellen
Codex hat die Startseite, das Punktfeld, den Projektring und barrierefreie Dialoge erstellt. Außerdem hat es TypeScript- und Build-Prüfungen durchgeführt, die Website im Browser untersucht und Probleme der ersten lokalen Version korrigiert.
Inhalte und Oberflächen verfeinern
Weitere Bearbeitungsrunden ergänzten den persönlichen KI-Werdegang, Insights, Rechercheartikel, Gefährdungskataloge und Projektaufnahmen. Dabei wurden Navigation und Datenschutztexte verfeinert, die Sitzungsanzeige entfernt und Textüberlagerungen auf Mobilgeräten sowie Probleme bei der Anordnung von Grafiken korrigiert.
Eine zusätzliche Prüfung vor der Veröffentlichung anfordern
Vor der Veröffentlichung habe ich eine technische, redaktionelle und sicherheitsorientierte Prüfung angefordert. Separate KI-Prüfer haben mit rein lesendem Zugriff die Implementierung, Aussagen und öffentlichen Dateien untersucht. Zusätzlich wurden die Abhängigkeiten geprüft.
Befunde korrigieren und die Änderungen prüfen
Codex hat die Befunde korrigiert und die betroffenen Prüfungen wiederholt. In der Nachprüfung hat sich außerdem gezeigt, dass beim Start gerenderte Inhalte ersetzt wurden und dabei der Lesestand verloren ging. Das wurde vor der Veröffentlichung behoben.
Veröffentlichen und das Live-Ergebnis prüfen
Die Versionsverwaltung wurde mit Vercel verbunden und die Domain über Hostinger konfiguriert. Codex hat HTTPS, Weiterleitungen, die veröffentlichten Inhalte, Interaktionen und den Datenschutzhinweis geprüft. Bestehende E-Mail-Einträge blieben dabei erhalten.
Spätere Änderungen prüfen
Bei späteren Änderungen kamen Versionsverwaltung, Builds, gezielte Prüfungen und Untersuchungen der veröffentlichten Website zum Einsatz. Dazu gehörte der Ersatz des beispielhaften JSON-Panels durch Kataloge und Forschungsfragen.
03FALLSTUDIE
Was geprüft wurde
Die folgenden Ergebnisse betreffen die korrigierte Erstveröffentlichung und die Prüfung vom 11. Oktober 2026. Jede Prüfung beantwortet andere Fragen. Auch zusammen belegen sie keine vollständige Sicherheitsabdeckung.
TypeScript und Produktionsbuild
pnpm check führt tsc --noEmit aus. Bei pnpm build kommt vite build hinzu. Das erste Produktionsprotokoll von Vercel bestätigte, dass beide erfolgreich waren. Bei späteren Änderungen wurde git diff --check zur Prüfung auf Leerraumfehler eingesetzt. Diese Befehle prüfen Typen, Build-Ausgabe und Formatierung, aber keine Schwachstellen.
Browserverhalten und Barrierefreiheit
Die werkzeuggestützten Browserprüfungen umfassten Layouts mit 1440, 1024, 390 und 320 Pixeln Breite sowie geringe Fensterhöhen. Geprüft wurden Navigation, Routen, erneutes Laden, Fragmente, Ringsteuerung, Dialoge und die Rückkehr des Fokus. Auch Scrollen, reduzierte Bewegung, die Alternative zu Canvas, Konsolenfehler und Dateien wurden geprüft. Eine automatisierte Regressionssuite wurde nicht dauerhaft vorgehalten.
Codeprüfung und sicherheitsorientierte Prüfung
Ein separater KI-Prüfer hat Rendering, Mediengrenzen, Datenverarbeitung, das Aufräumen von Event-Handlern, Navigation, Dialoge und Bewegung untersucht. Einen früheren Git-Vergleichsstand hat er dabei nicht verwendet. Das war eine Quellcodeprüfung und weder SAST noch ein konfiguriertes GitHub-Codex-Review.
Schwachstellen in Abhängigkeiten (SCA)
pnpm audit --prod und pnpm audit meldeten am 11. Oktober 2026 keine bekannten Schwachstellen. Geprüft wurden die damals bekannten Sicherheitshinweise zu Abhängigkeiten. Die Anwendungslogik und unentdeckte Fehler wurden damit nicht geprüft.
Datenschutz und Grenzen öffentlicher Dateien
Die Prüfer haben Code und Build-Ausgabe nach Speicherung, Tracking, Netzwerkaufrufen, Zugangsdaten und internem Material durchsucht. Eine Aufnahme, die Entwicklungsdetails offenlegte, wurde ersetzt. Zugangsdaten, private Originaldokumente oder Source Maps wurden nicht gefunden. Die Implementierung enthielt weder Anwendungscookies noch dauerhafte Besucherkennungen, Analytics oder externe Schriftart- und Medienabhängigkeiten. Die Verarbeitung von Hosting-Anfragen wird im Datenschutzhinweis beschrieben.
Redaktionelle Aussagen und lesbares HTML
Die Prüfer haben die persönliche Einordnung, Referenzen und den Umfang der Artikel kontrolliert. Artikel und Katalogquellen wurden im gebauten HTML verfügbar gemacht. Skripte ergänzten die vorhandenen Inhalte um Interaktionen. Die Datenschutzhinweise wurden an die Hosting-Konstellation angepasst.
Live-Bereitstellung
Die Live-Prüfungen bestätigten HTTPS sowie die Weiterleitungen von HTTP zu HTTPS und von www zur Hauptdomain ohne www. Dabei wurden 57 Dateien der Erstveröffentlichung, darunter 16 HTML-Dokumente, mit dem lokalen Build verglichen. Außerdem wurden Medien, Dialoge und Bewegungssteuerungen bedient. Diese Zahlen stammen aus der Zeit vor späteren Artikeln wie diesem.
04FALLSTUDIE
Was ein grüner Prüfstatus bestätigt
Aktualisierung vom 14. Oktober 2026. Ein späterer Pull Request ordnete AI Insights und die zugehörige Navigation neu. Ich habe geprüft, was seine beiden grünen Vercel-Ergebnisse und die Konfliktmeldung von GitHub tatsächlich bedeuteten. Diese Wartungsergebnisse sind von den oben beschriebenen Prüfungen der Erstveröffentlichung zu unterscheiden.
GRAFISCH ERLÄUTERT
Was die einzelnen Prüfungen bestätigen
- Vercel-Deployment
- BESTÄTIGT
Die konfigurierte TypeScript-Prüfung und der Produktionsbuild wurden abgeschlossen. Die Vorschau wurde bereitgestellt.
- BESTÄTIGT NICHT
Dass jede Interaktion funktioniert oder Sicherheitstests stattgefunden haben.
- Kommentare zur Vorschau
- BESTÄTIGT
In dieser Vorschau waren keine offenen Rückmeldungen erfasst.
- BESTÄTIGT NICHT
Dass sie jemand geprüft hat. Die dokumentierte Vorschau enthielt keine Kommentare.
- Zusammenführbarkeit in Git
- BESTÄTIGT
Git kann die vorgeschlagenen Änderungen ohne Konflikt mit dem Basisbranch zusammenführen.
- BESTÄTIGT NICHT
Korrektes Verhalten nach der Integration oder einen bereits geplanten Merge.
Diese Prüfungen gehören zum datierten Wartungsbeispiel dieser Fallstudie. Sie belegen nicht nachträglich, dass weitere Tests ausgeführt wurden.
Vercel für Build und Bereitstellung
Die Bereitstellung wurde abgeschlossen. Das Protokoll bestätigte die konfigurierte TypeScript-Prüfung und den Vite-Build. Damit war eine Vorschau gebaut und bereitgestellt. Tests der Interaktionen oder der Sicherheit waren dadurch nicht belegt. [03]
Vercel Preview Comments als Rückmeldungsstatus
„No unresolved feedback“ bedeutete null offene und null erledigte Kommentare. Der Status beschrieb damit Rückmeldungen. Er war weder ein Codetest noch ein Nachweis dafür, dass jemand die Vorschau geprüft hatte. [04]
GitHubs Merge-Prüfung für das Zusammenführen der Änderungen
Git konnte die Änderungen ohne manuelle Konfliktauflösung zusammenführen. „Merging can be performed automatically“ beschrieb diese Möglichkeit. Daraus ließ sich weder ein geplanter automatischer Merge noch korrektes Verhalten nach der Integration ableiten. [05]
Lokale Codex-Prüfungen passend zur Änderung
Codex hat für diese Änderung Typ- und Build-Prüfungen, gezielte Browserprüfungen und ein separates KI-Review durchgeführt. Im Browser wurden Navigation, responsive Layouts, Fokus, Fragmente, reduzierte Bewegung und lesbares HTML ohne JavaScript geprüft. Diese Prüfungen entsprachen den Projektanweisungen.
Für diesen Pull Request wurden weder ein gesondertes Sicherheitsreview noch ein SAST-Scan oder eine neue Prüfung der Abhängigkeiten ausgeführt. Die oben genannten Sicherheitsprüfungen stammen vom 11. Oktober. Die GitHub-Codex-Reviewfunktionen müssen konfiguriert oder ausdrücklich angefordert werden. Sie sind vom Vercel-Status zu unterscheiden. [06]
05FALLSTUDIE
Sicherheit über den Softwareentwicklungslebenszyklus hinweg
Ein sicherer Softwareentwicklungslebenszyklus bindet Sicherheit in die Entwicklung ein. Wie seine Phasen heißen, hängt vom Modell ab. Das Secure Software Development Framework (SSDF) von NIST beschreibt Praktiken, die sich in verschiedene SDLC-Umsetzungen integrieren lassen. Eine bestimmte Phasenfolge schreibt es nicht vor. [02]
Der folgende Vergleich verwendet die fünf Phasen des Testframeworks aus OWASP WSTG v4.2. Die Originalformulierungen „Before“ und „During“ ordnen Sicherheitsaktivitäten im Lebenszyklus ein. Es handelt sich um die Phasen dieses anpassbaren Testframeworks und keine allgemeingültige Liste von SSDLC-Phasen. Die aufgeführten Aktivitäten und Lücken betreffen dieses persönliche Experiment. [01]
- WSTG / PHASE 1Vor Entwicklungsbeginn (Before Development Begins) (öffnet in einem neuen Tab)
Lebenszyklus, Leitlinien und messbare Kriterien festlegen.
Beobachtet. Der genehmigte Plan definierte Umfang, Akzeptanzkriterien und Datenschutzvorgaben.
Nicht abgedeckt. Es wurde weder ein formales organisatorisches Programm für sichere Entwicklung noch ein Programm für Sicherheitsmetriken eingerichtet.
- WSTG / PHASE 2Während Definition und Entwurf (During Definition and Design) (öffnet in einem neuen Tab)
Sicherheitsanforderungen und Architektur prüfen. Bedrohungen modellieren.
Beobachtet. Der Entwurf nutzte eine statische Website und lokale Dateien ohne Analytics oder Anwendungsbackend. Grenzen für öffentliche Inhalte und Medien wurden definiert.
Nicht abgedeckt. Es wurde weder eine dokumentierte Bedrohungsmodellierung noch eine formale Sicherheitsbewertung der Architektur durchgeführt.
- WSTG / PHASE 3Während der Entwicklung (During Development) (öffnet in einem neuen Tab)
Codeabläufe verstehen und den Code auf Sicherheitsfehler prüfen.
Beobachtet. Typ-, Build- und Browserprüfungen, getrennte KI-Reviews sowie Prüfungen der Abhängigkeiten wurden ausgeführt. Befunde wurden korrigiert.
Nicht abgedeckt. Es wurden weder ein SAST-Scanner noch eine Lint-Konfiguration oder eine dauerhaft vorgehaltene automatisierte Regressionssuite eingerichtet. Funktionale Browserprüfungen belegen keine Abdeckung durch Sicherheitstests.
- WSTG / PHASE 4Während der Bereitstellung (During Deployment) (öffnet in einem neuen Tab)
Die laufende Anwendung und ihre Bereitstellungskonfiguration testen, einschließlich Penetrationstests.
Beobachtet. HTTPS, Weiterleitungen, veröffentlichte Dateien, lesbares HTML, eingebundene Ressourcen und ausgewählte Live-Interaktionen wurden geprüft.
Nicht abgedeckt. Es wurde weder ein Penetrationstest noch ein DAST-Scan oder eine gesonderte Prüfung der Sicherheitsheader durchgeführt.
- WSTG / PHASE 5Während Wartung und Betrieb (During Maintenance and Operations) (öffnet in einem neuen Tab)
Betrieb prüfen, regelmäßige Zustandsprüfungen durchführen und Änderungen verifizieren.
Beobachtet. Spätere Änderungen nutzten Versionsverlauf, Build-Prüfungen, gezielte Reviews und Live-Verifikation.
Nicht abgedeckt. Bei der Erstveröffentlichung war weder eine fortlaufende Schwachstellenüberwachung noch ein geplanter Prozess regelmäßiger Sicherheitsprüfungen konfiguriert.
06FALLSTUDIE
Grenzen und meine Schlussfolgerungen
Bei der Erstveröffentlichung waren weder eine Lint-Konfiguration noch SAST, DAST, ein Penetrationstest, ein gesonderter Secret-Scanner oder eine dauerhaft vorgehaltene automatisierte Testsuite vorhanden. Automatisches GitHub Codex Code Review und ein gesondertes Codex Security Review waren nicht konfiguriert und wurden nicht ausgeführt. Die KI-gestützte Quellcodeprüfung ersetzte diese Methoden nicht.
Der WSTG-Vergleich dokumentiert Aktivitäten und Lücken. Er belegt weder Konformität noch einen vollständigen Prozess für sichere Entwicklung. Daraus nehme ich mit, erwartetes Verhalten früh festzulegen, ausgeführte Prüfungen zu dokumentieren und künftige Prüfungen an Änderungen von Funktionalität, Angriffsfläche und Datenverarbeitung auszurichten.
Der Abschluss einer Aufgabe, eine bestandene Prüfung und die Akzeptanz einer Veröffentlichung müssen jeweils gesondert beurteilt werden. Ich möchte die Nachweise dafür sichtbar halten.
QUELLEN / 06
Quellen.
Projektaufzeichnungen stützen die Darstellung von Umsetzung, Veröffentlichung und Wartung. Die privaten Protokolle werden nicht veröffentlicht. OWASP und NIST liefern den Kontext zum Lebenszyklus. Sie wurden am 17. Oktober 2026 geprüft. Die Plattformreferenzen erläutern Funktionen und behalten ihre jeweiligen Abrufdaten. Welche Prüfungen hier tatsächlich ausgeführt wurden, belegen sie nicht.
- OWASP — WSTG v4.2 / lifecycle testing framework (öffnet in einem neuen Tab)
Kapitel 3 mit Übersicht und Phasen 1–5. Originale Phasenbezeichnungen und Sicherheitsaktivitäten über den SDLC hinweg. Ein anpassbares Testframework.
- NIST — SP 800-218 / Secure Software Development Framework v1.1 (öffnet in einem neuen Tab)
Abstract zu übergeordneten Praktiken sicherer Entwicklung, die sich in unterschiedliche SDLC-Umsetzungen integrieren lassen. Keine vorgeschriebene Folge von Lebenszyklusphasen.
- Vercel — Deploying GitHub projects (öffnet in einem neuen Tab)
Vorschaubereitstellungen, GitHub-Integration und Bereitstellungsstatus.
- Vercel — Managing comments on preview deployments (öffnet in einem neuen Tab)
Erledigen von Rückmeldungen zur Vorschau. Die dokumentierte Prüfausgabe liefert die Kommentarzahlen.
- GitHub — Merge conflicts (öffnet in einem neuen Tab)
Automatisches Zusammenführen und Unterschiede, die manuelle Konfliktauflösung erfordern.
- OpenAI — Review GitHub pull requests with Codex (öffnet in einem neuen Tab)
Einrichtung von Code Review und Security Review, automatische Prüfung und ausdrückliche Prüfanfragen.