2026-07-14 · 8 min read · Raw Drafts / AI / Software / Organizations
The End of the Software Request
AI-generated software is shortening the organizational queue between noticing a need and building a tool, while moving hidden product decisions closer to the requester.
A large part of software work begins with a request.
Someone notices that a process is awkward, repetitive, or held together by spreadsheets. They describe the problem to someone else, who tries to turn it into requirements. The request enters a backlog, competes with other requests, gets discussed in meetings, reduced in scope, designed, developed, tested, and eventually released. Sometimes this works well. Sometimes the person who originally needed the software has already found another workaround by the time it arrives.
AI-generated software first changes this process. A person can increasingly move from noticing a need to making something that responds to it without first persuading an organization to allocate resources. The request no longer has to enter somebody else's queue.
There is a useful precedent in the spreadsheet.
Before electronic spreadsheets, exploring a new financial scenario could involve several people. An analyst changed an assumption, calculations were repeated, tables were prepared again, and the updated result returned later. VisiCalc brought much of that process onto one screen. The manager or analyst could change a number and immediately see what happened.
The spreadsheet did not remove accounting, finance, or data processing. It moved a particular kind of calculation closer to the person asking the question. It shortened the distance between wondering and testing. That was enough to change who could build models, how quickly organizations could respond, and how much informal software could exist inside a company.
AI coding tools appear to be doing something similar across a much wider range of work. A person who would previously have built a spreadsheet, created a Notion database, or sent a request to the product team can now attempt a small application. It might connect several sources, create an interface, automate a process, and publish the result. The difference between an internal workaround and a software product is becoming less obvious.
The request becomes the work
The most important capability of AI-generated software may be directness.
A founder can describe a small internal tool and watch it take shape. A researcher can build an interface around a dataset without waiting for an engineering slot. Someone in operations can turn an awkward sequence into an application before the next planning meeting has happened.
The application may still be fragile. It may still depend on hosted models, databases, authentication services, deployment platforms, and APIs. The organizational sequence around its creation has nevertheless become much shorter.
This is a form of disintermediation, although the intermediary being removed is difficult to name. It includes the developer, but also the ticket, the planning cycle, the specification, the budget approval, and the need to convince several people that the problem is worth solving.
The disappearing layer is the software request itself.
That makes this different from the usual story about AI replacing a profession. The product team may remain. Engineers may still be responsible for the systems that matter most. Designers may still make sense of complex workflows. The change is that these roles no longer control every point at which software begins to exist.
More software can now start elsewhere.
Desktop publishing for applications
Desktop publishing created another version of this shift.
Writing, typesetting, layout, proofing, and production had once been distributed across several people and technical systems. During the 1980s, the combination of the Macintosh, PageMaker, laser printing, and PostScript brought much of the composition process to the person sitting in front of the document.
More people gained control over the finished page. Many of them had little understanding of typography, printing, editorial structure, or production constraints.
The decisions did not disappear. They were made in more places, by more people, with varying levels of awareness.
AI-generated software is likely to have the same effect. A person generating an application is making decisions about permissions, defaults, data structures, error states, user behavior, and failure recovery, even when they think they are merely asking the AI to add a feature.
This may be desktop publishing for applications.
The old production system separated writing from composition and composition from printing. The new system placed them on one desk. AI is beginning to place product definition, interface generation, code, data, and deployment inside one conversational environment.
This expands authorship. It also expands the number of people making technical and product decisions without a clear sense that they are doing so.
Friction sometimes contained judgment
Software development has always contained a layer of interpretation.
A designer may question what a user appears to be asking for. An engineer may notice that the simple version of a request creates a security problem. A product manager may connect one department's request to a larger organizational pattern. These roles can be slow, political, and frustrating, but some of the friction contains useful judgment.
When a request goes directly into a generation system, part of that interpretation disappears. The system may produce a plausible version of exactly what was requested. This feels efficient until the request was based on an incomplete understanding of the problem.
Credit scoring offers a more uncomfortable example of what happens when interpretation is compressed into a system.
Earlier lending decisions depended heavily on personal assessment and the judgment of individual loan officers. Credit scoring converted parts of that decision into a standardized numerical process. This made decisions faster, more consistent, and easier to scale. It also moved authority into a system whose assumptions could be less visible and less open to negotiation.
The loan officer had not only been processing information. They had been the place where explanation, discretion, prejudice, context, and appeal could enter the decision. Standardization removed some arbitrary treatment and introduced another form of distance.
Generated software creates a related tension. The intermediary between intention and execution may have been doing more than implementation. They may have been translating between different views of the organization, preserving institutional memory, or noticing consequences that were invisible from the position of the requester.
Removing that layer creates speed. It can also remove the moment when someone asks whether the requested system should work in the requested way.
Shadow IT becomes larger than a spreadsheet
There is already a name for software that appears when people stop waiting for official systems: shadow IT.
Employees build spreadsheets, databases, scripts, and automations because the approved software does not match the work closely enough. These systems are often useful precisely because they are made near the problem. They can also become critical without anyone knowing who owns them, how they work, or what happens when their creator leaves.
Research on end-user computing controls has documented this tension for years. The same tools that give people flexibility can create operational risk when important systems grow outside normal review, documentation, access control, and maintenance.
AI expands the possible size of that unofficial layer.
The unofficial spreadsheet can now become an unofficial customer portal. A manually maintained list can become a database with authentication. A departmental workaround can become a public-facing service. The person creating it may experience the process as casually as building a spreadsheet, while the resulting system behaves much more like production software.
This is where disintermediation becomes useful as a frame. AI reduces the number of people who must be consulted before software can exist. It also moves responsibility toward people who may never have thought of themselves as software makers.
They gain the ability to act directly, along with decisions about reliability, maintenance, access, security, and trust.
Governance becomes the next intermediary
The likely response is another layer of intermediation.
Organizations will need ways to see what has been generated, what data it can access, who depends on it, and whether it should continue to exist. The future intermediary may be less involved in building each application and more involved in defining the environment in which applications are allowed to operate.
This has happened before.
Spreadsheets created freedom and eventually produced controls around financial models. Desktop publishing gave people direct access to layout and made design literacy more important. Websites allowed organizations to publish without traditional media and created new systems for hosting, search, analytics, moderation, and security.
Each transition removed one queue and created another set of responsibilities around the activity that had been opened up.
The same pattern may now be reaching software. The product team will no longer be the only place where applications are made. Its role may gradually shift from receiving every request to maintaining the conditions under which other people can build safely.
Design may become less concerned with controlling every interface and more concerned with how generated systems inherit rules, communicate uncertainty, and fit into the rest of an organization. Engineering may spend less time implementing every small workflow and more time creating reliable boundaries around data, identity, permissions, and deployment.
The new intermediary is governance.
It does not stand between a person and the first version of an application. It appears between that application and the wider organization.
Software begins before anyone calls it software
The most immediate effect of AI-generated software is that more people can make consequential systems without passing through the process that previously identified software as consequential.
A request used to signal that something had crossed a threshold. It needed a budget, an owner, a specification, and a place in a roadmap. Once software can be generated before any of those things exist, the threshold becomes harder to see.
This may be the real disintermediation.
The developer is still there. The platform is still there. The cloud provider, model company, database, and payment system are still there. What disappears is the organizational moment when a need becomes an acknowledged software project.
The software exists first.
The recognition that it matters comes later.
The distance between wanting a tool and having one is becoming much shorter. The distance between having a tool and understanding what it has introduced may remain exactly where it was.
AI authorship note
This essay developed from Kris Haamer's question about whether AI-generated software can be understood as disintermediation. AI supported historical research, synthesis, drafting, editing, and implementation. Kris directed the article away from familiar retail examples and toward the organizational queue, VisiCalc, desktop publishing, credit scoring, and shadow IT.