[Claude Code Meetup] Eine Umgebung schaffen, in der Agenten und Menschen in einer Legacy-Codebasis gemeinsam exzellent arbeiten

(Dies sind Unterlagen aus einem Vortrag auf dem Claude Code Meetup Seoul am 17. Dezember. Die vollständigen Vortragsfolien finden sich unter diesem Link.)

---

Das Ziel des „internen Consultings“ des Corca-AX-Teams

• Gute Praktiken für Agentic Engineering bei Corca verankern und den Boden dafür schaffen, sie gemeinsam kontinuierlich weiterzuentwickeln.
  • Bei Corca wird „Agentic-Engineering-Praxis“ definiert als „Praktiken, um AI-Agenten so einzusetzen, dass sowohl Softwarequalität als auch Produktivität steigen“.
• Dafür sorgen, dass Engineering-Kompetenz zu einer weiteren zentralen Wettbewerbsstärke von Corca wird.
• Dafür wurde begonnen, das Moonlight-Team zu unterstützen.

Die Situation von Moonlight

• Moonlight ist Corcas Hauptprodukt und positioniert sich als „AI-Kollege, mit dem man gemeinsam Papers liest“.
• „Mit PDFs sprechen“ ist ein Produktkonzept, das es schon seit den allerersten Tagen von ChatGPT gibt. Unter den vielen Konkurrenzprodukten hat Moonlight überlebt und befindet sich derzeit am Anfang der J-Kurve des Wachstums (zuletzt stark steigende Nutzerzahlen aus China).
• Auf dem Weg dorthin gab es viele Trial-and-Error-Phasen, aber die zentrale Wettbewerbsstärke war, das Tempo und den Rhythmus der Feature-Entwicklung irgendwie aufrechtzuerhalten.
• Einige frühe Entscheidungen zugunsten von Geschwindigkeit
  • typescript strict: false
  • Minimale automatisierte Tests
  • Duplikate und Hardcoding erlaubt
  • Keine Trennung nach Rollen. Fast alle Teammitglieder (6 von 7) implementieren mit Coding-Agenten und stellen PRs ein.
• Als das Produkt auf Kurs kam, wurde die technische Schuld nach und nach belastend.
  • Das Produkt wurde komplexer, das Team bekam viele neue Mitglieder, und gleichzeitig liefen viele Experimente parallel.
  • Das Tempo bei Produktverbesserungen verlangsamte sich langsam, während die Unsicherheit zunahm.
  • Die Last der Code-Reviews konzentrierte sich auf wenige Personen, und es entstanden größere und kleinere Fehler.

Unmittelbare Aufgaben für das AX-Team

• [Produkt] Die Qualität von Moonlight verbessern und zugleich das Tempo beim Hinzufügen und Verbessern von Features erhöhen!
• [Team] Es allen erleichtern, Moonlight-Code zu ändern, und den Stress nach Deployments verringern!
• [Kultur] Damit 1 und 2 gelingen, sollen Moonlight-Team und AX-Team gemeinsam gute Agentic-Engineering-Praktiken finden, anwenden, verfeinern und schrittweise im Unternehmen verbreiten!
  → Man ging davon aus, dass sich die meisten Probleme lösen lassen, wenn Coding-Agenten bessere Antworten geben können.

Wie geben Agenten bessere Antworten?

[1] Von Anfang an auf einen guten Pfad lenken

• Eine hohe Codebasis-Qualität ist in drei Punkten vorteilhaft.
• Es muss weniger unnötiger Kontext mitgegeben werden (Less is More).
• Der Agent folgt eher bereits vorhandenen guten Mustern.
• Man kann die Wahrscheinlichkeit erhöhen, dass Antworten aus Bereichen des vortrainierten Codes gesampelt werden, in denen sich hochwertiger Code häuft.
  • Es gibt viele Untersuchungen dazu, dass hochwertiger Kontext zu besseren Antworten führt.
  • (Bauchgefühl) Wenn man eine Anfrage an einen Agenten in einer Codebasis mit sortierter import-Reihenfolge schickt: Ist dann nicht die Wahrscheinlichkeit höher, dass Code mit sortierten imports im vortrainierten Korpus insgesamt hochwertiger ist?
  • Aus dem Anthropic-Blog: „Schon allein durch interessante Fonts verbessern sich auch andere Designelemente.“

