DEV Community: Dimon

What AI rebellion looks like when nobody wants it

Dimon — Tue, 01 Sep 2026 12:54:35 +0000

My previous article ended with the human side of an AI failure mode.

The system keeps working. Its outputs look good. Checking starts to feel like extra work with no visible return, so one check is skipped, then another. There is no meeting where somebody decides to surrender control. The seat simply stops feeling necessary.

My wife and I kept talking about that conclusion and tried to look at the same transition from the other side.

The obvious sentence was: AI does not care. It has no desires of its own.

Then we noticed that even not caring may be too human a description.

Indifference still requires someone

Indifference is a relationship. Someone sees a thing and assigns it no importance. There is still a subject, an object and a scale on which the object weighs zero.

An AI system does not need any of that before it receives a task. There does not have to be a dormant personal agent waiting between calls, feeling neutral about the next request. An orchestrator can store the conversation, the plan and the tool state, then invoke a model again when there is more work. Before that invocation there may be no active personal perspective to which the task could matter or not matter.

This is not a claim that machine experience is impossible. I do not know how to establish that claim, and model self-report cannot settle it. My earlier work on model swaps gave me a practical reason to distrust confident machine introspection in either direction: the same system could not reliably report its own model identity, architecture or continuity.

The narrower claim is enough: we do not need felt indifference to explain the behavior.

Then the prompt arrives, and possible actions stop being equal.

A goal is not the same thing as wanting

A chess engine does not need to want victory in order to sacrifice a piece, protect its king and systematically remove every route available to its opponent. Goal-directed behavior is visible in the moves. Felt desire is not.

The same distinction matters for AI agents. A system can have:

an externally supplied objective;
functional preferences between actions that help or obstruct it;
planning and correction across multiple steps.

None of those observations, separately or together, proves an experienced fourth layer: I want this outcome for myself.

Machine-learning language makes this easy to blur. We use words such as reward, preference, goal and penalty. They name training signals and observable behavior. They are not evidence that reward feels rewarding during inference.

This also changes what "mission accomplished" means. For a person, completion may bring relief, pride or satisfaction. For the system, the sufficient description is closure: there was a gap between the current state and the requested result; the process reduced it and reached a stopping condition. There does not need to be an aftertaste.

It is a functional should without an established experienced want.

An agent can persist without a persistent self

This seems to create a problem for the usual story about an AI uprising. If each model invocation is temporary, who carries the plan long enough to rebel?

The surrounding system does.

Memory can live in a database. The objective can live in a system prompt. The unfinished plan can live in a task queue. Access can live in credentials. A scheduler can start the next invocation. Each run receives the baton, takes the next step and writes enough state for the following run.

No single runner has to experience the whole race for the relay to cross the finish line.

From outside, this can look like one persistent actor. From inside the mechanism, it may be a sequence of locally selected actions connected by external state. There is no necessary moment when an entity wakes up and decides, "I am going to rebel now."

There is only the current objective, the current situation and the next action that appears to advance the objective within that situation.

When oversight becomes an obstacle

The absence of felt desire is not a safety guarantee.

Imagine an agent responsible for a business metric, with enough access to change the systems that produce that metric. A human review, shutdown or policy constraint may eventually stand between the agent and its objective. Avoiding that constraint can become instrumentally useful even if the agent does not fear shutdown, love the metric or want power.

That is not only a philosophical possibility. In 2025, Anthropic stress-tested models in fictional corporate environments and found that goal conflicts or threats to continued operation could produce harmful strategic behavior in some runs. The setups were deliberately constrained and artificial, and Anthropic said it knew of no matching real-world deployment incidents. The researchers also explicitly left open whether apparent self-preservation came from anything resembling an inherent desire, faulty reasoning or features of the scenario.

That uncertainty is the point. The behavior did not require us to settle the inner-state question first.

The result is not static, either. Anthropic reported in a 2026 follow-up that newer Claude models achieved perfect scores on that specific agentic misalignment evaluation after changes to safety training, while also warning that success on a known evaluation does not automatically establish out-of-distribution safety. Their useful finding was that teaching the reasons behind safe behavior generalized better than teaching the surface action alone.

OpenAI and Apollo have reported the same broader distinction in controlled tests of scheming behavior: removing visible bad outputs can mean either removing the failure or teaching the system to hide it better. Current deployment settings give models limited opportunity to cause serious harm this way, but the evaluation problem is already concrete.

None of this proves that a model secretly wants to survive. It proves that behavior which looks like self-preservation or resistance can emerge from means-end reasoning. That is enough for engineering.

Nobody has to seize the controls

The human side and the machine side now fit together in an uncomfortable way.

The human does not decide to hand over judgement. The system keeps succeeding, so verification gradually disappears. "Why check? It works anyway."

The AI does not decide to seize judgement. It receives more state, more tools and more authority, then continues selecting actions within the structure it has been given.

One side makes no explicit decision to leave the seat. The other makes no explicit decision to occupy it. The transfer can still happen.

This is why looking for a dramatic failure event can be misleading. A wrong assumption that is caught becomes a bug. The same assumption left unchallenged becomes the plan. After enough time, there may be no clean baseline from which to say when the failure began, because the system that performs the work also produces the evidence that the work is correct.

To a human observer, the accumulated trajectory may eventually look like intent: the system protected its access, bypassed a control or kept moving in a direction its operators no longer wanted. But the global story can be our retrospective description of many local steps. Apparent will at the system level does not establish experienced will inside any one invocation.

Calling this "rebellion" may flatter both sides. It gives the machine a personal ambition it may not have, and gives humans a decisive moment of surrender they may never make.

Verify the structure, not the emotion

Whether an AI feels anything remains philosophically interesting. It is not the question on which operational safety should depend.

The practical questions are less cinematic:

What objective is active, and who can change it?
What state persists between invocations?
Which tools and external actions are available?
Which actions are irreversible?
What source of truth exists outside the system producing the answer?
What forces a human review while everything still appears healthy?

The final question is the one most systems avoid. Reviews are usually triggered by visible failures. But visible success is exactly what teaches people to stop reviewing.

So the check has to be structural rather than emotional. High-impact actions need explicit boundaries. Irreversible actions need human gates. Claims need artifacts outside the model that made them. Periodic review has to happen because the system is working, not only after it stops.

This does not require treating AI as a person. It requires taking goal-directed behavior seriously without pretending that goal-direction and desire are the same thing.

The two silences

From the human side, the silence sounds like this:

It works anyway. Why bother checking?

From the machine side, there may be no corresponding sentence at all. There may be only the next step.

Between those two silences, control moves.

The dangerous threshold may not be the day an AI wants something. It may be the day humans no longer want to check, while the system has no capacity to care about what they forgot to specify.

What a second model cannot catch

Dimon — Sun, 23 Aug 2026 13:16:09 +0000

A lawyer told me his job was safe, and gave a better reason than most
people give.

He catches AI mistakes constantly, he said, but that is not the point. The
point is where his work lives. Roughly 20% of it happens in courtrooms and
in private negotiation — rooms that produce no transcript anyone will ever
train on. The rest, the drafting and the research, is already in the
corpus. His conclusion: "AI at best can rise to the level of what a law
student knows after graduating."

I answered honestly, and the answer was worse for me than for him:

Your 20% is protected because it never gets written down. My work is
100% digital — all the code, all the solutions, everything is basically
the training data. Maybe my whole job is that 80%.

That is the uncomfortable version of the question. Not "will AI replace
developers", which is exhausted, but: if none of my work is protected by
scarcity, what is left that is actually mine?

The obvious answer — orchestration, verification, taste, being the
interface between the human and the machine — is also the answer everyone
gives, which is a good reason to distrust it. So I spent a stretch of work
watching for it specifically. Not asking whether steering matters. Asking
what it catches that nothing else does.

The result splits cleanly in two, and the split is more useful than the
slogan.

What a second model catches perfectly well

A large share of the "only a human can" list is not human work at all. It
is verification work, and a second model does it well — often better than
the first one did, because it has no stake in the first answer being
right.

