Wie sieht exzellente Ingenieursarbeit im Zeitalter der KI aus?

Lesen Sie das Transkript:

Wir probieren gerade aus, unsere Podcasts mit einem Softwareprogramm zu transkribieren. Bitte entschuldigen Sie eventuelle Tippfehler, da der Bot nicht immer zu 100 % korrekt ist.

Hannah Clark: Es ist schon fast zum Witz geworden, wie das Zeitalter der KI zum Untergang jeder Tech-Jobrolle geführt hat. Tatsächlich sind allein dieses Jahr so viele Jobs weggefallen, dass ich überrascht bin, nicht zu mehr Beerdigungen eingeladen worden zu sein. Produktmanagement ist tot, User Research ist tot und – am gravierendsten – Software Engineering ist tot. Wahrscheinlich predige ich hier für den Chor, aber jeder, der wirklich glaubt, Softwareentwicklung sei tot, nur weil Ihr freundliches LLM aus der Nachbarschaft Code schreiben kann, ist definitiv selbst kein:e Ingenieur:in.

Mein heutiger Gast, Anish Dhar, Gründer von Cortex.io, würde sogar argumentieren, dass Engineering keineswegs tot ist. Es wird einfach erwachsener. Früher war er als Ingenieur bei Uber tätig, und Anish hat Cortex gegründet, um Ingenieur:innen das Verständnis komplexer Code-Bases zu erleichtern. Als Ingenieur und jemand, dessen Nutzer:innen ebenfalls Ingenieur:innen sind, sieht er in diesem Bereich tatsächlich eine Weiterentwicklung von Engineering Exzellenz – und eine Diskrepanz zwischen neuen und alten Messmethoden dafür. Wir teilen Next-Gen-Denken – wie Exzellenz im Engineering gemessen und bewertet wird – und eine heiße Meinung, wie der aktuelle „Vibe Coding“-Hype dazu passt. Los geht’s.

Übrigens, solche Gespräche führen wir wöchentlich – wenn Sie das spannend finden, abonnieren Sie doch! Jetzt aber wirklich los.

Willkommen zurück beim CPO Club Podcast. Heute bin ich mit Anish Dhar hier. Er ist der Gründer von Cortex.io.

Anish, danke, dass du dir Zeit für das Gespräch nimmst.

Anish Dhar: Vielen Dank für die Einladung.

Hannah Clark: Kannst du uns ein wenig über deinen Hintergrund erzählen und wie du zu deiner heutigen Rolle gekommen bist?

Anish Dhar: Ja, absolut. Ich bin Mitbegründer und CEO von Cortex.io. Wir haben das Unternehmen vor etwa sechs Jahren gestartet. Zuvor war ich als Ingenieur bei Uber tätig. Dort begann ich meine Karriere. Viele der Probleme, die ich als Ingenieur bei Uber hatte, waren ausschlaggebend dafür, dass wir Cortex überhaupt gegründet haben.

Zwei enge Freunde von mir. Uber hat eine riesige interne Service-Architektur. Für mich als Ingenieur war es extrem schwierig, verschiedene Teile der Codebasis zu verstehen – besonders als ich neu dazu kam. Es wurden so viele verschiedene Services gebaut. Das brachte eine enorme Komplexität mit sich und ich sprach mit einem engen Freund, der bei einem sehr kleinen Startup namens Lend als Ingenieur arbeitete.

Sie hatten nur etwa hundert Ingenieur:innen, während es bei Uber über tausend waren. Aber wir beide hatten ähnliche Herausforderungen in Sachen Organisation und Verständnis unserer Service-Architektur. Das klingelte bei mir sämtliche Alarmglocken – wenn Uber und ein Startup auf komplett unterschiedlichen Skalenniveaus die gleichen Probleme haben, ist das ein großes Branchenthema.

So kam es zur Unternehmensgründung. Wir waren im Winter 20 im Y Combinator Batch. Heute arbeiten wir mit mehreren hundert Unternehmen zusammen; sie nutzen Cortex, um ihre Komplexität zu managen.

Hannah Clark: Cool. Eine tolle Reise – und es ist immer schön, wenn ein Unternehmen aus einem Problem erwächst, das man persönlich kennt.

Apropos: Wir sprechen heute über Engineering Excellence und wie die im aktuellen Tech-Umfeld aussieht. Ein Thema, das dich durch deine Karriere begleitet hat. Wie definierst du Engineering Excellence im Jahr 2025 und warum wird es gerade für CTOs und VPs of Engineering so zentral?

