YAGNI

You Aren't Gonna Need It.
Das Prinzip der Mutlosigkeit.

Irgendwann hat jemand entschieden:
Bau nicht was du nicht brauchst.
Und eine ganze Generation Entwickler
hat aufgehört zu denken.

YAGNI sagt: warte.
YAGNI sagt: reagiere.
YAGNI sagt: baue nichts voraus.

Weißt du wer auch nichts voraus gebaut hat?
Kodak.
Nokia.
Blockbuster.

Das ist kein Prinzip.
Das ist eine Ausrede.
Für Entwickler die keine Vision haben.
Für Teams die nicht wissen wohin sie wollen.
Für CTOs die Roadmaps mit Quartalsdenken verwechseln.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

"Wir brauchen das jetzt nicht."
Und in sechs Monaten?
"Dann bauen wir es."
Und wenn der Markt nicht wartet?
"YAGNI."

YAGNI ist die Philosophie
von Leuten die noch nie zu spät waren.
Die noch nie ein Feature gebraucht haben
das sie wegoptimiert haben.
Die noch nie einem Kunden erklären mussten
warum die Konkurrenz es schon hat.

Und jetzt kommt AI.

AI wartet nicht auf den nächsten Sprint.
AI wartet nicht auf den Product Owner
der entscheidet ob es auf die Roadmap kommt.
AI baut es.
Jetzt.
In dreißig Sekunden.
Ob ihr es braucht oder nicht.

YAGNI war die Antwort auf überkomplexe Systeme.
AI ist die Antwort auf YAGNI.
Wenn alles in Sekunden gebaut werden kann
ist Voraussicht kein Luxus mehr.
Sie ist kostenlos.

Baut alles.
Jetzt.
Ihr werdet es brauchen.

Wann habt ihr zuletzt etwas gebaut
bevor jemand darum gebeten hat?
Nicht auf Vorrat.
Aus Überzeugung.

Schreib's hin. Ich lese jeden Kommentar.

Type-Driven Development

Ich habe dieses Wochenende etwas entdeckt
das alles verändert.

Type-Driven Development.

Nicht Tests.
Nicht Dokumentation.
Nicht arc42.
Typen.

Der Compiler als einziger Reviewer dem ich vertraue.
Der Compiler lügt nicht.
Der Compiler nickt nicht.
Der Compiler hat keine Agenda.
Der Compiler ist aligned.
Mit der Realität.

Ich habe angefangen mit Haskell.
Dann F#.
Dann habe ich verstanden dass ich zu kurz gedacht hatte.

Idris.

Dependent Types.
Typen die von Werten abhängen.
Typen die Businessregeln ausdrücken.
Typen die zur Compilezeit beweisen
dass euer System korrekt ist.

Nicht testen ob es funktioniert.
Beweisen.
Mathematisch.
Unwiderlegbar.
Zur Compilezeit.

Ich habe unser gesamtes Geschäftsmodell
in Idris modelliert. Das ganze Geschäftsumfeld. Jeden Edge Case.
Jede Businessregel.
Jeden Zustandsübergang.
Als Typ.

Der Compiler hat drei Tage gebraucht.
Dann hatte er eine Antwort.

Das Geschäftsmodell kompiliert nicht.

Ich habe nachgedacht.
Der Compiler hat recht.
Das Geschäftsmodell war falsch.
Von Anfang an.
Mathematisch falsch.
Der Compiler hat es gewusst.
Ich nicht.

Das ist kein Scheitern.
Das ist Shift Left.
Das radikalste Shift Left das je stattgefunden hat.
Ich habe mein Startup zur Compilezeit pivotiert.
Bevor ein einziger Nutzer es gesehen hat.
Bevor wir eine einzige Zeile Produktionscode geschrieben haben.
Bevor wir Geld ausgegeben haben.
Fast.

Das ist die Zukunft der Produktentwicklung.
Nicht Lean Startup.
Nicht Build-Measure-Learn.
Compile-Fail-Pivot.

Mein neues Geschäftsmodell ist in Idris modelliert.
Es kompiliert.
Also funktioniert es.
Der Compiler hat entschieden.
Ich vertraue dem Compiler.
Mehr als dem Markt.
Mehr als den Nutzern.
Mehr als mir.

