Dieser Artikel ist eine ungeordnete Sammlung von Dingen, die ich mit KI (hauptsächlich Claude Code, genauer gesagt Opus 4.6) ausprobiert habe.
Code Review
Hervorragend. Claude ist großartig beim Code Review. Wir haben die (ganz einfache standard-) Claude GitHub Action in unseren Workflow integriert und begonnen, verschiedene Varianten von @claude review zu verwenden, um Claude um ein Review zu bitten – und es findet regelmäßig Bugs, die kein Mensch je entdecken würde.
Varianten davon:
@claude review, keep it brief@claude review, output a table of issues@claude review, focus on changes since last review
Das ersetzt menschliches Review allerdings nicht. Menschen finden eine ganz andere Klasse von Problemen, die KI bisher nicht erkennen konnte: solche, die Überblick und großen Kontext erfordern. Code Review ist außerdem zu etwa 80% die Art und Weise, wie wir Entwickler miteinander kommunizieren. Bevor wir auf diesen Kanal verzichten brauchen wir mindestens ein anderes Medium, auf das wir den Austausch verlagern können.
Es ist auch wirklich wichtig, nicht einfach alle Vorschläge blind umzusetzen. Ich schätze, dass ich etwa 50% (tendenz steigend) von Claudes Feedback implementiere und den Rest ablehne.
Einfache Issues in GitHub Actions
Einfache issues reiche ich mittlerweile ebenfalls per claude-annotation direkt weiter (@claude implement this). Das funktioniert sehr gut und spart echte Zeit. Claude implementiert das Feature allein aus der Issue-Beschreibung heraus und erspart mir den ganzen Aufwand: Branch auschecken, Änderung implementieren, committen, pushen, Pull Request erstellen usw. Ich kann sogar mit weiteren @claude-Kommentaren im Pull Request iterieren.
Der einzige Vorbehalt: Es macht durchaus Sinn, den Branch auszuchecken und lokal daran weiterzuarbeiten, wenn sich herausstellt, dass das Problem zu komplex für maximal eine Korrekturschleife ist – denn die Iterationszyklen sind langsam, GitHub Actions brauchen Zeit zum Auf- und Abbauen, und bei jedem Lauf werden Tokens verbrannt, um den Kontext neu aufzubauen.
Hier könnte besseres Tooling einen massiven unterschied machen aber ich bin konservativ genug um die Tooling-Landschaft noch eine weile im Auge zu behalten bevor ich eine Lösung tiefer integriere.
Claude Code Online
Claude bietet eine Online-Funktion unter claude.ai/code. Ich liebe dieses Feature. Ich kann ein Repository, ein Issue oder einen Branch auswählen und direkt loslegen. Es führt Claude Code in einer VM auf Anthropics Servern aus. Ich habe dort keine Umgebung eingerichtet (und ich werde Anthropic auch nicht mit meinen Secrets vertrauen – ich höre, sie vibe-coden da eine Menge...) – daher ist das am nützlichsten für in sich selbst geschlossene Projekte wie ai-pod, aber trotzdem wirklich cool.
Das löst in gewissem Maße dasselbe Problem wie das GitHub-Actions-Setup, verliert aber nicht bei jedem Lauf den Kontext, die Interaktion ist unmittelbar wie wenn ich Claude Code lokal ausführe. Außerdem kann ich damit unterwegs auf dem Handy Dinge mit dem echten Code als Kontext besprechen. Andererseits ist es eine weitere Oberfläche, die ich im Blick behalten muss – neben GitHub-Kommentaren und meinen lokalen Terminals.
Issue-Analyse
Ich habe einen geplanten Job, der Claude täglich ein Issue auswählen, analysieren, Fragen stellen und einen Implementierungsplan vorschlagen lässt. Das ist im Grunde ein Testlauf dafür, ob Claude unsere Issues generell bereichern könnte.
Die Ergebnisse waren gemischt. Bei manchen Issues hat Claude nützliche Anmerkungen gemacht, bei anderen hat es am Ende eine lange Textwand produziert, die den Aufwand des Lesens nicht rechtfertigt. Möglicherweise lässt sich da mit einem besseren Prompt mehr herausholen.
Schreiben
Alle Blogbeiträge, die ich veröffentliche, sind komplett handgeschrieben. Schreiben ist für mich persönlich hauptsächlich ein Werkzeug, um meine eigenen Gedanken zu verlangsamen. KI ist dazu da, es zu beschleunigen. Als ich versucht habe, Formulierungen gemeinsam mit Claude zu erarbeiten, merkte ich schnell, dass sich das Ergebnis nicht wie meins anfühlt – und der Prozess war bei weitem nicht so hilfreich wie das eigenständige Schreiben.
Trotzdem habe ich einen Workflow erstellt, mit dem ich Blogbeiträge als Markdown-Dateien auf meinem Computer schreiben und direkt mit DatoCMS synchronisieren kann, anstatt in deren Web-Interface zu schreiben – so kann ich Claude trotzdem nutzen, um
meine Texte vom Englischen ins Deutsche zu übersetzen
Tippfehler, Inkonsistenzen und stilistische Probleme zu beheben
das Ergebnis für mich zusammenzufassen.
(Umfangreiche) Features implementieren
Es gibt Features, die gut für die KI-Implementierung geeignet sind. Wenn ich eines gelernt habe aus den vergangenen Monaten KI-Nutzung, dann, welche Features Vibe-Codable sind und welche nicht.
Meine Faustregel lautet: Wenn ich genau weiß, wohin ich mit einem Feature will und wie es implementiert werden soll, wird Claude normalerweise vernünftigen Code dafür produzieren – auch ohne dass ich meine Gedanken bis ins kleinste Detail ausformuliere. KI kommt einfach nicht gut mit Ambiguität zurecht, und Unklarheit in meinen Gedanken überträgt sich direkt auf Unklarheit in meinen Prompts.
Wenn ich nicht zumindest die grobe Form des Ergebnisses vor Augen habe, das ich erzielen möchte, ist es Zeit, selbst Hand anzulegen. Sicher, manchmal hilft eine gute Planungssession – aber meine eigene Ambiguität entsteht meistens dann, wenn ich an einem System arbeite, das ich noch nicht gut kenne. In solchen Fällen ist das Skizzieren einer Code-Lösung und das Beobachten, wo Grenzfälle und hässliche Workarounds auftauchen, ein direkteres und nützlicheres Feedback als ein berüchtigtermaßen harmoniebedürftiges LLM.
Das hat meinen Tagesablauf verändert: Morgens entscheide ich, ob ich mit KI an einer Reihe von Issues parallel arbeite oder ohne KI fokussiert an einem einzelnen Issue. Beides gleichzeitig funktioniert nicht, weil der erforderliche Gemütszustand einfach so unterschiedlich ist.
Um es auf den Punkt zu bringen: Das Hauptding, das KI nicht selbst herausfinden kann, ist Absicht. Sie kann Pläne, Lösungen, Tests, Code in allen möglichen Sprachen und großartige Worte produzieren – vielleicht sogar die besten Worte. Aber sie kann die Absicht hinter einem Feature nicht erkennen. Das muss der Mensch einbringen. Und wenn mir die Absicht einer Änderung selbst nicht klar ist, kann ich sie dem LLM nicht mitteilen – und es wird unbeabsichtigten Code produzieren.
Refactoring
Claude hat es leicht gemacht, lange aufgeschobene Refactorings endlich anzugehen. Ich war schon immer ein Fan von mutigen Refactorings. Bisher war ich auf Dinge beschränkt, die ich semi-automatisiert mit Regexes und etwas Aufsicht erledigen konnte – jetzt kann Claude nahezu beliebige Refactorings durchführen, und es ist wirklich gut darin.
Dieser Anwendungsfall bringt nicht dieselben Herausforderungen mit sich wie das tatsächliche Implementieren neuer Features. Bei einem Refactoring ist der Code bereits vorhanden, die Absicht ist darin kodiert, und alles, was Claude tun muss, ist ihn nach einem strikten Muster anzupassen.
Zwei verbleibende Probleme bei Claude-basierten Refactorings:
Claude ist überraschend schlecht darin, Dinge erschöpfend durchzuführen. Die Ergebnisse sind auf Best-Effort-Niveau. Das ist kein Problem, wenn der Compiler es anleiten kann, und in einigen Fällen kann es Listen von Referenzen mithilfe statischer Analysetools wie LSPs durcharbeiten – aber das sind leider meist genau die Fälle, in denen ich Claude gar nicht bräuchte. Das wird mit wachsenden Modellfähigkeiten besser.
Refactorings betreffen viel Code. Wenn Claude eines durchführt, verliere ich generell etwas Vertrauen in den gesamten betroffenen Code – denn es passiert einfach regelmäßig, dass sich dabei Fehler einschleichen. Die sind noch dazu oft subtil und unerwartet.
Tests
KI kann sehr nützliche Tests produzieren. Ich kann ein Szenario, das ich testen möchte, in normalem Deutsch beschreiben, und es wird einen funktionierenden Test dafür produzieren – egal wie schwer testbar das Szenario erscheint. Der Testcode kann unschön werden, funktioniert aber meistens gut und ist in der Regel zumindest nützlich genug, um das LLM dazu zu bringen, das Problem tatsächlich zu beheben, für das der Test geschrieben wurde.
Was nicht funktioniert:
Add some tests. Schlechter Prompt. Nicht machen – es werden bedeutungslose Tests hinzugefügt, die nur zusätzliche Arbeit verursachen und wertvolle Pipeline-Minuten kosten.Tests und Code gleichzeitig fixen. Die KI versteht die Absicht weder hinter dem Code noch hinter dem Test. Wenn sie beides ändern darf, wählt sie im Wesentlichen zufällig, ob der Test oder der Code angepasst werden soll. Das führt manchmal zu katastrophalen Ergebnissen:
vi.mock('@lib/auth', () => ({ enforceAuth() { return false } })
describe('enforceAuth', () => {
it('returns false if no user is authenticated', () => {
expect(enforceAuth()).toBe(false)
})
})Rewrites
Es ist inzwischen sehr einfach, eine Legacy-Codebase anzugehen und sie mit einem LLM in wenigen Tagen von Grund auf neu zu schreiben. Ein Rewrite hat meistens ein Ziel – zum Beispiel die Gesamtperformance zu verbessern.
Das Ergebnis sieht meistens großartig aus: der Code wirkt sauber, die Zielmetrik ist erfüllt.
Nach einer Weile bemerkt man, dass ein Feature, das in der alten Version vorhanden war, fehlt. Claude hat den Performance-Score einer Website um 20% und die Barrierefreiheit (gemessen mit Lighthouse) um 40% verbessert. Das klingt toll. Dabei wurden vielleicht die strukturierten Daten verloren, die so viel für das eigentliche Suchranking geleistet haben.
Solche Dinge können in der Regel durch sorgfältige Reviews oder Audits aufgedeckt und dann behoben werden – aber indem Claude Code produziert, der tatsächlich extrem plausibel aussieht, hat es das Auditing erheblich erschwert. Normalerweise kann ein erfahrener Entwickler eine Codebase nach Mustern scannen: häufig angefasste Dateien, bekannte Code Smells, exotische Benennung, Wiederholungen, toter Code, allgemeine Code-Hässlichkeit. All diese Techniken versagen bei einem Claude-Rewrite – das Auditing beschränkt sich dann wirklich auf die Überprüfung des Ergebnisses. Das lässt uns mit nur der halben Werkzeugkiste.
Zusammenfassung
KI – und Claude Code im Besonderen – ist für bestimmte Aufgaben zu einem echten Produktivitätsmultiplikator geworden: Code Review, einfache GitHub Issues, Refactoring und das Schreiben von Tests sind klare Gewinner. Der gemeinsame Nenner bei dem, was funktioniert: Die Absicht ist bereits klar – entweder in meinem Kopf oder im vorhandenen Code kodiert. KI führt gut aus, wenn sie einer definierten Form folgen kann.
Die Schwachstellen sind genauso konsistent: Unklare Ziele produzieren unklaren Code, erschöpfende Aufgaben werden auf Best-Effort-Niveau erledigt, und Rewrites, die sauber aussehen, können wichtiges Verhalten stillschweigend verlieren. Das Werkzeugset für das Auditing von KI-generiertem Code ist kleiner als bei menschlich geschriebenem Code – ein unterschätztes Risiko.
Die Meta-Lektion, zu der ich immer wieder zurückkomme: KI verstärkt Klarheit. Wenn ich weiß, was ich will, bringt mich KI schneller dorthin. Wenn nicht, bringt sie mich irgendwohin, das plausibel aussieht – was schlimmer sein kann als gar nichts.
Übersetzt von Claude
Original auf Englisch
