Linkblog

Die dänische Entscheidung, konsequent für Wohlbefinden zu sorgen

Sat, 25 Apr 2026 14:46:44 +0000

"Morgen fahren wir nicht nur 800 Kilometer nach Hause. Wir reisen 30 Jahre in der Zeit zurück."

Prolog | Am Abend vor unserer Abreise sagte ich zum Reiseleiter: „Morgen fahren wir nicht nur 800 Kilometer nach Hause. Wir reisen 30 Jahre in der Zeit zurück.“

Damit meinte ich nicht die Digitalisierung in Dänemark. Vielmehr meine ich damit die Art, wie Dänen und insbesondere die Kopenhagener Zusammenleben gestalten.

Das Design | Wenn man Dänemarks und Kopenhagens Idee von Stadtplanung verstehen will, kommt man nicht an Jan Gehl vorbei. Foto aus dem Danish Architecture Center:

Als der 79-Jährige seinerzeit Architektur studierte, zeigten ihm seine Professoren Fotos mit Gebäuden. Um die Fotos zu machen, sind sie um 5 Uhr aufgestanden, damit keine Menschen auf den Bildern zu sehen waren. Gehl sagt, er habe im Studium gelernt, Skulpturen zu erschaffen, keine Gebäude für Menschen. Dann heiratete er eine Psychologin, „a big crossing point in my life“. Seither, sagt er, studiere er Architektur neu, seit 40 Jahren.

Das erzählt er in seiner Standardvorlesung, die zum Beispiel als Annual Lecture 2018 Mistra Urban Futures zu sehen ist, Video ab Minute 8:30. Oder im Podcast The Developer.

Gehl begann, Menschen zu beobachten. Er fuhr nach Italien und führte in den Altstädten akkurat Buch darüber, was in den Straßen, Gassen und auf den Plätzen geschah. Er schrieb auf, wie sich Menschen verhalten. Er bereiste andere Länder, andere Städte. Ihm wurde klar, dass die Architektur bislang einem Irrtum unterlegen war: Sie maß, wie viele Menschen wo gehen und fahren – um dann Straßen und Häuser zu gestalten. Dabei sei nicht wichtig, wo sie sich bewegen, sondern wo sie stehenbleiben, in Kontakt kommen, miteinander sprechen. So entstand Gehls Verständnis von Stadtplanung.

A good city is like a good party — people stay longer than really necessary because they are enjoying themselves.

Er beschäftigte sich mit menschlichen Dimensionen, mit Augenhöhen, Sichtachsen, wie weit wir gucken und laufen können, bei welchen Geschwindigkeiten wir noch was wahrnehmen können, welche Strecken wir wählen, warum wir lieber am Rand sitzen als in der Mitte, bis zu welcher Entfernung wir Mimik lesen können und vieles mehr.

Gehl kam zu dem Schluss, das der Mensch alles tut, um Energie zu sparen. Wenn wir uns entscheiden, wie wir eine Strecke zurücklegen, dann ist es immer eine Effizienzentscheidung. Also, sagte er sich, müssen Städte so gestaltet sein, dass sie effizient und bequem sind – nicht für ein Auto, sondern für den Menschen, für den menschlichen Körper und den menschlichen Geist.

Das Ergebnis ist eine Stadtplanung, die Plätze und Räume priorisiert, auf denen Menschen zusammenkommen und sich sicher fühlen, eine Planung, die am menschlichen Körper ausgerichtet ist, die Aktivität fördert und Gesundheit erhält. Er entwickelte eine demokratische Stadtplanung, die wiederum Demokratie fördert.

It emphasizes that we shall walk more, we shall meet each other more. That’s good for health, that’s good for safety, that’s good for social inclusion, that’s good for democracy. Don’t sit in your private little house and look out of little little windows. Come out in our wonderful outdoor spaces and enjoy the spaces with your wonderful fellow citizens.

Filmempfehlung: The Human Scale, verfügbar auf youtube. Leseempfehlung: Städte für Menschen. Außerdem ein Interview beim Deutschlandfunk.

