On The Future of Software, Part 2: When Software Recedes

This essay is broken down into:

1. Foreword

2. Sona’s World

3. Part 1: The Old World — The Old World Market Equilibrium for Software

4. Part 2: The Shift — Five inflection points: ChatGPT, Vibe Coding and the AI IDE, When Models Learned to Think, When the Harness Met the Model, The Second Constraint Starts Breaking

5. Part 3: The New World — Four consequences: How We Build Software, What Software Survives, How Capital Reorganizes, The New Market Equilibrium

Foreword

In 2024, I fell deep down a rabbit hole with LLMs. I had spent a decade professionally as a product manager, but suddenly I was spending all my free time building software myself, reading about how these models worked, and dreaming about where they were going. There was a child-like giddiness to all of it — the most excited I had felt about technology in years. I worked myself into a fervor and channeled many of my thoughts into a doc titled The Future of Software.

In it, I explored how LLMs and natural language were collapsing the barrier to software creation. I imagined new tools for building, IDEs that welcomed entirely new types of builders that had previously never considered themselves technical. I was excited that more people would build, and I felt the world would be better off if more people realized their inner creator could live again.

Much of this speculation has come true in the last 2 years. There’s certainly an explosion of new builders, as vibe coding has gone from niche experimentation to a true phenomenon. Tools like Claude Code and Codex have put coding agents at the center of the building software, as AI writes most code now. The importance of design and human touch is growing but still undervalued, as we reckon with a world where anyone can ship software. The economics of software are visibly shifting as companies reckon with how to staff humans vs. AI, how to spend on models vs. headcount, and how to compete in a world where building is less and less a bottleneck.

I wrote the original version of this essay as a Part 2, in the first months of my daughter’s life while I was on paternity leave. Writing has always been how I orient myself, it’s a way for me to distill what I believe from first principles and drown out the noise.

Two years ago, I explored the question: “what happens when everyone can build software?” Now, I’m asking: “what happens if humans no longer have to operate most of it?”

Sona’s World

Her name is Sona. When she arrived into my world, she quickly reorganized my days. For the first time in my career, I was not behind a laptop or in meetings but instead shuffling between bottle feeds, naps, walks, small windows of writing, and the strange feeling of watching a new life arrive. My professional identity had always been defined by screens: docs, dashboards, Zoom meetings, Asana tickets, Figma canvases, Slack threads, spreadsheets, browsers. My entire economic productivity was defined by what I did working with people, across these systems.

But while on leave, and then after leaving Figma in June, I’ve gained a new lens to look at my own economic usefulness that comes from time spent behind a screen. Sure, there are necessary pockets of it but I could also clearly see how much of my former screen time was spent navigating the work instead of doing it. Opening the right tool, moving information from one place to another, updating a tracker so someone else could read it, finding a number from a dashboard — all of it was activity I never actually wanted to do but I accepted as the cost of being a PM.

Sometimes, I imagine the world in the future. I imagine Sona entering the workforce — let’s say around 2046, and picture how different things might be for her. I find myself sitting with a question that’s both professional and personal: will she spend the same amount of time behind screens, or worse, more? Will being economically productive still require the same tax of navigation on computers?

I hope not.

This essay explores a specific paradox: Sona may grow up surrounded by more software than I ever was, while spending far less of her life directly operating it. I’m not expecting software to disappear — in fact, I assume we will only have way more of it. But my hope is that the software that surrounds Sona may increasingly run beneath the surface, doing its work without requiring her presence to keep it moving.

I believe the future of software is bifurcated: the visible layer that requires human attention may shrink, while the invisible layer operated by agents grows.

The Old World Market Equilibrium for Software

For over 50 years, the business of building and selling software was built on an extraordinary asymmetry. You could take scarce and expensive human labor, coordinate it through a slow and messy process, turn it into code that became a product, and then sell that product at scale globally, with near-zero marginal cost. No other industry offered this spectacular ratio of input cost to output scale — we minted billionaires from the leverage of building once, serving millions, and generating revenue while humans sleep.

How is this asymmetry possible? Let’s start with the demand-side of the market first. There were two important factors for creating an extraordinary appetite for software.

The first was that the rise of the Internet and mobile devices broke the constraint of physical presence. For the first time in human history, you could build something and distribute it to anyone in the world at essentially no cost. This was a new capability that unlocked entirely new categories of human behavior and economic activity. These were categories that never existed before because geographic distance and physical friction made it impossible. Marketplaces to connect buyers and sellers that would have never found each other. Social networks and communication apps to let people maintain relationships across the world. Productivity tools to let small teams compete with large institutions. The demand for software was demand for things that could physically not exist before.

The second was the migration of human attention in a zero-sum environment. As more of human life moved online – people spending more of their working hours, social hours, and leisure hours on screens – the economic value of capturing that human attention compounded. Every new behavior that migrated online created a new surface area for software. Checking email inboxes replaced going to your mailbox every morning. Google searches replaced buying encyclopedias and Yellowbook. Scrolling feeds and sending DMs replaced local newspapers and watercooler conversations. Setting an Uber pickup replaced making phone calls to taxi dispatchers. Each of these transitions was a massive business opportunity where those that moved fastest to serve each transition accumulated users, data, and network effects that entrenched them further. In other words, human attention as a scarce resource was moving online.

Against this backdrop of human demand, the supply-side had a specific structure that shaped how software businesses were built. The input was human labor – which was expensive, specialized, scarce, and slow. Building great software required assembling teams that spanned specialist roles like frontend engineers, backend engineers, UX designers, product managers, data scientists, and user researchers. To become proficient in each discipline, it required not just an education in the foundation but also practical experience and intuition from the real-world. So each specialist commanded significant compensation for the niche skill set they had developed. When the final team is assembled, building software itself is a coordinated and messily beautiful process that itself consumes more time and energy.

Here lies the asymmetry that made the business of building software extraordinary:

• The input was human labor, which is constrained in all the ways that human labor is always constrained: expensive, slow, finite, in need of coordination + management + sleep

• And the output was code, one of the most valuable types of leverage. It is permission-less and has zero marginal cost of replication.

It was possible to absorb the expensive, human-constrained input cost upfront and then unlock a basically infinite, scalable, zero-marginal cost output on the other side.

This asymmetric upside created winner-take-most dynamics. Once a software company reached certain scale, the economics would compound in their favor with multiple flywheels:

• More users meant more user data

• More user data meant better products

• Better products meant more users

• More users meant more brand recognition

• More brand recognition meant more negotiating power

• More negotiation power meant stronger distribution advantages

• Stronger distribution advantage meant more users

• More users again meant higher switching costs

• …and so on

Scale itself became a particular type of moat, layered on top of whatever technical or product advantages a company had built.

These were the ideal risk conditions for venture capital. The structure of opportunity in building software matched the structure of investment, because several market conditions converged simultaneously:

• High upfront cost: assembling and maintaining specialized human teams over the months/years required to build something worth using was expensive. Salaries, benefits, office space, tooling – all contributed to a high burn rate which was sustained until the single dollar of revenue materialized.

• Long time to payoff: software products don’t generate meaningful revenue immediately. Finding PMF takes time and scaling to meaningful revenue takes longer.

• High failure rate: many software products fail regardless of how well they are built. The odds of any individual bet paying off were low, so investors needed the winners to return enough to cover the losers many times over.

• Asymmetric upside: the companies that do find PMF and scale could end up returning the entire fund. No other asset class offers this combination of failure rate and upside magnitude.

