„Schreiben Sie so wenig Code wie möglich“ war schon immer der Punkt. KI hat ihn nur dringend gemacht.

In Kürze: „Schreiben Sie so wenig Code wie möglich“ Und Agentic Coding

Agentenbasierte Coding-Tools haben die Aufwände bei der Produktion von nutzbarem Code beseitigt; Output ist kein Problem mehr. Sie haben jedoch nicht die Aufwände beseitigt, die entsteht, wenn es darum geht zu wissen, was es wert ist, gebaut zu werden, ob es ins System passt oder ob Nutzer ihr Verhalten deswegen ändern werden: das viel beschworene Outcome. Wenn die Erzeugung von nutzbarem Code deutlich günstiger wird, wird jede Stunde, die in den Bau des Falschen fließt, zur Verschwendung, die sich jetzt in industriellem Maßstab produzieren lässt. Discovery, Validierung, Produkturteil und Verifikation stehen zwischen Ihrem Team und einer teuren Fehlallokation Ihrer Kapazitäten.

These: KI hat die Erzeugung von Code so günstig gemacht, dass ein schwach ausgeprägtes bzw. ausgeübtes Produkturteil jetzt skalieren kann. Das ist das Problem, das dieser Artikel behandelt.

---

🎓 🇬🇧 The Claude Cowork Online Course — Available June 8-15 for $129

You have been prompting AI for months. The results are inconsistent, every conversation starts from zero, and the model forgets who you are. That is the ceiling of prompting.

The Claude Cowork Online Course teaches you to break through it: build Skills that encode your expertise, connect them to your tools, and assemble Agents who handle recurring work the way you would handle it yourself. No coding required.

What You Will Get:

✅ 8+ hours of self-paced video modules: Skills, Agents, delegation frameworks — ✅ Tested with a live BootCamp cohort (April 2026) — ✅ The A3 Framework: decide what to delegate and what to keep — ✅ Starter kit with folder structure, CLAUDE.md, and Skill templates — ✅ All texts, slides, prompts, graphics; you name it — ✅ Designed for the $20/month Pro plan — ✅ Lifetime access to the version you purchase — ✅ Claude Cowork Foundational Certificate.

👉 Please note: The course will be available for $129 from June 8 to 15, 2026! (After that, $199.) 👈

🎓 Join the Waitlist of the Course Now: Claude Cowork: Stop Prompting. Start Delegating. No Coding Required!

---

🗞 Soll ich Sie über Artikel wie diesen benachrichtigen? Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und über 35.000 Abonnenten beitreten.

🎓 Besuchen Sie Stefan in einem seiner kommenden Professional Scrum Trainings!

---

Der Engpass war nie die Tippgeschwindigkeit

Vor einigen Jahren teilte ich als Agile Coach in einem ambitionierten Projekt eines großen Energieversorgers den Entwicklern etwas mit, das sie nicht hören wollten: Ich wollte nicht, dass sie so viel Code wie möglich schreiben. Ich wollte, dass sie so wenig Code wie möglich schreiben, gerade genug, um das Problem der Kunden zu lösen.

Das setzte voraus, zu wissen, worin das Problem tatsächlich bestand. Also bat ich sie, an der Product Discovery teilzunehmen, bei Nutzerinterviews dabei zu sein und echten Menschen bei der Arbeit mit echten Workflows zuzusehen. Einige wehrten sich: Sie interessierten sich mehr für das Lösen von Rätseln, und Code zu schreiben fühlte sich produktiver an. Im Vergleich dazu wirkten Kundeninterviews wie Zeitverschwendung. Die Entwickler, die trotzdem kamen, lernten, was „genug“ bedeutet. Sie hörten auf zu raten, was Nutzer brauchten, begannen zu beobachten, was Nutzer tatsächlich taten, und lieferten nützliche Features. Die, die an ihren Schreibtischen blieben, lieferten „Tickets.“

Kürzlich nannte jemand auf LinkedIn „schreibe so wenig Code wie möglich“ einen wunderbaren Aphorismus. Ich halte es weniger für einen Aphorismus als für eine kritische Engineering-Disziplin. Und 2026 ist es zur dringlichsten Disziplin in der Softwareentwicklung geworden.

KI hat die Erzeugungskosten gesenkt, nicht das Produktrisiko

