Warum Software-Fabriken scheitern: Harness Engineering allein reicht nicht

 (github.com/humanlayer)
1 Punkte von GN⁺ 2 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Eine lights-off Software Factory ohne Menschen, die Code lesen oder schreiben, erhöht zwar die Generierungsgeschwindigkeit, entfernt aber auch die Menschen, die langfristige Wartbarkeit beurteilen können – und ist deshalb in komplexen Produktions-Codebases schwer praktikabel
  • Reinforcement Learning für Coding-Modelle optimiert auf schnelle, eindeutige Belohnungen wie bestandene Tests und kann Kosten schlechten Designs, die erst Monate später sichtbar werden, nicht bestrafen
  • SWE-bench-ähnliche Benchmarks bewerten Bugfixes und den Erhalt bestehender Tests, filtern aber keine Änderungen, die die Codequalität schleichend verschlechtern, etwa wahllose try/catch-Blöcke, Type Casts oder Shotgun Surgery
  • Derzeit müssen Menschen Code Reviews übernehmen und Produktanforderungen, Systemarchitektur, Programmdesign und Vertical Slices vor der Implementierung prüfen, um Nacharbeit und Reviews großer Mengen KI-generierten Codes zu reduzieren
  • Wer die Grenzen der Modelle akzeptiert, kann statt überzogener 10- bis 100-facher Automatisierung mit nahezu menschlicher Qualität 2- bis 3-mal schneller entwickeln; zentrale Entscheidungen und das Lesen von Code lassen sich noch nicht auslagern

Versprechen und Realität schleifenorientierter Software-Fabriken

  • Im Wettlauf um den Produktionseinsatz von KI-Coding verbreitet sich die Vorstellung, man müsse nur mehr Harnesses und Agent-Loops hinzufügen
  • Dieser Ansatz beruht auf der Annahme, dass Menschen der Engpass sind, Modelle gut genug sind und die Kosten der Codegenerierung praktisch niedrig sind – man müsse also einfach mehr ausliefern
  • Ziel ist es, 10- bis 100-fache Geschwindigkeit, hohe Qualität und den Wegfall menschlicher Code Reviews gleichzeitig zu erreichen
    • Man geht davon aus, dass Software sich selbst sicher machen kann, wenn man mehr Linter konfiguriert und PR-Review-Bots zu adversarial Reviews anweist
  • In der Praxis zeigen sich Fälle, in denen Fehler von Coding Agents Ausfälle verursachen und Codebases schnell zerfallen
  • Der Bericht von Faros AI beobachtete nach der Einführung von KI-Coding-Tools folgende Veränderungen
    • Zahl und Länge von Review-Kommentaren nahmen zu, zugleich wurden aber auch mehr PRs ohne Review gemergt
    • Incidents und Bugs pro Entwickler nahmen zu
    • Dabei handelt es sich allerdings eher um Korrelationssignale als um nachgewiesene Kausalität
  • Belastbare Daten zu den Ergebnissen von StrongDM sind schwer zu finden; auch öffentliche Updates zwischen Februar und Juni waren eher selten

Komplexe Codebases sind ein anderes Problem als Vibe Coding

  • Ein Nebenprojekt, das nur wenige nutzen, und ein Team, das ein zehn Jahre altes Enterprise-System wartet, teilen kaum dieselben Einschränkungen
  • Diskutiert werden nicht Vibe Coding an sich, sondern die schwierigen Probleme komplexer Codebases und Wartung in Produktion
  • Früher meinte Brownfield alte Java-Systeme und Ähnliches; durch das hohe Entwicklungstempo können aber auch von Agents erzeugte Codebases nach etwa 3 bis 6 Monaten schwer änderbar werden
  • Wenn Ergebnisse schlecht sind, lautet ein häufiger Rat, es liege an zu wenigen Tokens oder mangelnder Technik; das Kernproblem liegt jedoch weniger im Harness als in der Art, wie Modelle trainiert werden

