Latest / KI Espresso / Matt Pocock: Software-Grundlagen beim Programmieren mit KI

Transcript

Matt Pocock: Software-Grundlagen beim Programmieren mit KI · KI Espresso

• 0:00
  SPEAKER_00: Willkommen bei KI Espresso.
• 0:02
  SPEAKER_00: In dieser Folge hört ihr Matt Pocock mit seinem Vortrag Software Fundamentals Matter More Than Ever bei AI Engineer Europe 2026 in London.
• 0:13
  SPEAKER_00: Wir haben ihn vollständig ins Deutsche übersetzt, weil er eine praktische Frage aufgreift.
• 0:19
  SPEAKER_00: Wie bleibt Software verständlich und wartbar, wenn KI immer mehr Code schreibt?
• 0:24
  SPEAKER_00: Pocock spricht über gemeinsame Anforderungen, kurze Feedbackschleifen und den Entwurf von Schnittstellen.
• 0:31
  SPEAKER_00: Fürs Hören ohne Video hilft eine Erklärung zu seinen Schaubildern.
• 0:36
  SPEAKER_00: Viele kleine, eng miteinander verflochtene Module stellt er wenigen tieferen Modulen gegenüber.
• 0:43
  SPEAKER_00: Deren einfache Schnittstellen verbergen die komplexe Implementierung.
• 0:47
  SPEAKER_00: Wenn er später auf diese Bilder verweist, meint er diesen Unterschied.
• 0:51
  SPEAKER_00: Die deutsche Fassung wird mit einer synthetischen Stimme gesprochen.
• 0:55
  SPEAKER_00: Matt Pocock spricht im Original Englisch.
• 0:58
  SPEAKER_00: Den Vortrag von AI Engineer und die gezeigten Skills findet ihr in den Shownotes.
• 1:04
  SPEAKER_00: Besucht auch das Original und hinterlasst dort gern einen Kommentar.
• 1:08
  SPEAKER_00: Jetzt zum Vortrag.
• 1:24
  SPEAKER_00: Hallo zusammen.
• 1:25
  SPEAKER_00: Gefällt euch die Konferenz bisher?
• 1:28
  SPEAKER_00: Gefällt euch die Konferenz bisher?
• 1:30
  SPEAKER_00: Gut.
• 1:31
  SPEAKER_00: Wunderbar.
• 1:32
  SPEAKER_00: Ich habe eine Botschaft für euch, die hoffentlich allen etwas Mut macht, die glauben, ihre Fähigkeiten seien in dieser neuen Zeit nichts mehr wert.
• 1:43
  SPEAKER_00: Ich glaube nämlich, dass die Grundlagen der Softwareentwicklung heute wichtiger sind als je zuvor.
• 1:49
  SPEAKER_00: Ich unterrichte und habe in letzter Zeit einen Kurs namens Cloud Code for Real Engineers gegeben.
• 1:57
  SPEAKER_00: Schön provokant.
• 1:59
  SPEAKER_00: Bei der Arbeit an diesem Kurs musste ich einen Lehrplan für das Programmieren mit KI entwickeln.
• 2:06
  SPEAKER_00: Ein ziemlicher Albtraum, weil sich ständig alles verändert, oder?
• 2:11
  SPEAKER_00: KI ist ein völlig neues Paradigma.
• 2:13
  SPEAKER_00: Da müssen wir doch bestimmt alle alten Regeln über Bord werfen, damit Platz für das Neue ist.
• 2:18
  SPEAKER_00: Darum hat sich eine Bewegung gebildet: Specs-to-Code.
• 2:25
  SPEAKER_00: Sie sagt, man kann in einer Spezifikation beschreiben, wie eine Anwendung funktionieren soll und diese dann mit KI in Code umwandeln.
• 2:34
  SPEAKER_00: Gibt es ein Problem mit der Anwendung, geht man zurück zur Spezifikation.
• 2:38
  SPEAKER_00: Den Code schaut man sich eigentlich nicht an.
• 2:40
  SPEAKER_00: Man ändert nur die Spezifikation, lässt den Compiler noch einmal laufen und bekommt neuen Code.
• 2:45
  SPEAKER_00: Hand hoch, wer davon schon gehört hat.
• 2:47
  SPEAKER_00: Lasst die Hand oben, wenn ihr es ausprobiert habt.