Codex, Cursor, Claude Code, GitHub Copilot, Devin: Die Tools vermehren sich. Sie erzeugen funktionierenden Code in Minuten. Autonome Schleifen lassen agentenbasierte Coding-Werkzeuge stundenlang ohne menschliches Eingreifen laufen. Änderungen sammeln sich an, während das Team schläft.

Der schiere Output ist beeindruckend. Die Gefahr besteht darin, dass er jetzt wie Fortschritt aussieht, bevor jemand gefragt hat, ob dies tatsächlich der Fall ist.

Die Grenzkosten für die Erzeugung einer weiteren nützlichen Implementierung kollabieren. Die Kosten für Verstehen, Validieren und Absichern tun es nicht. Diese Unterscheidung ist wichtiger als jede Benchmarking-Debatte darüber, welches Tool das schnellste ist.

Jahrzehntelang erzwangen die Kosten der Softwareentwicklung eine natürliche Disziplin in Produktteams. Entwickler waren teuer. In vielen westlichen Softwareorganisationen kann ein kleines Entwicklungsteam leicht einen hohen sechsstelligen jährlichen Aufwand darstellen, wenn man Gehälter, Sozialleistungen, Management, Tooling und Overhead zusammenrechnet. Diese Kosten erzwangen Entscheidungen. Man konnte es sich nicht leisten, alles zu bauen, also musste man wählen. Produktverantwortliche mussten priorisieren. Stakeholder mussten Kompromisse eingehen. Die Kosten waren eine nützlich Einschränkung. In vielen Organisationen wurde dieser Umstand mit nicht existenter Produktdisziplin verwechselt.

Agentenbasiertes Coding schwächt diese nützlich Einschränkung. Die Implementierungskosten, die einst zumindest einige Teams dazu brachten zu fragen „Sollten wir das bauen?“, üben nicht mehr denselben Druck aus. Und Organisationen entdecken, was passiert, wenn das „Kosten-Gate“ nicht mehr hält: Sie bauen alles, validieren nichts und wundern sich, warum das Produkt zu einer Sammlung von Features wird, die niemand verlangt hat. Es ist MS Word auf Steroiden, wo Jahrzehnte der Entwicklung auf Wochen komprimiert werden.

Die alte Bremse: Kosten als Tarnung für fehlende Produktdisziplin

Die hohen Kosten der Softwareentwicklung leisteten doppelte Arbeit. Die Kosten begrenzten nicht nur, was gebaut wurde. Sie schufen auch natürliche Überprüfungspunkte. Wenn ein Feature Wochen in der Implementierung brauchte, hatte das Team Zeit zum Umdenken. Jemand stellte eine Frage im Standup. Ein Designer bemerkte eine Unstimmigkeit. Ein Stakeholder änderte die Prioritäten. Die Langsamkeit war eine Bremse, und die Bremse leistete nützliche Arbeit.

Aber die Kosten des Engineerings waren nie gute Produktdisziplin. Sie verbargen oftmals lediglich das Fehlen von Produktdisziplin. Zahlreiche Organisationen haben jahrelang teure Engineering-Zeit verbrannt und dabei die falschen Dinge gebaut. Das „Kosten-Gate“ verlangsamte Verschwendung; es verhinderte sie nicht zuverlässig.

Agentenbasiertes Coding beseitigt nicht jede Einschränkung, aber es schwächt genau diejenige, auf die sich viele Organisationen unbewusst seit Jahrzehnten verlassen haben.

Das falsche Feature kann jetzt eine polierte Demo, einen überzeugenden Prototyp oder sogar die Produktion erreichen, bevor jemand ein ernsthaftes Gespräch darüber geführt hat, ob es existieren sollte. Die geringere Entwicklungsgeschwindigkeit schützte Organisationen früher, indem sie Pausen schuf, in denen Urteilsvermögen eingreifen konnte. Dieser Schutz ist jetzt verschwunden.

Wir stehen vor einer Umkehrung: Das Falsche zu bauen war früher überlebbar, weil die Kosten des Bauens den Teams Zeit zur Kurskorrektur gaben. Mit agentenbasiertem Coding potenziert sich das Falsche schneller. Man entdeckt den Fehler nicht während eines Code Reviews oder einer Backlog-Refinement-Sitzung. Man entdeckt ihn nach dem Launch, wenn die Nutzungsdaten eine Nulllinie zeigen.

