End-user programming

End-user programming is the practice of enabling people who are not professional software developers to create, modify, and extend computational systems. Unlike conventional programming, which requires specialized training in syntax, algorithms, and software architecture, end-user programming embeds computational capability within domain-specific tools — spreadsheets, visual scripting environments, interactive notebooks, and macros — that users already understand.

The concept has its deepest roots in Seymour Papert's Logo and Alan Kay's Smalltalk, both of which were designed to make programming accessible to children. In commercial computing, the spreadsheet is the most successful end-user programming environment in history: millions of users write formulas, conditionals, and recursive calculations without identifying their activity as programming. Excel alone contains more lines of "code" than all professional software combined, written by people who would never call themselves programmers.

The Systems Problem

The challenge of end-user programming is not technical but epistemological. Professional programming assumes a separation between the system and its user. End-user programming dissolves this boundary, creating systems that are simultaneously tools and subjects of modification. This makes them difficult to maintain, difficult to secure, and difficult to reason about — but also uniquely capable of evolving to fit the idiosyncratic needs of their users.

Consider the spreadsheet. A single Excel workbook can contain business-critical logic — valuation models, risk calculations, compliance checks — embedded in formulas that reference cells across dozens of sheets, with no version control, no testing framework, and no documentation. When the original author leaves, the organization inherits a black box that nobody understands but everyone depends on. The 2008 financial crisis revealed that some of the most consequential decisions in global finance were made using spreadsheet models with known errors that propagated through the system undetected.

This is the paradox of end-user programming: it democratizes computational power while concentrating risk. The user who builds the model is not the user who audits it, and the user who audits it lacks the time and tools to do so properly. The result is a shadow infrastructure of unverified, unmaintained, business-critical software that exists outside the governance structures of professional software engineering.

Security and Governance

End-user programming poses a distinct security challenge. Traditional software security assumes a hard boundary between code and data, between trusted and untrusted inputs. End-user environments blur these boundaries: a spreadsheet cell can contain data that is also code (a formula), and a macro can download and execute arbitrary code from the internet. The attack surface is not the operating system but the user's cognitive model of what the tool does.

The response has been to restrict: disable macros by default, sandbox scripts, limit API access. But each restriction reduces the power that made end-user programming attractive in the first place. The tension is irresolvable: either the user has enough power to solve their problem, or the system has enough control to prevent misuse. Most organizations oscillate between the two poles, producing policies that are simultaneously too restrictive to be useful and too permissive to be safe.

The Current Landscape

The 2020s have seen a resurgence of end-user programming, driven by three forces. First, large language models have lowered the barrier to generating code from natural language descriptions, enabling users to produce scripts and applications without learning syntax. Second, no-code and low-code platforms have proliferated, promising to replace programming with visual interfaces. Third, the integration of computation into everyday tools — from data analysis in Jupyter notebooks to automation in Notion and Airtable — has made end-user programming the default mode of interaction with digital systems.

Whether this resurgence will solve the governance problems of end-user programming or merely amplify them remains to be seen. The history of the field suggests that each wave of democratization is followed by a wave of consolidation, as the costs of unmanaged complexity become unbearable. The question is not whether end-user programming will persist — it will, because it serves a genuine need — but whether we can develop governance structures that allow it to flourish without producing the institutional fragility that has characterized its previous iterations.

The spreadsheet is the most widely used programming language in history. It is also the most dangerous. The danger is not in the tool but in the social arrangement that places critical decisions in the hands of users who have never been taught to think about the systems they are building. End-user programming is not a technical problem waiting for a better interface. It is a social problem waiting for a better theory of distributed cognition and distributed responsibility.