All Episodes

Robi, what could possibly go wrong? Hast du dich das auch schon mal gefragt?

Ja, ich hab mich gefragt, wenn der AI kaputt ist, wenn ich es wieder schaffe, normal mein, mein Arbeitsalltag und mein Leben auf die Reihe zu kriegen. Aber ich glaub, das meinst du nicht.

Nee, nee, genau, also diesen Satz 'What could possibly go wrong?' Wir haben den in der Softwareentwicklung früher mal benutzt, sozusagen als Mutprobe. Ja, komm, lass mal die point. Ja, nee, weiß nicht, ja, aber could possibly go wrong und los geht es, weißt du so. Und die Frage ist tatsächlich einfach im Grunde genommen, wenn man sie sich ernsthaft stellt, ist sie super wichtig. Ja, und genau in der, über dieses Thema wollen wir in einer heutigen Episode sprechen und zwar über das Thema Threat Modelling.

Sehr cool. Ich glaub, du weißt mehr als ich darüber. Ich bin sehr gespannt.

Genau, also willkommen bei Tobi hoch 2 doppelt Tobi Doppeltag, heute zum Thema Threat Modeling und vielleicht gleich mal vorweg Threat Modeling, also Threat mit T. Ja, es ist die Bedrohung und nicht der der Faden, über den wir reden. Und es geht um Bedrohungsmodellierung. Ja, und es geht um um Sicherheit. Es geht um, wie kann ich meine Software oder mein Projekt sicher machen? Ja, und was was bedeutet das alles? Ja, und wie kann man, wie kann man damit loslegen? bist du denn schon mit dem Thema mal in Berührung gekommen?

Ja, klar, wer nicht, glaub ich, oder man hat irgendwie Software zu Pentestern gegeben und hat sich dann darüber unterhalten, was die so alles gefunden haben. Was ich persönlich immer glaube, was zu zu kurz gekommen ist, ist ganz oft der Sinn und Verstand. Also dieses, was will ich denn überhaupt schützen? Ja, also welche Daten hab ich denn da so was auch immer für einer Software. Und blödes Beispiel, wenn ich jetzt eine Software habe, wo ich einen Mercedes bestellen kann oder ein anderes Auto, dann ist die Frage, muss ich da überhaupt was schützen in der Konfiguration? Weil am Ende ist ja wahrscheinlich eh alles irgendwie public, was ich da auswählen kann. Also die Frage ist, was kann mir da jetzt ein Angreifer am Ende klauen oder welche Daten will er vielleicht haben? Aber das war immer ganz ganz oft halt dieses Problem, wenn man über Security nachdenkt, dass das nicht immer so gesehen wurde, ne. Es wollte, wurde immer quasi so, wir bauen einfach 'n Zaun drum rum, in Anführungszeichen, und dann haben wir einfach alles geschützt. So, und da war ich jetzt nicht immer 'n Freund und hab gesagt, vielleicht müssen wir ja nicht alles schützen, ne. Also, der Schalterraum in der Bank, den muss ich jetzt vielleicht nicht so hoch absichern, ja, weil der Tresor, da ist eigentlich das Wichtige drin, in Anführungszeichen.

Ja, aber auch da, also du hast ja vorhin schon Pentesting oder Penetration Tests als Stichwort gegeben. Das ist eigentlich super, weil in der klassischen, also klassisch im Sinne von, so haben wir das früher immer gemacht, Ablauf ist ja, wir haben Entwickler, die entwickeln was und dann wird getestet und dann gibt es vielleicht Security Tests und am Ende gibt es noch ein bisschen Dokumentation und dann sind wir fertig. Das ganze Thema Threat Modeling setzt aber viel, viel früher im Prozess an und zwar ist die Idee, dass du Leute hast, die dieses System bauen. Also es ist eigentlich völlig egal, ob es der Tresor einer Tresor um einer Bank ist oder die Konfiguration eines Autoherstellers, ja, die stellen sich mal vors Whiteboard und überlegen sich, hm, wie kriegen wir unsere Software denn jetzt kaputt gespielt, ja, und genau das meinte ich auch am Anfang mit diesem Satz, what could possibly go wrong, weil das im Prinzip eine Gedankenübung ist von denjenigen, die es bauen, dass die einfach mal versuchen, eine andere Perspektive auf ihr eigenes Projekt einzunehmen und zu gucken, wie würde ich denn, wenn ich Angreifer wär, mit dem Wissen, was ich jetzt über diese korrekt habe, ja, wie würde ich daran gehen, um das Ganze kaputt zu machen, ja, oder was zu erbeuten und Tresorraum ist ein schönes Stichwort. Es gab ja vor einiger Zeit diesen Einbruch in in dieser einen Bank, wo die Leute einfach durch den Keller gekommen sind, einfach ein Loch in die Wand gebohrt haben. Ja, und das ist ein schönes Beispiel, die haben wahrscheinlich eine Tür gehabt, die war verschlossen, die haben wahrscheinlich eine dicke Tresortür gehabt. Also, wie du gerade gesagt hast, der Zaun sozusagen um das eigene Grundstück und damit kann nichts passieren, die Angreifer haben aber einfach ein anderen Weg gefunden, in den Raum zu kommen. Ja, und das Ganze war halt ein dicker Boa und genau also diese Frage, what could possibly go wrong, versucht man halt mit Threatmodeling systematisch und und frühzeitig zu erkennen, ja, was schiefgehen könnte. Und das ist die ganze Idee, dass man das Ganze sehr, sehr frühzeitig im Prozess hat. Also Shift-Left ist hier wieder das Thema Shift-Left-Security und dass man versucht, von Anfang an an Security zu denken, eine Perspektive eines Angreifers einzunehmen und sich auch überlegt, was kann ich denn erbeuten. Ja, also der beim Tresorraum ist es ziemlich offensichtlich, das was im Tresorraum gelagert ist, aber wie du schon gesagt hast, die Konfiguration eines Autoherstellers oder so, da könnten Identitäten drin sein, da könnten Sachen drin sein, die vielleicht schon im Konfigurator, aber noch nicht auf dem Markt sind. da könnten Sondereditionen drin sein, da könnte man vielleicht was bestellen, was es gar nicht gibt in der Kombination. Also da gibt es schon genug Schabernack, den man anstellen könnt. Und ja, Teil der Denksportaufgabe, sich diese Frage zu stellen, absolut, das ist Teil der Denksportaufgabe. Ja, was, was könnte man denn damit machen und vor allen Dingen, ja, was, was kann ich erbeuten, was kann ich kaputt machen und da ist halt auch einfach auch relevant für für alle Entwickler und auch nicht nur für Security Experten, weil wir kennen kenn das ja ganz typischerweise auch von Bugs, je früher etwas erkannt wird, desto preiswerter ist es halt zu fixen. Ja, das was für Defekte gilt, gilt halt natürlich auch für Security und wenn man ein Security Problem frühzeitig erkennt, ist es vielleicht einfacher, als wenn man die gesamte Architektur auf links drehen muss.

Ja, also du meinst, bleiben wir bei der Bank, ich sollte jetzt nicht ein Gebäude bauen mit einem Stararchitekten für Design und dann, wenn das Gebäude da ist, sich mir darüber Gedanken machen, wie baue ich denn jetzt noch Sicherheit ein, sondern vielleicht von Anfang an, was wollen wir schützen, wie bauen wir das und wie müssen wir vielleicht ein sicheres Gebäude und wie könnten Angreifer da reinkommen et cetera uns überlegen und dann entsprechend uns halt absichern, um das dann auch richtig sicher zu machen.

Spannend. Auch bei dem Bankbeispiel ist einfach, ich sag mal, der Keller wurde ja an sich als sicher definiert, weil da ist die Erde drumherum oder da ist ja ein Kellergewölbe drumherum. Also da kann ja gar nichts passieren und auch da haben wir gesehen, hm, es kann ja anscheinend doch was passieren. Genau, aber reden wir mal drüber, was Threat Modeling eigentlich ist. Also noch mal die 2 Worte, Threat Bedrohung und Modeling ist halt die Modellierung von einer Bedrohung und ja, es ist halt eine, wie wir schon gesagt haben, eine Denksportaufgabe und man kann das im Prinzip relativ einfach machen. Also man kann sich ans Whiteboard stellen, vielleicht auch in als regelmäßige Übung und einfach mal überlegen, was kann man denn tun, wie kriegen wir es denn kaputt gespielt, sozusagen. Und man kann das Ganze aber auch strukturiert machen und strukturieren im Sinne der der Modellierung wär eine Zeichnung und man macht das typischerweise so, dass man ein Datenflussdiagramm macht. Also man hat vielleicht eine 3 t Architektur in der Softwareentwicklung und hat die womöglich auf verschiedenen Systemen laufen, vielleicht sonst vielleicht haben wir eine Datenbank als vielleicht Past Service am Ende und dann haben wir ein Kubernetes in der Mitte und und vorne haben wir ein Frontend drauf und dann hat man natürlich die Datenflüsse und dann vielleicht noch sowas wie so ein Active Directory, wo es dann den weiteren Authentifizierungsfluss gibt und so weiter. Und letztendlich hat man halt immer einen Bruch der Stelle, wo ein Datenfluss von einem System aufs andere übergeht. Ja, das ist so eine so eine typische Bruchstelle und da kann man sich überlegen, was kann denn da schief gelaufen an der Stelle. Also Nehmen wir mal ein ganz einfaches Beispiel, wenn wir zwischen Browser und Backend nicht verschlüsseln, was kann denn da schiefgehen?

Man in the Middle, jemand fängt alles ab, jemand könnte sogar Informationen austauschen, jemand kann mitlesen, mitlesen. Genau, also eine Menge.

Genau, und das ist auch nichts, was ganz abstrakt nur in der Softwareentwicklung relevant ist. Das ist ja auch für normale Altersgegenstände extrem relevant. Also nehmen wir mal den Schlüssel, diesen Funkschlüssel, der dein Auto womöglich entsperrt. Ja, was würde denn passieren, wenn das nicht verschlüsselt ist oder wenn da jemand ein Man-in-the-Middle-Angriff macht und auf einmal dein Auto aufmachen kann? Ja, da kann natürlich folgen, da kann natürlich Inhalt des Autos klauen, da kann das Auto womöglich gestartet werden, womöglich wegfahren und also da merkt man einfach, wenn man das so ein bisschen abstrahiert und einfach auch auf Prozesse in der realen Welt abbildet, wie die Sicherheitsprüfung am Flughafen oder das eigene Auto, ja, oder Ampelsteuerung oder sowas, da kann man halt immer, wenn man sich fragt, what could possibly go wrong relativ viele Beispiele finden, wo ganz schnell ganz viele Sachen falsch laufen.

Ja, das stimmt, wobei man oft auch nicht immer an alles denkt, das ist ja auch so ein sieht man jetzt ja auch in der jetzigen Zeit oder mit A.I., ne. Also vieles, was früher irgendwie so nach dem Motto, ha, das wird keiner machen, weil da musst du irgendwie 4 Wochen sitzen und da irgendwie keine Ahnung was ausprobieren, macht halt irgendwie so 'n A.I. Agent in Minuten, halben Stunden, was auch immer. Und auf einmal sind Szenarien möglich, die waren früher eher unwahrscheinlich.

Ja, umso wichtiger ist, dass man sowas wie Threatmodeling macht und sich überlegt, wie das hier aus, wie das aussehen könnte, weil es geht ja am Ende auch immer nur darum, die Hürde für die Angreifer möglichst hoch zu legen. Ja, also dass die Angriffe möglichst möglichst teuer werden und teuer kann ja heißen, das kostet extrem viel Geld oder kostet extrem viel Tokens oder was auch immer. Aber kommen wir noch mal zu der Modellierung zurück. Wir machen uns Gedanken darüber, was potenziell schief gehen kann. Also es gibt so ein paar zentrale Fragen. Also, Frage 1 was bauen wir überhaupt? Also, wir haben, wir haben eine Systemarchitektur, wo ich schon gerade als Beispiel gesagt hab, wir haben beispielsweise eine 3 t Architektur, vielleicht noch mit einem Active Directory, vielleicht noch mit ein paar anderen Systemen drumrum, Caching, was auch immer, und haben erstmal eine Architektur des aktuellen Systems und überlegen uns, wo fließen denn überhaupt die Daten zwischen diesen einzelnen Bereichen. So, und was kann da schief gehen? Das ist schon Frage 2. Ja, kommen wir gleich dazu, es gibt eine Klassifizierung von Bedrohung, die nennt sich Stride im Threatmodeling, da steht jeder Buchstabe steht für eine Bedrohung und man kann sich halt überlegen, was kann da an an jeder Stelle schief gehen und das hilft natürlich auch, wenn man die Bedrohung klassifiziert hat, eine entsprechende Gegenmaßnahme zu finden und das ist schon die Frage 3. was Was machen wir da dagegen als Gegenmaßnahme? Und in dem Moment, wo wir eine Klassifizierung haben, ich hab ja gerade das Beispiel gegeben, wo ist der oder wo ist das Problem, wenn zwischen Frontend und Backend die Verbindung nicht verschlüsselt ist, dass jemand mitlesen kann. Das ist die Bedrohung, die Gegenmaßnahme ist natürlich hier Verschlüsselung einführen oder S. S. L. oder sowas. Ja, und dann natürlich am Ende idealerweise auch noch mal, wenn man das in einer Form validieren kann, ist die vierte Frage, haben wir das denn eigentlich richtig gemacht? wie gesagt, das findet man überall in der realen Welt, das findet man also, was mir immer prominent einfällt, ist die ist die Schlange am Flughafen, wo ganz klar ist, sozusagen, wie der in diesem Fall nicht Datenfluss, sondern der Menschenfluss durch die Schlangen ist, was da genau passiert, dass man irgendwie seinen Rucksack aufmachen muss und sein Laptop rausholen muss und so weiter. Und da werden die Ingenieure, die das Ganze gebaut haben, was ganz, ganz Ähnliches gemacht haben.

Und wenn man das jetzt baut, dann überlegt man sich quasi, O. K., wir müssen zum Beispiel jetzt S. S. L. einsetzen oder halt irgendwie Encryption und also es geht da drum, quasi schon ein richtiges Design, eine richtige Architektur zu finden, um dann so, wie du gesagt hast, die Schwierigkeit zu erhöhen, für einen Angreifer Dinge zu tun.

Idealerweise muss man auch keine Architektur finden, idealerweise ist es ja die eigene Architektur und man versucht ja eigentlich auch nur noch die Schwachstelle zu finden. Also wir bauen ja jetzt nicht ein, ein, eine eigene Architektur für so ein Szenario auf, sondern haben eine bestehende Architektur und versuchen die auf auf Herz und Nieren zu prüfen, um mal zu gucken, was denn schief gehen kann in diesem Fall. Ja, und es gibt zum Beispiel auch noch so ein Konzept, das nennt sich Trust Boundaries. Ja, und die Idee ist, alles was innerhalb von einer Trust Boundary ist, vertraut sich. Ja, also schönes Beispiel wieder beim Flughafen, sobald du durch die Sicherheitskontrolle durch bist, kommt typischerweise keine zweite Sicherheitskontrolle. Also alles das, was da drin ist, dem wird vertraut, egal ob es ein Passagier ist, der durch die normale Schlange gekommen ist, oder ein Personal Mitarbeiter, der quasi über den Personaleingang reingekommen ist und auch gescannt wurde, oder der Mensch von der Sicherheitsfirma, der da arbeitet. Ja, das ist diese Idee in der Trust Boundary und in der Softwarearchitektur haben wir das auch, so dass wir sagen, zum Beispiel die Flüsse innerhalb der Datenbank betrachten wir nicht. Also man kann das ja im Prinzip von der Granularität immer und immer weiter aufdröseln, bis man in der Kommunikation zwischen beispielsweise Prozesse und Speicher wäre oder so. Aber das macht man typischerweise nicht, weil es einfach viel zu komplex ist, dass man am Ende sagt, es gibt Trust Boundaries und alles innerhalb dieser Trust Boundary dem vertraut. Ja, genau und immer dann, wenn es halt so eine quasi so eine in der Zeichnung ein Kreuz gibt, also ein Datenfluss, verlässt eine Trust Boundary oder kommt zu einer Trust Boundary an, dann ist das der Fall, wo man einfach gucken kann, was, was passiert denn da oder was könnte denn hier schiefgehen. Ja, ja, genau, auch das Beispiel zum Beispiel A.P.I.s ist extrem spannend. Es gibt ja immer diesen schönen Satz, man traut nichts, was aus dem U.I. kommt. Das heißt, der, das was hinten an der A.P.I. ankommt, kann ja von der vom U.I. kommen. Es kann aber auch von einer von einem Drittsystem kommen, was einfach nur diesen Request auslöst und diesen Request manipuliert. Ja, und genau, das ist das beste Beispiel, dass man einfach an jeder Stelle da validieren muss und auch das ist im Grunde genommen die Konsequenz von von Threat Modeling. Ja, und zur Klassifizierung, es gibt ein ganz bekanntes Framework, ich hab ja gerade schon den Namen gesagt, Strite heißt das und jeder Buchstabe steht ja für etwas. Also das S. steht für Spoofing, ja, das ist die Identitätsfälschung. Also ich geb mich für dich aus, beispielsweise, ja, oder ich, ich versuche vorzugeben, Admin zu sein oder in der realen Welt. gehe ich vielleicht als paketdienstleistender Fahrer in eine Firma rein und sag, ich hab hier ein Paket für Herrn Meyer oder irgendwie sowas. Ja, also das ist ja im Prinzip auch eine Identitätsfälschung, weil weil man wohl wirklich durchgelassen wird, weil man vorgibt, jemand anders zu sein. Ja, das T. Tempering, das ist die Datenmanipulation. Das heißt, die Daten, die durch das System fließen, sind nicht mehr in dem Zustand, wie sie eigentlich sein sollten. Also jemand anders hat was hinzugefügt, hat vielleicht einen anderen Payload, nimmt was mit, was er nicht nehmen darf, sowas entsprechend. Ja, das ist Tempering.

Aber es geht darum, wirklich dann Daten zu manipulieren oder sie auch einfach abzugreifen oder?

Abgreifen ist das I. tatsächlich, das ist Information Disclosure, das ist die Informations Preisgabe.

Aber ich könnt zum Beispiel jetzt irgendwie Daten, ja, mich auch wieder ausgeben als bin und irgendwie die Daten manipulieren. Oder ich könnte versuchen, meinen Kontostand höher zu machen und dann geht vielleicht die Überweisung noch durch oder irgendwie so ein Quatsch.

Also O. K., genau, oder du könntest versuchen, jemand anderen zu schaden, indem du sich als als diese andere Person ausgibst und irgendetwas in einem internen Chat schreibst, was vielleicht nicht zitierfähig ist.

O. K., O. K.

Ja, dann gibt es die Repudiation, das ist die Abstreitbarkeit, Rückbarkeit. Also die Frage ist ja immer, ob denn das, was du da, was du da machst, abgestritten werden kann. Also dass du quasi Spuren verwischst, sowas Entsprechendes, ja.

Also nicht Rückverfolgbarkeit und dass du halt einfach eine weiße Weste hast am Ende.

Eine weiße Weste, genau. Also du könntest ja auch Logging-Mechanismus versuchen auszuschalten oder Ähnliches, ja. Das wäre was Typisches.

Dass es keine keine Logs gibt, einfach auch vielleicht den Angriff gar nicht, dass er gar nicht so auffallen kann. Ja, ich greif an, mache irgendwas und versuche jetzt vielleicht nur gutartige Logs zu erzeugen und gar nicht irgendwas, wo jetzt dann steht, hm, da ist was komisch und dann kann ich vielleicht diesen Zugriff oder was auch immer ich da erbeute oder das länger nutzen. Das hört man ja auf, dass Hacker viel länger im Netzwerk waren, Als als es dann aufgefallen ist, ne? Also, dass die dann schon ein, 2 Monate da waren und sich quasi so Abstreitbarkeit oder Repudiation mäßig verhalten haben, um einfach nicht auffällig zu sein und dann quasi viel mehr Infos zu bekommen und rauszufinden, was können wir denn wirklich da erbeuten oder mitnehmen oder über die Zeit viel mehr mit zu leben zu können, ne? Und es gibt auch so Angriffe, die sind richtig, richtig krass, da haben Angreifer. ganz lange Zugriff auf deine Mailbox, aber sie nutzen das nicht. Sie warten quasi, und ich meine, mit AI ist das relativ einfach, ich meine, AI kann ja Kontext in E-Mails verstehen, also sie lesen immer deine Mailbox quasi mit, und wenn dann etwas kommt, wo sie merken, oh, jetzt lohnt es sich, dann geben sie sich zu erkennen und benutzen quasi den Zugriff auf deine Mailbox und fangen zum Beispiel diese Mails ab und fangen dann an, irgendwelche Verträge oder Kontonummern auszutauschen. Und auf einmal fragt jemand, hey, wo ist denn das Geld? Und da ist mir noch ein anderes Konto gegeben und das Geld ist weg. Und das ist gang und gäbe, das ist echt crazy. Also wieder Hinweis auf unsere Folge mit dem Passwort-Save. Benutzt Passkey am besten überall und labert nicht lange rum, dass das alles so schwierig und blöd ist.

