Maybe Not Everyone Wanted to Be a Programmer

I have been metabolizing the Airtable news for a few days, and I am going to resist trying to extract some grand conclusion from it. Companies get sold for all sorts of reasons, markets change, and retrospective explanations have a suspicious tendency to make everything look inevitable. I am, however, skeptical of one explanation making the rounds, which is that Airtable somehow lost the race to AI. Airtable was supposed to let more-less ordinary businesspeople build their own software solutions, AI arrived and made that dramatically easier, and suddenly Airtable found itself on the wrong side of history...maybe.

There is another possibility worth considering: perhaps the citizen programmer dream was never quite as large as everyone thought it was.

As I always understood it, Airtable was built around a compelling idea: The person closest to a business problem often understands it better than the people building software for them, so give that person sufficiently flexible tools and they can construct exactly what they need. No development team, no six-month IT project, no requirements document produced by seven people followed by another meeting to determine what the requirements document means.

At one point, markets proclaimed Airtable was going to become the real operating system of business. They built a good business, but it remained far from that vision. The question is whether the ceiling was always considerably lower than the dream. There may simply be fewer people wandering around accounting departments desperately wishing they could become software developers than Silicon Valley imagined.

We have been using uncontrolled spreadsheets as evidence for the opposite proposition for decades. Look at all those spreadsheets inside companies; clearly people want to build their own software; I am not sure that follows. People build spreadsheets because spreadsheets are spectacularly good at solving local problems. The state is visible, the dependencies are limited, and you can see the inputs, formulas and outputs sitting in front of you.

Things get ugly surprisingly quickly when the problem becomes important. Salesforce says one thing and NetSuite says another, Finance has rules, Legal has different rules, and Operations has exceptions to both because Dave in Ohio has apparently been doing something completely different since 2017 and nobody can remember why. Now we need permissions, security, audit trails, data retention, exception handling and integrations; just to get a little automation going, somebody has to decide which system owns the customer and what happens when one of the six systems involved changes something. Our empowering little citizen development project has somehow now acquired business analysts and engineers.

This is where I have trouble with the claim that AI means everyone will simply prompt their way out of SaaS systems. The logic is appealing: AI makes software extraordinarily easy to create, the user knows the problem, the user tells the AI what they want, the AI builds it, and everyone starts wondering why they are paying some SaaS company $47 per seat per month.

Some of that is absolutely going to happen. If your SaaS product is essentially a database with a nice logo and three opinionated workflows sitting on top of it, this might be a good time to revisit the strategic plan. There is a class of software whose value depended heavily on the cost of building a relatively simple interface around a relatively simple process, and AI is coming directly for that cost.

The larger conclusion, that SaaS itself is doomed, seems considerably harder to support. Usually the user knows their part of the problem. Sales knows what it needs, Finance knows what has to happen before revenue can be recognized, Operations kn ows what happens after the contract is signed, Legal knows why three apparently identical customers have completely different terms, and IT knows there are actually four customer databases while everyone else has been politely pretending there is one. There is often no single user who understands the whole problem well enough to prompt the correct system into existence. Much of the difficulty of enterprise software comes from reconciling these different versions of reality and getting an organization full of human beings to behave consistently enough for the whole thing to work.

I also have some history with another version of this problem. About twenty years ago I was building software for banks, and customers were constantly asking for configurable screens and integrations. They wanted our underlying system, but they did not necessarily want our opinion about how every employee should interact with it. One bank wanted these fields, another wanted those fields, another wanted information from some other system displayed on the same screen, and everybody had a workflow that was apparently unique in the recorded history of banking. The demand for what we would now call headless software was already there. The economics were terrible. Somebody still had to build all those screens and integrations, so software companies responded with configuration. Soon we were building products, configuration systems for the products, and increasingly elaborate ways of configuring the configuration system. Eventually there would be hundreds of settings, and nobody could remember what half of them did. This was considered progress.

