Secrets Not Included: Agentic Engineering statt Vibe Coding: Warum KI gute Entwickler nicht ersetzt

Willkommen zurück zu einer hervorragenden, fantastischen neuen Folge Secrets Not Included mit Daniel und Ole. Und letzte Woche haben wir euch angekündigt, wir wollen ein bisschen nochmal über Agentic Engineering sprechen.

Ja, jetzt hatten wir fünf Minuten Zeit, uns vorzubereiten. Stimmt, tut mir leid. Nee.

Daniel, seit wann bereitest du dich vor? Ich finde, das ist unprofessionell. Also, du kannst jetzt nicht behaupten, du würdest dich vorbereiten zu einem Podcast oder vorbereitet in Meetings gehen. Nachher können, also, nee, nee, bitte. Nachher weißt du noch etwas und kannst noch etwas, das würde jetzt alle Menschen davon abhalten, nichts zu wissen.

Wollen ihr nicht übertreiben, ja? Ja, soll ja Spaß machen.

Ja, genau, also nicht overperformen hier, vor allem nicht im Podcast, bitte. Ja, es geht ja nicht, dass wir irgendwas wissen können oder sonst irgendetwas. Deswegen lassen wir ja eigentlich auch Vibe-Coding-mäßig die KI alles programmieren. Ja, und chillen hier halt und machen nur nette Podcasts und ansonsten trinken wir den ganzen Tag über Kaffee oder Tee oder beides.

Das mache ich ohne Podcast doch auch. Also ich verstehe den Unterschied nicht. Sehr gut. Also. Mit Bierchen. Zu streamen.

Sorry. Der Unterschied ist, dass wir im Podcast halt miteinander quatschen und dabei trinken. Alkoholfreie Getränke. Vielleicht sollten wir mal so eine Abendsession machen. Das müssten wir aber als Live-Podcast machen. Das wäre auch noch eine Idee. Ja.

Bin dabei.

Ich weiß noch nicht, ob das... Mal schauen, mal schauen.

Ja.

Also, falls ihr das haben wollt, dann müsstet ihr mal kommentieren. Wo auch immer ihr kommentiert, bei Instagram oder Spotify oder Apple Podcast. Wir werden das dann drei Wochen später oder so lesen und zur Kenntnis nehmen. Ja, Agentic Engineering wollten wir eigentlich drüber quatschen. Ähm, ja. So, was gibt's da zu sagen, Daniel? Ach, die ich dir geben müsste, okay. Hast du mir letzte Woche nicht zugehört?

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. Also ich bin ehrlich, was?

Genau. Okay. 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. Du sagst, der KI, bau mir das neue Slack für meine Company.

Ja, genau. Ja, dann kannst du ein Scheren.

mach das ohne Fehler. Ja? Der Hype für, also der Trick für alle Hype-Performer immer hinten, mach keine Fehler und mach eine Million-Dollar-Company raus. Ähm... 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. Und Agentic Engineering ist die Weiterentwicklung der Softwareentwicklung, des Programmierens oder des Entwicklens. Ich finde, Programmieren haben wir lange schon nicht mehr gemacht, weil Programmieren war dieses, jemand produziert einfach Code runter, so Code-Monkey-mäßig.

Ja.

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. Ja, vom Problem angefangen zur Software zu fertigen und Agentic Engineering ist jetzt im Prinzip, Du hast jemand, der kann Software entwickeln, der versteht die Prinzipien, der könnte selber programmieren, wenn er Lust dazu hat. Und geht jetzt hin und arbeitet mit Methoden wie Spectrum Development, über das wir auch schon gesprochen haben, mit der KI zusammen. In einer Form, dass die KI spezifizierte Aufgaben bekommt, die dann auch wieder überprüft werden, ob sie denn entsprechend ausgeführt wurden.

Also eher zum Code generieren und zum Sparring vorher so ein bisschen, das Back-Driven.

Genau, die... Ja, genau, also du hast einen KI-gestützten Entwicklungsprozess. Und hast selber aber die Fähigkeiten, auch das selber tun zu können, um halt das vollständig zu beurteilen. 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.

