Zum Hauptinhalt springen

KI-Schulung für Entwickler am Repository Ihres Teams

Wir zeigen Entwicklerteams, wie sie mit Claude Code, Cursor und GitHub Copilot schneller liefern, ohne dass die Qualität leidet. Keine Übungs-App aus dem Tutorial: Wir arbeiten an Ihrem Code, richten Kontext für Agenten ein, schreiben Tests vor der Implementierung, lesen Diffs, die niemand aus dem Team geschrieben hat, und legen fest, was nicht ins Modell gehört.

  • Claude Code, Cursor und GitHub Copilot
  • Geübt wird am Repository Ihres Teams
  • Der Trainer entwickelt so eigene Produkte im Live-Betrieb
  • Workshop mit 4 oder 8 Stunden

KI-Schulung für Entwickler im Überblick

Die KI-Schulung für Entwickler von Webforte ist ein praktisches Programm für Entwicklerteams, die Code mit KI-Assistenten und Agenten schreiben wollen, ohne die Kontrolle über die Qualität zu verlieren. Gearbeitet wird mit Claude Code, Cursor und GitHub Copilot direkt am Repository des Teams, nicht an einer Übungsanwendung. Das Programm hat sechs Module: Vorbereitung des Repositorys und Regeln für KI, Kontext und Anweisungen für Agenten (CLAUDE.md, AGENTS.md), Generieren und Refactoring mit Review, mit KI geschriebene Tests, Code Review und Sicherheit, agentische Workflows und ihre Grenzen. Dazu gehören Regeln für Secrets im Repository, Lizenzen von generiertem Code und Daten, die nicht ins Modell gehören. Trainer ist Miroslav Douda, Geschäftsführer der Webforte Technologies s.r.o. (IČO 23364343, Prag), der so täglich die eigenen Produkte Kurikula.ai, Dotazio und Chytrejbyt.cz entwickelt. Für Unternehmen außerhalb Tschechiens bieten wir Workshops mit 4 oder 8 Stunden und einen halben Tag für die Leitung an. Das geförderte 50-Stunden-Programm steht nur tschechischen Firmen offen. Den Preis nennen wir nach einem Beratungsgespräch.

Das kennen Sie aus Ihrem Team

KI-Werkzeuge laufen in der Entwicklung inzwischen fast überall. Die Probleme zeigen sich nicht am ersten Tag, sondern nach einigen Wochen in der Git-Historie.

  • Mehr Pull Requests, das Review kommt nicht hinterher

    Der Agent erzeugt in zehn Minuten eine Änderung über zwanzig Dateien. Der Reviewer klickt sie durch, weil die Tests grün sind, und einen Monat später weiß niemand, warum die Funktion so aussieht.

  • Der Agent fängt jedes Mal bei null an

    Im Repository fehlt eine Datei mit Projektregeln. Also wählt der Agent wieder eine andere Formular-Bibliothek, einen anderen Import-Stil und andere Namen. Das Team korrigiert von Hand und hat den Eindruck, die KI bremse.

  • Tests entstehen erst nach dem Code

    Schreibt der Agent Implementierung und Test in einem Zug, bestätigt der Test oft nur, was der Code tut, einschließlich des Fehlers. Eine grüne Pipeline sagt dann nichts aus.

  • Niemand weiß, was ans Modell ging

    Der Inhalt der .env im Kontext, ein Export von Kundendaten im Chat, Code unter NDA in einem Tool ohne Firmenlizenz. Ohne Regeln achtet niemand darauf, und ein Verbot führt nur dazu, dass die Werkzeuge heimlich genutzt werden.

Das Programm in Modulen, an Ihrem Repository