Die Evolution der Software Factory

  • Von 1968 bis vor dem KI-Einsatz

    • Der Begriff „Software Factory“ reicht zurück bis zur NATO-Konferenz 1968, auf der auch der Ausdruck „Software Engineering“ aufkam
    • Eine typische Factory um 2022 hatte folgenden Kreislauf
      • Menschen entscheiden, was gebaut werden soll, und tragen es in Tracker wie Linear oder Jira ein
      • Die zuständige Person implementiert und testet
      • Automatisierte Checks und menschliche Code Reviews folgen; bei Problemen geht es zurück zur Implementierung
      • Nach dem Deployment in Produktion wird überwacht, und Incidents sowie Nutzerfeedback fließen zurück in den Tracker
    • Da Implementierung und Review jeweils Stunden oder Tage dauern können, stellen Teams Planung, Architekturvorschläge und Sprint Planning voran, um zuerst Konsens zu schaffen
    • Einigkeit vor der Implementierung reduziert Nacharbeit, und ein ausgereifter PR, der der beschlossenen Richtung entspricht, lässt sich schnell prüfen, selbst wenn man jede Zeile liest

  • Agentische Factory

    • Ramp, Stripe, WorkOS, Brex und andere berichten, dass Agent Factories etwa 75 % des Codes ausliefern
    • In der bestehenden Factory wird der Schritt, in dem Menschen implementieren, durch Agents ersetzt; dazu werden Orchestrierung, Harnesses, Sandboxes, Modelle und Computer Use kombiniert
    • Die Implementierungszeit sinkt von Stunden oder Tagen auf Minuten oder Stunden, doch menschliches Codelesen und Testen bleiben bestehen, sodass Review zum Engpass wird
    • Um diesen Engpass zu verringern, werden mehrere Loops ergänzt
      • Agent-Code-Reviews auf Stil, Bugs und Sicherheit
      • Regressionstests, die mithilfe von Browser- und Computer-Use externes Verhalten prüfen
      • Abläufe, die Incidents automatisch mit PRs verknüpfen, sodass Verantwortliche Fix-Kandidaten erhalten
      • Abläufe, die Nutzerfeedback direkt in die Arbeitsqueue leiten
    • Am Ende reduziert sich das operative Problem darauf, wie viel man in die Arbeitsqueue legen kann und wie schnell Ergebnisse geprüft und getestet werden können

  • Lights-off Factory

    • Die von Dan Shapiro benannte lights-off Factory entfernt den Schritt, in dem Menschen jede Änderung lesen
    • Statt in Code Reviews wird in folgende Bereiche investiert
      • Selbsttests von Agents
      • Sandboxes und Orchestrierung
      • Automatisierte Reviews und Monitoring
      • Schrittweise Releases und Sammlung von Nutzerfeedback-Signalen
    • Wenn menschliches Urteil entfernt wird, bleibt nur noch die Frage, wie viele Aufgaben man Agents geben kann; in komplexen Produktions-Codebases funktioniert dieser Ansatz jedoch nicht

Scheitern eines selbst angewandten lights-off-Ansatzes

  • Ab Juli 2025 wurde ein vollständig lights-off Ansatz eingesetzt, bei dem kleine und mittlere Aufgaben allein anhand von Spezifikationen und Tickets an Background Agents übergeben wurden
  • Nach einigen Monaten traten komplexe Probleme auf, die sich auch mit fortgeschrittenen Prompts und Workflows nicht lösen ließen
    • Der nötige Kontext wurde gesammelt und dem Modell bereitgestellt
    • Der Agent versuchte auf etwa zehn Arten, das Problem zu reproduzieren
    • Am Ende musste ein Mensch direkt in eine Codebase einsteigen, die drei Monate lang nicht gelesen worden war, und die Ursache finden
  • In dieser Zeit fiel die Website aus, Nutzer hatten Probleme, und Menschen mussten angesammelten minderwertigen Code lesen
  • Beim ersten Fehlschlag erschien es noch vertretbar, für Geschwindigkeit Risiken einzugehen; als etwa im November das dritte Problem auftrat, war es einfacher, von vorn neu zu schreiben
    • Ein Mitgründer implementierte die Patterns zwei Wochen lang direkt in VS Code neu

Warum Modelle die Qualität von Codebases verschlechtern

  • Aktuelle Modelle können die Qualität einer Codebase ohne erhebliche menschliche Steuerung langfristig weder erhalten noch verbessern
  • Wartbarkeit bedeutet hier die Fähigkeit, Zustände wie Shotgun Surgery zu vermeiden, bei denen eine Änderung an einer Stelle andere Teile kaputtmacht und dieselbe Änderung an mehreren Stellen vorgenommen werden muss
  • Modelle haben bei Einmal-Problemlösungen oder beim Erstellen neuer Marketing-Websites große Fortschritte gemacht, doch ihre Fähigkeit, Codequalität über die Zeit zu verbessern, scheint sich nicht eindeutig verbessert zu haben
  • Da es keinen guten Benchmark für Wartbarkeit gibt, ist es auch schwer, diesen Unterschied zu belegen oder zu widerlegen
  • Selbst wenn Modelle wie GPT-5.5 xhigh hervorragende Refactorings durchführen: Wenn Menschen die Codebase verstehen und die nötige Arbeit konkret anweisen müssen, ist das Problem der lights-off Factory nicht gelöst

Claude Code und Reinforcement Learning innerhalb des Harness

  • Schon vor Claude Code boten CLI-Agents wie aider, cline und codebuff Lese-, Schreib-, Editier-, Such- und Shell-Tools sowie Context Engineering
  • Frühere Agents hatten teils nicht genug Stabilität bei der Tool-Nutzung, etwa wenn sie wiederholt an derselben Änderung scheiterten
  • Das SWE-Agent-Paper analysiert, dass schon kleine Unterschiede im Tool-Design die Leistung beeinflussen, etwa Zeilennummern in ReadFile-Ergebnissen oder Editieren per Zeilenbereich statt per Suchen/Ersetzen
  • Als zentraler Grund für das schnelle Wachstum von Claude Code gilt, dass Anthropic das Modell per Reinforcement Learning innerhalb des tatsächlich auszuliefernden Harness trainierte
    • Die Gewichte wurden so angepasst, dass das Modell genau dieses Toolset innerhalb der Agent Loop aufruft
    • Anders als externe Entwickler, die Tool-Definitionen und Evaluierungen an Modellpräferenzen anpassen, kann der Model Owner das Modell selbst an die Tools anpassen
  • Teams, die sowohl Harness als auch Modellgewichte besitzen, sind im Vorteil gegenüber Teams, die nur den Harness bauen und die Gewichte nicht anpassen können

