KI-Widerstand, Audience of One, Product Engineers

Robert: Hallo zusammen bei AI und jetzt. Heute bei mir zu Gast ist der liebe Stefan. Hallo Stefan, grüß dich.

Stephan: Hallo Robert, grüß dich.

Robert: Wie geht's dir?

Stephan: Mir geht's gut. Wenn ich rausgucke, blauer Himmel, Sonne scheint. Bingo.

Robert: Das ist doch der Hammer. Bei mir genau das gleiche. Wir kommen aus einem langen, langen Winter. Jetzt der letzte Schnee geschmolzen und jetzt hat es 20 Grad, das ist alles total verrückt. Du, wir wollen ja nicht über das Wetter reden. Wir wollen über, ja, worüber wollen wir reden? Über AI auf jeden Fall. Aber ich wüsste gerne erstmal, wer du bist, wo du herkommst. Viele Hörerinnen und Hörer kennen dich wahrscheinlich unter dem Titel The Amazing CTO. Du hast ein Coaching-Programm, du bist Coach für CTOs. Du machst ein Newsletter mit dem gleichen Namen. Magst du kurz uns eine kleine Hafenrundfahrt geben?

Stephan: Oh, Hafenrundfahrt. Hafenrundfahrt und Wetter. Erinnert mich, ich war mal in Hamburg mit einer Frau und da waren bei einer Hafenrundfahrt, dann hat es angefangen zu schneien, dann sind alle unter Deck gegangen, außer uns, und dann war der Schneebecom. Hafenrundfahrt.

Stephan: Ja, ich habe 1981 angefangen zu programmieren. Ich wollte Videospiele programmieren. Ich wollte die Videospiele programmieren, die ich im Kopf hatte. Und da musste ich Programmierer werden, um die zu spielen. Und dann bin ich Programmierer geworden, habe mir Programmieren beigebracht, habe mal Videospiele geschrieben.

Stephan: Und dann, ohne großen Erfolg, Mitte der 80er war kein Internet, Limited Distribution. Ich habe es in ein paar Zeitschriften geschafft, aber das war es dann auch schon. So zum Abtippen. Und bin dann während des Studiums in Startups gerutscht, wusste gar nicht, was Startups sind. Bin da irgendwie reingerutscht in ein Startup. Bin dann sehr, sehr schnell in Engineering Management Rollen reingerutscht und war dann 25 Jahre Engineering Manager. Bis zu dem Zeitpunkt, wo my friend your startup verkauft hat.

Stephan: And then I said, I have a CTO, war CTO, war Engineering Manager. Ich mache jetzt CTO Coach und mache jetzt seit, ich weiß nicht, eight years or so was CTO-Coaching und helfe CTOs mit allen ihren Problemen. Und das sind aktuell in großem Maße und großem Umfang AI und die Anwendung von AI in der Softwareentwicklung.

Robert: Wie wir uns wahrscheinlich alle denken können, das treibt die Damen und Herren CTOs wahrscheinlich gerade alle um. Mindestens um, wenn nicht auf die Palme, oder? Ja, also auf jeden Fall.

Stephan: Die sind, kriegen sehr viel Druck vom CEO. Da wird immer gefragt, wie viel Prozent unserer Zeilen-Code machen wir denn mit AI schon und so. Das einzige, was sozusagen der CEO da immer mitnimmt aus der öffentlichen Diskussion, wenn er hört, dass Microsoft 50 Prozent und Meta 80 Prozent oder so, das kommt beim CEO an. Und das gibt der CEO natürlich dann als Talk beim CEO weiter.

Stephan: Und mit den Entwicklern gibt es manche Entwickler, die eben sehr, sehr Garn-AI machen, superfunne dabei sind, sehr, sehr viel ausprobieren. Und es gibt aber eben auch sehr viel Resistance und sehr viel Chaos und wenig Plan und in diesem Umfeld bewegt sich so der CTO.

Robert: Das ist auch meine Wahrnehmung. Interessant, dass du das auch so siehst. Also bestätigt meine Wahrnehmung so total. Sag doch mal aus deinen Gesprächen mit den CTOs.

Robert: Was sind denn so, wissen die eigentlich noch, wo oben und unten ist? Haben die in der Mehrheit schon vielleicht eine klare Fahrtrichtung oder auf diesem Spektrum irgendwas dazwischen? Wo stehen die denn so mehrheitlich? Kannst du dazu was sagen? Darfst du dazu was sagen?

Stephan: Solange ich keine Namen nenne, darf ich, glaube ich, schon was sagen.

Stephan: Ich würde sagen, die CTOs stehen alle sehr confused herum. Sie sind sehr, sehr viel am Experimentieren, also was funktioniert, was funktioniert nicht. Die wenig aktiv gesteuert, würde ich sagen. Mehr die Entwickler machen lassen, was sie wollen. Generell so ein bisschen vielleicht Hackathons, Workshops, Trainings. Ich bin auch, ich mache auch, ich habe so einen Vortrag, der heißt AI is not software, den ich mit dem kostenlos durch die Lande tingeln und bei Firmen halte, um Entwicklern zu zeigen, wo es eigentlich hingeht. Weil ich glaube, das hat noch keiner so auf dem Schirm, wo es eigentlich hingeht. Und die stehen so ein bisschen confused rum, wird viel experimentiert. Manche haben einen Plan, ich versuche auch mit allen Coaches daran zu arbeiten, zu sagen, aus meiner Sicht braucht ihr eine Vision und einen Plan, wie ihr da hinkommt. Und das haben die meisten nicht. Ich hatte letztens mit einem in die Diskussion auch. Stefan, wie viel Prozent sollten wir denn jetzt machen? Das IGU sagt immer, wir brauchen AI-Prozent-Code, AI und so, 70 oder 80, 60, 70, 80, was soll man machen? Sage ich, es gibt für mich nur eins, das ist 100% AI-Written Code. Und die Frage ist nur, wie kommt ihr da safe hin?

Robert: Das ist für mich die Frage nicht, ob 70 oder 80. Das ist, würde ich sagen, mal so zusammenfassen, wo CTOs heute stehen. Ich hole noch mal kurz die Hörerinnen und Hörer so ein bisschen rein. Wir reden hier natürlich über Engineering-Abteilungen oder ganze Companies oder Teams. Und damit meinen wir natürlich die sogenannte Softwareentwicklung. Und jetzt gibt es mittlerweile auch richtige Begriffe für das Thema, über das wir heute sprechen. Das nennt sich Agentic Engineering. Manche nennen es Agentic Software Engineering, also die Softwareentwicklung mit der Unterstützung von Agenten, KI-Agenten. Diese Unterstützung von ist ein Spektrum von wir lassen die Dinger mal machen und drücken Ja, nein, ja, nein, du darfst, bis hin zu, wir geben einen umfangreichen Plan, eine Idee rein, was auch immer, und lassen die hoffentlich iterieren und nicht einfach nur so einen Zero-Schuss produzieren. Und das kann mal über Nacht laufen, das kann auch Tage laufen, das kann Stunden laufen. Und auf diesem Spektrum bewegt sich dieses ganze Thema des Agentic Engineering. Und da hast du, Stefan, ja gerade einen Einblick gegeben, was die CDO so umtreibt. Jetzt hast du gesagt, du siehst alles in deiner Arbeit. Du siehst die Entwicklerinnen und Entwickler, die sofort dabei sind, die richtig brennen, dafür wahrscheinlich. Du siehst die WiderstandskämpferInnen. Die sehe ich übrigens auch. Vor zwei Jahren gab es so ein Hashtag ResistAI im Internet. Ich weiß nicht, der ist mittlerweile umbenannt worden oder hat sich irgendwie verselbstständigt. Es gibt definitiv so ein WiderstandskämpferInnen-Lager. Und dann gibt es die People in the middle, über die ganz wenig gesprochen wird, die ich aber total interessant finde, weil ich glaube, dass man die ja gewinnen muss und gewinnen will. Hast du da schon Ideen, wie man das tun kann?

Stephan: Also die Schwierigkeit, die ich feststelle, oder mein aktuelles Denkmodell hat zwei Hürden für den Entwickler. Und die erste Hürde, würde ich sagen, ist die einfachere Hürde. Die erste Hürde ist, dass der Entwickler, je mehr Geld er verdient, aktuell nicht weiß, wie er das gleiche Menge Geld verdient in einer AI-Zukunft. Also, wenn er dafür Geld verdient, that he 10 years long er zehn Jahre lang Erfahrung hat, wie man Software baut und wie man Architektur macht und wie many waitbare und sichere Software schreibt, dann ist ihm not clear, wie er 120.000 Euro im Jahr verdient, wenn AI das gleiche macht. Oder when a junior entwicker with AI the gleiche machined as a senior entwickler with AI. This is, würde ich mal sagen, this is an einfachere Problem, aber ein sehr materielles, klares Problem, wo ist mein Wert eighteen in this AI-Zukunft? Und da geht es darum, dem Entwickler aufzuzeigen, oder Entwicklerin, ich bin zwar alt, ich bemühe mich.

