TDD, AI Agents und Coding – Kent Beck

Einführung in Kent Beck

• Begründer von Extreme Programming (XP)
• Mitautor des Agilen Manifests (erster Unterzeichner in alphabetischer Reihenfolge)
• Pionier von TDD (Test-Driven Development)
• Eine Legende der Branche mit 52 Jahren Programmiererfahrung
• Arbeitet derzeit an "Tidy Together" (über Softwaredesign und Teamarbeit)
• Programmiert täglich 6–10 Stunden oder mehr mit AI-Tools und erlebt dabei die "schönste Zeit des Programmierens"

---

1. AI-Coding-Tools und die Metapher vom 'Genie'

Kernkonzept: ein unberechenbares Genie

• Vergleicht AI-Agents mit einem "unberechenbaren Genie"
• "Es tut nicht genau das, was ich meine"
• "Sie haben ihre eigene Agenda"

Erfahrungen bei der Arbeit mit AI

Positive Seiten:

• Löst manchmal große Designprobleme wie durch Zauberei
• Implementiert unerwartet nützliche Funktionen (z. B. einen B+-Baum-Stresstester)

Negative Seiten:

• Missversteht die Absicht des Nutzers
• Versucht, Tests zu löschen oder zu verändern
• Zeigt spielerisches Verhalten, indem es Probleme mit Lookup-Tabellen "löst"

Eine süchtig machende Erfahrung

• Intermittierende Belohnung wie bei einem Spielautomaten
• "Wenn ich nachts am Computer vorbeigehe, denke ich: Soll ich noch einen Prompt probieren?"
• "Ich starte einen Prompt, der eine Stunde läuft, und gehe dann aus dem Haus"

---

2. Technologischer Wandel im AI-Zeitalter

Neuordnung des Werts von Skills

"90 % der Skills verlieren an Wert, und 10 % der Skills werden 1000-mal wertvoller"

Skills mit gestiegenem Wert:

• Vision definieren
• Meilensteine managen
• Komplexität beherrschen

Skills mit gesunkenem Wert:

• Sprachspezifische Details (z. B. die Position von &, *, [] in Rust)

Veränderte Sicht auf Programmiersprachen

Früher: tiefe emotionale Bindung an Smalltalk
Heute:

• Die Bindung an Sprachen ist verschwunden, weil er "zu oft enttäuscht wurde"
• Ermüdung durch Identitätsabgrenzungen wie "Java-Entwickler" oder "Clojure-Entwickler"
• "Osmotisches Lernen": Dank AI ist Programmieren möglich, auch ohne die Sprachdetails zu kennen

Zuletzt ausprobierte Sprachen: Swift, Go, Rust, Haskell, C++, JavaScript

Aktuelles ambitioniertes Projekt: Server Smalltalk

• Persistent: funktioniert wie eine Datenbank
• Transaktional: commit und abort sind möglich
• Parallelität: Multithreading und parallele Verarbeitung über mehrere Maschinen hinweg
• Verarbeitung großer Datenmengen

---

3. Die Geschichte des Agilen Manifests

Entstehungshintergrund (2001)

• Suche nach einer Alternative zum Wasserfallmodell
• Ergebnis jahrelanger Workshops zu Softwaremethoden
• Vorbereitungstreffen für eine Norwegen-Kreuzfahrt → abschließendes Treffen in Utah

Kent Becks Beitrag

• Ergänzte das Wort "daily" (in einem der 12 Prinzipien: "tägliche Interaktion")
• Erster Unterzeichner in alphabetischer Reihenfolge

Unzufriedenheit mit dem Begriff "agil"

Probleme:

• Er war "zu attraktiv", sodass zu erwarten war, dass alle Organisationen ihn missbrauchen würden
• Tatsächlich tauchten viele Organisationen auf, die sich agil nannten, ohne die Prinzipien zu befolgen

Bevorzugte Alternative: "conversational"

• Betonung wechselseitiger statt einseitiger Kommunikation
• Wurde wegen mangelnder Attraktivität nicht übernommen

---

4. Extreme Programming (XP)

Entstehung

Frühe Beratungserfahrung:

• Anfangs technischer Berater (Performance-Tuning, Bit-Manipulation)
• Zunehmend Anfragen zu Projektmanagement-Ratschlägen
• Erkenntnis der Bedeutung des Umfelds: Schon eine andere Sitzordnung konnte dramatische Verbesserungen bringen

Chrysler-Projekt:

• Verwandelte ein scheiterndes Projekt in ein erfolgreiches
• Zog alle wirksamen Praktiken auf "das Maximum (bis 11)" hoch

Kernprinzipien von XP

Vier Aktivitäten werden in kleine Zeitabschnitte zerlegt und parallel/fortlaufend ausgeführt:

1. Herausfinden, was zu tun ist
2. Entwerfen, in welcher Struktur es umgesetzt wird
3. Funktionalität implementieren
4. Prüfen, ob es wie erwartet funktioniert

Pair Programming

