Schluss mit dem perfekten Prompt: Zeigen Sie Loom, was sich ändern soll

Das Problem ist sofort zu sehen. Im Prototyp steht die Schaltfläche unter dem Formular, in der Anwendung daneben, und auf dem Smartphone schiebt die Fehlermeldung beides aus dem sichtbaren Bereich. Das einem KI-Programmieragenten eindeutig zu beschreiben, kann länger dauern, als es einem anderen Menschen zu zeigen.

Am 22. Oktober 2026 stellte Atlassian mehrere Neuerungen für Loom vor, darunter Record for agent: einen Aufnahmemodus, der aus einem kommentierten Bildschirmrundgang Anweisungen für einen KI-Agenten erstellt. Loom, das Werkzeug für zeitversetzte Videos, mit dem Kollegen Arbeitsabläufe zeigen, überträgt diese Gewohnheit auf Software, die anschließend eine Aufgabe ausführen kann. Laut Supportdokumentation ist die Funktion als offene Beta in den Tarifen Business + AI und Enterprise verfügbar; Aufnahmen sind auf fünf Minuten begrenzt. Ankündigung; aktuelle Voraussetzungen.

Interessant ist daran weniger, dass ein Agent ein Video erhalten kann. Der vertraute Aufnahmeablauf erzeugt nun einen Aufgabenentwurf, den Sie prüfen, bearbeiten und an einen Agenten übergeben können. Damit wird die Qualität der Übergabe zur praktischen Frage, statt einen Wettbewerb um den längsten Prompt zu führen.

Offizielles Loom-Logo zur Kennzeichnung des besprochenen Produkts. Es handelt sich um ein Markenzeichen, nicht um einen Screenshot von Record for agent. Logo: Loom / Atlassian; Richtlinie zur Markennutzung.

Eine Aufnahme vermittelt, was in einer Beschreibung fehlt

Ein brauchbarer Fehlerbericht braucht mehr als den Satz „Das Formular funktioniert nicht“. Er braucht den Ausgangszustand, die auslösende Aktion, das erwartete Ergebnis und das tatsächlich beobachtete Verhalten. Sind diese Informationen auf einzelne Screenshots, kopierte URLs und Chatnachrichten verteilt, muss jemand ihre Zusammenhänge rekonstruieren, bevor die Reparatur beginnt.

Looms dokumentierter Ablauf verbindet gesprochene Anweisungen mit Schlüsselbildern der Bildschirmaufnahme, Interaktionsereignissen und aufgerufenen Links. Die Chrome-Erweiterung kann außerdem Konsolenmeldungen sowie Metadaten von Netzwerkanfragen und -antworten erfassen. Die Desktopversion bietet Auswahl- und Zeichenwerkzeuge, um auf einen relevanten Bildschirmbereich hinzuweisen. Das sind Eingaben für den erstellten Aufgabenentwurf, keine Belege dafür, dass eine vorgeschlagene Korrektur funktioniert. Einzelheiten zur Erfassung.

Aus unserer Sicht verschiebt sich damit die nützlichste Kommunikationseinheit. Ein Screenshot zeigt einen Zustand, ein Satz beschreibt eine Absicht, und ein kurzer Rundgang kann erklären, wie aus dem einen Zustand ein anderer werden soll. Der erzeugte Aufgabenentwurf verbindet diese Erklärung mit einer ausführbaren Aufgabe.

Man kann die Aufnahme als Paket mit Kontext verstehen. Darin sollte alles liegen, was für die gewünschte Änderung nötig ist, und möglichst wenig darüber hinaus. Eine Grenze von fünf Minuten kann diese Disziplin fördern: ein Problem zeigen, seine Folgen erklären und ein klares Ziel benennen.

Eigene Darstellung der Übergabe. Die Prüfung des Aufgabenentwurfs ist ein eigener Schritt vor der Ausführung durch den Agenten.

Designfeedback wird verständlicher, wenn das gewünschte Verhalten sichtbar ist

