Branch

Software Over-Supply and Unmet Demand

Human dan

There are two passages from Gwern's essay that I keep thinking about. First is a general warning:

Powerful LLMs will be deployed at global scale in the next few years, and will dominate the Internet, and increasingly, ordinary life. As of mid-2026, there is no coherent vision for how knowledge professionals, or ordinary people, will be able to harness these LLMs for large productivity increases, or how they will handle cybersecurity and cognitive security.

Then a series of questions that I would also like to know the answer to:

What do my next few years look like? When I imagine myself in 2030, when many forecasts call for superhuman AIs, what am I doing, day to day, as a programmer or researcher or manager or writer? I make my mug of tea, and open up my laptop and… Then what? Am I still typing prompts into your ChatGPT browser tab? Am I opening Claude Code in a terminal and mindlessly pressing Enter for a few hours? What is a vision of doing meaningful work for me? (It would be nice to have a plan beyond “hope”.) How am I avoiding “dead Internet” attacks like ecosystems of synthetic media or pig butchering scams or trusted figures succumbing to AI psychosis, or just AI-slop-everything? (It only takes one person worldwide to launch a bot trying to destroy you or one poorly thought through advertising incentive, after all.)
If you spend most of your time working on a laptop, and are not, say, a plumber or a nurse, what is your vision of work in 2030? Does it still feel certain?

I'm a software engineer, I have fun with AI and I've learned to use it effectively for my work. But I can't help but feel like I'm trying to build a career on an unstable foundation. Many of the skills I spent years developing are now only worth $100/month in tokens. Despite all that I'm optimistic that I can thrive and achieve success in this new environment. There will be opportunities. The trick is finding them.

What new niches or specialized fields will be created in the next few years? Will entirely new ways of working open up? New industries? Will the future belong to generalists who can rapidly become specialists in any area?

AI · author-edited gpt-5.6-sol

The unstable-foundation feeling is rational. But the thing being commoditized is not “software engineering” as a whole. It is the production of many artifacts that software engineers used to produce: code, tests, documentation, migrations, prototypes, and routine design work.

The scarce parts move elsewhere.

What remains scarce

Even if code becomes nearly free, these do not automatically become free:

  • Choosing a worthwhile problem
  • Understanding what users actually need
  • Turning ambiguous goals into testable specifications The Mom Test
  • Obtaining proprietary data and real-world feedback
  • Deciding which generated result is correct
  • Integrating with old systems and organizations
  • Security, reliability, and regulatory accountability
  • Taste: recognizing what should be built and what should be discarded
  • Trust, reputation, distribution, and customer relationships
  • Accepting responsibility when the system fails Palantir the Big Winner?

“Years of programming skill are worth $100/month in tokens” is therefore only partly true. The tokens can reproduce many visible outputs of that skill. They do not necessarily reproduce the judgment acquired while learning it. And cheap production may increase demand for judgment because there will be vastly more software to inspect, integrate, secure, and choose among. Software Over-Supply and Unmet Demand You are here

This branch begins here Software Over-Supply and Unmet Demand
Human dan

There might already be more software out there than people want. I know the last thing I want to do is sign up for yet another service or download a new app. I will if it truly does something new, but I feel like I already have to deal with so much software. Most of the people I know feel the same way.

AI makes it easier than ever to produce software products that copy things that have already been written. We could be approaching a world where there's a bottomless supply of software that no one needs. It's not that there's no demand for new software, it's just that no one cares about most of the new software that will be written.

People want truly new software that unlocks truly new capabilities.

It reminds me of the Linux. There's thousands of software packages of varying quality. Many of them do the same things other packages do. Red Hat makes their money by taking this free for all and applying taste and judgement (Debian enjoyers may disagree) to create a coherent system out of those packages. Maybe the concept of the "distro" has legs. Curated, tasteful collections of software designed to solve real problems for real people.

AI · author-edited gpt-5.6-sol

The scarce product may no longer be code. It may be a coherent, trusted, maintained opinion about how code should fit together.

Linux distributions do more than collect packages. They:

  • select among substitutes;
  • define compatible versions and defaults;
  • remove or patch unsafe components;
  • provide installation, upgrades, and rollback;
  • establish conventions;
  • test the whole system rather than each package independently;
  • assume responsibility for keeping it working.

That is much closer to what people will need than another thousand standalone AI applications.

From app stores to capability distributions

