Warum Software-Fabriken scheitern

oder: das Harness reicht nicht

Update – Die Talk-Version dieses Beitrags ist auf YouTube live: https://www.youtube.com/watch?v=Ib5GBkD555M

Ich schätze, wir machen jetzt Loops

Wir alle sind im Rennen, KI-Code in Produktion zu bringen. Es wurde viel über Loop-Engineering gesagt, und die vorherrschende Meinung ist, dass wir wahrscheinlich mehr Loops schreiben sollten.

StrongDM hat über ihre Softwarefabrik ohne Licht geschrieben, in der kein Mensch Code liest und kein Mensch Code schreibt.

Die Erzählung geht ungefähr so:

1. Du bist der Engpass.
2. Die Modelle sind gut genug.
3. Code ist kostenlos.
4. Liefer einfach mehr Zeug aus.

Ryan Lopopolo von OpenAI hat im Februar darüber geschrieben und im April einen Talk gehalten über OpenAIs Softwarefabrik, Symphony.

Diese Leute sind alle verdammt schlau und ich habe großen Respekt vor ihnen. Aber die zynischste Interpretation hier wäre, dies als eine weitere Ausrede zu bezeichnen, um mehr VC-Geld in die Schloderkanone zu pumpen.

Es ist, äh... es läuft

Unser Freund Mario ist bei AI Engineer Europe aufgestanden und hat uns gebeten, langsamer zu machen – weil Unternehmen, die eigentlich keine Ausfälle aufgrund von Coding-Agent-Pannen haben sollten, nun ja... Ausfälle aufgrund von Coding-Agent-Pannen haben.

Wie Matt Pocock es ausdrückte: Codebasen zerfallen schneller als je zuvor.

Ich konnte keine eindeutigen Daten/Erkenntnisse von StrongDM dazu finden, wie diese ganze dunkle Fabrik gelaufen ist. Der Wetterbericht hat ein paar spärliche Updates zwischen Februar und Juni dieses Jahres. Bearbeitung – Es gibt eine Diskussion mit dem Team auf Hacker News vom 23. Juli – klingt, als ob wir bald ein formelleres Update bekommen könnten!

Die Leute bei Faros AI haben einen Bericht veröffentlicht: Seit wir2 alle diese KI-Coding-Tools im Januar und Februar aufgegriffen haben, ist die Qualität der Pull-Request-Reviews drastisch gesunken.

• Mehr Kommentare, längere Kommentare und jede Menge PRs, die ohne jede Überprüfung gemergt werden.
• Vorfälle sind stark gestiegen.
• Bugs pro Entwickler sind stark gestiegen.

Dieser Bericht ist eher ein Korrelationssignal als ein verifizierbares Rauchfass (ja, ich habe dieses Wort absichtlich gewählt, fangt mich nicht mit Claude-Prosa an), und der ganze Punkt dieses Beitrags ist, vorsichtig mit Schloderdaten zu sein, aber es fühlt sich basierend auf dem, was ich gesehen habe, richtungsmäßig gültig an.

„Du hältst es falsch“ (tust du nicht)

Viele Leute werden dir sagen, dass das ein Skill-Problem ist – dass wenn du keine guten Ergebnisse bekommst, das deine Schuld ist.

Aber wie auch immer du dich entscheidest, es zu... ähm... halten, ich garantiere dir, dass dir gesagt wird, dass wenn Token-Maxxing für dich nicht funktioniert, es ein Skill-Problem ist. Du musst nur mehr Tokens ausgeben. Hör auf, den Code zu lesen. Und wenn du gerade erst anfängst, ich verspreche dir, es gehört zur Entwicklung dazu. Ich dachte letztes Jahr im Sommer auch so.

Leider für mein Ego wurden einige dumme Dinge, die ich darüber gesagt habe, „wie man es besser hält“, aufgezeichnet und haben jetzt insgesamt etwa eine Million Aufrufe auf YouTube. Ich versuche hier nicht anzugeben, ich teile das nur, um zu verdeutlichen, dass ich mich schon sehr lange intensiv mit den besten Methoden zur Nutzung von Coding-Agenten beschäftigt habe und einige Dinge entdeckt habe, die viele andere wirklich nützlich fanden.

