Join the discussion on LinkedIn
There is a peculiar optimism surrounding the current wave of AI-assisted software development. Give a developer a sufficiently capable language model, a vague description of a product, and a weekend, and the result might be a functioning application that would have required a small engineering team a few years ago. The enthusiasm is understandable. Software that once took months to develop can now be assembled in days, sometimes hours. Vibe coding has turned implementation into something approaching a conversation.
Yet, if you look closely at what is actually being built, a rather less revolutionary picture emerges. Much of the software produced through these methods is a reproduction of functionality that has existed for years, sometimes decades. Another project management application, another image editor, another CRM system, another clone of an established productivity tool. The code is new, the repository is new, and perhaps even the company is new. The underlying ideas are usually familiar.
ArtCraft is an interesting example of this phenomenon. Its approach reproduces functionality and interaction patterns familiar from established Adobe products, down to considerable similarities in the user interface. The motivation, as the project’s originator has acknowledged, is largely economic: achieving comparable functionality without having to pay for the established commercial software. There is nothing inherently wrong with that. Competition has always involved reproducing successful ideas, and software has never been immune to imitation. What makes this example interesting is the role AI plays in making such reproduction considerably cheaper. The technology has changed the economics of implementation, while the product concept itself remains largely inherited.
This raises a question that deserves more attention than it currently receives: how much of the apparent explosion in software innovation is actually innovation, and how much is simply the accelerated reproduction of existing solutions?
The distinction matters because software development has historically involved a substantial implementation cost. An idea could be relatively simple, yet turning it into a reliable product required architectural decisions, programming expertise, testing, integration, maintenance, and a considerable amount of time. These costs acted as a natural barrier. Many ideas that were technically feasible never became products because the effort required to implement them exceeded their expected commercial value. AI has started to remove that barrier. Consequently, we are seeing an increasing number of products that would previously have been economically unattractive to build. Their existence is evidence of a dramatic change in production economics, although it tells us surprisingly little about the rate at which genuinely new ideas are emerging.
The underlying mechanism is fairly straightforward. Large language models are trained on enormous collections of existing programming code, documentation, and other technical material. During training, they develop statistical representations of programming languages, architectural patterns, algorithms, and the relationships between them. When asked to implement something, they draw on these learned representations to generate code that is appropriate for the requested task. They can combine patterns, adapt implementations, and produce variations that were never explicitly present in their training material. This is an impressive capability, particularly when the model can use a compiler, execute tests, inspect errors, and iteratively improve its output. Nevertheless, the intellectual raw material remains overwhelmingly derived from human-created knowledge.
The result is a machine that can explore an enormous space of possible implementations at very low cost. It can produce a thousand variations of a familiar application, combine components from unrelated domains, and adapt established algorithms to unfamiliar requirements. Given a sufficiently precise problem description, it may even discover an implementation that its human operator would never have considered. Such results can be genuinely valuable, and the fact that the underlying concepts are established does not make their application insignificant. The invention of a new combination can itself represent a meaningful contribution.
Consider how engineering has progressed throughout history. Many important advances have emerged from applying an established principle in a field where it had previously been overlooked. The mathematics, physical effects, and materials involved may have been understood for generations, while their combination produces an entirely new capability. The same phenomenon occurs in software. An algorithm developed for one purpose may turn out to be exceptionally useful in another domain, particularly when AI makes the experimentation required to discover that connection inexpensive. There is considerable room for innovation in this process.
However, recombination has its limits. A system that can explore combinations of known concepts does not automatically understand which unexplored concepts might deserve to exist. It can be remarkably effective at navigating a space of possibilities that is defined by existing knowledge, yet the act of defining a fundamentally different space is a separate intellectual challenge. This is where the distinction between engineering and invention becomes particularly relevant.
The history of computing provides plenty of examples. The graphical user interface, relational databases, object-oriented programming, the spreadsheet, the web browser, and the smartphone were not simply cheaper implementations of existing products. Each introduced a different way of approaching a problem, changing the expectations of users and developers in the process. Their subsequent implementations were copied, refined, and commoditized, often with enormous commercial success. Yet the original conceptual leap happened before the market filled with competing implementations.
AI-assisted development is exceptionally well-positioned to accelerate this second phase. Once a new concept has been demonstrated, language models can help reproduce it, port it to different platforms, add missing features, and create competing products. The time between an initial implementation and the arrival of numerous alternatives may shrink dramatically. This could make the commercial life of an original software idea considerably shorter, while increasing the importance of whoever first identifies a meaningful new problem or interaction model.
There is an irony here. As the cost of implementation approaches zero, the value of deciding what should be implemented may increase. When everyone can build a competent application in a weekend, the ability to build one ceases to be a particularly strong competitive advantage. The difficult part becomes recognizing a problem that others have failed to notice, understanding why existing solutions are inadequate, and imagining an alternative that users did not previously know they needed.
This also changes the role of software architecture. When implementation is expensive, architects spend much of their time controlling complexity, establishing reusable structures, and ensuring that a system can be maintained over time. When AI can generate and modify large amounts of code at relatively little cost, the center of gravity moves towards the definition of systems, their constraints, their interfaces, and their intended behavior. The architect increasingly becomes responsible for establishing the conceptual framework within which implementation takes place. AI can generate the building materials and assemble them at extraordinary speed, but the quality of the resulting structure still depends heavily on the decisions that determine what is being built.
None of this should be interpreted as an argument that AI-assisted software development is unimportant. Quite the opposite. Making implementation dramatically cheaper is an economic and technological development of enormous significance. It will allow individuals and small teams to compete in markets that were previously inaccessible, enable niche applications that could never justify conventional development costs, and make experimentation considerably less risky. It may even lead to entirely new products through combinations that emerge unexpectedly during the development process.
However, we should be careful when interpreting the resulting activity as evidence of an unprecedented age of invention. A million new applications do not necessarily represent a million new ideas. They may simply represent a million cheaper ways of implementing ideas that were already there.
The real test of AI’s inventive capabilities will come when it starts consistently changing the questions we ask, rather than merely accelerating the answers to questions we already know how to formulate. Until then, much of what we are witnessing is an extraordinary industrialization of software production. The machines are getting better at building things. Whether they are getting better at inventing them remains a much more interesting question.