- AI-Coding-Tools sollen die Entwicklung beschleunigen, doch der tatsächliche Engpass liegt nicht beim Schreiben von Code, sondern in ineffizienten organisatorischen Prozessen
- Wenn die Code-Menge steigt, verschärfen sich Staus in nicht entwicklungsbezogenen Phasen wie wartende Reviews, verzögerte Deployments und unklare Anforderungen, und die tatsächliche Cycle Time steigt sogar
- Laut Eli Goldratts Theory of Constraints verschlechtert die Optimierung eines nicht limitierenden Schritts das System, statt es zu beschleunigen
- Wenn nicht einmal die Verfasser AI-generierten Code vollständig verstehen, entsteht ein strukturelles Risiko, bei dem die Angriffsfläche für Störungen wächst und zugleich weniger Menschen das System noch nachvollziehen können
- Der Wettbewerbsvorteil liegt nicht bei dem Team, das am schnellsten Code schreibt, sondern bei dem Team, das herausfindet, was gebaut werden muss, und es zu den Nutzerinnen und Nutzern bringt
Der Beginn der falschen Optimierung
- Es tauchen Meldungen auf, wonach durch die Einführung von AI-Coding-Assistenten die Code-Ausgabe um 40 % gestiegen sei
- Doch die Frage fehlt: „Geschwindigkeit in Richtung wovon?“
- Wenn Ressourcen in einen ohnehin schnellen Schritt (das Schreiben von Code) gesteckt werden, wird das Gesamtsystem langsamer
- Wird ein Bereich beschleunigt, der nicht der Engpass ist, stapelt sich Bestand an unfertigem Code, und Qualitätsverluste sowie Chaos sind die Folge
Wenn man nicht den Engpass optimiert, wird das System noch schlechter
- Kernaussage der Theory of Constraints, die Eli Goldratt 1984 in seinem Roman The Goal vorstellte: Jedes System hat genau einen Engpass, und der Gesamtdurchsatz wird durch den Durchsatz dieses Engpasses bestimmt
- Wird ein nicht limitierender Schritt optimiert, wird das System nicht schneller; stattdessen häuft sich nur Bestand an unfertiger Arbeit an, was zu längeren Lead Times, Verwirrung und sinkender Qualität führt
- Bildlich gesprochen: Selbst wenn Station A Widgets schneller produziert, ändert das nichts, wenn die Engpass-Station B gleich schnell bleibt — zwischen A und B entsteht nur ein größerer Haufen unbearbeiteter Widgets
Was „dreifache Code-Ausgabe“ in der Praxis wirklich bewirkt
- Entwickler produzieren PRs schneller als je zuvor, aber die Anzahl der Reviewer bleibt gleich, also liegen PRs einen Tag, zwei Tage oder eine Woche in der Review-Queue
- Die Autorin oder der Autor ist gedanklich bereits beim nächsten AI-unterstützten Feature und hat den Kontext gewechselt, sodass man sich bei Review-Kommentaren zu Code von vor acht Tagen kaum noch an diesen Code erinnert
- Weil es zu viele Reviews gibt, entstehen Rubber-Stamp-Reviews, bei denen ohne richtiges Lesen freigegeben wird
- CI dauert 45 Minuten, scheitert wegen flaky Tests und muss neu gestartet werden, die Deployment-Pipeline wartet auf die manuelle Freigabe einer Person, die gerade in Meetings sitzt, und ein Feature bleibt drei Tage in Staging liegen
- Die Entwickler haben bereits zwei weitere PRs eröffnet, WIP (Work In Progress) steigt stark an, alle arbeiten gleichzeitig an sechs Dingen, und nichts wird fertig
- Es wird mehr Code produziert, aber weniger Software ausgeliefert; die Cycle Time hat sich verschlechtert, doch im Dashboard steht eine Produktivitätssteigerung von 40 %
- Ein zusätzliches Risiko von AI-generiertem Code: Die Person, die ihn „geschrieben“ hat, hat ihn in Wirklichkeit nur per Prompt erzeugt und grob überflogen, sodass bei einem Produktionsausfall um 2 Uhr morgens weder die On-Call-Person noch die Prompt-verfassende Person diesen Code erklären kann
- Wenn der Code zunimmt und das Verständnis abnimmt, ist das keine Produktivitätssteigerung, sondern eine Zeitbombe mit hübscherem Dashboard
Der tatsächliche Engpass 1: Man weiß nicht, was gebaut werden soll
- Der PM hat seit zwei Monaten nicht mit echten Nutzerinnen und Nutzern gesprochen, und Anforderungen kommen als drei Zeilen in einem Jira-Ticket und ein Figma-Link an
- Engineers treffen pro Tag 50 Mikroentscheidungen zu Verhalten, Edge Cases und Fehlerbehandlung auf Basis von Vermutungen, ohne jede Spezifikation
- Ein Team entwickelte sechs Wochen lang ein Feature auf Basis dessen, was ein Vertriebsmitarbeiter in Slack weitergegeben hatte und was ein potenzieller Kunde in einem Gespräch vielleicht gesagt haben könnte; dieser potenzielle Kunde kaufte nicht, und das Feature wurde von 11 Personen genutzt (davon 9 aus dem internen QA-Team)
- Schneller Code zu schreiben erhöht nur die Geschwindigkeit, mit der das Falsche gebaut wird; es automatisiert bloß das Raten
- Der Engpass ist das Verständnis des Problems selbst und lässt sich nicht durch schnelleres Tippen beheben
Der tatsächliche Engpass 2: Alles, was passiert, nachdem der Code „fertig“ ist
- In den meisten Organisationen macht das Schreiben von Code nur etwa 20 % der gesamten Reise aus; die restlichen 80 % sind Wartezeit in verschiedenen Queues
- Es gibt Fälle, in denen ein Feature an einem Nachmittag implementiert wurde, aber zwei Monate brauchte, um in Produktion zu gelangen
- PR-Reviews, CI, Staging, QA, Security-Review, Produktfreigabe, Deployment-Fenster, Canary-Rollout — eine lange Kette aus Übergaben, Wartezeiten und Queues
- Die meiste Zeit bewegt sich der Code nicht; er wartet darauf, dass ihn jemand ansieht, dass eine Pipeline läuft und dass er die Erlaubnis erhält zu existieren
- Wer schneller releasen will, muss die Punkte finden, an denen Arbeit wartet, und das Verhältnis von tatsächlicher Arbeitszeit zu Queue-Wartezeit messen
Der tatsächliche Engpass 3: Der Teufelskreis mangelnden Deployment-Vertrauens
- Wenn Tests flaky sind, die Observability chaotisch ist und niemand dem Canary-Prozess vertraut, dann fürchten Teams Deployments
- Aus Angst bündeln sie Änderungen zu größeren Releases; das erhöht das Risiko, macht Deployments noch beängstigender und führt erneut zu größeren Bündeln — ein Teufelskreis der Angst
- Wenn darauf noch schnellere Code-Erzeugung trifft, gilt: Es gibt mehr Code, aber die Deployment-Kultur bleibt unverändert angstgetrieben, also werden die Batches größer und die Release-Frequenz sinkt
Der tatsächliche Engpass 4: Fehlendes Feedback nach dem Release
- Ein Feature wird gebaut und veröffentlicht, aber es gibt weder saubere Analysen noch Nutzerinterviews nach dem Release, und niemand prüft, ob das Feature das Problem tatsächlich gelöst hat
- Das nächste Feature ist wieder geraten, das danach ebenfalls — die gesamte Produkt-Roadmap ist eine Folge von Vermutungen ohne Feedback
- Schnellere Code-Ausgabe beschleunigt nur den Zyklus aus „bauen, releasen und mit den Schultern zucken“
Der tatsächliche Engpass 5: Der Kalender ist die tragende Wand
- Manchmal ist der Engpass nicht technischer Natur, sondern besteht aus Meetings für Entscheidungen, einer API-Vertragsabstimmung zwischen drei Teams, die seit einem Monat nicht mehr gesprochen haben, oder einem Architekten mit zwei Wochen Rückstand, der als einzige Freigabestelle für alle wichtigen Designs fungiert
- Wegen eines quartalsweisen Planungsprozesses, der sechs Wochen dauert, kann selbst dringende Arbeit erst nach fünf Wochen beginnen
- Es gibt reale Fälle, in denen ein Feature nicht veröffentlicht wurde, weil man auf ein Meeting mit einer Person im Urlaub wartete
- Das sind Koordinationsprobleme, menschliche Probleme und politische Probleme — ohne Zusammenhang mit der Geschwindigkeit beim Schreiben von Code
Was stattdessen getan werden sollte
- Value Stream Mapping: Ein Feature von der Idee bis zur Produktion verfolgen und für jeden Schritt die benötigte Zeit sowie die Wartezeit zwischen den Schritten erfassen
- Cycle Time messen: Nicht Codezeilen, Anzahl gemergter PRs oder Story Points messen, sondern die Zeit vom Commit bis zu dem Moment, in dem Nutzerinnen und Nutzer es in Produktion verwenden können
- Wartezustände beseitigen: Wenn PR-Reviews zwei Tage dauern, mit Pair Programming, kleinen PRs, dedizierten Review-Zeiten oder asynchronen Review-Normen gegensteuern. Wenn Deployments auf manuelle Freigaben warten, automatisieren oder mindestens auf einen Slack-Button umstellen
- Aufhören zu starten und anfangen fertigzustellen: Es gibt einen Grund für WIP-Limits; drei abgeschlossene Dinge sind besser als zehn laufende. Alles, was in Arbeit ist, verursacht Kosten durch Context Switching
- Mit den Leuten sprechen, die die Arbeit machen: Entwickler wissen bereits, wo die Engpässe liegen; sie äußern Frust im Stand-up und machen seit Monaten Memes in Slack. Sie dachten nur, niemand höre zu
Zentrales Fazit
- Statt „Code-Ausgabe um 40 % erhöht“ zu verkünden, hätte ein VP sagen sollen: „Unsere Value-Stream-Analyse zeigt, dass ein Feature im Durchschnitt neun Tage zwischen den Schritten wartet, und wir werden diese Zeit halbieren“
- Der Wettbewerbsvorteil liegt nicht bei dem Team, das am schnellsten Code schreibt, sondern bei dem Team, das herausfindet, was gebaut werden muss, es baut und in die Hände der Nutzerinnen und Nutzer bringt
- Der Engpass ist nicht die Tastatur
4 Kommentare
lol
Die Pipeline ist dieselbe
ich habe nur das Gefühl, dass die Entwickler unverantwortlicher geworden sind
Ich will zum Software-Handwerker werden.
Hacker-News-Kommentare
Als unser Team ernsthaft mit agentenbasierter Entwicklung angefangen hat, hatten wir Sorge, dass zwar die Coding-Geschwindigkeit steigt, aber dafür die Review-Zeit zunimmt
Bisher gibt es noch keine klare Veränderung, und alle lernen noch den neuen Workflow, daher haben wir noch nicht genug Daten
Aber es gibt Fälle, in denen schnelles Coden besonders nützlich ist — Ideen ausprobieren, komplexe Wiederholungsarbeit, einfache, aber arbeitsintensive Implementierungen, das Abdecken von Edge Cases nach dem Happy Path usw.
Besonders gut funktionieren Agenten, wenn sie einen bestehenden Branch oder PR direkt erweitern
Der größte Produktivitätsgewinn ist, dass ich während der Agent codet, etwas anderes machen kann. Zum Beispiel reviewe ich einen PR und wenn ich zurückkomme, liegt ein Ergebnis vor
Anfangs war ich skeptisch, inzwischen bin ich vorsichtig optimistisch. Eine Verzehnfachung ist wohl unrealistisch, aber schon eine Verdopplung wäre großartig
Dieser Ansatz taugt nur, wenn Fehler billig sind oder der Änderungsumfang klein ist. Sonst sinken Qualität und Zufriedenheit, und am Ende wird nur der Zeitplan enger
Unterm Strich gewinnt man keine Zeit durch Parallelisierung zurück, sondern schiebt aufgeschobene Arbeit nur etwas weniger weit auf
Nur dieses „während der Agent codet, etwas anderes tun“ erzeugt bei mir eine seltsame Müdigkeit
AI ist produktiv, aber es ist eine völlig andere Art von Arbeit als das Coden als menschlicher Handwerker
Ein Refactoring, das man selbst gemacht hätte und deshalb nur schwer aufgeben würde, lässt sich bei AI leichter ehrlich als „das war nichts“ bewerten
Ständiges Multitasking führt schnell zu Burnout. Schade, dass der menschliche Faktor in der Diskussion fehlt
Ich möchte nicht immer im „optimierten Zustand“ arbeiten
Jemand sagte, der Flaschenhals sei das Verstehen des Problems, und ich würde gern fragen, warum schnelles Tippen nicht helfen soll, ein Problem besser zu verstehen
Wenn man schnell etwas Falsches baut, kann man dadurch nicht vielleicht auch schneller die richtige Richtung finden?
Ich merke oft erst beim Bauen von etwas, was ich eigentlich wirklich will. Je billiger Prototyping wird, desto stärker wird dieser Effekt
Natürlich endet es am Ende oft doch mit der Rückschau „Wir hätten mehr mit den Nutzern reden müssen“, aber das ist wieder ein anderes Problem
Bei Banken etwa kann man bestenfalls einmal pro Woche ein Experiment machen
Aber die meiste Software ist nicht so. Code zu schreiben ist nur ein Teil der gesamten Arbeit
So wie ein Chirurg nicht einfach nur „schneidet“, besteht auch die Arbeit eines Engineers nicht nur daraus, Code zu schreiben
Wenn man allein nur am Code feilt, erzeugt man damit womöglich einfach nur mehr Verwirrung
Manchmal ist ein einstündiges Gespräch mit PM oder Kunden sehr viel besser
Der aktuelle LLM-Hype fühlt sich an, als sei zuerst die Lösung da gewesen und erst danach das Problem
Wenn man wirklich schneller werden will, muss man zuerst fragen: „Was ist eigentlich der Flaschenhals?“
Wenn das Management eine AI-Präsentation sieht und dann glaubt „Damit werden wir schneller“, ist das nur Vibe-Management
Coding ist davon der arbeitsintensivste und am ehesten automatisierbare Teil
LLMs können hier eine Menge Last abnehmen. Gerade beim Schreiben von Testcode ist AI gut
Menschliche Entwickler können ihre Fixierung auf Code immer noch nicht loslassen
Tatsächlich ist Code nur eine Zwischenrepräsentation (IR) einer Lösung
So wie GCC bei der Übersetzung in Assembler nicht über interne Optimierungen nachdenken muss, müssen wir auch bei agentisch erzeugtem Code nur auf die Korrektheit des Ergebnisses schauen
Mit einer klaren Spezifikation und einem iterativen Review-Prozess können Menschen und Agenten dieselbe Implementierung hervorbringen
LLMs tun das nicht. Sie können missverstehen oder halluzinieren
Deshalb muss weiterhin ein Mensch reviewen
Agenten wählen oft die falschen Muster oder häufen technische Schulden an
Vielleicht schaffen wir Programmiersprachen eines Tages ganz ab, aber bis dahin ist es noch weit
Bedeutung wird erweitert oder komprimiert und verschwindet manchmal sogar
Viele Unternehmen wollen in Wahrheit gar keinen guten Code
Intern wird danach bewertet, „wie viel ausgeliefert wurde“, und wenn man Probleme anspricht, heißt es, man sei „zu pedantisch“
Am Ende wollen die internen Stakeholder einfach nur die Begründung haben, sagen zu können, dass es ein Erfolg war
Techniker haben die Verantwortung, dieses Risiko zu erklären
Seit der Einführung von AI zeigt sich tatsächlich ein Qualitätsverlust
In unserer Firma werden PR-Freigaben schlampig erledigt, CI braucht 45 Minuten und Deployments verzögern sich um Tage
Außerdem ist die Nutzung von AI verboten. Angeblich ist der meiste Code von Menschen geschrieben, aber ich habe da meine Zweifel
Der Artikel übersieht zwei Dinge — (A) Agentennutzung und Prozessoptimierung können gleichzeitig existieren, (B) bei manchen Tickets ist Code wirklich der Flaschenhals
Am Ende ist nicht AI oder Nicht-AI entscheidend, sondern Prozessverbesserungen zur Beseitigung von Flaschenhälsen
Ich bin Solo-Entwickler. Coding-Geschwindigkeit ist tatsächlich ein Problem, weil sie mir Zeit für andere Aufgaben wegnimmt
Ich habe heute Claude Code eingerichtet, und jetzt verbringe ich weniger Zeit mit Googeln oder dem Schreiben von Tests
Die Produktivität steigt dadurch vielleicht nicht um das Zehnfache, aber als arbeitssparende Technologie hat es absolut Wert. So wie eine Spülmaschine
Jetzt schreibt AI sogar Tests und warnt mich vor Edge Cases
Perfekt ist das nicht, aber die Geschwindigkeit bei der Auslieferung neuer Funktionen steigt und ich habe mehr Zeit
„AI kann man nicht vertrauen“ klingt für mich wie „Compilern kann man nicht vertrauen“
Letztlich geben Menschen die Richtung vor, verbessern die Prompts und wachsen gemeinsam damit
In Startup- oder VC-Umgebungen geht es stärker um das Lösen von Geschäftsproblemen als um Coding
Mehr Codeoutput garantiert noch lange kein besseres Ergebnis für das Gesamtsystem
Wie bei Templates oder Codegeneratoren wird es zwar schneller, aber Anforderungserhebung wird dadurch nicht zehnmal schneller — also sind auch zehnfache Produktivitätsgewinne unmöglich
Als Metapher ist das daher etwas unpassend
Wie verhindert man, dass AI Fehler macht, die Menschen normalerweise nicht machen?
Menschen prüfen Code schrittweise und logisch, AI tut das nicht
Selbst wenn Senior Engineers reviewen, ist Review kein Prozess, der alle Bugs finden soll
Und je seniorer jemand ist, desto mehr Meetings hat er und desto weniger kennt er den Kontext des Codes. Wie wirksam ist so ein Review dann überhaupt?
Zu glauben, Menschen seien perfekt, ist eine Illusion
Wir legen an AI höhere Maßstäbe an als an Menschen
Entscheidend ist am Ende ein stärkerer QA-Prozess. Man sollte Tests nicht den Entwicklern allein überlassen
Das erinnerte mich an das Buch The Goal, das ich früher gelesen habe. Wenn man einen Schritt in einem Prozess automatisiert, wird der nächste Schritt zum Flaschenhals
Bei Software ist es genauso: Selbst wenn Codegenerierung schneller wird, bringt das nichts, wenn der restliche Prozess nicht mithält
Am Ende ist alles dem Ziel der Gewinnerzielung untergeordnet. Auch Codequalität ist nur ein Unterbegriff dieses Ziels
Die Geschwindigkeit des Codeschreibens ist in Situationen mit hohem Risiko nicht der Flaschenhals
Manchmal ist es besser, langsam zu planen und die Folgen gründlich zu bedenken
Wenn man zum Beispiel wie in der AI-Industrie riesige Systeme zu schnell baut, kann das ein zivilisatorisches Risiko in die falsche Richtung erzeugen
Bei einem kleinen Spiel, das man allein am Wochenende baut, spielt das dagegen keine Rolle. Letztlich bestimmt die Größe des Risikos das Tempo