Patrick Steiner: Willkommen zurück beim Databricks Deutschland Podcast. Dem Podcast, in dem wir nicht nur über Daten und KI sprechen, sondern auch über die Menschen, die das Ganze möglich machen. Heute sprechen wir über ein Thema, das die Art und Weise, wie Softwareentwicklung, aber auch Datenpipelines entwickelt werden, gerade fundamental auf den Kopf stellt. Es geht ⁓ WIPECODING. zu verstehen, was hinter diesem Basswirt steckt und wie das Ganze in der Praxis funktioniert, habe ich mir heute Felix Ehler als Gast eingeladen. Herzlich willkommen, Felix. Stell unseren Zuhörern doch mal ganz kurz vor, wer du bist, du kommst und auch ein bisschen was du bei Dead Rakes gerade machst.

Felix: Hi Patrick, danke für die Einladung. Ich freue mich sehr, hier zu sein. Ich bin Felix, bin in unserem Field Engineering Team als Solution Architect tätig. Vor meiner Zeit bei Databricks war ich als Software Entwickler bei einem Automotive Konzern und als IT Consultant bei einer Beratung. Und genau, als Solution Architect, wir helfen eigentlich unseren Kunden bei allen technischen Themen, die man sich so vorstellen kann. Das heißt, ich gebe auch technische Beratungen, wenn es ⁓ Architektur-Themen geht, aber auch Vorbereitungen von Demos, von POCs, also alles, wo wir unsere Kunden unterstützen können im technischen Hinblick. Und genau, schauen wir so ein kleiner Teaser. Also Vibe Coding hat wirklich sehr stark verändert, vor allem die letzten Monate, wie wir hier im Field Engineering arbeiten. Und ja, freue mich gleich ein bisschen mit dir darüber zu sprechen.

Patrick Steiner: jetzt hast du den Begriff direkt auch im Teil deiner Jobbeschreibung oder Tätigkeiten genannt. Dann sag doch bitte so lieb und erklär unseren Zuhörern doch bitte mal, was steckt genau hinter Vibecoding.

Felix: Ja, sehr gerne. wenn man Vibe Coding googelt, dann findet man als erstes einen Tweet von André Carpathy. Ich glaube, er einer der Mitbegründer von OpenAI. Und er hat damals geschrieben, give into the vibes, forget that the code even exists. Und das hat damals, glaube ich, so relativ stark einen Nerv getroffen, weil wirklich Entwickler einen Großteil ihrer Zeit damit verbracht haben, Code zu debuggen. Boilerplate Code zu schreiben, aber nicht so wirklich damit eigentlich wirklich Logik zu bauen und ihr Ziel zu definieren und daran zu arbeiten. Und heute ist es so mit Vibe Coding, dass man wirklich eher beschreibt, was man möchte. Also wie sieht mein Ziel aus? Und die AI schreibt für mich den Code. Das ist erstmal ganz, ganz simpel. Unterschied vielleicht noch ein bisschen zu so Copilot ähnlichen Tools, die man ja auch schon in der Vergangenheit kennenlernen konnte, ist dass es nicht nur autocomplete ist, sondern wirklich ein Agent, den ganzen Kontext versteht, der Dateien liest, der Befehle ausführt. Heißt so ein bisschen, früher war ich mehr der Autor, der quasi den Code geschrieben hat und jetzt entwickelt sich das immer mehr zu einem Regisseur oder zu einem Dirigent, der das Ganze wirklich orchestriert.

Patrick Steiner: Okay, das heißt ich programmiere nicht mehr in einer der verschiedenen Programmiersprachen, sei es nun Python, Java oder irgendwas anderes, sondern ich programmiere in Anführungszeichen quasi auf Deutsch oder Englisch.

Felix: glaube, kann man durchaus so sagen. Also im Endeffekt habe ich mein Interface offen mit dem Agent und ich schreibe erstmal in natürlicher Sprache, also auf Deutsch oder meistens wahrscheinlich auch auf Englisch. Genau. Und das macht das Ganze natürlich erstmal deutlich leichter und auch den Einstieg deutlich einfacher und verschiebt auch den Fokus etwas von... Wie implementiere ich das Ganze? Also ist jetzt mein kleiner Code Teil, habe ich das jetzt richtig programmiert? Mehr zu was genau möchte ich eigentlich erreichen? Was ist mein Ziel? Genau, also als kleines Beispiel wäre ein Prompt, bitte erstelle mir eine Databricks App auf Basis von React, die ich zum Beispiel mit einem User Interface, über die ich Genie aufrufen kann. Vielleicht noch mit einer Voice Functionality dazu, dass ich auch mit Genie sprechen kann. Aber ich würde wirklich nur diesen Prompt beschreiben und der Agent macht dann erst mal alleine weiter.

Patrick Steiner: Okay, klingt erstmal komplett spannend und reduziert auch die Einstiegshürde, glaube ich, ⁓ ins Programmieren reinzukommen. Ich würde gerne auf etwas zurückkommen, das du am Anfang gesagt hast, nämlich dass das Vibe-Coding auch bei dir, bei uns im Field Engineering starken Einzug genommen hat über die letzten Monate. Wie sieht denn das konkret bei dir im Alltag aus? Was genau hat sich verändert?

Felix: Mmh. Ja, also wenn ich an die Zeit zurückdenke, auch noch wirklich vor Agents, aber auch vor LLMs, es ja wirklich sehr viel Code, also sehr viel erst mal Doku lesen, Doku verstehen und ganz viel Stack Overflow googeln. Also damals war, glaube ich, ein Skill, man oder einer der wichtigsten Skills war, dass ich richtig googeln konnte und wusste, wonach ich suchen muss, ⁓ den richtigen Stack Overflow Thread zu finden. ich habe ganz viel Zeit damit verbracht, Boilerplate Code zu schreiben, also wirklich immer das Gleiche, immer in der gleichen Form, ganz viel Copy Paste. Genau, und heute ist es eben wichtiger geworden, dass man richtig prompten kann. Bedeutet, beziehungsweise heute ist es so, dass wir wirklich viel schneller zu funktionierenden Prototypes und auch Demos kommen. Also... Wie gesagt, früher haben wir Tage, vielleicht Wochen damit verbracht, Code zu schreiben, einen Bug zu fixen. Und heute geht es innerhalb von Minuten, vielleicht wenigen Stunden, ⁓ auch eine Demo vorzubereiten für unsere Kunden zum Beispiel. Genau, ein Praxisbeispiel. Ich hatte letzte Woche eine Demo bei unserem Kunden, wo ich Genie Code zeigen wollte. Da können wir später, wenn du möchtest, auch kurz darauf eingehen. Und da wollte ich relativ schnell was was Vyp-Coden, ⁓ denen was zeigen zu können. Und das hat innerhalb von vielleicht einem halben Tag geklappt. Also es geht deutlich, deutlich schneller. Ja, zudem, ich kann Workflows viel besser automatisieren. Also wenn ich sage, das Erstellen meiner Expenses, meine Reisekosten, Abrechnungen, sowas kann ich vereinfachen. Genau, das ist sehr cool. Und Noch als letzter Punkt, was ich die letzten Monate auch viel gesehen habe, wirklich, dass Agents qualitativ viel besser geworden sind, weniger Flüchtigkeitsfehler machen, schneller geworden sind. es hat schon stark verändert die letzten Monate.

Patrick Steiner: Okay, super spannende Beispiele. glaube, auf das automatisieren der internen Workflows gerade für Reisekostenabrechnungen sollten wir beide nochmal offline reden. Würde mich auch interessieren, wie ich mich optimieren kann. Jetzt hast du sehr viel, wie ich immer, Licht oder Sonne beschrieben. Aber wo Licht und Sonne ist, ist auch Schatten. Gibt es auch Dinge, wo das gar nicht funktioniert mit Vibe Coding?

Felix: Ja. Ja, würde jetzt nicht was Pauschal ausschließen. Ich glaube, man muss das Ganze immer mit einer kleinen Skepsis betrachten, beziehungsweise blindes Vertrauen vermeiden. Ich ich triff es besser. Also es ist trotzdem wichtig, wenn ich jetzt durch meinen Agent-Code generieren lasse, dass ich dem Code nicht blind vertraue, dass ich den Code trotzdem revue und wirklich natürlich überprüfe, vor allem bevor man was produktiv setzt, dass man das sehr stark überprüft. wenn die Logik auch bisschen komplexer wird, das ist glaube ich sehr wichtig. Zudem brauche ich natürlich diese technische Basis. Also ich brauche ein gewisses technisches Grundverständnis. Ich muss den Code verstehen können, auch allgemein, welche Tools die Applikation nutzt etc. Und auch immer ein bisschen mit diesem Governance oder Security Aspekt drauf gucken und zu sagen... Beziehungsweise einfach sicherzustellen, dass keine Credentials erstmal an die AI gegeben werden, aber auch natürlich nicht im Code landen, keine Kundendaten sowieso. Das ist natürlich wichtig. Also alles immer mit einer gewissen Review und Governance Sicht betrachten.

Patrick Steiner: Das heißt, gute alte Vier-Augen-Prinzip oder wenn wir mehr den Blick in Agile Software Development kommen, das ist etwas, wo ich mich viele Jahre auch drin bewegt habe, das Pair Programming bleibt bestehendes Pair Programming, nur ist mein Partner jetzt nicht mehr ein anderer Entwickler, sondern im Zweifelsfall ein AI Agent. Kann man das so vereinfacht darstellen?

Felix: Ja, ich glaube, das ist ein sehr gutes Beispiel, Patrick. Ich würde grundsätzlich sagen, der Agent, wie gesagt, unterstützt einen sehr stark in der Entwicklung, aber man selbst muss natürlich einfach nochmal drauf gucken, so ein bisschen der Senior-Dev, der mit den Praktikanten zusammenarbeitet und sicherstellt. dass das Ganze wirklich auch stimmt und bevor es produktiv geht, das alles nochmal überprüft.

Patrick Steiner: deckt sich so ungefähr wie ich mir das auch vorgestellt habe. Vielen Dank dafür. Gut, jetzt kann ich ja das WIPECODING nicht einfach irgendwie auf der Konsole machen, dass ich mein Terminal öffne und einfach drauf los tippe, sondern auch da müssen ja irgendwelche Tools verwendet werden. Kannst du da ein bisschen Beispiel bringen, konkret ⁓ welche Tools verwendest du zum Beispiel für deine WIPECODING Sachen?

Felix: Ja, gerne. Ja, gerne. Grundsätzlich glaube ich, würde ich es in so drei Kategorien unterteilen. Das Wichtigste ist erstmal der Agent. Also da ist das Herzstück des Ganzen, haben wir schon mal kurz erwähnt jetzt. Dann gibt es noch die Skills, so das Wissen, auf das der Agent auch zurückgreift. So quasi das Buch, das er sich rausnehmen kann. Und dann noch MCP. Da ist es die Verbindung zur Außenwelt, ich sagen. Also die Tools, ich zum Beispiel auf gewisse Tools zugreifen möchte. Genau, da gehen wir dann gleich bisschen genauer drauf ein. Erstmal zum Agent. Also der Agent sind Large Language Models wie zum Beispiel Cloud Code oder wie ChatGPT. Und das Ganze ist, oder kann ich CLI-Base nutzen? Also ich kann Cloud im Terminal nutzen, mache ich durchaus auch oft. Aber ich kann auch vor allem, wenn es viel Code generiert, ich möchte sicherstellen, dass die Strukturen alles passt, kann ich das Ganze auch in einer IDE wie Cursor nutzen. genau, der Agent versteht einfach den Kontext, der liest Dateien, schreibt Code für mich, führt meine Befehle aus. Genau, das, glaube ich, ist auch viel in einem Begriff soweit. Dann zu den Skills. Das, wie bereits kurz erwähnt, ist so das Wissen, auf das der Agent zurückgreift. Das heißt, wir haben davor definierte Fähigkeiten, die der Agent aufrufen kann. Und im Endeffekt dient es so ein wie Expertenwissen oder es kapselt dieses Expertenwissen oder Best Practices. Also zum Beispiel jetzt im Databricks Kontext hätte ich dann einen Skill, der besonders genau weiß, wie man Spark-Declarative Pipelines baut. Das heißt, wenn ich dem Agent die Aufgabe geben würde, diese Pipeline zu bauen, dann könnte er dort nachgucken und wüsste, hey, genau das ist die Best Practice, wie ich vorgehen sollte. der Agent entscheidet aber auch selbst, welchen Skill er benutzt. ⁓ ist... Ich kann es dadurch beeinflussen, wie ich diesen Skill aufbaue. Also ihr könnt euch das vorstellen wie ein Markdown-File. Und da ist der Name des Skills drin, eine kurze Beschreibung, aber auch ein Trigger. Also zum Beispiel bei dem FDP-Beispiel wäre dann Spark Declarative Pipelines. Wenn das Wort vorkommt in meinem Prompt, wird der Agent ziemlich sicher auf diesen Skill zurückgreifen. und dann eben das Skill selbst, wo ich ganz genau beschreibe, auf was muss ich alles achten, wenn ich das implementiere. Als letzten Punkt hatten wir noch MCP, das steht für Model Context Protocol. Es wurde von Anthropic eingeführt und ist ein offener Standard, oder über den die Agents Tools, Datenquellen und Funktionen aufrufen können. Ich kann zum Beispiel Slack nutzen, kann Gira nutzen, kann Google Docs nutzen. Also das ist meine Verbindung, wie mein Agent auch für mich ein neues, eine neue Google Slider stellen kann oder ein neues Google Docs Dokument. Und genau, im Endeffekt ist MCP so ein bisschen das USB-C für AI, glaube ich kann man sagen. Also ein Standardstecker für alles und genau. Wie nutze ich das Ganze jetzt konkret, war ja deine Frage, Patrick. erst mal lokal nutze ich einfach Cloud Code bzw. Cursor. Und wir haben aber auch von Databricks Seite zwei Produkte, die ich aktuell sehr viel nutze oder zwei Features. Das eine ist Open Source und das andere ist auch bereits in einem Databricks Workspace verfügbar und zwar Genie Code. Das haben wir vor kurzem erst mal veröffentlicht und Genie Code ist so der Coding-Agent von Databricks. Genau, ist kostenlos in jedem Workspace verfügbar und der wählt auch immer das beste Modell nach Aufgabe. hatte anfangs schon mal kurz erwähnt, dass ich für letzte Woche eine Kundendemo vorbereitet hatte und dafür habe ich zum Beispiel sehr intensiv Genie Code genutzt. Genau, das Coole ist, ich muss nichts installieren, das läuft alles schon auf einem Databricks-Environment und wenn ich meinen Databricks Workspace öffne, finde ich oben einfach diesen Genie Code Icon. Wenn ich drauf klicke, kann ich schon mal einen Prompt eingeben und sagen, hey, bitte bau mir aus diesen beiden Tabellen eine neue Tabelle, wo die Average Werte berechnet werden, gruppiert nach irgendeinem gewissen Wert. Und genau, ich finde es besonders deswegen sehr hilfreich, weil ich auch eigene Skills hinzugeben kann. Ich kann MCP Server hinzugeben. Und ja, also es ist wirklich für mich sehr hilfreich. Ich nutze es viel im Alltag und ich glaube auch für unsere Kunden, zuhören, ist es besonders hilfreich für Data Engineers, aber auch für Data Analysts oder jeder, der eben ein bisschen Vibe coden möchte, der noch nicht so wahnsinnig viel Coding Experience hat, aber einfach mal bisschen rumprobieren möchte. Da ist Genie Code sehr gut dafür. Das zweite Tool, das ich sehr viel nutze, ⁓ Vibe zu coden, ist das Databricks AI Dev Kit. Das ist ein Plugin, das kann ich auch auf Genie Code nutzen oder mit Genie Code installieren. ist speziell für die Plattform beziehungsweise für Agents gedacht, zum Beispiel SQL zu schreiben, auch Dashboards zu bauen, Jobs zu bauen. Also quasi alles, jede Databricks Functionality kann eine iDevKit unterstützen. genau, finde ich auf jeden Fall sehr hilfreich. Und mit AI Dev Kit und Genie Code habe ich eben letzte Woche eine Demo gebaut. Für die hätte ich normalerweise, ich weiß nicht, ein, zwei Wochen gebraucht. Und ich glaube, ich habe das auf einem Nachmittag, ja, gevibe-coded.

Patrick Steiner: hat es vorhin kurz, glaube ich, angesprochen, wenn ich das richtig mitgekriegt hatte, dann weiß ich es teilweise natürlich ja auch, dass Databricks AI Dev Kit ist ⁓ Source, während Gini Code einfach Teil des Produktes ist, so wie ein Kunde das bekommt. Jetzt ich ja seit vielen Jahren Open Source Fanatiker, darum lass uns da mal vielleicht noch ein bisschen tiefer reinschauen.

Felix: Ja.

Patrick Steiner: genau kann ich alles mit diesem Open Source AI Dev Kit machen?

Felix: Ja, das AI Dev Kit ist, also erstmal gesagt, das ist Open Source, also auch für jeden von euch, den es interessiert. Patrick, ich glaube, du kannst das wahrscheinlich in die Show Notes packen, das Repo. guckt euch das schon mal gerne an. haben aktuell, ich glaube, ich habe gestern geguckt, ca. 1000 GitHub Stars. Das finde ich schon mal sehr gut.

Patrick Steiner: Kann ich gerne eine Idee haben.

Felix: Genau, was macht es? Es ist eigentlich kein eigenes Tool, sondern mehr ein Plugin, das bestehende AI-Agents unterstützt, wirklich Databricks-Intelligen zu machen, ich es nennen. bedeutet, wenn ich jetzt kein AR Dev Kit nutze, sondern einfach mir von Cloud Databricks Code erstellen lasse, dann nutzt Cloud ⁓ welche Agent noch immer ich nutze, sehr veraltetes Internetwissen. nicht die aktuellsten Databricks Skills, Databricks Docs. Und mit dem AI Dev Kit würde er eben kuratierte und die aktuellen Patterns nutzen, die wir oder auch ihr, also die Open Source Community, gebaut haben. Also zum Beispiel, was ist der korrekte Weg, Dashboard zu bauen? Wie genau sollte ich meine Pipelines konfigurieren? Was sind Unity Catalog Best Practices? Das ist dort alles aufgeschrieben. Genau. Also ich glaube, kann man so ein bisschen auch noch mal auf die Analogie von vorhin zu sprechen zu kommen, aber ich habe einen Praktikanten, der das Ganze googelt oder ich habe einen Senior Engineer, der wirklich die Plattform kennt und AI Dev Kit ist wirklich dieser Senior Dev, der sehr detailliert Bescheid weiß, was die Best Practices sind.

Patrick Steiner: Okay, ist also dann mit auch eine sehr gute Hilfestellung für Leute, die neu mit Databricks sich beschäftigen und ihre ersten Aufgaben innerhalb von Databricks machen wollen.

Felix: Christus! Richtig, Dadurch, das AI Dev Kit wirklich über alles Bescheid weiß, also wie kann ich Queries ausführen, auch wie kann ich eine neue Databricks App bauen, was wir auch bei vielen Kunden gerade sehen, ist es da sehr, hilfreich. Die AI kennt best practices und ist so ein bisschen wie der erfahrene Kollege, der neben einem sitzt und einem da unterstützt. Genau. Wir haben auch Guardrails verankert, um bisschen sicherzustellen, dass natürlich sag mal, kostenkritisch gebaut wird und genau, also es ist natürlich trotzdem wichtig, wenn ich diese Tools nutze, wie schon vorhin erwähnt, dass man ein gewisses Verständnis selbst aufbaut, dass ich selber auch einen kritischen Blick durchaus mal drauf werfe, aber es ist einfach ⁓ Lernbeschleuniger, der wirklich unterstützt, schneller in diese Themen reinzukommen. Genau. Vielleicht noch kurz ⁓ das zu erwähnen, Patrick, was ich cool finde in diesem ganzen Community Approach ist, wie Community Driven das Ganze ist. Also sowohl wir im Field Engineering bauen neue Skills und können die in dem repo veröffentlichen, dazu beitagen, aber auch unsere Kunden können das Ganze machen oder jeder, der sich daran beteiligen möchte. Genau, das bedeutet, wenn ich jetzt neuen Skill entwickle, dann stelle ich den einfach im repo öffentlich und kann ihn nutzen und das finde ich schon ziemlich cool, dass wir uns da gegenseitig alle supporten und das in diesen Open Source Suspect auch weiter pushen können.

Patrick Steiner: Grenze bei mir, wie gesagt, als alter Open Sourceler die offenen Türen nur ein. Speed und Innovationskraft von Open Source ist glaube ich unbestritten im Markt.

Felix: Ja. Ja, stimm ich dir zu.

Patrick Steiner: Okay, super, vielen Dank für die Erklärung und den Deep Dive in das AI Dev Kit. Sollte sich wirklich jeder angucken, genauso wie natürlich auch Genie Code.

Felix: Patrick. Jetzt habe ich ja schon sehr viel geredet in unserem ersten Teil. Und unsere Zurekon schon viel erfahren, wie wir im Field Engineering, wie ich als Solution Architect das Ganze nutze. Du als Manager kommst ja auch nicht ganz am AI-Thema vorbei. Vielleicht magst du mal ein bisschen erzählen, wie ist es so bei dir, wie hat AI so deinen Manager-Alltag auch verändert?

Patrick Steiner: Frage und vielen Dank, dass du sie gestellt hast und danke, dass du mich hier auf den Spot setzt und einfach den Spieß muss ich dazu einleitend sagen, für die, die mich nicht kennen und das werden wahrscheinlich 99 Prozent der Zuhörer sein, ich komme ursprünglich gar nicht aus dem Data-Umfeld, so wie du oder viele andere bei Databricks, sondern ich komme aus der Software-Entwicklung. habe klassisch Softwareentwicklung gemacht, auch viele Jahre. Und als erstes muss ich sagen, auch für mich ist dieses Thema Bytecoding eine Revolution. Auch im privaten Umfeld. Ich habe in meinem Leben keine Mobile App gebaut, wollte eine haben für meine privaten sportlichen Aktivitäten, die ich mache und habe innerhalb von einem Abend von null auf testen verfügbar auf Flutter Basis eine Multi-Page-Mobile-App mit lokaler Datenhaltung gebaut, die dann auf iOS und Android genutzt werden kann. Innerhalb von einem Abend während parallel meine Frau Fernsehe geguckt hat. Das war für mich unglaubliches Erlebnis, aber auch bisschen erschreckend. muss man ganz klar sagen, weil es revolutioniert, wie wir am Anfang gesagt haben, die Art und Weise, wie Softwareentwicklung betrieben wird. Kommen wir zu deiner eigentlichen Frage. Ja, auch als Führungskraft innerhalb von Databricks. kann ich nicht nur AI-Tools nutzen, sondern wir werden wirklich aktiv auch von unseren Gründern, da ist Arsalan ganz stark auch hinter motiviert, AI-Tools zu nutzen, ⁓ unsere Produktivität zu steigern. Und das geht tatsächlich mit Vibe-Coding-Dingen los. Weil ich halt aus der Anwendungsentwicklung komme, habe ich über die letzten anderthalb Jahre mir ein Spreadsheet gebaut mit Makros und allem Möglichen, mein Business für mich besser managen zu können, weil ich der Meinung war, so viel ich die Daten auch visuell dargestellt haben möchte, bin ich mit meiner Expertise einfach schneller, Skripte zu bauen, das zu machen. Dieses Skript habe ich innerhalb von einem Nachmittag per WIPECODING über genau die Tools, die du auch genannt hast, jetzt als Databricks App laufen. Und das ist für mich unwahrscheinlicher Produktivitätssteigerung, weil ich einfach mich nicht mehr ⁓ irgendwelche Makros kümmern muss, sondern es läuft alles. Aber auch, das ist jetzt weniger mit WIPECODING, sondern mehr mit Agents. Wobei ich glaube, da kann man, das ist ja wahrscheinlich Vibe Coding, wenn ich einem Agent in natürlich sprachlicher Form sage, was für Skills oder Routinen ich haben möchte, die er für mich dann regelmäßig auszuführen hat, dann programmiere ich ja auch nicht, sondern ich rede natürlich sprachlich mit meinem Agent und er baut dann die Skills, die du davon erklärt hast und legt sie ab. Da kann ich aus der jüngsten Vergangenheit zum Beispiel erzählen. Wir sind ja Teil einer Vertriebsorganisation, das heißt auch ich habe regelmäßig Reviews, wo ich vor meinem Manager und den Sales-Leadern erklären muss, wo steht mein Book of Business, steht das Territory und statt mich durch verschiedene Informationen zu graben, verschiedene Daten und Zahlen zusammenzutragen und sie dann auch noch visuell aufzubereiten, habe ich mir dafür ein Skill geschrieben. Oder was geschrieben? Gevibe. Und den konnte ich dann halt auch beliebig oft laufen lassen. Und wenn ich gesehen habe, der Output gefällt mir nicht. Das ist ja das Faszinierende. Dann macht man einfach einen Screenshot, gibt das dem Agent und sagt B möchte ich aber nicht da haben, sondern ich möchte lieber zwei Spalten weiter rechts und bitte ende auch die Formatierung und mache mir ein Color Coding nach folgenden Regeln. Und dann läuft der Agent wieder und die nächste Iteration des Dokuments hat dann genau das, was sie haben soll. Also das ist tatsächlich so mehr die Richtung, in der ich das AI-Tools und auch Vibe Coding in meinem täglichen Alltag verwende. Das schöne ist, wenn man ja sowas baut wie so ein Agent, ich habe den für mich gemacht zusammen mit meinem Sales Counterpart, mit dem ich zusammen das aktuelle Review hatte. Aber die Fragen, die dahinter stehen, sind ja grundlegend gleich auch für andere Kollegen. Und dann habe ich dann halt den Agent nochmal laufen lassen und gesagt, und jetzt macht das bitte nicht für meine Kunden, sondern macht das für die Kunden des Kollegen. Und dann hat er seine Zahlen aufbereitet bekommen. Und ich glaube, das kann man an Zeit ersparen, kaum noch bewerten, was da der positive Effekt ist.

Felix: Sehr spannend, Patrick. Und wie lange würdest du, wenn du es einschätzen müsstest, sagen, dass es gedauert hat, diesen Skill zu bauen und auch ein bisschen zu iterieren?

Patrick Steiner: glaube jetzt muss man tatsächlich zwischen der Brutto- und Nettozeit unterscheiden. Ich glaube meine Interaktion mit dem Agent Nehmen wir mal das Beispiel des Bauen der Vibe-gecodeten App, die dann mein Dashboard, meine Databricks App für mich so gebaut hat, wie ich sie gerne habe, wird nicht länger als eine halbe Stunde bis dreiviertel Stunde gewesen sein. Was dann aber natürlich bisschen länger dauert, ist der Agent, der dann im Hintergrund erst los rennt, weil ich hab ihm ja noch nicht mal gesagt, wo die Daten liegen, die er... heranziehen soll, sondern ich habe das einfach den Skills überlassen, auch selber die Daten zu identifizieren und rauszufinden, wo sind die. Und auch da, wenn er mir zum Beispiel eine falsche Zahl genannt hat, ich aber wusste, wie die richtige Zahl sein soll, habe ich ihm einfach als Feedback gegeben, ne, das ist nicht 350, sondern 327. Dann ist er selber losgerannt und hat festgestellt, wo kriege ich die 327 her und kann das so, ah ja, jetzt sehe ich meinen Fehler. Ich ändere meine Kalkulation um. Das hat ein bisschen länger gedauert. Also darum glaube ich, die Bruttozeit, die wird schon auch für die App vielleicht um die drei, vier Stunden gewesen sein. Aber dadurch, dass die Nettozeit von mir so kurz war, lief das parallel zu anderen Tätigkeiten. Darum

Felix: Okay, ja.

Patrick Steiner: kann man eigentlich sagen, hat gar keine Zeit gekostet.

Felix: Ja, das ist schon Wahnsinn. Genau wie du gesagt hast, sehe das auch bei uns in Field Engineering. Wir haben schon eine sehr große Zeit ersparnis, die man auch wirklich wieder für andere Themen nutzen kann. Noch besser wird es, wenn man da nicht nur einen Agent, sondern mehrere Agents laufen lässt und orchestriert. Also da gibt es wirklich sehr, sehr viel Potenzial, dass man ja rausholen kann.

Patrick Steiner: Ja, absolut. Jetzt dreh ich den Spieß wieder zurück ⁓ Felix, weil was ich von dir gerne hätte, ist so ein bisschen auch noch ne Einschätzung oder ein Ausblick nach deiner persönlichen Meinung, weil ich glaub die Wahrheit kennt keiner jetzt, aber aus deiner Expertise und persönlichen Meinung, wo geht die Reise hin?

Felix: Ja. Mmh. Ja, ist eine gute Frage und die Frage stelle ich mir und auch jeder meiner Kolleginnen und Kollegen, ich wahrscheinlich täglich. Meine persönliche Vermutung ist erst mal kurzfristig sehen wir auf jeden Fall noch eine tiefere Integration von immer mehr Agents in unseren Alltag. Wir das bei Databricks schon sehr stark. Ich glaube, werden das allgemein in Deutschland, aber auch weltweit natürlich mehr sehen. werden mehr autonome Agents haben. ⁓ werden mehr Vibe-Coded-Applikationen haben. Also einfach wirklich auch so fast Prototyping mit Vibe-Coding, das wird immer noch viel, viel stärker kommen. Ich glaube, mittelfristig wird es noch viel mehr AI in den IDEs, in unseren Pipelines, also die ICD Pipelines etc. geben. Und werden auch wirklich Leute, die in der Vergangenheit nicht entwickelt haben, werden auch produktivere Entwickler werden. Also ich werde nicht mehr die Coding Experience brauchen oder wirklich die Coding Skills, ⁓ Applikationen zu bauen. Und langfristig denke ich einfach, beziehungsweise sowohl von jetzt schon bis auch wirklich im langfristigen Horizont, wir sehen die Rolle des Entwicklers, dass die sich verändert. Also bis hinweg von diesem klassischen Entwickler, der boilerplate-coach schreibt, vielmehr zum Architect, zum Orchestrator, der das Ganze orchestriert. Ich glaube, wichtig zu erwähnen ist trotzdem, und das ist jetzt meine persönliche Meinung, niemand ersetzt oder man ersetzt keine Entwickler, man macht sie einfach effektiver. Wichtig ist natürlich trotzdem, dass man gewollt ist, sich weiterzuentwickeln. Also dass man sich diesen neuen Technologien annimmt, sich dem ganzen hingibt ⁓ auch die Motivation hat sich da reinzulesen und reinzuarbeiten.

Patrick Steiner: absolut auch mein Bild und vielleicht noch als kleine Anekdote am Rande, weil du sagst, dass es sehr stark für Entwickler einen Einfluss hat. meiner vielen Hobbys ist unter anderem auch 3D-Druck, zum Teil auch für praktische Dinge und tatsächlich war gestern Abend so eine Situation, wo ich einen Adapter für etwas brauchte, wo ich ein viereckiges Objekt an ein rundes Objekt anbinden wollte. Der klassische Weg, den ich immer gegangen wäre, ich mache mein CAD Tool meiner Wahl auf, mache eine CAD Zeichnung und schaue dabei 10 YouTube Videos. wie das geht. Gerade so einen Übergang zu machen in der CAD-Zeichnung von viereckig auf rund. Als ich gestern das Tool nach längerer Zeit wieder gestartet habe, was erschien da auf der Bildschirmseite am Rand, hier ist Ihr AI Agent. Bitte prompten Sie Ihre Aufgabe. Dann habe ich tatsächlich das Beschrieben gesagt. Ich brauche ein Objekt, das unten quadratisch ist mit folgender Kantenlänge. So viel Zentimeter über dem Quadrat soll ein Kreis sein mit dem Radius. Die beiden Objekte sollen durch Wände von zwei Millimeter Stärke verbunden sein, in der Mitte alles hohl. Das für mich konstruiert. Also tatsächlich findet dieses Vibe Coding oder die Methodologie, die dahinter steckt, ich glaube, die wird in immer mehr Bereichen ihren Einfluss finden. Daher... Vielleicht eine meiner abschließenden Fragen an dich. Was würdest du jemandem raten? Wie soll man damit anfangen? Wie soll man es ausprobieren? Wo den Start finden?

Felix: Ja, ich glaube an den Punkt war jeder einmal der bereits Revive code und in Zukunft werden auch viele Leute da noch hinkommen. Also gute Frage von dir, Patrick. Ich würde wirklich euch einraten, probiert einfach aus, startet einfach erst mal vielleicht mit einem kleinen Projekt, ein kleines Skript, kleine Automatisierung, ein Agent, der meine E-Mails sortiert, irgendwie sowas in die Richtung. Und das, glaube ich, hilft wirklich, ⁓ da mehr reinzukommen und auch zu sehen, wie wahnsinnig unterstützend und wahnsinnig wertschaffend das ganze sein kann. was für mich persönlich sehr hilfreich war, du hattest ja vorhin jetzt auch schon mal kurz YouTube erwähnt, Patrick, sind schon auch soziale Netzwerke, also YouTube, Reddit, wo ich viele, viele Videos und Tutorials darüber finde. Genau, also mein Rat an euch wäre wirklich, probiert es einfach aus und ja, dann guckt mal was rauskommt.

Patrick Steiner: Super, vielen vielen Dank Felix. Ich glaube wir können zusammenfassend sagen, Vibe Coding ist ein kurzlebiger Hype. Es ist ein fundamentaler Wandel, die Arbeit, die wir jeden Tag machen, mal bisschen mal radikaler verändern wird. nochmal Felix, vielen Dank für diesen Deep Dive in auch deinen persönlichen Werkzeugkasten und deinen Alltag im ⁓ Engineering. Vielen Dank an unsere Zuhörer, dass ihr so lange durchgehalten und uns treu geblieben seid und alles was mir zu sagen bleibt am Schluss ist gute Daten.

Felix: Entscheidungen.

Patrick Steiner: In diesem Sinne, bis zum nächsten Mal.