• 2:50
  SPEAKER_00: Okay, ich habe es auch ausprobiert.
• 2:52
  SPEAKER_00: Ihr könnt die Hände runternehmen.
• 2:53
  SPEAKER_00: Dabei fiel mir auf, ich ließ das laufen und versuchte mir, den Code nicht anzusehen.
• 2:58
  SPEAKER_00: Habe dann aber doch reingeschaut.
• 3:00
  SPEAKER_00: Erst bekam ich Code heraus, dann ließ ich es noch einmal laufen und bekam schlechteren Code.
• 3:05
  SPEAKER_00: Beim nächsten Mal wurde er noch schlechter.
• 3:07
  SPEAKER_00: Und dann noch einmal, ich ließ den Compiler immer wieder laufen.
• 3:11
  SPEAKER_00: Immer wieder.
• 3:12
  SPEAKER_00: Und am Ende kam nur noch Müll heraus.
• 3:14
  SPEAKER_00: Hand hoch, wem das auch passiert ist.
• 3:16
  SPEAKER_00: Ja, ich glaube nicht, dass das funktioniert.
• 3:19
  SPEAKER_00: Die Vorstellung, wir könnten den Code einfach ignorieren und ihn sich selbst überlassen, ist doch nur Vibecoding unter einem anderen Namen.
• 3:26
  SPEAKER_00: Damals habe ich das aber noch nicht geglaubt.
• 3:28
  SPEAKER_00: Ich dachte, okay, wie repariere ich den Compiler?
• 3:32
  SPEAKER_00: Wie kriege ich es hin, dass er nicht jedes Mal schlechten oder noch schlechteren Code erzeugt?
• 3:36
  SPEAKER_00: Also dachte ich, ich muss dem LLM auf Englisch erklären, wie eine gute Codebasis aussieht.
• 3:42
  SPEAKER_00: Holen wir mal eines meiner alten Lieblingsbücher hervor.
• 3:45
  SPEAKER_00: A Philosophy of Software Design von John Austerhaut.
• 3:48
  SPEAKER_00: Geht auf Amazon und kauft es euch.
• 3:50
  SPEAKER_00: Er hat eine Definition dafür, wie schlechter Code aussieht.
• 3:54
  SPEAKER_00: Er nennt ihn komplexen Code.
• 3:56
  SPEAKER_00: Komplexität ist alles an der Struktur eines Softwaresystems, was es schwer macht, das System zu verstehen und zu verändern.
• 4:03
  SPEAKER_00: Eine schlechte Codebasis ist also eine Codebasis, die sich schwer ändern lässt.
• 4:07
  SPEAKER_00: Wenn ihr sie nicht ändern könnt, ohne Fehler zu verursachen, dann ist es eine schlechte Codebasis.
• 4:12
  SPEAKER_00: Gute Codebasen lassen sich leicht ändern.
• 4:15
  SPEAKER_00: Da dachte ich, oh, das war gut.
• 4:17
  SPEAKER_00: Versuchen wir noch ein Buch.
• 4:19
  SPEAKER_00: The Pragmatic Programmer.
• 4:20
  SPEAKER_00: Geht auf Amazon und kauft es euch.
• 4:22
  SPEAKER_00: Darin gibt es ein ganzes Kapitel über Softwareentropie.
• 4:25
  SPEAKER_00: Genau das habe ich beobachtet.
• 4:27
  SPEAKER_00: Entropie beschreibt die Vorstellung, dass sich Dinge auf eine Katastrophe zubewegen, auseinanderdriften und zusammenbrechen.
• 4:34
  SPEAKER_00: Und genau so verhalten sich die meisten Softwaresysteme.
• 4:37
  SPEAKER_00: Wenn ihr etwas an einer Codebasis ändert und dabei nur an diese Änderung denkt, nicht an den Entwurf des gesamten Systems, wird eure Codebasis immer schlechter und schlechter.
• 4:46
  SPEAKER_00: Genau das habe ich gesehen.
• 4:48
  SPEAKER_00: Bei diesem Specs-to-Code-Ansatz, bei dem man den Compiler einfach immer wieder laufen lässt, wurde der Code immer schlechter.
• 4:55
  SPEAKER_00: Eine Vorstellung treibt diese Bewegung an.
• 4:58
  SPEAKER_00: Code ist billig.