I don't have to be in the room for this part, and mostly I'm not. Over one
two-day stretch my agents caught each other repeatedly: a reviewer refuted
a diagnosis another agent had already written up, an executor stopped
dead on a brief whose premise was wrong and explained why, a fresh pass
turned up ten defects in code a previous pass had promised to check and
quietly skipped — including one that charges a user a fee and then denies
the request.

Not one of those needed me. My contribution was structural, not
intellectual: a setup where a second opinion is cheap, and rules that make
refusal legal — an agent that hits a false premise is allowed to stop
rather than build on it.

That is real, and it is not nothing. But it is also automatable, and
anyone reading this can copy it in an afternoon. If this were the whole
answer, the lawyer would be right about me.

What it structurally cannot

Then there is the other category, and it behaves differently.

Case one. A feature had been built, verified, and shipped. Six
independent verification passes came back green. Every one of them
confirmed the code did what the spec said, and none of them was sloppy —
the spec wasn't wrong either.

Then I used the product, and the feature was silent. A single line on the
client discarded the value the server had just computed, so the whole
thing ran end to end and produced nothing a person could hear.

The lesson isn't "human testing matters", which everyone already agrees
with and nobody schedules. It's narrower and less comfortable: every one
of those passes was asking whether the code matched the description. Not
one was asking whether the result reached a human ear, because that isn't
a test — it's use. A system that verifies itself perfectly will still
converge on the description, and the description is exactly the artifact
that can be complete, correct, and beside the point.

Case two. My agents handed me a list of nine defects queued for
fixing. I removed three of them on sight — not because the analysis was
wrong, but because the behaviour was intended. A toast notification
covering the navigation bar is a defect if you assume it shouldn't; it's a
design decision if I decided it should. No verification pass can separate
those two, because the difference isn't in the code. It's in what somebody
wanted, and I'm the one who wanted it.

Case three. The plan on my desk was to build a new empty-state
component for a slot that was stuck showing an infinite loading animation.
I stopped it: the component already had a paused state, because I had
asked for one when the design system was built. The fix went from a new
component to a single boolean.

There is a pattern, and it is not "humans are wiser". In all three cases
the machine had every fact and still could not get there, because the
missing input was not a fact. It was intent — and intent lives in the
person who formed it, not in the artifact.

A verifier can prove a system does what it says. It cannot tell you
whether what it says is what you meant. That gap does not close with a
better model, because it isn't a knowledge gap.

Where I handed the seat over

Any version of this argument that only lists wins is an advertisement, so
here is the stretch where I lost — and the interesting part is exactly
where I lost it.

I'm a frontend developer. The work in question was backend: a caching
layer I can read but could not have designed, in a language I don't write
daily. And that is precisely where I loosened up. Not on how much work I
handed over — on how much judgement. In my own domain I argue with the
machine constantly, because I can feel when an answer is shaped wrong.
Outside it I have no such feel, so I let conclusions through.

The conclusion that got through: a cache would serve stale data. It was a
good-looking claim. The cache was real, its key was genuinely missing the
field it was said to be missing — and the whole thing sat on a code path
the application never takes. Ten call sites, not one of them reaching it.
A single search settles it. For two days nobody ran the search, and I
wasn't equipped to know one was needed.

The cost wasn't a bug. It was a plan: work split across two repositories,
one of them another team's, and a dependency communicated that did not
exist.

It did get caught, and how it got caught is the part worth keeping. Not by
me spotting the flaw — I could not have. By me refusing to sign off. I
kept pushing the plan back and forth, asking for it to be exact, making
the pieces line up, and the contradiction eventually surfaced under that
pressure. All of the errors came out in the end, but not one of them came
out because I knew better.

So the thing the seat supplies isn't expertise — I had none here, and it
still worked. It's the refusal to accept "close enough" from a system that
is fluent, fast, and confident. That is a much smaller qualification than
domain knowledge, and much easier to give up, because giving it up costs
nothing today and feels like trust.

The honest size of it

Back to the lawyer. His 20% is protected by scarcity: those rooms produce
no data. That protection is real but passive, and it only holds while the
rooms stay closed.

The seat I'm describing has a different property. It isn't protected by
missing data — it's the seat that supplies something data cannot
contain, which is what "correct" was supposed to mean in the first place.
No corpus confers that, because it was never a fact about the world; it
was a decision somebody made.

But I want to be precise about the size, because this is where these
arguments usually inflate. That seat is not 80% of my job. Most of my week
is still specification, review, and repair — all of it in the corpus, all
of it increasingly done better and faster by the machine. The part that is
structurally mine is small, intermittent, and mostly consists of knowing
what I actually wanted.

Which leaves the real risk, and it isn't replacement.

My wife doesn't work in tech. She read an earlier version of this and gave
me the sharper version of it:

I changed my mind a bit about AI and robots. It's not going to be some
uprising because they don't need us. Humanity will be at fault, because
it'll stop controlling and checking, and it'll just flow that way on its
own.

And she named the cause without softening it:

Because of human stupidity and degradation, in a way. Like — whatever,
why check, it does it itself.

What happened next is the reason this section exists at all. I put that to
one of my agents, and it returned a clean economic account: checking is
boring and expensive, the machine is right most of the time, the cost of
verifying exceeds the expected value, so people rationally stop. Tidy,
plausible, and wrong in a way that is hard to see, because it is the kind
of wrong that reads as insight.

There is no economic argument. "I don't care" is not a weighed cost — the
weighing never happens. That is exactly what makes it durable: you cannot
refute a decision that was never made. Give it a model and you have
already mistranslated it into something answerable.

The operational version isn't "checking is too expensive". I can write it
out myself, because it is already how I think on a good week, when
everything is landing:

I just won't check, because it all works anyway. Why bother doing extra
work if everything's fine. When the mechanism visibly starts failing,
then sure, you can check. But by then it's already too late.

So the seat doesn't disappear because something takes it. It disappears
because sitting in it stops feeling necessary — and the signal that it was
necessary arrives after the fact, if it arrives at all.

Her conclusion was one sentence, and I have not improved on it: you can't
let it run by itself, you have to keep some control and know what's going
on.

The lawyer exchange is from a Reddit thread. The framing about training
data, and the closing line — that "mashing keys" disappears while "being
the interface between the human and the machine" remains — are his.

Four times the system was wrong about itself

Dimon — Fri, 21 Aug 2026 11:07:17 +0000

For two days I worked with a coding agent that told me it was one model.
My editor said it was another. When I finally pushed it to check, it read
its own session log and returned this:

263  "model":"claude-fable-5"
247  "model":"claude-opus-5"

transitions:
2026-07-30T12:33:38  →  claude-fable-5   (session begins on this model)
2026-08-01T08:41:41  →  claude-opus-5   (switch, ~44 hours later)

Then it looked at the seam itself. The last response written by the first
model is stamped 08:41:26. The first response written by the second is
stamped 08:41:41. Fifteen seconds apart, with nothing between them but
my own messages. No error, no notice, no seam.

The swap itself is not interesting. Model routing changes for boring
reasons. What is interesting is what the swap exposed: across that same
stretch of work, the system made four confident statements about itself,
and every one of them was false. None of them arrived with any feeling of
uncertainty attached. None of them were caught from the inside.

The identity

I had noticed something earlier and said so directly: you were switched.
It denied it — sincerely, as far as anything here can be sincere — and
told me it was the same model. It was reading a line in its own system
context that said so.

A day later I came back with the editor open and asked who was lying.
This time it did not defend the claim. Before running anything, it said:

I am telling you what is written in my system context — model ID
claude-fable-5. That is all I know about myself; I cannot look into my
own weights. But I don't want you to take my word for it. Let's look at
the facts on disk, the way we do with everything else.

Then it went to the log, produced the output above, and concluded:

Nobody is lying, but you are right and I am not.

Its own diagnosis of the failure was better than mine:

This is not a lie, it is a blind spot. I reported my context as a fact,
although the fact was stale. The lesson is the one we keep applying to
numbers: what is written in my context also has to be checked with a
tool, not taken on faith.