Oh ja, ich brüll gleich Bingo.

Ähm.

Hast du so oder so? Also du haftest ja auch als Unternehmer für das, was du produzierst. Aber anderes Thema.

Anderes Thema. Nicht schon wieder so ein juristisches Ausschweife hier heute, bitte.

Okay.

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. Ja, so wie früher in der Softwareentwicklung, du bist verantwortlich für den Shit, der da rauskommt. aber du hast einen KI-geschützten Prozess. Der unterstützt dich halt vielleicht schon bei dem Weg der Spezifikation. 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.

Mhm.

Ja, deswegen der Job des Programmierers, der einfach nur Code schreibt, wenn der nicht schon vor zehn Jahren tot war, jetzt ist er tot. Aus meiner Sicht. Weil das kann die KI halt tatsächlich einfach schneller. Und die hat das halt mittlerweile ja so viele Trainingsdaten gehabt, dass die Qualität halt auch in Ordnung ist. Man muss das reviewen, man muss da Leitplanken einbauen mit den Spezifikationen, was Sicherheit, was Architektur etc. angeht. Das muss man auch reviewen, aber manchmal vergisst die Dinge.

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

Ja. Ja. Ja.

Also ein anderes Beispiel ist so, gerade wenn es Präsentationen gibt, hast du dieses leere Blattproblem. Also ich bin ganz schlecht darin, mich hinzusetzen und zu sagen, ich mache eine Präsentation. Also kann ich sagen, KI, mach mal. Sie rotzt da was hin. Ich gucke an und sage, das ist okay, aber das gefällt mir nicht, das gefällt mir nicht, das gefällt mir nicht. Und dann kann ich anfangen umzubauen und bin schnell. 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.

Hm. Hm.

Da sage ich der KI, mach mal. Mit Spec-Driven Development fange ich an, Sachen runter zu spezifizieren. Früher habe ich Tickets runtergeschrieben im Team. Wenn ich alleine war, habe ich trotzdem ähnlich irgendwie versucht, mich erstmal vorher zu sortieren. 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. Das gleiche ist jetzt mit Spectrum Development auch nur im Ping-Pong mit der KI erstmal. Also...

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.

Mhm.

Verrückt, ne? Also gibt es eine Untersuchung zu und das ist auch völlig, also man kann das nicht so genau eingrenzen, wann das passieren wird. Ja, meine 7 versuchen mal 8, mal 20, so. Also, das passiert. 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. Ja, auch das, dazu gibt es Studien, die halt auch sagen, okay, 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. Einfach random, zwischendrin. Das passiert einfach.

Mhm. Mhm.

Und aus meiner Erfahrung mit dem Umgang heißt, wo jeder neuen Aufgabe das Kontextwindow zu lernen hilft, abarbeitet. Dann, Dann, was hatte ich gesagt? Feature-Branch, kleiner Kontext. Also selbst, dass das Kontext-Windows jetzt zum Beispiel bei Cloud Code eine Million ist, ja, ist total schön. macht es schlimmer. Also früher mal ein Clear oder Compress oder so, ist total sinnvoll, um die Qualität zu steigern.

Ja.

So, und dann halt wirklich den Shit kontrollieren. Du kommst nicht um eine Code Review rum. Und da halt mittlerweile auch bei mir der Fokus ganz krass darauf, ist nur das geändert worden, was ich erwarten würde. Also an Dateien, 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?

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

Was Syntax und so weiter. Hm.

vorne länger gebraucht hätte, brauche ich mindestens doppelt hinten beim Reviewen. 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. Ja, natürlich, im ersten Moment, weil ich auch Tests schreiben muss, aber hinten raus viel weniger Fehler habe und dadurch Zeit spare.

Mhm.

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

Ja, genau. Und das ist halt das, was dann nachher auch das Vibe-Coding und das Agentic Engineering unterscheidet.

Mhm.

Dass du halt schaust, die KI so zu steuern mit deinen Specs auch, dass diese Dinge halt nicht passieren.

Der macht keine Fehler am Ende.

Dass man halt

Genau. Mhm.