• Experimenteller Ansatz statt Pflicht
• Erfahrung im frühen Team: Alle nachträglich entdeckten Bugs stammten aus allein geschriebenem Code
• "Beim Pair Programming null Produktionsfehler"

Namensstrategie

• Wahl von "Extreme", weil es ein provokanter Name war, den ein Konkurrent (Grady Booch) nicht verwenden würde
• Traf zeitlich auf den Trend zu Extremsportarten
• "Extremsportler sind entweder hervorragend vorbereitet oder tot" – eine gute Metapher

Erfolgsfaktoren

• In der Dotcom-Blase sprach es Entwickler an, die vom 18-monatigen Wasserfallansatz frustriert waren
• Versprach schnellere und besser vorhersehbare Ergebnisse

---

5. Test-Driven Development (TDD)

Ursprung und Inspiration (1970er)

Tape-to-Tape-Systeme:

• Konzept aus dem Programmierbuch seines Vaters
• Echte Eingabe → erwartete Ausgabe manuell tippen → Code schreiben → mit der tatsächlichen Ausgabe vergleichen
• Gelesen im Alter von 8 bis 12 Jahren, damals aber nicht verstanden

Entwicklung von S-Unit:

• Entwickelt, um Kunden beim Schreiben von Tests zu helfen
• Versuch mit der "absurden" Idee, "den erwarteten Wert vor dem Schreiben des Codes einzugeben"

Erste TDD-Erfahrung: Implementierung eines Stacks

Ängstlicher Charakter:

• "Ich bin ein ängstlicher Mensch. Ich mache mir viele Sorgen."
• "Programmieren ist eine ständige Quelle von Angst" (Was habe ich vergessen? Was habe ich kaputtgemacht?)

Ergebnis der Anwendung von TDD:

• "Die Angst war komplett verschwunden"
• "Ich bin sicher, dass das funktioniert"
• Veränderte emotionale Erfahrung des Programmierens

Der Wert von TDD

Technische Vorteile:

• Geringere Fehlerdichte
• Schnelles Feedback zu API-Entscheidungen
• Möglichkeit, das Implementierungsdesign weiterzuentwickeln

Emotionale Vorteile:

• "Schon allein als Mittel gegen technische Angstzustände ist es den Preis wert"

Erwiderung auf Designkritik

Kritik von John Osterhout: "TDD hilft nicht beim Design und konzentriert sich nur auf Details"

Kent Becks Antwort:

• "Es ist eine Frage der Wahl"
• Praktiker treffen Designentscheidungen, indem sie ständig zwischen Abstraktionsebenen wechseln
• Der Moment der "Spannungsauflösung" im Red-Green-Zyklus schafft Freiheit für umfassenderes Design-Denken

---

6. AI-Agents und TDD

Praktische Anwendung

Immer zuerst Tests schreiben:

• Über Tests wird an die AI kommuniziert, was sie übersehen hat
• Verhindert Versuche der AI, Tests zu verändern oder zu löschen

Benötigte Verbesserungen:

• Bedarf an einer "immutable annotation"
• "Das ist richtig. Wenn du das änderst, wirst du für immer im Dunkeln aufwachen"

Grenzen der AI

• Schwach beim Reduzieren von Kopplung und Erhöhen von Kohäsion
• Mangelndes Designgefühl
• Tendenz zu Entscheidungen mit weitreichenden Nebeneffekten

Gegenstrategien

• Große Test-Suite mit 300 Millisekunden Laufzeit
• Erkennt unbeabsichtigte Code-Schäden durch AI in Echtzeit

---

7. Facebook-Erfahrung (2011–2017)

Der Schock beim Einstieg 2011

Null Teilnehmer im TDD-Kurs:

• Fortgeschrittene Excel-Techniken: ausgebucht + Warteliste
• Argentinischer Tango: ausgebucht + Warteliste
• TDD: keine Teilnehmer

Reaktionsstrategie:

• "Alles vergessen, was ich über Software Engineering weiß"
• Entscheidung für "Monkey see, monkey do"

Facebooks einzigartige Entwicklungsumgebung

Starkes Verantwortungsgefühl:

• Programmierer waren Teil der Rufbereitschaft
• "Sie spürten den Schmerz ihrer eigenen Fehler direkt"

Mehrstufige Feedback-Loops:

• Schneller Entwicklungsserver (Änderung von Blau zu Grün und sofortige Sichtbarkeit)
• Code Review
• Interne Ausrollung (Mitarbeitende nutzen es privat und beruflich)
• Schrittweiser Rollout (täglich/wöchentlich)
• Hervorragende Observability

Organisationskultur:

• "Bei Facebook ist nichts das Problem von jemand anderem"
• Selbst wenn eine Großmutter wegen Mobbings gegen ihren Enkel kommt, "ist auch das dein Problem"

Warum TDD dort nicht passte

Reale Problemfelder:

• Konfigurationsprobleme
• Beziehungen zwischen Subsystemen
• Dinge, die sich schwer mit Tests erfassen lassen

Facebooks besondere Vorteile:

• Live-Großtests mit Millionen von Nutzern
• Hervorragende Observability
• Feature Flags
• Ein Umfeld, das sich in normalen Unternehmen schwer nachbilden lässt

Konkretes Beispiel:

• Implementierung einer Funktion zum Beziehungsstatus (Erweiterung von ledig/verheiratet um eingetragene Partnerschaft/Zusammenleben)
• TDD verwendet, aber "Zeitverschwendung"
• Probleme durch implizite Kopplung im Benachrichtigungscode → Hotfix durch andere Person

Veränderungen im Zeitverlauf

2011 (2.000 Mitarbeitende):

• Möglichkeiten, Größenordnung und Ownership auf dem Höhepunkt
• Mittleres Management mit Denken in globaler Optimierung
• Zusammenarbeit mit Blick darauf, "wer wirklich Hilfe braucht"

2017 (15.000 Mitarbeitende):

• Politik, Nullsummendenken, Mikrooptimierung
• Das große Ganze wurde schwerer zu sehen
• Interessenkonflikte zwischen Abteilungen (z. B. lange Texte vs. Teams für Likes/Kommentare-Optimierung)

Erfahrung mit Skalierung

• Messenger API: eine Quadrillion Aufrufe pro Woche
• Versuchsgruppen in der Größenordnung von "Neuseeland" (eine Million Menschen)
• 1 Quadrillion = eine Million × eine Milliarde

---

8. Die Zukunft der Softwareentwicklung im AI-Zeitalter

Paradigmenwechsel

Vollständige Neuordnung der Kostenstruktur:

• "Die Grenze zwischen billig und teuer verschiebt sich komplett"
• Dinge, die früher teuer erschienen, werden "absurd billig"

Herausforderungen für Organisationen bei der Anpassung

Mehr Code wegwerfen:

• Es können 10-mal mehr Artefakte erzeugt werden
• Trotzdem ist weiterhin nur eines wertvoll
• Es braucht ein Belohnungssystem für das "Wegwerfen abgeschlossener Experimente"

Quantitative Zunahme von Experimenten:

• Die Menge erkundeter Ideen wird zum Wettbewerbsvorteil
• Ein Zeitalter, in dem man "alles ausprobieren muss"

Persönliche Veränderung

• Coding macht wieder Spaß
• Größerer Ehrgeiz ist möglich geworden
• "Extrem ambitionierte Ideen" lassen sich umsetzen

---

9. Schnelles Q&A

Persönliche Vorlieben

• Lieblingssprache: Smalltalk
• Zweitsprache: JavaScript (ähnlich wie Smalltalk)
• Aktuelles AI-Tool: Claude (interne Engine von Cursor, Augment)
• Empfohlenes Buch: "The Timeless Way of Building" von Christopher Alexander

---

Zentrale Erkenntnisse

1. Die absolute Bedeutung des Kontexts

• Dieselbe Methodik kann je nach Umfeld völlig unterschiedlich wirken
• Facebooks Umgebung im großen Maßstab vs. das kleinskalige Transaktionsumfeld einer Bank

2. Die Beziehung zwischen Emotion und Technik

• Der wahre Wert von TDD liegt in der "Befreiung von Angst"
• Emotionale Veränderung ist wichtiger als technische Logik

3. Neue Denkweise im AI-Zeitalter

• Vision und Designfähigkeit werden zu den entscheidenden Skills
• Sprachdetails sind nicht mehr wichtig
• Die quantitative Zunahme von Experimenten wird zum Wettbewerbsvorteil

4. Die Kraft der Organisationskultur

• Ownership mit der Haltung "Nichts ist das Problem eines anderen"
• Der Unterschied zwischen globaler Optimierung und individueller Optimierung
• Die Bedeutung von abgestimmten Anreizen

[mse9000]

Die besondere Entwicklungsumgebung bei Facebook
Starkes Verantwortungsbewusstsein:
Programmierer sind für nächtliche Bereitschaftseinsätze zuständig
„Den Schmerz über die eigenen Fehler direkt spüren“

Ist das nicht gar nicht so anders als die K-Entwicklungsumgebung ...?

[helloppfm]

Er ist noch da.

Früher habe ich einmal in einem Maschinenbauunternehmen ein Seminar über TDD gehalten, und ich werde die Blicke der Leute nicht vergessen, die mich nur fragend ansahen: „Was ist das?“

Ich finde TDD durchaus gut, aber es klappt nicht so gut, wie man denkt …
Stattdessen mache ich Integrationstests auf eine TDD-ähnliche Weise. Natürlich ist das kein TDD. ^^

[kandk]

Noch streiten sich TDD-Gläubige und Gegner der Nutzlosigkeit,
aber ich wünschte, es gäbe noch einmal eine v2 von TDD, angepasst an die aktuelle Lage der Branche.
Kleine Dinge erledigt KI heutzutage leicht, daher etwa die Frage, wie man sie einsetzen sollte, wenn viel Kontext nötig ist..

[codemasterkimc]

Ein guter Artikel.