Whole Earth AI is a project-based learning tool that turns any personal goal into a step-by-step project guide with multimedia, quizzes, materials lists, and branching deep dives. Since I’m not really an engineer, I mostly used Whole Earth AI to teach me how to build Whole Earth AI.

I built it to explore two questions:

1. What new UX patterns do LLMs make possible?

2. What might the Montessori Method applied to software for adults look like?

Here’s what I learned:

We learn best by doing

Seymour Papert, John Dewey, and Jean Piaget (among many others) showed us the value of open-ended hands-on learning.

When I first started building Whole Earth AI, I thought the core challenge was information transfer—how quickly we could get knowledge into a learner’s head. This was largely a matter of personalizing the learning material—which does help(!) as evidenced by Bloom’s 2 sigma problem.

However, I quickly discovered that information transfer is dwarfed by the challenge of getting learners to stick with the learning journey over time, even when it becomes hard. The real problem to solve was motivation.

What’s more motivating than learning something new? Doing something new—and not just any new thing. A specific new thing.

Say I want to build a mid-century oak coffee table with sashimono joinery. As a novice I’d need separate books on woodworking, mid-century design, and sashimono technique—and then piece them together myself.

Or, I could go to a woodworking class where we build a birdhouse. But I don’t want to build a birdhouse—I want to build a mid-century modern oak coffee table with sashimono joinery!

LLMs can tailor learning to your project, not a prefab assignment.

Sometimes the project is common but the learner is not. Imagine a nurse who wants to switch to UX design. The nurse may have lots of transferable skills from their prior career. There’s no existing guide on “How to Become a UX Designer for Nurses” — but Whole Earth AI can generate one easily.

Our own idiosyncratic projects and goals are far more motivating than abstract learning-for-learning’s sake, therefore Whole Earth AI is a project-based learning tool.1

Useful guidance starts with rich context

If you’ve used LLMs extensively, you know that context window management becomes just as central (if not more central) than good prompting. LLMs really only have access to their training data (and maybe the internet), but beyond that all they know is what you tell them.

When you’re new, you don’t yet know which details—or constraints—really matter. How big do you want that mid-century modern coffee table to be? The answer might make a big difference for how you should approach building it!

You don’t know what you don’t know, therefore, Whole Earth AI prompts you (for important context) more than you prompt it.

Recognition over recall

One of the shortcomings of AI chatbots from a UX perspective is that they often require you to recall information. If you don’t remember an important detail, it’s not making it into that context window.

That’s why UX designers lean heavily on the concept of recognition over recall. The basic idea is that recognizing correct or relevant information from a set of choices is less cognitively demanding than having to remember it on your own.

By proposing plausible options to choose from (in addition to open-ended answers), Whole Earth AI also spurs new consideration and widens the scope of awareness for possible goals. In user studies it was common to see these suggestions take users’ projects in new directions.

Building context can be a learning opportunity in itself while reducing cognitive load, therefore, Whole Earth AI offers multiple choice options.

No two learners are alike

Even if the project is exactly the same for both, learners have different levels of pre-existing knowledge. Subject matter is multi-dimensional. One learner might know a lot about woodworking but nothing about mid-century modern design, while another may know lots about mid-century modern design and nothing about woodworking.

This goes back to the subject of efficient information transfer.

Learning material should always be as adapted to the learner as possible, therefore, Whole Earth AI creates assessment quizzes to inform the focus of the project guide it creates.

Preparation produces confidence

Scrambling for materials mid-project induces a state of anxiety and chaos. Chefs know this—mise en place cooking allows for a state of confidence and efficiency going into a recipe. We want all of our ingredients gathered, organized, and ideally measured out before we begin cooking. Then all we have to think about is combining them.

This principle applies to learning projects too. If we can be confident going into a project that we have everything we’re going to need, we’ve removed an enormous amount of friction. It’s also an opportunity to price things out before we’re in too deep!

There should be as little friction as possible between us and our learning goals, therefore, Whole Earth AI provides a comprehensive list of necessary materials (with price estimates) before you dive in.

Learning depends on trust

As we all know, LLMs are not always trustworthy. They’ve gotten much better, but they still hallucinate—and worse still, they hallucinate with great confidence. This is especially problematic for learners, who are naturally ill-equipped to distinguish between fact and confident lie.

LLMs are more trustworthy when they have reliable information to work from. We can give an LLM access to the web, but as we know, just because something was published online doesn’t make it trustworthy either.

Whole Earth AI pulls in content from the web for every lesson, but before it synthesizes it into instructional content, it undergoes a multi-layered filtering process for ensuring that all content is both immediately relevant and high-quality. This process is expensive and not always perfect, but the improvement to quality and reliability is worth it. Content then references sources in-line. In short: fewer hallucinations, more aha-moments.

Learning is built on trust, therefore, Whole Earth AI does its best to gather and synthesize from reliable sources.

Information prefers certain modalities

Some information is best explained in text. Other times we need images to drive the point home. Sometimes video is best.

LLMs can provide basic instructional text out of the box, but pulling together images and video in a coherent and useful way is less straightforward.

Here’s how Whole Earth AI does it under the hood:

1. Receive the lesson subject and each of the tasks. Split the tasks into parallel LLM calls for generating instructional content for that task.

2. Once instructional content is generated for a task, another LLM reviews the content and identifies any place within the text where an image would help make the point of the text clearer. Then it generates an image search query.

3. This image search query is sent to an image search API, which pulls in the top 20 images for that query.

4. Another LLM—this time multimodal—reviews those images alongside the instructional text and determines which of the 20 images is best for the content.

5. This image is placed within the text.

In parallel, we grab a video for the lesson:

1. The lesson title and project goal are provided to an LLM, which translates this information into a youtube search query.

2. We pull the most popular youtube video on the subject from the Youtube API.

3. Another LLM reviews the Youtube video metadata and determines if it’s a good and relevant video for the lesson.

4. If not, it repeats the process until we find a good video.

It’s a lot of LLM+API gymnastics, but that’s what it takes to reliably create a coherent multimedia experience with LLMs today (and when something as salient as video or images doesn’t exactly match the content, it feels really bad and loses user trust). The payoff: every lesson surfaces a crisp image or video that clarifies your next step.

A multimedia learning experience is more enjoyable and more effective, therefore, Whole Earth AI can search, assess, and synthesize multimedia relevant to the lesson.

LLMs like focus

Just like humans, LLMs don’t perform great when you ask them to multitask. An early version of Whole Earth AI sent the entire lesson generation prompt (with all its tasks) to a single LLM call. So in the case of our demo, all of the content for the lesson “Establish Project Parameters” including instructions for “Fundamentals of rooftop greenhouses, hydroponics, and smart-ag basics”, “Choose primary crop species to optimize system design”, “Measure and record rooftop footprint & load limits”, and “Determine local building code & permitting requirements” would all be handled by a single LLM prompt.

That didn’t work well. What did work well was splitting all of these task instructions up into dedicated LLM calls.

The less you ask of the AI, the better, therefore, Whole Earth AI breaks up content as much as possible before passing to an LLM.

Anything can spur a question

You know what kind of sucks about chatbots? They’re linear. They spit out a ton of tokens making all sorts of points, and I have to respond to it wholesale.

But maybe I have multiple questions on multiple points. I can ask all of them together but I risk confusing the LLM (see above), or I can ask them one at a time but the point I’m referencing rides off into the sunset. It’s just too much friction for curiosity.

So I developed a different UX pattern. Any chunk of text can branch into a deep dive. When I click on a chunk of text, I can ask any question I want — but what if there was even less friction than that?

Whole Earth AI has quick fire question buttons for digging deeper — “How do I do this?”, “Explain this like I’m 5”, “Tell me more” and “Give me an example”. When I click these buttons, I get a deep dive in the chosen direction regarding that specific chunk of text.

My personal favorite part is that we can do this recursively — deep dives within deep dives!

Learners should always be encouraged to follow any path of questioning, therefore Whole Earth AI makes digging deeper frictionless and infinite.

Visible progress keeps us going

As plenty of psychological research and common sense will attest — we love line-go-up. We can’t help it. We want to see our progress.

There’s much more I’d love to explore on this theme, but one instantiation of the idea in Whole Earth AI is indicators for leveling up skills. Every time the user completes a task, an LLM reviews it against the focus areas they said they were interested in when they created the project. If completing the task indicates an uplevel in skill, the user gets a popup notification to this effect.

As mentioned before, a core problem of successful learning is motivation, therefore, Whole Earth AI helps you track your progress.

Projects get more specific over time

By definition, learning means you don’t know how to do everything upfront. When you start a project you’ve never done before, you don’t know what decisions to make, and you may not even know what decisions will have to be made.

Imagine you want to create a database from scratch, but you’ve never built a database before. The context questions that Whole Earth AI asks when you’re creating a project guide might ask “Do you want to use PostgreSQL, MongoDB, MySQL, or SQLite?” But if you’ve never worked with databases before, these words might mean nothing to you—so you say “I don’t know”.

Well, you’re going to need to know at some point to accomplish your project goal of building a database, because guidance (AI-generated or otherwise) is going to need that specificity in order to be useful.

Whole Earth AI is built for this. It creates carefully placed ‘decision tasks’ throughout your project. When you reach a decision task, the lesson content is designed to help you make that decision with all the most relevant information for your project goal.

So, at this point you might have learned a bit about databases and are asked yet again, “What kind of database do you want to use?”