• 4:59
  SPEAKER_00: Hand hoch, wer diesen Satz schon gehört hat.
• 5:02
  SPEAKER_00: Code ist billig.
• 5:03
  SPEAKER_00: Ja.
• 5:05
  SPEAKER_00: Ich glaube nicht, dass das stimmt.
• 5:07
  SPEAKER_00: Ich finde, Code ist nicht billig.
• 5:10
  SPEAKER_00: Schlechter Code ist sogar teurer als je zuvor.
• 5:14
  SPEAKER_00: Wenn sich eure Codebasis schwer ändern lässt, könnt ihr nicht alles nutzen, was KI euch bieten kann.
• 5:20
  SPEAKER_00: Denn in einer guten Codebasis arbeitet KI wirklich sehr, sehr gut.
• 5:25
  SPEAKER_00: Das heißt, gute Codebasen sind wichtiger denn je.
• 5:28
  SPEAKER_00: Und damit sind auch die Grundlagen der Softwareentwicklung wichtiger denn je.
• 5:31
  SPEAKER_00: Das ist die These dieses Vortrags.
• 5:33
  SPEAKER_00: Werden wir praktisch.
• 5:34
  SPEAKER_00: Ich spreche über verschiedene Probleme mit KI, die ihr vielleicht schon erlebt habt, oder bisher noch nicht.
• 5:40
  SPEAKER_00: Und darüber, wie ihr sie vermeiden könnt, indem ihr in alte Bücher schaut und gute Praktiken der Softwareentwicklung nutzt.
• 5:46
  SPEAKER_00: Klingt gut?
• 5:47
  SPEAKER_00: Das erste Problem.
• 5:48
  SPEAKER_00: Die KI hat nicht gemacht, was ich wollte.
• 5:50
  SPEAKER_00: Ich dachte, ich hätte eine gute Idee im Kopf, aber die KI hat etwas völlig anderes gemacht.
• 5:55
  SPEAKER_00: Oder irgendwelche Spezifikationen, die ich.
• 5:58
  SPEAKER_00: Sie hat einfach etwas gebaut, das ich nicht wollte.
• 6:01
  SPEAKER_00: Hand hoch, wem das schon passiert ist.
• 6:03
  SPEAKER_00: Gut.
• 6:03
  SPEAKER_00: Okay, in The Pragmatic Programmer steht dazu, niemand weiß genau, was er will.
• 6:09
  SPEAKER_00: Zwischen euch und der KI gibt es eine Kommunikationsbarriere, oder?
• 6:14
  SPEAKER_00: Wenn ihr mit der KI sprecht, ist das also gewissermaßen ihre Anforderungserhebung.
• 6:19
  SPEAKER_00: Sie versucht, von euch herauszufinden, was ihr braucht.
• 6:23
  SPEAKER_00: Dann fiel mir noch ein Buch ein: The Design of Design von Frederick P.
• 6:28
  SPEAKER_00: Brooks.
• 6:29
  SPEAKER_00: Darin geht es um das sogenannte Designkonzept.
• 6:33
  SPEAKER_00: Wenn mehrere Menschen gemeinsam etwas entwerfen, schwebt zwischen ihnen diese flüchtige Vorstellung von dem, was sie bauen.
• 6:41
  SPEAKER_00: Und das, was ihr baut, beziehungsweise die Vorstellung davon, heißt Designkonzept.
• 6:46
  SPEAKER_00: Es ist kein greifbares Arbeitsergebnis, das ihr in einer Markdown-Datei ablegen könnt.
• 6:50
  SPEAKER_00: Es ist die unsichtbare Vorstellung davon, was ihr baut.
• 6:54
  SPEAKER_00: Da dachte ich, okay, das ist das Problem.
• 6:56
  SPEAKER_00: Die KI und ich haben kein gemeinsames Designkonzept.
• 7:00
  SPEAKER_00: Also habe ich einen Skill entwickelt.
• 7:02
  SPEAKER_00: Der ist sehr, sehr einfach.
• 7:04
  SPEAKER_00: Er heißt Grill Me und sieht so aus.
• 7:06
  SPEAKER_00: Befrage mich unerbittlich zu jedem Aspekt dieses Plans, bis wir ein gemeinsames Verständnis haben.
• 7:12
  SPEAKER_00: Gehe jeden Ast des Entscheidungsbaums für den Entwurf durch.