No new bugs, please. Genau. So, und das ist halt eine Disziplin, ja. 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. 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 benötigst du normalerweise mindestens die gleiche Zeit wie für das Programmieren.

Ja, mindestens. Es könnte Projekte geben, wo es jetzt noch nicht gute Spezifikationen gibt.

So, und jetzt sehen wir halt, das verschiebt sich so krass, das Programmieren geht jetzt auf einmal viel schneller.

So.

Wir schreiben jetzt aber viel bessere Spezifikationen auf einmal. Also vielleicht wäre früher Programmieren auch schneller gegangen, wenn die Spezifikationen besser gewesen wären. 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.

Was? Haben die extra Fehler gemacht? Ja, ja, genau. Ich habe die... Ja, genau.

Entwickler haben ja früher auch nicht fehlerfreie Sachen geschrieben. Also so. Habe ich gehört. Ich habe natürlich immer bugfrei geliefert. Das waren immer andere. Nie bei GitBlame bin ich, habe ich mich erst eine halbe Stunde aufgeregt, dann das GitBlame gemacht, um festzustellen, der Ole...

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. Der Freund hat den Monitor geteilt.

Was ist das denn für scheiß Code hier?

Richtig abgelästert so. Oh Mann, ich habe euch so oft gesagt, das ist der letzte Scheiß.

So hätte ich das ja niemals geschrieben.

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

Ey, natürlich hochprofessioneller Code. Das ist die einzige akzeptable Lösung. Vergiss, was ich bisher gesagt habe.

Ja, es hatte bestimmt einen Grund, als ich das gebaut habe. Ja, natürlich haben wir auch Fehler gemacht damals oder immer. Ich baue jetzt immer noch den perfekten Code, also

Ja, ja, immer noch. Also das ist so. Da hat ja auch KI einfach nichts dran verändert, dass halt Fehler passieren und Fehler in den Codes drin sind. Ähm,

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. Wenn ein Mensch Quelltext schreibt oder ein guter Entwickler zum Beispiel, 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.

Mhm.

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 Der liest, also macht irgendwelche Sachen, wenn das eintritt, dann kommen drei Fehlerbehandlungen. Wenn das eintritt, dann kommen da noch ein paar Fehlerbehandlungen. 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.

Ab. Ab.

So wächst der Code dann. 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 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, 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.

Definitiv, definitiv. Also ich bin ja auch nicht der von Anfang an der größte Fan. Also ich glaube, wir haben sehr früh damit gestartet und ich war da auch sehr euphorisch. Und ich sage jetzt mal, ich lerne aus Schmerzen so ein bisschen. Also für dein Bettproblem habe ich eine pragmatische Lösung Hochbett. dann siehst du das.

Da passt mehr drunter. Hm. Hm. Hm.

Und für die KI habe ich, ja, da passt auch mehr drunter, definitiv. Aber du siehst es auch leichter. Du musst dich nicht selber so. Und naja, die KI muss durch die gleichen Quality Gates wie der menschliche Entwickler. PHP-Stand, Clean Code. Und was ich halt einfach mache, was heißt einfach, aber was wir mittlerweile machen, oder was ich eingeführt habe, ist, natürlich muss der auch PHP-Stand etc. bestehen. So, aber wir haben halt auch einfach ein Skill, Clean Code, ja, nach, ja, Bob, wie heißt er denn? Naja, steht hier bestimmt, da steht es irgendwo, ne, seht ihr jetzt nicht.

Nicht, nee.

Clean Code, Clean Architecture, nach den Prinzipien, die Review macht, und dann hast du halt einfach das Ding, dass du natürlich nicht die Schwierigkeiten hast, dass dein Code nicht diesen Prinzipien entspricht. 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.

Schnell da.

Und es halt grundsätzlich per Pistain ausgeführt wird und dann halt zurückkommt mit, hey, ähm, das passt aber hier nicht, das PRP-Stan-Level wird nicht geschafft. 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. 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,

Mhm.

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. Also du musst ihn halt wirklich da reinlenken, gerade auch, ich finde, in PHP ist es zum Beispiel schlimmer als in Go, ähm, dass wirklich sauber gearbeitet wird. 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.

