230 Millionen Tokens für ein Feature: Was passiert, wenn KI-Agenten Software bauen

Was passiert, wenn Coding nicht mehr der Engpass in der Produktentwicklung ist?

In dieser Folge von Becoming CTO Secrets spricht Philipp Deutscher mit Kilian Hann, CTO bei helloTESS!, über agentische KI in der Praxis. Als realen Produktentwicklungsprozess. Kilian erklärt, wie sich seine CTO-Rolle verändert hat, warum bei KI-gestützter Entwicklung Spezifikation, Review und QA plötzlich viel wichtiger werden und wie er mit Paperclip eine virtuelle Softwareorganisation aus AI Agents aufgebaut hat.

helloTESS! entwickelt ein iPad-basiertes Kassensystem für Gastronomie, Hotels, größere Ketten und Kantinen. Dadurch geht es in der Folge auch um die besondere Komplexität von Software, die im operativen Betrieb einfach funktionieren muss: Offline-First, Resilienz, hohe Integrationstiefe, Fiskalisierung, Property-Management-Systeme, Lohnabrechnung, Subventionen und Support in zeitkritischen Umgebungen.

Im Zentrum steht Kilians Paperclip-Experiment: Mit Agentenrollen wie Product Owner, UX, Developer, Test Agent und Reviewer hat er eine Flutter-App autonom entwickeln lassen und bis zur App-Store-/Store-Submission gebracht. Aus dem Experiment ist mittlerweile ein Ansatz entstanden, den helloTESS! in abgegrenzten Produktbereichen produktiv testet.

Wir sprechen über:

• warum KI das Bottleneck vom Coding zu Spezifikation und QA verschiebt,
• wie Paperclip als Orchestrierungslayer für eine digitale Softwareorganisation funktioniert,
• warum Guardrails, Pull Requests und Human Gates entscheidend sind,
• wie visuelle Drifts, Rollendrift, Model Drift und plausible Fehler entstehen,
• warum 230 Millionen Tokens für ein Epic eine echte Wirtschaftlichkeitsfrage aufwerfen,
• wie Kilian Paperclip mit Mac Mini, dediziertem GitHub-User und klaren Berechtigungen betreibt,
• wie Artefakte im Repository Toolwechsel überleben,
• und warum zukünftige CTOs vor allem zwei Dinge lernen müssen: präzise spezifizieren und gnadenlos reviewen.

Eine Folge für CTOs, Engineering Leader und Entwickler, die verstehen wollen, was agentische Softwareentwicklung heute schon kann – und wo der Mensch weiterhin Verantwortung übernehmen muss.

Transcript

SPEAKER_01 0:00

Hallo und herzlich willkommen zu Becoming CTO Secrets, dem Podcast von CTOs für CTOs und diejenigen, die es noch werden wollen. Ich bin Philipp Deutscher, externer CTO, CTO Coach und auch der Gründer der Becoming CTO Community. Heute spreche ich mit Kilian Hahn von Hello Test über seinen Weg zum CTO und natürlich auch darüber, wie agentische KI gerade die Softwareentwicklung verändert. Ja, das ist ein Thema, das kommt gerade immer wieder, auch bei uns hier im Podcast. Besonders spannend daran ist nämlich, Kilian experimentiert nicht nur theoretisch mit autonomen Entwicklungsprozessen, sondern hat mit Paperclip bereits eine Flutter App bis in den App Store gebracht und arbeitet daran, diesen Ansatz in ein echtes Produktteam zu überführen. Ich habe auch schon sehr viel mit Payperclip gemacht in den letzten Wochen und ich bin sehr gespannt drauf, Kilian mich mit dir dazu auszutauschen und vor allen Dingen auch zu verstehen, was du machst und wie weit du bisher gekommen bist. Also herzlich willkommen. Vielen Dank für die Einladung, Philipp. Freut mich. Sehr, sehr gerne. Hab mich wirklich sehr gefreut auf das Gespräch. Wir hatten ja schon ein längeres Vorgespräch bei einer CTO-Konferenz und da war ich relativ hockt darüber, über was wir heute alles sprechen werden. Killian, wenn du dich jemandem vorstellst, der Hello Test und vor allen Dingen auch deinen Background noch nicht kennt, was ist denn so der rote Faden deiner bisherigen CTO-Reise?

SPEAKER_00 1:22

Ja, also ich habe angefangen mit Wirtschaftsinformatik, bin dann lange ins Ausland gegangen, nach England, war fünf Jahre in England, habe dort dann ERP-Informatik gemacht, war dann in der Schweiz. Und als ich zurück nach München gekommen bin, war ich zuerst in einer Parallelfirma zu Hello Test und bin dann irgendwann operativ rübergegangen und habe dort die Rolle als CTO-Gründer.

SPEAKER_01 1:43

Sehr gut, was macht denn Hello Test eigentlich? Vielleicht, also wir wollen keine Hello Tess-Werbe-Podcasts machen, aber du darfst natürlich trotzdem ein paar salbungsvolle Worte über deinen Arbeitgeber sagen, was ihr macht und wofür ihr bekannt seid.

SPEAKER_00 1:54

Also, wir machen ein iPad-basiertes Kassensystem für die Gastronomie und sind da besonders auf größere Ketten und Hotels spezialisiert. Und auch, weil das mit dazugehört, für geschlossene Zahlsysteme, zum Beispiel in Kantinen.

SPEAKER_01 2:10

Okay, sehr gut. Und zurück mal auf deine Reise. Das ist jetzt auch nicht deine allererste CTO-Rolle, sondern du hast bereits ein paar in der Vergangenheit gehabt, wenn ich das richtig noch aus LinkedIn-Eninnerung habe. Wie viele Rollen waren das bisher?

SPEAKER_00 2:23

Ja, ich habe das in der Schweiz, die technische Leitung gehabt in der Kommunikationsagentur. Das war ein sehr kleines Team.

SPEAKER_01 2:31

Und du warst, gab es da einen bestimmten Moment dann auch auf deiner Reise, in dem du gemerkt hast, dass du jetzt nicht mehr nur technischer Problemlöser bist, sondern wirklich CTO. War das ein bestimmter Moment oder an den du dich rückerinnern kannst oder der sich in dem Moment dann auch so angefühlt hat?

SPEAKER_00 2:52

So einen richtigen, eindeutigen Moment nicht, aber schon, wenn man sich zurückerinnert, schon eigentlich, wie man sich weiter von dem Code entfernt und weiter von dem eigentlichen Doing entfernt und dann mehr in das übergeordnete, in die übergeordnete Rolle geht. Im Austausch mit Kunden, aber natürlich auch im Austausch nach innen hinein in das Team.

SPEAKER_01 3:13

War das dann eine Veränderung, die du auch gerne so in Kauf genommen hast? Oder hast du dich dann zwischendrin auch dagegen gesträubt oder gewählt? Also ich kenne tatsächlich viele, die damit hadern, auch mit dem Verlust an technischer Detailexpertise, wenn sie natürlich immer weiter höher wandern, sowohl halt auf Managerial Level, weil sie dann irgendwann die ja sehen, sie machen mehr high-leveligere Aufgaben und sind viel weniger in der technischen Implementierung. Und das merken sie und das fühlt sich erstmal wie Identitätsverlust an. War das bei dir ähnlich oder gar nicht?

SPEAKER_00 3:49

