- Zusammenfassung von sechs Wochen Erfahrung, in denen die Zahl der Commits durch Verbesserungen an der Entwicklungsinfrastruktur stark anstieg – etwa durch die Automatisierung einfacher, wiederkehrender Aufgaben für AI-Agenten, das Eliminieren von Build-Wartezeiten und den Aufbau eines parallelen Worktree-Systems
- Mit dem Skill
/git-pr wurde der Prozess zur PR-Erstellung automatisiert und damit die Kosten von Context Switching beseitigt; außerdem schreibt der Agent selbst detailliertere PR-Beschreibungen
- Durch den Wechsel des Build-Tools zu SWC wurde der Serverneustart auf unter 1 Sekunde verkürzt, was eine Entwicklungsumgebung ohne Unterbrechungen im Flow ermöglicht
- Mit der Preview-Funktion von Claude Code kann der Agent die UI selbst prüfen, wodurch der Flaschenhals entfällt, dass Entwickler jede Änderung manuell kontrollieren müssen
- Wenn Reibungspunkte nacheinander entfernt werden, zeigt sich direkt das Theory-of-Constraints-Muster, bei dem jeweils der nächste Engpass sichtbar wird
- Der Fokus liegt nun weniger auf der Implementierung von Features als auf dem Aufbau einer Infrastruktur, in der Agenten effizient arbeiten, und auf der Beschleunigung der Loop-Geschwindigkeit
Automatisierung einfacher, wiederkehrender Aufgaben
- Anfangs wurden das Stagen von Änderungen, das Schreiben von Commit-Messages, das Formulieren von PR-Beschreibungen, das Pushen und das Erstellen von GitHub-PRs vollständig manuell erledigt
- Der erste Wendepunkt war die Erkenntnis, dass es sich dabei um einfache Routinearbeit (grunt work) handelt; die Rolle änderte sich damit vom Implementierer zum Manager, der Agenten steuert
- Als ersten Claude-Code-Skill wurde
/git-pr geschrieben, um den gesamten Ablauf der PR-Erstellung zu automatisieren
- Weil der Agent den kompletten Diff liest und die Änderungen sauber zusammenfasst, sind die PR-Beschreibungen detaillierter als die zuvor manuell verfassten
- In der
CLAUDE.md der Codebasis ist die Nutzung von Graphite festgehalten, persönlich wird jedoch plain git bevorzugt und daher mit /git-pr gearbeitet
- Der größere Effekt gegenüber der reinen Zeitersparnis ist die Beseitigung des mentalen Overheads: Das kleine Context Switching von „über Code nachdenken → über die Erklärung des Codes nachdenken“ bei jeder PR entfällt
Wartezeiten eliminieren
- Für lokale Previews musste man die aktuelle Arbeit immer wieder verlassen, den Dev-Server stoppen und in einem neuen Branch neu starten
- Der Server-Build dauerte etwa 1 Minute – lang genug, um die Konzentration zu unterbrechen, aber zu kurz, um sinnvoll etwas anderes zu tun
- Durch die Umstellung des Builds auf SWC wurde der Serverneustart auf unter 1 Sekunde verkürzt
- Direkt nach dem Speichern einer Datei läuft der Server bereits wieder, sodass keine Lücke mehr entsteht, in der die Aufmerksamkeit abdriften kann
- Verglichen wird das mit dem Unterschied zwischen „einem Gespräch mit peinlichen Pausen“ und „einem Gespräch, das natürlich fließt“
Eigene UI-Prüfung durch den Agenten
- Zuvor mussten alle UI-Änderungen manuell in einer lokalen Preview geprüft werden, wodurch der Entwickler zum Flaschenhals für jede Funktion wurde
- Nachdem eine Chrome-Erweiterung ständig abstürzte, wurde auf die Preview-Funktion von Claude Code umgestellt
- Der Agent kann die Preview einrichten, Sitzungsdaten beibehalten und damit selbst direkt prüfen, wie die UI tatsächlich aussieht
- Das wurde in den Workflow integriert, sodass eine Aufgabe nur dann als „fertig“ gilt, wenn der Agent die UI selbst verifiziert hat
- Da die Verifikation delegiert werden kann, ist Eingreifen nur noch beim finalen Review nötig, und der Agent kann über längere Zeit autonom arbeiten
- Ein deutlich wichtigerer Effekt als erwartet ist, dass der Agent eigene Fehler selbst erkennt
Paralleles Worktree-System
- Nachdem schnelle Rebuilds und automatisierte Previews vorhanden waren, trat die nächste Reibung offen zutage: Bequem ließ sich immer nur eine Aufgabe gleichzeitig bearbeiten
- Um PRs anderer Agenten oder Teammitglieder zu reviewen, musste vom Main-Branch auf einen PR-Branch gewechselt sowie neu gebaut und getestet werden – was mit uncommitteten Änderungen kollidierte
stash → checkout → rebuild → test → switch back → pop stash, oder manuelles Erstellen eines Worktree mit anschließenden Port-Konflikten
- Die App benötigt für Frontend und Backend jeweils eigene Ports, und alle Worktrees teilen dieselben Umgebungsvariablen, sodass sie versuchen, sich an dieselben Ports zu binden
- Zur Lösung wurde ein System aufgebaut, das beim Erstellen eines Worktree jedem Server automatisch einen eigenen Port-Bereich zuweist
- Damit können sogar 10 Previews gleichzeitig laufen
- Statt schon von 2 parallelen Branches überfordert zu sein, wurde auf einen Zustand umgestellt, in dem 5 Worktrees gleichzeitig betrieben werden
- Mehrere Agenten laufen in separaten Worktrees, bauen jeweils unterschiedliche Features und arbeiten autonom weiter, bis die UI-Selbstprüfung abgeschlossen ist
- Nach intensiver Beteiligung in der Planungsphase wird bis zum Zeitpunkt des Code-Reviews nicht mehr eingegriffen
- Auch Reviews laufen nun deutlich reibungsloser: lesen, prüfen, mergen – ohne Setup-Arbeit, Rebuilds oder Port-Konflikte
Der Kern ist nicht AI, sondern Infrastruktur
- Die Rolle hat sich verändert: Statt Zeit damit zu verbringen, komplexe Probleme selbst zu lösen und perfekte UI zu bauen, macht es mehr Spaß, Infrastruktur aufzubauen, die Agenten effektiv macht
- Es fühlt sich eher so an, als wäre man nicht Solo-Entwickler, sondern Manager eines zehnköpfigen Teams
- Es ist keine glamouröse Plumbing-Arbeit, aber genau sie entscheidet darüber, ob man im Flow bleibt oder mit der Umgebung kämpft
- Bei Tano war die Arbeit mit dem höchsten Hebel nicht Feature-Entwicklung, sondern der Aufbau einer Infrastruktur, die den Commit-Fluss in einen Stromschnellen-Modus verwandelt hat
Der Loop: Anwendung der Theory of Constraints
- Jeder Schritt beseitigt eine andere Art von Reibung:
/git-pr: beseitigt die Formatierungsreibung, um Code-Änderungen in eine PR zu überführen- SWC: beseitigt die Wartereibung zwischen Änderung und Sichtbarkeit des Ergebnisses
- Preview-Funktion: beseitigt die Verifikationsreibung beim Prüfen von Änderungen
- Worktree-System: beseitigt die Context-Switching-Reibung zwischen mehreren Arbeitsströmen
- Jedes Mal, wenn ein Engpass entfernt wird, wird sofort der nächste sichtbar – ein typisches Muster der Theory of Constraints
- Das Wesen der Arbeit hat sich verändert: Nicht mehr „ein Tool zum Schreiben von Code benutzen“, sondern ein enger Feedback-Loop aus Aufgabenstart → Agent schreibt Code → Preview prüfen → Diff lesen → Feedback oder Merge → nächste Aufgabe
- Wenn der Loop schnell genug ist, bleibt keine Lücke, in der die Aufmerksamkeit entweichen kann, und die Geschwindigkeitssteigerung selbst wird zum Spiel
- Am Ende verschiebt sich das Ziel der Entwicklung von der Feature-Implementierung hin zu der Frage, wie weit sich die Geschwindigkeit des Loops noch erhöhen lässt
- Ein Stadium, in dem Geschwindigkeit selbst zur Freude am Engineering wird
2 Kommentare
Als Reviewer war meine Erfahrung nicht besonders gut, wenn ich eine von einer Maschine geschriebene PR-Beschreibung gesehen habe. Vielleicht liegt es einfach daran, dass man nur das Prompt-Tuning gut hinbekommen muss..
Hacker-News-Kommentare
Es fühlt sich an, als wäre die Kennzahl „wöchentliche Codezeilen“ aus den 90ern zurück
„Mehr PRs zu machen“ ist kein Beleg dafür, dass AI gut funktioniert, sondern bedeutet nur, dass mehr gemergt wird
Codequalität, Bugs und Wartungsaufwand auszublenden und Leistung nur nach Output zu bewerten, unterscheidet sich nicht von den schlechten Metriken, die frühere Manager durchgedrückt haben
Am Ende haben wir wohl nicht schlechte Metriken abgelehnt, sondern es gehasst, überhaupt gemessen zu werden
Das eigentliche Ziel ist Code, der einfach ist und wirkungsvolle Ergebnisse liefert
Ich experimentiere damit, mehrere Agenten gleichzeitig laufen zu lassen, damit sie unterschiedliche Implementierungen versuchen, und die guten Ideen daraus zusammenzuführen
Außerdem sammle ich Dokumentation und Anforderungen, stelle dem Agenten dazu Fragen und verallgemeinere Feedback aus Code-Reviews zu Checklisten, die ich in die nächste Review übernehme
So viel zu arbeiten, dass man krank wird, ist kein Grund zum Stolz, sondern ein Signal für ein kaputtes System
Das COCOMO-Modell gilt zum Beispiel als so verlässlich, dass es sogar vor Gericht zur Schätzung des Systemwerts verwendet wird
Die meisten Entwickler wollen sich selbst nicht quantifizieren
AI-Befürworter meinen allerdings, dass man messen muss, um Verbesserungen nachzuweisen
Ich finde, man sollte LLMs so einsetzen, dass sie die kognitive Last reduzieren
Menschen sind schlecht im Multitasking, und LLMs gleichen das nicht aus
Ich lasse Claude die Implementierung nicht einfach übernehmen, sondern nutze es eher so, dass ich durch den Implementierungsprozess geführt werde
So verstehe ich den gesamten Ablauf und kann gleichzeitig Details und das große Ganze sehen
Claude sollte nur die repetitiven und mechanischen Teile übernehmen
Ich stelle dem LLM Fragen, damit es das Problem versteht, schreibe den Kerncode selbst und lasse es dann den restlichen Implementierungsplan aufstellen
LLMs sind stark beim Lesen, Erklären und bei einfachen Aufgaben im Code, und ich konzentriere mich darauf, die Richtung der Problemlösung zu wählen
Ich experimentiere mit Prompts wie „Erstelle eine Liste der Annahmen“ oder „Zähle Entscheidungen auf, die nicht im Plan standen“, um nachzuverfolgen, was das LLM an meiner Stelle entschieden hat
Wenn man die Eigenheiten von Claude versteht, wird auch die Verifikation effizienter, und mit mehr Erfahrung wird Qualitätskontrolle einfacher
Wenn man mehrere Agenten auf ein großes Feature ansetzt, entsteht am Ende das Problem, dass die Review-Zeit enorm steigt
Denn fremden Code zu lesen – ob von Menschen oder AI – ist schwieriger, als ihn selbst zu schreiben
Man könnte das mit Testautomatisierung abfedern, aber vollständiges Vertrauen ist schwer
Ich mache Umfang, Tests und Dokumentationsplan klar, setze Code-Review-Bots (Sourcery, CodeRabbit, Codescene) und starke Linting-Regeln ein
Dazu nutze ich BDD, Property Testing, e2e-Tests, Code Audits und sogar Mutation-/Fuzzing-Tests
Der Vorteil von Agent Coding ist, dass es Zeit für genau diese Qualitätskontrolle freimacht
Ich probiere schrittweise Auslieferung mit Ansätzen wie 100 PRs a day aus
Wenn man Arbeit kleinteilig schneidet und den Tests vertraut, wird auch AI-Code-Review leichter
Ich schaue mir die Testfälle genauer an und ziehe das Code-Review schnell durch
Ich lasse nicht mehrere Agenten parallel laufen, aber durch AI ist meine Produktivität definitiv gestiegen
Wenn das Schreiben von PRs nur noch automatisiert abläuft, verschwindet die Gelegenheit zur Selbstprüfung
Beim Formulieren der PR-Beschreibung habe ich oft Merkwürdigkeiten in meinem Code entdeckt
Der Moment, in dem ich es auf Englisch erklären musste, war der letzte Sanity Check
Dank des worktree-Systems ist Kontextwechsel leichter geworden, gleichzeitig steigt aber die mentale Ermüdung
Wenn man sie in kleine Einheiten aufteilt und kurze Review-Zyklen fährt, ist Qualitätskontrolle einfacher
Mir gefällt, dass ich meinen Flow nicht unterbrechen muss und am nächsten Tag zurückkomme, während der Fortschritt schon da ist
Ich bin skeptisch gegenüber der Annahme, dass Claude Code automatisch hochwertigen Code fertigstellt
In der Praxis braucht es mehrere Runden aus Feedback und Korrekturen, und mehrere Aufgaben gleichzeitig parallel zu steuern ist eher ineffizient
Claude Code ist als Lernwerkzeug revolutionär, aber die Qualität der Codegenerierung schwankt
Ich habe beim Lernen von Flutter/Dart Claude zu Konzepten befragt und konnte so ohne Buch in nur einer Woche eine App bauen
Es fühlt sich fast wie eine interaktive Enzyklopädie an
Auf Fragen wie „Was ist in dieser Sprache der idiomatische Weg, X zu tun?“ bekommt man sofort nützliche Antworten
Es ist aber weniger etwas, das die Welt verändert, als einfach ein sehr gutes Werkzeug
Übertriebenes Marketing hat aber negative Auswirkungen auf die Wirtschaft insgesamt
Es gibt auch die Sorge, dass jüngere Menschen Berufe aufgeben, weil sie der Illusion glauben, AI werde alle Jobs ersetzen
Es gab die Aussage: „Nach dem Wechsel auf SWC sank die Zeit bis zum Server-Neustart auf unter 1 Sekunde“,
SWC steht für Speedy Web Compiler und ist ein Tool zum schnellen Transpilieren ohne Type-Checking
Dasselbe wird auch in der NestJS-Dokumentation erklärt
Nur weil man LLMs nutzt, ist das kein Grund, mit explosionsartig gestiegener Produktivität zu prahlen
Wenn alle dieselben Tools verwenden, steigt einfach die Basislinie
Außerdem ist die langfristige Qualität unklar, wenn große Mengen AI-generierten Codes nicht ordentlich reviewt werden
LLMs steigern die Produktivität zwar, aber das über Commit-Zahl-Graphen zu messen, ist sinnlos
Genauso töricht wie Qualität nach LOC zu beurteilen
Ich schreibe den Code selbst und verstehe ihn dabei, und Claude hilft stark bei Aufgabenzerlegung und als Review-Partner
Die Fähigkeit, komplexen Code durch einfache Abstraktionen zu ersetzen, ist echte Produktivität