• Advanced Context Engineering for Coding Agents
• No Vibes Allowed – Solving Hard Problems in Complex Codebases
• Everything We Got Wrong About RPI

Wie auch immer, Das Versprechen all dieses Online-Geplappers über „einfach härter tokenisieren“, das wir ertragen mussten, ist kurz gesagt: Mit genügend Harness-Engineering können wir das Beste aus beiden Welten bekommen:

• 10 bis 100x schneller,
• hohe Qualität, und
• niemand muss jemals das tun, was wir alle hassen – Code-Review

Alles, was wir tun müssen, ist, mehr Linter zu konfigurieren und ein paar magische Worte wie „adversarial review“ auf genügend PR-Review-Bots zu streuen, und unsere Software wird sich fröhlich von selbst bauen, ohne Zwischenfälle.

Das ist kein Skill-Problem

Was ich versuchen werde, dich zu überzeugen, ist, dass kein noch so großes Harness-Engineering oder Loops-Maxxing lösen kann, was im Grunde ein Problem des Modelltrainings ist.

Um das zu begreifen, musste ich mich damit befassen, wie Coding-Modelle tatsächlich trainiert und evaluiert werden – sowohl in Bezug auf RLVR als auch auf die Benchmark-Seite.

In diesem Beitrag werde ich Folgendes durchgehen:

1. Softwarefabriken gehen zurück bis 1968, wie haben sie sich entwickelt und wie hat KI sie verändert?
2. Warum Modelle Berge von Schloder produzieren können, obwohl sie Benchmarks mit Bravour bestehen (sogar die brandneuen „Frontier“-Benchmarks)
3. Trotzdem kannst du ziemlich schnell vorankommen, ohne deine Codebasis in Brand zu setzen

Ich werde versuchen, den Hype um jedes täglich neu erscheinende Skills-Plugin und die KI-Psychose-Token-Maxxing-Ratschlags-Pandemie zu durchbrechen und in allgemeinen Begriffen über die Arten von Dingen, die funktionieren, zu sprechen, ohne auf ein bestimmtes Skill oder Framework zu verweisen.

Video-Version: Dieser Beitrag basiert auf (und erweitert) meiner Keynote auf der AI Engineer World's Fair 2026.

Danke an @addyosmani, @CyrusNewDay, @HamelHusain, @zeeg, @dillon_mulroy, @nayshins und @jeffreyhuber für das Feedback zu diesem Beitrag.

Ein Exkurs: Das hat nichts mit Vibe-Coding zu tun

Addy Osmani hat das entwirrt, was es wert ist, hervorgehoben zu werden:

Ein Entwickler, der ein Nebenprojekt mit Vibe-Coding betreibt, das ein Dutzend Leute jemals nutzen werden, und ein Team, das ein zehn Jahre altes Unternehmenssystem für ein weiteres Quartal am Leben erhält, teilen fast keine nennenswerten Einschränkungen, und der Großteil der im Umlauf befindlichen Ratschläge ist wirklich einer dieser beiden Leute, die dem anderen sagen, wie er zu leben hat.

Wenn du Vibe-Coding liebst, bitte, mach weiter so. Ich vibe-code auch viele Dinge, ich betreue aber auch viele Produktionssysteme (und helfe durch HumanLayer Tausenden anderen Ingenieuren, dasselbe zu tun), also richtet sich der Rest des Beitrags an Leute, die schwierige Probleme in komplexen Codebasen lösen.

Ich höre oft das Wort Brownfield, um diese Trennung zu beschreiben. Historisch bedeutete das ein zehn Jahre altes Java-Ding, aber bei dem Tempo, das wir jetzt liefern können, fühlt es sich an, als ob eine agentengebaute Codebasis nach vielleicht drei bis sechs Monaten anfängt zu kämpfen – du wirst langsamer, und die Art und Weise, wie du neue Dinge hinzufügst, muss sich ändern.

Eine kurze Geschichte der Softwarefabrik

