KI Marketing vs Realität

Seit längere Zeit wird KI immer wichtiger in der Welt und besonders im Bereich der Softwareentwicklung. Doch meiner Meinung nach ist zwischen Marketingversprechen und der Realität stellenweise ein ziemlich tiefer Abhang. 
Hier teile ich mal meine private Einschätzung. 

Was KI heute tatsächlich gut kann

Routine-Code beschleunigen

KI spart viel Zeit bei:

• CRUD-Code
• DTOs
• Mappings
• Unit Tests
• SQL-Abfragen
• API-Clients
• Dokumentation (Wer hat das nicht gehasst ?)
• Refactorings
• Schnellere Recherche bei Issues. 
• Wissen komprimieren

Ein erfahrener Entwickler kann dadurch oft 20–50 % schneller werden.

KI als Sparringspartner / Pairingpartner

Ein guter Einsatz ist:

"Bewerte meine Architektur."

"Welche Risiken hat dieser Ansatz?"

"Welche Alternativen gibt es?"

Das funktioniert häufig erstaunlich gut.

Was KI schlecht kann

Große Systeme verstehen

Marketing sagt:

"Die KI versteht deine gesamte Codebasis."

Realität zeigt:

Bei einigen tausend Dateien wird es schwierig.

Die KI kennt:

• nicht alle historischen Entscheidungen
• nicht alle Geschäftsregeln
• nicht alle impliziten Abhängigkeiten

Genau dort entstehen viele Produktionsfehler.

Fachlichkeit

Ideenfindung und Konzeption

Marketing sagt:

„KI generiert komplette Konzepte in Minuten.“

„Produktideen entstehen automatisch.“

„KI ersetzt Workshops.“

In Wirklichkeit liefert KI Rohmaterial, aber kein tragfähiges Konzept und Fachbereiche müssen trotzdem priorisieren, validieren, entscheiden.
KI erzeugt oft zu viele Optionen, was Entscheidungen verlangsamt.
Effekt auf TTM : 10-20%

Domänenwissen:

"Was darf das System überhaupt tun?"

KI kennt die Domäne oft nur oberflächlich, wie soll die KI dann rechtssichere Antworten geben. 
Beispiel : etwas was in einem Logistik-System vielleicht erlaubt ist, kann in einem Banken oder gar medizinischen System verboten sein. 

Solange KI Modelle nicht vollen, isolierten Zugriff auf alle relevanten Informationen der Domäne haben und nur die Daten der Domäne für die Arbeit nutzen, ist jede Entscheidung detailiert zu reviewen und zu hinterfragen.

Marketing sagt: 

• „KI schreibt automatisch User Stories, Epics, Akzeptanzkriterien.“

• „Keine Requirements Engineers mehr nötig.“

Realität : KI kann Stories generieren, aber oft unpräzise, nicht domain‑spezifisch, widersprüchlich, d.h. Teams müssen alles reviewen, korrigieren, priorisieren.
Aber bei guten Prompts und einer klaren Architektur ist die Auswirkung auf TTM 20%-40%

Softwareentwicklung

Marketing sagt: 

„KI schreibt 80 % des Codes.“

„Entwickler werden zu Reviewern.“

„MVP in Wochen statt Monaten.“

In der Realität kann es klappen, aber bei größeren Systemen kann die KI zwar Code generieren., aber sehr oft ist der Code nicht buildfähing und es sind mehrere Durchgänge notwendig.  Auch die Kompatibilität mit der bestehenden  Architektur , gerade in gewachsenen Systemen ist sehr oft nicht gegeben. Auch die Sicherstellung , dass keine Sicherheitslücken eingebaut werden , ist nicht 100%ig gegeben. Aus eigener Erfahrung weiß ich , dass gerade bei der Nutzung von Dritt-Anbieter-Libraries nicht unbedingt von der KI die aktuellsten Versionen eingebaut werden, sondern die Version, die beim Anlernen des Modells aktuell waren. Um dieses Sicherzustellen, bräuchte die KI eigentlich Zugang zu aktuellen CVE Informationen und den Versionsinformartionen.

Und dann haben wir noch die Testqualität, die KI hat aktuell noch Probleme bei der Edge-Cases Berücksichtigung. Als Entwickler kenne ich den Einfallsreichtum der Anwender und auf welche Ideen diese kommen können. Eine KI hat hier Probleme. 
Auch Testfehler in Unit Tests sind des öfters eine Herausforderung der KI. Die KI hat die Methode gebaut die getestet wird und es kommt ein falsches Ergebnis raus. Hat nun die Methode einen Fehler oder der Testfall. Hier verhält sich die KI ab und zu echt menschlich. Passt das Ergebnis nicht zum erwarteten , passe ich einfach das erwartete Ergebnis an , auch wenn das Ergebnis falsch ist. Der Test ist auf jeden fall grün.