Und also spannend, vielleicht nochmal als ganz konkretes Beispiel, ich hab die Tage, hab ich auf meinem privaten E-Mail-Account eine Spam E-Mail bekommen, wo der Absender vorgegeben hat, dass das mein Hoster wäre und ich müsste doch wegen einer NIST 2 Anpassung meine Domain noch mal verifizieren oder irgendwas. Ja, so die sah 1 zu 1 richtig gut aus. Ja, und ich musste also wenn man da drauf geklickt hat, ist man halt zu diesem Login gekommen, wo man halt also an der URL erkannt hat, das ist nicht letztendlich der Hoster, aber inhaltlich sah das absolut richtig aus. Ja, und man hätte dann das Passwort eingegeben, was wär denn da passiert oder was ist da passiert? Da hat man natürlich einerseits Identitätsdiebstahl begangen, so weil das Portal sah halt sehr, sehr ähnlich aus. Die hätten dann mit meinen Credentials sich angemeldet an dieser am Backend. Ja, und das hätt ich natürlich nicht abstreiten können, dass ich das dann womöglich gewesen wär hinterher, wenn sie das gehabt haben. Also ist tatsächlich einfach auch 'n gutes Beispiel, dass es auch mehrere Sachen natürlich hier betreffen.

Ja, können wir nachher noch diskutieren. Ich glaub, einer der Punkte ist halt, wie geh ich denn mit Usern um und ich glaub, das ist, glaub ich, der größte Angriffsvektor heutzutage, die die Faulheit oder die Bequemlichkeit von Menschen, ohne jetzt jemandem nahe zu treten zu wollen. Ja, aber glaub, das ist etwas, das ist das größte Problem aktuell, was wir so haben.

Aber gehen wir noch mal kurz weiter durch, wir waren ja beim S. T. und R. I. ist Information Disclosure, also Informationspreisgabe, das heißt, dass die Daten einfach abgezogen werden, dass sie dann womöglich einen neuen Preis bekommen im Darknet und dass einfach Leute diese Informationen haben, die sie nicht haben. Dann gibt es das D. im Strike, das ist Denial of Service, das ist die Dienstverweigerung. Also man kennt ja das als Stichwort Denial of Service Angriff, dass man beispielsweise so viele Requests an ein System schickt, dass das System da drunter unter dieser Last kollabiert. Genau, auch das könnte natürlich passieren in meinem Beispiel mit dieser 3 T. Architektur und Browser vorne dran, kann das natürlich sein, dass irgendjemand über so ein Botnetz zum Beispiel das Backend einfach angreift, ja, und da ganz viele Requests schickt. Was kann man da wiederum gegen machen? Man könnte natürlich ein Proxy davor schalten, man könnte ein Caching einschalten und so weiter. Und das ist halt auch wieder wieder genauso markiert als Denial of Service. Was tun wir dagegen? Entsprechend ein Mechanismus, wie zum Beispiel eine D.D.O.S. Firewall davor schalten, die so eine Attacke abwehrt. Und das letzte Elevation of Privilege, das ist die Rechteauswertung, also Ausweitung, sorry, also wenn ich es irgendwie schaffe, mehr Rechte zu bekommen, als ich eigentlich haben dürfte, ja, also sowas wie, ich sag einem Kollegen, gib mir mal bitte den Schlüssel für den Serverraum, ich muss da mal gerade was machen, ja, das ist ja sowas in einer typisch analogen Welt, ja, der Es darf natürlich nicht passieren, dass jemand, der einen bestimmten Schlüssel hat, den einfach so weitergibt. Oder halt entsprechend ein Recht im System, etwas zu ändern, was ich einfach gar nicht haben darf. Das kann ich natürlich auch von mir ruhig erbeuten. Und genau, es gibt für jedes einfach wahnsinnig plastische Beispiele in der echten Welt. Also wir haben ja vorhin über das Auto Keylers sozusagen gesprochen, also wenn jemand, der nicht das Recht hat, mit dem Schlüssel mein Auto zu öffnen, das darf, ist das natürlich auch schon wieder eine rechte Ausweitung, genauso wie es natürlich in der Softwareentwicklung, dass das ganz typisch ist. Ja, und sobald man das zusammen hat, also wir haben jetzt uns ein Modell aufgezeichnet, wir haben mit Strite Bedrohungen klassifiziert, das ist so der der Moment, wenn man das Ganze beispielsweise mit seinem Team am Whiteboard gemacht hat, wo man sich überlegen kann, hey, welchen Mechanismus führe ich denn jetzt ein um genau diese Bedrohung abzuwenden. Weil in dem Moment, wo man, sagen wir mal, wir haben System, wir haben 10 Bedrohungen identifiziert und hat gegen diese 10 Bedrohungen jetzt schon eine Gegenmaßnahme definiert und führt diese auch ein und setzt sie entsprechend um, dann ist es ja so, dass derjenige, der das System angreifen möchte, schon mal mindestens, ich sag mal, über diese 10 Hürden springen muss, um überhaupt die Hälfte zu finden, typischerweise.

Also ich erschwer es quasi, natürlich, genau, und es gibt keinen, 100 Prozent sicher. Das haben wir ja auch in unserer Passwort oder Passwortfolge genannt. Am Ende wird es halt immer schwieriger, aber es ist nicht die Garantie, dass es unmöglich wird. Das ist halt einfach so.

Genau. Und man weiß halt auch, warum man bestimmte Sachen einführt. Also, warum habe ich SSL, wenn ich eine Website betreibe, ja, damit einfach Tempering, also die Manipulation von Daten oder Information Disclosure einfach nicht passieren kann. ne, auch wenn das vielleicht nervig ist und auch wenn es vielleicht C.P.U. Zyklen kostet und aufwendig ist und man Zertifikate verlängern muss und so weiter, es gibt ein Grund, dass man das.

Oder Crosssite Origin, das ja so was viele sagen, ich mach da jetzt einfach mal das Sternchen rein, weil das zum Entwicklungszeitpunkt bin ich irgendwie genervt, dass ich jetzt von da nicht dahin darf und so weiter und der Browser quasi sagt, nö nö nö nö, aber ja, das hat auch seinen Grund, ne, dass halt quasi nicht jeder einfach dahin darf und es nur von einer bestimmten Domäne kommen darf et cetera. Also das sind meistens, glaube ich, auch Hürden. Du kannst jetzt, oder es gibt auch viele Sachen in Frameworks, die gut überlegt sind im Sinne von Security, aber wenn halt die, ja, Lazyness, Bequemlichkeit der Entwickler dann kommt und sie quasi zum Entwicklungsteil, ja, das machen wir dann später, wir machen es jetzt mal aus, ja, weil wir haben andere Sorgen und Nöte, wir müssen ja irgendwie was bauen und Features liefern und dann gerät das vielleicht sogar in Vergessenheit, dann ist es vielleicht cool, wenn ich so eine Liste habe, warum haben wir welches Feature und vielleicht auch diese Liste durchgehen kann und sagen kann, habe ich SSL, habe ich das richtig konfiguriert, habe ich das eingeschaltet? Lasst uns nochmal draufschauen und nicht im Glauben zu leben, wir haben das Beste gemacht, so nach dem Motto.

Ja. Und was wichtig ist, auch nochmal dieser Perspektivumkehr, also es gibt einfach einen Riesenunterschied, wie ein Ingenieur, der etwas implementiert, denkt und wie ein Angreifer denkt. Und der Ingenieur, der etwas entwickelt, der denkt typischerweise in Listen. Also sowas wie, ich implementier Feature A, dann mach ich Feature B, dann mach ich Feature C und dann hab ich vielleicht ein noch ein To-Do, ein Bugfix für Feature A und dann vielleicht noch mal was Neues, ein Feature D. und so weiter. Also für für die Personen, die immer etwas entwickeln, für die ist das immer so eine so eine lineare Liste, so eine so eine Abfolge. das als erstes mach ich das, dann mach ich das und damit ist es erst einmal erledigt. Ein Angreifer denkt in in Bäumen, ja, das nimmt man typischerweise Attack Trees, ja, und ein Attack Tree zeichnet einfach auf, wie man etwas erbeuten kann. Und wenn wir noch mal für dieses Beispiel mit dem mit dem Keyless Drive von einem Auto, wenn wir da noch mal drüber nachdenken würden, ist ja die erste Frage, wo parkt denn überhaupt ein Auto? So, wenn ich das rausgefunden hab, ist die Frage, wie komme ich denn überhaupt in die Nähe, wenn jemand das Auto auf oder abschließt, dass ich ein Funksignal abgreifen kann. So dann ist die Frage, welche Hardware brauche ich dafür, wie bin ich im richtigen Moment da, um genau das zu erbeuten. So, wann kann ich das Auto denn wiederum wegfahren, was kann ich mit diesem Schlüssel alles machen in dem Auto, wenn ich den erbeutet hab und so weiter. Also für die ist es halt eher so eine, ja so so eine Baumstruktur, die sich sozusagen auffächert oder eine Kette. wo man sagt, als erstes hab ich das eine bekommen und mit dem einen kann ich jetzt das nächste erreichen und mit dem nächsten kann ich jetzt wieder das dritte bekommen, um am Ende schlussendlich zu Punkt 4 zu kommen. Ja, und das ist halt der der Unterschied zwischen Menschen, die was entwickeln, völlig egal ob Software oder Hardware ist, die denken halt eher in Listen, Feature 1, Feature 2, Feature 3 und Hacker denken typischerweise in Ketten. Wenn ich 1 erbeutet hab, kann ich damit 2 machen, um zu 3 zu gelangen. Ja, und deshalb ist es auch so spannend, dass man sich einfach mal so eine Perspektivumkehr leistet und sagt, so, hey, was könnt ich denn nicht machen, wenn ich das erbeutet habe? Ja, und ja, was will ich denn eigentlich erreichen? Also, wenn ich jetzt ein Malicious Actor wär in meinem System, was ist denn da zu erbeuten, so, oder was sind da für Daten drin und welche Kette müsste ich denn aufbauen, um an diese Daten zu gelangen? Ja, und das ist, glaub ich, ist glaub ich, extrem spannend für jemanden, der sonst eher in so Feature-Listen denkt.

Ja, ja, das sieht man ja auch, wenn man sich so Angriffe dann anschaut, wie die das gemacht haben, denken sie, hm, das ist echt smart, teilweise, ne. Also ja, am Ende ist das so, so Kleinigkeiten oder so Schnipsel und viele Schnipsel geben dann 'n Puzzle, ja, gerade auch, wenn man so über so Social Engineering und sowas nachdenkt, dann ja, ist es echt krass, was man heutzutage tun kann, weiterzukommen, wenn man jemanden angreift.

Und in der Softwareentwicklung wird ja auch ganz viel immer über über Bugs gesprochen, also im Sinne von, da ist ein Fehler passiert. Aber es ist manchmal auch gar nicht so sehr ein Bug, es ist einfach etwas, was sich aus der Konsequenz von dieser Listen Darstellung von Features einfach ergibt. Ja, also wenn man, wenn man in der Reihenfolge Feature A. B. und C. implementiert, dann hat man halt nicht über den Zwischenraum zwischen Feature A. und B. nachgedacht. Ja, wenn man so ein Attack Tree aufmalt, dann macht man das womöglich neben neben Stride und Third Modeling gibt es noch ein paar weitere Frameworks. Ja, es gibt auch eine Framework, das nennt sich Pasta, das ist Process for Attack Simulation und Threat Analysis, hab ich ein bisschen mehr risikozentriert. Es gibt auch eine grafische Darstellung von Attack Trees oder typischerweise gibt es von OWASP so eine Top Ten von Bedrohung, die es im Web gibt. Also das ist typischerweise sowas wie SQL Injection drin, solche Themen Cross-Site Scripts Ding und so weiter und ja, letztendlich gibt es mehr als ein Framework, um dieses Mindset zu etablieren, mehr auf Sicherheit zu achten und entsprechend kann man halt gucken, was für den eigenen Softwareentwicklungs Lifecycle ideal ist und vielleicht sprechen wir noch mal kurz, wer wer beteiligt sein sollte. Also ich glaub bei so einer, bei so einem Threat Modelling ist es halt extrem spannend, verschiedene Rollen zu haben. Also dass man nicht nur, nicht nur Entwickler oder nicht nur einen Architekten hat, ja, sondern vielleicht auch jemanden aus der Security Abteilung, vielleicht ein ein Product Owner mit dabei, der Product Owner müsste einem ja sagen können, was man zum Beispiel erbeuten kann bei einem System und dass man einfach eine eine bunte Mischung an Leuten hat und einfach versucht mit mit diesen verschiedenen Rollen in so eine Analyse reinzugehen, um zu gucken, hey, was kann man denn da jetzt irgendwie herausfinden, wie wär sozusagen die Reihenfolge, wo kann man diese Kette denn auch brechen mit so einem typischen Datenflussdiagramm. Ja, und ja, dass man einfach eine möglichst breite Palette an Rollen da hat, die einfach alle versuchen, mal diesen Umkehrschluss zu tun und zu sagen, hey, lass uns doch mal gucken, was wir hier machen können. Ja, Tools, vielleicht noch mal ganz kurz, es gibt ein Threat-Modelling-Tool von Microsoft, es gibt auch diverse Open-Source-Tools. Ich glaube, es gibt eins von Ovors, das heißt, glaube ich, tracken, wenn ich das richtig im Kopf habe. Es gibt auch eine, wie heißt es, Three Three Child, das ist Thread Modeling, Three Agile, genau, schwer auszusprechen, Third Modeling as Code. Ja, das ist auch was, dass man quasi versucht, das Ganze mit mit Code abzudecken. Ja, aber entsprechend, ich find es eigentlich immer noch tatsächlich auch sehr gut, das Ganze an so einem, an so einem Whiteboard und so einem Datenflussdiagramm zu machen. oder einfach mal erst mal drauflos zu überlegen, ja, und dann das Ganze hinterher vielleicht in so ein Datenflussdiagramm zu überführen und dann auch regelmäßig mal das Ganze macht. Also, wenn man innerhalb eines Projektes das Ganze einmal macht, dann hat man vielleicht, na ja, einen kleinen Prozentsatz von dem, was möglich ist, abgedeckt. Aber ich glaub, es ist echt sinnvoll, weil so ein so ein Produkt ja auch einer Evolution unterliegt, das einfach regelmäßig zu machen. Ja, vielleicht so ein paar Tipps, kleinen Anfang, hab ich ja gerade schon gesagt. Ja, vielleicht gucken wir uns erstmal nur ein einzelnes Feature an oder eine A.P.I. als erstes Threadmodel. Ja, und dann langsam größer werden. Es muss auch gar nicht perfekt sein am Anfang. Also überhaupt ein Threadmodel zu haben ist besser als keins. Ich hab ja schon am Anfang gesagt, klassischerweise in der Softwareentwicklung wurde ja dieses ganze Thema Sicherheitstests oder Penetration Tests am Ende gemacht. Ja, und damit frühzeitig anzufangen, ein Threadmodel zu haben und das direkt in die Entwicklung mit rein zu geben, ist halt besser als gar keins zu haben und das wird am Ende auch einfach von der von den Kosten her preiswerter. Ja, regelmäßig wiederholen, besonders bei Architekturänderungen. Also wenn man sich jetzt überlegt, man ändert meinetwegen den Auth Provider, ja, ist das vielleicht eine gute Idee, das zu machen oder man ändert die Datenbank oder man ändert eine Zugriffsschicht oder man ändert hier was, was Größeres ist, definitiv regelmäßig wiederholen. Das Ganze auch in Form eines Teamworkshops machen. Also ich sag mal, mehr Augen, ja, sehen einfach auch mehr. Also als Einzelkämpfer so ein Third Model zu machen, da wird man, glaub ich, kommt man nicht weit. Und es erhöht natürlich auch die Akzeptanz im Entwicklerteam, da was zu machen. Dann wie immer Dokumentation pflegen und im Zweifelsfall vielleicht auch machen, A. A. I. Agenten nutzen. Ja, man kann sich ja auch ein Agenten bauen dafür und einfach auch mal den Agenten fragen, was denn hier schief gehen könnte. Ja, und vielleicht kommt der Agent ja auf noch weitere Ideen, die man gar nicht gesehen hat.

Ja, aber es gibt ja diesen Ansatz auch mit dem Red und Blue-Team, das rote Team will immer irgendwie einbrechen und das blaue muss es verhindern. Und während das passiert, beobachtet man, was sind denn Schwachstellen? Ah, SSL vergessen, keine Ahnung, irgendwas falsch konfiguriert. Und vielleicht kann man das ja heutzutage auch mit AI-Agents machen, dass man da jetzt nicht wirklich Teams feiern muss, sondern sagen kann, hier, du bist ein was auch immer, Hacker versuchen mal hier einzubrechen und ihn vielleicht guided, also hab ich, ist vielleicht auch ein Ansatz, den man, den man gehen kann, um einfach auch rauszufinden, ist gut oder ist nicht gut.

Vor allen Dingen, um vielleicht auch einen Attack Tree herauszufinden, auf den man selber nicht gekommen wäre.

Ja, genau, also quasi sagen, brecht da mal ein und gucken, welche Kreativität gibt es denn, ne, und dann einfach ja, wie du sagst, daraus den Baum zu bekommen und dann zu gucken, wie können wir das denn besser machen, wie können wir das denn besser absichern?

Ja, es gab ja grad dieses, vor wenigen Tagen ist ja dieses Open A. I. Thema durch die Presse gegangen, wo die, ich glaub, bei Huggingface eingebrochen sind mit dem Modell oder das Modell, das gemacht hat, ohne dass sie es eigentlich wollten. Und da hat das Modell ja im ersten Schritt auch das geschafft, die diese Sandbox zu überwinden und auf einen Server zu kommen, der Internetzugriff hat und das heißt ja, glaub ich, für eine Schwachstelle in NPM, irgendein Paket von NPM, glaub ich, gemacht oder so. Und das ist sicherlich etwas, wo die Leute, die das Sandbox-System designt haben, auch nicht im ersten Moment drauf gekommen sind, dass die A.I. genau das versucht. Ja, und so kann man natürlich auch womöglich einen neuen neuen Attack-Vektor finden.

Ich glaub, A.I. allgemein bringt stellt auch das tierisch auf den Kopf. auch wenn man jetzt so sieht, was da so möglich ist mit mit Packages et cetera. Ich mein, früher gab es ja so die sogenannten Script-Kiddies, das waren ja so Tools, die du runterladen konntest und die haben dann irgendwelche bekannten Schwachstellen einfach ausgenutzt, ja, und du musstest jetzt nicht mehr so viel wissen, in Anführungszeichen. Und ich glaub, mit DAI hat das halt das Script-Kiddy noch mal 'ne ganz andere Mächtigkeit, ne? Also, ich hab da so 'n Agent und erzähl dem lustig, was ich jetzt gerne hätte und Die Absicherung, die da drin steckt, ne, also manchmal hat man das ja, hey, ich kann das nicht machen, weil ne, oder ich, wir können das nicht tun, weil das ist ja alles nur trainiert, das ist ja, heißt ja nicht, dass das jetzt unbedingt 100% sicher ist, ich kann das ja dann trotzdem aushebeln, ne, also ich hab mal einfach, ich wollte mal wissen, ist es möglich mit A.I. mal eben was zu dekompilieren, ne, weil ganz viele auf LinkedIn auch sagen, hier, ich hab irgendein Spiel nachprogrammiert, hat irgendwie 24 Stunden war fertig, ne, und dann dachte ich mir, Wenn ich jetzt A.I. sag, ich hab hier irgendwie 'ne Exe und jetzt nicht irgendwie Java oder .net, wo irgendwie E.L. Code dazwischen ist, sondern wirklich C++ oder sowas, geht das denn, ne? Und der erste Zug der A.I. war: 'Ja, weißt du, das können wir ja gar nicht machen, das ist ja gar nicht dein Programm.' Das, das will ich nicht und dann hab ich einfach gesagt: 'Ja, weißt du, ist ein bisschen blöd, weil mein Source Code ist abhanden gekommen.' Du bist meine einzigste Chance, wieder an das Wissen zu kommen. Ja, OK, dann mach ich es. So, Also selbst wenn jetzt irgendwie in den Models und wenn das alles schwerer wird, quasi dann auszuführen, was man sich alles ausdenken kann, Sandboxes et cetera. Aber ich glaube, wenn jemand nicht ganz blöd ist, kann er mit Hilfe von A. I. eine Menge anstellen. Das war früher überhaupt nicht möglich, ne?