Wege und Plätze | Der Reiseleiter und ich sind in den vergangenen Jahren mehr als tausend Kilometer mit dem Fahrrad durch Dänemark gefahren. Diese Mobilitätsform hat zwar den Nachteil, dass einem immer irgendwas weh tut und man sich fortwährend mit Keksen befüllen muss. Sie hat jedoch einen entscheidenden Vorteil: Man erkennt hervorragend Muster und Zusammenhänge, Verbindungen zwischen Menschen und Geographie, zwischen Städten und Stadtteilen, sich wiederholende Strukturen und die Prioritäten, die sich durchs Land ziehen. Diese Prioritäten finden in Kopenhagen ihren kummulierten Höhepunkt: Allerorten geht es darum, Gemeinschaft zu stärken. Der öffentliche Raum gehört dem Menschen, nicht Autos, nicht der Wertschöpfung, sondern dem Wohlbefinden der Däninnen und Dänen. Der Mensch wird willkommen geheißen: mit Bänken und Blumen, Schatten spendenden Bäumen, Spielgeräten, Wasser, Schaukeln und Rutschen – auch für Erwachsene -, mit Ruheliegen, Picknickmöglichkeiten, öffentlichen Toiletten, breiten Wegen und Beleuchtung.

Sollten Sie einmal in Kopenhagen sein, organisieren Sie sich ein Fahrrad und fahren Sie durch die Stadt. Sie werden erkennen, wie alles auf magische Weise verbunden ist, wie Wege sich öffnen und fügen, wie es fließt und wie verschiedene Orte und unterschiedliche Stadtteile sich zu einem verwobenen Ganzen zusammenfügen, das ohne Motor, nur mit menschlicher Körperkraft erfahrbar ist. Es existieren viele Plätze, die im Einzelnen unscheinbar wirken, die in ihrer Fülle und in ihrer Verbindung jedoch ein Netz bilden, das nicht nur für den funktionalen Teil des Erwachsenendaseins, sondern fürs Zusammenleben aller Altersgruppen sicher und praktikabel ist.

Kopenhagen hat weniger Spielplätze als deutsche Städte mit vergleichbarer Fläche. Es braucht auch nicht so viele, weil die Stadt selbst kinderfreundlich ist, weil sie Plätze hat, die zum Spielen, Rennen und Verstecken einladen. Eingezäunte Spielplätze helfen nicht, wenn die Stadt außerhalb des Zauns feindlich ist.

Dass Kinder Teil der Stadt sind, zeigt sich auch am Israels Plads, einem großen Platz, der umringt ist von Schulen (Foto des Reiseleiters aus dem vergangenen Juni):

Der Platz ist der Pausenplatz aller Schulen und gleichzeitig ein öffentlicher Ort. Kinder mischen sich mit Menschen, die einkaufen, mit Senioren, die sich ausruhen, mit Mittagspäuslern, die Smørrebrød essen. Keine Haftungsfrage, keine Angst: ein Schulhof, nicht eingezäunt? Der Platz ist übrigens auch Teil der städtischen Klimaanpassung. Er ist ein Regenrückhaltebecken, das tiefer liegt als die Umgebung: Regnet es zu viel, läuft er voll.

Gebäude für alle | Wir radelten zu den Nørrebrohallen. Ein Treffpunkt, eine Bibliothek, Sporthallen – alles öffentlich, alles steht für alle zur Verfügug.

Es gibt mehrere ähnliche Orte in Kopenhagen. Über die Seite bookbyen.dk („Buch die Stadt“) kann jeder sich einen Platz, einen Raum buchen. Ein Badmintonkort kostet beispielsweise 98 Kronen pro Stunde, das sind etwa 13 Euro. Als wir dort waren, war massig los: Die Leute kamen aus den Sporthallen, gingen hinein, trafen sich im Café, saßen einfach nur auf Bänken, besuchten die öffentliche Toilette, den Bücherschrank oder waren alleine oder mit Kind in der Bücherei. In der Eingangshalle standen locker 25 Kinderwagen. Es gibt einen Kochclub und andere Interessenskreise, außerdem Snakkeklubber für diverse Sprachen, in denen man seine Sprachkenntnisse vertiefen und sprechen üben kann – auch in Dänisch für alle Zugewanderten.

Wir hielten uns dort eineinhalb Stunden auf, lasen, aßen etwas. Ich nahm ein Buch aus dem Bücherschrank mit, einen Krimi, mein erstes Buch, das ich auf Dänisch lese. Mit etwas Anstrengung verstehe ich gut; mein Vokabelschatz erweitert sich um Wörter wie „Tatort“, „Ertrinkungstod“, „Zeugenaussage“ – mein Dänischlehrer wird irritiert sein. Das Schöne an dem Ort: Wir fühlten uns willkommen, obwohl wir nur Gäste waren. Ein Ort der unkomplizierten Freundlichkeit.

Die Bibliothek in den Nørrebrohallen war ein warmer, wuseliger, kreativer Ort. Den Sorte Diamant, Der Schwarze Diamant, die Dänische Nationalbibliothek, ist deutlich minimalistischer und vor allem dem Studium gewidmet.

