DEV Community: Andrés Clúa

Stop Letting AI Decide Your JavaScript Architecture

Andrés Clúa — Thu, 05 Nov 2026 21:32:04 +0000

AI can generate working code in seconds. But working code and good architecture are two very different things.

We've reached a point where generating JavaScript is no longer the difficult part.

You can ask an AI coding assistant to build a slider, a modal system, a router, or an entire application, and chances are you'll get something functional within minutes.

That's impressive.

But there's a question we don't ask often enough:

Who is making the architectural decisions?

When AI creates a class, introduces an abstraction, extends a base component, or splits something into five different modules, it's making decisions that will influence how your codebase evolves.

And those decisions aren't necessarily wrong.

They're just not necessarily right, either.

The problem is that we tend to evaluate AI-generated code by asking one question:

Does it work?

I think we should be asking another:

Will this still make sense when the requirements change?

Let's explore that with a small JavaScript experiment.

1. The Experiment: One Slider, Three Architectures

Imagine we're building a lightweight JavaScript slider.

Nothing particularly complicated.

Our initial requirements are simple:

Navigate between slides.
Support autoplay.
Emit events when slides change.
Expose a small public API.
Allow functionality to be extended later.

We could give an AI coding assistant this prompt:

Build a lightweight JavaScript slider with navigation, autoplay, and change events. Use modern JavaScript.

That's it.

No architectural requirements. No preferences for composition, inheritance, or functional programming.

Now here's the interesting part.

There isn't one objectively correct implementation.

An AI might generate a single class, a hierarchy of classes, several modules, or a collection of functions.

All of them could work.

So rather than pretending one particular architecture is what every AI would generate, let's compare three valid approaches and see what happens when we add complexity.

2. Approach One: The Everything Class

Our first implementation puts all the functionality inside a single class.

class Slider {
  #index = 0;
  #timer = null;
  #listeners = new Set();

  constructor(slides, interval = 3000) {
    this.slides = slides;
    this.interval = interval;
  }

  next() {
    this.#index =
      (this.#index + 1) % this.slides.length;

    this.#emitChange();
  }

  onChange(callback) {
    this.#listeners.add(callback);

    return () => this.#listeners.delete(callback);
  }

  startAutoplay() {
    this.stopAutoplay();

    this.#timer = setInterval(() => {
      this.next();
    }, this.interval);
  }

  stopAutoplay() {
    clearInterval(this.#timer);
    this.#timer = null;
  }

  #emitChange() {
    for (const callback of this.#listeners) {
      callback(this.#index);
    }
  }
}

For the sake of the example, assume the slider receives a non-empty array of slides.

This implementation isn't terrible.

Actually, for a small project, it's pretty reasonable.

It has encapsulated state, a straightforward public API, and very little indirection.

But notice what happens as the library grows.

We want to introduce:

Previous-slide navigation.
Looping and non-looping modes.
Different autoplay behaviors.
Keyboard controls.
Custom transitions.
Touch and swipe interactions.

Now the Slider class starts accumulating responsibilities.

Navigation logic, event management, timing, input handling, and rendering all live in the same place.

Every new feature potentially touches the same class.

The problem isn't that we used a class. It's that one class is becoming responsible for too many things.

Still, we shouldn't immediately rewrite it.

Complexity needs to justify abstraction.

3. Approach Two: Inheritance

One way to organize this functionality is through inheritance.

class BaseSlider {
  constructor(slides) {
    this.slides = slides;
    this.index = 0;
  }

  next() {
    this.index =
      (this.index + 1) % this.slides.length;
  }
}

class AutoplaySlider extends BaseSlider {
  startAutoplay() {
    this.timer = setInterval(() => {
      this.next();
    }, 3000);
  }

  stopAutoplay() {
    clearInterval(this.timer);
  }
}

class AnimatedSlider extends AutoplaySlider {
  animate() {
    // Run transition animation
  }
}

This looks nicely organized.

We have a base class and specialized implementations.

But something subtle has happened.

An animated slider now inherits autoplay behavior, whether it needs it or not.

What if we want an animated slider without autoplay?

Or autoplay without animations?

What if we want multiple interchangeable animation engines?

We could introduce more subclasses, but eventually we risk creating an increasingly complicated hierarchy.

BaseSlider
  └── AutoplaySlider
       └── AnimatedSlider
            └── TouchSlider

The hierarchy is starting to describe combinations of features rather than genuine relationships between types.

And that's where inheritance becomes uncomfortable.

Inheritance is useful when one class is a meaningful specialization of another.

It becomes problematic when we're using it simply to assemble features.

Not every reusable behavior needs to become a parent class.

4. Approach Three: Composition

Let's try a different approach.

Instead of asking what our slider should inherit, let's ask what responsibilities it needs.

We identify three pieces:

A navigation system.
An autoplay controller.
An event system.

Each can be implemented independently.

class Navigation {
  #index = 0;

  constructor(length) {
    this.length = length;
  }

  next() {
    this.#index =
      (this.#index + 1) % this.length;

    return this.#index;
  }
}

class Autoplay {
  #timer = null;

  start(callback, interval) {
    this.stop();

    this.#timer = setInterval(
      callback,
      interval
    );
  }

  stop() {
    clearInterval(this.#timer);
    this.#timer = null;
  }
}

Our main slider becomes responsible for coordinating these pieces.

class Slider {
  #navigation;
  #autoplay;
  #listeners = new Set();

  constructor(slides, options = {}) {
    if (!slides.length) {
      throw new Error(
        "Slider requires at least one slide"
      );
    }

    this.#navigation =
      options.navigation ??
      new Navigation(slides.length);

    this.#autoplay =
      options.autoplay ??
      new Autoplay();
  }

  next() {
    const index = this.#navigation.next();

    for (const callback of this.#listeners) {
      callback(index);
    }
  }

  onChange(callback) {
    this.#listeners.add(callback);

    return () => this.#listeners.delete(callback);
  }

  startAutoplay(interval = 3000) {
    this.#autoplay.start(
      () => this.next(),
      interval
    );
  }

  destroy() {
    this.#autoplay.stop();
    this.#listeners.clear();
  }
}

Now navigation and autoplay are separate responsibilities.

We can test them independently.

We can substitute implementations without changing the slider's public API.

And we haven't needed a complicated class hierarchy.

That's composition.

But there's something important worth mentioning.

Composition isn't automatically better just because we've created more classes.

If our slider only needs ten lines of logic and will never grow, introducing multiple modules might make the code harder to understand.

The goal isn't to maximize modularity.

It's to introduce useful boundaries where they actually make sense.

5. Eight OOP Techniques That Solve Different Problems

This is where I think AI-generated code becomes particularly interesting.

We often discuss object-oriented programming as though it were one architectural approach.

But OOP includes several techniques, each solving a different problem.

Understanding their differences makes it much easier to decide when to use them.

1. Encapsulation: Protect Internal State

Encapsulation controls access to an object's internal data and behavior.

class Slider {
  #index = 0;

  next() {
    this.#index++;
  }

  get index() {
    return this.#index;
  }
}

Consumers can read the current index, but they can't directly modify the private field.

Use it when: you want to enforce state invariants and prevent consumers from depending on implementation details.

2. Inheritance: Specialize Existing Behavior

Inheritance allows a class to reuse and extend another class's behavior.

class Component {
  destroy() {
    console.log("Destroyed");
  }
}

class Slider extends Component {}

Here, Slider inherits destroy().

Use it when: there's a genuine is-a relationship and the subclass can safely fulfill the expectations of its parent.

Avoid using inheritance purely to share unrelated functionality.

3. Composition: Combine Independent Behaviors

Composition builds complex objects from smaller objects.

class Slider {
  constructor(navigation, autoplay) {
    this.navigation = navigation;
    this.autoplay = autoplay;
  }
}

The slider has a navigation system and has an autoplay controller.

It doesn't need to inherit from either.

Use it when: responsibilities can evolve independently or features need to be combined in different ways.

4. Polymorphism: Interchange Implementations

Polymorphism allows different objects to be used through the same expected interface.

Consider a page-transition library.

class FadeTransition {
  run(element) {
    return element.animate(
      [{ opacity: 0 }, { opacity: 1 }],
      { duration: 300 }
    ).finished;
  }
}

class SlideTransition {
  run(element) {
    return element.animate(
      [
        { transform: "translateX(100%)" },
        { transform: "translateX(0)" }
      ],
      { duration: 300 }
    ).finished;
  }
}

Both expose the same run() method.

Our transition controller doesn't need to care which implementation it's using.

class TransitionController {
  constructor(effect) {
    this.effect = effect;
  }

  run(element) {
    return this.effect.run(element);
  }
}

Use it when: different implementations share a meaningful contract.

JavaScript doesn't require formal interfaces to achieve this. Objects can satisfy contracts through their behavior.

5. Abstraction: Hide Unnecessary Complexity

Abstraction exposes what a system does without forcing consumers to understand how it works.

slider.next();
slider.startAutoplay();
slider.destroy();

The consumer doesn't need to know how timers, event listeners, or internal state are managed.

That's the purpose of a good public API.

Use it when: implementation details would otherwise leak into consuming code.

Encapsulation and abstraction are related, but they're not identical: encapsulation controls access, while abstraction simplifies the model exposed to consumers.

6. Dependency Injection: Receive Dependencies

Dependency injection means a class receives dependencies rather than constructing all of them internally.

class PageLoader {
  constructor(fetcher = fetch) {
    this.fetcher = fetcher;
  }

  async load(url) {
    const response = await this.fetcher(url);

    if (!response.ok) {
      throw new Error("Request failed");
    }

    return response.text();
  }
}

Now we can provide another fetch implementation, including one for tests.

Use it when: dependencies need to be replaced, configured, or tested independently.

You don't need a dependency-injection framework to use dependency injection.

7. Delegation: Let the Right Object Do the Work

Delegation is about forwarding responsibility to another object.

class Slider {
  constructor(navigation) {
    this.navigation = navigation;
  }

  next() {
    return this.navigation.next();
  }
}

The public API belongs to Slider, but navigation logic lives in Navigation.

Use it when: a class should coordinate behavior without implementing every operation itself.

Delegation and composition often work together, but they describe different things.

8. Mixins: Share Behavior Across Classes

Mixins allow behavior to be added to multiple classes without creating a parent-child relationship.

const EventEmitter = {
  emit(event) {
    console.log(event);
  }
};

class Slider {}
class Modal {}

Object.assign(Slider.prototype, EventEmitter);
Object.assign(Modal.prototype, EventEmitter);

Both classes gain an emit() method.

Use it when: sharing behavior this way is appropriate and the resulting method ownership remains clear.

Personally, I'd be careful with mixins. They can introduce naming collisions and make it difficult to understand where behavior originates.

In many cases, an explicit composed object is easier to maintain.

6. The Real Test: Change the Requirements

Let's return to our slider.

Imagine a new requirement arrives:

We need to support different autoplay strategies. Some sliders should advance at a fixed interval, while others should wait until the current animation finishes.

This is where architectural decisions become visible.

With the everything class, we might add conditionals to the existing timer logic.

With the inheritance-based architecture, we might introduce more subclasses or override existing methods.

With composition, we can introduce another autoplay implementation.

class AnimationAwareAutoplay {
  #running = false;