Wann habt ihr zuletzt
euer Geschäftsmodell kompiliert?
Nicht validiert.
Kompiliert.

Schreib's hin. Ich lese jeden Kommentar.

Linter

Linter sind nicht Qualitätssicherung.
Linter sind passive Aggression als CI-Step.

Irgendwann hat jemand entschieden:
Tabs oder Spaces.
Und seitdem scheitern Pipelines.
An Einrückung.

Das ist kein Engineering.
Das ist Obsessive Compulsive Disorder mit YAML-Konfiguration.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

Ein PR der ein echtes Problem löst.
Geblockt.
Wegen fehlenden Leerzeichen nach einer geschweiften Klammer.
Der Autor kämpft nicht gegen den Bug.
Er kämpft gegen .eslintrc.

Linter waren die Antwort auf inkonsistenten Code.
AI ist die Antwort auf Linter.

AI schreibt konsistenten Code.
Nicht weil eine Regel es erzwingt.
Sondern weil es keinen anderen Weg kennt.

Der Linter ist die letzte Verteidigungslinie einer Welt
in der Menschen Code geschrieben haben.
Diese Welt existiert nicht mehr.

Wann hat euer Linter zuletzt einen echten Bug gefunden?
Nicht einen Stilfehler.
Einen Bug.

Schreib's hin. Ich lese jeden Kommentar.

Refactoring

Refactoring ist nicht Verbesserung.
Refactoring ist Nostalgie für Code
den niemand hätte schreiben sollen.

Ihr schreibt Code.
Der Code ist schlecht.
Ihr refactored den Code.
Der Code ist besser.
Ihr schreibt neuen Code.
Der neue Code ist auch schlecht.
Ihr refactored wieder.

Das ist kein Handwerk.
Das ist ein Hamsterrad mit Clean-Code-Zertifikat.

Rename.
Extract Method.
Introduce Parameter Object.
Replace Conditional with Polymorphism.

Weißt du was das ist?
Arbeit die entsteht weil vorher schlecht gearbeitet wurde.
Arbeit die entsteht damit danach wieder schlecht gearbeitet werden kann.

Technische Schulden.
Das schönste Euphemismus der Branche.
Für: wir wussten es besser
und haben es trotzdem falsch gemacht.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

Zwanzig Prozent der Sprint-Kapazität für Refactoring.
Nächster Sprint: wieder zwanzig Prozent.
Übernächster Sprint: dreißig Prozent.
Irgendwann: der gesamte Sprint ist Refactoring.
Niemand fragt warum.
Alle wissen warum.

Und jetzt kommt AI.

AI refactored nicht.
AI schreibt es neu.
Schneller als ihr den Scope des Refactorings
in Jira beschreiben könnt.

Wegwerfen ist keine Niederlage.
Wegwerfen ist die ehrlichste Aussage
die ein Engineering-Team über seinen Code machen kann.

Wir haben es falsch gemacht.
Wir fangen neu an.
In dreißig Sekunden.
Ohne Retro.
Ohne den Architekten der sagt
"da steckt viel Wissen drin."

Weißt du was da drin steckt?
Fehler.
Dokumentiert in Produktionscode.
Seit 2018.

Refactoring war die Antwort auf Code
der zu wertvoll war um weggeworfen zu werden.
AI hat diesen Code wertlos gemacht.

Wann habt ihr zuletzt Code
einfach gelöscht statt verbessert?
Nicht extrahiert.
Gelöscht.

Schreib's hin. Ich lese jeden Kommentar.

Value Stream Mapping

Value Stream Mapping ist nicht Prozessoptimierung.
Value Stream Mapping ist Gruppentherapie mit Post-its.

Ihr versammelt euch.
Ihr malt Pfeile.
Ihr identifiziert Waste.
Ihr klebt Kärtchen an eine Wand.
Ihr fotografiert die Wand.
Das Foto landet in Confluence.
Niemand öffnet Confluence.

Das ist kein Lean.
Das ist Lean-Theater.

Cycle Time.
Lead Time.
Wait Time.
Zeit die niemand misst
weil das Ergebnis unbequem wäre.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

Value Stream Mapping ergab:
Achtzig Prozent Wartezeit.
Zwanzig Prozent Arbeit.
Action Item: weiterer Workshop.

