In August 2011, Marc Andreessen published his now-famous Wall Street Journal op-ed arguing that software was systematically transforming and disrupting every major industry. The thesis was prescient. The prediction proved correct in ways that even Andreessen probably did not fully anticipate at the time. Banks have become fintech platforms. Media companies have become algorithm-driven content engines. Retailers have become logistics and data operations. Healthcare has become a software problem as much as a medical one.
But the op-ed had a gap. A significant one.
It described what software was doing to industries without examining the human infrastructure required to do it. The piece that almost nobody discusses in the thirteen-plus years since is the specific, concrete skill question it left completely unanswered: who, exactly, builds, maintains, secures, and makes sense of this software-eating-the-world? And what happens to the millions of professionals in industries that software is transforming — do they survive the transformation, or does the eating extend to them as well?
This article takes Andreessen's thesis seriously on its own terms and then examines the dimension it missed: the human capability question. It is written for practitioners who are not neutral observers of software eating the world — who are either building it, working in an industry it is disrupting, or trying to position themselves to be on the right side of that disruption.
What Andreessen Actually Got Right (Which Is Most of It)
Before examining what the thesis missed, it is worth being precise about what it got correct — because the accuracy of the prediction is directly relevant to the urgency of the capability question it left unanswered.
Andreessen's core observation was not that software companies would become large. It was that non-software companies would become software companies — that the defining competitive advantage in almost every industry would eventually be software capability, regardless of what the industry nominally sold.
The evidence for this in 2026 is extensive:
In financial services: The largest banks in the world now employ tens of thousands of software engineers. JPMorgan Chase's technology headcount exceeds that of most technology companies. Goldman Sachs rebuilt its core trading infrastructure as software and spun out Marcus as a consumer fintech product. The competition in financial services is now substantially a competition in software quality, data infrastructure, and algorithmic capability.
In retail: Amazon's competitive advantage over traditional retailers was never primarily about lower prices or broader selection — it was about logistics and inventory software that allowed it to operate with structurally lower costs and higher reliability. Walmart's response was to become a technology company that happened to sell groceries — deploying machine learning at scale for demand forecasting, supply chain optimisation, and personalisation.
In healthcare: The most significant competitive differentiation in diagnostics is now AI-assisted imaging analysis. The most effective drug discovery pipelines use computational chemistry and machine learning. Electronic health records have made clinical data management a software problem of the first order.
In media: The content that people consume is now selected by algorithms, not editors. The platforms that distribute content have more market power than the companies that create it, specifically because their distribution software is the scarce and valuable resource.
Andreessen was right. The transformation is real, it is ongoing, and it is accelerating rather than plateauing.
The Part of the Thesis Nobody Talks About: The Human Capability Gap
Andreessen's essay describes a world where software disrupts industries. What it does not describe — and what has turned out to be equally important — is the massive, sustained human capability gap that software transformation creates.
The gap is this: when a financial services company, a hospital, a retailer, or a media company becomes a software company, it needs people who can build, operate, interpret, and govern software at a level that their existing workforce does not have. This is not a minor transition. It is a fundamental restructuring of which human skills are economically valuable.
The people who thrived in a pre-software financial services firm — fixed income traders who used intuition and relationships, branch managers who built customer trust through face-to-face service, analysts who built models in Excel and produced reports for senior management — are not automatically valuable in a firm that has rebuilt itself as a fintech platform. Some of those skills transfer. Many do not. And the skills that are most in demand in the transformed firm — data science, software engineering, machine learning engineering, cybersecurity, cloud infrastructure — were not part of the original workforce in any significant way.
The human capability gap is not a problem that resolves itself. It compounds. As software eats faster, the gap between the skills the transformed economy demands and the skills the existing workforce possesses grows wider. The gap is not primarily a pipeline problem — it is not simply that there are not enough people studying computer science at university. It is a depth problem: the skills required to do economically valuable work in a software-first economy are genuinely difficult to acquire, require sustained investment to maintain as the technology evolves, and are not evenly distributed across the population.
This is what Andreessen's thesis missed: the eating happens, but digestion takes time, and the human infrastructure required to make the eating work is the binding constraint on how fast it can proceed.
Who Actually Builds It: The Invisible Architecture of Software-Driven Industries
When a bank deploys a machine learning model to approve loans in milliseconds, the model is visible. What is invisible is the human architecture that makes it possible to exist and keep working.
Consider what it actually takes for a production machine learning model to exist in a financial services context:
The data engineer who built and maintains the pipeline that collects, cleans, and transforms the raw transactional data into features the model can use.
The data scientist who designed the model, selected the features, evaluated the performance across different population segments, and documented the decisions made during development.
The ML engineer who converted the data scientist's experimental model into production-ready code, set up the serving infrastructure, and configured the monitoring that alerts when the model's performance degrades.
The platform engineer who maintains the cloud infrastructure the model runs on, manages the costs, and ensures the system scales under load without failing.
The security engineer who reviewed the system for adversarial inputs, ensured the data pipeline complies with PII regulations, and maintains the audit trail that regulators require.
The compliance officer or model risk manager who reviewed the model for bias, validated that its decision-making logic is explainable to regulators, and approved it for production use.
The product manager who specified what the model needed to do, translated business requirements into technical specifications, and owns the ongoing decisions about when the model needs to be retrained or replaced.
The domain expert — in this case, a credit risk professional — who reviewed the model's outputs against their understanding of creditworthiness, flagged cases where the model's predictions conflicted with their experience, and provided the business context that pure data analysis cannot supply.
None of these people appears in Andreessen's thesis. The essay describes what software does to industries. It does not describe the human ecosystem required to make software do those things reliably, safely, and at the scale that industries require.
The Three Categories of People Software Transformation Creates
Andreessen's thesis is often read as a binary: software wins, everything else loses. The actual landscape is more nuanced. Software transformation creates three distinct categories of professional outcomes — and understanding which category you are in, or heading toward, is the most practically important implication of the thesis.
Category 1: The software builders.
These are the practitioners who directly create the software that is eating the world. Software engineers, data scientists, ML engineers, data engineers, security engineers, cloud architects. This category is in high demand, commands strong compensation, and — critically — tends to retain economic value as the technology evolves, because the underlying skill (building and maintaining complex systems) transfers across technology generations even as the specific tools change.
The non-obvious truth about this category is that it is not homogeneous. A junior software engineer who knows how to write basic CRUD applications is not in the same position as a senior engineer who understands distributed systems, data consistency, and performance at scale. The software builder category has significant internal stratification, and the economic premium concentrates heavily at the upper levels.
Category 2: The software-enabled domain experts.
These are domain professionals — in finance, healthcare, law, marketing, logistics, media — who have built sufficient technical literacy to work effectively at the intersection of their domain expertise and the software systems that are transforming it.
The financial analyst who can not only understand a credit model's outputs but can critically evaluate the features it uses, the data it was trained on, and the business logic embedded in its design, is in a substantially stronger position than the analyst who simply reads the model's recommendations without engaging with how it works.
This category is arguably the highest-value category in the near term — not because it pays more than expert software engineering, but because the combination of deep domain knowledge and software literacy is rarer than either skill alone. The supply of people who genuinely possess both is small, and the demand for them is very large.
Category 3: The domain experts without technical evolution.
These are domain professionals who have not built the technical literacy required to engage effectively with the software systems that are transforming their fields. They retain their domain expertise — which still has value — but they are increasingly dependent on the software systems for productive output without the ability to evaluate, challenge, or govern those systems.
In stable environments, this category persists. The senior professional with thirty years of domain knowledge who cannot engage with the technology systems in their industry does not immediately disappear — their knowledge still has organisational value, and organisations have not yet fully transitioned.
In the medium term, this category faces significant attrition — not because the individuals are not talented or experienced, but because the work they do is increasingly performed by the software that their industry has adopted, and they have not built the skills to do the higher-order work that remains.
The Full Stack Developer in Context: Why the Role Matters More Than the Label
The term "full stack developer" is used loosely enough to be almost meaningless in some contexts and precisely defined in others. In the context of software eating the world, the full stack developer represents something specific and important: the practitioner who can move across the entire technology stack that makes a software product work.
The stack, in its concrete modern form, typically includes:
Frontend (client-side): The user interface that humans interact with — built in HTML, CSS, and JavaScript, typically using frameworks like React, Vue, or Angular.
Backend (server-side): The application logic that processes requests, validates data, applies business rules, and returns responses — typically built in Python, Node.js, Java, or Go.
Database layer: The persistent storage of data — relational databases like PostgreSQL for structured transactional data, or document stores and time-series databases for specific use cases.
APIs and integrations: The interfaces between the application and external systems — payment processors, authentication providers, third-party data sources.
Infrastructure and deployment: The cloud environment where the application runs — containerisation, orchestration, CI/CD pipelines, monitoring.
A practitioner who can work competently across this entire stack — building a frontend, writing the backend logic, designing the database schema, exposing an API, and deploying to a cloud environment — can independently build software products that solve real problems. This is the economic significance of the full stack role: not just that it is in demand (though it is), but that it represents a unit of productive capability that can operate with a minimal team.
The non-obvious implication: in the software-eating-the-world context, the full stack developer is not primarily valuable because they can fill a technical role on a large team (though they can). They are primarily valuable because they can build the specific software artefacts that transform a non-software business — the internal tool that automates a manual process, the API that connects two legacy systems, the dashboard that gives a senior manager visibility into data they previously could not access.
Data Science as the Translation Layer Between Domain and Software
If full stack development is the capability that builds the software infrastructure of transformed industries, data science is the capability that extracts intelligence from the data those industries generate — and translates it into decisions that humans and systems can act on.
Andreessen's thesis implies that software transformation produces value. Data science is the specific practice through which a significant portion of that value is actually realised.
Consider the retail example more precisely. Amazon does not simply have more software than traditional retailers — it has more data about customer behaviour, and it has the analytical capability to convert that data into predictions that drive operational decisions. The recommendation engine, the demand forecasting system, the dynamic pricing model, the inventory placement algorithm — each of these is a data science artefact that translates raw transactional and behavioural data into specific, value-generating decisions.
The data scientist in this environment is not a statistician who analyses data retrospectively and produces reports. They are a practitioner who builds and maintains the analytical systems through which an organisation's data generates ongoing operational value. This is a fundamentally different role than the analyst functions that data science is typically said to replace — and it requires a fundamentally different skill set.
What the practitioner role actually requires:
-
Statistical foundations: The ability to reason correctly about uncertainty, evaluate model performance, design experiments that produce clean causal inferences, and avoid the analytical errors (p-hacking, selection bias, overfitting) that produce misleading results.
-
Programming and engineering skills: The ability to write production-quality code that processes large data volumes efficiently, not just prototype analyses in a notebook environment.
-
Domain literacy: The ability to understand the business problem well enough to formulate it correctly as a data problem — to know which questions are worth asking, which data is relevant, and whether the model's outputs make business sense.
-
Communication and translation: The ability to explain analytical conclusions to non-technical decision-makers in terms that produce good decisions, not just accurate ones — which requires understanding how decision-makers think and what information they can and cannot effectively use.
The rarest combination — and the one that commands the highest premium — is a practitioner who brings genuine depth in statistical foundations, programming, domain knowledge, and communication simultaneously. Each of those capabilities is learnable. Developing genuine depth in all four requires sustained investment and deliberate practice, not simply completing a course or acquiring a certification.
The Cybersecurity Dimension: What Nobody Is Talking About at Scale
Andreessen's thesis describes software consuming industries. A predictable consequence that the thesis does not examine is that software consuming industries also means that the attack surface for malicious actors expands to include the core infrastructure of those industries.
When a hospital's medical records are in a spreadsheet on a paper-based system, a cyberattack cannot bring the hospital to its knees. When those records are on networked, internet-connected software systems — as they now are everywhere — they can, and they do. The ransomware attacks on healthcare systems in the United States and United Kingdom that have delayed surgeries, disrupted cancer care, and shut down emergency services for days are a direct consequence of software eating the world without sufficient human infrastructure to secure it.
The cybersecurity capability gap is, in many ways, the most acute version of the human capability problem Andreessen's thesis ignores. The demand for cybersecurity professionals has grown faster than the supply for over a decade. The skills required are genuinely difficult to build — they span networking, operating systems, cryptography, application security, threat intelligence, incident response, and increasingly AI-driven attack and defence mechanisms.
The practical implication for practitioners is twofold:
For builders: Every software system that goes into production in a regulated industry — financial services, healthcare, energy, government — requires security as a design requirement, not an afterthought. A full stack developer who understands application security, authentication design, and data handling is categorically more valuable than one who does not. The security skills are not optional capabilities — they are table stakes for production-quality work in high-stakes environments.
For domain professionals: Understanding cybersecurity at a conceptual level — what kinds of attacks exist, how they succeed, what the defensive posture of an organisation should include — is increasingly part of governance literacy for anyone in a leadership position in a software-transformed industry. The CISO who cannot communicate with the board, the board member who has no framework for evaluating cybersecurity risk — these are the specific gaps that produce governance failures when attacks occur.
The Investment Banking and Financial Analysis Dimension
Investment banking is one of the industries where software eating has been most visible and most consequential — and where the human capability question is most sharply defined.
The transformation of financial services through software has not eliminated the need for financial analysts. It has eliminated the need for financial analysts who only do financial analysis. The analyst who spends their time building Excel models by hand, searching manually for market data, and producing reports by compiling information from multiple sources is increasingly being replaced — not by AI in some abstract sense, but by specific software tools that automate exactly those tasks.
What has not been replaced is the judgment required to formulate the right analytical question, evaluate whether a model's outputs are economically sensible, synthesise disparate pieces of information into a coherent investment thesis, and communicate that thesis to decision-makers in ways that produce good outcomes.
The investment banking analyst who survives and thrives in this environment is not the one who builds the best Excel models. It is the one who understands the business well enough to know what the model should tell them, can identify when the model is telling them something wrong, and can construct the narrative around the numbers that makes the analysis actionable.
This requires a specific combination:
Financial modelling depth: Not just knowing how to use Excel but understanding the logic of DCF modelling, the assumptions embedded in comparable company analysis, the mechanics of leveraged buyout models, and what each type of model is and is not capable of revealing.
Data literacy: The ability to work with large datasets that contain the financial information financial models are built from — understanding data quality, normalisation, and the analytical approaches that work at scale rather than in small hand-built models.
Structural business understanding: The ability to look at a business and understand the drivers of its economics, competitive position, and future trajectory — which requires the kind of domain knowledge about industries that only accumulates through sustained engagement.
Communication and storytelling: The ability to construct a coherent narrative around numbers that produces decisions — which is the human capability that AI tools, at least in their current form, cannot replicate at the required quality level.
The Non-Obvious Implication: Domain Expertise Is Not Enough, But It Is Not Obsolete
The human capability argument in this article runs the risk of being read as "domain expertise is being replaced by technical skills." That is precisely the wrong conclusion, and it is worth being explicit about why.
Domain expertise — deep knowledge of how a specific industry works, accumulated through years of direct engagement — is not becoming less valuable because software is transforming the industry. In many ways, it is becoming more valuable, because it is the critical input that software systems cannot supply for themselves.
An AI system trained on historical credit data can identify patterns in that data with extraordinary accuracy. It cannot tell you whether those patterns will hold in a credit environment fundamentally changed by a pandemic, a rapid interest rate cycle, or a shift in consumer behaviour driven by factors that are not in the training data. That judgment requires a credit professional who understands not just the historical patterns but the causal mechanisms behind them and the conditions under which those mechanisms change.
What domain expertise is not sufficient for, in isolation, is everything else that the software-transformed industry requires. The credit professional who can make that macroeconomic judgment but cannot engage with the model that is making the credit decisions — cannot evaluate its features, understand its limitations, identify when it is being used in conditions it was not designed for — is not in a position to contribute that judgment at the point in the process where it matters.
The specific capability argument is this: domain expertise plus technical literacy is the combination that produces durable economic value in the software-transformed economy. Neither alone is sufficient. Both together are rarer than either individually and therefore carry a premium.
The practical implication for career strategy is clear but often resisted: the domain professional who has accumulated genuine expertise needs to build technical literacy as an additive capability, not as a replacement for domain knowledge. The question is not "should I become a data scientist" — it is "do I understand data science well enough to contribute to and govern the data-driven systems that are making decisions in my industry."
What This Means for the Next Decade: The Skills Infrastructure Question
Andreessen's thesis framed the software-eating-the-world phenomenon as primarily a business strategy question: which companies would be disrupted, which would do the disrupting, and how fast would it happen. The human capability dimension frames the same phenomenon as a skills infrastructure question: how does a society, an organisation, or an individual produce and maintain the capabilities that make the transformation work rather than break?
The answer has three levels:
At the individual level: The most important decision is which category to be in — and then pursuing the capabilities that determine that category with the seriousness those capabilities deserve. Technical skills do not improve from exposure alone; they improve from application to real problems, feedback from practitioners who are further along, and sustained engagement over time rather than course completion. Domain skills do not deepen from reading about an industry; they deepen from direct engagement with the decisions and trade-offs that industry faces.
At the organisational level: Organisations that transformed their products and operations through software but did not invest proportionally in the human capabilities required to operate and govern those systems are discovering that the technical debt — not in code, but in people — is a significant constraint on how far the transformation can proceed. The question for leaders is not "how do we deploy more AI" but "do we have the people who can make AI deployments work reliably, safely, and in alignment with our objectives."
At the societal level: The question Andreessen's thesis most directly implies is about educational infrastructure: does the education system produce practitioners with the combination of technical depth and domain breadth that the software-transformed economy requires? The answer in most geographies, right now, is not at the scale and quality the transformation demands. The gap between what employers need and what graduates possess is a structural constraint on how fast industries can transform and on which populations benefit from the transformation.
Closing: The Thesis Is Incomplete Without the People Who Execute It
Marc Andreessen was right about software eating the world. The transformation is happening, it is accelerating, and it is producing enormous economic value for companies and individuals positioned on the right side of it.
What the thesis left out is the infrastructure problem: the specific, sustained human capability required to build the software, secure it, extract intelligence from its data, and maintain the domain judgment that prevents it from producing automated nonsense at industrial scale.
Understanding this gap — and taking it seriously as a career question — raises the adjacent issues that any practitioner thinking about their position in this transformation will encounter. How exactly does a full stack development skill set translate into the specific products and systems that non-software companies need as they transform? What does a data science practice actually look like inside a financial services firm, a healthcare organisation, or a retail company — what problems are they solving, and what analytical capabilities are required to solve them? And how does the cybersecurity dimension interact with the development and data practice — what does it mean in concrete terms to build software that is secure by design, and how does that constraint change the development workflow?
These are the questions that Meritshot's programmes are built around — not as theoretical frameworks but as applied practice in the specific contexts where the transformation is actually happening. The Full Stack Development programme builds the capability to produce working software independently across the entire stack, grounded in the kinds of systems that software-transformed industries actually deploy. The Data Science programme develops the combination of statistical rigour, engineering skill, and domain literacy that makes analytical work genuinely valuable rather than impressive-looking but unreliable. The Cybersecurity programme trains practitioners in the security dimension that every software builder needs to engage with — not as an adjacent specialisation but as an integrated part of how software is designed and deployed. If Andreessen's thesis makes sense and the human capability dimension it missed is the binding constraint on the transformation, Meritshot is the place where that capability gets built.
Meritshot EdTech — training professionals across Data Science, Investment Banking, Full Stack Development, Cyber Security, and Business Analytics.