  async start(advance, delay) {
    this.#running = true;

    while (this.#running) {
      await new Promise(resolve =>
        setTimeout(resolve, delay)
      );

      if (!this.#running) break;

      await advance();
    }
  }

  stop() {
    this.#running = false;
  }
}

For simplicity, this example shows the scheduling mechanism; a production implementation would also need cancellation and lifecycle handling for pending waits.

The important part is that we can replace the autoplay behavior without rewriting the slider itself.

That's a meaningful benefit of composition.

But here's the catch.

The best architecture isn't necessarily the one with the most flexibility. It's the one with the appropriate amount of flexibility.

If we never need multiple autoplay strategies, a separate abstraction might not be worth maintaining.

This is why architectural decisions should be evaluated against real requirements, not just theoretical extensibility.

And it's exactly the kind of reasoning I want an AI coding assistant to perform.

7. The Instructions I Give AI Before It Writes JavaScript

Instead of asking AI to "write clean, scalable, maintainable code," I'd rather give it specific architectural guidance.

Here's a reusable set of instructions for a CLAUDE.md, AGENTS.md, or similar project configuration.

## JavaScript Architecture Guidelines

### Core principles
- Prefer composition over inheritance.
- Favor simple solutions over speculative abstractions.
- Keep responsibilities focused and explicit.
- Protect internal state through encapsulation.
- Design small, predictable public APIs.
- Follow KISS, DRY, and YAGNI.

### Classes and functions
- Use classes when managing persistent state,
  identity, or an object lifecycle.
- Prefer functions for stateless transformations.
- Avoid classes that only group unrelated helpers.
- Avoid unnecessary inheritance hierarchies.

### Dependencies
- Use dependency injection when dependencies
  need to be configurable or replaceable.
- Prefer explicit dependencies.
- Avoid introducing containers or frameworks
  without a concrete requirement.

### Extensibility
- Use polymorphism when multiple implementations
  share a meaningful contract.
- Prefer delegation over duplicating responsibilities.
- Avoid premature design patterns.
- Do not create interfaces or abstract layers
  for hypothetical future use cases.

### Before introducing an abstraction
Ask:
1. What problem does this abstraction solve?
2. Do multiple implementations actually exist?
3. Does it reduce coupling or just move code?
4. Would a simple function be clearer?
5. Is the added complexity justified?

### General rule
Choose the simplest architecture that satisfies
current requirements while allowing reasonable
future changes.

Do not overengineer.

These guidelines aren't meant to replace architectural judgment.

They're meant to establish a useful default.

And defaults matter.

Especially when a coding assistant can generate hundreds of lines before you've had time to question the first architectural decision.

8. What I'd Actually Evaluate in AI-Generated Code

I wouldn't judge an implementation by counting classes.

Or measuring how many design patterns it uses.

Or checking whether it follows every SOLID principle.

Instead, I'd ask:

Can I understand it?

Does the code communicate its responsibilities clearly, or do I need to jump between six abstractions to understand a simple operation?

Can I change it?

What happens when a new feature requires modifying an existing behavior?

Can I test it?

Can I test navigation without starting timers or interacting with the DOM?

Are the boundaries meaningful?

Are classes separated because they genuinely represent different responsibilities, or simply because someone decided smaller files are always better?

Is the complexity justified?

Would a function solve the same problem more effectively?

These questions apply to code written by humans and AI alike.

The difference is that AI makes it easier to generate complex structures without experiencing the effort of writing them.

And that can make unnecessary complexity harder to notice.

9. Composition Isn't a Religion

There's a danger in turning any architectural recommendation into an absolute rule.

"Always use composition" isn't much better than "always use classes."

Inheritance has legitimate uses.

A single class can be the right solution.

Functional programming can be more appropriate than OOP.

And sometimes a straightforward procedural implementation is all we need.

JavaScript is a multi-paradigm language.

That's one of its strengths.

We don't have to commit to one technique for every problem.

A useful default might be:

Functions for stateless logic. Classes for stateful objects. Composition for assembling independent behaviors.

But even that is a guideline, not a law.

The objective is to make deliberate decisions instead of following patterns automatically.

10. Stop Outsourcing Architectural Judgment

AI coding assistants are becoming remarkably good at producing working implementations.

And I think that's great.

But generating code and designing software aren't quite the same thing.

Architecture involves understanding constraints, anticipating likely changes, identifying meaningful boundaries, and deciding which complexity is worth introducing.

Those decisions require context.

Context that isn't always present in a prompt.

So the next time an AI assistant generates a perfectly functional class hierarchy, don't immediately accept it.

Ask why inheritance was necessary.

Ask whether composition would simplify it.

Ask whether the abstraction solves a real problem.

And, perhaps most importantly, ask whether the entire thing could have been a function.

AI doesn't need more design patterns. It needs better reasons to use them.

And until it has enough context to make those decisions reliably, architectural judgment should remain part of our job.

I Replaced Math.random() With CSS. Here Is What Works.

Andrés Clúa — Wed, 28 Oct 2026 21:27:25 +0000

Why I care about this

I build creative sites for a living. Almost every project has some small random detail. Cards that sit a bit crooked. Particles that start at different times. A hue that changes on every load.

For years, that meant the same ten lines of JavaScript. Loop over the elements, call Math.random(), write a CSS variable. It works. But it runs after the HTML loads, it needs a script, and it fights with my server rendering.

On October 20, Google shipped Chrome 156. It includes the CSS random() function. Safari already had it. So I spent a few evenings replacing my JavaScript with plain CSS.

This post is what I learned. What works, what does not, and the one thing that will confuse you if you read older tutorials.

The basic syntax

random() takes a minimum and a maximum. It returns a value between them. You can add a third value, a step, to snap the result to fixed increments.

.card {
  rotate: random(-4deg, 4deg);           /* any angle in the range */
  width: random(200px, 320px, 40px);     /* 200, 240, 280 or 320px */
  animation-delay: random(0s, 2s);
}

Three rules to remember, all from MDN:

Min, max and step must be the same data type. Lengths with lengths, angles with angles. Units can differ (1em and 40vw is fine).
The range is inclusive on both ends.
If max is smaller than min, you get the min value. No error, no warning. It works anywhere CSS accepts a length, angle, time, number, percentage, integer, frequency or resolution. That covers most of what I randomize.

The part that confused me: who shares the value

By default, every random() call is independent. Every element, every property, every position in a shorthand gets its own value. Most of the time that is what you want.

But sometimes you need a square. Width and height must be random, but equal. That is what the optional first argument is for. MDN calls it the <random-key>.

Key	Same value across elements?	Same value across properties?
`auto` (default)	No	No
`element-scoped`	No	Yes
`property-scoped`	Yes	No
`--my-name`	Yes	Yes
`--my-name element-scoped`	No	Yes, for calls with that name
`fixed 0.5`	You pick the seed (0 to 1)	Yes

So a set of random squares, each one a different size, looks like this:

.tile {
  width: random(--tile-size element-scoped, 60px, 140px);
  height: random(--tile-size element-scoped, 60px, 140px);
}

Here is the trap. Older articles, including the WebKit announcement and early Frontend Masters tests, use a keyword called element-shared. The spec has moved on. The current names are element-scoped, property-scoped and property-index-scoped. If you copy a snippet from 2025 and nothing happens, check this first.

One more gotcha. A normal custom property does not store a random result. --size: random(1px, 100px) is text substitution, so every var(--size) rolls again. If you want one stored value, register the property with @property. MDN explains this with a short example.

Example 1: a messy stack of cards

This is a pattern I use a lot. A grid of photos or cards that look like they were dropped on a table. Each one tilted and shifted a little.

Here is the JavaScript version I have shipped many times:

const cards = document.querySelectorAll('.card');

function randomBetween(min, max) {
  return Math.random() * (max - min) + min;
}

cards.forEach((card) => {
  card.style.setProperty('--tilt', `${randomBetween(-6, 6)}deg`);
  card.style.setProperty('--shift-x', `${randomBetween(-12, 12)}px`);
  card.style.setProperty('--shift-y', `${randomBetween(-12, 12)}px`);
  card.style.setProperty('--delay', `${randomBetween(0, 0.6)}s`);
});

.card {
  rotate: var(--tilt, 0deg);
  translate: var(--shift-x, 0) var(--shift-y, 0);
  animation: drop 0.5s var(--delay, 0s) both;
}

It works. But the cards render straight, then jump when the script runs. With server rendering you also get a mismatch between server and client values.

Here is the CSS version:

.card {
  rotate: random(-6deg, 6deg);
  translate: random(-12px, 12px) random(-12px, 12px);
  animation: drop 0.5s random(0s, 0.6s) both;
}

No script. No flash. Each card gets its own values because the default key is auto. The two values inside translate are also independent, because auto separates calls by their position in the declaration.

If you add the step argument, you get a more designed feel. Tilts of exactly -6, -3, 0, 3 or 6 degrees look less random and more intentional:

.card {
  rotate: random(-6deg, 6deg, 3deg);
}

Example 2: a palette that changes on every load

Pure random color looks bad. Fast. What I usually want is one random hue for the whole page, and small variations per element. That is where the keys pay off.

.blob {
  /* One hue for the whole page: a named key alone is global */
  --hue: random(--page-hue, 0, 360);

  /* Lightness varies per element, in steps of 10 */
  background: hsl(var(--hue) 70% random(35%, 75%, 10%));

  /* Each blob is a circle of its own size */
  width: random(--blob-size element-scoped, 80px, 240px);
  height: random(--blob-size element-scoped, 80px, 240px);

  /* Scatter them across the hero */
  position: absolute;
  top: random(0%, 90%);
  left: random(0%, 90%);
}

Every load gives you a new mood. But it always looks like one palette, because every blob uses the same --page-hue seed.

The JavaScript version needed one value for the page and one loop for the elements. Something like this:

const hue = Math.floor(Math.random() * 361);
document.documentElement.style.setProperty('--hue', hue);

document.querySelectorAll('.blob').forEach((blob) => {
  const size = 80 + Math.random() * 160;
  const light = 35 + Math.floor(Math.random() * 5) * 10;
  blob.style.setProperty('--size', `${size}px`);
  blob.style.setProperty('--light', `${light}%`);
  blob.style.setProperty('--top', `${Math.random() * 90}%`);
  blob.style.setProperty('--left', `${Math.random() * 90}%`);
});

Ten lines of script turned into a few declarations. For a hero section, I will take that trade every time.

Shipping it today: a fallback that only runs when needed

Firefox does not support random() yet. Smashing Magazine reports positive signals from Mozilla, but no release. So for client work, I treat it as progressive enhancement.

Step one: write a calm default first, then add the random layer inside a feature query. MDN uses order: random(1, 2) as the test, which is a nice trick.

.card {
  rotate: var(--tilt, 0deg);
}

@supports (order: random(1, 2)) {
  .card {
    rotate: random(-6deg, 6deg, 3deg);
  }
}

Step two: if the random effect really matters to the design, add a tiny script that only runs in browsers without support.

const supportsRandom = CSS.supports('order', 'random(1, 2)');

if (!supportsRandom) {
  const steps = [-6, -3, 0, 3, 6];
  document.querySelectorAll('.card').forEach((card) => {
    const tilt = steps[Math.floor(Math.random() * steps.length)];
    card.style.setProperty('--tilt', `${tilt}deg`);
  });
}

Chrome and Safari users get pure CSS. Firefox users get the old behavior. Nobody gets a broken page.

If you want one code path for every browser, CSS-Tricks covered a polyfill that resolves random() with JavaScript. I have not used it in production, so test it before you trust it.

Honest caveats

random() is great. It is not a full replacement for Math.random(). Here is where JavaScript still wins, or where you need to be careful.

You cannot re-roll on demand. The value is picked when styles are computed. There is no "shuffle" button. If a user action should create new values, you still need JavaScript.

Hover states may not change. With the default auto key, the browser builds the seed name from the property and position. So width: random(100px, 200px) on .foo and on .foo:hover share a seed, and nothing changes on hover. MDN shows this case. Use a different named key for the hover rule if you want a new value.

You cannot read the value easily. If your WebGL scene or GSAP timeline needs to know the exact random number, keep it in JavaScript. Syncing CSS randomness into a canvas is more work than it saves.

Contrast is your problem now. A random text color can land on an unreadable value. MDN warns about this directly. Randomize decoration, not readable content, or keep the range tight.

Motion still needs an off switch. Random delays and positions are often used in animation. Wrap that animation in prefers-reduced-motion like any other.

Support is still partial. Chrome 156 and Safari support it. Firefox does not, as of today. MDN still marks it as limited availability.

What to do this week

Open Chrome 156 or Safari and paste the card example into a CodePen. It takes two minutes and you will understand the keys faster than by reading.
Search your codebase for Math.random() used only to set styles. Those are your candidates.
Pick one decorative effect and move it to CSS behind @supports (order: random(1, 2)).
Keep a calm default for Firefox. Add the JavaScript fallback only if the effect is part of the design.
Ignore any snippet that uses element-shared. Translate it to element-scoped or a named key.
Leave anything interactive, readable or synced with canvas in JavaScript.

Tokens Are Not the Metric

Andrés Clúa — Tue, 06 Oct 2026 15:55:40 +0000

When developers start using AI seriously, one metric appears almost immediately: token usage.

How many tokens did this agent consume?
How much did this coding session cost?
Can we reduce the context window?
Can we use a cheaper model?

Those are reasonable questions. But they can also lead us toward the wrong optimization.

The goal should not be to use fewer tokens.
The goal should be to waste fewer tokens.

There is a big difference.

A million tokens can be cheap

Imagine two AI agents. These are hypothetical examples, not benchmark results.

