Die Grenzkosten der Korrektheit gehen gegen Null. Sie müssen sich bewusst machen, was das für Ihre Arbeitsweise im Bereich Softwareentwicklung bedeutet. Sie müssen darauf versessen sein, die Dinge korrekt zu erledigen.
Früher konnte sich ein Ingenieur durch reines technisches Talent von anderen abheben: effizientes algorithmisches Denken, skalierbare verteilte Systeme, das mühsame Durcharbeiten von Debugger-Haltepunkten. Dies verliert jedoch in immer schnellerem Tempo an Bedeutung. Dank KI-Agenten ist heute jeder in der Lage, korrekten Code zu schreiben.
Die wichtigste Fähigkeit, die Sie entwickeln müssen, um sich heute von anderen abzuheben, ist ein gutes Gespür: die Fähigkeit, Dinge zu erkennen, die einfach nicht stimmen, und die Willenskraft, sie in Ordnung zu bringen.
Wir trainieren bei Pangram gerade ein neues Modell (ich glaube nicht, dass ich damit zu viel verrate) – es wird größer, intelligenter und auch *schneller* sein als unsere bisherigen Modelle. Dieser letzte Superlativ wäre ohne die Besessenheit, Dinge einfach nur um ihrer selbst willen richtig zu machen, nicht möglich gewesen. Weil wir es können. Weil wir stolz auf unser Handwerk sind. Weil ich eines Tages unsere API getestet habe und dachte: „Das sollte definitiv schneller sein als das hier.“
Damals konnte ich noch nicht ahnen, wie genau sich dieser Sprung ins Ungewisse auszahlen würde. Ich war lediglich von der Überzeugung getrieben, dass wir die Dinge richtig angehen sollten, und von dem Glauben, dass mit Fable an meiner Seite alles möglich war.
Nur wenige Tage später hatten wir es geschafft und den Kampf gegen die Latenz gewonnen, die mein Dogfooding zuvor beeinträchtigt hatte. Mit Fable gelang es mir, eine vollständig lokale Testumgebung für unseren komplexen, verteilten API-Orchestrator zu erstellen. Wir erstellten Hypothesen für alle Hotspots in unserem Code und testeten für jeden einzelnen Korrekturen. Wir führten komplexe Redis-Operationen in einer Pipeline durch und überprüften die Beibehaltung des Verhaltens. Wir führten Simulationen verschiedener Lastmuster auf Basis des Produktionsdatenverkehrs durch und schätzten die erforderliche Infrastruktur ab.
Ohne Agenten wäre dies ein undurchführbares, undurchführbares Projekt gewesen – es hätte Wochen oder Monate an Entwicklungsarbeit in Anspruch genommen. Stattdessen war es ein Nebenprojekt, während mein Trainingslauf im Hintergrund ablief.
Für unsere Bemühungen wurden wir mit einer etwa fünffachen Steigerung der GPU-Auslastung belohnt – von 20 % (autsch) auf 98 % – und einem Durchsatz, der dem unserer Bare-Metal-Knoten in nichts nachsteht. Das hat uns kaum etwas gekostet. Und es hat uns alles eingebracht. Dadurch wurde das Hosting unseres neuen Modells von einer unerschwinglichen Ausgabe zu einem regelrechten Schnäppchen.

