7 Min. Lesezeit
Futureware: Software Engineering Hypothesen zur Strategie 2030
Autoren: Dr. Josef Adersberger und Josef Fuchshuber
In der Ethnologie beschreibt ein „Rite of Passage“ den Übergang von einer Lebensphase in eine andere: Trennung vom Alten, eine unsichere Schwellenphase, schließlich die Wiedereingliederung in eine neue Rolle. Genau in einer solchen Schwellenphase befindet sich das Software Engineering gerade.
Die alten Regeln gelten nicht mehr vollständig. Die neuen sind noch nicht stabil.
Cloud, agile Produktentwicklung und DevOps haben die vergangenen Jahre geprägt. Jetzt befinden wir uns am Anfang der nächsten Phase: Generative und Agentic AI. Und diese Phase ist kein gewöhnlicher Toolwechsel. Sie verändert, wie Software entsteht, wer Software gestalten kann und welche Kompetenzen im digitalen Unternehmen künftig benötigt oder knapp werden.
Wir haben sieben “Futureware” Thesen im Rahmen einer Keynote auf unserem jährlichen QAware Engineering Camp aufgestellt. Die Hypothesen beziehen sich nicht unbedingt auf technische Vorhersagen, sondern auf die transformative Kraft der AI-Technologie. So wie PC, Internet, Smartphone und Cloud zuvor neue Märkte, Geschäftsmodelle und Organisationsformen ermöglicht haben, so macht das nun Agentic AI.
Die entscheidende Frage lautet nicht:
Wie viel Code kann KI erzeugen?
Sondern:
Welche Organisationen sind in der Lage, diese Technologie in Wirkung zu übersetzen?
Denn genau daran entscheidet sich der Unterschied zwischen KI-Theater und echter Transformation.
Hypothese #1: Gewinnen werden Organisationen, die transformative Technologien wirksam einsetzen

Transformative Technologien entwickeln sich schneller als Organisationen. Die technische Leistungsfähigkeit wächst in frühen Phasen oft exponentiell. Die Fähigkeit einer Organisation, diese Technologie sinnvoll, sicher und verantwortungsvoll einzusetzen, wächst dagegen meist linear. Dadurch entsteht Technologiespannung.
Diese Spannung ist der emotionale Grundton der aktuellen KI-Debatte, allgemein und auch im Software Engineering.
Sie kann negativ werden: FOMO, hektische Pilotprojekte, Hyperaktivität, Überforderung, Resignation oder die Flucht in die Abhängigkeit von technologischen Schutzmächten. Dann wird viel ausprobiert, viel kommuniziert und viel lizenziert – aber wenig verändert.
Sie kann aber auch positiv werden: Aufbruchsstimmung, Freude am Lernen, konkrete Produktivitätsgewinne und echte Differenzierung vor dem Kunden. Dann wird KI nicht als Selbstzweck eingeführt, sondern dort angewendet, wo es am meisten wehtut und am meisten wirkt: im Kerngeschäft.
Die Gewinner sind deshalb nicht die lautesten Organisationen. Es sind die „entspannt-konsequenten“. Entspannt, weil sie nicht jedem Hype hinterherlaufen. Konsequent, weil sie die Technologie nicht in Innovationsfolklore parken, sondern in den Maschinenraum des Unternehmens bringen.
Hypothese #2: Individualsoftware wird eine Renaissance erleben
Die vielleicht spannendste These lautet: Wir erleben eine Renaissance der Individualsoftware.
Das wirkt zunächst kontraintuitiv. Seit Jahren dominieren Standardsoftware, SaaS und Plattformökonomie die IT-Strategien großer Unternehmen. Individualsoftware galt oft als teuer, riskant, wartungsintensiv, oder ihr Entwicklungszeitraum als zu lang – Unternehmen bevorzugten oft eine risikoärmere Standardisierung gegenüber Differenzierung.
Doch Agentic AI verändert die ökonomische Gleichung.
Noch nie war die Eintrittsschwelle zu einer transformativen Technologie so niedrig. Noch nie waren die Werkzeuge so leistungsfähig. Und noch nie war die Distanz zwischen einer Idee und laufender Software so klein. Wir erleben gerade die Demokratisierung von „Idea to Code and Running Software“.
Damit verschiebt sich die alte „Build or Buy“-Logik. Aus der Frage „Kaufen oder bauen?“ wird zunehmend: „Customize or Compose“.
Unternehmen werden nicht mehr nur zwischen Standardsystem und Individualentwicklung wählen. Sie werden Plattformen, APIs, Datenprodukte, Workflows, KI-Agenten und domänenspezifische Erweiterungen kombinieren. Das Ergebnis sieht von außen oft wie Individualsoftware aus – ist aber innen stärker komponiert als klassisch gebaut.
Das verändert auch den Markt.
Klassische Individualentwicklung und langlaufende Transformationsprogramme stehen weiterhin unter Druck. Gleichzeitig entstehen neue Bedarfe in IT-Organisationen: Architekturberatung, Plattformaufbau, Risk- und Security-Audits, Modernisierung von Altsystemen und die Fähigkeit, kritische Systeme in eine „Customize or Compose“-Welt zu überführen. Unser Wert als IT-Dienstleister für unsere Kunden verschiebt sich von „Wir bauen für euch" hin zu „Wir befähigen euch – und übernehmen Verantwortung für kritische Systeme".
Hypothese #3: Software Engineering ist der Vorreiter im Agentisierungs-Change
Der Wandel ist da – und er tut auch ein bisschen weh. Der “Engineering Handwerksstolz" muss neu interpretiert werden. Wer früher mit Begeisterung täglich viel Code geschrieben hat, hat heute Agenten dafür. Wir Software Engineers sind mittendrin im “Wheel of Change” – Vorahnung, Schock, Verneinung, Einsicht, Akzeptanz, Ausprobieren, Integration – das durchläuft gerade unsere ganze Branche. Ungeschönt.
Und genau das ist die These: Software Engineering ist die Branche, die Agentisierung jetzt tief am eigenen Leib erlernt. Die Anthropic-Studie "Measuring AI agent autonomy in practice" aus dem Februar 2026 zeigt es deutlich: Rund 50 Prozent aller Agent-Tool-Calls stammen gerade aus dem Bereich Software Engineering – ein langer Balken weit vor allen anderen Domänen.