	Agent A	Agent B
Tokens	50 million	5 million
What it does	Implements a feature	Repeatedly scans the same repository
	Writes tests	Retries failed tasks
	Fixes regressions	Summarizes information nobody reads
	Opens a pull request	Runs every 30 minutes
	Generates documentation	Produces no meaningful output
Result	Saves an engineer two days of work	Nothing

Which one is expensive?

Looking only at token consumption, Agent A looks ten times worse. Looking at actual value, Agent B may be the worse investment.

This is why I increasingly think about AI usage in three buckets: learning, production, and spin.

1. Learning tokens

These are the tokens we spend figuring things out:

Trying a new coding agent
Experimenting with MCP
Building a better system prompt
Testing whether an agent can translate a Figma design into production code
Letting a model explore an unfamiliar codebase

Some of this work will fail. That's fine.

In traditional software development, we don't expect every minute spent by an engineer to produce production code. We research. We prototype. We read documentation. We throw things away.

AI systems need the same space. Trying to aggressively eliminate this type of token usage can actually slow down adoption.

The important question isn't "How many tokens did we spend?"

It's "What did we learn from spending them?"

2. Production tokens

These are the easiest tokens to justify. They produce something useful:

A pull request
A migration
A test suite
A component
A technical document
A content update
A bug fix
An accessibility audit
A production deployment

Once AI moves beyond autocomplete and starts operating as an agent, token consumption becomes closer to compute.

You wouldn't measure a CI pipeline only by how many CPU seconds it consumed. You care about what the pipeline accomplished. AI should be evaluated the same way.

A useful metric might be:

AI cost / completed task
AI cost / pull request merged
AI cost / engineering hour saved

Suddenly, token usage becomes much more meaningful.

These metrics still need context: task complexity, quality, review time, and downstream rework. A merged PR is useful evidence, but it isn't proof that the work saved time.

3. Spin

This is where the real problem lives.

Spin is AI activity that looks productive but produces little or no value.

Some common examples:

Agents repeatedly reading the same files without a reason
Enormous context windows being resent unnecessarily
Automated jobs running far more often than needed
Multiple agents duplicating the same research
Retry loops without proper termination conditions
Long reasoning chains for trivial operations
Generated reports nobody reads
Background agents running simply because they can

This is the AI equivalent of an infinite loop with a cloud bill attached.

And as AI systems become more autonomous, spin becomes much easier to create. A developer using an AI assistant manually will eventually notice that something isn't working. A scheduled agent can waste money quietly for weeks.

The problem with "make it cheaper"

When AI costs start increasing, the first reaction is usually: use a cheaper model.

Sometimes that's correct. But it's often treating the symptom instead of the cause.

Suppose an agent performs a task 48 times per day when it only needs to run twice. Switching to a model that costs half as much sounds like an optimization. But reducing the execution frequency would cut the execution cost by roughly 96%, assuming the cost per run stays the same.

const costPerRun = 1;

const cheaperModel = 48 * (costPerRun * 0.5); // 24
const fewerRuns = 2 * costPerRun;            // 2

const savingsCheaperModel = 1 - cheaperModel / 48; // 0.50
const savingsFewerRuns = 1 - fewerRuns / 48;       // ~0.96

Architecture can matter more than model pricing.

Before changing models, I would ask:

Does this agent need to run this often?
Does it need the entire repository as context?
Can it retrieve only the relevant files?
Does every step need the most capable model?
Can deterministic code replace part of the workflow?
Does the output lead to an actual action?
Does the agent know when to stop?

These questions can produce much larger savings.

AI efficiency is becoming an engineering discipline

We already have mature ways of measuring traditional software systems: latency, CPU, memory, error rates, throughput, availability.

AI systems need their own operational metrics.

Cost per successful task

total AI cost / successfully completed tasks

Include failed runs in the numerator, and define success before running the workflow.

Retry rate

executions requiring at least one retry / total executions

A high retry rate can reveal brittle prompts, bad tools, or poor agent architecture.

Human intervention rate

tasks requiring human correction / total tasks

Track correction time too. A quick approval and a two-hour repair have very different costs.

Useful output rate

How often does an agent produce something that actually gets used?

Context efficiency

How much of the provided context was actually relevant? This is harder to measure directly, but comparing focused retrieval against larger context inputs can help.

Agent idle activity

How often does the system execute when nothing meaningful changed?

These are more useful indicators of AI efficiency than raw token counts alone.

The cheapest token is not always the best token

Developers have spent decades learning that premature optimization can make systems worse. AI is no different.

If a stronger model uses 30% more tokens but solves the problem correctly on the first attempt, it may be cheaper overall than a smaller model requiring five retries. The result depends on pricing and the work each attempt performs.

Likewise, giving an agent more context can sometimes reduce total cost if it prevents it from exploring blindly.

Token efficiency is not the same thing as token minimization. The objective is productive computation.

Think in terms of return

A useful starting point is:

value-to-cost ratio = value produced / total workflow cost

Total workflow cost should include AI execution, tools, human review, and rework. Estimating the value produced is harder, but ignoring it doesn't make the cost metric more useful.

A $20 agent run that saves four hours of engineering time is probably excellent.
A $0.20 automated task that runs thousands of times without producing anything useful is not.

As AI becomes embedded in engineering workflows, teams will need to become comfortable with this distinction. Otherwise, we risk optimizing systems for impressive-looking token dashboards rather than actual productivity.

The real optimization

So when your AI bill starts growing, don't immediately ask "How do we use fewer tokens?"

Ask:

Which spending produces useful work, which helps us learn, and which keeps the system busy without moving anything forward?

Here is how I would start:

Pick one workflow.
Define what success looks like.
Record the full cost of getting there.
Check whether anyone actually uses the output.
Remove unnecessary runs, bound retries, and make the stopping condition explicit.

Protect experiments that teach you something. Improve workflows that deliver useful work. Shut down activity that does neither.

That's a much better optimization target than a smaller number on a token dashboard.

Inspired by The Token Gym and its distinction between learning, shipped work, and spin. The agent scenarios and workflow examples above are illustrative.

What do you measure in your AI workflows today: token consumption, cost per task, or whether the output actually gets used? Let me know in the comments.

You Don't Need an LLM for Every Decision

Andrés Clúa — Wed, 23 Sep 2026 09:38:43 +0000

Most of the AI calls in my code never needed words. They needed a choice.

Route this ticket. Is this chunk useful. Should we retry. Is this tool call safe. All of them went to a text model. The model wrote tokens. My code parsed the JSON, checked it, and then a normal if made the real decision.

That is a lot of work for a yes or no.

Last week a new kind of model appeared. It does only the decision part. I tried it for a few days. Here is what it is, where it helps, and where it does not.

All examples are JavaScript, and I kept them small on purpose.

What a System One model is

TypeSafe released Jev on September 15, 2026, in early access. They call it the first public System One model.

The idea is simple. You send your application state. You send typed questions. You get back probabilities. There is no text. A normal LLM writes JSON one token at a time. This one returns typed answers directly.

All the answers come back in a single forward pass. That is why it is fast.

There are three question types:

Type	You give	You get
`noul`	a yes or no question	the probability of yes
`choice`	instructions plus named options	the chosen option, probabilities, confidence
`score`	instructions plus ordered levels	a number, probabilities, confidence

choice accepts up to 255 options. score accepts 2 to 10 levels.

The smallest example

Install it and run it. You need Node 20 or newer.

npm install @typesafe-ai/sdk
export TYPESAFE_API_KEY="your-key"

One question. One answer.

import { noul, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();

const response = await client.systemOne({
  state: "I was charged twice. Please fix this.",
  questions: {
    isBilling: noul("Is this about billing?"),
  },
});

console.log(response.answers.isBilling.noul); // 0.97

That number is the probability of yes. Nothing else comes back.

Now a question with options.

import { choice, TypeSafeClient } from "@typesafe-ai/sdk";

const response = await client.systemOne({
  state: ticketText,
  questions: {
    team: choice("Which team should read this?", {
      billing: "Payments and invoices",
      support: "Bugs and how-to questions",
      sales: "New customers and pricing",
    }),
  },
});

console.log(response.answers.team.choice); // "billing"
console.log(response.answers.team.confidence); // 0.88

The types come from the questions you wrote. No schema file. No parser. No retry when the JSON is broken.

You can also send several questions at once. They all travel in one request, which matters for the cost numbers below.

const response = await client.systemOne({
  state: ticketText,
  questions: {
    isBilling: noul("Is this about billing?"),
    isAngry: noul("Is the customer angry?"),
  },
});

Case 1: put it in front of your model, not instead of it

This is where I would start. The common advice at launch was not to replace your model. Let the small decision happen first, so the expensive model runs only when you really need it.

const gate = await client.systemOne({
  state: userMessage,
  questions: {
    needsWriting: noul("Does answering this need a written reply?"),
  },
});

if (gate.answers.needsWriting.noul < 0.5) {
  return sendCannedReply(userMessage);
}

return await callClaude(userMessage); // the expensive path, now less common

That 0.5 is my code, not the model. It is an example value, not a measured or recommended one. Choose yours from your own data.

Some numbers were reported from an email tool that made this change. Two AI calls per email became one decision call. A test with 120 tickets took 42 seconds instead of 22 minutes, and cost $0.0003 instead of $0.059. The person who ran the test said his slow version was also slowed down by retry errors, so the real gap is smaller.

Read that as a direction, not as a benchmark.

Case 2: check the output before you send it

This is the shape I liked most. The LLM writes the reply. The small model checks it.

const draft = await callClaude(prompt);

const check = await client.systemOne({
  state: { question: userMessage, draft },
  questions: {
    isGood: noul("Does the draft answer the question?"),
  },
});

if (check.answers.isGood.noul < 0.8) {
  return sendToHuman(draft);
}

return send(draft);

Use an object for state when you have more than one piece of context, like here. A plain string is fine when you have one.

The official advice is to ask only for judgments that a person who knows the topic could make in about a second. If a question needs slow thinking, split it into smaller questions and combine the answers in your own code.

That rule is the whole design. The model judges. Your code decides.

Case 3: check relevance before you build the prompt

This one is cheap and people talk about it too little. Before you put twenty retrieved chunks into a prompt, rate them.

Build the questions in a loop, one per chunk.

const questions = {};

chunks.forEach((chunk, i) => {
  questions[`chunk_${i}`] = noul("Does this passage help answer the question?");
});

const result = await client.systemOne({
  state: { question: query, passages: chunks },
  questions,
});

const keep = chunks.filter((chunk, i) => {
  return result.answers[`chunk_${i}`].noul > 0.6;
});

Send many questions at once, then filter in code. The prompt that reaches the expensive model gets smaller, and that is usually where the bill comes from.

If you want more than yes or no, score gives you levels instead.

score("How relevant is this passage?", ["not at all", "a little", "a lot"]);

There is already an unofficial LlamaIndex integration that does this. The model rates the retrieved passages and picks which tool answers a query. Note that score mode is a rubric, not cosine similarity.

Case 4: when the data cannot leave your servers

For agency work this is the important part. I would rather not explain to a client why their data goes to a third party on every routing call.

Jared Palmer, who built Turborepo and v0, released Kev. It is an open source family that follows the same interface. There are three models, 0.8B, 4B and 9B, and you can train, inspect and run them on your own hardware under Apache-2.0. The server, the weights and the training code stay local.

So the change is a base URL. The SDK appends /v1/systemone to it.

const client = new TypeSafeClient({
  baseURL: "http://localhost:8000", // your own server
});

Everything else in your code stays the same. You can also skip the constructor and set TYPESAFE_BASE_URL in the environment, so the same code runs against the hosted model in development and against your server in production.

You pay for this in accuracy. On the published numbers, Kev-9B gets 0.837 on the locked test set, against 0.857 for the hosted model. The cost of building it still surprises me. The whole port to Qwen3.5 was about $95 of Modal H100 time plus three cents of API calls.

Latency is not free either. Kev-4B on an Apple M5 took 779ms for five questions, up from 174ms on the earlier Qwen3 version. Measure it on your own hardware first.

Why this is worth an afternoon

You delete the parsing layer. No schema prompt, no JSON repair, no error branch that nobody tests.
The options are yours. You write the list of possible answers in your own code. The model does not invent them.
You get real probabilities. Confidence is a number you can compare against a threshold. That is how you build a safe fallback.
One request, many questions. You can classify, score and gate a ticket in a single call.
You can undo it. Put it behind a flag, keep the old call, run both for a week, compare, then delete.

The ecosystem is already usable. There are provider integrations for Cloudflare AI, the Netlify AI Gateway, OpenRouter and the Vercel AI Gateway. On the JavaScript side there are integrations for LangChain.js and Effect. In the Vercel AI SDK, the Boolean type is what TypeSafe calls Noul. Knowing that will save you ten minutes.

Honest caveats

I like this, and I am still not putting it in a client's critical path this month.

It is one week old. Early access, launched September 15, 2026.
The launch numbers are marketing numbers. The claims of 20 to 200 times faster and 40 to 400 times cheaper came from launch posts. The most careful writeup I found says clearly that it is an analysis of the documentation and architecture of Jev 1.13, not an independent latency test and not a production deployment.
The model is uneven. The TypeSafe docs list limits around arithmetic, dates, distractors, adversarial state and inconsistent structure. Do not ask it to do math.
The training data is synthetic. That is confirmed, and it is 100% synthetic. The architecture is still a guess from outside. The best guesses are ModernBERT and diffusion.
The open models are not the same model. The Kev README says clearly that no outputs from the hosted model were used for training. That is good practice, and it also means you get the same interface, not the same quality.
Confidence is not accuracy. Choice and Score report confidence separately from the answer probability, and Noul has no confidence field at all. Read that page before you write a threshold.

What I would do next

Search your code for AI calls whose output only ever feeds an if. Those are your candidates.
Pick the one with the most traffic. Ticket routing, moderation, relevance filtering.
Write the list of options in your own code, not in a prompt.
Put the decision call in front of the existing call, behind a feature flag, and keep the old path as a fallback.
Run both for a week and compare on your data, not on the launch benchmarks.
If the data cannot leave your servers, run Kev locally and point the SDK at it.
Only then delete the old call.

Here is the idea I keep coming back to. An agent is a long chain of small judgments with a little writing at the end. We have been paying the writing price for the whole chain.

The Problem Isn’t AI. It’s the Pace.

Andrés Clúa — Tue, 18 Aug 2026 21:42:00 +0000

Swipe and there is food at the door. Swipe and there is a date on Thursday. Swipe and there is a stranger's car outside taking you home.

Ask for a function and there is code. Ask for a design and there is a mockup. Ask for a summary of a forty page document and it is done before you have finished reading the first page yourself.

None of this felt like a decision. It arrived, and we adapted to the interface without ever adapting to the change.

That is the part I keep thinking about. Not whether the technology is good. Whether the gap between how fast it moves and how fast we absorb it is still a survivable gap.

The race is worth running

I want to be clear about where I stand, because the easy version of this article is a complaint, and I do not want to write that one.

I like this. I have built things in the last two years that I could not have built in the previous ten. I read release notes for fun. The speed is genuinely exciting and I am not nostalgic for a slower industry.

The problem is not the speed. It is that the speed now exceeds my ability to form an opinion about what is moving.

Where I notice it in my own work

The clearest version for me is tooling.

I wrote a while back about Rust taking over the JavaScript toolchain. Vite, Rolldown, the whole rewrite of the layer underneath everything we ship. It was a good story to write. It was also a story where, by the time I understood the tradeoffs well enough to have a real position, the position was already outdated.

That used to be an annoyance. Now it is the normal condition. I do not reach competence with a tool anymore. I reach a working familiarity, and then the tool changes, and I am back near the start with a slightly better instinct than last time.

Evaluation has become the bottleneck. Not learning. Deciding what is worth learning.

Multiply that by every developer on a team, and you get an organisation where nobody is deeply expert in anything because expertise takes longer to build than the thing takes to be replaced. That has architectural consequences. It is why so many codebases are now three eras of tooling stacked on top of each other, with nobody left who understands the bottom layer.

The honest version of "our brains cannot keep up"

The line I first wanted to write was that our brains do not finish processing the change. It feels true. It is how the tiredness actually feels from the inside.

But I do not think I can defend it as stated, and there is a lot of confident pop neuroscience about attention spans and dopamine that does not survive contact with the actual research. So let me say the thing I can defend instead.

What lags is not biology. It is everything built on top of biology.

Norms take years. Nobody knew what phone etiquette was for a decade. Laws take longer. Professional identity takes a career, which is why a developer who trained on one paradigm spends their whole working life partly translating. Institutions are the slowest of all, and they are the layer that decides what is permitted rather than what is possible.

Those lags are measurable. You do not need a claim about neurons. The technology iterates in months and the scaffolding around it iterates in decades, and every year that ratio gets worse.

Every generation said this

I have to include this part or the article is dishonest.

People said it about the printing press. The telegraph. Radio. Television. The internet. Every one of those came with a serious argument that human beings were about to be overwhelmed, and in every case we absorbed it and the panic reads as quaint now.

"This time is different" is the most overused sentence in technology. I do not get to skip that objection just because I feel tired.

So here is the only version of the difference I can actually argue for, and I hold it loosely.

Every previous case had a plateau. The technology arrived, there was a shock, then a long flat stretch while people, laws and habits caught up, and then the next thing. The plateau is what made it survivable. Adaptation happened during the pause.

The proposal on the table now is to remove the pause.

Which brings me to the letter

On July 28, 2026, more than a thousand employees of the frontier AI labs signed a statement called Pacing the Frontier. The site listed 1,178 signatories when I checked and the form is still open. Anthropic, OpenAI, Google and Meta are all represented, including several CEOs and chief scientists.

They are not asking for a pause. The single request is that the U.S. government support an international effort to build the technical and governance tools needed to "deliberately pace the frontier of automated AI development."

Automated AI development is the phrase that matters. Models used to build better models, which are then used to build better models again. That is a description of a process with no plateau in it. The gap between capability and comprehension stops being constant and starts compounding.

What struck me most was not the request. It was the personal comments on the signatory page. Several of them are people who work on capability evaluations for a living saying the recent pace has been a shock to them too.

That is the same feeling I have on a much smaller scale about build tools. It goes all the way up. Nobody is standing somewhere calm.

So what do we actually do

I do not have a policy answer. I build websites and internal tools. The governance question is above my pay grade and I am suspicious of developers who pretend otherwise.

But I have a working answer for myself, and it is not "keep up."

Keeping up is no longer a coherent goal. There is more happening per week than any person can evaluate, and treating that as a personal failure is a category error. The skill is not consumption. It is choosing what to deliberately not keep up with, and being at peace with that choice.

For my own work that means a short list of things I go deep on and a much longer list I let pass. It means I do not adopt a tool until it has survived long enough to have known problems. It means I write about things a few weeks late, once the first wave of takes has burned off and there is something real to say.

That is a personal mitigation, not a solution. The version of this problem that operates at the scale of an industry does not get solved by individuals choosing to read less. Which is, I think, the strongest thing the letter has going for it. It is the institutional form of the same admission. Someone should be allowed to say wait, and right now nobody is.

I do not think we should stop out of fear. I do think there is something absurd about waiting until we have lost control before starting the conversation about how we would want to exercise it.

Sources: the statement and signatory list at pacingthefrontier.com, with reporting from The Next Web. Signatory counts were accurate at the time of writing.

How to Tell If You Can Actually Drop Your Animation Library

Andrés Clúa — Tue, 11 Aug 2026 11:56:46 +0000

The Demo Is Not the Migration

Every post telling me to delete my animation library opens with the same snippet.

.progress-bar {
  animation: grow linear;
  animation-timeline: scroll();
}

@keyframes grow {
  from { transform: scaleX(0); }
  to   { transform: scaleX(1); }
}

Zero bytes. Native platform. The browser does it now.

That code is real, it works, and it is genuinely great. It is also not the decision.

I lead a team that builds animation-heavy sites, so when scroll-driven animations got real browser support I took the question seriously. I expected to come out with a smaller bundle. I came out with two conclusions that sit oddly together: this is the most fun I have had with the platform in years, and I am not removing GSAP from a single project.

The reason is not that CSS is worse. It is that a stack decision is not scored on its best example.

How this decision actually works

Nobody switches stacks because the new thing is prettier. You switch when everything you currently do has an equivalent in the new thing, or when the gaps are small enough to absorb.

So the question is never "can CSS do a progress bar." It is: go through the animations that exist in your codebase right now, every one of them, and find the ones with no equivalent. Those are the whole decision. The happy path is not information, because the happy path is what the demo already showed you.

And there is arithmetic that people skip. If forty animations move to CSS and three cannot, the library is still in your bundle. You did not save 35 KB. You saved nothing, and now you maintain two animation systems, two mental models, two sets of debugging habits, and a rule about which one owns what. Partial migration is often more expensive than either endpoint.

That reframes what the rest of this article is for. It is not a comparison table. It is the inventory: what has an equivalent, what has a partial one, and what has none. I would rather you finish it able to run the same audit on your own projects than agree with my conclusion.

Starting with the thing almost every comparison gets wrong.

CSS can scrub. That was never the gap.

Scrubbing is exactly what animation-timeline does. Animation progress is tied to scroll position, one to one. The snippet at the top of this article is a scrubbed animation, running off the main thread, with no library.

What CSS does not have is smoothed scrub:

gsap.to('.panel', {
  x: -1000,
  scrollTrigger: { trigger: '.section', scrub: 1 }
})

scrub: true is one to one, same as CSS. scrub: 1 means the animation takes a second to catch up to the scroll position. It lags behind you. It eases toward the target instead of snapping to it.

That single digit is a large part of why GSAP work feels expensive and CSS scroll animations can feel mechanical. There is no CSS-only equivalent.

There is, however, a four kilobyte one, and it is probably already in your project. I come back to that below, because it is the most interesting thing I found while writing this.

What CSS is genuinely great at

I want to be fair before I list limits, because the limits are not a reason to ignore this. Some of it is better than what we were doing.

Reveals on enter, the most common item in any brief:

.reveal {
  animation: fade-up linear both;
  animation-timeline: view();
  animation-range: entry 0% entry 100%;
}

@keyframes fade-up {
  from { opacity: 0; transform: translateY(2rem); }
  to   { opacity: 1; transform: translateY(0); }
}

That replaces an IntersectionObserver, a class toggle, and the teardown for both. I have written the JavaScript version of this hundreds of times and I do not miss it.

Progress bars are one declaration. Parallax is a keyframe with animation-range: cover. And named timelines are the part people overlook, because they unlock layouts where the scroll container is not the animated element:

.gallery {
  overflow-x: auto;
  scroll-timeline: --gallery inline;
}

.indicator {
  animation: grow linear;
  animation-timeline: --gallery;
}

Three things push me toward CSS that have nothing to do with capability. It runs on the compositor thread, which a ScrollTrigger onUpdate does not, and on a mid-range Android that gap is visible. It has no lifecycle to get wrong, which removes an entire class of bug on client-side routed sites. And it costs nothing.

Hold onto that first one. If you run WebGL it reverses completely, and that is the last section of this article.

So I use it. Just not for everything.

The refresh problem, which CSS simply does not have

This is the advantage I underrated, and if your pages have accordions, filters, lazy content or late-loading images, it is probably the one that matters most to you.

ScrollTrigger measures start and end positions when it is created and caches them. Change the page height afterwards and those numbers are stale.

GSAP's own docs are direct about it: ScrollTrigger refreshes automatically when the viewport resizes, but a value you hardcoded at creation will not update unless you made it function-based. And if you load images without width and height attributes, or fetch content that affects layout, you normally have to call ScrollTrigger.refresh() yourself in the callback.

So real code ends up looking like this:

ScrollTrigger.create({
  trigger: '.section',
  start: () => 'top top',
  end: () => '+=' + panel.offsetHeight,
  invalidateOnRefresh: true,
  scrub: true
})

accordion.addEventListener('toggle', () => ScrollTrigger.refresh())

new ResizeObserver(() => ScrollTrigger.refresh())
  .observe(document.querySelector('.dynamic-grid'))

Function-based start and end so they recompute. invalidateOnRefresh so recorded tween values are discarded. A refresh call on every DOM mutation you can anticipate. A ResizeObserver for the ones you cannot.

And refresh brings its own problems. It re-measures every trigger on the page, so it is not cheap when you have forty of them. Refresh order matters, which is why refreshPriority exists. Internally it jumps scroll position to zero so every element sits at its natural position, which is why scroll-behavior: smooth on your html element quietly breaks it. And progress is not preserved across a refresh unless you save and restore it yourself with refreshInit and refresh listeners.

None of this is a knock on ScrollTrigger. It is the unavoidable cost of caching measurements in userland.

The CSS version of that code is the CSS version of any other scroll animation:

.reveal {
  animation: fade-up linear both;
  animation-timeline: view();
  animation-range: entry 0% entry 100%;
}

Open an accordion, load a grid, swap a font, filter a list. Nothing to call. A scroll timeline is not a stored number, it is derived from layout and evaluated as part of it. When the scroll range changes, the range changes. There is no cache to invalidate because there was never a cache.

Two honest caveats.

The underlying physics do not disappear. If the scroll range changes while an animation is mid-progress, the animation's position remaps immediately to the new range, so you can still get a visual jump when something expands above the fold. The difference is that CSS self-corrects and lands correct, whereas a stale ScrollTrigger stays wrong until you refresh it. Wrong-then-right beats silently wrong.

And if you run Lenis, it has to know the new dimensions too. It observes wrapper and content size by default and exposes lenis.resize(), so this is mostly handled, but it is one more thing that can fall out of sync.

For a marketing site with static sections, this whole section is irrelevant. For anything with expandable content, filtering, or user-generated length, it is the strongest single argument for moving your simple animations to CSS.

Where it stops

This is the real body of the article. Every item here is something we ship regularly.

Smoothed scrub

Covered above. No CSS counterpart.

Real pinning

position: sticky is not pinning. ScrollTrigger's pin: true takes the element out of flow, holds it, injects spacer height so the page below does not jump, and restores it at the end.

ScrollTrigger.create({
  trigger: '.panels',
  pin: true,
  scrub: true,
  end: () => '+=' + document.querySelector('.panels').offsetWidth
})

Horizontal scroll sections, pinned storytelling, anything where pin duration is computed from measured content. Simple cases approximate with sticky and a tall parent. pinSpacing, nested pins and measured durations do not.

Orchestration

A CSS keyframe animation drives one element. A GSAP timeline sequences many, with labels, relative offsets, nesting and stagger.

const tl = gsap.timeline({ scrollTrigger: { trigger: '.hero', scrub: true } })

tl.to('.title', { y: -100 })
  .to('.subtitle', { opacity: 0 }, '-=0.3')
  .from('.cards', { y: 60, stagger: 0.08 }, 'cards')
  .to('.bg', { scale: 1.2 }, 'cards')

You can hand-roll this by giving every element the same named timeline and different animation-range values. It works. It is also a spreadsheet of magic numbers, and when a designer asks to shift one beat by 200ms you are recalculating all of them. For a solo experiment that is fine. For a team where someone else maintains it next year, it is not.

Progress in JavaScript

A shader uniform is not a CSS property. If scroll progress has to drive a canvas, a video scrub or an analytics event, you need the number in JavaScript.

ScrollTrigger.create({
  trigger: '.section',
  onUpdate: self => uniforms.uProgress.value = self.progress
})

There is a ScrollTimeline JavaScript API you can pass to element.animate(), but MDN lists it as limited availability, and it hands you an animation timeline rather than an arbitrary per-frame callback.

If you run WebGL this is the biggest item on your list by some distance, and it has a wrinkle that surprised me. It gets its own section at the end.

Responsive scene logic

ScrollTrigger.matchMedia() lets you build structurally different scenes per breakpoint with correct teardown. CSS media queries get you different values, not different structures.

The plugin surface

SplitText for per-character reveals, MorphSVG, DrawSVG, MotionPath with real control. No CSS equivalent, and these are precisely what an art director asks for by name.

Worth noting: GSAP has been 100% free since April 2025, every former Club plugin included, commercial use included, after Webflow acquired GreenSock. Cost is no longer an argument for leaving. Only bundle size and main-thread work are, and those are real but they are a tradeoff rather than a verdict.

If you use Lenis, half of this changes

I almost published without this section, and it would have been wrong.

Lenis is on most of the sites we build, and it changes the scrub answer completely. To see why, you have to know how it works, because a lot of people assume it is doing what Locomotive v4 used to do.

Old smooth scroll libraries faked it. They fixed a wrapper and translated it every frame. Under that approach, native scroll position never actually changes, so animation-timeline: scroll() sees nothing and your CSS scroll animations simply never run.

Lenis is not that. It runs on top of the native scroll engine, as a small animation layer built on scrollTo, with no transforms painted per frame, in under 4 KB. It intercepts the input, interpolates toward the target, and then sets the real scroll position each frame.

That single design decision is the whole story. The document's actual scroll offset updates, just smoothly. And animation-timeline reads the actual scroll offset.

So with Lenis on the page, your CSS scroll-driven animations inherit the smoothing for free. No configuration, no wiring, no lenis.on('scroll', ...). The lag I said CSS could not do arrives through the scroll position itself.

That is a genuinely good deal. Compare the integration cost:

// GSAP with Lenis: you wire it up
lenis.on('scroll', ScrollTrigger.update)
gsap.ticker.add((time) => lenis.raf(time * 1000))
gsap.ticker.lagSmoothing(0)

/* CSS with Lenis: nothing */
.reveal {
  animation: fade-up linear both;
  animation-timeline: view();
}

The CSS version has no integration code because there is nothing to sync. Both are reading the same number from the same place.

Four caveats before you get excited, because I did and then thought about it.

The smoothing is global, not per animation. Lenis has one lerp value for the entire page. ScrollTrigger's scrub is per instance, so you can have a hero lag by a full second and a progress bar track instantly. With Lenis everything shares one feel. For most sites that is fine, and arguably more coherent. For a hero where one layer should drag and another should stick to the cursor, it is not enough.

Do not double-smooth. Lenis plus scrub: 1 is a lerp on top of a lerp. It feels mushy and disconnected, and it is the most common mistake I see in this combination. If Lenis is running, use scrub: true and let Lenis own the feel.

You lose the compositor argument. This is the honest cost. One of the best things about CSS scroll-driven animations is that they run off the main thread. Lenis drives scroll from a main-thread rAF loop, so the position updates are now gated by main-thread frames. The animation still avoids the class of jank that comes from JavaScript touching style on every scroll event, but "this runs on the compositor and your JS cannot block it" is no longer true. If off-main-thread smoothness was your reason for moving to CSS, adding Lenis takes back part of what you bought.

Reduced motion removes the effect. Lenis honors prefers-reduced-motion by default and forces lerp to 1, so scroll tracks the input device one to one. That is correct behaviour, and it means users with that preference get the raw unsmoothed version of your animation. Do not build a scroll effect that only reads correctly with the lag.

The upshot: if Lenis is already in your stack, the case for CSS on simple scroll work gets meaningfully stronger, because you were paying for the smoothing anyway and CSS gets it for nothing. If it is not, adding a library to make your zero-byte solution feel right is a trade you should make deliberately rather than by habit.

Where support actually stands

Chrome and Edge shipped it unflagged in 115, July 2023. Three years of runway.

Safari landed it in Safari 26 in September 2025, added threaded scroll-driven animations in 26.4, and fixed progress-accuracy bugs in 26.5 in June 2026.

Firefox is still behind the layout.css.scroll-driven-animations.enabled flag in stable as of Firefox 152, June 2026. On by default in Nightly, and a named Interop 2026 priority, so it is coming.

Around 82% globally, which means not Baseline, blocked by Firefox.

I ship it anyway because the failure mode is benign. An unsupported browser ignores animation-timeline and the element sits at its natural state. Write it so that natural state is the visible one:

.reveal {
  opacity: 1;
  transform: none;
}

@supports (animation-timeline: view()) {
  .reveal {
    animation: fade-up linear both;
    animation-timeline: view();
    animation-range: entry 0% entry 100%;
  }
}

Visible by default, animated as enhancement. Compare that to a library failing to initialise, which usually means content stuck at opacity: 0 and a client on the phone.

Run the audit yourself

Here is the version of this you can actually apply, and it is not a list of my conclusions.

Open a real project. List every scroll animation in it. For each one, mark it green if CSS has a direct equivalent, yellow if you could get close with named timelines and some magic numbers, red if there is no equivalent at all. Reveals, parallax and progress bars will be green. Anything driving a WebGL uniform will be red.

Then look only at the red column. That column is the decision. If it is empty, you have a genuine migration and a smaller bundle. If it has three items, the library stays and the honest question becomes a different one: is CSS worth adopting alongside something I am keeping anyway?

For me the answer is yes, and for reasons the bundle-size framing misses entirely.

Reveals, parallax, progress bars: CSS. Wrapped in @supports, visible by default. Most animation work by volume, and it deletes a category of init and teardown bug.
Sections with dynamic height: CSS whenever possible. No refresh calls, no observers, nothing to invalidate.
Pinned sequences, horizontal scroll, orchestrated heroes: GSAP. No hesitation.
Anything driving WebGL or canvas: GSAP, and everything coupled to it too. The uniform needs the number in JS, and any DOM element that must stay locked to the scene has to come off the same clock.
Never both on one element. One owner per animation or you will lose an afternoon to a fight you cannot see in DevTools.
CSS first when prototyping. No install, no init, no cleanup, edit in DevTools and see it immediately. I now rough out scroll ideas in a stylesheet before deciding whether the finished version needs a timeline. Half the time it does not, and the other half I already know exactly what I am asking GSAP to do.

That is not a migration. It is a second tool, and it is a better one for a large share of the work.

If you run WebGL, one entry in that red column is different

I left this until now because it does not apply to everyone. If it applies to you, it is probably the most important section here.

Pure WebGL is easy to reason about. It is all JavaScript, so you write JavaScript. The trouble starts when a DOM element has to move with the WebGL. A heading locked to a distorted image plane. A caption sitting on a mesh as it scrolls. Text revealing in step with a shader wipe. This comes up constantly, partly because you usually want the text to stay real DOM for accessibility and SEO rather than baking it into the canvas.

Now two things have to agree, and here is the twist: the compositor advantage becomes the problem.

That was the first item on my list of reasons to like CSS. Scroll-driven animations are updated by the compositor, deliberately independent of your main thread. Your WebGL renders in a main-thread rAF. Those are two different clocks. On a given frame the CSS-animated heading can reflect one scroll position while the rendered WebGL frame reflects a slightly older one. The offset is a fraction of a frame. It is invisible in a screenshot and glaring in motion. The text swims against the image.

It reads as cheap, which on this kind of project is the single thing you were paid to avoid.

Off the main thread means on a different clock. Everywhere else that is the feature. Here it is the bug.

This is not hypothetical, it is the reason Lenis exists at all. It began as an internal tool for syncing WebGL and the DOM, and its own pitch is that jumps and delays in scroll-linked animations come from browsers running effects asynchronously from native scroll.

So the rule is about coupling, not co-presence:

A DOM element that must stay locked to WebGL: drive both from the same JS loop. Same rAF, same progress value, one source of truth. No CSS scroll-driven animation on that element, ever.
A DOM element that merely shares a page with WebGL: CSS is fine. A nav shrinking, an unrelated section fading in, a progress bar. Nobody perceives sub-frame desync between two things that are not visually related.

Get that line wrong and you produce the worst class of bug in this kind of work. Nothing breaks. Nothing errors. It just feels slightly wrong, and nobody on the call can articulate why.

Which is a decent argument for the whole thesis, actually. The snippet at the top of this article would have worked perfectly in that project, on that page, next to a WebGL scene it was quietly fighting with.

The part that generalises

None of the above is really about animation.

The pattern repeats for every stack decision I have made in fifteen years. Someone posts the snippet, the snippet is real, and the snippet is the easiest 80% of a problem whose difficulty lives entirely in the other 20%. Vue to Nuxt, REST to GraphQL, SCSS to Tailwind, npm to pnpm. The demo is always the happy path, because a demo of the hard path would not be a demo.

Stack decisions are not made on the best case. They are made on the worst thing you currently do that the new thing cannot do, and on whether keeping both is cheaper than keeping either.

Zero bytes is a great headline. It is not a feature inventory. I would rather ship 35 KB and the animation the client approved.

Sources: MDN on CSS scroll-driven animations and ScrollTimeline, the Lenis repo, and Webflow's GSAP announcement. Support figures accurate at time of writing. Check caniuse before shipping, this one is moving.

The Problem Isn’t AI. It’s the Pace.

Andrés Clúa — Wed, 29 Jul 2026 22:02:54 +0000

Swipe and there is food at the door. Swipe and there is a date on Thursday. Swipe and there is a stranger's car outside taking you home.

Ask for a function and there is code. Ask for a design and there is a mockup. Ask for a summary of a forty page document and it is done before you have finished reading the first page yourself.

None of this felt like a decision. It arrived, and we adapted to the interface without ever adapting to the change.

That is the part I keep thinking about. Not whether the technology is good. Whether the gap between how fast it moves and how fast we absorb it is still a survivable gap.

The race is worth running

I want to be clear about where I stand, because the easy version of this article is a complaint, and I do not want to write that one.

The problem is not the speed. It is that the speed now exceeds my ability to form an opinion about what is moving.

Where I notice it in my own work

The clearest version for me is tooling.

Evaluation has become the bottleneck. Not learning. Deciding what is worth learning.

The honest version of "our brains cannot keep up"

The line I first wanted to write was that our brains do not finish processing the change. It feels true. It is how the tiredness actually feels from the inside.

What lags is not biology. It is everything built on top of biology.

Those lags are measurable. You do not need a claim about neurons. The technology iterates in months and the scaffolding around it iterates in decades, and every year that ratio gets worse.

Every generation said this

I have to include this part or the article is dishonest.

"This time is different" is the most overused sentence in technology. I do not get to skip that objection just because I feel tired.

So here is the only version of the difference I can actually argue for, and I hold it loosely.

The proposal on the table now is to remove the pause.

Which brings me to the letter

That is the same feeling I have on a much smaller scale about build tools. It goes all the way up. Nobody is standing somewhere calm.

So what do we actually do

I do not have a policy answer. I build websites and internal tools. The governance question is above my pay grade and I am suspicious of developers who pretend otherwise.

But I have a working answer for myself, and it is not "keep up."

I do not think we should stop out of fear. I do think there is something absurd about waiting until we have lost control before starting the conversation about how we would want to exercise it.

Sources: the statement and signatory list at pacingthefrontier.com, with reporting from The Next Web. Signatory counts were accurate at the time of writing.

HTTP Just Got Its First New Method in 20 Years. Here's Why You Should Care.

Andrés Clúa — Fri, 03 Jul 2026 12:00:27 +0000

If you have ever written this, this article is for you:

// a "search" that is actually a POST
axios.post('/api/search', { category: 'shoes', maxPrice: 100 })

Or the vanilla version:

fetch('/api/search', {
  method: 'POST',
  body: JSON.stringify({ category: 'shoes', maxPrice: 100 })
})

We all did it. The query was too big for a URL, so we used POST. It worked. But it was always a lie. We were telling HTTP "this modifies something" when it didn't.

In June 2026 the IETF published RFC 10008. It defines a new HTTP method called QUERY. It is the first new method in more than two decades. And it fixes exactly this.

The problem in 30 seconds

GET is perfect for reading data. It is safe, idempotent and cacheable. But it cannot carry a body, and URLs have length limits. Around 8000 characters if you are lucky. Less if a proxy in the middle disagrees.

POST carries any body you want. But HTTP assumes it changes state. So no automatic caching. No safe retries. If a POST times out, the client cannot just retry it. Maybe it already did something.

For years we had to pick one. Clean semantics or a real payload. Never both.

What QUERY does

QUERY is a GET with a body. That's it.

QUERY /products HTTP/1.1
Content-Type: application/json

{
  "category": "shoes",
  "maxPrice": 100,
  "sort": "price_asc"
}

I use axios for most of my projects, so this is how it looks there:

const { data } = await axios({
  method: 'QUERY',
  url: '/api/products',
  data: {
    category: 'shoes',
    maxPrice: 100,
    sort: 'price_asc'
  }
})

There is no axios.query() helper yet, but axios passes any custom method straight through to the underlying HTTP client, in the browser and in Node. No plugin needed.

If you prefer plain fetch, same idea:

const res = await fetch('/api/products', {
  method: 'QUERY',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    category: 'shoes',
    maxPrice: 100,
    sort: 'price_asc'
  })
})
const data = await res.json()

