That goal is what turned "which model is best" into an actual question worth testing, because "best" depends entirely on the job. So I ran two experiments. First: how do the various models cope when the input is bulleted, fragmented notes versus a finished draft? That's the real fork in how I write - some days I hand it clean prose, some days a pile of stubs. Second: how does the prose itself differ model by model, once you strip out the effect of the input? I wanted to know each model's fingerprint, not just a leaderboard.

Notes below from testing the polish step across 8 configurations (7 remote models + local gemma4:e4b) over the blog's real drafts. What I learned.

The prompt every model ran

One thing worth being explicit about: every model got the exact same prompt. No per-model tuning, no coaxing the weaker ones with extra hand-holding. That was the point - I wanted to see the model's own behavior, not my ability to prompt-engineer around it. If I'd tweaked the prompt per model I'd be measuring my patience, not the models.

The prompt frames the model as "the author's editor" and hands it my rough notes. The load-bearing part is a rule I put in caps and at the very top: do not lose ideas. Not "summarize," not "improve" - present all of my thinking, every distinct point, and reuse my own vivid phrasing rather than paraphrasing it into mush. I spelled out that dropping or watering down an idea to make the text shorter or smoother counts as a failure, because that's exactly the "helpful" instinct I was trying to suppress. The model is allowed to reorder for flow, merge fragments into sentences, and add light connective tissue, but it may not invent new claims.

Two more blocks round it out. A voice block pastes in my writing guide verbatim - including the list of words and phrases the model must never use - so "in their voice" isn't left to interpretation. And a format block asks for clean Markdown, translates any German into natural English (I draft in both), and insists on the article body only, no frontmatter or preamble.

Here's the whole thing, with the two injected values marked in braces (my voice guide gets pasted into the first, the raw draft into the second):

You are the author's editor. The text below is the author's own rough notes for a blog post. Turn them into a finished, flowing article in their voice.

[MOST IMPORTANT RULE - DO NOT LOSE IDEAS]
The notes contain the author's actual thinking. Your job is to present ALL of it, not a summary of it.
- Keep every distinct point, argument, example, and section. If the notes make five points, the article makes five points.
- Keep any vivid phrase, metaphor, analogy, or joke the author used. These are the best part - reuse the author's own wording, do not paraphrase them away.
- Dropping or watering down an idea to make the text shorter or smoother is a FAILURE. When in doubt, keep it in.
- You may reorder for flow, merge fragments into sentences, and add light connective tissue, but do not invent new claims or facts.

[VOICE]
Write the way the author writes. Match this guide exactly, including the list of words and phrases you must never use:
{voice_guidelines}

[FORMAT]
- Clean Markdown. Translate any German into natural English.
- Do not output frontmatter, a title, JSON, or any preamble. Output ONLY the article body.

[AUTHOR'S NOTES]
{raw_draft}

The interesting design consequence: this single prompt is what makes the whole thing auto-scale. Because rule #1 is "preserve the author's wording," a finished draft leaves almost nothing to do and every model just tidies, while a bare outline forces the model to actually write. I didn't build separate "copy-edit mode" and "draft mode" prompts - the same instruction produces both behaviors depending on what I feed it. The bake-off was partly a test of whether that hunch held up. It did.

The core finding - divergence tracks draft shape, not model

How much the models' outputs differ from each other is driven almost entirely by how finished the source draft is, not by which model ran. Measured across 6 posts, flow-similarity lined up monotonically with the draft's bullet-ratio: prose drafts converged (57 - 98%), while a pure outline diverged wildly (3%).

The mechanism is simple. The polish prompt's #1 rule is "preserve the author's wording." On finished prose there's nothing to invent, so every model just tidies and they land in the same place; on bare bullets each model writes its own prose, so they scatter.

This means the system's aggressiveness auto-scales to how much you write - hand it prose, it copy-edits; hand it bullets, it drafts. You control the dial just by draft finishedness, no setting to touch. This is exactly the behavior I want.

The "outline test" is where model choice actually matters - that's the column set worth studying when picking a model, because that's where the model is writing rather than tidying.

As a side note, hello_world's 98% similarity was a bit of a degenerate data point. Its "draft" was already a finished, published article (title/date/tags and all), so every model handed it back ~98% unchanged. It wasn't a case of "models agree" so much as "nothing to polish."

Genuinely model-specific tics (survive after stripping out format effects)

• Mistral: emits em-dashes (7 across 6 posts vs ~0 for others) even when instructed otherwise.
• Sonnet: emphatic register - heavy bold (10× vs ≤3), and "genuinely" (4×). Rewrites openings more, but mainly on short/outline drafts.
• DeepSeek: the boldest re-framer on prose input (threw out the opening on engine-update and pulled a buried line to the top); also slowest remote model, especially on long drafts (181s on the 996-word one).
• e4b (local): genuinely good on prose - preserved all ideas, no banned words, recognizably the right voice; only slip was occasional em-dashes. On pure outlines it ran ~10 - 15% wordier than Opus and added filler.

On e4b as a daily driver

Similarity measures agreement, not quality - so the verdict came from reading outputs, not the numbers.

My verdict is that e4b is defensible as a daily driver specifically because of the auto-scaling property. On prose the quality gap to large models nearly vanishes; it only opens on bare outlines. So: prose → e4b is great (local, private, free); outlines → consider a remote model.

Where big models win is tighter prose (they cut instead of padding), better paragraph structure, and zero style-guide violations.

The takeaways that actually changed my mind

A few things landed hard enough to shape what I use:

Big models are overkill for this job. The whole task is "tidy my prose without losing my ideas," and that ceiling is low - once a model can do it cleanly, a bigger one doesn't do it more. On finished drafts the giants were spending their capability on a problem that didn't need it. That reframed the whole decision for me. I stopped chasing the best model and started looking for a good-enough one I could run as close to home as possible.

Mistral is a serious contender. Setting aside its em-dash habit (which I strip mechanically anyway), it turned in genuinely good prose and was quick about it. If I were picking a remote model purely on the writing, it'd be near the top. Worth keeping in mind for the outline path where model choice still matters.

gemma4 is the real surprise. This is the one that made me rethink the setup. A small model running locally on my own machine held its own against remote giants on the writing - and then, remembered, it's multi-modal! It writes my alt text too, describing real photos coherently, image bytes never leaving the machine.

See it for yourself

You don't have to take my word for any of this. I put the whole comparison online: every source draft, and side by side, what each of the nine configurations did with it. Read across a row and watch the prose drift apart on the outline drafts and snap back together on the finished ones - that's the core finding, right there in front of you. If you like to see an example where the source was just bullets, select "smartphonefree" or "AICare". These are the articles with most variety in results.

Have a look: https://unprompted.dirkprimbs.de/viewer.html

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.

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.