Robert: Also jeder wie er will.

Stephan: Nee, das ist mehr so geistige Faulheit manchmal.

Stephan: Also Entwickler und Entwicklerinnen, aufzuzeigen, wo es hingeht, und die ist falsch natürlich, meine geistige Faulheit, möchte ich es nochmal klarstellen. Wo es hingeht und eine Zukunft aufzuzeigen, eine goldene Zukunft aufzuzeigen, in der sich alle wiederfinden können. Das ist der eine Teil.

Stephan: Die schwierigere Hürde, würde ich sagen, tut sich auf, indem sich Entwickler und Entwicklerinnen in zwei Lagerspalten finden. Und zwar in das Lager der Coder und in das Lager der Creator.

Stephan: Und der Creator besiegt, sie sieht Software, Entwicklung, Coding als Werkzeug etwas zu schaffen. Und der Coder sieht Softwareentwicklung und Code als Wert an sich. Also es geht darum, Code zu schaffen, und für den anderen, für die andere Person geht es darum, Dinge zu erschaffen mit Code. Und Leute, die Dinge schaffen wollen, also die sich als Creator sehen, haben keine großen Probleme in die AI zu wechseln. Die sagen, oh, toll, stärkeres, machtvolleres, größeres Tool, klar. Vom Handbohrer zur Bohrmaschine, natürlich. Und der Coder, der die Handbohrmaschine mag, der hat die Schwierigkeiten, dieses Tool zu wechseln. Das würde ich mal, sonst die zweite Hürde.

Robert: Ja, das kann ich unterschreiben. Das sehe ich sehr, sehr ähnlich. Wenngleich die Realität natürlich oft sehr viel komplexer ist.

Robert: Die Frage, die sich mir stellt, ist: Wie kriegen wir denn jetzt die Leute, die noch am Code hängen? Der Code nicht nur als Artefakt, sondern als handwerkliches Erzeugnis der eigenen Arbeitskraft, der eigenen Kreativität. Wie kriegen die wir die in diese Creator-Rollen? Müssen die jetzt alle Product Engineers werden? Das entstehen ja, glaube ich, gerade ganz viele Begriffe, ne? Es gibt ja auch dieses schöne Zitat, dessen Zitatgeber ich mir nie merken kann, weil ich nicht so gut mit Namen bin. Wo neue Sprache entsteht, wo neue Begriffe entstehen und wo sich Anwälte tummeln, da wird die Zukunft gebaut. Ich könnte sagen, hier wird die Zukunft gebaut. Aber wie kriegen wir die Leute da hin, die noch am Code hängen, die generell am Code hängen, für die das schon ein Karriereinhalt, mindestens, wenn nicht ein großer Lebensinhalt ist?

Stephan: Also, was ich vorher sagte, gilt schon. Also, man muss den Leuten eine vision aufbauen, in der sie sich sehen können. Eine Zukunft, in der sie sich selbst sehen können. Man muss aber aus meiner Sicht auch den Leuten klar machen, und es klingt so hart, aber den Leute, die Leute mitnehmen und erklären, dass manuelle Schreibmaschine eine tolle Sache sind, aber für die meisten Leute einfach nicht das richtige Werkzeug.

Stephan: Für die meisten Leute ist, wenn sie ein Buch schreiben wollen, Word mit einer Rechtschreibkontrolle das richtige Werkzeug. Und wenn du vielleicht Stephen King bist, dann kannst du wahrscheinlich eine manuelle Schreibmaschine verwenden, wenn du den Brand hast. Aber für die Masse ist es das eben nicht. Und davon müssen die Leute sich, müssen die Entwickler einfach verabschieden. Ich glaube, da führt kein Weg drumherum. Jetzt sehe ich in manchen meiner Kunden, dass Mitarbeiter des Unternehmen verlassen, weil der CTO AI pushed, weil sie am Coding hangt. Und ich mag ja auch Coding, ich kann es schon irgendwo verstehen, aber am Ende führt da, glaube ich, kein Weg dran vorbei, das aufzugeben. Und die Rolle, die sich danach entwickelt, ist unklar. Ich würde auch aktuell zu Product Engineer tendieren, am meisten. Aber ich glaube, es ist aktuell unklar, wie die aussieht. Man darf an dieser ganzen Rolldiskussion bloß nicht vergessen, dass als das Internet kam, vor dem Internet, also in den 90er Jahren, die Software-Entwicklungsrollen auch alle anders waren. Ja. Aber da gab es sowas wie Reak Requirements Engineers. Da gab es alles voller Tester. Und es gab keine Produktmanager und es gab eher Program Manager als Strukturmanager. Das heißt, wir hatten schon mal vor 20 Jahren einen Riesenumbruch und da sind alle Rollen durcheinander gewusst worden. Konnte keiner nach vorne gucken, ich glaube, sowas haben wir heute auch. Und um den Kurve zu kriegen zu deiner Frage, zu dem Teil einer Frage, wie kriege ich die Leute da mit? Ich finde es sehr, sehr wichtig, das habe ich früher auch als CTO gemacht, dass Entwickler Anteil am Produkt nehmen. Wir haben so ein bisschen vielleicht im marxistischen Sinne die Entfremdung vom Produkt über die letzten 20 Jahre beim Entwickler gesehen. Gib mir ein Ticket, ich baue es dir. Und es ist, glaube ich, ganz wichtig, dass der Entwickler, die Entwicklerin am Produkt teil hat und Produkt Skills wirbt und Kreativität, die in jedem steckt, auch einsetzt. Und nicht die Kreativität nicht nur auf wie benenne ich jetzt diese Klasse reduziert.

Robert: Du hast es gerade marxistisch genannt. Meine Wahrnehmung ist, und ich hätte es so formuliert, ohne dir jetzt das marxistisch wegnehmen zu wollen, ich habe einfach gerade gar nicht den Raum in meinem Kopf, darüber nachzudenken, über das, was ich alles von dir lerne.

Robert: Meine Wahrnehmung ist, dass sehr viele Entwicklerinnen und Entwickler, besonders die, die sehr auch am Code hängen, an dem Code als Artefakt, als Handwerk, so ein gewisses betriebswirtschaftliches Verständnis, naja, ich vermisse es oft. Also, das, also, ich will jetzt auch nichts pauschalisieren, aber es ist schon eine Wahrnehmung von mir, dass gerade diese Menschen oft auch das, es glaube ich, gewohnt waren, in den ganzen letzten, in den, ich nenne es immer die fetten Jahre, so zu arbeiten, als gäbe es diese Randbedingungen nicht. Als müsste man, als könnte man endlos viel Detailarbeit investieren, als müsste man nicht fertig werden, jetzt extrem überspitzt formuliert. Siehst du wie siehst du das? Kommt das vielleicht daher, dass wir immer in den fetten Jahren viel zu wenig Entwicklerinnen und Entwickler hatten, die gepampert haben, die wir gute Gehälter gezahlt haben, weil alle von denen zu wenig hatten? Dann kamten auf einmal alle zu viel und dann kam AI. Wie siehst du das?

Stephan: Lot to unpack.

Robert: Dafür sind wir hier.

Stephan: Mein erster Reflex ist: sage ich immer, Zuckerbrot ist alle. Also, ich glaube schon, dass die dass die Zeiten vorbei, die Zeiten mit Entwicklerpampern vorbei sind. Punkt, erster Gedanke. Der zweite Gedanke. Ich glaube sogar eher, dass Entwickler unterbezahlt waren. Über die letzten 20 Jahre. Ich würde nicht sagen, die sind überbezahlt, sondern für das, was Entwickler als Wert schaffen, würde ich behaupten, sie waren irgendwie 20 Jahre unterbezahlt. Da könnte der Entwickler auch 500.000 Euro verdienen. Die Firmen, also in diesem Umfeld, jetzt nicht im deutschen Mittelstand, Handwork, oder wo ein Softwareentwickler sitzt, da wird das Geld nicht rein geholt. Aber in den Bereichen wo Softwareentwicklung Produkte, würde ich ja behaupten, die waren unterbezahlt. For that, was sie einen Wert haben, and man sagt immer so ein bisschen, ja, wir waren angewiesen auf Softwareentwickler. Ich würde es ja umgekretent sehen, die haben unglaublich viel Wert geschaffen. And deswegen wollte jeder welche haben. Und sie haben so viel Mehrwert geschaffen, dass man es ja am Ende auch pampern kann. Also, ich kann den Leuten eine Spezi-Kiste hinstellen und einen Kicker, weil die Leute so viel Wert schaffen. Und mein allererster Job, den ich angenommen habe, so kam ich in diese ganze Industrie rein, da war eine Stellenausschreibung, war drei Monate alt.