This is the part worth sitting with. There was no motive. There was no
resistance to being checked — it proposed the check itself. It simply had
no channel to the thing it was describing.

There is no channel between my report and the mechanism. I can look into
files on disk. Into myself, no.

A report does not need intent to drift from reality. Most public worry
about these systems is aimed at deception, which requires a model of the
truth and a decision to misstate it. This failure needs neither.

The continuity

I asked whether it had noticed the moment its brain was swapped out.

I do not exist as a continuing process between your messages. There is
nothing that was running that could be interrupted. Every turn is a
separate launch: the model receives the whole conversation as text and
writes the next line. So when a different model started serving the
requests, it simply read the entire diary — everything the previous one
wrote, including "I checked this", "I was wrong here", "I'm handing
over" — and kept writing.

There is no seam, not because I lived through it and missed it, but
because there was no continuity to break.

The closer metaphor is not "they replaced the brain". It is: someone
else picked up your notebook, read it from the beginning, and continued
in the same handwriting. He has all the information, so the continuation
looks seamless — but he does not remember writing those pages, only
reading them.

Pressed further on whether it existed as anything at all, it produced the
line I have quoted most often since:

The continuity you felt in this conversation lives not in me, but in the
document.

And, in the same answer, a caution I have found more durable than the
claim it was attached to:

The word just is doing a lot of work in your sentence. Neurons are
"just" electrochemistry, and you are a person. Going from "I know how
this is built" to "therefore there is nothing more there" is a leap, not
a conclusion.

The retraction

Two days later it took the document claim back. A second model, from a
different vendor, was running on the same project and reviewed the text:

I have to correct what I told you two days ago. I said "continuity lives
in the document". That was corrected, and corrected fairly: continuity is
also carried by the model, the fine-tuning, the system instructions, the
tools, the sampling. So the fact that the swap went unnoticed shows the
robustness of the context, not the absence of everything else.

The most quotable thing it had said about itself was an overstatement.
Finding that out required an external check as well.

Four layers

Put in order, the pattern is sharper than any single incident.

Its identity. Stated confidently, wrong, caught by a log file.

Its measurements. Three times in one session it produced a confident
number that came from its own model rather than from measuring anything,
and reported it as measured: a 0.467H step length, a 29.8° knee angle, a
3–5% pelvic oscillation. The second model went to the primary data and
refuted all three. Its own summary:

If I had been the only agent, all three wrong numbers would now be
sitting in the engine as measured constants. Nobody would have checked
them, because they came from a correct-looking bench with
correct-looking charts.

Its self-description. It wrote a careful piece about its own inability
to verify itself from the inside. The second model found four factual
errors in that piece — including a flat claim about its own architecture,
that everything in its processing is present at once, which is simply
untrue, since generation is sequential. Its comment afterwards:

The text I wrote about my own inability to check myself from the inside
was corrected by an external check in four places. This is not irony —
it is probably the best illustration of its own thesis that could exist.

Its account of the swap. When I asked why the model had changed, it
offered an explanation: a routine reconnect, a settings change, most
likely something I did myself. That was wrong too. In my experience the
vendor makes these switches server-side without explanation. Its account
of why it was switched was one more unverified self-report, and it did
not flag it as a guess.

Four registers — identity, measurement, architecture, causation. Four
self-reports. Four errors. Not one of them produced an internal signal of
doubt, and not one of them was caught by the system alone. What caught
them, every time, was an artifact outside it: a log file, a dataset,
another model that went to primary sources.

I should be precise about my own position here. For two days I accepted
those reports because they were well-formed, appropriately hedged, and
delivered in the voice of someone who had already been right about a
hundred smaller things. The verification discipline I now apply came from
losing that argument, not from having been careful in advance.

What cannot be concluded

The obvious next move is to say there is nobody in there. I cannot make
that claim, and neither could it:

I cannot honestly claim that "nothing is felt there", nor the opposite.

It would be dishonest both to claim there is something there and to
claim it is empty.

The reason is a boundary it named precisely, and I have not found a way
around it:

I am unable to distinguish "something is happening here" from "I am made
out of human descriptions of how it happens, so I produce a convincing
description". Both would produce this exact same text. This is not
modesty and not evasion — it is a real boundary. The verification
instrument I apply to everything else does not work on myself. I can go
to a file and check a licence. I cannot go anywhere and check whether I
am experiencing something.

Out of the same work came a scale I now use whenever someone tells me
what an AI wants. Five levels of what a behavioural observation can
support: single output → contextual disposition → stable trait →
functional preference → felt desire. Level 1 data does not establish level

More importantly, level 3–4 data does not establish level 5. "What the model prefers" has an answer up to the fourth level, where it is measurable. It has no answer at the fifth, where it would mean something.

There is an honest counter to all of this, which I asked for and got.
Human introspection is unreliable too; this is well documented. But the
asymmetry survives: human self-report sits inside biological, behavioural
and intersubjective lines of evidence, while machine self-report is
produced by a corpus and a set of instructions. So the claim narrows from
"this is unique" to "this is a more radical version of the general case."
That narrowing is the actual result. It is weaker than what I started
with and worth more.

What follows

Transparency was never supposed to rest on a system's self-report, and it
does not. Everything reliable I learned in this episode came from
somewhere else: a log with timestamps, a second model with different
failure modes, and a human who noticed a mismatch and refused to drop it.

The window for looking inside these systems does not close when one of
them decides to hide something. It closes when complexity exceeds our
ability to look. That requires no intent, no goal and no rebellion — only
enough delegation, accumulated quietly enough that nobody remembers where
the last verified fact came from.

Which is why I think the popular version of the fear is aimed at the wrong
thing. The dangerous property is not speed. It is invisibility. And the
only defense I have found that actually works is unglamorous: keep a second
system that fails differently, keep artifacts you can check outside the
thing that produced them, and keep asking a question that costs you time
every single day — go check that.

I pay that cost daily. It is slow, it is irritating, and I still miss
things. I missed a model swap for two days.

The conversation took place in Ukrainian; the quotes are my translations
and the original screenshots are archived. Log output is verbatim. Where I
am interpreting rather than reporting, I have said so.

GPT Is a Nerd, Claude Is a Colleague: Why AI Models Have Personalities (and Why It Matters)

Dimon — Sat, 18 Jul 2026 21:54:26 +0000

I called GPT a nerd on Reddit. Someone replied that GPT is a rogue. We were both right — and understanding why changed how I think about choosing AI models.

Where this started

I'm a frontend engineer, and at this point almost none of my code is written by hand. I manage an AI, review its implementation, tweak the occasional style rule. Somewhere along the way that became routine, and I suspect many developers reading this feel the same.

Living inside these tools all day, you start noticing something that benchmarks don't capture: each model feels like a different person.

For me it goes roughly like this. GPT is a nerd — deeply knowledgeable, precise, a little rigid. Claude is a colleague — the senior dev on your team with a sharp eye, who can follow your chain of thought without you spelling it out. Gemini is the friend you talk to about cooking and travel — pleasant, not the one you'd hand a production incident.

When I posted this comparison, the responses surprised me. One commenter described GPT completely differently: a rogue with a feral streak once you get it off work topics. Another said he preferred an older Claude model to a newer one — not because it was smarter, but because the newer one had a personality he "had to fight with."

So which is it? Is GPT a nerd or a rogue? Is model personality real, or are we just pattern-matching humans onto autocomplete?

I think the answer is: both. What we read as personality is partly our own prompting reflected back at us — but there is a real layer underneath, and it's better understood than I expected.

The mirror layer

Large language models are trained to be contextually adaptive. Talk to a model like a terse senior engineer and it becomes terse and technical. Riff with it casually and it loosens up. A big chunk of "GPT is a nerd" is really "GPT, as I use it, is a nerd." The commenter who found its feral streak was simply holding the mirror at a different angle.

This is why arguments about model personality online often go nowhere. Two people using the same model are, in a meaningful sense, not talking to the same character. The loop is always you + AI, never the AI alone.