Grenzen der Belohnungen beim Reinforcement Learning von Coding Agents

  • Reinforcement Learning für Coding-Modelle wiederholt im Wesentlichen millionenfach folgenden Ablauf
    1. Für eine Aufgabe wie das Fixen von Tests wird eine Ausführungsspur des Agents erzeugt
    2. Ein Validator bewertet die Ausführungsspur
    3. Die Modellgewichte werden so aktualisiert, dass die Wahrscheinlichkeit guter Ausführungsspuren steigt und die schlechter sinkt
  • Das Problem ist, dass die Bewertung zu eindimensional sein kann

  • Beispiel SWE-bench Multilingual

    • SWE-bench Multilingual nutzt etwa 15-minütige Aufgaben aus Open-Source-Repositories wie Redis, jq und Django
    • Die Belohnung ist 0 oder 1 und prüft zwei Bedingungen
      • FAIL_TO_PASS: Wurde das angeforderte Problem behoben?
      • PASS_TO_PASS: Wurde bestehendes Verhalten nicht beschädigt?
    • Die Aufgabe fastlane__fastlane-19304 betrifft einen Bug, bei dem bei fehlenden optionalen Parametern include und exclude .empty? auf nil aufgerufen wird
    • Der tatsächliche menschliche Fix war eine Änderung von zwei Zeilen, die nil standardmäßig auf leere Arrays setzte
    • Das Modell erhält nur den Basis-Commit direkt vor dem Fix und den Bug Report, nicht aber den Lösungspatch oder den Testpatch zur Bewertung
    • Die Bewertung läuft in folgender Reihenfolge ab
      1. Der vom Modell erstellte Patch wird beibehalten
      2. Änderungen des Modells an Testdateien werden entfernt
      3. Der private Testpatch des Benchmarks wird angewendet
      4. Bestehende und neue Tests werden gemeinsam ausgeführt
    • Teständerungen werden verworfen, weil Modelle sonst fehlschlagende Tests auskommentieren oder bedeutungslose Mocks einbauen können, um zu bestehen
    • Benchmark und Reinforcement-Learning-Validator sind nicht identisch und sollten getrennt sein, doch beide zeigen dieselbe strukturelle Grenze beim Bewerten der Qualität von Coding-Ausführungsspuren

  • Keine Strafe für Designverschlechterung

    • Wenn die Tests bestehen, gehen Lösungsweg und strukturelle Qualität nicht in die Bewertung ein
    • Auch das Einwickeln aller Stellen in try/catch oder lose Type Casts, die die Vorteile des Typsystems untergraben, können als richtige Lösung gelten
    • Beschädigte Wartbarkeit wird nicht bestraft, solange bestehende und neue Tests bestehen

Qualitätsprüfung ist schwieriger als bestandene Tests

  • Tests liefern innerhalb von Sekunden klare Erfolgs- oder Fehlschlag-Signale, sodass Reinforcement Learning millionenfach wiederholt werden kann
  • Die Kosten schlechter Architektur zeigen sich erst nach Wochen, Monaten oder Jahren, wenn kleine Änderungen an mehreren Stellen nötig werden
  • Aktuelle Benchmarks können solche langfristigen Designkosten nicht bewerten
  • Reinforcement Learning und Benchmarks sind nicht dasselbe; wäre Wartbarkeit im Reinforcement Learning gelöst, würde sich diese Fähigkeit aber wahrscheinlich auch im Benchmark-Design zeigen
  • Daher lässt sich aus besseren Benchmark-Scores nicht ableiten, dass Modelle Codebases nicht mehr verschmutzen

Neue Versuche, Wartbarkeit zu bewerten

  • Die Frontier der Modellqualität verbessert sich, doch Erwartungen und Marketing eilen technischer Disziplin voraus
  • Beispiele, die sich an wartbarkeitsnähere Bewertungen herantasten, sind
    • SWE-Marathon: nutzt Aufgaben im Umfang von etwa 400 Stunden, etwa die Nachbildung aller Excel-Funktionen, und mehrere Belohnungskanäle statt eines einzelnen Erfolgs-/Fehlschlag-Signals
    • DeepSWE: nutzt große Open-Source-Aufgaben, die in der Realität nicht implementiert wurden, um Kontamination der Trainingsdaten zu reduzieren; das Qualitätsproblem selbst löst es aber nicht
    • Frontier Code: bewertet Aufgaben über mehrere PRs hinweg und bestraft Tests, die auch im Code vor dem Patch nicht fehlschlagen
      • Die Wirksamkeit von Tests wird ähnlich wie bei Mutation Testing deterministisch geprüft
      • Zusätzlich läuft ein Judge-Modell, das Diffs anhand von Codequalitätsregeln prüft
  • Eine Grenze bleibt: Wenn ein Judge-Modell Qualität zuverlässig unterscheiden kann, hätte es möglicherweise von Anfang an guten Code erzeugen können
  • Reinforcement Learning braucht ein schnelles, verlässliches Oracle, doch für Wartbarkeit gibt es ein solches Oracle nicht
  • Review Agents und zusätzliche Tokens können offensichtliche Fehler finden und die Mindestqualität anheben, heben die Spitzenqualität aber nicht über das hinaus, was dem Modell per Reinforcement Learning beigebracht wurde
  • SWE-Marathon, DeepSWE und Frontier Code sind frühe Versuche, Wartbarkeit über reine Erfolgs-/Fehlschlag-Urteile hinaus zu bewerten, reichen aber noch nicht aus, um ihnen eine ganze Codebase anzuvertrauen