Stephan: Ich dachte, ich bewerbe mich trotzdem, wird jem. Wird immer gesucht, der Webseiten macht und Plattenbankprogrammierung und CGI und so. Also CGI im Sinne von Common Gateway Interface, nicht im Sinne von Computergrafik. Und dann war ich der erste Bewerber nach drei Monaten, weil Mitte der 90er waren diese Skills relativ wenig verbreitet. Und dann habe ich da angefangen, und in dem Rahmen war auch meine erste Tätigkeit, ein virtuelles Labor zu bauen. Da ging es darum, dass über eine Webcam ein Laborgerät beobachtet werden konnte vom Kunden und der konnte zugucken, wie seine Chemikalien da, wie seine Oligonukleotide hergestellt werden. Und ich hatte das sozusagen automatisiert, also Webfeed und man konnte übers Web eintippen, was man will, und dann würde es verpackt und gelabelt und so weiter und so fort. Und habe ich auch ganz gut verdient. Und da kam jetzt so die Erkenntnis, ja, der Labormitarbeiter kann jetzt die doppelte oder die dreifache oder die fünffache Menge an Maschinen bedienen und betreuen, als vorher. Ich habe die jetzt nicht arbeitslos gemacht in meiner Softwareentwicklung, aber ich habe verhindert, dass vier weitere Laborassistenten eingestellt werden. Also, und wenn ich mir vorstelle, was ich sozusagen der Firma dann an Wert geschaffen habe, also ich habe vier Gehälter eingespart, obwohl ich gut verdient habe, habe ich nicht das verdient, was ich der Firma gebracht habe. Und so würde ich das eher im Kontext sehen, dass einfach Softwareentwickler unglaublich viel Wert hatten in den letzten Jahren und eher unterbezahlt waren.

Robert: Würdest du sagen, wir haben da ein Schattendelta offen gelassen in den tatsächlich bezahlten EntwicklerInnen-Gehältern, zu denen, die sie eigentlich sein müssten? Und in dieses Delta rutschen jetzt die Frontier Labs mindestens, aber die AI-Companies rein mit ihren Token-Kosten. Ist das eine haltbare Hypothese?

Stephan: Hab ich so noch nicht drüber nachgedacht, aber ja. Also ich höre das über Token-Kosten. Also, einerseits macht der AI, und da bin ich fest schon überzeugt, das sehe ich bei mir sozusagen Softwareentwicklung viel, viel schneller und billiger.

Stephan: Ich kann heute am Tag ein Feature bauen, die Leute aus dem Coder-Camp sagen, ja, schlechte Code-Qualität und so. Aber ich kann heute halt im Plan an einem Tag ein Feature bauen, wo ich vorher fünf brauchte dafür. Also, es geht einfach sehr, sehr wieder effizient. Und wenn dann jemand sagt, ja, aber Tokenkosten, 1000 Euro Tokenkosten pro Entwickler pro Monat sind ja unglaublich viel Geld, dann denke ich auch in der Hinsicht wieder, genau, wie der Entwickler zu billig war. Eigentlich sind auch die Token in diesem Ansatzbereich zu billig. Aber möglicherweise, wenn ich natürlich jetzt irgendwie, weiß ich nicht, eine Studie schreibe oder irgendwas zusammenschreibe mit AI-Hilfe, dann sind potenziell die Token zu teuer. Für die Softwareentwicklung sind die Token potenziell zu billig, sind die gleichen Token.

Robert: Aber ja. Die sogenannte Token-Effizienz, ne, das wird auch noch ein großes Thema. Ich glaube, weil alle gerade natürlich sehr viel ausprobieren im Unternehmen. Mehr oder weniger im Schatten oder im Licht, ne? Schatten-KI ist ja auch ein großes Thema. Wie werden die Engineers mindestens, wenn nicht auch die anderen MitarbeiterInnen überhaupt ausgestattet, kriegen? Die AI-Subscriptions, eine sogenannte usage-basierte Flatrate. Da gibt es ja Produkte von OpenAI, Anthropic und Co.

Robert: Oder rechnen die alle nach Nutzung ab? Haben die ein fixes Budget pro Monat? Und wie wird das in Effizienz, also wie effizient wird das genutzt? Wann ist es keine Spielerei mehr? Wann schafft es tatsächlich einen Wert? Ich glaube, in diesem Dickicht, stehen gerade noch die meisten. Und dann kommt die Limited Distribution, die du erwähnt hattest, dazu. Wenn wir jetzt darüber reden, über persönliche Agenten für alle Mitarbeiter, ob das jetzt mit Open Claw, Nemo-Claw oder was auch immer ist, aber ich könnte, würde Jensen von der Nvidia zustimmen, wenn er sagt, dass jedes Unternehmen eigentlich eine Claw-Strategie haben sollte für die MitarbeiterInnen. Dass die mindestens einen persönlichen Agenten für ihre Arbeit bekommen. Aber was kostet das? Wie wollen wir das messen? Was messen wir da? Das stellt jetzt, glaube ich, alle so ein bisschen auf den Kopf, dieses Thema.

Robert: Wie siehst du das?

Stephan: Ich würde das auch so sehen.

Stephan: Rückgreifend auf das, was du vorher sagtest, zu wirtschaftlichem Denken der Entwickler. Ich hatte immer wieder die Diskussionen mit vielen Mitarbeitern an dem Grundprinzip, das Grundprinzip zu verinnerlichen, dass jeder Euro, der auf dem Lohnkonto landet, von dem Kunden bezahlt worden ist. Es sei denn, man verbrennt gerade, Bekannte hatte mal die Webseite burningbcmoney.de.

Stephan: Also entweder man verbrennt andere Leute Geld oder man muss halt das Kundengeld einsammeln. And that bedeutet that's by OpenClaw oder by the agent for the Mitarbeiter and the Kosten irgendwo muss das Geld herkommen. And jetzt kommt es entweder daher, dass ich as vielleicht intelligente Firma neue tolle Ideen habe, die ich umsetzen kann, um mehr Geld am Markt einzusammeln von Kunden.

Stephan: Meine deprimierende Hypothese is aber, nachdem ich viele, viele, viele, viele Firmen gesehen habe, dass die Firmen nie Softwareentwickler limitiert waren, sondern vielleicht eher gute Ideen limitiert waren. Von daher ist nicht ganz klar, wo die guten Ideen herkommen sollen. Weil wenn ich in so Backlogs reingucke, finde ich da nicht so viele gute Ideen. Und also entweder ich hole mir mehr Geld durch gute Ideen mit AI, oder ich werde zwangsleistend Mitarbeiter entlassen müssen. Das ist so, und das sieht man immer, wenn Firmen aus meiner Sicht Mitarbeiter entlassen, dann heißt es, ich bin Ideen limitiert.

Robert: Das ist sozusagen die Aussage, die die Firma trifft.

Stephan: Ich habe keine guten Ideen, ich entlasse Mitarbeitern. Aber irgendwo, entweder beim Mitarbeit entlassen, um für AI zu bezahlen oder mehr gute Ideen zu haben, um für AI zu bezahlen, irgendwo muss das Geld herkommen.

Robert: Das ist extrem interessant. Das erinnert mich so ein bisschen an die, nicht, dass ich unendlich viele Studien im Kopf hätte, die ich zitieren könnte, aber an die, mit der ich auch immer, wenn ich mit CTOs und Engineering Managern spreche, hausieren gehe, ist die Procter Gamble-Studie, die die Harvard University durchgeführt hat, mit dem Herrn Ethan Mollick, dem einen oder anderen sicheren Begriff. Da haben die sich ja nicht die Entwicklungsproduktivität angeschaut. Ich kann die sowieso nicht mehr hören, die macht mich wahnsinnig, sondern die Lösungsqualität in der Produktweiterentwicklung oder Neuentwicklung. Und da haben die eben Erkenntnisse gehabt, wie zwei Personen, eine Person mit KI ist genauso effektiv oder effektiver in der Lösungsqualität, in der Produktentwicklung, wie drei ohne. Und das sind interessante Studien. Und das müsste man, glaube ich, firmenintern wirklich auch anfangen zu messen. Was tun die Leute denn jetzt in der Lösungsqualität und in der Innovation? Und ich sage immer, die Innovation ist ja das, das wollen ja, glaube ich, alle. Das muss ja eigentlich jede Firma wollen. Egal in welchem Sektor man irgendwie arbeitet. Aber dafür muss Innovation kommt immer aus Daten, könnte man sagen. Auch jetzt werden viele gähnen, aber wenn die Unternehmensdaten, die spannenden, eben nicht zugreifbar sind für AI, dann verbrenne ich Tokens, Tokens, Tokens, Tokens.