Anish Dhar: Sehr gute Frage. Bei Cortex haben wir festgestellt, dass sich das Gespräch lange Zeit stark auf die Developer Experience konzentrierte. Und Developer Experience ist wichtig – es geht um simple Dinge, z. B. dass Entwickler:innen beim Firmenstart schnell Zugang zu internen Systemen, GitHub und passenden Tools haben. Oder dass beim Deployment die Infrastruktur so eingerichtet ist, dass man ohne viel Aufwand starten kann.

Doch gerade in den letzten Jahren hat sich die Diskussion von reiner Developer Experience hin zu Engineering Excellence verschoben. Der große Unterschied: Engineering Excellence fokussiert sich auf verschiedene Teams innerhalb der Organisation – wie SRE, Security, Developer Productivity, auch Developer Experience – und ordnet sie klaren Geschäftsergebnissen unter. Das ist der entscheidende Unterschied: Engineering Excellence fragt sich immer: Wie zahlt die aktuelle Arbeit aufs Business ein? Wie werden die Ziele des Gesamtunternehmens, von der CEO-Ebene bis hin zum SRE, beeinflusst? Ein Beispiel: Wenn ein Unternehmen die Kundenerfahrung verbessern möchte – damit Kund:innen das Produkt zuverlässiger nutzen und so den Umsatz steigern – könnte das SRE-Team eine „Production Readiness Checklist“ einführen. Alle Services müssen bestimmte Standards erfüllen, bevor sie deployed werden dürfen. So zieht sich eine Initiative, die im SRE startet, bis zum Geschäftserfolg durch.

Für Teams ist es wichtig, ihre Initiativen so zu denken, weil es den Wert bestätigt und technische Maßnahmen mit den Geschäftszielen verknüpft – und das ist für mich das Wesen von Engineering Excellence.

Hannah Clark: Interessant. Und das ist bestimmt – wie du sicher oft beschreibst – eine nie endende Reise, die viele Disziplinen erfordert und Teamwork voraussetzt.

Erzähl mal von eurem Framework: Was sind die Eckpfeiler? Wie wendet ihr das in eurer Organisation an?

Anish Dhar: Genau, es ist wirklich eine endlose Reise. Viele Unternehmen – ob große mit viel Legacy oder neue, vielleicht AI-first Unternehmen – verfolgen Initiativen rund um Engineering Excellence und benötigen eine durchdachte, teamübergreifende Herangehensweise, um die Business Excellence-Ziele zu erreichen. Unser Framework: Am Anfang steht immer Business Excellence – es gibt unterschiedliche Ziele auf Führungsebene, etwa Innovation beschleunigen und Time-to-Market verkürzen, Kosten senken und Effizienz steigern sowie Qualität und Kundenerlebnis verbessern.

Darunter liegen die Säulen der Engineering Excellence: Teams und Praktiker:innen, die Initiativen für diese Ziele starten. Da geht es z. B. um Velocity, Effizienz, Sicherheit, Zuverlässigkeit. Auch innerhalb der Teilbereiche gibt es Initiativen wie etwa Security-Migrationen, Readiness-Checklisten, Incident-Management-Prozesse – oder das Tracking von DORA-Metriken zur Produktivitätsmessung. Das Fundament jeder Engineering-Exzellenz-Initiative bilden die vier „Cs“: vollständige Transparenz („complete visibility“), kontinuierliche Verbesserung („continuous improvement“), konsistente Developer Experience und natürlich klare Verantwortlichkeiten („clear ownership“). Wer die Codebasis und die Services nicht überschaut oder verantwortet, kann keine Initiativen vorantreiben.

Ohne dieses Fundament ist es sehr schwer, Verbesserungen zu initiieren. Interne Developer Portale (IDPs) können helfen, diese Basis zu schaffen – interne Tools ebenso, aber irgendwo braucht man ein System, das sichtbar macht, was gebaut wird, um Initiativen in Angriff zu nehmen.

Hannah Clark: Ich möchte gern tiefer auf das Thema Messung der Performance eingehen. Es gibt ja durchaus Kontroversen über Metriken wie Lines of Code – wie sollten Engineering-Leader Produktivität ganzheitlich messen, sodass alle „Cs“ und Aspekte berücksichtigt werden?