Quelle: Anthropic Studie, 18.2.2026, Measuring AI agent autonomy in practice
Andere Branchen folgen erst noch. Und das ist gut so, dass unsere Branche als Keimzelle der Digitalisierung, auch hier eine Vorreiterrolle übernimmt. Denn was wir jetzt im Software Engineering lernen – die Change-Mechanik, die emotionalen Ups und Downs, die technischen Patterns – wird in den nächsten Jahren zur Exportware für den Agentic-AI-Change in anderen Domänen.
Wer schon mal selbst im „Wheel of Change“ war, wird viel eher zur richten Zeit die richtigen Fragen stellen:
- Creating: Was müssen wir neu erschaffen?
- Preserving: Was müssen wir bewahren?
- Eliminating: Was ist blockierend und muss weg?
- Accepting: Was können wir nicht ändern und müssen es akzeptieren?
Creating und Preserving richten den Blick auf das Wertvolle. Eliminating und Accepting helfen, realistisch mit dem umzugehen, was belastet oder nicht mehr steuerbar ist.
Das klingt fast therapeutisch. Ist aber harte Transformationsarbeit.
Hypothese #4: Wir sehen unterschiedliche Reifegrade und Geschwindigkeiten gleichzeitig

Die KI-Transition wird nicht synchron verlaufen. Wir unterscheiden sechs Stufen – von Level 0 (digitalisiert) über assistiert, teilautomatisiert, hochautomatisiert, vollautomatisiert bis hin zu Level 5 (autonom), wo der Mensch nur noch als Kunde und letzte Autorität auftritt.
Im Software Engineering ist heute noch nicht klar, welches Level in welchen Bereichen in der Zukunft möglich sein wird und darf.
Jedes neue Software-Vorhaben startet in einem anderen Kontext. Wo ist der Einstiegspunkt? Agiert man in einem Startup oder im Konzern? Wie reguliert ist die Branche (Banking, Insurance, Pharma)? Wie komplex sind die Kernprozesse? Wie steht es um Datenlage, Technikreife, Mitarbeiterkompetenzen. Manche fangen bei Level 3 an, andere stehen noch bei „minus eins" und arbeiten noch an ihrer Digitalisierung. In größeren Firmen werden wir also in unterschiedlichen Bereichen auch unterschiedliche Start- und End-Level sehen.
Hinzu kommt, dass die Bereiche sich mit unterschiedlichen Geschwindigkeiten verändern werden. Bildlich gesprochen, ist unsere Aufgabe im Software Engineering, diese Change-Zahnräder zu synchronisieren. Große, langsame Räder und kleine, schnelle dürfen sich nicht gegenseitig blockieren.
Was heute schon im Customer Service einer Versicherung möglich ist, kann nicht einfach auf die Entwicklung der Kernsysteme übertragen werden. Es braucht eine Übersetzung.
Hypothese #5: Produktivität ist nichts ohne Qualität
Die aktuelle KI-Debatte ist stark von Produktivität geprägt. Mehr Output. Schnellere Umsetzung. Weniger Aufwand. Mehr Features pro Sprint.
Das ist verständlich. Aber im Software Engineering war Output noch nie gleich Wert.
Mehr Code ist kein Fortschritt, wenn er das falsche Problem löst. Mehr Features helfen nicht, wenn sie schlecht integriert sind. Mehr Automatisierung ist gefährlich, wenn niemand mehr versteht, was automatisiert wurde.
Um es auf den Punkt zu bringen: Produktivität ist nichts ohne Qualität. Denn Produktivität ohne Qualität baut den Qualitätsschuldenberg, aus technischen und fachlichen Schulden, nur schneller auf und führt schneller in den Softwarebankrott. KI kann die reinen Erzeugungskosten senken. Aber sie senkt nicht automatisch die kompletten Lifecycle-Kosten einer Software.
Das Spannende an der Qualitätsfrage ist der menschliche Faktor: Schlechte KI-Ergebnisse sind nicht primär ein technisches Problem. Die Qualität des KI-Outputs korreliert vielmehr stark damit, wie gut der instruierende Mensch selbst klar denken und schnell lernen kann. Ein Bericht von Anthropic bringt dies treffend auf den Punkt: „How humans prompt is how Claude responds“.
Für die IT-Teams der Zukunft bedeutet das einen wichtigen Perspektivwechsel: Es geht nicht um die klassische Diskussion „Junior vs. Senior“. Der wahre Erfolgsfaktor für herausragendes Software Engineering ist die Qualität des Denkens und Lernens. Wir brauchen Fachkräfte, die in der Lage sind, präzise zu denken, schnell zu lernen, sich ein solides Urteil zu bilden – und die Softwarequalität trotz sehr kurzer Entwicklungszyklen kompromisslos in den Mittelpunkt rücken.
Hypothese #6: Größere Unternehmen brauchen AI-native Anwendungslandschaften

