# AI-Driven Engineering: Scaling Productivity and Operational Excellence

**Podcast:** HMZE
**Published:** 2026-03-27

## Transcript

Ich glaube, man vergisst dann immer retrospektiv, wie zäh das dann halt irgendwie immer war.
Das glaubt, ich habe noch bestimmt eine Woche damit zu tun.
Männer schnupfen halt.
Das herzlich willkommen zur achten Folge unserer neuen Staffel von HMZE Beyond Vibecoding, der Podcast, in dem wir den fundamentalen Change in der Softwareentwicklung begleiten.
Ich bin Sebastian Heidemeyer zur Erben, CTO bei North.io.
Und ich bin André Neubauer, CTPO bei Trusted Shops.
Schön, dass ihr wieder da seid.
Unser heutiger Gast ist wieder ein ehemaliger Kollege, diesmal von dir, Sebastian.
Und der ist aktuell Engineering Manager bei Mapbox, einer US Tech Company.
Genau, und damit ist es wieder ein Perspektivwechsel, weil, wie man sich vorstellen kann, so eine moderne US Tech-Company durchaus sehr, ich sag mal, II-Emracing ist.
Und da tatsächlich ganz spannende Themen hochkommen.
Also wir sprechen über Tooling für Engineering Manager.
Spoiler, der EM-Agent oder Co-Pilot ist real.
Eines der neuen Bottlenecks, nämlich Code Reviews und wie Mapbox damit umgeht, beziehungsweise was Mapbox da gerade für Erfahrung macht.
Und Operational Excellence bei einer Firma, die das Thema wirklich atmet.
Freut euch drauf.
Super spannende Folge.
Viel Spaß beim Hören.
Herzlich willkommen, Uli, bei der achten Episode inzwischen, glaube ich, von unserem HMZE Beyond Vibecoding Podcast.
Ich glaube, das ist insgesamt die 55.
HMZE-Episode.
Interessiert eigentlich keine Sachen, egal.
Herzlich willkommen, Uli.
Schön, dass du da bist.
Und oh, das sagt André normalerweise.
Naja, diesmal habe ich es dir geklaut, dein Trademark-Spruch, André, ich hoffe, es ist okay.
Absolute Ordnung.
Genau, am Anfang bitten wir unsere Gäste, sich immer kurz vorzustellen.
Ja, möchtest du unseren Zuhörern einmal kurz erzählen, wer du so bist, was du gemacht hast.
Ja, gern.
Mein Name ist Uli, ich bin Engineering Manager.
Ich bin aktuell bei Mapbox.
Vorher mit Sebastian schon zusammengearbeitet, bei einem kleinen Berliner Startup in der Mobilitätsbranche Door to Door.
Später haben wir bei Tonis zusammengearbeitet.
Genau.
Und jetzt bin ich aktuell bei Mapbox.
Amerikanisch Startup, sagen sie immer noch, obwohl es 900 Mitarbeiter hat.
Genau, bin da Engineering Manager für zwei Teams.
Mein Hauptfokus ist im Routing.
Wir bilden, wir bauen die Directions API.
Das ist mein Team verantwortlich, um den Graph zu bauen.
Wir nehmen die rohen Daten und bauen darauf den Graphen.
Und ja, integrieren auch die Echtzeitdaten in den Graphen und machen das, stellen es dann weiteren Teams zur Verfügung.
Das ist im Groben meine Aufgabe.
Ja, cool.
Für alle, die Mapbox nicht kennen.
Mapbox ist im Prinzip, wenn ich es richtig, oder korrigiere mich, wenn ich es zu einfach ausdrücke, aber wenn man nicht Google Maps nehmen möchte, für alle möglichen Maps-Bedarfe, dann nimmt man halt Mapbox.
Also im Prinzip.
Im Wesentlichen, ja, die erkennen auch.
Als ich auf die Webseite geschaut habe, hat sich es angeführt wie on Starroids.
Das wirkt schon nochmal wie eine bessere Version als Google Maps, um euch da mal auch auf den Thron zu heben.
Das war schon sehr, sehr, sehr, sehr beeindruckend.
Also das wirkt so ein bisschen wie so eine, da wirkt Google Maps wie so eine 1-0 dagegen.
Ja, ich glaube, der Hauptunterschied ist, unsere Hauptkunden sind Entwickler.
Wir wollen Leute ermöglichen, ihre bedruckte Produkte zu verbessern mit allem, was Karten sind.
Also es suche dann die visuelle Karte und dann Directions.
Und Google bietet das auch an, aber nicht zu dem Extent.
Also man kann es nicht so weit customisen wie bei uns.
Ja, super cool.
Und genau, also Uli hat auch einen Hintergrund in Geo-Sachen, sag ich mal.
Also wir haben auch bei Dotodor, aber auch in dem Bereich zusammengearbeitet und ja, von daher, ich glaube, perfect Match.
Genau, ja.
Ich habe Geoinformatik studiert und habe eigentlich mein ganzes Leben was mit Koordinaten zu tun gehabt.
Denn Karte involviert, das ist interessant für mich.
Ja, deswegen passt es perfekt.
Ja, wir steigen ja immer ein, so ein bisschen mit dem Status Quo mit dem Text-Stack unserer Gäste.
Ja, magst du dazu ein bisschen was erzählen?
Tech-Stack, ja.
Also für AI mein wichtigstes Tool.
Ich kann eigentlich nicht mehr ohne, ist Cloud Desktop-App.
Das ist für mich.
Unterscheide ich mich, glaube ich, auch von den Entwicklern.
Die Entwicklern bei uns ist Cloud Code, das wichtigste Tool.
Die können nicht mehr ohne.
Für mich ist es die Cloud Desktop-App.
Ist eigentlich mein wichtigster Partner geworden.
Mein wichtigster Mitarbeiter.
Ich nutze es immer für alle Zwecke.
Diese Abhängigkeit, die haben wir auch schon mehrfach diskutiert.
Das ist natürlich ein neuer, sagen wir mal, ich meine, wir sind ja abhängig von vielem, ne?
Aber es ist ein neuer, eine neue Dimension, die man auch einfach im Hinterkopf haben muss.
Ist eine neue Dimension, ja.
Und ich habe den Eindruck, Firmen wie GitHub und AWS stehen da aktuell besser da.
Also deren OPEX-Culture ist stabiler.
Wenn man mal auf die Cloud-Status-Webseite geht, da ist sehr viel rot.
Also man merkt einfach bei Anthropic ist da noch sehr viel in der Entwicklung und die sind noch nicht da, glaube ich, wo sie gern sein möchten.
Und das merken wir natürlich auch, wenn irgendwas schief geht.
Geht es bei uns auch nicht mehr weiter.
Absolut.
Ja.
Kannst du noch ein bisschen was dazu erzählen, wie du die Cloud Desktop App genau nutzt?
Die habe ich tatsächlich noch nie selber benutzt, weswegen super spannend.
Genau, das ist ein anderes Produkt von Anthropic als Cloud Code.
Also es ist nochmal eine extra Lizenz, aber ist im wesentlich das gleiche.
Das ist eine Desktop-App.
Ich nutze es eigentlich wirklich für alles.
Also jetzt, wir hatten Performance Review Cycle.
Ich habe alle Performance Reviews mit dieser App geschrieben.
Also ich gebe den, es hat mittlerweile Zugang zu Google Docs.
Also ich kann das One-on-One-Dokument reingeben.
Es hat Zugang zu Slack.
Ich kann sagen, ey, schau, was habe ich mit der Person auf Slack kommuniziert?
Und dann gebe ich Ihnen noch den Prompt, ey, ich möchte Situation, Behavior, Impact Feedback haben und ich kriege das Feedback.
Und es ist verdammt gut.
Also ich im Vergleich, was ich früher an Performance Reviews und Zeit investiert habe und wie ich das jetzt mit Claude schreiben kann, die Qualität ist so viel besser und ich spare wahnsinnig viel Zeit.
Ansonsten nutze ich es einfach immer wieder, um Kontext zu kriegen.
Also ich werde den ganzen Tag, die Firma ist wahnsinnig schnell, wahnsinnig viel Bewegung in verschiedene Themen reingezogen.
Wo mir gerade am Anfang, als ich angefangen habe bei Mapbox Kontext gefehlt hat, Wissen gefehlt habe und da war Claude unglaublich hilfreich.
Also es kann von so vielen Schnittstellen Informationen holen, um mir ein Brief geben.
Also in fast jedes Meeting gehe ich kurz vorher versuche ich in Claude nochmal reinzugehen, gib mir den Brief, um mich kurz abzuholen, was der aktuelle Stand auf Slack, was der aktuelle Stand in den Google Docs und dann lasse ich mich kurz einfach vorher informieren.
Genau, ja.
Ansonsten nutze ich es auch einfach für mich, um als EM zu wachsen.
Also ich bei uns werden fast alle Meetings mit Gemini transcribed mittlerweile.
Und die Meetings, die ich interessant finde, die gebe ich dann nochmal Claude und sage explizit, hey, du weißt, ich bin EM, gib mir Feedback.
Ich habe das jetzt aktuell sehr viele Interviews und da gebe ich einfach nochmal die Interview-Transcripts rein und sage mir, okay, wo war ich schwach als Interviewer?
Gib mir da Feedback und das ist super hilfreich, um zu wachsen, um Feedback zu kriegen.
Das ist fantastisch.
Genau, super cool.
Sorry, André.
Darf ich, darf ich eine, ich bin mir gar nicht sicher, ob ich das gar nicht brechen, aber mich würde eine Sache mal interessieren, Uli.
Ist das deine erste US-Company?
Das ist tatsächlich die erste US-Company, ist richtig, ja.
Aber du hast, äh, naja, wahrscheinlich Dort wüsste ich gar nicht, ob das, wie, wie, wie amerikanisch oder wie europäisch das geprägt ist, aber du kennst wahrscheinlich ja auch dann, also ohne zu sagen, dass Tonis jetzt ein typisch deutsches Unternehmen ist, aber du kennst ja auch dann wahrscheinlich dir so ein bisschen das Kontrastprogramm.
Würdest du sagen, dass, also oder wie würdest du nur einschätzen, wie so ein amerikanisches Unternehmen mit diesen ganzen AI-Themen umgeht im Vergleich zu, sag mal, eher was Europäischem, eher was Deutschem.
Merkst du da irgendwie einen kulturellen Shift, mehr Risikoappetit, mehr, wir nutzen das, weniger Angst, mehr Angst, wie würdest du das einschalten?
Bloß weiß gerade, weil mir wird das gerade so klar und du sprichst da auch so locker drüber, ja, Claude, Desktop machen wir.
Ich kenne auch genug Firmen, die jetzt sagen, Security Assessment müssen wir erstmal gucken, keine Ahnung.
Wie führt es sich das für dich an?
Ja, es ist, also ich bin bei Tonis rausgegangen, da war Copilot das Beste der Dinge.
ChatGPT kam gerade so auf, aber wirklich in der Arbeit genutzt haben wir das noch nicht.
Kam dann bei Mapbox hinzu und da waren einzelne Tools, die waren freigeschaltet.
Da war es aber noch freigeschalten.
Das dürft ihr nutzen.
Das ging so eine Weile und man hat sich so Wege drumherum gebaut, dass sowas freigeschalten ist, maximal zu nutzen.
Und dann hat es aber in dem letzten halben Jahr wirklich einen starken Schiff gegeben, wo ganz klar die Ansage ist, er nutzt alles, was geht.
Wenn Tool nicht freigeschalten wird innerhalb von 24 Stunden, dann braucht es eine ganz klare Begründung.
Man kann zu Leadership gehen, escalaten, wenn du nicht Zugang zu einem Tool kriegst.
Die Erwartung ist, wir sollen AI zu maximal nutzen.
Bei uns, der letzte Schritt, der jetzt noch gegangen wurde, Mapbox hat einen sehr intensiven Interviewprozess.
Es sind im Wesentlichen vier große Interviews, du die durch musst.
Die sind sehr strukturiert, sehr klar, aber sehr aufwendig.
Zu den vier Schritten kam jetzt ein fünfter hinzu, bis ein AI-Interview.
Also wir schauen explizit bei Kandidaten, wie stehen die zu AI.
Also erstmal sind die offen dafür und welche Erfahrung die haben.
Also die Erwartung ist an alle AI maximal zu nutzen.
Und ja, es ist eine sehr hohe Erwartung, dass man das Maximum mit AI rausholt.
Und wer das nicht will, der ist eigentlich bei Mapbox mittlerweile falsch.
Also die Leute, die noch kritisch sind, oh, in Production Code will ich keine AI nutzen, diese Stimmen hört man ja immer wieder.
Da ist keine Offenheit mehr.
Also, das ist die Frage ist groß, wie gehen wir damit um, aber die Erwartung ist, dass es maximal nutzt.
Ja, ich kann jetzt nicht die Comparison zu Deutschland sagen, da weiß ich gerade nicht, wie andere Firmen aufgestellt sind, aber es ist ein ganz klarer Push von Leadership.
Nutzt AI maximal.
Danke dir.
Danke dir.
Da kommen wir vielleicht gleich im weiteren Verlauf auch noch dazu, wie sich das bisher auswirkt.
Denn also das hat ja verschiedene Folgen.
Ich glaube, oder vielleicht erstmal ein wichtiger Input für eine amerikanische Firma ist natürlich, dass die ganzen Anbieter, die man so landläufig nutzt, amerikanische sind.
Das heißt also, Security, GDPR, geopolitisch, geopolitische Fragestellungen sind einfach anders für amerikanische Firmen.
Aber dann glaube ich auch, dass die Kultur auch eine etwas andere ist.
Und das zusammen erzeugt natürlich gerade einen massiven Pull in diese Richtung.
Genau.
Und dann spannend, wie sich das tatsächlich auswirkt.
Aber bevor wir dahin kommen, würde ich gerne nochmal weiter auf das Thema, wie du arbeitest und den Textteck kommen.
Du hast ja gesagt, dass die Cloud Desktop-App für dich eigentlich mehr oder weniger jetzt deine Schnittstelle ist für alles Mögliche.
Das heißt also, dass Slack, Google Docs wahrscheinlich auch, ich weiß nicht, nutzt dir Notion oder irgendeine Knowledge Base.
Eine Confluence und Tira.
Und für Integration ist eben auch da.
Das ist mein Go-To-Ort, um.
Ja, ich brauche eigentlich weniger zu den einzelnen Tools zu gehen.
Ich kann alles von Claude machen.
Cloud ist so weit, dass, und das habe ich jetzt auch ein paar Mal gemacht, dass ich Claude schreibt in meinen Namenslack-Nachrichten.
Man kann es vorher nochmal überprüfen und kann überlegen, ob man das machen will, aber ja, ich finde es faszinierend, die App.
Ja, es ist, ich bin noch ein bisschen begrenzt, weil eben noch nicht alles freigeschalten ist.
Also ich habe keinen Zugang zu GitHub über Cloud.
Das ist noch eine Riesendimittierung.
Weil das ist nochmal was.
Man weiß, was in Cheerra passiert.
Das ist so die halbe Wahrheit, wo ein Projekt steht.
Slack ist wahrscheinlich ein bisschen mehr Wahrheit, wo ein Projekt steht als Tira.
Die eigentliche Wahrheit ist im Source Code.
Und der Zugang, den muss ich dann immer noch über die Krücke über Cloud Code gehen.
Also ich muss den Code polen, dann Cloud Code aufmachen, wo stehen wir da?
Also Mapbox, meiner Stelle ist schon sehr viel Reporting, was ich machen muss.
Und also schriftlich Reporting und da ist AI eine wahnsinnige Hilfe.
Also schnell Texte schreiben.
Genau.
Und wie kriege ich den Input?
Ist eben über Slack, Tira GitHub und über den Source Code.
Und da nutze ich dann Cloud Code zusätzlich noch.
Also ich gehe zu Cloud Code, er gebe mir den aktuellen Stand und den kopiere ich dann rüber zu Cloud Desktop-App, um meine Artefacts rauszukriegen.
Ich muss dann nochmal nachfragen, aber aus Interesse.
Wie strikt seid ihr, was so, was so Tooling angeht?
Also quasi, wenn wir jetzt mit einem Kollegen von dir sprechen würden, würde der sagen, ich mach alles mit Gemini, und der dritte quasi macht das noch mit ChatGPT oder habt ihr so eine, also macht ihr das alles auf dem Rücken von Claude, das jetzt Desktop oder Cloud Code.
Also wie sehr ist denn das ein Corsett?
Also ist kein Corsett.
Also man kann da frei wählen, aber ich merke, eigentlich nutzen fast alle Cloud Code.
Also in meinem engeren Umfeld ist eigentlich aus.
Das hat sich jetzt mittlerweile durchgesetzt in den letzten paar Monaten.
Alle nutzen Cloud-Code und wir haben auch einmal die Woche so Knowledge-Sharing-Sessions über AI-Entwicklung.
Man merkt einfach, alles geht Richtung Cloud Code.
Ey, Corsett sollte gar nicht negativ konnotiert sein.
Ich habe auch so das Gefühl, dass das auch ein bisschen ein bisschen mehr enge quasi Speed erzeugen kann, weil du natürlich quasi jeder hat sein Tool.
Da musst du auch für jeden überlegen, quasi, also welche Integration erlaubst du, weil welche Integration erlaubst du halt nicht.
Und wenn du da halt, sag mal, vielleicht dann eben eher auf die 90%-Variante halt irgendwie gehst, dann das eine Tool, kannst du dich halt irgendwie mehr mit den Integrationen beschäftigen und mehr freigeben und damit mehr Speed halt irgendwie schaffen.
Also ein Thema, was mich zum Beispiel gerade treibt, wie viel Varianz im Tooling willst du halt zulassen.
Aber sorry, beziehungsweise danke.
Ja, ja, generell ist aber die, die Eingabe von Leadership ist, nutzt alle Tools, die da sind.
Also es ist jetzt nicht so, ihr müsst Clock-Code nutzen, aber ich merke von den Entwicklern die Tendenz, das ganz klar zu Clock-Code.
Ist wahrscheinlich das Beste, was auf dem Markt gerade ist.
Ja, ja.
Gemini haben wir auch freigeschaltet, halt das Tolle ist, super mit den Google-Tools integriert.
Ich sehe es aber eigentlich, wir nutzen es wesentlich nur die Gemini Meeting-Transcripts.
Danach sehe ich nicht viel, dass es da viel Nutzen ist.
Achso, weil ihr Google Meet nutzt.
Genau, wir haben halt das komplette Google-Set und Google Meet.
Das ist der Hauptgrund.
Am Anfang war da mehr Push von der Company, wir sind Gemini nutzen.
Das war das erstes freigeschalten.
Ich war da aber sehr frustriert, ich habe es immer wieder kopiert und bin dann immer wieder über Umwege bei Cloud gelandet.
Interessant.
Ja, super spannend.
Das heißt also, eigentlich habt ihr schon dann oder du nutzt deinen persönlichen Agenten, der im Prinzip die Schnittstelle ist für alles, was du so tust und der dir einfach wirklich unfassbar viel genau das abnimmt, was für Menschen eben schwieriger ist, dieses Informationsquellensichten, dann die relevanten Fakten raussuchen, Pattern Matching machen und so, das macht das Tool dann offensichtlich sehr gut für dich.
Genau, und es hat halt wahnsinnig viel Kontext.
Ich habe es jetzt ein Jahr gefüttert.
Es hat all diesen Kontext.
Ach, ich frage regelmäßig, gebe mir mal eine Zusammenfassung über mich.
Es ist irre, wie gut das mich kennt.
Anderes Beispiel, ich muss eine neue Stellenausschreibung machen für mein Team.
Okay, ich sage einfach mal, Claude Claude macht die Stellenausschreibung für das Routing-Teiling-Team.
Es war perfekt.
Also es wusste so viel über mein Team, dass ich nichts nachbessern musste.
Also.
Das glaube ich.
Und den Kontext baut sich die Cloud, das, und hier weiß ich wirklich nicht, baut sich denen die selber auf oder hast du dann lokal so eine Markdown-File-Struktur oder irgendwas?
Nee, das wird irgendwo gespeichert.
Also ich fütter natürlich regelmäßig Infos rein, aber es kann den Kontext gut genug halten.
Ich merke dann immer, wenn ich Sachen.
Ich verstehe auch nicht, wie die App im Detail funktioniert, würde mich auch mal interessieren, aber wenn ich Sachen von größerer Vergangenheit frage, dann kommt immer so ein paar Compact-Ding, der Content.
Also dann dauert es irgendwie fünf Minuten.
Irgendwo wird dann der Content rausgezogen.
Aber es kann generell den Kontext sehr gut halten.
Ja, die werden irgendwo eine Memory-Funktion haben, sicherlich, wo wahrscheinlich genau der die bisherigen Chats zusammengefasst, irgendwie nachgehalten werden, wahrscheinlich sogar mit Embeddings, also dass semantische Suchen funktioniert.
Ja.
Cool.
Habt ihr, habt ihr in dem Zusammenhang bloß ganz kurz, weil ich habe diese Woche, vielleicht ist es auch zwecks Urlaub irgendwie in der Timeline von bei von LinkedIn ein bisschen älter gewesen, aber habt ihr von Claude Code Dream gehört?
Naja, nur einmal einmal kurz irgendwo gesehen, so aufgepumpt.
Also, das ist genau das, was wir gerade diskutieren.
Also, quasi, das geht auf deren Memory-System.
Und das läuft, wenn ich es richtig zusammen richtig verstanden und jetzt noch zusammenkriege, läuft das halt im Hintergrund immer wieder mal.
Also quasi gerade wenn der Memory oder das Kontextfenster halt irgendwie relativ voll ist und räumt halt auf.
Das fand ich so faszinierend.
Also hat wenig für mich mit Dream, also mit Träumen zu tun.
Aber da dann halt auch wieder das, also die Relevanz halt rauszufiltern.
Ich könnte mir vorstellen, wahrscheinlich unter der Haube ist quasi Claude Code Desktop auch nichts anderes als ein Cloude Code.
Ja, ich glaube, ich bin mir relativ sicher, dass das gleich ist, nur eine UA und ein paar andere Schnittstellen.
Ja, für Manager halt eben nicht die Konsole, ne?
Genau, ja.
Ist ja auch, sagen wir mal, praktischer, wenn du eher die Schnittstellen in die anderen Tools brauchst, ne?
Und dann eher Informationen verarbeiten.
Genau, ja.
Absolut.
Absolut, absolut, absolut.
Ja, aber das mit dem Memory finde ich echt spannend.
Also, ich habe tatsächlich gestern Lostless Memory für meinen Open Claw-Bot mal installiert.
Ich weiß noch nicht, ich glaube, so richtig zum Laufen gekriegt habe ich es noch nicht.
Aber wie das funktioniert, ist auch total spannend.
Und zwar macht es auch Conpactions.
Das heißt, es guckt immer, wenn der Kontext einen bestimmten Füllungsgrad hat, tatsächlich schon 20 Prozent oder so, dann erzeugt es Zusammenfassungen von Messages und speichert aber die Original-Messages trotzdem nochmal weg in der Datenbank und hält sich Referenzen an diese Messages in der Zusammenfassung vor.
Und das macht es mehrstufig.
Das heißt, also du hast irgendwie, keine Ahnung, drei Messages, die quasi in einer Zusammenfassung drin sind, dann werden wieder drei Messages zusammengefasst, wieder drei und dann wird darüber eine Metazusammenfassung erzeugt, die aber jeweils immer noch den Link zur kompletten Message in der Datenbank enthält.
So kann also das LLM selber entscheiden, wenn es sagt, ah, okay, hier habe ich jetzt eine Zusammenfassung, ich brauche aber die Details, dann kannst du selber rausziehen, noch aus der Datenbank.
Völlig total spannend.
Ich weiß noch nicht, ob es bei mir gut funktioniert hat.
Ich glaube, die Embeddings funktionieren gerade nicht, aber anderes Thema.
Alright.
Dann, ja, vielen Dank.
Würde ich sagen, habe das Text-Stack-Thema, glaube ich, ganz gut abgefrühstückt.
Hochspannend.
Also muss ich mir die Desktop-App auf jeden Fall auch nochmal angucken.
Kann ich, ja, kann ich es ja empfehlen.
Und würde jetzt zum Hauptthema übergehen, zum Miet.
Und da geht es natürlich, super spannend, gerade, hatten wir auch gestern eine Diskussion auf LinkedIn um das Thema, was macht es eigentlich mit so einer Organisation, wenn man so at-Scale-Software, also Code produziert sozusagen, agentisch.
Was sind so die Folge-Themen?
Genau.
Und ich glaube, da habt ihr bei MapBox durchaus einiges zu, oder hast du einiges zu erzählen, ne, von euch.
Ja, ich glaube, generell muss man erstmal sagen, fast aller Code, den wir produzieren, der ist mittlerweile co-authored bei Claude.
Also es gibt, ich sehe selten mal einen Commit, der noch von Menschen alleine kommt.
Genau, was macht es mit einer Firma?
Also die größte Herausforderung, in der wir jetzt stehen, ist, wir produzieren wahnsinnig viel Code.
Das ist toll, das wollten wir.
Wir müssen den aber weiter in Review.
Und das ist, glaube ich, aktuell die größte, der größte Blocker, der Productivity-Blocker.
Also er blockiert uns eigentlich AI maximal zu nutzen, weil der Code muss noch reviewed werden.
Gleichzeitig, der Code, der gemergt wird, ist unser Code.
Wir sind verantwortlich für den.
Und deswegen muss er reviewed werden und daran hapert es.
Also wir haben sehr große Pull-Requests, sehr viele Pull-Requests und die Pull-Requests werden zu oft einfach approved.
Das ist so die größte Herausforderung aktuell.
Genau, das ist jetzt, wie gehen wir damit um?
Wir wollen niemand blockieren, einen Code zu produzieren, aber wir brauchen irgendwelche Hilfswege jetzt, um den Code trotzdem noch reviewen zu können.
Das ist zumindest der aktuelle Ansatz.
Also das aktuelle Messaging an die ICs ist, der Code, den ihr commitet, ist euer Code.
Auch wenn der von Claude kommt, ihr seid verantwortlich.
Ist euer Code, ihr müsst Fragen dazu beantworten können.
Wenn der Code was falsch macht, ist es euer Code.
Ihr seid dafür verantwortlich.
Wir akzeptieren noch keine Antwort.
Claude hat den produziert, ist nicht mein Code.
Das ist so eine Message, die wir versuchen, die Leute reinzukriegen.
Deswegen ist der Review-Prozess nach wie vor wichtig.
Wir haben aber jetzt keine Antwort.
Wir haben ein paar, also ich merke, es entstehen so Hilfswege, um das besser zu machen.
Also ich kann mal von zwei erzählen.
Eine Sache, die wir intensiv nutzen, ist natürlich Claude als Review.
Das ist sinnvoll, aber das hilft nur begrenzt.
Also da ist unser Eindruck, je nachdem, wie man den Prompt einstellt, entweder ist super nice und sagt, das ist der tollste Pull-Request, die in den letzten zehn Jahren gesehen haben, das ist wenig hilfreich.
Wenn man ihn Schärfe einstellt, dann geht es in die andere Richtung, dann werden Bugs gefunden, die es gar nicht gibt.
Wir lassen es trotzdem laufend schauen darüber, aber das Human Review, das bleibt wichtig.
Eine interessante Sache, die wir jetzt in den letzten zwei Wochen eingeführt wurden, ist, wir nutzen Claude, um gerade für große Pull-Requests zu visualisieren.
Also ein Pull Request wird erstellt, dann wird automatisch eine HTML-Webseite erstellt, wo der Code Change, also gerade bei größeren visualisiert wird.
Das ist einmal, welche Architektur, wie ist sie aktuell und wo geht die hin in den Code Change.
Dann sind da, also es ist eine Webseite, die entsteht.
Die kann man dann anklicken und anschauen.
Dann ein paar Basic Statistics, die einem eigentlich auch GitHub gibt.
Aber es hilft den Reviewer schon mal den großen Kontext zu kriegen und so vielleicht zumindest Design-Probleme zu sehen, die man so in der Masse, also wenn jetzt da 10.000 Line Code-Change kommt, eigentlich nicht mehr machbar sind.
Das andere Messaging, was wir Leute nach wie vor geben, und das ist auch die gleiche Nachricht, die man als EM vor zehn Jahren gegeben hat, ist, versucht die Pull Requests runterzubrechen.
In kleine Pull-Requests, die Review besser.
Ich habe Empathie mit denen, der den Pull Requests reviewen muss.
Wenn du ihnen einen 10.000 Line-Change-PR gibt, kann man den nicht reviewen.
Das sind eigentlich die gleichen Themen, die wir schon vor AI hatten.
Wir wollten vorher auch keine großen Pull-Requests, wir wollten kleine klare Commits, also strukturierte Commits, dass wir Commit by Commit Reviewing können.
Das alles kann man super mit Cloud machen, aber man muss ihn, man muss Cloud auch darauf trainieren, so zu arbeiten.
Das hilft.
Ich glaube aber, wir sind gerade an einem Tipping Point.
Also, dass ich, ich sehe nicht, dass das die langfristige Lösung ist.
Ich finde, der Review-Prozess ist, der bremst uns unglaublich.
Und ich sehe, ich sehe eigentlich GitHub da am Zug.
Euer Kernmodell ist der Review-Prozess.
Git hat schon vor GitHub existiert.
Da braucht man keine große Hilfe, aber was GitHub gut gemacht hat in den letzten Jahren, ist den Review-Prozess zu verbessern.
Aber da fehlt mir jetzt aktuell die Innovation nicht.
Aus meiner Meinung nach bräuchte Style jetzt ein Innovationsschlag.
Wie können wir GitHub weiter nutzen mit AI und den Review-Prozess verbessern, wenn wir beim Review-Prozess bleiben wollen?
Oder der andere Weg, sehe ich auch eine Option ist, wir sparen uns den Review-Prozess.
Wir merken zu Master.
Das wird wahnsinnig viel Produktivität anblocken.
Wir müssen uns aber dann Wege finden, wie können wir trotzdem noch, also wir würden dann nicht mehr owner von den Code sein, sondern AI were owner of diesem Code.
Wir müssen uns dann aber mehr auf, ich sag mal, Guardrails um den Code zu kümmern.
Also wie können wir AI nutzen, dass der Code, der da ist, das macht, was wir wollen.
Genau.
Das ist auch eine Strömung, die es innerhalb von Mapbox gibt, die nennt sich Spec-Driven Development.
Auch nichts Neues, ist ähnlich wie Test-driven Development, aber man fokussiert sich auf die Specks.
Was da gemacht wird, also eine Gruppe, die eine Flag-Gruppe, die da sehr intensiv dran arbeitet.
Man nutzt AI, um vorher die Specs sehr klar zu machen.
Also man erstellt einen YAML-File oder einen Markdown-File.
Aktuell sind sie auf YAML.
Um sehr klar runterzubrechen, also von dem schwammigen Cheerer-Ticket, was sind die Specs, die wir brauchen.
Diese Specks, die werden mit committed.
Die kriegt dann Cloud und baut darauf die Feature auf.
Und also das sehe ich tatsächlich als eine Möglichkeit, dass man sich mehr auf die Richtung fokussiert.
Die Aufgabe des Entwicklers ist, die Specs richtig klar zu machen und weniger den Code zu schreiben.
Und das wird vielleicht ermöglichen, dass man den Review-Prozess sich spart, sondern dass man eher die Specs reviewed.
Das ist ein Riesenschritt.
Den Schritt ist Mapbox nicht noch nicht gegangen.
Aber ich finde es spannend, wie es sich es weiterentwickelt.
Ich finde, der aktuelle Review-Prozess is uns im Weg.
Es ist er blockt uns mehr und gleichzeitig, wir kriegen nicht die Qualität vom Review-Prozess, was wir eigentlich haben möchten.
Ja, genau, das hört man gerade von vielen Unternehmen, die auch schon so ein bisschen weiter sind in der Adoption.
Vielleicht erstmal eine Frage vorab.
Ihr wärt ja wahrscheinlich schon jetzt auch eine Produktivitätssteigerung wahrnehmen im Sinne von, sagen wir mal, Commits nach Production.
Also sprich, wie häufig Changes deployed werden.
Auch das müsste ja mehr geworden sein, oder?
Wird jetzt, ich habe keine klaren Zahlen, aber wir schaffen Projekte in einem Zeitraum, die vor Jahre gedauert haben, jetzt in Monaten.
Das ist ganz klar, ja.
Am klarsten merkt man es im Tooling.
Also unser Produkt ist ja eine API und wir brauchen wahnsinnig viel Tooling, also interes Tooling, um die Qualität zu sichern von unserem Produkt.
Und das war immer in der Vergangenheit ein Riesenproblem.
Oh, wir bräuchten mal das Tool, um das zu überprüfen.
Das waren früher Gespräche, ja, ob man das in das OP, also in das Planungsdokument fürs nächste Jahr mit aufnimmt, so ein Tool zu bauen.
Mittlerweile in der Zeit, wo man das Gespräch führt, baut einfach jemand diese Tools.
Also wir haben ein Wachstum an internen Tools, das ist gigantisch.
Das merkt man ganz klar.
Also, wir haben Tools, die wir immer wollten, die sind jetzt einfach alle da.
Das ist, das ist, ja, auch die Hürde niedriger, kann das gemerkt werden, das ist ein internes Tool.
Das sind andere Prozesse.
Das hat es so gut.
Habt ihr da?
Können wir da kurz mal reinspringen, finde ich mich auch super spannend, haben wahrscheinlich viele Firmen die Herausforderung, also oder also quasi den Need und das war nie dringend genug.
Habt ihr das irgendwie geframed?
Macht ihr das auf irgendeiner bestimmten Plattform?
Schreiben das nur Entwickler oder nur Engineers oder wer darf den so eine Tools bauen?
Weil wie du richtig sagst, dass quasi das Level an Qualität, was auch immer da Qualität bedeutet, ist halt vielleicht ein Ticken niedriger.
Wie macht die?
Die Tools werden einfach gebaut.
Also die ganz einfache Sachen, jemand hat ein Pull-Request und will was validieren, der baut mal kurz mit Cloud eine Website, um das Problem zu visualisieren.
Dass wir früher in Team für sich, dass das hätte bauen müssen.
Oft sind das Wegwerf-Webseiten, also die werden einmal gebaut, kurz angeschaut.
Entweder die serven den Need oder die sind so gut, also sagen wir auch, dann geht es ins Gespräch.
Okay, das ist interessant.
Wie können wir das in unsere offizielle Toolchain integrieren?
Dann werden die Hürden größer, dann sind andere Leute involviert, dann muss deployed werden, muss von einem Login.
Genau.
Aber es entstehen einfach wahnsinnig viele Wegwerf-Tooling.
Und dann zeigt sich auch recht schnell, welches Tool hat Wert und dann geht es eher in den Produktzyklus, dass man darauf weiter aufbauen.
Danke.
Spannend.
Genau, das ist ja auch nicht.
Ja, das ist wirklich, ja, das macht Spaß.
Das ist so, internes Tooling ist natürlich prädestiniert, weil da, also gerade wenn du ein Tool nutzt, um die Qualität von der API zu überprüfen, hast du ja ganz andere Anforderungen an die Skalierbarkeit, an Security von diesem Tool, wenn es intern genutzt wird.
Von daher ist da auch schon mal die Barriere deutlich geringer.
Und die nächste Frage wäre nämlich gewesen, also, oder mal anders, wie ich darüber nachdenke, wenn man sich den Flow anguckt, so ein Prozess, dann haben wir halt verschiedene Prozessschritte.
Jetzt haben wir hier halt vorne das Bottleneck bei der Programmierung anblockt und laufen jetzt beim Review in den Bottleneck.
Wahrscheinlich war aber das Review, die Review-Capacity vorher nicht saturiert.
Das heißt, also da muss schon mehr durchgehen als früher, was du ja auch sagst.
Also sprich, Projekte, die früher Jahr gedauert hätten, gehen jetzt in Monaten.
Das heißt also, man sieht schon ein Uplift.
Und jetzt ist die Frage, wenn ganz viel davon sich für interes Tooling sozusagen auf internes Tooling entfällt, dann wird wahrscheinlich die Operational Stability sozusagen oder Reliability der Plattform nicht darunter leiden.
Das ist ja die Gefahr, die man versucht, auch mit so einem Review-Prozess zu unterbinden, dass man A das Qualitätslevel hochhält und B auch sicherstellt, dass das, was gebaut wird, dass es dafür Mental Models in den Köpfen der Entwickler gibt, sodass Leute wissen, was da gebaut wurde.
Ich sehe sie noch nicht leiden.
Also wir haben noch bei Mapbox ist ein recht klarer Prozess mit Incidents.
Es gab noch keinen einzigen Incident, weil Code von AI generiert wurde, der nicht reviewed wurde.
Ich warte aber drauf, dass er kommt.
Also es ist, glaube ich, nur eine Frage der Zeit, weil eben das Tooling drumherum, also die Guardrails haben sich nicht verändert.
Also wir haben die gleiche Testing-Infrastruktur wie vor.
Klar, wir können bessere und mehr Tests schreiben.
Aber der Review-Prozess hat sich nicht verändert und auch die Testkultur hat sich jetzt dadurch nicht verändert.
Und was ich halt eben schon beobachte, es werden viele Pull-Requests gemercht, die nicht gut genug Reviewt wurden.
Also einfach nur Approof ohne Kommentar wird gemerkt.
Und das ist ein Signal, das kann nicht sein.
Da muss doch was kommentierbar sein.
Und das liegt einfach an der Masse der Pull-Quest und an der Größe der Pull-Requests.
Ja, das heißt also, du gehst davon aus, dass da Probleme auftreten werden und die dann auch gelöst werden müssen.
Das heißt also, also da muss es dann Maßnahmen geben.
Genau, ja.
Ja, mein Wunsch ist, dass wir jetzt halt proaktiv werden.
Wie können wir was bauen, ja.
Lieber, lieber bevor die Probleme dann wirklich großwertig haben.
Genau, ja.
Ja, ich vor dem Hintergrund, also so zwei, zwei Sachen.
Erstmal eine kleine Anekdote.
Ich habe gestern tatsächlich einen, oder vorgestern, glaube ich, ein Feature gebaut für den Mentoring Club, an dem ich ja mit rumwerke und habe das mit Cloud Code gebaut und habe dann, ich habe so auch immer noch so eine alte GitHub-Copilot-Lizenz.
Die läuft da immer so mit.
Die nutze ich eigentlich nur, wenn ich mal ein Security-Update für so eine Open Source-Komponente mache, wie ich noch habe.
Und dann habe ich gesehen, ich kann ja den Co-Pilot auch den Chatbot da bitten, einen Review zu machen.
Und dann hat er tatsächlich wirklich auch lange rumgerödelt und hat da ein krasses Review gemacht, war sehr, sehr pingelig.
Und dann habe ich gesagt, okay, Claude, hier, guck dir das mal an, bitte.
Und Claude Code hat dann so gesagt, so, ja, das sieht solid aus, on point.
So, und hat dann die Kommentare oder beziehungsweise der Copilot hat dann tatsächlich die Kommentare, ich habe den direkt gesagt, hier komm, mach mal einen Pull-Request auf und merge den Kram.
Das hat tatsächlich ganz gut funktioniert.
Also insofern, weil du vorhin sprachst davon, dass es eine Chance für GitHub wäre.
Meine Einzelerfahrung, jetzt, n gleich eins, ne, war tatsächlich da relativ positiv, auch wenn es den Prozess trotzdem in die Länge gezogen hat, weil ich wollte eigentlich schnell das Feature Mergen, war auch irgendwie nur im Admin-Bereich und so, jetzt kein großes Risiko.
Aber tatsächlich gab es ein Bug auf Prot, den ich lokal nicht gesehen habe und den konnte ich dann über diesen Flow auch fixen.
Von daher hat es da funktioniert.
Genau.
Aber so allgemeiner haben wir gestern auch so bei LinkedIn so ein bisschen diskutiert und Fabian Wesner hatte da einen ganz guten Post gemacht, wie seine Sicht auf die Dinge ist.
Fabian Wesner, glaube ich, seines Zeichens, glaube ich, der ehemalige CTO von Spriker, wenn ich es richtig in Erinnerung habe.
Und der hat aufgeschrieben, dass er drei relevante Themenbereiche da sieht.
Das eine ist, Guidelines und Guardrails.
Das heißt, also genau wie du auch sagst, du brauchst natürlich eine Testinfrastruktur, brauchst irgendwie auch bestimmte Guidelines, wie der Code und Projekt strukturiert sein soll.
Es gibt ja immer irgendwelche bestimmten Grundregeln, die man, die man einziehen möchte.
Dann sagt er, er macht nicht mehr, er reviewt auch nicht mehr jeden Code, aber er macht High-Level-Reviews.
Das ist ja auch was, was ihr ja schon eine Richtung, in die ihr geht, über diese HTML-Views, die so kompackt, mehr oder weniger, den riesen den riesen Pull-Request zu einem einer besseren Übersicht, mehr oder weniger.
Und genau das sagt er auch, insbesondere auch um einen Mental Model aufzubauen, von dem, was da tatsächlich passiert.
Also, dass man immer noch, das ist ja dieses, was dahinter steht, das Problem, ne, ownership without authorship, ne, obwohl, also wie, wie ihr das ja auch schön definiert hat, du hast den Code zwar nicht geschrieben, aber dein Claude-Agent hat ihn geschrieben, deswegen bist du trotzdem für diesen Code verantwortlich.
Und um dieses Mental Model aufzubauen, genau, er schreibt dann noch, dass er bestimmte Dinge guckt er sich tatsächlich dann en detail an, also Database-Schema oder komplizierte Logik, so, das macht auch total Sinn, stelle ich auch immer wieder fest, weil die Agenten dann doch anfangen, wo man eigentlich eine ID hat und genau nachvollziehen kann, sozusagen, also genau einen Key-Value-Lookup machen kann.
Wenn irgendwas nicht funktioniert, machen die dann irgendwelche Fallback-Logiken, wo ich sage, nee, eigentlich möchte ich, wenn da irgendwas schiefläuft, möchte ich eigentlich einen Fehler zurückbekommen, keine Fallback-Logik, der den Fehler verwischt.
Also dafür ist es schon, glaube ich, sinnvoll.
Genau, und das sind so, also und Mental Model sind so die drei Punkte, die er da aufführt.
Und das fand ich ganz spannend, weil, also A, glaube ich, das geht genau in die richtige Richtung, auch um das zu anblocken, nicht mehr jedes Detail, sondern High Level, die Guardrails, ne?
Und B, weil, ja, genau.
Also ich glaube, dass man muss sich da halt rantasten, was sind so die richtigen Guardrails, aber wie bei allem, ist es halt ein Change-Prozess und man quasi muss mal in die eine Richtung steuern, dann wieder in die andere Richtung steuern.
Ich glaube, wenn man das so betrachtet, dann kann man da tatsächlich Fortschritt machen.
Klingt nach einer guten Beschreibung, ja.
Also gerade diese Mental Models, da finde ich, hilft AI, also nicht nur im Code-Review-Prozess, ich nutze es auch sonst so, ich nehme mal IG gern her, ey, hier ist der Code oder hier ist das Dokument, visualisier mir das.
Ja.
Und dann am Anfang habe ich da Chemini benutzt, mittlerweile Claude Desktop das selbst integriert, diesen Visualisierungsprozess.
Und das ist für Architekturdiskussion oder Design-Konversation unglaublich hilfreich, wenn ich ein Meeting mit einem Bild starte.
Das triggert so viel bessere Gespräche.
Und das war in der Vergangenheit.
Ich hätte Stunden gesetzt, irgendein schönes Mirrorboard aufzusetzen.
Das kriege ich jetzt in wenigen Minuten und dadurch kann ich so viel bessere Meetings haben.
Transcribe dann die Meetings mit Gemini und füttert das dann wieder zurück, um dadurch, also wir nutzen das wahnsinnig viel für Design-Dokumente, immer das Transcript wieder zurückfüttern und Claude iteriert dann am Design-Dokument, dass wir dann wieder reviewen.
Das ist unglaublich hilfreich.
Ja, wahnsinnig gut, was das auch für ein Productivity-Boost darstellt.
Und das sind ja wirklich Dinge, du guckst ja jedes Artefakt an.
Das heißt, du überprüfst auch, ob er das richtig aufgenommen hat und siehst auch, ob das dem entspricht, was du erwarten würdest.
Von daher, da gibt es auch wenig klar, kann man da auch mal was überblicken.
Aber das, was man an Zeit spart, dass man das nicht selber strukturieren, zusammenfassen muss, und wie du schon sagst, ein großes Figma-Board oder Miro-Board oder was auch immer aufsetzen muss, Wahnsinn.
Genau.
Und holt halt auch Leute ab, die sehr visuell denken.
Also, vorher war alles in geschriebener Form oder in Code.
Jetzt kann man nochmal viel leichter visuell kommunizieren.
Das finde ich einfach toll.
Ich würde tatsächlich, ich kenne, also ich würde da mal gerne beiwohnen.
Ich habe immer die Sorge, dass wenn man etwas visualisiert, dann ist das halt auch wie eine Art Compaction.
Das ist halt, also da gehen natürlich auch Informationen verloren.
Absolut.
Wir finden ja da alle unseren Weg gerade.
Also insofern, ich will es gar nicht zerreden.
Die Visualisierung, da ist Mapbox sehr streng.
Ist nur ein Hilfsmittel.
Bei Mapbox ist alles, muss geschrieben sein und alles als Text.
Also keine Bulletin Points.
Diagramme können nur als Unterstützung benutzt werden.
Es muss Mapbox hat eine wahnsinnig starke Written Culture.
Also alles muss immer ausgeschrieben sein als Text.
Das war, das war ein großer Unterschied von den deutschen Unternehmen, von denen ich kam zu Mapbox.
Da ein Meeting zu kommen, du hast immer eine Reading-Time am Anfang des Meetings und du fängst immer mit einem geschriebenen Dokument an, um eben das zu vermeiden.
Im Bild kann man wahnsinnig viel interpretieren, in den Text viel weniger.
Sehr Amazon-like.
Ja, es ist so stark durch viele, viele von der Geschäftsführung kommen von AWS.
Ja, macht Sinn.
Dann macht es Sinn.
Ja, das ist wahrscheinlich ein ganz guter Segway, um auch so ein bisschen die Kultur von Mapbox mal insgesamt zu beleuchten.
Ihr habt ja eine sehr ausgeprägte OPEX-Kultur, was auch super spannend ist, weil da muss ich gestehen, da habe ich, also ich habe auch schon Touchpoints gehabt mit, sagen wir mal, Kulturen, die stärker waren in dem Bereich, aber in den meisten Startups, in denen ich so wage habe, wenn die noch ein bisschen jünger sind, da ein bisschen noch nicht so sehr auf die Operational Excellence fokussiert, sondern eher auf die, sagen wir mal, Effektivität im Sinne von was Neues erstmal überhaupt hinzustellen, statt irgendwie dann hintenrum zu optimieren und ja, halt die Kultur drauf anzupassen.
Deswegen, ja, super spannend.
Ja, Mapbox hat eine sehr intensive OPEX-Kulture.
Also es musste ich wirklich neu lernen, als ich dazu kam, da zu Mapbox, was das bedeutet.
Man muss vielleicht auch wissen, fast alle bei Mapbox sind Entwickler oder Entwicklerinnen gewesen.
Also Peter, der CEO, der war AWS-Mitarbeiter Nummer 22, soweit ich weiß.
Also bis zur obersten Etage haben alle ein wahnsinnig gutes technisches Verständnis und auch dadurch ein Verständnis, warum Operational Excellence Tech-Dab wichtige Themen sind.
Das ist eigentlich immer das prominenteste Thema.
Und das spürt man dann einfach in allen Gesprächen.
Ja.
Ich habe das am Anfang am meisten gemerkt über Post-Mortems.
Wenn ihr wollt, kann ich da ein bisschen tiefer einsteigen, wie Post-Mortems beim Mapbox ablaufen.
Da gibt es, ich kann den Post-Modems eher so von deutschen Startups, ja, man trifft sich mal und schreibt ein Dokument, was gut lief und schlecht lief und hat vielleicht ein, zwei Action-Items.
Und das war dann das Post-Mortem.
Bei Mapbox ist das anders.
Also wenn ein Incident ist, hat man erstmal ein Incident Document.
The Incident Command ist dafür zuständig, das aufzusetzen.
Ist ein recht starrer Prozess, den man dann durchlaufen muss.
Es muss eine kurze Beschreibung und relativ schnell muss der Custom Impact herausgearbeitet werden.
Und das muss dann auch, da gibt es dann ein Slack Channel geteilt werden.
Wir haben diesen Incident und der wird dann kategorisiert von Stufe 1 bis 4.
Eins ist full outage, zwei ist Partial Outage und dann geht es je nach Stufe immer weiter runter.
Genau, nachdem unser Incident ist dann hat auch ein klare Ablauf.
Also je nachdem, wie höher die Stufe ist, umso mehr Support kriegt man, kann mehr Leute reinholen, kann verschiedene eskalieren.
Dadurch laufen nicht sehr strukturiert und schnell ab.
Und das bleeding sollte eigentlich dann in der Regel schnell gestoppt werden.
Da dabei zu sein, das war einfach, als ich dazu kam zu Mapbox, wie sowas abläuft, unglaublich spannend.
So, die ersten Incidents-Calls habe ich viel gelernt, da ist wahnsinnig viel Adrenalin und auch sehr professionell, also wie sowas abläuft.
Da kommt dann wirklich, das ist jetzt nicht nur die Entwickler, sondern da kommt auch schnell das obere Management dazu und kommt zu den Incident-Call dazu und kann wahnsinnig tiefe, detaillierte Fragen stellen, wo ich so, wow, du bist zwei Stufen über mir und du kannst jetzt diese Frage über den Code stellen, weil ich so wirklich beeindruckt.
Das kannte ich von den Firmen, wo ich vorher war, da war einfach nicht, dass so viele Ebenen über mir, die noch so ein gutes Verständnis von Code haben und was das für ein Kunden bedeutet.
Bei all den Gesprächen geht es immer um Custom Impact.
Also nachdem dann so ein Incident is, wir haben dann ein weekliches Operational Metrics Review Meeting.
Das ist der erste Schritt, dann Quick Hits.
Da hat man fünf Minuten Zeit, den Incident vorzustellen.
Und in den Operational Metrics Review, sehr intensives Meeting, da kommen alle ganze Geschäftsführung zusammen, alle EMs und alle Tech Leaders, also Staff Engineers und so, treffen sich da.
Groß ist die Gruppe.
Es sind knapp 100, 150 Leute.
Okay.
Also du musst dann vor 150 Leuten inklusive Geschäftsführung dem Incident vorstellen und Fragen annehmen.
Es wird nicht erwartet, dass du die Fragen beantworten kannst.
Aber du musst die Fragen abnehmen, außer das bleeding is ongoing.
Also wenn der Incident ongoing ist dann, dann wird es sehr kritisch, aber in der Regel ist der Incident dann resolved.
Also du nimmst dann die Fragen an, kannst du sie beantworten, musst du allerdings nicht, und du hast dann eine Woche Zeit, das Post-Mortem auszuarbeiten.
Da müssen dann all diese Fragen, die du bekommen hast, beantwortet sein.
Und das Post-Mortem ist jetzt nicht so one-Pager, sondern das sind eher so fünf bis zehn Seiten.
Sehr detailliert.
Also, da ist erstmal eine kurze Zusammenfassung.
Dann recht große Teilung Custom Impact.
Und der ist, da war ich auch überrascht, da wird wahnsinnig viel Arbeit dann reingesteckt, zu verstehen, was hat das eigentlich für den Kunden bedeutet.
Das ist bei einer API gar nicht so einfach.
Also wir liefern eine API, was bedeutet das jetzt für ein Auto, das irgendwo rumfährt, wenn ein Teil der API für eine gewisse Zeit nicht ging, das rauszuarbeiten.
Und da wird auch viel Code geschrieben, um den Custom Impact zu analysieren.
Super interessant und die D-Section, die muss eigentlich richtig sharp sein.
Es ist klare Zahlen und auch klare Beschreibung, was es für den Endnutzer bedeutet und auch wie wurde das dann an den Kunden kommuniziert.
Also dass wenn die Section nicht scharf ist, dann wird es schwierig.
Genau.
Danach kommt eine Timeline und da kommt AI natürlich auch wieder voll ins Spiel, um das Post-Mortem zu schreiben.
Die Timeline, ich habe den Slack Incident Channel, wo es Zugang hat, ich habe den Meeting Transcript, da habe ich innerhalb von wenigen Sekunden die Timeline generiert und kann sie dann noch ein bisschen curaten, dass die wichtigen Sachen herausgehoben sind.
Die Timeline ist wichtig, um dann rauszuarbeiten, wie haben wir es gemerkt, dass ein Incident da ist, wie schnell haben wir das gelöst, wie lief die, wie schnell lief die Customer Communication ab.
Genau, dann beim Post-Mortem Review wird die auch nochmal intensiv auseinandergenommen.
Und wenn da die Zeit zu lang ist, kommen da kritische Fragen.
Warum hat das so lange gedauert?
Warum habt ihr das nicht gemerkt?
Warum habt ihr ein anderes Team gemerkt?
Solche Sachen werden dann über die Timeline herausgearbeitet.
Und dann kommt die five Y Section, also die fünf Fragen.
Und das hat mir gerade an Anfang, also die ersten post-mortems, die ich geschrieben habe, habe mir Claude unglaublich geholfen, diese 5W-Fragen to beantworten.
Also weil ich hab, okay, ich bin neu, gute Opportunity for me, das system besser to verstehen, that's my team owned.
Ich will gerne mal schreiben.
Mein Team gibt mir dann Feedback, das ich da schreibe, richtig ist.
And da in den 5W-Fragen, da geht man wirklich dann tief in den Code rein.
Warum ist dieses Problem aufgestanden?
Warum wurde es nicht über Tests gefangen?
Und da kann mir einfach Claude wahnsinnig helfen, also Claude Code dann diese W-Fragen zu beantworten.
The abschluss ist dann Lessons learned from post-mortem.
Und da ist Webbox auch sehr klar.
Lessons learned is not, oh, we had a test gebraucht, sondern die suchen explizit nach wie weiter von Incident sicherstellen, dass die nicht normal passiert.
Also, wie können wir einen ähnlichen Incident firmware sicherstellen, dass wir sowas nicht nochmal haben.
And the Lessons Learned gehen dann über Action Items.
And that finde ich eigentlich ganz toll.
Action Items sind nicht Sachen, die man niederschreibt und vergisst, sondern action items gehen in Share Tickets über und die haben ein 30-Day SLA.
Das heißt, Action-Items, die aus dem Post-Mortem entstehen, hat man 30 Tage Zeit zu beheben.
Ansonsten ist dieses Team rot.
Also jedes Team muss einmal die Woche eine Scorecard abliefern.
Und ein SLA ist, ob du deine Action-Items from Post-Mortems erledigt hast.
Und da hast du 30 Tage Zeit.
Und das gibt eine ganz klare Priorisierung von Tech-Dab.
Die ewige Tech-Dab-Frage ist teilweise gelöst dadurch.
Du hast ein Incident mit Clarn Customer Impact.
Daraus hat eine Gruppe von 150 EMs und Senior Leaders entschieden, dein Team muss diese Action-Items in 30 Tagen erledigen.
Und jegliche Diskussion, ist das jetzt wichtig oder machen wir das jetzt oder in einem halben Jahr ist dahin.
Weil du willst sicherstellen, dass du diesen Art von Incident nicht nochmal hast.
Und das gibt eine super Priorisierung von Tech-Dap.
Du priorisierst genau da, wo der Kunde Pain hat, wo Tech-Dab ist, was das post-mortem herausgearbeitet hat.
Also die Action-Items sind nicht nur so, machen wir da ein Pflaster drüber, sondern strukturell verändern, dass wir diese Art von Incident nie wieder haben.
Und das gibt mir also eher ein super Tool an die Hand, um zu priorisieren.
Also, die große Aufgabe ist, bei MacBooks hat nicht jeder EM immer einen Produktmanager an der Hand.
Also, ich beispielsweise keinen.
Das heißt, ich bin für die Priorisierung verantwortlich.
Gib mir ganz klare Prioritäten.
Wir müssen alles dran setzen und das ist nicht einfach, in 30 Tagen, diese Action Items in production müssen die sein, umzusetzen.
Genau, also ich liebe diesen Postmortem-Prozess.
Da ist, man taucht wirklich tief ein.
Man stellt wirklich sicher, dass die Probleme strukturell gelöst werden und nicht nur ein Pflaster obendrauf.
AI hilft wahnsinnig viel.
Also ich mittlerweile, wir haben Incident.
Früher war das eher so Arbeit von mehreren Wochen, gutes Post-Mortem to schreiben.
Mittlerweile ist die Guideline sieben Tage.
And I'm talking, man has an incident, then is man eighteen now so an incident plot.
Da passiert nicht mehr viel on so ein Tag, aber am Tag danach ist eigentlich das erste, ich hole alle Gemini transcripts, ich hole alle Facten that I have, schmeißt die in Claude und lass mir den ersten Draft from Postmortem schreiben.
Den review ich dann das erste Mal team intern.
And dann iterieren wir.
Wir haben dann eine Woche Zeit zu iterieren, bis das Postmortem gut genug ist, um das in der großen Gruppe zu präsentieren.
Das sind dann wirklich Artifacts, die sind super spannend zu lesen.
Also es ist einmal wenn man präsentiert, man will sicherstellen, man präsentiert da wahnsinnig hohe Qualität, weil es bis zum CEO sind da alle anwesend, die dein Postmortem lesen.
Also 150 Leute lesen dein Postmortem.
Gleichzeitig ist es auch super interessant in diesen Meeting, weil du gießt jede Woche so ein Postmortem von anderen Team, du lernst wahnsinnig viel.
Also, wie gehen andere Teams mit ähnlichen Problemen um lernst, wie funktionieren Produkte bei MapBox.
Das ist eines der interessantesten Meetings, das Operational Metrics Review Meeting bei MapBox.
Sehr intensiv, aber man lernt wahnsinnig viel.
Ja, klingt, klingt super.
Also insbesondere auch der, die der Punkt, das du sagst, also grundsätzlich das Ziel von einem Post-Mortem ist ja immer, dass du Action-Items machst, damit du ähnliche Inzidenz in Zukunft verhinderst und früher detectest, im Zweifel.
Aber genau dieser Fokus, 30 Tage und dann muss es live sein und dass es nicht verhandelbar, da merkt man dann auch, dass einfach Techis quasi dafür verantwortlich waren.
Ja, es ist halt eine Verankerung auf einer Kulturellen eben.
Ja.
Man merkt die Begeisterung an und ich spüre auch eine innere Begeisterung.
Das freut mich.
Ja, das klingt super.
Genau.
Das ist wirklich, und ja, das ist vielleicht dann auch ein Unterschied, ne?
Sagt man ja immer, in Deutschland gibt es viele Unternehmen, die irgendwie so von WWLern gegründet werden, die halt ganz anders auf so eine Themen draufgucken, als ehemalige Entwickler.
Also man muss auch unterscheiden, also es ist jetzt Mapbox ist kein Startup, das eine App baut für ein Endnutz, sondern unsere Kunden sind viel Automotive, teilweise autonomes Fahrenes involviert.
Da sind, wir dürfen uns keine Fehler erlauben.
Deswegen gibt es diese strenge OPEX-Kultur, über die nicht verhandelt wird.
Das ist einfach, die ist gegeben.
Das ist immer ein ganz klares Argument in der Priorisierungsfrage.
Und da kommt man nicht drum rum.
Ja, und da wird auch, ja, wird erwartet, dass man da mitzieht und dass das so sieht.
Und da muss da muss ich tatsächlich, das war ein Step-up von meiner von den vorherigen Stellen, die ich hatte.
Da musste ich wachsen, um da mitzuhalten.
Ja, cool.
Ich glaube, wenn man einmal so eine Kultur mit erlebt hat, dann davon kann man ja immer zehren sozusagen im weiteren Karriere.
Ja, cool.
Das war sehr spannend.
Haben wir alle Themen adressiert, die du so auf der Agenda hattest, Uli.
Ja, ich könnte ein anderes Thema ist noch Root Cause Analysis, finde ich auch interessant, geht auch mit in die OPEX-Kultur, wenn ihr wollt.
Es ist ein ähnlicher Prozess, eigentlich wie ein Post-Mortem.
Ja, wir haben wie viele Firmen viele Bugtickets, mit denen wir umgehen müssen.
Und da, das war auch ein großer Learning für mich, als ich zu Mapbox kam.
Ein Bugticket, gut, bei uns sind Bugtickets häufig komplizierter als jetzt ein Button geht nicht in der App.
Der Umgang mit dem Bug-tickets, it's a bit anders, als ich ihn kannte.
Man löst nicht nur, man macht nicht ein Pull Request und löst das Problem, sondern man trifft sich erstmal, also man kriegt ein Ticket und geht dann auch ein sehr strukturierter Prozess durch, ähnlich wie beim Post-Mortem, um das Ticket zu verstehen.
Also es sind im Wesentlichen vier Schritte.
Also man produziert auch wieder ein Textdokument.
Also, man verlässt Tira, geht zu Google Doc, there's a festes Template, das man verfolgt, wie beim Postmortem.
What is the Kundenerwartung?
What is the actual behavior?
Also, da formuliert man wieder an clear paragraph, understates this with beweisen, also screenshots of what the drift is: do we agree this is a problem?
Die ist sehr, sehr wichtig, this is a problem.
Man denkt man, when the kund says it's a problem, it's not clear that it's a problem, but often, no, the system function as it function.
But the kid is trotzdem not clear.
Deswegen is the wichtig.
Is it a problem or is it a problem?
And then it's over in why does the system behave this way?
Also, the erkling why we have this bug, and this is then easily the five Y section in post-mortem.
And my error is when we try to three entwickler, inclusive EM, and we give some document through.
We write this with Claude for.
Also, we made this bug-ticket, it's with Cloud Code and let's a draft for this for this RCA document and review this.
We have the pause in my why does the system behave this way?
The last shit is where the fix aussie.
And we focus on the problem.
We're the error, when the problem really sauber herausgearbeat is, then is the fixed.
I won't say a gewission.
Genau, yeah.
Und das zu verstehen, yeah.
Genau.
We have also the artifact is we have the geschriebene document.
But these RCA Sessions in Person stattfinden.
Also man trifft sich wie in an Incident Call in person.
In the vergangenheit, there are wahnside in Share passiert with Comments.
Tickets were from one team to the next team geworfen, our problem.
Beweisen.
Also wenn einer sagt, this problem is not in my team, sondern in dein team, dann okay, show me.
Beweis mir, wo das Problem ist.
Und dann macht man Screenshots, fügt es in the RCA-Dock hinein und so arbeitet many stuff for stuff on the problem run.
Daddy was clear, wo ist das Problem.
Das ist am Anfang, wenn wir so ein Ticket bekommen, bei uns nie klar, ist es im SDK?
Is this a routing Engine team, ist das ein Data-Problem von Road Team.
Es gibt wahnsinnig viele Bereiche, wo so ein Problem entstehen kann, wenn der Route nicht passt.
Und da sind diese In-Person-Meetings wahnsinnig hilfreich.
Und so kann man sich dann an die Lösung herangearbeiten.
Genau, Claude unterstützt uns halt wieder, um einen initialen Draft zu machen von dem Dokument.
Dann der finale Draft.
Also am Ende muss das Dokument scharf sein.
Der letzte Schritt ist dann eine Message an den Customer, die der EM approven muss.
In all den Schritten AI voll involviert, um das Ganze die Formulierung zu machen und dann letztendlich den Fix auch zu machen.
Genau, und das ist eine Art von OPEX Culture, die ich vorher so nicht kannte, dass man so mit Bugtickets umgeht.
Man stellt halt eben dadurch sicher, dass Probleme langfristig gelöst sind.
Also, dass da jetzt nicht nur ein Pflaster oben drauf kommt, dass das Problem weg ist.
Sondern dass man wirklich den Root cause von dem Problem löst.
Genau.
Yeah, das ist irgendwie, sagen wir mal, bringt das Thema Zero Bug Policy nochmal auf ein ganz anderes Level, sozusagen.
Weil wenn du für jeden Bug so ein Aufwand betreibst, und das ist natürlich bei einer Infrastruktur wie Mapbox einfach auch essentiell, glaube ich, dann wirst du die auch los am Ende.
Und was ich cool finde, ist, man hat es ja so oft, dass man nicht genau weiß, wo der Bug jetzt tatsächlich ist, und dann wandert es zum einen, wandert zum anderen und wandert irgendwie zum Dritten.
Und das ist einfach ausgeschlossen durch den Prozess.
Das klingt auch sehr, sehr, sehr, sehr cool.
Ja, zu Zero Bug Poicy vielleicht noch ein Wort.
Also die RCAs haben auch häufig das Ergebnis, ey, das System funktioniert, wie es funktionieren soll, aber wir haben ja ein Design-Issue.
Das können wir jetzt nicht in ein, zwei Wochen lösen.
Dann wandert das Ticket to the third, aber wir haben eine klare Dokumentation.
Und was wir dann suchen, ist andere Bugtickets, die im gleichen Root Course haben, zu bündeln.
Und dann hast du Argumente für das nächste OP-Planning, also Mapbox operiert in diesem Operational Planning Modus.
Ich habe hier 30 Bug-Tickets, die haben alle den gleichen Root Course.
Es erfordert ein System Redesign.
Hier ist der Custom Impact ganz klar dokumentiert.
Ich habe ja all meine RCAs geschrieben schon.
Und das gibt mir wieder Futter, um einen größeren System Redesign zu verteidigen in einem Operational Planning Meeting.
Also ja, wir können nicht alle Bugs lösen, aber die RCAs sind es trotzdem wichtig, um den eigentlichen Root Course und ein System Redesigned zu justifieren.
Ja.
Macht total Sinn.
Cool.
Hört sich, also hört sich spannend an.
Ich glaube, es ist halt super viel Disziplin, ne?
Das halt, also wenn man da drin steckt, weiß nicht, ob man es dann immer noch so spannend findet.
Also weil es anstrengend ist.
Es ist super spannend, weil eben diese Disziplin da ist.
Also es ist nicht, es ist nicht so um den Tisch gekehrt.
Und das macht alle.
Du brauchst halt eine brauchst eine spezielle Schlagleute.
Also ich glaube, das ist halt, also wenn ihr, ich gerade überlege, das Sebastian hat ja auch gerade gesagt, so Zero Bug Policy, ich finde das greift viel zu kurz.
Das ist halt eigentlich eher, also ist halt viel mehr in der Kultur verankert, quasi Technical Excellence oder Operational Excellence.
Und das braucht dementsprechend ganz andere Leute, wohingegen so eine Bugpolicy eher als man oft nur auf einer prozessualen Ebene halt irgendwie greift.
Und das ist halt, das haben wir alle schon halt irgendwie schon zwei oder dreimal halt irgendwie gesehen.
Teilweise funktioniert es, andere nicht, aber das liegt halt immer an der Organisation, an der Kultur, an den Leuten, die du halt irgendwie hast.
Und wenn du jetzt sagst, es ist halt spannend, dann würde ich sagen, passt du genau in diese Kultur halt rein.
Aber das halt irgendwie durchzuekzertieren in einer Kultur, die da nicht drauf passen würde, also das jetzt einzuführen, ist, glaube ich, ein Riesen, ist ein Riesenshift, weil es eben nicht nur ist, jetzt lass uns mal halt irgendwie die Bugs auf Null bringen, ja.
Sondern das ist ein anderer Schnack, wie man im Norden sagen würde.
Ja, also braucht das volles Commitment von Leadership.
Also und das, ich kann total verstehen, wenn ein kleineres Startup anderen Fokus hat, mehr auf Revenue.
Aber Mapbox ist eben Leadership ganz klar, der Custom Impact.
Es dreht sich alles immer um Custom Impact.
Ist der Customer Impacted?
Das startet jede Konversation und das priorisiert dann ganz klar.
Und das, ja, ich kann total verstehen, wenn.
Ich glaube, dieses Modell funktioniert nicht für alle Firmen.
Ja, es ist halt, es orientiert sich sehr stark an eurem Kontext.
Und ich glaube, dahingehend ist es halt The right pick.
Ja, absolut.
Genau.
Würde ich auch sagen, wenn eine Firma, die eine Infrastruktur wie Mapbox zur Verfügung stellt, nicht so stark auf Operational Excellence achtet, dann wird es schwer auch dahin zu kommen.
Also ich glaube, den Umkehrschluss kann man auch wagen.
Ja, vielen Dank.
Ich glaube, jetzt sind wir so ungefähr durch alle möglichen Themen, die wir aufgeschrieben hatten oder die du auch aufgeschrieben hattest, mal durchgerast.
Wahnsinnig spannend.
Also auf der einen Seite zu hören, wirklich, wie Mapbox als klassisches amerikanisches, ja nicht mehr Startup, sondern Scale-Up, würde man wahrscheinlich bei uns sagen, mit AI umgeht und wo da jetzt die Bottlenecks sich verschoben haben, viel drüber gesprochen.
Bei euch ist es halt Realität.
Genau, wir haben am Schluss noch zwei so kleinere, regelmäßige Segmente.
Das eine ist der Reality-Check, wo es immer darum geht, so welches Tool dich zuletzt irgendwie mal wieder enttäuscht hat, so ein What the fuck-Moment und aber auch, was so für dich der gerade der heißeste Scheiß ist.
Genau.
Ja, welches, ich glaube, ich kann die Frage mit einem Tool beantworten.
Das ist zuletzt Rovo AI.
Die habe mich total begeistert und total enttäuscht gleichzeitig.
Ich kenne die Rovo AI von Atlashian.
Ja, das ist einfach das AI-Tool von Atlasion in Chira integriert.
Als ich gesehen habe, macht total Sinn, in Chira AI zu integrieren.
Das erste Mal habe ich es benutzt vor ein paar Monaten.
Du hast diese Tickets, die ist schon ewiges Thema.
Tickets sind schlecht strukturiert, schlecht geschrieben.
Kannst du Leute noch so oft sagen, bitte strukturiert die bitte besser.
Es hat nie richtig funktioniert.
Atlash hat einen Button eingebaut und strukturiert dir abhängig von den Comments, die es schon gibt, das Ticket total sauber.
Und es war so, wow, das ist so endlich.
Ich kann mir diesen Kommentar sparen, ich traue nur in diesen Knopf drücken.
Und alle waren begeistert im Team und die Qualität war wirklich gut.
Also das Ticket war gut strukturiert und hat uns dann erlaubt, das Ticket wirklich zu verbessern, sodass wir damit arbeiten können, von einem Kauderwilsch zu einem strukturierten Ticket.
Aber ich so, habt ihr toll gemacht, Atlasion, das ist wirklich guter Mehrwert.
Und dann wollte ich es weiter nutzen.
Wie gesagt, man muss relativ viel Reporting bei Mapbox machen.
Einmal die Woche muss ich für größere Initiativen kurze Berichte schreiben.
Ey, da ist es perfekt.
Ich habe alle Infos in Rovo, also in Atlasion, in Sheera.
Ich nutze Rovo, um meine Summaries zu schreiben.
Also, das sind so halbe Seiten in etwa.
Und weil der Kontext ist da und da war ich dann echt enttäuscht.
Also es hat all den Kontext, alle Infos und die Texte, die rauskam, ich habe langere Versuch mit verschiedenen Prompts.
Hat einfach, das war einfach nur eine Zusammenchachtelung an Tickets, was dann als Text rauskam.
Und dachte ich, ihr habt allen, also es konnte nicht mal von der Initiative auf Epic auf Task runterbrechen, sondern es ist immer auf die Initiative geblieben, wo ich so, okay, da hättet ihr mal eine Chance.
Also ich hoffe auch, sie entwickeln weiter, was ich dann gemacht habe.
Ich bin zurück zu Claude gegangen, ey Claude.
Hol den Kontext hier raus und Claude ist dabei meinen, um meinen weiter gute Texte zu schreiben, die ich dann habe, um sie zu refinen, dass ich viel Potenzial für das ganze Reporting da besser zu werden.
Das heißt, ich war begeistert von Robo, aber auch enttäuscht.
Alles klar.
Ja, cool, danke dir.
Und dann letzter Punkt, und das haben wir ja vorhin, haben wir ja schon so ein bisschen drüber gesprochen, ne?
Hast du noch eine kleine Prediction vielleicht?
Ja, ich hab, das ist eigentlich das Thema, was wir besprochen haben.
Wie geht Code Review weiter?
Also, was ist die Zukunft von GitHub?
Ich habe keine klare Prediction, aber mein Bauchgefühl ist, wir pushen bald eher zum Main Branch.
Und der Review-Prozess in der Form wird vorbei sein.
Aber das ist so ein bisschen.
Ich sehe ein Problem, aber ich sehe nicht ganz klar, ganz klar die Lösung.
Ich erhoffe mir GitHub kommt in die Puschen und löst das für uns.
Ja.
Alles klar.
Vielen Dank, Uli.
War ich cool.
Also abgesehen davon, genau, mal wieder mit dir zu sprechen, was immer schön ist, aber auch super spannend, was du von Mapbox erzählt hast.
Sehr, sehr cool.
Und auch hier wieder habe ich das Gefühl, es wäre so geil, wenn wir uns in sechs Monaten oder so nochmal unterhalten würden, um zu gucken, wie habt ihr dann das Review-Problem gelöst, etc.
Total interessant, ja.
Ich habe ein bisschen bei all den Themen jetzt, das ist, wir stecken überall in diesen Kinderschuhen, haben überall diese Kinderkrankheit.
Die einen Tools lassen sich nicht gut verbinden, MCP-Server existiert, aber es klappt oft nicht so.
Also diese ganzen Schnittstellen, das gefühlt in einem halben Jahr ist das gelöst.
Also dieses ewige Problem, wie organisieren wir Knowledge und Confluence.
Ich glaube, all diese Probleme sind in einem halben Jahr gelöst.
Wir sind total spannender Zeit jetzt.
Also ich kann es nicht erwarten, halb Jahr zurückzuschauen.
Wo stehen wir jetzt?
Ja, also wir bauen viele Prozesse jetzt drumrum um AI.
Ich glaube, viele Prozesse sind überflüssig in einem halben Jahr.
Wir müssen die trotzdem machen jetzt.
Wir müssen jetzt handeln, aber ich glaube, viel ist obsolet in einem halben Jahr.
Deswegen, ja, ich freue mich auf ein halbes Jahr, um das erneut zu besprechen.
Please ein bisschen.
Der HMZE-Podcast ist ein gemeinsames Projekt von Sebastian Heidemeyer zu Erben und André Neubauer.
Infos zum Gast und Themen aus dem Podcast findest du in den Shownotes.
Diskutieren kannst du mit uns bei LinkedIn und für alles andere, zum Beispiel wen du gerne mal hier hören möchtest, kannst du gerne eine E-Mail an podcast.hmzde.tech checken.
Vielen Dank für deine Zeit.
Wenn es dir gefallen hat, abonniere den Podcast.
Bis zur nächsten Folge.