The server runs the query and returns the result. Nothing changes on the server. The spec guarantees two things:

Safe. It does not modify state.
Idempotent. Sending it twice gives the same result as sending it once.

Those two guarantees are what everything below is built on.

This pattern is going to change

Look at almost any API in production today:

POST /search        <- reads data, says it writes
POST /reports/run   <- reads data, says it writes
POST /products      <- actually writes

Two of those three endpoints are lying. Here is where APIs are heading:

QUERY /search       <- reads
QUERY /reports      <- reads
POST  /products     <- writes

Not overnight. But the direction is clear. So the two questions that matter are: what works today, and how will our apps actually change.

Compatibility: where we are right now

The RFC is weeks old, so let's be honest about the current state.

The protocol side is already fine. HTTP does not have a fixed list of methods. QUERY is just a token in the request line. Any HTTP/1.1 or HTTP/2 connection can carry it today.

Servers. Nginx and Apache will pass QUERY requests through, but your config may need small tweaks. Anything that whitelists methods (limit_except, security rules, WAFs) needs QUERY added explicitly. This is where most early friction will live.

Frameworks. This is the real bottleneck. Your router needs to understand the method. Spring has a pull request in progress. Rails is discussing it. Express lets you handle custom methods with a bit of manual work. Expect native support to roll out across 2026 and 2027.