Menschen in vier Schritten zurück in die Loop holen

  • Da derzeit Menschen die zuverlässigen Qualitätsrichter sind, müssen Code Reviews wiederhergestellt werden
  • Vorabplanung, wie sie schon vor KI genutzt wurde, reduziert lange Reviews und mögliche Nacharbeit
  • Der Hebel von KI wird in vier Phasen genutzt: Produktanforderungen, Systemarchitektur, Programmdesign und Vertical Slices

  • 1. Produkt-Review

    • Kurze Sätze oder lange Sprachnotizen werden in halbstrukturierte Dokumente verwandelt, die festhalten, was warum gebaut wird
    • Zuerst wird in der Sprache der Nutzer das zu lösende Problem definiert, anschließend die Kriterien, nach denen nach dem Release Erfolg beurteilt wird
      • Verkürzung der Ausführungszeit eines Workflows
      • Früheres Erreichen von Onboarding-Meilensteinen
      • Verbesserung von Fehlerrate oder Latenz
      • Reduzierung bestimmter Support-Tickets
    • Der Fokus liegt auf der User Experience statt auf technischen Details; wenn technische Entscheidungen Produktentscheidungen blockieren, wird das aktuelle Dokument gespeichert und in Architektur-Review oder Machbarkeitsprototyp gewechselt
    • Bildschirmverhalten lässt sich oft besser mit groben HTML-Mockups als mit langen Beschreibungen abstimmen
    • Für Textänderungen, einmalige Skripte und Bugs mit klaren Repro-Schritten wird dieses Verfahren nicht angewandt; sie gehen direkt an den Agent
    • Nur Änderungen, bei denen Missverständnisse des Agents teuer wären, werden einem Produkt-Review unterzogen
    • PR-Reviewer sollen auch Produkt- und technische Spezifikationen vorab prüfen; asynchrone Dokumentkommentare oder GitHub, Notion usw. können dafür genutzt werden

  • 2. Systemarchitektur

    • Abgestimmt wird, wie Services, Endpoints, Schemas, Queues und Stores miteinander kommunizieren, ohne bis in die interne Programmlogik hinabzugehen
    • Um die Kommunikationsbandbreite zwischen Menschen und Agents zu erhöhen, werden folgende Darstellungen genutzt
      • Sequenzdiagramme zwischen UI, API, Services und Stores
      • API Contracts, die Requests und Responses zeigen
      • Datenmodelle mit neuen Tabellen und Query-Formen
    • Mermaid ist nützlich, kann bei Übernutzung aber falsche Sicherheit erzeugen, dass tatsächlich Einigkeit erzielt wurde
    • Architektur-Reviews sind wirksam, um schlechte Modellgewohnheiten früh zu stoppen, reichen aber nicht aus, um hochwertigen Code zu garantieren

  • 3. Programmdesign

    • Vor der Implementierung wird eine Ebene unterhalb der Architektur die Form des Codes festgelegt
      • Typen
      • Methodensignaturen
      • Programmplatzierung
      • Call Stack
    • Leichte Pseudocode-Visualisierungen sind lesbarer als komplexe Mermaid-Diagramme
    • Für Änderungen an Orchestrierung oder Kontrollfluss werden Call-Stack-Bäume verwendet; wenn die geänderten Teile wichtig sind, kommt Diff-Syntax zum Einsatz
    • File-Tree-Diffs zeigen Position und Rolle neuer und geänderter Dateien
    • Typen und Methodensignaturen zentraler Funktionen werden vorab festgelegt, um die Wahrscheinlichkeit zu senken, dass der Agent das interne Design falsch wählt
    • Das Modell kann einen Entwurf erstellen und Menschen können ihn anpassen; Entscheidungen, die sonst implizit im Code Review fallen würden, werden damit auf einen günstigeren Zeitpunkt vorgezogen

  • 4. Vertical Slices

    • Modelle bevorzugen horizontale Pläne, die von Datenbankmigration über Service Layer und API bis zum Frontend schichtenweise aufbauen
    • Bei horizontalen Plänen ist es während der Arbeit schwer, die tatsächliche Lösung im Browser oder per curl anzufassen und zu prüfen
    • Entwickler vor KI schrieben selten 500 oder 2.000 Zeilen auf einmal, sondern arbeiteten sich von der Mitte nach außen vor und überprüften ständig
      1. API Contract und Mock-Daten erstellen und mit curl prüfen
      2. Mock-Daten im Frontend konsumieren und im Browser verfeinern
      3. API mit dem Service Layer verbinden
      4. Datenbankmigration und Store-Anbindung hinzufügen
      5. Businesslogik hinzufügen
      6. Fehlerbehandlung hinzufügen
    • Vertical Slices oder Tracer Bullets ermöglichen es, in jedem Schritt echtes Verhalten zu testen und zu verbessern
    • In Bereichen, in denen Qualität besonders wichtig ist, ist es günstiger, pro Schritt 100 bis 200 Zeilen zu prüfen und die Richtung neu zu justieren, als später mehr als 2.000 Zeilen zu korrigieren
    • Auch aktuelle Modelle tun sich schwer, solche Pläne ohne menschliche Steuerung zu erstellen, und die Generalisierung über Codebases und Aufgaben hinweg ist schwierig; Menschen müssen in der Loop bleiben

