Euer Team lernt Agentic Engineering mit den Copilot-Lizenzen, die es schon hat.

So läuft die Schulung mit GitHub Copilot

hackers&wizards gibt GitHub-Copilot-Schulungen für Entwicklerteams als Inhouse-Teamschulung: zwei Tage, remote oder vor Ort in Deutschland, Österreich und der Schweiz, auf Deutsch oder Englisch, danach Mentoring, während euer Team das Gelernte in echter Arbeit anwendet. Es ist unsere Schulung Agentic Engineering for Developers and QA, auf euren Copilot-Lizenzen.

1.500 EUR pro Person. Teamschulung, höchstens 15.000 EUR für die zwei Tage: bis zu 12 Personen nehmen teil, ihr zahlt höchstens für 10. Netto zzgl. USt., vor Ort zzgl. Reisekosten nach Aufwand.

Teams haben jedes unserer Trainings für Engineering, Produkt und Führung schon in GitHub Copilot durchlaufen.

2026 haben die Tech- und Data-Teams eines Energieversorgers, rund 50 Leute aus allen Rollen, in drei Remote-Gruppen nach Stack mit Copilot CLI trainiert. Das Team eines Versicherungssoftware-Anbieters, 22 Personen, hat zwei Tage mit GitHub Copilot trainiert.

Was bei GitHub Copilot anders ist

Nach der Schulung legt euer Team jede Instruktion in eine Datei, die die genutzte Copilot-Oberfläche auch wirklich liest, und entscheidet pro Tool, was Copilot ohne Rückfrage darf.

• Drei Arten von Instruktionsdateien

  .github/copilot-instructions.md gilt für das ganze Repository, .github/instructions/*.instructions.md für die Pfade im applyTo-Glob, und AGENTS.md, CLAUDE.md oder GEMINI.md dienen als Agent Instructions. Copilot CLI und der Cloud Agent lesen alle drei. Copilot Chat in VS Code liest die ersten beiden und die AGENTS.md, Copilot Chat in JetBrains-IDEs nur die ersten beiden.

• Custom Agents, Skills und Hooks

  Custom Agents sind .agent.md-Dateien unter .github/agents. Skills liegen in .github/skills, .agents/skills oder .claude/skills, Skills aus Claude Code lassen sich also direkt übernehmen. Hooks sind JSON-Dateien unter .github/hooks, für Copilot CLI und den Cloud Agent.

• MCP, GitHub schon verbunden

  In Copilot CLI ist der GitHub-MCP-Server ab Werk verbunden. Weitere Server fügt jede Person mit /mcp add oder in ~/.copilot/mcp-config.json hinzu, fürs ganze Team gehören sie in .github/mcp.json im Repository.

• Freigaben pro Tool, Sandbox auf Wunsch

  Copilot CLI liest und durchsucht frei. Bevor es Dateien ändert, einen verändernden Befehl ausführt oder eine URL öffnet, fragt es nach. --allow-tool und --deny-tool legen für eine Session Regeln pro Tool fest, und eine Deny-Regel gilt sogar gegen --allow-all. Die lokale Sandbox ist aus, bis ihr sie mit /sandbox enable oder --sandbox einschaltet. --yolo gibt alle Tools, Pfade und URLs auf einmal frei und gehört deshalb in die Sandbox, mit abgeschalteten Bypass-Anfragen.

• Die IDE macht einen Unterschied

  In unseren Schulungen lief der Agent von Copilot in VS Code gut und in IntelliJ schlecht (Januar 2026). Teams mit JetBrains-IDEs trainieren deshalb in Copilot CLI, das dieselben Instruktionsdateien liest.

Was ihr bereitstellt

• Eine Copilot-Lizenz pro teilnehmender Person. Mit Business oder Enterprise verwaltet eure Organisation die Copilot-Policies für das ganze Team. Copilot CLI ist in jedem Copilot-Plan enthalten, bei Lizenzen einer Organisation muss aber die Copilot-CLI-Policy aktiv sein. Das prüfen wir vor dem ersten Tag mit euch.
• Unsere gehostete Trainingsumgebung läuft mit Claude Code, eine Copilot-Schulung findet deshalb auf euren Rechnern und Lizenzen statt. Euer Code bleibt, wo er ist: Wir arbeiten mit eurem Team am Bildschirm.
• Klärt mit eurer Security, welche Rechte die Teilnehmenden vergeben dürfen. Manche Unternehmen verbieten --allow-all-paths, und alle Übungen funktionieren auch ohne.

So sind Lizenzen und Rechte geklärt, bevor der erste Tag in Copilot beginnt.

Der erste Tag mit GitHub Copilot

Nach dem ersten Tag kann euer Team prüfen, ob eine Instruktion greift, Copilot eine Spec im Plan-Modus übergeben und Pushes auf main dauerhaft mit einem Hook sperren.

So lief der erste Tag in einer Copilot-CLI-Schulung, die wir gegeben haben. Wir schneiden ihn im Vorbereitungsgespräch auf eure Codebasis zu.

• Prüfen, ob die Instructions greifen

  Die Teilnehmenden schreiben eine copilot-instructions.md, stellen eine Frage, ändern eine Regel und fragen noch einmal. Dann beenden sie Copilot und machen mit copilot --resume in derselben Session weiter. Der typische Fehler: eine Regel, die Copilot nie sieht, weil die Datei im falschen Ordner liegt. Deshalb lassen wir alle prüfen, ob sich die Antwort wirklich geändert hat.

• Spec-​Sprint im Plan-​Modus

  Das Team schreibt die Repository-Instructions, entwirft mit Copilot eine Feature-Spec und übergibt sie im Plan-Modus. Der stellt Rückfragen, bevor sich Code ändert. Mit /model vergleichen die Teilnehmenden zwei Modelle an derselben Spec.

• Erst sperren, dann laufen lassen

  Am Ende des Tages sind Pushes gesperrt, und die freigegebenen Tools laufen ohne Rückfrage. Jeden Push in der Session sperren die Teilnehmenden mit --deny-tool='shell(git push)', einen Push auf main dauerhaft mit einem preToolUse-Hook in .github/hooks. Der liegt im Repository und gilt in jeder Session. Für alles andere läuft Copilot mit --allow-tool, und ein Review-Agent in .github/agents prüft das Ergebnis vor dem Pull Request.

Was gleich bleibt

Die Praxis ist in jedem Agenten dieselbe: wie die Agenten-Schleife funktioniert, welchen Kontext der Agent braucht, wie ihr so delegiert, dass er seine Arbeit selbst prüft, und wie das ganze Team eine Arbeitsweise behält. Agenda, Trainer:innen und Mentoring sind die der Schulung, die ihr bucht.

Fragen, bevor ihr bucht

Quellen

Alle Herstellerangaben auf dieser Seite haben wir am 27. Oktober 2026 in der Dokumentation des Herstellers nachgelesen.