DEV Community: Kevin Julián Martínez Escobar

3 Developer Archetypes That Can Break a Team

Kevin Julián Martínez Escobar — Tue, 22 Sep 2026 08:31:47 +0000

There are developers who make a team faster. There are developers who make a team better. And there are developers who slowly make a team dependent on them, without anyone noticing.

The three I want to talk about are usually rewarded for it. They look experienced, productive, sometimes indispensable. AI is making all three of them easier to scale.

1. The Senior Cynic

You have met this one. Years of experience and a long list of things that do not work. Every new approach reminds them of something they tried five years ago. A simpler architecture will not scale. A different testing strategy was already tried. Another tool is not going to solve anything.

Experience is valuable. It becomes a problem when it turns into a filter that rejects anything unfamiliar. The Senior Cynic is usually not protecting the architecture, they are protecting the mental model they have built over their career. Knowing why something failed in the past is useful. Assuming it cannot work in a different context is not.

AI makes this cheaper. Ask for arguments and you get arguments: comparisons, trade-off tables, a full technical rationale for the position you already held. You no longer just have a strong opinion, you have twenty pages backing it up in ten seconds.

The antidote is not optimism, it is evidence. Try the thing. Measure it. Let the current context weigh more than the muscle memory.

2. The Guess Coder

This one is easier to spot, because it shows up in the code. They build for a future that does not exist yet. A simple requirement becomes an abstraction. The abstraction becomes a framework. The framework needs configuration, the configuration needs an extension system, and now you maintain infrastructure for a problem you have never actually had.

The intentions are usually good. They want to avoid technical debt. They want something that scales. They have read about SOLID, clean architecture, hexagonal architecture, event-driven systems, distributed everything. The catch is that principles without context turn into cargo cult engineering, and often the best architecture for the future is the simplest one you can change today.

AI makes this effortless. Ask an agent to "make this extensible" and you get hundreds of lines of perfectly reasonable looking code. It compiles. The structure looks sophisticated. And you have just spent an afternoon solving a problem you do not have.

The fix is not to stop thinking about the future, it is to separate known future requirements from imagined ones. Build for what you know, keep the code easy to change, and validate an assumption before you turn it into architecture.

3. The Superhero

This is the one I worry about most.

The Superhero knows everything. The weird legacy service, how the deploy actually works, why that obscure config exists. When production breaks, everybody knows who to call. They are genuinely valuable, and that is exactly the problem.

The team learns that the fastest route to a solution is to ask them. So people stop investigating. They stop learning the system. They stop taking ownership. The Superhero rarely pushes back on that, and sometimes reinforces it: "I'll just do it", "it's faster if I handle it", "I'll explain it later". Because they are good at solving problems, it works. In the short term.

Then the organization starts rewarding the behavior. They become the person who saves releases and fixes incidents, and being indispensable starts to look like career progress. But there is a difference between being valuable and being a dependency. A healthy team should not need one specific person to keep operating.

The goal is not to stop the Superhero from solving incidents. It is to make sure the next incident does not need the same person. Fix the problem, share what you learned, improve the system, hand the responsibility over, reduce the odds of it happening again. Otherwise you are not removing the fire, you are building a very efficient fire department around one person.

What the three have in common

They look nothing alike, and they optimize for the same thing: themselves, instead of the team's ability to operate without them. The Cynic protects their experience. The Guess Coder protects their imagined future. The Superhero protects their indispensability.

AI amplifies all three. More arguments, more complexity, more changes landing faster than the rest of the team can follow them.

Which is why I do not think AI adoption is mostly a tooling problem. It is a team problem. A team with a strong engineering culture gets amplified. A team with weak delegation, thin tests, knowledge silos and a taste for over-engineering gets amplified too, and much faster.

What to optimize for instead

Not developers who know everything, but developers who make knowledge accessible. Not developers who build for every possible future, but developers who keep today's system easy to change. Not developers who are indispensable, but developers who make the team less dependent on them.

The strongest developer on a team is probably not the one who can solve every problem. It is the one who makes sure the team does not have to solve the same problem twice.

With AI in the loop, that distinction matters more, not less.

Your Agent Says the Tests Pass. Watch Them

Kevin Julián Martínez Escobar — Tue, 15 Sep 2026 07:25:23 +0000

An agent opened a pull request on my repo last week. Eleven files changed, three new tests, all green.

So what do you actually check?

You can read the diff. You can read the test file and see what it asserts. Both of those tell you what the agent believes it built. Neither tells you what a person using the thing would see, and that gap is where the interesting failures live.

I added a label. A minute later there was a comment on the pull request:

Recording: 3 clip(s), one per test this branch added.

Three short videos. One per test the branch added. I watched them in under a minute and knew more than the diff had told me in five.

The green tick got cheaper

For twenty years a passing test was a reasonable proxy for "someone thought about this". A human wrote the test, then wrote code until it passed. The test carried the intent of a second person, or at least of the same person on a different day.

When an agent writes the code and the test that proves the code, that separation is gone. The test is not an independent check. It is the same model's opinion, expressed twice.

That does not make the test worthless. It makes it a claim rather than evidence, and claims need checking in a way that evidence does not.

The cheapest check I have found is watching the thing run.

A test file tells you what it asserts, not what it looks like

Here is a test that passes and proves nothing useful:

const el = await screenDom.findByRole("button", { name: "Add project" });
twd.should(el, "be.visible");

The button exists. It is visible. The test is green.

It is also possible that the button sits on top of the heading, that the empty state it belongs to renders below the fold, or that clicking it does nothing at all because nobody asked for that yet. All of those are consistent with a green run and none of them are visible in the test file.

You do not find those by reading harder. You find them by looking.

Deterministic, not a demo

The distinction that makes this useful rather than decorative: the clip is produced by the run, not recorded by a person.

A demo video is a performance. Somebody walked through the app once, on their machine, at a moment when it happened to work, and the recording starts going stale the second it is saved. Six months later it shows a UI that no longer exists, and nobody notices because nobody regenerates it.

A test recording is the same execution that produced the green tick, captured. Re-run the suite and you get a new clip. Change the behaviour and the clip changes with it, or the test fails and there is no clip at all. It cannot drift from the code, because it is the code running.

That is what makes it safe to attach to a pull request and safe to keep.

The pacing detail that makes it watchable

The first time I tried recording a test suite I got a video that was mostly a flash. Tests run in milliseconds. A faithful recording of a fast test is unwatchable, which is why most attempts at this quietly get abandoned.

twd-cli paces the execution itself rather than slowing the video down afterwards:

npx twd-cli run --record --test "checkout flow"

Frames are captured at full rate and the pauses land where something just happened. The default is 300ms between actions, and --record-pace moves it:

npx twd-cli run --record --record-pace 500 --test "checkout flow"

The difference between pacing the run and slowing the file matters more than it sounds. A slowed-down video is uniformly sluggish. A paced run has rhythm: the click, then a beat, then the thing that happened. You can follow it.

Output is one file per matched test, named after the test:

twd-artifacts/
  todos-adds-a-todo.mp4
  todos-marks-a-todo-done.mp4

In CI, record only what changed

Recording an entire suite on every pull request produces an archive nobody opens. The version that gets watched records only the tests the branch added or modified:

uses: BRIKEV/twd-cli/.github/actions/record@v1.8.0
with:
  changed-since: ${{ github.event.pull_request.base.sha }}

The action installs ffmpeg, runs the recording, uploads the clips as an artifact, and gives you back a count and a URL you can put in a pull request comment. The inputs are documented at twd.dev/recording#recording-in-ci.

Three clips on a pull request is a review aid. Four hundred clips is a data retention problem.

Who it is actually for

The person who cannot read the test. A product owner can watch fifteen seconds and say "that is not what I meant". They cannot say that about a test file, and they will not tell you they cannot read it. They will just approve.

You, in six months. The pull request that changed this behaviour has a clip in it. That is a faster answer to "what did this used to do" than any amount of archaeology.

You, at 5pm. Reviewing agent output is a new and genuinely tiring kind of work. The bottleneck stopped being how fast code gets written and became how much of it you can actually check. Video is the highest bandwidth per second of attention I have found.

What it costs

A label, or one flag. Recording requires ffmpeg 8 or later, and twd-cli validates it before launching the browser so you get a clear failure rather than a corrupt file.

In my repo it is a record label on the pull request, applied after the agent has finished. Not automatic, because not every change is worth a video, and the person deciding that is me.

That is the whole trade. A minute of CI and a minute of watching, against approving a diff you skimmed because it was green.

Your Tests Pass. Your Layout Is Broken

Kevin Julián Martínez Escobar — Tue, 08 Sep 2026 21:18:14 +0000

You change one line of CSS. A flex-direction, a max-width, a padding on a shared card component.

Every test passes. The button is still there, the text still says "Continue", the modal still opens. Green across the board.

And the pricing page now has three columns overlapping on top of each other.

Assertions were never going to catch that

This is not a gap in your test suite. It is what assertions are.

twd.should(button, 'have.text', 'Continue');
twd.should(modal, 'be.visible');

Those questions are about content and state. Is the text right, is the element there, is it enabled. Every one of them still answers yes on a page whose layout has collapsed, because none of them is looking at where anything sits.

The information you need is geometry, and nothing in a normal test suite is measuring it.

So why doesn't everyone do visual testing?

The tools have existed for years. Most teams either never adopt them or quietly stop looking at them, and the reason is not the invoice.

It's the approval queue.

A visual testing tool compares screenshots pixel by pixel. So a font renders half a pixel differently, or a shadow shifts, and you get forty changed screenshots to review. None of them is a bug. You click approve on all of them.

Do that twice and you have learned a habit: approve the batch, do not look. From that point on your visual testing is a formality. You are paying for a service and reviewing nothing, which is worse than not having it, because now everyone believes it's covered.

The failure mode is not "it costs money". It's "it produced so much noise that we stopped reading it".

Watch the geometry, not the pixels

twd-js ships a beta command called matchLayout that starts from a different question. Not "are these two images identical", but "did anything move".

await twd.matchLayout(page, 'landing');

It deliberately does not see a colour change. It does not see a changed string. It does not see a font rendering one pixel wider. Those either do not matter for layout or are already covered by the assertions you have.

What it does see is a block that grew, a column that collapsed, a button that wrapped, a section that disappeared. When it fails, you get your own page backwith the areas that moved boxed in red:

Red is a region that changed. Orange is a region that is new, because the page got taller. Everything else is left alone, and that is most of the page.

Being coarse on purpose is the whole point. There is nothing to approve in bulk because the noise never gets generated.

The reference is a text file

The other half of the approval problem is where the review happens.

With a hosted tool, approving is a separate queue: another dashboard, another login, a list of thumbnails to get through. That separation is what turns reviewing into clicking.

matchLayout writes a small text file next to your test and you commit it. When a layout changes, the diff shows up in the pull request you were already reading.
There is no second queue, because approving is the code review.

No screenshots in git. No container spinning up somewhere to render your page. No account.

Try it

The verdict is decided by twd-cli, which
pins the viewport, so a snapshot never fails because you resized your browser while working.

npx twd-cli run

First run writes the reference and passes. Change your CSS, run again, and you get the picture above. If the change was intentional, --update-snapshots accepts it.

The docs are at twd.dev/layout-snapshots.

It's beta, and honest about what it is: a guard on geometry, not a pixel comparison. If you want to know that a button is exactly #1a1a1a, assert it.
If you want to know that your footer did not just eat the page, this is the cheaper way to find out.

Run Vue Component Tests Where Vue Runs: The Browser

Kevin Julián Martínez Escobar — Mon, 31 Aug 2026 09:13:04 +0000

A Vue component's job is to produce DOM in a browser. Most component tests ask it to do that somewhere else: in Node, against a DOM that jsdom simulates. That has been the default since npm create vue@latest started offering Vitest with jsdom, and for plenty of tests it is the right trade. It does set a ceiling on what a green test proves, though. Nothing is ever drawn. Your CSS never runs and nothing has a size or a position, so a component can pass every assertion in the file and still be broken on screen.

I co-maintain twd-js, which runs tests inside your actual dev server, in a sidebar, next to the app. It was built for flow testing: visit a route, click through the app, assert on what the user sees. Component testing was the thing it did not do.

Then I tried calling render() from @testing-library/vue inside a TWD test.

import { afterEach, describe, it } from "twd-js/runner";
import { twd, userEvent } from "twd-js";
import { render, screen, cleanup } from "@testing-library/vue";
import HomeView from "../../views/HomeView.vue";
import { componentHost, restorePage } from "../support/componentHost";

describe("HomeView component", () => {
  afterEach(() => {
    cleanup();
    restorePage();
  });

  it("increments the counter on click", async () => {
    // componentHost() is a blank div on an empty page. More on it below.
    render(HomeView, { container: componentHost() });

    const button = await screen.findByTestId("counter-button");
    twd.should(button, "contain.text", "Count is 0");

    await userEvent.click(button);
    twd.should(button, "contain.text", "Count is 1");
  });
});

