# Ocell AI Transformation: Beyond Engineering

**Podcast:** HMZE
**Published:** 2026-04-30

## Transcript

Also ein Beispiel, ich weiß gar nicht, ob ich das sagen darf, aber ich erzähle es einfach mal.
Zum Nutz schneiden wir es raus.
Unser CEO tatsächlich.
Herzlich willkommen zu einer neuen Episode 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 North.io.
Und ich bin André Neubauer, CTPO bei Trusted Shops.
Schön, dass ihr wieder da seid.
Heute ehrlich gesagt wieder zu AI Beyond Engineering, also der Gedanke alles auf einer Plattform End-to-End.
Genau, Alex Thiele von Ocel aus München ist heute zu Gast und berichtet auf begeisternde Weise von der AI-Transformation, die die Firma gerade durchläuft.
Genau, wieder AI-Transformation Beyond Engineering, aber wieder anders als bei ZipGate oder der Getaway Group.
Seid gespannt und freut euch auf die nächsten 60 Minuten.
Herzlich willkommen, Alex.
Wir freuen uns, dass du da bist.
kennen uns von nur einer relativ kurzen Episode, mal im Recruiting-Kontext.
Damals sind wir nicht zusammengekommen, aber sind auf LinkedIn immer in Kontakt geblieben und haben uns auch ausgetauscht.
Und daher weiß ich, dass du auch sehr spannende Themen gerade vorantreibst, die natürlich perfekt in unseren Podcast passen und freue mich insofern ganz besonders, dich heute bei uns begrüßen zu dürfen.
Insofern herzlich willkommen.
Und stell dich und gerne auch Ocell, die Firma, bei der du gerade arbeitest, einmal kurz unseren Zuhörern vor.
Ja, vielen Dank für die Einladung.
Genau, Alexander Thiele, mein Name, bin Head of Engineering bei Ocell.
Ocell ist ein Startup in München.
Und was wir machen, ist wirklich ganz spannend.
Und das ist auch ein Thema, was mir irgendwie ans Herz gewachsen ist.
Wir machen Waldwirtschaft oder wir sind ein Startup über die Waldwirtschaft.
Man kann sich natürlich viel darunter vorstellen oder auch nicht.
Wie sind, wenn man das in die Textsprache übersetzt, Jira für Förster, kann man vielleicht sagen.
Also die Planung im Wald, wo welche Bäume müssen gepflanzt werden, wie werden die gepflanzt und was muss ich machen und wo muss ich es machen.
Das ist alles Geolocation-basiert.
Spannendes Thema auch Offline-First, weil die Förster sind natürlich im Wald am Arbeiten.
Die LKW-Fahrer, die die Bäume abholen, fahren in den Wald und müssen schauen, wo die Polter, also wo die Bäume zu finden sind.
Deswegen ist Offline-First bei uns auch ein starkes Thema.
Ich finde per se erstmal Jira für Förster viel cooler als Uber for X.
Also von daher schon mal absoluter Pluspunkt.
Das ist mal schwer zu erklären, wenn man irgendwo startet.
Aber das ist wirklich die Software, die die Förster oder die Leute im Wald, auch die Besitzer der Wälder, halt benutzen, um einfach den Wald täglich zu planen.
Was ist der Benefit im Vergleich zu einer nicht-digitalen Experience?
Genau, also wir konkurrieren tatsächlich teilweise auch noch mit der physischen Karte, also unser Cap.
Unser großer Competitor, sage ich mal, ist auch die physische Karte, weil der Wald, der bewegt sich auch sehr langsam.
Wenn man so überlegt, ein Baum, der wächst ja nicht über fünf Jahre, sondern über eher 100 Jahre oder 80 Jahre.
Und so ist auch die Transformation im Wald, die ist recht, ich würde sagen, recht langsam.
Und wir versuchen das natürlich zu verbessern oder wir versuchen natürlich den Förstern oder die Waldbesitzer auch mehr Produktivität reinzubringen durch digitale Tools.
Ich habe im Vorfeld kurz auf die Webseite geschaut und was mich gecatcht hat, war der Slogan Digital Twins für den Wald.
Also quasi im Endeffekt.
Ich habe das mir so vorgestellt, ihr simuliert halt einfach einen Wald und könnt dann halt auf Vorspulen klicken.
Kann man sich das so vorstellen?
Teilweise, der digitale Twin ist erstmal wirklich eine digitale Kopie vom Wald zu machen.
Also der Wald ist teilweise dann über 10.000 Hektar, also kein kleiner Wald, sondern wirklich auch große Wälder.
Und diese wollen wir natürlich auch digital abbilden.
Und das bringt natürlich Komplexität mit sich.
Und ein Feature ist halt die Intelligenz, die wir auch entwickeln, auf die wir auch recht stolz sind.
Wir haben ein eigenes AI-Modell entwickelt und trainieren das auch, um wirklich auch die Bäume zu erkennen.
Also wirklich die Baumarten, die Baumtypen, die Stämme vom Baum, wie dick der Baum auch ist und das alles von Rasterdaten.
Also wirklich auch einfach ein Luftbild.
Luftbilder, alles klar.
den App-Benutzer oder Website-Benutzer darzustellen und zur Verfügung zu stellen, dass sie halt wirklich auch auf Datengrundlage ihre Arbeit tun können im Grunde.
Sehr cool.
Meine Frau arbeitet bei Live.io.
Die arbeitet viel mit Satellitendaten.
Das hätte mich jetzt interessiert, weil Satellitendaten sind zumindest kommerziell noch nicht hochauflösend genug, um sowas machen zu können.
Aber Luftbilder bieten natürlich die Auslösung.
Korrekt, genau.
Wir nutzen tatsächlich auch teilweise sehr scharfe Bilder, teilweise drei bis vier Zentimeter pro Pixel, aber auch mit unschärferen Bildern oder schlechteren Bildern mit teilweise 20 oder 30 Zentimeter Pixel pro Pixel.
Und es gibt auch die Bilder von Bundesländern, die dann auch vor free bereitgestellt werden.
Im Geoportal immer.
Genau, im Geoportal.
Und die kann man auch nutzen, um auch solche Bäume zu erkennen.
Wir machen das schon teilweise auch deutschlandweit.
Also wir haben auch zum Beispiel LNW und andere Staaten, wo wir wirklich jeden einzelnen Baum erkennen können, halt auf Bundeslandebene, was total extrem cool ist.
Sehr spannend.
Ja.
Dann hüpfen wir mal rein.
Würde ich auch sagen.
Unser erster Programmpunkt sozusagen ist ja immer der TechStack, also der Status quo, wie du gerade arbeitest.
Genau.
Erzähl gerne mal, was du so nutzt.
Genau.
TechStack, also mein eigener TechStack vom Team ist hauptsächlich Flutter.
Kennt ihr Flutter zufällig?
Ja, ja, klar.
Auch schon benutzt?
Aber ich glaube, wir nutzen es auf Arbeit, also für unsere Produkte.
Aber ich glaube, dem einen oder anderen, der jetzt gerade zuhört, dem sagt das vielleicht nichts.
Also kannst du irgendwie versuchen, mal Elevator Pitch in der Minute, warum man das nutzen sollte.
Ja, also ich bin auch, habe ich in der Intro vergessen, ich bin auch Google Developer Expert in Flutter, also ein bisschen auch mit Google verwandt, verbunden und da arbeite ich auch ein bisschen mit dem Team dran, um Flutter zu verbessern.
Was Flutter ist, ist im Grunde eine Multi-Plattform-Framework, wo man einen Code schreibt und den Code kann man auf verschiedenen Plattformen ausführen, unter anderem auch iOS, Android, Web, Microsoft, also Windows in dem Fall oder Linux oder auch Embedded, was sehr spannend ist.
Vorteil natürlich, klar, eine Callbase und mehrere Plattformen.
Wir nutzen tatsächlich Flutter für Android, iOS und Web.
Das heißt wirklich auch für das Web haben wir die gleiche Flutter-Version, was aber auch Schwierigkeiten mit sich bringt.
Zum Beispiel Offline-First, habe ich ja genannt.
Das heißt, Offline-First heißt ja auch, dass wir die Daten, mit denen der Nutzer arbeitet, laden wir herunter und mit den heruntergeladenen Daten arbeitet man.
Und da habe ich mal einen Talk auf der Konferenz in Berlin gemacht, kann man Google, glaube ich, Flatterkon, Offline First, kann man mal schauen.
Und da ist sich, also Vorteil, Nachteil, sage ich jetzt mal, die gleiche Funktionalität haben wir auch auf Web.
Das bedeutet, also wenn man sich bei Web einloggt, man hat ja meistens das Gefühl, wenn man jetzt sich irgendeine App einloggt, dann sind die Daten sofort da.
Man macht ja eine Serveranfrage und dann kommen die Antworten zurück und bumm, dann ist das Ergebnis da.
Bei unserer App, bei Offline First, ist es aber erstmal so, dass wir nach dem Login erstmal alle Daten herunterladen.
Das heißt, in die lokale Datenbank, auch im Web.
Und das bedeutet, dass halt die Web-Datenbank recht voll ist und das dauert teilweise 10 bis 1 Minute, also 10 Sekunden bis 1 Minute, bis man sich einloggen kann, weil wir ja schon mit recht vielen Daten arbeiten.
Genau, das ist einmal Frontend des Flutter.
Hauptsächlich im Backend haben wir Node-Server, ganz normal Express-Server.
Haben noch ein bisschen Past-Backend, falls man das noch kennt von früher.
Sind auf DigitalOcean ganz entspannt.
Nutzen Cloud hauptsächlich.
Das ganze Team nutzt Cloud.
Nicht nur unser Engineering-Team, sondern auch wirklich die komplette Company, was glaube ich speziell ist, oder sehr neu ist.
Ich kann mich nicht vergleichen jetzt mit anderen Unternehmen, aber wir nutzen wirklich alle Claude.
Und das 100% für alles.
Und dann Claude Desktop?
Also jetzt die Nicht-Entwickler?
Oder auch Claude Code?
Ja, also verrückterweise, ich bin natürlich ein Entwickler, ich bin hell of an G, ich mache weniger Entwicklungen, aber ich mag das Terminal sehr.
Aber seit der neuesten Version von Claude Desktop bin ich ein richtiger Fan von Claude Desktop geworden.
Und Claude Desktop CLI.
Cloud Desktop Code meine ich.
Habt ihr es schon mal benutzt bisher?
Ich muss sagen, ich bin vor wahrscheinlich zwei, drei Monaten von Desktop, wahrscheinlich zwei, drei Monate von Desktop auf CLI und bin eigentlich ganz happy.
Aber ich weiß, glaube ich, ich weiß auch, was du meinst.
Also so quasi die Mächtigkeit von Cloud in der CLI zu bedienen ist Ich glaube, braucht ein bisschen Erfahrung.
Also ich glaube, gerade Einsteiger finde ich es wahrscheinlich die Desktop-Variante passender.
Aber schieß mal los.
Also was ist dein Take?
Ja, aber nutzt du auch Cloud-Code-Desktop?
Ja.
Also okay.
Weil was mir jetzt sehr gut gefällt an Cloud-Code-Desktop ist vor allem die Preview.
Die gab es wahrscheinlich damals noch nicht.
Kann ich mir vorstellen.
Genau.
Warum ich es so toll finde.
Im Grunde ist es ja das gleiche wie die Cloud CLI, das ist wirklich ein Terminal.
Im Grunde ist es das gleiche.
Du kannst auch einen Automode machen.
Aber die Preview ist halt so toll, weil du siehst, vor allem bei Frontend-Anwendungen kann man sofort das Ergebnis sehen.
In der eigenen Preview von Cloud Desktop hauptsächlich.
Da ist ein MCP-Server hinter, der automatisch integriert ist.
Das heißt, wenn du Prompts, dann siehst, dann macht Cloud automatisch Screenshots.
Das liest die Network Requests und die Responses automatisch.
Es kann die Logs lesen, wirklich von der Frontend-Anwendung.
Das heißt, das ist so ein bisschen mehr integrierter.
in den Lifecycle.
Man kann sich das Gleiche auch mit Claude C.
Live schaffen, klar.
Aber das ist halt out of the box und du kannst auch sogar selecten, was ziemlich cool ist, was Lovable auch gemacht hat oder macht, wo man auch, wenn man im Frontend sieht, man kann dann den Inspector nehmen und bestimmte Elemente anklicken und sagen, hey, das gefällt mir noch nicht, das ist ein bisschen komisch und der hat dann eine Referenz zur UI sofort, was mir tatsächlich echt gut gefällt.
Ich muss gleich nochmal im Nachgang nachschauen.
Ich bin mir nicht sicher, ob das das gleiche Rendering ist wie bei Claude Coburg.
Da ist das Rendering halt sehr bescheiden.
Also alles, was so visuell und so ist, weiß nicht, was dahinter liegt für eine Engine.
Ich habe das auch mal durch Zufall gesehen.
Fand ich am Anfang nicht schlecht, aber quasi es ist halt einfach nicht wahrheitsgetreu.
Obwohl.
Im Web.
Da ist die Frage, welche Browser-Engine dahinter liegt wahrscheinlich.
Korrekt, genau.
Es ist auch nur ein Browser-Preview.
Coburg ist ja auch in so einer eigenen Sandbox so ein bisschen und das ist so ein bisschen eingeschlossener.
Aber das Coburg wird hauptsächlich von unserem HR-Team oder vom Customer Success Team oder Product Team verwendet.
Code auch.
Aber da eher auf Repositories, die halt die Engineers vorbereitet haben und die halt Produkt nutzen.
Und da ist es dann einfacher, auch einfach anderen zu sagen, hey, lade dir die Cloud Desktop App herunter.
Und hier nutz mal, hier, also der erste, ich kann mich noch erinnern, das erste Mal, wo ich Produkt so ein bisschen gesagt habe, hey, guck mal hier, Cloud, aber du musst das Terminal nutzen.
Und da kam erst mal B-Terminal.
Und das ist natürlich viel einfacher jetzt zu sagen, hey, lade dir Cloud Desktop runter.
Aber du musst noch deinen GitLab-Zugang verbinden mit SSH-Key und dann rastet natürlich erstmal aus, wenn die sagen, was ist denn eine SSH-Key und muss ich das jedes Mal machen und wie gehe ich das bei GitLab rein und das war immer ganz witzig.
Ja, spannend.
Genau, das erinnert mich gerade an.
Ich glaube, Markus Andretzak hat gerade geteilt, dass the next big thing sozusagen ist der geteilte Kontext in der Firma.
Also genau das, was du beschreibst.
Und er beschreibt auch genau dieses Problem, dass Leute, die bisher nicht mit Coding oder der Infrastruktur zu tun hatten, auf einmal GitHub oder GitLab Access...
und über diese Hürde einmal drüber springen müssen.
Aber ich gebe dir voll recht, das ist wahrscheinlich eine deutlich geringere Hürde und es muss ja eigentlich nur einmal eingerichtet werden, als mit einer CLI zu arbeiten, mit der Desktop-App einmal irgendwie Git-Account verknüpft und fertig.
Dann kannst du halt auf das Repository zugreifen, die Skills, Daten, was auch immer.
Ja, aber das machen wir mittlerweile auch nicht mehr.
Es ist auch schon outdated seit einer Woche.
Okay, bin gespannt.
Es verändert sich ja so schnell aktuell, dass man auch gar nicht mehr hinterherkommt, muss man wirklich sagen.
Und wenn ich jetzt mit einem Kollegen rede, der sagt jetzt, der PI-Agent, weiß gar nicht, wie es ausgesprochen wird.
Das ist jetzt, Claude ist das Geschichte, PI-Agent ist the future und von daher, ich komme auch tatsächlich gar nicht mehr hinterher und ich hoffe, dass es sich irgendwie so ein bisschen mal ein bisschen langsamer wird, die Entwicklung, damit man sich so ein bisschen auch mit dem Team auch was einlassen kann und nicht jede Woche eine neue Richtung gibt oder hey, probier mal das aus und vielleicht ist das die Richtung.
Aber was wir jetzt seit einer Woche oder zwei Wochen machen, ist wirklich hauptsächlich Cowork, auch für Produkt und für andere und dort haben wir Organisational Plugins.
Das heißt wirklich ein Plugin für die Organisation, die wir auch bereitstellen über GitHub.
Und da braucht man auch keinen SSH-Key und alles mögliche dafür.
Das macht dann Cloud selber.
Das heißt, man kann die einfach über GitHub bereitstellen und deployed wird es dann über Cloud.
Und dann kann man tatsächlich sich einfach das Plugin auswählen.
Also Produkt gibt es ein Produkt-Plugin.
Da können die dann einfach auch mit Tickets anschauen und Tickets durchsuchen, Verbindung finden, Roadmap-Planning machen.
All das können die quasi über so ein Plugin dann auch machen.
Interessant.
Das ist tatsächlich was, da muss ich mich auch nochmal tiefer mit beschäftigen.
Das habe ich mir noch gar nicht so sehr angeguckt.
Superspannend, gerade weil es die Barriere ja deutlich senkt nochmal.
Ich möchte nur kurz noch, und dann André, kannst du mich outen.
Ich bin ja großer Pi-Fan.
Also das ist so mein Go-To-Agent.
Ich mag das halt, dass ich mir das customizen kann und arbeite am liebsten mit Pi in meinem Kodex.
Plan sozusagen.
André?
Ja, ich muss gestehen, Plugins gehört nicht genutzt.
Ich bin großer Fan von Skills.
Kriegst du Skills und Plugins quasi so mal gegeneinander?
Also wofür das eine und wofür das andere?
Also kann man sich fragen, was ist der Unterschied zwischen Plugins und Skills?
Ja, genau.
Und Plugins ist einfach eine Ansammlung von Skills.
Mehr ist das ja gar nicht.
Und wenn man sich ein Skill anschaut in einem Repository, dann ist das ja einfach nur in Formius Cloud oder OpenCode oder was auch immer, Gemini-Folder, ist das einfach nur ein Skill, der zum Beispiel eine GitLab-API beschreibt zum Beispiel oder wie man ein Idea-Ticket schreibt.
Das ist ein Skill von mir.
Und wenn man jetzt ein Plugin macht, dann ist das eigentlich nur mehrere Skills gebündelt einfach nur.
Mehr ist das gar nicht.
Okay, und wird ausgeliefert über das, aber wird da nicht ausgeliefert über das Skill-Repository?
Weil das kann man ja sich als Firma anlegen.
Ich glaube, wir reden über das Gleiche.
Es ist ein Plug-in-Repository.
Vielleicht haben sie auch den Naming geändert, ich bin mir nicht sicher, aber aktuell heißt es Plug-in-Repository, aber das ist tatsächlich das Gleiche.
Okay.
Aber am Ende ist es ja eigentlich genau das, was man möchte.
Man hat bestimmte Themengebiete, sage ich mal, die für bestimmte Abteilungen relevant sind und da gibt es verschiedene, also die sind immer verschiedene Klammern, also sprich, du hast bestimmte Skills, die du zusammenklammerst zu Plugins, also von daher vom Konzept her macht es schon Sinn, wie du auch beschreibst, für das Product Team gibt es halt dann das Product Plugin entsprechend fürs Engineering, das Engineering Plugin wahrscheinlich oder keine Ahnung, dann gibt es Frontend oder Marketing oder whatever.
Ja, Engineering ist eher auf Code-Ebene, das heißt, die machen ihre eigene Skills im Repository.
Aber wir haben tatsächlich seit letzter Woche oder vorletzte Woche haben wir auch unsere UI-UXlerin, die einen eigenen Skill geschrieben hat, mit Cloud natürlich, auch mit Hilfe, aber das hat super funktioniert und das dann auch, dann habe ich da ein bisschen geholfen mit dem GitHub-Einrichten und dann konnte auch gepusht werden und so weiter und das alles liegt jetzt ein Skill oder ein Plug-in diesmal für UI-UX und für User-UX.
Was war das?
Userfragen.
Also...
User Research wahrscheinlich.
User Research Fragen, korrekt.
Genau, User Research Fragen und dann kann man zusammen mit dem Plugin oder dem Skill kann man dann brainstormen, wie man Kunden befragen kann oder welche Fragen man stellen kann.
Und das ist so ein Custom Skill, der dann auch einfach gepublikt wurde und der wird dann benutzt, um einfach mal zu brainstormen, was echt super ist, finde ich.
Und habt ihr da irgendeine Governance auf dem Thema oder darf jeder einen Skill bauen oder guckt ihr, dass die Skills eine gewisse...
Qualität, denn ich meine nicht technische, sondern fachliche Qualität haben?
Also wir sind ein kleines Startup, wir sind 40, 50 Leute, von daher ist es noch gar nicht so groß, von daher darf jeder alles machen, wenn er möchte und wir wollen auch eigentlich so die Hürde, also ich zumindest, die Hürde wegnehmen, um da irgendwie was zu kontrollieren.
Aktuell will man ja erst das supporten, probier es aus und natürlich schaubern darauf, ob irgendwelche Credentials geshared werden oder sonstiges natürlich, aber Aber sobald da nichts Kritisches drin ist, kann natürlich erstmal alles gepusht und deployed werden.
Da sind als Ansatz.
Tatsächlich kann ich das auch jedem empfehlen, auch als Engineer oder als Head of oder CTO, einfach mal mit Produkt sich hinzusetzen und zu schauen, hey, was können wir denn zusammen machen, damit wir eure Arbeit erleichtern.
Wir machen auch so ein Planning Meeting jede Woche.
Was wir auch schon gemacht haben, ist so ein Workflow geschrieben, ein Command kann man auch sagen oder auch ein Skill neuerdings auch, der einfach eine Abfolge von Aufgaben macht für Produkt und sich da zum Beispiel die aktuellsten Tickets oder die aktuellsten Ideen rauszuholen und zu schauen, hey, wie sind die denn specified?
Fehlt da vielleicht was?
Fehlt da was für den Engineer?
Und dann haben wir einen Sub-Agent gemacht, der zum Beispiel ein Flutter-Engineer ist und der schaut sich dann den Text an und schaut sich, hey, ist das eigentlich klar für mich, was da drin steht?
Kann ich mit dem arbeiten, was da drin steht?
Oder brauche ich noch irgendwie die Specification?
Oder so ein UX-Spezialist, ein Agent im Endeffekt, der halt schaut, okay, hey.
habe ich da ein UI drin?
Ist da irgendwas unklar?
Also da kann man auch tatsächlich so ein bisschen Produkt helfen und sagen, hey, wenn ich jetzt eine Idee schreibe, dann kann ich ja mit Sub-Agents schon eigentlich 90 Prozent der Fehler finden und fixen, ohne dass ich jemand anderen konsultieren muss.
Ja, da die Frage, das hatten wir, glaube ich, auch mit Lukas von Zipgate und das ist fairerweise auch ein...
Eine Erfahrung, die ich selber mit meinem PM und Head of Engineering gemacht habe.
Auch die Tickets meines Erachtens nach kann man ja mehr und mehr in der Kollaboration mit dem Agenten, welchen auch immer man nutzt, erstellen.
Also sprich, wenn du den Kontext des Produktes drin hast, idealerweise auch den Code drin hast.
Dann kannst du definieren, wo du gerne hin möchtest, was das Ziel ist.
Dann kannst du das Feature definieren und dann auch ja runterbrechen.
Macht ihr das schon?
Also weißt du, ob ein Produkt bei euch schon so arbeitet?
Wir machen das, also wir versuchen, wohin ich gerne möchte, tatsächlich ist, gar keine Dev-Tickets mehr zu haben.
Und ich glaube, ich weiß nicht, vielleicht ist es noch zu früh dafür, aber warum bricht man am Ende runter?
Warum bricht man das in kleinere Dev-Tickets?
Man kann natürlich so ein bisschen scopen, je nachdem, welche Ownership man hat.
Also wenn man jetzt so schaut, unser Frontend-Entwickler, der ist ja jetzt nicht nur Frontend, der macht jetzt auch Backend.
Das heißt, wir gehen eigentlich Richtung, alle machen Fullstack und die Ownership über eine Produktidee wird jetzt von vorne bis hinten durchgemacht, ohne eigentlich ein Dev-Ticket.
Am Ende kannst du die Idee oder die Produktidee eh nur komplett verifizieren.
Also warum bricht man es dann runter, wenn die Entwicklungsgeschwindigkeit eher nach oben geht?
Und das ist, glaube ich, das, wohin.
Also meine Meinung ist, dass weniger Dev-Tickets, weniger klein gebrochen, mehr Produktarbeit, mehr auf Produkt die Sicht zu haben und dann halt an den Iterationen zu verbessern.
Das heißt, wirklich die technische Iteration mit der AI.
dass man da einfach besser wird und schneller wird.
Zum Thema auch Veränderungsgeschwindigkeit meintest du ja vorhin, dass du dir wünschen würdest, dass es mal ein bisschen langsamer wird und man mal sagen kann, irgendwie so settelt sich das.
Ich befürchte, das Gegenteil wird der Fall sein.
Also Anthropic zeigt ja gerade, die sind total inzentiviert, einfach immer schneller zu releasen und solange nicht was grob schief geht bei denen und man, also ich würde sagen, Die Würfel sind noch nicht gefallen, ob da nicht was grob schief gehen kann, weil sind ja schon Dinge auch grob schief gegangen.
Denke ich, dass die die Pace weiter halten und erhöhen werden und fairerweise die anderen, die da mitspielen, müssen ja genauso agieren.
Von daher wird sich das wohl nicht so schnell ändern.
Ja, das stimmt.
Also wahrscheinlich nicht.
Aber ich würde gerne mal durchatmen tatsächlich, persönlich und privat.
Jede Woche kommen da irgendwelche...
Twitter-Ex-Nachrichten, das ist jetzt neu, hier, Claude Design ist da seit letzter Woche oder vorletzte Woche und nächste Woche kommt ein anderer, dann habe ich das andere noch gar nicht angeschaut.
Das ist tatsächlich so viel, dass man da gar nicht hinterherkommt.
Total, total.
Da muss man sich auch seine Boundaries schaffen.
Hatten wir auch schon mal vor ein paar Folgen.
Wie kriegt man es hin, da zu priorisieren?
Womit man sich jetzt auseinandersetzt, womit nicht?
Und auch, dass man genug Zeit für, also...
für die eigene Sanity zurückbehält, dass Sport nicht drunter leidet, Schlaf drunter leidet, alles Freizeit drunter leidet.
Absolut, genau.
Das ist vielleicht auch nochmal ein extra Thema, weil auch ich musste am Anfang, also ich habe eigentlich, würde ich sagen, ganz normalerweise einen ganz guten Rhythmus, um das alles ein bisschen zu trennen und dazu Mindestsport, den ich einfach immer einhalte und da geht auch nichts drüber.
Aber auch mir viel ist am Anfang wirklich schwer, das einzuhalten.
Jetzt habe ich einen ganz guten Modus gefunden.
Ja, vielleicht eine eigene Folge.
Ich habe sogar zwei Kinder vielleicht dazu noch und die ist ein Jahr und drei Jahre alt.
Und das ist ja nochmal on top dazu.
Und Sport für mich ist tatsächlich so ein bisschen nebenrangig.
Aber ich versuche tatsächlich einmal die Woche zu gehen.
Also wirklich da mal Zeit zu nehmen und dann muss man einfach gehen.
Ja, meine sind schon ein bisschen älter.
Da klappt es mit dem Sport schon.
schon ein bisschen besser.
Alright, dann haben wir den TechStack einigermaßen gut abgegrast.
Wenn ja, dann würde ich sagen, dann...
Kennt ihr T-Mux?
T-Max?
Ja.
Ich kann es noch nicht, aber unser Data Science Team nutzt es tatsächlich sehr, sehr, also sehr viel und tatsächlich sind auch teilweise Vibe-coded T-Max Extensions rausgekommen und...
Da ist dann so eine heavy use ID rausgekommen oder heavy use Terminal Experience eigentlich.
Und das hat er mal in der in der DASH Class, so heißt unser unser Knowledge Sharing Session, hat es mal gezeigt.
Alle waren tatsächlich mindblown, weil er seine Hotkeys da eingebaut hat und er hat dann quasi die GitLab Tickets mit einer Hotkeys Kombination herausgegeben hat er gezeigt und dann konnte dann sofort prompten und das in den nächsten Terminal starten.
Also innerhalb von zehn Sekunden hat er, glaube ich, zehn Sessions gestartet und hat an zehn Tickets weitergearbeitet.
Es war total verrückt.
Also worauf ich vielleicht nochmal hier nochmal sagen würde, ich glaube, was ich so ein bisschen herausgefunden habe, vor allem von so einem Higher Level vielleicht, dass diese AI-Geschichte ist, so kann man vielleicht vergleichen mit einer IDE.
Vielleicht.
Das kann ich mal in die Runde zur Diskussion werfen.
Weil für jeden ist ja die IDE, sage ich mal, heilig.
Heilig oder ich nutze es, weil es mir gefällt und ich nutze Visual Studio Code, ich nutze Android Studio, IntelliJ und alles mögliche.
Und das erlauben wir ja auch.
Im Endeffekt auch als Tech-Unternehmen oder in dem Management.
Und da sagen wir, hey, ja klar, du sollst das nutzen, was dir am besten gefällt.
Und das Gleiche erlebe ich tatsächlich auch jetzt mit den ganzen LLMs, also mit Cloud, mit Gemini und so weiter.
Von daher haben wir eine Person oder mehrere Personen, die halt eigene Terminal gebaut haben.
Andere nutzen die Desktop-Cloud-Application für Code zum Beispiel.
Andere nutzen ganz normal das Terminal oder auch in der ID selber.
Also es ist so verschieden auch.
Und da will man auch vielleicht gar nicht so einen Blocker.
sagen, hey, wir machen jetzt alles nur die Richtung hier, PyAgen haben wir gerade auch schon gehört.
Das kann man natürlich auch gerne nutzen, wenn man es möchte.
Und dann ist es so ein bisschen auch vom Stack, das gehört auch dazu vielleicht so ein bisschen.
Tatsächlich, wir, was ich, ich habe jetzt rausgehört, dass ihr da mehr Freiheit gebt.
Ich habe nicht, wie das mit Cloud dann noch funktioniert.
Wir gehen eher den Weg der Konsolidierung, weil ich glaube, dass der Vorteil, den man damit hat, größer ist als die Flexibilität, die man dadurch vielleicht verliert.
Also gerade, du hast es ja auch gesagt, wenn du so in den Non-Tech-Bereich halt schaust, aber da gibt es gar nicht diese meinungsstarke Sicht auf, es muss halt das Tool sein, sondern es ist halt einfach das, was halt irgendwie da ist.
Und ich kann mir vorstellen, dass, boah, das ist halt meine Meine Sicht, also meine Opinion, Meinung, ja Meinung ist mir zu schwach, meine Hypothese, das ist das Wort, was ich gesucht habe, ist, dass man mehr gewinnt, wenn man es schafft in einer Firma es zu standardisieren, weil dieser Benefit etwas Durchgehendes zu haben, über die Disziplin hinweg quasi.
Ich glaube, dass du den einzelnen Vorteil halt auffrisst, um es mal so rum zu sagen.
Dass man das halt mit irgendwas covern kann, aber Alex, du hast schon was, schieß mal los.
Lass uns Diskussion haben.
Ich stimme zu, wir nutzen alle Cloud, aber wie man mit Cloud redet, ist ja eine andere Frage.
Ja?
Also wenn, Tmux ist ja nur eine Anseitung von verschiedenen Terminals, die man customisen kann und das ist ja auch ein Terminal, aber auf eine andere Art und Weise.
Cloud Desktop Code ist ja auch eine Art andere.
Art von Terminal, dann hast du das Terminal selber, dann hast du ja IDE mit Integration von Claude.
Ich glaube, das, was, also bin ich bei dir, das, was die UI angeht, ist, glaube ich, also vor allen Dingen im technischen Umfeld, glaube ich, da willst du halt einfach alles Mögliche rund um Produktivität erlauben und vielleicht auch fairerweise sogar Security.
Wir hatten ja auch mal Stefan Schmidt hier, der mit Human was in die Richtung gebaut hat.
Ich finde halt, ich sehe den großen Benefit, die gesamte Firma mitzunehmen.
Und ich glaube, da ist es halt wahrscheinlich weniger relevant.
Aber ich habe den Punkt besser verstanden.
Ich habe gedacht, jeder darf das machen, was er verwendet, was er verwenden möchte.
Und da, glaube ich, lässt man gerade auf der nicht-technischen Seite echt viel liegen.
Du hattest ja vorhin schon gesagt, Plug-in-Skills.
Ja, korrekt.
Wir hatten das Thema auch letztes Jahr im November, glaube ich, gab, wo wir, oder im Oktober sogar, wo wir gesagt haben, hey, jeder darf alles nutzen.
Dann haben wir auch Co-Pilot verwendet oder manche haben Co-Pilot verwendet.
Tatsächlich kam doch auch ein Engineer und der hat dann einfach Co-Pilot-Chat verwendet oder auch das German.
Und dann habe ich auch gefragt, hey, probier doch mal die CLI aus.
Und so, nee, ich möchte gerne lieber in der IDE arbeiten.
Ich so, ja, so musst du es ja nur mal testen.
Mehr will ich ja gar nicht.
Und nachdem er das auch getestet hat, war er ein super Fan von diesen Terminal und Teamworks und der ist jetzt so ein heavy User geworden, einfach zum Ausprobieren.
Also wir hatten diese Phase, der, okay, jeder nutzt alles und gucken, Open Code testen wir mal mit Copilot und hatten tatsächlich schon durchgehabt.
Also den Benefit haben wir auch schon gesehen.
Jetzt sind wir tatsächlich auch eigentlich schon im Hauptteil drin, voll und ganz, würde ich sagen.
Der Hauptteil AI-Transformation bei Ocell, wir haben jetzt schon viel darüber gesprochen, Beyond Engineering nur, und dass ihr Claude mehr oder weniger als Hauptausprägung nutzt, wie auch immer LLM nutzt.
ist es immer Claude und dann Sonnet oder Opus oder so, mit verschiedenen Harnesses, die dann für die Abteilung quasi besser oder eine geringere Barriere darstellen.
Lass uns da vielleicht nochmal einmal so ein bisschen Struktur reinbringen.
Also du hattest mir schon mal geschrieben, dass du auch vorantreibst, dass die ja eigentlich die ganze Organisation gerne auf AI mehr oder weniger oder in diese Richtung transformieren.
Kannst du das vielleicht noch ein bisschen näher ausführen und auch wie ihr das gerade macht?
Ja, also zum Beispiel unser Customer Success Team.
Wir haben also ein großes Onboarding Team, weil wir haben ja auch sehr viele Polygone, mit denen wir arbeiten.
Also wir haben sehr Geolocation, also wir haben auch GeoJSON, falls jemand kennt.
Da ist natürlich dann viel, also Bestände mit drin, also welche Waldflächen und was ist in dem Wald drin?
Gibt es da Kalamitäten oder gibt es da, also das ist das Fachbegriff, wer komme ich jetzt mit an?
Und Wertholz oder also sehr viel, was halt im Wald schon drin steckt.
Und das Onboarding ist halt ein Thema, was bei uns halt sehr unstrukturiert ist oder mit sehr viel unstrukturierten Daten arbeiten muss zum Beispiel.
Und das ist natürlich ein...
perfekter Use Case für, ich sag mal, AI, indem wir versuchen, unstrukturierte Daten auf einen strukturierten Weg zu bringen.
Und deswegen war, also das machen wir jetzt gerade sogar, dass wir Kafka Success tatsächlich mit Cloud Cowork oder auch CDI ausstatten.
Und das ist natürlich die Frage, okay, die Personen, die das meistens nutzen, die haben natürlich dann nicht so viel Erfahrung mit Terminals und so weiter.
Und da muss man auch einfach hoffen, dass da auch einfach Kuriosität einfach besteht, dass man da auch was Neues testen möchte und sagen, hey, guck mal hier, wir helfen dir, wir helfen dir dabei.
Das heißt, wir bereiten diese initialen Skills vor, wir zeigen dir, wie es geht.
Wir trainieren dich dabei, dass du damit quasi arbeiten kannst.
Und dadurch wollen wir quasi am Ende schneller werden und einfacher.
Wir wollen ja quasi helfen im Grunde.
Und das ist das, was wir auch mit Engineering machen.
Das heißt, wir haben bestimmte Themes, mit denen wir arbeiten.
Und die Themes sind zum Beispiel auch, dass wir Customer Success helfen wollen.
Und dadurch wollen wir Tools entwickeln, um einfach das Onboarding von, jetzt um OKR von x Tagen auf y Tagen zu reduzieren.
Das ist dann zum Beispiel auch, wo wir dann mit CX zusammenarbeiten, wirklich auch mit denen in Gespräch geben, hey, wie arbeitet ihr eigentlich und wie können wir euch überhaupt helfen?
Das ist ja auch eine große Frage.
Und das ist dann halt so Stück für Stück, was wir dann machen und versuchen natürlich auch, die Value innerhalb der Company insgesamt einfach zu erhöhen, indem wir einfach alle mit Fähigkeiten ausstatten, auch mal eigene Skills zu entwickeln oder auch beizubringen, wie das alles überhaupt funktioniert.
Und das ist natürlich eine riesen Challenge und auch Zeitaufwand.
Ich meine, wenn ihr da sogar ein OKR für aufsetzt und die interne Kapazität von denjenigen, die sich natürlich damit am besten auskennen, nutzt, um die internen Kunden damit auszustatten und damit Prozesse eben zu verbessern, dann ist es natürlich ein riesen, also ein großes Investment, aber natürlich auch eine hohe Wahrscheinlichkeit, dass es ein Erfolg wird.
Seid ihr da schon mittendrin und gibt es da schon so erste Findings?
Habt ihr schon so Teilziele erreicht?
Ja, wir haben letzte Woche oder diese Woche sogar haben wir die erste Testwoche für Customer Success.
Also kann ich gar nicht genau sagen, wie das jetzt am Ende läuft.
Aber die ersten Ergebnisse waren natürlich sehr gut, dass sie auch wirklich damit arbeiten konnten.
Einfach mal das Cloud Desktop mit der Code Version auszustatten, initial Setup und dann.
versuchen, einen Plan zu generieren.
Hey, guck mal, ich habe jetzt den Kunden, das ist dann mit HubSpot verbunden und liste mir mal alle aktuellen Tickets bei HubSpot und da auch bestimmte Commands erstellt und dann kann man wirklich hauptsächlich in Cloud arbeiten.
Auf der Desktop, das heißt wirklich, also meine Vision ist auch so ein bisschen, dass innerhalb nächsten Jahres ist, dass man Cloud hauptsächlich als Tool nutzt und nicht nur nebenbei.
Das soll die Das soll das Hauptteil der Arbeit werden.
Das heißt, das Erste, was ich morgens aufmache, ist nicht HubSpot oder Jira oder was auch immer, sondern eigentlich Cloud und fragen, hey, was sind eigentlich heute meine To-Dos und was ist das Wichtigste, was ich gerade machen kann?
Ich glaube, dahin geht es, denke ich, das ist auch das, wohin es in Zukunft geht.
Und dass man nicht erst mal so ein Tool und sich da herumsucht, sondern wirklich die AI first nutzt und damit seine Aufgaben erledigt.
Ja, sehr coole Vision.
Genau, jetzt haben wir Customer Success so ein bisschen gesprochen.
Da macht ihr wahrscheinlich nicht Halt, ne?
Wie machst du das mit den anderen Abteilungen?
Ja, also Sales natürlich auch, Präsentationen natürlich auch, Transkripte von Customer Calls, falls es erlaubt ist natürlich, dann natürlich dann das.
herausziehen, Informationen, welche, also auch zum Beispiel irgendwelche Tickets herauszuziehen, was die Kunden gerne hätten in dem Sales Call und die Informationen halt auch nach Produkt spielen und da auch so ein bisschen spiegeln, was eigentlich aktuell gewünscht oder was ist eigentlich das Problem von den Kunden?
Da haben die das Problem ja nicht verstanden oder vielleicht, also das ist ja auch immer Produktarbeit, viel dabei.
Und das dann alles zu verbinden, ist, glaube ich, eine Meisterleistung.
Wir sind noch nicht am großen Ziel, natürlich nicht, aber ich glaube, dass wenn man alle Informationen halt bündelt, dass man am Ende halt ein super geiles Produkt bauen kann.
Und dafür ist AI einfach perfekt.
Das kann einfach die Information bündeln.
Du bist muted, André.
Das passiert ja nicht nur auf Arbeit.
Nee, das können wir drinnen lassen.
Das ist ja nicht nur auf Arbeit so.
Ich weiß nicht, ob das euch auch so geht, dass das bei einer Person pro Call passiert ist.
Das ist immer ganz hektisch.
Hände, Füße, alles bewegt sich, aber quasi Mikro aus.
Genau, insofern trifft es mich hier.
Nee, was ich sagen wollte, jetzt sprichst du ja mit einer schon ordentlichen Begeisterung.
bei allen Kollegen so oder musstet ihr die auf der Reise mitnehmen?
Da gibt es ja auch sicherlich Leute, für die das eine enorme quasi Lernstufe war.
Ja, also ein Beispiel, ich weiß gar nicht, ob ich das sagen darf, aber ich erzähle es einfach mal.
Sollte schneiden wir es raus.
Unser CEO tatsächlich, der Der hat tatsächlich einen Workshop übers Wochenende gemacht und das war dann ein Claude Workshop tatsächlich.
Das hat er gemacht, ich weiß gar nicht, ob es mit einem Freund war oder einer Gruppe, ich bin mir nicht sicher.
Auf jeden Fall nach dem Wochenende kam er wieder und war so begeistert von Claude und er ist dann all in und sagt, ich nutze jetzt Claude für alles tatsächlich.
Und der nutzt wirklich den Cloud für alles.
Der baut da HTML-Seiten, der macht Analysen mit Financial-Analysen mit Cloud und all den Kram.
Das ist verrückt.
Und dann hat er einen Kollegen gehabt, der hat ihm erzählt, dass man mit Sub-Agents SEO-Agenten machen kann, Landing-Pages bauen kann und dass er die ganzen Analysen macht.
Er sammelt sich dann die Skills irgendwie aus dem Internet und schaut, welche er aktivieren kann.
Das macht er alles automatisch.
Der war davon so begeistert tatsächlich, dass er Bei uns, den Fabi, hallo Fabi, falls du zuerst, den hat er quasi auch damit begeistert und gesagt, hey, lass doch mal einfach mal unsere Webseite umbauen und wir machen jetzt alles mit Cloud und Vibe Coding, weil vorher war es so ein bisschen mit Prismink noch, dann hat man den Content Headless gehabt und dann halt ein Frontend, der sich Daten lädt und die Static Sites baut und das verändert sich ja auch gerade.
Die Website selber ist jetzt auch einfach Vibe-Coded, das heißt, es macht wirklich eine Person gerade, die nichts mit Tech zu tun hat und da haben wir auch geholfen, ein bisschen das innere Setup zu machen und das kam auch vom CEO so ein bisschen und der fragt dann jede Woche, haben wir jetzt schon einen Agenten, der automatisch SEO-Checks macht und guckt, welche Keywords wir wieder einbauen können, um es wieder besser zu ranken und ich so, ja.
warte, entspann dich erst mal ein bisschen ruhig, weil Papi musste erst mal verstehen, wie Cloud funktioniert und wenn du jetzt erst mal um die Ecke kommst mit Sub-Agents, dann mein blauen erstmal, dann würde er gar nichts verstehen.
Und dann haben wir erstmal Basics gemacht und Seiten verwendet.
Daher ist das Cloud Desktop Preview perfekt, weil da kann man selekten und sagen, hey, die Webseite sieht gar nicht so toll aus, da ist irgendwas komisch, das Bild lädt zu langsam und dann so, oh ja, du hast natürlich komplett recht, ich mach das jetzt genau richtig.
Wenn ich höre, der Agent lädt sich oder sucht eigenständig nach Skills aus dem Internet und guckt dann, dass er die aktiviert.
Da kriege ich so ein bisschen, Herzrasen ist übertrieben, aber das ist natürlich security-technisch nicht ganz optimal.
Aber gut, man muss halt die Balance finden.
die für jede Organisation passt.
Aber ich habe tatsächlich noch gar nicht verstanden, wie das funktioniert, muss ich ehrlich sagen.
Deswegen, ich habe auch nicht weiter reingeschaut, wie man dann wieder nach eigenen Skills sucht, die irgendwie für das Repository wichtig sind und die dann aktiviert.
Muss ich mal genau reinschauen.
Ja, genau.
Vielleicht gar nicht verkehrt, mal reinzuschauen.
Ja, ich meine, also am Ende der Websearch-Skill, also den...
kannst du ja relativ leicht einem Agenten mitgeben und dann, klar, kann der nach Skills suchen.
Also ein Skills ist ja am Ende auch nur ein MD-File und vielleicht noch ein paar Zusatzfiles, die in so einer Directory-Struktur sind, runterladen, aktiviert und dann, wenn da Schad, also malicious Prompts drin sind, hast du eine Prompt Injection.
Aber genau, vielleicht einmal reingucken.
Nee, wir haben es noch nicht.
Also ich würde es bei den Kollegen reingucken, der es erzählt hat.
Wir haben es noch nicht bei einer Company.
Also von daher, wir sind noch safe, nur zur Info.
Aber ja, es gibt auf jeden Fall interessante Konzepte, sag ich mal so.
Absolut.
Das heißt also quasi so ein Use Case ist, nicht alle dabei, aber schon, die kann man überzeugen.
Gibt es da auch mehr?
Das hört sich fast zu gut an, um wahr zu sein.
Gerade was so auch dann die Adaptierung, also du beschreibst im Endeffekt so ein neues Operating-Modell.
Also der ganz normale Workflow, der ist nicht mehr da.
Da könnte ich mir vorstellen, dass Leute auch sagen, weiß ich nicht.
Jetzt seid ihr auf der anderen Seite eine sehr moderne Firma.
Ja, ich glaube, das ist auch unser Vorteil, glaube ich, weil wir sind recht jung, sage ich mal.
Und alle Kollegen sind sehr offen für Veränderungen auch.
Und ich glaube, das macht uns als Start-up auch aus am Ende.
Ich glaube, das ist wirklich toll, auch da zu arbeiten.
Also ich gehe jeden Tag mit einem Lächeln in die Firma und die Kollegen sind einfach super.
Von daher, also vielleicht ist es wahrscheinlich nicht selbstverständlich, aber es ist halt wirklich einfach toll.
Genau, also was ich auch noch jetzt überlege zu machen, ist, kennt ihr Graffiti zufällig?
Nein.
Okay, das ist so eine, also man kann da eine Graph-Datenbank hinzufügen.
Graph-Datenbank kennt ihr wahrscheinlich.
Man kann jetzt in der SQL-Datenbank speichern, NoSQL-Datenbank oder Graph-Datenbank ist auch NoSQL, aber man verbindet die Information mit Notes und Edges, also verbindet es eher Informationen mit in einem Graph und Graffiti baut darauf auf.
Es ist so ein Argentic-Layer um diese Graph-Datenbank herum.
Und man muss tatsächlich Graffiti mit einem API-Key, also einem LLM-API-Key starten, ohne geht es nicht, weil da wird der Prompt erstmal genommen und umstrukturiert.
Das heißt, deine Anfrage wird erstmal auf gewisse Sachen umstrukturiert, damit man besser im Graph die Noten Edges findet.
Und nur mal, das ist als Zeitnot, das ist noch alles ab vor Discussion, aber tatsächlich sehe ich, dass...
weil das MCP-Ready ist, auch als Knowledge-Datenbank für die Firma.
Und das kann man tatsächlich auch dann als Plug-in, kann man das auch in Cloud bereitstellen für alle.
Du musst dich anmelden und so weiter, ist alles mit drin und sicher auch.
Aber das könnte auch die Knowledge Base werden für alle, auch für Sales und sagen, hey, Sales und Product können verbinden.
Wenn Sales die Frage hat, hey, wann kommt eigentlich das Feature XY raus?
Und bevor wir jetzt da zu Produkt fragen und sagen, hey, wann kommt es raus?
Oder Engineering fragen, wann kommt es raus?
Man kann sich auch da die Infrastruktur bereitstellen, um einfach die Daten zu verbinden mit einer gewissen Schicht an Datenbanken.
Das ist alles noch ein Plan und das funktioniert im Tech-Team ein bisschen.
Muss natürlich dahinter sein, das auch zu pflegen und so, dass mehr Aufwand natürlich.
Aber ich glaube, das ist so die Richtung auch, in der ich die neuen Firmen auch sehe, die alles verbinden.
Das Kontextgraf GitHub Repository, meinst du ja?
Graffiti?
Ja, ich denke schon.
Kontextgraf aufstellt.
Ja, genau.
Build Real-Time Knowledge Graph.
Cool.
Nehmen wir mal in die Shownotes mit auf.
Und teilen wir.
Sieht auf jeden Fall spannend aus, weil am Ende, ich meine, das ist ja im Prinzip das, was du generell haben möchtest.
Du möchtest eben möglichst, also A, in der Organisation möglichst guten Kontext haben und dann, das bezieht sich, wenn ich es richtig verstehe, eher auf Agenten.
Dann möchtest du also Memory haben und idealerweise ein Knowledge Graph, der halt über reine Keyword Search oder Semantic Search auch quasi angereichert.
eben ja, Knowledge-Graphen abbilden kann, um da optimale Ergebnisse zurückzuliehen.
Genau.
Ich glaube, der initial use case ist auch hauptsächlich für das lokale Kontext.
Also ich meine, die meisten oder viele machen wahrscheinlich, dass sie den Plan und den Kontext, wo ich gerade daran arbeite oder was ich gerade gemacht habe, in Markdown-Files.
Das ist, glaube ich, so der Standard.
So, hey, ich habe Kontext, ich habe die Preference, ich habe mal was gelernt, ich muss das jetzt im Learning ablegen.
Und da kann man halt Graffiti auch super für nutzen.
Auch einfach Localhost starten und da einfach ein API-Key hinzufügen.
Und ich denke, das ist halt auch teilweise ein verbessertes Kontextmanagement.
Also könnte man mal ausprobieren.
Was ich auch sagen muss, es gibt nicht diese eine Lösung für alles.
Und das ist wirklich alles probieren.
Ich würde gerade sagen, das ist wahrscheinlich auch so ein bisschen gerade wie bei jeder neuen Technologie.
Da fängst du halt auch nicht, weiß nicht.
Als wir mit Cloud Computing angefangen haben, hat auch keiner über Infrastructure as Code nachgedacht oder über Microservices.
Und irgendwann hat man gemerkt, ja, das kann man ja vielleicht auch quasi so beschreiben wie Code.
Also die Infrastruktur und kleinere Komponenten machen mehr Sinn.
Ich glaube, wir sind da ganz am Anfang.
Das ist ja nämlich so ein bisschen an die Folge, die man mit Markus gemacht hat, Markus Andritz sagt, man muss halt einfach anfangen und ausprobieren.
Und wenn man wegschmeißt und man sagt, nee, funktioniert für uns nicht, dann ist das halt auch total in Ordnung.
Ich glaube, diese Außenbetrachtung alleine reicht halt nicht.
Ja, ich glaube auch viel ist halt Lernen einfach.
Einfach mal ausprobieren, schauen, wie es funktioniert.
Es ist halt vieles Learning dabei.
Deswegen eigentlich muss halt eine Organisation selber muss halt viel bereitstellen, ohne viele Hürden dazwischen zu haben, um einfach, dass die Leute mal testen können und schauen, hey, das funktioniert für mich und dann halt wirklich auch so eine Knowledge-Sharing-Session zu haben innerhalb der Firma, sagen, hey, wo jeder mal seine Erfahrungen teilen kann oder es gibt vielleicht jemanden, der Best Practices hat, je nach Größe der Firma, aber vor allem am Anfang ist es ja, man versucht so ein bisschen die Ambassador zu finden, die diesen Drive und auch diese Lust darauf einfach in die Firma bringt und das dann auch teilt.
Und das ist, glaube ich, auch sehr wichtig überall.
Ja, vielleicht noch so ein letzter Gedanke dazu.
Also ich fand deine Vision, die du geschildert hast, von Cloud Code oder Cloud wie auch immer als einziges Tool, was du benutzt, was deine To-Dos enthält, was dir morgens sagt, was du zu tun hast, sehr, sehr stark.
Und habe dabei nur die ganze Zeit im Kopf den Impact von, Oder mal anders, Pip Klöckner sagt ja immer, Token werden immer billiger.
Hat er ja auch recht.
Wir sind hundertfach im Preis gefallen in den letzten, wie auch immer, wie viele Jahren.
Auf der anderen Seite brauchen wir aber auch immer mehr Tokens.
Also die Agenten wie Lord Code oder generell Harnesses funktionieren deshalb, weil sie einfach den Kontext anreichern mit.
Unfassbar viel Informationen, die sich alle in Tokens sozusagen übersetzen, die einmal ingested werden müssen vom LLM.
Das LLM selber hat Thinking Tokens, es gibt irgendwie Output Tokens und per se wird es deswegen teurer, zumal gleichzeitig auch die Subscription Preise anziehen.
Cloud, also Anthropic zieht gerade die Preise an.
gerade gestern gesehen, ich habe noch so eine alte GitHub Copilot Lizenz, die phasen die Pläne aus, die quasi subventionierten Pläne und gehen dann auf ein komplett nur Pay-Per-Use Usage.
Wenn man dann wirklich diesen Tokenverbrauch und Pay-Per-Use Kosten hat, dann wird es schon ganz schön teuer oder kann es ganz schön teuer werden.
Insbesondere, wenn dann auch Anbieter aus dem Markt gehen, weil am Ende das ist nicht unwahrscheinlich, dass diesen Wettbewerb einfach dann irgendwann nicht mehr alle mitgehen können, sondern es werden irgendwie ein paar große LLM-Provider bestehen bleiben, die dann vielleicht auch Tooling bieten.
Ich weiß gar nicht, ob so ein Cursor oder so, ich meine gut, die werden jetzt wahrscheinlich von, oh jetzt habe ich durcheinander gebracht, oder SpaceX oder wer auch immer, ist ja alles eins jetzt, gekauft, aber die perspektivisch werden die ja eher verschwinden.
Und dann hast du eine Konsolidierung im Markt, dann hast du Marktführer, die die Preise natürlich treiben können und die die bisher noch stark subventionierten Subscriptions, die sie anbieten, wahrscheinlich dann quasi auch eher anpassen werden, sodass die echten Preise bezahlt werden.
Dann hast du natürlich den Gegeneffekt, dass du wiederum Open Source Modelle hast.
Aber warum du nicht drum herum kommst, ist die GPU-Stunde, die einfach egal wo ...
Kostet so.
Und das ist so eine Limitierung nach unten.
Du kannst natürlich irgendwann dann sagen, keine Ahnung, wenn die GPUs, Consumer GPUs besser werden oder generell auch verfügbarer, dann kannst du vielleicht sogar eigene GPUs, also kannst du OPEX in CAPEX umwandeln.
Aber auch da hast du, keine Ahnung, fünf gute Jahre von so einer GPU, die du maximal ausnutzen musst.
Und dann hast du das eigene Risiko, dass du das maximal ausnutzt, sodass die GPU-Minute optimal oder Stunde optimal bepreist ist.
Lange Rede, kurzer Sinn.
Das ist natürlich ein Thema, also ein Kostenthema, was man sich einkauft, wenn man so stark integriert.
Ich will gar nicht irgendwie der Partypuper sein und ich glaube auch, dass es in die Richtung geht.
Für mich ist tatsächlich noch total offen, wo sich das preislich hin entwickelt.
Und deswegen habe ich da noch so ein gewisses Störgefühl dabei.
Korrekt.
Ich meine, man kann sich auch die Frage on-premise jetzt auch...
Stellen und die ganzen, die werden ja auch alle immer besser und man braucht weniger RAM dafür.
Also das stimmt total.
Also wahrscheinlich wird, die Tokens werden günstiger oder auch nicht.
Man weiß es nicht.
Mal gucken, die Unternehmen gehen aus dem Markt, Open Source wird größer.
Kimi wird auch immer besser, zum Beispiel sehr günstig.
DeepSeek ist natürlich auch.
sehr günstig, aber muss man mal schauen.
Aber ich glaube, insgesamt, was, glaube ich, hängen bleibt, ist das Learning, glaube ich, im Team.
Und wie man damit umgeht, wie man mit Skills arbeitet, wie man mit Plugins, wie man allgemein mit den LLMs umgeht, wie man den Kontext reintut, wie man den Loop hinbekommt auf der anderen Seite.
Also dieser AI-Alignment-Loop und ich habe sogar auch ein paar Blogposts darüber geschrieben.
Und dieses Listen, das geht einfach nicht weg.
Und ich glaube, Das wird in Zukunft auch bleiben, glaube ich.
Und ich glaube, das ist das Wichtigste gerade.
Und alles, was passiert ist, kann man jetzt natürlich in Frage stellen oder schauen, wie es weitergeht.
Aber wir sind hier und jetzt, im Hier und Jetzt und nicht in zehn Jahren.
Von daher muss man schauen.
Und der Brot ist rumfriemeln, wie ich glaube, Margot Andres hat das genannt, das ist jetzt wichtig.
Ja, und da ist so ein bisschen wieder der Punkt mit dem...
Und mit der Standardisierung, wenn man zu sehr standardisiert, läuft man vielleicht auch Gefahr, dass man sich zu sehr auf einen Anbieter festlegt und dass die Learnings nicht gut übertragbar sind, gerade wenn man im Anthropic-Kontext ist.
Aber, ja, also wenn du jetzt spezifisch Plugins nimmst und halt die Claude Harnesses, die von Anthropic angeboten werden, dann kannst du da Gefahr laufen.
Wenn du aber natürlich standardisiert einfach Skills nutzt und Agent MDs und was auch immer, dann klar, dann kriegt man das hin.
Aber ich würde auch sagen, da ist noch nicht, also noch gibt es nichts von Anthropic, was meines Erachtens nach, ein wieder raus oder ein leichtes, also was die Switching-Cost so stark erhöht, dass es schwer wäre, da wieder rauszukommen, außer natürlich die Qualität, die die LLMs einfach haben bei Anthropic.
Aber ich kann mir durchaus eine Zukunft vorstellen, in der das so sein könnte.
Nichtsdestotrotz, wir sind eben hier und jetzt, da hast du vollkommen recht.
Ja, ich glaube auch, also ich bin in meinen privaten Projekten, switche ich immer zwischen Claude und Gemini und auch mal hin und her und schaue mal, wie das Open Code, wie es funktioniert und Tatsächlich einfach, ich meine, die Skills haben ja die gleiche Struktur auch.
Also eigentlich ist das Switch von einem zu dem anderen eigentlich gar nicht so schwer, hätte ich gesagt.
Nee, als Entwickler auch nicht.
Ich meine nur, wenn du in anderen Teams auf einem bestimmten Cloud-Cowork oder wie auch immer Tool bist mit Plugins, die es in anderen Umgebungen eben nicht gibt, also je tiefer du integrierst, desto größer die Switching kostet.
Ja, 100 Prozent, das stimmt.
All right.
Wir haben, glaube ich, schon die Stunde fast voll und wir peilen ja eigentlich immer so eine Stunde an.
Deswegen würde ich langsam auf die Zielgerade einbiegen wollen.
Und zum Abschluss, wie immer, unser Recurring-Segment, The Reality Check.
Du warst jetzt ganz begeistert und auch for good reason, denke ich.
Gibt es aber bei dir auch, hast du auch What-the-Fuck-Momente, wo du manchmal denkst, wie konnte das jetzt nicht funktionieren?
Also ich verstehe nicht, warum Opus 4.7 schlechter als 4.6 ist, aber es ist eine andere Sache.
Nee, also ich glaube enttäuscht.
Ich bin eher immer noch auf der Suche nach einem Personal Assistant.
Tatsächlich.
Und ich denke mir, warum gibt es den noch nicht?
Und das ist, mein Open Claw ist alles da, aber irgendwie fehlt mir da trotzdem noch was.
Und das ist mir irgendwie alles noch zu schwierig.
Da jetzt wirklich, dass ich den Assistant, den Personal Assistant in meinem Leben integrieren kann.
Die Tools sind so verschieden und Datenschutz, alles dabei und das ist halt irgendwie noch zu schwierig, da etwas auf die Beine zu stellen, was mir wirklich hilft irgendwie.
Tatsächlich.
Also ich weiß nicht, wie es euch geht, aber ja, ich, also heute hat jemand in so einer Gruppe geteilt, ein Meme oder nee, irgendjemand, glaube ich, hat einen Ex-Tweet abgesetzt.
Sorry, ich komme da immer durcheinander.
Er hat jetzt all seine SaaS Subscriptions gecancelt, 480 Euro gespart und ersetzt durch 1280 Euro Tokenkosten bei einem LLM Provider und 15 Stunden die Woche irgendwie in Jamelfalz irgendwelche Anpassungen machen.
Und ich fand das so sprechend, weil ich mich, also ich liebe meinen Open Claw.
Ich bastel da Allerdings auch wirklich viel dran rum, eher mit so einer Tinkering-Attitüde, weil ich irgendwie herausfinden möchte, wo sind die Grenzen, was kann man damit alles machen und habe da großen Spaß bei.
Fairerweise, ich nutze meinen Codex, meine Codex-Subscription, das heißt, es ist gedeckelt bei den 20 Euro im Monat, die ich da zahle.
Von daher habe ich da eine andere Experience, aber es ist natürlich trotzdem genauso, wie du es sagst, dass der...
Der hundertprozentige Agent, der einfach so funktioniert, der ist natürlich noch weit in der Zukunft.
For good reason auch.
Also der lethal trifecta ist einfach nicht so leicht zu lösen.
No matter what you do.
Das ist einfach, wenn du den Agenten irgendwie nutzbar machen möchtest, dann machst du ihn, also exposed du ihn nach außen und gibst ihm Zugriff auf relevante, also sensitive Daten.
Und damit hast du einfach das Problem eingekauft.
Nichtsdestotrotz finde ich tatsächlich meinen Agenten für die Use Cases, die ich jetzt mir so gebaut habe, gerade ja auch im Podcast-Bereich oder ansonsten, wirklich gut und immer wieder sehe ich irgendein YouTube-Video, irgendein neues, kein Art Tool oder so, was ich integriere und es wird immer besser und da habe ich Spaß dran.
Aber es ist wirklich keine Turnkey-Solution, gebe ich dir vollkommen recht.
Aber wie kommunizierst du mit OpenClaw?
Telegram.
Telegram einfach?
Okay.
Der Hauptkanal.
Ich muss fairerweise schon, wenn ich, ich habe einmal einen Bug-Hunt gemacht, da gab es irgendwie einen Bug, dass er manchmal Messages doppelt schickt nach Tool-Use und irgendwelche Konstellationen.
Da habe ich versucht, ein Bug-Fakes lokal bei mir zu machen.
Danach war das Ding tot und dann musste ich halt lokal irgendwie alles wieder herstellen und hin und wieder passiert mir das schon auch, dass ich irgendwie dann doch mich da einloggen muss.
Das ist mir tatsächlich schon zu kompliziert.
Da muss ich ein Telegram reingehen, da muss ich ein Chat finden und dann reintippen oder Sprachnachricht.
Tatsächlich, das ist mir schon, ich will es eigentlich noch einfacher gerne haben.
Also wirklich eigentlich eher auf OS-Level.
Das ist so, was ich gerne hätte, aber es ist einfach noch so weit weg.
iOS ist auch nicht so wirklich.
André?
Ja, ich habe gerade überlegt, ich glaube, du kommst aus der gleichen Stadt wie der Robert.
Wir machen heute ein Recap aller Podcast-Folgen.
Robert Glaser.
Der war ja auch mal bei uns.
Ich glaube, ganz, ganz großer Open-Claw-Fan betreibt die Open-Claw-User-Group in München.
Vielleicht mal eine Chance, vorbeizugehen.
Ich glaube, der ist in München.
Wenn ich mich jetzt nicht täusche.
Ich glaube, der Appetit kommt beim Essen an der Stelle.
Ich weiß nicht, ob du mal Open-Claw ausprobiert hast.
Sebastian und ich haben ein ähnliches Set, aber ich nutze das per WhatsApp oder Integration via WhatsApp und ich nutze Claude dagegen.
Das kostet ein paar Euro oder vielleicht auch ein paar Euro mehr, je nachdem, wie intensiv man es nutzt.
Ich finde die Experience besser.
Mir hilft das halt irgendwie mehr damit zu machen.
Ich habe da auch schon diverse Modelle durch und falle immer wieder auf das zurück.
Und ich muss sagen, je mehr ich es nutze, je mehr mag ich es.
Ich glaube, das ist auch wieder dieser Punkt, ausprobieren, ausprobieren und im Zweifelsfall, okay, dieses Plugin hat nicht funktioniert oder dann denkst du halt, dieser Use Case auch nicht, aber ich gebe dir recht, ist natürlich nicht diese Out-of-the-Box-Lösung.
Ich glaube, weil das halt auch sehr, sehr, sehr, sehr unterschiedlich ist, die Use Cases und das, was Sebastian halt auch gesagt hat, am Ende steht und fällt das halt mit den Daten, mit den die du zur Verfügung stellst.
Und das ist im Zweifelsfall natürlich heavy.
Ja, ich warte noch.
Oder ich gehe mal zur User Group tatsächlich.
Ja, wir connecten dich danach noch mit dem Robert.
Sehr gut.
Ich suche gerade schon auf LinkedIn.
Genau.
Gut, dann last but not least.
Hast du noch irgendwie einen heißesten Scheiß und oder eine Predictions?
für unsere Hörer.
Der heißeste Scheiß.
Vielleicht kennt ihr Auto-Research?
Ja.
Okay.
Tatsächlich ziemlich cool und ich meine, das ist im Data Science Bereich eher relevant, weil man ziemlich cool auch über Nacht einfach mal so ein bisschen Researchen lassen kann, automatisch und schauen, okay, hey, wie kann ich denn das Model tweaken, damit es morgen besser ist als heute?
Von daher ist es...
Das ist so ein bisschen Mindblowing für mich, weil es macht Sinn für mich, weil es kann das Ergebnis anschauen und gucken, ob es besser oder schlechter würde und das automatisch.
Und das ist halt super easy und super einfach.
Ja, so ein bisschen eigentlich das gleiche Konzept wie bei der Dark Software Factory dahinter.
Und es steht und fällt halt mit den klaren Testkriterien.
Wenn du klare Testkriterien hast, gegen die du agieren kannst, dann kann der Agent ja so lange probieren.
bis er es schafft, wenn er die Testkriterien nicht ändern kann.
Bei uns ist es ja so, dass wir mit dem eigenen Model, also Tree Prediction und Accuracy 95%, hat man eine genaue Nummer und wenn man jetzt den Parameter verändert, ist es besser oder schlechter als vorher?
Von daher ist es halt für unseren Fall extrem cool tatsächlich.
Ja, glaube ich, unbesehen.
Cool.
Vielen Dank.
Sehr gerne.
Danke auch.
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.hmze.tech schicken.
Vielen Dank für deine Zeit.
Wenn es dir gefallen hat, abonniere den Podcast.
Bis zur nächsten Folge.