Eén feedback loop voor tmux en Playwright: gedeeld bewijs voor mens en AI

TL;DR: Tests zouden niet alleen moeten slagen of falen. Ze zouden bewijs moeten opleveren dat mensen én AI samen kunnen reviewen. We hebben @accelerated-software-development/playwright-video-merge open source gemaakt, een klein pakket dat Playwright-opnames samenvoegt tot één geordende journey-video. Samen met tmux voor CLI-surfaces en asd.host voor het exposen van draaiende systemen geeft het mensen, AI én klanten één gedeelde werkelijkheid om naar te kijken.

Tests moeten ons niet alleen vertellen of iets is geslaagd.

Tests moeten laten zien wát er gebeurd is.

Dat is de filosofie achter veel van het werk dat we doen bij asd.host. We willen softwareontwikkeling observeerbaarder, reviewbaarder en bruikbaarder maken, voor mens én AI.

Het begint met een simpel idee:

AI hoort niet te gokken wat er gebeurd is.
AI hoort hetzelfde bewijs te inspecteren als een mens.

Voor command-line software is dat bewijs een terminalsessie. Voor frontend software is dat bewijs de browser. Geen van beide surfaces is bijzaak.

Hetzelfde bewijs voor mens en AI

tmux en

Playwright zijn twee smaken van dezelfde filosofie: maak het systeem observeerbaar, bestuurbaar en reviewbaar via hetzelfde bewijs dat mensen al gebruiken.

De AI werkt niet langer vanuit een vage prompt. Hij kijkt naar hetzelfde operationele vlak als de mens, dezelfde terminal, dezelfde browser, dezelfde flow.

Dat is het kernidee achter alles wat hieronder volgt.

Hoe tmux de CLI blootlegt

De filosofie begon niet in de browser. Hij begon in de terminal.

Met tmux sturen we commando's een echte ontwikkelsessie in en inspecteren we wat de ontwikkelaar ook zou zien, draaiende processen, logs, falende tests, server-output, shell-state, command history.

De loop is mechanisch: stuur een commando naar tmux, observeer dezelfde output als een mens zou observeren, bepaal de volgende nuttige actie, pas de code aan, draai het commando opnieuw, en vergelijk de nieuwe zichtbare staat met de vorige.

Dat is feedback-gedreven AI-ontwikkeling voor de CLI.

Playwright als browser-surface

Frontend-testen past dezelfde strategie toe op een ander vlak.

In plaats van een tmux-pane is het gedeelde vlak nu de browser. De browser laat zien wat de actor ervaart: layout, copy, navigatie, timing, frictie, gebroken states, visuele feedback.

Een mens kan de journey bekijken. Een AI kan dezelfde journey reviewen. Een klant kan dezelfde journey valideren.

Dezelfde filosofie, ander interface, beter bewijs.

Waarom geordende video review verandert

Een Playwright-trace is nuttig voor debuggen. Een screenshot is nuttig voor één state. Een video is nuttig om een journey te begrijpen.

Als opnames in willekeurige volgorde aankomen, moet de reviewer het verhaal mentaal reconstrueren. Dat verhoogt cognitive load, en het maakt AI-review onbetrouwbaar omdat het model de volgorde uit fragmenten moet afleiden.

Als tests geschreven en geordend zijn volgens de actor-journey, wordt de video review-bewijs, bruikbaar voor QA, UX-review, AI-gestuurde bug detection, klantvalidatie, sprint review, en uiteindelijk een ingesproken productvideo.

Geen gespeelde demo's. Geen nep click-throughs. Geteste flows die gereviewd, vertrouwd, ingesproken en hergebruikt kunnen worden.

playwright-video-merge installeren

Het pakket is bewust klein:

npm install -D @accelerated-software-development/playwright-video-merge

Neem video op voor elke test, niet alleen bij falen. Review-bewijs heeft de volledige journey nodig:

// file: playwright.config.ts

import { defineConfig } from "@playwright/test";

export default defineConfig({
  use: {
    video: {
      mode: "on",
      size: { width: 1280, height: 720 },
    },
  },
  reporter: [["json", { outputFile: "playwright-report.json" }]],
});

Draai vervolgens de tests en merge in report-volgorde:

npx playwright test
npx playwright-video-merge --report playwright-report.json --sort report-order -o artifacts/journey.mp4 -f mp4

Eén geordend review-artifact, in plaats van een map met losse clips.

Koppelen via MCP

Voor Claude Code blijft de MCP-setup klein:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "playwright-mcp"]
    }
  }
}

Dat is genoeg om Claude Code de browser te laten besturen, screenshots te laten maken en te laten redeneren over dezelfde artifacts die het team inspecteert.

Tests schrijven die het reviewen waard zijn

Een paar gewoontes maken het verschil tussen een map met clips en een bruikbare journey-video.

Schrijf tests als actor-journeys, niet als component-checks. Slechte titel: renders form fields. Betere titel: bureau maakt een verklaring en draagt deze over aan de klant. De tweede wordt een videohoofdstuk, een QA-artifact, een klantvalidatie-moment, en uiteindelijk, met inspraak, een product-demosegment.

