KI und WordPress WP Meetup Hamburg #140

Chapter 11

The middle ground

The question is not "AI or WordPress". It is: who may change this site in two years, and with what?

  • He does not abolish the CMS. He rebuilds it, for one client, alone.
  • WordPress runs anywhere: if a host gets too expensive, you move. With everything.
  • And if you are gone tomorrow, your client finds somebody who knows it.
  • The normal case is the middle: the client does text and images, we do the rest.
  • Bricks components as blocks, Etch, PHP blocks in core — templates with guardrails.

The AI builds the pieces. WordPress holds the frame, the permissions and the handover.

It is not about the framework

Which tool wins is the wrong question. There are three that count — and they are best asked before you commit to anything.

  • Maintainability: can somebody else change it?

    Not "can I change it". Can somebody who was not there change it, a year from now, without phoning me? Names in the markup and values in the token system are not a matter of taste — they are the answer to exactly that question.

  • Scalability: does the fiftieth page cost what the first did?

    If every new page needs fresh decisions about spacing, colour and variants, it does not scale — it gets more expensive with every page. If the pieces are settled, a new page is only: pour in the content.

  • Access: who can even get in?

    Not accessibility in the WCAG sense, but the plain question: who may publish, and can they? One person with a Git account and a deploy process — or anyone on the team who can log in? That decides whether a site stays alive or freezes.

  • And that is exactly the offer

    Set it up properly once: templates, components, roles, permissions. Then write and publish as often as you like, without anybody touching code. The effort sits at the start rather than in every single post — that is the whole bargain, and it is twenty years old.

Two ways to write the same card

On the left is what actually ships. On the right is the same element, with names for its parts. Both work. Only one of them can still be read in a year.

Without names — what the AI built
<div class="flex h-full flex-col justify-start gap-3.5">
  <div class="flex size-10 shrink-0 items-center
    justify-center rounded-full bg-gold/[0.18] text-gold">
  <span class="flex w-full flex-col before:absolute
    before:inset-0 before:content-['']">
    <h3 class="font-sans text-[19px] leading-6
      font-semibold text-white">Bessere Qualität</h3>
    <span class="mt-3.5 font-body text-sm
      leading-[23px] text-white/70">…</span>
With names — the same piece
<article class="feature-card">
  <div class="feature-card__icon">…</div>
  <h3 class="feature-card__title">Bessere Qualität</h3>
  <p class="feature-card__text">…</p>
</article>

A framework like ACSS takes the decision off your hands: consistent spacing, consistent colour, checked contrast — at the price of every site resembling the next, down to the identical icons. Utility classes take nothing off your hands: total freedom, and afterwards nobody knows what an element is. The middle is unspectacular: your own names for your own pieces, values from the token system. Then the markup says what a thing is, and the values say how it looks.