HTTP clients. Axios and fetch can already send arbitrary methods, so both of these work today:

// axios
axios.request({
  method: 'QUERY',
  url: '/api/products',
  data: { category: 'shoes', maxPrice: 100 }
})

// vanilla fetch
fetch('/api/products', {
  method: 'QUERY',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ category: 'shoes', maxPrice: 100 })
})

One detail worth knowing: axios ignores the body only on GET requests in browsers, because fetch and XHR do not allow it. For any other method, including QUERY, data becomes the request body without touching transformRequest.

The catch in browsers is CORS. QUERY is not a safelisted method like GET or POST, so cross-origin requests trigger a preflight. This applies to axios and fetch equally, since underneath it is the same mechanism. Your server has to answer the OPTIONS request with:

Access-Control-Allow-Methods: GET, POST, QUERY, OPTIONS

Same-origin requests need nothing. And in Node there is no CORS at all, so server-to-server QUERY calls work right now.

CDNs and proxies. Here is the interesting signal: the RFC was co-authored by engineers from Cloudflare and Akamai. CDN support may land before your framework ships it. That is not a coincidence. Caching is where QUERY pays off the most.

Discovery. The RFC also defines a response header, Accept-Query. A server uses it to announce that an endpoint supports QUERY and which formats it accepts. So clients and tools can detect support instead of guessing.