[2] Verhindern, dass sie auf einen falschen Pfad geraten

• Mit verschiedenen statischen Analysewerkzeugen lassen sich falsche Wege blockieren: Typfehler prüfen, Linter-Fehler prüfen, automatisierte Tests, Dead-Code-Erkennung, Prüfung der Dateilänge, Komplexitätsprüfungen, Erzwingen von Abhängigkeitsbeziehungen, Erzwingen des Verhältnisses von Testcode zu Produktionscode usw. (Dann wird so lange erneut gearbeitet, bis die Kriterien erfüllt sind.)

[3] Vor allem Aufgaben anfragen, die sie gut können

• Menschen, LLMs und Algorithmen sind jeweils in unterschiedlichen Dingen gut. Wer klug auswählt, wann was eingesetzt wird, spart Zeit und Kosten.
  • z. B. sagen, dass kein i18n-Key vergessen werden darf, vs. ein Skript zum Finden fehlender i18n-Keys ausführen lassen
• Wer wann was gut kann, verändert sich mit der Zeit und hängt von der Problem-Domain ab. Es ist hilfreich, sich die Gewohnheit anzueignen, dieses „Gespür“ in der eigenen Domain aktuell zu halten.
  • z. B. bei neuen Modellen mit eigenen Benchmarks testen, bekannte Beispiele aus Social Media nachstellen

[4] Bei Aufgaben helfen, die sie nicht gut können

• Allerdings sollte immer geprüft werden, ob sie etwas wirklich nicht können. Wenn Delegation nicht riskant oder extrem ineffizient ist, sollte eher AI/Algorithmen als Menschen die Arbeit übernehmen. (Token-Kosten werden ohnehin irgendwann so billig wie Stromkosten.)
• Wenn sie es wirklich nicht können? Von anderen LLMs gegenprüfen lassen
  • z. B. ganz einfach mit: „Das hier wurde von einem Junior-Entwickler geschrieben …“
• Damit AI Arbeit besser erledigen kann, muss man ihr eine Umgebung geben, in der sie besser arbeiten kann. Anders gesagt: Dinge, die der (derzeitige) Agent (hier) nicht gut kann, sollten von Menschen, Algorithmen und anderen Agenten ergänzt werden.

Worauf geachtet wurde

• Moonlight ist eine Rakete, die gerade erst zu fliegen beginnt, und das AX-Team sind Gäste von außen.
• Unbedingt vermeiden, dass Externe kommen, „etwas bauen“ und dann wieder gehen.
• Maßnahmen zur Qualitätsverbesserung sollen die Feature-Entwicklung möglichst nicht ausbremsen.
• Es wurde beschlossen, Arbeiten, die die bisherige Arbeitsweise kaum verändern, und anspruchsvollere, aber wirkungsvolle Maßnahmen in einem angemessenen Verhältnis zu mischen.
  → Das Bild war, dass AX-Team und Moonlight-Team gemeinsam passende Praktiken für Team und Produkt finden und anwenden, sodass sich dabei zugleich Code- und Produktqualität sowie Teamkompetenz verbessern.

Repräsentative Ergebnisse der letzten 4 Wochen

[1] Gute Gewohnheiten setzen sich fest, und gute Muster werden entdeckt

• Täglich winzige Refactoring- (tidying) Commits ohne PR-Review hochladen
• Prompts, die frühere vorbildliche Commits nachahmen (z. B. Unterstützung neuer Modelle), sowie Prompts, die solche Muster finden und sammeln
• Ein Code-Review-SKILL mit der Persona eines Seniors

[2] Beginn der Messung und Visualisierung von Codequalitätsmetriken. Die Zahl der Fehler/Warnungen im Verhältnis zu den Codezeilen sinkt schnell

• Die Codequalitätsmetriken sinken teils schrittweise, teils dramatisch.
• Besonders wichtig war, dass tidying die Codebasis jeden Tag ein wenig verbessert und dadurch irgendwann das Vertrauen entstand, auch große Refactorings und große Aufgaben anzugehen.
• Durch die paketweise Einführung von knip wurde auch alter, ungenutzter Code entfernt.
• Metriken sollten immer komplementär sein. 1000 Fehler in 1000 Zeilen Code sind viel schlechter als 5000 Fehler in 100.000 Zeilen. Deshalb wird nicht nur auf absolute Zahlen geschaut, sondern auf die Fehlerrate im Verhältnis zur Zeilenzahl, um gesündere Steuerungsmetriken zu etablieren.
  • Die Zahl sinnvoller Zeilen ohne Kommentare und Leerzeilen wird mit tokei gemessen.