• Winner-take-most: Scale compounds in the leader’s favor. Early bets on the right companies created sustained value that widened the gap between market leaders and challengers.

In the old world, the zero marginal cost of software distribution provided the return on the capital if the bet paid off. This capital structure was an elegant system.

Specialization made sense because the coordination tax across people was worth paying. Even if it was expensive and slow to assemble a team of specialists, it was necessary and productive to run them through a multi-phase development process. The alternative – generalists doing everything – would have produced worse outcomes, because the domain knowledge for each function was genuinely deep and non-overlapping. You could not expect one person to be great at a range of market strategy, visual design, distributed systems architecture, and statistical experimentation. So you hired specialists, paid the coordination overhead, and relied on some semblance of a process to keep everything aligned. The cost was real but the output was worth it.

I call this the old world market equilibrium. The demand for software was growing faster than the supply of people who could build it. This kept the value of specialized talent high, while the zero marginal cost of replication kept margins extraordinary for companies that achieved scale.

Part 2: The Shift

In March 2025, I vividly remember having a conversation with a senior engineering manager at Figma that I was working with. He had 15+ years of experience at the industry’s best tech companies and was one of the smartest technical minds at our company. I told him how bullish I was about LLMs writing code and how much more capable the models would later get.

He didn’t buy it. He didn’t believe AI could write real, production code. He didn’t have a specific technical counterpoint, he just had a gut feeling that it couldn’t be possible. But by the end of 2025, his position had reversed completely. He wasn’t the only one who was now a believer, the entire company was all in on Cursor, Claude Code, Codex – and so was most of the tech industry.

What changed? How could we swing from utter disbelief to all-in conviction in a matter of months? I want to trace the progress of AI for coding / software engineering through four inflection points: ChatGPT, vibe coding + the AI IDE, reasoning models, and what I’m calling the Claude Code moment. When you look at these four moments together, you can see why skeptics became believers and also how the ground is shifting.

Inflection Point #1: ChatGPT (Late 2022 - Early 2023)

On November 30, 2022, OpenAI released ChatGPT as a free research preview to the public. One million users signed up in the first 5 days. One hundred million users signed up within two months, making it the fastest-growing consumer application in history.

To understand why, it helps to ground ourselves in what ChatGPT actually was under the hood. It was built on GPT-3.5, an LLM trained on a massive corpus of Internet text using unsupervised pretraining. The model learned to predict the next token in a sequence, across hundreds of billions of examples, until it developed a rich internal representation of language and knowledge. But the model was also coupled with posttraining techniques like Reinforcement Learning from Human Feedback (RLHF). This enabled the model to not just predict the next token, but to follow human instructions and produce outputs that humans actually prefer. ChatGPT was a product that had the knowledge from pretraining and the steering from posttraining to be helpful in response to what a person was actually asking for. You could have a conversation about pretty much anything.

For software builders, the immediate implication was further democratizing access to specialized knowledge that had required years of experience. GPT-3.5 had been trained on text corpus that included code, documentation, Stack Overflow threads, public GitHub repositories, engineering blogs, and technical discussions. Though the model had not yet been explicitly taught programming, it absorbed the language that programmers used to talk about programming and so it developed software engineering fluency.

If you were a junior engineer, you could ask ChatGPT to explain a concept that would have taken hours of reading documentation or Stack Overflow threads to piece together. A non-technical founder could ask for a web app scaffolding. A PM like me could ask for help debugging a script. The knowledge moat that had made engineering expertise so scarce was starting to show cracks.

This was the first signal that something fundamental was changing about the relationship between human expertise and software creation.

Inflection Point #2: Vibe Coding / AI IDEs (Mid 2024 - Early 2025)

In the months after ChatGPT, there was progress on multiple fronts. GPT-4 arrived in March 2023 and contained a real capability jump – it passed the bar exam in the top 10% of test takers, compared to scoring in the bottom 10% with GPT-3.5. This jump gave developers a model that was reliable enough to use seriously inside a professional workflow for the first time. GitHub Copilot had been on the market since 2021 (powered by OpenAI’s original Codex model) but it was starting to feel like a real tool with features like auto-complete for writing code. Cursor had launched in 2023 as an AI-native fork of VS code, also embedding model assistance directly into the coding environment. Windsurf followed shortly after in 2024, and an entire category of AI IDEs was born.

These tools were effective but had real limitations. The original Codex model that powered the first wave of GitHub Copilot had been trained on 54 million public GitHub repositories, ~180 gb of Python code collected in 2020. This was a good starting point for language models to learn code representations: absorbing common patterns, standard libraries, developer idioms, and different programming languages. The models were best at auto-complete: predicting the next line, completing a function, or suggesting a common pattern.

But this knowledge skewed heavily towards the input training data – public GitHub repositories were finished, polished, and publicly shared code. They underrepresented the messy, in-progress, context-dependent code that looks closer to the real codebases inside companies. These public repositories also overrepresented certain languages, frameworks, and styles of software. A model trained on this corpus learned to write code that looked like open source code, but struggled with novel architectures, proprietary systems, or long-horizon reasoning that real production software engineering required.

On the consumer side, there was a more novel breakthrough that gave rise to a new class of non-technical builders: vibe coding. A new class of tools like Bolt (October 2024) and Lovable (November 2024) hit the market and promised the ability for anyone to build software applications. The premise was tantalizingly simple: describe what you want in English, and the tool would generate a working application. This was even more powerful than an IDE to this category of builders who had never been in IDEs and didn’t consider themselves technical before AI.

This was possible because of how these tools constrained the scaffolding for basic app development. They would default to a standard stack: React components, Tailwind CSS for styling, Supabase for the backend. This worked well with what the frontier models were most familiar with from open-source GitHub repos. For example, Tailwind was a utility-first CSS framework popularly used in the open-source community. Given the model’s internal representation of Tailwind and the framework’s modular, composable styling primitives – the models could then remix and use the primitives to produce visually coherent frontends from a simple language prompt.

This category took off with strong PMF as Bolt had $40M in ARR within 6 months of launch, and Lovable reaching $100M in ARR within 8 months. There was enormous latent demand from people who had the ideas but lacked technical skills to build them. Karpathy coined the vibe coding craze officially in February 2025: programming by feeling, accepting AI suggestions without reading the diffs, copying error messages back to the AI until it works.

But when I look back at this moment, the tools seemed impressive but were within a constrained range and quite brittle outside of it. Applications being built were mostly front-end heavy, greenfield projects. Models would lose context and coherence on larger codebases, even around 150-200 components. At its core, tools like Bolt and Lovable were generating recognizable variations of apps that already existed in the training data – reskinned with patterns the model had seen thousands of times.

AI IDEs told a similar story from the developer side. Cursor had built a genuinely devoted user base among professional developers for code review, debugging, explaining unfamiliar parts of the codebase, and generating boilerplate code. It was growing fast not just in the consumer segment but especially in organizations/enterprise. But the models were not good enough to be a real collaborator on well-scoped, well-specified tasks. There were glimpses of more agentic workflows but the tools could not run autonomously yet. AI IDEs provided good assistance in the early days, and the result was speeding up human development.

Inflection Point #3: When Models Learned to Think (Late 2024 - Early 2025)

The best number to pay attention to for this inflection point is SWE-bench: “a benchmark to evaluate LLMs’ abilities to solve real-world software issues sourced from GitHub.

• In 2023, the best LLMs could solve 4.4% of issues on SWE-bench