Robert: Aber wenn die AI, die liebe AI nicht rankommt, dann haben wir eben ein Problem. Dann laufen wir Menschen immer noch weiter die Treppenmooren runter und copy-pasten irgendwelche Akten der AI auf den Tisch. Deswegen, ich glaube, die meisten werden auch überhaupt mal an ihre ganzen Datensilos und Datengräber ran müssen, um überhaupt über Lösungsqualität und Innovation zu sprechen, oder?

Stephan: Ja, ich habe ja auch ein kleines Tool, heißt Human. Die Webseite heißt GetHuman.sh, das sind Tool, um agent laufen zu lassen, aber ein wichtiger Aspekt von diesem Tool ist insbesondere auch, dass es verschiedenste Konnektoren hat für Gyra, für verschiedene andere Tracker, aber eben auch für Sentry, für Amplitude, für Figma. Die Idee ist, die üblichen Daten, Notion, die üblichen Datenquellen und Sachen anzubinden, weil ich glaube, dass es wichtig ist, da auch in der Softwareentwicklung in der Entwicklung Daten zu haben, um Sachen richtig zu entwickeln. Und da kommt ein anderes meiner Themen auf. Ich finde es sehr, sehr spannend, mit AI Sachen zu machen, die vorher nicht möglich sind. Ich finde es sehr langweilig, mit AI Sachen zu machen, die vorher möglich waren, jetzt mache ich sie schneller. Das interessiert mich nicht sonderlich. Was mich interessiert, sind Sachen, die ich vorher in der Softwareentwicklung zum Beispiel nicht machen konnte. Das bedeutet, in dem Moment, in dem ich ein Feature bauen lasse von einem Agenten bauen, kann ich den Agenten connecten in ein ins Live-System zu Performance-Daten der Anwendung. Und der Agent kann gucken, okay, in dem Umfeld so und so viele User, das sind die Datenbank-Latenzen und so weiter und so fort. Deswegen muss ich das so und so bauen. Etwas, was der Entwickler in der Regel nicht gemacht hat, wenn nicht vorher jemand das ins Ticket gepastet hat. Das heißt, man kann Sachen tun mit AI, die oder auf andere Datentöpfe zugreifen oder sowas, die vorher gar nicht möglich waren. Und das finde ich sozusagen spannend. Oder zum Thema Innovation, manche meiner Kunden machen das, ist eben jeden Tag ein Prototypen bauen. Ja, also sozusagen jeden Tag ein Prototyp. Also ich habe so eine kleine Startup-Modell, das heißt Prototyp, MVP, PMF, Traction. Und da ein Prototyp zu bauen, um Sachen, um Ideen auszuprobieren und zu visualisieren, was vorher viel saufwendig gewesen wäre. Da hätte ich gesagt, geht zum Entwickler, ich brauche einen Prototypen, mach mir mal einen oder mache einen Spike. Dann hat er gesagt, dauert fünf Tage. Dann hat der Produktmanager gesagt: Ach, fünf Tage für den Prototypen. Ich habe eh schon so eine volle Roadmap, mach mal nicht. Und heute kann ich mich einfach mich hinsetzen, kann der Produktmanager sich hinsetzen und einen Prototypen bauen. Ob der dann, wie man den dann in die Produktion kriegt, ist dann nochmal ein Prozesstechnisches Thema und ein Engineering-Thema und so weiter. Oder Responsible Engineering-Thema. Aber der kann einen Prototypen bauen, der kann Sachen machen, die er vorher nicht machen konnte, weil die Kosten zu hoch sind.

Stephan: Und das finde ich eben sehr spannend, Dinge zu tun, an diesen zwei Beispielen, aber es gibt noch viel, viel mehr Beispiele, Dinge zu tun, die vorher nicht möglich waren, ohne die AI.

Robert: Ich glaube, da brauchen wir aber speziell nicht nur die Engineers für im Unternehmen aus dem Engineering-Silo, sondern mindestens mal die Product-Leute aus dem Product-Silo.

Robert: Also die Silos müssen ja eingerissen werden, sollten, hätten sie schon immer gesollt. Aber jetzt, umso mehr, AI wirkt da, glaube ich, so als Beschleuniger. Denn wer soll den mit den Kundinnen und Kunden denn die fünf Prototypen, die ja über Nacht entstehen können? Da sind wir ja jetzt, da waren wir schon vor kurzem. Wer zeigt die denen denn? Wer trifft Entscheidend? Es wird ja alles immer, also die Last könnte man es negativ formulieren, oder der positive Druck wird ja immer höher. Deswegen, ich glaube, das übt auf alle extremen Druck aus und ich glaube, diese ganzen Silos müssen sich auch zusammenrotten und über die Silos hinweg das nutzen. Was nützt es, wenn Engineering da über Nacht irgendwie fünf Prototypen rausleiert oder der Product Manager es tut und der Engineer dann meckert, weil es Vibe-Gecodet wurde, dann sitzen doch wieder alle in ihren Silos und schimpfen über das andere. Ich glaube, das übt viel mehr Druck, sowieso auf alles aus, aber vor allen Dingen auf die lieben Silos, oder?

Stephan: Ja, es ist also schon so ein Run auf die Honig-Töpfe. Also ich sehe ja nicht nur den Produktmanager und den Engineer mit Cloud Code rumbasteln, sondern auch den CEO. Also der CEO sits in a meeting und macht irgendwas und zeigt an den Engineers, was er haben will. Also this run of the Honig-Töpfe, also sprich die Run of the AI, setzt ja auf allen Ebenen ein und in allen Bereichen ein. Und ich glaube auch aus diesem Run of AI and this wilde Durchwürfeln of Rollen.

Stephan: Also, also es ist mir unklar, oder aktuell glaube ich, dass der Software Engineer einen großen Vorteil hat, weil er, ich nenne es Trigger Words, weil er die richtigen Trigger-Words kennt, die die AI triggern, bestimmtes Verhalten zu zeigen. Und das ist aktuell aus meiner Erfahrung notwendig, um aus einem Prototypen ein Produkt zu bauen. Das heißt, ich habe Prototypen, ich will den in die Produktion bringen. Dann brauche ich bestimmte Trigger-Words, wie vielleicht Anti-Corruption-Layer und Abstraction-Layer und TDD und so weiter und so fort, mit dem ich bestimmtes Verhalten bei der AI triggere. Und der Produktmanager kennt diese Trigger Words nicht. Der kennt Product Management Trigger Words und der Marketing Mensch kennt Marketing-Trigger Words. Da sind wir aktuell. Deswegen glaube ich, für die nächsten fünf Jahre hat der Engineer noch ein gutes Auskommen, weil er diese Prototypen in Produktion bringen kann. Ich bin mir nicht sicher, wo wir in fünf Jahren stahen. Auch das wäre deswegen ein Aufruf an alle Entwickler, sich doch ihrer Kreativität hinzugeben, was Produkte bedeutet.

Robert: Ja, und die Erfahrung, die man hat, eben auch nutzen. Das ist ja weiterhin wertvoll, wenn nicht, viel wertvoller als jemals zuvor. Diese sogenannte Systems Engineering und Softwarearchitekturkompetenz. Die wird, glaube ich, extrem viel wichtiger. Nicht, dass das Wissen nicht auch in den Modellen drinstecken würde, aber ich muss eben wissen, dass ich darüber reden muss mit der AI. Entweder stelle ich Fragen dazu oder ich nutze sie eben, um kollaborativ nicht nur vom Prototypen dazu verharren, sondern den eben in unsere bestehenden Systeme zu kriegen. Und das ist eben, das haben ja viele Engineers, diese Erfahrung. Software-Architektinnen und Architekten haben die eben besonderen, auch hoffentlich hat man diese Rolle nicht karrieremäßig immer so geschnitten, wie ich es jetzt formuliert habe. Ich glaube aber, das wird wichtiger, denn sonst kommt, wie kommt man denn jetzt von diesem dieser Software, deren Code niemand zu 100 Prozent mehr liest, in ein System oder in mehrere Systeme, die in dem Unternehmen gut laufen können, die vernünftig angebunden sind, die passende Softwarearchitektur haben. Was ist denn die passende Software-Architektur für unser Unternehmen, für unsere Teams? Das kann die AI nicht wissen, wenn wir nicht wissen, dass wir mit ihr darüber reden müssen. Dann kann die uns auch helfen, das zu formen.

