Das heißt, du schreibst in deiner Rolle als CTO wirklich noch Code und bist live am Keyboard?

Also ja, ist die Frage, ob man vielleicht den Begriff oder die drei Buchstaben CTO vielleicht manchmal zu sehr über einen Kamm schert. Also ich meine der CTO von der Deutschen Bank ist was anderes als der CTO von Thinktecure. Da wir jetzt sowieso schon immer sehr sehr technisch unterwegs waren und immer noch sind und sehr sehr nah an der Technologie-Grasennabe, muss ich mich natürlich mit den neuesten Technologien auseinander.

und da bringt es mir nichts, wenn ich nur die Dokumentation lese oder irgendwie Youtube-Video von jemand anderem mir anschaue, sondern ich muss dann Hands-on machen.

Ja, das ist super spannend. habe letztens auf LinkedIn ein Video gesehen von einem CEO, der hat nach zehn Jahren dann auch mal wieder Code committed, dank der Hilfe von AI. Das ganze Team war vor ihm so ein bisschen im Schreck, hat gedacht, Gott, er will ein Feature implementieren, was kommt jetzt hier an? Aber Entspannung, also es war gar nicht so schlecht und gerade durch die Hilfe mit AI war es ihm wieder möglich, dort ein bisschen einzusteigen, näher, ich sag mal, Touch Base zu schaffen mit dem Produkt. Und

Ja.

Viele von uns werden ja quasi mit der Digitalisierung Tech-Unternehmen oder streben das an. Aus deiner Sicht, was sollte selbst so ein CTO der Bank oder ein anderer Unternehmen, wie viel mehr Tech brauchen wir oder wie viel mehr Engineering brauchen wir auch auf Management-Ebene aus deiner Sicht.

Ja, das ist natürlich eine super, super schwierige Frage, weil ich glaube einfach nicht, dass wir bei den ganz vielen Schichten, wie es jetzt eine Bank oder eine Versicherung oder ein großer Industriekonzern hat, dass wir da immer von den gleichen Abstraktionsebenen und Levels und Titeln dann reden. Also ich denke mal, der CTO von einer Bank oder von einer Versicherung, naja, ich mit der heutigen

mit den heutigen AI-assisted coding und Architekturfindungsmöglichkeiten könnten die das auch machen, aber ich weiß nicht. Also ich spreche mal mehr von so einem Mittelständler. Ich glaube, das ist wahrscheinlich ein bisschen ergreifbarer. Also so der typische CTO von einem ISV, also einem Independent Software Vendor also eine Firma, die in einer Branche, in einer Nische eine Softwarelösung baut und sie dann verkauft oder vertreibt.

der sollte tunligst sehr nah noch an der Technik sein. meine, es ist ja ein CTO. Das T steht ja jetzt hier für technical. Spätestens mit den heutigen Möglichkeiten von AI-assisted tooling kann man ja auch sehr schön Ideen quasi generieren in einer kreativen Art und Weise, wo man vorher vielleicht einfach die Zeit hatte, vielleicht einfach nicht die

Motivation hatte oder gesagt hat, Gottes Willen, da muss ich wieder viel zu tief rein, sondern man kann das ja quasi so im Dialog sich so erarbeiten. Da würde ich schon sehen, dass man tief technisch sein sollte und dann auch mal Code schreibt. Das muss natürlich kein Produktivcode sein und wenn zum Beispiel das Produkt jetzt in, I don't know, in Java oder in .NET geschrieben ist, dann muss man das auch nicht tun, sondern dann nimmt man vielleicht eine Sprache oder eine Umgebung, die einem halt irgendwie

Ja.

besser liegt, sich auszudrücken. Aber es geht ja dieses grundlegende Verständnis, was ist möglich mit Programmiersprache, was ist möglich mit der Plattform, was ist möglich mit unterschiedlichen Patterns, ⁓ da halt auch nicht zu weit weg zu sein.

Mhm.

Ja und auch besser abschätzen zu können, jetzt irgendwie aus vom Kundenbereich was kommt oder aus dem Mitarbeiter, dass man einfach näher den Kontakt hat. Wenn das Produkt Technik im Kern hat, dann braucht man auf jeden Fall auch Technik auf der C-Ebene. Bevor wir jetzt, du bist schon ein bisschen eingetaucht in das ganze KI-Thema, aber bevor wir durchstarten, wie bist du eigentlich zur Technologie gekommen? Du bist jetzt auch schon ein bisschen länger hier im

Ja klar.

Wie war dein Weg zur Programmierung? Wie bist du dahin gekommen?

Also

bin Baujahr 74, das heißt, wenn man da zehn Jahre oben draufschlägt, sind wir im Jahr 1984 und im Jahr 1985 habe ich dann meinen ersten Homecomputer, den Commodore C64, bekommen. Das war ja damals Goldstandard in Deutschland. Genau, und damit habe ich natürlich erst mal nur gezockt.

teilweise wirklich das ganze Wochenende durch. ich hab meiner Mutter gesagt, ich geh zum Harry, das war unser Nachbar, und dann haben wir uns am Freitagabend getroffen, am Sonntag bin ich wieder gekommen und die hat halt irgendwie gedacht, ja ich hab halt bei ihm übernachtet und wir haben irgendwie eine schöne Zeit gehabt. Ja, wir haben aber nur gezockt, also wirklich rund die Uhr. Also es war völlig crazy, bis ich mich dann irgendwann mal ausgezockt hatte oder satt gezockt hatte.

Dann habe ich den Joystick einfach auf die Seite gelegt, weil es gab nichts mehr zu zocken. Dann habe ich mir den klassischen Wertegang am C64 angeguckt. Erstmal mit Basic, dann ein bisschen Maschinensprache. Später dann auch schon der Amiga. Da ging es dann bisschen mehr Richtung Hochsprachen. So hat sich das Ganze dann entwickelt, ich vielleicht so 14 war oder so was. Dann war ich auf...

Einmal ein paar Jahre lang komplett weg von der Technik. Ich habe immer einen Computer gehabt und habe sehr viel mit dem Computer gemacht. Aber von der Programmierung war ich irgendwie weg. Da habe ich dann mehr Sport getrieben, war mehr draußen in der Freizeit, der Natur. Wohne ich auf dem Land, ich wohne ja noch im gleichen Haus, wo ich damals aufgewachsen bin. Das hat dann gedauert bis eigentlich kurz vor dem Studium. Ich habe dann ...

Informatik mich eingeschrieben an der TU in Darmstadt. Also erst war es die TH, dann wurde sie konvertiert zur TU und erst dann ging es wieder los. Also dann so mit 19.

Spannend, also das heißt im Studium dann auch die Informatik nochmal ausgebaut oder wirklich auch daraufhin dein Berufsziel damit eingependelt, dass du

Genau,

eigentlich wollte ich Luft- und Raufertechnik studieren. Aber das war relativ simpel, dafür war ich zu dumm. Also dafür war ich dann im Endeffekt in Mathe zu schlecht und in Physik zu schlecht und es gab auch einen horrenden NC drauf, den ich nie geschafft hab. ja, ich war schon immer geeky und schon immer technisch unterwegs und dann hab ich gedacht, na komm ich mach das mit den Computern und der Softwareentwicklung und das ist schon was Cooles.

Und dann habe ich das gemacht. Das war reine Informatik. heißt also, Grundstudium war auch schon sehr, sehr mathematisch angehaucht.

Ich gerade sagen, Mathe bist du da nicht los geworden. Ganz im Gegenteil.

Nee. Nee.

Aber ich mein's war cool, also algebra lineare, algebra analysis, das war alles noch okay. Mein Schicksal wurde dann eigentlich fast die theoretische Informatik, da bin ich auch einmal durchgerasselt, aber wirklich mit Pauken und Trompeten. Heute sag ich...

Das Grundstudium war extrem wichtig, weil bestimmte Themen kommen doch immer wieder mal wie Komplexität, also Komplexitäten von Berechnungen, Berechenbarkeit, NP-Vollständigkeit und ähnliches. Aber im Detail war es dann viel, viel wichtiger, sehr, sehr früh hands-on und Praxis und praktische Erfahrungen zu sammeln. Was in dem Studium schwierig war, da musste man sich dann schon bisschen links und rechts selber umkommen.

Ja, das stimmt. ist dann oft theoretisch bei mir im Studium was zum Beispiel so, dass wir irgendwann Abschlussarbeiten nicht mehr als einen Test geschrieben haben, sondern haben ein Projekt bekommen, wo wir wirklich programmieren mussten und danach diese Software auch präsentieren mussten. Das heißt, sie musste nicht

Genau, das hatten wir dann

auch mal.

Die musste nicht

zwangsläufig funktionieren, aber du musstest zumindest irgendwie präsentieren können. Und der Professor war quasi dein Kunde. Und wenn er gesagt hat, ich kaufe, dann hattest du quasi eine gute Note. das war, da haben sie versucht, bisschen den Praxisteil mit reinzuführen. Was ich bei dir gesehen habe, du bist natürlich nach dem Studium dann auch gleich voll in die Praxis gegangen. Du hast gesagt, ich dich doch nicht.

Okay.

Nee, war... war...

es war während dem Studium. Ich wollte jetzt quasi den Bogen schlagen dazu. Naja, ich hab dann halt gemerkt, es ist ein bisschen zu theoretisch. Dann hab ich mir einen Hiwi-Job am Fraunhofer Institut für Grafische Datenverarbeitung gesucht in Darmstadt. Und dann war ich erstmal aufgepasst, zuständig für die Laserdrucker Toderkartuschen. Ist kein Witz. Das heißt, ich musste mich da für die...

⁓

Mhm.

Ich muss wieder die Bestellung kümmern, dass die immer alle aufgefüllt waren und so weiter und fort. Das war super cool. Ich war da im ganzen Institut unterwegs. Mich kannte wirklich jeder und ich kannte jeden, weil überall stand halt so ein Drucker. Also auch mit Vitamin B. hat das ganz gut funktioniert. irgendwann wurde mir das dann auch zu öde. Hatte mich dann schon parallel so ein bisschen mehr in diese ganze Microsoft und Windows Welt eingelesen und eingearbeitet. Auch Softwareentwicklung.

Und da war damals, das war 1996, 1995, 1996, war grad COM, DECOM, OLE und dann natürlich ASP, also Active Server Pages, also das UR, UR, UR ASP mit server.createobject, wer das noch kennt. Und da hab ich dann

habe ich einen Upgrade bekommen im Fraunhofer Institut zu einer Abteilung mit einem Betreuer, der Benny. Heute noch guter Kumpel. Der hat quasi so interne Systemadministrationen, hat aber auch eigene Tools gebaut und gebastelt. Da haben wir halt bisschen was rumgebastelt. So webbasierte Windows NT Systemadministration Tools fürs komplette

Ja, und das hat halt irgendjemand dann nochmal mitbekommen, weil der Benny hatte Kontakt zu Microsoft Consulting Services in Bad Homburg. Und dann hat der Typ den Benny gefragt, ob er jemanden kennt, der com und ASP kann, weil sie für die, heute kann man es ja sagen, für die Commerzbank damals ein webbasiertes Tool bauen mussten zur Verwaltung der Projekte für die Jahr 2000 Umstellung. Genau.

⁓ okay. Ich glaube,

in dem Zeitraum ging einiges im Web. Das war so der Start, wo viele Firmen jetzt gemerkt haben, wir müssen webbasiert werden. Und da konnte man ganz gut mit einsteigen. Ja, Mhm. Ja.

