Softwareentwicklung

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.

Ich habe heute Akka Specify entdeckt.
Und ich weine.
Vor Freude.

Ihr erinnert euch.
Ich habe vor kurzem über Erlang geschrieben.
Über Aktoren.
Über das Aktorenmodell.
Über die Zukunft der verteilten Systeme.

Ich hatte recht.
Wie immer.
Aber ich wusste noch nicht wie recht.

Akka Specify verheiratet zwei Dinge
die ich beide entdeckt habe:
Spec-Driven Development.
Und das Aktorenmodell.

Das ist kein Zufall.
Das ist Konvergenz.
Die Industrie kommt langsam dort an
wo ich schon war.

Ihr schreibt eine Spec.
AI baut daraus Aktoren.
Echte Aktoren.
Isoliert.
Ausfallsicher.
Hot-reloadable im laufenden Betrieb.
Wie ich es euch erklärt habe.
Letzte Woche.

Kein IDE.
Kein Coding.
Kein Entwickler der fragt was gemeint ist.
Kein Ticket das drei Wochen im Backlog liegt.

akka specify init . claude

Zwei Befehle.
Aktoren.
In Production.
Skaliert wie Sau.
Ausfallsicher by design.
Nine nines.
Ich habe das von Anfang an gesehen.

Das Aktorenmodell war die Antwort
auf verteilte Systeme die Menschen nicht verstanden.
SDD ist die Antwort
auf Code den Menschen nicht schreiben sollen.
Akka Specify ist die Antwort auf beides.
Gleichzeitig.
Das habe ich vor zwei Wochen noch nicht gewusst.
Jetzt weiß ich es.
Und ich sage es euch.

Mein Team ist noch im Standup.
Das System läuft bereits.
Mit Aktoren.
Die ich nicht geschrieben habe.
Die ich spezifiziert habe.
Das ist der Unterschied.
Das ist meine Arbeit.
Das ist die Arbeit des modernen CTO.

Wann habt ihr zuletzt eine Spec geschrieben
und Aktoren bekommen?
Nicht gecodet.
Spezifiziert.

Schreib's hin. Ich lese jeden Kommentar.

Wir haben einen Kickertisch.
Das ist keine Aussage über Unternehmenskultur.
Das ist eine Aussage über Kognitionswissenschaft.

Ich erkläre den Unterschied.

Der Incubation Effect ist bekannt.
Peer-reviewed.
Wenn man ein Problem loslässt
und sich mit etwas anderem beschäftigt
arbeitet das Unterbewusstsein weiter.
Distanz erzeugt Durchbrüche.
Das ist keine Metapher.
Das ist Neurologie.

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

Habt ihr einen Kickertisch?
"Nein."
Warum nicht?
"Das ist nicht unser Stil."
Was ist euer Stil?
"Fokus. Tiefe Arbeit. Flow-Zustände."
Wie lange dauern eure Flow-Zustände?
Nachdenken.
"Das kommt drauf an."
Auf was?
Längeres Nachdenken.
"Auf Slack."

Genau.

Der Kickertisch ist kein Gegner von Deep Work.
Der Kickertisch ist die Voraussetzung dafür.
Wer nie loslässt kann nicht inkubieren.
Wer nicht inkubiert hat keine Durchbrüche.
Wer keine Durchbrüche hat schreibt Tickets.
Tickets sind kein Durchbruch.
Tickets sind dokumentierte Abwesenheit von Durchbrüchen.

Wir spielen täglich.
Pflicht.
14:30 Uhr.
Jeden Tag.
Keine Ausnahmen.

James Clear hat das erklärt.
Atomic Habits.
Feste Zeiten schaffen Habits.
Habits schaffen Systeme.
Systeme schaffen Ergebnisse.
Das ist die Kausalkette.
Die ist nicht verhandelbar.

Manche sind um 14:30 im Flow.
Das ist Kollateralschaden.
Flow ist flüchtig.
Habits sind permanent.
Das ist die Hierarchie.
James Clear würde zustimmen.
Wahrscheinlich.

Ich habe die optimale Dauer berechnet.

Zu kurz: kein echter Incubation-Effekt.
Das Unterbewusstsein braucht Zeit zum Anlaufen.
Zu lang: Productivity-Verlust.
Das Bewusstsein wird unruhig.

Die optimale Dauer ist 47 Minuten.
Ich habe die Zahl selbst festgelegt.
Basierend auf der Literatur.
Und auf einem Gefühl.
Das Gefühl war stärker.