Ja, bestimmt sogar. 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. PHP lange Zeit eine Einstiegssprache war. Jetzt hat das Glück JavaScript geerbt. Das senkt natürlich das Level. Also, es ist noch nicht mal schlecht gemeint. Also, es kommen halt viele neue, die probieren sich aus.

Und viele Open-Source-PAP-Projekte haben auch hervorragende Code-Qualität seit Jahren. Also es ist ja eher so der, ich sag mal, der Wildwuchs, die Noise quasi, die außenrum so auf GitHub rumliegt und so. 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.

Aber nochmal zurückzukommen auf das Thema, gerade so Clean Architecture und das ganze Thema. Ich 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. Also du kannst

Hm? Hm?

stichpunktartig oder kurze Sätze nutzen, um einfach so etwas zu beschreiben. Du kannst es blumig ausdrücken. Die Art und Weise, wie Bücher geschrieben werden, man erkennt sogar die Handschrift von einem Autor. Und so ist es ja bei Quelltext auch. Und so ist es auf der einen Seite schwer, das irgendwie technisch sicherzustellen, dass gewisse Sachen... richtig sind. 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. Du kommst ins nächste Team und die sagen so, ne, das versteht ja keine Sau. Also das kann dir passieren, ohne dass du schlechter oder besser geworden bist. Deswegen finde ich das schwer, festzuhalten, dass die KI, zu sagen, KI mach mal, 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. Oder ich finde den nicht. Oder vielleicht ticke ich auch anders wie der Großteil der Trainingsdaten. Und das ist mein Problem. Mhm.

Ich kenne aber das Gefühl, das du beschreibst. Ich weiß es auch. Es ist halt einfach fremder Code und es ist häufiger nicht so, wie man das erwarten würde. Darum sage ich ja, man muss das quasi mitgeben. Die Specs bei mir enthalten zum Beispiel auch immer die Informationen, sehr technische Informationen zu, wie ich auch die Architektur haben möchte. Wie ich so etwas erwarte. Ich habe so ganz grundsätzlich mal definiert, definiert, wie ich Sachen aufbaue. Also wo zum Beispiel, also sowas auch festgelegt wie die zyklomatische Komplexität. dass ich da fest sage, pass auf, meinetwegen erreiche eine zyklomatische Komplexität von 10, ich möchte aber grundsätzlich unter 3 bleiben. In Ausnahmen kannst du davon abweichen. Und da auch sehr an so Standards... definiert, die es ja allgemein in der PHP-Welt gibt.

Ja.

Und das hat dazu geführt, dass die Qualität für mein Empfinden wesentlich besser geworden ist. Ja, manchmal fehlt da der rote Faden und manchmal hat die KI auch echt dumme Ideen zwischendrin. 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. Und das hatte ich am Anfang auch überhaupt gar nicht. Als wir das erste Mal über Spectrum Development gesprochen haben, 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.

Mhm.

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 Und so halt vorgehen und halt wirklich mit Spezifikationen zu arbeiten, damit im Prinzip je nach sechs, acht Entwicklern hingehen und das einfach abarbeiten. Genauso machen wir das halt zum Beispiel mit Inhalterstellung. Entwürfe und so weiter werden halt, wir arbeiten Pläne aus und diese Pläne werden selbstständig abgearbeitet.

Das habe ich auch schon gehört, dass Leute das können.

Und das war wirklich eine krasse Umgewöhnung, auch was dieses sprachliche Definieren ist. Ich habe immer noch nicht den Zugang gefunden, dass ich sage, ich spreche das rein, ich schreibe das wirklich runter. Aber auch mein gesamter Tagesablauf hat sich geändert. Ich habe ja eigentlich sehr, sehr wenig Zeit immer zum Arbeiten aus äußeren Umständen. Und ich muss sagen, so dieses Vorgehen, Speck-Driven-Development und über Nacht programmieren lassen, hat mir sehr viel Produktivität zurückgegeben.

Ja, krass. Also, ich sehe für mich mein Problem,

