Design and Architecture according to Claude (Sonnet 4.6 High on June 17th, 2026)

>Salut Claude! In the past, I've read, come up with, and used various definitions of software design and software architecture, including but not limited to the incorrect use of "architect" as a verb. How would you relate "design" (verb), "design" (noun), "designer" (noun), "architecture" (noun), and "architect" (noun) to each other in the context of software development?

Salut Paul! This is a genuinely interesting question about language – and about how imprecise vocabulary in a field can blur real conceptual distinctions. Let me lay out how I’d relate those five terms, then draw it.

The core relationship is that design (the verb) is the activity, and everything else flows from it.

When you design something, you engage in a process of making decisions under constraints – shaping a system to satisfy some goals. “To design” is fundamentally deliberate choice-making: choosing what to build, how to structure it, what to leave out. In software, this applies at every scale, from a class to a system of systems.

Design (the noun) is the artifact or outcome of that activity – the set of decisions made, whether recorded explicitly or just embodied in the code. Every piece of software has a design; only some have a documented design. Design-as-noun can also refer to a plan (design before implementation) or a description (design after the fact, reverse-engineered or documented).

Architecture (the noun) is a subset of design. It’s specifically the design decisions that are hard to reverse, that cut across concerns, or that establish the fundamental structure of a system – the bones, not the flesh. Not all design is architectural, but all architecture is design. The distinction is about significance and reversibility: choosing between a layered monolith and an event-driven microservice mesh is architectural; choosing a method name is design but not architecture.

Designer and architect (both nouns) are roles – people who perform design at different scopes or levels of abstraction. A designer might own a module, a component, or an interaction. An architect typically owns the cross-cutting structural decisions. In practice, the boundary is fuzzy and organizational, not technical.

As for “to architect” as a verb: it’s a back-formation that grates because “architecture” already has a perfectly good verb – to design. Saying “we architected the system” just means “we designed the system’s architecture.” The verb form adds nothing except a claim to seniority.

A few things worth highlighting from the diagram:

Architecture being nested inside design (not parallel to it) is the key structural insight. When people contrast “design” and “architecture” as if they’re the same level of abstraction, they’re already confused. Architecture is a kind of design – the high-stakes, load-bearing kind.

The roles (designer, architect) are dashed-arrow derivations from the verb: they’re what you call someone who habitually performs the activity at a certain scope. That’s why “architect” as a verb is redundant – the noun role already implies the verb “to design.”

One useful test for whether a decision is architectural: “If we got this wrong and wanted to change it in year 3, how painful would that be?” A naming convention – unpleasant but tractable. Switching from synchronous request/response to an event-driven model – deeply structural, probably involves rewriting large swaths of the system. The latter is architectural; the former is design but not architecture.