In der letzten Woche hatte ich zwei sehr unterschiedliche Meetups mit Entwicklern.
Am Dienstag saßen 18 Leute bei Claude Code Anonymous zusammen, mit Crossover zur Java User Group. Am Samstag stand ich in einem Open Space vor einem breiteren Publikum und habe unter anderem den Pi Agent gezeigt. Zwei Formate, zwei Stimmungen, zwei Gruppen mit leicht anderem Hintergrund.
Trotzdem blieb nach beiden Abenden derselbe Eindruck hängen: KI-Coding-Tools sind im Alltag angekommen. Die meisten haben sie längst ausprobiert. Viele nutzen sie punktuell produktiv.
Was deutlich seltener von allein passiert: der Schritt vom installierten Tool zur bewusst gestalteten Arbeitsweise.
Das hier ist keine Studie zur KI-Adoption in Deutschland. Es ist ein lokaler Snapshot aus OWL, aus Runden mit Leuten, die sich freiwillig an einem Abend in einen Raum setzen, um über KI-gestützte Entwicklung zu sprechen. Gerade deshalb finde ich solche Abende interessant. Sie zeigen oft früher als Marktberichte, wo die Reibung im Alltag tatsächlich liegt.
Zwei Meetups, ein erstaunlich ähnliches Bild
Die erste Beobachtung war banal und aufschlussreich zugleich: Fast jeder im Raum hatte irgendeine Form von Erfahrung mit KI-gestützter Entwicklung. Kaum jemand stand noch ganz am Anfang. Gleichzeitig war die Spannbreite groß.
Einige nutzten Claude Code oder Copilot schon regelmäßig. Andere hatten vor allem ChatGPT oder eine IDE-Integration ausprobiert. Manche kannten Begriffe aus Demos, Talks oder Threads, hatten sie aber noch nicht in den eigenen Workflow übersetzt. Das ist eine andere Lage als noch vor ein paar Monaten, als in vielen Runden erst einmal Grundsatzfragen im Vordergrund standen.
Heute ist das Grundinteresse da. Die Diskussionen drehen sich seltener um „Brauchen wir das überhaupt?“ und viel häufiger um Fragen wie diese:
- Wofür lohnt sich der Einsatz im Alltag wirklich?
- Wo kippt der Output von hilfreich zu unkontrolliert?
- Welche Art von Setup spart Reibung?
- Welche Grenzen gehören einfach zur aktuellen Generation der Tools dazu?
Wenn ein Team an diesem Punkt ist, hilft es wenig, noch einmal die Grundidee zu verkaufen: stattdessen geht es um Teamroutine, Guardrails und konkrete Arbeitsmuster.
Die Default Experience dominiert
Am Dienstagabend wurde sehr sichtbar, wie stark die Default Experience gerade den Alltag prägt.
Die meisten arbeiten mit dem, was ihr Tool oder ihre IDE direkt anbietet. Das ist nachvollziehbar. Die Einstiegshürde ist gering, die ersten Erfolgserlebnisse kommen schnell, und im Tagesgeschäft reicht das oft schon, um dranzubleiben. Wer ein Plugin installiert und am selben Nachmittag bessere Vorschläge bei Refactorings oder Tests bekommt, hat erst einmal keinen akuten Grund, tiefer zu gehen.
Gleichzeitig war in den Gesprächen zu hören, wie schnell diese erste Stufe an Grenzen stößt. CLAUDE.md oder vergleichbare Regeln waren ein Thema, aber selten systematisch. MCP spielte praktisch keine Rolle. Skills, eigene Regeln, bewusst eingesetzte Subagents oder Hook-basierte Qualitäts-Gates tauchten vor allem dort auf, wo jemand schon deutlich tiefer eingestiegen war. Subagents wurden eher dann genutzt, wenn das Tool sie automatisch startete. Eigenständige Orchestrierung war kaum zu sehen.
Ich werte das nicht als Mangel an Disziplin. Für mich ist das der normale Verlauf von Einführung. Man experimentiert, und das Meetup ist gerade dazu da, den produktiven Austausch zu fördern!
Ein Tool zu installieren dauert Minuten. Es an den eigenen Stack anzupassen dauert länger. Daraus einen Teamablauf zu machen dauert noch einmal länger. Von außen sehen diese Schritte ähnlich aus. Im Alltag fühlen sie sich komplett unterschiedlich an; und manche Aufgaben machen den Beteiligten je nach Interesse mehr Freude als andere.
In vielen Teams endet die Bewegung nach Schritt eins oder irgendwo mitten in Schritt zwei. Dann gibt es einzelne Leute mit guten persönlichen Routinen und eine größere Gruppe, die das Tool situativ nutzt, wenn es gerade passt. Genau dort entsteht die bekannte Schieflage: Die Tools sind da, aber die gemeinsame Arbeitsweise fehlt noch. Warum Teams an dieser Stelle oft hängenbleiben, habe ich in „Von Skeptiker zu Anwender“ ausführlicher beschrieben.
„Still high, but decreasing what the fucks per hour.“
Das beste Zitat des Abends kam von einem Teilnehmer:
Still high, but decreasing what the fucks per hour.
Besser lässt sich die aktuelle Phase kaum zusammenfassen:
-
Die Produktivität ist hoch. Wer die Tools regelmäßig nutzt, bekommt heute deutlich mehr aus ihnen heraus als noch vor einem halben Jahr. Aufgaben, für die früher viel manuelle Vorarbeit nötig war, laufen inzwischen in Minuten an: Tests ergänzen, Diffs strukturieren, Dokumentation aus verstreutem Input zusammenziehen, ein erstes Architektur-Outline erzeugen oder Optionen gegeneinander abwägen.
-
Gleichzeitig bleiben die Reibungspunkte deutlich spürbar. Ein Agent verliert nach langem Kontext plötzlich eine wichtige Anweisung aus dem Blick. Ein Prompt-Muster, das gestern stabil war, liefert nach einem Modell-Update andere Ergebnisse. Eine Aufgabe, die letzte Woche sauber durchlief, produziert heute einen Diff, den niemand gern reviewen möchte. Man sprach von Knowledge Churn oder schlicht von der täglichen Realität eines Mediums, das sich unter den Händen weiterentwickelt.
Ich finde diese Einordnung hilfreich, weil sie zwei Extreme vermeidet. Das eine lautet: „Alles funktioniert schon.“ Das andere: „Alles ist noch zu unreif für ernsthafte Arbeit.“ Beides passt nicht zu dem, was ich im Raum gehört habe.
Die Leute arbeiten produktiv mit den Tools. Und sie lernen parallel, mit ihren Eigenheiten umzugehen. Genau diese Doppelbewegung prägt die Phase: nutzen und gleichzeitig nachjustieren.
Für Teams hat das eine Konsequenz: Sobald mehrere Entwickler KI-Tools einsetzen, braucht es eine gemeinsame Sprache für diese Reibung. Sonst erlebt jeder dieselben Grenzfälle isoliert, zieht eigene Schlüsse daraus und baut persönliche Workarounds. Die Lernkurve bleibt individuell, obwohl das Problem längst ein Teamthema ist.
Sobald Kontrolle sichtbar wird, steigt die Aufmerksamkeit
Der Kontrast am Samstag war fast noch aufschlussreicher.
Im Open Space lag der Fokus stärker auf steuerbaren Setups: mehr Kontrolle über Dateizugriffe, sichtbare Regeln, differenzierte Tool-Nutzung, Subagents und anpassbare Agent-Harnesses. Als ich den Pi Agent gezeigt habe, kamen sofort Rückfragen. Leute wollten wissen, wie viel davon man selbst formen kann. Welche Teile lokal liegen. Wo Regeln herkommen. Wie ein Agent an Projektkontext kommt. Wie weit man das Verhalten steuern kann, ohne dass daraus ein Vollzeit-Hobby wird.
Die Reaktion war deutlich: Sobald Entwickler einmal sehen, wie eine bewusst konfigurierte Umgebung aussieht, verschiebt sich ihre Vorstellung davon, was überhaupt möglich ist.
Am Dienstag war die dominante Nutzung noch stark von Defaults geprägt. Am Samstag zog genau das Aufmerksamkeit auf sich, was über die Defaults hinausgeht. Nicht, weil plötzlich alle zu Tool-Bastlern werden wollen. Sondern weil sichtbar wurde, dass zwischen „Agent läuft“ und „Agent arbeitet in meinem Sinne“ ein ganzer Gestaltungsraum liegt.
Das trifft einen Nerv, den Entwickler aus anderen Bereichen kennen. Eine IDE wird mit Plugins und Einstellungen passend gemacht. Eine Shell wächst über Aliases, Funktionen und kleine Skripte. Ein Editor wird über Jahre an die eigene Hand angepasst. Bei Agent-Harnesses beginnt gerade ein ähnlicher Lernprozess.
Wer an dieser Stelle einsteigen will, braucht vor allem Orientierung. Nicht jede Stufe lohnt sich für jedes Team. Ein paar einfache Anpassungen bringen oft schon viel: Kontext sauber hinterlegen, Scope im Prompt deklarieren, Review-Regeln sichtbar machen, kleine eigene Werkzeuge einbinden. Die große Orchestrierung mit Subagents, Worktrees und spezialisierten Tools ist für manche Teams hochinteressant, für andere gerade noch zu viel.
Ein unterschätzter Einstieg: von Zeugs zu Dokumentation
Eine weitere Beobachtung aus beiden Runden fand ich besonders nützlich: Viele der stärksten Aha-Momente lagen nicht im klassischen „Schreib mir Code“.
Stattdessen kamen Beispiele auf den Tisch, bei denen aus losem, unstrukturiertem Material plötzlich etwas Lesbares und Verwendbares wurde: Dokumentation aus Stichpunkten, Analyse-Notizen aus verstreuten Beobachtungen, Triage von Fehlermeldungen, erste Diagramme, Zusammenfassungen von Problemen, die vorher nur als Bauchgefühl oder Chat-Verlauf existierten.
Ich habe das am Dienstag als „from stuff to document“ ans Whiteboard geschrieben, in Anlehnung an Getting Things Done, wo „stuff“ eben das ungeordnete Zeug ist, das verarbeitet werden muss. Also genau die Art von Arbeit, die in Teams ständig anfällt, aber selten als eigener Prozess ernst genommen wird.
Hier liegt ein praktischer Einstiegshebel für Teams. Wer noch keine stabile Teamroutine im Coding selbst hat, kommt mit solchen Aufgaben oft schneller zu brauchbaren Ergebnissen. Das Risiko ist geringer, die Wirkung im Alltag trotzdem hoch. Gute Dokumentation verkürzt Rückfragen. Eine strukturierte Analyse beschleunigt Entscheidungen. Ein sauberer Überblick spart später Zeit im Code.
Das erklärt auch, warum der Eindruck „Das Tool ist beeindruckend“ oft schon früh entsteht, obwohl der eigentliche Coding-Workflow noch gar nicht belastbar ist. Die schnellen Erfolge liegen häufig an den Rändern des Codes: Vorbereitung, Einordnung, Zusammenfassung, Strukturierung.
Was ich daraus für Teams mitnehme
Wenn ich beide Meetups zusammendenke, ergibt sich für mich ein ziemlich klares Bild.
Erstens: Das Interesse ist da. Ich musste niemanden von der Relevanz des Themas überzeugen.
Zweitens: Die meisten nutzen KI-Tools heute auf einer frühen, aber realen Produktivitätsstufe. Sie holen bereits Wert aus dem, was direkt verfügbar ist.
Drittens: Der Übergang zur belastbaren Arbeitsweise braucht mehr als nur weitere Zeit mit dem Tool. Teams profitieren hier von sichtbaren Mustern:
- Wie sieht ein guter Prompt mit klaren Grenzen aus?
- Wie hält man Diffs reviewbar?
- Welche Aufgaben laufen zuverlässig KI-gestützt?
- Welche Regeln gelten im Review?
- Wie viel Anpassung am Harness lohnt sich im eigenen Kontext?
Viertens: Die Lücke zwischen Tool und Workflow schließt sich leichter, wenn Leute einmal gemeinsam auf echte Aufgaben schauen. Demos wecken Interesse. Routinen entstehen dort, wo ein Team an konkreten Fällen festlegt, wie es künftig arbeiten will.
Genau deshalb interessieren mich Meetups als Format so sehr. Sie sind kein Ersatz für Teamarbeit auf der eigenen Codebasis. Aber sie zeigen sehr schnell, wo die Community gerade steht, welche Fragen zunehmen und welche Themen aus der Nische in den Alltag rutschen.
Wenn du das in deinem Team gerade beobachtest, würde ich weniger auf das nächste Tool schauen und mehr auf euren Teamablauf: auf Regeln, auf Review-Maßstäbe und auf die Aufgaben, bei denen KI im Alltag schon heute zuverlässig hilft.