Nein, also ich fand das total spannend, weil was natürlich in dem Moment passiert ist, wenn man weiter nach oben kommt, ist, dass man sein Wissen eigentlich multiplizieren kann, weil natürlich die Einzelnen, die drunter sind, natürlich ganz andere Wissen ganz anders verteilen können. Viel mehr technisches Wissen auf unterschiedlichen Feldern, was man selber viel schwerer sich erarbeiten kann, weil es einfach ein sehr breites Feld wird. Und das ist eigentlich der, das ist eigentlich der spannende Punkt dann gewesen.

SPEAKER_01 4:16

Hast du das von Anfang an wirklich auch so wahrgenommen und gefühlt? Oder war es da auch nochmal eine. Nein, das ist dann mit der Zeit gekommen. Das ist mit der Zeit gekommen.

SPEAKER_00 4:25

Am Anfang versucht man natürlich auch noch überall seine Finger mit drin zu lassen, in Anführungsstrichen, aber es ist, man kommt dann zu einem Punkt, wo man merkt, dass es einfach nicht geht.

SPEAKER_01 4:35

Jetzt bist du ja auch schon seit ein paar Jahren CTO, seit einigen Jahren. Was hat sich denn für dich an der CTO-Rolle in den letzten Jahren am stärksten verändert? Also ich gehe davon aus, du hast eine Veränderung wahrgenommen, vielleicht sogar besonders seit KI so massiv halt in Produktentwicklung reindrängt. Wie nimmst du das am stärksten wahr? Vielleicht auch an dir oder auch an anderen CTOs, die du kennst?

SPEAKER_00 5:00

Also in der Produktentwicklung merkt man am stärksten den Swift vom Bottleneck eigentlich. Man hat ganz klassisch eigentlich immer das Bottleneck in der Umsetzung gehabt und da ist es jetzt eigentlich gar nicht mehr. Das Bottleneck entsteht weiter vorne, wo die Ideen erstellt werden, kreiert werden, spezifiziert werden und entsteht weiter hinten, wo Curie stattfinden soll, wo das Ganze dann ins Endprodukt reinfließen soll. Der Mittelteil, der dazwischen klassischerweise eigentlich das, ja, das Bottleneck war gibt es eigentlich nicht mehr. Also es hat sich in die beiden äußeren Teile verschoben, allgemein aber. Wieso war das vorher ein Bottleneck? Es gab immer viel zu viele Ideen eigentlich, um sie umzusetzen. Also zumindest in so Startups, wie wir es waren, war das eigentlich immer der Fall.

SPEAKER_01 5:46

Vielleicht nochmal kurz zurück zu Hello-Test. Was macht denn aus deiner Sicht die Software für Gastronomie schwierig, gerade so aus der technischen Sicht? Man könnte ja von außen betrachten und sagen, ja, was ist denn da so schwierig da drin? Da muss halt irgendwie, da hast du eine App für, um das zu machen und ja, wo ist da die Komplexität?

SPEAKER_00 6:06

Also auf der einen Seite haben wir als Kassensoftware gerade in größeren Umgebungen einen sehr hohen Integrationsfaktor. Also wir sind sehr tief in den Umsystemen mit drin. Bei Kantinen zum Beispiel sind wir ein bisschen in die Lohnabrechnung oder in Subventionen. In Hotels sind wir ein bisschen ins Property Management System. Und auf der anderen Seite ist das Kassensystem für den Gastronom eigentlich nur ein Hygienefaktor. Es muss einfach funktionieren. Es ist nicht der Bedienung, ist es egal, wieso eine Kasse nicht funktioniert, wenn sie nicht funktioniert, da ist egal, ob das Zahlsystem nicht funktioniert, ob die TSI nicht funktioniert, ob irgendwas Stormon nicht funktioniert, die Kasse funktioniert nicht. Und deswegen muss ein Kassensystem sehr resilient aufgebaut sein. Das ist eben sowohl resilient gegenüber Fehleingaben des Benutzers als auch gegen Prozessstörungen, die weiter hinten stattfinden, weiterhin funktioniert, damit der gastronomische Betrieb nicht unterbrochen wird.

SPEAKER_01 7:04

Bedeutet das, also wo ist der Unterschied zu normaler Software? Also ich meine, theoretisch will jeder User, egal in welchem Bereich, eine funktionierende Software, eine zuverlässige Software, eine Software, die resilient ist, die ihm reibungslos funktioniert. Also wo ist der Unterschied im gastronomischen Bereich? Oder vielleicht nochmal der eine Aspekt, den es dann besonders macht.

SPEAKER_00 7:32

Es ist natürlich, also es gibt auch in den gastronomischen Betrieben ja meistens nur eine oder vielleicht zwei Kassen. Also wenn die ausfallen, dann ist der gesamte Betrieb gestört. Also während wenn ich jetzt, und es ist ja auch zeitkritisch, während wenn ich jetzt eine Software habe, die nicht hundertprozentig funktioniert, eine Textverarbeitung oder irgendetwas oder irgendwas Trivialeres, dann ist das ja egal, dann kann ich das auch verschieben zeitlich. Aber im gastronomischen Betrieb ist es schwierig, das zu verschieben.

SPEAKER_01 7:59

Bedeutet das dann auch viel Incident-Management? Oder wie darf ich mir das vorstellen, wenn dann wirklich mal was steht, ihr braucht dann eine 24-7-Eingreiftruppe, die schnell dafür sorgt, dass wieder alles da ist, oder baut ihr von vornherein so resilient, dass ihr eigentlich gar nie eingreifen müsst?

SPEAKER_00 8:15

Genau, also der Ansatz von unserem System ist, dass wir eben, obwohl wir eine cloud-basierte Lösung haben, ist, dass wir schon von Anfang an komplett offline ursprünglich waren. Also wir haben zum Beispiel auch unsere Kasse auf Weihnachtsmärkten laufen, wo die Kassen zwei Wochen lang offline sind und erst danach reinsynchronisieren. Also das ist schon mal egal von der Netzwerkinfrastruktur. Und das hilft uns auch, oder dieser Systemaufbau hilft uns auch, wenn wir zum Beispiel in Stoßzeiten in Kantinen sind, wo über die Mittagszeit tausend Essen ausgegeben werden an unterschiedlichen Kassen. Wenn es dort zu Netzwerkschwankungen kommt, dann ist es unserer Kasse erstmal egal. Es wird dann einfach nachgesendet. Also das ist etwas, was wir sehr früh und sehr tief ins System eingebaut haben.

SPEAKER_01 9:05

Okay, ja, das stelle ich mir tatsächlich schwierig vor. Über Weihnachtsmärkte hinweg, wenn Kassen mehrere Wochen am Stück offline sind. Was ist denn da, wenn dann wirklich mal was nicht funktioniert an der Kasse? Was macht der Kunde denn dann? Ruft er dann irgendwo an?

SPEAKER_00 9:20

Ja, also der ruft bei unserer Support Outline an, der kann über einen Hotspot online gehen. Wir finden da dann schon Lösungen. Also heutzutage ist es auch nicht mehr so, dass ein Weihnachtsmarkt jetzt nicht online ist. Heutzutage ist es ja auch eine Commodity geworden, dass du mit einem LTE-Router auch kleinere Venues online bringst. Oder eben direkt das iPad online bringst über eine LTE-Karte?

SPEAKER_01 9:46

Ja, ist ja eigentlich auch eine saublöde Frage von mir gewesen. Also, ich meine, natürlich rufst du dann irgendwo an, wenn irgendwas nicht geht und man nicht online ist, aber man ist mittlerweile so viel online, dass es eigentlich schon, man nicht mehr vergessen hat, dass es ja noch dieses komische Ding namens Telefon gibt und ja. Aber völlig nachvollziehbar. Wohin steht denn der eigentliche Mehrwert dann? Ist das dann in der Software und in der Resilienz der Software? Ist das dann im Prozesswissen, das ihr habt, über das, was da stattfindet? Ist es die Integration oder was ist es? Habt ihr eine besondere Nähe zu der Domäne in der Gastronomie?