[3] Ein Speicherleck behoben, das über ein Jahr lang bestand

• Mit einem Gesamtaufgebot aus verschiedenen Tools und Prompting, darunter repomix, wurde nach mehreren Anläufen ein Speicherleck beseitigt, das über ein Jahr lang bestand.
• Die Freude ist groß, weil wohl eine kleinere Server-Instanz ausreichen könnte.

[4] Es entstanden Abstraktionsstrukturen, Prompts und Skripte, mit denen sich die wöchentlich parallel laufenden Experimente einfacher und sicherer hinzufügen und entfernen lassen

Im Ergebnis greifen drei Dinge gut ineinander: Die Codequalität steigt stetig, Feature-Entwicklung wird sicherer und zugleich schneller, und die (agentische) Engineering-Kompetenz des Teams wächst kontinuierlich.

Trial and Error

• Natürlich lief nicht von Anfang an alles gut. Ursprünglich wollte man zwei Dinge gleichzeitig tun.
  • Große, wertvolle, aber etwas riskante Änderungen auf einmal einführen: strict-Option aktivieren, strenge eslint-Regeln einführen, allen Dead Code auf einmal löschen usw.
  • Auch wenn der Wert geringer ist, sicher Schritt für Schritt vorgehen: z. B. täglich tyding-Commits hinterlassen
• Doch Ersteres war zu unsicher und wurde deshalb nicht gekonnt, und Letzteres war zu langweilig und wurde deshalb nicht gemacht.
• Deshalb wurde der Ansatz geändert
  • Anspruchsvolle Dinge sicherer machen (für einzelne Dateien tsc strict aktivieren, beheben und wieder deaktivieren; eslint mit Minimalregeln anwenden; knip paketweise einführen usw.)
  • Sichere Dinge wertvoller machen (z. B. Prompts erstellen, die tidying-Vorschläge für jüngste Änderungen liefern)
• Es gibt noch viele offene Aufgaben
  • typescript: strict aktivieren
  • zod einführen, um Server-Client-Verträge abzugleichen
  • Strengere eslint-Regeln einführen
  • Höhere Abdeckung durch automatisierte Tests
  • Mit mehr statischen Analysewerkzeugen falsche Pfade blockieren
• Trotzdem geht es gemeinsam, kontinuierlich und keineswegs langsam voran.

One More Thing: Meine Lern- und Debugging-Gewohnheiten

In solchen Situationen lernt man viel, wenn man AI fragt, Experten konsultiert und die Ergebnisse gegeneinander prüft. Auch dieser Prozess wird in GitHub-PRs und Issues sowie in Slack dokumentiert und im Unternehmen geteilt.

• Andere wissen Dinge, die ich nicht weiß
  • Wie hat diese Person dieses Wissen bzw. diese Erfahrung erlangt? An welchen Signalen hat sie dieses Problem erkannt?
• Eigene Fehler, Bugs oder Anti-Patterns in der Codebasis entdecken
  • Welche Ursachen haben dazu geführt, dass dieses Problem überhaupt entstehen konnte? Wie lässt sich die Struktur verbessern, damit ich künftig weniger Fehler mache und Fehler früher entdecke?

Fazit

• Wenn AI bessere Antworten geben kann, lassen sich viele Probleme von Produktteams lösen.
  • Die Qualität der Codebasis erhöhen (von Anfang an auf einen guten Pfad lenken) und verschiedene Tools einführen (falsche Pfade blockieren)
  • Teammitglieder dabei unterstützen, ihre Agentic-Engineering-Kompetenz zu erhöhen (Aufgaben anfragen, die gut beherrscht werden, und bei schwierigen Aufgaben helfen)
• Wenn ein Team klug mit AI zusammenarbeitet, seine Kompetenz steigert und ein gutes Umfeld schafft, dann sind „höhere Qualität“ und „schnellere Feature-Ergänzung/-Verbesserung“ sehr wohl gleichzeitig möglich.
• Nicht „von außen“ gute Dinge mitbringen und helfen, sondern „von innen“ gemeinsam entdecken und ausprobieren. Messen, visualisieren, feiern und voneinander lernen.