Now you have what you need to answer that question. When you finally select PostgreSQL (basically always the right answer), an LLM reviews the remainder of your project guide with this choice in mind and updates the guide accordingly so it can be specifically adapted to this new context. Your guide is now about building a PostgreSQL database. Your project guide isn’t static or linear, it’s a generative choose-your-own-adventure game.

LLMs need specificity to be useful to us, but we can never know all the specifics when we start a project, therefore, Whole Earth AI provides decisions as tasks, helps you decide, and updates the remainder of the course accordingly.

Learning is an adaptive feedback loop

Lesson quizzes are a fun way to test yourself along your learning journey, but in Whole Earth AI, they serve a dual-purpose.

Answers to lesson quizzes update a live learner knowledge model that is continually refined throughout the course of your project. This is a model of what you know, so the AI can adapt accordingly in subsequent lessons. If you’re struggling with that sashimono joinery, it will emphasize that in future lessons. If you’ve got mid-century modern design down pat, it’ll set that aside and focus elsewhere. It’s a little like a loosely-structured spaced repetition system.

Assessment is an opportunity to turn learning into a feedback loop for personalization, therefore, Whole Earth AI uses quiz responses to update the AI’s model of your knowledge to help you where you’re struggling.

Learning is social

Mitchel Resnick (who studied under Seymour Papert) wrote that creative learning revolves around the four P’s: Projects, Passion, Play, and Peers. Learning together is better than learning alone.

I’d love to explore more ways for Whole Earth AI to be social—it could even connect you with people in your local community exploring similar projects to you.

As it is, the social features are pretty simple. You can make projects public for others to see.

But if you see someone’s project that you’d like to try for yourself, you can also fork that project—just like a Github repo—which adds it to your own collection of projects and lets you personalize it.

Learning is better together, and your peers are creative, therefore, Whole Earth AI lets you explore other’s projects and fork them.

Thanks for taking a look at Whole Earth AI!

I’m off building other things now, but I’m taking these learnings with me to inform the new venture. I hope they might inspire some explorations of your own.

Whole Earth AI did not happen in a vacuum-sealed lab. Huge thanks to my fiancée, family, and friends, notably Gordon Brander, Alice Albrecht, Nick Bowden, Tom Critchlow, Alex Komoroske, Jonathan Lebensold, Steve Klise, Alex Taber, Oshan Jarow, Jared Pereira, Tasshin Fogleman, Agree Ahmed, Rachel Inman, Greg Neiswander, Max Bittker, Gretchen Roehrs, Brian W. Jones, Morgan Allen, John Hess, and a generous grant from the Cosmos Institute.

p.s. Here’s some of the books that inspired Whole Earth AI.

How can that be?

By amplifying the rider’s effort, the e-bike takes its rider further, faster. The rider who goes further, faster ultimately rides more than their unassisted counterpart. Their heart, lungs, and muscles grow stronger as a result.

What if the rest of our technology worked more like an e-bike? What if our tools made you stronger and smarter while expanding your capabilities, rather than increasingly dependent on them as you atrophy? What if they took you further into new challenges, helping you test the limits of your own potential?

This is the vision I’m currently building towards—software that expands human agency. I want your most audacious goals and projects to become tractable.

I’m building to create a pedal-assist between idea and action,
an e-bike for the mind,
an ambition accelerator,
an agency machine.

I will share more in the weeks ahead, but since you’ve been on the journey with me up to this point I wanted you to know first.

I also need your help, because I believe many of you are the person I’m building for first. I’m looking for indie operators: freelancers, independent consultants, solopreneurs, early-stage founders, event planners, movers, shakers, schemers, and the like.

If this describes you, I’d like to interview you.

An hour together will help me understand how you approach your work and how this tool can expand your leverage over the challenges you face within it.

If you’re up for it, I’d be deeply grateful if you’d fill out this brief questionnaire, after which I will email you to schedule an interview if it’s a fit.

Onward,
Kasey

*Interviewees will get free early-access to the product beta. Thank you!

Last week I attended the Malleable Software demo night at South Park Commons in Manhattan. The evening solidified some loose hypotheses that have been tumbling around my brain about the shifting geography of tech—not just in the migration of talent or funding ecosystems, but in the ways that New York’s distinct culture shapes its tech scene and the resulting technology it produces. I think it’s quite special.

I spent most of the 2010s in the SF tech scene and working in Silicon Valley. Just as it is today, there was no question that California was the unrivaled epicenter of technical talent.

Since moving to Brooklyn in 2020, however, I’ve noticed the rumbling of an insurgent east coast tech scene playing by a different logic.

San Francisco remains the undisputed king of raw technical talent (the cracked 10x engineers, if you will). They’re the best in the world, no question. But among those who see technology as a means rather than an ends—an art as much as a craft—NYC has the edge.

I’ve seen this on the ground for some years now, but the Malleable Software demo night was the first time I realized the scale of this alternative tech scene. A room of over 200 people cheered on mind-bending demos from a legion of visionary New York tool builders. Rumor has it that this was only about half the people on the waitlist due to capacity limits. Linus Lee from Notion shared experiments visualizing the latent space of language models. Alice Albrecht of re:collect gave us a glimpse into the future of tools for thought. Tyler Angert demoed an AI-powered generative canvas with branch/merge capabilities. The list goes on. The room was a Where’s Waldo illustration of top tier creative technologists.

This surprisingly big microcosm reflected a broader culture. When I think of the New York tech scene, I think of people like Andrés Cuervo, Omar Rizwan, and Govind Manian at Folk Computer, a research lab for spatial operating systems.

I think of Brendan Schlagel, Celine Park, and Jared Pereira at Hyperlink Academy, a startup creating end user programming tools for learning and collaboration.

I think of Steve Krouse and Tom Macwright at Val Town, an end-user programming platform for social coding in the cloud.

Then there’s people like Max Bittker, Kelin Carolyn Zhang, Ryan Flomerfelt Mather, Charles Chamberlain, Taylor Baldwin, or Casey Tang. I don’t know what to call them. Creative technologists? Artists who code? Go play with Max’s super-fun 8-bit physics simulator Sandspiel or check out Kelin and Ryan’s Poetry Camera and you tell me.

I could list dozens more (especially if we include friends along the coast that come through NYC on frequent pilgrimage, like Jess Martin and Gordon Brander), but you get the idea.

A very distinct ethos is emerging in the NYC tech scene. These are technologists generally more inspired by the early democratic visions of computation—those of Doug Engelbart, Alan Kay, Ted Nelson, Seymour Papert, etc—and by the potential of human creativity than by the promise of unicorn market caps.1

To Andrés’ point, it’s illustrative that Partiful (an irl party planning tool) was founded in Brooklyn while Friend (an always-listening AI friend substitute) was founded in San Francisco.

Some of the NYC scene was inherited in the exodus from California over the last few years (and its certainly been nurtured by institutions like Recurse Center and ITP) but I think it’s also the direct result of a city where no industry truly dominates.

Compared to San Francisco, many more people in the NYC tech scene have domain experience outside of tech. The founders tend to be older. They have more friends outside of tech and a broader range of life experiences is represented within tech. 

This all amounts to a close connection with a more representative slice of both people and businesses that I suspect hints at the future of tech’s geography at large.

I asked my friend Jared Pereira how he’d describe the NYC tech scene’s ethos and idiosyncrasies. He sees these connections with the outside world as a boost for ideas that appeal beyond the confines of the tech industry:

Given its deep well of hardcore technical talent and the Stanford/Berkeley CS program pipeline, I expect San Francisco to maintain its position as the place where tech infrastructure is built and foundation models are trained.

However, I suspect New York will become the place where that technology is turned into end-user facing products for an endless array of niches—precisely because NYC itself is an endless array of niches. 

Thanks to Jared Pereira, Andrés Cuervo, and Agree Ahmed for sharing their perspectives on the community here to help form and sanity check the ideas in this post.

1

Creative and exploratory as it may be, it’d be a mistake to characterize the emergent New York tech scene as a charming gaggle of artist-types and indie hackers. It’s also serious business.

According to Pitchbook, 3 of the top 10 performing VC funds in the world are based in New York. Two are in the Bay Area.

The Bay Area currently accounts for 20.6% of all venture capital deals in the US, but NYC accounts for 14.7% and is on the rise.

There’s lots of load-bearing claims in the process of product development. Some are explicit, many are assumed.

“Our users care a lot about the author behind the content they consume.”

“The market for personalized healthcare experiences is enormous.”

“Our organization’s leadership values measurable climate impact.”

“This new technology will make just in-time interfaces feasible.”

These claims are memetic, flying around documents and meetings in a frenetic game of telephone.

As these claims are repeated, they quickly gain the weight of truth among team members.

While repetition from multiple internal sources might make a claim feel true, repetition is a weak basis for critical decision making.

Often these claims have no empirical origin. The originator of the claim might know this (and he or she might assume everyone else knows this), but elsewhere on the team decisions are being made as if that claim were rock solid.

I like using structured exercises with client teams to collectively elucidate, map, and grade the epistemic status of these load-bearing claims, but I’ve often found a well-placed dumb question can sometimes spark a necessary review of a claim’s provenance almost as well.1

This might sound like:

“What is that decision based on?”

or

“Interesting, how do we know that?”

Simply nudging team members to attach an epistemic status to claims in group contexts can reveal misalignment. Shorthands are useful.2

Fact: A claim grounded in robust qualitative and/or quantitative empirical data

