Eine Verteidigung dafür, den Code nicht zu lesen

• „Code nicht lesen“ bedeutet, sich statt auf Zeile-für-Zeile-Reviews auf Spezifikationen, Tests, statische Analyse und Produktionssignale zu verlassen; in bestimmten Risikobereichen kann zu Code-Review eskaliert werden
• Die Beispiele von OpenAIs Harness Engineering und OpenClaw zeigen einen Ansatz, der sich statt auf Code auf Tests, Beobachtbarkeit und automatische Verifikations-Infrastruktur konzentriert
• Als Entgegnung auf Skepsis rund um Blackboxen, Sicherheit und Bug-Akkumulation wird die historische Entwicklung von Abstraktionsschichten und die Bedeutung automatisierter Verifikationswerkzeuge hervorgehoben
• Es wird eine ausgewogene Position vertreten: Code-Lesen wird nicht vollständig ausgeschlossen, sondern für Sicherheit, Security und Architekturentscheidungen ist direkte Prüfung weiterhin nötig
• Code wird zunehmend zu einem Implementierungsdetail, während Spezifikationen, Architektur und Verifikationsschichten als zentrale Artefakte an Bedeutung gewinnen

---

Was „Code nicht lesen“ genau bedeutet

• Der Satz „Ich lese keinen Code mehr“ aus einem früheren Beitrag löste auf Hacker News mehr als 200 hitzige Kommentare aus
• Gemeint ist präzise, dass für den Großteil des Produktcodes Zeile-für-Zeile-Reviews nicht als Standardmethode der Verifikation dienen
• Spezifikationen und Tests, selektive Prüfung geänderter Diffs sowie Produktionssignale werden weiterhin kontrolliert; in bestimmten Risikobereichen kann zum Code-Lesen eskaliert werden
• Der Grund, Code nicht zu lesen, ist nicht, dass Code weniger wichtig wäre, sondern dass insbesondere in großen Umgebungen das Lesen Zeile für Zeile nicht die effektivste Methode ist, Korrektheit sicherzustellen

Beispiele als Grundlage

• OpenAIs Harness Engineering

  • OpenAI erläutert im Blogbeitrag Harness Engineering, dass sich die zentrale Rolle von Software-Engineering-Teams von der Code-Erstellung hin zu Umgebungsdesign, Spezifikation von Absichten und Aufbau von Feedback-Loops verschoben hat
  • Drei Engineers haben allein mit Codex-Agenten eine Million Zeilen Code erzeugt und damit ein Produkt gebaut, das von Hunderten internen Nutzern verwendet wird
  • Investiert wurde nicht primär in den Code selbst, sondern in das umgebende Harness — Dokumentation, Abhängigkeitsregeln, Linter, Test-Infrastruktur und Observability-Systeme
  • In Zeile-für-Zeile-Code-Reviews wurde nicht gesondert investiert

• OpenClaw

  • OpenClaw, von einer einzelnen Person ohne Team entwickelt, gehört in den vergangenen Monaten zu den am schnellsten wachsenden Open-Source-Projekten und hat mehr als 100.000 GitHub-Stars erreicht
  • Die Struktur betreibt 5 bis 10 Agenten parallel und wird von einem erfahrenen Engineer, nicht von einem Anfänger, entworfen und betrieben
  • In einem Interview mit dem Titel „Ich deploye Code, den ich nicht lese“ heißt es, dass gezielt in Refactoring, Architektur, Tests und das Harness rund um AI Coding investiert wird

• Vom Coder zum Orchestrator

  • Ein erfahrener Engineer, der ESLint entwickelt und mehrere O'Reilly-Bücher geschrieben hat, prognostiziert in einem aktuellen Beitrag, dass die Zukunft des Software Engineering nicht im Schreiben von Code, sondern in der Orchestrierung von AI-Agenten liegen wird
  • Die Kernkompetenzen verschieben sich von Syntax und Implementierung hin zu Architekturdesign, Spezifikationsschreibung und Design von Feedback-Loops

Entgegnungen auf Skepsis

