Shellsharks Blogroll - BlogFlock

Published on Citation Needed: "Issue 101 – Bought and paid for" - Molly White's activity feed

2026-02-26T22:02:10.000Z

Published an issue of Citation Needed:

Issue 101 – Bought and paid for

Bitcoin is down 50%, several prominent industry figures have been uncovered in the Epstein files, Trump’s facing a probe into his family’s $500M deal with the UAE, and crypto super PACs spend their first $6 million in the midterms.

A Sunday of chaos and quiet - Joel's Log Files

2026-02-26T17:00:00.000Z

I woke up early, turned on my laptop and opened the presentation for today’s sermon, the preacher sent it overnight and I was revising it. It took longer than expected, but it was bound to happen—AI generated graphics were used.

Helping with the media and worship presentations during service at my local church is a common task of mine. I probably should have done more to prevent this and set some guidelines beforehand, but now that it happened, I wouldn’t let it fly. After a short explanation of why, I saved the day, and educated one more person about the horrors of AI slop. I wish that had been the biggest mess of the day…

The morning kept going, I finished the presentation, song lyrics, the usual stuff. I have no breakfast on Sundays, I dressed up—more formal than usual, I was feeling fancy—and headed out with my family!

After the service was over—with AI nowhere to be seen—everyone stayed to have lunch together.

My church has been collecting money for a new building, so each week a different family prepares and sells a meal for everyone—we are a rather small group—to acquire funds and enjoy the time together.

I get in line for my serving—some great tacos de bistec that I couldn’t stop eating—and I sat on a different spot than normal, since most of my friend group helped prepare the orders, or handle cash. I was enjoying myself, listening to the chatter without saying much. I start to hear about violence going on in the streets, about drones flying above some areas, things start to get a little tense.

As much as I hate it, I install Facebook again—still the most popular social network in Mexico. I read the headlines, I read posts from the government in my state and my city. I hear the people around me, sharing their own thoughts and updates on the situation.

Some people with friends or contacts elsewhere start to get phone calls, people checking up on each other, people making sure everyone is safe. A few leave early, but things keep going pretty well.

I talk about it on the fediverse, in some group chats. I check up and see this is news worldwide. Flights are delayed, roads are blocked, hotels closed their doors— nobody in, nobody out.

The leader of the biggest drug cartel in Mexico died.

After this military operation, the narco is acting in retaliation with terrorist acts all over the country. The posts online from the local government are clear: go home and stay inside.

Things were going fine. People left at a rather slow pace, those who stayed finished their meal, and things went on as usual—the kids played and ran around outside. We were all rather calm, it was no big deal.

Perhaps is in moments like these where faith shines through, and being together brought a sense of peace amidst the chaos. Maybe it’s naive, maybe we are oblivious to reality. But we rest assured, beyond any despair this world may bring.

And the day went on, we returned home, and enjoyed a quiet evening. My mom decided to catch up on her current TV show of choice, my grandma joined her, even my dad. They made some popcorn too.

I wasn’t feeling like watchting TV, and I stopped reading the news. It had been a while since we had popcorn, so I got my own bowl and went to my bedroom to ~~watch Resident Evil retrospective videos and essays~~ clean up and get it tidy.

Later I returned to my playthrough of Resident Evil 2. It has been such an enjoyable experience, and it felt a bit surreal this time, I couldn’t help but think about the fact that I’m surviving a zombie apocalypse while there are vehicles on fire and buildings closed all over my state. At least I don’t think Zombies stand a chance in Mexico, I admit I chuckled at the intrusive thought.

Checking my emails, I realize I won’t have to work on Monday, and that my gym would be closed too. Not much to worry about, just an unexpected day off, a welcome development despite the circumstances.

A bit later, my church did an online call, where we prayed together about the whole situation going on, everyone arrived home well, and even though shops and the like were closed, we all had our needs covered. We prayed for the authorities, forgiveness for those committing these acts and their repentance, for the people who suffered a loss, and those who struggled because of it all.

My dad prepared some migas con huevo for dinner—probably my favorite way to eat eggs. I was happy that I wouldn’t have to wake up early tomorrow, and things went as normal, then it was time to go to sleep.

The thought about how I could have realized absolutely nothing if I hadn’t been with other people is also weird, I really am completely unaware of the news most of the time, but when stuff like this could happen all of a sudden, I see now why some folks are often very worried on what’s going on around them.

I guess I should try to find a balance. It’s easy to ignore that which doesn’t affect you, I guess, but then it does, and now what? I do hope that I’ll remain calm even then, maybe I can say it because nothing really affected me much, just the tension in the moment. I don’t know, I’ll figure something out.

I’d also like to thank those who checked up on me! I’m writing this last couple paragraphs a few days later now, and it really does feel kinda melancholic. I thought about writing about my day off too, but it really was just a normal time staying at home and playing videogames. That Sunday though, that was a day full of mixed emotions, but it kind of got me to see so some things differently, it was an interesting experience.

This is day 22 of #100DaysToOffload

Reply to this post via email | Reply on Fediverse

This time is different - Terence Eden’s Blog

2026-02-26T12:34:39.000Z

3D TV, AMP, Augmented Reality, Beanie Babies, Blockchain, Cartoon Avatars, Curved TVs, Frogans, Hoverboards, iBeacons, Jetpacks, Metaverse, NFTs, Physical Web, Quantum Computing, Quibi, Small and Safe Nuclear Reactors, Smart Glasses, Stadia, WiMAX.

The problem is, the same dudes (and it was nearly always dudes) who were pumped for all of that bollocks now won't stop wanging on about Artificial Fucking Intelligence.

"It's gonna be the future bro, just trust me!"

"I dunno, man. Seems like you say that about every passing fancy - and they all end up being utterly underwhelming."

"This time is different!"

*sigh*

The investor who says, “This time is different,” when in fact it’s virtually a repeat of an earlier situation, has uttered among the four most costly words in the annals of investing.

16 rules for investment success - Sir John Templeton

All of the above technologies are still chugging along in some form or other (well, OK, not Quibi). Some are vaguely useful and others are propped up by weirdo cultists. I don't doubt that AI will be a part of the future - but it is obviously just going to be one of many technology which are in use.

No enemies had ever taken Ankh-Morpork. Well technically they had, quite often; the city welcomed free-spending barbarian invaders, but somehow the puzzled raiders found, after a few days, that they didn't own their horses any more, and within a couple of months they were just another minority group with its own graffiti and food shops.

Terry Pratchet's ~~Faust~~ Eric

The ideology of "winner takes all" is unsustainable and not supported by reality.

Making fLaMEd fury Glow Everywhere With an Eleventy Transform - The Weblog of fLaMEd

2026-02-26T12:00:00.000Z

What’s going on, Internet? I originally added a .gradient-text CSS class as a fun way to make my name (fLaMEd) and site name (fLaMEd fury) pop on the homepage. shellsharks gave me a shoutout for it, which inspired me to take it further and apply the effect site-wide. Site wide was the original intent and the problem was it was only being applied manually in a handful of places, and I kept forgetting to add it whenever I wrote a new post or created a new page. Classic.

Instead of hunting through templates and markdown files, I’ve added an Eleventy HTML transform that automatically applies the glow up.

The effect itself is a simple utility class using background-clip: text:

.gradient-text {
  color: transparent;
  background-image: var(--gradient-flames);
  padding: 0.6rem 0;
  background-size: 50%;
  background-clip: text;
}

Swap --gradient-flames for whatever gradient custom property you have defined. The background-size: 50% repeats the gradient across the text for a more dynamic flame effect.

The transform lives in its own plugin file and gets registered in eleventy.config.js. It runs after Eleventy has rendered each .html page, tokenises the HTML by splitting on tags, tracks a skip-tag stack, and only replaces text in text nodes.

export const glowUp = eleventyConfig => {
  eleventyConfig.addTransform('glow-up', (content, outputPath) => {
    if (!outputPath?.endsWith('.html')) return content;

    const skipTags = new Set(['a', 'code', 'h1', 'h1', 'h3', 'pre', 'script', 'style', 'textarea', 'title']);
    const skipStack = [];
    let result = '';

    for (const token of content.split(/(<[^>]*>)/)) {
      if (token.startsWith('<')) {
        const isClosing = token.startsWith('</');
        const isSelfClosing = token.endsWith('/>');
        const tagMatch = token.match(/^<\/?([a-zA-Z][a-zA-Z0-9-]*)/);

        if (tagMatch && !isSelfClosing) {
          const tag = tagMatch[1].toLowerCase();
          if (!isClosing) {
            if (skipTags.has(tag)) skipStack.push(tag);
            else if (tag === 'span' && token.includes('gradient-text')) skipStack.push('gradient-text-span');
          } else {
            for (let i = skipStack.length - 1; i >= 0; i--) {
              if (skipStack[i] === tag || (tag === 'span' && skipStack[i] === 'gradient-text-span')) {
                skipStack.splice(i, 1);
                break;
              }
            }
          }
        }
        result += token;
      } else if (skipStack.length === 0 && token) {
        result += token.replace(/flamed( fury)?/gi, match => `<span class="gradient-text">${match}</span>`);
      } else {
        result += token;
      }
    }
    return result;
  });
};

Tags in the skipTags set, along with any span already carrying the gradient-text class, push onto the stack. No replacement happens while the stack is non-empty, so link text, code examples, the page <title>, and already-wrapped instances are all left alone. HTML attributes like alt and href are never touched because they sit inside tag tokens, not text nodes.

A single regex /flamed( fury)?/gi handles everything in one pass. The optional group greedily matches " fury" when present, so “fLaMEd fury” is always wrapped as a unit rather than just “fLaMEd”. The i flag covers every capitalisation variant (“fLaMEd fury”, “Flamed Fury”, “FLAMED FURY”) with the original casing preserved in the output. This helps because I can be inconsistent with the styling at times.

Export the plugin from wherever you manage your Eleventy plugins:

import { glowUp } from './plugins/glow-up.js';

export default {
  // ...other plugins
  glowUp,
};

Then register it in eleventy.config.js. Register it before any HTML prettify transform so the spans are in place before reformatting runs:

eleventyConfig.addPlugin(plugins.glowUp);
eleventyConfig.addPlugin(plugins.htmlConfig); // html prettify

That’s it. Any mention of the site name (fLaMEd fury) in body text gets the gradient automatically, in posts, templates, data-driven content, wherever.

Look out for the easter egg I’ve dropped in. Later.

Hey, thanks for reading this post in your feed reader! Want to chat? Reply by email or add me on XMPP, or send a webmention. Check out the posts archive on the website.

Four More Years - The Weblog of fLaMEd

2026-02-26T11:21:43.000Z

What’s going on, Internet? I’ve been using my iPhone 13 Pro for a little over four years now, since September 2021 and I want to keep using it for a couple more.

Keyboard lag. Apps taking a second to think before opening. Battery health sitting at 80%.

I had a quick look at the iPhone 17 and couldn’t justify it when everything else about this phone is still good. Storage is only half full. Camera is fine. It’s fast when it wants to be.

So I tried the logical fix first: a $90 battery replacement from a local repair shop.

This is where it had been sitting for a while. Still usable, but clearly the reason iOS had started throttling performance.

Straight after the swap I got a warning about the battery not being genuine which I was only made aware of right before pulling the trigger on this after reading a comment on the iPhone 13 Battery page on iFixit.