Ja, genau.

Also ich meine, in dem Fall war es natürlich ein Intranet, weil da ging es ja nur

die Verwaltung von den Projekten. Aber ja, so bin ich dann quasi zu Microsoft Consulting Services gekommen und musste, weil ich habe einen Werksvertrag dann bekommen beim Fraunhofer IGD, die habe ich dann quasi zu Microsoft Consulting Services und dort saß ich dann in Bad Homburg vor Ort und musste da eine Einzelfirma anmelden, weil ich über den

Freibetrag dann Das war der Anfang vom Ende. das war dann tatsächlich der... So ja, also am Anfang hieß ich nur Christian Weiher, dann habe ich auf einmal Freude daran gefunden, Vorträge zu halten. Da habe ich gedacht, na jetzt, muss irgendwas machen, so einen Firmennamen und so ein Logo. Dann hieß das EyeSoft, also von Weyer, aber Eye, also dann so Auge. Dann war das Logo so ein Auge, ein stilisiertes...

und das ist wie Think Tecture entstanden ist sozusagen.

Genau, also das ging quasi los im dritten Semester meines Studiums und hat sich dann über die Jahre bis mittlerweile Jahrzehnte hin weitergezogen bis heute.

Seitdem arbeitest du lieber mit ganz vielen verschiedenen Firmen als in vielen verschiedenen Firmen zu arbeiten.

So ist es ja. Das ist

genau. Also 1 zu N statt N so 1 oder oder N so Ja, das war und also wenn ich das jetzt retrospektiv betrachte, das heißt ja, ich war nie angestellt. Das heißt, ich kann natürlich bestimmte Sachen überhaupt gar nicht beurteilen und schon gar nicht verstehen. Deswegen war das natürlich am Anfang auch eine relativ große Herausforderung, als wir dann fest angestellt hatten.

Mein Companio, der Ingo und ich, weil wir selber nicht angestellt waren. heißt also, war dann, ja, da kamen dann ein paar interessante Punkte dann erzustanden.

Das kann ich mir gut vorstellen. Was natürlich auch spannend ist,

Du bist jetzt dann oft auch als Berater aufgetreten und hast natürlich dein Wissen verteilt, aber du warst ja eigentlich auch noch ein Rookie am Anfang. Also bist frisch aus dem Studium gewesen und Berater, Coaches, die haben natürlich Leben von ihrer Erfahrung. Und wie hast du es denn geschafft, dort gerade bei solchen Architekten, die schon länger unterwegs sind? Ich habe jetzt eben einen Konzern namen gehört. Da gibt es natürlich etablierte Architekten. Die lassen sich auch nicht von jedem was sagen. Die werden auch dafür bezahlt.

Ja.

Ja.

die Meinung nicht dauernd zu ändern. Wie findest du da immer deinen Weg oder wie hast du damals deinen Weg gefunden, Gehör zu bekommen?

Genau, also ich meine, die Initialzündung war ja quasi übers Fraunhofer, über Microsoft Consulting Services in einem internen Projekt. Das heißt also, da hatte ich mit den Architekten ja nichts zu tun. Da war ich mehr oder weniger Implementierungsunterstützer. Hab aber schon immer dann gemerkt, die Freude, also das Einarbeiten in das COM-DECOM mit VP6 oder dann mit der C++ ATL und das dann quasi schnell zu verstehen, schnell anzuwenden.

und es sogar anderen zu erklären. Das habe ich relativ schnell gemerkt. A. Es liegt mir. B. Ich kann es wohl ganz gut. Und C. Die anderen hören dazu. Und das war dann eigentlich auch schon der Schlüssel zum Erfolg. Ich bin halt rausgegangen. Ich habe Artikel geschrieben, habe Vorträge gehalten. Erstmal nur im Kleinen, es auszutesten. Der erste war an der IHK in Aschaffenburg. Das weiß ich noch irgendwie heute. Waren vielleicht so 25 Leute.

Es wurde immer größer und immer raus und Kontakte knüpfen, Leute kennenlernen, ⁓ die nächsten Schritte gehen zu können.

Ja, wenn man deine Vorträge hört, dann merkt man auch, sind sehr praxisnah, also damit kann man direkt in die Umsetzung kommen. also ich hab selbst schon welche von dir gehört und bin wirklich auch begeistert, wie du sprichst. Wie wichtig schätzt du das jetzt ein für Leute, die vielleicht im Moment noch nicht viele Vorträge gehalten haben, ein bisschen sichtbarer zu werden? Ist das eine Sache, die du heute noch genauso machen würdest? Oder wie schätzt du das ein?

Ja, also kommt natürlich drauf an, wo du arbeitest und...

was deine Aufgabe ist im Unternehmen. Ich kann es jetzt wieder nur auf mich oder auf uns dann bei ThinkTecture runterbrechen. Sichtbarkeit ist für uns das A und O, ⁓ unsere Expertise nach außen zu stellen. Wir machen keine explizite Werbung. Du siehst für uns keinen Werbebanner oder eine Seite früher irgendwo in einem Magazin oder sonst irgendwo auf einer Konferenz. Ab und zu mal, ja.

haben wir das auch irgendwie unterstützt, dann einfach nur um die Konferenz zu unterstützen. Aber wir machen immer implizite Werbung durch unser Wissen und durch die Vermittlung und den Transfer von Know-how. Und dazu gehört einfach Sichtbarkeit dazu. Also Visibility ist das A und O. Wenn du natürlich jetzt, ich sag mal, bei einem ISV oder bei einem Enterprise als Entwickler sitzt, dich halt normal weiterentwickeln möchtest, dann hast du vielleicht jetzt nicht so einen großen

irgendwie nach draußen zu gehen und Vorträge zu halten. Wenn du natürlich auf der anderen Seite selbstständig bist, ist es natürlich ein sehr sehr gutes Mittel, ⁓ dich auch nach außen hin sichtbar zu machen, auf dich aufmerksam zu machen, sodass halt die Leute dich dann kennen und wissen ach genau, das ist der Peter und der kann super VB5, den können wir uns mal einladen, irgendwie eine Windows Desktop Anwendung zu bauen.

Ja, sehe im Moment auch einige, gerade im Open Source umfällt, dann sprechen ihre Expertise dort nochmal sichtbar zu machen, ihr Projekt auch zu promoten. Ist mit Sicherheit auch eine spannende Möglichkeit. Du hast gesagt, euer Hintergrund ist eigentlich Microsoft.net und jetzt bist du aber seit einer gewissen Zeit ganz tief in das und dort ist ja die Technologie oder die Sprache der Wahl eher Python, ein ganz

Ökosystem außenrum. Wie kam es zu dem was waren deine Gedanken, das Microsoft-Universum dort mal zu verlassen und jetzt mal in eine ganz andere Technologie reinzuschauen?

Mh.

Vielleicht ist es gar kein Verlassen eines Universums, weil ich glaube die Universen sich ja mittlerweile überschneiden. Und im Daily bin ich natürlich noch immer sehr stark im Microsoft-Universum unterwegs, weil in Asha alles passiert oder auch im Es war eigentlich...

Wir suchen immer nach einem Trigger, nach einem Technologietrigger, wo wir unsere Stärken ausspielen können. Dass wir quasi tiefes Research machen können, dann zu beurteilen, welche Technologie macht wie, für wen, in welcher Situation, welchem Fall sind. Das ist das, was uns ausmacht, dann mit den Kunden dann zu arbeiten, diese Technologie mal zu...

Also A zu verstehen, B zu verproben und dann vielleicht sogar tatsächlich dann im Fahrtgang die komplett neue Produkt- oder Projektimplementierung auf Basis der neuen Technologien zu bauen. Und das passiert jetzt retrospektiv immer nur so alle zehn Jahre circa. Also der letzte große war so 2011, 12, 13 rum. Das war diese ganze The Web is the Winner.

Also wo man sich wegbewegt hat von Desktop und hin ins Web und Single Page Applications als Smart Clients im Browser. API basierte leichtgewichtige Architekturen und so weiter und so fort. kam später noch ein bisschen Cloud dazu. Aber das war so der letzte große Move. Davor war es natürlich Mobile. Das waren jetzt nicht, naja, zehn Jahre. Das waren so ungefähr fünf Jahre, weil mit dem

auftauchen vom iPhone in 207 war da natürlich noch mal ein ganz schöner schwung ja aber seit 2012 13 14 kam nicht wirklich was spektakuläres raus oder ob ich jetzt frontends in angular view react mache ob ich backends in dotnet, java rust, ruby, python, php, i dont know mache

Software Engineering war immer das gleiche, die Pattern waren immer das gleiche, die Architektur, die man gebaut hat, ob es Crud war oder Rest oder DDD basierte oder ES oder wie auch immer, ja, das kann man machen, aber ist egal mit welcher Technologie am Ende des Tages. Ja, ich habe halt immer so ein bisschen gesucht, wann kommt denn jetzt der nächste Trigger. Dann haben ja manche gesagt, naja.

Blockchain, ist jetzt der Trigger. Haben wir uns natürlich auch angeschaut. Nicht zu wenig. Sind damit auch rausgegangen. War es aber nicht. Aus bekannten Gründen wahrscheinlich. Bis dann eben 2022 im November ChatGPT kam. Da hat es mich noch nicht so gefetzt. Mein Kollege intern, der Marco, der hat uns da schon länger damit in Anführungszeiten jetzt genervt.

Und ich hab gesagt, ja, es ist alles schön und gut, aber komm, hör auf, ist das für ein Kindergarten? Ich schreib ein Text rein, es kommt ein Text raus, ja, super. Und er hat nicht locker gelassen. Zum Glück hat er gesagt, doch, das wird einiges ändern, wenn nicht alles. Und bei mir hat es dann Klick gemacht, als dann eben, weiß ich nicht, im März, glaub ich, drauf kam GPT-4 mit dem API davor. Und dann hab ich gemeint, okay, Wacker, du hast recht gehabt. Jetzt weiß ich, was du meinst und...

Wenn ich es dann irgendwann mal sehe, dann fängt es gleich an, überall zu explodieren und zu arbeiten im Kopf. Genau, dann haben wir das Ganze früher noch überlegt, wie wir uns strategisch aufstellen. Und ja, im August 2023 haben wir dann den allerersten Gen.ai-related Talk auf dem .NET Day Switzerland in Zürich gehalten. Und seit dem Sommer bin ich Vollzeit unterwegs in dem Thema.

Also dann ganz tief eingetaucht und eine hohe Expertise aufgebaut. Du hast eingangs im Gespräch gesagt, Vibe Coding ist 10 % AI und 100 % Software Engineering. Hilf mir bei der Mathematik und erklär vielleicht noch mal ganz kurz, was Vibe Coding ist.

Hehehehehe

Na ja, also, Vibecoding ist ja momentan einer der großen Trends, eines der Buzzwords die es wahrscheinlich gerade durch alle Kanäle schafft.

Ich nenne es lieber Gen.AI Assisted Development.

Nicht Coding, weil Software Development ist mehr als Coding, wie wir alle wissen. heißt also, GenAI Assisted Development heißt, du bist in deiner gewohnten Entwicklungsumgebung, also sprichwörtlich, wirst aber von einem oder von mehreren GenAI Modellen unterstützt, ⁓ Konzepte zu entwickeln, ⁓ Konzepte zu verifizieren, ⁓ vielleicht eine Architektur aufzustellen,

