KI-Coding-Schulung

Schulung für KI-Coding-Agenten in deiner Codebasis, nicht an einer Spielzeug-Demo.

Dein Team hat längst Zugriff auf Coding-Agenten. Was fehlt, ist eine gemeinsame Arbeitsweise: wie der Agent den richtigen Kontext bekommt, wie ihr prüft, was er schreibt, was er nie zu sehen bekommt und woran ihr erkennt, ob er wirklich hilft. Genau das trainieren wir in deinem Repository, mit den Tools, die dein Team nutzt.

Teamschulung besprechen →

KURZ ERKLÄRT

Eine Schulung für KI-Coding-Agenten bringt einem Softwareteam bei, mit Tools wie Claude Code, Cursor oder Codex im eigenen Repository zu arbeiten. Dazu gehören Kontext-Setup, Aufgabenzuschnitt, Code-Review, Sicherheit, Secret-Hygiene und die Messung, ob die Agenten dem Team helfen.

Passt für

  • Engineering-Teams, die Coding-Agenten einzeln und uneinheitlich nutzen und eine gemeinsame Praxis wollen
  • Tech Leads, die Review- und Sicherheitsregeln brauchen, bevor sich die Nutzung weiter ausbreitet

Eine andere Leistung passt besser

  • Fachabteilungen, die KI-Anwendungsfälle außerhalb der Softwareentwicklung suchen
  • Eine mit KI-Tools gebaute App, die jetzt ein Audit und Fixes braucht

Training für Engineers, die Code ausliefern, kein KI-Strategietermin

Diese Leistung richtet sich an Leute, die täglich Code schreiben und reviewen. KI-Anwendungsfälle in Geschäftsprozessen finden gehört zu unseren Workshops. KI im ganzen Unternehmen einführen, mit Tools, Schutzmaßnahmen und interner Automatisierung, gehört zum KI-Enablement. Wenn eine App schon mit KI-Tools gebaut wurde und jetzt bricht, prüft und repariert sie Vibe Coding Rescue. Prüfungen in der Pipeline durchsetzen, damit agentengeschriebene Änderungen dieselben Gates passieren wie alles andere, gehört zu DevSecOps. Die Schulung bereitet dein Team auf diese Gates vor; sie ersetzt sie nicht.

In deiner Codebasis arbeiten, denn dort gelingen oder scheitern Agenten

Ein Agent, der eine saubere Demo-App schreibt, kann sich in einem großen, echten Repository trotzdem verlaufen. Der Unterschied liegt meist im Kontext, nicht in der Intelligenz des Modells. Das zeigen wir in Kontext für Coding-Agenten. Deshalb laufen die Sessions auf deinem Code oder einer bereinigten Kopie davon.

Agenten-Anweisungen

Eine gepflegte Anweisungsdatei mit Build-Befehlen, Konventionen und Sperrzonen, geschrieben für die Tools, die dein Team wirklich nutzt.

Aufgabenzuschnitt

Kleine, prüfbare Aufgaben mit Plan vorweg. Wann du den Agenten laufen lässt, wann du ihn stoppst und wann du den Code selbst schreibst.

Tests als Rückkopplung

Agenten arbeiten besser, wenn ein Test oder Typcheck Nein sagen kann. Wir schauen, wo deine Testsuite schnelles, ehrliches Feedback gibt und wo nicht.

Repository-Kontext

Doku, Modulübersichten und Repo-Maps, und ob sie ins Git gehören. Unser [Graft Review](/de/blog/graft-review-agent-repo-map/) beantwortet diese Frage für ein Tool im Detail.

Review-Praxis für Code, den niemand getippt hat

Verantwortlich für eine agentengeschriebene Änderung bleibt die Person, die den Pull Request öffnet. Das Team legt fest, was das heißt: wie groß eine Änderung sein darf, was der Autor vor dem Review ausgeführt und gelesen haben muss, wie Reviewer Diffs lesen, die plausibel aussehen, aber nie durchdacht wurden, und welche Bereiche immer einen zweiten Menschen brauchen. Wir üben das an echten Änderungen aus deinem Backlog, auch an solchen, die der Agent falsch macht.

Secrets, Berechtigungen und was den Rechner verlässt