Neem elke test op, niet alleen falen. Playwright neemt standaard alleen video op bij falen, prima voor debuggen maar nutteloos voor review. Zet mode: "on" voor de suites die journeys representeren, houd failure-only voor ruizige low-level tests.

Gebruik stabiele selectors. Geef voorkeur aan data-testid-attributen boven tekst of placeholders. Houd een fallback-keten aan: data-testid eerst, structureel (input[name="..."], button[type="submit"]) tweede, tekst-content nooit. Journeys die overleven copy-wijzigingen en i18n zijn journeys die je echt kunt vertrouwen.

Houd commando's genoemd en stabiel. Geef het team en de AI dezelfde shortcuts. Met asd staan het netwerk-surface en de testpipeline in één asd.yaml. Eén macro exposeert een service over HTTPS via een publieke tunnel, één automation-task neemt de journey-video op, en een before-hook houdt .env in sync bij elke run:

# file: asd.yaml
version: 1
project:
  name: "demo"
  env_template: "tpl.env"

network:
  caddy:
    enable: true
    tls:
      enabled: true
      auto: true  # HTTPS via Caddy + ACME, no manual certs
  services:
    app:
      dial: "127.0.0.1:${{ env.APP_PORT }}"
      paths: ["/"]
      public: true  # exposed over the asd.host tunnel
      subdomain: "${{ env.APP_SUBDOMAIN }}"  # one macro, one HTTPS URL

automation:
  # Runs once before every top-level `asd run X`, keeps .env in sync with tpl.env.
  before:
- on: [dev, test-journey-video]
      steps:
- uses: _sync-env

  _sync-env:
- run: "asd env sync"

  dev:
- name: "Start the app"
      background: true
      run: "npm run dev"
- name: "Apply network (Caddy + tunnel)"
      run: "asd net apply --caddy --tunnel"

  test-journey-video:
- name: "Run Playwright"
      run: "npx playwright test"
- name: "Merge into one journey video"
      run: "npx playwright-video-merge --report playwright-report.json --sort report-order -o artifacts/journey.mp4 -f mp4"

De dagelijkse commando's zijn dan kort en identiek voor iedereen, mensen, agents en CI:

asd run dev                  # app live op https://<subdomain>.tunnel.asd.host
asd run test-journey-video   # Playwright plus geordende journey.mp4 in één call

De exacte tasks verschillen per project. Het principe niet: dezelfde naam, dezelfde uitkomst, elke keer.

Hoe wij herbruikbare skills schrijven

Skills zijn de manier waarop we een workflow vastleggen zodat Claude Code 'm betrouwbaar oppakt. Een goede skill lijkt meer op een runbook dan op een prompt.

Onze interne skills volgen een gedeelde vorm. De frontmatter geeft één doel in één zin, zonder gevulsel. Een selector-referentie dekt elke pagina die de skill aanraakt, met de data-testid, structureel, nooit-tekst fallback-keten expliciet uitgeschreven. Een executieprotocol loopt in fases, initialize, execute, report, zodat elke stap inspecteerbaar is. Het rapportformaat is expliciet: timings, screenshotnamen, console error checks. En er is een onderhoudsclausule: als een selector breekt, fix dan de skill in plaats van eromheen te werken.

We publiceren ze nog niet. Zodra er een zinnige registry is om skills door te delen, doen we het wel.

Wat er volgt voor de video pipeline

We werken aan automatisering van de tmux plus Playwright video-merge zodat de terminal-feedbackloop en de browser-journey kunnen landen in één doorlopende instructievideo, CLI-setup links, browser-journey rechts, één tijdlijn.

Zodra dat live is, verwacht meer videoposts hier. Het systeem uitleggen door geteste flows in beweging te laten zien, in plaats van gespeelde screen recordings.

Wil je het nu proberen? Installeer @accelerated-software-development/playwright-video-merge van npm. Wil je je draaiende systeem op dezelfde manier exposen? Start op asd.host.

Bonus, plak dit in je CLAUDE.md

Gebruik je Claude Code? Plak dit blok in je CLAUDE.md, dan pakt de agent de asd CLI vanaf dag één op:

**ASD CLI reference:**
- curl -fsSL https://asd.host/install.sh | bash
- `asd help`, top-level command list
- `asd schema` / `asd schema --ai`, full asd.yaml field reference (project / network / services / etc.)
- `asd schema automation`, automation YAML schema: every step type, options, and skip conditions. **Check this before hand-rolling shell. asd often supports it natively (e.g. `waitFor: <url>` instead of a custom poll script, `skipWhen.port` / `skipWhen.http` instead of conditional bash).**
- `asd rules`, AI-agent behavioural guidelines for working in asd projects (read these before generating asd config)
- `asd flow`, template-to-`.env` data pipeline (shows how `tpl.env` macros plus per-mode overlays resolve)
- `asd config validate`, validate `asd.yaml` against the schema