{
  "video_id": "TeGsFFNqRLA",
  "channel_slug": "aidotengineer",
  "channel_handle": "aidotengineer",
  "title": "1200 tok/s Fast Models Need Slow Developers — Sarah Chieng, Cerebras",
  "duration_seconds": 1082.0,
  "url": "https://www.youtube.com/watch?v=TeGsFFNqRLA",
  "upload_date": "",
  "transcript": "Hallo zusammen.  Dann legen wir gleich los\n.  So haben wir als Entwickler in den letzten Jahren aufgrund der\nlangsamen KI-Codegenerierung eine Reihe schlechter Angewohnheiten entwickelt.\nUnd so ist es uns allen vertraut.  Wir\nmachen Dinge wie riesige Story-Prompts schreiben und\nversuchen, sie in einem einzigen Durchgang zu schreiben.  Wir werden gewaltige Verpflichtungen eingehen\noder unsere 10 Agenten gleichzeitig auf dem\nBildschirm haben, die streiten,\ndiskutieren und nachdenken.  Und so haben\nwir bei Cerebrus und OpenAI vor etwa einem Monat\nein neues, hochmodernes\nModell namens Codex Spark veröffentlicht.  Codex Spark\nkann 1.200 Token pro\nSekunde generieren.  Um das in\nRelation zu setzen: Wenn man sich die Sonnet-\nFamilie oder die Opus-Familie ansieht, können diese\nCode mit einer Geschwindigkeit von etwa 40 bis 60 Tokens\npro Sekunde generieren.  In dieser neuen Ära, in der wir\nimmer schnellere Codierungsmodelle sehen,\nist dies 20-mal schneller.\nEs eröffnet nicht nur neue Möglichkeiten und\nAnwendungsfälle, sondern zwingt uns auch dazu,\nunsere Herangehensweise als Entwickler an\ndas Codierungsmodell zu überdenken.  Und viele\ndieser schlechten Angewohnheiten, die wir vorher hatten, führten dazu, dass wir\netwa 50 Token pro\nSekunde an fehlerhaftem Code erzeugten.  Wenn wir sie nicht reparieren, werden\nsie anfangen, 1.200\nTokens pro Sekunde fehlerhaften Codes zu erzeugen.  Und das\nist also das Thema des heutigen Vortrags.\nAlso, um gleich anzufangen: Mein Name ist Sarah\nChang.  Ich leite den Bereich\nEntwicklererfahrung bei Cerebrris, wo wir\nden weltweit größten und schnellsten\nKI-Prozessor entwickeln.\nEin großer Teil meiner Arbeit besteht darin, dass ich\nEntwicklern zum allerersten\nMal Modelle für schnelle Inferenz und schnelle Codierung vorstellen kann.  Und für die meisten Menschen ist das ein sehr\naufregender Moment.  Kein Nachdenken, kein\nWarten, kein Anlaufen – all das, worüber man sich\närgern könnte.  Aber gleichzeitig habe\nich gesagt: Solange wir unsere Gewohnheiten nicht ändern, werden\nwir auch in Zukunft keinen guten Code haben\n.  Dieser Vortrag ist also im Grunde ein\npraktischer Leitfaden dafür, wie wir als\nEntwickler\nin diesem neuen Umfeld mit den Modellen interagieren können,\ninsbesondere in einer Zukunft, in der die Modelle\nschneller Code generieren, als wir\nMenschen mithalten können.\nIch möchte also einen kurzen Blick in die Geschichte werfen\n.  Die\nletzten zwei Jahre waren sehr aufregend.  Die Modelle sind\ngrößer geworden, sie werden intelligenter, wir haben\ngrößere Kontextfenster, aber was\nin den letzten zwei Jahren relativ konstant geblieben ist, ist die Codierungsgeschwindigkeit bzw. die\nModellgeschwindigkeit.  Wenn wir uns also viele\nder beliebten Familiennamen ansehen, haben wir Gemini,\nClaude, GPT, Sonnet.  In den letzten zwei\nJahren lagen sie immer im Bereich von, Sie\nwissen schon, 50 bis 150 Token pro Sekunde.\nUnd das ist Codex Spark.  Auch hier gilt: Der Codec\nSpark ist nur das erste von vielen Modellen, von denen\nwir als Entwickler erwarten können, dass sie\nwesentlich schneller sind als das, was wir bisher gewohnt waren\n.  Und wir mussten sogar die\nY-Achse ändern, weil es so viel schneller geht.\nBevor wir also zu den eigentlichen\nStrategien und Tipps kommen, möchte ich darüber sprechen,\nwarum das passiert.  Warum\nsehen wir plötzlich so viel schnellere Modelle?  Und\ndas ist in der Tat eine sehr aufregende\nEntwicklung.  Es ist etwas, womit sich viele von Ihnen\nwahrscheinlich tagtäglich beschäftigen, aber\nes gibt so viele Unternehmen, die gleichzeitig\nan diesem Problem arbeiten\n.  Und als Folge davon wird der gesamte KI-\nInferenz-Stack auf\neinmal optimiert.  Um es kurz zu fassen: Gehen wir es\nganz schnell durch.  Wir haben die\nHardware.  Dies ist ein physisches Gerät, auf dem\nInferenz, Training und unsere gesamte Datenverarbeitung\nstattfinden.  Einer der wichtigsten\nAspekte, die wir bei\nHardware berücksichtigen müssen, ist die Speicherbegrenzung.  Und genau\ndeshalb beansprucht die Bewegung von Hardware und Speicher\n50 bis 80 % dieser Latenzzeit\nfür die Inferenz.  Hier liegt der Ursprung eines Großteils\nder Frustration.  Wenn\nwir also Inferenzprozesse durchführen, müssen wir\nunsere Gewichte und KV-Cache-\nWerte ständig zwischen dem Speicher und unserem eigentlichen\nChip verschieben.  Bei der NVIDIA-GPU handelt es sich um den\ntraditionellsten Hardwaretyp.  Der gesamte\nSpeicher ist extern auf einem\nexternen HBM-Chip gespeichert.  Und jetzt haben wir einen\nEngpass bei der Speicherbandbreite.  Was viele\nneuere Unternehmen tun, ist, sich mit\nFirmen wie Cerebrus oder Gro zu beschäftigen;\nsie überlegen, wie man\nden Speicher so nah wie möglich an den Chip bringen kann\n.  Hier ist also ein Beispiel für\neinen Cerebros-Wafer, bei dem der gesamte\nSpeicher\nüber den Chip in SRAM verteilt ist.  Jeder Kern\nhat somit direkten Zugriff auf die\nbenötigten Werte.  Noch spannender ist die\ndisaggregierte Inferenz, die\nin den letzten\nMonaten tatsächlich kommerzialisiert wurde.  Aus diesem Grund hat Nvidia Grock vor\neinigen Monaten für 20 Milliarden Dollar gekauft.  Und genau deshalb arbeiten\nCerebrus und AWS\njetzt zusammen, um den Wafer und das\nAWS Trainium gemeinsam zu bedienen.  Bei der traditionellen\nSchlussfolgerung gibt es also zwei Schritte.  Es gibt\nPrefill und es gibt Decodier.\nTraditionell wurden beide Schritte\nimmer auf demselben\nHardwaregerät ausgeführt.  Beim Prefill-Prozess werden\nalle vom Benutzer eingegebenen Token\nverarbeitet, eingebettet und\nunserem KV-Cache hinzugefügt.  Dies ist eine Sequenz,\nein Schritt, der\nparallel ausgeführt werden kann und daher rechenintensiv ist.   Beim\nDecode hingegen wird\ndas Ausgabetoken Token für\nToken erzeugt. Dieser Vorgang ist sequenziell und, wie bereits\nerwähnt, speichergebunden.  Es geht also wieder\num die gleichen Probleme, die wir\nbereits erwähnt haben.  Und so\nsehen wir es jetzt auch kommerziell: Wir\ntrennen diese beiden Schritte, sodass das\nVorbefüllen auf einem rechenoptimierten Hardwaretyp erfolgt\nund das Dekodieren\nauf einem anderen,\nspeicheroptimierten Hardwaretyp.  Weiter oben in der Hierarchie befindet sich\ndas Diagramm.  Im nächsten Schritt\nbetrachten wir die Modellarchitektur.  Es gibt\nso viele Möglichkeiten, wie wir unsere\nModelle trainieren und\nan unsere Hardware anpassen.  Wir haben spezifische\nSchichtabmessungen, Speicherbedarf und Modellgröße, über die\nwir ständig nachdenken.  Ein\ngutes Beispiel dafür ist eine typische\nModellarchitektur mit einer Mischung aus Experten.  Hier.\nAnstatt\nfür jedes einzelne Token das gesamte Modell auf einmal zu aktivieren,\naktivieren wir jeweils nur eine Teilmenge der\nExperten.  Dadurch erhalten\nwir die\nIntelligenz eines viel kleineren größeren\nModells zum Rechenaufwand eines viel\nkleineren Modells.  Und auch hier denken wir ständig\nüber den Speicherplatz und die Größe\nunserer Modelle nach.  Und viele Leute haben\nin den letzten\nJahren darauf aufgebaut.  Ein Beispiel ist das Reap Router\nWeighted Expert Activation Pruning.  Das\nmusste ich lesen.  Ähm, und hier\nschauen wir uns den konkreten Anwendungsfall an.  Wir\nprüfen, welche Experten überhaupt nicht\naktiviert werden, und entfernen\ndiese dann alle.  Wir schaffen sie ab\n.  Auch hier gilt: Wir denken immer an die\nGröße des Models.  Und ganz oben in\nder Hierarchie befinden sich die\nInferenzoptimierungen.  Und genau dort arbeiten viele von\nIhnen, und auch viele\nUnternehmen, die Ihnen wahrscheinlich bekannt sind,\nsind dort tätig.  Dies sind Unternehmen\nwie together, base 10, modal, who's\nalso here, fireworks.  Und einer der\nwichtigsten Punkte, über die wir\nauf dieser Ebene nachdenken, ist die Wiederverwendung des KV-Caches.\nIndem wir also zuvor\nberechnete Token-Repräsentationen speichern und wiederverwenden,\nmüssen wir die Aufmerksamkeit über die\nSequenz nicht bei jedem Schritt neu berechnen.\nUnd nun möchte ich zum allerbesten\nund spannendsten Teil kommen: dem Entwickler.\nSo\nsieht das Internet derzeit aus, oder so sieht Twitter\nLinkedIn aus.  Wir haben jemanden, der\nsechs Cloud-Code-Terminals\ngleichzeitig bedient.  Ein Schwarm von über 500 Agenten, die programmieren.  Ähm,\njemand, der acht Agenten auf fünf\nBildschirmen steuert.  Und ich verstehe, wie verlockend es sein kann, so\netwas zu tun.  Ich habe das Gefühl, wenn\nman heutzutage überhaupt auf Twitter unterwegs ist,\naußer man macht so etwas wie\ndas hier, vermittelt einem das Internet im Grunde das Gefühl,\ndass man in\nder Steinzeit lebt und dass man\naufholen muss.  Aber die Realität, die\nin all diesen Setups tatsächlich auftritt,\nist, dass wir riesige Mengen\nan Code generieren, den niemand überprüft.\nUnd in einer neuen Zukunft mit viel schnelleren\nSchlussfolgerungen wird dies zunehmend\ngefährlich.\nUnd so werden wir, insbesondere bei schnellen Inferenzprozessen,\nnun\ntechnische Schulden in einem noch nie dagewesenen Ausmaß anhäufen\n.  Und wir werden nicht\nwissen, was wir damit anfangen sollen.  Deshalb werde ich\nnun den Rest\ndes Vortrags den praktischen Vorgehensweisen,\nTipps und Arbeitsabläufen widmen und der Frage,\nwie wir als Entwickler\nin diesem neuen Umfeld schnellerer\nInferenz neu denken können.  Wie ich bereits erwähnte,\narbeitet Codex Spark mit 1.200 Token pro\nSekunde, aber das ist wirklich nur das erste\nModell, und wir als Entwickler sollten\nerwarten und uns darauf einstellen, dass ein neues\nRegime von durchweg schnelleren Modellen auf den\nMarkt kommen wird.  Und so beginnen wir mit der\nersten Kategorie, die sich mit der Auswahl\nder richtigen Modelle und der Frage beschäftigt, wie wir\nunsere Agenten so einsetzen, dass wir die\nStärken verschiedener Modelle optimal nutzen.  Ich\nglaube, historisch gesehen denken wir immer an\nIntelligenz.  Es ist kein Geheimnis,\ndass wir als Entwickler nicht\nbesonders loyal sind und\nzu dem Modell wechseln, das gerade am\nintelligentesten erscheint. Dabei spielen\nauch die Kosten eine Rolle, es sei denn,\nunser Unternehmen übernimmt die Kosten für alles, was wir wollen.\nDie Inferenzgeschwindigkeit ist\njetzt 20-mal höher, und wir müssen auch die\nGeschwindigkeit berücksichtigen. Ein\ngutes mentales Modell ist es, für die Planung oder langfristige Workflows ein größeres\nModell wie GBT 5.4 anstelle von 5.3 zu verwenden\nund dann ein schnelleres Modell wie Codex\nSpark als eigentlichen Executor einzusetzen.\nHier ist ein Beispiel.  Sie könnten\nIhren 5 GBT 5.4 bitten, Ihren Plan zu generieren.\nSie würden einen äh, Sie würden\nalle Ihre Subagenten mit Codecs Spark erzeugen\nund ihn tatsächlich ausführen lassen, äh, ihn\ntatsächlich alle diese Schritte\näh nacheinander ausführen lassen.  Ein weiterer sehr hilfreicher\nTrick besteht darin, aus erfolgreichen Sitzungen tatsächlich Fertigkeiten zu entwickeln\nund\nEntwicklungspfade festzuhalten, die wirklich\ngut funktionieren.  Eine Möglichkeit wäre,\nein Modell wie GPT 5.4 zu verwenden, um\ndie anfänglich schwierigere, größere\nAufgabe zu erledigen, dies als Fähigkeit zu erfassen und\ndadurch einen überprüfbaren,\nwiederholbaren Arbeitsablauf zu schaffen, und dann einen\nkleinen, schnelleren Agenten wie Codec Spark zu verwenden, der dies immer wieder\nim\nHintergrund ausführt.\nDie nächste Kategorie finde ich sogar noch\nspannender, denn hier geht es um\nDinge, die einfach nicht möglich und\nnicht praktikabel waren.  Das sind Dinge, die wir\nnicht tun würden, weil wir des ständigen Grübelns, Rechtfertigens und\nKeimens müde sind, das Sie vielleicht schon beobachtet haben.\nUnd deshalb möchte ich, dass wir darüber nachdenken\nund das verinnerlichen.  Bei\n1200 Tokens pro Sekunde ist die Validierung mit einem Modell wie\nCodec Spark praktisch\nkostenlos.  Es gibt keine Entschuldigung und keinen Grund,\nwarum man solche Dinge nicht tun sollte\n.  Testsuiten, Linting, Pre-Commit-\nHooks, Diff-Reviews, browserbasierte QA-\nAutomatisierungen.  Es gibt all diese Dinge,\ndie Sie in jeden Schritt Ihres Arbeitsablaufs einbauen können,\nweil es sofort funktioniert.  Es\nbremst dich nicht aus und du musst das\nalles auch nicht erst ganz am Ende oder kurz\nbevor du deinen\nCode hochlädst, erledigen.   Ein\nweiterer Tipp, den ich sehr mag, ist das\nAusprobieren von Rosinenpickerei.   Nehmen wir an,\nich möchte eine\nNavigationsleiste programmieren und diese soll nachtblau sein\n.  Ich möchte vier verschiedene Symbole.  Ich gebe\nes dem Modell und das Ergebnis ist\ngut.  Was ich stattdessen mit Codeex\nSpark oder einem viel schnelleren Modell machen kann, ist Folgendes: Ich kann es\nanweisen, 15 Versionen in der gleichen Zeit zu generieren, die ein\nvorheriges Modell für die Generierung einer\nVersion benötigt hätte, und ich kann mir die Version aussuchen,\ndie mir am besten gefällt.  Noch besser: Ich kann\nfünf Unterknoten generieren, die jeweils\n15 Versionen erzeugen, sodass ich nun 75\nVersionen habe und die beste auswählen kann.\nUnd das ist ideal für Dinge, bei denen wir\nWert auf Quantität oder Vielfalt legen.  Also\nDinge wie Forschungsrichtung,\nverschiedene Arten von\nArchitekturrichtungen oder auch einfach nur Grafikdesign.\nUnd der Grund, warum mir dieses\nModell so gut gefällt, ist, dass es uns quasi erlaubt,\nkünstlich Geschmack in unsere Modellausgabe einzubringen\n.  Es ist also kein Geheimnis, dass\nes traditionell sehr einfach ist, jegliche Benutzeroberfläche oder\nTexte, die ein Model schreibt, aufzuspüren.  Die Models\nselbst haben keinen Geschmack.  Und die\nArt und Weise, wie wir\ndieses Problem mit etwas Mühe umgangen haben, besteht darin, dass wir entweder\nselbst ein Beispiel erstellen oder\nBeispiele für das Modell finden, was\nzeitaufwändig ist, oder wir geben der Aufgabenstellung so\nviele Details, dass wir\ndie Aufgabe genauso gut selbst hätten erledigen können.  Das ist eine\ngroßartige Möglichkeit, Zeit zu sparen und gleichzeitig\ndeutlich bessere Ergebnisse zu erzielen.\nDer nächste Tipp ist eher ein\nmentales Modell: Da die Modelle heutzutage\nso schnell sind, sollte es nicht so sein, dass man\neine Sitzung startet, sich einen Hamburger holt, auf\nTwitter scrollt\nund dann zurückkommt.  Jetzt können Sie sich\ntatsächlich hinsetzen und\nmit diesem Modell ist eine Echtzeit-Zusammenarbeit möglich.  Sie sollten es viel\nmehr aus der Perspektive eines reinen Programmierers betrachten.  Und\nnur so können Sie\nschlechten Code vermeiden.  Sie können sich also hinsetzen und\nFragen stellen wie: Wie kann es\nden gesamten Kontext in Ihrem Repository erfassen? Und\nwie funktioniert es, wenn man selbst am\nSteuer sitzt und\nEntscheidungen und Implementierungen trifft?  Die KI\nsollte Ihnen immer bei\nEntscheidungen helfen, nicht umgekehrt.\nDie nächste Folie – ich hasse diese Folie, weil\nes jedermanns Triggerwort und ein\nüberstrapaziertes Wort ist – aber wie vermeiden wir\nSchlampigkeit?\nWie ich bereits erwähnt habe, sollte es\neigentlich nicht so sein, dass man beispielsweise\n10 Agenten erzeugt und den Code nie überprüft.\nMan weiß nicht, was unter\nder Oberfläche vor sich geht.  Wenn dich jemand um eine Erklärung bittet,\nmusst du den Code zum ersten\nMal lesen.  Jetzt können Sie tatsächlich zwei bis\ndrei Sitzungen einlegen und sich ganz entspannt\nneben Ihren Code setzen.  Und ich weiß, dass\nwir das nicht wirklich gewohnt sind, aber\nsetzen Sie sich damit auseinander und versuchen Sie, es zu steuern, zu\nverstehen, was passiert, denn\nwir erleben jetzt eine Echtzeit-\nZusammenarbeit, während wir mit diesem\nAgenten programmieren.  Sie können sehr detailliert sein.  Man\nkann Dinge tun wie dem Modell das\nLöschen von Dateien verbieten, ihm eine maximale Differenzgröße geben\n, das Modell nur\nlesend und schreibend machen und ihm sogar\nSteuerungsanweisungen geben, Dinge wie: Nur\ndies ändern, Typen noch nicht anfassen.\nMoment mal, diese Umsetzung war nicht ganz\nkorrekt.  Lasst uns das wiederholen.  Das Diagramm\nlinks ist ein hilfreiches mentales Modell, das\nbeispielhaft zeigt, wie der Entwickler, der KI-\nAgent und die Codebasis zusammenarbeiten können\nund wie das aussehen sollte.\nDieser nächste Schritt, das Refactoring, ist dem, worüber\nich im Zusammenhang mit der\nValidierung und Verifizierung gesprochen habe, sehr ähnlich.  Ähnlich wie bei der\nVerifizierung ist etwas wie das ständige\nautomatische Refactoring und Bereinigen Ihres Codes mit 1.200\nToken pro Sekunde praktisch kostenlos.  So können Sie Dinge erledigen,\nanstatt sie erst ganz am Ende\nkurz vor dem Einchecken Ihres\nCodes zu tun.  Sie können\ndies einfach in Ihren automatischen Arbeitsablauf einbauen, sodass Sie,\nnachdem jede einzelne Aufgabe auf dieser\nCheckliste erledigt ist,\ndas Modell einfach anweisen, automatisch\nungenutzte Importe zu löschen,\nunnötige Codezeilen zu bereinigen und dafür zu sorgen,\ndass alle meine Funktionen auf die\ngleiche Weise strukturiert sind.\nDie letzte Kategorie, über die ich sprechen möchte\n, und ich bin mir sicher, dass viele von Ihnen\ndiese beiden Wörter in\nden letzten\nTagen und in unzähligen Gesprächen schon unzählige Male gehört haben, ist\nKontextmanagement.  Aber der Grund, warum ich noch einmal\nmit Ihnen darüber sprechen werde, ist folgender:\nAngenommen,\nSie brauchten in der Vergangenheit 10 Minuten, um Ihren\nKontext zu füllen, bevor Sie, Sie wissen schon, das\ngottgefürchtete Wort Komprimierung sahen.\nWenn man nun 10 Minuten nimmt und diese\ndurch 20 teilt, erhält man eine Verdichtung in\n30 Sekunden.  Daher ist Kontextmanagement,\ninsbesondere bei schnellen Schlussfolgerungen,\nwichtiger denn je.  Und\nmit schlampigen Praktiken kommt man heutzutage nicht mehr durch\n.  Daher handelt es sich bei all diesen Dingen im Grunde um bewährte\nVorgehensweisen, unabhängig davon,\nwelches Codierungsmodell oder welche\nGeschwindigkeiten verwendet werden.  Ein allgemeines, sehr übergeordnetes\nRahmenkonzept besteht darin,\ngroße Aufgaben immer in kleinere, abgegrenzte Ziele zu unterteilen.\nUnd diese Grafik auf der rechten Seite ist ein gutes\nmentales Modell dafür, wie sich der Grad der Vollständigkeit Ihres\nKontextes auf Ihr\nVerhalten, das Modellverhalten, auswirkt.  Man sollte also\nunbedingt einen Wert zwischen 80 und 100 % vermeiden,\nda es sonst zu Verdichtung kommt.\nUnd wir alle wissen, dass dabei einiges\nverloren gehen kann.  Eine gute Möglichkeit, darüber\nnachzudenken, wie man\ndiese Erinnerung externalisieren kann, um\nkleine, abgegrenzte Ziele zu setzen, ist folgende: Wie sieht das konkret aus\n?  Ein Beispiel dafür, wie Sie\ndies tun und ein externes Speichersystem einrichten können,\ndas bei jeder\nEinrichtung einer neuen Sitzung persistent ist, ist dieses Vier-\nDateisystem.  Wir haben Agenten MD,\nwo wir alle unsere\nAgenten und Unteragenten definieren.  Wir haben Plan MD,\nden wir ganz am Anfang erstellen. Hier\ngenerieren wir den gesamten Plan und eine Schritt-für-\nSchritt-Checkliste, die wir durchgehen werden\n.  Wir haben Progress MD,\nwo wir festhalten,\nwas wir noch tun müssen und was\nbereits erledigt wurde.  Jedes Mal, wenn Sie\neinen neuen Agenten oder eine neue Sitzung starten, gibt es also keinen\nKontext.  Es kommt daher, dass es sich um einen\nFortschrittsbericht für Ärzte handelt.  Es sieht, was\nbereits gemacht wurde, und sagt sich: Okay, hier mache ich weiter\n.  Hier muss die nächste Aufgabe\nerledigt werden.  Und zum Schluss wird noch die\nMD-Verifizierung durchgeführt.  Und genau das verwenden wir\nbei jedem einzelnen Schritt, um sicherzustellen, dass\nalles gut aussieht.  Es handelt sich um sauberen Code,\nund wir können mit dem nächsten Schritt fortfahren.\nEin Beispiel hierfür ist die\nNutzung verschiedener Modelle mithilfe eines GPT\n5.3 oder 5.4 Codex, der Ihren\nPlan erstellt, und anschließend die Ausführung der Checkliste durch Ihren GPT 5.3 Codec\nSpark, und zwar\nviel schneller als zuvor.  Und als\nletzte Folie möchte ich Ihnen noch ein paar\nhilfreiche Befehle zeigen, mit denen Sie das\nBeste aus den Codecs herausholen können.  Dinge wie\nBerechtigungen, experimentelle Fähigkeiten, Überprüfung\nund Umbenennung.  Aber das Wichtigste, was ich\nhier wirklich betonen möchte, ist, dass\nes ehrlich gesagt nicht wirklich darum geht, nur\nschnellere Codierungsmodelle zu haben.  Das\nbedeutet in Wirklichkeit, dass die Entwicklererfahrung dadurch deutlich\nbesser wird.  Und wenn es\nso viel besser wird, können wir auch so viel mehr\ntun.  Und es gibt so viele Möglichkeiten, wie wir\njetzt vermeiden können, schlechten Code zu schreiben, ohne dass es uns zur\nQual macht oder wir\n30 Minuten lang auf einen Bildschirm starren müssen.  Vielen\nDank euch allen für den herzlichen Empfang heute\n.  Mein Name ist Sarah Chang.\nÄhm, ich bin aus San Francisco zu Besuch.  Es ist mir eine Ehre,\nhier in London zu sein.  Ähm, falls ihr\nFragen habt oder Guthaben benötigt, mein\nBenutzername ist milks and matcha auf allen\nPlattformen.  Danke euch!",
  "transcript_chars": 20430,
  "ingested_at": "2026-05-22T22:30:14.286987+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": 1396,
    "like_count": 48,
    "channel_id": "UCLKPca3kwwd-B59HNr-_lvA",
    "categories": [
      "Science & Technology"
    ],
    "tags": [
      "ai",
      "ai engineer",
      "ai engineering",
      "software development",
      "tech",
      "startups",
      "software architecture",
      "machine learning"
    ]
  }
}