Development 101

Vibe coding is computational design without the design.

Computational design treats the system that produces the work as the thing you design: rules, inputs, and constraints, with any single output as one provisional state. Vibe coding quietly made this every product team’s practice. Most teams just haven’t authored their system yet.

The term names something more specific than "design that involves computers." Computational design moves authorship upstream: instead of drawing the artifact, you write the process that draws it. The artifact becomes an output, one of many, and provisional by definition.

The person who carried that idea from the MIT Media Lab into the tech industry was John Maeda, who spent his Design in Tech years arguing that computational design is a third kind of design, distinct from classical design and design thinking. Then 2025 gave Silicon Valley a name for generating software without reading it: vibe coding. The two frames describe the same condition from opposite ends, and any team shipping UI through Cursor, Claude Code, or v0 is now living in it. The open question is whether anyone authored the system they are running.

The definition

Computational design is the practice of designing processes instead of artifacts. The designer authors a system: rules, parameters, inputs, and constraints. The system produces the outputs. Any single output is a provisional state of the running process, not the finished work. The work is the system.

Three things change when you design this way. Authorship moves upstream, from the artifact to the logic that generates it. Variation becomes expected rather than accidental: two runs of the system may differ, and both are correct if the rules held. And quality is judged across outputs, not on one of them. A system that produces one good screen and nine drifting ones is a bad system, however good the one.

The discipline is in the constraints. An unconstrained process produces noise; a well-constrained one produces variation inside a recognizable language. Constraints are not the opposite of exploration here. They are what makes exploration legible enough to evaluate.

The MIT heritage

The lineage runs through one building in Cambridge. Muriel Cooper founded the Visible Language Workshop at MIT and spent the eighties asking what graphic design becomes when the medium computes. John Maeda, an engineer turned designer, carried the question into the MIT Media Lab, where his Aesthetics + Computation Group treated code as a design material rather than a production tool; his 1999 book Design By Numbers taught designers to program as a creative act. Two of his students, Casey Reas and Ben Fry, turned that teaching into Processing, the language that gave a generation of designers their first running system. Sol LeWitt had shipped wall drawings as written instructions back in 1967; the Media Lab gave that idea a compiler.

Maeda then did the thing that matters for this audience: he took the term to the tech industry. In his Design in Tech reports, delivered at SXSW from 2015 to 2019 while he moved between venture capital and design leadership, he separated three kinds of design. Classical design makes perfect, finite objects. Design thinking navigates organizations. Computational design is design for systems that are alive: shipped incomplete on purpose, instrumented, revised in real time, serving millions of people concurrently. His argument was that the third kind was the scarce one, and the one the industry actually runs on.

In 2017 that description fit a handful of companies with billion-user products. What changed since is distribution. The condition Maeda described, products that are never finished, produced by processes rather than drawn by hand, stopped being a big-company property the moment code generation got cheap.

The taxonomy

The practice is one thing, but it divides along three axes: how the rules are authored, what the system does with its output space, and what substrate executes the logic. Any concrete method is a position on all three at once.

Computational design

Rule authoring asks what kind of system you write. Parametric design fixes the structure and exposes the values: a facade whose panel angles track the sun, a type scale derived from one ratio. Algorithmic design makes the procedure the designed thing, the way a Processing sketch is. Procedural design writes seeded rules that generate at scale, the technique behind game terrain and every rendered city no artist drew by hand.

Search behavior asks what the runs are for. Optimization converges: state a measure, and the process narrows toward the output that scores best against it. Generative work diverges: the process produces many candidates, and judgment picks among them. Substrate asks who wrote the logic. Explicit systems run rules a person authored, from a Grasshopper graph to a token file. Learned systems run a model, and the rules live in its weights. The learned column is the newest, and it is the one your team is already running.

The unauthored system

In February 2025 Andrej Karpathy named the new default: vibe coding, where you "fully give in to the vibes" and forget the code exists. The name is playful; the structure underneath is exactly what this post has been describing. A team prompting Cursor, Claude Code, or v0 is running a generative system whether it means to or not. The model is the process. The prompt, the codebase, and whatever context fits the window are the inputs. Each generated screen is a provisional output, shaped by input, parameters, and time, reproducible never.

Which means vibe coding is computational design with the authorship step skipped. Maeda’s designers wrote their own systems, so variation stayed inside a language they chose. A vibe-coded product inherits its constraints from the model’s training distribution, which is to say from everyone else’s interfaces. The thresholds and defaults embed someone’s intent; when nobody on the team authored them, the intent embedded is nobody’s.

Drift, in this frame, is not the model misbehaving. It is a computational process doing what unconstrained processes do: varying. The greys multiply and the spacing wanders not because the agent is sloppy but because no rule made those dimensions invariant. We wrote about the broader shift in the AI era essay; the computational-design lens sharpens the diagnosis. You do not have a generation problem. You have an authorship problem.

The design system is the program

If the work is the system, then the design artifact worth authoring is the one the process actually reads. This is where the computational-design tradition and the current tooling meet. Tokens are parameters. Usage rules are constraints. Checks are assertions that a given output stayed inside the language. A design system written for human eyes documents the rules; a design context layer makes them executable, present at generation time, inside the loop that produces the output.

Aestheria, the design context layer, is that program in shippable form: 443 tokens with usage rules, components and patterns meant to be reused rather than approximated, and skills that encode when a table beats a card grid and when a confirm step is required. The point of the frame is what it changes about the day: you stop correcting outputs and start editing the system, and the correction propagates to every screen generated after it.

Computational design spent two decades as a Media Lab thesis and a conference-deck category. Its posture, author the system, constrain it until behavior is legible, judge outputs as states rather than verdicts, turns out to be the right one for any team whose screens are now generated. Maeda was early. The condition is general.

Questions

What is computational design in simple terms?

Computational design is designing the system that produces the work instead of the work itself. The designer writes rules, sets constraints, and chooses inputs; a process, usually running as code, generates the outputs. Any single output is one state of the system, not the final artifact.

What is the difference between computational design and generative design?

Generative design names the technique: a process produces many outputs, often with randomness or optimization involved. Computational design names the practice: authoring rules, constraints, and inputs as the primary design act. A generative system is one thing a computational designer builds.

What are the types of computational design?

Computational design divides along three axes. Rule authoring separates parametric design (fixed structure, varying values), algorithmic design (the procedure is the designed thing), and procedural design (seeded rules that generate at scale). Search behavior separates optimization, which converges on one best output, from generative work, which diverges into many candidates. Substrate separates explicit systems, running rules a person wrote, from learned systems, running a model. Any concrete method is a position on all three at once.

What did John Maeda mean by computational design?

In his Design in Tech reports, John Maeda distinguished computational design from classical design and design thinking. Classical design produces perfect, finite objects; computational design is design for living systems: products shipped incomplete on purpose, instrumented, revised in real time, and serving millions of people at once. He argued it is the kind of design the tech industry actually runs on.

Is vibe coding a form of computational design?

Structurally, yes. Vibe coding runs a generative process: the model is the system, the prompt and codebase are inputs, and each generated screen is a provisional output. The difference is authorship. Computational design authors the rules and constraints deliberately, while vibe coding inherits them from the model’s defaults. Encoding your own rules closes that gap.

Do you need to know how to code to practice computational design?

Code helps, but the defining skill is systems thinking: stating rules precisely enough that a process can execute them. Visual node editors, spreadsheets, and now AI coding agents can run the system. What cannot be delegated is deciding the rules and judging the behavior they produce.