KI-App-Builder haben still und leise die erste Frage verändert, die sich jedes App-Entwicklungsteam stellt: “Können wir das überhaupt bauen?” Heute, mit Tools wie Rovo Studios App Builder oder den No-Code-App-Erstellern auf dem Marketplace, lautet die ehrliche Antwort meist: “Ja, und zwar schneller als gedacht.” Sie beschreiben ein Jira-Panel oder ein Confluence-Makro in natürlicher Sprache, und wenige Minuten später läuft es in einer echten Instanz.
Das ist wirklich beeindruckend. Es verschiebt aber auch den schwierigen Teil an eine neue Stelle. Die interessante Frage lautet nicht mehr “Kann ich das bauen?”, sondern “Wie bringe ich diesen Prototypen ohne böse Überraschungen in die Produktion?”
Nachdem auf diese Weise eine echte produktübergreifende App gebaut und so weit wie möglich in einen produktionsreifen Zustand gebracht wurde, geht es in diesem Artikel um den Teil der Reise, den Demos selten zeigen.
Die Lücke zwischen “läuft” und “reif für die Produktion”
Ein KI-Builder optimiert brillant auf ein Ziel hin: Er gibt Ihnen möglichst schnell etwas an die Hand, das vor Ihren Augen funktioniert. Das Ergebnis wirkt fertig. Die Falle besteht darin, dass “fertig wirkend” etwas anderes ist als “produktionsreif” – und die Lücke ist gerade deshalb schwerer zu erkennen, weil der Prototyp so poliert wirkt.
Die folgenden fünf Punkte stellen keine grundsätzliche Kritik an diesen Tools dar. Es handelt sich schlicht um die Checkliste, die ein Forge-Entwicklungsteam aus Gewohnheit durchgeht – im Gegensatz zu einem KI-Builder.
1. Vertrauen Sie den Logs, nicht der Aussage des Tools
Die nützlichste Gewohnheit beim Live-Schalten einer KI-gebauten App: Behandeln Sie Aussagen wie “Ihre App wurde veröffentlicht” und “Bug behoben” als Behauptungen, die überprüft werden müssen – nicht als Fakten. KI-Builder kennen nicht immer den tatsächlichen Deployment-Status Ihrer App und melden mitunter einen Erfolg, der so nicht eingetreten ist.
Die verlässliche Quelle ist die Atlassian Developer Console mit der Deployment-Historie, den Runtime-Logs und den API-Metriken. Wenn sich etwas nicht wie erwartet verhält, zeigen die Logs den tatsächlichen HTTP-Status und Fehler. Das ist weitaus zuverlässiger als jede Zusammenfassung des Tools. Mehr als einmal haben die Logs sowohl das Tool als auch durchaus selbstbewusste eigene Vermutungen korrigiert.
2. Lesen Sie den generierten Code, bevor Sie ihn ausliefern
Der Export aus einem KI-Builder ist echter Forge-Code und kommt oft mit einer überraschend guten Grundausstattung: Linting, Tests, sogar ein Security-Scan. Werfen Sie dennoch vor dem Produktiveinsatz einen gründlichen Blick auf den Code, denn die Dinge, die später Schmerzen verursachen, sind leicht zu übersehen:
Mock-Daten im Produktions-Bundle: Preview-Daten werden mitunter direkt in das Frontend einkompiliert und über eine fragile Heuristik angezeigt. Schlägt diese Heuristik fehl, kann ein echter Nutzer Fake-Daten zu sehen bekommen. Stellen Sie sicher, dass Beispieldaten nicht in die Produktion gelangen können.
Fehlende Pagination: Eine Liste, die “die ersten 100” abruft, ohne die nächste Seite folgen zu lassen, schneidet bei größeren Datenmengen stillschweigend Daten ab.
Nicht deklarierte oder nicht passende Abhängigkeiten: Code kann sich auf ein Paket verlassen, das nur zufällig auflösbar ist. Sobald Sie zu einem strikteren Setup wechseln (pnpm, CI, eine saubere Neuinstallation), bricht der Build. Stellen Sie sicher, dass jede Abhängigkeit tatsächlich deklariert ist.
Ein schneller lokaler tsc-Lauf bzw. Build sowie ein Durchlauf der projekteigenen Checks fördern diese Probleme in der Regel innerhalb weniger Minuten zutage.
3. Behandeln Sie Berechtigungen und Versionen als echte Entscheidungen
Nun kommt ein Punkt, an dem sich das Innehalten besonders lohnt. Ein zusätzlicher externer API-Aufruf oder ein zweites Produkt bedeuten neue Berechtigungen – und in Forge erfordert ein neuer Scope oder eine neue Egress-URL eine Major-Version mit Einverständnis des Kunden.
KI-Builder können solche Änderungen unbemerkt einführen: Eine neue Berechtigung, die der App erlaubt, Daten an eine Drittanbieter-Domain zu senden, kann sich über eine einzige Zeile im Publish-Dialog einschleichen. Halten Sie an dieser Stelle inne und lesen Sie tatsächlich, was Sie genehmigen – besonders alles, was Daten nach außerhalb der Atlassian-Infrastruktur versendet. Externer Datenabfluss hat Konsequenzen für das Qualitätssiegel “Runs on Atlassian” und für die Data Residency, was für Enterprise-Kunden erheblich ins Gewicht fällt.
Bei produktübergreifenden Apps kommt eine weitere Feinheit hinzu: Die App muss in beiden Produkten installiert sein, und Sie müssen die richtige API mit einem Scope aufrufen, der tatsächlich zum Endpunkt passt. asApp() korrekt von asUser() zu unterscheiden und mit dem passenden Scope zu kombinieren, ist genau die Art von Detail, die aus einem verwirrenden 401-Fehler ein funktionierendes Feature macht.
4. Bringen Sie Ihre “Source of Truth” in Ordnung
Der Code-Download aus einem Builder ist in der Regel eine Einbahnstraße: Sobald Sie ihn lokal ziehen und mit der Forge CLI weiterarbeiten, gibt es keinen sauberen Weg zurück in den Builder. Das ist grundsätzlich in Ordnung, bedeutet aber, dass der Download ein Cut-over-Punkt ist. Legen Sie sich auf eine einzige “Source of Truth” fest (Ihr Git-Repository) und arbeiten Sie nicht parallel im Builder weiter, sonst überschreiben sich beide Stände gegenseitig.
Von hier an handelt es sich um ein ganz normales Forge-Projekt: Richten Sie eine echte CI-Pipeline ein, die den vollständigen Satz an Checks durchläuft (Manifest-Validierung, forge lint, Type-Check, Tests, Security-Scan), speichern Sie Secrets ordnungsgemäß über verschlüsselte Forge-Variablen statt sie hart zu codieren, und legen Sie die Distribution der App bewusst fest, damit tatsächlich die richtigen Personen sie nutzen können.
5. Deployen Sie mit Bedacht
Zum Schluss folgt der eigentliche Schritt in die Produktion: Nutzen Sie echte Forge-Umgebungen und deployen Sie explizit in die Produktion, planen Sie den Consent-Schritt ein, den eine Major-Version bei Kunden-Installationen auslöst, und ersetzen Sie alle Platzhalter-Endpunkte durch die echten Dienste samt ihrer Rate Limits. Nichts davon ist schwierig, sobald man weiß, dass es existiert. Das Risiko liegt darin, es nicht zu wissen.
Die Lücke zwischen Prototyp und Produktion ist der Ort, an dem sich Expertise auszahlt
KI-Builder sind eine bemerkenswerte Einstiegshilfe. Sie bringen erstaunlich schnell funktionierende Apps hervor, und das verändert tatsächlich, wer überhaupt anfangen kann, mit Forge zu bauen. Das Handwerk verlagert sich nun auf die letzte Etappe: zu lesen, was generiert wurde, zu verstehen, was der Code tatsächlich tut, und ihn so zu härten, dass Sie ihm echte Daten und echte Nutzer anvertrauen würden.
Das ist auch sehr gut erlernbar. Wenn Ihr Team mit diesen Tools beginnt, auf Forge zu bauen, und einen Prototypen sicher bis in die Produktion bringen möchte, ist das genau das, was unsere Forge Developer Trainings abdecken. Und wenn Sie es lieber für sich entwickeln und härten lassen möchten, steht Ihnen unser Atlassian-Entwicklungsteam gerne zur Seite.