Wird Spring Boot obsolet?

Im März 2026 starteten wir in ein Modernisierungs-Projekt bei einem Kunden. Spring Boot war eine übliche Wahl. Es gab eine strategische Setzung. Es gab vorhandenes Know-how. Es gab bestehende Infrastruktur. Das Team stand. Die Arbeit lief an.

Einer der Kollegen brachte allerdings eine ungewöhnliche Ausgangslage mit. Er hatte kaum Berührungspunkte mit Java. Er hatte noch nie mit Spring (Boot) gearbeitet.

Früher wäre das ein ernstes Problem gewesen. Ich hätte gesagt, es hätte nicht funktioniert. Ein Ramp-up über mehrere Wochen wäre nötig gewesen. Vielleicht ein Mentor, der ihn durch die ersten Sprints trägt. Seine ersten Features wären langsam gekommen.

Stattdessen passierte etwas anderes. Mit KI-Assistent an seiner Seite begann er sofort zu liefern.

Das brachte mich ins Grübeln. Jemand ohne Java-Background lieferte in Tagen produktiven Code in einem Spring Boot Projekt. Hat das Konsequenzen?

Wird Spring Boot obsolet?

Nein

Natürlich wird Spring Boot nicht obsolet. Es ist ein hervorragendes Framework. Es wird weiterentwickelt. Unzählige Anwendungen laufen damit in Produktion.

Was sich verändert, ist die Verteilung von Framework-Wissen im Team. Bisher musste praktisch jede Entwicklerin den Stack im Detail beherrschen. Wer entwerfen wollte, musste auch bauen können. Diese Kopplung löst sich immer mehr. Tiefe bleibt nötig. Aber sie verschiebt sich nach oben. Den Rahmen abzustecken wird wichtiger. Reine Umsetzung übernimmt zunehmend die KI. Konkret wandert diese Arbeit in den Harness. Dort steht festgeschrieben, was gute Architektur und Qualität für uns bedeuten. Den Code darunter schreibt die KI.

Harness Engineering: unser Sicherheitsnetz

Wir sind erfahrene Senior-Engineers mit jahrelanger Praxis mit einem geschulten Blick für die typischen Fallen. Von Anfang an haben wir ein straffes Sicherheitsnetz gebaut. ArchUnit-Regeln lassen Architekturverstöße beim Build durchfallen. Eine umfassende Test-Suite läuft mit. Statische Codeanalyse spürt Code-Smells und typische Fehlermuster auf. Security-Scans warnen uns vor verwundbaren Dependencies und Code-Schwachstellen. Anforderungen an die Observability machen jede Abweichung in Produktion sichtbar.

All das läuft nicht erst in der CI. Es steht dem KI-Assistenten direkt in der Entwicklung als Feedback zur Verfügung. So sieht die KI jeden Verstoß sofort. Sie reagiert darauf. Sie macht es richtig.

Genau deshalb konnte der Kollege sofort liefern. Nicht weil er über Nacht zum Experten geworden war. Sondern weil die KI im Schutz des Netzes Code liefern konnte.

KI-Assistenten sind stochastisch. Sie halluzinieren. Immer. Manche Halluzinationen treffen zufällig die Wirklichkeit, andere nicht. Deshalb misstrauen wir ihrem Output grundsätzlich. Unser Sicherheitsnetz ist so gebaut, dass die guten Ideen durchkommen. Der Rest fliegt auf, bevor er teuer wird. Genau hier liegt die Trennlinie zwischen „KI-Assistenz funktioniert" und „funktioniert nicht": KI glänzt dort, wo wir automatisiert verifizieren können.

Der Shift: was sich verändert hat

Damit ist gesagt, was der Harness leistet. Bleibt die Frage, was das mit uns macht. Mit denen, die bisher jede Codezeile selbst geschrieben haben.

Bisher war unsere Hauptarbeit an der Tastatur. Frameworks im Detail beherrschen. Aus hunderten APIs die richtigen auswählen und sauber zusammenführen. Eine Konfiguration aufsetzen, die unter Last trägt. Wer das schnell und sauber konnte, war wertvoll. Es war ein Handwerk. Die Beherrschung dieses Handwerks war ein gangbarer Karriereweg, oft jahrelang.

Diese Arbeit übernimmt jetzt die KI. Sie schreibt immer mehr den Code.

Was bleibt da für uns?

Architektur. Wo ziehen wir die Grenzen zwischen Komponenten? Welche Datenflüsse soll das System haben? Welche Verträge zwischen Modulen? Welcher Persistenz-Ansatz? Welcher Kommunikationsstil? Auch hier hilft die KI mit. Sie skizziert Varianten. Sie vergleicht Pattern. Sie deckt Edge Cases auf, die du übersehen hast. Aber die Entscheidung, welche Architektur tragfähig ist, trifft sie nicht. Die bleibt bei dir. Sie ist irreversibel teuer, wenn sie falsch fällt. Und sie verlangt ein mentales Modell davon, wie Systeme unter Last funktionieren. Erfahrung, die sich nicht aus einer Doku ziehen lässt.

Produkt. Was soll das System eigentlich tun? Welches Problem löst es für wen? Was sagt der Kunde, dass er braucht? Was braucht er wirklich? Wo liegt der Unterschied? Das ist die Ebene, auf der Software entsteht oder scheitert. Die KI hilft auch hier mit. Sie spielt Optionen durch. Sie strukturiert Anforderungen. Sie deckt blinde Flecken auf. Aber die Entscheidung trifft sie nicht. Welches Problem das richtige ist, das bleibt bei dir. Am Tisch mit dem Kunden. Nachfragend. Urteilend.

