Adaptive Building Blocks

Mitchell Hashimoto wrote a few days back about what he called the Building Block Economy. His tl;dr - the fastest path to massive software adoption isn’t through building mainline applications, but instead building blocks that enable others to build. Here is Mitchell, talking about how in a world with more software, the imports of libraries go up as well:

The factory of today is agentic. I say that as objective truth, regardless of what your feelings about it are. You can argue that 99% of the stuff coming out of these factories is total crap, but you can’t argue the sheer quantity of stuff coming out. The numbers are everywhere spanning tech stacks and industries and they’re undeniable.

AI is okay at building everything from scratch, but it is really good at gluing together high quality, well documented, and proven components. And, AI prefers to do this when it can unless explicitly prompted otherwise. This is the “building block” nature of software today: we’re more than ever before grabbing off the shelf components and gluing them together.

And in his conclusion:

We have to accept that building blocks and software factories rule everything around us and accept and internalize the consequences of that.

I agree with Mitchell - in a world where software factories rule everything around us (I feel like Mitchell really missed an opportunity to make a Wu-Tang Clan reference, but I digress) - building blocks that make it easy to build what he calls a “mainline application” are where the juice is. What Mitchell doesn’t name is the property that makes building blocks so useful in this era: adaptiveness. It’s not just having great primitives - it’s that we can now have software that works the way we want it to work. It adapts to my needs, not the other way around.

This is a very sharp about-face for the industry. The cloud and SaaS eras moved us away from even attempting to run on-prem software, much less being willing to build something that is fit to purpose just for you. When DHH announced in 2022 that 37 Signals was leaving the cloud, I wound up in conversation after conversation on Twitter (rest in peace, old friend) about how it wasn’t ever going to save them money, it was too hard, and the operational risk was extreme. The massive group consensus was that you should outsource everything you possibly could to SaaS and the Cloud, because the cost of dealing with it was so high that you almost certainly didn’t save money, or you lost so much time doing it that the opportunity cost ate you alive. These arguments were wrong at the time - 37signals estimates they will save $10m over 5 years. But it’s now even more obvious than it was then: software factories give us the ability to build applications that solve our specific problems and maintain them over time. Which means our need to settle for the walled garden of a SaaS, Cloud Provider, or even a dependency has fallen with it.

When I started building the machine that builds the machine, this became wildly obvious. Swamp development has largely moved off GitHub - because more and more of our own SDLC has moved into the agent. The building blocks GitHub provided - things like comments, pull requests, etc - just no longer fit our workflow at all. It’s taken us maybe a couple weeks of discovery to improve our own process, and to reflect it exactly how we want it in the swamp.club lab. The software factory has its own needs, based on the software I want it to produce (in this case, Swamp). It’s the job of everything else to adapt based on those needs, not for the factory to conform to GitHub’s definition of how software development ought to be done (and thereby how it ought to be monetized, or consumed, etc.) If I don’t like how our software factory works - I will just change it.

What enables these factories is the ability of an AI Agent to adapt to the circumstances and requirements of the user. AI coding agents are fantastic because they take my prompt and adapt it to software I desire. This property is what enables Swamp to build automation workflows that would have been wildly out of reach with traditional automation tooling - not just things like “deploy my application on AWS” (which it does great) - but things like “triage my email and update my Obsidian to-do list”, or “build models that document and orchestrate every step of the software development process”. These are things Swamp knew nothing about, and had no built in support for. But it is an adaptive primitive - it knows how to extend itself, and no part of the system is closed to that adaptation. So it just extends itself as it needs to, in order to build whatever automated workflow you want.

This is why Mitchell is getting more adoption via libghostty than he has users of the Ghostty application. It’s not just because building libraries and being open source is the best thing - it’s because libghostty can be used by a user to adapt to their circumstances, and Ghostty never can. I’m never going back to using software that isn’t fit for my purpose ever again. I never really wanted to do it in the first place, if I’m being honest - it’s part of why I’ve always been a free software hippie. Adaptive primitives in the form of AI Agents, frameworks like Swamp, or libraries like libghostty mean I won’t ever have to.