Redesign by AI: Why JPKCom DB Deliberately Looks AI-Made

If you've known JPKCom DB for a while, you will have noticed the change straight away: a dark bar at the top like a terminal, headings in a monospace typeface, green arrows in front of every list item, longer code blocks in windows with three coloured dots. If this is your first visit, you may be thinking something else: This looks like it was built by artificial intelligence (AI).

Both are true. This is a redesign by AI: the idea, the direction and every approval came from me, and Claude Code carried it out, from the inventory through the specification to code, tests and reviews. And the fact that the site now looks the way AI-designed sites tend to look is not something I overlooked. It is deliberate, for three reasons: I want to show openly what I work with, I take a clear stand for AI, and the site is meant to be a teaching example that helps you learn to recognise AI design.

In this article I first show you how the redesign came about and how the work was split. Then comes the result: the colours (Dracula in the dark, a palette of my own in the light), accessibility with contrast ratios a test recomputes, the typefaces and their readability, usability, the behaviour from a 320-pixel phone to a wide screen, and the layer for AI readers, which deliberately stayed the same. Finally, you learn how to recognise AI-generated designs.

On method: The redesign figures come from this site's repository, from the build and from the logs of the working sessions with Claude Code. The contrast values are recomputed with the project's own colour maths. I back up the traits of AI-generated design with primary sources, including what Anthropic itself has published on the subject. Where I am giving my own reading rather than evidence, I say so.

The starting point: a good foundation that didn't look like me

JPKCom DB didn't start from scratch. Its first version sat on an Eleventy starter template that saved me a lot of work: the search, the code highlighting, the Markdown features for AI, a clean build chain. It was a good foundation. Everything added since builds on it: the two languages, the blog and by now more than 400 articles per language.

Visually, though, I had never really made the site my own. I had recoloured it several times in my brand colour, a muted slate blue. Even so, it didn't feel like my site. That was what set the redesign in motion.

How the redesign should be built technically was settled quickly: Claude Code proposed a token layer in which every colour lives in exactly one place, and I chose it. How necessary that step was only became clear in the inventory that followed. Six agents mapped every surface of the site, and a seventh spot-checked their results and looked for gaps. What came out:

519 hard-wired Tailwind colour classes, 216 of them as dark: variants, plus 110 classes of old custom tokens. They sat in 24 of the 77 files searched. That meant three parallel grey systems: one for light, one for dark, one in the CSS.
The base colours documented in the design documentation never reached the browser. A utility class on <body> overrode the documented rule.
prefers-reduced-motion, respecting a request for reduced motion, was documented as implemented. The code had not a single line for it.

A design system that existed on paper but not in the browser. Recolouring alone would not have changed that. Every colour had to move to one place.

Redesign by AI: how the work was split

I set the direction and approved every step. The redesign was built by Claude Code, Anthropic's AI tool for the command line, the tool I spend a good part of my working week in. Claude Opus did the coordination in two sessions, one per day, linked by a written handover in the repository. Sub-agents running Claude Sonnet carried out and checked most of the individual tasks, and the final reviews ran on Opus again. It took two days from the first message to the merge.

This is how it went:

Kick-off: I describe the problem and the direction.
Assessment: Claude Code presents three architecture approaches with pros and cons. I choose the token layer.
Inventory: the seven agents described above.
Specification: An adversarial review from four review perspectives finds 63 weaknesses in the first draft, and the corrections go into the specification. By the end it grows to 35 decisions. On top of that come 16 defaults that I confirmed in one go on the first day; three of them were dropped later.
Preview: a static HTML file. Based on it I change the logo colour, the accent in light mode and the list bullets.
Implementation in stages: As a rule only one agent writes at a time, and every task that changes something in the repository gets its own review.
Pause for a visual check: I sign off the palette, typefaces and headings and change cards and category lists.
Final review: five review perspectives and ten review agents that tried to refute every finding, 31 findings, five of them important. Then a wave of corrections and a follow-up check.
Approval and merge by me.

Who does what

 HUMAN                        AI (Claude Code)
 ──────────────────           ─────────────────────
 Idea, direction        ──►   Inventory
                              Specification, review
 Check the preview      ◄──   Preview
 Decide, reject         ──►   Plan, code, tests
 Visual check           ◄──   Interim state
 Report bugs            ──►   Final review, corrections
 Approval, merge        ◄──   Result with measurements

At the end there were 94 commits and roughly 630 colour classes replaced or deleted. The number of automated tests rose from 170 to 264, and the project's DESIGN.md had been rewritten.

If you are planning a redesign with AI yourself, adopt this split: the AI may propose, measure, build and check. Deciding and approving should stay with you.

