Wie sich mein Umgang mit KI als Senior-Entwickler verändert hat

Vor etwa sechs Monaten begann ich, KI-Werkzeuge systematisch in meine tägliche Arbeit als Senior-Entwickler zu integrieren. Was als Experiment mit GitHub Copilot in VSCode begann, entwickelte sich schnell zu einer produktivitätssteigernden Routine – doch die größten Veränderungen lagen nicht in der Code-Generierung, sondern in der Neugestaltung meiner Arbeitsprozesse. Hier ist die chronologische Entwicklung meines Verhältnisses zu KI.

Die ersten Schritte: Vom Code-Generator zum Allzweck-Assistenten

Meine ersten Berührungen mit KI-Werkzeugen begannen 2025 mit GitHub Copilot, das ich zunächst ausschließlich als Code-Vorschlagsmaschine nutzte. Doch bald erkannte ich, dass der wahre Mehrwert in Aufgaben lag, die wenig mit klassischer Programmierung zu tun hatten. Plötzlich konnte die KI mir helfen, technische Zusammenfassungen zu verfassen, präzise Schätzungen für Sprint-Planungen abzugeben oder E-Mails mit dem richtigen Ton zu formulieren.

Um die Unterschiede zwischen den verfügbaren Modellen zu verstehen, experimentierte ich bewusst mit verschiedenen Anbietern: GPT-4, Claude Sonnet, Gemini X Pro, Kimi 2.5 und Minimax. Jedes Modell hatte seine eigenen Stärken – einige eigneten sich besser für strukturierte Analysen, andere für sauberen Code oder die Erklärung von Trade-offs. Diese Experimente führten zu einer Art mentalem "Werkzeugkasten": Ich lernte, welches Modell ich für welche Art von Aufgabe einsetzen sollte.

Anfangs war die KI vor allem ein Produktivitätsbooster für Aufgaben, die ich ohnehin beherrschte. Transformativ war das noch nicht – aber es legte den Grundstein für eine tiefere Integration.

Die Trennung von Planung und Ausführung: Ein Gamechanger

Im Januar 2026 startete ich ein neues Projekt: die Entwicklung einer Echtzeit-Sprach-zu-Sprache-Pipeline mit NVIDIAs Holoscan SDK – einem Framework, mit dem ich zuvor keine Erfahrung hatte. Die technische Komplexität war beträchtlich: Es galt, ASR-Modelle, Übersetzungskomponenten, TTS-Systeme und latenzarme Streaming-Lösungen zu integrieren, während gleichzeitig unbekannte APIs navigiert werden mussten.

Hier kam mir eine Idee, die mein Arbeitsverständnis nachhaltig veränderte: Ich teilte die Arbeit zwischen zwei KI-Systemen mit unterschiedlichen Rollen auf.

• Gemini 2.5 Pro als Planer: Diese Rolle umfasste die Recherche, die Architekturplanung und das Verständnis des unbekannten Terrains. Ich übergab dem Modell eine Problemstellung und erhielt im Gegenzug eine strukturierte Analyse des Lösungswegs – inklusive potenzieller Fallstricke und notwendiger Technologiestacks.
• GitHub Copilot und Claude Sonnet als Arbeiter: Sobald die Architektur stand, übernahm diese Kombination die Implementierungsdetails direkt im IDE. Die Code-Generierung erfolgte präzise und im Kontext der bestehenden Codebasis.

Diese Trennung von Planung und Ausführung erwies sich als entscheidend. Die Planungsphase erforderte breite Kontextverständnisse, logische Deduktionen und die Fähigkeit, zwischen verschiedenen Dokumenten Verbindungen herzustellen – Eigenschaften, die ein Modell mit großem Kontextfenster und starker Reasoning-Fähigkeit besser abdeckt. Die Implementierung hingegen verlangte Präzision und ein tiefes Verständnis für den aktuellen Codefluss. Beide Rollen gleichzeitig von einem einzigen Modell übernehmen zu lassen, wäre gewesen wie einen Architekten zu bitten, gleichzeitig die Ziegel zu verlegen.

Die zentrale Erkenntnis: Warum Erfahrung durch KI nicht ersetzt wird

Als ich Zugang zu Claude und dessen Integration in Tools wie Cowork und Claude Code erhielt, wurde mir eine fundamentale Wahrheit bewusst: Ich selbst – mit meinen begrenzten Python-Kenntnissen – hätte niemals in der Lage sein können, eine produktionsreife FastAPI-Service-Architektur mit GPU-beschleunigter Audioverarbeitung von Grund auf zu entwickeln. Zumindest nicht in der Zeit, die ein solches Projekt erfordert.

Und doch gelang es mir mithilfe von KI. Die generierten Codezeilen funktionierten nicht nur, sondern wurden auch in Produktion eingesetzt und von echten Nutzern genutzt.

