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.