Redesign durch KI: Warum die JPKCom DB absichtlich nach KI aussieht

Wenn du die JPKCom DB schon eine Weile kennst, ist dir der Wechsel sofort aufgefallen: oben eine dunkle Leiste wie ein Terminal, Überschriften in einer Monospace-Schrift, grüne Pfeile vor jedem Listenpunkt, längere Code-Blöcke in Fenstern mit drei farbigen Punkten. Wenn du zum ersten Mal hier bist, denkst du vielleicht eher: Das sieht aus, als hätte eine Künstliche Intelligenz (KI) das gebaut.

Beides stimmt. Das hier ist ein Redesign durch KI: Die Idee, die Richtung und jede Freigabe kamen von mir, umgesetzt hat es Claude Code, von der Bestandsaufnahme über die Spezifikation bis zu Code, Tests und Reviews. Und dass die Seite heute so aussieht, wie KI-gestaltete Seiten eben aussehen, habe ich nicht übersehen. Es ist Absicht, aus drei Gründen: Ich will offen zeigen, womit ich arbeite, ich stehe klar zu KI, und die Seite soll ein Lehrbeispiel sein, an dem du KI-Design erkennen lernst.

In diesem Artikel zeige ich dir zuerst, wie das Redesign entstanden ist und wie die Arbeit geteilt war. Danach geht es um das Ergebnis: die Farben (Dracula im Dunkeln, eine eigene Ableitung im Hellen), die Barrierefreiheit mit Kontrasten, die ein Test nachrechnet, die Schriften und ihre Lesbarkeit, die Bedienbarkeit (Usability), das Verhalten vom 320-Pixel-Handy bis zum Breitbild und die Schicht für KI-Leser, die bewusst unverändert geblieben ist. Zum Schluss erfährst du, woran du KI-generierte Designs erkennst.

Zur Methodik: Die Zahlen zum Redesign stammen aus dem Repository dieser Seite, aus dem Build und aus den Protokollen der Arbeitssitzungen mit Claude Code. Die Kontrastwerte sind mit der Farbmathematik des Projekts nachgerechnet. Die Merkmale KI-generierter Designs belege ich mit Primärquellen, unter anderem mit dem, was Anthropic selbst dazu veröffentlicht hat. Wo ich selbst einordne, statt zu belegen, sage ich das dazu.

Die Ausgangslage: eine gute Grundlage, die nicht nach mir aussah

Die JPKCom DB ist nicht auf der grünen Wiese entstanden. Ihre erste Version stand auf einem Starter-Template für Eleventy, das mir viel Arbeit abgenommen hat: die Suche, die Code-Hervorhebung, die Markdown-Funktionen für KI, eine saubere Build-Kette. Das war eine gute Ausgangsbasis. Alles, was seitdem dazugekommen ist, baut darauf auf: die Zweisprachigkeit, der Blog und inzwischen über 400 Artikel je Sprache.

Optisch hatte ich die Seite aber nie wirklich zu meiner gemacht. Ich hatte sie mehrfach auf die Farbe meiner Corporate Identity (CI) umgefärbt, ein gedecktes Schieferblau. Trotzdem fühlte sie sich nicht wie meine Seite an. Das war der Anstoß für das Redesign.

Wie das Redesign technisch aufgebaut sein sollte, war schnell geklärt: Claude Code schlug eine Token-Schicht vor, in der jede Farbe an genau einer Stelle lebt, und ich habe sie gewählt. Wie nötig dieser Schritt war, zeigte erst die Bestandsaufnahme danach. Sechs Agenten haben jede Oberfläche der Seite kartiert, ein siebter hat ihre Ergebnisse stichprobenartig nachgeprüft und nach Lücken gesucht. Heraus kam:

519 fest verdrahtete Tailwind-Farbklassen, 216 davon als dark:-Variante, dazu 110 Klassen alter eigener Tokens. Sie steckten in 24 der 77 durchsuchten Dateien. Das waren drei parallele Grau-Systeme: eins für Hell, eins für Dunkel, eins im CSS.
Die Grundfarben, die in der Design-Dokumentation standen, kamen nie im Browser an. Eine Utility-Klasse am <body> hat die dokumentierte Regel überstimmt.
prefers-reduced-motion, die Rücksicht auf reduzierte Bewegung, stand in der Doku als umgesetzt. Im Code gab es dazu keine Zeile.

Ein Design-System, das auf dem Papier stand, aber nicht im Browser. Umfärben allein hätte daran nichts geändert. Jede Farbe musste an eine Stelle.

Redesign durch KI: So war die Arbeit geteilt

Ich habe die Richtung vorgegeben und jeden Schritt freigegeben. Gebaut hat das Redesign Claude Code, das KI-Werkzeug von Anthropic für die Kommandozeile, mit dem ich einen großen Teil meiner Arbeitswoche verbringe. Die Koordination übernahm Claude Opus in zwei Sitzungen, eine pro Tag, verbunden über eine schriftliche Übergabe im Repository. Die meisten Einzelaufgaben haben Sub-Agenten mit Claude Sonnet umgesetzt und geprüft, die Abschlussreviews liefen wieder mit Opus. Von der ersten Nachricht bis zum Merge vergingen zwei Tage.

So lief es ab:

Anstoß: Ich beschreibe das Problem und die Richtung.
Einschätzung: Claude Code legt drei Architektur-Ansätze mit Pro und Kontra vor. Ich wähle die Token-Schicht.
Bestandsaufnahme: die sieben Agenten von oben.
Spezifikation: Ein adversarischer Review mit vier Prüfperspektiven findet im ersten Entwurf 63 Schwachstellen, deren Korrekturen in die Spezifikation einfließen. Bis zum Ende wächst sie auf 35 Entscheidungen. Dazu kommen 16 Standardwerte, die ich am ersten Tag gesammelt bestätigt habe; drei davon sind später entfallen.
Vorschau: eine statische HTML-Datei. Ich ändere daran die Farbe des Logos, den Akzent im Light Mode und die Listenpunkte.
Umsetzung in Etappen: In der Regel schreibt nur ein Agent zur Zeit, und jede Aufgabe, die etwas im Repository ändert, bekommt einen eigenen Review.
Halt zur Sichtprüfung: Ich nehme Palette, Schriften und Überschriften ab und ändere Karten und Kategorie-Listen.
Abschlussreview: fünf Prüfperspektiven und zehn Prüf-Agenten, die jeden Befund zu widerlegen versuchten, 31 Befunde, davon fünf wichtige. Danach eine Welle mit Korrekturen und eine Nachprüfung.
Freigabe und Merge durch mich.

Wer macht was

 MENSCH                       KI (Claude Code)
 ──────────────────           ─────────────────────
 Idee, Richtung         ──►   Bestandsaufnahme
                              Spezifikation, Review
 Vorschau prüfen        ◄──   Vorschau
 Entscheiden, verwerfen ──►   Plan, Code, Tests
 Sichtprüfung           ◄──   Zwischenstand
 Fehler melden          ──►   Abschlussreview, Korrekturen
 Freigabe, Merge        ◄──   Ergebnis mit Messwerten

Am Ende standen 94 Commits und rund 630 ersetzte oder gelöschte Farbklassen. Die Zahl der automatischen Tests stieg von 170 auf 264, und die DESIGN.md des Projekts war neu geschrieben.