Der entscheidende Unterschied zwischen Junior- und Senior-Entwicklern liegt nicht darin, ob sie Code schreiben können, sondern darin, welches Urteil sie über diesen Code fällen. Ein Junior-Entwickler nutzt KI, um funktionierenden Code zu generieren. Ein Senior-Entwickler nutzt KI, um Code zu generieren, der nicht nur funktioniert, sondern auch architektonisch solide ist, Edge Cases behandelt, skalierbar ist und sich nahtlos in ein größeres System einfügt – ohne sechs Monate später zusammenzubrechen.

Die KI schreibt die Zeilen. Die Erfahrung des Entwicklers entscheidet, welche Zeilen in welcher Reihenfolge und unter welchen Constraints geschrieben werden. Der Abstand zwischen Junior und Senior schrumpft nicht durch KI – er wird durch sie vergrößert, weil die Technologie die Urteilsfähigkeit des erfahrenen Entwicklers erst richtig zur Geltung bringt.

Der heutige Workflow: KI als unsichtbarer Teamplayer

Meine aktuelle Arbeitsweise ist das Ergebnis dieser Entwicklungen und folgt einem klaren, wiederholbaren Muster:

1. KI-gestützte Recherche und Planung Bevor ich ein Ticket erstelle oder einen neuen Branch beginne, nutze ich Claude, um das Problem systematisch zu durchdenken. Ich beschreibe das geplante Feature, die bestehenden Constraints und die Architektur des Projekts. Das Ergebnis ist ein strukturierter Plan, den ich in Planungssitzungen verteidigen kann – nicht als vage Idee, sondern als durchdachte Lösung.

2. Sichtbare Artefakte für das gesamte Team Die aus der KI-generierten Planung extrahierten Erkenntnisse werden direkt in Jira und GitHub Projects übertragen. Der Plan existiert nicht länger nur in meinem Kopf oder in einem Chat-Fenster, sondern ist für das gesamte Team einsehbar. Kollegen können Kommentare hinterlassen, Fragen stellen und mich zur Verantwortung ziehen – ein entscheidender Schritt für Transparenz und Kollaboration.

3. Automatisierte Statusberichte Um Reporting-Aufwand zu reduzieren, setze ich n8n ein, um tägliche Arbeitsupdates automatisch zu generieren. Mein Vorgesetzter erhält wöchentliche Berichte, die direkt aus den Aktivitäten in Jira und GitHub gezogen werden. Kein manuelles Zusammenstellen mehr, keine hektischen "Was hast du diese Woche gemacht?"-Nachfragen. Die Sichtbarkeit meiner Arbeit erhöht sich, ohne dass ich zusätzlichen Aufwand betreiben muss.

4. Nahtlose Integration durch MCP-Server Der vielleicht schwer zu vermittelnde, aber entscheidende Fortschritt: Meine KI-Assistenten können nun direkt mit meinen Projektmanagement-Systemen interagieren. MCP-Server verbinden GitHub, Jira und n8n, sodass die KI nicht nur Informationen abrufen, sondern auch Workflows ausführen kann. Der Unterschied in der Arbeitsflüssigkeit ist spürbar – und reduziert die Reibung zwischen den verschiedenen Tools auf ein Minimum.

Ratschläge für Neueinsteiger: Worauf es wirklich ankommt

Der häufigste Fehler, den Entwickler bei der Einführung von KI machen, ist, die Technologie als reinen Code-Generator zu betrachten. Doch der wahre Mehrwert entsteht, wenn man sich fragt: Welche Teile meiner Arbeit sind langweilig, repetitiv oder erfordern nur begrenztes Fachwissen – und könnten durch KI effizienter erledigt werden?

In meinem Fall waren das:

• Das Verfassen von Statusberichten
• Die Übersetzung von Architekturentscheidungen in verständliche Ticket-Beschreibungen
• Das schnelle Verständnis unbekannter APIs oder Programmiersprachen
• Die Recherche zu technischen Trade-offs

Die spannenden Aspekte des Jobs – also die Frage, was überhaupt gebaut werden soll, warum es gebaut werden soll und wie es in das größere System passt – bleiben dabei unberührt. Die KI entfernt lediglich das Rauschen, sodass man sich auf das Wesentliche konzentrieren kann.

Mein Rat an alle, die diesen Weg einschlagen wollen: Fangt klein an, aber denkt groß. Beginnt damit, die KI für die 20% Ihrer Arbeit einzusetzen, die 80% Ihrer Frustration ausmachen. Doch lasst euch nicht täuschen: Die Technologie ist kein Zauberstab. Sie ist ein Werkzeug – und wie bei jedem Werkzeug kommt es darauf an, wer es bedient.