AI wird die Anwendungslandschaft in Unternehmen grundlegend verändern: sowohl den Zugang zu Anwendungen als auch die Verantwortung für fachliche Lösungen. Die User werden zukünftig immer seltner über klassische UI (z.B. Web- oder Smartphone-App) einzelner Anwendungen auf Systeme zugreifen, sondern über Chats, Voice Interfaces, Assistenten und Agenten. Gleichzeitig entsteht darüber eine stark vertikalisierte Anwendungsschicht, die näher an den Fachbereichen und ihren konkreten Prozessen.
Das verändert die Rolle von Kernsystemen und zentralen SaaS-Produkten. Sie bleiben relevant, werden aber konsequenter nach dem Clean-Core-Prinzip eingesetzt: stabil im Kern, erweiterbar an den Rändern. In AI-nativen Anwendungslandschaften behalten diese System ihre Daten- und Transaktionshoheit. Darüber entstehen konversationelle Benutzeroberflächen, Assistenten, Agenten, Analysen, Workflows und vertikale Lösungen für einzelne Fachdomänen. Die Kernsysteme werden “headless”. Sie werden zukünftig von anderen Softwaresystemen bedient und nicht mehr von Menschen die mit Maus und Keyboard vor einem Monitor sitzen.
Damit das funktioniert, braucht es Plattformen: Datenplattformen, KI- und Automatisierungsplattformen, Entwicklungsplattformen, APIs, Governance und klare Qualitätsstandards.
Die Rolle der IT verändert sich damit grundlegend. Sie ist nicht mehr nur Lieferorganisation. Sie wird Plattform-Provider, Enabler und Hüter technischer Qualität. Fachbereiche können eigene vertikale Lösungen entwickeln und weiterentwickeln – aber auf einem Fundament, das Sicherheit, Integration, Wartbarkeit und Skalierbarkeit sicherstellt.
Das ist der eigentliche Architekturshift. Es braucht keine einzelnen Abteilungen, die isoliert mit KI experimentieren. Der wirkliche Fortschritt entsteht dann, wenn eine Organisation die Voraussetzungen schafft, damit viele Menschen KI wirksam, verantwortungsvoll und skalierbar einsetzen können – durch klare Leitplanken, gemeinsame Plattformen und definierte Verantwortlichkeiten.
Freiheit braucht Infrastruktur. Sonst ist sie nur Chaos mit verbesserter User Experience.
Hypothese #7: Für das AI4SE-Flywheel und den „New Handwerksstolz" verschieben sich die Kernkompetenzen
Viele Organisationen werden in den kommenden Jahren viel Energie in KI-Tooling investieren. Das ist richtig. Wer moderne Werkzeuge nicht praktisch versteht, kann ihre Potenziale und Grenzen nicht beurteilen. Aber Tool-Kompetenz hat kurze Halbwertszeit. Das heute beeindruckende Tool ist morgen Basisfunktion, übermorgen Commodity und in drei Jahren vielleicht ein Screenshot in einer nostalgischen Keynote.
Der neue Handwerksstolz im Software Engineering wird deshalb nicht allein aus Prompting, Agentic Coding oder Toolchain-Optimierung entstehen. Er wird auf Kompetenzen beruhen, die länger tragen: Urteilskraft, Problem- und Domänenverständnis, Orchestrierung, Beratungs- und Transformationskompetenzen. Urteilskraft heißt: Qualität bewerten, Risiken erkennen, gute von schlechten (KI-)Ergebnissen unterscheiden und Verantwortung übernehmen. Problem- und Domänenverständnis bedeuten: echte Kundenprobleme erkennen, Anforderungen schärfen, Fachlichkeit modellieren und relevanten Kontext herstellen. Orchestrierung und Integration bedeuten: Menschen, KI-Agenten und Systeme zusammenspielen lassen, Arbeit zerlegen, delegieren, absichern und Ergebnisse integrieren. Beratung und Transformation bedeuten: Orientierung geben, Zielbilder entwickeln, Veränderung begleiten und neue Arbeitsweisen im Unternehmen verankern.
Das Berufsbild verschiebt sich damit. Aber nicht vom Menschen zur Maschine, sondern vom reinen Umsetzen zum verantwortlichen Gestalten. Der neue Stolz liegt nicht darin, möglichst viel Code selbst geschrieben zu haben. Er liegt darin, wirksame Lösungen entstehen zu lassen – schnell, sauber, anschlussfähig und nah am echten Problem.

