Ein Klassenzimmer voller Roboter

Hier ist ein Workshop, den man sich wünschen kann: dreißig Plätze, neunzig Minuten, Hände auf den Tastaturen. Alle bauen einen kleinen Workflow, trainieren darauf ein winziges Modell und gehen mit etwas nach Hause, das nächste Woche noch funktioniert. Und hier ist die unbequeme Frage, die dazugehört. Bevor du dreißig echte Menschen um neunzig Minuten ihrer Aufmerksamkeit bittest: Woher weißt du, dass der Raum hält — nicht hoffst, weißt?

Die Antwort, auf die diese Plattform hinarbeitet, sind dreißig Studierende, die es nicht gibt. Keine Metapher: synthetische Akteure, die echte Browser gegen das echte System steuern, damit die neunzig Minuten im Privaten scheitern dürfen, bevor sie es in der Öffentlichkeit tun. Dieser Text ist der Entwurf dieses Klassenzimmers — worauf er ruht, und was eine Probe beweisen müsste.

Dreißig Studierende, die es nicht gibt#

Die Simulationsschicht beruht auf einem Prinzip: synthetische Eingaben, echtes System. Ein Mock ist eine synthetische Eingabe, niemals eine parallele Implementierung. Die dreißig Akteure werden über den echten Anmeldepfad angelegt — jeder ist eine echte Identität mit Session und Handle (und einer synthetischen E-Mail-Adresse, die auf .invalid endet; sogar Menschen, die es nicht gibt, bekommen Datenhygiene). Die dreißig Laptops sind echte Headless-Browser-Kontexte, die der Session über den echten Koordinator beitreten, Inhalte über den echten Sync-Pfad laden und Workflows durch die echte Engine ausführen. Jede Zeile, die ein Roboter erzeugt, ist als simuliert gestempelt, damit man hinterher aufräumen kann — und kein Laufzeitpfad darf auf diesen Stempel verzweigen. Das System kann sich für Roboter nicht heimlich besser benehmen; was sie erleben, ist exakt das, was Menschen bekommen.

Ein einziger Root-Seed zieht sich durch alles: Akteur 17 von Seed 40712 hat bei jedem Lauf dasselbe Handle, dieselbe erfundene E-Mail, dasselbe geskriptete Verhalten. Spielst du das Szenario erneut ab, spielst du die neunzig Minuten erneut ab. Für eine Probe ist genau dieser Determinismus der ganze Wert: Ändere eine Sache, lauf noch einmal — und jeder Unterschied, den du siehst, ist die Sache, die du geändert hast.

Das Drehbuch für neunzig Minuten#

Eine Probe ist eine Datei. Szenarien sind deklarativ: ein Seed; Fixtures (wie viele Akteure, welche Browser, welche Datensätze); eine Timeline, wer wann was tut; und Assertions, die am Ende gelten müssen. Weil jede Fähigkeit in Scellis ein API-Befehl ist — die Oberfläche ist nur ein Client derselben Schnittstelle —, ist das Vokabular des Drehbuchs der Befehlssatz der Plattform selbst plus Browser-Aktionen. Niemand muss ein Workshop-Simulationsfeature bauen; die Grammatik ist schon das Produkt.

seed: 40712
fixtures:
  actors: 30
  browsers: { webgpu: 20, wasm_only: 10 }
  datasets: [workshop/tabular-10k]
timeline:
  - { at: 0m,  actor: instructor,     action: doc.open }
  - { at: 2m,  actor: "seats[1..30]", action: join.session }
  - { at: 12m, actor: "seats[1..30]", action: doc.fork }
  - { at: 14m, actor: "seats[1..30]", action: run.start }
  - { at: 38m, actor: "seats[1..30]", action: doc.commit }
faults:
  - { at: 20m, kind: peer_churn,       seats: "12..17", rejoin: +2m }
  - { at: 30m, kind: coordinator_loss, duration: 3m }