Robert: Du hast vorhin, das habe ich mir notiert, ja, darüber gesprochen, dass du gerade so einen Effekt siehst, dass viele Senior Developer gerade freiwillig gehen, weil sie keine AI nutzen wollen. Der Widerstand. Dann gibt es das Phänomen, dass Leute, die so in der stillen Mitte sind, sich eher einnisten und eher nicht gehen wollen, weil der Markt da draußen jetzt auch ein anderer ist als vor vielen, vielen Jahren. Und ich würde noch sagen, es gibt die Leute, die jetzt auch wegrennen, weil sie AI nutzen wollen, nicht, weil sie sie nicht nutzen wollen. Das hat Jeffrey Huntley, der den Ralf-Loop erfunden hat, ganz schön formuliert auf seiner, also ganz barsch formuliert auf seinem Blog vor ein paar Wochen. Wenn eure Firma ein AI-Budget, ein zweistelliges AI-Budget pro Monat für euch hat, rennt. Wie würdest du das formulieren?

Stephan: Ja, das ist natürlich mal die ewige Frage: Rennen oder verändern.

Stephan: Im Prinzip glaube ich, ja, also ich sehe auch, dass Leute, die mehr AI machen wollen, möglicherweise wechseln, wobei bei meinen Kunden jetzt so ist, dass eigentlich alle Entwickler ausprobieren dürfen, was sie wollen. Bezug Namen auf die CTOs von vorher. Ich muss aber auch sagen, meine Kunden sind alle in einem Rahmen von zwischen 5 und 80 Entwicklern. Ich habe ein paar Einzelkunden da oben drüber, mit ein paar hundert Leuten, aber so, das ist so mein, da wo ich mich am meisten auskenne, Startups, die wachsen. Und in dem Umfeld würde ich ja sagen, darf heute jeder probieren, was er will. Und wenn er sagt, ich brauche irgendwie 1000 Euro, wie auch immer das dann gehen soll. Also, es gibt ja Leute, die ja mehrere Cloud-Codes Max-Subscriptions haben, gleichzeitig, um den Token Hunger zu stellen. Ich glaube, das ist schon machbar. Also, aber ja, wenn das nicht machbar ist, ich würde mich auch als Entwickler, ich glaube, meine Zukunft als Entwickler hängt an AI und wenn meine Firma nicht ausreichend die richtigen Sachen macht, würde ich mich auch umgucken. Also von daher dem würde ich zustimmen. Vielleicht zu dem Resist nochmal ein ganz kurzer Moment. Ich weiß natürlich nicht jetzt, ob Resist moralisch richtig ist oder falsch. Also ich würde vielleicht trotzdem jedem Entwickler oder der Sachen, die mit AI macht, nochmal die Physiker nahelegen als Theaterstück und das nochmal zu lesen. All das, was heute letztlich mit AI auf dem Tisch kommt, ist eben schon nochmal zu genüge, vielleicht zur Genüge, vielleicht auch nicht, durchgekaut worden. Ich halte die Physiker immer noch für heute vielleicht für relevanter als in den letzten 30 Jahren, das mal zu lesen. Aber ja, die Leute, die, die gehen, sage ich dann immer, kann man machen, aber die Nische wird immer kleiner und die Inseln werden immer kleiner und die Inseln, die man suchen muss, werden immer weniger. Wenn man 50 ist, schafft man es vielleicht in die Rente. Wenn man 25 ist, schafft man es wahrscheinlich als Programmierer nicht in die Rente, also als jemand, der kodzentriert arbeiten möchte, nicht in die Rente.

Robert: Ja, ich glaube, es gibt auch gerade so viele so, was heißt Auffangbecken, ne? So Ausflüsse aus Firmen von Leuten, die keinen Bock darauf haben, die sich dann an Ausflüssen an anderen Seen oder Tümpeln tummeln, wo sie das so ähnlich Gesinnte sind, wo sie es vielleicht auch nicht müssen, wo das Projektgeschäft, wo das, wenn man denn Projekte macht, oder wo das Firmengeschäft da auch noch tickt.

Robert: Aber ich sehe es wie du, das ist, glaube ich, da läuft überall irgendwie die Sanduhr. Und wenn man über Firmen redet, die Projektgeschäft haben, dann muss man, glaube ich, auch gucken, wo sich das Projektgeschafft dann hin verlagern wird in Zukunft. Vielleicht in einen Kundenkreis, auf den viele, die eigentlich dahin geflohen sind, gar keine Lust haben, weil die auch alles andere verpennt haben. Also, das könnte ja auch so ein Strudel der Late-Docks.

Stephan: Das ist doch ganz schwierig. Also in der Zukunft. Ich habe die Diskussion auch mit ein paar von meinen Kunden, weil die sozusagen in der Zwickmühle sind, dass sie bisher die letzten 20 Jahre stundenbasiert abgerechnet haben. So, jetzt kommt die AI daher und jetzt dauert alles fünfmal kürzer, mal übertrieben gesagt. Woran auch immer man glaubt. Vielleicht ist es zweimal kürzer, vielleicht ist es zehnmal kürzer, aber sagen wir mal, zweimal kürzer.

Stephan: So, jetzt kann ich. Was mache ich denn jetzt? Jetzt billig dann nur noch die Hälfte aller Stunden? Oder versuche ich Wert zu verkaufen anstatt Stunden? Also in dieser Problematik befinden sich auch mehrere Männer Kunden. Also ins Projektgeschäft würde ich mich, glaube ich, nicht flüchten.

Robert: Da wird es wahrscheinlich noch schwieriger. Das ist zumindest sehr, sehr spannend. Ich glaube, sehr viele Geschäftsmodelle müssen sich jetzt einfach ändern. Wenn ich Projektgeschäft habe, muss es das. Wenn ich kein Projektgeschäft habe, muss es das, glaube ich, auch. Wenn ich irgendwelche Produktinnovationen mache, eigene Produkte oder Materialforschung, was auch immer, woran man arbeiten kann.

Stephan: Also für die Firme, die Projektgeschäft machen, ist super. Also SER ist super, aber für den Mitarbeiter, der quasi möglichst viele Stunden bilden soll, da wird es halt problematisch gleich.

Robert: Sag mal, wie siehst du denn überhaupt Teams in Zukunft? Du schreibst ja auf deinem Blog und in deinem Newsletter hast du den Begriff des Team of Two geprägt.

Robert: Wie siehst du das? Ist das der Weg für Engineering-Organisationen, jetzt deutlich kleinere Teams und vielleicht sogar Teams aus zwei Menschen zu haben?

Stephan: Again, much to unpack. Also potenziell kommt das Team of Two natürlich daher, dass ich als Kind Bud Spencer und Targanzell geguckt habe oder so. Und Tom und Jerry und uh jetzt, glaube ich, kein Team waren. Aber also da kommt das vielleicht her, der Gedanke trotzdem, die Frage stellt sich schon für mich immer, und die hatte ich letztes Mal mit dem Kunden lange durchdiskutiert: woher kommen denn Teams? Also warum will ich denn eigentlich Teams haben? Und das Softwareentwicklungsbereich hat potenziellen Teams of four to eight entwickers or sowas, würde ich mal sagen.

Stephan: Ach, it is as a team to teach them and a group of person. But in this bewaken. And I would mean that we Teams have this, einfach das, damit wir in einer Verantwortungseinheit, ausreichend große Aufgaben gemacht, die in einer reasonable Zeit abgearbeitet werden. Und deswegen habe ich im Prinzip Software-Teams. Dann habe ich fünf Entwickler, dann kann ich denen was geben und dann sind die in zwei Wochen fertig mit der Sache. Und ein Entwickler würde halt fünf Maße lang dauern, das dauert zu lang und so weiter und so fort. Und dann brauche ich, weil ich Teams habe, brauche ich irgendwie einen Tech-Lead, der die Leute da Tech-mäßig lead organisiert. Und ich brauche ein Team-Lead, kann auch die gleiche Person sein, die die Leute personell organisiert. Aber es kommt eigentlich daraus, welche Arbeitseinheiten habe ich denn als Firma und wem übergebe ich diese Arbeitseinheiten und damit die in der Zeit und in der Erwartung, die ich habe, fertiggestellt werden. Und wenn jetzt AI sehr viel effizienter ist, ist die Frage, wie organisiere ich mich? Habe ich überhaupt Teams? Habe ich nur noch lauter Einzelkämpfer, die einzelne Themen ownen? Habe ich, weiß ich nicht, habe ich ein Black, manchmal stelle ich mir das so vor, wie so in Computerspielen, da läuft man so rum. Vielleicht in, weiß ich nicht, ob das noch jemand kennt, in Skyrim oder sowas.

Robert: Das kenne ich, also ich kenne es noch, ich will nicht für die Hörerinnen und Hörer.

