CARLOS
In around 2007, Alex Payne, then lead API developer at (then) Twitter, created downforeveryoneorjustme.com. Twitter was where "Rails doesn't scale" was born, and the reason for the meme was that Twitter kept going down. downforeveryoneorjustme.com became the first place you would check if your favourite web service was undergoing an outage. Eventually tools were built to allow developer teams to scale apps far beyond their capacity so that surges in use wouldn't bring the entire platform down.
To cut a long story short, any service that wanted the convenience of a single mega-app shared by millions would trade stack complexity for reliability. And it worked! These days, large companies pay exorbitant sums to cloud providers and observability providers and platform providers and on the whole, stuff doesn't go down as much as it used to.
I write this the week that Revolut just suffered a massive outage that took its whole service offline in Ireland. A giant monolithic deployment taking down every customer, all at once. Any time AWS US East goes down, everyone shrugs while half of our day-to-day web services disappear and we wait until they come back.
In the meantime, alternatives have existed! For every web service I use, almost always there's a self-hostable alternative. Email, chat, social media, project management, CRM, blogging, office suite. All these categories have an infinity of options that have been created by folks who care about privacy and ownership of data, and adhere to the not exactly controversial maxim that we probably shouldn't be so quick to give all our data to big companies in order to interact and share stuff on the internet.
Also in the meantime, computers got very, very fast. If you watch any Apple keynote, they'll always spend a few minutes talking about how this year's processor is so much faster than last year's. And that has been going every years for the past 16 years. And that's just Apple Silicon. A rising tide lifts all boats. Computers were already fast. I don't think people realise how fast computers are.
Why? Because software still feels slow! If I think about the apps I use day-to-day: Gmail, Gsuite, Slack, Dropbox.
The slowness isn't all about compute. There are also layers and layers of jank that make things feel slow: a signin that shells out to a remote service, a two-factor auth step, a cookie banner that has to be clicked, an upgrade modal that plays psychological tricks. And when you finally get to where you meant to get to: a loading spinner or a skeleton screen that takes a second or two (or more) to show you what you want. And we pay hundreds of dollars a month to these "best in class" Software as a Service providers.
The reason for all of this is enshittification. All of the things that contribute to web app slowness are for things that are optimised not for the user, but for the corporation providing the service.
- Signin speed could be mitigated by a passkey or other fast signin mechanism
- Cookie banners could be mitigated by not tracking, or tracking via consent later
- Upgrade modals ... well, let's not get into the wasteful economy of SaaS
- Loading spinners could be mitigated by putting data and compute closer to the user
When technological solutions exist, enduring crap like the above from well-resourced corporations becomes much more of a bitter pill to swallow.
This was the backdrop that led to CARLOS. I have a lot to say about the actual tools and products that I've been having a lot of fun and stress over producing, but I wanted first to write about the principles and the architecture that was uncovered along the way.
CARLOS the name and the acryonym I came up with after producing a constitution of sorts parodying and then in homage to Adam Wiggins's twelve factors: Eleven factors for building apps with AI.
CARLOS stands for:
- Cost-effective
- Available
- Replicated
- Lightweight
- Open
- Secure
I've spent the last few months building apps like this and convincing myself that it's no longer a given that we need to hire big tech to get world class uncompromising software. Not that it ever was, but particularly now.
I've been having fun pushing agents to produce software that costs less to build, and costs less to run. I've experimented with self-hosting, and using relays to make self-hosting seem like cloud-hosted. I've often found myself in a position where I'm the only one maintaining a stack of software that has no backups, so I've pushed the agents to build systems that are simplier, but more resilient. Rich software that runs as a single binary (something I was always curious about). I'm fairly convinced that some of the projects are more secure than anything I've been able to produce before.
I haven't "announced" any of the stuff I've been working, but I've also not hidden any of it...the trail is pretty easy to follow, and I'm fairly convinced that in the near-ish future, all software will be open to some degree or other as open full-stack solutions start to outperform closed ones (indeed it's decreed in the Eleven Factors).
My question to myself last December was: can GenAI tools do the work I was doing?
My question six months later in July was: can GenAI tools build things that I never could, and big tech never would?
For now though, I'm starting with the most boring thing that has emerged after four months: a spec! It's basically a formalisation of my platonic ideals that anyone can use, but obviously is particularly aimed at agents. It's extracted from 19 apps that are in some state of production at the time of writing.
Here it is: the CARLOS spec.
I've never taken much time to read specs in the past, but it seems that specs are one place that an agent doesn't actually do a terrible job.