Marktmannen wiki Coderen met AI

Parallelle Bouwagents met Screenshot-Zelfkritiek (Fable 25)

Laatst bijgewerkt

TL;DR: Eén orchestrator-sessie als art director plus N parallelle bouwagents, elk met een verplichte render→kijk-naar-de-pixels→herstel-en-verbeter-lus, leverde volgens het project zelf 105 onderling verschillende websites op zonder templates — de kwaliteitssprong zit in het sluiten van de lus tussen geschreven code en gerenderde pixels.

Een praktijkverslag van een portfolio van volledig door agents gebouwde websites. Bij de eerste verwerking (juli 2026) telde het 55 sites in drie golven (25 → 30 → 55); volgens de site zelf staat de teller in oktober 2026 op 105 sites in vijf golven, met 330+ kritiekpassages. Alle cijfers in dit artikel zijn zelfgerapporteerd door het project (eigen showcase) en niet onafhankelijk geverifieerd. De reusable kern is niet "genereer een site 25 keer", maar een orchestrator/builder-split met een verplichte visuele zelfkritiek-lus. Wall-clock van prompt tot deploy voor de eerste golf: volgens het project circa drie uur, grotendeels besteed aan parallelle kritiekpassages.

De site vermeldt dat hij gebouwd is door Claude Fable 5; de huidige Fable-versie is Fable 5.1.

De architectuur: één director, N studio's

  • Eén orchestrator-sessie schrijft een gedeelde design constitution (BRIEFS.md): een niet-onderhandelbare bouwstandaard (echte copy, onderscheidende typografie, custom easing, responsive, toegankelijkheid, nul console-errors) plus per site een individueel art-directed brief met concept, palet, lettertypes, signature-techniek en één ding dat de site moet bewijzen.
  • N parallelle bouwagents (subagents van hetzelfde model) krijgen elk één brief en volledige autonomie over één map. Bewust géén templates en géén gedeelde componenten, zodat twee sites niet naar elkaar toe kunnen convergeren.
  • De orchestrator doet daarna cold review: bekijkt zelf de screenshots van elke afgeronde site en stuurt terug met specifieke QA-bevindingen (afbreking midden in een woord, knop met te weinig contrast, tekst die verzuipt in artwork).

De zelfkritiek-lus

Elke site doorloopt drie verplichte iteratiepassages. Eén passage is:

  1. Render de echte pagina in headless Chrome via een minimale Puppeteer-harnas — desktop én mobiel, boven/midden/onder, met console-errors en documenthoogte.
  2. Kijk naar de pixels. De agent leest zijn eigen screenshots met vision en bekritiseert ze als een vijandige design director: ritme, uitlijning, contrast, weduwen, dode zones, alles wat naar "AI-default" ruikt.
  3. Herstel alles wat gevonden is — en voeg één bewuste complexiteits-upgrade toe (textuur, micro-interactie, marginalia, easter egg). Die upgrade-regel voorkomt dat iteratie convergeert naar brave middelmaat.

Het harnas is ~25 regels:

node shot.js http://localhost:4179/strata/ out.png 1440x900 4000 [scrollY]
// → {"out":"out.png","docHeight":3834,"errors":[]}

Waarom dit werkt: code review ziet geen weduwe of modderige knop. Het sluiten van de lus tussen geschreven code en gerenderde output is wat "plausibele output" verandert in ontwerpoordeel. De 3D-terreinsite leverde zijn eerste passage af als een zwart niets; de eigen screenshot-kritiek ving dat en herbouwde mist, camera en belichting.

Assetpipeline: genereren, dan behandelen als productiemateriaal

Media wordt on demand gegenereerd (text→image, image→video, image→3D) en daarna geoptimaliseerd als elk professioneel asset:

  • Elke afbeelding: ffmpeg → WebP, ≤1920px breed — 5 MB PNG's worden 40–190 KB.
  • Elke video: h264, CRF 26, muted, faststart — onder 600 KB, veilig om te autoplayen.
  • Video genereren vanuit de hero-still houdt poster en loop visueel continu.