Ja, und auch da hilft halt am Ende Threat Modeling, um eine Idee zu bekommen, was denn überhaupt geht, was die anderen nutzen könnten, was passieren kann und so weiter. Ja, also das ist im Prinzip Wissen, was völlig egal, wie es mit A.I. weitergeht, wichtig ist im Kopf zu haben.

Ja, Security ist, glaube ich, in im Zeitalter von A.I. noch mal doppelt so wichtig.

Ja.

Und ich glaube auch, ich hab eine Mail bekommen von von meiner privaten Microsoft Account oder von dem Microsoft Account, da wurde mir gesagt, dass SMS und E-Mail, zweiter Faktor, wird abgekündigt und ich soll doch gefälligst einen Passkey machen. Und ich glaube und also ich finde das gut, ich glaub, viele werden jetzt auch wieder schimpfen und sagen, ah, nee, find ich blöd, aber Pask-Key ist so viel mächtiger, auch das, was du erzählt hast, ne, von diesem Hoster, ne, also du sollst dich da irgendwie einloggen und am Ende leiten das weiter und machen dann halt irgendwie was in einem Auftrag, mit Pask-Key funktioniert das einfach nicht, weil der Pask-Key ist auf diese Domain vom Hoster gebunden, das heißt, der Pask-Key würde da nie und nimmer landen bei dem, ne, die so, und deswegen, ja, User müssen auch ein bisschen Threat Bottling machen.

Und Fun Fact, die E-Mail wär auch, oder selbst wenn ich drauf reingefallen wäre, ich hab natürlich 2 Faktoren an, auch das hätte es natürlich am Ende nicht nichts gebracht, ne. Aber das Passwort wär schon mal in der Wildnis gewesen.

Genau, und wenn das jetzt noch woanders verwendet worden wär und so weiter, ne.

Genau, das tut es ja nicht mehr, da haben wir mit der Passwortepisode für gesorgt. Seitdem habe ich nur noch eindeutige Passwörter.

Ich glaube, was er vielleicht auch noch sagen kann, ist ja, dass Angreifer ganz oft auch auf diese Fear of missing out oder auf diesen, wenn du das jetzt nicht machst, dann geht die Welt unter, ja, Moment setzen. Und was Apple da ganz gut macht, also wenn die merken, dass du zu viel änderst in einer gewissen Zeit, dann sagen die auch, jetzt kannst du erst mal nichts mehr machen. Also komm vielleicht mal wieder in vier Stunden und dann können wir irgendwie weitermachen, ist vielleicht auch was für die Software, die man baut und wenn es echt schützenswert ist, dass man, ich meine, das ist unheimlich nervig, wenn du wirklich du bist, ja, und du willst das jetzt machen und das Ding sagt, ja, jetzt erst mal nicht, ja, komm einfach wieder in, wie lange auch immer die Zeit ist, aber ich glaube, für jemanden, der quasi durch Social Engineering oder wie auch immer das passiert, mit Phishing angegriffen wird, ist sowas natürlich einfach wunderbar, weil es einfach davor schützt, vielleicht auch diesen Moment der Pause und das Gehirn, und sein nicht mehr so viel Adrenalin fängt wieder an zu denken und man fragt sich eigentlich, was mach ich da eigentlich und ist nicht jetzt in dem Fluss und zieht das alles durch, was die so wollen. Also ja, ich glaub ja, und das ist in meinen Augen auch irgendwie etwas, was vielleicht in Threatmodelling rein muss, ne. Also wie schützen wir unsere User, selbst wenn die halt einfach ausgetrickst werden und so blöd sind, könnt man ja auch sagen, wenn der das macht, ist er selber schuld. Aber ich könnt auch sagen, wenn der sich ungewöhnlich verhält oder wenn der auf einmal irgendwie das Passwort und den zweiten Faktor ändern will und irgendwie noch eine Handynummer, dann sagen wir jetzt erst mal Stopp und verhindern das so ein bisschen.

Ja, wenn ihr mehr erfahren wollt, es gibt ein paar ganz tolle Bücher zum Thema Threat Modeling. Und zwar ist ein Autor, der Adam Shoustak, der hat ein Threat-Modeling-Buch geschrieben. Die zweite Edition kommt im Dezember, dann wohl mit AI-Security, also da bin ich auch schon mal sehr gespannt drauf. gibt es auch ein älteres Buch, das heißt auch Threat Modelling aus dem von Microsoft Press und wir packen das gerne hier in die in die Shownotes, den die Verweise auf die Bücher. Und dieser Adam Shoestek ist jemand, den man sich auf jeden Fall merken sollte. Der hat unter anderem ein Kartenspiel-Design, das nennt sich auch Avalation of Privileges. Und diese 4 Fragen, die ich am Anfang genannt habe, da gibt es halt auch entsprechend in seinem Repository Informationen dazu, also quasi dieses 4 Fragen Framework, ne, woran arbeiten wir, was könnte schiefgehen, was machen wir dagegen und haben wir einen guten Job gemacht, da gibt es halt entsprechend auch Informationen auf GitHub von Adam Shoustak und das ist derjenige, der letztendlich da sehr, sehr weit in dem Thema ist und sehr viel auch dazu publiziert und auch eine Beratungsfirma mittlerweile gegründet hat, ist ein Ex-Kollege von uns.

Ja, das war es von uns von heute von Tobi hoch 2. Es hat Spaß gemacht, dieses Thema mit euch zu teilen, Wenn ihr weitere Gedanken oder Fragen habt, schreibt uns doch eine Mail, gern auch wenn ihr Teamwünsche habt. Bis zum nächsten Mal bei Tobi hoch 2, wenn es wieder heißt: Doppel Tobi, Doppel Tech.

Ciao.

Ciao!

Hallo und herzlich willkommen zu einer neuen Episode von Tobi hoch 2. Heute heißt es wieder doppelt Tobi, doppelt Tag. Hallo Tobi.

Hallo Tobi.

Heute geht es um Git, warum Versionskontrolle mehr ist als ein Datei-Backup, wie Git Intern denkt Snapshots, Pointer, Hashes, welche Workflows im Alltag wirklich zählen und warum AI-Agents Git noch wichtiger machen. Dabei soll das keine reine Befehlsreferenz sein, wir reden über das Mindset hinter Git. Ja Tobi, welche Versionskontrolle Kontrollsysteme hast du denn schon in deiner Zeit als Entwickler genutzt?

Ja, ich bin ja älter. Ich bin älter, Mondeur. Und ich habe mal in einer Firma ein Praktikum gemacht, da hat man noch ZIP-Dateien gemacht. Also du hast irgendwie was geändert, dann hast du einen ZIP gemacht, hast das irgendwie auf einen FTP-Server hochgeladen und das war die Versionsverwaltung. Ja, das war das Krasseste. Ich hoffe, niemand auf diesem Planeten muss das noch machen.

Ach, bestimmt. Händchen von 2 Zips ist bestimmt super.

Ja, es ist, kannst du einfach vergessen. Ja, und natürlich auch das, was man früher gemacht hat, irgendwie, wenn du eine, keine Ahnung, musstest eine Arbeit machen, Powerpoint, hast halt einfach gesagt, oh, ist ein guter Stand, hast die Datei kopiert und dann irgendwie weitergemacht, ne? Also, dass du quasi halt dir selber so verschiedene Versionen eines Dokuments oder für ein, was auch immer es war, angelegt hast. Ich glaub, das kennt auch noch jeder und das hat man auch alles gebraucht, bevor es eigentlich so wirklich Git gab und jeder irgendwie Git verstanden hat, oder?

Ja, und ich hab gerade mal drüber nachgedacht. Also, ich hab mit Microsoft Sourcesafe Version, ich glaub, 6.0 A. angefangen, die hatten irgendwann so Buchstaben. Später war das denn die Team Foundation Server Versionskontrolle. Ja, ich hab auch Subversion mal eine Zeit lang nutzen müssen und genau, irgendwann ist Git aufgetaucht und dazwischen gab es auch noch ein paar andere. Also ich glaube, das war so die Zeit, Git musste um 2005 herum aufgekommen sein und in der Zeit gab es, ich sag mal, diese klassischen Versionsverwaltungssysteme wie zum Beispiel Subversion oder den Team Foundation Server. Und es gab auch eine Zeit lang, da kamen jetzt diese neuen Versionsverwaltungssysteme auf und ich hab damals zum Beispiel Joel on Software immer gelesen und der hat zum Beispiel immer für Mercurial so ein bisschen Werbung gemacht und weil Mercurial auch ein verteiltes Versionskontrollsystem ist. Und genau, da hab ich auch mal Mercurial ausprobiert, aber ich glaub nie, nie professionell eingesetzt.

Ja, du hast schon ein super Stichwort gesagt, ne, dieses zentralisierte und dieses dezentrale bei Versionsverwaltungen, worum geht es? Mal prinzipiell, vielleicht fangen wir erst mal damit an, um dann tiefer einzusteigen. Es geht darum, dass ihr irgendwie auf eurem Computer irgendwas bearbeitet und ihr immer irgendwie die Sicherheit haben wollt, dass ihr irgendwie zurückgehen könnt. Keine Ahnung, ihr macht ein Word-Dokument, schreibt da irgendwie einen Tag lang und irgendwann fällt euch auf oder irgendwas passiert und war vielleicht jetzt doch nicht so gut die letzten zwei Stunden. Ich würde gerne eigentlich zwei Stunden wieder zurückgehen. Das ist oder war früher relativ schwer. Man musste das irgendwie selber machen, man musste dran denken, dass man irgendwie die Datei wegkopiert und immer wieder sich daran erinnern, dass man auch speichert und so. Das ist ja heute alles irgendwie meistens weggekapselt, vor allem, wenn wir jetzt über Office oder sowas reden. Und als Softwareentwickler war es dasselbe. Du hast irgendwie Source Code geschrieben, was am Ende Text ist oder Textdateien und hast auch, wer kennt das? Es hat funktioniert und dann hast du gesagt, jetzt mache ich noch das und dann irgendwie eine Stunde später hat nichts mehr funktioniert, AI gab es noch nicht. die dir dann geholfen hat. Ja, und dann hast du dich quasi geärgert, dass ja eigentlich das vorher ganz gut war, aber jetzt gar nichts mehr geht und du auch gar nicht mehr weißt, wie du jetzt zurückkommst. Ja, und dafür braucht man sowas wie Versionskontrolle-Systeme. Und ich kann nur jedem empfehlen, ich hoffe, dass niemand auf diesem Planeten Software entwickelt ohne das, aber ich kann nur jedem empfehlen, es zu tun.

Aber was man sagt, absolut. Und spannend ist eigentlich auch, dass Git gefühlt gewonnen hat, jetzt eigentlich so seit einigen Jahren. Also, ich kenn jetzt keinen Entwicklerteam mehr, was jetzt nicht Git einsetzt. Ja, und im Prinzip ist ja Git für die Programmierung, ich sag mal, lebensnotwendig. Ja, und auch hier wieder irgendwie spannend, dass es am Ende ein Open Source Projekt ist, was von von Linus Torvalds ins Leben gerufen wurde und jetzt von Junior Hamano maintained wird. Ich glaub, der ist bei Google, der Kollege. Ja, und im Prinzip die ganze Welt auf dieses eine Open Source.

Und früher, also das gab es ja auch schon, du hast es genannt, verschiedene Tools. Und eins der Tools war immer irgendwie, dass es halt remote war. Also du hattest einen zentralen Server und du hast dich zu dem verbunden und konntest den dann irgendwie fragen nach verschiedenen Ständen. Wenn du jetzt gesagt hast, oh, das ist jetzt gerade eine ganz gute Idee, ein ganz guter Stand, konntest du quasi das so committen. Also committen ist immer, ich mache quasi so eine Art Speichern, ich mache so eine Art Snapshot und du hast aber immer den zentralen Server gebraucht. Also wenn du jetzt quasi keine keine Ahnung, der ist ausgefallen oder du warst irgendwie nicht in der Firma, nicht im VPN, wo auch immer der dann erreichbar war, hattest du immer die Schmerzen, dass du eigentlich gar nicht damit arbeiten konntest, so wie du halt arbeiten kannst, wenn du den erreichen kannst. Und früher war eigentlich auch das Mindset für Versionsverwaltung eher so, wenn ich alleine bin, brauche ich das nicht so, aber wenn ich halt mit den anderen zusammenarbeiten will, weil irgendwo müssen wir ja irgendwie unsrige Sachen dann zusammenbringen. aber man hat nie so darüber nachgedacht. Eigentlich ist es ja vielleicht auch sinnvoll, wenn ich alleine arbeite. Und ich kann nur sagen, dass ich es persönlich eigentlich, egal für was ich mache, es gibt es auf meinem Rechner. Ich mache einfach ein Getrepo und selbst wenn ich das nirgendwohin dann kopiere oder wir reden noch darüber, wie das so funktioniert, aber ich benutze es einfach, weil am Ende ist es mein Sicherheitsnetz, wenn irgendwas schief geht.

Es gibt auch einen ganz, ganz wesentlichen Unterschied zwischen früher und heute und zwar die Möglichkeit, eine Versionsverwaltung als Passdienst zu konsumieren und das ist, glaub ich, auch ein ein eine Riesensache, die die sich geändert hat zu damals. Heutzutage ist es so, man kann so was wie GitHub nutzen, man kann so was wie GitLab nutzen, man kann Bitbucket nutzen, es gibt diverse andere Dienste, die das alles können und man braucht letztendlich ein Account, vielleicht kostet es Geld, vielleicht auch nicht und dann kann man damit loslegen. Früher war es halt so, man braucht ein Server, man musste das da drauf installieren, es musste sicher sein, es musste von außen erreichbar sein, wenn man es irgendwo laufen hatte und da gibt es noch noch vielleicht noch ein paar mehr Hürden, an die ich jetzt gerade gar nicht denke und das hat es natürlich extrem schwer gemacht. Ja, also vor allen Dingen, wenn es darum geht, ein kleines Projekt irgendwie zu hosten, muss man sich einfach überlegen, ob man diesen Aufwand denn wirklich, wirklich treiben will. Ja, es macht natürlich aus, aus, ich sag mal, aus dem professionellen Ansatz heraus absolut Sinn, das zu tun. Ja, aber ich kann mir auch vorstellen, dass viele genau das vermieden haben. Ja, und das ist halt ein wesentlicher Unterschied zu früher.

Ja, hast du recht, ja, und wahrscheinlich ja, früher war Speicherplatz auch nicht so verfügbar wie heute.

Aber mal eine ganz andere Frage, wie, wie, wie stehst du denn zu Git?

I love it, mir, ich glaube, es ist ein Tool, wo ich jetzt mir ein, also nie das Gefühl hab, es fehlt was, oder? Oder hast du mal Git benutzt und dachtest dir, hm, wenn die endlich mal dies und jenes einbauen würden, dann wär es geil.

Das tatsächlich nicht. Also ich hab mich in der Vorbereitung auf diese Episode gefragt, ob Git wirklich immer eine gute Wahl ist und ob es, also ob es auch vielleicht auch Teams gibt, die vielleicht mit einer anderen Struktur, mit was zentralisierteren, besser zurechtkommen. Ja, von daher ist so eine, also ich mag Git, ja, ich find es ist auch ein gutes Tool, es ist tatsächlich an vielen Stellen, find ich, nicht so ganz intuitiv. Ja, es ist halt viel Konsole, viel Konsolenarbeit und man muss auch, ich glaube, ein Team haben, was sich mit diesem ganzen Team der Versionsverwaltung beschäftigt hat, ja, was, was auch Git verstanden hat. Ich glaub, dann hat Git so die richtige Power, wenn du ein Team hast, die sagen, nö, eigentlich hab ich darauf gar keine Lust, ja, und eigentlich möchte ich hier nur komm mit und weg, ja, auf meinem, auf meinem Dev Branch und los geht's, dann ist vielleicht nicht das richtige Tool. Also diese ganze Idee, wir werden ja bestimmt nachher noch über, über Branching und Merging und Zweigen und so weiter sprechen, das muss man, glaub ich, bei Git auch ganz doll lieben.

Ja, aktiv ist es dann das richtige Team. Natürlich. Fragezeichen. Entschuldigung. Aber wenn du schon Teams sagst oder ein Team, was ist denn wichtig? Also was würde denn passieren, wenn man jetzt keine Versionsverwaltung verwendet? Und ich meine, am Ende geht es auch darum, wenn man Software entwickelt, zum einen, welche Version ist denn gerade in Produktion, welche Version ist am Entwickeln, welche Version war mal die Version eins, zwei und was auch immer. man muss wissen, wer hat denn was geändert, dass, wenn man jetzt irgendwie Probleme hat oder Fragen hat, dass man zumindest mal vielleicht die Person noch fragen kann und auch rausfinden kann, wer hat das denn gemacht? Dann findet man vielleicht noch raus mit Versionsverwaltungssystemen, warum wurde was geändert? Also, wenn ich irgendwie ein Issue oder ein Task oder ein User Stories, was auch immer das dann ist, irgendwie verknüpft habe, kann ich vielleicht auch den Grund dafür rausfinden, was denn so die Intention war. Dann, du hast schon gesagt, diesen Developer Branch, also irgendwie ist das ja die Idee, ich kopiere mir einfach alles weg, mache, was ich will und irgendwann muss ich halt wieder zurück zu den anderen oder zu dem Hauptort. Und das ist sicherlich auch eine Geschichte in Teams, dass ganz viele an einem Projekt arbeiten und am Ende irgendwie muss es ja trotzdem zu einer Version zusammenkommen. Und das Nächste ist ja noch, und dafür ist eigentlich gilt auch immer das Beste, oder ich meine, ich war früher im Developer Support und früher haben ich habe festgestellt, dass viele auch Angst haben, einfach mal was zu tun. Und ich habe das eigentlich nie verstanden, weil wenn du irgendwie Versionsverwaltung hast, dann mach doch einfach irgendwie einen Brunch und jetzt bist du ja frei. Wenn es schiefgeht, dann löscht du den halt oder schmeiß das einfach weg, hast verlorene Zeit, aber es kann ja nichts passieren. Du riskierst jetzt nicht, da irgendwie Dinge zu machen, die halt am Ende Probleme verursachen, produktiv. Genau, das ist so ein bisschen die Anforderung, glaube ich.

Aber auch nur, weil Branchen extrem einfach ist bei Git.

Ja, jeder, der das mal mit einem Remote Tool gemacht hat, der weiß, dass das dann länger dauert und ich weiß nicht, wie, wie das intern abgebildet ist, aber es war immer einfach zum Verzweifeln. Genau, das, das, ja, stimm ich dir vollkommen zu. Also jeder, ich hab damals ein Team Foundation Version Control System verwendet und da waren Branches einfach ein Krampf. Ja, Und wenn du dann das erste Mal mit Gitten einen Branch gemacht hast und das war einfach so blab da und dachtest so, der ist kaputt, das kann nicht sein. Ja, das dauert noch mal ein bisschen länger, ja, dann hast du verstanden, warum du das brauchen kannst.

Absolut genau.

Und wir sprechen ja nachher noch über, über, über Workflows und am Ende ist, glaub ich, Branching einer der Kernelemente in so einem Workflow und es funktioniert wirklich sehr, sehr gut.

Ja, und also es hilft einfach auch, damit man nicht die Änderung des anderen überschreibt. Darum geht es ja im Grunde genommen.