• In August 2024, OpenAI launched SWE-bench Verified, a more carefully curated version of the benchmark, and the top models had reached 33%.

• By the end of 2024, they were consistently above 70%.

• By late 2025, Claude Opus 4.5 broke 80%.

• And by March 2026, the latest frontier models from Anthropic, Google, and OpenAI were all competing in the +80% range.

So we went from 4% to 80% in roughly 2 years. How did this large of a capability jump happen? There are too many variables to isolate cleanly, but I’m going to focus on 3 specific technical breakthroughs that compounded together.

The first was leveraging RL techniques for verifying good code output in model posttraining. There was Reinforcement Learning with Human Feedback (RLHF) but even more importantly, Reinforcement Learning with Verifiable Rewards (RLVR). Code is a rare form of human output where correctness can be verified automatically and objectively. This is ideal for a training environment where labs can train models using the execution environment itself as the reward signal. The model generates a candidate solution, runs it against test cases, and receives near-instant ground truth feedback about whether or not it worked. Over many iterations, the model can learn from optimizing for this reward function on which strategies for approaching coding problems work well. This intuition can come close to mimicking how experienced developers reason through different approaches through trial and error.

But even before RL could work here, models needed a competent baseline to start from. Models were pretrained on the GitHub training corpus described in the previous inflection point, and also from high-quality human annotated coding datasets. For post training, companies like Surge AI and Scale AI provide carefully curated coding tasks to frontier labs. Surge AI alone generated $1.2B in revenue in 2024 by serving roughly 12 frontier lab clients. So the human data labeling infrastructure worked hand-in-hand with RL. As models got better through RL, labs demanded better supervised fine-tuning data to push the capability floor higher and providers like Surge and Scale continued scaling their expert annotation workforces to meet that demand.

The second breakthrough was chain-of-thought reasoning. OpenAI released o1 in September 2024 which was the first time we saw the benefits of RL expressed in practice. Before o1, models were generating their outputs in a single forward pass. Whatever they produced first was the answer given back to the user. o1 introduced a paradigm where the model would generate an internal chain of thought as intermediate reasoning steps, before producing its final output. The chain of thought itself is trained via RL (each intermediate step can also be optimized towards a reward function). And this thinking time at inference produced better answers since the model could recognize when it had gone down the wrong path, to back up and try something else. Models gained the ability to audit themselves.

The third breakthrough was relaxing limitations on the context window. To understand why this mattered for coding in particular, we need a precise technical definition of what a context window is. A context window is the amount of text a model can hold in its working memory at once, measured in tokens (you can think of ~750 words as equal to 1,000 tokens). GPT 3-5 had a context window of 4,096 tokens which was good enough at the time. But it was completely inadequate for anything resembling real software development. This would require having dozens of code files, thousands of lines of code, the full history of a session – all in context.

The progression of context window lengths tracks almost directly with the progression of model capabilities. GPT-4 in 2023 extended its limit to 32K-128K tokens. Claude 3 in 2024 reached 200K tokens. GPT-4.1 in April 2025 reached 1 million tokens (equivalent to more than 8 copies of the entire React codebase). So the bottleneck was relieved but models still needed to use the context reliably. Early on, models suffered from context decay or lost-in-the-middle effect where models attended strongly to information at the beginning and end of context, but dropped in accuracy for information buried in the middle. These problems required innovation in algorithms like flash attention and rotary position embeddings.

These 3 breakthroughs: scaled RL for coding data sets, chain-of-thought reasoning, and long-context horizon cohesion all improved coding models ability to solve real-world coding problems. A model could remember what it had tried, what failed, what it learned from those failures, what files it has read, and what the overall architecture looked like.

Inflection Point #4: When the Harness Met the Model (Late 2025 - Early 2026)

On Feb 26, 2026, Karpathy wrote:

“It is hard to communicate how much programming has changed due to AI in the last 2 months: not gradually and over time in the “progress as usual” way, but specifically this last December. There are a number of asterisks but imo coding agents basically didn’t work before December and basically work since - the models have significantly higher quality, long-term coherence and tenacity and they can power through large and long tasks, well past enough that it is extremely disruptive to the default programming workflow.

Just to give an example, over the weekend I was building a local video analysis dashboard for the cameras of my home so I wrote: “Here is the local IP and username/password of my DGX Spark. Log in, set up ssh keys, set up vLLM, download and bench Qwen3-VL, set up a server endpoint to inference videos, a basic web ui dashboard, test everything, set it up with systemd, record memory notes for yourself and write up a markdown report for me”. The agent went off for ~30 minutes, ran into multiple issues, researched solutions online, resolved them one by one, wrote the code, tested it, debugged it, set up the services, and came back with the report and it was just done. I didn’t touch anything. All of this could easily have been a weekend project just 3 months ago but today it’s something you kick off and forget about for 30 minutes.

As a result, programming is becoming unrecognizable. You’re not typing computer code into an editor like the way things were since computers were invented, that era is over. You’re spinning up AI agents, giving them tasks *in English* and managing and reviewing their work in parallel. The biggest prize is in figuring out how you can keep ascending the layers of abstraction to set up long-running orchestrator Claws with all of the right tools, memory and instructions that productively manage multiple parallel Code instances for you. The leverage achievable via top tier “agentic engineering” feels very high right now.

It’s not perfect, it needs high-level direction, judgement, taste, oversight, iteration and hints and ideas. It works a lot better in some scenarios than others (e.g. especially for tasks that are well-specified and where you can verify/test functionality). The key is to build intuition to decompose the task just right to hand off the parts that work and help out around the edges. But imo, this is nowhere near “business as usual” time in software.”

What exactly changed by the end of 2025? Models seemed to have crossed a threshold of coherence – powering through large complex tasks without losing the thread. If you trace back coding agents in 2023 and 2024, they were elaborate scaffolding systems. The industry was investing in levers like prompt engineering to establish context, explicit orchestration of tool calls to navigate the codebase, human-in-the-loop to course correct when the model drifted, and restarts when the context window overflowed. The agent harness compensated for the model’s limitations.

What changed in late 2025 was that the models became capable enough to run on its own, and the harness could just get out of the way. I call this the Claude Code moment. Even though this terminal-native coding agent launched as a research preview in February 2025, it didn’t take off until the end of 2025. The reason is the harness needed to benefit from a more capable model in Opus 4.5. Boris Cherny described Claude Code’s approach in an interview with The Pragmatic Engineer:

“When you look at coding products, they get in the way of the model – they add scaffolding by adding UI elements and other parts that clutter things, so that the model running in those tools feels like it’s hobbling on one foot. We try to make the UI as minimal as possible. Every time there’s a new model release, we delete a bunch of code. With the 4.0 models, we deleted around half the system prompt because we no longer needed it.”

Claude Code ships with a small set of primitive tools like the ability to read files, write files, and run bash commands. So when you give it a task in plain English and point it at a codebase, the model determines which files to read, what changes to make, which tests to run, how to interpret failures, and what to fix next – working through the problem the way a developer would rather than following a prespecified set of steps.

OpenAI’s Codex launched in April 2025 and took the same insight in a different direction. Codex is cloud-based, so each task runs in an isolated sandbox preloaded with your repository and agents can work on multiple tasks in parallel while you step away. It is powered by OpenAI’s Codex models – specifically optimized for software engineering via RL on real-world coding tasks. Codex can write features, fix bugs, run tests, and propose PRs for reviews. The workflow shift in this inflection point transitions from pairing with an AI assistant in real-time to assigning tasks and walking away to come back and review outputs. The human’s role switches from active participant to reviewer.

