Ich arbeite als Softwareentwickler mit Webanwendungen – aktuell vor allem mit TypeScript, Rust und Dart, früher auch mal C#. Vielleicht bald Go. Und ich nutze KI seit über einem Jahr intensiv. Täglich. Nicht als Experiment, sondern als festen Teil meiner Arbeit.

Was ich dabei gelernt habe? KI kann verdammt hilfreich sein. Aber sie ist auch verdammt trügerisch.

Wie KI meinen Entwickleralltag verändert hat

McKinsey berichtet in ihrem “State of AI 2025” – einer globalen Umfrage unter knapp 2.000 Unternehmen aus 105 Ländern –, dass mittlerweile 88% der Organisationen KI in mindestens einer Geschäftsfunktion nutzen.¹ Ich verstehe warum.

Letzte Woche hatte ich ein Projekt mit sehr fragmentiertem Code. Ich hab der KI die Struktur gezeigt und gesagt: “Schlag mir was Besseres vor.” In 10 Minuten hatte ich drei Varianten, die ich alleine in Stunden nicht entwickelt hätte.

Das ist der Produktivitätsgewinn, von dem alle reden.

Diese Art von Zeitersparnis kommt einer guten Work-Life-Balance entgegen. Wenn man nicht in der Versuchung wäre, in der gesparten Zeit einfach noch mehr zu schaffen.

Wo KI wirklich hilft – konkrete Zeitersparnis

Ich will ehrlich sein: KI spart mir massiv Zeit.

Wo es am stärksten wirkt:

• Boilerplate & Setup: Projekt initialisieren, Config-Files, grundlegende Struktur – früher 1-2 Stunden, heute 10 Minuten
• Refactoring: Code umstrukturieren, den ich verstehe, aber nicht manuell umbauen will – spart 50-70% der Zeit
• Pattern-Implementierung: Ich kenne das Konzept (z.B. Observer Pattern), aber nicht die Syntax in Rust – KI liefert sofort
• Neue Frameworks: Früher gab es zu brandneuen Tools kaum Quellen. Mit KI habe ich eine starke Hilfe, fehlende Dokumentation zu kompensieren

Wo es stagniert:

• Debugging komplexer State-Probleme: KI rät, ich muss trotzdem verstehen
• Architektur-Entscheidungen: Welches Pattern passt zum Business-Case? KI kann nicht entscheiden
• Performance-Optimierung: Ohne Profiling-Daten liefert KI nur Vermutungen

Wo es länger dauert als vorher:

• Korrektur von KI-Fehlern: Wenn die KI falsche Annahmen trifft, dauert das Debuggen länger
• Review von KI-Code: Ich muss jeden generierten Code prüfen – das kostet Zeit

Wo KI scheitert – typische Fehlerquellen

Aber dann gibt es die anderen Tage.

Die KI generiert Code. Sieht gut aus. Funktioniert. Tests laufen durch. Ich übernehme es.

Drei Stunden später, bei einer komplexeren Interaktion, merke ich: Eine zugesagte Anforderung fehlt. Die Tests haben es nicht abgedeckt.

Die häufigsten Fehlerarten:

• Security by Hallucination: KI erfindet unsichere Patterns (z.B. direkte String-Interpolation statt Prepared Statements)
• Phantombibliotheken: Imports von Libraries, die gar nicht existieren – Code sieht gut aus, kompiliert nicht
• Falsche Annahmen: KI denkt, eine Funktion ist synchron, ist aber async – fällt erst in Production auf
• Subtile Logikfehler: Edge Cases nicht abgedeckt, weil KI die Business-Logik nicht versteht
• Context Drift: Bei langen Sessions verliert die KI den Überblick – plötzlich werden alte Entscheidungen überschrieben oder Abhängigkeiten vergessen
• Unidiomatischer Code: Der Code funktioniert, ist aber nicht idiomatisch – “unrusty Rust”, Anti-Patterns, die ein erfahrener Entwickler nie schreiben würde

Die Debugging-Falle: Das Problem ist, dass die KI beim Debuggen nur den Kontext des Fehlers sieht, nicht die Abhängigkeiten im Gesamtkontext. Gibt man ihr alle Freiheiten, greift sie in Bereiche ein, die stabil laufen sollten. Ein Teil wird korrigiert, woanders bricht etwas. Je komplexer die Software, desto länger die Kette.

Von außen könnte man denken: “Der hat jetzt KI, der macht viel früher Feierabend.” So ist es nicht. Die Arbeit hat sich verschoben. Anforderungen formulieren, testen und reviewen ist mittlerweile mein Hauptjob geworden. Die KI übernimmt das Coding, ich übernehme die Qualitätssicherung.

Die Zahlen sprechen für sich: Laut Stack Overflow Developer Survey 2025 vertrauen nur 33% der Entwickler der Genauigkeit von KI-Tools, während 46% aktiv misstrauen.² Bei erfahrenen Entwicklern haben sogar nur 2,6% “hohes Vertrauen” in die KI-Genauigkeit.