Genau, also Git bietet uns am Ende eine Historie, also diese ganzen Punkte, die wir vorher angesprochen haben, kann man mit Git lösen. Also ich weiß, wer, wann, was und warum vielleicht sogar gelöst hat. Ich kann parallel an einer Software arbeiten, ohne dass sich irgendwas überschrieben wird, wie du gerade gesagt hast. Ich kann in Branches Experimente machen, ich kann auch Reviews und Audits einbauen in diese Workflows und sagen, hey, wenn immer jemand was in seinem Developerbranch oder wo auch immer der dann ist, geändert hat, muss jemand anders drüber schauen. Erst dann akzeptieren wir das in den Hauptstrang oder in den Hauptbranch. Und ganz wichtig ist auch, Git hat eine Integrität. Das heißt, ich kann jetzt nicht mehr so ein Git-Repository holen und einfach da Dinge oder die Historie manipulieren, weil sich das durch diese, ja, wir reden auch drüber, über diese Hashes einfach verlinkt. Ja, also es ist eigentlich wirklich, ja, Audit oder wie sagt man das so, es ist sicher, es kann nicht quasi verändert werden.

Ja, aber auch zum Nachteil, weil man Sachen auch nicht unbedingt wieder rausholen kann. Ja, also wenn es einmal drin ist, dann ist es in der Historie.

Dann ist es in der Historie. Ja, es gibt Mittel, aber man braucht, ja, es ist nicht so einfach, sagen wir es mal so.

Ja, gibt ein paar Dinge, die Git auch nicht löst. Ja, also Git ist kein Backup-Konzept oder ähnliches. Ja, oder auch kein Allheilmittel gegen Konflikte, wenn 2 Leute an der gleichen Datei arbeiten. Ja, dann hoffentlich an verschiedenen Stellen, ansonsten hat man einen Merch Conflict und darf dann auseinandersetzen mit dem Code des anderen und die Sachen dann zusammenführen. Ja, genauso wie wir haben es ja gerade schon angesprochen, es ist kein Secrets Management, da gibt es Tools und Mittel und Wege, Repositories auch nach nach Secrets zu scannen. Letztendlich ist es aber so, wenn Secret eingecheckt ist, ist es in der Historie drin. Ja, und genau, und man braucht halt entsprechend auch eine Plattform außen drumherum, weil nicht notwendigerweise direkt Zugriffskontrolle drin ist. Ja, und ja, es geht auch immer natürlich um die Kultur, man soll sozusagen kleinere Änderungen sofort committen in den Branchen, in denen man arbeitet, so dass man immer Zwischenstände hat. Ja, wieso ja, wie so Marker eigentlich. Ja, also ein Stand von von 10:00 Uhr, von 11:00 Uhr, von 12:00 Uhr und so weiter, damit man auch zur Not zurückgehen kann und das erfordert natürlich auch entsprechend Disziplin. Also diese Idee, ich fang morgens um 9 an zu entwickeln und mach meinen ersten, komm mit abends um 18:00 Uhr, wenn ich nach Hause geh, das ist nicht nicht Best Practice, das ist eigentlich eher das Gegenteil von Best Practice. Ja, und natürlich auch entsprechend halt, wenn man auf dem eigenen Branch zum Beispiel unterwegs ist, öfter mal ein Push machen von von den Commits, die man gemacht hat.

Und du hast jetzt noch Secrets angesprochen und ich glaube, es ist ein guter Punkt. Also, wenn sie einmal drin waren, sind sie drin, dann müsst ihr sie am besten ändern und dann halt die geänderten nicht mit in das Repository und in die Commits mit rein. Und das andere große Thema ist, glaube ich noch, wir leben in der Welt des A.I. Agents und A.I. Codings, der sieht auch eure Secrets, ne? Und das kann natürlich auch bös ausgehen. Ich mein, wenn da der produktive Connection String für keine Ahnung was ist, dann kann er den finden. Und wenn ich in Yolo-Mode bin, kann er sich da vielleicht auch hin connecten und dann lustige Dinge machen. Und auf einmal klingelt das Telefon, hey, es geht da was nicht. Was machst du denn da? Also deswegen ist es, glaube ich, Secrets Management auch zum einen nicht ins Repository und zum anderen sich auch überlegen, dass solche produktiven oder gefährlichen und Systeme, die Daten haben oder die ich einfach nicht zerstören will mit Yolo-Mode oder mit Agentic Coding, dass das auch gar nicht in die in die Quere von so einem E. I. Agents kommen kann. Also 2 Gründe inzwischen, das nicht in ein Repository einzuchecken. Ja, wollen wir ein bisschen über die Historie reden von von Git?

Ja, wenn man sich die Historie anguckt, dann ist natürlich für Git Linus Torvalds extrem zentral und das Ganze ist so, dass es schon Versionskontrollsysteme natürlich vorher gab. Also C.V.S. ist 1 Subversion eigentlich als C.V.S. Nachfolger, so ab ungefähr 2000 war, war Subversion en vogue. Letztendlich ist aber die ganze Linux Kernelentwicklung auf einem anderen System passiert, nämlich auf Bitkeeper. Und es gab, glaub ich, um 2005 herum gab es einen, sagen wir mal, Disput, was die Lizenz angeht. Und der Linus Torvalds hat anscheinend Ersatz gebraucht und wollte einfach Bitkeeper nicht weiter benutzen und hat dann selbst ein Verwaltungssystem geschrieben. Daraus ist Git entstanden. Also Git ist quasi sein Produkt. Ja, was wie hast du ja gerade schon gesagt, Branching zum Beispiel sehr, sehr schnell ermöglicht und damit auch schnell Experimente ermöglicht. Und einfach, weil es, ich glaube, schon ziemlich intelligent aufgebaut ist, verteilt funktioniert, schnell ist, extrem robust ist und damit natürlich auch relativ schnell, obwohl es in Teilen vielleicht kompliziert ist, Anklang gefunden hat. Und ja, letztendlich ist ein Produkt wie GitHub 2008 entstanden, ja, als Hosting-Plattform für Git und Und damit ist natürlich Git erst recht Mainstream geworden, wo man relativ einfach jetzt seine Repositories hosten kann. Also ist quasi das Werkzeug gewesen, mit dem der Linux-Kernel gepflegt werden sollte.

Genau, und das erklärt, glaube ich, auch, warum es ganz viel erschlägt, was halt einfach verteilte Softwareentwicklung braucht. Und Linux-Kernel ist jetzt ja kein kleines Projekt. Und ich weiß gar nicht, wie viel Contributor das hat, aber Ich glaube, das irgendwie tausende. Und deswegen funktioniert es so gut. Und in Vorbereitung für die Episode habe ich mal geguckt, ob es Bitkeeper überhaupt noch gibt, weil ich kenne niemanden, wirklich niemanden, der das jemals benutzt hat. Und die Firma gibt es noch. Aber wie krass ist das? Also hätten die damals hier nicht gesagt, das finden wir irgendwie blöd und du musst uns Geld geben und hätten einfach gesagt, hey, finden wir cool, wie sähe heute die Welt aus? Und vielleicht würden wir nicht über Git reden, sondern über Bitkeeper, keine Ahnung. Ja, dann Wichtig ist, dass man einfach versteht, es gibt lokale, zentrale und verteilte Versionsverwaltungssysteme. Ich mein, lokal ist irgendwie etwas, was ihr so für euch macht, ne? Ohne jetzt irgendwie ein Tool, haben wir schon gesagt, Dateien umbenennen, Zips erstellen, wie auch immer, am besten einfach gar nicht mehr machen. Ja, ganz einfach. Dann zentral ist quasi irgendwie, ihr habt so was wie T.F.S. mit Team Foundation Source Control oder Subversion oder was auch immer, ist einem immer blöd, weil ihr braucht immer einen Server und ja, oder ihr nehmt sowas wie Git.

Ja, ich würd es nicht unbedingt, ich würd nicht sagen, es ist immer blöd. Ja, also es hat seinen Zweck. Ja, und also es hat auch tatsächlich damals bei bei T. F. S. mit der Einführung von Caching auch extrem gut im Offline-Modus funktioniert. Ja, also ich finde, es hat durchaus noch seine Berechtigung.

O. K., dann In meiner Welt gibt es nur Git. Aber ich lasse mich gerne vom Gegenteil überzeugen, wenn es dafür gute Gründe gibt.

Das nächste Projekt machen wir auf TSVC.

Ich bin raus. So, genau. Und dann gibt es die Distributed-Versionsverwaltungssysteme und das ist am Ende Git. Und Distributed heißt, dass ich keinen zentralen Server brauche und dass ich auch jetzt nicht irgendwie, wenn ich mir so ein Repository anlege oder wenn ich eins klone oder mir hole von jemandem anderen, dass ich automatisch dann irgendwie direkt schon zu dem diese Änderungen, die ich bei mir gemacht habe, irgendwie hinbekomme oder transferiert bekomme. Weil jede Kopie von so einem Repository ist einfach eine ganze Kopie. Ich habe einfach alles, ich habe die komplette Historie und so weiter. Bei Remote-Versionsverwaltungssystemen ist es meistens so, dass ich nur eine spezifische Version auf meine lokale Kopie bekommen. Ich hab dann noch irgendwie Zugriff vielleicht auf die Historie, aber ich kann jetzt da nicht ohne im Offline-Modus quasi einfach auf verschiedene Versionen gehen.

Ja, und das funktioniert letztendlich immer über Push und Pull. Also Push bedeutet, ich habe das, was ich jetzt lokal geändert hab, committed und ins zentrale Repository gepusht, zum Beispiel bei GitHub, ja, und alle anderen pullen wieder davon, ja, und es ist halt deshalb dezentral, wie du schon eben gesagt hast, weil alle alles haben. Also das heißt, die komplette Historie liegt bei mir lokal auf dem Rechner, genau wie auf allen anderen Rechnern, die in diesem Projekt mitarbeiten.

Und man hat quasi, also wenn ihr jetzt von GitHub ein Projekt euch holt, und dann müsst ihr das Projekt clonen, dann habt ihr natürlich in diesem Clone schon die Information, von welchem Upstream-Repository das kommt. Da steht dann irgendwie die URL von diesem Open-Source-Projekt drin. Aber wenn jetzt das zum Beispiel umzieht oder keine Ahnung, was passiert, dann könnt ihr einfach diese URL ändern. und seid wieder arbeitsfähig. Ja, also es ist kein großer Migrationsaufwand nötig. Ja, oder ihr könnt auch mehrere dieser Upstream Repos irgendwie hinterlegen, also verrückte Sachen damit machen. Ja, das ist eigentlich, ich weiß nicht, ich glaub, wenn das jemand hört, der nur Git kennt, denkt der, was labern die da eigentlich? Ja, genau, die alten Sänger, was will der eigentlich von uns? Aber ja, früher war das nicht so selbstverständlich.

Genau, vielleicht reden wir noch mal über das Offline-Szenario, aber ich glaub, da macht es das sehr, sehr deutlich. Also früher, vor Caching, in den zentralen Versionsverwaltungssystemen, musste man quasi immer mit dem Server Kontakt aufnehmen, um eine Datei auszuchecken. Also das hieß, nur einer arbeitet an einer Datei zu jeder Zeit und das heißt, ich hab quasi einen Checkout auf eine Datei gemacht, hab dann exklusive Schreibrechte bekommen. Also das heißt, die Datei, die auf meiner Festplatte liegt, da wird der Schreibschutz weggenommen und sie wird quasi geloggt auf dem Server. Dann hab ich mal eine Änderung vorgenommen und dann hab ich das Ganze wieder eingecheckt, was bei geht halt entsprechend ein Commit und ein Pushes. Und dann ist dieser, ist dieser Schreiblock wieder bei mir im System gesetzt worden, so dass ich jetzt nicht mehr so einfach überschreiben kann. Und auf dem Server ist der quasi wiederum weggenommen worden. Ja, und das ist, deshalb ist dieses ganze Offline-Szenario mit den anderen Versionsverwaltungssystemen immer problematisch gewesen, weil schönes Beispiel ist, ich markiere eine Datei, checke sie zur Bearbeitung aus und setz mich dann in ein Flieger, wo ich vielleicht kein Netzwerk hab. Ja, und dann in der Zeit können alle Kolleginnen und Kollegen einfach nicht an dieser Datei arbeiten. Ja, oder man muss natürlich sagen, man nimmt diesen, diesen Checkout Vorgang auf dem Server weg, so dass alle anderen wieder arbeiten können. Aber dann hab ich natürlich ein Problem, sobald ich wieder Netzwerk habe und meine eine Änderung reinbringen will. Also das heißt, da muss ich dann wieder die nachpflegen und so weiter und deshalb ist dieses offline Szenario, wo wir heute einfach sagen, ja dann bearbeite doch offline und merge das Ganze hinterher. einfach so schwierig gewesen.

Ja, und das war immer Pain und wenn irgendwie der Kollege, der diesen Log oder ja, es hieß Log damals, gesetzt hat, wenn der nicht erreichbar war, dann musstest du zu irgendeinem Serveradmin, du musstest den vollquatschen, dass er doch vielleicht diesen Log wieder wegmacht. Also ja, das sind Schmerzen und das, also ich kann mir das gar nicht mehr vorstellen, ne, aber ich hab das mal erlebt und das ist einfach, war einfach immer Mist, ne, oder wenn du das dann quasi dieses Log wegbekommen hast, hast du es geändert, der Kollege kam zurück und hat gesagt, hey, ich habe da auch was geändert. Alleine schon, das war quasi schon ein Grund, das ganze System durcheinander zu bringen. Ja, ja. Aber gute Überleitung, du hast gesagt, es ging mehr um die Dateien. Und wenn wir jetzt aber über Git sprechen, gibt es das schöne Wort Snapshots. Und Git denkt in Snapshots. Ein Commit ist am Ende ein Snapshot eines Projekts und ein Snapshot ist quasi Ja, also Git funktioniert auf Ordnern, muss man mal so sagen. Fangen wir mal so an. Also jeder Ordner kann zu einem Git-Repository gemacht werden. Ihr braucht einfach die Kommandozeile von Git oder das Tool, gibt Gitini ein in diesem Ordner und schon erstellt Git hier Source Control System. Und das ist am Ende einfach nur ein Ordner, der versteckt ist oder ihr seht den auch, je nachdem, wie euer Betriebssystem konfiguriert ist und der hat das .git-Kürzel. und das ist ein Git-Repository. Klingt simpel, ist aber so. Also das hat mich am Anfang, wo ich damit angefangen hab, am meisten verwirrt, weil ich immer so, ja, jetzt muss ich ja irgendjemandem sagen, dass ich so ein Git-Repository gemacht hab. Ich brauch ja jemanden, aber es ist einfach nicht so, du machst das auf deiner Platte und du brauchst jetzt auch nicht irgendwie einen zentralen Platz dafür. Und by the way, in meiner Arbeit, wenn ich weiß, ich sitz länger an was, fang ich eigentlich immer damit an, mach einen Ordner, geh Init oder in Visual Studio Code gibt es ja auch dieses, machen wir einfach hier in diesem Ordner schnell ein Git-Repository und ich lasse das erst mal lokal und committe da lustig rein und habe dann quasi schon den Luxus eines Versions-Control-Systems mit einer Kommandozeile. Das gab es früher auch nicht. Also früher musstest du den zentralen Menschen fragen, der musste dir ein Projekt anlegen, ja, war nicht so einfach. Genau. Und zurück zu kommen zu Commits und zu Snapshots. Also wir haben jetzt diesen Ordner und in diesem Ordner entstehen Dateien, es entstehen Ordner, es entstehen Subordner und Git speichert jetzt quasi den Zustand dieser Ordner, Unterordner, Dateien, was auch immer. Ja, es ignoriert leere Ordner, außer man macht sie wirklich explizit bekannt, aber am Ende geht es da drum, was für Dateien sind in diesem Ordner und wenn ich jetzt einen Commit mache, macht Git dafür einen Snapshot. Ja, Und dann weiß auch Git, dieser Snapshot beinhaltet diese Dateien in einer bestimmten Version. Und da jetzt Git weiß, welche Versionen da aktiv sind, macht es quasi pro Datei auch solche genannte Hashes. Also nehmen wir jetzt an, wir haben ein Verzeichnis geöffnet, wir haben GitInny gemacht, jetzt haben wir quasi Source Control System und jetzt gehen wir hin und machen da hallo.txt rein, schreiben da irgendwie auch hallo rein, schließen die, speichern das. wenn ich jetzt mit Git@ diese Datei hinzufüge und mit GitCommit ein Commit provoziere, dann geht Git hin, nimmt diese Datei, hasht die Datei, also den ganzen Inhalt. Da wird noch ein bisschen mehr gemacht, also es wird noch gezippt und sowas, aber lassen wir mal weg. Und dieser Hash, der dann wirklich ja eindeutig ist, also in der Passwortfolge haben wir über Hashing geredet, also der Hash ist quasi ein Abbild des Inhalts von dieser Datei und speichert den quasi, diese Datei mit dem Hashnamen in diesem Git-Folder und baut dann noch so eine kleine Art Datenbank auf und sagt, hey, der erste Commit, ja, wir müssen noch eine Commit-Message eingeben, was machen wir? Hello World, wer hätte es gedacht? Und in dieser Hello World Commit ist dann quasi dieser eine Hash verdrahtet und das ist das ganze Geheimnis. Und wenn wir jetzt, nehmen wir mal noch an, wir machen eine zweite Datei, die heißt hello2.txt, da steht hello2 drin und machen jetzt einen Commit, dann haben wir ja quasi unsere Hello txt, Hello 2, txt. Und wenn wir jetzt aber ein Commit machen, haben wir ja quasi nur diese Hello 2 geändert. Und wenn jetzt Git hingeht und sagt, ah, jetzt sind da ja zwei Dateien, ist es nicht so, dass es jetzt für diese beiden Dateien irgendwie einen Hash erzeugt und sagt, ich tue mir das wegkopieren, also eine volle Kopie macht, sondern es hasht quasi nur das, was jetzt so der Unterschied ist und erzeugt dafür einen Hash und speichert das dann, Das heißt, der zweite Commit in dieser Datenbank würde auf den alten Hash zeigen, den wir schon hatten, vom ersten Commit, und würde aber dann für diese zweite Datei einen neuen Hash erzeugen und das dann so abspannen. Konnte ich das erklären, Tobi?

Ich denke schon.

Ich habe es verstanden. Genau. Und was man halt erreicht, ist, dass ich quasi den Ordnerinhalt versioniere und nicht mehr so wie früher irgendwie in Dateien denke. Weil meistens geht es ja beim Entwickeln, ich habe irgendwie einen Ordner und in diesem Ordner arbeite ich und alles, was da drin passiert, gehört irgendwie meistens zusammen und das versuche ich zu resonieren.

Ich find diese dieses diese Idee vom Snapshot eigentlich tatsächlich ganz charmant beim drüber nachdenken, also dass man sagt, man hat quasi den Schnappschuss von von etwas und hat da ein Bild des aktuellen Zustandes und das ist quasi der Hashwert, ja, und nicht so sehr wie in diesen anderen. Dateiverwaltungssystem, wo du halt jede Datei hast und quasi eine Änderungshistorie für jede Datei und das nur zufällig zu einer bestimmten Version gemeinsam getaggt ist oder ähnliches.

Ja, und wichtig ist noch, vielleicht auch noch, also das gibt es manchmal, dass das Leute nicht wissen, das funktioniert gut, wenn es textuelle Dateien sind. Also Text ist Source Code, ist TXT, ist Markdown. Aber wenn es um binäre Dateien geht, es gibt eigentlich das falsche Tool. Also wenn ich jetzt anfange, da irgendwie, ich versuche da, keine Ahnung, was ich versionieren will, ein Lieferant liefert mir irgendwie Programme auf CDs.

Ja gut, es fängt schon bei PDF-Dokumenten an oder PDF-Dokumente.

Und jetzt fange ich an, diese PDF-Dokumente einzuchecken, schafft das Git auch, aber es ist eigentlich nicht dafür gedacht. Es gibt so ein paar Kniffe, wie man das vielleicht dann doch hinbekommt, aber ja, eigentlich eher nicht, würde ich jetzt mal sagen, oder Powerpoint-Dateien oder was auch immer, ne? Da würde ich mir Gedanken machen, ob das der richtige Weg ist.

Auch da, letztendlich wird das zu einem Speicherplatzproblem, weil wenn wir eine Binärdatei einchecken, die da tendenziell eher größer ist, also meine 300 Megabyte Powerpoint, wie du schön sagst, ja, und jetzt machen wir Snapshot auf Snapshot auf Snapshot und hat jedes Mal können die nicht verglichen werden und die Historie wächst einfach unheimlich an. Ja, also Binärdateien vermeiden.

