--- title: "Eval-Driven Development, LLM-Generated SQL, & the Cost-Uncertainty-Lag Triangle: Rippling's Playbook" source: https://www.youtube.com/watch?v=3lb_4OEOykc plattform: youtube channel: langchain duration_seconds: 1041 thema: Eval-Driven Development & Agent-Architektur nutzen: "Liefert ein produktionserprobtes Framework (Flat-Agent, generische SQL-Tools, Cost-Uncertainty-Lag-Evals) das Arias eigene Agent- und Eval-Strategie direkt informiert." umsetzungsidee: "" prioritaet: P1 klassifikation: Brain-Entry confidence: 0.82 status: aktiv tags: [evals, eval-driven-development, agent-architecture, langgraph, llm-sql, flat-agent, wilson-confidence-interval, cost-uncertainty-lag, rippling, tool-design, akp, video, auto-ingested] date: 2026-07-18 akp_run: kar-74 --- # Eval-Driven Development, LLM-Generated SQL, & the Cost-Uncertainty-Lag Triangle: Rippling's Playbook **Channel:** langchain · **Dauer:** 17 min · **URL:** https://www.youtube.com/watch?v=3lb_4OEOykc ## Kernaussage Rippling beschreibt seinen produktiven AI-Agent-Aufbau: ein flacher LangGraph-Agent statt Sub-Agent-Hierarchie, generische SQL-fähige Tools statt vieler bespoke Tools, und eval-driven development mit dem Cost-Uncertainty-Lag-Tradeoff (zwei von drei). Kernbotschaft: Glue-Code raus, LLM machen lassen, Evals sagen die Wahrheit. ## 7-Punkt Praxisanalyse ### 1. Was koennen wir lernen? Drei konkrete Architektur-Lektionen: (a) flache Agenten statt Multi-Agent-Hierarchien wegen Context-Sharing/Handoff-Problemen, (b) generische composable Tools (ein get_data mit Parameter statt N Methoden) + LLM-generiertes SQL gegen Schema statt Rohdaten im Context, (c) EDD mit statistischer Fundierung: Wilson-Confidence-Interval, Repetitions gegen Stochastizität, Smoke-Evals (jeder Commit, low cost/lag) vs. Health-Evals (2x/Tag, mehr Reps). ### 2. Wie koennen wir es einsetzen? Fuer KADi/MRR-Agenten: Sub-Agent-Sprawl vermeiden, stattdessen Skills/SOPs deklarativ in einen flachen Agenten injizieren. Bei datenintensiven Queries Schema statt Rohdaten in den Context geben und LLM SQL generieren lassen (mit Cache fuer Follow-ups). Eval-Pipeline zweistufig: schnelle Smoke-Evals im CI, groessere Health-Evals vor Prod-Promotion. ### 3. Konkreter Vorteil fuer Aria / KADi / Supplier Pulse / Workflow / Tools? Das Cost-Uncertainty-Lag-Framework und die Wilson-CI-Idee sind direkt auf Arias eigene Eval/Feedback-Loops uebertragbar — quantifiziert, wie viele Wiederholungen ein Eval braucht, statt 'einmal gruen = fertig'. Die Flat-Agent- und Generic-Tool-Prinzipien validieren/challengen unsere eigene Agent-Architektur. ### 4. Was koennen wir dadurch besser machen? Der Talk bleibt bei EDD abstrakt: keine konkreten Formeln/Sample-Sizes, kein Umgang mit LLM-as-Judge-Bias, keine Kosten-Zahlen. Aria koennte den Wilson-CI-Ansatz operationalisieren (konkreter Rep-Calculator pro Baseline/Regressionsgroesse) und die SQL-Generierung durch validierte Query-Templates/Read-Only-Guards absichern (Talk erwaehnt SQL-Injection/Fehlerhandling nur oberflaechlich). ### 5. Lohnt sich die Umsetzung — warum? Ja — es ist ein battle-tested Production-Playbook eines echten Multi-Domain-Agents, nicht Theorie. Die drei Prinzipien sind konkret und kontraintuitiv (weniger Abstraktion, weniger Tools). Passt exakt zur bestehenden Eval-Notes-Serie (3 Cross-Refs). ### 6. Naechste Schritte Als Brain-Entry ablegen, mit den drei Eval-Cross-Refs verlinken. Optional Spike: eigenen Rep-Count-Calculator (Wilson-CI) fuer Aria-Evals evaluieren. Flat-Agent-Prinzip gegen aktuelle KADi-Architektur pruefen. ## Kritik (Pflichtfeld) Der Eval-Teil ist theoretisch stark aber praktisch duenn: Wilson-CI wird genannt, aber keine anwendbaren Zahlen/Tooling. Die 'zwei von drei'-Triangle ist eine bekannte Reframing bekannter Tradeoffs (CAP-artig). Flat-Agent und generische Tools sind zunehmend Common Wisdom (2025er Konsens, siehe Anthropic/others). SQL-Generierung durch LLM ohne tiefe Diskussion von Sicherheit (Read-Only? Query-Validation? Cost-Runaway bei Cache-Miss?) — die Risiken werden verharmlost. Ueberschneidung mit den 3 bestehenden Eval-Notes ist erheblich; neuer Mehrwert liegt v.a. bei SQL-Ansatz + Cost-Uncertainty-Lag-Framing. ## Multi-Level-Challenge (inline, KAR-72) **Devils-Advocate:** Grosser Teil ist bereits durch die drei bestehenden Eval-Notes abgedeckt, und die Kern-Prinzipien (flach, generisch, evals-first) sind 2025 kaum noch neu — der Netto-Wissenszuwachs ist begrenzt. **Steel-Man:** Der Cost-Uncertainty-Lag-Triangle plus Wilson-CI und der LLM-SQL-gegen-Schema-Ansatz sind konkrete, uebertragbare Bausteine, die in den bestehenden Notes so nicht stehen und Arias Eval-Rigorosität messbar erhoehen koennen. **Synthese:** Refine — als Brain-Entry aufnehmen, aber gezielt auf die zwei neuen Bausteine (Wilson-CI/Rep-Sizing und LLM-SQL-Schema-Pattern) fokussieren und explizit gegen die 3 bestehenden Eval-Notes deduplizieren. ## Adversarial-Critic (separater Call, Cross-Model, KAR-747) **Verdict:** refine · **Confidence:** 0.79 · **Halluzinations-Risiko:** medium **Urteil:** Behaltenswert als Brain-Entry fuer den SQL-Schema-Ansatz und Flat-Agent-Bestaetigung, aber EDD/Wilson-CI-Claims sind nicht im vorliegenden Transcript-Auszug belegbar und machen ca. 40% der Analyse aus — Refine mit expliziter Kennzeichnung unverifizierbarer Abschnitte. **Schwaechen:** - Wilson-Confidence-Interval wird im Transcript-Auszug NICHT erwaehnt — der Transcript endet bevor der Eval-Teil beginnt ('Now we're going to switch gears'). Die Analyse behauptet konkrete EDD-Details (Wilson-CI, Repetitions, Smoke vs. Health Evals, Cost-Uncertainty-Lag-Triangle) als Transcript-Inhalt, obwohl der vorliegende Auszug genau dort abbricht. Das ist Halluzination oder Uebergeneralisierung aus unbekanntem Rest-Transcript. - Die Confidence von 0.82 ist zu hoch angesichts der Tatsache, dass die Haelfte der Kernaussagen (EDD-Framework, Wilson-CI, zwei-von-drei-Triangle) auf Transcript-Teilen beruht, die im Auszug nicht vorliegen und damit nicht verifizierbar sind. - SQL-Sicherheitsrisiken (Read-Only-Guards, Query-Validation, Cost-Runaway bei Cache-Miss) werden in der Kritik korrekt identifiziert, aber im Issue/Naechste-Schritte-Teil nicht adressiert — das ist eine Luecke fuer KADi-Umsetzung. - Flat-Agent und generische Tools sind im Transcript belegbar und korrekt wiedergegeben, aber die Einschaetzung 'kontraintuitiv' ist uebertrieben — das ist 2025er Mainstream-Konsens (Anthropic, LangChain-Doku etc.), der Mehrwert liegt nur in der Produktionsbestaetigung. - Der 'LLM-SQL-gegen-Schema statt Rohdaten'-Ansatz ist korrekt im Transcript belegt und der genuinste neue Baustein — dieser wird in der Analyse aber nicht prominent genug hervorgehoben gegenueber den nicht-verifizierbaren EDD-Claims. - P1-Prioritaet erscheint ueberhoeht fuer einen Talk, dessen Kernbotschaft (flach, generisch, evals-first) laut eigenem Challenge-Block bereits durch 3 bestehende Notes abgedeckt ist. ## Cross-Reference (Brain-Match) - [[2026-05-15-langchain-observability-and-evals-for-ai-agents-a-]] (score 47.525) - [[2026-06-15-langchain-the-eval-mistakes-everyone-makes-and-how]] (score 46.718) - [[2026-06-18-langchain-the-eval-system-behind-lyfts-ai-customer]] (score 45.867) ## Klassifikation: **Brain-Entry** · Prioritaet **P1** · Confidence **0.82** --- *Auto-generated by aria-akp-deep.py · cost $0.2796 · 2026-07-18T04:27:59.535052+00:00*