Vor der Schulung klären wir den Zugriff auf das Repository. Dürfen Sie Code wegen eines NDA nicht teilen, bereiten wir ein Übungsprojekt vergleichbarer Größe vor. Jedes Modul endet mit einem konkreten Ergebnis im Repository, nicht nur mit Notizen.

  1. 2 bis 4 Std.

    Repository und KI-Regeln vorbereiten

    Wir gehen Projektstruktur, Build- und Testbefehle sowie die Stellen durch, an denen ein Agent hängen bleibt: fehlende Typen, unklare Ordner, generierte Dateien. Wir richten .gitignore und Ausschlusspfade für die Tools ein, damit Secrets und Build-Artefakte nicht im Kontext landen. Dann entsteht die erste Fassung der Teamregeln: welches Tool wofür, was ohne Review committet werden darf und was nie.

    Ergebnis: Aufgeräumtes Repository und erste Fassung der KI-Teamregeln

  2. 2 bis 4 Std.

    Kontext und Anweisungen für Agenten

    Wir schreiben CLAUDE.md oder AGENTS.md für Ihr Projekt: Architektur, Konventionen, Befehle, verbotene Muster. Wir zeigen, warum eine kurze, präzise Datei besser funktioniert als ein langer Aufsatz, wie man Anweisungen nach Ordnern aufteilt und wie der Agent vor der Arbeit selbst die relevanten Dateien lädt. Dieselbe Aufgabe läuft einmal mit und einmal ohne Kontext, danach vergleichen wir die Diffs.

    Ergebnis: CLAUDE.md oder AGENTS.md, an einer echten Aufgabe geprüft

  3. 2 bis 4 Std.

    Generieren und Refactoring mit Review

    Wir nehmen ein echtes Ticket aus Ihrem Backlog. Erst der Plan, dann kleine Schritte, nach jedem Schritt Compiler und Linter. Beim Refactoring üben wir, die Änderung in einem lesbaren Umfang zu halten und den Agenten zurückzuholen, wenn er außerhalb der Aufgabe umbaut. Jede Person liest einen Diff, den sie nicht selbst geschrieben hat, und erklärt ihn den anderen.

    Ergebnis: Ticket als Pull Request, der das Review bestanden hat

  4. 2 bis 4 Std.

    Tests mit KI schreiben

    Test first: Ein Mensch beschreibt das Verhalten, der Agent schreibt den Test, der Test muss zuerst fehlschlagen, erst dann entsteht die Implementierung. Wir zeigen, wie man Tests erkennt, die nur den Code nachbilden, wie man mit dem Agenten Tests für ungetesteten Altcode ergänzt und wann ein Test von Hand schneller geschrieben ist.

    Ergebnis: Neue Tests für einen gewählten Code-Bereich und Test-first-Ablauf fürs Team

  5. 2 bis 4 Std.

    Code Review und Sicherheit

    Wir erstellen eine Checkliste für das Review von KI-Code: neue Abhängigkeiten, erfundene APIs, stille Verhaltensänderungen, fehlende Eingabevalidierung. Wir behandeln Secrets im Repository und in der Git-Historie, Lizenzen von generiertem Code und Filter für Übereinstimmungen mit öffentlichem Code. Und wir legen fest, was nicht ans Modell geht: Schlüssel, personenbezogene Kundendaten, Code, den ein Vertrag nicht mit Dritten teilen lässt.

    Ergebnis: Review-Checkliste und Sicherheitsregeln in der PR-Vorlage

  6. 2 bis 4 Std.

    Agentische Workflows und Grenzen

    Ein Agent, der selbst Befehle ausführt, braucht klare Berechtigungen. Wir richten eine Liste erlaubter Befehle ein, zeigen parallele Agenten für unabhängige Aufgaben und die Kontrolle per git diff nach jeder Rückmeldung. Vor allem klären wir, wo ein Agent nichts zu suchen hat: Migrationen der Produktionsdatenbank, Zahlungslogik, Rechteänderungen ohne zweites Paar Augen.

    Ergebnis: Eingerichtete Agenten-Berechtigungen und vereinbarte Grenzen fürs Team

Copilot, Cursor oder Claude Code

Wir küren keinen Sieger. Jedes Werkzeug passt zu anderer Arbeit, viele Teams nutzen zwei davon. Der Vergleich stammt aus unserer täglichen Arbeit, nicht aus Benchmarks.

Tabelle seitlich wischen, um alle Spalten zu sehen.