Genau, und Man unterscheidet so drei Bereiche bei Git. Das eine ist quasi das Working Directory. Also gehen wir zurück, wir haben unseren Ordner, da ist dieser versteckte .git-Ordner drin und unsere zwei Textdateien, das ist quasi eigentlich mein Working Directory. Das ist quasi, ich kann das jetzt öffnen, wo auch immer ich will und kann dann da irgendwas tun, Dateien hinzufügen, Dateien bearbeiten, das ist das Working Directory. Dann gibt es sogenannte Staging Area. Das heißt, wenn ihr jetzt zum Beispiel, und das funktioniert für AI agently coding ganz cool, by the way, aber vielleicht gleich nachher noch da was dazu am Ende, wenn ich jetzt, nehmen wir mal an, ich arbeite jetzt an meinen Textdateien, ich habe ganze zwei Stück davon und jetzt habe ich so eine halbe Stunde gearbeitet und denke mir, ist jetzt noch nicht ganz fertig, also ich will es noch nicht committen, aber ich will es eigentlich auch nicht verlieren, weil ich bin mir nicht ganz sicher, vielleicht geht es ja wieder kaputt. dann kann ich diese 2 Dateien, den Zustand, in dem jetzt gerade herrscht, kann ich quasi stagen. Ja, also das geht nicht in die Historie, ist aber für mich so eine Art Snapshot auf meiner lokalen Maschine. Bedeutet, wenn jetzt irgendwas schief geht, ja, kann ich wieder zurück zu diesem gestagten oder ich kann auch quasi meine aktuelle Version gegen die gestagte Version vergleichen. Ja, das ist quasi so 'nen Commit oder so eine Sammlung. Ich bin eigentlich ganz zufrieden, lass mich das mal stagen und wenn ich dann fertig bin, committe ich das auch. Genau, und dann gibt es noch die Commit-Historie. Das ist eigentlich das, was so in eurem .git-Ordner drin ist. Das ist quasi halt eigentlich das Repository selber mit der kompletten Historie. Also, und wir haben ja vorher gesagt, pro Commit wird, wenn eine Datei geändert wird, wird ein Hash erzeugt und diese Hashes, werden verkettet. Und diese Verkettung, also jeder Commit hat quasi einen Parent-Hash und einen eigenen Hash. Und dadurch, dass man diese, so eine Kette baut, so ein bisschen wie Blockchain in Anführungszeichen, dann, dadurch hat man eine gewisse Integrität und jeder Commit ist adressierbar, weil er hat einen Hash. Die Historie ist überprüfbar, ich kann da durchgehend gehen und gucken, ist diese Verkettung in Ordnung? Ja, und wenn ja, dann weiß ich, alles war O. K., es ist, ist nie manipuliert worden. Wenn ich jetzt so einen, du hast vorhin gesagt, man kann da nichts ändern, man kann schon was ändern, aber diese, diese Veränderungen erzeugen eigentlich eine neue Historie. Ja, also man kriegt das dann wieder mit. Ja, aber wichtig ist noch, diese Hashes sind natürlich Also man kann jetzt nicht anfangen und sagen, ich arbeite in einem Team und irgendwie gibt es, weiß ich nicht, 2 Gruppen. Und jetzt kann ich sagen, ja, aber die, die eine Gruppe soll nur Ordner A sehen und die andere Gruppe nur Ordner B oder sowas. Das gibt es nicht. Das gab es früher auch bei diesem Remote Versionsverwaltungssystem, dass man teilweise auch so Sachen verstecken konnte vor bestimmten Benutzergruppen. Bei Git gibt es das nicht, ne? Also Hashes und Git kennt eigentlich keine, keine Rechteverwaltung. Du kriegst immer alles oder gar nichts auf inklusive Historie, inklusive Historie, genau.

Ja, spannend find ich die Tatsache, dass ein Branch eigentlich nur ein ein Pointer ist und damit auch fundamental vom Konzept her anders ist als zum Beispiel bei Team Foundation Server Version Control. Also ein Branch ist sozusagen keine zweite Kopie, die ich von diesem ganzen Zweig mache, sondern nur ein Pointer auf einen Commit oder auf einen aktuellen Zustand, den man hat. Das heißt, wenn man auch auf der lokalen Festplatte ist und den Branch wechselt von beispielsweise Mainbranch auf meinen Featurebranch, ja, wo ich jetzt gerade was entwickel, dann ändern sich die die Dateien auf der Festplatte, weil sie natürlich diesen diesen Zustand, diesen Snapshot im Prinzip des anderen Branches übernehmen. Ja, es ist aber keine zweite Kopie und da ist, glaub ich, auch eine fundamentale Unterschied zwischen dem, wie man das letztendlich bei serverbasierten Versionskontrollsystemen hat, wo man tatsächlich echte physische Kopien hat von verschiedenen Zweigen, von beispielsweise einem Dev-Zweig und einem Testzweig und einem Production-Zweig oder oder ähnliches. Ja, also das heißt, man hat die also eine Datei in 3 verschiedenen Zuständen, in 3 verschiedenen Verzeichnissen. In diesem Fall bei Git ist es quasi ein Pointer, der quasi auf einen Zustand zeigt und damit kann man halt auch relativ schnell die die Branches letztendlich wechseln, auf denen man unterwegs ist.

Ja, genau, also ihr sagt, ich will jetzt in einen bestimmten Branch, ja, dann muss er ja nur noch gucken, welche Hashes sind da aktiv und dann halt quasi diese Dateien in den Zustand bringen, ja, aber er fängt jetzt nicht an, quasi alles zu kopieren, das wär ja Wahnsinn, ne, am Ende ist ein Branch eigentlich nur so eine Art Zeiger auf einem bestimmten Hash, ne, und das ist dann quasi der Anfang von diesem, Branch und du hast jetzt das Wort schon gesagt, Feature Branch. Was ist dann ein Feature Branch, Tobi?

Ja, der Feature Branch ist genau dafür da, wenn ich an einem Feature arbeite. Also ich möchte in einer Software eine ein ein bestimmtes Feature umsetzen, dann branche ich für ein, mach ich ein Feature Branch aus dem Branch, wo ich gerade unterwegs bin, benenn den beispielsweise nach dem Feature, in dem ich arbeite und ja, check immer auf diesem Branch ein, um dann hinterher diesen Branch wieder mit dem ursprünglichen Branch zu mergen. Ja, weil da müssen die Linien wieder zusammengeführt werden. Ja, und das ist quasi das Gegenteil von Branching, ist Merging. Ja, und da wird halt einmal verglichen, was ist denn auf beiden Zweigen gleich. Ja, was wurde geändert, also in dem einen und in dem anderen und gibt es parallele Änderungen. Ja, und wo es dann letztendlich eine Entscheidung geben muss. Ja, wenn wir jetzt eine Datei haben, die in beiden Zweigen direkt geändert wurde, kann es natürlich sein, dass kein Konflikt vorliegt, weil das an verschiedenen Stellen innerhalb der Datei passiert. Es kann aber auch sein, dass natürlich die gleiche Stelle auf beiden Zweigen geändert wurde und dann muss da eine menschliche Entscheidung her und dieser Brunch muss halt einfach oder die, sorry, dieser Merge muss einfach gelöst werden. Ja, und damit ist, man nennt das natürlich immer Merge Conflict, ja, weil es 2 Änderungen gibt, das ist aber erst mal kein Fehler, das ist Teil des Systems. Ja, und das ist genau das Auflösen von von.

2 gleichen Änderungen und vielleicht noch mal den den Vergleich zu ganz früher. Ne, also ganz früher hat es jeder Developer, so einen genannt, seinen Dev-Brunch. Ja, das war so eine auch eine eine Strategie. Also ich bin Tobias, ich hatte irgendwie in diesem Remote Control Verwaltungssystem einen Tobias-Brunch. Ja, und auf dem konnt ich machen, was ich wollte und das hat aber, glaub ich, eher dazu geführt, dass ich halt auch gemacht hab, was ich wollte. Ja, und das jetzt nicht so Feature getrieben und warum mach ich denn was war und. Man muss ja auch so einen Branch, also wir haben vorher gesagt, der zeigt auf einen bestimmten Hash, auf einen bestimmten Zustand bei Git und auch remote, im Remote Control System muss ich ja auch, nehmen wir jetzt mal an, ich mache meinen Branch, also kein Feature Branch, mein Tobias Branch, gehe drei Wochen in Urlaub. Das Team arbeitet ja aber weiter. Das heißt, die Historie läuft ja weiter. Und wenn ich jetzt quasi aber da in meinem Developer Branch so ein paar lustige Erinnerungen hatte, hatte, wo ich gesagt hab, die behalte ich mal für mich, die will ich auch nicht committen. Und ich kam dann zurück und hab gesagt, jetzt muss ich 3 Wochen, also ich muss ja wieder auf den aktuellen Stand kommen, ich muss dann quasi so einen Pull machen oder ein Update auf den Hauptzweig, auf den Hauptbranch. Und das hat alleine schon meistens irgendwie dazu geführt, dass man sehr viel Kaffee trinken konnte, um diesen Merch überhaupt hinzubekommen. und und deswegen ist auch in der Softwareentwicklung dieses Konzept von jeder hat seinen Devbranch und macht was er will oder wie auch immer man arbeitet, ist eigentlich so 'n bisschen, ich würd sagen, obsolete. Vielleicht gibt es noch Gründe dafür, dass man es so tut, aber ich seh das eigentlich weniger und man arbeitet eigentlich eher Feature-Branch mäßig. Das heißt, ich will ja irgendwie eine User Story, einen Task umsetzen, erzeuge genau für diese, für diese eine Arbeit einen Feature-Branch und arbeite dann auf dem. Ja, und optimalerweise sollte das auch so sein, dass das jetzt nicht Wochen und Monate dauert. Ja, weil ich hab ja auch dort wieder das Problem, dass ich Dinge ändere und das, wenn es ein großes Team ist, oder es ist Open Source, geht die Welt ja weiter währenddessen. Ja, dann muss ich auch meinen Featurebranch aktualisieren, ja, oder pullen. Bedeutet, ich muss den, ich muss zum einen die ganze Historie holen und ich muss mein, mein Zeiger, mein Pointer, mein, mein Hash, auf den ich quasi aufbaue, muss ich nach vorne bringen in der Zeitleiste. Bedeutet auch, dann kann es wieder zu diesen Merch-Konflikten kommen, ne?

Ja, und mit deinem eigenen Punch bist du ja quasi im Yolo-Modus, ne.

Ich bin im Yolo-Modus.

Ja, ich hab schon, ich hab in der Vergangenheit große Freerides gesehen auf eigenen Zweigen, ja, die dann natürlich irgendwie mit dem Hauptzweig wieder zusammengeführt werden müssen. Das ist schon ganz schön schmerzhaft.

Das ist, ja, genau. Und deswegen auch immer schön klein und du hast vorher schon gesagt, kleine Commits. Und ich meine, hallo, wir machen jetzt eh alle Agent Decoding. Der Agent macht das sehr gerne für dich und der committed auch sehr oft. Ich war mal in dem Projekt, vielleicht hören die Leute zu. Und auf der anderen Seite war ein Kunde und wir haben natürlich auch sehr gerne programmiert und Die hatten es aber jetzt nicht so mit den Messages für die Commit-Messages. Also war eigentlich so, jeder Commit war einfach nur safe. Kann man sich auch sparen. Kannst du dir auch sparen, genau. Ja, und das haben wir immer ganz lustig durchgezogen. Also wir sind klargekommen, es war ein erfolgreiches Projekt, muss man dazu sagen, aber danach haben das andere übernommen und dann durfte ich nicht mehr safe schreiben, sondern musste sinnvolle Dinge hinschreiben und heute mit Agentic Coding ist es ja überhaupt kein Problem mehr. Also der macht das schon von alleine, muss es ihm gar nicht sagen, er schreibt irgendwie was Lustiges hin. Die Kunst ist, das zu lesen und vielleicht zu sagen, nee, passt oder passt nicht. Ja, ich glaube, lass uns mal ein bisschen über Workflows sprechen. Und ich glaube, einen habe ich schon so ein bisschen beschrieben. Also, wenn immer ich lokal was mache, mache ich einfach, get in it und leg los. Wenn ihr auf der Kommandozeile bleibt, müsst ihr quasi neu neue Dateien immer mit Git Add hinzufügen, mit Git Commit kann man dann quasi dann committen. Da geht dann meistens auch, wenn man jetzt nichts dazuschreibt, keine Message, geht irgendwie ein Editor auf, der auf dem System default ist, dann kann ich da was reinschreiben. Aber ich glaube, die wenigsten machen eigentlich irgendwie Kommandozeile heute noch, oder? Also ich glaube, Visual Studio Code ist ein ganz guter Standard oder irgendein Editor eures Vertrauens. Und die meisten haben inzwischen auch Git, Support irgendwie integriert, würde ich mal behaupten. Also das ist eigentlich auch das Verrückte. Das war ja früher auch nicht so gang und gäbe. Du musstest irgendwie immer gucken, wie kannst du denn mit dem Source Control System arbeiten in der Umgebung, in die du willst? Und es gab ja auch ganz viele Plugins in den File Explorer, dass ich dann halt quasi auf Fileebene irgendwie das tun konnte. Die waren aber meistens auch nicht so, ja, lass mal das, Vergangenheit. Also ihr werdet irgendwie so was haben wie Visual Code und dann ist das Beste, ihr macht irgendwie 'n Git Init oder ich weiß gar nicht, wie das heißt, erzeugen wir ein Git, lokales Git Repo und dann committed ihr rein. Und selbst wenn ihr was anderes macht, also das Visual Studio Code gar nicht verwendet, vielleicht und ihr seid in einem Texteditor, warum auch immer man das tun will, aber jetzt nehmen wir mal das Beispiel, dann kann ja Visual Studio Code auch als Parallelinstanz irgendwie aufbleiben. Ihr macht irgendwas und immer wenn ihr halt committen wollt, geht ihr in Visual Studio Code. Ja, ich glaub, ihr müsst nicht mehr die die Kommandozeilenbefehle lernen heutzutage. Genau, wenn man im Team arbeitet oder wenn es irgendwie ein Repository gibt, das irgendwo zentral oder die Kopie zentral noch irgendwo liegt, zum Beispiel auf GitHub, GitLab, wo auch immer, dann brauche ich eine URL. Und natürlich, mit dieser URL brauche ich auch Zugriff. Es gibt vielleicht auch irgendwie Server, da kann ich über diese URL erst noch nichts bekommen und ich muss mich irgendwie authentifizieren. Und wenn ich aber diese URL habe und ich habe auch irgendwie Rechte oder es ist Public verfügbar, kann ich einfach Git clonen mit dieser URL machen und dann wird quasi diese Arbeit gemacht mit, ich hole mir jetzt von dem aktuellen Zustand, auf dem diese URL zeigt, die komplette Kopie auf meine Festplatte. Und wenn ich jetzt sehen will, gibt es denn auf dieser URL, also nehmen wir an, ich habe das vor meinem Urlaub geklont, jetzt komme ich zurück und jetzt würde ich gerne wissen, hat sich denn in diesem Open Source Repository überhaupt was getan oder nicht? Kann ich einen Git-Fetch machen? dann sehe ich, ob da irgendwas Neues ist. Und wenn ich das jetzt auch holen will und quasi auch in meine Kopie integrieren will, dann mache ich einen Gitpull. Dann hole ich quasi auch, also Fetch schaut nur und Gitpull holt dann auch quasi wieder von dieser Remote-URL. Genau. Und nehmen wir jetzt mal an, wir haben keinen großen Feature-, Branch und Pull-Request-Workflow und ich kann direkt auf dieses Hauptrepository pushen, dann kann ich natürlich auch lokal Commits machen. Und wenn ich die jetzt in dieses Remote oder in dieses andere Repository bringen will, muss ich einen Git-Push ausführen. Ich kenne niemanden, der so arbeitet. Ich habe gerade überlegt. Selbst wenn du alleine arbeitest, ich glaube, gehst du meistens über irgendwie Feature-Branches, aber ja. Genau, Git-Fetches ist quasi auch immer an deinen Freund, weil du am Ende nichts änderst und du guckst nur remote. Das ist, glaube ich, eine wichtige Info.

Ja, aber über Branching haben wir grad schon gesprochen. Ja, mit Gitbranch kannst du dir einfach einen neuen Branch anlegen. Ja, also Gitbranch und den Namen, also mein mein tolles Feature X. Ja, und Gitswitch wechselt dir auf der Kommandozeile einfach den Branch. Visual Studio Code hast du einfach auch den den Branch Auswahl. Genau, letztendlich geht es darum, Gitmerge mit dem Branch nehmen, dann entsprechend wieder die Änderung in den Hauptbranch zu integrieren. Ja, wenn man, wie du schon gesagt hast, keinen großen Pull Request Workflow hat.

Ja, Tobi, also wir haben jetzt versucht, den Hörer zu erklären, was es gibt. Ja, ich glaub, Fazit ist, versucht das einfach, also wenn ihr das echt nicht tut, ich hoffe, es gibt wenige Menschen, die in diesem Zustand sind, versucht das einfach immer irgendwie zu verwenden. Es ist quasi auch so ein bisschen wie so, ja, wie so ein Fallschirm, ne, dass man halt einfach nicht ein Voll-Crash hinlegt und Wenn man das mal gewohnt ist, damit zu arbeiten, ist es auch gar kein großer Pain mehr. Und vielleicht, ja, ich glaube, die Kommandozeile ist immer so, wenn was schiefgeht und dann muss man eh drüber nachdenken. Aber ansonsten würde ich, glaube ich, immer erst mal irgendwie mit einem UI-Tool, so was wie Vision Street Code oder wie auch immer euer Editor heißt, ich glaube, der hat sicher GIP-Support und damit mal reinschauen, was kann der alles und wie funktioniert das?

Absolut. Ich würde sogar sagen, wer es nicht nutzt, hat eine Wissenslücke. Ist da jetzt vielleicht ein sehr, sehr bold Statement, wie man so schön sagt, aber ich glaube, man kommt einfach nicht mehr dran vorbei.

Man kommt nicht dran vorbei, nee. Ja, genau. Wir haben vorher gesagt oder du hast gesagt, Git und AI und ich meine, es ist nicht nur eine Wissenslücke und ich glaube, jeder, der irgendwie mit Agentic Coding unterwegs ist oder irgendwie ein AI-Tool zur Hand hat, für den ist das ja überhaupt kein Pain mehr. Also zum einen sind die getrimmt, das eh schon zu machen, zum anderen diese ganzen, die Commit Message, diese ganzen Sachen, die man da eintippen muss, das können die alles schon. Und somit ist Git und AI eine gute Kombination. Und ich glaube auch, dass Repositories wahrscheinlich umso wichtiger werden, umso mehr man Agentic Coding machen will, ne? Weil diese ganzen Spezifikationen oder diese ganzen, das ganze Wissen ist ja im Prinzip in der Git-Historie über ein Projekt. Ja, das heißt, auch die, die Commits, die stattgefunden haben, die Commit-Messages, wenn es nicht einfach nur safe ist, haben ja einen gewissen Wert, ne? Und deswegen, glaube ich, ist Versionskontrolle mit Agentic Coding ein Muss plus ein Pluspunkt, weil daraus auch besserer Kontext entstehen kann für so einen Agent.

Es ist ja auch euer Sicherheitsnetz, also dadurch, dass einfach mit A.I. viel, viel mehr Code geschrieben wird in kürzester Zeit, ist es einfach so eine Art Sicherheitsnetz, um um Zwischenstände zu sichern, um verschiedene Commits zu haben, um zu gucken, hey, da ist mir wieder was weggenommen worden, was ich aber eigentlich behalten wollte, solche Sachen.

