Was bleibt vom Frontend-Entwickler, wenn die KI den Code schreibt?

Developer-Update Herbst 2026: Wie sich meine Arbeit durch KI verändert hat

Im Februar habe ich hier geschrieben, dass der Autopilot nicht das Cockpit übernimmt. Meine damalige These: Die Rolle von Entwicklern verändert sich. Weniger Tipparbeit, mehr Review, mehr Kommunikation und mehr Entscheidungen.

Acht Monate später stehe ich grundsätzlich noch zu dieser These. Aber ich muss zugeben: Die Verschiebung ging schneller und weiter, als ich es damals formuliert habe. Vor allem hat sich für mich die Frage verändert, welche Arbeit eigentlich noch den größten Teil meiner Zeit ausmacht. Zeit für ein Update.

Was ich im Februar unterschätzt habe

Damals habe ich geschrieben, dass KI uns bei der schnellen Prototypenentwicklung, bei Boilerplate und beim Recherchieren unterstützt. Das war rückblickend zu vorsichtig.

Heute übernimmt KI in unserem Arbeitsalltag bei IDENTIC einen großen Teil der eigentlichen Implementierung. Nicht nur einzelne Codezeilen oder wiederkehrende Komponenten, sondern zunehmend komplette Features und zusammenhängende Änderungen über mehrere Teile einer Codebase hinweg. Das bedeutet nicht, dass jede Aufgabe automatisch schneller oder besser wird. Aber es bedeutet, dass sich der Schwerpunkt meiner Arbeit deutlich verschoben hat.

Um das greifbar zu machen, hilft ein vereinfachter Blick auf den klassischen Entwicklungsprozess. Grob betrachtet hatten wir drei große Blöcke:

Specs → Implementation → Testing

Die Implementierung hat dabei häufig den größten Teil der Zeit beansprucht: Komponenten bauen, Layouts umsetzen, State verdrahten, Schnittstellen anbinden und Edge Cases abfangen.

Heute sieht die Kette bei mir zunehmend anders aus:

Context Engineering → Specification → Generation → Testing → Verification

Die Implementierung ist nicht verschwunden. Sie wird nur immer stärker zu einer Aufgabe, die ich an KI delegieren kann. Dafür werden die Schritte davor und danach wichtiger. Und genau darin liegt für mich die eigentliche Veränderung.

Der Flugplan wird wichtiger

Im letzten Artikel habe ich beschrieben, was Piloten tun, während der Autopilot fliegt: überwachen, kommunizieren und Verantwortung tragen. Was ich damals ausgelassen habe, ist der Teil vor dem Start.

Bevor ein Autopilot überhaupt fliegen kann, braucht es einen Flugplan. Eine Route, Wegpunkte, Höhen, Rahmenbedingungen und gegebenenfalls Ausweichmöglichkeiten. Ein Autopilot kann eine Route präzise abfliegen. Das bedeutet aber nicht, dass die Route sinnvoll ist.

Genau hier liegt für mich eine der wichtigsten Veränderungen in der KI-gestützten Softwareentwicklung. Die Frage lautet nicht mehr nur:

Wie implementiere ich dieses Feature?

Sondern zunehmend:

Welche Informationen, Regeln und Werkzeuge braucht die KI, um dieses Feature in unserem System richtig umzusetzen?

Diese Arbeit hat inzwischen einen Namen.

Von Prompting zu Context Engineering

Im Februar habe ich noch gutes Prompting als wichtige Fähigkeit empfohlen. Das würde ich heute anders formulieren. Prompting bleibt relevant. Aber ein guter Prompt ist nur ein kleiner Teil dessen, was ein KI-Agent für eine komplexe Aufgabe benötigt.

Der Begriff Context Engineering beschreibt die umfassendere Arbeit: den richtigen Kontext für den jeweiligen nächsten Schritt bereitzustellen. Andrej Karpathy hat den Begriff 2025 als das Befüllen des Kontextfensters mit den richtigen Informationen für den nächsten Schritt beschrieben. Inzwischen wird der Begriff zunehmend verwendet, um genau diese systematischere Form der Arbeit mit LLMs zu beschreiben.

In unserem Alltag bei IDENTIC bedeutet das beispielsweise:

• Architekturentscheidungen und bestehende Patterns verstehen
• Konventionen und Antipatterns einer Codebase dokumentieren
• Akzeptanzkriterien und Projektregeln präzisieren
• relevante Dateien und Abhängigkeiten gezielt bereitstellen
• Werkzeuge, Feedbackschleifen und Testmöglichkeiten zugänglich machen

Wir haben dafür eigene Workflows entwickelt, in denen die Planung neuer Features erst beginnt, wenn die relevanten Patterns und Strukturen der Codebase erfasst sind.

Das klingt zunächst nach zusätzlicher Dokumentation. In der Praxis ist es aber ein entscheidender Unterschied: zwischen einer KI, die irgendeine funktionierende Lösung produziert, und einem Agenten, der eine Lösung entwickelt, die zu unserem bestehenden System passt.

Context Engineering ist damit nicht einfach die Kunst, bessere Prompts zu schreiben. Es ist die Gestaltung der Arbeitsumgebung, in der KI Software entwickelt.

Wenn Implementierung billiger wird, wird Architektur wichtiger

Das führt zu einer Konsequenz, die ich im Februar so noch nicht auf dem Schirm hatte:

Wenn die Kosten der Implementierung sinken, steigt der relative Wert der Architektur.

Ein Agent kann heute relativ schnell eine neue API-Route bauen. Die schwierigere Frage ist: Soll diese API-Route überhaupt so existieren?

Er kann eine Datenbankstruktur erstellen. Ist das Datenmodell sinnvoll?

Er kann eine React-Komponente bauen. Ist das die richtige Abstraktion?

Er kann eine bestehende Funktion in fünf Dateien verändern. Ist das tatsächlich die Architektur, die wir langfristig wollen?

Früher musste ein Entwickler einen großen Teil seiner Zeit damit verbringen, eine Entscheidung technisch umzusetzen. Heute kann die technische Umsetzung teilweise innerhalb weniger Minuten erfolgen. Das macht die Entscheidung selbst nicht weniger wichtig. Im Gegenteil.

Wenn eine falsche Implementierung früher einen halben Tag gekostet hat und heute zehn Minuten, wird es billiger, Fehler zu machen. Aber dadurch wird es nicht billiger, die falsche Architektur über Monate mitzuschleppen.

Das verändert auch die Bedeutung von Code-Reviews. Wir müssen weniger darauf achten, ob jeder einzelne Entwickler dieselbe Implementierungstechnik beherrscht. Dafür müssen wir besser verstehen, ob die Lösung in das System passt.

Specification wird zum neuen Engpass

Dasselbe passiert eine Ebene höher. Wenn die Umsetzung eines Features immer schneller wird, wird eine unklare Spezifikation relativ gesehen zum größeren Problem.

Was genau bedeutet „fertig“? Welche Nutzergruppe steht im Mittelpunkt? Was passiert bei einem Fehler? Welche Randfälle sind relevant? Welche Einschränkungen gibt es? Welche Lösung ist überhaupt gewünscht?

Wenn die Implementierung günstig wird, wird es plötzlich besonders teuer, schnell in die falsche Richtung zu implementieren.

Deshalb glaube ich, dass gute Specification wieder stärker als Engineering-Aufgabe verstanden werden muss. Nicht im Sinne von langen Dokumenten, die niemand liest. Sondern als präzise Beschreibung dessen, was erreicht werden soll, warum es erreicht werden soll und woran wir erkennen, dass es erreicht wurde.

Das ist übrigens auch einer der Gründe, warum ich die Entwicklung von KI-Agenten nicht einfach als „besseres Autocomplete“ sehe. Ein Autocomplete wartet auf eine konkrete Codezeile. Ein Agent braucht einen Kontext, ein Ziel, Regeln, Werkzeuge und Feedback. Je autonomer die Systeme werden, desto wichtiger wird die Qualität dieser Umgebung.

Design-Systeme werden zum Kontext für KI

Das gleiche Prinzip gilt für Design. Wenn KI Interfaces generiert, kann sie unglaublich schnell Komponenten und Layouts erstellen. Ohne ausreichenden Kontext entstehen aber leicht inkonsistente Lösungen: unterschiedliche Button-Varianten, uneinheitliche Abstände, neue Komponenten für Probleme, die bereits gelöst sind, oder einfach Interfaces, die zwar funktionieren, aber nicht nach der eigenen Marke aussehen.

