GPT-5 revolutioniert die Programmierung mit realen Anwendungen

In den letzten Tagen habe ich Millionen von Tokens (danke Cursor und OpenAI!) verwendet, um die Fähigkeiten von GPT-5 im Bereich der Programmierung zu benchmarken. Ich habe festgestellt, dass es unglaublich geschickt darin ist, Code zu schreiben, der Probleme von Anfang bis Ende löst. In diesem Artikel beschreibe ich, wie ich GPT-5 genutzt habe, um ein mittleres Problem zu lösen: das Schreiben eines Parsers für das EVTX-Format in Zig (EVTX ist ein binäres Format, das für Windows-Ereignisprotokolle verwendet wird). Ich habe versucht, dies mit anderen Modellen zuvor zu tun, und GPT-5 war das erste Modell, das es tatsächlich erfolgreich umgesetzt hat!

Dies ist ein interessantes Problem, weil es: 1. nicht zu einfach ist – man benötigt einige tausend Zeilen Code, um etwas Funktionierendes zu erstellen; 2. nicht zu schwer ist – es ist nicht so ambitioniert wie das Schreiben eines vollständigen “Systems” oder etwas, das 20.000+ Zeilen umfasst; 3. deterministisch ist – es gibt eine Spezifikation und Referenzparser; 4. ich habe damit gekämpft und weiß, welche Teile schmerzhaft sind.

Ich werde die Gründe darlegen, warum ich denke, dass GPT-5 besser abgeschnitten hat als die vorherigen Modelle, mit denen ich versucht habe, diese Aufgabe zu bewältigen. Wenn Sie nur an dem Ergebnis interessiert sind, es ist tatsächlich in einem nutzbaren Zustand und sehr leistungsfähig, aber für die Produktion verwenden Sie bitte evtx.

Mein Test für ein reales Problem

Ich pflege evtx, einen in Rust geschriebenen EVTX-Parser, den ich vor Jahren erstellt habe; er ist immer noch recht beliebt. Als ich ihn ursprünglich schrieb, verwendete ich die Spezifikation hier.

Die Aufgabe, die ich dem Modell gab, ist recht einfach: 1. Nimm die Spezifikation – schreibe einen Parser. 2. Während !parser output = Rust output, repariere den Parser.

Ich wollte, dass das LLM es in Zig schreibt, weil: 1. ich Zig für eine interessante Technologie halte, um binäre Parser zu schreiben; 2. ich nicht möchte, dass es eine Implementierung aus einer anderen Sprache aus dem Gedächtnis/Web-Suchen klont; 3. ich nicht sehr versiert in Zig bin, also wollte ich es nicht selbst schreiben, aber ich würde es auf jeden Fall genießen, es zu lesen und zu sehen, wie es sich schlägt; 4. der Parser benötigt nicht viele externe Abhängigkeiten (da Zig kein großes Ökosystem hat); 5. Zig ist außerhalb der Verteilung für Modelle (hier schneiden alle kleineren Modelle/nicht-frontier Modelle im Grunde genommen schrecklich ab).

Warum GPT-5 besser abschneidet

Die größte Verbesserung: GPT-5 vermeidet es, “wild” am Code zu arbeiten. Es bevorzugt einen Workflow, der damit beginnt, Kontext zu sammeln – Dateien zu lesen, Dokumente zu überprüfen, nachzudenken – und dann Änderungen vorzunehmen. GPT-3 operierte ebenfalls in ähnlicher Weise, aber dies bringt es auf allen Ebenen voran. Im Vergleich zu GPT-3 macht es fokussiertere, minimale Änderungen; dies kumuliert sich wirklich gut, wenn es darum geht, Code zu produzieren, der später bearbeitet wird. Ich schätze, dass der von GPT-5 produzierte Code etwa 30% der Zeilen im Vergleich zu anderen Modellen ausmacht, und Änderungen können manchmal eine einzige Zeilenänderung sein (wie ein echter Mensch!).

Ich fand GPT-5 erheblich besser darin, nuancierte Anweisungen über die gesamte Kontext-/Laufzeit pro Sitzung hinweg zu befolgen. Ich instruierte die Modelle ausdrücklich, “Workarounds”, “Heuristiken” und anderen Müll zu vermeiden, auf den sie zurückgreifen, wenn sie das Problem nicht verstehen. Die Spezifikation ist deterministisch; dennoch, wenn Modelle es versäumen, einige Nuancen der Spezifikation zu “grok” (Wortspiel beabsichtigt), würden sie schreiben: “Ich habe einen Fallback-Weg hinzugefügt, der einfach zufällig versucht, was ich gesehen habe.” Dies bedeutet normalerweise, dass die Dinge schiefgehen und mehr Fehler auftreten werden.

Die Herausforderungen beim EVTX-Parsing

Das EVTX-Parsing ist nuanciert. Parser können auf subtile Weise fehlschlagen und man erhält unvollständige Datensätze. Wir können die Herausforderungen in zwei Kategorien unterteilen:

Micro-Level/Debugging

Debugging-Parser-Fehler ist wirklich schwierig. Selbst leicht falsche Parsing-Logik produziert kompletten Müll, sodass es oft nicht praktikabel ist, nur die Ausgabe zu verwenden, um zu debuggen oder Quellen zu überprüfen. Um über die Probleme nachzudenken, muss man: * Protokolle einführen. * Dinge in kleinere Teile zerlegen. * In der Lage sein, binäre Ausgaben zu interpretieren und zu verstehen, was passiert.

Ich bat alle Modelle während des Prozesses, Protokolle hinzuzufügen, wenn sie debuggen, und einen Logger zu erstellen, der die Modul-Verbosity umschalten kann, um den Kontext nicht zu überwältigen. Alle Modelle haben Schwierigkeiten mit EVTX-Vorlagen, was das Format ein wenig ärgerlich macht.

Macro-Level/Architektur

Um weiterhin Fortschritte zu erzielen, wäre es ratsam, den Code in eine Art Zwischenrepräsentation umzustrukturieren, anstatt zu versuchen, die Ausgabe während des Parsings “naiv” zu schreiben. Im Allgemeinen ist es schwierig, Codebasen zu refaktorisieren, insbesondere solche, die man nicht vollständig selbst verfasst hat (was ein Problem darstellt, wenn man versucht, einen Agenten eine Aufgabe vollständig zu erledigen). Dies erforderte im Wesentlichen, dass das Modell global über den gesamten Code “auf einmal” nachdenken musste.

Die Ergebnisse

Die Ergebnisse sind hier zu finden: GitHub Repository. Im nächsten Artikel werde ich näher darauf eingehen, wie ich es geschafft habe, den Zig-Code schneller zu machen als die ursprüngliche Implementierung und wie ich meinen Weg zu einem 3-fachen Geschwindigkeitszuwachs für die Rust-Version gefunden habe!