{
  "video_id": "yUmS-F9IX90",
  "channel_slug": "aidotengineer",
  "channel_handle": "aidotengineer",
  "title": "Don't Build Slop (4 Levels of AI Agent Maturity) - Ara Khan, Cline",
  "duration_seconds": 1132.0,
  "url": "https://www.youtube.com/watch?v=yUmS-F9IX90",
  "upload_date": "",
  "transcript": "In Ordnung.  Hallo.  Ähm,\nsehr schön, euch alle zu sehen.   Ähm, es\nist so interessant zu\nsehen, dass ihr nach so einem langen Tag trotzdem noch gekommen seid,\nund äh, ich fühle mich immer\nsehr geschmeichelt, wenn ich\nversuche, etwas zu präsentieren, und dann\nsind Leute da.  Es ist einfach so, äh,\nwenn es dir das Gefühl gibt, dass das, was\ndu tust, von Bedeutung ist.  Heute\nmöchte ich über das Thema sprechen, wie man so schön sagt: „\nBaut keinen Schrott“, und zwar über die vier Reifegrade von KI-Agenten\n.  Und was ich hier eigentlich tun möchte,\nist, über\netwas zu sprechen, das mir viele Leute geschildert haben, nämlich\nein\nProblem mit Massenpsychosen.  Im Grunde\nist es so, als ob jeder das\nGefühl hätte, dass da so eine Art\nriesige Ansammlung von Robotern um einen herum ist, die\neinfach so durchs Leben\nfliegen und unzählige Dinge erledigen,\nund man selbst ist mittendrin und total\nverwirrt.  Du bist völlig verwirrt und fragst dich:\nWas ist es? Was soll ich\ntun?  Soll ich etwa 15 Agenten haben, die ständig im Hintergrund arbeiten, während\nich\neinfach nur da wohne, oder soll ich mich wie\nein Bauer verhalten und\njede einzelne Codezeile durchlesen?  Und es ist\nsehr schwer, sich zu entscheiden\n.  Ich habe das Gefühl, wenn man an einen solchen Ort kommt, ist man\nimmer so formell, dass es einem einfach zu viel wird\n.  Man bekommt\nso eine Art Panikattacke oder so.  Aber\nich glaube, ich möchte mich da etwas zurückziehen\nund sagen:\n„Leute, lasst uns mal einen Gang runterschalten.\nLasst uns einfach mal durchdenken,\nwelche Probleme\nwir tatsächlich lösen können, und ich werde\neuch dabei helfen,\nwirklich nützliche Agenten zu entwickeln. Ich möchte das gesamte\nSpektrum abdecken, von eurem Bedürfnis, Dinge schnell zu entwickeln, bis hin zu eurem\nBedürfnis, ab einem gewissen\nPunkt langsam zu entwickeln und sie\nin Produktion zu bringen. Das ist im Grunde\ndas Ziel. Um euch ein Beispiel für\nMassenpsychose zu geben: Es gibt viele\nDinge, die sich sehr ähneln. Ich gebe\neuch ein Beispiel mit\ndrei Benutzeroberflächen.\nUnd das sind drei Frontier Labs, und ich\ngarantiere euch, keiner von euch kann erraten,\nwelche welche ist.\nEine davon ist Factory, eine\nist Codex und eine ist Cursor.\nIch bin mir sicher, keiner von euch weiß, welche welche\nist. Nicht einmal ich weiß es.“\nJa, genau darum geht es im Grunde\n. Alles ist\ngleich. Du willst dein eigenes Ding machen. Um\nspeziell Agenten zu entwickeln, würde\nich Folgendes vorstellen:\nIch möchte\ndas Problem der\nAgentenentwicklung in vier verschiedene Teile unterteilen.\nIm ersten Teil geht es darum,\nherauszufinden, ob\ndas überhaupt Sinn macht und\nfunktioniert. Hier verwendet man ein\nFramework. Im zweiten Teil meint man es\nernst und denkt: „Okay, ich\nwill hier wirklich etwas umsetzen.“ Jetzt\nentwickelt man die Dinge selbst, zum Beispiel als\nZustandsautomat oder als\ntatsächlichen Agenten. Der dritte Teil ist der\nUX-Workflow, bei dem man Kanban verwendet.\nIch schlage vor, dass dies ein hervorragendes Format\nfür die Arbeit mit Agenten ist. Und der\nvierte Teil wäre die Bereitstellung in der\nCloud. Dies ist also im Wesentlichen unser\nÜberblick darüber, wie wir\nmit Agenten arbeiten wollen. Ich denke,\nes wird Ihnen eine gute Faustregel liefern, wie\nSie das Problem lösen können.  Das\nProblem ist, dass man beim Erstellen von\nAgenten zunächst einfach\nein Framework verwendet. Es gibt da\nverschiedene\nFrameworks wie LangChain und LangGraph.\nIch selbst nutze sie aber nicht, da ich\nbei einem Kunden arbeite und die\ngesamte Benutzererfahrung selbst entwickeln muss\n. Warum sollte ich also ein\nFramework verwenden? Ich bin daher nicht der beste\nAnsprechpartner für Ratschläge, aber\nwenn Sie nach einem geeigneten Framework suchen und ein Problem haben, wie zum Beispiel: „\nIch möchte E-\nMails aggregieren oder ähnliches – also etwas Einfaches –\ntun“, dann könnte ein\nKI-Agent\nhilfreich sein.\nDas beste Modell ist mir wahrscheinlich egal.  Ich\nwill einfach nur etwas, das funktioniert.“ Jedes\nAgenten-Framework kann einem\nin etwa einer halben\nStunde etwas zum Laufen bringen. Man kann einfach Code schreiben. Es\nist ein toller\nEinstieg. Es ist großartig zu sehen, dass\nAgenten tatsächlich funktionieren und dass man\nsie selbst entwickeln kann. Die\nVerwendung von Frameworks birgt jedoch viele Fallstricke. Und\neiner der größten ist meiner Meinung nach, dass man, wenn man\nwirklich etwas\nProduktiv einsetzen und\netwas Ernsthaftes entwickeln will,\nsehr schnell feststellt, dass man den\nnötigen Grad an Anpassbarkeit, Zukunftsfähigkeit und Modularität\nin einem Framework einfach nicht findet. Ich kenne\nviele Leute, die mir widersprechen, und\nviele von ihnen liegen falsch. Nun gut,\nStufe zwei ist also,\neigene Agenten zu entwickeln, richtig?\nHier ist, wie man das macht.\nIch habe das Gefühl, dass dies\nein sehr komplexes Problem ist, das ich\nnicht zusammenfassen kann. Also, ich gebe\nIhnen einfach…  Fünf Regeln für das\nProgrammieren von\nAgenten: Es gibt fünf\nRegeln, die Sie anwenden können.\nDiese Regeln geben Ihnen einen groben\nÜberblick darüber, wie Sie\nIhren eigenen Agenten programmieren.\nDie erste Regel lautet: Betrachten Sie\njeden Agenten als Zustandsautomaten.\nZustandsautomaten sind ein\nThema für Anfänger, aber im Grunde ist\njeder Agent letztendlich eine\nrekursive Schleife. Das ist im Prinzip wie\njeder Hype-Zyklus,\negal was Sie denken, am Ende immer\ndie rekursive While-Schleife.\nEs ist eine While-Schleife mit einigen Bedingungen.\nUnd egal, was Ihr Agent gerade tut,\negal ob er einen\nCursor oder eine Uhr steuert, es ist immer eine While-\nSchleife mit einigen Bedingungen und einigen\nEndzuständen. Sie sollten in der Lage sein,\njederzeit\nein mentales\nModell davon zu haben, in welchem ​​Zustand sich der Agent befindet. Nehmen\nwir an, Sie möchten  Stellen Sie sich vor,\nSie möchten\neinige Dateien lesen und\nderen Bedeutung mithilfe von Clock-Code erklären. Der Prozess\nbeginnt mit der Benutzeraufgabe ganz oben, in der\nSie den Agenten anweisen, einige Dateien zu lesen.\nEr durchläuft den Zustand „\nDateien werden gelesen“ und verwendet das Aktionstool, um\ndie Datei zu lesen. Anschließend erkennt er: „\nDie Datei wurde gelesen, das ergibt Sinn.“\nDaraufhin ruft er das Abschlusstool auf, das den Vorgang abschließt. Die\nletzte Aufgabe, „Abgeschlossen“, beendet den Vorgang.\nSie können dies sehr komplex gestalten und\nden\ngesamten Zustandsautomaten 8 bis 10\nMinuten oder sogar Stunden lang analysieren. Im\nGrunde ist aber jeder Agent ein\nZustandsautomat. Wenn Sie sich das\nals mentales Modell vorstellen, wird\nIhnen das Erstellen eines Agenten viel leichter fallen\n. Die zweite Regel lautet: Jede\nErweiterung eines Agenten birgt das Risiko,\nihn zu verschlechtern. Ich denke, das ist die\nwichtigste Erkenntnis, die wir gewonnen haben.  Es\nwar eine bittere Lektion für\nviele Agentenentwickler:\nUmfangreiche Systemabfragen, viele\nverschiedene Sonderfälle und komplexe\nWenn-Dann-Logik verschlechtern die Leistung von modernen Algorithmen\n. Die wichtigste\nErkenntnis ist, dass man dem Modell einfach freie Hand lassen sollte. Moderne\nAlgorithmen sind so gut,\ndass\nsie umso besser funktionieren, je weniger Anweisungen man ihnen gibt. Ein\nklassisches Beispiel: Im\nCodex-Repository ist die Abfrage für GPT-5 nur\nein Drittel so groß wie die für GPT-5.3. Das liegt unter anderem daran,\ndass\ndie neueren Modelle so effizient sind,\ndass zu viele\nAnweisungen und längere Systemabfragen\nzu einer Reizüberflutung führen. Sie werden von der Informationsflut\nüberfordert und können nicht mehr\nrichtig reagieren. Daher ist\nEinfachheit immer besser. Ich denke, bei\njeder Änderung, die ich\nhinzufüge, sollte ich sehr vorsichtig sein.  Gott sei\nDank, ich mache es nicht noch schlimmer\nund versuche es immer weiter zu reduzieren. Wir sind sogar\nso weit gegangen, dass wir\nden gesamten Client neu geschrieben haben, weil\nwir festgestellt haben, dass da so viel Schrott\naus den älteren Client-Versionen drin war. Der\nClient-Code wurde, glaube ich,\nmindestens sieben Mal von Grund auf neu geschrieben\n. Aber die\nLeute im Team wissen es vielleicht besser.\nDie dritte Regel ist, dass der\nAgent ein einfacher Bestandteil einer\nPseudo-RL-Pipeline sein sollte. Das ist etwas knifflig\n, aber im Grunde bedeutet es,\ndass man beim Erstellen eines Agenten immer eine Art Befehlszeilenschnittstelle (\nCLI) haben sollte.\nDer Grund dafür ist, dass man, solange man\netwas hat, mit dem man\nden Agenten gut erstellen und testen kann, in Form\neiner CLI auch\nDinge erstellen sollte,\ndie sich sehr einfach\nmit\nanderen Coding-Agenten erstellen und testen lassen. Im Moment gibt es\ndiese Art interaktiven Tanz\nzwischen KI und Menschen, wo früher\nMenschen die\nKI quasi angeleitet haben.  Ich\ndenke, wir befinden uns an einem Punkt, an dem\nMenschen von KI geleitet werden. Ein wichtiger Aspekt dabei ist, dass man\nals Mensch Dinge so entwickeln möchte, dass\ndie KI problemlos damit arbeiten kann\n. Das kann bedeuten, beispielsweise\neine Datei wie agents.md zu schreiben und dabei\ndie entsprechenden Fähigkeiten einzusetzen. Der\nAufbau einer CI/CD-Pipeline, sodass\nandere Entwickler den\nAgenten einfach erstellen, testen,\nÄnderungen daran vornehmen und ihn dann von Anfang bis\nEnde testen können, ist entscheidend. So kann man\nÄnderungen vornehmen, indem man\neinen Agenten\nin einem parallelen Thread laufen lässt. Dieser führt\nalle Änderungen durch, testet sie, und\ndas gesamte System läuft. Wenn das\nErstellen und Testen jedoch schwieriger ist, wird es auch\nschwieriger, Agenten für die Entwicklung des\neigenen Agenten zu nutzen.\nSehr meta. Ähm,\nRegel Nummer vier: Seid nicht schlampig. Leute, bitte,\num Himmels willen, baut keinen schlampigen Code!\nIch denke, es gibt einen enormen\nDurchsatz, den man erreichen kann, und eine enorme Menge an\nToken, die extrem\nschnell verarbeitet werden können.\nDie wichtigste Lektion, die wir\nals erfahrene Entwickler gelernt haben, ist, dass es sich\nwirklich lohnt,\nZeit in die\nArchitektur, das\nDesign und die Funktionsweise des\nAgenten zu investieren, um sicherzustellen, dass alles Sinn ergibt.\nUnd man sollte sich\nzumindest die Zeit nehmen,\nden Code zu lesen, selbst wenn man nicht\nalles selbst schreibt. Das ist\nfür uns extrem wichtig, denn\ndie Architektur eines\nAgenten muss von einem\nMenschen sorgfältig und durchdacht entworfen werden\n. Selbst wenn man\neinen Agenten nur für die Kommunikation nutzt, sollte man sich\nviel Zeit nehmen, um\ndie Architektur und\nden Zustandsautomaten zu durchdenken. Man sollte nicht einfach\nandere Modelle\nden Code übernehmen lassen.\nUnd die Regel 50 von Frontier Labs besagt, dass…  Sie\nschränken die Benutzer ein. Und das\nist ein kniffliges Thema. Viele werden anderer Meinung sein\n, aber im Grunde genommen ist es so, dass\ndie APIs von Frontier Labs oft versuchen, die Benutzer einzuschränken und\ndie Austauschbarkeit zu erschweren\n. Um ein konkretes\nBeispiel zu nennen: Die neuen Modelle, beispielsweise\nOpus 4.6, Gemini 1.5, 1\nPro und 5.3, verwenden sogenannte\nReasoning Traces. Diese sind\nTeil des Caches und gleichzeitig Bestandteil der\nBerechnungsschleife des Modells.\nBei der Kommunikation\nmit diesen\nModellen müssen die Reasoning\nTraces im exakt\nerwarteten Format gesendet werden. Andernfalls funktioniert die Antwort zwar\nweiterhin, die\nLeistung ist jedoch deutlich schlechter, und man merkt es\nnicht.\nViele übersehen dadurch\ndie enormen Leistungssteigerungen\nder neuen Modelle.  Weil\nsie die APIs einfach nicht genau so nutzen, wie\nsie gedacht sind\n.\nAußerdem gibt es Asymmetrien in der API. Manche würden\nargumentieren: „Hey, vielleicht könntest du\nOpenRouter verwenden.“ Aber ich glaube nicht, dass das\nausreicht. Man muss wirklich\nvorsichtig sein, wenn man\nverschiedene Frontier Labs und verschiedene\nFrontier Labs APIs verwendet. Die Entwickler haben\nsehr sorgfältig geprüft, ob\ndie API korrekt funktioniert, und man hat sie auch getestet.\nDer nächste\nSchritt ist die\nVisualisierung der\nAgenten. Ich hatte ja bereits auf\neiner der\nvorherigen Folien gezeigt, dass\nCodex,\nCursor und andere alle gleich\naussehen. Aber ich habe eine\nandere These.\nAm 26. März habe ich getwittert, dass\nwir\nKanban verwenden sollten. Kanban-Boards, ich denke  Wenn\njemand Linear oder ähnliches verwendet hat, sind\nIhnen Kanban-\nBoards sicher bekannt. Ich bin also der Meinung, dass Kanban-\nBoards die beste Wahl sind.\nHans aus dem Publikum war so freundlich,\nmir seine Gedanken dazu mitzuteilen. Vielen\nDank dafür! Kanban-Boards basieren auf der\nIdee, dass man, wenn\nman mit einem Agenten arbeitet,\nimmer an die zugrunde liegenden Informationen gebunden ist. Viele von Ihnen\narbeiten mit Tools wie Kodak oder Alpha, die jeweils\n8 bis 10 Minuten laufen\n.\nWas tun Sie, wenn einer der Agenten 8 bis 10 Minuten lang arbeitet?\nSie könnten endlos scrollen, aber das geht nur bis zu einer bestimmten\nLänge. Also starten Sie einen\nweiteren Agenten. So\nhaben Sie immer mindestens zwei oder drei Agenten\nparallel laufen, da\nSie an die zugrunde liegenden Informationen gebunden sind. Und alle\nverändern potenziell dieselbe Datenquelle\n. Daher ist es wichtig, die veränderten Daten zu isolieren, um die\nIsolation des Zustands zu gewährleisten.\nDie beste UX-\nForm für mich ist das Kanban-Board,\nweil es einem quasi die Rolle eines\nEngineering\nManagers ermöglicht, der alle\nAgenten im Blick hat.\nMan erhält einen\nÜberblick über ihre Aufgaben und kann\nWorkflows erstellen, z. B.: „\nWenn diese beiden Aufgaben zuerst erledigt sind,\nerledige ich die nächste.“ Dadurch\nwird man quasi zum Engineering\nManager, und alle Agenten sind die ICs, die man über das Board\neinsehen kann.\nIch habe das am 26. März behauptet,\nund vor 10 Stunden hat Clock Code dasselbe veröffentlicht\n. Ich glaube also, ich\nhatte Recht.\nJa, man kann das über den Clock\nCode Client oder einen anderen Client nutzen, je nachdem, was am besten passt\n.\nKanban ist also im Grunde wie ein Engineering\nManager. Im\nletzten Schritt hat man\neinen Agenten, die Aufgabe wurde getestet und erstellt.\nSie haben eine\ngute UX-Oberfläche, die eine intuitive\nBedienung ermöglicht.\nWas tun Sie dann? Wie entwickeln Sie\neinen Agenten, der nicht nur\nnützlich und zuverlässig ist,\nsondern auch skalierbar? Er sollte für\nMillionen von Aufgaben und\nNutzern geeignet sein. Wenn Sie für ein Unternehmen mit beispielsweise\n8.000 Mitarbeitern arbeiten, wie stellen\nSie sicher, dass alle\nproblemlos damit arbeiten können\n? Anstatt die\nInstallation\nkomplexer\nWorkflows auf den Rechnern zu erzwingen – was unnötig kompliziert ist –, sollten Sie all das\nin die Cloud verlagern.\nCloud-Agenten bieten viele Vorteile,\nder wichtigste ist jedoch die vollständige Isolation. Sie können\nfür jeden Agenten eine separate Maschine verwenden. Es\ngibt keine lokalen Abhängigkeiten,\nda der Agent in der Cloud die\nUmgebung selbstständig einrichten und alle notwendigen Schritte durchführen kann.  UX-Aufgaben sind wichtig,\ndenn aktuell fehlt ein entscheidendes\nPuzzleteil, das viele\nnicht nutzen, obwohl ich es selbst\nintensiv verwende: Cloud-Agenten.\nDiese können nämlich sehr lange laufen. Ich habe\noft Aufgaben von meinem Handy aus gesendet, die dann\n15 bis 20 Minuten auf einem Cloud-Agenten ausgeführt wurden\n. Nehmen wir an, es geht um eine\nUX-Änderung wie: „Erstelle\ndiese VS Code-Erweiterung. Melde\ndich hier an, klicke auf Einstellungen, wähle\ndieses Team aus und\nteste das Ganze im Terminal.“\nDie Cloud-Agenten sind so effizient, dass sie\nalle Klicks\ndes beschriebenen Q A-Tests automatisch ausführen\n. Sie\nprüfen, ob die Tests funktionieren, und wiederholen den Vorgang bei Fehlern\n. Das\nkann leicht 50 bis 60 Minuten dauern.\nWenn man aber viele solcher\nAufgaben parallel über das Handy, den\nLaptop oder ein anderes Gerät sendet, … nun ja, dann …\nMan hat da so ein richtig einfach\nanpassbares und erweiterbares Ding. Und das\nhilft, extrem schnell zu skalieren.\nMan kann dann Aufgaben an\ndie Cloud-\nMaschine senden, quasi an einen Messias,\nund dann zurück zum Laptop,\nkann man einfach\nden Pull Request abrufen und schon läuft alles\n. Ein weiterer Aspekt\nvon Cloud-Agenten ist, dass sie,\nwenn man mit vielen\nverschiedenen Leuten zusammenarbeitet,\nhelfen, ein\ngemeinsames Setup zu erstellen, das viele andere nutzen\nund\nanpassen können.\nIch denke, die Kombination dieser beiden Aspekte wäre\ndie finale Lösung\n. Ich behaupte, dass es\neine Zukunft gibt, in der die Benutzererfahrung\nmit Agenten größtenteils über\nCanMan läuft und die\neigentliche Rechenleistung in\nder\nCloud. Ich denke, diese vier\nFramework-Ebenen sind sozusagen der letzte Schritt, um\nCanMan zu integrieren und\nin die Cloud zu migrieren. Diese Dinge sind\nsehr schwierig.  und sehr komplexe\nProbleme. Und ich denke, wenn ich\ndu wäre, würde ich das einfach als\ngrobe Faustregel verwenden und mit\ndem absoluten Minimum anfangen, dem Einfachsten, und dann, je nachdem,\nwie viel Mühe ich\ninvestieren möchte,\ndiese Stufen auf und ab bewegen. Also ja, das war's von\nmir. Ich habe\nviele gewagte Thesen aufgestellt. Ich glaube,\nich habe viele\noffene Fragen hinterlassen. Wenn ihr\nFragen oder Gedanken habt, die\neuch vielleicht verletzen könnten, könnt ihr euch gerne\nan mich wenden und mir\nFragen schicken. Es war sehr, sehr nett von\neuch, dass ihr euch die\nZeit genommen habt. Vielen Dank.\nDarf ich ein Foto von euch machen? Okay. Okay.\nOkay, danke. Habt\nihr noch Fragen?\nIch habe eine Minute Zeit.\nOkay, das ist... Oh ja\n.\nWie plant man in einem Can\nMan? Äh,\nich finde...  So eine Art Hin und\nHer beim Sammeln von Anforderungen, wissen Sie,\nder Agent soll herausfinden, was er\nvon mir braucht, um den nützlichsten Teil zu sein\n.\nOh ja, ja, ja, ja.\nOh ja, lassen Sie mich Ihnen das zeigen. Lassen Sie mich\nIhnen das zeigen. Also, im Grunde genommen\nist meine Interpretation von Kanban, dass man,\nwenn man den\nBildschirm sieht, in jede Aufgabe gehen kann\nund der gesamte\nAblauf der Aufgabe angezeigt wird.\nUnd an diesem Punkt ist es so, dass\ndiese Oberfläche, die Sie sehen, im\nGrunde die eigentliche CLI von\nCodex ist. Und ich denke, was\nich normalerweise mache, ist,\nhier ein Gespräch zu führen, und dann weiß ich, dass ich an einem\nbestimmten Punkt alleine weitermachen kann.\nAn diesem\nPunkt ziehe ich mich einfach zurück und konzentriere mich\nauf andere Dinge. Und\nwechselt es den Status, wenn es entweder\nIhre Überprüfung benötigt oder Sie dazu auffordert?\nJa. Ja. Ja. Also, am Anfang ist das so,\nsagen wir,\nwenn  Ich sage dann, man soll ein paar Dateien lesen oder\nso, richtig? Also,\nes wäre zunächst im\nBearbeitungsstatus, und wenn dann\nmeine Eingabe benötigt wird, wird es\nüberprüft.\nÄhm, ja.\nAlles klar. Danke.",
  "transcript_chars": 18375,
  "ingested_at": "2026-05-19T16:30:34.278642+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": 708,
    "like_count": 44,
    "channel_id": "UCLKPca3kwwd-B59HNr-_lvA",
    "categories": [
      "Science & Technology"
    ],
    "tags": [
      "ai",
      "ai engineer",
      "ai engineering",
      "software development",
      "tech",
      "startups",
      "software architecture",
      "machine learning"
    ]
  }
}