GitHub Copilot: Ein Persona-basierter Ansatz für die Entwicklung in der realen Welt

Wenn Sie GitHub Copilot schon einmal für mehr als nur ein schnelles Boilerplate-Snippet verwendet haben, haben Sie wahrscheinlich folgendes Gefühl: Es ist brillant... bis es das nicht mehr ist.

Im einen Moment vervollständigt es automatisch genau das, was Sie brauchen. Im nächsten Moment generiert es selbstbewusst Unsinn oder verdoppelt das schlechteste Codierungsmuster in Ihrem Repo. Sie wechseln innerhalb eines Herzschlags von "das ist Magie" zu "das hätte ich selbst schneller schreiben können".

Das Problem ist, dass die meisten von uns Copilot wie einen einzigen, allwissenden Assistenten behandeln - eine Art Programmierorakel, das immer "alles im Griff" haben sollte. Aber so arbeiten echte Softwareteams nicht. Bei echten Projekten erwarten Sie nicht, dass ein einziger Entwickler die Anforderungen sammelt, die Architektur entwirft, jede Zeile Code schreibt, die kniffligen Stellen debuggt und dann seine eigene Arbeit überprüft. Das wäre ein Rezept für Burnout (und Bugs).

Warum erwarten wir also, dass Copilot genau das tut?

Nach monatelangem Experimentieren habe ich einen besseren Weg gefunden: Hören Sie auf, Copilot wie einen einzelnen Helfer zu behandeln, und fangen Sie an, ihn wie ein Team zu behandeln.

Genau wie ein echtes Softwareteam Produktmanager, Architekten, Ingenieure und Prüfer hat, habe ich einen Ablauf entwickelt, bei dem Copilot diese Rollen durch Personas übernimmt. In Kombination mit soliden Repo-Leitplanken (Anweisungen, die wie die Onboarding-Dokumente von Copilot wirken) verwandelt dies Copilot von einem "Junior-Entwickler als Joker" in einen zuverlässigen Partner, dem ich beim Produktionscode tatsächlich vertrauen kann.

‌

In diesem Artikel zeige ich Ihnen meinen genauen Ablauf, von der Einrichtung der Repo-Anweisungen über die Definition von Personas bis hin zum Wechsel zwischen ihnen im Visual Studio Code-Chatmodus.

🛠️ Warum Anweisungen wichtig sind

Stellen Sie sich vor, Sie würden einen brandneuen Senior-Entwickler in Ihr Repo einführen.
Würden Sie einfach sagen:
"Hey, hier ist die Codebasis - viel Glück!"

Nein, natürlich nicht. Sie würden Zeit damit verbringen, den Zweck des Projekts, die Eigenheiten, die Architekturmuster und die "Landminen" zu erklären, die sie vermeiden sollten. Ohne diesen Kontext wird selbst der beste Entwickler in die schlechtesten Gewohnheiten des Repo verfallen.

Genau so funktioniert auch der GitHub Copilot. Wenn Sie ihn in Ihr Projekt einbinden, spiegelt er fröhlich den hässlichsten Code, den er finden kann - und er tut dies selbstbewusst.

Hier kommen die Repo-Anweisungen ins Spiel. Betrachten Sie sie als den Leitfaden für die Einführung von Copilot. Anstatt zu raten, erhält Copilot eine klare Beschreibung von:

📄 Meine Einstellung: copilot-instructions.md

Ich beginne ein neues Projekt immer mit der Erstellung einer copilot-instructions.md Datei in einem leeren Ordner. Diese Datei wird zum Playbook von Copilot - Leitplanken + schneller Kontext.

Hier ist ein Auszug aus meinem Projekt Teams Status Manager:

## Project Overview
**Teams Status Manager**: Create/Edit/Delete reusable Teams status templates, apply on demand, and schedule updates.

**Stack**: .NET 9 Minimal API • React (TypeScript, Vite) • SQL Server • Microsoft Graph SDK • Quartz.NET
**Auth Flow**: SPA → API (custom scope) → On-Behalf-Of (OBO) → Microsoft Graph (`Presence.ReadWrite`)

## Architecture Patterns

### Backend (.NET 9 Minimal API)
- **Endpoints**: Located in `src/backend/TeamsStatusManager.Api/Endpoints/` - separate files per feature
- **Services**: Interface/implementation pattern in `Services/` folder
- **Validation**: FluentValidation validators in `Validators/` folder
- **Jobs**: Quartz.NET jobs in `Jobs/` folder with SQL job store
- **Data**: EF Core entities in `TeamsStatusManager.Data/Entities/`

### Frontend (React + TypeScript)
- **Auth**: MSAL React in `src/auth/` with `AuthProvider.tsx` wrapper
- **Data Fetching**: TanStack Query hooks in `src/hooks/` (co-located with features)
- **Forms**: react-hook-form + zod schemas
- **Components**: Feature-based folders in `src/components/`

Diese Datei teilt Copilot mit, wie wir die Dinge hier aufbauen. Anstatt wahllos Code zu generieren, richtet er sich nach denselben architektonischen Regeln, die auch alle anderen Teammitglieder befolgen würden.