Anish Dhar: Absolut. Viele Frameworks zur Entwicklerproduktivität setzen auf Lines of Code oder DORA-Metriken und vereinfachen das Produktivitätsverständnis. An manchen Berechnungen ist etwas dran – ja, Lines of Code sind kein aussagekräftiges Produktivitätsmaßstab. Aber wenn jemand quartalsweise konstant null Zeilen Code abliefert, stimmt vermutlich etwas nicht. Es ist interessant, Teams miteinander zu vergleichen, aber die Debatte dreht sich inzwischen kaum noch um „Ich habe die Daten“, sondern: Wie motiviere ich Entwickler:innen, diese Daten zu nutzen und zu verbessern?

Das ist ein anderes, viel schwierigeres Problem. Die Metriken kann sich jede:r über die GitHub API holen – aber das reine Zeigen der Zahlen reicht Entwickler:innen nicht. Sie entwickeln Software fürs Business und wollen effizient arbeiten. Viele CTOs fragen sich heute: Ich habe Daten – wie mache ich sie für Entwickler:innen relevant?

Genau hier spielt Engineering Excellence eine zentrale Rolle – Entwickler:innen, gerade in schnell wachsenden Unternehmen, möchten Produkte bauen, weil sie die Wirkung erleben wollen. Entwicklerproduktivität ist heute nicht mehr „Hier sind Statistiken“, sondern: Das Business verfolgt bestimmte Ziele, die Metriken erzählen eine Geschichte davon – aber für Entwickler:innen muss es in ihrer täglichen Arbeit nachvollziehbar sein.

Das ist der große Wandel, den wir gerade sehen.

Hannah Clark: Gibt es veraltete Evaluierungsmethoden oder KPIs, die abgelöst werden? Und was sind die neuen Bewertungsansätze – kannst du ein Beispiel geben?

Anish Dhar: Gern. Ich sehe Produktivität als Zusammenspiel aus Input- und Output-Metriken. Zu den Output-Metriken zählen viele klassische Frameworks – zum Beispiel DORA-Metriken, die einen ganzheitlichen Blick auf die Performance eines Engineering-Teams geben sollen.

Viele Unternehmen möchten diese Output-Metriken sehen und erfassen – aber dann geht es darum, wie man sie überhaupt beeinflussen kann. Besonders spannend und auch für unser Wachstum bei Cortex verantwortlich ist der Trend zu Input-Metriken, die auf Output-Metriken einwirken.

Beispiel Deploy-Frequenz: Die Deployment-Rate ist ein guter Indikator, wie schnell Produkte ausgeliefert werden – und damit, wie wettbewerbsfähig das Unternehmen ist. Vielleicht entscheidet sich ein Unternehmen, Deploy-Frequenz als Hauptmetrik zu tracken: Ein Dashboard zeigt zweimal pro Woche – Ziel sind vier Deployments. Wie soll ein:e Entwickler:in nun im Alltag mit dieser Zahl umgehen? Bedeutet schneller Deployen mehr Fehler? Geht Zuverlässigkeit verloren?

Hier werden Input-Metriken entscheidend, weil sie die Output-Metriken steuern. Vielleicht wird ein verbessertes Deploy-Process eingeführt, um die Frequenz zu erhöhen. Ein Kunde – O’Reilly – verfolgte eine ähnliche Initiative und trackte Deploy-Frequenz mit unserem Dashboard. Um die Zahl zu steigern, wurden wichtige Guardrails fürs Deployment und klare Richtlinien bezüglich Zuverlässigkeit eingeführt. Schnell-Deploys führten bislang oft zu Fehlern und Bugs – die Folge war Zurückhaltung. Neue Input-Metriken wie „Ist On-Call korrekt eingerichtet?“, „Läuft der Build-Prozess fehlerfrei?“, „Sind die Tests bestanden?“ wurden in einer Production Readiness Checklist zusammengefasst. Entwickler:innen erhielten so eine nachvollziehbare, auf ihre Services zugeschnittene Handlungsanleitung. Das führte zu weniger Incident-Meldungen – und gesteigerter Deploy-Frequenz.

Deshalb sollten Unternehmen Output-Metriken und für Entwickler:innen relevante Input-Metriken als zusammenhängende Story betrachten.

Hannah Clark: Das macht das Thema ganzheitlicher. Bleiben wir beim schnelleren Deployen und werfen einen Blick auf „Vibe Coding“: Die neuen KI-Tools verändern Coding-Workflows massiv. Du hast mal gesagt, dass man sich mit „Vibe Coding“ keine Million Nutzer pro Tag erschleichen kann – eher eine Hot Take, oder nicht? Wie siehst du Realität versus Hype beim Einsatz von KI für produktive Systeme?