Cursor reported that 35% of its internal PRs were being created autonomously by agents. At Anthropic, engineers reported that 100% of their contributions to Claude Code were written by Claude Code itself. OpenAI described something similar as eng teams used Codex to offload repetitive but focus-breaking tasks so that they could concrete on higher-order architectural decisions. On the commercial side, Anthropic’s run rate crossed over $30B by April 2026 – up from approximately $9B by the end of 2025. The number of business customers spending over $1M annually doubled from 500 to 1,000+ in less than 2 months.

In the previous inflection points, AI made building software faster. In this one, it changed what building software looks like. The developer is no longer the primary writer of code. Instead, they are part-decomposer of problems, part-reviewer of outputs, part-orchestrator of agents.

All the preceding inflection points still continue to compound. Models keep getting better, context windows keep expanding, labs keep investing in scaling RL. But this inflection point added the product layer that lets model capabilities express themselves at scale – a harness simple enough to get out of the model’s way.

Inflection Point #5: The Second Constraint Starts Breaking (Early - Mid 2026)

When I originally wrote this essay, I stopped with four inflection points that tell the story of loosing the constraint on who can build software. But in the last few months, the industry has marched forward on relaxing another constraint for who has to operate software.

AI can increasingly use computers and the software we’ve built: the tools, systems, and interfaces that humans currently navigate themselves. We now have browser use agents, computer use agents, MCP connectors, workspace integrations and more. When the building abstraction moved from code to natural language to intent, the operating abstraction is moving from clicks to workflows to intent.

As of August 2026, we’re seeing the most concrete evidence of this. xAI launched GrokBot on August 11, which provides persistent AI teammates with their own computer that sign into tools you already use, can work across your apps and inboxes, and can finish work for you end to end. Each bot runs on a persistent cloud VM with a browser, file system, terminal and connectors to external services. These bots can work without clean APIs, even if a website doesn’t have one — using the browser and login, just as a human would.

In the same month, a startup called Instinct blew up online by offering consumers a personal AI agent you can text. It connects to your email messaging apps, calendar, and so on. Users were reporting booking flights, making restaurant reservations, buying groceries, canceling subscriptions and finding use cases where the agents could transact and complete tasks on their behalf. The company already raised $350M at a $2.5B valuation, co-led by Index and Benchmark.

Both these products represent a transition that is under way from the chat era of AI into the agentic era, where the competence of AI is increasingly measured by its ability to use software on your behalf. Whereas the old relationship required humans operating every intermediate step — this new relationship requires only the intention while the agents handle the rest.

Part 3: The New World

Given these inflection points across models and the harnesses wrapping them, let’s imagine the trajectory we are on leading to a new world of building and using software. What happens to the people, the processes, the businesses and the economic structures that were built around a world where writing code and building software was hard and expensive, and humans had to use software?

I offer a specific order of consequences below with a long-term thesis: AI models increasingly capable of performing human-level knowledge work will displace the human labor doing that work today, cascading into a new market equilibrium where humans spend less time online navigating software and more time in the chosen layer — entertainment, connection, creativity, recreation, and specialized expert tools, and more time using software through agents. These categories of software that demand true human attention will be even more valuable because those eyeballs are scarcer than before.

First-Order Consequence: How We Build Software Changes

Core Belief: The process of building software accelerates, the specialist functions that organized it evolve into new kinds of specialized, higher-level builders, and a Cambrian explosion of software follows as the barrier to building collapses

Why Convergence Is Now Possible

The convergence path — a single person moving across product definition, design, engineering, data, and research — has always existed in theory. However, it rarely existed in practice because each discipline had a steep enough learning curve and a specialized enough toolset that made crossing between them difficult. You could not reasonably expect a PM to design in Figma, write production code, and pull SQL queries. Even if it were intellectually possible, the tools themselves were built for domain experts that required years of depth and experience to use effectively.

A useful parallel to examine is in the shift from film to digital photography in the late 1990s. When digital cameras arrived and lowered the technical floor for photography, two things happened simultaneously. First, the convergence path allowed anyone with a camera to take photos instead of requiring deep specialization to develop film. Second, the depth path also sharpened as photographers with good visual judgment, compositional mastery, and storytelling ability became more valuable.

These two paths – convergence and depth – work towards dropping the floor and raising the ceiling. This dynamic is playing out in software building. The builders of these tools are being actively redesigned to accommodate a broader audience. Specialist tools are historically built for a narrow audience of trained professionals which lowers their growth ceiling in a world where the number of trained builders is the bottleneck. As more people want to build, these tools have to widen their TAM or cede ground to new tools that do. The companies building specialist tools are being forced, by the logic of their own revenue growth, to make their tools more accessible to a broader audience. Coding tools are being built for people who have never written a line of code. Data tools are being rebuilt around natural language rather than SQL. Design / prototype tools are being built for people who have never been in Figma. Research tools are being built to conduct and synthesize interviews without a trained researcher in the loop.

This dynamic ends up creating a flywheel. On the demand side, builders want to move across disciplines without the switching costs of learning an entirely new craft. This desire drives adoption of these newly accessible tools. And on the supply side, tool companies drive investment in making these tools more approachable to drive revenue growth.

Against this backdrop, each person working in a specialist building role must decide one of the two paths. These are not mutually exclusive, the most capable specialists will pursue both simultaneously and raise their level of ambition significantly.

On the convergence path: agents absorb the execution layer of each current specialist function as the tools become accessible enough for non-specialists to use. The hard boundaries between disciplines soften and a single person emerges as directing agents across product, design, engineering, data, and research. This is more economically viable for businesses rather than hiring a team of 5 specialist humans. The builder who follows this path becomes a new AI builder: holding the full build cycle, directing agents across all of it, developing judgment across domains rather than depth in one. This path favors people with low switching costs between disciplines, which is why PMs are the most naturally positioned to walk it first. But it is available to anyone willing to develop breadth.

On the depth path, the power law applies. The specialist who uses AI to push the ceiling of their domain higher — the designer whose taste is genuinely irreplaceable, the engineer whose architectural judgment separates good systems from fragile ones, the researcher whose ability to hear what isn’t being said cannot be automated — becomes more valuable and more rare to find. The median specialist is absorbed by agents, while the top gets amplified. Choosing this path requires genuine excellence, not just competence.

Both paths are real and viable. The most compelling people in the next era of software will be those who have gone deep enough in at least one domain to have genuine judgment, and broad enough across the others to direct agents across the full build cycle.

How the Software Development Lifecycle Changes

Discovery accelerates as agents can run user interviews, synthesize qualitative feedback across hundreds of sessions, pull and analyze behavioral data, and generate competitive intelligence simultaneously. The truth-seeking loop that previously ran on a timeline of weeks compresses to within days. The PM’s job in this phase shifts from orchestrating a process to evaluating the output and knowing which questions to ask next.

The exploration stage of the option space will accelerate, as agents can produce dozens of directions at the same time. It is still up to a human to decide which direction is right and why. This decision should not be given to an agent. This now includes more visual exploration with rapid prototyping or functional, working products to get a feel for the product experience.

The handoff between design and engineering compresses or disappears entirely in certain products. The translation layer between design and code has a minimal diff which makes the collaboration between design and engineering more important in the previous phase than in traditional handoff.