SPEAKER_00 10:24

Also ich würde sagen, dass es die Integrationstiefe und auch das Domänenwissen ist, was unsere Software stark auf den Markt macht und das auch dazu bringt, dass wir weiter wachsen können in diesem Markt. Brauchst du das auch als CTO? Ja, also es sind sicherlich auch Finanzthemen, die ich mir irgendwie aneignen musste, um die auch vernünftig abbilden zu können. Oder wir sind natürlich auch stark in stark regulierten Märkten, wo wir in Deutschland zum Beispiel die TSE als Fiskalisierung benötigen. Wir sind aber in nahezu allen europäischen Ländern, jedes europäische Land hat eine andere Fiskalisierungslösung. Bis hin zu USA, wo wir einige Kassen stehen haben, die auf einmal kein mehrwertsteuerbasiertes System haben, sondern ein nettobasiertes System, wo die Steuer drauf gerechnet wird. Das sind alles Herausforderungen, die dann natürlich auch bis hinein in die Software spielen.

SPEAKER_01 11:25

Okay, ist interessant. Das heißt also, du bist mittlerweile auch richtig Domain-Experte in diesem Gastrobereich und in den letzten zehn Jahren geworden, ein Experte darin.

SPEAKER_00 11:38

Ja, ein bisschen, ja.

SPEAKER_01 11:40

Sehr gut. Ja, ich glaube, ein Bereich, in dem du auch immer mehr zum Experten wirst, ist der Bereich der agentischen KI. Obwohl ich weiß nicht, ob wir uns alle schon Experten nennen können. Vielleicht ja, vielleicht nein. Wir sind, glaube ich, an der Spitze einer Bewegung, die gerade ganz massiv über uns hereinrollt und wir versuchen sie aktiv mitzugestalten. Vielleicht macht uns das zu Experten, wobei wir auch alle gerade selber versuchen auszuprobieren, was funktioniert und was nicht. Das bringt mich nämlich zu einem Thema, über dem, über das wir bereits gesprochen haben, offline, und das glaube ich wert ist, auch nochmal hier im Podcast besprochen zu werden. Und zwar geht es um, ich fange jetzt mal nicht an mit Paperclip. Ich werde gleich, oder du wirst vielleicht auch gleich erklären, was Paperclip ist, sondern um eine Idee, nämlich eine vollautonome, ich nenne es jetzt mal, Softwarefabrik zu bauen. Und du hast das gemacht. Vielleicht kannst du mal kurz erklären, was du gemacht hast und wie du darauf gekommen bist.

SPEAKER_00 12:38

Na, ich habe vor etwa einem Jahr durch einen CTO-Kollegen auch die sogenannte BMAT-Method kennengelernt. Das sind insgesamt sechs Agenten, die definiert sind, die Prozesse hinterlegt haben und die eigentlich ein komplettes Software-Entwickler-Team abbilden. Wir haben dies dann bereits bei uns im Produkt, also unser Produkt ist aufgeteilt in unterschiedliche Repositories. Dort haben wir das dann in unterschiedliche Repositories schon eingesetzt, sodass wir schon einzelne Agenten verwenden konnten, um zum Beispiel Spezifikationen für unsere Features im Agenten schreiben zu lassen. Ich bin dann, so im April irgendwann dieses Jahres, durch einen anderen Kollegen auf PayPalclip aufmerksam geworden und hatte dann eben die Idee, dieses BMAT-Framework, also es gibt, in PayPalclip zu integrieren. So dass die Agenten, die ich mir in PayPalclip erstelle, also PayPlip ist aufgebaut wie eine Softwareorganisation, du startest eigentlich mit deinem CEO und führst dann einen Hiring-Prozess durch. Diesen Hiring-Prozess hiert dir dann eben das, was du für dein Team brauchst, was du am Anfang eingepromptet hast, was du haben willst. Und ich habe eben diesen Hiring-Prozess dadurch gesteuert, dass ich mir die einzelnen Agenten habe basierend auf der BMAT-Spezifikation. Also sie hatten dann nicht nur das ganze Wissen oder die ganze Kenntnis von diesen agenten, sondern konnten auch diese Tools von diesen Agenten anwenden.

SPEAKER_01 14:27

Kannst du uns kurz erklären, was die BMET-Method ist? Ich glaube, die allerwenigsten wissen genau, was damit anzufangen ist.

SPEAKER_00 14:33

Das ist ein BMIT Method ist ein Open Source Projekt, in dem Agenten und auch Workflows erstellt werden, die dann tool-agnostisch laufen können. Also man installiert sich das in sein Repository hinein und kann dann überlegen, mit was man eben arbeitet, ob man mit Codex, Cloud oder Open Code oder was auch immer arbeitet. Und man hat dann diese Agenten zur Verfügung. Wenn ich jetzt zum Beispiel den UX-Agenten dann starte, hat er genau sein Toolset, das ein UX-Agent bräuchte. Und dieser Agent erstellt dann einen Artefakt mit einem festdefinierten Verzeichnis innerhalb vom Repository. Und wenn ich im Anschluss weitere Agenten drauf laufen lasse, greifen die genau auf diese Artefakte zu, aber nur genau auf den Bereich, den sie eigentlich benötigen. Das hält das Kontextfenster klein und hält auch das Wissen und die Fähigkeiten bei den einzelnen Agenten. Also jeder Agent ist dann auf das spezialisiert, was er eigentlich machen kann. Und wir haben den Vorteil darin gesehen, dass die Spezifikation, die erstellt wird, direkt im Repository-Code bleibt und dadurch tool agnostisch ist. Wir können also jetzt, wenn wir ein da drin ein Epic definiert haben, mit einem UX-Mock-Up, mit den einzelnen Stories und so weiter, der ganze Entwicklungsstand, der dann schon stattgefunden hat, lebt weiterhin im Repository. Das bedeutet, wenn wir irgendwann das Tool wechseln, können wir dennoch weiterhin darauf zugreifen. Und genau das habe ich dann im Prinzip mit Paperclip gemacht. Ich habe dann Agenten geschrieben, die Agenten schreiben lassen, die dann dieser BMAT Method folgen und genau auf diese Sets zugreifen, die dann im Source Code liegen.

SPEAKER_01 16:44

Das heißt, wenn du diese, also du hast gesagt, das sind sechs oder sieben verschiedene Rollen bei BMAT.

SPEAKER_00 16:50

Welche sind das dann? Die wichtigsten oder die ich am wichtigsten bin, ist der Product Owner UX Entwickler natürlich, den gibt es dann zweimal, einen Test Agent und noch ein Scrum Master. Also ich nehme eigentlich die fünf.

SPEAKER_01 17:04

Warum gibt es den Entwickler zweimal? Um mehr Durchsatz zu kriegen oder hat das eine spezielle Bedeutung?

SPEAKER_00 17:11

Nee, der hat, den kannst du leicht unterschiedlich starten. Ich weiß jetzt auch nicht, ob es in der aktuellen Version immer noch so ist von BMAT, aber den kannst du leicht unterschiedlich starten. Einmal, dass er schreibt und einmal, dass er mit einem anderen Model den Review macht. Also dass wir zum Beispiel mit Codex schreiben und mit Cloud Review und andersrum.

SPEAKER_01 17:30