Why the site deliberately looks AI-made

It all started because the site didn't feel like mine. The new look carries many of the traits by which you recognise AI designs today. I could have asked Claude Code to cover up those traces. I deliberately didn't. The site should look like what it is: a project I build with AI.

Openness. On the AI transparency page I disclose where AI helps create, correct and check the content. The design itself is now part of that openness. When you open the site, you see straight away what is being used here, without having to hunt for a footnote.

A clear statement for AI. I work with AI a lot and see no point in hiding it. A redesign in two days, with a contrast test for every important colour pair and several separate review passes, is a strong argument for AI in web development in my book.

A teaching example. AI-designed sites share a surprising number of traits. Once you have seen them, you recognise them everywhere. This site shows them to you in the original, and further down you learn why they come about.

What the site is not: purely AI-generated. I stand behind every line of content and every design decision. AI is a tool here, not an author with final responsibility. That is what the transparency page says, and it applies to the design just as much.

The guiding idea: a knowledge base that looks like its tool

JPKCom DB now looks like the place where its content gets used: the terminal.

That is more than taste. Most of the site consists of cheat sheets for 220 shell commands, documentation for 40 tools and blog articles with a lot of code. The build contains a good 18,000 code blocks. If you read something here, you often want to copy something into a shell right after. A design that looks like an editor and a terminal tells you at first glance: this is a technical reference, and much of it is meant to be copied.

Three principles carry the whole system:

Mono for structure, sans for reading. Headings, labels and controls are set in a monospace typeface, body text in a calm sans serif.
Code and header are always dark, in dark mode and in light mode alike. They are the site's terminal.
Every colour lives in exactly one place. No element gets its colour twice, and no component knows its own light and dark value.

On the desktop, this results in the following layout:

Layout from 1280 px

┌──────────────────────────────────────────────────────────────────┐
│ HEADER  dark in both modes, stays at the top, 56 px tall         │
│ JPKCom DB   [ Quick search…  Ctrl+K ]   DE  RSS   [ > jpkc.com ] │
├─────────────┬───────────────────────────────────┬────────────────┤
│ SIDEBAR     │ CONTENT  text column max. 896 px  │ ON THIS PAGE   │
│ 256 px      │ Breadcrumb                        │ 224 px         │
│             │ H1, description, tags             │                │
│ Areas       │ Body text in Instrument Sans      │ active item:   │
│ Categories  │ ┌───────────────────────────────┐ │ bold + bar     │
│ Legal       │ │ Code in a dark window         │ │                │
│             │ └───────────────────────────────┘ │                │
│             │ [ ← Previous ]        [ Next → ]  │                │
├─────────────┴───────────────────────────────────┴────────────────┤
│ FOOTER  full width: brand │ profile │ profile │ profile          │
└──────────────────────────────────────────────────────────────────┘

Dracula in the dark, a palette of my own in the light

The dark palette is Dracula (opens in a new tab), the colour scheme Zeno Rocha designed in 2013 for code editors and terminals. By its own account, Dracula is now available for more than 400 applications. The background is #282a36, the text #f8f8f2, plus the typical bright colours: purple, pink, cyan, green, orange and yellow.

The palette was not adopted blindly. For the site I set two limits from the Web Content Accessibility Guidelines (WCAG): 4.5:1 for secondary text and the error colour on the page, 7:1 for every syntax colour in code. Measured against those, the contrast fell short in four places:

Colour	Dracula	JPKCom DB	Contrast before → after
Secondary text	`#6272a4`	`#8e9abe`	3.03 → 5.10:1 on the page background
Red for errors	`#ff5555`	`#ff6969`	4.04 → 4.52:1 on the background grid
Comments in code	`#6272a4`	`#9ba5c5`	3.68 → 7.09:1 on the code surface
Red in code	`#ff5555`	`#ff7e7e`	5.52 → 7.05:1 on the code surface

Italics have also been removed from the syntax theme. Martian Mono, the code typeface, has no true italic, and artificially slanted letters had no place in code.

For light mode, Dracula now has an official light counterpart, Alucard (opens in a new tab). I don't use it. The DB's light palette is my own derivation with the same roles as in the dark, meaning the same colours for links, accents, success, warning and error, each checked against the light background for its contrast limit.

One colour I deliberately did not take from Dracula: the accent in light mode. Instead of purple it is #2f5468, the slate blue that was already the site's accent before the redesign. That is a bit of continuity, and it is also the better colour: light text on the accent reaches 7.78:1.

Technically, both palettes rest on a token layer. Both live in one file, _tokens.css, under the same names. Tailwind reads the variables via @theme inline and turns them into classes such as bg-page or text-fg:

Colour in exactly one place

/* _tokens.css: both palettes, same names */
:root { --page: #f5f5f7; --fg: #1a1a16; }
.dark { --page: #282a36; --fg: #f8f8f2; }

/* main.css: Tailwind turns them into classes */
@theme inline {
  --color-page: var(--page);
  --color-fg: var(--fg);
}

The markup then only says bg-page, with no pair of light and dark values and no dark: any more. A guard script reports every Tailwind palette class, every retired token of the old palette and every dark: variant in templates, CSS and JavaScript. Before the rebuild it would have flagged roughly 630 of them; today the count is 0. In the article on DESIGN.md I had described Tailwind's @theme block as the source of truth. Since the redesign, the source of truth for colours has been _tokens.css, and the new DESIGN.md lists the same token set for light and dark, value for value as in _tokens.css.

Code and header never switch. They use fixed constants instead of switching tokens, and besides the look there is a practical reason for it: a switching token would quickly fall below the limit in light mode on a dark background. The light-mode link colour would only reach 2.14:1 on the code surface instead of the required 4.5:1, and even the darker pink that shows focus in light mode would only just clear the 3:1 for a focus outline there, at 3.32:1. That is why everything in code uses only --code-* constants and everything in the header --head-*.

Which palette you see is decided first by your operating system. In the footer you can override it: the three icons there stand for system theme (screen), light (sun) and dark (moon). This matters because the Nielsen Norman Group (opens in a new tab), in its review of the research, concludes that people with normal vision mostly read better in light mode. It advises against making dark mode the default for a general audience and recommends offering it as an option. A terminal look that only works in the dark was therefore out of the question.

Accessibility: contrast a test recomputes

The most important accessibility decision was not a colour but a test. The file theme-tokens.test.mjs reads both palettes from the token file and recomputes every colour pair the design relies on: text on its surfaces, focus outlines, scrollbars, list markers. The syntax colours in code are checked by a second test, shiki-theme.test.mjs. If a pair falls below its limit, the test run turns red before you ever see the colour in a browser.

The limits in detail: 4.5:1 for normal text at level AA, 7:1 at the stricter level AAA, 3:1 for controls and graphical cues.

What	Limit	Measured light / dark
Body text	7:1 (AAA)	13.08 / 10.25
Headings	7:1 (AAA)	16.03 / 13.36
Links	4.5:1 (AA)	7.43 / 10.29
Secondary text	4.5:1 (AA)	4.92 / 5.10
Numbers of numbered lists	4.5:1 (AA)	all above
Every syntax colour in code	7:1 (AAA)	tightest value 7.05
Focus outlines, scrollbars, list arrows	3:1	all above

The second test also checks that the original Dracula fails the 7:1 limit. That is a reminder to tidy up: if a future Dracula version reaches 7:1 on its own, the contrast boost becomes unnecessary, and that is exactly when this test turns red.

The header is recomputed the same way. In dark mode it is 90 per cent opaque and blurs the content beneath it. The test assumes the worst case, the bar over a white area. At 85 per cent opacity the link text would drop to 4.48:1 there, which is why it is 90.

Colour is never the only signal. You can always recognise links in the text by their underline. The active entry in the table of contents is also bold, has a 2-pixel bar and aria-current, because between the accent and a normal entry there is only a contrast of 1.51:1 (light) or 1.16:1 (dark). Search hits are highlighted yellow and bold: in light mode, Dracula yellow has a contrast of only 1.12:1 to the background in the white search window, and just 1.08:1 on a selected hit.

Focus is always visible and never hidden. When you tab through the page, every element shows a 2-pixel outline in pink, with its own fixed colour in the header and in code. It is a real outline, not a shadow ring, so it also survives Windows High Contrast mode (contrast themes in Windows 11). To keep focus from ever disappearing under the header, there is exactly one offset for all jump targets: scroll-padding-top at the height of the header plus 1.5 rem. That applies to anchors, footnotes, the skip link and every element you reach with the Tab key. On narrow screens there is an extra offset at the bottom for the fixed bar at the lower edge.

Lists with green arrows stay lists. The ❯ character is a real list marker via list-style-type, not a mocked-up pseudo-element:

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

For screen readers, this is the simplest safe solution. A list with no visible markers at all, meaning list-style: none and nothing in its place, is no longer treated as a list by Safari for the VoiceOver screen reader. A pseudo-element with content would also rescue the role, but the real list marker needs no detour. The list stays a list for screen readers, including the number of items.

Then there are the things you only notice when you need them:

Reduced motion: If you set it in your system, you get no animations, no transitions and no smooth scrolling.
Contrast mode: Focus, active navigation and selected search hits use the system colours there, and the background grid disappears.
Print: If you print a page in dark mode, it comes out light, instead of putting light text on white paper. Code stays dark; header, navigation and footer are left out.
Theme switch: The three options are a radio group with aria-checked, and the selection is shown as a filled area rather than a shade of colour.

To be honest, there is a flip side: in dark mode, secondary text mostly has less headroom than before. Back then there were several greys for it. Descriptions, meta lines and article links in the sidebar reached 6.94:1, table of contents and search 8.60:1, but the "Previous" and "Next" labels below the article and the legal links in the sidebar only 3.78:1, below AA. Today secondary text uses a single Dracula blue-grey at 5.10:1: safely above AA, but closer to the limit. Claude Code flagged this regression itself in the first draft of the specification, without my asking.

The WCAG criteria behind these points: 1.4.1 Use of Color (opens in a new tab), 1.4.3 Contrast (Minimum) (opens in a new tab), 1.4.6 Contrast (Enhanced) (opens in a new tab), 1.4.11 Non-text Contrast (opens in a new tab), 2.4.7 Focus Visible (opens in a new tab) and 2.4.11 Focus Not Obscured (Minimum) (opens in a new tab). Why the site's landmarks are built the way they are is covered in HTML Landmarks in Practice.

Readability: mono for structure, sans for reading

Monospace typefaces are the most striking feature of the new look and at the same time the biggest risk to readability. A long article set entirely in monospace looks like a terminal but, to me, reads like a log file: every letter is equally wide, the "i" as wide as the "m", and the rhythm of the words gets lost. That is why the division of labour is strict.

Martian Mono (opens in a new tab) by Evil Martians is used for headings, navigation, labels, buttons and code. The typeface is variable in width and weight and has a tall x-height, meaning large lowercase letters. In code it is condensed to 87.5 per cent width, narrower than in the headings: a character there is 0.65 em wide instead of 0.70 em. That is closer to the roughly 0.6 em of common code fonts, and about 8 per cent more characters fit on a line.
Instrument Sans (opens in a new tab) is used for the body text, with a true italic instead of artificially slanted letters. The article titles in the sidebar and in the previous and next links below the article, as well as the entries in the table of contents, also stay in sans. You want to read those, not skim them.

Body text has a line height of 1.625, and the text column is at most 896 pixels wide.

The new typefaces come at a price. Every page now preloads two font files totalling roughly 96 KB, a good two and a half times as much as before: the old typeface got by with one file of roughly 38 KB per page. Italics, extended character sets and the diagram typeface are loaded by the browser only when a page needs them. For the italic that was already the case before. All fonts are self-hosted in the repository, with no request to Google Fonts. Why that is more than a matter of style is explained in my article on the Federal Court of Justice (BGH) ruling on data transfers.

And then there is a third typeface you only see in diagrams, including the ones in this article. After the font switch I noticed that the text diagrams in older articles had shifted. The cause: Martian Mono contains no box-drawing or block characters. The browser took ┌, ─ and │ from a fallback font with a different character width, and the frames drifted apart by up to 46 pixels per line. The fix is a subset of JetBrains Mono (opens in a new tab) of just 24 KB, used only for code blocks containing such characters. A tested function detects them during the build. Measured, that gave 0 pixels of column drift in all 28 diagram blocks that existed at the time. One detail shifted everything once more: the subset also has to contain the space character. Otherwise the space comes from the fallback font, is a fraction wider, and the columns wander again.

Usability: find fast, copy fast

A knowledge base is only as good as the path to the right page. That is why the interface relies on a few fixed paths that work the same everywhere.

The most important one predates the redesign: hub-and-spoke instead of a navigation tree. A sidebar that lists every article breaks down at more than 400 articles per language, and the goal is many more. So below the six main areas the sidebar only expands the area you are currently in: for cheat sheets and tools its categories and the articles of the active category, for guides and changelog the articles themselves. The blog grows without limit and gets no list at all; here the overview, the previous and next links, search and tags take you further. The three legal links follow below. On the tar cheat sheet that makes 29 links instead of all 220 cheat sheets.

Hub and spoke

              ┌──────────────┐
              │   Homepage   │
              └──────┬───────┘
     ┌───────────┬───┴───────┬───────────┐
     ▼           ▼           ▼           ▼
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│  Cheat  │ │  Tools  │ │  Blog   │ │ Guides, │
│ sheets  │ │         │ │         │ │Changelog│
└────┬────┘ └────┬────┘ └─────────┘ └─────────┘
     ▼           ▼
15 categories  40 tools
     ▼           ▼
220 commands   120 pages

Across it all: search, tags, links in the text

On top of that come the small paths that save you clicks:

Search from anywhere: You can also open the search field in the header with Ctrl+K (⌘K on a Mac) or the / key. You pick results with the arrow keys, Enter opens, Escape closes.
Tags as a shortcut: A click on a tag below the title opens the search, filtered to that topic.
Copying without aiming: In terminal windows the copy button has a fixed spot in the bar; in other code blocks it sits at the top right of the block. With a mouse it appears as soon as you move over the code, with the keyboard at the latest when the button itself gets focus. On a phone it is always visible.
Orientation: A breadcrumb above the title, the active section in the table of contents and previous and next links at the end of every article show you where you are.
Escape closes whatever is open: Side menu, table of contents and search close with Escape, and focus returns to where you were before; for the side menu and the table of contents, to the button you opened them with.

Responsive: from a 320-pixel phone to a wide screen

On a phone you don't have to scroll sideways from a width of 320 CSS pixels. At each breakpoint the page rearranges itself rather than just getting wider.

Width	What changes
below 360 px	The header moves closer together; all elements stay visible.
below 640 px	16 px side margin, the RSS link is hidden, overview cards are single-column.
below 1024 px	Menu button and a slide-out side menu instead of the sidebar; at the bottom a fixed bar with Home, Search, Contents (on pages with a table of contents) and "Back to top".
from 1024 px	The sidebar sits on the left (256 px), the search field in the header. The bottom bar disappears, and with it, up to 1279 px, the table of contents too.
from 1280 px	The table of contents appears as the right-hand column (224 px).
from 1536 px	Even next to sidebar and table of contents, the text column reaches its maximum width of 896 px; the whole layout ends at 1680 px.

On a phone the same page looks like this:

Layout on a phone

┌─────────────────────────────────┐
│ Ξ  JPKCom DB    DE [> jpkc.com] │
├─────────────────────────────────┤
│ Breadcrumb                      │
│ H1, 24 px, breaks if needed     │
│ Body text, 16 px side margin    │
│ ┌─────────────────────────────┐ │
│ │ Code scrolls inside  →      │ │
│ └─────────────────────────────┘ │
│ [ ← Previous                  ] │
│ [                      Next → ] │
├─────────────────────────────────┤
│ Footer: brand, profile columns  │
├─────────────────────────────────┤
│ Home Search Contents Back to top│
└─────────────────────────────────┘

That nothing overflows sideways is down to several small rules working together:

Headings of the two top levels scale via clamp() (the H1 from 24 to 30 pixels, the H2 from 22 to 26). All headings may break mid-word if needed and are hyphenated where the browser has a dictionary.
Code blocks scroll inside their own box and can be reached with the keyboard, so you can scroll sideways without a mouse.
Tables stack below 640 pixels into rows of label and value. Above that, tables that are too wide scroll in their own focusable box.
Titles in terminal windows are truncated with "…" rather than overflowing the bar.
Numbered lists with ten or more items get extra indentation so two-digit numbers don't stick out past the edge of the screen.

The most instructive story of the redesign happens at 320 pixels. Claude Code checked the site mid-rebuild, right after the header, page frame and footer, in a measurement matrix: 8 pages, 5 widths, 2 colour modes. All 80 combinations came back clean. Even so, the header already stuck out 36 pixels past the edge at 320 pixels at that point. At narrow widths the measurement ran in Chromium's mobile device mode, and in that mode the browser widens the layout viewport to the width of the content. The page was too wide, and the measured viewport simply grew with it. The bug was only found by the follow-up check after the final review, also by the AI. The fix is an extra breakpoint below 360 pixels that only reduces the spacing. The navigation now ends at 308 instead of 356 pixels, and every control stays at least 24 × 24 pixels, as WCAG 2.5.8 Target Size (Minimum) (opens in a new tab) requires.

I found a second bug myself, when I looked at the page at phone width: in numbered lists with ten or more items, the "10." was cut off on the left at 375 pixels. Since the redesign, the numbers are set in Martian Mono and are wider than before, and the number in front of the item, the list marker, slipped four pixels off the screen. None of the measurements had noticed.

One small flaw remains: in a desktop window only about 360 to 365 pixels wide that shows a classic scrollbar, the header sticks out past the edge by up to 6 pixels. The media query counts the scrollbar, so the narrow breakpoint doesn't kick in there. Phones overlay their scrollbar on the content and are not affected.

My lesson from this: a green measurement matrix only proves that the measurement found nothing. It doesn't replace looking at the page yourself. When you test responsively, look at the most important pages at the smallest width with your own eyes at the end. In Header Sizes: How Big Should a Website Header Be? I have written up in detail which header and breakpoint sizes can be justified with data.

Nothing changed for machines, and that is deliberate

The redesign left the Markdown layer untouched: AI readers still get clean text instead of Dracula.

JPKCom DB has been an AI experiment from the start. Every page also exists as raw Markdown: /db/en/blog/design-md/ has its mirror at /db/en/blog/design-md.md, every article page has a menu for copying as Markdown, and llms.txt lists the content for language models. If a program asks with Accept: text/markdown, it gets the Markdown directly instead of the HTML. Try it yourself:

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

The terminal windows only come into being when the HTML is rendered; the Markdown mirrors get none of it. The bar with the three dots is also excluded from the search index. Otherwise its labels, such as "Terminal" or the language name, would be indexed as page content, and every page with a longer shell block would be a hit as soon as you search for "Terminal".

The code is built for AI too. The HTML is cleanly structured with landmarks, every article page carries structured data as JSON-LD, and the DESIGN.md describes the design system value by value as a file an AI agent can read before every change. The contrast test and the guard script fire as soon as an agent hard-wires a colour again or pushes it below its limit. How I write content for AI readers is covered in Writing for AI.

Teaching example: how to recognise AI-generated designs

Why AI designs look alike

Anthropic explains the phenomenon itself, in the post "Improving frontend design through Skills" (opens in a new tab). If you let a language model build a landing page without guidance, it will almost always reach for the Inter typeface, purple gradients on a white background and minimal animations. Anthropic calls the cause distributional convergence: models predict each next piece of text from the statistical patterns in their training data. In that data, safe design choices dominate, the ones that work everywhere and offend no one. Without direction, the model reaches into the middle of that distribution.

A post by Adam Wathan, the creator of Tailwind CSS, shows how concrete that middle is. He publicly apologised (opens in a new tab) for having made every button in Tailwind UI bg-indigo-500 years ago, with the result that every AI-generated interface on earth was indigo too. It was a joke, but a fitting one.

Anthropic turned these experiences into a skill for Claude Code (opens in a new tab), a set of instructions Claude Code draws on for design tasks. It is meant to avoid such patterns and therefore lists them. In the version I summarise here (opens in a new tab), it names five clusters that AI designs currently gravitate to:

a warm cream background with a high-contrast serif display face for headings and a terracotta or warm-clay accent, often near #D97757, the colour Anthropic itself uses in Claude;
a near-black background with a single bright acid-green or vermilion accent;
a broadsheet-style layout with hairline rules, no rounded corners and dense columns;
the card kit of typical software-as-a-service (SaaS) sites: content chopped into identical rounded cards, one border radius on everything regardless of hierarchy, the same soft grey shadow under each card, gradient washes as decoration;
template chrome that appears whatever the subject: a tracked-out all-caps eyebrow label (small text in widely spaced capitals) above every heading; meta strings joined with middle dots ("A · B · C"); labels built as "WORD — fragment"; tinted near-black instead of black; a monospace face for small data labels; and a "→" appended to link and button text.

The first version of the skill was even more direct. It warned against overused typefaces such as Inter, Roboto and Arial, against purple gradients on white and against the tendency to converge on the Space Grotesk typeface again and again.

Adrian Krebs measured how widespread these patterns are. He automatically checked the landing pages of 1,590 "Show HN" projects (opens in a new tab), Hacker News's project showcase, for patterns that designer friends had named as typical of AI: typefaces such as Inter, Space Grotesk, Instrument Serif and Geist, "VibeCode Purple", permanent dark mode with medium-grey body text, large coloured glows, glassmorphism, identical feature cards and more. Because a single pattern doesn't make a site an AI site for him, he counted how many of them a site shows. 22 per cent of the sites landed in the highest tier with four or more patterns, a further 32 per cent in the middle tier. Whether a site was actually built with AI is not what this measures, and Krebs himself estimates his check's false positives at 5 to 10 per cent.

The traits on this site

Now for the acid test. These are the traits JPKCom DB carries, and each has a good reason. Most of them come from the lists above. Four I classify as typical of AI myself, without any of the sources naming them that way: Instrument Sans as the sister of Instrument Serif from Krebs' list, the windows with three dots, the grid with a soft mask and the keyboard-shortcut search.

Trait	Where you see it here	The good reason behind it
Dark background with bright accents	Dracula in dark mode: `#282a36` with green, pink, purple	familiar from editor and terminal
Tinted near-black	code surface and header in `#191a21`	high contrast without pure black, matching the Dracula palette
Monospace for labels	Martian Mono in headings, byline, tags and buttons	separates controls from content; digits line up in columns
Typeface from the Instrument family	Instrument Sans in the body text, by the same designers as Instrument Serif	calm grotesque with a true italic
All-caps label	"ON THIS PAGE" above the table of contents	short label, quick to take in
Meta line with a middle dot	"by Jean Pierre Kolb · date" below the title	author and date on one line
Window with three dots	terminal windows around longer code blocks	language and copy button always in the same place
Grid with a soft mask	at the top of every page	structure without competing with the text; the contrast on it is tested
Frosted-glass header	dark mode: 90 per cent opacity with blur	orientation while scrolling
Purple accent	`#bd93f9` as the accent in dark mode and in the header's DB chip	Dracula purple, 5.90:1 on the dark page background `#282a36`
Chips and cards with a 1 px border	tags, overview cards, previous and next links below the article	groups you can skim quickly
Keyboard-shortcut search	"Ctrl+K" or "⌘K" in the search field	keyboard first, instant search across everything
Glow	only on the homepage, around the terminal window at the top	a single accent rather than many

What you won't find here: Inter, purple gradients on white, entrance animations for every section, emoji as icons, gradient text in headings. And the radius isn't the same everywhere: tag chips have 6 pixels, the DB chip and inline code 4, code blocks 8, terminal windows 12. That is less my merit than a consequence of the direction: the site was meant to look like a terminal, not like a startup landing page.

A side note with a twist: in its post, Anthropic suggested, among other things, taking inspiration from the colour schemes of integrated development environments (IDEs) as a way out of the uniform look, and named JetBrains Mono for a code aesthetic. Dracula is one of those colour schemes, and JetBrains Mono is what the diagrams here are set in. Yesterday's way out is itself a recognisable look today. That is my reading, not Anthropic's. But it shows how quickly patterns spread when a great many people use the same tools with the same guidance.

Why these preferences are not a flaw

First things first: the AI's preferences are not lapses in taste. They are the average of a great many good decisions. Almost every trait above goes back to a tool or a rule that became standard for a good reason:

Inter was designed for computer screens (opens in a new tab), with a tall x-height for better readability.
According to its documentation (opens in a new tab), Tailwind's colour palette was carefully crafted by expert designers, every colour in eleven steps. Spacing builds on a base unit (opens in a new tab) of 0.25 rem, or 4 pixels: p-4 sets four times that as padding, 1 rem. The result is a calm, even rhythm.
shadcn/ui, the component collection that Vercel's v0 (opens in a new tab) builds on, among others, relies on building blocks that take care of accessibility: Radix (opens in a new tab) and, by now, Base UI by default. Radix follows the WAI-ARIA patterns of the World Wide Web Consortium (W3C), the guidance for accessible controls, and handles roles, focus management and keyboard operation.
Lucide's icons, the default in shadcn/ui, follow strict rules for a consistent style.
Cards, chips, keyboard-shortcut search are patterns you know from many sites and programs. You don't have to learn what is familiar.
Dark themes are widespread among developers: in JetBrains' developer survey (opens in a new tab) from 2021, the dark editor theme is much more popular than the light one.

The skill states explicitly: all of these traits are legitimate for some briefs, they are just defaults rather than choices. Adrian Krebs sums up his analysis in a similar way: "Is this bad? Not really, just uninspired." After all, he notes, before the AI era "everything looked like Bootstrap", the widespread CSS framework.

So an AI design is rarely bad. It is predictable. It only becomes a problem where a default replaces a decision.

How to sharpen your eye

If you want to know whether a site was designed with AI, these five checks help:

Check the typeface: right-click on some text, "Inspect", then look at the computed font-family. Inter, Geist, Space Grotesk and Instrument Serif are strong indicators, but none of them is proof on its own. On this site, by the way, you'll find Instrument Sans, the sister of Instrument Serif.
Check the colours: indigo or violet as the accent, medium-grey text on a permanently dark background, a near-black background with a single bright colour.
Check the structure: identical cards with an icon on top, all-caps labels above every heading, numbered steps "01, 02, 03" where there is no sequence at all.
Check the details: frosted glass, large coloured glows, a "→" after every link, middle dots in meta lines. In my observation, three dots above code and a grid with a soft mask belong on the list too.
Ask the decisive question: does this fit the subject of the site, or would it look exactly the same on any other?

No single trait proves anything. A cluster of them does. And the fifth point is the most important one: Anthropic's skill describes the traits in exactly that way, as things that appear regardless of the subject. For JPKCom DB my answer is: the terminal look fits a site full of commands and code. It is a default I chose deliberately.

My verdict: pros and cons

What speaks for AI in the redesign:

Speed. Two days to the merge, including specification, tests and several reviews.
Thoroughness. Every important colour pair is recomputed, every task that changed code was reviewed, and the final review produced 31 findings. That is the kind of work that often falls short in a rebuild this big.
Documentation as a by-product. Specification, plans and the new DESIGN.md came into being while building, not as a tedious chore afterwards.
Verifiably better accessibility. A test now recomputes every load-bearing colour pair. Reduced motion used to exist only in the documentation; now it is implemented. Support for Windows High Contrast mode and focus that never disappears under the header didn't exist before at all. Only the visible focus outline was already there, and for secondary text in dark mode the headroom has become smaller.

What speaks against it, or at least calls for caution:

Interchangeability. Anthropic itself writes that the generic AI look makes interfaces immediately recognisable, and that this makes them easy to dismiss. In its trend outlook for 2026 (opens in a new tab) (German), the German design magazine PAGE sees a counter-movement to AI smoothness: brands need to send signals people can trust, meaning clarity instead of output volume and closeness to a community instead of a uniform look. My antidote is the old brand colour as the accent, my logo and content from my own practice.
Snap judgements. Some visitors will probably pigeonhole the site quickly because of its look. The only remedy is checked content and full transparency.
The AI makes mistakes too. Two were its own doing, and it found both itself: its own measurement matrix missed the overflow at 320 pixels, and its follow-up check caught it. Tailwind read the whole repository, including the specification and the plans with their quoted old class names, and shipped rules for roughly 140 dead colour classes as a result; after the fix the built CSS shrank from 94 to 68 KB.
The AI doesn't see everything. Two further bugs were side effects of the font switch. No measurement caught them; I found them: the shifted diagrams and the cut-off "10.". Automated checks don't replace eyes.

FAQ

Was JPKCom DB built entirely by AI? No. The site, its structure and its topics are my own work. Claude Code carried out the redesign to my specifications; direction and approvals came from me. The content is also created with AI support to varying degrees, and the responsibility lies with me. Details are on the AI transparency page.

Which AI carried out the redesign? Claude Code by Anthropic. Claude Opus did the coordination in two sessions, one per day, linked by a written handover; sub-agents running Claude Sonnet carried out and checked most of the individual tasks. Direction and approvals came from me.

Why are code blocks dark in light mode too? Because code here should always look like it does in the terminal, and because fixed colours are safer there: switching colours would fall below the contrast limits on the dark code surface. That way the syntax colours only have to hold the AAA level of 7:1 on a single surface.

Why not Alucard, the official light Dracula theme? The accent in light mode is the colour the site already had. With a derivation of my own, light mode stays closer to my brand than with the Alucard palette.

Can I set light or dark permanently? Yes, with the switch in the footer: the system theme (screen icon) follows your system, light (sun) and dark (moon) are fixed. Your browser remembers the choice.

What is the quickest way to recognise an AI design? By how many of them come together: typeface, colour, cards and small details such as middle dots in meta lines or a "→" after every link. And by asking whether the design fits the subject or would look the same on any site.

Conclusion

The JPKCom DB redesign is a redesign by AI, and it is allowed to look like one. I set the direction, reviewed, rejected, found bugs and approved. Claude Code did the work that takes a lot of time in a rebuild this big: inventory, specification, implementation, contrast tests and reviews.

The result is a site with tested contrast in both modes and no sideways scrolling on phones from 320 pixels up, and one that is just as readable for machines as before. And a site that doesn't hide where it comes from. If, after this article, you suddenly start noticing the all-caps labels, the middle dots and the glowing purple on other sites, it has done its job as a teaching example.

The traits of AI design are not a flaw. They are good practice, distilled. All that matters is that behind the default there is someone who chose it.

Sources

Dracula Theme: specification (opens in a new tab): colour values of Dracula and Alucard
Anthropic: Improving frontend design through Skills (opens in a new tab): distributional convergence
Anthropic: frontend design skill, the version summarised here (opens in a new tab): list of AI design traits; the current version (opens in a new tab) may differ
Adam Wathan on bg-indigo-500 (opens in a new tab)
Adrian Krebs: Scoring Show HN submissions for AI design patterns (opens in a new tab)
Nielsen Norman Group: Dark Mode vs. Light Mode (opens in a new tab)
PAGE: UX-Design-Trends 2026 (opens in a new tab) (German)
W3C: Understanding WCAG 2.2 (opens in a new tab)

Before publication, this article went through two rounds of an adversarial factual review: every verifiable claim was tested with the goal of refuting it. More than 60 passages did not survive unchanged, among them a wrong order of events and a claim about screen readers that contradicted the source code of WebKit, the engine behind Safari.