Every front-end project using Vitest reaches this question at some point: environment: 'jsdom' or environment: 'happy-dom'?

The answer you usually find is "happy-dom is 2 to 4 times faster". I went looking for where that number comes from and, in most articles, it has no code, no methodology and no versions. So I decided to measure it.

I built a suite with 240 React component tests and ran it in both environments, under different Vitest configurations, several times. I also checked 20 browser APIs and behaviors in both to see what each one actually implements. The result has a surprise: Vitest's configuration matters more than the choice of library.

In the post about prompt, context and harness engineering I split the three layers apart and talked about the harness from the point of view of someone building an agent: idempotency, circuit breakers, approval gates, audit trails.

But most of us aren't building agents. We're using one: Claude Code, OpenCode, Cursor, Codex. Which raises the obvious question: if the tool already ships with a harness, what's left for me to do?

A lot. And it's exactly the part that changes results the most day to day.

If you use coding agents often, you've probably lived this scene: three terminals open, a Claude Code implementing a feature, a Codex reviewing another branch, an OpenCode investigating a bug. You go grab a coffee. When you come back, two of them have been sitting there for 15 minutes waiting for you to approve something, and one finished a while ago without you noticing.

Or worse: you accidentally close the terminal, the SSH connection drops, and the whole session goes with it.

Herdr solves exactly that. It describes itself as "where your coding agents live": a terminal runtime that keeps agents running in the background, shows the state of each one, and exposes an API so scripts (and other agents) can control everything.

Every JavaScript developer has a story with Date. The report that showed the previous day. The due date that jumped from January 31 to March 3. The birth date that changed when the user was in another time zone. The 300KB moment installed just to add a month.

Date was created in 1995, in a few days, copied from java.util.Date. Java itself deprecated most of that API shortly afterwards. JavaScript kept it for 30 years.

That's over. In March 2026 Temporal reached Stage 4 at TC39 and became part of ECMAScript 2026. It already runs without flags in Chrome, Edge, Firefox and Node 26.

This article is about what actually got better. With real, running examples, side by side with new Date().

If you follow the React ecosystem closely, you've probably tripped over this announcement this week. Dominic Gannaway launched Octane, described as "the React programming model, compiled". It's the declared successor to Inferno, the framework Gannaway himself built back in 2016 with the same performance pitch.

It's worth pausing to understand two things. First, what it actually does technically. Second, and more important for anyone making stack decisions, what its arrival says about where React is heading.

Have you ever spent half an hour refining a prompt — making the instructions clearer, more detailed, adding examples, adding constraints — and the agent kept failing in exactly the same way?

You've been there: the model hallucinates even with a perfect prompt. Or worse: the agent acts on the world, does something it shouldn't, and you find out in production. Not in the test chat, not in the sandbox. In production, with real data.

That's not a prompt problem. And polishing the system prompt text won't fix it.

This article is about understanding where the problem actually lives — and why conflating these three layers of AI engineering wastes time, money, and sometimes causes incidents.