Plattform und Harness. In welchen Leitplanken soll die KI arbeiten? Welche Architekturregeln machen wir maschinell durchsetzbar? Welche Tests sind das Minimum? Welche Schwellen für Performance, Security und Coverage ziehen wir? Diese Ebene gab es früher in dieser Form nicht. Heute entscheidet sie darüber, ob KI-Assistenz im Team funktioniert. Oder ob sie still im Hintergrund Schaden anrichtet.

Urteilsvermögen. Diese Fähigkeit läuft quer durch alle drei Ebenen. Du musst die Grenzen und Schwächen der KI im Gefühl haben. Zwei Muster sind besonders wichtig. Erstens: Ihr Output sieht besser aus, als er ist. Code, der kompiliert, Tests grün hält und unter Last trotzdem umkippt. Zweitens: Sie ist zustimmend von Natur aus. Sie widerspricht selten, wo sie sollte. Wer beides nicht erkennt, lässt sich von plausiblem Output in falsche Sicherheit wiegen.

Wo die Tiefe gebündelt sein muss

Bleibt die Frage, wo die Tiefe gebraucht wird. Drei Bereiche fallen mir konkret ein. Es sind die Stellen, an denen das Sicherheitsnetz selbst entsteht oder reißt.

Verantwortung übernehmen. KI kann beraten. Verantworten kann sie nicht. Bei Entscheidungen, die nicht rückgängig zu machen sind, reicht eine plausible Empfehlung nicht aus. Du brauchst jemanden, der sie wirklich versteht und einordnen kann. Outage, Security-Incident, datenkritische Migration. In solchen Momenten brauchst du Tiefe im Stack. Du löschst Daten. Du ziehst einen Failover. Du rollst einen Patch hot aus. Da reicht es nicht, der KI hinterherzulaufen.

Den Harness bauen. Ein Sicherheitsnetz ist nur so gut wie das Wissen über die Fallen, die es abfangen soll. Wer den Stack nicht kennt, kann nicht antizipieren, was schiefgehen wird. Und ein Harness, der die wichtigen Fallen nicht abdeckt, ist gefährlicher als gar keiner. Er suggeriert Sicherheit, wo keine ist. ArchUnit-Regeln formulieren, Test-Strategie aufsetzen, Schwellen kalibrieren. Das geht nur mit Tiefe im jeweiligen Framework.

Wo Verifikation an ihre Grenze stößt. Nicht alles lässt sich automatisiert prüfen. Manche Fehlermuster zeigen sich erst unter Produktionslast. Andere nur in seltenen Timing-Situationen. Wieder andere sehen plausibel aus. Kein Test erkennt sie als Fehler. Eine Race Condition etwa. In tausend Test-Durchläufen bleibt sie unauffällig. In Produktion tritt sie zuverlässig auf. Tests grün, Code kaputt. Wo der Harness nicht hinreicht, brauchst du jemanden, der den Stack runter lesen kann. Nicht jemanden, der gut prompten kann.

Für die einzelne Entwickler:in verschiebt sich der Sweet Spot. Sie muss nicht jede Annotation kennen. Sie muss aber verifizieren können, ob die KI-Lösung korrekt ist. Und sie muss erkennen, wann sie an die Grenze ihres Harness kommt.

Fundamentales Verständnis schlägt API-Wissen. „Wie funktioniert das Internet?" ist die wichtigere Frage als „Wie konfiguriere ich eine Spring-Boot-Security-Filter-Chain?" Die erste gibt dir ein mentales Modell, das jede Web-Technologie trägt. Die zweite schlägt dir eine KI in Sekunden nach.

Kein Abgesang, sondern ein Upgrade

Mein Kollege vom Anfang dieses Texts liefert weiter. Ohne Spring-Boot-Hintergrund. Mit KI-Unterstützung. Im Schutz eines Harness, den jemand anders mit Tiefe gebaut hat. Das funktioniert nicht, weil Framework-Wissen plötzlich egal wäre. Es funktioniert, weil sich die Verteilung dieses Wissens verändert hat. Einige bauen den Harness, in dem KI-Geschwindigkeit überhaupt erst sicher wird. Andere arbeiten mit KI-Unterstützung darin. Sie liefern schneller, als wir es noch vor zwei Jahren für möglich gehalten hätten.

Teams werden dadurch kleiner und anders zusammengesetzt. Ein, zwei mit Tiefe im Stack. Der Rest breiter aufgestellt. Wer weniger Zeit mit Framework-Reibung verbringt, gewinnt Zeit. Zeit für die Frage, was das System eigentlich leisten soll. Also näher am Produkt. Und für den Einzelnen verschiebt sich der Lerneinsatz. Nicht der nächste Spring-Boot-Workshop. Sondern Architektur, System Design, Testing-Strategien, verteilte Systeme. Das sind die Skills, die in zehn Jahren noch relevant sind. Unabhängig vom Framework.

Spring Boot ist nicht obsolet. Obsolet wird, dass jeder im Team das Framework im Detail beherrschen muss, um produktiv damit zu arbeiten. Was zählt, sind gute Engineering-Skills. Ein mentales Modell davon, wie Software funktioniert. Die richtigen Fragen stellen können. Ergebnisse verifizieren. Egal mit welchem Framework. Egal in welcher Sprache.