Substrates, Standards, and Emergence

When I published fluidware, I was trying to name a direction I could feel software moving as LLMs, and their related tooling, continued to improve. It felt like the natural evolution of digital computing’s core strength: malleability. Hardware, firmware, software, then fluidware. Each step has pushed the malleability further, making more of what a system does something we can change with less effort and fewer constraints.

At the application level, I imagined software becoming almost amorphous, with code changing underneath an experience as the needs around it changed. But the experience itself would need some consistency for humans, and our systems, to be able to interact with it in a stable and coherent way.

Over the last year, this fluid direction has become more tangible to me. I’ve driven, and witnessed, large-scale projects, ports and migrations that happened in ludicrously small amounts of time. I’ve watched useful software grow organically from non-engineers who knew the problem they needed to solve and, with the help of LLMs, went out and solved it. Some of the most impressive things I’ve seen have come from people who had never built software before. I’ve also seen seasoned engineers take on projects they would never have considered before.

Along the way, I’ve found myself building “disposable” software solutions. Applications that make sense for a particular use but not much beyond it. I’ve been building software for over 20 years, so I’ll be honest: this initially felt wrong. Historically, due to the overhead of building, we’ve tended to assume software will be built to last and accrete features as needs develop. But as implementation continues to get cheaper, more applications are likely to be built for specific purposes and stay that way. In that world, what we tend to “share” will sit underneath those applications, in substrates and standards.

On the personal artistic side, I’ve been having a bit of a paradigm shift in how I create in digital space. This summer, I was part of a music festival in south Minneapolis. We had a very small team (read: 2 people, including me), and I was asked to help produce digital media artifacts. An artist had been commissioned to create the physical poster and helped establish the visual style for the event.

I pulled out the colors, visual concepts, and individual elements, breaking them into smaller artifacts I could work with. Then I built the website, gathering information about the artists, the event, and pulling together the media we needed.

All of this lived in the same repository. As we got closer to the event, that repository accumulated more and more of the concept: images, video, artist information, visual treatments, and even the language we were using to talk about it. Each piece started feeding the next. We were shaping a little universe, one atom at a time.

Eventually, tooling emerged. I could pull in a new piece of media, describe the treatment I wanted, produce a digital artifact, and iterate until it felt right. The colors, assets, and previous pieces were there as reference and kept the visual language stable. The tooling was evolving as needs changed, but conceptual standards had emerged and were encoded in the repo. I wasn’t thinking much about “architecture” in the traditional sense: that was just growing organically around what surfaced. In a technical sense, debt was accumulating, but it wasn’t slowing us down.

The generative models, through Codex and Claude Code, were writing the code. LLMs are so well positioned for that kind of work that, in 2026, it hardly makes sense to type compiler/interpreter-ready instructions (code) directly anymore for most software. In some ways, I will miss that part. It was fun and scratched a certain itch for my type of brain. But I’ve always been a builder, and ultimately I’m far more interested in what machines can do for us than what we can do for machines.

For the visual work, I’d built a harness around Astro to build bespoke webpages in HTML, CSS, and JavaScript, then captured images or video from them. The browser became a rendering environment. I could compose the assets, animate them, attach audio (and audio-reactive effects), and then output the pieces we needed without opening Photoshop, Premiere, or After Effects. The “project files” were simply code.

This is quite different from simply giving a generative tool like Nano Banana or Veo a “prompt” and producing a rasterized visual. Those systems, at least in their current form, do not provide enough direct control to truly iterate with. Generative tools applied to code, however, can give us more direct control over how we work than large software abstractions. They let us build our own discrete solutions uniquely positioned for the job at hand. In this case, we built up the idea over time, and tools emerged that helped us work directly with the concepts and media available. We were able to step out of Adobe’s garden and into one uniquely curated to solve problems specific to this event.

In The Process Is the Cake, I argued that art is defined by its process. Here, for the most part, the process stayed mine. I kept what I felt to be sufficient artistic control and reasonable coherence without the tremendous digital toil (read: clicky clicky, typey typey). I wasn’t battling with some interface designed before I was born. I built the interface I needed to accomplish the tasks at hand as they came up.

I’ve been a part of similar things at work. Late last year, a small marketing team built a tool around their understanding of something that would help the people they worked with, and the business. They understood the relationships and could see an opportunity that would have been hard to recognize from somewhere else in the organization. They were able to build the first version quickly, with zero help from engineers, and demonstrate it to prospective users. As its value became clearer, engineering got involved, and we were able to progressively develop it toward something that could sustain hundreds of thousands of users.