Genau, und ja, also zum einen find ich es gut, also nehmen wir an, du, du machst mit so einem Coding Agents ein Feature und jetzt hat er so die erste Version gemacht, dann geh ich eigentlich hin, geh durch das Changeset, oh, ein neues Wort, das ist quasi das, was jetzt in dem Git-Zustand geändert wurde, also Dateien, die ich committen könnte, und geh die einmal durch, ja, und dadurch, dass ich ja Versionskontrollsystem hab, seh ich ja quasi auch den Div, also ich hoffe, die meisten kennen diese Ansicht, wo ich sehe, links ist das alte, rechts ist das neue und das hat sich in der Datei verändert. Und jetzt geh ich quasi diesen, dieses erste Changeset durch und alles, was ich gut finde, stashe ich schon mal weg und sag, finde ich gut, stashe ich. Dann gehe ich beim Durchgehen, mache ich mir Notizen, was ich denn noch vielleicht gerne anders hätte oder was ich anders sehe und gebe ihm das im zweiten Lauf. Hat jetzt aber einen Vorteil, weil wer der jetzt komplett, das gibt es ja manchmal, dass sie irgendwie durchdrehen oder komplett falsch abbiegen oder wie auch immer man das erklären will, dann habe ich ja nicht alles verloren, sondern es gab ja wirklich auch Dinge, die gut waren, plus meine Ansicht im Sinne von, was man ändern müsste und ich kann quasi wieder zurückgehen, ja, zu diesem, was ich gut fand, ja, und dafür stash ich eigentlich immer weg, ja, und wenn er dann fertig ist, geh ich quasi wieder durch das Change-Set, also die Stashes sind da nicht mehr dabei und sag, gut, gut, gut, ja, und irgendwann hab ich nur noch einen Stash und dann sag ich, hey, jetzt mach ich irgendwie auf meinem branchen Commit und mach vielleicht ein Pull-Rick-Fest oder was auch immer, ne, das ist so wie ich damit arbeite. Und das andere ist natürlich jetzt noch, wenn man diese Agentic Armee vor sich hat. Also du bist irgendwie Orchestrator von vier Coding-Agents in parallel. Dann habe ich ja dieses Problem, was man früher in Teams und auf Entwicklermaschinen hatte, habe ich ja quasi ohne Team auf meine Maschine gebracht, dass quasi, wenn ich es hart auf hart bringe, mehrere Agents oder vier oder fünf oder sechs parallel in diesem einen Verzeichnis arbeiten wollen. Und wenn ich jetzt mir nicht überlege, wie ich das irgendwie clever mache, kann ja der eine auch eine Datei ändern und der andere ändert sie auch wieder und irgendwie passt das alles nicht mehr zusammen. Das ist ja so der Ursprung von Versionsverwaltungssystemen. Genau. Und jetzt könnte ich natürlich auch anfangen, ich meine, wir haben ja vorhin gesagt, es ist dezentral, jetzt könnte ich natürlich auch sagen, ist ja kein Problem, dann hole ich mir halt einfach, keine Ahnung, ich will acht Agents haben, acht Ordner und mache jedes Mal dort ein Git Repository rein, eine volle Kopie. Ja, oder sagst du, hm, jetzt ist die Frage, wie viel Speicherplatz hab ich denn und wie groß ist das Repository, will ich das denn? Ja, und da kann man so machen, würd ich von abraten. Genau, und dafür gibt es inzwischen, oder es gab es schon immer, aber ich hab es nie benutzt vor Chanticoding, gibt es Working Trees. Ja, das heißt, ich kann quasi so tun, als wär in einem Verzeichnis ein ein Branch oder so eine so ein Zeiger auf einem bestimmten Stand. Ja, aber ich hab jetzt nicht die volle Historie da drin, also nicht den Punkt Git Folder. Ja, und das Schöne ist, dass ich dann so tun kann, als wär das 'n 'nen Branch und ich kann dann quasi auch wieder super committen. Das heißt, wenn ich 8 Agents hab, hab ich quasi 8 verschiedene Verzeichnisse mit Worktrees. Genau, das gibt es inzwischen auch in Visual Studio Code, wenn man Agenti Coding macht, kann man auch sagen, hier machen wir doch das auf oder diese Session auf Basis eines Worktrees. Und deswegen ist ist auch Git da dein wunderbarer Freund.

Ja, was hätten wir denn früher gern gewusst? Also letztendlich, Commits sind preiswert. Ja, man kann so viele davon haben, wie wie man will. Ja, sie stören nicht. Also Commit Early, Commit Offen, das ist so eine Sache, die man, die man sich das Herz nehmen sollte. Also nicht, ich sag mal, das große Werk am Ende einchecken, ja, sondern viele zwischen Commits machen. Ja, und wenn es funktioniert, wohl wirklich auch pushen. Ja, genauso wie Branches. Branches zu erstellen und wieder zusammenzuführen ist am Ende nicht mehr, nicht mehr riesen Aufwand. Ja, und deshalb, wenn man aus dieser Welt kommt, wo es, wo das nicht so einfach ging, ist es so im ersten Mal so, huhu, wir brauchen hier einen Brunch, aber es ist überhaupt kein großes Problem, in Git zu branchen. Ja, und deshalb, ja, Branches sind einfach auch keine Angstgegner. Ja, ja, Stashing ist super sinnvoll, Ja, sollte man sich auch angewöhnen, wenn man das braucht. Gute Messages sind auch irre wichtig hier in jedem Commit, einfach damit man auch Sachen wiederfindet in der im Historienbaum. Ja, und eine Sache, die ich auch immer sagen würde, ist so ein Git Ignore File, also das sind diese Verzeichnisse, stehen im Git Ignore File drin, die genau nicht ins Inversionsverwaltungssystem sollen, also wie zum Beispiel Notmodule oder so, ab dem Tag 1 benutzen, so dass man es hinterher nicht wieder rausholen muss.

Genau. Ja, ich glaube, wir haben euch viel erzählt jetzt über Git. Ich hoffe immer noch. Also ich habe ein bisschen überlegt, braucht man so eine Folge oder nicht? Aber ich glaube, auch mit AI Coding macht es Sinn, dass Menschen Git benutzen. Und eigentlich ist es so mehr so ein bisschen eine Motivation, dass wenn jemand das noch nicht macht, dass er das vielleicht anfängt. Ja, wenn ihr im Team arbeitet, benutzt vielleicht irgendwie so einen Pull Request Workflow, also Feature Branch, der wird gepusht auf das, auf das, auf die Zentrale und dort muss ich dann quasi über einen Pull Request in den Main rein committen oder rein mergen, weil so auch sichergestellt ist, dass quasi gewisse, weiß ich nicht, gewisse Qualitätsdinge, vielleicht laufen irgendwelche Pipelines, tun noch irgendwas scannen, abgedeckt sind und ich auch irgendwie Feedback bekomme und machen Coding Agents auch sehr gerne und ich glaube, das ist auch ein gutes Mittel. Ja, also benutzt Git, wenn ihr es noch nicht getan habt, versucht es vielleicht auch viel öfter zu benutzen, gerade auch mit AI-Tools. Ich meine, Text ist sehr schnell erzeugt oder Content ist sehr schnell erzeugt und sehr schnell geht es halt auch schief. Also jeder kennt das, wenn der Agent irgendwie jetzt doch nicht mehr so ist, wie ich das gerne hätte und ihm erzählt, ja, ich mach das und er macht irgendwie was ganz anderes, dann kann es halt gut sein, dass ich irgendwie im Regen stehe und mit mit deiner Strategie im Sinne von, ich stash das oder ich committe öfter oder wie auch immer man damit umgeht und wie der eigene Workflow mit AI-Tools dann aussieht, ist, glaube ich, jetzt auch hier dein größter Freund. Und so wie Toby grad gesagt hat, es kostet euch nichts. Das ist wirklich billig auf eurer Platte erst mal, beziehungsweise auch diese Commits. Das ist nicht so wie früher, dass da irgendwie 1000 Sachen gemacht werden müssen. Ja, genau. Und in diesem Sinne, es gibt noch ein Buch, packen wir euch in die Shownotes.

Pro Git, genau, kostenfrei herunterzuladen, liest sich spannend wie ein Abenteuerroman. Also von daher gibt es eigentlich nichts, was einen abhalten sollte.

Ja, genau, aber ja, vielleicht noch eine kleine, ein kleiner Ausblick, wo vielleicht die Reise hingeht oder was, was mir andere Leute überlegen. Es gibt dieses schöne Projekt Entire I. O., das ist vom ehemaligen CIO von GitHub, C. Und er hat sich überlegt, Coding Agents fangen jetzt hier an. Also ich habe irgendwie einen Prompt gehabt oder ich habe irgendwie einen Input, User Story, und irgendwie wird jetzt ja quasi so eine Session aufgebaut, also das Kontext Window. Und das ist ja unheimlich auch wertvoll im Sinne von, wenn ich diese Sessions behalten kann, mit meinem Code können ja vielleicht andere Agents nachvollziehen, warum der Commit so gekommen ist, wie er war. Also nicht nur diese Commit-Message ist vielleicht eine Aussagekraft oder hat eine Aussagekraft, sondern auch diese komplette Session zu diesem Commit, wie auch immer er entstanden ist. Und das ist so ein bisschen die Idee von Entire I.O., ne, dass man quasi ganz normal Git verwendet, so wie es ist. Aber jeder Commit, der da so stattfindet, hat quasi noch Zusatzinformationen, ne. Also den Prompt, die Response und vielleicht welche Tools da aufgerufen wurde, um zu diesem Ergebnis zu kommen. Also habe ich irgendwie einen MCP Server gefragt und weiß ich nicht, Daten von irgendwoher gezogen und auch dieser Reasoning oder dieser Kontext soll da mit so drin sein. Und ich finde die Idee spannend und ich glaube, das geht vielleicht in die richtige Richtung. Und das ist das, was wir vielleicht später oder irgendwann mal auch als Standard dann jeder benutzt, dass man irgendwie diese Sessions nicht verlieren will.

Ja, wir packen den Link einfach auch in die Shownotes. In diesem Sinne war es das für uns bei Tobi hoch 2. Es hat Spaß gemacht, das Thema mit euch zu teilen. Wenn ihr weitere Gedanken oder Fragen habt, schreibt uns doch eine E-Mail. Gerne auch, wenn ihr Themenwünsche habt. Bis zum nächsten Mal bei Tobi hoch 2, wenn es wieder heißt: Doppel Tobi, Doppeltech. Ciao, ciao.

Welcome to a new episode of Tobioth Zwei. As you hear, this is a premiere for us. It's the first podcast in English since we have a guest. Welcome, Karthik Rameshkumar, field CTO of GitHub. In this episode, we want to discuss AI coding, what is new on the horizon, and also what skills do we need in the future. So even if you are not a developer, this episode might be useful for you since we're talking about how to apply skills to your daily doings. So without further ado, welcome, Karthik.

Hey, thank you so much to the two Tobys for welcoming me on the podcast. I think the conversation to get on this podcast started a long time ago, but I'm so grateful to be here with all of you and be able to present whatever little I can share and the insights I can share with all of you. I'm looking forward to having a nice conversation.

Thanks. Thanks a lot for being our guest. Yeah.

Big pleasure. And for the audience, Karthik is sitting in front of us with a t-shirt from a German soccer team. Very, very good.

So I was just telling you that actually finding the German soccer team's t-shirt, this is special for the Tobbys, but finding the German soccer team's t-shirt is actually really difficult in Bangalore. I had to buy this one in Bangkok myself personally. So it usually goes on sale and sells out on day zero. So yeah, I'm a big fan of the German football team. Yeah. So let's see. World Cup coming soon?

Awesome.

Yeah, Karthik, what is a GitHub field CTO? What is your job, your new role, by the way?

It's a fantastic question because I think I'm trying to actively discover it as we are building towards it together. In a lot of ways, I think the GitHub field CTO is sort of a strategic stakeholder for all of the engineering leaders in the region for them to be able to have a singular point of contact on the GitHub side. I think the intent with this basically is to have someone that can have high-level conversations with stakeholders on the customer side, was the internal teams that we can then build a bridge and a liaison for a product features that we're trying to build, strategic conversations that we're trying to nurture around what direction a product should lead. And 3, to also feedback all of the signals back to our engineering team so that we can then refine our processes and build better software that our users will end up using a lot more. So I consider myself a custodian of our customers' experience on the platform. And my job is to have conversations with developers, have conversations with engineering leaders, have conversations with people that are part of the development ecosystem, testers, all the other people, right? then feed that information back so that the product team then is then able to take a holistic decision on prioritizing what features need to be delivered first to our customers. And in addition to that, I also help to sort of drive a little bit of understanding on where our thought leadership around the developer lifecycle basically comes for GitHub, right? I do a lot of talks. I do a lot of writing on LinkedIn. I do a lot of scrambling, sort of scribbling myself, sorry, to sort of write what I feel like my thoughts. And this sort of helps put the message out there in terms of what the development lifecycle looks like and to share a little bit of my two cents on where the world is going and what my observations are. And I think of late, the thing that I love about my role is that I think I sort of become like a best practices disseminator, right? So I get to talk to a lot of customers who are in the same boat. So Customers are very curious because sometimes when you're competitors, you don't get to talk to each other. But then at least with me, you can at least understand industry trends, right? Hey, if you're a bank, what are the banks thinking about? What direction do they want to go in? What does good look like is a fantastic role that I get to play. I think I'm excited about those roles together to sort of bring sort of insight into these boardroom discussions with leaders and help them build better software together with their teams, I think it's a very exciting role to have. But we're actively building it, and we're looking forward to all sorts of feedback on how to make that role better and more impactful for everyone.

It sounds very, very interesting, I would say. Cool. Yeah, let's speak later about that, what you speak with customers, because I think it's a tough time, because a lot of change, it's a fast piece of innovation. But one question, you mentioned region for the audience. You are from the Asia region, or what is your scope of where you're working with customers? This.

Is very interesting, because I think the first time I met Tobi's Opia is actually at an event where we were actually working with another customer. Shockingly, this customer is not an Asian customer, as in they don't have their headquarters in Asia. They're basically based out of Europe, somewhere else. So ironically, this podcast is happening because of one of the reasons why Asia is very unique, right? If you look at it, Asia has sort of become the developer center of the world, right? There's a lot of gravity that's shifted towards here because I think over time, one of the things that's been realized is that Asia has a ton of engineering talent, software engineering talent that passes out of its institutions and colleges. And this talent has now been able to then be employed in significantly impactful work across a long time. This started with all of the big GSIs, sort of a thing in India, and then a large part of a lot of the other Asian companies started off. But what's happened since 2020 2012, 2014 is that I think Asia sort of become the center, epicenter of software development in the world. So I jokingly say, right, so you guys can all go check it out. Actually, GitHub has this Octoverse metrics where we actually put the total number of developers in every continent and everything. Actually, if you go and look at Asia as a unit, it basically... smashes through the developer records on every other content whatsoever, right? Because it's just so many developers here and people that really want to try to get their hands dirty and more joining, right? Like I think one figure that I saw out of India is that I think every year we had about 300,000 software developers just from our tier one engineering colleges. I'm not even thinking about community colleges and all of those which add more developers. I'm just talking about people that graduate in computing sciences just every year is 300,000 people. That's a lot of people. that graduate in the core science. So I think that's the reason why, right? There's a ton of really smart talent coming out there, which means that a lot of the large European American organizations are setting up global capability centers in Bengaluru, in Pune, in Hyderabad, in Hanoi, in Vietnam. They're setting up centers in Singapore to drive conversations. They're doing it in Hong Kong, right? Australia, there's so many places where people are building these capability centers. I think what's happened is Microsoft is a fantastic example ourselves, where we are all gainfully employed. One of the things we understand is that Microsoft is a huge development team based out of Hyderabad. A large part of our development happens there in what we lovingly call the India Development Center, the IDC, right? So all of these are very interesting sort of views of where this epicenter has happened. So I'm uniquely positioned to kind of answer this culture because I work with customers on both spectrums, right? I understand how these products are built and what customer personas they're trying to look at. And then I understand sort of the builder persona out here who's sort of trying to fulfill those needs. And then I'm able to then bridge these two together in a way which is very unique to me. So I think this India perspective and the Asia perspective is very relevant to this conversation because a lot of the bleeding edge work is now being done out of here. If you see innovation centers, right, largely for a large number of European organizations, innovation centers are based out of India, based out of Singapore, based out of parts of Asia. It's spectacular to see the kind of thing. And all of this has then had bleeding effects for the economy ourselves, right? For digital payments to technology. That means that it's not just European companies that have had the explosion. It means that there are more organizations here who are building for the local market and therefore it starts a virtuous cycle of people building for other people. And it's a beautiful sort of ecosystem that's developed in itself. So I think that's the beauty of Asia. So if you look at Europe, I see a lot of, when I go to Europe and when I go to the Americas, there's a lot of innovation going on there. There's a lot of R&D. And then all of that R&D comes to India and other parts of Asia to get built, right? And sort of the bleeding edge and then, oh, what do we do differently? How do we move it forward? So I think that's a very unique perspective of this globalized economy, right? Where everybody's work feeds into someone else's work. And it's very exciting to see as we sort of go forward.

This also mirrors like our experience. So I have had like one project with colleagues of ours in Hyderabad, and Toby and I myself, we had a workshop together in Bangalore, and I was also recently in Bangalore. And the kind of hunger from everybody, you know, to innovate, to create something new that was really amazing. And when you walk through the streets, there are like posters on the streets saying like, Here you can learn about DevOps or you can learn about programming and stuff like that. And I haven't seen anything like that in Europe in one way or another. So that was really astonishing to see how much is actually coming out of these cities.

Yeah. And the energy, like Toby said, it's a different game, I would say. And you said we give it to you to produce, I think. There's already a change. Something like the idea comes from China or from India. And yeah, I would not say that we don't, can achieve something here in Europe or in Germany, but I think we need to adapt. We got a little bit lazy, I would say. I think now people are ****** on the podcast, but that's really my opinion. You should go there and you should feel that energy and it's like, wow, people, People behave different. And they have that energy and the smiley face and they want. The motivation is a different on a lot of people, I would say, not on everybody. Yeah, we were speaking about AI or we want to speak about AI. So Karthik, every day we wake up, every day something is new. How to manage the pace of fast innovation in AI area? What is your personal approach with that?

God, where do I get started? I think this is such a huge, this is such a huge part of our sort of where we have what our opportunity areas are as we sort of go forward. So there's a couple of ways to break it down, right? Like think about this. I think if we look at the pace of growth in this industry, I think There's two ways to look at this. Think about this. There's this one analogy that I read online that was very interesting where people said, you all think the AI way was really done a lot? Imagine this. If you were someone that lived in pre-World War I Europe, for example, right? Versus someone that came after World War I Europe, for example. And then let's assume that 10 years between here and there, you would have seen the growth of automobiles. You would have seen the ability for people to not have to do horse-drawn carts. You would have seen public lighting in most major cities in Europe. You would have seen commercial flight finally happening, right? The Wright brothers to commercial flight happening was like five, eight, nine years. So what people, some advocates of change and some people that really study this philosophy of how human scale change happens over time basically say that it's actually not very significant, that we have had other times in our past where we've gone very differently. Let's assume we put someone on a deserted island before World War I, when they came after World War II, they would see the whole world completely changed. So that's a huge mind shift because things became easier, things became more healthy. There was an entire pandemic. So many things happened in that time frame, right? So That's the beauty, right? So if we zoom out and look at it, then there, but today, because we are a large part of us are involved in that hype cycle, let's, I'm going to break it. This is a hype cycle, right? There's always a trough and a crest. There's so much going on that we all have to deal with, which is so shocking. Every day when you open Reddit is basically thread after thread after thread. Hacker news today is a whole different thing. Product hunt. was one of my favorites and every post and product is about an AI company that's now trying to anything that's to do with AI, for example, right? So whatever we used to do, there's an AI way of doing that right now differently and something new every day. Even in our own platform like GitHub, which I can speak about, right? Like we have change logs that I now subscribe to our own RSS feed. to be honest, because the pace at which the RSS feeds come out is easy. I get a notification from my mobile phone, and then I can see the change logs of what we're changing, you know, new models coming out, new things are different. So it's so fast and exciting for us that it's not. I think in one way, the AI wave has fed the AI wave in a lot of ways. So think about it. We are using AI to build these tools.

Yes, yes.

And then therefore we are building faster and then we are pushing more things and more impactful releases for our customers. I think it's wild to sort of see sort of how fast it goes. So I think for me, I think the intentionality is true. That's the first piece, right? You have to have an intention to gather more information, one. And two, I think today the more important job is filtering. critical information that you should consume versus what is information you can deflect and say, just know about a little bit and then go forward. So I think levels of knowledge is sort of what I've done. So I basically say, if I need to know this, I need to know all about this and I'll do deep research. If I need to know only what it does, I just need to know what it does. And then if it's really interesting, I'll get my hands dirty over the weekend. But if I were to get my hands dirty on every AI innovation that came in the past week, You would need an entire week to do that. just doesn't work.

