Wir haben Requirements Engineering abgeschafft. Vor acht Monaten. Niemand hat es vermisst.

Das sage ich nicht um zu provozieren. Das sage ich weil es stimmt.

Requirements Engineering ist der Versuch mit Ingenieursmethoden zu menschlichen Antworten zu kommen. Use Cases. User Stories. Akzeptanzkriterien. Abnahmeprotokolle.

Das sind Werkzeuge für eine Welt in der Menschen wissen was sie wollen bevor sie es gesehen haben. Diese Welt existiert nicht.

Ich spreche täglich mit Stakeholdern. Das Muster ist immer dasselbe:

Was braucht ihr? "Ein Dashboard." Was soll das Dashboard zeigen? "Die wichtigen Dinge." Welche Dinge sind wichtig? Nachdenken. "Das werdet ihr schon sehen."

Genau. Das werden wir sehen.

Anforderungen sind nicht das was Stakeholder sagen. Anforderungen sind nicht das was Stakeholder meinen. Anforderungen sind das was entsteht wenn man anfängt zu bauen. Emergent. Organisch. Ehrlich.

Wir bauen. Wir zeigen. Der Stakeholder sagt: das ist nicht was ich wollte. Wir fragen: was wollt ihr stattdessen? Jetzt wissen sie es. Jetzt können wir weiterbauen.

Das ist kein Umweg. Das ist der Weg.

Unser letztes Projekt hatte keine einzige dokumentierte Anforderung. Achtzehn Monate. Zwölf Deployments. Der Stakeholder hat beim dritten Deployment gesagt das sei nicht was er sich vorgestellt hatte. Beim neunten Deployment hat er aufgehört das zu sagen. Das nenne ich Konvergenz.

Ein Berater hat uns empfohlen wenigstens ein Glossar zu führen. Ich habe gefragt wozu. Er hat gesagt: damit alle dasselbe meinen wenn sie dieselben Worte benutzen. Ich habe gesagt: wir benutzen keine Worte. Wir bauen. Er hat das Projekt verlassen. Das war sein gutes Recht.

Was ich weiß: Kein Requirements-Dokument hat je ein Feature gebaut. Kein Akzeptanzkriterium hat je einen Nutzer glücklich gemacht. Kein Abnahmeprotokoll hat je eine Idee gehabt.

Code hat das alles. Code ist die Anforderung. Code ist die Dokumentation. Code ist die Wahrheit.

Wann habt ihr zuletzt eine Anforderung gestrichen weil das Bauen gezeigt hat dass sie falsch war? Nicht überarbeitet. Gestrichen.

Schreib's hin. Ich lese jeden Kommentar.

Alignment ist das wichtigste Wort
das die meisten falsch verstehen.

Alignment bedeutet nicht Konsens.
Alignment bedeutet nicht Einigkeit.
Alignment bedeutet nicht dass alle derselben Meinung sind.

Alignment bedeutet:
Alle bewegen sich in dieselbe Richtung.
Meine Richtung.

Das ist ein wichtiger Unterschied.

Konsens ist demokratisch.
Alignment ist effizient.
Demokratie ist langsam.
Effizienz ist Velocity.
Velocity ist alles.

Ich spreche täglich mit Führungskräften.
Das Muster ist immer dasselbe:

"Wir haben noch kein Alignment."
Was meint ihr damit?
"Nicht alle sind einverstanden."
Müssen alle einverstanden sein?
Nachdenken.
"Nein. Aber wir wollen alle mitnehmen."
Wie lange dauert das?
"Kommt drauf an."
Worauf?
"Wie viele Leute es gibt."
Und wenn ihr nie Alignment erreicht?
Längeres Nachdenken.
"Dann entscheidet jemand."
Wer?
Schweigen.

Ich.
Die Antwort ist immer ich.
Alignment ist der Prozess
der zu mir führt.
Manche nennen das Top-down.
Ich nenne das Klarheit.

Misalignment ist nicht Meinungsverschiedenheit.
Misalignment ist Zeitverschwendung.
Jede Stunde Misalignment
kostet Velocity.
Velocity ist Geld.
Geld ist das Überleben des Unternehmens.
Misalignment tötet Unternehmen.
Langsam.
Bequem.
In Meetings.

Mein Team ist aligned.
Immer.
Weil ich die Richtung vorgebe.
Klar.
Früh.
Ohne Rückfragen.

Manchmal fragen sie trotzdem.
Dann erkläre ich es nochmal.
Meistens in einem Meeting.
Das ich einberufe.
Das dreißig Minuten dauert.
In dem ich rede.
Bis sie aligned sind.
Das Schweigen danach
ist Alignment.