Aus meiner Sicht verbringen Entwickler aufgrund dieser Punkte mehr Zeit mit Debugging, Refactoiring und Architektur-Alignment. 

Der Effekt auf das TTM ist hier meiner Meinung nach nur max. 30% , bei machen Legacy-Systemen sogar eher negativ. Kleiner Änderungen sind kein Problem , aber bei neuen Features , bei dem das ganze System mit der bisherigen Architektur bekannt sein muss , sehe ich skeptisch entgegen, es sei denn man hat unlimited Token um das ganze System als Kontext mitgeben zu können. 

Ich denke bei Neuentwicklungen siehts viel besser aus. Aber wann startet man mal auf der grünen Wiese.

Noch ein kleiner Zusatz zu den Tests.

Marketing sagt:  

„KI generiert automatisch Unit‑Tests, Integrationstests, E2E‑Tests.“

„Qualität steigt automatisch.“

Wie schon oben gesagt , sieht die Realität teilweise anders aus. Jeder Test ist erstmal besser als kein Test. Aber ich habe festgestellt , das manchmal Tests redundant angelegt werden , nicht nach der ersten Generierung laufen bzw. wartbar sind.
Und je nach Anwendungsgebiet, müssen sinnvolle Testdaten noch manuell geliefert werden. Auch Mocks von externen Systemen müssen teilweise manuell bereitgestellt werden, da diese nicht im Kontext der KI stehen und die KI nur raten kann wir der Mock aussehen muss. 
Daher würde ich sagen in Bezug auf Tests ist positive Auswirkung auf TTM bei max. 20%, wen es sich um moderne , modulare Codebasen handelt. 

Deployment und Betrieb

Marketing sagt:

„KI automatisiert DevOps.“

„CI/CD wird selbstoptimierend.“

„Zero‑Ops.“

Das stimmt aus meiner Sicht teilweise. KI kann die entsprechenden Konfigurationen, pipelines , Dockerfiles ,... erstellen Aber schauen wir uns doch mal die Punkte Security‑Policies, Secrets, Compliance und Infrastruktur an. Aus wirtschaftlicher Sicht hatte ich echt probleme , wenn die KI eigenständig sich um ihre Hardware kümmen könnte und z.B frei VPS bestellen könnte. Oder das Thema Passwörter. Einer KI Passwörter anzuvertrauen , ohne zu Wissen , was mit den input Token bei den Toolherstellern wirklich passiert, würde mir massive Bauchschmerzen bereiten. 
Aber bezüglich Zugangsdaten , wurde ja schon öfters in verschiedesten Quellen erzählt, das Zugangsdaten in Klartext im Sourcecode hinterlegt wurden. Ich selber hab das mal bei einem Testprojekt ausprobiert und die KI hat es auch gemacht. Auf die Frage , warum dieKI das gemacht hat , kam die Antwort , das könnte man später nochmal refactoren , aber erstmal geht es darum einen produktionsreifen MVP zu bekommen. 

Daher meine Bewertung bzgl. dem Effekt auf TTM : 5-20 %.

Verantwortung

Wenn ein Fehler in Produktion geht:

• Der Entwickler "haftet" beruflich dafür.
• Nicht die KI.

Deshalb bleibt Review unverzichtbar.
Aber der durch das Marketing angedeutete Geschwindigkeitsgewinn kann hier zum Gegenspieler werden. 
KI entwickelt Code , Entwickler muss die Lösungsstrategie der KI erkennen und verstehen, den Code analysieren, Tests auf sinnhaftigkeit prüfen und so weiter.

Die Aussage ,,KI hat das programmiert'' zieht leider nicht. 
Da das Marketing sagt , dass Software Entwickler  zu Reviewern werden, kann ich nicht unterstützen. Ich würde eher sagen dass Entwickler zu KI Lotsen werden , sie steuern die K, ähnlich ie Fluglotsen die Flugzeuge. Und da ein Fluglotze max. 4 Stunden am Stück das machen dürfen, damit keine Fehler geschehen, überlegt mal was bei Entwicklern nach 8h KI Steuerung und Output reviews passieren kann. 
Ich habe mal 2 Modelle gefragt und beide Modelle haben mir gesagt, dass bis zu 30% bis 40% mehr Fehler in Produktion landen könnten. 