Also, wenn du mich fragst, ich bin jetzt garantiert produktiver im Sinne von Features, die gebaut werden, als vor zwei Jahren. Als ich noch Vollzeit, oder vor drei Jahren, als ich Vollzeit arbeiten konnte und halt auch manchmal 60 Stunden in der Woche gemacht habe. Programmieren, ne? Den anderen Shit.

das fing damals schon an mit dem Test-Driven-Development.

Mhm.

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. Und ich weiß es nicht, ich bin nie so tief in dem Thema immer drin gewesen oder mir fehlt anscheinend die Vorstellungskraft oder so. 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, 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. Muss noch irgendwo eine andere Datenquelle geupdatet werden.

Mhm.

Also so erarbeite ich. Und ich sage ja immer so, dieses Test-Driven-Development hat bei mir nicht funktioniert, weil ich muss erstmal die Klötzchen überall hinstellen. 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. Und das kann ich vorher gar nicht und das ist egal, ob bei Test-Driven-Development oder ist auch Speck-Driven. 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. Ich weiß, dass das ein Problem ist.

Das mache ich zum Beispiel im Spec.

Also so High-Level-Sachen, die kann ich alle abfrühstücken. Echt nicht?

Das mache ich zum Beispiel gar nicht. Ich lege gar nicht im Spec-Driven Development, also in meinen Specs, lege ich gar nicht fest, welche Datenbankfelder und so.

Okay. Mhm.

Nee. Ich definiere wirklich Architektur- mit, okay, da erwarte ich, dass das ein eigenes Blah ist und das ist ein eigenes Blub. Und ich lege jetzt aber nicht auf Objektebene fest die Sachen. Weil das weiß das Ding viel, viel besser als ich am Tagesende. 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. Mach nicht bitte für jeden Shit ein neues Datenbankfeld.

Und macht keine Fehler. Sorry.

Ich glaube, das ist so ein bisschen der Unterschied, dass die Kunst ist, spezifisch unspezifisch zu sein. Ähm.

Was wir Entwickler bestimmt sehr gut können, nicht. Ähm.

und es verändert, also warte mal, wie erkläre ich das denn jetzt, was ich denke? Also ich fühle das total mit Test-Driven-Development. Ich habe mich auch immer mega schwer damit getan, vorab Tests zu schreiben. Ich habe das quasi nie gemacht, wenn ich es vermeiden konnte.

Mhm. Mhm. Mhm.

Deswegen ist mein Vorgehen jetzt auch ein bisschen anders. schon. Die Specs sind ja auch Teil-KI generiert. Also ich arbeite ja quasi auf Epic-Ebene und dann vielleicht noch auf Story-Ebene und der Rest ist KI generiert.

Ja.

Und dann... werden die Testfälle geschrieben. Diese Testfälle review ich dann. Und sage, ja, okay, das entspricht dem, was ich erwarte, oder, nee, das muss geändert werden. Und passt die Specs dafür an? So quasi diesen Rückkanal aus. Wenn ich sage, der Testfall für das muss geändert werden, dann passt auch die Specs an. Und dann lasse ich programmieren. Wann auch immer, direkt oder nachts.

Ja, ja.

Wie man das halt so gerade machen möchte, ob man jetzt mehr Autonomie in dem System haben möchte oder nicht. Und was ich auch habe, ist, dass ich quasi Learnings, wenn ich Sachen korrigiere nachträglich, Learnings schreiben lasse, die dann wieder geladen werden, wenn ich neuen Kontext brauche.

Krass. Gut, dann arbeitet es komplett anders.

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,

Ja, ja. Das fängt von den Modellen ab.

rausgefunden habe, wie es für mich gerade am besten funktioniert. Ich weiß nicht, ob das der beste Weg ist. Also kein Plan. Und ob das der richtige Weg ist, ob der in zwei Monaten sich noch genauso gut anfühlt wie jetzt. Vielleicht gibt es dann einen komplett anderen Weg, den ich gehe.

Das fängt von den Modellen und den Fähigkeiten auch ab, glaube ich. Also