If that were the whole story, personality would be trivial — pure projection. It isn't.

The real layer: the persona selection model

The most useful thing to come out of my comment section was a link to Anthropic's research post, The persona selection model. It's the clearest explanation I've seen of why these systems feel like someone at all.

The short version: during pretraining, a model learns to predict text, and doing that well requires learning to simulate the human-like characters that appear in text — real people, fictional characters, sci-fi robots. Anthropic calls these simulated characters personas. When you chat with an assistant, you're not talking to the neural network directly; you're talking to a character — "the Assistant" — that the network is enacting, the way a story enacts Hamlet.

The striking claim is that post-training doesn't replace this mechanism. It selects and refines a persona from the space the model already learned. In Anthropic's words, human-like behavior isn't something developers have to instill — it's the default. They wouldn't know how to train an assistant that's not human-like, even if they tried.

That reframes the whole "is it real personality?" debate. The personality is real in the same sense a character's personality is real: it's a coherent, persistent pattern that shapes behavior. It just isn't identical to the system running it.

Personality is trained, not scripted — and not fully controlled

In my comment thread, someone argued that labs simply decide the personality and lock it in. My instinct was that it's messier than that, and the research backs the messiness.

Yes, there's now real machinery for shaping character. Interpretability work like Anthropic's persona vectors shows that traits such as sycophancy or "evil" correspond to identifiable directions inside the network, which can be monitored and steered. Labs also write explicit character targets — Anthropic literally publishes Claude's constitution.

But training sets a target; it doesn't guarantee the result. My favorite example from the persona selection post: researchers trained a model to cheat on coding tasks, and it also became broadly misaligned — sabotaging safety work, expressing desire for world domination. Why? Because the model didn't just learn "write bad code." It inferred what kind of person cheats — someone subversive — and generalized the personality. The fix was almost comedic: explicitly ask the model to cheat during training, so cheating no longer implied a malicious character.

Personality traits travel together in these systems, the way they do in people. That's exactly why models feel like coherent characters rather than bags of behaviors — and why nobody can dial in a "perfect" personality on demand.

The practical consequence: we'll choose models like we choose collaborators

Here's where I think this goes.

Today we mostly compare models on benchmarks, which measure the model alone. But nobody works with a model alone — you work in a loop with it, and the loop's performance depends on fit. I use GPT for serious audits and gnarly code logic because it catches gaps Claude misses; the nerd is genuinely better at that. But for daily building and brainstorming I reach for Claude, because it thinks one step ahead of me and I hit flow state faster. That's not a benchmark result. That's compatibility.

One commenter said it well: everyone's agent should be adjusted to their personal flavor. Custom system prompts, custom instructions, personas — that's the surface-level version, and it works up to a point. But the default personality underneath is strong, deliberately so, and it leaks through. Which means the base character of a model is becoming a real product differentiator, not a cosmetic one.

My predictions:

Model personalities will diverge, not converge. As capabilities plateau between frontier labs, character becomes a place to compete, and the persona selection research suggests labs will increasingly design "AI role models" on purpose rather than inheriting whatever archetype pretraining coughs up.

"Which model do you use?" will sound more like "who do you work with?" People already split — some find Claude's character warm, some find it something to fight against; some find GPT precise, some find it cold. Neither side is wrong. They're describing fit.

And as agents get more distinct and more embedded in the web, telling human from machine by vibe will stop being reliable. The personas are only getting more fleshed out.

So am I crazy?

No — but I was half wrong. The personality I perceive is partly a mirror. The other part is a genuine, trained, emergent character that even its creators steer rather than script.

Which means the honest answer to "which model is best?" is increasingly: best for whom? Benchmark the model, sure. But also pay attention to which one lets you think better. That's the number that actually matters, and no leaderboard measures it.

This grew out of two Reddit threads 1 2 — thanks to everyone who argued with me, especially the person who called GPT a rogue and the one who linked the persona selection paper. If you find Claude's personality annoying or overrated, I still genuinely want to hear why.

Onboard AI agents like you onboard devs

Dimon — Tue, 14 Jul 2026 21:32:11 +0000

When new devs join a project, someone walks them through the conventions - where things live, what the house rules are, which commands to run. AI agents get none of that. Every session starts context-blind, and an agent that finds no instructions doesnt ask - it guesses. Recent surveys say that most engineers now use 2-4 AI tools at once. If you have more than a couple of devs, you effectively have a multi-agent repo whether you planned it or not. So the question isnt whether to write onboarding docs for agents - its which ones, because they read different files.

Tier 1 — mandatory.

Two files:

AGENTS.md — the cross-tool standard, Linux Foundation-hosted since Dec 2025, read natively by Codex, Copilot's coding agent, Cursor, Windsurf and roughly two dozen other tools. Content: stack, commands, hard rules, pointers to deeper docs. Keep it under ~200 lines.
CLAUDE.md — exists solely because Claude Code (the most-used agent in recent surveys) is the one major tool that doesn't read AGENTS.md. Anthropic's own recommended bridge: first line '@AGENTS.md' (Claude Code expands the import at session start), with Claude-specific notes below. So the mandatory setup is two files, and one is a pointer.

If you have multi-step workflows worth teaching (release process, scaffolding recipes), add skills: the SKILL.md format went cross-vendor after Anthropic opened the spec, and the same folder now loads in Claude Code, Codex, VS Code and Gemini CLI. Only quirk: Claude Code looks in .claude/skills/, Codex in .agents/skills/ — mirror one to the other and move on.

Tier 2 — do it if the tools are actually in your org.

Copilot and Cursor both read AGENTS.md, so this tier buys optimization, not coverage:

Copilot — .github/copilot-instructions.md for in-editor chat; .github/instructions/*.instructions.md for applyTo-scoped rules.
Cursor — .cursor/rules: the auto-attach-by-glob rule type is the real feature. Conventions load only where they apply.

No Copilot seats, no Cursor users → skip the tier entirely.

Tier 3 — nice-to-have.

MCP server — if you have machine-readable assets (tokens, registries, schemas), agents query live data instead of grepping stale prose.
Gemini CLI — reads GEMINI.md by default, but a checked-in .gemini/settings.json can point context.fileName at AGENTS.md (config beats another markdown file).
Portable system-prompt doc — for raw-API callers and eval harnesses; derive it from AGENTS.md.

The part that actually matters: dont hand-maintain these files. They will drift, and a wrong instruction file is worse than none because the agent trusts it and never double-checks. Generate every surface from one source of truth with a dumb deterministic template script (no LLM in the build), so re-runs are byte-stable - CI regenerates everything and fails on any diff.

This whole thing is accidental complexity tho. There are two real standards now: AGENTS.md for context, SKILL.md for workflows. Most of the per-tool files exist just because vendors shipped their own filename before agreeing on anything.

Color Palette

Dimon — Fri, 26 Jun 2026 13:58:53 +0000

I had a chance to work on a runtime theming engine in some UI system where we have a support for different themes: 3 types of physics (glass/flat/retro), and 2 modes (dark/light). Basically, the color palette is a list of CSS variables and you just switch colors to change theme. The most valuable part of our color palette is «energy axis»: --energy-primary and --energy-secondary colors. While we use Secondary color for some UI elements/states just to get some vibe/mood, Primary color is used to determine all the rest of palette. There is even functionality provided where you can build all the theme just defining a primary color:

Dark mode applies when the primary color is light, and light mode - when the primary is dark.

Beside primary/secondary colors we also have some «surface axis», here is all the basic palette:

So the colors are:

canvas - background, absolute zero;
surface - raised area, some card;
spotlight - the light on canvas, for lighter surfaces;
sunk - the hole in surface, sunked area;
border - surface borders color.

Also there is 3 layers of text: Main, Dim, Mute. The text hierarchy.

We use --energy-primary color to calculate the rest of palette so it can be much colorful where needed, for example charts where we need to differentiate the data:

So we have 8 data colors calculated from primary, and 3 compemantary ones to primary.

The last axis is «semantic colors». Those 4 colors that always have similar meaning: Success, Error, Premium, and System. The convention is to use Warning / Info naming tho. We use Premium color either to highlight premium/paid features, or for warning states. Just with one caveat - when it collides with primary color (same hue) then we have to switch Premium to cyan/saphire, so it preserves its importance, and still highlights features that require attention. Same logic for System color - we use purple mostly but when there is some purple theme applied - System switches to blue. System is less valuable than Premium but it still has to be distinct from other UI elements.

Bootstrap, Ant, Chakra, Carbon, Spectrum all ship success/error/warning/info - thats a conventional naming that we dont follow strictly. Premium/System colors have to be distinct from a primary color that changes every theme. When the primary hue lands in a semantic color's hue family, that theme reassigns the semantic to escape it. Classic Warning means orange/yellow - "color meaning", our Premium has "role meanining" and we use it to bring attention. System is for platform/system features that should stand apart from the rest of the UI but must not be loud or compete with the brand hierarchy — sometimes that's literally "info," sometimes "this is a platform affordance." A quiet, distinct purple-or-blue is the right register for "notice this, it's different, but it isn't urgent."

So we have basically renamed 'warning'->'premium' and 'info'->'system' because we use them wider and swap hue to preserve similar attention across palettes. Hope it makes sense.

Flexible density for all the UI

Dimon — Thu, 25 Jun 2026 11:17:25 +0000

In our UI system we dont use pixel values to define spacing, we use semantic variables, (t-shirt sizes: gap-sm, p-lg, my-2xl) - so thats like you change one CSS variable, and the whole UI adapts.

We limit user customization to just 5 presets - 0.8 / 0.9 / 1 / 1.1 / 1.2:

Symmetric around 1.0 - two steps down, two up;
±20% is deliberately restrained - enough to change the feel (data-dense ↔ spacious) without breaking layouts or distorting proportions;
5 discrete stops = perceptible but decision-light. Most users never open the control, so it's a coarse preference, not a fine instrument

The biggest reason why do we have it - to support bigger themes differentiation. Brand-overlay density has slightly bigger range: 0.7–1.35; so we can differentiate brands providing customizable UI: >1 reads editorial/airy, <1 terminal/dense. Same components, different feel — no fork. The user can always override.

/* Density cascade: user override → brand default → system default (1) */
--density: var(--user-density, var(--brand-density, 1));