• Kritik am Blackbox-Ansatz

  • Auf die Kritik „Gibt es Fälle, in denen man freiwillig einen Blackbox-Ansatz wählt?“ wird betont, dass das Ergebnis von Code nicht der Code selbst, sondern das Produkt ist
  • Die passendere Analogie ist nicht, dass ein Fotograf seine Fotos nicht ansieht, sondern dass er nicht die interne Struktur der Kamera untersucht, die das Foto erzeugt
  • Dass wir Systeme auf Abstraktionsschichten aufbauen, die wir nicht direkt im Detail betrachten, ist in der Software ebenso wie in anderen Engineering-Bereichen längst gängige Praxis

• Sicherheitsbedenken

  • Zur Sorge, dass AI-generierter Code Backdoors enthalten könnte, heißt es: Das ist nicht primär ein Problem von „Menschen müssen jede Zeile lesen“, sondern eines von Tooling und Verifikationssystemen
  • Statische Analyse, Dependency-Scanning und Security-Linter existieren auch deshalb, weil Menschen ebenfalls verwundbaren Code schreiben; die Lösung liegt in stärkeren automatisierten Verifikationssystemen und damit in derselben Richtung wie ein Harness-zentrierter Ansatz
  • In besonders sicherheitssensiblen Bereichen bleibt menschliches Review allerdings weiterhin notwendig

• Das Problem der Bug-Akkumulation

  • Am häufigsten kommt die Kritik: „Wenn Code versagt, verschwindet das Geld der Menschen, Flugzeuge bleiben stehen und Autos gehen kaputt. Lies den Code.“
  • Laut Daten von CodeRabbit verursacht AI-generierter Code über die gesamte Softwarequalität hinweg 1,7-mal mehr Defekte
  • Allerdings gibt es sehr unterschiedliche Formen des AI Coding; Harness-zentrierte Entwicklung mit Spezifikationen, hierarchischen Tests und Architekturgrenzen unterscheidet sich grundlegend von einfachem Vibe Coding
  • Ein in den Kommentaren vorgeschlagener Ansatz: auf Spezifikationen, Tests und statische Analyse setzen, mehr als 85 % Test-Coverage halten, Testing Ladders als Integrationstests mit schrittweise erweitertem Umfang aufbauen und Fehler durch Benchmarking sowie intensives Dogfooding früh sichtbar machen
  • Die Kernfrage ist nicht „Hat AI-Code im Durchschnitt mehr Bugs?“, sondern „Erzeugt er innerhalb eines gut gestalteten Harness bei gleicher Entwicklungsgeschwindigkeit mehr Bugs als die Alternative?“
  • Auch Greg Brockman, Mitgründer von OpenAI, vertritt die Position, dass dieselben Maßstäbe wie für von Menschen geschriebenen Code gelten sollten

So ist das System tatsächlich aufgebaut

• Über den Großteil der Karriere hinweg wurde Code geschrieben, meist für interne Tools, aber auch für Systeme, auf die echte Nutzer angewiesen sind
• Die Form und Struktur von Code werden verstanden, aber es wird bewusst entschieden, ihn nicht direkt zu lesen

• Spezifikationsbasierter Workflow

  • Bevor ein Agent Code schreibt, wird zunächst in Gesprächen mit AI eine sehr konkrete und detaillierte Spezifikation erstellt
  • Über Requirement-IDs wird die Struktur so angelegt, dass Nachverfolgbarkeit von der Produktspezifikation bis zum Ausführungsplan möglich ist
  • Jede Aufgabe im Ausführungsplan enthält Akzeptanzkriterien mit einer angegebenen Verifikationsmethode
    • Automatische Tests sind (TEST)
    • Visuelle Prüfung ist (BROWSER:DOM)
    • (MANUAL) wird nur genutzt, wenn es keine andere Möglichkeit gibt; auch dann wird zuerst versucht, möglichst einen automatisierten Check auf Basis von curl oder bash zu erzeugen
  • Aufgaben ohne konkrete Verifikations-Metadaten werden von einer Audit-Funktion vor Arbeitsbeginn blockiert

