Software 1.0 · 2.0 · 3.0 — สามยุคซ้อนกันในระบบเดียวSoftware 1.0 · 2.0 · 3.0 — Three Eras, One Deployed System

🤔 If Nong Kram answers one refund-eligibility question wrongly tomorrow morning, what do you open first — the code in src/, the model your vendor hosts, or the system prompt?

The previous post, What Is an AI-Core System?, classified systems along two axes — decision authority and model indispensability — and placed Nong Kram, the customer assistant of the KramKraft ceramics shop, in the AI-core quadrant: model output controls an external action through the refund tool, and the removal ablation drops task success below the predeclared threshold. That quadrant comes with the full set of obligations — hard mediation, semantic evaluation, tracing, fallback — but before anything can actually be wrapped in an envelope, a more basic question has to be answered first: what does the system we are about to wrap consist of, and which files does its behaviour actually live in?

The whole post's answer comes from Section 3 of the paper: one AI-core system carries three eras of software stacked in a single call path — Software 1.0, explicit code the engineer writes by hand; Software 2.0, weights an optimiser learns from a dataset; and Software 3.0, context assembled at runtime and handed to a frozen model to interpret. These three are not rival architectures to choose between: they run together inside a single customer request. Each layer has its own author, its own principal artifact, its own assurance method, and — when it breaks — its own failure signature. The work of this post is to map your system onto those three layers, one artifact at a time, and write the result down as a document your team can actually triage incidents with.

1. The Eras Do Not Replace Each Other — They Stack in One System

The conclusion of this section fits in one sentence: Software 1.0, 2.0 and 3.0 are not an evolutionary sequence in which each generation swallows the last — they are overlapping layers in the single deployed call path of a real system.^[1] One customer question — "can I get a refund on order #1042?" — walks through all three layers in a few hundred milliseconds, and knowing which layer each stretch of that path belongs to is the root of every remaining post in this series.

Software 1.0 is the layer we know best: explicit logic an engineer writes as source code — the API routes, the database wiring, the refund() function that actually hits the payment processor. Its dominant uncertainty is human error in the logic, and its assurance methods have hardened over decades: type systems, code review, test suites, and formal proof for the critical parts. When this layer breaks, it breaks as a bug — wrong logic that reproduces deterministically and reads straight off a stack trace.^[1]

Software 2.0 is the layer of learned components — the term Karpathy coined back in 2017.^[2] The author of this layer's artifact is not a human but an optimiser: engineers curate the dataset and define the objective, and the training process writes the weights. In our system this layer is the frozen, version-pinned language model M_v, plus the embedding model on the retrieval side. Its dominant uncertainty is not wrong logic but generalisation beyond the training distribution; its failure signature is poor generalisation and distribution shift; and its era grew a concrete assurance discipline of its own — held-out evaluation and production-readiness rubrics such as the ML Test Score^[4] — which the paper extends onward to the third layer.

Software 3.0 is the layer that is genuinely new and least understood: context assembled at runtime — the system prompt, the customer's message, the passages retrieval pulled in, tool results — composed into one input and handed to a frozen model to interpret.^[3] Its artifacts are the assembled context, the tool schemas and the orchestration policy. The point people most often get wrong is variability: the randomness of sampling can be removed with deterministic decoding, but drift from retrieval and from model-version changes cannot. When this layer breaks, it breaks as hallucination, drift and prompt injection — and diagnosis needs the full invocation trace, because the failure may not recur under resampling.^[1]

The paper's Table 3 lays the three layers side by side across five dimensions. I condense its essentials here — this table is the backbone of the layer map we build in section 3.

The word not to miss when reading that table is stacked, not replaced. One refund request: a FastAPI route (1.0) receives the message; the assembly code (1.0) calls retrieval, which leans on an embedding model (2.0) to pull passages from the corpus and compose them into a context (3.0); M_v (2.0) interprets it; the result may be a tool call that must pass its schema (3.0) before the refund() code (1.0) creates the real effect — three eras trade control of one path several times inside a few hundred milliseconds.

The 1.0 layer never disappears — and must never be allowed to

The paper is explicit about this and I want to repeat it: however "3.0" a system becomes, era-1.0 code still holds the three things the whole system depends on — control flow, the interfaces, and the mediation of every effect.^[1] The thing that decides whether a tool call is authorised, the thing that validates the schema, the thing that writes the trace — all of it is explicit, human-written code, tested the 1.0 way and reviewed the 1.0 way. Every guard and every rail this series builds in the later posts is first-era software.

💡 My view: the way to catch a team that believes it has "moved to Software 3.0" is one question — if the guard around refund releases a transaction tomorrow that it should not have, who fixes it, and in which file? The answer is always an engineer and a .py file, never a prompt engineer and a dashboard, because what failed was not the model's capability but 1.0 code we did not write tightly enough. A team that stops investing in its 1.0 layer because it feels "legacy" is tearing up the floor it is standing on.

2. The Leverage Moves — Imperative, Declarative, Intentional

