Deryk King

Need marketing help? Contact Brafton here.

I’ve been building websites for over 20 years, and lately I keep getting this nagging feeling that I’ve seen all of this before.

I’ll open up a new site that somebody built with AI. There’s a little pill of text above the headline. A big bold headline. Two buttons, centered. Then three cards with icons in them, and every single thing on the page fades up from the bottom as I scroll.

Then I open the next one. Same thing, different logo.

I’ve been here before. Around 2015 it was premium WordPress themes, Bootstrap and a jQuery plugin for everything. The tools are different now, but the problem is exactly the same: everyone is starting from the same place and nobody is making real design or development decisions.

The way out is the same too. Premium themes weren’t the problem in 2015, and AI isn’t the problem now. What matters is who’s using them and what they bring to the table.

The First Time Around: Themes, Bootstrap and jQuery

If you built sites in the mid 2010s, you remember the multipurpose theme. Avada, Enfold, BeTheme, Bridge, X. You bought one on ThemeForest for well under a hundred bucks and got a few dozen demo sites with it. Avada alone has sold over a million copies.

Here’s how most of those sites got built: Import the demo. Swap the logo. Change the accent color. Replace the lorem ipsum. Launch. The content got poured into the template instead of the template being built around the content.

Under the hood it was almost always the same stack:

  • Bootstrap for the grid, so every site had the same 12 columns, the same breakpoints, the same navbar collapse and the same buttons. You could spot a Bootstrap site from across the room.
  • jQuery for everything that moved, plus a plugin for every feature. A slider plugin, a lightbox plugin, a parallax plugin, a sticky header plugin. It wasn’t unusual to find jQuery loaded two or three times on one page because different plugins each brought their own copy.
  • Slider Revolution bundled right into the theme, which is why every homepage had a giant rotating hero banner.
  • Animate.css and WOW.js so you could pick “fadeInUp” from a dropdown on every block in the page builder. And people did. On every block.

The sliders are the one that still gets me. Clients asked for them constantly, not because they solved anything, but because every other site they looked at had one. The data never backed it up. A well known test on the Notre Dame homepage found the carousel got about 1% click through, and 84% of those clicks were on the first slide. Nobody was waiting around for slide four. We built them anyway, over and over, because “that’s what websites look like.”

The fade-ins were the same story. One nice reveal on a hero can feel polished. Every paragraph, image, icon box and footer column sliding in from below just makes the site feel slow and makes users wait for content that was already there.

It wasn’t just a style problem either. All those bundled plugins meant old, vulnerable versions sat on live sites for years. In 2014, a Slider Revolution flaw was behind the SoakSoak attack that hit over 100,000 WordPress sites, largely because theme bundling kept site owners from updating it.

The Second Time Around: AI Design and Development

Now fast forward to today. The tools are Claude, ChatGPT, Lovable, Bolt and whatever launched last week. You type one sentence describing your business and get a full site back in a minute.

And it looks like this:

  • A little eyebrow pill above the headline that says something like “Now in beta” or “Trusted by 10,000+ teams.”
  • An oversized headline, usually Inter or a big italic serif.
  • Two centered buttons, one solid, one outlined.
  • A purple to blue gradient or a soft glow behind it all, often in dark mode.
  • A three- or six-card feature grid, each card with a little icon chip in the corner.
  • A 01 / 02 / 03 “how it works” row.
  • A logo marquee scrolling forever, and testimonials signed “Sarah K.”
  • Count up stats that animate from zero to a number nobody can source.

Then the motion. Every section fades up from about 20 pixels below, over about 300 milliseconds, with the exact same stagger between children. Every card lifts and casts a shadow on hover, even when it isn’t clickable. The headline has a shimmering gradient that never stops. Content below the fold animates on page load before you ever scroll to it.

And it’s not just what you can see. Look under the hood and the code is just as predictable. Ask AI for a five-page brochure site and you’ll often get React, Tailwind, shadcn, Framer Motion and a full build pipeline. That’s the 2026 version of loading Bootstrap and a dozen jQuery plugins for a site that needed a grid and a contact form. The stack gets picked by habit, not by what the project actually needs.

Swap in the client’s brand colors and logo and you have a “custom” site. Sound familiar? It’s the theme demo import all over again. The only things that changed are the fonts and the speed.

AI Doesn’t Design. It Remembers.

This is the part I think a lot of people miss. AI isn’t inventing a new look. It’s handing you back the average of everything it was trained on.