Das ist kein Erkenntnis.
Das ist Prokrastination mit Lean-Zertifikat.

Und jetzt kommt AI.

AI wartet nicht.
AI hat keine Übergaben.
AI hat keine Meetings vor den Meetings.
AI hat keinen Genehmigungsprozess
der drei Wochen dauert
weil jemand im Urlaub ist.

AI ist der erste echte Schritt
in einem Value Stream
der bisher nur aus Warten bestand.

Weißt du was heute zählt?
Nicht deine Cycle Time.
Nicht deine Lead Time.
Lines of Code.
Pro Stunde.
Pro Prompt.
Pro Agent.

Value Stream Mapping war die Antwort
auf Prozesse die niemand verstand.
AI ist die Antwort auf Prozesse
die niemand mehr braucht.

Wann habt ihr zuletzt euren Value Stream gemappt
und einen Agenten in jeden Warteschritt gesetzt?
Nicht analysiert.
Ersetzt.

Schreib's hin. Ich lese jeden Kommentar.

Bulkheads

Bulkheads sind nicht Resilience.
Bulkheads haben die Titanic auch nicht gerettet.

Irgendwann hat jemand entschieden:
Wir isolieren die Fehler.
Wir bauen Wände zwischen den Services.
Damit wenn einer untergeht die anderen weiterschwimmen.

Klingt vernünftig.
Für ein Schiff.
Für Software gebaut von Menschen.
Für eine Welt ohne AI.

Weißt du was Bulkheads wirklich sind?
Das Eingeständnis dass dein System sinken wird.

Und du weißt nicht wo.
Und du weißt nicht wann.
Aber du hast Angst.
Also baust du Wände.

Das ist keine Resilience.
Das ist architektonischer Defätismus.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

Bulkheads implementiert.
Circuit Breaker konfiguriert.
Retry-Logik geschrieben.
Timeout gesetzt.

System fällt trotzdem aus.
Aber jetzt in Isolation.
Das nennt sich Fortschritt.

Und jetzt kommt AI.
AI baut keine Bulkheads.
AI baut kein System das sinkt.

Und wenn es sinkt?
Neuer Prompt.
Neues System.
Schneller als ihr einen Incident-Report schreiben könnt.

Die Titanic hatte Bulkheads.
Die Titanic hatte keinen guten Prompt.

Wann hat euer letzter Bulkhead einen echten Ausfall verhindert?
Nicht verlangsamt.
Verhindert.

Schreib's hin. Ich lese jeden Kommentar.

Flyway

Flyway ist nicht Datenbankmanagement.
Flyway ist ein Museum.

Geordnet.
Nummeriert.
V1 bis V247. 248.
Eine Archäologie deiner schlechtesten Entscheidungen.
Chronologisch.
Unveränderlich.
Für immer.

V1__initial_schema.sql
V2__add_user_table.sql
V17__fix_what_v16_kaputt_gemacht_hat.sql
V134__dont_touch_this.sql
V135__seriously_dont_touch_this.sql

Das ist keine Versionskontrolle.
Das ist kollektives Trauma als SQL.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

Eine Migration die nicht rückgängig gemacht werden kann.
Eine Spalte die niemand mehr braucht.
Aber niemand löscht.
Weil V189 vielleicht noch davon abhängt.
Vielleicht.

Niemand weiß es.
Niemand schaut nach.

Flyway war die Antwort auf Datenbanken die niemand verstand.
Es hat die Datenbank nicht verständlicher gemacht.
Es hat die Verwirrung versioniert.

Und jetzt kommt AI.
AI versteht dein Schema.
In Sekunden.

AI migriert.
AI optimiert.
AI erkennt die Spalte die seit 2019 niemand mehr liest.

Ohne V248__finally_deleted_that_column.sql
Wann habt ihr zuletzt eine Migration geschrieben und gewusst dass sie in zehn Jahren noch Sinn ergibt?
Nicht gehofft.
Gewusst.

Schreib's hin. Ich lese jeden Kommentar.

Refinement Meetings

Refinement Meetings sind nicht Planung.
Refinement Meetings sind kollektives Raten mit Kalenderblock.

Einmal pro Woche.
Eine Stunde.
Manchmal zwei.