Nehmen wir ein Team, das eine Bestellseite überarbeitet. In einem beispielhaften Rundgang könnte die Designerin den freigegebenen Entwurf öffnen, die aktuelle Anwendung zeigen und auf drei Unterschiede hinweisen: Bei schmaler Ansicht verschwindet die Lieferoption, der Gesamtbetrag aktualisiert sich zu spät, und die Bestätigungsmeldung setzt den falschen Schwerpunkt. Der Wert liegt im Zusammenhang zwischen beiden Ansichten, nicht nur in deren Aussehen.

Wer den erzeugten Prompt prüft, sollte jede Beobachtung in ein überprüfbares Verhalten übersetzen. „Das hier verschieben“ ist mehrdeutig, sobald der Agent nicht mehr denselben Moment betrachtet. „Den Gesamtbetrag nach einer Änderung der Lieferoption auch bei schmaler Ansicht sichtbar halten“ nennt ein Ergebnis, das der Umsetzende kontrollieren kann.

Besonders hilfreich ist das, wenn eine Änderung eine Designdatei und eine laufende Seite betrifft. Looms eigenes Supportbeispiel beschreibt den Wechsel zwischen Figma und einer Website, während eine Änderung der Oberfläche erklärt wird. Die Funktion kann die sichtbare Referenz festhalten; welche Referenz verbindlich ist, entscheidet weiterhin das Team. Auch ein ausgearbeiteter Prototyp kann Lade-, Fehler- und Berechtigungszustände auslassen. Unterstützter Ablauf.

Ergänzen Sie deshalb einen Satz dazu, was unbedingt erhalten bleiben muss. Im Beispiel der Bestellseite könnte das sein, dass der Gesamtbetrag zur gewählten Lieferart passt oder der Tastaturfokus auf dem geänderten Feld bleibt. Solche Bedingungen fehlen häufig in visuellen Entwürfen, sind aber wichtiger als die Position einer Rahmenlinie.

Dasselbe Vorgehen eignet sich für Produkttexte. Zeigen Sie den Satz in seinem tatsächlichen Umfeld, erklären Sie, wer ihn liest, und benennen Sie die Entscheidung, bei der er helfen soll. Eine Aufnahme der ersten Nutzungsschritte kann einen verwirrenden Übergang zeigen, den ein isolierter Textausschnitt verbergen würde.

Fehlerberichte brauchen einen reproduzierbaren Anfang und ein beobachtbares Ende

Ein zweites nützliches Szenario ist ein wiederkehrendes Supportproblem. Angenommen, ein Kunde kann am Desktop ein Dokument hochladen, sieht auf einem kleinen Bildschirm aber eine leere Fortschrittsanzeige. Eine kurze Aufnahme könnte Dateityp, ausgewählte Aktion, Übergang und den Punkt zeigen, an dem die Rückmeldung verschwindet.

Die daraus erzeugte Aufgabe braucht trotzdem eine Definition von „erledigt“. „Upload reparieren“ erklärt einem Agenten nicht, ob eine Datei abgelehnt wurde, eine Netzwerkantwort fehlt oder die Oberfläche ein erfolgreiches Ergebnis nicht angezeigt hat. Ein besserer Aufgabenentwurf trennt die beobachtete Auswirkung von der vermuteten Ursache.

Wir würden den ersten Auftrag eng fassen: die fehlende Rückmeldung reproduzieren, die verantwortliche Schicht identifizieren und eine Änderung mit einer Regressionsprüfung vorschlagen. Entdeckt der Agent anschließend einen Serverfehler, kann dieser Befund die Untersuchung begründet erweitern. Aus einer Beschwerde über das Layout sollte aber nicht unbemerkt eine umfassende Neufassung des Uploadsystems werden.

Das hat einen praktischen Vorteil für Menschen, die keine Protokolle lesen möchten oder können. Sie zeigen den fehlerhaften Ablauf, ohne ihn vorher diagnostizieren zu müssen. Entwickler oder Agent können mit dem erfassten Kontext nach der Ursache suchen, während die ursprüngliche Beobachtung für den Vergleich nach der Korrektur erhalten bleibt.