Wer profitiert nun von der KI Nutzung am meisten? 

Wer glaubt, dass es Anfänger sind, der wird enttäuscht sein. Anfänger sind es nicht , da sie oft falsche Antworten, Sicherheitsprobleme und ungünstige Architekturen nicht erkennen. Und ob Anfänger etwas lernen und Berufserfahrung sammeln, wenn sie nur auf "Keep All" klicken, bezweifel ich. Es gibt natürlich auch hier Ausnahmen wie wirkliuch verstehen wollen , was das gebaut wird , aber bei vielen Vibe-Codern ist das nicht der Fall.

Senior Entwickler können allerdings von der KI profitieren. Sie erkennen sofort, was gut , was Unsinn ist und was fehlt.  KI kann hier wirklich zum Pairingpartner werden. 

Welche Jobs werden verschwinden?

Marketing sagte in der Vergangenheit immer , durch KI können viele Arbeitsplätze entfallen und massive Einsparungen durchgeführt werden. (Zum Thema Kostenentwicklung werde ich noch einmal einen weiteren Beitrag schreiben) 

Ich sehe das etwas anders :

Gefährdet

Reine "Code-Monkey"-Aufgaben:

• Standard-CRUD
• einfache Webseiten
• Boilerplate
• einfache APIs

Weniger gefährdet

Aufgaben mit viel:

• Architektur
• Kommunikation
• Fachlichkeit
• Verantwortung
• Systemdesign

Denn wir müssen im Kopf behalten: 

Unternehmen bezahlen selten für Codezeilen, sonderndafür,  dass ein Problem korrekt gelöst wurde.

Viele Entwickler glauben:

"KI schreibt meinen Job weg."

Ich sehe eher:

Entwickler, die KI gut nutzen, ersetzen Entwickler, die KI ignorieren.

Ähnlich wie früher:

• Git ersetzte keine Entwickler.
• IDEs ersetzten keine Entwickler.
• Stack Overflow ersetzte keine Entwickler.

Aber die Produktivitätserwartungen stiegen und stiegen.

Was sich in den nächsten 5 Jahren wahrscheinlich ändern wird

Der Alltag verschiebt sich von:

80 % Code schreiben
20 % Denken

30 % Code schreiben
70 % Prüfen, Entwerfen, Entscheiden

• Anforderungen verstehen
• Systeme entwerfen
• Risiken erkennen
• KI-Ergebnisse validieren

Mein Fazit

Für einen Java-Entwickler im Jahr 2026ff ist KI kein Ersatz für Fachwissen, sondern ein Verstärker.  Wer nur Framework-Methoden auswendig kennt, bekommt wahrscheinlich Probleme.

Wer dagegen versteht:

• Architektur
• Datenmodellierung
• Verteilte Systeme
• Performance
• Security
• Fachdomänen

wird mit KI oft produktiver als je zuvor.

Die größte Gefahr ist nicht, dass KI alle Entwickler ersetzt. Die größere Gefahr ist, dass man ihre Stärken und Schwächen falsch einschätzt: Manche erwarten Magie, andere ignorieren sie komplett. Beide Extreme führen meist zu schlechten Entscheidungen.

Mir tun nur die Junior-Entwickler leid.Wenn wir uns mal ansehn, was Junior Entwicker früher gemacht haben:

• einfache CRUD-Services
• kleine Bugfixes
• Boilerplate-Code
• einfache UI/API-Endpunkte

Genau diese Sachen kann KI heute ziemlich gut → dadurch gibt es weniger reine Low-Complexity Tasks.

Man beginnt klein und arbeitet sich hoch. Und das kleine verschwindet zum größten Teil.

Einstiegshürde ist höher geworden

Viele Teams erwarten inzwischen von Juniors:

• Git sicher beherrschen
• grundlegende Architektur verstehen
• Tests schreiben können
• nicht nur Code kopieren, sondern verstehen
• KI-Tools sinnvoll nutzen (z. B. ChatGPT/Copilot)

Das wirkt wie “schwieriger Einstieg”, ist aber eher eine Erwartungsverschiebung.

Ein Junior war früher oft:

“Ich lerne Programmieren im Job”

Heute eher:

“Ich kann schon programmieren und lerne Systementwicklung im Job”

Das ist der Unterschied.

Paradox, aber wichtig:

• Einstieg ist schwerer
• aber Lernkurve ist schneller

Mit KI kann ein guter Junior heute:

• schneller produktiv werden
• schneller verstehen, wie Systeme gebaut werden
• früher komplexere Aufgaben übernehmen