Wie leitet man AI-Coding Workshops am besten?

Geschrieben von Fachexperten: Timon Fiddike, CST®, Machine Learning seit 2005

Hintergrund

Mittlerweile habe ich ganz verschiedene AI-Coding Workshops geleitet, mit einer Dauer von 1, 2 und 3 Tagen, mit großen Gruppen, kleinen Gruppen und 1:1, remote, vor Ort und Hybrid. Beim AI-Camp Berlin und auf der P4A 2026 habe ich dann jeweils zu einer Session eingeladen, um mit anderen Workshopleitern gemeinsam zu reflektieren, wie man AI-Coding Workshops im besten Fall leitet.

Absprachen mit den jeweiligen Kunden geben natürlich den Rahmen vor, aber: In einigen Bereichen habe ich schon den Eindruck, dass sich “Good Practices” oder sogar “Best Practices” herauskristallisieren, die ich bei der Gestaltung zukünftiger Workshops einbeziehen werde und in der gemeinsamen Vorbereitung mit Kunden empfehlen werde.

Eigenschaften von AI-Coding Workshops

Meine bisherigen AI-Coding Workshops waren sehr unterschiedlich in Bezug auf die folgenden Eigenschaften:

• Anzahl der Teilnehmenden (1-10)
• Hierarchie-Ebene der Teilnehmenden (Dev, Teamleiter, Abteilungsleiter, CTO)
• vollständig vor Ort, hybrid, vollständig remote
• Art der Coding Agenten: CLI vs IDE
• Betriebssysteme der Teilnehmenden (macOS, Windows, Linux)
• Legacy Code oder Neuentwicklung
• Tech-Stack (von PHP bis .NET, Webservice bis Smartphone App)
• Anteile Erklärung vs. “Ausprobieren lassen”
• Anteil Diskussion unter den Teilnehmenden
• Widerstand und Umgang mit Ängsten

Diese Eigenschaften haben durchaus unterschiedlich viel Bedeutung:

Anzahl der Teilnehmenden

In meinen 1:1 Workshops war es für mich besonders leicht, mich auf den Bedarf der jeweils teilnehmenden Personen einzustellen.

Nun könnte man denken, dass der Bedarf der Teilnehmenden eher heterogener wird, je größer die Gruppe wird, oder das natürlicherweise mehr Diskussionen aufkommen, wenn mehr Personen beteiligt sind. Diese Gedanken wären naheliegend, tatsächlich habe ich diese Zusammenhänge aber so nicht beobachtet, sondern:

Ich habe größere Gruppen erlebt, die sehr diskussionsfreudig waren, und andere größere Gruppen, die mit kurzen Diskussionen sehr zielgerichtet gearbeitet haben. Relativ zur Gruppengröße sind also andere Eigenschaften der Gruppe bedeutsamer.

Hierarchie-Ebene der Teilnehmenden

Neben hauptberuflichen Entwicklern haben auch Teamleiter und Abteilungsleiter an meinen Workshops teilgenommen, in einem Fall auch ein CTO.

Nun könnte man denken, dass Personen, die seit Jahren nicht mehr hauptberuflich entwickeln, Schwierigkeiten hätten, in solchen Workshops zu folgen. Tatsächlich habe ich das Gegenteil beobachtet: Führungspersonen haben zwar nicht unbedingt alle relevanten technischen Details präsent, dafür können sie gut abstrahieren und Anweisungen geben. In der Arbeit mit Agenten sind die Führungsfähigkeiten von Teilnehmenden sehr wertvoll.

Vor Ort, hybrid, vollständig remote

Die Workshops, die entweder vollständig vor Ort oder vollständig remote stattgefunden haben, habe ich jeweils als besonders produktiv erlebt.

Vor Ort konnten wir uns vollständig auf die Arbeit mit den Agenten konzentrieren.

Remote mussten wir natürlich auch die Werkzeuge für die Videokonferenz und so weiter berücksichtigen, dies war jedoch für alle Beteiligten einheitlich, und rückte schnell in den Hintergrund. In beiden Fällen konnten wir uns leicht auf die produktive Arbeit konzentrieren.

