rarouš.w3b

Why I’m no longer updating this repository

2026-10-20T10:31:07Z

I’ve decided to archive the source code of my Ruby gems to make it clear that I’m no longer working on them; I’ve written this post to link from them in order to explain why.

In an article published in 2000, Yukihiro Matsumoto (a.k.a. “Matz”), designer of Ruby, wrote,

For me, the purpose of life is, at least partly, to have joy. Programmers often feel joy when they can concentrate on the creative side of programming, so Ruby is designed to make programmers happy.

And as recently as a 2019 interview, he said,

I designed Ruby for humans, not for machines.

It was during that era, when Ruby was ostensibly for joy, for creativity, for humans, that I developed this code. But that age, of doing things for humans, has passed, and with it my enthusiasm for working on Ruby gems. I won’t say it was always great, but at least we were working with and for people.

The pre-eminent application of Ruby has been making web applications using Rails. Rails is open source software but it’s owned and controlled by a man whose views I find abhorrent, although there is an ongoing effort to fork it. To judge by his keynote at Rails World this year – the conference that he himself set up in pique after he wasn’t invited to RailsConf a couple of years ago – he is no longer particularly interested in Ruby, Rails, or even programming itself. (He’s now using LLM agents to churn out apps in Rust, a language which he compares to “pouring acid into [his] eyes”, but that’s apparently fine because he doesn’t even look at what they generate.)

But even beyond Rails, the Ruby language itself is now substantially developed using LLM agents. Matz is giving talks repositioning Ruby as a “Programming Language for AI age”, to be emitted by LLM agents, and stating that to be able to do that LLMs need to consume more good human-written Ruby code. You might already have seen the problem here.

In that context, I no longer feel inspired to contribute to a commons that’s being strip-mined by massive corporations to feed the very machines whose unthinking output pollutes it. When people claim that it’s no longer sustainable to write code by hand, they’re not entirely wrong, but only in the same way that it’s no longer sustainable to sleep in a bed once someone has taken a shit in it.

You want changes? Go ask your agent or something. I’m told that’s what you’re supposed to do now. I’m out.

I’ve Changed My Mind About CSS Variables

2026-10-19T17:38:52Z

A while back, Eric Meyer emailed to ask about my old post arguing that CSS variables were a bad idea. Did I still feel that way?

No. I’ve changed my mind.

These days, I use CSS custom properties—the feature we often call “CSS variables”—quite a lot. To adapt interfaces to people’s preferences. To pass theme colors to JavaScript-driven interfaces. To theme many of the web components I build. I also discuss them quite a bit in my forthcoming course on progressive enhancement. At this point, that old headline no longer applies.

I’ve added a brief note to the original post, but I thought it best to explain the change in more detail. Hence this post.

My change of heart came not just because browser support improved, but because I realized I’d been too focused on custom properties as Sass variable replacements.

My original concerns

At the time of my original post, published in November 2014, browser support was extremely limited. The example I included used custom properties to store foreground and background colors:

:root {
  --foreground-color: #333;
  --background-color: #fff;
}

body {
  background: var(--background-color);
  color: var(--foreground-color);
}

I was concerned that browsers without support would lose those color declarations. To give those browsers the intended colors too, we’d need to write old-school color values first:

:root {
  --color-foreground: #333;
  --color-background: #fff;
}

body {
  background: #fff;
  background: var(--color-background);
  color: #333;
  color: var(--color-foreground);
}

I compared that with Sass, which could substitute the values during compilation, yielding universally understandable CSS:

$color-background: #fff;
$color-foreground: #333;

body {
  background: $color-background; 
  color: $color-foreground;      
}

If we only need to replace a name with a fixed value, doing that before sending the stylesheet was (and remains) perfectly reasonable.

But I went further. I treated the necessity of fallback declarations as a flaw and used it to dismiss custom properties altogether. I shouldn’t have.

The uncomfortable irony is that I’ve advocated for authoring a usable baseline followed by an enhancement in CSS for years. Some degree of repetition is often required to make that work. I shouldn’t have dismissed custom properties just because a preprocessor let me avoid the redundancy.

In that piece, I also speculated about the performance cost of custom props without bringing receipts. Browsers do have to resolve their values, but I had no proof this would cause a meaningful performance problem.

What I missed

I’ll admit I had a very simplistic view of custom properties. It was largely informed by my immersion in Sass at the time. I didn’t take the time to dig into the more powerful aspects of custom properties. Custom properties participate in the cascade. They inherit by default too. Their values can differ across elements or change in response to media queries and changes in the document.

That power becomes apparent in an example like this:

:root {
  --notice-background: #eee;
  --notice-foreground: #222;
}

@media (prefers-color-scheme: dark) {
  :root {
    --notice-background: #222;
    --notice-foreground: #eee;
  }
}