⚡ Der Arbeitsablauf

👥 Schritt 2: Arbeiten Sie wie ein Team von Personas

Selbst mit soliden Repo-Anweisungen wurde mir klar, dass ich immer noch den gleichen Fehler machte: Ich behandelte Copilot wie einen einzelnen Entwickler, der alles machen konnte - Anforderungen sammeln, die Lösung entwerfen, sie implementieren und dann debuggen.

So arbeiten echte Teams nicht. Bei einem echten Projekt hätten Sie:

Warum also nicht auf die gleiche Weise mit Copilot arbeiten?

Das war der Zeitpunkt, an dem ich zu einem persona-basierten Ansatz wechselte. Statt eines Copiloten habe ich jetzt mehrere spezialisierte Copilot-Personen, in die ich "wechseln" kann, je nachdem, in welchem Stadium der Entwicklung ich mich befinde.

🧑‍💼 Kernpersönlichkeiten

🔧 Besondere Persönlichkeiten

Jede Persona hat ihre eigene Aufforderung (ich werde meine später in diesem Artikel vorstellen) und ihre eigenen Stärken.

💬 Hinzufügen von Chat-Modi in VS Code

Und jetzt kommt das Beste: Sie müssen nicht jedes Mal Prompts kopieren und einfügen, wenn Sie die Personas wechseln möchten. Mit Visual Studio Code können Sie benutzerdefinierte Chat-Modi hinzufügen, so dass Sie mit einem einzigen Klick direkt in den "Produktmanager-Modus" oder den "Mr. Wolf-Modus" wechseln können.

Hier erfahren Sie, wie Sie sie einrichten können:

Wann immer Sie möchten, dass Copilot als Ihr Architekt, Produktmanager oder Problemlöser agiert, wechseln Sie einfach den Modus. Keine erneute Eingabeaufforderung. Kein Vergessen des Kontexts.

Beispiel:

Es fühlt sich weniger so an, als ob Sie mit einer "KI" sprechen, sondern eher so, als ob Sie ein Team von Spezialisten innerhalb Ihrer IDE leiten.

⚙️ Schritt 3: Der Arbeitsablauf in Aktion

Wenn die Anweisungen für das Projektarchiv stehen und die Personas bereit sind, fühlt sich der Entwicklungsprozess weniger wie die Anweisung einer KI an, sondern eher wie die Koordination eines kleinen Entwicklerteams. Jede Phase hat ihren eigenen "Besitzer", und Copilot bleibt fokussiert, anstatt in zufällige Vermutungen abzudriften.

So sieht mein Arbeitsablauf in der Praxis aus:

1. Erfassen von Anforderungen (Persona Produktmanager)

Ich beginne mit der Persona des Produktmanagers, die vage Ideen für Funktionen in klare Produktanforderungen umwandelt.

Für jede Funktion erstellt der Produktmanager eine PRD-Datei im Ordner docs ( z.B. docs/save-data-prd.md)

Dieser Schritt hält mich davon ab, mich in die Umsetzung zu stürzen, bevor ich weiß, wie "fertig" aussieht.

‌

2. Entwerfen der Lösung (Persona Softwarearchitekt)

Sobald die Anforderungen feststehen, wechsle ich zur Persona des Softwarearchitekten.

Für jede Funktion erstellt der Softwarearchitekt eine techspec-Datei im Ordner docs (z.B. docs/save-data-techspec.md).

An dieser Stelle hört Copilot auf zu raten und arbeitet nach einem konkreten Plan.

‌

3. Implementierung der Funktion (Engineer Persona)

Jetzt bringe ich die Person des Ingenieurs ins Spiel.

Hier macht sich der Produktivitätsgewinn wirklich bemerkbar: Copilot schreibt den Code, aber er tut dies innerhalb des von mir bereits definierten Rahmens.

‌

4. Fehlersuche und Testen (Spezielle Personas)

Unvermeidlich, dass etwas nicht wie erwartet funktioniert. In diesem Fall wechsle ich zu den speziellen Personas:

Diese Personas bewahren mich vor der Endlosschleife "Erstellen → Testen → Seufzen → Verbessern → Wiederholen". Stattdessen wird Copilot zu meinem QA-Sicherheitsnetz.

‌

Indem ich diese Phasen durchlaufe, fordere ich Copilot nicht einfach nur auf, zu programmieren. Ich leite einen strukturierten Prozess, bei dem die KI wie verschiedene Teammitglieder mit spezifischen Aufgaben agiert .

Das Ergebnis? Zuverlässigerer Code, weniger Umwege und ein Arbeitsablauf, der sich anfühlt, als würden Sie mit einem echten Team zusammenarbeiten, anstatt mit der Autovervollständigung zu kämpfen.

‌

🧩 Beispiel: Teams Status Manager Projekt

Um das Ganze etwas weniger abstrakt zu gestalten, möchte ich Ihnen zeigen, wie ich diesen Ablauf auf ein reales Projekt angewendet habe: Teams Status Manager.

