# Dark Factories: AI Automation in Software Development

**Podcast:** HMZE
**Published:** 2026-05-13

## Transcript

Jetzt, wo ich gerade darüber nachdenke, denke ich mir ja wirklich der feuchte Traum von so CEO-Dudes, also Continuous Innovation und irgendwie Data-Driven, Product-Led-Growth und so ein bisschen fühlt sich das an wie noch schnellere Entschittification vom Produkt und noch häufigere Änderungen der verschiedenen Features, was, da könnte ich mir schon vorstellen, dass die Nutzer da irgendwann an ihre Grenzen kommen.
Herzlich willkommen zu einer weiteren Folge unserer neuen Staffel von HMZE Beyond Vibe Coding, der Podcast, in dem wir den derzeitigen und fundamentalen Change in der Softwareentwicklung intensiv begleiten.
Ich bin Sebastian Heidemeier zu Erben, CTO bei North.io.
Und ich bin André Neubauer, CTPO bei Trusted Shops.
Schön, dass ihr wieder da seid.
Heute sind wir nur zu zweit.
Und worum geht es, 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 dazugeben.
Wir hoffen, dass euch eine solche Episode trotzdem auch gefällt.
Lasst es uns gern wissen.
Aber jetzt viel Spaß beim Hören.
Herzlich willkommen, André, 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 drüber zu reden.
Aber das Thema Dark Factory geistert ja jetzt schon auch ein paar Monate durch die Lander und es ist inzwischen viel darüber geschrieben worden.
Sehr gute, sehr umfangreiche Artikel.
Und wir möchten heute mal so den Versuch wagen, ein 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 weiterentwickeln ü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.
Ja, ich wollte eigentlich bloß hinzufügen, ich glaube, das 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 das Gespräch haben, quatschen wir ja mal 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, aber auch die ganze Produktseite.
Also eigentlich alle, die irgendwas mit Produktentwicklung zu tun haben, sollten den Begriff eigentlich kennen und einordnen können, weil der im Endeffekt dafür steht, 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 es auch ein Referenzmodell.
Absolut, genau.
Und genau, du hast ja umfangreich dich vorbereitet auf die Episode.
Deswegen vielleicht machen wir es so ein bisschen so, dass ich dich auch so ein bisschen interviewe.
Ich gebe natürlich auch immer meinen Senf dazu.
Insofern gehen wir doch mal das Sheet hier durch, das Dokument.
Wo kommt der Begriff Dark Factory eigentlich her, dass du vielleicht kurz mit einer Definition oder Einordnung startest?
Genau.
Ja, ich glaube, das, wo man es halt herkennt, ist tatsächlich eher klassische Industrie.
Also da, wo man halt große Lagerhallen hat, wo man Produktion hat und wo man die Chance hat, halt viel zu automatisieren.
Da kommt der Begriff halt her.
Das ist tatsächlich auch in der Produktion gar nicht so häufig, dass man sagt, alles ist eine Dark Factory, sondern ist eher die Ausnahme.
Es gibt halt, ich glaube, es heißt richtig ausgesprochen, Xiaomi, so eine Smart Factory in Changping, nördlich der 80.000 Quadratmeter, also richtig, richtig große Anlage und halt 100 Prozent Automatisierung.
Ich glaube, produzieren halt 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 halt umzulegen.
Ja, und genau da fängt es schon bei mir an immer, 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 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, dann wird ein Batch produziert, dann wird die Line sozusagen, die Production Line umgerüstet und dann wird halt das nächste Produkt aber immer genau gleich mit den gleichen Specs 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 vielleicht hat man gar keine Software mehr, sondern man hat Agenten, die einfach nur immer wieder Probleme lösen sozusagen.
Aber 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 die Probleme 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.
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, André.
Ja, ja, hast du ja schon quasi, genau, es gibt von Dan Shapiro, muss ich sagen, kannte ich vorher gar nicht so sehr.
Ich weiß nicht, ob du den, also, mich vorher noch mal ein bisschen so schlau gemacht.
kann man von, also der scheint schon sehr umtriebig zu sein.
Der ist CEO von Glowforge und auch so Research Fellow.
Also er scheint das eine oder andere veröffentlicht zu haben.
Muss man auch, also lass mich da ehrlich sein, ich kannte ihn vorher nicht.
Aber der hat halt veröffentlicht The Five Levels from Spicy Autocomplete to Dark Factory.
Der hat also versucht, das Konzept, was wir vorher hatten, also klassische Industrie auf Software Engineering halt umzulegen und hat halt gesagt, Man kann das ja eigentlich machen, wie du gerade gesagt hast, autonomes Fahren hat halt so von Level 0 bis Level 5, quasi im Endeffekt sechs Kategorien, das können wir ja mal auf Softwareentwicklung halt irgendwie umlegen und dann gibt es halt Level 0, heißt halt Spicy Autocomplete, das ist halt quasi, du hast so einen Co-Piloten, der dir halt irgendwie sagt, hier, das quasi 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 halt irgendwie so Boilerplate.
Und hast halt voll Human Review.
Also nicht mal nur ein Review im Sinne von ein Code Review, sondern halt ein Instant Review, quasi guckst zu.
Level 2 ist eher so das ganze Thema Pair Programming.
Das sind halt beide gleichberechtigt, also auch immer wieder im Wechsel.
Und da ist auch so ein bisschen der Gedanke quasi, wo Shapiro sagt, 90 Prozent der AI-Native-Engineers sind halt dort.
Also Leute, die sagen halt, ich bin halt AI-Native und wir sind halt erst bei L2.
Geht dann halt rüber zu L3, das ist ein Code-Reviewer.
Reviewed jede Zeile, oder reviewed jeden Div, nicht jede Zeile, aber jeden Div.
Also sind wir halt immer noch bei einem relativ kurzen Cycle, das hast du auch gerade angesprochen, kurzen Loop, genau, kurzen Loop.
Und dann gibt es L4, das ist schon spec-driven.
Wenn wir auch bestimmt gleich nochmal ein 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, ist schon ein größerer Loop.
Und dann L5 ist halt die Dark Factory.
Da geht es eigentlich eher in die Richtung, dass du halt sagst, also du gibst halt das Ziel vor, aber selbst die Spec quasi wird halt von dem System halt entwickelt, inklusive allem, was halt.
danach folgt.
Und das sind quasi diese sechs Level, die eigentlich auch einen guten Eindruck geben, an dem man sich gut entlanghangeln kann, wo man selbst steht, wo man halt mit einer Organisation steht.
Genau.
Vielleicht dazu mal eine Frage.
Der Unterschied zwischen L4, also ich schreibe Detail Specs und checke 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 umfangreich die Specs sind, die den Agenten dazu leiten, eben nicht nur ein Feature nach einer Spec, sondern ein ganzes Software-Increment oder Teilprodukt zu erstellen.
Fragezeichen?
Ja, also das auf alle Fälle.
Also es ist bestimmt ein...
gutes Messkriterium.
Ich überlege gerade noch, ich habe so ein System noch nicht gesehen.
Wir kommen ja 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 will nicht sagen YOLO, aber man kann da ein bisschen entspannter rangehen.
Also wenn man halt eine SPEC schreibt, ist das, glaube ich, anspruchsvoller.
Und quasi die Schwere, also der Anspruch, verschiebt sich ins System.
Deswegen ist es wahrscheinlich auch ein bisschen schwer, für mich zumindest noch nachzuvollziehen, wie ein System quasi auf Basis von weniger Informationen eine...
eine gute Antwort, also quasi ein gutes Ergebnis halt abliefern kann.
Auf der anderen Seite sind das halt die Freiheitsparameter, die man dann wahrscheinlich mit einem guten Harness halt so weit eingrenzen kann, dass das Ergebnis halt wiederum stimmt.
Ich glaube, was wichtig ist, ist halt, sorry, das ist jetzt zu viel Quatsch, wir kommen da bestimmt auch gleich nochmal 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 Spec schreiben, sondern das verändert alles.
Das verändert Prozesse, das verändert Organisation.
Insofern ist auch der Sprung von L4 zu L5 noch ein viel größerer.
Da geht es nicht nur darum, dass der quasi das Speck jetzt dann auch von dem System geschrieben wird, sondern da hängt, also das muss man sich immer wie noch eine größere Veränderung auf der Metaebene halt irgendwie vorstellen.
Also du brauchst halt viel mehr Harness, sorry, darüber müssen wir auch mal eine Folge machen.
Was ist ein Harness?
Damit das halt funktioniert.
Damit das halt funktioniert.
Ansonsten ist halt nämlich Slop.
Ja, ich meine, vielleicht ganz kurz nur für diejenigen, den der Begriff Hanus noch nicht sagt und den haben wir, glaube ich, auch schon benutzt in den 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 Tooling und mehr Automation, die genau diesen diese Noise reduziert, die wir in der letzten Folge mit Ingo Eichhorst besprochen haben, sodass am Ende auch wirklich was Deterministischeres rauskommt, als sozusagen wenn man ein sehr vages Gespräch führt.
Genau, das ist das Harnes und da hat Strong DM, die sind ja so die Vorreiter oder die sind halt rausgegangen ganz stark mit ihrer Dark Factory.
haben da auch sehr viel drüber geschrieben und die haben ja auch ein allgemeines Framework veröffentlicht, ihr Attractor-Framework, was, wenn man sich das mal anguckt, ja wirklich sehr auch, sagen 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 kein Tool oder kein Harness selber Open Source, sondern eher eine Reihe von Specs, tatsächlich kann man auch wieder sagen, die so einen Harness beschreiben.
Ich glaube, es sind genau drei Markdown-Files.
Also ich glaube, es gibt noch irgendwie Lizenz und Readme oder so, wenn ich es richtig sehe.
Ich glaube, das ganze Report 5 Files.
Ich finde, dass, wenn man sich das überlegt, da liegt natürlich die Komplexität in den Markdown-Files.
Das ist auch klar.
Aber wenn man sich überlegt, wie heutige Softwareprojekte aussehen, wie viele Artefakte, verschiedene Artefakte du da drin hast und wie stark man das abstrahieren kann und das mit einem Harness, eben halt trotzdem gute Ergebnisse halt rauskommen.
Das ist halt einfach faszinierend.
Also wir packen auch alle Links in die Shownotes, sind heute tatsächlich ein paar Sachen mehr.
Kann man, glaube, wenn man da vier, fünf Sachen liest oder sich die Gitter-Präbus anguckt, glaube ich, ist man aber auch schnell im Thema.
Genau, aber Strong DM ist wahrscheinlich eins der, kann man dazu Posterscheid sagen?
Ja, wahrscheinlich, würde ich sagen.
Wahrscheinlich sogar das Posterchild.
Ich weiß gar nicht, ob irgendjemand so stark damit rausgegangen ist und den Begriff so geprägt hat wie StrongDM.
Weiß ich gar nicht.
Also die sind immer das Beispiel, was so genommen wird.
Was wiederum natürlich auch die Frage offenlegt oder it backs the question sozusagen auf Englisch.
Ist es ein Standardfall oder ist es eher so eine Exception sozusagen?
Aber kommen wir vielleicht später nochmal 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.
Das soll mit Anthropic, OpenAI, aber auch anderen Modellen funktionieren.
Und da haben sie so eine Spec gebaut, die Designprinzipien oder eigentlich die Spezifika von den einzelnen LLM-Providern sozusagen 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 genau, also sprich, welche 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 Graphennotation nutzt, .syntax, um Anforderungen oder auch die Zusammenhänge zwischen Anforderungen zu beschreiben, damit eben dann am Ende ein System rauskommt, was der Agent oder das Harness sozusagen komplett autonom implementieren kann.
Ja, und sorry, bitte André.
Ich wollte sagen, auch das hatten wir 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, um 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 so formulieren, 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 Wasser.
Also man denkt halt immer noch sehr stark in diesem wahrscheinlich auch Level 3.
quasi viel Domäne, viel halt irgendwie, ich muss halt Rydion, 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 quasi diese Abstraktion, also trotz Abstraktion halt diese Präzision halt nicht verliert.
Und das finde ich, ich glaube, du hattest Boris Czerny halt, weißt du, ob der in dem Zusammenhang mal irgendwas erwähnt hat, aber vielleicht magst du es auch kurz korrigieren oder ergänzen.
Ja, am Ende entspricht es für mich so ein bisschen dem Vorgehen, was ich auch von Boris Czerny wahrnehme, dass der ja sehr viel seiner Zeit darauf verwendet, mit dem Harness, also in dem Fall natürlich.
Cloud-Code, in Planning-Modes zu interagieren, bis die Spec wirklich rund ist.
Und dann lässt er den Agent erst implementieren.
Und das ist sicherlich eher L4 als L5, aber nach meinem Dafürhalt ein bisschen universeller einsetzbar deswegen.
Genau, vielleicht...
Bevor wir da hinkommen, nochmal kurz zu, wie sind StrongDM 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, wir postulieren mal zwei Regeln.
Code darf nicht von Menschen geschrieben werden und darf auch nicht von Menschen gereviewt werden.
Und sind damit dann losgegangen und haben da eine ganze Reihe Erfahrungen gemacht.
eigentlich auch alle, die ich kenne, die so ein bisschen tiefer reingegangen sind ins Agentic Engineering, also Beyond Vibe Coding, die auch ganz schnell merken, natürlich sind die LLMs quasi, die inzentiviert immer 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, um den Test grün zu machen, gleich True gesetzt werden an irgendeiner Stelle, also ein Return True.
Und um das 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, um ...
das Ergebnis der fertigen Software, die Akzeptanzkriterien abzutesten.
Und haben dann auch gesagt, sie denken eigentlich eher in Szenarios, die sie durch die Agenten oder durch das 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 Szenarios 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 explizite oder gar nicht so viele UI-Interaktionen hat, sondern stark integriert ist in diverseste Tools, wo es halt immer um die Integrationstests geht.
Also 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.
Und jetzt erkennt man daran schon, das ist ein sehr spezieller Case.
Also ich meine, Integrationen 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, sehr viel über die korrekte, quasi das korrekte Ergebnis in der Integration, an der Schnittstelle sozusagen, darüber können sie viel validieren, ob das Produkt dem entspricht, was intendiert war.
Interessante, sagen wir mal, eine interessante Herleitung und auch interessante Findings, bei denen sie gelandet sind.
Und ich glaube, in der Vorbereitung, was das für mich so nochmal gezeigt hat, ist halt, wie groß diese Disziplin, also der Anspruch an Disziplin ist.
Und deswegen, du hattest es gesagt, es gibt halt zwei Rules, Code shall not be written by humans und Code shall not be reviewed by humans.
Also wenn du halt quasi human komplett rausnimmst, dann hast du auch also quasi eine Maschine, an der Stelle ist deterministisch.
Also es ist halt quasi, es wird eingehalten.
Und ich glaube, das ist halt super wichtig, dass man halt, wenn man quasi L4, L5, du brauchst halt einfach, also es ist dann nicht mal Larifari, um das mal anders zu sagen.
Also 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 da drinnen halt das System gut arbeiten kann.
Und das ist so elementar.
Als ich das gelesen habe, ist mir so bewusst geworden.
Und ich glaube, wenn man sich da auch selbst anschaut, das ist nicht immer in der täglichen Arbeit gegeben.
Da macht man mal hier einen Shortcut, mal da, ach komm, das machen wir nächste Woche.
Und hier, ach gut, das muss jetzt halt irgendwie raus.
Und das quasi, das gibt es in diesem System halt nicht.
ist aber elementar, wenn du halt auf dieses Level willst.
Ansonsten ist es halt Crap.
Absolut, das haben die halt wirklich par excellence durchgezogen und durch exerziert.
Und genau, und da sieht man auch, und das ist vielleicht auch jetzt wieder den Loop zum Beginn unserer Diskussion, wenn man sich auf diesen Pfad begibt, dann ist es ein echtes Commitment.
Man muss die Arbeitsweise grundlegend umstellen.
Und 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, um 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 lang wir diese Loop-Länge in unserem Kontext tatsächlich bekommen.
Der 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.
Jetzt ist Excel oder Excel, wie man im Englischen sagt, ja über Jahrzehnte entstanden, hat sich weiterentwickelt.
Man kann sagen, sicherlich hat ein gutes Stück auch in Certification 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 im 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, um 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.
Wer war das?
Irgendjemand hat einen Browser gebaut.
Ich habe vergessen, ob das, ich glaube Cursor, die haben den 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, da wirst du wahrscheinlich einen Agenten jetzt nicht zwei Wochen laufen lassen können, 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.
Das fällt heute schwer, das zu predikten.
Würdest du da mitgehen, dass man sagt, also quasi diese großen Sprünge L3, L4, L4, L5, dass das exponentiell mehr Aufwand bedeutet als die Sprünge davor?
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 quasi, also wenn du das auf eine gesamte Organisation mitziehst, dass es dann mehr Aufwand wird, weil an einem bestimmten Punkt, du schiebst ja irgendwelche Bottlenecks immer vor dir her.
Irgendwie ganz am Anfang, Autocomplete, du machst halt einfach das Codeschreiben für den Menschen schneller.
Das zweite ist auch immer noch Codeschreiben für den Menschen schneller machen.
Und auch das dritte, genau.
Dann eben Code Reviewen, da kommt dieses Bottleneck-Code-Review, hatten wir ja auch in der Folge mit.
mit Uli von Mapbox schön 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 eins weiter rausgesumt.
Wobei ich auch noch nicht genau sagen kann, ob nicht, wenn ich den Schritt von ich schreibe keinen Code mehr und quasi sozusagen bin auch nicht mehr aktiv an der quasi Coding ist gar nicht mehr meine 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 Codestellen an, wenn ich so eine Handschabe Da könnte irgendwas nicht stimmen, dann schaue ich da mal rein, frage den Agenten auch explizit dann nach, wie er bestimmte Probleme gelöst hat oder nach Code stellen.
Ansonsten checke ich aber die Specs und das ist halt der Punkt in dem Startup, was jetzt anfängt, wo du direkt sagst, wir versuchen mal jetzt so schnell zu sein wie nur irgend möglich, fängst du vielleicht auf L4 an und dann ist alles, was davor ist, vielleicht gar nicht da.
Deswegen würde ich sagen, es hängt von der Größe der Organisation an.
Achso, halt, und noch ein weiterer Punkt, sorry, ich bin auch ein bisschen will 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...
Codeschreiben ist einfach nicht mehr das Bottleneck, CodeReview ist das Bottleneck.
Dann irgendwann ist CodeReview nicht mehr das Bottleneck und dann sind es wirklich die Ideen, die das Bottleneck werden.
Und dann musst du halt gucken, wie kriegst du die Organisation, 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.
Ich glaube, das ist ein super Punkt mit, ich glaube, als Startup, 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 hätte ü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, also.
sie machen auf deinem Satellite doch Sinn.
Also du würdest halt nicht von quasi Per-Programming-Mode in quasi Spec halt irgendwie selbst springen, weil der Schritt ist halt viel zu groß.
Insofern brauchst du dann einen Zwischenschritt, quasi der Zwischenschritt über L3.
Code-Reviewer.
Genau, Code-Reviewer macht dann halt wahrscheinlich erst Sinn.
Warum ich das halt aber frage, warum ich das gefragt habe, ist halt auf der anderen Seite machen die Aufwände, zum Beispiel L3, L4, du musst jetzt auf einmal Spec-Driven lernen, also du liest nicht mehr Code durch, sondern du versuchst halt die Specs möglichst präzise zu formulieren, das ist glaube ich auch eine Fähigkeit, die braucht halt Training, Training, Training und dann hast du das halt irgendwann gemastert und dann sagst du, okay, jetzt L5, wenn du es denn möchtest, Da kommen wir vielleicht auch gleich nochmal zu.
Und F5 ist dann aber, da brauchst du dann wieder gar keine Specs.
Da hilft dir natürlich das Wissen quasi, wie eine gute Speck halt aussieht, total, damit du halt den Hannes, den richtigen Hannes darum herum bauen kannst.
Aber, 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 du, was ich meine?
Und deswegen stelle ich es mir sehr schwer vor.
Ich habe halt auch keine...
praktische Erfahrung von so einem L4 auf dem L5.
Ich 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 immer eine neue Klasse an Problemen.
Ja, ich bin hier gerade nochmal bei Dan 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 Innenstadtgebieten 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.
Und 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 Spec und quasi bist mit dem Agenten Hones, also arbeitest du an der Spec, schreibst Skills und machst Pläne etc.
Und bei Level 5, da ist dieses, das Harness ist halt fertig sozusagen und du bist nur noch auf der Spec.
Das heißt, du bist eigentlich, glaube ich, bist du vielmehr nur noch auf der Domäne, also auf der Business-Domäne und 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.
So verstehe ich es.
Komplett in dem Bild, ich wollte gerade sagen, ist, ich glaube, mal gucken, ob das stimmt, ob du da zustimmen würdest, ist, F5 bedeutet eigentlich keinen Führerschein mehr haben zu müssen.
Und das ist, glaube 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 halt eigentlich bedeutet, jeder.
kann Auto fahren, ohne Auto fahren zu können.
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, die 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 ein Engineering Know-how, beziehungsweise du musst irgendwann entweder es dir aneignen oder ...
Und das in irgendeiner Form hinzunehmen.
Je größer das wird, skalieren muss, dann auch Architektur-Know-how etc.
Technologie-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 Technologie-Know-how braucht.
Allerdings, jetzt wieder auf das Strong-DM-Beispiel zu kommen, kann ich mir durchaus vorstellen, dass man für einen bestimmten Anwendungsfall ein Harness bauen kann, was das Technologie-Know-how genug ist.
weg abstrahiert.
Wenn man sagt, man hat eben eine schmale UI, die 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 auf der Logikebene sagen, okay, welche Compliance oder also Regeln möchte ich denn jetzt abbilden können auf dieser Grundlage.
Das kann ich mir durchaus vorstellen.
Wobei auch bei StrongDM waren das ja Engineers, also unter anderem der CTO, die daran gearbeitet haben.
Total, total, total.
Ein bisschen gucken auf die Zeit.
Wir können bestimmt gleich, machen wir die Predictions?
Bestimmt.
Können wir mal überlegen.
Noch ein Beispiel, auch in der Recherche darüber gestolpert, Postdoc hat quasi ein ganz nettes Feature gelauncht und warum bringe ich das hier gerade auf?
Ich erkläre es auch gleich, was das macht.
Also warum macht man das halt eigentlich auch alles?
Man will ja quasi, man will ja trotzdem Wert schaffen.
Also es geht ja nicht nur darum, am Ende ein Level-5-System zu haben, um halt einfach zu sagen, jetzt kann ich halt...
x-beliebige Software halt irgendwie machen, sondern man will das ja entlang von quasi wirklich, also idealerweise würde man, vielleicht gibt es auch so ein Level 6 oder so, müsste man mal recherchieren.
Ich habe es auch schon ein, zwei Mal gehört von Leuten, die dann halt 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.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, um halt sich selbst zu füttern, um sich dann zu verbessern.
Und ehrlich gesagt, neben all dem L1 bis 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 ein bisschen wie Schiffe versenken, also man quasi hat so einen Treffer und dann versucht man halt mit quasi einer guten Strategie Und da ist man nicht auf sich selbst, weil man quasi vielleicht selbst immer denkt, man hat die besten Ideen, sondern halt wirklich datengetrieben, was das auch immer bedeutet oder wo auch immer die Daten und Impulse und Signale halt herkommen.
Quasi schafft man ein System, wo man sich kontinuierlich halt irgendwie vorwärts bewegt und dann halt irgendwie quasi ein zweites, ein drittes, ein viertes Thema halt für sich halt entdeckt, ohne dass man… wo er das System das für einen entdeckt.
So muss man es ja eigentlich sagen.
Fand ich unheimlich begeisternd.
Ich glaube, man kann sich auf eine Warteliste schreiben.
Ist announced für Frühling.
Keine Ahnung, wie lange der Frühling noch geht.
Aber also auf die Warteliste kann man sich schreiben und finde ich eine total spannende Entwicklung.
Du hast es ja geteilt im Vorfeld, ich fand es auch super spannend.
jetzt, wo ich gerade darüber nachdenke, denke ich mir ja wirklich der feuchte Traum von so CEO-Dudes und also Continuous Innovation und irgendwie Product-Led Growth und so ein bisschen fühlt sich das an wie noch schnellere Inchitification vom Produkt und noch häufigere Änderungen der verschiedenen Features, was da könnte ich mir schon vorstellen, dass es dass die Nutzer da irgendwann an ihre Grenzen kommen.
Also ich meine, ich weiß nicht, wie es dir so geht, aber es gibt so Tools, die ich benutze, da ist die Veränderungsgeschwindigkeit in Teilen so hoch, dass ich genervt bin.
Und ja, insofern muss man da, glaube ich, auch so Guardrails einsetzen.
Und am Ende, meine feste Überzeugung, solange du für Menschen was ein Produkt baust, musst du mit menschlichem Bauchgefühl oder muss irgendeine menschliche Intuition die Produktentscheidung zumindest informieren.
Das sollte ein relevanter Bestandteil der Entscheidung sein.
Da kann man ja natürlich auch wieder irgendwie so einen Human-in-the-Loop haben.
Ich fand den Impuls bloß, also quasi das, neben all der Theorie, diese praktische Anwendung an der Stelle halt beeindruckend.
Absolut.
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.
Eine ideale Weiterentwicklung.
Zweifelsohne.
Genau, vielleicht 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 Symfony.
Und einer der Wege, wie das ausgerollt wird, ist Einfach eine Spec.
Das heißt also, über eine Spec kann man sich im Agent der Wahl einfach dieses Tool bauen lassen, sozusagen.
Das ist auch wieder so ein 6000 Lines of Code Spec.
Und boom, da hast du sozusagen ein gutes Beispiel dafür, dass ein sehr gut durchgespecktes Softwareprodukt repeatable erzeugt werden kann in verschiedenen Umgebungen.
Ist so ein 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 ist auch ein sehr gutes Beispiel.
Eigentlich müsste man das mal in die Finger bekommen, dieses Speck, weil das ist ja ein sehr, sehr gutes Speck, um daraus mal zu destillieren, was macht halt ein gutes Speck halt aus.
Die ist ja im GitHub.
Die kannst du dir angucken.
So funktioniert es.
Du kannst 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, quasi gibt es Cloud Code, gibt es Pi, in welcher Umgebung auch immer.
Und sag, hier, bauen wir mal.
Dann folgende Sache.
Ich habe ja Fire.
Mal gucken, wann wir diese Folge veröffentlichen.
Aufnehmen tun wir am Montag.
Ich fahre am Mittwoch zurück mit ein paar Stunden im Zug.
Das gucke ich mir mal an.
Entweder machen wir dazu eine Folge dann nochmal oder also was macht ein gutes Backaus?
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, das ist eine schöne Fingerübung, weil auch als ich in dieses Repo geschaut habe, das sieht halt mega aufgeräumt aus, also vom Strong DM.
Aber da mal raus zu destillieren, was halt denn nun quasi wirklich ein gutes Spec 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-Ingenieurs, wir wären alle Spec-Ingenieurs.
Vielleicht auch das nochmal.
Text Engineers, oder Hanes.
Oh mein Gott.
Genau.
Jetzt haben wir alle Bullshit-Bingo-Worte, glaube ich, in unserem Bingo-Feld nochmal quasi abgekreuzt.
Genau.
Und können auf die Zielgerade einbieten, denke ich mal.
Reality Check and Prediction.
Schieß mal los.
Ja, Reality-Check, wir machen da einmal Fuck-up und beeindruckend.
Also ich würde das jetzt beides am Modell von Dan Shapiro halt mal belassen.
Erstes Positive, wie man immer gelernt hat.
Dieser Aha-Moment, der ist jetzt fairerweise schon ein paar Tage her bei mir, aber Der Aha-Moment quasi, wenn man Software auf eine andere Art und Weise erstellen kann.
Das ist für mich immer noch, also wenn immer das passiert, ist für mich so ein, also ich habe 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 ein bisschen der Fuck-up.
Modus ist, wenn du damit dann halt irgendwie denkst, okay, und jetzt halt irgendwie die nächste Stufe, das ist unendlich schwer.
Ich hatte ja vorhin schon gesagt, also quasi die ganze Organisation dahin zu bringen, ist halt schwer, nicht weil die Leute das nicht wollen.
Also das, klar, 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, ganz anderen Harness, vielleicht kleinere Teams, weil Agents sich ja ansonsten auf den Füßen stehen.
Also da kommst du von...
vom Hundertste ins Tausendste und das ist halt echt frustrierend, weil halt auch eine gewisse Menge halt erst schaffen musst, um halt quasi dann wirklich diese Benefits, von diesen Benefits zu partizipieren.
Also das wäre mein Reality Check.
Wie sieht es bei dir aus?
Ja, mein Reality Check ist tatsächlich also der 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 SARS-Tools ersetzt durch OpenClaw und zahle jetzt 1500 Euro an Anthropic im Monat und 15 Stunden die Woche muss ich irgendwie irgendwelche Probleme in irgendwelche Jamelfalls editieren.
Ich sehe mich da wieder.
Also ich zahle halt meine OpenAI-Subscription und dann noch ein bisschen Gemini, wenn ich mal ins Rate-Limit laufe, quasi Zusatz.
Das ist aber, weiß ich, 1,50 Euro war es im letzten Monat.
Also es hält sich in Grenzen so.
Von daher geht es noch.
Aber fairerweise, ich ersetze damit auch keine SaaS-Services, sondern ich mache damit Dinge, die vorher so gar nicht möglich gewesen wären.
Ob ich jetzt mein Wissen...
stärker organisieren, besser im Zugriff habe, eben den Kontext griffbereit habe, den ich für bestimmte Dinge einfach brauche oder eben bestimmte Sachen automatisiere, wie es im Podcast schon mehrfach erwähnt.
Und da bin ich halt immer dabei, an Skills rumzudoktern, aber regelmäßig muss ich dann auch doch wieder gucken.
Speicher auf dem Host ist vollgelaufen, muss ich mal Files löschen und der VM mehr Disk Space geben.
Oder einmal hatte 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 Kontext da oder die Sessions verarbeitet werden.
Und ich habe dann einen Backhand gemacht und habe dann mit dem Agenten eine Änderung vorgenommen, die dann aber leider den Agenten quasi ausgehebelt hat.
Und da musste ich nochmal zurückrollen.
Und genau, also ich verbringe mehr Zeit auf dem Host, als mir lieb 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 einen Wow-Moment hatte ich gerade heute wieder.
Ich habe jetzt ein paar Wochen nicht in so eine große, Applikationen reingeguckt, die ich halt agentisch ingeniert habe.
Und da ist mir gerade, während wir gesprochen haben, aufgegangen, dass ich tatsächlich da so ein bisschen von, also mich die Levels hochbewegt habe.
Also ich habe initial, ich will nicht sagen, dass ich Code geschrieben habe, das nicht.
Eine Go-Applikation mit React, ich habe 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, um 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 Codestelle angucken, wenn ich das Gefühl habe, hier könnte wieder so ein komischer Fallback entstanden sein, wo der Agent 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.
Ja, genau.
Irgendeine Annahme.
Magst du noch eine Prediction machen?
Also wird das besser, schlechter?
Was wäre deine Prediction allgemein?
Ja, das ist eine gute Frage.
Also 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 keine Blase platzen wird.
Das ist jetzt wirklich aus der hohlen Hand, habe ich vorher nicht genau darüber nachgedacht, aber 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.
Anthropik 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 dass auch nur annähernd mit den Kosten, die da entstehen, ein Produktivitätswachstum entsteht.
Das kann man jetzt auf verschiedene Arten interpretieren, beziehungsweise es gibt für alles Erklärungen.
Man kann natürlich sagen, dass die Studien oft veraltet sind.
Also sprich, die sind ja immer rückwärtsgewandt.
Die haben sich dann irgendwelche Sachen aus 2025 angeguckt.
Das kannst du mit.
den neuesten Modellen und den Harness-Entwicklungen jetzt schon gar nicht mehr vergleichen.
Model Evels sind strukturell einfach schwer und das ist wirklich, die wenigsten Firmen machen das at scale und dann hast du ja noch einen Harness und dann hast du noch irgendwie Skills und dann hast du noch ganz viele variable Faktoren.
Du hast geopolitische und wirtschaftliche Faktoren, die einen 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 Context Engineering Ansatz, einen Entwicklungsansatz finden, der für sie gut funktioniert, die können.
Sustained, sehr wahrscheinlich deutlich, deutlich schneller entwickeln als andere und auch vor allem viel, viel mehr experimentieren, als es früher war.
Was wir 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 Click-Dummy ist, aber schon auch ein Gutteil der Funktionalität, je nachdem, was es ist, irgendwie enthält.
Und ich glaube, dass es Firmen geben wird, die das als 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 da noch relativ am Anfang ist, die da noch nicht ganz klar belegen kann, ob es einen Produktivitätszuwachs gibt.
Das liegt ja auch darin, 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 Sinn, dieses Dark Factory Pattern.
nochmal zu reviewen in einem halben Jahr, einem Jahr, was auch immer.
Meine lange Prediction.
Sorry.
Ich höre da mal gespannt zu.
Zum Thema Produktivität ist ja die ewige Frage nach Output und Outcome.
Das ist, glaube ich, ein sehr schweres Thema.
Passt aber nicht so richtig in den Podcast, aber in die alten Folgen hätte es wahrscheinlich reingepasst.
quasi, was ist relevanter.
Meine Prediction ist, vielleicht 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 und 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 erstmal platzen muss, bevor es dann, nachdem durch das Tal der Tränen man durch ist, nachdem es dann wieder hoch geht.
Ja, bestimmt.
Du hast einen Punkt, ich habe es ja vorhin selbst gesagt, am Ende, egal ob L3, L4, L5, dass halt diese praktischen Anwendungen, wie das, was Podstock halt gerade eben im Release hat, das ist ja eigentlich was, was den Wert erzeugt.
Was ich sagen wollte, ist, ich weiß gar nicht, ob es eine Prediction ist oder eher ein Wunsch oder eine Hoffnung.
Und ich weiß 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 darunter gefundet wird.
Warum?
Weil das dieses ewige Problem von...
Legacy-Software-Technik-Adapt halt endlich mal eliminieren würde.
Ich glaube, Specs sind die Grundlage dafür, dass du halt Software halt auch einfach dann neu bauen kannst, wenn du halt ein gutes Specs-Repository hast, gute Dokumentation hast, das wirklich als Grundlage hast, einen guten Harness, das als quasi dir als Mensch auch selbst die Regel auferlegst, also eine gewisse Disziplin zu haben, hat das, glaube ich, viel für hat das einen großen Wert für Softwarequalität und quasi eliminiert auch so ein bisschen eine neue Arbeit, die wir beide auch schon lange immer wieder erlebt haben in unserer Karriere.
Irgendwohin gehen und da gibt es immer diesen Belarved Monolith.
Genau.
Wäre vielleicht eher ein Wunsch als eine Prediction.
Trotzdem.
Das quasi würde ich hier in diese Kategorie einbringen.
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 verkneifen, den Armin Ronacher da nochmal ins Spiel zu bringen, der ja gerade mit seiner Firma Aaron Deal Pie gekauft hat, das Coding Harness.
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 gecodet.
Und jetzt müssen die wieder runter.
mindestens mal ein Level, um da wieder rauszukommen, weil die Kombination aus Specs und Harness dann am Ende doch nicht gereicht haben, um sustainably an so einem Produkt weiterzuentwickeln.
Ja, genau.
Aber das ist wunderbar, dass du es sagst.
Also quasi Gedanken machen ist jetzt auch kein Garant, dass es funktioniert.
Und das zeigt halt einfach, wie groß dieser Sprung ist.
Und ich glaube, da haben wir heute leider nicht drüber gesprochen, aber wir haben ja gesagt, das ist die erste von mehreren.
Da kann man sicherlich auch nochmal so eine Fuck-Up-Story draus machen, wo Firmen, also um sich nicht drüber lustig zu machen, sondern um daraus zu lernen, dieses quasi Versuch, diesen Schritt zu machen 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 erstmal die nächsten Tage dieses Spec anschauen.
und versuchen da ein bisschen daraus zu distillieren, was dann eine gute Speck ausmacht.
Sehr cool, da bin ich gespannt drauf.
Das können wir hoffentlich in einer der nächsten Episoden nochmal zur Geltung kommen lassen.
Der HMZE Podcast ist ein gemeinsames Projekt von Sebastian Heidemeyer zu erben und André Neubauer.
Infos zum Gast und Themen aus dem Podcast findest du in den Show Notes.
Diskutieren kannst du mit uns bei LinkedIn und für alles andere, zum Beispiel, wen du gerne mal hier hören möchtest, kannst du gerne eine E-Mail an podcast.hmze.tech schicken.
Vielen Dank für deine Zeit.
Wenn es dir gefallen hat, abonniere den Podcast.
Bis zur nächsten Folge.
Auf die Plätze fertig los, würde ich sagen.
Bereit?
Weiter, ich mache einen Marker.
Hast du?
Habe ich.
Hast du?
Okay, alles klar.
Sorry, ich sehe den Bildschirm nicht, deswegen kann ich es...
Ach so, Entschuldigung.
Also ich habe hier so wieder meinen, du weißt schon, meinen, boah, wie nennt sich das?
Ja, du weißt schon.