Copilot, Cursor oder Claude CodeGitHub CopilotCursorClaude Code
Wo es läuftErweiterung für VS Code, JetBrains und weitere Editoren, mit GitHub verbundenEigener Editor auf Basis von VS CodeTerminal, mit Erweiterung für VS Code und JetBrains
Wo es am stärksten istVervollständigung beim Tippen und kleinere Änderungen im gewohnten EditorÄnderungen über mehrere Dateien mit Vorschau direkt im EditorLängere Aufgaben, bei denen der Agent das Repository liest, Tests startet und sich korrigiert
Umgang mit KontextOffene Dateien, Repository-Index und Anweisungen in .github/copilot-instructions.mdIndex des ganzen Projekts, Regeln in .cursor/rules, Unterstützung für AGENTS.mdCLAUDE.md auf mehreren Ebenen, Dateien sucht der Agent selbst mit Werkzeugen
Wann wir es empfehlenDie Firma nutzt GitHub Enterprise und will das Tool in der bestehenden LizenzverwaltungDas Team will einen Agenten und trotzdem jede Änderung im Editor sehenErfahrene Teams, die Aufgaben präzise stellen, Rechte begrenzen und größere Diffs lesen
Worauf zu achten istSchnelle Vorschläge verleiten dazu, Code ungelesen zu übernehmenWechsel des Editors, der Einstellungen und Gewohnheiten des ganzen TeamsDer Agent führt Befehle aus, Berechtigungen müssen vorher stehen

Die Werkzeuge ändern sich im Monatstakt. Deshalb vermitteln wir vor allem Prinzipien (Kontext, Plan, Test first, Review, Berechtigungen), die für alle drei gelten. Hat Ihre Firma ein bestimmtes Tool im Einsatz, bauen wir die Schulung darauf auf.

Was wir lehren, weil wir es täglich selbst tun

Unsere Website, Kurikula.ai, Dotazio und Chytrejbyt.cz entwickeln wir mit KI-Agenten. In der Schulung geben wir weiter, was sich bewährt hat, und auch die Fehler, die wir zuerst gemacht haben.

Kontext gehört ins Repository, nicht in den Prompt

Unser eigenes Repository hat eine CLAUDE.md und eine AGENTS.md: Stack, Befehle, Konventionen, Regeln für den Dark Mode, SEO-Vorgaben und was der Agent nicht ändern darf. Jede neue Session startet so mit demselben Wissen. Macht der Agent denselben Fehler zweimal, schreiben wir nicht den Prompt um, sondern ergänzen eine Regel in der Datei. Teams lernen das an ihrem Code: was in den Kontext gehört, was ihn nur aufbläht und wann man die Datei nach Ordnern aufteilt.

  • Eine Regeldatei für das ganze Team, versioniert in Git
  • Befehle für Build, Tests und Lint direkt in den Anweisungen
  • Ein wiederholter Agentenfehler wird zur neuen Regel
  • Eine kurze, präzise Datei wirkt besser als eine lange

Der Compiler ist der erste Reviewer

Wir setzen auf striktes TypeScript, Drizzle ORM und Validierung mit Zod. Der Grund ist praktisch: Ein Agent macht Fehler bei Typen oder im Datenbankschema häufiger als in der Logik, und der Compiler findet sie früher als ein Mensch. Nach jedem Agentenschritt laufen deshalb Typprüfung und Linter, erst ein sauberes Ergebnis geht ins menschliche Review. In der Schulung richten wir diese Schleife für Ihren Stack ein, auch ohne TypeScript.

  • Typprüfung und Lint nach jedem Agentenschritt
  • Starke Typen und Schema als Grenze für generierten Code
  • Eingabevalidierung auf Client und Server
  • Übertragbar auf andere Sprachen und Frameworks

Nach jedem Agenten ein git diff

Arbeiten wir mit mehreren Agenten parallel, bekommt jeder eine unabhängige Aufgabe, und nach seiner Rückmeldung lesen wir immer den git diff, auch wenn der Agent meldet, alles sei im Rahmen geblieben. Agenten ändern gelegentlich Dateien außerhalb der Aufgabe oder löschen Code, den sie für ungenutzt halten. Diese Disziplin vermitteln wir als feste Regel: kein Commit ohne gelesenen Diff. Das klingt nach Aufwand und spart später Stunden bei der Fehlersuche.

  • Ein Agent, eine Aufgabe, klar abgegrenzte Dateien
  • Den Diff liest ein Mensch, auch bei Erfolgsmeldung
  • Änderungen außerhalb der Aufgabe werden zurückgenommen

