PremiereRemote 702.gg in Live-Session mit AI-generiertem Code validiert

Streamstart und technische Vorbereitungen

00:06:53

Der Stream beginnt mit einer ungewohnten Situation, da der Streamer abends statt morgens codet. Zunächst werden technische Hürden wie Fensterpositionierungen und Copyright-Strikes (z.B. für das Intro 'Carry On Plays') thematisiert. Der Streamer erklärt, dass er zuvor auf dem Sofa codiert hat und diese Session live überträgt, um die Entwicklungsarbeit transparent zu machen. Trotz kleiner Probleme wie fehlenden Plugins oder fehlgeschlagenen Entwicklertools wird die Umgebung schrittweise aufgebaut, darunter ein DevContainer und neue Port-Konfigurationen (z.B. 8084 → 42000).

Erste Funktionsprüfung und Plugin-Validierung

00:11:46

Nach der Einrichtung wird ein erstes Plugin (PremiereRemote 702.gg) geladen und validiert, wobei der Streamer die automatisierte Neuladung via Stream Deck demonstriert. Der Server und Client werden neu gebaut, um die aktuelle Sequenz (141 Main) zu aktivieren. Ein zentraler Fokus liegt auf der Swagger-UI, die die generierten API-Endpunkte (z.B. 'Get Active Sequence') anzeigt. Der Streamer betont, dass die Architektur auf AI-generiertem Code basiert, der jedoch manuell nachgebessert wurde – etwa bei Performance-Optimierungen (z.B. 5x4-Operationen).

Technische Architektur: Client, Server und Shared-Modul

00:18:25

Der Streamer erklärt die grobe Aufteilung des Projekts in drei Hauptbereiche: Client (interagiert mit Adobe Premiere), Server (WebSocket/HTTP) und ein neues Shared-Modul (Typen-Definitionen). Das Shared-Modul wird als eigenständiges Paket extrahiert, um Abhängigkeiten zu zentralisieren – eine Maßnahme zur Verbesserung der Wartbarkeit und Vermeidung von Anti-Patterns wie 'God Objects'. Der Server-Code, ursprünglich monolithisch, wird in separate Klassen (HTTP-Server, WebSocket-Server) zerlegt. Kritisch wird die fehlende Dependency Inversion bemängelt, da der HTTP-Server direkt vom konkreten WebSocket-Server abhängt.

Refaktorisierung und Design-Prinzipien

01:00:18

Im weiteren Verlauf wird die Architektur weiter verfeinert, indem der HTTP-Server und WebSocket-Server als eigenständige Klassen umgesetzt werden. Der Streamer diskutiert Design-Prinzipien wie Dependency Injection und Inversion (SOLID-Prinzipien), wobei er kritisiert, dass KI-generierter Code oft gegen diese Prinzipien verstößt. Beispielhaft wird gezeigt, wie eine Abstraktion für WebSocket-Server die Flexibilität erhöht. Zudem wird die Nutzung von AI-Tools wie 'Caveman' oder 'Gemini' für Code-Optimierung thematisiert, wobei der Streamer betont, dass manuelle Reviews unverzichtbar bleiben, um Qualität zu sichern.

Der Streamer reflektiert die Schwierigkeiten, Code zu entwickeln *und* unterhaltsam zu streamen, und zieht Vergleiche zu anderen Content-Formaten wie Minecraft-24/7-Farmen. Er warnt vor der Illusion, dass KI-Tools allein Produktivität steigern können, da unkritische Nutzung zu sinkender Code-Qualität und höheren Support-Kosten führen kann. Gleichzeitig betont er die Chancen von KI für repetitive Aufgaben (z.B. Testgenerierung) und die Notwendigkeit manueller Steuerung. Der Stream endet mit einem Ausblick auf die Zukunft von Coding-Streams und der Frage, ob diese Formate langfristig relevant bleiben – besonders vor dem Hintergrund sinkender KI-Kosten, aber steigender Trainingskosten.

Codegenerierung und technische Diskussionen

01:14:52

Der Streamer thematisiert zunächst die generierte Code-Menge und deren Qualität, wobei er betont, dass schlechter Code zwar unterhaltsam sein kann, aber grundlegende Prinzipien wie saubere Implementierungen und strukturiertes Arbeiten nicht vernachlässigt werden sollten. Er diskutiert die Vorzüge von Abstraktionen im Code, insbesondere die Dependency Inversion, die durch Dependency Injection umgesetzt wird. Dies soll die Änderungsausbreitung minimieren und die Wartbarkeit erhöhen. Zudem wird der UXP-Pitch-Interface eingeführt, der als Abstraktionsebene dient und nur benötigte Methoden exponiert.

Architektonische Entscheidungen und Metriken

01:17:20

Der Fokus liegt auf der Begründung für Design-Entscheidungen wie Dependent Inversion und Abstraktionen, die die natürliche Begrenzung von Änderungen fördern. Der Streamer kritisiert dabei oberflächliche Metriken wie Token-Verbrauch oder Logging-Ausgaben, die in seinem Unternehmen irrelevant seien – entscheidend sei stattdessen, ob Aufgaben erfüllt werden. Er reflektiert seine persönliche Einstellung zum Programmieren und betont, dass Code nicht nur funktionieren, sondern auch sinnvoll strukturiert sein muss. Die Diskussion über die Automobilbranche und deren technologische Einfachheit dient als humorvolle Überleitung.

CI/CD-Pipelines, Testing und Refactoring

01:20:40

Es wird ein CI/CD-Script als bessere Alternative zu Pre-Commit-Hooks präsentiert, das nach dem Refactoring-Pipelines grün markiert und den Code auf Linting- und Formatierungsfehler prüft. Obwohl der Streamer zunächst betont, keine Tests geschrieben zu haben, wird später die Bedeutung von Tests für nachhaltige Refactorings hervorgehoben. Die Pipeline wird als entscheidend für professionelle Softwareentwicklung dargestellt, wobei der Streamer seine eigene Unerfahrenheit und die Vorteile kontinuierlicher Integration lobt.

Der Streamer integriert einen WebSocket-Server und plant die Portierung älterer CP-Implementierungen auf UXP, um Drehregler auf dem Streamback anzubinden. Zudem wird ein MCP-Server für KI-Anwendungen angekündigt, der sich aus einer generierten OpenAPI-JSON speist. Die bisherige Entwicklung wird als Framework-gestützte Lösung beschrieben, die nun erweiterbar gemacht werden soll. Humorvolle Kommentare zu KI-Modellen wie Claudia Opus unterstreichen den Unterhaltungswert des Streams.

Fazit und Ausblick

01:27:48

Der Stream endet mit der Feststellung, dass trotz technischer Hürden (exzessiver Token-Verbrauch) und unvollendeter Arbeiten (Server-Entvibfelieren) ein produktiver Abend mit Code-Refactorings und architektonischen Diskussionen stattgefunden hat. Der Streamer verweist auf ein bevorstehendes 25-minütiges Radiointerview zum Thema Solarpunk und kündigt an, im nächsten Stream weitere Implementierungen vorzunehmen – wann dieser stattfindet, bleibt jedoch unklar. Humorvoll endet er mit dem Aufruf, Solarpunkl-Turniere zu unterstützen.