• 7:15
  SPEAKER_00: Auch diese Idee stammt von Frederick P.
• 7:17
  SPEAKER_00: Brooks und kläre dabei Schritt für Schritt die Abhängigkeiten zwischen den Entscheidungen.
• 7:22
  SPEAKER_00: Das Repository mit diesem Skill hat ungefähr 13.000 Sterne oder so.
• 7:26
  SPEAKER_00: Es ist völlig durch die Decke gegangen.
• 7:28
  SPEAKER_00: Viral.
• 7:28
  SPEAKER_00: Die Leute lieden das.
• 7:30
  SPEAKER_00: Diese paar Zeilen sorgen dafür, dass die KI euch 40 oder 60 Fragen stellt.
• 7:34
  SPEAKER_00: Ich habe erlebt, dass sie Leuten 100 Fragen gestellt hat, bevor sie zufrieden war, dass ein gemeinsames Verständnis erreicht ist.
• 7:41
  SPEAKER_00: Damit wird die KI zu einer Art Gegenspieler.
• 7:44
  SPEAKER_00: Sie spielt euch ständig Ideen zu und versucht, ein gemeinsames Verständnis herzustellen.
• 7:49
  SPEAKER_00: Das Gespräch, das dabei entsteht, könnt ihr dann etwa in ein Dokument mit Produktanforderungen umwandeln.
• 7:56
  SPEAKER_00: Oder bei einer kleinen Änderung direkt in Issues.
• 8:02
  SPEAKER_00: Die übernimmt dann euer AfK-Agent.
• 8:05
  SPEAKER_00: Und jetzt bitte keine wütenden Nachrichten.
• 8:08
  SPEAKER_00: Ich persönlich finde das besser als den standardmäßigen Planungsmodus in dem Tool, das ich benutze, Claude Code.
• 8:15
  SPEAKER_00: Der Planungsmodus will unbedingt ein konkretes Arbeitsergebnis erstellen.
• 8:19
  SPEAKER_00: Er will einfach einen Plan schreiben und loslegen.
• 8:22
  SPEAKER_00: Ich finde es viel angenehmer, zuerst zu einem gemeinsamen Designkonzept zu kommen.
• 8:29
  SPEAKER_00: Das war Tipp Nummer eins.
• 8:32
  SPEAKER_00: Problem Nummer zwei.
• 8:33
  SPEAKER_00: Die KI ist viel zu wortreich.
• 8:36
  SPEAKER_00: Es ist fast so, als würdet ihr aneinander vorbeireden.
• 8:39
  SPEAKER_00: Hand hoch, wenn ihr das kennt, wenn ihr dieses Problem schon erlebt habt.
• 8:43
  SPEAKER_00: Ja, die KI braucht einfach viel zu viele Worte, um zu erklären, was sie gerade tut.
• 8:49
  SPEAKER_00: Es ist, als würdet ihr nicht dieselbe Sprache sprechen.
• 8:52
  SPEAKER_00: Das kam mir sehr bekannt vor.
• 8:54
  SPEAKER_00: Wenn ihr schon lange entwickelt und mit Fachleuten zusammengearbeitet habt, etwa beim Bau einer Anwendung, sagen wir, jemand aus dem Fachbereich möchte, dass ihr etwas mit Mikrochips baut.
• 9:05
  SPEAKER_00: Ihr habt keine Ahnung von Mikrochips.
• 9:08
  SPEAKER_00: Ihr müsst eine gemeinsame Sprache finden.
• 9:10
  SPEAKER_00: Sonst benutzen die Fachleute Begriffe, die ihr nicht versteht.
• 9:13
  SPEAKER_00: Ihr übersetzt das in Code, den ihr vielleicht selbst nicht versteht und den die Fachleute ganz sicher nicht verstehen.
• 9:18
  SPEAKER_00: Zwischen euch und den Fachleuten besteht also eine sprachliche Kluft.
• 9:23
  SPEAKER_00: Deshalb habe ich mich wieder mit Domain-Driven Design beschäftigt.
• 9:26
  SPEAKER_00: DDD.
• 9:27
  SPEAKER_00: Ich stehe da noch ziemlich am Anfang.
• 9:29
  SPEAKER_00: Aber alles, was ich über DDD lese, ist Musik in meinen Ohren.
• 9:33
  SPEAKER_00: Ich finde es verdammt gut.