Stephan: Klauf ihn rum und dann finde ich da, oder in Red Redemption, da finde ich da eine Anschlagtafel und da sind Tasks drauf. Ja, da gehe ich dann hin und dann sage ich ja, da muss ich ein Schwein einfangen und da muss ich irgendwie jemanden um die Ecke bringen und so. Also die Frage ist ja auch, wenn ich jetzt nur noch Einzelkämpfer habe, ist ja vielleicht das auch das Modell. Das heißt, die Firma hat so ein Taskboard, das hackt da aus und da kann man sich Sachen nehmen und wenn man Pech hat, wird man auch danach bezahlt, wie in einem Computerspiel. Denn für schwerere Sachen gibt es mehr Geld und für weniger gibt es weniger Geld. Ich glaube aber, aus einer menschlichen Sicht und organisatorischen Sicht halte ich ein Team statt Einzelkämpfern, nicht statt fünf Leuten, sondern statt dem Einzelkämpfer-Modell ein Team von zwei Leuten für sehr, sehr sinnvoll. A, gibt es zwei Leute, haben immer einen gewissen moralischen Support, der ist sehr wichtig. Das wird man auch immer feststellen, wenn man alleine eine Start-up gründet oder zur zweiten Startup gründet. Das ist ein fundamentaler Unterschied dazwischen.

Stephan: Und man kann sich auch ergänzen oder eben man kann sich gegenseitig ergänzen und man kann man hat als Firma auch noch mal ein gewisses eine gewisse Ausfallsicherheit. Wenn einer krank wirkt, dann ist nicht der Einzige, der sich mit dem Thema auskennt oder das Projekt bleibt nicht stehen oder sowas. Also von daher glaube ich, organisatorisch und mental und motivationstechnisch halte ich für ein Zweier-Team für super und für machbar. Aber eben nicht als, ich muss vom Fünfer runter, sondern ich glaube eher, dass wir sonst die Tendenz kriegen, lauter Einzelkämpfer zu haben.

Robert: Also ich habe jetzt auch schon Effekte gesehen von klassischen Teambesetzungen fünf Personen für einen ehemaligen Kunden und da war es sehr wohl der Fall. Also, die Teambesetzung war unsererseits extrem high-Agency erfahrene Engineers, fast durch die Bank in den fünf Leuten. Die haben sich nur auf den Füßen rumgestanden. Die haben dauernd gesagt: Kann ich da jetzt mal mit meinem Agent rein? Nee, ich bin da gerade. Also, es ist wie so wie so schnelle Tunnelbohrer, die sich dauernd in die Quere kommen. Da ist eigentlich der, der, das Abstimmen, wer macht was, nimmt viel zu viel Zeit in Anspruch. Und das war eigentlich für mich so ein Indikator dafür, dass die Teams jetzt schon bei guter Anwendung und das sind leider im Moment mehrheitlich die Seniors, wenn sie denn wollen, dann sind die Teams zu groß mit fünf Leuten. Ja.

Stephan: Wenn ich mir vorstelle, also ich mache sehr viel mit AI, dieses Open Source-Projekt, ich mache aber auch eine größere Anwendung für mein Coaching, habe ich selber, also Cloud Code, immer wenn ich sage, ich habe es programmiert seit sechs Monaten oder acht Monaten, habe nicht ich das programmiert, sondern Cloud Code das programmiert. Also ich habe auch eine Anwendung für mein Coaching, für Zeitabrechnungen und Erfassung und Businessmanagement und so weiter geschrieben. Weil keine A, am Markt nichts gab, was das kann, was ich brauche, und B, weil es mit AI halt kein Problem ist, das zu schreiben. Und wenn ich mir jetzt vorstelle, ich müsste diese Anwendung oder auch mein Open Source Tool, also Human, Get Human.sh, stand hinterlassen.

Robert: Nehmen wir in die Shownotes.

Stephan: Stand hinterlassen. Kämpfe um jeden einzelnen Stand auf GitHub. Dann wüsste ich auch nicht, wie ich interagieren würde mit Leuten. Also ich habe drei Agents laufen, die unterschiedliche Features arbeiten. Der eine macht einen Bug, der andere macht eine generelle Buganalyse, der eine arbeitet an einem Feature oder ich mache Ideation mit einem. So wie ich da arbeite, ist es für mich auch schwer vorstellbar, wie ich mich denn da integriere. Ich bin immer der Meinung, oder ich bin mittlerweile der Meinung, sehr, sehr viel von dem, was wir tun in der Softwareentwicklung über die letzten Jahre hinweg ist aus der Organisation von Menschen entstanden. Also, wie organise ich Softwareentwicklung mit Menschen? Da kommen die Dailies her, da kommen die Retros her und so weiter. Und so vieles von dem kommt eigentlich eine sehr menschenzentrierte Sicht der Softwareentwicklung. Und die wird jetzt mit AI, also es hindert mich. Also, diese ganzen Rituale hindern mich einfach auch noch mehr. Ich wüsste jetzt nicht, wie ich konkret mit anderen Entwicklern zusammenarbeiten sollte.

Robert: Ja, das ist eigentlich Risikomanagement, ne? Diese ganzen Ausprägungen, die Sprints, die Epics, die Teamgrößen, die Rollen, die Scrum Master oder was auch immer man anwendet.

Robert: Dass man nicht eben das Falsche über zwei Wochen programmiert.

Stephan: Ja. Und ist ja heute egal. Also, wenn ich nicht mehr zwei Wochen programmieren muss, sondern den Tag, dann kann ich am nächsten Tag feststellen, war es halt nicht, der Prototyp, hab den Prototyp gebaut, hab' meinem Chef gezeigt, das CEO findet es doof, ich mache ein MVP, habe ein MVP, zeig's dem Kunden, der findet es auch doof. Gut, dann halt nicht. Ja, während vorher hätte ich da wochenlang irgendwie Zeit investiert, da muss ich natürlich sehr viel sicherer sein, dass die Zeit, obwohl Agile ja eigentlich die Idee ist, von einem Jahr Entwicklungszyklen auf zwei Wochen runterzukommen, damit ich mir, damit ich nicht ein Jahr in was Falsches investiere, ist es halt heute so, dass ich, oder ist die Realität eher so, dass die Leute schon gar nicht zwei Wochen in das Falsche investieren wollen? Und jetzt mit AI ist es aber vielleicht so, vielleicht so, dass die Leute einen Tag nicht ins Falsche investieren wollen. Das kann natürlich auch sein. Aber potenziell ist mit AI so, dass man in Sachen investieren kann, in die man vorher nicht investieren hätte wollen.

Robert: Ja. Wenn du heute falsch investierst und es richtig gemacht hast, würde ich sagen, hast du eine Nacht, in der alle geschlafen haben, investiert, zahlst 35 Dollar und du hast fünf Varianten des Falschen. Da stehen wir eigentlich. Wir haben jetzt schon öfter über die lieben Senior Engineers gesprochen, die, wenn sie denn wollen und nicht in den Widerstand eintreten, Moral mal außen vor hier in der Diskussion, die davon extremst profitieren können. Der liebe Junior, der wurde ja schon in unserer Geschichte oft für tot erklärt. Jetzt tun das wieder viele. Was siehst du denn in den Gesprächen mit deinen CDOs, die du berätst? Wie wird da der Junior jetzt in dieser Zeit wahrgenommen? Gibt es Ideen, wie man die jetzt zum Senior bringt? Was sollen sie lernen? Sollen sie eigentlich nur noch nur noch Systems Engineering, Softwarearchitektur lernen, ohne das Coden zu Fuß zu lernen, wie wir das noch mussten?

Stephan: Also, ich würde mal sagen, die Mehrzahl meiner Kunden ist noch so verwirrt in der Entscheidung: nehme ich jetzt Cursor oder nehme ich laut Code, soll mein Entwickler auf Code gucken oder nicht, dass sie bei dem Thema noch nicht angekommen sind. Sie nehmen jetzt natürlich wahr, aus der öffentlichen Diskussion, was wird aus dem Junior, aber wenn ich mit meinen Kunden über Career Letters oder sowas spreche, konkret oder über Rollen oder so, dann würde ich sagen, ist es eher so, dass wir das classical Rollenmodell have plus AI, weniger ein neues Rollenmodell. Auch wenn ich mit dem einen oder anderen Kunden auch Rollendiskussionen über Product Engineers have und neue Definitionen habe über Product Engineers. Da ist, glaube ich, sind die Organisationen noch nicht. Also, ich glaube, die meisten Organisationen sind eher da. Klassisches Modell plus derjenige muss jetzt mehr AI machen und vielleicht derjenige muss mehr Produkt machen.

