KI und Coding Agents im Forge-Workflow

KI und Coding Agents im Forge-Workflow

0:00 KI-Werkzeuge schreiben inzwischen brauchbaren Code — in den meisten Umgebungen. Forge ist ein Sonderfall, und zwar ein lehrreicher. Der größte Teil dessen, was im Netz über Forge geschrieben steht, beschreibt eine Fassung der Plattform, die es so nicht mehr gibt. Sprachmodelle lernen aus dem, was häufig geschrieben wurde, nicht aus dem, was aktuell ist. Das Ergebnis ist Code, der plausibel aussieht und beim Ausrollen scheitert.

0:25 Dieses Modul zeigt, wie man trotzdem sinnvoll mit diesen Werkzeugen arbeitet — und woran man den Unterschied erkennt.

KI und Coding Agents im Forge-Workflow

0:32 Dieser letzte Teil des vierten Tages baut auf den beiden vorherigen auf, und das ist kein Zufall. Ohne ein klares Bild von Berechtigungen und ohne Tests ist generierter Code nicht verantwortbar — man könnte ihn gar nicht abnehmen. Mit beidem wird er zu dem, was er sein sollte: ein Vorschlag, den man prüft. Wir sprechen über Anforderungen, über Kontext, über das Review und über Daten, die nicht in einen Auftrag gehören.

Anforderungen vor dem Generieren

0:57 Fangen wir mit dem an, was vor dem ersten Prompt passieren sollte — und meistens nicht passiert. Der Satz, um den es geht, ist einfach: Generierter Code ist nur so brauchbar wie das Kriterium, an dem er gemessen wird. Wer nicht sagen kann, wann etwas fertig ist, kann einen Vorschlag nicht bewerten — er kann ihn nur gut finden oder nicht.

1:18 Deshalb stehen am Anfang drei Angaben: Was soll herauskommen, woran erkennt man es, und was darf sich dabei nicht ändern. Der dritte Punkt ist der, den fast alle weglassen — und der bei Forge der wichtigste ist. Das ist kein Code, sondern ein Auftrag — und trotzdem die wichtigste Folie des Moduls. Oben das Ziel in einem Satz. Darunter die Fertigkriterien, prüfbar formuliert.

1:41 Und unten, wie die Fußzeile betont, die eigentliche Sicherung: Manifest, Scopes und Speicherzugriff bleiben unverändert. Damit haben Sie die drei Stellen geschützt, an denen ein Vorschlag echten Schaden anrichten kann. Ein zusätzlicher Scope, der sich in einen Diff schmuggelt, ist später eine Zustimmungsfrage bei jedem Kunden.

2:01 Vier Gründe, und sie sind alle praktischer Natur. Ein kleiner Vorschlag lässt sich vollständig lesen — und was man nicht liest, kann man nicht abnehmen. Die Änderung bleibt einem Bereich zuzuordnen. Ein Fehlschlag kostet wenig, man verwirft und stellt die Aufgabe neu. Und Tests bleiben aussagekräftig, weil sich wenig gleichzeitig ändert.

2:21 Meine Erfahrung: Der Unterschied zwischen frustrierender und produktiver Arbeit mit diesen Werkzeugen liegt fast vollständig in der Größe der Aufgabe. Der erste Punkt ist der häufigste: Der Auftrag beschreibt die Lösung statt das Ziel — „bau eine Komponente mit einem Select" statt „ich will nach Status filtern". Damit verschenkt man genau die Arbeit, die das Werkzeug gut kann. Der zweite ist der, vor dem ich am meisten warne: Manifest und Scopes stehen nicht auf der Ausschlussliste.

2:50 Und der dritte ist der Grund, warum viele Durchgänge im Chaos enden — mehrere Anforderungen auf einmal, und danach ist nicht mehr zuzuordnen, was wovon kommt.

Forge-Wissen als Kontext bereitstellen

3:00 Kommen wir zu dem Teil, der bei Forge den größten Unterschied macht: dem Kontext, mit dem das Werkzeug arbeitet. Atlassian hat dafür inzwischen ein eigenes Angebot, das Forge AI Development Toolkit. Es besteht aus einem MCP-Server, der aktuelle Dokumentation, Modulkatalog und Manifest-Regeln zugänglich macht, und aus Developer Skills für typische Aufgaben — Gerüstbau, Review, Kostenprüfung, Sicherheitsprüfung, Fehlersuche.