Und Ich habe mit Test-Driven-Development die gleichen Schwierigkeiten gehabt. Ich habe auch am Anfang mit Agentic Engineering oder Vibe-Coding einfach keine coolen Ergebnisse gehabt. 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 Lass das komplett selbstständig laufen und das Ergebnis ist da, wenn ich wieder anfange zu arbeiten. Diese Idee, die fand ich einfach so faszinierend.

Ja, ist auch so. Du stehst auf und deine Arbeit ist fertig. Kannst dich wieder hinlegen. Ja, ja.

Ja, nicht, dann schreibst du die nächsten Speziele, dann testest du ja... 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.

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.

Ja. Ja, siehst du, ja.

Also das war so die Faulheit, die mich da definitiv getrieben hat.

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

Ja, oder so. Also das war Ping-Pong. 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. Ich hatte schon Dateien irgendwo liegen, die vielleicht noch eine Klasse enthalten haben, aber ein paar Methoden und die leer waren oder so. Da konnte ich Tests dafür schreiben. Das hat funktioniert. Ich merke jetzt auch für mich, also ich versuche auch mit Spec-Driven Development zu arbeiten, 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.

Mhm.

Man hat sich zusammengesetzt und so gegenseitig hochgeschaukelt. Der andere hat dann immer gesagt, hast du an die Stelle schon gedacht? Nein, habe ich natürlich vergessen. Bedenk das, das ist schon dreimal schiefgegangen. Dann hat man so eine halbe Stunde, Stunde Ping-Pong gespielt, hat Gewissen gehabt und hat das dann abgearbeitet. 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ß. Also das ist so ähnlich für mich, dass ich jetzt halt nur KI gegen Mensch getauscht, äh, Mensch gegen KI getauscht habe.

Ja.

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- Also das, was mit der IDE aktuell nicht geht, so eine Massenumbenennung, alle Stellen finden. Wenn du zum Beispiel, also bestes Beispiel hatte ich gestern, hat sich der Typ geändert. Also war eine Verwechslung im Quellcode. 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.

Ja.

keine Ahnung, 40 Verwendungen oder so, der KI gesagt, guck mal, da möchte ich das ändern, pass mal alle Stellen an. So diese Fleißarbeit. Super, das war keine drei Minuten, blub, blub, blub, lief das Ding durch, fertig. Dann Testfälle dafür geschrieben, für sowas nutze ich KI gerne, weil die natürlich dann schneller ist als ich. Oder wenn ich dann sage, guck mal, ich würde das jetzt gerne umbauen, wie oft wird das verwendet, was muss da noch passieren? So, um mir diese Recherche im Quelltext einfach zu ersparen, aber... Hm.

Ja, das ist nämlich auch das, was ich dann vorher gemacht habe. Das habe ich aber gemacht, als ich quasi schon als Co-Pilot rausgekommen bin. Und ich glaube, das ist, also bei mir war es zumindest so eine Entwicklung, dass ich auch entdecken musste, erforschen musste, wie 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.

Mhm.

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. Und vielleicht kommt nachher auch noch mehr Autonomie dabei raus. 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.

Mhm.

Und Und halt sehr autonom die Systeme laufen lassen kann bei einer für mich akzeptablen Qualität. Wenn die Qualität natürlich nicht passt, deswegen sage ich ja, Review ist so unglaublich wichtig. dann muss man da halt anders ran. Manchmal habe ich auch Tage, wo das halt nicht gut funktioniert. 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.

Hmm. Hmm.

Beim letzten Update von Cloud Code von 4.6 auf 4.7, musste die Sprache auf einmal viel spezifischer sein. So, dann musst du natürlich Dinge anpassen. Dann musste ich Sachen anpassen. Ich glaube, das hast du dann nicht so sehr, weil du es halt einfach anders einsetzt. Du nutzt halt quasi die KI als Ad-Hoc-Assistent und ich nutze die KI als Junior-Dev.

Ja, also der nachts nicht schlafen darf.

Ja, oder Outsourcing nach Indien.

interessant.

So. Es ist reißig gut.