die wieder zu verifizieren, ⁓ dann Code entsprechend zu bauen. Als Pair Programming Partner zusammen mit diesem Gen.AI Modell. Das ist mal so die Grunddefinition. Und wenn man das macht, das ist alles schön und gut. Man darf aber nicht vergessen, dass das jetzt nicht irgendwie

Stand heute, es kann sein, dass es in vier, fünf Jahren ganz anders ausschaut, dass es Stand heute jetzt nicht die KI ist, die jetzt unsere Software schreibt. Soweit ist es ganz sicher noch nicht. Also wie ich immer sage, es gibt noch keine Diode bei mir hier oben, wo ich dann denke und die Maschine schreibt das ganze Ding runter. Also so abgespaced ist es halt noch nicht. Und das 10 % und 100 % ist halt einfach so.

Wir nutzen AI. Ich bin auch kein AI Experte. Ich bin ein GenAI Engineering Experte. Und das ist aber ein himmlweiter Unterschied, weil ich benutze die ganzen Modelle, Large Language Models, Small Language Models, Embedding Modelle und die ganzen Tools etc. drum herum immer nur auf der API-Ebene. Ob es jetzt eine SDK-API ist oder ob es halt irgendwie eine HTTP-Web-API-Ebene ist.

Du nutzt halt die Capabilities von solchen Modellen, sind die 10%, musst aber immer noch wissen, wie man, wie der Franke hier daheim sagen würde, gescheite Software baut. Das heißt also End-to-End Architekturen und das sind eben die 100%. Du musst immer 100 % wissen, was du tust, Software Engineering-mäßig und Software Architecture-mäßig und kannst halt mit den 10 % oder von mir ist auch 20 % halt das Ganze

Beschleunigen, verbessern, kreativer werden, etc.

Sehr interessant, das heißt, Assisted Mode, also sozusagen die Assistenz kommt durch die KI und auch nochmal sehr interessant deine Unterscheidungen, also dass du kein KI-Experte bist, weil du machst wahrscheinlich keine Modelle selbst, sondern du nutzt sie einfach nur, du benutzt die Services, die zur Verfügung stellen. Jetzt hast du schon ein paar Themen hier angesprochen, Large Language Models, Small Language Models und da gibt es jetzt eine Riesenauswahl, also ich glaube täglich sind bei Hugging Face

Genau. Genau. Genau.

Prozentzahl man modelt mehr. Wie kann ich da, kannst du das ein bisschen für uns einordnen? Wann nutze ich einen Large Language Model? Wann ist es besser einen Small Language Model zu nutzen? Was ist überhaupt der Unterschied?

Ja.

Ich kann es tatsächlich nicht einordnen. ist ja Problem. Also fangen wir mal an, ein bisschen auszunehmen. Also ein Large Language Model ist das, was wir kennengelernt haben durch GPT. GPT 3.5, GPT 3.5 Turbo, da kam GPT 4. Large im Sinne von sie haben eine unglaublich viele Aktivierungsparameter des neuronalen Netzes was ja so ein Language Model ist.

Okay.

Man kennt von diesen Closed Modellen, ist ja lustig, kommt zwar von OpenAI, ist aber alles Closed, kennt man die Parameteranzahl nicht wirklich, man munkelt halt damit, dass es viele viele Trillionen sind. Oder einige Trillionen bei GPT-4, 4O, 4.1. Small Language Models sind dann quasi die, die signifikant weniger Aktivierungsparameter haben und die vor allem

ich sag mal, aus der open source Welt kommen, die man dann auch gegebenenfalls selber mal ausführen kann. Also so ein Klassiker ist jetzt Lama 3.370b. Und das 70b steht für 70 Billions, also 70 Milliarden Aktivierungsparameter. Das ist lächerlich klein, verschwindend klein im Vergleich zu der gemungelten Größe von irgendeinem GPT 4.x.

Das war zu large und mal zu small. Aber natürlich ist da irgendwo die Grenze fließend. Von daher sprechen viele vielleicht nur noch von Language Models. Andere bleiben einfach bei LLM, weil es sich mittlerweile auch eingebürgert hat. Und dann muss man halt im Detail über die Ausbrechung und über die Größe des Modells reden.

In deiner Praxis bist du eher ein Model to rule them all oder unterschiedliche Services einzusetzen mit unterschiedlichen Modellen. ist denn da dein Ansatz?

Ha!

⁓ Dinge

auszutesten, neue Konzepte anzutesten, gehe ich meistens auf eines der großen State of the Art Modelle, also GPT-4.0, 4.1 oder Cloud 37, Cloud 4 oder Gemini von Google oder halt eines von diesen Reasoning Modellen, wenn ich eben

einen längeren Prozess entwickeln möchte mit meinem gegenüberliegenden KI-Sparrings-Partner, dann gibt es ja da auch nochmal andere Modelle. Für die jeweilige Software-Lösung dann, ob das jetzt bei uns intern ist oder ob wir es dann im Consulting mit dem Kunden machen, gibt es dann tatsächlich eine Analysephase, welches Modell man einsetzt, weil da kommen ja ganz, ganz, ganz viele Faktoren dazu. Da kommt das Thema, ja, wie man...

über der Cloud halt, Vertrauen, Sicherheit, natürlich diese ganze Datenschutz-Thematik, dann kommen aber auch Kosten dazu, dann kommt aber auch vielleicht, okay, ich will nicht immer raus in eine Cloud, sondern ich will also immer intern bleiben, dann musst du da gucken, welche Option gibt es. Also, das ist eine relativ komplexe Matrix eigentlich, dann zu entscheiden. Und du musst halt sehr, sehr früh dann wirklich einen realen Proof of Concept bauen, weil die Anforderungen

müssen wirklich von dem jeweiligen Modell dann auch tatsächlich erfüllt werden können. Wie man sich vorstellen kann, ein 70B Lama 3.3 kann natürlich viele Dinge nicht so geil wie ein GPT-41. Ist ja logisch, Das heißt also, da muss man relativ früh dann gucken und die Anforderungen auch runter brechen und gegen das dann hoffentlich ideale Zielmodell verproben.

Weil ein Prompt ist nicht gleich dem anderen Prompt. Sprich wenn ich jetzt einen Prompt baue und gehe damit gegen GPT-41 dann funktioniert das mit Sicherheit nicht gegen Lama 370b und übrigens auch relativ oft umgekehrt.

Okay, ja spannend. Also du machst erst den Fächer ganz weit auf und dann, wenn du dann in Produktion gehst, hast du eine knallharte Empfehlung, wie man... Ja genau, also...

Also weit vorher natürlich.

Weil du kannst ja nur dann in Produktion gehen mit dem Kunden, wenn du vorher das Modell dann fest gepinnt hast. Jetzt haben wir unsere Tests gebaut, Language Model-spezifische Tests, weil du willst ja gucken, dass du einen relativ hohen Prozentsatz hast an richtigen Ergebnissen. Und da musst du ja relativ früh dich entscheiden.

Ja, sehr schön.

Genau, und was halt auch zu der Organisation passt Richtung Datenschutz und wo das gehorstet wird. In einem Under-Interview habe ich mal von dir so eine Aussage gehört, die Intelligenz der künstlichen Intelligenzmodel gar nicht so das Wichtige ist. Du findest es Hauptsache super spannend, dass die Maschine uns jetzt endlich versteht. Du hast wahrscheinlich schon ganz viel Code geschrieben.

Genau, genau,

Genau.

der darum ging, irgendwelche Nachrichten zu parsen und Informationen daraus zu holen. Und diese Algorithmen und was wir jetzt wahrscheinlich sogar mit den kleinen Modellen haben, ist, die Maschine versteht uns jetzt plötzlich. Und dass das ein sehr, sehr riesengroßer Vorteil ist in der Interaktion, in dem Usability mit der Software selbst. Vielleicht kannst du da nochmal ...

Schrecklich, oder? Genau.

Ja.

Genau.

sind sogar drei Punkte. A denke ich nicht, dass das, was wir momentan haben, diese Transformer-basierten Language Model Architekturen, dass wir da auch nur annähernd wirklich intelligent unterwegs sind. Also ich versuche tatsächlich dann im Fortgang, vielleicht hast du es gemerkt, den Begriff KI zu vermeiden, weil das ist nicht die KI, wie ich mir eine künstliche Intelligenz vorstelle. Also aus den ganzen utopischen Filmen, die wir alle kennen.

Das sieht man weit, weit weiter voren entfernt. Das war Punkt eins. Punkt zwei ist, ich will mich nicht wirklich immer auf das Weltwissen, also das antrainierte, angelernte Wissen von so Model verlassen müssen. Weil je mehr man die Freiheiten eines Models einschränkt oder eingrenzt, da kommt man vielleicht nachher noch drauf, desto besser kann ich es ja zähmen und nutzen und desto besser werden dann auch die entsprechenden Ergebnisse.

Deswegen ist für mich eigentlich, wie du schon gesagt hast, das wirklich Spannendste und auch das Geilste auf Deutsch der Sprachverständnis von so einem Model. Und ja, je mehr und je more sophisticated quasi das Trainingsmaterial wurde und je größer das neuronale Netzwerk ist, desto höher ist die Komplex... also desto höher, also desto besser kann es komplexere Sprache verstehen.

Wenn ich also einen bestimmten Satz, einem großen State of the Art Model gebe und sage, ok, bau mir da draus mal eine Chasing-Datenstruktur, dann ist die Wahrscheinlichkeit viel, viel höher bei dem großen als wenn ich zu einem kleineren Modell gehe. Da muss ich den Satz oder die Sätze vielleicht einfacher formulieren oder muss dann quasi die Aufgaben und die Fragen, die innerhalb von diesem Satz-Konglomerat sind, aufbrechen oder runterbrechen, damit die kleineren Modelle das verstehen.

aber überhaupt in der Lage zu sein, unstrukturierte menschliche Sprache, semantisch reiche Sprache da reinzugeben und dann in dem Fall, also in dem allerwichtigsten Fall, in einer Datenstruktur strukturierte Ausgabe zu bekommen, weil ich ja dann wieder irgendwas in meiner Software damit anstellen möchte. Das ist faszinierend für mich.

Das stimmt, das ist wirklich so ein Gamechanger, wie man so schön sagt, dass wir in der Lage sind, dass die Maschinen uns einfach verstehen. Was du vorhin angedeutet hast, mit wie viel Intelligenz haben wir wirklich, das hatte ich gerade so vor zwei Wochen mal in einem Vortrag, wo man mit dem Thema KI in der Krebsforschung, in der Bildanalyse einen Vortrag halten und da sprechen die oft von dem Clever-Hans-Effekt. Das ist aus dem 20. Jahrhundert jemand, der so einen Pferdetrick gemacht hat. Der hat gesagt, mein Pferd kann rechnen und hat dann

Vollkommen.

2

plus 3 gesagt und hat das Pferd angeguckt und das Pferd hat fünfmal mit der Hufe aufgestampft und dann haben alle gedacht das Pferd kann rechnen. Man hat später herausgefunden, das ist anhand der Körpersprache, das Pferd einfach nur jetzt ist Start zu stampfen und dann hat er irgendeine andere Bewegung gemacht, jetzt war Stopp sozusagen. was da oft mit beschrieben wird ist, dass bestimmte Pattern

oder so.

Schickad.