Yeah, I agree. And I think what we want also from Toby and Toby give a message is, I think it's a hype, yes, but I think it's a change. When we think about software development lifecycle, and I think there's so much improvement, I think the... The biggest challenge is nobody knows how to make that in a professional way. What is the new software development life cycle with AI? Where does it work good? What are good patterns? Tools, like we said, is you wake up, there's a new tool. So the tool sets are not like in past, yes, you start a new project and you know what kind of tools you need for that and which roles. But I think, and the message what we want to give for the audience is there will be a change. I'm 100% sure. We don't know how and we don't know how much was hype and how it will be in the future. But when you are a listener and you are not working with AI and you are somewhere on the software development lifecycle, I would highly recommend you start with it. And like Karthik say, don't take everything serious what comes out. But yeah, start. That I think is a big message.

Definitely. I also like the historic comparison you were making. Like I was just, while you were speaking, thinking about when you say pre-World War One, for example, that was my grandfather's father's generation. So, you know, that's not that far away from me because, you know, my grandfather is dead now. But I actually, well, I think he died when I was 12 or something like that. However, I mean, I never met his father, of course, but I have photographs from him and stuff like that. So that's not like historically not that far away from me nowadays, and. even when the pace now accelerates with everything, it is also pretty clear that when you have like a long-term project of a year or one in a year and a half or so, the stack that you started with will be probably different than the stack you're ending up on at the end of the project because so much is happening in between, and you have to be really agile about it and don't like stick to the pattern that have always worked with you, but rather adapt to like new patterns and new software stacks and everything.

Yeah, I think it's a mind shift. Mindset shift, it's really something what is hard, because mindset shift is also always hard to manage, to achieve and to go through it. Yeah, let's discuss about software development lifecycle. I think we have the different phases and what I observe when you use AI, it's changing because maybe a role can make different things because of large language models. What is your thought about that?

I think we spoke about this a bit before, and I think me and Toby have discussed this when he was in Bangalore as well. The beauty about this was that one of the things that we noticed is that while there's a lot of this change going on about the software developer life cycle and how people are changing things around this, and there's so much innovation, and every new product is coming out there, every other week there's someone new launching, something new about some part of the software developer life cycle. I think the idea is that there's the underlying shift of skill sets that we need to talk about of what's sort of essential for success as we grow. I think I see a large amount of change that's happened already in the code generation space that's already sort of now plateaued, right? So I think we know for a fact that AI can write code. We know we've understood AI can write good code now. And I think with the more models that are coming up, we know that AI can write and validate the code it's written in significant ways. I think the innovation that's happening right now is on sort of agents for every single area of that part after the code's been written. Do we want to check the quality of the code that we wrote? Do we want to check the validity of the methods that were written to sort of carry out the functions of what the code's supposed to do? Are we writing code that conforms to organizational standards or international standards for security, for quality, for styling, for all of those things, right? So I think in a large part of this, I think the most important piece, and I think everybody's got to think about is that your skill sets of what you do are basically what AI models are trained on. So if you're a really good tester, an AI agent that specializes in testing basically then has the skills of what you do potentially well testing and sort of it then learns from the code that you wrote is where the public conscience for the AI LLMs are. And the more parameters we train these LLMs on, the more volume of capability that they have to sort of then learn it. So when we talk about trillion parameters and all those in models, that's what we mean is that they then are able to then sort of collect more information across different sources and then be able to take that information and give it as more insightful responses for you. So I see that in the rest of the phases of the software level lifecycle, there's a large shift happening on how we can implement it right now. I think code generation already there. I think very easy use cases. I think most organizations across the world have some form of AI in that part of the lifecycle. And as they go into sort of then after generating code, what do you do with the code that's been generated? Validation, testing. in a QA, maintenance, all those things are sort of where they're sort of going into next, right? And I think all of this then feeds into what they're trying to build as a product over sort of a longer period of time as an organization. So it can then contribute to your bottom line. So if you're saving more time, building more features, making customers happier, and at the end of the day, that drives positive revenue growth for all of them, right? So I think it's a very interesting sort of a place we're in right now, where we then What after coding is the million-dollar question that people are asking now?

Yes, and what I observe is in past it was that time of the truth is in the code, so you have people they was testing and they come to you as a developer and said... Why is it not working? So where did you check it? In the code. Because there was the truth. There was written what it really does. The documentation and requirements maybe was outdated, let's say like that, because of laziness or because of this amount of work what you need to put in to update that stuff all. But what I observed with AI, it's a button click. So even the tester can give that question to an AI agent and say, hey, why this code is behaving like that? I expect it differently and gets tester role explanation, even when he don't understand the code, it's transformed for him as an example, what is really, really cool. Yeah, that's, and I see a lot of improvement, like you said. There comes some issues because of telemetry. You see there is something in production agents starting and grabbing this context and research your code base and give you maybe some kind of a root cause analyzer. And maybe next step is to say, hey, here's some kind of a branch and then check it out. I think it's a fix. And how cool is that? You're sleeping, your software is not working, you're waking up and It's something there. Someone was already working on that. And yeah, it's a big shift, I think.

Sort of one thing that we discussed was very interesting is that human beings need eight or 10 hours of rest.

Yeah.

We work eight or 10 hours and then we have the rest of the day to ourselves. But the beauty of the AI agents that we have to realize is that they're able to just constantly work 16, 18, 20, 24 hours a day, if you want. There's no limit to them. And the beauty of it is, Every software engineer now with agents basically can then say, I'm going to spin up 20 agents that do 15 different things for me. And then I can then concentrate on this one task that I think is subliminally important for this use case and just focus on that and say, OK, I'm going to focus on this system architecture piece while you build the UI, you build the test, and you build the framework around it. And then you then validate that I've written everything correctly. And then four agents go about doing what they're doing in parallel. So I think we started seeing this towards the end of last year where agents started exploding. I think what we're seeing now is how can we make these agents context-rich? And again, this is just in three months. By last year, I just mean December. November, December, when the whole agent thing is only one quarter in, the conversations around how do we wrangle these agents? Is it skills? Is it MCP? Now there's a bigger conversation around those things. What are the right places to give custom instructions for our agents, whichever agent you're using? So all those pieces are very important. So I think if I look at sort of where we will shift, I'm very excited for the future because that means that as human beings and human developers, we focus more on really meaningful pieces of work that drive change, like impactful change, rather than actually sitting and building a UI, which is like a solved problem, like how many login screens do you want to design?

Yeah, exactly. Exactly. I thought about that. I have a, um, I follow one guy about the stock market and he write really manual articles. And then I, I ask myself why I give that guy 20 euro per month. It can do a large language model. And then I read that article and I thought it can be done by a large language model, but I need to know what I put into the prompt to to get that result. So even his experience and his thinking about that world, I don't have it. So I would not be able to make that prompt and to get that prompt. point of view in some kind of a large language model generated article. And I think that is something what made me think about software. So like you said, log-in forms, I think average can now everybody. But to make it more advanced, you still need to think. You still need to guide that thing and say, hey, I don't want to have that standard log-in form. I want to have that. nice one why ever what is what means nice yeah but I think that is now something like you said people can more concentrate about user experience about how I make my software better and not about how to achieve the the average I would say.

Kind of leveling the playing field for everybody I think yeah and if you want to be be or create a high quality product this is like the the human work you can put on top yeah absolutely yeah.

Which then sort of naturally segues us to this million-dollar question, right? Which I think is the most often asked question that I get is, okay, how about my job?

Yes. Yeah.

If only I had a penny for every time someone asked me that job is the question. No, no. I think it's very interesting. I think this is something that came up in many different places, including the European Parliament, if I'm not wrong. I think this was brought up as a very active conversation where they spoke about it. I was very intrigued by the whole debate where they spoke about this. The way I look at it, I think the best way to put it, though it might sound like marketing speed, but it's not. But I think AI is a force multiplier. Whether you're in software development or not, doesn't matter. Because if you look at my example, is that I don't write as much code as I used to, to be honest. But I use a lot more documentation. I use a lot more of the office tools, for example, from ours table that I use on a day-to-day basis myself. Because I'm a little bit more distant from writing code on a data basis. I do review PRs and all that, but I don't write code, per se. And what I've realized largely is that there's a lot of AI to be gained in, regardless of what work you do, where you are. And there's a lot of fear-mongering going on. And I want to be very open about the fact that today's fear-mongering, people are creating a bias towards this fear, right? And I think it sounds good on a newspaper headline. If you want to be sensational, right? Like, oh yeah, it's coming for your jobs. It's fantastic for a tabloid newspaper. It's good for page three, right? But the reality of it is I think, yeah, AI still cannot do a lot of things that only humans can. Like the example of what you gave, right? the gentleman that wrote the finance newsletter, for example, that you pay for access to. Journalism is a fantastic example of where no chance in hell, you will not be able to have an investigative journalist AI. AI can maybe help the investigative journalist, but then cannot do that. But even people like me, for example, in management, when we're writing user spec documents or feedback documents, or when we're writing what sort of products to prioritize, or when I'm writing a BRD or a PRD for sort of a demo or something that I want to showcase how cool something is, but when I'm building a talk track, this is really cool for me, right? When I say, hey, is my talk track making sense? Will someone understand? Give me feedback about it. So it's a lot of using of AI. Helps me sort of then sound out my thoughts, because in a lot of ways, we used to work, even though you had teams, you had to work in isolation, right? It was until someone gave you feedback on what worked or what didn't work, you were largely isolated to your thoughts on your things. You didn't have a chance to sort of say what it was. But now you can have a mirror, someone standing right in front of you that says, hey, I have this thought, I have this idea, I want to make it work and how do I do it? And then you can then say, hey, it doesn't sound good and use it as a sort of a sounding board or a validation board. So I think a lot of people have to gain from AI. There's not many people that are at risk from AI. I'm not going to say that there's no one at risk from AI because I know that's not true. There is some risk from AI in some areas of jobs that can be actually replaced with AI, there will be, like data entry and OCR, Very easy use cases, image recognition. These are things that are part of development. I think we should be cognizant about those things. But a large part of what it takes to be human is still going to be human. And I think what we spoke about in the last, when we were speaking about right now, the skill set shift is critical for us to sort of have the right skills to be more impactful in whatever work we do, whether we're accountant or whether we're a software developer or whether we're office worker, it doesn't matter. It's just about Being open to change, understanding how this tool works, taking it one at a time. Don't speed through it. It's okay. You don't need to know all the innovation that week or that month or that year, but choose one innovation that drives significant impact for you and your work stream and just keep using it, keep better at that tool. I think that's the best way to do it.

Yeah, definitely. And the one thing I thought about the other day is I was writing an iOS application and I thought, well, it's not just me hacking in the code, which used to be my job like 15 years ago. I feel more like a kind of product manager or something like that, where I have the AI as a sparing partner and I'm putting in ideas and I'm getting feedback and I'm creating code and then I'm testing this stuff and it feels more or less, yeah, as I said, like a kind of product manager, when you're working with AI alongside.

Yes. And you can try out stuff faster. I think that's a good point. So making a short proof of concept. In past, you had this discussion with business and they had a wish and you as a developer said, ah, it will not work. And because there was a lot of effort, you never could show them that what they want to achieve. But now maybe it's one or two prompts. Yeah. And then show them. Something like what we called in past some mock-up application, and I think that is a nice thing, but the other story is, you say it feels like a product manager and a product owner, whatever, but... You need to digest what comes out. I think that is something that is the tough part of it. I see a lot of people, they use that things and they say always, Yes, yes, yes, it's the new next button behavior of people. You, and that is my biggest challenge. How can I follow this AI, whatever it does, whatever ideas comes up? How can I digest that? How can I be still a pilot? Because in the end, I need to understand what comes out there. And I think that's the, for me at least, the toughest part of it, to graft that knowledge.

I think we have a sort of a... We speak about this in our prep, where we're speaking. And that's the interesting thing. So there was this large analogy that I brought up. And I think I'd love to bring that up again for the audience as well, I think. It's just the way we used to-- we don't Bing something or Google something. It's a very foundational part of the human experience. We are humans. We are dumb. We don't know things. We Google things. So we always search on Bing for things. It's very simple. Very simple, rudimentary human behavior. Everybody knows how to do it. I don't think there's any, there's very few people that are on the spectrum who don't understand what it is, right? But the fact of the matter is today, because of the ability of us to have so many tools available that can get us that information, we just stop doing certain things in a certain way. And I was giving this example, right? So for example, let's say I just wanted to search for a certain interesting fact about, how does a certain engine type work, for example, and say, how does this, how does Mazda's rotary engine work, right? Typically, when you ask Google about the Mazda rotary engine, it will just give you a bunch of 10 links where you go to Mazda's website where they explain the rotary engine, or you would go to, you know, a physics website that told you about how the physics of it worked, or you would go to a car review website where someone wrote a car review about how the car that has the rotary engine works, for example. But today we either go open up a app, right? It could be ChatGPT or Perplexity or whatever, or Bing and search and say, okay, how does it work? And then it just gives you an entire output, like sort of the idea of what you, exactly what you ask and it gives you just that much as an answer. So it kills curiosity is my, is sort of the way I would look at it, right? It kills the ability for you to then say, How do I go about and do it? So I was talking to the team and I said, one of the ways I do it right now and I feel that it works really well is that I actually added a custom prompt inside all of the AI engines I use, which basically says, whenever I ask you for something that looks like a search, always give me back three links or three pieces of information that would be nice for me to study. And give a link for instantiating where you got that information from. So in the master case, for example, you'd come back and say, this is not the first ever time the rotary engine was tried out. Do you know that in marine applications, there are boats and ships that actually have this rotary engine as part of their thing. Do you want to check more about that, for example, right? So it then builds that curiosity for you to then go and drive and find new things. This goes back to what we spoke about AI, right? AI is a tool at the end of the day. It's like a hammer or a power drill. You have to know how to use the tool to be able to extract the output from the tool. And you have to have the right set of instructions for you to be able to use that tool. It's like a workman's boot. If you are in a factory and you don't have the right sized boot, you're always going to feel like it's either too tight and it's hurting your leg, or it's too loose and it keeps slipping off. Because you have not customized it for what works for you. Right now, I think a lot of people are using AI and finding that it is not as helpful or it's for instant gratification or instant help. But the more you customize it, the more you talk to it on what you need, I feel like the better it gets. So I think that's the foundation, not only is it for other AI, but the same thing in software development as well, right? As you customize it for what works for you, it gives insanely wonderful results.

Yeah, exactly. And I think the example you gave with the prompt about peripheral learning and getting different facts also besides these really specific query that you're giving it is actually brilliant, you know, and because all that context information, you're not getting that right now. And I would probably adapt to that and try it out myself, you know, as a next step. This is a great, great learning.

I think it's, you brought it up in a conversation before that recording, but I thought about that and I find that analogy, like someone makes a trip, so let's go to, I don't know, Africa. And he planned everything and you say, Toby, you want to join? And you say, yes, I join. So, and you make that trip, but it feels different. What I want to say is someone planned it, you jump in and you, Enjoy it or you plan it. And you think about that, what you want to see, you make some kind of research. I think that's my energy. So when you ask someone like a ChatGPT and you say, hey, what is a good way to visit Africa? You get an answer, sure. But I think you should think about what is important for you, how to, what you need to put into the prompt and how you need to challenge the answer. and think about that. That's my way of thinking. Yeah, definitely. So jumping in and be a guest is maybe not the right way in using of AI. Yeah. You've got to be in the loop.

You've got to be at the driver's seat. You've got to be the person that's orchestrating all of this happening, right? I think we've fixed it in software engineering, right? Because we've always had this process in the past, you know, where any code change that is written by anyone goes through this process called a pull request, for example, right? So for the audience that doesn't write code, a pull request is basically a unit of work for software engineers who, let's say you changed a few files of code and then you submit a change request. A pull request is basically a change request where then someone that's a more senior person can then review the code and recommend the changes that they feel would be more impactful in the code base for them to then be able to implement in their future. So In software development, there's already a gate. There's always already a gateway for you to be able to then go ahead and do that. So what you see is that a lot of large part of the agents are now part of that gateway and the humans are in the loop because they are the ones that are approving the pull requests. While someone can review a pull request, the approval of the code that's been written is always human. Someone's always in the loop and someone's always checking the code to ensure that it's valid and sort of then passes all the requirements that they have. So I think We've had horror stories in the past. A good example is how, I don't want to name this person, I don't want to name the tool, but then a tool came out in the newspapers a couple of weeks ago where this tool basically went out, deleted an entire production instance. And this software giant basically then had multiple hours of an outage because an entire set of agents were running on a set of permissions that they had granted for them that they should ideally not have had. in the first place. They were running on YOLO mode, for example, right? So it's like proper YOLO. And then that's shocking for me, right? Like I've seen, you know, Molt, so we all saw the announcements of, you know, Moltbook and Cloud Bot being acquired, for example. We saw what happened in the Cloud Bot apocalypse and all those things. So there's a lot of interesting lessons for a lot of people to learn, right? I think There's a lot of change. We have so much change every day. And we have to be in that mindset that, hey, we have to change the way we operate from in sort of different ways. But it's an exciting time to be there, but it's also a time where you have to be very cautious about what steps you take, what permissions you craft, what levels at which there, and ensure that at every point in time, there's a human that's saying, in your analogy to be like, if you want someone to go to Africa, Of course, if the AI LLM basically said, you know, put your head inside a lion, lion's face. That's probably not a good idea. Yeah, maybe. It makes an amazing Instagram photograph, but...

Unique experiences.

It's a unique experience, put your head inside a lion's face. I'm like, nope, I'm fine.

Exactly. But I think like that is like the deterministic versus non-deterministic. It's like, it's like this is a brilliant example, you know, for that. And when you're mentioning the production outage and stuff like that. So you also need to be prepared like for non-deterministic output, although it's a computer, you know, we are always used to like input validation and a certain output, you know, that is quite deterministic. And this is something we have to Yeah, have in our minds that AI might not always be the right tool for certain things and choose your tools wisely about what kind of output you want to have.

So this is a pet peeve of mine. Why do you need to use AI for everything? You don't need to necessarily do that. One of the most recent examples that I came across is very interesting. In a past life, I used to be a security researcher myself. I used to do a little bit of cybersecurity. And that space is full of tools that do that, right? There's so many leaders in that space that operate and have built amazing tool sets that have done a fabulous job of limiting risk. I'm not going to say that all the software that's written in the world is now safe before AI. It's not, but there's tons of progress on how to do stuff more safe, more securely for all the organizations out there. But ironically, what I realize is that all that comes out And then we have such a large, strong set of tools, including GitHub's own tool, right? For example, in code security. And then you basically see that there's a non-deterministic tool that's probabilistic that comes out. And then all of the industry then has an entire cycle says, Oh my God, that's the next best thing. So basically the translation of that is you have okay with an LLM that has 80% chance of getting something right. And you're okay with that running security scans and checking your stuff. But you're not okay with using a tool that has 100% chance of probably getting it right. Not maybe 100%, I mean 90%, 95% of getting it right, right? You're okay with taking a probabilistic tool, but you don't want to take a look at a deterministic tool that knows what it's doing and just has the right output, right? It's very interesting. It's like having this engine in your car that might work 90% of the time. Would you rather have that? Or you say, no, it's okay. It's got 98% reliability, but this works 90% of the time, but goes at 700 kilometers per hour. Or you can have a car that goes 300 kilometers per hour on the autobahn and then still, you know, it still works 98% of the time with reliability. That's the million dollar question, right? Yeah, I just don't get it.

Yeah, and I think that's the point. And even the example of what you brought up with this deletion of production database, I think, That is also a shift from a developer. In past, developers said, hey, I'm on my local machine. I'm in a special local environment. I can do whatever I want. But when you use AI, AI is very, very searchable. Let's say grab stuff somewhere. And when you don't think about where it got that information, what kind of information is, let's say you have somewhere an environment variable, some Why ever a productive database connection string? And you give him some questions and he asks you, can I use that tool? Can I execute that command? And you don't make that, I'm a pilot, I'm in charge, and now I want to understand what this thing is trying to achieve. And you say, yes, YOLO mode, then you are in ****. When it comes to customer or developers, they sometimes complain. They say it's not reliable. I don't like that. And I think that's that's not supposed to be the last. Yeah. Yes. First of all, when it would be reliable and deterministic, then we would not sit in here and speaking because the idea is it's generative and it's some kind of creative. And that gives you also a superpower, this challenging, getting new ideas, new thoughts when it would not be non-deterministic, it would also only give you that what you know. So it's not what you want. But I think that's the biggest challenge now for developer or for anybody who use that tool. It's when you need that kind of creativity with this uncertainty and you need to judge it. And when you do not need that. So for example, I had one case where a customer wants to create an agent to delete users and add users. And then I said, why you want to have that with AI? It's an important thing and it should not be- You mean you need an API call? Exactly. So why to do that? And that is, I think, We now are laughing about that, but I think a lot of people have that challenge because they have that mindset about it's something like smart. It's something like it works like smart and it's like a human and it's better than me, whatever is the thoughts and the fear, but it's not like that. And I always think about when is it really good to use this undeterministic stuff and when it's not good. Or you make a refactoring in your big, huge code base. Why not to use a traditional refactoring tool where you know, okay, I made a good renaming and everywhere it's now this renaming happened. With AI, I would not say it's not possible, but it's another game, I would say.