Ich habe meine gesamte Karriere über Softwarefabriken gebaut und studiert, aber ich habe erst kürzlich gelernt: Der Begriff geht zurück auf eine NATO-Konferenz im Jahr 1968 – dieselbe, die uns „Software Engineering“ bescherte.

Das einzige andere, was ich seitdem super interessant finde, ist, dass das US-Verteidigungsministerium ein 31-seitiges PDF verfasst hat, wie das DoD Jenkins besser nutzen muss oder so.

Die Softwarefabrik von 2022

Lass uns unsere Definition von „Softwarefabrik“ um das Jahr 2022 herum verankern, kurz vor KI. In einer typischen Softwarefabrik:

• Leute entscheiden, was gebaut wird – Ingenieure, PMs, Führungskräfte, die die Vision vorantreiben
• Es kommt in ein Tracking-System – Linear, Jira, was auch immer: eine Zustandsmaschine, was passieren muss
• Jemand schnappt sich ein Ticket und baut es – macht wahrscheinlich währenddessen ein paar manuelle/automatisierte Tests
• Pull-Request – automatische Checks, ein Mensch reviewt den Code, vielleicht zieht es jemand runter, um es zu testen
• Irgendwas falsch? Zurück zu „jemand baut das Ding“
• Auslieferung in Produktion – und es kommt in Kontakt mit Nutzern
• Monitoring hinzufügen – es gibt eine ganze Branche, die darum herum aufgebaut ist, um 3 Uhr morgens einen Ingenieur zu alarmieren, wenn etwas kaputtgeht
• Nutzer beschweren sich – fragen nach Dingen, finden Bugs, reichen Feature-Wünsche ein → zurück zum Team, um sie ins Tracking-System aufzunehmen

Und so weiter und so fort. Noch bevor wir überhaupt KI ins Spiel gebracht haben, gibt es bereits mehrere Loops in diesem Bild.

Alignment vorverlagern

Es gibt eine Sache, die Teams vor Jahrzehnten herausgefunden haben: Bauen dauert Stunden oder Tage, und Review auch.

Also verlagern wir die Arbeit vor – Planung, Architekturvorschläge, Sprint-Planung – gemeinsam als Team. Das bedeutet:

• weniger Nacharbeit, weil wir uns abgestimmt haben, bevor jemand Code geschrieben hat
• weniger Zeit für das Review jeder Zeile, wenn du jemals einen langen, aber gut gemachten PR gelesen hast, weißt du, wie schnell das Review geht, wenn es nahezu perfekt ist

Darauf kommen wir später zurück – lass uns anschauen, was passiert, wenn du agentisches Coding ins Spiel bringst.

Die agentische Softwarefabrik

Jetzt hat jedes Unternehmen und seine Mutter –

• Ramp
• Stripe
• WorkOS
• Brex

den größten Teil dieses Jahres damit verbracht, zu erklären, wie sie eine Agentenfabrik gebaut haben, die etwa 75 % ihres Codes ausliefert.

Die agentische Fabrik sieht meist so aus, dass „jemand baut das Ding“ durch „ein Agent baut das Ding“ ersetzt wird – es gibt hier einiges wie Orchestrierung, ein Harness, eine Sandbox, ein Modell, Computer Use usw. Ich werde nicht ins Detail zu diesen Dingen gehen, weil ich es ehrlich gesagt satt habe, darüber zu lesen, und ich bin sicher, du auch.

Wenn der Agent das Ding baut:

• Bauen sinkt von Stunden oder Tagen auf Minuten oder Stunden.
• Review dauert immer noch Stunden oder Tage. Ein Mensch muss den Code immer noch lesen und die Änderung testen. Also ist Review jetzt der Engpass.

Also beschleunigst du auch das Review:

• Agentisches Code-Review, um Stil, Bugs, Sicherheit zu erfassen.
• Agentisches Regressionstesting, um es von außen mit Browsern und Computer Use zu testen und dir vielleicht ein niedliches kleines Video zu schicken, wenn es fertig ist

Review ist jetzt schneller, aber es ist wahrscheinlich immer noch der Engpass. Aber wir können mehr Loops machen.

Als nächstes könntest du Vorfälle in die Fabrik leiten. Anstatt jemanden um 3 Uhr morgens zu alarmieren, wacht er zu einem PR auf, der es vielleicht schon behebt.

