Kimi K2.5 vs Minimax M2.7 beim Refactoring
Direkter Vergleich zweier starker Modelle bei der Arbeit mit Legacy-Code – gleicher Prompt, gleiche Aufgabe, unterschiedliche Ergebnisse.
Bernd D.H. Martin
Benchmarks sagen wenig über den echten Arbeitsalltag. Deshalb habe ich beide Modelle mit einer konkreten Aufgabe konfrontiert, die ich regelmäßig mache: Legacy-Code verstehen und sauber umbauen.
Der Testfall
Ein Angular-Service aus einem älteren Projekt – ca. 340 Zeilen TypeScript, gewachsen über drei Jahre, mit mehreren Verantwortlichkeiten in einer Klasse: HTTP-Calls, Caching-Logik, Error-Mapping und State-Management waren untrennbar verwoben. Kein Unit-Test, kein Kommentar.
Klassischer Fall von "es funktioniert, niemand will es anfassen".
Der Prompt war identisch für beide Modelle:
Analysiere diesen Angular-Service. Erkläre was er macht,
identifiziere Probleme und schlage einen Refactoring-Plan vor.
Zeig danach die refactored Version mit sauber getrennten Verantwortlichkeiten.
Kimi K2.5
Analyse
Kimi hat den Code schnell und präzise eingeordnet. Die Erklärung war strukturiert: erst Was, dann Warum es problematisch ist, dann Vorschlag. Keine Umschweife.
Besonders stark: Kimi hat erkannt, dass das Caching implizit über einen lokalen Array lief – eine Stelle die ich selbst beim Überfliegen übersehen hatte.
Refactoring-Vorschlag
Der Umbau war sauber in drei Services aufgeteilt: DataService für HTTP, CacheService für Caching, ErrorMapperService für Fehlerbehandlung. Die Interfaces waren klar definiert, Dependency Injection korrekt.
Stärken:
- Sehr schnelle Verarbeitungszeit
- Erkennt implizite Abhängigkeiten die nicht offensichtlich sind
- Erklärt warum eine Entscheidung sinnvoll ist, nicht nur was zu tun ist
Schwächen:
- Der generierte Code hatte an einer Stelle eine veraltete RxJS-Syntax (
combineLatestals Array statt Objekt) - Bei komplexeren Typen wurde gelegentlich
anyverwendet statt korrekte Generics auszuarbeiten
Minimax M2.7
Analyse
Minimax war in der Analyse ausführlicher – fast zu ausführlich. Die Erklärung war vollständig, aber strukturell weniger klar. Man merkt, dass das Modell stark auf Vollständigkeit optimiert ist.
Was Minimax besser gemacht hat: Die Erklärung der Abhängigkeitskette war detaillierter. Für jemanden der den Code wirklich nicht kennt, ist Minimaxs Erklärung zugänglicher.
Refactoring-Vorschlag
Minimax hat stärker auf moderne Angular-Patterns gesetzt – Signals statt BehaviorSubject, inject() statt Konstruktor-Injection. Das ist aktueller, aber in einem Legacy-Projekt nicht immer der richtige erste Schritt.
Stärken:
- Kennt aktuelle Framework-Patterns sehr gut
- Ausführlichere Erklärungen, gut für Onboarding oder Dokumentation
- Typen waren durchgehend korrekt – kein
any
Schwächen:
- Tendenz zu Over-Engineering beim ersten Schritt (Signals einführen obwohl nicht gefragt)
- Antwortzeit spürbar langsamer als Kimi
Head-to-Head Vergleich
| Kriterium | Kimi K2.5 | Minimax M2.7 |
|---|---|---|
| Analyse-Präzision | Sehr gut | Gut, aber verbose |
| Refactoring-Qualität | Gut | Sehr gut |
| Typ-Korrektheit | Mittel (gelegentlich any) | Sehr gut |
| Framework-Aktualität | Solide | Ausgezeichnet |
| Erklärungsqualität | Prägnant | Ausführlich |
| Geschwindigkeit | Schnell | Langsamer |
Fazit: Wann welches Modell?
Kimi K2.5 ist mein erster Griff wenn ich schnell verstehen will was ein Code-Stück macht und einen pragmatischen Umbauplan brauche. Die Kürze und Geschwindigkeit gewinnen im Alltag.
Minimax M2.7 setze ich ein wenn ich in ein unbekanntes Framework einsteige oder wenn eine ausführliche, dokumentationsreife Erklärung gebraucht wird. Der stärkere Fokus auf aktuelle Patterns ist ein echter Vorteil sobald das Projekt sowieso modernisiert werden soll.
Für reines Legacy-Refactoring ohne Modernisierungsauftrag: Kimi. Für Refactoring mit gleichzeitigem Upgrade auf aktuelle Patterns: Minimax.