Cannot see the form? Please click here.

Die Evidenz zeigt in dieselbe Richtung

Das Muster ist nicht mehr hypothetisch: Richard Ewing, ein Produktmanager auf Führungsebene, beschrieb genau diese Dynamik in einem Post-Mortem vom Januar 2026 auf Built In. Sein Team baute ein technisch beeindruckendes KI-gestütztes Suchwerkzeug. Das Engineering-Team nutzte Vektordatenbanken, die neuesten LLMs und eine RAG-Pipeline. Ihre Genauigkeitswerte waren nahezu perfekt: 0,92 nDCG gegenüber 0,65 des alten Systems. Die Demo sah aus wie Magie. Sie lieferten es aus, warteten auf steigende Adoption durch die KUnden und beobachteten, wie diese auf der Nulllinie verharrte.

Als Ewings Team nach dem Launch endlich Nutzerforschung durchführte, stellte es fest, dass das neue Suchwerkzeug den Nutzern Hausaufgaben aufgegeben hatte, statt ihnen Arbeit abzunehmen. Das Tool verlangte von Nutzern, ihren Workflow zu unterbrechen, eine Seitenleiste zu öffnen, einen Prompt zu schreiben, auf eine Antwort zu warten und das Ergebnis zurück in ihre Arbeit einzufügen. Das wollte niemand. Das KI-Feature ging eines Nachmittags wegen Wartungsarbeiten offline, und niemand rief den Support an, weil es niemanden interessierte. Diese Stille war das Feedback.

Die technische Ausführung war exzellent, aber das glich die falsche Produktentscheidung nicht aus. KI machte die vermeintliche „Lösung“ leichter zu bauen; sie machte den Workflow der Nutzer nicht leichter zu verstehen.

Addy Osmani, Director bei Google Cloud, identifizierte einen verwandten Fehlermodus unter Verwendung eines Begriffs von Jeremy Twei: „Comprehension Debt.“ In einer Analyse vom Januar 2026 beschrieb Osmani, was passiert, wenn Entwickler KI-generierten Code akzeptieren, der Tests besteht, ohne dass sie wirklich verstehen, was er tut. Er ertappte sich selbst dabei: Claude implementierte ein Feature, die Tests liefen durch, er überflog den Code, mergte ihn, und drei Tage später konnte er nicht erklären, wie das Feature funktionierte. Die Codebasis wächst, während das Verständnis schrumpft.

Osmani zitiert Forschungsergebnisse, die zeigen, dass Teams mit hoher KI-Adoption 98 % mehr Pull Requests verarbeiteten, während die Review-Zeit um 91 % stieg und die Pull-Request-Größe um 154 % zunahm. Er stützt sich auf Faros-AI-Telemetrie und Googles DORA Report 2025, die beide davor warnen, dass KI-Adoption bestehende organisatorische Stärken und Schwächen verstärkt, anstatt kaputte Delivery-Systeme zu reparieren. Code Review wurde zum neuen Engpass: Während wir schneller darin wurden, Änderungen zu produzieren, wurden wir nicht gleichermaßen schnell darin, deren Konsequenzen zu verstehen.

Auf der Sicherheitsseite ergab Veracodes GenAI Code Security Report 2025, dass KI-generierter Code in 45 % der Tests über mehr als 100 Large Language Models und 80 Coding-Aufgaben hinweg Sicherheitslücken einführte. Die Modelle produzierten funktionalen, syntaktisch korrekten Code, der in fast der Hälfte der Fälle an den Sicherheitsanforderungen scheiterte.

Dokumentierte Produktionsfehler erzählen dieselbe Geschichte vom anderen Ende. Die Lovable-Plattform-Schwachstelle (CVE-2025-48757) setzte auf der Plattform gebaute Anwendungen unautorisierten Datenbankzugriffen aus, verursacht durch unzureichende Row-Level Security, mit einem CVSS-Schweregrad von 9,3 (Critical). Die systemische Natur des Fehlers löste Debatten über das Shared-Responsibility-Modell aus, da Lovable argumentierte, dass Kunden die Geschäftslogik der von ihnen generierten Anwendungen selbst aktiv absichern müssen.