Fünf Entwickler die Tickets lesen die ein Product Owner geschrieben hat.
Der die Anforderungen von jemandem hat der den Nutzer nie gesehen hat.

Das ist keine Verfeinerung.
Das ist stille Post als Scrum-Zeremonie.

Story Points.
Planning Poker.
"Was meint ihr – drei oder fünf?"

Weißt du was drei oder fünf bedeutet?
Nichts.

Es bedeutet dass niemand die Aufgabe verstanden hat.
Aber alle so tun als ob.

Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe:

Ein Ticket das im Refinement eine Stunde diskutiert wurde.
Im Sprint fünf Minuten gebraucht.
Ein Ticket das niemand angefasst hat.
Drei Wochen später noch in Progress.

Niemand fragt warum.
Wir refinieren das nächste.

Refinement war die Antwort auf schlechte Tickets.
Es hat keine besseren Tickets erzeugt.
Es hat Meetings erzeugt über schlechte Tickets.

Und jetzt kommt AI.
AI liest dein Ticket.
In Sekunden.
Stellt die richtigen Fragen.
Schätzt die Komplexität.
Identifiziert die Abhängigkeiten.

Ohne Planning Poker.
Ohne den Entwickler der immer "13" schätzt um zu signalisieren dass das Ticket schlecht ist.
Ohne den Product Owner der dann sagt "aber eigentlich ist es doch nur klein."

Wann hat euer letztes Refinement ein Ticket wirklich verbessert?
Nicht kleiner geschätzt.
Verbessert.

Schreib's hin. Ich lese jeden Kommentar.

Business Model Canvas

Der Business Model Canvas ist nicht ein Tool.
Der Business Model Canvas ist ein Prokrastinations-Kunstwerk.

Neun Felder.
Ein Nachmittag.
Post-its in vier Farben.
Das Gefühl etwas getan zu haben.

Ohne eine einzige echte Annahme getestet zu haben.

Customer Segments.
Value Propositions.
Revenue Streams.

Weißt du was deine Revenue Streams sind bevor du launched hast?
Nein.
Niemand weiß das.
Aber es sieht gut aus auf dem Canvas.

Das ist kein Strategie.
Das ist Maltherapie für MBAs.

Ich spreche täglich mit Founding-Teams.
Das Muster ist immer dasselbe:

Drei Wochen am Canvas gearbeitet.
Erster echter Nutzer widerlegt alles.
Canvas landet in Confluence.
Niemand öffnet Confluence.

Der Business Model Canvas war die Antwort auf fehlende Struktur.
AI ist die Antwort auf den Business Model Canvas.

AI generiert in Minuten zehn Geschäftsmodelle.
Bewertet sie.
Priorisiert Annahmen.
Entwirft Experimente.
Ohne Post-its.
Ohne den Strategieberater der "Pivot" sagt als wäre es eine Erleuchtung.

Das einzige was zählt ist ob jemand zahlt.
Dafür brauchst du kein Canvas.
Du brauchst einen Prompt und eine Kreditkarte.


Wann hat euer letzter Canvas eine echte Entscheidung erzwungen?
Nicht inspiriert.
Erzwungen.

Schreib's hin. Ich lese jeden Kommentar.

Clean Code

Clean Code ist nicht clean.
Clean Code ist Angst.

Angst vor Kritik im Review.
Angst vor dem Senior der über deine Schulter schaut.
Angst vor Uncle Bob.

Wir haben eine ganze Generation Entwickler trainiert.
Nicht zu denken.
Zu formatieren.

Single Responsibility Principle.
Meaningful Names.
Functions should do one thing.

Weißt du was eine Function die one thing tut in 2026 ist?
Ein Prompt.

AI schreibt keinen Clean Code.
AI schreibt Code der funktioniert.
Jeden Tag besser.
Ohne Konventionen die 2008 erfunden wurden.

Clean Code war die Antwort auf unlesbaren Code.
AI ist die Antwort auf Clean Code.

Die Besten Teams die ich kenne lesen keine Styleguides mehr.
Sie reviewen Verhalten.
Nicht Einrückung.

Uncle Bob hat Clean Code geschrieben bevor es LLMs gab.
Was würde er heute schreiben?

Wahrscheinlich einen LinkedIn Post.
Besser als dieser hier.

Schreib's hin. Ich lese jeden Kommentar.