loki.dev

The Merge Conflict

2026-11-13T13:00:00+00:00

Technically the robot is right: no branches, no conflicts. An agent takes "force" very literally, and destructive git commands are on my list of things it only gets to do after asking. Better still if two people never work in the same checkout. That's what I use git worktree for.

The God Class

2026-11-06T13:00:00+00:00

Agents like to build where code already exists. The class that already knows everything is the most convenient place for the next feature, and the one after that. Every single diff looks harmless. A few weeks later you notice one file is half the application. A linter with limits on class size and complexity catches that earlier than any review.

The Friday Hotfix

2026-10-30T13:00:00+00:00

Don't deploy on Friday afternoon. We knew that long before agents. What's new is that an agent with too many permissions manages in seconds what a human on a bad day needed half an hour for. That's why my agent never gets near production. Read access yes, kill no.

The Refactoring

2026-10-23T13:00:00+00:00

An agent optimizes for exactly what you tell it. Say "more readable" and you get more readable, at the cost of everything else if need be. What helps are tests that pin down the behavior before anyone starts cleaning up. How I set that up in my own toolchain is in part 5 of the tooling series.

Do agents need a new Git branching model?

2026-10-22T09:00:00+00:00

(Translation was done by AI. Sorry :/)

I like OneFlow. Adam Ruka wrote it up in 2017 as a counter-proposal to GitFlow, and shortly after it became what I recommend whenever someone asks me about Git branching (well, sometimes also when nobody asks). One long-lived branch, short branches around it, releases as tags. Done. So a lot less complex than GitFlow.

