Korrekturhinweis (02.09.2026): Dieser Artikel enthielt bis heute Ergebnistabellen mit Trefferquoten und Zeitmessungen für drei Werkzeuge sowie den Verweis auf eine CSV-Datei mit Rohdaten. Weder die Messung noch die Datei hat es gegeben. Beides ist entfernt. Was bleibt, ist der Aufgabenkatalog und das Bewertungsschema — der Teil, der ohnehin den Gebrauchswert hatte.
Warum nicht noch ein Tool-Vergleich mit Zahlen
Weil er nichts taugt. Ein Coding-Tool-Vergleich hängt an drei Dingen, die dir niemand abnehmen kann: an deiner Sprache, an deiner Codebasis und daran, wie viel Nacharbeit du selbst noch reinsteckst. Dieselben fünfzig Aufgaben liefern in einem gewachsenen Django-Monolithen ein anderes Bild als in einem frischen Next.js-Projekt.
Dazu kommt das Verfallsdatum. Zwischen zwei Modellständen liegen Wochen. Eine Prozentzahl aus einem Blogartikel beschreibt einen Stand, den es beim Lesen nicht mehr gibt.
Deshalb hier kein Ergebnis, sondern das Verfahren.
Der Aufbau
Alle Werkzeuge bekommen dasselbe Repository, dieselben Dateien, denselben Prompt. Gemessen wird nicht nur, ob etwas herauskommt, sondern was es dich kostet, bis es brauchbar ist:
- Zeit bis zur ersten Antwort
- Review-Zyklen, bis das Ergebnis einsetzbar ist
- deine eigene Korrekturzeit pro Aufgabe
- daraus die Nettozeit — die einzige Zahl, die am Ende zählt
Der letzte Punkt ist der, den die meisten Vergleiche weglassen. Ein Werkzeug, das schneller antwortet und dafür mehr Nacharbeit erzeugt, ist nicht schneller.
Halte fest, welchen Modellstand du geprüft hast, mit Datum. Ohne das ist dein eigenes Ergebnis in sechs Wochen genauso wertlos wie fremde Zahlen.
Die fünf Kategorien
Zehn Aufgaben je Kategorie. Die Beispiele sind Vorlagen — ersetze sie durch Aufgaben aus deinem echten Projekt, sonst misst du eine Laborsituation.
Kategorie A — Neues Feature nach bekanntem Muster „Hier ist unser User-Service mit CRUD. Bau denselben für Subscriptions."
Kategorie B — Refactoring „Der ProductService hat 600 Zeilen und sieben Verantwortlichkeiten. Zerlege ihn in sinnvolle Services."
Kategorie C — Fehlersuche aus dem Stack-Trace „Hier ist der Trace. Behebe den Fehler, ohne bestehendes Verhalten zu brechen."
Kategorie D — Tests erzeugen „Schreib Tests für OrderService mit mindestens 80 % Abdeckung."
Kategorie E — Mehrdatei-Operationen „Wir wechseln von Django REST Framework zu FastAPI. Hier sind vier bestehende Views, portiere sie."
Kategorie E ist die aussagekräftigste. Editor-integrierte Werkzeuge und Terminal-Agenten unterscheiden sich vor allem darin, wie weit ihr Blick über die gerade offene Datei hinausreicht — und genau das zeigt sich erst, wenn eine Aufgabe mehrere Dateien konsistent anfassen muss.
Das Bewertungsschema
| Kategorie | Werkzeug A | Werkzeug B | Werkzeug C | |-----------|------------|------------|------------| | A · Neues Feature | /10 | /10 | /10 | | B · Refactoring | /10 | /10 | /10 | | C · Fehlersuche | /10 | /10 | /10 | | D · Tests | /10 | /10 | /10 | | E · Mehrdatei | /10 | /10 | /10 | | Gesamt | /50 | /50 | /50 |
Eine Aufgabe zählt als bestanden, wenn das Ergebnis nach höchstens zwei Review-Zyklen einsetzbar ist. Mehr als zwei Korrekturrunden gelten als Fehlschlag — sonst besteht am Ende jedes Werkzeug jede Aufgabe, es dauert nur unterschiedlich lang.
Für die Zeitseite eine zweite Tabelle:
| Kennzahl | Werkzeug A | Werkzeug B | Werkzeug C | |----------|------------|------------|------------| | Zeit bis brauchbar | | | | | Review-Zyklen | | | | | eigene Korrekturzeit | | | | | Nettozeit je Aufgabe | | | |
Fallstricke beim Messen
Drei Fehler, die einen solchen Vergleich wertlos machen:
- Reihenfolge-Effekt. Wer dieselbe Aufgabe dreimal hintereinander stellt, versteht sie beim dritten Mal selbst besser und formuliert schärfer. Mische die Reihenfolge der Werkzeuge je Aufgabe.
- Zustand im Repository. Läuft Werkzeug B auf einem Stand, den Werkzeug A vorher schon angefasst hat, misst du eine Kette statt eines Vergleichs. Nach jeder Aufgabe zurücksetzen.
- Bewertung im Nachhinein. Lege vorher fest, was „einsetzbar" heißt. Sonst verschiebt sich die Messlatte unbewusst zugunsten des Werkzeugs, das man ohnehin bevorzugt.
Was kein Werkzeug abnimmt
Aus dem 60-Tage-Tagebuch, und daran hat sich nichts geändert: Keines dieser Werkzeuge trifft gute Architekturentscheidungen. Keines fragt bei Unklarheit zurück. Keines hält Kontinuität über Tage.
Sie beschleunigen, was du ohnehin tun würdest. Das Nachdenken ersetzen sie nicht — und genau deshalb ist die Kennzahl „Nettozeit inklusive deiner Korrektur" die ehrlichere.
Weiterlesen
Den aktuellen Stand der beiden Marktführer — Abrechnung, Kontextfenster, verfügbare Modelle — findest du unter Cursor vs. Claude Code.
Im 60-Tage-Tagebuch geht es um einen langen Zeitraum mit einem Werkzeug statt um den Vergleich.
Du hast den Katalog gegen deine eigene Codebasis laufen lassen? Zone „Coding & Projekte" im Discord — dort sind konkrete Ergebnisse samt Modellstand willkommen.