Hybrid gab es am meisten Reibung, und die Beschäftigung mit Fragen des Raumes und der Videokonferenz und so weiter brauchte mehr Aufmerksamkeit als in den oben genannten Settings. In manchen Momenten ist es hilfreich, mit der gesamten Gruppe einen gemeinsamen Fokus zu haben, in anderen Momenten arbeiten wir parallel in Kleingruppen. In den “vollständig vor-Ort” / “vollständig remote” Settings kann man als Leiter eines Workshops zunächst einmal alle Teilnehmer einheitlich betrachten. Menschen haben zwar verschiedene Fähigkeiten, aber alle haben die gleichen Möglichkeiten, miteinander zu interagieren. Im Hybrid Setting kommen hier weitere Fragen und Beschränkungen auf:

In einem Workshop habe ich z.B. wie gewohnt vorgeschlagen, dass beim Bilden von Paaren oder Kleingruppen jeweils mindestens eine Person in der Kleingruppe vor Ort ist, weil das für schnelle Absprachen während der parallelen Arbeit erfahrungsgemäß hilfreich ist. Die vor Ort präsenten Personen haben dann aber angemerkt, dass sie extra angereist sind, um die Chance zu haben, direkt mit Kollegen zu interagieren, die sie sonst auch immer nur am Bildschirm sehen, und dass sie wirklich sehr gerne Kleingruppen bilden möchten, die ausschließlich aus Personen vor Ort bestehen. So entstand letztlich eine Konstellation, in der Kleingruppen, entweder ausschließlich vor Ort, oder ausschließlich remote interagiert haben. Grundsätzlich kann das alles sehr gut funktionieren, aber wer schon einmal eine solche Konstellation von Menschen geleitet hat, kann wahrscheinlich nachvollziehen, dass hierdurch zusätzliche Reibungspunkte entstehen, und es für die Gesamtgruppe einfach schwieriger wird, sich selbst zu organisieren. Hier ist dann umso mehr der Workshop Leiter gefragt, um (im Rahmen der Möglichkeiten) zu kompensieren.

Hier handelt es sich also um einen bedeutsamen Unterschied, und sofern irgend möglich, möchte ich in Zukunft entweder vollständig vor Ort, oder vollständig Remote arbeiten.

Art der Coding Agenten: CLI vs IDE

Da ich mich Anfang 2025 intensiv in die Arbeit mit Agenten gestürzt habe, und damals Cursor verwendet habe, einfach, weil es das mit Abstand populärste Tool für agentisches Coding war, habe ich zunächst unterschätzt, wie viel Widerstand bei Menschen aufkommt, wenn man eine neue IDE anbietet.

Ich habe selbst lange auch mit einer IntelliJ IDE gearbeitet, aber nachdem ich bei einer Demonstration eines erfahrenen Kollegen sehen durfte, was er mit Cursor geleistet hat, habe ich mich bereitwillig an die Kombination von Agent und VSCode gewöhnt.

Nun sind die verschiedenen Menschen in einer Gruppe von Teilnehmenden ggf. ganz unterschiedlich motiviert: Mindestens eine Person ist sehr motiviert, und hat organisiert, dass der Workshop überhaupt stattfindet. Bei allen anderen kann es durchaus unterschiedliche Motivationsgrade geben.

Bezüglich Cursor habe ich tatsächlich zu einer Zeit, als es weiterhin sehr populär war, (und noch vor der Übernahme durch xAI) erlebt, dass sehr viel Widerstand aufkommt, bei der Vorstellung, die eigene liebgewonnene IDE ausnahmsweise beiseite zu lassen.

Die Ablehnung ging in einem Fall soweit, dass jemand die Verwendung von Cursor in einem Worskop kurfristig verhindert hat, mit dem Argument, dass IntelliJ Produkte von Jetbrains aus der EU stammen und somit akzeptabel sind, während Cursor aus Datenschutzgründen auf keinen Fall verwendet werden darf, obwohl im konkreten Fall im Hintergrund in beiden Fällen überwiegend die Claude Modelle von Anthropic verwendet wurden. Der interne Konflikt endete später mit dem Ergebnis, dass unter bestimmten Voraussetzungen auch Cursor verwendet werden darf, aber für den Workshop mussten wir ersteinmal auf andere Tool ausweichen.