• 9:34
  SPEAKER_00: In DDD gibt es das Konzept der Ubiquitous Language, einer gemeinsamen, durchgängig verwendeten Sprache.
• 9:41
  SPEAKER_00: Bei einer Ubiquitous Language leiten sich die Gespräche unter Entwicklern, die Formulierungen im Code und die Gespräche mit Fachleuten alle aus demselben Domänenmodell ab.
• 9:50
  SPEAKER_00: Im Grunde ist es eine Markdown-Datei mit einer Liste von Begriffen, die ihr und die KI gemeinsam verwendet.
• 9:56
  SPEAKER_00: Ihr konzentriert euch auf diese Begriffe und achtet genau darauf, dass sie der tatsächlichen Bedeutung entsprechen.
• 10:02
  SPEAKER_00: Und ihr verwendet sie ständig.
• 10:03
  SPEAKER_00: Im Code, wenn ihr über den Code sprecht, im Gespräch mit Fachleuten oder in unserem Fall mit der KI.
• 10:09
  SPEAKER_00: Also habe ich einen Skill gebaut, den Ubiquitous Language Skill.
• 10:13
  SPEAKER_00: Er durchsucht im Grunde eure Codebasis nach Begriffen und erstellt dann eine Markdown-Datei für die gemeinsame Sprache.
• 10:20
  SPEAKER_00: Darin stehen Markdown-Tabellen mit der ganzen Terminologie.
• 10:25
  SPEAKER_00: Die gebe ich dann an die KI weiter und kann sie auch selbst lesen.
• 10:29
  SPEAKER_00: Ich habe sie tatsächlich immer offen, wenn ich mich von der KI ausfragen lasse und mit ihr plane.
• 10:34
  SPEAKER_00: Beim Lesen der Denkprotokolle der KI ist mir aufgefallen, das verbessert nicht nur die Planung.
• 10:39
  SPEAKER_00: Die KI kann auch mit weniger Worten nachdenken.
• 10:42
  SPEAKER_00: Und die Umsetzung entspricht stärker dem, was man tatsächlich geplant hat.
• 10:47
  SPEAKER_00: Das hat sich als unglaublich wirksam erwiesen.
• 10:49
  SPEAKER_00: Es war wirklich enorm gut.
• 10:52
  SPEAKER_00: Tipp Nummer zwei lautet also, schafft eine gemeinsame Sprache mit der KI.
• 10:56
  SPEAKER_00: Stellen wir uns nun vor, ihr habt euch mit der KI abgestimmt.
• 11:00
  SPEAKER_00: Ihr wisst, was ihr bauen sollt.
• 11:01
  SPEAKER_00: Die KI hat das Richtige gebaut, aber es funktioniert nicht.
• 11:06
  SPEAKER_00: Hand hoch, wem das schon passiert ist.
• 11:08
  SPEAKER_00: Ja, es funktioniert einfach nicht.
• 11:10
  SPEAKER_00: Da gibt es eine naheliegende Verbesserung.
• 11:13
  SPEAKER_00: Feedbackschleifen.
• 11:15
  SPEAKER_00: Wir können statische Typen nutzen.
• 11:17
  SPEAKER_00: Wenn ihr kein TypeScript verwendet, das ist doch verrückt.
• 11:21
  SPEAKER_00: Wenn ihr eine Frontend-Anwendung baut und dem LLM keinen Zugriff auf den Browser gebt, damit es sich darin umsehen kann, diesen Zugriff braucht es unbedingt.
• 11:31
  SPEAKER_00: Und natürlich braucht ihr auch automatisierte Tests.
• 11:34
  SPEAKER_00: Dabei fällt mir auf, selbst mit diesen Feedbackschleifen nutzt das LLM sie nicht besonders gut.
• 11:42
  SPEAKER_00: Es holt nicht so viel aus ihnen heraus wie ein erfahrener Entwickler.
• 11:47
  SPEAKER_00: Es macht meistens viel zu viel auf einmal.
• 11:50
  SPEAKER_00: Es erzeugt riesige Mengen Code und denkt dann, oh, den sollte ich vielleicht mal einer Typprüfung unterziehen.
• 11:57
  SPEAKER_00: Oder vielleicht sollte ich dafür einen Test laufen lassen oder so etwas.
• 12:01
  SPEAKER_00: In The Pragmatic Programmer wird das damit verglichen, schneller zu fahren als die Scheinwerfer reichen.