Nothing broke. The component mounts into the page, the sidebar shows it running, and reactivity does what reactivity does, in a browser, against a DOM nobody had to simulate.

Why this works at all

Vue Testing Library is a thin layer. render() mounts your component with @vue/test-utils and binds @testing-library/dom queries to the result. Neither of those is tied to jsdom. jsdom is just the DOM most people hand them.

Give them a real one and the same code runs, except now the component is actually on a screen, with a real size, a real position, and your CSS applied to it. TWD already runs inside your app in the browser, so the real DOM is right there.

The setup

One helper, and no changes to your app.

render() appends its container to document.body, so the component lands after #app, a full viewport below your layout. The app is also still on the page, so screen matches its elements as well as the ones your test just rendered. Both of those are the same problem: the app is in the way.

const HOST_ID = "twd-component-host";
const APP_ROOT_ID = "app";

let appRoot: HTMLElement | null = null;
let placeholder: Comment | null = null;

export function componentHost(): HTMLElement {
  detachApp();

  let host = document.getElementById(HOST_ID);
  if (!host) {
    host = document.createElement("div");
    host.id = HOST_ID;
  }
  if (!host.isConnected) {
    document.body.prepend(host);
  }

  host.innerHTML = "";
  return host;
}

export function restorePage(): void {
  document.getElementById(HOST_ID)?.remove();
  attachApp();
}

function detachApp(): void {
  if (placeholder) return;

  const root = document.getElementById(APP_ROOT_ID);
  if (!root) return;

  appRoot = root;
  placeholder = document.createComment(" app detached by twd component test ");
  root.replaceWith(placeholder);
}

function attachApp(): void {
  if (!placeholder || !appRoot) return;

  placeholder.replaceWith(appRoot);
  placeholder = null;
  appRoot = null;
}

Detaching the app root is not the same as emptying it. app.innerHTML = "" pulls the DOM out from under Vue while its vnodes still point at those nodes, and the next router navigation patches elements that are no longer in the document. Moving the node out and putting it back leaves that correspondence intact, so restorePage() returns a live app.

prepend rather than append puts the component at the top of the page. It also keeps it in normal flow, which matters in a browser: the page is offset to make room for the TWD sidebar, and anything in normal flow inherits that offset for free.

One detail worth keeping: cleanup() and restorePage() belong in afterEach, not beforeEach. In jsdom the environment is torn down for you between files. In a real browser it is not, so renders stack up, and your flow tests need the app back before they run.

That is the whole setup. Your app does not change.

The part that changes how the test reads

Here is the same idea on a view that fetches on mount and posts a form.

it("posts the form values when a todo is created", async () => {
  await twd.mockRequest("getTodoList", {
    method: "GET",
    url: "/api/todos",
    response: [],
    status: 200,
  });
  await twd.mockRequest("createTodo", {
    method: "POST",
    url: "/api/todos",
    status: 201,
    response: { id: "1", title: "Write the Vue post", description: "In a real browser", date: "2026-09-01" },
  });

  render(TodosView, { container: componentHost() });
  await twd.waitForRequest("getTodoList");

  await userEvent.type(await screen.findByLabelText("Title"), "Write the Vue post");
  await userEvent.type(screen.getByLabelText("Description"), "In a real browser");
  await userEvent.type(screen.getByLabelText("Date"), "2026-09-01");

  await userEvent.click(screen.getByRole("button", { name: "Create Todo" }));

  const rule = await twd.waitForRequest("createTodo");
  expect(rule.request).to.deep.equal({
    title: "Write the Vue post",
    description: "In a real browser",
    date: "2026-09-01",
  });
});

Nothing here is stubbed except the network. The component's onMounted, its ref state, the v-model bindings and the axios call all run for real, and the assertion is on the request that actually left the browser. In jsdom that test usually starts with a vi.mock of the API module, and from then on you are asserting that your component calls your mock correctly.

userEvent here comes from twd-js, which re-exports @testing-library/user-event so there is nothing extra to install. It drives v-model the way a person does, one key event at a time, and in a real browser those are real key events.

Both kinds of test, one run

Component tests and flow tests are now the same kind of artifact. Files in the same project, listed in the same sidebar, running in the same browser session against the same bundle. There is no second runner, no second DOM, and no second config to keep in sync.

The one thing to configure is the other direction. If you also run Vitest in the same repo, exclude the browser tests from it, or Vitest will collect them, find no describe it recognises, and fail the run:

test: {
  exclude: [...configDefaults.exclude, "**/*.twd.test.*"],
},

Where each style fits

Rendering a component in isolation is the right move when the component is the subject: a form's validation states, a modal that opens and closes, a table that sorts. You skip the navigation, you skip the fixtures, and the test says exactly what it is about.

Flow tests stay the right move for anything that crosses a boundary. Routing, data loading, a sequence of screens, state that survives a navigation. Rendering a component in isolation to test those means rebuilding the app around it, which is how component test files end up longer than the components.

The useful change is not that one replaced the other. It is that choosing between them is now a decision about scope, made per test, instead of a decision about which runner and which DOM you are committing to.

Try it

If you already have Vue Testing Library tests, copy one, change the imports for describe and it to twd-js/runner, and hand render() the component host. The rest of the test stays as it is.

The example app is on GitHub, with the same component tested in jsdom and in the browser side by side: BRIKEV/twd-vue-example.

I wrote the React version of this first, if you want the same walkthrough with @testing-library/react: No More Fake DOM.

No More Fake DOM: Testing Library Unit Tests in the Real Browser

Kevin Julián Martínez Escobar — Thu, 27 Aug 2026 18:34:24 +0000

Every Testing Library test you have written runs against a simulated DOM. You know this. You accepted it years ago, along with the small pile of things that come with it: no real layout, nothing ever drawn on a screen, jsdom throwing on APIs it does not implement, and the quiet suspicion that a passing test and a working component are not quite the same claim.

I co-maintain twd-js, which runs tests inside your actual dev server. It was built for flow testing: visit a route, click through the app, assert on what the user sees. Component testing was the thing it did not do, and I said so in print when I compared it to Vitest Browser Mode.

Then I tried calling render() inside a TWD test, mostly to see what would break.

import { render, screen, cleanup } from "@testing-library/react";
import { describe, it, afterEach } from "twd-js/runner";
import { AppProvider } from "@/context/AppContext";
import { twd } from "twd-js";
import { Add } from "../Add";
import { componentHost, restorePage } from "@/twd-tests/support/componentHost";