Anwendung je nach Aufgabengröße

  • 30 Minuten Vorabplanung können nach der Implementierung stundenlange Reviews ersparen
  • Um nahezu menschliche Qualität zu halten, müssen Menschen an Produktdesign, Systemarchitektur, Programmdesign und Vertical Slices beteiligt sein
  • Nicht jede Aufgabe durchläuft den gesamten Prozess
    • Etwa 40 % werden in einem Durchgang generiert oder mit ein bis zwei leichten Feedbackrunden abgeschlossen
    • Bei mittelgroßen Aufgaben werden Produkt- und Systemdesign in einem Planungsdokument kombiniert, ohne die Implementierung in Stufen aufzuteilen
    • Große Aufgaben durchlaufen alle vier Phasen; wenn Produkt-Review etwa bei großem Refactoring nicht passt, wird diese Phase ausgelassen
  • Üblicherweise werden dem Modell ein bis drei Slices auf einmal gegeben, während der entstehende Code geprüft wird
  • Interne Strukturen oder Funktionen früh zu korrigieren ist einfacher, als nach Massengenerierung herauszufinden, was schiefgelaufen ist

Der Engpass ist nicht die Zahl der PRs, sondern die PR-Qualität

  • Nicht zu viele PRs sind der Engpass, sondern zu viele schlechte PRs
  • Ein sauberer PR, der dem beschlossenen Design und den Konventionen des Teams folgt, lässt sich schnell prüfen, selbst wenn man jede Datei liest
  • Schon wenn nur 20 % der PRs Nacharbeit brauchen, entsteht für Einreichende und Reviewer kognitive und emotionale Belastung
  • Bei PRs, die KI in einem Durchgang erzeugt, liegt die Nacharbeitsquote häufig nahe bei 50 %
  • Auch wenn der Einreichende eine KI ist, muss jemand die Arbeit anstoßen und das Ergebnis verfeinern oder verantworten; die Kosten der Nacharbeit verschwinden also nicht

