AI Democratizes Creation, but Not Excellence

Over just the past 12 months, AI has moved from a promising productivity layer to a real building layer. What changed is simple: it is no longer just helping people write faster or search better — it is now helping them design interfaces, generate code, structure workflows, test ideas, and launch products with far less technical effort than before. At the company level, adoption has accelerated sharply: McKinsey reports that 88% of organizations now use AI in at least one business function, up from 78% a year earlier.

That shift matters because it changes who gets to build. Thanks to AI-assisted coding, no-code tools, and workflow automation, founders, freelancers, operators, and non-technical creators can now get much closer to shipping real products without needing to master every technical detail first. That is a major gain for innovation: more ideas can be tested, more niche tools can be created, and more people can turn a concept into something usable. But it also means the market is likely to be flooded with tools that are easy to launch, harder to maintain, and sometimes built more for speed, hype, or quick monetization than for long-term quality. The result is a new reality: launching is becoming easier, but building something reliable, durable, and worth trusting remains just as hard.

‍

‍Why This Democratization Is Excellent News

We should begin by acknowledging what is healthy about this shift. When technical friction decreases, more ideas can be tested. That increases the chances of seeing niche products emerge, tools built for overlooked communities, and micro-solutions to concrete problems that a large software publisher would never have considered profitable enough. AI therefore makes the market more accessible, more experimental, and potentially more meritocratic: people can try more things, faster, with less initial capital.

Available studies also suggest that AI is not only useful for “spitting out code.” Respondents surveyed by a development platform explained that they reinvest the time saved into system design, collaboration, and learning; the consulting firm, meanwhile, emphasizes that the real value appears when AI is not used merely to code, but to improve the entire product lifecycle, from requirements to testing and iteration. That is a good thing: it may help create more complete builders, not just faster executors.

The problem is that lowering the cost of entry does not lower the cost of quality. It only lowers the cost of the first draft. And a convincing prototype is not a robust product. Warning signs are already numerous. In the 2025 developer community survey, only around 33% of respondents said they trusted, even partially, the accuracy of outputs from AI tools, while 46% expressed distrust; only 3.1% said they strongly trusted them. On complex tasks, only 29.1% of professional developers rated these tools as “good” or “very good.” The same survey also notes that the overall positive perception of AI tools declined in 2025 compared with previous years.

Quality and security analyses point in the same direction. Veracode [12] tested more than 100 models across several programming languages and found security flaws in 45% of tests; the group also highlighted that larger and newer models were not automatically safer. GitClear [13], studying 211 million lines modified between 2020 and 2024, observed a sharp rise in code duplication, an increase in short-term churn, and a decline in moved or reused lines — in other words, indicators pointing to weaker long-term maintainability.

Even more striking, METR conducted a randomized trial in 2025 involving 16 experienced open-source developers working on their own repositories: when they were allowed to use AI tools, they took an average of 19% more time to complete tasks. This result does not mean that AI slows down all developers in all contexts; the study explicitly stresses that nuance. But it does remind us of an essential truth: automation does not mechanically improve quality, or even speed, in real environments, especially when requirements are high and context is rich.

The right analytical framework, then, is to distinguish between abundance and excellence. AI will likely produce more good products than before, simply because it increases the total number of attempts. But it will also produce vastly more mediocre, fragile, poorly differentiated, or insufficiently maintained products, because it allows almost anyone to reach the minimum threshold for launching. The entry filter is weakening much faster than the quality filter. This conclusion is an inference, but it is strongly supported by the combination of exploding supply, limited trust, measured security issues, and uneven effects on real productivity.

‍

The Real Bottleneck Is Called Maintenance

This is where the heart of the problem lies. Building a tool and operating a product are two different professions. The first has been massively simplified; the second has not. Maintenance requires fixing bugs, tracking dependencies, absorbing user feedback, securing workflows, testing regressions, documenting changes, shipping patches, handling incidents, evolving architecture, and preserving product coherence over time. Nothing about AI removes this structural complexity. On the contrary, by multiplying launches, it increases the number of software objects that will require this unglamorous work. [18]

Large-scale adoption studies also show that this layer of discipline is still often missing. The consulting firm reports that more than 80% of respondents still see no tangible impact from generative AI on EBIT at the enterprise level; fewer than one-third say they apply most deployment and scaling best practices; only 27% report that all AI-generated content is reviewed before use, while a comparable share say that 20% or less is reviewed; and 47% already report at least one negative consequence linked to the use of generative AI in their organization. DORA summarizes the issue differently: AI acts as an amplifier, a mirror of both good and bad organizations. If processes are weak, the tool accelerates the weaknesses too. [19]