KI-Ergebnisse müssen überprüfbar sein

In unseren Produkten gilt dasselbe Prinzip wie beim Programmieren. Dotazio antwortet nur aus den gelieferten Unterlagen und nennt die Quelle, Kurikula.ai belegt jeden Vorschlag mit dem Code aus dem tschechischen Rahmenlehrplan, unsere Redaktions-Pipeline für den Blog prüft Quellen vor der Veröffentlichung. In der Entwicklung heißt das: Der Agent darf keine API erfinden, die es im Projekt nicht gibt, und jede Aussage im Pull Request muss sich im Code oder in einem Test nachvollziehen lassen.

  • Prüfen, dass aufgerufene Funktionen und Pakete existieren
  • Neue Abhängigkeiten nur nach bewusster Freigabe
  • Die PR-Beschreibung muss zum tatsächlichen Diff passen

Ein Trainer, der lehrt und entwickelt

Miroslav Douda ist Geschäftsführer und leitender Entwickler von Webforte und war zuvor Pädagoge. Als Trainer hat er mit dem Team von PECKA über 9 000 Lehrkräfte geschult. Die Schulung ist deshalb keine Präsentation mit Demos, sondern Arbeit an der Tastatur: kurze Erklärung, Aufgabe an Ihrem Code, gemeinsames Lesen des Ergebnisses. Sie sprechen direkt mit der Person, die diese Werkzeuge im Live-Betrieb nutzt und weiß, wo sie versagen.

  • Den größten Teil der Zeit arbeiten die Teilnehmenden an eigenem Code
  • Fragen klären wir an konkreten Dateien, nicht abstrakt
  • Derselbe Trainer vom Erstgespräch bis zum letzten Modul

Formate für Teams außerhalb Tschechiens

Die Module stellen wir nach dem Stand Ihres Teams zusammen. Für Unternehmen außerhalb Tschechiens gibt es Formate, die direkt vom Unternehmen bezahlt werden.

WorkshopBis 12 Personen, damit der Trainer die Arbeit jedes Einzelnen am Repository durchgehen kann. Module nach Bedarf, Preis nach Beratungsgespräch.
4 oder 8 Stunden
Halber Tag für die LeitungFür CTOs, Teamleads und Inhaber: Werkzeugwahl, Lizenzen, Regeln für Daten und Sicherheit, Nutzen messen statt schätzen.
bis 8 Personen
Mehrere ModuleDas ganze Programm verteilen wir am besten auf mehrere Termine, damit das Team dazwischen im Alltag üben kann.
je 2 bis 4 Stunden
Gefördertes 50-Stunden-ProgrammDer Zuschuss aus dem Programm Vzdělávání pro firmy kommt vom tschechischen Arbeitsamt und steht nur Unternehmen mit Beschäftigten in Tschechien offen.
nur für tschechische Firmen

Was Ihr Team nach der Schulung hat

Die Ergebnisse bleiben in Ihrem Repository und gehören Ihnen.

  • CLAUDE.md oder AGENTS.md für Ihr Projekt, an einer echten Aufgabe erprobt
  • Teamregeln für KI: welches Tool wofür, was ohne Review geht und was nie
  • Checkliste für das Review von KI-Code in der Pull-Request-Vorlage
  • Sicherheitsregeln: Secrets, personenbezogene Daten, Lizenzen, was nicht ins Modell geht
  • Eingerichtete Agenten-Berechtigungen und eine Liste erlaubter Befehle
  • Mindestens eine echte Änderung, durch Test und Review gebracht
  • Unterlagen zu den Modulen und Teilnahmebestätigung mit Stundenumfang

Für wen die Schulung passt

Sinnvoll, wenn

  • Ihr Entwicklerteam KI-Werkzeuge schon nutzt, aber ohne gemeinsame Regeln
  • Sie die Werkzeuge einführen und Review und Sicherheit gleich mit aufsetzen wollen
  • Sie für die Schulung ein eigenes Repository oder einen Teil davon nutzen können
  • Sie ein kleines Nearshore-Team in Prag suchen, das selbst so entwickelt

