Skip to content
Latticework
Esc
Try
No. 100AI Systems

Software 2.0

Some software is no longer written as code but learned from data; the dataset and the objective become the program.

In Software 2.0 people write the data and the goal, and training finds the program.

To an executive

Some problems are better solved by showing a system examples than by writing rules. Quality then improves with better data, not just more programmer effort.

To an engineer

Decide per behaviour whether to write code, train a model or prompt one. Use learned components for perception, language and fuzzy judgement, and keep explicit code where rules are clear.

The idea

In 2017 Andrej Karpathy, a founding member of OpenAI who was then leading AI at Tesla, argued that neural networks are not just another tool in the programmer's kit but a different way of writing software. In "Software 1.0", people write explicit instructions. In "Software 2.0", people specify a goal and collect examples, and an optimiser searches for a program — the network's weights — that meets it.

In a 2025 talk he extended the idea: with large language models, much behaviour is now specified in plain language prompts, which he called Software 3.0. All three kinds now live side by side in the same systems.

Why it works

Some behaviour is easier to show than to describe. Nobody can write rules that recognise every face or parse every sentence, but examples of the right answer are plentiful.

Learned components improve with data, not just with effort. Better data and better models lift quality without rewriting logic by hand.

Where it applies

  • Deciding what to build as code and what to train or prompt. Perception, language and fuzzy judgement suit learning; rules, money and invariants suit code.
  • Change management. A new dataset or a new model version is a release, even if no line of code changed.
  • Team design. Data curation and evaluation become engineering work, not a side task.

How to apply

  1. Draw the boundary. For each capability, decide whether it is code, a trained model, or a prompted model — and keep deterministic rules in code.
  2. Treat data and prompts as source. Version them, review them and test them like code.
  3. Make evaluation the specification. A learned component is only defined by the examples it must get right.
  4. Release learned changes deliberately. Roll out new models or datasets with canaries and rollbacks, as you would new code.

Example scenario

A support platform routed tickets with three hundred hand-written rules that nobody dared touch. The team replaced routing with a model trained on two years of correctly routed tickets, kept refund approvals as explicit code, and built a regression set of tricky tickets.

Routing accuracy rose, and each later improvement came from adding labelled examples rather than new rules. When a retrained model misrouted urgent tickets, the regression set caught it before release.

Questions to ask

  • Which part of this system is behaviour we write, and which is behaviour we train or prompt?
  • Where is the source of truth for the learned part: the data, the evaluation set, or the weights?
  • How do we review, version and roll back a change in learned behaviour?

When not to use it

  • Behaviour you must explain or guarantee, such as pricing, permissions or compliance rules.
  • Problems with too little good data, where a learned component will be unreliable.

How it misleads you

Learned components fail in ways code does not: silently, unevenly and without a stack trace. Treating a model as a drop-in function without evaluation, monitoring and versioning turns a capability into an invisible source of risk.

In the wild

Further reading

Last reviewed · Suggest an improvement