Video-KI: Wenn das Modell den Prompt anders versteht als ich

Ein Videomodell kann eine Anweisung sichtbar erfüllen und trotzdem an ihrem eigentlichen Zweck vorbeiarbeiten. Auf einem Monitor erscheinen dann farbige Zeilen, Einrückungen und Klammern. Aus normaler Entfernung sieht das nach Programmcode aus. Beim genaueren Hinsehen ist es aber kein korrektes C#, sondern nur eine überzeugende grafische Annäherung an die Idee von Code.

Genau das passierte bei einer frühen Fassung des Operus-Manifests. Das 25-sekündige Reel sollte meine Entwicklung vom ersten BASIC-Programm über C++ und C# bis zu moderner Softwarearchitektur, Coding-Agenten und der heutigen Website operus.de erzählen. Dafür reichte es nicht, wenn die Monitore lediglich technisch wirkten. Die Inhalte mussten fachlich stimmen.

Die Video-KI verstand „zeige Programmcode“ als visuelle Aufgabe. Gemeint war aber ein exakter, lesbarer und technisch korrekter Inhalt.

Die erste Fassung sah richtig aus – bis man sie las

Die frühe Wan-Fassung besitzt eine starke Atmosphäre. Alte Computer, moderne Arbeitsplätze, Smart-Home-Bildschirme und Softwarediagramme gehen fließend ineinander über. Der Clip vermittelt sofort eine technische Entwicklung über mehrere Jahrzehnte.

Das Problem liegt mitten im Hauptmotiv. Auf den Bildschirmen steht etwas, das aus einigen Metern Entfernung wie Quellcode wirkt. Es besitzt Syntaxfarben und eine plausible Struktur, lässt sich aber nicht als echtes Programm lesen oder kompilieren. Auch Beschriftungen, Diagramme und Buchrücken folgen eher dem Erscheinungsbild einer Entwicklungsumgebung als einer konkreten technischen Aussage.

Für eine rein dekorative Szene könnte das genügen. In diesem Reel sollte der C#-Code jedoch zeigen, dass Software eine reale Smart-Home-Funktion steuert. Später sollte ein zweiter C#-Ausschnitt einen Ablauf aus Coding-, Test- und Review-Agenten erklären. Erfunden wirkende Zeichen hätten die Aussage des gesamten Videos beschädigt.

Am Ende kam noch ein zweites Problem hinzu: Eine generierte Website ist nicht dieselbe Website. Farben und Seitenaufbau können ähnlich sein, doch Logo, Navigation, Texte und Projektkarten dürfen bei operus.de nicht jedes Mal neu interpretiert werden.

Die Fassung wurde deshalb nicht veröffentlicht.

Nicht genauer prompten, sondern die Aufgabe anders aufteilen

Meine erste Reaktion hätte sein können, den Prompt noch länger zu machen: exakte Sprache nennen, Code vorgeben, Rechtschreibung verlangen und jedes Element der Oberfläche beschreiben. Bei generierten Bildern in Bewegung bleibt das jedoch riskant. Buchstaben sind keine unveränderlichen Objekte. Zwischen zwei Frames können Zeichen ihre Form wechseln, Zeilen wandern oder ganze Wörter neu entstehen.

Für die Neufassung bekam das Videomodell deshalb eine kleinere und passendere Aufgabe:

• Räume, Geräte, Licht und Kamerabewegungen erzeugen
• Übergänge zwischen den Epochen gestalten
• Monitore als stabile, dunkle Flächen freihalten
• keine Buchstaben, Zahlen, Symbole, Logos oder Benutzeroberflächen erzeugen

Den exakten Inhalt setzte ich anschließend mit Codex und Remotion ein:

• korrektes BASIC und C++
• zwei echte C#-Beispiele
• lesbare Architekturbezeichnungen
• den Ablauf der Coding-, Test- und Review-Agenten
• einen echten Screenshot von operus.de
• Musik, Feinschnitt und Übergänge

Die Idee dahinter war eine klare Arbeitsteilung: Die Video-KI übernimmt Bewegung und Atmosphäre. Remotion übernimmt alles, was exakt bleiben muss. Beim Operus-Manifest löste dieser Ansatz zwar das Problem mit Code und Schrift, er führte aber noch nicht automatisch zu einem insgesamt überzeugenden Video.

Ein Prompt mit absichtlich leeren Bildschirmen

Der Übergang vom alten Programmierplatz zum Smart Home zeigt diese Strategie besonders gut. Der Prompt verlangt ausdrücklich, dass der zweite Zoom aus dem Laptop-Display beginnt. Gleichzeitig verbietet er Code, Text und Benutzeroberflächen. Der Bildschirm soll nur eine stabile Fläche für die spätere Komposition liefern.

One continuous grounded cinematic transition from the supplied clean early-programming CRT workstation to the supplied clean smart-home workspace. Begin by pushing into the old CRT's clean dark screen. Inside the full-frame darkness, perform a precise screen-shape match cut to the clean dark display of the LAPTOP in the smart-home room. Then perform the second camera move as a slow pull OUT FROM THE LAPTOP DISPLAY: reveal the laptop bezel first, then keyboard and desk, and only afterward reveal the secondary widescreen monitor behind it and the living room. The laptop is unmistakably the source of the zoom-out, never the second monitor. Keep every display as a clean stable planar surface for later compositing. No dissolve, no crossfade, no generated text, code, letters, numbers, symbols, logos, labels or watermarks. Natural physics, stable geometry, smooth 2026 commercial cinematography, no jitter or screen warping.