The conclusion of this section: what changes across the three eras is not "the language you write in" but where the engineer's leverage sits — on control flow in 1.0, on the dataset and the loss in 2.0, and on runtime context in 3.0, the work the paper names context engineering.^[1] Misjudge where the leverage is and the whole project pushes in the wrong place.

The move is sharpest through the lens of "how behaviour is specified". In 1.0 we write imperatively — telling the machine what to do, step by step. In 2.0 we write declaratively — declaring an objective over a dataset and letting the optimiser find the function. In 3.0 we write in the mode the paper calls intentional — declaring the four things below and delegating the synthesis of that part of the behaviour to the model core.^[1] Karpathy drew the same picture in his 2025 talk: software is changing again, and a growing share of programs is now "written" in natural language fed to a model.^[3]

• Intent — what the system is trying to do, for whom, under which rules — for Nong Kram, the system prompt that defines the role, the scope and the tone
• Exemplars — what a good answer looks like — golden examples of the conversations we want to see repeated
• Grounding knowledge — the facts an answer must rest on — the policy corpus in policy/ and the catalogue in catalog/
• Permitted actions — the only ways the system may touch the world — the refund tool schema declaring its parameters and bounds in advance

The disciplinary consequence of this picture is the most expensive point of the whole post: prompts, the retrieval corpus, golden examples and eval suites are behaviour-determining artifacts alongside the code — one changed line in the system prompt shifts the system's behaviour as much as, or more than, one changed function — so they must receive the full discipline code gets: version control, review before merge, and test suites of their own.^[1] This is what Nong Kram's repo looks like after accepting that fact.

# Nong Kram's repo layout — 3.0 artifacts beside the code, under the same discipline
kramkraft-assistant/
├── src/                    # 1.0 — control flow, interfaces, mediation
│   ├── api/routes.py       #   chat endpoints for web and LINE
│   ├── tools/refund.py     #   the effectful part — creates real effects
│   └── context/assemble.py #   the context-assembly code
├── prompts/
│   └── system.th.md        # 3.0 — determines behaviour, as much as code does
├── policy/                 # 3.0 — return-policy and shipping corpus
├── catalog/                # 3.0 — product-page snapshot
├── schemas/
│   └── refund.json         # 3.0 — the boundary of the tool call
├── eval/
│   └── golden.jsonl        # 3.0 — the golden set for the top task
└── manifest.lock           # pins everything together (post #4's subject)

But the paper's next line matters just as much, and is the one most often skipped: these artifacts do not become the source code. Code retains the control flow, the interfaces and the mediation everything depends on.^[1] A prompt is code's equal in discipline, not code's replacement in function — text in the context is advice to the model, not a constraint on the system, and that dividing line is the reason post #8 has to exist.

💡 My view: the shorthand rule I use with my teams is a single sentence — "anything that changes the system's answer when you edit it is the program, and belongs under the program's discipline." Walk your files with that sentence and the list of artifacts that need versioning comes out roughly twice as long as most teams expect — especially the ones hiding in a vendor dashboard, where an edit leaves no trace at all.

3. The Seven Steps

The output of these seven steps is a layer map — one file that answers which artifact sits in which era, where it is versioned, and what it looks like when it breaks — which becomes the team's first triage tool and the base every later post builds on. Every step walks with Nong Kram as the live example.

Step 1 — Inventory every artifact in your repo and your runtime

Open a two-column ledger: the first column is everything git ls-files can see; the second is everything that determines behaviour at runtime but does not appear in that command's output. The second column is the real point of this step, because nearly every AI-core system has most of its behaviour living outside the repo without the team noticing. Nong Kram's first pass came out like this.

$ git ls-files          # the in-repo side — visible, diffable, reviewable
src/api/routes.py  src/tools/refund.py  src/context/assemble.py ...

# The side that determines behaviour but is absent above — write down all of it:
#  1. system prompt       -> edited in the vendor's dashboard
#  2. retrieval top-k     -> set in a console three months ago, value forgotten
#  3. catalog             -> exported by hand from the backoffice every month
#  4. version of M_v      -> pointing at "latest", not pinned

Step 2 — Assign each artifact to an era

Walk the ledger from step 1 and label every row with its era, Table 3 in hand: the label immediately says which discipline the artifact needs, how it is tested, and how it will fail. The labelling rule is straightforward.^[1]

• 1.0 — code and config that hold control flow: the routes, the context assembler, refund(), the validators — for Nong Kram, everything under src/
• 2.0 — weights and embeddings: the version-pinned model M_v and the retrieval embedding model — we did not train them, but they are our system's 2.0 layer all the same
• 3.0 — prompts, corpus, tool schemas and orchestration policy: prompts/system.th.md, policy/, catalog/, schemas/refund.json, and the rules for when a refund may be proposed

Step 3 — Find the behaviour-determining set for your top task

