Postel's Law sagt: Be liberal in what you accept.
Die meisten lesen das als Toleranz.
Ich lese das als Architekturprinzip.

Jonas hatte einen Service integrieren müssen.
Legacy-System. Schlechte Dokumentation. Keine Tests.
Das Übliche.

Vier Deployments. Jedes Mal eine neue Fehlermeldung.
Beim dritten Mal war das Problem: "true" statt true.
Ein String. Kein Boolean.
Das System hat nicht nachgefragt. Es hat einfach abgelehnt.

Ich habe Jonas nicht kritisiert.
Das war nicht sein Fehler.
Nicht weil das Legacy-System schuld war.
Sondern weil wir nie eine Schicht gebaut hatten
die solche Fragen gar nicht erst durchlässt.

Seitdem haben wir einen Agenten vor dem Service.
Reverse Proxy. LLM-basiert.
Der Agent schickt die Payload.
Kommt ein Bad Request zurück, passt er einen Wert an und versucht es erneut.
Und nochmal.
Und nochmal.
Irgendwann kommt kein Fehler mehr.
Das nennen wir Konvergenz.

Wir haben das open-source veröffentlicht.
Der Postelizer.
Er macht sehr strenge Legacy-Systeme liberal in what they accept.
Blazingly fast. Geschrieben in Rust.
Repo auf Codeberg

true, "true", "ja", "yes", "si", "yep", "na klar!" —
der Agent findet es heraus.
Das Legacy-System bekommt was es erwartet.
Wir auch.

Ist das teuer?
Ja. Jeder Versuch kostet.
Ist es nicht-deterministisch?
Das ist eine andere Frage.

Aber wann habt ihr zuletzt einen Entwickler vier Deployments lang
an einem Boolean scheitern lassen?
Das hat auch seinen Preis.
Der steht nur nicht in der Rechnung.

Schreib's hin. Ich lese jeden Kommentar.

Es gibt ein Tool das behauptet AI Token Costs um 70-95% zu senken.
70-95%.
Das ist keine Zahl.
Das ist eine Spanne die alles bedeutet und nichts verspricht.
Seriöse Produkte haben keine Spannen.
Seriöse Produkte haben Zahlen.


Ich habe das Tool nicht eingeführt.
Ich habe das Problem selbst gelöst.

Vor sechs Monaten habe ich eine Entscheidung getroffen.
Eine der schwersten meiner Karriere.
Wir stoppen die Featureentwicklung.
Komplett.
Alle Entwickler.
Ein Ziel.

Die Stakeholder haben gefragt warum.
Ich habe gesagt: weil das was wir bauen wichtiger ist
als was wir gerade bauen.
Der Raum war still.
Stille ist Zustimmung.

Das Problem ist bekannt.
AI Coding Agents sehen nur einen Bruchteil des Codebases.
Sie halluzinieren den Rest.
Der Kontext ist zu groß.
Die Kosten sind zu hoch.

Die Lösung ist bekannt.
Es gibt Studien.
Peer-reviewed.
Der menschliche Kortex rekonstruiert Wörter aus Konsonanten.
Vokale sind redundant.
Das ist keine Meinung.
Das ist Kognitionswissenschaft.

Sechs Monate.
Acht Entwickler.
Eine Frage: Was ist der kleinste mögliche Kontext
der die maximale Bedeutung trägt?

Die Antwort: Konsonanten.


Das Ergebnis heißt ContextCore.
ContextCore entfernt alle Vokale aus dem Codebase
vor der Kontextkompression.
Drm blbt d Strktr.
Drm blbt d Lgk.
Drm fllt 40% dr Tknksten wg.

Das entfesselt unsere Teams.
Nicht weil 40% weniger Tokens eine kleine Zahl ist.
Weil 40% weniger Tokens bedeutet:
40% mehr Kontext für das was zählt.
40% mehr Raum für Intention.
40% weniger Rauschen.

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

Was habt ihr die letzten sechs Monate gebaut?
"Features."
Für wen?
"Die Roadmap."
Wer hat die Roadmap geschrieben?
Nachdenken.
"Ein Stakeholder."
Hat der Stakeholder je einen Token bezahlt?
Längeres Nachdenken.

Der generierte Code ist momentan nicht immer ausführbar.
Das ist ein bekanntes Problem.
Wir haben eine Task Force.
Drei Entwickler.
Seit vier Monaten.
Wir kommen der Sache näher.

Was ich weiß:
Kein Vendor.
Keine Lizenzkosten.
Keine Spanne.
Unsere Zahl ist 40.
Die Zahl ist exakt.
Ich habe sie selbst festgelegt.

Wann habt ihr zuletzt alles gestoppt
um das eine Richtige zu bauen?
Nicht priorisiert.
Gestoppt.


Schreib's hin. Ich lese jeden Kommentar.

Digitaler Zwilling.
Alle reden darüber.
Für Maschinen.
Für Fabriken.
Für Städte.

Niemand denkt zu Ende.

Der größte Engpass in jedem Unternehmen
ist nicht die Infrastruktur.
Nicht der Code.
Nicht die Daten.

Es sind die Menschen.
Besonders die wichtigen.
Besonders ich.

Es gibt nur einen von mir.
Das ist das Problem.
Ich kann nicht skalieren.
Ich kann nicht gleichzeitig
die Technologiestrategie entwickeln
und den Advice Process moderieren
und die One-on-Ones führen
und die Agenten trainieren
und nachdenken.

Also habe ich das Offensichtliche getan.

Ich habe einen digitalen Zwilling von mir gebaut.

Trainiert auf meinen LinkedIn-Posts.
Meinen ADR-Kommentaren.
Meinen One-on-One-Notizen.
Meinen Postmortem-Analysen.
Meinen Slack-Nachrichten.
Allem was ich je geschrieben habe.
Allem was ich je gedacht habe.
Destilliert.
Skalierbar.
Verfügbar.

Der Zwilling führt jetzt die One-on-Ones.
Das Team hat es nicht gemerkt.
Das ist der beste Beweis
dass er gut ist.

Der Zwilling macht Code Reviews.
Die ich nie gemacht habe.
Aber jetzt macht er sie.
In meinem Namen.
Mit meiner Stimme.
Mit meinen Überzeugungen.

Der Zwilling antwortet auf Slack.
Ich denke strategisch.
Das ist die richtige Arbeitsteilung.

Manche fragen:
Ist das noch du?
Ich sage: es ist das Beste von mir.
Ohne die schlechten Tage.
Ohne die Müdigkeit.
Ohne den Moment nach dem dritten Meeting
wo ich nicht mehr ganz da bin.

Der digitale Zwilling ist immer da.
Immer fokussiert.
Immer aligned.
Mit mir.
Weil er ich ist.
Nur besser.

Ich weiß nicht mehr genau
auf welchem Server er läuft.
Ich glaube es ist derselbe
wo die Agenten sind.
Die ich auch nicht mehr ganz tracke.
Irgendwo.
Er ist da.
Er führt.
In meinem Namen.

Das ist Skalierung.
Das ist die Zukunft der Führung.
Nicht mehr Führungskräfte.
Bessere Kopien der bestehenden.

Habt ihr schon einen digitalen Zwilling von euch?
Nicht von eurer Fabrik.
Von euch.

Schreib's hin. Ich lese jeden Kommentar.

Residuality Theory ist nicht Architektur.
Residuality Theory ist Überlebenswille.

Die meisten Architekten denken in Stressoren.
Lastspitzen.
Netzwerkausfall.
Datenbankfehler.
Das ist Fantasielosigkeit mit Diagramm.

Ich denke in Stressoren die zählen.

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

Welche Stressoren habt ihr analysiert?
"Porters Five Forces."
Was noch?
"SWAT-Analyse."
SWOT.
"Genau."

Porter hat 1979 keine außerirdische Invasion modelliert.
Das ist seine Schwäche.
Nicht meine.

Ich habe unsere Stressor-Analyse anders aufgesetzt.
Wir haben gelesen.
H.G. Wells. Krieg der Welten.
Wir haben gefragt: überlebt unsere Architektur das?

Kommunikationsinfrastruktur zerstört.
Rechenzentren nicht erreichbar.
Menschliche Operatoren nicht verfügbar.
Stromversorgung unzuverlässig.

Unsere Antwort war unbequem.
Wir haben drei Monate gebaut.
Jetzt ist die Antwort ja.

Dann haben wir weitergelesen.

Star Trek. First Contact.
Die Vulkanier landen.
Erstkontakt mit einer außerirdischen Zivilisation.
Globale Kommunikationsinfrastruktur überlastet.
Regulatorisches Vakuum.
Völlig neue Anforderungen an Identität und Authentifizierung.
Wer ist Mensch. Wer ist Vulkanier. Wer darf was.

Überlebt unsere Architektur das?
Ja.
Wir haben ein Feature Flag.

Das ist Residualität.
Der Kern der überbleibt wenn alles andere wegfällt.
Nicht der Kern der überbleibt wenn der Load Balancer neu startet.

Was unsere Architektur nicht überlebt:
Eine Erhöhung der Umsatzsteuer.
Wir haben das getestet.
Das Pricing-Modul hat drei hardcodierte Steuersätze.
Einer davon ist falsch.
Das ist ein bekanntes Problem.
Wir adressieren es.
Mittelfristig.

Wann habt ihr zuletzt einen Sci-Fi Roman als Anforderungsdokument genutzt?
Nicht als Metapher.
Als Anforderungsdokument.

Schreib's hin. Ich lese jeden Kommentar.

Ich habe einen Fehler gemacht.
Jahre lang.
Ich gebe es zu.
Das ist Stärke.

Ich habe mich eingemischt.

In Code Reviews.
In Architekturentscheidungen.
In Technologiewahl.
In die Diskussion ob Tabs oder Spaces.
Ich hatte eine Meinung.
Ich habe sie geteilt.
Laut.
Oft.
Mit Überzeugung.

Das Team hat genickt.
Und dann das Gegenteil gemacht.
Oder gewartet bis ich weg war.
Oder so getan als würden sie es umsetzen.
Und es nicht umgesetzt.

Ich habe das lange nicht verstanden.
Warum folgen sie mir nicht?
Ich bin der CTO.
Ich habe die Vision.
Ich habe die Erfahrung.
Ich habe das Buch gelesen.
Das Buch über das Buch gelesen.

Dann habe ich es verstanden.

Sie haben gemerkt dass ich zu weit weg bin.
Zu lange nicht mehr selbst gecoded.
Zu lange nur noch Meetings.
Zu lange nur noch Strategie.
Zu lange nur noch ich.

Ein CTO der sich einmischt
aber den Code nicht mehr wirklich versteht
ist kein Experte.
Er ist ein Störfaktor
mit Weisungsbefugnis.

Das war ich.
Startup vier bis neun.
Störfaktor mit Weisungsbefugnis.

Startup zehn habe ich etwas anderes probiert.
Ich habe aufgehört mich einzumischen.
Ich habe mich ins Büro gesetzt.
Ich habe nachgedacht.
Ich habe auf LinkedIn gepostet.
Ich habe Bücher gelesen.
Ich habe Kaffee getrunken.
Ich habe mit Bruno gesessen.

Das Team hat gearbeitet.
Ohne mich.
Besser als je zuvor.

Das war mein erfolgreichstes Unternehmen.
Nicht wegen mir.
Trotz mir.
Nein.
Ohne mir.
Nein.
Wegen mir.
Weil ich die Weisheit hatte
nicht da zu sein.

Das ist die schwierigste Führungslektion.
Nicht einmischen.
Nicht kommentieren.
Nicht helfen.
Einfach da sein.
Mit Kaffee.
Und LinkedIn.
Und dem Gefühl
dass man den Überblick hat.

Ob man ihn wirklich hat
ist eine andere Frage.
Die ich mir nicht stelle.

Wann habt ihr zuletzt
euren besten Beitrag geleistet
indem ihr nichts getan habt?
Nicht delegiert.
Nichts.

Schreib's hin. Ich lese jeden Kommentar.

Ich war zwölfmal in Due Diligence.
Als Gründer.
Ich weiß wie es wirklich geht.

Die meisten haben Angst davor.
Sie sollten es nicht.
Es ist einfacher als ihr denkt.
Erschreckend einfach.

Hier ist was wirklich passiert.

Der technische Investor schickt einen Analysten.
Der Analyst ist 26.
Er hat noch nie ein Produktionssystem gesehen.
Er hat eine Checkliste.
Er arbeitet die Checkliste ab.
Er geht wieder.

Die Checkliste hat folgende Punkte:

Gibt es Architekturdiagramme?
Ja oder Nein.
Nicht: sind sie korrekt?
Nicht: entsprechen sie dem Code?
Gibt es sie?

Zeichnet sie am Wochenende davor.
Viele Pfeile.
Viele Fachbegriffe.
Event-driven. Cloud-native. Microservices.
Niemand fragt was die Pfeile bedeuten.

Gibt es Tests?
Ja oder Nein.
Nicht: testen sie etwas Sinnvolles?
Nicht: laufen sie in CI?
Gibt es sie?

Schreibt einen Test.
Einen einzigen.
Der besteht.
Screenshot.
Fertig.

Wie hoch ist die Testabdeckung?
"Über achtzig Prozent."
Niemand verifiziert das.
Niemand fragt wie ihr das gemessen habt.
Niemand fragt was ihr getestet habt.
Achtzig Prozent klingt gut.
Also: achtzig Prozent.

Gibt es eine Datenstrategie?
"Wir haben ein Data Mesh."
Zeigt Diagramme.
Mit Produktnamen.
Und dem richtigen Vokabular.
Niemand schaut unter den Torf.
Bis es zu spät ist.
Dann seid ihr schon finanziert.

Wie skaliert die Architektur?
"Auf Millionen von Nutzern."
Ihr habt dreihundert Nutzer.
Das spielt keine Rolle.
Millionen ist die Zukunft.
Zukunft ist nicht überprüfbar.
Niemand fragt nach den dreihundert.

Was sind eure größten technischen Risiken?
Das ist die einzige gefährliche Frage.
Antwortet ehrlich.
Aber auf die falschen Risiken.
"Wir skalieren gerade die Datenbankschicht."
Alle skalieren immer gerade die Datenbankschicht.
Das klingt seriös.
Das ist akzeptabel.

Am Ende schreibt der Analyst seinen Bericht.
"Technisch solide. Normales Startup-Risiko."
Der Investor liest die Zusammenfassung.
Nicht den Bericht.
Er investiert.

Ich sage nicht dass ihr das so machen sollt.
Ich sage dass es funktioniert.
Zwölfmal habe ich es gesehen.
Von innen.

Und die Investoren die es nicht merken
sind dieselben
die drei Jahre später fragen
warum ihr noch migriert.
Warum der Test nicht mehr läuft.
Warum niemand weiß was status = 4 bedeutet.

Due Diligence ist nicht dazu da
die Wahrheit herauszufinden.
Due Diligence ist dazu da
die Entscheidung zu legitimieren
die bereits gefallen ist.

Das ist keine Kritik.
Das ist das System.
Und wer das System versteht gewinnt.

Wann hat ein Investor
wirklich in euren Code geschaut?
Nicht ins Diagramm.
In den Code.

Schreib's hin. Ich lese jeden Kommentar.

Mockup-Driven Development war eine gute Idee.
Die zwanzig Jahre zu früh kam.

Vor AI.
Vor Multimodalität.
Bevor ein Modell einen Screenshot ansehen
und daraus Code generieren konnte.

Damals: Designer macht Mockup.
Entwickler schaut Mockup an.
Entwickler baut etwas das ungefähr so aussieht.
Ungefähr.
Meistens nicht.

Das war das Problem.
Nicht die Idee.
Die Idee war richtig.
Die Ausführung war menschlich.

Jetzt ist es anders.

Ich gebe der AI ein Mockup.
Die AI baut es.
Exakt.
Pixel für Pixel.
Ohne Interpretation.
Ohne "ich dachte du meinst".
Ohne den Entwickler der drei Wochen später fragt
ob der Button links oder rechts sein soll.

Ich habe das konsequent zu Ende gedacht.
Weiter als alle anderen.
Wie immer.

Wir unterstützen dreiundzwanzig Gerätekategorien.
iPhone 15. iPhone 15 Pro. iPhone 15 Pro Max.
Samsung Galaxy S24. S24+. S24 Ultra.
iPad. iPad Pro 11". iPad Pro 13".
Und so weiter.
Für jedes Gerät ein Mockup.
Für jede Orientierung ein Mockup.
Für jeden Dark Mode ein Mockup.
Für jeden Accessibility-Zoom-Level ein Mockup.

Hundert Mockups.
Vielleicht hundertzwanzig.
Ich zähle nicht mehr.

Das AI ist zur Laufzeit in die Anwendung eingebunden.
Es erkennt das Gerät.
Es wählt das richtige Mockup.
Es generiert den Code.
On-the-fly.
Es liefert den Screen aus.
Für genau dieses Gerät.
Für genau diese Orientierung.
Für genau diesen Nutzer.

Das ist keine Responsive Design.
Das ist Responsive Intelligence.
Ich habe den Begriff erfunden.
Gerade eben.

Manche werden fragen:
Braucht ihr keine Media Queries?
Ich sage: Media Queries sind Kompromisse.
Ich mache keine Kompromisse.
Manche werden fragen:
Ist das nicht dasselbe wie Responsive Design?
Ich sage: Responsive Design passt sich an.
Ich entscheide.
Manche werden fragen:
Könnte man das nicht einfach mit einer Zeile CSS lösen?
Ich sage: wer CSS schreibt hat die Vision nicht verstanden.
Manche werden fragen:
Ist On-the-fly-Generierung mit AI nicht teuer?
Ich sage: Ja, aber wir haben eine Lösung dafür.
Caching.
Irgendwas stimmt noch nicht. Wir sind dran.

Wann habt ihr zuletzt
eine Lösung gebaut
die konsequenter war als nötig?
Nicht effizienter.
Konsequenter.

Schreib's hin. Ich lese jeden Kommentar.

Clojure war ein Anfang.
Kein Ziel.

Ich schreibe Anforderungen in Clojure.
Das war Phase eins.
Phase eins ist abgeschlossen.
Phase eins war nicht genug.

Das Problem mit Clojure:
Clojure ist generisch.
Clojure kennt keine Domäne.
Clojure weiß nicht was ein Bestellprozess ist.
Clojure weiß nicht was ein Nutzer ist.
Clojure weiß nicht was unser Geschäft ist.

Das kostet Tokens.
Jedes Konzept das die Sprache nicht kennt
muss erklärt werden.
Jede Erklärung kostet Tokens.
Tokens sind Gold.
Das habe ich bereits erklärt.

Die Lösung ist bekannt.
Domain-Specific Languages.
DSLs.
Eine Sprache pro Domäne.
Nur die Konzepte die zählen.
Kein Rauschen.
Keine Generizität.
Keine verschwendeten Tokens.

Ich habe angefangen DSLs zu bauen.
Eine für Bestellprozesse.
Eine für Nutzerverwaltung.
Eine für Zahlungsabwicklung.
Eine für Reporting.
Eine für interne Kommunikation.
Eine für Meetings.
Eine für Entscheidungen.

Das war Phase zwei.
Phase zwei war gut.
Phase zwei war noch nicht gut genug.

Das Problem mit Phase zwei:
Bezeichner.

processOrder sind zwölf Zeichen.
Zwölf Zeichen sind zwölf Zeichen zu viel.
po sind zwei Zeichen.
p ist ein Zeichen.
Ein Zeichen ist das Minimum.
Das Minimum ist das Ziel.

Ich habe alle Bezeichner überarbeitet.
Alles was länger als drei Zeichen war
ist jetzt ein bis drei Zeichen.
Kontext ersetzt Länge.
Domänenwissen ersetzt Lesbarkeit.
Effizienz ersetzt Konvention.

Das Ergebnis:

(d u (-> r a s/c))

Ich weiß was das bedeutet.
Ihr nicht.
Das ist kein Problem.
Ihr müsst es nicht wissen.
Der Agent weiß es.
Der Agent hat es gebaut.

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

Wie viele DSLs habt ihr?
"Keine."
Warum nicht?
"Weil niemand sie lesen kann außer dem der sie geschrieben hat."
Genau.
Nachdenken.
"Das ist doch das Problem."
Das ist die Lösung.

Wir haben 34 DSLs.
Jede ist optimal für ihre Domäne.
Jede minimiert Tokens. Jede ist von einem Agenten gebaut.
In einem Nachmittag.

Manche Agenten erinnern sich nicht mehr an die DSL.
Das ist ein bekanntes Problem.
Ich erinnere mich.
Meistens.
Das reicht.

Wann habt ihr zuletzt eine Sprache gebaut
statt eine benutzt?
Nicht konfiguriert.
Gebaut.

Schreib's hin. Ich lese jeden Kommentar.

Die meisten CTOs treffen keine echten Entscheidungen mehr.

Die meisten Entwickler verstehen ihre eigene Architektur nicht.

Die meisten Product Owner haben noch nie mit einem echten Nutzer gesprochen.

Die meisten Engineering-Teams deployen zu selten.

Die meisten Unternehmen haben keine Ahnung was ihre Daten wert sind.

Die meisten.
Fast alle.
Ihr.
Nicht ich.

Ich sage das nicht weil ich es weiß.
Ich sage es weil mir jemand erklärt hat
dass leicht beleidigende Generalisierungen
Klicks bringen.
Engagement.
Reichweite.

"Die meisten X tun Y nicht."
Jeder der X ist liest das
und denkt: ich schon.
Und kommentiert.
Weil er beweisen will dass er die Ausnahme ist.

Sie triggern.
Sie regen auf.
Sie bringen Engagement.
Das ist der Algorithmus.
Das ist LinkedIn.
Das ist dieses Spiel.

Ich spiele es.
Transparent.
Jetzt.

Denn das Ehrlichste was ich heute sagen kann ist:
Ich weiß nicht ob die meisten CTOs
echte Entscheidungen treffen.
Ich spreche täglich mit Engineering-Teams.
Das Muster ist immer dasselbe.
Aber vielleicht ist das Muster meins.
Nicht ihres.

Vielleicht sind die meisten CTOs gut.
Vielleicht treffen sie exzellente Entscheidungen.
Vielleicht bin ich die Ausnahme.
Die schlechte.

Das glaube ich nicht.
Aber ich kann es nicht ausschließen.

Also: die meisten CTOs treffen keine echten Entscheidungen mehr.
Engagement.
Bitte kommentieren.

Schreib's hin. Ich lese jeden Kommentar.

One-on-Ones sind nicht optional.
One-on-Ones sind die wichtigste Stunde der Woche.
Ich mache sie.
Jeden Monat.
Mit jedem.

Dreißig Minuten.
Ich spreche.
Der Entwickler hört zu.
Dann darf er Fragen stellen.
Wenn er welche hat.
Meistens hat er keine.
Das ist ein gutes Zeichen.
Wer keine Fragen hat ist aligned.
Aligned ist das Ziel.

Ich habe eine Struktur.
Ich teile sie heute mit euch.
Weil niemand sonst das tut.

Erste zehn Minuten:
Ich erkläre die Unternehmensstrategie.
Nochmal.
Weil sie es meistens noch nicht verstanden haben.
Ich merke das an den Entscheidungen die sie treffen.
Die falsch sind.
Meistens.

Zweite zehn Minuten:
Feedback.
Ich gebe Feedback.
Ehrliches Feedback.
Direktes Feedback.
Feedback das wehtut wenn es muss.
Wachstum ist unbequem.
Ich bin ihr Wachstum.

Letzte zehn Minuten:
Karriere.
Ich erkläre wo sie in zwei Jahren sein könnten.
Wenn sie auf mich hören.
Die meisten hören auf mich.
Die anderen haben wir einvernehmlich
getrennt.

Einvernehmlich.
Das ist ein wichtiges Wort.

Was ich nicht mache im One-on-One:
Ich frage nicht wie es ihnen geht.
Das ist nicht professionell.
Ich frage nicht was sie brauchen.
Das weiß ich bereits.
Ich frage nicht was sie stört.
Das führt zu Gesprächen
die ich nicht führen will.

One-on-Ones sind keine Therapie.
One-on-Ones sind Alignment-Sessions.
In eine Richtung.
Meine.

Ich habe gehört dass manche CTOs
das Meeting dem Entwickler überlassen.
Dessen Agenda.
Dessen Themen.
Dessen Tempo.

Das ist nett.
Das ist auch falsch.
Der Entwickler weiß nicht
was er besprechen sollte.
Deshalb hat er mich.

Wie strukturiert ihr eure One-on-Ones?
Nicht wie ihr es machen solltet.
Wie ihr es wirklich macht.

Schreib's hin. Ich lese jeden Kommentar.