KI-Assistenten im Angular-Workflow vorbereiten

KI-Assistenten vorbereiten

0:00 Ein Assistent ohne Projektkontext schreibt das Angular, das er am häufigsten gesehen hat. Und das ist selten das aktuelle — schlicht deshalb, weil die alten Muster länger im Umlauf sind und entsprechend häufiger vorkommen. Das ist kein Vorwurf an die Werkzeuge, es ist eine Eigenschaft. Daraus folgt die Arbeit dieses Moduls: Aufgabe präzise formulieren, Kontext bereitstellen, Version nennen, Rechte begrenzen.

0:25 Nichts davon ist spektakulär, und alles davon entscheidet über die Qualität des Ergebnisses.

Modernisierung, KI-Einsatz und Abschluss

0:31 Wir sind im letzten Tag. Die Modernisierung steht, jetzt zwei Module zur KI-gestützten Entwicklung: In diesem bereiten wir vor, im nächsten prüfen wir. Die Reihenfolge ist Absicht — das Prüfen wird leichter, wenn das Vorbereiten stimmt.

Aufgabe und Akzeptanzkriterien formulieren

0:46 Beginnen wir bei der Aufgabe selbst. Und mit einem Maßstab, der erstaunlich gut funktioniert. Eine brauchbare Aufgabenbeschreibung nennt, was entstehen soll, woran der Erfolg gemessen wird und wo die Grenzen der Änderung liegen. Ohne Akzeptanzkriterien gibt es keinen Maßstab für die Abnahme — weder für einen Assistenten noch für einen Menschen.

1:07 Und das ist der Maßstab, den ich meine: Eine Aufgabe, die auch ein Mensch annehmen könnte. Wenn Sie die Beschreibung einer neuen Kollegin geben könnten und sie wüsste, was zu tun ist, dann ist sie gut genug. Fünf Schritte, und der vierte ist der, den man am häufigsten weglässt: benennen, was ausdrücklich nicht geändert werden soll.

1:25 Das klingt nach Misstrauen und ist einfach Klarheit — auch ein Mensch würde sonst vielleicht die Formatierung mitziehen. Schritt fünf ist der organisatorische und in der Praxis wichtigste: Die Beschreibung gehört ins Repository, nicht ins Chatfenster. Die Fußzeile sagt warum — was nur im Chat steht, ist beim nächsten Review nicht mehr auffindbar. Und dann können Sie nicht mehr prüfen, ob etwas beauftragt war.

1:49 Vier Punkte, und der zweite ist der, der Teams am meisten Zeit kostet: Die Abnahme wird zur Geschmacksdiskussion ohne Maßstab. Zwei Leute schauen auf denselben Vorschlag, der eine findet ihn gut, die andere nicht, und es gibt keine Grundlage, das zu entscheiden. Der dritte ist der, den man unterschätzt: Der Umfang wächst, weil keine Grenze gesetzt war — und im nächsten Modul sehen Sie, wie schnell aus fünf Dateien elf werden.

2:15 Der vierte: Beim zweiten Anlauf beginnt die Klärung von vorn. Der erste Punkt ist der häufigste Anfängerfehler und gilt für Menschen genauso: Die Aufgabe beschreibt die Lösung statt das Ziel. Dann bekommen Sie genau das, was Sie sich vorgestellt haben — auch wenn es eine bessere Möglichkeit gegeben hätte. Der zweite ist der, der die Abnahme unmöglich macht: Akzeptanzkriterien fehlen oder sind nicht prüfbar. „Soll übersichtlich sein" ist kein Kriterium.

2:42 Und der dritte: Die Grenze der Änderung wird nicht benannt.

Projektkontext bereitstellen

2:46 Jetzt zum zweiten Teil der Vorbereitung — und zu dem, was in Ihrem Repository ohnehin stehen sollte. Projektkontext heißt: die getroffenen Architekturentscheidungen, die Konventionen des Teams, ein bis zwei gute Beispiele und die eingesetzte Angular-Version mit ihren Standardannahmen. Das Angenehme daran: Das meiste davon haben wir in dieser Woche ohnehin erzeugt.

