Letzten Monat. Ein Maschinenbau-Zulieferer in Süddeutschland, 180 Mitarbeitende, drei Entwickler im Team. Der Teamleiter zeigt mir stolz, dass sie Copilot jetzt "im Einsatz" haben. Ich schaue auf den Bildschirm: Er lässt Copilot Getter und Setter generieren. In einer Legacy-Codebase aus 2011, die noch auf .NET Framework 4.7 läuft. Die monatlichen Lizenzkosten: 57 Euro. Der tatsächliche Zeitgewinn gegenüber einem Snippet-Template: schwer messbar.
Das ist kein Einzelfall. Es ist das typische Muster, das ich sehe, wenn KMUs Copilot einführen, ohne vorher zu klären, für welchen Schmerz sie eigentlich ein Werkzeug suchen.
Was Microsoft schreibt — und es ist gut gemeint
Der .NET Blog-Artikel von Microsoft ist handwerklich ordentlich. Der Kerngedanke: Hör auf zu fragen, welches Copilot-Feature du ausprobieren sollst, und fang an zu fragen, welchen Teil deiner Aufgabe du delegieren kannst. Der Artikel zeigt fünf konkrete Chat-Beispiele — Legacy-Code verstehen, Tests generieren, Refactoring planen, Cross-File-Änderungen in VS Code, Build-Fehler debuggen — und erklärt, wann Inline-Completion endet und agentic Workflows anfangen. Der Tipp mit den vier Bausteinen für gute Prompts (Ziel, Code, Constraint, erwartetes Antwort-Shape) ist konkret und sofort anwendbar.
Wer hauptberuflich .NET-Entwickler ist, in einem Unternehmen mit dediziertem Entwicklungsteam, aktuellem .NET 8/9-Stack und Visual Studio Enterprise — für den ist das ein brauchbarer Leitfaden.
Wo die KMU-Realität anders aussieht
Das Problem ist nicht, was der Artikel sagt. Das Problem ist, was er voraussetzt.
Voraussetzung 1: Ein homogener .NET-Stack. In meinen Mandaten sehe ich regelmäßig Teams, die gleichzeitig eine ASP.NET Core Web-API warten, ein altes WinForms-Tool pflegen, das keiner anfassen will, und ein PHP-Portal betreiben, das "irgendwann mal" migriert werden soll. Copilot ist an diesem Punkt kein uniformes Werkzeug — es ist eine weitere Variable, die Kontextsprünge erzeugt. Wer zwischen drei Technologien und vier Projekten wechselt, hat keine Zeit, für jedes Projekt den optimalen Prompt-Stil zu erlernen.
Voraussetzung 2: Entwickler, die Prompting als Skill ernst nehmen. Die vier Bausteine — Ziel, Code, Constraint, Shape — sind richtig. Aber in Teams von drei bis fünf Entwicklern, die primär Features liefern und keine Slack-Kanäle mit AI-Experimenten betreiben, schreibt niemand systematisch bessere Prompts. Der Artikel erklärt das Muster, aber nicht die Lernkurve dahinter. Aus meiner Erfahrung: Es dauert sechs bis acht Wochen täglicher Nutzung, bis ein Entwickler intuitiv unterscheidet, wann Chat hilft und wann er schneller selbst tippt. In Teams ohne Austausch über diese Erfahrungen verläuft diese Lernkurve flacher.
Voraussetzung 3: Zeit für Refactoring und Test-Coverage. Der Use Case "Generiere fehlende Unit Tests für CreateOrder" klingt attraktiv. In einem KMU-Entwicklungsteam, das seit Jahren im Modus "Feature rein, Support rein, nächstes Feature" arbeitet, gibt es oft keine Ticket-Kategorie für "Test-Lücken schließen". Ich habe Mandanten, die wissen, dass ihre Test-Coverage bei unter 20 % liegt — und die diese Zahl nicht ändern, nicht weil sie es nicht wollen, sondern weil kein Sprint-Slot dafür existiert. Copilot löst kein Priorisierungsproblem.
Was sich trotzdem lohnt — konkret
Ich sage das nicht, um Copilot schlecht zu reden. Ich empfehle es aktiv — aber für andere Use Cases als die im Artikel genannten.
Use Case 1: Legacy-Code verstehen, bevor man ihn anfasst. Das ist der einzige Punkt aus dem Artikel, den ich 1:1 unterschreibe. Die Prompt-Variante "Erkläre, was dieser Service macht, trenne Business Logic von Infrastructure, und schlag einen ersten sicheren Refactoring-Schritt vor" ist exakt das, was einem Junior-Entwickler in einem KMU zwei Stunden erspart, in denen er sonst Git-History und Kommentare aus 2015 entziffert. Hier rechnet sich Copilot schon nach dem zweiten Einsatz.
Use Case 2: Boilerplate in neuen Projekten. Minimal API Endpoints verdrahten, DTOs erzeugen, Entity Framework Konfigurationen aufbauen — das sind Aufgaben, bei denen Copilot schnell und zuverlässig ist. Nicht weil es kreativ ist, sondern weil diese Aufgaben repetitiv und strukturiert sind. In einem KMU-Team, das alle paar Monate ein neues Modul anfängt, zahlt sich das aus.
Use Case 3: Das CLI für Build-Fehler. Der Vorschlag im Artikel, Copilot CLI bei dotnet build-Fehlern einzusetzen, ist pragmatisch. Fehleranalyse ist zeitaufwendig, und die Qualität der Erklärungen ist inzwischen gut genug für die häufigsten Fehlerkategorien. Gerade für weniger erfahrene Entwickler ist das ein echter Zeitgewinn.
Was ich dagegen aus KMU-Projekten raushalten würde: Agentic Workflows für mehrschrittige Tasks. Nicht weil die Technologie schlecht ist, sondern weil das Reviewing des Outputs Zeit kostet, die in kleinen Teams knapp ist. Wenn Copilot 40 Tests generiert und ich 20 Minuten brauche, um sie zu verstehen und zu validieren, habe ich keinen Netto-Vorteil gegenüber einem Entwickler, der 15 Tests schreibt und sie selbst versteht.
Die eine Empfehlung, die ich dir gebe
Bevor du das nächste Copilot-Feature evaluierst, beantworte diese eine Frage ehrlich: Wo verliert dein Team heute tatsächlich Zeit?
Nicht gefühlt. Tatsächlich. Eine Woche Zeiterfassung auf Aufgaben-Ebene — nicht Projekte, sondern Tätigkeiten — reicht, um das zu beantworten. In fast jedem KMU-Entwicklungsteam, das ich begleite, sind es dieselben drei Kategorien: unbekannten Code verstehen, Bugs lokalisieren, Deployments koordinieren. Copilot hilft bei der ersten Kategorie gut, bei der zweiten mäßig, bei der dritten kaum.
Wenn dein Team dagegen vor allem an Feature-Velocity scheitert — zu langsam in der Umsetzung klarer Anforderungen — dann ist das oft kein Werkzeug-Problem, sondern ein Architektur- oder Anforderungsproblem. Copilot macht schneller, was du schon tust. Es ändert nicht, was du tust.
Der .NET Blog-Artikel ist eine gute Quelle für Entwickler, die Copilot gezielt einsetzen wollen und die nötigen Rahmenbedingungen mitbringen. Für KMUs ist er ein Ausgangspunkt — aber kein vollständiges Bild.
Der vollständige Original-Beitrag von .NET Blog (MS): Doing More with GitHub Copilot as a .NET Developer
Wenn du wissen willst, ob und wo Copilot in deinem Team konkret Zeit spart — ohne Lizenz-Pitch und ohne Feature-Demo:
— Bernhard