Mehr KI-generierter Code machte das Team nicht schneller. Charity Majors zielte trotzdem auf 2×.

Mehr KI-generierter Code macht Ihr Team nicht schneller. Er kann Sie tatsächlich ausbremsen.

Das ist kein Anti-KI-Take. Es ist Charity Majors—Mitgründerin und CTO von Honeycomb—die beschreibt, was passiert, wenn Generation skaliert und alles downstream nicht. Honeycomb baut Observability-Tools für komplexe Produktionssysteme. Wenn jemand der Speed-Narrative trauen sollte, dann sie. Trotzdem wählten sie ein 2×-Produktivitätsziel statt 10× zu jagen, und sie schrieben KI-Werte, bevor sie Mandate schrieben.

Der unbequeme Teil für die meisten Engineering-Leads: Der Engpass war nie Tippen. Es ist Software ausliefern, in Produktion debuggen und sie stabil am Laufen halten. Fluten Sie das Repo mit Agent-Output, kaufen Sie keine Velocity—Sie kaufen Warteschlangentiefe genau an den Schritten, die schon wehtaten.

Code schreiben war nie der harte Teil

Majors sagt das seit Jahren klar, lange bevor generative KI es modisch machte: Code schreiben war nicht der Constraint beim Shipping. Review, Integration, Deployment, Incident Response und kundensichtbare Zuverlässigkeit waren es.

KI verstärkt, was Sie ohnehin haben. Starke Observability und Release-Disziplin machen Codegen zum Hebel. Schwache Fundamente machen daraus Rauschen, das Sie bei nächtlichen On-Call-Alarmen trotzdem beheben müssen.

Deshalb sorgt sich ein Unternehmen, dessen Marke „sehen, was Produktion tut“ ist, weniger um Tastendrücke pro Stunde und mehr darum, ob jemand besitzen kann, was ausgeliefert wird.

Warum Honeycomb 2× wählte, nicht 10×

Honeycomb übernahm eine unternehmensweite 2×-Challenge—angelehnt an einen ähnlichen Push bei Intercom—nicht als Stunt, sondern als ehrliche Decke. Doppelter Impact mit KI über ein Jahr. Nicht zehnmal die Tokens. Nicht zehnmal die gemergten Zeilen.

Emily Nakashima, VP Engineering bei Honeycomb, hat den Rollout öffentlich beschrieben: ein Founder-Memo, das Experimente ermutigt, dann die wiederkehrende Frage der Ingenieure—wie messt ihr das?

Honeycombs Antwort ist lehrreich für jeden, der ein „10× Engineer“-Memo von Social Media kopiert:

• **Einzelmetriken de-emphasieren**, die Gaming einladen—Token-Spend, Lines of Code, PR-Count
• **Self-Reporting vertrauen**, ob KI Impact wirklich erhöhte, nicht ob sie Aktivität erhöhte
• **2× als Richtung behandeln**, nicht als Quote, die man mit unowned Output in main trifft

10×-Narrative klingen mutig im Board Deck. 2× mit Accountability überlebt den Kontakt mit Produktion.

KI-Werte schlagen KI-Mandate

Honeycomb blieb nicht beim Produktivitätsziel. Das Team schrieb KI-Werte—Prinzipien zu Transparenz, emotionaler Sicherheit und was „gut“ heißt, wenn Maschinen den ersten Entwurf liefern.

Die Zeile, die auf Engineering-Twitter am schnellsten reist, ist auch die operativste:

• **Jeder KI-Output braucht einen menschlichen Owner.** Wenn Sie Ihren Namen nicht darauf setzen wollen, ist es wahrscheinlich keine gute Arbeit.
• **Qualität zuerst, Quantität zweitens.**

Lesen Sie das als Policy, nicht als Poesie. Ownership ist, wie Sie verhindern, dass der Engpass von „Tippen“ zu „Code-Änderungen, die niemand debuggt“ wandert. Derselbe Instinkt wie Agent-Output wie Vendor-Code zu behandeln—nur ist der Vendor hier Ihr eigenes Team an einem guten Tag.

Mandate ohne Werte produzieren Theater: alle nutzen das Tool genug, um beschäftigt zu wirken, niemand verbessert den Release-Pfad, und Störungen häufen sich durch Code-Änderungen, die niemand vollständig erklären kann.

Was den Engpass wirklich bewegt

Wenn Generation billig ist, investieren Sie dort, wo Generation nie das Problem war:

• **Release-Cadence und Rollback-Klarheit**—wer kann agent-gestützten Code nachts bei einem On-Call-Alarm ohne Chat-Log zurückrollen?
• **Observability auf Pfaden, die KI berührt**—Auth, Zahlungen, Data Writes, Third-Party-Integrationen
• **Review-Tiefe bei Integration**, nicht Syntax—verhält sich diese Änderung unter echtem Traffic?
• **On-Call-Bereitschaft**—kann der On-Call-Ingenieur das Feature erklären, ohne die Prompt-Historie zu öffnen?

Honeycombs Weltbild ist hier kein Zufall. Observability ist, wie Sie Systeme debuggen, die Sie nicht vollständig autorisiert haben. Das wird wahrer, nicht weniger wahr, wenn KI die erste Version entwirft.

Web-Agenturen und Produktteams spüren das kleiner: eine Client-Landingpage mit kaputtem Formular ist kein „KI-Fail“. Es ist ein Shipping-Fail, der zufällig in einem Chat-Fenster begann.

Eine praktische 2×-Checkliste für Web-Teams

Sie brauchen nicht Honeycombs Stack, um dieselbe Disziplin zu nutzen:

• Ein **begrenztes** Experiment pro Sprint wählen—ein Funnel, eine Integration, ein Perf-Fix—nicht „KI überall“
• Einen **menschlichen Owner** auf jedem agent-gestützten PR vor Merge benennen; kein Owner, kein Ship
• **Cycle Time to Production** messen, nicht generierte Wörter
• **Incidents oder Reverts** auf KI-berührten Pfaden monatlich tracken; diese Kurve zählt mehr als Token-Charts
• Drei **KI-Werte** schreiben, denen Ihr Team zustimmt; kürzer als ein Policy-Doc, stärker als ein Tool-Mandat

Ein 2×-Ziel ist realistisch. Ein 10×-Ziel ist vor allem eine Schlagzeile. Realistische Ziele bauen mit der Zeit Schwung auf.

Das Fazit gegen den Strom

Charity Majors sagte Ingenieuren nicht, weniger zu tippen. Sie sagte ihnen, mehr zu besitzen—und auf Impact zu zielen, der Debugging übersteht.

Mehr KI-generierter Code ohne menschliche Ownership macht Ihr Team nicht schneller. Er macht Ihre Incident-Queue länger. Wählen Sie 2× mit Werten, nicht 10× mit Metriken, die beeindruckend wirken, aber keinen echten Impact messen. Zweite Meinung gewünscht, wo Agent-Speed hilft oder Ihren Release- und Review-Loop überholt? Schreiben Sie uns.