How our apps will change

This is the part I find more interesting than the spec itself. The migration is not just renaming a method. Some habits and workarounds simply stop making sense.

1. The fake POST endpoints disappear

Every /search, /filter, /reports endpoint that uses POST today is a QUERY endpoint waiting to happen. The body stays identical. Only the method changes:

// before
axios.post('/api/search', filters)

// after
axios.request({ method: 'QUERY', url: '/api/search', data: filters })

This will be the first and easiest migration in most codebases.

2. Retry logic gets simpler

Today, if a POST search times out, most clients do not retry. They can't. Maybe the server already processed it. So we write error screens and "try again" buttons.

With QUERY, clients and SDKs can retry automatically. The request is idempotent by contract. A whole category of defensive code in mobile apps and flaky-network handling gets thinner.

3. Caching layers move down the stack

Right now, caching a POST search means building it yourself. Redis, cache keys hashed from the body, invalidation logic. Application code.

With QUERY, the CDN can do it. Same body, same cached response, standard HTTP semantics. A lot of hand-rolled cache layers will quietly get deleted.

4. GraphQL gets a proper home

Every GraphQL query today travels over POST, even though almost all of them are pure reads. That is the most visible version of this problem. QUERY gives GraphQL correct semantics without touching the query language. Expect GraphQL clients and servers to adopt it early.

5. URLs get readable again

We have all seen this:

GET /products?filters=%7B%22category%22%3A%22shoes%22%7D&sort=price

JSON, URL-encoded, jammed into a query param because the framework offered nothing better. Those endpoints migrate to QUERY and the URL goes back to being just /products. Cleaner logs too. Query bodies do not end up in access logs and bookmarks the way URLs do.

6. Reading an API becomes self-documenting

When the method itself tells you if an endpoint reads or writes, documentation gets lighter and integration mistakes go down. New devs on your team stop asking "does this POST actually change anything?"

What I would do now

Nothing dramatic. But you can prepare:

Audit your API. List every POST endpoint that only reads. Those are your future QUERY endpoints.
Check your infra. WAFs, proxies and method whitelists that would block an unknown method.
Watch your framework's releases through 2026 and 2027.
If you control both client and server, nothing stops you from experimenting now with a small middleware.

Twenty years for a new HTTP method. The migration will take a while. The direction is already clear.

Rust Ate the JavaScript Toolchain. Then Cloudflare Bought It

Andrés Clúa — Fri, 26 Jun 2026 15:37:11 +0000

I run Vite on almost everything. Astro sites, Nuxt projects, a small group of libraries I maintain on the side. The build tool is the part of the stack I think about least, because it just works.

So when the thing under all of that changes twice in three months, I read the release notes properly.

Here is what actually changed, what breaks, and the part that made developers argue for a week straight.

For Five Years, Vite Ran on Two Bundlers

When Vite launched, it made a pragmatic bet. esbuild for the dev server, because it is fast. Rollup for production, because its output is well optimized. Two tools, two jobs.

It worked. But it had a cost. Two bundlers meant two configs, two sets of quirks, and output that could drift between dev and prod. You tuned one, and the other behaved slightly differently.

Vite 8 ends the split. It shipped on March 12 with a single bundler called Rolldown, written in Rust, with the Rollup plugin API on top. Under Rolldown sits Oxc, a Rust parser and transformer that does the TypeScript and JSX work Babel used to do.

One language. One pipeline. Dev and prod finally agree.

This Is a Pattern, Not a One-Off

esbuild (Go) made webpack look slow. Bun did the same to Node for some workloads. Biome replaced Prettier and ESLint and runs many times faster. Now Rolldown does it to Rollup and esbuild at the same time.

Every time a core JavaScript tool gets rewritten in a compiled language, the same thing happens. The speed jump is large enough to make the old version look broken.

The interesting part is not the speed. It is the compatibility.

These Rust tools do not ask you to relearn your stack. Rolldown speaks the Rollup plugin API. Biome follows ESLint and Prettier conventions. The migration is designed to be boring, and boring is the point.

The Numbers, With a Grain of Salt

The headline figure is real. Linear cut its production build from 46 seconds to 6. Vite reports builds 10 to 30 times faster than the old Rollup path. Other large projects report 3x to 8x.

I treat these like any benchmark. Your build is not Linear's build.

A small marketing site will not see a 40 second drop, because it never had a 40 second build in the first place. The gains land hardest where you were already hurting: big dependency graphs, slow CI, painful full reloads. If your build finishes in four seconds today, this is a nice-to-have, not a rescue.