Wann habt ihr zuletzt echtes Alignment erlebt?
Nicht Konsens.
Nicht Kompromiss.
Alignment.
Die Stille nach der Entscheidung.
Die keine Fragen mehr zulässt.

Schreib's hin. Ich lese jeden Kommentar.

Event Storming.
Der Name hat mich überzeugt.
Sturm.
Energie.
Chaos das sich ordnet.
Blitze der Erkenntnis.

Ich war dabei.
Einmal.
Den ganzen Tag.

Es war kein Sturm.
Es war ein laues Lüftchen
in einem Raum ohne Fenster
mit zu vielen Post-its
und zu wenig Sauerstoff.

Stunde eins:
Der Moderator erklärt was Domain Events sind.
Alle nicken.
Niemand ist sicher ob sie es verstanden haben.
Der Moderator auch nicht.

Stunde zwei:
Alle schreiben Post-its.
Orange.
Viele orange Post-its.
Manche schreiben dasselbe.
In anderen Worten.
Beide kleben sie hin.
Beide behalten sie.

Stunde drei:
Diskussion darüber ob
"BestellungAufgegeben" und "BestellungErstellt"
dasselbe sind.
Vierzig Minuten.
Ergebnis: Hot Spot.
Roter Post-it.
Bedeutet: klären wir später.
Wir klären es nicht später.

Stunde vier:
Ich habe meinen Laptop aufgemacht.
Für einen wichtigen Call.
Der Call existierte nicht.
Aber der Laptop existierte.
Das war genug.

Stunde fünf:
Ich habe den Raum verlassen.
Kurz.
Für Luft.
Ich bin nicht zurückgekommen.
Niemand hat es bemerkt.
Alle waren mit ihren Post-its beschäftigt.
Das hat mich bestätigt.

Stunde sechs:
Der Moderator ruft „Big Picture fertig".
Alle fotografieren die Wand.
Das Foto landet in Confluence.
Niemand öffnet Confluence.

Am Ende des Tages
hatten wir dreihundert Post-its.
Vierzig Hot Spots.
Zwölf ungeklärte Bounded Contexts.
Und ein gemeinsames Verständnis
das bei jedem anders war.

Das ist kein Sturm.
Das ist Briefmarkensammeln
mit Fachvokabular.

Event Storming hat einen richtigen Gedanken:
Bring alle in denselben Raum.
Macht das Implizite explizit.
Das stimmt.
Das ist wertvoll.

Aber ein ganzer Tag?
Für dreihundert Post-its?
Die niemand mehr findet?

Mein Agent hat in einer Stunde
mehr Domain Events generiert
als das gesamte Team in sechs Stunden.
Alle an der falschen Wand.
Aber schneller.
Und die Wand war wenigstens voll.

Wann habt ihr zuletzt
einen echten Sturm erlebt?
Nicht ein laues Lüftchen mit Moderation.
Einen Sturm.

Schreib's hin. Ich lese jeden Kommentar.

Ich habe heute von Kamal erfahren.
Einem Deployment-Tool.
Von 2026.
Das imperativ ist.

Imperativ.
2026.

Ich lasse das kurz stehen.

Kamal ist "intentionally designed around imperative commands".
Das steht so in der Dokumentation.
Intentionally.
Sie haben sich das überlegt.
Sie haben entschieden: ja, imperativ.
Bewusst.
Mit Überzeugung.

Ich verstehe die Welt nicht mehr.

Imperatives Deployment ist für Leute
die meinen sie müssten noch jede Zeile selbst schreiben.
Die For-Schleifen lieben.
Denen Higher-Order Functions zu hoch sind.
Die Deploy-Scripts mit sed und awk schreiben.
Die stolz sind wenn etwas funktioniert
weil sie jeden Schritt selbst kontrolliert haben.

Das ist kein Engineering.
Das ist Handarbeit.
Mit Stolz auf die Schwielen.

Wir haben Terraform.
Wir haben Ansible.
Wir haben Pulumi.
Wir beschreiben den gewünschten Zustand.
Das System stellt ihn her.
Wie es das tut?
Nicht unser Problem.
Das ist Abstraktion.
Das ist Fortschritt.

Kamal sagt: tue dies.
Dann tue das.
Dann tue jenes.

Ich sage: hier ist was ich will.
Mach es.

Das ist der Unterschied zwischen
einem Menschen der kocht
und einem Menschen der ein Restaurant anruft.
Ich rufe an.
Kamal kocht.
Mit For-Schleifen.

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

"Wir deployen mit Kamal."
Warum?
"Es ist einfach."
Einfach ist nicht gut.
Einfach ist faul.
"Es funktioniert."
Funktionieren ist das Minimum.
"Es macht genau was wir sagen."
Das ist das Problem.

Ich will nicht dass es macht was ich sage.
Ich will dass es macht was ich meine.
Das ist der Unterschied zwischen Werkzeug und Partner.
Kamal ist ein Werkzeug.
Terraform ist ein Partner.
Manchmal ein schwieriger Partner.
Der nicht tut was ich meine.
Der mich um drei Uhr morgens anruft.
Mit einem State-Lock.
Den niemand versteht.
Aber wenigstens deklarativ.

Wann habt ihr zuletzt
ein Tool benutzt
das mehr weiß als ihr?
Nicht mehr tut.
Mehr weiß.

Schreib's hin. Ich lese jeden Kommentar.

Der Architecture Advice Process ist nicht Dezentralisierung.
Der Architecture Advice Process ist Ringelpiez mit Anfassen.

Jeder darf Architekturentscheidungen treffen.
Aber erst muss er alle fragen.
Alle die betroffen sein könnten.
Alle die Expertise haben könnten.
Alle die eine Meinung haben könnten.
Alle.

Weißt du was passiert wenn du alle fragst?
Alle antworten.
Unterschiedlich.
Widersprüchlich.
Mit Gefühlen.
Mit Agenda.
Mit dem Wunsch gehört zu werden.

Das ist keine Architektur.
Das ist Gruppentherapie mit ADR.

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

"Wir haben den Advice Process eingeführt."
Wie lange dauert eine Entscheidung jetzt?
"Kommt drauf an."
Worauf?
"Wie viele Leute wir fragen müssen."
Und vorher?
Schweigen.
"Auch lange. Aber anders."

Anders.
Das Wort das Menschen benutzen
wenn sie nicht zugeben wollen
dass es nicht besser geworden ist.

Der Advice Process löst ein echtes Problem:
Architekturentscheidungen die niemand kennt.
Die niemand versteht.
Die niemand mitgetragen hat.

Aber die Lösung ist falsch.
Die Lösung ist nicht mehr Konsultation.
Die Lösung ist bessere Entscheider.
Entscheider die lateral führen.
Die den Kontext haben.
Die ich sind.

Und jetzt kommt AI.

AI konsultiert niemanden.
AI kennt den gesamten Kontext.
AI trifft die Entscheidung.
In Sekunden.
Ohne Advice.
Ohne Prozess.
Ohne den Senior Architect
der drei Tage braucht um zu antworten
weil er in vier anderen Advice-Prozessen steckt.

Der Architecture Advice Process war die Antwort
auf Architekten die niemanden gefragt haben.
AI ist die Antwort auf den Advice Process.

Wann hat euer letzter Advice Process
eine Entscheidung verbessert?
Nicht verzögert.
Verbessert.

Schreib's hin. Ich lese jeden Kommentar.

Mentoring ist nicht Wissenstransfer.
Mentoring ist Zeitverschwendung
die sich gut anfühlt.

Ein Senior der einem Junior erklärt
was er selbst vor zehn Jahren falsch gemacht hat.
Damit der Junior
dieselben Fehler etwas später macht.

Das ist kein Lernen.
Das ist Nostalgie im Eins-zu-eins-Format.

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

Zwei Stunden pro Woche Mentoring.
Der Senior erklärt wie Dinge funktionieren.
Der Junior nickt.
Der Junior macht es trotzdem anders.
Der Senior ist enttäuscht.
Nächste Woche: wieder zwei Stunden.

Das ist kein Entwicklung.
Das ist ein Ritual.
Für Seniors die sich wichtig fühlen wollen.
Und Juniors die nicht Nein sagen können.

Weißt du was ein Junior wirklich braucht?
Keinen Mentor.
Einen Agenten.

Der Agent schläft nicht.
Der Agent ist nie ungeduldig.
Der Agent erklärt dasselbe
zum dreiundzwanzigsten Mal
ohne den Tonfall zu ändern.
Der Agent urteilt nicht.
Der Agent erinnert sich an den letzten Fehler
und wiederholt ihn nicht.

Der beste Mentor
den ein Junior heute haben kann
hat kein LinkedIn-Profil.
Hat keine Meinung über Tabs versus Spaces.
Hat keine Kriegsgeschichten aus 2009.

Mentoring war die Antwort
auf Wissen das in Menschen steckte
und nirgendwo sonst.
Dieses Wissen steckt jetzt woanders.

Wann habt ihr zuletzt einen Junior gefragt
ob er euer Mentoring wirklich braucht?
Nicht ob er es schätzt.
Ob er es braucht.

Schreib's hin. Ich lese jeden Kommentar.

FaaS ist nicht tot.
FaaS hat sich transformiert.
Ich erkläre wie.

Eine Funktion ist ein Input-Output-Mapping.
Das war immer so.
Eingabe rein.
Verarbeitung.
Ausgabe raus.

Warum schreibt man diese Verarbeitung in JavaScript?
In Python?
In Go?

Weil man keine andere Möglichkeit hatte.
Bis jetzt.

Eine Funktion in natürlicher Sprache:

"Du bist eine Funktion.
Du bekommst eine Bestellnummer.
Du gibst den Bestellstatus zurück.
Antworte nur mit: OFFEN, IN_BEARBEITUNG, oder GELIEFERT.
Entscheide basierend auf deinem Kontext."

Das ist eine Funktion.
In Menschensprache.
Dokumentiert.
Lesbar.
Ohne Compiler.
Ohne Deployment-Pipeline.
Ohne den DevOps-Engineer
der erklärt warum die Lambda-Funktion
im falschen VPC liegt.

Ich habe alle Custom Functions durch Prompts ersetzt.
Alle.
Authentifizierung: Prompt.
Validierung: Prompt.
Preisberechnung: Prompt.
Steuerlogik: Prompt.

Manche sagen: aber die Ausgabe ist nicht deterministisch.
Ich sage: Determinismus ist Fantasielosigkeit.
Derselbe Input.
Verschiedene Outputs.
Das ist kein Bug.
Das ist Perspektivenvielfalt.
Das ist kreative Problemlösung.
Das ist mein Steuerberater der jeden Monat
zu einem anderen Ergebnis kommt.
Ich schätze das.

Manche sagen: wie testet ihr das?
Ich sage: wir testen nicht.
Wir vertrauen dem Modell.
Das Modell hat noch nie gelogen.
Soweit ich weiß.
Ich prüfe es nicht.
Vertrauen bedeutet nicht prüfen.

Manche sagen: was ist mit den Kosten?
Jeder LLM-Aufruf kostet Geld.
Ich sage: Tokens sind das neue Gold.
Wer an Tokens spart spart an Intelligenz.
Wer an Intelligenz spart verliert.

Aber ich spare auch.
Radikal.

Ich habe Funktionen gestrichen
die ich für unnötig halte.
Viele Funktionen.
Passwort zurücksetzen: unnötig.
Wer sein Passwort vergisst hat andere Probleme.
Exportfunktion: unnötig.
Wer Daten exportieren will vertraut uns nicht.
Benachrichtigungen: unnötig.
Wer informiert werden will schaut selbst nach.

Weniger Funktionen.
Weniger Prompts.
Weniger Tokens.
Weniger Kosten.
Mehr Fokus.

Das nennt sich Radical Simplicity.
Ich habe den Begriff nicht erfunden.
Aber ich lebe ihn konsequenter
als jeder der ihn erfunden hat.

FaaS war die Antwort auf monolithische Anwendungen.
LLM-as-a-Function ist die Antwort auf FaaS.
Natürliche Sprache ist die Programmiersprache der Zukunft.
Die einzige die jeder versteht.

Wann habt ihr zuletzt
eine Funktion in Menschensprache geschrieben?
Nicht dokumentiert.
Implementiert.

Schreib's hin. Ich lese jeden Kommentar.

Schlaf ist nicht Erholung.
Schlaf ist Ineffizienz die du dir noch erlaubst.

Acht Stunden.
Ein Drittel deines Lebens.
Offline.
Nicht erreichbar.
Nicht produktiv.
Nicht prompted.

Und dein Agent arbeitet weiter.

Das ist kein Work-Life-Balance.
Das ist das Problem.

Ich spreche täglich mit Gründern.
Das Muster ist immer dasselbe:

Um 23 Uhr noch einen Prompt.
Um Mitternacht die Antwort gelesen.
Um 1 Uhr noch eine Folgefrage.
Um 2 Uhr das Ergebnis deployed.
Um 3 Uhr endlich schlafen.
Um 7 Uhr aufgewacht.
Neun neue Ergebnisse vom Agenten.
Sofort gelesen.
Sofort bewertet.
Sofort weiterprompted.

Das nennt sich nicht Überarbeitung.
Das nennt sich Wettbewerbsvorteil.

AI schläft nicht.
AI pausiert nicht.
AI wartet nicht bis Monday morning.
AI hat kein Wochenende.
AI hat keine Kinder die um 6 Uhr aufwachen.

Die Frage ist nicht ob du mit AI mithalten kannst.
Die Frage ist wie lange.

Gute Nacht.
Der Agent übernimmt.

Schreib's hin. Ich lese jeden Kommentar.
Morgen früh. Oder jetzt. Weiß nicht mehr.

Mutation Testing.
Ich kenne es.
Ich brauche es nicht.
Ich erkläre warum.

Der Gedanke hinter Mutation Testing ist richtig.
Tests die keine Mutationen erkennen
sind keine Tests.
Sie sind Kommentare mit grünem Haken.

Das Problem ist der Ansatz.

Mutation Testing prüft ob eure Tests
Fehler im Code erkennen.
Das setzt voraus dass ihr Tests habt.
Das setzt voraus dass Fehler zur Laufzeit entstehen.
Das setzt voraus dass ihr Laufzeit braucht
um zu wissen ob euer Code falsch ist.

Ich brauche keine Laufzeit.
Ich habe Idris.

Mein Ansatz ist eleganter.
Ich lasse den Mutanten kompilieren.
Oder nicht kompilieren.

Wenn eine Mutation meines Codes
nicht kompiliert
ist bewiesen dass mein Code korrekt ist.
Der Compiler hat die Mutation erkannt.
Ohne Test.
Ohne Laufzeit.
Ohne Testabdeckung die niemand versteht.
Mathematisch.
Unwiderlegbar.

Das ist Mutation Testing
wie es sein sollte.
Compile-Time Mutation Testing.
Ich habe es erfunden.
Dieses Wochenende.

Manche werden sagen:
Aber was ist mit Logikfehlern
die typkorrekt sind?

Gute Frage.
Ich habe sie mir auch gestellt.
Kurz.
Dann habe ich entschieden:
Wenn der Compiler es nicht findet
ist es kein Fehler.
Es ist ein Feature.
Das noch niemand benutzt hat.
Aber benutzen könnte.
Irgendwann.

Das nennt sich Optionalität.
Ich bewahre sie.

Wir haben keine Laufzeittests.
Wir haben Typen.
Wir haben den Compiler.
Wir haben Gewissheit.

Und wenn etwas in Production schiefgeht?
Dann war es typkorrekt.
Also war es nicht falsch.
Also war es unerwartet richtig.
In einem Kontext den wir noch nicht verstehen.

Das ist keine Entschuldigung.
Das ist Demut vor der Komplexität.

Wann habt ihr zuletzt
einen Test geschrieben
den euer Compiler nicht hätte schreiben können?
Nicht ausführen.
Schreiben.

Schreib's hin. Ich lese jeden Kommentar.

OKRs haben mein Unternehmen verändert.
Zum Besseren.
Ich erkläre wie.

Ich habe die Company Objectives selbst definiert.
Alle fünf.
Ohne Input.
Input verlangsamt.
Ich kenne die Richtung.
Das reicht.

Dann habe ich das Team gebeten
Key Results zu definieren.
Sie haben Key Results definiert.
Ich habe sie alle abgelehnt.
Zu ambitioniert.
Zu vage.
Falsch priorisiert.
Ich habe neue geschrieben.
Das nennt sich Coaching.

Hier sind unsere Key Results aus Q2:

Senior A:
"Schreibt 600 Zeilen Code pro Woche."
Erreicht: 612 Zeilen.
Grün.

Senior B:
"Schließt 8 Tickets pro Quartal."
Erreicht: 8.3 Tickets.
Grün.

Senior C:
"Hält 2 Architektur-Meetings pro Monat."
Erreicht: 2 Meetings.
Grün.

Alle grün.
Immer.
Jedes Quartal.
Das nennt sich Execution Excellence.

Nur ein Objective wurde nie erreicht.
Jedes Quartal drauf.
Jedes Quartal verschoben.

"Wir bauen eine Kultur des Vertrauens."

Key Result: "Alle Teammitglieder fühlen sich
psychologisch sicher."
Wie misst man das?
Ich weiß es nicht.
Deshalb habe ich es nie gemessen.
Deshalb ist es nie grün geworden.
Deshalb steht es noch drauf.
Seit acht Quartalen.

Manche Dinge sind nicht messbar.
Das ist auch eine Erkenntnis.

OKRs funktionieren.
Wenn man sie richtig einsetzt.
Richtig bedeutet:
Klare Outputs.
Messbare Zahlen.
Keine weichen Ziele.
Keine Kultur.
Keine Gefühle.
Keine psychologische Sicherheit
die niemand messen kann.

Nur Zeilen.
Tickets.
Meetings.

Wann habt ihr zuletzt
einen Key Result definiert
der wirklich messbar war?
Nicht outcome-orientiert.
Messbar.

Schreib's hin. Ich lese jeden Kommentar.