From Users to Creators: The New Democratization of Software
For decades, the relationship most people had with software was fundamentally asymmetric. A relatively small group of professionals designed, programmed, and distributed it, while everyone else learned how to use it. Companies and individuals could choose between different products, configure them within certain limits, or combine multiple tools to solve a particular need, but the possibility of radically modifying how those systems worked—or building an alternative—remained largely restricted to people with technical knowledge. If an application did not do exactly what someone needed, the available options were predictable: adapt the process to the limitations of the software, look for another product, request a modification from an IT department, hire a developer, or learn how to program.
Generative artificial intelligence is beginning to alter that relationship. Not because it has eliminated the need to understand programming, nor because building reliable software has suddenly become trivial, but because it is reducing a distance that remained considerable throughout much of computing history: the distance between identifying a problem and building a digital tool capable of solving it. A person can now describe a workflow in natural language, request an interface, generate a function, connect services, transform data, build an automation, or produce the first functional prototype of an application without necessarily mastering the programming languages operating beneath those layers.
The distinction matters. Democratizing programming does not mean turning the entire population into professional software engineers. It means expanding the number of people capable of treating software not only as a finished product, but also as a modifiable material. The potential consequence is a change in the condition of the user itself: from a consumer of tools designed by others to a creator of tools built around their own needs.
A Democratization That Began Before Artificial Intelligence
The idea of allowing non-specialists to build programs did not begin with large language models. Spreadsheets, macros, content management systems, automation tools, and, more recently, low-code and no-code platforms have progressively increased the level of abstraction through which people can interact with computers. Research on end-user programming—programming carried out by people whose primary profession is not software development—predates the current generation of artificial intelligence by decades. A study presented at CHI 2016, for example, analyzed more than 200,000 public automations created through IFTTT and found a substantial ecosystem of users building small programs based on “if this happens, then do that” rules, often to provide functionality that the original applications did not offer.
What changes with artificial intelligence is the interface and, potentially, the scale of participation. A systematic review published in 2026 in Springer Nature’s Management Review Quarterly, based on the analysis of 383 definitions drawn from 306 publications, describes precisely this evolution of low-code and no-code platforms. The authors identify a transition from models based primarily on predefined instructions and components toward systems increasingly centered on user intent, in which natural language and AI agents can participate in the generation of interfaces and business logic. The study refers to this evolution as Programming by Natural Language: users describe through text or voice what they want to build, while the system translates that intention into an initial implementation that can later be refined iteratively.
From a historical perspective, generative AI can therefore be understood as another layer in a much longer process of abstraction. Programmers stopped entering binary instructions directly decades ago; high-level programming languages concealed much of that complexity; libraries and frameworks later encapsulated increasingly sophisticated operations; graphical interfaces allowed certain applications to be built without specifying every instruction manually; and now natural language is beginning to operate as another intermediate layer between human intent and the system that ultimately executes it. Code does not disappear beneath this abstraction, just as Internet Protocol does not disappear when someone uses a browser. Instead, a growing proportion of its complexity becomes invisible during the user’s immediate interaction.
From Software for Millions to Software for One Person
This reduction in the barriers to creation may have a particularly interesting economic consequence. Traditionally, software development was expensive enough that, outside certain internal projects, it generally made sense to build products capable of serving many users. A company identifies a relatively common problem, develops a generalized solution, and distributes the cost of that development across hundreds, thousands, or millions of customers. This logic explains much of the economics of commercial software: a word processor, CRM, project management platform, or productivity application must provide enough flexibility to serve users whose workflows are never exactly identical.
Lower development costs introduce another possibility: software whose legitimate audience may consist of a single person. A lawyer may need a system that classifies certain documents according to criteria specific to their practice; a researcher may want a tool that transforms scattered information into a structure adapted to a particular methodology; a designer may automate the preparation of repetitive files; an administrator may create an interface that consolidates information from several services; or a student may build a system that organizes materials, dates, and notes according to a completely personal logic. None of these tools needs to become a company, attract investment, or acquire thousands of users to be valuable. Their economic justification may simply be that they save one person several hours every week.
This makes it possible to imagine a much broader category of personal software than the one we have known until now. The idea goes beyond customizing an existing application through a few configuration options. Instead, people could construct small digital capabilities around the particular way they work. Some of these systems may exist for years; others may be created for a month-long project and discarded afterward. Under the traditional model, spending several days of engineering time on a tool designed to solve a temporary problem could be economically irrational. If a significant portion of that tool can instead be created conversationally in far less time, the calculation changes.
The comparison with previous technological democratization processes is useful. Digital cameras, and later smartphones equipped with increasingly capable cameras, did not turn every person into a professional photographer, but they radically reduced the cost of producing an image and triggered an enormous expansion in the number of photographs created. Content management systems did something similar for web publishing: they did not eliminate professional web development, but they allowed millions of organizations and individuals to publish online without building a site from scratch. AI-assisted development may produce a comparable phenomenon: not necessarily fewer developers, but dramatically more software.
The Possible Era of Microsoftware
This logic allows us to introduce the concept of microsoftware: small applications, automations, scripts, agents, or interfaces designed to solve an extremely specific problem and whose existence does not require them to become standalone commercial products. The term is useful here as an analytical framework rather than as a formal technical category. One piece of microsoftware may exist only to receive certain files, extract five variables, compare the results with a database, and generate a report; another may reorganize notes after a meeting; a third may prepare a weekly summary; and a fourth may connect two systems that were never designed to work together.
What matters is not each individual tool, but the environment that can emerge once building them becomes cheap enough. A worker could eventually operate alongside dozens of small personal systems designed to remove specific points of friction from everyday work. Instead of relying exclusively on large general-purpose applications, their digital environment could consist of a combination of commercial platforms, APIs, artificial intelligence models, and automation layers constructed around individual needs. The everyday question may therefore shift from “What application already exists for this?” to “Why am I still doing this manually?” or “Can I create something that does exactly what I need?”
This shift may be especially important for small businesses and teams that have historically been trapped between two imperfect options: using generic software that does not fully match their operations, or absorbing the cost of building custom systems. Artificial intelligence does not eliminate this tension—particularly when security, availability, scalability, or regulatory requirements become important—but it may greatly expand the middle ground in which smaller solutions can be built and maintained locally.
Natural Language as a Programming Interface
One of the most visible changes in this new phase is that describing an intention can increasingly become part of the programming process itself. For decades, turning an idea into software required several layers of translation: understanding the problem, designing a logical solution, and then expressing that solution through a syntax precise enough for a computer to execute. Generative models introduce a new layer capable of participating in that final translation. In simplified form, the process can be represented as: human intent → natural language → technical representation → code and execution.
The importance of this layer should not be confused with the idea that natural language possesses the precision of a formal programming language. Saying “organize my important documents” remains extraordinarily ambiguous compared with a technical specification. What does “important” mean? What happens when a file is duplicated? Where should information be stored? Who should be allowed to access it? What happens when classification fails? What should be preserved, and what can safely be deleted? Artificial intelligence may reduce the amount of work required to produce an implementation, but someone still has to make or supervise these decisions. This is why natural-language programming does not eliminate engineering: it shifts part of the effort from writing syntax toward specifying intent and evaluating outcomes.
Evidence from major technology organizations also shows how deeply AI has already entered parts of the software engineering workflow. Google Research reported in 2024 that its internal AI-based code completion tools achieved a 37% acceptance rate among engineers and participated in the production of roughly half of the characters typed into code in the contexts examined. At the same time, Google emphasized the importance of measuring actual effectiveness and distinguishing between a technically impressive demonstration and a system that materially improves the workflow of a developer.
Productivity: A More Complicated Story Than It First Appears
Lower barriers to software creation should not automatically be interpreted as higher productivity. The available evidence produces different outcomes depending on the kind of user, the type of task, the working environment, and the way productivity is measured. A controlled experiment conducted by researchers from GitHub and Microsoft found that programmers using GitHub Copilot completed a specific JavaScript HTTP server task 55.8% faster than participants without access to the tool. The researchers also suggested that the effects could be particularly relevant for people who were still developing their programming experience.
It would be misleading, however, to extrapolate from that experiment and conclude that artificial intelligence makes every software developer 55% more productive. A randomized controlled trial published by METR in 2025 examined almost the opposite setting: 16 experienced developers working on 246 real tasks inside large open-source repositories they had known for years. Before the study, participants believed that AI would reduce their completion time by approximately 24%. Even after using the tools, they estimated that AI had made them around 20% faster. The measured result was the opposite: in that specific environment, access to AI tools increased task completion time by approximately 19%. METR itself emphasized that the result should not be generalized to all software development, but the experiment is valuable precisely because it demonstrates that the effect of AI depends profoundly on the context in which it is used.
Stack Overflow’s 2025 Developer Survey shows a similar tension between adoption and confidence. Eighty-four percent of respondents said they were already using or planned to use AI tools in the development process, up from 76% the previous year, while 51% of professional developers reported using them daily. At the same time, 46% said they distrusted the accuracy of AI-generated outputs, compared with 33% who said they trusted them. Two of the most frequently cited frustrations involved receiving solutions that were “almost right” and spending additional time debugging AI-generated code.
The reasonable conclusion is therefore not that AI “works” or “does not work” for programming. Instead, its value changes according to the task. Building a relatively bounded application from scratch, exploring an unfamiliar programming language, generating repetitive code, or producing a prototype may benefit significantly from generative tools. Understanding a mature architecture, modifying systems with numerous side effects, preserving compatibility guarantees, or making decisions that depend on years of contextual knowledge is a different category of problem. Google Cloud’s 2025 DORA research reflects this distinction by describing successful AI adoption in software development as a question of systems and organizational capabilities rather than simply the acquisition of a new tool.
When Writing Code Is No Longer the Only Scarce Skill
If producing certain types of code becomes progressively cheaper, technical knowledge does not disappear; instead, the distribution of value changes. Memorizing a specific syntax may become relatively less differentiating in some contexts, while other capabilities become increasingly important: identifying a problem correctly, defining its limits, decomposing it into components, designing constraints, understanding data, evaluating results, identifying exceptions, verifying behavior, and recognizing when an apparently functional solution is wrong.
In this environment, someone without a traditional engineering background may be able to create surprisingly useful tools if they possess deep knowledge of their field and can describe their workflows clearly. The expertise of a doctor, lawyer, researcher, accountant, designer, or operations specialist may be combined with systems capable of translating parts of that expertise into software. Yet this same possibility also explains why professional developers remain essential. When a tool stops being a personal experiment and begins handling money, identities, confidential information, important decisions, thousands of users, or critical infrastructure, understanding what is happening beneath the abstraction layers becomes even more important.
It is therefore more accurate to describe the shift as a redistribution of skills rather than their disappearance. Professional developers may increasingly focus on architecture, security, infrastructure, observability, integration, quality assurance, platform design, and problems that require systemic understanding, while other users build on top of the layers those professionals provide. Paradoxically, the easier software becomes to generate, the more important it may become to distinguish between a demonstration that works and a system that can be maintained reliably.
Democratizing Software Also Democratizes Its Errors
There is an inevitable consequence to expanding the number of people capable of building applications: the number of people capable of building insecure, fragile, or incorrect applications also increases. An interface may appear to work perfectly while still storing credentials improperly, exposing personal data, trusting manipulable inputs, relying on vulnerable dependencies, lacking appropriate authorization controls, or producing incorrect results in situations its creator never anticipated.
This concern is not hypothetical. The Center for Security and Emerging Technology at Georgetown University has identified three broad categories of risk associated with AI code-generation systems: the generation of insecure code, vulnerabilities within the generative systems themselves, and downstream effects on software supply-chain security. The Center also warns that these risks will not be distributed equally. Organizations with greater resources can implement security reviews, testing procedures, and governance mechanisms that may not be available to individuals or smaller companies.
NIST addresses a related issue in its Secure Software Development Framework profile for generative AI systems. The agency notes that AI-based systems inherit traditional software risks while introducing additional concerns related to models, data, natural-language inputs, and new surfaces susceptible to manipulation. Its underlying recommendation remains relevant regardless of whether the code was written manually or generated by AI: secure software development requires protection, review, validation, and vulnerability-response processes throughout the system lifecycle.
This creates a fundamental distinction in any discussion about democratization: creating functional software and creating trustworthy software are not the same activity. AI can dramatically lower the barrier to the first. The second still depends on engineering discipline, testing, security, maintenance, domain expertise, and responsibility.
From Shadow IT to Shadow Software
Within organizations, this new capacity also creates a governance problem. For years, companies have used the term Shadow IT to describe technologies, applications, or services adopted by employees and departments without the knowledge or oversight of the organization’s formal technology function. Low-code and no-code platforms had already expanded this phenomenon; generating applications through natural language may push it significantly further.
Consider an employee who needs to automate a recurring task and, instead of waiting for approval of a new corporate system, creates in a few hours a small application connecting a spreadsheet, an external API, internal documents, and an AI model. From the employee’s perspective, an inefficiency has been eliminated. From the organization’s perspective, a different set of questions immediately emerges: What information is being processed? Where is it stored? Which permissions does the application have? Who maintains it if the employee leaves the company or changes roles? What happens if an API changes its behavior? Is there a backup? Does the system comply with internal policy and external regulation?
The Springer review of software development democratization explicitly identifies Shadow IT and technical debt among the risks that must be considered as low-code and no-code platforms move toward hyperautomation and intent-driven development. The likely result is the emergence of a new form of Shadow Software: hundreds or even thousands of small tools, automations, and agents created throughout an organization because their individual cost is low enough for employees to solve problems locally, but whose combined effect produces an infrastructure that no one fully understands or governs.
The organizational response cannot realistically consist only of prohibition. If these tools genuinely solve needs that centralized technology systems cannot address quickly enough, the incentive to use them will remain. The challenge will instead be to create governance models capable of preserving the speed of distributed development while maintaining control over data, permissions, identity, security, traceability, and maintenance.
The New Digital Divide
Speaking about democratization can create the impression that technological inequality will disappear. It is more likely that the dividing line will simply move. When operating a computer required knowledge of command-line systems, people who understood those environments possessed a substantial advantage. Graphical interfaces reduced that barrier but created others. The Internet dramatically lowered the cost of publishing information, yet it did not automatically turn every user into a producer capable of building influence or reaching an audience.
Something similar may happen with AI-assisted software development. The new divide may no longer exist only between those who know how to program and those who do not, but between those who know how to convert artificial intelligence into productive capability and those who merely consume its outputs. A person capable of understanding their own work as a collection of processes, identifying repetitive tasks, designing automations, structuring information, evaluating a solution correctly, and combining different services will possess a meaningful advantage even if they never memorize the full syntax of a programming language.
Technological literacy may therefore need to expand in meaning. It may no longer be enough to know how to use a word processor, spreadsheet, or specific software platform. It will become increasingly important to understand which processes can be automated, what information should or should not be delegated to a model, when a result needs verification, what permissions are being granted, and what happens when different systems are connected. The ability to build will become more widely distributed, but so will responsibility for what is built.
More Software, Not Necessarily Fewer Developers
Much of the public discussion around artificial intelligence and programming is framed as a labor question: if a machine can write code, how many programmers will still be required? The question is reasonable, but it may implicitly assume that society’s demand for software will remain constant. The history of other technologies suggests something different: when the cost of producing something falls dramatically, we usually begin producing much more of it.
If the cost of turning a small need into a functional digital tool falls sufficiently, projects that would never previously have received a budget suddenly become viable. A small company that would never have hired a development team to build ten internal systems may eventually operate dozens of automations. An individual who would never have commissioned a custom application may create several. Professional teams may experiment with significantly more ideas before deciding which deserve to become robust products. The cost per unit of software declines, while the universe of problems considered economically worthwhile to solve with software expands.
The role of the professional developer will almost certainly change as a result. Certain tasks can be partially automated, and some forms of work may lose relative value while others become more important. But reducing the entire transformation to a competition between “AI” and “programmers” overlooks a deeper consequence: the boundary defining who can produce software is moving.
From Users to Creators
The most important revolution brought by artificial intelligence to programming may not be that a model can generate a Python function, build a web page, or fix a programming error. Those capabilities are technically significant, but they belong to a larger phenomenon: the reduction in the cost required to turn an intention into a digital capability.
For decades, we learned to live inside systems designed by other people. We changed our processes to accommodate their menus, columns, forms, workflows, and limitations. The next phase may partially reverse that relationship. Instead of constantly searching for an application that comes sufficiently close to what we need, we will increasingly be able to create layers of software around the problem itself.
This does not eliminate professional software development, engineering, or the need for technical expertise. In fact, it may make those skills more important wherever the consequences of failure are greater. Nor does it mean that anyone can safely build any system simply by describing it. The available evidence on productivity, reliability, trust, and security demands a considerably more cautious interpretation.
Even with those limitations, however, the shift remains profound. Low-code platforms reduced the amount of code required to build software; no-code platforms allowed certain systems to be constructed without interacting with code directly; and generative models are beginning to reduce the distance between intention and implementation itself. Programming is therefore becoming, in some contexts, less exclusively a conversation between a programmer and a machine and increasingly a conversation between a person, an artificial intelligence system, and the infrastructure capable of executing what they define together.
The result may be an era in which creating small digital tools is no longer an extraordinary activity. An era in which an application can have a single user, exist for a week, and still be economically rational. An era in which automating repetitive work becomes less of a decision reserved for an IT department and more of an individual capability.
For decades, the user had to adapt to software. The new democratization of development raises the possibility of the opposite: that more and more software will be able to adapt to the user.
References
Abendroth et al. The democratization of software engineering: evolution, definition, and the future of low-code and no-code platforms. Management Review Quarterly, Springer Nature, 2026. View publication.
Stack Overflow. 2025 Developer Survey — AI. Data on AI adoption, trust, perceived productivity, and developer concerns. View survey.
Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. View paper.
Becker, J., Rush, J., Barnes, B., & Rein, D. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR, 2025. View study.
Chandra, S., & Tabachnyk, M. AI in Software Engineering at Google: Progress and the Path Ahead. Google Research, 2024. View publication.
Google Cloud / DORA. 2025 State of AI-Assisted Software Development. View report.
National Institute of Standards and Technology. Secure Software Development Practices for Generative AI and Dual-Use Foundation Models — NIST SP 800-218A. 2024. View NIST publication.
Ji, S., Jun, M., Wu, H., & Gelles, R. Cybersecurity Risks of AI-Generated Code. Center for Security and Emerging Technology, Georgetown University, 2024. View report.
Ur, B. et al. Trigger-Action Programming in the Wild: An Analysis of 200,000 IFTTT Recipes. CHI 2016. View proceedings.
