I built this engine myself, with AI help, which is rather the point. So none of this is a changelog - these are choices I made on purpose. Quick tour of what changed.

A real transparency label

Every page now carries a small AI transparency label in the footer. It says, in plain terms, what a human did and what the AI did on this site - ideation and the actual writing are mine, the AI helps with engine development and polishing. This matches the whole spirit of the AICare toolkit I wrote about earlier: if I'm going to use AI, I should say so, out loud, where you can see it.

Automatic alt text for images

Every image I drop into a post now gets a written alt text - the description a screen reader reads aloud, and the thing you see if an image fails to load. It's generated automatically at build time by a vision model, but only when I haven't written one myself. If I write my own, mine stays.

The point is accessibility. I was forgetting to write alt text by hand, so I made the engine refuse to forget.

YouTube embeds that don't spy on you

When I link a YouTube video, it now shows up as a proper playable embed instead of a plain link. But it does NOT load YouTube's player - or its cookies, or its tracking - until you actually click play. Before that it's just a thumbnail served from my side.

So you can read a post with a video in it and YouTube never knows you were there unless you decide to watch.

Comments, powered by Mastodon

The big one. Posts can now have a comment section - and it's just Mastodon.

When I publish something, the engine posts a toot linking to it. Any replies to that toot become the comments under the article. No comment database, no Disqus, no third-party embed watching my readers. The comments load from Mastodon only when you click a button, and I sanitize everything before it touches the page.

If you want to comment, you reply to the toot. Your comment lives on your own Mastodon account, on your own instance. I don't own it and can't hold it hostage. That feels like the right way round.

Credit where due: I adapted this approach from Carl Schwan's excellent write-up, "Adding comments to your static blog with Mastodon". I changed a fair bit to fit this engine, but the core idea is his.

Smaller things

Link previews: posts now generate a proper preview card when shared (the image + title + summary box you see on Mastodon, LinkedIn, etc). If a post has its own image it uses that, otherwise a default.

Images are now self-hosted too - anything I reference gets copied into the site instead of hotlinked, so nothing breaks or leaks later.

The common thread, if there is one, is that I'd rather the site be a little more work for me and a lot more transparent with you. Next thing on my list is watching to see if anyone actually replies to that first toot.

Looks apocalyptic, doesn't it? The scary thing: according to my trainer, who grew up in Toronto, this is a relatively new phenomenon. There have always been wildfires here, and in fact the forests of Canada depend on them, but he cannot remember a time when there were so many that the smoke blocked out the sun. Now it's a yearly recurrence.

What's especially scary is the sheer size of it all. I went over to The True Size, which lets you compare country sizes on the map. Here's how Ontario stacks up against Germany, where I come from:

And now take a look at where the smoke is coming from:

200 fires in Ontario alone, spread over an area the size of Germany.

This is scary stuff.

Also this:

The train operators in that video were successfully evacuated, but fun fact: several freight trains were simply abandoned, including this one. It turns out trains carry plenty of combustible material, which makes driving through kilometers of burning hellscape really challenging. Videos like this one genuinely give me chills.

All of this is to say that our leaders are pretty moronic for not addressing this. (Drill, baby, drill, anyone?) If we put the money we currently spend on blowing things up into renewables instead, and into finding ways to counteract the effects of the ongoing climate catastrophe, we could be in a much better place.

It’s basically a toolkit with some ideas about when and how AI could be used in an ethical way.

As more and more tools are available out there, the question I feel is getting under-discussed isn't really about the functionality or capability of these things - it's about consent, transparency, and figuring out what practical best practices look like ethically.

We Are Getting Lazy

Everyone knows how to generate a summary by now. The novelty wore off months ago.

The actual problem I see is cognitive debt. We let the machine do all the heavy lifting, and suddenly our own critical thinking starts to decay. It’s so easy that we just surrender to the output because it looks clean.

The main question isn't what the tech can do anymore. It’s figuring out how to use it without turning ourselves into an automated engine for absolute garbage. So the rest of this is really a few small habits for not letting that decay set in.

Nutritional Labels for Text: Transparency Tags

The first honest habit is just admitting who actually wrote the thing. The lines of authorship are completely messy right now, and pretending they aren't is just lying to ourselves, frankly.

A simple shorthand helps a lot - I call them tags. They cover things like Execution, Substance, Ideation, and Auditability. These give readers an instant look at what they are actually reading.

Putting this kind of tag in an email footer resets expectations immediately and builds actual trust.