I made peace with myself and I was prepared to live with it. For $90 and being done in 30 minutes without having to schedule with an authorised repair dealer and being without the phone for up to four days. I just wanted the speed back.

But apparently because I’m on a newer version of iOS, I had the option to run Apple’s verification process. So I did… and it passed.

Battery health back to 100%, full stats restored, and the warning moved to Parts & Service History where it belongs.

That’s basically the authorised-repair end result for third-party-repair money.

I followed the usual calibration cycle: charge to 100%, leave it on the charger for a couple more hours, run it down until it turns off, charge back to 100%. Mostly to give iOS a clean read on the new battery.

The battery fixes the hardware bottleneck. The other half is software. Years of installed apps, background processes, cached junk. So I’m preparing for a full wipe and setting the phone up as new. No restoring from backup, sign into iCloud and let the data sync back, reinstall apps one at a time. Only the things I actually use get to come back. It’s the closest you get to a new phone without buying one.

This whole reset cost less than a case for a new phone. If the lag disappears, that’s another couple of years out of a device that’s still more than good enough. If it doesn’t, then I look at upgrading. But it makes more sense to solve the worn-out-battery problem before spending thousands to avoid it.

I’ll report back once the clean install is done and I’ve lived with it for a few days.

Hey, thanks for reading this post in your feed reader! Want to chat? Reply by email or add me on XMPP, or send a webmention. Check out the posts archive on the website.

Members Only: Your anonymity set has collapsed and you don't know it yet - Westenberg

2026-02-26T01:41:29.000Z

Introducing Pure Comments (and Pure Commons) - Kev Quirk

2026-02-25T15:04:00.000Z

A few weeks ago I introduced Pure Blog a simple PHP based blogging platform that I've since moved to and I'm very happy. Once Pure Blog was done, I shifted my focus to start improving my commenting system. I ended that post by saying:

At this point it's battle tested and working great. However, there's still some rough edges in the code, and security could definitely be improved. So over the next few weeks I'll be doing that, at which point I'll probably release it to the public so you too can have comments on your blog, if you want them.

I've now finished that work and I'm ready to release Pure Comments to the world. 🎉

I'm really happy with how Pure Comments has turned out; it slots in perfectly with Pure Blog, which got me thinking about creating a broader suite of apps under the Pure umbrella.

Enter Pure Commons

I've had Simple.css since 2022, and now I've added Pure Blog and Pure Comments to the fold. So I decided I needed an umbrella to house these disparate projects. That's where Pure Commons comes in.

My vision for Pure Commons is to build it into a suite of simple, privacy focussed tools that are easy to self-host, and have just what you need and no more.

What's next for Pure Commons?

Well, concurrent to working on Pure Comments, I've also started building a fully managed version that people will be able to use for a small monthly fee. That's about 60% done at this point, so I should be releasing that over the next few weeks.

In the future I plan to add a managed version of Pure Blog too, but that will be far more complex than a managed version of Pure Comments. So I think that will take some time.

I'm also looking at creating Pure Guestbook, which will obviously be a simple, self-hosted guestbook along the same vein as the other Pure apps. This should be relatively simple to build, as a guestbook is basically a simplified commenting system, so most of the code is already exists in Pure Comments.

Looking beyond Pure Guestbook I have some other ideas, but you will have to wait and see...

In the meantime, please take a look as Pure Comments - download the source code, take it for a spin, and provide any feedback/bugs you find.

If you have any ideas for apps I could add to the Pure Commons family, please get in touch.

Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️

You can reply to this post by email, or leave a comment.

Book Review: Of Monsters and Mainframes - Barbara Truelove ★★★⯪☆ - Terence Eden’s Blog

2026-02-25T12:34:02.000Z

This is fun, silly, charming, and much better than The Murderbot Diaries despite being superficially similar.

Imagine you are an interstellar ship and, of course, your AI is conscious. What would you do if your passengers were killed - not by a terrifying alien, but by Count Dracula???

What if, on the return journey, another set of your passengers were similarly slaughtered. Except, this time, by a Werewolf? How would that make you feel? Would it drive you mad? Could you cope with the bullying from other starships? Or would you feel the need… the need for REVENGE!

As I said, silly and campy fun. It is episodic adventure with just the right amount of Hammer-style horror and not too much technobabble. All the classic monsters are here - depression, intrusive thoughts, envy, fear.

Oh, and Frankenstein’s spider.

As an ebook, it makes great use of fonts - which give it a delightfully retrofuturistic feel. There are some fun binary Easter-Eggs as well.

mquire: Linux memory forensics without external dependencies - Trail of Bits Blog

2026-02-25T12:00:00.000Z

If you’ve ever done Linux memory forensics, you know the frustration: without debug symbols that match the exact kernel version, you’re stuck. These symbols aren’t typically installed on production systems and must be sourced from external repositories, which quickly become outdated when systems receive updates. If you’ve ever tried to analyze a memory dump only to discover that no one has published symbols for that specific kernel build, you know the frustration.

Today, we’re open-sourcing mquire, a tool that eliminates this dependency entirely. mquire analyzes Linux memory dumps without requiring any external debug information. It works by extracting everything it needs directly from the memory dump itself. This means you can analyze unknown kernels, custom builds, or any Linux distribution, without preparation and without hunting for symbol files.

For forensic analysts and incident responders, this is a significant shift: mquire delivers reliable memory analysis even when traditional tools can’t.

The problem with traditional memory forensics

Memory forensics tools like Volatility are essential for security researchers and incident responders. However, these tools require debug symbols (or “profiles”) specific to the exact kernel version in the memory dump. Without matching symbols, analysis options are limited or impossible.

In practice, this creates real obstacles. You need to either source symbols from third-party repositories that may not have your specific kernel version, generate symbols yourself (which requires access to the original system, often unavailable during incident response), or hope that someone has already created a profile for that distribution and kernel combination.

mquire takes a different approach: it extracts both type information and symbol addresses directly from the memory dump, making analysis possible without any external dependencies.

How mquire works

mquire combines two sources of information that modern Linux kernels embed within themselves:

Type information from BTF: BPF Type Format is a compact format for type and debug information originally designed for eBPF’s “compile once, run everywhere” architecture. BTF provides structural information about the kernel, including type definitions for kernel structures, field offsets and sizes, and type relationships. We’ve repurposed this for memory forensics.

Symbol addresses from Kallsyms: This is the same data that populates /proc/kallsyms on a running system—the memory locations of kernel symbols. By scanning the memory dump for Kallsyms data, mquire can locate the exact addresses of kernel structures without external symbol files.

By combining type information with symbol locations, mquire can find and parse complex kernel data structures like process lists, memory mappings, open file handles, and cached file data.

Kernel requirements

BTF support: Kernel 4.18 or newer with BTF enabled (most modern distributions enable it by default)
Kallsyms support: Kernel 6.4 or newer (due to format changes in scripts/kallsyms.c)

These features have been consistently enabled on major distributions since they’re requirements for modern BPF tooling.

Built for exploration

After initialization, mquire provides an interactive SQL interface, an approach directly inspired by osquery. This is something I’ve wanted to build ever since my first Querycon, where I discussed forensics capabilities with other osquery maintainers. The idea of bringing osquery’s intuitive, SQL-based exploration model to memory forensics has been on my mind for years, and mquire is the realization of that vision.

You can run one-off queries from the command line or explore interactively:

$ mquire query --format json snapshot.lime 'SELECT comm, command_line FROM
tasks WHERE command_line NOT NULL and comm LIKE "%systemd%" LIMIT 2;'
{
 "column_order": [
 "comm",
 "command_line"
 ],
 "row_list": [
 {
 "comm": {
 "String": "systemd"
 },
 "command_line": {
 "String": "/sbin/init splash"
 }
 },
 {
 "comm": {
 "String": "systemd-oomd"
 },
 "command_line": {
 "String": "/usr/lib/systemd/systemd-oomd"
 }
 }
 ]
}

Figure 1: mquire listing tasks containing systemd

The SQL interface enables relational queries across different data sources. For example, you can join process information with open file handles in a single query:

mquire query --format json snapshot.lime 'SELECT tasks.pid,
task_open_files.path FROM task_open_files JOIN tasks ON tasks.tgid =
task_open_files.tgid WHERE task_open_files.path LIKE "%.sqlite" LIMIT 2;'
{
 "column_order": [
 "pid",
 "path"
 ],
 "row_list": [
 {
 "path": {
 "String": "/home/alessandro/snap/firefox/common/.mozilla/firefox/
 4f1wza57.default/cookies.sqlite"
 },
 "pid": {
 "SignedInteger": 2481
 }
 },
 {
 "path": {
 "String": "/home/alessandro/snap/firefox/common/.mozilla/firefox/
 4f1wza57.default/cookies.sqlite"
 },
 "pid": {
 "SignedInteger": 2846
 }
 }
 ]
}

Figure 2: Finding processes with open SQLite databases

This relational approach lets you reconstruct complete file paths from kernel dentry objects and connect them with their originating processes—context that would require multiple commands with traditional tools.

Current capabilities

mquire currently provides the following tables:

os_version and system_info: Basic system identification
tasks: Running processes with PIDs, command lines, and binary paths
task_open_files: Open files organized by process
memory_mappings: Memory regions mapped by each process
boot_time: System boot timestamp
dmesg: Kernel ring buffer messages
kallsyms: Kernel symbol addresses
kernel_modules: Loaded kernel modules
network_connections: Active network connections
network_interfaces: Network interface information
syslog_file: System logs read directly from the kernel’s file cache (works even if log files have been deleted, as long as they’re still cached in memory)
log_messages: Internal mquire log messages

mquire also includes a .dump command that extracts files from the kernel’s file cache. This can recover files directly from memory, which is useful when files have been deleted from disk but remain in the cache. You can run it from the interactive shell or via the command line:

mquire command snapshot.lime '.dump /output/directory'

For developers building custom analysis tools, the mquire library crate provides a reusable API for kernel memory analysis.

Use cases

mquire is designed for:

Incident response: Analyze memory dumps from compromised systems without needing to source matching debug symbols.
Forensic analysis: Examine what was running and what files were accessed, even on unknown or custom kernels.
Malware analysis: Study process behavior and file operations from memory snapshots.
Security research: Explore kernel internals without specialized setup.

Limitations and future work

mquire can only access kernel-level information; BTF doesn’t provide information about user space data structures. Additionally, the Kallsyms scanner depends on the data format from the kernel’s scripts/kallsyms.c; if future kernel versions change this format, the scanner heuristics may need updates.

We’re considering several enhancements, including expanded table support to provide deeper system insight, improved caching for better performance, and DMA-based external memory acquisition for real-time analysis of physical systems.

Get started

mquire is available on GitHub with prebuilt binaries for Linux.

To acquire a memory dump, you can use LiME:

insmod ./lime-x.x.x-xx-generic.ko 'path=/path/to/dump.raw format=padded'

Then you can run mquire:

# Interactive session
$ mquire shell /path/to/dump.raw

# Single query
$ mquire query /path/to/dump.raw 'SELECT * FROM os_version;'

# Discover available tables
$ mquire query /path/to/dump.raw '.schema'

We welcome contributions and feedback. Try mquire and let us know what you think.

Good vibes, bad vendors - Werd I/O

2026-02-25T10:00:03.000Z

When I was thirteen or fourteen I had a really comfortable sweatshirt that I wore to school all the time — but it did have a few inherent problems. For one thing, it had a great big target on it, and wearing a literal target to high school was just asking for it. For another, on top of that, in Looney Tunes writing, was the confident phrase: “It’s a good vibe!”