die erkannt werden in der Sprache, einem Rückschluss, zu einem Ergebnis führen, aber nicht gleichzeitig intelligent sind. Also das Pferd hat auch ein Pattern verstanden, wusste, was es machen sollte, wusste, was es quasi zurückgeben sollte, ohne dass es jetzt rechnen konnte. Aber es hat für uns quasi so ausgesehen, als könnte das Pferd rechnen. Und in der künstlichen Intelligenz ist es wohl ganz wichtig, dass man auch wirklich schaut,

Ist hier Intelligenz im Spiel oder ist es aufgrund eines anderen Patterns, was das Ergebnis beeinflusst? Fand ich eine sehr interessante Erkenntnis. Ja, in dem Bereich, wir LLMs besprochen, Small-Language Models. Jetzt ist ein Thema, was durch die Decke geht und wo jeder so ein bisschen das Lösungskonzept plötzlich sieht mit MCP, mit dem Model Context Protocol.

Cool! Sehr cool!

Kannst du uns dort nochmal deine Einschätzung geben?

frage mich wirklich,

warum wir immer ein Protokoll brauchen, um irgendetwas zu sehen. Ich meine, es war schon immer so. Ich bin groß geworden in der .NET-Community mit Soap. Also wirklich Soap. Simple Object Access Protokoll. Damals noch mit V bis 6 Soap Toolkit 1999. Das ging dann weiterhin zu Asmx Web Services, wer sich noch mal an die erinnert, und dann weiter zu WCF, der Windows Communication Foundation. Und immer hatten wir ...

Soap und WSDL und XSD, später dann Json mit leichtgewichtigen Web-APIs. Aber war ja immer irgendwie so eine Art von Standard notwendig. Und jetzt auf einmal, und es kann dir wirklich keiner erklären, warum das seit einem Vierteljahr so ist. Diese drei Buchstaben, an denen kommt niemand mehr vorbei. Selbst meine Frau nicht. die hat es jetzt auch begreift. Was ist denn das? Ich hab das irgendwie als Push in meiner ...

In meiner Nachrichten-App gab ich so ein gutes Video. Was hast du für eine Nachrichten-App? Versuch mal aufzudröseln und zwar ohne MCP erst mal. Ich hatte es ja vorhin ganz kurz erwähnt. Das Wichtigste, ⁓ erfolgreich mit einem Language-Model zu arbeiten, ist nicht das reine Weltwissen eines Language-Models anzuzapfen, weil wir wissen, A, es ist outdated, B, die neigen dann zu Halluzinationen, wenn man ihnen keine Leitplanken gibt. Das ist dieser berühmte Kontext.

Ganz kurz, Language Models sind komplett zustandslos, stateless. Das heißt, jedes Mal, wenn ich mit dem eigentlichen Model rede über einen API Call und der API Layer kein Caching oder kein Memory implementiert, was mittlerweile getan wird, zum Beispiel bei ChatGPT oder bei Claude, aber das reine Language Model weiß nichts mehr von dem, was ich vorher mit Ihnen besprochen habe. Das heißt, jeder Call muss

Das, was ich quasi das Language Model wissen lassen möchte, muss in diesem Call sein. Muss alles vollumfänglich abgeschlossen sein. Also sprich, meine der sogenannte System Prompt, also das Scene Setting der Kommunikation mit dem Language Model, meine User Query, das was ich eigentlich wissen will und vielleicht eben so eine Art von Historie, also ein persistiertes Memory. So und das muss alles in so einen HTTP Call rein.

Dann wird das Language Model wieder arbeiten, dann macht das irgendwas und dann kommt es zurück. Und die Summe der Daten nennt man ja dann das Context Window. Und das Context Window hat halt immer nur bestimmende Größe. Bei den State of the Art Modellen sind es teilweise bis zu eine Million sogenannte Tokens. Ja bei Gemini zum Beispiel, 2,5 pro. Bei den OpenAI Sachen sind es glaube ich 128.000 Token. Und wenn du dann runtergehst auf kleine Open Source Modelle bist du...

Da waren wir ganz schnell bei 32.000 oder sogar nur 8.000 oder nur 4.000 oder nur 2.000. Das heißt also, um erfolgreich mit so einem Language Model zu arbeiten, müssen wir immer diesen Kontext steuern, damit es Model genau weiß, was es zu tun hat und was es vor allem zu lassen hat. Und jetzt gibt es auch die unterschiedlichen Patterns dafür. Das Klassische ist, wenn man sich mit Dokumenten unterhalten möchte, dieses Talk to your data.

oder Talk to your Documents. Dann gibt es ja einen Pattern, heißt RAG, Retrieval Augmented Generation. Was macht es? Na ja, es retrieved erstmal Informationen aus einer vorher gefüllten Datenbank, sogenannten Vektor-Datenbank, macht eine semantische Suche, bekommt dann eine Ergebnisliste, basierend auf der Frage, ich über meine Dokumentenbasis gestellt habe. Und dann werden diese Dokumenten-Schnipsel genommen, werden in den Kontext gepackt,

und zum Large Language Model geschickt. Deswegen funktioniert Talk to Your Documents nicht, weil das Language Model mit unseren Daten trainiert wurde, sondern weil vorher ein Vektor-basiertes, ich sag mal, Archiv- oder Persistenzsystem aufgebaut wurde. Das heißt also semantische Suche plus Language Model-Interaktion macht es dann möglich, dass wir über RAG mit unseren Dokumenten reden können.

Das ist immer das gleiche Muster. Wir müssen den Kontext kontrollieren. Entweder füllen wir es selber und das Language Model zieht sich dann die wichtigen Informationen raus und antwortet uns dann mit der Antwort auf die Frage zu unseren Dokumenten. Jetzt ist aber nicht alles ein Dokument bei uns auf der Welt, wie wir wissen. Ganz vieles ist nämlich gar kein Dokument, sondern wir haben halt irgendwelche Systeme. Wir haben keine Ahnung, wir haben eine Google-Suche.

Wir haben ein File-System. Wir haben eine Windows Desktop API. Wir haben interne Business API. Wir haben Wettervorhersage. haben und so weiter und fort verschiedenste Systeme, die immer irgendwie geartet angesprochen werden können. Entweder über ein natives API oder über ein SDK oder über irgendwas web-mäßiges.

Wenn du jetzt eine komplexere Interaktion hinbekommen möchtest, indem du nämlich einfach komplexe Sachen dem Language Model sagst, dann weiß das Language Model natürlich nicht a. Wo bin ich gerade? b. Wie viel Uhr ist es? c. Wie ist das Wetter, wo ich gerade bin? und d. Welche Ausflugsmöglichkeiten gibt es denn überhaupt an dem Ort, ich bin, wo das Language Model gar nicht weiß, wo ich bin? Das heißt also, ich muss ihm dann

sogenannte Werkzeuge an die Hand geben. Tools. Und diese Tools können jetzt sein Get current location, get current weather, get sightseeing recommendations und so weiter und so fort. Die beschreibe ich als Software-System-Entwickler. Das heißt, ich gebe dann dem Language Model in dem Kontext, in dem Request, gebe ich ihm eine Liste von Tools mit.

Tools sind am Ende des Tages Name, eine Beschreibung, die ist sau wichtig, weil wir sind hier auf der semantischen Ebene unterwegs. Das heißt, du musst genau beschreiben, was dieses Tool tut und vielleicht auch, was es nicht tut. Und dann vielleicht eine Liste von Parametern, die reingehen und rausgehen. Also eine Schema-Beschreibung von diesem Tool. Am Ende des Tages ist es eine Funktion, weißt du? Früher dieses Function-Calling, jetzt heißt es halt Tool-Calling. Da geht man jetzt also mit zum Large-Language-Model.

Das Language Model parsed und versteht das, da ist, kann aber bestimmte Dinge nicht beantworten, weil es eben nicht weiß, wo ich bin und wie das Wetter ist und sagt, gib mir doch mal bitte die Information zu dem Wetter und ich habe gesehen in der Description, wenn ich diese Funktion, wenn du mir diese Funktion ausführst, bekomme ich die Information zum Wetter. Und so kannst du dich dann im Dialog mit dem Language Model hin und her hangeln.

dann nach und nach über die Toolcalls, die du ausführst oder ich ausführe, auf meiner Plattform, on-premises oder in meiner Cloud oder wie auch immer, es wird nicht automatisch von irgendeinem API oder Language Model Provider ausgeführt, sondern ich. Das Language Model bittet mich darum, die Informationen über dieses Tool, über die Tool-Ausführung ihm dann wieder zur Verfügung zu stellen. Und dann im nächsten Call packe ich dann diese Informationen, also das Ergebnis.

von dem Toolcall dann wieder mit rein. Und so kann es halt ein bisschen hin und her gehen, wie so eine Unterhaltung von Menschen halt auch, dann eben am Ende die finale Antwort zu bekommen. Ja, und dann bekomme ich vielleicht einen Json zurück, dein Name ist Vorname Christian, Nachname Weyer Location, keine Ahnung, dann kommt irgendwie die Koordinaten, dann kommt irgendwie die Postleitzahl, dann kommt die Stadt und...

Wetter und irgendwie eine Liste von Sehenswürdigkeiten gerankt nach TripAdvisor. I don't know. So. Das ist die ganze Idee. Den Kontext zu kontrollieren in der Kommunikation mit dem Language Model. Entweder Freiform über dieses RAG Pattern oder eben Function Tool, also Schema, gesteuert über Tool Calling.

Ja, sehr spannend für mich. Also ich habe jetzt in letzten Zeit beobachtet, so Themen wie RAG und Embedding und sowas, das ist alles weg. Alle machen nur noch MCP. Sollten sie nicht machen.

Ja, nee, ist es eben nicht, weil die Blase

jetzt nur noch über MCP spricht. es gibt ja LinkedIn. Und LinkedIn ist Fluch und Segen gleichermaßen. Ich hab ganz viele neue Kontakte in LinkedIn, von denen ich wirklich viel, lerne. Aber dann schießen halt von links und von rechts, schießen dann die sogenannten neuen AI-Engineers rein. Wo ich jetzt bisschen despektierlich sag, sie haben Futur, nun blasen keine Ahnung. So, sorry.

Okay.

Und da kommen dann halt so Sachen wie, RAG is dead. Und da denk ich mir auch, okay, liess es halt mal durch. Und dann denkst du dir auch, okay, Hauptargument ist, naja, wir haben ja jetzt State-of-the-Art-Modelle, die so große Context-Windows-Sizes haben, dass wir keinen RAG mehr brauchen, sondern wir schicken einfach immer alle Dokumente hin ins Language Model. Und ich sag, ja, genau, das ist eine super Idee. Super Idee, um Kosten zu sparen, super Idee, um Latenz runter.

oder klein zu halten, super Idee wegen Datenschutz. Also es sind lauter super Ideen. Hashtag not. RAG ist ein geiles Pattern und RAG funktioniert. Der schwierige Teil von RAG ist auch nicht die Interaktion mit dem Language Model, sondern es ist der ganze Teil davor. Daten säubern, Daten splitten, Daten in die richtige Struktur und ins richtige Format zu bringen, das richtige Embedding Model mit den richtigen Embedding Abbildungen zu finden, das in der Datenbank zu speichern.

Ja.

Das aktuell zu halten, das ist die Drecksarbeit. Wenn ich dann die semantische Suche über das Vector-Datenbank-API gemacht habe, dann habe ich eine Liste von drei bis fünf, zum Beispiel, typischerweise, Textschnipsel. So. Und das gebe ich ans Large Language Model. Das heißt, das ist die Kindergartenarbeit am Ende des Tages. Aber RAG ist wichtig.