Design-Systeme können hier eine wichtige Rolle spielen. Sie liefern nicht nur Farben, Abstände und Typografie. Sie beschreiben wiederverwendbare Komponenten, Regeln und gemeinsame Designentscheidungen.

Figma beschreibt genau diese Entwicklung inzwischen selbst: Design-Systeme werden zunehmend als Kontext verstanden, den KI-Agenten benötigen, um konsistenten und markengerechten Code zu erzeugen. Der Figma MCP Server kann dafür unter anderem Komponenten, Variablen und Layoutinformationen aus Figma in agentische Entwicklungsworkflows übertragen. Das ist ein wichtiger Schritt.

Aber ein Design-System allein löst das Problem nicht. Ein Interface kann die richtigen Komponenten verwenden und sich trotzdem komplett falsch anfühlen. Ein Agent muss nicht nur wissen, welcher Button verwendet werden soll. Er muss verstehen, welche Hierarchie, Dichte, Interaktionslogik und welcher Markencharakter beabsichtigt sind. Genau hier treffen sich für mich Frontend-Entwicklung und Design.

Und auch die Erstellung dieser Systeme verändert sich. KI kann heute bereits dabei helfen, Tokens, Komponenten und erste Regeln zu entwickeln. Figma beschreibt beispielsweise selbst Workflows, in denen KI aus bestehendem Code strukturierte Design-System-Regeln ableiten kann. Die Arbeit verschiebt sich damit teilweise vom manuellen Erstellen jeder einzelnen Variante hin zur Definition der Prinzipien, aus denen ein konsistentes System entstehen soll.

Das bedeutet nicht, dass Design weniger wichtig wird. Wenn die Erstellung von Interfaces günstiger wird, wird gutes Design eher wichtiger. Denn wenn jeder in wenigen Minuten ein funktionierendes Interface erzeugen kann, wird die Qualität der Entscheidungen zum Unterschied.

Testing wird automatisierbarer. Verification nicht.

Eine weitere Veränderung betrifft das Ende des Prozesses. Im Februar habe ich empfohlen, KI-generierten Code Zeile für Zeile zu reviewen. Diese Empfehlung bleibt für Lernende, kritische Änderungen und viele konkrete Situationen sinnvoll. Im Alltag skaliert sie aber nicht unbegrenzt, wenn ein Agent in kurzer Zeit große Mengen an Code erzeugt.

Die Lösung ist für mich nicht weniger Kontrolle, sondern eine andere Form der Kontrolle. Testing kann zunehmend automatisiert werden: Unit-Tests, End-to-End-Tests, visuelle Regressionstests und agentische Browser-Prüfungen. Aber ein bestandener Test beantwortet nicht jede relevante Frage.

Deshalb unterscheide ich für mich zwischen Testing und Verification.

Testing fragt: Funktioniert es gemäß den definierten Prüfungen?

Verification fragt: Ist es das Richtige?

Passt die Interaktion zur Marke? Ist der Flow für echte Menschen verständlich? Ist die visuelle Hierarchie stimmig? Ist die Seite auch unter realen Bedingungen zugänglich und benutzbar?

Ein automatisierter Check kann wichtige Fehler finden. Er ersetzt aber nicht automatisch das Verständnis der Produktabsicht. Die menschliche Abnahme wird dadurch nicht überflüssig. Sie verändert sich.

Wir prüfen nicht mehr zwangsläufig jede Codezeile mit derselben Intensität. Stattdessen müssen wir sicherstellen, dass unsere automatisierten Prüfungen sinnvoll sind und dass wir das Ergebnis auf der richtigen Ebene beurteilen.

Mehr KI bedeutet nicht automatisch mehr Produktivität

Das ist auch der Grund, warum ich bei pauschalen Aussagen über KI-Produktivität vorsichtig geworden bin.

Eine randomisierte METR-Studie aus 2025 untersuchte erfahrene Open-Source-Entwickler bei Aufgaben in ihnen vertrauten Repositories. In diesem konkreten Versuchsaufbau benötigten die Entwickler mit den damaligen KI-Tools 19 % mehr Zeit als ohne sie. Gleichzeitig hatten sie vorher eine Beschleunigung erwartet.