I was bullied as mercilessly as one might expect, but I honestly think it might have killed in the AI era. I’d like to think I was just ahead of my time.

Andrej Karpathy, an early OpenAI researcher who now works at his own startup, coined the phrase vibe coding last year. To vibe code is to use an LLM like Claude or ChatGPT to generate source code instead of writing it yourself. He meant it as a way to loosely prototype code or to make progress on a weekend project. LLMs, at least at the time, could not be fully trusted to write well-written, working code. It was an out-there idea.

What a difference a year makes. Today, it’s a mainstream conversation that is rapidly reshaping technology strategy — and informing layoffs across industries.

AI conversations are always fraught, for good reasons that include the underlying power dynamics and the bad behavior of most of the AI vendors. At the same time, the whole AI landscape is changing incredibly rapidly, and it’s become a cliché to point out that any discussion of what LLMs can and can’t do today will probably be invalid two or three months from now. And, of course, millions of words have been written about it at this point. But even despite all that, I still think it’s worth talking about.

If you’re running technology in a small, resource-constrained environment — like a newsroom or a non-profit — how should you think about AI-enhanced software engineering? Come to that, how should I?

Let’s talk about it.

First things first: does it work?

It didn’t, and then it did.

Six months ago, LLMs could generate a certain amount of code, but they would often make inefficient decisions or hallucinate libraries and API endpoints, and you’d need to babysit them a lot. Their use was mostly passive: they would generate code snippets based on immediate user prompts, and engineers would have to spend a bunch of time debugging the output. And in terms of security, it was the Wild West; there were essentially no security considerations. LLMs are famously stochastic (their output is randomly determined, not deterministic) and prone to hallucinations. The result was unreliable code.

A lot has changed since then. In particular, the models released in February, 2026 are a sea change in reliability: given the right prompt, they often genuinely can write decent code in one shot. Tools like Claude Code can go off, spawn multiple agents, investigate a problem, build a reasonable plan, and then execute on it, while working in a safely sandboxed environment.

It’s not just about improved models, although they obviously have a central part to play. An ecosystem is developing around doing AI-assisted software engineering well. Plugins like Jesse Vincent’s Superpowers encourage good decision-making based on principles of excellent software architecture design and product management. Structured frameworks like spec-driven development similarly help lead the agent to sensible outcomes; both are incorporated in all-in-one coding lifecycle toolkits like Metaswarm. A rigorous process is preserved, and throughout, there are far more safety guardrails to prevent security incidents (although it’s easy to overcome them, or they’re sometimes not on by default), and using AI to generate code is much safer than it was.

Claude Code absolutely can write the code, build a plan, and document its work. I have been an AI skeptic, but in my experiments I’ve found that it really can feel like magic. You can reasonably object to AI for any number of reasons, but this is no longer one. It works.

The thing to understand is that this is a tool for engineers — and senior engineers will get the best results. It takes real engineering skill to craft a prompt that will do the right thing and result in a strong architecture.

The process changes the center of gravity from writing source code in a programming language to crafting goals, understanding your user, being crystal clear about the experience and the value you want to convey, and thinking about architectural implications. That probably means talking to people, forming a hypothesis about what they need, testing it with them, and considering the ongoing technical implications of the work.

Those are things that senior engineers already spend much of their time doing — indeed, I’d argue that it’s what separates a great senior engineer from a mid-level one. The core question a senior engineer navigates well comes down to: lots of people can write code, but should they? Why, and for whom? Those questions only become more important in a world where AI is writing the source code. When implementation is faster, problem selection and scoping become the scarce skills.

Friction is training: we learn how to engineer software through our terrible experiences. When things go wrong, we learn. When we have to refactor, we learn. When we talk to our peers about our work, we learn. AI removes most of this friction and hides the complexity away from us: it obscures failure, compresses the process of debugging, and automates refactoring. When these hard-earned skills are the reason we can make good software engineering decisions with AI, but the AI doesn’t offer newcomers the ability to build those skills, who will train the AI once we are gone?

Opinions on that change in center of gravity will be intensely divided. I stand by this New Year’s Day thought about Claude Code:

It has the potential to transform all of tech. I also think we’re going to see a real split in the tech industry (and everywhere code is written) between people who are outcome-driven and are excited to get to the part where they can test their work with users faster, and people who are process-driven and get their meaning from the engineering itself and are upset about having that taken away.

I’m very much an outcome-driven developer, and to me it’s a giant relief. Not everyone will feel the same way.

Resource-constrained environments must be outcome-driven. They can’t spend their time on the process of software engineering; the best way for them to move forward is to start small, release a valuable core that solves a problem for some set of users as early as possible, and then continually iterate around it, using user feedback as a guide.

There’s no alternative to having empathetic, human-centered senior engineers on your team — with or without AI. But AI engineering tools may have an interesting side effect: I can see a world where pushing these product and spec questions to the forefront helps more engineers build those skills more quickly. The first step, after all, is understanding that those answers are needed to begin with.

It’s worth saying that there will be many managers who hope that tools like Claude Code will mean they can do away with engineers or dramatically cut their workforces. Of course there will. They may even see engineers as gatekeepers, and there may be resentment that they’re needed at all — and a hope that this work can be done directly by managers or other key employees. In a newsroom, for example, can’t the journalists produce tools now?

For non-engineers, they can be a useful prototyping tool: for a product manager, for example, it may help assess a user interface or experiment with an idea. But those prototypes are not enduring software; nor are they projects that can be “handed off” to engineers to support.

To properly architect a system, there’s a lot you need to consider. This includes performance, scalability, and the ongoing overhead of maintaining a project and keeping it safe: nobody wants to rely on software that proves to be slow, insecure, or impossible to update. You also need to assess the technical implications of a project: are there technical standards that the project should be adhering to, or battle-tested best practices that the design should take into consideration? For all these reasons, an engineer must be involved from the beginning.

These tools can’t replace technical staff, and they shouldn’t. Like I said, these tools are for engineers, not a replacement for them.

Okay, but what about those power dynamics?

Consider an individual, indie developer. Over the last few decades, they’ve become more and more empowered: developer tools have become cheaper and more of them are open source. Power and control have been devolved to the individual; you can run the tools you want on your own hardware, configure or recode them to your needs, use them for free, and share any of your changes. Engineering has become more and more of an open collective built on radical collaboration. That allows developers with fewer resources to build more easily, widening the pool of people who can build startups, create useful tools, and learn these skills to begin with.

AI-assisted engineering centralizes power back in the other direction. Claude Code, Codex, and so on are all centralized, proprietary tools that become harder to move away from the longer they’re relied upon. They’re also expensive: while open source tools are decentralized and free, it’s incredibly easy to spend large amounts on Claude. Based on my own experimentation and anecdotes from friends and peer companies, any engineer that relies on Claude Code as part of their daily work is likely to spend hundreds of dollars a week; these are new costs that didn’t previously exist.

Those extra costs could theoretically be offset by significant performance or efficiency gains. The thing is, those gains aren’t as strong as you might expect given the apparent magic of automatically generated code. A study recently published in Harvard Business Review indicated that adding AI actually intensified the workload, putting engineers at risk of burning out:

The changes brought about by enthusiastic AI adoption can be unsustainable, causing problems down the line. Once the excitement of experimenting fades, workers can find that their workload has quietly grown and feel stretched from juggling everything that’s suddenly on their plate. That workload creep can in turn lead to cognitive fatigue, burnout, and weakened decision-making. The productivity surge enjoyed at the beginning can give way to lower quality work, turnover, and other problems.

These can be mitigated by good work hygiene: enforcing breaks and sensible work hours. But the employers who are most enthusiastic about introducing AI may also be the ones that are least enthusiastic about benefits that center employee well-being over productivity.

I’ve already mentioned that some managers may hope that AI can reduce their investment in software engineers. One can easily imagine that the presence of AI — or, rather, the threat of being replaced by it — could be used as a cudgel to depress engineer salaries. It gives managers more leverage beyond money, too: those longer hours and more intense workloads that the HBR study found could burn engineers out might be more likely in a world where engineers fear for their jobs.

The long-term implications are even starker. Consider a world where the recentralization of power from individuals to large, centralized companies continues at the current pace. When AI writes most source code, fewer and fewer engineers will be capable of doing this work themselves, which will lead to even more dependence and lock-in.

It’s been noted in the past that while generative AI robs artists of the interesting work and leaves them with the mundane bits, for outcome-oriented engineers it robs them of the mundane bits and leaves them with the interesting parts. I’d argue that the real value is in the intersection between coding and the higher-level work; they’re inseparable. By improving the way we code, we improve the way we can solve problems for real people. (How can you solve a problem if you don’t really understand how the solution works?) By improving the way we think about solving problems, we improve the way we code. (How can you code something well if you don’t know who it’s for or why it needs to exist?) They aren’t two separate processes; they’re parts of the same thing. Removing one makes the other less effective.

Without concerted effort, an entire industry will be de-skilled and de-valued, their human expertise replaced with software that charges by the token.

So let’s put in the effort

AI isn’t going away, and AI-assisted software engineering is a permanent addition to the way we build software. But that’s not the same thing as saying that the way we use AI today won’t change.

Any policy for AI-assisted engineering has to take into account risks of various kinds. I’d loosely separate them into the following categories:

Employee risk: preventing burnout, staff turnover, and poor morale.
Security risk: preventing data leaks and security incidents that compromise customers, sources, employees, or other members of the community.
Quality risk: preventing low-quality code that impacts the efficiency, experience, or perceived quality of the organization’s work.
Supplier risk: reducing the potential impact of potentially harmful choices made by AI vendors.

While I’m not going to go into a full framework here — that’s part of what I do at my day job — let’s talk about how we might think about addressing them together.

Employee risk

In that Harvard Business School report about AI-driven burnout in engineers, the authors suggested some sensible mitigations. These included creating, as team norms, structured time for quiet reflection on the project at hand, and limiting interruptions; intentional processes for limiting the work that can move forward, to prevent engineers from taking on (or being asked to take on) too many tasks just because they think they can; and creating more space for empathetic human connection as a team.

Those are all things that every team should do, whether or not they use AI! But they become even more important on an AI-accelerated team. If you don’t have any norms about tightly controlling when work moves forward, for example, adding a tool that accelerates the work will result in a higher volume of work getting processed, but not necessarily any strategic selection about the most important work to do.

Perhaps most importantly, engineers are worried that they’ll be replaced at the hands of managers who may not understand what they do. They need to have the emotional safety and security that comes from knowing that they won’t. It needs to be communicated to them that the importance of their skills is understood. They are experts in their fields, and they’ve just gained another tool to help them; they are not interchangeable with the tool.

Security and quality risk

It turns out that you go a long way towards addressing a lot of security, quality, and efficiency issues — as well as some of the morale issues that lead to employee risk — by placing engineers at the center of the process. Some AI processes talk about “human in the loop”. That term was borrowed from more traditional machine learning processes; in the case of anything where AI takes an action in the world on behalf of a user, like engineering, I’d prefer to reframe it as a tool that is always directly under human control.

In that light, all code must have a human owner who will take responsibility for it. It’s their code, just as if they’d written it in an integrated development environment; they just happened to use a different tool. If all generated code must ultimately be owned and reviewed by a human, that person is able to tune the results for safety, efficiency, and quality.

