#116 KI unterstützte Software Entwicklung: Ein Reality Check mit Birgitta Böckeler von Thoughtworks

AI in der Software-Delivery: Unsere größte Möglichkeit oder purer Hype? - Ein Realitätscheck

Generative AI ist in der Software-Entwicklung allgegenwärtig. Mit Co-Pilot stellt GitHub den Platzhirsch im Bereich Codegenerierung und bewirbt es mit einer 55% Produktivitätssteigerung. Bei solchen Effekten dreht jedes C-Level-Management am Rad. Doch was ist dran am Hype? Sollten wir wirklich alle so aufgeregt sein?

Zu dieser Frage bzw. zu einem Realitätscheck sprechen wir mit Birgitta Böckeler, Global Lead for AI-assisted Software Delivery bei Thoughtworks. Sie beschäftigt sich u.a. damit, wozu Generative AI in der Softwareentwicklung genutzt werden kann, welche Einsatzbereiche neben der Codegenerierung existieren, für welche Bereiche Coding Assistenten gut und für welche nicht so gut sind funktionieren aber auch welchen Effekt die ganze AI-Bewegung auf den ganzen Softwareentwicklungsprozess hat.

Bonus: Ein Kampf zwischen AI-Fans und Skeptiker

**** Diese Episode wird gesponsert von der IU Internationale Hochschule

Für dich ist Bildung wichtig und du glaubst an Technologie als Enabler? Kannst du dich mit der Mission der IU “Educate People with the Best Technology" identifizieren?

Dann schau doch mal unter https://engineeringkiosk.dev/iu1, wenn du die Bildung von morgen gestalten willst.

********

Das schnelle Feedback zur Episode:

👍 (top) 👎 (geht so)

Sprungmarken

(00:00:00) Software Delivery und AI mit Birgitta Böckeler

(00:03:09) Die Bildung von morgen gestalten, als Dev bei der IU (Werbung)

(00:04:15) Birgitta Böckeler - Global Lead for AI-assisted Software Delivery

(00:07:17) Was ist Generative AI im Umfeld der Software-Entwicklung?

(00:13:33) Wie viel Erfahrung ist für den sinnvollen Einsatz von Generative AI notwendig?

(00:22:36) Intellectual Property (IP) bei Coding LLMs

(00:27:09) Retrieval Augmented Generation, Halluzinationen und Kontext für das LLM

(00:41:58) Erhöhte Produktivität durch Coding Co-Piloten

(00:55:40) In welchen Bereichen der Software-Entwicklung kann AI uns noch helfen?

(01:02:44) Wie verändert sich die professionelle Softwareentwicklung durch AI?

Hosts