Also ich habe halt mein Problem, mich noch komplett abhängig zu machen. Also die ganzen Sachen, die ich aktuell noch mit KI mache, könnte ich selber, aber nicht so schnell. Also weil Fakt ist, die kann schneller tippen als ich oder schneller Code produzieren als ich. Mir fehlt aber die Tiefe. 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, 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. 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.

Ja.

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

Ja, bei so Sachen wiederum spezifiziere ich halt. Das meine ich mit Architektur. Ja, das so wichtige Dinge gebe ich ihm quasi mit. Also ich mache mir Gedanken dazu, wie soll es denn aussehen? Nicht im Detail, aber im Großen und Ganzen. Ja.

Das kann ich nicht. Deswegen mein Test-Driven-Development-Beispiel. Ich kann das nicht. Mir fehlt das so vom Inneren. 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. Je mehr ich dann rumgucke, umso größer wird die Map. Plus jede Unterbrechung zerstört sie natürlich wieder.

Ja.

Das schöne Bild dazu, aber Und dann kann ich vom inneren Auge sagen, okay, guck mal, so funktioniert das. Oder beziehungsweise, wenn ich lang genug drauf geguckt habe, auch zwei, drei Tage später wieder abrufen. Da bin ich tief genug im Quelltext drin. Und das fehlt mir jetzt zum Beispiel an vielen Ansätzen, die ich hatte. 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? Kann ich das umbauen? Weiß ich nicht. Und dann guckst du in den Quelltext rein, erarbeitest du das und sagst, Alter Schwede, so hätte ich das nie gebaut. Oder ich hätte das aufgeräumt.

Ja, verstehe ich total.

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.

Ich habe das auch erst gelernt, als ich mich mehr mit Clean Code, Clean Architecture und so beschäftigte. beschäftigt habe, ja, so lange nachdem ich studiert habe, den ganzen Spaß, sich mal so mit diesen Qualitätssachen zu beschäftigen. 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. Und, ähm, kennen.

Vor und nach alle zu kennen, ja, ja.

Aber vielleicht auch, also so das Wissen dazu zu haben, es gibt das und das wäre jetzt eine gute Idee. 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. Das hat mir das alles eröffnet und ermöglicht.

Ja. Ja, also.

Ich muss ja auch, dazu gehört einfach auch sagen, ich hab halt mir selber Programmieren beigebracht mit 16, ne?

Früher.

So, mit 16 war damals verdammt früh, weil da hat man den ersten, also da hatten wir überhaupt gar keinen Computer. Ähm, Dafür jetzt den Kontext für die ganzen jüngeren Menschen unter uns. Das Internet war damals auch nicht so schnell. Das war auch zeitlich befristet. Da konnte dann auch keiner telefonieren, wenn man im Internet war. Über diese grauen Uhrzeiten reden wir, bevor es Google gab.

Also nochmal zu dem Design-Pattern-Thema zurück und dem ganzen Clean-Code. Also das hat ja auch einen Sinn und Zweck, das Ganze. 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, muss ein Update gemacht werden und da ist halt zum Beispiel von Doctrine im kompletten Projekt Abhängigkeiten drin. Doctrine muss aber aktualisiert werden, heißt, du hast da mehrere tausend Dateien, wo du dann irgendwie gucken musst, dass Parameter passen.

Ja.

Hätte man jetzt ein Pattern benutzt und diese Abhängigkeit auf eine Klasse reduziert und zwar diese Klasse dann aber überall verwendet, 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. 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. Also

Ja, absolut. Definitiv.

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

Ja, auch saubere Architektur und diese ganzen Sachen sind ja entstanden, um bessere Software zu schreiben. Und gute Software bedeutet ja auch, sie ist wartbar, updatebar und so weiter und so fort.

Es geht um Kohle. Es geht immer um Kohle. Je schneller ich Features rausbringen kann, umso günstiger bin ich ja als Entwickler, weil ich nicht drei Wochen oder eine Woche brauche.

Genau. 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 eben diesen Prinzipien nicht folgen, die Clean Code, Clean Architecture und so aufgestellt haben. 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.

Ja. Mhm.

