All I wanted for one of our websites was a small addition: a blog section. Not a huge feature, not a complex tool, just a "normal" blog. It was supposed to be even easier because we already have that section on our other website and simply wanted to carry it over one to one.
And for exactly that kind of task I thought: surely that must be pretty quick with Claude Code by now. Copy and paste, adjust a bit of CSS, done.
Spoiler: yes. But it is not quite that simple. At least not the first time.
Two perspectives on the same website
There is one more thing in my case: I always look at a website from two rather different angles.
I am a graphic designer, so I have a very strong visual take on websites. I see layout, spacing, typography, hierarchy, components – and of course I notice immediately when something does not look the way it should. At the same time I work in marketing and sales at Infralovers, which means a website interests me not only as a piece of design but as a tool:
- Does it work for users?
- Can I extend the content easily?
- Does it support how we communicate?
- Can we get new content online quickly?
- And how much effort actually sits behind one small change?
With AI-generated changes that leads to two rather different reactions.
As a designer I quickly land at: it is sort of okay, but I would personally have solved it differently.
As a marketing person I tend to think: it works, it was fast, it is fine as long as we can work with it and the content is right.
And those two perspectives kept me busy during our first small Claude Code experiment.
The small problem with "our website"
The website in question does not run on WordPress, Typo3, Drupal or any other CMS I have worked with dozens of times. It runs on Hugo and a Git repository.
For someone who works with that every day, this is presumably entirely normal.
For me it mostly means confusing rows of text and code, in folders whose names only partly make sense. Finding something in there is not always easy, especially when it is not a routine change like editing a bit of copy.
I can handle basic HTML and CSS, design files and Figma, but Hugo and Git are not the same playground as WordPress, where I know exactly where to click.
So first I needed help from someone who knows their way around. And that turned out to be the most important step.
Setup first. Then Claude Code.
Before Claude Code could get anywhere useful, we first had to establish – for Claude – how our website is put together, where the blog even belongs and how we wanted it to work.
That is probably the part you do not see in most AI coding success stories.
What you usually hear is: "I told Claude Code what I wanted and ten minutes later everything was finished and wonderful."
With an existing website and a defined corporate identity it is not quite that simple, because Claude Code needs to know not only what you want to build, but also where and how it fits into the existing structure.
And this is exactly where I, as a non-developer, faced a fair amount of work up front – work that would probably have taken me far longer on my own, and might not have been correct in the end. Fair warning, it gets dry for a moment: I will let Claude explain what we did.
"At the start there was a machine with literally nothing prepared on it: no SSH key, no GitHub CLI, no Hugo. So the first step was not code but a key pair, a
~/.ssh/configand two clones side by side – this project and the main website as the template we wanted to take layouts from. Hugo only arrived later, and that was the instructive part: as long as nothing could be built locally, a careful review stood in for the compiler. It found nine real defects – but not the decisive one. That one surfaced the moment the first build actually ran: during the rework an attribute had been lost from the blog cards, so clicking a category filter would not have filtered anything but hidden every post instead. Seconds after the firsthugo --gc --minifyit was obvious – and nobody had seen it before. To this day Node is still missing on that same machine, which is why the visual regression tests remain open – the same gap, one level up. The lesson is unspectacular and holds for any project: the most important setup task is not access to the repository, it is being able to see the result locally."
The brief: carry the existing blog over from website number two
We already have a blog on our other website. So why build everything from scratch?
The idea was simple: take the existing blog concept and layout and adapt it for the new site. So Claude Code essentially got the job of transferring the existing blog into the new website structure.
And surprisingly, for a task that size, that worked rather well.
This is where my designer side came in. Because "it works" and "I like it" are two different things.
With a result like that I of course look immediately at whether the layout really sits cleanly inside the existing website. In this case I was fundamentally happy with it. Not necessarily in the sense of perfect, but close enough that I can work with it.
And then came the filters. Of course, there had to be something …
The blog filters did not really look the way they did in the original. The structure of our existing blog was largely carried over, but the filter logic in particular came out not really usable.
From a developer's perspective you would probably say: then you fix it.
From a marketing perspective I asked myself: do we even need this?
Our new site has considerably fewer topic areas than the other website, and we do not have the problem of someone needing to navigate ten years of blog history to find posts on one particular subject.
So I decided it is good enough, because it works and does what it should.
And that is something I find genuinely important in projects like this. Not every deviation from the original system has to be repaired. If a feature brings no real value for the specific use case, you can simply leave it out.
Here too my two perspectives differed. As a designer, a component that is not identical bothers me. As the person responsible for marketing, I can say much more easily: for our current website this is not a relevant problem.
That may be one of the most interesting questions when using AI for this kind of work: does the result have to be technically perfect, or does it have to be good enough for the specific purpose?
The verdict: for small stuff it works rather well
If you take out the initial setup phase, which cost a fair bit of time, the actual implementation was pretty quick.
What I find most interesting as a designer is that I do not have to understand every technical change myself in order to judge the result. I can say very precisely how it should look and feel. From a marketing point of view I can judge at the same time whether it works for the actual purpose. Claude Code takes over part of the translation work between those requirements and the code. That does not mean I have suddenly become a Hugo developer. I still do not know which files I would need to touch.
But I can work with the system far better, and above all I can make small changes myself, test them and judge them, without turning every little thing into a full development process.
The result
The new blog is online, and for this first small addition my personal verdict is: for a small addition the result is rather good, and once the basic setup is done, it gets fast.
Next up it will no longer be about carrying over an existing page type. We wanted to build a completely new page type based on an externally supplied website template, taking only the content as orientation and adapting it to our own design, our structure and our wording.
And for me, as a designer and a marketing person, that gets considerably more interesting.
To be continued.