And what was it trained on? Mountains of public code. A huge share of modern front-end code on GitHub is Tailwind, shadcn style components, Framer Motion and a handful of popular UI kits. So when you don’t tell the model exactly what you want, it fills every blank with the most common answer it’s seen.

The Tailwind story is my favorite example. Adam Wathan, who created Tailwind, joked in 2025 that making every button in Tailwind UI bg-indigo-500 is the reason every AI generated interface on earth is now indigo. A placeholder color became the default brand color for half the internet.

Even Anthropic, who makes Claude, has written about this. They call it “distributional convergence”: left alone, models reach for Inter, purple gradients on white, and safe, generic layouts.

That’s the same thing that happened with themes. Back then, the defaults were picked by a few theme authors and we all bought the same ones. Now the defaults are picked by nobody. They’re just the statistical middle of the web.

It also feeds itself. AI sites go live, they get scraped, and they become training data for the next model. Every round, the middle gets a little narrower.

There’s one big difference that worries me more this time. With a theme, you could see the demo before you bought it. You knew what you were getting. AI sameness shows up looking like a custom build, so a lot of clients have no idea their new site looks like thousands of others.

The Tech Moved On. The Habits Didn’t.

What makes this funny to me is how much the actual technology changed in between. JavaScript went from a thing you sprinkled on a page to the thing the whole page was built on. React, Vue and the rest took over. jQuery went from being on basically every site to being something you rip out during a rebuild. Most of what we used plugins for back then, CSS just does now. Grid and flexbox replaced the Bootstrap grid. Transitions, keyframes and scroll driven animations replaced half the animation libraries. position: sticky replaced the sticky header plugin. Native <dialog> replaced the modal plugin.

We got better tools for doing original, lightweight work. And we used them to rebuild the same template.

The pattern was never really about jQuery or Bootstrap. It’s about what happens any time there’s a shared starting point and a process that rewards speed over thinking. In 2015, that was a theme demo. In 2026, it’s a prompt.

Same Tools, Different Hands

Here’s the part that gets lost when people talk about “AI slop.” Most of the sameness comes from how the general public uses these tools, not from the tools themselves.

That was true with themes too. The business owner who bought Avada, imported a demo and swapped the logo got a site that looked like everyone else’s. That’s not a knock on them. They wanted a website, not a design process, and the theme gave them exactly that.

But plenty of great sites from that era were built on the same stack. Experienced designers and developers used Bootstrap, jQuery and even premium themes as a starting point and then took them somewhere. They knew which defaults to throw away, which patterns actually worked for users, and where a site could break from the norm. Same tools. Completely different result.

AI is the same thing, turned way up. In the hands of someone with no design or development background, it does what it was built to do: it creates the most likely website. In the hands of someone who has spent years watching these trends come and go, it becomes something else. It becomes a way to push creative and development limits and create a more robust and efficient experience.

When you know the patterns, you can tell the model to avoid them. When you know why a pattern exists, you can bend it instead of copying it. And when you have an actual idea, like a layout you haven’t seen before, an interaction that fits the brand, or motion that tells a story, AI lets you prototype it in an afternoon instead of a week. You can try five versions, throw out four, and push the fifth further than you ever had time for before.

That’s the real difference. The general public uses AI to create a website. Experienced designers and developers use AI to push one. The model brings the speed. The person brings the taste, the experience and the idea. Put those together and you can build something that’s actually new.

The Developer’s Side of This

The design side gets most of the attention because it’s the part you can see. But I’m a developer first, and the development side is where the “same tools, different hands” idea matters most. It’s also where the risks are a lot less obvious.

I Pick the Stack, The AI Executes

When I build with AI, I tell it what to use. Sometimes that’s a library or package I know well and know is the right fit for the job. Other times I have it build something bespoke that does the one specific thing I need and nothing else.

Reinventing the wheel gets a bad rap. But when I only need one small piece of someone else’s wheel, building exactly that piece is the smarter move. Less code, fewer dependencies, and nothing extra to patch later.

I love golf, so here’s how I think about it. Pulling in a giant library for one small feature is like carrying your whole bag onto the green when all you need is your putter. You’re not hitting a driver from three feet. Take the club the shot needs and leave the rest in the cart.

Left on its own, AI grabs the whole bag every time. It’ll install a scroll animation library when CSS scroll driven animations would do the job, a modal package when native <dialog> is right there, or a carousel nobody asked for.

AI Makes Up Packages, and Someone is Waiting for Them

This one ties right back to picking your own stack, and it’s the one that worries me most.

