Embracing the Software 3.0 Era

Software 3.0 replaces hand-written rules with natural-language instructions to LLMs, but models alone cannot reliably perform real-world work. The missing piece is the harness: tools, context, and environments that connect an LLM to codebases, commands, databases, and users. Claude Code illustrates how familiar Software 1.0 architecture can guide agent design while adding a new capability—asking humans for judgment when uncertainty arises.

From Software 1.0 to Software 3.0

• Software 1.0: Developers explicitly write logic using languages such as Python, Java, or C++.
• Software 2.0: Data and training produce neural-network weights that function as the program.
• Software 3.0: Prompts and natural-language instructions direct LLM behavior.
• Karpathy’s central claim is that Software 3.0 is increasingly absorbing both traditional code and trained models.

Harnesses Make LLMs Useful

• A raw LLM cannot independently read a codebase, execute commands, modify files, or access databases.
• A harness supplies the tools and environment needed to turn model capability into practical work.
• Claude Code is presented as a harness for Claude: it transforms a language model into an agent capable of completing and shipping tasks.

Mapping Agent Concepts to Layered Architecture

The terminology of agent systems can be understood through familiar Software 1.0 design patterns:

• Slash commands → Controllers
  • They serve as entry points for user requests, such as /review or /refactor.
• Sub-agents → Service layer
  • They coordinate multiple skills to complete a workflow.
  • Each sub-agent has an independent context and acts as a self-contained unit of work.
• Skills → Domain components
  • Each skill should have one focused responsibility, such as reviewing code, generating tests, or writing documentation.
• MCP → Infrastructure or adapters
  • MCP provides abstraction boundaries for external systems such as APIs and databases.
• CLAUDE.md → Project constitution
  • It records stable project information: technology choices, conventions, and build commands.
  • Frequently changing task details should be provided through the conversation or injected into an agent’s context instead.

Agent Design Has Familiar Anti-Patterns

Traditional code smells also apply to agent systems:

• Feature Envy: A skill relies excessively on another skill’s data.
• Duplication: Prompts are copied across multiple skills.
• Long Method: A single sub-agent performs an overly long sequence of many skills.
• Clear boundaries, single responsibility, and limited coupling remain valuable.

The Difference: Agents Can Ask Humans

Layered architecture generally requires every failure and edge case to be handled through predefined exceptions, policies, or branches.

• Traditional code must decide what to do when an unusual case occurs.
• An agent using human-in-the-loop interaction can pause and ask the user for clarification.
• In this model, exceptions become questions, allowing the agent to continue after receiving a decision.

Agents should ask when:

• An action is difficult to reverse, such as deletion or deployment.
• Several valid options exist without a clear best choice.
• The decision has significant consequences.

They should proceed automatically when:

• The operation is safely repeatable.
• Existing conventions provide a clear answer.
• The action is easy to undo.

What Carries Forward into Software 3.0

The new paradigm does not make established engineering practices irrelevant.

• Move away from explicitly coding every possible rule and edge case.
• Do not reduce LLMs to simple autocomplete tools.
• Preserve layered design, single responsibility, abstraction, dependency management, and interface design.
• Continue emphasizing testability, debugging, code review, and iterative improvement.

The practical approach is to combine Software 3.0’s flexible reasoning with Software 1.0’s architecture and engineering discipline, while giving agents a clear way to involve humans when decisions require judgment.