Eine tolle Architektur.

Im Museum für Architektur und Design gab es übrigens eine Rutsche vom obersten Stockwerk ins Erdgeschoss – ausdrücklich auch für Erwachsene (mehr dazu, mit Bild). Ein wilder Ritt. Ich sah mein Leben an mir vorbeiziehen.

Rutschen-Architekt Carsten Höller:

Why are slides not used in architecture to complement stairs, elevators and escalators? They are fast, safe and energy-savvy – and they produce a sensation in the user that has been described as a kind of voluptuous panic upon an otherwise lucid mind, somewhere between delight and madness.

Das kann ich so bestätigen.

Epilog | „Aber in Deutschland ist doch nicht alles schlecht! – „30 Jahren hintendran – so kannst du das doch nicht sagen!“

In unserem Land sind Städte und Orte so gestaltet, dass sie funktionieren; dass sie effizient und vorschriftsgemäß sind. Dummerweise verhält sich der Mensch nicht normgerecht, sondern folgt seiner Intuition. In Dänemark passt sich die Stadt dem Menschen an, schafft Zugehörigkeit. In Deutschland muss sich der Mensch an die Stadt anpassen, steht der Individualismus über dem Gemeinsinn. Dieser Unterschied wirkt so fundamental, dass wir in Deutschland, selbst wenn alle Kommunen plötzlich Geld im Überfluss hätten, nur mehr von dem bekämen, was wir bereits haben: normtreu gestaltete Orte.

Bis wir diesen gedanklichen Sprung gemacht haben, werden Jahrzehnte vergehen.

Die Etappen | Auf der nächsten Etappe erzähle ich noch vom Radfahren in Kopenhagen:

#1 – Die Fahrt, der Wind, die Einöde, Schnee und ein Bällebad
#2 – Eine Erzählung über Museen und Friedhöfe
#3 – Brücken, Tunnel und Fähren – ein Beitrag für den Freundeskreis Ingenieurskunst
#5 – Test eines Mythos: Radfahren in Kopenhagen

I don't want your PRs anymore

Wed, 22 Apr 2026 04:38:30 +0000

I really appreciate that you're enjoying the software I'm maintaining and want to help. But we need to rethink this collaboration, because I feel like we're increasingly wasting each other's time.

Why I don't want to merge your PR

Since I don't really know you, I always have to assume that you might be trying to sneak in something malicious along with your changes, which makes reviewing and merging them riskier than implementing them myself.

On top of that, there are a lot of personal and subjective aspects to code. You might have certain preferences about formatting, style, structure, dependencies, and approach, and I have mine.

Then we often need to synchronize with respect to review, CI runs, merge conflicts, etc.

And then there's this common back-and-forth round-trip between the contributor and maintainer, which is just delaying things.

Even before LLMs, writing the code was not the main bottleneck for me. But writing code did take time, so a solid, working, easy-to-review PR was often worth the small extra risk and inconvenience.

With LLMs becoming quite good at implementing things, that tradeoff is almost never true anymore.

While I still need to review LLM-generated code, I generally don't have to worry about it being malicious the way an unknown contributor's code could be. I've already codified a lot of my coding preferences and style guidelines for my LLM. And I can rapidly iterate at my own pace without having to synchronize with another human who might be in a different timezone.

For these reasons, it's just easier if I make the code changes myself (with the help of an LLM).

The nature of software development has shifted

It's increasingly apparent that "the source code" is less "source" and more "code" — an intermediate formalized layer between ideas in the developer's head and instructions for the computer to execute. It's always been this way, but now, with the code itself being easier to generate automatically, it's just more visible.

There's a wide range of reactions to coding agents out there, from banning them to proclaiming that coding is dead and vibecoding is the future. Personally, as things are right now, I sit somewhere in the middle. I come up with the design, then let my agent do a lot of the actual writing, and then I review and refine the result.

I could get huge amounts of code written, but I'm bottlenecked on:

understanding — reading the existing code to be able to reason about it;
designing — coming up with the right changes and architecture;
reviewing — ensuring that the code is doing what I wanted.

The code in your PR doesn't help me much with any of these. So let's skip it — don't attempt to implement code changes with the goal of merging them into the codebase.

How can you help instead

As the "writing the code" part is becoming less valuable, all other ways of helping maintainers become relatively higher value.

Give feedback

As I'm busy implementing things, I often don't have much time to actually use them, or do good research on how to improve them.

Users telling me what works well and what could be improved can be very helpful.

Discuss ideas