Ich habe zwar einen Moment gebraucht, um dies einzusehen, aber: wenn sich Menschen ohnehin schon auf sehr viel Neues einlassen, was in der Arbeit mit Agenten aufkommt, hilft es, wenn man zumindest ein gewohntes Werkzeug vor sich hat, mit gewohntem Aussehen, und mit den gewohnten Tastenkombinationen und anderen Handgriffen voraussehbare Reaktionen erleben kann.

Seit ich in meinen AI-Coding Workshops primär mit CLI Tools wie Claude Code arbeite, ist die Akzeptanz für diese neuen Werkzeuge sprunghaft angestiegen. Das neue (CLI) ist dann offensichtlich eine mögliche Ergänzung des bestehenden (IDE). Man kann seine bestehende IDE behalten und das neue Werkzeug sogar in einem Terminalfenster der vertrauten IDE bedienen. Für viele Kombinationen von IDE und Agent gibt es auch Plugins für besonders gute Integration, aber unabhängig davon, ob das der Fall ist, durfte ich regelmäßig beobachten, dass es sehr viel hilft, wenn das Neue zumindest nichts Bestehendes verdrängt und klar als Ergänzung wahrgenommen wird.

Betriebssysteme

Mit macOS und Linux hat bisher die Arbeit mit den Agenten aus dem Stand gut funktioniert.

Die Arbeit mit Windows ist tendenziell komplizierter. Schon vor dem betreffenden Workshop waren mir Beispiele bekannt, die sich auf bestimmte Paketmanager, Frameworks oder Bibliotheken aus dem JS / nodeJS Ökosystem bezogen haben. In solchen Fällen wurde dann auf das “Linux Subsystem für Windows” ausgewichen.

In einem Workshop tauchten mit Windows aber noch ganz andere Herausforderungen auf: Einerseits hatte die betroffene Person recht viele Rechte und Möglichkeiten auf dem lokalen Gerät und konnte z.B. selbst nach Belieben Software installieren. Andererseits war auf dem dort verwendeten Gerät eine besondere Rechtebeschränkung aktiv, die z.B. schon in einem ersten harmlosen Beispiel (Veränderung der Statuszeile von Claude Code) zu Komplikationen geführt hat. Das Aufrufen von externen Tools durch Claude Code hat in einigen Fällen zu “silent errors” geführt, also Versagen ohne Fehlercode und ohne Fehlermeldung. Eine kurze Recherche hat bestätigt, dass dies typische Symptome des betreffenden Sicherheitssystems sind. Für unsere weitere Arbeit war es hilfreich, diesen Umstand schon früh zu bemerken und in der Folge immer im Hinterkopf zu haben.

Menschen ändern nicht so leicht ihr Betriebssystem, aber falls es Windows ist, bin ich nun zumindest vorsichtig und versuche um so mehr, in der Vorbereitungphase adäquate Erwartungen zu wecken.

Legacy Code oder Neuentwicklung

Meistens wollten Kunden bisher möglichst direkt mit ihrem Legacy Code arbeiten und bei meinen ersten Workshops habe ich dem auch nachgegeben. Im Einzelfall hat das Wort “Legacy Code” natürlich ggf. eine sehr verschiedene Bedeutung.

• Wenn ein bekanntes Framework verwendet wurde, kann der Agent sich ggf. auch in sehr altem Code gut zurecht finden.
• Ohne Framework, automatisierte Tests usw. wird es für Agenten schwieriger und es besteht das Risiko, viel Zeit (und viele Tokens) mit dem Suchen nach den relevanten Stellen im Code zu verbringen. Die Probleme sind i.d.R. lösbar. u.a. auch durch bessere Anweisungen an die Agenten, aber es gibt eben eine gewisse Einstiegshürde.