Ah, okay. Also du hast im Endeffekt da vorgesehen, dass mit eigentlich einem ähnlichen Rolle, aber unterschiedlichen Modellen gearbeitet wird. Das ist interessant, wenn ich an der Stelle dann mal einhake, weil ich habe, ich habe ähnliche Experimente gemacht. Ich habe nicht die Beamit-Method genommen, sondern ich bin, habe von vornherein ein Zielmodell im Kopf gehabt. Ich wollte CEO, CTO, CPO. Ich wollte CTO, also CPO sollte eine Produktorganisation unter sich haben mit Product Ownern. Der CTO hatte Architekt, hatte Entwickler, hatte QA und DevOps und so weiter. Und bin dann auch rangegangen und habe nicht dem CEO den Auftrag gegeben, diese Leute zu heiren, so wie du das gegeben hast, sondern habe das gleich halt über Cloud Code, habe das versucht zu orchestrieren. Habe dann gesagt, das ist meine Organisation, die stelle ich mir vor, gebe denen diese und jene Skills und habe mir im Vorfeld natürlich ein Set an sinnvollen Skills und Instruktionen runtergeladen und hab die dann versucht, darüber zuzuordnen. Das hat auch gut funktioniert. Wir kommen dann gleich zu all den vielen Punkten, bei mir zumindest, die nicht funktioniert haben. Und du kannst dann auch deine erzählen. Vielleicht nochmal ganz kurz ein, zwei Worte zu Paperclip für diejenigen, die Paperclip nicht kennen. Paperclip, ich würde sagen, ist eine, du möchte eine digitale Organisation abbilden oder die möglich machen und ist, ich verstehe PayPalclip als ein Orchestrierungslayer, auf dem du, mit dem du allerhand Sachen machen kannst. Und du kannst dann den Agenten, kannst du alle möglichen Modelle zuweisen, du kannst ihnen sogar quasi in Open Claw mitgeben, wenn du das möchtest. Ich bin auch übrigens auf die Idee dann irgendwann gekommen, dem CPO, also mehrere Instanzen des CPOs und des CTOs zu machen, nämlich abhängig davon, ob ich jemanden möchte, der hier mit Opus arbeitet oder dann doch mal nur mit Sonnet. Kommen wir gleich dazu, warum das dann wichtig ist. Aber genau, vielleicht noch ein bisschen Kontext zu schaffen. Also es gibt, du hast mit BMET-Method gearbeitet, ich habe das Ganze über einen anderen Weg reingebracht. PayPalclip ist der Orchestrierungslayer, aber die eigentliche Magic geht ja dann los, wenn die Agenten miteinander anfangen zu arbeiten. Wie hat das dann bei dir geklappt, als du dann angefangen hast?

SPEAKER_00 19:47

Naja, wie du es eingangs gesagt hattest, ich habe das Ganze als ein Greenfield-Projekt gestartet mit einer Flutter-App. Ziel der Applikation war, ich habe ja, wie ich eingangs auch gesagt habe, so ein bisschen Bioinformatik mal gemacht. Ziel war, eine App für Studierende zu schreiben, die einfache bioinformatische oder Bio-Tools zur Hand haben, dass sie die einfach lösen können. Ansatz war wieder Offline First, soll natürlich Multiplattform sein und Ziel war, dass es in sowohl in App Store als auch in Play Store ist und jeweils mit einer Paywall. Das war eigentlich mal das grobe Ziel, was ich haben wollte. Und dann habe ich angefangen, eben mit meinen Agenten, die ich da drin hatte, in einem komplett frischen Repository, alles aufzubauen. Und der Weg war eigentlich immer der folgende, dass ich immer den Product Owner-Agenten in PayPalclip angewiesen habe, mir ein Epic zu schreiben und das abzulegen im Code wiederum. Das Ganze wird ganz stringent immer durch einen Pull Request von mir abgesegnet. Also jede Code-Änderung, die immer gegangen ist, musste immer über einen Pull-Request gehen. Auch wenn es eben zum Beispiel nur ein Definitionsfall durch den Product Owner war. Wenn ich dann damit zufrieden war, ist es weitergegangen an den UX und so weiter, ich habe dann diese Teile später zusammengefügt, also dass dann zum Beispiel der Product Owner erst den Pull Request aufmachen sollte, wenn der UX bereits einen Mock-up gebaut hatte und so weiter. Also das konnte man dann nachher alles zusammenfügen. So dass es dann eigentlich, als das alles definiert war, dann Richtung Scrum Master gegangen ist, der dann die ganzen Tilstorys schreiben sollte und dann die Entwickler nach Bedarf starten sollte und eben wieder durch Pull Requests zum Ende bringen sollte. Also dass ich am Ende wieder einen Pull Request bekomme, mit dem ich dieses Feature dann kontrollieren konnte über ein Build und zurückmergen konnte. Das heißt, der Scrum Master hat die Story? gebaut. Ja, das ist in BMAT so, da gibt es dann aber noch so einen, da gibt es noch einen so einen Verification-Schritt, wo der nochmal schaut, dass es eben umsetzbar ist. Also die Rollen vom Scrum Master und Product Owner sind an der Stelle nicht ganz trennscharf.

SPEAKER_01 22:17

Ja, interessanterweise, da habe ich eben wirklich, war ich sehr überrascht, die Scrum Master-Rolle bei dir zu hören. Gerade auch vor dem Hintergrund, dass Scrum ein Prozess ist, der ja ich durchaus einige CTOs jetzt getroffen haben, die die Sinnhaftigkeit, die Sinnhaftigkeit von Scrum in einer agentic AI-Zeit in Frage stellen. Weil das nämlich auch sehr stark mit dem Engpass nämlich zu tun hat, warum man sowas wie Scrum überhaupt gebraucht hat und das jetzt immer obsolet wird. Also warum brauche ich einer agentischen Organisation, einen Scrum Master?

SPEAKER_00 22:53

Das ist, da gebe ich dir vollkommen recht. Wenn ich es jetzt nochmal neu aufbaue, dann würde ich, dann würde ich es auch nicht mehr reinnehmen. Das ist vollkommen recht.

SPEAKER_01 23:02

Aber das klingt bis hierhin ja schon mal sehr gut, ne? Und auch sehr durchdacht und so weiter. Hat das bis hierhin auch so gut funktioniert oder gab es dann gleich von Anfang auch ein paar Sachen, die richtig schief gegangen sind?

SPEAKER_00 23:13

Ja klar. Also das geht natürlich am Anfang alles schief, weil am Anfang gibt es vielleicht noch kein stringentes UX-Konzept. Also jedes Epic, jeder Screen, der dann in Flutter gebaut wird, sieht anders aus. Jedes, also das sind Sachen, die sind dann, die gehen dann komplett auseinander. Es ist bis dahin gegangen, dass zum Teil auch Datenbanken, also in Flutter gibt es so State Management, es ging dann dahin, dass mal Riverport, mal ein anderes State Management verwendet wurde und so. Also das, aber was dann das Gute war, war, dass man das eigentlich immer direkt zum CTO in Paperclip zurückspielen konnte und den CTO anweisen konnte, dass er das CloudMD-Agen-MD-File im Repository anpassen soll und das als neue Guardwell reintrücken soll. Und somit ist das Produkt eigentlich mit jedem Fehler, es ist wie ein Trichter zusammengelaufen, dass es eigentlich immer stringenter wurde, was dann eigentlich entwickelt wurde. Das finde ich, hat sehr gut funktioniert.

SPEAKER_01 24:20