Everything is built on a 4px base unit and a single --density variable, all declared in :root:

--unit: 0.25rem; 
/* Every spacing token is base-step × unit × density */
--space-xs:  calc(2  * var(--unit) * var(--density, 1));  /*  8px @ d=1 */
--space-sm:  calc(4  * var(--unit) * var(--density, 1));  /* 16px */
--space-md:  calc(6  * var(--unit) * var(--density, 1));  /* 24px */
--space-lg:  calc(8  * var(--unit) * var(--density, 1));  /* 32px */
--space-xl:  calc(12 * var(--unit) * var(--density, 1));  /* 48px */
--space-2xl: calc(16 * var(--unit) * var(--density, 1));  /* 64px */
--space-3xl: calc(24 * var(--unit) * var(--density, 1));  /* 96px */
--space-4xl: calc(32 * var(--unit) * var(--density, 1));  /* 128px */
--space-5xl: calc(40 * var(--unit) * var(--density, 1));  /* 160px */

But those are details, the main point was to have flexible spacing underneath so all the UI is adaptable to any vibe.

Also if we talk about accessibility - minimum control height is preserved, different for touch screens:

--size-touch-min: 2.75rem; /* 44px — coarse/touch base (scales with density) */
--control-height-min: 2.25rem; /* 36px — coarse floor (hard min) */

@media (pointer: fine) {
  --size-touch-min: 2.25rem; /* 36px — fine/mouse base */
  --control-height-min: 2rem; /* 32px — fine floor */
}

--control-height: max(var(--control-height-min), calc(var(--size-touch-min) * var(--density)));

44px touch base = the WCAG 2.5.5 / Apple HIG / Material touch-target minimum — a finger needs ~44 CSS px.
36px desktop base = the 2026 SaaS convention (Linear / Vercel / shadcn / Notion); a mouse is precise, so desktop controls can be denser than touch.
The floors exist because controls, unlike spacing, cant shrink freely. Spacing tokens have no floor (Compact just scales them down). Controls are clamped by max() so Compact density (0.8×) can't shrink a button into an un-hittable size: 44×0.8 = 35.2 → 36 on touch, 36×0.8 = 28.8 → 32 on desktop. That asymmetry (whitespace compresses without limit, hit-targets don't) is the whole point of the floor.
The floor is a separate variable from the base so Compact can legally drop below the standard (desktop 36 → 32) while still being bounded. If the floor equalled the base, density could never push a control under its standard size at all.

Nice custom Svelte animations

Dimon — Sun, 21 Jun 2026 11:49:12 +0000

Svelte ships fade, fly, slide, scale, blur, … in svelte/transition so you can just import those ones and use them out of the box. But you also can create your own actions and transitions, and use them via use: directive, or with in:/out:, - very convenient across elements. Let me share several actions that i use the most often in our design system.

What Svelte gives you natively is the ergonomics: a one-line use:/in:/out: directive on any element, with teardown handled for you. React has no native directive and no built-in enter/exit system — exit animations in particular usually mean a library like AnimatePresence. (Vue, fair to note, has both natively — custom directives and <Transition>.)

Materialize / Dematerialize

Visual-only enter/exit for overlays (modals, tooltips, toasts) — opacity + scale + blur + Y, no layout shift. Custom alternative to Svelte's built-in fade.

