# The Evolution of Agentic Engineering in Enterprise Software

**Podcast:** AI FIRST Podcast
**Published:** 2026-06-05

## Transcript

Herzlich willkommen zum AI First Podcast.
Heute spreche ich mit David Gebhardt, dem CTO von mobile.de und wir machen mal einen Deep Dive in KI in der Softwareentwicklung, weil da unfassbar viel passiert ist, insbesondere in den letzten Monaten.
Die einen rufen schon aus, dass KI das Ende der Softwareentwickler ist.
Auf der anderen Seite werden in großen Unternehmen immer mehr Softwareentwickler eingestellt.
Die Frage ist, wo liegt denn da eigentlich die Wahrheit?
Und David, ich bin einfach sehr gespannt, was du so berichten wirst aus eurer Arbeit.
Danke, dass du da bist.
Ja, cool, dass ich hier sein darf.
Hallo.
Erzähl mal kurz, wer du bist und was du bei Mobile machst.
Ich bin David Geppert, bin bei mobile.de Chief Technology Officer, darf mich also mit allem beschäftigen, was von der Softwareentwicklung, also all dem, was man sieht, wenn man auf mobile.de unterwegs ist, bis hin zur intern IT und Security verantworten und bin damit verantwortlich hier für ein Team von über 300 Personen, die tagtäglich AI im Einsatz haben und eben auch in der Softwareentwicklung.
Antropic, OpenAI und Google haben sich ja Software Engineering als so den ersten heiligen Gral rausgepickt, den sie knacken wollten, um darüber auch ihre eigene Forschung zu beschleunigen.
So zumindest die Idee dahinter, die man wahrnehmen kann.
Und gerade in den letzten drei bis sechs Monaten hat sich gefühlt die Geschwindigkeit nochmal erhöht.
Cloud Code und andere Anwendungen sind so richtig durchgestoßen und haben sehr viel Zuspruch.
in der Entwickler-Community gewonnen.
Jetzt seid ihr ja ein gewachsenes Unternehmen, kein kleines Start-up mehr, was sofort auf alle neuen Tools und Agenten draufspringen und die nutzen kann.
Aber ihr kommt ja auch nicht drum rum.
Was hat sich denn jetzt bei euch so in den letzten zwölf Monaten in eurer alltäglichen Arbeit dadurch verändert?
Genau, die Reise ist tatsächlich schon etwas länger als zwölf Monate.
in Machine Learning ansetzt, sprechen wir von einem Jahrzehnt.
Jetzt jüngere AI-Entwicklung ist natürlich mit Device of OpenAI und ChatGPT so der Startschuss gewesen.
Wir haben, glaube ich, den sehr glücklichen Umstand, dass wir auch, wenn wir bald 30 Jahre alt werden als Unternehmen, eine Digital First Company sind, also ein digitales Produkt, haben einen großen Teil unseres Personals.
im Product- und Tech-Bereich angesiedelt ist, damit eher Early Adopter als andere Unternehmen, was auch dazu führt, dass wir im Rahmen von Enterprise AI, also was so Text und Bildgenerierung, sehr zeitig dabei waren und auch im Software Engineering durchaus zeitiger, also mit GitHub Copilot damit eingestiegen.
Mittlerweile, das kommt wahrscheinlich wenig überraschend, Cloud Code.
Also auf Entropic setzen an der Stelle und da einfach auch eine extrem hohe Adoption im Engineering haben.
Also da sprechen wir wirklich von 90, 95 Prozent der Engineers, die das wirklich aktiv nutzen in der Softwareentwicklung.
Und jetzt gibt es ja wahrscheinlich, es gibt ja einen Begriff, der sich so geprägt hat, der Agentic Engineering, als Agentic Engineering bezeichnet wird.
Kannst du mal erklären, was ist der Unterschied zwischen Ich nutze jetzt ein KI-Tool, um mir beim Coden helfen zu lassen und ich praktiziere Agentic Engineering.
Ja, ich glaube, das kann man am besten damit beschreiben, welche Rolle nimmt der Mensch ein und welche Rolle nimmt eigentlich die KI an der Stelle ein.
Der Begriff Vibe-Coding wird ja viel überall verwendet für ich habe ein Tool und gehe in die Softwareentwicklung und in sehr kleinschrittigen Ausbaustufen.
Also ich fange mit etwas an und dann möchte ich hier aber noch einen Button.
Also prompte ich, baue mir doch bitte noch einen Button zum Speichern von dem, was ich da jetzt sehe, dort unten rechts und taste mich so vor.
Das ist also das, was ich als Vibe-Coding und AI-Assisted Engineering beschreiben würde.
Also die AI entwickelt.
auf dem Input des Menschen.
Aber eigentlich ist der Mensch noch so der Dreh- und Angelpunkt in dieser Entwicklung.
Also der Mensch entwickelt mithilfe von AI.
Bei Agentic Engineering dreht sich das Verhältnis aus meiner Sicht um.
Also der Mensch gibt Input.
Wir reden auch von deutlich längeren Cycles.
Der Mensch gibt deutlich mehr Input.
Fachtermini-Specs und Harness und Guardrails, um dann eben die AI, die Maschine, eben sehr lange arbeiten zu lassen und bestenfalls sehr viel näher schon an ein Endprodukt zu kommen.
Also es verändert die Rolle des Menschen in dem Ganzen und es dreht auch um, wer hier eigentlich maßgeblich mit wem arbeitet.
Kannst du mal anhand vielleicht von einem Beispiel erklären, wie so ein Entwickler bei euch arbeitet?
Specs genannt, Harness, Guardrails, ich verstehe das alles nicht.
Vielleicht geht es dem ein oder anderen Zuhörer auch so.
Was ist anders?
Ich stelle mir das vor, ich habe vorher ganz viel Code geschrieben und auf einmal mache ich das nicht mehr, sondern ich erkläre einem Agent, wie der den Code schreiben soll.
Aber wie mache ich das?
Genau, vielleicht von weggeschoben und ich glaube, das gilt für alle gestandenen Unternehmen in dem Umfeld.
Keiner hat den heiligen Graal schon gefunden und wir experimentieren alle noch und sind auch der Tatsache unterlegen, dass wöchentlich sich große Änderungen auftun in was möglich ist und wie das auch möglich ist.
Deswegen kann ich nur beschreiben, was...
Achtung, Vorsicht, heute gültig ist.
Es ist erstmal eine Mischung.
Also ich würde nicht sagen, dass wir 100% Agentic Engineering am Start haben, sondern es ist nach wie vor ein Mix.
Bei wirklichen Agentic Engineering, wenn man sich anschaut, wie Softwareentwicklung in der Vergangenheit gemacht wurde, dann startet das mit einer Idee.
Die wurde potenziell in ein Ticket, in eine Story gegossen.
UX hat vielleicht Wireframes gemacht, ein bisschen User-Testing gemacht, um sicherzustellen, dass das so grob passt.
Produkt hat das, wie gesagt, ein Ticket gepackt.
Der Engineer hat das genommen und hat in Inkrementen das gebaut und per Hand Source-Code geschrieben.
Auf dem Weg vielleicht ein paar Libraries, Frameworks benutzt, um Dinge abzukürzen.
Das Ganze wurde getestet gegen live, man hat vielleicht Learnings eingesammelt, gemessen, Metriken gesammelt und ist in den typischen Verbesserungszyklus gegangen.
So weit, so gut.
Im Agentic Engineering ist es so, dass ...
Der Entwickler in unserem Fall mit Cloud-Code arbeitet.
Das bedeutet erstens, erster großer Unterschied, es wird kein Source-Code geschrieben, sondern es wird in plain English oder auch Deutsch gepromptet.
Das andere ist, Cloud-Code ist dann noch umgeben von Dingen, die Richtlinien vorgeben und bestimmte Standards reingeben.
Kontext reingeben.
Was ich damit meine ist, wir haben natürlich bestimmte Richtlinien, wie sieht unser Styleguide bei Mobile aus, wie sehen Frontend-Komponenten aus, wie sieht ein Button aus, wie sieht ein Texteingabefeld aus.
Wir haben bestimmte Sicherheitsrichtlinien, wir haben bestimmte Anforderungen an welche Testabdeckung haben eigentlich die Sachen, die wir in Production haben, wie monitoren wir Dinge und so weiter.
All das wird mitgegeben.
Plus Kontext, das ist in unserem Fall ein MCP, also einfach gesagt eine Schnittstelle, über die Cloud Code verstehen kann, in welchem Kontext jetzt eigentlich entwickelt wird.
Also ist das jetzt gerade bei mobile.de im Leasing oder bewegen wir uns eigentlich im Financing und wir sehen eigentlich die Services und die Artefakte aus, die es darum eigentlich schon gibt.
All das ist da.
Was dann noch gebraucht wird, ist die Spezifikation.
Also was ist eigentlich der Intent von dem, was wir heute bauen wollen?
Und dafür benutzen wir Framework-3-Spec-Kit, was quasi auf Cloud-Code aufsetzt und den User, in unserem Fall Product Manager und Engineers, durch eine Art Interview führt.
Wenn ich jetzt sage, okay, ich möchte einen neuen Bezahldienstleister für unser C2C-Produkt bauen.
Dann kommen Fragen, okay, was muss denn das Ding können?
Kreditkarte oder auch PayPal oder das und jenes.
Dann geht es in technische Fragestellungen, Produktfragestellungen, wie soll der Userflow aussehen?
Das wird so lange getrieben, bis die Spezifikation komplett ist.
All das landet im Prompt.
Und was dann passiert, ist eben nicht der Engineer, der anfängt, das Problem jetzt in Source-Code zu übersetzen, sondern der Agent oder sogar die Agents, die sich gegenseitig auch noch delegieren, die loslaufen, das bauen, das gegen die Spezifikationen am Ende testen, auch sicherstellen, dass die Guardrails eingehalten sind, also am Ende ist die Testabdeckung.
wirklich genug sind die Sicherheitsstandards eingehalten und so weiter.
Bis nach Minuten, Stunden, je nachdem, wie es aufgesetzt ist, das Ergebnis steht, mehr oder weniger das fertige Produkt.
Und dann kommt die nächste Stelle, wo dann wieder der Mensch eine große Rolle spielt, das Reviewen von dem, was gewacht wurde.
Also in unserem Fall Der Pull-Request wird gereviewt, bevor irgendwas in Production landet.
Also die Arbeit verschiebt sich von der Umsetzung mehr, also von der Mitte, mehr nach vorne und nach hinten.
Genau, definitiv.
Also der Mehraufwand entsteht definitiv in der Spezifikation, als auch im Review am Ende.
Also am Ende verschieben sich Aufwände.
Es verschieben sich aber auch Constraints.
Im Software Engineering sind es genau diese Stellen, also wer und wo entsteht eigentlich die Spezifikation für das, was gemacht werden muss.
Das ist deutlich aufwendiger, als es in der Vergangenheit in iterativem Vorgehen war, wo auch implizites Wissen eine große Rolle gespielt hat.
Implizites Wissen funktioniert.
in der Interaktion mit einer Maschine eher schlecht.
Und dann eben auch gegen Ende des Prozesses, wenn es in den Human-in-the-Loop-Review geht, um sicherzustellen, dass tatsächlich das Ergebnis auch das ist, was wir erwartet haben.
Im größeren Kontext ist es dann auch noch so, wir nehmen einfach an, wir hätten das jetzt alles in Product-Engineering total gelöst.
Dann bin ich immer noch Teil von etwas Größerem.
Ich bin Teil eines Gesamtunternehmens.
Und jetzt stellen wir uns einfach vor, Software Engineering ist zehnmal so schnell wie in der Vergangenheit.
Auch dann bin ich wieder im Sinne von Constraint Thinking in einem System gefangen oder ich bin Teil eines Systems.
Und auch da gibt es Upstream und Downstream Bottlenecks.
Wenn ich sage, okay, ich kann vielleicht zehnfach so schnell Dinge tun, heißt das auch, ich muss zehnfach so schnell drüber nachdenken können, was ich tun möchte.
Und wie gesagt, in einem deutlich höheren Detail.
Also wie machen wir Strategie, wie machen wir Planung, wie entscheiden wir, was die richtigen Dinge sind, die wir verfolgen wollen.
Das ist definitiv ein Thema.
Das andere, und das sind die Downstream-Themen, wie bringe ich eigentlich all das, was ich tue, in den Markt, sodass es meine Kunden auch verstehen.
Und überhaupt begreifen können.
Und das sind alles Herausforderungen, die sind heute wahrscheinlich noch nicht komplett real.
Ich sehe bloß, dass genau diese Herausforderungen auf die Gesamtorganisation und da ist mobile.de bloß ein Beispiel, zukommen werden.
Wir gehen gleich nochmal auf die Rollenprofile ein, aber vorher, wenn ich nochmal so ein bisschen verstehe, wie kann ich mir das vorstellen?
Also setzen dann eure Engineers alle mit sechs unterschiedlichen Cloud-Code-Fenstern und vier Bildschirmen und einem Mikrofon davor und dann wird von einem zum nächsten und so weiter?
Oder wie sieht das aus?
Bis auf die vier Bildschirme ist das Bild gar nicht so schlecht.
Also vermutlich, oder?
Realistisch nicht alle mit sechs Cloud-Fenstern und einer Farm an Agents.
Also das ist schon eher auch singulärer.
Aber ja, es entwickelt sich immer mehr in diese Richtung und auch in die Richtung, dass die Eingabeform immer mehr von Tastatur zu Voice.
weil es einfach die Wahrheit ist, dass man schneller sprechen als tippen kann.
Mit all den Vor- und Nachteilen, die damit kommen.
Aber genau das ist die Richtung, die wir sehen, ja.
Ja, aber jetzt noch mal eine andere Frage.
Wie gut können so Coding-Agents wie Cloud Code schon mit eurer auch Legacy-Codebase umgehen?
Schaffen die das schon zu verstehen, wie eure gesamte Codebase strukturiert ist und wie sie dort reinarbeiten können?
Oder müsst ihr das nochmal separieren?
Oder wie macht ihr das?
Weil ich stelle es mir sehr einfach vor, wenn ich jetzt auf der grünen Wiese starte und quasi meine ersten Prompts reinspreche und dann fängt er an, die ersten Zeilen Code zu schreiben.
Aber der muss ja, das was da gebaut wird, muss ja in eure bestehende Infrastruktur reinpassen.
Ja, das ist in der Tat eine Herausforderung, vor allem gewesen ist es auch heute noch.
Aber gerade in den Anfängen von AI-Assisted Coding war Kontext ein deutlich größeres Problem.
Wir haben jetzt mehrere Entwicklungen, die uns da in die Karten spielen.
Das eine ist Kontextgröße.
Nimmt zu.
Wir sind jetzt teilweise bei einer Million Token.
Das andere, was wir sehen, ist Tooling drumherum, also auch Tooling, was wir geschaffen haben.
Wir haben unter anderem unsere gesamte Codebase indiziert in der Vektordatenbank als MCP bereitgestellt, sodass sie tatsächlich aktiv als Kontext benutzt werden kann von Cloud Code.
Wir haben das Gleiche für all unseren Observability-Stack.
gemacht, sodass wir auch Inzidenz live über MCP erfassen, sehen und damit arbeiten können.
Das alles hilft, um den Kontext zu setzen und deutlich spezifischer auch mit Cloud Code in dieser Form arbeiten zu können.
Dazu kommen spezifische Skills, die wir in XDA Repository für uns halten, die genau diese Sachen mobile.de spezifisch für uns bereitstellen, die wir auch an alle Teams und Engineers rausgeben, sodass wir das schon sehr spezifisch machen können.
Dennoch gibt es ein paar technische Herausforderungen, die lösbar sind.
aber die aus einer Tatsache stammen, dass vorher die Arbeit gänzlich von Menschen gemacht wurde.
Also Stichwort Microservices-Architektur.
Wir haben Dinge in Microservices runtergebrochen, vor allem um den Kontext für den Menschen zu kapseln und erfassbar zu machen.
Wir haben Arbeitsteilungen betrieben, Frontend, Backend, Native Apps und haben Repositories eben auch so, aufgebaut.
Wenn ich über was ist eigentlich perfekt für eine Maschine nachdenke, dann ist es wahrscheinlich nicht dieses Setup.
Und dann spricht man jetzt auf einmal wieder von Mono-Repositories, wo man Dinge wieder zusammenführen möchte oder bestenfalls von Anfang an genauso handhabt.
Das sind Herausforderungen, für die gibt es Lösungen.
Zum Teil Lösungen, die wir geschaffen haben, zum Teil Dinge, Wo man auch darauf vertrauen kann oder jetzt auch schon sieht, das Problem hat nicht nur mobile, das Problem haben eine Million Companies da draußen, die schon länger existieren als zwei Jahre und sich einfach sehr smarte Menschen diesem Problem schon angenommen haben und man dafür eine Lösung findet.
Aber genau diese Schritte helfen dann einfach nochmal.
den Kontext spezifischer zu machen und eben auch den Agents das Leben zu vereinfachen in so einem Brownfield, wie das halt so ist, wenn man 30 Jahre jetzt schon dabei ist, dann auch effektiv arbeiten zu können.
Ja, Wahnsinn, wie sich das entwickelt hat.
Ich erinnere mich noch, wie wir vor drei Jahren unseren Entwicklern GitHub-Copilot bereitgestellt haben und der konnte dann so gerade so helfen, so den geschriebenen Code noch zu vervollständigen und das war schon so.
Eye-Opening, aber da war nicht daran zu denken, dass der irgendwie die Codebase versteht oder so.
Das sind halt einfach drei Jahre.
Ja, da waren die besten Tipps noch, die drei Files, um die es geht, in Tabs offen zu haben in deiner IDE, damit es im Kontext ist.
Davon sind wir weit weg und es klingt wie vor 20 Jahren und nicht wie vor 18 Monaten.
Jetzt arbeitet ihr mit Cloud Code.
Unfassbar populär geworden.
In Tropic reitet die Welle gerade.
Aber es gibt ja auch noch so ein paar andere Spieler auf dem Markt.
Was hat euch zu der Entscheidung bewogen?
Wie seid ihr da aufgestellt?
Ist das was, wo ihr sagt, da geht ihr all in oder guckt ihr euch das regelmäßig an?
Wie denkst du da über den Stack nach?
Genau, also ich hatte ja gesagt, eingangs waren wir bei GitHub GoPilot, lag einfach nahe, weil wir wie viele andere GitHub-Kunden sind.
Das hat sich dann relativ schlagartig geändert.
Wir haben ein Proof of Concept in der Gruppe, zu der wir gehören, gemacht.
Also die Adewinter Group hat ein POC gemacht.
Da haben wir mit mehreren Teams ebenfalls teilgenommen, wo wir gebenchmarked haben, also die Cursor, GitHub Copilot, Cloud Code und Co.
Ich glaube zu dem Zeitpunkt noch Windsurf, Antigravity gab es da glaube ich noch nicht.
Und haben gebenchmarked über mehrere Teams, mehrere Plattformen hinweg und versucht aufgrund von Schätzungen, wie lange hätte mich die Arbeit gekostet.
Ohne Support.
Wie lange hat sie mich gekostet mit dem jeweiligen Tool?
Und haben das über zwei Monate gemacht.
Hat jetzt natürlich keine perfekte wissenschaftliche Signifikanz, aber der Abstand war einfach so groß zu dem Zeitpunkt, dass klar war, okay, das ist auf jeden Fall erst mal das Tool der Wahl für uns.
Wir machen das jetzt kontinuierlich, dass wir auch Newcomer damit reinnehmen und immer mal wieder Teams auf diesen POC-Fahrt schicken, um zu testen, was möglich ist.
Es ist natürlich immer mit ein Stück Aufwand verbunden, mit einem Stück Reibung verbunden, wenn man dann sich auf ein Tooling festgelegt hat und dann wieder Experimente nach links und rechts macht.
Stand heute würde ich sagen, ist halt immer noch Entrific, die sich auch einfach spezialisiert haben auf Software Engineering und den Vorsprung sieht man halt nach wie vor.
Ihr übernimmt jetzt also einen immer größeren Anteil der Ausführung von Arbeit bei dir im Team.
Was macht das denn mit den Rollen?
Wie verändern die sich?
Jetzt gibt es ja nicht nur Engineering, sondern es gibt ja auch die Produktteams.
Du hast darüber gesprochen, dass zwei Dinge, die ich interessant fand.
Der eine war, der Intent, also was wollen wir überhaupt entwickeln, wird ja immer wichtiger, wenn alle immer schneller entwickeln können, kommt es immer mehr auf die Qualität der Idee an, die wir da vorne reinstecken.
Und das Zweite ist auch, dass man es den Kunden erklärbar machen und nutzbar machen muss.
Also das Nutzererlebnis wird ja wahrscheinlich auch nochmal immer, wichtiger, wenn alles immer schneller wird.
Wie entwickeln sich diese Rollen bei euch weiter?
Ja, da sind wir vermutlich noch, also wie wahrscheinlich alle, am Anfang.
Eine Beobachtung, die wir jetzt schon haben und wir haben Teams auch in unterschiedlichen auch wieder Experimenten im Moment.
Aber was wir beobachten, ist, umso mehr Agentic Engineering das Tagesgeschäft ist, also umso wichtiger auch im Specs-Driven-Development die Specs zu Beginn sind, umso mehr verschmelzen eigentlich Rollen wie UX, Product und Engineering, wo es früher mehr oder minder klare Handover zwischen den Gewerken gab.
Heute sehen wir einen großen Wert, wenn...
diese Art von Rollen zusammenkommen und zusammen genau in dieser Spezifikation zusammenarbeiten.
Also ein Trio aus einem Product-Menschen, einem UX-Menschen, einem Engineer zum Beispiel.
Exakt.
Und das ist, glaube ich, auch gegründet auf der Tatsache, dass wir diese Rollen in dieser Dediziertheit haben.
Wenn ich jetzt mit ...
Unternehmen, die über die letzten zwei, drei, vier Jahre entstanden sind, spreche, dann ist da häufig die Rede von Product Engineer.
Also Engineers, die eine hohe Affinität oder auch ein Interesse haben, sich mit dem Business auseinanderzusetzen und auch mit Product Management auseinanderzusetzen und End-to-End die ganze Linie.
von ich verstehe das Business-Problem, ich kann es übersetzen in eine Product-Idee, in einen Intent und kann es so spezifizieren, dass es auch eine gewisse technische Tiefe hat und könnte sogar am Ende validieren, ob das, was der Agent gebaut hat, technisch auch fit for purpose ist.
Eine andere Rolle, die ich da immer wieder höre, ist dann Plattform-Engineer.
Das kommt wahrscheinlich unseren heutigen Engineern noch näher, weil sie dann Product Engineer sind die, die aber in einer rein technischen Domäne unterwegs sind, also wenig User-Facing-technische Artefakte bauen, sondern Plattform-Capabilities.
Heute in einer Struktur wie bei uns, wo wir Product UX und Engineering haben, wird es eine Zeit brauchen, das verschmelzen zu lassen und auch zu sehen, wie man diese Transition begleiten kann.
Was wir aber auch sehen ist, viele Produktmanager kommen aus dem technischen Feld oder waren mal Engineers, haben auch was Technisches studiert.
Also da sehe ich ganz viel, dass sie ohnehin auch jetzt schon Cloud-Code nutzen und gerne mehr machen würden.
Genauso habe ich ganz viele Engineers, die sagen, ganz ehrlich, mir fallen hier auch 23 Sachen ein, wenn ich auf dieses Produkt denke.
Und das sind genau die Profile, die wir brauchen, wenn es um Product Engineers geht.
Ich habe aber auch durch die Größe der Plattform auch Cross-Cutting-Concerns, also Authentifizierungsservices, Builderservices, wirklich eine Art Capability sind, die der ganzen Plattform zur Verfügung stellen, wo ich eben auch Plattform-Engineer brauche.
Also auch da wird eine Entwicklung hingehen.
Das eine ist also, wie werden sich Rollen verändern und werden wir diese Dediziertheit der Rollen noch haben, wo ich glaube, da wird es eine Verschmelzung geben.
Ein zweiter Aspekt ist, ich glaube, es wird eine Veränderung geben in der Zusammensetzung einer Engineering Org.
Was ich damit sagen will, ist, es wird eine Verschiebung geben, dass es bestimmte Rollen auch mehr braucht.
Also ein Beispiel, was ich ganz deutlich sehe, ist deutlich mehr Security-Rollen.
Denn AI wird dort draußen auch für Dinge benutzt, die jetzt nicht unbedingt...
Positiv sind.
Also das Thema Phishing-E-Mails, die verblüffend echt aussehen, deutlich professionelle Angriffe, auch technischer Natur, auch auf Plattformen wie mobile.de, sind einfach an der Tagesordnung.
Also Security ist definitiv ein Bereich, wo ich mir vorstellen könnte, dass deutlich mehr Rollen dorthin gehen.
Und auch vielleicht in einer technischen, AI-spezifischen Ausgestaltung auch wieder Quality Assurance.
Eine Rolle, die es so ein bisschen im Fadeout war im Engineering, sehe ich zumindest im Moment einen stärkeren Need, wieder diese Rollen zu haben, wenn es darum geht, wirklich zu verstehen.
Ist das, was wir da shippen, nachdem ein AI-Agent das gebaut hat, ist das eigentlich gut?
Können wir das vor die Nutzer setzen?
Funktioniert das in Production genauso, wie wir uns das gedacht haben?
Und schlussendlich vielleicht der letzte Trend, den ich zumindest wahrnehme, ist die Größe von Teams, die in der Vergangenheit bestimmt war durch ownership an technischen Artefakten, die Teams hatten und Gewerken, die es brauchte, um ein Produkt zu Ende zu bauen.
Da hatte man irgendwie Frontend, man hatte Backend, man hatte Native Engineers für iOS und Android, vielleicht noch ein Data Engineer und die Erkenntnis ist, Cloud Code interessiert nicht, ob es Frontend, Backend oder dataspezifischen Code schreibt.
Und damit sehe ich kommen, dass es kleinere Einheiten an Teams gibt, die einen gewissen Scope bedienen.
Das heißt nicht weniger Menschen, sondern wirklich kleinere Einheiten, die schneller in ihrer Domäne Entscheidungen treffen können und dann mit Agents ihre Produkte bauen.
Kurz in eigener Sache.
Wenn dir der AI-First-Podcast gefällt und du mehr spannende Inhalte und hochkarierige Gäste hören möchtest, dann freue ich mich über deine Unterstützung.
Mit einer 5-Sterne-Bewertung und einem Abo für den Podcast hilfst du uns, sichtbarer zu werden und AI-First weiterzuentwickeln.
Für dich und die gesamte Community.
Ich danke dir.
Wenn du jetzt noch mal in deine Software-Engineering-Karriere starten könntest, in der jetzt heutigen Welt, was wären Fähigkeiten, die du dir drauf schaffen würdest, weil du glaubst, dass sie in Zukunft immer wichtiger werden?
Ja, spannende Frage.
Ich glaube, ein paar Punkte vielleicht dazu.
Das eine ist vermutlich jetzt in der Tiefe sich auf eine Programming Language festzulegen und da Koryphäe werden, ist vielleicht nicht mehr der Weg.
Ich glaube, das architektonische Verständnis, also wie Systeme funktionieren, also auch da den Konzernen ein Level nach oben zu verlegen und zu sagen, wie funktioniert eigentlich Systems Engineering, wie funktionieren Architekturen, auch Themenbereiche wie Security.
Das wären definitiv Themen, die ich deutlich mehr vorstelle.
in den Fokus setzen würde, weil ich nach wie vor glaube, auch in einer Welt, wo AI-Agents den Code generieren und viel der Arbeit abnehmen, solange wir wollen, und das sehe ich auf mittellangfristigen Zeit auch noch so, dass dieser Human in the Loop ist, braucht es Menschen, die verstehen, wie solche Dinge in Gänze funktionieren.
Und das wären genau die Skills, auf die ich setzen würde.
Der generell aber wichtigste Skill, und da ist es eigentlich egal, ob Engineering oder Marketing oder eine Businessrolle, ist das Lernen schnell zu lernen und vor allem das neugierig sein und Dinge auszuprobieren.
Denn das, was ich in der ganzen Adoption-Journey von AI-Tools...
grundsätzlich sehe.
Die Leute, die neugierig sind und offen und da einfach Bock drauf haben und nicht ausschließlich Risiko in dem sehen, was kommt.
Das sind die Leute, die am schnellsten wissen, wie die Tools funktionieren und da auch den höchsten Wert draus ziehen können.
Und das ist für mich auch so ein bisschen die These, warum ich nicht sehe, wenn es heißt, irgendwie Die Juniors kriegen keine Jobs mehr in diesem Markt.
Glaube ich, die Juniors sind genau die, die wahrscheinlich noch am offensten sind, diese ganzen Tools auszuprobieren und wahrscheinlich auch am experimentierfreudigsten.
Also lasst uns dieses Kapital nutzen und die Leute reinbringen, um die Organisation einfach voranzubringen.
Sehr schönes Statement.
Also ich fasse nochmal zusammen zu den...
Rollen, wie verändern die sich?
Also was ich jetzt mitgenommen habe, ist, Product, UX, Engineering wächst tendenziell stärker zusammen.
Also ein Product Manager kann jetzt auch schon mal coden.
Der Engineer kann wiederum stärker auch in die Product-Richtung arbeiten.
Product Engineering-Rollen, die siehst du, kommen immer mehr.
Auf der anderen Seite braucht es Platform Engineers, die, wenn immer mehr gebaut wird, mehr stabile Infrastruktur bereitstellen.
Und dann hattest du aber auch gesagt, so an kleinere Teams glaubst, die enger zusammenarbeiten können.
Da würde mich interessieren, wie handelt, weil kleinere Teams haben ja auf der einen Seite reduzieren sie Komplexität innerhalb des Teams, weil es kleiner ist.
Auf der anderen Seite hast du ja dann immer noch die gleiche Anzahl an Menschen auf viele kleinere Teams.
verteilt, wo dann wieder die Arbeit koordiniert werden muss.
Wie geht ihr denn damit um?
Ich glaube, dafür gibt es einfach noch keine perfekte Lösung.
Eine Organisation hat einen gewissen Overhead, was einfach Abstimmungsbedarf ist.
Und ich habe jetzt schon mehrere Reorganisationen auch in der Pre-AI-Ära erlebt.
und gesehen und auch bei Reorganisationen glaube ich immer dran, dass man immer nur Probleme gegeneinander eintauscht.
Das ist einfach der Fakt.
Es gibt nicht die perfekte reibungslose Organisation.
Ich kann mich dafür entscheiden, in welche Richtung ich optimiere.
Also für was optimiere ich?
Ich kann total für Speed optimieren und einfach Abstimmung aussetzen.
Dann werde ich aber andere Probleme haben, nämlich, dass Dinge nicht mehr zusammenpassen.
Und ich kann es aber auch in die andere Richtung treiben.
Ich kann die perfekte Abstimmung machen und ich habe immer alle abgeholt, aber ich bin unglaublich langsam.
Und genau so sehe ich das eigentlich, wenn es um diesen Punkt geht.
Am Ende eine Konsequenz, die ich im Moment sehe, ist, wir werden vermutlich kleinere Team-Einheiten haben.
Die Frage ist, wie baue ich dann die Organisation darum auf?
Ein Thema ist, werde ich einfach die doppelte Anzahl Teams haben und alle bauen ...
Consumer-Customer-Facing-Dinge oder kann ich meine Organisation auch anders schneiden, dass ich ein Stück Abstimmungsaufwand rausnehme, indem ich eben die Plattform-Capabilities vielleicht anders handhaben kann, als ich Customer-Facing-Themen handhaben kann.
Das zweite Thema, was ich sehe, in der Vergangenheit war es so, dass wir ein relativ festes Ownership pro Team hatten.
Und gesagt haben, okay, hier das Team und irgendwie das Leasing-Produkt für Händler und das nächste Team das Leasing-Produkt für den Konsumenten und so weiter.
In einer Welt, wo Onboarding nichts mehr kostet.
Also wir sehen ganz klar ...
Time-to-Tents-PR, also das ist so eine Metrik, wo wir mal schauen, wie gut funktioniert Onboarding, also bis ein Entwickler das zehnte Mal einen Pull-Request gemacht hat, so diese Timespan, die ist bei uns krass gesunken.
Klar, wenn ich Tools zur Verfügung stelle, die mir auf jede Frage zu der Codebase eine Antwort geben können, ist es deutlich einfacher, als wenn ich mich in eine Legacy-Codebase einarbeiten muss per Hand, indem ich irgendwie mich durch alle Services klicke.
In einer Welt, wo das quasi nicht mehr ein Constraint ist, muss ich dann überhaupt noch jedes Team mit einem festen Ownership versehen?
Oder kann ich nicht Teams an die Stellen packen, wo gerade was zu tun ist?
Und in Einheiten, wo dann eben gar nicht mehr so viel Abstimmungsbedarf in den jeweiligen kleineren Aspekten ist?
Denn die Abstimmungsbedarfe sind ja häufig eher größere Trade-offs, die ich auf Company-Ebene machen muss.
Und dafür braucht es auch eine Lösung.
Aber die Theorie oder vielleicht die Hypothese, die ich habe, ist, wir werden vermutlich gar nicht mehr so eine starre Zuordnung von Product- und Tech-Teams oder Agentic-Enabled-Teams zu einzelnen Artefakten und Domänen haben müssen.
Was glaubst du, was der größte Bottleneck sein wird, wenn wir da mal die Fähigkeiten der KI-Modelle weiterdenken?
Die agentischen Fähigkeiten drumherum werden immer besser, das Tooling drumherum wird immer besser.
Du hast Menschen, die immer besser lernen, damit zu arbeiten.
Was ist dann der größte Engpass, der gelöst werden muss, um das Potenzial wirklich heben zu können, deiner Meinung nach?
Und was glaubst du, ist das Endgame?
Wie weit kann das gehen?
Und pendeln wir uns einfach auf so einem neuen Normal ein, was einfach unfassbar schnell auch Produkte weiterentwickelt, zu einer enormen Personalisierung in Produkten, Märkten führen kann, weil auf einmal dieser Bottleneck nicht mehr da ist.
Weil ich glaube, wahrscheinlich ist der Bottleneck die Aufmerksamkeit, die Menschen haben und wie schnell sie überhaupt noch irgendwas aufnehmen können.
Das ist ja zumindest das, was mir in den Kopf kommt.
Aber was sagst du?
Ja, da stecken eine Menge Fragen und interessante Hypothesen und Antworten drin.
Ich glaube, der erste mittelfristige Bottleneck ist eigentlich, dass es eben nicht mehr die Frage ist, können wir das bauen und liefern?
sondern die Frage immer mehr wird, wissen wir eigentlich gut genug, was wir bauen wollen?
Also haben wir eine Idee?
Haben wir den Intent verstanden?
Haben wir verstanden, wie die Lösung dafür produktseitig aussehen kann?
Das Positive ist, und in der Vergangenheit war das immer so ein interessantes, gemischtes Gefühl bei mir.
Wir haben immer so in Vorbereitung von ...
Budget und Annual Planning machen wir was, das nennt sich quasi so Opportunity Writing.
Also alle in der Company können Opportunities schreiben.
Was sollten wir eigentlich als mobile Idee tun, um unsere Kunden glücklicher zu machen, um Geld zu verdienen und so weiter.
Da kommen hunderte von Opportunities zusammen und dann gehen wir so in die realistische Auswahl von, dann kommen so Constraints dazu wie, ach so, wir haben eine gewisse Anzahl an Leuten, irgendwie gibt es auch ein Budget und so weiter.
Und dann ist immer so dieser Realismusaspekt drauf und auf einmal schmeißt du 75 Prozent der Opportunities weg, weil du sie nicht machen kannst.
Also ich mache mir jetzt wenig Gedanken darüber, ob wir genug Ideen haben, was wir noch alles machen könnten.
Also bestenfalls.
Noch?
noch bestenfalls ist es so ein unlock dass wir jetzt endlich deutlich mehr von dem machen können was wir gerne machen würden das sehen wir auch jetzt schon wenn ich mir den verlauf über die letzten zwei jahre anschaue und auf jetzt mal stumpf auf output gucke ist es einfach so dass wir unglaublich viel mehr jetzt schon machen Und wir wissen ja auch, irgendwie das Ramp-Up-AI-Coding ist über die letzten 12, 18 Monate eigentlich erst richtig abgegangen.
Also wir machen schon deutlich mehr.
Wir sehen eine deutliche Reduktion auch von Lead-Time, wenn ich mir First Commit to Merge anschaue.
Also wir sehen, wir machen schon schneller Dinge, wir machen mehr Dinge.
Also das sehe ich deutlich.
Zum Endgame.
Das ist natürlich so die Frage, über die wir alle nur spekulieren können.
Heute ist es so, dass, also heute und auch in der näheren Zukunft, die wir bisher besprochen haben, so dass natürlich irgendwie der Mensch das Bottleneck ist in der ganzen Nummer.
Entweder beim Review, beim Go-to-Market, beim Planen und Entscheiden.
Ich glaube, das...
wird auch eine ganze Weile so bleiben.
Ein Vollagentic Endgame könnte natürlich sein, die Vollagentic Company, wenn man sich darauf einlassen möchte.
Da bin ich mir nicht sicher, ob das dann tatsächlich so passiert.
Zu deiner anderen Frage, was wird mit dem Mensch passieren?
Ich glaube, durch die verendete Rolle, beobachte ich vor allem eine Sache und das ist sowohl in Enterprise AI so als auch im Engineering, die Dinge werden wieder schneller.
Wie mit jedem größeren technologischen Wandel werden Dinge schneller.
Das ist auch bei AI so, möglicherweise sogar noch deutlicher als bei anderen Technologien.
Gut, von Telegramm zu Telefonat, zu E-Mail, zu Slack.
Ist auch schon ein ganz schöner Beschleuniger gewesen.
Bei AI aber in einem deutlich kürzeren Zeitraum noch schneller.
Also Leute machen einfach noch mehr, noch schneller.
Das, was ich früher gedacht hätte, was ich in drei Tagen erledigen kann, mache ich heute an einem Vormittag.
Und das beschleunigt natürlich auch wieder das Leben aller anderen.
Und es ist leider ein interessanter Mythos, dass dann kommt AI und dann automatisiert es mir mein halbes Leben weg und ich habe jetzt Freizeit.
Das passiert ja nicht, sondern es gibt immer mehr zu tun.
Es gibt immer mehr Arbeit, es gibt immer mehr Möglichkeiten.
Also es ist eine Beschleunigung, was auch dazu führt, dass deutlich mehr Kontextwechsel bei jedem Einzelnen.
an jedem Tag, in jeder Stunde und Minute stattfinden.
Und wenn es einen Bereich gibt, in dem es genug Research gibt, dann das Kontextwechsel für menschliche Gehirne eher schwierig sind, ermüdend und wahrscheinlich auch nicht ganz gesund.
Und das, glaube ich, sieht man heute schon im Enterprise AI-Kontext, aber eben auch im Software Engineering.
Also du hast vorhin gesagt hier, sechs Cloud-Code-Fenster mit jeweils einer Farm an Agents.
Und ja, die wollen alle andauernd was von mir in unterschiedlichen Kontexten.
Und natürlich ist das ermüdend und hat Auswirkungen auf, wie mein Arbeitsalltag aussieht.
Und das Gleiche ist natürlich auch, wenn ich einen Schritt vorher schaue, selbst bei ...
nicht komplett agentic.
Und ich bin der Human in the Loop, der die ganzen Pull-Requests reviewt, bevor sie irgendwie live gehen sollen.
Das sind tausende Zeilen an AI-generated code.
Und dann ist das wahrscheinlich auch jetzt keine einfache Aufgabe, das zu durchdringen, was da passiert ist und komplett konzentriert am Ball zu bleiben.
Und wenn dann noch eine andere AI den Pull-Request schon vor mir gereviewt hat und so sagt, ja, passt schon so und hier noch zwei Dinge, aber habe ich eigentlich auch schon dann gefixt für dich, dann macht das ja auch was mit dem menschlichen Gehirn.
Und ich glaube, diese Herausforderung, also wie findet der Mensch in diesem ganzen Konstrukt statt?
Und wie ...
umgehe ich eigentlich, dass das menschliche Gehirn in irgendeiner Form auch immer einen einfachen Weg sucht, dass sich trotzdem am Ende der Human in the Loop überhaupt lohnt.
Weil in dem Moment, wo das Gehirn aus ist und ich nur auf irgendeinen Button in GitHub klicke, hat das wahrscheinlich wenig Wert.
Ich glaube, da wird es noch die wildesten Studien geben, was diese neue Arbeit mit unserem Gehirn macht und was da eigentlich passiert.
Ich glaube, es ist eine riesengroße Challenge, die ich von vielen Menschen höre.
Mir selbst geht es auch so.
Es ist leicht gesagt, sich kritisches Denken zu erhalten und es ist doch so schwer.
wenn man mit einer Technologie arbeitet, die so viel intelligenter in Anführungszeichen wird oder immer besser darin wird, das zu simulieren, sich das trotzdem zu erhalten, das ist eine große Challenge.
Lass uns abschließend nochmal über den Elefanten im Raum sprechen.
Denn natürlich glaube ich total daran, dass KI ein Anlocker ist, um Dinge zu heben, die vorher nicht möglich waren.
Und auch, dass sich Rollen in bestimmte Bereiche verändern und Security relevanter wird, alles gekauft.
Aber auf der anderen Seite haben wir jetzt auch einfach eine Technologie, die eine Sache sehr, sehr gut kann, die vorher sehr viele Menschen gemacht haben und immer besser darin wird.
Und die Frage ist natürlich schon, was macht das mit mir und vielleicht auch meinem Job?
Und da interessiert mich, wie geht ihr einfach damit um, dass dass da auch das richtige, dass mit dem richtigen Mindset im Team darauf reagiert wird und es nicht so Revierkämpfe gibt und irgendwie die Jobangst im Vordergrund steht, sondern eher die neuen Möglichkeiten und irgendwie der Wille, diese Veränderung positiv zu gestalten.
Ja, in der Tat eins der schwierigsten Themen und wir haben schon eine Reihe an schwierigen Themen angeschnitten, aber das wahrscheinlich nochmal Im Besonderen.
Und ich glaube, das liegt in der menschlichen Natur, dass Veränderung eben nicht nur positiv und mit offenen Armen empfangen wird, sondern auch Ängste mit sich bringt.
Und wie du gesagt hast, AI ist halt einfach verdammt gut in vielen Sachen.
Und in dem Fall von Software Engineering kommt dann noch dazu, dass AI hier ein...
Skill mitbringt, auch den Output da deutlich erhöht.
Das alleine entwertet ja auch schon so ein Skill.
Und dass da natürlich jetzt auch Vorbehalte da sind, ist, glaube ich, kein Geheimnis.
Das sehen wir in der ganzen Industrie.
Wir sehen einen unglaublichen Hype und gleichzeitig Vorbehalte.
Und das ist auch das Spannungsbild, was glaube ich, so alle CTOs, mit denen ich spreche, auch in ihren Organisationen sehen.
Das eine ist, aus einer Position von Stärke zu kommen als Unternehmen, so wie wir, wo du wirtschaftlich einfach sehr, sehr gut dastehst, hilft ungemein, deine Sicherheit auszustrahlen.
Das andere ist, dass wir eine positive Sprache verwenden, versuchen die Leute mitzunehmen, sie auch einzuladen, ganz viel zu testen.
Wir haben eine Champions-Gruppe aufgebaut im Software Engineering, die quasi diese Adoption treiben, aber gleichzeitig auch diese Vibes in der Organisation wahrnehmen und auch an mich mit zurückspielen, dass wir es aktiv adressieren können.
Das heißt nicht, dass wir alle Ängste nehmen können.
ist, glaube ich, schwierig, auch wenn man einfach schaut, wie schnell sich dieser Bereich entwickelt.
Und das, hätten wir diesen Podcast vor zwölf Monaten aufgenommen, hätte er komplett anders ausgesehen.
Wahrscheinlich hätte es schon zwei Monate gereicht.
Deswegen die Halbwertszeit von dem, was wir glauben, gerade State of the Art ist, die Halbwertszeit von dem, was wir glauben, wie die Welt in sechs Monaten aussehen könnte.
Und ich weiß nicht, ob ich Wetten für sechs Monate überhaupt abgeben würde.
Das ist einfach, schwierig und ja auch nicht nur eine Angst, die in den Engineer-Köpfen ist, sondern ja auch bei mir zum gewissen Teil.
Und einfach auch das zu teilen, zu sagen, hey, wir sind hier auf einer Reise, die hat die Menschheit so noch nicht gesehen.
Das ist jetzt nicht irgendwie so ein Copycat-Change, den ...
50.000 Firmen schon vor uns durchlaufen haben und guck mal, das ist das Pattern und so macht man das und das ist das Ergebnis, sondern wir durchlaufen ein Change, dessen Ende wir nicht kennen.
Wir kennen die Regeln davon nicht und wir wissen auch nicht, wie die Realität am Ende aussieht.
Und wir alle haben unsere eigene persönlichen Ängste, Hoffnung da dran.
Und wie gesagt, ich merke es an mir.
Ich freue mich wie ein kleines Kind, wenn ich mit Cloud Code wieder mal mir ein Tool bastle, wofür ich sonst nie Zeit gehabt hätte, was mir aber meinen Tag erleichtert.
Auf der anderen Seite frage ich mich natürlich auch, okay, wie sieht denn so eine Engineering-Org in drei Jahren aus?
Und was ist eigentlich der Weg dahin?
Und was sind all die Schritte, die wir gehen müssen?
Am Ende ist der einzige Weg, den wir gerade gehen können.
Und da komme ich zurück zu, was sind die Skills, die wir brauchen?
Lernen und Offenheit.
Also wir machen Experimente und POCs auch in Team-Setups, in wie Teams miteinander arbeiten, im Tooling und versuchen uns da ranzutasten und versuchen genau die Dinge zu adaptieren, die dann in den Experimenten funktionieren und auf andere Teams auszurollen.
Das andere, was wir uns natürlich anschauen, ist, Wenn jetzt Leute das Unternehmen verlassen und wir vor der Frage stehen, wie besetzen wir die Rolle jetzt eigentlich nach?
Dann zu sagen, Moment, halt mal, also sollten wir diese Rolle exakt so nachbesetzen oder haben wir eigentlich höheren Bedarf an Security oder heilen wir jetzt unseren ersten, okay, erster stimmt nicht mehr, aber heilen wir jetzt Product Engineers, also Leute, die tatsächlich diese diese Art von verschmolzene Rolle schon personifizieren.
Also das sind so die Sachen, die wir tun und dabei halt versuchen, die Organisation und die Menschen mitzunehmen auf der Reise und auch einfach rauszukriegen, was beschäftigt sie und wie können wir da Dinge tun, auch in dem Wissen, dass wir nicht immer all die Ängste adressieren und ausräumen können.
Du hast jetzt einiges schon ausprobiert und gelernt auf dem Weg.
Es gibt aber auch noch Engineering Leader, die vielleicht noch weiter vorne stehen und das Thema gerade erst in ihr Team bringen.
Was würdest du denen mitgeben auf dem Weg?
Als allererstes, und das hilft mir immer sehr, unterhaltet euch mit Peers.
Und zwar Peers nicht nur aus der gleichen Gruppe von Unternehmen.
also jetzt in unserem Fall irgendwie etabliert, gut Geld verdient und eine gewisse Größe, sondern sprecht mit Startups.
Hört euch an, wie die heute mit fünf Leuten Dinge bauen.
Sprecht auch mal, ist auch sehr erfrischend, mit Unternehmen mit 10.000, 15.000 Mitarbeitern und hört euch an, wie die das machen.
Einfach, um auch so dieses Spannungsfeld zu haben.
Das andere, eat your own dog food, habe Cloud Code und baue damit Dinge und versuche auch Dinge in deinem Kontext zu bauen und frage dich, geht das eigentlich gut, was brauche ich hier eigentlich noch, um das zu machen?
Und der letzte Punkt, und das ist so das generelle Thema Adoption, finde die Leute, die die Verstärker in deiner Organisation sind, hilf denen, ich nenne es immer das Licht zu sehen, also dieses, was kann AI, AI-Tooling und das Engineering-Tooling eigentlich für dich tun und mache die zur Stimme in der Organisation.
Das hilft mehr, als wenn ich jetzt mich persönlich vor die gesamte Tech-Community von Mobilidee stelle und sage, Cloud Code, das ist das neue große goldene Stück und jetzt sollten wir das alle tun.
Es hilft vielmehr, wenn die Leute mit echter Street Credibility, also die Engineers, die vorher auch schon immer durch ihr Expertenwissen, Know-how, die Tiefe, eine hohe Anerkennung der Organisation hatten, wenn die diesen Weg gehen, die nehmen.
die anderen Leute mit.
Und das ist, glaube ich, unglaublich wichtig, dann das Momentum in der Organisation zu entfachen.
Wenn du dir aussuchen könntest, in den nächsten sechs Monaten, du hast gesagt, es gibt keine Prediction, aber ich versuche dir jetzt trotzdem noch eine Kleinigkeit zu entlocken.
In den nächsten sechs Monaten, die Coding Agents werden nochmal 50% besser von dem, was sie heute können.
Und du kannst das nehmen.
Oder du könntest entscheiden, jetzt sechs Monate auf den Pauseknopf zu drücken bei Google OpenAI und Anthropic.
Was würdest du wählen?
Uff, schwer.
Ich glaube, ich würde trotzdem die 50 Prozent nehmen.
Weil ich glaube, die Frustration, die da ist, wenn du eine hohe Adoption hast und siehst, welche Dinge einfach noch nicht so gut funktionieren.
die ist groß, wenn die 50 Prozent das ausräumen oder zum Teil ausräumen können, dann ist das, glaube ich, viel wert, besser als jetzt noch sechs Monate auf dem Level zu sein, wo einfach so dieses Stück Frustration einfach noch da ist, weil Dinge einfach doch noch nicht so gut gehen.
Okay.
David, vielen, vielen Dank.
War sehr spannend.
Ich habe endlich gelernt, was Spec-Driven Development und ein Harness und so weiter bedeutet, wie sich Teams jetzt verändern können und wo doch noch die Bottlenecks liegen.
Danke für deine Einblicke und weiterhin viel Erfolg euch.
Danke dir.