Aber das trifft

es trifft auch vollkommen deine Aussage vom Anfang 100 Prozent Software Engineering. Also da brauche ich wirklich dann, wie optimiere ich, dass ich wirklich eine kurze Latenz habe, dass ich auch meine Energie consumption und die mit CPUs, GPUs sind teuer, damit ich das sozusagen im Griff halte.

Immer!

Und da ist schon Engineering wirklich notwendig, auch die Daten so aufzubereiten. Viele sagen, schlechte Daten, schlechte KI und die schimpfen dann immer auf das Modell. Ganz genau. Ja, für mich stellt sich die Frage, was machen wir mit unseren Datenbanken? wir haben...

Sag's halt richtig. Shit in, shit out. Es ist einfach so.

Aber jetzt warte mal,

wir müssen ja noch das MCP-Rätsel auflösen. Ich habe jetzt mal erst mal nur so quasi die Basis-Patterns beschrieben und dafür gibt es eine Spezifikation für das Tool Calling. Das wird federführend von OpenAI in der OpenAI-API festgelegt und alle anderen haben es mehr oder weniger dann adaptiert und kopiert. Function Calling oder Tool Calling, wie schon ein paar mal erwähnt.

Okay.

So, und was macht MCP jetzt? Na ja, MCP macht jetzt einen Industriestandard draus. Ins Leben gerufen wurde es von Anthropic oder Anthropic über den Claude Desktop. Und die ersten, die so wirklich breitflächig und professionell adaptiert haben, waren, jetzt schließt sich der Kreis wieder ein bisschen, diese GenAI Assisted Coding Tools in unseren Entwicklungsumgebungen.

Die haben auf einmal angefangen, MCP-Clients zur Verfügung zu stellen, ob sie sogenannten MCP-Servern kommunizieren zu können. Also MCP hat ein klassisches Konzept von Clients und Servers, es gibt auch noch Ressourcen, aber das interessiert meistens niemand, und ein Server kann unterschiedliche Tools zur Verfügung stellen. Das ist eigentlich alles. Und sobald ich das Wort Tool sage,

fängt wieder die gleiche Akkumination an wie vor viereinhalb Minuten, als ich erklärt habe, wie man mit einem Large Language Model eigentlich interagiert. Sprich, MCP ist ein Standard, ⁓ interoperable und discoverable, dynamisch AI-Funktionalität quasi in LLM Models nutzen zu können, indem wir unsere existierenden Tools und Umgebungen mit einbinden können. Ohne

dass wir jedes Mal einen eigenen API Adapter, einen eigenen SDK Adapter, einen eigenen File System Adapter bauen müssen, sondern da gibt es einfach eine Community von MCP Servern. Das ist es im Großen Ganzen.

Also

persönlich gesprochen bin ich über den Standard eigentlich froh, weil wenn jeder da sein eigenes Protokoll hacken müsste, mittlerweile habe ich glaube ich mitbekommen, Windows hat das auch in ihr Betriebssystem irgendwie eingebaut, also so dass wir schon einiger Tools auch standardmäßig zur Verfügung gestellt werden. Aber der Hype ist natürlich, geht durch die Decke zu dem Thema.

Ja.

Ja.

Ich wage jetzt wirklich einfach mal so zu behaupten, zu formulieren, wenn es interoperable Standardprotocol geht, habe ich schon das eine oder andere gesehen und auch an einem einen oder anderen schon ein bisschen mitgearbeitet und vor allem es adaptiert. MCP zum Stand heute ist eine Es ist eigentlich nur,

auf der lokalen Maschine über Standard In und Standard Out. Jetzt wurde es erweitert auf Remote, erst mit SSE. Jetzt wollen Sie es wieder umbauen, also von Server-Send-Events, wieder umbauen auf HTTP Streaming. Security, Oh wait, haben wir gar nicht dran gedacht. Sehen wir jetzt gerade dran, es zeichnet sich ab, als würde es O-Auth 2.1 werden mit ein paar Erweiterungen. ⁓

einfache Deployability, Scalability, weil momentan ist das Protokoll Inherent State Full. Also da gibt es noch so viele Baustellen und so viele Issues. Ich denke mal, gegen Ende des Jahres sehen wir da ein bisschen klarer, weil sich jetzt auch eben dann erfahrene Crews wie von Seiten Microsoft, Seiten Google, von Seiten Meta dann entsprechend auch daran beteiligen, das Ganze mal bisschen voranzutreiben.

Aber das ist auch ein spannendes Pattern, was ich beobachte, ehrlich gesagt, dass in diesem ganzen AI-Thema steckt auch so viel Geld drin, dass das unbedingt erst mal raus muss. Das heißt, die Leute bringen, releasing sehr frühzeitig schon ihre ganzen Tools, auch Protokolle und solche Sachen, das anzutesten und auch den Benefit sozusagen der Nutzung von der Service ist dann voranzuschreiten, weil ...

Man kann einfach nicht so lange warten. Im Moment ist da wirklich eine riesige Geschwindigkeit dran und man will erstmal so paar Sachen flankieren und sagen, hier haben wir erstmal was und...

Ich glaube,

ich weiß was du meinst, aber ich glaube es liegt hauptsächlich daran, weil viele einfach nicht wissen, A, was geht wirklich mit diesen Modellen und B, was brauchen die Leute wirklich da draußen. Und deswegen wird es einfach rausgeschossen. Und vieles ist super, super halb gar. Und zwar nicht nur MCP, teilweise auch die Modelle, teilweise auch die SDKs, teilweise auch die Embattings, teilweise auch die Tools, etc. drum rum.

Vieles ist extrem, extrem halb gar. Plus dann natürlich noch die exponentielle Entwicklung in den Modellen und in den Features und in den Frameworks drum herum. Das kann man als normaler Software-Ingenieur eigentlich überhaupt gar mehr fassen.

Also irgendwie denkt man, das ist schon ewig, so viele Bewegungen hat man drin und dann schaut man nach hinten, sind gerade mal zwei, drei Jahre, wir das Thema, wo das uns überhaupt begleitet und das ist schon echt eine enorme Geschwindigkeit und dort auch nochmal Hut ab, vor dir, dann mit Unternehmen da wirklich was zur Produktion zu bringen auf so einem immer weiter entwickelten Gerüst, also das ist mit Sicherheit auch eine Herausforderung.

Zweieinhalb Jahre.

Nö!

Vielleicht nicht Hut ab von mir, sondern Hut ab von meinem Team bei Thinktecture, weil die haben es mir ja ermöglicht, dass ich dann ab Sommer 2023 meine Rolle konvertieren konnte in Full-Time Research & Development und Visibility. Zusammen mit meinen Kollegen, die dann natürlich andere oder bestimmte Teilbereiche entsprechend dann aufgreifen und dann selber

Vorträge machen. Aber es muss natürlich dann auch das Unternehmen und die Kultur des Unternehmens entsprechend dann zulassen.

Auf jeden Fall. Wir haben jetzt ganz viel von den Modellen gesprochen und wie ich als Entwickler die KI nutze. Was natürlich ein spannender Use case ist, wenn ich ja eine Applikation, Applikation entwickle und die Applikation jetzt plötzlich mit KI erweitert wird oder bereichert wird sozusagen, dass ich innerhalb von meinem Software Entwicklungs, wie auch immer, Pattern, Lifecycle, wie ich ja unterwegs bin, dass ich jetzt plötzlich dort eine neue Möglichkeit habe,

Mhm.

KI mit einzusetzen. Welche Pattern und welche Practices siehst du dort?

Du meinst jetzt quasi, dass wenn wir als technische Consultants bei unseren Kunden sind, die entweder Entwickler bei einem ISV sind oder Entwickler in einem Unternehmen, wie wir dann mit denen sprechen und voranschreiten, deren Software quasi Gen.AI-enabled zu machen, richtig? Genau.

Genau, also ich habe eine Applikation,

ich entwickle, die ich auch an meine Kunden verkaufe. Und jetzt denke ich, das wäre doch sehr hilfreich für die Applikation, hier nochmal von der Power von AI zu profitieren. Und wahrscheinlich habe ich auch Vorurteile am Anfang. Also wir sprechen ja Hochsprachen, die sind hochtechnisch. Dafür braucht man eine Ausbildung. Jetzt haben wir plötzlich einen Prompt, der in ganz normaler Sprache gesprochen wird. Und wie passt das in meine Architektur rein? Was sind die Tools, die ich dort benutze?

Ja.

Genau. Also tools vielleicht nicht, sondern eher die Patterns. Also wie du es ja in der ersten Frage hattest.

Ich und wir sehen einfach einen riesen Hebel mit der menschlichen Sprache neuartige Zugänge oder andersartige Zugänge zu Software-Systemen zu schaffen. Also nicht mehr notwendigerweise über die klassischen graphical user interfaces. Wir kennen ja noch die ganzen

Desktop Patterns mit Menü im Menü, im Submenü, im Submenü, und dann geht ein Property-Dialog auf, dann hast du da wieder ein Menü und ein Subproperty-Dialog und ein Grid und so, sofort. Und jedes Mal, wenn du was Neues hinzubaust, musst du dir ja überlegen, wo ins UI oder ins GUI passt es jetzt. Ist es jetzt nur ein Fenster oder muss es irgendwie ein komplett neues Modul sein, das sich wieder irgendwie dynamisch lade und wie dynamisch lade wie

Zeige ich es dann an, wie ist die Interaktion, Maus orientiert, Keyboard, Shortcuts und so weiter und so fort. Da sind wir ja quasi die letzten, was haben wir, 20, 25, die letzten 40 Jahre darauf konditioniert worden, So zu denken. Und jetzt mit natürlich Sprachlichkeit auf einmal können wir das komplett umdrehen und sagen, Entschuldigung für die Wortwahl, aber scheiß doch aufs GUI. Wir sagen der Software einfach, was wir wollen. Das ist natürlich jetzt das andere Extrem, ja? Das heißt also,

Ich spreche nicht mal mehr über eine Chatbot-Dialogbox oder ein Textfeld, sondern ich rede mit dem Ding einfach. Dass das natürlich nicht komplett durchgängig implementierbar ist und auch nicht durchzudenken, ist es klar. Ich will nur quasi das andere Extrem jetzt mal hochholen. Dass wir quasi allein über semantisch angereichende, unstrukturierte Sprache und Interaktion mit einem Software-System slash Computer

genauso interagieren können über ein neues UI, Universal Interface. Also nicht mehr der User Interface, sondern das Universal Interface. So, und das kann in meiner Anwendung sein oder Microsoft geht sogar noch einen Schritt weiter, wie du gesagt hast, ist sogar in Windows drin. Und Google geht einen Schritt weiter, ist sogar demnächst in Chrome drin. Das heißt also, diese Idee, Language-Modelle sogar in Basisinfrastruktur zu verfügen, stellen, die schon lang da.

also die schon lang da und wird auch gerade umgesetzt. Das heißt, das ist immer so die Basisidee, dass wir sowohl mit der Software als auch das, was die Software herum liegt, Dokumentation, Hilfesysteme, Ticketsysteme und so weiter, natürlich sprachlich interagieren können. Ohne, dass wir großartig uns an der GUI vergreifen müssen, verkünsteln müssen. Heißt aber nicht,