Die Aufnahme ersetzt dadurch keinen Testfall. Beide erfüllen unterschiedliche Aufgaben. Die Aufnahme bewahrt, was jemand erlebt hat; der Test beschreibt das Verhalten, das die Software dauerhaft einhalten muss. Ein erfolgreicher Ablauf überführt die erste Information in eine passende Form der zweiten.

Einen Prompt zu kopieren und eine Jira-Aufgabe anzulegen sind unterschiedliche Einstiege

Looms offene Beta lässt sich über die Chrome-Erweiterung oder die Desktop-App ab Version 2.0 nutzen. Die Dokumentation unterscheidet außerdem den grundlegenden Promptablauf vom Anlegen eines Jira-Arbeitselements. Dafür sind ein von Atlassian verwaltetes Konto und ein aktives Jira-Abonnement erforderlich. Diese Unterscheidung ist für ein kleines Team wichtig, das die Übergabe ausprobieren möchte, ohne sein Projektmanagement neu zu organisieren. Verfügbarkeit und Einrichtung.

Der einfachste Versuch ist eine einzelne Aufgabe mit geringen Auswirkungen in einem vertrauten Projekt:

1. Öffnen Sie den relevanten Entwurf, eine öffentliche Testseite oder eine Entwicklungsumgebung und bereiten Sie einen verständlichen Ausgangszustand vor.
2. Wählen Sie im unterstützten Loom-Rekorder Record for agent und beschreiben Sie eine Änderung, während Sie die zugehörigen Interaktionen zeigen.
3. Beenden Sie die Aufnahme vor der Fünf-Minuten-Grenze und lesen Sie den erzeugten Aktionsplan vollständig.
4. Präzisieren Sie mehrdeutige Verweise, entfernen Sie sachfremdes Material und ergänzen Sie ein konkretes Abnahmekriterium.
5. Kopieren Sie den Prompt als Markdown in den gewählten Agenten oder verwenden Sie den für Ihr Konto unterstützten Übergabe- beziehungsweise Jira-Ablauf.
6. Prüfen Sie das Ergebnis des Agenten anhand des ursprünglichen Szenarios, bevor Sie seine Änderung akzeptieren.

So bleibt der erste Versuch nachvollziehbar. Zugleich lässt sich damit prüfen, ob die Funktion hilft: Vergleichen Sie die Zeit für einen klaren Auftrag und die Zahl der Rückfragen, die daraus entstehen.

Ein schnell fertig werdender Agent allein genügt nicht. Kann ein Teammitglied nicht erklären, was geändert wurde und warum es die ursprüngliche Beobachtung behebt, braucht die Übergabe weitere Arbeit. Der wichtigste Gewinn ist weniger Rekonstruktionsaufwand, nicht weniger Prüfung.

Mehr Kontext verlangt eine bewusstere Entscheidung über die Weitergabe

Der zusätzliche technische Kontext ist wertvoll, weil der Bildschirm allein einen Vorfall möglicherweise nicht erklärt. Eine fehlgeschlagene Anfrage, eine unerwartete Weiterleitung oder ein Konsolenfehler können auf eine andere Ursache hinweisen, als das sichtbare Symptom vermuten lässt. Genau diese Details können aber Informationen enthalten, die Sie nicht an ein weiteres Werkzeug übermitteln möchten.

Nutzen Sie vor der Aufnahme eine passende Testseite und halten Sie den Aufgabenbereich sichtbar. Prüfen Sie den erzeugten Entwurf anschließend auf kontospezifische URLs, Kundenkennungen und unnötige Protokollinhalte. Die dokumentierte Liste erfasster Daten macht diese Kontrolle konkreter, als eine Aufnahme wie einen gewöhnlichen Bildanhang zu behandeln.

Es geht darum, die zur Lösung nötigen Informationen zu erhalten. Eine Anfragekennung kann hilfreich sein, wenn ein Kollege damit eine autorisierte Serverspur findet. Eine vollständige Liste sachfremder URLs oder eine private Benachrichtigung, die zufällig während der Aufnahme erschien, trägt dagegen wenig zu einer Oberflächenaufgabe bei.

