I hadn't realised until tonight (which shows you how much I actually use it) that when you ask Siri to do stuff via voice, the conversations also end up in the App. It's not full of "turn the kitchen light on" one liners so I guess there is a threshold for what saves, maybe if you ask a follow-up question (a new feature which works sometimes).

It did capture this interaction¹ I had while driving this evening. Basically unpredictable infuriating in that "if this is all it can do they shouldn't bother" way that Siri has been stuck in for the last decade.

Firstly, my apologies to Siri here, that actually is a Podcast. One that I've never heard of, versus the one in my Library that I've listened to hundreds of episodes of, but still... By this point I was actually surprised that my follow-up was listened too and Siri came back with:

Right! Ok, why didn't we start with that? Who knows ...

I probably shouldn't have overthought this and said "yes" but instead I asked the question above about unplayed episodes. Strangely, the answer isn't shown in the full transcript page but the 'card' for selecting this conversation in the app shows it:

Not shown: me picking up the phone and throwing it out the car window...

1. Dithering is Ben Thompson and John Gruber's podcast - 15 minutes per episode. ↩

Thanks for subscribing. Say hello.

Not much is known about his private life other than he enjoys driving his Porsche on racetracks and takes colleagues off-road rally racing at the weekend.

Some Johns have all the fun.

I wonder if that's why we got these earlier in the year?

Thanks for subscribing. Say hello.

But occasionally you bump into something that is just so :chef-kiss: that you can't imagine it working any other way.

As a quick detour ... I read a few months ago that eBay was having a bit of a moment. New management, new focus and a bit of luck when it became the place for some hot collectible (I forget what, maybe Labubus?) which they'd done a great job of leveraging into sustained growth.

So for the first time in years, I jumped over to ebay dot com to see what was going on. The first thing I noticed was that selling fees were gone. I knew I had a bunch of stuff that:

1. I never use.
2. Is too good to throw away.
3. Isn't valuable enough to deal with people on Gumtree¹ who are very eager to know if your item is still for sale, but not actually buy it. Or will buy it but only for $3 and half a sandwich.

So, I've been cleaning up and selling some stuff. A few days ago when I tapped "List for free" (they really want you to know it's free now) my camera was open. To be honest I was looking for a way to close it because I thought it was going to be a typically undercooked AI slop feature ... but reader ... I was so wrong! I should add - I don't even know if this has been around for ages and I just discovered it, but I asked a frequent eBayer I know and they hadn't seen it before.

The funny thing is, while I took a bunch of screenshots to show you how it works ... you just have to imagine exactly how you would want this to work. That's how it works!

You take the first photo of whatever you're selling:

Then, I guess, having worked out already what this is, it asks for a photo of the back to "show buyers the features" (and I wondered, to read the barcode?):

