{
  "video_id": "EcqMYoIV57A",
  "channel_slug": "aidotengineer",
  "channel_handle": "aidotengineer",
  "title": "Why More Context Makes Your Agent Dumber and What to Do About It — Nupur Sharma, Qodo",
  "duration_seconds": 1587.0,
  "url": "https://www.youtube.com/watch?v=EcqMYoIV57A",
  "upload_date": "",
  "transcript": "Ich bin Nupur.  Ich arbeite mit Kodo.  Äh, bei Kodo\nmachen wir Agentenbewertungen.  Äh, ich habe einen\nHintergrund im Bereich DevSecOps.  Ich komme also\naus einer Branche, in der alles\ndeterministisch war.  Die Pipelines, die sie betreiben, bringen\nsie zum Zusammenbruch.  Wenn sie abstürzen, reparieren wir sie.\nÄh, hin zu einem Ort, an dem wir Agenten erschaffen, bei denen\nnichts deterministisch ist.\nIn den letzten Jahren habe ich also gelernt,\nwo und wie Agenten scheitern, welche\nLehren ich daraus gezogen habe, und heute werde ich einige\nmeiner Erkenntnisse mit Ihnen teilen.\nWenn man sich also die Entwicklung der\nAgenten ansieht, begann alles mit statischen Eingabeaufforderungen in\neinem 4K-Kontextfenster. Wir\nversuchten, alles Wichtige oder\nwas wir für wichtig hielten, einzugeben, und die KI-\nModelle verarbeiteten dies und lieferten\nein Ergebnis.  Rechts?  Als wir damit anfingen,\nbedeutete das, dass es an uns lag, den\nLLMs zu sagen, worauf sie achten sollten\n.  Das bedeutet, dass wir bei\nfalschen Eingaben möglicherweise keine\nkorrekten Ergebnisse erhalten.  Und dann dachten wir,\nvielleicht können wir es besser machen, wenn das Kontextfenster größer wird, wenn\ndie Kontextgröße zunimmt\n.  Wir können weitere Eingaben erhalten.  Und äh,\nwir haben mit agentenbasierten Workflows begonnen.  Also haben wir\neinen Agenten erstellt.  Wir bekommen\nTools wie die Suchfunktion, mit der man\nDokumente durchsuchen und\nBefehle ausführen kann.  Dann schaue ich mir die Suche noch einmal an\nund mache etwas, wodurch wiederum eine Art\nSchleife entsteht, in der das Tool nicht\nweiß, wo es anhalten soll.  Es scheint, als bräuchte ich immer wieder neue\nEingaben\n.  Das ist eine Schleife, die\nzum Improvisieren einlädt.  Heutzutage werden Multi-\nAents immer beliebter.  Erstellen Sie\nMulti-Aents, die viele Dinge gemeinsam erledigen.\nWenn wir es so betrachten, haben wir eine Menge\nAgenten, die für Sie arbeiten.  Ein\nSicherheitsagent versucht, Sicherheitsbedenken zu erkennen\n, ein Prüfagent versucht,\ndas Tool zu überprüfen, ein Codierungsagent versucht,\nFehler zu beheben.  Und auch hier gilt: Je mehr\nWerkzeuge man hat, desto mehr Probleme treten auf.  Nicht\njeder Agent versteht das, und es kommt zu Meinungsverschiedenheiten, die dazu führen, dass man\nkeine Ergebnisse erzielt.\nWas können wir also daraus lernen?  Was\nwir sehen, ist, dass der Kontext kein Problem darstellt.  Tag\nfür Tag kommen Modelle auf den Markt, in die man\nUnmengen an Kontext und Daten einfließen lassen kann\n.  Aber wird dadurch sichergestellt, dass die\nErgebnisse intelligent genug sind, um\nIhnen alles zu liefern, oder intelligent genug, um zu\nentscheiden, was wichtig ist?  Wenn man sich\ndie aktuellen LLM-Modelle ansieht, erkennt man ein Muster:\nSie übernehmen die anfänglichen Eingaben\n, sie übernehmen die letzten Eingaben, aber\nder Kontext dazwischen wird im Grunde\nentfernt.  Sie konzentrieren sich also nicht auf den\ndazwischenliegenden Kontext.  Die Agenten betrachten den\nStartpunkt und den Endpunkt und versuchen,\nIhnen die Ergebnisse zu liefern.  Das ist wie eine\nU-Kurve, bei der einige Dinge vom\nAnfang und einige Dinge vom\nEnde Sinn ergeben, aber alles, was man\ndazwischen anbietet, wird nicht\nberücksichtigt.  Ja.\nWoher weißt du das?   Daran\narbeiten wir\nund wir führen auch Vergleichsmessungen durch\n.  Wenn wir also Agenten erstellen, versuchen wir\nsicherzustellen, dass dies der Kontext ist, den wir\nden Agenten bereitstellen.  Berücksichtigt es diesen Kontext\nund liefert uns auch die\nErgebnisse?  Wir arbeiten also mit einer\nMultiagentenarchitektur, bei der wir für\njede Aufgabe, die wir im Rahmen von Code-\nReviews durchführen, die Aufgabe einem Agenten zuweisen und dann\nsagen: „Okay, gib uns ein Ergebnis.“  Jedes Mal, wenn\nwir beispielsweise Code-Reviews durchführen, versuchen wir\nzu sehen, ob wir den gesamten Kontext liefern können, ob\nwir beispielsweise die gesamte Codebasis präsentieren können\nund ob wir dadurch Ergebnisse erzielen können. Wir stellen jedoch fest, dass immer, wenn\nwir mit der Arbeit beginnen,\ndie anfängliche Aufgabe oder das\nanfängliche Ziel, mit dem wir starten,\nim Fokus steht.  Wenn wir am\nEnde etwas als Input angeben, das im Fokus steht, aber alles im\nKontext liegt, wie z. B. „Ich habe Jira, ich habe\nMCPS“, können Sie sich das ansehen? Die LLMs versuchen,\ndiese Dinge loszuwerden und zu bereinigen, damit sie für sich selbst Sinn ergeben\n.   Um\nalso mit dieser Situation umzugehen oder einen Ausweg zu finden, müssen wir eine\nstrategische Lösung für die Kontextoptimierung entwickeln, anstatt\nalles den\nModellen zu überlassen und von ihnen zu verlangen, intelligent\ngenug zu sein, um herauszufinden, was\nwichtiger ist.  Wir versuchen normalerweise herauszufinden,\nwas wir tun können, um den\nKontext für das Modell zu verbessern.  Es gibt bereits viele\nLösungen,\nund „Context Engine“ ist in aller Munde –\njeder will eine Context Engine entwickeln und\nanbieten.\nAber eine Context Engine ist wie ein Türsteher:\nIhr Auto rast, und die Context Engine\nfungiert als Türsteher und signalisiert Ihnen, was\nwichtiger ist. Gerade bei einer\ngroßen, unübersichtlichen Codebasis ist die\nEntwicklung einer Context Engine sinnvoll, da sie\nein Suchmuster und eine\nRanking-Logik erstellt. Immer wenn Sie\neine Aufgabe anfordern, sucht sie nach diesen Rankings\nund sagt: „Das ist wichtiger für Sie,\nnehmen Sie es an und bearbeiten Sie es.“  Das Problem besteht darin, dass\nder Indexierungsteil einen mäßigen Aufwand erfordert,\ndie Skalierung jedoch eine Herausforderung darstellt.  Wenn\nman beispielsweise von 600\noder 700 Repositories spricht, verlangsamt sich das Mapping und die\nIndizierung, und es\nwird wieder unvorhersehbar,\neine Kontext-Engine zu finden oder zu erstellen, es sei denn, man ist ausschließlich damit beschäftigt, eine\nKontext-Engine zu erstellen.\nEs gibt viele Bereiche, in denen\nAgenten mehr Kontext erhalten können, anstatt viel in die\nhierarchische Zusammenfassung der Kontext-Engine zu investieren. Anstatt\nalles zu erstellen oder durchzugehen,\nwird für jede Datei und jeden Ordner eine Zusammenfassung erstellt,\nsodass die Agenten beim\nSuchen die Zusammenfassung lesen\nund entscheiden können, ob dies für uns wichtiger ist\noder nicht.  Das Einzige\nist, dass man viel LLM-\nVerarbeitung benötigt.  Jedes Mal, wenn eine Datei erstellt\noder geändert wird, müssen einige der Agenten\neine Zuordnung dafür erstellen.  Es ist also ein\nhoher vorgelagerter Kontext der LLM-\nVerarbeitung erforderlich.  Eine weitere Möglichkeit\nist der Wissensgraph.  Wissensgraphen\nsind zwar komplex, aber sie leisten hervorragende Arbeit, wenn\nlogische Abhängigkeiten bestehen.  Nehmen wir an,\nSie haben eine Datei, die eine andere\nDatei beeinflusst, die wiederum eine weitere Datei beeinflusst.  Sie\nkönnen ein Graphdatenbank-Hosting erstellen.  Der\nanfängliche Input, den der Entwickler benötigt, ist\nsehr hoch.  Das Erstellen davon ist sehr zeitaufwendig\n.  Aber wenn Sie komplexe\nLogiken haben oder Abhängigkeiten von\nmehreren Repositories bestehen, funktioniert das\nbei mir hervorragend.  Ich denke, für den Großteil der Aufgabe, wenn\nSie kein Produktunternehmen sind, sondern\nAgenten für sich selbst oder\nIhre Prozesse erstellen, funktioniert iteratives Retrieval\nwirklich gut, weil anstatt überhaupt\neine Zusammenfassung zu erstellen, eine Art\nIndex erstellt wird.  Es ist also wie ein Bibliotheksausweis, den\nSie Ihren Agenten geben und ihnen sagen: „Das ist\ndas Thema, falls es für Sie relevant ist.“\nSie können den Code genauer untersuchen und\nnach den Ergebnissen suchen.  Das hat zwar\nerhebliche Kostenfolgen, aber man\nmuss nicht viel Energie investieren.  Der\nvon den Entwicklern\nfür das LLM erforderliche Input ist gering und es\nliefert bessere Ergebnisse.  Es gibt auch die\nMöglichkeit der Selbstkorrektur, bei der Sie\ndas LLM bitten, etwas zu tun, und es gibt\neinen Kritikerknoten, der prüft, ob\ndies für Ihr ursprüngliches Ziel relevant ist oder\nnicht.  Wenn in diesem Fall der Kontext verloren geht,\nkönnen Sie den Agenten erneut bitten,\nes noch einmal zu versuchen, da in der Kritik darauf hingewiesen wurde, dass\ndies nicht der richtige Weg ist.  Es\ndauert etwas länger, da die\nAusführung der Agenten eine Latenzzeit verursacht,\nerfordert aber\nvon den Entwicklern zunächst nicht viel Input, um\netwas zu erstellen.\nEine weitere Herausforderung, auf die ich gestoßen bin,\nwenn Leute\ndiese Agenten erstellen, ist das\nOrchestrierungsparadoxon.  Das führt dazu, dass\nLLM-Absolventen immer intelligenter werden.\nWenn man ihnen also eine Aufgabe gibt,\ndenken sie: Okay, ich sollte dieses Werkzeug benutzen,\näh, vielleicht kann ich es besser machen, ich sollte\nmehr recherchieren, was ich benutzen sollte.  Es\nentsteht eine Endlosschleife, in der man, anstatt\ndas Problem selbst zu lösen, nach\nder Methode sucht, mit der man das\nProblem lösen kann.  Sie wechseln ständig zwischen verschiedenen\nMethoden hin und her, und die meisten API-\nTokens werden dafür verschwendet, einen Weg zu finden, es zu tun, anstatt es zu\ntun.  Sie werden also einfach\nin den Recherchemodus wechseln.\nWenn Sie beispielsweise Opus neueste und\nbeste Versionen verwenden, werden sie versuchen,\ndie beste Methode dafür zu finden und sich\nimmer wieder selbst herausfordern.  Vielleicht nicht dieser, ein\nanderer Weg, ein anderer Weg.  Und so\ngerät man in einen Teufelskreis, in dem man versucht,\netwas zu tun, anstatt es tatsächlich zu tun.\nUm dieses Problem zu lösen, haben wir mit einem 80/20-\nHybridansatz gearbeitet.  Ich glaube, das ist eines der\ninteressantesten Ergebnisse, die ich je\ngesehen habe, bzw. einer der interessantesten Wege, diese\nEndlosschleife aufzulösen.  Unsere Teams\nstellen die neuesten und besten\nModelle zur Verfügung oder geben den Agenten die Möglichkeit,\n80 % der Zeit selbst zu recherchieren.  Man gibt\nihnen also das Ziel vor und sagt: „Okay, versucht, alles zu tun, was\nihr könnt, aber die 20 % der Aufgabe, bei denen eine\nabschließende Validierung erforderlich ist, sollen\nzusammengefasst werden. Das ist\nnicht etwas, das frei\nfließen kann, sondern eher eingeschränkt. Das\nsind feste Kontrollpunkte, zum Beispiel: Wenn ich\nX Ergebnisse erhalte, möchte ich Y. Das ist\ndeterministischer, sodass die Recherche, die\naus den restlichen 80 % stammt, reduziert werden kann.\nMan kann aber auch sagen,\ndass das 80-%-Tool immer noch weiterlaufen und\nin Endlosschleifen geraten kann.“  Wir haben Mechanismen, um daran zu\narbeiten.  Bei manchen Organisationen gibt es einen\nZählermechanismus, bei dem man nach\nvier oder fünf Zählern\nmit dem zuletzt ermittelten Ergebnis arbeiten muss.  Bei\neinigen von ihnen gibt es einen Timeout-Zähler,\nder nach 5 Minuten das\nzuletzt verwendete Werkzeug oder die zuletzt getroffene\nEntscheidung abbricht und dann\nzurückkehrt, wenn die Ergebnisse nicht zufriedenstellend sind.  Aber\nSie können diese 80% einschränken.  Kurz gesagt,\nwenn Sie etwas wie Discovery nutzen\noder herausfinden möchten, welches Tool Sie\nverwenden sollen, dann versuchen Sie, diese 80% äh Forschungsmodelle zu planen\n.  Wenn\nSie aber erneut versuchen, eine\nZusammenfassung zu erstellen, möchten Sie sehen: Okay,\ndas sind die Forschungsergebnisse, die ich habe.  Jetzt muss ich daraus\nein Ergebnis machen.  Die 20%-Regel\nfunktioniert wirklich gut.  Für 80 % der Aufgaben\nverwendet man üblicherweise hochentwickelte Modelle, die neuesten\nund besten. Für die restlichen 20 % benötigt man jedoch keine\nhochentwickelten Modelle, da\ndiese\ndeterministisch arbeiten. Man\ngibt ihnen vor, was benötigt wird, beispielsweise\nder bereits erwähnte Kritikerknoten. Dieser\nmuss nicht recherchieren oder herausfinden, was die beste Vorgehensweise ist. Er\nmuss lediglich das\nZiel, das angestrebte Ergebnis\nund die entsprechende Zusammenfassung ermitteln.\nAuch Fragen wie „Was wäre\nder nächste mögliche Schritt? Ich habe\ndieses Ergebnis, wonach sollte ich suchen?“ können\nmit den\ndynamischen 80-%-Modellen beantwortet werden. Zwar liegen alle\nErgebnisse der 80-%-Modelle vor, aber die Frage nach\ndem richtigen Weg oder den richtigen\nErgebnissen, die der Benutzer benötigt,\nkann mit\ndem 20-%-Modell beantwortet werden.   Und\nschließlich, äh, das ist wieder ein interessantes Beispiel für einen\nFehler, den wir schon beobachtet haben: Wenn der\nKontext wächst, denken die Teams: „Okay, wir können\nalles mit einem Agenten erledigen, weil das\nKontextfenster ziemlich groß ist, richtig? Wir\nkönnen alles hineinpacken, wir können einen Agenten bitten, äh,\nden Testteil zu übernehmen, wir können\ndiesen Agenten bitten, den Überprüfungsteil zu übernehmen, wir können\nden Agenten alle möglichen Dinge fragen, weil\nder Kontext derselbe ist, und sie können\nuns die Ergebnisse liefern.“ Das führt dazu, dass\nder Agent, wenn er weitermacht,\nvon den Eingaben überfordert wird und\nwieder versucht, seine\nursprüngliche Aufgabe aus den Augen zu verlieren.  Man gibt\ndem Agenten also beispielsweise vier Aufgaben, und irgendwann im Laufe der Zeit\nkonzentriert er sich auf zwei dieser Aufgaben.\nBei den ersten beiden Aufgaben erzielt man also hervorragende Ergebnisse,\naber die anderen beiden gehen irgendwie unter\n.  Für diese speziellen\nZwecke\nverwenden wir eine sogenannte\nWirkstoffmischung.  Und genau da hört man\nviel Gerede über mehrere Agenten oder\nMulti-Agenten-Technologiearchitekturen, bei denen man\nanstelle eines einzigen großen Agenten Agenten erstellt, die auf\nProblemspezialisten spezialisiert sind.  Wir bilden\nkleine Agenten aus, die\nin einer ihnen zugewiesenen spezifischen Aufgabe hervorragende Leistungen erbringen\n.  Darauf aufbauend\nentwickelt jeder Agent seine eigenen\ninteressanten Ideen oder erzielt eigene Ergebnisse.  Wie man\nsicherstellt, dass sich diese Ergebnisse kombinieren lassen und ein\nsinnvolles Gesamtbild ergeben.  Ich\nversuche beispielsweise, einen Urlaub zu finden.  Ich beauftrage\neinen Agenten, das beste Hotel für mich zu finden.  Ein weiterer\nMakler, der den besten Standort findet.  Ein anderer\nAgent versucht, die besten Flüge zu finden.  Aber alle\ndrei liefern mir unterschiedliche Ergebnisse.\nDas Hotel befindet sich in Griechenland.  Der Flug geht\nvon Amsterdam nach Portugal,\nund irgendwie ergibt das alles keinen Sinn,\nrichtig? Genau für solche Fälle gibt\nes ein Konzept namens Judge Agent. Seine Aufgabe ist es,\nalle\nErgebnisse zusammenzutragen und zu prüfen, ob sie\nzusammen Sinn ergeben. Man wendet also die\nbesten Methoden verschiedener Agenten an und\nerzielt so die besten Ergebnisse.\nEin Judge Agent hilft uns jedoch,\ndiese Ergebnisse zu kombinieren und daraus ein stimmiges Ganzes zu formen,\nanstatt so viele Dinge zu erhalten, die\nkeinen Sinn ergeben.\nEtwas Ähnliches setzen wir um.\nDies ist also unsere Architektur, äh, die Codos-\nArchitektur, bei der wir für die Code-Reviews\ndie gleiche äh Formel verwenden.  Im\nRahmen einer PR-Überprüfung haben wir einen\nKontextsammler, der den\nKontext aus den PRs sammelt; er kann den\nKontext auch aus der Kontext-Engine abrufen.\nEs sammelt zwar Kontextinformationen von den Tools, aber\ndann funktioniert es nicht und\nliefert keine Bewertungen.  Es\nteilt den gesamten\nbereitgestellten Kontext auf und leitet ihn an verschiedene\nAkteure weiter.  Die Aufgabe dieser Agenten besteht im Wesentlichen darin, sich\nauf ihren jeweiligen\nAufgabenbereich zu spezialisieren.  Zum Beispiel wird es\neinen Sicherheitsagenten geben, der versucht, Sicherheitslücken aufzuspüren\n.  Möglicherweise versucht ein Agent,\nCode zu schreiben.  Es könnte Unterschiede im Code geben.\nMöglicherweise versucht ein Agent,\ndie Jira-Vorgänge zu finden.  Sobald alle diese Agenten ihre Ergebnisse gemeldet haben\n, prüft ein Richteragent\ndie Resultate und fragt: „Okay, diese\nsind interessant genug, aber sind sie\nfür Sie relevant?“  Sie können dann\nim Kontext-Engine-Tool erneut die Pull Requests durchsehen\nund prüfen,\nwie viele der von Ihnen bereitgestellten 10 Elemente\ntatsächlich für Ihr Projekt sinnvoll sind.  Also\nnochmals die Ergebnisse so verfeinert, dass sie\nfür Sie verständlich sind.\nJa, ich denke, das war’s von meiner Seite.\nÄh,\nnoch Fragen?   Ja\n.  Ähm, wie genau ermöglicht man es dem Schwarm in der Praxis,\nmiteinander zu kommunizieren?\nÄh, Sie sprechen von den Agenten.\nAlso, da sind Agent A, Agent B und der\nRichter.  Ich kann mir vorstellen, dass sie in ein\nDateisystem schreiben oder dass sie ein firmeneigenes\nTool verwenden.   äh,\nwir verwenden äh Longchain ganz unten,\nund das wird verwendet, um zu\nkommunizieren und die Infrastruktur\nfür äh verschiedene Agenten aufzubauen.\nWeißt du, was die Sprachkette dafür verwendet?\nSammelt sie einfach die Antworten\nund gibt sie dann an\nden nächsten Agenten zurück?   Ja\n.  Ja.  Ja.  Ja.  Das ist also das, was\nwir tun: Wir versuchen, die\nErgebnisse zu erhalten und eine Eingabeaufforderung für den nächsten\nAgenten zu erstellen. Wenn es sich um mehrere Dinge handelt, gibt es wiederum\neinen Agenten, der die\nErgebnisse sammelt und eine bessere Eingabeaufforderung erstellt,\ndie dann für den nächsten Agenten optimiert wird. Haben\nSie schon einmal über einen\nKalibrierungsschritt für jeden Agenten nachgedacht?\nWenn Sie von Kalibrierung sprechen, können Sie\nmir das genauer erklären?\nAlso, wenn Sie eine\nCodeüberprüfung mit einem Agenten durchführen, richtig? Zumindest habe\nich heute gehört, dass man eine Kalibrierung durchführt, bei der\nman ihm sagt, was gut\nund was schlecht ist.   Ja\n.  Wenn Sie es also so formulieren,\nlassen Sie mich bitte wissen, ob das für Ihre\nFrage verständlich ist oder nicht.  Wir führen die Kalibrierung in einer\nForm durch, in der wir überprüfen, was wir als Kontext haben.\nWenn wir beispielsweise Code-\nReviews durchführen, weiß LLM nicht, was\nIhnen wichtig ist oder wie Sie arbeiten.\nWenn ein LLM-Student beispielsweise\nInput aus dem Gesundheitswesen, dem\nEinzelhandel\nund der Finanzbranche erhält,\nkann er dasselbe Java-Framework auf unterschiedliche Weise nutzen, wobei\nfür ihn unterschiedliche Dinge wichtig sind – für den Rest macht es keinen\nSinn.  Wir\nbieten Ihnen also zwei verschiedene Möglichkeiten,\nden Agenten Anweisungen zu geben, wie sie vorgehen sollen oder woran sie\narbeiten sollen.  Zum einen geben wir ihnen die PR-\nHistorie.  Wir indexieren also alle Ihre Pull Requests und prüfen,\nwann zuletzt ein ähnliches Problem\nfestgestellt wurde, und vergleichen es gegebenenfalls mit der\naktuellen Version\n.   Ja\n.  Ja.  Ja.  Ja.  Das machen wir.  Wir prüfen also,\nob wir in\nder Vergangenheit etwas Ähnliches gefunden haben, das wiederum\nzweimal auf den Kontext übertragen wurde.  Das erste Mal ist es so, dass wir\nden Unteragenten Kontext geben, damit sie\nDinge für Sie finden, und ein\nanderes Mal dem Richteragenten.\nWenn ich also 15 verschiedene Empfehlungen\nfür eine Code-Überprüfung erhalte, kann mein Prüfer\nprüfen, was vorher vorhanden war, wie\nIhr Prüfer kommentiert hat, wie Ihre\nEntwickler kommentiert haben und auf dieser Grundlage\nentscheiden, ob es sich lohnt, dies\nIhren Entwicklern zur Verfügung zu stellen oder nicht.  Und der andere\nTeil ist –\nund das gilt für jeden Agenten.\nFür jeden Agenten, ja,\nrichtig? Man teilt den Kontext nicht\nzwischen den Agenten, richtig?  Sie haben also\neinen spezifischen Kontext.\nJa, wir versuchen, den U-Teil zu lösen, indem\nwir, anstatt alles in den LLM zu laden, den\nwichtigeren Teil herausfiltern und dafür eine Kontext-Engine verwenden\n.  Wir wählen den\nwichtigeren Teil aus und liefern diesen\nspeziellen Teil nur dem jeweiligen\nAgenten.\nAber mir ist nicht klar, wie\nman diese Lücke schließt, anstatt zu sagen, man\nhabe einen\nQualitätsagenten und einen agentenspezifischen\nFramework-codierten Radioagenten,\nrichtig? Und dann teilt man, wie\nich es verstanden habe, im Grunde\nnur die spezifischen Informationen\nmit jedem Agenten, richtig? Und dann\nläuft im Grunde jeder Agent\natomar autonom. Ja.\nRechts.\nUnd es bietet kein vollständiges Bild,\nrichtig?  Zumindest aus der Perspektive eines\nMenschen, oder?  Und wenn man Code-\nReviews durchführt, ist es immer gut, wenn man einen\nvollständigen Überblick hat, richtig?  Ich würde sagen,\nfunktioniert diese Art von Methodik\nfür einfache Dinge, wie zum Beispiel die Verwendung von\nLinting?  Wird es verwendet? Ich weiß nicht, ob\nTests implementiert sind.  Aber wenn man darüber nachdenkt,\nzumindest denke ich, wenn man\nüber Architektur nachdenkt, zum Beispiel über\nArchitekturentscheidungen, die auch die\nSicherheit umfassen, denn alles ist ein Gleichgewicht,\nund äh,\nman muss das irgendwie berücksichtigen.\nWie löst man das also?\nJa, ich denke, wenn man sich die\nältere Version von Code-Reviews ansieht, sollte man\neinen erfahrenen Ingenieur haben, der den\nCode kennt, der weiß, welche\nPakete verwendet werden, und der\nkommentieren kann, ob der Entwickler\netwas Ähnliches wie das, was man gewohnt ist, gemacht hat\noder etwas völlig Seltsames,\nrichtig?  Früher hatte man dann einen\nSicherheitsbeauftragten, der überprüfte, ob\nalle Sicherheitsmaßnahmen vorhanden waren, ob die\nAPIs nicht fest codiert waren und ob\nkeine SQL-Injection-Angriffe möglich waren.  All\ndiese Dinge also, die\nSicherheitsexperten kennen.  Wenn Sie hingegen\nmit ISO- oder Socket-\nto-Conference-Anforderungen arbeiten, könnte ein Auditor\nden Teamleiter oder den\nleitenden Ingenieur fragen, ob Ihr Code protokolliert wird, ob\ndie\nÄnderungen protokolliert werden und so weiter.  Auch zuvor gab es\nviele Menschen mit\nSpezialkenntnissen, die sich\nspeziell mit solchen Bereichen befassten.  Wenn der\nKontext dann gegeben wird, heißt es immer: „\nDas sind meine Sicherheitsbedenken, denen ich\nständig nachgehen muss.“  Dies sind meine\narchitektonischen Bedenken.  Ein Architekt\nkönnte die Sache aus der architektonischen\nPerspektive betrachten.  Wir können etwas\nÄhnliches auch mit den Agenten machen,\ndenn zum Beispiel bei architektonischen\nSicherheitsbedenken haben wir ein Webportal, auf dem\nArchitekten ihre Richtlinien bereitstellen können, äh,\nCompliance-Beauftragte können\nihre Richtlinien bereitstellen, und ein Agent\nkann all diese Richtlinien überprüfen und\nsagen, ob sie validiert sind oder nicht.  Wenn Sie sich also\ndas\nAusgangsbild ansehen, weiß der Kontextsammler\nalles und stellt\nden Agenten dann den relevanten Kontext zur Verfügung.  Sie\nzwingen Ihre Kunden also im Grunde dazu,\ndiese Art von Dokumenten hochzuladen, richtig?\nIst das dann eine Art Voraussetzung?\nDenn das System liefert ja ein völlig\nanderes Ergebnis,\nwenn man die Informationen nicht genau so weitergibt. Das hängt von der\nOrganisation ab. Manche\nsagen, sie arbeiten ohne\nRegeln und Vorschriften, also sollen sie einfach mal unkonventionelle Lösungen anbieten. Das\nbedeutet auch, dass man nicht\nerwarten sollte, dass die Agenten etwas\nSpezifisches über die eigene Arbeit finden, es\nsei denn, es gibt eine gewisse PR-Historie. Denn\ndann greift die PR-Historie\nund zeigt an, was relevant ist. Auch\nwenn man sie nicht bereitstellt –\nich bin mir nicht sicher, ob die PR-Historie\nwirklich die beste Quelle ist, aber ich denke, sie kann eine sein. Deshalb gibt es\nverschiedene Quellen. Die\nPR-Historie ist eine\nRessource, sie ist Ihre,\nund jemand kocht bei mir zu Hause,\nja, aber sie kann eine der\nQuellen sein.\nUnd meine Frage ist: Ja,\nnatürlich kann sie das, richtig? Aber am\nEnde muss man entscheiden,\nsagen wir, auch vor Gericht, wie viel\nGewicht man hat. Also, die neuen\nDokumente, sagen wir mal…  Die technischen\nPrinzipien, die Architekturprinzipien –\nvergleichen Sie sie, sagen wir, mit Ihrem\nMer,\nja, ja, genau,\nsie könnten völlig aus dem\nGleichgewicht geraten, richtig? Ähm, es kommt darauf an, es kommt darauf an. Also, äh,\nich\ndenke, wenn man es nur aus einer\nPerspektive betrachtet, ist es schwierig zu entscheiden, aber\nwenn man den Kontext aus verschiedenen\nBlickwinkeln betrachtet, zum Beispiel die PR-Historie, ist das ein\nTeil, aber wenn man die Compliance durchführt und dies\nim Compliance-Portal angibt,\nist das wirklich wichtig.  Wir haben also verschiedene\nSegmente wie „Es ist ein Fehler“, „Es ist eine\nEmpfehlung“.  All diese\nFaktoren verleihen einem Feedback mehr Gewicht und helfen dabei, zu beurteilen,\nob es gut ist oder nicht.  Und jedes Mal, wenn Ihr\nEntwickler einen Vorschlag akzeptiert,\nwird dieser für den nächsten Vorschlag stärker gewichtet.\nWenn es den Vorschlag nicht annimmt\n, erhält es ein geringeres Gewicht.  Es geht also darum,\ndie Gewichtungen zu indexieren und sicherzustellen, dass sie irgendwo verwaltet werden.\nÄh, es gibt zwei Möglichkeiten.  Zum einen\nmessen wir, ob Ihre Empfehlungen vom Entwickler tatsächlich angenommen werden oder nicht.  Eine andere Möglichkeit besteht darin, anhand\nder früheren Pull Requests herauszufinden, ob ähnliche\nProbleme aufgetreten sind und ob Ihre Entwickler\ndiese tatsächlich umgesetzt haben.\nManche Leute sind es beispielsweise gewohnt,\nihre API-Schlüssel fest zu codieren, und ich\nhatte deswegen tatsächlich eine heftige Diskussion mit dem\nEntwickler, aber so machen wir das.  Nein, so sollte es\nnicht sein\n.  Ja, aber das Schöne passt\nauch gut zu dem, was ich meinte, richtig?\nWenn man sich also den Verlauf ansieht, heißt das\nnicht, dass es gut ist.\nUnd genau da\nversucht das System einem zu sagen, dass etwas nicht\ngut ist. Und dann liegt es\nan einem selbst,\nob man die nötigen Hinweise gibt, richtig? Es gibt also so\netwas wie Bugfixes und\nRegeln. Wenn man sie als Regel bereitstellt, werden sie\nhervorgehoben, egal ob\nman das möchte oder nicht.  Und dann gibt es noch\nBugs, bei denen der Agent versucht,\nSie darauf hinzuweisen, dass etwas nicht stimmt, und wenn der\nReviewer dem auch zustimmt und es nicht\n10 Mal implementiert hat, könnte der Reviewer\nes weniger gewichten und Ihnen ein\npositives Feedback geben.  Vielen Dank.\nDanke schön.",
  "transcript_chars": 25443,
  "ingested_at": "2026-06-15T00:50:30.535916+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": 6946,
    "like_count": 115,
    "channel_id": "UCLKPca3kwwd-B59HNr-_lvA",
    "categories": [
      "Science & Technology"
    ],
    "tags": [
      "ai",
      "ai engineer",
      "ai engineering",
      "software development",
      "tech",
      "startups",
      "software architecture",
      "machine learning"
    ]
  }
}