Like I went to this ATM last week. It was the most interesting, insane example. It just drove me nuts. So I went to this ATM. I don't want to say which bank, but then we went to this ATM and this Indian bank, and then there's a bank in India, and then They basically had an ATM that said, talk to a new conversational AI engine to withdraw your money. Oh, yeah. Wait, what? It's a ATM. It's 4 buttons. You press your title account, checking account, savings account. You press the amount of money you want. You put in your security code, and then the money comes out. How complicated is that? You don't need an AI agent for that. And just for kicks, I tried the AI agent. And because this ATM has to have a mobile connection, and then there's an LLM that's then sending a response back out to the ATM agent, it got stuck. Like, in the middle of the transaction, it got stuck, for example, right? Like, why? You don't need AI in an ATM. It's a four-step process. It's not complicated.

Yes.

Yeah, and now say your security pin loud and clear so the agent can listen to it. That's great. This is like having like a button on a double or nothing, you know, and make it a little dilificate.

Yeah, I like that. To be serious, we're living in a comfort world, luxury world, because at Microsoft, and I think at GitHub is the same. we can use LLMs as much as we want, let's say like that. I think there is some limit, but I know nobody will reach that. And it's a game changer when you don't have to think about how much token do I spend, how much tokens do I have today, how much premium requests, whatever. And it's nice that you can try out and to learn when is this the right tool, when is it not. But Still, even when I could use it for everything, I don't do it. And I think that's the biggest learning from my side. So, and that's the tough part. Where is it good and where is it not? And when you have something like an increase of productivity and you feel good and not like more chaos, yes. So let's say you make one prompt, you get an output and then you sit more time there to make that finishing and read through it and adapt it, then you would do it by your own. And then that is not something what should be what you want. Yeah.

So there's this learning philosophy called first principle thinking, right? Like where you basically say, you've got to ask an infinite number of whys to get something right, to get to the root of a problem, for example, right? You keep asking why. Like, why do you need-- so for example, if someone says problem, like the ATM use case, for example, if someone went and pitched it to a board and said, hey, I want to have a generative AI-powered voice assistant in an ATM, the first question the board should have asked was, why? And if they had asked the question, say, why, and then the why, and then maybe there is an accessibility use case that I'm not seeing, for example. Maybe there's someone that cannot see, for example, that for them, it's a better use case, right? But that's the why. You get to the core of it saying, okay, it's an accessibility feature that can be accessed by someone. But then if it's a button on a screen, how does the person that wants the accessibility feature access it, for example? So it's a critical flaw in the why chain. You have not asked the right amount of whys to get to the why of which matters here. In this case, it's a why saying, okay, this person came in. And then this person is, let's assume that they have visual impairment. they still cannot see the button to click and open the agent in this case, right? So I think one tip I would say is one of the things that I use, especially with my team, because like Toby said, we're in the middle of this AI wave ourselves. We have all the AI tools at our disposal. I keep asking my team, why? Like, why do we need to do it a certain way? Why can we not do this without AI? Is there a certain API that exists today that can do this for us? Why can we not use an existing tool or a code base that already exists for using that? Why do we need to generate something? Why do we need yet another login page, for example, right? That's the why framework for me.

Or raising these questions, why could we not achieve something in past? Because it's logic has some limits from computer. There was always some edge cases in the past where you said, Nice feature, but we cannot do it because it's too much effort or hard to program. So maybe then that the things and corners where you should think about using AI or I thought about that. We have a formalized world here in the Internet. So you want to have a pizza. It's not like you would do it in the store. It's like, okay, what is your first name? What is your last name? So nobody asks you that in the store. So I think a cool thing could be that you make it more the input of the data more like humans. So I want to have a pizza, I'm Toby, I'm living in a city and so on. And behind the scenes, this information, unstructured information will be grabbed and put into some kind of a structure and mitigated. And I'm not bothered with some kind of a formula and I need to click and then you are on the end and you click the button and it says, oh, you missed something and the data are lost and stuff like that. I think that's, for example, we can improve and I like that. But Don't put it everywhere, I would say. Yep.

Especially not in ATMs.

What I'm excited for is that thing, right? Where you have an agent that can talk to an agent and then sort of work with you. Imagine this, in the same use case that you're ordering the pizza, I think where we're talking about A2A frameworks and all that right now is that we're basically looking at a way to say, okay, let's assume that Toby has his own Toby personal ordering agent or something like a Jarvis from Iron Man's assistant Jarvis, right? Like for example, like you have an AI assistant that knows everything. So you open up your phone and say, Jarvis, please order a pizza for me. So in this case, Jarvis then knows everything about you. Jarvis knows you only like pepperoni pizza. Jarvis knows Toby likes pineapple on his pepperoni pizza. I'm just joking. I'm not sure he doesn't like pineapple on his pepperoni pizza. But like it knows your personal preferences. It knows the pizza store that you like to order from. It knows the phone number and then it places the request. And on the other end is another agent from the store, because again, why would you need a human to take an order? And then these agents talk to each other, and this does not have to be in human interaction. I think that's the next bleeding edge, where if agents can talk to each other in a more efficient communication format that is not human language, then it's much more efficient for them to then pass information to one another that's contextual in this use case. And then once they've passed information of what sort of pizza for where, where the addresses and all that, that agent disconnect in a couple of seconds because that's all it would take for two agents to talk to each other in say something like a JSON format with A2A, for example. And then the information is passed and it's done. So it's wild if you think about the possibilities of something like that. You save so much time for the person that's ordering, you save so much time for the pizzeria that does not have to have someone manning the phone line because That person can then be actually making the pizzas or attending to customers who are at the store, for example, right.

So yeah, it's very interesting. Yeah, and they can focus on the real business value, making good pizza and not sitting on the phone and taking calls and yeah, exactly. Did you see that video? We can put that in the show notes. There was some example. It was two agents and they was calling each other. And in the beginning they speak human, yeah. And then they say, hey, I'm an agent, da, da, da. Then the other one, yes, hi, I'm here. I'm also an agent. And after that, they started immediately to switch the language. And to improve that, what you say, it should be more easy. And maybe human language is not the best way for machines to communicate. So they switched and say, hey, I can speak that and that. We have an improvement and awesome to see. I think a lot of people are scary, but don't be scary, I think. Don't be scary.

Even if you look at GitHub, right? I think that's where the frontier is for us, right? Like if you look at, GitHub already has agents, like we have agents that do different types of things for you, we have security agents, we have coding agents, we have agents that can do a lot of things for you. I think a large part of our innovation right now is one in governance and control. Like how can you control these agents and how can you govern these agents? What agents and what LLMs are you using? What scopes do they have access to? That's a lot of the work that we're doing right now. We call it the agent control plane. And I think we have this offering called the agent HQ, where we basically try to bring different agents together into the one sort of a place. So you could have a cloud agent and you could have an open AI agent and you could have a, you know, you could have a, In the future, you could have, say, a Gemini agent. Whatever third-party agent wants to come onto the place, right? And you'll be able to then use an agent of your choice with a product like AgentSQ, where you can then choose the right agent for each task. Because what we've realized is just like being in a supermarket, right? Every LLM has something that is really good at doing, and then you can pass the LLM with just doing that. And for example, sometimes I've heard that Grok is really good with unit testing. I didn't hear about that until two weeks ago. Some people told me that, try Grok for unit testing. That's really cool. Like if you had a Grok agent that just did testing, for example, right? And so all these things are really interesting. So you can then mix and match things that you want. And then I think the next frontier for us is just that piece where how can we make agents talk to each other more effectively? How can they pass information between another end? Retain the context, because at the end of the day, ours is a huge platform, right? Like if you have hundreds of thousands of projects on GitHub as a large enterprise today, for example, how do you transfer and retain context between agents that are working for two different developers, but two different developers working on the same piece of code? That's a million-dollar problem to solve. That's a multi-billion-dollar problem to solve, right? How do you know who's doing what at what time, and how do you think the right intervention for who needs to sort of come in? That's the next horizon for GitHub, right? When we look at simultaneous use of agents and how developers are writing as they're writing code and they're using agents to implement changes in code, how can we communicate with each other sort of effectively? I think that's sort of the next in the horizon for us as we look at it as well. It's exciting times to come, to be honest, I think, as we... I'm very excited. I'm excited for the fact that When I wrote my first line of code, when I was in my first year of college, right, my first ever line of code was in C programming, right? And I was scared to start. I was scared because I did not know what it was. I did not understand what it was. I could not understand the characters in front of my eyes. Of course, as I became a more proficient developer, things start making sense. If you do something oftentimes enough in your life, you become good at it, right? Practice makes a human being perfect. But I think the beauty of what we have in our disposal right now is you can get rid of that fear. You can become a better singer with AI today. You can become a better author with AI today, write better things, right? You can become a better manager with AI today, ask it questions on how do I react to some, you know, one of my direct reports, how do I react to a better manager? You can be a better human being today, you can be more curious today, you can be what you want. with something that was just not possible five years ago, right? And have that ability to then drive those skill sets, which I think is fundamentally paradigm changing. And that excites me, like the expansion of human possibility, right? Of all of us being able to then do these new things is very exciting for me to then see what we will do collectively. And as long as we got our head on the right places and we do the right things for each other, we care about each other, and we keep building the way the human race has always looked out for each other, then I think the future is bright for all of us. I think we'll collectively build a sort of a world that looks forward to sort of then new innovations and new horizons for all of us together, right? Significantly saving human time, putting our brains together for efforts and things that we really need to solve so that our energy is spent in the right places. I'm excited for that.

Yeah, definitely. And thank you also for bringing up the human element of the whole chain. You know, I think this is something we in each and every technical discussion we leave out for often enough, you know, and bringing that basically back into our heads is really, really important. Yeah.

Yeah. And I think human also is a good word. And you mentioned some different models, different tools. Yeah. So and I think all Or what is a challenge for me? Someone comes and say, Hey, the model is better, but it's not like in the past that you have some kind of a deterministic feature matrix, and now you can compare, Okay, it has this, and you make a... black and white decision. Let's say it like that. Because when someone says that to you, you should think about, okay, what was the context? What was his prompt? What kind of data was accessible? Custom instruction and whatever. And that makes it so complicated. So, and when people come to me and say, ah, it's better. So then I challenge them and say, why? What did you do? And even with models, it's, I think, a tough part even for us who can use whatever we want to decide which model is now the right one. And it's my, my energy is like it's some kind of some employees. Yeah. So every model is an employee and you need to get a feeling how, how good is this employee? What, where are the strengths and where are not the strengths? And sometimes you even have to ask yourself, how can I give a better input? How can I better get better instructions for this guy that he can achieve in his style of working, whatever it is. And I think that's the biggest challenge for people who was not in that role of instructing someone. So more taking instructions and then digest this and do something. And it's about humans.

We saw this in GitHub, to be honest. At one point, I think our catalog had 21 models. And I think you can still find this on our documentation website, but I think we have an article that basically says, if you are using which model to use for what use case, I think it's still there on our doc site. You can still go check it out. But we realized through our AB testing for a lot of developers, that developers were just confused, like what to use. One of the interesting things that I think we've done, and I think a lot of the industry is now following suit with that, and I've seen that change, is what we call intent detection. We basically then try to understand, if you're trying to do a certain type of work, and we try to then understand what is the intent behind your work. Are you trying to write unit tests? Are you trying to write code? And then we then give people a random new model called auto, where you can basically just have choice of whatever LLM you want. we chose the LLM that we felt is best for you. We went out for AB tests and then trust me, people did not choose it. So today we actually incentivize that on our platform. But if you choose auto, we give you a 10% discount on premium request usage on GitHub Copilot. If you actually have auto as a default model and we're incentivizing users to use that more because we feel your experience with something like that is better because we're then letting An LLM, an agent, actually sits in between, which we call an intent detection agent, and then identifies what's the intent of the code base and then the prompt that you're giving, and then diverts you to the right model that will then do the task for you. And then whichever model you use, you'll get a 10% discount on that.

Yeah, that's brilliant.

Yeah, but this is, I think, the biggest challenge now. What model is good, what is not good, what is the model for the right use case for my project, technology stacks. It's a tough question. And yeah, it would be nice to have something, like you said, an AI, what has.

Some-- And then tell you which AI to use for this AI work, yes.

Exactly.

It's like having an AI supervisor that supervisors AI agents that are supervising other AI agents, which is actually real. It's a real use case. It's happening today.

And another point, I think, what to add, and also about mindset, I think a lot of process in past are made like they are because of humans. And one example, I see now people moving wikis in markdown into the repository for the reason it's easier to grab for AI systems. that knowledge. But let's assume two years back, you're sitting in an interview and someone asks you how you share information in the teams, how you have some kind of a knowledge platform. How you do that? And you will sit there and you say, it's a text file in the repository. You will not get a job. And I think that is now also something what is changing because we want to have, we have that large language models, we have easier, an easier life at processing. big, huge text of language. And it's a change. And even made me surprised. I saw that and I thought, it's genius, but hey, come on. Two years back, I would say, no, don't do that. Use something. What you see is what you get, editor or whatever. So to make that more easier to edit and adapt and to read, but it's not necessary anymore. Crazy times. And interesting, I would say. Yeah.

I just want to wrap that up. I know we've had a ton of conversation, but I think one place where I want to change, I think I'm going to be the guest that asks you guys the questions on your podcast. I want to have that recognition of being the guest that started this new trend. But I'm going to ask this question of you. So I think I love asking this question. Whenever I have a panel with CXOs or whenever I'm doing this, ask this question. I love asking this question. One is I love to ask, tell me one thing of everything that we discussed, one thing that keeps you awake at night, something that you're not necessarily afraid of, but something that gives you thoughts, that gives you thoughts of anxiety or thoughts of things that you don't know necessarily how something will happen, right? Not necessarily a fear, but you're uncertain about something. And tell me one thing that you're excited for, something that excites you and like, oh, this is fantastic, what's your exciting thing, to both of you, yes.

Yeah. So I can probably get started. So one thing, well, it's not necessarily keeping me up at night because I still have a good sleep, but I'm thinking a lot of right now is for younger generations. So I have two children, they're aged 11 and nine right now, and I'm also volunteering at a school in Frankfurt, Germany here. And these students are grade seven, you know, and whenever it comes the discussion up with AI and what they're doing, I think AI impacts these younger generations a lot more. First of all, they get used to using AI on a daily basis. So these young people, they're quite confident in using ChatGPT, for example. But on the other hand, it impacts their choice, for example, what they want to become later in their life. So we have had a conversation with somebody who said, well, you know, I want to become a software engineer, and I'm not sure if this is actually the right choice. And I mean, based on our discussion, Right now, I think it's still the right choice to go into software engineering and stuff like that, but these students, they still have, I don't know, six to seven years in school, and you don't know what is happening in the next six to seven years, and same for my children, so... I mean, you cannot beat knowledge, so it still makes a lot of sense to go to university and study a certain subject, in my opinion, But giving them good advice, what the world is going to look like in six to seven years or something like that is quite difficult nowadays. So this is something. which I'm thinking a lot, in terms of newer generations, in terms of programming languages, in terms of how we're doing stuff in the upcoming future. And there's a lot of where I'm spending a lot of thoughts on.

Very nice. And what keeps you excited? Yes.

Yeah, I mean, it's basically the same, you know. We were discussing like things opening up every day and new things coming up. And, you know, whenever I'm getting a chat from Tobi, have you seen the latest model, have you seen this, and have you seen that, you know. Yeah. You know, I'm trying things out myself like every day just to keep up with the pace, you know? And so I think the amount of AI knowledge is also not distributed equally within our society. So we have people who are at the forefront, you know, who are far more advanced than I am. I'm somewhere in the middle, you know, I guess I have a good overview, at least in terms of developer topics on AI and stuff like that, you know, but there are also people in my personal environment who said, well, can we switch off that whole AI thing? I'm not comfortable using that. So AI is still keeping me excited and being really having a good conversation about AI and good thoughts and when to use it, when not to use it. And so this is also something which keeps me excited with new possibilities, as well as deciding deliberately that for a certain problem, I'm not going to use AI today.

Okay, good points, Tohui. Yeah, what keeps me awake? I ordered a MacBook Pro first time in my life. The question is when it gets shipped. No, to take that more serious. Oh, God. I think what keeps me awake, I think it's this energy. So, two years back, I think it felt like everything is settled in our industry. We know where to go and how it works, and a bit bored, I would say. don't take it personal. Yeah. So no, nobody will listen to this, but it was my feeling. And now it's, it's this new, you feel like a child. You feel like, uh, everything is changing. Everything is possible. You see people starting to code who you never expect that they can code. Yeah. Because of the role, because of the, the time, what they have to do something like that. Um, and that makes me, yeah. Yeah, excited, and it's not taking my sleep, but it makes me a lot of thinking. How is this changing our industry, the world? And I liked the times, I think, because... One thing, what is serious, I think in past, I was a software developer. And when I was developing software, you have this imagination about what you want to achieve in your brain. And it's only in your brain. And it's very, very tough to translate that to product owner, to a customer. So you have always this kind of transformation of these two worlds. It's domain driven design. I think Eric Evan was writing about that and how tough it is, yeah, to bring these two worlds together and to understand where are the gaps and what I observe and what I think with this technology, I think this two worlds come closer to each other and maybe it's easier to bring in other people to give them a feeling what is possible, what is not possible to try it out. And I hope that it makes our world better in in the sense of better products. So not an ATM, like you said, but something really like, okay, now, because technology is always just a human sit in front of a machine. So you have that interface, let's say like that. And I hope that this kind of interface, it's designed by the limit of what was possible. And I hope that now we see really cool things like, Don't make me think when I want to order a pizza online or on an app. So let's do it. Yeah, and that is also my excitement, I think. It feels like a child, yeah. So I'm an old guy, but it feels like a child and playing around, sitting in a playground and doing fancy stuff. And I like it. I enjoy it, really. Yeah, that's my thought about that. What is about you, Karthik, to give the question back?

I think I shared a little bit before, right? I think when I was talking about what GitHub was working on, I think I'm really excited for human capability. I think that exactly what you're saying. I think we're amplifying people's skills so much. I'm so excited to see what everyone will do. I'm really genuinely excited. Like every time a developer walks up to me and shows me something cool that they tried out with Copilot, I get so happy. I feel so happy that Hey, this is so cool. Have you tried this out? That's genuinely so exciting for me. And I love talking to developers just for that one reason. What keeps me up at night is, I think I share a lot of what we spoke about. I think what keeps me up at night is, will we be able to, as a community, like me and of course the two told me is a part of this community that's trying to share and disseminate this knowledge with all of them and trying to make people use AI in a more effective way, right? Because as I said, there's a lot of fear-mongering going on out there. There's a lot of misconceptions about how to use AI going on out there. When I sleep, one thing that keeps me up is about my community, about my solutions engineers, about my field teams, about the people that work through this, about our DevRel teams that are working across the clock trying to share this information, saying, how can you use it more effectively? How can you use it to the right use cases? How can you build the right things? There's no right or wrong for anyone. And of course, it's always gray. Everybody has their own use cases of why they do some things. But I think it's there. I just hope that there's enough people that can share their thoughts, share their learnings, and educate as many people as we can. Because I think we've left a lot of people behind in the past with technology. And I'm really sad about that. Like when the mobile wave came forward, we left a lot of people behind. when we went to apps and smartphones, we left a lot of people behind. And what I don't want to do is leave people behind in this way. I think everybody deserves a seat at the table. Everybody deserves a chance to, you know, have that insightful ability to then be accelerated by AI and do something interesting. And I hope that all of us together will be able to do that for the better of humanity. That's my only thing that keeps me awake.

Thank you. Wow, thank you for your time.

Yeah, that's it for this episode of Toby Olds Wei Kartik. Thank you very much for joining us today. This episode was great fun. So for the listener, if you have any feedbacks, let us know via e-mail. Until next time at Toby Olds Wei. Thank you very much.

Bye.

Bye.