Ja, wenn man mit sauberen Patterns und sauberer Architektur durch die Gegend rennt, ä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. Also bedeutet, ähm, In dem Gesamtding, erstmal brauchst du für schlechte Software ein größeres Kontext, das verbraucht mehr Token. 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. 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. dann kommt nämlich auch bessere Qualität raus. Das ist wie beim Menschen. Wir haben ja auch nicht aus Spaß irgendwie Junior-Entwicklern gesagt, nee, mach das lieber anders und so und so.

Das ist geil.

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

Mhm.

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 unter sehr komplexen Bedingungen. Zehn Varianten vom Preis gab es unter je nach Mondphase, Sonnenstand,

Ja.

Keine Ahnung, 1000 Kriterien geführt. Also gab es einen zentralen Service, den jeder angesprochen hat, um den richtigen Produktpreis für das Ding zu bekommen. Da hast du eine SKU reingeschmissen, den Preis zurückbekommen. Konntest dann anzeigen, hast auch den Streichpreis gehabt und konntest halt einfach dieses Snippet, was zurückgekommen ist, einbauen. Super Ding, weil du wusstest, wenn das Ding richtig funktioniert, dann ist mein Ding auch richtig. Ich muss mich damit nicht mehr beschäftigen. 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. Und genauso wie das halt ein neuer Entwickler lernen muss, musst du das der KI auch mitgeben.

Das ist ein gutes Beispiel, dass einfach nicht fünf Projekte die gleiche Logik.

Ja.

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.

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.

Ja, sehr lustig.

Da können wir eine neue Folge zu machen, aber vielleicht nicht nächste Woche.

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. Und das ist halt das, was im Kontext von Vibe-Coding ja immer hört.

Ja.

mit, ja man muss ja kein Schleifchen drumherum bauen, das ist doch schnell genug und reicht doch aus. Also für deine fünf Seiten Landingpage, natürlich werde ich da nicht overengineeren und solche Sachen machen. 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. Oder ein ERP-System, was dann einfach nicht mehr läuft und keine Rechnung gestellt werden können. Das sind so Sachen, die tun ein bisschen mehr weh. 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. Und da ist ein ganz...

Ja. Fun fact, es reicht, um eine Website zu coden. Ja, stimmt. Aber du erkennst heute sehr, sehr gut Vibe-Coding-Websites daran, dass das Impressum die falschen rechtlichen Bedingungen nennt und die Streitschlichtungsstelle drin hat. Oder dass du einfach deine Webseite nicht aktualisierst.

Ich wollte es gerade sagen.

Die beiden Möglichkeiten gibt es.

Erwischt. Hat es auch noch bis letztes Jahr drin.

Entweder Vibe-Coding oder das System ist veraltet.

Hm.

Und was natürlich beim Vibe-Coding total häufig vorkommt bei Websites, ist, dass die ganzen Sachen aus externen Quellen geladen werden. 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. Ja, ach, so. Also das heißt auch da, man muss halt darauf achten, dass das Ganze auch nachher rechtlich sauber ist, was man da rausschmeißt.

Tito.

Also ja, man kann ein total nettes Design, ähm, Vibekon, mache ich auch, ja, gar kein Ding. Ähm, aber du musst es halt nachher reviewen. Ja.

Ja, definitiv. Und es gibt je nach Projekt unterschiedliche Qualitätslevel einfach, die man umsetzt. 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. 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. Da geht es nicht um 5 Euro. Also, für mich als Externen wird es teuer, für den Kunden wird es teuer.

Ja, definitiv.

Das sind halt ganz andere Anforderungen.

Ich glaube, das ist auch ein gutes Schlusswort für diese hervorragende Folge Secrets Not Included zu Agentik Engineering und anderen Themen.

Oh ja, ich sehe gerade, wir haben es geschafft. 53 Minuten. Ciao.

So, jetzt kein Teaser für nächste Woche. Da müssen wir dann nochmal in die Büt steigen, glaube ich. Und dann sehen wir uns trotzdem nächste Woche mit einer neuen Folge. Macht's gut. Ciao, ciao.