3:08 Der Architekturentscheid aus Modul acht, die Teststrategie aus Modul dreizehn, der Versionsstand aus Modul eins. Die Vorbereitung eines Assistenten ist zu einem guten Teil nichts anderes als ordentliche Projektdokumentation. Vier Felder, und das vierte ist das, was am häufigsten fehlt und am meisten bewirkt: die Version mit ihren Standardannahmen.

3:29 Zoneless, OnPush als Standard, Signal Forms — wenn das nicht dasteht, entsteht Code nach den Mustern, die am häufigsten im Umlauf sind. Das dritte Feld ist das, bei dem man aufpassen muss: gute Beispiele. Nicht irgendeine Datei — eine, die den Konventionen wirklich folgt. Ein schlechtes Beispiel wirkt stärker als eine gute Regel.

3:50 Der erste Punkt ist der, der die Hälfte aller veralteten Vorschläge erklärt: Die Version wird nicht genannt. Der zweite ist der eben angesprochene: Als Beispiel dient eine Datei, die selbst nicht den Konventionen folgt — dann pflanzt sich der Fehler fort, und zwar konsequent. Und der dritte ist der organisatorische, den ich schon genannt habe und der mir wichtig genug ist für die Wiederholung: Der Kontext steht im Chat statt im Repository und geht verloren.

Angular-Wissen für die eingesetzte Version

4:16 Kommen wir zu den Werkzeugen, die Angular selbst dafür anbietet. Und die lösen genau das Problem, das ich eingangs beschrieben habe. Der MCP-Server der Angular-Kommandozeile wird über einen Aufruf eingerichtet und in der Konfiguration des Editors eingetragen. Er bietet unter anderem Suche in der offiziellen Dokumentation, Abruf der Best Practices, Auflisten der Projekte, Starten und Stoppen des Entwicklungsservers, Ausführen von Zielen und eine Analyse für die Umstellung auf OnPush und zoneless.

4:46 Der entscheidende Punkt dabei ist der erste: Nachschlagen statt erinnern. Der Assistent arbeitet gegen die aktuelle Dokumentation, nicht gegen sein Gedächtnis. Fünf Zeilen Konfiguration, mehr ist es nicht. Der Server läuft über den Paketausführer und wird nicht installiert — er gehört nicht in Ihre Projektabhängigkeiten.

5:05 Die Datei gehört in die Editor-Konfiguration; je nach Werkzeug an unterschiedliche Stellen. Und in der Fußzeile steht das zweite Angebot: Angular Agent Skills, über einen eigenen Befehl aus dem offiziellen Repository. Das sind Anleitungen für idiomatischen Angular-Code — eine andere Art von Hilfe als die Dokumentationssuche.

5:26 Drei Zeilen, und die dritte ist die Empfehlung: beides zusammen. Der MCP-Server liefert aktuelles Wissen und ausführbare Schritte — er kann nachschlagen, bauen und testen. Die Agent Skills liefern Anleitungen, wie idiomatischer Angular-Code aussieht. Das eine beantwortet „wie ist es", das andere „wie macht man es gut". Zusammen decken sie die beiden Lücken ab, die ein Assistent ohne Vorbereitung hat: veraltetes Wissen und fehlende Konventionen.

5:54 Der erste Punkt ist der, gegen den dieses ganze Kapitel gebaut ist: Der Assistent erzeugt Code aus seiner Erinnerung statt aus der Dokumentation. Der zweite ist ein Rechteproblem, das ins nächste Kapitel überleitet: Dokumentationsrecherche und Ausführen von Befehlen werden vermischt. Das eine ist harmlos, das andere nicht — und man sollte es getrennt freigeben können.

6:16 Und der dritte ist der bittere: Die Werkzeuge werden eingerichtet, aber nie in der Aufgabe erwähnt. Dann stehen sie da und niemand benutzt sie.

Werkzeugrechte begrenzen

6:25 Damit zum letzten Teil der Vorbereitung. Und zu einer Übung, die zehn Minuten dauert und die Sie danach immer wieder machen werden. Rechte werden einzeln vergeben: Lesen im Repository, Schreiben in bestimmten Pfaden, Ausführen bestimmter Befehle. Drei Kategorien, drei Entscheidungen. Zugriff auf Geheimnisse, produktive Systeme und fremde Dienste bleibt ausgeschlossen — da gibt es nichts abzuwägen.