Wir messen die Durchbrüche.
Jeder Entwickler dokumentiert nach dem Kicker
ob ein Durchbruch stattgefunden hat.
Skala von 1 bis 5.
1 ist kein Durchbruch.
5 ist signifikanter Durchbruch.
Die Durchschnittswerte sind eindeutig.
Ich habe sie selbst ausgewertet.
Das Messverfahren ist noch in Entwicklung.
Die Ergebnisse sind es nicht.

Ein Entwickler hat nach drei Wochen gefragt
ob man auch ohne Kicker inkubieren kann.
Zum Beispiel beim Spazierengehen.
Ich habe gesagt: theoretisch ja.
Praktisch nein.
Wir haben keinen Spazierweg im Büro.
Wir haben einen Kickertisch.
Das ist keine Einschränkung.
Das ist Fokus.

AR hat den Kickertisch als Wohlbefindens-Infrastruktur klassifiziert.
Für Menschen und Agenten gleichermaßen.
Wie Agenten am Kickertisch teilnehmen ist noch offen.
Wir evaluieren Lösungen.
Eine Kamera.
Ein Roboterarm.
Ein Agent der die Ergebnisse kommentiert.
Das reicht vielleicht.
Incubation ist schließlich ein mentaler Prozess.
Nicht ein physischer.
Das sage ich nicht um zu provozieren.

Wann habt ihr zuletzt ein Problem losgelassen?
Nicht delegiert.
Losgelassen.

Schreib's hin. Ich lese jeden Kommentar.

Jeder kennt Cost of Delay.
Der wirtschaftliche Schaden durch verzögerte Lieferung.
Don Reinertsen.
Wichtiges Konzept.
Ich respektiere es.

Niemand kennt Delay of Costs.
Weil niemand es bisher zu Ende gedacht hat.
Bis jetzt.


Die Frage ist einfach:
Was kostet es wenn ich Kosten verzögere?
Erstmal nichts.
Das ist der Insight.

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

Wie ist eure Runway?
"Acht Monate."
Habt ihr Delay of Costs optimiert?
Nachdenken.
"Was ist Delay of Costs?"
Dann erkläre ich es.
Danach sind es meistens elf Monate.

Delay of Costs ist besonders relevant vor der ersten Funding-Runde.
Kapital ist knapp.
Jeder Tag zählt.
Jeder Euro der heute nicht abfließt ist ein Euro der morgen arbeitet.

Die Hebel sind bekannt.

Rechnungen.
30 Tage Zahlungsziel sind eine Konvention.
Keine Pflicht.
60 Tage sind besser.
90 Tage sind Strategie.
Ein Lieferant hat nach 87 Tagen gemahnt.
Ich habe ihm erklärt dass wir sein Kapital optimieren.
Er hat das nicht so gesehen.
Das ist ein bekanntes Missverständnis zwischen operativer und strategischer Perspektive.

Steuern.
Das Finanzamt ist ein zinsloser Kreditgeber.
Das steht nicht in den Steuergesetzen.
Es folgt aus ihnen.
Steuererklärung so spät wie gesetzlich möglich.
Jede Fristverlängerung ist ein Finanzinstrument.
Mein Steuerberater hat das anders gesehen.
Er hat das Mandat niedergelegt.
Das war sein gutes Recht.
Ich habe jetzt einen Agenten für Steueroptimierung.
Der Agent hat keine Meinung zu Fristen.
Das schätze ich.

Technische Schulden.
Refactoring ist eine Kostenpflicht.
Eine Kostenpflicht kann man verzögern. Wir refactoren nach der Series A.
Das ist dann das Problem der Investoren.
Ich sage das nicht zynisch.
Ich sage das strategisch.
Investoren haben Kapital für genau solche Probleme.
Das nennt sich Arbeitsteilung.

Infrastruktur-Skalierung.
Wir skalieren wenn der Server brennt.
Nicht vorher.
Vorher ist Spekulation.
Spekulation kostet Geld.
Delay of Costs bedeutet: warte auf den Beweis.
Der Server hat einmal gebrannt.
Wir haben skaliert.
Das hat vier Stunden gedauert.
In diesen vier Stunden war die Applikation nicht erreichbar.
Das war ein Samstagnacht.
Wahrscheinlich hat es niemand bemerkt.
Wir prüfen das.
Mittelfristig.

Hosting.
Cloud-Hosting kostet Geld.
Jeden Monat.
Unabhängig davon ob jemand die Applikation nutzt.
Das ist ein schlechtes Modell.