Nicht passend, wenn

  • Sie eine KI-Einführung für nicht-technische Kollegen suchen
  • Sie erwarten, dass KI Entwickler ersetzt und Reviews überflüssig werden
  • Sie mit dem geförderten 50-Stunden-Programm rechnen, es gilt nur für tschechische Firmen
  • Sie ein Zertifikat ohne Arbeit an der Tastatur möchten

Häufige Fragen

Der Preis hängt von Format, Anzahl der Module, Gruppengröße und dem Vorbereitungsaufwand für Ihr Repository ab. Unternehmen außerhalb Tschechiens bezahlen den Workshop direkt. Ein konkretes Angebot erhalten Sie nach dem Beratungsgespräch, in dem wir Stack, Erfahrungsstand des Teams und eingesetzte Werkzeuge klären.

Nur als tschechisches Unternehmen. Der Zuschuss aus dem Programm Vzdělávání pro firmy kommt vom tschechischen Arbeitsamt und ist an Beschäftigte in Tschechien gebunden. Für Firmen aus Deutschland, Österreich oder der Schweiz bieten wir Workshops mit 4 oder 8 Stunden, einen halben Tag für die Leitung oder mehrere Module über einige Termine verteilt an.

Ja. Wenn Ihr Team bereits mit Claude Code arbeitet oder es einführen will, bauen wir die Module darauf auf: CLAUDE.md, Berechtigungen, Hooks für Typprüfung und Tests, parallele Agenten und Review. Dasselbe gilt für Cursor oder GitHub Copilot. Die Prinzipien bleiben gleich, nur die Einrichtung unterscheidet sich.

Wir empfehlen es, denn am eigenen Code zeigt sich, womit das Team tatsächlich kämpft: fehlende Tests, große Repositorys, historische Entscheidungen. Dürfen Sie Code wegen eines NDA nicht teilen, bereiten wir ein Übungsprojekt vergleichbarer Größe vor. Möglich ist auch ein ausgewählter Teil des Repositorys ohne sensible Module.

Eine Entwicklerschulung funktioniert online gut, weil alle in ihrer eigenen Umgebung arbeiten und den Bildschirm teilen. Präsenztermine bei Ihnen oder in unserem Büro in Prag vereinbaren wir nach Gruppengröße. Format und Schulungssprache klären wir im Beratungsgespräch.

Dafür gibt es ein eigenes Modul. Wir legen fest, welche Dateien die Werkzeuge ignorieren, wie Secrets aus Repository und Git-Historie herausbleiben und welche Berechtigungen der Agent bekommt. Wir definieren, was nicht ans Modell geht: Schlüssel, personenbezogene Kundendaten und vertraglich geschützter Code. Auch Firmenlizenzen und Datenverarbeitungsbedingungen der Anbieter kommen zur Sprache.

Code aus der Schulung bleibt in Ihrem Repository und gehört Ihnen, ebenso alle Ergebnisse. Bei Lizenzen zeigen wir, warum generierter Code bestehendem Open Source ähneln kann, wie man Filter für Übereinstimmungen mit öffentlichem Code aktiviert und wie neue Abhängigkeiten im Review geprüft werden. Eine Rechtsberatung zu einzelnen Verträgen ersetzt das nicht.

Ja, wir setzen nur an einer anderen Stelle an. Juniors müssen vor allem lesen und prüfen, was der Agent geschrieben hat, und keinen Code übernehmen, den sie nicht verstehen. Erfahrene Teams kommen schneller zu agentischen Workflows, Berechtigungen und paralleler Arbeit. Den Stand der Gruppe klären wir im Erstgespräch.

Stellen wir das Programm für Ihr Team zusammen

Schreiben Sie uns, wie viele Entwickler Sie haben, welchen Stack Sie nutzen und welche KI-Werkzeuge bereits im Einsatz sind. Im Beratungsgespräch schlagen wir Module und Format vor und schicken ein Angebot.

Beratung anfragen