{
  "video_id": "504PvfXou5Y",
  "channel_slug": "aidotengineer",
  "channel_handle": "aidotengineer",
  "title": "BDD, ADR, PRD, WTF: Capturing Decisions for Humans and AI Alike — Michal Cichra, Safe Intelligence",
  "duration_seconds": 769.0,
  "url": "https://www.youtube.com/watch?v=504PvfXou5Y",
  "upload_date": "",
  "transcript": "[Musik]\nHallo, ich bin Michal.\nWillkommen bei der Erfassung von Entscheidungen für\nMenschen und KI gleichermaßen.\nGestern haben wir zusammen mit einem Team von Safe\nIntelligence Spec 27 veröffentlicht,\nein neues Produkt zum Testen von Agenten.\nDavor war ich bei Microsoft und Red\nHat tätig und habe insgesamt 10 Jahre an einem\neinzigen Produkt gearbeitet.\nDie Konsistenzprobleme, mit denen wir bei KI konfrontiert sind,\nund die Geschichte der Erfassung von Entscheidungen tauchen\nin jedem Produkt auf, das ich gesehen habe.\nUnd diese Notizen sind aus der\nErfahrung heraus destilliert.\nUnd ihr findet mich am Stand.\nÄhm\n, also\nBDD, PRD, ADR, das sind ja eine Menge\nAkronyme.  Äh, warum ist das alles\nwichtig?\nFangen wir also am Ende an.\nDiese Geschichte kennen Sie wahrscheinlich.  Ich hoffe,\ndas ist keine urbane Legende, aber\nWissenschaftler haben fünf Affen in einen Käfig gesperrt\nund Bananen auf eine Leiter gestellt.\nDann verpasste ich ihnen jedes Mal eine kalte Dusche, wenn\nein Affe versuchte, an eine Banane zu gelangen.\nAndere Affen verprügelten den armen Kerl.\nDann ersetzten sie die Affen einen nach dem anderen,\nund keiner der ursprünglichen Affen blieb übrig.\nUnd dennoch haben sie jeden\nAffen verprügelt, der versucht hat, die Leiter hochzuklettern,\nohne zu wissen, warum.\nMenschen und LLMs leiden also unter der\ngleichen Eigenschaft.  Begrenzter Kontext.  Die Leute\nvergessen.  LLMs Kontext kompakt.  Die Menschen\ngehen.  LLMs haben kein Gedächtnis.\n[schnaubt]\nNach einer gewissen Betriebszeit eines Produkts\nbeginnt das Team sich zu fragen: „Warum haben wir\ndiesen Ablauf? Warum ist das das Ziel dieser\nFunktion?\nWarum ist dieser Code so strukturiert?\nWarum? Wo gehört das hin?“\nUnd möglicherweise steht Ihnen der Gründungsingenieur nicht zur Verfügung, um Ihre Frage\nzu beantworten.\nUnd diese Probleme treten in jeder Organisation auf.  Äh,\nvielleicht mit KI viel früher als früher\n.\nADR steht also für Architecture Decision Record (Architekturentscheidungsdokument).\nEs hält fest, warum Sie etwas tun und wie\nSie es durchsetzen oder wie Sie es tun möchten\n.\nUnd Sie können Beispiele anhand von\nReferenzdokumenten und Codeausschnitten veranschaulichen.\nWir teilen beispielsweise den Code in Schichten auf, um\nN+1-Abfragen zu vermeiden.  Wir setzen diese\nAufteilung durch, indem wir Importe in Modulen linten.\nUnd wir erzwingen auch, dass das Lesen aus der\nDatenbank\neinfache Datenstrukturen anstelle von ORM-\nObjekten zurückgibt, damit wir\ndiese Abfragen nicht durchführen können und um\nDuplikate zu vermeiden.\nUnd außerdem wird es anhand der Modulimporte geprüft.\nUnd weitere ca. 50 ADRs, die die\nArchitektur des Produkts definieren.\nEs gibt kein festgelegtes Format, das\nSie verwenden müssen.  Es ist nur ein Konzept.\nÄhm,\nes ist ein Text, daher gibt es keine spezifische Möglichkeit, ihn\ndurchzusetzen.  Sie benötigen dennoch ein\nInstrument, um dies durchzusetzen.\nDas Tool wird Ihnen aber sagen, dass dies\ndie Regel ist.  Warum tust du das?  Und\nwie soll man das beheben?\nDann wird der Agent versuchen,\ndieses Dokument zu finden, um herauszufinden, warum dieser Grund besteht und\nwie man ihn beheben kann.\nAußerdem können Sie festlegen, auf welche Dateien es sich\ngenau bezieht, z. B. ob es sich um bestimmte\nPython-Dateien oder bestimmte Ordner handelt.\nUnd wie man es tatsächlich durchsetzt.\nPRD ist ein Produktanforderungsdokument.\nÄh, das ist etwas leichter verständlich, wenn man\neine Funktion entwickelt; da beschreibt man, warum\ndiese Funktion existiert\nund welche Probleme sie löst.\nUnd wie der Nutzer die App durchläuft, um\ntatsächlich mit ihr zu interagieren.  Wie sieht der\nAblauf innerhalb der Anwendung aus?\nEs kann sehr leicht sein.  Es muss kein\nwirklich langes und ausführliches\nDokument sein.  Man kann einfach das\nWarum, das Problem, das Ziel\nund den Weg, der sie miteinander verbindet, festhalten.\nUnd das gilt nicht nur für die Agenten, sondern\nauch für Sie in sechs Wochen, wenn Sie\nvergessen haben, warum Sie das getan haben.\nNun zu BDD.\nÄhm, es handelt sich um verhaltensorientierte Entwicklung.\nSie haben in letzter Zeit wahrscheinlich von spezifikationsgetriebener\nEntwicklung gehört, aber wenn Sie sie selbst\npraktiziert hätten, hätten\nSie vielleicht dasselbe durchgemacht\nwie ich.\nWie lässt sich überprüfen, ob das Produkt\ntatsächlich den Spezifikationen entspricht?\nEs handelt sich um ein Markdown-Dokument. Sie beschreiben,\nwie es funktionieren soll, aber woher\nwissen Sie, dass es tatsächlich so funktioniert?\nEine Sache, die schwieriger ist als das Lesen von KI-Code,\nist das Lesen von KI-Tests.   Ähm\n, was wäre, wenn man eine\nZwischenschicht hätte, die das\nVerhalten des Produkts in einer menschlichen Sprache beschreibt?\nUnd BDD ist zwar nicht neu und aufregend, aber es ist\nausführbar und lesbar.   Und da kommt die\nGurke ins Spiel.\nEs war fast vergessen, ist aber plötzlich wieder nützlich\n.\nEs ist definitiv einfacher zu überprüfen als\nherkömmliche Tests.\nSie können Szenarien direkt mit\nIhren Produktspezifikationen und kritischen Benutzerabläufen verknüpfen.\nEs ist lesbar, ausführbar und\nschließt die Lücke, die eine spezifikationsgetriebene\n[räuspert sich]\nEntwicklung offen lässt.\nDiese\nRegeln, äh, diese Spezifikationen werden später\nschrittweise analysiert und als Code ausgeführt.\nAber was Sie tun können, ist, dass Sie\ndiese Texte tatsächlich schreiben und lesen können.  Und Sie\nkönnen diese überprüfen.  Und das können Sie verstehen\n.  Die Sprache liegt in Ihrer Verantwortung.  Es\nmuss nicht\nerzwungen werden.  Wie du schon sagtest, gibt es mehrere\nMöglichkeiten, diese\nFunktionen zu schreiben.\nUnd das war's auch schon\n, aber sie beschreiben,\nwie man die\nAnwendung durchlaufen soll, warum es dieses Programm gibt und\nwie es funktioniert.  Und ebenso können sie\nauf all die Dokumente zurückgreifen, die Sie darüber\nbesitzen,\nwarum die Dinge existieren.\nUnd als Bonus stellt die\nErstellung konsistenter Benutzeroberflächen für Agenten eine\nweitere Herausforderung dar.\nSo wie\nDesignsysteme und Musterbibliotheken\nder Weg sind, um konsistente Benutzeroberflächen zu erstellen.   So\nwar es vor der KI, und so\nist es auch heute noch.\nSie dokumentieren also Ihre Sprache.  Man sagt\nzum Beispiel, ein primärer Button sei dies\nund das.  Es ist blau.  Es hat diese Form.\nEs hat diese Farbe und diese Größe.\nUnd du bestimmst deine Regeln.  Sie sagen: „\nAuf einer Website wird zu jedem Zeitpunkt nur ein primärer Button auf einer Seite sichtbar sein\n.“\nUnd dann können Sie diese Regeln auch durchsetzen.   In\nähnlicher Weise definieren Sie Komponenten und\nMuster.\nWenn Sie beispielsweise mehrere\nFarben für diese Schaltflächen und mehrere\nZustände haben,\ndefinieren Sie Komponenten und\nVorschauen,\ndemonstrieren deren Funktionsweise und erstellen\nVorschau-Snippets, damit Sie\ndiese auch sehen können.\nUnd die Agenten können sie sehen.\nUnd dann können Sie das überprüfen und feststellen, ob\ndiese tatsächlich den von\nmir festgelegten Prinzipien entsprechen.\nHalten sie sich an die visuellen Vorgaben?  Und dann\nverwendet man sie wieder.\nWie beim Programmieren baut man auch hier alles von\nGrund auf aus kleinen Teilen zu größeren\nEinheiten zusammen.  Man komponiert sie und verwendet\nsie wieder.\nAnsonsten herrscht Chaos, genau wie beim\nCode.\nSo\ncool.  Das sind tolle Ideen, aber wie setze ich\ndas in der Praxis um?\nAlso, mein Team und meine Agenten halten daran fest.\nWie kann ich die Kontinuität gewährleisten?   Nun ja\n, mit der Schleife.\nSie haben wahrscheinlich schon von Begriffen wie „\nSchleife schließen“, „Verstärkungsschleife“ oder „\nGurtzeug“ gehört.\nWie man den Agenten daran erinnert, dass es\nRegeln gibt und wie man diese befolgt.\nUnsere Schleife ist also einfach.  Es handelt sich um\nGit-Hooks, Skills, CI, Linter und\neine Reihe weiterer Prüfungen.\nZiel des Agenten ist es, einen Pull\nRequest zu erstellen, und dazu muss er\nGit verwenden.\nWir verwenden also Git Hooks, um\nvordefinierte Aufgaben auszuführen, die dann\nspäter auf einem CI-Server ausgeführt werden\n.  Es handelt sich um dieselben Aufgaben, die\nals Hooks ausgeführt werden.\nWenn Agenten beispielsweise faul werden\nund die Befehle nicht ausführen wollen oder\nsie überspringen, dann werden sie erwischt.\nUnd wir beinhalten Linting, Formatierung,\nTypüberprüfung, Code-Duplizierung,\nArchitekturprüfungen, Dokument-Linting – alles,\nwas möglich ist.   Es\ngab also eine Zeit, in der es bei Code-Reviews\num Stil, Tabulatoren und Leerzeichen ging, aber dafür\nist heute kein Platz mehr.\nAll diese Dinge stehen nicht zur Diskussion.\nEs sind Regeln, sie werden durchgesetzt und\nsie werden automatisiert, weil es keinen\nRaum mehr für Diskussionen darüber gibt\n.\nEs geht mehr um die übergeordneten Konzepte.\nWas man nicht finden kann, kann man auch nicht\ndurchsetzen.\nSo setzen wir beispielsweise die Architektur des\nProdukts und des Codes durch.\nWir trennen die Module\nund ihre Importe, sodass Sie sehen können, was Sie wo verwenden können\n.\nBeispielsweise kann unsere End-to-End-BDD-\nTestsuite nicht auf die Datenbank zugreifen.  Wir\nverbieten also den Zugriff auf jedes Modul, das auf eine\nDatenbank zugreifen könnte, und\nzwingen das Modul im Grunde dazu, die Modelle\nohne Datenbankzugriff zu durchlaufen und tatsächlich\nnur die Browserfunktionen der\nAnwendung zu nutzen.\nEbenso stellen wir im Produkt selbst sicher, dass\nwir nicht von den\nRendering-Vorlagen aus mit der Datenbank kommunizieren können.  Wir wissen also, dass es\nniemals N+1-Anfragen gibt.\nWir definieren einfach Wege, um zu verhindern, dass diese\nProbleme überhaupt erst auftreten.  Man kann\nsie nicht immer wieder finden.  Sie müssen\nsie vollständig verhindern.\nDann versucht der Agent, die Änderung zu committen\nund zu pushen, erhält Feedback zum\nCommit, wird abgelehnt und wird\nzurück zum Dokument verlinkt, wo er\nes liest und den Fehler behebt.\nUnd wiederholen Sie den Vorgang.   Es\ngibt also einige Nachteile.\nÄhm, ja.\nOh, Entschuldigung.  Es sind keine Nachteile.  Also\n, diese Schleife ist generisch.  Dieser Kreislauf, in dem\nsie etwas Arbeit erledigen, diese dann\nvorantreiben, Feedback erhalten und den Vorgang wiederholen\n.\nAber die Schleife kann ja Verschiedenes bedeuten,\nrichtig?  Manchmal arbeitet man an\neiner Produktfunktion, manchmal\nan der Benutzeroberfläche und manchmal\nan eher\nserverseitigen Dingen.\nDie Schleife bleibt also gleich, nur der\nFokus der Schleife ändert sich.  Wir\nhaben also unterschiedliche Fähigkeiten.  Es gibt ADR-Regeln, nach denen\nder Agent immer dann sucht, wenn eine ADR erwähnt wird, und\nwie man damit umgeht\n.\nWie findet man Code, der\nvon diesen ADRs betroffen ist?  Dasselbe gilt für PRD\n.  Bei der for-UI-Schleife überspringen wir tatsächlich eine\nReihe von Prüfungen und erzwingen stattdessen eine\nschnelle Iteration im Browser.\nUnd eine\nTestfähigkeit, die tatsächlich die\nauszuführenden Tests anhand der Codeabdeckung und der\nDateiänderungen identifiziert.  Wir betreiben also nur einen ausgewählten\nTeil der Suite und nicht die gesamte\nSuite.\nUnd einige Zielumsetzungen, die die vom\nModell getroffenen Entscheidungen speichern, damit\nwir sie später überprüfen können.\nAll diese Faktoren sorgen für einen Fokus innerhalb der\nSchleife, die Schleife selbst bleibt aber unverändert.\nEs gibt Nachteile.\nEs ist sehr kontextabhängig.  So als ob einem schon beim\nStart der Recherche die Hälfte des Kontextes fehlen könnte.   Ähm,\naber ich habe keine Angst vor Kontextkompakten\n.  So\nfunktioniert das tatsächlich seit etwa einem halben Jahr, glaube ich.\nIn meinen Sitzungen gibt es also 20-50\nKontextkompakte, und das ist in Ordnung.\nDenn\ndie wichtigen Dinge bleiben bestehen und der\nAgent wird sie immer wieder nachschlagen.   Das\nist also sowieso das Ziel, richtig?\nBeispielsweise möchten Sie mehrstündige\nSitzungen mit einem klaren Ziel durchführen, bei dem der Agent gemäß\nden von Ihnen definierten Regeln autonom arbeiten kann\n.  Das\nist also das Ziel, nämlich\nEntscheidungen, die man festhalten kann.\nEs gibt Teile des Produkts, bei denen man\nbeschreiben kann, warum diese existieren.  Es gibt beispielsweise\nCucumber oder BDD, die ausführbare\nSpezifikationen haben, die man tatsächlich\nlesen, überprüfen und verstehen kann.\nDesignsysteme können Ihnen dabei helfen,\naus Komponenten eine konsistente Benutzeroberfläche zu erstellen.  Und\nnochmals, achten Sie darauf, dass beispielsweise\nnirgendwo sonst Inline-Styles verwendet werden\n.\nUnd man verwendet ein Geschirr, um alles\nmiteinander zu verbinden.\nMöge die Kraft der Bestimmung mit dir sein.   Das war’s\n.\n[Applaus]\n[Musik]",
  "transcript_chars": 12418,
  "ingested_at": "2026-06-03T16:30:27.063276+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": 1708,
    "like_count": 73,
    "channel_id": "UCLKPca3kwwd-B59HNr-_lvA",
    "categories": [
      "Science & Technology"
    ],
    "tags": [
      "ai",
      "ai engineer",
      "ai engineering",
      "software development",
      "tech",
      "startups",
      "software architecture",
      "machine learning"
    ]
  }
}