dass UX jetzt wegfällt. Eher im Gegenteil, UX wird jetzt noch wichtiger, weil UX steht ja für User Experience und wenn wir jetzt auf einmal mit natürlich Sprachlichkeit entweder geschrieben oder gesprochen mit unserer Software interagieren, dann hat es natürlich ganz andere Auswirkungen, auch ganz andere Rahmenbedingungen und ganz andere Voraussetzungen. Das heißt also User Experience in so einer Chat AI Welt oder in einer

AI-Agentic-World wird UX noch wichtiger, aber ganz anders da als wir es bisher hatten. Das ist die Grundidee.

Sehr sehr.

Ja, das ist sehr spannend. Es hat, wie du sagst, schon ganz andere Herausforderungen. hatten im Podcast jemand, Ben Freiberg von AWS. sich auf Alexa Skills sozusagen spezialisiert, hat Voice Games gemacht und er hat gesagt, ist eine ganz andere Herausforderung, Voice zu arbeiten plötzlich. Wenn du keinen Bildschirm vor dir hast, wo ist der State und ...

Mhm.

Wobei, jetzt müssen wir ehrlich sein, die alten Alexa Skills waren brodumm. Du

musstest dich ja wirklich an so ein Protokoll halten, dass du einigermaßen mit denen interagieren konntest. Das bei Language Models natürlich eine ganz andere Ausnahme.

Ja.

Also die Sprachverständnis schon, aber dir Gedanken zu machen, sonst zeige ich alles im Grid, sonst habe ich immer alles vor der Nase, aber ich bin jetzt plötzlich, in irgendeiner Demo hattest du, glaube ich, eine Apple Watch, du dann irgendwas mal, da hast du ja kein User-Interface, wo du jetzt plötzlich dann eine Übersicht siehst, sondern das Ganze muss anders funktionieren und der Software-Entwickler muss natürlich auch anders denken. Also der kann gewisse Sachen vielleicht einfach per Audio wiederholen, damit ich das wieder präsent habe als User. Also das heißt, das Multimodale, wohin wir uns entwickeln, wir können tippen, wir können sprechen.

Ja, ja, okay.

Genau.

ne genau

Ja.

Das bedeutet dann nochmal ein ganz anderes User-Erlebnis, auch anders mit dem User, dann das Feedback zu geben.

Genau, da kommt bestimmt in bestimmten Umgebungen das, was du auf der Nasa hast. Also wir sehen ja gerade, dass es neue Google Class Entwicklungen gibt. Also wer da die Google I.O. ein paar Wochen verfolgt hat, das war ja eine sensationell geile Demo. heißt also auch da werden wir AI Unterstützung haben, sowohl im Input als auch im Output, also sprich im Feedback-System, sodass wir eben

nicht nur textuell und nicht nur audio, sondern eben auch visuell und vielleicht sogar haptisch über irgendwelche Akteuren dann neue User-Erlebnisse bauen können.

Ja, sehr spannend. Und was nutzt du jetzt konkret, das umzusetzen? Hast du einfach eine API, wo du einen Prompt hin haust oder wie baue ich dann eine Architektur auf?

Genau.

Genau. Also am Ende des Tages,

ja, also am Ende, am Ende des Tages bauen wir oft so, du hast ein API, das baust halt wie du willst, ja, in Asp.core oder in Java, Spring, XYZ, wie auch immer das heute gerade heißt, oder halt in Python, FastAP, you name it. Und dahinter hast du eigentlich so eine Komponente, die dann quasi intelligent entscheidet, was dieser menschlichsprachliche Input jetzt bedeutet.

könnte man jetzt bezeichnen als semantic router. heißt, da stelle ich dann über ein Embedding-Model fest, was ist jetzt der Intent, was ist sozusagen die Klassifizierung von dieser Frage oder von dieser Eingabe, ⁓ dann ganz klassisch in einen fachlichen Service oder in einen anderen fachlichen Service abzubiegen. diese fachlichen Services sind jetzt wieder Gen.AI-enabled. Der eine fachliche Service kümmert sich zum Beispiel ⁓

des Suchen und Verstehen von Dokumenten, in Klammern RAG und Semantic Search. Der andere fachliche Service oder Talk to your Data, der andere fachliche Service spricht vielleicht mit einem oder mehreren APIs oder Tools, Talk to your Applications oder Talk to your Systems, dann eben wieder mit der LLM-Interaktion oder über die LLM-Interaktion dann eben eine Antwort zu bekommen und zwar

immer eine strukturierte Antwort. Das ist ein Pattern, das wird bei uns in alle reingebrügelt. Die Interaktion mit dem LLM ist immer strukturiert, vor allem die Ausgabe. Weil eine unstrukturierte Ausgabe macht nicht Sinn. Selbst in einem RAG-Szenario brauche ich zur eigentlichen Antwort zu der Frage aus den Dokumenten, mal minimum die Liste an Quellen, wo das Language-Model

die eigentlichen Schnipsel, die Quell-Schnipsel gefunden hat. Das heißt, ich habe immer eine Datensstruktur und wenn Language Models mit Datensstrukturen arbeiten können, fühlen sie sich wohler und neigen weniger zur Halluzination. Tatsächlich. genau, weil wir wollen es ja dann weiter verarbeiten in dem verteilten System. Genau.

Maschinenlispa. Also wir haben dann einfach einen Sätze.

Ja super. Das heißt, wir definieren ein Routing, wie die Daten reinkommen. Oft hat man da aber auch noch Guardrails, wo man dann einfach sagt, nur da lang und nicht da lang. Okay, du siehst es davor.

ist hoffentlich sogar noch davor, also vor dem Routing,

weil du zum Beispiel Prompt Injection willst ja vorher schon weg haben. Das heißt also diese Guards können vor dem Router sein, sie können optional nochmal nach dem Router sein, aber oftmals hast du sie auf jeden Fall dann auch auf dem Rückweg, zu gucken, entspricht die Antwort meinen Qualitätsmaßstäben bei wirklich sensiblen Sachen kannst du dann sogar

noch mal Output Guards haben, zu verifizieren, ob das jetzt wirklich aus den Daten ist oder ob das Model nicht doch halitoniert hat. Auch diese Möglichkeit gibt es ja. Genau.

Ja,

interessant. hast dann gesagt, das teilt sich dann auf in verschiedene Services. Jetzt komme ich in das nächste Hype-Thema, was sozusagen gerade durch die Bubble geht. Sind das jetzt diese Agents, von denen alle sprechen? Agents, genau.

Ich glaube, ich weiß, was kommt. Die Agent!

Ach Gott, so viel Zeit haben wir auch nicht mehr. Wir sind schon lange, lange, lange unterwegs hier in dem Podcast. Was übrigens total viel Spaß macht. Ja und nein. Also das Problem ist halt jeder in der AI-Industrie sagt jetzt zu allem irgendwie Agent. Also selbst wenn ich nur einen einfachen Prozess habe, der einen LLM-Call macht, es jetzt ein Agent.

Okay.

von mir aus. Dann ist alles ein Agent, ist auch okay. Dann müssen wir uns aber nur unterhalten über welche anderen

Formen von Interaktionen gibt es denn noch. Dann haben wir also einen Simple Agent, dann haben wir einen Agent-basierten Workflow, nennt man gerne auch Agentic Workflow dann. Das ist ja dann das, was ich gerade im Kleinen beschrieben habe, kann ja dann sehr, sehr groß werden. Aus dem Routing können ja dann mehrere Abzweigungen kommen und dahinter können ja wieder mehrere Abzweigungen kommen und dann kommen die irgendwie wieder als Antwort zurück.

bis hin dann zu Agent-to-Agent-Kommunikation, bis hin zu vollautonomen Agents, die dann quasi von sich aus Dinge dann entscheiden, wie es weitergeht. Bei einem Simple Agent mit einem oder mehreren oder wenigen, ich sag mal sequenziell LM-Calls ist es ja klar, da bin ich der Master of Disaster, mein Code bestimmt, mein Code...

hat die Input, die Invariance bekommt am Ende dann den Output und validiert den und gibt ihn dann raus. Bei einem Workflow ist es so, es ist zwar komplexer, aber es ist ein Workflow. Das heißt, es ist statisch. Kann natürlich eine State Machine sein, kann irgendwie ein Flussdiagramm sein. Okay, aber ich entscheide immer noch, wie der Workflow ausschaut und wann er wie welchen Zweig und welche Abbiegung nimmt.

bei autonomen Agenten, AI-Agents, entscheiden die Modelle das. Das heißt also, die entscheiden dann quasi je nachdem, welcher Input kommt im Kontext und welche Liste von Tools stehen denn zur Verfügung für den jeweiligen Agent, dann entscheiden die, ob jetzt die Aufgabenstellung fertig ist und gelöst wurde oder ob man nochmal eine

Runde drehen muss. Und dann kann sein, du hast einen großen, allwissenden Agent oder du hast kleine, spezialisierte Agents wie vielleicht in so einem Softwareentwicklungsteam, wo du dann halt einen PO hast, dann hast du halt einen Architekt, dann hast halt einen Senior-Dev und Junior-Dev, dann hast einen Tester, hast du einen Doc-Schreifer und so weiter und dann könnte man das quasi so als Agent-Network bauen und könnte das, könnte es komplett autonom bauen, aber da glaube ich sind wir aktuell

noch nicht angekommen, ⁓ wirklich autonome Agents reliable und zuverlässig bei uns zu

Das heißt, die Technologie ist schon da, aber die Qualität der Ergebnisse braucht noch ein bisschen.

Genau, glaube die Modelle

sind dafür momentan noch nicht wirklich gut genug. Und ich glaube, und jetzt schließt sich ein anderer Kreis wieder, weil ich bin vorhin extra ja nicht auf die Frage eingegangen, wann wählst du welche Modelle, wann große und wann kleine. Ich glaube zum Beispiel bei Agents, auf dem Weg hin zu autonomen Agents werden wir sehen, dass wir kleine hochspezialisierte

feingetunte Modelle haben werden, die sehr sehr sehr genau wissen und sehr sehr sehr detiziert und spezialisiert abgestimmt sind und optimiert sind auf diesen einen Agent. Und dann können wir davon wieder mehrere haben.

Der Linux Ansatz, do one job and do it well und davon dann ganz viele kleine zu haben, die dann orchestriert werden können. Ja, Wahnsinn, richtig interessant.

Genau. Genau. Aber das sind wir,

glaube ich, noch bisschen davon entfernt. weiß, da schreien sich auch die Geister. Also wirklich. Es gibt Experten in meiner Community, die sagen, es geht alles heute schon. Aber ich experimentiere wirklich viel damit rum. Und jenseits der Hello World Beispiele und der SDK Beispiele, wo dann halt so eine simulierte Reise oder eine Travel Planning gemacht wird.

Also da sind wir glaube ich von realistischen Anwendungsfällen echt noch weit entfernt. Entschuldigung, und das kommt noch dazu, wir suchen ganz oft nach Agentic Use Cases, aber die Welt funktioniert aktuell ja noch anders. Die Welt, vor allem die Businesswelt, funktioniert ja in Prozessen und in Workflows. Deswegen sind Agentic Workflows super geil, weil

Das ist quasi die...

Selbst wenn du das Wort agentic weglässt, es sind immer noch Workflows und das versteht jeder, das kennt jeder, damit kann jeder umgehen und dann streust du noch ein bisschen LLM, SLM, Embeddings und ein bisschen semantic memory und semantic routing drüber und dann haben wir's.

Dann

