Ich habe vor Kurzem eine komplette funktionierende Anwendung weggeworfen.

Nicht weil sie nicht funktioniert hat. Sie hat funktioniert. Fast alles. Jede einzelne Funktion ließ sich aufrufen, jede Eingabe wurde verarbeitet, jeder Output kam zurück wie er sollte.

Das Problem war ein anderes. Alles hat für sich funktioniert. Aber nichts hat zusammen ein Problem gelöst.

Ich hatte Features. Aber kein Produkt.

Wer das Ganze benutzen sollte, fand sich in einer Sammlung von Möglichkeiten wieder, ohne klaren Pfad. Ich hatte den User, für den ich angefangen hatte zu bauen, unterwegs aus dem Blick verloren. Nicht aus Nachlässigkeit. Sondern weil das Bauen so einfach war, dass es das Auswählen ersetzt hat.

Das ist die Geschichte hinter diesem Artikel. Aber sie ist nicht meine Geschichte allein. Sie passiert gerade tausendfach in Solo-Projekten, in Agenturen, in Entwicklungsabteilungen. Und sie ist symptomatisch für etwas, das viel größer ist als ein einzelner Wegwurf.

Um zu verstehen was sich gerade verändert, muss man zuerst verstehen was früher funktioniert hat — und warum.

Wer in den letzten dreißig Jahren Software gebaut hat, hat das in einem System getan, in dem jede neue Funktion einen Preis hatte. Spezifikation kostete Zeit. Implementierung kostete Wochen. Tests kosteten noch einmal so lange. Code Review band Senior-Entwickler. Refactoring band sie noch einmal. Alles zusammen ergab eine Reibung, die viele für ein Übel gehalten haben — etwas, das man möglichst klein halten will.

In Wahrheit war diese Reibung der wichtigste Qualitätsmechanismus den wir hatten.

Sie hat zu Gesprächen gezwungen. Bevor jemand zwei Wochen in eine Funktion investiert, fragt das Team: Brauchen wir das wirklich? Was bringt es dem User? Lohnt es sich gegenüber den drei anderen Funktionen, die auch noch warten? Sind wir sicher, dass wir das Problem richtig verstanden haben?

Die Antwort war oft nein. Und genau das war der Punkt. Das Nein hat das Produkt fokussiert gehalten.

Sprint Planning, Backlog-Grooming, Architektur-Reviews, das gesamte Vokabular agiler Entwicklung — all das war im Kern ein einziger riesiger Filter. Ein Filter, dessen Funktionsweise davon abhing, dass Bauen teuer ist. Wenn etwas wenig kostet, lohnt sich auch der Filter nicht. Niemand veranstaltet ein Architektur-Meeting für eine Funktion, die in zwei Stunden fertig ist.

Genau das ist passiert.

Mit Cursor, Lovable, Claude Code, GitHub Copilot Workspace — wie auch immer das Werkzeug heißt, das Sie gerade benutzen — ist eine neue Funktion in Stunden implementiert. Manchmal in Minuten. Eine Idee, ein Prompt, ein Pull Request.

Was alle Diskussionen über diese Werkzeuge übersehen, ist Folgendes: Sie haben nicht nur die Implementierung billiger gemacht. Sie haben die gesamte Schicht drumherum mit weggeräumt.

Spezifikation? Reicht ein Prompt. Code Review? Macht das Tool gleich mit. Tests? Kann es generieren. Refactoring? Eine Frage. Dokumentation? Auch.

Das alles, was den Filter ausgemacht hat, ist genauso billig geworden wie das Bauen selbst. Und damit ist der Filter in sich zusammengefallen.

Die Frage „Sollten wir das bauen?" stellt sich nicht mehr automatisch — weil sie nirgendwo mehr im Prozess verankert ist. Es gibt keinen Moment mehr, in dem man innehält, weil es zu teuer wird, einfach weiterzumachen.

Das ist der eigentliche Mechanismus, und er hat einen Namen verdient.

Solange Bauen Aufwand bedeutete, war die Standardfrage: Können wir uns das leisten? Diese Frage erzwang automatisch eine zweite: Sollen wir das überhaupt? Die zweite ergab sich aus der ersten.

Heute ist die erste Frage in vielen Fällen trivial geworden. Das Können ist gegeben. Aber die zweite Frage erscheint deshalb nicht von selbst. Sie war nie eine eigenständige Frage — sie war ein Nebenprodukt des Aufwands.

