Ideen & Einblicke

AI-First-Entwicklung, Coding-Leitplanken und die Architektur der Entsorgbarkeit erkunden.

Den Bug zu beheben ist der einfache Teil. Herauszufinden, warum er existiert, ist das, was zählt.

Die meisten Teams beheben Defekte und machen weiter. Dieselben Defekte kommen zurück. So führen Sie Kausalanalyse innerhalb einer Fagan-Inspection durch, damit Sie denselben Bug nicht zweimal schreiben.

Jedes Team hat diesen einen Defekt, der immer wieder zurückkommt. Ein Off-by-one in der Paginierung. Ein fehlender Null-Check im Auth-Middleware. Ein Race…

Pull-Request-Reviews finden 15–30 % der Defekte. Die Daten sagen das seit 50 Jahren.

Mehrere Studien bei IBM, AT&T, HP und Microsoft bestätigen, dass informelle Code-Reviews etwa ein Viertel der Defekte finden. Hier ist, was die Daten tatsächlich sagen, warum die Zahl so niedrig ist und wie man das behebt.

Informelle Code-Reviews finden zwischen 15 und 30 Prozent der Defekte, die im überprüften Code vorhanden sind. Das ist keine Meinung. Es ist ein Befund, der…

Eine generische Checkliste findet nichts. Eine strukturierte findet 60 % der Defekte.

Die meisten Review-Checklisten sind kopiert-eingefügte Listen guter Absichten. Eine im Stil einer Fagan inspection strukturierte Checkliste wird aus tatsächlichen Defektdaten erstellt, auf bestimmte Artefakttypen zugeschnitten und während der individuellen Vorbereitung verwendet. So baut man eine, die funktioniert.

Wenn dein Team eine Code-Review-Checkliste hat, gibt es eine gute Chance, dass sie auf einer Wiki-Seite existiert, die niemand öffnet. Sie sagt wahrscheinlich…

Ein LLM kann Ihren Code vorab prüfen. Es kann aber nicht das Meeting leiten.

Fagan-Inspektionen benötigen vier bis sechs Personen und zwei Stunden, um 250 Zeilen zu reviewen. Ein LLM kann diese Kosten senken, indem es Vorbereitung und Checklisten-Überwachung übernimmt, aber es kann die menschlichen Rollen nicht ersetzen, die die teuersten Defekte finden.

Eine vollständige Fagan-Inspektion benötigt einen Moderator, einen Vorleser, zwei bis vier Inspektoren und den Autor. Das Team verbringt zwei Stunden damit,…

Fagan Inspections fanden 90 % der Defekte vor dem Testing. Dann haben wir aufgehört, sie durchzuführen.

Michael Fagans strukturierter Review-Prozess bei IBM erfasste fast alle Defekte, bevor sie den Compiler erreichten. Er verschlang aber auch 15–20 % des Gesamtprojektaufwands. Hier ist, warum die effektivste Review-Methode in der Softwaregeschichte verschwand und was Teams tatsächlich vermissen.

1976 veröffentlichte Michael Fagan einen Artikel im IBM Systems Journal, der einen Review-Prozess beschrieb, der so effektiv war, dass er zum Goldstandard für…

Dein bester Reviewer übersieht die meisten Defekte. Fagan hat es 1976 bei IBM gemessen.

Selbst Senior Engineers finden nur einen Bruchteil der Defekte in unstrukturiertem Review. Michael Fagans IBM-Forschung zeigte warum, und er baute einen strukturierten Inspection-Prozess, um das zu beheben.

Zwei Senior Engineers reviewen denselben Pull Request. Einer markiert einen fehlenden Null Check. Der andere entdeckt einen Race Condition im Cleanup-Path.…

Die meisten Code Reviews finden 20 % der Defekte. Fagan Inspections finden 90 %.

Informelles Code Review findet 15–30 % der Defekte. Fagan Inspections, ein strukturierter 50 Jahre alter Prozess, berichten konstant von 60–90 % Entfernungsraten. So funktionieren sie, warum Teams sie vermeiden, und wie man eine leichtgewichtige Version durchführt.

Die meisten Code Reviews finden zwischen 15 und 30 Prozent der Defekte, die sie finden sollten. Das ist keine Vermutung. IBM hat das in den 1970ern gemessen,…

AutoVerus verwandelt 40 Stunden Proof-Writing in 3 LLM-Calls. Der Trick ist, zu wissen, wann man aufgibt.

AutoVerus nutzt ein Netzwerk von LLM-Agents, um Verus-Correctness-Proofs für Rust-Code zu generieren und über 90% der Proof-Obligations durch eine Generate-Repair-Discharge-Schleife zu automatisieren, die vom Feedback des SMT-Solvers getrieben wird.

Der schwierigste Teil der formalen Verifikation war nie der Verifier. Es ist das Schreiben des Proofs. Gib einem erfahrenen Rust-Engineer Verus, den…

LLMs können Rust-Code generieren. Formale Beweise sind ein ganz anderes Problem.

Große Sprachmodelle schreiben erstaunlich guten Rust-Code, aber wenn man sie um einen formalen Beweis bittet, halluzinieren sie Invarianten und erfinden Syntax, die kein Verifizierer akzeptiert. Hier ist, was sie tatsächlich richtig machen, wo sie scheitern und wie man sie dennoch nutzen kann.

LLMs können Rust schreiben, das kompiliert und sogar besteht. Was sie nicht zuverlässig können, ist einen formalen Beweis dafür zu führen, dass der Code für…