haben wir die. Perfekt. Ja, aber das ist eine gute Überleitung. Use Cases. Was siehst du denn mit den Firmen, mit denen du zusammen arbeitest? Also oft Document Control, also Talk to your Documents. Ich sehe sehr viele Chatbots, die dann interagieren. Ich habe auch schon mit anderen Beratungsfirmen gesprochen, die sagen, es gibt ganz, ganz viele Ideen, die meist ähnlich sind, aber dann landen auch nur 20 Prozent in Produktion.

Was merkst du denn so in deinem Alltag? Wie stehen wir denn dort? Was für interessante Use Cases siehst du?

Also ich könnte jetzt ganz viel...

ganz viel rumbullshitten, aber am Ende des Tages ist es allerallermeist einfach doch RAG. Das ist einfach so. Weil es halt lowhanging ist und weil es auch am einfachsten zu verstehen ist und weil es auch im immediate einen unmittelbaren Mehrwert liefern kann. Ob das jetzt innerhalb von einem Chatbot ist oder ob das in die Anwendung integriert ist, das ist das viel Interessantere. Wir sprechen vielleicht nicht über diese

über irgendwie abgedrehten neuen Use Cases, sondern wie kann ich denn diese GenAI-enabled Use Cases, also Talk to your Data, Talk to your System, Semantic Routing, Real-Time Interactions, also über multimodale Real-Time Modelle, wie kann ich die sinnvoll in einer Software einbauen, damit sie Mehrwert für den Benutzer von der Software hat? Thema UX wieder auf einmal. Das heißt also da kreuzt sich und da geben sich wirklich diese GenAI-Themen und die

Ux-Themen dann wirklich wieder die Hand. Wir sehen einiges an POCs zum Ausprobieren, wohin könnten Agents gehen, also sowohl Agendic Workflow als auch dann wirklich autonomous oder halb-autonome Agenten und ein Pattern oder ein Use Case oder Pattern, was immer wieder hochkommt, was unabdingbar ist, ist human in the loop, sprich

Der Mensch ist da im Sinne von trust but verify. Also vertrauen, aber bitte überprüfen. Vertrauen ist gut, Kontrolle ist besser. glaube, so heißt es auf Deutsch. Dass man quasi in diese Interaktionen immer, Minimum mal die eigentliche Quelle noch mit reingibt aus dem Ergebnis, was so ein Language Model dir gibt. Ob das jetzt aus dem RAG-System kommt, dann brauchst halt irgendwie das Dokument und die Seite und dann bist du auf den Absatz oder sowas.

Oder es kommt dann aus einem Tool. Du musst wissen, welchem Tool oder aus welchem System kam das denn dann. Am besten mit einem Link, dass du das dann nochmal verifizieren kannst, zu gucken, ja, genau, das kommt da und da her, passt. Oder wenn du quasi Workflows hast, du hast komplexen Workflow und ich habe es ja vorhin gesagt, die Workflows in der echten Welt sind ja immer mit Menschen verbunden, mit mehreren Menschen auf unterschiedlichen Ebenen.

unterschiedlichen Zuständigkeiten und unterschiedlichen Rechten oder Berechtigungen. Das muss natürlich auch in diese Agilic Workflows mit reinbringen. heißt also Human in the Loop ist extrem extrem zentral.

Ja, echt spannend. Ich hoffe persönlich, also ich sehe ganz viele neue Applikationen, einfach ein Chat-Fenster drin haben und ich hoffe nicht, dass das Chat-Modell das neue UI der Zukunft wird, weil ich glaube Chat ist für eine bestimmte Art der Kommunikation gut. Wer verliert irgendwann den Kontext und dann sollte man es nicht nutzen. Also mein Wunsch wäre, das was du geschildert hast, richtig eingebettet in die Applikation, die Applikation noch bisschen intelligenter machen.

Genau.

Genau.

Ich glaube, gibt alles Mögliche. glaube, es gibt das, was wir gerade beschrieben haben. Plus es gibt aber auch etwas, wo du dann quasi in deinem, ich nenne es jetzt mal, Enterprise Messaging System bist. Also in Microsoft Teams oder in Slack oder in Discord oder sonst was. Und da ist ja Chat dominante Interaktionspattern. Und wenn du da hinten dran wieder so einen AI-enabled Endpoint hängst, ist ja alles okay.

Wichtig ist nur die Basisarchitektur dahinter. Das heißt also, du hast immer so einen API-Endpunkt. Dahinter ist Guarding, dahinter ist Routing und dann geht es in eine fachliche Systeme, wo du dann mit AI arbeitest oder eben ohne AI arbeitest. Und vorne dran kannst du dir dann einen Slackbot, einen Teamsbot, einen WhatsAppbot hängen, du kannst eine PWA hängen, du kannst eine Desktopanwendung hängen oder du kannst eine Watch-App hängen. Weil am Ende des Tages geht immer String rein.

und string raus. Oder halt eine abgewandelte, strukturierte Form von Ausgabe mit Ergebnis plus irgendwie Liste von Quellen, erkannte Sprache oder wie auch immer. Also menschliche Sprache rein und eine Datenstruktur raus mit dem menschlichen Sprachergebnis da drinnen, es dann wieder in dem jeweiligen Client dann halt zu verarbeiten.

Sehr spannend, ich merke immer mehr, du denkst multimodal, es sind unterschiedliche Clients, verteilte Systeme. Du hast jetzt gesagt, der Mensch muss in der Loop sein. Diese Technologie macht auch was mit den Menschen. Wie verändert sich dadurch der Job? Du sprichst sehr oft mit ISVs, die dann halt auch selbst als Aufgabe haben, Software zu entwickeln oder Architektur zu betreiben.

Immer! Genau!

Wie siehst du heute schon diese Veränderung, die KI mit reinbringt? Ist das auch eine Sache, die im Experimentierstatus ist oder verändert das schon wirklich Arten wie Entwickler oder Architektenarbeiten aus deiner Sicht?

Also aus der Entwicklersicht sieht man auf der einen Seite noch bisschen scheu mit den GenAI-Assisted-Tools zu arbeiten. Auf der anderen Seite dann aber auch sind die Tools noch nicht intuitiv genug. Also ich hatte gestern erst einen Call mit einem Kunden, der dann berichtet, ja, unsere Leute haben sich jetzt GitHub Copilot angeguckt und es funktioniert überhaupt nicht, so wie sie sich das vorstellen. Was nämlich schade ist, weil

Wenn ich schon so einen Universal Interface Ansatz auch in der IDE habe, dann sollte das vielleicht ein bisschen interaktiver, also A, intuitiver und B, dann interaktiver möglich sein, sich dann heranzurobben an die Lösung, die man eigentlich will. Und das ist halt ja teilweise noch nicht wirklich möglich. Sprich, da gibt es dann auch noch ein paar Hürden, die wir vielleicht noch technisch und technologisch, aber eben auch wieder von der User Experience in den Entwicklungsumgebungen nehmen müssen.

Und ansonsten, wenn ich jetzt außerhalb der Entwickler gucke, sondern bei unseren Kunden, die dann quasi ja selber Software bauen, die sich ja dann wieder entweder intern zur Verfügung stellen oder dann an die Endanwender verkaufen, da gibt es ganz, ganz viele Ideen. Also A gibt es natürlich das FOMO, also Fear of Missing Out. Die ganze Welt spricht davon und wir haben keinen Plan und schon ganz klar keine Lösung dafür. also den gibt es natürlich.

Dann gibt es diejenigen, ganz ganz viele Ideen haben, aber nicht wissen, wie sie es angehen sollen. Dann gibt es die, die halt eben sagen, ja okay, ich habe da schon mal rumgespielt, weil am Ende des Tages kannst du ja mit so einem Open-AI, API Playground und ein bisschen Prompting kannst du ja schon viele Sachen einfach mal schon mal ausprobieren. Inklusive RAG musst du halt händisch ein bisschen kopieren, pasten, beziehungsweise auch Tool Calling, da kannst du ja auch experimentieren.

wissen aber nicht, wie sie es dann quasi End-to-End in ihre Lösung reinbringen. Weil es ist ja dann kein Green-Field, es ist ja nicht neu, sondern es ist ja Brownfield. Es existieren Anwendungen, existieren Clients, es existieren APIs, existieren Dateien und Dokumente, es existieren Datenbanken. Wie kommt das dann da rein? Und da ist dann halt entsprechend hoher technischer Beratungsbedarf, um dann all diese Fragezeichen und Baustellen dann halt auflösen zu können.

Ja, sehr gut. Und da kommt jeder natürlich ins Spiel mit Think techture mit eurem Angebot. Wir haben jetzt schon auf den Namen fallen gelassen. Was macht ihr denn bei Think Tecture genau? Wie viele Leute seid ihr? Und wenn ich jetzt Formo habe und unbedingt ins Thema einsteigen will, wo treffe ich euch?

Haha.

Also wir sind ein kleines Team von hochspezialisierten Software-Engineers, die geil sind, sich in neue Technologien einzuarbeiten und die dann aber auch realistisch zu betrachten, sie dann aber auch wirklich tief technisch zu verstehen, sie dann optimal anwenden zu können. Sprich, sind jetzt demnächst 20, also es kommen noch zwei neue jetzt in dem Jahr dazu, wir sind 20 Leute,

Tieftechnisches Consulting, wie ich immer sage, wir kommen nicht mit Anzug und Schlips und vielen Folien, sondern wir kommen in Jeans und Hemd und Visual Studio offen, ⁓ eben dann mit unseren Kunden zusammen zu erörtern und zu erarbeiten, was sie brauchen, weil die Kunden kommen zu uns.

weil sie uns irgendwo gesehen haben. Es wieder dieses Sichtbarkeitsthema. Das ist halt extrem wichtig bei uns. Also Visibility. Rausgehen und an der Expertise sharen. Konferenzen, Meetups, eigene Webinare. Früher Bücher tatsächlich, früher Fachmagazine, früher Blogposts. Und dann kommen die Kunden, denken, ja genau, das ist das Thema, was ich brauche. Dann kommen wir dahin und dann...

merkt man, ja, das ist durchaus auch ein Teil des Problems. das Problem ist ein bisschen mehr. Es ist nicht einfach nur eine Rose, sondern es ist ein ganzer Blumenstrauß an Themen, die wir eigentlich hier haben. Und dann versuchen wir mal mit dem Kunden das quasi zusammen zu erarbeiten. Immer hands-on, soweit es irgendwie geht und Sinn macht, dann eine praktische und eine pragmatische Lösung zu finden.

Wenn man mit dir spricht, man merkt, bei euch ist bestimmt eine super Kultur auch. du gerade so hands-on das, was du am Anfang gesagt hast, hier, habe das jetzt einfach mal gemacht. Was braucht es denn aus deiner Sicht, ein Thinktecturer zu werden sozusagen? Wie wählst du das aus?

⁓ das Wort heißt

übrigens Thinktect.

Okay, sorry. Was braucht es, ein Thinktect zu werden bei euch? Wie wählst du das aus? Auf was schaust du, in dieses Team reinzupassen? So ein bisschen ...

HM!

Ich schaue,

ich wähle gar nicht mehr aus, das ist auch gut so, weil ich dann teilweise zu zu biased war, wenn Leute dann kamen und sich dann beworben haben. Also wir haben den ganz normalen Entwicklungs-, erquatscht den ganz normalen Bewerbungsprozess, der ist halt sehr sehr flach, aber wir schauen, dass es natürlich ein offener Mensch ist, ein kommunikativer Mensch ist und dass er sich