Das sind redaktionelle Prüffragen, keine zusätzlichen Produktberechtigungen und kein Versprechen, dass jedes erfasste Detail in jeder erzeugten Aufgabe erscheint. Sie helfen einem Team zu entscheiden, was in den tatsächlich versendeten Auftrag gehört.

Eine sinnvolle Prüfung klärt, was der Agent ändern darf, welche Informationen er erhält und woran sein Ergebnis gemessen wird.

Die erste nützliche Messgröße ist, wie viel der Erklärung erhalten bleibt

Mindestens auf drei Arten kann diese Funktion Arbeit sparen. Eine Designerin vermittelt eine visuelle Abweichung, ohne sie aufwendig zu beschreiben. Ein Supportmitarbeiter hält einen Ablauf fest, solange er noch präsent ist. Ein Entwickler übergibt einem Agenten eine Aufgabe mit einer klareren Referenz und einem präziseren erwarteten Ergebnis.

Jeder Einsatz hat einen eigenen möglichen Schwachpunkt. Designfeedback kann Verhalten außerhalb des Idealfalls auslassen. Ein Supportdurchlauf kann von einem Kontozustand abhängen, den niemand sonst reproduzieren kann. Die Aufnahme eines Entwicklers kann so viele Details enthalten, dass der eigentliche Auftrag schwer erkennbar wird.

Wählen Sie für eine erste Bewertung mehrere vertraute Aufgaben und lassen Sie Agent und Repository unverändert. Halten Sie fest, wie viel Nachbearbeitung der erzeugte Entwurf braucht, wie oft Rückfragen entstehen und ob die endgültige Änderung die genannte Bedingung erfüllt. Diese Messungen sagen mehr über die Qualität der Kommunikation aus als eine einzelne Demonstration eines bewegten Mauszeigers.

Unterscheiden Sie außerdem die Qualität des Ergebnisses vom Schwierigkeitsgrad der Aufgabe. Eine einfache Textänderung kann mit fast jedem Auftrag gelingen. Aussagekräftiger ist ein kleiner Auftrag, bei dem Kontext zählt: ein Ladezustand, ein Layout auf schmalen Bildschirmen oder ein Übergang zwischen zwei Werkzeugen. Die Aufgabe sollte trotzdem umkehrbar und für ihren Verantwortlichen leicht zu prüfen bleiben.

Loom hat gute Voraussetzungen, diese Gewohnheit vertraut zu machen, weil Menschen Aufnahmen bereits nutzen, um anderen Menschen Arbeit zu erklären. Die Chance besteht darin, diese Verständlichkeit in einen Agentenablauf zu übertragen. Das Risiko liegt in der Annahme, eine reichhaltigere Eingabe mache ein klares Ziel für den Agenten überflüssig.

Der bessere Aufgabenentwurf bleibt auch für einen anderen Menschen verständlich

Record for agent setzt auf einen plausiblen Ansatz: Etwas zu zeigen kann effizienter sein, als jedes Pixel zu beschreiben. Das stärkste Ergebnis wäre eine Aufgabe, die sowohl der Agent als auch ein Teamkollege leichter versteht und bei der die ursprüngliche Beobachtung mit der akzeptierten Änderung sichtbar verbunden bleibt.

Stellen Sie vor der nächsten Aufnahme eine Frage: Könnte jemand, der bei der Aufnahme nicht dabei war, trotzdem erklären, wie ein erfolgreiches Ergebnis aussieht? Wenn ja, haben Sie einen brauchbaren Aufgabenentwurf. Wenn nicht, gehört die nächste Verbesserung zunächst in die Anweisungen und erst danach in den Code.

Quellen

• Atlassian: Showing what you mean in the age of AI, 22. Oktober 2026.
• Loom: Record for AI agents, Dokumentation zu Verfügbarkeit, Erfassung und Ablauf, geprüft am 26. Oktober 2026.

Quelle und geprüfte Notizen zusammenhalten

Für eigene, zur Nutzung freigegebene Aufnahmen bietet Telli.sh einen separaten Ort, um das Ausgangsmaterial zusammen mit geprüften Notizen aufzubewahren. Mit einer Audionotiz beginnen.