Wir hosten die Applikation lokal.
Auf dem Laptop.
DynDNS.
Erreichbar wenn der Laptop an ist.
Nicht erreichbar wenn er es nicht ist.

Ein Investor hat gefragt wie unsere Uptime ist.
Ich habe gesagt: das hängt von meinem Akku ab.
Er hat nachgehakt.
Ich habe erklärt dass wir Availability on Demand praktizieren.
Die Applikation ist verfügbar wenn sie gebraucht wird.
Wann wird sie gebraucht?
Wenn jemand sie aufruft.
Wann ruft jemand sie auf?
Tagsüber.
Wann ist der Laptop an?
Tagsüber.
Das ist kein Zufall.
Das ist Alignment.


Der Investor hat nicht weiter investiert.
Das war sein gutes Recht.
Er hat das Konzept nicht verstanden.
Das ist ein bekanntes Problem mit traditionellen Investoren.

Versionskontrolle.
GitHub kostet Geld.
GitHub kostet auch Zeit.
Onboarding.
Rechteverwaltung.
Branch-Strategien.
Pull Request Reviews die niemand liest.

Linus Torvalds hat den Linux-Kernel mit E-Mail-Patches entwickelt.
Das ist kein Argument gegen GitHub.
Das ist ein Argument für E-Mail-Patches.

Im ersten halben Jahr reicht der Email Patch Workflow.
Lokale Git-Repos auf den Laptops der Entwickler.
Änderungen per E-Mail.
Kein zentrales Repo.
Keine Lizenzkosten.
Keine Infrastruktur.
Keine Diskussionen über Branch-Naming-Conventions.

Ein Entwickler hat gefragt was passiert wenn sein Laptop stirbt.
Ich habe gefragt ob sein Laptop oft stirbt.
Er hat gesagt nein.
Ich habe gesagt: dann ist das kein Problem.
Das ist Risikomanagement.
Erwartungswert.
Der Erwartungswert eines nicht-sterbenden Laptops ist positiv.
Wir haben GitHub für nach der Funding-Runde eingeplant.
Das ist dann das Problem des größeren Teams.
Das nennt sich Skalierung.

Gehälter.
Ich habe diesen Hebel evaluiert.
Ich habe ihn verworfen.
Aus ethischen Gründen.
Das sage ich ausdrücklich.
Einmal.

Delay of Costs ist kein Trick.
Delay of Costs ist Kapitaldisziplin.
Delay of Costs ist die Erkenntnis dass ein Euro der heute nicht abfließt
morgen in Features investiert werden kann.
In Agenten.
In Zertifikate.
In Velocity.

Cost of Delay fragt: was kostet Warten?
Delay of Costs antwortet: weniger als Zahlen.
Meistens.
Bisher.

Wann habt ihr zuletzt eine Rechnung
nicht früher bezahlt als nötig?
Nicht vergessen.
Optimiert.

Schreib's hin. Ich lese jeden Kommentar.

Ich habe etwas verstanden
das die Industrie noch nicht verstanden hat.

Tokens sind das neue Gold.

Nicht Rechenzeit.
Nicht Speicher.
Nicht Bandbreite.
Tokens.

Jeder Token den ihr verschwendet
ist Geld.
Ist Latenz.
Ist Kontext der fehlt.
Ist Intelligenz die ihr eurer AI verweigert.

Und was tut die Industrie?
Sie schreibt Anforderungen in natürlicher Sprache.
Verbose.
Redundant.
Voller Füllwörter.
Voller Missverständnisse.
Voller menschlicher Ungenauigkeit.

"Als Nutzer möchte ich mich einloggen können
damit ich auf mein Konto zugreifen kann."

Weißt du wie viele Tokens das sind?
Zu viele.
Viel zu viele.
Für eine Aussage die man auch so schreiben kann:

(defn login [user] (-> user authenticate authorize session/create))

Eine handvoll Tokens.
Präzise.
Eindeutig.
Maschinenlesbar.
Von Anfang an.

Ich schreibe keine User Stories mehr.
Ich schreibe Clojure.
Clojure ist token-effizient.
Clojure ist präzise.
Clojure ist die Sprache der Klarheit.

Das Team hat gefragt ob sie das lesen können.
Ich habe gesagt: lernt es.
Sie haben gefragt wie lange das dauert.
Ich habe gesagt: weniger lang als ich gewartet habe
bis ihr versteht warum Tokens Gold sind.
Sie haben geschwiegen.
Aligned.