describe("Add Component", () => {
  afterEach(() => {
    cleanup();
    restorePage();
  });

  it("renders the Add component", () => {
    // componentHost() is a blank div on an empty page. More on it below.
    render(<AppProvider><Add /></AppProvider>, { container: componentHost() });

    twd.should(screen.getByText("Add Item"), "be.visible");
  });
});

Nothing broke. The component mounts into the page, the sidebar shows it running, and the assertion checks an element that exists in a real browser. Same Testing Library API, no fake DOM under it.

That AppProvider is the real one, not a test double. Add uses a hook that reads from context and posts to an API, and in a real browser both of those work, so there is nothing to stand in for. That turns out to matter more than the missing jsdom.

Why this works at all

Testing Library was never tied to jsdom. @testing-library/react renders a component into a DOM node and @testing-library/dom queries it. jsdom is just the DOM most people hand it. Give it a real one and the same code runs, except now the component is actually on a screen, with a real size, a real position, and your CSS applied to it.

TWD already runs inside your app in the browser, so the real DOM is right there. render() uses it.

The setup

One helper, and no changes to your app.

render() appends its container to document.body, so the component lands after the app, a full viewport below the layout. The app is also still on the page, so screen matches its elements as well as the ones your test just rendered. Both of those are the same problem: the app is in the way.

const HOST_ID = "twd-component-host";
const APP_ROOT_ID = "root";

let appRoot: HTMLElement | null = null;
let placeholder: Comment | null = null;

export function componentHost(): HTMLElement {
  detachApp();

  let host = document.getElementById(HOST_ID);
  if (!host) {
    host = document.createElement("div");
    host.id = HOST_ID;
  }
  if (!host.isConnected) {
    document.body.prepend(host);
  }

  host.innerHTML = "";
  return host;
}

export function restorePage(): void {
  document.getElementById(HOST_ID)?.remove();
  attachApp();
}

function detachApp(): void {
  if (placeholder) return;

  const root = document.getElementById(APP_ROOT_ID);
  if (!root) return;

  appRoot = root;
  placeholder = document.createComment(" app detached by twd component test ");
  root.replaceWith(placeholder);
}

function attachApp(): void {
  if (!placeholder || !appRoot) return;

  placeholder.replaceWith(appRoot);
  placeholder = null;
  appRoot = null;
}

Detaching the app root is not the same as emptying it. root.innerHTML = "" pulls the DOM out from under React while it still holds references to those nodes, and the app does not come back. Moving the node out and putting it back leaves the references intact, so restorePage() returns a live app.

prepend rather than append puts the component at the top of the page instead of below where the app used to be, so you can watch it run without scrolling.

The payoff is that screen behaves exactly like it does in jsdom. The only thing in the document is what your test rendered, which also covers anything the component renders through a portal, since that lands on document.body rather than inside the container.

That is the whole setup. Your app does not change.

Two traps

screenDom will not find your component. TWD exposes screenDom, a wrapper around Testing Library queries scoped to your app root so it never matches the TWD sidebar. Testing Library's render() mounts outside that root. I probed it in a real app to be sure:

container.parentElement=<body>   inside #root=false
screen: found   screenDom: not found   screenDomGlobal: found

So use Testing Library's own screen, or TWD's screenDomGlobal, which queries the whole document. If you pick screenDomGlobal, keep queries specific, because it can also match elements inside the sidebar.

Everything else works normally. twd.should takes any element you hand it, whether a query found it in your app or in a component you just rendered.

Your test pattern probably says .ts. Component tests are .tsx. A pattern of /**/*.twd.test.ts skips them silently, with no error and no missing-file warning. They simply never appear in the sidebar:

twd({
  testFilePattern: "/**/*.twd.test.{ts,tsx}",
}),

If you also run Vitest in the same repo, exclude the browser tests from it. Vitest matches *.test.tsx by default, collects the TWD files, finds no describe it recognises, and fails the run with No test suite found in file:

test: {
  exclude: [...configDefaults.exclude, "**/*.twd.test.*"],
},

Both kinds of test, one run

This is the part I did not expect to matter as much as it does.

Component tests and flow tests are now the same kind of artifact. They are files in the same project, running in the same browser, in the same session, against the same instrumented bundle. So one command runs both:

$ npx twd-cli run
Running 14 test(s)...
Code coverage data written to .nyc_output/out.json

--- Run complete ---
  Passed: 14 | Failed: 0 | Skipped: 0
  Duration: 6.9s

Ten of those drive the whole app through routing, search, sorting and deletion. Four render a single dialog component in isolation. One coverage file comes out the other end, covering both.

That last part is usually where multi-runner setups get tedious. Component coverage in one report, end-to-end coverage in another, and a merge step that someone maintains. Here there is nothing to merge, because there was only ever one run.

Where each style fits

Rendering a component in isolation is the right move when the component is the subject: a form's validation states, a dialog that opens and closes, a table that sorts. You skip the navigation, you skip the fixtures, and the test says exactly what it is about.

Try it

If you already have Testing Library tests, the fastest way to see this is to copy one, change the imports for describe and it to twd-js/runner, and hand render() the component host.

The example app from this post is on GitHub, with the same component tested in jsdom and in the browser side by side: kevinccbsg/frontend-challenge.

In the next post I look at what happened when I put those two versions next to each other. The jsdom test mocked the hook it was testing through, and once I stopped mocking, it turned out the mocks had been doing most of the work.

AI Made Code Review the Bottleneck. Attach the UI to Your PR

Kevin Julián Martínez Escobar — Wed, 29 Jul 2026 18:57:30 +0000

You open a frontend pull request. The diff is 400 lines, an AI agent wrote most of it, and the description says "adds the checkout flow". CI is green.

You read the diff. It looks reasonable. You still have no idea what the UI actually does.

So you do what you always do. You pull the branch, install dependencies, start the dev server, and click through the flow yourself.

Ten minutes later you approve the PR.

That ten minutes is the bottleneck now.

AI made writing code dramatically faster. Reviewing frontend behavior did not.

Tests solve part of the problem

Tests already reduce a large part of that uncertainty.

With twd-js, they execute inside a real browser, against the real DOM, with the network mocked so runs stay deterministic. A green run means the entire flow actually executed.

But a green run only tells the reviewer that the assertions passed.

It does not tell them what the user sees.

Was the validation message attached to the correct field?

Did the modal actually close?

Does the empty state look intentional, or does it look broken?

Those are exactly the things reviewers still verify manually, and they are difficult to express as assertions alone.

