Eine Bereichsleiterin beschreibt in Rovo Studio in drei Sätzen ein Dashboard: Es soll inaktive User mit offenen Jira-Filtern und Dashboards abgleichen. Wenige Minuten später läuft ein Prototyp. Ohne Forge CLI, ohne npm install, ohne eine einzige von Hand geschriebene Codezeile.
Dieses Effizienzversprechen hat sich seit dem Start des App Builders in Rovo Studio mehrfach weiterentwickelt: Inzwischen lassen sich Screenshots hochladen, um Anforderungen an die Oberfläche zu zeigen. Ein laufender Build lässt sich unterbrechen und in eine andere Richtung lenken. Und eine Browser-Benachrichtigung meldet, sobald die App fertig ist.
Entsteht aus einem Prompt also etwas, das läuft? Ja! Spannender ist die Anschlussfrage: Wie weit trägt dieses “läuft”, und was bedeutet das für die Arbeit von Forge-Entwicklungsteams?
Wo der Prompt-Ansatz überzeugt
Rovo Studio spielt seine Stärken bei Apps aus, die sich gut in natürlicher Sprache beschreiben lassen: ein Formular mit Freigabeschritt, ein Dashboard-Panel, ein zusätzliches Feld in einem bestehenden Workflow. Vor dem eigentlichen Build erstellt Rovo einen Plan, genauer gesagt eine technische Spezifikation, die sich vor der Umsetzung noch anpassen lässt. Dieser Iterationsschritt fängt einige Missverständnisse ab, bevor überhaupt Code existiert.
Bei komplexeren Anforderungen wird das Bild weniger eindeutig, und Atlassian räumt das offen ein. Der App Builder ist im April 2026 als Open Beta gestartet und auch seit dem allgemeinen Rollout von Rovo Studio im Mai noch als Beta gekennzeichnet; Atlassian sammelt aktiv Feedback zu den Bereichen, in denen er noch Schwierigkeiten hat. Ein Beispiel: Eine der häufigsten Rückmeldungen aus der Beta lautete, dass die generierte Vorschau zwar nah dran ist, es aber schwerfällt, Rovo im Detail zu erklären, was sich ändern soll. Atlassian hat darauf reagiert und Annotationen in der Vorschau eingeführt. Damit klicken Sie direkt auf Elemente in der Vorschau und kommentieren gezielt einzelne Stellen, statt Änderungen in Worten zu beschreiben. Das zeigt zweierlei: Die Grenzen sind real und öffentlich dokumentiert, sie verschieben sich aber in kurzen Zyklen.
Wie sich das in der Praxis anfühlt, hat mein Kollege Paul Pasler in einem ausführlichen Erfahrungsbericht in der Atlassian Community dokumentiert. Für einfache Anwendungsfälle, etwa ein Jira-Panel, das die Storys eines Epics nach Status gruppiert, fällt sein Fazit klar positiv aus: in Minuten lauffähig, mit brauchbarer Fehlerbehandlung und ohne eine einzige von Hand geschriebene Codezeile. Sobald er die Anforderungen bewusst komplexer gestaltete, häuften sich kleinere Ungereimtheiten. Er band eine externe API an und erweiterte das Panel um Confluence-Daten, machte aus einer Single-Product-App also eine Cross-Product-App. Dabei fielen ihm unter anderem auf:
- ein veröffentlichter Build, dessen lokaler Type-Check eigentlich fehlgeschlagen war,
- ein generierter Changelog-Eintrag für ein Feature, das im Code gar nicht existierte,
- eine neue Berechtigung für ausgehende Daten, die im Veröffentlichungsdialog nur unauffällig in einer eingeklappten Zeile erschien.
Für sich genommen war nichts davon gravierend. In der Summe zeigt sich aber: Je weiter Sie sich vom Demo-Fall entfernen, desto mehr lohnt sich ein zweiter, kritischer Blick.
Was Studio technisch von reinen No-Code-Buildern unterscheidet: Am Ende entsteht echter Forge-Code und kein proprietäres Format. Darauf baut alles Weitere auf.
Die unterschätzte Lücke: Eine Studio-App ist keine Marketplace-App
An dieser Stelle lohnt ein genauer Blick auf den Weg, den eine in Studio gebaute App tatsächlich nimmt. Nach dem Build veröffentlichen Sie sie direkt aus Studio auf Ihrer eigenen Atlassian-Site, wahlweise in einer Development-, Staging- oder Production-Umgebung. Für interne Tools endet der Weg hier: Die App läuft, ein Team nutzt sie, fertig.
Eine öffentlich gelistete Marketplace-App hat dagegen noch weitere Schritte vor sich. Zunächst müssen Sie den zugehörigen Developer Space selbst im Marketplace veröffentlichen. Das ist ein eigener Prozess: Ein Space-Admin akzeptiert das Atlassian Marketplace Partner Agreement und erhält damit ein öffentliches Partnerprofil sowie Admin-Rechte im Marketplace. Erst danach lässt sich eine App überhaupt öffentlich listen, mit allem, was dazugehört: Sicherheitsanforderungen, ein Review-Prozess und Support-Verpflichtungen gegenüber zahlenden Kunden.
Das Fragezeichen im Titel dieses Beitrags ist also kein rhetorischer Kniff. Der Prompt bringt ein Team recht zuverlässig zu einer App-Grundlage auf der eigenen Site. Der Weg zu einer Marketplace-App, die andere Organisationen installieren und der sie vertrauen, ist dagegen ein bewusster, mehrstufiger Prozess, unabhängig davon, wie die App ursprünglich entstanden ist.
Governance ist die eigentliche Entwicklungsarbeit
Ein Muster aus der Developer-Community zeigt deutlich, wohin sich die Aufgabe verlagert, sobald KI-Generierung fester Teil des Workflows wird. In einem Forge-Projekt, das Analysen in natürlicher Sprache auf Forge-SQL-Daten anbietet, erzeugt Rovo aus Fragen der User zuverlässig SQL-Abfragen.
Das eigentliche Entwicklungsproblem beginnt danach: Wie stellen Sie sicher, dass eine von einem Sprachmodell erzeugte Abfrage nur lesend auf Daten zugreift, nur die vorgesehene Tabelle anspricht, keine versteckten Joins einschmuggelt und die zeilenbasierten Berechtigungen des anfragenden Users respektiert? Die Lösung war ein fest kodiertes, serverseitig durchgesetztes Regelwerk, das die generierte Abfrage validiert, bevor sie überhaupt ausgeführt wird. Mit anderen Worten: Handarbeit des Entwicklungsteams.
Im Kleinen zeigt sich hier die Rolle von Entwicklerinnen und Entwicklern in naher Zukunft: weniger “Wie schreibe ich diese Funktion?”, mehr “Welche Leitplanken brauche ich um das Generierte herum, damit es sicher, nachvollziehbar und berechtigungskonform bleibt?” Diese Leitplanken entwerfen sich nicht von selbst, und ein Prompt-Builder liefert sie nicht mit der App aus.
Was aus der Rolle von Entwicklungsteams wird
Damit gewinnen drei Fähigkeiten an Bedeutung:
Spezifikationen lesen und hinterfragen, bevor der Build überhaupt beginnt. Der Plan, den Rovo vor dem Build zeigt, ist der günstigste Zeitpunkt, um eine falsche Annahme zu korrigieren.
Die Architekturentscheidungen treffen, die ein Prompt nicht trifft. Welche Berechtigungen braucht eine App wirklich? Ist asApp() oder asUser() die richtige Wahl? Gefährdet eine Integration mit Datenabfluss nach außen den Status “Runs on Atlassian”?
Die Grenze zwischen “läuft” und “bereit für zahlende Kunden” erkennen. Das Entwicklungsteam muss wissen, wann eine in Studio generierte App diese Grenze überschreitet und zu einem regulären Forge-Projekt mit CI-Pipeline, Tests und Review-Prozess werden muss. Wer diesen technischen Weg konkret gehen möchte, findet eine ausführliche Checkliste in unserem Beitrag Atlassian Forge: Apps vom AI-Prototyp zur Veröffentlichung bringen.
Fazit: Der Prompt ersetzt den Einstieg, nicht die Verantwortung
Rovo Studio verlagert die Fähigkeit, eine Forge-App zu starten, weg von Forge-erfahrenen Entwicklungsteams hin zu allen, die eine Idee klar formulieren können. Die Verantwortung für das, was am Ende live geht, verlagert sich dagegen nicht: Governance, Berechtigungen, Datenschutz und, wenn das Ziel ein öffentliches Marketplace-Listing ist, ein bewusster, separater Veröffentlichungsprozess. Der Prompt ist ein sehr effizienter Einstieg, macht das Entwicklungsteam aber keineswegs überflüssig.
Möchte Ihr Team Rovo Studio produktiv einsetzen und dabei sicherstellen, dass generierte Apps Ihre eigenen Sicherheits- und Qualitätsstandards erfüllen? Unsere Forge-Developer-Trainings vermitteln genau das Handwerk, das zwischen Prototyp und Produktion entscheidet. Und wenn Sie Ihre App lieber mit einem Partner umsetzen möchten, unterstützt Sie unser Atlassian-Entwicklungsteam gerne.
