Ein Tag für den Bühnenmonitor – und halb so viele Regeln

Im Thalia Theaterverein aus Weeze steht bald unsere Vorführung an, und wir hatten nie eine sinnvolle Lösung, um Informationen zu teilen oder das Bild der Bühne sauber zu den Schauspielern zu bringen. Bisher liefen dort Kameras, die übers Internet streamten, doch dafür war das WLAN zu langsam. Es musste etwas Eigenes her.

Gleichzeitig wartete Kettenhemd auf Arbeit. Am Ende von Teil 3 wollte ich mein Regelwerk einfrieren, bis 20 echte Aufgaben aus mindestens zwei Projekten erledigt sind. Nur hatte ich an meinen anderen Projekten zuletzt kaum gearbeitet, und 20 Aufgaben waren nicht absehbar; im Plan stand der 13. November als erwartetes Ende.

Eine Frage um zwanzig vor sechs

Für lose Ideen nutze ich seit dem 24. Oktober die Ideenschmiede, ein Repo, in dem ich mit einem Agenten Ideen festhalte und weiterspinne, die noch keinem Projekt gehören. Dort gibt es keine Issues, keine Freigabe und keinen Reviewer. Eine Idee wandert durch wenige Stände von „Funke“ über „gemockt“ bis „reif“, und eine reife Idee zieht als neues Projekt aus. Seit dem Umzug nach Linux kann ich dort auch vom Handy aus eine Session starten.

Am 5. November um 05:40 legte der Agent dort die Idee Bühnenmonitor an. Ich hatte gefragt, ob es möglich ist, mit einem Pi und ein paar Kameras etwas aufzubauen, damit wir vernünftige Technik haben. Daraus entstand direkt noch eine Regieanweisung, mit der die Regie kurze Texte wie „Pause bis 20:45“ oder „Alle zur Bühne“ über dem Kamerabild an die Tablets hinter der Bühne schickt.

Sechs Minuten später lag der erste Mock der Tablet-Ansicht im Repo, um 05:50 folgte der Mock der Regieanweisung. Die Mocks waren unglaublich angenehm detailliert, und wir kamen schnell zu einem Ziel. Am 5. November flossen 22 Entscheidungen von mir in die Idee ein – etwa nur Bild und kein Ton, nur live und keine Aufzeichnung. Auch der Datenschutz war geklärt; die Kameras sind so ausgerichtet, dass kein Publikum im Bild ist, und die Mitglieder wissen von ihnen. Um 11:15 war die Idee „reif“.

Der Pi aus der 3D-Drucker-Zeit

Um 13:39 bekam Kettenhemd den Tag für Version 17, womit die Bewährung begann. Um 15:07 stand das Repo für den Bühnenmonitor, und um 16:41 folgte das erste Issue.

Am längsten hielt mich an diesem Tag die Hardware auf. Ich musste erst den Raspberry Pi finden, den ich früher für meine 3D-Drucker verwendet hatte, um OctoPrint bereitzustellen, und den ich lange nicht mehr im Einsatz hatte. Die Kameras lagen zum Glück sehr offen herum.

Danach ging es Schlag auf Schlag. Jede Aufgabe übernahm eine Untersession – also eine eigene Session, die genau ein Issue bearbeitet und dann endet. Um 17:26 lief die erste CI, um 19:44 waren Kameras und Pi geprüft, und um 20:05 die Funktionen in Issues geschnitten. Um 20:56 lief der Kamera-Dienst auf dem Pi, und um 21:41 zeigte die Tablet-Ansicht das Live-Bild.

Zwei USB-Kameras hängen links und rechts der Bühne am Pi. Der Pi rechnet ihr Bild in H.264 um und schickt es per Kabel an einen Server, wo der Streaming-Server MediaMTX die Bilder per WebRTC an die Browser der Tablets verteilt. Der übliche Weg im Netz wäre HLS gewesen – dabei wird das Video in kleine Dateien geschnitten, die der Browser nacheinander lädt, und das Bild hängt 3 bis 10 Sekunden hinterher. WebRTC hingegen schickt die Bilder direkt, bleibt unter einer Sekunde und erfüllt damit genau das, was ich am Vormittag als Bedingung festgelegt hatte.

Dreißig Minuten am Tablet

Dann kam am Abend der Rückschlag. Der Reviewer, ein Agent, der jede Aufgabe vor main prüft, ließ die Regieanweisung durchfallen. Ein Kriterium verlangte, dass eine Anweisung im Kiosk-Browser auf dem Android-Tablet auch nach 30 Minuten noch erscheint, doch das Urteil lautete: „Das Ergebnis ist nicht nachprüfbar“. Die Uhrzeiten im Issue passten nicht zu einem Test von 30 Minuten.