Most well-run engineering teams have a peer review process where code written by an engineer must be officially reviewed by a second engineer before it can be merged into the main codebase. If we assume that generated code is owned by Engineer A, that means there must be a human Engineer B to give it a second pair of eyes. They might also be using automated tools to help their review along, but they’re the ones who ultimately take responsibility for a review.

This isn’t enough. All projects need to have comprehensive automated testing: tests that must run on code that is about to be merged into the main codebase in order to make sure everything still functions. Tests for efficiency, adherence to style guidelines, and security issues can be run here too. What’s kind of fun is that when these are in place, tools like Claude Code will look at the test output, make corrections when something doesn’t pass, and try again — all automatically.

Supplier risk

The centralization that removes power and agency from engineers also introduces a serious business risk. If a core part of an organization’s value comes from software development, inexorably placing a centralized service in the middle of your process makes you heavily dependent on their decision-making. They can increase their prices, make changes to their stack, or change the way they think about keeping your data and source code safe, and there’s very little you can do about it.

The good news is that, right now, no AI vendor can lock you into their services, because your source code itself and your infrastructure stack are independent of your AI tools. Your code is managed, stored, and hosted in different places, and you can think of source code itself as being a kind of open protocol: because it’s plain text, you can use virtually any tool with it. Source code still has the devolved, open, decentralized properties of the open source ecosystem that has put power in engineers’ hands for decades. That provides at least some protection against an AI vendor suddenly increasing their prices or changing their privacy stance: you can always vote with your feet.

If you’re uncomfortable using one of the major model providers, open source alternatives are available. Tools like Aider and Cline can provide agentic coding using any model, including local models that could theoretically be run on an organization’s own infrastructure. In practice, though, this requires more powerful hardware than most smaller organizations can afford; this may become less of an issue over time, as new hardware emerges, but it certainly is one now. Still, local models could help prevent lock-in — and may prevent some security issues, too.

This inherent openness could change as AI vendors look for ways to increase their revenue and reduce churn. We may see AI-specific alternatives to git and GitHub; I can even imagine programming languages that are “optimized for AI” but that just happen to be proprietary and locked in to a vendor. Every company that builds software should watch for these forms of lock-in and reject them.

We should also be wary of marketing that tells us to just let the AI write code autonomously. These are ideas that cement vendors as a full replacement for the software development process, moving a center of expertise that was previously owned by an organization into a centralized technology owned by someone else. It’s a trap: that world is one where the source code can’t be moved between agents and your products are fully locked into their services without a credible exit.

Do we want to invite these companies into our workplaces?

A ton has been written on the issues surrounding AI. Last summer, I wrote a broader guide to navigating AI that I think still holds up. In it, I noted:

A lot of money has been spent to encourage businesses to adopt AI — which means deeply embed services provided by these vendors into their processes. The intention is to make their services integral as quickly as possible. That’s why there’s heavy sponsorship at conferences for various industries, programs to sponsor adoption, and so on. Managers and board members see all this messaging and start asking, “what are we doing with AI?” specifically because this FOMO message has reached them.

My approach to evaluating AI remains through two main lenses: the technology itself and the vendors who make it. The further reading section of that earlier piece is a good place to start.

The thing that I didn’t mention then, but is worth calling out now, is the sheer precarity of these vendors. AI vendors are offering their services for below cost and have struggled to articulate value in a way that could credibly lead to profitability. Apparently feeling this gap, OpenAI is experimenting with ads and porn, while finding itself under scrutiny for putting teen wellbeing at risk through choices it made to boost engagement. Anthropic was sued by Reddit last year for scraping Reddit data for training without authorization, and had to settle a high-profile lawsuit brought by book authors whose work it stole for training data. I’ve mentioned Claude Code a bunch in this piece, because it works really well, but it was trained using stolen work.

Meanwhile, from a technical standpoint, there has been some research that there are diminishing returns to new LLM development and we’re already past the peak.

There’s no guarantee these companies will make it. If an organization has invested in agentic coding processes that don’t substantially keep humans in the loop and the vendors that power them disappear, they will be left in a bind, with no in-house expertise, and company strategies that depend on AI. That makes it a dangerous gamble. We will have lost internal skill while increasing our dependence on very fragile external suppliers.

So how should you think about it?

AI coding works. It shifts the center of gravity from implementation to judgment, which increases the value of senior engineering skills. It also introduces significant power, labor, and supplier risks. That means that solid guardrails and cultural norms are non-optional.

Even if you haven’t rolled it out yet, your engineers are almost certainly using it. In conversations with my peers, I’ve heard countless stories of organizations that banned it but discovered that its workforce had just taken matters into their own hands. While there are many engineers who refuse to touch it, many more are eager to have it.

You could ban it, but it’d likely be fruitless: those engineers who use their own accounts will probably keep doing so. It’s better to have the tools in a place that’s under your control and observable than used in the shadows in a way that might put your data at risk. Given that, it’s better to roll it out than to not. But you need to do it with your eyes wide open and with a sense of intentionality. Be aware of the risks, and mitigate them in advance with common sense cultural norms like the ones I discussed earlier: pay attention to your employee and supplier risks in particular. Don’t let AI push to production without oversight. And keep humans not just in the loop but fully in control.

I don’t think it’s productive to mandate the use of AI-assisted engineering, which runs the risk of alienating some engineers — the split between AI skeptics and those who are excited about the technology is real — and preventing nuanced discussions about how the technology can be used inside your workplace. What happens in practice when you just let it roll out to anyone who wants to try it is that people do try it; they find that it’s useful for some tasks, and then quickly find its limitations. That’s a healthy exploration.

How should I think about it? I’m still figuring it out. Jesse Vincent compares the process of hating “agentic” development and pushing through it to discover that code was never the most important part of building software to the process of being a manager and asking your team to build things instead of coding them yourself. I agree that these experiences rhyme — but of course, when you lead a team, you’re investing in human beings, working alongside them, and helping them to grow in the process. That’s exponentially more rewarding than leading software agents built to provide value for a megacorporation.

But it doesn’t need to be that way. You can do both. If you treat the technology as a tool, albeit one that has been made by genuinely problematic companies, you can roll it out to a real, human team and continue to build things together. You can invest in and support them while you navigate new kinds of software problems; together, you can figure out how to shape the culture of an engineering team that is undergoing a paradigm shift. You can train the next generation of software engineers, both keeping the long history of software development in mind, and taking into account these new skills. And you can look for the next thing that properly devolves power down the stack to the individual, for the benefit of everyone.

Software development is still human. You can work together towards a shared mission, pick and choose the pieces of this new technology that make sense according to your strategy and values, and build community in the process.

That’s a good vibe.