Opinion: A claim grounded in limited data, personal experience, anecdote, or strong hunches.

Guess: A claim that exists usually because a claim needed to exist in order to move forward.

In the chaos of product development, basic operating heuristics tend to flatten all claims down to the same epistemic status (usually as a ‘fact’) in order to move forward. When these assumptions are made legible by grading the claim as a fact, opinion, or guess, it quickly becomes clear that one subset of team members was operating on the premise that a claim was fact while another knew it to be an educated guess. Or, we discover that everyone thought it was a fact because everyone assumed someone else had hard data, when if fact no one did.

Sometimes these misalignments follow the fault lines of seniority. An opinion from someone senior is interpreted as a fact by someone junior by virtue of their authority, or a guess by someone junior is transmitted as fact to senior team members in order for a middleman to save face.

The value is not in getting the team to agree that a particular claim is “a fact” or “an opinion,” but in identify precisely where there is a lack of agreement in the first place, and why. Perhaps some of the team hasn’t seen the research that others have—or perhaps there’s no research at all. In this case, an applied bit of empirical handy work (whether it’s rigorous research or simply a few key conversations) can provide nuance and confidence to the current path or avert a crisis before it hits if the leading assumption turns out to be false.

The earlier a team can practice good epistemic hygiene, the better. Once an unsubstantiated claim has taken on the veneer of truth and especially once critical decisions have been made on its basis, it becomes painful to course correct. Investments have been made, promotions planned, stakeholders appeased, and no one wants to lose face. Even in earlier-stage companies where these politics are less pronounced, the same mindset can still infect the product development process.

Not every decision must be based on hard data,3 and 100% certainty is an illusion whenever you’re building something new, but taking a periodic moment for epistemic hygiene is a low-cost, high-impact way to keep a team moving towards its goals.

Subscribe now

For those interested in the urban housing crisis, I recently published What Really Drives Housing Prices? on my personal blog. There I write and share analysis on subject matter that I find deeply important but off-topic for this newsletter.
Now, for your (ir)regularly scheduled broadcast…

Though densely interdependent, building technology and building products are two distinct activities.

Technology-building—the invention of new technologies—is a higher risk and slower activity than product-building. It requires unusually patient capital. For this reason it tends to happen in research labs funded by large governmental, academic, or corporate institutions.

You can trace most technologies back to these institutional research labs.

The US government is an especially potent generator of new technology. Government research labs like DARPA developed GPS, cellular communication, touch screens, drones, accelerometers, the first “Street View”, and funded the development of mRNA vaccines. We also have DARPA to thank for the internet.1

University-affiliated labs have also proven bountiful. Computer vision, e-ink, e-mail, and many other technologies were developed at MIT. Stanford Research Institute (SRI) produced the computer mouse, the inkjet printer, and the voice interface technology used in Apple’s Siri. The first AR head-mounted display system was developed at Harvard in the 1960’s. Larry Page and Sergey Brin developed PageRank at Stanford University before founding Google. The first text-to-image diffusion model was introduced by researchers at the University of Toronto in 2015.

We have corporate research labs to thank for many of the fundamental technologies of the digital era. Bell Labs developed the first transistors, lasers, charged-coupled devices, and solar cells as well as Unix and the C programming language.2 RCA Laboratories invented LCD displays, electron microscopes, and the first color television. Today, big tech companies like Google, Meta, Microsoft and Apple have their own internal labs for this kind of basic research.3

This pattern is likely to continue into the future, with independent non-profit labs playing a prominent role. It’s not an accident that OpenAI built the large language model underlying ChatGPT as an independent non-profit research lab before transitioning to a for-profit model in 2019. Few people know more about the strengths of the research lab model for building groundbreaking technologies than my friend Ben Reinhardt. He recently started Speculative Technologies, a non-profit research lab focused on materials and manufacturing, modeled after DARPA.4

Basic research labs are well-suited to building technology in part because they are ergodic — they generally get to fail as many times as necessary as they explore the entire search-space. If there’s gold to be struck, they’ll eventually strike it.

As a general rule, startups don’t build technology. Startups apply technology to build products that address a user need in the market. Neither Zoom nor Skype invented videotelephony or the image compression algorithms that make it possible, yet Zoom applied these technologies to become critical infrastructure for remote work around the world. Uber and Lyft didn’t invent GPS or mobile technology, yet they effectively harnessed these technologies to birth the multi-billion-dollar ride-sharing industry. Startups are usually better positioned to adapt, refine, and assemble existing technology rather than fundamentally build it.5

For example, the current explosion of AI startups isn’t driven by new companies building AI, it’s driven by companies searching for novel ways to apply this new technology through products. Many are little more than wrappers on ChatGPT’s API—and that’s to be expected!

This is not due to any lack of ingenuity or creativity among startups. It’s a direct consequence of the very nature of a startup's structure, resources, and goals.

The capacity of startups to create new technology is constrained by their dependence on venture capital, which demands a swift path to profitability and tolerates less technological uncertainty. The demand for swift and dramatic return by VCs should not be underestimated—they are competing with the ROI of every other asset class for the capital provided by their LPs. Unlike research labs, startups don’t have the luxury of patient capital.

This limited runway means that startups are non-ergodic—they get a limited number of times at bat before they cease to exist. This high-stakes environment creates very different developmental dynamics from those of research labs, where ongoing failure is accepted as a part of the process.

In light of these constraints (which come hand-in-hand with the upside of value capture), startups must limit their exposure to risk. Where research labs assume technical risk, startups assume market risk. It makes no sense for anyone to assume both. A healthy tech ecosystem distributes these risks so that no single actor takes on too much.6

Startups need to understand their role in this ecosystem in order to fulfill it successfully. Many operate as if they’re developing new technologies in research labs instead of new products inside a startup (they just do it faster). In my next post I’ll explore the implications of this problem and offer an alternative development model that I believe is better adapted to the needs and constraints of startups and product teams.

Subscribe now

My collaborator Oshan Jarow and I recently made public the Library of Economic Possibility, a knowledge tool for economic ideas just outside the Overton window. LEP is motivated by our belief that the economy should be understood as a complex adaptive system and economic policy as a design problem within it. It’s also a reaction to a deep structural problem with mainstream economic thought.

Economic thinking has long been dominated by two oversimplifications that have shaped the modern world.

Oversimplification #1: The economy can be centrally planned

One has already collapsed; the economic ideas of Marx and especially Lenin, who sought an egalitarian society through the centralized control of the economy. In their effort to eliminate the capitalist class, they made a fatal error in their descriptive model of how economies work.

In reality, most of the relevant knowledge needed to coordinate economic activity is distributed throughout the system. How many nails to produce each month, for example, depends on dispersed information that planners cannot access. The inefficiencies of central planning make it unsustainable.

Friedrich Hayek described this dynamic lucidly:

"The marvel is that in a case like that of a scarcity of one raw material, without an order being issued, without more than perhaps a handful of people knowing the cause, tens of thousands of people whose identity could not be ascertained by months of investigation, are made to use the material or its products more sparingly; that is, they move in the right direction."

—Friedrich Hayek, The Use of Knowledge in Society, 1945

Hayek’s insight into decentralized knowledge in markets helps explain why free market systems outlasted communist planning.

Unfortunately, Hayek’s insight was overshadowed by the second oversimplification.

Oversimplification #2: The economy is a static model

The impulse to exert control also underlies this second misconception, which continues to shape policy today. In the late 1800’s, economists like William Stanley Jevons and Léon Walras sought to model the economy as a mathematical equation.

Physics is rich with elegant mathematical equations, so these economists took them. I mean this quite literally. The neoclassical economic model of general equilibrium, which can be found in nearly every economics textbook of the last century, was lifted from chapter two of French mathematician Louis Poinsot's Elements of Statics (1803) by Léon Walras. Walras made this model the centerpiece of his Elements of a Pure Economics in 1872, and it spread rapidly in the decades that followed.

Our modern economic system relies on a 220-year-old physics model that was already rendered obsolete among physicists by new understandings of entropy and thermodynamic behavior at the time that Walras was taking it to Kinko's.