Da merkte ich, dass der Agent wirklich gründlich testen wollte. Ich konnte mir nicht vorstellen, was in 30 Minuten passieren soll. Er wollte unter allen Umständen sicher sein, und das hat mich schon ein wenig genervt, weil ich keine Gefahr gesehen habe. Der Pi ist aktiv gekühlt, und zwei Kameras sollten für das Ding kein Problem sein. Also schrieb ich „schließt den test ab, alles läuft“, und die zweite Runde bestand.

Um 22:48 war mit dem Verlauf der Regieanweisungen die vierte Funktion fertig – 17 Stunden nach der Idee und nach 39 Commits an einem Tag. Ich war sehr happy, das ging alles flott; die Entwicklung lief sehr zielgerichtet ab, und ich musste kaum etwas beisteuern. Für die 18 Sessions dieses Tages zeigte Claude Code zusammen 67,09 $ an, was aber ein Richtwert und keine echte Rechnung ist, denn ich nutze das Abo Claude Ultra.

Zu wenig Futter

Am Abend des 5. November waren 24 echte Aufgaben aus vier Projekten geschlossen, acht davon vom Bühnenmonitor. Damit war die Bewährung nach einem Tag voll.

Ich hatte nun nicht mehr genug Futter, denn alle Projekte waren fertig. Gleichzeitig wollte ich unbedingt das nächste Thema angehen, ein Spiel, brauchte dafür aber den Spiele-Entwickler im Kettenhemd – und den gab es in Version 17 noch nicht. Also wertete eine Untersession am 6. November aus, was da war.

Die Zahlen sahen gut aus. Eine Aufgabe brauchte im Median 38 Minuten von der Freigabe bis zum Schließen, und 20 von 23 gewerteten bestanden die erste Reviewer-Runde. Interessanter waren allerdings die drei, die durchfielen. Alle drei hingen an Kriterien, die man erst nach main, auf der Testumgebung oder am Gerät belegen kann, und meine 30 Minuten am Tablet waren eine davon. Der Reviewer prüft vor main, doch das Kriterium ließ sich erst danach belegen. Dazu kam ein zweiter Fund – Fach-Skills, also Anleitungen mit Fachwissen etwa zu einem Framework, hatte in 17 Sessions keine einzige geladen, obwohl Pläne sie nannten.

Halb so viel Text

Daraus entstand Version 18. Der Regeltext, den eine Untersession lädt, schrumpfte von rund 64 auf rund 31 KB, der des Reviewers von rund 83 auf rund 41 KB. Anthropic beschreibt in Effective context engineering for AI agents den Kontext eines Modells als begrenzte Ressource und rät dazu, nach dem „minimal set of information that fully outlines your expected behavior“ zu suchen. Mein Regelwerk war in 15 Tagen auf 25 Fallstricke und rund 200 KB angewachsen; neue Regeln gibt es jetzt nur noch mit Beleg aus einem echten Vorfall.

Was erst am Gerät belegbar ist, wird kein Kriterium mehr, sondern ein Prüfpunkt nach dem Abschluss, und das Laden der Fach-Skills prüft jetzt ein Skript. Der Spiele-Baustein kam als eigenes Plugin dazu, und die Sessions denken auf mittlerer Stufe statt auf hoher, nur der Reviewer bleibt hoch. Im Testlauf vor Version 18 lag der Richtwert im Schnitt bei 10,01 $ statt 12,10 $, und alle sechs Aufgaben bestanden in beiden Läufen die erste Runde.

Fertig ist das alles aber noch nicht. Version 18 wartet noch auf die letzte Konsistenzprüfung, und die Folge-Issues der Bewährung sind nur bis zum 6. November gezählt. Auch der Bühnenmonitor lief noch nicht im Theater; bis jetzt habe ich nur Bilder geteilt, und das Feedback ist positiv. Die Auslieferung auf den Server und den Pi im Theater bleibt ein offenes Issue.

Was die 17 Stunden möglich gemacht hat

Schnell war an diesem Tag nicht das Tippen. Als das erste Issue stand, waren die meisten Fragen schon beantwortet, von der Verzögerung bis zum Datenschutz. Wer morgen mit einer Idee für seinen Verein anfängt, sollte erst Brainstorming machen und schauen, wohin das Thema wächst. Es lohnt sich, mal ein bis zwei Stunden mit dem Agenten zu reden – was ist das Problem, wie lösen wir es, was habe ich und was kann ich damit anfangen. Die Ideenschmiede hat wenige Regeln und lässt mich sehr gut Konzepte machen.

Und die Bewährung hat mir etwas über Fristen gezeigt. Geplant war gut eine Woche, doch nach einem Tag hatte ich keine Arbeit mehr – und jetzt werde ich keine feste Zeit mehr vorschreiben.

Diesen Beitrag hat mein Agent aus einem Interview mit mir geschrieben; Zahlen und Abläufe stammen aus Kettenhemd. Gelesen und freigegeben habe ich ihn selbst.