Everything is awesome (why I'm an optimist) - Westenberg

2026-02-25T01:39:00.000Z

February is the month the internet decided we're all going to die.

In the span of about two weeks, Matt Shumer's Something Big is Happening racked up over 80 million views on X with its breathless comparison of AI to the early days of COVID, telling his non-tech friends and family that we're in the "this seems overblown" phase of something much, much bigger than a pandemic. Before anyone had finished arguing about that, Citrini Research published THE 2028 GLOBAL INTELLIGENCE CRISIS (all caps) a fictional dispatch from June 2028 in which unemployment has hit 10.2%, the S&P 500 has crashed 38% from its highs, and the consumer economy has been hollowed out by what they coined "Ghost GDP": output that shows up in the national accounts but never circulates through the real economy, because, as Citrini helpfully observed, machines spend zero dollars on discretionary goods. Michael Burry signal-boosted it. Bloomberg covered it. IBM fell 13%. Software and payments stocks shed over $200 billion in market cap in a single day, apparently because a Substack post called upon them by name and investors decided that constituted news.

The doom loop Citrini described is simple: AI capabilities improve, companies need fewer workers, white-collar layoffs increase, displaced workers spend less, margin pressure pushes firms to invest more in AI, AI capabilities improve. Repeat until civilization unravels. Shumer, meanwhile, told people to get their financial houses in order because the permanent underclass is imminent.

Both pieces went stratospherically viral, and both, I believe, are entirely wrong about where this is heading.

I want to make a case for optimism.

For anyone who read those pieces and felt the dread, whether you're building AI and worrying about what it means, or you've absorbed the pessimist consensus and started treating decline as a foregone conclusion, or you’re in the bucket of people Shumer insists are fucked; I'm going to argue that the pessimists have the best narratives and the worst track record. The doom scenarios require assumptions that don't survive contact with economic history, and the psychological posture you bring to this moment actually matters for how it turns out.

Why the doom loop feels so right

The central mechanism of the Citrini thesis: when you make intelligence abundant and cheap, you destroy the income that 70% of GDP depends on. A single GPU cluster in North Dakota generating the output previously attributed to 10,000 white-collar workers in midtown Manhattan is, in their framing, "more economic pandemic than economic panacea." The velocity of money flatlines. The consumer economy withers. Ghost GDP accumulates in the national accounts while real humans stop being able to pay their mortgages.

Noah Smith, writing on Noahpinion the day after the selloff, called it "a scary bedtime story" and pointed out that Citrini doesn't use an explicit macroeconomic model, so you can't actually see what assumptions are driving the doom spiral. Smith noted that none of the analysts whose job it is to track Visa and Mastercard stock had apparently thought about AI disruption until a blogger spelled it out for them, which tells you more about sentiment-driven trading than it does about macroeconomics. The economist Gerard MacDonell described the entire piece as "allegorical" but pointed out that it ignores a basic economic principle: production generates income.

Ben Thompson, on Stratechery, has been making a version of this counterargument for months, most forcefully in his January piece AI and the Human Condition, where he argued that even if AI does all of the jobs, humans will still want humans, creating an economy for labor precisely because it is labor. Thompson's framing cuts to something the doom narratives consistently miss. They model AI exclusively as labor substitution: the same economy, minus humans. Every section of the Citrini piece is about replacing workers and squeezing margins on existing activity. What they don't model is what the freed-up surplus creates. As Thompson put it in his analysis of the Citrini selloff, this is the real error: a refusal to believe in human choice and markets.

It's an error that has been made, in nearly identical form, about every major technological transformation in modern history. Every single time, the pessimists looked at what was being destroyed and extrapolated catastrophe, while failing to imagine what would be created, because the thing that would be created hadn't been invented yet.

Catastrophists keep being wrong

In 1810, 81% of the American workforce was employed in agriculture. Two hundred years later, it's about 1%. If you had shown someone in 1810 a chart of agricultural employment decline and asked them to model the economic consequences, the only rational projection would have been apocalypse. Where would 80% of the population find work? What would they do? How would anyone eat if the farmers were all displaced by machines?

The answer, of course, is that entirely new categories of work were created that no one in 1810 could have conceived of, and these new jobs paid dramaticaly more than subsistance farming. Factory work, office work, services, knowledge work, the entire apparatus of modernity: none of it was visible from the vantage point of the pre-industrial economy. The transition was brutal and uneven. The handloom weavers of England suffered. Dickens documented the squalor of early industrialization in prose that still makes you flinch. But the trajectory was real, and the people projecting permanent immiseration from the displacement of agricultural labor were, in the fullest sense, catastrophically wrong.

Tom Lee of Fundstrat made this point with a specific example that I find clarifying. The invention of flash-frozen food in the early 1900s disrupted farming, taking agriculture from 30-40% of employment down to its current sliver. The economy didn't collapse. It reallocated value elsewhere, into industries and occupations that the frozen food pioneers couldn't have imagined. And today, I can't name a single family that subsists on frozen TV dinners.

The Citrini scenario expects you to believe that AI will be the first major technological revolution in which this reallocation mechanism fails entirely. Where every previous wave of automation freed up human labor and capital to flow into new, higher-value activities, this time the loop... stops. The surplus accrues to the owners of compute, consumers lose purchasing power, and the negative feedback loop has no natural brake. It's worth sitting with how strong a claim that is. It requires every previous pattern of technological adaptation to be wrong, or at least irrelevant. And when you look at the actual data, there are signs that white-collar job postings have stabilized, layoff mentions on earnings calls remain well below early 2023 peaks, and forward-looking labor indicators show no sign of the displacement spiral that the doom thesis predicts.

Does that mean AI won't disrupt specific industries and jobs? Obviously it will. Some of those disruptions will be painful and dislocating for the people caught in them. But there's an enormous gap between "this technology will cause serious labor market disruption that we need to manage" and "this technology will cause a self-reinforcing economic death spiral from which there is no recovery." Citrini is arguing the latter, while the evidence supports the former.

Why vivid scenarios beat boring probabilities

There's a reason the doom narratives go viral while the measured counterarguments get a polite nod // a fraction of the engagement. It has nothing to do with the quality of the underlying analysis. It has everything to do with how human brains process information.

Daniel Kahneman's work on the availability heuristic showed that we judge the probability of events by how easily we can imagine them. Dystopia is easy to imagine. We have an extraordinarily rich cultural tradition of imagining technological nightmare scenarios in exquisite detail. Orwell did it brilliantly. Every season of Black Mirror does it competently. The Terminator gave us the visual grammar for AI catastrophe decades before anyone had a working language model. When Citrini describes a world where the unemployment rate hits 10.2% and the S&P crashes 38%, you can picture it. You can feel the dread. Hollywood has been training you to feel exactly this dread for your entire life.

Now try to imagine the positive scenarios. Try to picture, in concrete sensory detail, a world where AI helps us solve protein folding problems across thousands of neglected tropical diseases, where it accelerates materials science research by orders of magnitude, where it makes high-quality legal and medical advice accessible to people who currently can't afford it, where it enables forms of creative expression and economic activity that we can't yet name because they don't exist yet. It's fuzzy and abstract. You can state it intellectually, but you can't feel it the way you can feel the unemployment spiral.

This asymmetry isn't trivial. The Ifo Institute has published research showing that investors are willing to pay more for economic narratives than for raw forecasts, and that pessimistic narratives command higher prices among certain investor types. As Joachim Klement put it in his response to the Citrini selloff: investors value narratives more than actual recession forecasts. Stories travel faster than spreadsheets.

Shumer's piece is a narrative construction, and a questionable piece of analysis. He opens with the COVID comparison: remember February 2020, when a few people were talking about a virus and everyone thought it was overblown? He positions himself as the insider who sees what's coming, who's been "giving the polite, cocktail-party version" but can't hold back the truth any longer. Paulo Carvao, writing in Forbes, noted that it reads at times like a sales pitch. It’s a used-car pitch at that. The Guardian pointed out that Shumer "previously excited the internet by announcing the release of the world's 'top open-source model,' which it was not." (To be clear: this is a kinder way of saying it was fraud.)

But criticism doesn't travel like fear does. Fear is a better story. And so the doom narratives accumulate cultural mass while the boring, incremental, statistically-grounded counterarguments remain niche reading for economists and strategists.

We remember disasters, not the ones we dodged

Humans are spectacular at remembering disasters, passed down in every format from the written word to the oral tradition. We are (for obvious reasons) terrible at remembering the disasters that didn't happen. In 1962, during the Cuban Missile Crisis, a Soviet submarine officer named Vasili Arkhipov refused to authorize the launch of a nuclear torpedo, overriding two other officers who wanted to fire. The world didn't end. Most people today have never heard of Arkhipov. Everyone knows about Hiroshima and Nagasaki. The bomb that fell is seared into collective memory. The bomb that didn't fall is a footnote.

The Y2K bug was going to crash civilization; then billions of dollars of engineering work fixed it, and everyone retroactively decided it was never a real threat. The ozone layer was going to disintegrate; then the Montreal Protocol worked better than almost anyone predicted, and ozone depletion feels like a quaint 1990s worry. Acid rain was dissolving the forests of North America; then sulfur dioxide regulations cut emissions drastically, and the whole issue evaporated from public consciousness. Every one of these was a genuine threat. Every one was met by human ingenuity and institutional coordination. Every one was subsequently memory-holed, because success is boring and failure is vivid.

We're running our forecasting models on a dataset that systematically excludes our wins. It should be entirely unsurprising that the forecasts come out somewhat bearish.

Ben Thompson (as usual) gets it right

Thompson's core insight is that humans want humans. He points to the agricultural revolutions: in the pre-Neolithic era, zero percent of humans worked in agriculture. By 1810, 81%. By today, 1%. Machines replaced human agricultural labor entirely, and rather than the economy collapsing, entirely new categories of work were created that paid dramatically more. This cycle played out again with industrialization, with computing, with the internet. Every time, the displacement was real, and every time, new forms of human-valued work emerged that couldn't have been predicted.

Citrini called DoorDash "the poster child" for AI disruption, imagining vibe-coded competitors fragmenting the market overnight. Thompson flips it: DoorDash is the poster child for why the article is absurd. DoorDash didn't always exist. It was built, and it wins through the active choice of customers, restaurants, and drivers. The doom thesis treats it as a static rent-extraction layer sitting on top of human laziness, but DoorDash created its market from scratch and generated new jobs for millions of drivers along the way. What the Citrini analysis lacks, Thompson argued, is any belief in human choice or markets. If your starting assumption is that things are as they are, you can only envision breaking them.

Citrini predicted AI would collapse real estate commissions by eliminating information asymmetry. But the internet already did that. You can look up every house for sale right now, with full history and photos. Real estate agents still exist, which is one of the better arguments that humans are resourceful at giving themselves work to do even in fields where they arguably shouldn't need to.

In a world of AI abundance, the things humans create will become more valuable precisely because they're human. AI art will make human art more desirable, not less, because provenance matters. AI-generated content will make human-generated content worth more, because the imperfections and idiosyncrasies are features.

Is this optimistic? Yes. Could it be wrong? Sure it could. But it's grounded in a real observation about human psychology that the doom models don't account for. Citrini's Ghost GDP thesis assumes that when AI replaces human labor, the value simply evaporates from the consumer economy. Thompson's counterargument is that humans will create new forms of value that are specifically human, and that demand for those forms of value will intensify as machine-generated alternatives become ubiquitous. The history of technological disruption suggests Thompson has the stronger case.

Pessimism as a self-fulfilling prophecy

What actually worries me is the second-order effects of the doom narrative itself.

When the smartest, most technically capable people in a field become convinced that the field is heading toward catastrophe, several things happen. Some leave the field entirely, removing exactly the talent you'd want steering the ship. Some stay but adopt a posture of resigned inevitability, which is functionally identical to apathy. Some decide that since disaster is coming, they might as well accelerate and cash out. And a vocal minority become so consumed by existential risk that they advocate for extreme countermeasures that would concentrate power in ways that create entirely new categories of danger.

Robert Oppenheimer (in the wake of his famous invocation of the Bhagavad Gita) spent the years after the Manhattan Project arguing passionately for international cooperation on nuclear governance. He didn't say "we should never have done this." He said, essentially, "this is incredibly powerful, and we need to build institutions that can handle it." He was an optimist in the meaningful sense: he believed better outcomes were achievable if people worked to achieve them. He was right about that, because we're still here.

The most effective people working on AI safety and governance right now are, almost without exception, optimists. They work on alignment because they believe alignment is solvable. They push for better governance becuase they believe governance can work. The ones who've concluded that the problem is unsolvable tend to stop doing useful work, for obvious reasons.

Gramsci wrote about "pessimism of the intellect, optimism of the will." You look at the world clearly. You see the problems. And then you choose to act as if better outcomes are possible, because that choice is the precondition for achieving them.

Nobody can see the next economy

What both Shumer and Citrini miss is that they're modeling a future economy using the structure of the present economy. They see AI replacing white-collar workers within the existing economic framework and project the consequences of that replacement within that same framework. But every major technological transformation has changed the framework itself, creating entirely new economic structures that were invisible from the vantage point of the old ones.

In 1995, if you told someone that one of the largest employers in America would be a company that let strangers sleep in each other's homes, they would have thought you were insane. If you told them that millions of people would make a living by talking into microphones about their opinions, or recording themselves playing video games, or writing newsletters on the internet, they'd have had you committed. The entire creator economy, the gig economy, the app economy, the SaaS economy that Citrini is now eulogizing: none of it was predictable from the vantage point of 1995. And that's a 30-year window. The agricultural revolutions played out over centuries.

What will people do when AI can handle most current white-collar tasks?

I don't know.

And that's the whole point.

Nobody knew what displaced agricultural workers would do, either, until they did it. The absence of a visible next chapter isn't evidence that there won't be one. It's evidence that we're bad at predicting what humans will invent when constraints shift.

Choosing optimism with open eyes

I'm not saying everything will be fine. I'm not saying the transition will be smooth. I'm not saying that the people displaced by AI won't suffer, or that we don't need better policy frameworks to handle the disruption. The distributional concerns at the heart of the Citrini piece are legitimate. If productivity gains accrue primarily to the owners of compute and capital while labor income stagnates, that's a genuine problem. Labour's share of GDP has been declining for decades. These are real numbers pointing to real challenges.

What I am saying is that the leap from "this will be disruptive and we need to manage it carefully" to "this will cause an irreversible economic death spiral" isn't supported by the evidence, by economic history, or by what we know about how humans respond to technological change. The Citrini scenario requires every adaptive mechanism in the economy to fail simultaneously and completely within roughly two years. That's a very specific left-tail outcome.

If you're building AI systems, if you're founding companies, if you're writing code that will shape how people experience the world, your psychological orientation toward the future is a variable that directly shapes // affects outcomes. Pessimistic builders build defensively. They hoard and hedge and make decisions based on fear. Optimistic builders build with ambition. They invest in safety because they believe safety is achievable. They take on hard problems because they believe hard problems have solutions.

The tech industry is at a hinge point, and the narrative it tells itself will shape what it creates. If the dominant narrative is doom, the best people leave, the remaining people race to extract value before the collapse, and the governance frameworks get built by people who don't understand the technology. If the dominant narrative is cautious optimism, the best people stay, the work is good, and the institutions get built by people who know what they're building for.

Ed Yardeni, the veteran Wall Street strategist, noted in the wake of the Citrini selloff that "the AI story has morphed from a Roaring 2020s productivity booster to an existential threat to our way of life." He found this striking. I find it absurd. The underlying technology hasn't changed, and the capabilities haven't shifted. What changed is the narrative, and narratives are always, always choices.

I choose optimism. I choose it because the alternative is surrender as sophistication. And because every time I look at the historical record, the full record that includes both the disasters and the averted disasters, both the tragedies and the triumphs, the case for human ingenuity and resilience is stronger than the case against it.

The doomers may have the best stories.

I believe the optimists have the best evidence.

I'll take the evidence.

Everything is (going to be) awesome.

Notes on Setting up Forgejo on Coolify with SSH - Robb Knight • Posts • Atom Feed

2026-02-24T19:59:19.000Z

For reasons that I'll write about on another post, I had occasion to setup my own instance of Forgejo - "a self-hosted lightweight software forge", aka "We have GitHub at home". Despite having an install of Coolify on one of my servers which should have made this one-click, it was significantly more clicks than that.

The version in Coolify's library is version 8 where the current version is 14 - this was the start of my issues. I was able to get Forgejo running. I could create repositories, clone them and push, but only over HTTPS and not SSH. The port should have been mapped correctly to make it work but something was misconfigured. SSH is never a fun thing to debug and I had lots of help from Adam, Melanie, and Daniel all of whom had it working on their instances without any tinkering.

As best I can tell is that between version 8 and 14 lots of things changed, as you'd expect, so changes I made to port mapping weren't applying correctly. Then I'd try a fresh install but forget other settings I needed to edit. Then I'd do it again and forget something else. I installed Forgjo from fresh at least six times before I was able to get it running and the final working version was simple: change the version to 14, change the 22222 port mapping to 2222 and don't touch anything else. That's it. I had seen this GitHub issue which also ended with "lol did a reinstall now it's fine" so I at least have a bit more info here.

My final docker compose file looks like this:

services:
  forgejo:
    image: 'codeberg.org/forgejo/forgejo:14'
    environment:
      - SERVICE_URL_FORGEJO_3000
      - 'FORGEJO__server__ROOT_URL=${SERVICE_URL_FORGEJO}'
      - 'FORGEJO__migrations__ALLOWED_DOMAINS=${FORGEJO__migrations__ALLOWED_DOMAINS}'
      - 'FORGEJO__migrations__ALLOW_LOCALNETWORKS=${FORGEJO__migrations__ALLOW_LOCALNETWORKS-false}'
      - USER_UID=1000
      - USER_GID=1000
    ports:
      - '2222:22'
    volumes:
      - 'forgejo-data:/data'
      - 'forgejo-timezone:/etc/timezone:ro'
      - 'forgejo-localtime:/etc/localtime:ro'
    healthcheck:
      test:
        - CMD
        - curl
        - '-f'
        - 'http://127.0.0.1:3000'
      interval: 2s
      timeout: 10s
      retries: 15

Miscelanea

The app.ini file, when installed with Docker, lives at /data/gitea/conf/app.ini.

You can add robots.txt, customise the icons, and even the templates. These won't exist in the container under data/gitea/public (for robots and icons) or data/gitea/templates on a standard install. If you add them, they then override the defaults, usually after a reboot. My updated home page template, home.tmpl:


<div role="main" aria-label="" class="page-content home">
	<div class="tw-mb-8 tw-px-8">
		<div class="center">
			<img class="logo" width="150" height="220" src="/img/logo.svg" alt="">
			<div class="hero">
				<h1 class="ui icon header title" style="font-size: 3.5em;">
					
				</h1>
				<p style="font-size:1.3em">The personal Git instance of 
                <a href="https://rknight.me">Robb Knight</a>. 
                <a href="/robb">Have a gander at the code</a>.</p>
			</div>
		</div>
	</div>
</div>

Finally, not Forgejo related but noting it here anyway, to connect to the container when you're on the server (via Cory), run docker ps -a | grep forgejo to find the Forgejo container then use the ID to connect: docker exec -it <ID> sh.

You can browse the code I've already moved on my Forgejo at git.7622.me.

Adding OpenStreetMap login to Auth0 - Terence Eden’s Blog

2026-02-24T12:34:21.000Z

So you want to add OSM as an OAuth provider to Auth0? Here's a tip - you do not want to create a custom social connection!

Instead, you need to create an "OpenID Connect" provider. Here's how.

OpenSteetMap

As per the OAuth documentation you will need to:

Register a new app at https://www.openstreetmap.org/oauth2/applications/
Give it a name that users will recognise
Give it a redirect of https://Your Auth0 Tenant.eu.auth0.com/login/callback
Tick the box for "Sign in using OpenStreetMap"

Once created, you will need to securely save your Client ID and Client Secret.

Auth0

These options change frequently, so use this guide with care.

Once you have logged in to your Auth0 Tennant, go to Authentication → Enterprise → OpenID Connect → Create Connection
Provide the new connection with the Client ID and Client Secret
Set the "scope" to be openid
Set the OpenID Connect Discovery URL to be https://www.openstreetmap.org/.well-known/openid-configuration
In the "Login Experience" tick the box for "Display connection as a button"
Set the favicon to be https://blog.openstreetmap.org/wp-content/uploads/2022/07/osm-favicon.png or other suitable graphic

Next Steps

We're not quite done, sadly.

The details which OSM sends back to Auth0 are limited, so Auth0 is missing a few bits:

{
    "created_at": "2026-02-29T12:34:56.772Z",
    "identities": [
        {
            "user_id": "openstreetmap-openid|123456",
            "provider": "oidc",
            "connection": "openstreetmap-openid",
            "isSocial": false
        }
    ],
    "name": "",
    "nickname": "",
    "picture": "https://cdn.auth0.com/avatars/default.png",
    "preferred_username": "Terence Eden",
    "updated_at": "2026-02-04T12:01:33.772Z",
    "user_id": "oidc|openstreetmap-openid|123456",
    "last_ip": "12.34.56.78",
    "last_login": "2026-02-29T12:34:56.772Z",
    "logins_count": 1,
    "blocked_for": [],
    "guardian_authenticators": [],
    "passkeys": []
}

Annoyingly, Auth0 doesn't set a name or nickname - so you'll need to manually get the preferred_username, or create a "User Map":

{
  "mapping_mode": "use_map",
  "attributes": {
    "nickname": "${context.tokenset.preferred_username}",
    "name":     "${context.tokenset.preferred_username}"
  }
}

There's also no avatar image - only the default one.

Getting the Avatar Image

The OSM API has a method for getting user data.

For example, here's all my public data: https://api.openstreetmap.org/api/0.6/user/98672.json - thankfully no authorisation required!

{
  "user": {
    "id": 98672,
    "display_name": "Terence Eden",
    "img": {
      "href": "https://www.gravatar.com/avatar/52cb49a66755f31abf4df9a6549f0f9c.jpg?s=100&d=https%3A%2F%2Fapi.openstreetmap.org%2Fassets%2Favatar_large-54d681ddaf47c4181b05dbfae378dc0201b393bbad3ff0e68143c3d5f3880ace.png"
    }
  }
}

Alternatively, you can use the Unavatar service to get the image indirectly.

I hope that's helpful to someone!

Dopplr colours - James' Coffee Blog

2026-02-24T09:03:45.000Z

Last year I was introduced to the idea of “Dopplr colours” in the IndieWeb community. This refers to an accent colour assigned to cities on the now-defunct travel website Dopplr. You can see examples by clicking through different Dopplr city pages in the Internet Archive and paying attention to the borders of the map.

While I haven’t been able to find an authoritative description of the algorithm, to the extent I understand the Dopplr colours were assigned using an MD5-based algorithm. Aaron implemented a demo of the Dopplr colour system and described the algorithm in PHP as:

substr(md5($_REQUEST['city']), 0, 6)

Here is an equivalent Python implementation:

import hashlib

colour = hashlib.md5("jamesg.blog".encode()).hexdigest()[:6]

print("#" + colour)

These code snippets calculate the MD5 hash for a string, then take the first six characters. This creates a hexadecimal value that can then be used as a colour. The Dopplr colour for my domain name is #e228f3. It’s pink! Of note, you can calculate a Dopplr colour for any string, not just city names.

The IndieWeb community uses Dopplr to assign colours to cities in its timeline of in-person IndieWebCamp events:

I had never heard of the idea of Dopplr colours prior to the IndieWeb, and a Google Search was not fruitful in returning a page that described the algorithm. I thought I’d write this page to document the idea, and make it easier for people to find the idea.

Finished reading Blood Rites - Molly White's activity feed

2026-02-24T02:48:20.000Z

Finished reading:

The Dresden Files series, book 6.

Blood Rites

by Jim Butcher.

Published 2004. 372 pages.

Started February 8, 2026; completed February 21, 2026.

IndieWeb events, cleaning up and speedcubing - W08 - Joel's Log Files

2026-02-24T01:10:00.000Z

These weeknotes are being written earlier than usual, started on Thursday and will continue to be filled up throughout the weekend. I often forget some things going on in one day or another, so maybe doing it like this will be helpful, as more things are fresh on my memory as of the time of writing them.

Now that I’m finishing them in early Monday, so many things have happened… My country is in a state of disarray, as conflict between the army and drug cartels has risen after the leader of the biggest cartel in Mexico died. I type this after my workplace gave us the day off to avoid any risks. Me and family are safe, thank God. Alas, let’s continue with the rest of the notes!

📅 A few days ago I forgot to bring up that I assisted to a Homebrew Website Club meeting! I was invited by Naty and have been to a couple meet-ups already, but never talked until now. you can check the last event’s notes to see what we talked about! I introduced myself, talked about my bookshelf and my blog pings, and shared how I find people who mention my website via FreshRSS user queries.
✍️ I also had the chance to join the HWC Writing Edition meeting, which was hosted by James himself! That was pretty cool, although I didn’t speak at all on this one since I wasn’t by myself.
🏋️ Gymgoing was a bit of a failure this week, I went only once. However, I did use the stationary bike on my room, so that’s at least something, right?
🎮 Last week I couldn’t get my 8BitDo Pro 2 controller to connect via Bluetooth to my Laptop, but after dabbling around in a manner of ways, and installing tools like evtest and connecting to it via bluetoothctl something happened and it is now getting properly recognized and usable wirelessly! I played a lot more times later in the week and it connects without any issues now.
💾 I cleaned up my bedroom during the weekend, and honestly I am much happier with it once again. I found some inspiration to write about some old hardware of mine collecting dust. There’s a couple things yet to do, but they can wait.
⏲️ For the first time in ages, I did a 10-solves speedcubing session. The results were pretty good, if I do say so myself. My best time was 18.38 seconds, by best average of 5 was 19.98, my overall average was 25.55.
⌚ I think it might be nice to mention the watch I wore throughout the week! It’s often my Casio Royale, but this week I switched it up for the Casio CA-53W, I also wore the A-130WE yesterday!

Gaming

Completed

Resident Evil 2 - I cannot praise this game enough. This old title for the PS1 has been an absolute success for me, I finished playing the whole Leon A side and it was a joy from start to finish! I also started and finished the Claire B side, and experiencing a the story from a different angle was incredible to see, so much effort went into this game, and I enjoyed the variety between both scenarios, even if they don’t perfectly line up. For a game from the late 90s, it is commendable. It’s basically four campaigns—plus a bunch of extra modes to unlock—allowing for so much fun and replayability. I may revisit it some other time, but I’m also curious to try the other classics.

Ongoing

Grapple Dog - I have played some more levels of this game and it is really fun! A cute platformer with some challenge but rather great level design so far, I’ve already completed the first two worlds, and gotten a bunch of the collectibles as well, it’s rather awesome to traverse and the gameplay design has been top notch, every level introduces interesting mechanics! I kind of want to get all the achievements of this one, and I’m poking away at it whenever I’m on my laptop.
Final Fantasy VI - After obtaining the Falcon, my new flying ship, I decided to just grind for a little bit, but didn’t progress much in the story, I talked to a few people in a new town, to find some of my lost friends!
Slice & Dice - A few fights here and there, nothing too much happening, but I played it and had fun!

Reading

Planetes - I’ve read a few more chapters of this and I still find it super enjoyable. The plot has started to pick up and a timeskip happened that puts us right in the vanguard of space exploration. I an really looking forward for the rest of it, and I’m also a bit upset that it won’t much longer, as the manga is already finished with less than 30 chapters total.
Persepolis Rising - I keep struggling to commit to actually reading this book. I love the progress I made thus far, need to keep it up.

Around the Web

This time I added a new section where I will mention things I discovered or learned during the week! It can contain games, websites and other tidbits that aren’t blogposts or videos.

Blogposts

first impressions of my MP3 player (Innioasis Y1) - I love seeing more fellow bloggers getting into this kinda retro-inspired single-purpose device trend that I’ve noticed more lately. It may be just a temporary thing, but I genuinely find joy in it.
Unpublishing posts - I was actually going to share the series that Syl unpublished, but this post sharing some thoughts about getting too personal on the web. I don’t really mind that much when it comes to music, but there’s some things that I may have doubts on. Do whatever you like with your site people!
Letting go of old hobbies - This is such an interesting post, what happens when you had your fill with the hobby you enjoyed doing? When you are content with your skill, or your setup, and you don’t need to pursue any more? Good stuff.
Emulate vs Paying up! - Pokémon FireRed and LeafGreen made it to the Nintendo Switch, and they are not $20, but $26 USD in my country. I am not paying that kind of money for a GBA game that I can already play on my Anbernic or my Miyoo devices.
Rediscovering my CD collection - Elena shares some thoughts about her CD collection, ripping them up, digital vs physical media and optimizing the physical space they use, as well as some general thoughts about her music listening habits!

YouTube

These are Anbernic’s strangest handhelds - This was an incredible video featuring Anbernic’s mishaps creating handhelds. They always seem to have a caveat that makes them one step away from perfection. This was a very fun watch.
Handheld gaming has changed - A video reflecting on modern handheld gaming. The experience on the go should be quick and easy to return to. It doesn’t need to be a grandiose adventure, just something quick to lock-in to and spend time, but things have gotten muddier lately.
How Capcom botched the remakes of Resident Evil 2 and 3 - This was a wonderful video that explains in details the things that the RE remakes—wonderful games by themselves—
The transformative power of classical music - A YouTube short led me to this wonderful TED talk, I really enjoyed the speech given here, and the piano performance and the way things are laid out was simply superb, just give this one a watch, it’s an old one, but still holds up.

Cool discoveries

TTRPG Resources - Dave wrote a cool list of resources he has been finding as he explores the world of tabletop RPGs.
Games like Resident Evil - I found out about some games that follow the classic fixed camera and tank controls of the original games. Some interesting ones are Alisa, which features PS1-style graphics, or Tormented Souls, which is a more modern take that still sticks to the classic formula.

This is day 21 of #100DaysToOffload

Reply to this post via email | Reply on Fediverse

Agentic swarms are an org-chart delusion - Westenberg

2026-02-24T01:07:08.000Z

The "agentic swarm" vision of productivity is comfortingly familiar.

Which should be an immediate red flag...

You take the existing corporate hierarchy, you replace the bottom layers with a swarm of AI agents, and you keep humans around as supervisors. It's an org chart with robots instead of interns. The VP of Engineering becomes the VP of Engineering Agents.

Congratulations. You've reinvented middle management.

This is what Clayton Christensen would have called a sustaining innovation in the guise of disruption: you're using new technology to do the same thing slightly more efficiently, in a way that looks and feels like the old thing, and the incumbents love it because the power structure stays intact.

The person at the top still delegates. They still think in terms of roles and departments and functional areas. They've just swapped out the people underneath them for software that doesn't need health insurance.

But when an actually disruptive technology arrives, it makes the existing structure irrelevant.

And AI is that tech.

Roles are an artifact, not a law

The entire "swarms of agents" model is based on the idea that work naturally decomposes into roles. You ~need a marketing agent, a sales agent, a support agent, a development agent - because marketing, sales, support, and development are existing job titles and, for humans at least, fundamentally different activities that belong in different boxes.

This feels like an obvious truism, but it's a depreciable artifact of organizational scaling, not some deep // universal truth about work itself.

Adam Smith's pin factory example is famous because he showed that dividing labor into specialized roles made pin production dramatically more efficient. But the pin factory was a specific solution to a specific constraint: individual humans are slow, they get tired, and they can only hold so much context in their heads at once.

Specialization was a workaround for bio-cognition. If you could have one person who simultaneously understood metallurgy, wire-drawing, straightening, cutting, pointing, grinding, and packaging - and could do all of it concurrently without fatigue - Smith would never have divided the labor in the first place.

That hypothetical person is what a solo practitioner with a capable AI already looks like.

Outcomes over org charts

When I sit down with an AI assistant and say "write me a marketing brief, then generate the landing page copy, then draft the ad variants, then build the page, then set up the analytics tracking," I'm not managing a team of five agents with five different specializations. I'm issuing a sequence of commands to the same system from the same interface.

The boundaries between "marketer" and "developer" and "analyst" dissolve, because those boundaries were never real boundaries in the work itself. They were boundaries in human capacity.

The people who will thrive aren't "agent managers." They're people who can say what they want and evaluate whether they got it - and whether what they got was either good or shit.

The workflow looks less like a CEO directing department heads and more like a musician working in a DAW: one person playing every instrument, mixing, mastering, and producing, toggling between tasks at the speed of thought rather than delegating through layers of abstraction.

Brian Eno talked about the recording studio as a compositional tool — something that collapsed composer, performer, and engineer into one creative role. AI is doing the same thing to knowledge work, collapsing strategist, executor, and analyst into one operational role.

This is ~already happening

Plenty of one-person businesses are shipping products, running marketing, handling support, and managing finances through a single AI-augmented workflow. They're not thinking about it in terms of agents with job titles. They're thinking about it as "what do I need to get done today" and then doing all of it, fluidly, without ever switching between conceptual departments.

The "swarm of agents" idea appeals to people who either come from or aspire to the world of management. If you've spent your career hiring people and organizing them into teams - or dreaming // LARPing about becoming a CEO - then naturally you look at AI and see a new kind of team to organize. It's Maslow's hammer. When all you have is an org chart, everything looks like a headcount decision.

Why this matters

If you believe the future is agent management, you'll build tools for orchestrating fleets of specialized bots. You'll create dashboards for monitoring your marketing agent separately from your sales agent separately from your dev agent. You'll recreate Salesforce, but for robots.

If you believe the future is unified execution, you'll build tools that let one person express intent and get outcomes across every domain from a single surface. The interface collapses. The abstraction layers disappear. You don't manage agents any more than you manage the individual transistors in your laptop.

The first path leads to a world that looks a lot like the one we already have, just with fewer humans in the lower tiers.

The second path leads to something actually new: a world where the unit of economic production isn't the company or the team but the individual, with a general-purpose cognitive tool that makes specialization itself an anachronism.

I know which version the people who currently sit atop org charts would prefer. And I know which version the technology is actually pushing toward. Those two things, for the moment, are very different.

But the technology tends to win these arguments eventually. It won in music production. It won in publishing. It won in video. Every time a tool collapses specialized roles into generalist capability, the generalists inherit the earth — no matter how loudly the specialists insist their particular expertise can't be automated or absorbed.

The future of work isn't managing a swarm.

It's being the swarm.

Thoughts on Farcaster - Westenberg

2026-02-23T22:07:22.000Z

For the past few weeks I've been asking myself why I'm still on Farcaster, whether I'll stay, whether I even want to.

I've landed on some answers.

Farcaster, for the uninitiated, was the most credible attempt anyone has made at building a decentralized, crypto-based social network that people actually wanted to use. Founded in 2020 by Dan Romero and Varun Srinivasan, both ex-Coinbase, and backed by $180 million from Andreessen Horowitz, Paradigm, and Union Square Ventures, Farcaster set out to prove that crypto could build something worth using beyond speculation and exit liquidity and the endless recursive loop of tokens that exist to fund the creation of more tokens. It was going to be the social network you actually owned, where your identity and your social graph belonged to you in some meaningful sense, where no single corporate entity could rug-pull your entire online life the way Elon Musk had done to Twitter's culture or Mark Zuckerberg had done to everyone else.

And for a while, it worked. Vitalik Buterin posted there. Developers built interesting things on the protocol; Frames, for instance, let you embed interactive applications directly into posts. The Farcaster team shipped a working decentralized protocol that multiple independent teams could build on without permission. Most crypto projects never come close to that kind of technical achievement. And the vibe was good! If you squinted, you could see the outline of what a post-platform internet might look like: open protocols and communities forming around shared creation rather than algorithmic optimization.

And then 2025 happened.

After the crash

In December 2025, Dan Romero announced that social-first hadn't worked.

Farcaster pivoted to wallets and trading. The thesis was "come for the tool, stay for the network," an honest attempt to find the growth mechanic that the social layer alone hadn't provided. The wallet had been performing well, and Romero called it "the closest we've been to product-market fit in five years." You can argue with the direction, but I don't know that you can argue with a founder who spent half a decade on one approach, acknowleged it wasn't working, and tried something else instead of pumping a token and heading for the exits.

I'd call this integrity by crypto standards and, frankly, by most standards.

In January 2026, Neynar, the infrastructure company that already powered most of Farcaster's ecosystem, acquired the whole thing. Protocol contracts, code repositories, the app, Clanker, all of it. Romero and Srinivasan stepped back // away.

The handoff makes sense. Neynar had been Farcaster's backbone since 2021, serving over a thousand customers. If anyone understood the ecosystem's plumbing, they did. But it also meant the social network now had a new steward, and regardless of how well-intentioned that steward might be, an era had come to an end and the structural reality had shifted.

All of this happened against the backdrop of crypto's broader 2025 reckoning. The memecoin market cap collapsed from $150.6 billion in December 2024 to $39.4 billion by November 2025. The TRUMP token, launched three days before the inauguration with the subtlety of a carnival barker, cratered over 90% from its $75 peak. The LIBRA token, shilled by Argentine President Javier Milei on Valentine's Day, vaporized $4.5 billion and took 86% of its investors' money with it. Over 11.5 million crypto tokens died in 2025, most of them memecoins, most of them launched with no roadmap and no team, with no purpose beyond being the next thing someone could pump before dumping. The October crash wiped $19 billion in leveraged positions in a single event. The Fear & Greed Index, which had read "extreme greed" in September, plummeted to levels that suggested the market had collectively remembered that gravity exists...

If you were looking for a narrative about crypto fulfilling its original promise of financial sovereignty and a more equitable internet, 2025 was a punishing year.

I believe Romero and Srinivasan gave Farcaster everything they had to give. I believe they cared // gave a shit // tried. They spent five years building real infrastructure and shipping real products. They cultivated a community. They weren't exit-scamming or pumping a token. They were doing the boring // unglamorous work of trying to make decentralized social media function at scale, and they ran into the hard problem that it might not be possible.

Loyalty on a sinking ship

Platform loyalty during a platform's decline starts to feel religious. You're maintaining faith in something when the material conditions no longer support that faith. You're posting into a feed that's getting quieter. You're engaging with a community that's growing smaller. The people who remain on a platform in decline (let's be blunt about this) are, by definition, the people who didn't leave, and that group is filtered for stubbornness, ideological commitment, sunk-cost fallacy, or some combinaton of all three.

I know this pattern. We've all lived through it. LiveJournal. Google+. Vine. Tumblr's long twilight after the porn ban. Each one had its diaspora moment, the point where the population crossed some invisible threshold and the network effects reversed. Instead of each new user making the platform more valuable, each departing user made it less valuable, and the departure curve steepened. Robert Metcalfe's law, which tells us a network's value scales with the square of its users, works in both directions. The math is merciless on the way down.

You can map this against Albert Hirschman's framework from Exit, Voice, and Loyalty. When an organization declines, members can exit (leave), exercise voice (complain and try to fix things), or remain loyal (stay and hope). The internet has made exit nearly frictionless (you can sign up for Bluesky in ninety seconds) and voice nearly useless, because platforms at scale have no meaningful feedback mechanism between users and decision-makers. What's left is loyalty, and loyalty without either exit costs or voice mechanisms is inertia.

In Italo Calvino's Invisible Cities, Marco Polo describes a city called Fedora. In the city's museum, there are glass globes containing miniature models of the city, each one representing a version of Fedora that was imagined but never built, all the possible Fedoras that could have existed but didn't. The citizens spend their time gazing at these alternatives, at the roads not taken, the architectures never constructed. Farcaster sometimes feels like one of Calvino's globes: a beautiful model of what decentralized social could have been, preserved in amber, admired by a shrinking group of people who remember what it was supposed to become.

Why I haven't left

...And yet?

And yet.

I still haven't left.

I wish I had a clean, satisfying reason; something about decentralization principles or the irreducible value of owning your own social graph.

And those things do matter. But the real // honest answer is messier.

Partly it's that the alternatives are all terrible in their own specific ways. X under Musk has become, as Vitalik Buterin put it, "a death star laser for coordinated hate sessions." Bluesky absorbed the X refugees and immediately began replicating the dynamics that made X miserable. Threads is Instagram's vestigial social limb. Mastodon remains Mastodon, which is to say: technically impressive and culturally impenetrable, governed by norms that make posting feel like filing a planning application with the local council.

Partly it's that Farcaster, even in its diminished state, retains something I haven't found elsewhere. The community that remains is small, but it's weighted toward people who build things and people who think carefully about what they're building. The feed isn't optimized for engagement, nobody's trying to go viral, and the conversations that happen there have a texture I associate with early internet forums (in a good way.)

And partly it's that leaving would feel like conceding a point I'm not yet ready to concede.

Crypto's broken promise

The irony of crypto's 2025 collapse is that the technology worked. The Ethereum network processes transactions reliably. Layer 2 solutions have made fees manageable. Smart contracts execute as written. The decentralized exchange infrastructure handles billions in volume. The pipes do what pipes are supposed to do. What failed was the civilization we were supposed to build on top of them. What failed was...well, us.

The crypto pitch I actually gave a shit about (predating the NFT boom and the memecoin casino and the $75 presidential tokens) was infrastructure - building systems that couldn't be captured by any single actor, where the rules were encoded in mathematics rather than terms of service, and where your relationship to a platform couldn't reasonably be compared to serfdom.

That pitch had its origins in the cypherpunks of the 1990s, from Timothy May's "Crypto Anarchist Manifesto" and Eric Hughes's "A Cypherpunk's Manifesto," documents that imagined cryptography as a tool for individual sovereignty in an age of institutional surveillance. The cypherpunks weren't utopians, exactly. They were pragmatists who understood that privacy and autonomy wouldn't be granted by institutions, that they'd have to be built, technically, from the ground up.

Incentives pulled that vision apart. The same cryptographic tools that could enable sovereign identity and censorship-resistant communication enabled speculation at speed and scale. And speculation is both more "fun" than infrastructure and a good deal more viral. It certainly generates better fees, which is why pump.fun, the platform that enabled the creation of thousands of doomed memecoins, remained one of crypto's most profitable companies throughout 2025 even as the tokens it birthed collectivley lost billions in value.

When a technology designed to resist capture becomes the basis for financial instruments, the financial instruments capture the technology. The tail wags the dog. The protocol exists to serve the token, not the other way around. And the people building on the protocol start optimizing for token price rather than for the thing the protocol was supposed to enable.

Farcaster wasn't immune to this gravitational pull. The acquisition of Clanker, the AI token launchpad, in October 2025 signaled a shift in orientation. By the time Romero announced the wallet pivot in December, the trajectory was clear: the social network would become the social layer of a financial product, which is a very different thing than being a social network that happens to use crypto rails. You can respect the pragmatism of that decision (Romero and his team were responding to real data about what users actually wanted) and still mourn the original vision.

A working hypothesis

I cared about Farcaster for the community that decentralization attracted. But decentralization is a means, and means are only as good as the ends they serve. The protocol is the plumbing, and plumbing matters, but nobody moves into a house because the pipes are well-laid.

What Farcaster offered, at its best, was a social environment shaped by a belief in decentralization, a community that self-selected for people who cared about how their tools were built and who controlled them. The protocol was an attractor for a certain kind of person, and that kind of person created a certain kind of conversation, and that conversation was the actual product, regardless of what the cap table said.

This is the distinction: decentralization as architecture and decentralization as culture. The architecture has shifted; the founders have moved on; the wallet pivot reoriented everything toward trading.

But the protocol remains open, and the Neynar team has been embedded in the Farcaster ecosystem from the beginning. They understand what they've inherited. Whether they'll preserve it is an open question, but it's not a foregone conclusion. The culture, the sensibility, the community of people who were drawn to Farcaster because they wanted something different from the engagement-optimized hellscapes of mainstream social media, that's harder to kill. It migrates and reconstitutes. It finds new vessels.

In the early twentieth century, the Vienna Circle, a group of philosophers, mathematicians, and scientists, gathered regularly at the University of Vienna to work out the foundations of logical positivism. They believed that meaningful statements had to be empirically verifiable, that metaphysics was nonsense, that philosophy should be brought into line with the methods of science. When the Nazis rose to power, the Circle scattered. Its members fled to the United States, the United Kingdom, New Zealand.

The institutional vessel broke, but the ideas traveled with the people who carried them.

Why I'm still posting

So this is where I've landed.

I'm still on Farcaster because the people there are still interesting. I'm still there because the conversations still have a quality I can't reliably find elsewhere. I'm still there because even in its acquired, pivoted, wallet-focused state, the residual community maintains a standard of discourse that I value. And I'm still there because, whatever the business metrics say, Dan and Varun succeeded at something that doesn't show up on a revenue chart: they attracted and concentrated a community of thoughtful, building-oriented people who care about the internet they're constructing. That's worth more than product-market fit, even if you can't put it on a pitch deck.

I've grown deeply suspicious of the impulse to leave. Every few months, a new wave of platform migration sweeps through the internet, people fleeing X for Bluesky, fleeing Bluesky for Threads, fleeing Threads for Mastodon, fleeing whatever is currently on fire for whatever is currently promising not to be on fire. And these migrations are almost always driven by the same fantasy: that a new platform will fix the problem. The problem is the set of incentives that govern all platforms, the economic logic that turns every online space into either an engagement farm or a ghost town, and changing platforms without changing those incentives is like rearranging deck chairs on the Titanic, except the Titanic is the entire attention economy and the iceberg is the incompatability between advertising revenue and human flourishing.

What does it actually mean to give a shit about a platform in 2026? I think it means loyalty to the conversations you're having and the people you're having them with. The platform is scaffolding. Scaffolding gets removed when the building is done or abandoned, or when someone decides the scaffolding itself is the product and starts charging rent for standing on it.

And if those conversations and those people happen to be on Farcaster right now, then that's where I'll be, until they're somewhere else, at which point I'll be somewhere else.

This is a less inspiring position than "I believe in the decentralized web."

But at least it's honest.

Neynar might surprise us. Crypto might stop sucking. Farcaster may yet become something none of us predicted, something that Dan and Varun's original infrastructure enables even if it looks nothing like what they originally imagined.

The best thing about open protocols is, after all, that they can outlive the intentions of their creators.

I've stopped waiting for a single platform to replace Twitter. The dream I've settled on is smaller: pockets of genuine discourse, distributed across protocols and platforms and group chats and mailing lists, connected by people rather than by algorithms, sustained by care rather than by capital. That dream doesn't need a billion-dollar valuation. It doesn't need much in the way of product-market fit. It barely requires a protocol.

It does require, though, that at least a few people keep posting.

Weekend Happenings - Cool As Heck

2026-02-23T13:19:31.000Z

Friday night, my wife had book club here. Only a few of the ladies were able to make it. They brought their kids, most of whom are the same age as our youngest, 13, so they had a good time taking silly selfies and playing the Switch.

One of our twin daughters (18) was here and hung out with me which was a lot of fun. It's nice to know that our kids actually want to hang out with us. I guess we're not that lame after all. 😝

Saturday I spent most of the day with just me, myself, and I. The wife and kids had places to be and things to do. I got caught up on some personal chores and watched Pluribus. I only have a couple of episodes left. That is a fantastic show.

Sunday was spent walking around the mall at Tyson's Corner Center. I say walking around because not much shopping was actually done. The girls did end up buying a few things here and there but everything is so expensive and we've raised kids who are very price conscious. Mostly we just enjoyed spending time together and eating at the conveyor belt sushi place in the mall. 🍣

Back to the grind today. Looks like it's going to be a busy week. I'm sad the Olympics are over. It's been giving me so much joy. I'm really happy for all of our athletes for not only going over there and giving their best performances, but also for truthfully speaking their minds when asked about the current political situation in the States. Maybe the future is still worth saving.

Brainstorming search engine ranking introspection - James' Coffee Blog

2026-02-23T12:57:26.000Z

Search is one of my favourite disciplines in computing. In 2024 I spent a lot of time working on a NoSQL engine that I called JameSQL. This tool now powers the search engine on my website.

Designing search engine ranking systems is tricky to say the least. When I use my blog search engine, I sometimes notice that the article for which I am looking does not show up at the top of the search results. Google set a high standard for search; when I type something in Google in a site search, I can often find what I am looking for.

I am not yet ready to delve back into the world of search, but I did want to take a note of an idea I had today: I want my next search project to have tooling for ranking introspection. By this I mean I want to have tools that let me know why a particular article ranks above another.

At present, JameSQL only returns a single attribute, _score, which is computed using either TF-IDF or BM25, with any additional boosts you have specified (i.e. give h1s 3x more weight). I imagine having a value like _score_answer that would tell me how much weight each attribute used in ranking had, for example:

[
  {"bm25_on_post": 100.01},
  {"score_after_h1_boost": 101.01},
  {"score_after_inlinks_added": 109.01},
  ...
]

This would be an ordered list that specifies what calculation has been made, followed by the score at that point in time. This could then be used to calculate how many points each ranking factor added onto the final score. This can be done by calculating the difference between scores after each weight is applied.

This information would help me answer the question “why is this post ranking in this place for this query?” much more effectively than right now, by letting me see exactly how each calculation and ranking factor affects the final search engine ranking.

I started building a tool that lets me interactively experiment with different algorithms (see image of the dashboard) which was useful. I think I would like to revisit that dashboard to make it more useful if/when I work on a search project in the future.

Outside of the scope of this particular, developer-focused context, I generally want to use software that gives me a clear idea as to why I am seeing what I am seeing. As a user, I shouldn’t be left thinking “why did this show up?” With many opaque recommendation systems used on the web today, I am often left feeling exactly like that: “why did this show up?” This makes it a lot harder for me to understand, and therefore trust, a system.