KI-News bewegen sich schneller, als ein arbeitender Engineer sie testen kann. Wer jedem Modell, Benchmark, Agent-Framework und Editor-Feature folgen will, macht aus Lernen die Pflege eines Feeds.
Ich verfolge ein engeres Ziel: Änderungen bemerken, die eine Aufgabe verbessern könnten, die ich ohnehin erledige, und sie dann an genau dieser Aufgabe testen.
Beginne bei deinen Engpässen
Schreibe auf, wo Engineering-Zeit tatsächlich verloren geht. Bei mir fällt sie meist in Bereiche wie Repository-Suche, Testdiagnose, repetitive Migrationen, Code Review, Dokumentation und kleine UI-Iterationen.
Diese Liste ist der Filter. Ein Release ist relevant, wenn es Kosten, Geschwindigkeit oder Fehlerquote einer dieser Aufgaben verändert.
Ein neues Bildmodell mag interessant sein. Dringend ist es nicht, wenn dein aktueller Engpass das Debugging von Datenbanktransaktionen ist.
Halte drei Informationskanäle
Ich folge einer kleinen Auswahl an Primärquellen:
- Release Notes für Tools, die schon in meinem Workflow stecken;
- Maintainer, die Implementierungsdetails und Grenzen zeigen;
- Engineers mit ähnlicher Arbeit, die reproduzierbare Beispiele veröffentlichen.
Social-Media-Feeds taugen zur Entdeckung, nicht als Beweis. Wenn eine Behauptung zählt, lese ich die Dokumentation, das Issue, die Benchmark-Methode oder den Quellcode dahinter.
Das schützt vor Demo-Auswahl. Ein Tool, das an seiner Idealaufgabe gezeigt wird, kann an deiner Sprache, Repository-Größe, deinen Sicherheitsregeln oder deinem Budget scheitern.
Evaluiere mit einer Canary-Aufgabe
Behalte pro Tool-Kategorie eine kleine, repräsentative Aufgabe. Bei einem Coding-Agenten könnte das ein Bug sein, der Repository-Suche, eine gezielte Code-Änderung und Tests erfordert.
Führe dieselbe Canary-Aufgabe aus, wenn ein neues Modell oder Feature relevant aussieht. Halte fest:
Task:
Tool and version:
Time to first correct result:
Human corrections:
Verification result:
Usage or cost:
Notes:
Es geht nicht darum, einen universellen Benchmark zu veröffentlichen. Es geht darum, Tools an Arbeit zu vergleichen, die du gut genug verstehst, um sie zu beurteilen.
Nutze nach Möglichkeit eine frische Kopie der Aufgabe. Eine erinnerte Lösung, ein warmer Cache oder eine geänderte Abhängigkeit können das Ergebnis verfälschen.
Verlange einen spürbaren Gewinn
Ein Tool-Wechsel kostet: Einrichtung, neue Fehlerbilder, geänderte Shortcuts, Policy-Prüfung und verlorene Muskelerinnerung.
Ich übernehme ein neues Tool, wenn es eine praktische Schwelle überschreitet. Es sollte genug Zeit sparen, die Ergebnisqualität verbessern, eine blockierte Aufgabe lösen oder die Kosten so weit senken, dass sich der Wechsel lohnt.
Fünf Prozent Verbesserung bei einer Aufgabe, die ich monatlich erledige, sind Rauschen. Ein verlässlicher Weg, die Review-Zeit bei Arbeit zu kürzen, die ich täglich mache, verdient Aufmerksamkeit.
Bleib herstellerneutral
Nutze das Tool, das zur aktuellen Aufgabe und zu den Randbedingungen passt. Halte Prompts, Tests, Repository-Regeln und Evaluierungsaufgaben möglichst portabel.
Baue nicht deinen gesamten Prozess um ein herstellerspezifisches Feature, es sei denn, sein Nutzen rechtfertigt den Lock-in. Exportiere wichtigen Verlauf und behalte das Repository als Source of Truth.
Überprüfe nach Zeitplan
Ich evaluiere Tools nicht täglich. Ich sammle Kandidaten und gehe sie in einem festen Rhythmus durch, oder wenn ein echtes Problem die Frage erzwingt.
Die meisten Releases können warten. Die wenigen, die zählen, tauchen immer wieder auf, bekommen Dokumentation und überstehen den Kontakt mit gewöhnlicher Engineering-Arbeit.
Mithalten ist ein Filterproblem. Beginne bei deinen Engpässen, teste mit bekannten Aufgaben und übernimm nur die Änderungen, die deinen aktuellen Prozess schlagen.