Software 2.0 Is Here and It Changed How I Think About Programming

In 2017 I read a post called "Software 2.0" and honestly didn't fully get it. I remember thinking: "Yeah, neural networks are powerful. We use them for hard problems. Classic ML things — speech, vision, translation. Cool framing." And I moved on.

I had been writing software for six years at that point. I thought I understood where machine learning fit in my stack and where it didn't. It fit in a box: a specialized tool you reach for when the rules are genuinely too hard to enumerate. Everything else? You write the code. You write the logic. You ship.

That mental model was wrong. It took me another nine years and a lot of broken pipelines to understand how wrong.

What That Post Actually Said

The argument in Software 2.0 was not "neural networks are useful." That's obvious. The argument was that neural networks represent a different computing paradigm — one that should eventually displace traditional explicit programming as the default.

In Software 1.0, you write logic. If this, then that. Parse the string, apply the regex, compute the heuristic, return the result. You are the programmer. You write the rules.

In Software 2.0, you write the objective — the loss function — and you collect data. Gradient descent searches the space of programs and finds one that achieves your objective. You never write the actual logic. The logic emerges from optimization pressure over labeled examples.

The programmer's job doesn't disappear. It shifts. You become a curator of datasets and a builder of training infrastructure. You write the thing that tells the optimizer what "good" means, and you assemble the evidence it needs to find its way there.

In 2017, this framing felt academic to me. It felt like it described some future state of very large companies with very large research teams. It did not feel like a description of what I would be doing on a Tuesday in 2026.

And yet.

What Actually Happened

The last three years have been a systematic collapse of the boundary I thought existed between "problems you solve with code" and "problems you solve with models."

I have spent the last decade writing logic to do things like:

• Parse and normalize unstructured clinical text
• Route messages based on semantic intent
• Extract structured fields from messy documents
• Score user behavior against a rubric
• Classify support tickets into categories

Every one of those I used to approach with explicit logic first. Write the parser. Write the rules. Write the heuristics. Tune the thresholds. Ship.

Today, I approach every one of those problems with a model first. Not because I'm chasing novelty. Because the model is faster to build and better at the job. The explicit logic approach produces a system I have to maintain, edge-case forever, and retrain whenever the real world drifts. The model approach produces a system I improve by improving the data it sees.

That shift is exactly what the Software 2.0 framing described. And I didn't fully believe it until I lived through it enough times.

What It Got Right

The most important prediction was about the direction of the transition, not the speed. Software 2.0 would take over "a large fraction" of software development — and that turned out to be right about the fraction, and if anything conservative.

The specific domains called out — image recognition, speech-to-text, machine translation, game playing — those have been fully colonized by learned systems. No serious team is writing handcrafted feature extractors for those problems in 2026.

But the transition went further than I think anyone expected at the time. The LLM wave extended Software 2.0 thinking into domains that were previously untouched: freeform text understanding, code generation, document analysis, reasoning over long-context inputs. These aren't problems where the rules were "too hard to enumerate" in the classic sense. They're problems where it turns out nobody needs to enumerate the rules at all.

The role inversion also landed exactly as predicted. The programmer becoming a dataset curator and training infrastructure builder — that is exactly what ML engineering looks like. That is my job, in substantial part. The code I write today is increasingly scaffolding around models: the pipelines that feed them data, the evals that measure their outputs, the retrieval systems that give them context. The model does the inference. I maintain the conditions under which the model is right.

What It Underestimated

There are a few places where the Software 2.0 framing needs updating, or at least nuance.

First, the data curation burden is real and underappreciated. Writing the loss function is not always the hard part. Getting clean, representative, well-labeled data at the scale and diversity you need is genuinely hard. The post acknowledged this, but I don't think it conveyed how much of your time you end up spending there. In my experience, the data work is often three to five times the modeling work.

Second, the paradigm doesn't fully collapse traditional software — it sits on top of it. The stack underneath a modern ML system is deeply, thoroughly Software 1.0. Databases, networking, container orchestration, API design, security boundaries — none of that is learned. You still need people who can write explicit logic, and that logic matters. Software 2.0 is the application layer; it runs on a Software 1.0 foundation.

Third, the boundary between the paradigms is fuzzier in practice than it sounds in theory. I don't work on purely 2.0 systems. I work on hybrid systems constantly. A production pipeline might use a model for intent classification, explicit rules for routing based on that classification, another model for generation, and explicit validation logic to catch the generation going off the rails. The seams between paradigms require careful engineering.

What It Means Now, In 2026

Here is the mental model I have landed on after nine years of seeing this play out:

Software 2.0 is the right default for anything involving perception, language, or judgment. If the problem requires reading text, understanding intent, interpreting an image, or applying a nuanced rubric, start with a model. Do not start with rules. You will lose time and ship something worse.

Software 1.0 remains the right tool for anything deterministic, transactional, or where correctness can be formally specified. Database transactions, cryptographic operations, billing logic, access control — these have right answers, and right answers should not be approximated by gradient descent. Write the code.

The highest-value engineering skill right now is knowing which side of that line a problem lives on, and making that judgment quickly. I have watched smart engineers spend weeks building rule-based systems for problems that a model would have solved better in an afternoon. I have also watched engineers reach for a model for a problem that just needed a SQL query. Both are expensive mistakes.

Evals are the new tests. This is the Software 2.0 equivalent of the unit test. If you are shipping learned behavior without evaluation infrastructure, you are shipping blind. Writing good evals — covering the failure modes your system actually produces in the real distribution of inputs — is now a core engineering competency. Not a nice-to-have.

The shift also changes what it means to debug. In Software 1.0, a bug is usually findable: you trace the logic, find the branch that wasn't right, fix it. In Software 2.0, a "bug" is often a distribution problem. Your model is wrong on a class of inputs that are underrepresented in your training data. The fix is not a patch. It is data. Debugging means data analysis.

The Part That Still Surprises Me

What I did not anticipate — what I think most people building in 2017 did not anticipate — is that the shift would extend to the act of writing software itself. I did not expect that code generation would fall inside the Software 2.0 paradigm. The original post hinted at it, but it felt distant.

It is not distant. Claude Code is my daily environment. The experience of building software now involves me specifying objectives, reviewing outputs, correcting failures, and curating context — which is, structurally, a version of what Software 2.0 described as the programmer's job. I am not writing every line. I am maintaining the conditions under which the model produces lines that are right.

That 2017 post was not describing a future I would adapt to. It was describing the future I am already inside. That took me too long to see clearly, and I think the clearest version of seeing it is this: it was not about machine learning as a technology category. It was about the nature of programming itself, and what it means to instruct a computer to do a thing. That question has a different answer now than it did when I started.

I read the post in 2017 and thought it was about neural networks. I understand now that it was about epistemology.