Und so passiert das, was bei mir passiert ist: Man baut, weil man kann. Man baut, weil es faszinierend ist, wie einfach es geht. Man baut, weil eine Idee aufkommt und vier Stunden später als funktionierender Code im Repository liegt. Was vorher eine Diskussion gewesen wäre, ist jetzt einfach eine Implementierung.

Können hat das Sollen ersetzt. Das ist kein Disziplinproblem. Das ist ein strukturelles Problem.

In der Software-Entwicklung gibt es drei Begriffe, die jetzt aktueller sind als je zuvor — und gleichzeitig anders verstanden werden müssen als bisher.

Feature Creep war früher der Vorwurf an schlechtes Produktmanagement. An ein Team, das nicht klar genug priorisiert. An Stakeholder, die nicht Nein sagen können. Heute ist Feature Creep keine Frage des Managements mehr — es ist eine Frage der wegfallenden Reibung. Selbst ein perfekt geführtes Team produziert Feature Creep, wenn der natürliche Filter nicht mehr greift.

Code Debt durch Exploration ist der neue Bruder der klassischen technischen Schuld. Es ist nicht der Code, der schnell und schlampig geschrieben wurde. Es ist der Code, der sauber implementiert wurde — aber nie produktiv geworden ist. Funktionen, die jemand ausprobiert hat, weil es ging. Die im Repository liegen, weil niemand sie löscht. Die Tests haben, weil das Tool sie generiert hat. Die niemand mehr anfasst, weil keiner mehr weiß ob jemand sie nutzt.

YAGNI — You Ain't Gonna Need It — war drei Jahrzehnte lang eine Best Practice der agilen Entwicklung. Die Kernidee: bau nichts, was du nicht jetzt brauchst. Bisher war das eine Empfehlung, eine kluge Disziplin. Jetzt wird sie zur Überlebensstrategie. Wer keinen Mechanismus hat, der das Sollen aktiv durchsetzt, wird unter dem eigenen Können zusammenbrechen.

Vier Symptome, die fast jedes Solo- und Team-Projekt entwickelt, sobald die Reibung weggefallen ist:

Erstens: Das Verhältnis von genutzten zu vorhandenen Features wird absurd. Vierzig Funktionen, von denen acht regelmäßig verwendet werden. Der Rest existiert. Niemand weiß warum.

Zweitens: Code-Leichen. Module, die niemand anfasst, weil niemand mehr weiß ob sie noch live sind. Aus Vorsicht bleibt alles drin. Aus Vorsicht wächst die Codebase.

Drittens: Die Codebase wird schwer zu verstehen — nicht durch komplizierte Logik, sondern durch schiere Masse. Wer neu dazukommt, muss sich durch Schichten von Funktionalität arbeiten, die niemand mehr erklären kann.

Viertens: Das Kernprodukt geht in der Aufmerksamkeit aller Beteiligten unter. Bei Demos zeigt man die neuesten Features, nicht das Kernproblem. Bei Verkaufsgesprächen erklärt man die Möglichkeiten, nicht den Nutzen. Bei Diskussionen im Team geht es um den nächsten Build, nicht um den User.

Wer in seinem eigenen Projekt zwei oder drei dieser Symptome erkennt — der ist bereits dort.

Hier ist der Punkt, den die meisten Diskussionen über KI-Produktivität übersehen.

KI macht Entwickler schneller. Das ist messbar, das ist real, und das wird sich nicht zurückdrehen lassen. Gleichzeitig produziert dieselbe KI Produkte, die langsamer werden — nicht weil ihr Code schlechter wäre, sondern weil sie unter ihrer eigenen Komplexität zusammenbrechen.

Mehr Code in weniger Zeit ist nicht automatisch besseres Produkt. In vielen Fällen ist es das Gegenteil. Der Grenznutzen einer zusätzlichen Funktion wird irgendwann negativ. Die Anwendung wird nicht besser — sie wird schwerer. Schwerer zu verstehen, schwerer zu nutzen, schwerer zu erklären.