Wie viele Tokens hast du denn verbraten, bei deinem ersten Versuch, eine solche App zu bauen? Das klang ja jetzt so, wie du hast relativ schnell eben einen Auftrag gegeben, hier eine komplette App zu bauen. Du hast dann Vorgaben gemacht und das sollte dann Storys schreiben und so weiter und so fort. Mit welchem Token-Spend bist du denn da rausgegangen?

SPEAKER_00 24:38

Ja, ich wusste natürlich, dass die Frage kommen wird, deswegen habe ich mir mal einen Epic angeschaut. Ja, da kann man sich auch festhalten, ich habe für einen Epic, was ein Plattendesign, also ein GPT-Design, umsetzt, etwa 230 Millionen Token verbraucht.

SPEAKER_01 24:55

Holy shit.

SPEAKER_00 24:56

Das sind ungefähr 6000 Euro, oder? Bei 20 Euro. Das ist natürlich, das stellt natürlich die Sinnhaftigkeit in Frage. Im Anthropic Cloud Max 20, in dem das jetzt gelaufen ist, war das kein Problem, Subscription-Based. Nur wir wissen, dass es nicht für ewig Subscription-Based funktionieren wird. Deswegen ist da auch Überlegungen, das irgendwie so zu machen, dass es vielleicht auch sogar auf lokale Hardware läuft, weil die Zeit ist da eigentlich nicht die Issue. Ja, ich finde es auch falsch.

SPEAKER_01 25:40

Da bin ich nicht sicher, ob das mit lokaler Hardware und mit lokal laufenden Modellen dann am Ende des Tages besser wird. Ich habe einen anderen Ansatz, bin ich tatsächlich gefahren. Und zwar, ich habe dem ganzen Braten von Anfang an nicht getraut. Ich habe gleich, ich habe das gleich auch über die Anthropic API gemacht. Das heißt, ich bin gleich auf richtig Tokensband gegangen und habe das nicht über die Subscription gemacht, weil ich auch wirklich genauer sehen wollte, was passiert denn da und so weiter. Und was kostet mich das Ganze. Und mein erster Schritt war tatsächlich zu sagen, ich baue die Organisation und dann gebe ich Ihnen die Guardrails mit und dann möchte ich erstmal, was macht ein Entwickler, wenn er das erste Mal was ausprobiert, er baut ein Hello World-Programm. Und dann sage ich, das ist ja easy, das machen wir als allererstes Mal. So, dann bin ich aber herausgekommen und hat das Hello World-Programm, hat dann schon mal vier Euro gekostet. Aber ich gesagt, das kann ja wohl irgendwo nicht sein. Und dann hat sich auch herausgestellt, wie viel, also dann sind so Dinge, die auf die Füße gefallen, wie Orchestrierung findet, ist halt irgendwie mal ein Drittel oder ein oder 40 Prozent sogar von all den Vorgängen, die Token verbrauchen. Der CEO wacht 20 Mal auf während dieses gesamten Prozesses, weil sich irgendwelche Status in irgendeinem Ticket geändert haben. Das war jetzt nicht bei dem Hello World-Programm, aber das war bei einem anderen Thema. Der wacht auf, zieht sich dann kalt den Kontext halt jedes Mal komplett mit rein, verbraucht eine ganze Menge Tokens, nur um dann festzustellen, dass nichts für ihn zu tun ist und geht halt wieder weg. So, also das sind halt die Learnings auf dem Weg dahin, wo du merkst, nee, bevor ich irgendwie anfange, da ein größeres oder auch ein kleineres Produkt halt reinzukippen, möchte ich erstmal die Ökonomie in diesem System halt verstehen, verstehen, was am Anfang alles schiefläuft und habe dann tatsächlich die Erfahrung gemacht, das ist wie ein Kindergarten, der da losläuft. Also dann schreibt man Guardrails, man geht davon aus, man hat ja schon ausreichend gute Guardrails geschrieben, dann stellt man aber fest, dass die vielleicht nicht immer so eindeutig eingehalten werden. Das hat dann auch so Auswüchse angenommen, dass der CEO auf einmal angefangen hat, Code zu schreiben und zu committen, weil ihm dann doch mal irgendwas anscheinend nicht schnell genug ging oder er dachte, es wäre irgendwas abgebrochen. So, und das sind Learnings in diesem Prozess, die mir dann gezeigt haben, so, okay, wenn ich jetzt anfange, gleich ein größeres Repository da drin zu erstellen oder eine größere App erstellen zu wollen, dann geht mein Token-Spend richtig durch die Decke. Der ist auch später noch durch die Decke gegangen, aber ich habe es durch diesen Ansatz zumindest mal geschafft, dass mein Spend nicht in solche Bereiche vorgedrungen ist, wie das bei dir der Fall war, weil da hätte ich keine Lust dazu gehabt, irgendwie mehrere tausend Euro dafür zu bezahlen.

SPEAKER_00 28:22

Definitiv nicht. Also das ist auch, also cool, dass du das so gemacht hast. Ja, was dann im Endeffekt war, dass die so weit autonom gelaufen sind, dass ich eigentlich jeden Abend in der Region zwischen vielleicht fünf und acht, vielleicht mal zehn Pull-Requests hatte, die ich dann im Prinzip am Abend abgenickt habe. Der Scrum Master in dem Fall hatte dann die neuen Tickets, die eigentlich dann dran waren, die halt blockiert waren durch Vorherige, wieder geöffnet und hat die dann weiterentwickeln lassen. So, dass das eigentlich dann ein Prozess war, der kontinuierlich durchgelaufen ist.

SPEAKER_01 29:06

Ja, sehr gut. Hast du noch sonstigen Drift irgendwo gesehen bei dir? Also ich habe ja bei mir schon mal ein paar erwähnt, das war ein Cost Drift, der stattgefunden hat, weil der CEO halt so oft aufgewacht ist. Also, das ist ein Beispiel dafür, dass die Orchestrierung halt suboptimal war. Ich habe tatsächlich den Roll Drift festgestellt, das heißt, der CEO hat angefangen, Code zu schreiben. Und wie ich eben gesagt habe, und es gab noch Model Drift, das heißt, der CTO hatte eigentlich alles, was mit Orchestrierung zu tun war, erstmal auch mit Opus gemacht. Und das war natürlich sehr teuer für das, was stattfindet. Und wenn dann im Endeffekt du eine Projektleistung hast und da ist 36% Orchestrierung, 31% Rework, 17% Verification und nur 16% ist die eigentliche Entwicklung, die da stattfindet, dann weißt du, glaube ich, schon, wenn man das so aufdröselt, an welche Stellen man ansetzen muss, um das überhaupt mal einigermaßen effektiv zu machen. Also das war interessante Learnings dabei. Aber wie ging es denn bei dir weiter? Wie bist du weiter vorangekommen und hast dann das auch so weit getrieben, dass ihr mittlerweile im App Store seid mit der Flatte App, die du gebaut hast?

SPEAKER_00 30:15

Genau, also ich habe das dann, ich habe eigentlich das Epic für Epic abgearbeitet, hab dann noch sogar Sachen wie Flexmyth und sowas mit eingebaut, dass es featurebasiert Sachen an- und ausgeschaltet werden können. Und dann war wirklich der längste Prozess in dem Ganzen, oder der eigentlich am stagnierendsten war, war App Store und Placeur Submission. Das hat das war der manuelle Prozess auf deren Seite, der wirklich lange dauert hat.

SPEAKER_01 30:43

Länger als normal oder weil sie mittlerweile viele Guardrails haben, um das, um irgendwie AI-generierten Code abzufangen? Oder warum? Oder ist das im normalen Rahmen lange gedauert?

