Latest / Beyond Vibe Coding / #062 Ein Deep-Dive in Dark Factories (audio fix)

Transcript

#062 Ein Deep-Dive in Dark Factories (audio fix) · Beyond Vibe Coding

• Sebastian: willkommen Andre heute mal ohne externen Gast. Heute sprechen nur wir zwei genau über ein Thema, was uns eigentlich schon lange unter den Nägeln brennt. Wir hatten aber immer so einen vollen Terminkalender mit ganz tollen Gästen, dass wir es noch nicht geschafft haben, eher mal darüber zu reden. Aber das Thema Dark Factory geistert jetzt schon noch ein paar Monate durch die lande und es ist inzwischen viel darüber geschrieben worden sehr gute sehr umfangreiche artikel und wir möchten heute mal so den versuch wagen bisschen durchzugehen was so alles geschrieben wurde welche aspekte da relevant sind das hat keinen anspruch auf vollständigkeit und das thema wird sich mit sicherheit auch noch weiter entwickeln über die nächsten monate und vielleicht auch jahre aber wir wollen einfach mal einen abriss machen wie wir gerade das thema dark factory sehen genau Schieß los! André Neubauer: Ich würde eigentlich bloß hinzufügen, ich glaube, ist, wir hatten es ja auch gerade schon, kann man ja auch erzählen, bevor wir hier eine Aufnahme starten, also die Aufnahme läuft eigentlich ganz Zeit mit, aber bevor wir hier tatsächlich gesprochen haben, quatschen wir ja immer schon so ein bisschen. Und ich glaube, du hast einen wichtigen Punkt gesagt. Ich glaube, jeder sollte das Thema, also jeder Tech-Leader, jeder CTO, VP Engineering, ehrlich gesagt auch die ganze Produktseite, also eigentlich alle. die irgendwas mit Produktentwicklung zu tun haben, sollten das den Begriff eigentlich kennen und einordnen können, weil der im Endeffekt dafür steht, quasi also steht im Endeffekt für Beyond Vibe Coding. Und ich glaube, das war gerade eben im Vorgespräch, fand ich das halt von dir nochmal eine mega Brücke. Deswegen heute nur das erste Mal. Das ist etwas, was wir hoffentlich noch ein paar Mal streifen werden, so ein bisschen als, vielleicht ist das auch ein Referenzmodell. Sebastian: absolut genau und genau du hast ja umfangreich dich vorbereitet auf die episode deswegen vielleicht machen wir so ein bisschen so dass ich dich auch so ein bisschen interview ich gebe natürlich auch immer mein selbst dazu aber insofern geben wir doch mal das das schied hier durch das dokument wo kommt der begriff dark factory eigentlich her dass vielleicht kurz mit einer mit einer definition oder einordnung startet André Neubauer: Sehr gut. Genau. Ich glaube, wo man es herkennt, ist tatsächlich eher klassische Industrie. Also da, man große Lagerhallen hat, wo man Produktion hat und wo man die Chance hat, viel zu automatisieren, da kommt der Begriff her. Das ist tatsächlich auch in der Produktion gar nicht so häufig, dass man sagt, alles ist eine Dark Factory, sondern es ist eher die Ausnahme. ich glaube, heißt richtig ausgesprochen, Xiaomi. Also eine Smart Factory in Changping, nördlich der 80.000 Quadratmeter, also richtig, richtig große Anlage und halt 100 Prozent Automatisierung. Die produzieren Smartphones, gehen auch ein paar Millionen im Jahr rüber. Und das ist halt eine Halle, in der es kein Licht gibt. Warum? Weil da keine Menschen nötig sind. Und daher kommt der Begriff Dark Factories. Und das versucht man jetzt halt irgendwie auf die Softwareentwicklung auf die Produktentwicklung umzulegen. Sebastian: Ja, und genau da fängt es schon bei mir an, dass ich so eine quasi Antipathie entwickle gegen das Thema. Ich finde es total spannend und ich sehe durchaus auch sehr viele spannende Aspekte darin. Aber zwei Punkte, die sich mir da ergeben. Das eine ist erstmal ohne Menschen natürlich der große Traum. Alles automatisiert. Man braucht keine Menschen mehr, die teuer sind, die irgendwie krank werden, die André Neubauer: Ja. Sebastian: auch mal nicht so gut performen. Und insofern ist es ja auch okay, dass man automatisiert, wo man gut automatisieren kann. Aber da kommt für mich so ein bisschen der zweite Punkt zum Tragen, was man ja in einer klassischen Factory hat, ist ja ein Prozess, der sich irgendjemand mal ausgedacht hat, der einfach immer und immer und immer wieder abgespult wird. Wenn irgendwie so ein Produkt oder vielleicht auch eine Reihe von Produkten die irgendwie unterschiedlich konfiguriert werden. Das heißt, wird ein Badge produziert, dann die Line sozusagen, die Production Line umgerüstet und dann wird halt das nächste Produkt aber immer genau gleich mit den gleichen Specks nach den gleichen Vorgaben gebaut. Im Softwarebereich ist es ja grundlegend anders. Da bauen wir aktuell zumindest noch, jetzt kann man sagen, in der Zukunft hat man gar keine Software mehr, sondern man hat Agenten, einfach nur immer wieder Probleme lösen sozusagen. André Neubauer: Hm. Sebastian: So wie wir Software verstehen und Softwareentwicklung verstehen, lösen wir ja grundsätzlich eigentlich immer neue Probleme. Wenn wir alte Probleme lösen würden, dann hätten wir ja also ja den Problem nicht gut genug generalisiert oder automatisiert. Und da finde ich kommt der Begriff so ein bisschen für mich an seine Grenzen. Jetzt ist es aber, wenn man sich ein bisschen tiefer mit der Materie beschäftigt, ist es aber ja nicht so einfach, weil Am Ende sagt die Dark Factory ja eigentlich nur was darüber aus, wie lang dieser Loop ist, über den wir auch schon öfter gesprochen haben, nämlich der Loop, den man den Agenten alleine laufen lassen kann und beziehungsweise auch den man im Kontext der Softwareentwicklung überhaupt benutzen kann. Und da gibt es ja so eine Five Levels Auflistung. angelehnt an die das quasi an die AVs also autonomous vehicles die ja auch so ein Level 5 als Maximum haben. Genau vielleicht kannst du uns da mal kurz durchführen Andre. André Neubauer: Ja, ja, das ist ja schon quasi... Genau, es gibt von Denchap Hero, muss ich sagen. Kannte ich vorher gar nicht so sehr. weiß nicht, ob du den... Also, ich hab mich vorher noch mal bisschen so schlau gemacht. man von... Also, der scheint schon sehr umtriebig zu sein. Der ist CEO von Glowforge und auch so Research Fellow. Also, er scheint das ein oder andere veröffentlicht zu haben. Muss man auch... Also, lass mich da ehrlich sein, ich kannte ihn vorher nicht. Aber der hat veröffentlicht The Five Levels from Spicy Autocomplete to Dark Factory. Der hat also versucht, das Konzept, was wir vorher hatten, also klassische Industrie, mal auf Software Engineering umzulegen und hat gesagt, man kann das ja eigentlich machen, wie du gerade gesagt hast, autonomes Fahren hat halt von Level 0 bis Level 5, quasi im Endeffekt sechs Kategorien, und das können wir auf Software Entwicklung umlegen. dann gibt es halt ... Sebastian: sehen. André Neubauer: Level 0 heißt halt Spicy Autocomplete. Das ist halt quasi, du hast so einen Co-Piloten, der dir halt irgendwie sagt, hier kann eigentlich die nächste Line of Code halt irgendwie sein. Dann gibt es halt Level 1, dann hast du quasi, die AI schreibt halt schon Code, aber primär hat irgendwie so Boilerplate. Das ist halt irgendwie, und hast halt voll Human Review. Also das ist nicht mal nur ein Review im Sinne von einem Code Review, sondern ein Instant Review, wo sich zu Level 2 ist eher das ganze Thema Pair Programming. Es ist beide gleichberechtigt, also auch immer wieder im Wechsel. Und da ist auch der Gedanke, wo Shapiro sagt, 90 % der AI-Native-Engineers sind dort. Also Leute, sagen, Ich bin halt AI-Native und wir sind halt bei L2. Geht dann halt rüber zu L3, das ist ein Code-Reviewer. AI schreibt eigentlich den meisten Code. Aber der Mensch, also Human in the Loop, quasi reviewt jede Zeile, well, reviewt jeden Diff, nicht jede Zeile, aber jeden Diff. Sind wir halt immer noch bei einem relativ kurzen Zeige, das was du auch gerade angesprochen hast, kurzen Loop. Genau, kurzen Loop. Und dann gibt es L4. Das ist schon spec-driven. Wenn wir auch bestimmt gleich noch mal bisschen zu den einzelnen Unterschieden zwischen den Levels sprechen, aber bloß damit wir mal die Definition haben, ist spec-driven. Also als Human schreibst du halt eine spec und der Agent implementiert das dann, testet das gegen die Akzeptanzkriterien. Das schon ein größerer Loop. Und dann L5 ist halt die Dark Factory. Da geht es eigentlich eher in die Richtung, dass du sagst, du gibst das Ziel vor, aber selbst die Speck wird von dem System entwickelt, inklusive allem, was danach folgt. Das sind diese sechs Level, die einen guten Eindruck geben, an dem man sich gut entlanghangeln kann. wo man selbst steht, wo man halt mit einer Organisation steht. Genau. Sebastian: vielleicht dazu meine frage der unterschied zwischen l4 also ich schreibe detail specs und checken dann die acceptance criteria und l5 also ich schreibe nur noch specs und dann kommt software raus ist wahrscheinlich dann nur noch sozusagen die länge des loops also sprich wie wie umfangreich die specs sind die den Agenten dazu leiten, nicht nur ein Feature nach einer Speck, ein ganzes, weiß nicht, Software-Increment oder Teilprodukt zu erstellen. André Neubauer: Ja, also das auf alle Fälle. Also das ist bestimmt ein gutes Messkriterium. Ich überlege gerade noch. Ich habe so ein System noch nicht gesehen. Wir kommen bestimmt gleich auch dazu. Es gibt wenige Beispiele, kommen wir bestimmt gleich zu, wie gesagt. Ich würde für mich sehen, es verknappt die Notwendigkeit, die Domäne, in der man sich bewegt, gut zu verstehen. Man kann so ein bisschen Ich würde nicht sagen YOLO, aber man kann ein bisschen entspannter rangehen. Also wenn man eine Speck schreibt, ist das Double anspruchsvoller. Und quasi der Anspruch verschiebt sich ins System. Deswegen ist wahrscheinlich auch bisschen schwer für mich zumindest noch nachzuvollziehen, wie ein System auf Basis von weniger Informationen eine gute Antwort, quasi ein gutes Ergebnis halt abliefern kann. Auf der anderen Seite sind das halt die Freiheitsparameter, die man dann wahrscheinlich mit einem guten Harnes halt so weit eingrenzen kann, dass das Ergebnis halt wiederum stimmt. Ich glaube, was wichtig ist, halt, sorry, das ist jetzt zu viel Quatsche, wir kommen da bestimmt auch gleich noch mal zu, diese, aus meiner Sicht, bauen die Organisationen nicht notwendigerweise, also so eine L1-Organisation quasi ist ein guter Pfad für eine L2-Organisation. Aber das geht nicht notwendigerweise so weiter. L3 und L4, da sind riesige Sprünge drin. Das ist nicht einfach nur quasi vom Reviewer hin zum Speck schreiben, sondern das verändert alles. Das verändert Prozesse, das verändert Organisation. Insofern ist auch der Sprung von L4 zu L5 noch viel größer. Da geht es nicht nur darum, dass der Das ist Speck, das dann auch von dem System geschrieben wird. Das muss man sich immer wie noch eine größere Veränderung auf der Meterebene vorstellen. Du brauchst viel mehr Harnes, sorry, darüber müssen wir auch mal eine Folge machen. Was ist ein Harnes? Damit das halt funktioniert. Ansonsten ist es nämlich Slop. Sebastian: Ja, ich meine, vielleicht ganz kurz nur für diejenigen, der Begriff Hanes, den der Begriff Hanes noch nicht sagt und den haben wir, glaube ich, auch schon benutzt in letzten Episoden. Sie haben im Prinzip eigentlich nur das Gerüst ums LLM herum, was dir ermöglicht, quasi wegzukommen von dem reinen Chat-Interface und einem quasi ganz normalen Gespräch mit dem Agenten hin zu, ja. Tooling und mehr Automation, die genau diese Noise reduziert, die wir in letzten Folge mit Ingo Eichhorst besprochen haben, sodass am Ende auch wirklich was Deterministischeres rauskommt, sozusagen, wenn man sehr vages Gespräch führt. Genau das ist das Harnes und da hat hat, also Strong DM, die sind ja so die Vorreiter oder die sind halt rausgegangen ganz stark mit ihrer Dark Factory, da auch sehr viel darüber geschrieben und die haben ja auch ein allgemeines Framework veröffentlicht, ihr Attractor Framework, was, wenn man sich das mal anguckt, sehr auch, sind wir mal, sophisticated aussieht, also tatsächlich aus verschiedenen Layern auch besteht, die zusammen eben dann quasi eine Beschreibung eigentlich nur ihrer Vorgehensweise quasi erzeugen. Also die haben ja kein Tool oder kein Harnes selber Open Source, sondern eher eine Reihe von Specs, tatsächlich kann man auch wieder sagen, die so ein Harnes beschreiben. André Neubauer: Ja, das ist halt, sind, glaube ich, genau drei Markdown-Files. Also, ich glaube, gibt noch irgendwie Lizenz und ReadMe oder so, wenn ich es richtig, ich das ganze Report fünf Files. Ich finde, wenn man sich das überlegt, da sind natürlich, die Komplexität in den Markdown-Files, das ist auch klar, aber wenn man sich überlegt, wie heutige Softwareprojekte halt aussehen, wie viele Artefakte, verschiedene Artefakte, da drin halt irgendwie hast und... Sebastian: Genau. André Neubauer: wie stark man das abstrahieren kann. Und das mit einem Harnis, sodass eben trotzdem gute Ergebnisse rauskommen, ist einfach faszinierend. Wir packen auch alle Links in die Show Notes. Es heute tatsächlich paar Sachen mehr. Wenn man vier, fünf Sachen liest oder sich die Gitterpräpos anguckt, ist man aber auch schnell im Thema. Genau, aber strong DM. Es ist wahrscheinlich eins der... Kann man dazu Posterschalt sagen? Ja, wahrscheinlich. Sebastian: Ja, würde ich sagen, wahrscheinlich sogar das Post-Adschalt. Ich weiß gar nicht, ob irgendjemand so stark damit rausgegangen ist und den Begriff so geprägt hat wie Strong DM, weiß ich gar nicht. Also die sind immer das Beispiel, was so genommen wird. Was wiederum natürlich auch die Frage offenlegt oder it begs the question sozusagen auf Englisch. Ist es ein Standardfall oder ist es eher so eine Exception, aber da kommen wir später noch mal drauf. Ganz kurz ein bisschen tiefer reingegangen in dieses Attractor-Modell, würde ich mal sagen. Was die ganz unten drunter haben, die nennen das Unified LLM Client Specification, wo sie einfach sagen, die wollen modellagnostisch sein, es soll mit Anthropic, OpenAI, aber auch anderen Modellen funktionieren. Und da haben sie so ein Speck gebaut, ja die Design Prinzipien oder die die die Spezifika von den einzelnen LLM Providern sozusagen so ein bisschen weg abstrahiert, sodass sie da mehr oder weniger jedes Modell, was es so gibt, da runterpacken können. Dann gibt es die Coding Agent Loop Specification, die wiederum beschreibt, wie der Agent funktionieren soll. Also sprich, grundlegenden, wie die Architektur aussieht, welche grundlegenden Fähigkeiten der Agent hat, welche Bestandteile auch. Und dann gibt es noch die eigentliche Attractor Specification, die tatsächlich so eine Grafennotation nutzt, Dot Syntax, ⁓ Anforderungen oder auch die Zusammenhänge zwischen Anforderungen zu beschreiben. damit eben dann am Ende ein System rauskommt, was der Agent oder das Harnes sozusagen komplett autonom implementieren kann. Ja, sorry, bitte André. André Neubauer: Ich wollte sagen, auch das hat man ja kurz im Vorgespräch, oder das hast du für mich sehr, sehr gut eingeordnet. Das ist halt einer der fundamentalen Unterschiede im Vergleich zu einem Vibe Coding. Also dass man sich halt bewusst halt irgendwie Gedanken macht, wie will ich halt etwas erreichen, was brauche ich, ⁓ halt auch nicht nicht funktionale, aber auch funktionale Anforderungen halt quasi abzudecken. Und ich glaube, das ist etwas, was ich auch in den Ich will es gar nicht jetzt vorformulieren, aber was ich zu wenig vielleicht dann trotzdem noch sehe, also quasi diesen bewussten Gedanken sich zu machen, wie man etwas erreichen will und gar nicht das was. Also man denkt halt immer noch sehr stark in diesem wahrscheinlich auch Level 3. Es hat quasi vier Domäne, ich muss halt reviewn, also die Prozesse, wie man es halt früher gemacht hat. Aber quasi, wenn man L4, L5 erreichen will, dann geht das halt nur, indem man sich fundamental damit auseinandersetzt, wie man diese Abstraktion, also trotz Abstraktion halt diese Präzision nicht verliert. Und das finde ich, ich glaube, du hattest Boris Czerny, ob der in dem Zusammenhang mal irgendwas erwähnt hat, aber vielleicht magst es auch kurz korrigieren oder ergänzen. Sebastian: Ja, am Ende entspricht es für mich so ein bisschen dem Vorgehen, was ich auch von Boris Czerny wahrnehme, dass der sehr viel seiner Zeit darauf verwendet, mit dem Harnes, also in dem Fall natürlich Claude Coat im Planning Mode zu interagieren, bis die Speck wirklich rund ist. Und dann lässt er den Agent erst implementieren und Das sicherlich eher L4 als L5, aber nach meinem Dafürhalt ein bisschen universeller einsetzbar. Genau, vielleicht bevor wir da hinkommen, kurz zu wie sind Strong DM da eigentlich gelandet. Die haben ja irgendwann ein Experiment gestartet und haben gedacht so wow, AI oder LLMs können jetzt schon so viel. Wie weit kommen wir damit? Und haben dann gesagt, irgendwie, postulieren mal zwei Regeln. Code darf nicht von Menschen geschrieben werden und darf auch nicht von Menschen gereviewed werden. Und sind damit dann losgegangen und haben da eine ganze Reihe Erfahrungen gemacht. Eine Erfahrung, die haben eigentlich auch alle, die ich kenne, die so ein bisschen tiefer reingegangen sind in die, ins Agendic Engineering, also Beyond Vibe Coding, die auch ganz schnell merken, natürlich sind die LLMs quasi incentiviert immer den die schnellste den schnellsten Weg zu finden. Und das bedeutet nicht notwendigerweise, dass alle Tests immer super sinnvoll sind, sondern die können teilweise auch einfach nur quasi ja, also es kann einfach sozusagen den Test grün zu machen, gleich true gesetzt werden an irgendeiner Stelle und also return true und ⁓ das zu zu zu verhindern, haben sie dann angefangen, unterschiedliche LLM-Kontexte aufzumachen. Sie sind ja sogar irgendwann dazu übergegangen, dass sie unterschiedliche LLMs tatsächlich eingesetzt haben, ⁓ das Ergebniswert, also das Ergebnis der fertigen Software, also die Akzeptanzkriterien abzutesten und haben dann auch gesagt, sie denken eigentlich eher in Szenarios, die sie durch die Agenten oder durchs LLM, wie gesagt, streng vom Implementierer getrennten Kontext abtesten lassen wollen, die auch beide nichts voneinander wissen sozusagen. Also einer kriegt die Specs und implementiert und ein anderer Agent, wenn man so möchte, kriegt die Specs und muss dagegen testen oder die Szenario sozusagen und muss dagegen testen, sodass die Validation immer komplett getrennt ist. Und StrongDM und hier kommt so ein bisschen der Spezialfall rein. ist, wenn ich es richtig verstehe, ja im Wesentlichen Tool, was gar nicht so sehr eine explizite oder gar nicht so viele UI Interaktionen hat, sondern stark integriert ist in diverseste Tools, wo es halt immer ⁓ die Integrationstests geht. wie funktionieren die Integration mit den einzelnen Tools Slack, Okta, Jira und so weiter funktionieren die dauerhaft und Da sind sie sogar so weit gegangen, damit die Tests at scale immer funktioniert haben und sie nicht in irgendwelche Rate Limits gelaufen sind, dass sie sich Digital Twins gebaut haben für diese Tools, also sprich die Tools tatsächlich gemockt haben, sodass sie gegen diese gemockte Spezifikation oder die Mock-Tools dann automatisiert in einer sehr, sehr hohen Frequenz entsprechend testen konnten und damit validieren konnten, ob ihre Implementierung funktioniert. So und jetzt Erkennt man daran schon, das ist ein sehr spezieller Case. meine, Integration sind ja für viele Anwendungsfälle super relevant. Bei denen sind sie, wenn ich das Produkt richtig verstehe, ein Kern vom Produkt. Das heißt also, die können sehr, viel über die korrekte, quasi das korrekte Ergebnis in der Integration, an der Integration, an der Schnittstelle sozusagen. Darüber können sie viel validieren, ob das Produkt dem entspricht. was intendiert war. Nichtsdestotrotz interessante, sagen wir mal, interessante Herleitung und auch interessante Findings, bei denen sie gelandet sind. André Neubauer: Ja, und ich glaube, was das für mich so nochmal gezeigt hat, ist halt, wie groß diese Disziplin, also der Anspruch an Disziplin ist. deswegen, du hattest es gesagt, es gibt halt zwei Roots. Coach shall not be written by humans and coach shall not be reviewed by humans. wenn du halt quasi human komplett rausnimmst, dann hast du auch quasi eine Maschine an der Stelle, das ist deterministisch. Also es ist halt Es wird eingehalten. Und ich glaube, das ist halt super wichtig, man halt, wenn man quasi L4, L5, du brauchst halt einfach, also es ist dann nicht mal Larifari, um das mal anders zu sagen. quasi wenn du quasi dahin kommen willst, dass du halt mit Specs dein Produkt beschreibst oder deine Software beschreibst, Dann quasi verschwindet ja nicht die Arbeit. Die Arbeit findet bloß woanders statt und sie verschiebt sich halt in dieses Gerüst halt so sicher zu machen, dass das da drinnen halt das System gut arbeiten kann. das ist so elementar. ich das gelesen habe, ist mir so bewusst geworden und ich glaube, man sich da auch selbst anschaut. Das ist nicht immer in der täglichen Arbeit gegeben. Da macht man mal hier einen Shortcut, da, ach komm, das machen wir nächste Woche. Und hier, ach, das muss jetzt halt irgendwie raus. Und das, quasi, das gibt's in diesen, in diesen Systemen halt nicht. Ist aber elementar, wenn du halt auf dieses Level willst. Ansonsten ist es halt... Crap. Sebastian: ja absolut das haben die halt wirklich par excellence durchgezogen durch exerziert und genau und und da sieht man auch und das ist vielleicht auch jetzt wieder den loop zum beginn diskussion wenn man sich auf diesen Pfad begibt, dann ist es ein echtes Commitment. Man muss die Arbeitsweise grundlegend umstellen. ich glaube auch, wenn man das aktuell in einer größeren Organisation macht, dann muss man das auch eher als Experiment sehen und sagen, wir investieren jetzt mal eine gewisse Summe, also sprich eine gewisse Kapazität in diesen Ansatz, ⁓ diesen Ansatz besser zu verstehen und zu verstehen, wie der für uns funktioniert, wo der funktioniert, wo die Grenzen dieses Ansatzes sind oder wie lange wir diese Loop-Länge in unserem Kontext tatsächlich bekommen. vielleicht ein bisschen mehr auf... Und da bricht für mich immer dieses Pattern, wenn ich quasi... Wenn eine idealtypische Dark Factory wäre ja, dass ich sage, Ich will keine Ahnung, eine Tabellenkalkulation haben. Man hat was im Kopf und wünscht sich, dass man in Tabellen sehr gut kalkulieren kann. ist Excel oder Excel, wie man im Englischen sagt, ja über Jahrzehnte entstanden, hat sich weiterentwickelt. kann sagen, sicherlich hatten ein gutes Stück auch in Shedification erfahren, aber da stecken ja iterative Findings drin, die niemand von Null auf hätte so, niemand hätte zu Beginn gedacht, dass Makros relevant sind oder keine Ahnung, dass in Spreadsheet irgendwie Google Script relevant ist oder dass man auch noch aus dem Excel vielleicht andere Tools fernsteuern soll oder was auch immer. Das sind ja alles Dinge, auf die man erst im Laufe der Zeit kommt. Und genau da brauchst dann eben schon das Domain-Knowledge. Also sprich, genau da setzt ja das Domain-Knowledge an, dass ich dann auch während der Entwicklung iterativ feststelle, wo muss ich denn jetzt abbiegen, ⁓ den Wert zu maximieren, den diese Software quasi den potenziellen Kunden liefert. Und genau, also da Da bin ich dann immer wieder bei dieser Loop-Länge. Also wie weit kann ich denn in einem bestimmten Kontext vorausdenken, was das Ding tun muss. Super leicht ist es, wenn ich sage, ich will Excel nachbauen. Okay, gut, dann kann ich eins zu eins mir Excel angucken und kann eine Spec runterschreiben, die das genau spezifiziert und dann lasse ich den Agenten, mit Tests lasse ich den Agenten rödeln. So wie, ähm, wer war das? irgendjemand hat einen Browser gebaut. habe vergessen, das, ich glaube Cursor, die haben einen Browser gebaut und haben dabei natürlich auf eine der umfangreichsten Test-Suites überhaupt zurückgreifen können und natürlich ein extrem gut spezifiziertes Open Source Konstrukt. Und in einem eher Greenfield Projekt, wo du nur eine vage Vorstellung davon hast, wie es aussehen könnte, André Neubauer: Das kann sein. Sebastian: Da wirst du wahrscheinlich den Agenten jetzt nicht zwei Wochen laufen lassen können, ohne dass er, ohne dass du einmal drauf gucken musst oder dein Verständnis von welchen Wert bringt es denn dem menschlichen Nutzer, der davor sitzt, mit einfließen zu lassen. Genau, aber who knows, wo sich das noch hin entwickelt in den nächsten Monaten und Jahren. Es fällt heute schwer, das zu predikten. André Neubauer: Würdest du damit gehen, man sagt, also quasi diese großen Sprünge L3, L4, L4, L5, dass das exponentiell mehr Aufwand bedeutet als die Sprünge davor? Sebastian: Ich glaube, das kann man gar nicht so verallgemeinern. Für eine große Tech-Organisation, da kann das durchaus so sein, dass du den Schritt, also wenn du das auf eine gesamte Organisation beziehst, dass es dann mehr Aufwand wird, weil an einem bestimmten Punkt, du schiebst ja irgendwelche Bottle-Nix immer vor dir her. Ganz am Anfang, autocomplete, du machst halt einfach das André Neubauer: Ja, genau. Sebastian: Codeschreiben für den Menschen schneller. Das zweite ist auch immer noch Codeschreiben für den Menschen schneller machen. Dann und auch das dritte, genau, dann eben Code Review. Da kommt dieses Bottleneck Code Review hatten wir auch in der Folge mit Ulli von Mapbox schön. Da kommt dieses Code Review Bottleneck zum Tragen. Und da gibt es, wie du schon richtig sagst, auch den ersten Breaking Point, wo die Aufgabe sich dann einmal grundlegend verändert und Der nächste Schritt, spec driven, ist dann ja quasi nochmal ein zweiter rausgesoomt, wobei ich auch noch nicht genau sagen kann, nicht, wenn ich den Schritt von ich schreibe keinen Code mehr und quasi sozusagen bin auch nicht mehr aktiv an der, Coding ist gar nicht mehr meine Profession, ob dann nicht der Schritt vom Reviewer zum Spec Writer und Checker sozusagen, ob der dann nicht sogar wieder eher linear ist. Weißt du, weil am Ende wie arbeite ich? Ich bin würde ich sagen eher im Normalfall auf L4. Also ich gucke mir Occasionally-Code-Stellen an. Wenn ich so einen Hals habe, da könnte irgendwas nicht stimmt. Dann schaue ich da mal rein. Frage den Agenten auch explizit dann nach, wie er bestimmte Probleme gelöst hat und nach Code stellen. Ansonsten check ich aber die Specks und das ist halt der Punkt in einem Startup, was jetzt anfängt, wo du direkt sagst, irgendwie wir versuchen mal jetzt so schnell zu sein, wie nur möglich, fängst du vielleicht auf L4 an und dann ist der sozusagen ist alles, was davor ist vielleicht gar nicht da. Deswegen würde ich sagen, hängt von der Größe der Organisation an. Achso halt noch ein weiterer Sorry, ich bin auch ein bisschen wirr heute. Top vorbereitet. Und ein weiterer Punkt ist natürlich, dass das Verschieben der Bottlenecks hat ja dann auch wieder Auswirkungen auf die Organisation selbst. Also sprich, man kommt dann ja wirklich irgendwann an den Punkt, dass man sagt, okay, jetzt Codes schreiben ist einfach nicht mehr das Bottleneck, Code Review ist das Bottleneck. Dann irgendwann ist Code Review nicht mehr das Bottleneck, sondern es sind es wirklich die Ideen, die das Bottleneck werden. Und dann musst du halt gucken, wie kriegst du die die die Rollen, die Teams in der Organisation so verändert, dass du jeweils den neuen Bottlenecks begegnest. Und das ist natürlich, je größer und älter die Organisation, desto schwerer und schmerzhafter kann dieser Prozess möglicherweise sein. André Neubauer: Ich glaube, hast einen super Punkt mit, ich glaube als Start-up, als sehr junges Unternehmen solltest du dir sehr weise überlegen, wo du einsteigst, weil je höher du einsteigst, je weniger Schritte musst du gehen. Ich glaube, ich hatte überlegt, ob das wirklich eine Leiter ist oder ob man da Stellen überspringen kann. Weil so richtig logisch zahlen die Sachen alle nicht aufeinander ein, aber sie machen auf der anderen Seite dann doch, Sie machen auf den Settel dann doch Sinn. Also du würdest halt nicht von quasi per Programming Mode in quasi Speck halt irgendwie selbst springen. der Schritt ist halt viel zu groß. Insofern brauchst du dann einen Zwischenschritt. Quasi der Zwischenschritt über L3. Genau, Code Reviewer macht dann halt wahrscheinlich erst Sinn. Sebastian: CodeReviewer. André Neubauer: Warum ich das gefragt habe, ist auf der anderen Seite die Aufwände. Zum Beispiel L3, L4. Du musst auf einmal Spectrum lernen. Du liest nicht mehr Code durch, sondern du versuchst die Specs möglichst präzise zu formulieren. Das ist, glaube ich, auch eine Fähigkeit, braucht Training, Training, Training. Dann hast du das irgendwann gemastert und sagst, okay, jetzt L5, wenn du es möchtest. Da kommen wir vielleicht auch gleich noch mal zu. Und F5 ist dann aber, da brauchst du dann wieder gar keine Specks. Da hilft dir natürlich das Wissen quasi, wie eine gute Speckheit aussieht total, damit du den richtigen Harnes da rumbauen kannst. also vor dem Hintergrund macht das dann die Stufe ein bisschen Sinn. Aber so richtig fließen, also partizipierst du nicht so von den Aufwänden. Weißt was ich meine? Und deswegen stelle ich es mir sehr schwer vor. Ich habe halt auch keine ... Sebastian: Hm. André Neubauer: praktische Erfahrung von so F4 auf einem F5. würde sagen, wir selbst sind so L3, L4. Und das quasi hebt schon vieles aus den Angeln, weil auf einmal ist der Prozess anders. Man merkt halt einfach, hups, quasi man wird hyperproduktiv oder viele Agenten hüpfen auf der gleichen Stelle rum, erzeugen halt irgendwie andere Probleme und so weiter und so fort. Also das ist, Es ist immer eine neue Klasse an Problemen. Sebastian: Ja ich bin hier gerade nochmal bei Den Shapiros Post, also auch empfehlenswert auf jeden Fall, wenn man sich da mal tiefer einlesen möchte, der wirklich dieses autonomous Vehicle Thema aufmacht. Level 4 ist so, du hast eigentlich noch Lenkrad und alle Pedale und so und sozusagen hast die Möglichkeit auch noch selber einzugreifen, was du vielleicht auch musst, weil du in bestimmten Instandgebieten auch nicht komplett autonom fahren darfst. Und L5 ist tatsächlich so, es gibt da einfach keine Steuermöglichkeit mehr für dich. Das Auto steuert einfach immer. du kommst damit auf eine andere Ebene, in der du quasi über das Auto in der Form gar nicht mehr nachdenkst, sondern quasi nur noch über komfortablen Transport, wenn du so möchtest. Und was er hier als Beispiel macht, vielleicht nur ganz kurz noch, er sagt ja auf Level 4, da schreibst du die Speck und quasi bist mit dem Agenten Hones, also arbeitest du an der Speck, schreibst Skills und machst Pläne etc. Und bei Level 5, ist dieses, das Harnes ist halt fertig sozusagen und du bist nur noch auf der Speck. Das heißt, du bist eigentlich, eigentlich glaube ich, bist du viel mehr nur noch auf der Domäne, also auf der Business Domäne. nicht mehr in der Technologie. Das ist da der entscheidende Sprung, auch nicht mehr auf der Technologie den Agenten irgendwie zu verstehen oder weiterzuentwickeln, sondern das ist alles da, zu verstehe ich es. André Neubauer: Ja, komplett in dem Bild, ich wollte gerade sagen, ich glaube, mal gucken, das stimmt oder du dazu zustimmen würdest, F5 bedeutet eigentlich, keinen Führerschein mehr haben zu müssen. Und das ist, ich, ein riesiger Wert, wenn man das nämlich auf unsere Disziplin umlegt, heißt das, man muss keine Ahnung von Software Engineering haben, kommt aber von A nach B, also kann ein vollwertiges Produkt bauen. Und da, das ist schon massiv. Weil, also wenn wir uns jetzt halt überlegen, lohnt sich das L4 auf L5 und wir da vielleicht, oder ich da, auch immer für mich, da auch ein bisschen Zweifel, weil das halt einfach gerade für bestehende Organisationen auch ein riesiger Aufwand ist, machen wir das natürlich immer aus dem Kontext, weil wir einen Führerschein haben. Also quasi wir haben den Background in Software Engineering. Aber der Wert entsteht natürlich dahingehend, dass Level 5 eigentlich bedeutet jeder kann Auto fahren ohne Auto fahren zu können. Sebastian: Genau, ja, also eine schöne Zusammenfassung und da ist die, also, das was wir sonst immer diskutieren ist ja Du kannst Vibe coden, irgendeine App dir zusammen coden, die irgendwas tut und relativ schnell irgendwie ein shiny Ergebnis haben, kannst du ja relativ schnell. Wenn du die dann erweitern möchtest, dann brauchst du schon ein bisschen bessere Skills. Aber wenn du die dann nach Produktion bringen möchtest, auch Kunden drauf haben möchtest, dass die reliable immer funktioniert, dass die secure ist, dass die available ist, dann brauchst du irgendwann wirklich dann ein Engineering Know-how beziehungsweise du musst irgendwann entweder es dir aneignen oder das in irgendeiner Form hinzunehmen. Je größer das wird skalieren muss dann dann auch Architektur Know-how etc. Technologien Know-how kommt einfach unweigerlich noch dazu. Und die Frage ist halt also ich würde behaupten wir sind wahrscheinlich noch nicht da, dass man kein Technologien Know-how braucht. Allerdings jetzt wieder auf das StrongDM Beispiel zu kommen. kann ich mir durchaus vorstellen, dass man für einen bestimmten Anwendungsfall ein Harnis bauen kann, was das Technologienow-how genug weg abstrahiert. Wenn man sagt, irgendwie man hat eben eine schmale UI, mehr oder weniger über die man bestimmte Konfigurationen machen kann, die dann an bestimmte Tools weiter verteilt werden müssen, dann kann man da eine definierte skalierbare Architektur dahinter packen, die das technische weg abstrahiert. Und dann kann man André Neubauer: Mhm. Sebastian: auf der Logik-Ebene sagen, welche Compliance oder Regeln möchte ich denn jetzt abbilden können auf dieser Grundlage. Das kann ich mir durchaus vorstellen. Wobei auch bei StrongDM waren es ja Engineers, also unter anderem der CTO, die daran gearbeitet André Neubauer: Total, total, Bisschen gucken auf die Zeit. können bestimmt gleich machen mit den Predictions. Bestimmt. Können wir überlegen. Noch ein Beispiel, auch in der Recherche drüber gestolpert. Postdoc hat quasi ein ganz nettes Feature gelauncht. warum bringe ich das hier gerade auf? Ich erkläre es auch gleich, was das macht. Sebastian: Mhm. André Neubauer: Warum macht man das eigentlich auch alles? Man will ja trotzdem Wert schaffen. Es geht ja nicht nur darum, Ende ein Level-5-System zu haben, ⁓ zu sagen, jetzt kann ich x-beliebige Software machen. Man will das entlang von ... Idealerweise würde man Vielleicht gibt es auch ein Level-6 oder so. Müste man mal recherchieren. Ich habe es schon ein-, zweimal gehört von Leuten, die dann sagen ... Da kommt die Software auch mit dem Vorschlag, was man denn sinnvoll als nächstes tun sollte. Und so ein bisschen in die Richtung geht Postdoc Code, postdoc.com slash Code. Da nutzt nämlich das System quasi externe Signale, also quasi zum Beispiel, wie sich so ein Kunde auf einer Webseite verhält oder Error Messages. oder andere Indikatoren, also externe Signale, ⁓ sich selbst zu füttern, ⁓ sich dann zu verbessern. Und ehrlich gesagt, neben all dem L0 bis L5 finde ich eigentlich das das Beeindruckendste, weil man dann so eine Art Flywheel geschaffen hat. Also man hat quasi, für mich ist das so bisschen wie Schiffe versenken. hat einen Treffer und dann versucht man mit einer guten Strategie. Da ist man nicht auf sich selbst, weil man selbst denkt, man hat die besten Ideen, sondern Daten getrieben, was das auch immer bedeutet, wo die Daten, Impulse und Signale herkommen. Da schafft man ein System, wo man sich kontinuierlich vorwärts bewegt. Und dann ein zweites, ein drittes, ein viertes Thema für sich entdeckt, ohne dass man das System das für einen entdeckt. So muss man es eigentlich sagen. Fand ich unheimlich begeisternd. Ich glaube, man kann sich auf eine Warteliste schreiben. Es ist für Frühling Keine Ahnung, wie lange der Frühling noch geht. Aber auf die Warteliste kann man sich schreiben und finde ich eine total spannende Entwicklung. Sebastian: Du hast es ja geteilt im Vorfeld, ich fand es auch super spannend. Jetzt wo ich gerade über nachdenke, denke ich mir wirklich der feuchte Traum von so CEO Dudes und also Continuous Innovation und irgendwie Data Driven, Product Lead Growth und so ein bisschen fühlt sich das an wie noch schnellere Inchidification vom Produkt. Jetzt wo ich gerade über nachdenke, denke ich mir wirklich der feuchte Traum von so ⁓ CEO Dudes also Continuous Innovation und irgendwie Data Driven, Product Lead und ein bisschen fühlt sich das an wie noch schnellere Inchidification vom Produkt. ⁓ André Neubauer: Continuous Innovation, geiles Wort. Continuous Innovation, geiles Wort. Sebastian: und noch häufigeren Änderungen der verschiedenen Features. Da kann ich mir schon vorstellen, dass die Nutzer irgendwann an ihre Grenzen und noch häufigeren Änderungen der verschiedenen Features. Da kann ich mir schon vorstellen, dass die Nutzer irgendwann an ihre Grenzen kommen. Ich weiß nicht, wie es dir so geht, aber es gibt so Tools, ich benutze. Da ist die Veränderungsgeschwindigkeit in Teilen so hoch, dass ich genervt André Neubauer: ⁓ Sebastian: bin. Insofern ... muss man da glaube ich auch so Guardrails einsetzen und am Ende meine feste Überzeugung solange du für Menschen was baust, ein Produkt baust, musst du mit menschlichem Bauchgefühl oder muss irgendeine menschliche Intuition die Produktentscheidungen zumindest informieren. Das sollte ein relevanter Bestandteil der Entscheidung sein. André Neubauer: Da kann man ja natürlich auch wieder irgendwie so einen humanen Loop haben. fand den Impuls bloß, quasi das, neben all der Theorie, diese praktische Anwendung an der Stelle halt beeindruckend. Sebastian: Da stimme ich ja auch zu und das ist natürlich Postdoc, die ja Product Analytics nochmal komplett auf neue Füße gestellt haben sozusagen. ideale Weiterentwicklung, zweifelsohne. Genau, eine Sache noch, die ich neulich auch spannend fand, die ich dann noch kurz hinzufügen wollte. Und zwar habe ich neulich ein Video gesehen. Ich kriege ja auch viel Know-how über YouTube-Videos. Wenn ich mal zehn Minuten habe, sozusagen, dann ziehe ich mir so ein YouTube-Video rein und habe wieder irgendwas Neues gelernt. Und es gibt ein Agent-Orchestration-Tool, würde ich mal sagen, von OpenAI und das nennt sich Symphony und einer der Wege wie das ausgerollt wird ist einfach eine Speck. Das heißt also über eine Speck kann man sich im Agent der Wahl einfach dieses Tool bauen lassen sozusagen. Das ist auch wieder so ein 6000 Lines of Code Speck und da ist es sozusagen ein gutes Beispiel dafür, dass ein André Neubauer: was. Sebastian: sehr gut durchgespecktes Softwareprodukt repeatable erzeugt werden kann in verschiedenen Umgebungen. André Neubauer: ist so bisschen eigentlich wie ein 3D Druck. Also du kriegst nicht mehr das fertige Produkt, sondern bloß die Beschreibung zu diesem Produkt und generierst es dir halt selber. Das auch ein sehr gutes Beispiel. Eigentlich müsste man das mal in die Finger bekommen, dieses Speck. Weil das ist ja eine sehr, sehr gute Speck, ⁓ daraus mal zu destillieren, was macht halt eine gute Speck halt aus. Vielleicht ist das mal... Sebastian: Die ist ja im GitHub, die kannst du dir angucken, so funktioniert es. Entweder du lädst dir das Tool selber runter, ich glaube dann kommt es für OpenAI fertig, aber du kannst dir das auch selber so bauen, wie du es gerne hättest und dann auch für jeden, gibt es Cloud Code, gibt es Pi, in welcher Umgebung auch immer und sag hier, bauen wir mal. André Neubauer: Dann folgende Sache. habe ja mal gucken, wann wir diese Folge veröffentlichen. Aufnehmen tun wir am Montag. Ich fahre am Mittwoch zurück. Ein paar Stunden im Zug. Das gucke ich mir mal an. Irgendwie entweder machen wir dazu eine Folge dann nochmal oder... Also was macht eine gute Speck aus? Da können wir vielleicht uns auch wieder jemanden einladen. By the way, das ist auch der Aufruf, wenn jemand hier spannende Gäste hat, die er mal hören will. Gab es auch schon. Dann immer her damit. Aber ich glaube, ist eine schöne Fingerübung, auch als ich in dieses Repo geschaut habe, das sieht halt mega aufgeräumt aus, also von StrongDM. Aber da mal rauszudestillieren, was halt dann nun quasi wirklich eine gute Speck ausmacht. Also du hast es ja sehr detailliert beschrieben. Ja, ich glaube, da kann man sehr viel von lernen. Also wir wären alle nicht Prompt-Ingeniers, wir wären alle Speck-Ingeniers. Vielleicht auch das noch. Sebastian: Kontext-Engineers oder Harnes-Engineer. Jetzt haben wir alle Bullshit-Bingo-Worte, glaube ich, in unserem Bingo-Feld nochmal quasi zack abgekreuzt. Genau und können auf die Zielgerade einbiegen, ich mal. André Neubauer: Genau, context-engineered. ⁓ mein Gott. Genau. Genau, Reality Check und Prediction. Sebastian: Jo, schieß mal los. André Neubauer: Ja, Reality Check. Wir machen da einmal Fuck-up und beeindrucken. Also ich würde das jetzt beides am Modell von Dan Shapiro mal belassen. Erstens positive, wie man immer gelernt hat. Dieser Aha-Moment, ist jetzt fairerweise schon ein paar Tage her bei mir, aber... der Aha-Moment, wenn man Software auf eine andere Art Weise erstellen kann. Das ist für mich immer noch... Also, wenn immer das passiert, ist für mich so ein... Also, ich hab mich noch nicht dran gewöhnt, muss ich ganz ehrlich sagen. Es ist immer noch ein unheimlich schöner... Schön ist das falsche Wort. Unheimlich beeindruckender Moment, weil man selbst... Es ist außerhalb meiner Vorstellungskraft nach wie vor. Und damit auch schwer zu greifen und auch ein Stück weit schwer zu akzeptieren, muss ich auch sagen. Und das ist nach wie vor... damit spiele ich immer noch gerne rum. Also, es wird überhaupt nicht langweilig, dieser Effekt. Ich liebe es. Und so bisschen der Fuck-up. Modus ist, wenn du damit dann halt irgendwie denkst, okay, das und jetzt halt irgendwie die nächste Stufe. Das ist unendlich schwer. Ich hatte ja vorhin schon gesagt, quasi ganze Organisation dahin zu bringen, ist halt schwer. Nicht weil die Leute das nicht wollen. das ist ja nicht jeder von begeistert, aber Das ist gar nicht die Herausforderung. Die Herausforderung ist, dass Organisationen nicht für diese Art der Produktentwicklung gemacht sind. Sowohl was die Komposition von Teams angeht, die Skills, die Prozesse, wir hatten ja vorhin gesagt, braucht viel mehr Disziplin, anderen H &S, vielleicht kleinere Teams, weil Agents sich ansonsten auf den Füßen stehen. Also da kommst du vom 100. ins 1000. und das ist echt frustrierend, weil... halt auch eine gewisse Menge erst schaffen musst, ⁓ halt quasi dann wirklich diese Benefits, von diesen Benefits zu partizipieren. Also das wäre mein Reality-Check. Wie sieht es bei dir aus? Sebastian: Ja, mein Reality-Check ist tatsächlich also den What the fucks habe ich immer wieder mit meinem heiß geliebten OpenClaw-Agenten. Da gab es neulich ja irgendwie so ein Meme. Ich habe irgendwie alle meine Saas-Tools ersetzt durch OpenClaw und zahle jetzt 1500 Euro an Entropic im Monat und 15 Stunden die Woche. André Neubauer: Ja. Sebastian: muss ich irgendwie irgendwelche Probleme in irgendwelche Jammerfalls editieren. Und ich sehe mich da wieder. ich zahle halt meine Open AI Subscription und dann noch ein bisschen Gemini. Wenn ich mal ins Rate Limit laufe, quasi Zusatz. Das ist aber, weiß nicht, irgendwie 1,50 war es im letzten Monat. Also es hält sich in Grenzen so. Von daher geht es noch. Aber fairerweise, ich ersetz damit auch keine SaaS-Services, sondern ich mach damit Dinge, die vorher so gar nicht möglich gewesen werden, ob ich es jetzt mein Wissen stärker organisieren, besser im Zugriff habe, den Kontext griffbereit habe, den ich für bestimmte Dinge einfach brauche oder eben bestimmte Sachen automatisieren, wie zum Beispiel schon mehrfach erwähnt. da bin ich halt immer dabei, an Skills herumzudoktern, aber regelmäßig muss ich dann auch doch wieder gucken, Speicher auf dem Host ist voll gelaufen, muss ich mal Files löschen und der VM mehr Disk Space geben. einmal habe ich es kaputt gespielt, weil ich immer so einen regelmäßigen Fehler hatte, der aber im Pi-Framework drin ist, liegt an dieser Tree-Struktur, mit der der Contexte oder die Sessions verarbeitet werden. Und ich habe dann Backhand gemacht und habe dann mit dem Agenten eine Änderung vorgenommen, die dann aber leider den Agenten quasi ausgehebelt hat. Da musste ich nochmal zurückrollen. Genau, also ich verbringe mehr Zeit auf dem Host, als mir lief wäre. Aber es macht ja auch Spaß und ich bin ja auch Tinkerer und deswegen ist es auch cool auf der anderen Seite. Genau, und so ein Wow-Moment hatte ich gerade heute wieder. Ich habe jetzt ein paar Wochen nicht in so eine große Applikation reingeguckt, die ich halt agentisch engineered habe. Und da ist mir gerade während wir gesprochen haben aufgegangen, dass ich tatsächlich mich die Levels hochbewegt habe. ich habe initial, ich nicht sagen, dass ich Code geschrieben habe, das nicht. habe eine Go-Applikation mit React, hab nie Go und React gemacht. Aber ich habe zumindest mir den Code intensiv angeguckt und würde sagen, dass ich wahrscheinlich eher auf L2 angefangen habe. Das heißt also... AI hat schon den meisten Code geschrieben, aber ich habe da schon sehr dediziert mitgearbeitet. Bin dann zu L3 relativ schnell gegangen, einfach nur, ⁓ zu lernen sozusagen, was da passiert, was, glaube ich, tatsächlich als Startpunkt auch gar nicht so schlecht war und bin dann aber wirklich irgendwann auf L4 gegangen und bin jetzt komplett auf der Ebene, wie gesagt, mit dem Occasionally einmal mir eine Code Stelle angucken, wenn ich das Gefühl habe, hier könnte wieder so ein komischer Fallback entstanden sein, wo der Agenten eine Abkürzung nimmt, die mir aber so eigentlich gar nicht lieb ist, weil ich lieber einen undefinierten Zustand hätte, der dann in einem Error resultiert als einen undefinierten Fallback sozusagen. Genau. André Neubauer: Jaja, um eine Annahme. Sebastian: Genau. André Neubauer: Gut, magst du auch eine Prediction machen? wird das besser, schlechter? Was wäre deine Prediction allgemein? Sebastian: Ja, das ist eine gute Frage. ich würde mal predikten, dass wir in sechs Monaten immer noch nicht ganz genau wissen, ob das jetzt eine AI-Blase ist oder ob die oder ob es keine Blase, ob keine Blase platzen wird. Das ist jetzt wirklich aus der hohlen Hand, habe ich vorher nicht genau darüber nachgedacht, aber woher, wie komme ich darauf? Das Gefühl besteht ja schon bestimmt ein halbes Jahr, wenn nicht sogar länger, dass Leute angefangen haben zu sagen, wir sind in einer AI-Blase. Trotzdem steigen die Firmenwerte immer weiter. Anthropic hat jetzt massive Entwicklungen hingelegt, auch in der Adoption extrem stark und beschleunigt sich fast. Auf der anderen Seite gibt es quasi keine Studien, die irgendwie nahelegen, dass auch nur annähernd mit den Kosten, die da entstehen, Produktivitätswachstum entsteht. Das ist jetzt, kann man jetzt auf verschiedene Arten interpretieren, beziehungsweise es gibt für alles Erklärung. Man kann natürlich sagen, dass die Studien oft veraltet sind. Also sprich, die wirklich, die sind ja immer rückwärtsgewandt, die haben sich dann irgendwelche Sachen aus zwar 2025 angeguckt. Das kannst du mit den neuesten Modellen und den Harnes-Entwicklungen jetzt schon gar nicht mehr vergleichen. Model-Evers sind strukturell einfach schwer und das ist wirklich die wenigsten Firmen machen das at scale und dann hast du ja noch einen Harnes und dann hast du noch irgendwie Skills und dann hast du noch ganz viele variable Faktoren. Du hast geopolitische und wirtschaftliche Faktoren, die den Einfluss darauf haben, die es ganz schwer machen, eine Produktivitätssteigerung irgendwie messbar zu machen. Und ich bin mir nicht sicher, ob wir da in der Erkenntnis deutlich weiter sind in einem halben Jahr. Also ob wir ganz klar sagen können, ja, das ist definitiv produktivitätssteigernd oder nicht. Ich würde behaupten, dass Firmen, die das meistern, die für sich dann harnessen, einen Kontext-Engineering- Ansatz, einen Entwicklungsansatz finden, der für sie gut funktioniert, die können sustain, sehr wahrscheinlich deutlich, deutlich schneller und entwickelnd als andere und auch vor allem viel, mehr experimentieren als es früher war. Dieses, wir ja auch schon mit Markus und Anna besprochen haben, dass wir heutzutage gar nicht mehr quasi lange User Research machen müssen, bevor wir dann in die teure Prototypenentwicklung gehen, sondern wir bauen einfach einen Prototyp, der halt ein aufgehübschter Clickdummy ist, aber schon auch Gutteil der Funktionalität, je nachdem was es ist, irgendwie enthält. Und ich glaube, dass es Firmen geben wird, die das at scale hinkriegen. Ich glaube aber, dass wir in einem halben Jahr immer noch die überwiegende Mehrzahl an Firmen haben werden, die sich damit noch schwer tut, die dann noch relativ am Anfang ist, die da noch nicht ganz klar belegen kann, ob es einen Produktivitätszuwachs gibt. Das liegt ja auch darin, da oder sagen wir mal mitbegründet Softwareentwicklung ist da einfach at the forefront sozusagen. Also keine Domäne in meinen Augen ist so weit wie Softwareentwicklung, was das anbelangt und Softwareentwicklung. Ich weiß nicht, ob du es schon mal erlebt hast, aber es gibt halt einfach keinen anerkannten Industriestandard für Produktivitätsmessung in der Softwareentwicklung. Von daher wird es wahrscheinlich in der nächsten Zeit immer noch schwer werden und wir werden Rätsel raten. Und deswegen macht es wahrscheinlich auch so dieses Dark Factory Pattern nochmal zu reviewen in einem halben Jahr, einem Jahr, was auch immer. Meine lange Prediction, sorry. André Neubauer: Ich höre da mal gespannt zu deinem Thema Produktivität. ist ja auch die ewige Frage nach Output und Outcome. Das ist, sehr schweres Thema. Passt aber nicht so richtig in den Podcast, aber in die alten Folgen hätte es wahrscheinlich reingepasst. Quasi was ist, was ist relevanter? Meine Prediction ist, ich würde es mir wünschen, ja. Sebastian: Vielleicht ganz kurz, ich würde ganz kurz nur dazu noch, das ist ja am Ende schon immer noch relevant, weil es geht ja beyond Vibe Coding und es geht ja darum, dass wir am Ende irgendeinen Wert schaffen wollen. Wir wollen ja irgendwelche Probleme lösen für Nutzer, die dann wiederum Wert Business Value erzeugen. Ich glaube, am Ende, das ist ja der Kern des Ganzen und damit steht und fällt auch die Adoption oder halt die, ob die Blase erst mal platzen muss, bevor es dann André Neubauer: Shoot, shoot, shoot. Aschdenken. Sebastian: Nachdem man das Tal der Tränen durch ist, nachdem es dann wieder hochgeht. André Neubauer: Ja, bestimmt. Du hast einen Punkt. Ich habe es ja vorhin selbst gesagt. Ende, egal ob L3, L4, L5, das ist halt diese praktischen Anwendungen, wie das, was Podstock gerade eben im Release hat, das ist ja eigentlich, was den Wert erzeugt. Was ich sagen wollte, ich weiß nicht, ob es eine Prediction ist oder eher ein Wunsch oder eine Hoffnung. Und ich weiß noch nicht, wie man es misst, aber ich würde mir wünschen, dass Tech-Startups alle noch auf Level 4 starten. Idealerweise auch nicht mehr drunter gefundet wird. Warum? Weil das dieses ewige Problem von Legacy Software Technik Adept endlich mal eliminieren würde. Ich glaube, Specs sind die Grundlage dafür, dass du Software auch einfach neu bauen kannst, wenn du halt... gutes Speck-Repository hast, gute Dokumentation hast, dass wirklich als Grundlage hast, einen guten Harn ist, dass du dir als Mensch auch selbst die Regel auferlegst, eine gewisse Disziplin zu haben, hat das, glaube ich, einen großen Wert für Softwarequalität und eliminiert auch so bisschen eine neue Arbeit, die wir beide auch schon lange immer wieder erlebt haben in unserer Karriere, irgendwo hingehen. Und da gibt es immer diesen Belavt. monolith. Genau, wäre vielleicht eher ein Wunsch als eine Prediction. Trotzdem, das würde ich hier in diese Kategorie einbringen. Sebastian: Vielen Dank. Wir sind ja heute so ein bisschen wir zwei und haben ja durchaus auch so ein paar Kontrapunkte gehabt. Deswegen kann ich mir das gerade nicht verknüpfen, den Armin Rohneha dann nochmal ins Spiel zu bringen, der ja gerade mit seiner Firma Erindale Pi gekauft hat, das Codingharness, und der ja gerade selber überall rumläuft und sagt so mit L4, und so würde ich es mal bezeichnen, was die machen, haben die sich so ein bisschen in so eine Sackgasse gekodet und jetzt müssen die wieder runter, mindestens mal ein Level, ⁓ da wieder rauszukommen, weil die Kombination aus Specs und Harness dann am Ende doch nicht gereicht haben, ⁓ sustainably an so einem Produkt weiterzuentwickeln. André Neubauer: Ja, genau. Ja, ja. ich glaube auch, dass, aber das ist wunderbar, dass du es sagst. Das ist halt also quasi Gedanken machen ist jetzt auch kein Garant, dass es funktioniert. Und es zeigt halt einfach, wie groß dieser Sprung ist. Und ich glaube, da haben wir heute leider nicht drüber gesprochen. Aber wenn wir gesagt, das ist die erste von mehreren, da kann man sicherlich auch noch mal so eine Fuck-up-Story draus machen, wo Firmen also und sich nicht drüber lustig zu machen, sondern um draus zu lernen. und dann eben nicht diesen Schritt auf der Leiter geschafft und dann zurück. Und was bedeutet das eigentlich und woraus kann man dann lernen? Genau, aber ich werde mir erst mal die nächsten Tage diese Speck anschauen und versuchen, ein bisschen draus zu destillieren, was dann eine gute Speck ausmacht. Sebastian: cool, da bin ich gespannt darauf. Das können wir hoffentlich in einer der nächsten Episoden noch mal zur Geltung kommen lassen. auf die Plätze fertig los, würde ich sagen. Bereit? André Neubauer: Warte, ich mach einen Marker. Sebastian: Hast du? Okay, alles klar. Sorry, ich sehe den Bildschirm nicht. kann ich es Also ich habe hier so wieder meinen, du weißt schon, ... Boah, wie nennt sich das? André Neubauer: Hab es. Also, Entschuldigung. Sebastian: Herzlich willkommen zu einer weiteren Folge unserer neuen Staffel von HMZ E-Beyond Vibecoding, der Podcast, in dem wir den derzeitigen und fundamentalen Change in Softwareentwicklung intensiv begleiten. Ich bin Sebastian zu erben, CTO bei NorthIO. André Neubauer: und ich bin Andre Neubauer CTPO bei Tusted Schön, dass ihr wieder da Heute sind wir nur zu zweit. Und worum geht es, Sebastian? Sebastian: Dark Factories. Ein Hype-Thema, das in den letzten Wochen viel durch die Szene ging. Und natürlich können wir das Thema auch nicht ganz links liegen lassen. Müssen auch unseren Senf dazu geben. Wir hoffen, dass euch eine solche Episode trotzdem auch gefällt. Lasst es uns gern wissen. Aber jetzt viel Spaß beim Hören.