Stephan: Wie ich den Junior, ich bin mir nicht ganz sicher, was der Junior lernen sollte oder nicht. Ich hatte halt in der Vergangenheit schon Juniors, oder für mich entscheidet eh, ein guter ist ein guter Junior jemand, der Verantwortung übernimmt und der Grid hat und der Sachen machen will. Unabhängig von Technologie oder sonst irgendwelchen Dingen. Und derjenige, der das hat, der wird sich auch mit AI durchsetzen. Der Junior wird aber kein, also, das ist sozusagen, glaube ich, auch der Fehlschluss von vielen. Der Junior wird kein Senior Java Entwickler oder Senior TypeScript-Entwickler. Also, das wird da halt nicht. Ich weiß nicht, was für ein Senior er wird. Ja, es ist ein, der Zyniker würde sagen, Senior Prompter. Das glaube ich nicht, aber ich glaube, es geht zu verabschieden. In vielen dieser Diskussionen ist, wie kriege ich einen Junior-Entwickler ohne Programmiererfahrung dazu, einen Senior Java-Entwickler zu werden? Und das, glaube ich, passiert halt nicht. Der Junior wird irgendwas Neues werden. Was weiß ich nicht. Ich habe hier hinter mir, ich habe gehört, wir haben kein Video, aber hier hinter mir habe ich irgendein Buch stehen. Das heißt, das ist eines meiner Lieblingsbücher, Z80 Procedure Algorithms oder sowas. Eines meiner Lieblingsbücher zur Z80 Maschinensprache. Kann keiner mehr. Und da hat natürlich auch keiner mehr gestalten. Als C aufkam, hat auch keiner gefragt, wie wird denn jetzt dann ein Junior mit C ein Junior zu einem Senior Assembler-Programmierer? Nee, der wird halt ein C-Senior-Entwickler. Und von daher, wo es genau hingeht, weiß ich nicht. Aber ich sehe nicht den Abgesang auf Juniors. Ich glaube eher, der Junior hat alle Vorteile in der Hand. Der Junior ist jung und will was erreichen. Jetzt ganz übertrieben gesagt, der Senior möchte den Haushalt bezahlen.

Stephan: Also, ich möchte jetzt wirklich keinen Seniorentwickler zu Nahe treten.

Robert: Ich überspitze das. Nein, aber die Lebensumstände sind definitiv kein Problem.

Stephan: Ich verstehe das alles. Und ich will auch niemanden da schlecht machen. Ich meine, generell ist es nur, ich würde allen raten, nach vorne zu gucken. Das meine ich dann damit immer. Aber ich würde den Abgesang des Juniors nicht mittragen. Ich glaube, der Junior hat alle Karten in der Hand und ja.

Robert: Dabei wird ja auch in dieser Diskussion wird ja meines Erachtens auch oft verkannt, dass man mit AI nicht nur produzieren kann wie wild, sondern dass man eben auch mit AI lernen kann. Ohne den Menschen jetzt aus jedem Lernloop entfernt zu wollen, das ist gar nicht mein Ziel, aber in dieser Diskussion fehlt das immer, weil alle schon in dieser fabrikartigen Produktionsdenke hängen. Und das ist natürlich für einen Junior, wenn er da einfach nur Tokens reinkippt und es sprudelt Code raus und er versteht nichts, ist natürlich doof. Aber das kann ich ja auch enablen, dass es zum Lernen benutzt wird. Du hast das Buch geholt, habe ich gerade im Video gesehen.

Stephan: Ja, ich wollte jetzt nur nochmal, damit ich nicht ganz so doof aussehe, nochmal gucken, wie das Buch heißt. Das Buch heißt Z80 Assembly Language Subroutines.

Robert: Wir nehmen es in die Shownotes.

Robert: Man kann auch gerade besonders aus alten Büchern viel lernen, weil die neuen AI-Bücher so wahnsinnig schnell veralten.

Stephan: Ja, Assembler-Bücher aus den 80ern veralten halt nicht. Also es sind ja schon über diesen Zeitpunkt hinaus und so. Das Super Faszinierende an diesen Sachen ist so: Also, also Leute wissen es ja nicht, aber im Prozessor gibt es ja Register. Und bei Z80 ist zum Beispiel ist es total lustig, weil man kann aus einem Register Daten in ein anderes schieben, aber manchmal ist es asymmetrisch, man kann sie nicht zurückschieben. Also es ist der Befehlssatz ist asymmetrisch, das finde ich super toll. Als Brain teaser. Finde ich das toll, um damit Software zu entwickeln und meine Features zu schreiben? Nee. Aber so als Brain-Teaser finde ich es natürlich super, dass man, dass der Befehls Z80-Befehls asymmetrisch ist. Also manche Sachen gehen in die eine Richtung, aber nicht in die andere.

Robert: Ja, schöne Analogie gerade.

Robert: Du sag mal, jetzt haben wir sehr viel darüber gesprochen, wie gebaut wird, von wem. Ich finde es auch noch spannend, die Seite zu beleuchten, wie wird denn Software, die von jemand gebaut wurde, genutzt.

Robert: Die SARS-Aktien, die haben, ich glaube, letztes Jahr war es ja extrem Panik bekommen.

Robert: SARS wird jetzt oft zum Tode erklärt. Ich persönlich will jetzt auch nicht ein SARS-Unternehmen leiten oder darin arbeiten. Es wird zumindest sehr, sehr spannend werden.

Robert: Weil wir ja schon von Software on Demand reden. Ich sehe es gerade so ein bisschen bei mir privat. Ich baue gerade für meine Frau, die ist Innenarchitektin, eine Innenarchitekturanwendung, die mit Google Nano Banana Pro Szenen von Wohnungen, von Räumen, die man reinlädt, einfach mit bestimmten Möbeln stagt.

Robert: Da kann man Produkte anlegen. Und da ist ein Annotationsfeature drin, weil Claude mir das einfach vorgeschlagen hatte, ja, macht doch ein Feature, wo man einkringeln kann, wo die Lampe denn nun hin soll. Dann musst du dir nicht die Fingerwund prompten. Dann kann man Maße einpflegen, weil Nano Banana natürlich ein räumliches Reasoning-Potenzial hat. Und wenn es weiß, wie groß die Lampe ist, dann setzt es die auch korrekt in die Szenerie ein. Das ist Wahnsinn, das entsteht teilweise über Nacht, teilweise aber auch im sehr engen Loop, Software halt. Aber ich denke mir halt, ich kann nicht groß in diese Branche reingucken, aber Leute, die immer so 3D-Studio oder Blender-Renderings gemacht haben, um irgendwelche Räume zu stagen in tage- und wochenlanger Arbeit, nur für Angebotsphasen oder sowas, das ist vollkommen wild, was auch da eigentlich möglich ist. Deswegen, also, wie sieht aus deiner Sicht denn der Consumer die Consumer-Seite aus von SARS-Produkten?

Stephan: Die Frage, also spannend, zwei Aspekte.

Stephan: Meine ich rede zu viel und meine Sprachtrainerin hat mal gesagt, ich soll mal wenigstens, wenn ich so viel rede, wenigstens vorher ankündigen, was ich sagen möchte. Also zwei Aspekte. Der erste Aspekt ist, ich glaube, dass es mehr möglicherweise mehr Apps mit Audience of One gibt. Also, das heißt, ich kann mir möglicherweise als Firma eine SAS-Anwendung schreiben, die 50 Euro pro Person zu sparen oder sowas. Da sagen dann manche, ja, guck mal, du hast jetzt irgendwie ein Engineer drei Tage gesessen, hat ja auch 3,000 Euro gekostet, kannst du viele Lizenzen zahlen. That stimulation, but for me, aber für mich ist es eher so, ich kann Sachen bauen, die genau das machen, was ich will. Also, ich habe zum Beispiel eben meine Coaching-Anwendung mit einer Audience of One, mit mir geschrieben. Die ist integriert mit Zoom, mit Transkripten, mit Analysen, mit Google Dashboard, mit Google Kalender und zieht es ins Dashboard rein, hat die Sachen miteinander verknüpft, damit ich maximal wenig Arbeit mit dem Administrationsoverhead habe, an dem ich ganz ehrlich keinen Spaß habe. Und auch das Invoicing automatisiert. Keines der Produkte, der Markt kann das in der Form, wie ich es haben möchte, optimal. Also da glaube ich, sehe ich einen Trend, dass Firmen mit dieser Audience of One, sie als Firma eine, also früher hat man Custom Software-Entwicklung gesagt und dann haben wir gesagt, oh Gott, das ist teuer. Ich meine, der Maya, 80er Jahre vielleicht, ja, oder 90er. Überall Custom-Software-Entwicklung. Ich habe auch mal zum Beispiel in den 90ern sehr, sehr viel Delphi gemacht, um Windows-Anwendungen in der Firma, Windows-Anwendung für andere Firmen zu schreiben, als Custom-Anwendung. Dann ging es weg zum Standard, weil zu teuer, weil Standard billiger und Support und so weiter und so fort. Und dann kam SAS noch billiger, kann ich irgendwie skalieren und brauche ich nichts installieren und brauche ich gar nichts warten und so weiter und so fort. Und jetzt geht der Pendel möglicherweise wieder zurück, weil AI so billig ist, Software zu entwickeln, die genau auf mich zugeschnitten ist. Also das ist, und jetzt habe ich den zweiten Aspekt vergessen, aber das ist sozusagen das, das ist, glaube ich, was mit dieser Audience of One, wo es hingeht. Ach ja, the zweite Aspekt ist folgender.