SPEAKER_00 30:55

Das kann ich so nicht sagen. Nur wenn ich es vergleiche mit unserer normalen Kassen-App, die wir sonst submitten, da kann ich auch sagen, dass es in der letzten Zeit länger geworden ist. Die Reviews, die waren früher sonst so vielleicht 12, 24 Stunden, die sind jetzt schon 24 bis 48 Stunden. Ich weiß jetzt nicht, was geändert wurde, aber das ist auf jeden Fall auffällig.

SPEAKER_01 31:22

Hast du Probleme gehabt mit Guardrails? Also, ich habe ja ein bisschen was von meinen beschrieben. Hast du mit deinen Guardrails von deinen jeweiligen Rollen Probleme gehabt, dass die nicht richtig eingehalten haben oder hast du es gleich von Anfang an besser gemacht?

SPEAKER_00 31:34

Das kann ich so nicht sagen. Also es gab einen, aber das war ein Fehler von mir. Ich habe irgendwann das Repository umbenannt und die haben, manche haben wieder angefangen, ins alte Repository zu zerbinden und sowas. Das war natürlich ein bisschen, aber das war ein hausgemachter Fehler. Also den hätte man auch einfach vermeiden können. Ansonsten habe ich sehr stark eigentlich aufs Ergebnis geschaut nur. Also und da waren es, also visuelle Drifts gab es. Funktional eigentlich gar nicht. Also funktional habe ich eigentlich wirklich nichts entdeckt, wo es wirklich Regressionen gab. Ist auch ganz stark gewesen in den Anfangsgarde, als eben, was Unit-Tests und auch visuelle Tests eigentlich direkt betrifft, dass die direkt mitgeschrieben werden sollen. Dass die auch die Unveränderbarkeit natürlich davon.

SPEAKER_01 32:32

Was hat denn, was hat denn in dem Experiment dann am Ende des Tages besser funktioniert, als du es vielleicht erwartet hast? Oder sind deine Erwartungen weitestgehend erfüllt worden?

SPEAKER_00 32:44

Also was wirklich besser funktioniert hat mit dem Laufe der Zeit, war eigentlich, wie autonom die dann wirklich gearbeitet haben. Also dass es wirklich nur noch darum ging, eben dieses Human Gate als Pull Request absegnen, einzubauen und dass die dann eigentlich wieder selbstständig weitergelaufen sind und auch selbstständig in der richtigen Reihenfolge Tickets gemacht haben, also in der richtigen Abhängigkeitsreihenfolge. Das hat besser funktioniert, als ich das ursprünglich gedacht habe. Ursprünglich war es so ein bisschen, da wollte ich immer noch zuschauen, quasi, um zu schauen, dass es richtig funktioniert, aber das hat dann sehr gut funktioniert.

SPEAKER_01 33:27

Wie lange hast du denn am Anfang gebraucht, um diesen initialen ersten State deiner digitalen Organisation zu erstellen? Also es klingt mir so, als hättest du sehr viel Zeit damit verbracht, das zu tun. Ist das, interpretiere ich das richtig?

SPEAKER_00 33:45

Ich glaube, ich habe insgesamt vier Versuche gemacht. Erst der vierte Versuch von der Organisation war dann der, den ich dann auch verwendet habe und den ich jetzt auch noch weiter habe. Dazwischen waren es halt, also ich würde sagen, vielleicht war es ein Wochenende oder das ich da verbracht habe. Also das ist halt ganz stark Learning by Doing, was, weil natürlich auch dieses Paperclip natürlich an sich auch erstmal eher abstrakt ist und wie du auch schon gesagt hast, es ist sehr verbose, es ist eigentlich sehr laut, ja. Also mit dem, was es schreibt, was ist, wenn du dann anfängst, den einzelnen Kommentaren, die in den Issues geschrieben werden, zu folgen oder sowas, dann ist es sehr, also ich habe dann auch oftmals einfach reingeschrieben, dass es mir zusammenfassen soll nochmal, weil ich keinen Bock mehr hatte.

SPEAKER_01 34:33

Ja, es ist immer ein bisschen viel geworden. Sehr gut. Würdest du denn anderen empfehlen, oder siehst du für euch einen Weg, sowas auch produktiv einzusetzen und nicht nur als reine Spielerei, sondern wirklich jetzt als, da können Produkte im unternehmerischen Kontext damit gebaut werden, gewartet werden, weiterentwickelt werden. Würdest du das dafür empfehlen? Oder sagst du, ist noch nicht reif genug, aber vielleicht, keine Ahnung, in a year from now?

SPEAKER_00 35:06

Also wir verwenden es in einem ganz, oder ich habe es jetzt bei uns, bei Hello Test, in einem ganz engen Kontext auch in die Organisation gebracht. Ich habe eigentlich ein sehr ähnliches Setup wie für das Hobbyst auf einem McMini aufgesetzt, mit ganz strikten Zugriffsberechtigungen, auch oft nur die zwei Repositories, die auch bearbeitet werden sollen, mit einem dedizierten Benutzer, der wieder auch so rechtlich eingeschränkt ist, dass er auch wieder nur über pull requests arbeiten kann. Und das funktioniert sehr gut. Man muss aber dazu sagen, dass das zwei Repositories sind, die in sich komplett autark sind. Also die haben jetzt nichts mit dem Kernprodukt zu tun. Das eine betrifft eine interne Applikation, das zweite ist die Generierung von unseren PDFs, also im Prinzip ein Microservice. Der wird im Produkt nur umgeswitcht zwischen dem alten und dem neuen Service, aber der neue Service, der wird eben komplett über Paperclip und diesen BMAT-Workflow geschrieben.

SPEAKER_01 36:17

Siehst du da einen wirklich einen großen Mehrwert drin? Also sowohl was Kosten angeht, was Zeit angeht, eine solche Multi-Agent-Organisation gegenüber einem Team von Entwicklern, die Single Agent mit Harness im Endeffekt sind.

SPEAKER_00 36:36

Du sprichst jetzt wahrscheinlich auf so Verhältnis mit, wie viel Zeit braucht der Entwickler, um den Code zu prüfen, den der geschrieben wurde, autonom, gegenüber dem, als wenn er selber ist.

SPEAKER_01 36:48

Ja, die Frage, ja, ja und nein, es geht halt darum, also ich habe mir auch die Frage gestellt, ich sehe, dass ein, wenn du Claude Code siehst mit Opus oder auch mit Fable jetzt die paar Tage, die man damit arbeiten konnte, das ist schon sehr, sehr powerful, was da, was da im Hintergrund passiert. Natürlich bist das immer noch irgendwie, hast du gefühlt sitzt da einer im Driver's Seat, der Engineer und der steuert das, was da passiert durch seine Eingaben, aber am Ende des Tages und was Fable oder Opus im Hintergrund macht, ob die nochmal andere Agents oder Running Tasks halt irgendwie instanzieren, das sei mal dahingestellt, das kann ja auch mehrere sein, aber trotzdem ist halt da immer noch einer, der vom Bildschirm sitzt und alles immer erstmal abnimmt. Und dann kann sich dann selber entscheiden, mache ich ein Review, mache ich kein Review, nicke ich das einfach alles ab, schaue ich mir alles irgendwie an. Das ist schon, das wird trotzdem, auch dieser Weg wird gerade ja immer mächtiger. Und nach meiner Erfahrung setzen halt 95 Prozent, vielleicht sogar mehr der Organisation, der Engineers arbeiten ja genau so. Vielleicht haben sie dann einen Windsurf oder einen Cursor stattdessen. Aber die allerwenigsten machen ja etwas in diese Richtung, Richtung Softwarefabrik. Also warum ist das der Fall? Weil das alles noch nicht ausgreift genug ist, weil es am Ende des Tages noch keinen substanziellen Mehrwert darstellt, weil es noch zu komplex ist, weil noch zu viel schief geht.

