Angular AI in echten Projekten sinnvoll einsetzen

Ammar Najjar · Veröffentlicht am 13. Juli 2026 — angularaimcpngrxarchitecture

KI kann eine Komponente erzeugen, einen Test schreiben oder einen Compilerfehler erklären. In realen Anwendungen hängen die Ergebnisse jedoch deutlich stärker vom Projektkontext als von den Fähigkeiten des Modells ab. Sie kennt weder eure Architektur noch eure Konventionen oder die Grenzen, die über Jahre entstanden sind.

Angular hat kürzlich mehrere AI-orientierte Erweiterungen veröffentlicht. MCP, Agent Skills, AI Instructions und Signal Forms. Zusammen ergeben sie weit mehr als nur eine weitere KI-Integration.

So integriere ich diese Bausteine heute in einen Enterprise-Angular-Workflow.

Angular AI in echten Projekten sinnvoll einsetzen

Ich habe aufgehört, einzelne Features zu betrachten

Als ich zum ersten Mal über Angular CLI MCP, Agent Skills, AI Instructions, Signal Forms und die weiteren Neuerungen gelesen habe, habe ich jedes Feature einzeln bewertet. Das war im Nachhinein der falsche Ansatz.

Heute sehe ich sie als Teile eines gemeinsamen Werkzeugkastens. Jedes löst ein anderes Problem. Manche helfen dem Assistenten dabei, Angular besser zu verstehen. Andere vermitteln den Kontext meines Workspaces. Einige verbessern die Implementierung, andere die Verifikation.

Seit ich sie als ein zusammenhängendes Ökosystem statt als einzelne Funktionen betrachte, ergibt das Gesamtbild deutlich mehr Sinn.

Wenn ich den Assistenten bitte, ein neues Feature umzusetzen, liefert MCP Informationen darüber, welches Projekt betroffen ist, welche Build-Ziele ausgeführt werden müssen und welche Tests dazugehören. Agent Skills beschreiben, wie Komponenten in diesem Workspace aufgebaut werden sollen. AI Instructions sorgen dafür, dass unsere Konventionen eingehalten werden. Früher musste ich all diese Dinge manuell korrigieren. Heute startet der Assistent bereits mit dem Großteil des benötigten Kontexts.

Meine Anwendungsarchitektur hat sich nicht verändert

Eine Sache hat mich nicht überrascht. Die Laufzeitarchitektur ist im Wesentlichen gleich geblieben.

Das BFF übernimmt weiterhin alles rund um APIs, also Authentifizierung, Autorisierung, Validierung, Caching, Tool Calling und Observability. Die Angular-Anwendung arbeitet weiterhin mit typisierten Verträgen. NgRx verwaltet weiterhin den Feature-State. Services liefern weiterhin Observables zurück.

Diese Architektur hat bereits vor dem Einsatz von KI gut funktioniert. Ich sehe keinen Grund, sie zu ersetzen. Verändert hat sich vielmehr der Entwicklungsprozess rundherum.

Als KI-Werkzeuge Teil des Entwicklungsprozesses wurden, musste ich entscheiden, wo sie hingehören. LLM-Aufrufe, Prompt-Erstellung und Tool Handling ließen sich ganz natürlich im BFF unterbringen. Authentifizierung, Validierung und Caching waren dort ohnehin bereits angesiedelt. Dadurch bleiben diese Querschnittsthemen an einem Ort, während sich die Angular-Anwendung weiterhin auf Darstellung und Benutzerinteraktion konzentriert. Diese Aufteilung fühlte sich von Anfang an richtig an und hat sich bis heute bewährt.

Die größte Veränderung beginnt vor der Implementierung

Früher begann ich direkt mit der Implementierung.

Heute beginne ich mit einer kleinen Spezifikation.

Nichts Kompliziertes. Meist reicht sie aus, um folgende Fragen zu beantworten:

• Welches Problem lösen wir?
• Was gehört zu diesem Feature?
• Was gehört ausdrücklich nicht dazu?
• Welche Architekturgrenzen müssen eingehalten werden?
• Wann gilt das Feature tatsächlich als fertig?

So sieht eine dieser Spezifikationen im Repository typischerweise aus:

## Feature: Audit log export

### Problem
Compliance team needs to export audit logs as CSV for quarterly reports.
Currently manual DB queries.

### Scope
- New route: /audit/export
- BFF endpoint: GET /api/audit/logs/export?from=&to=&format=csv
- NgRx effect to trigger download
- Loading state in toolbar component

### Boundaries
- No UI changes beyond toolbar button
- BFF handles auth + rate limiting
- CSV generation happens server-side

### Out of scope
- PDF export (future)
- Real-time streaming