Put the flow in the pull request

Your tests already drive the application through the exact flow under review.

If reviewers could simply watch that execution, they would not need to pull the branch just to understand the UI.

twd-cli can record the run:

npx twd-cli run --record --test "checkout flow"

That produces:

twd-artifacts/checkout-flow.mp4

Drop the video directly into the pull request description.

The first problem you'll hit

The first time you try this, you discover something unexpected.

The tests finish in about a second.

The recording is technically correct.

It is also almost impossible for a human to follow.

Slowing the video down is the wrong fix

The obvious solution is to stretch the recording afterwards.

A simple ffmpeg filter can do that, but it stretches the same frames across a longer duration. As playback slows down, the effective frame rate drops.

Speed	Duration	Effective FPS
1x	1.00s	30
0.5x	1.90s	15.3
0.25x	3.90s	7.7

At quarter speed, you're watching an 8 FPS video.

It also slows every moment equally. The interesting interactions and the idle time both become longer. The result is not easier to understand. It is simply slower.

This is where architecture matters

Most testing tools record a browser that is being driven from the outside.

The recording is a byproduct of automation, so once execution has finished, post processing is your only option.

TWD works differently.

Its commands execute as JavaScript inside the page itself.

Because TWD owns the command loop, it can control when commands execute, not just how the recording is encoded.

Instead of stretching frames afterwards, it spaces out execution while the test is running.

Frames are still captured at full frame rate.

Pauses happen only after meaningful interactions.

Typing is paced character by character instead of appearing all at once.

That produces a recording that feels natural to watch without sacrificing smoothness.

Which is why recordings are paced by default:

# Default: 300ms pause after each command
npx twd-cli run --record --test "checkout flow"

# Better for demos or stakeholder reviews
npx twd-cli run --record --record-pace 500 --test "checkout flow"

In practice, values between 200ms and 500ms are usually enough to make interactions comfortable to follow while keeping recordings concise.

The result is still a smooth 30 FPS video.

Only the moments that matter become easier to observe.

What the reviewer gets

The reviewer watches the actual flow.

Driven by the actual tests.

Running against the actual application.

Not a screen recording someone remembered to make.

Not a Loom video that becomes outdated after the next commit.

The recording is regenerated every time the tests run.

The review changes from:

"Does this diff look correct?"

to:

"Is this the behavior we actually wanted?"

That is the question worth a human's attention.

The bottleneck moved

Every improvement in software development moves the bottleneck somewhere else.

Today, AI has made writing code significantly faster.

Frontend review is still largely manual because reviewers need to understand behavior, not just source code.

A green checkmark confirms that the tests passed.

It does not show what happened.

Browser based tests can produce something much more valuable than a success badge.

They can produce evidence.

Sometimes, that evidence is a short video that saves every reviewer ten minutes.

npx twd-cli run --record --test "the flow you changed"

If your tests already know how to reproduce the feature, your pull request should show it.

See the Recording Runs documentation for all available options.

Testing microfrontends with TWD, one suite per team

Kevin Julián Martínez Escobar — Mon, 27 Jul 2026 20:21:04 +0000

Microfrontends split a frontend into apps that build, deploy and version on their own. One team ships React 19, another is still on React 17 and migrating away from it, a third runs Vue. That independence is the point, and it is usually why the architecture got chosen.

It also means there is no single test setup anymore.

What usually happens to testing

Each team picks its own stack, and the same product ends up with three runners, three sets of conventions, and three different definitions of a passing build. Or testing gets pushed into one shared end-to-end suite that lives outside every team's repo and belongs to nobody. When that suite goes red, the argument about whose change broke it takes longer than the fix.

Neither outcome is anyone's plan. Both are what you get when the architecture splits and the testing story does not follow it.

Testing is harder to skip now

A lot of frontend code is generated rather than typed. Reading all of it line by line does not scale, and the useful question is not whether it looks right, it is whether the app still does what it claims. That answer has to come from the real thing, and it has to be cheap enough that every team gets it on every change.

Splitting a frontend is a reasonable way to move faster. Splitting it and losing the check that the pieces still work is not.

The same runner, whatever the framework

TWD runs tests inside the real browser, in a sidebar next to the app. It does not care which framework rendered the page, so the React team, the legacy React team and the Vue team all install the same thing.

Setup stays small. On Vite it is a plugin. On other bundlers it is a few lines in the dev entry point, plus one command to drop in the mock service worker. Nothing ships to production.

Each app keeps its own installation, its own tests and its own mocked endpoints. No shared fixture file, no shared test repo, nothing to coordinate before a team can ship. If you work with external vendors, "ship a green TWD suite" is an acceptance criterion they can satisfy in their own pipeline.

Tests that outlive the framework

The suites read like Testing Library: findByRole, findByText, a click. Anyone who has written a React Testing Library test knows the shape already.

Because the assertions run against the DOM and the accessibility tree, the same test works against a React class component, a React hooks component and a Vue component. That matters most for the team on the old version. The usual reason a legacy microfrontend exists is that someone is migrating away from it one route at a time, and tests written this way do not get rewritten when that migration lands. The suite is the part that survives.

Living documentation, in the tab you already have open

The sidebar sits next to the running app. The tests are executable examples of what each page does, in the same place you develop, so a new team member reads behaviour by running it instead of guessing from the code.

The same suites in CI

twd-cli runs the same tests headless. Each team points it at its own dev server and runs its own suite in its own pipeline:

npx twd-cli run

Nobody blocks anybody. Nothing gets rewritten into a second framework for the pipeline. What you watched pass in the sidebar is what runs on the pull request.

One thing to know

Today TWD is set up per microfrontend, and each one is tested on its own. Testing the fully composed page, with every microfrontend mounted together, is not something it does yet. In practice the split suits the architecture: teams own their own apps, and their tests follow the same boundary.

Try it

Microfrontends give every team its own framework, its own release and its own repo. They should not cost you the tests.

TWD: twd.dev
Example repo (three microfrontends, three frameworks, a TWD suite each): github.com/BRIKEV/twd-module-federation
Getting started: twd.dev/getting-started
Frameworks and bundlers: twd.dev/frameworks
Writing tests: twd.dev/writing-tests
API mocking: twd.dev/api-mocking
CI execution: twd.dev/ci-execution

Real-browser testing for Open Cells apps with TWD

Kevin Julián Martínez Escobar — Mon, 27 Jul 2026 08:39:38 +0000

