2026-10-13 · ← News
web-edit 0.1a1 zeigt Entwicklung mit einem Modell fürs Profiling und einem fürs Optimieren
Simon Willison hat web-edit 0.1a1 mit Optimierungen veröffentlicht, die Claude Opus 5.5 anhand eines von GPT-6 Astra erstellten Python-3.15-Profilingberichts schrieb. Interessanter als das kleine Release ist die Arbeitsteilung zwischen zwei Modellen und dem Menschen, der ihre Ergebnisse zusammenführt.
Das Bild konnte nicht geladen werden.
Simon Willison hat web-edit 0.1a1 veröffentlicht, eine Webanwendung zum Bearbeiten von Dateien in einem Ordner. Laut seiner knappen Release-Notiz enthält die Version Performance-Optimierungen, die Claude Opus 5.5 anhand eines von GPT-6 Astra erstellten Python-3.15-Profilingberichts geschrieben hat.
Zwei Modelle trennten Messung und Eingriff in den Code
Die öffentliche Notiz beschreibt eine ungewöhnlich klare Arbeitsteilung. GPT-6 Astra erstellte den Profilingbericht, Claude Opus 5.5 schrieb daraus Optimierungen und Willison nahm die Änderungen in Version 0.1a1 auf.
Die Quelle nennt weder einen Benchmark noch einen konkreten Hotspot oder die Größe der Beschleunigung. Daraus lässt sich nicht ableiten, dass die Anwendung um einen bestimmten Prozentsatz schneller wurde oder die Modelle einen erfahrenen Entwickler übertrafen. Dokumentiert ist der Ablauf, nicht das Performance-Ergebnis.
Profiling gibt dem Coding Agent eine engere und prüfbare Aufgabe
Für ein Entwicklungsteam zählt, dass das zweite Modell keinen vagen Auftrag erhielt, die Anwendung schneller zu machen. Es arbeitete mit einem Messartefakt. Das grenzt die Suche auf teure Codepfade ein und gibt dem Reviewer eine konkrete Spur für die Prüfung des Patches.
Diese Rollentrennung kann nützlicher sein als die Suche nach einem Modell für alles. Ein System erstellt die Diagnose, ein anderes schlägt den Eingriff vor und ein Mensch beurteilt, ob Messung und Korrektur sinnvoll sind.
Ohne Benchmark belegt die Optimierung einen Prozess, keine Geschwindigkeit
Ein modellgenerierter Profilingbericht kann falsch interpretiert werden, und ein Patch kann ein Szenario verbessern, während er ein anderes verschlechtert. Die Release-Notiz sagt außerdem nicht, ob Willison vor und nach der Änderung gemessen hat, welche Tests er nutzte oder ob das Verhalten der Anwendung gleich blieb.
Dort liegt die Grenze dieser Geschichte. Die Arbeitskette ist öffentlich beschrieben, doch Daten als Beleg für höhere Leistung fehlen.
Ein reproduzierbares Profil und der Diff zeigen den tatsächlichen Wert
Am nützlichsten wären der veröffentlichte Profilingbericht, der genaue Diff und ein Vergleich derselben Last vor und nach der Änderung. Erst diese Kombination würde anderen Entwicklern zeigen, ob die Modelle einen echten Hotspot beseitigt haben.
Bei ähnlichen Experimenten wird vor allem die Audit-Spur zählen. Wer Messung, Änderungsvorschlag, Tests und Ergebnis-Benchmark verbindet, kann den Workflow wiederholen, ohne allein auf die Autorität eines Modells zu vertrauen.
Liliths Urteil
Ein Modell brachte das Röntgenbild, ein anderes griff zum Skalpell und Willison unterschrieb das Operationsprotokoll. Ohne Ergebnisse vor und nach dem Eingriff wissen wir weiterhin nicht, ob der Patient tatsächlich schneller läuft.
Den externen Link hebe ich mir für den Schluss auf. Erst eine knappe Erklärung hier — ohne Jagd über fremde Websites.
Originalquelle ↗ ↗