• AI Coding Toolkit (das Harness)

  • Ein Toolkit aus Prompts, Skills, Hooks und Skripten beschränkt die Arbeitsweise der Agenten und umfasst mehr als 35 Skills, strukturierte Agenten-Anweisungen und eine hierarchische Verifikations-Infrastruktur
  • Agenten-Anweisungen werden als Infrastruktur verwaltet
    • AGENTS.md fungiert als zentrales Regelwerk: konservative Änderungen, Beibehaltung bestehender Interfaces, Einhaltung von TDD, kein Raten, keine Umschreibung der Git-Historie
    • VISION.md definiert die strategischen Grenzen
  • Es wird ein hierarchisches Verifikationssystem betrieben
    • Nach Abschluss jeder Phase führt ein Checkpoint-Skill mehrschichtige Gates aus, darunter Type Checking, Linting, Tests, Builds, Mutation Testing und Security Scans
    • Wenn Browser-Tools verfügbar sind, wird automatische Browser-Verifikation durchgeführt
    • Geänderte Diffs werden zur Einholung einer Second Opinion an ein anderes AI-Modell (Codex CLI) übergeben
    • Cross-Model-Verifikation kompensiert blinde Flecken einzelner Modelle
  • Es gibt Fälle, in denen Code direkt gelesen wird, aber nur in Ausnahmesituationen
    • Wenn alle Tests erfolgreich sind, sich das Produktverhalten aber seltsam anfühlt
    • Wenn bedeutende Architekturentscheidungen getroffen werden müssen
    • Wenn Störungen debuggt werden, die mehrere Agenten nicht lösen konnten
  • Selbst dann geht es nicht um die Analyse des Codes an sich, sondern darum, welche Lücke im Harness das Problem zugelassen hat, um Wiederholungen zu verhindern

Wann man Code lesen sollte

• Bei Systemen mit direktem Sicherheitsbezug, sicherheitskritischen Services und wichtigen Architekturentscheidungen ist Software Engineering tatsächlich Engineering, und in einer Zeit massenhaft erzeugten Codes wird diese Bedeutung eher noch größer
• Die Metapher „Children of the Magenta“ aus der Luftfahrt beschreibt das Phänomen, dass Piloten sich übermäßig auf die magentafarbene Flugroute auf dem Navigationsdisplay verlassen
  • Die Lehre lautet nicht „Nutze keinen Autopiloten“, sondern bewahre die Fähigkeit, bei Bedarf einzugreifen
  • Wenn Probleme auftreten, muss man das Automatisierungsniveau senken und zu den Grundlagen zurückkehren können; zu verlangen, jeden Flug immer manuell durchzuführen, wäre jedoch ineffizient und riskanter
  • Entscheidend ist die Balance: Automatisierung nutzen, ohne die Eingriffsfähigkeit zu verlieren

Auf die Entwicklungslinie setzen

• Jede Abstraktionsschicht im Computing stieß bei ihrem Auftreten auf Widerstand; ein typisches Beispiel ist die Neuschreibung von Unix in C durch Dennis Ritchie und Ken Thompson im Jahr 1973
  • Siehe auch den Beitrag von Cline: Von Assembly zu AI: Warum „Vibe Coding“ nur ein weiteres Kapitel in unserer Abstraktionsgeschichte ist
• Damals lautete die Kritik, es werde langsamer, die Kontrolle über die Hardware gehe verloren und zusätzliche Komplexität mache Wartung schwieriger; doch die Abstraktion von C ermöglichte es Unix, sich zu einem Betriebssystem mit hoher Portabilität und großem Einfluss zu entwickeln
• Das wiederkehrende Muster ist, dass Menschen mit Expertise in der abstrahierten Schicht die Bedeutung des Verständnisses dieser Schicht betonen; in manchen Situationen ist das berechtigt, aber die meiste Zeit wird doch in höheren Abstraktionsschichten gedacht und entworfen
• Die Entscheidung, Code nicht zu lesen, ist keine Behauptung, dass die Werkzeuge perfekt seien, sondern eine Einschätzung, dass dieser Ansatz für viele Anwendungsfälle bereits tragfähig ist und sich schnell verbessert
• Code verschwindet nicht, sondern wird zunehmend zum Detail der Implementierung; stattdessen treten Spezifikationen, Architektur und Verifikationsschichten als zentrale Artefakte hervor