Wenn du selbst ein Redesign mit KI planst, übernimm diese Aufteilung: Die KI darf vorschlagen, messen, bauen und prüfen. Entscheiden und freigeben solltest du.

Warum die Seite absichtlich nach KI aussieht

Der Anstoß war, dass sich die Seite nicht nach mir anfühlte. Der neue Look trägt viele der Merkmale, an denen du heute KI-Gestaltungen erkennst. Ich hätte Claude Code bitten können, diese Spuren zu verwischen. Ich habe es bewusst nicht getan. Die Seite soll aussehen wie das, was sie ist: ein Projekt, das ich mit KI baue.

Offenheit. Auf der Seite zur KI-Transparenz lege ich offen, wo KI beim Erstellen, Korrigieren und Prüfen der Inhalte mitarbeitet. Das Design ist jetzt selbst ein Teil dieser Offenheit. Wenn du die Seite öffnest, siehst du sofort, womit hier gearbeitet wird, ohne eine Fußnote suchen zu müssen.

Ein klares Statement für KI. Ich arbeite viel mit KI und halte nichts davon, das zu verstecken. Ein Redesign in zwei Tagen, mit einem Kontrasttest für jedes wichtige Farbpaar und mehreren getrennten Review-Durchgängen, ist für mich ein starkes Argument für KI in der Webentwicklung.

Ein Lehrbeispiel. KI-gestaltete Seiten teilen erstaunlich viele Merkmale. Hast du sie einmal gesehen, erkennst du sie überall. Diese Seite zeigt sie dir im Original, und weiter unten erfährst du, warum sie entstehen.

Was die Seite nicht ist: rein KI-generiert. Für jede Zeile Inhalt und jede Designentscheidung stehe ich ein. KI ist hier ein Werkzeug, kein Autor mit letzter Verantwortung. So steht es auf der Transparenzseite, und das gilt für das Design genauso.

Die Leitidee: eine Wissensdatenbank im Look ihres Werkzeugs

Die JPKCom DB sieht jetzt aus wie der Ort, an dem ihre Inhalte benutzt werden: das Terminal.

Das ist mehr als Geschmack. Den größten Teil der Seite machen Cheat-Sheets zu 220 Kommandozeilen-Befehlen, die Dokumentation zu 40 Tools und Blog-Artikel mit viel Code aus. Im Build stecken gut 18.000 Code-Blöcke. Wer hier liest, will oft gleich danach etwas in eine Shell kopieren. Ein Design, das nach Editor und Terminal aussieht, sagt dir auf den ersten Blick: Das ist eine technische Referenz, vieles darin ist zum Kopieren gedacht.

Drei Grundsätze tragen das ganze System:

Mono für Struktur, Sans zum Lesen. Überschriften, Beschriftungen und Bedienelemente stehen in einer Monospace-Schrift, der Fließtext in einer ruhigen serifenlosen Schrift.
Code und Kopfzeile sind immer dunkel, im Dark Mode wie im Light Mode. Sie sind das Terminal der Seite.
Jede Farbe lebt an genau einer Stelle. Kein Element bekommt seine Farbe doppelt, und keine Komponente kennt ihren hellen und dunklen Wert selbst.

Auf dem Desktop ergibt das diesen Seitenaufbau:

Seitenaufbau ab 1280 px

┌──────────────────────────────────────────────────────────────────┐
│ KOPFZEILE  dunkel in beiden Modi, bleibt oben stehen, 56 px hoch │
│ JPKCom DB   [ Schnellsuche…  Ctrl+K ]   EN  RSS   [ > jpkc.com ] │
├─────────────┬───────────────────────────────────┬────────────────┤
│ SIDEBAR     │ INHALT  Textspalte max. 896 px    │ AUF DIESER     │
│ 256 px      │ Brotkrumen                        │ SEITE  224 px  │
│             │ H1, Beschreibung, Tags            │                │
│ Bereiche    │ Fließtext in Instrument Sans      │ aktiver Punkt: │
│ Kategorien  │ ┌───────────────────────────────┐ │ fett + Balken  │
│ Rechtliches │ │ Code im dunklen Fenster       │ │                │
│             │ └───────────────────────────────┘ │                │
│             │ [ ← Zurück ]        [ Weiter → ]  │                │
├─────────────┴───────────────────────────────────┴────────────────┤
│ FOOTER  volle Breite: Marke │ Profil │ Profil │ Profil           │
└──────────────────────────────────────────────────────────────────┘

Dracula im Dunkeln, eine eigene Ableitung im Hellen

Die dunkle Palette ist Dracula (öffnet in neuem Tab) (englisch), das Farbschema, das Zeno Rocha 2013 für Code-Editoren und Terminals entworfen hat. Nach eigener Angabe gibt es Dracula inzwischen für über 400 Programme. Der Hintergrund ist #282a36, der Text #f8f8f2, dazu die typischen Leuchtfarben: Lila, Pink, Cyan, Grün, Orange und Gelb.

Blind übernommen ist die Palette nicht. Für die Seite habe ich zwei Grenzen aus den Web Content Accessibility Guidelines (WCAG) gesetzt: 4,5:1 für Nebentext und die Fehlerfarbe auf der Seite, 7:1 für jede Syntaxfarbe im Code. Daran gemessen reichte der Kontrast an vier Stellen nicht:

Farbe	Dracula	JPKCom DB	Kontrast vorher → nachher
Nebentext	`#6272a4`	`#8e9abe`	3,03 → 5,10:1 auf dem Seitenhintergrund
Rot für Fehler	`#ff5555`	`#ff6969`	4,04 → 4,52:1 auf dem Hintergrund-Raster
Kommentare im Code	`#6272a4`	`#9ba5c5`	3,68 → 7,09:1 auf der Code-Fläche
Rot im Code	`#ff5555`	`#ff7e7e`	5,52 → 7,05:1 auf der Code-Fläche

Außerdem ist die Kursive aus dem Syntax-Theme entfernt. Martian Mono, die Code-Schrift, hat keine echte Kursive, und künstlich schräg gestellte Buchstaben sollten im Code nicht auftauchen.

Für den Light Mode hat Dracula inzwischen ein offizielles helles Gegenstück, Alucard (öffnet in neuem Tab) (englisch). Ich nutze es nicht. Die helle Palette der DB ist eine eigene Ableitung mit denselben Rollen wie im Dunkeln, also denselben Farben für Links, Akzente, Erfolg, Warnung und Fehler, jede gegen den hellen Hintergrund auf ihre Kontrastgrenze geprüft.

Eine Farbe habe ich bewusst nicht aus Dracula genommen: den Akzent im Light Mode. Statt Lila steht dort #2f5468, das Schieferblau, das schon vor dem Redesign der Akzent der Seite war. Das ist ein Stück Kontinuität, und es ist auch die bessere Farbe: Heller Text auf dem Akzent erreicht 7,78:1.

Technisch steckt hinter beiden Paletten eine Token-Schicht. Beide stehen in einer Datei, _tokens.css, mit denselben Namen. Tailwind liest die Variablen über @theme inline und macht daraus Klassen wie bg-page oder text-fg:

Farbe an genau einer Stelle

