Von KI-unterstützt zu KI-nativ: Ein Pionier-Entwicklungsteam aufbauen — Clare Liguori, AWS
AAI Engineer
컴퓨터/소프트웨어경영/리더십AI/미래기술
스크립트
00:00:00Clare Liguori: Mein Name ist Clare Liguori und ich bin Senior Principal Engineer bei AWS.
00:00:17Ich arbeite hauptsächlich an Kiro, unserem Agenten-Decodierungsassistenten, aber heute möchte ich über
00:00:23einige der Praktiken sprechen, die wir bei Amazon in Amazon-Teams beobachten, bei denen wir
00:00:28wirklich spannende Ergebnisse von Produktivitätssteigerungen sehen, die eine sprunghafte Verbesserung darstellen gegenüber dem,
00:00:35was wir bisher mit KI gesehen haben. Ich beschäftige mich nun schon seit über drei Jahren mit agentischer KI,
00:00:43und ich habe sozusagen die Entwicklung miterlebt, die in unserer Branche in Bezug auf die Code-Assistenz
00:00:48durch KI stattgefunden hat. Zuerst hatten wir diese Inline-Code-Vervollständigung, die uns half, die nächste Zeile zu schreiben,
00:00:55vielleicht die nächste Funktion. Wir gingen zu Chat über und stellten Fragen zu unserem Code. Jeder fing an,
00:01:02irgendwann im letzten Jahr Vibe Coding zu betreiben, aber jetzt sehen wir sozusagen eine Early-Adopter-Phase
00:01:08dessen, was wir als Frontier Development bezeichnet haben. Und völlig anekdotisch, basierend auf meiner eigenen Erfahrung,
00:01:14habe ich mich durch all diese Phasen, die zuvor kamen, eigentlich nur vielleicht 10 bis 20 % produktiver gefühlt.
00:01:20Aber jetzt führen wir bei Amazon Pilotschulungen mit verschiedenen Teams im ganzen Unternehmen durch,
00:01:27und wir haben einen Median der Produktivitätssteigerung von dem 4,5-Fachen und manchmal mehr als dem 10-Fachen gesehen. Also,
00:01:34hier hat sich wirklich etwas verändert, jetzt, da wir diese sprunghaften Produktivitätsverbesserungen sehen.
00:01:40Und ich definiere das, was wir bei Amazon als Frontier-Entwickler bezeichnet haben, gerne
00:01:47anhand von drei Verhaltensweisen, die ich beobachten konnte. Das erste ist hands-off coding. Frontier-Entwickler schreiben vielleicht
00:01:541 bis 2 % des Codes, den sie produzieren. Der Rest sind Agenten. Das zweite ist, dass sie mit ihren
00:02:01Agenten nur selten interagieren. Sie versuchen dafür zu sorgen, dass ihr Coding-Assistent stundenlang läuft, ohne
00:02:08dass sie eingreifen müssen. Und das dritte ist, dass sie Leerlaufzeiten minimieren. Diese Frontier-Entwickler neigen dazu,
00:02:15mehrere Agenten parallel auszuführen und einen Aufgabenrückstand abzuarbeiten. Das erste Mal, dass ich ein Frontier-
00:02:24Entwicklerteam sah, war das Bedrock-Mantle-Team. Bedrock ist unser Modell-Hosting-Dienst. Er hostet LLMs wie Claude
00:02:34und GPT. Und irgendwann letztes Jahr wussten wir – oder ich sage wir, aber das Bedrock-Team wusste –, dass sie
00:02:43eine neue Inferenz-Datenebene bauen müssen. Aber sie hatten es auf 30 Personen über 18 Monate geschätzt. Das ist ein großer,
00:02:52großer Dienst. Und es würde Zeit brauchen, den neuen zu bauen, Kunden zu migrieren, Modelle
00:02:58zu migrieren. Und sie beschlossen, einen Schritt zurückzutreten. Sie nahmen sechs Leute und bauten ihn in 76 Tagen mit Kiro.
00:03:06Das war also eine enorme Leistung. Das war das erste Mal, dass wir so etwas bei Amazon gesehen hatten.
00:03:12Das war also wirklich das Wegbereiter-Team, das bewiesen hat, dass eine bis zu 20-fache Verbesserung möglich ist. Nun schauten sie sich
00:03:21Commits an, und ich werde auf ein paar andere Arten eingehen, wie wir Produktivitätsverbesserungen messen. Aber
00:03:27es gab ein Problem mit dieser Geschichte, nämlich dass sie zwar von sechs Leuten gebaut wurde. Sie wurde
00:03:34von einigen der Top-Ingenieure buchstäblich im Unternehmen gebaut, darunter zwei Distinguished Engineers. Das war
00:03:40also nicht irgendein Team aus sechs Leuten. Das waren Experten für verteilte Systeme, Experten für LLMs und deren
00:03:49Architektur. Diese Geschichte war also fantastisch und verbreitete sich wie ein Lauffeuer bei Amazon. Aber sie war
00:03:57auch für viele Teams sehr unerreichbar. Es gab viele Fragen dazu, ob sich das tatsächlich in einem
00:04:03anderen Team reproduzieren lässt. Ein weiteres Experiment, über das ich sprechen möchte, ist also ein experimenteller Sprint, der
00:04:10in der Prime-Video-Organisation durchgeführt wurde. Sie machten einen 10-Tages-Sprint und führten ein Experiment durch, bei dem sie wiederum sechs Ingenieure
00:04:19in einen Raum steckten und sie mit Kiro machen ließen, was sie wollten. Sie senkten die Projektabschätzung von den ursprünglich
00:04:29geplanten 90 Wochen auf 24, basierend auf all den Fortschritten, die sie in diesem 10-Tages-Sprint erzielt hatten.
00:04:36Und sie schauten sich ihre Commit-Historie an und betrachteten, was sie vor diesem
00:04:4210-Tages-Sprint zu tun pflegten und wie viele Commits sie allein in diesen 10 Tagen produziert hatten. Und dieser Sprint bewies also wirklich,
00:04:49dass wir wieder etwas erreichen können, das dem nahekommt, was das Bedrock-Mantle-Team erreicht hatte,
00:04:58und zwar mit einer anderen Gruppe von Ingenieuren. Aber auch hier gab es ein Problem bei dieser Geschichte, nämlich dass es sich um sechs
00:05:05Ingenieure in einem Raum handelte, die keine Rufbereitschaft, begrenzte Meetings und sehr wenige Ablenkungen hatten – was wir alle
00:05:12als normal im Leben eines Ingenieurs kennen. Und der leitende Ingenieur des Teams hatte die vorherigen
00:05:20drei Wochen damit verbracht, sehr detaillierte, kleine, gut abgegrenzte Aufgaben mit detaillierten Anforderungen für diese sechs
00:05:28Ingenieure zu erstellen, damit diese in diesen zwei Wochen einfach Gas geben konnten. Das war also wiederum nicht unbedingt das echte Leben.
00:05:35Das war ein strukturierter Sprint, ein Zeitpunkt, an dem sie dies erreichen konnten. Aber wiederum stellt sich
00:05:41die Frage, ob dies bei realen Teams für die tägliche Arbeit erreichbar ist. Also hat Amazon Stores, was
00:05:51Amazon.com, all unsere Einzelhandels-Websites sowie unsere physischen Geschäfte umfasst, einen strukturierteren Piloten durchgeführt.
00:05:59Sie beobachteten 50 Teams, die völlig normal waren – eine normale Verteilung von Berufsanfängern, Mitarbeitern
00:06:07mit mittlerer Berufserfahrung und Senior-Ingenieuren –, die an bestehenden Systemen arbeiteten. Nichts Greenfield, wie das Mantle-Team es
00:06:14von Grund auf neu aufbauen durfte, sondern bestehende Systeme mit bestehenden Codebasen. Und sie beobachteten sie den
00:06:21größten Teil des letzten Jahres und fanden etwas Superinteressantes heraus. Sie stellten fest, dass es einen großen
00:06:28Unterschied bei den Produktivitätssteigerungen gab, die sie zwischen der Hälfte der Teams und der anderen Hälfte sahen. Und in
00:06:34diesem Fall verwendeten sie eine Produktivitätsmetrik der Bereitstellungsgeschwindigkeit in die Produktion. Also nicht nur Commits, wie viele
00:06:41Commits sie produzieren, sondern wie schnell wir Änderungen zu den Kunden bringen. Wie schnell sind wir
00:06:48in der Lage, Dinge auszuliefern? Und sie sahen, dass die Hälfte der Teams einen Anstieg von weniger als dem 3-Fachen erzielte. Und was sie
00:06:56als Unterschied zwischen einer Produktivitätssteigerung von weniger als dem 3-Fachen und diesen Teams feststellten, die ein
00:07:01Median von dem 4,5-Fachen und in einigen Fällen mehr als dem 10-Fachen sahen, war, wie sie die Werkzeuge nutzten. 90 % dieser Teams verwenden Kiro
00:07:11neben anderen internen Tools, die wir haben. Und was sie herausfanden, war, dass es nicht an den Werkzeugen lag, sondern an der Art und Weise, wie sie
00:07:18arbeiteten. Die Teams, die sprunghafte Verbesserungen erzielten, änderten absichtlich ihre Arbeitsweise,
00:07:26während die anderen Kiro und einige der anderen Tools, die wir haben, sozusagen einfach nur über ihre
00:07:31bisherige Arbeitsweise streuten. Und das war für mich zumindest dieser große Aha-Moment, warum ich möglicherweise nicht
00:07:39die massiven Produktivitätssteigerungen gespürt hatte, die KI versprochen hat: Es geht darum, unsere Arbeitsweise zu verändern.
00:07:47Deshalb führten sie im Laufe dieses Piloten Interviews mit den Teams, die an dem Piloten beteiligt waren, sowie mit einigen
00:07:55dieser anderen Teams im Bedrock-Mantle-Team, bei Prime Video, und sie fanden fünf Gewohnheiten. Und ich verwende das
00:08:03Wort Gewohnheiten ganz gezielt, denn es geht eben nicht um diesen einen Sprint, sondern darum, dies Tag für
00:08:09Tag zu tun. Und bei den Interviews mit diesen Teams stellte sich heraus, dass es tatsächlich Gewohnheiten waren, die sie Tag für Tag
00:08:15aufbauen mussten. Wenn wir unsere Arbeitsweise ändern, fällt es schwer, diese Gewohnheiten aufzubauen; es braucht Zeit,
00:08:22diese Gewohnheiten aufzubauen. Gehen wir also jede davon einzeln durch. Gewohnheit Nummer eins ist die Investition in den Agentenkontext.
00:08:30Wir haben eine Menge Zeug in unserem Kopf, wir neigen dazu, all diesen Kram in unserem Kopf an andere Personen
00:08:35über Slack-Gespräche zu übertragen, durch Onboarding-Mentoren, solche Dinge durch Code-Reviews,
00:08:42durch Stand-ups und Sprint-Planung, und sie mussten das alles aufschreiben. Und die Gewohnheit, die sie
00:08:50aufbauten, war: Jedes Mal, wenn der Agent einen Fehler macht oder etwas tut, das nicht so ist, wie Sie es getan hätten:
00:08:55Was fehlt in meinen Skills-Dateien? Was fehlt in meinen Steering-Dateien, was der Agent gebraucht hätte?
00:09:01Aber wie wir wissen, sahen wir im Laufe des letzten Jahres sprunghafte Fortschritte bei den Fähigkeiten und Verhaltensweisen der Modelle.
00:09:09Sonnet 3.7 hatte Mitte des letzten Jahres viele Macken, so dass wir eine Menge „Nicht-Tun“-Anweisungen
00:09:16in unsere Steering-Dateien schreiben mussten. Und jetzt müssen wir das bei Opus 4.5 seit letztem November nicht mehr so stark tun,
00:09:23und wir hatten seither sechs Monate, mehr als sechs Monate Verbesserungen mit all den neuen
00:09:29Modellversionen, die seitdem herausgekommen sind. Die neue Frage und die neue Gewohnheit lautet also: Brauche ich das
00:09:35noch in meinen Steering-Dateien? Oder bläht das nur den Kontext auf? Das zweite ist: Langsamer werden, um
00:09:41schneller zu werden. Fast jedes befragte Team berichtete, dass ihre Produktivität tatsächlich sank,
00:09:48als sie absichtlich eine neue Arbeitsweise annahmen. Das ist kontraintuitiv,
00:09:53nicht wahr? Man muss erst absichtliche Ingenieursarbeit leisten, bevor man diese Hockeystick-Kurve
00:09:59Hockeyschwung-Kurve bei der Produktivitätssteigerung sehen. Denn wir müssen in unseren Codebasen zuerst
00:10:05damit Agenten dort erfolgreich sein können, insbesondere in bestehenden Brownfield-Codebasen. Sie mussten also
00:10:11diesen Agentenkontext aufbauen, sie mussten die Fehlermeldungen bestehender Tools verbessern, damit das Modell wusste,
00:10:17was vor sich ging, wenn es fehlschlug. Sie bauten neue Tools, neue MCP-Server, um dem Modell zu helfen, tatsächlich
00:10:24das zu erledigen, was erledigt werden musste. Viele Teams strukturierten schließlich ihre Codebasis um, damit Agenten
00:10:29sich darin leichter zurechtfinden konnten. Und ich habe sogar drastische Änderungen gesehen, wie das Ändern der Programmiersprache
00:10:36der Codebasis. Oft habe ich erlebt, dass Teams mit Python und JavaScript zu kämpfen hatten, weil es sich um
00:10:43untypisierte Sprachen handelt. Das ist schwer zu testen. Es gibt keine Compiler-Fehler. Also rät das Modell gewissermaßen und
00:10:50gibt es Ihnen zurück. Daher habe ich gesehen, dass Teams zu TypeScript wechseln. Rust ist sehr beliebt geworden
00:10:56bei Amazon. Der Compiler gibt hervorragende Fehlermeldungen aus. Das muss man nicht tun. Aber ich habe gesehen, wie viele
00:11:03Teams diese absichtlichen Änderungen für die Produktivitätsgewinne vornehmen, die sie erzielen können.
00:11:09Die dritte ist: Agenten füttern, nicht Agenten babysitten. Und für mich war dies einer dieser Aha-Momente,
00:11:16warum wir diese sprunghafte Produktivitätssteigerung sehen. Wenn Sie Vibe Coding betreiben, wenn Sie
00:11:23den ganzen Tag über ein hin und hergehendes Gespräch mit Ihrem Agenten führen, werden Sie natürlich keine
00:11:304- bis 5-fachen Produktivitätssteigerungen erzielen, weil Sie die ganze Zeit über in der Schleife sind. Sie sitzen wahrscheinlich
00:11:36dort und warten 30 Sekunden bis zu einer Minute darauf, dass er Code generiert und zu Ihnen zurückkommt
00:11:42mit dem zu überprüfenden Code. Wenn Sie dort sitzen und darauf warten, können Sie sich nicht anderen Dingen widmen.
00:11:48Zeug zu erledigen. Es ist wirklich schwierig, Agents parallel laufen zu lassen. Es ist sehr schwer, sich
00:11:55selbst in mehrere Agents zu klonen. Wenn deine Unterhaltungen also ein bisschen so aussehen wie auf der linken Seite, dann
00:12:01bist du am Babysitten dieses Agents, im Gegensatz zur rechten Seite, wo du ihm fütterst, was er tun muss und wie
00:12:08er sich selbst validieren kann. Das ist wirklich der Schlüssel, damit Agents sich selbst korrigieren und erst zu dir zurückkehren,
00:12:14wenn sie eine bestimmte Qualitätsmesslatte erreichen, wenn es tatsächlich läuft, kompiliert und Tests besteht, wenn
00:12:20es testbar ist und eine hohe Abdeckung aufweist. Und der nächste Schritt ist natürlich, all diesen
00:12:26Inhalt in deine Steuerungsdatei zu packen. Damit es jedes Mal passiert, ohne dass du es ihm vorgeben musst.
00:12:33Die vierte Gewohnheit besteht darin, die Absicht explizit zu machen. Bei Amazon praktizieren wir viel Spezifikations- und Entwicklung.
00:12:40Wir haben das in das Kiro-Produkt integriert. Daher ist es für Amazon-Entwickler sehr natürlich, es
00:12:46in Kiro zu übernehmen. Was ich beim Vibe-Coding im Gegensatz zur Frontier-Engineering typischerweise gesehen habe, ist das Geben
00:12:54eines sehr hochstufigen Prompts, das den Agenten eine Menge Code generieren lässt und dann ein hin und her
00:13:02gehenden Gespräch zu führen mit den Worten: Oh, das ist eigentlich nicht das, was ich meinte. Du hast die Anforderungen nicht ganz richtig verstanden.
00:13:10Nein, ich wollte es eigentlich nicht so bauen. Hier ist ein technisches Design. Und ich finde es weniger produktiv,
00:13:17mit dem Agenten über Code zu iterieren, wenn die Absicht selbst falsch war. Sehr oft lassen wir bei Amazon
00:13:26Ingenieure diesen Prozess für mehrdeutige, komplexe Funktionen durchlaufen, indem sie die Spezifikation schreiben.
00:13:34Und in Kiro muss man diese ganze Spezifikation natürlich nicht schreiben, man kann das Modell sie generieren lassen.
00:13:39Aber es ist viel einfacher, mit dem Modell in einer Art Hin- und Her-Gespräch über ein
00:13:46Dokument zu iterieren als über Code, dessen Änderungen über eine Codebasis verstreut sind. Das fünfte ist das Testen nach links zu verlagern
00:13:56Einer der Schlüssel hierbei ist, dem Agenten diese schnelle Feedbackschleife zu geben, denn das ist es, was ihn stundenlang
00:14:04alleine arbeiten und sich selbst korrigieren lässt. Der Agent wird Fehler machen, und das ist in Ordnung. Aber wenn man ihm die richtigen Signale gibt, kann er
00:14:12sich selbst korrigieren und einige Zeit damit verbringen. Daher habe ich gesehen, wie Teams Linter, Unit-Tests,
00:14:20Integrationstests, Leistungstests und Sicherheitstests hinzufügen. Das sind alles Dinge, von denen wir alle wissen, dass wir sie
00:14:24schon die ganze Zeit hätten tun sollen. Das ist gute Ingenieurshyggiene und bewährte Praxis. Aber jetzt ist der ROI
00:14:32meiner Meinung nach endlich hoch genug, dass wir tatsächlich darin investieren. Eine Sache, die viele Teams meiner Beobachtung nach tun, ist das Mocken von
00:14:40Diensten. Oft haben wir bei Integrationstests ein gesamtes System von Ende zu Ende getestet, einschließlich Live-Diensten.
00:14:46Aber wir haben stark in Mock-Dienste investiert, die vollständig lokal mit deterministischen
00:14:52Antworten laufen, weil es den Agenten alles lokal erledigen lässt. Alles auf dem Laptop zu machen, ohne
00:15:01eine Reihe anderer Dienste hochfahren und sich mit Clouddiensten verbinden zu müssen, macht alles viel schneller.
00:15:07Denn je schneller Ihr Agent Feedback erhalten kann, desto mehr Schleifen kann er
00:15:14durchlaufen und desto produktiver kann Ihr eigener Agent sein. Das sind also einige der Gewohnheiten,
00:15:21die wir gesehen haben. Aber ich wäre natürlich nachlässig, wenn ich Ihnen sagen würde: Wenn Sie all diese Gewohnheiten übernehmen,
00:15:28erreichen Sie das Nirvana, werden Sie die produktivste Engineering-Organisation sein, die die Welt je
00:15:35gesehen hat. Die Dinge sind immer noch schwer. Wir befinden uns nach wie vor stark in einer Early-Adopter-Phase und Teams versuchen immer noch,
00:15:42es herauszufinden. Eine Sache, die wir organisationsweit bei unseren Teams beobachtet haben, ist das Risiko
00:15:48von Burnout. Ich habe diesen Begriff nicht erfunden, ich habe vergessen, wer es auf welcher Konferenz getan hat, aber FOMAT ist real. Wir haben gesehen,
00:15:56wie Ingenieure bis spät in die Nacht aufbleiben und versuchen, diesen perfekten Prompt zu finden, der ihren
00:16:03Agenten stundenlang über Nacht laufen lässt, damit sie morgens mit einer fertigen Codeänderung aufwachen. Die kognitive Belastung
00:16:09steigt, wenn man diese mehreren Agents parallel laufen lässt; man wechselt ständig zwischen
00:16:15Terminal-Tabs hin und her. Und wir stellen fest, dass das Überprüfen von KI-Ausgaben für manche oft schwieriger ist als
00:16:22sie tatsächlich zu schreiben, besonders am Anfang der Karriere. Senior-Ingenieure haben bereits einen großen Teil ihrer
00:16:29Karriere damit verbracht, den Code anderer zu überprüfen. Aber Ingenieure am Anfang ihrer Karriere haben diesen Muskel noch nicht. Daher kann sich das Überprüfen
00:16:37nach viel mehr kognitiver Belastung anfühlen, als sie es gewohnt sind, wenn sie es selbst schreiben. Ein weiterer Punkt
00:16:44ist der organisatorische Wandel. Es ist ohnehin schwer, unsere Arbeitsweise als Ingenieure zu ändern. Die Art und Weise, wie wir
00:16:52unseren gesamten Tag verbringen, ändert sich völlig, wenn wir Frontier-Ingenieure sind. Aber auch Organisationen müssen
00:16:58sich verändern, um Frontier-Engineering-Teams zu ermöglichen. Eines, das ich sehr häufig gesehen habe, ist die Akzeptanz, langsamer zu werden,
00:17:07um schneller zu werden. Ich habe mich selbst dabei schuldig gemacht. Meine Führungskollegen haben sich dessen schuldig gemacht, zu sagen:
00:17:14Nun, du hast jetzt die KI-Tools und die Modelle sind jetzt so unglaublich. Warum wirst du nicht schneller?
00:17:22Und das liegt daran, dass man sich diese zwei Monate Zeit nehmen muss, um in seine Codebasis zu investieren, um die besten
00:17:29Best Practices für dein Team herauszufinden und schwierige Verhaltensänderungen in deinem Team vorzunehmen. Und wenn man ständig erwartet,
00:17:38jeden Monat Features auszuliefern, weil wir jetzt diese tollen Modelle haben, und wir sehen
00:17:44all diese Unternehmen auf X, die erzählen, wie sie 20 PRs am Tag ausliefern – wir müssen langsamer werden, um schneller zu werden.
00:17:54Der zweite Punkt ist, in der Organisation zu schnell zu breit zu gehen. Ich denke, wenn wir
00:18:01von allen Teams in riesigen Organisationen erwartet hätten, sofort Frontier-Teams zu sein, hätten wir nicht
00:18:08die Erkenntnisse gewonnen, die wir durch den Wegbereiter, durch das Sprint-Experiment, durch die Pilot-
00:18:16Teams bei Amazon gewonnen haben. Und die Herausforderung für uns besteht jetzt darin, wie wir das skalieren. Darum geht es im Jahr 2026.
00:18:22Für Amazon geht es darum, wie wir dies auf immer mehr Teams ausweiten, auf die nächsten 2000 Teams statt auf 50 Teams.
00:18:31Und ich denke, wenn man es zu schnell einführt, hat man viele Teams, die nicht wissen, was sie tun.
00:18:37Man hatte keine Zeit, die Best Practices für die eigenen Organisationen zu finden, den Kontext,
00:18:43den die eigene Organisation braucht. Und das Letzte ist, dass man neue Engpässe finden wird.
00:18:49Früher war das manuelle Schreiben von Code der Engpass. Ich stelle fest, dass wir bei Amazon herausgefunden haben,
00:18:58dass die Geschwindigkeit der Entscheidungsfindung zu einem neuen Engpass wird. Je mehr Zeit man damit verbringt, die Entscheidung zu überprüfen,
00:19:05tatsächlich ein neues Produkt zu bauen, desto langsamer lässt sich das Produkt jetzt bauen, da das Schreiben des Codes nur noch ein bis zwei Monate dauert.
00:19:12Alle Prüfungsprozesse im Zusammenhang mit der Produkteinführung werden zum Engpass.
00:19:20Wenn es früher neun bis zwölf Monate dauerte, ein neues Produkt zu bauen, fiel das im Großen und Ganzen
00:19:27nicht so stark ins Gewicht, wenn es zwei Monate dauerte, die Entscheidung zum Produktbau zu treffen, und dann zwei Monate,
00:19:33um den Launch zu genehmigen. Aber jetzt sind das die Engpässe. Das ist der heikle Punkt. Und so findet man all
00:19:40diese Dinge, die einen ausbremsen. Oft stelle ich fest, dass Frontier-Engineering-Teams mehr Zeit mit
00:19:48Entscheidungsfindungen verbringen als mit dem Schreiben von Code. Je schneller man also Entscheidungen treffen kann, besonders solche,
00:19:54die leicht rückgängig zu machen sind, desto besser. Meine wichtigste Erkenntnis für alle hier ist also, dass Frontier-
00:20:03Engineering bedeutet, die Arbeitsweise absichtlich zu verändern. Und das ist schwierig. Das braucht Zeit.
00:20:10Es bedeutet, neue Gewohnheiten und eine neue Arbeitsweise zu entwickeln. Und das gilt für jedes Engineering-Team sowie für Ihre
00:20:18Organisation. Daher ermutige ich Sie, darüber nachzudenken, wie Sie mit KI-Tools interagieren und wie sich das
00:20:27ändern kann, um sich davon zu befreien, ständig eingebunden zu sein. Danke. Ich bleibe noch ein wenig da, falls jemand
00:20:34hinten Fragen hat. Aber danke für die Zeit heute.