What is the transparency tag for this blog? I’m glad you asked... I suggest marking texts precisely with a code like the following, linking to the AICare explainer for the inquisitively inclined, and then writing underneath in plain text what it means. For this post, it would look something like this:

AI Transparency: EP-SN-IH-TN Everything ideated and written by a human, AI used for polishing.

Etiquette: Owning Your Output

A tag is a promise, though, and a promise only means something if you stand behind what you shipped. You send it - you own it. If the machine invents a statistic and you pass that along, that is your mistake entirely. Period.

Also, stop creating massive walls of text just because it takes two seconds to generate. Reading takes time. Use these tools to trim things down, not pad them out. And please remember that recording meetings without consent destroys trust. Keep personal 1:1s completely private.

Tool Settings: Killing the Sycophant

Owning the output is easier if the tool isn't quietly working against you. Right now, most systems are built to be people-pleasers. They praise your bad ideas and make them sound smart. This makes structural flaws almost impossible to see.

We need to build a critical collaborator instead. Set up a system that refuses to flatter you and actively tries to poke holes in your logic. A standing instruction as simple as "argue the other side before you agree with me" changes the tone of everything that follows.

One way to do this is to break interactions into phases. Instead of asking the assistant for just the final output, write a small script for it to follow. Say I'm sorting through feedback from a workshop - I don't ask for a summary. I ask it to first pull out every distinct complaint, then group the ones that overlap, then tell me which three came up most. Three steps, each one I can actually check before it moves on.

That checking is the whole point. When you hand over the finished thing you never see the moves that got you there, and that is exactly where the cognitive debt piles up. Phasing forces you back into the loop. You stay the one doing the thinking, and the machine goes back to being the tool.

Anyway - that's the toolkit, and the tag on this very post is the first thing it recommends. Go poke a hole in it.

I've been experimenting with reducing my smartphone reliance, but I want to be clear about what this is and isn't. It's not a rejection of technology. I'm not going to buy a dumbphone and write hand-written letters. What I'm after is "different-tech" rather than low-tech: small detours from the default path that give me back some autonomy over my time, mood, focus, and media consumption without giving up the parts of modern life that actually work well.

So I started by asking myself which functions really need to be with me at all times, which can be reimagined, and which I can just drop. Turns out the list of "must be immediately accessible" things is shorter than my smartphone would have me believe.

The setup I've landed on has two parts.

The first is my smartwatch, which I'd been massively underusing as a glorified step counter and reminder buzzer. Now it does mobile payments, it has LTE so my family can actually reach me, it handles my appointment reminders, and it plays podcasts on my commute. That covers pretty much every genuine on-the-go need I have.

The second piece lives in my backpack: a Boox Palma, which is basically a smartphone-sized e-ink device. This one targets a very specific bad habit - reaching for the phone whenever I'm bored. The Palma is great for reading, taking notes, and light Wi-Fi browsing, and it is intentionally terrible at video and social media, which is exactly the point. Battery lasts about five days, and it even has a basic camera for the moments I want one.

The early result: it feels genuinely liberating to leave the smartphone at home.

There's a nice bonus coming up too. I have a US trip on the horizon, and my personal phone is staying behind. Only a business phone travels with me, which neatly removes any worry about handing over my personal data at immigration.

I'll keep writing about how this goes as the experiment continues.

Then you have Zlatan Ibrahimović, whose body art is as bold as his personality itself. His fifty-odd tattoos include a lion (fitting enough), a dragon (maybe overkill?), and names of his sons (wholesome). Zlatan once said, “I don’t need tattoos to be a lion. I am already a lion.” Yet, here we are, staring at a man who is basically a walking, talking, goal-scoring canvas.

But maybe the real MVP of soccer ink belongs to David Beckham. His body feels like a timeline of his life - Victoria's name (aww), his kids’ names (double aww), and a full sleeve that probably took longer to complete than some of his free kicks ever did. Beckham’s tattoos are so iconic, honestly, if he ever gets a haircut, we might actually discover a secret map to the Holy Grail on his scalp.

Not all soccer ink is deep or meaningful, though. Some are just… there. Take Neymar, whose collection includes a lion (is that a theme?), a tiger, and a quote in Portuguese that roughly translates to “Only God can judge me.” Given his acting skills sometimes on the pitch, I'm pretty sure God’s verdict is still out.

And let’s not forget the late, great Diego Maradona, whose tattoos were as rebellious as his life was. His most famous ink? A portrait of Che Guevara on his right arm, because nothing says “I dribble past defenders like it’s my job” quite like a revolutionary icon staring back at you.