/* _tokens.css: beide Paletten, dieselben Namen */
:root { --page: #f5f5f7; --fg: #1a1a16; }
.dark { --page: #282a36; --fg: #f8f8f2; }

/* main.css: Tailwind macht daraus Klassen */
@theme inline {
  --color-page: var(--page);
  --color-fg: var(--fg);
}

Im Markup steht dann nur noch bg-page, kein Paar aus hellem und dunklem Wert und kein dark: mehr. Ein Wächter-Skript meldet jede Tailwind-Palettenklasse, jeden ausgemusterten Token der alten Palette und jede dark:-Variante in Templates, CSS und JavaScript. Aus rund 630 solcher Stellen vor dem Umbau sind 0 geworden. Im Artikel über DESIGN.md hatte ich noch den @theme-Block von Tailwind als Quelle der Wahrheit beschrieben. Seit dem Redesign ist es für Farben _tokens.css, und die neue DESIGN.md führt für Hell und Dunkel dieselbe Token-Menge, Wert für Wert wie in _tokens.css.

Code und Kopfzeile schalten nie um. Sie nutzen feste Konstanten statt umschaltender Tokens, und neben der Optik gibt es dafür einen handfesten Grund: Ein umschaltender Token läge im Light Mode auf dunklem Hintergrund schnell unter der Grenze. Die Linkfarbe des Light Mode käme auf der Code-Fläche nur auf 2,14:1 statt der nötigen 4,5:1, und selbst das dunklere Pink, das im Light Mode den Fokus zeigt, hielte dort mit 3,32:1 die 3:1 für einen Fokusrahmen nur knapp. Deshalb nutzt alles im Code ausschließlich --code-*-Konstanten und alles in der Kopfzeile --head-*.

Welche Palette du siehst, entscheidet zuerst dein Betriebssystem. Im Footer kannst du das überstimmen: Die drei Symbole dort stehen für Systemvorgabe (Bildschirm), Hell (Sonne) und Dunkel (Mond). Wichtig ist das, weil die Nielsen Norman Group (öffnet in neuem Tab) (englisch) in ihrer Auswertung der Forschung zu dem Ergebnis kommt, dass Menschen mit normalem Sehvermögen im Light Mode meist besser lesen. Sie rät davon ab, Dark Mode für ein allgemeines Publikum als Standard zu setzen, und empfiehlt, ihn als Option anzubieten. Ein Terminal-Look, der nur dunkel funktioniert, kam deshalb nicht infrage.

Barrierefreiheit: Kontraste, die ein Test nachrechnet

Die wichtigste Entscheidung für die Barrierefreiheit war keine Farbe, sondern ein Test. Die Datei theme-tokens.test.mjs liest beide Paletten aus der Token-Datei und rechnet jedes Farbpaar nach, auf das sich das Design verlässt: Text auf seinen Flächen, Fokusrahmen, Scrollleisten, Listenmarker. Die Syntaxfarben im Code prüft ein zweiter Test, shiki-theme.test.mjs. Liegt ein Paar unter seiner Grenze, wird der Testlauf rot, bevor du die Farbe je im Browser siehst.

Die Grenzen im Einzelnen: 4,5:1 für normalen Text auf Stufe AA, 7:1 auf der strengeren Stufe AAA, 3:1 für Bedienelemente und grafische Hinweise.

Was	Grenze	Gemessen hell / dunkel
Fließtext	7:1 (AAA)	13,08 / 10,25
Überschriften	7:1 (AAA)	16,03 / 13,36
Links	4,5:1 (AA)	7,43 / 10,29
Nebentext	4,5:1 (AA)	4,92 / 5,10
Ziffern nummerierter Listen	4,5:1 (AA)	alle darüber
Jede Syntaxfarbe im Code	7:1 (AAA)	knappster Wert 7,05
Fokusrahmen, Scrollleisten, Listenpfeile	3:1	alle darüber

Der zweite Test prüft außerdem, dass das Original-Dracula an der 7:1-Grenze scheitert. Das ist eine Erinnerung zum Aufräumen: Erreicht Dracula in einer neuen Version die 7:1 von selbst, hätte die Anhebung nichts mehr zu tun, und genau dann wird dieser Test rot.

Genauso nachgerechnet ist die Kopfzeile. Im Dark Mode ist sie zu 90 Prozent deckend und zeichnet den Inhalt darunter weich. Der Test nimmt den ungünstigsten Fall an, die Leiste über einer weißen Fläche. Bei 85 Prozent Deckkraft fiele der Link-Text dort auf 4,48:1, deshalb sind es 90.

Farbe ist nie das einzige Signal. Links im Text erkennst du immer an der Unterstreichung. Der aktive Eintrag im Inhaltsverzeichnis ist zusätzlich fett, hat einen 2 Pixel breiten Balken und aria-current, denn zwischen Akzent und normalem Eintrag liegt nur ein Kontrast von 1,51:1 (hell) bzw. 1,16:1 (dunkel). Treffer in der Suche sind gelb markiert und fett: Das Dracula-Gelb hat im Light Mode im weißen Suchfenster nur einen Kontrast von 1,12:1 zum Hintergrund, auf einem ausgewählten Treffer sogar nur 1,08:1.

Der Fokus ist immer sichtbar und nie verdeckt. Gehst du mit der Tab-Taste durch die Seite, siehst du an jedem Element einen 2 Pixel breiten Rahmen in Pink, in der Kopfzeile und im Code mit einer eigenen, festen Farbe. Es ist ein echter outline, kein Schatten-Ring, deshalb übersteht er auch den Kontrastmodus von Windows. Damit der Fokus nie unter der Kopfzeile verschwindet, gibt es genau einen Abstand für alle Sprungziele: scroll-padding-top in Höhe der Kopfzeile plus 1,5 rem. Das gilt für Anker, Fußnoten, den Sprunglink und jedes Element, das du mit der Tab-Taste ansteuerst. Auf schmalen Bildschirmen kommt ein Abstand nach unten für die feste Leiste am unteren Rand dazu.

Listen mit grünen Pfeilen bleiben Listen. Das Zeichen ❯ ist ein echter Listenmarker über list-style-type, kein nachgebautes Pseudo-Element:

ul { list-style-type: "❯  "; }
ul > li::marker { color: var(--prompt); }

Für Screenreader ist das die einfachste sichere Lösung. Eine Liste ganz ohne sichtbare Marker, also mit list-style: none und ohne Ersatz, behandelt Safari für den Screenreader VoiceOver nicht mehr als Liste. Ein Pseudo-Element mit Inhalt würde die Rolle zwar auch retten, der echte Listenmarker braucht aber keinen Umweg. Die Liste bleibt für Screenreader eine Liste, samt Zahl der Einträge.

Dazu kommen die Dinge, die du erst bemerkst, wenn du sie brauchst:

Reduzierte Bewegung: Stellst du sie im System ein, bekommst du keine Animationen, keine Übergänge und kein weiches Scrollen.
Kontrastmodus: Fokus, aktive Navigation und ausgewählte Suchtreffer nutzen dort die Systemfarben, das Hintergrund-Raster verschwindet.
Druck: Druckst du eine Seite im Dark Mode, kommt sie hell aufs Papier, statt hellen Text auf weißes Papier zu bringen. Code bleibt dunkel, Kopfzeile, Navigation und Footer fallen weg.
Theme-Schalter: Die drei Optionen sind eine Radiogruppe mit aria-checked, und die Auswahl ist eine Fläche statt einer Farbnuance.

Zur Ehrlichkeit gehört auch: Der Nebentext hat im Dark Mode meist weniger Reserve als vorher. Damals gab es dafür mehrere Grautöne. Beschreibungen, Meta-Zeilen und die Artikel-Links in der Sidebar kamen auf 6,94:1, Inhaltsverzeichnis und Suche auf 8,60:1, die Beschriftungen „Zurück" und „Weiter" unter dem Artikel und die rechtlichen Links in der Sidebar aber nur auf 3,78:1, also unter AA. Heute nutzt der Nebentext ein einziges Dracula-Blaugrau mit 5,10:1: sicher über AA, aber näher an der Grenze. Claude Code hat diesen Rückschritt im ersten Entwurf von sich aus angesprochen, ohne dass ich danach gefragt hätte.

Die WCAG-Kriterien hinter diesen Punkten: 1.4.1 Benutzung von Farbe (öffnet in neuem Tab), 1.4.3 Kontrast (Minimum) (öffnet in neuem Tab), 1.4.6 Kontrast (erhöht) (öffnet in neuem Tab), 1.4.11 Nicht-Text-Kontrast (öffnet in neuem Tab), 2.4.7 Fokus sichtbar (öffnet in neuem Tab) und 2.4.11 Fokus nicht verdeckt (Minimum) (öffnet in neuem Tab) (alle englisch). Warum die Landmarks der Seite so aufgebaut sind, wie sie sind, steht in HTML-Landmarks in der Praxis.

Lesbarkeit: Mono für Struktur, Sans zum Lesen

Monospace-Schriften sind das auffälligste Merkmal des neuen Looks und zugleich die größte Gefahr für die Lesbarkeit. Ein langer Artikel ganz in Monospace sieht nach Terminal aus, liest sich für mich aber wie ein Logfile: Jeder Buchstabe ist gleich breit, das „i" so breit wie das „m", und der Rhythmus der Wörter geht verloren. Deshalb ist die Arbeitsteilung strikt.

Martian Mono (öffnet in neuem Tab) (englisch) von Evil Martians setzt Überschriften, Navigation, Beschriftungen, Knöpfe und Code. Die Schrift ist variabel in Breite und Stärke und hat eine hohe x-Höhe, also große Kleinbuchstaben. Im Code ist sie auf 87,5 Prozent Breite gestaucht, schmaler als in den Überschriften: Ein Zeichen ist dort 0,65 em breit statt 0,70 em. Das liegt näher an den rund 0,6 em üblicher Code-Schriften, und in eine Zeile passen etwa 8 Prozent mehr Zeichen.
Instrument Sans (öffnet in neuem Tab) (englisch) setzt den Fließtext, mit einer echten Kursive statt künstlich schräg gestellter Buchstaben. Auch die Artikeltitel in der Sidebar und in den Vor- und Zurück-Links unter dem Artikel sowie die Einträge im Inhaltsverzeichnis bleiben in Sans. Die willst du lesen, nicht überfliegen.

Der Fließtext hat einen Zeilenabstand von 1,625, die Textspalte ist höchstens 896 Pixel breit.

Die neuen Schriften haben einen Preis. Jede Seite lädt jetzt zwei Schriftdateien mit zusammen rund 96 KB vor, gut zweieinhalbmal so viel wie vorher: Die alte Schrift kam auf jeder Seite mit einer Datei von rund 38 KB aus. Die Kursive, erweiterte Zeichensätze und die Diagramm-Schrift lädt der Browser nur, wenn eine Seite sie braucht. Bei der Kursiven war das auch früher schon so. Alle Schriften liegen selbst gehostet im Repository, ohne Aufruf bei Google Fonts. Warum das mehr als eine Stilfrage ist, steht in meinem Artikel zum Urteil des Bundesgerichtshofs (BGH) über Datenweitergaben.

Und dann gibt es eine dritte Schrift, die du nur in Diagrammen siehst, auch in denen dieses Artikels. Nach dem Schriftwechsel fiel mir auf, dass die Text-Diagramme in älteren Artikeln verrutscht waren. Die Ursache: Martian Mono enthält keine Rahmen- und Blockzeichen. Der Browser holte ┌, ─ und │ aus einer Ersatzschrift mit anderer Zeichenbreite, und die Rahmen liefen um bis zu 46 Pixel pro Zeile auseinander. Die Lösung ist ein 24 KB kleines Subset von JetBrains Mono (öffnet in neuem Tab), das nur Code-Blöcke mit solchen Zeichen bekommt. Eine getestete Funktion erkennt sie beim Build. Gemessen ergab das 0 Pixel Spaltenabweichung in allen 28 Diagramm-Blöcken, die es damals gab. Ein Detail hat dabei noch einmal alles verschoben: Das Subset muss auch das Leerzeichen enthalten. Sonst kommt es aus der Ersatzschrift, ist einen Bruchteil breiter, und die Spalten wandern wieder.

Usability: schnell finden, schnell kopieren

Eine Wissensdatenbank ist nur so gut wie der Weg zur richtigen Seite. Deshalb setzt die Bedienung auf wenige feste Wege, die überall gleich funktionieren.

Der wichtigste ist älter als das Redesign: Hub-and-Spoke statt Navigationsbaum, also Nabe und Speichen. Eine Sidebar, die alle Artikel zeigt, bricht bei über 400 Artikeln je Sprache zusammen, und das Ziel sind deutlich mehr. Deshalb klappt die Sidebar unter den sechs Hauptbereichen nur den Bereich auf, in dem du gerade bist: bei Cheat-Sheets und Tools seine Kategorien und die Artikel der aktiven Kategorie, bei Guides und Changelog die Artikel selbst. Der Blog wächst ohne Grenze und bekommt gar keine Liste; hier führen dich Übersicht, Vor- und Zurück-Links, Suche und Tags weiter. Darunter folgen die drei rechtlichen Links. Auf dem Cheat-Sheet zu tar sind das 29 Links statt aller 220 Cheat-Sheets.

Hub-and-Spoke

              ┌──────────────┐
              │  Startseite  │
              └──────┬───────┘
     ┌───────────┬───┴───────┬───────────┐
     ▼           ▼           ▼           ▼
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Cheat-  │ │  Tools  │ │  Blog   │ │ Guides, │
│ Sheets  │ │         │ │         │ │Changelog│
└────┬────┘ └────┬────┘ └─────────┘ └─────────┘
     ▼           ▼
15 Kategorien  40 Tools
     ▼           ▼
220 Befehle    120 Seiten

Quer dazu: Suche, Tags, Links im Text

Dazu kommen die kleinen Wege, die dir Klicks sparen:

Suche von überall: Das Suchfeld in der Kopfzeile öffnest du auch mit Ctrl+K (auf dem Mac ⌘K) oder mit der Taste /. Die Treffer wählst du mit den Pfeiltasten, Enter öffnet, Escape schließt.
Tags als Abkürzung: Ein Klick auf einen Tag unter dem Titel öffnet die Suche, gefiltert auf dieses Thema.
Kopieren ohne Zielen: In Terminal-Fenstern hat der Kopier-Knopf einen festen Platz in der Leiste, bei den übrigen Code-Blöcken sitzt er oben rechts im Block. Mit der Maus erscheint er, sobald du über den Code fährst, mit der Tastatur spätestens dann, wenn er selbst den Fokus bekommt. Auf dem Handy ist er immer sichtbar.
Orientierung: Brotkrumen über dem Titel, der aktive Abschnitt im Inhaltsverzeichnis und Vor- und Zurück-Links am Ende jedes Artikels zeigen dir, wo du bist.
Escape schließt, was offen ist: Seitenmenü, Inhaltsverzeichnis und Suche gehen mit Escape zu, und der Fokus springt dorthin zurück, wo du vorher warst; beim Seitenmenü und beim Inhaltsverzeichnis auf den Knopf, mit dem du sie geöffnet hast.

Responsive: vom 320-Pixel-Handy bis zum Breitbild

Auf dem Handy musst du ab 320 CSS-Pixeln Breite nicht seitlich scrollen. Mit jeder Breitenstufe ordnet sich die Seite neu an, statt nur breiter zu werden.

Breite	Was sich ändert
unter 360 px	Die Kopfzeile rückt enger zusammen, alle Elemente bleiben sichtbar.
unter 640 px	16 px Seitenrand, der RSS-Link ist ausgeblendet, Übersichtskarten sind einspaltig.
unter 1024 px	Menü-Knopf und ausklappbares Seitenmenü statt Sidebar; unten eine feste Leiste mit Start, Suche, Inhalt (auf Seiten mit Inhaltsverzeichnis) und „Nach oben".
ab 1024 px	Die Sidebar steht links (256 px), das Suchfeld in der Kopfzeile. Die untere Leiste verschwindet und mit ihr bis 1279 px auch das Inhaltsverzeichnis.
ab 1280 px	Das Inhaltsverzeichnis erscheint als rechte Spalte (224 px).
ab 1536 px	Auch neben Sidebar und Inhaltsverzeichnis erreicht die Textspalte ihre Maximalbreite von 896 px; das gesamte Layout endet bei 1680 px.

Auf dem Handy sieht dieselbe Seite so aus:

Seitenaufbau auf dem Handy

┌─────────────────────────────────┐
│ Ξ  JPKCom DB    EN [> jpkc.com] │
├─────────────────────────────────┤
│ Brotkrumen                      │
│ H1, 24 px, bricht notfalls um   │
│ Fließtext, 16 px Seitenrand     │
│ ┌─────────────────────────────┐ │
│ │ Code scrollt in sich  →     │ │
│ └─────────────────────────────┘ │
│ [ ← Zurück                    ] │
│ [                    Weiter → ] │
├─────────────────────────────────┤
│ Footer: Marke, Profil-Spalten   │
├─────────────────────────────────┤
│ Start  Suche  Inhalt  Nach oben │
└─────────────────────────────────┘

Dass nichts seitlich überläuft, liegt an mehreren kleinen Regeln, die zusammenspielen:

Überschriften der beiden obersten Ebenen skalieren per clamp() (die H1 von 24 auf 30 Pixel, die H2 von 22 auf 26). Alle Überschriften dürfen notfalls mitten im Wort umbrechen und werden, wo der Browser ein Wörterbuch hat, getrennt.
Code-Blöcke scrollen in ihrem eigenen Kasten und sind per Tastatur erreichbar, damit du auch ohne Maus seitlich scrollen kannst.
Tabellen stapeln sich unter 640 Pixeln zu Zeilen aus Beschriftung und Wert. Darüber scrollen zu breite Tabellen in ihrem eigenen, fokussierbaren Kasten.
Titel in Terminal-Fenstern kürzen sich mit „…", statt die Leiste zu sprengen.
Nummerierte Listen ab zehn Einträgen bekommen mehr Einzug, damit die zweistellige Ziffer nicht aus dem Bild ragt.

Die spannendste Geschichte des Redesigns spielt bei 320 Pixeln. Claude Code hat die Seite mitten im Umbau, gleich nach Kopfzeile, Seitenrahmen und Footer, in einer Messmatrix geprüft: 8 Seiten, 5 Breiten, 2 Farbmodi. Alle 80 Kombinationen kamen ohne Befund zurück. Trotzdem ragte die Kopfzeile schon zu diesem Zeitpunkt bei 320 Pixeln 36 Pixel über den Rand. Die Messung lief bei schmalen Breiten im Mobilgeräte-Modus von Chromium, und in diesem Modus weitet der Browser den Layout-Viewport auf die Breite des Inhalts aus. Die Seite war zu breit, und der gemessene Viewport wuchs einfach mit. Gefunden hat den Fehler erst die Nachprüfung nach dem Abschlussreview, ebenfalls von der KI. Die Lösung ist eine schmale Stufe unter 360 Pixeln, die nur die Abstände verkleinert. Die Navigation endet jetzt bei 308 statt 356 Pixeln, und jedes Bedienelement bleibt mindestens 24 × 24 Pixel groß, wie es WCAG 2.5.8 (öffnet in neuem Tab) (englisch) verlangt.

Einen zweiten Fehler habe ich selbst gefunden, als ich mir die Seite in Handybreite angesehen habe: In nummerierten Listen mit zehn oder mehr Einträgen war die „10." bei 375 Pixeln links abgeschnitten. Die Ziffern stehen seit dem Redesign in Martian Mono und sind breiter als vorher, und die Nummer vor dem Eintrag, der Listenmarker, rutschte vier Pixel aus dem Bild. Keine der Messungen hatte das bemerkt.

Eine kleine Lücke bleibt: In einem Desktop-Fenster, das nur etwa 360 bis 365 Pixel breit ist und eine klassische Scrollleiste zeigt, ragt die Kopfzeile um bis zu 6 Pixel über den Rand. Die Media-Query zählt die Scrollleiste mit, deshalb greift die schmale Stufe dort nicht. Handys blenden ihre Scrollleiste über dem Inhalt ein und sind nicht betroffen.

Meine Lehre daraus: Eine grüne Messmatrix beweist nur, dass die Messung nichts gefunden hat. Den eigenen Blick auf die Seite ersetzt sie nicht. Wenn du responsiv testest, schau dir am Ende die wichtigsten Seiten in der kleinsten Breite mit eigenen Augen an. Welche Maße für Kopfzeilen und Breitenstufen sich mit Daten begründen lassen, habe ich ausführlich in Header-Größen: Wie groß darf der Kopf einer Website sein? aufgeschrieben.

Für Maschinen hat sich nichts geändert, und das ist Absicht

Das Redesign hat die Markdown-Schicht nicht angefasst: KI-Leser bekommen weiterhin sauberen Text statt Dracula.

Die JPKCom DB ist von Anfang an auch ein KI-Experiment. Jede Seite gibt es zusätzlich als rohes Markdown: /db/blog/design-md/ hat seinen Spiegel unter /db/blog/design-md.md, jede Artikelseite hat ein Menü zum Kopieren als Markdown, und llms.txt listet die Inhalte für Sprachmodelle. Fragt ein Programm mit Accept: text/markdown nach, bekommt es direkt das Markdown statt des HTML. Probier es selbst aus:

curl -H "Accept: text/markdown" https://www.jpkc.com/db/blog/design-md/

Die Terminal-Fenster entstehen erst beim Rendern ins HTML, die Markdown-Spiegel bekommen davon nichts ab. Die Leiste mit den drei Punkten ist zusätzlich aus dem Suchindex ausgenommen. Sonst stünden ihre Beschriftungen wie „Terminal" oder der Name der Sprache als Seiteninhalt im Index, und jede Seite mit einem längeren Shell-Block wäre ein Treffer, sobald du nach „Terminal" suchst.

Auch der Code ist auf KI ausgelegt. Das HTML ist mit Landmarks sauber gegliedert, jede Artikelseite trägt strukturierte Daten als JSON-LD, und die DESIGN.md beschreibt das Design-System Wert für Wert als Datei, die ein KI-Agent vor jeder Änderung lesen kann. Der Kontrasttest und das Wächter-Skript schlagen an, sobald ein Agent eine Farbe wieder fest verdrahtet oder unter ihre Grenze drückt. Wie ich Inhalte für KI-Leser schreibe, steht in Schreiben für KI.

Lehrbeispiel: Woran du KI-generierte Designs erkennst

Warum KI-Designs sich ähneln

Anthropic erklärt das Phänomen selbst, im Beitrag „Improving frontend design through Skills" (öffnet in neuem Tab) (englisch). Lässt du ein Sprachmodell ohne Vorgaben eine Landingpage bauen, greift es fast immer zur Schrift Inter, zu lila Verläufen auf weißem Hintergrund und zu minimalen Animationen. Die Ursache nennt Anthropic distributional convergence: Modelle sagen jedes nächste Stück Text aus den statistischen Mustern ihrer Trainingsdaten voraus. In diesen Daten dominieren sichere Designentscheidungen, also solche, die überall funktionieren und niemanden stören. Ohne Richtung greift das Modell in die Mitte dieser Verteilung.

Wie konkret diese Mitte ist, zeigt ein Beitrag von Adam Wathan, dem Erfinder von Tailwind CSS. Er entschuldigte sich öffentlich (öffnet in neuem Tab) (englisch) dafür, dass er vor Jahren jeden Button in Tailwind UI mit bg-indigo-500 gestaltet hatte, mit der Folge, dass jede KI-generierte Oberfläche auf der Welt ebenfalls Indigo sei. Das war ein Scherz, aber ein treffender.

Anthropic hat aus diesen Erfahrungen einen Skill für Claude Code (öffnet in neuem Tab) (englisch) gemacht, also eine Anleitung, die Claude Code bei Gestaltungsaufgaben heranzieht. Sie soll solche Muster vermeiden und listet sie deshalb auf. In der Fassung, die ich hier übersetze (öffnet in neuem Tab) (englisch), nennt sie fünf Gruppen, um die KI-Designs derzeit kreisen:

ein warmer Cremegrund mit einer kontrastreichen Serifenschrift für die Überschriften und einem Akzent in Terrakotta oder einem warmen Lehmton, oft nah an #D97757, der Farbe, die Anthropic selbst in Claude verwendet;
ein fast schwarzer Hintergrund mit einem einzigen knalligen Akzent in Säuregrün oder Zinnoberrot;
ein Zeitungs-Layout mit Haarlinien, ohne abgerundete Ecken, mit dichten Spalten;
das Karten-Kit typischer Software-as-a-Service-Seiten (SaaS): Inhalt in identische, abgerundete Karten zerlegt, überall derselbe Radius, egal wie wichtig ein Element ist, unter jeder Karte derselbe weiche graue Schatten, Verläufe als Dekoration;
Vorlagen-Beiwerk, egal worum es geht: gesperrte Versal-Labels, also kleine Beschriftungen in weit gesetzten Großbuchstaben, über jeder Überschrift, Meta-Angaben mit Mittelpunkten („A · B · C"), Beschriftungen nach dem Muster „WORT — Fragment", getöntes Fast-Schwarz statt Schwarz, eine Monospace-Schrift für kleine Daten-Labels und ein „→" hinter Link- und Button-Texten.

Die erste Fassung des Skills war noch direkter. Sie warnte vor überstrapazierten Schriften wie Inter, Roboto und Arial, vor lila Verläufen auf Weiß und vor der Neigung, sich immer wieder auf die Schrift Space Grotesk einzupendeln.

Wie verbreitet diese Muster sind, hat Adrian Krebs gemessen. Er hat die Startseiten von 1.590 Projekten aus „Show HN" (öffnet in neuem Tab) (englisch), der Projektvorstellung auf Hacker News, automatisch auf Muster geprüft, die ihm befreundete Designer als typisch für KI genannt hatten: Schriften wie Inter, Space Grotesk, Instrument Serif und Geist, das „VibeCode-Lila", dauerhafter Dark Mode mit mittelgrauem Fließtext, große farbige Leuchteffekte, Milchglas-Effekte, identische Feature-Karten und einiges mehr. Weil ein einzelnes Muster eine Seite für ihn noch nicht zur KI-Seite macht, hat er gezählt, wie viele davon eine Seite zeigt. In der höchsten Stufe mit vier oder mehr Mustern landeten 22 Prozent der Seiten, in der mittleren weitere 32 Prozent. Ob eine Seite tatsächlich mit KI gebaut wurde, misst das nicht, und die Fehltreffer seiner Prüfung schätzt Krebs selbst auf 5 bis 10 Prozent.

Die Merkmale auf dieser Seite

Jetzt die Probe aufs Exempel. Diese Merkmale trägt die JPKCom DB, und jedes hat einen guten Grund. Die meisten stammen aus den Listen oben. Vier ordne ich selbst als KI-typisch ein, ohne dass eine der Quellen sie so nennt: die Instrument Sans als Schwester der Instrument Serif aus Krebs' Liste, die Fenster mit drei Punkten, das Raster mit weicher Maske und die Suche per Tastenkürzel.

Merkmal	Hier zu sehen	Der gute Grund dahinter
Dunkler Hintergrund mit leuchtenden Akzenten	Dracula im Dark Mode: `#282a36` mit Grün, Pink, Lila	vertraut aus Editor und Terminal
Getöntes Fast-Schwarz	Code-Fläche und Kopfzeile in `#191a21`	hoher Kontrast ohne reines Schwarz, passend zur Dracula-Palette
Monospace für Beschriftungen	Martian Mono in Überschriften, Byline, Tags und Knöpfen	trennt Bedienung von Inhalt; Ziffern stehen spaltengenau untereinander
Schrift aus der Instrument-Familie	Instrument Sans im Fließtext, von denselben Gestaltern wie die Instrument Serif	ruhige Grotesk mit echter Kursive
Versal-Label	„AUF DIESER SEITE" über dem Inhaltsverzeichnis	kurzes Label, schnell erfasst
Meta-Zeile mit Mittelpunkt	„von Jean Pierre Kolb · Datum" unter dem Titel	Autor und Datum in einer Zeile
Fenster mit drei Punkten	Terminal-Fenster um längere Code-Blöcke	Sprache und Kopier-Knopf stehen immer an derselben Stelle
Raster mit weicher Maske	oben auf jeder Seite	Struktur, ohne mit dem Text zu konkurrieren; der Kontrast darauf ist getestet
Milchglas-Kopfzeile	Dark Mode: 90 Prozent Deckkraft mit Weichzeichner	Orientierung beim Scrollen
Lila Akzent	`#bd93f9` als Akzent im Dark Mode und im DB-Chip der Kopfzeile	Dracula-Lila, 5,90:1 auf dem dunklen Seitenhintergrund `#282a36`
Chips und Karten mit 1-px-Rahmen	Tags, Übersichtskarten, Vor- und Zurück-Links unter dem Artikel	Gruppen, die du schnell überfliegen kannst
Suche per Tastenkürzel	„Ctrl+K" bzw. „⌘K" im Suchfeld	Tastatur zuerst, sofortige Suche über den ganzen Bestand
Leuchteffekt	nur auf der Startseite, um das Terminal-Fenster ganz oben	ein einziger Akzent statt vieler

Was du hier nicht findest: Inter, lila Verläufe auf Weiß, Einblend-Animationen für jeden Abschnitt, Emojis als Icons, Verlaufstext in Überschriften. Und der Radius ist nicht überall derselbe: Tag-Chips haben 6 Pixel, der DB-Chip und Inline-Code 4, Code-Blöcke 8, Terminal-Fenster 12. Das ist weniger mein Verdienst als eine Folge der Richtung: Die Seite sollte wie ein Terminal aussehen, nicht wie eine Startup-Landingpage.

Eine Pointe am Rande: In seinem Beitrag empfahl Anthropic als Ausweg aus dem Einheitslook unter anderem, sich von den Farbschemata für Entwicklungsumgebungen (IDE) inspirieren zu lassen, und nannte für eine Code-Ästhetik JetBrains Mono. Dracula ist ein solches Farbschema, und JetBrains Mono setzt hier die Diagramme. Der Ausweg von gestern ist heute selbst ein erkennbarer Look. Das ist meine Lesart, nicht die von Anthropic. Sie zeigt aber, wie schnell sich Muster verbreiten, wenn sehr viele Menschen dieselben Werkzeuge mit denselben Hinweisen benutzen.

Warum diese Vorlieben kein Makel sind

Das Wichtigste vorweg: Die Vorlieben der KI sind keine Geschmacksverirrung. Sie sind der Durchschnitt aus sehr vielen guten Entscheidungen. Fast jedes Merkmal von oben geht auf ein Werkzeug oder eine Regel zurück, die aus gutem Grund Standard geworden ist:

Inter wurde für Bildschirme entworfen (öffnet in neuem Tab) (englisch), mit einer hohen x-Höhe für bessere Lesbarkeit.
Die Farbpalette von Tailwind ist laut Dokumentation (öffnet in neuem Tab) (englisch) von Designern sorgfältig abgestimmt, jede Farbe in elf Stufen. Die Abstände bauen auf einer Grundeinheit (öffnet in neuem Tab) (englisch) von 0,25 rem auf, also 4 Pixeln: p-4 setzt das Vierfache davon als Innenabstand, also 1 rem. Das ergibt einen ruhigen, gleichmäßigen Rhythmus.
shadcn/ui, die Komponenten-Sammlung, auf der unter anderem v0 von Vercel (öffnet in neuem Tab) (englisch) aufbaut, setzt auf Bausteine, die sich um die Barrierefreiheit kümmern: Radix (öffnet in neuem Tab) (englisch) und inzwischen standardmäßig Base UI. Radix folgt den WAI-ARIA-Mustern des World Wide Web Consortium (W3C), den Vorgaben für barrierefreie Bedienelemente, und übernimmt Rollen, Fokus-Steuerung und Tastaturbedienung.
Die Icons von Lucide, der Standard in shadcn/ui, folgen strengen Regeln für einen einheitlichen Stil.
Karten, Chips, Suche per Tastenkürzel sind Muster, die du von vielen Seiten und Programmen kennst. Bekanntes musst du nicht erst lernen.
Dunkle Themes sind unter Entwicklern verbreitet: In der Entwicklerumfrage von JetBrains (öffnet in neuem Tab) aus dem Jahr 2021 ist das dunkle Editor-Theme deutlich beliebter als das helle.

Der Skill hält ausdrücklich fest: Alle diese Merkmale sind für manche Aufträge legitim, nur sind sie defaults rather than choices, also Voreinstellungen statt Entscheidungen. Adrian Krebs fasst seine Auswertung ähnlich zusammen: Ist das schlecht? Nicht wirklich, nur uninspiriert. Vor der KI-Ära, merkt er an, sah schließlich alles aus wie Bootstrap, das verbreitete CSS-Framework.

Ein KI-Design ist deshalb selten schlecht. Es ist erwartbar. Problematisch wird es erst dort, wo eine Voreinstellung eine Entscheidung ersetzt.

So schärfst du deinen Blick

Wenn du wissen willst, ob eine Seite mit KI gestaltet wurde, helfen dir diese fünf Prüfungen:

Schrift prüfen: Rechtsklick auf einen Text, „Untersuchen", dann die berechnete font-family ansehen. Inter, Geist, Space Grotesk und Instrument Serif sind starke Indizien, aber keines davon ist allein ein Beweis. Auf dieser Seite findest du übrigens die Instrument Sans, die Schwester der Instrument Serif.
Farben prüfen: Indigo oder Violett als Akzent, mittelgraue Schrift auf dauerhaft dunklem Hintergrund, ein fast schwarzer Hintergrund mit einer einzigen Leuchtfarbe.
Struktur prüfen: identische Karten mit einem Icon obendrauf, Versal-Labels über jeder Überschrift, nummerierte Schritte „01, 02, 03", wo gar keine Reihenfolge besteht.
Details prüfen: Milchglas, große farbige Leuchteffekte, ein „→" hinter jedem Link, Mittelpunkte in Meta-Zeilen. Dazu kommen nach meiner Beobachtung drei Punkte über Code und ein Raster mit weicher Maske.
Die entscheidende Frage stellen: Passt das zum Thema der Seite, oder würde es genauso auf jeder anderen stehen?

Kein einzelnes Merkmal beweist etwas. Die Häufung schon. Und der fünfte Punkt ist der wichtigste: Anthropics Skill beschreibt die Merkmale genau so, als Dinge, die unabhängig vom Thema auftauchen. Bei der JPKCom DB lautet meine Antwort: Der Terminal-Look passt zu einer Seite voller Befehle und Code. Er ist eine Voreinstellung, die ich mir bewusst ausgesucht habe.

Meine Bilanz: Pro und Kontra

Was für KI im Redesign spricht:

Tempo. Zwei Tage bis zum Merge, einschließlich Spezifikation, Tests und mehrerer Reviews.
Gründlichkeit. Jedes wichtige Farbpaar ist nachgerechnet, jede Aufgabe mit Änderungen am Code wurde geprüft, und der Abschlussreview hat 31 Befunde geliefert. Das ist die Arbeit, die bei einem so großen Umbau gern zu kurz kommt.
Dokumentation als Nebenprodukt. Spezifikation, Pläne und die neue DESIGN.md sind beim Bauen entstanden, nicht als lästige Pflicht danach.
Nachprüfbar bessere Barrierefreiheit. Jedes tragende Farbpaar rechnet jetzt ein Test nach. Reduzierte Bewegung stand vorher nur in der Doku, jetzt ist sie umgesetzt. Den Kontrastmodus von Windows und einen Fokus, der nie unter der Kopfzeile verschwindet, gab es vorher gar nicht. Nur den sichtbaren Fokusrahmen hatte die alte Seite schon, und beim Nebentext im Dark Mode ist die Reserve kleiner geworden.

Was dagegen spricht, oder zumindest Vorsicht verlangt:

Austauschbarkeit. Anthropic schreibt selbst, dass der generische KI-Look Oberflächen sofort erkennbar macht und dass sie sich dadurch leicht abtun lassen. Das Magazin PAGE sieht in seinem Trend-Ausblick für 2026 (öffnet in neuem Tab) eine Gegenbewegung zur KI-Glätte: Marken müssten Signale senden, denen Menschen vertrauen können, also Klarheit statt Output-Masse und Community-Nähe statt Einheitslook. Mein Gegenmittel sind die alte CI-Farbe als Akzent, mein Logo und Inhalte aus meiner Praxis.
Vorschnelle Urteile. Ein Teil der Besucher wird die Seite wegen ihres Looks vermutlich schnell in eine Schublade stecken. Dagegen helfen nur geprüfte Inhalte und offene Karten.
Auch die KI macht Fehler. Zwei gingen auf ihr Konto, und beide hat sie selbst gefunden: Den Überlauf bei 320 Pixeln hat ihre eigene Messmatrix übersehen und ihre Nachprüfung entdeckt. Tailwind las das ganze Repository, auch die Spezifikation und die Pläne mit ihren zitierten alten Klassennamen, und lieferte dafür Regeln für rund 140 tote Farbklassen aus; nach der Korrektur schrumpfte das gebaute CSS von 94 auf 68 KB.
Die KI sieht nicht alles. Zwei weitere Fehler waren Folgen des Schriftwechsels. Keine Messung hat sie bemerkt, gefunden habe ich sie: die verrutschten Diagramme und die abgeschnittene „10.". Automatische Prüfungen ersetzen keine Augen.

FAQ

Ist die JPKCom DB komplett von KI erstellt? Nein. Die Seite, ihre Struktur und ihre Themen gehen auf mich zurück. Das Redesign hat Claude Code nach meinen Vorgaben umgesetzt, Richtung und Freigaben kamen von mir. Auch die Inhalte entstehen mit KI-Unterstützung in unterschiedlichem Maß, die Verantwortung liegt bei mir. Details stehen auf der Seite zur KI-Transparenz.

Welche KI hat das Redesign umgesetzt? Claude Code von Anthropic. Die Koordination übernahm Claude Opus in zwei Sitzungen, eine pro Tag, verbunden über eine schriftliche Übergabe; Sub-Agenten mit Claude Sonnet haben die meisten Einzelaufgaben umgesetzt und geprüft. Richtung und Freigaben kamen von mir.

Warum sind Code-Blöcke auch im Light Mode dunkel? Weil Code hier immer wie im Terminal aussehen soll und weil feste Farben dort sicherer sind: Umschaltende Farben fielen auf der dunklen Code-Fläche unter die Kontrastgrenzen. So müssen die Syntaxfarben nur auf einer einzigen Fläche das AAA-Niveau von 7:1 halten.

Warum nicht das offizielle helle Dracula-Theme Alucard? Der Akzent im Light Mode ist die Farbe, die die Seite schon vorher hatte. Mit einer eigenen Ableitung bleibt der Light Mode näher an meiner CI als mit der Alucard-Palette.

Kann ich Hell oder Dunkel fest einstellen? Ja, über den Schalter im Footer: Die Systemvorgabe (Bildschirm-Symbol) folgt deinem System, Hell (Sonne) und Dunkel (Mond) gelten fest. Die Wahl speichert dein Browser.

Woran erkenne ich am schnellsten ein KI-Design? An der Häufung: Schrift, Farbe, Karten und kleine Details wie Mittelpunkte in Meta-Zeilen oder ein „→" hinter jedem Link. Und an der Frage, ob das Design zum Thema passt oder auf jeder Seite gleich aussähe.

Fazit

Das Redesign der JPKCom DB ist ein Redesign durch KI, und es darf so aussehen. Ich habe die Richtung vorgegeben, geprüft, verworfen, Fehler gefunden und freigegeben. Claude Code hat die Arbeit gemacht, die bei einem so großen Umbau viel Zeit kostet: Bestandsaufnahme, Spezifikation, Umsetzung, Kontrasttests und Reviews.

Heraus kam eine Seite, die in beiden Modi getestete Kontraste hat, auf dem Handy ab 320 Pixeln ohne seitliches Scrollen läuft und für Maschinen genauso lesbar geblieben ist wie vorher. Und eine Seite, die ihre Herkunft nicht versteckt. Wenn du nach diesem Artikel auf anderen Seiten plötzlich die Versal-Labels, die Mittelpunkte und das Leucht-Lila siehst, hat sie ihren Zweck als Lehrbeispiel erfüllt.

Die Merkmale von KI-Design sind kein Makel. Sie sind geronnene gute Praxis. Wichtig ist nur, dass hinter der Voreinstellung jemand steht, der sie gewählt hat.

Quellen

Dracula Theme: Spezifikation (öffnet in neuem Tab) (englisch): Farbwerte von Dracula und Alucard
Anthropic: Improving frontend design through Skills (öffnet in neuem Tab) (englisch): distributional convergence
Anthropic: Frontend-Design-Skill, übersetzte Fassung (öffnet in neuem Tab) (englisch): Liste der KI-Design-Merkmale; die aktuelle Fassung (öffnet in neuem Tab) (englisch) kann davon abweichen
Adam Wathan zu bg-indigo-500 (öffnet in neuem Tab) (englisch)
Adrian Krebs: Scoring Show HN submissions for AI design patterns (öffnet in neuem Tab) (englisch)
Nielsen Norman Group: Dark Mode vs. Light Mode (öffnet in neuem Tab) (englisch)
PAGE: UX-Design-Trends 2026 (öffnet in neuem Tab)
W3C: WCAG 2.2 Understanding (öffnet in neuem Tab) (englisch)

Dieser Artikel hat vor der Veröffentlichung zwei Runden eines adversarischen Faktentreue-Reviews durchlaufen: Jede überprüfbare Behauptung wurde mit dem Ziel geprüft, sie zu widerlegen. Über 60 Stellen haben das nicht unverändert überstanden, darunter eine falsche Reihenfolge der Ereignisse und eine Aussage über Screenreader, die dem Quellcode von WebKit, der Engine von Safari, widersprach.

Weiterlesen

DESIGN.md: Das Design-System als Datei, die auch die KI liest: das Format, in dem dieses Design-System dokumentiert ist
HTML-Landmarks in der Praxis: die Seitenstruktur hinter Kopfzeile, Sidebar und Footer
Header-Größen: Wie groß darf der Kopf einer Website sein?: Breitenstufen und Kopfzeilen mit Zahlen statt Bauchgefühl
CSS @layer in der Praxis: wie die Kaskadenebenen der Seite aufgebaut sind; die Token-Schicht liegt bewusst außerhalb
Schreiben für KI: wie Inhalte für KI-Leser aufgebaut sein sollten
Wer prüft den Prüfer?: der Review-Prozess, den auch dieser Artikel durchlaufen hat