The Programmable Web

The cost of producing software of any quality has fallen to the cost of a few API calls.  This mirrors the decline in production cost of many forms of media, like books and photographs.

As cost declines, production increases.  As Michael Keaton quipped while posing as Ray Croc, the founder of McDonald’s: “You increase the supply, demand will follow.”

Of course, the demand was always there; everyone wants to capture moments in time and share their ideas in ways that are more durable and transferable than memories and speech.  Everyone wants to create impressions.

This creative flood becomes a brute force search for “interesting”, placing pressure and strain on our ability to create, publish, host, filter, surface, and discover.  The browsable, hand-crafted blogosphere gave way to Twitter and Facebook’s commoditized units of content and algorithms out of necessity.  It would take us too much effort to create and too much time to find hawk tuah without them.

Today’s app development ecosystems resemble the creative contexts for writers and photographers pre-web and pre-iPhone.  They are based on assumptions that a trained professional is engaging in a noble pursuit.  Sit down, load up your IDE, give your app a name, make sure it belongs to a company with a business address, add a logo, upload screenshots, submit for review, wait, respond to the authorities, and hope your creation gets published.

Once you’ve tasted software creation via prompt, this multi-day journey and permission-seeking sounds excruciating.  What’s worse for incumbents: these app marketplaces have always acted as pressure release valves as they cannot possibly meet every customer's need using their internal resources.  Instead, “there’s an app for that.”  

But this new world of software creation will see customers bringing their own code to platforms and saying “run this now”, then five minutes later, “now run this.”  That valve wasn’t designed for this.

This is a role reversal of maker-consumer for software companies, who will either adapt or lose relevance.  Fitness will depend on their ability to call, host, execute, curate, surface, and dispose of code the way today’s social media companies handle static content.  This is an order so tall that it will be laughed at, then feared by most engineers inside large companies.

The winners? Today’s code and hosting platforms built for developers, from AWS to Cloudflare to Github, are not obviously it unless they solve for approachability.  Built for non-developers, no-code platforms will need to shed much of their forms UI if they want to capitalize on code generation by their end users, while somehow remaining approachable and not devolving into weak IDE’s.

It is inevitable and still up for grabs.

This post was also published as a tweet for easy sharing.