I don't know everything, and discussing things with other people with different experiences and perspectives can help me understand what I should be building and how.

Report and investigate bugs

A good bug report is 3/4 of the bug itself being fixed.

If you spotted a problem, please describe it well, and even do the debugging to figure out how to reproduce it and where exactly the problem is.

Then discuss potential solutions.

Prototype changes

Send me a reference PR and/or the prompt you used to produce it.

Yes, I know I just said that I don't want your PRs. So let me explain. With LLMs, it's easier for me to get my own LLM to make the change and then review it myself.

BUT — using code for illustrative purposes still makes sense. A quick glance at code implementing something can be helpful, even if I don't end up merging it.

And if you share the actual "source" (prompt) to produce the "code", I can reuse and refine it, saving time.

Review code and point out problems

As I'm bottlenecked on reviews, an extra pair of eyes helps.

Fork the code and report back

Don't be afraid of forking the code and changing it however you want.

Having to come up with designs supporting multiple use cases, forming consensus, debating best outcomes, looking for compromises, etc. is very time-consuming.

LLMs enable a great deal of software customizability. You can make the changes you want by yourself faster and easier than ever, and then rebase them (or not) on top of upstream at your own pace.

Just fork. Add support for your own use case, do things your way, ask neither for permission nor forgiveness.

As a maintainer, this saves me time too. And in the end, maybe both of us can learn something from your version taking its own route.

Hister - Your Own Search Engine

Mon, 20 Apr 2026 12:47:21 +0000

Your Own
Search Engine

Full-text search across your files, visited sites and beyond.

Free Software
Self-Hosted
Privacy Respecting

Features

AI Integration

Optional semantic search and MCP connectivity

Privacy-focused

Keep your browsing history indexed locally. No remote servers, no tracking, no data leaving your machine.

Full-text Indexing

Search through the actual content of web pages and your local files.

Blazing Fast

Instant results as you type. Full keyboard-driven workflow for maximum efficiency.

Advanced Search

Powerful query language for precise results.

Flexible Management

Configure blacklist and priority rules to control your indexed content.

Browser Extensions

Available for Chrome and Firefox to automatically index websites you visit.

Offline Preview

Readable offline previews of any result. Access your saved pages without internet.

Browser Import

Import existing Firefox or Chrome history with a single command.

Why Hister?

Keep your data private and local while enjoying powerful search capabilities.

Web UI

Terminal UI

Preserve your data

Free, open-source and completely private.

SDocs

Sun, 19 Apr 2026 04:42:46 +0000

Styles

General

Font family

Base size px

Line height

Colors

▶ Blocks

Default for code blocks, blockquotes, and charts. Override individually below.

Headers

▶ General h1–h4

Font family

Size scale

Margin bottom em

Paragraph

Line height

Margin bottom em

Lists

Item spacing em

Indent em

Blockquote

Border width px

Font size em

Save as default styles

Requires sdocs-dev CLI
- Install: npm link from project root
Saves to ~/.sdocs/styles.yaml
Paste the command below in your terminal

100% private (learn why) · Open source: verify server · CLI for you & your agents: npm i -g sdocs-dev · GitHub · You agree to our Terms

Thoughts on "LLM Wikis"

Wed, 15 Apr 2026 14:59:25 +0000

A thing I published on my employer's newsletter...

Hello Subscriber

this newsletter is a bit different, Instead of presenting what’s new in the world of DokuWiki, this more of a think piece. What does the advent of AI agents mean for the future of wikis and knowledge management?

We’d love to hear your thoughts on the topic.

Andreas Gohr

BTW: if you haven’t seen what an AI agent integration already can look like, have a look at our video showing the AI Agent plugin in action.

Thoughts on LLM Wikis

The idea of an LLM Wiki as postulated by Andrej Karpathy is currently making the rounds on LinkedIn and in other circles.

The idea is simple: instead of manually managing your wiki, creating pages, interlinking them, making sure the documentation is up-to-date and consistent, you just let an AI agent handle it. The “wiki” becomes a bunch of interlinked pages, read and written primarily by the agent. The interface to the information is the agent itself.

To add information, you dump documents, emails, or snippets into an “ingest” agent. A periodic “lint” agent takes on the role of the wiki gardener, and to get information from the system you talk to the “query” agent.

It sounds magical. Finally, the largest hurdle of wiki adoption is solved: nobody has to write anything down anymore.

When I presented the DokuWiki AI Agent plugin (see last newsletter) to my colleagues, their thinking went in the same direction. But I think the idea rests on a misunderstanding: collecting information is not the same as creating knowledge. A useful wiki is not just a storage layer an agent can read and write, but a shared, collaborative structure that humans can understand, navigate, and trust.