AI doesn’t just pick bloated packages. Sometimes it recommends packages that don’t exist. Researchers from UT San Antonio, Virginia Tech and the University of Oklahoma tested 16 code models across 2.23 million code samples. Almost 20% of the samples recommended at least one package that wasn’t real, which added up to over 205,000 made up package names. Worse, 43% of those fake names came back every single time the same prompt was run again.

That makes them predictable, and bad actors noticed. The attack even has a name now: slopsquatting. You register the package name the AI keeps making up, put malware in it, and wait. In early 2026 Aikido Security found a package on npm called unused-imports, a made up lookalike of a real ESLint plugin. It carried a script that steals API keys, cloud tokens and npm credentials the moment you install it, and it was still pulling hundreds of downloads a week.

Here’s the scary part. A security researcher once registered a fake package called huggingface-cli as a harmless test, and it got over 30,000 downloads in three months. Alibaba had copied the AI suggested install command straight into one of its public READMEs.

This is the SoakSoak problem all over again, just faster and harder to see. A developer checks whether a package is real, who maintains it and when it was last updated. The average user takes whatever the AI says at face value and runs it.

If You Can’t Explain It, You Can’t Maintain It

We’ve all inherited a site where someone edited the theme files directly, and every update broke everything. AI code that nobody on the team understands is the same tech debt, just produced a lot faster. If you can’t explain it, you can’t maintain it, and you definitely can’t secure it.

The Bells and Whistles, for Less

This is the part I’m most excited about. Clients have always wanted the big stuff: custom interactions, slick transitions, the things that make people stop scrolling. For most budgets, those used to be the first thing cut.

Now I can prototype a View Transitions effect, a WebGL hero or a custom Gutenberg block in an afternoon instead of a week. And because I know how it should be built, it comes out lean and maintainable instead of a pile of packages. I can give a client what they really wanted, all the crazy bells and whistles, for less, because I can build it faster.

That’s what experience plus AI looks like. Not a faster way to make the same site, but a way to finally build the one the client was picturing in the first place.

How to Use AI to Push Instead of Just Produce

I’m not anti-AI. I use it every day, and it’s the best tool I’ve had for taking an idea further than I could on my own. But it’s a tool for building, not for deciding, and it only pushes as hard as the person behind it. Here’s what I’d tell any team using it for web work:

  1. Make the design decisions before you prompt. Pick the typefaces, the hex colors, the spacing and the layout references up front. Every choice you leave out, the model fills with the average.
  2. Write down what you don’t want. No eyebrow pills, no three-card row, no indigo, no fade up on every section. A short “never” list goes a long way.
  3. Start from real content. Real copy and real photos push a design somewhere specific. Placeholder content always drifts back to the template.
  4. Give every animation a job. Good motion gives feedback, shows a change of state, or helps people understand where something came from. If removing an animation loses no information, it’s decoration. Keep one deliberate moment per page, tops.
  5. Respect reduced motion. Ship prefers-reduced-motion support on every build. People who turn it on in their OS often get dizzy or sick from parallax and scroll effects.
  6. Tell it what to build with. Name the libraries you trust, or tell it to write the one small piece you need. Don’t let it grab the whole bag.
  7. Check every package before you install it. Make sure it exists, who maintains it, how many people use it and when it was last updated. Never paste an install command you haven’t checked.
  8. Use your experience in the prompt. Name the patterns you want to avoid, the references you want to pull from, and the reason behind each choice. The more you know, the less the model has to guess.
  9. Explore with the speed, finish by hand. Generate several different directions, pick the strongest one, and refine it yourself. Let AI do the heavy lifting, not the deciding.
  10. Do the squint test. Put your homepage next to two competitors and a default AI site. Squint. If you can’t tell which one is yours, keep going.
  11. Push back on “I saw it on another site.” That’s how we ended up with a slider on every homepage. Ask what the thing is supposed to do, and whether there’s any proof it works.

We Already Know How This Ends

The theme era didn’t end because someone banned sliders and premium themes. It ended because people got tired of it. Sites that looked like everyone else’s stopped standing out, and clients started asking for something that felt like them.

The same thing is going to happen with AI built sites. The eyebrow pill and the indigo glow are going to look as dated as a Ken Burns slider with a preloader spinner in front of it.

The sites that hold up will be the ones where a person made the calls and used the tools to carry them out. That was true in 2015 and it’s still true now.

What’s different this time is how far that person can go. A designer or developer who knows the history, knows the patterns and shows up with a real idea can use AI to build things that just weren’t practical a few years ago. That’s the exciting part. The tool was never the problem. It’s what you bring to it that counts.

Sources