Still, the scale matters. Vite sits around 130 million weekly downloads. Changing its bundler changes a large slice of the web's tooling in a single release.

What Actually Breaks

This is the part the launch posts skip. Most projects upgrade with a version bump. Some do not. Here is what I would check before touching production.

Plugins that call transformWithEsbuild will fail. esbuild is no longer bundled. You move to transformWithOxc, or you install esbuild yourself as a peer dependency.

A few more sharp edges:

build.rollupOptions is renamed to build.rolldownOptions
CJS interop behaves differently in some setups
Yarn PnP projects have reported friction

The safe path is two steps, not one. First, swap vite for the rolldown-vite package while you are still on Vite 7:

# step 1: stay on Vite 7, swap the bundler underneath
npm install rolldown-vite@latest

# run your build, check plugins, diff the output
npm run build

Then, once that is green, take the major:

# step 2: upgrade to Vite 8
npm install vite@8

This separates the bundler change from the major version change. If something breaks, you know which one did it.

Real wins, real edges. Not magic.

Then Cloudflare Bought the Whole Thing

Now the part that lit up Hacker News.

On June 4, Cloudflare acquired VoidZero, the company Evan You founded to build this toolchain. Vite, Vitest, Rolldown, and Oxc all come with it. The whole team joins Cloudflare. Evan You stays in charge of the open-source roadmap.

The pledges are what you would expect. The projects stay MIT-licensed and vendor-neutral. No Cloudflare-only features land in core Vite. Cloudflare put one million dollars into an independent Vite ecosystem fund for maintainers outside both companies.

I also read the why. Evan You was honest that VoidZero had a money problem: huge adoption, no clear revenue. The team had tried a mixed license model, and was already building a Vite-native deploy platform on top of Cloudflare before the talks (SiliconANGLE has the details). The acquisition solves the funding question in one move.

The Part Worth Arguing About

Here is what makes me pause, and it is not the build tool.

This is the second time in six months Cloudflare has bought its way into foundational web tooling. It acquired the Astro team earlier this year, with the same promises: open source, MIT, portable, governed in the open.

So one company now sits very close to Vite, Vitest, Rolldown, Oxc, and Astro. The license is open. The governance is open. The pledges read well. But influence is not the same as control, and the influence here is real.

I am not waving a flag about it. Cloudflare has kept its hands off so far, and putting money behind maintainers is genuinely good news. But "trust us, it stays neutral" is a promise, not a guarantee. The healthy move is to keep watching, not to panic.

Open source has always run on trust. This just concentrates more of it in one place.

Should You Upgrade?

For most projects: yes, and soon.

The migration is usually a version bump, with a compatibility shim covering most plugins
The speed gain is free once you are on it
Staying on the old pipeline is slowly turning into a CI tax

But move like an adult about it:

Test rolldown-vite in a branch first, then take Vite 8
Check any plugin that touches transformWithEsbuild or rollupOptions
If you run Yarn PnP, budget extra time

The Rust toolchain is here, it is faster, and the upgrade is less painful than most majors. The ownership question is a separate one. Adopt the tool on its merits, and keep an eye on who steers it.

So my take is simple. Try it. Give it a chance in a throwaway branch this week, before you have an opinion about it.

Faster builds are the easy win. But a single Rust pipeline that owns the whole thing opens a better question, and it is the one I actually care about.

If one tool now controls parsing, transforming, and bundling end to end, shouldn't our bundles be getting smaller too? That is the part I want to see next. Tell me in the comments if you are seeing it already.

Leading a Dev Team Is Not a Coding Job (In Some Cases). It Just Looks Like One.

Andrés Clúa — Tue, 09 Jun 2026 13:51:26 +0000

Everyone tells you the same thing when you move into leading a dev team. "Now you stop writing code." Cool. I get it.

I lead a dev team at a digital agency. Frontend, backend, client work, mixed stacks, real deadlines. So when I made that move, I had a pretty clear picture of what the job would be. I was mostly wrong about it.

What I thought the job was

I thought leading meant being the person who makes the hard technical calls.

The architecture decisions. The "should we use WordPress or go headless on this one" conversations. The hairy bug nobody else can crack. The code review where I catch the thing that would have blown up in production.

That was the real work in my head. Everything else felt like overhead.

That part of the job does exist. But it's maybe twenty percent of it. The other eighty is something nobody really prepares you for.

The first time someone got stuck

Early on, someone on the team hit a wall on a ticket. I looked at it and saw the fix in about thirty seconds. My hand was already moving to the keyboard.

Then it hit me. The right move depends on how clear it actually is to me.

If I have it crystal clear, fine, I fix it and move on. No ceremony. But if I have any doubt, that's the signal to not solve it alone. That's when we work it through together with the person who owns it, and sometimes it's worth pulling in someone else too. The doubt is not a weakness to hide. It's the most useful thing in the room, because it's exactly where the team learns something instead of just receiving an answer.

If I fix everything the second I see it, the bug is gone today and the person is no better next week. So now I check myself before grabbing the keyboard. Is this a thirty-second fix I can hand back with an explanation, or is this a "let's look at it together" moment. That single question reset how I think about the whole role.

The moment delegation starts working

Here's the part that genuinely surprised me with how good it feels.

When you start transmitting clear ideas, and the other side responds the way you would have done it yourself (or at least follows your work patterns at 80%), something clicks. You hand off a piece of a project, you brace for it to come back wrong, and instead it comes back right. Maybe better than right.

So you hand off a bigger piece. Then a whole feature. Then a whole project.

That's the addictive part of the job nobody warns you about. Not control. The opposite of control. Watching a thing you used to hold get done well without you in the loop. The first time it happens you almost don't trust it. After a while it's the most satisfying part of the week.

You start seeing who they really are

The more this happens, the more you start noticing the shape of each person.

One gets sharp on performance. Another is the one who actually enjoys untangling a messy data model. Someone turns out to be great at the client conversation you used to dread. These specializations don't show up in a job description. They show up over months, in small moments, and a big part of leading is just paying attention long enough to see them.

And then the job is to expose them. A retro is one of the best places for this. When someone solved something clever, I don't summarize it for them. I put them in front of the team and let them walk through it. People need to be seen for what they're good at, by the people they work with, not just by me in a 1:1. That visibility is fuel, and it's free.

Throwing people into the deep end

The harder version of this is putting people into situations you've already lived through.

I've been in plenty of those. Some I walked into well prepared. Plenty I learned the hard way, getting hit until I figured it out. Part of leading is deciding when to recreate that on purpose for someone else.

Sometimes it's planned. You give someone a project that's slightly above their current level because you've seen enough to know they'll rise to it. Sometimes it's a bit "a los golpes", you let them take a hit you could have softened, because the lesson only lands when it costs something.

The skill is calibration. Too easy and they don't grow. Too hard and you break their confidence instead of building it. You're constantly guessing where that line is for each individual person, and you don't always guess right.

The variable nobody puts in the spreadsheet

And here's the thing that makes all of this messy: people aren't constant.

When I decide who goes on which project, the technical fit is only half the equation. The other half is where the person is at. Someone coming off a brutal sprint shouldn't get dropped into the next firefight. Someone who just nailed something hard might be exactly ready for a stretch. Someone going through a rough patch outside work needs a different kind of ticket this month.

And personal situations cut both ways. Sometimes life outside work is a distraction that pulls someone off their game. Sometimes the work is the calm, the steady thing someone holds onto while everything else is moving. Reading which one it is, for which person, in which week, is part of the job too.

You can't put that in a staffing spreadsheet, but it's real, and ignoring it is how good people burn out on your watch. Skill, timing, morale, what else they're carrying, who they work well with. A lot of things matter, and most of them have nothing to do with code.

Here's the payoff for getting this right over time. Even when I have to be out for four days, the team holds. They respond at maybe 80% to how I've taught them, and the gap between that and 100% is mostly the screwups I made and learned from the hard way, the ones I can now spare them from repeating. That's the whole point of teaching instead of just fixing.

And to be fully honest, I've had a margin of comfort that not every lead gets. Part of my team has been solid for more than six years. There's a real bond there, in every sense, and I don't take it for granted. I hope it stays that way. A lot of what works isn't a system I designed. It's trust that took years to build.

It's not a promotion, it's a different job

This is the thing I'd tell anyone moving into it. Leading a dev team is not "senior engineer plus meetings." It's a career change that happens to keep the same job title.

The skills barely overlap. Being great at the code can even get in your way, because it makes the keyboard so tempting. The new job is teaching, reading people, knowing when to delegate, knowing when to expose someone and when to protect them, and keeping a group of humans pointed in the same direction. The code is the most visible part. It's not the part that needs you most.

The first time someone on the team builds something better than what I would have written, a small part of me wants to find a flaw in it. That reaction is the trap. If everything good has to come from me, the team has a ceiling, and the ceiling is me. The whole job is raising that ceiling above my own head. You're trying to make yourself the least impressive engineer on the team over time. That's success, not failure.

I used to think this was the boring half of the work. Now it's the part I find genuinely interesting, because it never gets "done." There's always another person to read, another call to calibrate, another thing to hand off and watch come back better than you left it.

If you're about to make this jump, go in knowing you're starting a new job, not getting a reward for the old one. The sooner you stop reaching for the keyboard, the sooner you're actually doing it.

Visual regression testing: the missing piece in your testing stack

Andrés Clúa — Wed, 06 May 2026 15:54:34 +0000

In agencies, testing exists but it's mostly manual. Someone opens the site before deploy, clicks around, checks the forms, makes sure nothing looks broken. Sometimes there are unit tests with Vitest or Jest. Sometimes there aren't, depending on the project and the deadline. When the deadline is in three days, automated testing is the first thing to go.

And inside that manual process, there's one type of testing that's almost impossible to do well by hand: visual.

I've been researching visual regression testing for a while. I built it in research projects, tried it on side experiments, read a lot. What strikes me most isn't the tool itself. It's how rarely it's used in agency work, compared to the problem it solves and how easy it's become to set it up.

I'm not here to tell you my team has it running in production and we're rockstars. I'm here to share what I learned researching it, hoping to save you the first few hours.

Why visual testing is the hardest

Think about the types of testing you know.

Unit tests with Vitest. They check that a function returns what it should. Fast, deterministic, easy to write.

Integration tests. Slower, more fragile, still manageable.

End-to-end. Slow, fragile, environment-heavy. Less common.

Visual. Checks that the site looks the way it should. And here everything breaks. What does "looks good" even mean? How do you express that as an assertion? expect(button).toBeVisible() tells you nothing about padding, color, border-radius, or how a component looks next to three others.

Visual testing breaks the mental model of "logical assertion over code". What you want to assert is perceptual, not logical. That's why most stacks skip it.

What VRT actually does

It solves the problem indirectly. Instead of describing how something "looks good", it compares screenshots. You take a baseline, take another after a change, compare pixel by pixel. If the diff goes over a threshold, the test fails.

Not elegant in theory. Pragmatic and it works.

This catches the bugs every agency knows. You change a Tailwind variable, touch a design system component, update a UI dependency. Unit tests pass. Lighthouse passes. Site goes live. Days later a client reports the secondary button has a thicker border, or the footer lost its padding.

Why it's barely used

Four reasons, none technical.

First, agency testing is mostly manual. The human eye is bad at catching subtle visual changes. Nobody notices a padding going from 16 to 14 pixels during a quick walkthrough on a Friday afternoon. And since the manual process is already in place and "works", nobody questions what it systematically misses.

Second, the first attempt always fails. Someone sets it up on a Friday, by Monday the pipeline is red with 20 false positives, the team disables it, it dies in the repo.

Third, the team learning curve. Not because it's complex, but because every dev needs to understand baselines, when to update them, how to review diffs in a PR. If only one person gets it, it doesn't scale.

Fourth, and this one bothers me the most. Most content on the topic is written by SaaS vendors (Percy, Chromatic, Applitools) selling their product. They tell you it's complex, you need their tool, self-hosted doesn't scale. It's not true. Playwright ships everything you need.

The stack that makes sense

Playwright for running tests and comparing screenshots
GitHub Actions for CI
Screenshots versioned in your repo
A masking convention for dynamic content

No external services. No licenses. All inside your repo.

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test'

