# Notes of November
Friday, 28. November 2025



A few notes from November 2025:

## Tooling

I was using two tools in the recent months that gave me a lot of joy in my day-to-day work.
The first is [Jujutsu](https://docs.jj-vcs.dev/latest/), or `jj` in short.
It is a version control system (VCS). If I should describe it with my own words, it is a git-inspired and git-compatible
VCS based on the intuition many developers have about the way git _should_ behave.

Many daily development tasks like throwing away all uncommitted changes (`jj abandon`) or restoring a file
from an older commit (`jj restore`) are much simpler to use than in git, where these tasks usually require
a handful of flags that I have all stored in a large cheatsheet.

Git was the first VCS I used, and it still serves me well every day. For a private project,
`jj` has been giving me a breeze of fresh air lately and I hope we will see wider adoption in the future.

Another interesting project I discovered is [cdist](https://www.cdi.st/manual/latest/index.html). It is a configuration
management system for servers, initially developed in the space of the university ETH Zürich.
I have a couple of servers running and manage them mainly manually. Some administrative tasks got so tedious
though that I was looking for a lightweight alternative for Ansible or Puppet. I've used both systems, but I always
found them complex and slow and Ansible kept breaking after a couple of weeks for Python related topics that I don't understand.

It took my two evenings to understand cdist and deploy my own binaries with their respective OS users and service
definitions. Once I understood how to deploy and configure software with cdist, it was a matter of minutes to add
even more software to my deployment stack.
If you are looking to automate some parts of your server management and also find Ansible and Puppet too mighty for your
simple use-case, cdist might be your tool.

## Search

Google Search unfortunately is broken beyond a point of usability. The first half of the page is filled with AI fluff,
just for the second half of the page to be filled with ads.

It takes scrolling to reach the first usable results, even though medium.com is still ranked quite high and that's
usually not a useful result (and neither is LinkedIn).

I came across [kagi.com](https://kagi.com). It is a search engine which does only partially rely on other search
engines (in contrast to e.g. Ecosia which uses Google's search index).
A compelling feature is to up- or downrank websites, or block them entirely from the search (medium 👀).
There are a couple of customization options for searches.

What's most surprising for me is how used I got to Google gradually serving me a nightmare experience and how kagi
is able to bring back this intuitive feeling that Google once brought, to search for a thing and to find that thing within
the first page.

I've only tried kagi for a few days yet, and it already makes me feel different about how search engines should be.
Kagi is a Public Benefit Corporation, and they describe a few things about their mission on their blog, including their
stance on AI, which leads me to...

## AI on my blog

I thought I'd get around writing about LLMs. I just wanted to say that this article was written by hand and none of it
ran through generative transformers. I want to be honest and say that not every article on my blog is equal.
I was very impressed when Michael Lynch described in his blog how he
[hires a human editor to review his articles](https://mtlynch.io/editor/).

I see the value in well edited text, but I didn't want to spend this money, so I was looking for a more affordable solution in terms of
grammarly and the like (which seems to be an AI company now too...).
English is the language I speak best right after my first language German. I wished I could
speak with the same precision in both languages, but I don't, and probably I've reached a ceiling in my current
environment for how much I'll be able to improve.

I experimented with LLMs, namely to write an English article by hand and prompt the AI for
"You are an editor. Review my article...". Even though all my posts are handwritten, the editing of the past year or
so has this "AI smell" that nobody really can put a finger on, but we all notice when it is there.

I decided that for my own blog I want to be very much in charge of my own language, so I don't need AI writing or editing
anymore.

I compare the usage of LLMs (and the increased use of Agents) to the illusion of productivity-systems.
In all the years that I researched note-taking and productivity systems, I came to realize that most of what
you see on "Productivity Youtube" creates this illusion of being productive, because there are all these tools and
workflows. It is the complexity of the setups, the magic of automation that makes us believe we are more productive.
Most of the time though, real productivity comes from sitting down and doing the thing, not managing a system around
the thing.

When the LLM generates all these words "for us", we feel empowered and productive, as if we achieved something.
Personally, I don't want to read AI fluff and I prefer to sense when someone struggles with the language and struggles
and succeeds with making a point clear.

Probably the perception of reading blog posts will change in the age of AI. If in 2019 an article was extremely well written,
someone spent a lot of time and enthusiasm for language.
If in 2025 an article "sounds nice" or "reads well", it does not say much about effort anymore. The value of an article,
as it is with productivity systems, comes from "the thing", not the system that manages the thing.
I'll never write in a style like [The New Yorker](https://www.newyorker.com), especially in
English, and I am starting to get comfortable with my flaws, thanks to the uncanny text-valleys that LLMs produce.

I see LLMs as a search engine for words, which is NOT a search engine for information, knowledge or even wisdom.

## Closing with Feedback Culture

When I wrote about [Crew Resource Management (CRM)](https://raphting.dev/posts/engineering-crm/) in 2021, I only wrote about
the happy path. How to set up a framework for software developers to collaborate. I did not cover the topic of failure.

I was recently thinking about conflicts at the work place. Power struggles, power abuse and how "humans happen".
Giving good feedback is about knowing when not to give it. At the same time, we all have our boundaries, and there is
no life-hack to make communicating those boundaries easy. This communication itself can be another cause for friction.

Circling back to CRM, more often than not the root cause is an organizational system that leads to conflict, or phrased
differently, an organizational system that does not prevent a certain type of conflict.
Once in a while it is good to remember that resolving a conflict is not "you against me" but "us against the problem".
Nonetheless, reckless behaviour is not systematic and requires accountability.
Most of this is covered in the context of CRM, and it would require an article of its own to cover those topics.

My flight instructor taught me "always, with one eye, look out for a suitable landing area
to be prepared for an engine failure". Planning for the failure path is part of any aviation mission.

How come we set up systems like Scrum and assume they work if we follow what's written in the Guide?
How come the Scrum Guide does not mention the word "error" or its synonyms? (Except for the word "failure", which
is related to a "lost opportunity", which in turn is pretty much an empty phrase, as most sentences are in this Guide).

This is not just about Scrum. It is more about the observation that success is made systemic whereas failure is seen as
individual error. If framework X succeeds, it did because it is a good framework. If the same framework X fails, it did
because we blame an individual.

As with an API that doesn't define error scenarios, I am highly sceptical of
management frameworks that don't define those either.


By Raphael Sprenger