Open Cells is an open-source framework from BBVA for building web apps out of Web Components. It leans on Lit, real Shadow DOM, a hash-based router, and channels for state. If you build with Cells, you are working with real custom elements the whole way down. That is what makes Cells apps feel solid. It is also what makes them interesting to test.

The usual Vite stack, and the gap

A Vite app usually reaches for two tools: Vitest for component tests and Playwright for end-to-end. Both are solid. For a Web Components app, each leaves a gap.

Vitest runs in Node against a simulated DOM. For custom elements that means rebuilding the parts that matter most: Shadow DOM, element upgrades, the router, browser storage. You spend your effort standing in for the browser instead of using it, and you test an approximation of your app.

Playwright drives a real browser, but a separate one, outside the tab you develop in. It shines for full end-to-end flows and is heavier for the everyday component check.

TWD offers a third place to test: the real browser, in a sidebar next to your app. Your Cells app renders exactly as it always does, and the tests run against it right there. Real DOM, real components with their Shadow DOM intact, real browser APIs. The only thing you replace is the network.

Not just Cells

TWD is framework-agnostic. It works with any client-rendered frontend: React, Vue, Angular, Solid, Lit and Open Cells, even HTMX or plain vanilla JavaScript. If your app renders in the browser, TWD tests it in the browser. Cells is simply where the real-browser approach pays off most, because Cells is Web Components all the way down.

Setup is small

Cells apps run on Vite, and TWD installs as a Vite plugin. Add it to the config and the TWD sidebar appears next to your app, discovering your tests. Nothing to wire into your entry file, nothing shipped to production.

The tests read like Testing Library: findByRole, findByText, a click. Anyone who has written a React Testing Library test already knows the shape.

Because the tests run in a real browser, browser APIs are real. localStorage, sessionStorage, cookies: no mocks, no shims. A feature that reads a saved preference or a stored session is tested against the browser actually doing it. When you need to cut the app off from the outside world, you mock the network, so a page that calls a backend runs against fixed responses and stays deterministic and offline.

Coverage, without changing the build

TWD also produces coverage. A coverage-only dev server instruments the app, the headless runner collects it, and you get a standard report. No change to how the app is built beyond that coverage serve. The same tests run in CI with one command, so what you write in the dev tab is what runs on every pull request.

Try it

For a framework built on Web Components, the real browser is the natural place to test. Cells gives you real custom elements. TWD lets you test them as they actually run.

TWD: twd.dev
Example repo (a Cells app tested with TWD): github.com/BRIKEV/twd-cells
Writing tests: twd.dev/writing-tests
API mocking: twd.dev/api-mocking
CI execution: twd.dev/ci-execution
Coverage: twd.dev/coverage

Testing HTMX apps in the real browser with TWD

Kevin Julián Martínez Escobar — Wed, 22 Jul 2026 20:48:23 +0000

HTMX apps are refreshingly simple: the server returns HTML fragments, and HTMX swaps them into the page in response to hx-get, hx-post, and friends. There is usually no bundler and no client framework. That simplicity is the point, and it is also why the usual testing tools feel wrong. A jsdom unit test cannot see an HTMX swap, and a full end-to-end runner is a lot of machinery to bolt onto an app that deliberately avoids machinery.

twd-js fits the HTMX model well. It runs tests inside the real browser, so it sees exactly what HTMX does to the DOM, and it installs from a CDN with an import map, so it adds no build step of its own.

Setup: load both from a CDN

Load HTMX as usual, then add an import map for TWD next to it. esm.sh resolves TWD's internal dependency, so there is nothing else to wire up.

<script src="https://unpkg.com/htmx.org@2.0.10/dist/htmx.min.js"></script>
<script type="importmap">
  {
    "imports": {
      "twd-js": "https://esm.sh/twd-js@1.8.2",
      "twd-js/runner": "https://esm.sh/twd-js@1.8.2/runner",
      "twd-js/bundled": "https://esm.sh/twd-js@1.8.2/bundled"
    }
  }
</script>

Your markup stays pure HTMX:

<button hx-get="/api/todos" hx-target="#todo-list" hx-swap="innerHTML">Load todos</button>
<ul id="todo-list"></ul>

Test against the real backend

The important design choice for HTMX is what to assert against. Because HTMX endpoints return HTML fragments rather than JSON, the cleanest approach is to run the tests against your real HTML-returning backend and reset it between tests, rather than mocking. This is the same pattern the Nuxt example uses for real-backend testing.

A tiny dev-only reset endpoint gives every test a clean starting point:

import { twd, userEvent, screenDom } from 'twd-js';
import { describe, it, beforeEach } from 'twd-js/runner';

describe('Todo List (HTMX)', () => {
  beforeEach(async () => {
    await fetch('/api/reset', { method: 'POST' });
  });

  it('loads the seeded todos', async () => {
    await twd.visit('/');

    const loadButton = await screenDom.getByRole('button', { name: 'Load todos' });
    await userEvent.click(loadButton);

    // HTMX swaps asynchronously, so use findBy* (which waits) rather than getBy*.
    const todo = await screenDom.findByText('Learn TWD');
    twd.should(todo, 'be.visible');
  });
});

The one detail worth internalizing: HTMX swaps happen after an async request, and there is no mock to await, so query with Testing Library's findBy* (which retries until the element appears) instead of the synchronous getBy*.

A note on mocking

TWD's service worker will happily intercept HTMX's requests, the same as any fetch or XHR. Today twd.mockRequest serializes responses as JSON, which is a natural fit for JSON APIs but not for HTML fragments, so for HTMX we recommend the real-backend approach above. First-class HTML-fragment mocking for hypermedia frameworks is on the roadmap.

Try it

A complete example, an HTMX todo list with load, create, and delete, a small Express backend with a reset endpoint, in-browser tests, and CI, lives in twd-htmx. It is served as static files with TWD loaded straight from the CDN, so you can read the whole thing top to bottom without a build step in sight.

Test your vanilla JS app in the real browser, with no build step

Kevin Julián Martínez Escobar — Wed, 22 Jul 2026 20:47:10 +0000

Not every app has a bundler. Plenty of real software is still a folder of HTML and JavaScript served as static files: internal tools, landing pages, small products, and anything deliberately kept simple. These apps ship and they matter, but their testing story is thin.

The usual options do not fit. Jest plus jsdom tests a fake DOM, so tests pass while the real page breaks. Playwright is a lot of stack, and its own runner, for an app whose whole appeal is that it has no stack. What is missing is something in between: real browser behavior, without a build step to earn it.

