Transcript
Kai Ole Hartwig: Willkommen zurück zu einer hervorragenden, fantastischen neuen Folge Secrets Not Included mit Daniel und Ole.
Kai Ole Hartwig: Und letzte Woche haben wir euch angekündigt, wir wollen ein bisschen nochmal über Agentic Engineering sprechen.
Daniel Langemann: Ja, jetzt hatten wir fünf Minuten Zeit, uns vorzubereiten.
Daniel Langemann: Stimmt, tut mir leid.
Daniel Langemann: Nee.
Kai Ole Hartwig: Daniel, seit wann bereitest du dich vor?
Kai Ole Hartwig: Ich finde, das ist unprofessionell.
Kai Ole Hartwig: Also, du kannst jetzt nicht behaupten, du würdest dich vorbereiten zu einem Podcast oder vorbereitet in Meetings gehen.
Kai Ole Hartwig: Nachher können, also, nee, nee, bitte.
Kai Ole Hartwig: Nachher weißt du noch etwas und kannst noch etwas, das würde jetzt alle Menschen davon abhalten, nichts zu wissen.
Daniel Langemann: Wollen ihr nicht übertreiben, ja?
Daniel Langemann: Ja, soll ja Spaß machen.
Kai Ole Hartwig: Ja, genau, also nicht overperformen hier, vor allem nicht im Podcast, bitte.
Kai Ole Hartwig: Ja, es geht ja nicht, dass wir irgendwas wissen können oder sonst irgendetwas.
Kai Ole Hartwig: Deswegen lassen wir ja eigentlich auch Vibe-Coding-mäßig die KI alles programmieren.
Kai Ole Hartwig: Ja, und chillen hier halt und machen nur nette Podcasts und ansonsten trinken wir den ganzen Tag über Kaffee oder Tee oder beides.
Daniel Langemann: Das mache ich ohne Podcast doch auch.
Daniel Langemann: Also ich verstehe den Unterschied nicht.
Daniel Langemann: Sehr gut.
Daniel Langemann: Also.
Daniel Langemann: Mit Bierchen.
Daniel Langemann: Zu streamen.
Kai Ole Hartwig: Sorry.
Kai Ole Hartwig: Der Unterschied ist, dass wir im Podcast halt miteinander quatschen und dabei trinken.
Kai Ole Hartwig: Alkoholfreie Getränke.
Kai Ole Hartwig: Vielleicht sollten wir mal so eine Abendsession machen.
Kai Ole Hartwig: Das müssten wir aber als Live-Podcast machen.
Kai Ole Hartwig: Das wäre auch noch eine Idee.
Kai Ole Hartwig: Ja.
Daniel Langemann: Bin dabei.
Kai Ole Hartwig: Ich weiß noch nicht, ob das... Mal schauen, mal schauen.
Daniel Langemann: Ja.
Kai Ole Hartwig: Also, falls ihr das haben wollt, dann müsstet ihr mal kommentieren.
Kai Ole Hartwig: Wo auch immer ihr kommentiert, bei Instagram oder Spotify oder Apple Podcast.
Kai Ole Hartwig: Wir werden das dann drei Wochen später oder so lesen und zur Kenntnis nehmen.
Kai Ole Hartwig: Ja, Agentic Engineering wollten wir eigentlich drüber quatschen.
Kai Ole Hartwig: Ähm, ja.
Kai Ole Hartwig: So, was gibt's da zu sagen, Daniel?
Kai Ole Hartwig: Ach, die ich dir geben müsste, okay.
Kai Ole Hartwig: Hast du mir letzte Woche nicht zugehört?
Daniel Langemann: Also ich würde mal mit der Definition anfangen, die ich nicht gelesen habe und die du mir jetzt geben müsstest, weil ich habe keine Ahnung von dem Thema.
Daniel Langemann: Also ich bin ehrlich, was?
Kai Ole Hartwig: Genau.
Kai Ole Hartwig: Okay.
Kai Ole Hartwig: Ja, also für mich und ich glaube, das ist die lebende Definition, die wir gerade so, der lebende Konsent, den es so gibt, ist Vibe Coding.
Kai Ole Hartwig: Du sagst, der KI, bau mir das neue Slack für meine Company.
Daniel Langemann: Ja, genau.
Daniel Langemann: Ja, dann kannst du ein Scheren.
Kai Ole Hartwig: mach das ohne Fehler.
Kai Ole Hartwig: Ja?
Kai Ole Hartwig: Der Hype für, also der Trick für alle Hype-Performer immer hinten, mach keine Fehler und mach eine Million-Dollar-Company raus.
Kai Ole Hartwig: Ähm...
Kai Ole Hartwig: So, und dann nimmst du das Ding und dann läuft das auf Localhost 3000 oder so und sagst, hey, ich habe das geile neue Ding hier hochgezogen, war eine Sache von zwei Stunden und alles lief.
Kai Ole Hartwig: Und Agentic Engineering ist die Weiterentwicklung der Softwareentwicklung, des Programmierens oder des Entwicklens.
Kai Ole Hartwig: Ich finde, Programmieren haben wir lange schon nicht mehr gemacht, weil Programmieren war dieses, jemand produziert einfach Code runter, so Code-Monkey-mäßig.
Daniel Langemann: Ja.
Kai Ole Hartwig: Und Entwicklung war schon lange, länger dieses Thema mit, okay, wir haben ein Problem und wir überlegen uns, wie lösen wir das in der Softwareentwicklung.
Kai Ole Hartwig: Ja, vom Problem angefangen zur Software zu fertigen und Agentic Engineering ist jetzt im Prinzip,
Kai Ole Hartwig: Du hast jemand, der kann Software entwickeln, der versteht die Prinzipien, der könnte selber programmieren, wenn er Lust dazu hat.
Kai Ole Hartwig: Und geht jetzt hin und arbeitet mit Methoden wie Spectrum Development, über das wir auch schon gesprochen haben, mit der KI zusammen.
Kai Ole Hartwig: In einer Form, dass die KI spezifizierte Aufgaben bekommt, die dann auch wieder überprüft werden, ob sie denn entsprechend ausgeführt wurden.
Daniel Langemann: Also eher zum Code generieren und zum Sparring vorher so ein bisschen, das Back-Driven.
Kai Ole Hartwig: Genau, die... Ja, genau, also du hast einen KI-gestützten Entwicklungsprozess.
Kai Ole Hartwig: Und hast selber aber die Fähigkeiten, auch das selber tun zu können, um halt das vollständig zu beurteilen.
Kai Ole Hartwig: Also das heißt, du hast quasi das Ownership, Best-Wort-Bingo heute so ein bisschen, aber den Ownership über den Coach weiter, der da rauskommt.
Daniel Langemann: Oh ja, ich brüll gleich Bingo.
Kai Ole Hartwig: Ähm.
Daniel Langemann: Hast du so oder so?
Daniel Langemann: Also du haftest ja auch als Unternehmer für das, was du produzierst.
Daniel Langemann: Aber anderes Thema.
Kai Ole Hartwig: Anderes Thema.
Kai Ole Hartwig: Nicht schon wieder so ein juristisches Ausschweife hier heute, bitte.
Daniel Langemann: Okay.
Kai Ole Hartwig: Aber du gehst halt hin und hast das Ownership, ja, also das heißt, du prüfst auch, du bist verantwortlich dafür, was dort passiert ist und das hast du halt beim BIP-Coding ja irgendwie nur implizit und hier halt ganz explizit.
Kai Ole Hartwig: Ja, so wie früher in der Softwareentwicklung, du bist verantwortlich für den Shit, der da rauskommt.
Kai Ole Hartwig: aber du hast einen KI-geschützten Prozess.
Kai Ole Hartwig: Der unterstützt dich halt vielleicht schon bei dem Weg der Spezifikation.
Kai Ole Hartwig: Ja, das wäre dieses, wir machen Spectrum Development, also wir sagen, okay, wir möchten dieses Thema lösen und dann schreibst du deine Spezifikation auf KI-gestützt und hast dann nachher deine Tasks und diese Tasks sind ja im Prinzip dafür da, dass die KI das dann auch wieder abarbeitet und halt quasi die KI dein Code-Monkey ist, dein Programmierer.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ja, deswegen der Job des Programmierers, der einfach nur Code schreibt,
Kai Ole Hartwig: wenn der nicht schon vor zehn Jahren tot war, jetzt ist er tot.
Kai Ole Hartwig: Aus meiner Sicht.
Kai Ole Hartwig: Weil das kann die KI halt tatsächlich einfach schneller.
Kai Ole Hartwig: Und die hat das halt mittlerweile ja so viele Trainingsdaten gehabt, dass die Qualität halt auch
Kai Ole Hartwig: in Ordnung ist.
Kai Ole Hartwig: Man muss das reviewen, man muss da Leitplanken einbauen mit den Spezifikationen, was Sicherheit, was Architektur etc.
Kai Ole Hartwig: angeht.
Kai Ole Hartwig: Das muss man auch reviewen, aber manchmal vergisst die Dinge.
Daniel Langemann: Ja, das große Problem finde ich aber, dass du mittlerweile, ich glaube, mehr Zeit, also ich rede jetzt nur von mir, ich habe keine Studien dazugelesen, aber ich glaube, ich investiere mehr Zeit, mit der KI zu reden, zu diskutieren und zu reparieren,
Daniel Langemann: was sie baut, als manchmal, weiß ich nicht, wenn ich mich klonen könnte, ob der Daniel, der fleißig alles runtertippt, schneller wäre.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja.
Daniel Langemann: Also ein anderes Beispiel ist so, gerade wenn es Präsentationen gibt, hast du dieses leere Blattproblem.
Daniel Langemann: Also ich bin ganz schlecht darin, mich hinzusetzen und zu sagen, ich mache eine Präsentation.
Daniel Langemann: Also kann ich sagen, KI, mach mal.
Daniel Langemann: Sie rotzt da was hin.
Daniel Langemann: Ich gucke an und sage, das ist okay, aber das gefällt mir nicht, das gefällt mir nicht, das gefällt mir nicht.
Daniel Langemann: Und dann kann ich anfangen umzubauen und bin schnell.
Daniel Langemann: Und gerade dieses Umbauen ist eigentlich, also beim Programmieren oder beim Softwareentwickeln, sagen wir mal, bin ich tiefer drin, dann habe ich dieses weiße Blattproblem nicht so.
Kai Ole Hartwig: Hm.
Kai Ole Hartwig: Hm.
Daniel Langemann: Da sage ich der KI, mach mal.
Daniel Langemann: Mit Spec-Driven Development fange ich an, Sachen runter zu spezifizieren.
Daniel Langemann: Früher habe ich Tickets runtergeschrieben im Team.
Daniel Langemann: Wenn ich alleine war, habe ich trotzdem ähnlich irgendwie versucht, mich erstmal vorher zu sortieren.
Daniel Langemann: High-Level angefangen zu sagen, guck mal, was ist das Problem, wo kann, also bei Fehlersuche, wo kann es herkommen, was kann die Ursache sein oder bei Feature-Entwicklung, was möchten wir, was sind Nebenkriegsschauplätze, also will ich nicht mitmachen, was mache ich mit und habe mich dann so runterspezifiziert.
Daniel Langemann: Das gleiche ist jetzt mit Spectrum Development auch nur im Ping-Pong mit der KI erstmal.
Daniel Langemann: Also...
Kai Ole Hartwig: Ja, so, meine Erfahrung, und dazu gibt es aber auch Paper, also es gibt ein Paper, das sagt, relativ neu auch, je häufiger die KI ein Dokument anfasst, also eine Datei oder irgendetwas, und da Veränderungen macht, macht, steigt die Wahrscheinlichkeit, dass Dinge kaputt gehen.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Verrückt, ne?
Kai Ole Hartwig: Also gibt es eine Untersuchung zu und das ist auch völlig, also man kann das nicht so genau eingrenzen, wann das passieren wird.
Kai Ole Hartwig: Ja, meine 7 versuchen mal 8, mal 20, so.
Kai Ole Hartwig: Also, das passiert.
Kai Ole Hartwig: Und natürlich, und das ist nämlich dieser Faktor mit, du musst das reviewen, sehe ich auch immer wieder bei mir Glitches oder AI-Slop, wo auf einmal etwas verändert wird, was überhaupt nichts mit der Aufgabe zu tun hat.
Kai Ole Hartwig: Ja, auch das, dazu gibt es Studien, die halt auch sagen, okay,
Kai Ole Hartwig: In 20% der Zeit war es, glaube ich, da gilt mich jetzt nicht auf die 20% fest, fest, macht die KI Dinge kaputt, die sie vorher richtig gemacht hat.
Kai Ole Hartwig: Einfach random, zwischendrin.
Kai Ole Hartwig: Das passiert einfach.
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Und aus meiner Erfahrung mit dem Umgang heißt, wo jeder neuen Aufgabe das Kontextwindow zu lernen hilft,
Kai Ole Hartwig: abarbeitet.
Kai Ole Hartwig: Dann, Dann, was hatte ich gesagt?
Kai Ole Hartwig: Feature-Branch, kleiner Kontext.
Kai Ole Hartwig: Also selbst, dass das Kontext-Windows jetzt zum Beispiel bei Cloud Code eine Million ist, ja, ist total schön.
Kai Ole Hartwig: macht es schlimmer.
Kai Ole Hartwig: Also früher mal ein Clear oder Compress oder so, ist total sinnvoll, um die Qualität zu steigern.
Daniel Langemann: Ja.
Kai Ole Hartwig: So, und dann halt wirklich den Shit kontrollieren.
Kai Ole Hartwig: Du kommst nicht um eine Code Review rum.
Kai Ole Hartwig: Und da halt mittlerweile auch bei mir der Fokus ganz krass darauf, ist nur das geändert worden, was ich erwarten würde.
Kai Ole Hartwig: Also an Dateien,
Kai Ole Hartwig: und dann anstellen und dann schaut ja die Pipeline schon, ob die Codequalität mal so in dem Rahmen ist, wo es sein soll, ne?
Daniel Langemann: Ja, also ich habe zum Beispiel, also genau, um bei dem Beispiel zu bleiben, bei mir fällt halt auf, die Zeit, die ich früher
Kai Ole Hartwig: Was Syntax und so weiter.
Kai Ole Hartwig: Hm.
Daniel Langemann: vorne länger gebraucht hätte, brauche ich mindestens doppelt hinten beim Reviewen.
Daniel Langemann: Also ein Review-Prozess ist ja nicht etwas, was mich automatisch schneller macht, sondern wenn ich das eins zu eins vergleiche, damals beim Testen, war auch immer das Argument, ja, Testen macht mich langsamer.
Daniel Langemann: Ja, natürlich, im ersten Moment, weil ich auch Tests schreiben muss, aber hinten raus viel weniger Fehler habe und dadurch Zeit spare.
Kai Ole Hartwig: Mhm.
Daniel Langemann: Jetzt habe ich so das Gefühl, es ist genau das Gleiche mit KI macht mich schneller, das stimmt gar nicht, weil ich muss hinterher viel mehr reviewen und ich muss mich zum Beispiel in fremden Code einlesen, verstehen, was da passiert, reparieren, dann passiert mir zumindest immer wieder genau das, was du sagst, sagt die KI, oh ja, du hast recht, baut alles um und macht es noch schlimmer oder versteckt zwei andere Sachen, wo ich wieder von vorne anfange zu reviewen und ich verliere hinten raus viel mehr Zeit und
Daniel Langemann: Gerade in Themen, wo ich mich gut auskenne oder in Frameworks zum Beispiel, wo ich mich gut auskenne, wo ich sage, es gibt in Symfony oder in API-Plattformen gewisse Pattern, Sachen, die man macht oder nicht macht oder auch generell beim Programmieren, so Kontext irgendwie trennen, das kriegt die ganz schwer hin und klatscht dann zum Beispiel überall lustig Methoden irgendwo dran und dann findet man dreimal, fünfmal die gleiche Methode.
Kai Ole Hartwig: Ja, genau.
Kai Ole Hartwig: Und das ist halt das, was dann nachher auch das Vibe-Coding und das Agentic Engineering unterscheidet.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Dass du halt schaust, die KI so zu steuern mit deinen Specs auch, dass diese Dinge halt nicht passieren.
Daniel Langemann: Der macht keine Fehler am Ende.
Kai Ole Hartwig: Dass man halt
Daniel Langemann: Genau.
Daniel Langemann: Mhm.
Kai Ole Hartwig: No new bugs, please.
Kai Ole Hartwig: Genau.
Kai Ole Hartwig: So, und das ist halt eine Disziplin, ja.
Kai Ole Hartwig: Und ich glaube, dieses, oder mein Eindruck ist, mal von diesem Ich-Glaube-Wer wegzukommen, dass ganz häufig nur auf die Zeit des Programmierens, des Code-Erschaffens geschaut wird bei diesen Metriken.
Kai Ole Hartwig: Ein guter Freund von mir, den ich als Entwickler auch sehr, sehr schätze, hat mal gesagt, naja, für eine vernünftige Code-Review
Kai Ole Hartwig: benötigst du normalerweise mindestens die gleiche Zeit wie für das Programmieren.
Daniel Langemann: Ja, mindestens.
Daniel Langemann: Es könnte Projekte geben, wo es jetzt noch nicht gute Spezifikationen gibt.
Kai Ole Hartwig: So, und jetzt sehen wir halt, das verschiebt sich so krass, das Programmieren geht jetzt auf einmal viel schneller.
Daniel Langemann: So.
Kai Ole Hartwig: Wir schreiben jetzt aber viel bessere Spezifikationen auf einmal.
Kai Ole Hartwig: Also vielleicht wäre früher Programmieren auch schneller gegangen, wenn die Spezifikationen besser gewesen wären.
Kai Ole Hartwig: Ja, aber jetzt in der ganz heilen Welt schreiben wir jetzt ja Spectrum Development mäßig beim Agenting Engineering unsere hervorragenden Spezifikationen, die dazu führen, dass die KI halt sehr schnell sehr spezifischen Code entwickeln kann und möglichst wenig Fehler dabei produziert.
Daniel Langemann: Was?
Daniel Langemann: Haben die extra Fehler gemacht?
Daniel Langemann: Ja, ja, genau.
Daniel Langemann: Ich habe die... Ja, genau.
Kai Ole Hartwig: Entwickler haben ja früher auch nicht fehlerfreie Sachen geschrieben.
Kai Ole Hartwig: Also so.
Kai Ole Hartwig: Habe ich gehört.
Kai Ole Hartwig: Ich habe natürlich immer bugfrei geliefert.
Kai Ole Hartwig: Das waren immer andere.
Kai Ole Hartwig: Nie bei GitBlame bin ich, habe ich mich erst eine halbe Stunde aufgeregt, dann das GitBlame gemacht, um festzustellen, der Ole...
Daniel Langemann: Da war auch in einem Team irgendwo, also irgendjemand, so ein Freund von mir, war irgendwann beim Kunde vor Ort und wir waren glaube ich auch im Team Review, ich glaube wir waren drei oder fünf Entwickler sogar remote zugeschaltet in allem Gucken.
Daniel Langemann: Der Freund hat den Monitor geteilt.
Kai Ole Hartwig: Was ist das denn für scheiß Code hier?
Daniel Langemann: Richtig abgelästert so.
Daniel Langemann: Oh Mann, ich habe euch so oft gesagt, das ist der letzte Scheiß.
Kai Ole Hartwig: So hätte ich das ja niemals geschrieben.
Daniel Langemann: dann habe ich instinktiv GitBlame gemacht und da taucht da so mein Name auf und ich denke so, oh scheiße, das ist gleich aber groß.
Kai Ole Hartwig: Ey, natürlich hochprofessioneller Code.
Kai Ole Hartwig: Das ist die einzige akzeptable Lösung.
Kai Ole Hartwig: Vergiss, was ich bisher gesagt habe.
Daniel Langemann: Ja, es hatte bestimmt einen Grund, als ich das gebaut habe.
Daniel Langemann: Ja, natürlich haben wir auch Fehler gemacht damals oder immer.
Daniel Langemann: Ich baue jetzt immer noch den perfekten Code, also
Kai Ole Hartwig: Ja, ja, immer noch.
Kai Ole Hartwig: Also das ist so.
Kai Ole Hartwig: Da hat ja auch KI einfach nichts dran verändert, dass halt Fehler passieren und Fehler in den Codes drin sind.
Kai Ole Hartwig: Ähm,
Daniel Langemann: Mein großes Problem ist aber zum Beispiel, aktuell, wenn ich KI-geschriebenen Codes sehe, das, also ich kann es nicht anders beschreiben, das fühlt sich chaotisch an.
Daniel Langemann: Wenn ein Mensch Quelltext schreibt oder ein guter Entwickler zum Beispiel,
Daniel Langemann: dann hast du Text, der liest sich von oben nach unten, man erkennt eine rote Linie, wo er sagt, ich arbeite diesen Fall ab, wenn es diese Ausnahme gibt, gibt es einen Return, eine Exception oder eine andere Methode, die aufgerufen wird, das wird gekapselt und es liest sich halt wie so ein roter Faden durch.
Kai Ole Hartwig: Mhm.
Daniel Langemann: Und bei KI ist es oft so, dass du sagst, Alter, der springt von vorne nach hinten, von links nach rechts und ich kriege Kopfschmerzen beim Lesen, weil der immer wieder neuen Kontext aufmacht und
Daniel Langemann: Der liest, also macht irgendwelche Sachen, wenn das eintritt, dann kommen drei Fehlerbehandlungen.
Daniel Langemann: Wenn das eintritt, dann kommen da noch ein paar Fehlerbehandlungen.
Daniel Langemann: Dann gibt es einen Codeblock, der eigentlich gar keine Bedeutung mehr hat, weil der war vor fünf Schritten irgendwann mal wichtig, aber den hat die KI natürlich nicht aufgeräumt und ich habe ihn auch nicht entfernt, weil ich nicht wusste, dass er da ist.
Kai Ole Hartwig: Ab.
Kai Ole Hartwig: Ab.
Daniel Langemann: So wächst der Code dann.
Daniel Langemann: Und das habe ich jetzt schon mit ein paar Projekten gesehen, die mit Vibe Coding entstanden sind, wo du sagst, es funktioniert, es läuft alles glatt, aber
Daniel Langemann: Das Aufräumen nachher ist echt problematisch und das ist wie so, wenn du deinem Sohn oder deinem Kind sagst, räum dein Zimmer auf, das ist sauber, aber geh bloß nicht an die Schränke oder schau nicht unter das Bett, da findest du das Chaos und so fühlt sich das auch so ein bisschen vom Code an, also ich nutze auch super KI und ich bin auch super viel damit unterwegs,
Daniel Langemann: Also ganz außen vor, ich bin gar nicht dagegen, aber ich habe so meine Probleme einfach oder diese üblichen Wege, Sachen, die man ausprobiert hat, die für mich nicht funktioniert haben.
Kai Ole Hartwig: Definitiv, definitiv.
Kai Ole Hartwig: Also ich bin ja auch nicht der von Anfang an der größte Fan.
Kai Ole Hartwig: Also ich glaube, wir haben sehr früh damit gestartet und ich war da auch sehr euphorisch.
Kai Ole Hartwig: Und ich sage jetzt mal, ich lerne aus Schmerzen so ein bisschen.
Kai Ole Hartwig: Also für dein Bettproblem habe ich eine pragmatische Lösung Hochbett.
Kai Ole Hartwig: dann siehst du das.
Daniel Langemann: Da passt mehr drunter.
Daniel Langemann: Hm.
Daniel Langemann: Hm.
Daniel Langemann: Hm.
Kai Ole Hartwig: Und für die KI habe ich, ja, da passt auch mehr drunter, definitiv.
Kai Ole Hartwig: Aber du siehst es auch leichter.
Kai Ole Hartwig: Du musst dich nicht selber so.
Kai Ole Hartwig: Und naja, die KI muss durch die gleichen Quality Gates wie der menschliche Entwickler.
Kai Ole Hartwig: PHP-Stand, Clean Code.
Kai Ole Hartwig: Und was ich halt einfach mache, was heißt einfach, aber was wir mittlerweile machen, oder was ich eingeführt habe,
Kai Ole Hartwig: ist, natürlich muss der auch PHP-Stand etc.
Kai Ole Hartwig: bestehen.
Kai Ole Hartwig: So, aber wir haben halt auch einfach ein Skill, Clean Code, ja, nach, ja, Bob, wie heißt er denn?
Kai Ole Hartwig: Naja, steht hier bestimmt, da steht es irgendwo, ne, seht ihr jetzt nicht.
Daniel Langemann: Nicht, nee.
Kai Ole Hartwig: Clean Code, Clean Architecture, nach den Prinzipien, die Review macht, und dann hast du halt einfach das Ding,
Kai Ole Hartwig: dass du natürlich nicht die Schwierigkeiten hast, dass dein Code nicht diesen Prinzipien entspricht.
Kai Ole Hartwig: Also ich zwinge quasi die KI dazu, den Code in dieser Art und Weise zu schreiben, indem ich immer wieder ihr die Aufgabe gebe, review das nach diesen Prinzipien.
Daniel Langemann: Schnell da.
Kai Ole Hartwig: Und es halt grundsätzlich per Pistain ausgeführt wird und dann halt zurückkommt mit, hey,
Kai Ole Hartwig: ähm, das passt aber hier nicht, das PRP-Stan-Level wird nicht geschafft.
Kai Ole Hartwig: Und, ähm, das dann auch so weit geht, dass die KI sich darüber beschwert, das würde jetzt ja viel zu viel Zeit fressen, das umzubauen.
Kai Ole Hartwig: Im Moment musst du halt dann, ähm, hart bleiben, jetzt sind meine AirPods ausgefallen, naja, äh, musst, musst du halt hart bleiben und, und der KI halt so sagen, ja, Freund der Sonne, ähm,
Daniel Langemann: Mhm.
Kai Ole Hartwig: Mach mal, ja, wir bauen hier ordentliche Software, nicht, wir machen hier das Hobbyprojekt, was ein bisschen laufen soll, sondern orientier dich auch an dem Code, wie wir das bisher gemacht haben.
Kai Ole Hartwig: Also du musst ihn halt wirklich da reinlenken, gerade auch, ich finde, in PHP ist es zum Beispiel schlimmer als in Go, ähm,
Kai Ole Hartwig: dass wirklich sauber gearbeitet wird.
Kai Ole Hartwig: Und ich glaube, das hängt sehr, oder mein Eindruck ist, es hängt sehr, sehr, sehr viel damit zusammen, welche Qualitäten die Trainingsdaten hatten.
Daniel Langemann: Ja, bestimmt sogar.
Daniel Langemann: Also, dass das nicht das Gelbe vom Ei war, weil viele Corporate-Sachen, sag ich mal, wo gute Entwickler unterwegs waren, natürlich nicht Open-Source waren.
Daniel Langemann: PHP lange Zeit eine Einstiegssprache war.
Daniel Langemann: Jetzt hat das Glück JavaScript geerbt.
Daniel Langemann: Das senkt natürlich das Level.
Daniel Langemann: Also, es ist noch nicht mal schlecht gemeint.
Daniel Langemann: Also, es kommen halt viele neue, die probieren sich aus.
Kai Ole Hartwig: Und viele Open-Source-PAP-Projekte haben auch hervorragende Code-Qualität seit Jahren.
Kai Ole Hartwig: Also es ist ja eher so der, ich sag mal, der Wildwuchs, die Noise quasi, die außenrum so auf GitHub rumliegt und so.
Kai Ole Hartwig: Und da liegt halt auch viel rum, was halt einfach aus professioneller Entwicklungssicht halt ja eher so Pop-Charakter hat von der Qualität her.
Daniel Langemann: Aber nochmal zurückzukommen auf das Thema, gerade so Clean Architecture und das ganze Thema.
Daniel Langemann: Ich
Daniel Langemann: sehe KI noch nicht mal als Problem, sondern gerade dieses Clean Architecture und ich erzähle halt oder nutze gerne die Metapher, das ist wie so ein Buch schreiben.
Daniel Langemann: Also du kannst
Kai Ole Hartwig: Hm?
Kai Ole Hartwig: Hm?
Daniel Langemann: stichpunktartig oder kurze Sätze nutzen, um einfach so etwas zu beschreiben.
Daniel Langemann: Du kannst es blumig ausdrücken.
Daniel Langemann: Die Art und Weise, wie Bücher geschrieben werden, man erkennt sogar die Handschrift von einem Autor.
Daniel Langemann: Und so ist es ja bei Quelltext auch.
Daniel Langemann: Und so ist es auf der einen Seite schwer, das irgendwie technisch sicherzustellen, dass gewisse Sachen...
Daniel Langemann: richtig sind.
Daniel Langemann: Es ist sogar zwischen Teams unterschiedlich, dass man sagen könnte, in einem Team wirst du abgefeiert dafür, weil du echt guten Code schreibst und alle finden das toll, dass sie den gut lesen können.
Daniel Langemann: Du kommst ins nächste Team und die sagen so, ne, das versteht ja keine Sau.
Daniel Langemann: Also das kann dir passieren, ohne dass du schlechter oder besser geworden bist.
Daniel Langemann: Deswegen finde ich das schwer, festzuhalten, dass die KI, zu sagen, KI mach mal,
Daniel Langemann: Auf der anderen Seite ist halt auch, also mein Empfinden, immer wenn ich diesen Quelltext lese, habe ich oft das Gefühl, dass du bei KI einfach so, mir fehlt der rote Faden, ich erkenne den nicht.
Daniel Langemann: Oder ich finde den nicht.
Daniel Langemann: Oder vielleicht ticke ich auch anders wie der Großteil der Trainingsdaten.
Daniel Langemann: Und das ist mein Problem.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ich kenne aber das Gefühl, das du beschreibst.
Kai Ole Hartwig: Ich weiß es auch.
Kai Ole Hartwig: Es ist halt einfach fremder Code und es ist häufiger nicht so, wie man das erwarten würde.
Kai Ole Hartwig: Darum sage ich ja, man muss das quasi mitgeben.
Kai Ole Hartwig: Die Specs bei mir enthalten zum Beispiel auch immer die Informationen,
Kai Ole Hartwig: sehr technische Informationen zu, wie ich auch die Architektur haben möchte.
Kai Ole Hartwig: Wie ich so etwas erwarte.
Kai Ole Hartwig: Ich habe so ganz grundsätzlich mal definiert, definiert, wie ich Sachen aufbaue.
Kai Ole Hartwig: Also wo zum Beispiel, also sowas auch festgelegt wie die zyklomatische Komplexität.
Kai Ole Hartwig: dass ich da fest sage, pass auf, meinetwegen erreiche eine zyklomatische Komplexität von 10, ich möchte aber grundsätzlich unter 3 bleiben.
Kai Ole Hartwig: In Ausnahmen kannst du davon abweichen.
Kai Ole Hartwig: Und da auch sehr an so Standards...
Kai Ole Hartwig: definiert, die es ja allgemein in der PHP-Welt gibt.
Daniel Langemann: Ja.
Kai Ole Hartwig: Und das hat dazu geführt, dass die Qualität für mein Empfinden wesentlich besser geworden ist.
Kai Ole Hartwig: Ja, manchmal fehlt da der rote Faden und manchmal hat die KI auch echt dumme Ideen zwischendrin.
Kai Ole Hartwig: Auf der anderen Seite, wenn die Spezifikation gut ist, und das musste ich auch lernen, man muss sie sehr, sehr genau definieren, dann wird das Ergebnis auch sehr gut.
Kai Ole Hartwig: Und das hatte ich am Anfang auch überhaupt gar nicht.
Kai Ole Hartwig: Als wir das erste Mal über Spectrum Development gesprochen haben,
Kai Ole Hartwig: Das hat mir quasi erstmal den Weg dahin eröffnet, wirklich effizienten, guten Code agentisch auch in einer gewissen Art und Weise schreiben zu lassen, bis zu einer gewissen Selbstständigkeit so Probleme abarbeiten zu lassen, auch wirklich wie andere hingehen, die sagen, ja, pass auf, ich gehe eigentlich hin.
Daniel Langemann: Mhm.
Kai Ole Hartwig: schreibe die specs und dann sage ich dem ding jetzt okay pass auf hier die sachen die auf ready for coding oder was auch immer liegen und erhalten in ready liegen jetzt quasi für dich da im bord liegen die arbeitest du jetzt heute nacht alle selbstständig ab und morgens hingehen und reviewen ja zum teil selber auch tests implementiert haben die dann durchlaufen
Kai Ole Hartwig: Und so halt vorgehen und halt wirklich mit Spezifikationen zu arbeiten, damit im Prinzip je nach sechs, acht Entwicklern hingehen und das einfach abarbeiten.
Kai Ole Hartwig: Genauso
Kai Ole Hartwig: machen wir das halt zum Beispiel mit Inhalterstellung.
Kai Ole Hartwig: Entwürfe und so weiter werden halt, wir arbeiten Pläne aus und diese Pläne werden selbstständig abgearbeitet.
Daniel Langemann: Das habe ich auch schon gehört, dass Leute das können.
Kai Ole Hartwig: Und das war wirklich eine krasse Umgewöhnung, auch was dieses sprachliche Definieren ist.
Kai Ole Hartwig: Ich habe immer noch nicht den Zugang gefunden, dass ich sage, ich spreche das rein, ich schreibe das wirklich runter.
Kai Ole Hartwig: Aber auch mein gesamter Tagesablauf hat sich geändert.
Kai Ole Hartwig: Ich habe ja eigentlich sehr, sehr wenig Zeit immer zum Arbeiten aus äußeren Umständen.
Kai Ole Hartwig: Und ich muss sagen, so dieses Vorgehen, Speck-Driven-Development und über Nacht programmieren lassen, hat mir sehr viel Produktivität zurückgegeben.
Daniel Langemann: Ja, krass.
Daniel Langemann: Also, ich sehe für mich mein Problem,
Kai Ole Hartwig: Also, wenn du mich fragst, ich bin jetzt garantiert produktiver im Sinne von Features, die gebaut werden, als vor zwei Jahren.
Kai Ole Hartwig: Als ich noch Vollzeit, oder vor drei Jahren, als ich Vollzeit arbeiten konnte und halt auch manchmal 60 Stunden in der Woche gemacht habe.
Kai Ole Hartwig: Programmieren, ne?
Kai Ole Hartwig: Den anderen Shit.
Daniel Langemann: das fing damals schon an mit dem Test-Driven-Development.
Kai Ole Hartwig: Mhm.
Daniel Langemann: Also ich verstehe wieso, weshalb, warum, ich sehe die ganzen Vorteile, aber ich habe es nie für mich geschafft, zum Beispiel vorab Sachen zu spezifizieren und die Analogie ist ja jetzt gleich, da hast du auch vorab mit Tests zwar, aber hast du auch spezifiziert, hast Tests geschrieben und dann den Qualtext dazu geschrieben, um das Feature zu testen und es grün zu bekommen.
Daniel Langemann: Und
Daniel Langemann: ich weiß es nicht, ich bin nie so tief in dem Thema immer drin gewesen oder mir fehlt anscheinend die Vorstellungskraft oder so.
Daniel Langemann: Also mein Problem ist einfach, ich muss mich hinsetzen und ich fange, also wie mit Bauklitzchen, du fängst an, stellst so hier und da ein paar auf und sagst, okay, das könnte grob so passen,
Daniel Langemann: Und dann schmücke ich die Sachen aus und dann merke ich so, guck mal, an der Stelle, da habe ich etwas überhaupt nicht mitbekommen.
Daniel Langemann: Muss noch irgendwo eine andere Datenquelle geupdatet werden.
Kai Ole Hartwig: Mhm.
Daniel Langemann: Also so erarbeite ich.
Daniel Langemann: Und ich sage ja immer so, dieses Test-Driven-Development hat bei mir nicht funktioniert, weil ich muss erstmal die Klötzchen überall hinstellen.
Daniel Langemann: Dann die Verbindungen herstellen, dann nochmal hin und her schieben, die Hälfte wieder abreißen, weil es doch nicht passt oder ein anderes Pattern besser passt.
Daniel Langemann: Und das kann ich vorher gar nicht und das ist egal, ob bei Test-Driven-Development oder ist auch Speck-Driven.
Daniel Langemann: Also ich kann vorspezifizieren und sagen, guck mal, Datenbank, brauche ich das, dass die Entity oder in der Tabelle müssen diese Felder drin sein.
Daniel Langemann: Ich weiß, dass das ein Problem ist.
Kai Ole Hartwig: Das mache ich zum Beispiel im Spec.
Daniel Langemann: Also so High-Level-Sachen, die kann ich alle abfrühstücken.
Daniel Langemann: Echt nicht?
Kai Ole Hartwig: Das mache ich zum Beispiel gar nicht.
Kai Ole Hartwig: Ich lege gar nicht im Spec-Driven Development, also in meinen Specs, lege ich gar nicht fest, welche Datenbankfelder und so.
Daniel Langemann: Okay.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Nee.
Kai Ole Hartwig: Ich definiere wirklich Architektur-
Kai Ole Hartwig: mit, okay, da erwarte ich, dass das ein eigenes Blah ist und das ist ein eigenes Blub.
Kai Ole Hartwig: Und ich lege jetzt aber nicht auf Objektebene fest die Sachen.
Kai Ole Hartwig: Weil das weiß das Ding viel, viel besser als ich am Tagesende.
Kai Ole Hartwig: Und was ich ihm aber mitgebe, ist so etwas wie, hey, wenn wir passende Felder haben für diese Sachen, dann benutzt sie natürlich.
Kai Ole Hartwig: Mach nicht bitte für jeden Shit ein neues Datenbankfeld.
Daniel Langemann: Und macht keine Fehler.
Daniel Langemann: Sorry.
Kai Ole Hartwig: Ich glaube, das ist so ein bisschen der Unterschied, dass die Kunst ist, spezifisch unspezifisch zu sein.
Kai Ole Hartwig: Ähm.
Daniel Langemann: Was wir Entwickler bestimmt sehr gut können, nicht.
Daniel Langemann: Ähm.
Kai Ole Hartwig: und es verändert, also warte mal, wie erkläre ich das denn jetzt, was ich denke?
Kai Ole Hartwig: Also ich fühle das total mit Test-Driven-Development.
Kai Ole Hartwig: Ich habe mich auch immer mega schwer damit getan, vorab Tests zu schreiben.
Kai Ole Hartwig: Ich habe das quasi nie gemacht, wenn ich es vermeiden konnte.
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Deswegen ist mein Vorgehen jetzt auch ein bisschen anders.
Kai Ole Hartwig: schon.
Kai Ole Hartwig: Die Specs sind ja auch Teil-KI generiert.
Kai Ole Hartwig: Also ich arbeite ja quasi auf Epic-Ebene und dann vielleicht noch auf Story-Ebene und der Rest ist KI generiert.
Daniel Langemann: Ja.
Kai Ole Hartwig: Und dann...
Kai Ole Hartwig: werden die Testfälle geschrieben.
Kai Ole Hartwig: Diese Testfälle review ich dann.
Kai Ole Hartwig: Und sage, ja, okay, das entspricht dem, was ich erwarte, oder, nee, das muss geändert werden.
Kai Ole Hartwig: Und passt die Specs dafür an?
Kai Ole Hartwig: So quasi diesen Rückkanal aus.
Kai Ole Hartwig: Wenn ich sage, der Testfall für das muss geändert werden, dann passt auch die Specs an.
Kai Ole Hartwig: Und dann lasse ich programmieren.
Kai Ole Hartwig: Wann auch immer, direkt oder nachts.
Daniel Langemann: Ja, ja.
Kai Ole Hartwig: Wie man das halt so gerade machen möchte, ob man jetzt mehr Autonomie in dem System haben möchte oder nicht.
Kai Ole Hartwig: Und was ich auch habe, ist,
Kai Ole Hartwig: dass ich quasi Learnings, wenn ich Sachen korrigiere nachträglich, Learnings schreiben lasse, die dann wieder geladen werden, wenn ich neuen Kontext brauche.
Daniel Langemann: Krass.
Daniel Langemann: Gut, dann arbeitet es komplett anders.
Kai Ole Hartwig: Es ist halt, genau, ich glaube, wir arbeiten da gerade völlig anders, aber das ist für mich halt der Weg, den ich auch aus diesen Schmerzen quasi mit, es funktioniert nicht,
Daniel Langemann: Ja, ja.
Daniel Langemann: Das fängt von den Modellen ab.
Kai Ole Hartwig: rausgefunden habe, wie es für mich gerade am besten funktioniert.
Kai Ole Hartwig: Ich weiß nicht, ob das der beste Weg ist.
Kai Ole Hartwig: Also kein Plan.
Kai Ole Hartwig: Und ob das der richtige Weg ist, ob der in zwei Monaten sich noch genauso gut anfühlt wie jetzt.
Kai Ole Hartwig: Vielleicht gibt es dann einen komplett anderen Weg, den ich gehe.
Daniel Langemann: Das fängt von den Modellen und den Fähigkeiten auch ab, glaube ich.
Daniel Langemann: Also
Kai Ole Hartwig: Und
Kai Ole Hartwig: Ich habe mit Test-Driven-Development die gleichen Schwierigkeiten gehabt.
Kai Ole Hartwig: Ich habe auch am Anfang mit Agentic Engineering oder Vibe-Coding einfach keine coolen Ergebnisse gehabt.
Kai Ole Hartwig: Das hat sich erst verändert durch das Back-Driven-Development und dass ich dann mitbekommen habe, dass andere wirklich auch so diese Möglichkeit haben zu sagen, okay, ich
Kai Ole Hartwig: Lass das komplett selbstständig laufen und das Ergebnis ist da, wenn ich wieder anfange zu arbeiten.
Kai Ole Hartwig: Diese Idee, die fand ich einfach so faszinierend.
Daniel Langemann: Ja, ist auch so.
Daniel Langemann: Du stehst auf und deine Arbeit ist fertig.
Daniel Langemann: Kannst dich wieder hinlegen.
Daniel Langemann: Ja, ja.
Kai Ole Hartwig: Ja, nicht, dann schreibst du die nächsten Speziele, dann testest du ja...
Kai Ole Hartwig: den Teil, der nicht automatisch getestet ist und reviewst und schaust, ist das denn jetzt auch alles entsprechend oder sagst nochmal, ah, okay, hier muss noch nachgearbeitet werden und bereitest ja quasi die nächste Nacht vor, wo dann die KI wieder losrennt selbstständig und macht.
Daniel Langemann: Ich muss sagen, ich bin da definitiv anders unterwegs, weil bei mir war es, also auch mit dem Test-Driven-Development, wo ich nicht warm geworden bin, ich habe, während ich die Bauklötzchen verteilt habe, immer schon Tests dann passend dazu geschrieben, aber eher aus der Not heraus, weil ich zu faul war, eine Klasse immer wieder neu zu testen und Tests einfach viel schneller ausführbar sind, als irgendwie F5 im Browser zu drücken und dann alle Testfälle durchzulaufen.
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Ja, siehst du, ja.
Daniel Langemann: Also das war so die Faulheit, die mich da definitiv getrieben hat.
Kai Ole Hartwig: Ja, und ich war immer derjenige, der die Testfälle dann danach geschrieben hat und dann nochmal die Architektur angepasst hat, wenn ich nicht testen konnte.
Kai Ole Hartwig: Ja.
Daniel Langemann: Ja, oder so.
Daniel Langemann: Also das war Ping-Pong.
Daniel Langemann: Also ich glaube, ich habe einen Schritt früher angefangen, wenn so das Wireframe oder so die Blaupause entstanden ist, wo ich gesagt habe, jetzt weiß ich, wie ich die Sachen verknüpfe.
Daniel Langemann: Ich hatte schon Dateien irgendwo liegen, die vielleicht noch eine Klasse enthalten haben, aber ein paar Methoden und die leer waren oder so.
Daniel Langemann: Da konnte ich Tests dafür schreiben.
Daniel Langemann: Das hat funktioniert.
Daniel Langemann: Ich merke jetzt auch für mich, also ich versuche auch mit Spec-Driven Development zu arbeiten,
Daniel Langemann: Es hilft mir, was ich früher oft gemacht habe oder in Teams war das so, einen anderen Entwickler angerufen, gesagt, guck mal, ich bin an dem Feature dran, ich brauche mal entweder Rubber Ducking oder so Ping-Pong-Spielen, habe ich es genannt.
Kai Ole Hartwig: Mhm.
Daniel Langemann: Man hat sich zusammengesetzt und so gegenseitig hochgeschaukelt.
Daniel Langemann: Der andere hat dann immer gesagt, hast du an die Stelle schon gedacht?
Daniel Langemann: Nein, habe ich natürlich vergessen.
Daniel Langemann: Bedenk das, das ist schon dreimal schiefgegangen.
Daniel Langemann: Dann hat man so eine halbe Stunde, Stunde Ping-Pong gespielt, hat Gewissen gehabt und hat das dann abgearbeitet.
Daniel Langemann: Das ist jetzt so für mich Speck-Driven-Development in die Richtung, dass ich sage, ich fange an, das Feature zu spezifizieren und hoffe auf dieses gleiche Ping-Pong von der KI, dass sie sagt, aber da gibt es noch Rückfragen, das ist zum Beispiel noch unklar, was für mich natürlich offensichtlich ist, aber für die KI nicht, weil sie es nicht weiß.
Daniel Langemann: Also das ist so ähnlich für mich, dass ich jetzt halt nur KI gegen Mensch getauscht, äh, Mensch gegen KI getauscht habe.
Kai Ole Hartwig: Ja.
Daniel Langemann: Auf der anderen Seite, gerade wenn ich so fix, also im Quellcode unterwegs bin oder irgendwie Bugs fixen muss oder kleinere Sachen anfassen muss, nutze ich das eigentlich eher so als bessere Refactoring-
Daniel Langemann: Also das, was mit der IDE aktuell nicht geht, so eine Massenumbenennung, alle Stellen finden.
Daniel Langemann: Wenn du zum Beispiel, also bestes Beispiel hatte ich gestern, hat sich der Typ geändert.
Daniel Langemann: Also war eine Verwechslung im Quellcode.
Daniel Langemann: Ich hatte vorher was gebaut, die Klassenname war gleich, aber das eine war ein Model aus einem Bundle und ich sollte das Model, also die Entity aus einem anderen Bundle benutzen.
Kai Ole Hartwig: Ja.
Daniel Langemann: keine Ahnung, 40 Verwendungen oder so, der KI gesagt, guck mal, da möchte ich das ändern, pass mal alle Stellen an.
Daniel Langemann: So diese Fleißarbeit.
Daniel Langemann: Super, das war keine drei Minuten, blub, blub, blub, lief das Ding durch, fertig.
Daniel Langemann: Dann Testfälle dafür geschrieben, für sowas nutze ich KI gerne, weil die natürlich dann schneller ist als ich.
Daniel Langemann: Oder wenn ich dann sage, guck mal, ich würde das jetzt gerne umbauen, wie oft wird das verwendet, was muss da noch passieren?
Daniel Langemann: So, um
Daniel Langemann: mir diese Recherche im Quelltext einfach zu ersparen, aber... Hm.
Kai Ole Hartwig: Ja, das ist nämlich auch das, was ich dann vorher gemacht habe.
Kai Ole Hartwig: Das habe ich aber gemacht, als ich quasi schon als Co-Pilot rausgekommen bin.
Kai Ole Hartwig: Und ich glaube, das ist, also bei mir war es zumindest so eine Entwicklung, dass ich auch entdecken musste, erforschen musste, wie
Kai Ole Hartwig: wie kann ich das sinnvoll für mich einsetzen, dass ich mich halt nicht ärgere über das, was da rauskommt und das dann halt machen und dadurch ist halt diese, für mich auch vorher komplett andere Arbeitsweise entstanden.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Also das ist halt, keine Ahnung, also ich hoffe, dass das jetzt wirklich so ein Ding ist, dass das produktiv ist, dass es gut funktioniert, dass es auch weiter funktionieren wird.
Kai Ole Hartwig: Und vielleicht kommt nachher auch noch mehr Autonomie dabei raus.
Kai Ole Hartwig: Aber so schaffe ich es halt auch einfach, dass ich sechs, acht Agenten dann quasi zum Primären da laufen haben lassen kann, weil ich mich natürlich dann immer nur mit Spezifikation und Testen beschäftige und halt Feedback geben an der Stelle auch.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Und
Kai Ole Hartwig: Und halt sehr autonom die Systeme laufen lassen kann bei einer für mich akzeptablen Qualität.
Kai Ole Hartwig: Wenn die Qualität natürlich nicht passt, deswegen sage ich ja, Review ist so unglaublich wichtig.
Kai Ole Hartwig: dann muss man da halt anders ran.
Kai Ole Hartwig: Manchmal habe ich auch Tage, wo das halt nicht gut funktioniert.
Kai Ole Hartwig: Nur weil, also der Großteil der Zeit funktioniert es, es gibt aber auch genauso Sachen, wo es dann nicht funktioniert, wenn eine neue Model-Version da ist, dann muss man immer, also finde ich, muss man experimentieren, was klappt dann jetzt wie wieder richtig.
Daniel Langemann: Hmm.
Daniel Langemann: Hmm.
Kai Ole Hartwig: Beim letzten Update von Cloud Code von 4.6 auf 4.7,
Kai Ole Hartwig: musste die Sprache auf einmal viel spezifischer sein.
Kai Ole Hartwig: So, dann musst du natürlich Dinge anpassen.
Kai Ole Hartwig: Dann musste ich Sachen anpassen.
Kai Ole Hartwig: Ich glaube, das hast du dann nicht so sehr, weil du es halt einfach anders einsetzt.
Kai Ole Hartwig: Du nutzt halt quasi die KI als Ad-Hoc-Assistent und ich nutze die KI als Junior-Dev.
Daniel Langemann: Ja, also der nachts nicht schlafen darf.
Kai Ole Hartwig: Ja, oder Outsourcing nach Indien.
Daniel Langemann: interessant.
Kai Ole Hartwig: So.
Kai Ole Hartwig: Es ist reißig gut.
Daniel Langemann: Also ich habe halt mein Problem, mich noch komplett abhängig zu machen.
Daniel Langemann: Also die ganzen Sachen, die ich aktuell noch mit KI mache, könnte ich selber, aber nicht so schnell.
Daniel Langemann: Also weil Fakt ist, die kann schneller tippen als ich oder schneller Code produzieren als ich.
Daniel Langemann: Mir fehlt aber die Tiefe.
Daniel Langemann: Also bei deinem Ansatz würde mir zum Beispiel die Tiefe von dem Quelltext verstehen, dass wenn ich morgens aufstehe oder übermorgen mich jemand fragt, etwas dazu, dass ich sagen könnte,
Daniel Langemann: Also zum Beispiel würde dann kommen und sagen, ach mein Gott, wir haben noch etwas vergessen, kannst du noch was hinzubauen oder ist das noch einfach möglich, ist die Änderung noch einfach möglich, wir haben das falsch spezifiziert.
Daniel Langemann: Das wäre immer so im Projektkontext, das heißt so, ah, guck mal, da muss ein neues Payment hinzugefügen, ein neuer Step dazwischen oder so.
Kai Ole Hartwig: Ja.
Daniel Langemann: Und wenn ich da nicht tief genug drin bin, also ich muss nicht jede Zahl selber oder Buchstaben selber getippt haben, aber Quelltext-technisch muss ich tief genug oder möchte ich tief genug drin sein, dass ich sagen kann, klar, kein Problem.
Daniel Langemann: Das ist die und die Abstraktion, da gibt es irgendwo einen Event-Listener oder Event-Subscriber oder das ist ein anderes Pattern, da kann ich noch eine Klasse ganz einfach reinmachen, fertig.
Kai Ole Hartwig: Ja, bei so Sachen wiederum spezifiziere ich halt.
Kai Ole Hartwig: Das meine ich mit Architektur.
Kai Ole Hartwig: Ja, das so wichtige Dinge gebe ich ihm quasi mit.
Kai Ole Hartwig: Also ich mache mir Gedanken dazu, wie soll es denn aussehen?
Kai Ole Hartwig: Nicht im Detail, aber im Großen und Ganzen.
Kai Ole Hartwig: Ja.
Daniel Langemann: Das kann ich nicht.
Daniel Langemann: Deswegen mein Test-Driven-Development-Beispiel.
Daniel Langemann: Ich kann das nicht.
Daniel Langemann: Mir fehlt das so vom Inneren.
Daniel Langemann: Ich kann das nur, wenn ich einen Quelltext vor mir habe oder so, mich durchgearbeitet habe, dann kann ich so vom Inneren Auge den Bauplan aufklappen und sagen, guck mal, so sieht die Welt aus.
Daniel Langemann: Je mehr ich dann rumgucke, umso größer wird die Map.
Daniel Langemann: Plus jede Unterbrechung zerstört sie natürlich wieder.
Kai Ole Hartwig: Ja.
Daniel Langemann: Das schöne Bild dazu, aber
Daniel Langemann: Und dann kann ich vom inneren Auge sagen, okay, guck mal, so funktioniert das.
Daniel Langemann: Oder beziehungsweise, wenn ich lang genug drauf geguckt habe, auch zwei, drei Tage später wieder abrufen.
Daniel Langemann: Da bin ich tief genug im Quelltext drin.
Daniel Langemann: Und das fehlt mir jetzt zum Beispiel an vielen Ansätzen, die ich hatte.
Daniel Langemann: Also von Vibe-Coding bis anderen, wo ich nicht tief genug drin bin, wo du nachher sagst so, keine Ahnung, hat sich was geändert?
Daniel Langemann: Kann ich das umbauen?
Daniel Langemann: Weiß ich nicht.
Daniel Langemann: Und dann guckst du in den Quelltext rein, erarbeitest du das und sagst,
Daniel Langemann: Alter Schwede, so hätte ich das nie gebaut.
Daniel Langemann: Oder ich hätte das aufgeräumt.
Kai Ole Hartwig: Ja, verstehe ich total.
Daniel Langemann: Wenn ich reingeguckt hätte, hätte ich zum Beispiel eine andere Stelle gesehen, wo ich gesagt hätte, das beeinflusst das, das wird problematisch.
Kai Ole Hartwig: Ich habe das auch erst gelernt, als ich mich mehr mit Clean Code, Clean Architecture und so beschäftigte.
Kai Ole Hartwig: beschäftigt habe, ja, so lange nachdem ich studiert habe, den ganzen Spaß, sich mal so mit diesen Qualitätssachen zu beschäftigen.
Kai Ole Hartwig: Und das hat erst dazu geführt, dass ich überhaupt mir neben Patterns, dass ich die mal in so einem Gesamtkontext Architektur wahrgenommen habe und gesehen habe.
Kai Ole Hartwig: Und, ähm,
Kai Ole Hartwig: kennen.
Daniel Langemann: Vor und nach alle zu kennen, ja, ja.
Kai Ole Hartwig: Aber vielleicht auch, also so das Wissen dazu zu haben, es gibt das und das wäre jetzt eine gute Idee.
Kai Ole Hartwig: Und zwar rein aus, ich sag jetzt mal, aus der akademischen Richtung, ja, nicht aus dem, ich hab das programmiert und ich hab das da gesehen und jetzt verwende ich das mal, sondern rein auf diesem akademischen Level.
Kai Ole Hartwig: Das hat mir das alles eröffnet und ermöglicht.
Daniel Langemann: Ja.
Daniel Langemann: Ja, also.
Kai Ole Hartwig: Ich muss ja auch, dazu gehört einfach auch sagen, ich hab halt mir selber Programmieren beigebracht mit 16, ne?
Daniel Langemann: Früher.
Kai Ole Hartwig: So, mit 16 war damals verdammt früh, weil da hat man den ersten, also da hatten wir überhaupt gar keinen Computer.
Kai Ole Hartwig: Ähm,
Kai Ole Hartwig: Dafür jetzt den Kontext für die ganzen jüngeren Menschen unter uns.
Kai Ole Hartwig: Das Internet war damals auch nicht so schnell.
Kai Ole Hartwig: Das war auch zeitlich befristet.
Kai Ole Hartwig: Da konnte dann auch keiner telefonieren, wenn man im Internet war.
Kai Ole Hartwig: Über diese grauen Uhrzeiten reden wir, bevor es Google gab.
Daniel Langemann: Also nochmal zu dem Design-Pattern-Thema zurück und dem ganzen Clean-Code.
Daniel Langemann: Also das hat ja auch einen Sinn und Zweck, das Ganze.
Daniel Langemann: Das ist ja nicht nur mit, sagen wir mal, wer hat den Größten und wer kann da mehr Abstraktion irgendwo unterbringen, sondern, sagen wir mal, das konkrete Beispiel wäre jetzt, habe ich letztens wieder ein Projekt gehabt,
Daniel Langemann: muss ein Update gemacht werden und da ist halt zum Beispiel von Doctrine im kompletten Projekt Abhängigkeiten drin.
Daniel Langemann: Doctrine muss aber aktualisiert werden, heißt, du hast da mehrere tausend Dateien, wo du dann irgendwie gucken musst, dass Parameter passen.
Kai Ole Hartwig: Ja.
Daniel Langemann: Hätte man jetzt ein Pattern benutzt und diese Abhängigkeit auf eine Klasse reduziert und zwar diese Klasse dann aber überall verwendet,
Daniel Langemann: müsste ich nur die eine Stelle mit Doctrine anpassen und da die Parameter ändern und der Rest müsste ich nicht anfassen, weil das eigener Code ist.
Daniel Langemann: Dadurch, dass sich Doctrine ändert, muss ich alle Methoden anfassen und auch jede Stelle angucken, beurteilen, verändert sich was und daher kommt unser Entwicklerbedürfnis zu sagen, wir benutzen einen Pattern, um solche Fehler einfach in Zukunft nicht zu machen oder haben sie schon so oft gemacht und wollen es nicht nochmal machen.
Daniel Langemann: Also
Kai Ole Hartwig: Ja, absolut.
Kai Ole Hartwig: Definitiv.
Daniel Langemann: Das ist mir ganz wichtig, weil viele tun ja so Entwickler und Pattern und die über sowas reden, hört sich immer esoterisch an, aber das hat ja Hand und Fuß.
Kai Ole Hartwig: Ja, auch saubere Architektur und diese ganzen Sachen sind ja entstanden, um bessere Software zu schreiben.
Kai Ole Hartwig: Und gute Software bedeutet ja auch, sie ist wartbar, updatebar und so weiter und so fort.
Daniel Langemann: Es geht um Kohle.
Daniel Langemann: Es geht immer um Kohle.
Daniel Langemann: Je schneller ich Features rausbringen kann, umso günstiger bin ich ja als Entwickler, weil ich nicht drei Wochen oder eine Woche brauche.
Kai Ole Hartwig: Genau.
Kai Ole Hartwig: Ja, und jetzt hat halt, und das merke ich auch sehr stark, also viele schreiben ja irgendwie, ich habe meine Token schon wieder verballert und ich sehe das, ich verballere unfassbar viele Token in, wenn ich in Projekte reinkomme oder übernehme oder Review oder was auch immer, die
Kai Ole Hartwig: eben diesen Prinzipien nicht folgen, die Clean Code, Clean Architecture und so aufgestellt haben.
Kai Ole Hartwig: Also das, weil, und jetzt kommt es ja, der Witz darin, die haben nämlich immer viel, viel mehr Code produziert, als die, die mit sauberen Patterns gearbeitet haben.
Daniel Langemann: Ja.
Daniel Langemann: Mhm.
Kai Ole Hartwig: Ja, wenn man mit sauberen Patterns und sauberer Architektur durch die Gegend rennt,
Kai Ole Hartwig: ähm, hat man nämlich auch viel weniger Zeugs rumfliegen, was man sich anschauen muss, was man programmieren muss, was dann wieder weniger Token verbraucht.
Kai Ole Hartwig: Also bedeutet, ähm,
Kai Ole Hartwig: In dem Gesamtding, erstmal brauchst du für schlechte Software ein größeres Kontext, das verbraucht mehr Token.
Kai Ole Hartwig: Dann brauchst du zum Warten und Erweitern und Aufräumen mehr Token, als wenn du die sauber erstellen lässt oder ein sauberes Projekt hast und weiterentwickelst.
Kai Ole Hartwig: Und ja, also ich sag mal, es spricht alles dafür, weiterhin sauber zu arbeiten und der KI mitzugeben, wie, wo, an welcher Stelle das sauber funktioniert.
Kai Ole Hartwig: dann kommt nämlich auch bessere Qualität raus.
Kai Ole Hartwig: Das ist wie beim Menschen.
Kai Ole Hartwig: Wir haben ja auch nicht aus Spaß irgendwie Junior-Entwicklern gesagt, nee, mach das lieber anders und so und so.
Daniel Langemann: Das ist geil.
Kai Ole Hartwig: sondern halt vor dem Hintergrund, dass wir aus Erfahrung wissen, was kann denn alles noch passieren und warum ist es jetzt sinnvoll, hier auch ein Pattern zu verwenden oder Dinge wieder zu verwenden.
Kai Ole Hartwig: Einfach auch zu sagen, wir haben hier das Ding, also ich habe mal im Projekt gearbeitet, da hatten wir einen Microservice, der nur Produktpreise gerendert hat.
Daniel Langemann: Mhm.
Kai Ole Hartwig: klingt total banal an der stelle und irgendwie sinnfrei wenn man aber weiß dass ein content commerce projekt war mit typo 3 und und ich bin mir nicht mehr sicher mit einem shop system system hat anderes anderes team gemacht und wir an allen stellen
Kai Ole Hartwig: unter sehr komplexen Bedingungen.
Kai Ole Hartwig: Zehn Varianten vom Preis gab es unter je nach Mondphase, Sonnenstand,
Daniel Langemann: Ja.
Kai Ole Hartwig: Keine Ahnung, 1000 Kriterien geführt.
Kai Ole Hartwig: Also gab es einen zentralen Service, den jeder angesprochen hat, um den richtigen Produktpreis für das Ding zu bekommen.
Kai Ole Hartwig: Da hast du eine SKU reingeschmissen, den Preis zurückbekommen.
Kai Ole Hartwig: Konntest dann anzeigen, hast auch den Streichpreis gehabt und konntest halt einfach dieses Snippet, was zurückgekommen ist, einbauen.
Kai Ole Hartwig: Super Ding, weil du wusstest, wenn das Ding richtig funktioniert, dann ist mein Ding auch richtig.
Kai Ole Hartwig: Ich muss mich damit nicht mehr beschäftigen.
Kai Ole Hartwig: Das musst du natürlich wissen, wenn du in so einem Kontext unterwegs bist, dass du jetzt halt nicht selber VK0 und so weiter abrufst und selber anzeigst, sondern dass du den Service ansprichst, ja.
Kai Ole Hartwig: Und genauso wie das halt ein neuer Entwickler lernen muss, musst du das der KI auch mitgeben.
Daniel Langemann: Das ist ein gutes Beispiel, dass einfach nicht fünf Projekte die gleiche Logik.
Kai Ole Hartwig: Ja.
Daniel Langemann: Es müssten nicht fünf Projekte oder fünf Stellen die gleiche Logik einbauen, sondern die wird zentral an einer Stelle eingebaut und wenn eine Änderung kommt, müssen auch nicht fünf Teams das gleich ziehen oder nicht jeder kommt auf einen anderen Wert, weil er anders rundet oder so.
Kai Ole Hartwig: Ja, so und nachher geht es ja auch dazu, dann in die Bezahlprozesse rein und wenn du dann, da kommt ja noch mehr, wenn dann die Validierung fehlschlägt, weil der eine Preis kam aus dem System, der andere Preis von dem, dann ist das in den Bahnkorb gelandet und nachher kommt was komplett anderes raus.
Daniel Langemann: Ja, sehr lustig.
Kai Ole Hartwig: Da können wir eine neue Folge zu machen, aber vielleicht nicht nächste Woche.
Daniel Langemann: Ja, aber das zeigt dieses Grundbedürfnis, was Entwickler ja haben von Abstraktion und Kapselung von Logik und so diesen ganzen Themen, von denen wir immer reden, dass sie halt nicht einfach daraus entstehen, dass wir gerne einen Schleif hinunter bauen wollen.
Daniel Langemann: Und das ist halt das, was im Kontext von Vibe-Coding ja immer hört.
Kai Ole Hartwig: Ja.
Daniel Langemann: mit, ja man muss ja kein Schleifchen drumherum bauen, das ist doch schnell genug und reicht doch aus.
Daniel Langemann: Also für deine fünf Seiten Landingpage, natürlich werde ich da nicht overengineeren und solche Sachen machen.
Daniel Langemann: Also wir reden gerade über Sachen, die eher so mit Preisen zu tun haben, Online-Shops, Sachen, die einfach die nächsten fünf Jahre noch laufen sollen, weil dein Geschäfts- oder dein Business-Case darauf beruht und du damit Geld verdienst.
Daniel Langemann: Oder ein ERP-System, was dann einfach nicht mehr läuft und keine Rechnung gestellt werden können.
Daniel Langemann: Das sind so Sachen, die tun ein bisschen mehr weh.
Daniel Langemann: Und natürlich, also eine Landingpage oder auch dein Blog ist ärgerlich, SEO-technisch auch wichtig, tut aber anders weh, als wenn einfach ein Online-Shop offline ist oder andere Sachen.
Daniel Langemann: Und da ist ein ganz...
Kai Ole Hartwig: Ja.
Kai Ole Hartwig: Fun fact, es reicht, um eine Website zu coden.
Kai Ole Hartwig: Ja, stimmt.
Kai Ole Hartwig: Aber du erkennst heute sehr, sehr gut Vibe-Coding-Websites daran, dass das Impressum
Kai Ole Hartwig: die falschen rechtlichen Bedingungen nennt und die Streitschlichtungsstelle drin hat.
Kai Ole Hartwig: Oder dass du einfach deine Webseite nicht aktualisierst.
Daniel Langemann: Ich wollte es gerade sagen.
Kai Ole Hartwig: Die beiden Möglichkeiten gibt es.
Daniel Langemann: Erwischt.
Daniel Langemann: Hat es auch noch bis letztes Jahr drin.
Kai Ole Hartwig: Entweder Vibe-Coding oder das System ist veraltet.
Daniel Langemann: Hm.
Kai Ole Hartwig: Und was natürlich beim Vibe-Coding total häufig vorkommt bei Websites, ist, dass die ganzen Sachen aus externen Quellen geladen werden.
Kai Ole Hartwig: Na, dann hast du nämlich schön direkt Datenschutzthema, weil deine Website einfach so Google Maps lädt ohne Einwilligung, die Fonts von Google Fonts weiterbezieht direkt ohne Einwilligung und den ganzen anderen Kladdergalat, den man da so netterweise hat.
Kai Ole Hartwig: Ja, ach, so.
Kai Ole Hartwig: Also das heißt auch da, man muss halt darauf achten,
Kai Ole Hartwig: dass das Ganze auch nachher rechtlich sauber ist, was man da rausschmeißt.
Daniel Langemann: Tito.
Kai Ole Hartwig: Also ja, man kann ein total nettes Design, ähm, Vibekon, mache ich auch, ja, gar kein Ding.
Kai Ole Hartwig: Ähm, aber du musst es halt nachher reviewen.
Kai Ole Hartwig: Ja.
Daniel Langemann: Ja, definitiv.
Daniel Langemann: Und es gibt je nach Projekt unterschiedliche Qualitätslevel einfach, die man umsetzt.
Daniel Langemann: Also für meine Seite zum Beispiel bin ich ja auch nicht so, dass ich da alles komplett reduziert habe und da irgendwie so viel Mühe mir gebe, sage so mit Einrückungen und solche Sachen, das habe ich früher alles mal gemacht, das ist vorbei.
Daniel Langemann: Also, wenn du aber andere Projekte hast, da gibt man sich ein bisschen mehr Mühe, weil man genau gesehen hat, was passiert, wenn man in den Shop einen Tag lang offline ist.
Daniel Langemann: Da geht es nicht um 5 Euro.
Daniel Langemann: Also, für mich als Externen wird es teuer, für den Kunden wird es teuer.
Kai Ole Hartwig: Ja, definitiv.
Daniel Langemann: Das sind halt ganz andere Anforderungen.
Kai Ole Hartwig: Ich glaube, das ist auch ein gutes Schlusswort für diese hervorragende Folge Secrets Not Included zu Agentik Engineering und anderen Themen.
Daniel Langemann: Oh ja, ich sehe gerade, wir haben es geschafft.
Daniel Langemann: 53 Minuten.
Daniel Langemann: Ciao.
Kai Ole Hartwig: So, jetzt kein Teaser für nächste Woche.
Kai Ole Hartwig: Da müssen wir dann nochmal in die Büt steigen, glaube ich.
Kai Ole Hartwig: Und dann sehen wir uns trotzdem nächste Woche mit einer neuen Folge.
Kai Ole Hartwig: Macht's gut.
Kai Ole Hartwig: Ciao, ciao.
