Paul Campbell • October 29, 2026

Deshittification

I've been slowly writing my series on this new and disimproved blog for the last while, and mostly talking about something that has occupied my mind a lot for the past 20 years and a whole lot in the last 4 months: software quality.

As much as I love the word "shit", I don't enjoy experiencing shitness, and indeed in most of my endeavours I play a game with myself where I attempt to get the best ratio of of price to shitness that I can. One thing that has become clear to me: much of the software I use day-to-day is pretty shit, for one reason or another.

Of course, Sturgeon's Law exists for a reason, but Cory Doctorow's enshittification tells a more lamentable story: the decay of something that was once good that moves into the realm of shitness, but not before burying you in the shit so deep that it's often hard to leave.

I typed "Deshittification" into (I'm sorry) Google yesterday and it lists Doctorow's four steps to making the internet good again:

And a little Gemini provided summary: "Deshittification aims to restore digital tools, hardware, and online spaces to a state of high utility, user control, privacy, and transparency."

What a succint goal!

Using GenAI to help achieve such a goal for myself at least is something I've been going down a big hole on the last few months. I'm really happy with the Eleven factors. I enjoyed trying to imagine my platonic ideals of softare. The CARLOS spec whilst being a bit cart before horse after riding horse I think is very usable today.

Others are thinking about this too in grand (and what looks like US-centric) ways. The One Project is at least talking about directing their AI tools toward more democratic ideals. By the looks of it, they are well-funded and well-organised, which is good to see. See also the Center for Humane Technology. I reserve some scepticism that anyone involved with Google, Facebook, or Asana will restore balance to the Force of quality software, but it's always encouraging to see and hear other folks thinking along similar lines.

I've come to realise over the last few days that CARLOS, the nebulous project that I have uncovered and appear to be stewarding into the world, is my effort to participate in the janitorial pursuit of deshittification.

Deshittification for me is mostly in the realm of "open-source and self-hosting", but writing down a list of attributes and then iterating from there really helped me to define what the opposite of shit means for me.

I don't expect anyone to actually read the spec, although as specs go, particularly as written by an agent, I was pleasantly surprised at how parseable it is.

The first part of the spec is a declaration which isn't something I asked for, but I really like it. It's a really good set of headings to think about when building a new app, mostly around data protection and security. I learned a lot about these by going through the ISO27001 certification process. It would have been a gift to have been given a list of things to consider up front.

The first three sections of the spec are all about data, privacy, and security. In 2026, these are the first things I really want anyone building software that I might end up using to consider, and—along with accessibility—they're things that I fear a lot of people don't prioritise at all. What I learned in July by experimenting with building with end-to-end-encryption and building single-tenant apps rather than multi-tenant, is that a lot of hard scaling problems go away when you at least separate and at most encrypt customer data.

So: step one in the CARLOS deshittification process, and I expect Cory Doctorow would agree: respect user data.

Section 4 of the spec might move, but it's one I was very happy to add: respect the user's attention. I added it after signing in to Dropbox, and having to click through probably 8 or 9 unnecessary screens before I could click a folder only to get a loading screen before I could see a file. Attention is one of the most abused human factors by software in 2026, and I consider interrupting someone trying to just do a job to be worse than a slap in the face.

Section 5 is about security. Unfortunately in 2026 there's no getting past the reality that we need to be doing extensive nightly security scanning and regular patching of vulnerabilities. My goal is to automate this into oblivion, but what a shit state of affairs we're all in.

Sections 6–10 are mostly about the CARLOS framework and mix in some of the Eleven factors (particularly around self-hosting). If the Eleven factors is a set of philosophical positions to follow "if you must use AI", then Sections 6–10 technical things you can do now that you're using AI. It's all about creating full-stack apps with minimal dependencies using the fastest languages available and the simplest deployment to make self-hosting trivial.

Section 11 is about interop, and admittedly motivated by agent interop: everything an app can do via its UI should really be available via an API, and anything an app can do via an API should probably be doable via an agent. Part of the motivation of building CARLOS is to be competitive in a new software world, and the new software world—at least as far as I can tell—demands agents, fucking agents, and more fucking agents.

Sections 12 and 13 are about speed. It is shocking to me how slow software is in 2026 despite so many years of hardware performance improvements. There's so much cruft out there. My expectation is that software should be fast to build (both in terms of wall-clock time for features, and compile time for programs), it should be fast to deploy (how did we ever get OK with it taking multiple minutes to get simple features into production), and fast to use. If folks are going to use AI to build software (and they are), it should be really, really, really fucking fast. And no, fast is not fast enough. Make it faster.

Sections 14 and 15: Upgrades and observability, potentially could be referred to as "what can be automated should be automated". If I never have to think about devops or observability ever again, then I'd probably live a happier live, but in order to not think about it, I need to know that deploying new versions of apps will not break old ones, and that everything that can be measured on servers is being measured. It's almost like I read the 12 factors.

Sections 16 will probably move up to be with Security and Privacy: very EU-centric but world-applicable: ability of users to delete their data. You know what makes it really easy to delete user data with confidence? Tenant database isolation.

Section 17: Accessibility. I was in a room full of entrepreneurs a few weeks ago, and it was pretty embarrassing to see how few of them gave a shit about accessibility. "If there's one thing to take away from this session, it's this: when you leave here, add this line to your AGENTS.md":

Ensure this app is and continues to be WCAG 2.2 AA audit-ready

At least one person got the message and shared a screenshot the next day of their improved CI posture. It only took one prompt. No more excuses.

Section 18: Make native apps Web and native apps should conform to their platform. To paraphrase an old hero of many: "if you see an Electron app, they blew it". Same goes for wrapped web apps on mobile. Native apps are faster, more platform idiomatic, they're nicer to use, they inherit a whole bunch of conventions. "Build once run anywhere" was always bullshit, but it's more bullshit in a world where asking a GPU to "Make me an iOS version" is a thing that's possible.

The final sections I18n, L11n, customisation, and openness are continuing the inclusive themes. If folks are going to use GenAI to produce software, then there's no excuse for providing it in just one language, no excuse for not allowing folks to remix their own version (this is surely existential since folks can just make their own apps), and—though this remains to be seen—it feels inevitable to me that there will be no competitive advantage to proprietary software. I guess this is the ultimate "no-one knows" that we're all trying to figure out. Again though, I don't think Doctorow would disagree that open beats closed.

I'm sure that more attributes will come to light, but that's my fairly exhaustive list of ways to deshittify. I think the role of the software engineer or product manager or software vendor in late 2026 is deshittification. Let's make deshittification a competitive advantage. Let's make speed a required default. And if we're going to use agents to build apps, we should damn well make sure that the apps they're making are accessible.