Leider gibt es keinen einfachen Trick, um den Geruchssinn zu trainieren, aber es ist eine Fähigkeit, die man entwickeln kann. Folgendes hat bei mir (glaube ich) funktioniert:
Alles, was dich frustriert, frustriert wahrscheinlich auch deine Nutzer – beiß einfach nicht die Zähne zusammen. Du musst in dich hineinhören: Achte darauf, was dich im Laufe des Tages leicht aus der Ruhe bringt, welche Teile des Codes du vielleicht unbewusst meidest oder bei welchen Aufgaben du etwas zu unruhig wirst. Genau hier liegen die Chancen, etwas zu verbessern. Das war der Auslöser für meine eingehende Auseinandersetzung mit der API-Optimierung.
Ich sage gerne: „Einfache Dinge sollten einfach sein.“ Das gilt sowohl für Ihren Code (z. B. sollte die Ausführung eines einfachen Trainingsablationstests keinen geistigen Aufwand erfordern) als auch für Ihr Produkt (z. B. sollte ein einzelner API-Aufruf kaum langsamer sein als der Forward-Pass selbst). Wenn Sie sich dabei ertappen, zu denken: „So schwer sollte es eigentlich nicht sein“, dann beheben Sie das Problem! Sie haben jetzt doch Agenten! Starten Sie einen Worktree und werfen Sie Codex hinein. /Ziel Probier es doch einfach mal aus – was hast du schon zu verlieren?
Agenten machen das so einfach. „Wie lange sollte diese Aufgabe angesichts unserer Batchgröße, der GPU-Spezifikationen und der Anzahl der Parameter dauern?“ „Wie viel sollten wir angesichts unseres Daten- und Abfragevolumens für diesen Anbieter ausgeben?“ Wenn man weiß, wie das Richtige aussieht, ist es viel einfacher zu erkennen, was falsch ist.
Das mache ich für jede von uns unterstützte Modell-/Knoten-/Anfrage-Topologie – so optimiere ich unsere vLLM-Konfiguration, um sicherzustellen, dass wir nahe an der theoretischen Grenze liegen. So habe ich festgestellt, dass es eine Lücke zwischen unserem API-Durchsatz und dem gibt, was wir auf einem Bare-Metal-Knoten erreichen.
Dieser Grundsatz gilt auch für Ihren Code. Wenn Ihnen eine Abstraktion seltsam erscheint, geben Sie sich nicht einfach mit der Antwort „Das war schon immer so“ zufrieden. Überdenken Sie die Vereinbarung von Grund auf – wie sollte sie angesichts unseres heutigen Wissensstandes aussehen? Ihre Aufgabe ist es, herauszufinden, in welche Richtung der Agent gelenkt werden soll. Der Agent kann über Nacht Refactorings vornehmen und die Korrektheit überprüfen.
Eine meiner Lieblingsoptimierungen, die ich in meiner ersten Woche bei Pangram umgesetzt habe, wurde vom hybriden Sparse-Attention-Mechanismus von DeepSeek V4 inspiriert.
Meine Optimierung hatte nichts mit neuronalen Architekturen zu tun, geschweige denn speziell mit Attention. Es handelte sich um eine Verbesserung des Algorithmus, den wir zur Erkennung von Grenzen zwischen von Menschen verfassten und KI-generierten Texten verwenden und der zuvor einen unbegrenzten zweiten Inferenzdurchlauf erforderte.
Sammle so viele interessante Ideen von so vielen klugen Köpfen wie möglich. Deine Aufgabe ist es jetzt, unendlich neugierig zu sein, Zusammenhänge herzustellen und „Was wäre, wenn?“ zu fragen. Denk daran: Die Grenzkosten für das Herausfinden gehen gegen Null.

Ich habe jeden Sonntag ein Ritual, bei dem ich einfach Codex auf eine zufällige /Ziel um zu versuchen, meine wöchentlichen Token vor dem Reset aufzubrauchen. Meistens werfe ich den Code am Ende weg oder er verstaubt in einem vergessenen PR-Entwurf. Manchmal zahlt es sich aus. Ich lerne fast immer etwas aus dieser Übung. So oder so kostet es mich nichts. Manche nennen das „am Spielautomaten spielen“, aber ich sage: Wer nicht spielt, kann auch nicht gewinnen.

Ben ist bei Pangram an der Schnittstelle zwischen KI-Forschung und -Entwicklung tätig. Sein Interesse gilt dem Training größerer, intelligenterer Modelle und deren großflächigem Einsatz.