In einem meiner AI-Coding Workshops gab es von vornherein den Wunsch, ein Feature komplett neu zu entwickeln. Es war für mich erfrischend, zu sehen, wie leicht das gelingt (in der vorgegebenen Struktur, mit automatisierten Tests usw.).

Schließlich habe ich von einem Kollegen eine Idee aufgenommen, an der ich mich für die Zukunft auch orientieren werde. Im Nachhinein erscheint die Idee sehr naheliegend:

• Tag 1 Neuentwicklung mit dem Ziel-Stack, aber auf der grünen Wiese (“Green Field”).
• Tag 2 Legacy AI-Coding (“Brown Field”)

Durch diese Vorgehensweise verschwinden zwar nicht die Probleme des Legacy Codings, aber bevor man an den größeren Herausforderungen arbeitet, kann man auf der grünen Wiese zumindest schon die Werkzeuge kennenlernen und Mechanismen zum Steuern der Werkzeuge erproben, was dann unmittelbar auch den Umgang mit dem Legacy Code erleichtert.

Ich bin natürlich weiterhin dafür offen, mit Kunden das zu tun, was sie tun möchten. Ich werde aber zumindest engagiert dafür plädieren, einen größeren Teil der Zeit für das Eingewöhnen in die Werkzeuge in einem Neuentwicklungsszenario zu nutzen.

Tech-Stack

Zufällig hat sich ergeben, dass ich meine ersten AI-Coding Workshops mit Teams gemacht habe, deren Technik Stack mir zu großen Teilen aus meiner eigenen Arbeit als Entwickler vertraut war. Dadurch konnte ich bis in die Details mitreden und zum Teil auch sehr technische Vorschläge machen.

Dann habe ich zum ersten Mal einen Workshop gegeben, in dem ein gänzlich anderer Technik-Stack verwendet wurde. Dabei kam unter anderem C# mit .NET auf Windows zum Einsatz. Da mir Sprache, Framework und Betriebssystem nicht vertraut waren, habe ich mich auf die Steuerung der Agenten konzentriert, und das hat letztlich sehr gut funktioniert. Voraussetzung ist natürlich, dass die Teilnehmenden ihren eigenen Tech-Stack gut kennen, und zumindest die geeigneten AI-Coding Tools installieren können. Von da an ist der exakte Stack dann, meiner aktuellen Erfahrung nach, weniger bedeutsam.

Anteil Erklärung vs. “Ausprobieren lassen”

Da ich eine ganze Menge Erfahrung und Hintergrundwissen mitbringe und auch schon die Chance hatte, dies zum Teil in Form von Frames in Miro aufzubereiten, kann ich allerlei in Form eines interaktiven Vortrags erklären. Und natürlich ist es sinnvoll, bestimmte Ideen und Zusammenhänge zu verstehen, bevor man anfängt, wild herum zu probieren …

Ehrlicherweise möchte ich zugeben, dass ich den Vortragsteil in den ersten Workshops länger gemacht habe, als ich es im Nachhinein betrachtet für sinnvoll halte. Zum Teil wurde das auch dadurch befeuert, dass Widerstände bei einzelnen Personen zu Diskussionen innerhalb des betreffenden Teams geführt haben. Aber fairerweise habe ich eine ganze Menge erklärt, auch wenn es keine besonderen Konflikte gab.

In meinem letzten Workshop habe ich den initialen Erklärungsteil auf eine Stunde reduziert, und andere Teile erst bei Bedarf, und sehr kurz, angebracht, so dass der allergrößte Teil der Zeit für das praktische Erproben der Werkzeuge und eigenes Coding zur Verfügung stand. Nachdem ich nun genug Material habe, und so gut damit vertraut bin, so dass ich auch spontan immer noch mit Material erklären kann, werde ich in Zukunft auch wieder mit einer kurzen initialen Erklärung einsteigen, und weitere Teile erneut erst bei Bedarf bereitstellen.

Anteil Diskussion unter den Teilnehmenden

Diskussionen unter den Teilnehmenden können natürlich wertvoll sein, aber nicht jede Diskussion ist gleichermaßen wertvoll:

Als Beispiel für eine (für die Teilnehmenden) weniger wertvolle Diskussion, möchte ich den Fall anführen, dass nach vorheriger Absprache mit meinen Ansprechpartnern, bestimmte Agenten und Modelle für den Workshop ausgewählt wurden, diese dann jedoch kurzfristig im Workshop noch infrage gestellt und ausführlich diskutiert wurden. Diese Diskussion war in diesem Moment begrenzt wertvoll, weil relevante Personen nicht anwesend waren und die vorläufige Entscheidung dann am Folgetag durch eine weitere Person wieder revidiert wurde. Nützlicher wäre gewesen, das Thema entweder vorab schon abschließend zu klären, oder ansonsten zumindest die Diskussion auf einen Zeitpunkt zu vertagen, zu dem die relevanten Entscheider einbezogen werden können. Einerseits müssen Konflikte innerhalb des Kundenunternehmens nicht primär mein Thema sein, wenn ich für ein technisches Thema beauftragt werde, andererseits möchte ich natürlich, dass die gemeinsame Zeit so gut wie möglich genutzt wird, und versuche entsprechend, mein Möglichstes dafür zu tun, dass wir produktiv arbeiten können.

In allen nachfolgenden Workshops habe ich in der Auftragsklärung umso mehr darauf geachtet, dass verschiedene Beteiligte eingebunden werden, und eine absehbar tragfähige Entscheidung bezüglich der Agenten und Modelle schon vor dem Start des Workshops gefällt wird.

Umgang mit Widerstand und Ängsten

Bei einem Kundenunternehmen formulierte ein Entwickler gegenüber Kollegen seine Befürchtungen bzgl. des Umstiegs auf AI-Coding sinngemäß wie folgt: “Wenn das wirklich funktioniert, sind wir alle arbeitslos”.

Solche Ängste in Bezug auf die Einführung von AI Tools sind rational berechtigt. AI kann nicht unbedingt jede Art von Arbeit erleichtern oder ersetzen, aber speziell AI-Coding funktioniert tatsächlich hervorragend, wenn man systematisch vorgeht. Für Entwickler ist es also naheliegend, sich zu Fragen, ob es für mehr Kapazität in der Entwicklung dann auch mehr Aufträge gibt oder ggf. ein Teil der Mitarbeiter absehbar entlassen werden soll.

Seitdem habe ich mit verschiedenen Kunden durchaus unterschiedliche Erfahrungen in diesem Bereich gemacht. Zusätzlich hatte ich die Gelegenheit, mich auf Konferenzen, u.a. dem AI-Camp Berlin, mit anderen Leitern von AI-Coding Workshops auszutauschen. Die Führung verschiedener Unternehmen geht sehr unterschiedlich proaktiv mit der Frage um, welche Konsequenzen mögliche Produktivitäsgewinne für die Belegschaft haben werden:

• Extrembeispiel 1: das Thema wird vorab überhaupt nicht adressiert, sondern erst, wenn Widerstände aufkommen
• Extrembeispiel 2: 20 % der Beschäftigten werden entlassen, von den verbleibenden Mitarbeitern wird erwartet, mit Hilfe von AI-Tools den Verlust wieder auszugleichen

Beide Beispiele sind tatsächlich so vorgekommen, als glanzvoller habe ich das folgende balanciertere Beispiel erlebt:

Bei einem meiner Kunden, einer Digitalagentur, hat sich eine höhere Führungskraft, rechtzeitig vor dem geplanten AI-Coding Workshop, in einem regelmäßigen internen Termin vor Ort, an alle betroffenen Mitarbeiter gewendet: Er hat klar mitgeteilt, dass das Risiko besteht, dass die Firma als Ganzes, ohne den umfangreichen systematischen Einsatz von AI-Coding, absehbar nicht mehr konkurrenzfähig sein wird. Um diese Befürchtung zu untermauern, hat er vorab bereits selbst per Vibe Coding ein Beispielprodukt erstellt und in seinem Vortrag demonstriert. Es gab dabei keinen Anspruch an eine wartbare Architektur usw., wohl aber ein Produkt, das von außen betrachtet bestehenden Produkten ähnelt, aber innerhalb von Stunden entstanden ist (und nicht innerhalb von Monaten).

