Developers now use language model–based tools for software development. These tools can write, refactor, and explain code. They come with clear and obvious advantages: development is faster, boilerplate disappears, and it is easier to get from idea to working code.

If that is true, it feels natural to expect that the amount and quality of software should have gone up. The tools and apps we use should have become better and more capable. We should see new tools in areas where we did not have any before. In general, there should simply be more good software.

But do we actually experience that?

When we look at the apps and tools we use every day, many of them feel much the same as a few years ago. Some have gained “smart” features and assistants. A few things are smoother or slightly more automated. But we do not see a clear wave of fundamentally better tools, or a flood of new kinds of software in areas that were previously untouched.

Something seems to block the translation from better development tools to noticeably better products. Part of the explanation is that writing code has never been the only hard part. Understanding users, deciding what to build, designing something simple enough to use, dealing with legacy systems and regulations — none of that disappears just because code is easier to generate.

Incentives also matter. Many companies optimize for engagement, lock-in, and short‑term metrics, not for maximum quality or radically better user experience. Extra development capacity can end up in internal projects, experiments, and incremental changes, instead of visible improvements to the tools we rely on.

This does not mean language models make no difference. For developers, a lot has changed: faster prototyping, easier learning, less time spent on repetitive tasks. There are also behind‑the‑scenes improvements in infrastructure and internal tools that users rarely see directly.

If we really used this new capability to its full potential, we might expect more obvious results: simpler and more reliable everyday apps, more tools for niche workflows and small professions, more software adapted to specific languages, regulations, and local needs.

The question “Where is the improved software?” is therefore less about the tools themselves and more about what we choose to build with them. The technical ability to create more good software is increasingly there. Whether we actually get that software depends on priorities, incentives, and the willingness to aim for genuinely better tools, not just more code.