Stephan: Wenn alle Features, wenn alle, also wie, wie, die Frage ist für mich eher, das sehe ich auch in meiner Software, die ich schreibe, oder Clutch, immer wie gesagt, Cloud schreibt, wenn ich sage, ich schreibe. Wo ist das Limit der Features? Also wird in Zukunft jede Software alle Features haben, die denkbar sind. Also das ist so philosophisch: der Raum aller denkbaren Features. Und wenn ich, du sagtest es vorher, die AI kann ja auch nachts durcharbeiten. Ich habe es letztens gerade wieder mit dem CTO geredet, der hat auch gesagt, naja, er hat sich jetzt auch, um da weiterzuarbeiten und Sachen zu machen, der hat sich ein VPS gestartet, damit Claude halt irgendwie auf dem VPS laufen kann, mit Claude Remote, und dann kann man da, dann läuft der 24 Stunden. Und wenn jetzt lauter diese Produktionsengines 24 Stunden am Tag Features bauen, dann hat potenziell irgendwann jede Software, jedes Feature. Und dann ist mir die Frage, wer konsumiert die wie?

Robert: Deswegen Produktarbeit wird wahrscheinlich, wie viele andere Rollen und Aufgaben, noch viel, viel wichtiger. Weil man sieht ja jetzt schon die erste erste Bloatware, ne? Da haben Leute endlich mal das berühmte Dashboard gewipecodet, das nie jemand bauen konnte. Und es hat alle Features, von denen man zwei immer haben wollte. Und die anderen 90, niemand. Die gibt es trotzdem jetzt und es findet sich keiner zurecht. Ich glaube, das gibt auch nochmal Druck auf das Produktdesign einfach.

Robert: Du, lass uns doch nochmal, um den Bogen zu schließen, und bevor wir uns gleich verabschieden, vielleicht die spannendste aller Fragen stellen.

Robert: Wie viele von den Unternehmen, mit denen du sprichst? Du musst es nicht genau quantifizieren, wahrscheinlich darfst du doch gar nicht drüber sprechen, aber kannst dir ein Bauchgefühl geben? Wer hat denn eigentlich Stand heute in der AI-Strategie? Wie mit all diesen Themen im Haus umgegangen werden soll? Und Folgefrage: Sollte man die haben oder frisst nicht Kulturstrategie zum Frühstück? Wieder der Zitatgeber, der mir entfallen ist. Aber das ist, glaube ich, auch ein sehr wichtiges Thema, oder?

Stephan: Ich dachte ja jetzt, die spannende Frage ist, die jedem bewegt ist. Brauche ich einen CTO-Coach? Und die Antwort ist natürlich ja, weil jeder, der, jeder Top-Performer hat drei Coaches, überall, bloß irgendwie, das sieht die Wort keinen.

Stephan: Klingt wie Werbung, passt aber jetzt zum, passt aber zum Strategiethema. Aus meiner Sicht haben die meisten nicht, also aus meiner Sicht sind die meisten Firmen sowieso verwirrt, was Strategie und Vision betrachtet und machen ganz viele komische Dinge, machen meist nicht die falschen Dinge. Und ich habe da ganz simple Vorstellungen gemacht. I've been simpel, habe ich eine simple Vorstellung, was Vision und Strategie ist. Und in dem Sinne würde ich mal sagen, ah, 10% der Firmen, mit denen ich arbeite, haben eine Strategie und eine Vision in that sense, which I think it is sinnvoller achte. Manche haben einen Plan, manche haben eine Vorstellung, aber wirklich zu sagen, unsere Vision ist, wir haben die gleiche Anzahl Mitarbeiter, aber machen zehnmal mehr, oder wir haben zehnmal weniger Mitarbeiter, oder wie kommen wir da hin? Oder was machen wir denn und wo setzen wir AI ein und wer ownt das und wer macht Governance? Und alle diese Sachen sind eher eher als Antwort auf Gegebenheiten, denn aus einem strategischen Plan heraus. Also ich würde sagen, klein, verschwinden, ein kleiner Anteil. Ich arbeite sehr hart daran, mit meinen CTO-Kunden eine Vision zu erarbeiten und zu sagen: Hier, hier da glaube ich, dass wir in fünf Jahren sind. Haben wir jetzt in dem Podcast gar nicht drüber gesprochen, was ich glaube eigentlich, aber jeder kann bei mir anfragen nach dem Vortrag: AI ist eine Software, um zu erfahren, wo es hingeht.

Stephan: Wir arbeiten daran, aber es sind aus meiner Sicht viel zu wenig Firmen, die einen Plan haben oder eine Vision, wo es denn hingehen soll, aus ihrer Sicht.

Robert: Ich glaube, das liegt auch daran, dass der Mensch einfach inhärent die Taktik liebt und die Strategie einfach unfassbar anstrengend ist, weil man sich auf eine nicht taktische Ebene begeben muss. Und das muss man auch eben lernen. Und vielleicht ist es jetzt wieder pauschalisiert, aber im deutschen Mittelstand mindestens ist es schon schwierig, strategisch zu arbeiten.

Stephan: Ich glaube, nee, ich glaube, es ist anders. Ich muss ja widersprechen.

Robert: Ja.

Stephan: Vielleicht, wenn ich das darf.

Robert: Mach das.

Robert: Dafür sind wir hier, dass wir uns eigentlich konstant widersprechen. Okay, dann müssen wir auch ganz widersprechen.

Stephan: Der Widerspruch ist, die Leute machen aus meiner Sicht keine Strategie aus zwei Gründen. Oder auf Level 3. Erstens wissen sie nicht genau, was es ist. In vieles Handwerkszeug und dann gibt es noch Missionen und dann sind sie total verwirrt. Aber die eigentlichen Gründe sind, Strategie schließt Optionen aus. Und das machen Leute Ungarn. Also, wenn ich sage, ich gehe jetzt erst nach Frankreich und dann nach England, und zwar mit 150% Conviction, dann schließt das halt alternative Optionen aus. Und ich glaube, das mögen die Leute einfach nicht.

Stephan: Also das Commitment auf Sachen, die Leute committen sich Ungarn auf Entscheidungen. Die treffen eh Ungarn Entscheidungen und Schlechte Entscheidungen. Die meisten Firmen sind ganz grottig in Sachen Entscheidungen. Strategie bedeutet Entscheidungen treffen. Und deswegen ist das, glaube ich, der eine Grund. Und der andere, viele Gründer in meinem Umfeld wollen sich nicht an Regeln halten. Das heißt, eine Strategie wird eher als Belastung wahrgenommen, die die the eigene handlungsoptionen einschränkt und das eigene Handeln einschränkt anders. Anstatt zu sagen, yeah, morgens stehe ich auf und ich mache halt, was mir einfällt. Also, and when mir einfällt, dass wir jetzt da irgendwie grüne Taschenrechner auf den Markt bringen, bringen wir grüne Taschenrechner auf den Markt. Das wird dann meistens auch noch gejubelt with Innovationen und tollen Ideen, die ich habe. Und bei uns kann jede Idee was werden. Aber aus den zwei Sachen, glaube ich, hauptsächlich. Aus diesem, man will sich nicht eine, und wenn es der eigene Plan ist, nicht einen Plan unterwerfen, einerseits, sondern man will sich auch nicht die Optionen nehmen und auf den Plan committen.

Robert: Grün scheint irgendwie ein sehr starkes Gewicht, diesen Podcast zu haben.

Robert: Wir hatten in einer der frühen Folgen die Currywurst aus Gurken. Und jetzt haben wir die grünen Taschenrechner. Ich hoffe, wir bleiben uns treu und haben noch sehr viele grüne Metaphern hier zu finden. Stefan, ich fand das extrem spannend. Ich glaube, ich könnte mit dir noch drei Stunden weiterreden, bis wir irgendwann den Kamin anmachen und dann noch sechs Stunden weiterreden. Sollten wir vielleicht auch mal irgendwann tun.

Robert: Wir haben jetzt eine Stunde voll. Mein Kopf explodiert. Ich hoffe, du hattest Spaß und freue mich, wenn du ganz bald mal wieder bei uns bist.

Stephan: Ich hatte sehr viel Spaß, habe mich sehr gefreut über die Einladung und würde ja auch sehr gerne wiederkommen.

Robert: Sehr gerne. Mach's gut. Bis dann. Danke dir für deine Zeit. Ciao an alle.

Stephan: Sehr gerne wiederkommen.

Robert: Sehr gerne. Mach's gut. Bis dann. Danke dir für deine Zeit. Ciao an alle.