I don’t think that particular tool could have been designed in isolation from those people. And no “off the shelf” system or library could have supported the features needed. Its usefulness came from their understanding and the feedback they could get while building it. It emerged from the best possible place: the people closest to the work. The difference is that, unlike in the past, they were able to do that themselves.

I’ve been noticing this pattern across most of the teams I work with, across the industry, and in art. The marketing team is one example of a much broader change in who can turn their understanding of their work into useful software. There is great power in the people closest to a problem (or vision) being able to iterate on creating it in tight feedback loops.

And in all of this, where was the pre-existing system we would historically have expected to need? Where was the generalized tool or framework that anticipated the workflow and all the variations we might want later? There were substrates, lower level bits like runtimes, generative tools like Claude Code, programming languages, and media formats. But the archetypal “tool” that prescribed a workflow was not present. It emerged directly from the work.

This is one of the more interesting qualities software has, and one we’ve rarely been in a position to use. In physical architecture, nearly everything needs to be known up front: you can’t move a foundation once the walls are up. For a long time we treated software the same way, because implementation was expensive and change was costly. As that cost drops, the architecture doesn’t need to be decided in advance. It can emerge from the work, taking shape around the needs that actually surface, in the hands of the people who have them.

For the festival, the specific system we needed came into existence as we needed it. There was no way for someone to have already packaged that exact combination of capabilities, along with our style choices, into a product. We could use the assets already in the repository, generate the code for the next treatment, and add that capability to the system.

Historically, getting something like that working might have prompted the next thought: this is good, maybe I should generalize it and use it in a bunch of other places. Maybe it could become a framework or a product. That expectation is becoming less useful. Generalizing means taking on other people’s requirements, accommodating variations, and maintaining an abstraction that makes sense across all of them. That’s a substantial amount of work, and it changes the thing you’re building.

Some capabilities will prove useful in enough places that they deserve to become part of the infrastructure. But for much of the software we build, I think generalization will become the exception. A system can remain specific to the people using it, sometimes even just momentarily, and still be worth the effort of making it.

This brings up an interesting tension that was previously less apparent. Where do you draw the line on a software system? If it takes 30 minutes to build something that works well enough for a particular project, at what point does it make sense to have that same system grow into helping with the next one versus just starting over? Should software exist at a project level? A team level? An org level? In my work, I’ve been finding the answer to that to be increasingly ambiguous. The line may matter less than what crosses it.

A substrate is the environment something can grow within. In the engineering world, we would often refer to this as a “platform”. A browser, an operating system, a framework, a runtime. Even an application can be one: you build a core and let features grow on it over time. At a different scale, the internet is also a substrate, albeit one made up primarily of standardized protocols instead of a particular archetypal design. Protocols give independently built systems ways to interact, making requests and responding in ways the other side(s) can understand. They generally become standards when enough humans (or systems) agree that they cover the needs to sufficiently support federated interactivity.

As a permaculturalist and nature lover, I enjoy thinking about the ways complex systems can co-exist. I chose the word substrate in this piece specifically because of what it represents in the plant world. Different things grow well in different conditions. Plants need different substrates to thrive. Understanding soil, mycology, seed and land access, and knowing which plants grow where makes decentralized growing more viable. Making that knowledge accessible changes who can do it successfully.

Software has its own version of that local knowledge. The people doing the work know things about it that are hard to fully communicate in a requirements document. And sometimes can’t be known upfront. Giving them the ability to iterate and build makes more of that understanding available to the system itself. It might lack some of the technical perfection that an engineer could bring, but in most cases, that can be added when the system has evolved enough to demand it… And in some cases it’s just never needed. Home gardens don’t require a master gardener or agriculture expert to serve their needs, but as scale increases the expertise becomes more important.

There are interesting parallels here with biodiversity and monoculture. We chose certain ways of building software because they seemed to scale well under the constraints we had. Implementation was expensive, and a common solution let us spread that cost across a lot of people. We became very good at building systems that could serve many contexts, and finding ways for large numbers of unique people to fit their work into them.

Those choices came with trade-offs. We gained efficiency at scale, but lost variety, flexibility, and resilience. Local differences became special cases. Features needed enough demand to earn a place on a roadmap. People adapted their processes to what the software could express. Just as, under monoculture, people adapted their food to what was available. There are thousands of varieties of tubers across the globe: we’ve mostly landed on just a few of them.