Wie ich damit umgehe – meine Strategien

Ich habe gelernt: Fortschritte dokumentieren. Kleinteilige Anweisungen geben. Der KI mehr Kontext mitgeben – mit Rules (mehr dazu in meinem Artikel zu sessionübergreifenden KI-Regeln). Im Worst Case: Zurück zum Vortagesstand in GitHub, neue Runde mit den Erkenntnissen.

Was konkret hilft:

• Regeln definieren: Coding-Style, Do/Don’t, Projektarchitektur in einer .claude oder .cursorrules Datei festhalten. Die KI liest das bei jeder Session und macht weniger Fehler.
• Kontext geben: Je mehr die KI über dein Projekt weiß, desto besser. Projektstruktur, wichtige Interfaces, Naming Conventions. Manchmal sogar Beispiel-Code aus früheren Modulen.
• Tests erst, dann Code: Lass die KI zuerst Tests schreiben – dann Implementierung. Grüne Tests = höhere Confidence.
• Halluzinationen abfangen: Bei Imports prüfen: Existiert die Library wirklich? Ich google mittlerweile jeden zweiten Import.
• Code-Execution nutzen: Moderne KI-Tools können Code ausführen. Lass die KI Tests laufen, bevor du den Code übernimmst.
• Design erst, dann Code: Lass die KI erst das Design erklären: “Erkläre mir die Architektur, bevor du implementierst.”
• Patch-by-Patch, nicht Full Rewrite: Bei großen Änderungen: Kleine Schritte, jeder testbar. Kein “Schreib alles neu”.

Und es ist eine Kostenfrage: Wer bei der KI spart – Token-Kosten oder Zeit für Tests –, zahlt doppelt. Schlechte Leistung kostet mehr, als wenn man es gleich richtig macht.

Das Problem mit Vertrauen und Verifizierung

Dieses Spannungsfeld – KI liefert schnell Antworten, aber wie verlässlich sind sie? – erlebe ich nicht nur im Code.

Neulich hat mein Sohn seine Pokemon-Karten sortiert und sie mit einer Taschenlampe durchleuchtet. Bei mehreren waren wir uns nicht sicher, ob sie echt sind (zu günstige Mitbringsel aus dem Urlaub). ChatGPT hat die Karten analysiert, Details aufgezählt – klang überzeugend. Aber wir waren danach nicht schlauer. Mussten trotzdem selbst recherchieren, Vergleichsbilder suchen.

Das ist genau das Muster, das ich aus der Entwicklung kenne: KI gibt selbstbewusst Antworten, aber die Verantwortung für die Richtigkeit bleibt bei mir. Ob Code-Import, Pokemon-Karte oder Business-Entscheidung – am Ende muss ich prüfen.

Was das für meine Rolle bedeutet

Ich merke, dass ich anders arbeite als vor einem Jahr.

Früher war ich der, der Code schreibt. Heute bin ich eher der, der Architektur definiert, Qualitätskriterien setzt und kontrolliert.

Die KI macht den Hands-On-Teil. Ich mache das Controlling. Manchmal nutze ich sogar KI, um die Ergebnisse einer anderen KI zu prüfen. KI kontrolliert KI. Das klingt absurd – ist aber meine Realität.

Jeder Programmierer managt jetzt quasi mehrere “Angestellte”, die – wie echte Mitarbeiter – mal gute und mal schlechte Tage haben.

Habe ich meine Coding-Skills abgegeben? Schon ein bisschen. Aber ich kann mich mehr auf Softwarearchitektur, Anforderungsmanagement und die Brücke zur Infrastruktur fokussieren.

Und das erinnert mich an Science Fiction. Star Trek: “Computer, Tee, Earl Grey, heiß.” Iron Man: JARVIS führt komplexe Aufgaben autonom aus. Was früher Fiktion war, wird jetzt Realität – nicht in 50 Jahren, sondern innerhalb weniger Jahre.

Wie sich meine Werkzeugnutzung verändert hat

Früher habe ich für Stockfotos Shutterstock genutzt. Heute generiere ich mit Midjourney in Sekunden genau das Bild, das ich brauche. Früher habe ich Texte mit DeepL übersetzt. Heute macht das die KI direkt im Kontext.

KI kann vieles ersetzen. Das ist nicht nur “praktisch”. Das ist strukturell disruptiv. Und es passiert jetzt.

Was das für Teams bedeutet

Die fünf zentralen Punkte:

• KI beschleunigt – aber nur, wenn man das Ergebnis kontrolliert. Ohne Review wird aus Zeitgewinn Risiko.
• Geschwindigkeit ist Chance und Risiko. Mehr Output bedeutet nicht automatisch bessere Qualität.
• Entwickler werden zu Orchestratoren. Weniger coden, mehr definieren, kontrollieren, entscheiden.
• Teams müssen Regeln definieren. Nicht verbieten, sondern regeln. Sessionübergreifende KI-Regeln helfen dabei.
• Schattennutzung ist ein Risiko. Viele nutzen KI inoffiziell – ohne Leitlinien, ohne Transparenz, ohne Qualitätskontrolle.

Diese Fragen haben wir noch nicht beantwortet. Aber wir sollten anfangen, darüber zu reden.

Der größere Kontext

Wer sich für die gesellschaftlichen Auswirkungen von “KI-Slop” interessiert – also dem Phänomen, dass das Internet zunehmend mit KI-Inhalten minderer Qualität überflutet wird – dem empfehle ich meinen ausführlicheren Artikel: KI-Slop, Gesellschaft und unsere Zukunft. Dort analysiere ich fünf Szenarien, wohin die Reise gehen könnte – von der Dystopie bis zur post-knappen Utopie.

Wie massiv KI-generierter Content bereits Social-Media-Plattformen überschwemmt, zeigt das Video “KI-Müll überflutet YouTube – so erkennt ihr ihn” von Sascha Pallenberg³. Die Unterscheidung wird schwieriger – für viele ist KI-generierter Content bereits nicht mehr erkennbar.

Dass diese Entwicklung rasant voranschreitet, zeigt auch der Sprung von Sora 1 zu Sora 2: Innerhalb kürzester Zeit ist KI-generierter Video-Content von “erkennbar künstlich” zu “täuschend echt” geworden. Die Grenze zwischen Realität und KI verschwimmt – mit allen Konsequenzen für Plattformen, die bisher Creator für guten Content monetarisierten.

Wohin führt das für die IT-Branche? Die Grenze zwischen “Programmierer” und “Systemarchitekt” verschwimmt. Entwickler werden zunehmend zu Orchestratoren – weniger selbst coden, mehr definieren, kontrollieren, Architektur entscheiden.

Für mich persönlich? Als Freelancer bin ich nicht nur Entwickler, sondern auch Unternehmer und mein eigener Projektmanager. Ich sehe weiterhin eine Entlastung – mehr Zeit für Architektur, Kundenberatung und strategische Entscheidungen statt repetitive Implementierung. Vorausgesetzt, die Nachfrage nach meiner Arbeitskraft bleibt bestehen.

Die Auswirkungen sind bereits messbar: Eine Stanford-Studie zeigt, dass zwischen Ende 2022 und Juli 2025 die Beschäftigung von Software-Entwicklern im Alter von 22-25 Jahren um fast 20% zurückgegangen ist – während die Beschäftigung älterer Entwickler in denselben Positionen wuchs.⁴ In Deutschland zählte StepStone im Q1 2025 45% weniger Einstiegspositionen als im Fünfjahresdurchschnitt.⁵

Es gab eine Zeit, da wurde blind eingestellt. Startups und Konzerne suchten händeringend nach Entwicklern – Hauptsache Kapazität. Diese Zeit ist vorbei. KI übernimmt den quantitativen Aufwand: Code generieren, Boilerplate schreiben, einfache Bugs fixen. Genau die Aufgaben, die früher Juniors gemacht haben.

Und KI skaliert perfekt – in beide Richtungen. Mehr Arbeit? Mehr Tokens. Weniger Arbeit? Weniger Kosten. Kein Arbeitsvertrag, keine Kündigungsfrist, kein Onboarding. Eine LeadDev-Umfrage 2025 zeigt: 54% der Engineering-Leader planen, weniger Juniors einzustellen – dank KI-Copilots, die Seniors produktiver machen.⁶

Das ist keine Zukunftsprognose. Das passiert jetzt.

---

Quellen

Footnotes

1. McKinsey & Company: The State of AI 2025 – 88% der Organisationen nutzen KI in mindestens einer Geschäftsfunktion (2025) ↩

2. Stack Overflow: Developer Survey 2025 – Nur 33% der Entwickler vertrauen der Genauigkeit von KI-Tools, 46% misstrauen aktiv (2025) ↩

3. Sascha Pallenberg: KI-Müll überflutet YouTube – so erkennt ihr ihn – YouTube (2025) ↩

4. Stanford Digital Economy Lab: New evidence strongly suggests AI is killing jobs for young programmers – Beschäftigung von Software-Entwicklern (22-25 Jahre) sank um 20% zwischen Ende 2022 und Juli 2025 (2025) ↩

5. TZG - Technologie Zeitgeist: KI drückt Junior-Jobs: Warum junge Entwickler am stärksten verlieren – StepStone zählte 45% weniger Einstiegspositionen im Q1 2025 (2025) ↩

6. Stack Overflow Blog: AI vs Gen Z: How AI has changed the career pathway for junior developers – 54% der Engineering-Leader planen, weniger Juniors einzustellen (LeadDev Survey 2025) ↩