Frontend Engineering
Architektur beantwortet wichtige Fragen.
Sie hilft dabei, Grenzen zu finden, Verantwortlichkeiten zu verteilen und Systeme so zu schneiden, dass sie langfristig veränderbar bleiben.
Damit allein entsteht aber noch keine gute Softwareentwicklung.
Ein sauber geschnittenes System kann trotzdem schlecht getestet sein. Ein gutes Design kann an einem unzuverlässigen Delivery-Prozess scheitern. Teams können sinnvolle Architekturentscheidungen treffen und trotzdem jeden Release mit Bauchschmerzen ausliefern.
Und selbst der beste Code hilft wenig, wenn niemand mehr weiß, wie man ihn sicher verändert.
Genau dort beginnt für mich Frontend Engineering.
Mehr als Code
Abschnitt betitelt „Mehr als Code“Frontend Engineering beschäftigt sich nicht nur damit, wie wir Code schreiben.
Es geht um das Handwerk rund um reale Frontend-Systeme: wie wir sie entwickeln, prüfen, ausliefern, beobachten, verändern und über längere Zeit zuverlässig betreiben.
Dazu gehören Themen wie Softwarequalität, Tests, Quality Gates, Code Reviews, CI/CD, Tooling, technische Governance und Entwicklungsprozesse. Aber auch Rollen, Zusammenarbeit und die Frage, wie Teams Entscheidungen treffen und Wissen weitergeben.
Vieles davon wirkt weniger spektakulär als ein neues Framework oder ein besonders cleveres Pattern.
Im Alltag entscheidet es trotzdem sehr oft darüber, ob ein System wirklich professionell entwickelt werden kann.
Das Handwerk um die Architektur herum
Abschnitt betitelt „Das Handwerk um die Architektur herum“Strategisches und taktisches Design beschäftigen sich mit dem System selbst.
Strategisches Frontend-Design fragt, wo Grenzen verlaufen und welche Teile eines Systems gemeinsam oder unabhängig wachsen sollen.
Taktisches Frontend-Design fragt, wie diese Grenzen und Verantwortlichkeiten im konkreten Code sichtbar werden.
Frontend Engineering betrachtet das Umfeld, in dem diese Entscheidungen dauerhaft funktionieren müssen.
Wie prüfen wir, ob eine Änderung wirklich korrekt ist? Welche Qualität wollen wir überhaupt erreichen? Welche Regeln sollten automatisiert werden? Wo reicht ein Code Review, und wo brauchen wir mechanische Verifikation? Wie verhindern wir, dass Wissen nur in den Köpfen einzelner Menschen existiert?
Und natürlich auch: Welche Werkzeuge helfen uns tatsächlich?
Denn Tooling ist dann interessant, wenn es Arbeit verbessert. Nicht nur, wenn es neu ist.
Professionelle Softwareentwicklung ist ein System
Abschnitt betitelt „Professionelle Softwareentwicklung ist ein System“Softwarequalität entsteht selten durch eine einzelne Maßnahme.
Ein Test allein macht noch keine gute Teststrategie. Ein Linter ersetzt kein Architekturverständnis. Eine Pipeline macht ein Team nicht automatisch schneller, und ein Quality Gate hilft wenig, wenn niemand versteht, warum die Regel überhaupt existiert.
Professionelles Engineering entsteht aus dem Zusammenspiel vieler kleiner Dinge.
Gute Werkzeuge helfen dabei. Klare Prozesse helfen ebenfalls. Automatisierung kann Fehler früh sichtbar machen. Reviews können Wissen verteilen. Dokumentation kann Entscheidungen nachvollziehbar halten.
Und manchmal ist die wichtigste Verbesserung weder ein neues Tool noch ein neues Pattern, sondern einfach eine klarere Verantwortung.
Frontend Engineering interessiert sich genau für dieses Zusammenspiel.
Auch Rollen gehören dazu
Abschnitt betitelt „Auch Rollen gehören dazu“Softwareentwicklung besteht nicht nur aus technischen Artefakten.
Menschen übernehmen unterschiedliche Rollen, haben unterschiedliche Stärken und betrachten dasselbe System aus unterschiedlichen Perspektiven.
Ein Senior Developer ist nicht automatisch ein Softwarearchitekt. Ein Architekt ist nicht automatisch der stärkste Entwickler im Team. Ein Tech Lead, Staff Engineer oder Solution Architect kann wiederum ganz andere Verantwortung tragen.
Solche Unterschiede sind nicht nur Karrierebezeichnungen.
Sie beeinflussen, welche Entscheidungen jemand treffen soll, welche Perspektive erwartet wird und wie Verantwortung im Team verteilt ist.
Deshalb sollen in diesem Bereich langfristig auch Rollen, Verantwortlichkeiten und Zusammenarbeit einen Platz bekommen.
Nicht als Organigramm-Theorie, sondern aus Sicht realer Entwicklungsarbeit.
Und dann kam AI
Abschnitt betitelt „Und dann kam AI“LLMs und Coding Agents sind inzwischen ein wichtiger Teil meiner eigenen Arbeit.
Ich halte sie weder für eine eigene Architekturschicht noch für einen vorübergehenden Nebeneffekt.
Sie sind Werkzeuge innerhalb von Software Engineering.
Sehr leistungsfähige Werkzeuge, aber eben Werkzeuge.
Sie verändern, wie schnell Code erzeugt werden kann, wie wir Informationen suchen, wie wir Anforderungen analysieren und wie viel Arbeit sich automatisieren lässt. Gleichzeitig verschieben sie die Bedeutung von Verifikation, explizitem Wissen und klaren technischen Grenzen.
Damit passen sie ziemlich genau in diesen Bereich.
Nicht als Hype-Thema, sondern als neue Realität im Werkzeugkasten.
Die erste größere Serie in diesem Bereich beschäftigt sich mit LLMs, Coding Agents und Agentic Work aus Sicht professionellen Software Engineerings.
Sie beginnt bei den Grundlagen von LLMs und Benchmarks und geht anschließend immer weiter in die praktische Arbeit mit Coding Agents. Dabei geht es um Context, Memory, Requirements, Architektur, Datenschutz, Verifikation, AI-friendly Software und die wirtschaftlichen Auswirkungen agentischer Arbeit.
Am Ende steht weniger die Frage, welches Modell gerade vorne liegt.
Interessanter ist, was sich verändert, wenn Code immer leichter erzeugt werden kann und andere Teile von Software Engineering dadurch wichtiger werden.
Die Serie versucht deshalb weder AI zu feiern noch kleinzureden.
Sie betrachtet das Werkzeug, seine Möglichkeiten und seine Grenzen möglichst dort, wo es am Ende auch eingesetzt wird: in echter Softwareentwicklung.
Worum es in diesem Bereich gehen soll
Abschnitt betitelt „Worum es in diesem Bereich gehen soll“Frontend Engineering soll langfristig die Themen aufnehmen, die zwischen Architekturdiagramm und produktivem Betrieb liegen.
Qualität und Verifikation. Delivery und Tooling. Entwicklungsprozesse. Large-Scale Applications. Technische Governance. Rollen und Verantwortung. Neue Werkzeuge und die Frage, welche davon tatsächlich helfen.
Nicht jedes Thema braucht dabei eine große Theorie.
Manchmal reicht eine gute Methode.
Manchmal ein verlässlicher Prozess.
Und manchmal einfach ein Werkzeug, das seinen Job macht, ohne daraus gleich eine neue Religion zu machen.