{
  "video_id": "bQbzfC8jAXY",
  "channel_slug": "deeplearningai",
  "channel_handle": "DeepLearningAI",
  "title": "AI Dev 26 x SF | Marc Brooker: It's Time to Be Right",
  "duration_seconds": 879,
  "url": "https://www.youtube.com/watch?v=bQbzfC8jAXY",
  "upload_date": "20260519",
  "transcript": "Hey, guten Morgen.  Ich freue mich riesig darauf, mit\neuch allen zu sprechen.  Äh, mein Name ist\nMark Brooker.  Ich bin Vizepräsident und angesehener\nIngenieur bei AWS und verbringe meine Tage damit,\nan Agentic AI zu arbeiten, und zwar an\nEntwicklertools, Tools für Unternehmensanwender,\nder Agent Core Runtime zum\nAusführen von Agenten und vielen weiteren Produkten, also\nDingen, die wir im\nBereich Agentic AI entwickeln.\nIch bin Softwareentwickler.  Ich verdiene meinen\nLebensunterhalt mit Softwareentwicklung.  Ich schreibe\njeden Tag Software, äh,\noft auch Produktionssoftware.  Und ich muss sagen, dass dies die aufregendste\nZeit meiner Karriere ist.  Ich verdiene seit\netwa 30 Jahren meinen Lebensunterhalt mit dem Schreiben von Software, und ich habe noch nie ein so hohes\nTempo des Wandels erlebt wie heute, und\nich hatte noch nie einen so großen Einfluss\nund so viel Macht über Probleme wie\nheute.\nEs ist eine unglaublich aufregende Zeit,\nin der Softwarebranche tätig zu sein, und eine\nunglaublich aufregende Zeit, die Möglichkeit zu haben, einen\nTeil dieser\nBranche mitzugestalten.\nAber\nes ist noch nicht perfekt.  Wir haben noch einiges\nzu tun.\nIch habe also eine Hypothese über die\nZukunft.\nMeine Hypothese ist, dass die Möglichkeiten\nfür Agenten, insbesondere die Möglichkeiten für\nWissensarbeitsagenten,\ndurch die Fehlerrate begrenzt sind.\nUnd so\nhaben wir\nin den letzten etwa 18 Monaten eine unglaubliche Zunahme der\nTätigkeiten erlebt, die Agenten an einem\nguten Tag ausüben können, also der Art von Aufgaben, bei denen sie\nuns helfen können, wenn sie im Einsatz sind.  Und\nwir haben eine deutliche Verbesserung bei der\nFehlerquote festgestellt, bei den Dingen, die sie\nfalsch machen.\nIch glaube jedoch, dass Verbesserungen bei dieser\nFehlerrate mehr\nzur allgemeinen Chance der Agenten beitragen werden,\nals dass sie die Grenzen unbedingt\nweiter verschieben.\nLassen Sie mich kurz auf die Form eingehen\n.\nIch werde Ihnen nun eine klassische\nVier-Blocker-Formation vorstellen.\nWir werden uns ansehen, wie häufig\nFehler bei Handlungsergebnissen auftreten und wie\ngravierend diese sind.\nUnd hier spreche ich von Ergebnissen\neiner Agentenschleife, nicht von Ergebnissen des\nRohmodells.\nUnd wie Sie wissen, ist das\nInteressante an Agenten, dass sie eine Rückkopplungsschleife darstellen.\nUnd Rückkopplungsschleifen gehören zu den\nwirkungsvollsten Mustern in Wissenschaft und\nTechnik.\nMit\ndem richtigen Feedback kann man aus sehr fehlerhaften Dingen großartige Dinge entwickeln.  Ich\nspreche hier also vom Ergebnis dieser Schleife,\ndem Ergebnis, nachdem wir das Feedback angewendet haben\n.  Und wie wir dieses\nFeedback anwenden.\nIch möchte außerdem darauf hinweisen, dass\nhier eine gewisse Vermischung vorliegt, wenn ich über Probleme\nzwischen der\nzu erledigenden Aufgabe spreche.  Manche sind leichter, manche\nsind schwieriger.\nManche sind wichtiger, manche weniger\nwichtig.\nUnd die Fähigkeiten der Agenten.  Und deshalb\nvermische ich diese beiden\nDinge absichtlich.\nBeginnen wir also damit, uns die schlimmste\nEcke anzusehen.\nHohe Problemhäufigkeit.\nHohe Priorität der Probleme.  Es\nmacht wichtige Dinge oft falsch.\nDieses Produkt will niemand kaufen.\nNahezu niemand möchte dieses\nProdukt kaufen.  Es könnte ein kurzes\nZeitfenster geben, in dem ein gewisser Hype entsteht.  Und die\nLeute denken dann: „Oh, ich muss\ndieses Produkt kaufen, weil mein Vorstand es\nmir sagt oder mein CEO es mir sagt.“\nAber das wird nicht von Dauer sein.  Niemand\nwill dort sein.\nDann können wir uns\nden Problemen zuwenden, bei denen wir\nviele kleine Fehler beobachten.  Und genau hier\nfinden wir den Schlamper.\nUnd Unordnung ist nicht unbedingt etwas Schlechtes.\nIn unserem Leben gibt es viele\nProbleme, bei denen wir eine\nhohe Anzahl von Fehlern mit geringen Folgen in Kauf nehmen.   Könnten\nSie mir dieses kurze Dokument bitte zusammenfassen?\nSag mir Bescheid, falls\nim Schulnewsletter etwas Interessantes steht.\nDie Fehler stören mich nicht so\nsehr, und ich kann mit dem einen oder anderen Gedankenstrich\noder der seltsamen Satzkonstruktion oder was auch immer einverstanden\nsein.\nAber auch hier sind die Möglichkeiten\nbegrenzt.  Es gibt nur eine begrenzte Anzahl solcher\nProbleme auf der Welt, und sie gehören in der Regel zu den am\nwenigsten wichtigen\nProblemen.\nDann kommen wir zum nächsten Punkt, nämlich\neiner geringen Wahrscheinlichkeit für schwerwiegende\nFehler in der Agentenleistung.\nDies sehen wir insbesondere in Bereichen wie der\nSoftware- und Systementwicklung, wo\nAkteure komplexe Systeme entwickeln, die\nauf den ersten Blick korrekt erscheinen.  Sie\nbestehen alle Tests.  Sie scheinen\ndas Richtige zu tun.  Sobald die\nProdukte in Produktion gehen, passieren seltsame und\nunerwartete Dinge.\nUnd wer behebt dann diese seltsamen und\nunerwarteten Dinge?  Teams von menschlichen\nExperten.  Das ist doch immer noch toll,\noder?  Wir konnten die Markteinführungszeit dennoch deutlich verkürzen\n.  Wir haben etwas Cooles gebaut\n.  Wir haben etwas Cooles verschickt.  Das\nist kein schlechter Ort, aber gleichzeitig ein\nsehr einschränkender Ort, weil wir\nein gefährliches und scharfes Werkzeug geschaffen haben, das\nnur von einer kleinen Anzahl von\nMenschen bedient werden kann, und die Möglichkeiten dafür\nsind wiederum begrenzt.\nUnser eigentliches Ziel\nist also eine niedrige Rate an Fehlern mit geringen Folgen\n.  Dort kann jeder\nmitspielen.  Jeder kann vorbeikommen,\ndenn man muss kein\nExperte sein, um Probleme zu finden und zu beheben.  Sie\nmüssen sich nicht mit Schlampigkeit abfinden,\nund Sie müssen sich nicht\nmit schwerwiegenden Mängeln abfinden.\nHier liegt das wirklich\ninteressante Potenzial für agentenbasierte KI\n.\nUnd wir müssen uns selbst antreiben, um\ndorthin zu gelangen.\nQualitativ betrachtet, und\nich fasse es grob zusammen, haben wir in den letzten etwa 18 Monaten\nenorme Fortschritte bei der Senkung\nder Fehlerhäufigkeit gesehen,\naber deutlich weniger Fortschritte – immer noch\ngute Fortschritte – bei der Verbesserung der\nFähigkeit der Mitarbeiter, komplexe Aufgaben mit einer\nniedrigen Fehlerrate zu erledigen.   Eine\nandere Möglichkeit, dies zu\nbetrachten, ist folgende: Wenn man\neine Verteilung der KI-Ergebnisse hat, befinden sich\nam linken Ende die guten\nErgebnisse.  Entschuldigung, meine linke Seite, Ihre rechte.\nWir erzielen gute Ergebnisse.\nDas sind die Fälle, die für Schlagzeilen sorgen.\nDas sind die Projekte, die Risikokapitalgeber begeistern.\nDas sind diejenigen, die aufwendige\nDemos erstellen.  Die sind super.  Wir sollten weiterhin\nin sie investieren.  Lass uns gehen.\nAuf der anderen Seite haben wir die negativen\nErgebnisse.\nDas sind die Dinge, die die\nLeute vergraulen und dazu führen werden, dass\nMenschen und Organisationen diese\nGeräte abschalten.\nUnd wir müssen dort genauso\nintensiv investieren wie in die\naufsehenerregenden Dinge.\nInteressanterweise habe\nich neulich ein\nGrenzmodell gebeten, mir dieses Diagramm zu zeichnen\n.  Bei der ersten Version, die\nsie erstellte, bat ich um eine Cauchy-\nVerteilung.  Die erste Version, die es zeichnete,\nwar normal.  Es sagte mir, es sei Cauchy.  Ich\nsagte: „Nein, ich glaube dir nicht.“  Ich habe\nes erneut weitergeleitet.  Es hat mir irgendwelchen spitzen\nMist mit einer Unstetigkeit bei Null geschickt.  Und\nwir mussten ungefähr\n15 Minuten lang im Kreis laufen, bis es endlich aufhörte,\nmich hinsichtlich der Form dieser Verteilung anzulügen.\nIch fand, das war ein passendes\nBeispiel für meinen Standpunkt.   Was\nunternehmen wir also bei AWS dagegen?\nWas unternehmen meine Teams und Organisationen in\ndieser Hinsicht?  Und dies wird nur\neine kleine Auswahl aus einem umfangreichen\nWerk sein.  Und hier werde ich mich auf\ndie, sagen wir, weniger neuronalen Dinge konzentrieren.\nWir investieren vorwiegend in ein\nbreites Spektrum an Technologien.\nIch möchte Sie aber bitten, einige unserer\nArbeiten hervorzuheben, die,\nsagen wir mal, etwas symbolischer Natur waren.\nDie erste große Investition besteht also in\nkorrekten Konstruktionsrahmen für die\nSoftwareentwicklung und die Erstellung kritischer\nSoftwarekomponenten.  Und hier möchte ich\nzwei besondere Bemühungen hervorheben.  Eine davon\nist Hydro.  Hydro ist ein\nin Rust entwickeltes Framework, das es\nAgenten und Menschen erleichtert, korrekte\nverteilte Systeme und Protokolle zu schreiben.\nDas ist extrem hilfreich, denn wir wissen,\ndass die Entwicklung verteilter Protokolle eine\nenorm schwierige Aufgabe ist.  Wir\nwissen auch, dass zumindest die aktuelle\nGeneration von Modellen, und es gibt\nAnzeichen dafür, dass die nächste Generation von\nModellen dieses Problem ebenfalls nicht gut lösen kann\n.\nSie sind nicht gut darin,\nParallelitätsprobleme systematisch zu analysieren, und auch im\nUmgang mit Fehlern sind sie nicht besonders gut\n.\nHydro schafft ein Framework, das von\nden Modellen, Agenten und\nCodierungsagenten genutzt werden kann, um von Grund auf\nkorrekte verteilte\nSysteme zu erstellen.\nUnd dann gibt es noch Zeder.  Cedar ist eine\nSprache, die für das Schreiben von\nAutorisierungsformularen entwickelt wurde.\nÄh, es handelt sich um eine Richtliniensprache.  Und es handelt sich um eine\npolitische Sprache, die tief in der\nVernunft und im automatisierten Denken verwurzelt ist, was\nes wiederum viel einfacher macht, richtig zu liegen\n.\nWir investieren stark in Bereiche wie\nKira, unseren Codierungsagenten für spezifikationsgetriebene\nEntwicklung und Tests, weil wir\nfestgestellt haben, dass ein Codierungsagent, dem eine\nSpezifikation\nals Kontext gegeben wird,\nin der anfänglichen Entwicklungsphase viel näher an die Korrektheit herankommt\nund sich bei der\nIteration und Verbesserung einer\nSoftware nicht so schnell wieder von der Korrektheit entfernt.\nWir investieren massiv in automatisiertes\nSchließen und Werkzeuge, die es Agenten ermöglichen,\nCode auf automatisierte\nund mathematisch präzise Weise zu analysieren.\nEines meiner Lieblingsprojekte hier, in das\nwir investieren, ist eine\nZwischenrepräsentation namens Strata. Dabei handelt es sich um eine\nSprache, in die wir Sprachen kompilieren\nund anschließend\nmithilfe mehrerer Backends für automatisiertes\nSchließen analysieren können.  Das ist eine Investition\n[räuspert sich] in\ndie alte Schule der KI, die von der neuen\nSchule der KI unterstützt wird.  Ich finde das sehr\naufregend.  Und all das wird durch\nLean ermöglicht, diesem unglaublichen neuen\nBeweisassistenten und dieser Sprache, die branchenweit\nüberall Anwendung findet\n, und wir investieren\nbei AWS massiv in diese Richtung.   Ein\nweiterer großer Investitionsbereich ist die\nFormalisierung des Automobilsektors.  Das ist ein großes Wort.  Es\nbedeutet, eine natürlichsprachliche Aussage oder\neine allgemeinverständliche Standardarbeitsanweisung (SOP) oder\nAnweisung zur Zugriffskontrolle\nin eine mathematisch präzise\nSpezifikation umzuwandeln.\nWas wir hier bei Bedrock AI Guardrails\nund Agent Core Policy machen, ist, dies als\nDialog mit dem Kunden zu gestalten.  Hey, du hast\nmir diesen Text in natürlicher Sprache geschickt.\nEs ist nicht ganz präzise.  Es weist einige\ninterne Widersprüche auf.\nLass uns darüber sprechen und herausfinden, was\ngenau du meinst, und dann können wir\ndas in ein Programm in Cedar kodieren, wir können\ndas in ein Programm in Lean kodieren und\nmathematisch präzise\nAussagen über das Verhalten dieser\nRichtlinie oder Spezifikation treffen.\nEs ist ein extrem leistungsstarkes Werkzeug.   Ein\nweiterer großer Investitionsbereich liegt in der Entwicklung\ndeterministischer Agenten- und Werkzeugrichtlinien.  Wie können\nwir die von Ihnen\nin natürlicher Sprache formulierten und von uns\nformalisierten Richtlinien auf das\nVerhalten der Agenten anwenden?\nWir setzen dies an mehreren Stellen in\nAWS ein, hier sind einige Beispiele.  In der Agent\nCore Policy können Sie diese auf diese\nTool-Aufrufe im Agent Core Gateway anwenden.  In\nStrands, unserem Framework zum Erstellen von Agenten, gibt es\neine tolle Funktion namens\nStrands Steering, mit der man\nRichtlinien als Mengen von Vor- und\nNachbedingungen für Tool-Aufrufe kodieren kann. Dies\nist ein hervorragender Kompromiss zwischen\nder Flexibilität der Modelle, ihre Stärken auszuspielen,\nund der gleichzeitigen Führung\nin Richtung eines korrekten\nErgebnisses.\nErst diese Woche haben wir ein Tool\nnamens Trusted Remote Execution als Open Source veröffentlicht, das\ndie\nin Cedar geschriebenen, automatisch formalisierten Richtlinien in\nden operativen Bereich überträgt. Wenn wir\nSkripte zum Betrieb der Cloud ausführen, werden diese\nSkripte und ihre Möglichkeiten, während sie\nvon Agenten erstellt werden, durch\ndiese formalen Cedar-Richtlinien eingeschränkt. Dadurch\nkönnen wir den Agenten Kreativität\nund Anpassungsfähigkeit ermöglichen und gleichzeitig\nmathematisch präzise Kontrolle\ndarüber behalten, was sie beim\nBetrieb unserer Cloud tun können.\nFür uns ist es die perfekte Balance.\nIch denke daher, dass wir branchenweit\nhöhere Standards brauchen.  Ich denke, wir\nmüssen uns wirklich die Idee verinnerlichen,\ndass, obwohl die coolen Sachen cool und\nglänzend sind und wir alle darüber reden\nund uns dafür begeistern sollten, letztendlich die Fehlerrate den Ausschlag gibt\n.  Es\nsenkt die Fehlerrate und\nbegeistert die Menschen dafür, sich\nin ihren Unternehmen und im Alltag tatsächlich auf agentenbasierte KI verlassen zu können\n.   Dazu gibt es\nein paar konkrete Vorträge.\nIch denke, wir brauchen mehr Benchmarks, die den\nSchweregrad von Fehlern erfassen, anstatt\nnur die Fehlerhäufigkeit.\nWir sollten Formulierungen wie „bestanden bei 10“ über Bord werfen.\nStattdessen sollten wir uns die Fehler ansehen und\nsie danach klassifizieren, wie wichtig\nsie tatsächlich für den Kunden und\nden Nutzer einer generativen KI sind.\nWir benötigen eine ganzheitlichere Sicht auf den\nErfolg einer generativen Entwicklung, die auch\noperative Eigenschaften miteinbezieht.  Es\numfasst Leistungseigenschaften und\nverbessert Kosteneigenschaften, Haltbarkeit,\nVerfügbarkeit usw.\nWir müssen ein\ntiefes Verständnis\nfür die Art dieser Fehler entwickeln – und dies ist eine Art Forschungsprogramm –, damit wir\nWerkzeuge, Modelle und Prozesse entwickeln können,\num deren Auswirkungen auf\nunsere Systeme und unsere Kunden zu minimieren.\nUnd wir müssen unsere schlimmsten Tage genauso\nernst nehmen wie unsere besten.\nWir müssen eine echte Kultur des\nVerstehens dafür entwickeln, was nicht funktioniert.\nUnd in die Instandsetzung von Geräten zu investieren und\nsie wirklich zuverlässig zu machen.",
  "transcript_chars": 14325,
  "ingested_at": "2026-05-21T19:18:31.847335+00:00",
  "source": "retry-no-transcript",
  "yt_meta": {
    "view_count": 418,
    "like_count": 9,
    "channel_id": "UCcIXc5mJsHVYTZR1maL5l9w"
  }
}