Das klingt zunächst wie ein Widerspruch zu meiner eigenen Erfahrung. Ist es aber nicht unbedingt. Die Studie untersucht einen bestimmten Zeitraum, bestimmte Entwickler, bestimmte Repositories und die damals verfügbaren Tools. METR weist selbst ausdrücklich darauf hin, dass daraus keine Aussage darüber folgt, ob KI die Mehrheit der Entwickler oder Softwarearbeit beschleunigt.

Und genau das ist für mich der interessante Punkt. Der Nutzen von KI hängt offenbar stark davon ab, wie wir sie einsetzen.

Auch die Stack Overflow Developer Survey 2025 zeigt diese Spannung: 84 % der Befragten nutzten KI-Tools oder planten deren Nutzung im Entwicklungsprozess. Gleichzeitig gaben 46 % an, den Ergebnissen nicht zu vertrauen. 66 % nannten „fast richtige“ KI-Lösungen als größte Frustration.

Die Frage ist also nicht nur, wie viel Code KI erzeugen kann. Die Frage ist, wie gut wir die Umgebung bauen können, in der sie arbeitet.

Breiter statt nur tiefer

Im letzten Artikel habe ich tiefe Spezialkenntnisse als wichtiges Differenzierungsmerkmal genannt. Das gilt weiterhin. Aber ich sehe inzwischen eine zweite Dimension, die mindestens genauso relevant wird: Breite.

Ein Agent, der ein Feature implementiert, arbeitet möglicherweise nicht nur an React-Komponenten. Er verändert API-Routen, Datenmodelle, Authentifizierung, SEO-Metadaten, Deployment-Konfigurationen oder andere Teile des Systems. Wer diese Änderungen verantwortet, muss nicht in jedem dieser Bereiche Spezialist sein. Aber er muss genug Verständnis mitbringen, um Zusammenhänge zu erkennen, Risiken einzuschätzen und Ergebnisse zu verifizieren.

„Ich mache nur Frontend“ wird dadurch nicht bedeutungslos. Aber die Grenzen des Frontends werden durchlässiger. Und vielleicht ist genau das eine der interessanteren Entwicklungen für Frontend-Entwickler. Wir werden nicht zwangsläufig zu schlechteren Spezialisten. Wir müssen nur zunehmend verstehen, was außerhalb unseres Spezialgebiets passiert, wenn wir eine Änderung anstoßen.

Also: Wie relevant bin ich 2026 und 2027 noch?

Die Antwort aus dem Februar bleibt im Kern bestehen: Die Relevanz hängt davon ab, wie wir uns an die veränderte Arbeit anpassen. Heute würde ich es allerdings konkreter formulieren.

Wenn ein großer Teil der Arbeit darin besteht, klar definierte Tickets in Code zu übersetzen, wird dieser Teil der Tätigkeit zunehmend automatisierbar. Das bedeutet nicht, dass Frontend-Entwicklung verschwindet. Es bedeutet, dass Codeproduktion allein immer weniger ein ausreichender Grund für die Rolle eines Entwicklers sein wird.

Wichtiger werden dafür Fähigkeiten wie:

• Anforderungen und Produktabsichten präzisieren
• Kontext und Arbeitsumgebungen für KI gestalten
• Architektur und Systemzusammenhänge verstehen
• Design-Systeme und Interaktionsprinzipien entwickeln
• automatisierte Prüfungen sinnvoll aufbauen
• Ergebnisse technisch, visuell und fachlich verifizieren

Das sind keine vollständig neuen Fähigkeiten. Gute Entwickler haben sie schon immer gebraucht. Aber ihre Gewichtung verändert sich.

Und vielleicht ist das die eigentliche Antwort auf die Frage, wie relevant mein Job in 2026 oder 2027 noch sein wird. Die Fähigkeit, Code zu produzieren, wird zunehmend weniger knapp. Die Fähigkeit zu wissen, welcher Code überhaupt produziert werden sollte, bleibt knapp.

Der Autopilot fliegt heute mehr, als ich im Februar erwartet hätte. Und vermutlich wird er in Zukunft noch mehr Aufgaben übernehmen. Aber wohin er fliegt, welchen Flugplan er bekommt und woran wir erkennen, dass er am richtigen Ziel angekommen ist, bleibt vorerst unsere Aufgabe.

Das Cockpit bleibt besetzt. Nur die Arbeit darin verändert sich.