SPEAKER_00 38:12

Ja, ich weiß, was du meinst. Also sicherlich, wenn der Entwickler näher an einem Code ist, kann er natürlich schneller eingreifen. Auf der anderen Seite ist natürlich, wenn der Eingriff früh genug stattfindet im Sinne der Spezifikation, dass die Spezifikation bereits so eben zum Beispiel über den BMAT-PM so gebaut würde, dass sie auch agententauglich ist, in einem Code drin ist, dann sehe ich keinen, sehe ich nicht wirklich einen Vorteil, dass wenn sowieso wieder der Entwickleragent das Ganze umsetzt, wieso das in einem Cursor stattfinden soll und der Real-Entwickler obendrauf schauen soll. Also das kann ja auch, das kann ja losgelöst stattfinden und der Real-Entwickler schaut dann auf den Pull Requests.

SPEAKER_01 39:06

Siehst du, dass bei euch auch die Arbeit an bestehenden Produkten übernehmen? Oder nur Greenfield?

SPEAKER_00 39:16

Also am bestehenden, am bestehenden Produkt, ich meine, wir sind ein Legacy-Produkt, also, oder was heißt Legacy-Produkt und es gibt seit seit 13 Jahren, da ist natürlich die Codebase jetzt auch nicht mehr ganz frisch. Und das ist natürlich schon in vielen Bereichen, die auch stark in Fiskalisierung oder sowas hineingehen, da weiß ich jetzt nicht, also da sehe ich jetzt das Full Agentic Coding nicht. Es gibt aber Randbereiche, da sehe ich sicherlich. Und wofür wir es auch stark verwendet haben, ist um unsere um automatisiertes Testen, gerade in unserer SRS-Applikation, also in der Cloud-Applikation, dort auf den Legacy-Code anzuwenden. Also dass wir wirklich einfach mal in einem großen Bereich Unit-Tests drauf schreiben lassen, die einfach den Status quo mal festhalten. Ob der jetzt richtig ist oder falsch, ist total wertfrei. Aber das ist einfach, dass wir eben ein, dass wir dann in der CCD-Pipeline, dass wir dann einfach mal sehen, wenn etwas gravierend ändert.

SPEAKER_01 40:20

Ja, guter Punkt. Und auch eine gute Idee. Ich habe auch schon mit Leuten zusammengearbeitet, wo es dann auch darum ging, dass man erstmal das bestehende Produkt quasi reverse engineert und nochmal ein neues, ein Backlog erstellen lässt. Reverse engineert auf Basis der eigentlichen Codebase. Und das dann mal dagegen mappt gegen die tatsächlich, das tatsächliche Black Backlog, um überhaupt mal aufzugreifen, so, was wollt ihr, was dachten wir denn, was wir eigentlich alles schon gebaut haben und was ist denn in der Codebase da eigentlich noch drin? Und man wird sich wundern, wie viel Drift es da auch schon gibt. Also das ist tatsächlich sehr interessant. Ich stelle mir auch die Frage, also das Spannungsfeld, das ich sehe, ist, dass Tooling gerade extrem schnell evolviert und dass Teams oder auch Menschen gerade sehr viel Zeit brauchen, nicht alle, aber viele, um neue Arbeitsweisen wirklich zu übernehmen. Also meine These ist, dass wir diese Form von Multiagenten mit einer digitalen Organisation und einem richtigen digitalen Org-Chart, dass wir die in den nächsten ein, zwei Jahren sehr viel häufiger sehen werden, auch wenn sie jetzt vielleicht noch an einem Punkt sind, wo sie, naja, bei euch sind sie ja teilweise schon produktiv im Einsatz, aber an den meisten Stellen ist es halt Proof of Concept, mehr nicht. Deswegen war es mir auch so wichtig, mit dir zu sprechen, weil ihr schon so weit seid. Aber siehst du eine ähnliche Entwicklung oder denkst du, dass die Engineers in den normalen Teams die Organisationsform der Zukunft ist?

SPEAKER_00 41:51

Also jetzt auf den Punkt mit dem schnellen Wechsel des Toolings. Also, das ist einer der Gründe, wieso wir uns für BMAT entschieden haben, weil die Definitionen, die stattfinden, die Epic-Definition und auch die Implementierungsartefakte weiterhin im Code leben. Als wir angefangen haben, hat jeder von unseren Entwicklern einen Cursor verwendet. Ja, und hat die Agenten da drin laufen lassen. Das können wir auch jetzt noch machen, das können wir eins zu eins machen. Ich kann jetzt ein Artefakt nehmen, was mir jetzt ein Agent in Paperclip gebaut hat, kann es mir auschecken und kann in Cursor oder Cloud weiterarbeiten. Genau mit dem gleichen Wissen und dem gleichen Kontext, den Paperclip zur Verfügung hatte. Also in dem Sinne sind wir an der Stelle transparent. Und das ist mir auch wichtig, dass dieser Teil in einem Code weiterlebt und nicht nur in dem Model oder in dem Tool, was ich zu dem Zeitpunkt verwendet habe. Weil das kann sich sehr schnell ändern. Und es kann sich nicht nur schnell ändern, weil sich technisch ändert, es kann sich auch schnell ändern, weil vielleicht Fable abgeschaltet wird oder weil es zu teuer wird oder weil es gibt tausend Gründe.

SPEAKER_01 43:10

Ja, guter Punkt. Also vielleicht nochmal kurz, bevor wir das Thema dann auch irgendwann zumachen müssen, weil uns die Zeit auch ein bisschen davon rennt. Wie beobachtest du denn, was die Agenten tun? Guckst du auf die Logs, guckst du auf die Kosten, guckst du immer nur in das Dashboard von Paperclip rein und so oder guckst du auf Diffs, auf machst du eigene Reviews nochmal? Hast du andere Metriken, die du verwendest?

SPEAKER_00 43:35

Also ich gucke primär auf das Dashboard in Paperclip. Wir haben jetzt für uns, für die Hello Test-Organisation, auch eine Verbindung zu Linear geschaffen. Also wir arbeiten mit Linear und haben dort eine Verbindung geschaffen, sodass Tickets, die linear existieren, für die menschliche Interaktion von PayPalclip übernommen werden, dort bearbeitet werden und zurückkommentiert werden. Also Wir haben das ein bisschen abstrahiert, sodass nicht jeder mit Paperclip arbeiten möchte, weil Paperclip ist auch ein Tooling, was gegebenenfalls irgendwann ausgetauscht werden kann. Definitiv. Also ich überwache Paperclip an der Stelle ein bisschen, die Agenten, und ansonsten ganz klar über die Devs, also über das, was an Artefakten entsteht, sowohl an Spezifikationsartefakten als auch an Code-Artefakten.

SPEAKER_01 44:25

Was habt ihr für ein AI-Token-Spend im Monat? Oder beziehungsweise, ich weiß ja, ob das jetzt Token, wenn du alles über Subscription machst, ob der Tokens, obwohl doch, was ist der Token Spend, wenn du das sagen darfst.

SPEAKER_00 44:38

Das wüsste ich jetzt nicht. Das wüsste ich jetzt, muss ich ganz ehrlich sagen, das weiß ich jetzt gar nicht. Also weil es alles da drin läuft.

SPEAKER_01 44:45