assertions:
  - run.completed: { every: seat, within: lab_window }
  - commit.exists: { every: seat }
  - diagnostics: { silent_failures: none }

Der Ablauf: Die Lehrperson präsentiert zwölf Minuten auf einer geteilten Arbeitsfläche, während dreißig Cursor zusehen; dann forkt jeder Platz den Workflow und rechnet die Übung auf dem eigenen Gerät; vor dem Abschluss committen alle. Selbst die langweiligste erste Zeile verdient ihren Platz: Dreißig kalte Tabs öffnen denselben Link und ziehen das Arbeitsset der Übung — Workflow, Datensatz, Blöcke — aus der Datenbank in den lokalen Catalog jedes Platzes. Dreißig gleichzeitige Erst-Ladevorgänge sind genau die Sorte Ereignis, die man einmal gesehen haben will, bevor sie einem passiert.

Die Maschine im Kopf ist nicht die Maschine im Raum#

Zehn der dreißig Browser in dieser Fixture-Liste haben gar kein WebGPU. Das ist kein Pessimismus, das ist die ehrliche Form eines Raums: Draußen fehlt es grob einem von sieben Geräten, und Schulungsräume liegen schlechter — verwaltete Laptops, festgenagelte Browser, Hardware, die Mittelklasse war, als sie neu war. Vor einer Weile.

Was ein Platz ohne WebGPU bekommt, ist ein entworfener Zustand, kein weißer Bildschirm: Der komplette Workflow läuft auf dem CPU-Referenzpfad, hinter einem lauten, dauerhaften Banner, das genau das sagt — läuft auf CPU, langsamer. An der Lektion ändert sich nichts. Außer der Zeit. Und ein Stundenplan ist nichts als Zeit.

Also rechne, bevor du die Übung schreibst, nicht danach. Ein CPU-Pfad ist um einen großen Faktor langsamer als eine GPU, nicht um einen kleinen — bei Arbeit dieser Form eine bis zwei Größenordnungen. Nimm ein Modell mit rund 170.000 Parametern auf 40.000 Zeilen: auf einer Laptop-GPU bequem unter einer Minute — und damit auf dem langsamsten Platz im Raum irgendwo jenseits der halben Stunde. Länger als das gesamte Übungsfenster. Die Übung, die diese Multiplikation überlebt, ist bescheidener: sechzehn Merkmale in zwei verborgene Schichten, knapp elftausend Parameter, zehntausend Zeilen — rund zwei Größenordnungen weniger Arithmetik, und genau das braucht es, um den schlechtesten Platz ins Fenster zu holen, während der beste in Sekunden fertig ist. Die Regel gehört über den Stundenplan: Dimensioniere die Übung für den langsamsten Platz — die GPU macht sie bequem, niemals erst möglich.

Dreißig Cursor sind eine Demo, kein Lab#

Das Zweite, wofür die Probe da ist, ist sozial, nicht rechnerisch. Ein einziges Live-Dokument mit dreißig Cursorn ist großartig — bis es ein Lab sein soll. Skripte zwei Plätze so, dass sie während der Präsentation weitereditieren (jedes echte Klassenzimmer hat diese zwei), und die Plattform behandelt das korrekt: Änderungen validiert, Undo strikt pro Person — das Cmd+Z der Lehrperson rührt die Arbeit einer Studentin nie an. Aber korrekt behandelt ist nicht didaktisch richtig. Dreißig Menschen auf einem Graphen sind eine Menge, keine Klasse.

Das Format, das funktioniert, trennt die beiden Modi: gemeinsam für die Demo, isoliert für die Übung. Jeder Platz forkt den Workflow — die eigene Kopie, mit aufgezeichneter Herkunft. Beim Einsammeln beantwortet sich die Frage, wessen Fork das ist und wovon er stammt, von selbst.