6:49 Und was ein Assistent getan hat, muss nachvollziehbar bleiben: im Diff und in der Historie. Das ist übrigens derselbe Anspruch, den wir an Menschen stellen, nur dass er hier öfter ausgesprochen werden muss. Vier Gründe, und der dritte ist der, bei dem es kein Zurück gibt: Geheimnisse im Kontext sind nicht mehr zurückzuholen. Alles andere lässt sich reparieren — das nicht.

7:12 Der erste: Ein Schreibrecht außerhalb des Bereichs erzeugt unbemerkte Änderungen, und unbemerkt ist hier das Problem, nicht die Änderung. Der zweite: Ein Ausführungsrecht mit Netzzugang verlässt den geprüften Rahmen. Und der vierte: Ohne nachvollziehbare Spur fehlt die Grundlage für die Abnahme — dann bleibt nur Vertrauen.

7:32 Der erste Punkt ist die Abkürzung, die ich verstehe und trotzdem nicht empfehle: Alle Rechte werden zusammen freigegeben, weil es schneller geht. Es geht auch schneller — bis zu dem Tag, an dem es nicht mehr schneller geht. Der zweite ist ein Hygienefehler mit großer Wirkung: Der Assistent arbeitet auf dem Hauptzweig statt auf einem eigenen. Dann können Sie den Diff nicht mehr sauber lesen.

7:54 Und der dritte: Zugangsdaten liegen in einer Datei im Arbeitsverzeichnis — und damit im Lesebereich.

Übung

8:00 Bereiten wir eine echte Änderung vor. Ausgeführt wird sie im nächsten Modul — und dann sehen Sie, was Ihre Vorbereitung wert war. Spurweite soll in der Auftragsübersicht eine Spalte für den zugewiesenen Monteur bekommen, sortierbar und filterbar. Die Änderung ist bewusst klein gewählt — klein genug, um sie im Seminar vollständig zu begleiten, und groß genug, um Architektur, Tests und Zugänglichkeit zu berühren.

8:25 Fachlich ist sie übrigens real: Bei Falkenhorst fragen die Meisterinnen heute mündlich nach, wer an einem Auftrag arbeitet. Das Lernziel ist in einem Satz gesagt und schwerer, als es klingt: eine Aufgabe so vorbereiten, dass ihr Ergebnis abnehmbar ist. Abnehmbar — nicht gut, nicht richtig. Überprüfbar. Das Erfolgskriterium verlangt drei Artefakte: eine Aufgabenbeschreibung mit prüfbaren Akzeptanzkriterien, den benannten Projektkontext und eine Rechteliste, in der jede Freigabe einzeln begründet ist.

8:56 Wer früh fertig ist, ergänzt, welche Werkzeuge zur Dokumentationsrecherche bereitstehen sollen. Der erste Schritt ist der, bei dem man sich zusammenreißen muss: das fachliche Ziel ohne Technik beschreiben. Kein „Spalte hinzufügen", sondern „Meisterinnen sollen sehen, wer an einem Auftrag arbeitet". Schritt zwei formuliert drei bis fünf prüfbare Kriterien.

9:19 Schritt drei zieht die Grenzen. Schritt vier stellt den Kontext zusammen — und da werden Sie merken, dass das meiste schon existiert. Und Schritt fünf ist die Rechteliste, je Zeile mit einer Begründung. Der erste Punkt ist der, der die Abnahme im nächsten Modul scheitern lässt: Die Akzeptanzkriterien sind nicht prüfbar, sondern Geschmacksfragen.

9:41 Der zweite ist der, der sich fortpflanzt: Der Kontext verweist auf eine Datei, die den Konventionen nicht folgt. Und der dritte ist die Abkürzung von vorhin: Die Rechte werden pauschal vergeben und einzeln nicht begründet. Im nächsten Modul lassen wir den Assistenten arbeiten — und prüfen, was dabei herauskommt.