Latest / Beyond Vibe Coding / #055 Wie das Review Problem gelöst wird - mit Uli Strötz (Mapbox)
Transcript
- HMZE Podcast - Beyond Vibe Coding: Ich glaube, man vergisst dann immer retrospektiv, wie zäh das dann halt irgendwie immer war. Das, glaubt ich, hat bestimmt noch eine Woche damit zu tun. Männer schnupfen halt. Herzlich willkommen zur achten Folge unserer neuen Staffel von HMZE Beyond Vibe Coding, der Podcast, in dem wir den fundamentalen Change in der Softwareentwicklung begleiten. Ich bin Sebastian Heidemeier zu erben, CTO bei NorthIO. Und ich bin André Neubauer, CTPO bei Trusted Jobs. Schön, dass ihr wieder da seid. Unser heutiger Gast ist wieder ein ehemaliger Kollege, diesmal von dir, Sebastian. der ist aktuell Engineering Manager bei Mapbox, einer US Tech Company. Genau. damit ist es wieder ein Perspektivwechsel, weil, wie man sich vorstellen kann, so eine moderne US Tech Company durchaus sehr, ich sag mal, eye-embracing ist und da tatsächlich ganz spannende Themen hochkommen. Also wir sprechen über Tooling für Engineering Manager. Spoiler, der ⁓ 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 Vibe Coding Podcast. Ich glaube das ist insgesamt die 55. HMZE Episode. Interessiert eigentlich keine Sau. Egal. Herzlich willkommen Uli. Danke Sebastian. Hallo. Schön, dass du da bist. Und das sagt André normalerweise. Naja, diesmal habe ich es dir geklaut, deinen Trademarkspruch André. Ich hoffe es ist okay. Absolut. Genau, am Anfang bitten wir unsere Gäste, 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 haben wir Sebastian schon zusammengearbeitet bei einem kleinen Berliner Start-up in der Mobilitätsbranche door-to-door. Später haben wir bei Tonys zusammengearbeitet. Genau, und jetzt bin ich aktuell bei Mapbox. Amerikanisches Start-up, sagen sie immer noch. Obwohl es 900 Mitarbeiter hat. Genau, ich der Engineering Manager für zwei Teams. Mein Hauptfokus ist im Routing. Wir bauen die Directions API. Und die Directions API ist mein Team verantwortlich, den Graph zu bauen. Wir nehmen die rohen Daten und bauen darauf den Graphen. Und integrieren auch die Echtzeitdaten in den Graphen und stellen es dann weiteren Teams zur Verfügung. Das ist im Groben meine Aufgabe. Ja, cool. alle, Mapbox nicht kennen, Mapbox ist im Prinzip, wenn ich es richtig oder korrigiere mich, wenn ich es zu einfach ausdrücke, 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, genau. Als ich auf die Webseite geschaut habe, hat sich es angefühlt wie On Starlets. Das wirkt schon nochmal wie eine bessere Version als Google Maps, ⁓ euch da mal auch auf den Thron zu heben. Das war schon sehr, sehr beeindruckend. da wirkt Google Maps wie so eine 1.0 dagegen. Ja, ich glaube, der Hauptunterschied ist, unsere Haupt-Kunden sind Entwickler. Wir wollen Leute ermöglichen, ihre Produkte zu verbessern, mit allen, Karten sind. Also, Suche, dann die visuelle Karte und dann Directions und Google. Bietet das auch an, aber nicht nicht zu dem Extend. Also man kann es nicht so weit custom-alten wie bei uns. Ja, super cool. genau, also Uli hat auch einen Hintergrund in Geo-Sachen, sag ich mal. Also wir haben auch bei Dorthe Door, 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 aus dem Koordinaten zu tun gehabt und eine Karte involviert. Das ist interessant für mich. Deswegen passt es perfekt. Ja, wir steigen ja immer ein so bisschen mit dem Status Quo, mit dem Tech 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, 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. ist natürlich ein neuer, ich meine, wir sind ja abhängig von vielem, aber es ist eine neue Dimension, die man auch einfach im Hinterkopf haben muss. Es 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-Website geht, da ist sehr viel rot. Also man merkt einfach bei Anthropic ist da noch sehr viel in Entwicklung und die sind noch nicht da, glaube ich, wo sie sein möchten. Und das merken wir natürlich auch, wenn irgendwas schief geht, geht es bei uns auch nicht mehr weiter. Absolut. Kannst noch ein bisschen was dazu erzählen, wie du die Cloud-Desktop-App genau nutzt? Die habe ich tatsächlich noch nie selber benutzt. Deswegen super spannend. Genau, ist ein anderes Produkt von Anthrophic als Cloud Code. Das ist nochmal ein extra Lizenz. Aber es ist im Wesentlichen das Gleiche. eine Desktop-App. Ich nutze es eigentlich wirklich für alles. Wir hatten einen Performance Review Cycle. Ich habe alle Performance Reviews mit dieser App geschrieben. Es hat mittlerweile Zugang zu Google Docs. Ich kann das One-on-One-Document 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, ich möchte Situation, Behaviour, Impact Feedback haben und ich kriege das Feedback. Und es ist verdammt gut. Im Vergleich, was ich früher an Performance Reviews an Zeit investiert habe und wie ich das jetzt mit Claude schreiben kann, ist die Qualität ist so viel besser und ich spare wahnsinnig viel Zeit. Ansonsten nutze ich es einfach immer wieder, ⁓ Kontext zu kriegen. 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, Mapbox Kontext und Wissen gefehlt habe, da war Cloud unglaublich hilfreich. ich kann von so vielen Schnittstellen Informationen holen und mir einen Brief geben. in fast jedes Meeting gehe ich kurz vorher, versuche ich in Cloud nochmal reinzugehen, gebe mir den Brief, ⁓ mich kurz abzuholen, was der aktuelle Stand auf Slack, was der aktuelle Stand in den Google Docs. Und dann lasse ich mich kurz vorher informieren. Ansonsten nutze ich es auch einfach für mich, ⁓ als ⁓ zu wachsen. Also uns werden fast alle Meetings mit Gemini Transcribed mittlerweile. Und die Meetings, die ich interessant finde, gebe ich dann nochmal Claude und sage explizit, du weißt, ich bin ⁓ gib mir Feedback. habe das jetzt in aktuellen sehr vielen 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, ⁓ zu wachsen, ⁓ Feedback zu kriegen. Das ist fantastisch. super cool. Sorry, Andre. Darf ich eine? Ich bin gar nicht sicher, ob ich das gar nicht brechen aber mich würde eine Sache mal interessieren, Uli. Ja. Ist das deine erste US-Company? Das ist tatsächlich die erste US-Company. Das richtig, Du hast, na ja, wahrscheinlich door to door, wüsste ich gar nicht, wie amerikanisch oder wie europäisch das geprägt ist, aber du kennst wahrscheinlich ja auch dann, also ohne zu sagen, dass Tonys jetzt ein typisch deutsches Unternehmen ist. Aber du kennst ja auch dann wahrscheinlich dir so bisschen das Kontrastprogramm. Würdest du sagen, also 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 einschätzen? Mir wird das gerade so klar und du sprichst auch so locker drüber. Ja, Klo, Desktop, machen wir. Ich kenne auch genug Firmen, die jetzt sagen, hm, Security Assessment müssen wir erst mal gucken. Keine Ahnung. Wie fühlt sich das für dich an? Ja, ich bin bei Tonys rausgegangen. Co-Pilot, das Beste der Dinge. Chatchu PT kam gerade so auf, aber wirklich in der Arbeit genutzt haben wir das noch nicht. Kam dann bei Mapbox hinzu und da waren eins, die Tools 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 so etwas freigeschalten ist, maximal zu nutzen. Und dann hat es aber, ich würde sagen, in den letzten halben Jahr wirklich einen starken Shift gegeben, wo ganz klar die Ansage ist, nutzt alles, was geht. Wenn ein nicht freigeschalten wird, innerhalb von 24 Stunden, dann braucht es eine ganz klare Begründung. Man kann zu Leadership gehen, eskalate, wenn du nicht Zugang zu einem Tool kriegst. Die Erwartung ist, sollen AI zu maximal nutzen. Der letzte Schritt, der jetzt noch gegangen wurde, Mapbox hat einen sehr intensiven Interview-Prozess. sind im Wesentlichen vier große Interviews, die durchmust. Die sind sehr strukturiert, sehr klar, aber sehr aufwändig. Zu den vier Schritten kam jetzt ein fünfter hinzu, das ist ein AI-Interview. Also wir schauen explizit bei Kandidaten, wie stehen die zur 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. wer das nicht will, der ist eigentlich bei Mapbox mittlerweile falsch. Also die Leute, die noch kritisch sind, ⁓ im Production Code will ich keine AI nutzen. Diese Stimmen hört man ja immer wieder. Da ist keine Offenheit mehr. Die Frage ist groß, wie gehen wir damit ⁓ aber die Erwartung ist, dass wir maximal nutzen. Ich kann 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. Nutz AI maximal. Danke. Danke. Da kommen wir vielleicht gleich im weiteren Verlauf auch noch dazu, wie sich das bisher auswirkt, denn das hat ja verschiedene folgen. Ich glaube, 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. heißt also Security, GDPR, geopolitische Fragestellungen sind einfach anders für amerikanische Firmen. Aber dann glaube ich auch, dass die Kultur auch 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, du arbeitest und den Text-Dac kommen. hast ja gesagt, dass die Claude Desktop App für dich eigentlich mehr oder weniger jetzt deine Schnittstelle ist für alles Mögliche. Genau, heißt also, ist Slack, Google Docs wahrscheinlich auch. Ich weiß nicht, nutzt ihr Notion oder irgendeine Knowledge Base? Na, Confluence und Chira. Confluence. Und die Integration ist eben auch da. Das ist mein Go-To-Ort, ⁓ Ja, ich brauche eigentlich weniger zu den einzelnen Tools zu gehen. Ich kann alles von Claude machen. Claude ist so weit, und das habe ich jetzt auch paar Mal gemacht, dass ich Claude schreibe in meinen Namen, Slack 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, ich bin noch ein bisschen begrenzt, weil eben noch nicht alles freigeschalten ist. Also ich habe keinen Zugang zu GitHub über Claude. Das noch eine riesen Demetierung. Das ist nochmal was, man weiß was in Chira passiert, das ist so die halbe Wahrheit, ein Projekt steht. Slack ist wahrscheinlich bisschen mehr Wahrheit, wo ein Projekt steht als Chira. Die eigentliche Wahrheit ist im Source Code. Und der Zugang, den muss ich dann immer noch über die Krücke, Cloud Code gehen. Also ich muss den Code pullen, dann Cloud Code aufmachen, wo stehen wir da? Also Mapbooks in meiner Stelle ist... schon sehr viel Reporting, was ich machen muss. Schriftliche Reporting und da ist AI eine wahnsinnige Hilfe. Also schnell Texte schreiben. Genau, wie kriege ich den Import? ist eben über Slack, Jira, GitHub und über den Source Code. Und da nutze ich dann Cloud Code zusätzlich noch. ich gehe zu Cloud Code, er gibt mir den aktuellen Stand und den kopiere ich dann rüber zur Cloud Desktop App, ⁓ meine Artifacts rauszukriegen. Ich muss da nochmal nachfragen. Ja. Wie strikt seid ihr, was so Tooling angeht? quasi, wenn wir jetzt mit einem Kollegen von dir sprechen würden, würde der sagen, ich mache alles mit Gemini und der Dritte quasi macht das noch mit Jpt oder habt ihr so eine, also macht ihr das alles auf dem Rücken von Cloud, das jetzt Desktop oder Cloud Code, also wie sehr ist denn das ein Korsett? Also es 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 aussch- Das hat sich jetzt mittlerweile durchgesetzt in den letzten paar Monaten. Alle nutzen Cloud Code und in- Ja, wir werden auch einmal die Woche so Knowledge Sharing Sessions über AI-Entwicklung und man merkt einfach alles geht Richtung Cloud Code. Corsett sollte gar nicht negativ konnotiert sein. Ich habe auch das Gefühl, dass das auch bisschen mehr Enge Speed erzeugen kann, weil natürlich jeder hat sein Tool. Da musst du für jeden überlegen, welche Integration erlaubst du, welche Integration erlaubst du nicht. Und wenn du da vielleicht dann eher auf die 90 %-Variante gehst, dann das eine Tool mehr mit der Integration beschäftigen und mehr freigeben und damit mehr Speed schaffen. Also ein Thema, was mich zum Beispiel gerade treibt. wie viel Varianz im Tuning willst du halt zulassen. Aber sorry, bzw. danke. Ja, generell ist aber die Eingabe von Leadership, nutzt alle Tools, da sind. Also es ist jetzt nicht so, ihr müsst Clockcode nutzen, aber ich merke von den Entwicklern, die Tendenz ist ganz klar zu Clockcode. ist wahrscheinlich das Beste, was auf dem Markt gerade ist. ja, Gemini haben wir auch freigeschaltet. Also das Tolle ist, mit den Google-Tools integriert. Ich sehe es aber eigentlich, wir nutzen wesentlich nur die Gemini Meeting Transcripts. Danach sehe ich nicht viel, dass da viel Nutzen ist. Ach so, weil ihr Google Meet nutzt. Genau, wir haben halt das komplette Google Set und Google Meet. Das ist der Hauptgrund. Am Anfang war der Mehrpush von der Company, sollen Gemini nutzen. Das war als erstes freigeschalten. Ich war da aber sehr frustriert. Ich habe es immer wieder probiert 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 Informationsquellen sichten, 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. Also ich frage regelmäßig, ich gebe mir mal eine Zusammenfassung über mich. Es ist irre, wie gut das mich kennt. Ein anderes Beispiel, muss eine neue Stellenausschreibung machen für mein Team. Okay, sage mal, Cloud macht die Stellenausschreibung für das Routing-Tiling-Team. Es war perfekt. Es wusste so viel über mein Team, dass ich nichts nachbessern musste. Das glaube ich. Und den Kontext, baut sich die Cloud Desktop, und hier weiß ich wirklich nicht, baut sich die dieselbe auf? Oder hast du dann lokal so eine Markdown-File-Struktur oder irgendwas? Nee, das wird irgendwo gespeichert. Ich füttere natürlich regelmäßig Infos rein, aber es kann den Kontext gut genug halten. merke dann immer, wenn ich Sachen, ich verstehe auch nicht, die App im Detail funktioniert, das würde mich auch mal enttäuschen, aber wenn ich Sachen von größerer Vergangenheit frage, dann kommt immer so ein paar Compact-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 die bisherigen Chats zusammengefasst irgendwie nachgehalten werden, wahrscheinlich sogar mit Embeddings, also das semantische Suchen funktioniert. Cool. Ja. Habt ihr in dem Zusammenhang, bloß ganz kurz, ich habe diese Woche, vielleicht ist es auch Zwecks Urlaub irgendwie in der Timeline von LinkedIn ein bisschen älter gewesen, aber habt ihr von Claude Code Dream gehört? Nur einmal kurz irgendwo gesehen. Also das ist genau das, was wir gerade diskutieren. quasi das geht auf deren Memory-System. Und das läuft, wenn ich es 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 die Relevanz halt rauszufiltern. Ich könnte mir vorstellen, wahrscheinlich unter der Haube ist quasi Cloud Code Desktop auch nichts anderes als ein Cloud Code. Ja, ich glaube, bin mir relativ sicher, dass das gleiche ist, nur eine andere UX und ein paar andere Schriftstellen. Ja, für Manager halt eben nicht die Konsole. Genau, ja. Ist ja auch, sagen wir mal, praktischer, wenn du eher die Schnittstellen in die anderen Tools brauchst und dann eher Informationen verarbeiten. Genau, Absolut. Absolut. Absolut. Absolut. Ja, aber das mit dem Memory finde ich echt spannend. Also ich habe tatsächlich gestern, wie heißt es, lossless memory für meinen OpenClaw-Bot mal installiert. 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 Compactions. Das heißt, es guckt immer, wenn der der Kontext einen bestimmten Füllungsgrad hat, tatsächlich schon 20 % oder so, dann erzeugt es Zusammenfassungen von Messages und speichert aber die Original-Messages trotzdem noch mal weg in der Datenbank und hält sich Referenzen an diese Messages in der Zusammenfassung vor. Und das macht es mehrstufig. Das heißt, 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 Meta-Zusammenfassung erzeugt, die aber jeweils immer noch den Link zur kompletten Message in der Datenbank hält. So kann also das LLM selber entscheiden, wenn es sagt, ⁓ okay, hier habe ich jetzt eine Zusammenfassung, ich brauche aber die Details, dann kann es die selber rausziehen noch aus der Datenbank. mich total spannend. Ich weiß noch nicht, ob es bei mir gut funktioniert hat. Ich glaube, die Embeddings funktionieren gerade nicht, aber anderes Thema. All right, dann Ja, vielen Dank. Würde ich sagen, haben wir das Tech Stack Thema, glaube ich, gut abgefriestückt. Hochspannend. Also muss ich mir die Desktop App auf jeden Fall auch nochmal angucken. Kann ich, ja, kann ich sehr empfehlen. Ja. Und würde jetzt zum Hauptthema übergehen, zum Meet. Und da geht's natürlich, das ist 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 Folgethemen? Genau, und ich glaube, da habt ihr bei Mapbox durchaus einiges zu, oder hast du einiges zu erzählen von euch? Ja, ich glaube, generell muss man erstmal sagen, fast aller Code, den wir produzieren, ist mittlerweile ein Co-Author bei Claude. Also es gibt, ich sehe selten mal einen Commit, der noch von Menschen alleine kommt. Genau, was macht es mit einer Firma? Die größte Herausforderung, der wir jetzt stehen, ist, Wir produzieren wahnsinnig viel Code, das ist das Tolle, das Folgende. Wir müssen den aber weiterhin reviewen. Und das ist, glaube ich, aktuell 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 gemerged wird, ist unser Code. Wir sind verantwortlich für den. Und deswegen muss er reviewed werden und daran harbets. 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, wie gehen wir damit ⁓ Wir wollen niemanden blockieren, ein Code zu produzieren, aber wir brauchen irgendwelche Hilfswege jetzt, ⁓ den Code trotzdem noch reviewen zu können. Das ist zumindest der aktuelle Ansatz. Also das aktuelle Messaging an die ICs ist der den ihr committet 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 euer Code. Ihr seid dafür verantwortlich. Wir akzeptieren noch keine Antwort. Claude hat den produziert. Das 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... Ich merke, es entstehen Hilfswege, ⁓ das besser zu machen. 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, immer den Prompt einstellt, entweder er super nice und sagt, ist der tollste Pro Request, in letzten zehn Jahren gesehen haben, das ist wenig hilfreich. Wenn man ihn schärfer einstellt, dann geht es in die andere Richtung, dann werden Bugs gefunden, die es gar nicht gibt. Wir lassen das doch zum Laufen schauen da drüber, aber das Human Review, das bleibt wichtig. Eine interessante Sache, die wir jetzt in den letzten zwei Wochen eingeführt worden ist, wir nutzen Cloud, ⁓ gerade für große Porequest, die zu visualisieren. Also ein Porequest 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 die aktuell und wo geht die hin in den Code Change? Dann sind da, also es ist eine Webseite, entsteht. Die kann man dann anklicken und anschauen. Dann ein paar Basics, Statistik, die einen eigentlich auch GitHub gibt. Aber es hilft den Reviewer schon mal den großen Kontext zu kriegen und so vielleicht zumindest Designprobleme zu sehen, die man so in der Masse, also wenn jetzt da 10.000 Line Codechanged kommt, eigentlich nicht mehr macht, was es Das andere Messaging, was wir Leute nach wie vor geben und das ist auch Die gleiche Nachricht, man als ⁓ vor zehn Jahren gegeben hat, versucht, die Pull Requests runterzubrechen. In kleine Pull Requests, die reviewbar sind. Hab Empathie mit denen, der den Pull Requests reviewen muss. Wenn du ihnen 10.000 Line Change PR gibst, kann man den nicht reviewen. Das sind eigentlich die gleichen Themen, die wir schon vorher hatten. Wir wollten vorher auch keine großen Pull Requests, wir wollten kleine, klare Commits, also strukturierte Commits, dass wir Commit-by-Commit-Reviewen können. Das alles kann man super mit Claude machen, aber man muss Claude auch darauf trainieren, so zu arbeiten. Das hilft. Ich glaube aber, wir sind gerade an einem Tipping Point. Ich sehe nicht, dass das die langfristige Lösung ist. Ich finde, Review-Prozess bremst uns unglaublich. Und ich sehe eigentlich GitHub da am Zug. Euer Kernmodell ist der Review-Prozess. GitHub hat schon vorher existiert. Da brauchen wir 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. Aus meiner Meinung bräuchte es da jetzt einen 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, das 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 dem Code sein, sondern AI wäre Owner von diesem Code. Wir müssen uns dann aber mehr auf, ich sag mal, Guardrails ⁓ den Code 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, nennt sich Spectrum in Development. Auch nichts Neues, ähnlich wie Test Driven Development, aber man fokussiert sich auf die Specs. Was da gemacht wird, eine Gruppe, eine Slack-Gruppe, die da sehr intensiv dran arbeitet. Man nutzt AI, ⁓ vorher die Specs sehr klar zu machen. Erstmal erstellt ein YAML-File oder ein Markdown-File. Aktuell sind sie auf YAML. ⁓ sehr klar runterzubrechen, also von einem schwammigen Chira-Ticket, was sind die Specs, die wir brauchen. Diese Specs Die werden mit committed. Die kriegt dann Cloud und baut darauf die Feature auf. Das sehe ich 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. Das wird vielleicht ermöglichen, dass man den Review-Prozess sich spart, sondern dass man eher die Specs reviewt. Das ist ein Riesenschritt. Den Schritt ist Mapbox noch nicht gegangen. Aber ich finde es spannend, wie sich das weiterentwickelt. finde, aktuelle Review-Prozess ist uns im Weg. Er blockt uns mehr und gleichzeitig bekommen wir 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 bisschen weiter sind in der Adoption. Vielleicht erstmal eine Frage vorab. Ihr werdet 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? Ich habe keine klaren Zahlen, aber wir schaffen Projekte in einem Zeitraum, die vor Jahren gedauert haben, jetzt in Monaten. Das ist ganz klar. Am klarsten merkt man es im Tooling. Also unser Produkt ist ja eine API und wir brauchen wahnsinnig viel Tooling, internes Tooling, ⁓ die Qualität zu sichern von unserem Produkt. Und das war immer in der Vergangenheit ein Riesenproblem. ⁓ wir bräuchten mal das Tool, ⁓ das zu überprüfen. Das war ein früher Gespräch, da man das in das OP, also in das Planungsdokument fürs nächste Jahr mit aufgenommen, 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 die Hürde niedriger. Man das gemütchern, das ist ein internes Tool. Das sind andere Prozesse. Können wir da kurz mal reinspringen? Finde ich mich auch super spannend. Haben wahrscheinlich viele Firmen die Herausforderung, also quasi den Need und das war nie dringend genug. Genau. Habt das irgendwie geframed? Macht ihr das auf irgendeiner bestimmten Plattform? Schreiben das nur Entwickler oder also nur Engineers? Oder wer darf so eine Tools bauen? Weil wie du richtig sagst, das quasi das Das Level an Qualität, was auch immer Qualität bedeutet, ist vielleicht ein Ticken niedriger. Wie macht ihr das? Die Tools werden einfach gebaut. Einfache Sachen, die man ab und vor requestet und will was validieren. Der baut mal kurz mit Cloud eine Website, ⁓ das Problem zu visualisieren. Das war früher ein Team für sich, das das hätte bauen müssen. Oft sind das Wegwerf-Websiten, 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 deploit werden, muss von in Login. Genau, es entstehen einfach wahnsinnig viele Wegwerftooling und dann zeigt sich auch recht schnell, welches Tool hat Wert und dann geht es in eher einen Produktzyklus. dass wir darauf weiter aufbauen. Danke. Spannend. ist wirklich, ja, das macht Spaß. Das ist so, internes Tooling ist natürlich prädestiniert, weil da, gerade wenn du ein Tool nutzt, ⁓ 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, ich darüber nachdenke. Wenn man sich den Flow anguckt, so ein Prozess, dann haben wir halt verschiedene Prozessschritte. Jetzt haben wir halt vorne das bottleneck bei der Programmierung unblockt 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. 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 internes 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 in den Köpfen der Entwickler gibt, sodass Leute wissen, was da gebaut wurde. Ich sehe sie noch nicht leiden. haben noch, bei Mapbox ist es 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 darauf, dass er kommt. Also das ist, ich, nur eine Frage der Zeit, weil eben das Tooling drumrum, also die Guardrails, haben sich nicht verändert. Also wir haben die gleiche Testing-Infrastruktur wie vorher. klar, wir können bessere und mehr Tests schreiben. Aber der Reviewprozess hat sich nicht verändert und auch die Testkultur hat sich jetzt dadurch nicht verändert. Und was ich halt eben schon beobachte, ist, werden viele Pull Requests gemercht, die nicht gut genug reviewt wurden. Also einfach nur Approve ohne Kommentar wird gemercht. Und das ist ein Signal, das kann nicht sein. Da muss doch was kommentierbar sein. Und das Es liegt einfach an der Masse der Pull requests 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, muss es dann Maßnahmen geben. Genau, Mein Wunsch ist, dass wir jetzt halt proaktiv werden. können wir was bauen? Lieber bevor die Probleme dann wirklich groß werden. Ja, vor dem Hintergrund, also so zwei Sachen, erstmal eine kleine Anekdote. habe gestern tatsächlich Ich vorgestern, glaube ich, 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 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, die ich noch habe. Und dann habe ich gesehen, ich kann ja den Co-Pilot auch, den, äh, äh, den Chatbot da, äh, also 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, pingelig. Und dann habe ich gesagt, okay, Claude, hier guck dir das mal an, bitte. Und Claude Code hat dann so gesagt so, äh, ja, das sieht solid aus, äh, on point. So hat dann die, äh, die Kommentare oder beziehungsweise Der Copilot hat dann tatsächlich die Kommentare, ich hab den direkt gesagt, hier komm, mach mal ein 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, endgleich einzelne, 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 Merge, war auch irgendwie nur im Admin Bereich und so jetzt. kein großes Risiko. Aber tatsächlich gab es einen Bug auf Pod, 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 bei LinkedIn 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 der ist der ehemalige CTO von Spryker, wenn ich es richtig in Erinnerung habe. Und der hat aufgeschrieben, dass er drei relevante Themenbereiche da sieht. Das eine ist Guidelines and Guardrails. Das heißt, also genau wie du auch sagst, du brauchst natürlich eine Testinfrastruktur, brauchst irgendwie auch bestimmte Guidelines, wie der Code im Projekt strukturiert sein soll. Es gibt ja immer irgendwelche bestimmten Grundregeln, 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 in Richtung in die ihr geht über diese HTML-Views, die so kompakten mehr oder weniger, riesen Pull-Request zu einer besseren Übersicht mehr oder weniger. Und genau das sagt er auch, insbesondere auch ⁓ einen Mental Model aufzubauen von dem, da tatsächlich passiert. dass man immer noch, ist ja dieses, was dahinter steht, Problem, Ownership without Authorship, obwohl, also wie ihr das ja auch schon definiert habt, du hast den Code zwar nicht geschrieben, aber dein Cloth Agent hat ihn geschrieben, deswegen bist du trotzdem für diesen Code verantwortlich. Und ⁓ dieses Mental Model aufzubauen, genau, er schreibt dann noch, dass er bestimmte Dinge guckt er sich tatsächlich dann in Detail an, also Database Schema oder komplizierte Logik, das macht auch total Sinn, stelle ich auch immer wieder fest, die Erkenntnissen dann doch anfangen, wo man eigentlich eine ID hat und genau nachvollziehen kann, sozusagen, 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 schief lä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, ⁓ das zu unblocken, nicht mehr jedes Detail, sondern High Level, die Guardrails und B, weil, ja genau, also ich glaube, dass man muss sich da halt ran tasten, was sind so die richtigen Guardrails, aber Wie bei allem ist es halt ein Change-Prozess und man 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. 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 AIG gern her. Hier ist der Code oder hier ist das Dokument. Visualisieren wir das. Und dann am Anfang habe ich da Gemini benutzt, mittlerweile Cloud Desktop, das selbst integriert, diesen Visualisierungsprozess. Und das ist für Architektur-Diskussion oder ja... 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 jetzt stundengesetz, irgendwie schön, das Mirrorboard aufzusetzen. Das kriege ich jetzt in wenigen Minuten und dadurch kann ich so viel bessere Meetings haben. Transcribe in an die Meetings mit Gemini und fütter das dann wieder zurück. Und dadurch, also wir nutzen das wahnsinnig viel für Design-Dokumente. immer das Transcript wieder zurückfüttern und Claude iteriert dann an einem Designdokument, das 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, 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, sehr visuell denken. Also vorher war alles in geschriebener Form oder in Code. Jetzt kann man noch mal viel leichter visuell kommunizieren. Das finde ich einfach toll. Ich würde da immer gerne beiwohnen. habe immer die Sorge, wenn man etwas visualisiert, dann ist das auch wie eine Art Compaction. Da gehen natürlich auch Informationen verloren. Wir finden ja da alle unseren Weg gerade. Also insofern will ich gar nichts zu reden. Die Visualisierung, das ist in Mapbox sehr streng, ist nur ein Höchstmittel. Bei Mapbox muss geschrieben sein und alles als Text. Also keine Bulletinpoints. Diagramme können nur als Unterstützung benutzt werden. Mapbox hat eine wahnsinnig starke Written Culture. Also alles muss immer ausgeschrieben sein als Text. Das war ein großer Unterschied von den deutschen Unternehmen, von denen ich kam, zu Mapbox. Da ein Meeting zu kommen, hast immer eine Reading Time am Anfang des Meetings und du fängst immer mit einem geschriebenen Dokument an, ⁓ eben das zu vermeiden. Ein Bild kann man wahnsinnig viel interpretieren, in den Text viel weniger. Sehr Amazon-like. Ja, es ist so stark durch, dass viele von der Geschäftsführung kommen von AWS. Ja, macht Sinn. Dann macht Sinn. Ja, das ist wahrscheinlich ein ganz guter Segway, ⁓ auch so 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, stärker waren in dem Bereich, aber in den meisten Start-ups, in denen ich so war, gerade wenn die noch ein bisschen jünger sind, da bist du 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 halt die Kultur darauf anzupassen. ja, super spannend. Ja, Mapbox hat eine sehr intensive Opex-Culture. 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-tab, wichtige Themen sind. Das ist eigentlich immer das prominenteste Thema. Und das spürt man dann einfach in allen Gesprächen. 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's... Ich kann den Postmortem eher so von deutschen Start-ups. 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 Postmortem. Bei Mapbox ist das anders. Also wenn ein Incident ist, hat man erst mal ein Incident-Document. Der Incident-Command ist dafür zuständig, das aufzusetzen. Das ist ein recht starker Prozess, den man dann durchlaufen muss. Es muss eine kurze Beschreibung und relativ schnell muss der Customer Impact herausgearbeitet werden. Und das muss dann auch, da gibt es dann den Slack Channel, geteilt werden. Wir haben diesen Incident und der wird dann kategorisiert von Stufe 1 bis 4. 1 ist Full Outage, 2 ist Partial Outage und dann geht es je nach Stufe immer weiter runter. Genau, nachdem, also so ein Incident hat auch ein klare Ablauf. Also nachdem, wie höher die Stufe ist, umso mehr Support kriegt man, kann mehr Leute reinholen, kann verschieden eskalieren. Da ich glaube, 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 zum Mapbox, wie sowas abläuft, unglaublich spannend. Die ersten Incident-Calls habe ich viel gelernt, ist wahnsinnig viel Adrenalin. Und auch sehr professionell, also wie sowas abläuft, da kommt dann wirklich, das ist jetzt nicht nur der Entwickler, sondern da kommt auch schnell das obere Management dazu und kommt so den Incident Call dazu und kann wahnsinnig tiefe, detaillierte Fragen stellen. ich so wow, das ist zwei Stufen über mir und du kannst jetzt diese Frage über den Code stellen, war ich so wirklich beeindruckt. Das kannte ich von den Firmen, wo ich vorher war. Da war einfach nicht das. so viele Ebenen über mir, die noch so ein gutes Verständnis von Code haben und was das für einen Kunden bedeutet. Bei all den Gesprächen geht es immer ⁓ Custom Impact. Also nachdem dann so ein Incident ist, 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, kommen alle Die ganze Geschäftsführung kommt zusammen, alle EMS und alle Tech Leaders, also Staff, Ingenieure und so treffen sich da. Wie groß ist die Gruppe? Es sind knapp 100, 150 Leute. okay. Also du musst dann vor 150 Leuten, inklusive Geschäftsführung, den Incident vorstellen und Fragen annehmen. Es wird nicht erwartet, dass du die Fragen beantworten kannst. Aber du musst die Fragen annehmen, außer das Bleeding ist ongoing. Also wenn der Incident ongoing ist, dann Dann wird es sehr kritisch, aber in der Regel ist der Incident dann resulvt. Du nimmst dann die Fragen an, kannst sie beantworten, musst sie 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 ein One-Payter, sondern das sind eher so fünf bis zehn Seiten. Sehr detailliert. Also da ist erstmal kurze Zusammenfassung. Und dann recht große Teilung Customer Impact. 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. 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 beschrieben dann, ⁓ den Custom Impact zu analysieren. Super interessant. Und die Section muss eigentlich richtig sharp sein. Also klare Zahlen und auch klare Beschreibung, was es für den Endnutzer bedeutet und auch wie wurde das dann an den Kunden kommuniziert. 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, ⁓ das Postmortem 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 bisschen curaten, dass die wichtigen Sachen herausgehoben sind. Die Timeline ist wichtig, ⁓ dann rauszuarbeiten, wie haben wir das gemerkt, dass ein Incident da ist, wie schnell haben wir das gelöst, wie schnell lief die Customer-Communication ab. Genau, dann beim Postmodern Review wird die auch noch mal intensiv auseinandergenommen und wenn da die Zeit zu lange ist, kommen da kritische Fragen. Warum hat das so lange gedauert? Warum habt ihr das nicht gemerkt? Warum habt... dass ein anderes Team gemerkt, solche Sachen werden dann über die Timeline rausgearbeitet und dann kommt die im Anschluss daran die 5Y-Section, also die 5W-Fragen. Und das hat mir gerade am Anfang, also die ersten Postmortems, die ich geschrieben habe, mir unglaublich geholfen, diese 5W-Fragen zu beantworten. weil ich habe gesagt, okay, ich bin neu hier, gute Opportunity für mich, das System besser zu verstehen, dass mein Team owned. Ich würde es gern mal schreiben. Mein Team gibt mir dann Feedback, das, ich da schreibe, richtig ist. Und da in den fünf W-Fragen, da geht man wirklich tief in den Code rein. Warum ist dieses Problem aufgestanden? Warum wurde es nicht über Tests gefangen? Da kann mir einfach Claude wahnsinnig helfen, also Claude Code, diese W-Fragen zu beantworten. Der Abschluss ist dann Lessons Learned von Postmortem. Da das Webbox auch sehr klar. Lessons Learned ist nicht, wir hätten einen Test gebraucht, sondern... Die suchen explizit nach, wie können wir diese Klasse von Incidenten sicherstellen, dass die nicht nochmal passieren. Also wie können wir einen ähnlichen Incident firmenweit sicherstellen, dass wir sowas nicht nochmal haben. genau, die Lessons lang gehen dann über Action-Items. Und das finde ich eigentlich ganz toll. Action-Items sind nicht Sachen, die man nie erschreibt und vergisst, sondern Action-Items, gehen in Chira-Tickets über und die haben dann 30-Day SLA. Das heißt Action-Items, die aus dem Postmortem entstehen. man 30 Tage Zeit zu beheben. Ansonsten ist dieses Team rot. Also jedes Team muss einmal die Woche eine Scorecard abliefern. werden verschiedene SLAs bewertet und ein SLA ist, ob du deine Action-Items von Post-Mortems erledigt hast. Und da hast du 30 Tage Zeit. Und das gibt eine ganz klare Priorisierung von Tech-Dap. Die ewige Tech-Dap-Frage ist teilweise gelöst dadurch. Du hast ein Incident mit Clankustom 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 Jahr, ist dahin. Weil du willst sicherstellen, dass du diesen Art von Incident nicht noch mal hast. Und das gibt eine super Priorisierung von Tech-Dapt. Du priorisierst genau da, wo der Kunde Pain hatte, wo Tech-Dapt ist, was das Post-Wart-Hem herausgearbeitet hat. die Action-Items sind nicht nur so jetzt... machen wir da ein Pflaster drüber, sondern strukturell verändern, dass wir diese Art von Incident nie wieder haben. Und das gibt mir als EM ein super Tool an die Hand, um zu priorisieren. Also große Aufgabe ist, bei Mebux hat nicht jeder EM immer einen Produktmanager an der Hand. Also ich beispielsweise habe keinen, das heißt ich bin für die Priorisierung verantwortlich. Das gibt mir ganz klare Prioritäten. Wir müssen alles dran setzen und das ist nicht einfach. In 30 Tagen diese Action-Items im Production müssen die sein. umzusetzen. Genau, also ich liebe diesen Postmodern-Prozess. Man taucht wirklich tief ein, man stellt wirklich sicher, dass die Probleme strukturell gelöst werden und nicht nur ein Pflaster oben drauf. AI hilft wahnsinnig viel. mittlerweile, haben ein Incident. Früher war das eher so Arbeit von mehreren Wochen, gutes Postmodern zu schreiben. Mittlerweile ist die Guideline sieben Tage. Und am Tag, man hat den Incident, dann ist man eigentlich noch so ein Incident platt. Da passiert nicht mehr viel an so einem Tag, aber am Tag danach ist eigentlich das erste. Ich hole alle Gemini-Transcripts, ich hole alle Fakten, ich habe, schmeiße die in Clot und lasse mir den ersten Draft vom Post-Mortem schreiben. Den review ich dann das erste Mal teamintern. Und dann iterieren wir. Wir haben dann eine Woche Zeit zu iterieren, bis das Post-Mortem gut genug ist, ⁓ das in der großen Gruppe zu präsentieren. Das sind dann wirklich Artifacts, die sind super spannend zu lesen. Also das ist einmal, wenn man präsentiert. Man will sicherstellen, man präsentiert da wahnsinnig hohe Qualität, weil bis zum CEO sind da alle anwesend, die dein Post-Mortem lesen. Also 150 Leute lesen dein Post-Mortem. Gleichzeitig ist es auch super interessant in diesem Meeting, weil du liest jede Woche so ein Post-Mortem von anderen Team. Du lernst wahnsinnig viel. Also wie gehen andere Teams mit ähnlichen Problemen um? Lernst du wie funktionieren Produkte bei Mapbox? Das ist der interessantesten Meetings des Operation und Matrix Review Meeting bei Mapbox. sehr intensiv, aber man lernt wahnsinnig viel. Ja, klingt super. Also, das Ziel von einem Postmodern ist ja immer, dass du Action-Items machst, damit du ähnliche Inzidenz in Zukunft verhinderst und früher detektest, Zweifel. Aber genau dieser Fokus, 30 Tage und dann muss es live sein und das ist nicht verhandelbar. Da merkt man dann auch, dass einfach Techies quasi dafür verantwortlich waren. Ja, das ist halt eine Verangerung auf einer kulturellen Ebene. 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. Sagt man ja immer, in Deutschland gibt es viele Unternehmen, die irgendwie so von BWL angegründet werden, die halt ganz anders auf so eine Themen drauf gucken als ehemaliger Entwickler. Man muss auch unterscheiden. Mapbox ist kein Startup, das eine App baut für einen Endnutz, sondern unsere Kunden sind viel automotive, teilweise autonomes Fahren ist involviert. Wir dürfen uns keine Fehler erlauben. Deswegen gibt es diese strenge OPEX Kultur, über die nicht verhandelt wird. 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 erwartet, dass man da mitzieht und dass das so sieht. Und da muss ich tatsächlich, das war ein Step-up von meiner, von den vorherigen Stellen, die ich hatte, da musste ich wachsen, ⁓ da mitzuhalten. Ja, cool. Ich glaube, wenn man einmal so eine Kultur miterlebt hat, kann man ja immer zehren sozusagen. weiteren, in der weiteren Karriere. Ja cool. Das war sehr spannend. Haben wir alle Themen adressiert, die du so auf der Agenda hattest, Uli? Ja, 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, 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 zum 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 Bugticket ist ein bisschen anders als ich ihn kannte. Man löst nicht nur, wenn man macht einen Pro Request und löst das Problem, sondern man trifft sich erstmal, also man kriegt ein Ticket. und geht dann auch einen sehr strukturierten Prozess durch, ähnlich wie beim Post-Mortem, ⁓ das Ticket zu verstehen. Also es sind im Wesentlichen vier Schritte. Man produziert auch wieder ein Textdokument. Also man verlässt Chira, geht zu Google Doc. Das ist ein festes Template, das man verfolgt wie beim Post-Mortem. Was ist die Kundenerwartung? Was ist die Actual Behaviour? Also da formuliert man wieder einen klaren Paragraph, unterstützt das mit Beweisen, also Screenshots, wie was passiert. Dann die dritte Frage, do we agree this is a problem? Die ist sehr, wichtig, diese Frage. Man denkt immer, wenn der Kunde sagt, ist ein Problem, ist doch klar, dass es ein Problem ist. Aber oft hat man ja so, naja, das System funktioniert ja, wie es funktionieren soll. Aber der Kunde ist trotzdem nicht glücklich. Deswegen ist der Bereich sehr wichtig. Ist es ein Problem oder ist es kein Problem? Genau, und dann geht es über in Why does the system behave this way? Also eine Erklärung, warum haben wir diesen Bug. Und das ist dann ähnlich wie die 5-Y-Section in post-mortem. wenn meine Erfahrung ist, wenn man, also wir betreffen uns dann zwei bis drei Entwickler, inklusive ⁓ und wir geben so ein Dokument durch. Wir bereiten das mit Claude vor. Also wir nehmen das Bug-Ticket, arbeiten das mit Claude-Code auf und lassen uns einen Draft schreiben für dieses für dieses RCA Dokument und reviewen das. Wir machen aber die Pause dann immer, does the system behave this way? Der letzte Schritt ist, wie der Fix aussieht. Den lassen wir Cloud nicht machen, weil dann fokussiert man sich in der Regel auf die Lösung, ohne das Problem gründlich verstanden zu haben. Und wir fokussieren uns dann immer auf das Problem, weil unsere Erfahrung ist, wenn das Problem wirklich sauber herausgearbeitet ist, dann ist der Fix ganz einfach. Dann ist der Fix in der Regel mit Cloud. Wenige Schritte, aber es geht sehr viel Zeit rein in why does the system behave this way. Das zu verstehen. Man muss auch verstehen, das System, was wir own, ist ein Routing Engine mit vielen, vielen Nebenkomponenten. Es ist super komplex. Ich wollte gerade sagen, eine gewisse Unkomplexität. Genau, und das zu verstehen. Also der Artifakt ist wieder das geschrieben Dokument. Aber diese RCA Sessions, die müssen in Person stattfinden. Also man trifft sich wie in einem Incident Call in Person. In der Vergangenheit haben wir gesehen, dass wahnsinnig viele Diskussionen in Schere passiert, Comments. Tickets werden von einem Team zum nächsten Team geworfen. Euer Problem. Mit diesen RCA Lösungen löst man das. Man holt alle relevanten Leute ins Meet-In rein. Alle sind da, alle müssen sich Zeit nehmen. nimmt sich in der Regel so 90 Minuten Zeit dafür. Und man sucht nach Beweisen. wenn einer sagt, das ist nicht in meinem Team, sondern in deinem Team, dann okay, show me. Beweis mir, wo das Problem ist. Und dann macht man Screenshots, fügt das in das RCA-Doc hinein und so arbeitet man sich Stück für Stück an das Problem ran. Dadurch wird klar, wo ist das Problem. Am Anfang, wenn wir so ein Ticket bekommen bei uns, nie klar, ist das im SDK? Ist das im Routing Engine Team? Es ist ein Dataproblem vom Roads Team. Es wahnsinnig viele Bereiche, wo so Problem entstehen kann, wenn die Route nicht passt. Und da sind diese in-Person-Meetings wahnsinnig hilfreich. Und so kann man sich dann die Lösung herangearbeiten. Genau, Claude unterstützt uns halt wieder, ⁓ einen initialen Draft zu machen von dem Dokument. Dann der finale Draft. Am Ende muss das Dokument scharf sein. Der letzte Schritt ist dann ein Message an den Customer, die der ⁓ approven muss. In all den Schritten ist AI voll involviert, die Formulierung zu machen und dann letztendlich den Fix auch zu machen. Genau, und das ist eine Art von, auch wie der Opex Culture, die ich vorher so nicht kannte, dass man so mit Bucket Tickets umgeht. Man stellt dadurch sicher, dass Probleme langfristig gelöst sind. 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. Ja, ist irgendwie, zum Beispiel, bringt das Thema Zero-Bug-Policy nochmal auf ein ganz anderes Level, sozusagen. wenn du für jeden Bug so einen 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. Wann hat zum anderen und wann hat irgendwie zum dritten? Und das ist einfach ausgeschlossen durch den Prozess. Das klingt auch sehr, sehr, sehr, sehr cool. Ja, zu Zero-Bug-Positiv vielleicht noch ein Wort. Also die RCA's haben auch häufig das Ergebnis, 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 Bucket Tickets, die den gleichen Root Cause haben, zu bündeln. Und dann hast du Argumente für das nächste OP-Plan, also Mapbox, operiert in diesem Operational Planning Modus. Hey, ich habe hier 30 Bucket Tickets, die haben alle den gleichen Root Cause. Es erfordert den System Redesign. Hier ist der Custom Impact ganz klar dokumentiert. Ich habe hier all meine RCA's geschrieben schon. Und das gibt mir wieder Futter um einen größeren System Redesign. zu verteidigen in einem Operation and Planning Meeting. Wir können nicht alle Bugs lösen, aber die RCA sind es trotzdem wichtig, ⁓ den eigentlichen Root Cause und den System Redesign zu justifieren. Ja, macht total Sinn. Cool. Hört sich spannend an. Ich glaube, es ist halt super viel Disziplin, dass man da drin steckt. Ich weiß nicht, ob man es dann immer noch so spannend findet, weil es anstrengend ist. Es ist super spannend, weil eben diese Disziplin da ist. Es ist nicht immer an Tisch gekehrt. Du brauchst eine spezielle Schlagleute. glaube, ist halt, wenn ich gerade überlege, Sebastian hat ja gerade gesagt, so Zero-Bug-Policy, ich finde, das greift halt viel zu kurz. Das ist halt eigentlich eher, also das ist halt viel mehr in der Kultur verankert, quasi Technical Excellence oder Operational Excellence und das braucht dementsprechend ganz andere Leute, wohingegen so eine Bug-Policy eher als man oft nur auf einer Prozessualen-Ebene halt irgendwie greift. Das haben wir alle schon halt irgendwie, schon zwei oder drei Mal 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. 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 durchzuexerzieren in der Kultur, die da nicht drauf passen würde, also das jetzt einzuführen, ist glaube ich ein Riesenschift, weil es eben nicht nur ist, jetzt lass uns mal halt irgendwie die Bugs auf Null bringen, sondern das ist ein anderer Schnack, wie man im Norden sagen würde. Also braucht das volles Commitment von Leadership. Ich kann total verstehen, wenn ein kleineres Start-up andere einen Fokus hat, mehr auf Revenue. Aber bei Mapbox ist eben Leadership ganz klar der Custom Impact. Es dreht sich alles immer ⁓ Customer Impact, ist der Customer Impact. Das startet jede Konversation und das priorisiert dann ganz klar. das, ja, ich kann total verstehen. Ich glaube, dieses Modell funktioniert nicht für alle Firmen. Ja, es orientiert sich sehr stark an eurem Kontext und ich glaube dahingehend ist es halt the right pick. absolut. Würde ich auch sagen, wenn eine Firma, eine Infrastruktur wie Mapbox zur Verfügung stellt, nicht so stark auf operational excellence achtet, dann wird es schwer auch da hinzukommen. Also ich glaube, den Umkehrschluss kann man auch bewagen. 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, wie Mapbox als klassisches, amerikanisches, ja nicht mehr Start-up, sondern Scale-Up, würde man wahrscheinlich bei uns sagen, mit AI umgeht und wo da jetzt die bottlenecks sich verschoben haben. Viel darü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, es immer darum geht, welches Tool dich zuletzt irgendwie mal wieder enttäuscht hat, so ein What-the-fuck-Moment und aber auch, für dich gerade der heißeste Scheiß ist. Ja, welches? Ich glaube, ich kann die Frage mit einem Tool beantworten. Das ist zuletzt Rovo AI. Die hat mich total begeistert und total enttäuscht gleichzeitig. Kennt ihr Rovo AI von Atlassian? Ja, das ist einfach das AI-Tool von Atlasion in Jira integriert. Als ich gesehen habe, macht total Sinn, in Jira AI zu integrieren. Das erste Mal habe ich es benutzt vor ein paar Monaten. Du hast diese Tickets, das ist schon ewiges Thema, Tickets sind vielleicht strukturiert, vielleicht gefrieben. kannst Leuten noch so oft sagen, bitte strukturiert die, bitte besser. Es hat nie richtig funktioniert. Atlasion hat einen Button eingebaut und strukturiert die abhängig von Den Comments, die es schon gibt, das Ticket ist total sauber. Und es war so wow, endlich. Ich kann mir diesen Kommentar sparen, ich brauch nur 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. einem Kauderwilsch zu einem strukturierten Ticket. Habt toll gemacht, AdLashen? Das ist wirklich guter Mehrwert. Und dann wollte ich es weiter nutzen. Wie gesagt, man muss... relativ viel Reporting beim Mapbox machen. Einmal die Woche muss ich für größere Initiativen kurze Berichte schreiben. Da ist es perfekt. Ich habe alle Infos in Rovo, in Atlasion, in Chira. Ich nutze Rovo, ⁓ meine Summaries zu schreiben. Also das sind so halbe Seiten etwa. Weil der Kontext ist da und da war ich dann echt enttäuscht. Also es hat all den Kontext, alle Infos und die Texte, rauskamen. habe lange versucht mit verschiedenen Prompts. Das war einfach nur eine Zusammenschachtelung an Tickets, was dann als Text rauskam. Es konnte nicht mal von der Initiative auf Epic, auf Task runterbrechen, sondern es immer auf der Initiative geblieben, wo ich so, okay, da hättet ihr mal eine Chance. Ich hoffe auch, Sie entwickeln weiter, was ich dann gemacht habe. Ich bin zurück zu Claude gegangen. Hey Claude, hol den Kontext hier raus. Und Claude ist dabei, mal weiter gute Texte zu schreiben, die ich dann habe, ⁓ sie zu refine. Da sehe 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, cool, danke dir. Und dann letzter Punkt, und das haben wir ja vorhin schon so bisschen drüber gesprochen. Hast du noch eine kleine Prediction vielleicht? Ja, ich habe das eigentlich das Thema, was wir besprochen haben, wie geht Code Review weiter? Also was ist die Zukunft von GitHub? Ich habe keine klare Prediction, mein Bauchgefühl ist, wir pushen bald eher zum Main Branch. Der Review-Prozess in der Form wird vorbei sein. das ist so ein bisschen... Ich sehe ein Problem, aber ich sehe nicht ganz klar die Lösung. Ich hoffe, mir GitHub kommt in die Brust und löst das für uns. Alles klar. Vielen Dank, Uli. War wirklich cool. Also abgesehen davon, mal wieder mit dir zu sprechen, was immer schön ist, aber auch super spannend, was du von Madbox erzählt hast. 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, ⁓ zu gucken, wie habt ihr dann das Reviewproblem gelöst etc. Total interessant. Ich habe das Gefühl, all den Themen jetzt, 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. Ich habe Gefühl, in einem halben Jahr ist das gelöst. Dieses ewige Problem, organisieren wir Knowledge and Confluence. glaube, all diese Probleme sind in einem halben Jahr gelöst. Wir sind total spannend in Zeit jetzt. Ich kann es nicht erwarten, halbes Jahr zurückzuschauen. Wo stehen wir jetzt? Wir bauen viele Prozesse jetzt rum ⁓ 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 freue ich mich auf ein halbes Jahr, ⁓ das erneut zu besprechen. Plus eins. 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 Show Notes. 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.hmze.techt schicken. Vielen Dank für deine Zeit. Wenn es dir gefallen hat, abonniere den Podcast. Bis zur nächsten Folge.