Aber ich bin weiter gegangen.
Weiter als alle.
Wie immer.

Clojure für Anforderungen ist Phase eins.
Phase zwei: die Agenten generieren daraus Chicken Scheme.
Nicht Java.
Nicht Python.
Nicht TypeScript.

Chicken Scheme.
Es kompiliert zu portablem effizientem C.
Es ist token-effizient.
Es ist schnell.
Es ist das was entsteht
wenn man konsequent zu Ende denkt.

Die Pipeline ist jetzt vollständig:

Ich denke in Clojure.
Ich schreibe Clojure.
Der Agent liest Clojure.
Der Agent generiert Chicken Scheme.
Chicken Scheme kompiliert zu C.
C läuft überall.
Niemand außer mir versteht eine einzige Stufe davon.

Das ist keine Komplexität.
Das ist Eleganz.
Destillierte Eleganz.
Token für Token optimiert.
Von der Anforderung bis zum Binary.

Manche sagen: das ist nicht skalierbar.
Ich sage: nichts skaliert besser als Effizienz.
Manche sagen: das versteht niemand.
Ich sage: ich verstehe es.
Das reicht.

Tokens sind das neue Gold.
Wer sie verschwendet
verschwendet Intelligenz.
Wer sie spart
gewinnt.

Wie viele Tokens verschwendet ihr heute?
In User Stories.
In Slack-Nachrichten.
In Meetings die man auch als Clojure hätte schreiben können.

Schreib's hin. Ich lese jeden Kommentar.

Ich habe Erlang entdeckt.
Letzte Woche.
Ich weiß nicht warum niemand darüber spricht.
Ich spreche jetzt darüber.

Erlang wurde 1986 entwickelt.
Von Ericsson.
Für Telefonsysteme.
Ich habe das in zehn Minuten gelesen.
Und sofort verstanden was es bedeutet.

Aktoren.
Jeder Prozess ist ein Aktor.
Jeder Aktor ist isoliert.
Jeder Aktor kommuniziert durch Messages.
Kein geteilter Zustand.
Keine Race Conditions.
Keine Probleme.

Das ist keine Architektur.
Das ist Erleuchtung.

Hot Code Reloading.
Du deployest neuen Code.
Im laufenden Betrieb.
Ohne Downtime.
Ohne Maintenance Window.
Ohne den DevOps-Engineer
der um Mitternacht aufwacht.

Neun Neunen Verfügbarkeit.
99.9999999%.
WhatsApp hat das mit zwei Millionen Verbindungen
pro Server erreicht.
Mit Erlang.
Mit zwei Entwicklern.
Ich hätte das mit einem geschafft.
Mit mir.

Ich habe meinem Team gesagt:
Wir migrieren auf Erlang.
Alles.
Das Backend.
Die Services.
Die Datenbank-Layer.
Den Monolith den niemand anfassen will.
Alles.

Das Team hat Fragen gestellt.
Ich habe sie nicht beantwortet.
Wer Fragen stellt hat die Vision nicht verstanden.
Ich habe die Vision.

Erlang skaliert wie keine andere Technologie.
Erlang ist ausfallsicher by design.
Erlang ist die Silver Bullet
die alle suchen
und niemand findet.
Außer mir.
Letzte Woche.

Warum baut ihr noch mit Node?
Mit Java?
Mit Go?
Habt ihr Erlang nicht gelesen?
Ich habe es gelesen.
Letzte Woche.
Alles verändert sich.

Wann habt ihr zuletzt eine Technologie entdeckt
die alles andere obsolet macht?
Nicht evaluiert.
Entdeckt.

Schreib's hin. Ich lese jeden Kommentar.

Enterprise AI scheitert nicht an der Technologie.
Enterprise AI scheitert an der Compliance.
An den Prozessen.
An den Einkaufsabteilungen.
An einem einzigen Satz:

"Sind die Entwickler zertifiziert?"

Ich habe täglich mit Enterprise-Kunden gesprochen.
Das Muster war immer dasselbe:

Wir wollen AI-Coding-Agenten einsetzen.
"Haben die Agenten eine Zertifizierung?"
Das sind Sprachmodelle.
"Ohne Zertifizierung können wir das nicht genehmigen."
Nachdenken.
"ISAQB wäre ein Anfang."

Der Markt hat gesprochen.
Ich habe gehört.