Wichtig war in diesem Zusammenhang die Mitteilung, dass es bei der Einführung darum geht, die Firma konkurrenzfähig zu halten, und gleichzeitig alle bestehenden Mitarbeiter weiter bei der Firma zu behalten. Der Workshop mit diesen Mitarbeitern war besonders produktiv. Wie in jedem Workshop gab es auch hier berechtigte Bedenken, gleichzeitig konnten diese auf sachlich produktive Art diskutiert werden, ohne dass eine große, emotionale Ladung involviert war.

Proaktiver Umgang mit möglichen Ängsten der Entwickler ist somit meiner Erfahrung nach ein besonders wichtiges Thema, das frühzeitig Aufmerksamkeit der Führungskräfte verdient.

Zusammenfassung

Zwei Dinge sind im Zusammenhang mit AI-Coding Workshops besonders wichtig:

Schon vor dem Workshop brauchen die Mitarbeitenden durch eigene Führungskräfte Orientierung in Bezug darauf, wie mögliche Produktivitätsgewinne sich später auswirken werden. Sollen Mitarbeitende entlassen werden oder gibt es mehr Aufträge, die zu erfüllen sind? Wenn dieses Thema nicht proaktiv adressiert wird, machen sich die Mitarbeitenden eigene Gedanken, was in der Regel verschiedene Befürchtungen und Gerüchte nährt

Innerhalb der Workshops setzte ich mittlerweile auf kurze Erklärungblöcke, sowohl zu Beginn, als auch und unterwegs bei Bedarf. Der größte Teil der Zeit wird zum systematischen Erarbeiten des Umgangs mit Werkzeugen und Vorgehensweisen genutzt.

Hilfreich ist es zudem, mit Hilfe des Ziel-Stacks zunächst eine Neuentwicklung zu erproben und sich erst im Anschluss daran mit gegebenenfalls vorhandenem Legacy Code auseinander zu setzen.

AI-Coding Hands-on Workshop

Du bist von Anfang an selbst an der Tastatur. Am Ende unseres AI-Coding Workshops hast Du einen prall gefüllten Werkzeugkoffer. Du arbeitest souverän mit aktuellen Werkzeugen und lieferst in kurzer Zeit Ergebnisse in hoher Qualität.

Zum Deep Dive / Workshop

Reflexion, Einladung und Angebot

• Hast Du als Entwickler konkrete Ideen für Deinen eigenen Weg bekommen?
• Hast Du als Führungskraft einen Eindruck gewonnen, welche Schritte Deine Mitarbeiter gehen könnten? Denkst Du darüber nach, ihnen andere Impulse und Unterstützung anzubieten als bisher?
• Hast Du einen ersten Eindruck von mir?

Nimm Kontakt mit mir auf, wenn Du Dich für einen Impulsvortrag (mit Coding Demo) oder Workshop interessierst! Lass uns gemeinsam überlegen, welche Art von Unterstützung für Euch hilfreich sein kann:

Unten auf der Seite Kontakt kannst Du Dir direkt per Calendly einen Termin für ein Erstgespräch aussuchen (unverbindlich und kostenlos).

Über den Autor

Dr. Timon Fiddike

• Seit 2010 auf dem Pfad der Agilität
• Seit 2005 KI, AI, Machine Learning, siehe Werdegang
• Erfahrung als Entwickler im Team, Product Owner, Scrum Master, Geschäftsführer und Coach
• Höchste Zertifizierung: Certified Scrum Trainer® (weltweit ca. 220 Personen) für die Scrum Alliance®
• Erfahrung in Startup, Mittelstand & Konzern
• Integraler Coach – Ausbildung nach ICF ACTH-Standard
• Unterstützt mit Begeisterung das menschliche Wachstum, das agile Arbeit ermöglicht
• Geschäftsführer Agile.Coach GmbH & Co. KG

Zu Timons Profil