Anish Dhar: Heißes Thema! Nahezu jedes Entwicklerteam denkt darüber nach oder nutzt schon KI Coding-Assistenten – etwa Cursor oder andere populäre Tools. Auch unser Team nutzt KI-Assistenten für den Alltag.

Unsere Erfahrung: KI-Coding-Assistants eignen sich hervorragend, um erste Ideen schnell umzusetzen, Prototypen für Frontends zu erstellen oder Funktionsweisen zu validieren. Für schnelle, „schmutzige“ Prototypen oder zur Validierung von Ideen sind sie super – darum gibt es aktuell hier viel Wachstum.

ABER: Keinem Code, der rein „Vibe Coding“-basiert entsteht, würde ich Produktsysteme mit Millionen Nutzern anvertrauen. Aus Erfahrung kann ich sagen: Das Skilllevel entspricht maximal einem oder einer Junior-Entwickler:in, der / die gerade coden gelernt hat. Für echte Systemarchitektur, Skalierung, Betrieb sind Senior Engineers unerlässlich. KI entwickelt sich zwar rasant, aber aktuell verlässt sich kein Unternehmen ernsthaft beim Produktsystem auf Vibe Coding. Übrigens: Die Produktivität steigt durch Coding-Assistenten, aber oft in anderen Bereichen als popkulturell diskutiert wird. Für den Unternehmenseinsatz sind sie heute nicht bereit.

Hannah Clark: Viele finden das nachvollziehbar, insbesondere wenn Außenstehende glauben, die Profession werde durch KI-Tools plötzlich einfacher oder vollkommen automatisiert.

Für Führungskräfte stellt sich die Frage: Wie balanciert man Investitionen in KI-Tools versus Ingenieur:innen-Headcount? Wie misst man Effekt und Berücksichtigung im Budget?

Anish Dhar: Sehr gute Frage – und sehr komplex. Ich halte es für sehr nachteilig, Entwickler:innen den Zugang zu diesen Tools zu verwehren. In den nächsten 10 Jahren wird wohl sehr viel Code KI-assistiert geschrieben – vor allem bei frühen Iterationen. Gerade für Startups oder MVPs kann man mit Cursor und Co. viel schneller Ideen testen, ohne an Skalierbarkeit zu denken.

Langfristig profitieren Teams davon, KI im Lebenszyklus sinnvoll einzusetzen – auch große Unternehmen mit hohen Anforderungen sollten offen sein. Sogar Nicht-Techniker:innen – etwa PMs, TPMs oder Data Scientists mit technischem Hintergrund – können so Ideen eigenständig validieren und produktiver beitragen. Es wäre also wenig klug, hierfür keinerlei Budget bereitzustellen.

Die entscheidende Frage bleibt jedoch: Wieviel Produktivitätsgewinn bringt es wirklich? Praktisch jede:r im Enterprise sucht aktuell eine Antwort darauf. Unsere Kund:innen fragen uns, wie stark z. B. Copilot den Output beeinflusst und ob das tatsächlich messbar ist. Man kann aber Deploy-Frequenz alleine schlecht isoliert betrachten, weil z. B. schlechtes KI-generiertes Coding zu Reliability-Problemen führen kann. Daher ist ein 360-Grad-Blick auf verschiedene Metriken nötig – stets mit Bezug zu konkreten Business-Zielen.

In der Realität sind die Effekte mitunter schwer zu beziffern und werden manchmal überschätzt – sechs Monate später fragt man sich, ob die Massenlizenzen sinnvoll waren. Die Einführung von KI-Tools sollte immer einer klaren Strategie folgen – ob es um Wettbewerb, Innovation oder ein modernes Arbeitsumfeld geht. Wichtig ist, die eigenen Ziele zu reflektieren und nachzuprüfen, ob die Investition tatsächlich die angestrebte Wirkung erzielt.

Hannah Clark: Ich stimme zu: Überall ringt man mit der Spannung zwischen Menge und Qualität. Das zieht sich durch viele Abteilungen und macht deutlich, dass KI-Tools in den richtigen Kontext gebracht und sinnvoll eingesetzt werden müssen – als Ergänzung, nicht als Ersatz, besonders im Hinblick auf den Headcount.

Kommen wir zu Qualität und Sicherheit: Wie erreicht ihr im Unternehmen das Gleichgewicht zwischen Codierstandards, Zuverlässigkeit, Security und dem Drang, State-of-the-Art zu sein?