twd-js is that middle option. It runs your tests inside the real browser, in a sidebar next to your app, using Testing Library queries you already know. And because its bundled build is self-contained, you can load it from a CDN with an import map. No bundler, no npm install.

Setup: one import map

TWD's bundled entry ships everything it needs, and esm.sh resolves its internal dependency automatically. So the entire install is an import map in your HTML:

<script type="importmap">
  {
    "imports": {
      "twd-js": "https://esm.sh/twd-js@1.8.2",
      "twd-js/runner": "https://esm.sh/twd-js@1.8.2/runner",
      "twd-js/bundled": "https://esm.sh/twd-js@1.8.2/bundled"
    }
  }
</script>

Then boot TWD from your entry module. With no bundler there is no import.meta.glob, so you list your test files by hand: a label pointing at a lazy import of each one.

<script type="module">
  import { initTWD } from 'twd-js/bundled';

  if (location.hostname === 'localhost') {
    initTWD(
      {
        './tests/helloWorld.twd.js': () => import('/tests/helloWorld.twd.js'),
        './tests/todoList.twd.js': () => import('/tests/todoList.twd.js'),
      },
      { open: true, position: 'left', serviceWorker: true, serviceWorkerUrl: '/mock-sw.js' },
    );
  }
</script>

The localhost guard keeps TWD out of production. Wrap your app in a known root such as <div id="app"> so TWD's scoped queries know where to look.

The tests read like Testing Library

Test files import from the same bare specifiers the import map defines. If your team has ever written a Testing Library test, this is familiar:

import { twd, userEvent, screenDom } from 'twd-js';
import { describe, it } from 'twd-js/runner';

describe('Counter', () => {
  it('increments on click', async () => {
    await twd.visit('/');
    const button = await screenDom.getByText('Count is 0');
    await userEvent.click(button);
    twd.should(button, 'have.text', 'Count is 1');
  });
});

Mocking works too

TWD ships a mock service worker. The library loads from the CDN, but the service worker has to be served from your own origin, because browsers only register same-origin service workers. Run npx twd-js init public (or download mock-sw.js from the CDN) once, and API mocking works exactly like a bundled setup:

await twd.mockRequest('getTodos', {
  method: 'GET',
  url: '/api/todos',
  response: [{ id: '1', title: 'Learn TWD' }],
  status: 200,
});
await twd.visit('/todos');
await twd.waitForRequest('getTodos');

The part that pays off later

Here is the argument for starting with TWD even on a throwaway vanilla app: the tests are not tied to vanilla JS. They are Testing Library queries and TWD commands against the rendered DOM. The day you outgrow plain HTML and move the app to React, Vue, or Solid, the test files come with you unchanged. Only the setup changes: the import map becomes a devDependency and a Vite plugin.

That makes TWD a low-commitment way to add real tests now, and a migration you never have to redo. A working end-to-end example, counter and todo list, API mocking, and CI, lives in twd-vanillajs.

The easiest way to test a legacy Create React App

Kevin Julián Martínez Escobar — Tue, 14 Jul 2026 13:15:20 +0000

Create React App was officially deprecated in February 2025. The apps built with it didn't disappear. If you maintain one, you know the drill: the app works, it ships, and the Vite migration sits on the backlog behind everything that makes money.

The testing story is where that hurts. Your options look like Jest plus jsdom, where tests pass while the real page breaks, or bolting Playwright onto an app that's in maintenance mode. One is too far from the browser, the other is a lot of stack for an app nobody wants to invest in.

There's a third option. twd-js runs your tests inside the real browser, in the dev server you already have open, using Testing Library queries you already know. Every TWD guide assumes Vite, but the library doesn't care about your bundler. It works on CRA's Webpack with one block of code.

That's the TWD sidebar next to a CRA app. The tests drive the actual page: real DOM, real router, real fetch calls intercepted by a service worker.

Setup

Install the library and copy the mock service worker into public/:

npm install --save-dev twd-js
npx twd-js init public

Vite projects get a plugin that handles test discovery. On Webpack you wire it yourself with require.context in src/index.js:

if (process.env.NODE_ENV === "development") {
  // Webpack's version of import.meta.glob
  const context = require.context("./", true, /\.twd\.test\.ts$/);

  const testModules = {};
  context.keys().forEach((key) => {
    testModules[key] = async () => Promise.resolve(context(key));
  });

  const { initTWD } = await import('twd-js/bundled');

  initTWD(testModules, {
    open: true,
    search: true,
    serviceWorker: true,
    serviceWorkerUrl: '/mock-sw.js',
  });
}

The NODE_ENV guard keeps all of it out of the running production app.

One detail that surprised me: the test files are TypeScript (.twd.test.ts) inside a plain JavaScript CRA project, and that just works. CRA's Babel pipeline strips types without the typescript package installed. You don't get type checking on the tests, but they compile and run.

You already know the queries

TWD's screenDom wraps @testing-library/dom and its userEvent wraps the Testing Library user-event package. If your team writes Testing Library unit tests today, the tests read the same. The difference is where they run.

import { twd, userEvent, screenDom } from "twd-js";
import { describe, it } from "twd-js/runner";

describe("Hello World Page", () => {
  it("should display the welcome title and counter button", async () => {
    await twd.visit("/");

    const title = await screenDom.getByText("Welcome to TWD");
    twd.should(title, "be.visible");

    const counterButton = await screenDom.getByText("Count is 0");
    await userEvent.click(counterButton);
    twd.should(counterButton, "have.text", "Count is 1");
  });
});

Run npm start, open the app, and the sidebar lists your suites. Click one and watch it drive the page you're looking at.

Mocking the API

The service worker intercepts requests before they leave the browser, so tests are deterministic without a backend running (expect ships with twd-js, no chai install needed):

it("should create a todo", async () => {
  await twd.mockRequest("getTodoList", {
    method: "GET",
    url: "/api/todos",
    response: [],
    status: 200,
  });
  await twd.mockRequest("createTodo", {
    method: "POST",
    url: "/api/todos",
    response: { id: "1" },
    status: 200,
  });
  await twd.visit("/todos");

  await userEvent.type(await screenDom.getByLabelText("Title"), "Test Todo");
  await userEvent.type(await screenDom.getByLabelText("Description"), "Test Description");
  await userEvent.type(await screenDom.getByLabelText("Date"), "2024-12-20");
  await userEvent.click(await screenDom.getByRole("button", { name: "Create Todo" }));

  const rule = await twd.waitForRequest("createTodo");
  expect(rule.request).to.deep.equal({
    title: "Test Todo",
    description: "Test Description",
    date: "2024-12-20",
  });
});