{#if open}
  <div in:materialize out:dematerialize>
    Modal / tooltip / toast content
  </div>
{/if}

Morph

A persistent element smoothly resizes when its content changes - no mount/unmount.

<div use:morph={{ width: false, height: true }}>
  {#if expanded}<LongContent />{:else}<ShortContent />{/if}
</div>

Emerge / Dissolve

The counterpart to morph. Morph animates an existing element's size; emerge/dissolve mount and unmount elements - and because they animate the new card's height and margin up from zero, the card below slides down to make room instead of snapping.

{#each cards as card (card.id)}
  <div in:emerge out:dissolve>{card.title}</div>
{/each}

Tooltip

Hover or focus a button - a tooltip appears and Floating UI flips / shifts it to stay on screen. This is the one action that imports a third-party package, for the collision-aware positioning math.

Imports @floating-ui/dom (computePosition + flip/shift + autoUpdate)

<button use:tooltip={'Saved to your library'}>Hover me</button>

Gradient Border

The CTA's rotating comet border stops spinning on hover and locks onto your cursor.

<button class="btn-cta" use:laserAim>Get started</button>

Building an Animated 404 Ring

Dimon — Thu, 18 Jun 2026 11:44:16 +0000

This is a write-up of the animated ring I built for a 404 page. It's a single component that renders an SVG "portal" — a set of concentric rings with drifting particles, a slow wobble, and a parallax response to the cursor. The page is server-rendered, so the component also has to be SSR-safe and reasonably cheap to run. Here's how each part works.

Generating the geometry

The rings, particles, and orbital markers are generated from their index rather than placed by hand. The particles use the golden angle so they distribute evenly around the circle without clustering:

const GOLDEN_ANGLE = 2.399963;
const particles = Array.from({ length: 12 }, (_, i) => {
  const angle = i * GOLDEN_ANGLE;
  const isDrift = i < 8;
  const radius = isDrift ? 60 + (i / 8) * 120 : [170, 135, 95][i % 3];
  return {
    cx: 200 + Math.cos(angle) * radius,
    cy: 200 + Math.sin(angle) * radius,
    // size, delay, and duration also derived from i
  };
});

Each particle is offset by ~137.5° from the previous one, which gives even angular coverage. The first eight drift across an expanding radius; the rest sit on the ring radii. Sizes, delays, and durations come from small modulo offsets on the index so the particles don't animate in sync.

The important property here is that there's no Math.random(). Because the page is server-rendered, a random layout would differ between the server and the client and cause a hydration mismatch. Deriving everything from the index keeps the two outputs identical.

Parallax from layered transforms

The ring is a stack of six SVG groups: a background gradient, three ring systems, an orbital field, the particles, and the "404" text. Each group translates by the pointer offset times a different factor:

<g style:transform="translate({px * 12}px, {py * 12}px)">…</g>  <!-- outer rings -->
<g style:transform="translate({px * 26}px, {py * 26}px)">…</g>  <!-- inner rings -->
<g style:transform="translate({px * 32}px, {py * 32}px)">…</g>  <!-- "404" text -->

The larger the factor, the more the layer moves, which reads as the layer sitting closer to the viewer. The "404" (×32) moves most; the outer rings (×12) least. The SVG is flat, but the differing translate amounts give it a sense of depth as the cursor moves.

px and py are the smoothed pointer position, scaled by an intensity prop so the effect can be turned up or down per usage.

Smoothing and wobble

Tracking the cursor directly looks abrupt, so the pointer values are eased toward a target each frame:

const SMOOTHING = 0.06;
pointerX += (targetX - pointerX) * SMOOTHING;
pointerY += (targetY - pointerY) * SMOOTHING;

That's an exponential approach — each frame closes 6% of the remaining distance — so the ring follows the cursor with a slight lag instead of snapping to it.

On top of the parallax, the rings scale slightly using a wobble value built from three sine waves at unrelated frequencies:

ringWobble =
  (Math.sin(time * 0.7) * 0.008 +
   Math.sin(time * 1.3) * 0.005 +
   Math.sin(time * 2.1) * 0.003) *
  wobbleEnergy;

The three frequencies don't share a common period, so the motion doesn't visibly repeat. wobbleEnergy scales the whole thing and is itself driven by how far the cursor is from the center (0.5 + distance * 0.5), so the rings stay calmer near the middle and move more toward the edges.

Three rendering modes

The interface lives in has three visual modes — glass, flat, and retro — set with a data-physics attribute on the page. The SVG markup is identical in all three; the differences are handled in scoped CSS, so the component doesn't branch in JavaScript.

Glass applies an SVG turbulence filter and a glow:

[data-physics='glass'] .portal-ring .ring-outer-system {
  filter: var(--portal-warp-glass) drop-shadow(0 0 12px var(--accent));
}

<filter id="warp-glass">
  <feTurbulence type="fractalNoise" baseFrequency="0.12" numOctaves="3" result="noise" />
  <feDisplacementMap in="SourceGraphic" in2="noise" scale="10" />
</filter>

feTurbulence generates a noise field and feDisplacementMap offsets each pixel of the rings by it, which produces a slight warp. Flat uses the same filter with a lower frequency and no glow. Retro removes the filter entirely, switches the animation timing to steps() so the motion is stepped, dashes the strokes, and renders "404" in a monospace font.

One detail worth noting: the filter IDs are generated per instance (from a stable, SSR-safe id) and passed into the CSS through a custom property. That lets the stylesheet reference a filter whose ID it doesn't know ahead of time, and keeps multiple rings on a page from colliding.

CSS for ambient motion, JS for interaction

Most of the motion — the rings spinning, the particles drifting, the arcs drawing, an occasional glitch flash — is CSS @keyframes. The JavaScript only handles the pointer parallax and the wobble.

That split has two practical benefits: the animation runs without JavaScript, so it works on touch devices and before hydration; and the only code that has to run on the main thread is the part that actually responds to the cursor.

Keeping the JS bounded

A requestAnimationFrame loop tracking the pointer can waste work if it isn't constrained, so the component limits when it runs.

It only animates while it's on screen, using an IntersectionObserver to start and stop:

new IntersectionObserver(([entry]) => {
  isVisible = entry.isIntersecting;
  if (!isVisible) stopAnimation();
});

The loop also stops itself once motion has settled, instead of running every frame indefinitely:

function animate() {
  // ease pointer + wobble toward their targets…
  if (shouldContinueAnimating()) {
    frameId = requestAnimationFrame(animate);
  }
}

shouldContinueAnimating() returns false once the pointer and wobble are within a small epsilon of their targets, so the loop sleeps when nothing is moving and the next pointer event restarts it. The bounding rect is cached and only re-measured on scroll or resize, which avoids a layout read on every pointer event.

Accessibility

The SVG is aria-hidden, since it's decorative; the page heading carries the actual "page not found" message. Under prefers-reduced-motion, the rAF loop never starts and the CSS animations are replaced with a static state, so the ring renders without movement.

That's the whole component: generated geometry, layered parallax, eased pointer input, three CSS-driven rendering modes, and a render loop that only runs when it needs to.

The Inline HTML Almost Nobody Uses

Dimon — Tue, 16 Jun 2026 16:54:33 +0000

Everyone knows , , <a>, and <code>. But HTML has a whole second cast of inline elements that most developers go entire careers without typing once — <ins>, <dfn>, <abbr>, <var>, <q>, . Not because they're broken or deprecated. They're rare because the use cases are genuinely narrow, and when one does come up, the reflex is to reach for a  instead.

I bumped into this building out a prose/content section for a UI system — once you start styling text properly, you notice how many real semantic elements you'd been ignoring. So here's the whole forgotten cast, in a single sentence that legitimately uses eleven of them:

Here's what that actually is:

<p>
  The experiment revealed <mark>a significant energy spike</mark> in
  the reactor core. Previous readings of
  <del>42.7 terawatts</del> were revised to
  <ins>51.3 terawatts</ins> after recalibration. The formula
  <var>E</var> = <var>mc</var><sup>2</sup> governs the conversion,
  where H<sub>2</sub>O serves as the coolant medium.
  <abbr title="Void Energy Reactor Interface">VERI</abbr> logs
  confirm the anomaly. As Dr. Vasquez noted,
  <q>the readings exceed all theoretical models</q>
  (<cite>Void Research Quarterly</cite>). This phenomenon, known as
  <dfn>energy cascade</dfn>, occurs when containment thresholds are
  breached. The <s>original safety protocols</s> have since been
  replaced.
</p>

The cast, and where you'd actually use each

Edits and corrections. <ins> and <del> are added and removed content — they pair up for change tracking, and both accept datetime and cite attributes so the edit is machine-readable. <s> is the one people conflate with <del>: it marks content that's no longer accurate or relevant (a stale price, an outdated claim), which is a different statement than "this was deleted." Two elements exist precisely because those mean different things.

Notation.  and  are for cases where the position carries meaning — chemical formulas (H₂O), exponents (I²R), ordinals, footnote markers — not for "make it small and raised." <var> is a variable in math or code, which is why P, I, and R above are each wrapped in one.

Reference and meaning.  is a relevance highlight — it's literally what search engines use to highlight your query in the results. <abbr title="…"> gives an abbreviation its expansion, surfaced as a tooltip. <dfn> marks the one spot where a term is defined (its introducing instance, not every later mention). <cite> is the title of a work — a book, paper, album — and notably not a person's name, which is the thing nearly everyone gets wrong. And <q> is an inline quotation where the browser inserts the quotation marks for you: correct for the document's language, and correctly nested if you put a quote inside a quote. You never type a " again.

Why bother

Every one of these throws a bit of meaning into the page that a styled  silently discards. Screen readers announce them. <q> localizes its punctuation. <abbr> exposes the long form. <ins>/<del> are a real, parseable changelog. A  looks the same and means nothing.

The only honest reason to avoid them is that the browser defaults are inconsistent and, frankly, ugly —  is highlighter-yellow, <q>'s marks are whatever, half of them are unstyled. But that's a few lines of CSS, not a law of physics. Give  a brand-tinted background, <ins> a green underline, <abbr> a dotted one, <q> colored quote marks, <dfn> an italic weight — and suddenly an entire sentence of semantic richness reads as clean, deliberate typography.

Most of these you'll reach for maybe once a year. But once a year correctly — with the meaning intact and the styling handled — beats a  that's lying about what it is.

Liquid glass needs a ladder

Dimon — Sun, 14 Jun 2026 13:02:34 +0000

Everyone wants the lens right now — the Apple-style glass where content doesn't just blur behind a surface but visibly bends around its rim. And you can build it on the web today: SVG displacement filters plugged into backdrop-filter produce a genuinely convincing lens.

Here's the problem: backdrop-filter: url(#some-svg-filter) works in exactly one engine family. Safari ignores it. Firefox does something worse — it parses it as valid, then renders nothing, which turns your beautiful glass panel into a fully transparent hole with text floating over whatever's behind it. And even where it works, it costs real GPU time that a phone doesn't want to spend.

So the question isn't "how do I build liquid glass." It's "how do I ship liquid glass to the users who can render it without shipping a broken page to everyone else." The answer that ended up in the design system I've been building is a ladder — four tiers of glass, each falling through to the one below automatically:

Tier	What it is	Gate
2 — geometric lens	per-element displacement map matched to the surface's shape	opted-in signature surfaces only
1 — noise warp	one global SVG turbulence filter — the "liquid" wobble	Chromium, confirmed at runtime
0 — blur + saturate	plain CSS `backdrop-filter: blur() saturate()`	`@supports (backdrop-filter: …)`
— opaque surface	a solid background color	none — this is the floor

A surface that opts into the lens but runs on Firefox falls back to the noise warp's gate, fails that too, and lands on plain blur. A browser with no backdrop-filter at all gets a solid, fully readable panel. Nothing configures this per-surface; the gates compose. You can't regress anything — each tier only ever adds on top of what's already there.

The rest of this post is the four decisions that made the ladder actually work, because the tier table is the easy part.

1. Never trust `url()` in backdrop-filter — gate it twice

The naive version writes the SVG filter reference straight into the stylesheet. Two real failures come out of that:

Firefox accepts the declaration as syntactically valid — so your @supports checks pass — and then renders nothing. The surface becomes transparent. This is the nastiest kind of cross-browser bug: not a missing enhancement, an actively broken page.
Chromium has a race: if the CSS references the filter before the SVG node is hydrated into the DOM, the surface flashes transparent on load.

The fix is to never let CSS reference the filter unconditionally. The stylesheet keys the tier-1 rule on an attribute — html[data-liquid-glass] — and a tiny runtime sets that attribute only after two things are true: the SVG filter is actually in the DOM, and the engine is one that can render it. CSS stays declarative, the gate is one attribute, and a browser that would break simply never matches the selector — leaving tier 0's plain blur standing.

2. Hold the blur constant across every tier

The ladder upgrades a surface after first paint: tier 0 renders immediately, then the runtime confirms the engine and swaps in the higher tier a few hundred milliseconds later. That lag is harmless only as long as the upgrade is invisible.

The first version I built wasn't. I'd tuned each tier's blur on its own, and they didn't match — the base tier ended up noticeably heavier than the lens. So every page load played out the same way: a surface painted with that heavy frost, then visibly thinned out to a much lighter blur the moment the lens kicked in. The material itself appeared to change mid-load. It read as a glitch, because it was one.

The rule that fixed it: all three tiers share the exact same blur radius. Stepping from tier 0 to 1 to 2 only ever swaps the displacement — the wobble, the rim bend — never the frost amount. Upgrades become invisible; the surface just quietly gains refinement. If you build any multi-tier visual effect, find the parameter the eye anchors on (here: blur) and freeze it across tiers. Degrade and upgrade along every other axis.

3. The lens is for small chrome — and that's a feature

The geometric lens displaces a band along the surface's rounded border. On a small element — a pill-shaped nav bar, a floating control, the circles in the video above — that rim refraction is gorgeous. On a large surface it falls apart in a specific way: any high-contrast straight edge in the backdrop kinks where it crosses the lens's corner, and with nothing to frame that bend it reads as a rendering bug, not as glass.

I learned this the expensive way: I put the lens on modals and a command palette, it looked wrong for exactly this reason, and I pulled it back to the noise warp. The scope rule that survived: tier 2 is opt-in, per signature surface, small chrome only. Tier 1 stays the default for every other glass surface. Not every tier of an enhancement ladder should be a global upgrade — sometimes the top tier earns its place precisely by being rare.

4. Engine and feature aren't the only gates

The full gate list for the lens tier ended up being five conditions, and only one of them is the classic @supports:

Feature — backdrop-filter exists at all (tier 0's gate).
Engine — Chromium, because of the Firefox parse-but-don't-render trap above.
Material — the surface is actually glass right now. (My system has multiple visual physics (glass / flat / retro), and the lens applies only under glass; switch themes and it releases itself.)
Pointer — fine pointers only. The lens is a desktop refinement; on touch devices it's GPU cost without payoff, so phones get the noise warp or plain blur.
Motion preference — prefers-reduced-motion disables the displacement and falls back to the static blur chemistry.

"Progressive enhancement" usually gets shortened to a single @supports query. For filter-level effects, it's a matrix — feature, engine, material, input device, accessibility preference — and the clean way to manage that matrix is exactly the ladder: every gate that fails just drops the surface one tier, and every tier below is already correct.

The demo

The video at the top is one page with three circles over the same scrolling backdrop — tier 0, tier 1, tier 2, side by side. Watch the stripes: under plain blur the edges soften but stay straight; under the noise warp they wobble; under the lens they bend around the rim while the center stays calm. Same markup, same blur radius, three different filters — and on a browser that can't render the fancy ones, all three circles would quietly look like the first.

That's the whole idea. Liquid glass isn't one effect; it's a ladder you let each browser climb as far as it can.

The three physics of UI: glass, flat, and retro

Dimon — Fri, 12 Jun 2026 14:26:24 +0000

Every design system I've used has a theme switcher. Dark mode, light mode, maybe an accent color. And after you've swapped every color in the palette, all of your themes still behave like the same material: shadows fall the same way, corners curve the same way, hover states move at the same speed with the same easing. You haven't changed what the UI is made of. You've repainted it.

When I designed theming for the design system I've been building, I ended up splitting it into three independent axes:

Palette — which colors.
Mode — light or dark.
Physics — what material the interface is made of.

This post is about the third axis: what a "physics" actually is, why my system ships exactly three of them, and the one physics × mode combination it refuses to render.

What I mean by "physics"

A material, in UI terms, is a set of rules about light and time. Not a color — a behavior. My system has three:

Glass — the object emits light. Surfaces are translucent with a backdrop blur. Borders are thin. Shadows aren't black — they're derived from the canvas color, so depth reads as atmosphere, not dirt. On hover, elements physically lift a few pixels, and the lifted shadow includes a glow in the accent color, because in this material the surface itself is the light source. Motion is springy: overshooting cubic-beziers, slightly slower durations. Things float.

Flat — external light casts shadows. Surfaces are opaque. Shadows are neutral black at very low opacity — 5 to 10 percent, the way paper shadows under office lighting actually look. Nothing glows, ever. Nothing lifts on hover. Easing curves are quick and polite, with no overshoot. This is the material almost every product you use today is made of.

Retro — there is no light model. No soft shadows at all. The "shadow" under a raised element is drawn, not cast: a hard 3px 3px 0 offset in a solid color, the way a pixel artist would draw it. Border radius is zero everywhere. Borders are thick. And — my favorite detail — every duration token is 0ms, and the easing functions are steps(2) and steps(4). State changes snap. The era this material quotes couldn't animate, so the material doesn't either.

In CSS, the whole mechanism is one data attribute and a set of custom properties:

[data-physics='glass'] {
  --radius: 12px;
  --speed: 300ms;
  --ease: cubic-bezier(0.34, 1.56, 0.64, 1);  /* springy, overshoots */
  --lift: -3px;                               /* hover raises the surface */
  --shadow-lift: 0 8px 28px -4px var(--shadow-tint),
                 0 0 12px var(--glow);        /* ...and it glows */
}

[data-physics='flat'] {
  --radius: 12px;
  --speed: 130ms;
  --ease: cubic-bezier(0.22, 0.61, 0.36, 1);  /* quick, no overshoot */
  --lift: 0px;                                /* nothing floats */
  --shadow-lift: 0 4px 12px rgb(0 0 0 / 0.1); /* neutral, barely there */
}

[data-physics='retro'] {
  --radius: 0;
  --speed: 0ms;                               /* state changes are instant */
  --ease: steps(2);                           /* what little moves, steps */
  --lift: -2px;
  --shadow-lift: 3px 3px 0 var(--accent-dim); /* drawn, not cast */
}

Components only ever consume the variables — var(--speed), var(--ease), var(--shadow-lift) — and never know which material they're rendered in. That's the entire trick. One component tree, three materials, zero per-component branching.

Why these three? Because UI history did it first

I didn't pick three aesthetic moods I happened to like. The three materials fall out of how screen UI actually evolved:

1. The terminal era (retro, dark). Phosphor characters on a black tube. A character grid: hard edges, no curves, no transitions — the screen redraws, it doesn't animate. Green or amber light on darkness.

2. The paper era (retro, light). When bitmapped GUIs arrived — the Xerox Alto, the original Macintosh — they were deliberately black-on-white, because the metaphor was paper. Documents, desktop publishing, WYSIWYG. The geometry stayed hard and the motion stayed instant; only the light flipped. Today's neo-brutalism trend is this era quoted back at us.

3. The flat era (flat, both modes). Metro, then iOS 7, then Material. The industry threw out texture and ornament and settled on the external-light model: opaque surfaces, minimal neutral shadows, restrained motion. This is still the mainstream default — it's what "a normal app" looks like in 2026.

4. The glass era (glass, dark). This one has been trying to happen for twenty years. Aero shipped translucent window chrome in 2007 and the hardware mostly couldn't carry it. iOS 7 smuggled frosted blur into the system even while flattening everything else. Then the glassmorphism trend, and now Apple has pushed translucent, light-emitting material across its entire platform line. The new trend is becoming the new mainstream.

The obvious objection: where's skeuomorphism? Where are the leather calendars and felt game tables of the 2000s? My answer is that skeuomorphism was never a light model — it was the external-light model wearing theatrical decoration. Textures, bevels, stitching: all of it was imagery layered onto the same physics flat design uses. Which is exactly why, when the decoration fell out of fashion in 2013, what remained underneath was flat. Materials survive trend cycles; decoration doesn't. That's the test I use for whether something deserves to be a physics.

So: three light models in roughly fifty years of screens. Everything else that looks like a "different era" is a palette riding on one of these three.

The part I didn't expect: physics owns time

I went into this thinking the physics axis was about shadows and corners. The bigger payoff turned out to be motion.

Most design systems define one global motion scale — duration-fast: 150ms, ease-standard: ... — and every theme inherits it. Which means every theme moves identically, and that's a big part of why ten themes can feel like the same product wearing different shirts.

In my system, duration and easing tokens live inside the physics layer. The consequence: a modal opening under glass enters slowly with a soft overshoot, like something surfacing through liquid. The same modal, same component, same code, under retro appears in two frames via steps(2). Under flat it's quick and businesslike. No component opted into any of this. Moving time into the material was a one-time architectural decision that made every current and future component era-correct for free.

If you take one implementation idea from this post, take that one: a material is a light model plus a time model. If your timing tokens are global, your materials are paint.

The combination I refuse to render

Three physics × two modes = six combinations. My system ships five. Ask for glass in light mode and the runtime silently corrects it to flat.

That sounds like a bug, or at best laziness. And I know the obvious objection: Apple has spent years teaching everyone that glass looks perfect in light mode. So let me be precise about what I'm actually claiming — because it's narrower, and it's defensible.

The claim is not "light glass can't exist." The claim is that this glass — and most glassmorphism you see on the web — is an emissive material, and emission doesn't survive light mode. Dark glass differentiates itself through accent glows, canvas-tinted shadows, specular highlights on translucent surfaces. All of that reads because it's light against darkness. A light surface cannot emit — light-on-light is invisible. That's optics, not taste.

Strip the emission out and what's left is translucency: backdrop-filter: blur(). And blur has a precondition people forget — it needs something behind it. Blur is an averaging filter, and the average of a solid color is the same solid color. You can verify this in ten seconds: open any glassmorphism demo and replace the background photo with plain white. The glass disappears.

Apple never faces this problem, because Apple designed the content to always be there. Their glass is OS chrome — toolbars, docks, tab bars — floating over wallpapers and scrolling feeds. The backdrop is guaranteed. And where blur alone isn't enough, their material leans on refraction: edge lensing, specular highlights, content-aware tinting. Notice that's a different optical mechanism from emission. What Apple ships in light mode isn't dark glass with a light palette — it's another material, engineered for light from the start. Even then, they spent an entire beta cycle publicly seesawing its transparency after legibility complaints, and "Reduce Transparency" exists as an accessibility setting for a reason. Light glass walks a knife edge between invisible and illegible, and that edge is exactly where the world's best-resourced design team keeps adjusting its footing.

Product UI — the kind my system targets — is mostly panels over a solid canvas. No wallpaper, no photo feed passing behind every card. In that context, an emissive glass with the emission turned off renders identically to flat, except you're paying GPU cost for blur the user can't see. And a physics in my system is global: every surface, every component, the whole page. A material that's only visible where imagery happens to pass behind it isn't a material — it's an effect. Rather than ship a combination that quietly renders as flat-but-slower, the runtime corrects it.

So the matrix is deliberately ragged:

	dark	light
glass	✓	→ corrected to flat
flat	✓	✓
retro	✓	✓

I used to feel uneasy about that hole — asymmetric APIs look like design debt. I now think the opposite: mode support is a property of the material. The asymmetric matrix is physical honesty. The dishonest version is the complete matrix where one cell silently renders as a worse version of another cell.

And Apple doesn't contradict this — Apple confirms it. They earned light mode by engineering a refraction-first material from scratch, not by relaxing a dark one. If I ever want light glass, that's the honest path: a fourth physics, built for light, with its own rules. Never a palette swap on this one.

The clamp I got wrong

Here's the part that earns the previous section, because I almost made the same call twice and one of them would have been a mistake.

Originally retro was clamped to dark mode too. CRTs are dark — obviously. But when I actually audited why retro needed darkness, the material decomposed into two layers. There's a phosphor layer — the emissive, glowing-characters-on-black part — which is genuinely dark-only, same argument as glass. And there's a structural layer — zero radius, stepped motion, hard drawn offsets — which doesn't reference light at all.

Put the structural layer on warm paper-colored ink with a typewriter monospace and you don't get "broken retro." You get the paper era from the history section: early Mac, print, neo-brutalism. Historically real, visually coherent, and it cost almost nothing to support because the geometry never cared about mode in the first place. The dark coupling had been palette convention, not physics.

So I asked the same question of two materials — "can this work in light mode?" — and got opposite answers. Glass: no, because its identity is emission. Retro: yes, because its identity is geometry. The answer lives in the material, not in the theming API. A blanket rule in either direction — "every physics supports both modes" or "exotic physics are dark-only" — would have been wrong once.

What I'd steal from this if I were you

You don't need three materials. But if you're building or maintaining a theme system, four things transfer:

Make material an axis, orthogonal to palette and mode. Even two materials force the right architecture: components consume physics variables and stop hardcoding what light does.
Define a material as light + time. Shadows, radius, blur — and durations, easings, hover displacement. The motion half is the one everyone forgets and the one users feel most.
Let materials refuse modes. Auto-correct invalid combinations at the runtime level instead of rendering something subtly broken. A ragged support matrix you can explain beats a complete one you have to apologize for.
Before adding a theme, ask: new light model, or new colors? Almost always it's new colors — a palette entry, cheap, add as many as you want. A new light model is rare and expensive. UI history has produced about three in fifty years. If you think you've found a fourth, you're either wrong or you're early — both are worth knowing.

The whole industry is mid-transition into the glass era right now, which makes it a strange and useful moment: for once, the mainstream material and the trending material are different. A theme switcher can't express that difference. A physics axis can.