# Agentic AI Software Factories: CTO Strategy

**Podcast:** Becoming CTO Secrets
**Published:** 2026-06-30

## Transcript

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 Hann von HelloTest ü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 Paperclip gemacht in den letzten Wochen und ich bin sehr gespannt darauf, 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.
Ich habe 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 hooked darüber, über was wir heute alles sprechen werden.
Kilian, wenn du dich jemandem vorstellst, der HelloTest und vor allen Dingen auch deinen Background noch nicht kennt, was ist denn so der rote Faden deiner bisherigen CTO-Reise?
Ja, also ich habe angefangen mit Wirtschaftsinformatik, bin dann lange ins Ausland gegangen, nach England.
War fünf Jahre in England, habe dort dann eher Bioinformatik gemacht, war dann in der Schweiz.
Und als ich zurück nach München gekommen bin, war ich zuerst in einer Parallelfirma zu HelloTest und bin dann irgendwann operativ rübergegangen und habe dort die Rolle als CTO gewonnen.
Sehr gut.
Was macht denn HelloTest eigentlich?
Wir wollen keinen HelloTest-Werbe-Podcast machen, aber du darfst natürlich trotzdem ein paar salbungsvolle Worte über deinen Arbeitgeber sagen, was ihr macht und wofür ihr bekannt seid.
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.
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 in Erinnerung habe.
Wie viele Rollen waren das bisher?
Ja, ich habe das in der Schweiz, die technische Leitung gehabt in der Kommunikationsagentur.
Das war ein sehr kleines Team.
Gab es da einen bestimmten Moment 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, an den du dich rückerinnern kannst oder der sich in dem Moment dann auch so angefühlt hat?
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 die übergeordnete Rolle.
Im Austausch mit Kunden, aber natürlich auch im Austausch nach innen hinein in das Team.
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 gewehrt?
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?
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 darunter 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.
Hast du das von Anfang an wirklich auch so wahrgenommen und gefühlt?
Oder warst du auch nochmal eine...
Nein, das ist dann mit der Zeit gekommen.
Am Anfang versucht man natürlich auch noch überall seine Finger mit drin zu lassen, in Anführungsstrichen.
Aber man kommt dann zu einem Punkt, wo man merkt, dass es einfach nicht geht.
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 in Produktentwicklung reindrängt.
Wie nimmst du das am stärksten wahr?
Vielleicht auch an dir oder auch an anderen CTOs, die du kennst?
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, spezialisiert werden und entsteht weiter hinten, wo QRA stattfinden soll, wo das Ganze dann ins Endprodukt reinfließen soll.
Der Mittelteil, der dazwischen klassischerweise eigentlich das Bottleneck war, gibt es eigentlich nicht mehr.
Also es hat sich in die beiden äußeren Teile verschoben.
Wieso war das vorher ein Bottleneck?
Es gab immer viel zu viele Ideen eigentlich, um sie umzusetzen.
in so Startups wie wir es waren, war das eigentlich immer der Fall.
Vielleicht nochmal kurz zurück zu HelloTest.
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 sagen, ja, was ist denn da so schwierig da drin?
Da hast du eine App, um das zu machen.
Und ja, wo ist da die Komplexität?
Also auf der einen Seite ist, haben wir als Kassensoftware gerade in größeren Umgebungen einen sehr hohen Integrationsfaktor.
Also wir sind sehr tief in den Umsatzsystemen 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 es egal, ob das Zahlsystem nicht funktioniert, ob die TSI nicht funktioniert, ob irgendwas drumherum nicht funktioniert.
Die Kasse funktioniert nicht.
Und deswegen muss ein Kassesystem sehr resilient aufgebaut sein, dass es 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.
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 reibungslos funktioniert.
Also wo ist der Unterschied im gastronomischen Bereich?
Oder vielleicht nochmal der eine Aspekt, den es dann besonders macht.
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.
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.
Deutet 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?
Genau, also der Ansatz von unserem System ist, dass wir eben, obwohl wir eine cloudbasierte 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 rein synchronisieren.
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 1000 Essen ausgegeben werden an unterschiedlichen Kassen.
Wenn es dort zu Netzwerkschwankungen kommt, dann ist es unserer Kasse erst mal egal.
Es wird dann einfach nachgesendet.
Also das ist etwas, was wir sehr früh und sehr tief ins System eingebaut haben.
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 der dann irgendwo an?
Ja, also der ruft bei uns das 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 dem LTE-Router auch kleinere Venues online bringst oder eben direkt das iPad online bringst über eine LTE-Karte.
Das 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.
Aber völlig nachvollziehbar.
Wohin steht denn der eigentliche Mehrwert 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?
Also ich würde sagen, dass es die Integrationstiefe und auch das Domänenwissen ist, was unsere Software stark auf den Markt macht und die uns 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 eine Kasse stehen haben, die auf einmal kein mehrwertsteuerbasiertes System haben, sondern ein netto basiertes System, wo die Steuer aus dem E-Mail drauf gerechnet wird.
Das sind alles Herausforderungen, die dann natürlich auch bis hinein in die Software spielen.
Okay, das ist interessant.
Das heißt also, du bist mittlerweile auch richtig Domain-Experte in diesem Gastro-Bereich und in den letzten zehn Jahren geworden ein Experte darin.
Ja, ein bisschen.
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 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.
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 Softwareentwickler-Team abbilden.
Dies dann bereits bei uns im Produkt, also unser Produkt ist aufgeteilt in unterschiedliche Repositories.
Dort haben wir das dann in unterschiedliche Repositories eingesetzt, sodass wir schon einzelne Agenten verwenden konnten, um zum Beispiel Spezifikationen für unsere Features über diese Agenten schreiben zu lassen.
Ich bin dann, so April, irgendwann des Jahres, durch einen anderen Kollegen auf Paperclip aufmerksam geworden und hatte dann eben die Idee, dieses BeMate-Framework, was es gibt, in Paperclip zu integrieren, sodass die Agenten, die ich mir in Paperclip erstelle, also Paperclip ist aufgebaut wie eine Softwareorganisation, du startest eigentlich mit deinem CEO und führst dann einen Hiring-Prozess durch.
Dieser 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 bauen lassen, 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.
Kannst du uns kurz erklären, was die BIMIT Method ist?
Ich glaube, die allerwenigsten wissen genau, was damit anzufangen ist.
Die BIMIT Method ist ein Open Source Projekt, in dem Agenten und auch Workflows erstellt werden, die dann toolagnostisch laufen können.
Also man installiert sich das in seinen Repository hinein und kann dann überlegen, mit was man eben arbeitet, ob man...
mit Codex Cloud oder OpenCode 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 ein Artefakt, einem fest definierten Verzeichnis innerhalb vom Repository.
im Anschluss weitere Agenten drauflaufen 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 da drin ein Epic definiert haben, mit einem UX-Mograb, 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 also Agenten schreiben lassen, die dann dieser BMED Method folgen und genau auf diese Sets zugreifen, die dann im Source Code liegen.
Das heißt, wenn du diese, also du hast gesagt, es sind sechs oder sieben verschiedene Rollen bei BMED?
Welche sind das dann?
Die wichtigsten oder die ich am wichtigsten finde, ist der Product Honor UX Entwickler natürlich, den gibt es dann zweimal, ein Test Agent und noch ein Scrum Master.
Ich nehme eigentlich die fünf.
Warum gibt es den Entwickler zweimal?
Mehr Durchsatz zu kriegen oder hat das eine spezielle Bedeutung?
Nee, den kannst du leicht unterschiedlich starten.
Ich weiß jetzt auch nicht, ob es in der aktuellen Version immer noch so ist von Bmed, aber den kannst du leicht unterschiedlich starten.
Einmal, dass er es schreibt.
Und einmal, dass er mit einem anderen Model den Review macht.
Also, dass wir zum Beispiel mit Codex schreiben und mit Claude Review oder andersrum.
Ah, okay.
Also, du hast im Endeffekt da vorgesehen, dass mit eigentlich einer ähnlichen Rolle, aber unterschiedlichen Modellen gearbeitet wird.
Ja, genau.
Das ist interessant, wenn ich an der Stelle dann mal einhacke, weil ich habe ähnliche Experimente gemacht.
Ich habe nicht die BIMIT-Method genommen, sondern ich bin...
Ich habe von vornherein ein Zielmodell im Kopf gehabt.
Ich wollte CEO, CTO, CPO.
Ich wollte, 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 hirn, so wie du das gegeben hast.
sondern habe das gleich über Cloud Code versucht zu orchestrieren.
Da habe ich 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 habe 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, möchte eine digitale Organisation abbilden oder die möglich machen.
Und ich verstehe Paperclip als ein Orchestrierungslayer, mit dem du allerhand Sachen machen kannst.
Den Agenten kannst du alle möglichen Modelle zuweisen.
Du kannst ihnen sogar quasi einen OpenClaw mitgeben, wenn du das möchtest.
Ich bin auch übrigens auf die Idee dann irgendwann gekommen, 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, da vielleicht noch ein bisschen Kontext zu schaffen.
Also es gibt, du hast mit B-Method gearbeitet.
Ich habe das Ganze über einen anderen Weg reingebracht.
Paperclip 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?
Naja, wie du es eingangs gesagt hast, ich habe das Ganze als ein Greenfield-Projekt gestartet mit einer Flutter-App.
Ziel der Applikation war, ich habe, 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 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 Paperclip 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 in UX und so weiter.
Ich habe dann diese 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 Mockup 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 Teil-Stories 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 Bild und zurückmergen konnte.
Das heißt, der Scrum Master hat die Stories gebaut?
Ja, das ist in B-Med so.
Da gibt es dann aber noch so einen Verification-Schritt, wo der...
wo der nochmal schaut, dass es eben umsatzbar ist.
Also die Rollen vom Scrum Master und Product Owner sind an der Stelle nicht ganz trennscharf.
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 von Scrum in einer agentic AI-Zeit infrage stellen.
Weil das nämlich auch sehr stark mit dem Engpass zu tun hat, warum man sowas wie Scrum überhaupt gebraucht hat und das jetzt immer obsolet wird.
Also warum brauche ich in einer agentischen Organisation einen Scrum Master?
Da gebe ich dir vollkommen recht.
Wenn ich es jetzt nochmal neu aufbaue, dann würde ich es auch nicht mehr reinnehmen.
Das ist vollkommen recht.
Aber das klingt bis hierhin ja schon mal sehr gut 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?
Ja klar, also da geht natürlich am Anfang geht alles schief, weil am Anfang gibt es vielleicht noch kein stringentes UX-Konzept.
Also jedes Epic, jeder Screen, der dein Vater gebaut wird, sieht anders aus.
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 ein, dass mal Riverport, mal ein anderes State Management verwendet wurde und so.
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 Cloud-Agents-MD-File im Repository anpassen soll und das als neue Guardrail reintun soll.
Und somit ist das Produkt eigentlich mit jedem Fehler, es ist wie ein Trichter zusammengelaufen.
Also es ist eigentlich immer stringenter wurde, was dann eigentlich entwickelt wurde.
Das finde ich hat sehr gut funktioniert.
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 Story schreiben und so weiter und so fort.
Mit welchem Token Spend bist du denn da rausgegangen?
Ja, ich wusste natürlich, dass die Frage kommen wird.
Deswegen habe ich mir mal ein Epic angeschaut.
Ja, da kann man sich auch festhalten.
Ich habe für ein Epic, was ein Plattendesign, also ein Deputierdesign umsetzt, etwa 230 Millionen Token verbraucht.
Holy shit.
Das sind ungefähr 6.000 Euro.
6.000 Euro.
Das ist natürlich, wir stellen natürlich die Sinnhaftigkeit infrage.
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 Ja, gibt es natürlich auch Überlegungen, das irgendwie so zu machen, dass es vielleicht auch, vielleicht sogar auf lokale Hardware läuft, weil die Zeit ist da eigentlich nicht die Issue.
Ja, da bin ich nicht sicher, ob das mit lokaler Hardware und mit lokalen laufenden Modellen dann am Ende des Tages besser wird.
Ich habe einen anderen Ansatz, bin ich tatsächlich gefahren, und zwar Ich habe den ganzen Braten von Anfang an nicht getraut.
Ich habe das gleich auch über die Anthropic API gemacht.
Das heißt, ich bin gleich auf richtig Token Spend 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.
Dann sage ich, das ist ja easy, das machen wir als allererstes mal.
So, dann bin ich aber rausgekommen und das Hello World Programm hat dann schon mal 4 Euro gekostet.
Aber ich sage, 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 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.
Also das sind halt die Learnings auf dem Weg dahin, wo du merkst, bevor ich irgendwie anfange, da ein größeres oder auch ein kleineres Produkt reinzukippen, möchte ich erst mal 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.
Und das sind Learnings in diesem Prozess, die mir dann gezeigt haben, 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.
Definitiv nicht.
Also das ist auch 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, sodass das eigentlich dann ein Prozess war, der kontinuierlich durchgelaufen ist.
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 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 Role 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, erst mal 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 welchen Stellen man ansetzen muss, um das überhaupt mal einigermaßen effektiv zu machen.
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 Flutter App, die du gebaut hast?
Genau, also ich habe das dann, ich habe...
Ich habe das Epic für Epic abgearbeitet, habe dann noch sogar Sachen wie Flagsmith und sowas mit eingebaut, dass es featurebasiert Sachen an- und ausgeschaltet werden kann.
Und dann war wirklich der längste Prozess in dem Ganzen, oder der, der eigentlich am stagnierendsten war, war App Store und Play Store Submission.
Das hat, das war ein...
der manuelle Prozess auf der einen Seite, der wirklich lang gedauert hat.
Länger als normal oder weil Sie mittlerweile viele Guardrails haben, um irgendwie AI-generierten Code abzufangen oder ist das im normalen Rahmen lange gedauert?
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.
Hast du Probleme gehabt mit Guardrails?
Also ich habe ja auch ein bisschen was von meinen beschrieben.
Hast du mit deinen Guardrails von den jeweiligen Rollen Probleme gehabt, dass die die nicht richtig eingehalten haben oder hast du es gleich von Anfang an besser gemacht?
Das kann ich so nicht sagen.
Also es gab ein...
Aber das war ein Fehler von mir.
Ich habe irgendwann das Repository umbenannt und die haben, manche haben wieder angefangen, ins alte Repository zu subwenden 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.
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 Anfangsgrad, dass eben was Unit-Tests und auch visuelle Tests eigentlich direkt betrifft, dass die direkt mitgeschrieben werden sollen.
Auch die Unveränderbarkeiten, das will ich davon.
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?
Also, was wirklich besser funktioniert hat im 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 Pre-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, um zu schauen, dass es richtig funktioniert.
Aber das hat dann sehr gut funktioniert.
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.
Interpretiere ich das richtig?
Ich glaube, ich habe insgesamt vier Versuche gemacht.
Der vierte Versuch von der Organisation war dann der, den ich dann auch verwendet habe und den ich jetzt auch noch weiter habe.
Inzwischen waren es halt, also ich würde sagen, vielleicht war es, War es ein Wochenende, das ich da verbracht habe?
Also das ist halt ganz stark learning by doing, 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.
Also mit dem, was es schreibt, 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.
Ja, es ist immer ein bisschen viel geworden.
Ja.
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?
Also, wir verwenden es in einem ganz, oder ich habe es jetzt bei uns, bei HeloTest, in einem ganz engen Kontext auch in die Organisation gebracht.
Ich habe eigentlich ein sehr ähnliches Setup wie für das Hobby, das ist oft mit Mini aufgesetzt, mit ganz strikten Zugriffsberechtigung, auch oft nur die zwei Repositories, die auch bearbeitet werden sollen, mit einem dedizierten Benutzer, der wieder auch suchrechtlich 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.
Siehst du da 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?
Du sprichst jetzt wahrscheinlich auf das Verhältnis mit wie viel Zeit braucht der Entwickler, um den Code zu prüfen, der geschrieben wurde, autonom gegenüber dem, als wenn er selber...
Ja und nein, es geht halt darum, Also ich habe mir auch die Frage gestellt, ich sehe, dass ein, wenn du Cloud 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 im Hintergrund passiert.
Natürlich bist du das immer noch irgendwie, hast du gefühlt sitzt da einer im Driver Seat, der Engineer, und der steuert das, was da passiert, durch seine Eingaben.
Aber am Ende des Tages, was Fable oder Opus im Hintergrund macht, ob die nochmal andere Agents oder Running Tasks halt irgendwie instanziieren, 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 er 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 Organisationen, 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 ausgereift 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?
Ja, ich weiß, was du meinst.
Also sicherlich, wenn der Entwickler näher in dem Code ist, kann er natürlich sicherlich 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 wurde, dass sie auch agententaugig ist, in dem Code drin ist.
dann 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 losgelöst stattfinden und der Real-Entwickler schaut dann auf den Pull-Quest.
Siehst du das bei euch auch, die Arbeit an...
bestehenden Produkten übernehmen oder nur Greenfield?
Also am bestehenden Produkt, ich meine, wir sind ein Legacy-Produkt, oder was heißt Legacy-Produkt?
Und es gibt 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 Fiscalisierung oder sowas hineingehen, da...
weiß ich jetzt nicht.
Also da sehe ich jetzt das Full-Logent-Decoding nicht.
Es gibt aber Randbereiche, da sehe ich es 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 draufschreiben lassen, die einfach den Status Quo mal festhalten.
Ob der jetzt richtig ist oder falsch, ist total wertfrei.
Aber das ist einfach, dass wir dann in der CECD Pipeline, dass wir dann einfach mal sehen, wenn etwas gravierend ändert.
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 Backlog erstellen lässt.
Reverse-engineert auf Basis der eigentlichen Codebase.
Und das dann mal dagegen mappt gegen das tatsächliche Backlog, um überhaupt mal aufzugreifen, 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.
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, 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 ja schon so weit seid.
Aber siehst du eine ähnliche Entwicklung oder denkst du, dass die Engineers in den normalen Teams, dass das die Organisationsform der Zukunft ist?
Also ich gehe jetzt auf den Punkt mit dem schnellen Wechsel des Toolings.
Das ist einer der Gründe, wieso wir uns für BMAT entschieden haben, weil die Definitionen, die stattfinden, die Epic-Definitionen und auch die Implementierungs-Artefakte weiterhin im Code leben.
Als wir angefangen haben, hat jeder von unseren Entwicklern einen Cursor verwendet 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 der...
Agent in Paperclip gebaut hat, kann es mir auschecken und kann in Curse oder Code 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 dem 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 es sich technisch ändert, es kann sich auch schnell ändern, weil vielleicht Zähl abgeschaltet wird oder weil es zu teuer wird oder weil es gibt tausend Gründe.
Sehr guter Punkt.
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, machst du eigene Reviews nochmal, hast du andere Metriken, die du verwendest?
Also ich gucke primär auf das Dashboard in Paperclip.
Wir haben jetzt für uns, für die Heli-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 Paperclip ü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.
Ja, definitiv.
Also ich überwache Paperclip an der Stelle ein bisschen, die Agenten und ansonsten ganz klar über die Diffs.
Also über das, was an Artefakten entsteht.
sowohl an Spezifikations-Artefakten als auch an Code-Artefakten.
Was habt ihr für ein AI-Token-Spend im Monat?
Oder beziehungsweise, ich weiß nicht, ob das jetzt, wenn du alles über Subscription machst, obwohl doch, was ist der Token-Spend?
Das wüsste ich jetzt nicht.
Das wüsste ich jetzt nicht.
Ich muss ganz ehrlich sagen, das weiß ich jetzt gar nicht.
Also weil es alles da drin läuft.
Okay.
Ja, die Kosten sind natürlich interessant.
Wenn es aktuell nur über Subscription geht, dann funktioniert das jetzt noch.
Die Frage ist, wie verschiebt sich das, wenn genau das 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.
Genau, aber an der Stelle ist es eben auch so, dass wir eben auch schon mit lokalen Gegebenheiten experimentieren, ob das nicht vielleicht auch eine Möglichkeit ist.
Was ist denn die wichtigste Lektion, die du bisher aus deinen bisherigen Paperclip-Experimenten gezogen hast?
Wichtigste Takeaway ist vielleicht, dass man es wirklich als Side-Project 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 Punkt.
Wir haben jetzt sehr viel über Paperclip gesprochen, was am Ende des Tages ein GitHub-Projekt ist, das man verwenden kann.
Hast du schon mal geguckt, ob es da Alternativen gibt, die dich interessieren, mit denen du vielleicht sogar das vielleicht nochmal starten würdest from scratch?
Würdest du irgendwas anders machen oder würdest du wieder Paperclip nutzen?
Also im Moment habe ich nicht wirklich links oder rechts geschaut.
Also es gibt sicherlich andere, aber wie du vorhin schon gesagt hast, das Tooling ändert sich so schnell, dass es auch ein Produktivitätskiller ist, immer nach dem Neuesten zu schauen und immer versuchen, den Neuesten hinterher zu jagen.
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, AWS sogar.
Und dann denke ich mir auch, 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?
Ja, wahrscheinlich eben, wie gesagt, er sollte vielleicht ein eigenes Team sich mal aufbauen, um in einem eigenen...
um mit einem eigenen Team vielleicht mal ein Seitentrojekt sich aufzubauen.
Jetzt haben wir am Schluss ein paar Internetprobleme, merke ich gerade.
Warum auch immer.
Wir kommen aber auch sowieso schon zu einer der beliebten Kategorie 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.
Ein Dirigent, der meine Agenten...
zusammenspielen lässt, anstatt dass jeder Entwickler solo spielt mit denen.
Hätte ich nicht besser formulieren können, gefällt mir.
Größter Produktivitätshebel durch AI-Agents?
Dass der Weg zwischen oder die Fleißarbeit zwischen der Idee und dem laufigen Stand kleiner wird.
Okay, sehr gut.
Größtes Risiko bei autonomer Entwicklung?
Das ist, wenn plausibler Code entsteht, der aber niemandem auffällt, weil er irgendwie Zwar plausibel ist, aber nicht richtig funktioniert.
Ja, das ist bei mir schon mit ganz vielen Unit-Tests so gegangen, 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, habe das an einem Abend irgendwie schnell gemacht und habe 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 mich jetzt hier noch weiter um Kopf und Kragen rede.
Ein Prozess, den du nie wieder komplett manuell machen willst?
Der Weg von der Spezifikation zu einem Erstzustand von einer Art Produkt.
Dass man diesen Weg komplett verquitzt oder ausschließt.
Sehr gut.
Und eine Fähigkeit, die jeder zukünftige CTO lernen sollte?
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.
Also ich denke, wir schreiben so viel schneller, so viel mehr Code.
Die Möglichkeiten sind da, es ist unrealistisch anzunehmen, dass das haltbar ist.
Ich glaube, es ist jetzt ja noch nicht mehr haltbar.
Aber bei so einem Review kann ja auch sein im Produkt selber.
Muss ja jetzt nicht auf der Code-Basis sein.
Das kann ja auch einfach im Produkt selber sein.
Und du kannst ja auch Agentic Helferlein 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 es gibt 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.
100%.
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.
Tschüss.
Gerne, ebenso.
Mach's gut.
Ciao, ciao.