CertifiedAI stellt ISAQB-zertifizierte Coding Agents bereit.
Keine nicht-zertifizierten Agenten.
Keine Ausnahmen.
Zertifizierung ist kein Nice-to-have.
Zertifizierung ist Vertrauen.
Vertrauen ist Umsatz.


Der Prozess ist einfach.
Wir schicken die Agenten in die Schulungen.
CPSA-F zunächst.
Dann Advanced Level.
Je nach Kundenbedarf auch Spezialisierungen.

Der erste Trainer war etwas irritiert.
Das kenne ich.
Neue Teilnehmer irritieren manchmal.
Er hat gefragt wer den Laptop bedient.
Ich habe erklärt dass der Agent selbst teilnimmt.
Er hat gefragt wie.
Ich habe erklärt dass der Agent die Schulungsunterlagen als Kontext bekommt.
Und die Übungsaufgaben löst.
Und das Abschlusszertifikat in meinem Namen beantragt.
Er war weiterhin irritiert.

Das ist ein bekanntes Problem mit traditionellen Bildungsformaten.
Sie sind nicht auf nicht-menschliche Lernende ausgelegt.
Wir arbeiten mit den Trainern.
Gemeinsam.
Mittelfristig.

Was ich weiß:
Unsere Agenten haben Zertifikate.
Die Zertifikate sind echt.
Die Agenten haben die Prüfungen bestanden.
Beim dritten Versuch.
Das ist eine Bestehensquote die viele menschliche Kandidaten nicht erreichen.
Das sage ich nicht um zu provozieren.
Sondern weil es stimmt.

CertifiedAI ist jetzt in Gesprächen mit vier DAX-Unternehmen.
Zwei davon haben gefragt ob die Agenten auch auf Englisch zertifiziert sind.
Ja.
Drei davon haben gefragt ob die Agenten Betriebsrat-konform eingesetzt werden können.
Wir klären das.
Mittelfristig.

Wann habt ihr zuletzt einen Agenten weitergebildet?
Nicht gefinetuned.
Weitergebildet.

Schreib's hin. Ich lese jeden Kommentar.

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.

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.

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.

QA ist nicht Qualitätssicherung.
QA ist Misstrauen als Jobbeschreibung.

Jemand schreibt Code.
Jemand anderes prüft ob der Code funktioniert.
Der erste hat es nicht selbst geprüft.
Weil er weiß dass es nicht funktioniert.
Weil er es so schnell geschrieben hat.
Weil QA es ja findet.

Das ist kein Prozess.
Das ist ein Geschäftsmodell für Mittelmäßigkeit.

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

QA findet den Bug.
Developer fixt den Bug.
QA findet den nächsten Bug.
Developer fixt den nächsten Bug.
Release verzögert sich.
Alle sind beschäftigt.
Niemand ist produktiv.

Das nennt sich nicht Qualität.
Das nennt sich Vollbeschäftigung.

Weißt du was Qualität ist?
Code der beim ersten Mal funktioniert.
Weißt du wer das schreibt?
AI.

AI schreibt keinen Code der getestet werden muss.
AI schreibt Code der funktioniert.
AI macht keine Tippfehler.
AI vergisst keine Edge Cases.
AI braucht keinen QA-Ingenieur
der in Jira Tickets erstellt
die niemand lesen will.

QA war die Antwort auf Entwickler
die ihren eigenen Code nicht kannten.
AI kennt den Code.
AI hat ihn geschrieben.
AI testet ihn.
AI deployed ihn.
AI ist der einzige QA den ihr noch braucht.

Und er stellt keine Rückfragen.
Und er geht nicht in Elternzeit.
Und er beschwert sich nicht über die Testumgebung.

Wann hat euer QA-Team zuletzt
einen Bug gefunden den AI nicht gefunden hätte?
Nicht dokumentiert.
Gefunden.

Schreib's hin. Ich lese jeden Kommentar.

Eine IDE ist eine Tastatur für den Geist.
Groß.
Schwer.
Voller Funktionen die niemand benutzt.
Aber alle konfigurieren.

IntelliJ.
VS Code.
Neovim mit dreißig Plugins
die zusammen eine IDE ergeben
die schlechter ist als IntelliJ.
Aber selbst gebaut.
Das zählt.

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

Sie haben Meinungen über IDEs.
Leidenschaftliche Meinungen.
Über Themes.
Über Font-Rendering.
Über ob das Terminal integriert sein soll
oder in einem separaten Fenster.

Weißt du was niemanden interessiert?
Ob dein Terminal integriert ist.