Development becomes continuous and agent-driven. Agents translate intent into writing code, running tests, interpreting failures, and iterating without waiting for a human to review each step. The Cognition team’s documentation of what teams are already doing with agents — auto-triaging production errors before on-call engineers open their phones, running smoke tests daily, reproducing customer bugs from Slack messages, running parallel migrations across eight or more simultaneous sessions — describes a development process that is continuous, parallel, and largely autonomous at the execution layer.

Testing and monitoring merge as the distinction softens when agents can run across both continuously. Agents can catch regressions before they reach production and they can surface anomalies in real time. The feedback loop between what was built and what users actually do will tighten.

Overall, the SDLC transforms from a relay race into a continuous loop. The whole process is still oriented towards developing the clearest possible picture of a problem worth solving and a solution worth building. The main change is how many people are holding the compass and how fast they can move.

Next, let’s look at how each role evolves.

Product Management

There is a common view that PMs become more valuable in the age of AI because they are generalists, and AI gives generalists more leverage. I believe this is true but imprecise. The formal responsibilities like defining what to build, prioritization, assembling roadmaps, synthesizing signals from users and data are the visible parts of the job. But there is also the unglamorous work of coordination between people who view the world differently. Human communication is lossy in a way that agent communication simply is not. Every handoff between two people introduces friction, misalignment, and delay.

Agents absorb the execution layer of each specialist function, including a significant portion of the coordination tax for PMs. Previously, a PM may spend 3 days getting a data scientist to pull an analysis together, a designer to mock up a direction, and an engineer to scope the feasibility of a feature. Now, a PM can direct agents to do all 3 simultaneously. The time that they’ve freed up from coordination can now be reallocated.

There are 2 directional options for this reallocation. The first is downward, into actual specialist work. More PMs can spend their time doing tangible work like designing mockups, conducting user interviews, making dashboards, writing and deploying code. The best PMs today were already operating in this empowered way although it was the exception, not the norm. Tomorrow, it becomes the expectation and it becomes possible because AI creates an abstraction layer that makes each specialist discipline approachable without requiring years of depth. Voice agents on a Figma canvas to design. Natural language in AI-first coding tools to build and deploy. Natural language SQL queries to look at data. Agentic UX research interviewers to conduct and synthesize user interviews. All these tools already exist or are in the works.

The second option is upward: to direct their energy into the strategic, human, judgment-heavy work that agents genuinely cannot do. This involves things like cross-functional alignment at the leadership level, stakeholder management that requires reading the room, understanding organizational politics, company strategy and messy context that lives in people’s heads. This work becomes more important for a human to absorb as agents handle more of the operational layer.

The economic argument for this reallocation is that companies will find it increasingly difficult to pay for 5 specialists when a PM directing agents delivers comparable output at a fraction of the cost and time. This is an uncomfortable value proposition for existing specialists. But if you were a startup founder today, who would be the most economically compelling hire you’d want to make if you already had an existing baseline of domain specialists?

This person may not be a traditional “PM” and maybe the title itself will feel like a legacy label. Karpathy described this role as a director, an orchestrator, someone who decomposes problems, assigns work to agents, evaluates outputs with genuine expertise across multiple domains, and drives them towards outcomes. What’s clear is that the best PMs of today who were already doing a bit of everything – combining generalist instinct with specialist depth in at least one domain – are the template for what the role becomes. The anomaly becomes the standard.

To be clear, there will still be a need for domain specialists in each function as AI pushes the ceiling of each domain. But that is the top of each function. The broad middle gets absorbed, first into agents and then into the expanded scope of this PM-turned-AI builder who directs them.

Design

Design is the function that most clearly illustrates the power law dynamic at work. While AI has fundamentally disrupted coding as a strictly verifiable domain (it either works or it doesn’t), design does not have that feedback loop. Design is a visual modality: pixels, vectors, spatial relationships, typographic hierarchy, color theory, the way negative space communicates weight and intention. The question of whether design output is good is not strictly verifiable because there is inherent subjectivity. The judgment of whether something earns human trust and delight cannot be reduced to a test suite.

The design industry has spent decades trying to encode good design – through design systems, brand guidelines, principles of craft, annotated examples of what separates adequate from excellent. There is far too much context, far too much tacit knowledge, far too much situational judgment embedded in what great designers actually do for a model to have learned it the way coding models learned to reason about syntax and architecture. Having spent the last year working directly on Figma Make, trying to close exactly this gap, I am not convinced we are anywhere near replicating what skilled human designers do. What the models are good at is remixing reusable primitives — assembling components from design systems, generating variations on familiar patterns, producing outputs that are visually adequate. What they are not yet good at is genuine creative judgment: knowing when to break the pattern, understanding the emotional register a specific user in a specific context needs, holding the tension between what looks right and what communicates right.

This means the execution layer of design is not yet as agent-able as the execution layer of coding. So we should expect to see a re-pricing on the value of design in this order of consequence. There is a near-term market correction where designers are being pushed to move faster, get closer to production, learn to write code, deliver working prototypes, and so on. This is a healthy correction because the previous design process could often be interpreted as too slow or disconnected from the reality of what engineering could deliver.

But this correction should not be mistaken as a replacement for the process. The design process has always had two distinct phases that require fundamentally different tools and different cognitive modes. The first is exploratory: going wide, generating a large option space, wandering through possibilities before committing to a direction. This phase requires something like a canvas, rich expressiveness, the ability to be creative and rapidly sketch and compare directions without being bound to a declared representation like code. The second phase is precise: going deep in a chosen direction, pixel-level manipulation, the kind of exacting craft that separates a design from one that functions to one that also communicates. Code is not well suited for either. The feedback loop between intention and output in a code editor is too indirect for the kind of fine-grained visual control that both phases require.

The market correction today is compressing both phases in the name of speed. The result is software that moves faster to production and also increasingly looks the same – there’s a homogenization of digital experiences that results from everyone using the same AI-generated design primitives assembled into the same familiar patterns. This might be good enough for most software experiences. But as software that demands human attention becomes scarcer and more valuable (as the fourth-order consequence predicts) – good enough won’t be sufficient.

This is where a second market correction is required. The same force that currently depresses the market value of design will eventually reverse it. Software that earns genuine human attention must be crafted by people who understand the art of design, not just the science or speed. The highly specialized designer who has developed genuine taste, understands both the exploratory and precise phase of the process and can navigate between them, has the judgment to know when a model’s output is adequate vs. not – this person becomes more valuable than before.

The irony is that design – the specialist function most associated with human creativity and taste – may end up being the most durable of the traditional specialist functions in the face of AI, for the same reason it is currently being undervalued: what it does at its best is genuinely hard to automate.

Engineering

The inflection points from part 2 were focused on disruption to software engineering. Reasoning models, RLVR, context window expansion, the harness meeting the model – they all are fundamentally about AI learning how to write code. It is by now obvious that engineering is the function that is more directly threatened by the transition. But let’s look at what type of engineering work doesn’t get absorbed by agents and instead becomes what today’s engineers must evolve into.

There are two distinct categories of work that I’ll outline. The first is architectural, systems-level thinking. This is where an engineer must flex a different set of skills at a higher abstraction: evaluating whether agent produced code is correct, maintainable, and well-suited to the system it is entering, whether the tradeoffs made in implementation are the right ones given the constraints of the full architecture, whether a codebase is accumulating tech debt that will compound badly. It’s possible that agents get better at this type of judgment as they absorb more system-level context. But it’s more likely that humans are better at holding the full system in mind: the history of decisions, the downstream consequences, and the organizational context that shape constraints. Engineers who have developed this judgment at the systems level will be more productive in an agent-native world. They can direct agents across the implementation layer while holding the architecture layer themselves.