Selbst diese klare Anweisung wurde nicht vollständig umgesetzt. Angefordert waren 9:16 und 1080p. Das Modell lieferte den zweiten Clip trotzdem in 1920 × 1080, also im Querformat. Weil der zentrale Laptop gut genug positioniert war, konnte ich das Material in Remotion kontrolliert beschneiden und musste keine weitere Generierung bezahlen.

Auch das ist ein typisches Missverständnis: Das Modell kann Motiv und Kamerabewegung gut treffen, während eine technische Randbedingung ignoriert wird. Entscheidend ist dann, ob sich der Fehler ohne Qualitätsverlust korrigieren lässt.

Was später wirklich auf den Monitoren stand

Der Smart-Home-Ausschnitt wurde nicht als Bild generiert, sondern als echter C#-Text gesetzt:

public async Task ActivateEveningSceneAsync(
    Room room, CancellationToken cancellationToken)
{
    await lights.SetLevelAsync(room, 35, cancellationToken);
    await blinds.MoveToAsync(room, 20, cancellationToken);
    await climate.SetTargetAsync(room, 21.5m, cancellationToken);
}

Für den Agenten-Workflow verwendete ich ebenfalls lesbaren C#-Code:

var result = await codingAgent.ImplementAsync(
    task, cancellationToken);

await testAgent.VerifyAsync(
    result.Changes, cancellationToken);

await reviewAgent.ReviewAsync(
    result.PullRequest, cancellationToken);

Damit ist der Inhalt nicht nur dekorativ plausibel. Er erzählt genau das, was die Szene behauptet: Eine Abendszene steuert Licht, Rollläden und Klima; danach implementiert ein Agent, ein zweiter prüft und ein dritter führt ein Review durch.

Technisch korrekt – und trotzdem nicht gut genug

Für die überarbeitete Fassung entstanden fünf unabhängige Übergangsclips mit Gemini Omni Flash 1.1. Jeder Clip war fünf Sekunden lang und kostete 22,5 Credits. Insgesamt wurden für diese fünf Generierungen 112,5 Credits eingesetzt. Code, Browser, Musik und Schnitt entstanden anschließend in Remotion und verursachten keine weiteren Higgsfield-Credits.

In der überarbeiteten Fassung stammen Räume, Kamerafahrten und Übergänge aus den KI-Clips. Der lesbare Inhalt bleibt davon getrennt. Der Abschluss zeigt keinen erfundenen Operus-Schriftzug, sondern einen unveränderten Screenshot der echten Website in einem kontrollierten Browserfenster.

Technisch ließ sich die Datei vollständig abspielen. Alle 750 Frames wurden zusätzlich in 15 lückenlosen Übersichten kontrolliert; Code, Website-Screenshot und Export waren sauber. Trotzdem war auch diese Fassung ein Fehlschlag. Nachdem die offensichtlichen Textprobleme behoben waren, genügte mir das Video als Ganzes nicht mehr. Bildsprache, Wirkung und Gesamteindruck erreichten nicht den Anspruch, den ich an das Operus-Manifest hatte. Es wurde deshalb ebenfalls nicht veröffentlicht.

Das war für mich eine wichtige Unterscheidung: Eine bestandene technische Kontrolle bedeutet nur, dass die Datei korrekt aufgebaut ist und keine auffälligen Einzelbildfehler enthält. Sie beantwortet nicht, ob die Geschichte überzeugt, die Gestaltung zusammenpasst oder das Ergebnis gut genug für eine Veröffentlichung ist.

Was „Missverständnis“ bei Video-KI bedeuten kann

Diese Fälle haben wenig mit einem „dummen“ Modell zu tun. Generative Videomodelle sind darauf optimiert, plausible Bilder und Bewegungen zu erzeugen. Ein Compiler, ein Browser und ein Compositing-Werkzeug lösen andere Aufgaben. Probleme entstehen vor allem dann, wenn ich von einem Werkzeug gleichzeitig Atmosphäre, Bewegung und pixelgenaue Wahrheit verlange.

Meine praktische Grenze

Inzwischen behandle ich folgende Inhalte grundsätzlich als kontrollierte Ebene außerhalb der Videogenerierung:

• echter BASIC-, C++- oder C#-Code
• lesbare Benutzeroberflächen und Diagramme
• Logos und Markenbestandteile
• Webseiten und Browserinhalte
• fest vorgegebene Texte
• Musik oder Effekte, die bildgenau einsetzen müssen

Das Videomodell darf weiterhin eine Monitorfläche bewegen, Licht darauf spiegeln lassen oder die Kamera daran vorbeiführen. Den Inhalt selbst bekommt es jedoch möglichst nicht mehr zur freien Interpretation. Beim Operus-Manifest hat diese Trennung einen konkreten Fehler beseitigt, aber das Projekt noch nicht gerettet.

Ein längerer Prompt hätte die frühe Fassung vielleicht etwas verbessert. Die zuverlässigere Lösung für exakte Inhalte war, dem Modell nur passende Aufgaben zu geben und Code sowie Website anschließend selbst zu kontrollieren. Das Beispiel zeigt aber ebenso deutlich: Auch ein technisch sauber korrigiertes Video darf am Ende noch durchfallen, wenn der Gesamteindruck nicht stimmt.