{
  "video_id": "Z_pCTBtCmck",
  "channel_slug": "deeplearningai",
  "channel_handle": "deeplearningai",
  "title": "AI Dev 26 x SF | Tom Howlett: Can LLMs Generate Enterprise Quality Code?",
  "duration_seconds": 2178.0,
  "url": "https://www.youtube.com/watch?v=Z_pCTBtCmck",
  "upload_date": "",
  "transcript": "Die große Frage lautet also:\nKönnen LLMs Code in Unternehmensqualität generieren\n?\nOffensichtlich hat sich im Bereich der\nSoftwareentwicklung,\ninsbesondere bei der Codegenerierung, viel verändert.\nAndrei Kapothy hat es sehr schön formuliert.\nIch bin sicher, dass ihr das alle schon erlebt habt.\nEs ist super schön.  Wir generieren Code.   Es\nfunktioniert.  Es fühlt sich fantastisch an.\nKönnen wir es im gesamten Unternehmen einsetzen?\nDie Situation erinnert mich irgendwie ein bisschen an\ndie 90er Jahre.  Ich bin alt genug, um mich an die\nEntstehung des World Wide Web zu erinnern.\nUnd äh,\nich habe die gleiche Erfahrung gemacht, richtig?  Ich\nkönnte eine Webseite schreiben.  Ich könnte\nes einsetzen.  Jeder auf der Welt könnte es sehen.\nDoch dann, als ich in einem\nGroßunternehmen arbeitete, gab es\ngroße Probleme.  Nein, nein, so einfach geht\ndas nicht.  Oder wir könnten es jedenfalls nicht schnell genug schaffen\n.\nUnd warum ist das so?  Das liegt daran, dass sich\nder Softwareentwicklungszyklus\nändern musste.  Es gab eine ganze Menge\nWerkzeuge, Prozesse und\nInfrastruktur, die\nfür diese neue Welt wirklich nicht gerüstet waren.\nUnd das hinkt der\nTechnologie gewissermaßen hinterher.  Und ich habe das Gefühl, dass\nwir genau das jetzt bei den LLM-Absolventen beobachten.  Sie sind\nunglaublich.\nDer Softwareentwicklungszyklus\nhat sich jedoch noch nicht angepasst.\nUnd Organisationen wie Code Rabbit leisten dabei einen wichtigen Beitrag\n.  Du machst das gut\n.  Und heute werde ich darüber sprechen\n, ich werde etwas genauer darauf eingehen\nund äh, wie wir daran arbeiten\n.   Gibt\nes also ein Problem?  Ich nehme an, das ist das Erste\n, richtig?\nDie Carnegie Mellon University hat hierzu eine hervorragende\nStudie über Cursor durchgeführt.  Ich weiß nicht,\nob du es gesehen hast.   Ähm,\nsie haben gezeigt, was, glaube ich,\njeder irgendwie schon ahnt, was da vor sich geht\n.\nAls die Leute anfingen, Cursor zu benutzen, gab es\neinen wirklich großen Geschwindigkeitsanstieg, drei-\nbis fünfmal so hoch.\nGeneriert Unmengen an Code, Unmengen an\nZeilen, Unmengen an Commits.\nSie erzeugen außerdem mehr\nWarnungen bei der statischen Analyse.  Hmm, okay.  Nun, mal sehen,\nwie das läuft.\nAuch die Komplexität des Codes nimmt zu.\nOkay, nun ja, heute kein großes Problem.\nAber jeder, der schon\nlänger als Softwareentwickler tätig ist, weiß, dass sich diese\nProbleme noch verstärken.\nProbleme im Code häufen sich, die Komplexität nimmt mit dem\nWachstum der Software zu, und je mehr davon\npassiert, desto schlimmer wird es, bis man\nan einen Punkt gelangt, an dem man nicht\nmehr entwickeln kann.\nUnd tatsächlich, nach drei Monaten – es dauerte nicht\nwirklich lange – wurden sie nicht\nmehr schneller.\nUnd ich nehme an, wir können davon ausgehen, dass sie\nFehler behoben haben.\nSie hatten Schwierigkeiten, einen Teil\ndes geschriebenen Codes zu verstehen.\nUnd dann ging es immer langsamer voran.\nIch nenne das also sozusagen die\nQualitätslücke im Unternehmen.  Ich glaube nicht, dass es nur für\nGroßunternehmen gedacht ist, sondern wahrscheinlich für\njeden, der\nProduktionscode in großem Umfang einsetzt.\nDie LLMs produzieren naturgemäß qualitativ hochwertigen\nCode auf einem gewissen Qualitätsniveau, was\nwirklich gut ist, wenn man einfach drauflosprogrammieren will\n, wenn man schnell loslegen möchte,\nsuper effektiv.  Man kann zwar sehr\nschnell vorankommen, aber das ist möglicherweise nicht skalierbar.\nWenn Sie eine kurzlebige App schreiben\n, die vielleicht weniger als 50.000 Codezeilen hat, dann\nfunktioniert das einwandfrei, okay?  Man kann\nes in der Regel sehr schnell zum Laufen bringen, und es ist\näußerst effektiv.  Und ich glaube, dass dies in\nder Tat so ist. Ich habe mit\nKunden gesprochen, die das tun und\nes lieben.  Das ist derzeit der große Vorteil für die LLMs\nund Agenten:\nSie können interne Anwendungen und\nTools superschnell generieren.  Das sind Dinge,\ndie sie\njahrelang nicht warten werden.\nWas wir nicht sehen, sind die gleichen\nVerbesserungen bei den geschäftskritischen\nProduktionsanwendungen, die den Betrieb dieser\nUnternehmen aufrechterhalten.\nIch spreche also von großen, umfangreicheren\nAnwendungen.\nAnwendungen, die voraussichtlich\njahrelang laufen werden.  Okay, wir haben Kunden, die\nAnwendungen ausführen, die noch in\nCOBOL geschrieben sind, okay?  Viele\nDinge müssen also eine lange Lebensdauer haben.\nUnd es wird viele potenzielle\nfeindliche Nutzer geben, richtig?  Diese Dinge\nwerden öffentlich sein.  Möglicherweise steht dahinter eine Bank\n.  Die Leute werden ihr Bestes geben\n.  Wir müssen sicherstellen, dass\nQualität und Sicherheit einwandfrei sind und das System\nzuverlässig ist.\nUm den von LLM generierten Code auf\ndieses Qualitätsniveau zu bringen, ist allerdings ein gewisser\nAufwand erforderlich.\nWenn wir die Prozesse des Standard-\nSDLC verwenden, die wir heute einsetzen, also im\nGrunde Code-Reviews und\nandere Prüfungen wie Sonar,\ndann müssen wir jedes Mal, wenn wir\nein Problem finden, den Code überarbeiten und\ndiesen Zyklus erneut durchlaufen.  Es dauert lange\n.   Die\nAgenten erzeugen sehr große Änderungssätze\n.  Die Codeüberprüfung wird dadurch weniger\neffektiv.  Es wird einfach immer schwieriger\n.  Und ich glaube, das ist das Problem, das\nwir momentan beobachten.  Und wir\nsehen oft, dass die Leute sagen: „Nun ja,\nes ist sowieso fast einfacher, es selbst zu schreiben\n, wo ich es verstehe, wenn ich\ndieses Qualitätsniveau benötige.“\nUnd was passiert, wenn man die Qualitätslücke nicht schließt\n?\nNun, wir sehen es ja bereits.  Ich werde\ndiese nicht im Detail durchgehen.\nWir beobachten einen\nAnstieg der Vorfälle auf der ganzen\nWelt.\nWir sehen jede Woche neue Geschichten.   Was\nmir am meisten Sorgen bereitet, ist, dass die Leute\ndiese zusätzlichen Kosten nicht mit einkalkulieren, wenn sie\nCode auf Unternehmensebene schreiben.  Und die Teams werden unter Druck gesetzt,\nso schnell wie möglich etwas zu entwickeln, sobald die\nLeute intuitiv etwas programmieren können,\nokay?  Und das funktioniert nicht, und genau da\nsehen wir diese Probleme.   Hoffentlich\nkönnen wir das\nBewusstsein für diese Herausforderung schärfen.\nWarum passiert das?\nDas ist also Sonar, bei uns dreht sich alles um\nCodequalität und Sicherheit.\nWir wollten also die LLM-Absolventen vergleichen.\nUnd wir haben einen Benchmark erstellt, der\nden anderen Benchmarks, die\nSie sehen, sehr ähnlich ist.\nEs umfasst rund 4.000 Aufgaben.\nÄhm, und wir erhalten ähnliche Ergebnisse hinsichtlich der\nKorrektheit und der Bestehensquoten.\nDer Unterschied zu dem, was wir tun, besteht darin,\ndass wir auch den generierten Code analysieren\n.\nWir analysieren es auf Komplexität,\nSicherheitslücken, Bugs\nsowie Wartbarkeits- und\nStrukturprobleme – also auf die Dinge, die einem\nwirklich schaden können –, um zu sehen, wie sich\ndiese\nin einer groß angelegten Unternehmensumgebung darstellen\n.\nDas wirklich Interessante daran ist, dass jedes\nModell anders ist.  Wir erkennen\nhier überhaupt kein einheitliches Muster.   Bei jeder\nneuen Version, jeder neuen Ausführung und\njedem neuen Denkmodus zeigt sich ein\nvöllig anderes Verhalten und ein\nanderes Profil.\nDieser\nCode mag zwar recht kompakt sein,\nkönnte aber auch gravierende\nSicherheitslücken aufweisen.  Ein anderes Modell\nmag zwar hinsichtlich der Sicherheitslücken hervorragend sein\n, ist aber extrem ausführlich\nund enthält bis zu viermal so viel Code\nwie das andere Modell.  Und man muss\ndiese Kompromisse wirklich eingehen.\nWir haben also diesen\nBenchmark veröffentlicht.  Sie finden die Informationen, wenn Sie nach „\nSonar LLM Benchmark“ googeln.\nÄhm, und ich glaube, wir haben jetzt\n52 Modelle.\nUnd dann bis hin zu den neuesten Versionen,\nwir haben also Opus 4.7 und GPT 5.5 getestet.\nUnd hier sehen wir die Unterschiede wirklich\n.\nWährend die Bestehensquoten\nderzeit immer bei etwa 80 % liegen und ich mir nicht sicher bin, ob es\nso viel ausmacht, ob sie 1 oder\n2 % darüber oder darunter liegen,\nist der Code drastisch anders.  Also,\nwenn wir uns das hier ansehen,\nkönnen wir sehen, dass Gemini und Sonnet – ich\nweiß nicht, Gemini und Opus 4 7 denken –\netwa 336 Zeilen\nCode für diese Aufgaben schreiben.\nGPT-5 hingegen arbeitet an 703.000\nCodezeilen.  Wir haben dort doppelt so viel\nCode auf beiden hochmodernen\nHochleistungsmodellen.\nSchau dir die Käfer an.  Wir haben dort eine riesige Auswahl\n.  Schauen Sie sich die\nSicherheitslücken an.\nWir werden das also weiterhin so machen.\nIch denke, für Sie als Kunde\ndieser Modelle ist es wirklich gut, sich dessen\nbewusst zu sein, was Sie\nberücksichtigen müssen.\nWenn Sie sich diese Benchmark ansehen,\nkönnen Sie das Profil jedes einzelnen Modells genauer unter die Lupe nehmen.\nMan kann bestimmte Fehler erkennen, die häufig auftreten\n, spezifische Sicherheitslücken.   Was\nwir zunehmend beobachten, sind\nProbleme mit der Parallelverarbeitung, was\neine echte Herausforderung darstellen wird.  Sie sind\nschwer zu debuggen, schwer zu durchdenken.  Ich glaube, je\nintelligenter die Modelle werden, desto\nschwieriger werden die Fehler, die sie tatsächlich erzeugen,\nwas ja auch ganz natürlich ist, oder?\nCool.  Wie\nbei den meisten Benchmarks handelt es sich also im Grunde um\neine einmalige Sache.  Er erhält eine Aufgabe,\nliefert Code, der Code wird\nausgewertet.\nAber das ist doch keine richtige\nSoftwareentwicklung, oder?\nAls Softwareentwickler arbeiten wir eines Tages\nan einer einzigen Funktion.  Wir wissen nicht,\nworan wir\nmorgen arbeiten werden.  Am nächsten Tag fügen wir eine weitere\nFunktion hinzu.\nUnd dann noch ein Feature, und noch eins\n.\nDie Kunst der Softwareentwicklung besteht also darin,\netwas zu entwerfen, das auch\nmorgen noch funktioniert, obwohl man nicht weiß, was\nmorgen passieren wird.\nEs gibt einen supercoolen Benchmark, mit dem ich in\nletzter Zeit viel herumexperimentiert habe, der heißt Slip\nSlop Code Bench.  Das ist ein echter\nZungenbrecher.\nAlso, Slop Code Bench,\nich wünschte, ich hätte einen anderen Namen.\nUm im Grunde zu versuchen, dieses\nSzenario nachzubilden.\nEs beginnt also mit einer einzigen Aufgabe\nund bietet dann keinerlei\nEinblick in die zukünftigen Aufgaben.  Dann wird\nein zweites hinzugefügt, dann noch ein drittes,\nund anschließend wird der Code ausgewertet.   Eine\nsehr ähnliche Bewertungsart also.\nSie achten auf Komplexität,\nWeitschweifigkeit und ähnliche Dinge.\nUnd es ist ein unterhaltsamer Vergleichswert, weil man damit ein bisschen\nherumspielen kann.  Sie können\ndie Konfigurationen ändern.  Sie können den\nKontext ändern.  Sie können verschiedene Tools anschließen\nund deren Auswirkungen beobachten.\nUnd das erste Diagramm, das ich zeigen werde, ist das, was passiert,\nwenn man nichts hat und keinen\nKontext angibt; dann sagt man einfach, es löst sich.\nIch habe das in Python in Python gemacht,\nund zwar in einer Code-\nSuchanwendung.\nDer erste Schritt ist also eine sehr einfache Code-\nSuche.   Der\nCode ist schön.  300 Zeilen Python-Code.\nWenige Funktionen.  Sieht alles gut aus.  Großartig.\nAber im zweiten, aber im dritten\n,\noh, immer noch eine einzelne Reihe.\nNoch zwei oder drei Funktionen.  Sie sind\njetzt etwas größer.\nKein Problem.\nGehen wir auf 10 und schauen wir, was passiert.\nOkay, jetzt habe ich eine\neinzige Python-Datei mit 6.000 Zeilen.  Ich habe da Funktionen mit 600 Zeilen\nLänge drin.  Sie sind\nvöllig unverständlich.\nUnglaublich, aber der LLM kann das immer noch.\nUnd es schafft es immer noch, weiteren Code dieser Art hinzuzufügen\n.  Sie\nscheinen schlampigen Code geradezu zu mögen,\nwas ich als\nSoftwareentwickler natürlich nicht nachvollziehen kann, aber ich\ndenke, es gibt einen Punkt, an dem das\nnicht mehr der Fall ist, oder?  Ich glaube, es gibt einen Punkt, an dem\nes zu viel wird und dann nachlässt\n.  Nach 10 Kontrollpunkten ist es nicht mehr zu sehen\n.  Es hat nach wie vor eine gute\nErfolgsquote.\nÄhm,\nja, es ist eine unterhaltsame Übung, und ich\ndenke, sie verdeutlicht sehr gut,\ndass man beim ständigen Hinzufügen immer wieder\ndenselben Code ändert.  Es\nwird das Mindeste tun, was\nzur Lösung Ihrer Aufgabe nötig ist, richtig?  Ihre Aufgabe ist die\nErfolgsquote.\nWir sagen darin nicht, dass wir\ngute Qualität wollen.\nÄhm,\nund das wird sich einfach wieder beheben.\nSeien Sie sich dessen also unbedingt bewusst.\nWenn wir also solchen Code haben, wie können\nwir dann sicherstellen, dass die\nQualität gut ist?\nIch denke, die Überprüfung des Codes durch den Menschen ist\nfür die meisten\nOrganisationen, insbesondere in\nUnternehmen, die wichtigste Säule der Qualitätssicherung.\nUnd ich denke,\nSie wissen auch, dass die meisten Unternehmen vor dem LLM-Abschluss genauso\nviel Zeit mit Code-Reviews verbringen wie mit dem eigentlichen\nProgrammieren.\nAber wenn die Codegenerierung 10-mal\nschneller ist,\ndann verbringt man, ich weiß nicht, meine\nMathekenntnisse sind miserabel, 90 bis 95 % seiner Zeit mit der\nÜberprüfung.\nDas ist ein wirklich schwieriger Prozess.\nEs ist auch wirklich schwer, nicht wahr?\nDas Ganze ist so, als würdest du\nmit einem Agenten zusammenarbeiten, der etwas getan hat, was\ndu selbst nicht unbedingt tun könntest.  Das ginge\nsicher nicht so schnell.\nIch glaube, wir haben eine natürliche Voreingenommenheit.\nWarum sollte ich diesem Ding sagen, dass es falsch ist,\nnicht wahr?  Es sieht wirklich schön aus.  Das ging aber\nwahnsinnig schnell, oder?  Das ist wirklich schwer\n.\nIch habe mich sehr über diese Arbeit\nvon Sharan Nave gefreut, die auch auf einer Wharton-Studie basiert.\nUm es\ntreffend zu nennen: Schnelles Denken, langsames Denken und\nkünstliches Denken.  Ich denke also, dass viele\nhier das Buch „Schnelles Denken,\nlangsames Denken“ von Kahneman gelesen haben werden.  Aber sie haben so etwas wie\nkünstliche Intelligenz hinzugefügt.\nWie verändert das unser Denken?\nSie präsentierten, ich glaube, es waren\n10.000 Versuche.\nEs begann damit, dass sie sagten\n, manche Dinge seien richtig,\nmanche nicht.  Diejenigen, die die\nBewertung vorgenommen haben,\nwaren mit den Dingen zufrieden, 92 % von\nihnen waren mit den Dingen zufrieden, die\nkorrekt waren.  Also, ich habe ein ziemlich gutes Gespür dafür, ob die\nDinge richtig sind.  Es gibt also\noffensichtlich noch immer einige Leute, die der Meinung sind, dass etwas nicht stimmt\n.   Selbst\nwenn etwas nicht stimmte,\nsagten die Leute in vier von\nfünf Fällen, es sei richtig.  Ich habe den Rat dennoch befolgt\n.\nWenn das der Fall ist, können wir\nuns dann wirklich zutrauen, Code manuell zu überprüfen?\nKönnen wir wirklich objektiv sein, wenn\ndiese psychologischen Mechanismen bei KI eine Rolle spielen?\nIch habe darauf noch keine wirkliche Antwort\n.  Ich bin mir sicher, dass es hier einige großartige\nIngenieure gibt, die objektiv bleiben können,\naber ich weiß, dass ich\ndefinitiv davon beeinflusst werde.   Das\nist also die menschliche Überprüfung.  Wie sieht es mit KI-gestützter\nÜberprüfung aus?  Wir haben einfach einen weiteren LLM mit der\nCode-Review beauftragt und lassen ihn den Code überprüfen.\nUnd tatsächlich\nist die KI-Überprüfung wirklich beeindruckend.  Ich bin sicher,\nSie haben gerade den vorherigen Vortrag gesehen. Mir wurde gesagt,\nSie hätten gerade den vorherigen Vortrag gesehen.  Code\nRapid leistet hervorragende Arbeit beim Aufspüren von\nFehlern.\nAber es scheint auch ein wenig fehlerhaft zu sein, nicht wahr\n?  Es ist so, als ob man sagen würde: Okay, das ist der LLM-Absolvent, der es\ngeschafft hat.  Es überzeugt mich nun davon, dass mein\nCode korrekt ist, weil es ihn überprüft hat.\nOder ein anderer LLM-Studiengang, richtig?\nIch glaube, das erinnert mich an meine Zeit als\nEntwickler. Damals habe ich es viel lieber gemacht, bei einer\nCode-Review neben dem Entwickler zu sitzen,\nder den Code überprüft hat.\nUnd dann würde er so etwas finden\nund ich würde sagen: „Nein, nein, nein, das ist in Ordnung.“  Ich\nglaube, es war eher ein Junior-Entwickler, der sagte:\n\"Nein, nein, nein, nein, wissen Sie,\ndas geht einfach nicht. Deshalb. Es ist\ndie richtige Entscheidung.\"  Und sie sagen: „Okay,\nTom. Alles klar, dann checken wir es mal ein.“\nIch habe das Gefühl, dass es bei den beiden\nLLMs so ähnlich ist, da sie sich gegenseitig ihren Code überprüfen\n.  Es überzeugt einen fast davon, dass\ndas so richtig ist.\nAus menschlicher Sicht trägt all das zu dieser Voreingenommenheit bei\n.   Ähm,\nich muss damit aufhören.  Danach lief alles nur noch über\nGitHub Pull Requests.\nAber ja, wir müssen bei KI-gestützten Überprüfungen vorsichtig sein\n.  Ich finde es großartig.  Ich denke, es\nergänzt all die anderen Dinge, die wir im Zusammenhang mit der\nÜberprüfung tun müssen, aber wir müssen\nsehr vorsichtig sein, dass wir nicht denken,\nnur weil eine KI einen KI-geprüften Code überprüft hat\n, dass das alles war.  Es ist vollständig\nverifiziert.  Es ist sicher.\nWas können wir also gegen all das tun?\nNun ja,\nbei Sonar ging es uns schon immer um die\nVerifizierung von Code.\nWir haben es so umgesetzt, dass es den\nmenschlichen Entwickler unterstützt, und jetzt\nverlagern wir den Fokus auf KI – etwas, das eher\nfür den KI-Entwickler oder genauer gesagt für den\nAgenten geeignet ist.   Beginnen wir also damit, uns anzusehen, was eine\ngute Verifizierung ausmacht.\nDas Erste, was gleichzeitig das\nSchwierigste ist, ist, dass es\nvollständig sein muss.\nEine der Dinge, die wir überprüfen müssen, ist, ob\ndie\nentwickelte Funktionalität den Spezifikationen entspricht.\nUnd ich freue mich riesig zu sehen, dass TDD und\nBDD hier ein großes Comeback feiern,\nnicht wahr?  Das ist eine gute Art zu\nsagen: Ich beginne mit etwas in natürlicher\nSprache, am Ende habe ich etwas Code, und\nhier sind einige Tests, die beweisen,\ndass ich von dort dorthin gelangt bin.  Und Sie\nals Prüfer können diese Tests überprüfen und\nsicherstellen, dass sie Ihrer Absicht entsprachen, dass\nsie vollständig Ihrer Absicht entsprachen.\nDas ist also eine gute Methode, und ich meine, die\nMakler dazu zu bringen, eine\nRot-Grün-Entwicklung durchzuführen,\nist ein großartiger Anfang.\nAber Unit-Tests können nicht\nalles erfassen, oder?  Da ist das Orakelproblem\n.  Es gäbe unendlich viele\nDinge, die man\ntesten müsste, um jede einzelne Möglichkeit zu prüfen.\nSonar kommt also ins Spiel, indem es\njene Dinge aufspürt, die nicht Teil Ihrer\nSpezifikationen sind, aber dennoch\nfunktional funktionieren müssen.  Solche\närgerlichen Fehler, die man nicht vorhergesehen hat,\ndiese Sicherheitslücken,\ndiese Wartungsprobleme, an die man damals\nnicht gedacht hat,\ndie aber in Zukunft wichtig werden könnten.\nUnd ich denke, die Kombination aus beidem, TDD und dieser Methode,\nergibt eine\numfassendere Version.  Ich will nicht behaupten, dass\nwir schon am Ziel sind,\nund ich bin mir sicher, dass es im Zuge der\nWeiterentwicklung des KI-SDLC noch mehr geben wird,\naber für den Moment ist das ein guter Anfang.\nDie Ergebnisse dieser Überprüfung müssen\nnachvollziehbar sein.\nZum Glück ist TDD so.  Im Code können wir ganz klar sehen\n, ob es funktioniert oder nicht\n.\nUnd das können wir auch mit statischer Analyse sehen\n.   Bei\nder statischen Analyse wird ein Problem aufgeworfen, das\nmorgen erneut zur Sprache kommen wird und auch\nnächsten Donnerstag wieder.  Sie\nkönnen den Tag sehen, an dem es im Code erschienen ist,\nund den Tag, an dem es aus dem Code entfernt wurde\n.\nEs ist unvoreingenommen, es ist subjektiv.\nEs ist deterministisch.\nIch denke also, wir konzentrieren uns auf die hörbare\nSeite.\nUnd schließlich muss es effizient sein.\nWir können nicht 95 % unserer Zeit mit\nCode-Reviews verbringen.\nEine Art Verifizierung, die sowohl\nschnell als auch relativ kostengünstig ist, damit wir\nsie ständig durchführen können.  Zeit.  Darauf werde ich gleich eingehen\n.\nÄhm, das hilft wirklich.\nHier möchte man sicherlich keine nächtlichen Kontrollen durchführen.\nWie Sie wissen, haben wir diesen neuen\nSTLC, den agentenzentrierten Entwicklungszyklus, geprägt\n.   Es handelt sich dabei im Grunde um\neine Art inneren und äußeren Kreislauf,\nder den Agenten\nzunächst dazu anleitet, korrekten Code zu schreiben, dann\nüberprüft, ob der Code korrekt ist,\nund schließlich etwaige Probleme löst oder\nden Agenten in die Lage versetzt, die Probleme selbst zu lösen.   Ähm, also\n, lasst uns das mal etwas\ngenauer betrachten.\nSprechen wir also über die Richtlinien.\nAls ich noch in einem Softwareteam gearbeitet habe, habe\nich neue Mitarbeiter nicht einfach auf\nmeine Codebasis losgelassen, oder?\nIch werde sie hinsetzen lassen.\nIch werde über unsere Codierungsstandards sprechen\n.  Ich werde über die\nArchitektur unserer Anwendung sprechen.  Ich werde darüber\nsprechen, welches\nQualitätsniveau ich erwarte.\nDas Gleiche gilt für Agenten.\nUnd irgendwie gelingt uns das,\nglaube ich, nicht besonders gut.\nWir neigen dazu, etwas in\nunsere Kontextdatei einzutragen,\naber wir lassen es die\nArchitektur selbst entdecken.\nWir haben es ähm,\nich weiß nicht, ja, hinsichtlich der\nQualitätsstandards zugelassen.  Wir sagen ihm einfach, es soll seine\nArbeit gut machen, nehme ich an.  Man sagt ja oft: „Schreiben Sie\nguten Code.“  Funktioniert nicht wirklich.\nDas Gleiche gilt auch für die Verifizierung.\nIch werde den\nneuen Code dieses Auftragnehmers sehr\nsorgfältig prüfen.  Gleiches gilt für den Agenten.\nDie Überprüfung ist sehr wichtig.\nUnd dann müssen wir sicherstellen, dass\nder neue Auftragnehmer weiß, wie wir\ndie Probleme lösen, richtig?  Er kennt die\neinzuhaltenden Standards.\nDas Gleiche gilt für den Agenten.\nWir haben also diesen Leitfaden-, Überprüfungs- und Lösungszyklus\n, der meiner Meinung nach ein sehr natürlicher\nSoftwareentwicklungszyklus ist.\nAber es ist super wichtig, weil wir oft\nnur ans Verifizieren denken.\nWir müssen unbedingt alle drei einbeziehen.\nDie größte Veränderung, zumindest für Sonar, ist also\ndieses Konzept der inneren und äußeren\nSchleife.\nDie äußere Schleife ist der Mensch in der Schleife,\ndie wir schon immer hatten.  Wir prüfen also den\nCode im Pull Request,\nstellen sicher, dass alle\nPrüfungen durchlaufen werden und dass vor dem Mergen\nalles sicher ist.\nAber die äußere Schleife ist ziemlich\nineffizient, oder?  Es ist schon etwas\nspät.\nWenn ich 50 Probleme in meiner PR-Meldung habe,\nund um ehrlich zu sein, ist das der Grund, warum in der\nVergangenheit nicht jeder Sonar so sehr geliebt hat, wie\nwir es uns erhofft hätten.\nDiese Probleme müssen behoben werden, richtig?\nDas ist ärgerlich.  Du hast deinen Pull Request eingereicht,\ndachtest, du wärst fertig, und plötzlich tauchen 50\nProbleme darin auf.\nWir möchten diese\nProbleme also im Vorfeld beheben können.  Bei menschlichen\nEntwicklern gäbe es IDE-Erweiterungen,\ndie ihnen bei der Arbeit helfen würden\n.\nUnd so haben wir etwas Ähnliches mit\nAgenten, denen\nwir die\nWerkzeuge zur Verfügung stellen, die sie benötigen, um\nsie anzuleiten, ihren eigenen Code zu überprüfen\nund natürlich auch ihre eigenen Probleme zu lösen.  Sie\nwissen, wie man die auftretenden Probleme löst\n.\nÄhm\n, ja, das war eigentlich ganz nett, denn\nes bedeutet, dass, wenn alles gut funktioniert, dem\nEntwickler Code präsentiert wird, der dem von ihm\nerwarteten Qualitätsstandard entspricht, und\nman führt die abschließenden Prüfungen nur noch in der\näußeren Schleife durch, wo es ineffizienter ist.\nWie sieht das in der Praxis aus?\nZurück zur Code-Slot-Bank.\nIch bin also ununterbrochen damit beschäftigt,\nTests auf Code Slot Bench durchzuführen.  Meine CTOs\nfragen mich oft nach meiner Token-Nutzung.\nIn diesem Fall habe ich also das Original,\ndas ganz ohne Anleitung auskam.\nUnd damit wird die strukturelle\nErosion gemessen.  Bei der strukturellen Erosion handelt es sich um\ngroße, hochkomplexe Prozesse, die\nman kaum nachvollziehen kann.  Das ist eine ziemlich\nschnelle Art, es auszudrücken.\nWenn Sie den Agenten anleiten, erzielen Sie hier eine deutliche\nVerbesserung, richtig?\nWenn man es mit einem guten Kontext leitet und ihm\narchitektonische Richtlinien gibt, leistet es\nviel bessere Arbeit.  Man bekommt die\nstrukturelle Erosion einigermaßen in den\nGriff.\nWenn man es anleitet\nund dann überprüft, funktioniert es noch\nbesser.\nDer Makler muss\nimmer Kompromisse eingehen, nicht wahr?  Es kann nicht\nalles.   Nun ja\n, das könnte es, wenn es unbegrenzt Zeit\nund Energie hätte,\naber innerhalb eines bestimmten Zeitraums kann es\nso viel erreichen.\nWenn Sie es anweisen, eine komplexere Architektur zu erstellen\n, wird es dafür Energie aufwenden\n.  Sie werden oft eine niedrigere Erfolgsquote\nbei dem von Ihnen durchgeführten Test feststellen.\nUnd dann wird es einfach so weitergehen, und es wird\nanfangen, Abkürzungen zu nehmen, besonders wenn\nIhr Hauptziel darin besteht,\ndie Prüfungen zu bestehen.\nUnd ich denke, worauf ich hinauswill, ist, dass\nes immer Kompromisse geben wird.\nWenn man weiß, dass man etwas überprüft, und wenn man\nden Code überprüft,\nkann man sozusagen alle Abkürzungen erkennen, die er\ngenommen hat,\nund alles, was er nicht vollständig verstanden hat.\nUnd wenn Sie diesem Programm Feedback geben,\nkann es diese Probleme beheben.\nDas geht also ziemlich schnell.  Wir haben eine\nArt neue Verifizierungsmethode entwickelt,\ndie sehr schnell funktioniert.\nÄhm, und das trägt eigentlich nicht viel bei.\nWir haben es so effizient wie\nmöglich gestaltet, und ich bin mir sicher, dass es mit der\nWeiterentwicklung noch effizienter werden wird.\nWie können wir das jetzt umsetzen?\nIch weiß nicht, wie viele von Ihnen\nSonarQube kennen, aber normalerweise ist es ein recht\nhoher Anteil.  Ich vermute, bei\nDatenwissenschaftlern ist das vielleicht nicht so sehr der Fall.  Vielleicht machen wir es einfach mit den Händen\n.  Wie viele Menschen kennen\nSonarQube?\nOkay.\nVermutlich fast die Hälfte.  Das ist cool.\nWenn Sie also nicht... ähm...\nwir verfolgen einen mehrschichtigen Zero-Trust-\nAnsatz zur Codeverifizierung.\nEs ist deterministisch.  Es verwendet keinen\nLLM zur Verifizierung.  Es verwendet\nstatische Analyse.\nWir haben viele Ingenieure für statische Analysen\n, und wir gehen dabei deutlich tiefer als\nviele der anderen Analyseanbieter\n.\nSo können wir komplexere Probleme mit einer\nniedrigen Rate falsch positiver Ergebnisse finden.\nWir decken über 40 Sprachen ab.\nÄhm, 7,5 Tausend verschiedene Prüfungen,\ndie wir durchführen werden.\nUnd wir haben es integriert. Wir haben\nkürzlich die Architektur hinzugefügt.  Das\nwar etwas, was mich immer frustriert hat, dass\nwir es verpasst haben.   Ähm, denn\nfür mich war bei technischen Schulden die\nArchitektur die größte Herausforderung.\nUnd ich denke, wir hatten das Glück,\nvor ein paar Jahren in Architektur zu investieren.  Wir haben kürzlich\ndas Architekturprojekt veröffentlicht, mit dem\nSie nun einen Abhängigkeitsgraphen\nIhres Codes erstellen und auf\ngrafische Weise Einschränkungen festlegen können, um zu verdeutlichen, wie\nunsere Geschäftsschicht mit\nunserer Datenschicht kommunizieren soll.  Unsere Datenschicht\nkommuniziert nicht mit unserer Geschäftsschicht.  Und\ngehen Sie dabei so detailliert vor, wie Sie möchten.\nUnser Ziel ist es also, einen Plan\nfür diesen ACDC-Zyklus zu erstellen, diesen Leitfaden zu erstellen, zu überprüfen\nund zu lösen.   Dafür gibt es\nmittlerweile einige gute Tools.\nWir haben also ein Plugin auf dem Cloud-\nMarktplatz und fügen Plugins auch\nden anderen Agenten-Marktplätzen hinzu.   Dadurch\nwerden MCP und CLI installiert, mit denen\nSie die Tools verwenden können, die den\ninneren Schleifenteil ausführen.\nSobald das erledigt ist, was muss konfiguriert werden?\nWir müssen den Agenten erst dazu bringen,\ndie Tools auch wirklich zu benutzen.   Im\nIdealfall nutzt der Agent die Tools von Anfang an so, wie\nwir es erwarten, aber\noft geben wir ihm in Claude MD oder Agent MD am Ende doch\neinige Richtlinien vor.  Ich denke,\nwir arbeiten momentan noch daran, die beste Methode dafür zu finden\n.\nDer Agent wird niemals deterministisch sein\nund er wird oft ignorieren,\nwas wir verlangen.  Ähm, aber wir können da schon\nziemlich nah rankommen.\nAus diesem Grund ist es wirklich\nwichtig, dass wir\ndie Auswirkungen jeder Änderung, die Sie an Kontextdateien mit Agenten vornehmen, überwachen, und zwar nicht nur\neinmal.  So oft nehme ich eine kleine\nAnpassung an meinem Claude MD vor und es macht\ngenau das, was ich mir erhofft habe, und ich denke:\nJa, ich habe den Agenten gemeistert, aber beim\nnächsten Durchlauf läuft es wieder\nganz anders.  Das ist aber gar nicht so einfach\n.  Daher lohnt es sich,\nmehrere Durchläufe zu überwachen.\nSie möchten, dass die Wahrscheinlichkeit, dass es das tut,\nwas Sie wollen, so\nhoch wie möglich ist.\nUnd worauf man sich konzentrieren sollte,\nist auch das Ergebnis.  Wie der Agent\ndorthin gelangt, müssen wir dem\nAgenten überlassen.  Wir können nicht sagen, dass Sie genau diesem\nProzess folgen sollen, denn dadurch verlieren Sie die Wirksamkeit des Beauftragten\n.\nAber wenn man sagt: Okay, ihr habt hier eine Reihe\nvon Werkzeugen, so sind sie\nnützlich, die Ausgabe wird hier\nin SonarQube überprüft,\nihr habt eine Möglichkeit, das selbst zu überprüfen\n, dann wird sich ein guter\nProzess dafür entwickeln.   Lassen Sie uns\nden Prozess also etwas\ngenauer betrachten.  Beginnen wir mit der inneren\nSchleife.   Der\nlustige Teil.\nDer Benutzer\nerteilt also dem Agenten die Aufgabe.   Als\nerstes holt sich der Agent\neinige Richtlinien von\nSonarQube.\nDiese Richtlinien werden sich um Dinge drehen, die\nvermieden werden sollten, um Codierungsstandards\nund um die Architektur.\nDann kommt es zurück, der Agent generiert\nden Code.\nDer Agent überprüft dann\nden Code, ruft Analysemethoden auf und prüft, ob\nÄnderungen vorgenommen wurden.\nWenn dabei Probleme gefunden werden, werden\ndiese behoben, anschließend erfolgt eine erneute Analyse, und\nder Zyklus wird wiederholt.  Es läuft alles ziemlich\nreibungslos ab.  Die Mitarbeiter beheben in der Regel alle\nProbleme auf Anhieb.\nSchauen wir uns also den ersten Schritt an,\ndie Richtlinien, den Kontext.\nWir haben also eine MCVP-Methode, um\nRichtlinien zu erhalten.\nDer Agent wird ihm mitteilen, woran er gerade\narbeitet.\nEs wird also an einer Datenzugriffskomponente gearbeitet\n.\nUnd das Tool weiß, an welchem ​​Projekt es\narbeitet.\nUnd an diesem Punkt greift es auf\ndie Historie dieses Projekts zu, um festzustellen, dass es\nan der Datenzugriffskomponente arbeitet\n.  Dabei werden die Datenzugriffskomponenten untersucht\nund die\nProbleme analysiert, die in\nder Vergangenheit bei diesen Komponenten aufgetreten sind.\nAnschließend wird eine Liste mit\nPunkten angezeigt, die der Agent\nbeachten sollte.\nDadurch werden\ndie Richtlinien gewissermaßen auf die\njeweiligen Aufgaben zugeschnitten.\nWenn wir alle 7.500 Prüfungen durchführen würden,\nwäre das Kontextfenster\nvollständig gefüllt, richtig?  Das können wir nicht tun.  Das\nwürde nicht funktionieren.  Aber wenn wir\ndie Probleme, die dadurch entstehen werden, vorhersehen\nund ihnen vorbeugen können, dann\nfunktioniert das wirklich gut.  Und tatsächlich\nreduziert es in unseren Tests tatsächlich die\nAnzahl der auftretenden Probleme\n.\nAls nächstes kommt die Architektur.\nWenn Sie also\nSonarQube-Nutzer sind und es noch nicht gesehen haben, dann haben Sie die Architekturfunktion noch nicht entdeckt – die ist echt super\n.  Wir\nhaben hier einen sehr minimalistischen\nAbhängigkeitsgraphen, in dem Sie navigieren können, um\nwirklich zu sehen, was in\nIhrer Architektur vor sich geht.\nUnd dann eine Möglichkeit, zu definieren, was genau das sein soll\n.\nDie Werkzeuge, die der Agent hier verwenden wird, sind also:\ndie aktuelle Architektur ermitteln und die\nangestrebte Architektur ermitteln.\nWenn es diese Werkzeuge nicht besitzt,\nwird es versuchen,\ndie Dateien selbst zu beschaffen, richtig?  Es sucht nach Dateien, die\nbearbeitet werden sollen.  Es wird versuchen,\nBeziehungen herzustellen.  Es wird geprüft, ob\nSchnittstellen und Vererbung vorhanden sind.  Aber es funktioniert\nnicht so effizient.  Indem man ihm\ndiesen architektonischen Abhängigkeitsgraphen gibt, leistet es\nwirklich gute Arbeit.\nEs gibt außerdem eine ganze Reihe von Tools, die\nich hier nicht aufgeführt habe, mit denen sich\ndiese Architektur erkunden lässt.  Es kann\nHierarchien erstellen.  Ähm, es kann,\nes kann sehen, ähm ja, verschiedene\nArten von Beziehungen.\nIch hoffe also, dass Sie damit und mit Ihrer Hilfe sehen, wie es\nfunktioniert, und dass Sie erkennen, dass ich die\nArchitektur überprüft habe.  Hier ist mein Plan.  Ich weiß, dass es\nder beabsichtigten Architektur entspricht.\nIch werde hier keine Regeln brechen.\nUnd bei der anschließenden Überprüfung stellen wir keine\nAbweichungen fest.\nUnd so haben wir hoffentlich einen\nguten Code geschaffen.  Ich hatte keinerlei\nSonarprobleme.  Es hatte eine gute Architektur.  Wir können\nes verifizieren lassen.\nDas Problem bei der statischen Analyse\nist, dass sie eine Weile dauern kann.\nWenn man sich nur eine Datei ansieht, erfasst man nur\neinen Teil der Probleme.  Es treten\nausschließlich Syntaxfehler auf.\nDer Code ist wesentlich komplexer.\nUnd die wirklich wertvollen Fragen beinhalten\nSemantik.  Wenn ich also\neine Methode lese, die\nandere Methoden aufruft,\nmöchte ich wissen, welche Methoden das sind, um zu überprüfen,\nob die Methode\nkorrekt arbeitet, richtig?   Es reicht also\nnicht aus, sich nur eine Datei anzusehen und\nsie zu analysieren.  Um gute Ergebnisse zu erzielen, müssen Sie die Analyse\nim Kontext der gesamten\nAnwendung durchführen.  Um\ndie wirklich wertvollen\nThemen zu finden.\nAlso, so wie wir das jetzt machen, ähm\nja, aber das dauert eine Weile, richtig?\nDas kann bei einer großen Codebasis einige Minuten dauern,\nund das können wir\nmit dem Agenten nicht machen, richtig?  Wir wollen nicht\nabwarten und eine vollständige Analyse durchführen.\nWir haben hier also einen neuen\nService erstellt, der die vorgenommenen\nCodeänderungen mit einer\nvorherigen Analyse zusammenführt, in der alle Typen\naufgelöst sind und der gesamte Kontext vorhanden ist, den die\nLS-Analyse benötigt.   Dadurch erhalten\nwir eine Art Hybrid, bei dem\nwir\n95 % der Probleme, die eine vollständige Analyse\naufdecken würde, in wenigen Sekunden erfassen.\nEs ist also so schnell wie ein Linter, aber so\ntiefgründig wie eine Sonaranalyse.  Es ist noch nicht ganz zu\n% fertig.  Wir arbeiten daran,\naber es ist schon fast soweit.\nCool.  Das ist also die innere Schleife.\nHoffentlich haben wir diesen\nZyklus durchlaufen, alle Probleme beseitigt\nund der Entwickler hat den Code überprüft.   Der\nEntwickler erstellt einen Pull Request.\nWas geschieht dann?\nSobald also ein Pull Request erstellt wird, wird ein\nBuild ausgelöst.  Es werden Tests durchgeführt.\nÄhm,\nund wir werden eine vollständige Analyse durchführen.  Und so\nwerden hoffentlich keine Probleme gefunden, aber\nes besteht die Möglichkeit, dass dennoch einige Probleme\nentdeckt werden.\nWenn Probleme festgestellt werden und diese\ninnerhalb der Schwelle der\nQualitätskontrolle liegen,\nwird der Administrator oder der Teamleiter eine Qualitätskontrolle festlegen.  Wie\nviele Probleme würden dadurch durchgelassen\n?  Um welche Arten von Problemen handelt es sich?\nWelche Schweregrade?  Das kann man gewissermaßen definieren\n.\nWenn der PR die Qualitätsprüfung nicht besteht,\nwird er blockiert.\nDer Code kann nicht zusammengeführt werden.  Hoffentlich befinden\nwir uns in einer Situation, in der es die\nQualitätsprüfung besteht.  Sie können zusammenführen.  Sie können die\nBereitstellung starten.  Die wirklichen Produktivitätssteigerungen erzielen wir\nhier.\nSollten Probleme mit dem PR auftreten,\nwerden diese deutlich.  Sie können durchklicken.  Sie\nkönnen die Problematik verstehen.  SonarQube\nerklärt die Problematik wirklich sehr gut\n.\nWir haben einen Sanierungsbeauftragten, der\ndie Probleme beheben wird.\nAlternativ können Sie es an\nden Agenten zurückgeben, und der Agent kann sich die\nPR ansehen.  Es kann die Probleme aufgreifen und\nbeheben.  Ihr\nCodegenerierungsagent kann diese Probleme also auch beheben.\nEs dauert also tatsächlich etwas länger.\nAnschließend müssen Sie den Pull Request aktualisieren.\nAber irgendwie funktioniert es immer noch.\nÄhm, dann gibt es noch eine Art KI-Code-\nReview.\nWir entwickeln momentan tatsächlich unser eigenes KI-\nCode-Review-Tool, um\ndies zu ergänzen.  Aber es gibt\nnatürlich noch andere Tools für Code-Reviews\n.\nDas wird dem menschlichen\nEntwickler in gewisser Weise helfen, ihm den nötigen Kontext liefern und\nihn hoffentlich nicht zu sehr beeinflussen.\nDann können wir die Überprüfung durchführen\nund die Pressemitteilung erstellen.   Zu\nden anderen Dingen, auf die ich hier noch\nnicht eingegangen bin, gehören beispielsweise\nregulatorische Berichte und ähnliches,\ndie wir häufig durchführen.\nUm Sonar kann das auch.  So kann man sich beispielsweise\ndie OWASP-Berichte ansehen\n.  Das könnten Sie in Erwägung ziehen.\nDies ist also die endgültige Überprüfung des PR.\nHier erhalten wir ein übersichtliches Dashboard, das anzeigt\n, was fehlgeschlagen ist und warum.  Und man kann da richtig tief\neinsteigen und sich\nKennzahlen ansehen.\nSie können auch die Testabdeckung einsehen.\nWir überlassen es Ihnen also,\ndie Testabdeckung mit Ihren eigenen\nTools zu berechnen, geben diese Daten aber an SonarQube weiter,\ndamit Sie einen umfassenden Bericht erhalten.\nUnd eine der\nwichtigsten Sachen ist, dass\nwir uns nur die Abdeckung des\nneuen Codes ansehen wollen, nicht den gesamten Code.\nViele unserer Nutzer verfügen daher\nmöglicherweise über eine schlecht abgedeckte Codebasis,\ndie sie nicht über Nacht reparieren können.  Vielleicht\nhaben sie derzeit eine Abdeckung von 30 %, aber sie wollen\nsie verbessern.  Deshalb wurde eine\nQualitätsprüfung eingeführt, die besagt, dass 80 % des gesamten neuen Codes\nabgedeckt sein müssen.  Und im Laufe der Zeit\nerweitern sie dann die Abdeckung ihrer\ngesamten Codebasis.   Es\nist also gut, das auch in\ndiesem Bericht zu sehen.  Da sind\nDuplikate drin, damit wir sehen können, wo es zu viel\nWortreichtum gibt.   Damit sind sowohl\nfunktionale als auch nicht-funktionale\nPrüfungen abgedeckt.\nUnd falls es dann Probleme gibt,\nkönnen die Agenten diese, wie bereits erwähnt, lösen\n.\nJa, wie gesagt, es ist etwas, was\nEntwickler nicht oft gerne tun, um unsere\nProbleme zu beheben, daher ist es\nfür uns ein echter Vorteil, einen Agenten zu haben, der das für uns übernimmt.  Wir lieben es.\nUnd schließlich die Vorbereitung auf die menschliche\nÜberprüfung, indem wir dies\ndurch unsere Führung verdeutlichen.\nFakt ist, dass der Mensch nach wie vor die\nVerantwortung trägt.  Und das ist etwas, was wir\nimmer wieder vergessen dürfen.\nWir sollten sie also auf keinen Fall\nin irgendeiner Weise in die Irre führen.   Das war's im Großen und Ganzen\n.  Hoffentlich hat\ndas die Frage beantwortet:\n„Sind die LLM-Absolventen bereit für die Unternehmenswelt?“\nUnd was können wir wahrscheinlich dagegen tun?   Das\nist der Teil, den ich sozusagen hinzugefügt habe.   Die\nmeisten dieser Tools sind jetzt als\nBetaversion oder als Teil unserer\nHauptproduktionslinie verfügbar.   Der\nGroßteil davon läuft auf SonarQube Cloud, unsere\nCloud-Version wird auch auf der\nServerversion verfügbar sein.  Viele Nutzer hier\nwerden also die Serverversion verwenden,\nsobald wir\nsichergestellt haben, dass sie funktioniert.\nSobald wir die Serverversion bereitstellen, bleibt sie\ndort für immer, deshalb gehen\nwir dabei immer etwas vorsichtig vor.   Ähm\n, ja, ich denke, der\nentscheidende Punkt ist, dass wir\nein kritisches Urteilsvermögen bewahren müssen.  Der\nEntwickler\nmuss in der Lage sein, objektiv zu erkennen, was vor sich geht\n.\nIch denke, wir stehen wahrscheinlich erst an der Spitze\ndes Eisbergs, was mit\ndem KI-SDL-Zustand passieren wird.\nAber hoffentlich hat Ihnen dies eine\nVorstellung davon gegeben, wohin die Reise gehen kann und wie wir uns sozusagen auf die\nvollständige agentenbasierte Entwicklung im\nUnternehmen vorbereiten können.",
  "transcript_chars": 39240,
  "ingested_at": "2026-05-22T04:31:16.982497+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": 84,
    "like_count": 2,
    "channel_id": "UCcIXc5mJsHVYTZR1maL5l9w",
    "categories": [
      "Education"
    ],
    "tags": []
  }
}