The second category is newer and evolving every day: agent development infrastructure and security for AI-built software. This is not the same as traditional DevOps or cloud infrastructure work, though it will build on it. As agents become the primary builders and operators of software systems, the underlying architecture has to change to accommodate them. Agents need orchestration layers, sandboxing environments, memory systems, permission models, and verification infrastructure that did not exist in the pre-agent era. These agents need to operate within systems that are hardened against the new attack surfaces they introduce.

The Anthropic Mythos system card makes this security dimension very concrete. Mythos Preview was a model not released publicly exactly because of its powerful capabilities, such as its ability to autonomously discover and exploit zero-day vulnerabilities in major web browsers and operating systems. The same capabilities that make powerful models useful for defensive cybersecurity make them dangerous if deployed without careful infrastructure design. So building and maintaining the systems that agents operate within becomes deeply technical engineering work that requires more specialized expertise.

Beyond the security layer, there is a broader reskilling for engineers where they shift from writing application code to maintaining and operating agentic systems: workflow orchestration, debugging agent-written code, managing the interop between systems in a multi-agent world, and understanding new architecture for agent-native software. Aaron Levie tweeted about this job evolution after meeting with dozens of enterprise AI leaders across banking, media, retail, and healthcare:

Another week on the road meeting with a couple dozen IT and AI leaders from large enterprises across banking, media, retail, healthcare, consulting, tech, and sports, to discuss agents in the enterprise.

• Clear that we’re moving from chat era of AI to agents that use tools, process data, and start to execute real work in the enterprise. Complementing this, enterprises are often evolving from “let a thousand flowers bloom” approach to adoption to targeted automation efforts applied to specific areas of work and workflow.

• Change management still will remain one of the biggest topics for enterprises. Most workflows aren’t setup to just drop agents directly in, and enterprises will need a ton of help to drive these efforts (both internally and from partners). One company has a head of AI in every business unit that roles up to a central team, just to keep all the functions coordinated.

• Tokenmaxxing! Most companies operate with very strict OpEx budgets get locked in for the year ahead, so they’re going through very real trade-off discussions right now on how to budget for tokens. One company recently had an idea for a “shark tank” style way of pitching for compute budget. Others are trying to figure out how to ration compute to the best use-cases internally through some hierarchy of needs (my words not theirs).

• Fixing fragmented and legacy systems remain a huge priority right now. Most enterprises are dealing with decades of either on-prem systems or systems they moved to the cloud but that still haven’t been modernized in any meaningful way. This means agents can’t easily tap into these data sources in a unified way yet, so companies are focused on how they modernize these.

• Most companies are *not* talking about replacing jobs due to agents. The major use-cases for agents are things that the company wasn’t able to do before or couldn’t prioritize. Software upgrades, automating back office processes that were constraining other workflows, processing large amounts of documents to get new business or client insights, and so on. More emphasis on ways to make money vs. cut costs.

• Headless software dominated my conversations. Enterprises need to be able to ensure all of their software works across any set of agents they choose. They will kick out vendors that don’t make this technically or economically easy.

• Clear sense that it can be hard to standardize on anything right now given how fast things are moving. Blessing and a curse of the innovation curve right now - no one wants to get stuck in a paradigm that locks them into the wrong architecture. One other result of this is that companies realize they’re in a multi-agent world, which means that interoperability becomes paramount across systems.

• Unanimous sense that everyone is working more than ever before. AI is not causing anyone to do less work right now, and similar to Silicon Valley people feel their teams are the busiest they’ve ever been.

One final meta observation not called out explicitly. It seems that despite Silicon Valley’s sense that AI has made hard things easy, the most powerful ways to use agents is more “technical” than prior eras of software. Skills, MCP, CLIs, etc. may be simple concepts for tech, but in the real world these are all esoteric concepts that will require technical people to help bring to life in the enterprise.

This both means diffusion will take real work and time, but also everyone’s estimation of engineering jobs is totally off. Engineers may not be “writing” software, but they will certainly be the ones to setup and operate the systems that actually automate most work in the enterprise.

This is what engineering re-skilling will actually look like. We’ll migrate the technical expertise to be focused on maintaining and deploying agentic systems, from building individual features to designing and securing the infrastructure that agents run on. The engineers who can navigate this shift will become valuable people in any organization building with AI.

The two paths for engineers are starker than for any other function. The convergence path leads towards the previously described AI builder – an engineer who can direct agents across the implementation layer and also gains more breadth in domains like design and product to contribute across the full build cycle. The depth path splits into two sub-categories: the architect with system-levels judgment and the infra specialist who can create secure software. Both depth paths will require more technical excellence, not less.

Data Science

This function is highly disrupted by AI because the measurement and experimentation loop is highly agentable. Agents can already run smoke tests, triage errors, generate daily health digests, synthesize what happened across a codebase in a certain time window. Each of these tasks may have something that required a human specialist in data science or data engineering to execute. But now the function will be compressed at the execution layer and also accrue towards the judgment layer. It’s more important to know which questions to ask, evaluate whether the answers actually point at truth or noise, and formulate hypotheses that nobody else thought to test. Like other functions, this is the part of data science that the best practitioners were always doing and the part that the median practitioner rarely had time to reach because the execution layer consumed most of their bandwidth.

For data scientists, there is only one choice to survive: become AI-native in working with agents that absorb the execution layer, and be the empowered one who can direct agents to run analyses at scale, synthesize large bodies of behavioral data, surface anomalies continuously while refining your judgment for questions that matter. Reinvent yourself with AI.

User Research

While agents can conduct synthetic interviews, synthesize transcripts, identify patterns across qualitative data, and generate summaries of user insights – there is still something missing about how AI disrupts this field. All these capabilities are real and compress the execution layer of researchers.

But user research is fundamentally relational work, the specialists make genuine contact with real human beings. The core value of user research was not synthesis of findings, it was the direct observation of a person encountering something you built, the ability to hear what isn’t being said, the discipline of being open enough to what you observe that reality comes through without being filtered by your existing assumptions. I’m not convinced that capability exists in agents or ever can. It requires presence, attention, and a form of practiced empathy that may be impossible to simulate.

I see a clear path for researchers in the future: one who can direct agents to scale the analytical layer while preserving their own judgment for direct human contact that produces the most important insights. This person leverages AI to have agents absorb the logistical tax of their field: recruiting, scheduling, transcribing, writing synthesis docs and slides.

If user research can close the feedback loop faster, there is an opportunity to more directly influence product decisions. This gap has partially existed because the synthesis layer in research was slow and expensive. But if agents can compress the synthesis layer, the insights from direct human contact can travel faster and more completely into the building process. Research becomes less of a phase-gated activity and more of a continuous input, which is what the best researchers always argued it should be.

The Cambrian Explosion of Software

The most immediate and visible consequence of all of these changes – a new type of builder, tools that widen the TAM of builders, the flywheel accelerating between both – is a Cambrian explosion of software. Today, there probably is not enough software in the world where there should be. And these enabling factors will make it so that more software, will be built faster, by a much larger pool of people, than any prior point in history.

We can see glimpses of this already happening. The YC winter 2025 batch reported 25% of its startups had codebases that were 95% AI-generated. Bolt.new reached $40M ARR in 6 months, Lovable reached $100M ARR in 8 months. Think of the indie builders, solopreneurs, people building tools for themselves and small audiences that are empowered with LLMs. The pool of people who can build software has expanded by an order of magnitude, and the pool keeps growing.

