Software 3.0 Compared With Code and Trained Models
Compare Software 3.0 with explicit code and trained models on predictability, testing, and project continuity before choosing an approach.
You need to add a feature, and there are several ways to make it work. You could write explicit rules, use a trained model, or give a language model instructions. The choice turns on how predictable the result must be, how you can check it, and what someone will need to understand when they return to the project. Software 3.0 is a useful name for that last approach, but it does not make the other two obsolete.
Software 1.0, 2.0, and 3.0 on the same criteria
These labels describe where a program's behavior comes from. Software 1.0 uses rules written in code. Software 2.0 gets some of its behavior from learned model parameters. Software 3.0 uses natural-language instructions to direct a language model. An AI tool that writes conventional code can help you build Software 1.0; the generated code does not become a prompt-driven feature merely because AI wrote it.
| Criterion | Explicit code, or Software 1.0 | Trained models, or Software 2.0 | Language-model instructions, or Software 3.0 |
|---|---|---|---|
| Behavior | Rules are specified in code | Behavior is learned from data | Behavior is guided by instructions and context |
| Checking a change | Run tests against the changed rules | Evaluate outputs against representative cases | Test outputs, edge cases, and the instructions supplied |
| Resuming work | Read code, tests, and change history | Revisit model choices and evaluation results | Recover the prompt, context, observed result, and decision |
| Good starting point | A rule with a clear correct answer | A recurring pattern supported by suitable data | A language task whose outputs you can review |
The categories can coexist in one app. A small SaaS might use code to enforce account permissions, a trained model for a prediction, and language-model instructions to draft a user-facing summary. The important comparison is the behavior of each feature, not the tool used to build it.
Choose explicit code when the answer must be exact
Suppose an internal tool lets an account owner invite teammates. The permission check should have a definite outcome. You can express that rule in code and test an owner account alongside a non-owner account. A language model can help you write the implementation, but its generated change still needs a diff review and a test of the authorization path.
For a closer review of permission checks and other safety boundaries, see this guide to security risks in AI-generated code.
Explicit code also gives you a clear place to inspect when a rule changes. Its drawback is that someone has to specify and maintain the rule. For a well-defined permission check, that work buys you useful control. For an open-ended request such as summarizing a messy support message, enumerating every acceptable response in code is much less practical.
Choose a trained model or Software 3.0 for less rigid inputs
A trained model fits a task when you have an appropriate model and a way to evaluate its performance on the inputs that matter to you. A prompt-driven feature fits a different kind of uncertainty: you can describe the job in language, supply relevant context, and review whether the output is useful. Neither choice makes testing disappear. Their outputs need examples that include awkward inputs, failures, and cases where the system should decline to act.
For a support-message summary, you might ask a language model to extract the customer's issue and proposed next action. Keep any consequential action, such as changing account access, behind explicit checks. If the summary misses a key detail, save the input, the instruction that produced it, and the correction. That record gives you something concrete to improve instead of another attempt from memory.
Pick the approach you can verify and resume
For a fixed business rule, start with code even if AI helps write it. For a recurring prediction task, evaluate whether a suitable trained model meets your needs. For a reviewable language task, try instructions and test them on representative cases before relying on the output. A feature that mixes these approaches should make the boundary clear: identify which part generates a suggestion and which part decides what the app is allowed to do.
Software 3.0 introduces a particular continuity problem. A useful instruction can be scattered across chat history, while the codebase shows only part of why the feature behaves as it does. At the end of a build session, keep the instruction, one observed result, the decision you made, and the next test together. If the instruction later fails, you can revise the feature from evidence rather than reconstructing the conversation.
Keep the reasoning with the project
Before your next session, write a short note for the feature you just touched. Name its source of behavior, how you checked it, and what remains uncertain. That is enough to help you choose the next change without slowing down the current one. For prompt-driven work, keep your tested instructions and build notes in VibeCrumbs.