The Dual Essence of Code: Instructions, Models, and the Future with AI

Overview

In an era where artificial intelligence agents increasingly generate code, a fundamental question emerges: will traditional source code disappear? To navigate this future, we must first grasp what code truly is. Code is not merely a list of commands for a computer; it is a dual-purpose artifact. It serves as both precise instructions to a machine and a conceptual model of the problem domain. This tutorial unpacks these intertwined roles, explores how programming languages function as thinking tools, and examines how this understanding shapes our work with large language models (LLMs). By the end, you will have a robust framework for thinking about code—past, present, and future.

The Dual Essence of Code: Instructions, Models, and the Future with AI — Source: martinfowler.com

Prerequisites

A basic familiarity with programming (any language will do).
Curiosity about the philosophical and practical nature of code.
No prior experience with LLMs is necessary, but general awareness helps.

Step-by-Step Guide to Understanding Code’s Dual Purpose

Step 1: Recognize Code as Machine Instructions

At its most straightforward, code tells a computer what to do. Every instruction—whether it’s ADD, MOVE, or PRINT—is a direct command that the machine’s hardware or virtual machine executes. This is the instructional layer. It is precise, unambiguous, and low-level enough that the computer can follow it deterministically.

Example in pseudocode:

SET temperature = 25
IF temperature > 20:
    PRINT "It's warm"
ELSE:
    PRINT "It's cool"

Here, each line is a pure instruction: assign a variable, evaluate a condition, output text. The machine does not understand warmth—it merely reacts to bits.

This instructional nature makes code executable. Without it, the computer cannot operate. Yet, focusing solely on instructions misses half the picture.

Step 2: Understand Code as a Conceptual Model

Code also embodies a conceptual model of the problem domain. When a developer writes code to manage a library, they create abstractions like Book, Member, and Loan. These are not instructions per se; they are conceptual building blocks that reflect real-world entities and relationships.

Example in object-oriented style:

class Book:
    title: String
    author: String
    isAvailable: Boolean

class Member:
    name: String
    borrowedBooks: List<Book>

This code models the domain. It helps the developer reason about the problem: a member can borrow a book only if the book is available. The model constrains what instructions are later written. It is a thinking tool, not just a set of commands.

The two purposes are intertwined. The model influences the instructions (e.g., you call borrow() only on an available book), and the instructions realize the model. To understand code fully, you must hold both aspects simultaneously.

Step 3: Explore Programming Languages as Thinking Tools

Programming languages are not just syntax; they are abstraction engines that shape how you think about a problem. High-level languages like Python, Ruby, or Haskell allow you to express the conceptual model more directly. Low-level languages like C or assembly force you to stay closer to machine instructions.

Why does this matter?

Languages with strong type systems (e.g., Haskell, TypeScript) help you encode domain invariants at compile time.
Functional languages encourage modeling with immutable data and pure functions, reducing mental complexity.
Object-oriented languages promote modeling with interacting objects, mirroring many real-world systems.

Each language “thinks” differently. The choice of language affects both the instructions you write and the model you hold. This cognitive dimension is why code is more than a mechanical recipe—it is a medium of thought.

Step 4: Apply This Understanding to LLMs and the Future of Code

When we delegate code writing to LLMs, we are outsourcing the instructional layer. The AI generates syntactically correct commands. However, the conceptual model—the problem domain understanding—must still be communicated, often via prompts, specifications, or examples.

Key insight: If you only provide instructions (e.g., “write a function that sorts a list”), the LLM will generate instructions without a deep model. The resulting code may work but be brittle or unmaintainable. But if you first articulate the domain model (e.g., “We have a list of orders. Each order has a priority and a date. We need to sort by priority first, then by date.”), the LLM can generate code that aligns with that mental model.

Practical advice:

When prompting an LLM, describe the concepts and relationships, not just desired outputs.
Review LLM-generated code for conceptual consistency, not just syntax.
Treat the LLM as a co-architect of the model, not just a code typist.

In the future, source code might not be the primary artifact—but the conceptual model will persist in documentation, schemas, or even latent within the LLM’s training. Understanding the dual nature of code prepares you to work with, not against, these shifts.

Common Mistakes

1. Treating Code Only as Instructions

Newcomers often view code as a series of steps. They forget that the structure and naming of those steps create a model. This leads to spaghetti code where the domain is obscured. Always ask: “Does this code explain the domain as much as it commands the machine?”

2. Ignoring the Cognitive Load of Language Choice

Choosing a language based solely on popularity or job market neglects how that language affects your thinking. For domains with complex state, functional languages may reduce bugs. For CRUD apps, OOP may be more intuitive. Evaluate your conceptual needs before picking a syntax.

3. Over-Reliance on LLMs Without Domain Context

When using LLMs, many developers copy-paste prompts that lack domain specifics. The resulting code often works in isolation but fails to integrate with the larger conceptual model. Always provide context about entities, relationships, and constraints.

4. Confusing Model with Implementation

It’s easy to think that the code is the model. In reality, the same model can be implemented in multiple ways. A library system can be written in Python, Java, or even SQL. The model survives translation. Focus on preserving the model’s integrity when refactoring or porting code.

Summary

Code is not monolithically “instructions.” It serves two critical purposes: machine instructions and conceptual model. Programming languages are thinking tools that shape how we model problems. As LLMs take over instruction generation, our role shifts to nurturing the model—through clear prompts, domain descriptions, and careful review. By embracing the dual essence, you future-proof your understanding of code and harness AI more effectively.

Remember: code is what machines execute, but it is also what humans understand. Both matter.