Wir können auch Nutzerfeedback in die Fabrik leiten. Leute fragen nach Dingen, es wird gebaut.

An diesem Punkt besteht der Job aus zwei Fragen: Wie viel kannst du in die Warteschlange stecken, und wie schnell kannst du reviewen und testen, was rauskommt?

Was uns zur Softwarefabrik ohne Licht bringt.

Die Softwarefabrik ohne Licht

Dan Shapiro hat diesen Begriff geprägt und Simon Willison hat über StrongDMs Implementierung davon geschrieben – wo wir den Code nicht mehr lesen.

Du schaust auf deine schöne Softwarefabrik. Sie ist ruiniert von diesem lästigen kleinen Code-Review-Schritt, und du sagst: Weißt du was, dieses Ding, bei dem ein Mensch jede Änderung liest? Nein danke.

Also lässt du es weg und steckst die Mühe woanders rein:

• Investiere in Tests und lass den Agenten seine eigene Arbeit testen
• Investiere in Sandboxen und Orchestrierung
• Investiere in automatisiertes Review
• Investiere in Monitoring
• Investiere in Rollout
• Investiere in das Sammeln von Feedback-Signalen von Nutzern

Und jetzt besteht der Job wirklich nur aus einer Frage: Wie viel Zeug können wir den Agenten bitten zu bauen? Wie viel vom Ozean wollen wir verkochen?

Das wird großartig (wird es nicht)

Ich werde etwas postulieren, das vielleicht kontrovers ist: Die Fabrik ohne Licht funktioniert nicht.

Lass uns eintauchen, warum Softwarefabriken scheitern.

Wir haben das versucht

Im Juli 2025 sind wir komplett ohne Licht gefahren. Einfach die Spezifikationen und Tickets gelesen, Hintergrund-Agenten für das ganze kleine/mittlere Zeug, der ganze Kram.

Wenn du das ernsthaft für ein paar Monate versucht hast, weißt du bereits, wie es endet. Du findest mindestens ein Problem, das knifflig genug ist, dass der Agent es nicht lösen kann – selbst mit deinem ausgefeiltesten Prompting und Workflows.

• Du machst tiefe kontextbewusste Recherche, sammelst alle richtigen Teile in der Smart-Zone, damit das Modell sie analysieren kann
• Du lässt den Agenten versuchen, es auf 10 verschiedene Arten zu reproduzieren

Irgendwann musst du in den sauren Apfel beißen und in die Codebasis eintauchen, die du vor drei Monaten aufgehört hast zu lesen, um herauszufinden, was kaputt ist.

Und in der Zwischenzeit:

• Deine Seite war down.
• Deine Nutzer waren sauer.
• Und du, wenn du so bist wie ich, warst elend – hast all den Schloder-Code gelesen, den du in dein System gelassen hast.

Das erste Mal, als das passierte, habe ich es abgeschüttelt. Auch wenn ich gerade den besseren Teil von zwei Wochen damit verbracht hatte, Claude-Spaghetti zu durchforsten, „das Abwärtsrisiko war die Geschwindigkeit wert“. Beim ~dritten Mal im November entschieden wir, dass es einfacher wäre, von Grund auf neu zu schreiben, und mein Mitgründer hat zwei ganze Wochen in VS Code (nicht mal Cursor) verbracht und alle Patterns von Hand reingeschrieben.

Modelle verschlechtern die Codequalität im Laufe der Zeit

Worauf ich hinaus will, ist dies: Modelle haben eine Schwäche. Sie können die Codequalität im Laufe der Zeit nicht aufrechterhalten und verbessern – nicht ohne eine anständige Menge menschlicher Steuerung.4

Wenn ich Wartbarkeit sage, meine ich die spezifische Sache, bei der es wirklich, wirklich schwer wird, einen Teil der Codebasis zu ändern, ohne einen anderen Teil zu brechen. Das ist Martin Fowlers Shotgun Surgery.

Ich werde nicht viel mehr über Wartbarkeit sagen. Es gibt eine Reihe von Büchern, die du darüber lesen kannst:

• John Ousterhouts A Philosophy of Software Design
• Robert C. Martins Clean Code
• Martin Fowlers Refactoring

Also, warum können Modelle keine Software-Wartbarkeit?

„Aber sicherlich sind die Modelle seitdem besser geworden“

An diesem Punkt möchtest du vielleicht sterbend sagen: aber Dex, sicherlich sind die Modelle seit Juli viel besser geworden

Das sind sie – in mancher Hinsicht. In anderer Hinsicht sind sie ungefähr gleich.

• Einmalige Probleme lösen oder eine neue Marketing-Seite mit Vibe-Coding bauen? Ja. Viel besser.
• Codequalität im Laufe der Zeit verbessern? Nicht viel besser, soweit ich das beurteilen kann.

Ich kann das nicht beweisen. Du kannst es auch nicht beweisen. Es gibt keine guten Benchmarks für die Fähigkeit eines Modells, Codequalität aufrechtzuerhalten. (Mehr dazu, wo das hinführt, später.)

ES GIBT KEINE GUTEN BENCHMARKS für die Fähigkeit eines Modells, Codequalität aufrechtzuerhalten

Aber wenn du eine Weile mit Coding-Agenten gearbeitet hast – und viele Leute posten genau darüber –, hast du wahrscheinlich schon das Gefühl: Sie neigen dazu, die Dinge im Laufe der Zeit zu verschlechtern und die Arbeit in der Codebasis zu erschweren.

Also, um herauszufinden, warum das passiert, möchte ich zum ersten großartigen Coding-Agenten zoomen.

Claude Code hat gewonnen, weil Reinforcement Learning im Harness stattfand

Claude Code ging von null auf ~4 Milliarden Dollar – jetzt etwa ~9 Milliarden Dollar – Umsatz in weniger als einem Jahr.

Was ein bisschen verrückt ist, denn es gab bereits großartige CLI-Agenten. aider, cline, codebuff – alle älter als Claude Code, alle mit wirklich großartigem Context Engineering, alle mit dem gleichen Tool-Set, das du Claude Code zuschreiben könntest: read, write, edit, grep, bash. Ich habe sie benutzt. Sie waren gut. Aber auch, die Tool-Nutzung würde einfach manchmal... fehlschlagen – du hast zugesehen, wie es dreimal an derselben Bearbeitung gescheitert ist und deinen Editor wieder geöffnet, um es selbst zu machen.

Das SWE-Agent-Paper von 2024 skizziert, wie kleine Änderungen in der Tool-Form spürbare Unterschiede machen, z.B. das Einfügen von Zeilennummern in ReadFile-Ergebnissen oder das Ändern eines Edit-Tools von Find/Replace zu Zeilenbereichs-Edits.

Dann startete Claude Code und ging ziemlich schnell vertikal. Du kannst das als Distribution abtun, aber die kanonisch akzeptierte Erklärung ist, dass Claude Code gewonnen hat, weil es besser war, und dass es besser war, weil Anthropic das Modell im Harness durch RL trainiert hat – das erste Mal, dass ein Labor ein Modell mit den exakten Tools trainiert hat, die sie ausliefern wollten. Und es wurde wirklich, wirklich gut darin, diese Tools in einer agentischen Schleife zu verwenden.

Es ist eine Sache, an Tool-Definitionen und Evals herumzubasteln, bis du die Form findest, die dem Modell am besten gefällt – ich habe Wochen damit verbracht, das für verschiedene Anwendungsfälle zu tun. Es ist ein anderes Spiel, wenn du die Gewichte besitzt und das Modell selbst ändern kannst, um bei einem bestimmten Satz von Tools besser zu sein.

Das OpenAI-Team hat im November einen Talk gehalten, der das ziemlich gut auf den Punkt brachte: Wenn du ein Harness baust, aber nicht die Gewichte besitzt und das Modell nicht darin durch RL trainieren kannst, wirst du immer im Nachteil gegenüber einem Team sein, das beides besitzt.

Coding-Agent-RL in 60 Sekunden