Wolfgang Gassler (https://mastodon.social/@woolf)
Andy Grunwald (https://twitter.com/andygrunwald)

Feedback (gerne auch als Voice Message)

EngKiosk Community: https://engineeringkiosk.dev/join-discord
Email: stehtisch@engineeringkiosk.dev
Mastodon: https://podcasts.social/@engkiosk
Twitter: https://twitter.com/EngKiosk
WhatsApp +49 15678 136776

Transkript

Das Transkript wurde automatisiert per Speech-to-Text erstellt und kann daher Fehler enthalten.

Birgitta Böckeler (00:00:02 - 00:01:13)

Aus meiner Wahrnehmung als Beraterin ist inzwischen IntelliJ oder die JetBrains-Produkte sind ganz klar Marktführer und die kosten Geld, also wenn man die professionell benutzt. Eclipse hat kein Geld gekostet. Das heißt, es gab eine Zeit, wo Leute einfach das Geld nicht ausgeben wollten dafür und einfach nicht geglaubt haben, dass es das wert ist, weil du kannst halt nicht auf dem Papier beweisen, wie viel hast du jetzt gespart, weil deine zehn Entwickler IntelliJ benutzen. Und ähnlich sehe ich das auch bei Copilot, dass es halt eventuell schwierig ist, das zu beweisen. Ich versuche auch immer nicht so die alte Frau zu sein, die auf der Veranda steht und ihre Faust schwingt und sagt, die jungen Leute heute mit Coding Assistance, die lernen gar nicht mehr, wie man richtig programmiert. Und vielleicht ist das einfach jetzt eine andere Art zu lernen, als wir Internetsuche, Google und so weiter bekommen haben. da hat es so einen richtigen kognitiven Shift gegeben. Also von, ich muss Sachen auswendig wissen, zu ich muss nur wissen, wo ich die finde. Und das war so ein kollektiver, kognitiver Shift, wie wir denken. Meine Oma zum Beispiel konnte immer noch Gedichte auswendig und sowas. Das macht ja heute keiner mehr, weil muss man nicht mehr. Also das fand ich einen interessanten Gedanken. Gibt es da jetzt einen kognitiven Shift und ob der gut ist oder schlecht, werden wir vielleicht dann sehen. Und es gibt auf jeden Fall auch Anzeichen, dass es auf der anderen Seite auch sehr helfen kann.

Wolfi Gassler (00:01:17 - 00:02:16)

Mit generativer KI, die in der Softwareentwicklung immer präsenter wird, oder auch mit GitHub Copilot, der eine Produktivitätssteigerung von 55% verspricht, stellen sich wahrscheinlich auch viele die Frage, wie real ist dieses Versprechen eigentlich? Ist diese Begeisterung gerechtfertigt oder sind wir nur wieder mal einem Hype aufgesessen? Wir sprechen mit Birgitta Bröckeler, und jetzt kommt ein schweres Wort, ihre Job Description, Global Lead for AI Assisted Software Delivery bei ThoughtWorks. Und wir sprechen, wie die KI unseren Softwareentwicklungsprozess beeinflusst oder vielleicht auch noch beeinflussen wird. Und natürlich, ob diese versprochene Produktivitätssteigerung überhaupt realistisch ist. Wir sprechen aber auch über die mittlerweile schon als klassisch zu bezeichneten Code Generations, über Retrieval Augmented Generation Ansätze bis hin zu Chatbots, die uns vielleicht in Zukunft Meetings mit Product Ownern einsparen könnten. Also los geht's mit unserem Reality Check zur AI-Assisted Software Delivery.

Andy Grunwald (00:02:20 - 00:02:49)

Ich glaube in der aktuellen Zeit ist das Wort Hype mit dem Thema AI gleichzusetzen und hier im Podcast gibt es so zwei Welten. Zum einen Wolfgang ist super Hyped über das ganze Thema AI, Software Engineering, AI in der Software Engineering oder beziehungsweise AI gestütztes Software Engineering und ich bin so ein bisschen die andere Seite. Vielleicht nicht der Skeptiker, vielleicht irgendwie der Late Adopter, wenn ich in Hype-Cycle-Terms spreche.

Wolfi Gassler (00:02:49 - 00:02:51)

Der Realist wolltest du sagen.

Andy Grunwald (00:02:51 - 00:03:08)

Vielleicht auch der Realist. Auf jeden Fall, was mir so ein bisschen sauer aufstößt ist, da gibt es neues geschnittenes Brot, jeder springt drauf und sagt, das ist die Lösung für alles. Und um diesem Thema mal so ein bisschen, ich sag mal, den Wind aus den Segeln zu nehmen, ein bisschen mehr Realismus in die ganze Sache reinzubringen.

Wolfi Gassler (00:03:09 - 00:04:15)

Hast du vielleicht schon einmal überlegt, wie du deine Coding-Skills am sinnvollsten einsetzen kannst? Zum Beispiel in der Bildungswelt, um hunderttausende Studierende mit deinem Beitrag und den besten technologischen Lösungen weiterzubringen? Unser Episodensponsor DIU ist Deutschlands größte Hochschule und sucht SoftwareentwicklerInnen, um ihr Learning-Angebot weiterzuentwickeln und durch KI und modernste Technik den Markt weiterzurevolutionieren. Wie die IU selbst ist auch der Arbeitsplatz hier flexibel gestaltbar. Wo, wann und wie du arbeitest, obliegt ganz dir selbst. Ob vollständig remote an einem der 35 Standorte in Deutschland oder sogar bis zu sechs Monate im Jahr aus dem Ausland. Hier finden Frühjahrsteher bis zu den Nachteulen alle ihren Platz. Also wenn selbstständiges Arbeiten mit vielen Herausforderungen im EduTech Umfeld für dich interessant klingt, Schau mal unter engineeringkiosk.dev.au vorbei, also auf deutsch geschrieben I.U. Und noch ein kleiner Geheimtipp. Die I.U. sucht nicht nur VollzeitentwicklerInnen, sondern auch Lehrende und freie DozentInnen, die nebenberuflich ihr Wissen weitergeben möchten. Alle Links findest du in den Show Notes. Und damit zurück zur Episode.

Andy Grunwald (00:04:15 - 00:04:23)

Bin ich sehr stolz, dass wir heute dazu eine Expertin eingeladen haben und sie auch die Einladung angenommen hat. Hallo, Birgitta.

Birgitta Böckeler (00:04:24 - 00:04:25)

Hallo Andi, hallo Wolfgang.

Andy Grunwald (00:04:25 - 00:04:38)

Birgitta, lass mich dich bitte ganz kurz vorstellen. Wir haben uns mal vor circa zehn Jahren auf einem Hackathon in Hamburg kennengelernt, beziehungsweise ich habe dich kennengelernt, weil du diesen Hackathon gewonnen hast. Glückwunsch nochmal dazu.

Birgitta Böckeler (00:04:38 - 00:04:39)

Mit meiner ganzen Gruppe, ja.

Andy Grunwald (00:04:40 - 00:05:48)

Natürlich mit einem team und dann bist du auf meinem radar wieder erschienen als du einen talk auf der lead dev konferenz in berlin zum thema ei für softwareentwicklung reality check gemacht hast weil ich auf der suche nach jemandem war okay der da mal ein bisschen realismus reinbringt in dieses ganze thema ei kogenerierung ei für die softwareentwicklung und so weiter. Und dann haben wir dich eingeladen und du hast zum glück auch oder zu unserem glück die einladung angenommen vielen dank nochmal dass du dir die zeit nimmst. Ja gerne. Aber wer bist du denn ich meine du wohnst in berlin du hast ein diplom mit informatik an der berliner hochschule für technik gemacht. Du bist eine regelmäßige Speakerin auf den Bühnen dieser Welt, beziehungsweise auf den Tech-Bühnen dieser Welt, und das auch nicht erst seit zwei Jahren, sondern schon etwas länger. Du bist seit über 18 Jahren im Bereich Softwareentwicklung unterwegs und da primär im Bereich Consulting, beziehungsweise Software-Consulting, warst vorher bei Accenture, bist nun bei ThoughtWorks auch schon ein paar Jahre. Und du hast vor circa acht Monaten eine neue Stelle bei ThoughtWorks angetreten, die ich sehr interessant finde. Und zwar nennt die sich, glaube ich, Global Lead for AI Assistant Software Delivery.

Birgitta Böckeler (00:05:48 - 00:05:54)

Ja genau, ist ziemlich lang aber irgendwie kann man nirgendwo was kürzen, hat alles eine Bedeutung.

Andy Grunwald (00:05:54 - 00:06:05)

Darum geht's heute auch in dieser Podcast Episode und du bloggst ziemlich viel beziehungsweise veröffentlichst auch Memos zu generative AI auf martinfauler.com.

Birgitta Böckeler (00:06:05 - 00:06:05)

Genau.

Andy Grunwald (00:06:05 - 00:06:06)

Habe ich irgendwas vergessen?

Birgitta Böckeler (00:06:06 - 00:06:11)

Das war eigentlich eine ganz gute Zusammenfassung, ja.

Andy Grunwald (00:06:11 - 00:06:25)

Meine erste Frage an dich wäre eigentlich, da du dich jetzt professionell mit dem Thema AI Assisted Delivery beschäftigst, kannst du das Wort AI eigentlich noch hören beziehungsweise ertragen? Weil also mir hängt es gerade so wie jeder Hype von früher irgendwie aus den Ohren raus.

Birgitta Böckeler (00:06:25 - 00:07:12)

Ja, ist eine gute Frage eigentlich, ja. Ich glaube, es gibt auf jeden Fall, wenn man sich intensiv mit dem Thema beschäftigt, gibt es immer Sachen, die einen irgendwann nerven. Aber ich glaube, das Wort AI oder Gen-AI, sagt man ja auch gerade die ganze Zeit, also generative AI, also der spezifische Flavor von AI, der ja gerade groß ist. Ja, das Wort nervt mich eigentlich gar nicht so. Interessant, ja, gute Frage. Aber ich find's auch interessant, dass du gesagt hast, ich mein, du hast eingeführt, dass du eher so der Skeptiker vielleicht bist oder Realist und hast dann gesagt, wir wollen dem Thema den Wind aus den Segeln nehmen. Aber was ich natürlich auch erreichen möchte, ist, ich möchte dich ein bisschen mehr positiv stimmen. Also, es liegt irgendwo in der Mitte. Ich bin auch eher skeptisch an das Thema rangegangen, aber es liegt irgendwo in der Mitte. Mal sehen, ob ich das schaffe.

Andy Grunwald (00:07:12 - 00:07:15)

Werd ich dir am Ende des Podcasts auf jeden Fall das Ergebnis nennen.

Birgitta Böckeler (00:07:16 - 00:07:16)

Ja, gut.

Wolfi Gassler (00:07:17 - 00:08:17)

Jetzt tut es mir schon mal leid, dass wir da Andi in unserem Gespräch haben, weil Andi ist ja fast der absolute Kritiker, würde ich mal sagen. Umso schöner ist natürlich, dass du da bist, wobei ich es super interessant gefunden habe, weil der Andi hat mir deinen Talk geschickt und hat irgendwie gemeint, super, da gibt es endlich jemanden, der das Ganze kritisch betrachtet und mal eben das Wind aus den Segeln nimmt. Und dann habe ich deinen Talk angeschaut und habe mir gedacht, der ist total positiv. Also man nimmt sich glaube ich immer diese Elemente raus, die einem persönlich einfach mehr liegen. Aber um mal in das ganze Thema einzusteigen, ich glaube, das, was wir ja alle so als Entwickler und Entwicklerinnen so am Schirm haben, ist irgendwie Co-Pilot, das ist ja so in aller Munde. Aber wenn du jetzt Andi mal erklären müsstest, was das Ganze ist, eigentlich so dieses Co-Pilot oder Co-Generation, von dem alle sprechen, Und vielleicht auch mit einem positiven Touch, damit Andi vielleicht auch mal damit startet, wie würde diese Erklärung aussehen?

Birgitta Böckeler (00:08:17 - 00:10:02)

Genau, also ich hab's ja gerade schon gesagt, es geht natürlich hauptsächlich um diese aktuell gehypte Ausprägung von AI, also Generative AI. Und da im Coding-Bereich ganz speziell natürlich die Large Language Models, also eben genau das, was wir bei Chat-GPT und diesen Tools auch haben, die eben sehr gut sind im Pattern-Matching und im Pattern-Synthese, also dann Patterns wieder Es gibt ja auch diesen Begriff, stochastic parrots, also dann eben diese, wie ein Papagei, halt Patterns zu wiederholen, aber eben angepasst auf die Situation, also das, was ich gefragt hab zum Beispiel. Und das ist eben das, was sich für Code so gut eignet. Also, wenn man eben Large-Language-Model mit sehr viel Code füttert, dass es dann eben eine gewisse Fähigkeit hat, das zu wiederholen, also die Patterns wiederherzustellen. Also das, wenn ich zum Beispiel sage, okay, ich möchte hier eine Methode schreiben, die folgendes macht, dass es eben dann seine Patterns, die es hat über Code, auf meine Situation anwenden kann. Und das funktioniert eben erstaunlich gut. Es funktioniert auch nicht immer, da können wir gleich auch noch drüber reden. Aber das ist eben das, warum sich die Large-Language-Models für Code dafür so gut eignen. Und man kann sie dann aber eben zusätzlich auch noch mit anderen Dingen kombinieren. Also, so ein Large-Language-Model versteht nicht wirklich den Code. Es denkt ja nur in Tokens. Also, genauso, wenn es Sprache, wenn es natürliche Sprache, also Deutsch oder Englisch, wiederholt, es versteht nicht wirklich, was es da macht inhaltlich, ne? Aber man kann eben dann zusätzlich, das Large-Language-Model noch kombinieren mit dem, was eine IDE kann. Also, was die IDE weiß über JavaScript zum Beispiel oder über Java oder so. Und das ist eben das, was Tools wie, GitHub Copilot machen, dass sie eben nicht nur rein das Large-Language-Model benutzen, sondern das auch kombinieren mit der Language Intelligence, die man in der IDE hat, und dadurch wird es dann eben potenziell nochmal ein bisschen besser.

Andy Grunwald (00:10:03 - 00:10:53)

Aber jetzt stelle ich mir die frage ist denn coding wirklich voll von patterns weil im endeffekt ist ja softwareentwicklung ja ein sehr kreativer bereich das bedeutet du hast eine syntax und die syntax wird in ganz verschiedenen formen neu miteinander kombiniert natürlich hast du design patterns die sich immer wieder spiegeln oder klassische funktionen wie bauen wir mal ein palindrom oder errechnen wir den median oder ähnliches, Das ist klar, dass solche Sachen sich wiederholen. Aber im Großen und Ganzen gibt's ja auch in der Softwareentwicklung noch, ich sag mal, Innovationen. Nehmen wir mal diese Berechnung von Kamek bei Doom, ich glaub, wie der eine Wurzel zieht oder so was. Das ist ja dieses klassische Beispiel von innovativer Softwareentwicklung. Ich stell mir grad die Frage, gibt's denn wirklich so viel Patterns in der Softwareentwicklung, dass das wirklich so gut funktioniert?

Birgitta Böckeler (00:10:54 - 00:13:33)

Ja, also ich meine, es kommt ja auch darauf an, in welcher Größe man denkt. Und wie gesagt, das funktioniert auch nicht unbedingt für alle Situationen, die man hat. Aber, also wenn ich Copilot benutze, dann kriege ich erstmal normalerweise relativ kleine Snippets vorgeschlagen. Also es ist nicht wie, ich gehe zu Chat-GPT und frage und bitte Chat-GPT, mir ein ganzes Programm zu generieren. Also in Copal ist es ja eher so, dass ich tippe, also das ist wie Autocomplete on Steroids, sagen auch viele Leute, ne? Und dann kriege ich halt Vorschläge. Und das sind dann irgendwas zwischen eine Zeile und, sagen wir mal, ich hatte auch schon mal so bis zu zehn Zeilen oder so, ne? Und wenn du mal so drüber nachdenkst, was man so schreibt an so einem Tag, ich hab's auch mal Info gelesen, ich glaube, Simon Wardley hat das Info geschrieben, dass irgendwie über 90 Prozent des Codes, den wir schreiben, ist schon mal irgendwie geschrieben worden. Und, also es ist ja oft, wir machen irgendwie eine For-Loop, wir mappen irgendwie eine Liste, all diese Sachen. Du hattest die Medienfunktion als Beispiel genannt, genau, das ist irgendwie so ein typisches Beispiel, wo man sich vorstellen kann, ah ja, das wurde, ist irgendwo im Modell in den Trainingsdaten drin, das, da gibt's Lösungen auf Stackoverflow und die krieg ich jetzt hier vorgeschlagen, ne. Aber ein anderes Beispiel ist, ich hab zum, in einem Co-Pilot-Training, was ich mache, hab ich immer das Beispiel, da wollte ich, da musste ich so Listenverarbeitung machen. Also ich hatte eine Liste und musste im Prinzip, um mein Problem zu lösen, musste irgendwie was gruppieren, und dann was mappen, und dann irgendwie die flatten. Und halt so diese typischen Listenoperationen, das machen wir ja ständig. Und ich hab quasi beschrieben, was ich machen wollte, und hab wirklich diese drei, vier, fünf Schritte von Listenoperationen von Copilot bekommen, und er hat sogar die Library benutzt, die ich schon importiert hatte, die mir bei Listenoperationen hilft. Und das ist so ein Beispiel von Patterns, wo es so ein bisschen mehr angewendet ist, wirklich auf meine Situation. Also es ist nicht ganz Boilerplate, aber es ist jetzt auch nicht besonders speziell, sag ich mal, ja. Und es hilft mir einfach dann, schneller voranzugehen. Es hilft mir natürlich mehr, wenn ich, so wie ich halt, mehr als 20 Jahre Erfahrung im Programmieren habe. Und ich hab eigentlich schon im Kopf, was ich machen will. Und CoPilot hilft mir einfach nur, die Details zu füllen. Und ich bin auch relativ schnell darin zu sehen, Ah ja, genau, das ist das, was ich brauche oder so. Oder ich weiß, ich habe schon einen Test und ich habe eine schnelle Feedback-Loop und ich kann gucken, ob das stimmt. Es kann natürlich potenziell für Entwickler oder eine Entwicklerin mit weniger Erfahrung, kann es natürlich ein bisschen schwieriger sein, weil du vielleicht auch gar nicht im Kopf hast, wo die Patterns, die du brauchst, um das zu implementieren. Und dann kann der Review länger dauern oder man kann schneller mal was glauben, was nicht stimmt oder was nicht passt. Aber das ist so ein gutes Beispiel, finde ich, von diesem Patterns-Anwenden auf meine Situation über so eine simple statische Reproduktion von der Medienfunktion.

Wolfi Gassler (00:13:33 - 00:13:45)

Würdest du dann sagen, dass es gefährlich ist für Junior-Devs, so was einzusetzen? Oder auch vielleicht, wenn gerade die, die halt neu sind, in der ganzen Entwicklungsszene, dann direkt so was einzusetzen?

Birgitta Böckeler (00:13:45 - 00:15:19)

Ja, das ist auf jeden Fall eine sehr oft gefragte Frage. Und ich bin mir immer noch nicht so ganz sicher. Ich hab natürlich auch mit ein paar neueren Entwicklerinnen und Entwicklern geredet, aber so richtig bin ich auch noch nicht. Ich glaub, das wird die Zeit auch so ein bisschen zeigen. Ich versuche auch immer nicht so die alte Frau zu sein, die auf der Veranda steht und ihre Faust schwingt und sagt, ah, die jungen Leute heute mit Coding Assistance, die lernen gar nicht mehr, wie man richtig programmiert. Ich will aber auch positiv sein und vielleicht denken, vielleicht ist das einfach jetzt eine andere Art zu lernen. Also ich habe in einem Artikel auch mal gelesen, da hat die Autorin gesagt, als wir Internet-Suche, Google und so weiter bekommen haben, Da hat es so einen richtigen kognitiven Shift gegeben. Also von, ich muss Sachen auswendig wissen, zu, ich muss nur wissen, wo ich die finde. Und das war so ein kollektiver, kognitiver Shift, wie wir denken. Also meine Oma zum Beispiel konnte immer noch Gedichte auswendig und sowas. Das macht ja heute keiner mehr, weil muss man nicht mehr. Also das fand ich einen interessanten Gedanken. Gibt es da jetzt einen kognitiven Shift? Und ob der gut ist oder schlecht, werden wir vielleicht dann sehen. Und es gibt auf jeden Fall auch Anzeichen, dass es auf der anderen Seite auch sehr helfen kann. Also klar kann man vielleicht irgendwie in falschen Pfad runtergeleitet werden, aber es gibt auch sehr viele Beispiele, wo Leute wirklich in eine Konversation gehen mit einem Chatbot und wirklich was lernen auch. Gerade wenn es so um Basics geht, wo es halt wahnsinnig viele Beschreibungen und Daten in den Trainingsdaten gibt von den Modellen. kann das auch ganz gut funktionieren und tatsächlich Leuten auch helfen, besser autonom zu lernen. Aber ja, das ist auf jeden Fall ein Konzern.

Wolfi Gassler (00:15:20 - 00:15:44)

Es erinnert mich auch eigentlich so an meine Zeit an der Uni. Ich habe lange an der Uni auch gelehrt. Und im Prinzip, du könntest ja immer irgendwelche Libraries verwenden, um jetzt irgendeinen Sortieralgorithmus zu verwenden. Macht man ja üblicherweise auch. Aber trotzdem lernst du an der Uni natürlich, wie so ein Sortieralgorithmus aufgebaut, was sind die Eigenschaften oder eine verkettete Liste, wie füge ich da ein Element ein, was es auch immer ist.

Birgitta Böckeler (00:15:44 - 00:15:45)

Habe ich übrigens nie gelernt.

Wolfi Gassler (00:15:46 - 00:15:49)

Eben ist die Frage, muss man das heutzutage noch lernen?

Birgitta Böckeler (00:15:49 - 00:16:31)

Und habe ich auch nie benutzen müssen. Ich glaube, wir dürfen auch nicht romantisieren, wie wir gelernt haben. Also wie viel ich Copy und Paste aus dem Internet einfach zusammengesteckt habe. Also ich will auch nicht irgendwie in den Himmel loben, wie ich damals wunderbar gelernt habe. Aber natürlich ist es jetzt amplifiziert und geht dann nochmal schneller potenziell das Falsche zu machen. Es gibt vielleicht auch teilweise weniger, ich frage mich auch, ob es weniger, sorry, über mein Denglisch, ich rede so viel Englisch über dieses Thema, ob es weniger Incentive, weniger Anreiz, Anreiz ist das Wort, ja, ob es weniger Anreiz gibt für Leute, dann auch Sachen besser zu machen, wenn es halt einfach so schnell geht, das funktional hinzuschreiben. Das ist auch vielleicht noch eine andere Frage.

Wolfi Gassler (00:16:31 - 00:16:58)

Aber ich glaube, man kann es halt auch positiv einsetzen, weil du bekommst halt auch schnell Hilfe und Input, wenn du eben einen Chat machst oder so und fragst, was ist jetzt an meiner verketteten Liste zum Beispiel falsch? Du könntest sofort Input bekommen und das eher im positiven Sinne sehen. Und vermutlich müssen manche Leute auch in Zukunft noch wissen, wie verkettete Listen funktionieren. Die Frage ist, wie viele Leute es noch wissen müssen. Weil Assembler programmieren kann halt auch nicht mehr jeder.

Birgitta Böckeler (00:16:58 - 00:18:33)

Ja. Und auch dieses, wie gehe ich mit diesem Assistenten um? Und wann vertraue ich der Maschine und wann vertraue ich ihr nicht? Also zum Beispiel, Andi hat erwähnt, ich schreibe so Memos auf martinfowler.com zu dem Thema. Und das Letzte, was ich geschrieben hab, da geht's eben grad um dieses Thema, also, ja, ob Halluzinationen oder generell, wie gehe ich damit um, dass dieser Assistent nicht so ist wie andere Software? Also, der ist halt nicht deterministisch und ... Ich kann dem nicht immer trauen. Und ich muss halt zum Beispiel drüber nachdenken, okay, ich krieg jetzt eine Information von dem Chatbot, wie schnell ist zum Beispiel die Feedback-Loop, die ich habe, um rauszufinden, ob das stimmt oder nicht. Ich hab zum Beispiel in letzter Zeit viel Python geschrieben, hab ich früher nie gemacht. Das heißt, ich hab viel so dumme Fragen gefragt wie, gibt es das Konzept von statischen Methoden in Python oder so was, ne? Also so Basisfragen. Und dann geht immer in meinem Kopf so eine Checkliste. Einmal ist es relativ ... Also eine relativ simple Frage. Also ich habe eigentlich hohes Vertrauen, dass die Antwort wahrscheinlich richtig ist. Das ist so eine Sache. Oder ich kann es ganz schnell einfach eintippen in meine IDE und ich kriege vom Python-Interpreter in der IDE relativ schnell Feedback, ob es dieses Keyword überhaupt gibt. Kann auch schnell meinen Test ausführen und gucken, ob das funktioniert. Das heißt, ich habe relativ schnell Vertrauen, dass es geht. Andererseits, wenn ich vielleicht irgendwie ein Infrastruktur-Change schreibe, wo aufgrund meiner Umgebung ich 20 Minuten brauche, bis ich weiß, ob der funktioniert, weil ich erstmal deployen muss, dann gucke ich vielleicht doch lieber auf einer Webseite, weil da kostet es mich halt, wenn der Assistent mich irgendwie aufs Glatteis führt.

Wolfi Gassler (00:18:33 - 00:19:09)

Wobei ich da ja sagen muss, wenn man jetzt die klassische Stack-Overflow-Zeit sich zurückruft, du hast natürlich genauso ausprobieren müssen, ob diese Lösung für dich funktioniert hat. Also mir ist es auch oft so gegangen, dass man da was rauskopiert hat oder copy-based, wie du zuerst gesagt hast. Und am Ende hat es auch nicht funktioniert oder in meinem speziellen Szenario und Kontext nicht funktioniert. Und da würde ich vielleicht sogar sagen, dass durch die Anpassung an den aktuellen Kontext das vielleicht sogar eigentlich die bessere Antwort ist, die mir irgendein Co-Pilot liefern kann, weil er eben meinen Kontext unter Umständen auch noch besser verstehen könnte in der Theorie.

Birgitta Böckeler (00:19:10 - 00:19:25)

Vielleicht ja. Auf der anderen Seite hat man natürlich im Stackoverflow was, was man im Assistenten nicht hat. Und das sind die Up- und Downvotes von den anderen BenutzerInnen. Wenn dann schon 150 Leute gesagt haben, das funktioniert für mich so, dann das führt natürlich auch dazu, dass ich mehr Vertrauen habe.

Andy Grunwald (00:19:26 - 00:19:53)

Aber ist das nicht ein essenzieller Teil der Trainingsdaten? Ich mein, deswegen, so hab ich das zumindest verstanden, hat jetzt zum Beispiel auch Reddit ihre API eher dichtgemacht, beziehungsweise kostenpflichtig gemacht, aufgrund dieser Community-Upvotes, ja? Also, es ist ja nicht nur Content, den eine Person reingestellt hat, sondern den haben etliche Leute durch den Upvote verifiziert, oder dass die Upvotes jetzt bei Stack Overflow oder Reddit dann eher eine höhere Gewichtung hat. So hab ich verstanden, werden LLMs ja auch trainiert, oder nicht?

Birgitta Böckeler (00:19:54 - 00:19:59)

Meinst du, ob die LLMs beim Trainieren auch diese Up- und Downvotes mit in Erwägung ziehen?

Andy Grunwald (00:19:59 - 00:20:00)

Ganz genau.

Birgitta Böckeler (00:20:00 - 00:20:15)

Das kann ich mir eigentlich nicht vorstellen. Dann müssten sie ja wirklich für jede Webseite, die sie scrapen oder wo sie aus der API die Sachen rausholen, dann auch irgendwie eine Heuristik anwenden. Also ich glaube, ich habe bisher immer gedacht, das ist rein statistisch alles, also Menge, einfach nur Menge, wie oft ist was geschrieben.

Andy Grunwald (00:20:16 - 00:20:16)

Auch ein guter Punkt.

Wolfi Gassler (00:20:16 - 00:20:42)

Also meines Wissens hast du natürlich manche Datasets, die einfach höher gewichtet sind und Reddit ist an sich schon höher gewichtet, weil es halt User-Content ist und nicht irgendein SEO-Content, der schon halb automatisch erstellt wird, sondern halt eher User-Generated-Content und dadurch im Idealfall vielleicht auch qualitativer ist. Ich könnte mir auch vorstellen, dass sie natürlich irgendwelche Upvotes mit einrechnen, um das Gewicht zu erhöhen. Aber ja, wir wissen ja leider nicht.

Birgitta Böckeler (00:20:43 - 00:22:36)

Ja, ja, genau, genau. Ja, und es ist natürlich, jetzt kommen wir natürlich auch in das Feld rein von, ist das eigentlich alles okay? Weil natürlich auch die Large Language Models, gerade die, die speziell für Coding trainiert wurden, wie zum Beispiel das Codex Model, was von GitHub Copilot benutzt wird, Ja, das ist quasi ein Scraping von einfach allen Public Repositories auf GitHub. Und da gibt's natürlich auch Repositories mit Free Software Lizenzen zum Beispiel, ne? Und ist das eigentlich okay, ne? Und das ist schon auch ein, was, was bei mir auch immer mitschwingt, wo ich denke, ach, das macht mich schon auch, Uncomfortable. Und ist das eigentlich okay, dass jetzt Microsoft so viel Geld damit verdient? Ein Produkt, was, obwohl man auch nicht weiß, übrigens Sidebar, ob das wirklich gerade so wahnsinnig viel Geld macht oder nicht. Da gibt es, also weil es auch sehr teuer ist, das zu hosen. Aber wie dem auch sei, ist das eigentlich okay, dass so eine Firma wie Microsoft jetzt gerade Geld damit verdient, mit einem Produkt, was nicht existieren könnte, wenn es nicht irgendwie 20 plus Jahre an freier Arbeit von Leuten an Open Source und sowas gegeben hätte, ne? Das Einzige, was ich da halt im Moment hoffe, aber es muss sich rausstellen, ob das, ob das funktioniert, weil GitHub schon sehr, sehr große Marktmacht gerade in dem Bereich hat und auch ein sehr gutes Produkt, ist, dass es jetzt auch immer mehr Open-Source-Modelle gibt oder auch Modelle, die, die anders trainiert sind, also wo extra bestimmte Repositories vielleicht nicht mitbenutzt wurden in den Trainingsdaten. Und dass je mehr es auch offene Modelle gibt, dass vielleicht es mehr Möglichkeiten gibt, für andere Leute auch Produkte zu bauen oder das mehr, also auch Open-Source-Produkte halt in dem Bereich besser zu machen. Das würde mir dann ein bisschen besseres Gefühl geben, aber ich glaube, das wird immer mitschwingen bei diesem Thema, weil es eben gleichzeitig schwer ist, drumherum zu kommen. Es ist jetzt da und es funktioniert erstaunlich gut. Ja, ich glaube nicht, dass es wieder weggeht.

Wolfi Gassler (00:22:36 - 00:23:11)

Wie siehst du das, weil du ja auch viel mit Firmen vermutlich zusammenarbeitest bei ThoughtWorks, wie groß sehen die Firmen diese Gefahr, dass da irgendwie ihr eigener Code nach außen gelangt, weil du musst ja doch immer den gesamten Kontext, irgendwelche Codesnippets an einen Server da draußen irgendwie schicken und dann wird das vielleicht irgendwie verwendet für irgendwelche Trainingszwecke und dann hast du noch deine lokalen Secrets womöglich aus irgendeinem Endfile da drin, weil das im Kontext liegt. Also wie sieht das Ganze aus? Gibt es da Angst auf der Firmenseite und wie siehst du das Ganze?

Birgitta Böckeler (00:23:11 - 00:25:14)

Ja, da gibt es auf jeden Fall Angst oder einfach Risiko-Betrachtung. Also es sind eigentlich zwei Sachen. Das eine ist das, was du gerade beschrieben hast. Kann mein Code irgendwie leaken und irgendwo anders auftauchen oder eben auch gerade die sensiblen Teile, also wie zum Beispiel Secrets. Und die andere Seite ist, kriegen wir in der Zukunft Ärger, wenn die Gesetze quasi hinterherkommen und dann sagen, nee, ihr habt Coding Assistants benutzt und deshalb habt ihr Open Source Lizenzen verletzt. Also das sind so die zwei Bereiche. Und was die Code Confidentiality angeht, sag ich mal, also das landet mein Code irgendwo anders. Das ist einer der Gründe, warum GitHub Copilot gerade so große Marktmacht hat, weil viele Firmen sowieso ihren Code schon auf GitHub posten, also in privaten Repositories. Und wenn du deinen Code sowieso schon an GitHub gegeben hast, dann ist schon mal der nächste Schritt, dann zu sagen, jetzt schicke ich auch Snippets, während ich code, an GitHub, ist dann nicht mehr so groß, weil der Code ist eh schon bei GitHub. Und GitHub hat natürlich auch einen gewissen Ruf als im Sinne von Engineering-Qualität und den Produkten, die sie haben. Und deswegen vertraut man ihnen vielleicht auch nochmal mehr als jetzt irgendwie einem frischen Startup, was das Schützen von den Daten auch angeht. dass die Snippets nicht gespeichert werden. Und wenn sie gespeichert werden, sind sie gut geschützt. Und GitHub hat auch, also nach ihren eigenen Angaben, in ihrem Backend auch noch extra Security-Vulnerability-Scans und so was eingebaut, bevor sie dir die Snippets zurückschicken. Und da ist, glaub ich, ein gewisses Grundvertrauen auch dann da. Ja, was die andere, was die Gesetzssituation angeht mit Copyright und Copyleft insbesondere, ja, in diesem Fall, Ja, muss man schauen. Es gibt ja ein paar Lawsuits auch gerade. Ich bin keine Anwältin. Deswegen halte ich mich da immer so ein bisschen zurück. Es gibt viel Presse und viele Anzeichen, dass es als Fair Use legal eingestuft werden könnte. Da bleiben dann natürlich immer noch die Konzerns. Trotzdem ist es okay. Aber ich bin keine Anwältin. Ich kann es schlecht einschätzen, wie das weitergeht.

Andy Grunwald (00:25:15 - 00:26:06)

Ich kann mir gut vorstellen, dass das rechtlich auch eine unglaublich komplizierte Geschichte ist, weil, ich meine, länderübergreifend, kontinentübergreifend, dann haben wir die EU noch dazwischen. Welches Recht gilt denn da? Gilt denn das Recht von Microsoft oder von GitHub aus Amerika? Gilt das Recht von dem Autor, von der Software aus dem Land, wo der Autor herkommt? Ich weiß es alles nicht. Ich bin mir gar nicht sicher, ob es jemand weiß. Und ich bin mal gespannt, ob diese Lawsuits dann überhaupt rechtens sind, auch wenn dann Richter irgendwas gesprochen hat. Oft hört man natürlich auch, zumindest aus unserer Sparte, wenn man sich mal diese ganzen Lawsuits im Informatik- und Softwarebereich ansieht, da sagt der klassische Softwareentwickler ... Gut, die Jury hat ja von Tuten und Blasen keine Ahnung. Da sagt ja der Chaos Computer Club ja auch kontinuierlich irgendwas von daher.

Birgitta Böckeler (00:26:06 - 00:27:08)

Und insbesondere halt, also es gibt ja einmal dieses ist das Fair Use, dass eine Firma das alles benutzt hat, um was zu trainieren, um dann ein Produkt zu machen. Aber dann gibt es ja auch den Teil, die Benutzer dann von dem Assistenzprodukt, haben die ein Problem, dass sie das verletzen, wenn sie das Produkt benutzen. Und da ist, glaube ich, vor allem, ich habe vorhin darüber geredet, wie es oft kleine Vorschläge sind. Und das kennen wir ja eben auch, also es gab ja auch diesen großen Rechtsstreit zwischen Google und Oracle über die Android-SDKs, also vor, ich weiß nicht, wie lange ist das jetzt her, sechs, sieben Jahre oder so. Wo wir ja auch alle gesagt haben, man kann doch nicht jetzt diese SDKs irgendwie, diese APIs als IP irgendwie bezeichnen oder so, weil es ist so generisch, ne? Und wenn ich da irgendwie meine Listenprozessierung bekomme, und das ist zufällig auch genauso in einem Open-Source-Projekt, ist eigentlich erstmal keine, also ich meine, und dieses Kopierrisiko haben wir ja heute im Prinzip auch schon. Es ist halt jetzt nur eben vergrößert. Also es hat so ein bisschen auch was mit der Größe der Snippets zu tun, die man benutzt.

Wolfi Gassler (00:27:09 - 00:27:49)

Ich habe jetzt gerade chat.gpd gefragt, Lawsuit heißt Klage. Nochmal ins deutsche übersetzen. Ganz allgemein, weil du jetzt die Snippets und so weiter erwähnt hast und was da geschickt wird an den Server, hast du da irgendwie nähere Einblicke, beziehungsweise kannst du uns mal erklären, was da im Hintergrund eigentlich passiert, dass Copilot oder so ein Code Generator so gut funktioniert, dass ich da einfach während ich programmiere, sinnvolle Vorschläge bekomme, weil für mich ist es auch immer, wie viel wird da einbezogen, plötzlich bekomme ich irgendwelche Variablen, die in ganz anderen Dateien drin sind, aber irgendwie können ja nicht alle Dateien an den Server gesendet werden, also hast du da irgendwie einen Einblick, was da im Hintergrund so passiert?

Birgitta Böckeler (00:27:49 - 00:30:25)

Ja, also erst mal ganz grundsätzlich, was das, ich sag mal fast Architekturpattern angeht, was hier passiert, ist eigentlich das Gleiche auf einem, auf einem hohen Abstraktionslevel, was in den meisten Applikationen gerade passiert, die ein Large Language Model im im Backend haben. Und das ist so ein Ansatz, der heißt Retrieval Augmented Generation. Ich weiß nicht, ob ihr davon schon mal gehört habt, RAG für kurz, also R-A-G. Und im Prinzip ist das immer so, bei diesen Applikationen so, der Benutzer oder die Benutzerin gibt einen Input, also zum Beispiel eine Frage oder im Fall von einem Coding-Assistenten wäre es, ich tippe was in die IDE. Und dann gibt es eben eine Applikation zwischen dem Benutzer und dem Large Language Model, Und diese Applikation baut erst mal noch mal den ultimativen Prompt zusammen. Also Prompt quasi das, was ultimativ an das Modell geht. Und da kann alle mögliche Logik passieren. Und der Teil von dieser Retrieval Augmented Generation ist eben, dass man sagt, es passiert noch Information Retrieval zusätzlich. Also es ist der Terminus Technicus, das war jetzt noch nicht mal in denglisch, Information Retrieval, wo ich andere Datenquellen noch mal angehe und dann anreichere den Prompt. Und im Fall von einem Produkt wie GitHub Copilot ist eben diese Anreicherung passiert eben anhand des Codes, den ich in meinem Editor habe. Also was da dann genau passiert, ist eben auch so ein bisschen obskur. Also da gibt es irgendeine Heuristik in dem Plugin, in dem IDE-Plugin. Und diese Heuristik versucht zu bestimmen, welcher andere Code könnte denn noch relevant sein gerade. Also einmal ist es natürlich nach meinem Cursor und vielleicht ein Stück vor meinem Cursor, aber es guckt dann anscheinend auch, welche anderen Dateien sind offen vom gleichen Language-Typen, also wenn ich gerade JavaScript schreibe, welche andere JavaScript-Datei ist noch offen, und versucht dann irgendwie zu gucken, was könnte denn da noch relevant sein an dieser Stelle. Und das passiert alles in der IDE, das ist noch gar nicht beim Modell. Und daraus wird dann eben final eben ein Promt zusammengestellt, der dann quasi sagt, okay, das ist die folgende Sprache und das ist eben das, was das Produkt ausmacht, das IDE-Plugin. Also wie gut das funktioniert und was natürlich auch eine Engineering-Herausforderung ist, ist das mit niedriger Latenz zu machen. Weil wir natürlich als EntwicklerInnen, wir sitzen da und tippen und wir wollen schnell unseren Vorschlag haben und wenn der nicht schnell genug kommt, dann tippen wir einfach weiter. Und dann hilft es uns auch nicht. Und das ist, glaube ich, so die Herausforderung, weil je besser die Modelle sind, desto langsamer sind die normalerweise auch in der sogenannten Inferenz. Also in dem, wenn ich anfrage und eine Antwort zurückkomme, das nennt sich Inferenz. Genau, das ist dann die Engineering-Herausforderung. Das, wofür man auch bezahlt, wenn man das Produkt kauft.

Wolfi Gassler (00:30:25 - 00:31:18)

Das Problem ist ja auch, was ich persönlich schon einige Male jetzt mittlerweile erlebt habe, sind ja so diese, ich würde sie mal nennen, sophisticated Halluzinationen. Das heißt, eine Halluzination, die eigentlich irgendwie passt in meinem Code mit einer Variable. Und ich übersehe das Problem und bekomme dann irgendwelche Arrows irgendwo geschmissen. Und ich kenne aber die Variable. Und was mir schon passiert ist, ich habe dann an der falschen Stelle gesucht, weil ich die Variable irgendwo anders verwendet und habe dort den Bug vermutet. Und dabei hat mir der Co-Pilot irgendwo was injected. Und ich bin dann wirklich lange teilweise am Bug-Hunting gesessen, um wirklich diesen Bug aufzuspüren. Das macht es natürlich noch mal komplizierter. Gibt es irgendwelche Methoden, um die Halluzinationen zu vermeiden oder zu reduzieren? Oder vielleicht auch, die Vorschläge am Ende besser zu machen?

Birgitta Böckeler (00:31:18 - 00:33:53)

Ich höre manchmal so Sätze wie, how to ensure, Und ich glaube, dass das nicht möglich ist. Aber eben diese Ansätze, wie zum Beispiel RAC, Retrieval Augmented Generation, wird immer so gesagt, es ist so, die erden das Modell zu einem gewissen Grad auf das, was ich lokal eigentlich gerade mache. Also zum Beispiel, wenn meine anderen Dateien offen sind. Aber es ist natürlich trotzdem nicht perfekt. Das heißt, Teil des Ganzen ist eben einfach auch unser mentaler Ansatz, also wie wir damit umgehen. Und ist eben auch eine Weile, das Tool zu benutzen, um ein Gefühl dafür zu bekommen. Also ein paar Mal halt auch auf die heiße Herdplatte zu fassen, um irgendwann dann eben ein Gefühl dafür zu bekommen, wann ich vertraue und wann ich dem vielleicht nicht vertrauen sollte oder so. Also, was du zum Beispiel gerade beschrieben hast, die Sophisticated Hallucinations, ich hatte das mal, ich habe GitHub-Copilot-Chat gebeten, mir ein Klassendiagramm in Mermaid.js-Format zu generieren. Und es hat mir das generiert, es sah total plausibel aus. Und ich habe dann versucht, das zu rendern und habe irgendwie zehn Minuten versucht, das hinzukriegen. Ich habe gedacht, ich embedde das nicht richtig in meiner Markdown-Datei. Und irgendwann bin ich dann auf die Ich bin auf die Webseite gegangen von Mermaid.js und hab festgestellt, die Syntax sieht ganz anders aus. Aber es sah halt total plausibel aus, wie ein Klassendiagramm. Und dann hab ich dann Copilot Chat ein Copy-and-Paste-Beispiel von der Webseite gegeben. Und dann hat er gesagt, ja, Entschuldigung für die Confusion. Und hat mir dann anhand dieses Beispiels perfekt das Klassendiagramm für meine Situation generiert. Also, das kann auf jeden Fall passieren. Genauso, wie es uns passieren kann, dass wir was Falsches von Stack Overflow kopieren oder so. Aber deswegen, glaube ich, ist es wichtig, dass wir vertraut werden mit dem Tool und es auch eine Weile benutzen, bevor wir es an die Seite legen. Weil es ist ein neues, ja, ich sag mal, Mindset. Das ist ein englisches Wort. Aber was ich vorhin gesagt habe, das ist nicht wie andere Software. Es ist nicht deterministisch, es gibt uns nicht immer die richtige Antwort. Und wir sind es gewohnt, mit richtiger Software zu arbeiten, sag ich jetzt mal, ne? Und wenn man dann zum Beispiel skeptisch rangeht, wie zum Beispiel, was du gesagt hast, Andi, dass du skeptisch bist vielleicht, ne? Und dann, wenn man zweimal eine falsche oder nicht so perfekte Antwort bekommt, dann gleich sagt, ah ja, das funktioniert ja gar nicht. Es kommt immer darauf an, welche Erwartungen man hat. Es hört sich vielleicht komisch an, aber es geht halt darum, bringt mich das 60, 70 Prozent des Weges auf eine Art und Weise, die im Gesamtergebnis für mich hilfreich ist? Und wir sind das nicht gewohnt, als Softwareentwickler irgendwie so über Software nachzudenken. Und das ist halt so ein bisschen der Mindsetchange. Und dann deswegen ist es halt auch so, dass man eine Weile es benutzen muss, um so diese Beispiele zu haben und wirklich zu merken, funktioniert das für mich oder funktioniert das für mich nicht und für meine aktuelle Situation?

Wolfi Gassler (00:33:53 - 00:34:17)

Aber du hast schon dieses Beispiel erwähnt, du hast dann die Webseite zur Verfügung gestellt. Gibt's da irgendwie schon mehr Möglichkeiten, dass man mehr Input liefert? Keine Ahnung, irgendwie Dokumentation, die man sonst rumliegen hat oder... Also, dass es mehr als diese paar JavaScript-Dateien, die da in meiner IDE noch offen sind, dass man dadurch irgendwie eine höhere Qualität erreicht? Und gibt's das in der Praxis schon? Weil aktuell installiere ich ja dieses Ding und es funktioniert einfach.

Birgitta Böckeler (00:34:18 - 00:35:31)

Und das ist eben genau wieder dieses Retrieval Augmented Generation Thema. Also, dass ich eben schaue, wie kann ich weitere Informationen anreichern, bevor ich an das Large Language Model gehe. Und das ist eben auch oft der viel leichtgewichtigere und pragmatischere Ansatz, als Modelle zu finetunen. Also es ist ja dann oft die Frage, ah ja, kann ich das Modell finetunen mit meiner Codebase oder kann ich es finetunen mit meiner Dokumentation oder so. Und Finetuning ist halt sehr teuer und führt auch nicht unbedingt dann zu dem Ergebnis. Ich hab mal im Podcast letztens den schönen Satz gehört, Finetuning ist for tone, rag, retrieval augmented generation, is for facts. Also der Gast im Podcast hat dann das schöne Beispiel gegeben, dass man zum Beispiel, wenn man möchte, dass ein Modell so spricht wie Shakespeare, das ist ein super Use Case für Finetuning. Also wenn man den Ton ändern will. Und man kann aber in einem Large Language Model, Er hat behauptet, es ist unmöglich, ihm beizubringen, dass es nicht Romeo und Juliet ist, sondern Bob und Juliet. Also einen Fakt wirklich zu ändern. Und das kriegt man halt nur hin, also Fakten ändern kriegt man nur hin, indem man eben Retrieval Augmented Generation macht und lokal eben seine ganzen Informationen zusammensucht.

Wolfi Gassler (00:35:31 - 00:35:48)

Aber ist das jetzt noch eher ein Forschungsbereich, wo aktuell geforscht wird, würde ich mal sagen? Also wird sowieso garantiert geforscht, aber kann ich sowas schon in der Realität wirklich einsetzen? Gibt's irgendwelche Tools, wo ich sage, okay, das ist meine gesamte Dokumentation, mach da noch Information Retrieval drauf? Also gibt's das in der Realität schon?

Birgitta Böckeler (00:35:48 - 00:37:55)

Ja, auf jeden Fall. Also, wie gut ist dann immer noch die Frage, aber es gibt wahnsinnig viele POCs, Prototypen, erste Produkte, die das machen. Es gibt zum Beispiel, ich weiß nicht, ob ihr Kunden bei Zalando seid, aber bei Zalando gibt es jetzt so ein Chat, das ist der Zalando Fashion Assistant, wo man eben beschreiben kann in natürlicher Sprache, hier, das ist irgendwie, was ich suche. Und dann machen die im Hintergrund genau das, Retrieval Augmented Generation. Also, die haben quasi ihre Daten von ihrem Katalog an Produkten, und versuchen, das zusammenzuziehen und dann mit einem Large Language Model mir eine, mit Hilfe eines Large Language Models mir ein Ergebnis zu geben. Wir kommen vielleicht später auch noch drauf, was kann man denn noch machen außer Coding. Das kann man natürlich auch toll benutzen, wenn man jetzt drüber nachdenkt, okay, kann ich auch ein Large Language Model benutzen, um mir beim Storywriting zu helfen oder beim Threat Modeling. Nehmen wir mal das Beispiel Threat Modeling, ja? Sagen wir mal, ich habe irgendwie einen Prompt, den ich in meiner Organisation teile mit Leuten, der mir hilft, Threat Modeling zu machen für meine Applikation. Also ich muss meine Applikation beschreiben und dann hilft er mir so durchzugehen, okay, was gibt es denn für Szenarien? Brainstorm mir vielleicht erste Szenarien, was zum Beispiel diese ganzen Kategorien angeht, also Tempering of Input und so diese ganzen Threat Modeling Kategorien. Und dann zusätzlich kann ich aber auch sagen, okay, gibt's denn noch irgendwelche Sachen, an die ich denken sollte, anhand spezifisch für meine Organisation, unsere Security Guidelines und unsere Architektur generell, die ich nicht jedes Mal wieder hinschreiben will. Und dann kann ich eben hingehen und diese Information reinziehen und es wird versucht, rauszufinden, was ist der relevante Teil der Dokumentation? Und mir das zusammenzufassen. Und das ist dann auch eigentlich, der Kern hier ist dann gar nicht das Large Language Model, sondern es ist eine neue Art von Suchfunktion. Also im Kern bei RAG ist eigentlich eine Suche. Also ich hab dann meine Konversation, die geht über Threat Modeling, und dann gibt es eine Suche auf meiner Knowledge Base meiner Dokumentation. Welche Sprache in meiner Dokumentation ist ähnlich zu dieser Threat Modeling Konversation? Also Similarity Search nennt sich das zum Beispiel. Und das ist eigentlich der Kern. Es ist gar nicht das Large Language Model selber, aber mit Large Language Models ist jetzt dieser Similarity Search Teil auch einfacher.

Andy Grunwald (00:37:55 - 00:38:06)

Okay, das hört sich aber so an, als kombiniert man da, ich sag mal, andere Bereiche aus dem Suchbereich und ähnliches halt mit dieser Heuristik, Statistik eines LLMs, richtig?

Birgitta Böckeler (00:38:06 - 00:38:45)

Genau, genau. Und LLMs machen es jetzt eben auch einfacher, diese Daten zu erstellen für dieses Similarity Search, also sogenannte Embeddings. Also dann die Daten auch so, also sagen wir mal, ich hab meine Dokumentation und die verarbeite ich dann so, dass sie eben in diese Embeddings transformiert wird und wird irgendwo gespeichert in einer Vektordatenbank oder so. Und dann kann ich darauf jetzt meine Similarity Search machen. Das heißt, diese Technologie hat das jetzt nochmal wieder einfacher gemacht, aber am Ende ist es ein Suchprodukt. Also deswegen auch Elasticsearch zum Beispiel ist auch recht gut darin, dann das auch zu kombinieren mit anderen guten Suchansätzen, die halt Produkte wie Elasticsearch natürlich sehr gut können.

Wolfi Gassler (00:38:45 - 00:38:56)

Und wenn ich jetzt die eigentliche Konversations-Hub plus das Ergebnis von meinem klassischen Text-Retrieval oder Retrieval-Prozess, dann verwende ich wieder ein LLM, um das zusammenzufassen.

Birgitta Böckeler (00:38:56 - 00:40:25)

Um das zusammenzufassen, ganz genau, ganz genau. Und um jetzt wieder auf deine Originalfrage zu kommen, ich bin so ein bisschen abgeschweift, aber du hattest gefragt über Dokumentation, ne? Also ich hatte mal ein Beispiel mit mermaid.js-Klassendiagramm und dann bin ich manuell zu der Webseite gegangen. Genau sowas kann man sich jetzt halt auch vorstellen, wenn man eben Dokumentation für die Libraries, die man benutzt, eben auch so vorbereitet hat und lokal liegen hat in der IDE. Es gibt zum Beispiel ein IDE-Produkt, das heißt Cursor. Das ist eins von diesen Start-up-Produkten, die hochgekommen sind jetzt während der GNI-Zeit. Und die haben das auch schon, dass man bei denen im Chat dann sagen kann, ich möchte bitte, dass du bei meiner Antwort die Dokumentation für Mermaid berücksichtigst. Und dann indiziert er das quasi lokal, also beim ersten Mal, wenn ich das mache, dauert das so ein bisschen, ist das bei mir lokal indiziert. Ich nehme an, unter der Haube ist das dann auch, wird das in Embeddings verwandelt. Und dann kann er das eben mit berücksichtigen. Und genauso ist es jetzt in GitHub Copilot zum Beispiel auch so, dass ich inzwischen im Chat sagen kann, at Workspace. Und dann, wenn ich eine Frage stelle, bezieht er die ganze Codebase mit ein oder versucht zu bestimmen, was in der Codebase ist hier relevant. Und das passiert auch alles bei mir lokal, bevor es dann ans Large-Language-Model geht. Und das ist auch wieder der gleiche Ansatz. Also es wird mal eine Frage genommen, es wird geguckt, was in der indizierten, in der Embeddings verwandelten Codebase könnte relevant sein für diese Frage. Und so funktioniert das dann eben ohne Fine-Tuning und auch mehr lokal als remote.

Andy Grunwald (00:40:25 - 00:40:50)

Also könnte man eigentlich auch sagen, dass das Rack eigentlich dafür da ist, um auch, ich sag mal, das Sprengen der Kontextgröße zu verhindern, oder? Ich mein, in diesen Large-Language-Models geht's ja immer nur darum, okay, du hast so und so viel Tokens und Kontexte und so weiter verfügbar. Und wenn ich mir jetzt eine große Codebase ansehe, dann hab ich immer die Frage, okay, reicht dieser Kontext überhaupt für meine Codebase? Sagen wir mal 4, 5, 6, 7.000 Zeilen. Aber dieses Rack, umgeht das ja dann eigentlich.

Birgitta Böckeler (00:40:51 - 00:41:56)

Genau. Und es ist dann nicht nur RAG, sondern eben, was ich auch vorhin gesagt habe, mit Language Intelligence das noch verbinden. Also diese ganze Applikation in der IDE oder auch in einem großen Produkt. Es gibt zum Beispiel so ein Produkt, was ich letztens gesehen habe, Driver AI. Die haben sich darauf spezialisiert, wirklich mit großen Legacy-Codebases zu arbeiten und die zu verstehen und die zu navigieren. Und die werden wahrscheinlich auch eine Art von RAG benutzen, aber dann noch viel mehr, was da wirklich in dem Produkt passiert und ein Large Language Model ist dann nur ein Teil des ganzen, was da passiert. Und das ist eben auch das, was mir dann relativ schnell so diese Erkenntnis gegeben hat, ah, diese ganzen Schwächen, die ich sehe von Large Language Models, die mich skeptisch machen. Viele von denen lassen sich mitigieren oder es gibt ganz viele Kombinationen mit anderen Technologien und anderen Ansätzen, die jetzt eben, ja, ganz neue Möglichkeiten haben in Kombination mit Large Language Models. Und das ist das Spannende. Und ganz viel von den Sachen, wie es jetzt immer besser wird, ist auch nicht unbedingt dadurch, dass größere Modelle trainiert werden oder so, sondern eben durch Engineering von mehreren Techniken zusammen.

Andy Grunwald (00:41:58 - 00:42:48)

Ich lerne hier schon wieder viele neue Dinge. Wahnsinn. Jetzt kommt der Skeptiker in mir raus. Und ich meine, als Softwareentwickler bin ich eh immer ein bisschen skeptisch bezüglich Marketingmaterial. Und wenn wir hier den Platz hier nehmen, GitHub Copilot, und wenn ich da auf die Marketingwebseite gehe, dann steht da 55% schnellere Entwicklung. Und auch in deinem Talk auf der Lead Dev hattest du gesagt, du warst mal bei einem Kunden, der sogar, ich weiß nicht, vielleicht scherzhaft oder halt auch nicht scherzhaft, aber auch wenn es ein Scherz war, ein bisschen Wahrheit steckt da immer drin, der sagte, kann ich jetzt mein Engineering Team halbieren, weil die arbeiten jetzt ja 55 Prozent schneller. Und das stößt mir so ein bisschen sauer auf, kriege ich vielleicht so ein bisschen Gänsehaut und denke mir so, woher kommt denn diese Zahl, wie wurde diese gemessen, wo ist denn diese Datenbasis, weil wir sind ja alle datengetrieben und so weiter. Und meine Frage ist, wie stehst du dazu? Ich bin glaube ich nicht der Erste, der dich mit dieser Zahl konfrontiert.

Birgitta Böckeler (00:42:48 - 00:45:59)

Ja, und es ist auch nicht nur im Scherz, also es gibt auch schon jetzt nicht in Deutschland, im anderen Land, Wettbewerber von uns, also ThoughtWorks ist eine Software-Consulting-Firma, ein Wettbewerber von uns, der versucht hat, uns auszuboten, indem er dem Kunden versprochen hat, wir machen jetzt alles mit 50 Prozent der Leute, nur dadurch, dass wir den Leuten ein Co-Pilot geben und eine Art von Share-GPT. Das war vor sieben, acht Monaten, das hat sich inzwischen herausgestellt, das hat nicht funktioniert. Spoiler, Leute. Aber es ist, es ist tatsächlich real, ja. Aber genau, also GitHub hat diese Zahl 55 Prozent und um fair ihnen gegenüber zu sein, die wird auch aus dem Kontext genommen. Also es ist nicht so, dass sie sagen, ihr könnt jetzt mit der Hälfte der Leute arbeiten, sondern sie sagen, es kann bis zu 55 Prozent schnellere Task Completion mit Copilot. Mhm. Aber, man muss natürlich das dann immer in Kontext setzen, ne? Also, einmal ist es ja so, dass ... Nehmen wir einfach mal Cycle Time. Also, User Story Cycle Time. Also, die Cycle Time von, wenn man eine Story anfängt, bis dass sie fertig ist. Weil das von ganz vielen als Proxyvariable benutzt wird, von wie schnell sind wir, ne? Und in der Cycle Time verbringen wir aber nur 30 bis 40 Prozent der Zeit damit, überhaupt zu coden. Und wenn ich jetzt, also, sagen wir mal, ich benutze Copilot oder Coding Assistant, das ist alles, was ich mache im AI-Sinne. Also sagen wir mal, sehr positiv gedacht, 40 Prozent meiner Zeit ist Coding in der Cycle Time. Und dann sagen wir mal, so 60 Prozent der Zeit kann ich auch Copilot wirklich benutzen und es ist hilfreich. Weil es hilft auch nicht immer, ne. Also du hattest vorhin auch ein Beispiel von etwas komplexerer, innovativerer Programmierung. Vielleicht hilft es da nicht. Oder ich habe auch mit dem Team gesprochen, die bauen was mit einem proprietären Framework vom Kunden und kriegen einfach weniger hilfreiche Vorschläge, weil es eben nicht in den Trainingsdaten ist und so weiter. sagen wir mal 60% der Zeit kann es mir helfen und immer wenn es mir hilft, bin ich tatsächlich 55% schneller. Dann wenn man das ausrechnet, dann kann ich bis zu 13% schneller sein in der Cycle Time. Also wir wissen alle, Cycle Time ist auch, da gibt es viele Variablen und Es ist auch nicht die beste Variable, aber nur mal, dass man so einen Ballpark hat, also so eine Größenordnung, wie viel Impact das haben kann. Und dann sagen wir mal, unter guten Umständen ist dann bei mir im Kopf immer so 10 Prozent. Aber ich sehe das vielleicht noch nicht mal in meinen Daten. Also, weil Cycle Time ist eben, wie gesagt, sehr variabel. Und wenn ich, sagen wir mal, eine durchschnittliche Cycle Time habe von drei, vier Tagen, und dann werde ich über die Zeit vielleicht über drei Monate insgesamt zehn Prozent schneller. Ich sehe das vielleicht in meinem Rauf und Runter gar nicht, in meinem Graphen. Das ist aber für mich nicht unbedingt ein Zeichen, dann zu sagen, es ist gar nicht hilfreich. Also einmal ist ja so, nur weil jetzt alle einmal 50 Prozent gehört haben und da geankert sind, es gibt ja diesen Cognitive Bias, den Anchoring-Effekt. Also dass, wenn man einmal eine Zahl gehört hat, dann ankert man alles drumherum und alles, was weniger ist, ist schlecht und alles, was mehr ist, ist gut. Und wir haben jetzt alle einmal diese 45 Prozent gehört und wenn wir jetzt 10 Prozent hören, sagen wir, ist ja nix. Aber gleichzeitig kosten diese Produkte weniger als ein Zehntel von einem Prozent von dem, was ein ganzes Team kostet. Und das ist ja ähnlich, ich muss dann immer daran denken, also es gab ja mal eine Zeit als Eclipse eigentlich die marktführende IDE war.

Wolfi Gassler (00:45:59 - 00:46:01)

Ja, die gute alte Zeit.

Birgitta Böckeler (00:46:01 - 00:46:40)

Aus meiner Wahrnehmung als Beraterin ist inzwischen IntelliJ oder die JetBrains-Produkte sind ganz klar Marktführer. Und die kosten Geld, also wenn man die professionell benutzt. Eclipse hat kein Geld gekostet. Das heißt, es gab eine Zeit, wo Leute einfach das Geld nicht ausgeben wollten dafür und einfach nicht geglaubt haben, dass es das wert ist, weil du kannst halt nicht auf dem Papier beweisen, wie viel hast du jetzt gespart, weil deine zehn Entwickler IntelliJ benutzen. Und ähnlich sehe ich das auch bei Copilot, dass es halt eventuell schwierig ist, das zu beweisen. Und ja, deswegen wird das interessant zu sehen, über die Zeit, wie Unternehmen bereit sind, da rein zu investieren und ihren EntwicklerInnen auch zu glauben, wenn sie ihnen sagen, dass es sie mehr produktiv macht.

Wolfi Gassler (00:46:40 - 00:46:56)

Der Unterschied ist natürlich auch, dass AI mittlerweile So ein Hype Thema ist, dass es wahrscheinlich eher vom C-Level teilweise sogar kommt. Bei der IDE hat man noch als Entwickler kämpfen müssen, dass man die IDE bezahlt bekommt und jetzt kommt der AI Hype wahrscheinlich sowieso von oben über C-Level rein.

Birgitta Böckeler (00:46:57 - 00:47:38)

Wenn der AI-Hype dann halt nicht das Versprechen erfüllt, dass jetzt alle 50 Prozent schneller sind, dann mal gucken. Weil man kann ja auch einfach jeden Tag aufhören, das zu benutzen. Es ist ja nicht wie irgendwie eine Library, die in der Runtime ist, die man dann migrieren muss. Du kannst ja einfach sagen, okay, jetzt canceln wir unsere Subscription, ne? Ja, aber dann darüber hinaus ist es natürlich auch nicht nur, es geht ja nicht nur um Schnelligkeit, ne? Also es geht ja auch darum, okay, was mache ich mit der Zeit, die ich spare? Wenn ich zum Beispiel jetzt wieder davon ausgehe, dass ich wirklich irgendwie schneller bin im Programmieren, schreibe ich dann vielleicht mehr Tests, weil ich mehr Zeit habe. Oder nehme ich mir doch mehr Zeit, auch mal was zu refactoren. Also dadurch würde dann wieder dieser Zeiteffekt runtergehen, aber gleichzeitig habe ich halt trotzdem Benefit, weil ich halt potenziell die Qualität verbessert habe.

Wolfi Gassler (00:47:38 - 00:47:43)

Moment, ihr habt gedacht, die Tests werden sowieso von der AI und Code Generator geschrieben.

Birgitta Böckeler (00:47:43 - 00:48:20)

Das ist doch mal wieder ein anderes Thema. Wann sollte man das machen und wann nicht? Und gleichzeitig ist es natürlich so, ich will natürlich auch nicht nur positiv über Qualität reden, wenn es darum geht. Gleichzeitig muss man natürlich auch auf die Risiken gucken und aufpassen, dass es nicht einen negativen Effekt hat. Also, dass ich zum Beispiel auf einmal längere Zeit brauche, um meine Incidents zu debunken, weil ich den Code nicht mehr so gut kenne. Oder dass irgendwann dann so nach zwei, drei Monaten sich rausstellt, ich kann irgendwie die Codebase nicht mehr so gut erweitern, weil das Design vielleicht nicht mehr so gut ist, weil es war einfach so verführerisch, alles schneller zu machen mit dem Coding Assistant. Also das würde ich natürlich auch überhaupt nicht runterspielen.

Andy Grunwald (00:48:20 - 00:49:30)

Du hattest in deinem Talk und auch in einem Artikel, den du veröffentlicht hast, mal gesagt, okay, jetzt sind wir alle dabei, schneller Code zu schreiben. Und Codeschreiben ist ja nur ein Teil vom Softwareentwicklungsprozess. Du hast das als Teamsport bezeichnet, als hochkollaborative Angelegenheit. Und du hattest ein Diagramm erstellt, was so ähnlich wie so ein Wasserschlauch ist, wie so ein Gartenschlauch, wo dann in der Mitte auf einmal so eine etwas größere Blase entsteht. Und das ist dann die Coding-Time, weil wir sind ja jetzt alle schneller. dann kam die frage aber bringt es uns das wirklich wenn wir jetzt deutlich mehr code schreiben wenn aber vorne dran ein bottleneck entsteht oder hinten dran so nach dem motto können wir jetzt das backlog schneller füllen können wir den code den wir mehr producen auch schneller deliver. Und das bringt mich zu der Frage, weil wir haben sehr viel jetzt über Code-Generierung gesprochen, das bringt mich zu der Frage, was gibt es denn neben der Code-Generierung denn noch für Themen, die unter dem Begriff AI-Assisted-Delivery, Software-Delivery fallen? Weil das ist jetzt der Platz hier, aber ich hoffe, Da gibt's noch links oder rechts was.

Birgitta Böckeler (00:49:31 - 00:53:19)

Ja, bevor ich dazu komme, noch vielleicht ein Kommentar zu dieser Bottlenecksache, ne? Also, das ist auch so eine von diesen Sachen, die nicht unterschätzt werden sollten, dass man Software Delivery, ja, ist kollaborativ und man muss das weiterhin als ein System betrachten, ne? Also, was da passiert, die Prozesse, ne? Und das eben, wenn wir nur den Throughput vom Code erhöhen, was passiert dann mit dem Rest? Und zum Beispiel auch, was passiert mit meinem Review-Prozess, ne? In vielen Organisationen ist der Pull-Request-Review-Prozess heute schon ein Bottleneck. Wenn ich jetzt schneller Code produziere, wird das dann noch schlimmer. Also das heißt, und da gibt's ja dann nicht nur jetzt, dass ich an anderen Stellen, jetzt muss ich einfach auch AI für meine Reviews benutzen und dann wird das alles besser. Das funktioniert natürlich auch nicht immer. Man kann natürlich auch zurückfallen auf gute alte Praktiken, die wir auch haben. Zum Beispiel sind wir bei Vorex große Fans von Pair-Programming. Was halt Review just in time ist, während man zusammen den Code schreibt, was auch das entlasten kann, ne, diesen Prozess. Also einmal ist es, dass man natürlich jetzt nicht einfach nur überall anders hingeht und auch AI anwendet und dadurch wird der Throughput überall höher und dann wird alles besser, ne. AI hilft das potenziell, an manchen Stellen Artefakte schneller zu erstellen, also Output schneller zu machen. Aber das Artefakt ist ja nicht immer das, was wir brauchen. Also es ist ja oft die Reise hin zu dem Artefakt, also auch wenn wir Dokumentation schreiben oder sowas, ne. Und genau, das führt mich dann zu deiner Frage, was gibt's noch? Also Dokumentation ist vielleicht direkt das beste Beispiel. Wird auch viel drüber geredet, weil man eben weiß, dass Large Language Models eben gut sind im Formulieren, im Zusammenfassen, im Clustern von Informationen. Ich hab zum Beispiel mal irgendwie über 100 Commit-Messages an TGPT4 gegeben und es gebeten, die für mich zusammenzufassen. Und es war total gut darin, die auch zu clustern und richtig auch Zwischenüberschriften zu geben. Und ich hab das dann auch tatsächlich angeguckt, und es hat auch Sinn gemacht. Also sagen wir mal 90 Prozent hat Sinn gemacht. Also das heißt, da sind Large Language Models sehr gut drin. Das heißt, Art der Dokumentation, wo man sich vorstellen kann, wenn man Release Notes hat oder Change Notes, die man immer erstellen kann, dann kann einem das einen ersten Draft dafür geben. Auf der anderen Seite, Genau, bin ich auch bei mancher Art von Dokumentation eben skeptisch, weil ich glaube, dass da die Journey die Destination ist. Also, die Reise hin zu dem Artefakt. Also, wenn man zum Beispiel Architecture Decision Records schreibt, das ist für mich immer ein Prozess. Während ich das aufschreibe, merke ich auch noch, woran ich vielleicht noch nicht gedacht habe. Oder, oh, das ist so kompliziert, das zu erklären. Vielleicht ist es noch nicht simpel genug, was wir uns hier ausgedacht haben, ne? Also, das ist jetzt nur ein Beispiel. Das heißt, es hilft mir jetzt nicht, dass ich mir einfach zack, zack, ne Decision Record generieren lasse von einem Large Language Model. Aber was ich sehr interessant finde, ist so aus der Konsumentensicht von Dokumentation das Potenzial, weil ich ja jetzt auch die Möglichkeit habe, mir on the fly quasi Dokumentation generieren zu lassen, die ich ja noch nicht mal persistieren muss. Also sagen wir mal, es wäre möglich und ich habe das schon auch sagen wir mal, fast ganz gut hingekriegt, einmal mit dem Large Language Model mir ein Sequenzdiagramm generieren zu lassen von einem Teil vom Code. Und das ist normalerweise was, was sich nicht so richtig lohnt, irgendwie manuell zu machen. Es gibt natürlich auch Tools dafür, klar, aber vielleicht habe ich eine Sprache, wo ich gerade kein Tool habe oder ich bin zu faul, mir ein Plugin zu installieren und ich versuche es einfach mal schnell mit dem Large Language Model. Und dann gibt mir das halt einen aktuellen Stand vom Code oder sagen wir mal 80% korrekt, aber es hilft mir zu navigieren. Und dann schmeiße ich es einfach wieder weg. Also alles, was mit Dokumentation zu tun hat, die den aktuellen Status des Codes beschreibt und jetzt nicht irgendwie Historie oder sowas. Da kann ich on the fly eben Fragen stellen, wie ich vorhin schon gesagt habe, diese Workspace suche in Copilot Chat. Und krieg potentiell Antworten, die, wie gesagt, vielleicht 80 Prozent korrekt sind. Aber die mir schnell genug helfen, das zu finden. Und schneller, als wenn ich irgendwie in Confluence gehen müsste. Und schneller, als wenn jemand mal gesessen hat und drei Stunden das beschrieben hätte. Und zwei Monate später ist es nicht mehr aktuell.

Wolfi Gassler (00:53:19 - 00:54:06)

Was ich persönlich auch erfahren habe, ist, bisher so in der Zusammenarbeit mit anderen, dass grundsätzlich Kommentare im Code sehr stark ansteigen. Weil ich persönlich mach's auch so, ich starte mit Kommentaren. ich will das und das erreichen, dann kommt ein Vorschlag von Co-Pilot, der ist falsch, ich schreibe meine Kommentare um, um es klarer zu gestalten, bis dann der richtige, einigermaßen richtige Code dasteht. Und im Nachhinein entscheide ich, okay, machen die Kommentare noch Sinn, lösche ich manche Kommentare weg. Und ich habe das Gefühl, dass dadurch wesentlich mehr Kommentare im Code stehen und auch mehr sinnvolle Kommentare, weil ich durch diese Schleife durchgehe, dieses Kommentar noch mal zu verbessern, damit am Ende der richtige Code ausschaut. vielleicht mein Gedankengang auch mehr im Kommentar irgendwo drin ersichtlich ist schlussendlich.

Birgitta Böckeler (00:54:06 - 00:55:39)

Ja, ich sehe das so ein bisschen anders. Also GitHub sieht das auch als Feature von Copilot. Jetzt gibt es bessere Kommentare oder mehr Kommentare. Und für mich sind eigentlich viele Kommentare immer eher ein Smell. Also immer, wenn ich einen Kommentar schreiben will, dann frage ich mich immer, okay, brauche ich diesen Kommentar oder sollte ich den Code anders schreiben, sodass der besser lesbar wird? Weil Kommentare eben auch schnell nicht mehr aktuell sind, weil sie eben nicht Teil dessen sind, was ausgeführt wird, ne? Das heißt, das war eigentlich für mich immer so ein Dorn im Auge, dass man in Copilot so viele Kommentare schreibt. Ich hab die dann immer wieder gelöscht. Gleichzeitig ist natürlich, andersrum sind ja auch die Funktionsnamen, sind ja auch Teil des Proms. Das heißt, für mich ist es eher so der Vorteil, dass es mir hilft, expressivere Funktionsnamen und variablen Namen zu schreiben, weil je besser ich das mache, desto besser sind auch die Vorschläge, die ich von Copilot bekomme. Es ist aber inzwischen so, dass mit neuen Features in GitHub Copilot muss ich jetzt gar keine Kommentare mehr schreiben, weil es gibt jetzt so einen Inline-Chat, den ich jetzt normalerweise mal aufmache, und da tippe ich einfach ein meine Anweisung, die ich habe. Und dann gibt mir Copilot nicht nur neue Zeilen, sondern es kann mir auch Vorschläge machen, wie die nächsten beiden Zeilen geändert werden sollten. Also wenn ich zum Beispiel eine Zeile selektiere und sage, sortiere mir das mal nach ABCD, alphabetisch oder was auch immer, dann macht CoPilot mir einen Vorschlag, wie ich die Zeile ändern könnte. Aber dieser kleine Inline-Chat verhindert es jetzt halt auch, dass ich diese ganzen Kommentare noch schreibe überhaupt. Also deswegen, das ist für mich eher jetzt ein gutes Ding, dass ich keine Kommentare mehr schreiben muss für CoPilot.

Wolfi Gassler (00:55:40 - 00:56:18)

Ja, ist natürlich auch ein Fairpoint. Kommt immer drauf an, wie man es sieht und von welcher Seite man kommt. Aber um nochmal rauszuzoomen, weg vom Coding und wenn man diese Cycle Time betrachtet und du sagst, okay, 40% ist Coding, 60% ist alles andere und Andi und mein Lieblingsspruch ist ja immer, die Technik ist relativ einfach, das Schwierige ist der Mensch. Also gerade wenn man die anderen Dinge betrachtet, die dir ja niemand mag, Meetings unter anderem oder die Kommunikation, siehst du dort irgendwo Möglichkeiten, wo uns AI unterstützen kann in der Softwareentwicklung an sich? Jetzt schon vielleicht auch?

Birgitta Böckeler (00:56:18 - 00:59:15)

Ja, eine Sache, die wir gerade anfangen zu benutzen als Ansatz mit ein paar Kunden, ist die Idee von einem Team-Assistenten. Also nicht Coding-Assistent, sondern Team-Assistent. Also quasi eine kleine Applikation, die man im Team hat, wo ich hingehen kann, wenn ich bestimmte Tasks, bestimmte Aufgaben erfüllen muss. Also nehmen wir vielleicht mal das Beispiel Thread-Modeling oder User-Story-Writing oder sowas. Und diese Applikation gibt mir dann zwei Sachen. Das eine ist Prompts, also Prompts, die sich im Team vielleicht schon bewährt haben. Und diese Prompts helfen mir dabei, Practices, Praktiken zu benutzen, auf die wir uns im Team geeinigt haben. Und auch auf eine Art und Weise zu benutzen, wie wir uns im Team geeinigt haben, dass wir die machen wollen. Sagen wir mal, wir wollen im Team immer Given-When-Then-Szenarios schreiben in unseren User-Stories, und dann könnte das Teil des Prompts sein, dass mir dieser Prompt hilft, das genau in dem Format zu schreiben. Oder, sagen wir mal, für Thread-Modeling wollen wir immer das Stride-Framework benutzen. Das Stride-Framework sind so fünf Kategorien von Security-Threads, die man in Thread-Modeling benutzt, und dann hilft mir dieser Prompt, diese Praktik so anzuwenden. Also es ist eine Art und Weise, so ein bisschen so ein Alignment zu haben, und es ist einfacher für jeden zu machen, Dinge so auszuführen, wie wir uns drauf geeinigt haben, und vielleicht auch, wenn ich was noch nie gemacht habe, wie zum Beispiel Thread Modeling, hilft es mir auch, diese Fähigkeit aufzubauen. Das ist das eine, diese Prompts für Praktiken im Team. Und Standardisierung will ich nicht so richtig sagen, mehr so Alignment. Und dann das zweite ist, eben wieder zurückzukommen auf das Retrieval Augmented Generation. Ich habe dann auch in diesem Team Assistenten Wissensquellen. Also zum Beispiel die Security Guidelines in der Organisation. Oder in unserer Demo zum Beispiel haben wir martinfowler.com als eine Wissensquelle. Das heißt zum Beispiel, wenn ich irgendwie an einer Aufgabe arbeite und ich bin in meinem Chat drin und dann sage ich irgendwann, Was steht denn eigentlich auf martinfowler.com zu diesem Thema? Also, es ist so eins unserer Demo-Anwendungen, um diese Wissensquellen zu demonstrieren. Es kann natürlich auch irgendwie ein Teil vom Wiki sein, ja, also ein Teil, der ganz besonders kuratiert ist, und wieder Retrieval Augmented Generation. Man transformiert all diese Sachen in Embeddings und kann das dann eben in diesem Team Assistenten benutzen und es kann mir dann potenziell eben Wissen aus der Organisation und aus dem Team hochspülen, genau in dem Moment, wenn ich an einer Aufgabe arbeite. Oder wenn ich eine Story schreibe, gibt es vielleicht schon eine vorbereitete, kurze Beschreibung von meiner Domäne, sodass das immer mitgeschickt wird ans Modell und ich muss nicht jedes Mal meinen ganzen Kontext beschreiben. Und das ist so die Idee halt, Wissen im Team zu verbreiten. Was ich immer so ein bisschen fürchte, und das werden wir jetzt sehen, wie sich das rausstellt, ist, dass das nochmal wieder ein weiterer Grund ist für Leute, nicht mehr miteinander zu reden. Also es könnte auch nach hinten losgehen, weil es ist ja mit Remote- und Hybrid-Arbeit sowieso schon irgendwie weniger geworden. Aber genau, die Idee ist, dass halt Experten im Team über diese Prompts und über diese Wissensquellen halt sich ein bisschen mehr multiplizieren können.

Andy Grunwald (00:59:15 - 01:00:05)

Aber das, was du da beschreibst, klingt eigentlich nach Process Mining, beziehungsweise das Thema, wo ich auch meine Bachelorarbeit damals schreiben durfte, Software Repository Mining. Also eigentlich kontextbezogene Daten mit reinspülen und dann, ich sag mal, Mehrwert bei der Softwareentwicklung, beziehungsweise beim User-Story-Schreiben oder, oder, oder zu machen. Das scheint so ein bisschen völlig in die Richtung zu gehen, okay. Du hast jetzt wirklich deinen kompletten Pool, martinfauler.com, dein Wiki und so weiter. Und dann wird's dazugeschrieben, ja? Keine Ahnung. Bin mal gespannt, wohin das noch so alles führt, denn in manchen Bereichen ist diese ganze Thematik ja noch nicht so weit. Keine Ahnung, zum Beispiel, wenn es um Gesetze geht, Steuergesetz oder ähnliches. Gut, das heißt, Deutschland ist vielleicht auch nicht der Beste Anwendungsfall oder vielleicht doch, ich weiß es nicht, aber nur gut, schauen wir mal.

Birgitta Böckeler (01:00:05 - 01:00:59)

Ja und wichtig ist, glaube ich, da auch im Kopf zu behalten, dass es nicht immer um Fakten geht, es geht auch oft um Kreativität. Also wenn ich zum Beispiel eine User-Story schreibe und sagen wir mal, tatsächlich, ich bin jemand, die noch nicht viel Erfahrung damit hat. Wird auch an der Uni ja, glaube ich, immer noch nicht gelehrt, ich weiß nicht, ob es inzwischen anders ist. Aber ich kann zum Beispiel das Modell dazu bringen, mir Fragen zu stellen. Was ist denn eigentlich damit? Was passiert denn, wenn der Benutzer das macht? Kann man denn eigentlich das ausfüllen, ohne dass man ein Datum angibt? Und so kann ich irgendwie Lücken in meinem Denken entdecken. Also das Gleiche auch mit Architektur, ne? Also es ist schwer, dem Modell wirklich den ganzen Kontext von Architektur zu geben. Wir wissen, da ist immer sehr viel Trade-offs und Kontext ist ganz wichtig. Aber ich kann so fragen, ja, was ist denn ein Risiko oder eine Schwäche an dieser Architektur? Und vielleicht sagt es mir fünf Sachen und drei davon sage ich gleich, ja, ist Blödsinn, macht bei uns keinen Sinn. Aber da ist eine Sache, wo ich denke, ach, da habe ich noch gar nicht drüber nachgedacht. Also das ist auch ein Anwendungsfall, Kreativität und Brainstorming.

Wolfi Gassler (01:01:00 - 01:01:36)

Wenn du jetzt sagst, es hilft mir beim User Story entwickeln, dann würde mir ja sofort einfallen, weil als Engineering Manager liegen mir die Leute ständig im Ohr. Sie müssen mit diesem dummen Business da kommunizieren und irgendwie da die ganzen Infos reinholen. Dann wäre ja so der Traum wahrscheinlich für ganz viele EntwicklerInnen einfach, ich schicke dir so einen Chatbot zu meinem PO oder Kunden oder Business, was auch immer und der macht alles für mich und am Ende putzeln so die perfekten User Stories raus. Wie weit sind wir davon entfernt? Unabhängig davon, ob es gut ist oder schlecht. Ich bin auch ein großer Verfechter der Kommunikation an sich.

Birgitta Böckeler (01:01:36 - 01:01:48)

Ja, ich meine, das ist auch ein komplexes Thema, weil ich höre auch schon von vielen KollegInnen, die sagen, ja, aber Story is a placeholder for a conversation, um wieder ein Martin-Fowler-Quote-Zitat reinzubringen.

Wolfi Gassler (01:01:48 - 01:01:50)

Ja, aber es kann ja auch eine Chat-Konversation sein.

Birgitta Böckeler (01:01:50 - 01:02:44)

Genau, genau. Ja, und vielleicht will man auch gar nicht so detaillierte User-Stories, ne? Und ein Risiko ist auch Scope-Creep, ja? Sagen wir mal wieder den Archetypen von dem etwas unerfahrenen Product-Owner, der noch nie Stories geschrieben hat und der kriegt diese ganzen Fragen und denkt dann, oh Gott, ja, das müssen wir auch noch machen, das müssen wir auch noch machen, das müssen wir auch noch machen. Und auf einmal habe ich irgendwie eine Story, die irgendwie einen Monat braucht, ne? Also, das musste ich noch alles rausstellen, aber es ist auch eine interessante, hatte ich so noch gar nicht drüber nachgedacht, so dieses, wie können Entwickler irgendwie dann beitragen zu diesem Prompt, sodass der Product Owner bessere Stories schreiben kann, weil Entwickler schon mal so ein bisschen ihre typischen Fragen so ein bisschen, die dann in der Chat-Session hochkommen normalerweise, die so ein bisschen kodifiziert sind in diesem Prompt. Ja, wie weit sind wir davon weg? Ja, es ist schwer zu sagen, aber ich habe schon interessante Sachen gesehen.

Andy Grunwald (01:02:44 - 01:04:06)

Lass uns mal ein bisschen auf die Zukunft gucken. Wir haben ziemlich viel über die Gegenwart gesprochen, über die Möglichkeiten, aber auch über die in Anführungszeichen Risiken, würde ich mal sagen. Und eine Frage bei der Zukunft habe ich, die fange ich mit einer Story an. Zwar geht es um das Thema, welche Bedenken, du hast in Bezug auf die Anwendung von AI und wie wird sich die professionelle Softwareentwicklung verändern? Meine Story in Bezug dazu wäre immer, als die ganzen Hyperscaler, Cloud, GCP, Amazon usw. aufkamen, sind sehr viele Leute laut geworden, hey, verlernen wir denn jetzt alle eigentlich die Netzwerkverkabelung? Ja, Racks bauen und so weiter und so fort. Denn die ganzen Hyperscaler, die bauen ja die großen Datacenter, und die heuern ja die ganzen Leute an, die wissen, wie man Racks baut, wie man Netzwerkinfrastruktur aufbaut. Verlernen wir das bald alle, weil sie, die Hyperscaler, das Wissen bündeln und die Mittelständler dann keine entsprechenden Leute mehr finden, die dann, ich sag mal, die Co-Location racken können oder ähnliches? Und ist dieses Bedenken auch irgendwie transferierbar auf Verlernen wir Softwareentwicklung? Oder wie verändert sich die professionelle Softwareentwicklung? Ja, du hattest auch schon gesagt, die AI lernt auf Patterns, die schon da sind, ja, und innovative Softwareentwicklung haben wir auch schon ein bisschen drüber gesprochen. Also meine Frage ist eigentlich, welche Bedenken hast du in Bezug auf die Anwendung von AI und wie wird sich die professionelle Softwareentwicklung, ja, verändern? Ich sag mal im positiven oder negativen Sinne. Ich mein, ist natürlich Glaskugel, aber.

Birgitta Böckeler (01:04:06 - 01:05:09)

Ja, wir können auch nur spekulieren alle im Moment, ja. Also, ja, ein gängiger Gedankengang ist natürlich dieses, okay, ist das jetzt das nächste Abstraktionslevel, natürliche Sprache? Also, wir versuchen ja immer, unser Abstraktionslevel zu erhöhen, sodass wir als EntwicklerInnen uns nicht mit allen Details befassen müssen. Also, deswegen haben wir Programmiersprachen und Compiler. Und deswegen haben wir auch mit Codegeneratoren mal viel experimentiert. Das ist jetzt, glaube ich, nicht mehr so gängig. Deswegen gibt es Low-Code, No-Code-Plattformen und so weiter, ja? Und dann ist jetzt so der Gedankengang, okay, ist das jetzt das nächste Abstraktionslevel? Wir schreiben einfach natürliche Sprache und das macht dann alles für uns. Und ich bin da so ein bisschen skeptisch, dass es so einfach ist, dass es einfach das nächste Abstraktionslevel ist. Ich sehe das eher, ich sehe Gentle Fair Eye oder Large Language Models da eher so, Lateral an der Seite halt als Assistenten immer noch, ne? Also und die ich dann halt auf jedem Abstraktionslevel benutzen kann. Also ich kann die benutzen, um eine Low-Code, No-Code-Applikation zu erstellen, aber auch um Java-Code zu generieren, aber auch um, weiß ich nicht, noch niedrigeren, auf noch niedrigeren Abstraktionslevel Sachen zu machen.

Wolfi Gassler (01:05:09 - 01:05:12)

Also so ähnlich wie die Autovervollständigung von der IDE eigentlich.

Birgitta Böckeler (01:05:12 - 01:07:32)

Ja, und die beeindruckendsten Demos sind auch im Moment im Low-Code-No-Code-Bereich, was das so ein bisschen bestätigt. Also, dass ich halt einfach einen Absatz schreibe und dann kreiert mir das so eine Low-Code-No-Code-Applikation. Das ist natürlich sehr beeindruckend, aber gleichzeitig habe ich dann auch eine Low-Code-No-Code-Applikation mit den gleichen Einschränkungen. Also, dass ich weniger Kontrolle habe und weniger Also für halt die Use Cases, wo das funktioniert, wunderbar. Aber wenn ich halt was anderes brauche, muss ich halt im Abstraktionslevel wieder runtergehen, damit ich mehr Kontrolle bekomme. Deswegen bin ich so ein bisschen skeptisch, dass das einfach so Abstraktionslevel eins höher, sondern ich glaube, es ist ein bisschen komplizierter. Und deswegen glaube ich auch, dass Programmieren an sich und also die Verkabelung kennen sozusagen auch immer noch relevant ist. Also wir müssen ja immer so ein bisschen das nächste Abstraktionslevel unter dem kennen, was wir gerade machen. Es ist ja gerade auch so, dass man immer noch so ein bisschen verstehen muss, was passiert eigentlich bei Spring unter der Haube? Weil wenn ich manchmal da einen Stack Trace hab, muss ich trotzdem gucken, was da passiert. Was ich mich immer frage, ist, wie vielleicht unsere Designs und unsere Architektur sich ändern müssen, damit sie mehr promptable sind. Also damit sich das mehr eignet. Und das ist natürlich dann interessant, wie ist dann der Trade-off? Wenn ich das Design ändere, sodass es mehr sich dazu eignet, AI dafür zu benutzen, aber dann führt das vielleicht gleichzeitig zur Runtime, zu anderen Problemen. Aber das kann ich mir zum Beispiel vorstellen, wenn man sich so überlegt, im Backend haben wir immer dieses Controller Service Repository, ja? Sind immer die gleichen Patterns, ja? Also, wenn man wirklich so, solche Patterns hat, da kann ich mir schon eher vorstellen, dass man sowas vielleicht auch dann einfacher generieren und einfach zusammenstecken kann, als ich mir das zum Beispiel im Browser vorstellen kann. Weil der Browser halt, ja, nicht logisch ist. Ich wüsste nicht, wie ich ein Large Language Model erklärt sollte. Also sag ich jetzt mal so halb im Spaß, wie der Browser funktioniert. Deswegen, es kann auch sein, dass es in manchen Bereichen, in manchen Technologiebereichen, in manchen Layern einfacher sein wird, da mehr mit AI zu machen als in anderen. Und dann geht's aber am Ende immer noch um die Patterns, um die Design-Patterns, um die, wie man das zusammensteckt. Das heißt, eine Hypothese ist auch, dass sich halt einfach die Fähigkeiten, dass die überwandern so ein bisschen, dass man halt mehr, dass man das auf jeden Fall immer noch sehr gut verstehen muss und wenn nicht sogar mehr. Also, dass man vielleicht mehr Design-Arbeit und so was machen muss, als man sich tatsächlich mit der Syntax beschäftigen. Ich hab auch manche von der Basis, von der Basis-Syntax von Python hab ich immer noch nicht richtig gelernt, weil ich die ganze Zeit Copilot dafür benutze.

Wolfi Gassler (01:07:33 - 01:07:57)

Jetzt, meine Frage müsste ja eigentlich von Andis Seite kommen, aber wo siehst du denn die Felder, die nicht ersetzbar sind, so schnell zumindest oder was die schwierigsten Felder sind in der Softwareentwicklung und vielleicht dann auch die Felder, wo man vielleicht seine Zeit noch eher investieren sollte, die 10 Prozent, die man sich spart beim Coding, wo sollte ich die jetzt investieren oder auf welche Bereiche sollte ich mehr Acht geben?

Birgitta Böckeler (01:07:58 - 01:09:50)

Ja, gute Frage. Also ich sehe eigentlich jetzt, also ich finde es auf jeden Fall übertrieben, dieses ah, in zwei, drei, vielleicht sogar fünf Jahren müssen wir in manchen Bereichen gar keinen Code mehr schreiben. Das sehe ich irgendwie nicht. Also wie gesagt, das ist Spekulation. Vielleicht kann ich es mir einfach nicht vorstellen, wenn man 20 Jahre einen Job macht, dann kann man sich auch oft schwer vorstellen, dass es irgendwie anders wird. Aber ich habe mir das jetzt auch sieben, acht Monate angeguckt und ich sehe einfach zu viele, wenn man dann doch ins Detail geht, dann kommt man wieder auf so Sachen, ja okay, aber das muss ja auch alles irgendwie zusammen funktionieren und das muss sicher sein und das muss irgendwie ja, alles zusammenspielen. Also, wir kennen das ja als Entwickler, ne? Was da ständig, woran man alles denken muss heutzutage. Das war auch vor 20 Jahren noch alles viel einfacher, ne? Deswegen kann ich's mir eigentlich in den nächsten Jahren erstmal noch nicht vorstellen, dass es irgendwo ganz ersetzt wird. Wie gesagt, also ich glaube, dass es vielleicht in Bereichen, wo die Patterns einfach viel klarer definiert sind, dass es da einfacher sein wird. Also, ihr hattet dieses Back-and-Front-End-Beispiel. Und im Sinne von, wo man selbst für seine eigene Entwicklung investieren sollte, ist glaube ich wirklich einfach dieses Verstehen, wie alles zusammensteckt weiterhin. Also vielleicht ist sünntags halt nicht mehr so wichtig, aber war es ja vorher eigentlich auch nicht, oder? Also die Idee hat mir vorher auch schon viel geholfen und ich habe viel kopiert und so, ne? Und jetzt geht es halt einfach nochmal schneller. Und verstehen, also es ist so dieses, was viele gerade sagen, verstehen, wie die AI mir helfen kann. Also nicht sich von der AI ersetzen lassen, sondern jemand werden, der oder die gut mit der AI umgehen kann und auch weiß, wann hilft es mir und wann nicht. Also das benutzen einfach. Und wie gesagt, ich glaube, es ist jetzt hier und es wird auch bleiben und es wird auch noch besser werden. Aber es hat auch viele Risiken. Also wir haben auch über Qualität und so weiter gesprochen. Und deswegen ist es, glaube ich, wichtig, dass wir das alle benutzen und versuchen, die richtigen Wege zu finden, das verantwortlich zu benutzen und weiterhin guter Qualität.

Andy Grunwald (01:09:51 - 01:10:12)

Das hört sich gerade so ein bisschen so an, als willst du mir Hoffnung machen. Danke dafür, dass ich als Late Adopter doch noch eine Chance habe. Kommen wir zum Ende dieses Gesprächs. Und meine Frage wäre eigentlich, welche Empfehlung hättest du denn für Leute wie mich, die einfach Late Adopter sind? Die sich einfach mal zurückgelehnt haben, die ganze Chose beobachtet haben, weil da entwickelt sich ja unglaublich viel.

Wolfi Gassler (01:10:13 - 01:10:15)

Du meinst die Leute, die sich weigern, AI zu verwenden?

Andy Grunwald (01:10:15 - 01:10:38)

Das hab ich nicht gesagt, sondern es geht halt ... Naja, man schaut sich halt erst mal diesen Hype-Driven-Development an, weil ziemlich viele Hypes haben keine acht Monate überlebt. Und anscheinend ist das jetzt ein längerer Hype oder gekommen, um zu bleiben. Ich weiß es nicht. Schauen wir noch mal. Aber welchen Tipp würdest du denn solchen Leuten wie mir geben, okay, ich muss jetzt langsam mal, ja?

Birgitta Böckeler (01:10:38 - 01:10:51)

Also, ich würde sagen, mit Coding Assistance anfangen. Also, wir reden die ganze Zeit über das Produkt, aber es ist leider das reifste und der Marktführer GitHub Copilot ist, würde ich schon sagen, von allem, was ich gesehen habe, aktuell das Beste.

Wolfi Gassler (01:10:52 - 01:10:55)

Der große Vorteil ist ja, dass alle Produkte irgendwie Copilot heißen.

Birgitta Böckeler (01:10:55 - 01:10:56)

Ja, das ist der große Vorteil.

Wolfi Gassler (01:10:56 - 01:11:00)

Das heißt, die überall aus allen Ecken sprießen, die heißen alle irgendwie Copilot.

Birgitta Böckeler (01:11:00 - 01:11:55)

Noch viel besser, es gibt auch Codium und Codium, eins ist mit E geschrieben und eins ist ohne E. Und es gibt Cody und Cody, eins ist mit E geschrieben und eins ist nicht mit E geschrieben. Ja? Also es ist alles sehr kreativ. Aber das ist auf jeden Fall der No-Brainer, der Einstieg, würde ich sagen. Weil es eben schon relativ weit fortgeschritten ist. Du kannst relativ schnell sehen, was das Potenzial ist und es einfach im täglichen Doing benutzen. Also ich meine, bei uns in der Beratung, wir müssen natürlich immer darauf achten, dass unsere Kunden zum Beispiel uns das erlaubt haben, es zu benutzen. Weil man darf nie vergessen, dass es Drittanbieter sind, wo der Code hingeht. Das heißt, für wen auch immer man arbeitet, also Arbeitgeber oder Kunde muss zugestimmt haben, dass man das benutzt mit deren Codebase, ne? Also ich weiß nicht, woran ihr gerade arbeitet, aber das wäre was, wo man, was man im Hinterkopf behalten müsste. Aber ja, das einfach benutzen und sich vielleicht, ja, dass man mal ein paar Beispiele bekommt, wo man sieht, oh ja, jetzt verstehe ich, wie das funktioniert.

Andy Grunwald (01:11:56 - 01:12:09)

Okay, dann verspreche ich hier im Podcast, dass zumindestens bis die Episode released ist, die wir jetzt gerade aufnehmen, habe ich auf jeden Fall schon mal GitHub Copilot gestartet und mindestens mal einen Unitester mitgeschrieben oder ähnliches.

Wolfi Gassler (01:12:10 - 01:12:21)

Vielleicht noch von der anderen Seite. Hast du irgendeine Empfehlung für Leute, die absolut hyped sind und glauben, alles wird ersetzt und nur mehr alles mit AI machen? Einfach weitermachen oder ... Na ja, klar.

Birgitta Böckeler (01:12:21 - 01:12:58)

Also, immer mit einer gesunden Portion Skepsis weiterhin, würde ich sagen. Und halt immer dran denken, im Genitive-AI-Bereich ist es sehr leicht, eine beeindruckende kleine Demo zu zeigen. Also, ich hab mal irgendwo ... Hat das mal jemand Party-Trick als Party-Trick bezeichnet? Und dann will man, guck mal, und jetzt hat man die User-Story. Und dann guckt aber keiner so genau drauf, was da eigentlich rauskommt. Also immer, ne, also über die Demos und den Party-Trick hinausschauen und wirklich überlegen, was bedeutet das wirklich im täglichen Geschäft, wenn man wirklich in einem Team zusammenarbeitet. Und hilft mir das da jetzt wirklich oder ist das einfach nur so ein kleiner beeindruckender Trick?

Andy Grunwald (01:12:59 - 01:13:58)

Birgitta, vielen lieben Dank, dass du dir die Zeit genommen hast, unsere zwei Lager oder Extreme hier etwas zusammenzuführen. Also ich bin dir noch eine Antwort schuldig. Ja, du hast mich etwas mehr begeistert. Ich bin jetzt aber, muss ich zugeben, es ist natürlich sehr schwer, ein skeptisches Lager komplett in den Hype zu treiben innerhalb von einer Stunde. Aber du hast es geschafft. Und vielleicht muss ich einfach mal jetzt. Es ist jetzt nicht so, als möchte ich nicht, sondern ich hab's einfach nicht gemacht. Du kennst das nicht, es ist nie wichtig genug. Aber vielleicht muss ich noch. Vielen lieben Dank, dass du dir die Zeit genommen hast, dass du bei uns hier im Engineering-Kiosk mit dem Thema vertreten warst. Wir verlinken natürlich all deine Artikel und alle Ressourcen, die wir auch erwähnt haben und auch die Ressourcen, die du erwähnt hast, unten in den Shownotes. Und natürlich auch, wo man dich mal vielleicht kontaktieren kann oder wo man natürlich zum Beispiel jetzt mal deine Memos verfolgen kann, über die wir auch gesprochen haben. Verlinken wir natürlich auch. Hast du noch irgendetwas, was du unseren Hörerinnen und Hörern mitgeben möchtest?

Birgitta Böckeler (01:13:58 - 01:14:21)

Ich habe schon so viel geredet und schon so viel mitgegeben. Ich hoffe genau, wie wir am Anfang gesagt haben, dass vielleicht die unter den HörerInnen, die mehr skeptisch auf Andis Seite waren, vielleicht jetzt doch ein bisschen mehr sehen. Okay, vielleicht ist da doch ein bisschen mehr. Aber auch die, die vielleicht gedacht haben, das ändert jetzt alles in fünf Jahren, auch vielleicht ein paar neue Einsichten bekommen haben, woran sie vielleicht noch nicht gedacht hat.

Andy Grunwald (01:14:21 - 01:14:24)

Danke nochmal, Grüße in die deutsche Hauptstadt und bis zum nächsten Mal.

Wolfi Gassler (01:14:25 - 01:14:36)

Tschüss. Ciao. Und nicht vergessen, wenn du die Bildung von morgen gestalten willst, schau bei unserem Episodensponsor, der IU, vorbei. Links in den Show Notes.