Information is not Knowledge

The goal of a wiki is to aggregate and synthesize knowledge from information. Karpathy hints at the issue when he describes how he runs the “ingest” phase:

Personally I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize.

Without this close supervision and guidance, you’re basically “vibe coding” your knowledge base. In case you’re not familiar with the term, “vibe coding” refers to the process of creating software using an AI coding agent without ever looking at the created code (sometimes not even knowing how to program). The results can be impressive for a short time, but the larger the scope and the longer the project development, the more vibe-coded software turns into unmaintainable spaghetti code with lots of duplicate code, unexpected bugs, and side effects.

It’s the same with knowledge management: dump ten years of project emails into an ingest pipeline and you’ll get summaries of conversations, but not institutional know-how. Knowledge requires human synthesis and perspective, the LLM can’t do that alone.

What Karpathy actually hints at, when describing how he uses the ingest phase, is not automation without oversight. His approach is less “vibe coding” and more “vibe engineering”. In software development, this describes working with an AI agent where every output is reviewed, refined, and iterated until approved by an experienced human software engineer. It is a different kind of software development, but it is not necessarily faster or easier than traditional development. The human’s role shifts from developer towards architect and QA manager.

In the case of an “LLM Wiki”, it means that unless you want your knowledge base turning into an unknowable black box, you need to keep a very close eye on how the agent organizes the information and what knowledge is synthesized from it, and permanently steer and correct it.

As explained above, you want to keep an eye on what the agents do with the information you feed them. This is made difficult by the system Karpathy suggests. His “wiki” consists of hundreds of markdown files sitting side by side in one directory, with a single index.md providing one-line descriptions and optional categories. He’s explicit: you’re not meant to touch anything here: “The LLM owns this [storage] layer entirely”.

The result is a kind of digital dumping ground: technically searchable, but cognitively opaque. Even with Obsidian providing a graph view or backlink visualization, there’s no real overview, no curated entry points, no intentional hierarchy. Once the number of files crosses a certain threshold, orientation becomes difficult - you can’t easily tell what’s missing, what’s redundant, or where to start exploring.

Traditional wiki gardening solves this by emphasizing human navigation design: choosing page titles, linking paths, organizing namespaces, and summaries that guide the reader. It’s less about storage and more about providing a common thread. Without that human editorial layer, the “wiki” devolves into a bag of loosely connected text fragments - accessible to the LLM perhaps, but exhausting for people to read and trust.

Personal Systems are not Collaborative Wikis

What most people seem to miss in their excitement is the very first sentence of Karpathy’s article: “A pattern for building personal knowledge bases using LLMs.” (emphasis mine).

I have no doubt this system is working great for him. He seems to invest a lot of time into maintaining and refining the data in it. I feel like he’d be great at using a traditional wiki as well.

What his “pattern” is lacking, though, is any notion of how it would work with multiple users. How would the system evolve when prompted by different users with different needs? How can anyone trust the information in the wiki? Who are edits attributed to when agents potentially edit and rewrite whole sections of the wiki at any time? Hallucinations have become rarer with modern models, but they still exist.

Use in a corporate context is even more questionable. There is no notion of ownership, permissions, or approvals at all. While I personally would celebrate the adoption of the “wiki way” where everyone is allowed to see and edit everything, it is very rare for enterprises to adopt that mindset fully.

AI can help, but not Replace Stewardship

The recent hype around OpenClaw illustrates a similar dynamic. OpenClaw promises a personal assistant that manages your email, files, and workflows across every messaging platform you use. And for technically savvy users who take the time to isolate it, restrict its permissions, and audit third-party skills, it delivers. But the vast majority of adopters don’t do any of that. The result: tens of thousands of misconfigured instances exposed to the internet, a skills marketplace flooded with malicious plugins, and critical vulnerabilities that allowed entire agent takeovers from a single website visit.

I fear the pattern will be similar with LLM Wikis: agentic systems promise to remove the hard, tedious parts of a task - but that tedious work is what makes the result useful. Take away the expert supervision and you don’t get magic, you get a mess that’s harder to clean up than what you started with.

I think there are many interesting aspects in Karpathy’s pattern, and I am sure we will see many of them implemented in future wikis, but I don’t think it will magically solve the “issue” of knowledge management being work. Wikis rise and fall with people participating and shaping the information stored in them into knowledge. AI agents can help a lot with that, but they can’t (and shouldn’t) think for you.