Ich nutze GitHub Copilot seit über einem Jahr täglich in Enterprise-Java-Projekten — zuletzt im Product Order Tracking Projekt bei der Deutschen Telekom. Dieser Artikel ist kein Marketing-Beitrag. Ich schreibe auf, was wirklich passiert, wenn man ein KI-Coding-Tool in eine gewachsene Microservice-Landschaft mit Spring Boot, Kubernetes und Camunda einführt.

Der Kontext: kein Greenfield-Projekt

Die meisten Copilot-Erfahrungsberichte stammen aus Greenfield-Projekten oder Solo-Entwicklern, die eine neue App bauen. Enterprise-Realität sieht anders aus: bestehende Codebasis mit jahrelanger Geschichte, Offshore-Team in verschiedenen Zeitzonen, strenge Code-Review-Prozesse, TMForum-API-Standards die eingehalten werden müssen.

Genau in diesem Umfeld habe ich Copilot eingesetzt — und die Ergebnisse waren differenzierter als erwartet.

Wo Copilot echte Zeit spart

1. Boilerplate-Code bei REST-Endpunkten

Spring Boot REST-Controller folgen immer demselben Muster: Annotation, Dependency Injection, Methode, Exception Handling, Response-Wrapping. Copilot erkennt dieses Muster nach wenigen Beispielen zuverlässig und vervollständigt neue Endpunkte zu 80–90% korrekt. Was früher 10 Minuten dauerte, dauert jetzt 2.

2. Unit-Tests für einfache Service-Methoden

Test-Skelette für einfache Service-Klassen generiert Copilot sehr gut. Arrange-Act-Assert Struktur, Mockito-Setup, typische Happy-Path-Tests — das funktioniert zuverlässig. Bei komplexen Integrationstests mit mehreren Abhängigkeiten wird es schlechter, aber der Ausgangspunkt ist trotzdem nützlich.

3. Regex, SQL-Queries, Mapping-Logik

Aufgaben, die präzise und repetitiv sind, erledigt Copilot ausgezeichnet. Eine MapStruct-Mapping-Definition, eine JPA-Query-Annotation, ein Regex für eine Validierung — hier ist der Vorschlag meistens direkt verwendbar.

Wo Copilot in die Irre führt

1. Domain-spezifische Logik

Copilot kennt Spring Boot — aber er kennt nicht dein Domänenmodell. Bei komplexer Geschäftslogik (z.B. TMForum Product Order State Machine) schlägt er plausibelklingende, aber fachlich falsche Implementierungen vor. Das Gefährliche: der Code sieht gut aus. Ein Junior-Entwickler der den Review überfliegt, übersieht den Fehler leicht.

2. Sicherheitsrelevanter Code

Bei Authentifizierung, Autorisierung, Datenverschlüsselung oder DSGVO-relevanten Datenflüssen würde ich Copilot-Vorschläge niemals ohne gründliche Prüfung übernehmen. Das Modell optimiert für "kompiliert und läuft", nicht für "sicher und compliant". Hier ist menschliche Expertise unverzichtbar.

3. Architekturentscheidungen

Copilot schlägt vor, wie man etwas implementiert — nie warum man es anders implementieren sollte. Die Frage "Soll das ein eigener Microservice werden oder bleibt das im bestehenden Service?" beantwortet kein KI-Tool. Das ist Architekturarbeit, und die bleibt menschlich.

Mein Workflow-Empfehlung für Spring Boot Teams

Nach einem Jahr Praxis habe ich einen Workflow entwickelt, der das Beste aus beiden Welten holt:

  • Copilot aktiviert, aber nicht blind vertraut: Jeden Vorschlag kurz lesen, nicht einfach Tab drücken. Das klingt selbstverständlich, aber im Flow-Zustand passiert es schnell.
  • Für Boilerplate freie Hand: REST-Controller, DTOs, Mapper, einfache Tests — hier einfach annehmen und weiterarbeiten.
  • Bei Domänenlogik: Copilot als Startpunkt, nicht als Ergebnis: Den Vorschlag als Strukturhilfe nehmen, die eigentliche Logik selbst schreiben.
  • Sicherheitsrelevanter Code: Copilot deaktivieren: Ich schalte die Inline-Vorschläge bei Auth-Code bewusst ab — die Ablenkung kostet mehr als sie bringt.
  • Code-Review-Prozess anpassen: Das Team muss wissen, dass Copilot-generierter Code im Review keine Behandlung als "schon geprüft" verdient. Explizit ansprechen.

Fazit

GitHub Copilot ist kein Entwickler-Ersatz — er ist ein sehr guter Autocomplete-Assistent, der ein tiefes Kontextverständnis mitbringt. In einem erfahrenen Enterprise-Team erhöht er die Produktivität messbar, etwa 20–30% bei gut eingespieltem Workflow. In einem unerfahrenen Team kann er Schaden anrichten, weil er selbstsicher klingende, aber falsche Lösungen vorschlägt.

Die entscheidende Frage ist nicht "Copilot ja oder nein?" sondern "Wie integrieren wir KI-Assistenz so in unseren Prozess, dass wir den Nutzen heben ohne die Risiken zu ignorieren?" — Das ist eine Architektur- und Prozessfrage, keine Tool-Frage.

Sie überlegen, KI-Tools in Ihr Entwicklungsteam einzuführen? Ich helfe bei der Auswahl, dem Setup und der Governance — praxisnah, ohne Buzzwords.

Unverbindlich anfragen