Den Genie zähmen: "Wie Kent Beck programmieren"

• Ein Experiment prüfte, ob sich die Codequalität verbessert, wenn man dem AI-Coding-Tool (Genie) den Persona-Prompt "Code like Kent Beck" hinzufügt. Das Ergebnis: Teststil und Variablennamen wurden besser, aber das Architekturdesign änderte sich nicht.
• Anhand eines Projekts zur Implementierung der Rope-Datenstruktur wurde die Wirkung von Persona-Prompts und Design-Constraints vergleichend überprüft.
• Die Persona verbessert Mikroverhalten (Testweise, Benennung), während explizite Constraints die Makroarchitektur (Klassenhierarchie) bestimmen.
• Ein Experiment mit vier Gruppen zeigte, dass ein kombinierter Prompt aus Persona und Constraints die besten Ergebnisse liefert.
• Unter Verweis auf Rich Suttons "The Bitter Lesson" wird nahegelegt, dass es wirksamer ist, Rechenressourcen zu nutzen, als menschliche Expertise zu kodieren.

---

Die aktuelle Phase der AI-Coding-Tools

• Aktuelle AI-Coding-Tools (Genie) befinden sich in der Phase der "pferdelosen Kutsche".
• Jede technologische Innovation wird zunächst im alten Deutungsrahmen verstanden, bevor der grundlegende Wandel erkannt wird.
  • pferdelose Kutsche → Automobil
  • drahtloser Telegraf → Radio
  • E-Mail → Messaging
• Um die sekundären Effekte neuer Technologien sowie Verstärkungs- und Dämpfungsschleifen zu verstehen, muss man sie lange genug verwenden.

Experiment: Rope-Datenstruktur

• Die Rope-Datenstruktur dient dazu, das Löschen von Zeichen in der Mitte sehr langer Strings effizient auszuführen.
• Der einfache Ansatz verschiebt alle Zeichen rechts davon und benötigt O(n) Zeit.
• Die Rope-Struktur verarbeitet Löschungen in konstanter Zeit, indem sie Substring-Objekte und Concatenation-Objekte verwendet.
  • Beim Löschen werden 3 Objekte allokiert.
  • Die Suche kostet O(Anzahl der Operationen), ist aber kleiner als die String-Länge und kann periodisch komprimiert werden.

Ablauf des Experiments

Phase 1: Persona ("Code like Kent Beck")

• Es wurde geprüft, ob das Hinzufügen des Prompts "Code like Kent Beck" die Codequalität verbessert.
• Ergebnis: Eine Verbesserung des Codestils wurde bestätigt.
  • bessere Variablennamen
  • die Teststrategie wechselte von einem monolithischen Skript zu modularen Unit-Tests (im TDD-Stil)
• Unerwartete Erkenntnis: Die Architektur änderte sich nicht.
  • Rope wurde als standardmäßiger Binärbaum implementiert.
  • Das von Kent Beck verwendete Composite-Muster wurde ignoriert.

Phase 2: Zusätzliche Design-Leitlinien

• Der Code der Control-Gruppe war so ausführlich, dass wegen Überschreitung des Token-Limits Syntaxfehler auftraten.
  • Gelöst durch Erhöhung des Token-Limits
  • mehr Compute kann eine einfache Lösung sein
• Dem Prompt wurden explizite Constraints hinzugefügt.
  • "Composite-Muster verwenden"
  • "Verhalten in kleine, spezialisierte Klassen aufteilen"
• Ergebnis: Das erwartete Design wurde umgesetzt.
  • getrennte Klassen für Substring und Concatenation
  • eine einfachere Struktur als eine einzelne Klasse
  • tatsächlich ergab sich ein noch einfacheres Design: Verarbeitung als Substring 0..size ohne Null Object (EmptyString) oder nativen String-Wrapper

Phase 3: Experiment mit vier getrennten Gruppen

• Um festzustellen, welche Intervention die Wirkung erzeugte, wurde ein Kreuzexperiment entworfen.
  1. Control: Standard-Assistent
  2. Kent Beck: nur Persona
  3. Composite: nur Architektur-Constraint
  4. Combined: Persona + Constraints

Fazit des Experiments

• Es zeigte sich ein 2x2-Matrix-Effekt.
  1. Personas bestimmen Mikroverhalten: Der Prompt "Kent Beck" verbessert zuverlässig Teststil und Benennung, hat aber keinen Einfluss auf strukturelle Entscheidungen.
  2. Constraints bestimmen die Makroarchitektur: Der Prompt "Composite Pattern" erzwingt die Klassenhierarchie und erzeugt auch ohne Persona ein fein gegliedertes Design.
  3. Die Kombination ist am besten: Die Combined-Gruppe lieferte sowohl die richtige Architektur (Composite) als auch die richtigen Entwicklungsgewohnheiten (TDD/Unit Tests).

Anwendung von The Bitter Lesson

• Das verborgene Ziel war, Genie zu einer besseren Entwicklung zu bringen, indem Funktionalität und Zukunftsfähigkeit ausbalanciert werden.
• Versuchte Methoden: sorgfältiges Prompting, aufmerksame Prüfung der von Genie vorgeschlagenen Änderungen, kleinere/größere Schritte usw.
• Verweis auf Rich Suttons "The Bitter Lesson"
  • Die Lehre aus 70 Jahren AI-Forschung: Die Nutzung von Rechenressourcen liefert bessere Ergebnisse, als menschliche Expertise zu kodieren.
  • Der Versuch, Stil zu kodieren, war derselbe Fehler, den alle machen.

Vorschlag für einen effektiven Entwicklungsstil durch Nutzung von Compute

• Man muss nicht in einem ungeschickten Coding-Genie gefangen bleiben, das den schlechten Codestil zahlloser Repositories kopiert.
• Vorgeschlagene Nutzung von Compute
  1. ein großes Repository auswählen
  2. eine Million Genies dieselbe nächste Funktion implementieren lassen, wobei jedes Genie eine andere Art und ein anderes Maß an Aufräumarbeit wählt
  3. das Genie auswählen, das die Funktion mit den niedrigsten Kosten (Zeit, Tokens, Strom, Geld usw.) erfolgreich hinzufügt
  4. das über viele Genies, viele Funktionen und viele Repositories hinweg wiederholen
• Das mag wie eine "Verschwendung" von Coding wirken, ist es aber in Wirklichkeit nicht.
• Jessica Kerr nennt das einen "Design Contest"