Ich habe zu diesem Thema eine Menge recherchiert und eine Reihe von Visualisierungen erstellt, um die relevanten Teile zu erklären, aber ich fand, dass Calvin French-Owen (MTS im Codex-Team, Gründer von Segment) einen Talk bei AI Council gehalten hat, der das viel besser und sauberer gemacht hat, also werde ich hier einfach diese Animation zeigen, inspiriert von seinen Folien:

Um ein Modell besser im Programmieren zu machen, wirst du:

1. einige Coding-Agent-Traces generieren, um ein Problem zu lösen (z.B. meine Tests reparieren)
2. die Traces basierend auf bestimmten Kriterien bewerten (Verifier)
3. die Modellgewichte aktualisieren, um die guten Traces wahrscheinlicher und die schlechten Traces unwahrscheinlicher zu machen

Und dann machst du das Millionen Mal über Wochen oder Monate.

Der „Bewertungs“-Teil dieser Dinge kann jedoch dazu neigen, launisch eindimensional zu sein.

Es gibt keine Strafe für schlechtes Design

Nimm SWE-bench Multilingual. Die Aufgaben sind klein – etwa fünfzehn Minuten Arbeit pro Stück – aus Open-Source-Repos wie Redis, jq und Django herausgekratzt. Die Belohnung ist eins oder null basierend auf:

• FAIL_TO_PASS – hast du das Problem behoben, das behoben werden sollte?
• PASS_TO_PASS – hast du es getan, ohne etwas anderes zu kaputt zu machen?

Hier ist ein echtes Beispiel, fastlane__fastlane-19304, aus fastlane – ein Ruby-Projekt. Seine zip-Aktion greift sich zwei optionale Parameter und ruft sofort .empty? darauf auf, also sobald du include und exclude weglässt, fällt es um:

Der menschliche Fix, der dieses spezielle Problem geschlossen hat, sind zwei Zeilen (Standard-Nils auf leere Arrays setzen):

Während der Evaluierung

1. startet das Modell von einem Basis-Commit – das Repo ausgecheckt auf den Moment kurz bevor der Fix landete
2. der Bug-Report – in diesem Fall „zip_command': undefined method 'empty?' for nil:NilClass“

Der Agent geht los und schreibt basierend auf dem Issue etwas Code. Er sieht weder den goldenen Patch noch den Test-Patch, der als Bewertungsgrundlage dient:

Dann:

1. Wir behalten den Patch, den es produziert hat, und
2. verwerfen alle Änderungen, die es an den Testdateien vorgenommen hat (wir haben ein Modell erwischt, das leise den fehlschlagenden Test auskommentiert oder einen Mock eingefügt hat, der den Test nutzlos macht)
3. Wenden den Test-Patch des Benchmarks darüber an, und
4. führen die gesamte Suite aus: die bestehenden zip-Tests (PASS_TO_PASS) plus den neuen (FAIL_TO_PASS), um zu sehen, ob beide bestehen

Exkurs – Benchmarks sind keine Verifier – tatsächlich müssen sie voneinander ferngehalten werden (nicht auf Test trainieren, etc.) – ich meine damit hauptsächlich, die Form von „Qualität eines Coding-Agent-Traces beurteilen“ und ihre Grenzen zu vermitteln.

Wie das Modell zu einer korrekten Antwort gekommen ist, spielt keine Rolle. Wenn die Tests bestehen, haben wir gewonnen, aber es gibt keine Strafe für die Verschlechterung der Code-Wartbarkeit.

Es gibt keine Strafe für die Verschlechterung der Code-Wartbarkeit

So bekommst du try-catches um alles herum:

Qualität zu verifizieren ist um Größenordnungen schwieriger als „haben die Tests bestanden“

Die Tests laufen zu lassen, gibt dir in ~Sekunden ein klares Bestehen oder Nichtbestehen. Deshalb kann RL Millionen von Loops durchlaufen, um jede Modellgeneration zu optimieren.

Aber die Kostenfunktion schlechter Architektur wird in Wochen, Monaten, vielleicht sogar Jahren gemessen. Sie tritt auf, wenn jemand zum ersten Mal diese Datei für eine einzeilige Änderung öffnet und feststellt, dass er sie nicht in einer Zeile machen kann – dass jemand hier ein bisschen zu hart gevibed hat, und jetzt müssen wir dieselbe Bearbeitung an elf Stellen vornehmen und hoffen, dass nichts leise drei Dateien weiter kaputtgeht.

