Wenn KI mehr Code in kürzerer Zeit erzeugt, wächst nicht automatisch der geschäftliche Nutzen. Der Engpass verschiebt sich: Teams müssen schneller erkennen, ob Änderungen korrekt, sicher, wartbar und im Betrieb beobachtbar sind. Charity Majors, Mitgründerin von Honeycomb, vertritt deshalb die These, dass Zuverlässigkeit und Verifikation zu den knappen Fähigkeiten KI-gestützter Entwicklung werden. Für Unternehmen ist diese Position vor allem ein Anlass, ihren Delivery-Prozess neu zu bemessen.
Die Aussage ist kein neutraler Branchenstandard und kein Beweis für eine bestimmte Produktivitätssteigerung. Sie stammt aus einem Gespräch über AI Coding, Observability und Engineering-Praxis. Plausibel ist jedoch die zugrunde liegende Kapazitätsfrage: Wenn die Menge möglicher Änderungen schneller wächst als Test-, Review- und Betriebsfähigkeit, steigt der Rückstau an ungeprüftem Risiko. Mehr Generierung ohne mehr Evidenz kann Durchsatz nur scheinbar erhöhen.
Welche Position Charity Majors vertritt
Majors argumentiert, KI werde zu einem grundlegenden Bestandteil der Softwareentwicklung. Gleichzeitig würden Reliability und Verification wichtiger, weil nichtdeterministische Systeme mehr Disziplin verlangten. Genannt werden Tests, Evaluierungen und Konformitätsprüfungen. Sie erwartet außerdem, dass professionelle Entwickler künftig Code ausliefern könnten, den sie nicht vollständig gelesen haben. Diese Prognose ist eine Meinung; daraus folgt aber eine prüfbare Anforderung an den Prozess: Vertrauen muss aus unabhängiger Evidenz entstehen.
Auch ihre Skepsis gegenüber dem traditionellen Stellenwert von Code Reviews ist als Position zu kennzeichnen. Majors bewertet menschliche Gespräche und die Entscheidung, was gebaut werden soll, höher als das Lesen jeder einzelnen Änderung. Das bedeutet nicht, Reviews ersatzlos zu streichen. Unternehmen müssen vielmehr unterscheiden: Welche Risiken lassen sich automatisiert prüfen, welche Architekturentscheidungen brauchen Diskussion und welche Änderungen verlangen weiterhin detaillierte menschliche Inspektion?
Stop being skeptical about AI for development
Titel des Gesprächs im Pragmatic Engineer
Verifikation als System statt letzter Prüfschritt
Ein belastbarer Prozess beginnt vor der Codeerzeugung. Anforderungen, Nichtziele, Sicherheitsgrenzen und Abnahmekriterien müssen so konkret sein, dass Menschen und Maschinen das Ergebnis prüfen können. Danach folgen schnelle lokale Kontrollen, automatisierte Tests, statische Analyse, Abhängigkeits- und Geheimnisscans sowie Integrationsprüfungen. In Staging werden reale Schnittstellen, Migrationen, Last und Fehlerverhalten geprüft. Produktions-Observability bestätigt schließlich, ob die Annahmen unter echten Bedingungen tragen.
- Spezifikation: gewünschtes Verhalten, Grenzen und messbare Abnahme vor dem Prompt festlegen.
- Build: Formatierung, Typen, statische Analyse, Abhängigkeiten und Secrets automatisch prüfen.
- Test: Unit-, Integrations-, Property-, Sicherheits- und Regressionstests risikobasiert kombinieren.
- Evaluation: nichtdeterministische Komponenten mit festen Datensätzen und Konformitätsgrenzen bewerten.
- Betrieb: Traces, Metriken, Logs, SLOs, Rollback und Incident-Verantwortung vor Auslieferung sichern.
Die Pyramide verhindert, dass menschliche Reviewer jeden generierten Token kontrollieren müssen. Automatisierung übernimmt reproduzierbare Prüfungen; Menschen konzentrieren sich auf Zweck, Architektur, Risiko und ungewöhnliche Änderungen. Das funktioniert nur, wenn Tests selbst vertrauenswürdig sind. Von derselben KI erzeugter Code und Test können denselben blinden Fleck teilen. Für kritische Pfade sind unabhängige Testfälle, bestehende Regressionen und fachliche Abnahme notwendig.
Freigaben nach Wirkung staffeln
Nicht jede Änderung verdient denselben Prozess. Dokumentation oder interne Entwicklungswerkzeuge können mit schlanken Kontrollen auskommen. Authentifizierung, Zahlungen, Berechtigungen, Datenmigrationen oder sicherheitskritische Infrastruktur brauchen strengere Gates. Der Maßstab ist die mögliche Fehlwirkung, nicht die Zahl der geänderten Zeilen. Eine kleine KI-generierte Konfigurationsänderung kann riskanter sein als ein großer, gut getesteter Refactor.
- Änderungen nach Datenzugriff, Reversibilität, Außenwirkung und Sicherheitsrelevanz klassifizieren.
- Pro Klasse verpflichtende Tests, Reviewer, Staging- und Rollback-Anforderungen definieren.
- KI-Herkunft protokollieren, ohne sie pauschal als Qualitätsurteil zu verwenden.
- Bei fehlender Evidenz den Scope verkleinern oder die Auslieferung stoppen.
- Nach Produktion SLOs und Fehlersignale beobachten und Regeln aus Incidents nachschärfen.
Besondere Vorsicht gilt Kommunikation und anderen Outputs, die Menschen direkt erreichen. Majors empfiehlt, jede KI-unterstützte Nachricht vor dem Versand vollständig zu lesen. Für Unternehmen ist das ein sinnvolles Mindestprinzip: Externe E-Mails, Incident-Updates, Release Notes und sicherheitsrelevante Anweisungen brauchen eine verantwortliche Person. Automatisches Erzeugen darf nicht mit automatischer Autorisierung verwechselt werden.
Kapazität und Kosten richtig messen
Klassische Kennzahlen wie Pull Requests, Commits oder erzeugte Zeilen können falsche Anreize setzen. Sinnvoller sind Zeit bis zu belastbarer Evidenz, Anteil automatisch nachgewiesener Anforderungen, entkommene Defekte, Rollbacks, Incident-Folgen und Wartungsaufwand. Ebenso wichtig ist die Auslastung von CI, Testumgebungen und Review-Rollen. Wenn KI den Build-Durchsatz verdoppelt, aber Testwarteschlangen und Störungen steigen, wurde der Engpass nur verlagert.
Ein Pilot sollte deshalb mit wenigen Teams und klaren Baselines starten. Verglichen werden ähnliche Aufgaben mit und ohne KI-Unterstützung. Gemessen werden nicht nur Entwicklungszeit, sondern auch Nacharbeit, Testflakiness, Reviewdauer, Produktionsfehler und Zeit bis zur Wiederherstellung. Teams dokumentieren, welche Aufgaben gut delegierbar sind und wo Kontext oder Verantwortung fehlen. Aus diesen Daten entstehen verbindliche Einsatzklassen statt allgemeiner Verbote oder Euphorie.
Fazit
Charity Majors formuliert eine zugespitzte, aber nützliche These: Wenn Codeerzeugung billiger wird, werden Verifikation und Zuverlässigkeit wertvoller. Unternehmen sollten daraus weder blindes AI-First noch ein Ende menschlicher Reviews ableiten. Entscheidend ist ein risikobasierter Evidenzprozess aus Spezifikation, automatisierten Prüfungen, unabhängigen Evals, Observability und klarer Freigabeverantwortung. Erst wenn diese Kapazität mitwächst, wird zusätzlicher Code-Durchsatz zu verlässlichem Geschäftsnutzen.