The Homogenization Problem: When Show HN Looks Like One Big Template
Source: hackernews
There is a particular aesthetic that has come to dominate a huge swath of new web projects: dark background, purple-to-indigo gradient hero, glassmorphism cards, an Inter or Geist font, a “Features” section laid out in a three-column icon grid, and a pricing table with one tier badge that reads “Most Popular.” If you have spent any time scrolling through Show HN submissions over the last eighteen months, you have seen this layout hundreds of times. It is not a coincidence, and it is not plagiarism. It is the natural output of a generation of apps built with the same AI-assisted scaffolding stack.
A recent project by Adrian Krebs, documented on his blog, takes a systematic look at this phenomenon. He built a scoring system to quantify how many AI-typical design patterns appear in Show HN submissions. The piece landed 289 points and over 200 comments on Hacker News, which tells you the community recognized something true in it.
What Makes a Design Pattern “AI-Typical”
The term “design slop” is borrowed from the broader discourse around “AI slop,” the label applied to low-effort, indistinguishable AI-generated content. For images, slop has recognizable tells: extra fingers, melting text, impossible reflections. For UI design, the tells are different but equally consistent.
The canonical AI-assisted web app in 2025-2026 reaches for the same toolkit almost automatically. shadcn/ui provides components. Tailwind CSS handles styling. Next.js is the framework. Vercel handles deployment. These are all fine choices individually, and together they form a stack that any AI code generator will reach for by default because that is what the training data is saturated with.
The design patterns that emerge from this stack are not random. They cluster around a handful of choices:
- Gradient backgrounds anchored somewhere in the violet-blue-indigo range
- Card components with subtle border and backdrop blur
- Section dividers that use a slight opacity shift rather than a hard line
- CTA buttons in solid purple or teal
- Testimonial grids with circular avatar placeholders
- Feature icons from Lucide or Heroicons
Scoring these programmatically is a tractable problem. You can fetch the deployed URL, parse the rendered HTML and computed styles, and check against a rubric. Color histogram analysis can flag the gradient bias. Font detection catches the Inter monoculture. DOM structure analysis can identify the three-column feature grid pattern. Screenshot-based vision model scoring is another route: you feed a screenshot to a multimodal model and ask it to rate how much it looks like “an AI-generated SaaS landing page” on a 1-10 scale.
The interesting engineering question is which approach gives the most signal. Pure DOM/CSS analysis is deterministic and fast but brittle, since a project could use bespoke CSS that produces the same visual output without using Tailwind utility classes. Vision-based scoring is more robust to implementation details but introduces model variance and cost. A hybrid approach, checking for structural markers first and falling back to screenshot analysis for edge cases, is probably the right architecture.
Why Show HN Specifically
Show HN is a useful dataset for this analysis because it has a shared intent: these are things people built and are proud enough of to show. The signal-to-noise ratio is higher than, say, a random sample of newly registered domains. Most Show HN posts have a live demo link. The submissions cluster around certain categories, SaaS tools, developer utilities, side projects, which means you are comparing somewhat like to like.
The community has also developed an informal aesthetic sense over decades of exposure to indie hacker projects. Older Show HN submissions often had rough, idiosyncratic design, sometimes ugly, but visually distinct. A Rails app from 2014 had a particular look. A Python Flask project from 2017 had another. The design choices reflected the builder’s taste, however limited. What Krebs is quantifying is the degree to which that individuality has eroded.
This is not purely a quality argument. A well-designed SaaS landing page built with shadcn/ui and Tailwind can be excellent. The issue is signal degradation: when everything looks the same, it becomes harder to use visual presentation as a proxy for the care and thought a builder put into their project. A polished-looking landing page used to imply a certain level of investment. Now it implies running a prompt through Cursor or Bolt.
The Stack That Ate Indie Design
The homogenization has a specific origin point. Tools like Bolt, Lovable, and v0 are explicitly designed to generate full-stack web applications from text prompts. They are trained on or fine-tuned for the modern JS ecosystem, which means they default to Next.js, Tailwind, and component libraries that have good documentation and wide adoption. The design output is consistent because the generation process is consistent.
This is a feedback loop. The tools generate code in a particular style. Developers ship projects in that style. The style becomes ubiquitous. Future training data includes more examples of the style. Future model outputs lean even harder into it.
There is a parallel in content generation. When large language models write blog posts or marketing copy, the output has recognizable texture: certain transition phrases, a preference for numbered lists, a particular rhythm of paragraph length. Readers have developed an informal ability to detect it. The same thing is happening with AI-generated UI.
The Scoring System as a Mirror
What makes the Krebs project interesting beyond the novelty is that a scoring system like this, applied at scale to Show HN submissions, is essentially a quantitative version of something the community was already doing qualitatively. HN commenters regularly note when a project looks like it was “vibe-coded” or when the landing page was clearly AI-generated. The scoring system just operationalizes that judgment.
This has practical implications. You could imagine a browser extension that scores a Show HN submission before you click through, giving you a rough estimate of whether the project is a carefully built tool or a scaffold with a thin feature layer on top. You could use it to filter a corpus of Show HN submissions for research purposes. You could run it retrospectively over years of data to map the inflection point where the design monoculture took hold.
Running this kind of analysis also surfaces what the exceptions look like. Projects that score low on the AI design pattern rubric tend to have idiosyncratic CSS, non-standard component choices, or visual design that reflects a particular builder’s taste. Sometimes that means they look worse by conventional standards. But it often correlates with projects that have a clearer point of view and more genuine technical depth.
Where This Leaves Us
The tools that produce design slop are not going away. The speed advantage of scaffold-and-iterate development is real. For many categories of project, shipping a slightly generic-looking tool quickly is the right call. Not everything needs to be a design statement.
But the community absorbing this and developing better filters for it is a healthy response. Scoring systems, community norms around labeling vibe-coded projects, and growing aesthetic literacy around what AI-generated design looks like are all part of adapting to the new environment.
For developers who build with these tools and want their work to stand out, the implication is straightforward. The default output of any AI scaffolding tool is a floor, not a finished product. Customizing past the defaults, on typography, color, layout rhythm, or component behavior, is now the minimum effort required to signal that a human made meaningful choices about the presentation of their work. That bar has shifted, and projects that do not clear it increasingly blend into a background of indistinguishable purple-gradient SaaS scaffolding.
The irony is that the tools themselves could help with this. Prompting Bolt or v0 with explicit instructions to avoid the shadcn defaults, to use an unusual color palette, to skip the standard testimonial section, produces more distinctive output. The monoculture is partly a prompt engineering failure. Most people accept the first output.