• 12:06
  SPEAKER_00: Man fährt also zu schnell, denn die Geschwindigkeit des Feedbacks bestimmt euer Tempolimit.
• 12:11
  SPEAKER_00: Die Geschwindigkeit des Feedbacks bestimmt euer Tempolimit.
• 12:14
  SPEAKER_00: Ihr solltet also laufend testen und kleine, bewusste Schritte machen.
• 12:19
  SPEAKER_00: Von sich aus ist KI darin wirklich nicht besonders gut.
• 12:22
  SPEAKER_00: Skill Nummer 3 ist deshalb TDD.
• 12:26
  SPEAKER_00: Ihr solltet testgetrieben entwickeln.
• 12:28
  SPEAKER_00: Denn TDD zwingt das LLM dazu, wirklich kleine Schritte zu machen.
• 12:33
  SPEAKER_00: Erst schreibt ihr einen Test.
• 12:35
  SPEAKER_00: Dann sorgt ihr dafür, dass er besteht.
• 12:37
  SPEAKER_00: Anschließend überarbeitet ihr den Code, macht ihn sauberer und denkt über den Entwurf nach.
• 12:43
  SPEAKER_00: Das Problem ist, testen ist wirklich schwierig.
• 12:47
  SPEAKER_00: Das war es schon immer.
• 12:49
  SPEAKER_00: Und der Grund dafür ist, dass ihr beim Schreiben eines Tests sehr viele Entscheidungen treffen müsst.
• 12:56
  SPEAKER_00: Ihr müsst klären, wie groß die Einheit sein soll, die ihr testet.
• 13:00
  SPEAKER_00: Ihr müsst entscheiden, was ihr durch Mogs ersetzt und welche Verhaltensweisen ihr überhaupt testen wollt.
• 13:05
  SPEAKER_00: All diese Entscheidungen hängen voneinander ab.
• 13:08
  SPEAKER_00: Wenn ihr eine sehr große Einheit testet, etwa eine riesige Anwendung, kann der Test ziemlich unzuverlässig sein.
• 13:14
  SPEAKER_00: Vielleicht wollt ihr dann nicht so viele Verhaltensweisen testen.
• 13:17
  SPEAKER_00: Wenn ihr nur diese Einheit testet, müsst ihr jene durch einen Mock ersetzen.
• 13:20
  SPEAKER_00: Das hängt alles zusammen.
• 13:22
  SPEAKER_00: Darüber denke ich seit Jahren nach.
• 13:24
  SPEAKER_00: Meine ganze Laufbahn als Entwickler hindurch.
• 13:27
  SPEAKER_00: Dabei sehen wir, gute Codebasen lassen sich leicht testen.
• 13:32
  SPEAKER_00: Hier kommen wir also wieder dazu zurück, dass Code wichtig ist.
• 13:36
  SPEAKER_00: Je besser eure Codebasis, desto besser eure Feedback schleifen.
• 13:40
  SPEAKER_00: Denn ihr könnt dem LLM besseres Feedback geben.
• 13:43
  SPEAKER_00: Und es erzeugt besseren Code.
• 13:45
  SPEAKER_00: Also habe ich mich gefragt, wie sieht eine gute, testbare Codebasis aus?
• 13:50
  SPEAKER_00: Wieder hilft John Austerhaut.
• 13:53
  SPEAKER_00: Er spricht von tiefen Modulen in der Codebasis.
• 13:57
  SPEAKER_00: Keine flachen Module, nicht lauter Module, die viele Funktionen nach außen anbieten.
• 14:02
  SPEAKER_00: Es sollten relativ wenige große, tiefe Module mit einfachen Schnittstellen sein.
• 14:08
  SPEAKER_00: Vergleichen wir das kurz.
• 14:09
  SPEAKER_00: Tiefe Module.
• 14:10
  SPEAKER_00: Viel Funktionalität hinter einer einfachen Schnittstelle.
• 14:13
  SPEAKER_00: Die Komplexität bleibt verborgen.
• 14:15
  SPEAKER_00: Ihr könnt in das tiefe Modul hineinschauen, wenn ihr wollt.
• 14:18
  SPEAKER_00: Aber ihr müsst nicht.
• 14:19
  SPEAKER_00: Ihr könnt einfach die Schnittstelle nutzen.
