Wenn KI auf Angular und Flutter trifft

In Zeiten, in denen KI-gestützte Entwicklungstools wie Pilze aus dem Boden schießen, liegt es nahe, auch komplexe Frontend-Applikationen und Consumer Apps mit ihrer Hilfe zu erstellen. Doch was passiert, wenn man sich blind auf die künstliche Intelligenz verlässt? Ich durfte kürzlich ein Code Review der öffentlich zugänglichen Quellcodes einer Angular-Applikation und der zugehörigen Flutter-App begleiten, die fast ausschließlich mit KI-Unterstützung entwickelt wurde. Ziel der Analyse war es, die Wartbarkeit, Qualität und Risiken der bestehenden Codebasis zu bewerten. Das Ergebnis fiel ernüchternd aus.

Beim ersten Blick in das Projektverzeichnis fiel sofort auf: Die KI hatte fleißig produziert. Komponenten, Services, Module – alles war da. Doch die Struktur wirkte chaotisch. Die KI hatte offenbar keine klare Projektarchitektur verfolgt, sondern Code-Snippets generiert, die funktionierten, aber nicht zusammenpassten. Die Applikation nutzte aktuelle Technologien wie Angular 19, Tailwind CSS, NgRx und TypeScript – ein solides Fundament für skalierbare Frontend-Projekte. Einzelne Module wie die Keycloak-Anbindung waren vorhanden, doch die Gesamtstruktur folgt keinem erkennbaren Muster:

• Kein Designsystem: Es fehlte ein konsistentes Frontend-Designsystem wie Material Design, das Wiederverwendbarkeit und einheitliche UX sicherstellt.
• Keine Coding Guidelines: Weder Naming Conventions noch Strukturprinzipien wie Atomic Design wurden eingehalten.
• Fehlende Separation of Concerns: Logik, Darstellung und Datenfluss waren oft vermischt, was die Wartbarkeit massiv erschwert hat.

Das Review offenbarte eine Reihe qualitativer Defizite, die man sonst eher bei unerfahrenen Entwickler*innen sieht:

• Fehlende Typisierung: Viele Variablen und Methoden waren als `any` deklariert – ein No-Go in TypeScript. Die Verwendung von `any` untergräbt die Typsicherheit von TypeScript und erhöht die Fehleranfälligkeit.
• Fehlende Error-Handling-Strategien: HTTP-Requests wurden ohne `.catchError()` oder globale Interceptors geschrieben.
• DRY-Prinzip verletzt: Redundanter Code, doppelt verwendete Komponenten.
• Monolithische Komponenten: Einige Komponenten umfassen bis zu 600 Zeilen Code – ein klares Zeichen für fehlende Modularisierung. Eine Komponente mit mehr als 50 Zeilen in der Render-Methode ist ein Warnsignal. Sie sollte in kleinere, wiederverwendbare Bausteine zerlegt werden.
• Hardcoded Konfigurationen: API-Keys und Endpunkte sind direkt im Code eingebettet statt über Environment Variables gesteuert oder i18n-unterstützt.
• Kein Linter: Es fehlt ein Tool zur statischen Codeanalyse, das Stil und Qualität sicherstellt.

Wichtige Sicherheitsaspekte wurden ignoriert:

• OWASP Top 10 nicht berücksichtigt: Kritische Risiken wie XSS, CSRF oder Injection wurden nicht adressiert.
• Fehlende Input-Validierung: Formulare und API-Aufrufe sind ungeschützt.
• Sensible Daten unverschlüsselt: Keine Verschlüsselung bei Authentifizierung oder Speicherung.
• Console.log bei Auth-Events – solche Logs können in der Produktion sensible Daten preisgeben. 

Beispiel:

Die Anwendung verletzt grundlegende Accessibility-Richtlinien:

• Fehlerhafte HTML-Struktur: z. B. `<div>` innerhalb von `<ul>`-Listen.
• Unvollständige Aria-Labels
• Keine nativen HTML-Elemente wie `<main>`, `<footer>`, `<article>`
• Nicht verknüpfte Labels
• Leere Fehlermeldungen
• Fehlende Alt-Texte bei Bildern
• Keine vollständige Keyboard-Navigation
• Keine Sprachumschaltung – nur Landing Page auf Englisch

Accessibility ist kein Nice-to-have, sondern gesetzlich vorgeschrieben. Die Missachtung kann rechtliche Konsequenzen nach sich ziehen.

Die Anwendung wurde ohne jegliche Teststrategie entwickelt:

• Keine Unit Tests
• Keine Error Boundaries – Fehler in Komponenten führen zu White Screens.
• Keine zentrale Fehlerbehandlung

Ohne Tests und Fehlerhandling ist die Anwendung instabil und schwer wartbar. Fehler bleiben unentdeckt, Nutzererfahrung leidet.

Die Dokumentation ist praktisch nicht existent:

• Keine Kommentare im Code – weder das „Warum“ noch das „Was“ wird erklärt.
• Keine externen Dokumente wie API-Spezifikationen.
• README ist Standard-Template – ohne projektspezifische Inhalte.
• Keine selbstdokumentierende Struktur – kryptische Namen und fehlende Klarheit.

Dokumentation ist essenziell für Teamarbeit, Wartung und Onboarding. Ohne sie wird jedes Update zur Detektivarbeit. Hinzu kommt: Angular 19 wird nur bis Mai 2026 unterstützt, die aktuelle Version ist bereits Angular 20. Ein Upgrade ist dringend zu empfehlen.