Okay. Ja, die Kosten sind natürlich interessant. Wenn es aktuell nur über Subscription geht, dann ist das, dann funktioniert das jetzt noch. Die Frage ist, wie verschiebt sich das, wenn die nicht mehr da ist? Also wenn das Subscription Model so nicht mehr tragfähig ist und du nur noch über dir quasi Tokens kaufen musst und für die Tokens bezahlst, wie sich dann das noch rentiert oder ob du dann spätestens anfangen musst und dir quasi die Ökonomie deines Systems nochmal anzuschauen, wie viel Zeit für Orchestrierung draufgeht und so weiter.

SPEAKER_00 45:19

Ja, genau, aber an der Stelle ist es eben auch so, dass wir es, dass wir eben auch schon mit lokalen Gegebenheiten experimentieren, ob das nicht vielleicht auch eine Möglichkeit ist.

SPEAKER_01 45:31

Was ist denn die wichtigste Lektion, die du bisher aus deinen bisherigen Paperclip-Experimenten gezogen hast?

SPEAKER_00 45:37

Das wichtigste Takeaway ist vielleicht, dass man es wirklich als Side-Projekt startet. Dass du wirklich schaust, dass du etwas Abgeschlossenes nimmst, was klein genug ist, dass du es komplett überschauen kannst, aber groß genug, dass es sich lohnt, so eine virtuelle Firma eigentlich obendrauf zu setzen. Und dass du das eben versuchst, darüber einmal zu bauen. Das ist, glaube ich, so ein.

SPEAKER_01 46:02

Wir haben jetzt sehr viel über PayPalclip gesprochen, was am Ende des Tages ein GitHub-Projekt ist, dass man sich, dass man verwenden kann. Gibt es, hast du schon mal geguckt, ob es da Alternativen gibt, die dich interessieren, mit denen du vielleicht sogar das vielleicht nochmal nochmal starten würdest vom Scratch, würdest du irgendwas anders machen oder würdest du wieder Paperclip nutzen?

SPEAKER_00 46:20

Also im Moment habe ich nicht wirklich links oder rechts geschaut. Also es ist, es gibt sicherlich andere, aber das, wie du vorhin schon gesagt hast, das Tooling ändert sich so schnell, dass das auch ein Produktivitätskiller ist, immer nach dem Neuesten zu schauen, immer versuchen, den Neuesten hinterherzujageln.

SPEAKER_01 46:39

Das ist leider richtig und trotzdem ist es so interessant, was da passiert. Ich bin jetzt heute über Kiro oder Cairo gestolpert, was ja ein Spec-Driven-IDE ist von, ich glaube, ABS sogar. So, und dann denke ich mir auch, so sollte ich mir vielleicht mal anschauen, vielleicht, aber sollte ich mich einfach auch mal auf ein paar andere Sachen konzentrieren. Was sollte denn ein CTO in den nächsten 90 Tagen ausprobieren, wenn er agentische Entwicklung ernsthaft verstehen will?

SPEAKER_00 47:04

Ja, wahrscheinlich eben, wie gesagt, er sollte vielleicht ein eigenes Team sich mal mal aufbauen, um in einem eigenen eigenen Team vielleicht mal ein Seitenprojekt aufzubauen.

SPEAKER_01 47:16

Jetzt haben wir am Schluss ein paar Internetprobleme, merke ich gerade. Warum noch immer? Wir kommen aber auch sowieso schon zu einer der beliebten Kategorien der Rapid-Fire-Fragen am Schluss. Das ist schöne Tradition hier im Podcast. Ich habe fünf schnelle Fragen und du hast hoffentlich fünf schnelle Antworten. Hast du noch ein paar Minuten, Kilian? Ja, warte. Paperclip in einem Satz beschrieben.

SPEAKER_00 47:38

Ein Dirigent, der meine Agenten zusammenspielen lässt, anstatt dass jeder eigentlich, jeder Entwickler Solo spielt mit denen.

SPEAKER_01 47:46

Hätte ich nicht besser formulieren können, gefällt mir. Größter Produktivitätshebel durch AI-Agen.

SPEAKER_00 47:53

Dass der Weg zwischen oder die Fleißarbeit zwischen der Idee und dem laufigen Stand kleiner wird.

SPEAKER_01 47:58

Okay, sehr gut. Größtes Risiko bei autonomer Entwicklung.

SPEAKER_00 48:04

Das ist, wenn plausibler Code entsteht, der aber niemandem auffällt, weil er irgendwie zwar plausibel ist, aber nicht richtig funktioniert.

SPEAKER_01 48:13

Ja, das ist bei mir schon mit ganz vielen Unitests hochgegangen, die ich im ersten Schritt. Aber das springt da wieder nur dafür. Du hast angefangen, hast dir erstmal ein Wochenende Zeit genommen, um deinen quasi Paperclip vorzubereiten. Ich bin quick and dirty hingegangen, hab das an einem Abend irgendwie schnell gemacht und hab dann versucht, iterativ davon zu lernen. Ich glaube, beide Ansätze sind gut und man sieht ja, jetzt hat sie uns beide an unterschiedliche Stellen gebracht. Vorletzte Frage, bevor ich mir jetzt hier noch weiter um Kopf und Kragen rede: Ein Prozess, den du nie wieder komplett manuell machen willst.

SPEAKER_00 48:48

Der Weg von einer Spezifikation zu einem Erzzustand von einer Art Produkt. Dass man diesen Weg komplett verkürzt oder ausschließt.

SPEAKER_01 48:58

Sehr gut. Und eine Fähigkeit, die jeder zukünftige CTO lernen sollte.

SPEAKER_00 49:03

Genau spezifizieren und gnadenlos reviewen. Alles, was vom Agenten kommt, gnadenlos reviewen. Hältst du das für haltbar? Es wird sich zeigen, ob es machbar ist.

SPEAKER_01 49:13

Also ich bin, also ich denke, wir schreiben so viel schneller, so viel mehr Code. Und die Möglichkeiten sind da, es ist unrealistisch anzunehmen, dass das haltbar ist. Ich glaube, es ist jetzt ja noch nicht mehr mehr haltbar.

SPEAKER_00 49:25

Aber ein Review kann ja auch sein im Produkt selber. Muss ja jetzt nicht auf der Codebasis sein. Es kann ja auch einfach im Produkt selber sein. Der funktioniert.

SPEAKER_01 49:35

Und du kannst ja auch Agentic Helferline dafür nutzen, um dir zu helfen, Spezifikationen zu checken, Architectural Guardrails, Security Guardrails und so weiter und so fort. Also ja, der Review muss sein, die Verantwortung verlässt nicht irgendwo denjenigen, der für das Bauen verantwortlich ist. Aber ich denke, genauso wie es Helfer gibt, die Code bauen, wird es Helfer geben. Und da gibt es jetzt auch schon Helfer, die reviewen und so weiter. Nur der Mensch wird nicht mehr jede Zeile Code sich anschauen. Aber ein Mensch soll es immer absegnen. 100 Prozent. Sehr schön. Kilian, vielen lieben Dank. Danke dir. Ich habe heute auch wieder viel gelernt, auch dass ich das nächste Mal, glaube ich, wenn ich mit Paperclip arbeite, es ein bisschen anders mache. Genau, freut mich davon zu hören, wie erfolgreich ihr damit seid. Vielen lieben Dank, dass du heute da warst und weiterhin viel Erfolg. Danke dir, hat Spaß gemacht.

SPEAKER_00 50:22

Tschüss.

SPEAKER_01 50:22

Gerne, ebenso. Mach's gut. Ciao, ciao.