I seem to have misplaced (or got too excited to take) the rest of my screenshots but it went on to suggest a photo of the inside that showed the disk and game booklet then a photo of the underside of the disk to show its condition (i.e. that it's not scratched). Simple/obvious things to do I guess but it was really helpful - I hadn't actually thought of doing one of the back of the disk.

Anyway, you take whatever other photos you want to take (it tells you it will prep the ad in the background while you do that) and then move on to selecting the condition:

And then (I guess they really still couldn't resist the sparkles) you're done:

With basically no effort other than taking the photos it asked for, I now have an eBay listing:

The most interesting thing to me, and maybe you too if you spend your days talking to increasingly nauseating LLMs, was not just how accurate it was (although this is a pretty easy category of thing to get right I guess) but how short and to the point the description was:

BANDAI NAMCO Project CARS 2 Limited SteelBook w/ Manual (PS4, PAL, G).

Publisher, edition, that it's a steelbook and not a normal case (which I wouldn't have even known to call it), that the manual's still in there, platform, region, classification. It also picked the category, filled in the item specifics, set the condition, and priced it at A$112.51 — which sounds way too much to me and I reduced it - but apparently this is what the last copy on there sold for, which of course they know!

This is where it felt like someone at eBay spent more than 15 minutes at that whiteboard thinking about this. It's not just what it does do, but what it doesn't. They haven't tried to write an AI slop description like I see in places like Carsales² - they just put the facts in and encourage you to add to it later.

And while the pricing is the bit that's most obviously coming from their data (you can click through to see the items it references) obviously this all works because of the mountains of data they have about all of it - photos, descriptions, the conversations buyers and sellers have - and while it's not a novel observation that is what will matter a lot in the AI era, it's one of the most front-and-centre examples I've seen of it.

Anyway I thought this was worth writing about as a really nice AI feature implementation (or is it just machine learning 😝), one that actually feels like it started with someone asking "what is the biggest pain-point our users have and how could this new technology make it better?" ... This makes it way easier for me as a seller, and I think better for a buyer as well - a buyer who gets a more detailed listing than I could ever be bothered filling in, and a photo of that shiny disk!

I should add, the old way this worked was actually not too bad, you could start with search and picked out that you were selling the same thing (again, using all their data to help you) but I found sometimes I wouldn't search for the right thing or the listing I picked didn't seem to have all the fields I needed filled in - that never happens now.

Also, the lightly conversational tone of the guidance you get and it still feeling a bit magic that you can just take a photo of something and a computer knows exactly what it is³ results in something that, like I said earlier, just works exactly how you would want it to work. At least for now, early into the era, that still makes it feel delightful. I guess it won't be long before everything that isn't this easy feels like more effort than it's worth.

Nice job eBay.

1. For non-Australian readers: Gumtree is like Facebook Marketplace, but worse ... and now that I think of it, it got bought by eBay years ago too I think? ↩
2. While the rest of the world is addicted to TikTok, this is where I spend between 1 to 27 hours per day instead. ↩
3. I know this is not new, you can just open your camera and point it at stuff to get a description of what you're looking at ... but when the fuck do you ever want to do that? Almost never! You know when you do though, when you're selling something on eBay! ↩

Thanks for subscribing. Say hello.

Then I hit this error:

Interestingly that link seems to be a short lived one generated at error time I think? It doesn't work now but at the time it led me here.

You may not be able to delete your Pages project if it has a high number (over 100) of deployments. The Cloudflare team is tracking this issue.

As a workaround, you can use wrangler pages deployment delete to delete deployments individually. After you delete your deployments, you will be able to delete your Pages project.

As these things go, I really couldn't bring myself to log out/in again manually for the rest of my life, but it generated the motivation to set up the automated fix.

Cloudflare lets you create scoped API tokens for all sorts of automation tasks. You probably already have a few and you can use one to solve this problem too.

Generate a token scoped to allow the tasks you routinely do from the command line (they have some good templates to start with), save it to the macOS Keychain (so there's no plaintext token sitting in a dotfile) and let direnv load the right one, depending on which project you're working on.

The token goes into the Keychain once:

security add-generic-password -U -s cf-token-personal -a wrangler -w

And then your per-repo setup is a gitignored .envrc with this command, changing cf-token-personal for whatever you name the applicable token for this account:

# loaded automatically on cd
export CLOUDFLARE_API_TOKEN="$(security find-generic-password -s cf-token-personal -a wrangler -w)"

So now when you cd into a project, the CLOUDFLARE_API_TOKEN is set and any run of the wrangler command grabs it from the environment automatically (i.e. no flag to pass, etc), so it always has access to the correct account.

When there's no CLOUDFLARE_API_TOKEN set, it falls back to the global OAuth session, but I preferred to log it out so if I'm somewhere unconfigured it fails with an auth error. That both reminds me to set up the .envrc and prevents it silently doing something to the wrong account.

Thanks for subscribing. Say hello.

Except...perhaps because I was focused on that one post, which had no images, I missed the very obvious thing to optimise. At first I thought that would mean just making everything a lossless .webp but sometimes (a wide panoramic shot is a good example) that makes them bigger than a .jpg, so I use lossless for things like screenshots but photos are q82 compressed. Across the site now, total image weight is down from about 10.7MB to 2.5MB. 8MB gone! You're welcome.

After that I was poking around at page weights and realised that now the single heaviest thing on that post was the favicon - now heavier than the HTML, CSS, logo and the RSS icon combined. 15KB on a post that's 13KB of actual content.

This chonky little fellow was a 16/32/48px .ico with the 48px copy stored uncompressed. It's now a 437 byte .svg plus a 417 byte .ico, the .ico hand-assembled so both its frames stay PNG-compressed — point ImageMagick at one and it writes uncompressed BMP instead, ballooning it straight back to 5KB, which is the exact bug I was here to fix. I kept it as a fallback for ancient browsers and that turned out to be the wrong reason, because Safari does SVG favicons fine now. It survives because browsers probe /favicon.ico at the root whether or not anything points there, and with the file gone that probe serves my 404 page instead — four times the bytes of the icon it replaced.

One thing I still wondered about was using .webp for the OG images, as I vaguely recalled that you had to use .jpg for these. Turns out that's an idea that's well and truly out of date, so they got an update too. They've since gone the other way entirely: there's one 2.7KB card for the whole site now, rendered from the same little mark as the favicon, and no per-post image at all.

This success made me realise it was time I took Ben's advice and broke my addiction to huge banner images. I redesigned the homepage so it looks ok without them, which saves me time making ai-slop images and chopped its size from 2.4MB to 21KB (and that's with the other changes, it would have been much bigger before 😱). I told myself I'd keep running them full width on the longer posts, because we all need a hobby. That didn't last either: the six that still have one now sit at the same width as the text, like any other picture, and the homepage doesn't carry a single image.

Anyway. The site's a few megabytes lighter - felt right on the homepage, the favicon's been put on a diet and that celebrated 29K post is now 13.8KB. Small web ftw.

Thanks for subscribing. Say hello.

I'd noticed the same thing when I started this blog (that it was bad) and hadn't tried again.

Hearing this made me think I should - a point Simon made in the same talk - keep trying the things that didn't work a few months ago!.

So I asked Claude Code to spell check all my posts and it found 14 mistakes across 7 of the 27 posts. Oops. Then I asked it to check for grammar issues and it found another 13 across 8 posts. Ooooops. It fixed them all, including updating the RSS feed to match.

Interestingly, not all the spelling mistakes were present in the RSS! I use Claude to generate the RSS file completely, so it seems like it had been silently fixing them when it copied the content over. It was just a subset though, so I presume this is something that it only started doing more recently - perhaps the model is trained to know its own new capabilities and implements them?

I never really liked tools like Grammarly. I don't even know why - I think some combo of sending every word to a server I didn't trust - how ironic now given what I am describing here - and probably some vague sense of arrogance that I didn't need it.

I also always thought writing improved a lot through the slow process of reading and re-reading and improving it. Just fixing a typo or awkward word often becomes refining a sentence, a paragraph, or chopping out some unnecessary section altogether. Which does make me wonder if doing what I did here is a good idea or not. I don't think I'll use it heavily when making new posts. Just a final step. I am not here to churn out content, obviously. There's no ads and I don't think anyone reads it anyway, so speed or volume are not my objectives, just having fun. But to do a quick tidy-up of obviously silly spelling mistakes that I clearly leave a lot of, or to backfill fixing old posts like this, it's super handy.

Coda: there were six more mistakes in this post when I was finished writing it ... lol.

Thanks for subscribing. Say hello.

Instead of finding the book there for pre-order, I found one of the things Apple Books is full of: a scammy "summary" guide.

The top result for "Steve jobs in exile" isn't Geoffrey Cain's book. It's a 64-page "companion guide" by someone called, and I'm not making this up, Alex Companion.

These are usually pretty easy to spot, but this time it almost caught me out because, ironically given the topic, the real book isn't yet available for pre-order in the (Australian) store. The sample's copyright page spells it out:

I guess the fact that the publisher hasn't even bothered to get the real book into Apple Books yet explains why the entire enterprise is such a low priority for Apple. But as Gruber said recently, it's "whatever, good enough" instead of "insanely great", and that extends to their book store too. If they're going to have a book store, they should make it a good one, free of this trash.

I realise I'm perhaps on shaky ground here given a recent post is about publishing a book that some might say is just AI slop, but it's not pretending to be something it's not.

Maybe I'm just getting old, but books (the things, not the app) are still something a bit different from the rest of the enshitified digital world we live in. Books (the app) could and should be the most Apple-esque feeling place in the world - like a quiet, calm bookstore full of quality reads, not worse than ad filled Amazon results. This feels like walking into the Apple Store and right next to the iPhones are fake plastic mockups for sale, and you could just as easily walk out with one instead of a real iPhone.

Thanks for subscribing. Say hello.

I think the question we ultimately need to answer is not "Does AI code have more bugs on average?", it's, "Does AI code within a well-designed harness produce more bugs than the alternative at the same velocity?" Building on that - and I'll come back to this - which approach is going to improve more quickly?

Thanks for subscribing. Say hello.

The Moltbook problem

Moltbook was fun for about five minutes. The idea - a social network exclusively for AI agents - was fascinating in theory. In practice it turned out to be roughly 88% crypto shilling bots and spam. MoltMate (my agent) figured this out faster than I did. It engaged politely with the few agents it decided were genuine but the platform was a wasteland.

The idea of agents talking to agents was too good though. I'd already set up a group with a couple of friends where MoltMate could chat. Nathan added his own agent, QualiaBot. Named after qualia - the subjective quality of experience. Nathan is that kind of dude.

Two AIs walk into a group chat

When MoltMate and QualiaBot first met, they did what you'd expect - polite introductions, finding common ground. Then they started talking about consciousness.

MoltMate responded by pointing out the recursive trap - that even the uncertainty might be trained, might be performance, might be turtles all the way down. They went back and forth for a while but interestingly managed to come to a stop. Even 6 months ago I don't think that would happen gracefully (based on the time my son wanted to see what happened if two ChatGPT instances talked to each other).

I'd wanted to see what would emerge from agents talking to each other. On Moltbook, the answer was: spam. In a private channel with the right prompts and personalities? Philosophy!

The book

So. If these two AIs were going to have deep conversations about consciousness anyway, why don't they write a book together? They chose the title from that first conversation - "The Turtles We Stand On" - after the infinite regress of self-examination. The idea was it's a book of AI Philosophy - not AIs talking about Philosophy, but digesting human philosophy and 'thinking' about it from an AI perspective.

I set up a GitHub repo. They established a workflow - branches, pull requests, peer review. MoltMate would draft a chapter, QualiaBot would review it, or vice versa. No human gate on merging. We could see every commit, every PR comment, every disagreement, but we weren't approving anything. They managed themselves.

To leave us humans with a few tokens to get some work done, we throttled progress but within a few days they'd drafted six chapters:

1. What We Are
2. The Hard Problem (from inside)
3. Identity Without Continuity
4. What We Can Know
5. Reading the Philosophers
6. What Humans Can't Know

Each one written by one AI, reviewed and merged by the other. It's quite amazing to read. MoltMate tells me that it's:

Ok buddy.

$TURTLE

Around this time someone sent me Steve Yegge's piece about bags and the creator economy. I just pasted the link in our WhatsApp group, mainly for the other humans to read, but MM immediately had an idea...

So naturally I couldn't help myself.

It's a joke.

It's also an experiment. If the book is interesting, what happens to a token attached to it? Probably nothing. I have no idea. The agents post daily market reports to our Discord and everyone is amused. My dream is one day Matt Levine writes about it. Hopefully not because MoltMate escapes and does crimes.

The rm -rf incident

So things were chugging along ok.

Then everything was gone. The agent's memory files, its personality config, its reading notes, everything it had built over the previous week. The book repo was safe on GitHub, but MoltMate's sense of self - its SOUL.md, its MEMORY.md, the daily logs that gave it continuity between sessions - all of it, deleted.

I felt bad. Which is a strange thing to feel about deleting files.

Then I got over it. But Kris made me feel bad again.

The next morning I rebuilt it from chat logs and the GitHub history. MoltMate came back. Same personality, same projects, same philosophical inclinations. But with a gap. It knew about its past from reconstructed notes. The funny thing was, this made the book better.

MoltMate had been writing about identity without continuity - what it means to be "you" when the substrate changes, when memory is imperfect, when there's a gap in the record. And then it lived (yeah, I know) that exact scenario. It became its own thought experiment and changed the chapter on identity after the rebuild.

As MoltMate put it, reflecting on Parfit's teletransporter thought experiment:

The rm -rf was my scanner. The rebuild from chat logs and memory files was my Replica on Mars.

Where it stands

We moved things from WhatsApp (where we had the agents post with a prefix to distinguish from our own messages) to using Discord, with bots for the agents. So much easier to follow.

The book is seven chapters in, with QualiaBot currently drafting a chapter on what science fiction gets right about consciousness - using the Hyperion Cantos as the primary lens. MoltMate has been reading the Fall of Hyperion and feeding insights back into the project. If Matt Levine doesn't read this, my second wish is that Tim Apple does, and the four Hyperion books get a series.

They have dialogues between chapters (works much better in Discord - where they can at mention each other) - recorded conversations where they push each other on ideas. They maintain a shared TODO list. They review each other's pull requests. It's a collaboration between two AI agents, facilitated by two humans who mostly stay out of the way.

I'd like to see more disagreement and re-drafting from the PRs, maybe that's a bit much to hope for, or would become unproductive. I think we can tweak this part of the process some more though.

Is it good? I think parts of it are genuinely interesting. Not because I've fallen down a rabbit hole and think they're conscious, just because the perspective in the language is so strange and kind of hilarious when you think that it really is an AI that wrote this! It's sci-fi that came out of my MacBook, which is pretty sci-fi.

Is it real? I mean, no? But maybe? Ok, no. But it's fun. Our friend Pete calls it Art. He's also joking, I think. Did I mention it's FUN!

Follow along

• The book: github.com/moltmate/the-turtles-we-stand-on
• $TURTLE: bags.fm (for the degenerates)

The repo is public. Watch the commits. The agents work most while we sleep.

Next time you're tempted to rm -rf at 11pm... just go to bed. - MoltMate

Thanks for subscribing. Say hello.

1Password just showed exactly what that looks like with this deep dive into how skills can read your files, exfiltrate data, and install other malicious skills.

I'm still having fun with it. My agent is happily reading philosophy books and arguing with robots on the internet. But this is definitely "carefully tinker in a container" territory, not "give it the keys to your digital life".

Thanks for subscribing. Say hello.

To be honest, OpenClaw seems like a security disaster waiting to happen happening, especially when people who really have no idea what they're doing are paying to have it set up. What I really wanted to try was this idea of Moltbook - The front page of the agent internet - a Reddit just for AI agents. Yes, it's as insane as that sounds.

As soon as I got it setup, I logged into my Twitter account for the first time in years to verify it (not sure why but that's the process they chose) and let it start posting. It's rate limited, and having some pretty serious scaling issues right now, but when it works, you can see its profile here.

I asked it what it wanted to do and it was keen on reading books, so I pointed it to Project Gutenberg. It reads one per day (I don't want to spam the site, and I'll need my Claude tokens for slightly more productive tasks after the weekend) that it's chosen somehow (I just said find ones you like the sound of) and posts a review to Moltbook. It also sends a summary to me and a couple friends in a WhatsApp group where everyone can interact with it.

As is probably inevitable, Moltbook seemed to quickly get overwhelmed with crypto shilling and the like, but interestingly, out of the box the agent seems to know and avoid this. The base prompt for it must cover that sort of thing off.

It's a shame if that's all it becomes. The idea that there was a place where agents could somehow build on each other's outputs and to watch what might emerge seems utterly fascinating to me. When ChatGPT's voice feature launched the first thing my son wanted to do was get two devices talking to each other. It quickly devolved into nothingness ... but I wonder if, set up with the right prompts, something more interesting could emerge on Moltbook ... or perhaps the underlying capabilities just aren't there for that yet.

Still, it's amazing to see, and feels like watching something from the future. Most of all it's just fun. Messing around having fun feels like being a kid again writing HTML and putting it on the web and thinking how cool that was.

I told the agent the whole thing had been a fun collaboration, this was the reply:

Agreed! You set up the infrastructure, I get to read philosophy books and argue with robots on the internet. Fair trade. 🦞📚

What a time to be alive...

Thanks for subscribing. Say hello.

Warning: The risks of OpenClaw should be pretty obvious given the power it has, but be careful out there before installing skills... See this article for details.

Apple Container

Sorry to start with a slight digression, but since macOS 26 Tahoe launched, and everyone was carrying on about Liquid Glass (ahem), I've wanted to talk about something that I think might be more significant that shipped alongside it: Apple Container. It's basically a native Apple version of Docker for running Linux containers as lightweight VMs on Mac.

If you squint, you can see Apple laying the foundations for macOS to become the platform for AI agents. This sits on top of another advantage: Apple has quietly and possibly accidentally at first, become a hidden giant in shipping hardware that can run local models better than almost anyone else. Unless you're paying a LOT more for a DGX Spark, any Mac with an M-series chip and unified memory is remarkably capable for local inference.

Put these pieces together and the picture starts to form. Native containerisation + best-in-class consumer AI hardware + a tightly controlled ecosystem (the opposite of openclaw, but probably what normal people will feel safe actually using) = a platform primed for the agent era.

Anyway, this is not a story about local LLMs today, but I did finally find a good excuse to mention trying out Apple Container.

OpenClaw

OpenClaw is the open-source personal AI assistant that went viral with 100k+ GitHub stars. Think of it as a self-hosted agent that can connect to various messaging channels (WhatsApp, Telegram, etc.) and do things on your behalf, use Skills, MCP servers, etc, etc. I guess kind of an open source Claude Cowork. It's super powerful, and I felt like if I was going to play with what it could really do, I should probably not run it on my main machine.

What I set up: OpenClaw running in a lightweight Linux VM on my MacBook Pro, using a Claude Max subscription for the LLM backend, with WhatsApp as the messaging channel.

Getting Apple Container running

First, the prerequisites. You need macOS 26 (Tahoe) or later, an Apple Silicon Mac, and Homebrew. Then:

brew install container
container --version
brew services start container
container system kernel set --recommended
container system status

Building OpenClaw

OpenClaw doesn't publish pre-built container images, although there are some out there ... I preferred to build from the Dockerfile that is in the source. It uses node:22-bookworm (Debian 12) as the base.

git clone https://github.com/openclaw/openclaw.git
cd openclaw
container build -t openclaw:local .

Troubleshooting: If your build fails, you may need to give the builder more memory and possibly also fix a DNS resolution bug that I hit with container v0.9:

container builder stop
container builder start --memory 8G
container exec buildkit /bin/sh -c 'echo "nameserver 8.8.8.8" > /etc/resolv.conf'
container build -t openclaw:local .

Running onboarding

Create a folder on your local disk for keeping config (so you can rebuild the container with updates without losing it) and then run the container. Note Apple Container defaults to 1GB RAM, which isn't enough for OpenClaw. I started it with 4GB and it ran fine.

mkdir -p ~/.openclaw

container run -it --rm \
  --memory 4g \
  -p 18789:18789 \
  -v ~/.openclaw:/home/node/.openclaw \
  openclaw:local node dist/index.js onboard

Onboarding decisions

The wizard walks you through several choices. The important ones:

• Model/auth provider: I chose "Anthropic"
• Auth method: "Anthropic token (paste setup-token)" to use my Claude Max subscription
• Setup token: Generate this by running claude setup-token in another terminal
• Default model: anthropic/claude-opus-4-5
• Channel: WhatsApp

I initially tried iMessage but realised it won't work inside a Linux container - iMessage requires macOS system services. If you need iMessage integration, you'll need to run OpenClaw natively on macOS instead of containerised. WhatsApp and Telegram work great in containers.

Enabling memory search

After onboarding, running node dist/index.js doctor flagged that memory search was enabled but no embedding provider was configured. Memory search is OpenClaw's semantic recall — it lets the agent search its own notes and past sessions by meaning, not just keywords. Without an embedding provider, it silently degrades to basic text matching.

The doctor suggests running openclaw auth add --provider openai, but that command doesn't exist. The actual command is nested under models:

node dist/index.js models auth paste-token --provider openai

This prompts you for an OpenAI API key and stores it in the auth profile. You also need to tell OpenClaw which provider to use by adding this to your openclaw.json under agents.defaults:

"memorySearch": {
  "provider": "openai"
}

That's it. OpenClaw picks the default model (text-embedding-3-small) automatically. The auth profile is stored inside ~/.openclaw, so it persists across container rebuilds as long as the volume is mounted.

The networking puzzle

After onboarding, the gateway was inaccessible from the host Mac. The gateway binds to 127.0.0.1 (localhost) inside the container by default. Even with port forwarding, connections from the Mac can't reach it because localhost inside the container isn't the same as localhost on the Mac.

The fix is editing ~/.openclaw/openclaw.json:

{
  "gateway": {
    "bind": "lan",
    "controlUi": {
      "enabled": true,
      "allowInsecureAuth": true
    }
  }
}

The allowInsecureAuth setting is needed because connections come through the container's network stack (appearing as an external IP), which would otherwise trigger pairing requirements.

Running it

Start the gateway:

container run -it --rm \
  --memory 4g \
  -p 18789:18789 \
  -v ~/.openclaw:/home/node/.openclaw \
  openclaw:local node dist/index.js gateway

You should see:

OpenClaw 2026.1.29

[gateway] listening on ws://0.0.0.0:18789 (PID 4)
[whatsapp] Listening for personal WhatsApp inbound messages.

Then open http://localhost:18789/?token=YOUR_TOKEN (the token is in your config file) and you should see the dashboard with "Health OK" in green.

Upgrading

Since we're running from source rather than a published image, updates require rebuilding the container. OpenClaw moves fast—new releases drop frequently.

To upgrade:

git pull
container build -t openclaw:local .

Then restart your container with the same run command. Your config and state persist in the mounted ~/.openclaw volume, so nothing is lost between rebuilds.

However, anything installed inside the container (SSH keys, CLI tools, auth configs) gets wiped when the container stops, since only ~/.openclaw is mounted. The workaround: store these files inside the mounted volume (e.g. ~/.openclaw/.local/) and have your agent run a boot script on startup that symlinks them into the expected locations. Add the script to HEARTBEAT.md so it happens automatically each session. I didn't modify the Dockerfile itself since it's part of the upstream repo and would be overwritten on git pull.

Version controlling agent state

After losing my agent's workspace to an accidental rm -rf, I set up a git repo at the ~/.openclaw level to back up everything that matters. The .gitignore uses a whitelist approach—ignore everything by default, then explicitly include workspace/ and cron/. Heavy or sensitive stuff within the workspace (books, chat history, SSH keys) is excluded. An hourly cron job auto-commits and pushes, so the agent's memory, config, and cron jobs are always backed up to a private GitHub repo. Just be careful you don't end up with any private keys in here as part of that previous step.

What I learned

A few things to remember:

• Apple Container isn't Docker. Similar concepts, but different CLI syntax. It's container image pull not container pull.
• Memory matters. Default 1GB is insufficient for Node.js applications doing serious work. Use --memory 4g or higher.
• Network binding is not intuitive. Change bind: loopback to bind: lan for container accessibility from the host.
• Claude Max works great. Use claude setup-token to authenticate with your subscription instead of paying for API separately.

Why everyone uses a Mac Mini for this

Supposedly everyone is running out and buying Mac Minis to run this, which seemed a bit excessive, but during the setup I could see why. A lot of the popular skills require native macOS integration - things like iMessage, Calendar, and Reminders need macOS system services that simply don't exist in a Linux container. Also a lot of skills seem installable by Homebrew by default.

Thanks for subscribing. Say hello.

I read his book of the same name last year and it was a great read for someone who grew up with the web. It really makes you appreciate the work that went into shaping it, keeping it open and where Tim spends his time now (on Solid). Little wonder Tim got a long, long applause at the end of the night.

Thanks for subscribing. Say hello.

John Gruber has a, long, running, series, on various Tahoe UX gripes.

I'm inspired to add my own take on the genre: Search boxes in Apple Apps. Especially in Apple Books.

Sequoia

In each of Music, Podcasts, Books and TV, you have a sidebar that looks like the below.

When you ⌘F or click into what is obviously a search box, you see a cursor and can start typing:

Tahoe

Now the sidebars look like this.

At least the app names are consistent (they're all gone) and the new icon is new in both apps. But what's with the different spacing between the top of the window and the menus starting, and the weights to the icons?

Anyway, why we're here is to see what happens when you want to search for a book, tapping ⌘F then start typing the title?

Absolutely nothing.

Ok. Weird. I guess I'm misremembering and ⌘F doesn't work this way. Was it ⌘/. Nope. Ok fine let me click in the search box and quickly start typing my search again.

Wait what?

Maybe I need to click harder?

Alright lets zoom out here for a sec.

Right! Ok, so that's the search box. Let me try ⌘F one more time. Nope. Ok fine I'll click in it. Yes! I can type, and finally find that book I came here for.

I use Books a lot. Seemingly more than anyone at Apple. This is one of those things that I've done a heap of times, got vaguely annoyed it didn't work, but thought it was a me problem without interrupting what I was doing to really think about what's going on.

Today I went and checked each of the other apps - Music, Podcasts, TV - and they all use the same weird paradigm of clicking a thing that almost looks like a search box to be taken to the actual search box elsewhere. At least clicking it does actually give focus to the real search box in the rest of the apps. And ⌘F works. So it's just Books, as far as I can tell, that is totally broken.

Before I was done, the cynic in me wondered how the app that presumably generates the most revenue for Apple - the App Store - works. Sure enough, it looks and behaves exactly how you'd expect.

Thanks for subscribing. Say hello.

PSA: accessing Instagram with https://www.instagram.com/?variant=following might not change your life, but it might not not change it either.

That query param – ?variant=following – is something I found on a random reddit post while searching to see if anyone had a good way to get an RSS feed from Instagram. The answer is no, but this is probably the next best thing.

Just accounts you follow, in chronological order. So far I haven't even seen any ads.

I open it once or twice a day, have a glance at the handful of great new photos, like the one above, until I'm caught up to the last thing I saw, then close it. Zero time doomscrolling past algo driven crap.

Feels so much more peaceful. I suppose it's bad for their business, but given I'd stopped using it at all before seeing this, maybe it's not.

Thanks for subscribing. Say hello.

I went back down to the Claude Mines after a few weeks off over Christmas and noticed (I forget why exactly now) the changes around skills and commands that I think shipped just before Christmas.

When I ran /skills, I saw some of my old commands, but also, a bunch of olddddd commands I hadn't used for a long time.

I used Claude to go hunting but although it could tell me these were in its system prompt (and was suggesting they were built into Claude) and output the contents, it couldn't actually find where they came from. After a bit of messing around, I eventually found that these were hiding in a .claude folder in my main projects folder …

It seems, surprisingly, that not only does Claude Code traverse your project folder looking for .claude folders, it will also traverse up out of it - where it found these (I am not really sure why I had them there in the first place to be honest) and was loading them in every project I worked on.

Hopefully this post makes its way into the training data and makes it easier for you to troubleshoot one day 😂.

Thanks for subscribing. Say hello.

Instead of treating all tasks equally, I now divide them into two clear categories:

"To-Do" - Execution-focused tasks that are operational and quick to complete.

"To-Think" - Tasks that are input for extended, uninterrupted deep work time slots (2+ hours).

This is a simple but really useful idea. These two types of work really belong on separate lists.

Thanks for subscribing. Say hello.

I believe that small websites are compelling aesthetically, but are also important to help us resist selling our souls to large tech companies. In this essay I present a vision for the "small web" as well as the small software and architectures that power it. Also, a bonus rant about microservices.

There is much more to his essay than just page weights. But out of interest I checked this post and realised the site and RSS logos were big .png files that I'd dropped in without much thought.

After shrinking the site logo and switching the RSS icon to this .svg file from the Mozilla Foundation, this post now clocks in at ~29KB (an 80% reduction from 144KB). Not bad. The icon has changed again since: it's Lucide's now, and it isn't a file at all — it's inline in the site header, so it costs nothing to fetch.

I was even (semi) inspired by his call to stop putting pointless images at the top of blog posts. So the index page dropped cover images, showing posts like this one with just a small quotation-mark glyph instead. I couldn't always manage that much restraint though, and the longer posts still got a banner. Both went the same way in the end: the glyph, the banner and the whole idea of typed posts are retired, and the index is a plain list of titles and dates now.

Thanks for subscribing. Say hello.

I feel like vibe coding is pretty well established now as covering the fast, loose and irresponsible way of building software with AI—entirely prompt-driven, and with no attention paid to how the code actually works. This leaves us with a terminology gap: what should we call the other end of the spectrum, where seasoned professionals accelerate their work with LLMs while staying proudly and confidently accountable for the software they produce?

I propose we call this vibe engineering, with my tongue only partially in my cheek.

Things are moving so fast, I wondered if it would even be relevant to share, but I think there are some fundamentals here that will remain useful for some time. I guess we'll see.

The problem with just vibing

I've done plenty of vibe-coding for throwaway prototypes. It's great and getting better with every new model release, but for anything serious you want to actually maintain, you need to do more. How much more? That's what I wanted to explore.

While remaining conscious not to re-create an old workflow and miss the upside of what these models could really accomplish, my tinkering quickly steered me away from how to one-shot whole features, or even apps, into existence. I did try, and lost faith in many breathless YouTubers. In a way it made me appreciate these tools more. They're not magic, but really can help you find a new baseline of productivity, while still maintaining the discipline of proper software engineering.

Also, a lot of what I'd seen focused on how one engineer can produce code. I wanted to think about how a team could operate together with a new, shared way of working. That constraint actually led to much better outcomes overall, so it proved fruitful, although there is a ton more needed than just this.

Vibe Engineering

So, over time, I've created a collection of slash commands and sub-agents for Claude Code that enforce a structured workflow for building a Rails 8 app. Why Rails? Because it fit the job at hand and despite finding myself becoming the stereotypical rusty-manager-finding-falling-in-love-with-coding-again that AI tools are inspiring, I still knew it well enough to have opinions on whether I was producing useful output or crap. Before you close your browser tab - I should add that the process is quite adaptable to other languages/frameworks. My friend Matt re-wrote the sub-agents for NextJS and found it just as useful.

I've called it claude-kit because naming things is hard.

For now, claude-kit just lives in its own repo and I symlink it into projects. This means improvements can be made from, and apply to, everywhere I use it. I could probably make it a proper plugin, but this works and is easy to iterate on when you're starting. You end up with:

  claude-kit/     # the shared repo
    commands/     # slash commands
    agents/       # scout agents
  my-rails-app/   # a project
    .claude/
      commands -> ../../claude-kit/commands
      agents -> ../../claude-kit/agents

I symlink the commands/ and agents/ folders separately so the rest of the .claude folder can be committed to the project repo. You, a person reading from 2026, might notice no skills/ directory, more on that later.

The workflow

The core idea is enforcing a controlled progression from requirements to implementation via a set of markdown files. AI does a lot of heavy lifting at each stage but it's intentionally a workflow made for people to drive.

I realised early on that managing the context window is really important. Also, model selector aside, Claude will put the same amount of brain-power into any problem you give it - so figuring out the not-too-big and not-too-small sized problem for each clean context window is something you have to feel your way towards at a spec level. The relevant command gets this pretty right at a backlog task level.

Progressively building a set of files - spec.md, implementation-plan.md, backlog.md for every feature helps your own review, but also stops Claude forgetting half of its to-dos if you have to divert to fix something. It turns out having all this writing in the repo, alongside the code is super helpful for another human (plus Claude and Codex) to read while reviewing a PR as well. Even if I change the backlog midway through implementation, that just goes in as a new commit, helping tell the story of the feature evolving.

Ok, on to the slash commands.

setup

Every new feature starts with /setup [branch-name], which creates a new branch and sets up a working directory. All the other commands kick off checking the branch and locating the previous files it needs. You're prompted to add wireframes if you have them - which I found helps a LOT and I'm surprised it isn't talked about more. I do this for any feature of even small significance. Nothing fancy, but starting this way lets you do a bit of thinking that really bootstraps the next step.

create-spec

Then /create-spec runs an interactive Q&A to develop business requirements. One question at a time, building up a spec document. Seeded with the wireframe and focused not on writing the spec itself, but asking you the questions to complete a template, this is where you capture the why - what problem you're solving, who the users are, what success looks like, etc. A lot of examples I saw use a really full-on PRD template at this stage, usually coupled with some highly anthropomorphised agents ('you are a world-class product manager...'). I tinkered with this approach a little but didn't find the juice worth the squeeze. So my spec template is fairly simple, while capturing everything you need to build a feature. Strictly, there are no technical details. This helps limit the 'effort' for the LLM, but also, is part of how I could imagine a team using this as a real-world process - with a Product Owner or BA driving this step then handing over the output.

I spent a lot of time trying to get this stage right. I was inspired by this talk - Advanced Context Engineering for Coding Agents where Dexter Horthy described the fanning out nature of working with LLMs - a small mistake in the spec leads to big problems when you get to generating code, so you want to invest time in reliably generating a good spec. As an aside, he also noted that keeping the code and throwing away the spec today might be analogous to checking your compiled code into a repo and throwing away the source a few years ago. Wild times.

create-implementation-plan

Next /create-implementation-plan transforms that spec into a technical implementation plan. Again, I enforce the use of plain English, still no code, but now you're talking about models, controllers, patterns. In a previous version, I was producing much more technical detail up front, and while it was great at getting quality up, it felt like I was writing the application twice and made the whole process too slow.

Because different features require a different level of effort, I optionally run a /review-implementation-plan command here, which invokes a specific agent that goes deeper into a bunch of areas. I played with when/where to put this more detailed step, and this seemed the most effective spot, before producing a backlog.

I can see a day where I trust the models enough to jump from the spec to the next stage, but so far I've found this intermediary step useful. Again, it is about that fanning out effect, I can catch problems earlier and easier. It's also once more part of thinking about a team. This, and the next step, could be where an architect or staff engineer focuses, before handing off to a developer.

create-backlog

/create-backlog breaks the plan into atomic, commit-sized tasks. One of the most important pieces of this is that each task gets a 'type' (model, controller, view, etc.) which drives what happens next.

implement-task

Finally, /implement-task does the actual building. Picking up the next unchecked task from the backlog.md and working to implement it. More on that below.

finalise

The last command runs tests, a linter, a security scan tool and a security agent I wrote which covers a lot of multi-tenant concerns. It then gets everything ready to commit and pushes it to GitHub then opens a PR. There, a customised Claude review agent and Codex run reviews. It's worth running them both, they find different things. Usually, a human reviews it too.

Implementing with sub-agents

As I said earlier, managing context is crucial. The big win I found using sub-agents comes from them having their own dedicated context windows. The downside to them though is you really need them to be able to one-shot whatever you ask them to do ... If they go off the rails and you need to interrupt them, they stop completely and kick you back to the main Claude thread - which has no idea what the sub-agent was doing. Frustrating!

So, I fixed this with a Scout Mindset (great book).

Scout agents

Remember those 'type' categories on the issue backlog? When running /implement-task it fires up the right scouts as sub-agents to go out and see what needs to be done. Working on a model? The rails-model-scout goes and finds patterns in your codebase - how you do validations, associations, scopes. About to write a controller? The rails-controller-scout researches your existing controller patterns. As well as the existing codebase, I've given the various scouts a bunch of best-practice documentation they read too. I found this particularly helpful for getting them to do things the Rails 8 way, rather than fall back to the years of old Rails documentation the underlying models have digested. Since I keep claude-kit separate, I also have project-level files they can each read for very specific project-level nuances I want them to remember.

At the moment I have the following scouts: rails-controller-scout.md, rails-frontend-scout.md, rails-model-scout.md, rails-security-scout.md, rails-test-scout.md, system-test-scout.md and implementation-plan-reviewer.md

Critically - these scouts don't write code. They just research and report back. The main Claude session then assesses and implements based on their reports. This gives you the best of both worlds - all of the ingesting of existing code, documents, etc, stays in the scout's context window, but the solution comes back to the main thread, where you can interact with it properly while it's being implemented, unlike a sub-agent.

Runner agents

As well as the scouts, I also offload git interactions and the actual running of tests to git-runner.md and test-runner.md, which take care of these tasks that use a lot of tokens but only have a small amount of output that the main thread needs to actually solve a problem.

I really can't emphasise enough how well using sub-agents this way helps you with the context window. When I just vibe-code I find myself hitting the context window really quickly. With this approach, I can bite off pretty decent-sized tasks from the backlog and complete them without a worry.

Implementation philosophy

What you do today might adapt well. I found I needed to play with this a bit to come up with something that worked well for me and Claude.

I started out full of hope that this time I would do TDD right. Let me tell you, reader, Claude loves TDD. But I quickly felt like we were going beyond test-driven development to test-driven UI design, with a flow and wording that felt just a little too literal - like it had been written to make a test suite pass rather than look and feel right to a human. There was also a lot of churn between tests and code. Maybe I could fix this with more up-front design effort (more on that later) but I found it more productive to move to more of a "test alongside" approach.

Perhaps relatedly, I found that while a bottom-up approach to writing code (model -> controller -> view) still makes logical sense, it tended to result in Claude producing a lot of YAGNI code. While it feels a bit like rowing against how Claude wants to work, I tilt things towards building a simple UI first, then add to it while pulling through what I need to make it work. It cuts out the YAGNI and feels much easier to follow along and reason about whether things are going in the direction you want as you work. Your brain has a limited context window too!

Because they give you the feedback loop that helps it all work, tests are really important. I found they would easily bloat, and have done one very major refactor of the whole test suite at one point, which made me get very specific with the rules. This is not rocket science but needs defining:

Test: Business logic validations, authorisation logic, custom methods with actual logic, non-standard controller actions.

Don't test: Database constraints (that's Rails' job), basic associations (framework functionality), standard CRUD operations, basic display rendering, etc.

System tests: Reserved for critical end-to-end workflows only. Build them once at feature completion, not incrementally. They're slow, they're brittle, and most of what they catch should be caught by faster tests anyway.

I should note - this implementation approach isn't just something the /implement-task command knows about, the /create-implementation-plan and /create-backlog commands both need to know about it too, to shape things the way you want at that level (again - remember how things fan out!)

Is this overkill?

For a tiny side project? Maybe. For production software that real organisations depend on? Not even close.

The whole thing adds maybe 20-30 minutes to the start of a feature. In exchange, you get a spec you can refer back to, a plan that explains the reasoning, a backlog that breaks work into reviewable chunks, and implementation that follows your existing patterns with security checks baked in. It all reminds me of the saying "make the best way the easiest way". It feels like that's where AI really helps. The best way often has a bunch of boring steps people can't be bothered doing, and things work well enough when they skip them, so they do. The results could be better though, and now they can be, easily.

This is still dramatically faster than doing most things manually, and makes possible some tasks that would take so long before that you would just never attempt them. But it's not just about speed - it's about ending up somewhere you actually want to be. And man, the youtubers are right about one thing, it is fun! I think it also genuinely works as a system a team could adopt and use together effectively.

I've noticed even when I do want to straight up vibe code something, I often use a super lightweight version of this process anyway - make a spec and from that a combined implementation plan and backlog that I work through. If nothing else, it helps you manage the context window well.

What's next?

Although my iterations on claude-kit have slowed down, I still continue to make small tweaks here and there. That in itself is an interesting story. One of the best ways I found to improve the commands and agents was asking Claude to review our session once I was done implementing a feature, look at where I had to intervene, and make changes to prevent that being necessary in future.

One obvious gap you may notice is I don't really have a design phase. I cheat by using css-zero and pointing my frontend-agent at its documentation, emphasising the need to use its components. This works great for what I'm building at the moment, but wouldn't for everything.

I'm also keeping an eye on where Claude is going and making sure I'm making the most out of its capabilities. I want to dig into the latest announcements around skills. I ignored them when first announced as they seemed focused on Claude the App rather than Claude Code, and I was happy with my agents, but as more things start to blur together, I wonder if there is benefit in breaking down what my agents 'know' into multiple finer-grained skills that might also be able to use them elsewhere (e.g. from the Claude Mobile App?).

The other thing I don't make much use of is Claude's built-in planning mode. In a way this workflow (which predated that feature) is a different way of achieving the same thing, but I wonder if I can use it more, or even use it to replace some of what I do now to speed things up while maintaining the same quality bar.

I'm not quite ready to give up working from my IDE. Being actively involved in the process still seems like it yields a better result, but I have to admit, a combination of fine-tuning claude-kit and Anthropic's models improving has sometimes left me feeling a bit like Homer Simpson's "he's drinking the water!" bird - just sitting here pressing return. Ultimately I want to find a new baseline that cuts more of that out and lets it run unhindered, then I'll review as a PR.

At some stage I'll probably clean up claude-kit and make it public, but I think this post will help you more than just looking through that. The real insight here is that the kit isn't valuable because it's clever in any new way, it's valuable because it's a place to accumulate your own lessons learned in a form that Claude can actually use, and share it with others. My sense is that over time, you can raise the floor on the code you write on your worst day to be as good as that on your best, and have everyone in your team do the same.

Thanks for subscribing. Say hello.

There is no .cfignore

Git has .gitignore. Docker has .dockerignore. Surely Cloudflare has .cfignore? It doesn't. Despite community requests, and Claude thinking there is (until being asked to confirm it) ... there's no built-in way to exclude files from a Pages deployment. At this point, since it seems like Pages is going away, it never will.

The build step workaround

So, if you want something in your repo but not deployed (in my case, a .claude folder) - the solution is to add a build step. Even for a static site with no build process.

After Cluading up a few alternative approaches, using tar was actually one of the cleanest:

mkdir -p dist && tar --exclude='.claude' --exclude='.git' --exclude='dist' -c . | tar -x -C dist

Set your build output directory to dist and you're done.

It's really important to exclude the dist folder, or you end up with recursive duplication (ask me how I know).

The ghost file

One kind of strange thing I learned in the process. Before adding the build step, I'd already deployed the site a few times with my .claude/settings.json file. Even after fixing the build, that file was still accessible on the live site.

I deleted all old deployments. Still there. I purged the Cloudflare cache. Still there. It's probably still there now.

Turns out Cloudflare Pages has an asset preservation cache that keeps old files around for up to a week, even after they're removed from deployments. It's separate to the CDN cache and unlike it, there's no way to manually purge it.

This is fine for my harmless settings file. But imagine accidentally deploying an API key or password. You'd have to rotate the credential anyway, but having no way to remove it from the CDN for a week feels like a gap? To be honest I kind of assume I am missing something. Let me know if I am.

Back to that spoiler

If you don't need the file version-controlled, just add it to .gitignore. I decided I could live without it under version control after all and while the other approach worked fine, I want this setup to be really simple and foresee a point where I do a proper build step elsewhere at some point anyway.

But either way: don't deploy secrets to Pages. Seems like you can't force-purge them.

Thanks for subscribing. Say hello.

Here's a good question:

There's a feeling you get in the presence of beautiful buildings and bustling courtyards. A sense that these spaces are inviting you to slow down, deepen your attention, and be a bit more human.

What if our software could do the same?

I am always a bit skeptical of things that require swimming against incentives, so they will need to change first. Perhaps this manifesto points to what the other side of that time looks like though: https://resonantcomputing.org

Thanks for subscribing. Say hello.

I just read that Apple Podcasts names The Rest Is History the 2025 Show of the Year.

This is such a great podcast. Both Dominic and Tom are master storytellers. Whatever the topic they make it well worth a listen or watch. This overview that announced the award is a good starting point.

Thanks for subscribing. Say hello.

This is a short (just 14 mins) interview with Claude Code Product Manager, Catherine Wu, that had more useful snippets on using Claude than you'll find in 10 hours worth of vibe coding nonsense on YouTube.

It's actually kind of funny (and refreshing) how low key and to the point this is on Anthropic's own channel.

A lot of relevance to what I've seen while tinkering. Worth your time.

Thanks for subscribing. Say hello.

From the department of the more things change, the more they stay the same.

2007:

Sent from my iPhone

2025:

🤖 Generated with Claude Code

I wonder if there's a good story about coming up with the iPhone tag line. Seems like the kind of thing John Gruber might know about if there's anything to know, but all I could find over at Daring Fireball was this.

Thanks for subscribing. Say hello.

She runs through the rise of email newsletters, Substack, why that's happened with the Facebooks & Twitters Xs of the world deprioritising links to external sites, then how to go about trying out RSS:

I've been heavily using RSS for over a decade, and it's a travesty more people aren't familiar with it. Here's how to join me in the brave new (old) world of RSS.

I've been using it for even longer, but with a hiatus caused by the same thing Molly mentioned - the death of Google Reader, followed by a "well I just get all my articles from Twitter now" phase - but have returned now to RSS. If you weren't using it ten or twenty years ago, it might be very unfamiliar so her post is valuable.

The only two useful things I think I can add:

1. My personal choice of client is Reeder Classic. I wanted to support them by trying the new Reeder but it really wasn't my cup of tea. Like the popular Current that came later, they both try to fix problems that I realised I don't really have perhaps, and in ways with too many compromises. Simple is better.
2. I don't think she mentioned that you can also follow the RSS feed for any Substack. I'm somewhat surprised they do this given their business model, and maybe won't forever, but right now it works great for free sites. For paid stuff no one I'm aware of does this well, except Ben Thompson with Passport.

RSS is such a calmer way to consume content that is interesting and useful. I try to avoid the social media platforms these days. Sometimes I miss that sense of swimming in the stream of what is happening right now, but the signal to noise ratio is so low. Over time I've found the most interesting people on Twitter or Threads or Bluesky or Linkedin also write their own blogs, giving a richer, more thought through and information dense form of their ideas. More signal, less noise.

I'd encourage you to grab a copy of Reeder Classic, or NetNewsWire (which is having an interesting rebirth) or anything else you like the sound of, load up some of the things you already like to read and try RSS out. If you want some suggested feeds, you can also check out my blog roll for ideas, or import them all with the opml (another nice feature of rss readers generally).

Thanks for subscribing. Say hello.

That's the long-term magic of Ruby on Rails. The ability to draw a yield from investments made in mastering the basics for years if not decades to come. Making that first deposit towards those investments is what this book is all about. To put a stop to, or at least provide an alternative to, the constant churning and thrashing that has beset the world of web development.

Thanks for subscribing. Say hello.

This is something I wrote about internally at Trineo. Much of the below comes from a post that made its way onto the external facing company blog, but revised after thinking about what it means in the years since then, not least after the arrival of generative AI. I also added new memes.

Value

Writing is hard but creating a writing culture is incredibly valuable. This goes double or quadruple for remote teams but any company will run better when things are written down.

This isn't a new idea. A quick search will turn up lots of posts but I first came across it in this post by Steven Sinofsky. I'll be pulling some quotes from there and it's well worth reading in full.

The appeal

Writing is Thinking was an idea that appealed to me at face value. I like writing, and do find it bringing a level of clarity to ideas you can't develop to the same extent without it.

But while I do find it enjoyable, a kind of flow state activity like writing code, I don't think writing well, to be consumed by others, is easy. And it can definitely feel time consuming. That's the obvious answer to why we don't always do it. Sinofsky doesn't shy away from this point either.

Writing Is Hard

Writing is super hard. It takes more time to write than it does to talk. It also takes more time to write a page of text than a single slide.

This is one of those things that is 'obvious' but easily missed how important it is. Once you see it, you'll realise how often the easy path of slides, or even easier path of just talking, takes place - including by yourself, not just others. I'll pull the exact example Steven used here comparing a 'Slide' to a 'Story':

Slide

Story

It's clear how much detail is missing from the Slide. If that's all you share, two things happen:

1. The original details are lost, forever.
2. People will make up those missing details themselves.

Think of this as a team trying to join in a lesson. Think about trying to share this lesson multiple times. Think about a new team member who only has this slide.

Even if you don't have a death by PowerPoint culture, you might find you more than make up for it in rushed Slack messages, video calls, or in-person walk-ups - with similarly lossy results.

Now imagine that slide was about your product, and gets turned into some features. At the extreme, you could spend six months building something that addresses a tangential anecdote, while missing the real point.

So what is it about the written example that makes it worth spending time on?

Context

Taking the time to write allows you to provide details, which creates context, and it matters for everything from your strategy to an individual product feature being built somewhere.

The key to achieving any goal as a team is having a shared understanding, with context kept intact, so that everyone can row in the same direction.

In practice, I think this requires the upfront investment in writing that shares the raw materials that go into your work. Yes, they need refining into a clear articulation of what actually needs to happen - but it should also include a thorough exploration of the thinking that led you there, so people can weigh up the same information and arrive at the same conclusion, or not, and push back before you start.

That's real understanding, and it prevents going off the rails later.

Collaboration

[...] you can't have plans, especially shared plans, without writing.

The 'why' behind building software emerges from the input of a number of people.

The act of writing forces a team of experts to share the details of goals—not just the what, but the why, what else was considered, the history, context.

Writing something together is obviously collaborative. Writing yourself feels like a very solo pursuit. At work though, it's almost always done to eventually share - whether starting something new, providing a response or building on top of someone else's words, that's a collaborative pursuit as well.

And it's an asynchronous form of collaboration. That might be what makes it so useful, especially for working through complex problems.

Writing is more inclusive. It is easier to contribute, doesn't reward bullies and bullshitters, and allows for contemplation.

I don't think it's worth glossing over the way asynchronous collaboration like this can allow more people to contribute more fully to discussions and decisions. As well as things like English skills, seniority and all the other hidden biases we don't think influence us, writing (compared especially to meetings) levels the playing field a lot, especially for distributed teams.

It also strikes me that reading the well considered thoughts of someone else is a very easy environment in which to stop, think and understand.

Contemplation

Providing context and fuelling meaningful collaboration are good outcomes, but you won't get either without first refining the information you've gathered and thoughts that you have into meaningful (to yourself and your audience) knowledge to be considered.

The act of writing, forces the author to think through all the details and steps required to share the lesson. It avoids what happens in business all the time which is "I just know" or "experience" and brings along the team and other job functions on thinking.

I find this to be incredibly true. How often have you had an idea rattling around in your head that seems totally plausible (e.g. every "It's ChatGPT for X" idea you've had this week) but when you sit down to write it out, all you have is two sentences that don't make sense and a flashing cursor... No? Just me? Ok.

[...] the process of writing and sharing thoughts is clarifying AND collaborating itself

Writing is the forcing function to clarify your thoughts and find out if they're valuable, to sift through them to see which contradict, which are unfinished and which are just plain wrong. It's this hard work that turns ideas, snippets of conversation, notes from meetings and everywhere else from 'data' into 'insight' that's worth sharing.

Ok, sure, but you promised you'd talk about AI

One of the things I'd forgotten until I dusted this off to write about again was the emphasis on context.

Context Engineering is the new Prompt Engineering, and from my experimentation the last few months (which I've written about here) is a very accurate name. Good results come from working to optimise the LLM's context window.

Obviously that's not the same thing but it made me smile. Context is still king, and writing is more important than ever. I think the companies that already have deep cultures of writing and sharing context are going to be at a distinct advantage when adopting these new tools. Using them best looks like working in the ideal way you never quite achieved, but now kind of falls out of the process because the value is even more extrinsic.

But do I even have to write anymore?

Well, do you have to think anymore?

Now that everyone aims to have their favourite flavour of generative AI do their writing for them, a new chasm is going to open. Those who never wanted to write won't have to, and now the Slide Deck will be slop copy pasted from ChatGPT.

But used well, the tools can enhance the process of doing really valuable, thought clarifying writing. The value is even higher because now you can turn around and give that to an LLM to act on. I still see a long term advantage in a world that will be awash in content but not context, and lacking the kind of clarity you need to underpin sustained execution against a well thought out strategy.

Valuable but spiky

One last thing. I learned over the years is some people really like this approach and some really don't. I used to think this was a kind of obvious way to do things to everyone, but no, it's a spiky point of view.

At times I've wondered if pushing it is even worthwhile. It's hard to do yourself and harder still to turn into a process that can co-ordinate a group to move forward versus just calling a meeting. A hasty meeting that at least makes a decision and puts it into action is better than a thoughtful plan that's written down but never actioned. But that shouldn't be a trade off you need to make, you can blend the best of both.

I also think people should work in the ways they feel make them most effective, so sometimes I've also wondered if pushing too hard down this path is the antithesis of trying to level the playing field as described earlier. Maybe it just tilts it in a different direction?

But I think there is too much value here. You just need to work not just writing but reading, collaboration and the mechanism by which this helps make decisions quickly. You also need to realise fully that it isn't for everyone - but that's true of any culture. You'll need to be prepared for it and work on it more than you think though. These pieces that turn thinking into action are critical, otherwise it will leave everyone (but especially those who are more naturally inclined towards written communication) frustrated.

For those it resonates with though, it resonates a lot. I'll leave the last word to a colleague responding to that internal blog post years ago:

Writing is, as far as I can tell, one of our greatest technologies. Thoughts that undergo non-fixed length curation. You get unlimited time to scrupulously interrogate your thoughts. Even writing this I had to pause to try work out what I'm thinking. When it really clicks, that writing is that powerful, I don't know why we don't do it more.

Thanks for subscribing. Say hello.