I use AI. Every day.

To be clear: This post is not a plea against AI. I use it myself every day, for programming, structuring ideas, and checking texts. Anyone who doesn't do this as a developer today is falling behind.

The question is therefore not, whether one uses AI, but how. When it comes to the internet, we have been talking about media literacy for years: Not believing everything that is on a website, checking sources, understanding contexts. We need exactly the same skills now in dealing with AI, and developers are not exempt from this.

Vibe Coding, YOLO mode, and Co.

Around AI-supported programming, several terms have emerged in a short time:

• Vibe Coding: The term comes from Andrej Karpathy (early 2025). It means generating code via prompt and adopting it without really reading it. If it works, it's good. If it doesn't work, you ask the AI again.
• YOLO mode: Many AI tools can make changes independently, without asking beforehand. Files are written, commands are executed, everything goes through.
• “Accept all”: Accept all AI suggestions at once, without looking at them individually.

For a hobby project on the weekend, that's perfectly fine. You try something out, learn from it, and if it breaks, no one is affected.

With a corporate website, it's different. There, inquiries, revenue, and trust are at stake. A site that crashes after three hours or during the next update is not just a cosmetic flaw, but a problem for the operation.

What is in AI-generated website code

In one of my projects, there was initially a website draft that had been created with AI. The first version was unstructured and hardly maintainable. However, the more interesting part are the errors that were still present in later, seemingly clean versions. The following examples come from real code, anonymized.

Fabricated content

The most dangerous problem was not technical. On one page, there was a customer testimonial with a first name and age. The same person had actually given feedback elsewhere, but with completely different content. The AI had rewritten the quote to fit the theme of the page and attributed it to the real person.

For the operator, this is tricky: Fabricated customer testimonials undermine trust and can have legal consequences.

Similar with claims: The text stated "confidential and GDPR-compliant," while the page simultaneously loaded documents from Google servers, thereby transferring visitor data to third parties. And in the footer, a legal form appeared that no one had specified.

Instructions in the visible text

A heading simply read "In a paragraph." That was not a heading, but an instruction from a marketing scheme that the AI had adopted as content. Elsewhere, a placeholder read: "Send me the wording, and I will insert it here." The AI spoke with the client, not with the visitor. On a live page, such things quickly appear unprofessional.

Placeholders that could go live

• Links with href="#" in WhatsApp, imprint, and data protection. They look like links but lead nowhere.
• The company logo as a substitute for a portrait photo, with the alt text "Portrait of ...".
• A standard placeholder image from the CMS as a "quality seal."

Individually, these are minor details. Together, they create a page that looks finished at first glance but is not.

Conflicts with the CMS

The design directly shaped elements like body, header, footer, h1 and a. In a standalone HTML file, this works. However, once the code is integrated into a CMS like Odoo, which brings its own headers, footers, and styles, it overrides these across the entire website. The result: menus shift, font sizes change in places that no one has touched.

Inconsistencies

The same button (“Start check”) once led to the actual domain and once to a technical subdomain of the host. “Book appointment” pointed to the appointment booking in one place, and to the contact form in two others. And the same long link was hardcoded six times in the code. If the target changes, you have to find all six places. If you miss one, visitors end up in a void.

In addition, there were inline styles in the middle of the HTML and class names like .ph, .q or .w, where in three months no one will remember what they stand for.

Why “just keep building” becomes expensive

None of these errors are noticeable when you view the page once in the browser. They become apparent when a customer clicks on a link that doesn’t work. When the CMS gets an update. When the page is to be translated into a second language. Or when someone recognizes the customer voice.

Auf einem solchen Entwurf aufzubauen bedeutet, jedes dieser Probleme mitzunehmen und mit jeder Änderung neue hinzuzufügen. In meinem privaten Projekt war es am Ende schneller, den Entwurf als visuelle Vorlage zu nutzen und den Code sauber neu aufzubauen.

The responsibility remains with the developer

This is the core for me: AI writes code, but it bears no responsibility for it. That responsibility lies with the developer. He must understand the code he delivers and ensure that it meets quality standards. This means specifically:

• Every line that goes into a client project is read and understood.
• Content such as quotes, numbers, and claims are checked against the source.
• The code fits the system in which it runs, not just the browser window.
• The page is tested before it goes live, not after.

AI makes me significantly faster at many tasks. But the time saved partly goes into this testing. That's not extra effort, that's the job.

Before and after: an example

This is what a typical section in the draft looked like (simplified, with example domain):

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Before</title>
<style>
  body { margin: 0; font-family: "DM Sans", Arial, sans-serif; color: #3a302c; }
  header { position: sticky; top: 0; background: #faf6f1; padding: 12px 20px; }
  h1 { font-size: 3rem; margin: 0; }
  a { color: #9a5f59; }
  .btn { display: inline-block; background: #b5766f; color: #fff; padding: 13px 22px; border-radius: 999px; text-decoration: none; }
</style>
</head>
<body>
<header>Logo</header>
<section style="background:#f6ebe7;padding:54px 20px">
  <h1>More Energy in Everyday Life</h1>
  <a class="btn" href="https://kunde.hoster-beispiel.com/survey/start/3f2a9c71-0b4e">Start Check</a>
  <a class="btn" href="https://www.beispiel-kunde.be/survey/start/3f2a9c71-0b4e">Start Now</a>
</section>
</body>
</html>

The problems: body, header, h1 and a apply to the entire website, the design of the section is embedded inline in the HTML and the same link is stored differently twice.

This is what the same section looks like when structured cleanly:

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>After</title>
<style>
  .kd {
    --kd-ink: #3a302c;
    --kd-soft: #f6ebe7;
    --kd-accent: #b5766f;
    font-family: "DM Sans", Arial, sans-serif;
    color: var(--kd-ink);
  }
  .kd-hero { background: var(--kd-soft); padding: 54px 20px; }
  .kd-hero__title { font-size: 3rem; margin: 0 0 24px; }
  .kd-btn {
    display: inline-block;
    background: var(--kd-accent);
    color: #fff;
    padding: 13px 22px;
    border-radius: 999px;
    text-decoration: none;
  }
</style>
</head>
<body>
<div class="kd">
  <section class="kd-hero">
    <h1 class="kd-hero__title">More Energy in Everyday Life</h1>
    <a class="kd-btn" href="/check">Start Check</a>
    <a class="kd-btn" href="/check">Start Now</a>
  </section>
</div>
</body>
</html>

What has changed:

• Own namespace: All styles depend on the prefix kd- and apply only within .kd. Odoo's own header and footer remain untouched.
• Colors as variables: A color change happens in one place, not in twenty.
• No inline styles: Design is in the CSS, content is in the HTML.
• One link, one target: Both buttons point to /check. In Odoo, you set up a redirect once (Website › Configuration › Redirects) from /check to the actual form. If the target changes, you only need to adjust this one redirect.

Note: I usually pull styles into a separate file for Separation of Concerns. 

„Separation of Concerns (Separation of concerns) is a principle of software development, where a program is divided into separate sections so that each area solves exactly a specific task – such as structure, design, or logic – independently."

Checklist: If you have an AI draft

You have created a website draft with ChatGPT or another tool and are considering building on it? You can check these points even without programming knowledge:

1. Click every link. Does it lead where it should? Does it lead anywhere at all?
2. Check every quote and every number against the source. Did the person really say that? Is the number correct?
3. Look for placeholders. Words like "placeholder", "example", "Lorem ipsum" or sentences that address you instead of visitors.
4. Check legal information. Company name, legal form, imprint, data protection. None of this should be invented by the AI.
5. Test on the phone. Many designs only look good on the large screen.
6. Dare to make a small change. Let a color or button text be changed. If it requires searching in many places, the code is not a good foundation.

Conclusion

AI is an excellent tool for quickly making an idea visible. A generated design is a good sketch and a good basis for discussion. It only becomes a foundation for a business page when someone has understood, checked, and built it cleanly.

I use AI to work faster. But I only deliver code that I understand and can stand by.

Do you have an AI design and are unsure if it can be built upon? Or do you want to place your website on a clean foundation right away? I would be happy to take a look at your project:

Request project