My day looks different from 2017, though. Often several agents run at the same time, each in its own worktree (most people don't even notice), each on its own branch with a claude- prefix or similar. By the afternoon there are branches in the repo I never created myself, and a few PRs that all want into main at once.

Do we need a new model for this? Or does OneFlow do the job, just turned faster? And which part of it gives the most benefit without me sinking a weekend into tooling? Or even better: spending three weeks introducing a new model, and half a year later everything changes again?

I think the model itself can stay. The branches get smaller and live only a few hours (compared to days before), and at the end a human (still?) has to decide whether they get back onto the default branch.

OneFlow in 60 seconds

Just a quick refresher. For details, feel free to click the OneFlow link above.

There is exactly one long-lived branch, usually main. That is where the history happens.
Feature branches start from main and get deleted after the merge.
Releases are tags. Release branches are temporary and only exist when a release needs stabilisation (QA, code freeze), then they go away again.
Hotfixes branch off the latest release tag.

For features, Ruka recommends rebase plus fast-forward so the history stays linear. He names two cases where OneFlow does not fit: projects that maintain several incompatible versions in parallel, and continuous deployment, where the release process looks completely different.

Fun fact: Vincent Driessen, who invented GitFlow, sees it similarly by now. Since 2020 there has been a note on top of his article saying that teams doing continuous delivery should pick something simpler.

What superintelligence (lol :D) changes

Many more branches, much shorter ones

Agents work in worktrees. Claude Code does this on its own with claude --worktree <name>: new directory under .claude/worktrees/, new branch worktree-<name>, branched from the default branch on the remote. Subagents get their own with isolation: worktree. I wrote about what git worktree is back in 2021, when it was still for humans.

A branch now lives only as long as the one task it was created for. If the agent gets lost, the branch is set up again in ten minutes, changes included, and that is usually faster than debugging its mess.

On trunkbaseddevelopment.com, Paul Hammant gives short-lived feature branches a couple of days at most, including the time spent waiting for review. He now explicitly counts the developer's own coding agents among those allowed to work on such a branch.

More conflicts, and size causes the most trouble

The best numbers I found come from AgenticFlict (Ogenrwot and Businge, AIware 2026). For this study they collected more than 142,000 PRs from coding agents across more than 59,000 repos and test-merged about 107,000 of them. 27.7% had conflicts. Per agent it ranged from 15% (Copilot) to 32% (Codex). Claude Code was at 26%, but with only 779 PRs, so the evidence is thin.

I find the size data more interesting than the agent comparison, mostly because we can learn something from it:

PRs with about two changed lines conflicted around 10% of the time, at about 25 lines it was almost 30%. Above that, the rate levels off at around 32 to 33%.

This lines up with the AI Capabilities Model from the 2025 DORA report. Of the seven capabilities that decide whether AI helps or hurts a team, two are "strong version control practices" and "working in small batches". According to DORA, teams that commit often and make use of rollbacks get more out of AI.

The dangerous conflict is the one Git cannot see

Text conflicts are annoying, but at least Git reports them. Worse is when two agents change different files, both branches are green, and main is red after the second merge anyway. Agent A renames a parameter, agent B still calls the function with the old name.

"Passes Alone, Fails Together" (Xia, Wu, Park, September 2026) looks at exactly this. In constructed tasks where two agents work on the same Django helpers, 97% of runs broke. A single message telling the second agent what the first one had already changed rescued 82% of them.

On real PR pairs mined from Django, though, the problem showed up in only one of 834 runs, and the authors themselves warn against reading the 97% as an everyday number. The tasks were built on purpose so that both agents poke at the same helpers. In everyday work this is rare. When two agents touch the same interface, it can happen easily, and then I would not let them run blindly in parallel.

Merging stays manual work

Starting agents is trivial by now, no "proof" required :D. Bringing the work back together is still on me, though. The Claude Code docs describe worktrees as isolation for file edits. What happens to the branch afterwards is my job. Of course AI is a useful tool for that too, but real logic conflicts in particular still have to be resolved by a human.

With review, which I wrote about recently, it was similar. Since the agents do the typing, reading is the bottleneck. Branches play the same game one step later in the process, at the merge.

And Scion?

Scion comes from Google. I had filed it under Anthropic at first. It is an experimental orchestrator, open source since April 2026, pre-1.0, and according to its README explicitly not an officially supported Google product.

The idea: every agent (Claude Code, Gemini CLI, Codex, OpenCode) runs in its own container, with its own worktree and its own credentials. The agents coordinate through the Scion CLI and message each other. Humans follow along through a web UI or via Slack, Teams and friends.

Mostly it showed me how little a worktree isolates. Ports, database, Docker volumes and caches are still shared by every agent on my machine, only the files are separate. That is why Scion puts each agent in a container with its own credentials, and I like the second part in particular. An agent fixing typos in the docs has no business holding a deploy token.

How the work comes back together is something Scion leaves open too. I found nothing in the README about branch names, merge strategy or PRs. So I have to bring the branching model myself either way.

Do I need Scion? Not right now. It pays off when many agents run for a long time, on several machines and with different permissions. For a handful of agents on my laptop, worktrees are enough.

My proposal: OneFlow, turned faster

One long-lived branch, and it is always green. Same as OneFlow. What is new is how expensive a red main has become. Every new agent branches off the current main, which is the default in Claude Code. If it is broken, every agent starts from a broken state and burns tokens chasing bugs that are not theirs.
One task, one branch, one worktree, one PR. The ticket number goes into the branch name (agent/PROJ-123-retry-logic), so three weeks later I still know where it came from. Lifetime: hours, one working day at most. If an agent heads in the wrong direction, I delete the branch and start again with a better ticket.
Cut it small. Whatever does not fit into a small PR becomes a stack. GitHub made stacked PRs generally available on 6 October 2026, gh stack supports worktrees, and a stack goes through the merge queue as one group. Unfinished work goes behind a feature flag. There are no long-lived feature branches.
Squash merge. This is where I deviate from Ruka. He cleans up with an interactive rebase before merging. With five commits from a human that works. Nobody cleans up the dozens of WIP commits an agent leaves behind by hand, and squash does the same thing automatically: one PR, one commit on main, one git revert if it goes wrong. That also settles Ruka's own complaint about rebase (reverting a feature means reverting several commits). The commit message gets the ticket number and an Assisted-by trailer.
Merge queue as soon as several agents open PRs in parallel. The queue tests each PR against main plus every PR ahead of it. That is exactly what catches the conflicts Git cannot see. On GitHub it is a branch rule (depending on your plan), GitLab calls it a merge train.
If two tasks share an interface, they run one after the other. Or the second agent gets told what the first one changed. In the Django study above, exactly that one sentence rescued 82% of the broken runs.
Agents do not merge and do not tag. Branch protection on main, changes only via PR, a human merges. Releases stay as in OneFlow: tag on main, release branch only when needed, hotfix from the tag.

What gives the most for the least effort?

My estimate, roughly in the order I would introduce things:

Measure	Effort	Benefit	When
Protected `main`, required CI	about an hour	very high	right away
Worktree per agent	one flag	high	right away
Small PRs, squash merge	one repo setting, plus discipline	high	right away
Ticket in branch name, `Assisted-by` in commit	none	medium	right away
Merge queue	one setting, merges take longer	high	several parallel agent PRs per day
Stacked PRs	a new habit	medium	features that do not fit into one PR
Container per agent (Scion and friends)	days	high for credentials	many agents, several machines, different permissions

The first four rows together cost an afternoon. After that I would measure for two weeks before touching anything further down the table.

What I leave out on purpose

The develop branch. Ruka's variant with develop as the working branch and master as a pointer to the latest release is meant for open source projects. For agents, a second long-lived branch is mostly a second place to branch off from by mistake.
Release branches by default. For web apps with continuous deployment, a tag is enough.
jj. Jujutsu treats conflicts as normal data you can commit and resolve later, and has an undo for every operation. Sounds ideal for agents. I have not tried it seriously yet, and as long as Git with worktrees does the job, switching is too expensive for me.
Agent sessions in the repo. Entire, the company of former GitHub CEO Thomas Dohmke, attaches agent sessions to commits via an Entire-Checkpoint trailer and keeps the metadata on a separate branch. Interesting when traceability is mandatory. For now, a link to the session in the PR description is enough for me.

Conclusion

Do agents need a new branching model? I don't think so. I am sticking with OneFlow: main is the branch that matters, and everything else can go once its task is done. With agents that just happens a lot more often.

New branches cost me almost nothing today. Getting each one of them back into main still takes as much time as it used to, and there are many more of them. That is why almost all the rules above are about merging, and about a human clicking the merge button at the end.

Sources (selection)

Adam Ruka, OneFlow: a Git branching model and workflow, 2017
Vincent Driessen, A successful Git branching model, with a note from 2020
Paul Hammant, Short-Lived Feature Branches
Ogenrwot, Businge, AgenticFlict, arXiv:2604.03551, AIware 2026
Xia, Wu, Park, Passes Alone, Fails Together, arXiv:2609.25396, 2026
DORA, State of AI-assisted Software Development 2025
Claude Code Docs, Run parallel sessions with worktrees
GoogleCloudPlatform/scion
GitHub Changelog, Stacked pull requests generally available, 6 October 2026

Speech recognition in 17 MB, entirely in the browser

2026-10-21T17:00:00+00:00

(Translation was done by AI. Sorry :/)

Until now, speech recognition mostly meant one of two things: send the audio to a server, or run a local model that weighs a few hundred megabytes and really wants a GPU. On October 2, Cactus Compute released Whistle. The whole model is a single 16.9 MB file, and it runs on the CPU.

At 17 MB the obvious question was: does this work in the browser, with no server and without the audio ever leaving the tab? It does. The PoC took one evening and lives here: loki.dev/lab/whistle.

What Whistle is

Whistle runs on the same engine as Needle, the small tool-calling model Cactus put out in May. Both share the .cact container format, the quantisation (Cactus Quants, 2 to 4 bit) and the SIMD kernels. There are no dependencies and no GPU is needed. The license is Apache 2.0.

According to the model card, Whistle understands seven languages: English, German, French, Spanish, Italian, Dutch and Polish. If you don't name one, it detects it. It handles up to 30 seconds in one pass and splits longer recordings into windows. For every word it returns start, end and a probability, taken from the decoder's attention. A keyword list lets you push names and jargon.

In live mode it transcribes while you talk and only commits the words two passes agree on. If you don't need a transcript at all, you get the encoder output as an embedding, one row per 80 ms, for something like search over audio.

Cactus lists the limits themselves. Silence and steady noise give you an empty transcript instead of an invented sentence. Music, on the other hand, can still come out as text. If you leave a microphone open all the time, put a voice activity detector or a wake word in front of it.

The Hacker News thread has reports you won't find in the model card. The most striking one: a user ran it on a TV episode and got nothing but "Thank you." in several places, once for 60 seconds of dialogue in a row. Polish is apparently only usable if you speak loud, clear and slow, and with a Flemish accent Whistle kept guessing between Dutch and German.

How the PoC works

Cactus also ships the engine as a WebAssembly build: needle.js plus needle.wasm, just under 1 MB together, 0.4 MB over the wire with gzip. Add whistle.cact to that. All of it is hosted on loki.dev itself, so there are no requests to Hugging Face or a CDN.

Everything heavy runs in a Web Worker so the page doesn't freeze. The worker fetches engine and model as an ArrayBuffer, copies the model into WebAssembly memory and loads it:

const [wasm, cact] = await Promise.all(
  ['vendor/needle.wasm', 'vendor/whistle.cact'].map((u) => fetch(u).then((r) => r.arrayBuffer())),
);
// The build ignores locateFile, so hand it the wasm bytes directly.
M = await createNeedle({ wasmBinary: wasm });
const p = M._malloc(cact.byteLength);
M.HEAPU8.set(new Uint8Array(cact), p);
if (M._needle_load(p, BigInt(cact.byteLength)) < 0) throw new Error(M.UTF8ToString(M._needle_last_error()));

The wasmBinary is needed because the build ignores locateFile and would otherwise look for the .wasm file in the wrong place.

After that, transcribing is a single C call through ccall. The samples go in as a pointer, language and keywords as strings, and the result comes back as JSON in a buffer reserved up front:

const out = call('needle_transcribe', [...T, 'number', 'number', 'number'], [
  p, m.pcm.length, m.language || null, m.keywords || null, m.words ? 1 : 0, outPtr, OUT_CAP,
]);

call is a small wrapper around M.ccall that checks the return code and reads the buffer with JSON.parse.

Whistle wants 16 kHz mono as a Float32Array. For the microphone, the browser handles that: new AudioContext({ sampleRate: 16000 }) resamples the mic signal by itself. For files I first decode with decodeAudioData and then render the result through an OfflineAudioContext with one channel at 16 kHz. That downmixes to mono and resamples in one step. Videos work too, as long as the browser can decode the audio track.

In live mode there is only ever one pass in flight. As soon as a second of audio has piled up and the worker is free, the buffer goes to needle_stream_transcribe_process. Whatever arrives in the meantime goes into the next pass. What comes back is the committed words plus a tentative tail, which I show dimmed. On stop, needle_stream_transcribe_stop collects the rest. Words the model is less than 60 % sure about get a dotted underline, and the timestamps sit in the tooltip.

A service worker caches the page, the worker, the engine and the model. After the first visit the page works in airplane mode. The audio never leaves the tab, which you can check in the network tab of the DevTools.

The comparison

Up front: all numbers come from the vendors. Everyone measures with their own setup, partly with different normalizers and scoring rules. The tables are good enough for orders of magnitude, not for a ranking down to the decimal.

First, the fact sheets:

Model	Download	Languages	License	Runs on
Whistle	16.9 MB	7, incl. German	Apache 2.0	CPU, WebAssembly too
Moonshine tiny	41.9 MB¹	English only	MIT	CPU
Whisper base	145 MB¹	99	MIT	CPU, GPU
Parakeet TDT 0.6B v3	714 MB (GGUF q8_0)	25 European	CC-BY-4.0	NVIDIA GPU with NeMo, locally via NeMo-Speech.cpp
Nemotron Speech Streaming en 0.6B	700 MB (GGUF q8_0)	English only	NVIDIA Open Model License	same as Parakeet
Nemotron 3.5 ASR Streaming 0.6B	742 MB (GGUF q8_0)	40 locales, incl. de-DE	OpenMDW-1.1	same as Parakeet, plus an ONNX export (int4)

¹ Size from Whistle's benchmark chart. The NVIDIA models have 600 million parameters each and weigh about 2.5 GB as .nemo files.

Then the word error rates (WER in %, lower is better):

Model	LibriSpeech clean	LibriSpeech other	TED-LIUM	Earnings-22	AMI	FLEURS de
Whistle	4.31	10.49	7.61	19.01	26.07	n/a²
Moonshine tiny	4.52	11.71	5.64	21.25	22.77	en only
Whisper base	4.9	11.0	5.0	n/a	21.5³	17.9
Parakeet TDT 0.6B v3	1.93	3.59	2.75	11.42	11.31	5.04
Nemotron en (1.12 s)	2.32	4.84	3.50	12.52	11.73	en only
Nemotron 3.5 (1.12 s)	n/a	n/a	n/a	n/a	n/a	8.31

² For FLEURS, Whistle only gives the average over all seven languages: 21.4. ³ AMI-IHM. Whistle counts empty references on AMI, the way the Open ASR Leaderboard does.

Sources: the linked model cards, for Whisper base the Whisper paper (tables 9 and 13), for Moonshine the Moonshine paper (table 3). Whistle's own chart compares against exactly these values.

Whistle is roughly on par with Whisper base and Moonshine tiny. Slightly ahead on LibriSpeech, behind on TED-LIUM and AMI. In Whistle's chart, the Whisper base bar is higher on FLEURS and a bit lower on MLS (Multilingual LibriSpeech), but those bars carry no numbers. It gets interesting with size: 17 MB against 145 MB for Whisper base. Then there's speed. On an M4 Pro, Cactus measures 11.1 ms to the first token and 1,319 tokens per second. Whisper base gets 73.2 ms and 266 tokens/s, Moonshine tiny 22.8 ms and 262 tokens/s. Vendor numbers again.

On accuracy, Parakeet and Whistle are far apart. If I average Parakeet's own FLEURS results over Whistle's seven languages, I get about 5.2, while Whistle is at 21.4. Even with a generous allowance for different measuring methods, that leaves roughly a factor of four. Then again, Parakeet is more than 40 times the size.

Nemotron is designed for streaming: a cache-aware FastConformer with an RNN-T decoder that only computes new audio chunks and keeps the encoder context cached. You pick the chunk size at runtime, from 80 ms to 1.12 s. For the English version, the average WER goes from 6.93 to 8.43 when you drop from 1.12 s to 80 ms. For Nemotron 3.5 on German (FLEURS) it's 8.31 and 9.81.

There are two more options for the browser. Chrome's Web Speech API can now recognize speech on the device, but only if you set processLocally to true. Without it, the browser decides for itself, and the audio may well end up on a server.

For Parakeet there's also a community ONNX port that runs on WebGPU through onnxruntime-web. The encoder is fp16 and 1.24 GB, because the int8 variant gives wrong results under WebGPU. The position embeddings cover about 35 seconds, so you chunk longer recordings yourself, and you write the TDT decoding yourself too. Doable, but a different calibre than 17 MB.

What I'd use for what

For anything that has to run in the browser or on small hardware without a GPU, I'd take Whistle: dictation, short voice commands, a search bar with a mic button, subtitles for your own short clips. A 17 MB download is fine there, 700 MB is not. I'd only run an always-open microphone with a VAD in front, though.

If there's a server with an NVIDIA GPU and accuracy matters, Parakeet is the better choice. For long meetings or interviews whose transcript someone will actually read, 26 % WER on AMI is just too much. For German and the other European languages, Parakeet is the most accurate of the open models I've looked at.

Nemotron pays off once latency matters, say for a voice agent that starts answering while you're still talking. Then the en version for English and 3.5 for the rest.

And Whisper stays the pick when you need a language none of the others support. Nobody else here does 99 languages, and the ecosystem around it is huge.

As for the PoC, I'm sticking with Whistle. The page loads a little over 17 MB once and then works on a plane.

Who actually reviews the code the AI writes?

2026-10-20T09:00:00+00:00

(Translation was done by AI. Sorry :/)

At work, agents now write a decent part of our new code. That is fast. Very fast. And we do it even though (or precisely because?) we are experienced developers, some of us with 15+ years in the industry.

The problem comes afterwards, in the pull request. Either it is slow, or it is not thorough enough, or the understanding is simply missing. Lately I have been sitting in front of 900-line diffs that nobody on the team typed themselves, asking myself: who actually understands this right now? Honestly: not me anymore. And since I am not exactly the passive team member type, I needed a solution :D

But it is 2026. So I had three AIs (Claude, ChatGPT, Gemini Argon) research the topic independently, added my own experience, merged everything and looked up the contested numbers in the original sources. Brave new world...

Here is the short version.

The work has moved

We write more code but barely ship more. The DORA 2025 report (about 5,000 respondents) links AI adoption to higher throughput and higher instability at the same time. DORA calls the extra checking effort the "verification tax". Faros AI telemetry (10,000+ developers, vendor data, so take it with a grain of salt) shows the mechanism: 98% more merged PRs, PRs 154% larger, review time up 91%, no gain at company level.

Keep in mind that the DORA report is from 2025, and in the last six months alone we have made huge jumps with Opus 5, Fable & co. Still, my guess is that the gap has only widened since then. The agents write faster, and reading still happens at the same speed.

The bottleneck has moved from typing to reading.

I am clearly not alone with this. There is an Ask HN with hundreds of comments right now on how to deal with shipping AI-written code you do not understand. It started with a Meta engineer whose own code now feels like a black box to them. A senior engineer with ten years of experience writes there that nobody can seriously review thousands of changed lines a week, and sums up their daily routine like this:

"I just approve PRs, because I have to."

That is exactly where I do not want to end up. By the way, the top answer in the thread is pretty much my station 1 further down: the human does the design, the agent only fills in the gaps.

Three things that worry me

1. We lose our understanding of our own code. In 1985 Peter Naur wrote in Programming as Theory Building that a program is a theory held by the team: why it is built this way and how it reacts to change. That theory used to form as a side effect of writing. If an agent plans, writes and tests, the side effect is gone. In a randomized trial by Anthropic (52 developers, January 2026) the AI group scored 17% lower on comprehension. The interesting part is the split inside that group: people who asked the AI to explain things scored 65 to 86%. People who just delegated scored 24 to 39%. There is even a name for it now: "comprehension debt", meaning code the team accepted before anyone could explain it.

2. Security. Veracode tested over 100 models: without security guidance in the prompt, 45% of the samples contained a known flaw, and that did not improve across model generations. Then there is a lovely new attack: almost 20% of the packages AIs suggest do not exist, and many of the invented names come back on every run. Attackers simply register them in advance ("slopsquatting"). And in April 2026 researchers showed that prompt injection in PR titles and comments makes several AI review bots leak CI secrets.

You can watch what this looks like at scale in public, by the way. The Claude Code issue tracker (CLI and desktop app), a project written to a large part by its own agent, currently has about 14,700 open issues against roughly 86,000 closed ones. So a good one in seven issues is still open. curl, maintained by humans the old-school way, sits at 15 open against about 5,600 closed. It is not a clean comparison (user base, age and release cadence are completely different), but it matches my gut feeling pretty well.

3. Responsibility. AI helps with review, just not very well. On SWR-Bench (1,000 real PRs) the best tool reached an F1 score of 19%. Important: the paper is from September 2025, so it tested models that are already two generations old. The number is surely better by now, but still far from a reliable gate. In a study across 178 repos, 1 to 19% of AI comments led to a code change, against 60% for human comments.

The Linux kernel settled this cleanly in 2026: an AI may not add Signed-off-by, and the human who submits is responsible for all of it. That is also the only approach that works. Neither OpenAI nor Anthropic take responsibility for the code their models generate. Whoever checks it in owns it.

What I take from it

Keep the pull request, give it a new job. To me a PR is now a package a human can check: what is supposed to happen, how do I see that it works, where is the risk, and who owns it.

And a PR has to create understanding again, the way writing used to as a side effect. That only happens if the human author goes through and edits the AI's work before anyone else looks at it. Passing the PR along just moves the understanding to the reviewer, who has just as little context.

Five stations for that:

Intent first. Before an agent starts, there is a ticket with acceptance criteria, invariants and what is explicitly out of scope. Otherwise an AI ends up checking the code against itself.
Author check. Read the full diff, rework what does not fit. Write the PR description in your own words. Mark AI use with an Assisted-by trailer.
Automated gates. Tests, types, linters, SAST, secret scanning, dependency checks (does the package even exist, how old is it).
AI review. Runs in a sandbox without secrets, writes comments, cannot approve anything.
Human reviews and merges. How deep depends on the risk. Docs and formatting: one reviewer is enough. Auth, crypto, personal data, CI/CD: code owner or security review, no exceptions.

Plus a few rules I mean quite seriously:

If you cannot explain the essential logic of your change, you get the PR back. No matter who wrote it.
An approval means "I could maintain this". It does not mean "CI was green", and it certainly does not mean "the AI liked it".
PRs stay small. Google calls about 100 lines reasonable and 1,000 too much. I start with a soft limit of around 400 lines.

Garbage in, garbage out

An agent works only as well as the ticket it gets. That was never different for humans. What is new is that most models do not notice on their own when information is missing. If they are allowed to ask clarifying questions, performance goes up by as much as 74% according to Ambig-SWE.

I do not write tickets myself, but this is how I want them: written for two readers. The colleague who joins next year, and an agent that knows nothing outside the repo.

In practice: name modules and files, point to the existing implementation to follow, put quality goals in numbers ("under 16 ms", not "fast") and say how to verify it.

And this one matters: decisions go into the ticket or an ADR when they are made. Chat logs and agent sessions disappear at some point, and the reasoning with them.

Conclusion

I can already guarantee that this will not fly in a post-mortem: "The AI wrote it". "Another AI reviewed it" will not work either.

For me that means: the tools can write as much as they like. A human has to understand it and sign it.

I am in the middle of proposing this approach to my team, and hopefully we will try it over the next few weeks. With numbers before and after: review time, PR size, defects after merge and whether a second engineer can explain a critical change. Once there are results, I will write about them.

Sources (selection)

DORA, State of AI-assisted Software Development 2025
Anthropic, How AI assistance impacts the formation of coding skills, January 2026
Comprehension debt study, arXiv:2607.10856, 2026
Spracklen et al., We Have a Package for You!, USENIX Security 2025
Zeng et al., SWR-Bench, arXiv:2509.01494
Sun et al., Does AI Code Review Lead to Code Changes?, arXiv:2508.18771
Vijayvargiya et al., Ambig-SWE, arXiv:2502.13069
Naur, Programming as Theory Building, 1985
Linux kernel, Documentation/process/coding-assistants.rst

What Is My Purpose?

2026-10-16T13:00:00+00:00

Since agents type most of the code, a good chunk of my day is reviews. Not a complaint, review was always the part that really mattered. Still funny when the colleague who was supposed to take work off your plate has the same existential crisis you had.

Creative Limitations

2026-10-09T13:00:00+00:00

The first strip of the series, and right away a bit meta. Yes, the strips here are AI-generated, and yes, that's exactly what people are fighting about right now. The robot still has a point: the tired developer at his desk joking about tech debt was a genre of its own long before image generators.

From now on I'd like to put out one of these every Friday ;).

Brooks's Law, Now With Agents

2026-08-06T09:00:00+00:00

(Translation was done by AI. Sorry :/)

This post is not going to be particularly useful, but I need to get the topic off my chest: I have seen the following pattern in several projects, and it always runs the same way.

Months pass without anyone committing to a date. Then a date shows up somewhere in a slide/mail/meeting, because it was promised to the outside world, and suddenly a half-finished state has to be done in six weeks. In the meeting after that comes the suggestion from the C-level that I have learned to expect:

... more resources.

The odd part is that the suggestion comes even more reliably the shorter the remaining time is. With six months left, people discuss scope. With six weeks left, two extra developers from another project. Fred Brooks wrote down what happens then, in 1975:

"Adding manpower to a late software project makes it later."

That is Brooks's Law, from The Mythical Man-Month. Brooks had the material first hand back then: he managed the development of OS/360 at IBM. With thousands of people involved, every date was missed anyway. The problem he identified is the unit itself. Cost scales with people times months, progress explicitly does not.

Why short deadlines make it worse

Ramp-up eats exactly the window that is left. Anyone joining has to be taught by the people who already are the bottleneck. With six weeks to go, that is the entire six weeks.

Then there is coordination. With n people there are n(n-1)/2 possible channels, four people have six, eight people have twenty-eight. Every one of them is a chance for two different assumptions about the same interface, and those only surface during integration week.

Most expensive of all, much of the work is sequential. Until the schema is migrated, nobody can rebuild the endpoint on top of it. A second developer then waits exactly as long as the first one, only on payroll.

What would have helped

Brooks's own answer is uncomfortable and still the only one:

Cut scope or move the date.

In the projects that did turn out fine, there was an honest list at the start of what really had to work on the date. The rest shipped one release later, and nobody outside the team noticed.

And that is exactly the option that always gets ruled out. Possibly even for good reasons (usually something along the lines of "time2market beats quality"), but that does not change the fact that certain things are incompatible with reality.

And with agents?

Since I started running several Claude instances in parallel, the question comes up again, this time without payroll. One of the three causes does fall away: ramp-up costs almost nothing, the context lives in AGENTS.md (or CLAUDE.md or GEMINI.md) and gets reused per agent. The sequence stays, the dependency graph does not care who sits in front of it. And coordination comes back as duplicated work: two agents refactoring the same helper, each of them plausible.

Plus a bottleneck Brooks did not have. I am the only one allowed to accept a result. Three agents in parallel help me, at ten I am just reading diffs and deciding worse and worse. What does scale is the deterministic part of review: linters, type checking, tests and pre-commit hooks judge as fast for ten agents as for one. Exactly the argument from part 5 of the tooling series (yes, that is shameless self-promotion :D).

After 51 years, one of the three causes has fallen away and a fourth has been added. For that meeting with six weeks left and the suggestion from above, the arithmetic comes out the same as in 1975.

(Most of the numbers and examples are adapted and based on old experience, and have nothing to do with any current events.)

Modern Tooling Part 5: The toolchain as a corset for AI agents

2026-07-26T12:00:00+00:00

In Part 1 I wrote about two upheavals: the Python ecosystem is moving to Rust-based tools, and more and more code is written by AI. The four parts before this one worked through the first upheaval. This bonus part adds the second, because the two fit together better than it first looks.

In short: the same uv, ruff, ty and prek checks that make my work easier are also the corset that makes an AI agent productive and (more) trustworthy.

Why an agent needs guardrails

An AI agent writes plausible-looking code in seconds. Often it's still wrong: it invents APIs, misses None/null cases, ignores the project's architecture boundaries, or just pulls in a new dependency. Review all of that by hand and the speed gain is gone immediately.

So I give it an environment where mistakes show up instantly and deterministically. I'd built the toolchain for exactly that anyway (and used it this way long before AI).

The same checks, now as a feedback loop for the agent

I don't need a new setup for the agent. The checks from parts 2 to 4 are already a machine-readable, deterministic truth about the code:

uv run ruff check --fix . cleans up and reports what it can't fix itself
uv run ty check catches type and None errors before they become runtime errors
uv run bandit and import-linter guard security and architecture
uv run pytest tells me whether the code still does what it should

The agent gets these commands (for me in an AGENTS.md, with a CLAUDE.md/GEMINI.md pointing to it) and works in exactly the loop I use as a human: write, check, follow the errors, fix, repeat. The only difference is that it runs the loop far more often and faster.

Why speed becomes a prerequisite

In the earlier parts, speed was "just" comfort. With an agent it becomes a prerequisite. A check that takes 30 seconds kills an agent's loop the same way it kills mine, except the agent might want to check twenty times a minute. Only because ruff and ty answer in the millisecond range can the agent iterate tightly. With slow checks it waits minutes after every step or, worse, skips them entirely.

The corset: rules the agent can't get around

My select = ["ALL"] strategy from Part 2, the strict type discipline from Part 3, and the architecture rules from Part 4 are more valuable for an agent than for me: they fix the shape of the project. The agent is free to be productive, but only within that shape.

There's no negotiating with it. The pre-commit hook blocks bad code before it reaches the history, and CI catches the rest (including the --no-verify of an over-eager agent). The agent can argue as convincingly as it likes, the red check stays red.

Conclusion

The two upheavals from Part 1 belong together. A fast, strict, deterministic toolchain is the precondition for AI-assisted development not ending in a pile of plausible but broken diffs.

The series:

Part 1: uv
Part 2: ruff
Part 3: ty
Part 4: prek
Part 5: a corset for AI agents (bonus, this part)

Modern Tooling Part 4: High-performance Git hooks with prek

2026-07-20T21:00:00+00:00

Over the course of this series I've rebuilt my Python stack with uv (Part 1), ruff (Part 2) and ty (Part 3). In Part 4 I bring it all together: the checks should run automatically, before code even reaches the repository. Nobody feels like running this stack of tools by hand all the time.

Git hooks as a quality gate

Every check that only fails in CI is a delay and pulls me out of my tasks: write, commit, push, wait five minutes, red pipeline, fix, "Fix linting" commit, push again. A pre-commit hook moves exactly those same checks to the earliest possible point: errors get fixed before they land in the history, and CI turns from the thing that finds errors into a pure safety net.

The bottleneck with classic pre-commit

The pre-commit framework has been a standard for this for years. Tools like lefthook or husky are great too. But prek is fast and, thanks to its compatibility with pre-commit, my tool of choice. Because pre-commit has a few downsides: it's a Python package itself, isolates every hook in its own virtual environment, and runs hooks sequentially. The first git commit after a fresh clone can take minutes while environments are built.

prek

prek is a reimplementation of the pre-commit framework in Rust that reads the same .pre-commit-config.yaml, just with smarter caching and without the virtualenv overhead:

# Installation (a single static binary, no Python needed)
uv tool install prek
# alternatively via brew/pacman/apt/etc.

# Enable the git hook in the repository (once per clone)
prek install

# Run hooks manually
prek run                # against staged files
prek run --all-files    # against the whole codebase
prek run gitleaks --all-files  # a single hook specifically

My hook setup in detail

The .pre-commit-config.yaml of my template chains together everything I built in the last three parts. I split the hooks into two kinds:

Remote hooks come from foreign repositories: the basics like YAML/TOML validation, trailing whitespace, and the secret scanner gitleaks:

- repo: https://github.com/pre-commit/pre-commit-hooks
  rev: v6.0.0
  hooks:
  - id: check-yaml
  - id: check-toml
  - id: check-merge-conflict
  - id: trailing-whitespace
  - id: end-of-file-fixer

- repo: https://github.com/gitleaks/gitleaks
  rev: v8.30.1
  hooks:
  - id: gitleaks

Local hooks, on the other hand, run via uv run in my project environment. That way ruff, ty and bandit check with exactly the versions pinned in uv.lock:

- repo: local
  hooks:
  - id: ruff-format
    name: ruff format
    entry: uv run ruff format
    language: system
    types: [python]

  - id: ruff-check
    name: ruff check
    entry: uv run ruff check --fix
    language: system
    types: [python]

  - id: ty
    name: ty-check
    entry: uv run ty check --verbose --output-format=full .
    language: system
    types: [python]
    pass_filenames: false

  - id: bandit
    name: bandit
    entry: uv run bandit -r src/app -c pyproject.toml
    language: system
    types: [python]
    pass_filenames: false

On top of that there's import-linter, which guards my architecture: it fails as soon as someone imports infrastructure from the domain layer. That turns the architecture rules into an executable check.

One commit, the whole quality gate

With that, every git commit automatically runs: formatting, linting with auto-fix, type checking, security scan (bandit), secret scan (gitleaks) and the architecture check. Thanks to prek largely in parallel and within a few seconds, fast enough that nobody is tempted to switch it off.

For emergencies there's still the back door:

git commit --no-verify

But that's exactly what CI is the safety net for (well, that and the cases where someone forgot to run prek install): there the same checks run again (ruff format --check, ruff check, ty check, bandit, lint-imports, pytest), just as the last line of defence.

Series conclusion

These four tools, uv, ruff, ty and prek, each replace a slow, fragmented part of the Python toolchain with a fast Rust binary, while staying compatible with what they replace (pyproject.toml, Black formatting, .pre-commit-config.yaml).

And if I'm honest, they're usually the first tools of their kind that fit: a codebase that was already perfect here is something I've never seen before.

The series:

Modern Tooling Part 3: The future of type checking with ty

2026-07-20T07:32:00+00:00

So far in this series I've sorted out package management with uv (Part 1) and linting with ruff (Part 2). Part 3 is the most demanding piece of static analysis: type checking.

Why type checking?

I really got into type checking back in the PHP days, through phpstan/psalm. It felt like the validation I knew from other languages was finally arriving in the scripting languages too. YES: it's a bit more work, and of course arrays (PHP) or lists aren't quite as flexible anymore. But throwing everything in there was never a good idea anyway. So for me type checkers enforced sensible behaviour.

The main reason for me, though, is that type checkers in scripting languages simply wipe out entire categories of bugs. Combined with linters, you should have far fewer (or even zero) None errors left in Python. Used consistently, you avoid a lot of problems, e.g. unhandled logical branches in match/if-elif-else cascades.

And finally: code completion. With AI that matters a bit less these days, but every modern IDE can read these type hints and make useful suggestions. The success of FastAPI/pydantic rests partly on exactly that: the DX (developer experience) is so good!

In my template with a hexagonal architecture, types are even load-bearing: the ports are defined as abstract, fully typed interfaces:

class ItemRepository(ABC):
    @abstractmethod
    async def save(self, item: Item) -> Item: ...

    @abstractmethod
    async def by_id(self, item_id: UUID) -> Item | None: ...

A type checker makes sure every adapter fulfils this contract exactly, and that nobody forgets to handle the None case of by_id.

The catch was always the price: mypy gets noticeably slow on growing codebases. And a check that takes 30 seconds stops being run locally, it moves into CI, and type errors only surface after the push. Exactly the feedback-loop problem that ruff solved for linting still existed for type checking.

ty

ty is Astral's answer to that: a type checker written in Rust, built for massive parallelism, that slots directly into the uv/ruff toolchain. The check runs so fast that it fits into any pre-commit hook without trouble:

uv run ty check

A typical finding looks like this, where someone forgets that by_id can also return None:

item = await repository.by_id(item_id)
print(item.name)  # error: `name` on `Item | None`, `None` has no `name`

At runtime that would be an AttributeError in production. With ty it's a red line before the commit even exists, or depending on your CI tooling even a prevented commit or merge.

My type discipline

Important for context: the rule that every function, variable and class must be fully typed and that Any stays the absolute exception is a project rule of my template. ty is the tool that makes it enforceable, together with ruff's ANN rules that flag missing annotations.

In the pre-commit hook the check runs across the whole codebase:

- id: ty
  name: ty-check
  entry: uv run ty check --verbose --output-format=full .
  language: system
  types: [python]
  pass_filenames: false

pass_filenames: false is set deliberately here: type checking only makes sense across the whole project, since a change in file A can trigger a type error in file B. Thanks to ty's speed I can afford the full check on every commit. Nice :).

In the editor

ty also ships its own language server: autocompletion, hover, go-to-definition and auto-imports, all at ty speed.

VS Code: There's an official ty extension from Astral. It automatically turns off the Python extension's language server (sets python.languageServer to None) so you don't run two language servers at once.

PyCharm: From version 2025.3 on, ty is built in. Tick Enable under Settings → Python | Tools → ty. PyCharm then picks up the ty version installed in your interpreter.

Underneath it's always the same language server, which you can also start manually (uv run ty server), e.g. for Neovim.

Caveats

ty is young. My template pins it to ty==0.*: the zero before the dot isn't always meaningful in the open-source world. Here it does hold, though, ty is officially still a beta up to version 0.0.61. In my opinion (very subjective!) it's already production ready, and the speed advantage is simply worth it to me.

In my Architecture Decision Records I still mark the adoption as Experimental: I'm evaluating ty as the primary type checker and watching how quickly it catches up to mypy/pyright on the more complex typing PEPs (generics, ParamSpec, overloads).

For a template and greenfield projects the risk is manageable, the type constructs there are rarely exotic. Anyone with a large existing codebase and elaborate mypy plugin setups should weigh the switch consciously, though: mypy currently still has more complete rule coverage.

Conclusion

The real win of ty is a type checker that runs fast: locally, on every commit, without anyone having to wait. Type discipline only sticks when the feedback is fast.

The series:

Modern Tooling Part 2: Consistent Linting and Formatting with ruff

2026-07-16T17:14:00+00:00

After tidying up package management with uv in Part 1, today I want to deal with ruff in Part 2.

Toolchain soup

"Code quality" long meant chaining four or five tools together:

Black for formatting
Isort for import sorting
Flake8 (or pylint) for linting (plus a dozen plugins)
pyupgrade for modern syntax
and Bandit for security checks

Here too the rule held: every tool has its own config file, its own version and its own conflicts. Black and Isort, for example, had to be explicitly aligned so they didn't keep reformatting each other's imports.

And it was slow. On medium codebases these checks ran for seconds, sometimes even minutes. Imho too slow to run on every save or commit. I still kept them on, was usually already onto the next problem, and got promptly kicked back because of some trivial issue. So more than once I disabled them and forgot to run them again at the end, only to get annoyed by a red CI pipeline.

ruff!

ruff is linter and formatter in a single Rust binary. It implements the rules of Flake8 (including the popular plugins), Isort, pyupgrade and large parts of Bandit, and formats Black-compatibly (with minimal deviations). The runtime stays in the millisecond range even on large codebases, which makes a decisive difference:

Checks that are instant run on every save in the editor, on every commit and in CI. Checks that take seconds eventually only run in CI. Together with --fix, simply brilliant tooling that also works independently of the IDE <3.

The two commands you need:

# Find linting errors and fix them automatically where possible
uv run ruff check --fix .

# Format the codebase
uv run ruff format .

In CI I flip it around and only check:

- name: Formatting Check (Ruff)
  run: uv run ruff format --check .

- name: Linting Check (Ruff)
  run: uv run ruff check .

My configuration: opt-out

Most projects enable a handful of rule groups and add more over time. My template goes the other way: all rules on, and every exception has to be justified. That forces a deliberate decision on each ignore, and documents the decision right there:

# Part of pyproject.toml
[tool.ruff.lint]
# I want to be strict and only opt out deliberately!
select = [ "ALL" ]
fixable = [ "ALL" ]

ignore = [
  # strict
  "D102",    # would require docstrings for every public method
  "D203",    # incompatible with D211 (no blank line before class docstring)
  "EM101",   # would force exception texts into variables first

  # incompatible with "ruff format"
  "COM812",

  # temporary - as an example
  "TC003",   # would enforce TYPE_CHECKING blocks.
]

The comment behind each rule is the core of the strategy: a year from now nobody remembers why COM812 is off, unless it says so right next to it.

Per-file ignores: tests are different

Rules that make sense in production code are often just noise in tests. assert is the normal case in tests (in production code the Bandit rule S101 forbids it), and "magic numbers" in a test case are simply the test data:

# Part of pyproject.toml
[tool.ruff.lint.per-file-ignores]
"tests/*" = [
    "ANN201",   # return annotations for test functions: unnecessary
    "PLR2004",  # magic values in comparisons: those ARE the test data
    "S101",     # assert is essential in pytest
]

Import sorting included

Isort is on board right away as rule group I. So that the sorting stays deterministic even in edge cases, I declare explicitly what is third-party and what is my own code:

[tool.ruff.lint.isort]
known-third-party = ["fastapi", "pydantic", "starlette"]
known-local-folder = ["app"]

Quick reminder: isort makes sure the import blocks are roughly split into 3 categories:

"batteries included" imports, e.g.: from math import sqrt
third-party imports: from fastapi import FastAPI
project imports: from my_project.domain import ImportantClass

And within the blocks, alphabetically.

In the editor: feedback as you type

The biggest win comes when ruff already runs as you type.

VS Code: The official Ruff extension (by charliermarsh/Astral) handles both linting and formatting. What matters to me is that it uses the version pinned in the project: ruff.importStrategy defaults to fromEnvironment, so it picks up the ruff from the uv environment instead of the bundled one.

// .vscode/settings.json
{
  "[python]": {
    "editor.defaultFormatter": "charliermarsh.ruff",
    "editor.formatOnSave": true,
    "editor.codeActionsOnSave": {
      "source.fixAll.ruff": "explicit",
      "source.organizeImports.ruff": "explicit"
    }
  },
  "ruff.importStrategy": "fromEnvironment"
}

The .ruff suffix on the code actions pins the fixing and import sorting to ruff. Without it, some other formatter can grab the job by accident.

PyCharm: From version 2025.3 on, Ruff support is built in. Enable it under Settings → Tools → Ruff, and Reformat Code and Optimize Imports will use ruff. For older versions there's the Ruff plugin by koxudaxi. In both cases it's worth pointing it at the ruff from the project environment rather than a globally installed one.

Conclusion

ruff replaces four config files with one block in pyproject.toml and makes linting so fast that there's no excuse left not to run it everywhere. The opt-out strategy with select = ["ALL"] is deliberately radical: it costs a bit of time to set up, but in return you get a ruleset where every exception is a documented decision.

The series:

Modern Tooling Part 1: Blazing-Fast Package Management with uv

2026-07-13T19:50:00+00:00

Hey and welcome to my series on modern Python tooling: four parts on the tools themselves, plus a bonus part on AI agents. I'm writing it now because the Python ecosystem is going through an upheaval. Several, in fact:

The Python ecosystem is being replaced in large part by Rust-based tools. I largely have Astral to thank for that.
Ever-larger parts of development are being done by AI from various vendors, and keeping it under control leads to growing problems.

Conveniently, these two shifts fit together perfectly.

So my goal is first to introduce these new Rust-based tools, and then to show how they help in AI-driven development. I'll look at four+ of these tools along a real FastAPI project template: uv, ruff, ty and prek (+more mini tools).

Part 1 (this one) is about the foundation: uv.

The problem I see: five tools for one job

Anyone who wanted to set up a Python project cleanly used to need a whole toolbox:

pyenv to install the right Python version
venv or virtualenv (I've also used pipenv) to create an isolated environment
pip to install packages
pip-tools, pip freeze (or poetry) to lock dependencies
plus the source .venv/bin/activate ritual (often automated via a zsh/bash script)

Each of these tools has its own configuration (including its own config formats), its own quirks and its own failure modes. The result: "works on my machine". Thrown in for free, you get a CI pipeline that spends minutes resolving dependencies.

The solution: uv, a single binary

uv replaces the entire stack with a single Rust binary. It's package installer, environment manager, dependency resolver and Python version manager in one. And it's orders of magnitude faster while doing it.

Installing it is quick:

curl -LsSf https://astral.sh/uv/install.sh | sh
# or on macOS:
brew install uv

(As always: read the install script first, or even download it first and then run it. For simplicity, only the direct step from the docs is shown here.)

Workflow

After that, day-to-day Python comes down to three commands:

# Install dependencies from the lockfile (incl. venv creation)
uv sync

# Add a package: updates pyproject.toml AND uv.lock
uv add fastapi

# Run any command in the project environment
uv run pytest

So there's no more activate. uv run makes sure the command runs in the right environment and that this environment matches the lockfile. If it doesn't, uv syncs it beforehand automatically. With uv venv (optionally with --python 314) you can also create a venv environment separately. Alternatively, you can add a .python-version file to the project with the content 3.14. Then uv simply downloads the matching interpreter on demand. pyenv becomes unnecessary.

Dependency groups tame requirements sprawl

Instead of requirements.txt, requirements-dev.txt and requirements-test.txt, my template defines everything in pyproject.toml, using the standard for dependency groups (PEP 735), including groups that include other groups:

[dependency-groups]
dev = [
  "prek==0.4.9",
  { include-group = "tests" },
  { include-group = "lint" },
]

tests = [
  "httpx==0.*",
  "pytest==9.*",
  "pytest-asyncio",
]

lint = [
  "ruff==0.*",
  "ty==0.*",
  "bandit==1.*",
  "import-linter>=2.11",
]

uv sync installs the dev group by default, uv sync --no-dev leaves it out. Perfect for the production environment. Further flags for the groups are --all-groups or, very specifically, --group lint|tests|dev.

Reproducibility: uv.lock

Important for stable deployments is uv.lock: it pins every dependency (including sub-dependencies) with an exact version and hash, across platforms. In CI and Docker I use --frozen to enforce that the lockfile is current. If pyproject.toml diverges from it, the build fails instead of quietly installing something else.

Here's how that looks in an example Dockerfile from my template (multi-stage, with a cache mount):

# Deliberately not alpine, since that's often extra work right now with binary
# builds (e.g. psycopg2/etc.).
FROM python:3.14-slim AS builder

ENV UV_COMPILE_BYTECODE=1
ENV UV_LINK_MODE=copy

# First step: have uv. There are also ready-made Docker images!
COPY --from=ghcr.io/astral-sh/uv:latest /uv /bin/uv
COPY pyproject.toml uv.lock ./

# Dependencies only first, this layer gets cached
# as long as the lockfile doesn't change
RUN uv sync --frozen --no-dev --no-install-project

# Then the source code -> frequent changes
COPY src ./src

# Install using the cache (makes a huge difference, especially in CI)
RUN --mount=type=cache,target=/root/.cache/uv \
    uv sync --frozen --no-dev

And in the GitHub Actions pipeline, the official action handles setup and caching in a single step:

- name: Install uv
  uses: astral-sh/setup-uv@v8.2.0
  with:
    python-version: "3.14"
    enable-cache: true

- name: Install dependencies
  run: uv sync --all-groups

Conclusion

uv needs less configuration than the old stack and is still noticeably faster. It's the reason every following part of this series starts with uv run ....

Bonus feature: running scripts with inline dependencies. Perfect for DevOps and the like. :)

The series:

Claude Code, Claw Code and the End of Secrets?

2026-05-04T12:00:00+00:00

Sorry for the long silence! Quite a bit of time has passed since the last post. I've still got a whole pile of drafts sitting around (.md.draft), but when I look at them, they all need a serious overhaul first, the world (and especially the AI world) is just moving too fast ;).

But right now it's precisely this AI thing keeping me occupied, and I'm missing a voice that's neither swept away by the hype nor hiding in a cave ignoring current developments. So I'm just going to do it, even written entirely without AI.

Claude Code first, since it's fairly clearly leading the popularity charts among developers. It's already fascinating (and a bit ironic) that a tool designed to help us write code released its own source code, even after Mythic (the thing so good it had to be kept from the public) was already in use; or because of it? 🤔 Some might remember similar claims around GPT-5.

Claw Code

Anyone who wants to look at the whole thing in detail (while it's still online) should check out Claw Code. The project essentially "deductively" processed the leaked code and made it accessible. It's a fascinating piece of software architecture showing how Anthropic orchestrates the interaction between LLM and local shell.

The legal side: DMCA Whack-A-Mole

Of course Anthropic finds this less amusing. There have apparently been over 8,100 takedown requests already. Heise published a very good article about it that untangles the legal side. It's the classic "birth of a tool from a leak", and the desperate attempt to put the cat back in the bag.

I find this quite telling about the current state of AI:

The tools are becoming more powerful, but also more complex.
Code (and bugs) are being produced faster and getting less and less genuine review.
"Security by Obscurity" works even less with AI than it did before.

I'm still thinking about whether to write a deeper article specifically about AI Guardrails, a kind of safety corset for AI. I have the feeling this is still missing for many people, even though it's really a pretty low-hanging fruit.

Immutability / Const vs Let

2024-12-06T09:34:00+00:00

tl;dr

Use const over let
Make your variables immutable as often as possible

I will teach you about how useful immutability is and how to use it in typescript (but similar concepts apply to other languages as well).

What is immutability?

Basically the name describes it already: Making stuff immutable: Not changeable. In typescript all basic datatypes are immutable!

So when you do:

let a = 5;
let b = a;
a = 123;
// 5 still exists in memory

b = 42;
// 5 will be garbage collected soon

Just as a hint to future content: immutability is a major part in functional programming ;). To dive deeper into (im)mutability let's start with an example:

let helloWorldString = "Hello World!"; // immutable
helloWorldString = "Hello Moon!"; // no error, but var name no longer correct!

// vs:

const helloWorldString = "Hello World!"; // immutable
helloWorldString = "Hello Moon!"; // error! We can rely on the content of the var!

In the top part the stuff inside the variable changes and makes it harder to predict what's inside it.

"But what about counter variables? I NEED to count stuff all the time!?"

Correct. Let's break this up a little:

The guideline is:

avoid mutable variables when possible
if mutable variables improve readability or are the only viable way (very seldom): go for it

When I say "seldom" I mean that in many cases Type/Javascript will give us a way to avoid counter variables:

let uppercaseNames = [];
for (let name of ["alice", "bob", "charlie"]) {
  uppercaseNames.push(name.toUpperCase());
}

// Functional approach
const uppercaseNames = ["alice", "bob", "charlie"].map((name) =>
  name.toUpperCase(),
);

Obviously this example is trivial, but in any way: We KNOW that uppercaseNames will contain exactly what it tells us, as soon as it's defined!

Why

Immutability doesn't mean all the way and also doesn't mean that mutable stuff is inherently bad, but it definitely removes some footguns, when programming and debugging.

Biome has a lint lint/style/useConst forcing us to use const when a variable is never reassigned, but I'd go further and replace lets as often as possible by const.

Imagine the following:

const mutateVar = (innerA) => {
  innerA = 9;
  return 12;
};

let outerA = 123;
const result = mutateVar(outerA);
// no change due to pass-by-value for elemental types
console.log({ result, outerA });

// But:
const mutateObj = (obj) => {
  // sideeffect we don't know about when reading function name:
  obj.x = 123;
  return obj;
};

const originalObject = { a: 42 };
const mutatedObject = mutateObj(originalObject);
console.log({ originalObject, mutatedObject });

We expect originalObject to be still the same and mutatedObject to contain the new value. If we try to remember to not change existing objects and also use const we will never be surprised by behaviour inside a function.

Functions which don't mutate parameters and are solely depending on parameters are called pure functions. A concept which has various advantages over unpure functions. But I'll go into that in the next article.

But const objects are NOT immutable

Right. Especially because of javascript, but other languages like python/php/etc. have similar problems. Fortunately with typescript we have powerful tools at our hands: Readonly, readonly and as const.

// Readonly
type Tree = { name: string };
const ahorn: Readonly<Tree> = { name: "ahorn" };
ahorn.name = "bhorn"; // typescript error

// As const
const ahorn = { name: "ahorn" } as const;
ahorn.name = "bhorn"; // typescript error

// readonly
class Tree {
  constructor(readonly name: string) {}
}

const t = new Tree("ahorn");
t.name = "asdf"; // typescript error

What about string builders

I personally prefer:

extracting the process of building a string into a function
having a template in the end where the various bits and pieces fit into

And then use the result:

/** Approach of most people */
function greetCustomer(customer) {
  let message = "";
  if (customer.age > 15) {
    message += "Good day sir,\n";
  } else {
    message += "Hey little one,\n";
  }

  if (customer.hasEaten) {
    message += "Can I offer you something to drink?";
  } else {
    message += "Can I offer you our lunch menu?";
  }

  console.log(message);
}

// vs what I prefer
function buildGreeting(customer): string {
  const greet = customer.age > 15 ? "Good day sir" : "Hey little one";
  const offer = customer.hasEaten ? "something to drink" : "our lunch menu";
  return `${greet},\nCan I offer you ${offer}?`;
}

function greetCustomer(customer) {
  const greeting = buildGreeting(customer);
  console.log(greeting);
}

I think this is better as it

reduces the complexity making it more visible how the final text is structured.
reduces indentation. Another topic I'd like to cover soon!
We extracted the logic into a pure function while having the side effect function only using this
That again makes the buildGreeting function easier to test as we don't rely on catching console output

Linters & Stylecheck

2024-12-02T09:00:00+00:00

Stylecheck

Let's start with the simpler issue: Stylechecks. It all boils down to maintaining the same style over the full application. It doesn't really matter WHICH style, but it must be the same!

Why?

Pattern matching: Regardless of developer level it makes it easier to recognize patterns if they all are in the same structure
Git Diffs: Having multiple styles might result in a back-and-forth of changes each time different styles collide
Tools: Having a tool which can format your code and auto apply its rules may help a lot!

Tools

prettier is the more commonly known tool for this
But I prefer biome as it is faster and can also take care of linting
- It's also 97% compatible with prettier (same rules) - the differences are reasonable
- It can format: JavaScript, TypeScript, JSX, TSX, JSON, CSS and GraphQL

Examples

Trivial: using the same kind of quote ' vs " where applicable or the same amount of spaces
Readability: Splitting multiple lines of import if the line gets too long

Trivial: Spacing

// FROM
@Injectable()
export class JwtService {
    
    decodeToken (token: string): any {
        return jwt.decode(token);
    }
}

// TO
@Injectable()
export class JwtService {
    decodeToken(token: string): any {
        return jwt.decode(token);
    }
}

or tabs vs spaces

// FROM 2 spaces
describe('ReportsController', () => {
  let controller: ReportsController;

  beforeEach(async () => {

// TO tabs
describe('ReportsController', () => {
	let controller: ReportsController;

	beforeEach(async () => {

* Btw I'm a spaces guy, but convention over sympathy!

Trivial: Newlines

// FROM
@Module({
  controllers: [IntegrationController],
  providers: [IntegrationService, PrismaService, ScrapingService, CustomerIoService, JwtService]
})

// TO
@Module({
	controllers: [IntegrationController],
	providers: [
		IntegrationService,
		PrismaService,
		ScrapingService,
		CustomerIoService,
		JwtService,
	],
})

There is also the analyzer which sorts imports in a predictable manner. This is optional, but gives each header of a file the same order. For details about the order you can look here.

Linting

This is giving us a headstart on customers finding bugs. Each linter obviously has a small false positive rate, but the ruleset itself makes sure to exclude some classes of errors before they even happen!

The full ruleset of biome is here.

It has some very trivial checks like no distracting elements which prohibits marquee and blink, but also far more advanced checks.

My favorite category is nursery which contains legacy JS features which are surpassed by advanced Syntax.

Linter warnings examples

// 1. no banned types
code-block.ts:1:10 lint/complexity/noBannedTypes ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ✖ Don’t use ’{}’ as a type.
  > 1 │ const n: {} = 0
      │          ^^

// 2. complexity
code-block.js:1:10 lint/complexity/noExcessiveCognitiveComplexity ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ⚠ Excessive complexity of 21 detected (max: 15).
  > 1 │ function tooComplex() {
      │          ^^^^^^^^^^
    2 │     for (let x = 0; x < 10; x++) {
    3 │         for (let y = 0; y < 10; y++) {

// 3. for .. of  vs  Array.forEach
code-block.js:1:1 lint/complexity/noForEach ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ✖ Prefer for…of instead of forEach.
  > 1 │ els.forEach((el) => {
      │ ^^^^^^^^^^^^^^^^^^^^^
  > 2 │   f(el);
  > 3 │ })
      │ ^^

// 4. no useless catch
code-block.js:4:5 lint/complexity/noUselessCatch ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ✖ The catch clause that only rethrows the original error is useless.
    2 │     doSomething();
    3 │ } catch(e) {
  > 4 │     throw e;
      │     ^^^^^^^^

// 5. no uselss ternary
const a = foo === 1 ? false : true; // just use foo !== 1

code-block.js:1:9 lint/complexity/noUselessTernary  FIXABLE  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  ✖ Unnecessary use of boolean literals in conditional expression.
  > 1 │ const a = foo === 1 ? false : true;
      │           ^^^^^^^^^^^^^^^^^^^^^^^^

Is trivial, but don't use useless/harmful types
Is using the Cyclomatic Complexity to give upper boundaries of complex code. Is code too complex -> make it simpler. Google for McCabe Metric to find more details. Depending on the language we should try to be <10 (10 possible ways of data routes through a function) and MUST be below 15, as this would be hard to maintain.
Language features: for .. of .. is easier to read than Array.forEach(...). Also a performance issue!
obviously almost dead code which doesn't serve any function/purpose
Is a great example of FIXABLE lints: This one can be auto corrected!

... Aaaaand a lot more! We should use linters at every stage of our development process. The earlier the better and we WILL be using them soon in our processes.

Biome in your editor

For the huge amount of reasons we should use biome wherever possible.

For the most common editors here the extension/plugin so that you can benefit directly. Just make sure the red squiggly lines disappear and autoformatting is active

General and Vim/Emacs/etc.: biomejs.dev
webstorm: plugins.jetbrains.com
VSCode: VSCode Marketplace
CLI:
- npm install --save-dev --save-exact @biomejs/biome
- Format: biome format FOLDER/FILE or biome format --write FOLDER/FILE
- Lint: biome lint FOLDER/FILE or biome lint --write FOLDER/FILE
- All checks (format and lint): biome check FOLDER/FILE

Afterwards be sure to:

Set autoformat on
Actually read and see the errors supplied by the linter

Magic Numbers

2024-11-22T10:00:00+00:00

Magic numbers are numbers/string literals which are used as const and where the actual use is not directly known.

This is part of a series I do for work and is intended for junior developers and external people. When the code is generic enough I use real life examples from work, otherwise I'll just invent something ;).

The examples are in typescript as it is readable by almost all developers, but obviously the concepts are similar in other languages. Python for example doesn't really have "constants", but you can combine pure UPPERCASE with typing.Final:

from typing import Final

MAX_KNOWN_POWER_SIZE: Final[int] = 9000

This won't catch resetting the variable at runtime, but will complain when run with ruff or mypy.

Examples

HTTP Status Codes

// DONT
if (error.response.status === 409) {
    ...
}

// DO
import { HttpStatus } from '@nestjs/common';

if (error.response.status === HttpStatus.CONFLICT) {
    ...
}

Now even if we don't know all the http status codes by heart, we know we have some kind of conflict error without adding comments/complexity

Timeout

// DONT
setTimeout(() => {
    refreshData();
}, 300000); // What does this number mean?

// DO
const REFRESH_INTERVAL_MS = 300000; // 5 minutes in milliseconds
setTimeout(() => {
    refreshData();
}, REFRESH_INTERVAL_MS);

Limits: business logic

// DONT
if (user.age >= 18 && cart.total >= 50) {
    applyDiscount(cart);
}

// DO
const MINIMUM_AGE_FOR_DISCOUNT = 18;
const MINIMUM_PURCHASE_FOR_DISCOUNT = 50;

if (user.age >= MINIMUM_AGE_FOR_DISCOUNT && 
    cart.total >= MINIMUM_PURCHASE_FOR_DISCOUNT) {
    applyDiscount(cart);
}

Limits: password

// DONT
if (password.length < 8 || password.length > 128) {
    throw new Error('Invalid password length');
}

// DO
const PASSWORD_LENGTH_MIN = 8;
const PASSWORD_LENGTH_MAX = 128;

if (password.length < PASSWORD_LENGTH_MIN || 
    password.length > PASSWORD_LENGTH_MAX) {
    throw new Error('Invalid password length');
}

Python Unplugged: Mining for hidden batteries

2024-07-10T00:00:00+00:00

[ ▶ load video ] One click loads the player from YouTube, which sends your IP address to Google.

Slides (PDF): Download PDF

Repository: github.com/dev-loki/europython2024-python-unplugged-slides

What is this about?

A beginners talk about all the unknown modules of the vanilla/standard python library.

Python is required and at least a basic understanding of python
No pip install PACKAGE necessary <3
Mainly around itertools, collections and functools
Sprinkles of contextlib, urllib and other packages
Some stuff requires python3.12 (e.g. batched)

The repository contains some more code examples, which are:

more detailed
heavily commented
"complete" and executable

(english only)

Faster Workflow with Test-driven Development

2022-04-12T00:00:00+00:00

(english only)

Original Text

In this talk I will show you, that TDD is in fact not a process for testing, but a helpful way of developing, taking away a lot of the annoying "lets open the application and see if this still works" part of development.

After this talk you will know how to apply TDD to your workflow and use it to your benefit. We will clean up the popular misconception, that TDD is a technique for testing and will have a working prototype at the end.

Addendum

In this talk I showed how to do a minimal url shortener with fastapi/pytest and in style of TDD. It was almost successful, as I did not expect so many questions ;).

In general I was far too nervous to do a good job, and even though people complimented me, I think I could have done a much better job!

Learning for me: 1h 30min was too little time to dive deep into the TDD methodology. 2h would have been perfect.

My own expectation to improve this after I changed jobs with a lot of new stuff to learn.

Will there be a proper course?

Most likely, but for non conference usage I would rather do a more intense 2-4h course where I'd also cover issues like database migration and deployment.

But can I see it?

Yes, if you must :D. But beware: My english was very rusty as I hadn't spoken english for 1-2 years before that. I'm super glad it got better again with my new job :)

[ ▶ load video ] One click loads the player from YouTube, which sends your IP address to Google.

Advanced GIT: Git Worktree

2021-11-25T00:00:00+00:00

One of the coolest features in Git. And simultaneously one of the least used.

The classic situation:

You're in the middle of working on feature/blubb_feature and then a colleague sends an MR asking you to quickly review hotfix/make_that_users_dont_die_immediately so it can go live ASAP. Unfortunately the branch is too complex to review entirely in GitLab.

So you actually need to check it out and dive deep into the code...

The classic approach

git stash your changes
git checkout hotfix/... to look at the branch and go through everything
Approve or reject

A much better approach

You've set up git worktree (it's built into git) and have a folder structure like this:

project_name/
 - main/
 - develop/
 - feature/
   - blubb_feature/
 - hotfix/
   - make_that_users_dont_die_immediately/

Each folder acts like its own Git repository, but they all share the same Git metadata. Your current state stays untouched. A git worktree add BRANCH_NAME creates a folder pointing to that branch for you.

So how does it work?

Super simple, really :).

mkdir my_project (create project directory) and navigate into it: cd my_project
Clone the repository (note the first special step): git clone --bare GIT_URL .bare
- We only clone the bare repository without checking out a branch
- These metadata are stored in the .bare folder (the leading . hides it on macOS/Linux)
Create a file my_project/.git with the following line:
```
gitdir: ./.bare
```
This tells Git where to find the repository metadata
From here, worktree works perfectly:
- git worktree add main adds our main branch
- git worktree add feature/ABC_new_stuff_to_play feature/ABC_new_stuff_to_play to check out or create branches with / in the name
- You can also freely choose the folder location in the filesystem. The format is: git worktree add PATH BRANCHNAME

More useful commands

Delete a branch:
- Option 1: rm -r BRANCH_NAME then git worktree prune
- Option 2: git worktree list lists all worktree branches
Move a branch: git worktree move SOURCE DESTINATION

Stress-free Programming with Clean Code I

2021-09-02T00:00:00+00:00

Talk updated:

Translated into English
Errors corrected
Dart-specific parts removed
Adapted to new employer :)

Slides

Voting Aids for the 2021 German Federal Election

2021-08-23T00:00:00+00:00

Note: This article is about the 2021 German federal election (Bundestagswahl). The tools listed are German-language voting aids designed to help German voters understand party positions.

Since I share some of the criticism of the Wahl-O-Mat (Germany's official party matcher), I want to introduce the alternatives and complements here.

For completeness, my personal criticisms of the Wahl-O-Mat:

One-dimensional → there's no nuance or "not like this, but like this:" option
It only reflects what politicians say, not what they do. It would be nice if those two things didn't diverge so often.
Only a limited set of political theses is covered.

All these points have some merit, since of course you can't go infinitely deep.

Still, I find the basic concept of the Wahl-O-Mat super useful, because it enables discussion and can establish a rough "alignment". If I have 2% overlap with a party, the chance that I should vote for them is very very small.

Now there isn't just the Wahl-O-Mat, but also various alternative voting aids with different angles, which I'd like to collect and present here.

DeinWal.de

Link: deinwal.de

~~The current version for the 2021 election wasn't online yet when I wrote this~~, but the concept of deinwal.de is my absolute favourite! Rather than comparing party manifestos or what parties currently claim to stand for, it compares past votes in parliament against your own views.

Even before the BTW21 version launched, you could work through older elections to see how the major parties actually voted back then. Tip: try the 2019 European election and BTW2017.

Every question comes with detailed information and direct links to the parliamentary press release, abgeordnetenwatch, and Wikipedia.

Every vote is rated Yes/No/Abstention and placed in context at the end. Weighting is not possible.

Despite the lack of smaller parties, a clear recommendation, especially for politically engaged users who want a lot of background information.

Edit: The newest version of deinWal is finally online. The core concept is unchanged. Unfortunately, the main disadvantage remains: only established parties are included.

Wahlswiper

Link: voteswiper.org

Here you can, Tinder-style, swipe political statements good/bad and at the end find out your overlap with the parties.

The good news: 35 of 39 parties are included, so you'll find smaller parties like LIEBE or the Party for Children, Young People and Families.

As a bonus, every question comes with a short video and text explaining the topic objectively. Questions can be rated with Agreement/Rejection/Abstention. Topics that matter especially to you can be double-weighted.

Also a good recommendation for beginners, especially for people who don't usually follow politics closely.

Sozial-O-Mat

Link: sozial-o-mat.de

Exclusively focused on social policy, the Sozial-O-Mat compares your views with those of the parties purely on social issues. It covers four topic areas:

Work
Health
Family and Children
Migration

Operated by the Diakonie (a German social welfare organisation). Each of the four topics opens with a short introduction highlighting its relevance.

There are no videos or explanations here. Each thesis is backed by a "story", a personal narrative to help frame the issue. Interesting concept, though it does nudge the reader in a certain direction.

Each thesis can be rated Positive/Neutral/Negative, or skipped to remove it from the equation.

Good for a rough overview; I'd treat it mainly as a supplement.

Steuer-O-Mat

Link: smartsteuer

One of the shortest and most direct voting aids: the Steuer-O-Mat very straightforwardly calculates your approximate net income under each party's tax plans.

Enter your gross salary, optionally your married partner's, and get a pure tax-based voting recommendation.

Agrar-O-Mat

Link: agrarheute.com

Since, as we all know, food obviously only comes from the supermarket, this voting aid is strictly for farmers ;).

As the name suggests, it focuses exclusively on agricultural policy and adjacent topics. No additional background information.

Each thesis can be agreed with, rated neutrally, or rejected. Important topics can be double-weighted.

Interesting as a curiosity and supplement, but I personally lack the expertise to go really deep into agricultural policy.

Klima-Wahl-Check

Link: klimawahlcheck.org

I also write about climate here on the blog and will definitely cover it much more, but specifically climate-focused there's the Klimawahlcheck.

It's divided into 6 categories:

Energy
Mobility
Industry
Buildings
Climate Justice & Climate Targets
Agriculture & Biodiversity

Personally one of the most important tools for me, because it's not just about "the climate" in a naive sense, but covers all the interconnected social, economic, and scientific topics as well.

Unlike the others, each topic is rated on a 5-step scale from red to green. Topics can also be skipped. Each thesis comes with a short background summary.

Afterwards you see an overview diagram placing parties to the left/right/aligned with you. After completing all categories there's a full evaluation.

As I said, this is the most important tool for me personally, because climate decisions have significant knock-on effects for the economy, quality of life, and even survival.

Clear recommendation. Obviously ;).

Waehlbar2021

Link: waehlbar2021.de

Going well beyond a simple matcher, waehlbar2021 provides comprehensive background information AND detailed positions from almost all parties. CDU/CSU is predictably missing. Apparently they figured that not responding at all means nobody can hold them to anything.

The best feature is seeing the MPs from your own constituency directly, with their voting records. Enter your postcode and get all local candidates suggested, including their alignment on individual theses.

MPs who haven't yet responded can be messaged directly here asking for transparency.

A clear recommendation here too.

Wahl-o-Mat

Link: wahl-o-mat.de

Finally it arrived. As the best-known voting aid, the Wahl-O-Mat interviewed 39 of the 40 competing parties on numerous questions.

I have to admit this year's version is slightly better than before. While there's still no detailed background for questions or enough nuance, we now have the ability to compare all parties directly (thank you Volt for that), plus the option to play around with the results and weighting afterwards.

I personally got a different result than from the other tools, which at least broadens the perspective.

The questions are also quite varied and cover different areas, though of course familiar topics like a motorway speed limit pop up almost everywhere.

A clear recommendation here too.

Conclusion

In my view, every voter should work through at least one (but ideally all) of these tools before the election, to get a feeling for exactly what each party stands for.

One of the biggest problems in our democracy (in my opinion) is that parties and politicians have learned to speak without making any concrete commitments. This leads many people to vote for parties that are completely unsuitable for their own interests. The voting aids don't change that fact, but they help build an understanding of party positions without needing to read full manifestos.

My recommendation is this "formula":

Work through all the voting aids
Exclude parties that consistently land in the bottom third
Then weight all the tools:
- 1/3¹ from deinWal, since it's the only tool that goes beyond (possibly empty) promises.
  
  If you're considering smaller parties too, I'd recommend using deinWal at least as an exclusion criterion: I'd rule out the two worst-performing parties.
  
  ¹ assuming you're only considering established parties anyway
- 1/3 from the other tools, by giving points to each recommended party
- 1/3 from your own research. Here it's important not to be influenced either by Tagesschau/ZDFheute etc., or (and this is crucial!) by Facebook/WhatsApp groups/etc.
Take the things that matter to you (pension, taxes, climate, whatever) and explicitly engage with the opposing positions and arguments too. This ensures we're not making a pure gut decision for one of the most important elections in decades.

Climate Crisis I: The Current State

2021-08-19T00:00:00+00:00

First and most importantly: I'm writing this article for family and friends with the goal of not constantly having to be the "annoying climate activist".

My aim is to gather as many climate facts as possible in one place and explain why a radical change in politics and how we live together matters so much to me.

This whole issue is really complex and extensive, which is why I'm trying to split it into 3 articles:

The Current State (this article)
What's coming (in a timeframe we will definitely still experience, and that forms the core of Ophelia/Aurora's lives)
What we must do (strictly the scientific/economic consensus and the minimum required to minimise the impacts)

The abstract concept of so-called climate change (more accurately: climate catastrophe) is familiar to everyone by now, and we've all heard the rough outline: sea levels are rising, it's getting hotter, and the probability of extreme weather events is increasing.

But unfortunately that's not the complete picture, and in my opinion it doesn't make the real consequences clear enough.

In this first piece I want to talk about the impacts we're already feeling in Germany today, and also look at what we're seeing around the world right now as a glimpse of Germany's future. These are all measurable things, and the vast majority were scientifically predicted exactly this way. Unfortunately, usually for a few years further in the future. Unfortunately it turned out that almost all projections were significantly too optimistic.

Impacts in Germany

The closest to home are the consequences in our own country. A brief summary in bullet points:

Heat deaths have doubled
First lakes have already dried up, others affected by blue-green algae
Economic damage in the billions
Crop failures
Water shortages
Zoonoses
Forest die-off

Heat Deaths

Since 1955, the number of heat-related deaths has risen by 120%. In the four-year period 2014-2018, that was approximately 12,000. A large share of this growth happened in the decade between 2004 and 2014. For comparison: that's 1.5 times more deaths than in all German road traffic, though it's not entirely fair to compare directly, since traffic itself contributes to those heat deaths.

Dried-up Lakes & Blue-Green Algae

In Brandenburg, the first lakes have already dried up entirely. Where a lake once was, there's now (still) fertile meadow. Across Germany, many more lakes are affected or will dry up within the next 20 years, only to be periodically flooded by heavy rainfall.

The lakes that haven't dried up are already increasingly affected by cyanobacteria in summer. I still remember my childhood swimming in the gravel pit lake at Oppum. These days, warnings about gravel pit lakes are increasingly common due to algae.

To be honest: the climate crisis isn't the only cause of the algae problem. Intensive agriculture plays a role too. But that topic is complex enough to deserve its own article.

Economic Damage

A really important topic. Economics isn't exactly my favourite subject, but you constantly read and hear arguments about who will pay for it all, and the political mainstream (primarily CDU/SPD) tries to frame climate action as something to be "balanced" with the economy.

I find that deeply dishonest, since politics has long been advised by both scientists and economists that climate protection IS economic protection. The only thing that would suffer is short-term quarterly results. In the long run climate action is cheaper, completely ignoring lives and quality of life.

In Concrete Numbers

The fact that we're not only failing to invest in climate protection but that the CDU and in particular Altmaier actively obstructed climate action makes it no easier. An industry with 80,000 jobs in renewable energy, where Germany was once a global pioneer, has practically nothing left. When even Die Welt, a newspaper that has recycled climate misinformation from the AFDP-adjacent "EIKE Institut", notices, things are truly dire.

Crop Failures

It may have been an anomaly, but last year (2020) crop losses were between 30 and 50 percent. Almost entirely caused by drought. A factor that will definitely intensify. This year (2021) everything is extremely wet, so plants/trees/etc., already weakened, are now fighting rot from the other direction.

So far these conditions have been softened by the fact that we already throw away enormous amounts of food and could import. But our main vegetable/fruit import countries, Spain and the Netherlands, will struggle even more than us, with heat (Spain) and flooding (Netherlands). The Netherlands is already below sea level, currently staying above water only because pumps run continuously.

Water Shortages

Last year in Nieder-Beerbach we experienced it very directly ourselves: two weeks of mandatory water conservation. In Lower Saxony, the fire brigade had to distribute water in some areas because the tanks were simply empty.

Due to our geographically fortunate position, it will remain a matter of days to weeks and be locally limited in the medium-term future, but the impacts will still be severe and are already prompting warnings from water utilities and researchers.

Forest Die-off

In addition to drinking water shortages, about 1/3 of our forests are currently dying. Drought alone is often enough, and where that doesn't finish them off, "pests" help deal the final blow.

The consequences aren't just "less green" or losing more CO₂ sinks, but also rapidly declining biodiversity, soil damage (such as landslides), and more severe weather phenomena that are no longer blocked or weakened by forests.

An area of originally around 12 million hectares has already lost 300,000 hectares in the last 20 years, and that doesn't even count the coal-power forests. Specifically, only around 21% of our trees are still healthy.

Zoonoses

COVID-19 was not the first zoonosis and will not be the last. What was once a matter of centuries without human influence will happen more frequently. My generation will live through at least one more zoonosis like COVID, and for my daughters it will become a matter of habit.

The Federal Agency for Civic Education itself goes into detail on their pages, but as so often the priorities remain shaped by what RWE or the domestic steel and auto industry wants.

While we're still fighting SARS-CoV-2, more pathogens of various kinds are already on their way to us. Not only are our efforts on climate/human protection somewhere between inadequate and failing, as a species we also kick ourselves again by primarily breeding multi-resistant pathogens through our meat and livestock industry.

Global Impacts

When we talk about climate change, we often talk about so-called tipping points. We've identified around 16 of them so far. A tipping point is a threshold beyond which a process sets in motion that we cannot reverse. After that point, it just runs, and in most cases with self-reinforcing effect.

Permafrost

One of the tipping points we've already reached is that permafrost is thawing worldwide. This releases large amounts of methane, which naturally accelerates warming further. Methane is probably the most lastingly damaging element, but thawing permafrost brings many more problems.

For example, the online version of GEO magazine reports on several studies about further bacteria, viruses, and more hidden there. Most of it will be harmless, but even harmless 15,000-year-old pathogens can hit our immune systems extremely hard, just as happened during the colonisation of the Americas, when European settlers brought their diseases and wiped out entire tribes, not because the diseases were so dangerous in themselves, but because the immune systems of the Native Americans were entirely unprepared.

Rainforest

The rainforest has been misleadingly called the green lung of the earth. Unfortunately, this year we reached the point where the rainforest is releasing more greenhouse gases than it absorbs. That is devastating, and in this case almost 100% attributable to meat consumption.

To say it clearly: we've reached the point where the rainforest is NO LONGER the green lung. In simple terms, we have to rewrite our textbooks. Practically, it means we have permanently destroyed one of the planet's most important ecosystems. And for what: highly processed soya?

Ironically, people like to point to soya fields and blame vegetarians, while conveniently forgetting that only 6% of global soya ends up in veggie products and the rest is animal feed. The soya from the rainforest doesn't reach German mouths anyway, since German products use semi-regional suppliers. And it takes around 12kg of soya to produce 1kg of beef. Pigs and poultry are thankfully considerably more efficient.

"But we can't save the world on our own"

... how do we get others to help?

We don't have to. We mainly just need to stop blocking. In Europe, Germany is THE brake par excellence.

Although we represent just 1% of the world's population, we produce around 2% of greenhouse gases. And that doesn't even include products manufactured in China/Taiwan or services like servers etc. from abroad destined for the German market, which really should be counted against us.

Per capita, Germany is still significantly ahead of China: China is at around 5t CO₂, while we're at an average of 11t. Twice as much as the "terrible China". Out of over 200 countries, we're currently in the top 10 for absolute emissions. Do we really want almost 200 other countries to use the same argument? Would we accept "but the others are doing it!" as an argument from our children?

Edit: Finally, here's a wonderful summary by Quarks of the first IPCC report. In total there will be 3 reports and 1 summary. Importantly, the reports are already finished, but won't be published until 2022 because governments are allowed to exercise influence first. A summary of the leak from Part 2 (not due until January 2022) was published by Der Spiegel.

It may also be relevant that the REASON for this leak is that the scientists are afraid that the report will be watered down by governments.