AI makes that old idea interesting again because it could radically change the economics of the experience layer. A mature enterprise platform can own the data model, identity, permissions, security, auditability, transaction logic, integrations and years of accumulated institutional machinery, while interfaces and workflows become much easier to create and change.

Salesforce is already moving in this direction with its headless strategy. The interesting future may be one where a company keeps the enterprise power and maturity of (say) Salesforce underneath while employees, departments or agents interact with completely different experiences on top of it. Some of those experiences may barely resemble software as we currently think about it. The UI stops being the product boundary.

This feels much more significant to me than everybody becoming a citizen programmer. Perhaps people never particularly wanted to build software; they wanted software to conform more closely to the way they work. Historically those two things got conflated because customization required programming; AI may finally separate them.

A banker does not have to become a developer. She can say, in effect, I need these six things when I open a commercial account, I do not care about these other twelve fields and show me the credit information from the other system here. If AI can cheaply produce that experience while the serious machinery remains underneath, we have solved a problem enterprise customers have been complaining about since approximately five minutes after enterprise software was invented.

There is also some useful history here because AI is hardly the first technology that was supposed to collapse the economics of software.

Way back when, open source was going to do something remarkably similar. Once high-quality code became freely available, the argument seemed obvious; soon there would be a library for everything, increasingly sophisticated components would be sitting on the internet waiting to be assembled, and much of the scarcity value associated with software development would disappear.

A great deal of that prediction was correct, open source changed software enormously. Entire layers became effectively free, programming became more accessible, startups could build things with a handful of people that once required serious capital and infrastructure, and engineers moved up the stack. Cloud did it again, APIs did it again, frameworks and development tools did it again. Every few years another barrier falls.

What tends to happen afterwards is that engineering moves upward. As the lower layers become easier and cheaper, we attempt more ambitious things. Systems become larger and more interconnected, expectations rise, security gets harder, data volumes increase and new engineering disciplines appear.

AI may be a larger turn of that wheel. It could make the first 50 percent of building a business application astonishingly easy; perhaps it becomes 60 or 70 percent, and I have no particular interest in betting against the capability curve. The remaining complexity, however, often comes from the organization the software represents. General Motors remains General Motors regardless of how cheaply someone can generate code.

There may even be a perverse outcome. If everybody can create applications, workflows and agents, companies may eventually have more uncontrolled digital infrastructure. The CFO who once discovered 4,700 undocumented Excel files may someday discover 900 AI generated agents quietly moving financial and customer data around the company. We will presumably call this transformation.

Which brings me back to Airtable. Perhaps Airtable lost a race to AI. Perhaps AI really does unleash millions of citizen programmers who can finally build exactly what they need; I would not dismiss the possibility. I wonder, though, whether Airtable also helped us discover the natural ceiling of the citizen programmer idea. There are plenty of people who enjoy building things and plenty of local problems that lend themselves beautifully to it. Most people may simply want the systems they use to work better and conform more closely to what they are trying to accomplish.

That distinction matters when we start declaring every SaaS company a dead man walking. Some probably are in trouble, particularly those whose value amounts to a thin interface and a few workflows sitting on somebody else’s infrastructure. AI can eat a lot of that surprisingly quickly.

For everyone else, history offers another possibility. Open source lowered a barrier, cloud lowered another, APIs lowered another, and each time some layers lost value while engineering moved upward and new layers became important. AI may be the largest and fastest version of that transition we have seen.

Maybe this time the whole stack really does collapse; I stand ready to be wrong.

But I suspect it’s just another layer moving.

The Jacquard loom, invented around 1801, used punched cards to control complex weaving patterns; Babbage later recognized that the same idea could be applied to computing. The instructions could change without rebuilding the machinery underneath. So apparently we have been separating the interface from the infrastructure, and trying to make programming easier, for about 225 years. This may be less of a new idea than advertised.