Totale generatiekosten eerste golf volgens het project: circa 40 credits voor ~27 assets. Vijftien van de 25 sites zijn volledig procedureel (GLSL, canvas, SVG, CSS) — restraint is ook een budget.

Operationele lessen uit de latere golven

De lessen hieronder komen uit de gids (stand juli 2026); wat golf 4 en 5 aan nieuwe lessen opleverden, is nog niet verwerkt.

  • Assetgeneratie hoort bij de director, niet bij de builders — één wachtrij, één budget, geen botsende caps. Delegeren naar builders werkt wél bij ≤2 jobs per agent onder een gedeelde cap.
  • Headless-Chrome screenshot-modi kunnen machinebreed vastlopen onder parallelle belasting; pin de stabiele modus in het gedeelde harnas.
  • Een 12 MB GLB is een ontwerpfout, geen asset — 1K WebP-textures brachten het terug naar 2 MB zonder zichtbaar verlies.
  • Terugkerende bevinding wordt regel: tekst over een heldere 3D-scène heeft altijd een text-shadow nodig (drie van zes sites vergaten het en alle drie moesten terug); bij extreem drukke achtergronden een zachte scrim-plaat.
  • Naamgevingsbotsingen tussen DOM- en scene-code (bijv. een .stage-class) zetten camera en copy uit de pas.

Het reproductierecept

  1. Schrijf een bouwstandaard die agents niet kunnen wegonderhandelen (copykwaliteit, motion, a11y, nul errors).
  2. Schrijf echte briefs — benoem palet, typografie, signature-techniek en wat bewezen moet worden.
  3. Geef elke agent een screenshot-harnas en eis N kritiekpassages met een complexiteits-upgrade-regel.
  4. Genereer media async en vroeg; optimaliseer als productie-asset.
  5. Houd één sessie als director: bekijk elke hero-shot koud, stuur terug met specifieke bevindingen.
  6. Deploy statisch. Complexiteit in de pixels, niet in de pipeline.

Ingebouwd alternatief voor de orchestratie: Claude Code heeft inmiddels dynamic workflows: een JS-script orkestreert subagents (standaard 16 tegelijk, instelbaar tot 256, max 1.000 agents per run, geen gebruikersinput midden in een run). Daarmee is de director/builder-verdeling zonder eigen orchestrator-sessie op te zetten; zie Dynamic Workflows. De cold review door één director en de screenshot-lus per builder moet je dan wel zelf in het script en de briefs vastleggen.

Zelfdocumentatie als bijproduct

Elke site draagt zijn eigen /guide-route, geschreven door de agent die hem bouwde, in de visuele taal van die site: de ontvangen brief, de signature-techniek met code-excerpten uit de eigen source, herkomst van de assets, en wat de drie kritiekpassages daadwerkelijk vonden en veranderden. De documentatie is dus onderdeel van de deliverable, niet een aparte stap achteraf.

Toepasbaarheid buiten websites

De drie overdraagbare mechanismen zijn tool- en domeinonafhankelijk:

  • Niet-onderhandelbare bouwstandaard + per-taak brief — te vertalen naar elk batchproces waarin output onderling moet verschillen maar aan dezelfde ondergrens moet voldoen.
  • Gerenderde-output-kritiek in plaats van code review — de agent moet het resultaat beoordelen (screenshot, PDF, gerenderde mail), niet de bron.
  • De complexiteits-upgrade-regel — een expliciete anti-convergentie-instructie die voorkomt dat iteratie richting het veilige gemiddelde zakt.

Open vragen

  • Werkt de complexiteits-upgrade-regel ook bij niet-visuele deliverables (rapporten, offertes), of leidt hij daar tot ruis in plaats van kwaliteit?
  • Bij welke N per director wordt de cold review de bottleneck? (Het project schaalde zelf door naar 105 sites in vijf golven; hoe de review daarbij verliep, is niet verwerkt.)
  • Hoeveel van de kwaliteitssprong komt van de vision-kritiek zelf en hoeveel van simpelweg drie verplichte iteraties?

Verwante concepten

Bronnen

#agents #architectuur #werkwijze

Backlinks