Why will this explosion happen? Today, new creators are entering the market with a mental model of the old world where there was still an arbitrage opportunity of software, when it was bottlenecked by scarce human labor. But that window is closing as the economics that made software so lucrative are under pressure. And yet the explosion of building software is still happening anyway, and will continue to accelerate.

The reason is that when the cost of trying approaches zero, you don’t need a compelling business case to build. You can build because you have an idea and the barrier to acting on it has collapsed. Matthew Gallagher built Medvi with $20,000 and two months, generating $401 million in revenue in year one with no employees. Daniel Roth, LinkedIn’s editor in chief, built iOS apps for fifteen people — not for revenue, not for scale, but because he could and because the thing he wanted existed once he built it. Feltsense rebuilt every startup in a YC demo day batch in 24 hours to demonstrate what is now possible. The motivation to build is no longer primarily economic. You can build to explore your curiosity, to express yourself, to solve a problem, or to act on the fundamental human impulse to make things that didn’t exist before.

More software will inevitably mean more noise. The same dynamic that produced an explosion of low-quality content on social media will play out in software. Most of what gets built will not be good and will not survive. Just as the Cambrian explosion in biology produced enormous diversity but also enormous extinction.

Second-Order Consequence: What Software Survives

Core Belief: When execution becomes abundant, it is no longer a moat for venture-scale software businesses. What survives are defensible software products: proprietary data in specialized domains, distribution or entrenched incumbents as legacy players, or persistently scarce markets

Clayton Christensen defined the Conservation of Attractive Profits: when one layer of a value chain commoditizes, the attractive profits migrate to the adjacent layer that is still scarce and differentiated. It happened in computing when disk drives commoditized and profits moved to operating systems, when operating systems commoditized and profits moved to applications, and when applications commoditized and profits moved to data and user relationships.

For 50+ years, the attractive profits in software lived in execution – in the ability to build things that were hard and expensive to build. This justified venture capital inflow for high margin returns. With AI commoditizing the execution layer, we must look for where the attractive profits now migrate. Below, I outline 3 non-exhaustive categories of software that survive the abundance transition.

The first category is software built on proprietary data, workflows, or in specialized domains. Data is the most durable moat in a world where execution is abundant, because user data accumulates through genuine human activity. Any product with strong distribution on a valuable human behavior will generate proprietary signals that make that product genuinely better for the people that use it. If domain-specific knowledge is embedded into the dataset, this makes it even more difficult for competitors to replicate by building the same interface.

The businesses that survive on proprietary data tend to be the ones operating in highly specialized domains where the data is inherently hard to collect. This may be because the domain is narrow and the signal can only be generated by genuine practitioners. Examples could include a healthcare platform that has accumulated years of clinical workflow data, a legal research tool that has indexed proprietary case outcomes, a financial model trained on decades of proprietary transaction data. These types of products become more defensible pieces of software because unless human behavior migrates to another surface, the user data is the moat.

The second category is deep incumbents that have staying relational power or entrenched distribution. Distribution has always been important in software and will continue to be. There are businesses that have earned genuine distribution or mindshare of their users, through years of trust-building and accumulating switching costs that come from being the system of record. These products find their position strengthened rather than weakened when execution becomes cheap. Their competitors can build faster and newer features, but they cannot recreate existing distribution especially in enterprise.

Going back to Levie’s enterprise observations, we can see incumbent vendors adapting AI-native requirements by focusing on things like headless, interoperable agent interfaces. This further strengthens their distribution advantage. Legacy players who have embedded deep into institutional complexity like regulatory processes, procurement systems, long-term contracts, org dependencies are an extreme version of this. Change management and migrations are long, painful processes that no one enjoys. Incumbents are not invincible to disruption, but their moat was not execution so they are less immediately threatened.

The third category is software serving persistently scarce markets. These markets are scarce because the underlying human activity they serve is constrained. Physical proximity is scarce. Genuine human connection is scarce. Trust between strangers is scarce. The desire to be entertained and moved by something real is scarce. The software that serves these scarce underlying activities survives the abundance transition because what it is selling is not software — it is access to something that software alone cannot produce.

For example, online marketplaces endure because they break the constraint of physical proximity for economic exchange. You can find a buyer for your handmade ceramics anywhere in the world because Etsy exists. You can stay in someone’s home in a city you’ve never visited because Airbnb digitized trust. The underlying scarcity — that buyers and sellers are separated by geography, that strangers need a trust infrastructure before they can transact — does not dissolve because execution becomes cheap. Agents will handle more of the navigation layer of these marketplaces. The marketplaces themselves, and the trust infrastructure they have built, remain.

Entertainment endures because the experience of being moved, surprised, and transported by something good is irreducibly human. Netflix, Spotify, YouTube, gaming platforms – they’re not going away because the human being having the experience is the point. Agents can generate content at scale, and flood the supply side but the premium will accordingly move to curation, taste, and genuine creative expression. The experience remains human and platforms that have earned the distribution to deliver the human experience to hundreds of millions of people have a moat that cheap execution cannot erode.

So what doesn’t survive?

The middle of all software. Rasmus Andersson captured the competitive consequence in February 2026: there is now only one playbook remaining – make the best product. Not the fastest, not the cheapest, not the one that updates the most often. The best. Because when execution is cheap, the quality of judgment about what to build becomes the differentiator.

The businesses that sat in the middle that were execution-heavy, coordination-intensive, without genuine data moats, distribution advantages, or institutional embeddedness were businesses whose primary value was packaging workflows into a navigable interface and whose defensibility rested on building being hard. Now if the primary value you delivered was a navigable interface for a workflow that agents can navigate directly, what is the product actually for?

The story of what survives is ultimately the Conservation of Attractive Profits completing its cycle. As execution commoditizes, the profits migrate to proprietary data, earned distribution, and markets that are persistently scarce because human activity is constrained.

But the cycle doesn’t stop there. As the model layer itself begins to commoditize – as the gap between frontier models narrows, access to capable AI becomes ubiquitous with open-source models – the profits in building software migrate again. This time we should see value accrue to the infrastructure around the model: the orchestration layers, memory systems, harnesses and sandboxes, evaluation pipelines. I’m bullish on headless software – APIs, orchestration endpoints, data access layers built for agentic consumption rather than human navigation – as an emerging category where the migration lands. Businesses building this infrastructure are doing what every prior generation did before, becoming the new scarce layer where the attractive profits go next.

As the floor drops for software and empties out the middle, what happens to the capital markets that funded the middle for the last few decades?

Third-Order Consequence: How Capital Reorganizes

Core Belief: The economic structures built around human labor as the scarce input – venture capital funding, high margins, winner-take-most dynamics – reorganize as input to building software becomes abundant. This kills the market for the median software business and produces a long-tail of software creation that is not venture-viable

The first two consequences describe what happens inside the act of building software and inside the competitive landscape around it. But there’s a third consequence that follows directly from both, and it’s the one that I think is most underappreciated in the current discourse: what happens to the financial architecture that funded the software industry for the last fifty years.

To understand why capital has to reorganize, I need to go back to the five conditions I described in Part 1 that made venture capital the right instrument for software in the first place: high upfront cost, long time to payoff, high failure rate, asymmetric upside, and winner-take-most dynamics.