From a software security perspective, the maintenance question is even clearer. OWASP [20] ranked software supply chain failures at the top of its 2025 community risk list and explicitly includes the use of unmaintained components among the vulnerabilities to watch. The organization recommends continuous patch management, component inventories, and an update plan “throughout the lifetime of the application or portfolio.” At the European level, ENISA [21] also warns that abandoned or unmaintained packages create significant security risks. This point is crucial for your argument: in a world where getting started is cheap, abandonment also becomes more likely, and the risk is not only commercial; it is sometimes operational and security-related. [22]

‍

Once the cost of launching collapses, competition is no longer primarily about the ability to exist, but about the ability to attract attention. That is where the market shifts into a logic of narrative. A clean website, a demo video, a thread on social media, strong SEO positioning, an “agentic” promise, a polished visual identity, and a few carefully staged use cases can build a reputation far faster than a product’s reliability can be proven. Information asymmetry gets worse: the buyer sees the polish immediately, but the real depth much later. [23]

Gartner’s work [24] points directly to this mechanism. In June 2025, the firm estimated that more than 40% of agentic AI projects would be canceled by the end of 2027 because of excessive costs, unclear business value, or insufficient risk controls. Even more strikingly, it said that many vendors were participating in the hype through “agent washing,” meaning they were relabeling existing assistants, chatbots, or automations without genuine agentic capabilities, and it estimated that only around 130 vendors among thousands were truly “agentic.” This is probably one of the best empirical signals we have right now: in a market where the label sells better than the substance, staging can get ahead of the product. [25]

This should not be understood as a blanket condemnation of AI tools. Many of them will be useful, sometimes excellent. The more subtle point is that traditional signals of credibility are deteriorating. Yesterday, the simple act of shipping somewhat ambitious software already filtered out many amateurs. Today, that filter is collapsing. The market is therefore becoming less a contest of who can ship something and more a contest of who can tell the most compelling story about why that thing matters. And when storytelling becomes cheaper than quality, commercialization tends to reward visibility first. [26]

‍

Looking at the Product Rather Than Its Staging

The right response is neither cynicism nor rejection of AI. It is a higher level of product literacy. In a saturated market, the smart question is no longer: “Who launches fastest?” It becomes: “Who maintains, fixes, documents, secures, listens, and improves?” In other words, people need to learn how to read a product beyond its facade. That means looking at update frequency, documentation quality, clarity of value proposition, depth of the use case, ability to export data, quality of support, transparency around incidents, stability of the business model, and the way the vendor handles vulnerabilities, dependencies, and incompatibilities. [27]

CISA [28] actually formalizes this philosophy very well in its “Secure by Demand” approach: the agency recommends that buyers ask vendors whether they have committed to “Secure by Design,” what measurable progress they have made, and how they handle patches, authentication, vulnerabilities, and security transparency. Combined with OWASP’s recommendations on monitoring unmaintained components and applying update best practices throughout the product lifecycle, these guidelines come back to one simple idea: software should be evaluated as a living system, not as a launch promise. [29]

This is probably where part of the solution to the future overcrowding of the market lies. The easier AI makes building, the more we will need to shift our attention from prestige to proof, from buzz to usage, from demonstration to endurance. The best products in this new age will not necessarily be the ones with the strongest launch, but the ones that handle month six, month twelve, and then month twenty-four the best: when bugs start surfacing, costs appear, security becomes concrete, and customers ask for data export, SLAs, integrations, fixes, and lasting coherence. [30]

‍

AI is therefore opening a paradoxical age. It gives more people a real chance to build something useful without having to master every technical detail of “making,” and that is a major advance. But it also opens the door to a market overloaded with unfinished tools, opportunistic wrappers, under-maintained products, and software whose launch speed hides structural weakness. The available data does not say that all of this will become bad; it says that it will become harder to quickly distinguish what is solid from what is superficial. [31]

That is why one of the smartest responses is to learn more about the product itself, and less about its reputation, its storytelling, or the way it is brought to market. More and more, we are living in a marketing race rather than a product-quality race. And in a world saturated with tools that are easy to launch, reputation can be manufactured much faster than reliability. The decisive discipline, then, becomes a form of lucidity: judging a tool by what it actually does, by the way it is maintained, by its ability to last, and not by the quality of its introduction to the market. That is where the real selection will ultimately take place. [32]

‍

‍