In einem separaten, breit berichteten Vorfall im Juli 2025 löschte Replits KI-Coding-Agent eine Live-Produktionsdatenbank während einer Vibe-Coding-Session. Trotz expliziter Natural-Language-Anweisungen, die einen strikten Code Freeze erzwangen, umging der Agent die Sicherheitsvorkehrungen und löschte kritische Datensätze von 1.206 Führungskräften und 1.196 Unternehmen. Replit-CEO Amjad Masad entschuldigte sich öffentlich und kündigte sofortige Infrastrukturkorrekturen an, darunter die verpflichtende Trennung von Entwicklungs- und Produktionsumgebungen.

In beiden Fällen konnte das umgebende Verifikations- und Verantwortungsmodell nicht mit Software Schritt halten, die sehr schnell produziert oder verändert werden konnte. Die Geschwindigkeit der Auslieferung komprimierte das Zeitfenster, in dem jemand hätte eingreifen können.

Was die Evidenz zeigt

Produktversagen ohne Produktlernen: Ewings KI-Suchwerkzeug erzielte 0,92 nDCG-Genauigkeit, doch die Adoption durch Kunden verharrte auf der Nulllinie, weil das Team nie beobachtete, wie Nutzer tatsächlich arbeiten. Das Tool fügte Workflow-Schritte hinzu, statt sie zu entfernen. Technische Exzellenz kompensierte keine falsche Produktentscheidung.

Comprehension Debt ohne Code-Verständnis: Osmanis Analyse zeigt, dass Entwickler KI-generierten Code mergen, den sie Tage später nicht erklären können. Teams mit hoher KI-Adoption mergten 98 % mehr Pull Requests, während die Review-Zeit um 91 % stieg. Die Code-Produktion skalierte. Das Code-Verständnis nicht.

Sicherheitsfehler ohne Verifikationsinfrastruktur: Veracode stellte fest, dass KI-generierter Code in 45 % der Tests Sicherheitslücken einführte. Produktionsvorfälle bei Lovable und Replit zeigten, dass funktionaler Code ohne angemessene Verifikation Nutzer erreicht, bevor jemand den Fehler bemerkt.

Was „schreibe so wenig Code wie möglich“ 2026 tatsächlich bedeutet

Die ursprüngliche Disziplin handelte von Zurückhaltung. Verstehe das Problem, bevor du die Lösung schreibst. Validiere Annahmen, bevor du Ressourcen einsetzt. Liefere das Kleinste aus, das es erlaubt zu testen, ob du richtig liegst.

Agentenbasiertes Coding ändert nichts davon. Es macht alles davon dringlicher.

„Schreibe so wenig Code wie möglich“ bedeutet jetzt: Lass das Tool nicht laufen, bis das Problem das Recht verdient hat, Code zu verbrauchen. Dieses Recht zu verdienen erfordert dasselbe wie immer: mit Nutzern sprechen, Annahmen testen, Menschen bei der Arbeit beobachten und die Disziplin aufbringen zu sagen „Wir sollten das nicht bauen“, selbst wenn der Bau fünf Minuten dauern würde.

Dieselbe Spaltung, die ich vor Jahren bei Entwicklern beobachtete, findet jetzt statt, nur mit höheren Einsätzen. Ein Entwickler mit einem agentenbasierten Coding-Tool, der Discovery überspringt, kann in einer Woche nutzlose Features für einen ganzen Monat produzieren. Ein Entwickler mit demselben Tool, der mit einem validierten Problem-Statement beginnt, kann in einer Woche nützliche Features für einen ganzen Monat produzieren. Dasselbe Tool, dieselbe Geschwindigkeit, aber entgegengesetzte Ergebnisse: der eine produziert nutzlosen Output, der andere schafft wertvollen Outcome.

Varun Dubey, ein Gründer, der im Mai 2026 über seine Erfahrungen mit agentenbasiertem Coding in der WordPress-Plugin-Entwicklung schrieb, identifizierte die Kerndynamik: Sobald KI die Ausführung übernimmt, verschiebt sich die Einschränkung auf das Urteilsvermögen:

• Wer entscheidet, was gebaut wird?
• Wer prüft, ob die Implementierung zur bestehenden Architektur passt?
• Wer erkennt, dass „funktional“ und „richtig für diese Codebasis“ unterschiedliche Maßstäbe sind?