Das Ziel war auf dem Papier einfach: Erstellen, bearbeiten und löschen Sie wiederverwendbare Teams-Statusvorlagen. Wenden Sie sie bei Bedarf an oder planen Sie Aktualisierungen automatisch.

Aber wie jeder Entwickler weiß, verbirgt sich hinter "einfach auf dem Papier" oft eine Menge an beweglichen Teilen. Hier sehen Sie, wie sich der Persona-basierte Ansatz und die Repo-Anweisungen entwickelt haben.

‌

📝 Schritt 1: Repo-Anweisungen

Ich habe mit der Datei copilot-instructions.md.instructions.md begonnen.

Darin werden der Zweck des Projekts, der Stack und die Architekturleitplanken beschrieben.

Das bedeutete, dass Copilot es im Voraus wusste:

Ohne dies hätte Copilot fröhlich Muster gemischt, neue Ordner erfunden oder Logik an die falschen Stellen gestopft. Mit den Anweisungen fühlte er sich bereits auf mein Projekt "trainiert".

🧑‍💼 Schritt 2: Personas in Aktion

⚡ Das Ergebnis

Anstatt dass Copilot das generiert, was es für richtig hält, arbeitet es wie ein echtes Entwicklerteam:

Am Ende hatte ich nicht nur Code, der sich kompilieren ließ - ich hatte eine Lösung, die auf meine Architektur abgestimmt und für echte Benutzer bereit war.

🌟 Vorteile des Persona-Ansatzes

Nach monatelangem Experimentieren hat dieser persona-basierte Ansatz meine Arbeit mit GitHub Copilot völlig verändert. Anstelle von "manchmal brillant, manchmal frustrierend" ist er zu einem beständigen Partner geworden, dem ich bei realen Projekten vertrauen kann.

Hier ist der Grund, warum das so gut funktioniert:

✅ 1. Struktur schlägt Chaos

Ohne Personas versucht Copilot, alles auf einmal zu machen - Anforderungen, Design, Code, Debugging - und schneidet dabei in der Regel ab. Indem Sie Rollen zuweisen, bringen Sie Struktur in dieInteraktion. Copilot kennt seine Aufgabe, genau wie ein menschlicher Teamkollege.

✅ 2. Repo-Leitplanken = Konsistenz

Die Datei copilot-instructions.md ist das Onboarding-Dokument für jeden KI-Assistenten, der das Repo berührt. Unabhängig vom Modell bleibt die Architektur konsistent. Dadurch werden die Momente vermieden, in denen Sie sich fragen: "Warum gibt es jetzt einen zufälligen utils-Ordner?".

✅ 3. Schnellere Iteration, weniger Frustration

Anstatt sich mit Copilot herumzuschlagen, wenn er vom Weg abkommt, wechseln Sie einfach die Personas.

Dies erspart stundenlanges Umschalten zwischen den Kontexten und erneute Eingabeaufforderungen.

✅ 4. Eingebaute Qualitätskontrolle

Die meisten Entwickler verlangen nicht, dass Copilot seine eigene Ausgabe überprüft. Mit dem Tech Spec Reviewer und dem Implementation Reviewer erhalten Sie ein eingebautes Sicherheitsnetz. Sie prüfen nicht nur - sie erkennen Skalierbarkeitsprobleme, Race Conditions und übersehene Schritte, bevor sie in Ihrem Code landen.

✅ 5. Skaliert mit Komplexität

Bei einer kleinen Funktion brauchen Sie vielleicht nur PM → Architekt → Ingenieur. Bei einem komplexen Unternehmensablauf können Sie Prüfer und Problemlöser hinzuziehen. Das Modell lässt sich wie ein Team skalieren: Fügen Sie weitere Spezialisten hinzu, wenn das Projekt wächst.

Mitbringsel

GitHub Copilot wird oft als "KI-Paarprogrammierer" vermarktet, aber wenn Sie erwarten, dass er ein einzelner, allwissender Programmierpartner ist, werden Sie irgendwann auf eine Mauer der Frustration stoßen. Der wirkliche Durchbruch kommt, wenn Sie Copilot nicht mehr als einen Assistenten, sondern als ein Team behandeln.

Durch Kombination:

...Copilot verwandelt sich von einem Platzhalter in einen strukturierten, zuverlässigen Mitarbeiter.

Für mich hat dieser Ansatz Copilot von einem "Tool, mit dem ich manchmal kämpfe" zu einem "Entwicklerteam, das ich leite" gemacht.

👉 Kopieren Sie nicht einfach meine Personas - erstellen Sie Ihre eigenen. Welche Rollen würde Ihr Copilot-Team haben? Ein Sicherheitsprüfer? Ein Leistungsoptimierer? Ein Dokumentationsschreiber?

Sie finden alle meine Personas in diesen Gists, die ich erstellt habe, um sie mit Kunden und der Community zu teilen, hier: #🚀 GitHub Copilot: Ein Persona-basierter Ansatz.md