That last assertion checks the exact body your form submitted. If someone renames a field in the payload, this fails in the sidebar while you're developing, not in QA.

Two gotchas (and the fixes)

CRA's tooling assumes every test file in src/ is a Jest test. TWD tests are not, so there are two collisions.

Jest picks up the TWD tests. react-scripts test matches *.twd.test.ts and tries to run browser tests in jsdom. Exclude them in the test script:

"test": "react-scripts test --testPathIgnorePatterns=src/twd-tests"

ESLint flags the assertions. The react-app/jest preset reports TWD's chai-style expect(...).to.deep.equal(...) as jest/valid-expect errors, and CRA surfaces them as compile errors in the dev server. Relax the rules for TWD test files only:

"eslintConfig": {
  "extends": ["react-app", "react-app/jest"],
  "overrides": [
    {
      "files": ["src/twd-tests/**/*", "**/*.twd.test.*"],
      "settings": {
        "testing-library/utils-module": "off",
        "testing-library/custom-renders": "off",
        "testing-library/custom-queries": "off"
      },
      "rules": {
        "jest/valid-expect": "off",
        "jest/valid-expect-in-promise": "off"
      }
    }
  ]
}

Everything stays strict for your regular Jest tests.

CI in one job

The same tests run headlessly with twd-cli, a Puppeteer-based runner. After the usual checkout and npm ci, the whole job is: start the dev server, run the CLI.

- name: Start CRA dev server
  run: |
    nohup npm start > cra.log 2>&1 &
    npx wait-on http://localhost:3000
  env:
    CI: true
    BROWSER: none

- name: Run TWD tests
  uses: BRIKEV/twd-cli/.github/actions/run@main

The CLI can also validate every request mock against an OpenAPI spec, so your mocks can't silently drift from the real API. See contract testing if that's your kind of thing.

The whole thing is a repo

Everything above comes from a working example with green CI: twd-create-react-app. The CRA guide in the TWD docs covers the same steps.

When you finally migrate to Vite

Here's the payoff that outlasts the maintenance work. These tests are agnostic to your bundler. They drive the real DOM in a real browser, not your webpack config, so nothing in them is tied to CRA.

When the Vite migration finally gets prioritized, you don't rewrite the suite. You run it against the new build and confirm the app behaves exactly as before. TWD runs on Vite too, so the tests carry over untouched. The setup you added to survive on CRA is the setup that tells you the migration worked.

Your app might be legacy. Your tests don't have to be.

The Production Bug You Can't Reproduce by Clicking

Kevin Julián Martínez Escobar — Fri, 03 Jul 2026 11:40:59 +0000

A payment request showed up in production logs with country: "ROW" at the top level and billing_address.country: "FRA" inside the customer object. Two different countries in the same body. The frontend clearly sent it, but nobody could make it happen again.

Every team has a bug like this. The payload contradicts itself, the logs prove it happened, and no amount of clicking through the app reproduces it. That's usually the signature of a timing bug: something failed, or arrived late, at exactly the wrong moment.

Why Manual Testing Can't Touch It

We tried to reproduce it by hand first. No luck.

The reason is structural, not lack of effort. To trigger this bug you need one specific API call, the price recalculation that fires when the user changes country, to either fail or respond slowly, at the exact moment the user submits the payment. Manually, you have no lever for that:

You can't make the real backend fail once, on demand, for one request.
Browser devtools throttling is global and clumsy: it slows everything, not the one call you care about.
Even if you get lucky once, you can't do it twice. A repro you can't repeat is not a repro.

So the bug stays "unconfirmed", the ticket goes stale, and the payload keeps showing up in the logs every few weeks.

An Agent Reads Code, Not Screens

This is where the AI agent changed the approach. Instead of guessing from the outside, it read the code and found that the app keeps the country in two places: one in the billing form the user fills in, and one in app state, set when the page first loads. When the user picks a different country, the app fires a background request to update prices, and only when that request succeeds does the app state catch up with the form.

That gap between "the form changed" and "the app state caught up" is the whole bug. Two ways to fall into it, found in minutes:

The background request fails. The app state keeps the old country, the form shows the new one, and the pay button still works.
The user pays too fast. The payment is built before the background request comes back, so it still reads the old country.

Both are timing conditions. Both are exactly the kind of thing you can't produce by clicking. And both are trivial to express as TWD mocks, because in TWD the test controls the server's behavior per request.

The failure case is one mock:

await twd.mockRequest("recalcFail", {
    url: "/api/pricing/quote",
    method: "POST",
    status: 500,
    response: { message: "recalculation failed" },
});

await selectBillingCountry("France");
await twd.waitForRequest("recalcFail");

await clickSubmitPayment();
const rule = await twd.waitForRequest("createPayment");

// The exact payload from the production logs
expect(rule.request.country).to.equal("ROW");
expect(rule.request.customer.billing_address.country).to.equal("FRA");

Note the assertion: twd.waitForRequest returns the intercepted body, so the test checks what the app actually sent over the wire, not what the UI displayed.

Reproducing the Race with a Delayed Mock

The second path needs timing control: the recalculation must succeed, but slowly. TWD mocks accept a delay, so the service worker holds the response while the test keeps going:

await twd.mockRequest("recalcSlow", {
    url: "/api/pricing/quote",
    method: "POST",
    status: 200,
    response: cartResponse,
    delay: 3000,
});

await selectBillingCountry("France");
await clickSubmitPayment(); // pay before the recalculation lands

const rule = await twd.waitForRequest("createPayment");
expect(rule.request.country).to.equal("ROW"); // stale, the store never updated

No setTimeout in the test, no flaky sleep, no real backend behaving badly on cue. The race is deterministic because the delay is part of the mock definition. The condition we could never hit manually now reproduces on every single run.

Both tests passed on the first attempt. Weeks of "cannot reproduce" closed in one session.

What Made the Difference

Two things, and neither is magic:

The agent reads code. A human reproducing a bug works from the UI inward and has to guess where the timing window is. An agent works from the code outward: it finds the store, the sync mechanism, and the gaps, then writes tests that target them directly.
The mock layer makes timing a test input. Failures and delays are declared per request, in the test file, running against your real app in the browser. That turns "race condition" from something you hope to catch into something you specify.

The whole loop ran through twd-relay, which drives the browser tab you already have open, so every repro attempt was visible as it executed. After the fix, the same two tests stayed in the suite as regression coverage.

If you have a ticket that says "cannot reproduce" and a log line that says otherwise, this combination is worth trying: let the agent read the code and put the timing in a mock.