Dieser Beitrag ist anders als meine üblichen Texte. Ich werde euch nicht durch etwas führen, das ich ausgeliefert habe. Stattdessen möchte ich erkunden, was gerade tatsächlich mit agentischer KI in der Frontend-Entwicklung passiert — welche Tools existieren, was Teams damit machen, und wo ich die echten Chancen sehe. Betrachtet das als Erkundungsbericht.
Mein Ausgangspunkt war einfach: Ich habe Claude Code mit einem Figma-MCP-Server verbunden. Diese eine Verbindung — ein KI-Coding-Agent, der meine Design-Dateien sehen konnte — hat verändert, wie ich über den gesamten Frontend-Workflow denke. Es hat mich fragen lassen: Was können Agenten noch sehen? Was können sie noch tun? Also habe ich nachgeforscht.
Die MCP-Schicht: Agenten Augen und Hände geben
MCP — Model Context Protocol — ist das Stück, das einen Coding-Assistenten in etwas verwandelt, das einem Entwickler näherkommt. Ohne MCP kann deine KI Code schreiben, aber sie ist blind. Sie kann deine Designs nicht sehen, deine Komponentenbibliothek, deine Browser-Ausgabe oder deine Testergebnisse. Mit den richtigen MCP-Servern verbunden, kann sie all das sehen.
Der Figma-MCP-Server war mein Einstiegspunkt. Er gibt dem Agenten direkten Zugriff auf Design-Daten — Variablen, Komponenten, Layout und sogar eine React-plus-Tailwind-Code-Repräsentation. Du wählst einen Frame in Figma, der MCP-Server extrahiert die Design-Tokens und das Layout, und der Agent generiert Komponenten aus echtem Design-Kontext statt aus einem Screenshot zu raten. Er ersetzt den alten Copy-from-Inspect-Workflow. Das Ergebnis ist kein Produktionscode — es ist Gerüstbau — aber Gerüstbau, der bereits deine echten Design-Tokens und Abstände verwendet.
Aber Figma MCP ist nur ein Teil. Das Ökosystem, das sich bildet, ist interessanter als jeder einzelne Server. Storybook hat in Version 10.3 einen MCP-Server ausgeliefert, der Agenten deine bestehenden Komponenten, ihre Props und ihre Stories nachschlagen lässt, bevor sie neuen Code schreiben. Google hat Chrome DevTools MCP lanciert — Agenten können jetzt das DOM inspizieren, Netzwerk-Requests analysieren, Konsolenfehler lesen und Screenshots der laufenden App machen. Microsofts Playwright MCP stellt Browser-Automatisierung für E2E-Tests bereit. Und Context7 liefert Agenten aktuelle Framework-Dokumentation, um den häufigen Fehler zu vermeiden, dass ein Agent Patterns aus Next.js 13 und 15 mischt.
Der praktische Stack, der sich herausbildet: Figma MCP für Design, Storybook MCP für deine Komponentenbibliothek, Chrome DevTools MCP für Debugging, Playwright MCP für Tests, Context7 für Framework-Docs. Verbinde alle fünf und dein Agent wird von einem Code-Schreib-Assistenten zu etwas, das das Design sehen, prüfen was bereits existiert, Code generieren, ihn im Browser verifizieren und Tests schreiben kann. Das ist kein Spielzeug. Das ist ein Workflow.
PR-Reviews, die Kontext verstehen
Automatisiertes PR-Review ist einer der ausgereiftesten agentischen Anwendungsfälle im Frontend. Die Tools sind über das Stadium des «verherrlichten Linters» hinaus. CodeRabbit hat über 13 Millionen PRs in 2 Millionen Repos gereviewed — es führt 40+ eingebaute Linter aus und generiert kontextuelle Vorschläge für TypeScript, React und den Rest deines Stacks. Greptile geht anders vor: Es baut zuerst einen Wissensgraphen deiner Codebasis, dann reviewt es mit architektonischem Kontext. Es findet mehr Bugs, erzeugt aber mehr False Positives — der klassische Precision-Recall-Trade-off.
Was diese Tools für Frontend-Teams tatsächlich finden: fehlende Fehlerbehandlung, ungenutzte Imports, Typ-Inkonsistenzen und offensichtliche React-Anti-Patterns wie fehlende Dependency-Arrays in useEffect-Hooks. Was sie nicht zuverlässig finden: Rendering-Performance-Probleme, falsche Memoization-Strategien oder subtile State-Management-Bugs. Die Ermessensentscheidungen — ob diese Komponente aufgeteilt werden sollte, ob diese Abstraktion verfrüht ist, ob dieser Datenfluss den nächsten Entwickler verwirren wird — brauchen immer noch einen Menschen.
Aber was mich begeistert: Diese Tools werden besser darin, die Konventionen deines Projekts zu verstehen, nicht nur generische Best Practices. Wenn dein KI-Reviewer deine Codebasis kennt — deine Ordnerstruktur, deine Benennungsmuster, deine Komponentengrenzen — kann er Konsistenz auf einem Niveau durchsetzen, das für einen menschlichen Reviewer schwer zu erreichen ist bei Dutzenden PRs pro Woche.
Jenseits von ESLint: Architektur mit Agenten durchsetzen
Das ist der Bereich, den ich für Senior Engineers und Tech Leads am interessantesten finde. Traditionelles Linting findet Syntax- und Formatierungsprobleme. Architektur-Durchsetzung — «keine Business-Logik in Komponenten», «jeder API-Call geht durch die Service-Schicht», «Shared State muss dieses spezifische Pattern verwenden» — hat sich immer auf Code Review und Stammwissen verlassen. Das ändert sich.
Das Pattern, das entsteht: Du definierst Einschränkungen in maschinenlesbaren Dateien (CLAUDE.md, AGENTS.md, Architecture Decision Records), der Agent schreibt Code nach diesen Regeln, und deterministische CI-Checks blockieren Verstösse. Der Agent behebt dann seine eigenen Verstösse ohne Entwicklereingriff. Ein Tool namens Archgate verwandelt ADRs in ausführbare Regeldateien, die in CI laufen — ein fehlschlagender Check blockiert Merges. Der Agent konsultiert die Regeln, bevor er Code schreibt, sodass die meisten Verstösse nie im PR landen.
Was das speziell für Frontend-Teams mächtig macht: Du kannst Komponenten-Patterns (Smart vs. Dumb), Modul-Grenzen (keine Cross-Feature-Imports), State-Management-Konventionen und Accessibility-Standards durchsetzen — alles als ausführbare Regeln statt als Wiki-Seiten, die niemand liest. Der Linter bleibt die Durchsetzungsschicht. Der Agent ist die Authoring-Schicht, die Einschränkungen folgt und sich selbst korrigiert. Die Kombination ist effektiver als jede allein.
Ich dachte bereits über den Einsatz von Agenten zur Linting-Durchsetzung nach, bevor ich mit der Recherche für diesen Artikel begann. Jetzt bin ich überzeugt, dass es eines der Dinge mit dem höchsten Hebel ist, in die ein Frontend-Team investieren kann. Schreib deine Architekturregeln einmal, gib sie deinen Agenten und deiner CI-Pipeline, und hör auf, dieselben PR-Review-Kommentare zum zehnten Mal zu schreiben.
Framework-Migrationen: Wo Agenten bereits übertreffen
Wenn es einen Bereich gibt, in dem agentische KI ihren Wert zweifelsfrei bewiesen hat, dann sind es Framework-Migrationen. Die Zahlen von echten Teams sind beeindruckend. ZoomInfo hat 938 Dateien von Angular zu React migriert mit einer Flotte von 15 Agenten, koordiniert von einem Lead-Agenten. Ein Ingenieur, eine Woche. Die Schätzung für die manuelle Durchführung: sechs Monate mit vier bis fünf Ingenieuren. mgm technology partners hat eine SvelteKit-App zu Next.js migriert mit einer vierstufigen Agenten-Pipeline — Analyst, Planer, Implementierer, Validator — und es in 10 Personentagen abgeschlossen statt geschätzter 200 bis 250.
Die Architektur dieser Migrationen ist wichtig. ZoomInfo nutzte einen Claude-Opus-Agenten als «Teamleiter», der 15 Claude-Sonnet-Worker koordinierte — 10 für Implementation, einen für Unit-Tests, einen für E2E-Tests mit Playwright, zwei für Code-Review und einen für Paritäts-Audit. mgm passte Modelle an Aufgaben an: Opus für Planung, Sonnet für Implementation, Haiku für Validierung — was die Kosten auf der Review-Schicht um rund 80% reduzierte.
Aber die Fehlermodi sind lehrreich. Agenten, die Code zeilenweise zwischen Frameworks übersetzen, produzieren kaputten Output — ein SvelteKit Reactive Statement hat kein 1:1 React-Äquivalent. Die Teams, die Erfolg hatten, behandelten Migration als Neubau von einem funktionalen Blueprint, nicht als Übersetzung. Agenten stolperten auch über Randfälle: Memory Leaks in Async-Tests, überengineerte State-Verwaltung und endlose Transformationsschleifen. Das konsistente Ergebnis ist, dass Agenten die ersten 80% dramatisch schneller bewältigen als Menschen. Die letzten 20% — Randfälle, Performance-Tuning, architektonisches Urteil — brauchen immer noch erfahrene Ingenieure.
Es gibt einen interessanten Gegenpunkt aus der Codemod-Community: Für bekannte Patterns sind deterministische AST-Transforms zuverlässiger und günstiger als KI. Der React-Summit-2026-Vortrag «Where We're Going, We Don't Need Tokens» argumentiert, dass KI bei 200 Dateien Tokens verbrennt und manchmal halluziniert, während ein Codemod es perfekt und kostenlos erledigt. Der praktische Ansatz ist, Codemods für bekannte Patterns und KI für das Schreiben von Custom-Codemods für einzigartige Patterns deiner Codebasis zu verwenden.
Design-to-Code: Ehrliche Einschätzung
Der Design-to-Code-Bereich — v0, Lovable, Bolt, Screenshot-to-Code — bekommt viel Aufmerksamkeit. Hier ist die ehrliche Einschätzung, nachdem ich mir angesehen habe, was Teams tatsächlich mit diesen Tools ausliefern. v0 von Vercel produziert die saubersten React-plus-Tailwind-Komponenten. Es ist ein Frontend-Spezialist, und es ist tatsächlich gut darin, UI-Gerüste zu generieren, die in ein bestehendes Next.js-Projekt passen. Lovable ist die vollständigste End-to-End-Option, wenn du ein funktionierendes MVP mit Auth und Datenbank willst. Bolt glänzt bei Iterationsgeschwindigkeit in seiner Browser-IDE.
Keines von ihnen produziert Code, den du ohne Review ausliefern würdest. v0s Output ist am nächsten an Produktionsqualität für UI-Komponenten. Lovable und Bolt produzieren funktionale Apps, die architektonisches Cleanup, Security-Review und Performance-Optimierung brauchen, bevor sie Produktion berühren. Alle funktionieren am besten als Beschleuniger für die ersten 70-80% der Implementierung — das Gerüst, das dich schneller zu den interessanten Entscheidungen bringt.
Der grössere Wandel liegt aber nicht in Standalone-Tools. Er liegt im Figma-MCP-plus-Coding-Agent-Workflow. Wenn dein Agent dein tatsächliches Design-System lesen kann, deine bestehenden Komponenten in Storybook sehen und seinen Output in einem echten Browser über DevTools MCP verifizieren kann, wird die Design-to-Code-Pipeline kontextuell statt generisch. Das ist die Richtung, die mich am meisten begeistert.
Die 80/20-Realität
Über alle Anwendungsfälle, die ich recherchiert habe — PR-Reviews, Migrationen, Design-to-Code, Architektur-Durchsetzung — taucht dasselbe Muster auf. Agenten beschleunigen die ersten 70-80% der Frontend-Arbeit dramatisch. Die letzten 20-30% — Randfälle, Performance, Accessibility, architektonisches Urteil — brauchen immer noch menschliche Expertise. Anthropics eigene Daten bestätigen das: Entwickler nutzen KI in rund 60% ihrer Arbeit, können aber nur 0-20% der Aufgaben vollständig delegieren.
Das ist keine Einschränkung, über die man frustriert sein sollte. Es ist das Betriebsmodell, für das man designen sollte. Die Teams mit den besten Ergebnissen investieren in maschinenlesbare Einschränkungen — typisierte Interfaces, durchgesetzte Linting-Regeln, CI-Gates, dokumentierte Konventionen — die das Verhalten der Agenten leiten. Sie versuchen nicht, sich zur Qualität zu prompten. Sie bauen Leitplanken, die die 80% zuverlässig und die 20% offensichtlich machen.
Für Accessibility im Speziellen ist das kritisch. KI-Agenten können WCAG-Checks durchführen und Verstösse triagieren, aber automatisierte Erkennung deckt nur etwa 60-70% der Accessibility-Probleme ab. Die restlichen Probleme — kontextabhängige Beschriftung, Fokus-Management, Screenreader-Fluss — erfordern menschliches Testen. Mit dem European Accessibility Act in Kraft und US-ADA-Klagen über 4.600 pro Jahr ist es ein Haftungsrisiko, Accessibility als «die KI kümmert sich drum»-Problem zu behandeln.
Was ich als Nächstes ausprobieren würde
Basierend auf allem, was ich erkundet habe, hier was ich für ein Frontend-Team heute am wirkungsvollsten halte. Erstens: Verbinde deinen Coding-Agenten mit Figma MCP und Storybook MCP. Der sofortige Gewinn ist, dass der Agent aufhört, Komponenten zu generieren, die bereits existieren, und anfängt, auf deinem tatsächlichen Design-System aufzubauen. Zweitens: Füge einen KI-PR-Reviewer hinzu — CodeRabbit ist die sicherste Wahl für Breite, Greptile wenn du tieferes architektonisches Bewusstsein willst und mehr Rauschen tolerieren kannst.
Drittens — und das ist das, worüber ich am meisten begeistert bin: Schreib deine Architekturregeln als ausführbare Einschränkungen. Keine Wiki-Seite. Kein Confluence-Dokument, das niemand liest. Echte Regeln in CLAUDE.md oder ADR-Dateien, die dein Agent vor dem Code-Schreiben konsultiert und deine CI-Pipeline danach durchsetzt. Komponentengrenzen, Import-Restriktionen, State-Management-Patterns, Accessibility-Anforderungen. Mach sie maschinenlesbar und du verlässt dich nicht mehr auf Code Review, um dieselben Verstösse jeden Sprint zu finden.
Viertens: Wenn du eine Migration auf der Roadmap hast — Framework-Upgrade, Library-Swap, Design-System-Überholung — starte ein Pilotprojekt mit einer Agenten-Flotte. Die ZoomInfo- und mgm-Ergebnisse deuten darauf hin, dass eine gut strukturierte Agenten-Pipeline Monate von Migrationsarbeit in Tage komprimieren kann. Das Schlüsselwort ist gut strukturiert: Du brauchst klare Stufen, modellgerechte Aufgabenzuordnung und menschliche Aufsicht bei den Randfällen.
Wir sind nicht an dem Punkt, wo du einem Agenten ein Jira-Ticket gibst und weggehst. Aber wir sind weit über den Punkt hinaus, wo Agenten nur Autocomplete sind. Die Frontier liegt im Bindegewebe — den MCP-Servern, den Architekturregeln, den CI-Integrationen — die isolierte KI-Tricks in einen kohärenten Entwicklungsworkflow verwandeln. Dort investiere ich meine Aufmerksamkeit, und ich glaube, dort liegen die grössten Renditen für jedes Frontend-Team, das bereit ist zu experimentieren.