Agentic Coding verändert sowohl die Tätigkeiten, als auch den Takt der Softwareentwicklung. Wenn Lösungsinkremente künftig in Minuten statt Tagen oder Wochen entstehen können, verschiebt sich der Engpass. Dann ist nicht mehr die reine Umsetzung knapp, sondern die Fähigkeit, Potenziale zu erkennen, Probleme zu verstehen, gute Lösungen abzuleiten und aus den Ergebnissen schnell zu lernen.
Genau das beschreibt das AI4SE-Flywheel: Potenzial erkennen, Problem verstehen, Lösung ableiten, Lösungsinkrement entwickeln, vom Inkrement lernen. Daraus folgen organisatorische Konsequenzen.Teams werden kleiner. Drei bis fünf Personen können künftig mehr Wirkung entfalten als große, schwerfällige Projektapparate. Programme werden schlanker. Rollen-Bloat verliert an Legitimation. Dauerhafte Produktverantwortung wird wichtiger als projektförmige Übergaben.
Das ist für viele Organisationen unbequem. Denn viele IT-Strukturen wurden gebaut, um Knappheit zu verwalten: knappe Entwicklungskapazität, knappe Releasefenster, knappe Fachbereichsverfügbarkeit. Wenn Umsetzung schneller und günstiger wird, werden diese Strukturen nicht automatisch effizienter. Sie können selbst zum Engpass werden. Der künftige Flaschenhals liegt näher am Endkundenproblem und näher an der Fachlichkeit.
Fazit: Die Zukunft gehört den entspannt-konsequenten Organisationen
Das goldene Zeitalter der Individualsoftware beginnt nicht, weil plötzlich alle wieder alles selbst bauen sollten. Es beginnt, weil sich die Bedingungen verändern. Ideen lassen sich schneller in Software übersetzen. Fachbereiche können näher an der Lösung arbeiten. Plattformen ermöglichen neue Formen der Komposition. KI-Agenten übernehmen Teile der Umsetzung. Gleichzeitig steigen die Anforderungen an Qualität, Integration, Sicherheit, Verantwortung und Domänenverständnis.
Damit wird Software Engineering nicht weniger wichtig. Es wird strategischer. Die Zukunft gehört Organisationen, die drei Dinge gleichzeitig schaffen:
- Sie erzeugen positive Technologiespannung statt hektischer KI-FOMO.
- Sie ermöglichen Individualisierung, ohne in Schatten-IT und Integrationschaos zu kippen.
- Sie entwickeln einen neuen Handwerksstolz, der Wirkung, Qualität und Verantwortung über reine Toolbeherrschung stellt.
Dieser Rite of Passage ist kein gemütlicher Übergang. Er ist eine Schwellenphase. Alte Routinen verlieren an Kraft, neue Routinen müssen erst entstehen. Aber genau darin liegt die Chance. Software Engineering kann jetzt lernen, was viele andere Branchen erst noch lernen müssen: wie Menschen, KI-Agenten und Organisationen so zusammenspielen, dass nicht nur mehr Output entsteht – sondern bessere Wirkung.
Die entscheidende strategische Frage darf deshalb nicht lauten: „Wie viel KI setzen wir ein?“. Viel besser ist: „Welche Fähigkeit bauen wir auf, um mit KI unser Kerngeschäft besser zu machen?“
Ein Beitrag von
Mehrere Autoren
Dieser Artikel wurde von mehreren Autoren verfasst. Weitere Informationen zu den einzelnen Mitwirkenden finden Sie im Artikel. [...]