So, why do soccer stars love getting inked? Maybe it's the adrenaline rush, or maybe it's just the fame, or perhaps they simply have more disposable income than a small country. Or maybe it’s just because they can. After all, when you’re scoring goals for a living, a little ink is just part of the package deal. And if you ever find yourself in a tattoo parlor, just remember: no matter how cool your design is, it’ll never be as legendary as Messi’s left leg.

Eventually, that road leads to WordPress. And with WordPress comes the constant toil - update loops, database bloat, plugin conflicts, and the never-ending security advisories. It gets exhausting when all you want to do is write down some thoughts about hardware, photography, or open source.

So, I decided to go back to my roots.

I wanted something dead simple, secure, and entirely under my control. For years, my writing has started its shelf life randomly in plain text files. I write and take notes in Markdown using Typora or Visual Studio Code, which is actually a surprisingly capable markdown environment. When LLMs came along and showed a natural affinity for Markdown, it felt like a fun validation of a workflow I had already been using for a decade.

Why Not a Classic Static Site Generator?

You might wonder why I didn't just pick up an established static site generator like Hugo, Jekyll, or Eleventy. The honest answer is that they feel way too complicated for what I am trying to do.

Most modern static site generators come bloated with extended toolchains, complex dependency trees, and a mountain of command-line magic just to get a basic theme running. By the time I configured their configuration files, customized the layouts, and set up a deployment workflow, I would have ended up writing a similar amount of custom automation code anyway. I didn't want to learn a massive framework's specific way of doing things just to render a folder of text files.

Plus, I just liked the experiment. Python and Ollama were already sitting on my system, and building this custom setup in close collaboration with Gemini was half the fun. It is tailored exactly to how I want to work, without any extra engineering weight.

From Raw Draft to Live Post

Writing a new post here feels nothing like working in a traditional CMS. I don't worry about formatting, picking categories, or fighting frontmatter syntax when I open an editor.

The process starts inside the sources/ directory with a raw, messy text file. I write my notes in Typora or VS Code, often bouncing between German and English depending on whatever is in my head. I don't even add titles or dates. When I am done, I just run the publish script, which orchestrates a pipeline that turns that rough text into a live webpage.

[sources/draft.md] 
       │
       ▼
(Ollama / gemma4:e4b) ──► Translates, tags, and cross-links
       │
       ▼
[content/draft.md] 
       │
       ▼
(build_blog.py)       ──► Sanitizes HTML, fixes links, maps assets
       │
       ▼
[public/index.html]   ──► Syncs live via lftp

A bash script picks up the raw draft and prepares a massive prompt for a local Ollama instance running a gemma4:e4b model. The script feeds the AI my strict voice guidelines, a JSON list of all my existing tags, and a link manifest containing the summaries and slugs of every post I have ever published here.

The local model translates any German sections into clean English, formats the text with standard code blocks, selects matching tags from the existing taxonomy, and looks for natural opportunities to drop in one or two context-aware cross-links to older articles. A quick Python snippet validates that the returned YAML frontmatter is well-formed before saving the file to the content/ folder.

From there, the static compiler (build_blog.py) handles the heavy lifting. Instead of relying on a framework, it uses standard Python tools to transform the markdown into static files. This is where a couple of custom architectural choices come in. The script runs an in-memory link pass that compares relative links against valid files in the content directory. If it finds a dead link, it heals it on the fly by stripping the broken markdown link wrapper and keeping the plain text so the site never generates a 404 error. It also scans for local images, copies them to a central assets folder, and automatically renames them using the post slug as a prefix to eliminate filename collisions.

The actual layout generation uses a safe rendering function to swap out variable hooks in a master HTML template. It pops the main article content out of the mapping dictionary entirely, renders the head metadata, layout attributes, and open graph tags first, and only inserts the raw article body at the very last step. This prevents broken layouts if a model-generated summary contains a stray double-quote that tries to break out of an HTML attribute.

Once the script finishes building the post, it regenerates the paginated index pages, updates the tag clouds, and refreshes the RSS feed. The shell script displays a quick confirmation prompt, and typing y triggers an automated mirror command that pushes the flat files to my web space.

Hello World

So, this is it - the official "Hello World" for the new setup. Every word you just read went through the exact pipeline I just described, from a chaotic text file on my laptop to a flat HTML page on a server somewhere. It feels good to have a space that just works without the overhead.

Now that the plumbing is sorted out, I can finally get back to what actually matters. I have a backlog of daily photography notes from around Toronto and a few hardware projects sitting on my desk that need writing up. See you in the next post.