Um fair zu bleiben: Es gab auch Lichtblicke. Die KI hatte moderne Angular-Features wie Reactive Forms, Observables und sogar RxJS-Operators korrekt eingesetzt. Auch die Grundstruktur der Komponenten war solide – Inputs, Outputs, Lifecycle Hooks wurden korrekt verwendet. Doch diese technischen „Erfolge“ wirkten wie isolierte Inseln in einem Meer aus inkonsistenter Architektur.

Die App basierte auf einem aktuellen Flutter-Stack und ließ sich grundsätzlich ausführen. Sie verfolgte ein White-Label-Konzept, um verschiedene Varianten der App für unterschiedliche Anwendergruppen bereitzustellen. Als Architekturansatz wurde Bloc (Business Logic Component) verwendet – ein etabliertes Pattern zur Trennung von Präsentations- und Geschäftslogik. Bloc wurde für State-Management und Strukturierung eingesetzt, aber die Umsetzung war inkonsistent. Der GraphQL-Client wurde beispielsweise tief in andere Schichten gereicht, statt klar im „Data Provider“ isoliert zu sein. Obwohl die Architektur auf modernen Prinzipien basierte, fehlte es an Stringenz und Klarheit, was die Komplexität unnötig erhöhte.

Trotz eines überschaubaren Funktionsumfangs war die Codebasis überraschend umfangreich. Die Ursachen lagen auf der Hand:

• Duplizierte UI-Komponenten, die mehrfach verwendet wurden statt modularisiert.
• Generierter Code (z. B. mit `freezed`) – hilfreich, aber ohne Tests schwer nachvollziehbar.
• Barrel-Dateien zur Import-Vereinfachung – teils sinnvoll, teils überflüssig.
• Unnötige Abstraktionen ohne praktischen Nutzen.
• Keine Hinweise auf Coding-Guidelines wie „Effective Dart“.
• Drittanbieter-Bibliotheken wie `screen_brightness` waren eingebunden, aber nicht verwendet.

Die Codebasis wirkte überladen und unstrukturiert. Ohne klare Guidelines war sie schwer zugänglich – insbesondere für neue Entwickler*innen.

Positiv anzumerken ist, dass in der App eine Grundsicherung vorhanden war. Personenbezogene Daten wurden über `flutter_secure_storage` verschlüsselt gespeichert, API-Keys oder Secrets waren im Quellcode nicht auffindbar und die Authentifizierung erfolgte über eine Keycloak-Instanz.

• Es existierten keine Unit-, Widget- oder Integrationstests.
• Eine CI/CD-Konfiguration für die App war nicht vorhanden.
• Es gab keine Error Boundaries oder Logging-Strategien.

Das Fehlen jeglicher Tests stellte ein gravierendes Risiko dar. Zukünftige Änderungen können nicht zuverlässig geprüft werden, was die Wartung erschwert und die Stabilität gefährdet.

• Die Dokumentation war rudimentär und beschränkte sich auf wenige Aspekte.
• Informationen zu Architektur, APIs oder Build-Prozessen fehlten.
• Eine Dokumentation der GraphQL-Schnittstellen war nicht auffindbar.
• Das Tool „flutter_flavorizr“ zur Erstellung neuer Varianten war dokumentiert – jedoch fehlten DEV/PROD-Konfigurationen.
• Hinweise zu Verantwortlichkeiten oder CI-Prozessen waren nicht vorhanden.

Dokumentation ist essenziell für nachhaltige Softwareentwicklung. Das Fehlen jeglicher Dokumentation stellt ein Risiko für die zukünftige Verwendung und Weiterentwicklung dar.

KI-Tools können repetitive Aufgaben beschleunigen, Boilerplate-Code generieren und sogar komplexe Logik vorschlagen. Aber sie verstehen keine Projektkonventionen, keine Teamstandards und keine langfristige Wartbarkeit. Sie optimieren für „funktioniert jetzt“, nicht für „wartbar morgen“.
Eine gute Frontend-Applikation oder App braucht:

• Klare Modulstruktur
• Wiederverwendbare Komponenten
• Saubere Trennung von Logik und Darstellung
• Testbarkeit und Dokumentation
• Ein Designsystem – es definiert Standards für Komponenten, Layouts und Interaktionen. 

All das kann eine KI nur leisten, wenn sie mit klaren Vorgaben und menschlicher Kontrolle arbeitet.

Das Code Review war ein wertvoller Reminder: KI kann ein mächtiger Helfer sein – aber kein Ersatz für erfahrene Entwickler*innen. Wer mit KI entwickelt, muss umso mehr reviewen, refaktorisieren und dokumentieren. KI kann repetitive Aufgaben übernehmen, Boilerplate generieren und sogar komplexe Logik vorschlagen. Aber ohne klare Vorgaben, menschliche Kontrolle und Review entsteht kein qualitativ hochwertiges Produkt.

Mein Rat: Nutze KI, um schneller zu starten. Aber verlasse dich nicht darauf, dass sie dein Projekt auch sauber zu Ende bringt. Für die nachhaltige Softwareentwicklung nutze KI vielmehr als Co-Pilot, aber setze dich selbst ans Steuer. Architektur, Sicherheit, Accessibility und Tests sind keine Nebensache, sondern die Basis für nachhaltige Softwareentwicklung.