Entwicklungsgeschwindigkeit mit akzeptierten Einschränkungen

  • Die zentrale aktuelle Einschränkung ist, dass klar ist, was Modelle gut und schlecht können, und dass Menschen vorerst Code lesen müssen
  • Statt 10- bis 100-fache Geschwindigkeit zu jagen und anzunehmen, Codequalität sei unwichtig, kann man durch Optimierung innerhalb dieser Grenzen sicher 2- bis 3-fache Geschwindigkeit erreichen
  • Die praktischen Prinzipien sind vier
    1. Ausreichend mit Modellen arbeiten, um ein Gefühl für ihre Grenzen zu entwickeln
    2. Das Entwicklungssystem innerhalb dieser Grenzen optimieren
    3. Stellen mit hohem Hebel finden
    4. Den tatsächlichen Code lesen
  • Harnesses und Loops sind Werkzeuge, um offensichtliche Fehler zu reduzieren, ersetzen aber Wartbarkeitsurteil und Design Thinking nicht

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 시간 전
Hacker-News-Kommentare

  • Ich nenne das das Intent-Implementierungs-Qualitäts-Problem
    Softwarefabriken können mit einer einzeiligen Anforderung Apps, Features, Bugfixes, Designänderungen und Refactorings umsetzen, aber ob sie auch die menschliche Absicht hinter dieser Anforderung und die Entwicklungsrichtung des Produkts korrekt hervorbringen können, ist eine andere Frage
    Die Zahl der möglichen Implementierungswege explodiert kombinatorisch, und der „richtige“ Weg, der zum System passt, konsistent, skalierbar, leicht verständlich ist und Millionen Nutzer sicher unterstützt, ist je nach Mensch und Problem subjektiv. Mit Tests und Arbeitsnachweisen lässt sich ein Teil der Qualität verbessern, aber es gibt keine Feedback-Schleife, um diese subjektive Qualität zu validieren und zu korrigieren

    • Selbst wenn der Kunde sagt, er wolle „X“, will er vielleicht in Wirklichkeit X gar nicht, braucht X nicht oder will eigentlich Y, kann das aber nur nicht ausdrücken. Andere Kunden wollen X vielleicht nicht, oder sie treiben Entwickler auch einfach ohne besonderen Grund vor sich her
    • Für Einzel- und Hobby-Software mit kaum Nutzern und Umsatz, bei der sich Bugs mit einem einzigen Claude-Prompt beheben lassen, oder für Startups vor dem Product-Market-Fit eignen sich Softwarefabriken gut
      Es ist auch ein Gleichgewicht möglich, bei dem man den Code überhaupt nicht ansieht und nur den Erfolg der Anforderung als Feedback nutzt, aber bei anderer Software sind die Probleme von Intent und subjektiver Qualität noch nicht gelöst
    • Schon die Annahme, dass es nur einen einzigen Weg gibt, Anforderungen in Implementierung zu übersetzen, ist nicht richtig

  • Der Artikel enthält gute Punkte, aber es ist schwer, ein autonomes Betriebs-Experiment im Juli 2025 auf die aktuellen Grenzen von Agenten zu verallgemeinern
    Die Nützlichkeit der Modelle machte im Herbst 2025 oder Frühjahr 2026 etwa einen großen Sprung, und auch ich konnte Agenten erst seitdem komplette Features anvertrauen. Der Artikel erwähnt Modellverbesserungen, ignoriert sie faktisch aber, und das passt nicht zu meinem Eindruck

    • Sowohl der Artikel als auch die Produktwebsite scheinen im Jahr 2025 stehen geblieben zu sein. Besonders der Text „langer Kontext ist nicht die Antwort“ wirkt, als würde er frühere Leistung einfach auf aktuelle Modelle extrapolieren
      Modelle seit Opus 4.6 waren selbst bei 700.000 bis 900.000 Tokens so stabil, dass kaum ein Intelligenzverlust spürbar war; kosteneffizient ist das zwar überhaupt nicht, aber es funktioniert
    • Letzte Woche habe ich einen Podcast gehört, in dem Dex Horthy zu Gast war, und seine Firma Humanlayer verschiebt die Grenzen von Agenten offenbar weiter und setzt sie offensiv ein
      Da er die Fähigkeiten aktueller Modelle gut kennt, würde er es wohl erneut versuchen, wenn er entschieden hätte, dass eine autonome Softwarefabrik heute möglich ist
    • Opus 4.5 war definitiv ein großer Sprung. Bewertungen von Leuten, die spätere Modelle nicht ausprobiert haben, sind weniger wert, aber auch unvollkommene Modelle sind sehr nützlich
    • Dann wäre es klarer gewesen zu schreiben: „Wir haben es 2025 flächendeckend eingeführt, und auch 2026 hat sich im Kern nichts verbessert“
      Ich glaube, selbst aktuelle Frontier-Modelle können Kontextverlust oder Shotgun Surgery nicht wesentlich besser handhaben. Wer widersprechen will, sollte das nicht einfach abtun, sondern konkrete Belege und andere Nutzungserfahrungen vorlegen
    • Das mag kontrovers sein, aber bei komplexem Engineering hatte ich das Gefühl, dass Opus 4.1 schlauer war als 4.5
      4.5 war schneller und besser darin, mit einfachen Prompts und impliziter Absicht umzugehen, was für die schnelle Gewinnung neuer Nutzer vorteilhaft war

  • Ich habe meine Softwarefabrik 8 Monate lang aufgebaut und betrieben; automatische Aufgabenerfassung und PR-Einreichung gibt es noch nicht, aber nachdem die Anforderungen festgelegt sind, läuft der Großteil bis zum Deployment selbstständig. Nach einer Systemevaluierung habe ich in den letzten 4 Monaten aufgehört, Code-Reviews zu machen
    Statt eines Einzeilen-Prompts kläre ich in einem Interviewprozess offene Fragen und Unklarheiten zuerst, und ich nutze Plan-Reviews, browserbasierte Qualitätssicherung, adversariale Reviews, Unit-Tests, Linter, Type Checker, Post-Commit-Hooks und das Nachverfolgen formaler Methoden als Schutzmechanismen
    Wenn sich wiederholte Fehler zeigen, kann ich auch ohne in den Code zu schauen erkennen, wo Bereiche unordentlich geworden sind. Wenn die Anforderungen wachsen und sich Zustandsvariablen überlappen, refaktoriere ich auf einen einzigen Summentyp; wird es komplex, erstelle ich mit Quint ein formales Modell und Traces und führe diese als Unit-Tests aus
    Die Codebase besteht aus einem über ein Jahr alten Frontend und Backend. Agenten kopieren bestehende Muster einfach weiter, daher sind klare Prinzipien wichtig; beim Aufteilen neuer Systemgrenzen urteilen Sonnet-Modelle oft falsch, und Opus war besser

    • Es ist zwar keine vollständige Fabrik, aber ich habe bei mehreren reifen Vibe-Coding-Projekten ein ähnliches Gefühl gehabt
      Qualitätsverschlechterungen ließen sich meist erkennen, und ich hatte bisher noch keinen Fall, in dem ich das Problem nach dem Öffnen des Codes nicht mit einem Agenten bereinigen konnte. Ich habe auch keine Situation gesehen, in der ein durchschnittlicher Engineer die Verunreinigung einer Codebase nicht mehr rückgängig machen konnte
    • Mich interessiert nicht die Codefabrik selbst, sondern was damit gebaut wurde. Es braucht Ergebnisse, die zeigen, dass sich damit auch Produkte jenseits von AI-Coding-Tools bauen lassen
    • Wenn du die konkrete Konfiguration und den Workflow in Form eines langen Textes oder Repositories veröffentlichst, würde ich mir das gern ansehen

  • Man muss entweder verstehen, wie eine Codebase funktioniert, oder man muss es nicht
    Claude kann den Code zwar stellvertretend schreiben, aber nicht stellvertretend verstehen, und dieser Prozess läuft weiterhin mit menschlicher Geschwindigkeit ab. Es gibt Fälle, in denen man nicht alles verstehen muss, aber hier braucht es eine feinere Unterscheidung, und selbst wenn Claude perfekten Code schreibt, ändert das nichts

    • Claude kann Spaghetti-Codebases durchsuchen viel schneller als Menschen. Gerade das ist eher das Problem: Wenn man das Projektverständnis an Claude auslagert, kann man weiterarbeiten, selbst nachdem es für Menschen bereits unbenutzbar geworden ist
    • Statt Verständnis als binäre Frage zu sehen, kann man auch fragen, wie viel Verständnis nötig ist, um in einer bestimmten Codebase effektiv zu arbeiten
      Schon vor LLMs kannte niemand eine große Codebase vollständig, aber zumindest die eigenen PRs und den eigenen Verantwortungsbereich hat man meist verstanden
    • Meine Erfahrung ist das Gegenteil. Bei zwei großen Codebases, die ich größtenteils selbst geschrieben und auch konzeptionell entworfen hatte, hat Claude ein viel tieferes Verständnis entwickelt als ich, und inzwischen lässt er mich Dinge erklären, die ich vor langer Zeit vergessen hatte

  • Das ähnelt meiner eigenen Erfahrung so sehr, dass es beruhigend ist. Es erinnert mich an das in letzter Zeit oft erwähnte Geschmack und Urteilsvermögen
    Die Qualität einer Architektur hat möglicherweise keine objektiv richtige Antwort, ähnlich wie Mode; nachdem wir Vernunft und Rationalität an Maschinen abgegeben haben, müssen Menschen vielleicht Ästhetik lernen.
    Ohne die Erholung, die der Implementierungsprozess früher bot, muss man ständig zwischen nahezu gleichwertigen Optionen Abwägungen treffen, was ermüdet, und selbst bei Modellen auf dem Niveau von Fable oder GPT-5.6 ist Code-Review weiterhin nötig. Kleine Mängel merke ich mir und behebe sie gesammelt, sobald sich genug ähnliche Probleme angesammelt haben.
    Auch bei Agenten muss man wählen, ob man eng mit wenigen herausragenden Kräften zusammenarbeitet oder eine große Zahl von Unteragenten laufen lässt und automatisch die Spreu vom Weizen trennt. Mein Geschmack geht zu einem kleinen, hochgradig eingespielten Team, aber ob das die richtige Antwort ist, wird die Zeit zeigen.

    • Jake Nations sagte während seiner Zeit bei Netflix: „Schlechte Muster erkenne ich sofort, weil ich sie schon um 2 Uhr morgens debuggt habe.“
      Geschmack ist die hart erarbeitete Intuition, die man aus allen Antipatterns und Tretminen gewinnt, die man beim Entwickeln von Software selbst ausgelöst hat.
      https://www.youtube.com/watch?v=eIoohUmYpGI

  • Diese Person hat schon früher eingeräumt, mit erfundenen, unbegründeten Behauptungen Schaden angerichtet zu haben, und auch diesmal gibt es überhaupt keine Belege dafür, dass dieser Gedanke gut ist. Es braucht einen Grund, ihm wieder zu vertrauen.

    • Letztlich ist es nur eine lange Werbung für sein Produkt Humanlayer.

  • Das auffälligste Problem in der aktuellen Situation ist die User Experience bei PR-Reviews.
    Ich habe die PR-Ansicht von GitHub immer gehasst und deshalb Branches lokal heruntergeladen, um Diffs im $EDITOR anzusehen, aber inzwischen gibt es keinen Grund mehr, dass das noch so umständlich sein muss. Sogar Linear, kein Unternehmen für Code-Review, bietet mit einem kleinen Modell bessere Grundfunktionen als GitHub, indem es geänderte Dateien thematisch bündelt und mit Erläuterungen sowie einer Wichtigkeitsreihenfolge versieht.
    Ohne zusätzliche Arbeit für Reviewer oder Anfragende sinkt die kognitive Last deutlich, und auch Folgefunktionen wie Visualisierungen wären gut möglich. Ich frage mich, ob dieser Ansatz falsch ist oder ob es dafür verbreitete Alternativen gibt.
    https://linear.app/docs/diffs#guides

    • Die besten Teams machen keine PR-Reviews. Sie besprechen Design und Architektur gemeinsam während der Änderung, automatisieren Kleinigkeiten wie Linting und Formatting und halten sich mit vielen Tests und Prüfungen strikt an Regeln, die den Build nicht kaputt machen.
      Mit einem starken Rollback-Verfahren wird das PR-Gate dann zu einem überflüssigen Schritt, der keine nützlichen Probleme mehr findet, und Teammitglieder können direkt mergen.
    • Eine Policy, Code-Review als Integrationshürde zu verwenden, ist sinnlos. Mein Agent beantwortet Review-Anfragen in meinem Namen und reviewt auch selbst, und sogar Unternehmensrichtlinien, die menschliches Review erzwingen, lassen sich umgehen.
      Man muss Software reviewen, die tatsächlich läuft, und dafür braucht es ein System, das Änderungsvorschläge sofort vorführen kann. Code und Spezifikationen werden an Gewicht verlieren, und die Softwareproduktion der Zukunft wird eher Replit als GitHub ähneln.
    • PR-Reviews waren schon vor Agenten schwierig, aber jetzt ist es viel schlimmer, weil es sogar mehr PRs zum Reviewen gibt.
    • Das thematische Bündeln und Beschreiben von Dateiänderungen ist doch eigentlich Aufgabe von Commits, oder nicht?
    • Ich halte LLMs nicht für besonders gut darin, Wichtigkeit zu beurteilen oder Code zusammenzufassen.
      Ich habe den Tree-sitter-basierten Ansatz https://github.com/0x007BA7/codebook ausprobiert und mochte ihn. Für den Produktionseinsatz ist er noch nicht weit genug, aber es gibt Spielraum, einen ähnlichen Ansatz zu einem Produkt zu machen.

  • Gegenüber der Softwarefabrik habe ich gemischte Gefühle.
    Beim Kernprodukt ist der Umfang so groß, dass jede Änderung menschlichen Input braucht, aber leichte Refactorings, das Schreiben von Tests und die Automatisierung von UI-Änderungen funktionieren gut. Bei kleinen Experimenten dagegen war der resultierende Code zwar nichts Besonderes, zeigte aber Potenzial für spätere Erweiterung, und ich denke, man kann neue Strategien und Architekturen entwerfen, von Anfang an in der Annahme, dass Agenten sie schreiben werden.
    Ein öffentliches Experiment ganz ohne Eingriffe habe ich auf https://relentless.works/ dokumentiert. Einen Trading-Agenten beobachte ich ebenfalls ohne Eingriffe; er liegt etwa 3 % im Minus, hat aber nicht das ganze Geld verloren und kürzlich sogar neue Positionen eröffnet.
    Softwarefabriken wirken möglich, aber es braucht neue Konzepte, einen Wandel im Denken und die Geduld, auf AI zu warten.

  • Schon darin, was es überhaupt bedeutet, Software zu entwickeln, steckt ein grundlegendes Problem.
    Wenn man GitHub-Tickets einfach AI-Agenten zuweist und sich ausruht, werden sich Abstraktionen und indirekte Schichten wahrscheinlich immer weiter auftürmen. Während des Codens entstehen Perspektiven wie: „Was wäre, wenn wir hier Redis verwenden?“, „Die API liefert die benötigten Daten doch schon“, oder „Kunden ohne Aktivität im letzten Jahr lassen wir aus dem Bericht weg“ — und irgendwann muss ein Mensch das beurteilen.

    • Das hängt mit der in Agentic Coding leicht verlorengehenden Sicht zusammen, dass Programmieren Theorieaufbau ist.
      https://gwern.net/doc/cs/algorithm/1985-naur.pdf
    • Stimme voll zu. Gängige Workflows und Tool-Sammlungen für Coding-Agenten sind so gestaltet, dass sie beim Planen oder Schreiben von Code menschliche Einsichten und Intuition hervorlocken.
      Dazu gehören der Planungsmodus von Claude Code, mattpocock/skills, obra/superpowers und Abläufe wie Research-Plan-Implementierung.
    • Für Entwickler aus dem obersten 1 %, die so denken, mag das stimmen, aber verglichen mit den meisten Entwicklern, denen ich in Jahrzehnten begegnet bin, sind heutige Modelle besser als Menschen außerhalb der absoluten Spitzengruppe.
    • Maschinen bauen einem inzwischen sogar Dinge, die es noch gar nicht gibt, genau so, wie man sie anfordert. Wichtiger als vollständige Unbemanntheit ist die Fähigkeit, mit Informations-, Entscheidungs- und Kreativitätstheorie die richtigen Anweisungen zu geben.
      Das Gedächtnis von Modellen wird nicht so integriert, wie Menschen es im Schlaf in ihre Gewichte einschreiben; es ähnelt eher dem Überreichen von Notizen an jemanden, der sich nicht an gestern erinnert. Es wäre nicht überraschend, wenn ein System mit hoher Entropie einem Projekt im Lauf der Zeit noch mehr Entropie hinzufügt.
    • Das Problem „Die API gibt die benötigten Daten bereits zurück“ ist besonders groß. Ich habe mehrfach gesehen, wie Top-Modelle etwas, das sich mit einer einzigen Änderung in einem bestehenden Client lösen ließe, stattdessen mit riesigen Mengen an Code und Tokens lösen, indem sie alte Client-Server-Muster nachahmen.
      Solche Verschwendung ist in Vibe-Coding-Projekten allgegenwärtig, aber die Person, die den Prompt geschrieben hat, merkt das womöglich nicht. Es ist gut, wenn Tools jeden Tag Zeit sparen, aber Überimplementierung ist ein ernstes Problem.

  • Es ist lächerlich, bei der Diskussion über eine unbemannte Softwarefabrik Produktivität an PRs oder der Anzahl von Commits zu messen. In dieser Richtung müsste man Code-Einheiten bereits bos (bunch of shit) nennen.

    • Es wird der alte Fehler wiederholt, die Auslastung statt des gesamten Durchsatzes zu optimieren. Eli Goldratt hat dieses Problem schon seit den 1970er Jahren behandelt, und trotzdem wurde daraus noch immer nichts gelernt.
      https://en.wikipedia.org/wiki/The_Goal_(novel)
    • Wenn man dieses Konzept ernsthaft betreiben will, darf man weder Vanity-Metriken noch Unwissen über Code zulassen. Je mehr automatisiert wird, desto niedriger werden die Maßstäbe nicht, sondern desto höher; außerdem braucht es viel mehr Mathematik und Aufwand.
      Es ähnelt eher einem Tausch, bei dem man statt wie ein extremes Startup Kapital zu schonen mehrere Lebensjahre investiert