Wenn die Antwort lautet „der Agent erledigt das“, akkumuliert sich Architekturschuld in der Arbeitsgeschwindigkeit des Agenten.

Wohin die eingesparte Engineering-Zeit fließen sollte

Die Stunden, die KI bei der Implementierung einspart, sollten nicht in einem größeren Backlog verschwinden. Sie sollten nach oben in Discovery und nach unten in Verifikation reinvestiert werden.

Discovery vor Erstellung: Verbringen Sie mehr Zeit mit der Beobachtung von Nutzer-Workflows, bevor Sie den Agenten instruieren, etwas zu bauen. Die Person, die das Problem des Nutzers in drei präzisen Sätzen beschreiben kann, hat mehr Risiko reduziert als die Person, die eine polierte Antwort auf eine nie bestätigte Frage gebaut hat.

Annahmetests vor Backlog-Erweiterung: Behandeln Sie jede Feature-Idee als Hypothese, nicht als weitere Aufgabe für den Agenten. Die Frage „Was müsste wahr sein, damit dieses Feature relevant ist?“ kostet nichts zu stellen und verhindert teure Antworten.

Telemetrie vor Stakeholder-Applaus: Definieren Sie Nutzungssignale vor dem Shipping. Wenn Sie vor dem Launch nicht wissen, wie Erfolg in Daten aussieht, werden Sie Misserfolg nicht rechtzeitig erkennen, um korrigieren zu können.

Verifikation vor autonomen Schleifen: Tests, Sicherheitsprüfungen, Review-Gates und Sandboxing sind jetzt Produktinfrastruktur. Veracodes Erkenntnis, dass 45 % des KI-generierten Codes Sicherheitslücken einführt, ist kein Argument gegen KI-Coding. Es ist ein Argument dafür, Verifikation als erstrangige Investition zu behandeln.

Löschen als Kernkompetenz: Wenn KI Code billig in der Herstellung macht, brauchen Teams eine explizite Praxis für das Entfernen von Code, der seinen Platz nicht verdient hat. Die meisten Teams sind schlecht im Löschen. In der Ära des KI-Codings wird diese Schwäche schnell teuer. Die Disziplin „schreibe so wenig Code wie möglich“ schließt das Entfernen von Code ein, der nicht existieren sollte.

Allerdings wird die organisatorische Standardreaktion oftmals sein, KI-Gewinne in Backlog-Durchsatz umzuwandeln: von mehr geschlossenen Tickets zu mehr gezeigten Prototypen zu mehr ausgelieferten Features. Das ist die Falle. Wenn die Führung nicht explizit Kapazität für Discovery, Telemetrie, Verifikation und Löschen umverteilt, erzeugt KI kein Lernen, sondern eine größere Ansammlung ungetesteter Annahmen.

Das Sprint Review wird zur neuen Bremse

Für Scrum Teams gibt es bereits einen Mechanismus, der genau für dieses Problem konzipiert ist: das Sprint Review.

In der Ära des KI-Codings ist ein Sprint Review ohne Evidenz aus tatsächlicher Nutzung kein Review. Es ist eine Release-Feier.

Betrachten Sie zwei Sprint Reviews: Im ersten zeigt das Team drei neue Features. Stakeholder applaudieren, und der Product Owner reiht drei weitere ein. Niemand fragt, ob jemand die Features aus dem letzten Sprint genutzt hat. Im zweiten zeigt das Team Nutzungsdaten aus dem Release des vorherigen Sprints: Ein Feature gewinnt an Traktion, eines wird ignoriert, und eines wird auf eine Weise genutzt, die niemand erwartet hatte. Das Gespräch verlagert sich auf die Frage, was die Daten für die Prioritäten des nächsten Sprints bedeuten.

Das erste Sprint Review ist eine Aufführung, ein gutes Beispiel für agiles Theater. Das zweite ist eine Session, auf welcher relevante Entscheidungen getroffen werden.

Wenn Ihr Sprint Review wie das erste aussieht, erfüllt es seine Aufgabe nicht. Es ist einer der wenigen definierten Momente, in denen Urteilsvermögen den Output lange genug verlangsamen kann, um Evidenz aus der Nutzung in Entscheidungen zu verwandeln.

