I'm not a fan of 'vibe coding'. Yet this website was made that way.

Honestly: the term vibe coding always grated on my ears a little.

The idea that someone talks to an AI until something comes out that works, without really knowing why: for a developer that’s what instant coffee is to a barista. It comes out. Whether it tastes good is another question.

And yet: the website you are reading now, including all the documentation of our framework and the base modules of the ERP system, was built entirely by AI, without a single line of code (HTML, CSS, JavaScript) written by hand. That is the new trend: vibe coding, the word of the year in 2025.

The reason was practical. On our old Wix website we couldn’t keep the documentation of our software products automatically up to date, even though it is precisely that documentation that matters for supporting our clients.

How I went about it

I started with an extensive briefing for Claude Code (the AI assistant we work with daily); the reason for the migration, a reference to our old website, and the boundaries within which it had to happen.

A look under the hood: our boundaries; what we do and don’t want

On one side, boundaries about what we don’t want:

accidentally publishing the full source code or leaking other confidential information (this happened to the company behind Claude Code)
publishing incorrect code or broken links that break the website
syntax or grammar errors in written texts

On the other side, boundaries about what we do want:

preserve the structure and content of our old Wix website
a consistent house style, captured in a separate brand document
extensive search engine optimization and AI optimisation
explicit rules for selecting documents to publish from our Java software

Within these boundaries, Claude worked out a proposal for the technology and tooling. With my technical background I of course questioned those choices, but in the end, convinced by good arguments, I adopted Claude’s advice one-to-one.

The first version was disappointing. Only after my explicit instruction to look at the old Wix website visually from a browser did something usable come out.

After that we tackled all the technical and content issues together. I didn’t give instructions on what Claude should change, only points I was unhappy about. Based on that, Claude came up with one or more proposals to improve them, and carried them out on request.

But it also works the other way around, simply asking Claude what is still missing from the website or what could be improved. Claude compiles a clear list and, if desired, picks up each point entirely on its own. Both structural improvements, such as splitting up the vacancies page, and the syntax and grammar errors that always creep in anyway.

A look under the hood: Claude’s advice

Hugo to turn loose text files into a complete website
GitHub to store the source code
Cloudflare to put everything online
Resend to deliver contact-form messages to our mailbox

For me, mainly a matter of creating the right accounts. And Claude is helpful there too, for example with an instruction for the required DNS changes at my specific internet provider.

The result

The result is this website, with branding and content comparable to the Wix original. I edit the content locally, with Claude’s help where needed, and see the result immediately in my browser. With a single command (git push) it’s online, fully under version control.

More importantly: the documentation of our software now comes straight from the Java source code. Whatever the developers update there is on this website too after a sync. No manual work, no outdated documentation. That was exactly what we were after.

And the best part: everything is plain text, even the formatting.

A look under the hood: an AI that makes its own tools

The scripts that pull the documentation from our Java source code and place it on the website, plus the working instructions that let a next AI session use them flawlessly (skills in AI jargon), were written by the AI itself.

A fragment from the sync script: filtering out files we do not want to publish.

  while IFS= read -r -d '' src; do
    local name; name="$(basename "$src")"
    local rel="${src#$doc_root/}"

    # Skip junk files anywhere in the tree.
    [[ "$name" == "___index.asc" ]] && continue
    [[ "$name" == ".asciidoctorconfig.adoc" ]] && continue
    [[ "$name" == wip_* ]] && continue

    # Skip the subtree's top-level index.asc/_index.asc when configured to —
    # the manual root index for the domain manual is the PDF book entry
    # point and should be replaced by a generic _index.adoc.
    if [[ "$use_source_index" == "false" && "$rel" != */* && ( "$name" == "index.asc" || "$name" == "_index.asc" ) ]]; then
      continue
    fi

    process_file "$src" "$doc_root" "$dest_root" "$slug" "$weight"
    count=$((count + 1))
  done < <(find "$doc_root" -type f -name '*.asc' \
              ! -path '*/themes/*' \
              ! -path '*/tmp/*' \
              -print0)
}

Because an AI writes and runs these scripts itself, it is important to review them and to limit their permissions to prevent disasters.

When it works, when it doesn’t

For a well-defined project like this website, vibe coding works just fine.

My initial scepticism has become more nuanced. For a well-defined, non-critical project like this website, vibe coding can simply work. The website is manageable, errors are quickly visible and recoverable, and the pace at which something like this comes together is remarkably high.

For heavier work (business software on which the continuity of an SME depends) the story is different. There we don’t build on a vibe but on a specification. How that works, we explain on our approach page.

If I now ask Claude what it thinks of the website we built together, I get a long list of improvement points, both technical and substantive. And after solving them, that list somehow doesn’t get any shorter. Perhaps knowing when to stop vibe coding is an art too.