Code Is a Conceptual Model: Joshi's Thoughtworks Frame Ratifies the Harness

Unmesh Joshi, a principal consultant at Thoughtworks, published What Is Code? on Martin Fowler’s site on May 12, 2026. The byline matters because the piece is hosted on martinfowler.com but written by Joshi, and the argument carries Thoughtworks’ delivery weight, not Fowler’s personal column. The thesis lands clean: “Code is still instructions for a machine. But it is also a model of understanding. In the LLM era, that second role becomes even more important.”

We have been saying the same thing for a year, with a different word. Joshi calls it conceptual model. We call it the harness. The piece is the canonical Thoughtworks-stamped version of an argument we have been making in essay form, and it deserves a careful read because of where it leaves the verification question.

The Two Roles of Code

Joshi opens with the split that organizes the rest of the piece. Code has always had two simultaneous roles. The first is mechanical: instructions for a machine. Source files are compiled or interpreted, the CPU executes, the network responds. The second is conceptual: a model of the problem domain expressed in a notation precise enough to be checked by a compiler and read by a human.

For most of software’s history these two roles were welded together. You could not separate them because you could not afford to. Writing the conceptual model was the same act as writing the instructions, and the cost of the second role was paid by doing the first carefully.

LLMs break that welding. The first role, writing instructions, is what models are good at. They can produce working code from a sufficiently specified prompt in seconds. The second role, building the conceptual model, is something they accelerate but do not replace. The model still has to be correct, coherent, and aligned with how the business actually works. Someone has to verify that.

Joshi’s framing is that the first role is being commoditized and the second role is becoming more valuable. The center of gravity in software engineering moves from typing to modeling.

TLA+, DSLs, and Domain Concepts

The examples Joshi works through are specific, and they matter. He shows TLA+ pseudo-code expressing snapshot isolation more clearly than the equivalent verbose Java. The Java compiles. The TLA+ does not, in the production sense. But the TLA+ is the conceptual model. It is what you read when you want to understand whether the algorithm is correct. The Java is what runs.

He walks through DSL construction next. A well-designed DSL gives you an English-like interface sitting on top of a stable abstraction layer. The DSL is the conceptual model exposed to the user. The abstraction layer underneath is the instructions to the machine. When teams build a good DSL they are explicitly separating the two roles, and the separation is what makes the system usable.

Then he gets to domain modeling. The retail example maps catalog concepts onto web constructs: GET, POST, PUT, DELETE on Catalog resources. The mapping is the conceptual model. The HTTP handlers are the instructions. A team that gets the mapping wrong can write perfectly functioning HTTP handlers that solve the wrong problem.

Each example is a way of pointing at the same observation. The valuable artifact is the model, not the instructions. The instructions are downstream.

Tests and Types as Guardrails

This is where Joshi’s piece does the work that ratifies our position. He reframes tests and types. They are not, in this frame, primarily about correctness in the classical sense. They are about model accuracy. A type system encodes a model of valid states. A test encodes a model of expected behavior. Together they are the artifacts that say “the conceptual model is supposed to look like this.”

In the LLM era, that role flips from convenience to load-bearing. When a model generates code, the question is not whether the code compiles. Models produce compiling code by default. The question is whether the generated code matches the conceptual model the team has in its head. Tests and types are the only sustainable way to answer that question at velocity.

Joshi writes about this as guardrails for model accuracy. We have been writing about it as verification infrastructure. The substance is the same. When AI commoditizes the first role of code, the second role demands a substrate that can verify it, and that substrate is exactly the discipline most teams already half-have and have been treating as overhead.

The Cross-Walk to the Harness

Worth being precise about the mapping because the vocabularies converge but do not collide.

Joshi’s “conceptual model” is what lives in our harness as the encoded shape of the work: the types, the test cases, the schema, the domain glossary, the architectural constraints. His “vocabulary” maps to what we have called the cross-discipline vocabulary that travels with the work between marketing, design, legal, and engineering.

Joshi’s “tests and types as guardrails” is exactly what we have called the verification layer. His framing emphasizes accuracy of the model; ours emphasizes reproducibility of AI-assisted output. These are the same property viewed from two angles. A model that cannot be verified will drift; output that cannot be verified cannot be reproduced.

Where our framing adds something Joshi’s piece does not push on: we treat the conceptual model as an artifact under active governance, with ownership, versioning, and change control. Joshi treats it as a quality attribute of the code. The Thoughtworks delivery culture has those governance habits baked in, so the piece can take them as given. For teams without that baseline, the operational question is how the conceptual model gets maintained when no one owns it.

Why the Byline Matters

A note on attribution. The piece is published on martinfowler.com and will be shared with Fowler’s name attached. That is a misattribution. Joshi is at Thoughtworks. Fowler is Thoughtworks’ Chief Scientist. The site is Fowler’s, the lineage is Thoughtworks, and the author is Joshi.

This matters because the argument is institutionally backed. When a Thoughtworks principal publishes on their Chief Scientist’s site that “code is a conceptual model of understanding, and tests and types are guardrails for that model in the LLM era,” it is not one writer’s hypothesis. It is the practitioner consensus of a firm that has been shipping AI-augmented delivery work at scale for two years. Citing it as Joshi keeps the institutional weight intact. Citing it as Fowler turns it back into a personal essay, which it is not.

What to Do Now

Three actions for teams reading this.

Audit the conceptual model surface in your codebase. The types, the schemas, the domain glossary, the test contracts. List them. If they are not explicit artifacts that someone owns, the LLM era has already raised your verification cost and no one is paying it.

Reframe test and type investment internally. The narrative inside engineering teams has been “tests slow us down, AI makes us faster.” Joshi’s piece reverses the polarity. Tests and types are what let AI velocity convert into reproducible output. The reframe is rhetorical but it changes budget conversations.

Read Joshi directly, not the second-hand summaries. The piece is short and the examples carry the argument. The summaries will lose the TLA+ example, which is the load-bearing one for anyone arguing the case to an engineering leader.

The vocabulary is still multiplying. Conceptual model, harness, structured prompt, model accuracy, verification substrate. The thing they all point at is the same. Code’s second role is now the surface where AI value either accumulates or evaporates, and the teams that build artifacts for that surface will be the ones whose AI investments compound.

This analysis builds on What Is Code? by Unmesh Joshi (Thoughtworks), published on martinfowler.com, May 2026.

Victorino Group helps teams build the conceptual models, vocabularies, and verification layers that make human-AI collaboration safe at scale. Let’s talk.