3:26 Beides lässt sich einzeln einbinden oder als Plugin zusammen. Der Nutzen ist weniger Bequemlichkeit als Aktualität: Das Werkzeug bekommt die Doku von heute statt die Blogartikel von vorgestern. Vier Glieder, und das zweite ist der ganze Punkt dieses Kapitels. Ohne dieses Glied geht die Kette direkt vom Auftrag zum Vorschlag — und der Vorschlag speist sich dann aus dem allgemeinen Trainingswissen.

3:50 Mit dem Doku-Zugang dazwischen verändert sich die Qualität deutlich. Beachten Sie aber auch das letzte Glied: Das Review fällt nicht weg. Der Doku-Zugang verschiebt die Fehlerquote, er beseitigt sie nicht — und Architektur- oder Sicherheitsentscheidungen trifft er ohnehin nicht. Das ist die Erklärung, die ich Ihnen schuldig bin. Der größte Teil der Forge-Beispiele im Netz beschreibt die erste Fassung von UI Kit.

4:14 Paketnamen, Einstiegspunkte, Komponenten — alles hat sich geändert, und morgen sehen wir das im Detail. Module und Scopes kommen hinzu und entfallen. Und ein Modell bevorzugt das häufig Geschriebene, nicht das Aktuelle. Deshalb ist der veraltete Vorschlag hier kein Zufall, sondern der Normalfall. Wer das weiß, ist nicht überrascht, sondern vorbereitet.

4:37 Der erste Punkt ist der Ausgangszustand: Der Agent arbeitet ohne Doku-Zugang und erfindet Komponenten, die es nie gab. Der zweite ist tückischer — der Zugang ist eingebunden, wird aber nicht genutzt, weil die Aufgabe ihn nicht verlangt. Und der dritte ist der Satz, den ich in Reviews am häufigsten höre und am wenigsten gelten lasse: Der Vorschlag wird übernommen, weil er kompiliert.

4:59 Bei Forge bedeutet Kompilieren fast nichts — die interessanten Fehler zeigen sich beim Ausrollen oder gar erst im Betrieb.

Generierten Code prüfen

5:07 Damit zum Handwerk des Reviews — und zu einer Prüfliste, die Sie sich ausdrucken dürfen. Geprüft wird gegen die Dokumentation, nicht gegen den Eindruck. Das ist der entscheidende Unterschied zu einem gewöhnlichen Code-Review unter Kollegen: Dort prüfen Sie Logik und Stil und setzen voraus, dass die verwendeten APIs existieren.

5:27 Hier ist genau diese Voraussetzung die Fehlerquelle. Gibt es das Modul? Heißt die Komponente so? Ist der Scope nötig? Und erst danach kommen Diff-Review und Tests. Das Laufverhalten im Tunnel ist übrigens das schwächste Argument von allen. Diese sechs Zeilen sind nach meiner Erfahrung die Abkürzung. Lesen Sie die rechte Spalte einmal durch: Es sind fast durchweg Spuren der alten Fassung — falsches Paket, falscher Einstiegspunkt, alte Komponentennamen, fehlende Angabe für natives Rendern.

5:57 Nur die letzten beiden Zeilen sind anderer Natur und zugleich die gefährlichsten: ein zu breiter Scope und eine Autorisierung, die auf Frontend-Werten beruht. Die Fußzeile sagt es deutlich: Diese sechs Punkte decken die Mehrzahl der Fehler ab. Wer sie abarbeitet, braucht für den Rest deutlich weniger Misstrauen. Der rote Faden ist eine Reihenfolge, die Neugier bremst: Diff lesen, bevor irgendetwas ausgeführt wird.

6:22 Dann jede unbekannte Komponente nachschlagen — und unbekannt heißt hier wirklich unbekannt, nicht „klingt plausibel". Manifest-Änderungen einzeln bewerten, Scopes besonders. Dann Tests. Und erst danach ausrollen und im Produkt prüfen. Wer diese Reihenfolge umdreht und zuerst ausrollt, prüft am Ende nur noch, ob es zufällig funktioniert hat.

6:44 Der erste Punkt ist menschlich: Der Diff wird überflogen, weil im Tunnel nichts rot ist. Der zweite ist der, vor dem die Ausschlussliste schützen sollte — eine Manifest-Änderung rutscht als Nebenwirkung durch. Und der dritte ist der, der am meisten Zeit frisst: Der Vorschlag wird nachgebessert, statt die Aufgabe neu zu stellen.

7:03 Zwei, drei Korrekturrunden später ist mehr Zeit vergangen, als ein sauber formulierter zweiter Anlauf gekostet hätte.

Grenzen im Umgang mit Daten

7:10 Zum Abschluss ein Thema, das weniger technisch ist und im Zweifel teurer: Was gehört überhaupt in einen Auftrag? Was Sie in einen Auftrag schreiben, verlässt Ihren Arbeitsplatz — das ist der ganze Kern. Vorgangsinhalte, Kundennamen, Zugangsdaten, Protokollauszüge mit Personenbezug gehören deshalb nicht hinein. Und das ist keine theoretische Sorge: Genau solche Auszüge sind beim Debuggen das Naheliegendste, was man kopiert.

7:36 Für Beispiele genügen erfundene Daten mit derselben Struktur — so wie wir es in diesem Seminar mit der Falkenmoos GmbH die ganze Woche gemacht haben. Vier Gründe, die alle in dieselbe Richtung zeigen. Ein Scope im Manifest ist eine Zusage an die Administration — die kann kein Werkzeug für Sie geben. Ein Speicherzugriff hat Folgen über die Sitzung hinaus. Verantwortung für eine veröffentlichte App lässt sich nicht delegieren; im Zweifel steht Ihr Name daran.

8:04 Und der letzte Punkt fasst es zusammen: Vorschläge sind verhandelbar, Berechtigungen nicht. Das ist übrigens keine Skepsis gegenüber den Werkzeugen — es ist dieselbe Trennung, die wir heute Vormittag zwischen Anzeige und Autorisierung gezogen haben. Der erste Punkt ist der wahrscheinlichste im Alltag: Ein Protokollauszug mit Vorgangsinhalten wandert in den Auftrag, weil man gerade einen Fehler sucht.

8:28 Der zweite ist der, den man selten bemerkt — Zugangsdaten stehen in einer Datei, die das Werkzeug ohnehin mitliest. Schauen Sie einmal nach, was in Ihrem Projekt alles lesbar herumliegt. Und der dritte ist die Abkürzung, die man sich nicht erlauben sollte: eine Manifest-Änderung automatisch übernehmen.

Übung

8:46 In der Übung machen Sie den ganzen Durchlauf einmal bewusst — mit Kriterien vorher und Beleg hinterher. Die Aufgabe ist bewusst klein gewählt: ein Filter über den Status in der Liste von Klarpfad. Klein genug, um den Vorschlag vollständig zu lesen, und groß genug, um typische Befunde zu erzeugen. Genau diese Größe ist im Projektalltag die richtige Einheit.

9:08 Und die Reihenfolge ist die, über die wir gesprochen haben: Kriterien formulieren, dann generieren, dann gegen die Dokumentation prüfen. Drei Erfolgskriterien, und das mittlere ist das eigentliche Ziel: mindestens eine Abweichung, belegt mit einer Doku-Stelle. Nicht „das sieht veraltet aus", sondern „diese Komponente heißt laut Doku anders, hier ist der Link".

9:30 Diese Art von Befund hält im Team stand, alles andere ist Geschmacksdiskussion. Wer früh fertig ist, stellt dieselbe Aufgabe ohne Doku-Zugang und vergleicht — das ist die eindrücklichste Demonstration dieses Kapitels, die ich kenne. Fünf Schritte, deren Reihenfolge die Pointe ist. Ziel, Kriterien und Ausschlussliste zuerst — ohne sie ist der Rest Zufall. Dann den Doku-Zugang einbinden und die Aufgabe stellen.

9:56 Dann lesen und nachschlagen. Dann Befunde notieren, mit Beleg. Und zum Schluss entscheiden — übernehmen oder verwerfen. Das Verwerfen ist ausdrücklich ein erlaubtes Ergebnis, und wer es einmal bewusst getan hat, tut es beim nächsten Mal leichter. Drei Muster, die Sie kennen werden. Die Kriterien entstehen nachträglich, passend zum Ergebnis — dann hat man nichts geprüft, sondern sich überzeugt.

10:21 Der Befund lautet „wirkt veraltet" ohne Beleg und überlebt keine Diskussion. Und der dritte ist der ehrlichste: Der Vorschlag wird übernommen, weil das Nachbessern länger gedauert hätte. Morgen sehen wir, was aus solchen Entscheidungen wird — der fünfte Tag beginnt mit Migration und dem Erkennen alter Fassungen.