Das ist das Paradox von billigem Bauen: Je einfacher es wird, desto früher passiert dieser Punkt. Und desto unsichtbarer ist er, weil das individuelle Bauen sich produktiv anfühlt. Wer eine neue Funktion in zwei Stunden ausgeliefert hat, hat einen Erfolgsmoment. Dass er damit die Anwendung als Ganzes verschlechtert haben könnte, ist nirgendwo sichtbar — weil dieser Effekt erst beim hundertsten Feature anfängt zu wirken.

Die naheliegende Schlussfolgerung lautet: Senior-Entwickler und Product Owner werden unwichtiger, weil ja jetzt jeder bauen kann. Diese Schlussfolgerung ist falsch — und sie ist gefährlich.

Senior-Rollen werden nicht unwichtiger. Sie werden anders wichtig.

Senior-Entwickler waren in der alten Welt vor allem deshalb wertvoll, weil sie Code schreiben konnten, den andere nicht schreiben konnten. In der neuen Welt sind sie deshalb wertvoll, weil sie Nein sagen können — auf eine Weise die ein Junior nicht kann. Weil sie wissen, was passiert, wenn man bestimmte Dinge baut. Weil sie schon einmal eine Anwendung weggeworfen haben.

Product Owner waren in der alten Welt Verteiler von Aufwand. In der neuen Welt sind sie Verteiler von Aufmerksamkeit. Aufwand ist billig geworden. Aufmerksamkeit nicht. Was ein Team gemeinsam denkt — was im Backlog steht, was in den Demos gezeigt wird, was in den Reviews diskutiert wird — formt das Produkt mehr als jeder einzelne Pull Request.

Drei Fragen, die ein Team sich vor jeder neuen Funktion stellen sollte:

Wenn auch nur eine dieser Fragen unbeantwortet bleibt, sollte die Funktion nicht gebaut werden. Das ist keine bürokratische Hürde — das ist der Ersatz für den Filter, den die Werkzeuge weggenommen haben.

Was ich aus dem Wegwurf konkret mitgenommen habe und seitdem konsequent umsetze:

Ein Produkt löst ein Problem. Nicht zwei. Nicht eine Familie verwandter Probleme. Eines.

Jede Funktion muss dieses Problem besser lösen. Wenn eine Funktion das Problem nicht direkt besser löst, sondern „auch noch nützlich" ist — dann gehört sie nicht in dieses Produkt. Vielleicht in ein anderes. Aber nicht hier.

Das Verbot ist die Funktion. Die Disziplin, Funktionen nicht zu bauen, ist heute genauso wertvoll wie die Fähigkeit Funktionen zu bauen war. Vielleicht wertvoller. Wer sich diese Disziplin nicht selbst auferlegt, wird sie nicht haben — denn die Werkzeuge erzwingen sie nicht mehr.

Das klingt einfach. Es ist nicht einfach. Es widerspricht der ganzen Atmosphäre dessen, was gerade passiert. Wenn jeder um Sie herum begeistert davon erzählt, was er alles gebaut hat, fühlt es sich falsch an, weniger zu bauen.

Aber wenn Bauen billig wird, muss Denken teurer werden. Sonst ist am Ende kein Produkt da. Sondern ein Sammelsurium aus Möglichkeiten.

In den Debatten über KI-generierten Code geht es meistens um technische Probleme: Halluzinationen, Sicherheitslücken, fehlerhafte Datenbankabfragen, Compliance-Verstöße. Das sind reale Probleme, und sie sind ernst.

Aber das vielleicht unterschätzte Problem ist nicht technisch — es ist methodisch. Wenn Bauen aufhört wehzutun, hört das Auswählen auf zu existieren. Und ohne Auswahl wird jede Codebase irgendwann ein Sammelsurium statt ein Produkt.

Das gilt für Solo-Projekte genauso wie für Konzern-Codebases. Es gilt für Indie Hacker und für CTO-Teams. Es ist kein Problem schlechter Werkzeuge — die Werkzeuge sind sehr gut. Es ist ein Problem fehlender Filter, die früher in den Werkzeugen mit drin waren und jetzt nicht mehr drin sind.

Wer das nicht aktiv kompensiert, wird in zwölf Monaten vor einer Anwendung stehen, die alles kann und nichts wirklich gut. Und vielleicht steht die Frage dann an: wegwerfen oder weiterleiden?

Ich habe weggeworfen. Es war die richtige Entscheidung. Aber sie wäre vermeidbar gewesen — wenn ich den Filter früher aktiviert hätte, den die Werkzeuge nicht mehr von selbst mitbringen.