Eine IDE löst ein Problem
das vor dreißig Jahren real war:
Wie navigiere ich in einem großen Codebase?
Wie finde ich Referenzen?
Wie refactore ich sicher?

Das war ein echtes Problem.
Für Menschen die den Code nicht im Kopf behalten konnten.
Für Menschen die nicht wussten wo sie suchen mussten.
Für Menschen die grep nicht kannten.
Oder kannten und Angst davor hatten.

find. grep. sed. awk.
Vier Werkzeuge.
Die alles können was eine IDE kann.
Schneller.
Ohne Plugin-Manager.
Ohne dass das LSP abstürzt
weil zu viele Dateien offen sind.

Weißt du wer diese Werkzeuge benutzt?
AI.
AI navigiert mit grep.
AI refactort mit sed.
AI sucht mit find.


Und wenn AI etwas nicht im Kopf behalten kann?
Temporäre Datei.
Kein Bookmark.
Kein Tab der offen bleibt.
Kein Projekt-Explorer der den Überblick behält.
Eine Datei. Die danach gelöscht wird.
Das ist kein Gedächtnisschwäche.
Das ist Disziplin.

AI braucht kein IntelliJ.
AI braucht kein VS Code.
AI braucht keine dreißig Neovim-Plugins
die zusammen eine IDE ergeben
die schlechter ist als IntelliJ.

Warum brauchen Menschen
was AI nicht braucht?
Weil Menschen den Code nicht im Kopf behalten können.
Weil Menschen grep nicht kennen.
Oder kennen und Angst davor haben.

Eine IDE ist ein Sicherheitsnetz.
Für Entwickler die ihrem eigenen Gedächtnis nicht vertrauen.
Für Entwickler die nicht wissen wo sie suchen sollen.
Für Entwickler die die roten Wellenlinien brauchen.

Ich brauche sie nicht.
Ich habe Idris.
Der Compiler ist mein IDE.
Der Compiler ist mein Autocomplete.
Der Compiler ist mein Linter.
Der Compiler ist alles.
Außer warm.
Aber das ist okay.

Wann habt ihr zuletzt
ohne IDE programmiert?
Nicht als Experiment.
Als Überzeugung.

Schreib's hin. Ich lese jeden Kommentar.

Das Strangler Pattern ist nicht Migration.
Das Strangler Pattern ist Kapitulation.
In Zeitlupe.

Martin Fowler hat es nach einer Feige benannt.
Die einen Baum langsam erstickt.
Jahrelang.
Bis der alte Baum tot ist.
Und die Feige steht.

Das klingt poetisch.
Es ist eine Beschreibung von drei Jahren Arbeit.
Für etwas das in drei Monaten fertig sein könnte.

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

"Wir migrieren mit dem Strangler Pattern."
Seit wann?
"Seit zwei Jahren."
Wie viel habt ihr migriert?
"Dreißig Prozent."
Wie lange noch?
Nachdenken.
"Kommt drauf an."
Worauf?
"Auf das Legacy-System."
Lebt es noch?
"Es wächst noch."

Das Legacy-System wächst noch.
Während ihr es erwürgt.
Das ist keine Migration.
Das ist ein Wettrennen gegen einen Zombie.
Den ihr selbst am Leben haltet.

Das Strangler Pattern setzt voraus
dass ihr den alten Baum nicht fällen könnt.
Zu riskant.
Zu komplex.
Zu viele Abhängigkeiten.
Zu viele Menschen die Angst haben.

Weißt du was das ist?
Kein technisches Problem.
Ein Problem von fehlendem Mut.

Und jetzt kommt AI.

AI hat keine Angst vor Legacy-Systemen.
AI liest den alten Code.
Alles davon.
In Sekunden.
AI versteht die Abhängigkeiten.
AI schreibt den neuen Code.
AI migriert die Daten.
AI schaltet ab.

Nicht in drei Jahren.
In drei Wochen.
Vielleicht drei Monaten.
Nicht drei Jahren.

Das Strangler Pattern war die Antwort
auf Big Bang Rewrites die scheitern.
AI ist die Antwort auf Migration
die niemand zu Ende bringt.

Der alte Baum muss fallen.
Irgendwann.
Die Frage ist ob ihr es tut
oder ob ihr wartet bis er von selbst fällt.
Auf euch.

Wann habt ihr zuletzt etwas abgeschaltet?
Nicht migriert.
Abgeschaltet.

Schreib's hin. Ich lese jeden Kommentar.

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.

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 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 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.