Coding-Agenten lesen Dateien, führen Befehle aus und schicken Kontext an einen Modellanbieter. Die Schulung behandelt Secret-Hygiene (keine Keys in Prompts, Anweisungsdateien oder Logs), die Rechte jedes Tools auf dem Entwicklerrechner, Sandboxing für Befehle, Prompt Injection über Repository-Inhalte und Abhängigkeiten sowie die Frage, welcher Code laut deinen Verträgen das Unternehmen verlassen darf. Die technische Durchsetzung in der CI gehört zu DevSecOps; hier lernt dein Team die Gewohnheiten, damit die Pipeline nicht die einzige Verteidigungslinie ist.

Messen, ob es hilft, statt zu raten

Wir versprechen keinen Produktivitätsgewinn in Prozent. Das Ergebnis hängt von Codebasis, Aufgabenmix, Tools und Menschen ab. Stattdessen wählt dein Team vor der Schulung ein paar Signale, etwa die Durchlaufzeit für einen Aufgabentyp, Nacharbeit im Review, Fehler nach dem Merge und Toolkosten pro Engineer, und prüft sie nach einer vereinbarten Pilotphase erneut. Wenn der Agent bei einer Art von Arbeit nicht hilft, ist das ein gültiges Ergebnis. Modellwahl und Kostensteuerung für ein verbreitetes Tool behandelt Claude Fable 5.1 in Claude Code nutzen.

Vorbereiten, trainieren, nach der Pilotphase auswerten

Umfang, Format und Honorar vereinbaren wir vor der Buchung. Remote-Sessions funktionieren international; Termine vor Ort kalkulieren wir separat.

  1. Vorbereitung

    Teamgröße und Erfahrung, genutzte oder getestete Tools, Repository-Zugriff oder eine bereinigte Kopie und eine kurze Liste echter Aufgaben zum Üben.

  2. Praxis-Sessions

    Arbeitssessions an den vereinbarten Aufgaben, am Ende ein schriftliches Team-Playbook, eine Anweisungsdatei und die Signale, die ihr verfolgt.

  3. Folgetermin

    Nach der Pilotphase eine Auswertung der Signale, des Playbooks und der Fehlerfälle. Weitere Sessions vereinbaren wir separat.
// beweise

Woher das Material kommt

Einen veröffentlichten Kundenfall für diese Schulung haben wir noch nicht, und wir behaupten auch keinen. Das Material stammt aus Wavects eigener täglicher Engineering-Praxis: Wir bauen Kundensoftware und diese Website jeden Tag mit Coding-Agenten und veröffentlichen, was wir dabei lernen, im Blog, darunter die oben verlinkten Artikel. Das ist unsere eigene Praxis, keine Ergebnisgarantie für dein Team.

Fragen vor dem Start

Die, die dein Team nutzt oder testet, zum Beispiel Claude Code, Cursor, Codex oder Open-Source-Agenten. Die Schulung ist anbieterneutral. Wir haben keine Partnerschaft mit einem KI-Anbieter und verkaufen keine Lizenzen, deshalb sagen wir auch, wenn ein Tool schlecht zu deiner Arbeit passt.
Mit deinem echten Repository wird die Schulung am nützlichsten. Wenn das nicht geht, nehmen wir eine bereinigte Kopie oder ein öffentliches Projekt mit ähnlichem Stack. Zugriff, Datenumgang und welcher Agent welchen Code sehen darf, vereinbaren wir vor der ersten Session.
Das versprechen wir nicht. Die Schulung richtet eine Messung ein, mit der dein Team den Effekt auf die eigene Arbeit sieht, und der Folgetermin schaut sich die gesammelten Zahlen an.
Ja, wenn die Gruppe dafür geplant ist. Juniors und Seniors brauchen unterschiedliche Regeln, wann sie einem Agenten trauen. Teilnehmermix und Gruppengröße klären wir beim Scoping.
Das ist eine Praxisschulung, keine akkreditierte Zertifizierung. Wenn du formale Schulungsanforderungen hast, sag es beim Scoping, dann vereinbaren wir, welche Dokumentation möglich ist.

Der passende nächste Schritt

Teamschulung besprechen

Beschreib das Team, den Stack, die genutzten oder getesteten Coding-Agenten und was noch nicht funktioniert. Für das erste Gespräch reicht ein kurzer Überblick ohne vertrauliche Details.

Teamschulung besprechen →