Bei Minute zwanzig klappt das Drehbuch sechs Laptop-Deckel mitten im Lauf zu und öffnet sie zwei Minuten später wieder. Das Wiederbeitreten ist unspektakulär: Änderungen rebasen, nichts geht verloren, und wer spät beitritt, bekommt den vollen Sitzungszustand und die ganze Metrik-Kurve ab t = 0. Wer zu spät kommt, ist im Rückstand — nicht verloren.

Bei Minute dreißig tötet das Drehbuch den Sitzungs-Koordinator für drei Minuten — der klassische WLAN-Tod im Seminarraum. Die Session wird ausgesetzt; die Cursor verschwinden. Und die dreißig Läufe interessiert das nicht, denn jeder Lauf ist lokales Rechnen auf dem eigenen Gerät des Platzes; der Server trug Präsenz, nie Berechnung. Die Demo stirbt mit dem WLAN. Die Übung überlebt es. Kollaboration ist auf dieser Plattform strikt additiv, und im Klassenzimmer ist das keine Fußnote — es ist der Unterschied zwischen einem Schluckauf und einer verlorenen Doppelstunde.

Kein Account in Minute null, eine URL in Minute neunzig#

Keiner der dreißig Plätze hat einen Account. Das ist kein Kompromiss; es ist der Punkt. Eine Anmeldewand in Minute null kostet zehn Minuten und ein Drittel des Wohlwollens im Raum. Wer ohne Login kommt, tritt der Session als stabiles, zuordenbares Handle bei, forkt, baut und rechnet — Berechnung ist nie an einen Tarif gebunden, auch nicht für Menschen ganz ohne Account. Die Arbeit bleibt unter dieser anonymen Identität auf dem eigenen Gerät, bis sie es wert ist, behalten zu werden; sie später mit einem Account zu beanspruchen ist eine einzige Geste, die alles mitnimmt und nichts verliert.

Und abgegeben wird eine URL, keine Datei. Jeder Platz committet seinen Fork und prägt einen Snapshot-Link: eingefroren, inhaltsadressiert, ohne Login zu öffnen. Die Frage der nächsten Woche — wo ist meine Arbeit hin? — hat eine Antwort, die ein Link ist, und der Link löst noch auf. Dieselbe Eigenschaft, die Ergebnisse zitierbar macht, macht Hausaufgaben haltbar.

Was ein Klassenzimmer wirklich braucht#

• Keine Installationen. Die Software des Raums ist eine URL; Versions-Wildwuchs über dreißig Maschinen ist ab Minute eins nicht dein Problem. Der traditionelle erste Akt eines Hands-on-Workshops — Toolchain-Triage — existiert schlicht nicht.
• Keine Accounts zum Start. Identität kann warten, bis es etwas gibt, das sich zu behalten lohnt.
• Rechne mit der schlechtesten Maschine. Dimensioniere jede Übung für den CPU-Pfad; die GPU ist ein Bonus, nie eine Abhängigkeit.
• Gemeinsam für die Demo, isoliert für die Übung. Der Fork ist die Tür zwischen beidem.
• Am Ende stehen URLs. Committete, inhaltsadressierte Arbeit überlebt die Sitzung, das WLAN und das Semester.

Was dir dreißig Roboter nie sagen können: ob der Workshop gut ist. Sie langweilen sich nicht; sie fragen nie Moment — warum? in genau dem Moment, in dem das Warum zählt; sie vertippen sich nur auf Skript. Eine grüne Probe ist ein Beleg dafür, dass der Raum hält — dreißig Plätze, die langsamste Maschine, der WLAN-Tod mitten in der Übung —, kein Urteil über die Lehre. Dafür braucht es Menschen. Und wenn die echten dreißig auftauchen, werden Dinge schiefgehen, die kein Seed je erzeugt hat. Aber es wird auf die interessante Art schiefgehen — die, die vom Unterrichten handelt, nicht von der Infrastruktur. Mehr sollte man von einer Probe nie wollen: ein Klassenzimmer, in dem die einzigen verbliebenen Überraschungen die menschlichen sind.