export default defineConfig({
  testDir: './tests/visual',
  expect: {
    toHaveScreenshot: {
      maxDiffPixelRatio: 0.01,
      threshold: 0.2,
    },
  },
  projects: [
    { name: 'mobile', use: devices['iPhone 13'] },
    { name: 'desktop', use: { viewport: { width: 1440, height: 900 } } },
  ],
})

A base test:

import { test, expect } from '@playwright/test'

const pages = ['/', '/about', '/services', '/contact']

for (const path of pages) {
  test(`visual: ${path}`, async ({ page }) => {
    await page.goto(path)
    await page.waitForLoadState('networkidle')
    await page.evaluate(() => document.fonts.ready)

    const name = path === '/' ? 'home' : path.replace(/\//g, '-')
    await expect(page).toHaveScreenshot(`${name}.png`, {
      fullPage: true,
      mask: [page.locator('[data-vrt-mask]')],
      maskColor: '#808080',
    })
  })
}

Setup is faster than ever

Two years ago, building this stack from scratch was two or three days of focused work. Today, with current codegen tools, it takes a couple of hours if you know what to ask for. The barrier dropped. The knowledge of what to ask for is still critical. If you don't know you need document.fonts.ready before the screenshot, no tool will suggest it without context.

Here's the prompt I use to scaffold it on new projects:

I need visual regression testing in this project.

Stack: [Nuxt 3 / Next.js / WordPress / whatever]
CI: GitHub Actions

Implement:

1. Install Playwright as dev dependency. Configure Chromium only.

2. Create `playwright.config.ts` with two projects: mobile (iPhone 13)
   and desktop (1440x900). Threshold 0.2, maxDiffPixelRatio 0.01.

3. Create `tests/visual/pages.spec.ts` iterating over the main public
   routes. For each route:
   - Wait for networkidle
   - Wait for document.fonts.ready
   - Scroll to bottom to force lazy loading
   - Disable animations via injected CSS
   - Take fullPage screenshot, masking [data-vrt-mask] elements
     with maskColor #808080

4. Create `.github/workflows/visual-regression.yml` that:
   - Runs on every PR
   - Shards by project (mobile, desktop)
   - Caches node_modules and Playwright browsers
   - Uploads playwright-report as artifact on failure
   - Does NOT auto-update baselines

5. Add scripts to package.json:
   - `test:visual` to run tests
   - `test:visual:update` to update baselines locally

6. Document in `tests/visual/README.md`:
   - How to run tests locally
   - When and how to approve new baselines
   - The [data-vrt-mask] convention

Do not install Percy, Chromatic, or external services.
Self-hosted with Playwright only.
```

`

Drop it into your AI tooling at the repo root and the scaffold comes out in one pass. The prompt isn't the point. Understanding why each decision is there is.

## Masking dynamic content: where it all breaks

This is by far the hardest part of the whole setup. Everything else you can build in an afternoon. Masking can take weeks of fine-tuning if your site has any real complexity.

An honest list of the enemies:

- **Dates and timestamps**. "3 hours ago", "Published May 5, 2026". They change every run.
- **Sliders and carousels**. They start in different positions, change height when slide content has different size, often have autoplay you can't easily disable.
- **Animations and transitions**. A 400ms fade-in produces a different screenshot at ms 200 vs ms 600. Multiply by every component using `motion-safe` or GSAP.
- **WYSIWYG content**. The client edits CMS text and breaks your test. But you can't mask the whole block or you're testing nothing.
- **Lazy-loaded images**. Depending on browser request order, the page has different heights mid-render. Full-page screenshots come out different each time.
- **External iframes**. YouTube, Vimeo, maps, Calendly, chat widgets. Different load times, rotating content.
- **Cookie banners, A/B tests, geolocation**. The site the CI bot sees isn't the site you see, and sometimes it's not even the same between two runs.
- **Skeletons and loading states**. Capture early, you see the skeleton. Capture late, you see the data. Both valid, both break the test.
- **Async fonts (FOUT/FOIT)**. Screenshot before fonts load, you get Arial. After, you get Inter. Catastrophic diff.
- **Real-time counters**. Any "1,234 users online" widget guarantees a false positive every run.

False positives are worse than no tests. They train the team to ignore warnings. Two months in, nobody reads the reports and the setup dies.

The rule that worked for me: anything with genuinely dynamic content gets a `data-vrt-mask` attribute. Not tooling magic, team discipline:

```vue
<template>
  <article class="post">
    <h2>{{ post.title }}</h2>
    <time data-vrt-mask>{{ post.publishedAt }}</time>
    <YouTubeEmbed data-vrt-mask :id="post.videoId" />
    <HeroSlider data-vrt-mask />
    <p>{{ post.excerpt }}</p>
  </article>
</template>
```

Playwright paints that region a neutral gray (`#808080`) before comparing. The rest gets compared pixel by pixel.

Use neutral gray, not Playwright's default magenta. When a dev opens a report with 15 diffs and half are screaming magenta blocks, their brain enters alarm mode and approves everything in a hurry. Neutral gray makes real diffs pop and masked regions disappear visually.

For animations, the highest-impact trick is killing them globally during the test:

```typescript
await page.addStyleTag({
  content: `
    *, *::before, *::after {
      animation-duration: 0s !important;
      animation-delay: 0s !important;
      transition-duration: 0s !important;
      transition-delay: 0s !important;
    }
  `,
})
```

This single line eliminates half the false positives.

For lazy images, force-scroll to the bottom before capturing. It's ugly. It works. Put it in a helper and never look at it again.

## Baseline approval

When a diff appears, someone decides if it's a bug or an intentional change. The common mistake is letting each dev approve their own baselines locally with `--update-snapshots` and committing the result. In three months you have approved baselines hiding real bugs. Someone shipped a broken margin, approved it, now it's the official state. Test passes green and lying.

What works:

1. Baselines update via PR. Never direct commit to main.
2. The PR shows visual diffs as artifact.
3. At least one reviewer who isn't the author.

```yaml
- uses: actions/upload-artifact@v4
  if: always()
  with:
    name: playwright-report
    path: playwright-report/
    retention-days: 14
```

## When it's not worth it

If your site barely changes, one client, monthly deploys, the overhead isn't worth it. Baseline maintenance is real work.

If you have a shared design system across multiple clients, deploy several times a week, and every visual bug means an awkward conversation with a client lead, this is the best thing you'll add this year.

VRT doesn't catch logic bugs, accessibility bugs, or performance issues. It doesn't replace unit tests if you have them. It doesn't replace manual QA on critical flows like checkout or login. It's one more layer, the one covering the gap the others leave and the human eye misses worst.

## Closing

Visual regression testing is one of those tools that, when you look at it closely, you wonder why everyone isn't using it. The answer is a mix of inertia, vendor-driven content bias, and the fact that the first attempt always fails.

Visual testing remains the hardest. And it's still mostly done by hand, which in practice means it's not done at all. With today's tooling, the barrier to entry is gone. What's left is the decision.

I don't have the perfect recipe because I don't have it running in production yet. But after researching it deeply, I'm convinced any agency with a shared design system and frequent deploys should have this. And the self-hosted Playwright setup is fully viable, contrary to what the SaaS vendors want to sell you.

I'm starting to roll it into a project soon. If you already use it in production and learned things this article doesn't cover, write them. We need more honest content on this.

Claude Code, the Pricing Gap, and the Rise of Build-Your-Own AI

Andrés Clúa — Fri, 24 Apr 2026 14:03:44 +0000

On April 21, 2026, Anthropic quietly removed Claude Code from its $20 Pro plan. No email, no announcement, no changelog. People noticed because the pricing page changed overnight. A few hours later it got reverted, and Anthropic's Head of Growth posted on X that it was a test on 2% of new signups.

Simon Willison wrote the best account of what happened. He pays for Claude Max himself and is not exactly a hater. His point is simple: the revert doesn't matter. What matters is that Anthropic considered it.

The experiment got pulled. The signal didn't.

It is going to get more expensive

Claude Code is back in Pro today. But if you zoom out a bit, the direction is obvious.

GitHub did the same thing on the same day with Copilot. Earlier in April, Anthropic blocked third-party tools from running on Pro and Max subscriptions. Enterprise plans moved to per-token billing. Weekly caps got tighter. Peak-hour limits got stricter.

Claude Code already makes Anthropic billions of dollars a year. The company just raised $30B. This is not a company in crisis. It is a company figuring out how to charge more for the people who use it the most.

The logic makes sense from their side. From ours, it means one thing: the tool we built our workflow around can change price on us overnight, and there is nothing we can do about it.

The gap nobody talks about

A hundred dollars a month in San Francisco is not a hundred dollars a month in Bilbao, Buenos Aires, Lagos, or Jakarta. It is not the same for a two-person agency billing in euros, or a freelancer on a retainer, or a bootstrapped startup watching runway.

Most of the AI tooling conversation assumes one user: a well-paid dev at a US tech company. For that person, $100/month is noise. For a lot of working developers, it adds up fast. An agency with 15 devs on Max is $18,000 a year, and that is before you count Cursor, Copilot, or anything else.

But the price is not even the main problem. The main problem is depending on something you do not control. When your main tool can 5x its price on a Tuesday as a "test", you have a problem that is bigger than the bill.

You do not have to build anything from zero

When people hear "build your own AI" they imagine training a model, GPU clusters, a whole research team. That is not what this is about.

It is more like cooking at home instead of eating out every day. You do not have to grow the wheat to make bread. You buy the pieces, you put them together, you eat.

The pieces already exist. There are solid open-source models you can run locally or use through an API for a fraction of what Claude costs. There are tools like Ollama that make running one of these models about as hard as installing an app. There are terminal workflows like OpenCode that work similar to Claude Code but against whatever model you want.

The other piece, which is actually the important one, is your stuff. Your codebase, your docs, your conventions. That is the part nobody else has. That is what makes a generic model useful for the work you actually do.

When the big players go open, you should notice

If this still sounds like a fringe thing, look at Cursor.

Cursor is one of the most popular AI coding tools right now. They just launched their flagship model, Composer 2, positioning it as their own in-house thing. Less than 24 hours later, a developer named Fynn found a model ID in their API traffic that gave it away: Composer 2 is built on top of Kimi K2.5, an open-weight model from a Chinese lab called Moonshot AI.

Cursor confirmed it and later published a technical report admitting the Kimi base. VC Tomasz Tunguz made the point well: a $50B company reaches near-parity with state-of-the-art at a fraction of the price, running on an open model they did not build. That is not ideology. That is math.

If a company valued at $50B reached that conclusion, a dev in Bilbao or an agency in Madrid can reach it too. At a smaller scale, same idea.

It is not only about saving money

Cost is the easy argument. The more interesting part is what you gain when you control the model.

You can shape it to your work. A base model that you use on your own code and your own patterns gets better at your specific job, in a way a generalist model cannot, no matter how big it is.

Your code stays with you. Depending on what you work on, that is the difference between "we can use AI" and "legal says no".

No rate limits reset every Tuesday. No weekly caps. No versions deprecated on someone else's schedule. No experiment changing your plan overnight.

None of this makes Claude irrelevant. What it does is make Claude one tool in a stack, instead of the stack.

What to try

The gap between what you can run locally and what you pay a subscription for is smaller than most people think. If you have not looked at this in a year, you are working with outdated assumptions.

A reasonable starting point: install Ollama, pull a coding model, plug it into OpenCode or something similar, and take the next small task you would give Claude Code. Give it to the local setup instead. Notice where it falls short and where it surprises you.

You will find that for a lot of the routine stuff (boilerplate, refactors, small features, tests), local models are closer to what you pay for than the marketing lets on. For hard problems, you will still want a frontier model. That is fine. The point is not to replace Claude. The point is to stop depending on it.

If running local is not an option, the same logic works through APIs. There are providers selling access to these open models for a lot less than Anthropic charges.

Closing

The question in 2026 is not "cloud or local". It is "which model for which task, and who decides".

If Claude Code costs $100/month next week, what happens to how you work? If the answer is "everything breaks", that is not really an AI problem. That is a dependency problem. And it is true for every other tool in your stack.

The hedge is not loyalty. It is having a plan B. Spend a Saturday on it.