Bei einem großen Kunden von uns läuft seit über zwei Jahren ein groß angelegter KI-Change in der IT. Hackathons, KI-Champions, Learning-Formate, Proof of Concepts, ein eigenes Enablement-Team — und natürlich die Werkzeuge selbst. Claude, Copilot, eine interne KI-Plattform. Bei den Entwicklern hat sich das mittlerweile gesetzt, alle drei werden täglich genutzt.
Vor ein paar Monaten wurde Claude Enterprise auch für die Business Analysten freigeschaltet. Große Ankündigung, eigener Roll-out, sogar ein dedizierter Kanal in Teams. Nach einem Tag war der Zugang wieder weitestgehend zurückgedreht — Datenschutzbedenken. Bei den Entwicklern, die mit denselben Werkzeugen seit zwei Jahren produktiv arbeiten, hatte sich diese Frage nie in dieser Schärfe gestellt.
Das ist kein Einzelfall. Es ist das Muster.
Über die Zukunft des Entwicklers wird seit zwei Jahren auf jeder Konferenz, in jedem zweiten LinkedIn-Post und in mindestens drei Blogartikeln pro Woche nachgedacht. Über die Zukunft der Berufsgruppe, die mit Entwicklern am selben Tisch sitzt, redet kaum jemand: Business Analysten. Nicht, weil die Frage uninteressant wäre. Eher, weil sie im Schatten der lauteren Entwicklerdebatte verschwindet.
Das ist eine merkwürdige Schieflage. Denn wer sich anschaut, was KI in Entwicklerteams verändert, sieht ein Muster, das sich nicht auf Codierung beschränkt. Es betrifft das, was vor dem Code passiert: fachliche Klärung, Strukturierung, Übersetzung, Spezifikation, Priorisierung. Also genau das, was Business Analysten den ganzen Tag tun.
Die erste Welle der KI-Debatte traf die Entwickler. Die zweite trifft die Menschen, die Arbeit vor dem Code strukturieren. Und es ist eine Ironie dieses Artikels, dass er Business Analysten in den Mittelpunkt stellen soll — hierbei jedoch zuerst (einmal mehr) Entwickler in den Mittelpunkt stellt.
Was wir über Entwickler wissen
Es folgt ein kurzer Marsch durch die Studienlandschaft. Wer keine Lust auf Prozentzahlen und Stichprobengrößen hat, darf gerne überspringen — die Pointe folgt am Ende des Abschnitts. Wer mitliest, sieht eine dichte und gleichzeitig widersprüchliche Datenlage.
Die berühmteste Zahl stammt aus einer der frühen Studien: GitHub und Microsoft ließen 2023 in einem kontrollierten Experiment 95 Entwickler einen HTTP-Server schreiben, einmal mit Copilot, einmal ohne. Die KI-Gruppe war 55,8 % schneller [1]. Ich habe diese Zahl vermutlich zehn Mal selbst in eigenen Folien zitiert, immer mit ein wenig schlechtem Gewissen — denn die Studie hat einen Schönheitsfehler: Sie gilt für eine standardisierte Greenfield-Aufgabe, nicht für die Realität gewachsener Codebasen.
Wer differenzierter hinsieht, findet differenziertere Zahlen. McKinsey misst je nach Aufgabentyp Zeitgewinne zwischen 50 und 60 % bei Dokumentation und Refactoring, aber nur etwa 10 % bei komplexeren Aufgaben [3].
Die Studie, an der ich seither nicht mehr vorbeikomme, wenn das Thema im Raum steht, ist eine andere. Das Forschungsinstitut METR hat 2025 ein randomisiertes Kontrollexperiment mit 16 erfahrenen Open-Source-Entwicklern in deren eigenen Repositories durchgeführt. Die Erwartung der Teilnehmer vor dem Experiment: KI macht sie 24 % schneller. Das gemessene Ergebnis: KI machte sie 19 % langsamer [4]. Und das, was ich für die eigentliche Pointe halte: Nach dem Experiment glaubten die Teilnehmer immer noch, KI habe sie 20 % schneller gemacht. Sie konnten den eigenen Geschwindigkeitsverlust nicht spüren.
Eine der in meinen Augen belastbarsten und aktuellsten Studien zu diesem Thema haben Fiona Chen und James Stratton im Januar 2026 an der Harvard University vorgelegt. Sie werten rund 200 Millionen Arbeitsereignisse von 100.000 Entwicklern aus 500 Unternehmen aus — gewonnen aus der direkten Telemetrie der Engineering-Plattform Jellyfish, kombiniert mit einem methodisch sauberen Vergleich von Firmen, die KI-Tools zu unterschiedlichen Zeitpunkten eingeführt haben [2].
Die Befunde zur Produktivität sind moderat: 8,5 % mehr Coding-Aktivität, 8,7 % schnellere Aufgaben-Erledigung, bei unveränderter Code-Qualität. Bemerkenswert ist allerdings, was die Studie nicht findet: keine signifikante Veränderung des Outputs pro Firma, keine Verschiebung zwischen Coding- und Nicht-Coding-Aufgaben, keine messbaren Beschäftigungseffekte — weder insgesamt noch differenziert nach Senioritätsstufe. Der individuelle Produktivitätsgewinn übersetzt sich nicht sichtbar in Firmen-Output und nicht in einen Arbeitsmarkteffekt. Wo er versickert, ist eine der offenen Fragen der aktuellen Forschung.
Die Datenbasis von Chen und Stratton umfasst den Zeitraum von Januar 2022 bis Juni 2025 — also eine Phase, in der sich wirklich agentische Softwareentwicklungsprozesse erst langsam entwickelt haben. Es mag angesichts der Geschwindigkeit dieser Entwicklung fast absurd klingen, dass eine Datenlage, die kein Jahr alt ist, veraltet sein könnte. Aber für mich steht die Veröffentlichung von Claude Opus 4.5 im November 2025 sinnbildlich für einen weiteren Übergang: weg vom punktuellen Coding-Assistenten, hin zu länger und autonomer laufenden, agentischen Arbeitsprozessen. Ich bin gespannt, ob neuere Zahlen ein anderes Bild zeigen werden.
Wer die vier Studien nebeneinanderlegt, sieht den Widerspruch in einer Bewegung:
Der Markt selbst zeigt zwei Bewegungen, die sich auf den ersten Blick widersprechen. Die Adoption ist hoch: Der Stack Overflow Developer Survey 2025 misst 84 % Nutzung oder geplante Nutzung von KI-Tools unter 49.000 befragten Entwicklern. Das Vertrauen in die Ergebnisse ist allerdings parallel gesunken: von 40 % auf 29 % binnen eines Jahres. 66 % der Entwickler geben an, mehr Zeit mit dem Debugging „fast richtiger” KI-Outputs zu verbringen als vorher [5].
Wir nutzen die Werkzeuge mehr und vertrauen ihnen weniger — beides zugleich.
Diese Beobachtungen zeichnen ein Bild, das in der öffentlichen Diskussion gut versorgt ist: ein Berufsbild im Wandel, mit empirischer Tiefe, mit ehrlichen Daten zu Beschleunigung und Verlangsamung, mit Befunden zu Vertrauen und mit Studien, die sich teilweise widersprechen. Über Softwareentwickler wissen wir viel — und wir wissen es differenziert.
Einordnung: Warum KI-Studien mit Vorsicht zu lesen sind
So überzeugend diese Zahlenlage auf den ersten Blick wirkt: Sie hat ein Problem, das die Forschung selbst inzwischen offen diskutiert.
Eine systematische Übersichtsarbeit aus dem November 2025 hat 445 Studien zu LLM-Benchmarks untersucht — begutachtet von 29 Reviewerinnen und Reviewern aus führenden NLP- und Machine-Learning-Konferenzen. Das Ergebnis: Fast alle untersuchten Studien haben in mindestens einem Bereich Validitätsprobleme. Die gemessenen Konzepte sind unzureichend definiert, die Aufgaben repräsentieren nicht zuverlässig das, was sie zu messen behaupten, und die Metriken passen nicht immer zu den gezogenen Schlüssen [6].
Eine parallele Untersuchung von 60 weit verbreiteten Benchmarks fand, dass fast die Hälfte mittlerweile gesättigt ist — sie kann zwischen den besten Modellen nicht mehr zuverlässig differenzieren [7].
Hinzu kommt ein methodisches Problem, das bei kaum einer anderen Technologie in dieser Schärfe auftritt: Die Werkzeuge, über die geforscht wird, sind häufig schon veraltet, wenn die Forschung erscheint. METR selbst hat im Februar 2026 öffentlich beschrieben, dass das Folgeexperiment zur eigenen viel zitierten 19-%-Studie in ein beobachtendes Studiendesign überführt werden musste, weil die Adoption von KI-Tools mittlerweile so flächendeckend ist, dass sich eine saubere Kontrollgruppe kaum noch bilden lässt [8].
Eine Studie zu Scrum-Praktiken kann zehn Jahre nach Veröffentlichung noch relevant sein. Eine Studie zu KI-Werkzeugen kann ein halbes Jahr nach Veröffentlichung empirisch überholt sein, ohne methodisch falsch zu sein.
Die Zahlen in diesem Artikel sind deshalb nicht als endgültige Wahrheit zu lesen. Sie sind Momentaufnahmen einer Praxis, die sich schneller verändert, als Forschung sie stabil vermessen kann.
Warum Entwickler zuerst im Mittelpunkt standen
Wenn es so viel Forschung zur Wirkung von KI auf Softwareentwickler gibt, stellt sich die naheliegende Frage: Warum wissen wir so wenig über Business Analysten?
Ganz unfair ist diese Schieflage zunächst nicht. Entwickler waren für generative KI das naheliegende erste Experimentierfeld. Sie sind nah an der Technik. Sie arbeiten ohnehin mit Werkzeugen, Automatisierung, APIs, Repositories, Entwicklungsumgebungen. Ihr primäres Arbeitsergebnis liegt in einer Form vor, mit der Sprachmodelle besonders gut umgehen können: Text.
Code ist Text, aber nicht irgendein Text. Er ist formalisiert, regelgebunden, stark musterhaft und in riesigen Mengen öffentlich verfügbar. Genau deshalb war Softwareentwicklung ein ideales frühes Anwendungsfeld für generative KI. Die Modelle konnten aus öffentlichen Repositories lernen, wiederkehrende Muster erkennen, Syntax nachbilden, Bibliotheken verwenden, Fehlermeldungen erklären und Code in vorhandene Kontexte einpassen.
Hinzu kommt: Arbeitsergebnisse in der Softwareentwicklung lassen sich vergleichsweise schnell überprüfen. Code kompiliert oder kompiliert nicht. Tests laufen oder laufen nicht. Linter schlagen an oder nicht. Eine CI-Pipeline wird grün oder rot. Und gerade im Frontend fallen viele Fehler dem Nutzer unmittelbar auf: Ein Button ist falsch positioniert, ein Formular verhält sich anders als erwartet, ein Layout bricht, ein Nutzerfluss funktioniert nicht.
Natürlich heißt das nicht, dass Softwareentwicklung einfach zu messen wäre. Gerade in großen Brownfield-Codebasen, in verteilten Systemen, bei Architekturentscheidungen oder nicht-funktionalen Anforderungen wird es schnell komplex. Aber im Vergleich zu vielen anderen Wissensarbeitsfeldern hat Softwareentwicklung einen entscheidenden Vorteil: Sie produziert Artefakte, die ausführbar, testbar und teilweise automatisiert bewertbar sind.
Das macht sie für KI besonders attraktiv. Und es macht sie für Forschung vergleichsweise zugänglich.
Warum Business Analyse als Nächstes kommt
Bei Business Analysten ist die Lage anders. Unter Business Analysten fasse ich hierbei alle Menschen und Rollen zusammen, die fachliche Probleme analysieren und verstehen, um diese in technische Anforderungen zu übersetzen. In manchen Organisationen gibt es diese Rolle unter exakt diesem Titel, manchmal liegen die Aufgaben aber auch bei Product Ownern, Requirements Engineers oder fachlich starken Entwicklern. Für diesen Artikel ist deshalb weniger der Rollentitel entscheidend als die Funktion.
Auch die Arbeit von Business Analysten ist sprachlich. Sie schreiben Anforderungen, formulieren Akzeptanzkriterien, schneiden fachliche Domänen, strukturieren Workshops, klären Begriffe, modellieren Prozesse, beschreiben Schnittstellen, priorisieren Anforderungen und übersetzen zwischen Fachbereich und IT.
Genau deshalb ist ihre Arbeit ebenfalls ein naheliegendes Anwendungsfeld für generative KI. Nur sind ihre Ergebnisse schwerer zu prüfen.
Eine User Story kompiliert nicht. Ein Fachkonzept hat keinen Unit Test. Und ein missverstandenes Requirement fällt häufig nicht nach Sekunden auf, sondern erst Wochen, Monate oder gar Jahre später. Das macht die Wirkung von KI auf Business Analysis nicht unbedingt größer oder folgenreicher als in der Entwicklung. Aber sie ist schwerer sichtbar. Schwerer messbar. Schwerer eindeutig zuzuordnen.
Ein Vergleich auf der Zeitachse
Wenn wir die Wirkung also nicht direkt messen können — was lässt sich dennoch sagen? Eine Möglichkeit ist, das Muster der Entwicklerdebatte zu betrachten und zu fragen, ob es sich übertragen lässt. Entwickler haben seit Ende 2022 einen erkennbaren Zyklus durchlaufen: eine anfängliche Euphorie nach dem ChatGPT-Launch, einen Tooling-Reifesprung in den Jahren 2023 und 2024, einen Vertrauensknick im Jahr 2025, und eine produktive Integration, die sich gerade andeutet — der DORA-Report 2025 misst hier erstmals einen positiven Throughput-Effekt, allerdings nur dort, wo gleichzeitig die Workflows mit angepasst wurden [11].
Bei Business Analysten sehen wir aktuell etwas, das stark an die erste dieser Phasen erinnert. Eher isolierte Tool-Nutzung von LLMs für User Stories, Akzeptanzkriterien, Workshop-Zusammenfassungen. Wenig spezifische Tool-Integration in Anforderungs- oder Workflow-Plattformen. Und eine sehr positive Grundstimmung in der eigenen Berufsgruppe — der IIBA Global State of Business Analysis Report 2025 misst 74 % positive Karriere-Einschätzung unter Business Analysten, ein Sprung um 11 Prozentpunkte gegenüber 2024 [9]. Das ist die Art von Selbsteinschätzung, die wir bei Entwicklern in den Jahren 2023 und Anfang 2024 gesehen haben.
Ein Blick auf den aktuellen Toolmarkt deutet zumindest an, dass sich auch in der Business Analyse ein Tooling-Reifesprung ankündigt. Atlassian hat seinen KI-Agenten Rovo bereits 2024 gelauncht [10], wobei sich die Adoption in vielen Organisationen meiner Erfahrung nach erst jetzt langsam etabliert. Gleichzeitig haben viele Unternehmen spezifische KI- und Agentenplattformen aufgebaut, die verschiedene Daten- und Informationsquellen im Unternehmen verknüpfen und KI direkt in die Kernaufgaben von Business Analysten integrieren.
Ich vermute, dass sich die KI-Adoption in der Business Analyse in zwei Punkten von derjenigen der Entwickler emanzipieren wird. Erstens: Die meisten Organisationen haben mittlerweile Erfahrungen mit der Einführung von KI-Werkzeugen gesammelt. Der Vertrauensknick, den wir bei Entwicklern 2025 gesehen haben, fällt in der Business Analyse vermutlich deutlich schwächer aus. Die Organisationen wissen inzwischen besser, was sie methodisch zu erwarten haben.
Zweitens: Business Analysten arbeiten stärker in soziotechnischen Umfeldern als Entwickler. Stakeholder-Klärungen, Konflikt-Moderationen, fachliche Aushandlungen — das sind Tätigkeiten, in denen sich Arbeitsroutinen langsamer verändern. Die Lücke zwischen Dev-Change und BA-Change könnte sich, je nach Aufgabentyp, sogar weiter vergrößern, statt zu schließen.
Was die Zeitachse damit etwas verkompliziert: Die BA-Welle wird vielleicht keine versetzte Kopie der Dev-Welle sein, sondern eine eigene Kurve mit anderen Peaks und einem anderen Tempo. Die Verzögerung ist nur die erste Dimension. Die zweite ist die strukturelle Andersartigkeit der Aufgaben selbst.
Wie sieht die Rolle der Business Analyse aus?
Dies alles ist natürlich ein Blick in die Glaskugel. Die zugrundeliegenden Fragen sind aber sehr konkret. Ich kenne durchaus Organisationen, in denen offen diskutiert wird, ob zukünftig überhaupt noch Business Analysten gebraucht werden. Meine Antwort ist hier relativ eindeutig: ja. Aber die Rolle wird sich verschieben.
Niemand wird in fünf Jahren mehr händisch GIVEN-WHEN-THEN-Muster in User Stories formulieren. Das übernimmt die KI — so wie sie Entwicklern heute schon große Teile ihrer Unit Tests vorschlägt. Die Daumenregel ist einfach: Je textlastiger eine Aufgabe und je einfacher zu validieren, desto schneller wird sie durch KI ersetzt.
Nachdem dieser Artikel über Business Analysten zu großen Teilen retrospektiv auf Entwickler geschaut hat, möchte ich zum Abschluss aus den Beobachtungen ein paar Thesen zuspitzen. Manche treffen die Business Analyse direkter als andere — aber alle gelten für die Arbeit an der Schnittstelle zwischen Fachbereich und IT, in der Business Analysten den größten Teil ihrer Zeit verbringen. Sie sind als Diskussionsangebot gedacht.
Teams werden kleiner und durchlässiger
Die ideale Teamgröße schrumpft auf drei bis fünf Köpfe. Dev und BA mischen sich, Rollen werden durchlässig. Erste Experimente in diese Richtung sehen wir schon heute — und damit meine ich keine Solo-Entrepreneure mit dem nächsten SaaS-Startup, sondern echte Projektarbeit in Dax-Konzernen.
In einem Konzernprojekt sollten Business Analysten federführend einen Onlinerechner umsetzen — Fachbereich bei ihnen, KI dabei. Die erste Iteration war HTML pur, ohne firmeneigene Frameworks, ohne die fachliche Tiefe, die der Rechner eigentlich abbilden sollte. Im zweiten Anlauf saßen die BAs in einem crossfunktionalen Team. Zwei Entwickler setzten den technischen Rahmen, die BAs die fachliche Logik. Plötzlich lief der Rechner.
Es geht nicht darum, BAs durch KI zu ersetzen. Es geht um die Mischung — und um T-shaped-Profile, die in ihr tragen: eine Sache wirklich gut, dazu Breite.
Validieren ist der neue Key-Skill
Fehler in KI-Antworten erkennt nur, wer fachlich tief drin ist. Tests, Akzeptanzkriterien und scharfe Reviews werden zum eigentlichen Hebel der Arbeit. Das gilt für Devs wie für BAs.
Eine User Story zu schreiben ist trivial geworden. Eine User Story zu beurteilen wird zur eigentlichen Tätigkeit.
Die kulturelle Verschiebung ist härter als die technische
KI liefert Entwürfe. Verantwortet wird das Ergebnis weiter von Menschen — mit Namen, Rolle und Konsequenz. Das klingt trivial. Ist es aber nicht.
Wer einmal erlebt hat, wie schnell eine erste Fassung kommt — und wie passabel sie auf den ersten Blick aussieht — lässt sich auf das Hinterfragen nur ungern wieder ein. Die Versuchung, das gute Gefühl „die KI hat das so vorgeschlagen” nicht mehr zu prüfen, ist real. Und sie wächst mit der Geschwindigkeit, in der Entwürfe entstehen.
KI löst kein Datenqualitätsproblem
Der alte Spruch „Shit in, shit out” stimmt leider weiterhin — und KI macht ihn sogar noch glaubwürdiger. Konfidenter falsch ist gefährlicher als offensichtlich falsch, weil die Korrekturschleife fehlt.
Für Business Analysten heißt das: Die Arbeit an Datenmodellen, Domänenklärung und fachlicher Konsistenz wird wichtiger, nicht weniger wichtig. Wer sauberen Input liefert, bekommt brauchbaren Output. Wer es nicht tut, bekommt überzeugende Halluzinationen.
Effizienz wird reinvestiert, nicht eingespart
Effizienzgewinne in der Softwareentwicklung führen historisch gesehen selten zu Stellenabbau. Sie werden in der Regel von neuen Prozessen und höheren Anforderungen wieder eingesammelt. Tabellenkalkulationen haben keine Buchhalter ersetzt — sie haben Controlling-Funktionen geschaffen, die es vorher gar nicht gab. Compiler haben keine Programmierer überflüssig gemacht — sie haben Software in Branchen gebracht, in denen sie vorher zu teuer war.
Wer es sich in seiner Rolle bequem gemacht hat, bekommt Probleme — das ist in technologischen Umbrüchen fast immer so gewesen. Aber pauschal arbeitslos wird niemand.
Was bleibt
Was passiert in den nächsten zwei oder fünf Jahren? Wenn ich meine eigenen fünf Thesen ernst nehme, ehrlich gesagt: gar nicht so viel, wie uns manch ein IT-Vorstand oder LinkedIn-Guru gerade verkaufen will. Keine Massenentlassungen, keine Jobverdoppelung — eher tausend kleine Verschiebungen, von denen viele erst rückblickend sichtbar werden.
Andererseits — und an dieser Stelle ist Amaras Gesetz [12] zu nennen — neigen wir dazu, die kurzfristige Wirkung einer neuen Technologie zu überschätzen und ihre langfristige zu unterschätzen. Was sich in zwei Jahren wie eine leise Welle anfühlt, kann in zehn Jahren eine Brandung sein, die ein ganzes Berufsbild umkrempelt.
Wir dürfen gespannt sein.
Quellen
[1] Peng, Sida; Kalliamvakou, Eirini; Cihon, Peter; Demirer, Mert: The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv:2302.06590, 2023.
[2] Chen, Fiona; Stratton, James: Artificial Intelligence in the Firm. Harvard University, Preliminary Working Paper, Januar 2026.
[3] McKinsey & Company: Unleashing developer productivity with generative AI. Juni 2023.
[4] Becker, Joel; Rush, Nate; Barnes, Beth; Rein, Daniel: Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR, arXiv:2507.09089, Juli 2025.
[5] Stack Overflow: Developer Survey 2025. survey.stackoverflow.co/2025.
[6] Zhou, Andrew; Mhamdi, El Mahdi El et al.: Measuring what Matters: Construct Validity in Large Language Model Benchmarks. arXiv:2511.04703, November 2025.
[7] Evaluating Evaluations Coalition: When AI Benchmarks Plateau: A Systematic Study of Benchmark Saturation. arXiv:2602.16763, 2026.
[8] METR: We are Changing our Developer Productivity Experiment to an Observational Study. Februar 2026.
[9] International Institute of Business Analysis: Global State of Business Analysis Report 2025. 2025.
[10] Atlassian: Introducing Atlassian Rovo — AI for the modern team. 2024.
[11] Google Cloud / DORA: State of AI-assisted Software Development 2025. 2025.
[12] Wikipedia: Hype-Zyklus (enthält Amaras Gesetz mit Originalzitat). de.wikipedia.org/wiki/Hype-Zyklus.
Die zweite Welle trifft auch Ihre Organisation? Wir begleiten Teams beim Umbau ihrer Arbeit an der Schnittstelle zwischen Fachbereich und IT — in unseren Beratungs- und Engineering-Leistungen und in unserer Schulungsreihe Agentic Engineering.
Geschäftsbereichsleitung «Finanzdienstleistungen»
Daniel ist seit 2017 in der IT-Branche aktiv und bringt seine umfassende Erfahrung als Senior Managing Consultant und Geschäftsbereichsleiter bei atra consulting ein. Besonders begeistert ihn das Zusammenspiel technischer, methodischer und organisatorischer Aspekte. Seine Kunden unterstützt er als Softwarearchitekt, agiler Coach und Berater bei der nachhaltigen und zielgerichteten Umsetzung von Entwicklungsprojekten.