sich technologisch ausdrücken kann, dass es sehr schnell geht, neue Konzepte auch zu ergreifen, zu begreifen, sie dann auch zu lernen und danach umzusetzen. das allererste, ich glaube im ersten Call macht es mittlerweile mein Kollege oder spätestens im zweiten Call ist, Entwicklungsumgebung auf und ran an die Tasten.

Per

Programming mit euch zusammen oder Livecoding.

Ja,

spätestens dann, wenn du eingeladen wirst zum Vorstellungsgespräch nach Karlsruhe ins Office, das ist den ganzen Tag nur Coden und interaktiv Software-Ingenierienthemen besprechen, Software-Architektur, Consulting-Situationen entsprechend simulieren und so. Und dann gucken wir, dass du halt weißt, wovon du sprichst.

Du hast gesagt, du wählst selbst nicht mehr aus. Macht ihr das zur Teamentscheidung? Also sitzen dann da cross-funktional mehrere Leute, die dann einfach ihr Voting geben?

Genau. Genau so ist es ja. Genau,

angefangen von, ja... Wir haben immer ein Problem mit so Titeln und mit so Abteilungsnamen, weil das sind sowieso Schall und Rauch. Also, es ist ein nicht so technischer Kollege dabei, der sich sehr, sehr stark aber den Kundenkontakt, die Kundenverbindungen kümmert. Dann ist eine Kollegin dabei aus dem Backoffice, die das Ganze zusammenhält.

quasi und dann sind natürlich meistens zwei Techniker noch dabei, einer für die Basis Technologie und einer dann für den Gen. AI Aspekt. Genau und die entscheiden das dann im Team.

Wie wichtig ist für dich die Cross-Funktionalität bei demjenigen, zu dir kommt? Weil ihr seid ja schon hochspezialisiert unterwegs.

Ja, je nach Rolle auch. Wir haben nur drei Rollen, wir bezeichnen. Das ist Developer, Architect und Consultant. Sind aber natürlich am Ende Tages Bänder, also Erfahrungsbender. Der Dev geht von hier bis hier und dann fängt der Arc hier an, ist aber noch in dem Dev-Band, aber geht dann bis hier und dann fängt der Consultant hier an, ist noch im Arc-Band, aber geht irgendwie dann so nach oben.

Und je nachdem, wie sich die Gegenseite der Bewerber dann halt entsprechend gibt, welche Vorstellungen er oder sie dann halt auch hat und was wir dann aber intern auch brauchen, versuchen wir es dann halt entsprechend zu matchen. Also da gibt es keine feste Tabelle oder Matrix oder sowas.

Sehr cool.

Ich glaube, die Kultur, das hat man auch den ganzen Podcast übergemerkt, dass ihr sehr pragmatisch dort unterwegs sind und die Hierarchie eigentlich zweitrangig ist. Jetzt habe ich dich bei irgendeiner Konferenz gesehen oder ich habe den Podcast gehört und weiß jetzt, der Christian hat ein extremes Expertenwissen dort aufgebaut und ich rufe bei euch an, ich bekomme jetzt einen anderen Consultant. Wie verteilt ihr sozusagen euer Wissen intern? Also du bist ja im Moment sehr tief drin. Du hast dir

Ja, genau.

Hmm.

Zeit genommen,

tief auch in dieses Thema einzutauchen. Und wie verteilt ihr in dem Team, die natürlich auch einen Daily-Job haben, die damit Sicherheit nicht so viel Zeit haben, so in Tiefe zu gehen, wie sichert ihr das sozusagen, dass das Wissen, was einzelne Leute jetzt haben, verteilt werden im Team, obwohl die sternförmig unterwegs sind bei Kunden? Das ist auch immer eine spannende

Ja.

Ja,

super Frage. Also in unserer, ich glaube es heißt Gleitkultur jetzt auf Neudeutsch, ist Research ein ganz wichtiges Standbein. Das heißt wir haben 25 plus 25 Tage Research pro Experte im Jahr. Die 25 sind zur freien Verfügung und 25 sind dann, ich sag mal taktisch, strategisch gebunden.

Am liebsten ist es mir, dass wir immer alles, was wir researchen, Ergebnis öffentlich machen. Weil öffentlich schlägt ja zwei Fliegen mit einer Klappe. Es ist sichtbar und jeder von uns kann das auch angucken und sich damit auseinandersetzen. Dafür gibt es ja dann die entsprechenden Research-Zeiten. Dann haben wir natürlich noch interne Zirkel. Das eine nennen wir TEA. Das ist Think Tecture Exchange After the Weekend.

irgendwelche Akronyme braucht man ja heutzutage. Das sind dann so knackige 20-Minuten-Talks, meistens zu technischen Themen, aber eben auch zu internen Themen. Das heißt, da können auch die Kolleginnen und Kollegen aus dem nicht-technischen oder aus dem Backoffice-Bereich dann ihre Erfahrungen, ihre Ideen, Pläne und ja, aktuelles

researchtons am besten geben und für etwas längere und etwas technisch detailliertere Sachen haben wir dann noch den T5. Also TT teaches TT, Think Tecture teaches Think Tecture. Noch so ein geiles Akronym, wo man dann halt quasi intern ohne Netz und doppelten Boden, ohne Powerpoint, direkt rein in die IDE, wenn es früher was zu Angular war, zu .NET war, zu Identity, zu Azure.

Dann rein, jetzt sind es halt immer mehr und immer vermehrt irgendwelche Gen.AI-related Themen. Und ansonsten halt einfach ganz viel und ganz oft miteinander sich austauschen. Viele organisieren sich dann auch innerhalb der Projektteams dann quasi über einen Zoom-Call und hängen den ganzen Tag in einem Zoom-Call, obwohl sie eigentlich an unterschiedlichen Teilen von Projektarbeiten, aber

können sich dann so immer sehr sehr schnell und über kurze Strecken dann eben austauschen und dann sprechen über Frontend-Architekturen, über irgendwelche Pattern, wie macht man das dann, das muss offline first funktionieren, ja hier im Backend, da haben sie das in Azure und so. Also das ist auch Teil der Kultur, also jetzt nicht irgendwie im stillen Kämmerlein, im Dunkeln mit der Scheuklappe und der Käppi und ja, so, so, so.

Nee, da kommt man bei uns wirklich weiter.

9 Uhr reinschleichen und 5 Uhr schnell wieder raus. Ja, stilles Kämmerlein, Zoomcalls. Habt ihr eine Remote-First-Kultur? Seid ihr remote? Seid ihr alle vor Ort?

Ja, nee, das ist schwierig.

Also wir sind auf jeden

Fall remote. Ich habe immer ein bisschen Probleme damit zu verstehen oder zu definieren, was Remote First heißt und durch Covid hat sich sowieso nochmal alles geändert. Das müssen wir jetzt hier nicht nochmal warm machen. Aber wir arbeiten meistens aus dem Homeoffice. Wir haben ein Vorortoffice in Karlsruhe, wo wir dann alle fünf Wochen, fünf bis sechs Wochen rum uns

Treffen, ist dann der sogenannte Vorsicht, nächster Akronym, Meet in the office days. Wer dann also kann und Lust hat, kommt dann halt nach Karlsruhe und da sind wir dann zwei, drei Tage dann zusammen, meistens komplett ohne Zwang. Essen dann aber zusammen, gehen abends nochmal irgendwo hin, machen irgendwie Bowling-Events, Darts oder irgendwie was anderes.

Sie hatten sogar mal Escape Room gemacht, da war ich auch gar nicht dabei. Also ja, so Sachen dann halt, wo man sich dann auch ein bisschen mehr wieder wie ein Team fühlt, weil ansonsten sind wir natürlich durch unsere starke persönliche Expertise natürlich auch schon sehr, sehr stark individuell ausgeprägt und geprägt. Haben aber natürlich schon Teams bei den Kunden in den jeweiligen Projekten. Aber wir sitzen, wie gesagt,

die meiste Zeit im Homeoffice oder dann eben ab und zu mal in Karlsruhe oder dann halt wenn es ja wenn es Sinn macht fahren wir dann auch zum Kunden für Workshops, Initial-Workshops, für Meilenstein-Workshops, für Abschluss-Präsentationen oder einfach ⁓ wieder mal sich zu sehen und nicht nur auf der flachen Bildschirmscheibe.

Per Matscheibe.

ich glaube, das ist superschwierig, gerade wenn man viel bei dem Kunden dann auch ist, trotzdem eine Teamkultur aufzubauen und zu erhalten. Aber für mich hört sich das auf jeden Fall sehr, cool an, was ihr so macht und vor allem, euch aufstellt. Ich glaube, das Thema AI habt ihr voll mit eingebaut. Also alle, die jetzt in dem Thema sind und Hilfe suchen, könnt euch gerne an Christian wenden zu dem Stichwort, wo kann man dich...

soll

aber hier nicht zur Werbeveranstaltung werden. Das ist ja nur ein Podcast.

Genau, nur unter uns eigentlich.

und nebenbei... Aber wenn man dich erreichen will zu deiner Expertise oder wie auch immer, wo findet man dich in welchen sozialen Oder wie kann man...

Also am meisten findet

man mich auf Konferenzen. Weil da kann man dann auch direkt mit mir vor dem Talk, während dem Talk nicht so gerne oder nach dem Talk stundenlang auch reden. ich erst letzte Woche, war super super tolles Erlebnis wieder. Ich hatte einen Talk in den Abendstunden, also Abendstunden heißt, der war 18 Uhr fertig und ⁓ 19 Uhr ging dann das offizielle Abentevent los von der

Konferenz, das war perfekt, weil mein Thema war noch super präsent und dann hat man sich ganz super gut mit den Leuten dann unterhalten können. Nachteil war nur, ich kam überhaupt nicht zum Essen, weil halt so viele Fragen und Ideen kamen zu den ganzen GenAI-Themen überdies da ging. Ansonsten versuche ich, einiges auf LinkedIn zu platzieren und auch zu kommentieren, auch wieder mit dem Hashtag No Bullshit und Hashtag Pragmatic Approach Gedanken.

X ist ja heutzutage nichts mehr. Blue Sky ist zwar eine nette Idee, aber funktioniert nicht, weil keiner dort ist und keiner was postet hat. heißt also Social Media dreht sich wahrscheinlich alles rund LinkedIn.

Alles klar. Ich werde auf jeden Fall die Webseite noch, deine E-Mail-Adresse eventuell oder deinen LinkedIn-Kontakt in die Showcodes mit aufnehmen. Christian, eineinhalb Stunden haben wir jetzt geredet.

Gerne, gerne, Natürlich.

Alter, Falter, wer hört sich das an? Das frage ich mich.

Ich hätte nach der Viertelstunde aufgehört oder abgeschaltet. bin gespannt, wie viel ... Siehst du das später in der Statistik, wer wirklich durchhört? ⁓ hohohoho. Huiuiui. Mir hat es Spaß gemacht ohne Ende. Super.

Ja, wir können mal reingucken. Genau. Also ich fand's persönlich sehr spannend. Es hat mir unheimlich viel Spaß gemacht. Die Zeit ist

wie im Flug sozusagen vergangen. Danke vielmals, dass du dir die Zeit genommen hast und an alle anderen danke, dass ihr zugehört habt. Hoffentlich bis zum Schluss. Schreibt vielleicht mal in die Kommentare, wie ihr das fandet und dann bis zum nächsten Mal. Vielen Dank und ciao.

Ja, ja.

Immer gerne, immer gerne.

Danke euch, ciao!