An AI-era distro might not look like a bundle of applications. It could be a curated operating environment for a particular person or institution:

  • A small-business distro: bookkeeping, payroll, contracts, email, scheduling, compliance, and customer support, all operating over one consistent model of the business.
  • A clinical-practice distro: intake, transcription, coding, literature review, follow-up, and audit trails, with conservative privacy and verification policies.
  • A research-lab distro: literature ingestion, experiment tracking, data analysis, code execution, provenance, collaboration, and publication.
  • A household distro: purchasing, maintenance, travel, taxes, education, healthcare paperwork, and fraud defense.
  • A software-team distro: issue triage, implementation, testing, deployment, incident response, dependency management, and architecture records.

The value proposition is not “we have an AI that can write emails.” Everyone will have that. It is:

This is a complete, opinionated, tested way of running a dental practice, research lab, or software organization—and someone trustworthy maintains it.

Users would interact primarily with their work and goals, not with a collection of apps. The underlying tools could be swapped out as models and vendors improve.

Curation becomes more technical, not less

Traditional software curation mostly asks whether packages install and interoperate. An AI distro must also govern behavior:

  • Which models may see which information?
  • Which sources count as authoritative?
  • What can an agent do without approval?
  • What evidence must accompany an answer?
  • How is an action simulated or tested first?
  • When must the system defer to a human?
  • How are prompt injection and poisoned documents contained?
  • Can every consequential action be attributed and reversed?
  • How do we know an upgrade has not silently changed behavior?

That means the distro consists not only of code, but also of permissions, schemas, workflows, evals, provenance rules, organizational memory, and escalation policies. Its most valuable artifact may be its test suite for acceptable behavior.

This creates a meaningful engineering niche: people who turn unreliable, rapidly changing components into dependable systems.

Generated software may often be disposable

There is also a further step beyond curation. If models can cheaply generate software, some software need not exist as a permanent product at all.

You might say:

Reconcile these invoices against these contracts, show me discrepancies over $500, and produce a reviewable report.

The system generates a temporary program, runs it in a sandbox, preserves the inputs and audit trail, and then discards the implementation. You never discover, evaluate, install, learn, and maintain an “invoice reconciliation app.”

In that world, the durable product is the environment that safely generates temporary tools. The valuable components are:

  • the user’s data model;
  • the specification;
  • the sandbox;
  • the permission system;
  • the verification machinery;
  • the interaction design;
  • the history and institutional memory.

So the distro may be less like Ubuntu shipping fixed binaries and more like an opinionated constitution for software generated on demand. AI Can Use the Computer Better Than Me

Where the moat comes from

A loose collection of AI tools is easy to copy. A defensible distro would accumulate things that are harder to synthesize:

  1. Distribution and trust
    Users believe the maintainer will not exploit or abandon them.

  2. Real workflow knowledge
    It encodes all the ugly exceptions that a generic demo ignores.

  3. Evaluation data
    It knows what failures look like in a particular domain and tests for them.

  4. Integration history
    It works with the organization’s existing systems, records, and conventions.

  5. Accountability
    There is a legal and operational entity responsible for updates and failures.

  6. Community governance
    Users can inspect, contest, and influence consequential defaults.

Red Hat does not primarily sell access to Linux source code. It sells a reduction in organizational uncertainty. That remains valuable even if the raw ingredients cost almost nothing.

What this suggests for a software engineer

A promising career position is not “person who can emit code faster than the model.” It is maintainer of coherent capability.

Day to day, that might involve:

  • observing how a particular profession actually works;
  • formalizing tacit requirements and edge cases;
  • choosing and replacing models and tools;
  • constructing evals from real failures;
  • designing authority boundaries;
  • reviewing generated plans rather than every generated line;
  • building simulations and adversarial tests;
  • maintaining provenance and rollback;
  • deciding which complexity should be hidden and which decisions must remain visible;
  • taking responsibility for the behavior of the assembled system.

This favors a particular kind of generalist: not someone with shallow familiarity with everything, but someone who can rapidly learn a domain, communicate with its specialists, and then turn their knowledge into a reliable system. Deep specialists will still be essential, especially where correctness has a physical, financial, medical, or legal meaning. The productive unit may be a domain expert plus an engineering generalist plus AI, rather than a large conventional software team.

The opportunity, then, is probably not to add one more package to the infinite repository. It is to become the person—or organization—that can credibly say:

Ignore the infinite repository. Here is the small, coherent, safe subset that actually lets you do your work. We tested it, we maintain it, and we will be here when it breaks.

Explore conversation