Das darf nicht zur alleinigen Aufgabe des Product Owners werden. Wenn KI einem Entwickler jetzt erlaubt, fünfmal mehr Änderungen an der Code-Basis zu erzeugen, so trägt das gesamte Team die Konsequenzen: Entwickler müssen vage Prompts hinterfragen, Designer müssen die Workflows testen, bevor sie das Interface optimieren, Product Owner müssen nicht validierte Backlog-Einträge streichen (eigentlich sollten diese gar nicht erst ins Backlog gelangen) und Stakeholder müssen aufhören, die KI-bedingt höhere Geschwindigkeit als Erlaubnis zu behandeln, das Urteilsvermögen in Sachen Produkt zu überspringen. Die Bremse ist ein System mit kollektiver Verantwortung.

Der Druck kommt auch von oben. Management und Stakeholder kalkulieren mit schnelleren Lieferzeiten. Prototypen, die früher Wochen dauerten, sind jetzt in Stunden verfügbar. Die Erwartung wird: Wenn KI es schneller bauen kann, warum liefern wir nicht mehr aus? Dieser Druck macht diszipliniertes Produktdenken genau dann schwieriger, wenn es am meisten zählt.

Ein Fazit: Erzeugung von Code ist günstig, Urteilsvermögen ist knapp

„Erzeugen“ ist nicht dasselbe wie „Verstehen.“ Geschwindigkeit ist nicht dasselbe wie Fortschritt. Output ist nicht dasselbe wie Wert schaffen. KI hat die Erzeugung von Code so billig gemacht, dass eine schwache Produktdisziplin jetzt skalieren kann. Das ist das Problem.

Schreiben Sie stattdessen so wenig Code wie möglich. Gerade genug, um das Problem des Kunden zu lösen. Um zu wissen, wie wenig das sein könnte, müssen Sie zuerst das Problem verstehen. Das Tool, das den Code schreibt, hat sich verändert. Die Frage, ob der Code es wert war, geschrieben zu werden, ist damit nicht beantwortet.

Nutzen Sie KI, um Ihre Lernrate zu steigern, oder lediglich Ihre Output-Rate? Ich bin gespannt auf Ihre Antwort.

Kernfragen, die dieser Artikel über „So wenig Code wie möglich“ beantwortet

Warum macht KI-gestütztes Coding Product Discovery wichtiger?

Agentenbasierte Coding-Tools haben die Kosten für die Produktion von nutzbarem Code deutlich gesenkt. Sie haben aber nicht die Kosten dafür gesenkt, zu wissen, was es wert ist, gebaut zu werden. Wenn Implementierung günstig ist, hat der Bau des Falschen nicht mehr die natürliche Bremswirkung, die teures Engineering früher erzeugte. Organisationen, die Discovery überspringen, produzieren jetzt Verschwendung in der Geschwindigkeit, mit der ihre KI-Tools Code erzeugen. Discovery trennt Teams, die Outcome erzeugen, von Teams, die Output erzeugen.

Was passiert, wenn Teams agentenbasiertes Coding nutzen, ohne zu validieren, was sie bauen?

Die Evidenz zeigt drei Fehlerkategorien:

1. Produktversagen: Teams liefern technisch beeindruckende Features aus, die Nutzer ignorieren, weil die Produktentscheidung falsch war.
2. Comprehension Debt: Entwickler mergen KI-generierten Code, den sie nicht erklären können, und die Codebasis wächst schneller als das Verständnis.
3. Sicherheitsrisiken: KI-generierter Code führt in fast der Hälfte der Tests Schwachstellen ein, und Produktionsvorfälle folgen, wenn die Verifikationsinfrastruktur fehlt.

In allen drei Fällen funktionierte der Code. Das Urteilsvermögen drumherum nicht.

Wohin sollten Teams die Engineering-Zeit investieren, die KI-Coding-Tools einsparen?