### Done
- Export completes < 10s for 30-day range
- Error state handled in UI
- E2E test for happy path

Diese Spezifikation liegt direkt im Repository. Sobald sie vorhanden ist, wird alles Weitere deutlich einfacher. Der Assistent muss das Feature nicht mehr aus einem Gespräch rekonstruieren, und Reviewer müssen die ursprüngliche Absicht nicht erraten. Die Spezifikation wird zur gemeinsamen Referenz.

Angular versteht endlich Angular

Einer der größten Vorteile ist für mich, dass Angular inzwischen selbst Teil dieses Workflows geworden ist.

AI Instructions, llms.txt, Agent Skills und Angular CLI MCP reduzieren ein Problem, das ich früher regelmäßig gesehen habe.

Code, der zwar funktionierte, sich aber nicht wie Angular anfühlte. Genauer gesagt, nicht wie modernes Angular.

Frameworkseitig gepflegte Empfehlungen verbessern das deutlich. Der Assistent versteht wesentlich mehr über Angular, bevor überhaupt Code erzeugt wird. Dadurch fällt später deutlich weniger Korrekturarbeit an.

Früher erzeugte der Assistent beispielsweise so etwas:

@Component({
  selector: 'app-audit-export',
  template: `<div>...</div>`
})
export class AuditExportComponent {
  constructor(private http: HttpClient) {}
}

Heute entsteht deutlich häufiger Code, der tatsächlich zum Projekt passt:

@Component({
  selector: 'app-audit-export',
  standalone: true,
  imports: [FormsModule],
  template: `<div>...</div>`
})
export class AuditExportComponent {
  private readonly store = inject(Store);
  readonly exportState = this.store.selectSignal(selectExportState);
}

Angular CLI MCP hat meine Erwartungen verändert

Angular CLI MCP hatte wahrscheinlich den größten Einfluss auf meine tägliche Arbeit. Nicht weil dadurch besserer Code entsteht, sondern weil sich meine Erwartungen an den Assistenten verändert haben.

Bevor überhaupt ein Feature umgesetzt wird, erwarte ich inzwischen, dass der Assistent den Workspace versteht.

Ich erwarte, dass er weiß,

• welches Projekt betroffen ist,
• wo das Feature implementiert wird,
• welches Build-Ziel erfolgreich sein muss,
• welche Tests dazugehören,
• und welche Angular-APIs sinnvoll sind.

Diese Erwartungen entsprechen viel stärker der Arbeitsweise eines erfahrenen Entwicklers.

Ich messe Erfolg nicht mehr am generierten Code

Die Qualität des erzeugten Codes ist weiterhin wichtig. Aber längst nicht mehr so entscheidend wie früher.

Heute interessieren mich vielmehr Fragen wie:

• Hat der Assistent die Architektur verstanden?
• Hat er die Grenzen des Features eingehalten?
• Ist NgRx dort geblieben, wo es hingehört?
• Wurde das BFF respektiert?
• Sind bestehende Verträge erhalten geblieben?
• Ist das Ergebnis für andere Entwickler gut nachvollziehbar?

Das sind für mich deutlich bessere Erfolgsindikatoren als die Anzahl erzeugter Codezeilen.

Die andere Seite von Angular AI

Bisher ging es um KI als Entwicklungshilfe.

Das Angular-AI-Ökosystem umfasst jedoch noch einen weiteren Bereich. Mit Genkit, Firebase AI Logic und der Gemini API lassen sich KI-Funktionen direkt in Angular-Anwendungen integrieren. Auch die Entwurfsmuster für den Einsatz von LLM-APIs mit Signals und der resource API sind spannend.

Das ist allerdings ein eigenes Thema. Es gehört dennoch zum selben Ökosystem.

Wohin die Reise geht

Einige Teile des Angular-AI-Ökosystems gehören inzwischen zu meinem täglichen Workflow. Andere müssen ihren Platz noch beweisen.

Es gibt noch viel zu entdecken. Jedes dieser Werkzeuge verdient einen eigenen Blick, nicht als Feature-Ankündigung, sondern als Teil der modernen Angular-Entwicklung.

Mich interessiert besonders, welche Erfahrungen andere gemacht haben. Wenn ihr Angulars AI-Werkzeuge bereits in euren Projekten nutzt, freue ich mich über eure Eindrücke. Was funktioniert gut? Was eher nicht? Welche Werkzeuge haben euch überzeugt und welche weniger?

Die Entwicklung schreitet schnell voran, sodass keine einzelne Perspektive das gesamte Bild abdecken kann.

Schreibt eure Gedanken gerne in die Kommentare oder meldet euch direkt bei mir.

Ich lese jede Rückmeldung.