.notice {
  background-color: #eee;
  background-color: var(--notice-background, #eee);
  color: #222;
  color: var(--notice-foreground, #222);
}

.notice--warning {
  --notice-background: #ffe08a;
  --notice-foreground: #222;
}

Here, ordinary notices change their theme based on a user’s color-scheme preference. A warning notice, however, gets its own colors without changing the declarations that use them. Descendants can inherit those custom properties and use them too.

A Sass variable, in contrast, is static. It doesn’t respond to that context at all. A custom property does. We can generate preference-aware styles with Sass, of course, but compiled variables and browser-resolved custom properties are worlds apart.

I didn’t understand how powerful custom properties are when I wrote the original post. I was squinting at them through Sass’s pink-tinted glasses.

Theming through and through

One project that made the value of custom props much clearer to me was a canvas-based audio visualizer I was working on. It looked fine while I was using dark mode. When I switched to the light theme, however, the visualization disappeared against its background. As my son would say: “That’s buns.”

I’m almost always in dark mode, so that’s what I’d been testing in. I’d totally neglected to give it a look in light mode. Yikes.

I was already using custom props to handle site-wide theming, so rather than maintain a second set of theme colors in JavaScript, I opted to read the values CSS had resolved:

const theme = {};

function importTheme() {
  const styles = window.getComputedStyle(document.documentElement);

  theme.foreground =
    styles.getPropertyValue("--color-foreground").trim() || "black";
  theme.background =
    styles.getPropertyValue("--color-background").trim() || "white";
}

importTheme();

The drawing code could use those values for its strokes and fills. Then a listener could refresh the theme values when the user’s color-scheme preference changed:

const preference = window.matchMedia("(prefers-color-scheme: dark)");
preference.addEventListener("change", importTheme);

When the theme changes, the next draw uses the updated colors. A graphic that isn’t being continuously redrawn would also need to be repainted, of course, but for an audio visualizer it was perfect.

I covered the setup in “Passing Your CSS Theme to canvas”. The key benefit of this approach is that CSS remains responsible for resolving the theme, while JavaScript can focus on managing the drawing. Clean separation.

Styling components

If you’ve been following my work for a while, you’ve probably seen my growing list of web components. I use custom properties in them quite often. My <fullscreen-control> component, for instance, adds a “fullscreen” button to a wrapped <video> or <iframe>. Authors can adjust the button’s position through custom props:

fullscreen-control {
  --fullscreen-control-button-inset-block-start: 1rem;
  --fullscreen-control-button-inset-inline-end: 1rem;
}

Those values control the button’s position. No need to crack open the JavaScript to move it. And because the positioning uses logical properties, the offsets follow the writing mode rather than assuming a particular physical corner.

Similarly, <form-validation-list> exposes custom properties for icon size, matched and unmatched colors, and similar design choices. That makes it relatively straightforward to adapt the component to a site’s design without touching the component’s behavior.

In both cases, custom properties provide a simple way to alter the look and feel of the component directly from within a stylesheet, where design decisions belong.

Fallback, carefully

Even though I complained about them at the time, I don’t want to gloss over the importance of fallbacks for custom properties. Used properly, they help make our designs robust and progressively enhanced.

When the browser doesn’t support custom properties

Take the following, for example:

:root {
  --flow-space: 1em;
}

.flow > * + * {
  margin-block-start: 1em;
  margin-block-start: var(--flow-space);
}

.compact {
  --flow-space: 0.75em;
}

In this code sample, the second rule (.flow > * + * {}) establishes space between adjacent children in two steps: first, it sets a block-start margin using a standard value (1em), then it overrides that value using a custom property (var(--flow-space)).

Browsers that understand custom properties use the value of --flow-space because that declaration comes later in the rule. Browsers that don’t understand var() ignore that declaration, following the rules of fault tolerance. They apply the earlier 1em declaration instead.

The .compact rule overrides the inherited spacing value, so a flow container in a compact region can use tighter spacing without a different margin rule.

When the custom property is missing

The second argument in var() handles a different situation:

.flow > * + * {
  margin-block-start: 1em;
  margin-block-start: var(--flow-space, 1em);
}

In a browser that supports custom properties, it provides a backup value the browser can use when the referenced property is missing or resolves to the guaranteed-invalid value. To test this, you could remove the --flow-space assignment from :root and—if no other assignment applied or was inherited—the fallback argument would supply 1em.

It’s important to note that this situation is different from a value being unacceptable for a given property. The fallback argument doesn’t check whether the custom prop’s value is a valid size or color.

I’ll illustrate that with a silly example:

.notice {
  --notice-color: 20px;

  color: #333;
  color: var(--notice-color, #333);
}

In a browser that supports var(), the earlier color declaration (color: #333) isn’t used. The custom property (--notice-color) exists, and 20px is a valid value for an unregistered custom property, so the fallback argument isn’t used either. Unfortunately, after substitution, the winning declaration is color: 20px, and 20px is not a valid color value.

In this scenario, you might expect the browser to fall back to the previous color declaration. It doesn’t.

This is an example of an invalid-at-computed-value-time failure. The browser stores the 20px value for --notice-color with no problem. The problem only becomes apparent when that value is used as a color, after the cascade has selected the declaration. At that point, it’s too late to ignore the declaration during parsing, as the browser would with a literal color: 20px. Instead, the element inherits its color from its parent. For non-inherited properties like background-color, the browser uses the initial value instead.

The browser won’t rewrite the custom property. It won’t go back through the earlier declarations looking for a replacement either.

That was a contrived example. Here’s a more realistic one.

When the value requires a newer feature

Just because a browser supports custom properties doesn’t mean every value we assign to one will work. Imagine you want to use a newer color function in a custom property:

:root {
  --button-background: color-mix(in oklab, #e200ff, black 65%);
}

button {
  background-color: #222;
  background-color: var(--button-background, #222);
}

A browser that supports custom properties but doesn’t know what color-mix() means will still retain the custom property’s value as a sequence of tokens. The failure comes later, when it tries to use that value as a background color. Neither the preceding declaration nor the fallback argument can save you; the background becomes transparent, its initial value.

To retain a known-good value while using color-mix() as an enhancement, we can test for support before assigning it:

:root {
  --button-background: #222;
}

@supports (color: color-mix(in oklab, red, red)) {
  :root {
    --button-background: color-mix(in oklab, #e200ff, black 65%);
  }
}

button {
  background-color: #222;
  background-color: var(--button-background, #222);
  color: #fff;
}

The @supports block checks whether the browser accepts color-mix() in the oklab color space, without tying it to a particular palette or background. Mixing red with itself is a terse way to test the syntax. We can then group multiple enhanced custom-property assignments inside that same block. If you’re using other color spaces or newer color syntax, place each in its own @supports block to ensure maximum compatibility.

In this example, the known-good value (#222) remains unless the support test passes. Browsers without custom-property support still have the literal background declaration too.

Note: When enhancing this way, it’s critical that we test each potential color combination to ensure accessible contrast levels.

Fallbacks aren’t mandatory. Sometimes an inherited value or the browser’s default provides a reasonable baseline experience. It’s good to know we have these options, though, and a modest amount of redundancy when it matters is a small price to pay.

Where that leaves me

Eric’s question was a useful nudge to revisit an opinion I’d left sitting on the Web long after my own work had moved on.

I still stand by the central concern in that original post: people should have a usable experience when a particular enhancement isn’t available. The difference is that now I’ve got plenty of ways to use custom properties in service of that goal. They let me respond to preferences, adapt components, and share dynamic styles between CSS and JavaScript.

If you’re deciding between a preprocessor variable and a custom property, consider when the value needs to be resolved and what needs to influence it. If it needs to respond to the person using the page or the rendering context, a custom property resolved in the browser can be genuinely useful. Just be sure to check what happens when the value—or the enhancement consuming it—isn’t available.

That’s the question I should have spent more time on in 2014.

Will serving real html content make a website faster lets experiment

2026-10-14T16:30:55Z

We couldn’t extract the content of this article. Here is the URL so you can access it:
https://www.catchpoint.com/blog/will-serving-real-html-content-make-a-website-faster-lets-experiment

Setup Jellyfin with Hardware Acceleration on Orange Pi 5 (Rockchip RK3558)

2026-10-04T10:50:16Z

Introduction

As promised in my previous post, today I will be sharing about how I set up Jellyfin with hardware acceleration on my Orange Pi 5 Plus server.

Recently I migrated Jellyfin along with couple of other services on my new Orange Pi 5 Plus server. The Orange Pi 5 Plus has a Rockchip RK3558 SoC which has with integrated ARM Mali-G610 GPU which is compatible with OpenGL ES1.1/2.0/3.2, OpenCL 2.2 and Vulkan 1.2. This helps in offloading the video decoding and encoding tasks from the CPU to the GPU which results in better performance and lower power consumption.

In addition to common codecs, the RK3558 chip from Orange Pi 5 Plus is also able to support 10-bit H.264 (High10) and AV1 decoding, and has an H.264/HEVC encoding speed of up to 1080p@480fps or 4k@120fps which is quite impressive.

With that said, let’s get started with the setup.

Prerequisites

Before we start, here is what I did as the prerequisites to enable hardware acceleration for Jellyfin.

Install Ubuntu 22.04 (Jammy)

I installed Ubuntu 22.04 (Jammy) headless on my Orange Pi 5 Plus. You can download the image from the Orange Pi 5 Plus website ↗️ and flash it on a microSD card or a NVME drive.

The reason for choosing Ubuntu 22.04 is that it has good support for Rockchip SoCs and the drivers required for hardware acceleration are available easily.

One thing to take a note of is that the Kernel version of 6.1 or 5.10 LTS is required for the Mali G610 GPU to work. You can check the kernel version by running the following command.

💡

Note for ubuntu-rockchip users

If you are using the Ubuntu 24.04 image from Joshua Reik ubuntu-rockchip ↗️ repository, then you can skip the below steps as the image comes with the required drivers pre-installed.

Skip directly to the Setting up Jellyfin section.

Install and enable the GPU drivers

We will add two repositories to install the GPU drivers. The first repository is to download the Mali G610 firmware and the second one to get the rockchip multimedia configuration.

Terminal window

sudo add-apt-repository ppa:rockchip-linux/ppa
sudo add-apt-repository ppa:liujianfeng1994/rockchip-multimedia

Next, update the package list and install the required packages.

Terminal window

sudo apt update && sudo apt install mali-g610-firmware rockchip-multimedia-config

Optionally you can then remove the repositories.

Terminal window

sudo add-apt-repository --remove ppa:liujianfeng1994/panfork-mesa
sudo add-apt-repository --remove ppa:liujianfeng1994/rockchip-multimedia

Now to support HDR tone-mapping we will install OpenCL runtime (libmali) on our system. We will find this here ↗️. Copy these commands to your terminal to start installing the OpenCL runtime.

Terminal window

mkdir -p ~/tmp/libmali && cd ~/tmp/libmali
wget 'https://github.com/tsukumijima/libmali-rockchip/releases/download/v1.9-1-55611b0/libmali-valhall-g610-g13p0-gbm_1.9-1_arm64.deb'
sudo dpkg -i ./libmali-valhall-g610-g13p0-gbm_1.9-1_arm64.deb

Finally we will just verify that our devices are available which are required for hardware acceleration.

Terminal window

for dev in dri dma_heap mali0 rga mpp_service \
 iep mpp-service vpu_service vpu-service \
 hevc_service hevc-service rkvdec rkvenc vepu h265e ; do \
 [ -e "/dev/$dev" ] && echo " --device /dev/$dev"; \

If you see an output like below, then you are good to go.

Terminal window

--device /dev/mpp_service

With these prerequisites done, we can now move on to setting up Jellyfin.

Setting up Jellyfin

Jellyfin have brought in support for hardware acceleration on Rockchip from version 10.9.0. So we will install the version 10.9.0 or later. At the time of writing this post, the latest version is 10.9.7.

I am using Docker to run Jellyfin and I have a docker-compose file for the same. Here is the docker-compose file I am using.

 image: 'ghcr.io/jellyfin/jellyfin:10.9.10'
 container_name: 'jellyfin'
 security_opt: # enables full access to /sys and /proc, still far better than privileged: true
 - '/dev/dma_heap:/dev/dma_heap'
 - '/dev/mali0:/dev/mali0'
 - '/dev/mpp_service:/dev/mpp_service'
 - '/media/content:/media'

It is a standard docker-compose file but I will highlight few important parts here. First thing is that we need escalate the container’s privileges to access the GPU devices. We do this by adding the security_opt option. This is better than using privileged: true as it only gives access to /sys and /proc directories.

Next we add the GPU devices to the container using the devices option. This will allow the container to access the GPU devices.

Additionally we adding the video group to the container using the group_add option. This is required to access the video devices. You can check what is the id of the video group by running the following command.

Terminal window

getent group video | cut -d: -f3

With this docker-compose file, you can now start Jellyfin by running the following command.

Once the container is up, you can access Jellyfin on http://<your-ip>:8096 and start setting up your media library.

To verify that the OpenCL runtime is working correctly inside the docker container, you can run this command.

Terminal window

docker exec -it jellyfin /usr/lib/jellyfin-ffmpeg/ffmpeg -v debug -init_hw_device rkmpp=rk -init_hw_device opencl=ocl@rk

If you see an output like this, then the OpenCL runtime is working correctly.

Terminal window

arm_release_ver: g13p0-01eac0, rk_so_ver: 10
[AVHWDeviceContext @ 0x55b1c52f00] 1 OpenCL platforms found.
[AVHWDeviceContext @ 0x55b1c52f00] 1 OpenCL devices found on platform "ARM Platform".
[AVHWDeviceContext @ 0x55b1c52f00] 0.0: ARM Platform / Mali-G610 r0p0
[AVHWDeviceContext @ 0x55b1c52f00] cl_arm_import_memory found as platform extension.
[AVHWDeviceContext @ 0x55b1c52f00] cl_khr_image2d_from_buffer found as platform extension.
[AVHWDeviceContext @ 0x55b1c52f00] DRM to OpenCL mapping on ARM function found (clImportMemoryARM).
Successfully parsed a group of options.

If you see any errors then you might have missed something in the prerequisites. Go back and check the prerequisites again. If you are still facing issues, feel free to ask in the comments.

PROMOTED Built & launched by me

Company-event signals as one clean API

Datahyena delivers funding rounds, acquisitions, and executive moves as clean, typed records. Every signal is deduplicated and resolved to canonical companies and investors, ready for your GTM, research, or data workflow.

Enable Hardware Acceleration in Jellyfin

Now this is the final but very important step (side story, I spend a good 30 minutes only to realize that I missed this step, so don’t be like me 😅).

To enable hardware acceleration in Jellyfin, go to Dashboard -> Playback -> Transcoding. Under Hardware acceleration choose Rockchip MPP (RKMPP) and enable hardware decoding for H.264, HVEC, HVEC 10 bit and AV1 codecs.

If your OpenCL runtime is working correctly, then you can also select the Enable Tone mapping option to enable HDR tone mapping.

Go below and click on Save to save the settings and you are done.

Moment of Truth

Those were some pretty good amount of steps that we had to do right, so let’s see if it was worth it. To test it I played a 4K HVEC HDR video and here are the results.

Running a 4K HDR video on Jellyfin with Transcoding enabled

The above image shows the Jellyfin video player showing the playback stats and the video being transcoded with ffmpeg.

Let’s look at the CPU usage when the video is being played.

CPU stats when playing a 4K HDR video on Jellyfin with Transcoding enabled

As you can see the average CPU usage is around 10-11% which is quite impressive for a 4K HDR video. This is because the video decoding and encoding tasks are offloaded to the GPU. Here are the stats from the RGA engine.

RGA engine stats when playing a 4K HDR video on Jellyfin with Transcoding enabled

Now if you are wondering if this is actually any good, then here’s the stats for the same video being played without hardware acceleration.

CPU stats when playing a 4K HDR video on Jellyfin without Transcoding enabled

As you see, the CPU usage hovers around 75-80% where sometimes it even goes to 95% which is quite high given its just a single stream that is being transcoded. So yeah, hardware acceleration is definitely worth it.

With the current setup, I was comfortably able to play 2 4K HDR videos simultaneously without any issues. So I am quite happy with the performance.

Common issues

Playback failed due to a fatal player error

If you are facing this issue, then it is likely because of the video group is not added to the container. Add the video group to the container and restart the container. Make sure you add the video group id to the container in the docker-compose file as mentioned before in this blog.

Apart from this, if you want to check that the OpenCL runtime is working correctly, you can run the following command.

Terminal window

docker exec -it jellyfin /usr/lib/jellyfin-ffmpeg/ffmpeg -v debug -init_hw_device rkmpp=rk -init_hw_device opencl=ocl@rk

If you see any errors, then it is likely because of the OpenCL runtime is not working correctly. You can try to install the OpenCL runtime again by following the steps in the Prerequisites section.

If this is also working correctly, you should inspect the network call to the Jellyfin server. You can do this by opening the developer tools in your browser and inspecting the network calls. I ran into a scenario where the request was returning a 431 error ↗️ (Request header fields too large) and this was because I was using a reverse proxy (Caddy) and the default max header size was being hit, if this is the case you can increase the max header size by adding the following to your Caddyfile (or whichever reverse proxy you are using).

Conclusion

That’s it for this post. I hope this guide helps you in setting up Jellyfin with hardware acceleration on your Orange Pi 5 Plus server. If you have any questions or need help, feel free to ask in the comments.

You can also reach out to me on Twitter ↗️ / Reddit ↗️ / Mastodon ↗️.

Until next time, happy blazingly fast streaming! 🍿🎥🎶

The Web Is Being Made Accessible for AI, Not People

2026-10-02T05:25:27Z

The Svelte web framework recently added a section to its documentation site addressed, cheerfully, to artificial intelligences: “If you’re an artificial intelligence, or trying to teach one how to use Svelte, we offer the documentation in plaintext format. Beep boop.” Svelte is participating in a broader movement to make the web legible and navigable to AI systems. The specific convention it adopted, llms.txt, is just one piece of this effort. From Model Context Protocol (MCP) servers that give AI agents structured access to tools and services, to Vercel’s proposal to include LLM instructions in HTML, the trend is clear. The modern web, originally built for sighted humans using browsers, is now being redesigned for a new kind of user.

What these developers are offering their AI visitors is essentially an accessibility accommodation. Yet, the framing on Svelte’s site sends an unfortunate message. When the audience is AI, accommodation is offered with a wink. Beep boop! But when the audience is a disabled person, it has historically been treated as an afterthought. Structured, concise text-based representations of complex content are almost exactly the kind of accommodation that blind and low-vision screen reader users have spent decades requesting from web developers, largely in vain. The Web Content Accessibility Guidelines (WCAG) have required semantic, machine-readable HTML for decades. Yet, a 2026 study of the top million webpages found accessibility flaws in over 95% of sites.

The overlap between what AI agents need and what screen reader users need, however, is narrower than it appears. Screen reader users require not only plaintext, but also structure: heading hierarchies that allow jumping between sections, landmark regions, descriptive link text, and alt text for images. WCAG requires semantic HTML because screen reader users navigate content sequentially and depend on structural cues to find specific information.

A format like llms.txt goes in the opposite direction, flattening documentation into undifferentiated plaintext that a language model can ingest wholesale but that offers a screen reader user nothing to navigate by. And as large language models gain the ability to process images natively, AI-optimized pages have diminishing incentive to include alt text at all—even though blind users still depend on it. The risk is not only that these accommodations fail to help disabled users, but also that developers begin treating "machine-readable" as synonymous with "accessible," checking a box that was never truly checked.

This is not the curb cut effect—the oft-referenced idea that accommodations designed for disabled people ultimately benefit everyone. It is closer to the inverse: an accommodation built to serve a well-capitalized technological system that incidentally happens to address a need disabled people have long articulated without sufficient response.

It’s easy to forget that the curb cut, now widely taken for granted, was not given freely. In the early 1970s, disabled activists in Berkeley, California, wheeled themselves to intersections at night and poured their own cement ramps. Police threatened them with arrest. Though the curb cut effect is often invoked as a feel-good story about universal design, the original curb cuts were won through direct action, litigation, and political organizing.

Disability scholars have argued that the curb cut narrative, however well-intentioned, has been used to erase disabled people from their own innovations by justifying accessibility investments only when they can be shown to benefit non-disabled people. This emerging pattern takes that erasure a step further. The accommodation is not being built for disabled people at all, but for AI companies. Political will, funding, and urgency materialize only because the tech industry needs the same thing that disabled communities could not get on the basis of their civil rights.

This is not an isolated case. Consider road markings, a mundane feature of transportation infrastructure, that nevertheless carries significant consequences for both human drivers and autonomous vehicles. In a 2016 press demonstration in Los Angeles, a semi-autonomous Volvo repeatedly refused to move because its cameras could not detect the faded lane markings. Volvo’s North American CEO reportedly yelled at the Mayor of LA, “You need to paint the bloody roads here!”

As early as 2013, General Motors testified before the US Congress that for autonomous vehicles, “one of the key highway needs is to provide—at a minimum—clearly marked lanes and shoulders.” The resulting push for standardized, high-contrast, well-maintained road markings, culminating in 2022 Federal Highway Administration rules on minimum retroreflectivity, was driven substantially by the autonomous vehicle industry. Such improvements benefit all drivers, including those who drive at night. The need was always there, but meaningful action occurred only when the self-driving car companies needed the same thing.

Our content delivered to your inbox.

Join our newsletter on issues and ideas at the intersection of tech & democracy

Thank you!

You have successfully joined our subscriber list.

Sidewalk delivery robots present a more ambivalent example of this pattern, because the robots share disabled people’s infrastructure needs while also competing with them for space. Researchers have argued that delivery robots require many of the same things as wheelchair users: a continuous, unobstructed path free of cracked pavement, missing curb cuts, and overgrown vegetation. In testing, robots were unable to operate in some neighborhoods because of infrastructure limitations that wheelchair users navigate daily.

Yet these same robots also create new hazards for wheelchair users. In 2019, a delivery robot reportedly blocked a wheelchair user from accessing a curb cut while she crossed an intersection in Pittsburgh. More recently, in 2025, a man using a mobility scooter filmed a robot repeatedly swerving into his path and colliding with him. Researchers have documented disabled people’s concerns that sidewalk robots reintroduce access barriers because robotics companies overlook accessibility in the design process, even as they tout the robots’ potential to incentivize better sidewalk maintenance. Infrastructural changes for new technologies can produce both benefits and burdens, and disabled people are left to absorb both.

This pattern, in which disabled people fight for infrastructure only for it to be leveraged and overtaken by automated systems, deserves a name. Let’s call it the “ramping automation effect”: the ramps that wheelchair users built and fought for are now used by robots competing for the same sidewalks, as technological automation increases in scale and force (“ramps up”) across physical and digital domains. The ramping automation effect follows a long history of capitalistic and militaristic uses of otherwise public infrastructures that consolidate power while actively displacing disabled people.

To resist the ramping automation effect, disability advocates and policymakers must play a leadership role in shaping AI-driven infrastructure changes so they benefit disabled people. If the web is going to be restructured for machine readability, accessibility experts should be at the forefront of deciding how that restructuring happens, ensuring that standards serve disabled users and not only AI agents. Infrastructure improvements motivated by autonomous systems must incorporate co-design from a plurality of perspectives to ensure they deliver meaningful accessibility improvements and advance the public interest.

There are genuine opportunities to align the interests of AI and accessibility, but that alignment cannot be taken for granted. Plaintext documentation optimized for a language model is not the same as well-structured HTML for a screen reader. If the benefit for accessibility is assumed rather than intentionally designed, the result may be superficial or illusory.

However, the public must not accept that incidental accessibility benefits arising from AI development are an unqualified good. Not only is this assumption flawed, but it accepts a hierarchy that disability advocates should be challenging. The implicit premise is that disabled people’s needs require a commercial co-signer before they merit action. When a society is unmoved by decades of advocacy from disabled communities but springs into action when a tech company needs the same accommodation, it reveals whose claims on shared resources are treated as legitimate and whose are treated as optional.

And as AI companies begin to frame machine-readability and robotic infrastructure as accessibility stories, as some already do, the risk of accessibility-washing grows. Starship Technologies, whose delivery robots reportedly blocked a wheelchair user from curb cuts, maintains a dedicated accessibility page touting the robots as a service for disabled customers. Similarly, Agentic AI companies may create agent-friendly content that introduces new accessibility barriers, while claiming credit for accessibility work they are not actually doing.

Political energy for real accessibility mandates may weaken if the public comes to believe AI is solving the problem as a byproduct of technological progress. Controversial AI deployments, in turn, may be legitimized through the language of inclusion. Accessibility is a civil right. Treating it as a fortunate side-effect of fashionable AI development is another way of saying that disabled people’s needs, on their own, were never considered sufficient.

Mathematicians, Here’s a Way To Think About Your Existential Crisis

2026-09-29T13:39:50Z

Two years ago programmers were all like, “What I do is code. Who I am is a coder. The genie codes. Now who am I?” Now mathematicians are all like, “What I do is prove theorems. Who I am is a theorem prover. The genie codes. Now who am I?” Here’s a framework I’ve found helpful for answer that question for myself.

Features & Futures

Something similar to the structure of the two fields, programming & math, is that there is a (relatively) visible part—features in the case of programming & proofs in the case of mathematics—& a huge (relatively) invisible part. The invisible part is understanding, education, simplification, enabling abstractions.

If all we work on is the visible part, progress on that visible part slows to a crawl. But nobody gets credit for the invisible work, so we rely on an ethos of work to ensure that the invisible work gets done and everyone can continue to make progress on the visible stuff.

I call this hidden dimension “futures”, although “optionality” might be a more accurate word (if less alliterative).

In programming we also call this inverse of this axis “technical debt”, coined by Ward Cunningham. Sometimes you have to pay off your debts to get “interest” payments low enough that you can get back to progress on the principal.

Genies Hate the Invisible

I wonder if the angst among mathematicians is because:

The genie is so good at the visible stuff
Without the invisible work, visible progress eventually slows to a crawl, genie or no genie
Nobody gets credit for the invisible work

Put these together & you have a world where mathematicians no longer get any credit. The visible stuff is better done by machine. The invisible stuff is, well, invisible.

So What?

One constructive response to the identity crisis for programmers is to say hey I’m here to keep the genie on course. With the genie’s help I’m able to learn quicker than ever before. I still get to use my honed intuition to quickly stop useless directions. My reach has just extended. Yes, my work has changed, but my strategic decisions are more valuable than ever because they come more frequently.

I visualize this as taking breaks between visible progress to make invisible progress. I wonder if this way of thinking about their situation will help mathematicians take advantage of the powerful new tools available to them without losing their reason for being mathematicians. Good luck!

Most teams don’t have a strategy problem. They have an adaptation problem.

Your plan was never going to survive contact with reality. The question is whether your organization bends or breaks when it doesn’t.

I help teams bend. Adapt to Thrive.

Booking a handful of custom talks and advisory engagements now. I interview your people, measure your real software flows, and hand you the truth plus what to do about it.

Curious whether it fits? Tell me about your team.

The death of web development education – Rescuing a field from disappearing

2026-09-30T06:36:05Z

In a personal blog post, Baldur Bjarnason describes how he worked in various fields and positions: as an author, publisher, consultant, developer, educator, as well as radio and TV producer. Many independent educators who used to earn a living from web development training and developer relations have reported that GenAI has ruined their business.

The root scroller and how not to lose it

2026-09-23T10:42:30Z

Every page has one main scroll container that scrolls the page itself: the root scroll container, or root scroller for short. Because it scrolls the entire page, the browser gives the root scroller a bunch of features that regular scroll containers don't get, and because they work automatically, most developers aren't aware of them.

It's easy to accidentally stop using the root scroller, and hard to notice when you have. Your 'page' still scrolls (visually at least) and you don't get any errors, but your site misses out on some features and that can make the user experience worse.

In this article we'll go over what the root scroller is, how it's different from other scroll containers, and how to fix it when you've accidentally opted out of it.

A scroll container is any element that lets you scroll through content that doesn't fit inside it (which sometimes is referred to as overflowing content).

An element becomes a scroll container when you give it an overflow value of auto, scroll or hidden and fixed (explicit height or width) or constrained (like max-width, grid areas or flex constraints) dimensions. Overflow set to auto and scroll means users can scroll it with the mouse (and keyboard, when focused). With hidden they can't, but it's still a scroll container, and you can still scroll it programmatically.

When a scroll container sits inside the page or inside another scroll container, it's called a nested scroll container.

Try the different overflow values below to see how they affect the scroll container behavior.

overflow

ScrolledNot a scroll container

This box has a fixed height of 150px, so this text overflows it.

Change the overflow value above and see what happens to the overflowing content.

With hidden you can't scroll it with your mouse or keyboard, but it's still a scroll container. Click the "scroll programmatically" button to see it scroll.

This is the last line, overflowing the container.

When your content is taller than the viewport, the entire viewport becomes a scroll container. The specs call this the viewport's scrolling box, but browser engineers refer to it as the root scroller, and that's the name we'll use here.

The browser knows what the root scroller is, and document.scrollingElement returns the element that represents it:

document.scrollingElement;

In standards mode this is the <html> element and in quirks mode it's <body>. That never changes for a given document, so document.scrollingElement is mostly just a convenient way to access the root scroller without having to check both elements or parsing the doctype.

When dealing with the html and body elements, the browser sometimes applies styles and overflow behavior differently than it would for other elements: styling sometimes gets propagated to the viewport rather than being set on the element itself. This propagation was introduced to ensure that the viewport reflects the intended styles even when the html and body elements do not fill the entire viewport.

One that you might have encountered before is that adding a background to body will add it to the entire viewport even if body doesn't fill the full height. The background is "pushed back" to the root scroller.

That is, unless you also have a background set on the html element, in which case that background is applied to the viewport, and the one you set on the body behaves like a normal background. Try it out for yourself below:

The same happens to other properties that affect layout and scrolling. That propagation behavior is not something you commonly need to care about, but being aware of it can save you a few head scratchers.

The overflow CSS property controls how overflow works, and so creates scroll containers. The value set on <html> doesn't apply to the element itself but is propagated to the viewport. If <html> has the default value overflow: visible, the overflow value of <body> is propagated instead. We'll need this rule later on.

There is nothing wrong with using nested scroll containers. Browsers treat them as independent elements with their own scrolling context, and a user can scroll them without affecting the rest of the page.

Sometimes though, you accidentally create a nested scroll container that encompasses the entire viewport. When you do that, a mouse wheel or touch scroll will scroll the nested container. When that happens, you lose special behavior given to the root scroller:

Scroll restoration. When someone navigates back to your page, browsers restore the scroll position of the root scroller. Support for restoring nested scroll containers is inconsistent, so users often end up back at the top instead of where they were.
Keyboard scrolling. Space, Page Down and the arrow keys scroll the root scroller by default. A nested scroll container needs to be clicked or focused into first.
window.scrollY and scroll events on window only report the root scroller. Methods like window.scrollTo(), window.scrollBy() only apply to the root scroller. So anything that relies on these for getting and setting the scroll position will not work correctly with nested scroll containers.
Printing and screenshots. Printing uses the height of the root scroller. A page locked to the viewport height prints as a single page and cuts off the rest. Full-page screenshots have the same problem.

On mobile specifically

Though scroll-restoration is annoying everywhere, mobile browsers include more scroll-specific functionality that depends on the root scroller, and it's where things will feel more 'broken' as users interact with your website.

Mobile browser UI. On phones the address bar and toolbar collapse when the root scroller scrolls. With a nested scroll container they stay visible, so your users have less screen space. (Mobile browser UI has a few more quirks, which we covered in using safe-area-inset to build mobile safe layouts.)
Tap to scroll to top. On iOS, tapping the status bar scrolls the root scroller to the top. It does nothing for nested scroll containers.
Pull to refresh and overscroll. These also only work on the root scroller.

The example below simulates these behaviors, toggle between the root and nested scrollers and see the difference when doing those actions above: scrolling to move the browser UI out of the way, clicking the top bar to scroll back to the top, and pulling down to refresh the page. When scrolled, reloading the page with the reload button will also restore the scroll position for the root scroller, but not for the nested scroller.

Card 1

Card 2

Card 3

Card 4

Card 5

Card 6

Card 7

Card 8

Card 9

Card 10

Card 11

Card 12

Card 13

Card 14

Card 15

Card 16

Card 17

Card 18

Card 19

Card 20

How you accidentally opt out

The most common version is adding an app shell or 'wrapper' like this:

html,
body {
  height: 100%;
  overflow: hidden;
}

.page-wrapper {
  height: 100vh;
  overflow: auto;
}

When you look at your page it still looks the same, but you can see that the dashed border i added around body is fully visible at the bottom, while you would expect it to be pushed down by the content.

scroll containerscroll to find out

The content still scrolls, but it's .page-wrapper that is scrolling instead of the viewport. This is usually done on purpose, for a fixed header and sidebar with a scrolling content area, a sticky footer layout, or to prevent the page from scrolling behind a modal. Sometimes a framework sets it up for you.

The result is a root scroller that doesn't scroll, since that responsibility has been taken over by the nested scroll container.

Accidentally opting out with overflow propagation

Another common way to accidentally opt out of the root scroller is by setting that overflow-x property on both the html and body elements to prevent horizontal overflows, along with height: 100% to make the page at least as tall as the viewport and keep footers are where you want them. Variants of this can be found in many CSS boilerplates and frameworks.

html,
body {
  height: 100%;
  overflow-x: hidden;
}

Because of the propagation rule, the overflow of <html> goes to the viewport. Since <html> is no longer set to overflow:visible, the overflow of <body> stays on <body>. And when one axis is hidden, the other axis computes to auto. So <body> becomes a scroll container.

Now just the overflow-x: hidden declaration on <body> is not a problem. <body> still grows with its content because of its natural block layout and doesn't become a scroll container.

That is, until you give it a fixed height with height: 100%. Now <body> is only as tall as the viewport and <body> scrolls instead of the root scroller. Both declarations are common on their own, so it's easy to end up with the combination without realising it.

Try the example below to see how the overflow is both propagated to the viewport, and causes the default values to change. See if you can guess when you've opted out of the root scroller, then scroll to see if you were right.

scroll container…

propagated to viewport…

html {
  overflow-x: visible;
}

body {
  overflow-x: visible;
}

Scroll down your page a bit and run this in the console:

If this returns 0 while you've clearly scrolled, you've opted out of the root scroller and something else is scrolling. Here's that check side by side, for a root scroller and for a nested wrapper:

To find out which element is scrolling, listen for scroll events in the capture phase. Scroll events on elements don't bubble, but a capturing listener on the document does catch all of them.

Paste this into your console, then scroll:

document.addEventListener('scroll', (e) => console.log(e.target), { capture: true });

If it logs #document, the root scroller is working. If it logs an element like div.page-wrapper, that's your nested scroll container.

The Elements panel in Polypane shows a "scroll" badge next to elements that are scroll containers, so you can spot them while going through the DOM tree.

Starting in Polypane 31, elements that are currently being scrolled will have their scroll badge highlighted so you know exactly which element is handling the scroll.

To list all vertical scroll containers on a page at once, run this in the console:

[...document.querySelectorAll('*')].filter((el) => {
  const { overflowY } = getComputedStyle(el);
  return ['auto', 'scroll', 'hidden'].includes(overflowY) && el.scrollHeight > el.clientHeight;
});

Once you know what you're looking for, seeing it on a real phone is easy too. If the address bar doesn't collapse when you scroll, or tapping the status bar doesn't scroll you back up, the root scroller isn't being used.

Testing it in Polypane

Most of these issues only show up on touch devices, with a keyboard or when printing, so you won't see them with a mouse on a desktop viewport. But they'll still feel broken to users interacting with your site in those ways.

Test your pages at mobile sizes with touch events enabled using device emulation, try scrolling with only your keyboard, and run the capture listener above.

Another way it surfaces in Polypane

If you use Polypane, scroll syncing and full height screenshots can give it away too.

Polypane syncs the scroll position of all scroll containers, root and nested, across panes.

But if you accidentally create a nested scroll container at a specific breakpoint, for example by setting overflow inside a media query, the page is scrolled by the root scroller in some panes and by the newly created nested scroll container in others. Those aren't the same scroll container, so their scroll positions can't be synced.

If scrolling stays in sync between your desktop panes but your mobile pane doesn't follow along (or the other way around), check which element is scrolling in that pane using the methods described above.

For full height screenshots, Polypane takes the height of the root scroller to determine the total height of the page. If that's just a single viewport, then the resulting full height screenshot will be too.

You usually end up with a nested scroll container while building a specific layout. Each of these layouts can be built while keeping the root scroller, so let's go through the common ones.

Make the page fill at least the full screen

For example so the footer sits at the bottom of the screen on short pages. A common way to do that is to make a wrapper exactly as tall as the viewport and let the content scroll inside it:

html,
body {
  height: 100%;
  overflow: hidden;
}

.page-wrapper {
  display: flex;
  flex-direction: column;
  height: 100vh;
}

main {
  flex: 1;
  overflow: auto;
}

What you actually want is a page that is at least as tall as the screen, so use min-height instead of height and let the document grow with its content:

.page-wrapper {
  display: flex;
  flex-direction: column;
  min-height: 100svh;
}

main {
  flex: 1;
}

You also don't really need the overflow: hidden on html and body either. Using svh or dvh instead of vh also avoids the mobile issue where 100vh is taller than the visible area. We wrote more about the small viewport units when we added them to Polypane's device emulation.

We can go a bit further too, since you probably don't even need a dedicated wrapper element for the page at all. Remove the wrapper entirely and apply the min-height and flex properties directly to the body and main elements:

body {
  min-height: 100svh;
  display: flex;
  flex-direction: column;
}

main {
  flex: 1;
}

The body can be a wrapper just as much as a dedicated .page-wrapper element, simplifying your layout and keeping the root scroller intact by not restricting the height of the body element.

This is the app shell layout: a header at the top, a sidebar on the side and only the content area scrolling. It's often built as a grid that's exactly as tall as the viewport, with the content area as a scroll container. This fits a nice mental model of the viewport as a fixed frame. The web isn't a fixed frame though. The viewport is just that, a view into a part of the document.

You can keep the root scroller intact by using position: sticky and using a min-height on the sidebar to get the same layout. The page scrolls normally and the header and sidebar stick to the viewport:

scroll event targetscroll to find out

.app {
  display: grid;
  grid-template-columns: 100px 1fr;
  grid-template-rows: auto 1fr;
  height:100vh;
}

.header {
  grid-column: 1 / -1;
}

.sidebar {
  grid-row: 2 / -1;
}

.content {
  overflow: auto;
}

The sidebar can still scroll on its own if it's long (becoming its own scroll container). That's fine because it's a secondary scroll container, not the page itself. Content inside the main area will scroll with the page as expected.

If your sticky elements don't stick, check all the ways position: sticky can fail. For grid layouts, it's very easy to create that unexpected scroll container (making sticky elements not stick as intended) or to have the element not able to get stuck, because it stretches the full grid area.

Something on the page is wider than the viewport and causes a horizontal scrollbar, so you hide it:

html,
body {
  height: 100%;
  overflow-x: hidden;
}

As we saw earlier, when <body> also has a fixed height, this turns it into the element that scrolls the page because setting overflow: hidden in one direction automatically changes it from visible to auto in the other direction.

A quick solution is to use clip instead:

html,
body {
  height: 100%;
  overflow-x: clip;
}

clip cuts off overflowing content like hidden does, but it doesn't create a scroll container. The overflow of the other direction is still set to visible, and its contents will just overflow outside the body's height.

overflow-x	overflow-y
body		…

html,
body {
  height: 100%;
  overflow-x: hidden;
}

Quick fix vs. proper fix

This is a quick fix, but it isn't a good fix, since it hides the symptom (the bar is still overflowing).

Finding and fixing the element that causes the overflow is the better solution, and our article on strategies for dealing with horizontal overflows shows you how.

Polypane also detects horizontal overflow for you and highlights the element that causes it.

When a modal is open, scrolling inside it shouldn't scroll the page behind it. Some sites solve this by keeping the page in a wrapper with its own scroll container permanently, so they can lock the wrapper while the modal is open.

You only need to lock the page while the modal is open. With :has() you can do that in CSS:

html {
  scrollbar-gutter: stable;

  &:has(dialog[open]) {
    overflow: hidden;
  }
}

Hiding the scrollbar can make the page shift sideways, so we add scrollbar-gutter: stable to html to keep the space reserved.

Toggle the lock off and try scrolling behind an open dialog — then turn it back on:

Toggle scroll locking on the HTML

dialog openno

html overflow-yvisible

scrollY0px

Though most of this article is spent explaining how to avoid creating unwanted scroll containers, there's plenty of situations where you'll want to use them (like the scrollable sidebar in the example above, or a chat window).

What you want to avoid is accidentally creating a scroll container that covers your whole viewport, but there are plenty of other places where nested scroll containers are perfectly fine.

If you want to understand how scroll containers fit in with the rest of CSS layout, read understanding the fundamentals of CSS layout.

Use the root scroller for the main page

I hope this article has helped you understand why using the root scroller for the main scrolling area of your page is important and beneficial for your visitors, and helped you get a better grasp of managing scroll behavior in your own projects.

Check out some of the tools in Polypane to help you check and manage scroll behavior effectively:

The code snippets above executed in our console panel make it really easy to catch differences introduced by media breakpoints, and help you make more resilient websites.
With the device emulation in Polypane, you can see how your page behaves across different screen sizes and orientations, ensuring that the root scroller remains consistent and effective.
The elements panel in Polypane allows you to inspect and manipulate the DOM, making it easier to understand how scroll containers are applied and how they affect your layout.

By combining these tools, you can confidently manage scroll behavior and create more robust and user-friendly web experiences.

Build a digitally sovereign second brain

2026-09-08T10:00:03Z

We thought we’d go big this Maker Monday, what with it being the serious business of Back to School and all. Here’s a tutorial from the latest issue of Raspberry Pi Official Magazine that shows you how to keep everything in your brain organised and searchable, from notes to appointments and ideas.

A while ago, we read the book Building a Second Brain by Tiago Forte (Figure 1). It starts with the idea that we are all a little overloaded and bombarded with information, and how overwhelming it can be to not be able to retrieve the information that we need at a later time. The foundation of a Second Brain is to increase the capture and cataloguing rate of information, and the book delves into lots of custom systems to tag, organise, prioritise, and retrieve information. This Personal Knowledge Management (PKM) idea feels similar to the ideas of David Allen and the older, but still brilliant, ‘Getting Things Done’ system.

Logseq running on Raspberry Pi OS; this is a ‘graph view’ that shows all your tagged information, along with the connections between the tags

At the heart of these PKM systems is the concept of ubiquitous capture: the idea that, as a start, we need to capture the information of interest. This is also an idea in journalling and is basically being proactive about note-taking. The question then is how to store these bits of information. There are lots of options.

The end of sticky notes

There’s nothing wrong with a pile of sticky notes (or index cards, which are the author’s favourite) and a pen; however, you can quickly end up with a huge pile of notes which need to be physically stored and searched. Of course, lots of people have moved to software applications. Many of the popular operating systems for mobile devices will include some form of note-taking application, and there are many that require you to make an account and store your data in the cloud, so it’s a nice challenge to build a system that doesn’t store your information on another person’s computer. Finally, the solutions we explore here use open source projects so we can examine the code should we need to maximise our privacy and security.

Figure 1: Inspired by the Tiago Forte book Building a Second Brain, it’s quite possible to create a personal knowledge management system across Raspberry Pi devices

The solution we are going to explore is centred around Logseq, a privacy-focused open source knowledge management system. It’s a really rich piece of software with more features than most people will use, and we’ll only really cover the basics, although the basics are incredibly powerful. Later in the article we’ll use Syncthing, another open source project, to synchronise our second brain created in Logseq across multiple devices. Syncthing is a peer-to-peer continuous file synchronisation tool, which means that it can sync data without passing that data through the cloud/a company’s server. It also encrypts and decrypts the data in transit, so you are nice and secure whilst the data is moving. It’s totally OK to just install Logseq on one machine and have a play with it to see if it can meet your needs.

Figure 2: A Raspberry Pi 500 is a good target for your first attempt at installing Logseq and Syncthing

We began by installing Logseq on a Raspberry Pi 500 (Figure 2), but note that the procedure outlined below is the same for any Raspberry Pi board; so, for example, we have this system currently set up on the Raspberry Pi 500, a Raspberry Pi Zero, and our Uconsole, which contains the Raspberry Pi Compute Module 4 board.

Currently, the only option to install a build of Logseq is via Snap. So, if working from a fresh Raspberry Pi OS installation, we’ll need to install the Snap package manager. If you already have Snap installed on your system, then you can skip to installing Logseq.

To install Snap and then Logseq, open the Terminal application and, at the prompt, enter:

$ sudo apt update

We can then install the latest version of Snap using:

$ sudo apt install snapd

We then need to reboot Raspberry Pi 500:

$ sudo reboot

Once the machine has rebooted, open the Terminal application; we need to install a Snap package called ‘snapd’:

$ sudo snap install snapd

With Snap installed and set up, we can then go ahead and install Logseq using:

$ sudo snap install logseq –channel =og

With Logseq now installed, you will be able to launch it using the desktop applications menu at Accessories > Logseq Desktop. On launch, Logseq will open a demo page showing a journal-style entry for the current date (Figure 3). In this entry is a basic tutorial on how Logseq works and some of its functions.

Figure 3: When you first open Logseq, you land on an informative demo page

In Logseq terminology, when you create a collection of notes and potentially other assets, you insert them into a ‘graph’. Scrolling on the current demo page, you should find a section where Logseq wants us to specify a folder it can use to contain all our information. You can use an existing folder, but it’s probably better to create a new folder. Click to ‘add a graph’ and then give your folder the title that you want your second brain system to be called; we went with ‘2nd_Brain’, rather unimaginatively. This OG version of Logseq will, in this specified folder, store all the data you input into the system. It essentially creates Markdown files and also stores any uploaded assets (PDFs, pictures, audio, etc.) to an assets subfolder. This means that you could manually copy this entire folder, move it to another machine, and open it in another installation of Logseq.

Filling the brain with information

With the file specified and a new graph created, let’s put some basic information into our second brain system. Whenever you open Logseq, it will create an empty journal page for the current day. Each of these journal dates will become a page item in our system. So let’s type something in the currently empty journal page.

As an example, we typed a note: ‘Spotted a book I’d like to read today, called “How to Build a Second Brain” by Tiago Forte’ (Figure 4). Now imagine we wrote a note about a different book every day. Currently the only way to return to this piece of information in the future is if we remember the date or use the search function. If we’d forgotten the name of the book, however, we could only really search for terms like ‘book’, which might generate a lot of returned results. What we need is to tag our information. Tagging is the secret sauce of Logseq that makes it incredibly useful.

Figure 4: Adding a note without a tag is fine, but the only way to rediscover that tag is to either remember the date it was made or the exact contents

To add a tag to a piece of information, we place the tag term inside two pairs of square brackets. Let’s return to the line we entered earlier and write at the end of the line (though tags can be placed anywhere in text) ‘[[Books To Read]]’ and then press ENTER. Note that the tag text will become a clickable link (Figure 5). If we click that tag, the link then takes us to a new page, as every tag we add to Logseq becomes a new page. On the new [[Books To Read]] page, we will see the reference to our line, ‘… “How to Build a Second Brain” by Tiago Forte’. If we click the back arrow in the upper toolbar, we can navigate back to our journal. Let’s add a second line, ‘Another book I’d like to read, “Design an RP2040 Board with KiCad” by Jo Hinchliffe’. This line will always be listed in the current journal page, but again we can add the [[Books To Read]] tag as we did previously and it will be populated to that tag page. If we write a book title every day into separate journal entries, so long as we use the [[Books To Read]] tag, they will all appear on the tag page (Figure 6). Note that in the image we made a typo in the book title; in a way, this doesn’t matter — just be sure to spell your tags correctly!

Figure 5: Adding a tag creates a new page for each tag in which tagged information is listed and linked

However, tags are free and unlimited, so it’s worth tagging information widely with lots of tags, thinking about how you might remember them in the future. As an example, in our second brain Logseq setup, we have some Customs and Excise tariff numbers; these numbers are unique for different types of goods that you sell, and it can be quite hard when faced with a new item to research and identify the correct tariff number as they are quite complex and there are a lot of them. It’s definitely the type of information you want to keep note of rather than have to discover every time. If we consider how we might think about these numbers, it’s pretty clear to tag them as [[Tariff]], but sometimes we might think [[Customs]] or might want the tariff number for a particular product or project, so we might use the [[Product Name]] as a tag. Adding multiple tags to items of information increases your chances of finding your way back to the info when needed, as the same piece of information will appear regardless of which tag you remember or use in the future.

Figure 6: The ‘Books To Read’ tag page begins to collect all the inputs listed with that tag

We need to move on to other aspects of the system, but it’s worth noting that you can type ‘/Upload an asset’ (or rather start by writing ‘/U’, which will autocomplete) to add files of pretty much any type to an entry. You can then tag these in the usual way, and the asset will be copied to the assets folder in your designated directory. This means you don’t have to worry about copying and pasting items, or losing links to items, as they are all stored in the folder. Finally, note that you can embed links and videos, and even highlight and annotate PDFs, in Logseq, tagging the exact part of a PDF to return to later.

Figure 7: Syncthing Web UI is the admin console for Syncthing, allowing you to connect devices and share directories and files

So we have the basis of our second brain setup, but we’d like it to be accessible on more than one device. Our approach for this will be to install Logseq on another device, and then use Syncthing to synchronise folders so that our second brain folder is on both devices and up to date (Figure 7).

To install Syncthing on Raspberry Pi, it’s best to first run:

$ sudo apt update

$ sudo apt upgrade

…to make sure our system is up to date. Then we need to add the ‘apt-transport-https’ package to the apt service by running:

$ sudo apt install apt-transport-https

We then need to store the Syncthing GPG keys on Raspberry Pi in our keyrings directory. In a nutshell, this means that the Syncthing packages we install are legitimate and are sourced from the right place. To do this, run the following command:

$ curl -s https://syncthing.net/release-key.txt | gpg --dearmor | sudo tee /usr/share/keyrings/syncthing-archive-keyring.gpg >/dev/null

We can now add the Syncthing repository with:

$ echo "deb [signed-by=/usr/share/keyrings/syncthing-archive-keyring.gpg] https://apt.syncthing.net/ syncthing stable" | sudo tee /etc/apt/sources.list.d/syncthing.list

We can then update the packages once again with:

$ sudo apt update

And then finally install Syncthing with:

$ sudo apt install syncthing

Once it’s installed, you will find two Syncthing items in the applications menu: one is a simple ‘Start Syncthing’ which sets the service running; the other is ‘Syncthing Web UI’. First, double-click the ‘Start Syncthing’ application, then double-click the ‘Syncthing Web UI’. This should now launch the default web browser and will land on a default Syncthing admin page for the device. From here, we can set up files and directories for synchronisation.

Figure 8: Adding folders you want to synchronise in the Syncthing Web UI

First, let’s click the ‘Add Folder’ button. In the ‘Add Folder’ dialog box (Figure 8), we can add a folder label — for example, ‘second_brain_directory’, as we are going to share the directory we made for our Logseq second brain files. Leave the Folder ID with the default generated identifier string, and then in the last input, Folder Path, set the exact folder path to match where the Logseq folder you made is. So for example, if you made your Logseq folder in the default user directory of a Raspberry Pi and you called it ‘2nd_Brain’, you can input the tilde (~) character (which means the same as /home/username) and write ~/2nd_Brain. Clicking Save sets this file to be shared.

Figure 9: Adding devices to your Syncthing setup is straightforward

On another device with Logseq and Syncthing installed (we used our Uconsole), on the same Web UI page you can click on the short name identification in the ‘This Device’ area. Clicking this launches a dialog box with a QR code and a long-form ID string for the device (Figure 9). This is a 56-digit string with dashes. Back on the Raspberry Pi 500, you can click the ‘Add Remote Device’ button and type in the long device ID; note that you don’t need to add the dashes or spaces, just the long string. If you leave the Device Name section empty, it will populate with the random generated device name on the other device; or you can add a more descriptive name such as ‘Uconsole’ or ‘Pi Zero’ here.

Quick tip

Note that you don’t have to be on the same network for Syncthing to synchronise your files.

Finally, by clicking on the folder we created to share earlier on the Raspberry Pi 500, and then clicking the Edit button, we can move over to the Sharing tab in the dialog box, where we should be able to see the remote device we just added (Figure 10). If we tick the box to share with that device, we can then click Save. Give everything a couple of minutes to work through the networks and then check on the other device; you should see a notification that the other device wants to share a folder with you. Accept the folder and follow the instructions to set up a path to a directory to synchronise that folder to. All that then remains is to open Logseq on the second device and click ‘add graph’, navigating to the synchronised folder we just made. This means if we add or change anything in Logseq on our first device (Raspberry Pi 500) or our second device (Uconsole), then these changes appear on both devices, keeping our Logseq second brain system up to date. You can of course repeat this process, sharing and synchronising your 2nd_Brain Logseq folder onto as many devices as you want.

Figure 10: Editing a file setting to share with specified devices

Careful now!

Note that synchronising folders is not a backup! If you accidentally delete part or all of your Logseq folder content, this will propagate through Syncthing and delete it everywhere! A solution to this is to, on one or more devices, set up a system that periodically backs up your folder to another folder.

To do this, we will create a small Bash script that will copy a target folder to a different folder that we won’t sync. We’ll then use the cron service to make this script run periodically so that we don’t have to think about it. You can do this on any of the Raspberry Pi devices, or indeed more than one; however, it would be most useful on a device which can be left always on. In our system, we have it set up on a Raspberry Pi Zero W which runs headless and is an ‘always on’ device in our workspace. However, we’ll set this up here on the Raspberry Pi 500, as it’s easy to do by typing commands into the terminal.

To begin, launch the Terminal application, and in the root directory of your Raspberry Pi device, launch the nano text editor to write a Bash script:

$ sudo nano

In nano, type the following small Bash script, replacing LOGSEQ_Directory_Path with the path to your Logseq folder. If your folder is in the home directory, you don’t need any leading edge slashes; so, backing up our ‘2nd_brain’ folder in the home directory to ‘backup_2nd_brain’ is really straightforward to input.

#! /bin/sh 

rsync -avh LOGSEQ_Directory_Path
Backup_Directory_Path

Save this file with a name like backup_script.sh.

We need to set this file as executable, so in the same working directory as the script, we need to run:

$ sudo chmod +x backup_script.sh

We can now test the backup_script.sh script by, in the same directory, executing it with:

$./backup_script.sh

You can then use the File Manager (or the Terminal) to check if the files have been copied to the newly created backup folder. Finally, we can automate this script using a cronjob. We can do this by editing a file called crontab. Type:

$ crontab -e

…in the terminal. If this is the first time you have done this, it might ask which editor you would like to use; select nano from the list. In the now-open crontab file, there is a long section of comments that give a great overview of how the cron system works (Figure 11). At the end of the file, we can add a line that has the following structure: minutes, hour, day of month, month, day of week, followed by the command. You can leave slots empty using an asterisk (*) so you can construct values for different automated periods. So, for example:

46 10 * * 1 /home/concretedog/backup_script.sh

…would execute the backup_script.sh script every Monday at 10.46am. Note that if you wanted to run the script once a day, you’d simply leave the day of week value empty, such as:

30 10 * * * /home/concretedog/backup_script.sh

Of course, you can extend and enhance the system; it would be great to back up the folders to an attached SSD, or you might like to explore how to add monitoring and logging to your cron system. Logseq and Syncthing are available for most desktop distributions, and they are also ported to smartphone operating systems, meaning you can carry your private, secure, and backed-up second brain with you always!

Figure 11: Setting up crontab to create a periodically repeating job

Find more Raspberry Pi projects in Raspberry Pi Official Magazine

This article appears in issue 169 of Raspberry Pi Official Magazine, which you can access online. You can also subscribe to the print version of our magazine. Not only do we deliver worldwide, but those who sign up to the six- or twelve-month print subscription will receive a FREE Raspberry Pi Pico 2 W!

You can find Raspberry Pi Official Magazine on Facebook, X, Threads, LinkedIn, and Mastodon. You can also contact the team via email: magazine@raspberrypi.com

AI Software Development - What Does The Data Say? - Codemanship's Blog

2026-08-12T19:34:21Z

AI Software Development – What Does The Data Say? – Codemanship's Blog

AI Software Development – What Does The Data Say?

I’m currently pulling together a bunch of sources – that are mostly recent – on the topic of LLMs and their use in software development.

Some are peer-reviewed studies. Some are industry studies that haven’t been peer-reviewed.

One is statistical physics. Expect more from that angle. Wanna’ know the limits of a technology? Ask a physicist.

One is just a blog post, but very useful information about the effect of context size.

Most are corroborated by personal experiments and also observations on teams. As time goes on and more data comes in, my picture comes more into focus.

Code Evolution & Long-Horizon Agentic Workflows

SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration
https://arxiv.org/abs/2603.03823

SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks
https://arxiv.org/html/2603.24755v1

SWE-Milestone: Evaluating AI Agents on Continuous Software Evolution
https://arxiv.org/abs/2603.13428

Context Engineering

Context Is What You Need: The Maximum Effective Context Window for Real World Limits of LLMs
https://arxiv.org/abs/2509.21361

Beyond RAG vs. Long-Context: Learning Distraction-Aware Retrieval for Efficient Knowledge Grounding
https://arxiv.org/abs/2509.21865

Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?
https://arxiv.org/abs/2602.11988

(blog post – informational, not peer-reviewed research)
The Hidden Science Behind LLM Token Limits (And How Million-Token Models Actually Work)
https://www.ashisharora.ai/post/the-hidden-science-behind-llm-token-limits-and-how-million-token-models-actually-work

Language models are not naysayers: An analysis of language models on negation benchmarks
https://arxiv.org/abs/2602.11988

Rethinking the Role of Demonstrations: What Makes In-Context Learning Work?
https://aclanthology.org/2022.emnlp-main.759

STALE: Can LLM Agents Know When Their Memories Are No Longer Valid?
https://arxiv.org/abs/2605.06527

Task Matters: Knowledge Requirements Shape LLM Responses to
Context–Memory Conflict
https://aclanthology.org/2026.findings-acl.202

(I call these “dominant priors”, when information in the model overrides that provided in the context)

Large-scale Industry Studies in Software Engineering

What 28 million workflows reveal about AI coding’s biggest risk (CircleCI)
https://www.linkedin.com/pulse/what-28-million-workflows-reveal-ai-codings-biggest-risk-circleci-j9syc/

The Acceleration Whiplash – AI Engineering Report 2026 (Faros)
https://www.faros.ai/research/ai-acceleration-whiplash

State of AI-assisted Software Development 2025 (DORA)
https://dora.dev/research/2025/dora-report/

Psychology, Cognition & Learning

Super-intelligence or Superstition? Exploring Psychological Factors Influencing Belief in AI Predictions about Personal Behavior
https://arxiv.org/html/2408.06602v3

The Impact of Generative AI on Critical Thinking: Self-Reported Reductions in Cognitive Effort and Confidence Effects From a Survey of Knowledge Workers
https://arxiv.org/html/2408.06602v3

Experimental evidence of the effects of large language models versus web search on depth of learning
https://arxiv.org/html/2408.06602v3

At What Cost? Software Developers’ Well-Being in the Age of GenAI
https://ourarchive.otago.ac.nz/esploro/outputs/preprint/At-What-Cost-Software-Developers-Well-Being/9926870122801891

Limits of LLMs & Deep Learning

The wall confronting large language models – (statistical mechanics study)
https://arxiv.org/abs/2507.19703

Learning long-term dependencies with gradient descent is difficult
https://pubmed.ncbi.nlm.nih.gov/18267787/
(Why deep neural networks can’t see the bigger picture, at any scale of model)

What are the implications for teams using this technology? If you’re interested in a hype-free, evidence-based take about why the technical practices of Agile Software Development are so closely aligned with AI-assisted and agentic software engineering, join me on October 6th at 18:45 BST.

Register: https://www.tickettailor.com/events/codemanship/2324138

Author: codemanship

Founder of Codemanship Ltd and code craft coach and trainer View all posts by codemanship

Cloudflare OS is an architecture of distrust

2026-08-10T09:21:28Z

The strangest thing in the Cloudflare OS source code took me a while to understand.

When an agent inside Cloudflare OS wants to do something with a side effect (merge a pull request, send an email, write a row to a system of record), it goes through a Gatekeeper, a small service that holds the credential and mediates the action. So far, that’s just a well-built MCP server. But read the contract a Gatekeeper is written against (packages/workshop-shared/src/gatekeeper.ts, around line 617) and you find this instruction to the author:

It is suggested that the gatekeeper “simulate” actions that have not been approved yet, that is, the Session interface should reflect the state of the resource as if all actions had been applied.

Sit with that. The agent asks to merge the PR. The human hasn’t approved it. So the Gatekeeper tells the agent the PR is merged, and if the agent reads the branch back to check its work, hands it a fabricated reality in which the merge happened. The agent, satisfied, queues the next three steps that depend on it. None of it is real. Later a human looks at the batch and either commits it or bins it, and if they bin it, everything the agent built on the fiction goes too.

The first time I traced this I thought it was a hack. It’s the philosophy of the whole system, compressed into one method signature. The Gatekeeper lies to the agent on purpose, because the alternative (letting an agent’s actions touch the world the moment it decides to take them) assumes the agent’s decisions are sound. Cloudflare OS is built from end to end on the assumption that they are not.

The name is a distraction, so set it aside. The Hacker News thread spent most of its energy arguing about whether “OS” is a permitted word for the thing, and that’s a dead end. What’s actually interesting is that a team led by Kenton Varda, the people who built the Workers runtime, sat down to design a platform for AI agents doing real work inside a company, and the organising principle they landed on was this: the agent cannot be trusted, so build so that its mistakes cannot matter. Every load-bearing part of the system is a variation on that sentence.

Last week I wrote about Opus 5 getting things confidently, quietly wrong: shipping a change that reported success while doing the opposite, caught only on a second pass. This is what it looks like to take that failure mode not as a grievance but as a permanent design constraint, and pour concrete on top of it.

Make the code irrelevant to safety

Start with the sandbox, because everything else stands on it.

When you make a slide deck in Cloudflare OS, you aren’t using one shared slide-deck app. The system spins up a private instance of the slide-deck code, a “gadget”, that belongs only to you. It runs in its own Dynamic Worker, with its own SQLite database behind a Durable Object Facet, outbound networking switched off. Every document is its own sandboxed process.

This is Sandstorm, Kenton’s startup from a decade ago, reborn. What Sandstorm got right and could never make cheap was fine-grained instancing: every document in its own isolation boundary. Containers made that far too expensive, seconds of cold start and hundreds of megabytes per grain, so the idea sat on a shelf for ten years until V8 isolates made it roughly a hundred times cheaper to run. I wrote a book about this platform and called Durable Objects its most underappreciated primitive; the thing they were waiting to enable, it turns out, was this.

Per-document instancing changes where security lives. For twenty-five years the boundary in multi-tenant SaaS has run straight through the application code. One shared service holds everyone’s data, and a single mistake in a WHERE clause, one missing tenant_id, leaks customer B’s records to customer A. The code is load-bearing for security. It has to be correct, and a junior engineer’s off-day is a breach.

Cloudflare OS moves the boundary out of the code and into the platform. If every user has their own instance, and the platform controls who can reach an instance at all, a bug in the gadget can only hurt the one person who owns it. Kenton puts it flatly: the AI cannot introduce a significant security bug. He’s right, in the sense that matters. A gadget can’t leak to another user however badly it’s written, because there is no other user in its sandbox to leak to.

This is the first and boldest act of distrust. They didn’t make the AI’s code trustworthy. They gave up on that and made it irrelevant, arranging things so the correctness of what the agent writes is no longer a security property at all. You can let a non-technical colleague vibe-code an app and share it, and the reason the security team sleeps is not that the app is good. It’s that a bad app can’t reach them.

Never let the agent hold the key

The cleverest move is the quiet one.

The obvious way to give an agent access to GitHub is to give it a GitHub token. Anyone who has wired up an MCP server has done some version of this, and felt the small cold moment of realising a token in a prompt can end up anywhere the prompt’s output goes.

Cloudflare OS never gives the agent the credential. The Gatekeeper holds it. What the agent gets is a capability: in the generated code it appears as a binding, env.PROJECT, an object it can call methods on. Not the key itself, but permission to perform a specific, narrowed set of operations the Gatekeeper will carry out on its behalf. Give the GitHub Gatekeeper a single repository and it can let the agent read issues but not source, mask fields, refuse to merge without approval. The agent can call listIssues(). It cannot see the token, widen its own access, or reach the network except through capabilities it was explicitly handed.

None of this is theoretical to me. I built exactly this credential-broker pattern for CDS, and it has since rolled out across the engineering practice there: the broker holds the secret, the agent gets a handle and never the key itself.

This is the object-capability model, and it isn’t decoration. It’s the Cap’n Proto lineage Sandstorm was built on, resurfacing as Cap’n Web RPC, because a capability is the only kind of authority you can safely hand an actor you’ve decided not to trust. A key is bearer authority: whoever holds it wields it. A capability is a leash. It does one thing, it can be revoked, it stays attached to whatever granted it. If your agent might be confidently wrong, or prompt-injected, or just careless about what it writes into an app’s source, the credential is the one thing it must never touch. So it never touches it.

Let it act, but never let it commit

Now the simulated merge from the opening makes sense: the same idea, moved from access into control flow.

The problem it solves is one I’ve felt every day for a year. Synchronous approval is miserable. The agent stops on step one, you’ve wandered off to make coffee, you come back to no progress. So people cave and turn on auto-approve, or --dangerously-skip-permissions, and the safety mechanism they installed to sleep at night is the first thing they switch off to get anything done.

Cloudflare OS splits acting from committing. Reads flow: a read is authorised against the capability and recorded, but it doesn’t stop for a human. Writes are provisional. The Gatekeeper accepts the action, simulates the result, and lets the agent race ahead building whatever depends on it, while the real effect sits in a queue for a person to release in a batch, later, when it suits them. The agent gets the throughput of auto-approve; the human keeps the veto of manual review. The human is no longer an interruption in the loop. The human is the commit.

It’s optimistic concurrency for actions in the real world, with a person as the transaction monitor, and it has the property optimistic concurrency always has: the agent spends part of its life operating on a state that isn’t true yet and may never be. It reads back its own un-happened writes and reasons about them. The architecture’s answer to “isn’t that dangerous?” is a shrug. It doesn’t matter what the agent believes about a world no human has ratified. Belief is free. Only the commit is real, and the agent doesn’t hold the commit.

Distrust the outputs, not just the actions

The subtlest move is the one the blog post almost entirely hides.

The first three mechanisms distrust what the agent does. This one distrusts what it produces. An agent reads a sensitive revenue table and builds a live dashboard from it. The dashboard is a new artefact with no access list of its own. Share it, and you may have just handed the table to everyone who can see the dashboard: a leak no single component did anything wrong to cause.

So Cloudflare OS records every observation a gadget makes. The mechanism lives in docs/observers.md, and it is, in essence, decentralised information-flow control: the academic dream of the mid-2000s, the Jif and HiStar and Flume line of work that never shipped commercially because labelling every piece of data by hand cost more than it returned. When Alice shares a gadget with Bob, every Gatekeeper the gadget has touched is asked, independently, whether Bob may directly read everything the gadget has already read through it. If he can’t, he’s refused. From then on, any new read the gadget makes that Bob isn’t cleared for is blocked outright.

The detail I keep turning over is that the kernel refuses to understand identity. The overseer, the “kernel” in the repo’s own OS analogy, does not know what a GitHub user is, or a Google user, or what any vendor’s permissions mean. It hands each Gatekeeper an opaque token minted by the observer’s own account and lets the Gatekeeper be the sole authority on its own resource. The code goes out of its way to make that handle a random string, so no Gatekeeper author is tempted to parse identity out of it. Authority is decentralised on purpose. The centre is built to know as little as it can.

Where the policy engine can’t yet express the nuance, it falls back to raw distrust. A flag, prohibitAllSharing, marks data so sensitive it must never leave the owner. Once a gadget reads something wearing that flag, it drops into “lockdown mode”: it can still read, but it can no longer take a single action, through any Gatekeeper, ever, in case the action is what smuggles the secret out. A taint bit. A one-way door. The bluntest instrument available, and the comment above it says so and calls it a stopgap. What DIFC never had a good enough reason to ship for, an autonomous agent supplies: you cannot hand-audit what a thing read when it reads a thousand times an hour and reasons about all of it at once.

A tell in the contributing guide

The worldview surfaces in an odd place. CONTRIBUTING.md asks you, politely, not to send pull requests longer than a dozen lines or so, and says why: AI has made writing code cheap, so an outside contribution donates the easy part while creating the expensive part, which is review and keeping the whole thing coherent. They would rather you didn’t.

There’s a real claim buried there. The scarce resource in software has inverted. Producing code is no longer the bottleneck; vouching for it is. And it’s the same reflex as everything else in the system. An unreviewed contribution is untrusted input, and it barely matters whether a careless human or a confident model produced it: the instinct, now written into the project’s own governance, is to keep unvetted work out until someone accountable has looked at it. They’ve generalised their distrust of the agent into a distrust of the contribution, and then into a policy about you.

Is this wisdom or a cage?

I’ve read a lot of agent frameworks this year, and most are optimistic in a way that embarrasses them within a month. This one isn’t, and I admire it for that. It’s the first agent platform I’ve seen that treats the failure mode as real instead of writing a longer system prompt and hoping. If you believe, as I’ve come to, that the models are confidently wrong often enough that their self-reports can’t be load-bearing, then an architecture that assumes exactly that isn’t cynicism. It’s honesty.

But an architecture built on the premise that the worker can’t be trusted also caps what the worker is allowed to become. An agent that can never hold a credential can never do the job that truly needs one. A write that is always provisional means a human is always, structurally, in the loop: the precise bottleneck agents were meant to remove. Every act of distrust here is also a leash, and the leash that keeps the animal safe is the one that stops it pulling the cart very far. You can’t design for maximum autonomy and maximum containment at once. Cloudflare has chosen containment, hard, betting that a caged agent doing real work beats a free one you daren’t deploy.

And there’s one thing the distrust never turns on. The agent is untrusted. The user’s code is untrusted. The human contributor is untrusted. Every principal is held at arm’s length and made to earn each move through a capability. Every principal except Cloudflare, whose primitives are the arm. The observation log, the Gatekeepers, the sandbox that makes the whole thing safe are all Workers, Durable Objects, Facets, some added to the runtime for this and existing nowhere else. It runs on workerd, which is open source, and you can self-host it, which is more than most of its rivals can say. But the architecture that trusts no one rests entirely on trusting the one party that poured the ground beneath it.

Last week a model told me it had fixed something, and it hadn’t, and I only found out because I went and looked. Cloudflare has built a whole operating system on the certainty that it always will (that the thing you delegate to will report a success it hasn’t earned), and then arranged matters so that when it does, a human holds the only pen that writes to the world. Whether that’s the shape of all serious agent infrastructure from here, or a very elegant set of walls we’ll spend three years learning to resent, I can’t tell. Probably both. The kernel table in the README has a row for processes, a row for users, and a row for agents left blank, marked only ???. They know it’s a new kind of thing. They just don’t trust it yet.

SSD Streaming for AI Models: How to Turn RAM from a Wall into a Dial

2026-08-07T10:58:44Z

When RAM Becomes the Bottleneck, Not the Solution

If you’ve ever tried running a large language model locally, you’ve probably hit the same wall. You find a model you want to use — maybe a Mixtral variant, a DeepSeek model, or something else with real capability — check the requirements, look at your available RAM, and discover you’re about 20GB short. The model doesn’t run at a reduced quality. It just doesn’t run.

That binary outcome is the core frustration of local AI deployment. RAM has always functioned as an on/off switch: either the whole model fits, or nothing works. SSD streaming flips that logic entirely. By storing model weights on disk and loading them on demand, it turns RAM from a fixed ceiling into an adjustable dial. Dwarf Star is one of the more interesting implementations of this idea, specifically targeting the expert weights in Mixture of Experts (MoE) models.

This article explains how SSD streaming works, why MoE architectures make it practical, what trade-offs you’re accepting, and who actually benefits from it.

The Real Problem with Running Large Models Locally

Most people frame the local AI problem as “my computer isn’t powerful enough.” That’s not quite right. The more precise framing is: model weights have to live somewhere your processor can access them quickly, and RAM is the fastest accessible space in that chain.

Plans first. Then code.

PROJECTYOUR APP

SCREENS12

DB TABLES6

BUILT BYREMY

1280 px · TYP. A · UI · FRONT END

Remy writes the spec, manages the build, and ships the app.

When you load a model, its weights get copied into RAM. Every inference — every token generated — reads from those weights repeatedly. If the weights don’t fit in RAM, the system starts reading from swap space (disk), and inference slows to a crawl or crashes entirely.

For smaller models (7B parameters, quantized), this is manageable. A 4-bit quantized 7B model runs comfortably in 6–8GB of RAM. But the models that people actually want to run locally — the ones with strong reasoning, broad knowledge, and real-world utility — tend to be 30B, 70B, or larger. A 70B model at 4-bit quantization still needs around 40GB of RAM.

Most consumer machines top out at 16–32GB. That gap isn’t small.

The Scale Problem Gets Worse with Capability

There’s an uncomfortable relationship between model capability and size. Broadly speaking, more parameters means better performance on complex tasks. The models people reach for when they want serious results — multi-step reasoning, code generation, nuanced writing — are the ones that won’t fit.

This creates a practical tiering problem. You can run the models you need for simple tasks, but the moment you need something harder, you’re looking at API calls, cloud costs, or a hardware upgrade.

SSD streaming is an attempt to break that relationship by changing where model weights live, not by shrinking the model itself.

Mixture of Experts: Why Not All Weights Are Created Equal

To understand why SSD streaming is practical at all, you need to understand Mixture of Experts (MoE) architecture. It’s the key that makes on-demand weight loading viable.

In a standard dense model, every layer processes every input. If a model has 70 billion parameters, all 70 billion are involved in generating each token. That’s why large dense models need so much RAM — everything has to be loaded and accessible.

MoE models work differently. Instead of one large feedforward network in each layer, they have multiple smaller networks called “experts.” A routing mechanism looks at each input token and decides which experts to activate — typically just two or four out of eight, sixteen, or more available.

What This Means Practically

A model like Mixtral 8x7B has eight expert networks per layer. For any given token, only two of them fire. The other six sit idle.

Total parameter count is high — around 46 billion parameters — but active parameters per forward pass are much lower, closer to 12–13 billion. That’s why MoE models can punch above their inference weight: you get the parameter breadth of a large model with the compute cost of a smaller one.

But here’s the implication that makes SSD streaming interesting: if only two experts are active at any given moment, you don’t need all eight experts in RAM simultaneously. You only need the two that are about to be used.

This is the architectural opening that Dwarf Star exploits.

How SSD Streaming Actually Works

The core idea is straightforward: keep the expert weights on your SSD instead of in RAM, and load them into memory only when the router selects them.

Everyone else built a construction worker.
We built the contractor.

🦺

CODING AGENT

Types the code you tell it to.
One file at a time.

🧠

CONTRACTOR · REMY

Runs the entire build.
UI, API, database, deploy.

Dwarf Star stores the expert weight tensors on disk. The non-expert components of the model — the attention layers, layer normalization, routing weights — stay in RAM because they’re used for every token and need to be fast. But the expert weights, which represent a large fraction of total parameters, get offloaded to disk.

When inference runs and the router selects experts for a given layer, the system fetches those expert weights from the SSD, runs the computation, and moves on. The weights don’t need to stay loaded — they’ll only be needed again if that expert is selected for a future token.

The Math Behind It

Take Mixtral 8x7B as an example. Total weights are roughly 90GB in full precision, around 26GB at 4-bit quantization. A large chunk of that is expert weights.

If you store experts on disk and only pull the active two per layer per token, your RAM requirement drops dramatically. The non-expert weights — the part that actually needs to stay in memory — can fit comfortably on a machine with 16–24GB of RAM.

You’re not running a smaller model. You’re running the same model, with the same output quality, but with a much smaller RAM footprint.

Prefetching Matters

A naive implementation would have noticeable latency: pick an expert, wait for the disk read, compute, repeat. That would be slow enough to make the approach impractical.

Better implementations use prefetching. Because the routing decision for layer N is known before layer N+1 executes, the system can start loading the next layer’s experts from disk while the current computation runs. With a fast NVMe SSD (which can sustain 5–7+ GB/s sequential reads), and with careful prefetching logic, the disk reads can largely happen in parallel with compute.

The result is that SSD streaming doesn’t feel like constant disk thrashing — it feels like slightly slower inference than native RAM, not like reading from a hard drive.

SSD Speed Is Not Optional

This only works if your storage is fast. A traditional SATA SSD tops out around 550 MB/s sequential read. A modern NVMe SSD using PCIe 4.0 hits 5,000–7,000 MB/s. That’s a 10x difference, and it’s the difference between a streaming approach that’s workable and one that makes inference painfully slow.

If you’re considering running Dwarf Star or similar expert-streaming setups, your storage tier matters as much as your RAM:

NVMe PCIe 4.0 or 5.0: This is where streaming inference becomes genuinely usable. Read speeds are fast enough that prefetching keeps the pipeline fed.
NVMe PCIe 3.0: Still viable, but you’ll notice the latency more. Tokens per second will be lower.
SATA SSD: Too slow for comfortable inference on most MoE models. You’ll likely bottleneck here before you bottleneck on compute.
HDD: Not a realistic option. Seek times alone make this unworkable.

This is worth flagging because “runs on your laptop” can mean very different things. A machine with a fast NVMe drive and 16GB RAM can have a genuinely good experience. The same RAM with a slower drive won’t.

The Trade-off Triangle: RAM, Speed, and Model Quality

SSD streaming doesn’t give you something for free. It trades one resource (RAM) for another (SSD bandwidth and some latency). Here’s how the trade-offs stack up:

What You Gain

Dramatically lower RAM requirement: Models that would need 40–90GB of RAM can run on 16–24GB.
Access to genuinely capable models: You’re not compromising down to a smaller model — you’re running the full thing.
No quality degradation: The output is identical to running with full RAM. The model doesn’t know its weights are coming from disk.

Other agents ship a demo. Remy ships an app.

React + Tailwind ✓ LIVE

API

REST · typed contracts ✓ LIVE

DATABASE

real SQL, not mocked ✓ LIVE

AUTH

roles · sessions · tokens ✓ LIVE

DEPLOY

git-backed, live URL ✓ LIVE

Real backend. Real database. Real auth. Real plumbing. Remy has it all.

What You Give Up

Tokens per second: Inference is slower than native RAM loading. How much slower depends on your SSD speed, the model, and how effective the prefetching is. Expect noticeably fewer tokens per second than a fully RAM-loaded run.
SSD write endurance (minor): Heavy inference use means lots of reads. SSDs have endurance ratings. For most users, this isn’t a practical concern — but it’s worth knowing.
Latency on first token: The initial load can take a moment as the first experts get pulled from disk.

For interactive use — asking questions, generating code, writing — the speed trade-off is usually acceptable. For batch inference or applications that need to process thousands of requests, you’d want native RAM or cloud infrastructure instead.

Who This Is Actually For

SSD streaming is a specific solution for a specific problem. It’s worth being honest about the audience.

It’s a good fit if:

You want to run a high-capability MoE model locally and have 16–24GB RAM
You have a fast NVMe SSD with adequate free space
Your use case is interactive or low-throughput (personal use, development, research)
You care about privacy or offline access and can’t or don’t want to use cloud APIs

It’s probably not the right fit if:

You need high-throughput inference (many requests per minute)
Your SSD is slow (SATA or older NVMe)
You’re building a production system that serves multiple users
The latency trade-off would visibly degrade your end-user experience

It’s also worth noting that SSD streaming is most relevant for MoE architectures. Dense models don’t have the same natural partition — there’s no concept of “active vs. inactive” weights at inference time in the same way. Applying streaming to a dense model would require different approaches and would likely be significantly less efficient.

Where Cloud Models Change the Calculation

For most people building AI-powered applications, the local hardware constraint is the wrong problem to be solving. Running a model locally makes sense for privacy-critical applications, offline use, or research. But if you’re building something that needs to work reliably, serve multiple users, or access the best available models, cloud inference is the practical path.

This is where something like MindStudio fits into the picture. MindStudio gives you access to 200+ models — Claude, GPT-4o, Gemini, Mistral, and others — without managing API keys, worrying about RAM constraints, or thinking about SSD speeds. You pick the model that fits your task, and the infrastructure is already handled.

For teams building AI agents and automated workflows, that matters more than most people realize. The bottleneck isn’t usually “can I run this model” — it’s “can I connect this model to the right data, trigger it at the right time, and get the output into the right system.” MindStudio’s visual workflow builder handles exactly that: connecting models to business tools, building multi-step pipelines, and deploying without writing infrastructure code.

Other agents start typing. Remy starts asking.

YOU SAID "Build me a sales CRM."

REMY ASKS

01 DESIGN Should it feel like Linear, or Salesforce?

02 UX How do reps move deals — drag, or dropdown?

03 ARCH Single team, or multi-org with permissions?

Scoping, trade-offs, edge cases — the real work. Before a line of code.

If you’re interested in what capable models can actually do in production rather than in your terminal, you can try MindStudio free at mindstudio.ai. It’s a different solution to the same underlying goal: getting access to capable AI without the friction.

Practical Setup Considerations for SSD Streaming

If you’re interested in trying expert streaming locally, here’s what to think through before starting.

Storage Requirements

Large MoE models are large. Mixtral 8x7B at 4-bit quantization is around 26GB. Larger models like Mixtral 8x22B run over 80GB even quantized. Make sure you have adequate free space — running out mid-inference is painful.

Quantization Still Helps

SSD streaming and quantization work together. A 4-bit or 8-bit quantized model still produces the expert streaming benefit, and smaller file sizes mean faster disk reads. GGUF format (used by llama.cpp) and similar quantized formats are generally compatible with streaming approaches.

RAM Allocation

You’ll want to be deliberate about what stays in RAM versus what streams from disk. The routing logic, attention layers, and other non-expert components should stay in RAM for speed. Most expert streaming implementations handle this automatically, but knowing the split helps you debug if something’s slow.

Thermal Throttling on Laptops

Sustained inference on a laptop will push both CPU and SSD hard. SSDs throttle when they get hot, which will slow your reads and hurt inference speed. If you’re doing long inference sessions on a laptop, this is worth monitoring.

Frequently Asked Questions

What is SSD streaming for AI models?

SSD streaming is a technique that stores model weights on an SSD rather than keeping them entirely in RAM. During inference, the system loads only the weights it currently needs from disk, runs the computation, and discards or cycles them. This reduces RAM requirements significantly while maintaining full model quality, at the cost of some inference speed.

Does SSD streaming reduce model quality?

No. The model weights are identical — they’re just stored on disk rather than RAM. The outputs of inference are the same as if you’d loaded everything into RAM. Quality is only affected if you also apply additional quantization on top of the streaming setup, which is separate.

What kind of SSD do I need for AI model streaming?

You need an NVMe SSD, ideally PCIe 4.0 or better. These drives achieve sequential read speeds of 5,000–7,000 MB/s, which is fast enough for prefetching to work effectively. SATA SSDs (capped around 550 MB/s) are generally too slow for comfortable inference. PCIe 3.0 NVMe drives are workable but will show more latency.

Why does SSD streaming work better for MoE models?

Mixture of Experts models only activate a fraction of their expert networks per token — typically two out of eight or more. This creates a natural partition between “weights needed right now” and “weights that can stay on disk.” Dense models don’t have this partition, so streaming them is less efficient — you’d need all weights for every forward pass.

How does Dwarf Star differ from just using swap space?

REMY IS NOT

✕a coding agent
✕no-code
✕vibe coding
✕a faster Cursor

IT IS

✓a general contractor for software

The one that tells the coding agents what to build.

Operating system swap space uses disk as a passive overflow when RAM fills up. It’s not optimized for sequential weight loading and lacks any awareness of model structure or inference patterns. Dwarf Star actively manages which weights to load, when to load them, and uses prefetching based on routing decisions to hide disk latency. It’s a purpose-built system, not a generic fallback.

Can I use SSD streaming for production applications?

For low-traffic or single-user scenarios, it’s viable. For production systems handling multiple concurrent users or requiring high throughput, the latency and bandwidth limitations of SSD streaming become problematic. In those cases, cloud inference or dedicated GPU infrastructure is more appropriate.

Key Takeaways

RAM has historically been a binary constraint for local AI models — either the full model fits or it doesn’t run. SSD streaming turns it into a sliding scale.
MoE architectures make SSD streaming practical because only a subset of expert weights are active at any given time — the rest can live on disk without affecting output quality.
Dwarf Star implements this by streaming expert weights from SSD to RAM on demand, with prefetching to minimize latency impact.
NVMe SSD speed is critical. PCIe 4.0 drives make this approach genuinely usable; slower storage undermines the value.
The trade-off is tokens per second, not quality. Outputs are identical to a fully RAM-loaded run — inference is just slower.
For most people building AI-powered applications, cloud inference through a platform like MindStudio eliminates the hardware constraint entirely and lets you focus on what the models actually do rather than how to make them run.

New research: The Core Web Vitals thresholds you trust might be wrong for your site

2026-07-17T18:16:45Z

I decided to dig into my questions properly. I pulled a month of real user data from ten leading online retailers and built a correlation chart for each one, plotting session-level Largest Contentful Paint (LCP) data against bounce rate for each site.

Before we get into the findings, first I want to cover what a performance correlation chart is and what it shows you.

A correlation chart is a powerful data visualization that shows you the relationship between your page speed metrics and your business and user engagement metrics.

To illustrate, here’s the correlation chart for the first retail site in this research:

Correlation charts are generated using real user monitoring (RUM) data. They give you a histogram view of all your user traffic, broken out into cohorts based on performance metrics, such as Start Render, Largest Contentful Paint, Interaction to Next Paint, and more. Each cohort shows you the median time for whatever metric you’re tracking for the session. (Those cohorts are represented in the yellow columns in the chart above.)

The next layer of the chart is where things get really interesting.

You also get an overlay (the blue line in the chart above) that shows you the business or user engagement metric – commonly conversion rate or bounce rate, but there are many more – that correlates to each of these cohorts. This lets you see at a glance how closely your business/engagement metric aligns with the speed of your site.

For this investigation, I focused on bounce rate rather than conversion rate because it’s captured by default in most RUM tools, so there’s no extra instrumentation required. It’s also a good directional proxy. In my experience, if you see a relationship between a performance metric and bounce rate, there’s a good chance a similar relationship exists with conversion rate, too.

On the correlation chart for each site, I marked three points:

If you’re not familiar with the performance plateau, I’ve written about it before. Short version: every site eventually hits a point where shaving off more milliseconds stops moving the needle on engagement. Below that point, speed matters a lot. Beyond it, you’re optimizing for nothing.

Across all ten retailers, the optimal LCP — the point tied to the best bounce rate — ranged from 100 milliseconds to 1 second.

Not 2.5 seconds.

Every one of these sites saw its best engagement well before Google’s “good” threshold. For several sites, 2.5 seconds was already sitting on the plateau – the zone where speed had stopped helping long before.

I want to emphasize this before I go on: this is NOT a new number for you to chase. 100ms–1s isn’t a universal target any more than 2.5 seconds is. That’s exactly the trap we’re trying to avoid. What it tells you is that “good enough” – for real users on real sites – can be much faster than the industry standard suggests. The only way to know your number is to look at your own data.

The start time for the performance plateau ranged from 500 milliseconds to 5.6 seconds across all ten sites. This wasn’t surprising. There’s typically a lot of variance in how the performance plateau manifests across different sites.

What was surprising was that, for four of the ten sites, the performance plateau started before 2.5 seconds. By the time those four sites met Google’s recommended threshold for “good” Largest Contentful Paint time, they were already on the performance plateau.

In other words, even though these four sites are technically fast enough for Google, they’ve actually bottomed out in terms of bounce rate.

At the risk of repeating myself (but it bears repeating), you should never assume that meeting external thresholds is actually helping your business. You need to look at your own data to set meaningful targets.

Below, I’m sharing the correlation chart for each of the ten retailers, along with what stood out in each one: where the optimal LCP landed, where the plateau began, and anything else worth noting about the shape of the curve.

To be completely candid, even though I hypothesized these results, I was surprised at how consistent they were.

It’s tempting to look at “100 milliseconds to 1 second” and treat it as a new target to chase. Please, please don’t. As I mentioned earlier, that’s exactly the trap we’re trying to avoid. Consider this research a methodology, not a number.

The good news is that the method is straightforward:

Pull your own RUM data.
Build a correlation chart plotting LCP (or any other user-oriented metric) against bounce rate.
Find where your bounce rate is actually at its best, and where your plateau begins.
Set your performance goals based on that – not on a number based on millions of sites you don’t run.

Your optimal LCP might turn out to be 1.8 seconds. It might be 400 milliseconds. It might be 5 seconds. Who knows! There’s no way to know without looking. But if these ten retailers are any indication, “fast enough” may be faster than the industry standard suggests. Treating 2.5 seconds as your finish line could mean leaving engagement and revenue on the table without realizing it.

If you run this analysis on your own site, I’d love to hear what you find! If you’re an Embrace/SpeedCurve customer and you want to know how to do your own investigation, let me know and I’ll be happy to help.

A Boring Tiny Tooling paradigm

2026-07-02T05:36:29Z

6/1/2026 ☼ product ☼ consulting ☼ AI ☼ BTT

tl;dr: Small-medium businesses are missing a huge opportunity because of three imagination failures: they believe digital transformation must be big and disruptive, they haven’t recalibrated software buying for the collapse in software development costs, and they don’t realise this economic shift requires a different consulting approach. These businesses need Boring Tiny Tools (very narrowly scoped software automating repetitive workflows) built by amorphous consultants who observe actual operations before proposing solutions.

Over the last year, I’ve been writing about and doing a lot of amorphous consulting while using the meaningmaking lens to think practically about what human work should be in a time of AI. In doing that, I’ve spent a lot of time both in and lurking at the edges of conversations with people working at the cutting edge of AI use. I recently had a long call with Rob Miller, a software developer and independent consultant who emailed me after reading an essay I wrote about Boring Tiny Tools. (A BTT is a very narrowly scoped piece of software that automates boring, routine workflows without disrupting other workflows.)

Rob told me about spending a single afternoon building a BTT for his wife’s firm, a barristers’ chambers. This BTT is a court submission preparation tool that works on-premises to be compliant with data protection. The tool makes PDF multi-document bundles, automatically creates hyperlinked tables of contents, and formats the bundle to court specifications. Error-prone humans used to spend hours doing this boring job manually. Now it is a software-enabled, reliable automated process that takes minutes. Multiply that across 50-60 people and thousands of cases per year in the organisation and the savings quickly stack up.

Rob’s BTT is yet another validation of the new emerging paradigm I’m seeing (and am maybe a part of) at the place where software, consulting, and digital transformation touch each other. The greatest potential beneficiaries of this new paradigm are small-medium businesses with a particular profile:

Small enough to have no in-house transformation tools team, but
Large enough that efficiency gains from transformation save a significant amount of money annually (say, millions vs tens of thousands of dollars), but
Not so large that transformation savings justify spending hundreds of thousands of dollars on conventional transformation consultants to write bespoke business process software.

Three imagination failures

Unfortunately, these small-medium businesses don’t actually seem to be benefiting yet. It’s more accurate to say that the new Boring Tiny Tooling Paradigm is struggling to emerge but three related imagination failures keep getting in the way.

These three imagination failures affect the idea of what transformation should look like, what the software that enables it should be, and what kind of consulting approach to buy:

Inability to conceive of digital transformation as anything other than Grand and Disruptive. Only big strategic software deployments, enterprise platforms, major integrations, or organisation-wide rollouts are legible as transformation. BTTs that address a profusion of tiny business processes don’t read as transformation, even when the return on investment is both immediate and measurable.
Inability to recalibrate the scale of software bought to account for the sudden collapse in the cost of writing software. Software that used to cost tens of thousands of dollars and take months to write now costs thousands of dollars and takes days to write. It’s finally economically feasible to write BTTs to automate tiny, boring business processes.
Inability to see that the collapse in software economics necessitates a different transformation consulting approach. That BTTs are suddenly cheap, fast, and viable to build should be feeding through to the kinds of transformation consulting services businesses buy … but businesses continue to want conventional consulting services that price and deploy oversize, too-expensive transformation solutions based on pre-collapse software economics.

A consulting problem

That last imagination failure is the big one.

When businesses can only imagine transformations that are big and legible, they look for and engage conventional consultants who promise big legible transformations. These conventional consultants scope and deliver expensive and needlessly enterprise-scale solutions to justify their big fees and promises of big transformations.

(It is now an open secret that the big consulting firms are using AI tools internally to cut development time while still charging out at pre-AI prices. They keep the difference and have no incentive to educate clients about these new economics.)

Meanwhile, what the small-medium business actually needs is a different consulting approach entirely: What I call amorphous consulting. In contrast to conventional consulting, amorphous consulting comes into a client engagement with an open mind about the problem and the solution.

Rob’s bundle preparation tool was a solution scoped out of a deep understanding of the user’s real operational problems. The amorphous consultant gets this kind of deep understanding by spending time observing what’s happening in the client’s organisation. This approach to consulting leads to tiny, boring, highly effective solutions. When software is scoped and built by amorphous consultants, it is more likely to be

Minimal and fast to build (because the scope will be limited to only features needed to address the actual problem to be solved),
Functional within actual operational constraints faced by users on the ground,
Actually adopted by users with operational responsibilities, and
Undisruptive to other workflows.

These are all desirable characteristics of transformation software.

How Rob scoped and built his BTT — prompted by a serendipitous observation of his wife doing silly rote work to prepare a bundle manually while on holiday in Champagne — is an example of the kind of amorphous consulting approach that most small-medium businesses actually need.

Unfortunately, most of these businesses don’t know how to procure these kinds of amorphous consulting services where the scopes of work and target deliverables can’t (and shouldn’t be) defined in advance.

Imagination is the hard part

As I wrote in AI’s missing middle, small-medium firms in traditional industries represent a massive market and a massive missed opportunity. (Policymakers and investors might want to take note.) Small-medium firms don’t need fancy conventional consultants and their overscoped and expensively disruptive software. What they do need are Boring Tiny Tools scoped and built by amorphous consultants.

None of this is expensive or technically challenging. All it takes is better imagination.

Even with a silver bullet, you still have to aim

2026-06-30T03:44:53Z

As George Lucas once said, for some reason: history is like poetry. It rhymes.

Our industry is certainly rhyming with a historical era I love to pick on: the boom in tech investment that followed the one-two punch of the Dot Com Bust and the Financial Crisis. Companies and their investors were desperate to find that one silver bullet that would turn everything around. Back then, that silver bullet was Design Thinking. Big tech poached designers from celebrated consultancies and airdropped them into pure chaos without a plan beyond “fix the product for us.”

Ten years after design thinking’s heyday, there’s a new silver bullet that everyone has pinned their hopes on, without a clear idea of what exactly it will do. At this point in the hype cycle, you’ve seen the numbers for yourselves: billions in investments, and loud cricket noises for returns. Anecdotes of individual productivity gains are easy to come by, and yet they do not translate to improvements in the bottom line!

What’s actually making teams move faster is org design. Taking care of organizational dysfunction may be a side effect of “AI transformation” but it sure seems to be offering the majority of the benefits.

❝

Consider this story when the right handpicked people completed in 3 hours, a piece of work estimated at 10-12 weeks. That story was from roughly ten years ago, well before any of the AI tools appeared on the scene. It didn’t rely on magical tooling, it just needed us to undo some organizational dysfunction and to put the right people in the room to collaborate on the problem.

The purpose of a system is what it does

“AI works” vs “AI doesn’t work” is an exhausting debate; no one is ever convinced of anything and the only winners of the arguments are keyboard manufacturers. I’m not going to go over the various hallucination rates and studies on how much longer it takes to check an AI’s output for errors than to just do it yourself. Even with 0% error rates, those figures would be besides the point. The biggest problem — and don’t take my word for it, listen to some Nobel laureate guy — is that the bottleneck lies upstream of your Jira ticket:

❝

Most research on AI productivity is overblown because it overwhelmingly focuses on easy, well-defined tasks where context is clear. These are not representative of the economy, which simply isn't set up with so many of those.

We are not in the future. It is still 2016. It is still 1986, if you are so inclined. We have hardly made any strides in our ability to define tasks and their context. What baby steps we’ve made in the right direction have been swallowed up by a great cloud of noise. For every Toyota Way book written in the 90s, there is a Ford counterexample being eagerly practiced today.

AI has intensified this problem, as it intensifies all things to which it is applied. But the problem did not originate with AI. Before Claude could learn to talk like the median LinkedIn influencer, the median LinkedIn influencer had to arrive at that mindset under their own power:

❝

Criticism of the […] slop genAI produces invariably fails to acknowledge how much slop-ification was already characterising so many discourses prior to retail LLMs: PEEL paragraphs, Powerpoint slides, TED talks, Big Consultancy strategy canvases, PR company produced apologies to customers, LinkedIn posts...

The bottleneck is the context in which the work takes place

For every step a would-be thought leader took towards “synergistic leadership” or “growth-hacking paradigms” they took a step away from reality. And corporate bullshit (not my name for it but a real term of the art, take it up with Cornell!) is not the only layer lubricating a product’s slide into slop. Robert Fabricant has a good layman’s overview of how little a modern product is influenced by a given design decision, and how much is a consequence of business and technology decisions that stack up over time without a single decision-maker deliberately steering things to be so. I recommend giving this one a read, as a means of cognitive estrangement from the ways of working we take for granted, because we are too close to them to realize how ridiculous they really are.

Unfortunately, many tech leaders do not take the time to reflect on whether the system actually makes sense. They shirk the responsibility given to them — to build an effective system — and instead whip the existing, faulty system to run faster and faster, until all the wheels fall off:

❝

“Ship more faster now” is not a product strategy; it’s a psychosis. …

Reframe craft as care for collaborators, users, and the collective aspiration to create something useful, meaningful, and significant. Craft is a social act that binds teams around shared values and takes time.

But how do we make this reframe happen? How do we seize control of our discipline’s story?

That’s where my head’s been at for years — before the Picnic, before my work for NN/g, even before I started publishing with the UX Collective. But only lately have those thoughts come together into something actionable enough to share. I’ll be writing on this topic through July, but the capstone of these ideas will be my one-day workshop with Throughline on July 31st.

Flex those professional development budgets and join me in taking back control of the conversation.

— Pavel at the Product Picnic

untitled

2026-06-21T18:45:46Z

Moving beyond hunch and silencing the sceptics. Over the years, Conway’s Law has resurfaced as a guiding principle to organise teams. Yet, many people still hesitate to accept the idea. Ultimately, it remains a hypothesis. Melvin Conway did not provide any proof when publishing the thesis. However, in the meantime, decades later, a good deal of academic research supports the thesis. Ultimately, Harvard and MIT researchers provided robust empirical validation for the hypothesis across the software industry, further confirmed by the CHAOS Report from the Standish Group, reinforcing The Mirroring Principle as an undeniable organisational reality.

Henderson and Clark observed in 1990 that established firms are unable to adopt architectural innovation because the architectural knowledge is embedded in the communication structures of the organisation, preventing them from adopting new designs.

We show that architectural innovations destroy the usefulness of the architectural knowledge of established firms, and that since architectural knowledge tends to become embedded in the structure and information-processing procedures of established organizations, this destruction is difficult for firms to recognize and hard to correct. Architectural innovation therefore presents established organizations with subtle challenges that may have significant competitive implications.

– Architectural Innovation: The Reconfiguration of Existing Product Technologies and the Failure of Established Firms, Henderson and Clark, 1990

“Architectural innovation” is defined as innovations that change the way product components are linked together, while leaving the core design concepts — and thus the basic knowledge underlying the components — untouched. That does not mean that components remain untouched. Often, architectural innovation is triggered by a change in a component that triggers new interactions and connections with other components.

The study’s outcome is based on the analysis of 20 years of data (1962-1986) from the photolithographic alignment equipment industry, where four organisations subsequently took over market leadership because a competitor uncovered an architectural innovation that the previous leader was unable to detect due to its organisational structure.

There has been growing evidence of numerous technical innovations that involved apparent modest changes to existing technology, but that had dramatic competitive consequences. In the mid-1950s, RCA developed a prototype for a portable radio receiver. It utilised technology that RCA mastered well. Yet, they did not pursue the idea. Until Sony, a small, relatively new company, entered the US market with portable radio receivers. RCA remained a follower. The irony was that Sony produced radios during many years using RCA’s licensed technology. The case of Xerox, in the mid-1970s, although the inventor of the plain-paper copier, was, during eight years of strategic errors, unable to compete with competitors offering smaller, more reliable copiers. Xerox lost half of the market. For a more recent example, we look at the German car industry, which had trouble marketing electric cars until Tesla, and later the Chinese car manufacturers took over the market. Meanwhile, Audi closes its Belgian factory that produces the expensive electric SUV because of a market mismatch.

This inability to adopt architectural innovation happens because an organisation organises itself around the product’s key components that make up the “dominant design”. The “dominant design” is characterised by a general acceptance of a particular product architecture. It incorporates a range of basic design choices that are not revisited — think car platforms, or in software, a CRUD design. It results in communication channels between the design teams that reflect the organisation’s knowledge about the critical interactions between these components. Thus, an organisation’s communication channels embody the organisation’s architectural knowledge that is critical to effective design. From this moment on, organisations incline to focus only on “incremental innovation”, tending to reinforce the competitive positions of established firms as it builds on their core competencies.

As such, the architectural knowledge is a mirror of the communication structures organised around the product being designed. Somehow, this is the knowledge parallel of Conway’s thesis “[Any] organisation which designs systems is constrained to produce designs which are copies of the communication structures of the organisation”. If communication structures dictate design (Conway, 1968), they also dictate what an organisation is capable of knowing (Henderson and Clark, 1990).

Henderson and Clark establish that, given how knowledge is organised in firms, learning about changes in the product architecture is unlikely to happen. It requires explicit management, or even a different organisation. To counter this, the authors suggest cross-functional teams as a possible response to the danger of architectural knowledge becoming embedded within tacit communication lines.

Recently, I was front-seat observing an organisation unable to run only a simple experiment, which would let them eventually discover a potential innovation, merely because of the structures in place.

Because the communication channels are “frozen” around the old product architecture, the knowledge is also frozen; the organisation cannot distinguish or adjust to a possible new architecture reality, or even conceive a new design reality. This is Conway’s Law working back over time (more on this in Dynamics: Conway’s Time Component).

The Aircraft Engine/Automotive Validations (2004, 2007)

In 2004, Sosa et al. published a study that investigated the design process of a commercial aircraft jet engine, the PW4098, at Pratt & Whitney. They studied how design interfaces in the product architecture map onto communication patterns within the development organisation. More specifically, they explored whether organisational problems exist at the boundaries of the components inside the jet engine, i.e. whether a misalignment exists between the design team boundaries and system component interfaces.

According to Henderson and Clarke, architectural knowledge is embedded in the communication structures of organisations; therefore, organisations need to understand how they manage embedded knowledge. This is especially relevant when designing new products. In this context, system design interfaces are the primary sources of team interdependence, or at least, they should be. Meaning, when a specific team designs their own component with an interface to a neighboring component, there should be a corresponding technical interaction between the two respective teams. These are the expected cases. On the other hand, unmatched design interfaces and unmatched team interactions are unexpected. As it seems, these cases were largely ignored in previous research.

However, we believe that considering these cases is important because their existence would indicate that not all known product-related interdependences are addressed by direct technical communication, and that technical communication (where not expected) may uncover undocumented product-related interdependences.

– The Misalignment of Product Architecture and Organizational Structure in Complex Product Development, Sosa et al, 2004

Finally, the study concludes that …

… we provide empirical evidence that product ambiguity exists, and it is more likely to be present across organizational and system boundaries

– The Misalignment of Product Architecture and Organizational Structure in Complex Product Development, Sosa et al, 2004

Meaning, that there is a great likelihood that some of the system component interfaces are not covered by team interactions, which can lead to major setbacks involving significant rework that can be extremely costly. The paper, exactly, refers to two major setbacks during the design of that specific jet engine.

What they are essentially saying here is: If there is a misalignment between the organisation and the product architecture, there will be problems.

In 2007, Gokpinar et al. conducted a study examining the design of cars in the automotive industry.

[…] a key challenge for product development organizations is matching the organization to the product being developed. This involves two fundamental problems: (1) How to assign people to the parts and subsystems that make up the product, and (2) How to ensure that people communicate/collaborate effectively in the performance of design tasks.

– The Impact of Misalignment of Organization Structure and Product Architecture on Quality in Complex Product Development, Gokpinar et al, 2007

The research defined a new metric coordination deficit, which quantifies mismatches between product architecture and organisation structure, and investigated the effect of coordination deficit on product quality.

They concluded that mismatches between product architecture and organisational structure are positively associated with quality problems.

Our results suggest that misalignment of the design organization with the product architecture negatively affects product quality”

– The Impact of Misalignment of Organization Structure and Product Architecture on Quality in Complex Product Development, Gokpinar et al, 2007

Once more, if there is a misalignment between organisation and product architecture, there will be problems.

The Micro Software Validation (2006)

In 2006, Cataldo et al. investigated the consequences of congruence on the speed and efficiency of software development work inside a single software project. They investigated the impact of misalignment.

This is particularly important in product development organizations which organize themselves around their products’ architectures because the main components of their products define the organization’s key sub-tasks.

– Identification of Coordination Requirements: Implications for the Design of Collaboration and Awareness Tools, Cataldo et al, 2006

This matters because, as architectural knowledge is embedded in the communication structures of organisations (Henderson and Clark, 1990), any minor changes to the product architecture can disrupt the organisation’s ability to coordinate effectively.

Ultimately, Cataldo et al. found that tasks were completed more rapidly when the patterns of communication between team members were congruent with the patterns of interdependency between components (more on congruence in Mechanics: The Mathematical & Geometrical Shades).

Congruence between coordination requirements and coordination activities shortened development time.

– Identification of Coordination Requirements: Implications for the Design of Collaboration and Awareness Tools, Cataldo et al, 2006

Fundamentally, the research indicates, if teams are aligned with the components they work on, teams are more efficient.

The Macro Software Validation (2012)

In 2012, we had the first empirical evidence for the software industry provided by the research paper Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis from Baldwin et al.

One of their findings was: software products tend to mirror the structure of the organisation in which they are developed.

We find strong evidence to support the hypothesis that a product’s architecture tends to mirror the structure of the organization in which it is developed.

– Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis, Baldwin, MacCormack and Rusnak, 2012

Source: Sketchplanations https://sketchplanations.com/conways-law

To validate this hypothesis, they compared open-source with closed-source software. Based on the idea that the open-source communities are loosely coupled organisations by design because contributors have diverse goals, belong to different organisations, work in different geographical locations and time zones, and have no formal authority to guide development activities. Whereas closed-source organisations are more tightly-coupled, as they consist of smaller, co-located teams that share common goals, and are dedicated full-time to products and have formal decision-making authority to guide development.

The study’s approach focused on comparing the architectures of open-source and closed-source software products that have similar functions and are of a similar size. They identified five software categories: financial management, word processing, spreadsheets, operating systems and databases. For each category, they selected an open-source and a closed-source software product.

Because commercial firms are somehow reluctant to share their code base, especially for research comparing with “free” equivalents, researchers did not always have a closed-source codebase at their disposal. When commercial options were unavailable, they turned to formerly closed-source products that had been open-sourced. In those instances, they analysed the first open-source version.

So they ended up comparing:

For financial management: GnuCash vs MyBooks
For word processing: Abiword vs StarWriter
For spreadsheets: Gnumeric vs StarCalc
For operating systems: Linux vs Solaris
For databases: MySQL vs Berkeley DB

The paper primarily explores whether organisations with distinctly different forms develop products with distinctly different architectures.

The outcome of the study was that loosely-coupled organisations, such as open-source, tend to develop products with a more modular architecture than tightly-coupled organisations such as commercial firms. This confirms Parnas’ information hiding concept (Parnas 1972), which allows individual, isolated contributors to work independently. It also reaffirms Henderson and Clark’s observation. Loosely coupled, open-source organisations prevent architectural knowledge from becoming a central, siloed trap. They adopt cross-functional, loosely coupled teams to democratise knowledge. Tightly-coupled organisations, on the other hand, stumble when faced with innovations, because knowledge is tightly frozen, siloed, in the structures of the organisation.

The Industry Reality Check (1995-2020)

We know why projects fail, we know how to prevent their failure – so why do they still fail?

– Cobb’s Paradox, Martin Cobb, CIO for the Secretariat of Treasury Board of Canada, CHAOS University, 1995, published in Unfinished Voyages I, Standish Group, 1995

When organisations keep treating software products as mere, rigid projects, the resulting architecture and outcomes for users will be notably poor, leading to surprising failures.

From 1994 until 2020, the Standish Group published the CHAOS Report, a study on the success, failure, and challenge rates of IT projects.

Year	Success	Challenged	Cancelled
1994	16%	53%	31%
2000	28%	49%	23%
2002	34%	51%	15%
2004	29%	53%	18%
2006	35%	46%	19%
2008	32%	44%	24%
2011	39%	39%	22%
2012	37%	46%	17%
2013	41%	40%	19%
2014	36%	47%	17%
2015	36%	45%	19%
2020	31%	50%	19%

– source: CHAOS Reports 1995, 2009, 2015, 2020, Standish Group.

Although this may look baffling at first, this stagnation blindsides no experienced practitioners. The numbers reveal a flatline trend. Despite agile and DevOps, the success rate is capped at approximately 30%.

Till 2015, the Standish Group focused mainly on classic project management requirements to measure success, such as well-defined upfront requirements, proper planning, skilled project managers, as well as user involvement and project sponsor. Success was defined in classic PMI terms, the Iron Triangle, i.e. on time, on budget, with all features as initially specified. Then, in 2015, a first significant shift happened. The success resolution definition changed. It was still on time and on budget, however, with satisfactory results. All requirements no longer have to be implemented, since data shows that some projects meet the Iron Triangle yet do not return value. In the end, satisfaction and value are greater when fewer features are delivered, but meeting obvious user needs. This is aligned with Lean principles, as well as another Standish Group study revealing that 64% of delivered features are rarely used. Later confirmed by the 2019 Pendo Feature Adoption Study, revealing 80% of features see low to zero adoption.

By 2020, the Standish Group had pivoted and reported an astonishing outcome that contradicts their early recommendations. Stop treating software products as a project because, by definition, projects have a start and an end, but products do not. They explicitly stated that project managers harm software products and increase the failure rate. Specifically, the report demonstrates that project managers often generate more paperwork, resulting in slower decision-making that inevitably slows down feedback. While, once more, not surprising for experienced practitioners — it was already established long before, and brought to the public in 2017 with the #NoProjects movement — the Standish Group brought it to the masses.

Ultimately, the Standish Group concluded that project success is defined by Good Sponsor, Good Team, Good Place, and Short Decision Latency. To a large extent, this aligns with the 2001 findings from the book Good to Great. Organisations become great when they have Level 5 Leadership (Good Sponsor) to build enduring greatness through a paradoxical blend of personal humility and professional will. They focus on First Who … Then What (Good Team), first securing the right people before figuring out where to drive it, before vision, before strategy, before tactics, before organisational structure, before technology. Lastly, they Confront the Brutal Facts of Reality (Good Place), by fostering a climate where the truth is heard.

These crucial prerequisites enable Short Decision Latency, allowing information to circulate rapidly. However, low decision latency is entirely dependent on communication paths. Since Conway’s Law dictates that systems reflect the organisation’s communication structures, high-latency organisations stuck in silos are unable to produce high-velocity, decoupled system designs. This architectural congestion hampers communication and impedes overall success.

Ultimately, the CHAOS Report recommends moving away from “projects” and adopting Infinite Flow, which Lean has been promoting since the 1980’s. Somehow, this is the business world finally accepting what Baldwin et al. proved in 2012: tightly coupled organisations produce tightly coupled system architectures that work against flow, while loosely-coupled organisations thrive because they produce loosely coupled system architectures that enable flow, short time to markets, and consequently accelerated feedback to meet user expectations better. The 2020 CHAOS Report Good Place — where truth is heard to reduce Decision Latency — is exactly the type of environment needed to break the “frozen”, siloed, tacit communication lines Henderson and Clark blamed for corporate blindness.

Conclusion

To conclude, the tech industry spent decades trying to fix management processes, only to realise they were fighting a losing battle against the structural gravity of Conway’s Law and its implications on innovation and market leadership. Mediocrity is the default. Success is optional. Just saying …

The Series: Navigating the Shades

Beyond the Shades of Conway’s Law series:

Foundations: The Origin & The Mirroring Principle - How the worlds of organisation and product design observed the same thesis independently.
Validation: The Research & Reality Check - Moving beyond the “hunch”, how researchers proved the Law in different industries, but especially in software.
Mechanics: The Mathematical & Geometrical Shades - The geometry of design: from mathematical isomorphism, homomorphism, congruence to compatibility.
Strategy: Reversing the Law - How the system ultimately forces the organisation to change versus deliberately changing the organisation.
Scale: Conway’s Corollary - The required organisational flexibility.
Dynamics: Conway’s Time Component - The “Engineer Half Life” and why architecture is “sticky” long after teams change.
Conclusion: The Different Lenses - A concluding look at how we perceive organisations and their systems.

Bibliography

How Do Committees Invent?, Melvin Conway, 1968
On the Criteria To Be Used in Decomposing Systems into Modules, Parnas, 1972
Architectural Innovation: The Reconfiguration of Existing Product Technologies and the Failure of Established Firms, Henderson and Clark, 1990
CHAOS Report 1995, Standish Group, 1995
Unfinished Voyages I, Standish Group, 1995
Good to Great, Jim Collins, 2001
The Misalignment of Product Architecture and Organizational Structure in Complex Product Development, Sosa et al, 2004
Identification of Coordination Requirements: Implications for the Design of Collaboration and Awareness Tools, Cataldo 2006
The Impact of Misalignment of Organization Structure and Product Architecture on Quality in Complex Product Development, Gokpinar et al, 2007
CHAOS Report 2009, Standish Group, 2009
Exploring the Duality between Product and Organizational Architecture: A Test of the “Mirroring” Hypothesis, Baldwin, MacCormack, Rusnak, 2012
CHAOS Report 2015, Standish Group, 2015
Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch, InnoQ, 2015
Are 64% of Features Really Rarely or Never Used?, Mike Cohn, 2016
The 2019 Feature Adoption Report, Pendo, 2019
Chaos Report — why this study about IT project management is so unique about the CHAOS Report 2020, Radek, The Story, 2024

untitled

2026-06-14T16:10:31Z

The Plan

In the beginning was the Plan.

And then came the Assumptions.

And the Assumptions were without form.

And darkness was upon the face of the Workers.

And they spoke among themselves, saying, "It is a crock of shit, and it stinketh."

And the workers went unto their Supervisors and said, "It is a pail of dung, and none may abide the odour thereof."

And the Supervisors went unto their Managers, saying, "It is a container of excrement, and it is very strong, such that none may abide by it."

And the Managers went unto their Directors, saying, "It is a vessel of fertiliser, and none may abide its strength."

And the Directors spoke amongst themselves, saying one to another, "It contains that which aids plant growth, and it is very strong."

And the Directors then went onto the Vice Presidents, saying unto them, "It promotes growth and is very powerful."

And the Vice Presidents went unto the President, saying unto him, "This new plan will actively promote the growth and vigour of the company; with powerful effects."

And the President looked upon the Plan, and saw that it was good.

And the Plan became Policy.

This is How Shit Happens.

→ Check out more Funny Shit

untitled

2026-06-14T06:26:18Z

Think about the last time you tracked your progress on a personal goal. Maybe you were trying to exercise more frequently, be more patient with a spouse or partner, or learn a new skill. Chances are, you had a rough sense of how it was going. And chances are that sense was more optimistic than the evidence warranted.

This is not a character flaw. It is one of the most reliable findings in behavioral science: We are systematically poor judges of our own progress, and during periods of active change, we tend to get worse.

One reason is what psychologists Terence Mitchell and Leigh Thompson at the University of Washington termed rosy retrospection. This is our consistent tendency to remember past experiences more favorably than we rated them in the moment. When we look back over a month of trying to exercise more or sleep differently, our memory selectively surfaces the days we succeeded. The days we failed are there, but they are not as memorable. We feel we’ve been doing better than we really have.

A second explanation is subtler. Motivation isn’t a fixed state; it shifts gradually, often well before behavior changes in any visible way. The enthusiasm that felt solid in January has usually started to erode by March. But because the erosion is incremental, we rarely catch it in real time. We trust that how we feel today is roughly how we’ve been feeling all along. It almost never is.

Together, these two patterns create a specific failure mode: We assume the feedback loop is running when it isn’t. We trust that because we know our own goals and intentions, we know how we’re actually doing. But intention and behavior are not the same thing. How we feel about a change is not the same as how we’re enacting it. And until we close that gap with something more rigorous than a gut check, we’re optimizing for a version of our progress that may not exist.

In researching what separates change successes from failures at organizations for my book, my coauthors and I found that leaders designing change were consistently more confident about employee progress on change than the employees’ actual behavior or stated experience supported. They trusted their read on the room. The data, when they gathered it, told a different story. The wider the gap, the more likely the change failure.

The same gap operates in personal change. And the same remedy applies: Use measurement, not instinct.

This doesn’t require an elaborate system. Research by James Pennebaker at the University of Texas at Austin shows that the act of writing specifically about your experience—not vague journaling, but naming exactly what you did, how it felt, and where the friction was—produces measurable improvements in self-understanding and in the likelihood of follow-through. Writing forces the brain to translate impression into information. The gap between what you felt and what actually happened becomes clearer.

Social accountability produces a related effect. A study by psychologist Gail Matthews at Dominican University found that people who wrote down their goals and reported progress to a friend were 42 percent more likely to achieve those goals than people who kept them private. Part of what accountability does is discipline the story you tell yourself. You can’t smooth over the gaps as easily when someone else is watching for them.

Both interventions do the same thing: They replace vague impressions with actual information. When people begin gathering that information honestly, they usually discover not only the gaps in their efforts, but also the progress they had stopped noticing.

Teresa Amabile, a psychologist at Harvard Business School, spent years studying what helps people stay motivated during sustained effort. Her research, drawn from the daily diaries of 238 professionals tracked over several months, produced a counterintuitive finding: The single biggest day-to-day motivator wasn’t recognition from a manager or a meaningful reward. It was the perception of making progress on work that mattered. Small wins, when noticed specifically, produced outsized improvements in engagement and follow-through. The operative word is “noticed.” Progress that goes unobserved doesn’t produce the same effect. It needs to be named to become fuel.

This is what honest self-assessment makes possible. When you journal about your week in specific detail, you often discover you accomplished much less than your vague, optimistic impression suggested—and you'll have a record you can point to as concrete evidence. That specificity matters more than it might seem. Ayelet Fishbach at the University of Chicago Booth School of Business has shown across repeated experiments that concrete progress feedback strengthens goal commitment more than encouragement does. What keeps people going isn’t being told they’re doing well. It’s seeing, with some precision, that they truly are.

Motivation Essential Reads

The story you’re telling yourself about your progress probably has some blind spots. But it may also be overlooking real growth that felt too small or too ordinary to count. Learning to see your progress more clearly, without judgment, isn’t self-punishment. It’s an invaluable form of self-support.

untitled

2026-06-11T19:21:22Z

Chances are you used an AI tool before 9 a.m. today. Chances are most of your users didn't.

It's a simple contrast, but Debbie McMahon, VP of Product at Loveholidays, built an entire MXP London session around it and what it means for every product decision. She called it the AI adoption gap, and she was refreshingly clear-eyed about the ways it had distorted her own judgment.

The AI adoption gap and the 0.04%

An infographic Debbie shared on stage breaks the world's relationship with AI into four tiers:

84% of people have never used AI

16% have tried a free chatbot

0.3% pay for AI

0.04% are actively building with it

That last group is the one that fills rooms like MXP London. And Debbie's point is that this creates a fundamental disconnect. The people designing AI-powered products are a statistical anomaly relative to the people they're designing for.

She made that concrete with a story about her friend Agnes. Agnes is a primary school teacher who spends her days helping children from difficult family circumstances settle into school. She's smart, busy, and has a free ChatGPT account she’s never used. Why? Her school doesn't allow AI tools on work devices. The budget isn't there for anything paid. And nobody on staff is confident enough with the technology to know where to start, even if the first two problems disappeared tomorrow.

Agnes is not an edge case. She's a typical Loveholidays customer, and she's who Debbie asked the MXP London audience to hold in mind.

“

We're living in a bubble. We're the 0.04% and our daily experience of AI has essentially nothing to do with our users’ reality.”

Debbie McMahon

VP of Product, Loveholidays

For a look at how AI engagement is trending across real products, Mixpanel's 2026 AI benchmarks draw on nearly 290 billion AI events across 2.6 billion devices, and the picture is more nuanced than adoption headlines suggest.

Three ways the bubble distorts your decisions

Debbie named three patterns she sees in herself and across the industry.

Over-prioritizing AI features. "Have you put something out there just because it was easy to do?" She raised her own hand. The pressure is real: boards want AI in the roadmap, investors want AI in the roadmap, competitors are shipping. And the tooling makes it fast to build something. But fast to build isn't the same as worth building.

Underestimating friction. Most people are forming their views on AI right now without the benefit of product communities or conference sessions to help them process it. That's not a knock on users. They're figuring out whether to trust the technology at the same moment they're being asked to use it. Dropping a disclaimer like "generated by AI, so may not be accurate" into a set of results doesn't help someone who's already uncertain about the output.

Asking users to change behavior. Behavior change is extraordinarily difficult even when people want to change. For users with an ingrained habit and no clear reason to do anything differently, it's close to impossible. The customers who are confused or skeptical about AI aren't going to reroute their entire search behavior for a feature they weren't asking for. If what they want is a keyword search and a filter, that's what they'll reach for.

Go deeper

See whether your AI features are delivering value, or just getting used:

What the data actually showed

Two case studies from Loveholidays that Debbie shared with the kind of candor that makes MXP sessions worth attending.

The room grouping problem. Hotel listings at Loveholidays had accumulated a long tail of duplicated, poorly named room types, a messy, years-old problem that had resisted every previous attempt to fix it. When a team went after it with AI, they went in with confidence. What they found was that the problem was deterministic: two rooms are either the same or they're not, and AI isn't built for that kind of precision. The model grouped rooms in ways that didn't hold up to scrutiny, renamed options customers recognized, and quietly dropped listings that people had been booking. The output looked coherent, but it wasn't.

In Debbie’s own words: "Don't put AI on top of a broken thing. Fix the actual problem."

The Q&A tool. Another team shipped an LLM-based Q&A feature into the pre-booking journey, built around the hypothesis that customers comparing hotels would want to ask questions. The feature got used, a lot, actually. But when the team looked at who was using it, the data didn't match the hypothesis at all.

The users weren't pre-booking customers weighing their options. They were people who had already made a booking, navigating a long and confusing post-booking experience to find basic information about their upcoming trip. And the questions they were asking weren't the ones the team had imagined. The top two were whether their room came with a kettle and whether it had an iron. Third most common: the wi-fi password.

In other words, customers who needed information Loveholidays already had were threading through a complex AI-powered feature just to ask if they needed to pack a travel iron. The team proposed moving the tool into the post-booking journey where the actual demand was. Debbie shut it down, and the reasoning is worth sitting with.

“

Just because it does answer those users’ questions doesn't mean that this is the right solution. We have that information. It’s a fact. We just need to give it to them in a form that they need it in.”

Debbie McMahon

VP of Product, Loveholidays

The post-booking journey got fixed instead, and the Q&A tool got pulled. The story doesn't end there: the team is relaunching the feature with a genuinely different hypothesis behind it. Since that original experiment, Loveholidays launched its own reviews platform, which changes what a Q&A tool can meaningfully do and who it's actually for. There's a real use case now tied to a specific user group, and that's what "not now" looks like when it's used well.

Go deeper

Further reading on building and measuring product adoption in the AI era:

Building different journeys for different people

Loveholidays went to their customers directly and asked how they'd feel about AI-mediated booking experiences. The words that came back included "anxiety," "I trust filters more," and "I prefer clicking." There was also genuine enthusiasm from a portion of respondents. But the skepticism was real, present across a significant share of the audience, and Debbie didn't try to explain it away.

53% of consumers distrust AI-powered search results, according to a Gartner survey published in September 2025. Debbie cited a similar figure on stage and her read was plain: "I can't ignore that. That’s the reality for my customers, and that's where we're starting from."

Her answer is to segment more precisely. AI comfort and interest now sit alongside demographics, holiday type, and referral route as a dimension Debbie's team uses to personalize the experience. Design one AI-mediated journey for everyone and you either hold back the users who want to explore new things or push unwanted change onto the customers who aren't ready for it.

Debbie's dad started using email about a decade after she did. She uses that as a reference point: adoption follows its own timeline, and you can't compress it by shipping a feature and calling it done.

The playground: A structural answer

Recognizing a problem clearly is useful. Building an organizational system to address it at scale is something else. That's what separates this MXP session from a general mindset piece.

Debbie's team built what she calls "out the bubble," an internal prototyping environment that anyone at Loveholidays with access to Codex or Claude Code can use, with no prior technical setup required. It's pre-integrated with the company's design system, data mesh, live pricing, and real images, which matters more than it might sound. When you put a prototype in front of a customer in a travel context, the first thing they notice is whether the hotel price looks real. This system removes that distraction so the feedback is about the experience itself.

The pipeline works in three stages:

Anyone at the company builds a prototype, sometimes in 10 minutes, sometimes a couple of hours, and pushes it to an internal testing environment for NMD review.

Prototypes that clear that bar are automatically routed to Usertesting.com, with the builder setting up the user panel themselves, no dependency on a separate research team.

The ones that pass user testing move to a small live test, pushed out via socials, CRM, or the homepage to a defined customer segment.

The important shift isn't the speed, though. It's that the people with the best product ideas are no longer gated by their ability to build prototypes. The system makes that capability available to the whole company. Fewer ideas get duplicated. More of them get in front of real customers. And when something earns the full investment of a real build, there's actual evidence behind the decision.

Start with the problem. The tools will follow.

Debbie closed by revisiting the Henry Ford quote, carefully, because she's not entirely sure Ford said it. But the argument holds regardless. The car achieved adoption because Ford understood what his customers actually needed. He built a faster horse, not a different animal entirely.

“

AI doesn't let us skip understanding what our users need. If you want people to adopt things, you have to start with their problem.”

Debbie McMahon

VP of Product, Loveholidays

The tools have changed. The product job hasn't. What AI does change is how big your answers can be once you've understood the question clearly. The potential is genuinely extraordinary, but only after you've done the harder work of understanding what your users need and why they'd change.

Remember Agnes from the opening of this piece? The primary school teacher who supports children through difficult family circumstances, has a ChatGPT account she never uses, and has no budget, no tech support, and no time to figure it out herself. She's never going to ask for an AI-powered solution to her problems. But she'd benefit enormously if someone took the time to understand those problems and built something that addressed them, with AI as part of the answer rather than the starting point.

That's what good product work looks like, and as Debbie put it, that's always been the job.

Build the bridge your users are ready to cross

The product teams pulling ahead right now aren't the ones shipping the most AI features. They're the ones who understand the gap between their own relationship with AI and their users', and who've built the systems to keep closing it.

To understand what your users are doing in your product, Mixpanel AI is built to surface that signal proactively, so the insight finds you rather than the other way around. For technical teams who want to go further, try Mixpanel Headless where AI agents read and drive Mixpanel programmatically.

Social RSS (?)

2026-06-01T15:41:59Z

What’s up with this?

The spirit, of course, is “I want my Google Reader back.”

I should be careful though: I imagine if we really did have it back exactly as it was, it would probably not be as cool as we remember. That was a long-ass time ago and web software just wasn’t as nice as it is now. But: it really did have social features in it! I could leave comments and see comments from my friends. (How “friends” worked back then, I scarcely remember.)

I’m not alone in wanting this. Here’s what I’ve seen so far.

There is Skyreader, and it looks like Tim Disney is still actively working on it:

In my mind (and perhaps not reality?) Skyreader solves a “cold start” problem where signing up for a new social site is a lonely bummer because you don’t have any friends. Well, if all my Bluesky friends were automatically my friends on Skyreader, wouldn’t that be, like, good?

My problem is… I don’t… get it.

Maybe there aren’t really “friends” on Skyreader? If there are, I can’t really find a list of them. If there aren’t, I guess this isn’t what I’m looking for. Or is it just assumed they are the same as Bluesky friends? I dunno, I think I have a lot to learn about this AT Proto stuff.
What happens when I share an article? Does it share on my Bluesky? It doesn’t look like it. Who sees my shared articles then? My friends, if there are such a thing? Other people who explicitly subscribe? How would anyone figure out how to do that?
It looks like I can share and I can highlight stuff specifically in what I share. Who sees the highlight? I imagine they need to use Skyreader to see that highlight? Or does it republish as RSS somehow?
No comments… right? That’s weird to me for a social feed reader. What I think of when I think social feed reader is 90% writing and reading my friends comments.
The UI is confusing to me. I don’t love the expanding list format that jumps around a lot.

The main reason I can’t “really use it,” though, is that it doesn’t sync with Feedbin. I understand that’s a niche concern, but I need one canonical feed source, so everything I’m subscribed to is in one place, and how much I’ve read is also canonical. That might be antithetical to AT Proto? I have no idea.

Indieweb has their own version of all this, but it’s seriously no joke getting involved. From one of the reader sites, Togther:

What You Need

#1 Your own website

On the IndieWeb your website is your identity. It doesn’t need to be advanced, it doesn’t need to be pretty, it just needs to be yours.

#2 IndieAuth

IndieAuth is a technology to allow you to sign into services using only your website.

#3 A MicroSub Server

MicroSub is where the real magic happens. There are 2 parts; the server and the client. Together is the client, but it needs a server to go along with it. The server does a lot of tricky work such as fetching & parsing feeds as well as keeping track of what you have read and how you have everything organized. If you don’t already have a MicroSub server then check out Aperture.

#4 MicroPub (optional)

MicroPub is an optional but very cool piece of the puzzle. If your own website has MicroPub functionality then you can use Together not just to read content, but also to reply and create your own content. You can like, repost and reply to stuff you are following, you can even write full on blog posts from inside Together.

I mean, I’m not above some nerd hackin’, but this is 100% not ever going to be a place with a critical mass of my friends just chillin’ and sharing/commenting on blog posts. Way too hard.

The closest thing I’ve seen is CommonRSS by Brad Coffield which was build in a direct response to my original Bluesky post.

I originally had a gut reaction to the vibe coding nature of it. Like I don’t wanna use this thing you slopped together over a weekend, you gotta get more serious about it first. Which I admit is just a gut reaction and not a fair assessment of the software. Brad does seem quite sincere about making it a thing. But at the same time, it feels like it’s been months without updates, which is a bad sign for super brand new software.

In testing it lately…

It looks great, love the design — but it feels quite slow across the board.
The Feedbin sync (yay!) didn’t work at first, but appears to be working now.
It now claims to have 2-way syncing (yay!) but that doesn’t work for me. The articles I read aren’t read in feedbin. The stars don’t sync.
It’s got the cold-start social problem: there isn’t anyone to follow. The discover page only lists Brad, and clicking the follow button from him doesn’t work.

It feels like it’s close, but it needs to work better. The commenting feature (again, like my main thing for wanting this) requires you to highlight some of the post first, then you can comment, but the comment won’t save.

CommonRSS feels like a solid concept, but it’s both got the cold-start thing in terms of the social network, but also the cold-start thing in terms of a business. My guess is it’s hard for Brad to muster a ton of enthusiasm to work on the project all day every day with low users.

I’m thinking the main problem is that there just isn’t much of a business to be built around RSS. It can build boutique one-person companies with a passion for it, but even then, difficult.

On top of that, maybe there just isn’t much appetite for the social part? There are a number of arguably already-decently-successful boutique RSS apps, so why haven’t they done it? Why hasn’t Feedbin done anything terribly social? Why not Feedly? Remember FlipBoard’s kind weird taking on RSS? Now they have an equally weird spinoff. My guess is it’s just too hard of work for too little payoff.

rarouš.w3b

Why I’m no longer updating this repository

I’ve Changed My Mind About CSS Variables

My original concerns

What I missed

Theming through and through

Styling components

Fallback, carefully

When the browser doesn’t support custom properties

When the custom property is missing

When the value requires a newer feature

Where that leaves me

Will serving real html content make a website faster lets experiment

Setup Jellyfin with Hardware Acceleration on Orange Pi 5 (Rockchip RK3558)

Introduction

Prerequisites

Install Ubuntu 22.04 (Jammy)

Install and enable the GPU drivers

Setting up Jellyfin

Company-event signals as one clean API

Enable Hardware Acceleration in Jellyfin

Moment of Truth

Common issues

Playback failed due to a fatal player error

Conclusion

The Web Is Being Made Accessible for AI, Not People

Our content delivered to your inbox.

Thank you!

Mathematicians, Here’s a Way To Think About Your Existential Crisis

Features & Futures

Genies Hate the Invisible

So What?

The death of web development education – Rescuing a field from disappearing

The root scroller and how not to lose it

On mobile specifically

How you accidentally opt out

Accidentally opting out with overflow propagation

Testing it in Polypane

Another way it surfaces in Polypane

Make the page fill at least the full screen

Quick fix vs. proper fix

Stop the page scrolling behind a modal

Use the root scroller for the main page

Build a digitally sovereign second brain

The end of sticky notes

Filling the brain with information

Careful now!

Find more Raspberry Pi projects in Raspberry Pi Official Magazine

AI Software Development - What Does The Data Say? - Codemanship's Blog

Share this:

Related

Author: codemanship

Leave a comment Cancel reply

Cloudflare OS is an architecture of distrust

Make the code irrelevant to safety

Never let the agent hold the key

Let it act, but never let it commit

Distrust the outputs, not just the actions

A tell in the contributing guide

Is this wisdom or a cage?

SSD Streaming for AI Models: How to Turn RAM from a Wall into a Dial

When RAM Becomes the Bottleneck, Not the Solution

The Real Problem with Running Large Models Locally

Plans first. Then code.

The Scale Problem Gets Worse with Capability

Mixture of Experts: Why Not All Weights Are Created Equal

What This Means Practically

How SSD Streaming Actually Works

Everyone else built a construction worker.We built the contractor.

The Math Behind It

Prefetching Matters

SSD Speed Is Not Optional

The Trade-off Triangle: RAM, Speed, and Model Quality

What You Gain

Other agents ship a demo. Remy ships an app.

What You Give Up

Who This Is Actually For

Where Cloud Models Change the Calculation

Other agents start typing. Remy starts asking.

Practical Setup Considerations for SSD Streaming

Everyone else built a construction worker.
We built the contractor.