Wie ich einen Demo-Generator mit Duo Agent Platform baute

Früher saß ich Tage an einer Demo: Screenshots, Erzähltext, vieles mehr in einem externen Werkzeug zusammenbauen, vortragen, später Feedback einsammeln. Und jedes Mal, wenn sich die Funktionen änderten, ging es von vorn los. Vor einigen Monaten habe ich den größten Teil davon an einen Agenten in der GitLab Duo Agent Platform übergeben.

Die GitLab Duo Agent Platform ist auf intelligente Orchestrierung ausgelegt und führt agentische Workflows über den gesamten Software-Lebenszyklus aus. Sie ist aber flexibel genug, um auch wiederkehrende Arbeit jenseits der Entwicklung zu übernehmen. Ich habe sie stattdessen auf die Demo-Erstellung angesetzt, und das lief so gut, dass sich derselbe Versuch mit jeder Aufgabe lohnt, die gerade auf dem eigenen Schreibtisch liegt. Für den Einstieg habe ich dieses praxisnahe Tutorial geschrieben. Und noch etwas: Man muss dafür nicht programmieren können. Auch aus nicht-technischen Rollen kommt zunehmend Interesse daran, agentische Workflows wie diesen mit GitLab zu betreiben. Wer sich darin wiedererkennt, kann direkt mitmachen.

In diesem Artikel:

• Warum Click-Through-Demos so wirksam sind
• Die Entwicklung: von VMs über externe Demo-Tools zu Agenten
• Die Phasen einer Demo-Erstellung
• So funktioniert der Demo-Generator
• Demos liegen jetzt im Code
• Was die GitLab Duo Agent Platform möglich gemacht hat
• Den ersten Agenten bauen

🎯 Die GitLab Duo Agent Platform heute ausprobieren!

Warum Click-Through-Demos so wirksam sind

Wer eine Funktion in Aktion sieht, versteht sie besser als beim Lesen. Live-Demos sind allerdings heikel: Sie brauchen Produktzugang und genug Routine, um sich sicher durch die Oberfläche zu bewegen.

Eine Click-Through-Demo löst das. Man klickt die Schritte selbst durch, geführt von einem kurzen Erzähltext bei jedem Schritt. Anders als bei einem Video bestimmt man das Tempo selbst. Und anders als ein echter Zugang, für den eine reale Umgebung nötig ist, ist sie nur ein Link: frei teilbar, wiederverwendbar und jedes Mal gleich.

Beispiele finden sich im GitLab Demo Hub.

Eine Click-Through-Demo führt Schritt für Schritt durch einen echten Produktablauf

Die Entwicklung: von VMs über externe Demo-Tools zu Agenten

So sahen Demos nicht immer aus. Über meine Berufsjahre hinweg ist daraus diese Entwicklung geworden:

• VMs (2000er): virtuelle Maschinen mit vorinstalliertem Produkt und Demo-Inhalten, später zentral auf ESX-Servern.
• Externe Werkzeuge (SaaS-Ära): Wechsel auf Anbieterplattformen mit eingebauter Analytik, die aber weiterhin von Hand gebaut werden mussten und an die Infrastruktur des Anbieters gebunden blieben.
• Agentisch (jetzt): Agenten erzeugen Demos aus einem Prompt, ausgeliefert aus demselben Projekt, in dem sie entstehen, ohne Abhängigkeit von einem Anbieter.

Jede Schicht machte Demos zugänglicher. Die agentische Schicht macht sie tragfähig.

Die Phasen einer Demo-Erstellung

Zu einer Click-Through-Demo gehören diese Phasen:

1. Die Funktion verstehen: Dokumentation lesen, Issues und Slack durchgehen, sich mit Product Managern und Engineering abstimmen, um wirklich zu erfassen, was gezeigt wird, und vor allem das Problem, das es löst, samt Wirkung und Nutzen für die Kundschaft.
2. Die Geschichte bauen: ein realistisches Szenario entwickeln, das die Wirkung auf die Kundschaft zeigt, also welches Problem es im Alltag löst und warum das zählt.
3. Die Umgebung aufsetzen: ein Projekt anlegen und realistische Demo-Daten erzeugen, die die Geschichte tragen, etwa eingestreute Schwachstellen für ein Security-Dashboard oder Daten für aussagekräftige Diagramme.
4. Die Inhalte aufnehmen: Screenshots machen oder Clips des tatsächlichen Ablaufs aufzeichnen.
5. Den Erzähltext schreiben: Inhalte formulieren, die durch jeden Schritt führen, aufbauend auf der Geschichte und dem Kundenszenario aus Schritt 2.
6. Die Demo bauen: in einem externen Werkzeug alles zu einem klickbaren Durchlauf zusammenfügen, Verweise auf verwandte Materialien ergänzen und für jeden Schritt den Call to Action festlegen.
7. Mit Beteiligten prüfen: einen Entwurf teilen, Feedback sammeln, nachschärfen.
8. Änderungen einarbeiten: Erzähltext aktualisieren, Schritte umsortieren, bei Bedarf neu erzeugen.
9. Veröffentlichen: nach GitLab Docs, in den Demo Hub und an alle weiteren Zielorte ausliefern.
10. Ankündigen: intern über Slack teilen, in Blogbeiträge einbetten, in sozialen Netzwerken posten.