The web has always had room for this kind of diversity. I think of earlier personal websites, networks, and blogs: GeoCities, MySpace, Tumblr. Different corners of the internet felt like different people. You could arrive somewhere and get a sense of the person who had made it. Stumbling across these bespoke pages could sometimes feel clunky, but there was something magical about it.

Facebook took a more monocultural approach to the social profile, with the same structure and neutral palette repeated across everyone. It felt like looking through the white pages. That consistency made the experience familiar and easy to navigate. It also limited how much of ourselves we could put into the space. The common template standardized how people could express themselves along with how others could find them. Nearly all of the modern social networks followed Facebook’s (boring) approach.

Those older personal spaces felt like the heart of the web: a biodiverse, decentralized universe, with common ways to link, discover, and move between things. The substrate could support an enormous range of expression. In reality, it still does. In many ways, given how browser technology has evolved, it’s even more capable of that. We’ve just lacked the tools for everyday people to make use of these complex technical capabilities. We have them now.

Our technological progress seems to ebb and flow between centralization and diversification. Think mainframes vs. the PC. On one hand, the centralization-heavy eras can make things feel orderly. Much like large single-crop farms. This can make the work clearer, but it can also make things boring. Ultimately, I think I prefer the messier garden, with many ecotones, strategies, and divergent evolutions.

But carrying that same freedom into software that people depend on raises another problem: maintaining a thousand local tools when the people who built them leave. A hundred specific applications might turn out to be variations of the same forms and records, carrying the same authentication bug. Visual variety tells us very little about the diversity or reliability of the system underneath.

Cheap implementation only changes part of that calculation. Some tools will cost more to maintain than their specificity is worth. Where a tool becomes part of ongoing work, the team responsible for that work needs to own its continued operation. There is still a wide gap between software built rapidly with no architectural vision and software built more carefully, even if the code itself comes out of an LLM. Migrating a system from one mode to the other is a challenge many teams are currently facing. Changing ownership is even more difficult.

Dependable shared services for things like identity, storage, and deployment can reduce how much each team has to maintain. Each local workflow still needs its permissions and behavior checked. And where several tools really do serve the same need, consolidating them may be the better choice. The value of specificity has to hold up against the cost of keeping it working.

With that said, those shared services bring their own trade-offs. A well-vetted shared solution can concentrate expertise and make protections available to everyone using it. A vulnerability in something widely deployed, though, creates an opportunity to repeat the same attack across many systems. Diversity can limit that kind of shared failure, while introducing more variation to understand and maintain. A collection of custom applications can still share a vulnerable dependency or rely on the same provider, leaving them exposed to the same failure. We still need to understand the risks in those shared foundations and have people responsible for responding when something goes wrong.

Standards are the agreements that make interactions between systems dependable. This includes standards in the human sense: our expectations for accessibility and reliability, for how our information is treated, and for whether a familiar action continues to do what we expect it to do.

If the applications themselves are disposable, the agreements between them can’t be. The protocols tools use to talk to each other, the expectations around identity and how data is handled, the tests and documentation that say what must hold: these move out of the individual application and into the substrate and the seams between things. They are what make a thousand local tools something other than a thousand separate risks. This is the consistency I was reaching for with fluidware: the code underneath can keep changing, as long as what it promises to the people and systems around it holds.

For engineers, more of the work will involve creating environments people can safely build within and making capabilities available through understandable interfaces and standards. We’ll help promising local tools & features become reliable enough for the people who are starting to depend on them. That includes making them maintainable by someone beyond their original builder. This is the nature of stewardship: not everything should be treated as disposable. As people grow to depend on a system it is important to find ways to make that system sustainable.

We are currently experiencing an explosion of diversity in software driven, ironically, by tooling provided mostly by a few mega corporations. The garden is diverse; the soil isn’t (yet). My hope is that open models will keep pace so that no single entity can claim the genie’s lamp. That freedom will come with its own risks, but the alternative just has too much negative historical precedent, not to mention cautionary art, to ignore.

Everyone is becoming software-capable. The moat around building it that many of us engineers had is mostly gone. That opens more opportunities for our expertise, though: we now have the chance to be guides to others and push for all the things we always knew were important in software building. As we look to the future, we will need to be increasingly mindful of the substrates we are building on. When building with or for others, we will need to choose our standards consciously; they are what will outlast any particular tool.

For just about everything else, we can work with our creative minds, other human beings, and our sci-fi-era tooling, and let solutions emerge from the process itself.

Share Feedback