However, in order to turn the economy into a simple static model, neoclassical economists had to make a few assumptions (the first of which effectively erases Hayek's1 insight):

1. Everyone has perfect information at all times.

2. People always act rationally and logically.

3. Everyone has access to at least some amount of every possible good and service.

4. There are futures markets for everything.

5. The probabilities of all future events are known with certainty.

6. There is no social or collective agency, no shared goals or common interests—there is only the individual.

Why would the backbone of modern economics accept these obvious distortions of the real world?

Because without these assumptions, the math doesn't work!

The neoclassical model’s assumptions take it to a radical end: If markets always find balance, then the sole role of policy must be to cease meddling with their course. Simply put, we must eliminate all forms of intervention. But in mistaking model for reality and logical extreme for pragmatic mandate, this conclusion casts a spell that has cost us dearly.

Beginning in the 1970’s, this ‘free market fundamentalism’ drove deregulation, privatization, attacks on unions, financialization, and cuts to public services.

The previous economic model had its own clear failings, but if economic growth, shared prosperity, and business dynamism were the goal of the new system, then this project has failed. Economic growth has slowed to a crawl, inequality has skyrocketed, and we now have more businesses dying than being born. Rather than tending towards equilibrium, a strict adherence to non-interventionism has led to a new form of consolidated control by rent-seekers in the private sector.

High modernist economics

Let’s turn to Hayek again.

“The curious task of economics is to demonstrate to men how little they really know about what they imagine the can design.”

—Friedrich Hayek, The Fatal Conceit, 1988

There’s an irony in Hayek’s critique of economic interventionism, since the free market fundamentalism that he supported exhibits the very same ‘design’ impulse he criticized.

‘Design’ for Hayek referred to the dominant approach of his era, high modernism.

High modernism is a design paradigm characterized by:

1. Strong belief in scientific and technological progress. High modernists held a utopian faith in experts and intellectuals to use scientific knowledge to master nature and society.

2. Attempts to control and redesign complex systems. High modernism tried to impose order on organic or historical environments using engineering-inspired methods to rationally plan and optimize systems.

3. Disregard for context and specificity. A "one-size-fits-all" approach ignored local history, culture, geography, and differences in favor of universal “scientific” principles.

4. Reliance on legibility and efficiency. The goal was to make systems more transparent and efficient via simplification.

While free markets are seen as the opposite of communism (which clearly exhibits the failure patterns of high modernism), a modest dive into the epistemic origins of Hayek’s free market fundamentalism reveals it to carry all of the same high modernist traits. Free market fundamentalism is yet another flavor of high modernist economics.

Communism

• Perceives itself as scientific, is actually based on the pseudoscience of historical materialism

• Technocratic view of economics as an engineering problem

• Believes a pure state-planned economy can achieve maximum efficiency

• Built on numerous simplifying assumptions of how the economy works

Free market fundamentalism

• Perceives itself as scientific, is actually based on the pseudoscience of the neoclassical model

• Technocratic view of economics as an engineering problem

• Believes a pure market-driven economy can achieve maximum efficiency

• Built on numerous simplifying assumptions of how the economy works

The core problem with both systems is that they aren’t based on reality. They are simplified models derived from idealized blank-slate visions of what that reality ought to look like, imposed from above on the rich complexity of real economies.

While it makes for an elegant model, economic equilibrium doesn’t actually exist in the real world. The map is not the territory and the model is not the economy. While markets have real strengths, real world economies do not follow a simple physics model’s rules.

As economist Steve Keen observes,

“There is one striking empirical fact about this whole literature, and that is that there is not one single empirical fact in it. The entire neoclassical theory of consumer behavior has been derived in ‘armchair philosopher’ mode, with an economist constructing a model of a hypothetical rational consumer in his head, and then deriving rules about how that hypothetical consumer must behave.”

— Steve Keen, Debunking Economics

How do you get a healthy ecology?

Fortunately, high modernism is not the only approach to design, nor is armchair philosophy the only approach to economics.

The prescriptions of central control or pure non-intervention are naïve responses to unrealistic economic models. Even free markets are designed — they require institutions to create, regulate, and police them.

In 2019 I attended a symposium on complexity economics at the Santa Fe Institute, where Eric Beinhocker, author of The Origin of Wealth, made a comment that framed the problem beautifully:

“Asking ‘Do you want more market or more state?’ makes about as much sense as asking ‘Do you want more plants or more animals?’ The real question is ‘How do you get a healthy ecology?’”

—Eric Beinhocker, SFI Complexity Economics Symposium, 2019

Like ecologies, economies are complex adaptive systems. They exhibit feedback loops, delays, adaptation, path dependence, nonlinearity, emergent phenomena and — importantly — people.

Economics is a social science. As the renowned physicist Murray Gell-Mann once quipped, “Imagine how hard physics would be if electrons could think!”

So how do we achieve a healthy ecology?

While no single measure can adequately describe a complex system, ecologists generally assess the health of an ecosystem with a few key indicators:

Biodiversity

The variety of species present and their relative abundances. Higher biodiversity indicates a healthy, stable ecosystem.

In economics, we might consider the ‘biodiversity’ of businesses. High market concentration suggests problems.

Nutrient Cycling

The efficient circulation of nutrients like nitrogen, carbon, and oxygen through the system. If nutrients are accumulating or being depleted, it may indicate the system is out of balance.

In economics, we might consider the velocity of money. If capital is accumulating rather than cycling through the economy, imbalances may emerge.

Resilience

The ability of an ecosystem to withstand an exogenous disturbance, and then recover from it. Resilient, healthy ecosystems can handle stress without collapsing.

In economics, we might consider whether the economy can withstand a natural disaster or, say, a pandemic. As we’ve learned, hyper-efficient supply chains don’t fare well under stress.

Indicator Species

The presence, absence, or abundance of sensitive species are indicators of ecosystem health. Indicator species are the ecological ‘canary in the coal mine’. For example, mayflies are sensitive to water pollution, so their population declines indicate impending problems.

In economics, we might consider the presence of small businesses, young people, or artists in the economy. Their struggle or decline could signal problems with economic opportunity and vitality — just as the absence of mayflies signals pollution.

Far from mechanical equilibrium or precision-tooled growth, a complexity-oriented approach to public policy might track the economy’s more organic vital signs.

Complexity-based intervention

Ecologists take a nuanced, evidence-based approach to intervening in complex adaptive systems.

Consider their work on trophic cascades to increase biodiversity in Yellowstone park. By reintroducing grey wolves 70 years after they had been killed off, ecologists set off a chain reaction of ecological restoration. The wolves put the deer and elk population back in check, which made room for a resurgence of trees and vegetation. This increased the diversity of birds and increased the population of beavers, whose dams provided habitats for otters, muskrats, ducks, fish, reptiles and amphibians. The intervention even stabilized river banks and altered river behavior. A careful design intervention triggered self-reinforcing positive change, restoring ecosystem balance and a dramatically improving ecological health.

Other interventions include restoring mangrove forests in coastal wetlands to enable nutrient cycling and reduce fertilizer runoff, or creating wildlife corridors to connect fragmented habitats and boost biodiversity.

Ecologists developed these interventions through an empirical understanding of how ecologies work in the real world. They observed the dynamic behavior of food webs and ecological response to disturbances. They ran controlled and natural experiments, beginning with small-scale interventions, testing and evaluating before expanding the idea to larger ecosystems. Much like the systems they study, ecologists are adaptive and change their approach as they learn more about how the system behaves and responds to change.

Economic possibilities

I believe economic thinking would better support flourishing societies if it adopted ecologists’ approach to natural ecosystems. Fortunately, many economists are already doing the hard work of empirical research into potential interventions within the context of economic complexity and have been for quite some time. Rather than forcing a simple model on complex reality, they are building a nuanced understanding of the economy starting with observations in the real world.

For example, a 2019 study by Reimer, Guettabi, and Watson found that a universal $1,000 payment from the Alaska Permanent Fund — a natural experiment in basic income — decreases the probability of an Alaskan child being obese by as much as 4.5%. They estimate that a national expansion may therefore trigger self-reinforcing positive change resulting in medical cost savings of approximately $310 million.

Or consider the 2016 study that studied the effects of a land value tax in Harrisburg, Pennsylvania. In the period following the intervention, the number of vacant lots fell by 80%, the tax base rose from $212 million to $1.6 billion, and crime was cut in half.

Our mission at the Library of Economic Possibility (LEP) is to make the nuanced work of these economists more accessible to the public. By collecting and sharing studies on the real-world effects of new policy approaches — both successes and limits — LEP aims to help ground popular economic thinking in an empirical and pragmatic understanding of what might be possible amid complexity. From land value tax to worker codetermination, carefully designed economic interventions may trigger virtuous cycles of prosperity and resilience — if we are willing to experiment with a pragmatic eye towards ecological health.

The economy is not a machine to be programmed or a windup toy to be set loose, but a garden to be tended. Careful intervention informed by pragmatic learning can tip systems into virtual cycles that outstrip our narrower aspirations of control. It’s time to move past high modernist economics. The economy awaits the hands of humble student-stewards — willing not just to act on it, but to learn how it acts in turn.

Sign Up Here

I don’t usually discuss the business side of my work at Rhizome, but in light of recent layoffs across the tech industry I’ve decided to offer a free/pay-what-you-want workshop on going independent after Big Tech.

I want everyone experiencing layoffs right now to look back at it as the best thing that happened to them.

A lot of folk will want to go find another job, that's great. For those with a wild hair to test their mettle in the open waters, the freedom and variety of independent life is amazing.

I laid myself off (quit, no severance) from Google 2 years ago to give it a shot. The first year was a baptism by fire. Second year much better. I still have much to learn, but there's a lot I know now that I wish I'd known then.

Going from life inside an enormous (and lavish) corporate exoskeleton to total independence in the wilderness is a big shift... but for some it’s totally worth it.

We'll have an honest conversation about whether independent life is right for you, getting and managing clients, structuring your work, handling contracts, writing proposals, getting paid, and whatever else folk want to dive into.

I hope to see you there.

Cheers,
Kasey

A History

The pioneers of early computation had a beautiful dream. Technology as they envisioned it would be a democratizing force. It would empower everyday people to build and control tools that improved their lives. These “bicycles for the mind” would give wings to their creativity and materialize solutions to even the most niche and idiosyncratic needs. To make this dream a reality, the pioneers would need to marry permissionless composability with user-friendly interfaces.

Permissionless composability would enable new innovations through the combination of technologies and modules without a central authority telling people what they can or can’t do with these technologies. User-friendly interfaces would make this power available to the masses, not just the “priesthood of programmers”.

For a time, the pioneers made progress towards this dream. In the 1970’s, researchers at Xerox PARC developed the earliest forms of copy and paste in text editors, which Apple then expanded into a universal API at the operating system level.

Copy and paste is a bit like public libraries—if we hadn’t inherited these blessings from our forefathers, their proposal would seem wildly radical to today’s sensibilities (You want to allow unfettered data transfer between programs created by different companies? What’s next, taxpayer-funded books?). Copy and paste enabled user-friendly interoperability of data between programs, which in turn enabled a vast degree of composability for people who otherwise couldn’t speak the language of computers. Other revolutionary attempts of this era to combine composability with usability included Hypercard (1987), digital spreadsheets (1979), and Logo (a programming language designed for children, created in 1967).

Amidst the innovation, however, a civil war was brewing.

As technology became more valuable to a broader market, it also attracted the attention of large corporations and investors who saw an opportunity for profit in digital’s zero-marginal cost production. In order to make a profit, however, they needed legal intervention. Software wasn’t subject to copyright and therefore all software and its source code existed in the public domain without licenses. In 1983, US courts (ruling in favor of Apple) granted software the legal status of literary works, enabling companies to claim ownership and profit from their creations. That same year, IBM announced that it would no longer distribute source code along with its software—making modifications by the end-user impossible.

But software-for-profit had detractors. A month after the 1983 ruling, Richard Stallman founded the GNU Project with the goal of giving users control by collaboratively developing and publishing free, open-source software. The open-source movement of volunteer developers positioned themselves as the Rebels against corporate tech’s Galactic Empire.

Clashes erupted. Microsoft’s Steve Ballmer called open-source “a cancer” while leaked internal documents revealed a strategy to push proprietary protocols that would limit interoperability and kneecap open-source alternatives to Microsoft products. As major tech companies began to rely on open-source software, some open-source resorted to sabotage by deleting their own code.

However fierce the battle, neither side of this fraternal conflict could realize the original dream of user-friendly and permissionless composability.

For-profit tech companies sought the ROI of usability (it’s no coincidence that ‘user-centered design’ also emerged in the 1980’s) and marshaled their vast resources towards this aim even as the underlying technology became steadily more complex. Today the software produced by Big Tech is easy to use, but only in the predetermined ways that their creators allow. That means closed ecosystems, limited interoperability, no composability, and strict permissions.

Conversely, the open-source community prioritized permissionless composability, but this came at the expense of usability. Open-source software is built by volunteers without profit—and developing user-friendly interfaces is expensive, especially as technology becomes more complex. Therefore most open-source software is built by developers for other developers.

Corporate software built easy-to-use tools, but at a cost and without composability. Open-source software supported permissionless composability, but their tools weren’t user-friendly.

An Opportunity

This was the state of computation until last week, when OpenAI released ChatGPT.

For months we’ve marveled at the fantastic hallucinations of image generators like Midjourney, Dall-E, and Stable Diffusion. We’ve been awed by GPT-3’s ability to write essays and short stories.

ChatGPT is an implementation of GPT-3 that is specifically designed for conversational language tasks. ChatGPT takes the capabilities of large language models (LLMs) further by introducing the ability to converse with the LLM and reference past subjects of conversation.

Large language models like ChatGPT are trained using deep learning, a powerful form of machine learning that involves training a network of interconnected neurons to recognize patterns in data. In the case of language models, this means feeding the neurons vast amounts of text data so they can learn the patterns of language. Once trained, the model can use this knowledge to generate human-like text when given a prompt.

The more text data the model is trained on, and the more powerful the computer hardware used to train it, the better it becomes at generating realistic text. That's why ChatGPT can produce such convincing and coherent responses.

Don’t believe it? Those last two paragraphs were generated by ChatGPT.

Twitter has been abuzz since the release as people share their amazement and skepticism of what ChatGPT can do (the second coming of Tolstoy it is not—its writing tends towards the banal and sophomoric, often confidently expressing information that may not be correct). While rewriting the lyrics of Apple Bottom Jeans in the style of Soviet propaganda is a great party trick and take-home essays may soon be extinct, ChatGPT has another trick up its sleeve that is far more consequential.

ChatGPT knows how to code.

On my first morning with ChatGPT, I asked it to create a custom client intake questionnaire with multiple question types and complex branching logic, where only one question is displayed per page. I've been looking for a program like this for a while, but none of the available web form services met my particular needs. I'm also a terrible programmer. Not only did ChatGPT generate plausible questions for my use case, it produced a working python script that met my criteria in seconds.

Of course, there’s some technical knowledge expressed just in knowing enough to request a python script. What if I don’t know what I need? A single python script isn’t enough. Again, ChatGPT is a generous and understanding developer.

But I don’t just want it to work, my clients will see this! I need it to look good too. ChatGPT, help!

One more thing — I forgot to tell it that I wanted my questions to show up one at a time. Can we rewrite the code to do that? Of course, it’ll just whip up some javascript for us.

The code is often incomplete and not entirely free from error, but ChatGPT will also assist and explain any errors encountered along the way (poetry may not be dead but Stack Overflow probably is). As someone who is literate enough to ask questions in plain English but not technically proficient enough to memorize syntax or write error-free code, I find ChatGPT's abilities to be incredibly empowering. What would have taken me days or weeks to do on my own now takes just seconds or minutes with ChatGPT's help.

Whatever our current AI’s shortcomings as a developer may be, it’s clear they will be short-lived. Yesterday, Google’s Deepmind announced AlphaCode, which writes code of a high enough quality to place in the top half of coding contests.

The implications of AI-written software—prompted in plain English—are enormous. In a recent post I discussed the concept of ‘design for emergence’ and identified three criteria for this design paradigm (which aligns closely with that envisioned by computation’s early pioneers). They were:

1. The designer can be meaningfully surprised by what the end-user creates with their tool.

2. The end-user can integrate their local or contextual knowledge into their application of the tool.

3. The end-user doesn’t need technical knowledge or training to create a valuable application of the tool.

Until last week, programming languages (many of which were created by the open-source community) satisfied criteria #1 and #2, but not #3. Wielding these powerfully composable languages effectively required an untenable amount of technical knowledge for the average person.

With the introduction of ChatGPT and AlphaCode, the amount of technical knowledge required to create a valuable bespoke application has fallen dramatically. With a simple request, almost anyone can suddenly create a useful tool built from composable code using little more than a request in plain English.

There is no question that this moment represents an enormous leap in the trajectory of technology. With composability and usability reunited once more, the dream of early computation’s pioneers would be realized.

There’s just one glaring problem.

A Warning

Despite its name, OpenAI is not an open-source project. In fact, its largest investor is the very behemoth that once schemed to destroy open-source—Microsoft. In 2020, OpenAI announced that it would grant an exclusive license for GPT-3 to Microsoft, giving the company the sole power to embed, repurpose, and modify the model as it pleases.

To be clear, Microsoft under Satya Nadella is not Microsoft under Steve Ballmer. The company has in fact become a formidable contributor to the open-source community.

All the same, ChatGPT is anything but permissionless. We can’t look under the hood of the model or review the datasets that the model was trained on. Those that build tools or businesses on top of these APIs are taking a leap of faith. Access to this powerful tool is granted based on the terms determined by OpenAI and its investors.

To some concerned with the power of AI, this may be a good thing. As philosopher Nick Bostrom commented, "If you have a button that could do bad things to the world, you don't want to give it to everyone." But while OpenAI’s CEO Sam Altman has expressed good intentions, it’s unclear why a private organization with little oversight should be trusted with such a button either.

While OpenAI did open-source their multi-lingual transcription model, few expect GPT to receive the same treatment.

Instead, we’re enjoying permissioned user-friendly composability for the (likely brief) period of time while it is freely available. Time will tell what sort of limitations and fees may be placed on tools like ChatGPT or AlphaCode. In the meantime, the open-source community isn’t far behind.

How does design for emergence apply to the future of work?

This week I had a great conversation with Dror Poleg exploring this question. We barely skimmed the surface in our brief half-hour chat, but expanded on some of the points made in my recent post When to Design for Emergence.

I’d love to hear your thoughts on the subject. Please feel free to share your perspective in the comments or on Twitter.

/K

For years, I’ve heard some variation of the following lament from clients, collaborators, and friends with startups:

“There’s so many use cases we could solve for, but every user we talk to wants something different, and we just don’t know which ones to focus on.”

or,

“We’ve designed for all the common and important user needs and now we’ve hit a ceiling. How do we grow without bloating our product with minor features?”

Both statements describe what we can call the long-tail problem. It’s very common—I’ve seen the long-tail problem at tiny two-person startups and at Big Tech corporations with billions of users.

In the long-tail problem, all the opportunities in front of you live on the long tail of user needs. Collectively they represent many users, but individually none of them appear important enough to invest time or resources in.

Common needs represent large markets, but the needs are largely met, and competition between solutions is fierce. Long-tail needs are often unmet and come with much less competition, but individually represent markets too small to justify the expense of development.

Let’s look at some example user needs from the world of digital mapping.

Perhaps the most common user need we see in the mapping space is “How do I get there from here?” Such ubiquitous user needs are experienced by nearly everyone, often many times a day. Purpose-built solutions in the “traditional” style of product development often work well here (if you can hold your own in a crowded market). Long-tail user needs, like “Is this passable at low tide?” represent a comparatively small group of people, yet the investment required to build an adequate solution often remains the same.

There is a way of addressing the long-tail problem, but it requires a very different paradigm for thinking about the way we design products, tools, and services. We can call this paradigm design for emergence.

In complexity science, ‘emergence’ describes the way that interactions between individual components in a complex system can give rise to new behavior, patterns, or qualities. For example, the quality of ‘wetness’ cannot be found in a single water molecule, but instead arises from the interaction of many water molecules together. In living systems, emergence is at the core of adaptive evolution.

Design for emergence prioritizes open-ended combinatorial possibilities such that the design object can be composed and adapted to a wide variety of contextual and idiosyncratic niches by its end-user. LEGO offers an example — a simple set of blocks with a shared protocol for connecting to one another from which a nearly infinite array of forms can emerge. Yet as we will see, design for emergence can generate value well beyond children’s toys.

In many ways, design for emergence is an evolution of the design paradigms of past and present. Let’s take a look at the past to place this future in context.

High Modern Design

The mid-20th century saw the apex of high modern design. This paradigm was characterized by a hubristic disregard for context, history, and social complexity in favor of an imposed rational order and universal standardization. “Rational” in this paradigm describes a state of superficial geometric efficiency as conceived by the designer.

In high modernism, not only does the designer exert near-total control over the design, he also operates under the assumption that he holds all relevant knowledge about the design problem.

If we plot these two dimensions—knowledge and control—on a simple chart, high modern design occupies a distinct quadrant.

High modern design was widely discredited following a series of high-profile failures in the 1970s and 80s, ranging from the demolition of Pruitt Igoe to the collapse of the Soviet Union. By the end of the 20th century, a new design paradigm had taken its place.

User-Centered Design

In contrast to high modern design, user-centered design takes a more modest position; the designer does not inherently know everything, and therefore she must meticulously study the needs and behaviors of users in order to produce a good design. User-centered design remains the dominant design paradigm today, employed by environmental designers, tech companies, and design agencies around the world.

User-centered design suggests identifying well-trodden ‘desire paths’ and designing for them (in this case by paving a new sidewalk).

While user-centered design discards the high modern assumption that the designer always knows best, it retains the idea that the designer should maintain control. In this paradigm, design is about gaining knowledge from the user, identifying desirable outcomes, and controlling as much of the process as possible to achieve those outcomes. ‘Design’ remains synonymous with maximizing control.

User-centered design has a better track record than high modern design, but it still exerts a homogenizing effect. The needs of the modal user are accommodated and scaled through software or industrial manufacturing, while power users and those with edge cases can do nothing but actively petition the designer for attention. In most cases, diverse users with a wide variety of niche use cases are forced to conform to the behavior of the modal user.

In many cases this is sufficient. Don Norman, who coined the term ‘user-centered design,’ is infamous for his ‘Norman Door’ design example. User-centered design generally works well as an approach to solving common problems like permeable separation between spaces (i.e. the common problem doors solve) or comfortable food preparation.

But consider even the ‘desire path’ example pictured above. The modal user may be well supported by paving the desire path indicated by their behavior, but what good is a paved path leading to stairs for a wheelchair user? In practice, user-centered design tends to privilege the modal user at the expense of the long-tail user whose needs may be just as great.

Long-tail users of user-centered design are not given the degree of control necessary to adapt the design object or tool to their unique needs, and designers are faced with the long-tail problem mentioned earlier.

This is where design for emergence offers an alternative.

Design for Emergence

In design for emergence, the designer assumes that the end-user holds relevant knowledge and gives them extensive control over the design. Rather than designing the end result, we design the user’s experience of designing their own end result. In this way we can think of design for emergence as a form of ‘meta-design.’

What does it mean to give the user control?

Ashby’s Law of Requisite Variety states that enabling control depends on the controlling system (i.e. the tool) having at least as many possible states as the system it controls (i.e. the end-user’s design problem). In Ashby’s words:

In order to deal properly with the diversity of problems the world throws at you, you need to have a repertoire of responses which are (at least) as nuanced as the problems you face.

In other words, to address the long-tail problem, the tool must be flexible enough that it can be adapted to unexpected and idiosyncratic problem spaces—especially those unanticipated by the tool’s designer.

We can draw a useful boundary around design for emergence with the following criteria.

1. The designer can be meaningfully surprised by what the end-user creates with their tool.

Design for emergence is open-ended. There’s no room for surprise in high modern or user-centered design, unless the design is exapted for an unintended use (see “Design Exaptation” in the bottom right quadrant of the 2x2 above). Meanwhile, a key characteristic of design for emergence is that the end design may be something that the original designer never imagined. Whereas exaptation may indicate a design failure, this kind of surprise is an indication that the designer has succeeded in nurturing emergence.

Design for emergence is permissionless. It empowers people by way of its constitution even though it can never know what people will do with that power. In contrast to user-centered design, design for emergence invites the user into the design process not only as a subject of study, but as a collaborator with agency and control.

2. The end-user can integrate their local or contextual knowledge into their application of the tool.

Design for emergence is context-adaptable. It leverages distributed, local intelligence. In machine learning, a variation of the long-tail problem manifests as an increasing amount of data required to generalize a model across applications (e.g., training a robot to open a particular door versus training a robot to open any door). Data has diminishing returns. The pattern holds true for long-tail problems as approached by user-centered design—the cost of information about users holds steady but satisfies an ever-smaller number of users. 

Rather than trying to collect and incorporate all possible relevant information, design for emergence gives form to systems on the basis of general information while letting end-users “finish the job” with their unique on-the-ground knowledge.

3. The end-user doesn’t need technical knowledge or training to create a valuable application of the tool.

Design for emergence is composable. It provides a limited ‘alphabet’ and a generative grammar that’s easy to learn and employ, yet can be extended to create powerful, complex applications. As Seymour Papert once remarked, “English is a language for children,” but this fact, “does not preclude its being also a language for poets, scientists, and philosophers.”

To borrow another metaphor from Papert (and Mitchel Resnick), design for emergence needs:

• Low floors (an easy way to get started)

• Wide walls (many possible paths)

• High ceilings (ways to work on increasingly sophisticated projects)

Low floors are especially important in a market context as most users are not technical. For this reason, design for emergence often looks like a ‘kit of parts,’ with ease of use operating largely as a function of the number of parts and the number of ways they can be joined together. Limiting both quantities keeps the floor low, while the combinatorial explosion of possibilities that even a limited set can generate produces wide walls and high ceilings.

While design for emergence is in the midst of being rediscovered, it is hardly a new paradigm. Christopher Alexander’s A Pattern Language (1977) was a ‘kit of parts’ in the form of 253 design patterns. His design theory has close theoretical parallels to complexity science, which studies the natural phenomena of emergence. Oskar Hansen diverged from his high modernist roots in the direction of design for emergence with his participatory theory of ‘open form’ in the 1960’s. Questions of user control in system design are also central in cybernetics, which goes back at least as far as Norbert Weiner’s 1948 publication of Cybernetics: Control and Communication in the Animal and the Machine.

Perhaps the best historical example of design for emergence in a popular application is HyperCard, released by Apple in 1987. HyperCard could be easily adapted to unanticipated purposes. Children used it to create and organize databases of game cards. Academic researchers used it in psychological studies. Restaurateurs used it to report orders coming through registers. HyperCard was even used to control the lights on two of the world’s tallest buildings, the Petronas Towers in Kuala Lumpur, Malaysia. Creator Bill Atkinson described HyperCard as a programming tool "for the rest of us,” and, “an attempt to bridge the gap between the priesthood of programmers and the Macintosh mouse clickers.”

Hypercard was laid to rest in 1998. Despite its adoring user base, Apple executives didn’t believe it could make money. While this may have been true in 1998, the rise of software-as-a-service (SaaS) business models has made design for emergence once again financially viable.

Today, design for emergence—made profitable by SaaS—supports an enormous market of left-behind long-tail users.

Notion is a philosophical descendent of HyperCard (turns out you can even buy a third-party HyperCard-themed Notion template) that offers extremely adaptable information structures built from an alphabet of ‘content blocks’. It’s also worth $10 billion and has 30 million users. I used it to create the first bidirectionally linked note-taking system that matched my own idiosyncratic research needs.

ClickUp is a project management tool that “flexes to your team's needs” with a modular structure composed of a handful of ‘ClickApps’ and Views. The five-year-old company is growing at a rate that would make most startups blush. Elsewhere, ‘nocode’ tools like Airtable, Webflow, and Zapier have found great commercial success with their composability, interoperability, and extensibility.

Then there’s the great destroyer of would-be single-purpose tools, the software market juggernaut Microsoft Excel. With a small handful of data types and a two-dimensional grid of cells, non-technical users can make simple calculations (low floor) or design massively complex data systems (high ceilings), adapted to their specific needs and without IT support. Generations of enterprise software designers have had to answer the difficult question: “Why wouldn’t our users just do this in Excel?” 

Web-based competitors like Google Sheets leverage yet another tactic for emergence by introducing multiplayer capabilities to the already powerful end-user programming tool. Together these digital spreadsheet tools support billions of monthly active users worldwide.

What all these tools have in common is support for open-ended adaptation to highly contextual problems without the need for technical knowledge. Rather than building a static, purpose-built solution to a single common problem with lots of users (and lots of competitors), they’ve won robust user bases by supporting a broad swath of long-tail user needs.

In future posts we’ll explore tactics for how to design for emergence, but for now I’ll leave you with a question:

How many markets are currently sitting untapped on the long tail, waiting for tools that empower emergence?

Early-stage innovation is like climbing to the tallest peak of a mountain range…

As you stand at the base of the mountain, you realize this mountain is steep and untamed. It has not been climbed before, and there is likely a reason for that.

Not only do you want to get to a summit, but you want to get to the *right* summit — the tallest peak you can climb to — without getting stuck on the lower levels surrounding it.

For design research, this peak represents the ideal fit between design and need, product and market, service and serviced. It symbolizes a problem being successfully solved as well as possible.1

…covered in landmines…

If you make a wrong step at the wrong time it can be game over.2

About 95% of startups fail.3 In my experience, the failure rate is similar for innovation ventures in large corporations and in the public sector.

…in the dark.

In the dark, we cannot see the landmines, or even which path actually leads up the mountain! One of the biggest reasons for innovation’s high failure rate is that teams cannot see the existential risks that surround them or the opportunity ahead of them. Focusing only on your immediate area can give you the illusion of upward progress, but if you can’t see the bigger picture, you are likely to find yourself disoriented atop a much smaller foothill or hit a landmine.

Realistically, you would not attempt to climb this mountain without some basic tools, but teams and organizations often try to innovate without the basic tools provided by design research.

Design research gives us a map, a route, and a flashlight.

Our odds of making it to the summit of this tall, dark, and landmine-covered mountain improve with three tools. A map can tell us which peak is tallest, a route can give us an informed plan, and a flashlight lets us see where we are stepping as we climb (preferably towards higher ground and not onto a landmine).

Foundational research is our map.

The map gives us a sense of where the highest peak and our goal really is, and it helps us avoid getting stuck on lower foothills.

We can use foundational research to obtain a 10,000ft aerial view of opportunities and risks. Here, the highest peak represents the right problem to solve, so we avoid becoming distracted by lesser issues. This map will not show us every rock, snake’s nest, and landmine, but it will give us a sense of the landscape and where we are headed.

Foundational research employs methods like ethnography, surveys, open-ended interviews, and literature synthesis to identify and craft a strong definition of the design problem, as well as any important behavioral dynamics that we will need to keep in mind.

For example, a foundational study on personal fitness might find that individuals who get less exercise tend to be less competitive in nature but possess a mental model of fitness associated with competitive sports. If our goal is to engage more people in personal fitness, we might define the design problem as the negative association between personal fitness and competitiveness. Thus, conducting foundational research lends us an overview of the personal fitness landscape and indicates where we aim to go.

Design strategy is our route.

Now that we have a map of the mountain, we can strategize about how we will climb it. The quality of our planned route is naturally dependent on the quality of our map. Drawing our route through this terrain map is where we turn robust knowledge into a strong plan of action.

There are many possible paths we can take up the mountain. In choosing a path, we are looking for leverage; we want the path that takes us furthest upward while demanding the least expenditure of energy and resources — after all, the air is thin up here!

Strategy requires searching the adjacent possible, which is highly dependent on our existing assets. An attractive strategy for a software company may involve manufacturing new computer hardware, but the leap to do so would incur large costs given the company’s core competency in software. Design strategy often involves leaning into our existing strengths or, otherwise, making big trade-offs.

There is no one-size-fits-all ideal in terms of design strategy, but small, structured workshops like design sprints are one useful way to review foundational research, align on a problem definition, and leverage the diverse perspectives and creativity of team members to flesh out a variety of possible routes forward.

For example, in the case of personal fitness, we could devise any number of strategies. One strategy might be to shift people’s mental models of fitness by devising explicitly cooperative forms of exercise. Another strategy might be to disregard the mental model altogether and instead integrate physical exercise into an activity that is disassociated from personal fitness, like video games. Importantly, we will commit to one strategy rather than attempting to split the difference across various strategies.4

Iterative prototyping is our flashlight.

Our map and route are useful, but they are crude abstractions of the real world ahead of us. In order to see where we are stepping (and avoid landmines) as we navigate on the ground, we are going to need a flashlight. This tool enables us to perceive what is directly in front of us and adjust our steps accordingly.

In iterative prototyping, we instantiate our strategy by creating a quick and dirty version of the product or service experience and testing it with a representative group of our target users. We will then learn whether the idea makes sense to them, if they interact with the product in the way we would expect, how it makes them feel, and where desirable outcomes are achieved or not. We then take these findings and iterate upon them to create a new prototype (and repeat this process multiple times, continuing to progressively iterate).

In the early stages of iterative prototyping, we focus on concept validation and often use mockups or “Wizard of Oz” prototypes. In later stages, we refine lower-level design problems like interaction patterns or materials and may wish to use higher-fidelity working prototypes. Prototypes are not just simple versions of final products,5 but rather they are designed to investigate a particular set of questions. Answering these questions allows us to eventually reach the highest possible peak with our final product.

It’s very possible that we encounter a boulder that was not on our map, and we will have to change our route on the fly. Sometimes, the only way to reveal a risk or a new opportunity is to watch real people interact with a real thing. Thus, iterative prototyping will light the way in front of us and allow us to update our path based on any unexpected obstacles that arise.

By combining these three tools, we can radically improve our odds of identifying the right problem to solve, strategically leveraging that knowledge into a plan of action, and iterating our way towards a refined and well-adapted solution.

Just remember to enjoy the view.

Forgetting Christopher Alexander

In the spring of 2011, when I was a design student in Copenhagen, my professor loaned me a copy of Christopher Alexander’s A Pattern Language (1977).

Heavy with thin pages, the red, leather-bound book felt like a Bible in my hands. Although I didn’t fully grasp what I was reading at first (in some ways I'm still trying to wrap my mind around it), I realized that Alexander was describing a truth about reality which was much deeper than architecture.1 I had never read anything like it—it was somehow mathematical yet poetic, sophisticated yet straightforward, philosophical yet practical. After finishing A Pattern Language, I swiftly devoured as many of his books and essays as I could find.

A proper introduction to Alexander’s work would require its own book, but I’m going to summarize the important elements with a crude ontology.2 I view Alexander's work as a series of concatenated levels: an object-level artifact or tool; an information architecture that structures the artifact; a process that generates that information architecture; an epistemology that implicates that process; and a moral value system that motivates all of the above. Let’s dive in.

Level 1: Artifact

At the surface level, A Pattern Language is a design and construction handbook for everyone. It contains 253 rules of thumb expressed in the form of patterns. Patterns are reusable sets of relationships forged over time to address common problems. For example, first-floor window sills should be 12 to 14 inches high (pattern #222). Car parking should occupy no more than 9% of land (#22). Balconies should be no shallower than 6 feet (#167). Patterns in this sense are highly applicable and concrete.

Level 2: Information Architecture

A Pattern Language is believed to be the first book written in hypertext, with non-hierarchical links (see “context” above) between closely related patterns. This was by necessity, as patterns form an interconnected web which can generate a vast range of combinatorial possibilities to address unique, contextual needs. As suggested by the title, this format is similar to a language in which just a few letters can be combined in many ways to form tens of thousands of words, which can be combined in even more ways to form an infinite number of sentences.3

Level 3: Process

Patterns must be applied and interrelated through a process. In texts like Systems Generating Systems (1968), The Timeless Way of Building (1979), and The Nature of Order (1981), Alexander describes a design process akin to "the way it works in nature," that is, through step-by-step adaptation. In contrast to the top-down approach of modernist design,4 Alexander's method is more like gardening. The designer accepts more limited control over outcomes in exchange for the generativity and context-sensitivity of an open-ended compositional process.

Level 4: Epistemology

Alexander describes a research method, called the “Mirror of Self” test, by which we can evaluate a design. Subjects are asked to self-examine the degree to which a given system or object (say, a salt shaker) “enhances their wholeness” relative to that of another item (say, a bottle of ketchup). Despite the unusual question, most people are able to give a firm answer—and, according to Alexander in The Nature of Order, responses are astonishingly consistent. Alexander wrote about the results, “People make the same choice, whether they are young or old, man or woman, European or African or American.”

Alexander’s method implicates an epistemological framework that allows for an objective reality beyond that which is perceptible to, “the dry positivist view too typical of technical scientific thinking.” He described aesthetics as “a mode of perceiving deep structure, a mode no less profound than other simpler forms of scientific observation and experimentation."

To the modern rationalist thinker, this likely sounds a little woo-woo. But as we’ll see, science may be catching up.

Level 5: Value System

Persistent in Alexander’s work is a call to make the world more whole through “living structures.” In Notes on the Synthesis of Form (1964), this value system is a matter of form having fit within its unique context. In The Timeless Way of Building, he describes “the quality without a name” which he later calls life or wholeness. This quality is deeply relational. In A Pattern Language, he implores designers:

“When you build a thing, you cannot merely build that thing in isolation. You must repair the world around it, and within it, so that the larger world becomes more coherent and more whole; and the thing takes its place in the web of nature as you make it.”

To Alexander, design is a process that is interwoven with the natural world around it and can, and should, positively contribute to rebuilding and improving society.

Not long after first encountering Alexander's work, I enrolled as a graduate student at UC Berkeley’s College of Environmental Design—where Alexander taught until the early 2000’s.

To my surprise, however, I could hardly detect a trace of his imprint at the CED. Despite the fact that he taught there for four decades and produced an abundance of meaningful work, Alexander was almost never mentioned. Most students made it through their entire programs without ever hearing his name.

Why were such monumental ideas seemingly erased?

An Absence in Complexity

In the fall of 2019, I found myself at the Santa Fe Institute with some of my friends and colleagues from Google. We are all deeply fascinated by complex systems, so being at SFI—the world-renowned epicenter of complexity science—felt to us a bit like a trip to Mecca.

The event we were attending was a fairly small three-day symposium. To our amazement, we frequently found ourselves in conversations over coffee with luminaries like Geoffrey West (author of Scale), Eric Beinhocker (author of Origins of Wealth), Joshua Epstein (pioneer of agent-based modeling), and Brian Arthur (a godfather of complexity economics). Occasionally we’d step out into the dry New Mexico air to give our aching brains an opportunity to process everything.

Though he had passed away four years prior, the presence of John H. Holland—a leading figure in the genesis of complexity science and an SFI founder—was strongly felt. As I think many at SFI would agree, there’s likely no better person from whom we can learn the basics of complexity.

Holland characterized complex systems as exhibiting the following five behaviors:

1. Self-organization

Elements of the system self-organize into ordered patterns, as occurs with flocks of birds or schools of fish.

2. Chaotic behavior

Small changes in initial conditions produce large changes later on (popularly known as 'the butterfly effect').

3. 'Fat-tailed' behavior

Extreme events (e.g. mass extinctions and market crashes) happen more often than a normal (bell-curve) distribution would predict.

4. Adaptive interaction

Interacting agents (like traders in a marketplace or players in a Prisoner's Dilemma) update their strategies in diverse ways as they accumulate experience.

5. Emergence

Spontaneous, global order results from many local interactions between agents who lack a source of centralized control.

Since complex systems exist in such a wide range of phenomena, SFI convenes a vast breadth of disciplines. At the symposium, we met physicists, political scientists, epidemiologists, economists, sociologists, ecologists, computer scientists, and even philosophers.

To my surprise, however, there were no designers. No architects, no industrial designers, no graphic designers, no urban designers, no UX designers, and no service designers. Here we were, peering into the fundamental nature of the very social problems designers profess to solve, yet they were nowhere to be found.

Why were designers absent?

Alexander gave us a starting point for applying complexity theory in design

Though Alexander’s work predates the formal term “complexity science,” both describe the same fundamental patterns of complex systems.5 Both focus on interactions within systems where the whole is greater than the sum of its parts.

For example, Alexander described pattern languages as "very complex sets of interacting rules.” Using precisely the same understanding as Alexander, a central interest of complexity science is pattern formation.

Alexander described his evolutionary design process as a "new technique that focuses on emergence” (emphasis added) towards greater fitness between form and context. Meanwhile, biologist and complexity scientist Stuart Kauffman describes evolution as a process occurring across “fitness landscapes” with “adjacent possibilities.”

By 2003, Alexander was in direct conversation with complexity science. He penned an essay titled New Concepts in Complexity Theory, inviting complexity science into the normative design framework.

The essay’s attempt to bridge between the fields highlights where Alexander and complexity science diverge, and begins to explain the rift we witness between complexity science and design today. While complexity science is chiefly interested in describing and understanding complex systems as they arise in nature or society, Alexander embraces the logic of complex systems into the practice of design.

“In [fields dealing with complexity] the scientists are passive as to the issue of creation. In architecture, we are the active proponents.”
—New Concepts in Complexity Theory, 2003

Alexander makes the case that the kind of fitness that arises from complex systems in nature (the evolution of a bird's beak, for example) can and must be achieved by designers through new step-by-step adaptive processes.

Still, Alexander’s move towards actionable complexity doesn’t fully explain why design and complexity theory no longer overlap.

Why have design and complexity theory grown apart?

In 2005, a survey of 1,051 design professionals, faculty, and students asked respondents to prioritize various potential design research topics. Systems theory (a superset of complexity theory) ranked at the bottom of pressing matters for research. (Sustainability—which perhaps most exemplifies the need to understand complex systems—ranked first.)6

I don't know exactly why designers have turned away from complex systems, but one possibility is that complexity challenges a central doctrine of design—namely, that it is the designer’s job to identify desirable outcomes and exert as much control over the process as possible towards those ends.

In some cases, such as the design of a simple object with a simple function (e.g. a chair), this conceptualization may be sufficient.7

But in the world of complex systems—cities, economies, ecologies, society, and the like—complexity theory teaches us that the totalitarian designer’s approach is both likely to backfire in unexpected ways and sacrifices the vast networks of local intelligence distributed throughout the system.

Complexity theory suggests a new conception of design that flies in the face of mainstream practices over the last century. Reimaging design in this way will not come easily, but in many cases, it is necessary.

Why should designers understand complexity theory?

“Complexity is the science of the 21st century”
—Stephen Hawking

I believe that complexity science is the beginning of an upcoming (and deeply necessary) revolution in the cognitive tooling of society. The mental models of a deterministic machine-like reality have gotten us far in complicated domains where systems actually operate in this manner (such as Newtonian physics), but we’ve seen these methods collapse in the face of systems that are complex. Worse still, the failure of these enlightenment ideas to achieve social progress has induced a sort of epistemic resignation that the systems surrounding us are unknowable and uncontrollable, thus rendering our actions effectively meaningless. This is not true!

As a field centered around forging the future by developing new solutions, design in particular must understand complexity. The wicked problems of the 21st century—climate change, inequality, pandemics, political breakdown, and more—demand no less.

Designers must pick up where Alexander left off and develop new ways to think about and apply complexity science in our work, for three main reasons:

1. Reality is complex. We design within reality.

As I have mentioned, Alexander described good design as a proper fit between form and context. If the context is complex (as it often is) then the design of form must understand the nature of complexity. Rigid, non-adaptive, centralized, and machinistic solutions are a path to crisis.

Appropriately, complexity science may be rising in relevance due to evolutionary pressures. If we are to survive as a species in a changing environment, unfit mental models must be eclipsed by better adaptations to the world around us. And, if we are to survive, then those who design the systems around us need to be plugged into this new scientific revolution.

2. Design for emergence leverages distributed intelligence.

Emergent outcomes cannot be planned in advance, just like cities don’t follow one large blueprint and only the complex process of coevolution can create a rainforest.

This reality is not a threat to designers, but an opportunity. In many cases, thousands of minds are exponentially better than one. The final outcome may be one the original designer never imagined, and that’s exactly the point: design for emergence leverages the unique intelligence of end-users to adapt solutions to their unique contexts. This kind of design can create something wonderfully complex like a rainforest—an ecology of heterogeneous agents evolving and co-evolving novel problem solving strategies within a complex web of relationships.

Consider the wide range of adaptive outcomes made possible by digital spreadsheets, in which the simple relationships of cells (which can only contain a small handful of data types) can be combined to create highly complex systems. Digital spreadsheets have eclipsed thousands of would-be single purpose software tools because a general purpose tool designed for emergence can fulfill a wide variety of potential niches.8

Alexander attempted to leverage this kind of local intelligence by creating widely accessible tools like A Pattern Language.9 In Systems Generating Systems, Alexander describes this kind of design as a “kit of parts.” We might think of these kits as innovation-enabling innovation, from which entire ecologies of ideas and solutions might emerge.

3. Design benefits from interdisciplinary mental models

In 1969, Ludwig von Bertalanffy outlined the major aims of general system theory (a precursor to complexity theory):

1. There is a general tendency towards integration in the various sciences, natural and social.

2. Such integration seems to be centered in a general theory of systems.

3. Such theory may be an important means for aiming at exact theory in the nonphysical fields of science.

4. Developing unifying principles running 'vertically' through the universe of the individual sciences, this theory brings us nearer to the goal of the unity of science. This can lead to a much-needed integration in scientific education.

This integration is also necessary in design. The human experience is so exceptionally multidimensional that it forces us to bring together established mental models from diverse fields. Complexity theory combines these many fields, in part because it offers a shared language for collaborating across distinct areas of study and drawing value from these differing perspectives. Ecologists are sharing ideas with economists, physicists are collaborating with political scientists, and computer scientists are engaged with epidemiologists—all with promising results.

What would happen if designers joined the exchange?

More Resources

For an expanded introduction to Christopher Alexander, check out Ryan Singer’s fantastic talk here:

For more examples of “design for emergence” in the space of software and technology, check out Gordon Brander’s recent post drawing from the ideas of Friedensreich Hundertwasser:

For a deeper dive on the potential of complexity theory for designers, you can watch my talk Designing for Complexity given at Milan Design Week last summer:

The principal characteristics of a rhizome: unlike trees or their roots, the rhizome connects any point to any other point, and its traits are not necessarily linked to traits of the same nature; it brings into play very different regimes of signs, and even non-sign states.
—Gilles Deleuze and Felix Guattari, A Thousand Plateaus

Hello friends!

Here’s a little flag in the ground of cyberspace, a sandbox for thought, and an opportunity to share a few things I’ve learned in my journey through design, research, and complexity. It is also an extension of my independent research operation by the same name.

Some areas of inquiry include:

• Complexity theory for designers

• Research as a form of map-making

• Meta-processes for novel problems

• Interdisciplinarity as mental model arbitrage

• Generative methods for grounded strategy

• Tools for thought

Centrally, the writing here will revolve around novel problems, and how to approach them. Since we have no shortage of novel problems, I hope it can be a resource for you in thinking about, strategizing, understanding, addressing and perhaps even solving the novel problems ahead of you—as well as an opportunity for us to learn together.

Here we go!

Cheers,
Kasey

Subscribe now