Zusammengenommen können diese Schritte Tage dauern, und sobald sich am Produkt etwas ändert, geht es ab Schritt 3 von vorn los.

Bei fast allen diesen Schritten kann ein Agent helfen: Dokumentation lesen, Issues durchsuchen, Kontext aus Slack ziehen, Demo-Daten im Projekt anlegen und das Wesentliche herausarbeiten. Den Menschen, der entscheidet, was entstehen soll, und die Ergebnisse vor dem Ausliefern prüft, ersetzt er damit nicht. Die Grundlagenarbeit nimmt er ihm aber zu einem bemerkenswerten Teil ab.

In meinem Click-Through Demo Generator habe ich mich auf die Schritte 1, 2, 5, 6 und 9 konzentriert: die mit klaren Eingaben, vorhersehbaren Ergebnissen und bislang vollständig manueller Ausführung. Die übrigen Schritte lassen sich ebenfalls von spezialisierten Agenten übernehmen.

So funktioniert der Demo-Generator

Der Ablauf sieht so aus: Screenshots in einen Ordner im Projekt legen, optional mit einer context.md als Hintergrund zur Funktion, dann den Workflow aus einem Issue-Kommentar heraus starten. Der Agent sortiert und benennt die Screenshots, schreibt den Erzähltext, baut die Demo mit einer eingebauten Markenvorlage und öffnet einen Merge Request. Ist der geprüft und gemergt, geht die Demo automatisch über GitLab Pages online. Soll sich etwas ändern, genügt eine Nachfrage beim Agenten.

Der Issue-Kommentar, der den Click-Through Demo Generator auslöst, und die Antwort des Agenten mit dem Link zum Merge Request

Unter der Haube wird ein Custom Flow ausgelöst. Der Agent ruft ein selbst gebautes Tool auf, das die Demo in eine HTML-Vorlage einbaut, jeden Screenshot mit seinem Erzähltext-Kasten überlagert und den Link zum Merge Request zurück in das Issue kommentiert. Eine Skill gibt dem Schreiben die Richtung, damit der Erzähltext GitLabs Marketing-Botschaften folgt und auf den Nutzen für die Kundschaft zielt statt auf unsere eigenen Funktionen.

Hier der tatsächliche Anweisungstext aus der SKILL.md dieser Skill, den der Agent bei jedem Erzähltext liest und befolgt:

"Great narration sells an outcome, not a UI tour. Someone who clicks through should understand what problem the product solves, why this approach is better, and what they could now do, without reading any docs.

Structure every demo as three acts: Open on the customer's pain, show the product solving it step by step, and close by naming the value they walk away with."

Für Demos in weiteren Sprachen genügt eine Lokalisierungs-Skill im Projekt, von da an wird jede Demo automatisch lokalisiert.

Die Demo-Galerie: hier werden Demos geprüft und bereitgestellt, bevor sie in Produktion gehen

Veröffentlichen mit einer Skill

Auch die Veröffentlichung im Demo Hub, unserem produktiven Demo-Portal, läuft ohne Handarbeit ab. Ist eine Demo fertig, wird sie in der Entwicklungsgalerie als production markiert. Das ist das Signal für den Agenten: Er führt in diesem Projekt eine Skill aus, die in das Demo-Hub-Projekt greift und den Rest übernimmt. Sie schreibt eine kurze Beschreibung, versieht sie mit dem heutigen Datum, markiert sie als neu und öffnet einen Merge Request, der die Demo als Karte ergänzt. Diesen MR zu mergen und die Demo live zu stellen, bleibt eine menschliche Entscheidung.

Demos liegen jetzt im Code

Eine Click-Through-Demo besteht im Kern aus ein paar Dateien: HTML, Screenshots und Konfiguration. Damit gehört sie in ein Repository. Sie steckt nicht länger in einem separaten Werkzeug, das nur wenige bedienen können. Sie liegt in einem GitLab-Projekt und lässt sich deshalb:

• in Merge Requests prüfen
• von Kolleginnen und Kollegen verbessern
• über die Zeit versionieren
• von Agenten aktualisieren, nicht nur von Menschen