Anish Dhar: Gute Frage. Erstmal: Die Vorstellung, dass KI Ingenieur:innen ersetzen kann, ist meiner Meinung nach ziemlich abwegig. Eventuell kann ein Early-Stage-Team einige Entwickler:innen weniger einstellen und iteriert schneller – aber spätestens bei Produktsystemen ist jeder Versuch, auf Personal zu verzichten, illusorisch und eher Wunschdenken.

Hannah Clark: Ohne Namen zu nennen.

Anish Dhar: Ja. Es wird weiterhin Bedarf geben und Unternehmen, die das Gegenteil behaupten, suchen eher Publicity. Zur Frage: Wie beeinflussen KI und Coding-Assistenten unsere zentralen Säulen wie Zuverlässigkeit und Security?

Das ist aktuell die große offene Frage – viele Teams, auch SRE, Security oder Operational Excellence, haben zurecht Bedenken. KI schafft mehr Oberfläche, weil mehr Code entsteht – und je mehr des Systems KI-assistiert gebaut ist, desto weniger verstehen Teams die Interna. Das ist kritisch: Bei Reliability-Problemen ist es schwieriger, das System zu durchdringen, wenn man die Ursprünge nicht nachvollziehen kann.

Genau deshalb wird das Foundation-Layer von Engineering Excellence (Transparenz und Ownership) noch wichtiger. Je mehr das System von KI geschrieben ist, desto weniger Sichtbarkeit und Besitz ist da – das sorgt für Unsicherheit in Security-Teams. Auch bei uns: Wird Code KI-generiert, wird das explizit gekennzeichnet und nochmals geprüft. Ein Trend ist „KI-gestütztes Testing“, bei dem Tests durch KI reviewed werden – das kann funktionieren, aber es gibt Risiken. Trotz aller Vorteile bleibt: Je mehr des Systems auf KI beruht, desto weniger Klarheit über Funktion, Ownership und Security besteht. Das birgt Risiken im Hinblick auf Ausfälle und Sicherheit.

Hannah Clark: Ich stimme zu, das ist ein logistisches Problem, das oft übersehen wird: Mehr Output fordert auch mehr Kontrolle.

Ein Gespräch letzte Woche mit dem SVP of Product Management von Mastercard Gateway drehte sich ebenfalls um KI-Tools und wie sie Dokumentation für Markteintritte beschleunigen. KI erledigt Routine-Bürokratie sehr schnell – aber man braucht immer noch Verantwortliche, die alle Einreichungen prüfen und verantworten. Dieser Balanceakt zwischen Geschwindigkeit und Verantwortlichkeit zieht sich durch viele Teams, nicht nur die Entwicklung.

Deshalb: Schnell deployen ist das eine – aber können wir gleichzeitig auch schnell genug Verantwortung übernehmen? Das muss betont werden. Wir haben mit vielen Bereichsleiter:innen gesprochen und es ist interessant zu sehen, wie ähnlich die Herausforderungen in unterschiedlichen Disziplinen sind.

Vielen Dank für deine Einblicke! Hier endet unsere Episode. Wo können Leute dir online folgen, Anish?

Anish Dhar: Am besten über LinkedIn oder Twitter – einfach meinen Namen suchen. Cortex ist auch auf LinkedIn präsent. Wir veranstalten Engineering Excellence Summits weltweit – wenn einer in Ihrer Nähe stattfindet, freuen wir uns! Wir wollen eine Community für Menschen aufbauen, die sich mit diesen Themen beschäftigen – jedes Unternehmen steht da vor ähnlichen Fragen.

Außerdem veranstalten wir die IDPCON, unsere eigene Konferenz rund um Engineering Excellence, mit Speaker:innen aus verschiedenen Unternehmen und Entwickler:innen, die sich austauschen möchten. Viele spannende Talks! Im Oktober in New York City – vielleicht sehen wir uns dort.

Hannah Clark: Klingt fantastisch. Wir erwähnen es gern in der Beschreibung. Vielen Dank, dass du Zeit für uns hattest.

Anish Dhar: Danke, es war mir eine Freude!

Hannah Clark: Vielen Dank fürs Zuhören. Für weitere Insights, Anleitungen und Tool-Reviews abonnieren Sie unseren Newsletter unter theproductmanager.com/subscribe. Weitere Gespräche gibt es, wenn Sie den CPO Club-Podcast überall abonnieren, wo Sie Podcasts hören.