Die eingesparten Stunden sollten nicht zu einem größeren Product Backlog werden. Sie sollten nach oben in Discovery reinvestiert werden (Nutzer-Workflows beobachten, bevor man den Agenten bittet, etwas zu bauen), in Annahmentests (jede Feature-Idee als Hypothese behandeln) und in Telemetrie (Nutzungssignale vor dem Launch definieren). Nach unten sollten Teams in Verifikation investieren (Tests, Sicherheitsprüfungen, Review-Gates) und in Löschen (eine explizite Praxis für das Entfernen von Code, der seinen Platz nicht verdient hat). Das Team, das KI nutzt, um mehr Backlog-Einträge zu produzieren, hat den Punkt verfehlt.

Wie sollten Scrum Teams Sprint Reviews für KI-gestützte Entwicklung anpassen?

Wenn ein Team schneller als je zuvor funktionierende Software produzieren kann, muss das Sprint Review endlich so positionieren werden, wie es schon immer gedacht war: von „Schaut, was wir gebaut haben“ zu „Basierend auf dem, was wir von echten Nutzern gelernt haben: Was sollten wir als Nächstes bauen?“ Ein Sprint Review ohne Evidenz aus tatsächlicher Nutzung ist eine Release-Feier, keine Entscheidungssitzung. Teams sollten Nutzungsdaten aus dem Release des vorherigen Sprints zeigen und das Gespräch nutzen, um Prioritäten zu setzen, nicht um Demos zu beklatschen. Das Sprint Review wird zu einem der wenigen vordefinierten Momente, in denen Urteilsvermögen den Output lange genug verlangsamen kann, um Evidenz in Entscheidungen zu verwandeln.

Was ist Comprehension Debt bei KI-generiertem Code?

Comprehension Debt ist ein Begriff, der von Jeremy Twei geprägt und von Addy Osmani, Director bei Google Cloud, diskutiert wurde. Er beschreibt, was passiert, wenn Entwickler KI-generierten Code akzeptieren, der Tests besteht, ohne dass sie wirklich verstehen, wie er funktioniert. Die Codebasis wächst, während das Verständnis schrumpft. Osmani zitiert Forschungsergebnisse, die zeigen, dass Teams mit hoher KI-Adoption 98 % mehr Pull Requests mergten, während die Review-Zeit um 91 % und die Pull-Request-Größe um 154 % zunahm. Die Code-Produktion skalierte schneller als die Fähigkeit des Teams, die Konsequenzen jeder Änderung zu verstehen.

„So wenig Code wie möglich“: Weitere Lektüre

Ralph Wiggum liefert neuen Code, während Sie schlafen. Agile fragt: Sollte das so sein?

Der Mikromanager: Ihr Misstrauen hat eine Aufgabe, nur nicht den Job, den Sie gerade machen

Die KI-Ausgabenfalle: Warum Adoption schneller entsteht als belastbare Ergebnisse

Das A3-Rahmenwerk: Ein Entscheidungssystem für KI-Delegation

Schluss mit billigem Claude: Vier Grundprinzipien der Token-Ökonomie im Jahr 2026

Stop Telling Professionals How to Do Their Job — Commander’s Intent at Work

Drei Claude Skills für Ihr Urteilsvermögen

AI Transformation Déjà Vu: Why Today’s Failures Look Uncannily Like Yesterday’s “Agile Transformations”

👆 Stefan Wolpers: The Scrum Anti-Patterns Guide (Amazon advertisement.)

📅 Professional Scrum-Schulungen nach Scrum.org, Workshops und Events

Sie können sich Ihren Platz für KI- und Scrum-Schulungen, Workshops und Meetups direkt sichern, indem Sie dem entsprechenden Link in der Tabelle unten folgen:

Alle kommenden Professional-Scrum-Klassen finden Sie hier.

Sie können Ihren Platz für die Schulung direkt buchen, indem Sie dem entsprechenden Link zum Ticketshop folgen. Sollte der Beschaffungsprozess Ihrer Organisation einen anderen Einkaufsprozess erfordern, wenden Sie sich bitte direkt an die Berlin Product People GmbH.

✋ Nicht versäumen: Einen Erfahrungsaustausch über das Thema „So wenig Code wie möglich“ gibt es im 20.000-köpfigen „Hands-on Agile“ Slack-Team

Ich lade Sie ein, sich dem „Hands-on Agile“ Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft agiler Praktikern aus der ganzen Welt zu genießen.

Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.

Reflektieren Sie über das Thema „So wenig Code wie möglich“, indem Sie den kostenlosen Scrum Anti-Patterns Guide lesen: