Das Gespräch ist auf Englisch, das Transkript hier ist aus dem Englischen übersetzt. Den Wortlaut findet ihr im englischen Original. Zurück zur Folge
Intro
Benedikt Stemmildt
Moin moin und willkommen zurück zu einer neuen Folge von Rethink Engineering. Die hier ist für mich eine ganz besondere, weil wir mit unserem heutigen Gast viele der Themen besprechen, wegen denen wir den Podcast umbenannt haben. Ich bin Benedikt, ich bin Co-Founder von hackers&wizards. Wir bringen Engineering-Teams bei, wie sie mit Agenten und Factories arbeiten, und diese Show hier wird von uns präsentiert und auch von re:cinq.
Mein Gast heute ist Patrick Debois. Ich bin ein riesiger Fan. Er hat die ersten DevOpsDays in Gent organisiert, ich glaube 2009. Er macht das also schon eine ganze Weile. Und es gibt viele Ähnlichkeiten zwischen DevOps und Agentic Engineering. Er hat also echt interessante Gedanken dazu, was wir tun müssen und was gerade passiert.
Wir diskutieren über Factories, Organisation, auch darüber, wie das unsere Rollen verändert. Und was mich besonders gepackt hat, war, dass wir uns gerade vielleicht zu sehr auf Code konzentrieren und die Möglichkeiten übersehen, die diese Factories haben, sobald wir uns auf das Ergebnis konzentrieren. Und ja, darüber sprechen wir in der Folge. Mir hat die hier echt Spaß gemacht.
Ich hoffe, euch auch. Viel Spaß. Hi, hallo, Patrick. Super, dass du da bist. Vielen Dank. Ich fühl mich echt geehrt. Wir freuen uns auf die Folge.
Patrick Debois
Wie man so sagt, moin moin. Nee, ich weiß nicht, was ich sagen soll. So begrüßt du mich ja immer. Also danke, dass ich bei dir in der Show sein darf, Benedikt.
Benedikt Stemmildt
Super. Also lass uns, keine Ahnung, lass uns, glaube ich, einfach ins Thema einsteigen. Mich interessiert total, was dich gerade so beschäftigt. Wie stehst du gerade zu Engineering? Ich glaube, du hast viel zu erzählen. Also vielleicht fängst du einfach mit dem an, worüber du gerade am meisten nachdenkst.
Software Factories durch die DevOps-Brille
Patrick Debois
Ich versuche, Software Factories und Dark Factories zu verstehen. Und mit meinem Hintergrund in DevOps, in CI/CD, versuche ich zu sehen, was gleich ist, was anders ist. Das ist irgendwie, irgendwie vielleicht so meine Analyse. Wohin geht das und wohin geht die Reise, im Grunde? Also das beschäftigt mich gerade irgendwie.
Benedikt Stemmildt
Weißt du, wir sind hier auf einer ähnlichen Reise und versuchen das auch herauszufinden. Und mich interessiert total, was für dich denn der Unterschied ist? So, was ist dein, so, gibt es überhaupt einen Unterschied? Ist es dasselbe wie CI/CD? Wie ist da der aktuelle Stand?
Patrick Debois
Naja, ich habe mir so Firmen angeschaut und verglichen, die Factory-Lösungen anbieten. Und ich war irgendwie ein bisschen traurig, dass es sich so ähnlich war. Die waren alle so: Hey, wir produzieren Code, wir reviewen Code, wir deployen Code. Und es fühlte sich irgendwie an, als wäre es dasselbe. Natürlich ist die Technologie neu und wir können neue Funktionalitäten umsetzen, so wie im Review.
Wir könnten andere Wege haben, statt den Code nur laufen zu lassen und zu testen. Wir können Code bewerten lassen. Aber wir können auch adversariale Code-Checks haben. Und ich glaube, ein vielleicht aufkommendes Thema, das öfter auftaucht, ist das Thema Risiko. Und das gilt besonders, wenn man es auf eine traditionelle CI/CD bezieht: Da baut man sie Schritt für Schritt aus.
Und man fügt mehr Checks hinzu. Und man geht davon aus, dass die Checks reichen, um ein bestimmtes Level an Deployment zu machen. Aber da war trotzdem noch viel menschliche Beteiligung dabei. Und jetzt hoffen wir, dass es viel mehr Autonomie gibt, dass das System so Dinge in Produktion bringt. Und diese Verifikationsschicht war traditionell Testing, wie ich gesagt habe.
Aber jetzt ist es so eine ganze Reihe von Verifiern, könnte man sagen. Aber wann mergt man eigentlich? Diese Entscheidung, naja, eigentlich geht es sogar noch darüber hinaus. Es geht nicht nur darum, was man mergt. Wenn man mergt, deployt man. Was stellt man vor seine Kunden? Und wie sieht die Risikoanalyse dazu aus? Und ich finde es faszinierend, dass alles, was wir gemacht haben, irgendwie darauf reduziert wird: Was ist das Risiko, etwas rauszubringen, gegenüber dem Nutzen, etwas für einen Kunden rauszubringen.
Jedenfalls ist das insofern interessant, als ich die Parallele ziehe: Wir haben mit DevOps so viel automatisiert, dass wir sofort eine neue Maschine bekommen konnten, die hat eine neue Version, irgendwie ganz flüssig. Aber es gab immer die Diskussion, man sollte, sagen wir mal, auch Dinge wie Datenbankschemata automatisieren. Aber nicht viele Leute haben sich das getraut, weil das Risiko schwerer wog als dieser manuelle Schritt.
Und ich habe das Gefühl, jetzt führen wir irgendwie ähnliche Gespräche. Aber was kann man tun? Und und ich habe das Gefühl, es gibt eine starke Korrelation zu, und ich glaube, das ist ein unterschätzter Wert der Software, wo man alle Tests laufen lassen kann und sie gehen durch und man kann den Code reviewen und er ist in gutem Zustand. Aber wir haben so beim Deployment gelernt, dass es die Architektur deiner Anwendung ist, die ein gewisses Maß an Unsicherheit abfängt.
Dass ich meinen Container killen kann und er einen neuen startet, ist irgendwie die Art, wie wir Microservices architektiert haben. Und ich habe das Gefühl, hey, wenn man das vergleicht, so Kompartimente und Teile aus seinem Code zu machen, die könnten sagen, das hier darfst du anfassen, was okay ist, so eine andere Farbe ist vielleicht nicht der Weltuntergang.
Aber wenn dein Payment-System ausfällt, hast du vielleicht ein größeres Problem. Also so diese Teile finden. Und das ist nur ein Beispiel. Da sind, da sind natürlich pro Domäne, pro Firma die Risiken unterschiedlich. Und wie geht man damit um?
Das Risiko ist die eigentliche Merge-Entscheidung
Benedikt Stemmildt
Interessant. Also, also du sagst im Grunde, dass, ich meine, die Idee, die Idee der Factory ist, dass man tatsächlich mehr von seiner Engineering-Arbeit wegautomatisieren kann, was man vorher nicht machen, machen konnte. Genau. Also das Schreiben des Codes oder das Reviewen des Codes und so weiter. Und du sagst, dass es echt schwer ist herauszufinden, wie man das hochhebt von so, sehr viel im Loop sein zu nicht so viel im Loop sein. Genau. Und das ist dieses Risikoproblem.
Patrick Debois
Ja, genau. Ja.
Benedikt Stemmildt
Ja. Okay. Und die Idee, die du beschrieben hast, ist, dass vielleicht nicht jeder Teil des Codes dasselbe Risikoproblem hat. Und das ist okay. Und deshalb könnte jemand irgendwie herausfinden, ob das etwas ist, was wir auch in den Factories machen könnten, dass wir, dass wir unseren Code und so weiter irgendwie anders aufteilen, als wir es vorher gemacht haben. Ist es das, was du sagst?
Patrick Debois
Na ja, wir sind so, es ist eine Art, das zu betrachten. Genau. Ich projiziere fast schon. Stell dir vor, alle automatisieren denselben Loop, Code Review. Das wird nicht in jeder Factory so unterschiedlich sein. Okay, na ja, vielleicht gibt es ein bisschen Schnickschnack dabei, irgendwie wie dieser Loop laufen wird. Aber letztlich, was die, die größeren Versprechen der Dark Factory sind, nicht nur, weißt du, irgendwie die Factory, wie wir sie kennen, ist, dass es Entscheidungen gibt, die von Maschinen so getroffen werden, dass wir unsere Aufmerksamkeit nicht irgendwie darauf richten müssen.
Also wenn die Factory von sich aus entscheidet, eine Änderung zu machen, müssen wir dann immer das Review machen? Ja oder nein? Und das ist irgendwie, okay, ich kann eine Million Tests draufpacken, aber trotzdem, was ist das Risiko, dass sie das ohne dich im Review macht? Und das ist irgendwie eher der fortgeschrittenere Teil, den ich mir in einer Factory anschauen würde.
So, wie hilft sie dir, nicht nur so den Code zu reviewen, sondern irgendwie, was könnte sie tun, um Teile von diesem Teil abzunehmen? Also, auch wenn es nicht wirklich Engineering-Arbeit ist, so, es ist nicht das Bauen. Es ist nicht das mechanische Deployment. Es ist eher so eine businesszentrierte Entscheidung. Was, solltest du es so machen? Ja oder nein?
Und ich habe das Gefühl, dass es eine Korrelation mit der Architektur gibt, aber es könnten vielleicht auch deine Service Level Agreements oder deine Kundengröße sein. Oder ich weiß nicht was, so, das sind alles irgendwie Faktoren, die in diesen Teil einfließen. Aber ich erkenne auch, dass das vielleicht eher der fortgeschrittenere Teil in der Factory ist, wo sich auch viel davon ansammeln wird, weil wir wollen, dass es autonom läuft. Und das ist irgendwie eine der Herausforderungen, die da sein müssen.
Benedikt Stemmildt
Ich finde, das ist ziemlich auf den Punkt. Aber ich habe im Moment gar nicht so viel an Risiko gedacht. Also ich finde, das ist echt, echt aufschlussreich für mich. Es war, ich erzähle immer diese Geschichte über Vertrauen, oder? Ich vertraue meiner CI/CD Pipeline, weil sie deterministisch ist und weil ich da viele Checks drin habe, bei denen ich weiß, okay, sie wird nichts Dummes machen.
Irgendwie war die Frage für mich immer so, ja, wie muss ich meine Factory bauen, damit ich ihr zutrauen kann, die richtigen Entscheidungen zu treffen? Ich weiß nicht, ob das die Idee verändert, aber vielleicht ist Risiko, ist es ein besserer Ansatz, weil ich diesen Gedanken, auf den du hinauswillst, echt mag, dass die Architektur da irgendeine Korrelation hat, weil, ich meine, ich meine, wir haben zum Beispiel Dependencies.
Ich, ich meine, ich pinne die Version der Dependency und bin mit diesem Teil des Codes zufrieden. Und ich habe dann das Gefühl, das Risiko ist gering, oder? Also für diesen Teil des, und ich könnte ein, ich könnte diese Dependency neu bauen, das Interface zur Außenwelt ist dasselbe. Ich, ich meine, da ist vielleicht, das ist so ein Ding, das abgekapselt ist, wo ich nicht viel Risiko habe, weil das Interface ziemlich klar ist.
Und ich könnte das irgendwie mit mehr von meinen Komponenten machen und dann sagen, bei dieser Komponente, die Factory entscheidet da nichts, weil ich ihr das noch nicht zutraue oder so.
Patrick Debois
Es gibt einen gewissen Trugschluss im Glauben, dass wir alles testen können, und das ist vielleicht irgendwie eine unbequeme Wahrheit, wenn man Dinge rausbringt, weil es immer einen anderen Teil gibt, okay, natürlich ist Production anders als Test, oder? Weil es User gibt, es gibt verschiedene Dinge, die passieren werden. Aber wenn wir uns wirklich so den ganzen Code anschauen wollen, den das Ding produziert, wird es einige Fälle geben, wo einfach was durchgerutscht ist.
Und aber es ist, es ist ähnlich zu dem, was irgendwie ein Mensch macht. Aber die haben normalerweise so ein Gefühl von, hey, das braucht so, weißt du, ein Peer Review, und das ist so, weißt du, diese Art von Ding. Also das zu analysieren und an die Oberfläche zu bringen und das dann irgendwie in deiner Architektur abzufedern, ist wahrscheinlich etwas, das Sinn ergibt.
Und ich habe angefangen, darüber nachzudenken, dass die, die Dark Factory Abstufungen hat, und zwar so, dass, weißt du, es für manche Fälle kein, es keinen Sinn ergibt, bei dem Risiko, das man eingeht, bestimmte Teile zu automatisieren. Und bei anderen wird es heißen, ja, natürlich, das, das ist der. Also es ist ein Spektrum davon. Und die Art, wie man auf dem Spektrum entscheidet, ist, was der Impact und das Risiko und die Wahrscheinlichkeit sind, irgendwie ähnlich wie, weißt du, bei Dingen, die man in Production bringt, und das zu automatisieren, wird noch entscheidender dafür sein.
Es sagt, du kannst in Production gehen. Ja, nein, aber es ist vielleicht zusätzlich. Ich sage nicht, schmeiß alle Tests weg, aber es ist, es ist eine weitere Entscheidung, die man sehen muss, so, hey, ich habe mir den Teil angeschaut. Das hast du nicht angefasst. Das hast du nicht angefasst. Scheint okay. Ich kann das autonom machen. Und, und das ist vielleicht ein Schritt, den wir nicht machen konnten, so etwas zu einer Pipeline hinzuzufügen, das so von sich aus entschieden hat, und dann irgendwie zu sagen, na ja, du kannst es selbst machen.
Dark Factories gibt es in Abstufungen
Benedikt Stemmildt
Es gibt viele Diskussionen darüber, so, ob all diese Checks deterministisch sein sollten, oder? Und was ist mit nicht-deterministischen Checks darin? Und ich habe das Gefühl, dass das hier wirklich auch eine neue Aufgabe ist, nämlich, wie du gesagt hast, so herauszufinden, was wir, was können wir nicht-deterministisch machen und trotzdem Vertrauen oder ein geringes Risiko dabei haben.
Oder wie kann das sogar so ein Vorteil sein, den wir vorher nicht hatten? Jetzt, wo wir nicht-deterministische Fähigkeiten haben, kann das sogar eine riesige Verbesserung sein gegenüber nur den Tests, die vorher deterministisch waren?
Patrick Debois
Genau. Ich bin ein großer Fan davon, alles, was wir können, in deterministische Checks zu verwandeln. Da gibt es normalerweise einen Vorteil bei Geschwindigkeit und Kosten, dass wir es nicht mit so LLMs oder Turns machen müssen oder es zu lange dauert, diese Teile wiederzuentdecken. Jetzt ist das ein zweischneidiges Ding. Es ist so, wenn du an den Test als Harness denkst, den du um das LLM herum legst, oder, so, okay, du so, du kannst nicht pausieren, wenn du, du kannst dieses Teil nicht lösen.
Es gibt einen, es gibt einen schmalen Grat zwischen Mikromanagement deines LLM und ihm irgendwie etwas Freiheit zu geben, dass es Teile lösen kann. Genau. Also, also, es gibt so einen Cash-on auf eine Art von Regeln, die du in den, in den Prompt schreiben könntest. Aber du musst fast wissen, du brauchst einen Wartungs-Check, der so sagt, ist das noch der richtige Weg?
Und das ist irgendwie die Fabrik, die über sich selbst reflektiert und schaut, so, ist das noch irgendwie richtig an seinem Platz, weil es passiert ist. Und wir haben es hinzugefügt, weil es, es gab einen Incident. Aber stimmt das noch? Also, es ist irgendwie, an sich selbst zu zweifeln, bei der Architektur, bei den Lösungen auch.
Orchestratoren vs. State Machines
Benedikt Stemmildt
Also, wie du vorhin gesagt hast, dass du das Gefühl hast oder oder dass du gesehen hast, dass die meisten dieser Loops am Ende wahrscheinlich sehr ähnlich aussehen. Okay. So, du hast diesen Default, Expect und Plan und so weiter. Ich weiß, dass es gerade eine Diskussion gibt, dass wir diese, so, Pipelines mit diesen Checks und so weiter vielleicht gar nicht brauchen, dass dass man einfach einen Orchestrator haben kann und der das alles ganz allein herausfindet. Also, wie siehst du das?
Patrick Debois
LLMs sind großartig, aber bei bestimmten Dingen sind sie eben auch nicht großartig. Sagen wir, du willst einen Zähler haben. Nimm einfach, nimm einfach kein LLM dafür. Ja. Also, das ergibt keinen Sinn. Oder ich hatte das jetzt mehrmals. Ich baue ein Tool und sage, na ja, lies, irgendwie nutz eine API, um die IDs aus der Datenbank zu holen, und gib die dann an etwas anderes weiter.
Und dann halluziniert es nach einer Weile einfach IDs. Die Technologie an sich ist also nicht immer das verlässliche Teil, oder es verliert vielleicht Context, oder so, man kann das nicht so lesen, als würde das alles ersetzen. Es gibt natürlich die große Hoffnung, dass, solange man alles perfekt spezifiziert, weißt du, die Dinge gut gehen. Aber diese Theorie kaufe ich nicht.
Ich sage nicht, dass man Dinge nicht spezifizieren sollte. Es hilft auf jeden Fall, Context zu geben und irgendwie bessere Ergebnisse zu machen und zu liefern. Aber ich sehe keins, selbst mit so erschöpfendem Training. Es kann nicht so deine Geschäftsentscheidungen verstehen. Sie können diese Dinge nicht in ihr eigenes Verständnis übernehmen. Na ja, es ist nicht wirklich Verstehen. Es ist es ist eher Vorhersagen. Also, dass es irgendwie alles übernimmt, das kaufe ich nicht.
Man sieht ziemlich oft, dass ein Orchestrator ziemlich locker anfängt, so: Hey, nimm dir die nächste Aufgabe. Ja. Weißt du, zufällig, hier ist was zu tun, so, mach irgendwas. Was die meisten Leute am Ende bauen, ist nah an einer State Machine. Na ja, zuerst ist es hier, wenn du in dieser Phase bist. Dann kannst du dorthin gehen, und sie packen die Dinge in in eine Art Graph-System.
Warum machen sie das? Weil sie wissen, dass es unzuverlässig ist, es das einfach allein machen zu lassen. Oder das Lager vom LLM-Training wird sagen, mit genug Training macht es das. Aber da sind wir wir sind irgendwie noch nicht da. Ja. Also, warum irgendwie darauf hoffen, und ich glaube, dieser Trugschluss von "Du sollst nicht scheitern" ist irgendwie genau das, wogegen wir fast im ganzen letzten Jahrzehnt angekämpft haben, und wir sagen: Geh davon aus, dass es scheitern wird.
Das ist ein viel besserer Ansatz, um irgendwie damit umzugehen. Aber genau deshalb, wenn du davon ausgehst, dass es scheitern wird, musst du über das Risiko nachdenken.
Benedikt Stemmildt
Ich bin auch eher im Lager von deterministischer und lass lass uns eine State Machine daraus machen. Ich glaube, es gibt auch diesen Unterschied, ob ich davor sitze und die ganze Zeit draufschaue oder ob ich will, dass es irgendwo autonom läuft. Also, so mache ich es immer, ich meine, wenn ich oder wenn ich es selbst nutze, um Apps zu bauen, und ich wirklich davor sitze, mache ich es eher mit diesem Orchestrator-Ansatz, weil ich einfach verfolgen kann, was es macht, und es dann unterbrechen oder irgendwie herausfinden kann, ob es in die richtige Richtung geht.
Und wenn ich Factories für unsere Kunden baue, ist es eher so: Okay, wir müssen herausfinden, wie wir das vertrauenswürdiger und autonom in der Cloud machen können, sonst sitzen einfach alle die ganze Zeit davor. Also vielleicht ist das auch so eine Sache, wo es einfach von der Situation abhängt, oder?
Patrick Debois
Es ist nichts falsch daran, davor zu sitzen, so wie ich das erkläre: Wenn du, sagen wir, klassisch entwickelt hast, lässt du Dinge laufen und hast sie irgendwie auf deinem Laptop, und irgendwann ziehst du das in deine CI/CD. Es gibt also etwas, das du lokal machst, vielleicht mit einer eingeschränkten Umgebung, so vereinfacht, und das kannst du irgendwie so machen.
Und dann packst du es in die größere, irgendwie besser testbare Umgebung. Dasselbe beim Testen. Es gibt eine Phase, wo du sagst, lass all diese Tests laufen, bis hin zu explorativem Testen. Ich persönlich glaube also nicht, dass die Factory an sich der beste Weg sein wird, schnell zu iterieren, so wie in einer IDE. Das würde ich typischerweise, das behalte ich lokal.
So eine, wo wir eine Factory haben, und ich hasse es irgendwie, das dort zu machen, weil die Latenz, bis man Feedback bekommt, einfach, ja, zu wahnsinnig ist. Und deshalb mag ich die schnelle Innovation. Aber ich kann andererseits, wenn ich so eine Aufgabe habe, wo ich sage, recherchier das, und es legt los, klar.
Und dann schaue ich mir die Ergebnisse an. Da ist es mir ziemlich egal, dass ich auf das ganze Ding warten muss. Es ist also irgendwie so, dass es verschiedene Tools für verschiedene Teile deiner deiner Reise dabei sind. Aber eins ist explorativ. Und ich hoffe, das ist irgendwo eher ein emergentes System der Factories, das wir vorher nicht hatten.
Wir sehen uns jetzt delegieren, so: Hey, weißt du, komm zurück und check den Code. Was verursacht das irgendwie? Okay, eine sehr forschende Sache, oder? Aber es ist nicht so, dass ich coden muss, sondern es muss recherchieren und graben, oder? So, wenn ich selbst reingrabe, dauert das lange. Und ich könnte einfach sagen: Leg los, komm mit den Ergebnissen zurück.
Und das kann ich dann wahrscheinlich irgendwie analysieren. Aber nichts hält uns davon ab zu sagen: Na ja, gib mir vier Optionen. So, das ist auch so eine typische LLM-Agent-Sache. Warum bauen wir also diese Research-Loops nicht in unsere Factories? So, unsere Factory ist immer noch so darauf fokussiert, so: Nimm die Spec und leg los. So, und ich hoffe, da kommt noch mehr.
Und heute Morgen hatte ich eine Diskussion, und jemand meinte: Na ja, ich hasse das Wort Factory, weil es so die Kreativität da drin abtötet. Und dann kam mir die Idee. Ich dachte so: Wie wäre es mit, es ist eine Traumfabrik, oder? So, sie sollte dir erlauben, von Ideen zu träumen, die du umsetzen könntest. Und so verteidigt man, glaube ich, auch viel mehr vom ROI.
Wenn es etwas ist, wo du vor der Factory nie hingekommen wärst, gibt es nicht einfach einen Multiplikator von eins zu X, sondern es geht fast gegen unendlich, weil ich das nicht hätte machen können. So, so, es gibt keinen anderen Weg. Und ich glaube, diese Fälle werden den Wert der Factory noch mehr verstärken, als nur dafür zu sorgen, dass wir schneller werden bei so Testen, Deployen und irgendwie diesen Bereichen. Guter Punkt.
Research Loops und die Traumfabrik
Benedikt Stemmildt
Es geht auch ein bisschen in die Richtung von so Outcome versus Output, oder? Also du könntest im Moment mehr Output bekommen, oder vielleicht sind wir da sogar schon. Aber am Ende wollen wir mehr Outcome, und herauszufinden, was wirklich Outcomes erzeugt, das ist der explorative Teil, oder? Und der Teil mit dem Träumen.
Patrick Debois
Ja. Und deshalb glaube ich auch, dass es jetzt eine engere Beziehung gibt, weil der Product Owner die Factory nutzen kann und so irgendwie die Lücke zwischen ihnen überbrückt wird, wo sie einen Prototyp mit Vibe Coding bauen müssen. Und dann kommen sie zur Factory, und das muss neu gemacht werden. Ich glaube, so, es gibt noch keine Produkte, die versuchen, die zwei Welten zu verschmelzen und irgendwie dahin zu gehen.
Das ist also fast so wie der Upstream, den wir verbessern. Als ich an DevOps gearbeitet habe, hab ich immer gesagt, so, es gibt die Pipeline, die wir kennen, die DevOps Pipeline, aber es gibt auch eine Sales Pipeline. Es gibt eine GTM Pipeline. Es gibt irgendwie eine Legal Pipeline. So, jede, es hat jeder Intake, Triage, so irgendwie was machen, so irgendwie Review, okay, Schleife zurück.
Gut, also, und das ist noch eine Chance. Ich glaube, bei der Factory ist es so, wenn man anfangen kann, das zu verknüpfen, weil der Bottleneck sich verschiebt von, okay, wir können mehr produzieren. Oh, jetzt müssen wir uns irgendwie mehr Sachen ausdenken. Na ja, nein, sollten wir nicht. Aber so, das Ganze ist eigentlich, Nein zu Sachen zu sagen statt Ja, was wir früher nicht konnten.
Und wenn wir das dann produzieren, so, Sales als Nächstes, irgendwie ist die ganze Dokumentation nicht aktuell. Also irgendwie sind all diese Teile neue Chancen, die wir mit einer Factory nicht irgendwie unter Kontrolle halten konnten. Aber es ist nicht nur im Code, so, weißt du, testen und deployen. Es gibt so viel mehr, was wir in eine Factory packen könnten.
Und das ist vielleicht die Vorstellungskraft. Die erste Iteration muss sich auf das einpendeln, was wir haben. Und dann können wir anfangen, was hinzuzufügen. Aber ich warte sehr gespannt darauf, dass wir anfangen, mehr hinzuzufügen.
Kleinere Teams, verschmolzene Rollen
Benedikt Stemmildt
Super inspirierend. Ich meine, die Frage, die mir sofort in den Kopf kommt, ist so etwas wie: Das wird wahrscheinlich auch auf der organisatorischen Ebene viel verändern, oder? So, wie bauen Organisationen eigentlich so Teams und Abteilungen und so weiter auf? Und wie macht man Leadership? Haben wir da irgendeine Idee, was denkst du darüber?
Patrick Debois
Also das, na ja, es gibt diese ganze Vorstellung, Agile ist tot, aber es ist nicht tot, weil es dieselben Praktiken sind oder schnelles Feedback. Und man geht so auf, weißt du, das, was zählt. Die Zyklen von Scrum allerdings, die, zum Beispiel, die würden sich ändern, weil man, statt nur darüber zu reden, es einfach machen könnte und irgendwie die Ergebnisse liefern.
Eine andere Sache, die sich ändert, ist, weißt du, früher hat jemand ein Ticket aufgemacht und musste dann auf Engineering-Kapazität warten. Es lag im Backlog. Jetzt könnten sie einfach die Factory starten, so, okay, lass uns ein Gespräch führen. Was ist es? Also, woran scheitert es? Einfach den PR erstellen und fast die ganze Arbeit machen.
Und dann reviewt der Engineer. Es gibt also irgendwie eine Chance, so zu kleineren Teams zu kommen, wo es früher vielleicht acht waren, zwischen, weißt du, irgendwie auf dem Niveau. Näher an vier oder fünf heranzukommen, auf eine gute, konsistente Art. Aber es gibt immer noch die Frage, die Codebase zu verstehen, finde ich, obwohl KI dabei auch hilft.
Aber es gibt ein gewisses Maß an fast so latentem Wissen, das jemand im Team haben muss, um zu verstehen, wie "gut" aussieht, was die Entscheidung über die Auswirkung von Entscheidungen ist, und so weiter. Es ist also fast so, als wären wir wieder bei, wir würden jetzt gern die Product- und die Engineering-Rolle zu einer verschmelzen, weil sie es könnten.
Aber nicht jeder, der Engineer ist, ist ein guter Product Owner, und andersherum genauso. Es ist wie Full Stack, weißt du, Full Stack in allem, vielleicht. Also legen wir da sogar noch mehr Augenmerk drauf. Aber generell suche ich irgendwie nach Überlappung. Es ist also ähnlich wie bei DevOps, die T-shaped People, die überlappen, die arbeiten irgendwie zusammen.
Also jemand mit mehr Product-Affinität von der Engineering-Seite und jemand mit Engineering. Natürlich ergibt das mehr Sinn, weil es da eine gemeinsame Sprache gibt. Ich glaube, es gibt immer noch, wenn man anfängt, Dinge in größerem Maßstab zu machen, braucht es irgendwo Aufmerksamkeit auf der operativen Seite. Es ist nicht nur die Seite des Erstellens, sondern es gibt das Operative. Obwohl KI uns da auch helfen wird.
Ich bin jetzt also so bei Dev, PM und der Ops-Person. Und dann würde ich sagen, man sollte fast, ich würde es nicht Trainee nennen, aber die Person, die irgendwie irgendwo das Backup ist. Weil das immer noch ein Faktor ist, dass so eine Person, das sind Menschen, die können gehen, die sind nicht verfügbar. Ja, es gibt eine Factory, aber so irgendwie fast so ein Aufseher über die Domäne.
Und wenn man diese Person also nicht reinnimmt, und das könnte ein Junior sein, der irgendwie neben den anderen mitlernt, oder es könnte einfach eine Backup-Person sein, von der man sagt, die setzt man da rein. Also ich persönlich würde nicht unter vier gehen. Man könnte niedriger gehen, aber dann vergisst man irgendwie die nachhaltige Basis, das Risiko, dass eine Person weggeht, das fühlt sich für mich wie die Untergrenze an.
Benedikt Stemmildt
Ja, ich glaube auch, dass es oft auch diese Schnittstelle zur Außenwelt gibt. So, es kommen viele Leute von außen, die etwas von dir wollen. Also muss das auch irgendwie jemand abpuffern, oder? Damit das Team produktiv arbeiten kann. Weniger als vier ist also tatsächlich super klein.
Patrick Debois
Ja, aber ich würde nicht niedriger gehen. Aber es gibt Leute, so, ich bin Solo-Founder. Und natürlich kann man alles machen, wenn man so hat, und je mehr Verbindungen man kappt, was das Kommunizieren-Müssen angeht, da gibt es einen gewissen Anteil an Schneller-Werden, aber, weißt du, da steckt irgendwie definitiv ein Bus-Faktor drin. Und es gibt einen limitierenden Faktor.
Aber für dein Solo-Projekt ist das vielleicht in Ordnung. Und du bringst es raus. Aber es läuft wieder darauf hinaus, so, was ist das Risiko, oder? Wenn du nicht rechtzeitig reagierst, was ist das Risiko für deine Kunden? Wenn Systeme irgendwie schiefgehen, wie ist deine Reaktionszeit? Und das macht mich irgendwie immer unruhig, wenn Leute sagen, na ja, ich schaue mir den Code nicht mehr an.
Und dann grabe ich nach. Okay, du schaust dir den Code nicht mehr an. Na ja, ich habe meine eigenen Verifier. Okay, das ist super. Und dann, und dann frage ich sie, was ist die Auswirkung? Na ja, ich bin Solo-Dev. Mir ist das egal. Natürlich kannst du das machen. Mach es. So, das interessiert niemanden. Großes Unternehmen. Da ist es anders, oder? So, da geht es um Geld, so Auswirkung.
Deshalb sage ich, es gibt Abstufungen bei den Leuten. Und die erzählen normalerweise nicht die ganze Geschichte, was sie machen und wie sie aus ihrer Perspektive mit diesem Risiko irgendwie umgehen.
Benedikt Stemmildt
Also ja, und ich finde, es ist auch in größeren Unternehmen oder generell echt schwer für eine Person, von außen auf sich selbst zu schauen. So, was mache ich eigentlich Tag für Tag? Sogar auch für die Engineers, weil, ich meine, das ist etwas, was man machen müsste, um so eine Factory mit geringem Risiko zu bauen, oder?
Man müsste sich selbst analysieren. Was machen wir? Das dann nehmen und bauen. Ich finde, da entsteht vielleicht auch so etwas wie eine neue Rolle, oder unsere aktuellen Rollen verändern sich ein bisschen dahin, dass manche Engineers in der Lage sind, das zu tun, von oben drauf zu schauen auf das, also, du weißt, was ich meine, oder? Mehr über den Prozess zu reflektieren, wie sie eigentlich Sachen engineeren.
Patrick Debois
Das sind Systemdenker, oder? So, das ist irgendwie das, wonach man sucht. Und das System abzuklopfen, das ausgefallen ist. Als sich die CI/CD-Pipeline rund um DevOps irgendwie gesetzt hatte, kam die Rolle des Chaos Engineers auf, der im Grunde das System abgeklopft hat, ob es noch funktioniert, und irgendwie Hypothesen aufgestellt hat und irgendwie fast so wie Feuerübungen.
Das wird wahrscheinlich auch in Zukunft da sein, während sich das irgendwie weiterentwickelt. Wir müssen die Sicherheitschecks in Ordnung haben. Wir müssen sicherstellen, dass die Backups da sind. Also, ich sehe nicht, dass das verschwindet. Aber natürlich kann man sagen, das Einzige, was ich tun muss, ist, uns zurückzugeben, und dann wird sich darum gekümmert.
Aber das sind, ja, normalerweise Leute, die vielleicht nicht den länger laufenden Ops-Betrieb gemacht haben, Dinge werden ausfallen und damit muss man umgehen, meiner Meinung nach.
Benedikt Stemmildt
Meiner Erfahrung nach steckt hier auch eine Menge Engineering-Skill drin, oder? Also, um diese State Machines zu bauen, um diese Factories zu bauen und um systemisch darüber nachdenken zu können, was man da macht, braucht man das ganze Engineering-Wissen. Man kann nicht einfach sagen, na ja, das LLM wird das schon irgendwie machen, oder?
Patrick Debois
Ich glaube, die sind versiert in irgendwie mehr dem Agentic Engineering und die bewegen sich Richtung Factory und lernen im Grunde diese Factory und die Loops und Sandboxes und Kosten und all die Dinge, die typischerweise in eine Plattform reingehen würden. Oder es ist andersherum. Leute sind es gewohnt, eine Plattform zu betreiben, und die sagen, na ja, wir könnten die Agenten reinholen.
Wir können auch irgendwie diese Teile reinholen. Jetzt gibt es eine breitere Streuung von Wissen, und wie du erwähnt hast, dass sich Dinge in einer Organisation verändern. Ich finde, es ist keine so klare Trennung, aber grob würde ich sagen, es wird Leute geben, die arbeiten und die Factory zum Laufen bringen und sie am Brummen halten, und es gibt Leute, die wahrscheinlich mehr Spec machen, technische Anforderungen, und da reingehen.
Das Schöne ist, dass die Factory als solche ein bisschen ein Ausweg ist für die eher technischen Leute, die sich nicht gut darin wiederfinden würden, nur Specs zu schreiben. Aber es gibt auch, wie du sagst, vielleicht erfordert es etwas Erfahrung. Es geht nicht ums Alter, sondern mehr so darum, okay, bei wie vielen der Meta-Bausteine, die man da einbauen kann, man die Wirkung sieht.
Wenn ich hier einen Prompt ändere, was passiert dann da? Na ja, was sind die Risiken bei meiner Sandbox? Oder wie steigen die Kosten? Man bekommt also einen ganzheitlicheren Blick auf das Ganze, um darüber nachzudenken. Also, aber ja, ich glaube, da gibt es ein logisches Plattform-Stück, aber es ist unsicher, ob es eher von der Seite der KI-Engineers oder eher von der Plattform-Seite übernommen wird. Ich bin noch, da ist das letzte Wort noch nicht gesprochen, glaube ich, in der Branche.
Factories als Plattformen
Benedikt Stemmildt
Ja, das erinnert mich wirklich an die frühen Cloud-Tage, als noch nicht wirklich klar war, wo die richtige Abstraktionsebene sein würde und wie man eigentlich, weil diese KI-Plattformen mehr sind als eine Infrastruktur. Da steckt viel Prozess drin oder Regeln und so weiter. Sind Regeln schon Teil der Plattform oder ist das etwas, das man von außen reingibt und so weiter? Ich habe das Gefühl, darauf haben wir noch nicht wirklich eine Antwort.
Patrick Debois
Nein, aber ja, die Plattform ist nie nur eine Maschinerie. Es geht also immer so darum: Was ist dein Geschäftsprozess? Wie willst du deployen? Was ist das Risiko? Es ist also eine sehr ähnliche Diskussion, wie wenn man so neue Projekte auf eine Plattform onboardet, aber es kommt drauf an. So manche Leute sagen einfach: Ich habe die Plattform gebaut. Mir ist egal, wer darauf läuft, aber das ganze Narrativ, die Plattform als Produkt zu betreiben, heißt, deinen Kunden zuzuhören, was sie brauchen.
Und das heißt im Grunde, hinzugehen und zuzuhören. Was brauchst du? So, wie müssen wir uns anpassen? Was ist nützlich? Was ist wichtig für dich? Und sie dann auch auf diese Factory zu holen.
Benedikt Stemmildt
Ja, interessant. Mir gefällt auch die Idee richtig gut, diese Rollen ein bisschen aufzuteilen in Leute, die die Factory bereitstellen oder daran bauen, also eher als Platform Team, vielleicht. So etwas in der Art. Wir wissen es noch nicht wirklich, aber es könnte sein. Und dann die Leute, die vielleicht eher richtig gut darin sind, die explorative Arbeit und die kreative Arbeit zu machen, und mehr auf der Produktseite sind.
Und dann muss es diese Übergabe geben. Und beide haben wahrscheinlich auch ein anderes mentales Modell davon, was sie gerade eigentlich sind. Du hast diesen Latent Space erwähnt. Ich weiß nicht. So, für mich hätten beide Gruppen wahrscheinlich ihr eigenes mentales Modell davon, was sie bauen, und beide sind sehr wertvoll. Weißt du? Aber ich glaube, da ist...
Patrick Debois
Na ja, in deiner Plattformsprache würdest du sagen, es gibt die Feature Teams und das Platform Team. Nein, man weiß noch nicht, ob diese Zentralisierung etwas ist, bei dem wir landen werden. Oder ob es am Ende eine sehr konfigurierbare SaaS-Lösung wird, mit der jeder seine eigene Pipeline baut. Aber es ist ein bisschen so wie früher, wenn man als Platform Team einen CI/CD-Flow vorgegeben hat, ist der selten innerhalb eines Teams Vanilla geblieben.
Die haben ihn alle in irgendeine Form oder irgendeine Variante angepasst, so: Na ja, weißt du, ich will diesen Linter laufen lassen. Und deshalb muss es konfigurierbar sein, aber die Maschinerie vielleicht, weißt du, wir implementieren nicht alle irgendwie Prompt-Injection-Erkennung oder so neu, oder? Oder keine Registry oder irgendwie so ein Inference Gateway. So, niemand... Aber wir wollten alle, dass es an einen Workflow angepasst ist, um damit loszulegen.
Es ist also ein bisschen so wie damals, als das mit GitOps aufkam. So, wir definieren es, aber die Plattform wird tatsächlich zentral betrieben, mit diesen Teilen auch.
Benedikt Stemmildt
Ich meine, als die Person, die eher das explorative Zeug machen würde, will ich auch nicht so das alles wissen müssen, oder? Ich will es einfach haben, okay, ich kann Inference nutzen und es ist sicher. Check. Richtig. Und jemand anders kümmert sich um das ganze Zeug, damit es für mich sicher zu nutzen ist.
Patrick Debois
Na ja, es gibt keine vollständige Abstraktion. Und ich gebe mal ein Beispiel. Sagen wir, du wechselst in deiner Factory auf ein neueres Modell. Okay. Die Auswirkung auf mich, wenn ich Prompts schreibe und Teile schreibe. Das ist also etwas, das immer noch passiert. Aber das ist dasselbe, wie wenn ich meine Version von was auch immer upgrade, für eine Zelle oder auf eine neue Version, muss ich ein Upgrade machen.
Dependencies und Upgrades wird es also auch in Factories weiterhin geben. Aber, weißt du, wir bekommen vielleicht einen Pull. Hey, weißt du, wir haben das gemacht, wir haben deine Tests damit proaktiv für dich laufen lassen. Aber dann bei einem Major Upgrade, so, was machen wir dann? So, wir alle mögen irgendwie so das Genörgel bei Security. Wir hassen es total, oder? Also ist es wahrscheinlich eher andersrum. Aber ja, wahrscheinlich.
Benedikt Stemmildt
Ich meine, deine Factory ist auch ein Produkt, oder? Also bräuchtest du, wie du sagst, bräuchtest du so Dependency Updates für die Teile der Factory da drin auch. Und dann, ja, wenn sich das Modell ändert, wird es eine größere Änderung geben, oder? Ich glaube, das ist so Teil des Problems, warum wir diese Abstraktionsebene noch nicht wirklich kennen.
Denn wenn sich das Modell ändert, und eine Menge von deinem nicht-deterministischen Zeug ändert sich sofort, weil du es neu konfigurieren musst. So, ich weiß nicht, so ein bisschen wie Reverse Engineering, so, wie verhält sich das Modell in bestimmten Szenarien, und dann irgendwie Regeln raus und neue Regeln rein und so weiter, je nachdem, welches Modell du wählst, oder? Es ist so, genau.
Patrick Debois
Ja, und normalerweise gibt es eine Migrationsphase von, hey, weißt du, das zentrale Team bereitet das Upgrade vor und nimmt die üblichen Use Cases und testet sie und sieht, was das Muster ist. Sie versuchen, das zu extrapolieren. Sie machen daraus ein paar Tools. Vielleicht, weißt du, gibt es für das Modell so ein paar Evals. Die kann man laufen lassen und sehen, was das Modell liefert.
Aber es ist immer noch viel Engineering, so auf beiden Seiten, um irgendwie mit dieser Art von Komplexität umzugehen. Die Power ist also großartig. Aber so, was viele Leute vergessen, ist: Ja, es gibt immer noch Arbeit, wenn das passiert. Und die Auswirkung auf diese Flows ist größer, so, Dinge in einem Prompt zu reduzieren. So, es ist ziemlich einfach, Dinge zu einem Memory hinzuzufügen und Dinge zu einem Prompt hinzuzufügen, aber Dinge zu reduzieren.
Ich so: Was, was soll ich rausnehmen? So, na ja, lass mich mal checken, was das Modell schon weiß. So, was kann es? Und irgendwie diese, ja, sehr interessanten Fragen. Und ich glaube, ich habe mit dir, einer Person von Anthropic gesprochen, die damit zu tun hat, so, jedes Mal, wenn es ein neues Modell gibt, müssen sie zu Kunden gehen und sagen: Hey, Vorsicht, macht was damit.
Und das wird in der Factory nicht anders sein, aber es ist ein großes Cloud-Upgrade. Es ist dasselbe. Es ist also irgendwie so.
Was wird aus den Juniors?
Benedikt Stemmildt
Um ein bisschen in eine andere Richtung zu gehen, aber an etwas anzuknüpfen, das du vorhin erwähnt hast, den Junior in die Organisation reinzuholen: Ich mag die Idee wirklich, dass diese Backup-Person ein Junior ist oder so jemand, der so ein Trainee ist oder vielleicht noch nicht so weit ist, oder so, weil das gerade so eine riesige Diskussion ist.
So, wie gehst du damit um, ich meine, wir haben ja gesagt, diese Factory-Builder sind wahrscheinlich so Systemdenker. Also muss man irgendwie zum Systemdenker werden, oder? So, das ist normalerweise, ich meine, es ist nicht das Alter, wie du gesagt hast, aber es ist eher so, ja, man braucht so Erfahrung dafür. Keine Ahnung. Es gibt diese riesige Diskussion. Wie, was wird damit passieren? Also, wie machen wir das? Wie machen wir es? Was ist deine Idee dazu?
Patrick Debois
Das ist eine häufige Frage. Und sie geht in beide Richtungen. Seniors sagen mir oft, na ja, die Juniors werden keine Gelegenheit haben zu lernen. Genau. Und dann sagen mir die Juniors, wir können schneller lernen als alle anderen. Großen Dank an KI. Es geht also in beide Richtungen. Aber es geht irgendwie darum, damit in Berührung zu kommen, ein bisschen Anleitung, ein paar Lektionen. Deshalb sage ich, das Alter ist nicht per se irgendwie der Punkt, aber sie mit auf die Reise zu nehmen, ergibt irgendwie Sinn.
Und es ist nicht nur so. Sie lernen die technischen Details des Systems kennen, aber auch das Business. Genau. Deshalb sage ich, man kann im Engineering Senior sein, aber trotzdem Junior in der Domäne oder bei dem Problem, das man da auch zu lösen versucht. Es war also nicht per se eine Illusion, aber ich denke schon, dass das im Allgemeinen noch nicht entschieden ist.
Einerseits sagen die Leute immer, es gibt das Risiko, dass Automatisierung die Anzahl der Leute reduziert. Ich sage es jetzt. Cloud, DevOps, jedes Mal gibt es anfangs diese Diskussion. So, etwas wird automatisiert und dann wird reduziert. Und meine Parallele wäre, wenn man an Fotografie denkt: Man hat ein Handy, das kann ein Foto machen. Es gab also einerseits weniger professionelle Fotografen, aber es gab eine Explosion von so YouTube-Leuten, oder?
Also so, wo reduziert die Komplexität irgendwie die Anzahl der Leute und welche neuen Arten von Rollen bringt sie mit sich? Und irgendwie gibt es vielleicht etwas in der explorativen Phase oder etwas in der Engineering-Phase. Also bisher war es bei den Wellen, die ich gesehen habe, so, dass es, ja, eine Reduktion gibt, aber dann gibt es eine ganz neue Welt neuer Rollen.
Und da blühen die Juniors dann vielleicht irgendwann auf. Und es gibt auch ein gewisses Maß an Reduktion von Komplexität. In den frühen Tagen, CI/CD, waren die Dinge wirklich komplex und chaotisch, und man musste wissen, was man tut. Und dann hat sich das zu dieser fast so sehr zugänglichen Art geformt, Dinge zu tun und irgendwie zu definieren. Und es war leicht, jemanden in diesen neuen Flow reinzuholen.
Und dann haben sie den neuen Flow erlebt, und dann konnten sie etwas über den Flow lernen. Es ist also eine andere Art, mit dieser Komplexität umzugehen.
Benedikt Stemmildt
Ja, ich meine, CI/CD ist ein schönes Beispiel, finde ich. Ich bin ein riesiger Fan von GitLab CI/CD. Ich finde, das hat uns wirklich auf das nächste Level gebracht. Und wenn Leute jetzt anfangen, es zu benutzen, brauchen sie nicht die Erfahrung von der Reise, die es gebraucht hat, um dahin zu kommen, um es jetzt einfach zu verstehen und zu benutzen, oder?
Und ich war einer der Ersten, die auf Node.js aufgesprungen sind. Und ich habe das Gefühl, wenn man die frühen Tage von Node.js mit dem vergleicht, wo wir jetzt sind, gibt es auch das, ja, man kann es jetzt benutzen, ohne wissen zu müssen, wie wir dahin gekommen sind, weil es super chaotisch war. Und ich glaube, ich meine, Node ist an vielen Stellen immer noch super chaotisch, oder?
Patrick Debois
Es ist ein Privileg, irgendwie mitzuerleben, wie ein neues Feld entsteht, bei dem man sagt, oh, das wurde erkundet. Oh, das war diese Richtung. Aber an einem gewissen Punkt wird das nutzlos, und doch nicht nutzlos, oder? So, nutzlos in dem Sinne, dass man es nicht im Alltag braucht. Aber wenn es da so eine bestimmte Sache gibt, so, warum wurde die Entscheidung getroffen?
Dann ist es so, ja, deswegen. So, man weiß nicht, dass es deswegen war. Und das ist nützlich. Aber ich verstehe auch Leute, die sagen, wir überspringen das, bis es ausgereift ist. Und dann steigen wir ein, und die werden eine andere Art von Lernerfahrung damit haben. Ich schätze, wir beide sind wahrscheinlich eher so süchtig nach den neuen Dingen und verstehen irgendwie die neuen Dinge.
Aber das ist irgendwie eine, wahrscheinlich eine Persönlichkeitssache, oder so, warum wir jetzt hier in diesem Bereich und in diesem Podcast sind.
Benedikt Stemmildt
Also ja, ich meine, meine Sicht ist auch, wie du sagst, von der Persönlichkeit her mache ich das wirklich gerne. Aber ich habe auch das Gefühl, dass es auch sehr vorteilhaft ist, diese Dinge schon jetzt zu machen, statt zu warten, oder? Weil, ich meine, in der Vergangenheit war das nicht so klar, so ein bisschen klarer. Aber so mit CI/CD Pipelines und so weiter war es trotzdem ein riesiger Haufen Arbeit, um einen kleinen Vorteil zu gewinnen.
Aber jetzt mit KI habe ich das Gefühl, dass sogar die kleinen Sachen, die man jetzt machen kann, einem schon einen riesigen Vorteil verschaffen im Vergleich zu Leuten, die warten und es gar nicht machen, oder?
Patrick Debois
Ja, das ergibt Sinn. Man muss Arbeit reinstecken. Das ist eine von diesen, wie fangen wir an? Das ist eine Frage, die ich oft bekomme, und es ist so, ja, such dir einfach ein Projekt aus, fang an, es zu machen. So, man kann Bücher lesen, aber das geht komplett an einem vorbei, wenn man nicht selbst drinsteckt, weshalb ich ihnen sage, so, sucht euch ein Projekt aus, das euch wichtig ist, so etwas, das ihr selbst verbessern wollt, und taucht einfach ein.
Ist das der effizienteste Weg? Es gibt verschiedene Arten zu lernen. Wenn es irgendwie gut aufbereitet ist, könnte man wahrscheinlich viel mehr Informationen aufnehmen, als wenn man in das Feld reinstolpert, aber es gibt trotzdem viel Verschwendung, weil man sich alle Videos, alle Blogposts anschauen muss, oder? So, irgendwas setzt sich irgendwann, und den ganzen Rest kann man irgendwie vergessen.
Aber ich glaube, es ist ein bisschen wie beim Handwerker, oder? So, beim Handwerker geht es darum, viele Werkzeuge am Gürtel zu haben und irgendwie zu wissen, wann man das richtige nimmt. Und das heißt nicht, dass man nicht auch mit ein paar Werkzeugen auskommt, wenn das das Ding ist, das man macht, aber das ist das, was man auf der Reise aufsammelt.
Und ich hatte das schon oft, dass ich in diese Rabbit Holes reingehe und die zu nichts führen, aber so, weißt du, fünf Jahre später ist es so, wow. So was in der Art.
Benedikt Stemmildt
Ich meine, um das ein bisschen abzurunden, auch wieder in Richtung Risiko, es ist so, oder so, wie implementieren Unternehmen jetzt eigentlich Factories in ihrer täglichen Arbeit, und das Lernen von, ich habe das Gefühl, dass es oft nicht wirklich eine technische Lernsache ist. Es ist eher so, dass die Organisation drumherum sich verändern und anpassen muss. So wie, wenn wir Agile in diesen Unternehmen einführen, geht es nicht wirklich ums Lernen in dem Sinne, dass ich gelernt habe, was Agile ist.
Ich meine, es ist ein sehr kurzes Buch. Es gibt also nicht viel zu lernen, was so die Theorie angeht. Und es gibt viel zu lernen, was so echte Erfahrung und das echte Machen der Arbeit angeht. Was ist also deine Sicht darauf, so in Bezug darauf, wie man das jetzt bei der Factory macht? Wie, wie sollten Unternehmen damit anfangen?
Patrick Debois
Ich habe also angefangen, den Unterschied zu sehen zwischen Leuten, die lokal auf ihrem Laptop an ihrem Agent arbeiten und ihn irgendwie tunen. Sie fügen ihr eigenes Zeug und ihre eigene Note hinzu. Dann haben sie angefangen, Dinge wie Shared Context und ihren Harness mehr ins Repo einzuchecken. Und dann wurde das quasi über die Factory auch anderen Leuten zugänglich gemacht.
Diese Art von Sichtbarkeit war also wahrscheinlich der größte Impact. Ja, der Schritt von solo zu irgendwie diesem Team war insofern nützlich, dass, oh, wir halten uns jetzt alle an dieselben Standards, und da lief so eine Art Alignment. Die Tatsache, dass man jetzt Tickets an eine Factory stellen und sagen kann, bitte mach das, bitte gib Kommentare, bitte hilf mir hier.
Das hat es einerseits irgendwie geöffnet. Da war so, es wurde im Unternehmen demokratisiert, eine Änderung zu machen. Das war also definitiv eine Veränderung. Und dann die Tatsache, dass es das ganze Wissen wiederverwenden konnte, das da war, weil wir zur Factory beitragen und sie robuster machen. Das heißt, es hat einen Wert, Dinge nicht neu erfinden zu müssen.
Und ich habe vor Kurzem einen Talk gehalten, und ich würde sagen, dass all die Deployment-Metriken immer noch Sinn ergeben. Okay, robust, und es muss rausgehen, und Tests und Escape Rates und alles ist gültig, und Delivery, die Geschwindigkeit der Delivery, so, was auch immer man da wertschätzt. Aber ich glaube, dass die Anzahl menschlicher Berührungspunkte in Prozessen sinkt, ist definitiv eine, weil das diese Effizienz schafft.
So, wir müssen nicht alle Leute einbinden. Und die zweite ist, wie viel davon von anderen Leuten wiederverwendet wird. Wenn man also die Factory als Service anbietet und alle dasselbe Wissen nutzen können, dann bekommt die Arbeit, die man in der Factory gemacht hat, nicht nur einen Multiplikator auf dem eigenen Laptop, so nach dem Motto, ich bin X besser geworden, sondern die ganze Organisation ist darin besser geworden.
Und dann sind das, glaube ich, so zwei Metriken: so, die Anzahl menschlicher Berührungspunkte reduzieren. Wenn man kann, mit dem richtigen Risiko und all den Dingen, die dazugehören. Also nicht YOLO machen, aber dann irgendwie, wie viel davon wird im ganzen Unternehmen wiederverwendet? Das ist meine zweite Metrik, um darüber nachzudenken. Und ich glaube, die Factory irgendwie und das Interface, ob das ein Chat-Interface ist oder ob es auf unsere Tickets schaut, oder etwas, das diese zwei irgendwie so Werte oder Metriken verkörpert, muss ich sagen, um da irgendwie Verbesserungen zu bekommen.
Zwei Metriken für eine Software Factory
Benedikt Stemmildt
So wie du das beschreibst, klingt das für mich auch so, als wäre das ein sehr strukturierter und bewusster Prozess, das zu machen. Und dass die Factory dabei auch hilft, weil ich viele Firmen sehe, die so sind: Jeder nutzt das einfach auf seinem Laptop, so super chaotisch. Jeder hat einfach, keine Ahnung, sein eigenes Setup und ich brauche mehr Token.
Ich brauche mehr Token und so weiter. Aber es scheint, als bräuchte es so ein Programm drumherum, das sagt, okay, wir wollen eine Factory bauen, wir wollen da hinkommen. Und was denkst du?
Patrick Debois
Es gibt Geschichten, die von dem erzählen, was fast so, was ich Dev Factories nennen würde. Tatsächlich laufen die auf ihren Laptops, und die sind besser geworden, und die Harnesses kümmern sich irgendwie darum. Aber wonach ich normalerweise schauen würde: Die Factories sind die, die in der, nicht nur in der Cloud sind, weil man sein Developer-Ding ja auch in die Cloud packen könnte, sondern die Tatsache, dass es zentralisiert wird und übergreifend wiederverwendet wird.
Und ich glaube, das ist das, was die Ubers, die Ramps, so all diese zentralisierten Engineering-Gruppen in ihren Firmen machen. Und ich glaube, da multiplizieren sich die Vorteile. Ich sage nicht, dass eine Dev Factory schlecht ist oder so, aber es ist nicht so, sie bringt dich schon auf ein Level, aber wenn dein Kollege sie nicht nutzen kann, ist der Impact begrenzt.
Deshalb sage ich so: Von Solo zu Shared zu Multiplayer ist manchmal ein Spruch, den man hört, und dieses Multiplayer, also eine Factory, die als Self-Service für die ganze Org bereitgestellt wird, könnte viel mehr versprechen, als sie solo in deiner, in deiner Umgebung zu haben. Und ich habe sogar angefangen, darüber nachzudenken, so, viele Leute reden davon, ich kann Skills installieren, und ich habe angefangen zu denken, so, deployen wir nicht eigentlich Skills?
So, sollten wir die nicht irgendwie zentral bauen und dann wiederverwendbar machen, so irgendwie, wir machen das ja in gewisser Weise, weil unsere Coding Agents uns irgendwie erlauben, das zentral abzuholen, aber es ist fast so, als würde ich das zentralisieren und in so einem Service-Modus verfügbar machen wollen, dass jeder meinen Skill sofort nutzen kann, mit den richtigen Credentials, mit der richtigen Umgebung, mit den richtigen Sachen, die angebunden sind, und von da aus weiter.
Benedikt Stemmildt
Also ja, das ist interessant. Es ist interessant zu sehen, wie, ich meine, das Feld entsteht ja noch, oder? Und jetzt haben wir diese Idee von Plugins, und vielleicht wird es so mehr eine Art Installer dafür geben. Und so richtig herausgefunden haben wir das noch nicht, oder?
Patrick Debois
Aber es sind Denkmuster, oder? Okay, wir haben Skills. Die wurden zu Plugins. Vielleicht ist das Nächste, dass wir Loops haben werden, die man in seiner Factory installieren kann, was der Fall zu sein scheint. So, viele Leute reden über Loops. Du installierst, dein Code Review ist ein Loop. Dein Spec-to-Code ist ein Loop. Das wird also irgendwie zu einer neuen Entität, an der man arbeitet.
Und vielleicht wird es dann wieder so austauschbar. Vielleicht müssen wir über austauschbare Factory-Configs nachdenken. Weißt du, irgendwann kommen wir da hin, Kompatibilität von einer Factory zur anderen. Sodass man so, es ist, es ist extravagant. Wir sind noch nicht da, aber das ist, das ist, das ist fast das coole Zeug, über das man anfangen kann nachzudenken.
Benedikt Stemmildt
Also ja, also da wir, da wir uns dem Ende unserer Zeit nähern, nähern, habe ich noch eine letzte Frage. Also, was würdest du den Leuten raten, jetzt zu tun? So, wenn sie die Episode, keine Ahnung, in ein paar Wochen hören. Was ist das, worüber Leute deiner Meinung nach nachdenken sollten oder womit sie anfangen sollten? Ich weiß, es ist nicht nur eins.
Patrick Debois
Hängt natürlich definitiv von deiner Reife ab. Aber wenn du gerade erst anfängst, fang einfach an, damit zu spielen. So irgendwie, je mehr Erfahrung du damit sammeln kannst, und mach das, wie gesagt, mit etwas, das dir wichtig ist. Und wenn du erfahrener wirst, denk darüber nach, wie ich raten würde, so, bitte denk über den reinen Coding Loop hinaus und geh ins Unternehmen.
Und ich sage oft, dass es bei Senior Engineers nicht nur darum geht, besseren Code zu bauen. Die gehen ins Business, die denken über Architektur nach, die denken über Kosten nach, die denken auch über andere Werte nach. Also fang an, das zu erkunden. Und vielleicht ist es in dem Zuge so, finde heraus, wo willst du hin? Willst du mehr ins Platform Team, willst du mehr ins explorative Spec Team, und versuch irgendwie, deine Karriere dort zu gestalten.
Natürlich wird es neue Akronyme geben für Deployed Engineer, KI-Product-Engineer. Und wir werden für alle einen Namen haben. So irgendwie, such dir deinen eigenen Weg und so, ja, lern mehr, würde ich sagen. Das ist gerade das Motto.
Benedikt Stemmildt
Vielen, vielen Dank, Patrick. Mir hat diese Episode echt Spaß gemacht. Ich glaube, wir hatten hier viele Erkenntnisse. Ich hoffe, wir sehen dich wieder. Ich glaube, du bist auf, bist du dieses Jahr auf der code.talks? Oder ich bin mir nicht sicher, ob du da bist.
Patrick Debois
Leider nicht. Ich kuratiere eine andere Konferenz.
Benedikt Stemmildt
Okay, okay.
Patrick Debois
AI DevCon in New York.
Benedikt Stemmildt
Oh, wow.
Patrick Debois
2. bis 4. November, und ich kuratiere das Programm, und das Thema ist Factories. Also hey, ja, du kannst ja genauso gut kommen.
Benedikt Stemmildt
Oh, vielleicht fahre ich da hin. Ich war noch nie in New York. Ja, das wäre super. Vielen, vielen Dank. Und ja, hab eine tolle Zeit, und bis bald.
Patrick Debois
Danke, dass ich dabei sein durfte. Das weiß ich echt zu schätzen.
Benedikt Stemmildt
Vielen Dank fürs Zuhören. Das war eine weitere Episode von Rethink Engineering. Patrick, auch dir vielen Dank. Ich habe es echt genossen, dich hier in der Show zu haben. Ich hoffe, ich werde besser darin. Mal sehen, was die Kommentare sagen. Es war mir ein Vergnügen, den Factory-Teil zu machen. Wenn ihr mehr darüber lernen wollt, bleibt dran. Folgt uns.
Oder trefft Patrick in Brooklyn auf der AI DevCon. Nein, 2. bis 4. November. Dort werdet ihr viel mehr über Software Factories lernen. Er kuratiert auch ainativedev.io. Also schaut da vorbei. Die Links findet ihr in der Beschreibung. Und jetzt ist es endlich so weit, dass wir eine Episode mit Deejay haben werden.
Ich freue mich echt, dass er dabei ist, und wir werden herausfinden, was er gerade macht, ob er öfter dabei sein wird. Und ja, ich glaube, das war's. Das war Rethink Engineering mit hackers&wizards und re:cinq. Bis zum nächsten Mal. Tschüss.