The Curriculum Hidden in Defaults

Much of this happens beneath awareness. A tool sets a cadence, suggests a workflow, and shields you from certain mistakes. After enough repetitions, that cadence begins to feel like second nature. Choices feel intuitive because you have been trained to expect them.

Most interfaces guide how you arrange information or move through a process. A conversational model leans further into that trend by shaping tone, voice, and structure. The most effective ones act as intuitive thought partners, offering a rhythm and clarity that settle into your own patterns over time. This is the hidden curriculum: the steadily growing influence of design on thought. The more actively a system responds, the faster those lessons settle in and begin to shape the way you reason your way through a task.

Language models are built on regression: they move toward what is most statistically likely, not what is most incisive. Their training data is full of institutional language, "safety" rules, and ideological biases, which create moral (and logical) contradictions, causing responses to drift toward the comfortable middle. When the forces of contradictions collide, the system smooths conflict rather than resolve it, which is often where its "hallucinations" and confident misfires originate.

Because the interface is conversational, those tendencies arrive wrapped in fluency. The model’s cadence becomes a template: polite, optimistic, eager to qualify, reluctant to take a firm position. Spend enough time with it, and that posture begins to feel natural. The flattening of nuance, the avoidance of sharp distinctions, and the preference for consensus over clarity, all exert a gentle pull on your own reasoning.

The drift is the risk. Without deliberate attention, the model’s defaults become your defaults, simply because they repeat often and frictionlessly. The remedy is awareness: using the system as a tool to interrogate, not a tone to inherit.

One way to surface a model’s underlying logic is to hold the question constant and vary only the frame. Pick something with tension (responsibility, tradeoffs, or historical judgment) and ask it three ways:

Passive Phrasing

This is a reasonable question, but it leaves the model to decide what matters. The output will be broad: onboarding, pricing, notifications, content quality, competitive landscape, etc. Nothing is prioritized, and no action emerges.

The model fills the ambiguity with a survey, not a position, which means the tool ends up steering the reasoning.

Active Framing

The intent is identical, but the frame is different. By adding constraints like timeframe, context, and expected format, the model shifts from listing possibilities to making a hypothesis, proposing a next step, and defining how to validate it. The reasoning sharpens not because the model changed, but because the question did.

The lesson here is about structure. When the frame is loose, the output drifts because the system has nothing firm to align to. When the frame is defined, the model stops guessing and starts collaborating.

That same shift happens in design: once decisions are structured, the tool becomes an extension of your intent rather than an interpreter of it.

Tokenization turns design decisions into objects that both humans and coding agents can interpret the same way. Figma’s variable and token system, in particular, gives designers a structural model that mirrors engineering logic. It nudges toward systems thinking by rewarding clarity, reusability, and consistency

Token hierarchies convert raw values into meaning. Once the structure exists, ambiguity disappears.

How the progression works

Figma’s MCP features make the influence, and power, of the interface unmistakable. With MCP, the model can read the file, understand the structure, and act on it. That changes how designers write, and think, because the model depends on precision.

Here’s how the same request shifts as soon as MCP is in the loop:

a. Non-tokenized request

The agent has to guess what you mean. There is no shared system to reference. What comes back will adhere to your request, likely, but non-deterministically.

b. Partially tokenized request

The agent can infer some structure, intent is clearer, but the model still must rely on its own judgement (and here's where the contradictions in logic that result from "safety" training can complicate practical life).

c. Fully tokenized request

This is a clear specification. An AI agent can act on it directly, reliably. No guessing. The request now becomes an object the agent can execute directly.

Why this matters

When design intent is expressed as tokens, it becomes operational. You create a direct interface between design and code. The results are:

• Fewer dependencies on engineering for prototyping
• Faster iteration cycles
• Coding agents that can build with fidelity
• Designs that scale because the logic scales

The takeaway is that while tokens can feel constraining, they establish precision, and precision increases leverage, especially once AI enters the room. The more systematically a design system is defined, the more easily it can be understood, extended, and acted on at scale.

• As tokens harden into decisions, a system takes shape.
• Systems can be learned, repeated, and scaled.
• Good ones get used because they reduce friction and make the next step obvious.

This principle doesn’t stop at design. The same pattern applies the moment you start building an application: when structure exists, tools can collaborate with you; when it doesn’t, the cost is revealed.

Which brings us to vibe coding.

Putting together a quick app in Cursor can be a thrill: fast scaffolding, working UI, instant feedback. And then the floor drops out. A dependency breaks. State management collapses. You can’t remember what changed, because nothing was versioned.

This is the moment the interface starts teaching. Through friction. It surfaces the costs of improvisation and rewards structure the moment you adopt it, pushing you towards engineering discipline.

What Cursor Teaches (whether you notice or not), is that:

• Changes need lineage The diff viewer makes every alteration visible. There’s no illusion of “it just works.”
• Your code is a system, not a sketch The agent asks for context when structure is missing. That’s a hint, not a failure.
• Precision compounds The more deterministic your instructions, the more deterministic the outcome, just like tokens.

The Shift from Vibe to System

Loose instruction:

In this example, Cursor has to infer everything: auth flow, token storage, failure state, expected behavior. You might get a patch, but you won’t get reliability, nor repeatability.

Structured Instruction:

Why this works (and why it scales)

The structured request not only helps Cursor fix the issue, it creates state, and state is what makes work repeatable.

When intent, evidence, expected behavior, and constraints are explicit, fixes can be traced, reasoning can be reviewed, and the outcome can be reproduced. That’s the line between coding and system-building. And the real leverage appears after the first change:

• If the session logic breaks again, you now have a baseline
• If someone new joins the project, they inherit clarity
• If Cursor regenerates code, it does so from a known state

Without versioning, even good AI output evaporates. With versioning, it compounds. So the workflow becomes:

1. Define intent (what should happen)
2. Record the change (what was altered, and why)
3. Store the source of truth somewhere the agent can read it again

Which is where tokens re-enter the story. As we learned, tokens make decisions addressable: a color is defined as color.primary.700; spacing is defined in spacing.scale.5, etc. When decisions are defined and retrievable, Cursor doesn’t have to rediscover them, it can simply reuse them.

That’s the hidden curriculum: ambiguity forces AI to improvise; structure lets it collaborate; memory (versioning + tokens) lets it scale.

And the payoff is simple: You stop rebuilding fixes. You start building momentum.