Pick your single most important task and ask, artifact by artifact: "if I edit this, does the answer to this task change?" The set of artifacts that answer yes is the behaviour-determining set — the real program of that task. Nong Kram's top task is "answer refund eligibility correctly against policy", and its set is: the system prompt, the corpus in policy/ together with its snapshot, the retrieval config, the version of M_v, the decoding config, and schemas/refund.json — while the logging code, the site's CSS, and even catalog/ are outside this task's set (though catalog/ is inside the set of the "answer product questions" task). Knowing the set per task matters because it tells you which task's regression tests must run when which file changes.

Step 4 — Mark where your engineering leverage actually is

Most systems this series' readers operate use a frozen hosted model — the weights are not ours to edit, which means the 2.0-era leverage is not ours. What actually moves is two layers: the 3.0 layer (prompt, corpus, retrieval config, exemplars) for shaping behaviour, and the 1.0 layer (mediation, validation, routing) for bounding the damage. For Nong Kram I wrote the repair order straight into the document: on a wrong answer, look at the corpus first, then the retrieval config, then the prompt — and a model-version change is a release that reruns the whole golden set, never a hotfix, because behavioural evidence about a context is tied to the model version that interprets it.^[1]

Step 5 — Mark what is versioned today and what is floating

Return to the step-1 ledger and draw the line: what is versioned, and what is "floating" — editable with no diff, no review and no way back. The sentence I want remembered from this step: a prompt edited in a dashboard is a program change nobody reviewed. It is a deploy with no record, and on the day the system's behaviour changes mid-week there will be no evidence of who changed what. Nong Kram closed this hole in one morning.

$ mkdir -p prompts schemas
$ # paste the latest dashboard text into files — the repo is the source of truth now
$ git add prompts/system.th.md schemas/refund.json retrieval.yaml
$ git commit -m "Move behaviour-determining artifacts into the repo"
$ # new rule: the dashboard is a read-only mirror; deployment reads from the repo only

Step 6 — Learn each layer's failure signature, and the evidence its debugging needs

The three layers break in three different ways and need three different kinds of evidence to diagnose. A team that cannot tell the three signatures apart will debug the wrong layer every time — the classic symptom is three days spent reading code hunting a "bug" that is really a corpus older than the actual policy. Drill the classification with three invented Nong Kram incidents.^[1]

• A 1.0 case — bug: refund() rounds satang incorrectly; every order ending in .50 reproduces it, one hundred percent of the time — the evidence needed: a stack trace and one unit test
• A 2.0 case — poor generalisation: the embedding model retrieves the wrong passages when customers write "indigo glaze" one way rather than another — the evidence needed: a data snapshot of real queries and a recall metric, not a stack trace, because nothing throws
• A 3.0 case — hallucination: Nong Kram invents a "returns within 45 days" condition that exists in no policy anywhere; ten reruns reproduce it twice — the evidence needed: the full invocation trace of the failing run — the context actually assembled, the passages actually retrieved, the raw output — because resampling may never show the symptom again

Step 7 — Write the layer map as a living document

Fold every step into one table in docs/layer-map.md: one row per artifact, four columns — name, era, where it is versioned, failure signature — plus a behaviour-determining-set heading per top task. Then wire it into the workflow: any PR that adds a new behaviour-determining artifact must add its row to the map before it can merge. A document that does not grow with the system turns into fiction within a quarter — and Nong Kram's full map is the next section.

4. Nong Kram's Layer Map

This is the post's artifact in full — KramKraft's docs/layer-map.md after walking all seven steps: thirteen rows, three eras. Copy the skeleton directly (the numbers and file names are the tutorial's, not the paper's).

The map showed the KramKraft team two things on day one. First — the two most behaviour-determining artifacts in the system (the system prompt and the retrieval config) had both been floating outside the repo. Second — the shop's top task depends on era-3.0 artifacts in seven of the thirteen rows, which means the existing 1.0-style tests covered less than half of the system's real behaviour. The 40-case golden set (a tutorial number) is seeded in this post, and gets worked hard in post #9.

5. Validation Check — Audit Your Own Layer Map

The paper's rule, applied in every post of this series: every audit question must be answered with an artifact you can produce, never with an adjective.^[1] Run these seven against your own system — any row with nothing to show is a fail, however confident the team feels.

6. The Road Ahead

This post delivers one tool that is simple but changes how the team talks: a layer map that says where the system's behaviour lives, who versions it, and what it looks like when it breaks. The three eras of software are not period labels to pick a side over — they are three layers of one system, each demanding its own discipline, and knowing which layer the incident in front of you belongs to is the first half of fixing it in the right place.

What this post deliberately does not answer is where our old guarantees break down. We now know the 3.0 layer fails as hallucination and prompt injection, but we have not yet explained what structural property of the model core makes those failures possible in the first place. That answer needs another mental model: treat the AI core as an operating system — the weights as a CPU, the context window as RAM with no memory protection, retrieval as a file system with no stable read contract — and then walk the seams where the analogy cracks. That is the whole of #3 The AI-OS Mental Model.