Tests geben dir Feedback in Sekunden, aber die Kostenfunktion schlechter Architektur wird in Wochen, Monaten, vielleicht sogar Jahren gemessen

Schlechtes Design ist das eine, das heutige Benchmarks nicht bewerten können. Und ich weiß, ich weiß, RL != Benchmarks, aber wenn das in RL gelöst wäre, wäre ich ziemlich sicher, dass es sich auch in der Gestaltung unserer Benchmarks zeigen würde.

Auf jeden Fall vertraue ich persönlich keinen Verbesserungen bei heutigen Benchmarks als Indikator dafür, dass die Modelle plötzlich gut darin sind, deine Codebasis nicht vollzuschlodern.

Die Grenze wird besser, langsam

Natürlich arbeiten viele kluge Leute daran. Mein Punkt ist nicht, dass es nicht machbar ist, sondern dass der Hype schneller läuft als die Disziplin.

Ein paar Bemühungen, die meiner Meinung nach in die richtige Richtung gehen:

• SWE-Marathon (Abundant AI): ~400-Stunden-Aufgaben wie „klone ganz Excel, jedes Feature“ – mit einem zusammengesetzten Belohnungskanal anstelle eines einzelnen Bestehen/Nichtbestehen-Bits
• DeepSWE (Datacurve): große Aufgaben in OSS-Repos, die nie wirklich in der realen Welt gebaut wurden, also per Konstruktion nicht bereits im Trainingssatz sein können (löst Kontamination, aber nicht Qualität)
• Frontier Code (Cognition): Multi-PR-Aufgaben und ein kluger Schachzug, der Qualität deterministisch bewertet – es bestraft das Modell dafür, Tests zu schreiben, die nicht im Vor-Patch-Code fehlschlagen (wenn du noch nie von Mutation Testing gehört hast, erwartet dich eine lustige Reise5). Es lässt auch ein Judge-Modell über den Diff laufen, das Code-Qualitätsregeln überprüft.

Aber ein Modell, das Qualität beurteilt, kann nur begrenzt viel.

Es ist eigentlich gar nicht so schwer, sich vorzustellen, dass ein Modell, wenn es zuverlässig guten von schlechtem Code unterscheiden könnte, vielleicht gleich die gute Version geschrieben hätte. RL braucht ein schnelles und zuverlässiges Orakel, und für Wartbarkeit haben wir noch keins.

Wenn ein Modell zuverlässig guten von schlechtem Code unterscheiden könnte, hätte es vielleicht gleich die gute Version geschrieben, aber für Wartbarkeit gibt es kein schnelles Orakel, also können wir sie während RL nicht belohnen.

Natürlich helfen mehr Review-Agenten und mehr Token – sie heben die untere Messlatte an, indem sie die dummen Fehler abfangen.

Aber sie verschieben die obere Grenze nicht, denn die obere Grenze ist das, was wir dem Modell in RL beigebracht haben, und gutes Design ist das, was wir ihm noch nicht beibringen können.

Deshalb würde ich meine Codebasis immer noch nicht auf eine dieser Methoden setzen. Aber es sind die ersten Evaluierungen, die ich gesehen habe, die überhaupt versuchen, Wartbarkeit zu bewerten, anstatt bei Bestehen/Nichtbestehen stehen zu bleiben.

Nebenbei Vielleicht bekommt ein zukünftiges Modell das einfach hin und wir können aufhören. Wenn du so lange Prompts ins Blaue schießen willst, bis GPT-7 ausgeliefert wird, und es dann herausfinden willst, bitte – aber die Bitter Lesson hin oder her, wir haben jetzt Probleme zu lösen, und ich werde durchgehen, wie wir das machen.

Das Licht wieder anschalten

Heute habe ich gelernt, dass Twitter-Artikel ein „Medienlimit“ haben, was bedeutet, dass der Rest in einem Teil-II-Beitrag landet – bleibt dran.