Damit wird die Demo zur Sache des Teams und nicht mehr zur Aufgabe einer einzelnen Person. Das macht einen großen Unterschied. Deutlich mehr Kolleginnen und Kollegen können Demos erstellen, prüfen, verbessern und veröffentlichen, ohne besonderes Werkzeugwissen. Wer ein Issue öffnen und einen MR freigeben kann, kann diesen Workflow nutzen.

Selbst ausprobieren?

Das Projekt Click-Through Demo Generator forken und die README für das vollständige Setup lesen. Custom Flows werden beim Forken nicht mitkopiert, deshalb muss der Flow "Generate click-through demo" (dafür ist eine Anmeldung bei GitLab nötig) im geforkten Projekt zusätzlich aktiviert werden. Alles Weitere steht in der README.

Was die GitLab Duo Agent Platform möglich gemacht hat

Ohne die GitLab Duo Agent Platform wäre dieses Projekt deutlich schwieriger geworden.

Die GitLab Duo Agent Platform lieferte mir die fehlende Infrastruktur: einen Custom Flow, der aus einem Issue-Kommentar heraus startet, und ein Container-Image, das ich mit genau der Laufzeit und den Abhängigkeiten definiere, die es braucht. Dazu kommen eingebaute Tools für die direkte Arbeit mit GitLab, etwa das Öffnen von Merge Requests und das Kommentieren von Issues. Im Merge Request prüfe ich die Demo, bevor ich sie merge und der Agent sie im Demo Hub veröffentlicht.

Im Vokabular der Plattform heißt das agentische Automatisierung: Der Custom Flow orchestriert das Verhalten des Agenten, und GitLabs eingebaute Tools lassen ihn mit Issues, Projektdateien, Merge Requests und GitLab Pages arbeiten, ohne separate Integrationen.

Mit Custom Flows lässt sich ein eigener mehrstufiger Workflow festlegen und der Agent um eigene Tools erweitern. Eines davon habe ich selbst gebaut: Es baut Screenshots und Erzähltext in die HTML-Vorlage der Demo ein und läuft als Teil des Flows auf GitLabs Compute.

Alles bleibt in GitLab: die Anfrage, die Prüfung, das Ergebnis, die Auslieferung. Das macht den Ablauf klarer und leichter zu übergeben.

Den ersten Agenten bauen

Einmal weg von meinem eigenen Ablauf und hin zur Frage, was passiert, wenn wiederkehrende Arbeit an einen Agenten mit Zugriff auf die eigenen GitLab-Daten übergeht. Für eine Teamleitung heißt das: weniger Aufwand für die Erstellung von Material, mehr für Prüfen und Entscheiden. Dieselbe Verschiebung zeigt sich überall dort, wo eine wiederholbare, klar umrissene Aufgabe auf GitLab-Kontext aufsetzt.

Klein und einfach anfangen. Der Demo-Generator ist nur ein Beispiel für dieses Muster, für den Anfang braucht es aber weder eigenen Code noch einen Custom Flow. Also mit einem einzelnen Agenten beginnen, ihm eine klare Aufgabe geben und schauen, was er kann, bevor es komplizierter wird.

In diesem kurzen Tutorial entsteht der erste eigene Agent, einer, der bei der Planung der eigenen Arbeit hilft. Kein Zugang zur GitLab Duo Agent Platform? Zum Mitmachen genügt eine kostenlose Testversion. Zwei Aufgaben, mit überschaubarem Aufwand:

Aufgabe 1: einen eigenen Agenten anlegen. In der GitLab-Oberfläche einen eigenen Agenten anlegen und ihn "Daily Planner" nennen. Ihm mitteilen, was Priorität bedeutet, etwa Issues, die Kolleginnen und Kollegen blockieren, alles mit Fälligkeit in dieser Woche, oder "alles mit dem Label customer gilt als höchste Priorität, unabhängig vom Fälligkeitsdatum". Er soll die zugewiesenen Issues und Merge Requests ansehen, diese Regeln anwenden und benennen, was zuerst anzugehen ist, was andere blockiert und was warten kann.

Aufgabe 2: aktivieren und prüfen. Den Agenten im Projekt aktivieren, dann GitLab Duo Agentic Chat öffnen, ihn auswählen und um eine Tagesplanung bitten. Er hat eingebauten Zugriff auf GitLab und zieht die tatsächlich zugewiesenen Issues und MRs selbst. Seinen Plan mit dem vergleichen, was man selbst zusammengestellt hätte, und die Anweisungen des Agenten nachschärfen, bis der Plan wirklich brauchbar ist.

Damit steht der erste eigene Agent, und er macht den Tag schon ein wenig leichter. Ab hier wird es interessant: Was würde man ihm noch übergeben? Welche Entscheidung ist man leid, selbst zu treffen? So wächst aus dem Agenten für einen Zweck die Assistenz, die den ganzen Ablauf trägt.