# Building AI-Driven Software Factories for Scalable Development

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

## Transcript

Wir sind eigentlich alle noch im Moment so Zauberlehrlinge, die versuchen, den Herr der Agenten zu werden, in Anlehnung an Herr der Ringe.
Da sind wir im Moment noch.
Und ich glaube, wir lernen alle noch.
Und ich weiß auch noch nicht, wo die Reise hingeht.
Aber eins würde ich sagen, ist Software Factories kommen, ob Dark oder Light.
Keine Ahnung an der Stelle.
Vielleicht auch was dazwischen.
Herzlich willkommen zu einer weiteren Folge unserer neuen Staffel von HMZ eBiond Vibe Coding.
Der Podcast, in dem wir den fundamentalen Change in der Softwareentwicklung begleiten.
Ich bin Sebastian Heidemeier zu Erben, CTO bei Northeis.
Und ich bin André Neubauer, CTPO bei Trusted Shops.
Schön, dass ihr wieder da seid.
Heute mal wieder was ganz anderes.
Einige von euch haben bestimmt unsere Folge zu Dark Factories gehört.
Zumindest eine Person, nämlich der Ulrich.
Genau er hat uns nämlich im Anschluss geschrieben und von einem...
Experiment in seiner Firma ZIT.
Ganz genau.
Das war der Grund, warum wir Ulrich und seinen Kollegen Andreas für heute eingeladen haben in unseren Podcast.
Er beschreibt den Weg zur Dark Factory.
Wobei ganz dark ist die Factory dann noch nicht.
Er sagt auch selber, dass er den Begriff nicht so doll findet.
Aber interessant war das Gespräch.
Trotzdem freut euch drauf.
Viel Spaß beim Hören.
Herzlich willkommen Ulrich und Andreas von NPIT.
Wir haben uns ja kennengelernt in Folge unserer Episode über Dark Factories.
Ulrich, da hast du mich angeschrieben, uns angeschrieben und ganz Spannendes zu berichten gehabt.
Und ja, da kam die Idee auf.
Laden wir euch doch direkt mal ein und hören mal aus der Praxis von euch.
Aber bevor wir dahin kommen, wie üblich stellt euch doch gerne...
ganz kurz und auch vielleicht Enpit, was ihr so tut und euch beide unseren Zuhörern mal vor.
Ulrich, möchtest du anfangen?
Ja, sehr gerne.
Danke erstmal Sebastian, André, dass wir dabei sind an der Stelle.
Ich habe eure Folge sehr gut verfolgt und dachte, wow, jetzt würden wir gerne mal unsere Meinung dazu sagen, wie wir bei Enpit dazu denken.
Wer bin ich?
Ich bin CEO von der Enpit.
Wir sind ein kleines Consulting-Lösungsunternehmen.
was Digitalisierung und all diese Buzzwords macht, die ihr alle kennt.
Die werde ich jetzt nicht wiederholen.
Und ich habe den PIT mit dem Andreas, der oben rechts von mir sitzt, gegründet und der sagt jetzt mal was zu sich.
Ja, ich bin der Andreas Koop, bin Mitgründer von NPIT und arbeite als Software-Engineer, Architekt.
Immer mit so einem pragmatischen Mindset.
Das ist mir immer wichtig.
Ergebnisse zu liefern, gleich Dinge auszuprobieren, nicht nur irgendwie auf Papier zu malen, auch wenn wir das auch gerne machen, also arbeiten sehr viel mit Whiteboards sehr gerne.
Und ja, um Dinge als, ja, Leute alle abzuholen, die irgendwie involviert sind in der Problemstellung.
Und ansonsten, ich bin Informatiker, habe Informatik studiert, bin also durch und durch Technik verliebt nach wie vor und ja, Liebe ist, sage ich mal, Probleme zu lösen.
Und wir bei N-PID sind gerne auch immer dabei, vorne dabei, was passiert in der Technik und es ist immer unser Anspruch, vorne mit dabei zu sein.
Wunderbar.
Ja, dass Probleme lösen, das vereint uns wahrscheinlich und auch die Liebe zur Technik.
Deswegen sind wir hier heute auch zusammengekommen.
Cool.
Erstmal vielen Dank für die Intro.
Wir starten ja immer mit dem...
aktuellen Status sozusagen bei euch.
Also womit arbeitet ihr denn so?
Wie sieht euer Tech-Stack aus?
Naja, ich würde sagen, vor einiger Zeit sind wir damit angefangen, die vielleicht viele, die dann in dieses Weekend so gezogen sind und alles ausprobiert haben an der Stelle und haben die Reisen über verschiedene LLMs hinter uns, von Codex, Antigravity, Cloud.
Wir haben uns im Microsoft-Stack angeguckt, da sind wir wieder weggegangen so ein bisschen an der Stelle.
Und auch diese typischen Dinge, dass wir angefangen haben, eigene Skills zu schreiben, Reviewer als Beispiel.
Und für uns war wichtig, in diesen Dingen, wie wir arbeiten, zu lernen, was heißen denn diese neuen Konzepte wie Context Engineering?
Was heißt denn Arnes?
Was heißt das denn eigentlich selber zu fühlen?
Und was vielleicht noch wichtig ist, bevor ich das Wort zu Andreas gebe, ist, wir schauen gerade, weil wir ein kleines Unternehmen sind, nicht nur aus der Code-Sicht hin.
Software-Development, weil wir wollen diese Tools natürlich auch für das Business, für das Backoffice etc.
benutzen an der Stelle und da sind wir natürlich auch im Moment auch mit Cowork und damals auch so ein bisschen mit Microsoft-Dingen unterwegs, um zu fühlen, wie das nachher zusammenpasst.
Andreas, was willst du ergänzen?
Also ich sag mal so, das Main-Werkzeug-To-Go ist so ein bisschen das Cloud-Universum.
Zuletzt haben wir uns so ein bisschen geeinigt, sprich jeder hat da irgendwie so ein Account und das ist so das Way-To-Go.
Aber natürlich haben wir halt drumherum immer noch einzelne Personen, die halt Dinge halt ausprobieren.
Und das ist eben Codex auf jeden Fall, dass einer auf jeden Fall schaut, was da passiert in dem Umfeld von OpenAI.
Gemini hat der Uni zum Beispiel mal sehr viel experimentiert.
Wie ist dann die Verbindung mit der Google Cloud?
Weil wir auch natürlich Cloud-Projekte machen.
Das heißt, das ist immer auch ein entscheidender Faktor für uns, wie funktioniert das in dem ganzen Ökosystem.
Ja, also im Grunde so quer durch.
Ich persönlich habe letztes Jahr, sage ich mal, als irgendwie ganz am Anfang des Jahres, Januar, so mit Lovable, so die ersten Coding-Themen hochkamen.
Da dachte ich, wow, das ist ja echt, da kann man die erste Kunden anfragen und dachte, ich probiere das mal, wie weit kommt man damit?
Das war jetzt so fast anderthalb Jahre her.
Und da war ich schon geflasht, wow, da funktioniert ja schon was.
Und dann ist das wieder ein bisschen abgeabbt und dann so mit Cloud Code Mitte des letzten Jahres, da hat es dann wieder eingepackt, wo man sagte, wow, jetzt können wir so richtig in so einen Engineering-Prozess reingehen.
Und tatsächlich hatte mich dann irgendwann im September, Oktober, wurde ich so ein bisschen auf den Blog von Peter Steinberger aufmerksam.
Und da dachte ich, wow, das sind coole...
coole Aspekte, die er macht und dann hat er auch so ein bisschen auch, ja, seinen Eindruck geschildert, dass er durchaus mit Codex, sage ich mal, sehr, sehr erfolgreich ist, auch wenn es langsamer geht, aber die Analysen sind besser.
Und deswegen persönlich habe ich jetzt immer, sage ich mal, am meisten Erfahrung tatsächlich auch so im Engineering Coding mit Codex gemacht.
Cloud Code immer mal wieder ausprobiert und geschaut, aber irgendwie hat das seit GPT 5.2 oder so.
das hat einfach so gut funktioniert.
Alles, was ich angepackt habe, dachte ich, ja, alle reden jetzt gerade so im Januar, Februar, Claude, hier und da.
Und ich dachte, okay, macht mal.
Da gibt es wieder irgendwie einen Monat frei.
Und die haben das ja richtig gepusht, so im März, als auch die App dann nochmal einen Aufwind bekommen hat.
Da dachte ich so, cool, einfach mal machen.
Und es hat immer funktioniert irgendwie.
Also ich war immer begeistert schon.
Ja, was man jetzt auch vielleicht raushört.
Deswegen.
Aber wir gucken immer links und rechts und haben halt auch für so erste Prototypings, da schmeiße ich auch mal was in Lovable und nehme einen Teil davon und schmeiße es dann in Codex oder ich schreibe eine Spec erst, rödel das nochmal durch Clote durch und dann, wenn ich zufrieden bin, haue ich das in Codex rein und er codet das.
Also ist durchaus so der Anfangrad für neue Ideen.
Probiere ich gerne immer vieles aus.
Und zuletzt Pi.
Pi-Coding-Agent, kommen wir vielleicht nochmal später, was so der Hotshit ist, aber bin ich auch begeistert.
Jetzt hast du sowas zählt.
Ja, bin ich auch ein Riesenfan von.
Was ihr vielleicht so ein bisschen wahrnimmt, es gibt hier schon so Lager, jeder hat so seine Vorlieben für eine bestimmte LLM oder für ein bestimmtes Onkelsystem und das hilft uns eigentlich an der Stelle auch nochmal so wirklich ein Geschmackle zu kriegen.
den Spieltrieb, den mögen wir.
Wir haben das ja nicht so häufig, dass wir Leute hier haben, die sagen, Codex, Superfan, funktioniert für mich viel besser als mit Claude Code.
Deswegen, wenn du beide Seiten gesehen hast, Andreas, ich muss sagen, mein Three Months bei Open Air ist gerade wieder ausgelaufen und ich habe es nicht genutzt, nachdem mir das jemand quasi rübergeworfen hat.
Aber wenn du beides schon mal so intensiver ausprobiert hast, Wie würdest du einen Unterschied beschreiben?
Ist das nur Taste?
Ist das Flavor?
Oder gibt es da irgendwie so richtig Sachen, die einem also quasi an der Stelle einem Cloud Code halt irgendwie fehlen?
Interessentistema.
Das erste Thema, was mich dann sofort da gepackt hat, ist, dass es gleich in der Codex-App einfach so einen Div-Editor gab.
Und es ist ja nicht so, dass ich jetzt Full-Time Software Engineering mache.
Das ist jetzt bei mir seit letztem Jahr einfach wieder hochgesprießt, sage ich mal.
Das Thema, dass E-Mails auch mehr wieder so um Coding-Themen einfach eintauchen, weil man damit schnell Produktideen einfach wieder ins Leben prompten kann sozusagen.
Dann dachte ich so Cloud Code, ja, aber es ist halt Terminal-basiert und für DIV, da musst du vielleicht wieder mit T-Mux irgendwas bauen, um die DIVs zu haben oder du musst das als Teil von Visual Code nutzen oder Cursor haben wir letztes Jahr auch hier und da auch eingesetzt und ausprobiert.
Aber das war zum Beispiel ein Grund, warum ich sage Codex, hey geil, das ist einfach eine App, ich habe ein Terminal, kann es aufklappen, ich habe diesen Chat-System, ich habe links den Durchlauf meiner Projekte.
kann hin und her springen und ich habe die Diff-Ansicht und ich kann einen Button drücken und der macht mir Commit-Message-Push.
Das war halt für mich so der Change, den es bei, sag ich mal, bei Cloud, sag ich mal, bei der App nicht gab.
Das kam erst jetzt später, wo sie auch Code integriert haben.
Aber auch da muss ich sagen, das ist so ein bisschen parallel.
Da gibt es wieder Code und es hat noch nicht so alle Features und Cowork parallel und Codex ist jetzt auch nochmal den Weg gegangen, dass sie da wirklich Also es ist quasi eine App, aber du kannst halt coden, du kannst jetzt Bilder generieren, du kannst alles machen.
Und das finde ich halt irgendwie, die haben das so ein bisschen alles zusammengemerged gerade.
Ich habe die Codex-App tatsächlich ganz am Anfang auch initial für so ein kleines Spielprojekt mal benutzt und bin da auch ganz gut vorangekommen.
Das war schon gut.
Ich habe da jetzt aber fairerweise, ich habe vorher viel mit Anti-Gravity gearbeitet und habe da ganz unterschiedliche Projekte beackert.
Deswegen habe ich da gar keinen großen Unterschied oder konnte ich nicht die Unterschiede so direkt festmachen, weil das Gesamtsetting ganz anders war.
Jetzt arbeite ich aber an unterschiedlichen Projekten mit Cloud Code und Codex tatsächlich.
Und den Pi-Agent habe ich mir da so gecustomized für ein großes Projekt, dass es sehr gut passt.
Und da würde ich schon sagen, dass das, was Peter Steinberger oder auch Markus Andrezak und so sagen, dass Cloud Code viel eher einfach losrennt und mal macht, während Codex tatsächlich erst mal sehr, sehr viel quasi liest, also wirklich Rack ganz grundsätzlich durchführt auf allen möglichen Dateien, sodass dann das Ergebnis viel mehr sich mehr grounded anfühlt, zumindest mit anderen Worten.
Der normale Workflow, den ich in meinem größeren Projekt so habe, der ist schon so, dass da in aller Regel die Ergebnisse sehr, sehr gut sind.
Das fühlt sich schon gut an.
Ich muss dazu aber auch sagen, ich habe neulich mal QEN 3.6 ausprobiert, quasi auf eine ähnliche Art und Weise.
Und es war schon auch ein sehr, sehr gutes Ergebnis.
Insofern wüsste ich jetzt nicht, ob das hundertprozentig nur an Codex liegt.
Genau, aber das auf jeden Fall beides viable, würde ich sagen, sowohl Codex als auch QEN 3.6.
Das ist das, was wir auch eigentlich so erleben.
Es kommt auf mehr an als nur die LLM.
Das ist das, was wir auch alle so erleben an der Stelle.
Und irgendwann hat jeder so sein Flavor, sage ich jetzt mal.
Aber für das, was du dann vielleicht als kleinen Task machst oder als kleine Sache, die du jetzt gerade durchbringst, ist das vielleicht nicht mehr ganz so entscheidend.
Das ist vielleicht so ein Fazit.
Kommen wir vielleicht später auch nochmal darauf.
Ja, ja, ich wollte gerade sagen, ich glaube, das passt super zu unserem Thema heute.
Also ich bin a, komplett bei euch, dass das gar nicht nur ums LLN geht, sondern vielmehr mittlerweile das Drumherum.
Deswegen, ich weiß gar nicht, vor wie vielen Monaten das war, aber das als zufällig, Cloud Code war das doch gewesen.
Also das quasi als Entropic da aus Versehen seine App.
Seinen Code veröffentlicht hat.
Ich glaube, das ist, tatsächlich hat man ja da viel mehr quasi gesehen, wie das halt alles funktioniert.
Ich glaube auch, das ist eigentlich der Rahmen drumherum mittlerweile das ist, was den Unterschied ausmacht.
Und ich glaube auch, es gibt vielleicht sogar einen Unterschied.
Und du hast recht, Sebastian, ich glaube, es war in der Folge mit Robert, der hatte das auch mal erwähnt, dass der Codex ein bisschen gründlicher ist und quasi Claude eher versucht, schnell Ergebnisse zu liefern.
Und ich könnte mir vorstellen, dass der Unterschied auch quasi mit Blick auf das, was wir gleich diskutieren wollen, also quasi Dark Factories, also ein bisschen mehr grounded, kann schon zu besseren Ergebnissen führen, weil du ja relativ einen langen Loop halt im Endeffekt hast.
Und je mehr der grounded ist, je besser vielleicht auch die Ergebnisse.
Also so zumindest mal die Hypothese.
Jetzt haben wir aber schon ein bisschen vorgespult.
Gibt es denn noch irgendwas?
Ja, genau.
Bevor wir weiterspringen, würde mich nochmal interessieren, ihr arbeitet ja an verschiedenen Projekten wahrscheinlich.
Also sprich, es wird bei euch weniger so sein, dass ihr langfristig an einem bestimmten Projekt arbeitet und da dann eben so ein Workflow honet sozusagen, sondern eher...
viele verschiedene Projekte.
Habt ihr da trotzdem so bestimmte Basis, irgendwie, keine Ahnung, eine Basis-Agent-MD, die immer reinkommt und Basis-Skills?
Oder ist es immer eigentlich clean slate und je nach Projekt baut sich das immer auf?
Oder nutzt ihr vielleicht Skills oder sowas auch gar nicht, weil ihr sagt, die LLMs sind so gut genug und es ist so individuell, dass es von Projekt zu Projekt gar nicht viel gibt, was sich lohnt, mit rüberzunehmen.
Vielleicht ich mache mal einen Aufschlag.
Also erstmal, wir haben natürlich Unterschiede.
Wir haben halt so Kundenprojekte, da ist so ein bisschen vorgegeben, was du da auch teilweise nutzen darfst.
Und wir haben ein paar Sachen auch vom Kollegen nochmal mitgenommen, der unterteilt das Ganze schön, sage ich mal, in so traditionelle, sage ich mal, im regulierten Umfeld, sage ich mal.
Und da ist zum Beispiel so IntelliJ und das, was IntelliJ dann zur Verfügung stellt und vielleicht auch teilweise ein Kunde.
erlaubt zu nutzen.
Also da ist zum Beispiel IntelliJ, dann gibt es moderne Projekte, wo wir sagen, okay, das kommt von uns heraus, da sind wir der Owner des Codes, das haben wir im Griff.
Da ist zum Beispiel, ich selber bin da jetzt nicht so hängen geblieben, aber Kollegen nutzen zum Beispiel Conductor, wo sie einfach dieses agentische und mehrere Agenten im Überblick haben.
Und dann gibt es natürlich nur so, Wir schauen, was gerade hip ist, was modern ist und da probiert man halt, keine Ahnung, die RALF-Loop aus und da probiert man halt irgendwelche anderen Agenten-Framework aus.
Also das erstmal so grundsätzlich, wie wir versuchen da irgendwie, natürlich von den Rahmenbedingungen her, schaut man, was nimmt man da gerade.
Also um das vielleicht nochmal so ein bisschen klarer zu machen, wir gucken hin, okay, drei Klassen kennen wir, reguliert, das ist das erste, was Andreas gesagt hat, das zweite modern.
Wir ownen selber, wir sind verantwortlich für die Qualität, wir gucken, was rauskommt und dann gibt es dieses All-in, Gebeam, Sandkasten, um zu experimentieren und in den beiden reguliert und, sag ich jetzt mal, modern, haben wir Selbstprodukte oder sind im Projekteinsatz beim Kunden.
Daher kommt diese Herleitung und danach versuchen wir eigentlich ein Setting zu bauen an der Stelle und das führt uns dann alles so, dieses, alles, was wir dazu gelernt haben, im Grunde zu unserem Thema, wir nennen das ja dann digitale Produktfactory, wo wir dann gelernt haben, okay, wie kriegen wir das denn eigentlich für unseren Modern Stack, also der, den ermittel ich, den wir selber own so hin, dass wir digitale Produkte sehr schnell bauen können und auch, kommen wir vielleicht gleich zu, dann selber nutzen und wie sich das ergibt.
Genau, also dass wir nicht immer von vorne anfangen, das heißt, da kommen wir gleich nochmal zu, wie unser Ansatz ist, das mal irgendwie zusammenzuhalten.
Und gleichzeitig merken wir auch, dass das halt bei Kunden auch passiert, dass das natürlich alles teilweise ein bisschen langsamer, aber dass man dort dann eben auch beim Kunden versucht, das natürlich aufzubauen mit etwas, sagen wir mal, unterschiedlichen Rahmenbedingungen.
Aber Ziel ist klar, irgendwo nicht immer bei Null anzufangen, sondern in Richtung so einer Fertigungsstraße zu kommen, in Richtung Standardisierung und ja.
Ja, da würde ich sagen, haben wir eine perfekte Überleitung.
Dann gehen wir doch direkt zum Hauptthema über.
Genau, zu eurer digitalen Produktfabrik auf Deutsch übersetzt.
Sorry, ich habe gerade mit dem Kopf, weil es da so Deutsch-Englisch drin stand.
Erzählt doch mal, wie ihr das aufgebaut habt.
Ich fange mal an an der Stelle.
Eure letzte Sendung da mit dem Dark Factory hat mich getriggert, weil ich glaube nicht an Dark Factory.
An der Stelle kommen wir vielleicht nachher nochmal dazu.
Aber warum haben wir uns mit dem Thema beschäftigt?
Ganz klarer Case.
Wir haben gesagt, wir bezahlen im Moment sehr viel Geld für eine SaaS-Lösung im Abo, im HR-Bereich, die ganz viele Funktionen hat, die wir in unserer Größe gar nicht brauchen, aber wir bezahlen Geld dafür.
Und wir brauchen vielleicht, ich sage jetzt mal fünf bis zehn Features daraus.
Wieso sollen wir dann die anderen 60 bezahlen?
So, und dann haben wir gesagt, okay, wir glauben jetzt im Grunde, das war ungefähr Dezember.
Wir glauben jetzt, wenn wir das angehen, dann können wir beweisen, ob es klappt oder nicht, für uns selber eine HR-Lösung zu bauen mit den Features, die wir brauchen.
Die Line war dann für unser Team intern zu sagen, wir müssen Ende März unser Abo kündigen.
Dann möchten wir eine produktive Sendung, einen produktiven Service haben, ein Produkt, mit dem unsere Funktion HR durch unsere Kraft im Hintergrund im Backoff ist.
ausgeführt wird und wir haben natürlich das System, sobald ich HR bin, Verschlüsselung etc., also real life an der Stelle und haben dann begonnen, im Grunde hier etwas aufzusetzen.
Dann würde ich mal an Andreas weitergeben.
Ja und los ging es halt natürlich, dass man gesagt hat, okay, jeder hat irgendwelche Tools ausprobiert, der eine hat noch eine Anti-Gravity-Lizenz und Zugriff auf bestimmte Modelle.
der andere Cursor und so weiter.
Und von der Produktentwicklung her haben wir Trello, sage ich mal so, als halt Kanban, Lightweight Kanban-Lösung, um dann entsprechend unsere nächsten Produktfeatures zu planen.
Und so hat, sage ich mal, die Kollegen bei uns, die, sage ich mal, im IER hauptsächlich aktiv ist, ist die Product-Ownerin und hat angefangen, Storys zu entwickeln.
So, und dann haben wir natürlich gesagt so, oh cool, jetzt wäre es ja cool, dass wir einfach die nächste Story, ne, Agenten anzapfen lassen, machen und so weiter und dann hat sich das so nach und nach, haben sich so Workflows etabliert, ne, und irgendwann habe ich gesagt, ah, das ist ja auch doof wieder, da haben wir jetzt irgendwie ein Skill im Code drin und dann haben wir Requirements im Trello drin und es ist irgendwie integriert, aber dann hatten wir angefangen so, dass auch so ein Requirement automatisch erstmal, quasi gecheckt wird, passt denn das, gibt es irgendwo Konflikte, hat das irgendwie schon das Feature, vielleicht ist das schon implementiert oder so, weil das nach und nach, gerade auch wenn man so schnell unterwegs ist, braucht man einfach so eine gute Analyse auch.
Und dann dachte ich, naja, okay, der erste Schritt war, der erste, sagen wir mal, Agent-Schritt analysiert.
kommentiert dann in der Trello-Karte.
Aber dann habe ich wieder irgendwie im Beschreibungstag, in den Akzeptanzkriterien habe ich Informationen, die müssen ja dann wieder aktualisiert werden mit diesem Review-Schritt und so weiter.
Und dann dachte ich, naja, eigentlich wäre es ja cool, dass man das irgendwie auch gleich einfach sagt, okay, da kommt ein Review und das überarbeitet man wieder und hat eine Single Source of Truth.
Und dann kam die Idee auf, hey, cool, lass uns mal probieren hier einfach mal so ein Kanban-Board, wo wir einfach ein eigenes Tool zu bauen.
Und dann war so der erste Schritt so, ja, okay, ich brauche ja nicht viel.
Erstmal eine User-Story erfassen.
Nächster Schritt ist Clarify.
Dann wird der Code ausgecheckt, geguckt, diese Anforderungen.
Also mir war es immer wichtig, auch am realen Objekt, weil es halt so schön agentisch funktioniert, auch mal zu checken, okay, passt das?
Was gibt es halt für Fragen?
So, und das ist im Grunde, ja, so der erste Agentenschritt.
Und es ist im Grunde mit so einem, ja, sehr simpel, mit einem Prompt definiert, was er eigentlich tun sollte.
Und dann kommen am Ende ein paar Rückfragen.
Product Owner hat die Möglichkeit, dann nochmal Details zu geben und dann wird nochmal mit diesen Antworten quasi diese Story nochmal neu geschrieben.
Und dann habe ich halt eine saubere, spezifizierte User Story und kann die nachher noch bearbeiten.
Aber das fand ich halt super, weil das so der erste Optimierungsschritt war, eine super saubere User Story zu haben.
Und dann, wenn das halt geklärt ist, dachte ich, naja, der nächste Schritt ist irgendwie in die Planung der Implementierung zu gehen.
Also einfach nur ein Button, Next Step, Planung irgendwie, Implementierungsplan erstellen.
Und dann nutzen wir im Hintergrund natürlich so die Skills, die da entstanden sind, wie wir vorgehen und die referenzierten Guides aus der AgentsMD für unsere Coding-Richtlinien, für das Database-Design und so weiter.
Und das fließt dann halt mit rein und dann haben wir gesagt, naja, cool, dann haben wir eigentlich schon den nächsten Implementierungstep.
Und so kam dann halt die Idee, naja, dass man eigentlich ja so weitermachen kann und so eine Pipeline nach und nach entstanden ist.
Das waren so die ersten Ideen, wie wir gesagt haben, okay, wir probieren mal, machen mal, wie kommen wir in so einen strukturierten, standardisierten Prozess.
Und ergänzen möchte ich dazu, was hat das jetzt mit Factory zu tun oder realen Welt?
Wir durften mal ein Projekt in der Automobilindustrie unterstützen.
Da gibt es sowas wie Manufacturing Engineering Systems.
Die steuern die Produktion, die geben so einen Blick auf die Produktion, was unterwegs ist, wie das Auto gebaut wird.
Und da war ich dann im Grunde beteiligt.
Und was man da erkennen kann, ist, dass diese Systeme natürlich so Ampeln und Qualitätsmerkmale auf einem Dashboard in dem Produktionsprozess haben.
Und da kam natürlich der Punkt zu sagen, naja, was haben wir im Moment?
Wir haben keine Transparenz über die Qualität.
Wir haben keine Transparenz, was der Agent jetzt irgendwo gemacht hat.
Wir haben keine Transparenz darüber, ist das Feature jetzt implementiert worden und wie sieht es aus?
Also war die Idee eigentlich genau über Kanban so einen Prozess abzubilden.
Jemals können Karten durch einen Agenten implementiert werden oder durch einen Menschen.
Aber es ist ein Prozess, der dann auch die Ergebnisse, also was hat der Agent programmiert, kann ich mir ein Diff angucken oder ich kann mir das Video angucken von dem Test, wie das Feature realisiert ist, weil das will der PO sehen.
Dafür muss er jetzt nicht erst wieder in ein anderes Tool.
Wir hatten Schwierigkeiten mit Trello die Anbindung etc.
zu machen und das war nicht beherrschbar.
Deswegen sind wir gesagt, okay, wir müssen eine eigene Umgebung schaffen, wo die Fachlichkeit, der Entwickler, die Qualitätsmerkmale, ich sage jetzt mal Code Quality, Security Test etc.
zusammenlaufen, wie in einem Produktions-Dashboard und ich sehen kann, okay, wo läuft das hin?
Um dann auch als Mensch oder wie auch immer als Lead-Entwickler darauf zu reagieren.
Und konzeptionell sind wir eigentlich so weit, dass wir sagen, naja, was mache ich denn mit meinen Junioren?
Und da sagen wir, naja, idealerweise ist es ja so, dass dann durch ein Algorithmus oder durch irgendetwas bestimmt wird, dass eine bestimmte Karte dann durch den Junior realisiert wird.
Wir müssen ja schaffen, dass das, was wir da bauen, vielleicht auch im Grunde noch verstehbar oder ich sage immer beherrschbar ist.
Und das ist das Konzept, wo ihr jetzt seht, das ist für mich überhaupt keine Dark Factory, sondern wir sehen das eigentlich, dass sich diese Rollen intensiv vielleicht in einem Werkzeug, wie in so einer Monitoring, in einer Fertigungsstraße zusammenfährt.
Und dann haben wir gesagt, okay, wenn wir jetzt das nächste Produkt machen wollen, dann brauchen wir natürlich so eine Umgebung, wo ich sagen kann, ich brauche die und die MD-Files, die und die Skills, ich möchte gerne das Template haben, gerne rot-weiß oder blau-weiß und er stellt schon die Umgebung zur Verfügung.
Und der nächste Schritt ist dann zu sagen, okay, jetzt kann ich direkt mit dem, was Andreas gestartet hat, schon spezifizieren und der Prozess bringt los.
Das heißt, ich schaffe ein unglaublich schnelles Boarding, der Fachlichkeit und dann auch der Entwickler.
Weil, unter uns gesprochen, wir brauchen sie.
Ich bin immer bei diesem Thema der Beherrschbarkeit, was da erzeugt wird.
Und das ist das, André, das Hauptpunkt, wo ich sage, glaube ich nicht so ganz an die Dark Factory.
Wir machen ja jetzt kein Massenprodukt.
Sondern, hattet ihr auch an der Weh, sondern wir machen ja eigentlich, dass wir ein spezifisches, ich will jetzt die Brücke schlagen, spezifisches Auto bauen, was wir aus bestimmten...
Dingen auswählen und nachher möchte ich, dass genau dieses Auto in grün-blau mit, was weiß ich, Hirschgeweih oder Sonstiges rauskommt.
Und irgendeiner muss das sagen, das Zusammenspiel, wie dann das Hirschgeweih angeschraubt ist, das muss ja einer irgendwie wollen, sage ich jetzt mal.
So, das ist das Konzept oder die Idee dabei.
Und das ist eine Ingenieursleistung.
Und wir nennen das auch im Moment, wir nennen das Shift Left Left.
Wir gehen immer weiter rüber.
Und dann ist die wichtige organisatorische Frage, wie kriege ich die alle an einen Tisch, dass sie noch mindestens auf einer bestimmten Flughöhe die richtige Sprache miteinander haben.
Heute haben wir das ja sehr auseinander.
Und das muss sich hier angleichen.
Und das war die Idee.
Und Andreas, ich glaube, wir setzen uns ein.
Es läuft.
Ich habe es heute tatsächlich probiert.
Wir hatten jetzt zum Beispiel, gestern hat man ein Meeting und da war das Gespräch so.
Wie ist denn das Durchschnittsalter jetzt von den Mitarbeitern bei uns?
So, und ich habe jetzt unser neues Tool ausgerufen, da habe ich gesagt, ah, die KPI war standardmäßig noch nicht drin.
Da gibt es natürlich wie viele Mitarbeiter, wie ist es aktiv, in Teilzeit und so.
Also ein paar Metriken sind da drin.
Ja, Durchschnittsalter haben wir nicht, aber prinzipiell sind die Daten da.
Und jetzt habe ich heute noch vor dem Meeting da, ich schmeiße das mal an, mache jetzt ein Ticket, habe jetzt einfach diesen Clarify-Prozess durchgespielt, Next Step.
Und das Feature, ich glaube, das hatte ich irgendwo, Cursor hat es, glaube ich, auch mal implementiert oder so, aber ich wollte halt ein Video von diesem Happy Pass dann, dass man sagt, okay, er hat jetzt halt in unserem Reportings irgendwie Ansicht, hat er dann eine neue Kachel mit dem Durchschnittsalter.
Und das fand ich halt krass jetzt gerade, dass das funktioniert.
Obwohl ich jetzt einmal so...
Ich bin halt nicht regelmäßig dran.
Das ist noch im Entstehen.
Also muss man auch dazu sagen, wir lernen auf dem Weg.
Aber die Erfahrung ist auch, beim Touren und so kommen uns neue Ideen, da adaptieren wir.
Und so richtig muss man natürlich noch gucken, wie viel wird man dann noch eingreifen, wohin.
geht die Reise am Ende klar, glauben wir schon, natürlich diesen Input zu geben, was soll denn jetzt gebaut werden?
Ich meine, das ist so dieses, das nach links verschieben, das heißt, ich muss eigentlich dann eigentlich relativ gut spezifizieren können, was soll denn die Software dann als nächstes machen, was sind die nächsten Features, was muss vielleicht abgebaut werden und da machen wir jetzt unsere, sag mal, guten Fortschritte und am Ende läuft natürlich wieder auch nochmal ein unabhängiges Code-Review, Sonar-Metriken, also alles, was Uli so angerissen hat, Schwachstellen-Scans, dass man da auch schnell eine Visibility hat und auch nicht in zig Tools wieder springen muss, sondern dass man irgendwie Qualitätstab aufruft und sieht, okay, alles klar, nach diesem Feature sind so und so viele Tests dazugekommen, die laufen alle grün, wenn nicht, dann läuft da halt sowieso nochmal eine Schleife.
aber dass man im Grunde so eine Control Plane hat und sieht, was passiert, wie viele Agents sind da, wobei ich auch da noch nicht so unterwegs bin, dass man sagt, da laufen jetzt ganz viele Agents und ganz viel parallel, sondern halt eher, naja, es muss halt irgendwie kontrollierbar sein.
Und ich denke, die Geschwindigkeit des Codes, sie ist ja so schnell.
Also ich brauche gar nicht so viel.
Ich habe immer jetzt die Diskussion, ich verstehe, ja, ich brauche so viele Agents, die muss ich kontrollieren.
Also mir geht es darum, dass die Features, die ich habe, dass die kontrolliert, genau das halt am Ende, jetzt in dieser Pipeline ein bisschen die Produktion durchrutscht.
Und da bin ich schon heftig, wenn ich sage, okay, ich habe morgens eine Idee oder mir fällt was auf in dem Meeting, da fehlt noch was.
Ich haue das hier schnell rein, muss nichts auschecken, die Pipeline läuft durch.
Wenn irgendwo was hakt, haben wir so einen Filter, Needs Engineer oder so.
Und der letzte Feature, was wir da reingebaut haben, ist, dass man, mich hat es immer genervt, dass man irgendwie sagt, okay, ich muss jetzt nochmal als Entwickler irgendwo Code auschecken und gucken, in welchem Branch und, und, und.
Also all das, womit man sich immer, sage ich mal, bei so Complex-Switches gerade mental ja immer erstmal so reinfinden muss.
Und da haben wir jetzt gesagt natürlich, okay, ich will einfach einen Button hier, ich klicke drauf und dann im Hintergrund läuft Open Code.
Und ich springe direkt in einem separaten Tab in die Open-Code-Umgebung, in genau dieses Feature, in den ausgecheckten Branch mit dem aktuellen Codestand und kann dann quasi in der Web-Oberfläche in Open-Code weitermachen oder gucken, weil da habe ich natürlich als Engineer nochmal mehr Möglichkeiten.
Das ist so ein bisschen das, wo wir sagen, da kann ich es trotzdem nochmal verzahnen und kontrolliert als Engineer auch steuern.
Und da haben wir zum Beispiel Open-Code dann auch, sage ich mal, mit reingepflanscht.
weil es halt super diese Web-UI einfach gibt, Open-Source sowieso gut und irgendwie integrierbar, auch wenn da noch ein kleines Feature fehlt, um das noch super zu integrieren, aber da will ich jetzt nicht zu tief eintauchen, aber diese Idee, ich bin im Kontext einer User-Story, eines Features, was implementiert wird, es hakt irgendwo und dann kann ich sagen, okay, ich brauche jetzt hier einen Software-Entwickler, der drückt auf einen Button und der ist sofort in dem Kontext drin.
Der muss nicht, oft ist es so, ja, da hakt irgendwas und die, der PO sagt, ja, könnt ihr da nochmal was, da läuft irgendwas nicht.
Und allein dieses schnell mal da rein irgendwie und in den Kontext zu finden, das nehmen wir wahr, das kostet einfach viel Zeit, wenn man jetzt nicht, also bei uns, weil das halt mehr so als Zeitprojekt irgendwie läuft.
Und ich glaube, das merken wir ja auch, dass man...
plötzlich anfängt, parallel irgendwie Projekte zu managen und zu machen, weil es eben so schnell geht.
Und das fand ich normal so für mich erhellend.
Ja, cool.
Ich klicke drauf, bin im Kontext und kann dann, wenn ich muss oder wenn ich will, habe ich auch plötzlich die Coding-Umgebung.
Also ich habe eine ganze Reihe Fragen.
Zum Ersten, das heißt also, ihr habt ein Kanban-Board.
Das Kanban-Board ist mehr oder weniger das Interface zum Menschen, also zwischen Mensch und Agent, wenn man so will.
Und ihr habt quasi den Entwicklungsprozess in Spalten auf diesem Kanban-Board abgebildet.
Wie viele Spalten gibt es und welche?
Aktuell gibt es, ich springe da direkt mal rein, es gibt auf jeden Fall einen Backlog.
Da werden erste Ideen gesammelt.
Und wenn ich eine Karte in Backlog öffne, da gibt es einen Button und der, also klar, ich habe schon mal die ersten Informationen erfasst, aber der nächste Schritt ist eigentlich Work und dann steht, was der macht, wenn ich auf diesen Button Work klicke, dann steht, okay, der nächste Schritt ist Clarify und diese Anforderung wird nochmal geprüft und dann kriege ich eben Rückfragen, beantworte das als Product Owner.
Oder wie auch immer, als jemand, der dieses Feature neu baut.
Und dann wandert das Ganze quasi, wenn diese Spezifikation validiert ist, sauber ist, dann wandert die nächste Lane, die heißt dann ready.
Das heißt, da wird automatisch spezifiziert.
Also da ist dann die Spec fertig sozusagen.
Und dann müsste der Implementation Plan kommen sozusagen.
Genau.
Genau.
Also wir haben es nicht komplett automatisiert, weil ich sagte, okay, da ist es nochmal so, dieses Spec ist einfach aktualisiert mit dem ersten Schritt und da kann ich als Product Owner, wie auch immer nochmal schauen, wir haben das so ein bisschen strukturiert nach Edge Cases, die man dann halt nutzen kann für entsprechende Tests, Entwicklung dann, sage ich mal, im Implementierungs-Step und ein Bereich so ein bisschen explizit so.
Expected Outcome, so, da habe ich jetzt zum Beispiel bei dem Durchschnittsalter steht dann jetzt, die Kachel zeigt das korrekte Durchschnittsalter, durch den Filter, ausgewählte Mitarbeiter und mit einer Nachkommastelle.
Das sind zum Beispiel alles Informationen, die so durch die Rückfrage dann gekommen sind.
Weil ich erstmal sage, ich will dann eine Kachel und rückfragen kann, ja, möchtest du denn auch eine Nachkommastelle, wie viel?
Möchtest du die aktiven Mitarbeiter, möchtest du alle und so weiter?
Und da habe ich geantwortet, naja, wir haben ja oben Filter, dann soll das berücksichtigt werden.
Also das fand ich schon cool.
Einfach mal eine Idee reinwerfen und dann kriegst du halt irgendwie einen Haufen Fragen, beantwortest die, teilweise auch Dinge, auf die man erst mal gar nicht dran gedacht hat, dass es wichtig ist.
Und in der Spec ist das dann halt strukturiert und diese Spec, diese Struktur.
ermöglicht das dann halt, die Implementierungsplan auch nochmal wieder strukturierter anzugehen, dass man auch weiß, okay, für die Edge-Cases haben wir dann auch wirklich Tests und keine Ahnung, so und so viel.
Kann ich auch später nach der Implementierung auch nochmal, ja, einfach sicher sein oder nochmal gegenchecken, hey, diese Edge-Cases sind auch wirklich abgetestet.
Ja, also das ist der nächste Step sozusagen dann in Ready.
Ich kann das nochmal checken sozusagen, diese Struktur der Speck.
Und dann geht es eigentlich so in die Implementierungsphase.
So, und da würde dann, und was ist dahinter eigentlich?
Also was nutzt ihr für ein Harness?
Nutzt ihr da auch jeweils OpenCode oder ist, genau, was sozusagen triggert den Agenten?
Das läuft jetzt, weil ich wollte das insoliert haben im ersten Schritt.
Und das läuft jetzt erstmal in einem Container.
Weil ich, also angefangen hatte, dass Anfang des Jahres sozusagen die Idee, die parallel zu unserem Produkt der HR-Lösung entstanden ist, habe ich direkt einfach Codex installiert halt in den Container.
Und da wird jetzt halt Codex, sag ich mal, im nicht-interaktiven Mode mit Dangerous Full Access oder wie das heißt, im Container angestartet.
Codecs.
Nachher habe ich gesagt, wollte ich dieses Feature, das man in Web-UI hat, also einfach in den Container in das Image da nochmal Open-Code reingeknallt.
Im Grunde läuft da beides und die Idee ist natürlich, dass man da auch jetzt noch Pi installiert und so weiter und vielleicht dann auch mal selber quasi in der Konfiguration auch ein bisschen steuern kann und sagen, okay, für diesen Schritt nehme ich dies und vielleicht ein anderes Modell.
Das sind so weitere Ideen, die wir haben, um das Produkt halt weiter auszubauen für uns.
Also diese digitale Softwarefabrik.
Das heißt also, da ist eine Webapplikation und die löst halt bestimmte Events aus, wenn eben eine Karte erstellt wird oder eine Interaktion auf einer Karte passiert und dann wird sozusagen Codex getriggert, auf dieser Karte zu arbeiten.
Also erst der Plan wird erstellt, also sprich die Spec, dann die Implementierung.
Und wie geht es dann weiter nach der Implementierung?
Gibt es da noch einen Review-Punkt durch den Menschen?
Genau, da gibt es Doing.
Also ich kann ja theoretisch, wenn ich jetzt im Backlog mehrere Karten hatte und so, könnte ich ja parallel mehrere Dinge starten.
Die laufen dann in separaten Containern, in Doing.
Und dann ist die nächste Spalte Review.
Und im Review habe ich die Möglichkeit, also was da passiert.
Wir nutzen bei uns jetzt intern für die Endbit-Projekte mal GitLab als unser Source-Code-Repository.
Da wird jetzt ein Merge-Request automatisch erzeugt.
Also wir haben da halt in diese, sag ich mal, Container-Umgebung ist auch ein GitLab-CLI mit drin, sodass man auch sehr, sehr gut halt mit GitLab interagieren kann.
Merge-Request wird automatisch aufgemacht.
Dann läuft dort entsprechend auch so ein Zeitprodukt, was entstanden ist, so ein agentenbasiertes Code Review, was dann halt auch in der GitLab Pipeline drin ist, also dass man es auch natürlich unabhängig machen kann.
Also ich muss jetzt diese Softwarefabrik nicht nutzen.
Ich kann natürlich auch, wie auch immer, halt mit der IDE, das wir mitglasig unterwegs sind, halt einfach coden.
Das heißt, wir haben dann nochmal so ein Code Review in dem Pipeline-Schritt in der GitLab CI und Ja, im Grunde, das ist jetzt noch nicht so zurück in dieses, da stehen wir gerade noch so, nicht zurück jetzt drin, sage ich mal, das Feedback direkt in die Karte, aber das ist so die Idee.
Das heißt, so eine Kanban-Karte hat aktuell...
Spezifikationen, sozusagen der erste Blick ist sozusagen aus fachlicher Sicht, kann ich nochmal drüber gucken, dann habe ich so einen Agent-Unterreiter in dieser Kanban-Karte, da sehe ich so Live-Logs vom Agent, kann nochmal gucken, was hat er denn eigentlich so produziert und dann dachte ich, okay, weil das halt eben, ich muss dazu sagen, weil das halt durchs Coding so einfach ist, habe ich gesagt, ich brauche noch einen Div-Tab, dann habe ich schon mal auch direkt in dieser Kanban-Karte als Techie, sage ich mal, kann mir auch schnell mal so Diffs angucken.
Der hat einfach ein Git-Diff gemacht, sage ich mal, und rot und grün markiert, so wenn man das halt low-level kennt, wenn man mit Gits auf Terminal-Ebene arbeitet.
Aber theoretisch kann ich mir das auch direkt dort anschauen.
Wenn mir das schon reicht, kann ich auch sagen, okay, das looks good oder so, wenn die Feature klein sind.
Aber kann natürlich auch wieder in GitLab nochmal als Engineer drauf gucken.
Ich kann dann natürlich nochmal ein anderes Tooling oder Möglichkeiten nutzen, um da weiterzukommen und da gibt es nochmal so ein Timeline, wann ist welches Event passiert, dass wir das so ein bisschen tracken, um theoretisch auch nochmal so Auswertung zu machen, wie lange hat so ein Feature gedauert, wie lange von der ersten Idee bis irgendwie in Produktion.
Das ist auch so ein bisschen die weitere Idee.
dass man dadurch wirklich zum Produkt auch so einen Stand hat.
Welche Features sind durchgegangen?
Was haben wir schon im Port?
Bis hin vielleicht dann auch so Links zu Logs haben wir schon mal so eingebaut, zu Staging, die Links und zum Monitoring, dass ich wirklich so ein Cockpit habe und nicht lange suchen muss, wo ist denn das, sondern schnell die wichtigsten Links und Metriken dann drin habe.
Aber das ist so dieser Review-Prozess.
Und dann, wie gesagt, ist das noch ein Branch und der nächste Schritt ist, danke, super Arbeit, klick drauf und dann wird automatisch auch aus dieser Oberfläche dann würde, ja, dieser Merge-Request halt gemerged und dann passieren halt natürlich in der GitLab CI, das ist halt einmal definiert, unser Prozess, wie der dann halt weitergeht und wenn die Tests alle safe durch sind und so, geht es halt ins Deployment.
Macht der Totalsinn da.
die CI, die CD-Ply-Ply nachzunutzen an der Stelle.
Aber Sebastian, du wolltest da noch.
Das ist jetzt quasi entstanden, als er dieses Personal-Tool nachgebaut hat, dessen Namen wir hier natürlich nicht nennen, von einem deutschen Hersteller.
Habt ihr es geschafft, im März das Abo zu kündigen?
Ja, wir haben es gekündigt, aber es lief dann noch jetzt, wir hatten es nochmal zwei Monate, glaube ich, Backup, aber es ist jetzt zu Ende.
Aber gekündigt wurde es und dann hatten wir das nochmal als Backup zwei Monate.
Leider sind die Kündigungsfristen dann mit irgendwas noch verknüpft, was wir dann erst noch festgestellt haben.
Aber da müssen wir ja nicht reingehen an der Stelle.
Aber uns war wichtig, E-T-O und Dogfood und jemanden, der fachlich Druck macht, um dieses Gefühl rauszubekommen.
Diese Kommunikation, dieses neue Miteinander.
Und weil wir am Anfang einfach die Transparenz verloren haben, habt ihr jetzt vielleicht diese Geschichte gehört.
Jeder macht für sich so ein bisschen Sachen.
Dann haben wir schon eine CI-CD-Pipeline, wir haben das alles schon stehen gehabt.
Und dann fehlte irgend so ein Missing Piece.
Wie kriegen wir denn jetzt diese Kontexte zusammen?
ohne jetzt, ich sage jetzt mal, den PO zu erklären, muss da und da und da und da noch was machen, damit er mitspielen kann.
Das ist so ein bisschen der Punkt.
Oder wir haben eine neue studentische Hilfskraft hinzubekommen und sagen, okay, wie kann der denn jetzt am schnellsten mit einsteigen?
ohne jetzt alles mögliche, auch CI, CD und sonstige, all die anderen Dinge, die wir alle eigentlich schon haben, die aus der Vergangenheit auch gut funktionieren, jetzt wieder irgendwie müssen wir das alles beibringen bis ins Letzte jetzt sofort oder an welcher Stelle kann er eigentlich schon anfangen, Features mit zu reviewen, zu lernen und solche Dinge zu tun?
Also ich denke, das muss man mit bedenken.
Ich glaube, ihr habt da was gebaut, was wahrscheinlich viele Unternehmen quasi sich in den nächsten Monaten bauen werden.
Wenn ich da ganz ehrlich bin, also quasi meine hauptberufliche Journey da so mal mit abgleiche.
Weil ich glaube auch, dass dieser Schritt quasi Level 5, im Endeffekt ist Dan Shapiro, der hat sich das ausgedacht.
Das ist ja jetzt nur nicht, dass das in Stein gemeißelt ist.
Das ist ja jetzt nicht wie das Periodensystem, wo man sagen würde, okay, das ist schwerer anzufechten.
Und insofern, das ist ja bloß eine mögliche Definition.
Aber ich finde das eigentlich eine tolle Success-Story und halt vor allen Dingen eine, die sich weiterspinnen lässt hin zu einer Dark Factory, ob man das halt jetzt will oder nicht.
Weil im Endeffekt habt ihr eine Factory gebaut.
Das ist, glaube ich, ein Riesen-Asset.
Das ist das, was Unternehmen halt alle bauen werden oder versuchen zu kaufen, weil quasi genau das, was du beschrieben hast, Andreas, quasi diese...
kleinen quasi Konnektoren dazwischen.
Das ist halt irgendwie, was muss ich halt irgendwie tun, damit die Person dann noch befähigt wird.
Und das ist alles nicht viel, aber das existiert als Produkt meiner Meinung nach eben noch zumindest nicht in den gängigen Lösungen.
Und gleichzeitig habt ihr eine Lösung, wo man halt Stück für Stück das Licht halt ausknipsen kann.
Ihr habt ja gerade auch selbst gesagt, es ist schon left-left.
Man kann ja noch weiter nach links gehen.
dann halt irgendwie sagen, mach doch mal einen Vorschlag für ein Feature.
Und dann kannst du auch die Prozessschritte halt einfach ohne Review, wenn man sich halt sicher fühlt, irgendwann halt einfach durchlaufen lassen, weil die Systeme halt immer stärker ausgehärtet werden und man mehr Vertrauen da drin hat.
Also ich finde, für mich ist das gar nicht irgendwie, ob Dark Factory oder nicht, sondern ich glaube, ihr habt euch da eine gute Runway quasi gebaut, um da vielleicht mal hinzukommen.
egal ob man das erreicht oder nicht.
Siehst du, ich wollte jetzt fragen, wann sie es Open-Sourcen, aber das hast du jetzt ein bisschen kaputt gemacht, indem du das als krasses Asset herausgestellt hast.
Genau, dann wann Open-Sourcest das?
Ja, da überlegen wir noch dran, aber wie gesagt, es ist tatsächlich viel so nebenher jetzt entstanden, tatsächlich primär durch mich aktuell.
Wir müssen das intern nochmal erstmal aufarbeiten, dass da nochmal ein Profi drüber guckt, der von Code ein bisschen mehr versteht, sage ich mal, weil das tatsächlich mehr so parallel eben zu der Entwicklung und ich habe eigentlich die Sachen, die jetzt entstanden sind von einzelnen Entwicklern bei uns, versucht da eben zu nehmen und halt für mich halt so einen Rahmen erstmal zu bauen und das funktioniert tatsächlich.
das ist so on the way eigentlich entstanden.
Und da ist auch eine Datenbank dahinter, wo gewisse Dinge halt eben gepflegt werden.
Und ja, da muss ich noch gucken.
Es wäre halt wahrscheinlich einfacher, wenn das noch ein bisschen irgendwie, keine Ahnung, Markdown-only konfigurierbar ist oder so.
Aber aktuell ist halt eine Datenbank dahinter einfach, damit man Dinge dort auch ganz easy ablegen kann und den State.
Und ja.
Aber ich denke natürlich schon, okay, kann man es vielleicht vereinfachen noch.
Die Erfahrung ist auch, das ist halt mit jedem Feature, was man halt dazu flanscht, wird es halt komplexer auch.
Und am Anfang war es noch easy irgendwie, morgens noch irgendwie ein paar Prompts rein und dann läuft das schon oder vor dem Meeting noch oder in der Pause.
Da war man so im Fluss.
Und jetzt hat das halt so eine Komplexität.
Das ist auch ein Learning, Komplexität erhalten.
wo man jetzt genau überlegen muss, wie mache ich denn jetzt dieses Feature und passt das noch zusammen?
Und weil da jetzt schon auch viel Code entstanden ist, mehrere Datenbanktabellen, Datenbankmodell und wenn man jetzt kleine Änderungen macht, dann will ich auch nichts kaputt machen.
Da schließen sich auch noch zwei Folgefragen an, die ich habe und zwar das eine.
mit wie vielen Personen arbeitet ihr denn mit diesem Tool?
Ich habe jetzt gehört, irgendwie Product-Ownerin, dann Werkstudenten, dann du, Andreas.
Wie viele Personen arbeiten denn mit diesem Kanban-Board?
Aktuell würde ich sagen zwei, drei.
Also wie gesagt, das ist MVP und ist in einer Entstehungsphase.
Und nur für das eine Projekt oder auch Multiprojekt?
Weil vorhin habe ich irgendwas von Templates gehört, das klang so als...
Würdet ihr das auch quasi bald schon für Kunden ausrollen, dass ihr dann mit Kunden da interagieren könnt?
Ist die Idee dahinter, aber um nochmal kurz einzugreifen.
Ich glaube, wir haben noch nicht unseren Qualitätsanspruch, das an Open Source zu machen oder damit weiter rauszugehen.
Ich glaube, ich bin auf eure Sendung da ja getriggert worden, zu sagen, es geht im Wesentlichen um dieses Konzept, um dieses Learning und das ist das, was wir auch mitgeben wollen, auch das, was Andreas gesagt hat.
Diese Reise, wir probieren die einzelnen Entwickler, wir verlieren die Transparenz, wir müssen diesen Left-Left-Shift irgendwie hinbekommen und das ist, glaube ich, der Kern und dann kann es genau, wie André sagt noch, wer weiß, wohin geht.
Sei es bis zur Dark Factory oder nicht, aber dieser Punkt, dass sich in diese Richtung sich die Reise entwickelt.
Sei es, dass sich eine IT-Abteilung das selber baut, weil sie Tools haben, weil sie so eine CIs, die Pipeline haben, die sie integrieren wollen oder keine Ahnung von wem was kaufen.
Da sind wir, glaube ich, ziemlich davon überzeugt, dass das passieren wird.
Ansonsten würde ich sagen, es ist Andreas ein bisschen zurückhaltend mit seiner Qualität.
Punkt.
Nutzt ihr denn das System selber, um das System zu entwickeln?
In den ersten...
Tests, sage ich mal, habe ich das gemacht.
Aber das ist halt mit, wie gesagt, mit zunehmender Komplexität ist das halt, ja, war das halt nicht mehr, also ich habe es halt gemacht, weil man natürlich auch ein Testprojekt, gerade in der Weiterentwicklung dieser Factory, brauchst du ja irgendwie auch erstmal ein Spielprojekt.
Und das heißt, ja.
Die Factory könnte das Spielprojekt werden.
Genau, also das ist auch tatsächlich drin, die Factory selbst und ja, ist tatsächlich, also die Argentic Product Factory, soll ich es genannt halt, die ist auch Teil dieses Spiels als Projekt und ich kann auch ein neues Projekt anlegen, Git-Repo hinterlegen und dann legt der los und legt schon mal die, aus den Settings, die vorgegebenen Guidelines für Architektur, Coding-Richtlinien und so weiter.
Ich plane auch noch ein Video zu machen und dann vielleicht auch mal bei LinkedIn zu veröffentlichen.
Genau, aber ja, wir warten noch, bis ein bisschen mehr Zeit da ist und dann die Reife noch ein bisschen höher ist, dann wird das sicherlich auch publiziert.
Ja, auf der anderen Seite ist so ein bisschen halt die Frage, reicht vielleicht auch nur der Prompt dafür oder die Specs, sage ich mal.
damit jeder halt irgendwie eine Basis hat und damit loslegen kann.
Das ist auch so ein Learning oder so ein Vorgehen, was ich oft mache, dass ich sage, okay, man sieht etwas, macht ein paar Screenshots, gibt ein paar Inputs, dann generiert man sich erstmal eine Speck, geht dann selber nochmal durch und das ist oft schon ein super Starting Point.
Und ob es dann irgendwie ein, zwei Software-Factories werden oder ob es ganz viele Individuelle geben wird.
Ja, also ich könnte mir vorstellen, dass es durchaus viele individuelle Software-Factories geben könnte.
Ja, vielen Dank.
Total spannend.
Also wirklich eine schöne Geschichte, wie ihr das Problem mit der Kollaboration im Team mit den neuen Möglichkeiten für euch so angeht und auch denkt.
Total spannend.
Genau, so langsam, glaube ich, können wir dann auf die Zielgerade einbiegen.
Wir versuchen ja immer so ungefähr bei einer Stunde zu bleiben.
Und wir haben noch zwei kleine Segmente am Ende.
Und zwar das erste Segment der Reality Check.
Gibt es bei euch auch immer mal wieder What-the-fuck-Momente?
Habt ihr da lustige Beispiele für unsere Zuhörer?
Oder aber auch Sachen, wo ihr sagt, das ist der absolut heißeste Scheiß.
Ich greife mal zum heißen Scheiß.
Also dieses Thema mit dem Software Development Lifecycle, insbesondere Thema Security und Qualität.
Das ist etwas, was uns sehr umtreibt an der Stelle.
Und da möchten wir gerne eigentlich das, was wir auch gesagt haben, als Konzept nochmal weiter nach vorne treiben.
Und wenn man jetzt schaut, was gerade so passiert, habe ich den Eindruck, wenn wir jetzt in Richtung Entropic gucken und auch gerade in den letzten Tagen, was da passiert.
Da kommt jetzt so ein Plugin raus.
was im Grunde hier eine Security-Unterstützung gibt.
Und da habe ich auch so, what the fuck ist Moment drin.
Mit Entropic habe ich eine Smartphone-App gecodet etc.
Natürlich achten wir darauf, dass der Artikee nicht ins Repository kommt.
Alles drum herum getan.
Ich habe es nicht gesehen.
Der Agent hat es trotzdem getan.
Ich habe einen anderen Agenten gehabt, der das festgestellt hat, dass ich das gemacht habe.
Aber das ist ja auch schon zu spät, wenn ich losschicke.
Das heißt, ich muss eigentlich da, wo ich lokal unterwegs bin, muss eigentlich schon eine Security greifen, damit es gar nicht in einem Repository oder was auch immer passiert.
Und das finde ich im Moment einen absolut spannenden Punkt.
Welche Security, welche Guards neben der eigentlichen, neben dem eigentlichen Agenten, unabhängig von ihm, können wir in die Systeme bringen, um eine Glaubwürdigkeit herzustellen.
Dem Hersteller glaube ich, dass er gut arbeitet, aber es wäre cool, wenn ich noch was Weiteres habe, was unabhängig vom Hersteller ist, der ihn noch auf die Finger guckt.
Das finde ich im Moment ein ziemlich interessanter Punkt, weil das muss man eigentlich haben, sonst verlässt man sich an der Stelle nur auf eins und ich glaube, dass es nicht ausweichend.
Ja, ansonsten, what the fuck, Moment, habe ich jetzt nicht so viele im Sinn.
Also zuletzt, was mich echt überrascht hat, wo ich dachte, okay, da kam halt als ...
als Response für einen Tool Call plötzlich eine .exe.
Also es war eigentlich eine YAML-Datei und die hat hintendran noch einen .exe gehabt.
Das heißt, da war ich echt überrascht.
So dachte ich, es hat jetzt keinen Schaden ausgelöst, weil auf Mac und so.
Aber dass da jetzt ein LLM dann plötzlich sagt, obwohl ich echt dachte so, hey, wir sind jetzt echt super zuverlässig mittlerweile irgendwie oder ja, auf jeden Fall besser.
Aber es kommt manchmal was zurück, was dann irgendwie eine Exe ausführen will.
Das hat mich wieder irgendwie so ein bisschen geerdet, wo ich dachte, oh, da müssen wir echt auf das Thema Security, Sandbox, da müssen wir echt drauf achten, weil das sieht man jetzt auch immer häufiger, dass sich so Dinge reinschleichen und das ist so subtil.
Und das war für mich nochmal so ein Alarm.
Hey, da müssen wir echt drauf achten, dass das wirklich in der Sandbox läuft.
Also Sandboxen bin ich auch, ich glaube, das ist unterschätzt, das Thema.
Weil man halt einfach, also man denkt so, man kann ja jedes Kommando vorher im Zweifelsfall abnicken.
Aber eigentlich ist das zwischen den Zeilen, ist das YOLO-Mode.
In deinem, also quasi auf deinem System, wo halt auch im Zweifelsfall sensible Daten oder Zugänge halt irgendwie liegen.
Ich finde es auch krass, auch wenn man mal so ein bisschen schaut, den Lösungswege, die Lösungsweg oder den Lösungsweg, den LLM halt irgendwie wert ist, auch mitunter wild.
Also welche Tools da irgendwie für was halt irgendwie angezapft werden, würde es ja selbst gar nicht so tun.
Und man sitzt halt einfach dann so dabei und ertappt sich dann, ich kenne das ja selbst, so in den Side-Projects, klick, klick, klick, klick, klick, also idealerweise so die Tastatur mit quasi zwei oder drei Tasten bloß noch, weil man gar nicht, also man versteht es im Zweifelsfall gar nicht oder die Ausmaße dahinter nicht.
Ich habe heute eine nette Story irgendwie gehört, wo, was war das gewesen, eine Java-Bibliothek, die halt in einem Standard-Output quasi gesagt hat, bitte löscht dich und alle, bitte löscht mich, also quasi die Bibliothek und alle Tests, aber quasi nur, wenn das halt quasi ...
interaktiv oder nicht interaktiv war und das war halt durch zwei, Sebastian hat es auch gelesen, hat schon genickt, müssen den Post halt unbedingt hier reinpacken.
Also da gibt es solche Angriffsszenarien, die können wir uns gar nicht vorstellen.
Und wir führen das halt ab.
Genau, so dumm kann man gar nicht denken, dass der Maintainer das selbst eingebaut hat.
Und am Ende in einem interaktiven Terminal hat er am Ende einfach einen ist an die Zeile zurückgesprungen sozusagen und hat die gesamte Zeile gelöscht.
Das heißt, es ist im Terminal nicht sichtbar tatsächlich, aber im Logging-Output, glaube ich, beim Build-Prozess, da ist es dann einem Nutzer der Applikation aufgefallen.
Das hat da jetzt keinen Schaden angerichtet, weil es an der Stelle nicht von einem Agenten benutzt wurde.
Aber das ist kein Supply-Chain-Angriff, sondern das ist einfach ein...
Maintainer von einer Library, der sagt, LLMs sind nicht ethisch und deswegen alle, die LLMs nutzen, quasi bestraft durch so ein Output.
Wahnsinn.
Aber Credits übrigens an Ralf D.
Müller, bei dem habe ich es nämlich gelesen.
Wir müssen quasi einen LinkedIn-Artikel in die Show Notes packen.
Aber das ist das, was ich vorhin meinte, das Thema Security.
an der Stelle, Sandboxing, das ist sehr heiß, weil wir nicht wissen, es ist nicht beherrschbar.
Er erzeugt Code, er macht irgendwas.
Das siehst du gar nicht mehr, was er da tut.
Du kannst glauben, so wie es mir passiert ist, ich habe das im Griff mit den API-Keys und das ist so.
Das ist Realität.
Danke euch.
Last but not least, habt ihr noch irgendwie eine Prediction, die ihr unseren Zuhörern mitgeben wollt?
Kommen wir gleich.
Ich wollte noch ein paar Punkte nennen zum Reality-Check.
Also was Reality-Check unserer Erfahrung ist, so ein bisschen MCPs wurden ein bisschen überbewertet, das Thema Rack wurde ein bisschen überbewertet und was auf jeden Fall nochmal Hot Shit ist, so lokale On-Premise-LLMs.
Da haben wir in einem Kundenprojekt auf jeden Fall Zugang, sage ich mal, zu einem lokalen On-Premise-LLM, was gut ausgestattet ist, sage ich mal.
Das ist halt schon mal was anderes, wo du dann halt, ja, Dinge halt ohne dir Gedanken zu machen, was du da halt reinschicken kannst.
Und das hat, glaube ich, Potenzial und das werden wir halt verstärkt sehen, dass sich das, glaube ich, noch weiter etablieren will, auch wegen den Tokenkosten und so weiter.
Ja, finde ich spannend und das Rack insofern überbewertet, weil ich glaube einfach, ein Agent mit Zugang zu entsprechenden APIs und den Suchmöglichkeiten, die dann halt so schnell passieren, haben wir ja die Erfahrung, dass das oft echt ausreicht für einen Agenten.
Der kann sich durch APIs, wenn du ihm die richtigen Tools gibst, so schnell durchsuchen.
Da lohnt sich für viele Cases, lohnt sich da kein Rack aufzubauen.
Gut, dann kommen wir zur Prediction, oder?
Jo.
Habt ihr eine Prediction für uns?
There is no silver bullet.
an der Stelle.
Auch über dieser Glaube, wir retten die komplette Welt.
Ich bin ja schon ein bisschen älter, das habe ich schon öfters immer so gehört, immer wenn so eine Welle kam.
Und das, was Andreas gerade gesagt hat, hinsichtlich jetzt so MCP, Rack, wir sind eigentlich alle noch im Moment so Zauberlehrlinge, die versuchen, den Herr der Agenten zu werden, in Anlehnung an Herr der Ringe.
Da sind wir im Moment noch.
Und ich glaube, wir lernen alle noch und ich weiß auch noch nicht, wo die Reise hingeht, aber eins würde ich sagen ist, Software-Factories kommen, ob Dark oder Light, keine Ahnung an der Stelle, vielleicht auch was dazwischen.
Die Idee, so wie wir sie kennen, die geht nicht weg, die wird es weitergeben, aber es wird sich das Zusammenarbeitsmodell, wie wir vorhin auch schon gehört haben, wie unsere Sicht ist, verändern.
Und das ist wichtig, dass wir es alle verstehen.
Ja, plus.
Also ich muss oft denken oder gerade auch, was Pi ausmacht, dass man es schnell selber modifizieren kann.
Und man hat ein Stück Software und das ist halt wirklich on the fly quasi änderbar.
Und das könnt ihr mir vorstellen als ein Szenario, dass, wie gesagt, ich mache die Software auf, das Feature ist noch nicht da.
Ich wünsche es mir und etwas später ist es plötzlich da.
Also so ein bisschen on demand.
Computing oder wie man das auch nennen wird, wie auch immer, self-modified, so in die Richtung, glaube ich schon, dass wir da einfach mehr sehen, dass Software sich einfach sehr, sehr schnell anpassen wird, vielleicht auch personalisiert ausgespielt, der gleiche Softwarekern, aber dann habe ich halt on the fly, kriege ich für den Use Case, für die Persona vielleicht unterschiedliche Oberflächen.
Da glaube ich, da wird eigentlich viel passieren.
weil es machbar ist.
Sich selbst verändernde Software.
Vielen Dank euch.
Danke schön.
Gerne.
Danke, dass wir da sein durften.
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.