• 14:21
  SPEAKER_00: Flache Module.
• 14:22
  SPEAKER_00: Wenig Funktionalität, komplexe Schnittstelle.
• 14:25
  SPEAKER_00: Ich warte kurz, bis ihr die Fotos gemacht habt.
• 14:28
  SPEAKER_00: Flache Module in einer Codebasis sehen ungefähr so aus.
• 14:32
  SPEAKER_00: Viele winzige Klumpen, durch die sich die KI hindurch arbeiten und navigieren muss.
• 14:37
  SPEAKER_00: Das ist für die KI tatsächlich ziemlich schwer zu erkunden.
• 14:41
  SPEAKER_00: Bei einer solchen Codebasis seht ihr deshalb oft Folgendes.
• 14:44
  SPEAKER_00: Und KI ist sehr gut darin, solche Codebasen zu erzeugen.
• 14:48
  SPEAKER_00: Die KI versteht nicht, was euer Code tut.
• 14:51
  SPEAKER_00: Sie versucht, den Code zu erkunden.
• 14:53
  SPEAKER_00: Aber weil er schlecht strukturiert und voller flacher Module ist, erreicht sie vielleicht nicht rechtzeitig das richtige Modul oder versteht nicht alle Abhängigkeiten und so weiter.
• 15:03
  SPEAKER_00: Sie versteht euren Code nicht.
• 15:04
  SPEAKER_00: Wie sieht also eine Codebasis voller tiefer Module aus?
• 15:08
  SPEAKER_00: So.
• 15:09
  SPEAKER_00: Es ist derselbe Code, aber innerhalb klarer Grenzen angeordnet.
• 15:14
  SPEAKER_00: Mit diesen Schnittstellen obendrauf.
• 15:18
  SPEAKER_00: Über diese Schnittstellen solltet ihr wahrscheinlich viel Kontrolle behalten und sie sehr sorgfältig entwerfen.
• 15:25
  SPEAKER_00: Sonst könnte die KI den Entwurf vermurksen.
• 15:27
  SPEAKER_00: Die Implementierung könnt ihr dagegen ein Stück weit der KI überlassen.
• 15:32
  SPEAKER_00: Wie macht man also aus einer Codebasis, die so aussieht, eine, die so aussieht?
• 15:39
  SPEAKER_00: Dafür habe ich einen Skill, Improve Codebase Architecture.
• 15:43
  SPEAKER_00: Das ist ziemlich kompliziert, aber es ist eine Folge von Schritten, die sich immer wieder anwenden lässt.
• 15:50
  SPEAKER_00: Ihr erkundet die Codebasis, sucht nach zusammengehörigem Code und fasst ihn in einem tiefen Modul zusammen.
• 16:00
  SPEAKER_00: Das ist eine testbare Codebasis, weil die Grenzen um diesen Code so einfach sind.
• 16:05
  SPEAKER_00: Ihr testet an der Schnittstelle, überprüft das Verhalten über diese Schnittstelle und schon seid ihr bereit.
• 16:11
  SPEAKER_00: Diese Codebasis belohnt also TDD.
• 16:15
  SPEAKER_00: Aber was ist mit Problem Nummer 6?
• 16:17
  SPEAKER_00: Nehmen wir an, eure Feedbackschleifen funktionieren.
• 16:20
  SPEAKER_00: Alles kommt in Gang.
• 16:21
  SPEAKER_00: Ihr könnt mehr Code ausliefern als je zuvor.
• 16:25
  SPEAKER_00: Aber euer Gehirn kommt nicht hinterher.
• 16:27
  SPEAKER_00: Hand hoch, wenn ihr euch müder gefühlt habt als jemals zuvor in eurer Laufbahn als Entwickler.
• 16:33
  SPEAKER_00: Ja, ich auch.
• 16:34
  SPEAKER_00: Das ist wahnsinnig anstrengend.
• 16:36
  SPEAKER_00: Ich glaube, diese Codebasis macht es eurem Gehirn zusätzlich schwer.
• 16:41
  SPEAKER_00: Denn genauso wie die KI müsst auch ihr all diese Informationen im Kopf behalten.
• 16:46
  SPEAKER_00: Das hier lässt sich dagegen nicht nur leichter lesen und verstehen.
• 16:51
  SPEAKER_00: Ihr könnt diese tiefen Module auch gewissermaßen als graue Kästen betrachten.