Every one of those conditions was downstream of human labor as the binding constraint. When I think about what changes when token costs replace headcount costs, each condition shifts. The upfront capital requirement collapses — a two-person team building with agents doesn’t need to raise a Series A to hire fifty engineers before they can ship. The time to first revenue compresses from years to months, sometimes weeks. The failure rate changes because the cost of finding out whether your venture will fail is a fraction of what it was before. The asymmetric upside that justified venture scale bets is harder to sustain when execution is no longer a moat for many businesses. And the winner-take-most dynamics weaken when the compounding advantage of having more resources to build faster than competitors also weakens.

Venture capital loses its fit for the middle of the market it was designed to serve. The venture model was always a power law: a small number of enormous winners funding a large number of failures. But the shape of the distribution needs to change accordingly.

At the top of the power law, the concentration becomes even more extreme. The businesses with true innovation at the frontier, asset-heavy investments, genuine data moats, distribution advantages, and institutional embeddedness will survive and increasingly attract more capital, and return more of it. You can already trace capital flows to neolabs and new categories like agent infrastructure bets, as capital allocators recognize the value of a new platform layer: whoever owns the orchestration rails, the memory systems, and the eval infra that agents run on, is building the next generation of compounding distribution advantages.

At the bottom of the distribution, I expect an explosion of software creation that operates entirely outside the venture model. Indie builders, solopreneurs, small teams building on token costs, generating real revenue without ever needing or wanting institutional capital. Patrick Collison pointed at this in a February 2026 interview — bespoke software created the moment you need it, not packaged into a SaaS product and sold on a per-seat basis to thousands of companies who all need something slightly different. When custom software is cheap to produce, the economic rationale for one-size-fits-all SaaS erodes. The indie builder who can now build and maintain a product that once required a funded startup is the beneficiary of that erosion.

And in the middle, the businesses that represented the bulk of venture deployment over the last decade or two will face pressure as their expected value declines. Many venture funds whose thesis was built around the old unit economics of software will find their model misaligned with the market they are trying to serve.

Ryan Daniels named the emerging organizational form that fills the gap left by the middle collapsing. He calls it the neofirm — small teams organized around outcomes rather than functions, combining practitioners and engineers, pricing on results rather than seats. The neofirm is not a startup in the traditional sense. It doesn’t raise venture capital, doesn’t chase winner-take-most dynamics, and doesn’t need to scale to justify its existence. It’s a different organizational atom built for a world where execution is cheap and judgment is expensive — where the value is in knowing what to build and whether it worked, not in the capacity to build it at scale. I think the neofirm is the organizational structure that the new economics of software actually optimize for, and I expect we’ll see a lot more of them.

Lenny Rachitsky’s data from early 2026 is an early leading indicator of where this is already showing up inside companies. PM and engineering roles are at three-year highs — consistent with the near-term signal that the Cambrian explosion is driving more building. But design roles are plateauing. I’ve always thought of design as the leading edge of these transitions, because it’s the function most directly tied to taste and judgment rather than execution. When design plateaus while engineering is still at highs, it suggests to me that the reorganization has started at the judgment layer and will work its way through the execution functions over time. The capital markets will follow the talent markets, as they always do — lagging by the time it takes for the shift to show up in portfolio performance rather than hiring trends.

The net result is a software economy that looks less like the one the last fifty years produced. At one end: a small number of large, deeply defensible businesses capturing more value than ever, and a new class of infrastructure companies building the rails the agent economy runs on. At the other end: a vast distributed long tail of software creation operating entirely outside the venture model. The middle — which venture capital built and funded and celebrated for fifty years — is what the scarcity-to-abundance shift most directly hollows out. The capital that used to flow to that middle has to go somewhere. My bet is that it bifurcates: more of it chases the genuinely defensible businesses at the top, and more of it chases the new infrastructure layer at the bottom, while the middle quietly empties out.

Fourth-Order Consequence: The New Market Equilibrium

Core Belief: When agents absorb both the building and the navigating of certain software, the question of what we needed software for will again have a clean answer. Human attention can be relieved of the tax of digital complexity and productivity, and reallocated towards the things worth being present for.

The first three consequences describe what happens to the act of building software, to the businesses built on it, and to the capital markets that funded it. The fourth is the one I find most interesting to think about, and also the hardest to be precise about. It requires stepping back from the proximate changes and asking the question that the first three consequences make it possible to ask: what was software actually for?

I want to start with something personal, because I think it makes the long-term thesis more concrete than any amount of abstract reasoning could.

My life in 2026 changed my view on digital productivity because I spent my time differently. I still went online to watch TV, text friends, scroll, read articles, write, pay bills and so on. But I spent more and more of my day in the physical world – in shared experiences, and in the presence of another human being who just arrived in this world, in the kind of connection that has no digital equivalent. The things I still do online are chosen, not imposed. I’m not logging in to be productive. The decoupling of economic viability from screen time changes the relationship to screens entirely. And it turns out, it’s possible to imagine a life that doesn’t require a screen.

I think this is a preview of a future state we could be headed towards. As models increasingly become capable, as we pursue the path of recursive self-improvement, and hurl ourselves towards AGI and ASI — intelligence in its machine form will be abundant. Even in the near-term, agents will absorb more of the knowledge work layer of screen time the same way parental leave absorbs the economic pressure to be online. When agents handle your inbox, triage your tasks, synthesize your research, navigate your digital complexity, and manage the routine operations of your digital life — what do you do?

On one hand, we will keep striving for efficiency and achieve a different form of Jevon’s paradox. We will attempt to do more with our newfound time, to be more ambitious, and to pursue more velocity. There will be new forms of digital work and jobs to done, perhaps heavily oriented around collaborating and managing agents. But I don’t believe this type of work dictates the same navigation and orientation to screens as it once did, perhaps migrating to new form factors and interactions beyond the computers and phones woe have today.

I believe when we do look at screen, we will be more intentional about what requires our scarce attention. What remains online is the chosen layer: recreation, leisure, genuine connection, and the things humans do because they want to. Human attention will become scarcer. And the software that earns that attention also becomes more valuable.

I’ll admit that this is the most speculative of the four consequences. The near-term reality is that more software is being built than ever, more people are spending more time online navigating more digital complexity, and the AI era has, if anything, increased the cognitive load on most knowledge workers rather than relieved it. The equilibrium I’m describing may be ten or twenty years away. But I think the direction is a good one to orient towards and my experience on leave gave me a concrete way to feel what that direction points toward.

Software moves from scarcity to abundance. The amount of human intelligence allocated to building and using software shifts. Part of it moves up toward the new specialization of building with and building for agents. But a larger part reallocates to other activities — to the things that generate genuine value for people and for society in ways that are hard to predict from where we sit today. The old arbitrage opportunity of software — absorbing expensive human labor as input, producing infinitely scalable code as output — will no longer exist in its current form. What replaces it is still being invented. But the direction is clear: toward software that earns human attention rather than extracts it. Toward a world where the screen is a place you choose to be.

I think about my daughter, who just arrived in this world with no relationship to any of this — no learned dependency on productivity software, no inbox to manage, no SDLC to run. She will grow up in a world where agents handle most of what I spent my career learning to navigate. What she will need software for will look completely different from what I needed it for. And that, more than anything else I’ve written in this essay, is what makes me genuinely optimistic about where this is going.

A massive thank you to those who read drafts of this and shared feedback: Rohan Chitalia, Chris Rappoli, Shiv Patel, Maximillian Piras, John Falcone, and others.