• 16:57
  SPEAKER_00: Ihr könnt sagen, okay, ich entwerfe nur die Schnittstelle.
• 17:02
  SPEAKER_00: Über die Implementierung mache ich mir nicht so viele Gedanken oder prüfe sie nicht ganz so genau.
• 17:07
  SPEAKER_00: Das geht natürlich bei Teilen eurer Anwendung, die weniger kritisch sind.
• 17:11
  SPEAKER_00: Bei Finanzfunktionen oder ähnlichen Dingen geht das nicht.
• 17:14
  SPEAKER_00: Aber bei vielen Modulen eurer Anwendung müsst ihr euch nicht allzu viele Gedanken über die Implementierung machen.
• 17:19
  SPEAKER_00: Solange ihr außen eine testbare Modulgrenze habt, den Zweck des Moduls versteht und es von außen entwerfen könnt.
• 17:26
  SPEAKER_00: Das hat meinen Kopf wirklich entlastet.
• 17:28
  SPEAKER_00: Ich kann einfach sagen, okay, KI, du kümmerst dich um das Innere dieses großen Klumpens.
• 17:34
  SPEAKER_00: Ich teste und überprüfe ihn von außen.
• 17:36
  SPEAKER_00: Das ist Tipp Nummer 5.
• 17:38
  SPEAKER_00: Entwerft die Schnittstelle, delegiert die Implementierung.
• 17:42
  SPEAKER_00: Das bedeutet aber, wann immer wir Code anfassen oder etwas planen, müssen wir an die Module unserer Anwendung denken und sie kennen.
• 17:50
  SPEAKER_00: Diese Landkarte müssen wir sehr gut im Kopf haben.
• 17:53
  SPEAKER_00: Sie muss Teil unserer gemeinsamen Sprache sein und auch in unsere Planungsskills einfließen.
• 17:58
  SPEAKER_00: Bei meinem Skill Write a PRD beschreibe ich deshalb im Anforderungsdokument konkret, wie die Module und ihre Schnittstellen verändert werden.
• 18:05
  SPEAKER_00: Ich denke die ganze Zeit darüber nach.
• 18:07
  SPEAKER_00: Von Kent Beck stammt der Rat, investiert jeden Tag in den Entwurf des Systems.
• 18:13
  SPEAKER_00: Darum geht es im Kern.
• 18:14
  SPEAKER_00: Denn bei Specs to Code investieren wir nicht in den Entwurf des Systems.
• 18:19
  SPEAKER_00: Wir ziehen uns daraus zurück und geben ihn auf.
• 18:22
  SPEAKER_00: Ich halte das aber für absolut entscheidend.
• 18:27
  SPEAKER_00: Code ist also nicht billig.
• 18:29
  SPEAKER_00: Das ist die Botschaft, die ihr mitnehmen sollt.
• 18:32
  SPEAKER_00: Code ist wichtig.
• 18:33
  SPEAKER_00: Wenn wir KI als sehr guten Programmierer vor Ort betrachten, als taktischen Programmierer, als Unteroffizier, der vor Ort die Code-Änderungen erledigt, dann braucht es darüber noch jemanden.
• 18:46
  SPEAKER_00: Jemanden, der strategisch denkt.
• 18:48
  SPEAKER_00: Und das seid ihr.
• 18:50
  SPEAKER_00: Dafür braucht ihr die Grundlagen der Softwareentwicklung, mit denen wir seit 20 Jahren arbeiten.
• 18:54
  SPEAKER_00: Sogar noch länger.
• 18:55
  SPEAKER_00: Falls euch die Skills interessieren, die ich hier gezeigt habe, ihr findet sie im GitHub-Repository mattpock-skills.
• 19:02
  SPEAKER_00: Wenn ihr euch für meine Schulungen oder kostenlose Inhalte interessiert, ich bin auf YouTube und Twitter und auch auf aihero.dev.
• 19:10
  SPEAKER_00: Dort gibt es einen Newsletter, den ihr euch ansehen könnt.
• 19:13
  SPEAKER_00: Vielen Dank.
• 19:14
  SPEAKER_00: Ich hoffe, das gibt euch Zuversicht in dieser neuen KI-Zeit, dass ihr tatsächlich etwas Gutes bewirken könnt.
• 19:20
  SPEAKER_00: Danke.