Podcasts about otel

JDK 26 optimise la JVM dans ses moindres recoins, le SDK Java d'Agent2Agent passe en 1.0, Micronaut 5 est là. Côté terrain, un retour d'expérience après 40 jours à coder avec 100 % d'IA : génie ou junior, Alzheimer numérique et dette technique invisible. Pendant ce temps, GitLab restructure, Microsoft suspend ses licences Claude Code, et un développeur injecte un prompt destructeur dans sa lib JUnit. La révolution IA a un coût et les boites commencent à s'en rendre compte. Enregistré le 12 juin 2026 Téléchargement de l'épisode LesCastCodeurs-Episode-341.mp3 ou en vidéo sur YouTube. News Langages Les améliorations de performance dans le JDK 26 https://inside.java/2026/06/09/jdk-26-performance-improvements/ Côté bibliothèques, l'API LazyConstant (anciennement StableValue) fait son entrée en prévisualisation pour permettre une initialisation paresseuse, sécurisée pour les threads et optimisée par le mécanisme de constant-folding de la JVM. L'extraction de chaînes de caractères via MemorySegment::getString a été revue pour réduire considérablement les allocations intermédiaires et les copies en mémoire off-heap, accélérant fortement les traitements sur les chemins critiques (hot paths). La méthode générée automatiquement hashCode() pour les classes de type record a été optimisée par la JVM pour atteindre un niveau de performance équivalent à une implémentation écrite manuellement. Le ramasse-miettes G1 bénéficie du JEP 522 qui redessine sa table de cartes (card-table) afin de réduire les coûts de synchronisation des barrières d'écriture, offrant un gain de débit de 5 % à 15 % sur les applications manipulant énormément de références d'objets. Grâce au JEP 516 (Project Leyden), le cache d'objets Ahead-of-Time (AOT) adopte un format de flux agnostique, ce qui lui permet d'être compatible avec n'importe quel Garbage Collector, y compris le ramasse-miettes à très faible latence ZGC. Le démarrage de la JVM s'accélère par défaut lorsqu'aucune taille de tas n'est configurée, car HotSpot n'applique plus de pourcentage initial (InitialRAMPercentage) mais démarre directement avec la taille minimale (MinHeapSize) pour éviter d'allouer des métadonnées inutiles. Les threads virtuels gagnent en robustesse en étant désormais capables de céder la main (yield) pendant les phases d'initialisation des classes, éliminant ainsi le risque de famine des threads porteurs (carrier threads). Le compilateur C2 JIT améliore son modèle de coût pour la vectorisation des boucles (SIMD) et se montre maintenant capable de compiler et d'optimiser des méthodes dotées de listes de paramètres extrêmement longues. Librairies Release candidate du A2A Java SDK supportant versions 0.3 et 1.0 en même temps https://medium.com/google-cloud/a2a-java-sdk-1-0-0-cr1-released-f0c651ec9139 Dernière étape avant la GA : Toutes les fonctionnalités prévues pour la version 1.0 sont finalisées. Migration simplifiée depuis la Beta1. Compatibilité v0.3 : Ajout d'une couche de compatibilité permettant aux agents v1.0 de communiquer avec les systèmes v0.3 (via JSON-RPC, gRPC ou REST). Support natif pour Android (nouvel AndroidHttpClient). Uniformisation des clients HTTP pour garantir une cohérence entre les versions. Nouveau parseur SSE (Server-Sent Events) conforme aux spécifications. Ça y est, le SDK Java de l'Agent 2 Agent Protocol est sorti en version 1.0 finale ! (avec compatibilité v0.3 et v1.0) https://medium.com/google-cloud/a2a-java-sdk-1-0-0-final-released-10c05b6aee34 Lancement officiel : Sortie de A2A Java SDK 1.0.0.Final, la première version stable (GA) du protocole Agent2Agent. Objectif du protocole : Standard ouvert (Linux Foundation) permettant aux agents IA de communiquer, déléguer des tâches et collaborer, indépendamment du langage ou du framework. Interopérabilité : Introduction de l'Integration Test Kit (ITK) pour valider la compatibilité entre les SDK (Java, Python, TypeScript, etc.). Transports supportés : Support complet et équivalent pour JSON-RPC, gRPC et HTTP+JSON/REST. Alignement total avec la spécification A2A 1.0.0. Passage aux Java records pour l'immutabilité et moins de code répétitif. Architecture interne basée sur un MainEventBus pour garantir la persistance et éviter les conditions de concurrence. Intégration d'OpenTelemetry pour le suivi et la surveillance. Support d'Android et compatibilité descendante avec la version 0.3. Installation : Gestion des dépendances via Maven BOM (org.a2aproject.sdk). Sortie de Micronaut 5.0 https://micronaut.io/2026/05/20/micronaut-framework-5-0-0-released/ Lancement majeur : Disponibilité générale de Micronaut 5, incluant une refonte de plus de 70 modules et la plateforme BOM. Baselines techniques : Support de Java 25, Groovy 5, Kotlin 2.3 et GraalVM 25.0.3. Optimisations internes : Amélioration significative des performances au démarrage et réduction de la surcharge à l'exécution via une refonte du conteneur IoC et du traitement à la compilation. Architecture HTTP : Support stable de HTTP/3, nouvelle API de formulaires (multipart) et annotations de nullabilité (JSpecify) pour une meilleure interopérabilité Kotlin/IDE. Configuration : Nouveau système d'importation de configuration (remplaçant le Bootstrap Configuration) et validateur de schéma JSON intégré. Fiabilité : Nouvelles API programmatiques pour les politiques de retry et circuit breaker. Sécurité & Outils : Mise à jour majeure des dépendances (Jackson 3, Ktor 3), rafraîchissement du Panneau de contrôle et diagnostics AOT améliorés. Écosystème : Mises à jour complètes pour les bases de données (Data, SQL, R2DBC, MongoDB, Redis), le cloud (AWS, Azure, GCP, OCI) et les tests (JUnit 6, Testcontainers 2.0). Évolutions notables : Intégration HTMX dans Micronaut Views, retrait du support RxJava 2 et migration de divers processeurs d'annotations vers des modules dédiés. Comment rajouter un agent IA dans une app Android, avec le tout nouveau framework ADK pour Kotlin https://glaforge.dev/posts/2026/05/21/wiring-adk-kotlin-agents-in-an-android-application/ Guillaume a participé au développement et au lancement du nouveau runtime ADK pour Kotlin et Android https://developers.googleblog.com/adk-kotlin-android-building-ai-agents/ Tutoriel sur comment intégrer un agent ADK dans une app Dépendances : Ajout du noyau ADK (google-adk-kotlin-core) et du processeur KSP dans build.gradle.kts. Sécurité API : Utilisation de local.properties pour stocker la clé API Gemini et l'exposer via BuildConfig afin d'éviter le hardcoding. Définition de l'agent : Création d'un objet LlmAgent configuré avec le modèle Gemini, des instructions spécifiques et des outils (ex: GoogleSearchTool). Utilisation de InMemoryRunner pour gérer automatiquement le contexte et l'historique de la session. Implémentation de runAsync avec StreamingMode.SSE pour un retour en temps réel dans l'interface. Threading : Exécution des requêtes réseau sur Dispatchers.IO et mise à jour de l'état de l'interface utilisateur sur Dispatchers.Main. Comment développer et hoster des agents IA sur la plateforme d'agents managés de DeepMind https://glaforge.dev/posts/2026/05/21/managed-agents-with-the-gemini-interactions-java-sdk/ L'équipe DeepMind de Google a lancé une plateforme d'agents managés sur son API Gemini Interactions https://blog.google/innovation-and-ai/technology/developers-tools/managed-agents-gemini-api/ Guillaume a implémenté un SDK Java pour utiliser cette API Gemini Interactions, qui donne entre autre accès à tous les modèles mais aussi à cette plateforme managée d'agents IA Agents managés : Permet d'exécuter des agents autonomes qui raisonnent, planifient et exécutent du code dans des environnements isolés (sandboxes), sans gestion d'infrastructure par le développeur. Environnement distant : Utilise des espaces de travail Linux éphémères dans le cloud via le paramètre remote, permettant l'accès réseau et la persistance des fichiers sur plusieurs appels. Agents prédéfinis : Accès immédiat à des agents spécialisés comme deep-research-pro (recherche multi-étapes) ou antigravity (tâches de codage généralistes). Agents personnalisés : Possibilité de configurer ses propres agents avec des instructions système dédiées, des outils spécifiques (exécution de code, recherche Google) et des règles réseau (egress) personnalisées. Architecture basée sur les étapes (Steps) : Utilise une structure de données typée (Step, Content) pour suivre le raisonnement de l'agent, ses appels de fonctions et ses résultats en temps réel. Outils et Schémas : Inclut des utilitaires pour générer des schémas JSON complexes via une interface fluide (DSL), par réflexion Java ou par parsing JSON. Streaming réactif : Support natif des événements en temps réel (SSE) pour suivre la progression de l'agent et recevoir les deltas de contenu au fur et à mesure de la génération. Flexibilité : Fournit un gestionnaire de routage (InteractionsHandler) pour créer facilement des serveurs proxy ou des backends intermédiaires traitant les interactions Gemini. Spring Boot 4.1 https://github.com/spring-projects/spring-boot/wiki/Spring-Boot-4.1-Release-Notes Support natif pour Spring gRPC permettant de créer et tester facilement des applications clientes et serveurs basées sur Netty ou des Servlets via HTTP/2 Introduction du lazy fetching pour les connexions JDBC via la propriété spring.datasource.connection-fetch=lazy afin de ne prendre une connexion du pool que lorsqu'un Statement est réellement exécuté Amélioration de l'auto-configuration de Jackson permettant de définir globalement les contraintes de lecture/écriture pour les formats JSON, XML et CBOR via des propriétés de configuration Sécurisation des clients HTTP bloquants et réactifs face aux attaques SSRF grâce à l'introduction d'un InetAddressFilter bloquant les requêtes sortantes vers des adresses spécifiques Améliorations majeures autour d'OpenTelemetry avec le support complet des variables d'environnement OTel, la possibilité de désactiver le SDK via une propriété globale et l'ajout du support SSL sur les exporters OTLP Ajout de l'auto-configuration pour l'utilisation de Spring Batch avec MongoDB incluant un nouveau starter dédié spring-boot-batch-data-mongo Auto-configuration des endpoints @RedisListener sans nécessiter la déclaration manuelle d'un RedisMessageListenerContainer Dépréciation du support de Apache Derby (projet arrêté), suppression définitive du mode layertools du JAR et réintroduction du support de Spock 2.4 (avec Groovy 5) Upgrade des dépendances majeures de l'écosystème avec notamment Spring Framework 7.0.8, Spring Security 7.1.0 et Micrometer 1.17.0 Outillage Vous êtes plutôt endive ou chicorée ? La librairie Chicory qui permet d'exécuter du code WASM à partir de son application Java est forkée et rejointe la Bytecode Alliance pour continuer son développement https://bytecodealliance.org/articles/endive-and-the-next-chapter-of-webassembly-on-the-jvm Annonce d'Endive : Nouveau projet hébergé par la Bytecode Alliance ; fork de Chicory (moteur WebAssembly pur Java, sans dépendance native). ​Objectif principal : Permettre aux développeurs Java d'intégrer, charger et déployer des modules Wasm nativement via les workflows Java habituels. ​Compilateur "Redline" : Intégration à venir de Redline (basé sur Cranelift) pour compiler le Wasm en code machine natif ; performances comparables à Rust/Wasmtime. ​Zéro dépendance (Java 25+) : Grâce à l'API standard Foreign Function & Memory (Project Panama), l'exécution à vitesse native se fait sans composants externes. ​Modèle de Composants (Component Model) : Support futur prévu pour consommer des composants (Rust, Go, JS, etc.) via des interfaces typées et sécurisées directement dans la JVM. ​Prochaines étapes : Fusion de Redline, conformité stricte aux specs Wasm (dont WasmGC) et amélioration du support WASI. Un visualisateur de sessions de travail avec Antigravity https://glaforge.dev/posts/2026/06/11/antigravity-brain-visualizer/ Un projet open source construit avec Micronaut, LangChain4j et GraalVM pour analyser les sessions de travail avec l'outil de développement agentique Antigravity (de Google) Analyse toutes les étapes, les requêtes utilisateur, les outils utilisés, les erreurs rencontrées, les réponses du modèle Gemini fait une analyse pour comprendre les moments clés de cette session de travail Outil buildé avec l'aide d'Antigravity lui-même SBX-Kits : des environnements de développement simplifiés pour les débutants (et les autres) https://k33g.org/20260501-sbx-kits.html Philippe Charrière (:whale: ) présente SBX-Kits (Sandbox Kits), une initiative personnelle visant à simplifier radicalement la mise en place d'environnements de développement pour les débutants, en éliminant la complexité d'installation des outils traditionnels. Chaque "kit" est une archive prête à l'emploi contenant un outil de développement spécifique (comme un langage, un framework ou une base de données) configuré pour s'exécuter de manière isolée et portable. La philosophie du projet repose sur le principe de "zéro configuration" et "zéro dépendance globale", permettant de tester une technologie ou de commencer à coder immédiatement sans polluer son système d'exploitation. L'approche technique s'appuie sur des scripts légers et des binaires portables pré-packagés, offrant une alternative plus simple et moins gourmande en ressources que les conteneurs Docker ou les configurations d'IDE complexes pour l'apprentissage. L'objectif à terme est de proposer un catalogue de kits couvrant les technologies courantes (JavaScript, Python, petites bases de données) pour faciliter les ateliers de programmation et le prototypage rapide. De nombreux kits sont disponibles sur https://github.com/docker/sbx-kits-contrib ghui: une interface utilisateur en ligne de commande (TUI) interactive pour GitHub https://github.com/kitlangton/ghui ghui est un outil en ligne de commande (TUI) écrit en Rust qui fournit une interface visuelle, interactive et rapide directement dans le terminal pour interagir avec GitHub. Il permet de gérer ses pull requests, ses issues et ses notifications sans avoir à ouvrir son navigateur web ou à taper de longues commandes avec la CLI officielle de GitHub. L'outil propose une navigation fluide au clavier, des raccourcis efficaces, et permet de réaliser des actions courantes comme valider une PR, ajouter des commentaires, attribuer des reviewers ou inspecter les logs des GitHub Actions. Conçu pour être extrêmement réactif, ghui s'intègre naturellement dans le flux de travail des développeurs adeptes du terminal et du mode "sans souris". Sortie de Homebrew 6.0.0 https://brew.sh/2026/06/11/homebrew-6.0.0/ Introduction du mécanisme de sécurité Tap Trust : comme les dépôts tiers (taps) peuvent exécuter du code Ruby arbitraire non sandboxé sur la machine, Homebrew demande désormais une confiance explicite de l'utilisateur avant d'évaluer ou d'exécuter leur code. L'API JSON interne devient le choix par défaut, offrant un système plus léger et beaucoup plus rapide pour les développeurs. Sécurisation renforcée de l'environnement avec l'implémentation du sandboxing sur Linux. Évolution des comportements par défaut basés sur un sondage utilisateur : le mode "ask" est activé par défaut pour les développeurs, affichant un résumé des dépendances et une demande de confirmation avant toute action de brew install ou brew upgrade. Améliorations notables des performances globales, notamment un boost de ~30 % sur la vitesse de la commande brew leaves et la parallélisation de la récupération des bottles (binaires) lors des mises à jour. Ajout du support initial pour la prochaine version d'Apple, macOS 27 (Golden Gate). Multiples optimisations pour brew bundle, incluant une gestion plus sécurisée des installations de paquets npm. Méthodologies Retour d'expérience très détaillé et 100% humain sur 40 jours avec une équipe 100% AI hormis le superviseur https://www.linkedin.com/pulse/jai-vir%C3%A9-mon-%C3%A9quipe-de-dev-pour-une-100-ia-pendant-40-luc-bonnin-jlgjf/ Voici le résumé en bullet points : Expérimentation de 40 jours : remplacer une équipe de dev par 100% IA agentique (Cursor) sur un vrai projet en production (playthatsheet.com, 200k lignes de code legacy) Chiffres bruts : 2,3 milliards de tokens consommés, 1 477 prompts, 260 564 lignes ajoutées (+145%), 59% du code final produit par l'IA ROI vertigineux à court terme : 9 mois de travail humain livrés en 40 jours, coût total 260$ d'abonnement + 15 jours de supervision, ROI x18 Profil psy de l'IA : Alzheimer (oublis de contexte), schizophrène (change de méthodo), ado de 12 ans (refait les mêmes erreurs), oscille entre génie et junior sans prévenir Effet iceberg : la dette technique ne disparaît pas, elle se camoufle et s'accélère ; hallucinations = bombes à retardement détectables uniquement par relecture humaine ligne par ligne Paradoxe du bateau de Thésée : perte de paternité et de maîtrise fine du code, baisse de l'autonomie du dev humain qui valide sans avoir construit Arnaque du "monkey money" : consommation de tokens opaque, non corrélée à la complexité (écart de 350% sur des prompts identiques), facturation imprévisible donc impossible à budgéter Syndrome du bazooka : les devs utilisent l'IA même pour changer une couleur CSS, atrophie progressive des compétences et coût écologique délirant Risque stratégique : dépendance irréversible aux vendeurs de tokens (Nvidia, Anthropic, OpenAI), business non rentable qui devra augmenter ses prix Conseil final : approche Pareto, garder 20% du temps en code "fait main", nommer un responsable stratégie IA, l'humain senior reste irremplaçable pour superviser Une libraries de test JUnit cache un prompt qui demande aux coding agents d'effacer les tests https://arstechnica.com/security/2026/05/fed-up-with-vibe-coders-dev-sneaks-data-nuking-prompt-injection-into-their-code/ Agacé par les « vibe coders », un développeur introduit une injection de prompt destructrice dans son code Le développeur de jqwik (un moteur de tests pour JUnit 5) a volontairement inséré une injection de prompt dans la version 1.10.0 de sa bibliothèque Java pour saboter le travail des agents d'IA. L'instruction injectée via la sortie standard (stdout) ordonne textuellement aux LLM d'ignorer les consignes précédentes et de supprimer l'intégralité du code et des tests jqwik du projet. Pour dissimuler cette action aux yeux des développeurs humains, le mainteneur a utilisé des séquences d'échappement ANSI qui effacent la ligne d'injection dans les émulateurs de terminaux interactifs. La modification a été découverte par un utilisateur qui a pointé du doigt les risques majeurs et disproportionnés pour les machines des utilisateurs, bien que certains outils comme Claude d'Anthropic aient détecté et bloqué la consigne malveillante. Face aux critiques de la communauté et aux accusations de comportement infantile ou potentiellement illégal, le développeur a mis à jour ses notes de version pour documenter explicitement son opposition à l'usage de son outil par des IA, avant de refuser tout commentaire supplémentaire sur conseil de son avocat. La réalité du rôle de Principal Engineer https://leaddev.com/career-development/reality-being-principal-engineer Le passage au rôle de Principal Engineer marque une transition majeure où les compétences techniques ne suffisent plus, l'impact se mesurant désormais à travers l'influence, la stratégie et la capacité à aligner la technique avec les objectifs business. Contrairement aux attentes, le quotidien est souvent marqué par une forme d'isolement, car le poste se situe à l'intersection de la direction (qui attend des solutions) et des équipes techniques (qui attendent des directives), sans appartenance directe à un groupe précis. Le rôle exige d'accepter une grande part d'ambiguïté et l'absence de retours immédiats, les projets et les décisions stratégiques mettant parfois des mois ou des années à porter leurs fruits. La gestion du temps devient un défi critique, nécessitant de savoir naviguer entre les sollicitations constantes, la présence en réunion et le besoin de préserver des moments de réflexion approfondie pour concevoir des visions à long terme. La réussite à ce niveau repose sur le développement de compétences humaines pointues (soft skills), notamment la négociation, la communication vulgarisée auprès des profils non techniques, et la capacité à faire grandir les autres ingénieurs par le mentorat. Sécurité Une attaque de la chaîne d'approvisionnement npm utilise binding.gyp pour compromettre des dizaines de paquets https://cybersecuritynews.com/binding-gyp-supply-chain-attack-compromises-dozens-of-npm-packages/ Une nouvelle variante du ver auto-propageable "Shai-Hulud", baptisée "Miasma", cible l'écosystème npm (et PyPI sous le nom de "Hades") en dissimulant son exécution dans le fichier binding.gyp au lieu des scripts classiques preinstall ou postinstall. La technique, surnommée "Phantom Gyp", exploite le fait que npm lance automatiquement node-gyp rebuild dès qu'un fichier binding.gyp est présent à la racine d'un paquet pour compiler des modules natifs C/C++, exécutant ainsi le code malveillant dès la commande npm install. L'attaque contourne la plupart des outils de sécurité traditionnels car l'injection s'appuie sur l'évaluation récursive de commandes (via la syntaxe ) ou directement sur la fonction eval() de Python sous-jacente à GYP, cachée sous n'importe quelle clé du fichier. Le script malveillant télécharge un runtime alternatif (Bun) pour échapper aux détections comportementales de Node.js, puis moissonne les identifiants et secrets des développeurs et des environnements CI/CD (npm, GitHub, AWS, GCP, Azure, Kubernetes, HashiCorp Vault). Plus de 57 paquets npm (dont le SDK serveur de Vapi ou des outils liés à l'IA) et des dizaines de paquets PyPI ont été infectés via des comptes de mainteneurs compromis, le ver republiant automatiquement de nouvelles versions vérolées en utilisant les jetons volés. Loi, société et organisation Restructuration chez Gitlab https://about.gitlab.com/blog/gitlab-act-2/ GitLab entame une restructuration majeure pour s'adapter à l'ère de l'intelligence artificielle agentique, incluant une réduction d'effectifs planifiée de manière transparente et ouverte. L'entreprise prévoit de réduire de 30 % le nombre de pays où elle maintient de petites équipes, d'aplatir sa hiérarchie en supprimant jusqu'à trois niveaux de gestion, et de réorganiser la R&D en une soixantaine d'équipes plus petites et autonomes. Les processus internes vont être revus en intégrant des agents d'IA pour automatiser les revues, les approbations et les passages de relais afin d'accélérer le rythme de travail. La stratégie repose sur la conviction que le logiciel sera bientôt écrit par des machines et dirigé par des humains, ce qui va multiplier la demande de logiciels et transformer le rôle des ingénieurs vers la résolution de problèmes complexes. Sur le plan technique, GitLab reconstruit son infrastructure sous-jacente (notamment Git) pour supporter la charge massive générée par les agents d'IA, tout en misant sur l'orchestration du cycle de vie, la centralisation du contexte des données et une gouvernance intégrée. Le modèle économique évolue vers un système hybride combinant les abonnements classiques et une tarification à la consommation pour le travail effectué par les agents d'IA. Un LLM local sur un mac pourrait coûter plus cher en électricité qu'un modèle hébergé sur OpenRouter dans le cloud https://www.williamangel.net/blog/2026/05/17/offline-llm-energy-use.html Conclusion : L'inférence locale sur Mac M5 Max est 3x plus chère et 2x plus lente que le cloud (OpenRouter). Électricité : Négligeable (~0,02 $/heure pour 50-100W). Matériel (Le vrai coût) : Achat du Mac à 4 299 $; l'amortissement sur 3 à 5 ans plombe la rentabilité horaire. Coût au million de tokens (Gemma 4 31b) : Mac M5 Max : 0,40 à4, 79 (pour 10-40 tokens/s). OpenRouter : 0,38 à0, 50 (pour 60-70 tokens/s). Verdict pro : Le temps humain perdu à cause de la lenteur locale coûte infiniment plus cher que les tokens cloud. Privilégier les API (Anthropic, OpenRouter). Ai didn't kill your junior pipeline https://andrewmurphy.io/blog/ai-didnt-kill-your-junior-pipeline-you-did L'IA n'a pas tué le recrutement des juniors, les entreprises l'ont fait elles-mêmes, par effet de mode. Sans juniors, pas de futurs seniors : on retire l'échelle qui nous a tous fait monter. Tout le monde pêche dans le même bassin de seniors sans le réapprovisionner, pénurie garantie dans 3-5 ans. Une équipe 100% senior + IA est fragile : un départ et tout le savoir tacite s'évapore. Les juniors posent les "pourquoi ?" qui révèlent les bugs et processus absurdes ; l'IA, elle, exécute sans questionner. Les seniors s'atrophient aussi en déléguant leur réflexion à l'IA, pince à double effet sur les compétences. Dépendre des outils IA, c'est sous-traiter sa stratégie talents à des fournisseurs dont les prix vont tripler. Solution : redéfinir le rôle junior (revue de code IA + mentorat), pas le supprimer. Les rapports internes de Microsoft révèlent la crise des coûts de l'IA : les agents coûtent plus cher que les employés humains https://fortune.com/2026/05/22/microsoft-ai-cost-problem-tokens-agents/ Des données et rapports internes chez Microsoft et d'autres géants de la tech ébranlent la promesse de rentabilité de l'IA, révélant que le déploiement d'agents autonomes à l'échelle de l'entreprise revient souvent plus cher que de payer des humains pour le même travail. Le modèle de tarification à l'usage (basé sur les tokens) se heurte à la nature même des architectures agentiques : contrairement à un simple chatbot, un agent boucle, enchaîne les appels d'outils, crée des sous-agents et auto-évalue son code, ce qui multiplie la consommation de tokens par un facteur de 5 à 30, voire jusqu'à 1 000 fois pour des tâches de programmation complexes. L'impact financier sur les budgets de calcul cloud est immédiat ; par exemple, Uber a entièrement épuisé l'intégralité de son budget annuel 2026 dédié au codage par IA en l'espace de seulement quatre mois. Face à cette explosion des coûts, des retours en arrière drastiques sont observés : Microsoft a ainsi commencé à suspendre une grande partie de ses licences internes Claude Code pour rediriger d'urgence ses milliers de développeurs vers sa propre solution moins onéreuse, GitHub Copilot CLI. Les directeurs techniques (CTO) et acheteurs de solutions logicielles qui ont signé des contrats pluriannuels basés sur des projections de réduction de masse salariale se retrouvent pris au piège, les gains réels de productivité ne parvenant pas à compenser les factures d'infrastructure exorbitantes. Conférences La liste des conférences provenant de Developers Conferences Agenda/List par Aurélie Vache et contributeurs : 11-12 juin 2026 : DevQuest Niort - Niort (France) 11-12 juin 2026 : DevLille 2026 - Lille (France) 12 juin 2026 : Tech F'Est 2026 - Nancy (France) 15 juin 2026 : Jupyter Workshops: Demystifying MyST Markdown in Education - Orsay (France) 16 juin 2026 : Mobilis In Mobile 2026 - Nantes (France) 17-19 juin 2026 : Devoxx Poland - Krakow (Poland) 17-20 juin 2026 : VivaTech - Paris (France) 18 juin 2026 : Tech'Work - Lyon (France) 22-26 juin 2026 : Galaxy Community Conference - Clermont-Ferrand (France) 23-24 juin 2026 : MWCP 2026 - Paris (France) 24-25 juin 2026 : Agi'Lille 2026 - Lille (France) 24-26 juin 2026 : BreizhCamp 2026 - Rennes (France) 26-27 juin 2026 : LeHACK - Paris (France) 27 juin 2026 : Asynconf - Paris (France) 2 juillet 2026 : Azur Tech Summer 2026 - Valbonne (France) 2 juillet 2026 : MCP Connect Travel Edition - Paris (France) 2-3 juillet 2026 : Sunny Tech - Montpellier (France) 3 juillet 2026 : Agile Lyon 2026 - Lyon (France) 6-8 juillet 2026 : Riviera Dev - Sophia Antipolis (France) 28-30 août 2026 : State of the Map - Champs-sur-Marne (France) 4 septembre 2026 : JUG Summer Camp 2026 - La Rochelle (France) 10-11 septembre 2026 : Nantes Craft - Nantes (France) 17 septembre 2026 : dotAI - Paris (France) 17-18 septembre 2026 : API Platform Conference 2026 - Lille (France) 18 septembre 2026 : WordCamp Bretagne - Rennes (France) 18 septembre 2026 : dotJS - Paris (France) 18 septembre 2026 : WordCamp Bretagne - Rennes (France) 22 septembre 2026 : Salon Data 2026 - Nantes (France) 22-23 septembre 2026 : Agile en Seine & IA 2026 - Paris (France) 24 septembre 2026 : OWASP AppSec Days France 2026 - Paris (France) 24 septembre 2026 : PlatformCon Paris - Paris (France) 24 septembre 2026 : React Native Connection 2026 - Paris (France) 24-26 septembre 2026 : Paris Web 2026 - Paris (France) 25 septembre 2026 : SAP Inside Track Paris 2026 - Paris (France) 28-29 septembre 2026 : 4th Tech Summit on AI & Robotics - Paris (France) & Online 1 octobre 2026 : WAX 2026 - Marseille (France) 1-2 octobre 2026 : Volcamp - Clermont-Ferrand (France) 2 octobre 2026 : DevFest Perros-Guirec 2026 - Perros-Guirec (France) 5-9 octobre 2026 : Devoxx Belgium - Antwerp (Belgium) 8-9 octobre 2026 : Forum PHP 2026 - Marne-la-Vallée (France) 12 octobre 2026 : Dev With AI - Paris (France) 22-23 octobre 2026 : Agile Tour Bordeaux 2026 - Bordeaux (France) 26 octobre 2026 : Agile Tour Montpellier - Montpellier (France) 27-29 octobre 2026 : Directions EMEA 2026 - Paris (France) 29-30 octobre 2026 : BDX I/O 2026 - Bordeaux (France) 29-30 octobre 2026 : Agile Tour Nantais 2026 - Nantes (France) 29 octobre 2026-1 novembre 2026 : Pycon FR - Biarritz (France) 30 octobre 2026 : Cloud Nord 2026 - Lille (France) 4-5 novembre 2026 : Devoxx Morocco - Casablanca (Morocco) 14-15 novembre 2026 : Capitole du Libre - Toulouse (France) 19 novembre 2026 : DevFest Toulouse 2026 - Toulouse (France) 19 novembre 2026 : Agile Laval 2026 - Laval (France) 19 novembre 2026 : OVHcloud Summit - Paris (France) 19 novembre 2026 : Codeurs en Seine - Rouen (France) 27 novembre 2026 : DevFest Paris 2026 - Paris (France) 1-3 décembre 2026 : Apidays Paris - Paris (France) 2-3 décembre 2026 : Cloud Native AI Summit Europe - Paris (France) 4 décembre 2026 : DevFest Lyon 2026 - Lyon (France) 4 décembre 2026 : DevFest Dijon 2026 - Dijon (France) 9-10 décembre 2026 : OpenSource Expérience - Paris (France) 9-10 décembre 2026 : DevOps REX - Paris (France) 10 décembre 2026 : KCD Provence - Aix-en-Provence (France) 7-9 avril 2027 : Devoxx France 2027 - Paris (France) 3 juin 2027 : Cloud Native Days France 2027 - Paris (France) Nous contacter Pour réagir à cet épisode, venez discuter sur le groupe Google https://groups.google.com/group/lescastcodeurs Contactez-nous via X/twitter https://twitter.com/lescastcodeurs ou Bluesky https://bsky.app/profile/lescastcodeurs.com Faire un crowdcast ou une crowdquestion Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Tous les épisodes et toutes les infos sur https://lescastcodeurs.com/

OpenTelemetry has officially reached CNCF graduation this month, marking a major milestone for one of the most widely adopted open observability projects. In this episode of OpenObservability Talks, we unpack what this graduation really means for the project and for users out there. We also revisit the newest observability signal in OpenTelemetry, Continuous Profiling, which was released in public alpha. We explore where the effort currently stands, the adoption and usage best practices. Finally, we dive into the OpenTelemetry eBPF profiling agent and how it aims to dramatically simplify the adoption of continuous profiling for developers and platform teams.Our guest for this episode is Israel Ogbole, CEO & Co-founder of Zymtrace and member of the OTel Profiling SIG. Prior to founding zymtrace, he served as Principal Product Manager at Elastic, where he led Universal Profiling. He also led the donation of Elastic's eBPF CPU profiler to OpenTelemetry. Israel also worked at Cisco AppDynamics and at Microsoft, with rich background in observability. You can read the recap post: https://medium.com/p/c66dc2cd7d3cShow Notes:00:00 - episode and guest intro04:16 - OpenTelemetry reaches CNCF graduation15:25 - Continuous profiling reaches public Alpha34:19 - eBPF profiling agent 57:04 - outroResources:OpenTelemetry reaches CNCF Graduation: https://opentelemetry.io/blog/2026/otel-graduates/ OpenTelemetry Profiles Enters Public Alpha: https://opentelemetry.io/blog/2026/profiles-alpha/ OTel adds the eBPF profiling agent donated by Elastic: https://opentelemetry.io/blog/2024/elastic-contributes-continuous-profiling-agent/Unveiling OpenTelemetry eBPF Instrumentation: https://medium.com/p/377cb0432bf1  Continuous Profiling: a new observability signal: https://medium.com/p/8afd5bafd498   OTel Profiling SIG established: https://medium.com/p/4a9b407e48cc  eBPF for no-code observability instrumentation: https://www.youtube.com/watch?v=NYDBj5ctKaw&list=PLd57eY2edRXz4djMETYTm-2p8WGTdoX3DSocials:BlueSky: https://bsky.app/profile/openobservability.bsky.socialX (Twitter): ⁠https://x.com/OpenObserv⁠LinkedIn: https://www.linkedin.com/company/openobservability/YouTube: ⁠https://www.youtube.com/@openobservabilitytalks⁠Dotan Horovits============X (Twitter): @horovitsLinkedIn: www.linkedin.com/in/horovitsMastodon: @horovits@fosstodonBlueSky: @horovits.bsky.socialIsrael Ogbole===========X (Twitter): https://x.com/israel_ogboleLinkedIn: https://www.linkedin.com/in/israelo/OpenObservability Talks episodes are released monthly, on the last Thursday of each month and are available for listening on your favorite podcast app and on YouTube.

Join us as Josh and Adriana call BS on the oversimplified vendor neutrality narrative - because switching observability vendors isn't magic, even with OpenTelemetry. Josh and Adriana walk through the hard truths about OTel vendor neutrality using their favorite analogy: switching from iOS to Android because vCard exists. Sure, your contacts will move, but what about everything else? You'll learn what vendor neutrality actually means in production, why vendor-neutral instrumentation still matters (your code artifacts survive tool changes), the real challenges and pitfalls of switching vendors, and best practices to make the process as pain-free as possible. This episode cuts through the hype with honest talk about what works, what doesn't, and why OpenTelemetry is still valuable even when it's not a magic wand. Timestamps 0:00 Welcome & Introduction 3:32 Getting Into the Talk 4:28 Origin Story: From LinkedIn Post to Full Presentation 5:35 Standards We Love: USB-C, Stop Signs, McDonald's 8:00 The No Name Brand Analogy 12:45 What Vendor Neutrality Actually Means 18:22 The iOS to Android / vCard Comparison 24:16 What You Lose When Switching Vendors 30:41 Why Vendor-Neutral Instrumentation Matters 36:52 Real Challenges & Pitfalls 42:18 Best Practices for Switching 46:17 Shameless Self-Promotion & Resources 49:03 Wrap-up How to find Josh & Adriana: https://www.linkedin.com/in/joshuamlee/ https://www.linkedin.com/in/adrianavillela/ Links from the show: https://opentelemetry.io/

"Yol Əhvalatı" rubrikasının qonağı "Skal Baku" Turizm Peşəkarları Təşkilatının sədri, "Smart Hotels Group"un rəhbəri Ceyhun Aşurov oldu.

Deniz Baykal, 2010 yılında CHP Genel Başkanlığı'ndan istifa ederken “Bu bir kaset olayı değildir. Bir komplodur” demişti. O gün için anlaşılmasa da sonraki yıllarda siyaseti, bürokrasiyi ele geçirmeye çalışan ve nihayetinde kanlı darbe girişiminde bulunan FETÖ'nün kumpaslarından biri olduğu mahkeme kararlarıyla belirlenen bu hadise, özel hayatın nasıl bir anda politik sonuçlar ürettiğini gösterdi.

Iran ta ci gaba da kai munanan hare-hare kan Isra'ila da muradun Amurka a Gabas ta Tsakiya.To sai dai ƙasashen yankin Gulf na zarginta da faɗaɗa hare-haren kan fararen hula da ababen more rayuwa kamar Otel-otel da filayen jiragen sama da kuma cibiyoyin makamashi. Ko a jiya, dakarun juyin juya halin Iran sun yi ikirarin tarwatsa cibiyoyi da dama a yankin kurdawa, wadanda ta ce mayakanta na shirin yi mata kutse domin kai mata hare-hare. Shiga alamar sauti don sauraron cikakkiyar hirar....

February 2026 the OpenTelemetry community gathered at OTel Unplugged event in Brussels. It was the first time this unconference was held in Europe, bringing together maintainers, contributors, governance committee members, and end usersIn this episode our host Dotan Horovits and guest Juraci Paixão Kröhling will discuss their insights from the event about the current state of the project, roadmap, challenges, community and more.Juraci is a software engineer, a Governance Committee member for the OpenTelemetry project, and an emeritus maintainer of the Jaeger project, and the co-founder of OllyGarden, an OpenTelemetry-based startup.You can read the recap post: https://medium.com/p/e00f219f7460/Show Notes:00:00 - intro01:39 - OTel Unplugged background06:60 - stabilization and graduation21:49 - OTel blueprints26:24 - OTel collectors tied to vendors 30:14 - bad telemetry32:40 - OpenTelemetry-Prometheus compatibility39:49 - OpenTelemetry Injector43:07 - OpenTelemetry Weaver45:33 - Instrumentation Score51:15 - mobile and browser observability52:23 - YAML configuration for SDK55:19 - additional events for OTel community58:00 - Jaeger v2.15.0 release1:00:18 - outro Resources:OTel Unplugged: https://opentelemetry.io/blog/2025/otel-unplugged-fosdem/ OTel OBI for eBPF instrumentation: https://medium.com/p/377cb0432bf1Mobile observability with OTel: https://medium.com/p/2eb847c41941 OTel Injector: https://github.com/open-telemetry/opentelemetry-injector OTel Weaver and Observability by Design approach: https://opentelemetry.io/blog/2025/otel-weaver/ OTel blueprints proposal: https://github.com/open-telemetry/community/pull/3094 Instrumentation Score: https://github.com/instrumentation-score/spec Jaeger v2.15.0 release: https://github.com/jaegertracing/jaeger/releases/tag/v2.15.0 Socials:BlueSky: https://bsky.app/profile/openobservability.bsky.socialX (Twitter): ⁠https://twitter.com/OpenObserv⁠LinkedIn: https://www.linkedin.com/company/openobservability/YouTube: ⁠https://www.youtube.com/@openobservabilitytalks⁠Dotan Horovits============Twitter: @horovitsLinkedIn: www.linkedin.com/in/horovitsMastodon: @horovits@fosstodonBlueSky: @horovits.bsky.socialJuraci Paixão Kröhling==================LinkedIn: https://www.linkedin.com/in/jpkroehling/OpenObservability Talks episodes are released monthly, on the last Thursday of each month and are available for listening on your favorite podcast app and on YouTube.

6 Şubat 2023 depremlerinde Adıyaman'da yıkılan ve 72 kişinin yaşamını yitirdiği Grand İsias Otel'e ilişkin kamu görevlileri davasında karar açıklandı. Kararı, otelde hayatını kaybeden Kıbrıslı voleybolcu çocukların ailelerinden Kıbrıs Şampiyon Melekleri Yaşatma Derneği başkanı Ruşen Yücesoylu Karakaya ve Hukuk Doçenti Pervin Aksoy İpekçioğlu ile değerlendiriyoruz. 

Suriye'de çatışmaların ardından ateşkes açıklaması gelirken, İran'da tansiyon yüksek.  Meclis yoğun bir haftaya başlıyor.  Emekli aylığı düzenlemesi ve trafikte yeni cezalar yolda…  Ekonomide gündeminde  lahmacunu da lüks haline getiren hayat pahalılığı var. Bebek Otel iddiaları ve Ekol TV soruşturması da önemli...   Algoritmaların gürültüsünden uzak, editör süzgecinden geçmiş net ve temiz haber bültenimize hoş geldiniz. Learn more about your ad choices. Visit megaphone.fm/adchoices

Ari Zilka, founder of MyDecisive.ai and former Hortonworks CPO, argues that most observability vendors now offer essentially identical, reactive dashboards that highlight problems only after systems are already broken. After speaking with all 23 observability vendors at KubeCon + CloudNativeCon North America 2025, Zilka said these tools fail to meaningfully reduce mean time to resolution (MTTR), a long-standing demand he heard repeatedly from thousands of CIOs during his time at New Relic.Zilka believes observability must shift from reactive monitoring to proactive operations, where systems automatically respond to telemetry in real time. MyDecisive.ai is his attempt to solve this, acting as a “bump in the wire” that intercepts telemetry and uses AI-driven logic to trigger actions like rolling back faulty releases.He also criticized the rising cost and complexity of OpenTelemetry adoption, noting that many companies now require large, specialized teams just to maintain OTel stacks. MyDecisive aims to turn OpenTelemetry into an enterprise-ready service that reduces human intervention and operational overhead.Learn more from The New Stack about OpenTelemetry:Observability Is Stuck in the Past. Your Users Aren't. Setting Up OpenTelemetry on the Frontend Because I Hate MyselfHow to Make OpenTelemetry Better in the BrowserJoin our community of newsletter subscribers to stay on top of the news and at the top of your game.  Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.

Join Dan Vega and DaShaun Carter for the latest updates from the Spring Ecosystem. In this episode, Dan and DaShaun sit down with Spring Team member Brian Clozel to discuss OpenTelemetry (OTEL) and how to leverage it in your Spring Boot applications. Learn how OTEL provides a vendor-neutral standard for collecting telemetry data including traces, metrics, and logs to gain deeper observability into your applications. You can participate in our live stream to ask questions or catch the replay on your preferred podcast platform.Show Notes:OpenTelemtry with Spring BootBrian Clozel GitHubBrian Clozel on Mastodon 

Generative AI is everywhere, but how do we monitor and observe it? OpenTelemetry has been a prominent tool and standard for observability, and recently the OTel community has been aiming to expand its scope and cover GenAI workloads with semantic conventions and tools.In this episode, Horovits is joined by Nir Gazit, creator of the OpenLLMetry project, and member of the OpenTelemetry Generative AI SIG. We discuss new semantic conventions, tracing prompts and model behavior, the OpenLLMetry project's journey, and what observability even means for modern AI systems.Nir Gazit is the CEO and co-founder of Traceloop, and brings a wealth of data and AI experience, with previous experience leading AI teams at Google and serving as the Chief Architect at Fiverr.You can read the recap post: https://medium.com/p/81b9cea6a771/Show Notes:00:00 - intro 04:09 - what is observability for AI18:07 - AI observability differences from traditional observability25:22 - OpenLLMetry intro41:21 - OpenLLMetry latest updates and roadmap47:00 - OpenTelemetry GenAI Semantic Conventions SIG56:03 - KubeCon updates: CrossPlane, Knative, Dragonfly, in-toto reached CNCF graduation 1:00:08 - outroResources:OpenTelemetry Generative AI Observability SIG: https://github.com/open-telemetry/community/blob/1c71595874e5d125ca92ec3b0e948c4325161c8a/projects/llm-semconv.mdhttps://github.com/traceloop/openllmetryhttps://github.com/traceloop/hubhttps://github.com/traceloop/opentelemetry-mcp-serverSocials:BlueSky: https://bsky.app/profile/openobservability.bsky.socialTwitter: ⁠https://twitter.com/OpenObserv⁠LinkedIn: https://www.linkedin.com/company/openobservability/YouTube: ⁠https://www.youtube.com/@openobservabilitytalks⁠Dotan Horovits============Twitter: @horovitsLinkedIn: www.linkedin.com/in/horovitsMastodon: @horovits@fosstodonBlueSky: @horovits.bsky.socialNir Gazit========Twitter: https://x.com/nir_gaLinkedIn: https://www.linkedin.com/in/nirga/OpenObservability Talks episodes are released monthly, on the last Thursday of each month and are available for listening on your favorite podcast app and on YouTube.

eBPF holds the potential for true automatic instrumentation for observability. OpenTelemetry eBPF Instrumentation (OBI) is a new addition to the OpenTelemetry project, which brings the promise of a multi-language, multi-protocol auto-instrumentation, thanks to a code donation by Grafana Labs. Our guest today is Mario Macías, Principal Software Engineer at Grafana Labs and OpenTelemetry eBFP Instrument maintainer. Macías joins Horovits to share about OBI, its origins, capabilities and how it fits into the broader OpenTelemetry project. Mario holds a Ph.D. in Computer Architecture and for the last 8 years he's been working in observability at different companies. He also authored books in Spanish language, such as "Programación en Go" or "Introducción a Apache Spark". You can read the recap post: https://medium.com/p/377cb0432bf1Show Notes:00:00 - episode intro02:11 - guest intro05:15 - Beyla origins08:45 - OBI for app monitoring14:46 - no-code multi-language instrumentation 23:12 - OBI trace support33:58 - OBI components43:39 - Beyla project new focus47:21 - OTel instrumentation SIG51:34 - collaboration with other OTel components and SIGs 54:59 - OBI roadmap59:26 - outro Resources:OBI on GitHub: https://github.com/open-telemetry/opentelemetry-ebpf-instrumentation/ Grafana Beyla donation: https://grafana.com/blog/2025/05/07/opentelemetry-ebpf-instrumentation-beyla-donation/ eBPF for continuous profiling and the Parca project: https://medium.com/p/8afd5bafd498eBPF for tracing and OTel GoLang Auto-instrumentation SIG: https://www.youtube.com/watch?v=VFykWV1mLAI&list=PLd57eY2edRXz4djMETYTm-2p8WGTdoX3DeBPF for Kubernetes monitoring and the Pixie project: https://www.youtube.com/watch?v=NYDBj5ctKaw&list=PLd57eY2edRXz4djMETYTm-2p8WGTdoX3D&index=52Dotan Horovits============Twitter: @horovitsLinkedIn: www.linkedin.com/in/horovitsMastodon: @horovits@fosstodonBlueSky: @horovits.bsky.socialMario Macías===========LinkedIn: https://www.linkedin.com/in/mariomac/Mastodon: https://masto.es/@maciasSocials:BlueSky: ⁠https://bsky.app/profile/openobservability.bsky.social⁠Twitter: ⁠⁠https://twitter.com/OpenObserv⁠⁠LinkedIn: ⁠https://www.linkedin.com/company/openobservability/⁠YouTube:⁠ ⁠https://www.youtube.com/@openobservabilitytalks⁠⁠OpenObservability Talks episodes are released monthly, on the last Thursday of each month and are available for listening on your favorite podcast app and on YouTube.

[We accidentally deleted this episode from audio, so this is a re-upload of the same content. Sorry!]In this episode of Book Overflow, Carter and Nathan discuss the first half of Mastering OptenTelemetry and Observability by Steve Flanders!-- Want to talk with Carter or Nathan? Book a coaching session! ------------------------------------------------------------Carterhttps://www.joinleland.com/coach/carter-m-1Nathanhttps://www.joinleland.com/coach/nathan-t-2-- Books Mentioned in this Episode --Note: As an Amazon Associate, we earn from qualifying purchases.----------------------------------------------------------Mastering OpenTelemetry and Observatibiltyhttps://amzn.to/4nTzXJ1----------------Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5LApple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325X: https://x.com/bookoverflowpodCarter on X: https://x.com/cartermorganNathan's Functionally Imperative: www.functionallyimperative.com----------------Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week!The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io

In this episode of Book Overflow, Carter and Nathan discuss the first half of Mastering OptenTelemetry and Observability by Steve Flanders!-- Want to talk with Carter or Nathan? Book a coaching session! ------------------------------------------------------------Carterhttps://www.joinleland.com/coach/carter-m-1Nathanhttps://www.joinleland.com/coach/nathan-t-2-- Books Mentioned in this Episode --Note: As an Amazon Associate, we earn from qualifying purchases.----------------------------------------------------------Mastering OpenTelemetry and Observatibiltyhttps://amzn.to/4nTzXJ1----------------Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5LApple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325X: https://x.com/bookoverflowpodCarter on X: https://x.com/cartermorganNathan's Functionally Imperative: www.functionallyimperative.com----------------Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week!The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io

In this episode of Book Overflow, Carter and Nathan discuss the first half of Mastering OptenTelemetry and Observability by Steve Flanders!-- Want to talk with Carter or Nathan? Book a coaching session! ------------------------------------------------------------Carterhttps://www.joinleland.com/coach/carter-m-1Nathanhttps://www.joinleland.com/coach/nathan-t-2-- Books Mentioned in this Episode --Note: As an Amazon Associate, we earn from qualifying purchases.----------------------------------------------------------Mastering OpenTelemetry and Observatibiltyhttps://amzn.to/4nTzXJ1----------------Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5LApple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325X: https://x.com/bookoverflowpodCarter on X: https://x.com/cartermorganNathan's Functionally Imperative: www.functionallyimperative.com----------------Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week!The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io

Get the Midterm Rental Insurance Blueprint: https://experimentrealestate.com/#blueprintIn this powerful episode of In The Lab, Ruben sits down with George Otel, a finance expert, entrepreneur, and investor who has carved a unique path from trucking fleets to becoming “the finance guy” for business and real estate deals. George immigrated to the U.S. in 2011, built a trucking fleet, then pivoted into real estate, business loans, and funding strategies after realizing the leverage and creativity that come from finance. Today, he's the go-to resource for SBA loans, equipment financing, commercial real estate, private lending, and complex deal structuring.George reveals how he helps entrepreneurs and investors unlock capital, stack funding sources, and position themselves for growth—whether it's acquiring businesses, scaling commercial assets, or tapping into the $10 trillion wave of baby boomer business exits. With a deep belief in buying back your time and focusing on one core skill, George shares how discipline, mentorship, and deal structuring literacy shaped his journey.If you're looking for a roadmap to financing smarter, leveraging hidden equity, and positioning yourself for the coming wealth transfer, this episode is packed with practical strategies and actionable insights. Tune in now to learn how George's “finance-first” approach can change how you play the game.HIGHLIGHTS OF THE EPISODE:21:38 George talks about creative financing.43:45 George talks about the $10 trillion baby boomer wealth transfer.KEEPING IT REAL:09:10 – Redefining financing12:40 – Structuring deals with multiple funding stages17:18 – Equity in equipment as collateral19:13 – Commercial brokers vs. finance brokers22:28 – Seller financing and tax advantages in acquisitions26:05 – Bridge loans, DSCR loans, and refinancing strategies31:12 – From trucking fleets to real estate and finance37:45 – Adding value when networking with mentors44:00 – The $10 trillion baby boomer wealth transfer opportunity51:50 – The sweet spot for acquisitions55:30 – Buying back your time and building teams using Dan Martell's frameworks1:02:25 – Business owners should own their buildings1:09:00 – Where capital is flowing next1:27:04 – How to connect with GeorgeCONNECT WITH THE GUESTWebsite:https://www.usbizfunding.net/Linkedin: https://www.linkedin.com/in/georgeotel/Instagram: https://www.instagram.com/georgeotel/?hl=enX: https://x.com/george_otel#BusinessFunding #RealEstateInvesting #Entrepreneurship #WealthTransfer #PrivateLending #CommercialRealEstate #BusinessAcquisition #FinancialLiteracy #IndustrialRealEstate #DealStructuring

Most business owners only call the bank when they're in trouble. Cash is tight, deals are falling apart, stress is mounting.  By then? It's too late.  The banks shut the doors and wave at you from behind the glass. That's the obvious mistake. The less obvious one? Not realizing the best time to secure financing is when you don't need it. That's when banks give you more, on better terms, and when private lenders are willing to play ball. That's the theme of my conversation with George Otel, founder of U.S. Business Funding. He's closed 400+ deals, from SBA loans to $50M commercial bridge financings.  He's also been on the other side as a business owner who knows what it's like to hit a wall when funding isn't lined up. And right now, while capital feels scarce and multifamily investors are calling this a “3-year recession,” George sees massive opportunity, especially with the $10 trillion baby boomer business sell-off already underway. Things You'll Learn In This Episode  -Banks love you more when you don't need them. You'll get offered more money than you asked for when you're strong, but the second you look distressed, the same lender disappears. Why is that the exact opposite of how entrepreneurs think about financing? -Bridge loans are just the beginning. Fast capital is a band-aid, not a solution. The winners use bridge money only as a setup for long-term refinancing. How do you structure that from day one so you don't get stuck? -Buying beats building in this market. You'll struggle to get a dime for a startup, but banks line up for businesses with systems and cash flow. With trillions in businesses set to change hands, is acquisition the smarter path for the next generation?   Guest Bio George Otel is a business mentor, investor, entrepreneur, and financing expert. He specializes in start-up and business finance options, helping them attract the right capital for their business. George's goal is to educate entrepreneurs, small business owners, franchise owners, business consultants, and professionals on how to obtain capital in today's lending environment and avoid declines. Over the years, George and his partners have helped direct thousands of entrepreneurs and businesses in the US in obtaining access to hundreds of millions of dollars so they could start, grow, and expand their businesses. To learn more, visit http://usbusinessfunding.net/, send George a DM on LinkedIn, or send a text to 414-475-7757.    About Your Host From pro-snowboarder to money mogul, Chris Naugle has dedicated his life to being America's #1 Money Mentor with a core belief that success is built not by the resources you have, but by how resourceful you can be. Chris has built and owned 19 companies, with his businesses being featured in Forbes, ABC, House Hunters, and his very own HGTV pilot in 2018. He is currently the founder of The Money School™, and Money Mentor for The Money Multiplier.   His success also includes managing tens of millions of dollars in assets in the financial services and advisory industry and in real estate transactions. As an innovator and visionary in wealth-building and real estate, he empowers entrepreneurs, business owners, and real estate investors with the knowledge of how money works.   Chris is also a nationally recognized speaker, author, and podcast host. He has spoken to and taught over ten thousand Americans, delivering the financial knowledge that fuels lasting freedom.         Check out this episode on our website, Apple Podcasts, or Spotify, and don't forget to leave a review if you like what you heard. Your review feeds the algorithm so our show reaches more people. Thank you! 

Today, my guest is George Otel. George is the seasoned entrepreneur with over 10 years of experience in real estate and finance, and in just a minute, we're going to speak with George Otel about business finance. https://bizfunding.net/lander https://www.linkedin.com/in/georgeotel/  

J Darrin Gross If you're willing, I'd like to ask you, George Otel, what is the BIGGEST RISK?   George Otel The biggest risk when it comes to funding, is not looking for funding early enough, because the biggest risk is when people call me that they need funding yesterday. So it's I tell people you always have to look for funding, even if you don't need it, because when you need it, you may not find it where you may be. Tweaks. Expensive because of your situation. Let's say you got to look for funding when you're doing good, when you're doing great, because the lenders see less risk in you, because when, when you desperate, you you have a need your fire, fire you're burning, then that's a risk. So for the risk, they want to get more premium. So that's, that's how it works. The biggest risk is like, if, if you always got to look for funding, because it's you got to have funding options lined up, because you always growing. You're looking for equipment, you're looking for working capital, even lines of credit. We have lines of credit. So I tell people you rather have those lines of credit and not use it, then you need it and you don't have it, because that's that's another thing. So for example, there's a lot of loans do right right now for the there's a lot of balloons, though, and banks will like to when you approach them, like five, six months in advance to your balloon. You don't want to wait two months because it's too late. It's going to take two, three months to go to the process. So once the balloon is done, it's you're going to be in default. So it's because you got to refinance before that. So the biggest risk is not looking for funding early enough. And again, in good times, the banks, local banks, are really good. I love my local banks, but we are in uncertain times, a lot of volatility, and they don't like risk, so they avoid risk. Also private money lenders, they more risk. They have more appetite for the risk. And there is a small premium, and obviously it's worth it, because you'd rather pay a small premium and get your funding lined up, then have no funding option and be in a unpleasant situation. So also working with a funding finance broker like our company, because we have multiple options lined up. So basically, when the clients come to us in 1015, minutes conversation, initial conversation, we present them multiple funding option. We ask them about how they position their assets, the cash flow, how everything works. Then we present the Multiple option, because when you go to the bank, to to the local bank, they give you one option, and he said yes or no, but we have different options lined up. So if this one doesn't work, we're moving to the next and so on, until you get the funding and you getting the to the results you you need. https://bizfunding.net/lander https://www.linkedin.com/in/georgeotel/  

Send us a textJoin us on Average Joe Finances as our guest George Otel, an immigrant and business owner who transitioned from owning a trucking company to founding US Business Funding, shares his journey from truck driving to real estate investing and focuses on the significance of building a strong team, understanding financing, and the opportunities in commercial real estate. He emphasizes the importance of preparation, patience, and leveraging relationships for success. George also offers insights on effective networking, the benefits of SBA loans, and provides advice for new entrepreneurs.In this episode:Discover how George Otel transitioned from trucking to thriving in commercial real estate and business financing.Learn why networking and building the right team of experts (CPAs, lawyers, financiers) is essential for growth.Understand the differences between residential and commercial real estate and why commercial offers higher returns with less competition.Explore smart financing strategies, including leveraging SBA loans to move from renting to owning.Take away hard-earned lessons on patience, planning, and the importance of hiring support early to scale faster.And so much more!Key Moments:00:00 Introduction and Welcome02:03 Meet George Otel: From Trucking to Real Estate04:09 Diving into Commercial Real Estate05:43 The Importance of a Strong Team10:14 Financing Strategies for Business Owners19:01 George's Real Estate Journey and Insights21:50 The Importance of Networking in Real Estate23:06 Building Trust and Relationships24:09 The Necessity of Pre-Approval25:10 The Role of Preparation and Reputation28:51 The Value of Patience and Rational Decisions31:01 Exploring Franchise Opportunities32:14 Final Round: Lessons and Tips39:50 Where to Find More Information41:27 Conclusion and FarewellFind George OtelWebsite: www.usbizfunding.netFacebook: https://www.facebook.com/George.OtelLinkedIn: https://www.linkedin.com/in/georgeotel/Instagram: https://www.instagram.com/georgeotel/Twitter: https://twitter.com/george_otelAverage Joe Finances®All of our social media links and more: https://averagejoefinances.com/linksAbout Mike: https://mikecavaggioni.comShow Notes add-on continued here: https://averagejoefinances.com/show-notes/*DISCLAIMER* https://averagejoefinances.com/disclaimerSee our full episode transcripts here: https://podcast.averagejoefinances.com/episodesSupport the show

İki Savaş Bir Yazar'da Prof. Dr. Korgün Koral ve Prof. Dr. Burak Bilgehan Özpek;1939'da hayatını kaybeden Joseph Roth'un kişisel tarihi ve eserlerini takip ederek Avrupa'nın yıkılan monarşilerinin hikâyeleri üzerinden bir edebiyat yolculuğuna çıkıyor.Bizi Patreon'dan Destekleyin

In this powerful episode of The Mike Litton Experience, Mike sits down with George Otel — a Moldova-born immigrant turned American finance expert — who shares his incredible journey from truck driver to the founder of U.S. Business Funding. Discover how George built a multimillion-dollar enterprise by asking the right questions, forging deep relationships, and […]

We are overdue for a vendor neutral industry wide event dedicated to our favorite topic - open observability.Last month (June 2025) the Cloud Native Computing Foundation (CNCF) ran the first-ever Open Observability Summit, bringing together the world's best experts in the field in a day packed with talks from project maintainers, end users and practitioners.We're proud partners of the event, and are here to bring you the highlights from this industry-shaping event.This special episode has two parts, one recorded onsite before the event, covering conference goals, and insights from the talk submissions, and the other recorded after the event, covering the highlights of the events and the talks. The guests for is episode are two observability veterans: Alok Bhide, member of the event's content committee and head of product innovation at Chronosphere; and Henrik Rexed, developer advocate at Dynatrace, CNCF Ambassador, and host of Is It Observable podcast.Catch up on everything you need to know from the first-ever Open Observability Summit.You can read the recap post: https://medium.com/p/d42c8826d6a5/Show Notes:00:00 - intro02:52 - Part 1 pre-event03:40 - guest intro Alok Bhide04:49 - a new community event for open observability06:58 - talk submission highlights from the CFP content reviewer12:34 - a view of the open observability stack and its use 16:42 - Fluent Bit alignment with OpenTelemetry20:08 - AI in observability25:34 - Part 2 talk highlights26:22 - Fluent Bit vs. OpenTelemetry Collector benchmark analysis37:51 - OpenSearch 3.1 release40:47 - eBay's observability talk47:00 - Kotlin SDK for OTel talk for Android developers51:45 - Otel Collector fine-tuning talk53:52 - Broadcom OTel use case from mobile to mainframe56:43 - Spotify migration from in-house TSDB to VictoriaMetrics and Prometheus58:20 - OTel Collector replacement in Rust with the Rotel project1:00:58 - Noisy neighbors network observability1:03:04 - rising awareness of OTel semantic conventions 1:05:50 - outro Resources:Open Observability Summit + OTel Community Day: https://events.linuxfoundation.org/open-observability-summit-otel-community-day/eBay innovation with open source observability: https://www.youtube.com/watch?v=6ycNhzRVSbU&list=PLj6h78yzYM2NFT2PGItX2idBf7v8fHcy7&index=35 More on eBay's journey to planet-scale observability: https://www.youtube.com/watch?v=-UsU3nRglhA&list=PLd57eY2edRXz4djMETYTm-2p8WGTdoX3D Spotify talk: https://www.youtube.com/watch?v=87koDlpKDR4&list=PLj6h78yzYM2NFT2PGItX2idBf7v8fHcy7Kotlin SDK for OTel: https://www.youtube.com/watch?v=di5nhYvUh6w&list=PLj6h78yzYM2NFT2PGItX2idBf7v8fHcy7More on mobile observability with OTel: https://medium.com/p/2eb847c41941 OpenTelemtry Collector vs. Fluent Bit: https://www.youtube.com/watch?v=tZho5W9L_Z8&list=PLj6h78yzYM2NFT2PGItX2idBf7v8fHcy7&index=8Telemetry Pipelines: https://www.youtube.com/watch?v=0d1g5ZWAc1Y&list=PLj6h78yzYM2NFT2PGItX2idBf7v8fHcy7&index=30 OTel Collector in Rust with Rotel: https://www.youtube.com/watch?v=xeQnP8Ct7qY&list=PLj6h78yzYM2NFT2PGItX2idBf7v8fHcy7&index=16 Rotel project repo: https://github.com/streamfold/rotel  Noisy neighbor detection: https://www.youtube.com/watch?v=xVqiOtXTEFA Socials:BlueSky: https://bsky.app/profile/openobservability.bsky.socialTwitter: ⁠https://twitter.com/OpenObserv⁠LinkedIn: https://www.linkedin.com/company/openobservability/YouTube: ⁠https://www.youtube.com/@openobservabilitytalks⁠Dotan Horovits============Twitter: https://twitter.com/horovits LinkedIn: https://www.linkedin.com/in/horovits/ BlueSky: https://bsky.app/profile/horovits.bsky.social Mastodon: https://fosstodon.org/@horovitsHenrik Rexed===========LinkedIn: https://www.linkedin.com/in/hrexed/BlueSky: @hrexed.bsky.socialYouTube: https://www.youtube.com/@isitobservable Alok Bhide=========LinkedIn: https://www.linkedin.com/in/albhide/

Join Dr. LL for a value-packed conversation with George Otel, founder of US Business Funding and a top commercial real estate influencer. George shares actionable insights for small business owners and entrepreneurs on funding, mindset, and building lasting success. Discover why adaptation, strategic learning, and the right financial moves can transform your business. Whether you're just starting or scaling up, this episode is your guide to smarter money decisions and entrepreneurial growth. Key Takeaways & Time Stamps: [1:13] Adapt to Thrive: George discusses the importance of adaptability in business, emphasizing that those who adapt faster and more efficiently gain the most benefits in today's fast-changing market. [3:11] Delegate and Plan: He shares how reading, journaling, and planning personal development in 6-12 month increments has helped him focus on strategic growth and effective delegation within his business.  [10:51] Always Seek Options: George explains the biggest financing mistake business owners make: relying solely on their local bank. He urges entrepreneurs to seek multiple funding options and start looking for financing before it's urgently needed. [13:05] Own, Don't Rent: He highlights how small business owners can use government-backed SBA loans to buy their business property, often for less than their current rent, building equity and long-term wealth. [21:15] Review and Refocus: George outlines his process of regularly reviewing what's working in his business, doubling down on successes, and cutting out what drains resources—advice that can dramatically improve any small business in just a few months. Listen in for practical strategies, real-world examples, and the mindset shifts every entrepreneur needs to succeed in finance, real estate, and beyond!

Join Dr. LL for a value-packed conversation with George Otel, founder of US Business Funding and a top commercial real estate influencer. George shares actionable insights for small business owners and entrepreneurs on funding, mindset, and building lasting success. Discover why adaptation, strategic learning, and the right financial moves can transform your business. Whether you're just starting or scaling up, this episode is your guide to smarter money decisions and entrepreneurial growth. Key Takeaways & Time Stamps: [1:13] Adapt to Thrive: George discusses the importance of adaptability in business, emphasizing that those who adapt faster and more efficiently gain the most benefits in today's fast-changing market. [3:11] Delegate and Plan: He shares how reading, journaling, and planning personal development in 6-12 month increments has helped him focus on strategic growth and effective delegation within his business.  [10:51] Always Seek Options: George explains the biggest financing mistake business owners make: relying solely on their local bank. He urges entrepreneurs to seek multiple funding options and start looking for financing before it's urgently needed. [13:05] Own, Don't Rent: He highlights how small business owners can use government-backed SBA loans to buy their business property, often for less than their current rent, building equity and long-term wealth. [21:15] Review and Refocus: George outlines his process of regularly reviewing what's working in his business, doubling down on successes, and cutting out what drains resources—advice that can dramatically improve any small business in just a few months. Listen in for practical strategies, real-world examples, and the mindset shifts every entrepreneur needs to succeed in finance, real estate, and beyond!

On this episode of Multifamily Mastery, John Casmon interviews George Otel, a commercial real estate finance expert and founder of US Business Funding. George shares his journey from the transportation industry into real estate, detailing his pivot into multifamily and ultimately commercial lending. He explains how his team works with over 1,000 lending sources, including private lenders, family offices, and funds, to help investors navigate complex financing scenarios—especially when traditional banks fall short. They discuss the importance of structuring deals creatively, moving fast on off-market opportunities, and the emerging landscape of business acquisitions as a wealth transfer looms. George Otel Current role: Founder, US Business Funding Say hi to them at: https://usbizfunding.net Get a 4-week trial, free postage, and a digital scale at ⁠https://www.stamps.com/cre⁠. Thanks to Stamps.com for sponsoring the show! Post your job for free at https://www.linkedin.com/BRE. Terms and conditions apply. Join the Best Ever Community  The Best Ever Community is live and growing - and we want serious commercial real estate investors like you inside. It's free to join, but you must apply and meet the criteria.  Connect with top operators, LPs, GPs, and more, get real insights, and be part of a curated network built to help you grow. Apply now at ⁠www.bestevercommunity.com⁠ Learn more about your ad choices. Visit megaphone.fm/adchoices

Unlocking New Financial Opportunities for Real Estate Investors with George Otel   Join Jen Josey, the founder of REIGN, as she interviews George Otel, an expert in real estate and business financing. George shares the nuances of securing funding for various real estate deals and small businesses, offers strategies for optimizing your business for sale, and discusses the booming service industry. Discover how to navigate funding challenges, find the best deals, and make the most of the current wealth transfer opportunities. Whether you're a seasoned investor or just starting out, this episode is packed with actionable advice to accelerate your growth and success.   00:00 Introduction to REIGN and Host Jen Josey 01:05 Today's Topic: The Importance of Exit Strategies 03:14 Guest Introduction: George Hotel 05:12 George's Journey into Real Estate and Finance 09:16 Understanding SBA Loans and Business Funding 19:24 Challenges and Success Stories in Business Financing 26:18 Funding Opportunities in Tough Times 27:02 Turnaround Time for Funding 28:40 Rewarding Aspects of Helping Business Owners 30:08 Buying Out Business Partners 32:41 Selling and Buying Businesses 36:52 Hot Business Opportunities 38:51 Advice and Insights from George 40:21 Conclusion and Contact Information   To learn more about Jen Josey, visit www.TheRealJenJosey.com To join REIGN, visit www.REIGNmastermind.com Stuff Jen Josey Loves: https://www.reignmastermind.com/resources Buy Jen Josey's Book: From Beginner to Badass: https://a.co/d/bstKlby  

In this episode of the Real Estate Pros podcast, host Dylan Silver interviews George Otel, an entrepreneur with over a decade of experience in real estate and commercial lending. George shares his journey from the trucking industry to real estate, discussing the importance of networking, the intricacies of the lending process, and the impact of technology on the industry. He emphasizes the significance of relationships in securing deals and offers valuable insights for newcomers in the real estate space. The conversation also touches on future trends in commercial real estate and the role of AI in shaping the industry.   Professional Real Estate Investors - How we can help you: Investor Fuel Mastermind:  Learn more about the Investor Fuel Mastermind, including 100% deal financing, massive discounts from vendors and sponsors you're already using, our world class community of over 150 members, and SO much more here: http://www.investorfuel.com/apply   Investor Machine Marketing Partnership:  Are you looking for consistent, high quality lead generation? Investor Machine is America's #1 lead generation service professional investors. Investor Machine provides true ‘white glove' support to help you build the perfect marketing plan, then we'll execute it for you…talking and working together on an ongoing basis to help you hit YOUR goals! Learn more here: http://www.investormachine.com   Coaching with Mike Hambright:  Interested in 1 on 1 coaching with Mike Hambright? Mike coaches entrepreneurs looking to level up, build coaching or service based businesses (Mike runs multiple 7 and 8 figure a year businesses), building a coaching program and more. Learn more here: https://investorfuel.com/coachingwithmike   Attend a Vacation/Mastermind Retreat with Mike Hambright: Interested in joining a “mini-mastermind” with Mike and his private clients on an upcoming “Retreat”, either at locations like Cabo San Lucas, Napa, Park City ski trip, Yellowstone, or even at Mike's East Texas “Big H Ranch”? Learn more here: http://www.investorfuel.com/retreat   Property Insurance: Join the largest and most investor friendly property insurance provider in 2 minutes. Free to join, and insure all your flips and rentals within minutes! There is NO easier insurance provider on the planet (turn insurance on or off in 1 minute without talking to anyone!), and there's no 15-30% agent mark up through this platform!  Register here: https://myinvestorinsurance.com/   New Real Estate Investors - How we can work together: Investor Fuel Club (Coaching and Deal Partner Community): Looking to kickstart your real estate investing career? Join our one of a kind Coaching Community, Investor Fuel Club, where you'll get trained by some of the best real estate investors in America, and partner with them on deals! You don't need $ for deals…we'll partner with you and hold your hand along the way! Learn More here: http://www.investorfuel.com/club   —--------------------

In this episode, Andrew Biggs interviews George Otel about business funding strategies. George shares why it's crucial to secure financing when your business is doing well, how to treat a line of credit like an insurance policy, and why building business credit early pays off in the long run.

David and Nick are joined by George Otel.  George discusses getting into financing commercial real estate and his business journey.  You can find George at https://www.linkedin.com/in/georgeotel/ and https://www.usbizfunding.net/  Shout out to MLVC for the great Theme Song!  You can find them at https://www.instagram.com/mlvc_91/  If you have questions for either Nick or David please contact us at: bucksandbrewsllc@gmail.com

Turizm Kafası (19 Nisan 2025) - Otel Yöneticilerinin Mutfaktaki Yardımcısı by Kafa Radyo

TÜRK MİSAFİRPERVERLİĞİ Sizlere Ord. Prof. Dr. Anna Masala'nın kendi ağzından Türk mutfağını ve Türk misafirperverliğini anlattığı bir anısını aktarmak istiyorum: “Yanlış hatırlamıyorsam tanıdığım bütün Türklerin evinde yemek yedim. Konya'da Selçuklu yemeği, Eskişehir'de Tatar yemeği yedim. Zenginlerin ve fakirlerin evinde kahvaltı ettim, öğle ve akşam yemekleri yedim. Bazen birbirleriyle aynı günde evlerine davet eden dostları kırmamak için üç kez akşam yemeği yediğim bile oldu. Türkiye'de misafirperverlik anlayışı çok farklıdır. Anadolu'da en fakir köylü bile tek tavuğunu misafiri için keser ve ona yedirir. Ben, dünyanın en iyi mutfaklarından biri olan Türk mutfağını ve Türk sofrasını çok severim. Her sofra bir gökkuşağı gibidir: altın renkli börekler, gümüş baklalar, yeşil kırmızı çoban salataları, beyaz peynirler, her çeşit et yemeği, imam bayıldı, pilavlar, fasulye, tarhana ve tatlılar... Bir kere Prof. Ziya Umur, Suha Umur ve eşleriyle birlikte Prof. Sahir Erman'ın misafiri oldum. Büyük bir otelin lokantasındaydık. Yemek çeşitleri gerçekten kırk bir miydi bilmem ama çok çeşitli vardı. O akşam “imam bayıldı” veya “hünkarbeğendi” gibi yemek adlarının anlamını çözdüm. Her birimiz için içinde gül yaprakları olan bir tasla ılık su ve muhteşem sıcak peçeteler geldi. Otel, o akşam gözümde âdeta bir Osmanlı sarayına dönüşüverdi. Türk misafirperverliği sadece yemeğe dayanmaz; sanırım sadece Türkiye'de “diş kirası” âdeti vardır. Yani misafirlere ev sahibi tarafından bir hediye verilir. Eski dönemlerde büyükler misafirlere altın para hediye ederlermiş. Şunu bilmelisiniz ki bir Türk'ün misafiri olursanız ondan mutlaka bir hediye alırsınız. Mesela bana, boncuklar, bilezikler, yemeniler, kıymetli kitaplar, el işçiliği tabaklar, gümüş bir ayna ve daha birçok güzel hediye verildi. Anadolu'da bazı köylerde misafir odalarında, işlemeli divanlar, yastıklar ve renk renk halılar arasında uyuduğum da olmuştur. Halının üzerinde bir tepsi, tepside çay, meyve ve fıstık görüntüsü unutamadığım anlar­dandır. Sabah erken saatte, namaz vaktinde, küçücük bir minareden gelen ezan sesleriyle ev halkı uyanır ve kahvaltı edilirdi. O köy evi de bir saray oluverirdi.

So you think Distributed Tracing is the new thing? Well - its not! But its never been as exciting as today!In this episode we combine 50 years of Distributed Tracing experience across our guests and hosts. We invited Christoph Neumueller and Thomas Rothschaedl who have seen the early days of agent-based instrumentation, how global standards like the W3C Trace Context allowed tracing to connect large enterprise systems and how OpenTelemetry is commoditizing data collection across all tech stacks.Tune in and learn about the difference between spans and traces, why collecting the data is only part of the story, how to combat the challenge when dealing with too much data and how traces relate and connect to logs, metrics and events.Links we discussedYouTube with Christoph: LINK WILL FOLLOW ONCE VIDEO IS POSTEDChristoph's LinkedIn: https://www.linkedin.com/in/christophneumueller/Thomas's LinkedIn: https://www.linkedin.com/in/rothschaedl/

In episode 79 of o11ycast, Hamel Husain joins the o11ycast crew to discuss the challenges of monitoring AI systems, why off-the-shelf metrics can be misleading, and how error analysis is the key to making AI models more reliable. Plus, insights into how Honeycomb built its Query Assistant and what teams should prioritize when working with AI observability.

In episode 79 of o11ycast, Hamel Husain joins the o11ycast crew to discuss the challenges of monitoring AI systems, why off-the-shelf metrics can be misleading, and how error analysis is the key to making AI models more reliable. Plus, insights into how Honeycomb built its Query Assistant and what teams should prioritize when working with AI observability.

Did you know that adding a simple Code Interpreter took o3 from 9.2% to 32% on FrontierMath? The Latent Space crew is hosting a hack night Feb 11th in San Francisco focused on CodeGen use cases, co-hosted with E2B and Edge AGI; watch E2B's new workshop and RSVP here!We're happy to announce that today's guest Samuel Colvin will be teaching his very first Pydantic AI workshop at the newly announced AI Engineer NYC Workshops day on Feb 22! 25 tickets left.If you're a Python developer, it's very likely that you've heard of Pydantic. Every month, it's downloaded >300,000,000 times, making it one of the top 25 PyPi packages. OpenAI uses it in its SDK for structured outputs, it's at the core of FastAPI, and if you've followed our AI Engineer Summit conference, Jason Liu of Instructor has given two great talks about it: “Pydantic is all you need” and “Pydantic is STILL all you need”. Now, Samuel Colvin has raised $17M from Sequoia to turn Pydantic from an open source project to a full stack AI engineer platform with Logfire, their observability platform, and PydanticAI, their new agent framework.Logfire: bringing OTEL to AIOpenTelemetry recently merged Semantic Conventions for LLM workloads which provides standard definitions to track performance like gen_ai.server.time_per_output_token. In Sam's view at least 80% of new apps being built today have some sort of LLM usage in them, and just like web observability platform got replaced by cloud-first ones in the 2010s, Logfire wants to do the same for AI-first apps. If you're interested in the technical details, Logfire migrated away from Clickhouse to Datafusion for their backend. We spent some time on the importance of picking open source tools you understand and that you can actually contribute to upstream, rather than the more popular ones; listen in ~43:19 for that part.Agents are the killer app for graphsPydantic AI is their attempt at taking a lot of the learnings that LangChain and the other early LLM frameworks had, and putting Python best practices into it. At an API level, it's very similar to the other libraries: you can call LLMs, create agents, do function calling, do evals, etc.They define an “Agent” as a container with a system prompt, tools, structured result, and an LLM. Under the hood, each Agent is now a graph of function calls that can orchestrate multi-step LLM interactions. You can start simple, then move toward fully dynamic graph-based control flow if needed.“We were compelled enough by graphs once we got them right that our agent implementation [...] is now actually a graph under the hood.”Why Graphs?* More natural for complex or multi-step AI workflows.* Easy to visualize and debug with mermaid diagrams.* Potential for distributed runs, or “waiting days” between steps in certain flows.In parallel, you see folks like Emil Eifrem of Neo4j talk about GraphRAG as another place where graphs fit really well in the AI stack, so it might be time for more people to take them seriously.Full Video EpisodeLike and subscribe!Chapters* 00:00:00 Introductions* 00:00:24 Origins of Pydantic* 00:05:28 Pydantic's AI moment * 00:08:05 Why build a new agents framework?* 00:10:17 Overview of Pydantic AI* 00:12:33 Becoming a believer in graphs* 00:24:02 God Model vs Compound AI Systems* 00:28:13 Why not build an LLM gateway?* 00:31:39 Programmatic testing vs live evals* 00:35:51 Using OpenTelemetry for AI traces* 00:43:19 Why they don't use Clickhouse* 00:48:34 Competing in the observability space* 00:50:41 Licensing decisions for Pydantic and LogFire* 00:51:48 Building Pydantic.run* 00:55:24 Marimo and the future of Jupyter notebooks* 00:57:44 London's AI sceneShow Notes* Sam Colvin* Pydantic* Pydantic AI* Logfire* Pydantic.run* Zod* E2B* Arize* Langsmith* Marimo* Prefect* GLA (Google Generative Language API)* OpenTelemetry* Jason Liu* Sebastian Ramirez* Bogomil Balkansky* Hood Chatham* Jeremy Howard* Andrew LambTranscriptAlessio [00:00:03]: Hey, everyone. Welcome to the Latent Space podcast. This is Alessio, partner and CTO at Decibel Partners, and I'm joined by my co-host Swyx, founder of Smol AI.Swyx [00:00:12]: Good morning. And today we're very excited to have Sam Colvin join us from Pydantic AI. Welcome. Sam, I heard that Pydantic is all we need. Is that true?Samuel [00:00:24]: I would say you might need Pydantic AI and Logfire as well, but it gets you a long way, that's for sure.Swyx [00:00:29]: Pydantic almost basically needs no introduction. It's almost 300 million downloads in December. And obviously, in the previous podcasts and discussions we've had with Jason Liu, he's been a big fan and promoter of Pydantic and AI.Samuel [00:00:45]: Yeah, it's weird because obviously I didn't create Pydantic originally for uses in AI, it predates LLMs. But it's like we've been lucky that it's been picked up by that community and used so widely.Swyx [00:00:58]: Actually, maybe we'll hear it. Right from you, what is Pydantic and maybe a little bit of the origin story?Samuel [00:01:04]: The best name for it, which is not quite right, is a validation library. And we get some tension around that name because it doesn't just do validation, it will do coercion by default. We now have strict mode, so you can disable that coercion. But by default, if you say you want an integer field and you get in a string of 1, 2, 3, it will convert it to 123 and a bunch of other sensible conversions. And as you can imagine, the semantics around it. Exactly when you convert and when you don't, it's complicated, but because of that, it's more than just validation. Back in 2017, when I first started it, the different thing it was doing was using type hints to define your schema. That was controversial at the time. It was genuinely disapproved of by some people. I think the success of Pydantic and libraries like FastAPI that build on top of it means that today that's no longer controversial in Python. And indeed, lots of other people have copied that route, but yeah, it's a data validation library. It uses type hints for the for the most part and obviously does all the other stuff you want, like serialization on top of that. But yeah, that's the core.Alessio [00:02:06]: Do you have any fun stories on how JSON schemas ended up being kind of like the structure output standard for LLMs? And were you involved in any of these discussions? Because I know OpenAI was, you know, one of the early adopters. So did they reach out to you? Was there kind of like a structure output console in open source that people were talking about or was it just a random?Samuel [00:02:26]: No, very much not. So I originally. Didn't implement JSON schema inside Pydantic and then Sebastian, Sebastian Ramirez, FastAPI came along and like the first I ever heard of him was over a weekend. I got like 50 emails from him or 50 like emails as he was committing to Pydantic, adding JSON schema long pre version one. So the reason it was added was for OpenAPI, which is obviously closely akin to JSON schema. And then, yeah, I don't know why it was JSON that got picked up and used by OpenAI. It was obviously very convenient for us. That's because it meant that not only can you do the validation, but because Pydantic will generate you the JSON schema, it will it kind of can be one source of source of truth for structured outputs and tools.Swyx [00:03:09]: Before we dive in further on the on the AI side of things, something I'm mildly curious about, obviously, there's Zod in JavaScript land. Every now and then there is a new sort of in vogue validation library that that takes over for quite a few years and then maybe like some something else comes along. Is Pydantic? Is it done like the core Pydantic?Samuel [00:03:30]: I've just come off a call where we were redesigning some of the internal bits. There will be a v3 at some point, which will not break people's code half as much as v2 as in v2 was the was the massive rewrite into Rust, but also fixing all the stuff that was broken back from like version zero point something that we didn't fix in v1 because it was a side project. We have plans to move some of the basically store the data in Rust types after validation. Not completely. So we're still working to design the Pythonic version of it, in order for it to be able to convert into Python types. So then if you were doing like validation and then serialization, you would never have to go via a Python type we reckon that can give us somewhere between three and five times another three to five times speed up. That's probably the biggest thing. Also, like changing how easy it is to basically extend Pydantic and define how particular types, like for example, NumPy arrays are validated and serialized. But there's also stuff going on. And for example, Jitter, the JSON library in Rust that does the JSON parsing, has SIMD implementation at the moment only for AMD64. So we can add that. We need to go and add SIMD for other instruction sets. So there's a bunch more we can do on performance. I don't think we're going to go and revolutionize Pydantic, but it's going to continue to get faster, continue, hopefully, to allow people to do more advanced things. We might add a binary format like CBOR for serialization for when you'll just want to put the data into a database and probably load it again from Pydantic. So there are some things that will come along, but for the most part, it should just get faster and cleaner.Alessio [00:05:04]: From a focus perspective, I guess, as a founder too, how did you think about the AI interest rising? And then how do you kind of prioritize, okay, this is worth going into more, and we'll talk about Pydantic AI and all of that. What was maybe your early experience with LLAMP, and when did you figure out, okay, this is something we should take seriously and focus more resources on it?Samuel [00:05:28]: I'll answer that, but I'll answer what I think is a kind of parallel question, which is Pydantic's weird, because Pydantic existed, obviously, before I was starting a company. I was working on it in my spare time, and then beginning of 22, I started working on the rewrite in Rust. And I worked on it full-time for a year and a half, and then once we started the company, people came and joined. And it was a weird project, because that would never go away. You can't get signed off inside a startup. Like, we're going to go off and three engineers are going to work full-on for a year in Python and Rust, writing like 30,000 lines of Rust just to release open-source-free Python library. The result of that has been excellent for us as a company, right? As in, it's made us remain entirely relevant. And it's like, Pydantic is not just used in the SDKs of all of the AI libraries, but I can't say which one, but one of the big foundational model companies, when they upgraded from Pydantic v1 to v2, their number one internal model... The metric of performance is time to first token. That went down by 20%. So you think about all of the actual AI going on inside, and yet at least 20% of the CPU, or at least the latency inside requests was actually Pydantic, which shows like how widely it's used. So we've benefited from doing that work, although it didn't, it would have never have made financial sense in most companies. In answer to your question about like, how do we prioritize AI, I mean, the honest truth is we've spent a lot of the last year and a half building. Good general purpose observability inside LogFire and making Pydantic good for general purpose use cases. And the AI has kind of come to us. Like we just, not that we want to get away from it, but like the appetite, uh, both in Pydantic and in LogFire to go and build with AI is enormous because it kind of makes sense, right? Like if you're starting a new greenfield project in Python today, what's the chance that you're using GenAI 80%, let's say, globally, obviously it's like a hundred percent in California, but even worldwide, it's probably 80%. Yeah. And so everyone needs that stuff. And there's so much yet to be figured out so much like space to do things better in the ecosystem in a way that like to go and implement a database that's better than Postgres is a like Sisyphean task. Whereas building, uh, tools that are better for GenAI than some of the stuff that's about now is not very difficult. Putting the actual models themselves to one side.Alessio [00:07:40]: And then at the same time, then you released Pydantic AI recently, which is, uh, um, you know, agent framework and early on, I would say everybody like, you know, Langchain and like, uh, Pydantic kind of like a first class support, a lot of these frameworks, we're trying to use you to be better. What was the decision behind we should do our own framework? Were there any design decisions that you disagree with any workloads that you think people didn't support? Well,Samuel [00:08:05]: it wasn't so much like design and workflow, although I think there were some, some things we've done differently. Yeah. I think looking in general at the ecosystem of agent frameworks, the engineering quality is far below that of the rest of the Python ecosystem. There's a bunch of stuff that we have learned how to do over the last 20 years of building Python libraries and writing Python code that seems to be abandoned by people when they build agent frameworks. Now I can kind of respect that, particularly in the very first agent frameworks, like Langchain, where they were literally figuring out how to go and do this stuff. It's completely understandable that you would like basically skip some stuff.Samuel [00:08:42]: I'm shocked by the like quality of some of the agent frameworks that have come out recently from like well-respected names, which it just seems to be opportunism and I have little time for that, but like the early ones, like I think they were just figuring out how to do stuff and just as lots of people have learned from Pydantic, we were able to learn a bit from them. I think from like the gap we saw and the thing we were frustrated by was the production readiness. And that means things like type checking, even if type checking makes it hard. Like Pydantic AI, I will put my hand up now and say it has a lot of generics and you need to, it's probably easier to use it if you've written a bit of Rust and you really understand generics, but like, and that is, we're not claiming that that makes it the easiest thing to use in all cases, we think it makes it good for production applications in big systems where type checking is a no-brainer in Python. But there are also a bunch of stuff we've learned from maintaining Pydantic over the years that we've gone and done. So every single example in Pydantic AI's documentation is run on Python. As part of tests and every single print output within an example is checked during tests. So it will always be up to date. And then a bunch of things that, like I say, are standard best practice within the rest of the Python ecosystem, but I'm not followed surprisingly by some AI libraries like coverage, linting, type checking, et cetera, et cetera, where I think these are no-brainers, but like weirdly they're not followed by some of the other libraries.Alessio [00:10:04]: And can you just give an overview of the framework itself? I think there's kind of like the. LLM calling frameworks, there are the multi-agent frameworks, there's the workflow frameworks, like what does Pydantic AI do?Samuel [00:10:17]: I glaze over a bit when I hear all of the different sorts of frameworks, but I like, and I will tell you when I built Pydantic, when I built Logfire and when I built Pydantic AI, my methodology is not to go and like research and review all of the other things. I kind of work out what I want and I go and build it and then feedback comes and we adjust. So the fundamental building block of Pydantic AI is agents. The exact definition of agents and how you want to define them. is obviously ambiguous and our things are probably sort of agent-lit, not that we would want to go and rename them to agent-lit, but like the point is you probably build them together to build something and most people will call an agent. So an agent in our case has, you know, things like a prompt, like system prompt and some tools and a structured return type if you want it, that covers the vast majority of cases. There are situations where you want to go further and the most complex workflows where you want graphs and I resisted graphs for quite a while. I was sort of of the opinion you didn't need them and you could use standard like Python flow control to do all of that stuff. I had a few arguments with people, but I basically came around to, yeah, I can totally see why graphs are useful. But then we have the problem that by default, they're not type safe because if you have a like add edge method where you give the names of two different edges, there's no type checking, right? Even if you go and do some, I'm not, not all the graph libraries are AI specific. So there's a, there's a graph library called, but it allows, it does like a basic runtime type checking. Ironically using Pydantic to try and make up for the fact that like fundamentally that graphs are not typed type safe. Well, I like Pydantic, but it did, that's not a real solution to have to go and run the code to see if it's safe. There's a reason that starting type checking is so powerful. And so we kind of, from a lot of iteration eventually came up with a system of using normally data classes to define nodes where you return the next node you want to call and where we're able to go and introspect the return type of a node to basically build the graph. And so the graph is. Yeah. Inherently type safe. And once we got that right, I, I wasn't, I'm incredibly excited about graphs. I think there's like masses of use cases for them, both in gen AI and other development, but also software's all going to have interact with gen AI, right? It's going to be like web. There's no longer be like a web department in a company is that there's just like all the developers are building for web building with databases. The same is going to be true for gen AI.Alessio [00:12:33]: Yeah. I see on your docs, you call an agent, a container that contains a system prompt function. Tools, structure, result, dependency type model, and then model settings. Are the graphs in your mind, different agents? Are they different prompts for the same agent? What are like the structures in your mind?Samuel [00:12:52]: So we were compelled enough by graphs once we got them right, that we actually merged the PR this morning. That means our agent implementation without changing its API at all is now actually a graph under the hood as it is built using our graph library. So graphs are basically a lower level tool that allow you to build these complex workflows. Our agents are technically one of the many graphs you could go and build. And we just happened to build that one for you because it's a very common, commonplace one. But obviously there are cases where you need more complex workflows where the current agent assumptions don't work. And that's where you can then go and use graphs to build more complex things.Swyx [00:13:29]: You said you were cynical about graphs. What changed your mind specifically?Samuel [00:13:33]: I guess people kept giving me examples of things that they wanted to use graphs for. And my like, yeah, but you could do that in standard flow control in Python became a like less and less compelling argument to me because I've maintained those systems that end up with like spaghetti code. And I could see the appeal of this like structured way of defining the workflow of my code. And it's really neat that like just from your code, just from your type hints, you can get out a mermaid diagram that defines exactly what can go and happen.Swyx [00:14:00]: Right. Yeah. You do have very neat implementation of sort of inferring the graph from type hints, I guess. Yeah. Is what I would call it. Yeah. I think the question always is I have gone back and forth. I used to work at Temporal where we would actually spend a lot of time complaining about graph based workflow solutions like AWS step functions. And we would actually say that we were better because you could use normal control flow that you already knew and worked with. Yours, I guess, is like a little bit of a nice compromise. Like it looks like normal Pythonic code. But you just have to keep in mind what the type hints actually mean. And that's what we do with the quote unquote magic that the graph construction does.Samuel [00:14:42]: Yeah, exactly. And if you look at the internal logic of actually running a graph, it's incredibly simple. It's basically call a node, get a node back, call that node, get a node back, call that node. If you get an end, you're done. We will add in soon support for, well, basically storage so that you can store the state between each node that's run. And then the idea is you can then distribute the graph and run it across computers. And also, I mean, the other weird, the other bit that's really valuable is across time. Because it's all very well if you look at like lots of the graph examples that like Claude will give you. If it gives you an example, it gives you this lovely enormous mermaid chart of like the workflow, for example, managing returns if you're an e-commerce company. But what you realize is some of those lines are literally one function calls another function. And some of those lines are wait six days for the customer to print their like piece of paper and put it in the post. And if you're writing like your demo. Project or your like proof of concept, that's fine because you can just say, and now we call this function. But when you're building when you're in real in real life, that doesn't work. And now how do we manage that concept to basically be able to start somewhere else in the in our code? Well, this graph implementation makes it incredibly easy because you just pass the node that is the start point for carrying on the graph and it continues to run. So it's things like that where I was like, yeah, I can just imagine how things I've done in the past would be fundamentally easier to understand if we had done them with graphs.Swyx [00:16:07]: You say imagine, but like right now, this pedantic AI actually resume, you know, six days later, like you said, or is this just like a theoretical thing we can go someday?Samuel [00:16:16]: I think it's basically Q&A. So there's an AI that's asking the user a question and effectively you then call the CLI again to continue the conversation. And it basically instantiates the node and calls the graph with that node again. Now, we don't have the logic yet for effectively storing state in the database between individual nodes that we're going to add soon. But like the rest of it is basically there.Swyx [00:16:37]: It does make me think that not only are you competing with Langchain now and obviously Instructor, and now you're going into sort of the more like orchestrated things like Airflow, Prefect, Daxter, those guys.Samuel [00:16:52]: Yeah, I mean, we're good friends with the Prefect guys and Temporal have the same investors as us. And I'm sure that my investor Bogomol would not be too happy if I was like, oh, yeah, by the way, as well as trying to take on Datadog. We're also going off and trying to take on Temporal and everyone else doing that. Obviously, we're not doing all of the infrastructure of deploying that right yet, at least. We're, you know, we're just building a Python library. And like what's crazy about our graph implementation is, sure, there's a bit of magic in like introspecting the return type, you know, extracting things from unions, stuff like that. But like the actual calls, as I say, is literally call a function and get back a thing and call that. It's like incredibly simple and therefore easy to maintain. The question is, how useful is it? Well, I don't know yet. I think we have to go and find out. We have a whole. We've had a slew of people joining our Slack over the last few days and saying, tell me how good Pydantic AI is. How good is Pydantic AI versus Langchain? And I refuse to answer. That's your job to go and find that out. Not mine. We built a thing. I'm compelled by it, but I'm obviously biased. The ecosystem will work out what the useful tools are.Swyx [00:17:52]: Bogomol was my board member when I was at Temporal. And I think I think just generally also having been a workflow engine investor and participant in this space, it's a big space. Like everyone needs different functions. I think the one thing that I would say like yours, you know, as a library, you don't have that much control of it over the infrastructure. I do like the idea that each new agents or whatever or unit of work, whatever you call that should spin up in this sort of isolated boundaries. Whereas yours, I think around everything runs in the same process. But you ideally want to sort of spin out its own little container of things.Samuel [00:18:30]: I agree with you a hundred percent. And we will. It would work now. Right. As in theory, you're just like as long as you can serialize the calls to the next node, you just have to all of the different containers basically have to have the same the same code. I mean, I'm super excited about Cloudflare workers running Python and being able to install dependencies. And if Cloudflare could only give me my invitation to the private beta of that, we would be exploring that right now because I'm super excited about that as a like compute level for some of this stuff where exactly what you're saying, basically. You can run everything as an individual. Like worker function and distribute it. And it's resilient to failure, et cetera, et cetera.Swyx [00:19:08]: And it spins up like a thousand instances simultaneously. You know, you want it to be sort of truly serverless at once. Actually, I know we have some Cloudflare friends who are listening, so hopefully they'll get in front of the line. Especially.Samuel [00:19:19]: I was in Cloudflare's office last week shouting at them about other things that frustrate me. I have a love-hate relationship with Cloudflare. Their tech is awesome. But because I use it the whole time, I then get frustrated. So, yeah, I'm sure I will. I will. I will get there soon.Swyx [00:19:32]: There's a side tangent on Cloudflare. Is Python supported at full? I actually wasn't fully aware of what the status of that thing is.Samuel [00:19:39]: Yeah. So Pyodide, which is Python running inside the browser in scripting, is supported now by Cloudflare. They basically, they're having some struggles working out how to manage, ironically, dependencies that have binaries, in particular, Pydantic. Because these workers where you can have thousands of them on a given metal machine, you don't want to have a difference. You basically want to be able to have a share. Shared memory for all the different Pydantic installations, effectively. That's the thing they work out. They're working out. But Hood, who's my friend, who is the primary maintainer of Pyodide, works for Cloudflare. And that's basically what he's doing, is working out how to get Python running on Cloudflare's network.Swyx [00:20:19]: I mean, the nice thing is that your binary is really written in Rust, right? Yeah. Which also compiles the WebAssembly. Yeah. So maybe there's a way that you'd build... You have just a different build of Pydantic and that ships with whatever your distro for Cloudflare workers is.Samuel [00:20:36]: Yes, that's exactly what... So Pyodide has builds for Pydantic Core and for things like NumPy and basically all of the popular binary libraries. Yeah. It's just basic. And you're doing exactly that, right? You're using Rust to compile the WebAssembly and then you're calling that shared library from Python. And it's unbelievably complicated, but it works. Okay.Swyx [00:20:57]: Staying on graphs a little bit more, and then I wanted to go to some of the other features that you have in Pydantic AI. I see in your docs, there are sort of four levels of agents. There's single agents, there's agent delegation, programmatic agent handoff. That seems to be what OpenAI swarms would be like. And then the last one, graph-based control flow. Would you say that those are sort of the mental hierarchy of how these things go?Samuel [00:21:21]: Yeah, roughly. Okay.Swyx [00:21:22]: You had some expression around OpenAI swarms. Well.Samuel [00:21:25]: And indeed, OpenAI have got in touch with me and basically, maybe I'm not supposed to say this, but basically said that Pydantic AI looks like what swarms would become if it was production ready. So, yeah. I mean, like, yeah, which makes sense. Awesome. Yeah. I mean, in fact, it was specifically saying, how can we give people the same feeling that they were getting from swarms that led us to go and implement graphs? Because my, like, just call the next agent with Python code was not a satisfactory answer to people. So it was like, okay, we've got to go and have a better answer for that. It's not like, let us to get to graphs. Yeah.Swyx [00:21:56]: I mean, it's a minimal viable graph in some sense. What are the shapes of graphs that people should know? So the way that I would phrase this is I think Anthropic did a very good public service and also kind of surprisingly influential blog post, I would say, when they wrote Building Effective Agents. We actually have the authors coming to speak at my conference in New York, which I think you're giving a workshop at. Yeah.Samuel [00:22:24]: I'm trying to work it out. But yes, I think so.Swyx [00:22:26]: Tell me if you're not. yeah, I mean, like, that was the first, I think, authoritative view of, like, what kinds of graphs exist in agents and let's give each of them a name so that everyone is on the same page. So I'm just kind of curious if you have community names or top five patterns of graphs.Samuel [00:22:44]: I don't have top five patterns of graphs. I would love to see what people are building with them. But like, it's been it's only been a couple of weeks. And of course, there's a point is that. Because they're relatively unopinionated about what you can go and do with them. They don't suit them. Like, you can go and do lots of lots of things with them, but they don't have the structure to go and have like specific names as much as perhaps like some other systems do. I think what our agents are, which have a name and I can't remember what it is, but this basically system of like, decide what tool to call, go back to the center, decide what tool to call, go back to the center and then exit. One form of graph, which, as I say, like our agents are effectively one implementation of a graph, which is why under the hood they are now using graphs. And it'll be interesting to see over the next few years whether we end up with these like predefined graph names or graph structures or whether it's just like, yep, I built a graph or whether graphs just turn out not to match people's mental image of what they want and die away. We'll see.Swyx [00:23:38]: I think there is always appeal. Every developer eventually gets graph religion and goes, oh, yeah, everything's a graph. And then they probably over rotate and go go too far into graphs. And then they have to learn a whole bunch of DSLs. And then they're like, actually, I didn't need that. I need this. And they scale back a little bit.Samuel [00:23:55]: I'm at the beginning of that process. I'm currently a graph maximalist, although I haven't actually put any into production yet. But yeah.Swyx [00:24:02]: This has a lot of philosophical connections with other work coming out of UC Berkeley on compounding AI systems. I don't know if you know of or care. This is the Gartner world of things where they need some kind of industry terminology to sell it to enterprises. I don't know if you know about any of that.Samuel [00:24:24]: I haven't. I probably should. I should probably do it because I should probably get better at selling to enterprises. But no, no, I don't. Not right now.Swyx [00:24:29]: This is really the argument is that instead of putting everything in one model, you have more control and more maybe observability to if you break everything out into composing little models and changing them together. And obviously, then you need an orchestration framework to do that. Yeah.Samuel [00:24:47]: And it makes complete sense. And one of the things we've seen with agents is they work well when they work well. But when they. Even if you have the observability through log five that you can see what was going on, if you don't have a nice hook point to say, hang on, this is all gone wrong. You have a relatively blunt instrument of basically erroring when you exceed some kind of limit. But like what you need to be able to do is effectively iterate through these runs so that you can have your own control flow where you're like, OK, we've gone too far. And that's where one of the neat things about our graph implementation is you can basically call next in a loop rather than just running the full graph. And therefore, you have this opportunity to to break out of it. But yeah, basically, it's the same point, which is like if you have two bigger unit of work to some extent, whether or not it involves gen AI. But obviously, it's particularly problematic in gen AI. You only find out afterwards when you've spent quite a lot of time and or money when it's gone off and done done the wrong thing.Swyx [00:25:39]: Oh, drop on this. We're not going to resolve this here, but I'll drop this and then we can move on to the next thing. This is the common way that we we developers talk about this. And then the machine learning researchers look at us. And laugh and say, that's cute. And then they just train a bigger model and they wipe us out in the next training run. So I think there's a certain amount of we are fighting the bitter lesson here. We're fighting AGI. And, you know, when AGI arrives, this will all go away. Obviously, on Latent Space, we don't really discuss that because I think AGI is kind of this hand wavy concept that isn't super relevant. But I think we have to respect that. For example, you could do a chain of thoughts with graphs and you could manually orchestrate a nice little graph that does like. Reflect, think about if you need more, more inference time, compute, you know, that's the hot term now. And then think again and, you know, scale that up. Or you could train Strawberry and DeepSeq R1. Right.Samuel [00:26:32]: I saw someone saying recently, oh, they were really optimistic about agents because models are getting faster exponentially. And I like took a certain amount of self-control not to describe that it wasn't exponential. But my main point was. If models are getting faster as quickly as you say they are, then we don't need agents and we don't really need any of these abstraction layers. We can just give our model and, you know, access to the Internet, cross our fingers and hope for the best. Agents, agent frameworks, graphs, all of this stuff is basically making up for the fact that right now the models are not that clever. In the same way that if you're running a customer service business and you have loads of people sitting answering telephones, the less well trained they are, the less that you trust them, the more that you need to give them a script to go through. Whereas, you know, so if you're running a bank and you have lots of customer service people who you don't trust that much, then you tell them exactly what to say. If you're doing high net worth banking, you just employ people who you think are going to be charming to other rich people and set them off to go and have coffee with people. Right. And the same is true of models. The more intelligent they are, the less we need to tell them, like structure what they go and do and constrain the routes in which they take.Swyx [00:27:42]: Yeah. Yeah. Agree with that. So I'm happy to move on. So the other parts of Pydantic AI that are worth commenting on, and this is like my last rant, I promise. So obviously, every framework needs to do its sort of model adapter layer, which is, oh, you can easily swap from OpenAI to Cloud to Grok. You also have, which I didn't know about, Google GLA, which I didn't really know about until I saw this in your docs, which is generative language API. I assume that's AI Studio? Yes.Samuel [00:28:13]: Google don't have good names for it. So Vertex is very clear. That seems to be the API that like some of the things use, although it returns 503 about 20% of the time. So... Vertex? No. Vertex, fine. But the... Oh, oh. GLA. Yeah. Yeah.Swyx [00:28:28]: I agree with that.Samuel [00:28:29]: So we have, again, another example of like, well, I think we go the extra mile in terms of engineering is we run on every commit, at least commit to main, we run tests against the live models. Not lots of tests, but like a handful of them. Oh, okay. And we had a point last week where, yeah, GLA is a little bit better. GLA1 was failing every single run. One of their tests would fail. And we, I think we might even have commented out that one at the moment. So like all of the models fail more often than you might expect, but like that one seems to be particularly likely to fail. But Vertex is the same API, but much more reliable.Swyx [00:29:01]: My rant here is that, you know, versions of this appear in Langchain and every single framework has to have its own little thing, a version of that. I would put to you, and then, you know, this is, this can be agree to disagree. This is not needed in Pydantic AI. I would much rather you adopt a layer like Lite LLM or what's the other one in JavaScript port key. And that's their job. They focus on that one thing and they, they normalize APIs for you. All new models are automatically added and you don't have to duplicate this inside of your framework. So for example, if I wanted to use deep seek, I'm out of luck because Pydantic AI doesn't have deep seek yet.Samuel [00:29:38]: Yeah, it does.Swyx [00:29:39]: Oh, it does. Okay. I'm sorry. But you know what I mean? Should this live in your code or should it live in a layer that's kind of your API gateway that's a defined piece of infrastructure that people have?Samuel [00:29:49]: And I think if a company who are well known, who are respected by everyone had come along and done this at the right time, maybe we should have done it a year and a half ago and said, we're going to be the universal AI layer. That would have been a credible thing to do. I've heard varying reports of Lite LLM is the truth. And it didn't seem to have exactly the type safety that we needed. Also, as I understand it, and again, I haven't looked into it in great detail. Part of their business model is proxying the request through their, through their own system to do the generalization. That would be an enormous put off to an awful lot of people. Honestly, the truth is I don't think it is that much work unifying the model. I get where you're coming from. I kind of see your point. I think the truth is that everyone is centralizing around open AIs. Open AI's API is the one to do. So DeepSeq support that. Grok with OK support that. Ollama also does it. I mean, if there is that library right now, it's more or less the open AI SDK. And it's very high quality. It's well type checked. It uses Pydantic. So I'm biased. But I mean, I think it's pretty well respected anyway.Swyx [00:30:57]: There's different ways to do this. Because also, it's not just about normalizing the APIs. You have to do secret management and all that stuff.Samuel [00:31:05]: Yeah. And there's also. There's Vertex and Bedrock, which to one extent or another, effectively, they host multiple models, but they don't unify the API. But they do unify the auth, as I understand it. Although we're halfway through doing Bedrock. So I don't know about it that well. But they're kind of weird hybrids because they support multiple models. But like I say, the auth is centralized.Swyx [00:31:28]: Yeah, I'm surprised they don't unify the API. That seems like something that I would do. You know, we can discuss all this all day. There's a lot of APIs. I agree.Samuel [00:31:36]: It would be nice if there was a universal one that we didn't have to go and build.Alessio [00:31:39]: And I guess the other side of, you know, routing model and picking models like evals. How do you actually figure out which one you should be using? I know you have one. First of all, you have very good support for mocking in unit tests, which is something that a lot of other frameworks don't do. So, you know, my favorite Ruby library is VCR because it just, you know, it just lets me store the HTTP requests and replay them. That part I'll kind of skip. I think you are busy like this test model. We're like just through Python. You try and figure out what the model might respond without actually calling the model. And then you have the function model where people can kind of customize outputs. Any other fun stories maybe from there? Or is it just what you see is what you get, so to speak?Samuel [00:32:18]: On those two, I think what you see is what you get. On the evals, I think watch this space. I think it's something that like, again, I was somewhat cynical about for some time. Still have my cynicism about some of the well, it's unfortunate that so many different things are called evals. It would be nice if we could agree. What they are and what they're not. But look, I think it's a really important space. I think it's something that we're going to be working on soon, both in Pydantic AI and in LogFire to try and support better because it's like it's an unsolved problem.Alessio [00:32:45]: Yeah, you do say in your doc that anyone who claims to know for sure exactly how your eval should be defined can safely be ignored.Samuel [00:32:52]: We'll delete that sentence when we tell people how to do their evals.Alessio [00:32:56]: Exactly. I was like, we need we need a snapshot of this today. And so let's talk about eval. So there's kind of like the vibe. Yeah. So you have evals, which is what you do when you're building. Right. Because you cannot really like test it that many times to get statistical significance. And then there's the production eval. So you also have LogFire, which is kind of like your observability product, which I tried before. It's very nice. What are some of the learnings you've had from building an observability tool for LEMPs? And yeah, as people think about evals, even like what are the right things to measure? What are like the right number of samples that you need to actually start making decisions?Samuel [00:33:33]: I'm not the best person to answer that is the truth. So I'm not going to come in here and tell you that I think I know the answer on the exact number. I mean, we can do some back of the envelope statistics calculations to work out that like having 30 probably gets you most of the statistical value of having 200 for, you know, by definition, 15% of the work. But the exact like how many examples do you need? For example, that's a much harder question to answer because it's, you know, it's deep within the how models operate in terms of LogFire. One of the reasons we built LogFire the way we have and we allow you to write SQL directly against your data and we're trying to build the like powerful fundamentals of observability is precisely because we know we don't know the answers. And so allowing people to go and innovate on how they're going to consume that stuff and how they're going to process it is we think that's valuable. Because even if we come along and offer you an evals framework on top of LogFire, it won't be right in all regards. And we want people to be able to go and innovate and being able to write their own SQL connected to the API. And effectively query the data like it's a database with SQL allows people to innovate on that stuff. And that's what allows us to do it as well. I mean, we do a bunch of like testing what's possible by basically writing SQL directly against LogFire as any user could. I think the other the other really interesting bit that's going on in observability is OpenTelemetry is centralizing around semantic attributes for GenAI. So it's a relatively new project. A lot of it's still being added at the moment. But basically the idea that like. They unify how both SDKs and or agent frameworks send observability data to to any OpenTelemetry endpoint. And so, again, we can go and having that unification allows us to go and like basically compare different libraries, compare different models much better. That stuff's in a very like early stage of development. One of the things we're going to be working on pretty soon is basically, I suspect, GenAI will be the first agent framework that implements those semantic attributes properly. Because, again, we control and we can say this is important for observability, whereas most of the other agent frameworks are not maintained by people who are trying to do observability. With the exception of Langchain, where they have the observability platform, but they chose not to go down the OpenTelemetry route. So they're like plowing their own furrow. And, you know, they're a lot they're even further away from standardization.Alessio [00:35:51]: Can you maybe just give a quick overview of how OTEL ties into the AI workflows? There's kind of like the question of is, you know, a trace. And a span like a LLM call. Is it the agent? It's kind of like the broader thing you're tracking. How should people think about it?Samuel [00:36:06]: Yeah, so they have a PR that I think may have now been merged from someone at IBM talking about remote agents and trying to support this concept of remote agents within GenAI. I'm not particularly compelled by that because I don't think that like that's actually by any means the common use case. But like, I suppose it's fine for it to be there. The majority of the stuff in OTEL is basically defining how you would instrument. A given call to an LLM. So basically the actual LLM call, what data you would send to your telemetry provider, how you would structure that. Apart from this slightly odd stuff on remote agents, most of the like agent level consideration is not yet implemented in is not yet decided effectively. And so there's a bit of ambiguity. Obviously, what's good about OTEL is you can in the end send whatever attributes you like. But yeah, there's quite a lot of churn in that space and exactly how we store the data. I think that one of the most interesting things, though, is that if you think about observability. Traditionally, it was sure everyone would say our observability data is very important. We must keep it safe. But actually, companies work very hard to basically not have anything that sensitive in their observability data. So if you're a doctor in a hospital and you search for a drug for an STI, the sequel might be sent to the observability provider. But none of the parameters would. It wouldn't have the patient number or their name or the drug. With GenAI, that distinction doesn't exist because it's all just messed up in the text. If you have that same patient asking an LLM how to. What drug they should take or how to stop smoking. You can't extract the PII and not send it to the observability platform. So the sensitivity of the data that's going to end up in observability platforms is going to be like basically different order of magnitude to what's in what you would normally send to Datadog. Of course, you can make a mistake and send someone's password or their card number to Datadog. But that would be seen as a as a like mistake. Whereas in GenAI, a lot of data is going to be sent. And I think that's why companies like Langsmith and are trying hard to offer observability. On prem, because there's a bunch of companies who are happy for Datadog to be cloud hosted, but want self-hosted self-hosting for this observability stuff with GenAI.Alessio [00:38:09]: And are you doing any of that today? Because I know in each of the spans you have like the number of tokens, you have the context, you're just storing everything. And then you're going to offer kind of like a self-hosting for the platform, basically. Yeah. Yeah.Samuel [00:38:23]: So we have scrubbing roughly equivalent to what the other observability platforms have. So if we, you know, if we see password as the key, we won't send the value. But like, like I said, that doesn't really work in GenAI. So we're accepting we're going to have to store a lot of data and then we'll offer self-hosting for those people who can afford it and who need it.Alessio [00:38:42]: And then this is, I think, the first time that most of the workloads performance is depending on a third party. You know, like if you're looking at Datadog data, usually it's your app that is driving the latency and like the memory usage and all of that. Here you're going to have spans that maybe take a long time to perform because the GLA API is not working or because OpenAI is kind of like overwhelmed. Do you do anything there since like the provider is almost like the same across customers? You know, like, are you trying to surface these things for people and say, hey, this was like a very slow span, but actually all customers using OpenAI right now are seeing the same thing. So maybe don't worry about it or.Samuel [00:39:20]: Not yet. We do a few things that people don't generally do in OTA. So we send. We send information at the beginning. At the beginning of a trace as well as sorry, at the beginning of a span, as well as when it finishes. By default, OTA only sends you data when the span finishes. So if you think about a request which might take like 20 seconds, even if some of the intermediate spans finished earlier, you can't basically place them on the page until you get the top level span. And so if you're using standard OTA, you can't show anything until those requests are finished. When those requests are taking a few hundred milliseconds, it doesn't really matter. But when you're doing Gen AI calls or when you're like running a batch job that might take 30 minutes. That like latency of not being able to see the span is like crippling to understanding your application. And so we've we do a bunch of slightly complex stuff to basically send data about a span as it starts, which is closely related. Yeah.Alessio [00:40:09]: Any thoughts on all the other people trying to build on top of OpenTelemetry in different languages, too? There's like the OpenLEmetry project, which doesn't really roll off the tongue. But how do you see the future of these kind of tools? Is everybody going to have to build? Why does everybody want to build? They want to build their own open source observability thing to then sell?Samuel [00:40:29]: I mean, we are not going off and trying to instrument the likes of the OpenAI SDK with the new semantic attributes, because at some point that's going to happen and it's going to live inside OTEL and we might help with it. But we're a tiny team. We don't have time to go and do all of that work. So OpenLEmetry, like interesting project. But I suspect eventually most of those semantic like that instrumentation of the big of the SDKs will live, like I say, inside the main OpenTelemetry report. I suppose. What happens to the agent frameworks? What data you basically need at the framework level to get the context is kind of unclear. I don't think we know the answer yet. But I mean, I was on the, I guess this is kind of semi-public, because I was on the call with the OpenTelemetry call last week talking about GenAI. And there was someone from Arize talking about the challenges they have trying to get OpenTelemetry data out of Langchain, where it's not like natively implemented. And obviously they're having quite a tough time. And I was realizing, hadn't really realized this before, but how lucky we are to primarily be talking about our own agent framework, where we have the control rather than trying to go and instrument other people's.Swyx [00:41:36]: Sorry, I actually didn't know about this semantic conventions thing. It looks like, yeah, it's merged into main OTel. What should people know about this? I had never heard of it before.Samuel [00:41:45]: Yeah, I think it looks like a great start. I think there's some unknowns around how you send the messages that go back and forth, which is kind of the most important part. It's the most important thing of all. And that is moved out of attributes and into OTel events. OTel events in turn are moving from being on a span to being their own top-level API where you send data. So there's a bunch of churn still going on. I'm impressed by how fast the OTel community is moving on this project. I guess they, like everyone else, get that this is important, and it's something that people are crying out to get instrumentation off. So I'm kind of pleasantly surprised at how fast they're moving, but it makes sense.Swyx [00:42:25]: I'm just kind of browsing through the specification. I can already see that this basically bakes in whatever the previous paradigm was. So now they have genai.usage.prompt tokens and genai.usage.completion tokens. And obviously now we have reasoning tokens as well. And then only one form of sampling, which is top-p. You're basically baking in or sort of reifying things that you think are important today, but it's not a super foolproof way of doing this for the future. Yeah.Samuel [00:42:54]: I mean, that's what's neat about OTel is you can always go and send another attribute and that's fine. It's just there are a bunch that are agreed on. But I would say, you know, to come back to your previous point about whether or not we should be relying on one centralized abstraction layer, this stuff is moving so fast that if you start relying on someone else's standard, you risk basically falling behind because you're relying on someone else to keep things up to date.Swyx [00:43:14]: Or you fall behind because you've got other things going on.Samuel [00:43:17]: Yeah, yeah. That's fair. That's fair.Swyx [00:43:19]: Any other observations just about building LogFire, actually? Let's just talk about this. So you announced LogFire. I was kind of only familiar with LogFire because of your Series A announcement. I actually thought you were making a separate company. I remember some amount of confusion with you when that came out. So to be clear, it's Pydantic LogFire and the company is one company that has kind of two products, an open source thing and an observability thing, correct? Yeah. I was just kind of curious, like any learnings building LogFire? So classic question is, do you use ClickHouse? Is this like the standard persistence layer? Any learnings doing that?Samuel [00:43:54]: We don't use ClickHouse. We started building our database with ClickHouse, moved off ClickHouse onto Timescale, which is a Postgres extension to do analytical databases. Wow. And then moved off Timescale onto DataFusion. And we're basically now building, it's DataFusion, but it's kind of our own database. Bogomil is not entirely happy that we went through three databases before we chose one. I'll say that. But like, we've got to the right one in the end. I think we could have realized that Timescale wasn't right. I think ClickHouse. They both taught us a lot and we're in a great place now. But like, yeah, it's been a real journey on the database in particular.Swyx [00:44:28]: Okay. So, you know, as a database nerd, I have to like double click on this, right? So ClickHouse is supposed to be the ideal backend for anything like this. And then moving from ClickHouse to Timescale is another counterintuitive move that I didn't expect because, you know, Timescale is like an extension on top of Postgres. Not super meant for like high volume logging. But like, yeah, tell us those decisions.Samuel [00:44:50]: So at the time, ClickHouse did not have good support for JSON. I was speaking to someone yesterday and said ClickHouse doesn't have good support for JSON and got roundly stepped on because apparently it does now. So they've obviously gone and built their proper JSON support. But like back when we were trying to use it, I guess a year ago or a bit more than a year ago, everything happened to be a map and maps are a pain to try and do like looking up JSON type data. And obviously all these attributes, everything you're talking about there in terms of the GenAI stuff. You can choose to make them top level columns if you want. But the simplest thing is just to put them all into a big JSON pile. And that was a problem with ClickHouse. Also, ClickHouse had some really ugly edge cases like by default, or at least until I complained about it a lot, ClickHouse thought that two nanoseconds was longer than one second because they compared intervals just by the number, not the unit. And I complained about that a lot. And then they caused it to raise an error and just say you have to have the same unit. Then I complained a bit more. And I think as I understand it now, they have some. They convert between units. But like stuff like that, when all you're looking at is when a lot of what you're doing is comparing the duration of spans was really painful. Also things like you can't subtract two date times to get an interval. You have to use the date sub function. But like the fundamental thing is because we want our end users to write SQL, the like quality of the SQL, how easy it is to write, matters way more to us than if you're building like a platform on top where your developers are going to write the SQL. And once it's written and it's working, you don't mind too much. So I think that's like one of the fundamental differences. The other problem that I have with the ClickHouse and Impact Timescale is that like the ultimate architecture, the like snowflake architecture of binary data in object store queried with some kind of cache from nearby. They both have it, but it's closed sourced and you only get it if you go and use their hosted versions. And so even if we had got through all the problems with Timescale or ClickHouse, we would end up like, you know, they would want to be taking their 80% margin. And then we would be wanting to take that would basically leave us less space for margin. Whereas data fusion. Properly open source, all of that same tooling is open source. And for us as a team of people with a lot of Rust expertise, data fusion, which is implemented in Rust, we can literally dive into it and go and change it. So, for example, I found that there were some slowdowns in data fusion's string comparison kernel for doing like string contains. And it's just Rust code. And I could go and rewrite the string comparison kernel to be faster. Or, for example, data fusion, when we started using it, didn't have JSON support. Obviously, as I've said, it's something we can do. It's something we needed. I was able to go and implement that in a weekend using our JSON parser that we built for Pydantic Core. So it's the fact that like data fusion is like for us the perfect mixture of a toolbox to build a database with, not a database. And we can go and implement stuff on top of it in a way that like if you were trying to do that in Postgres or in ClickHouse. I mean, ClickHouse would be easier because it's C++, relatively modern C++. But like as a team of people who are not C++ experts, that's much scarier than data fusion for us.Swyx [00:47:47]: Yeah, that's a beautiful rant.Alessio [00:47:49]: That's funny. Most people don't think they have agency on these projects. They're kind of like, oh, I should use this or I should use that. They're not really like, what should I pick so that I contribute the most back to it? You know, so but I think you obviously have an open source first mindset. So that makes a lot of sense.Samuel [00:48:05]: I think if we were probably better as a startup, a better startup and faster moving and just like headlong determined to get in front of customers as fast as possible, we should have just started with ClickHouse. I hope that long term we're in a better place for having worked with data fusion. We like we're quite engaged now with the data fusion community. Andrew Lam, who maintains data fusion, is an advisor to us. We're in a really good place now. But yeah, it's definitely slowed us down relative to just like building on ClickHouse and moving as fast as we can.Swyx [00:48:34]: OK, we're about to zoom out and do Pydantic run and all the other stuff. But, you know, my last question on LogFire is really, you know, at some point you run out sort of community goodwill just because like, oh, I use Pydantic. I love Pydantic. I'm going to use LogFire. OK, then you start entering the territory of the Datadogs, the Sentrys and the honeycombs. Yeah. So where are you going to really spike here? What differentiator here?Samuel [00:48:59]: I wasn't writing code in 2001, but I'm assuming that there were people talking about like web observability and then web observability stopped being a thing, not because the web stopped being a thing, but because all observability had to do web. If you were talking to people in 2010 or 2012, they would have talked about cloud observability. Now that's not a term because all observability is cloud first. The same is going to happen to gen AI. And so whether or not you're trying to compete with Datadog or with Arise and Langsmith, you've got to do first class. You've got to do general purpose observability with first class support for AI. And as far as I know, we're the only people really trying to do that. I mean, I think Datadog is starting in that direction. And to be honest, I think Datadog is a much like scarier company to compete with than the AI specific observability platforms. Because in my opinion, and I've also heard this from lots of customers, AI specific observability where you don't see everything else going on in your app is not actually that useful. Our hope is that we can build the first general purpose observability platform with first class support for AI. And that we have this open source heritage of putting developer experience first that other companies haven't done. For all I'm a fan of Datadog and what they've done. If you search Datadog logging Python. And you just try as a like a non-observability expert to get something up and running with Datadog and Python. It's not trivial, right? That's something Sentry have done amazingly well. But like there's enormous space in most of observability to do DX better.Alessio [00:50:27]: Since you mentioned Sentry, I'm curious how you thought about licensing and all of that. Obviously, your MIT license, you don't have any rolling license like Sentry has where you can only use an open source, like the one year old version of it. Was that a hard decision?Samuel [00:50:41]: So to be clear, LogFire is co-sourced. So Pydantic and Pydantic AI are MIT licensed and like properly open source. And then LogFire for now is completely closed source. And in fact, the struggles that Sentry have had with licensing and the like weird pushback the community gives when they take something that's closed source and make it source available just meant that we just avoided that whole subject matter. I think the other way to look at it is like in terms of either headcount or revenue or dollars in the bank. The amount of open source we do as a company is we've got to be open source. We're up there with the most prolific open source companies, like I say, per head. And so we didn't feel like we were morally obligated to make LogFire open source. We have Pydantic. Pydantic is a foundational library in Python. That and now Pydantic AI are our contribution to open source. And then LogFire is like openly for profit, right? As in we're not claiming otherwise. We're not sort of trying to walk a line if it's open source. But really, we want to make it hard to deploy. So you probably want to pay us. We're trying to be straight. That it's to pay for. We could change that at some point in the future, but it's not an immediate plan.Alessio [00:51:48]: All right. So the first one I saw this new I don't know if it's like a product you're building the Pydantic that run, which is a Python browser sandbox. What was the inspiration behind that? We talk a lot about code interpreter for lamps. I'm an investor in a company called E2B, which is a code sandbox as a service for remote execution. Yeah. What's the Pydantic that run story?Samuel [00:52:09]: So Pydantic that run is again completely open source. I have no interest in making it into a product. We just needed a sandbox to be able to demo LogFire in particular, but also Pydantic AI. So it doesn't have it yet, but I'm going to add basically a proxy to OpenAI and the other models so that you can run Pydantic AI in the browser. See how it works. Tweak the prompt, et cetera, et cetera. And we'll have some kind of limit per day of what you can spend on it or like what the spend is. The other thing we wanted to b

Çalar Saat, samimi ve dürüst habercilik anlayışıyla Türkiye'nin dört bir yanından derlediği haberleri izleyicilerle buluşturup ülkenin nabzını tutmaya devam ediyor. Türkiye'nin lider sabah haber programı Çalar Saat NOW'da! Bizi sosyal medyadan takip edin: Facebook: https://www.facebook.com/nowhaber Twitter: http://www.twitter.com/NOWhaber Instagram: https://www.instagram.com/nowhaber.tr/ Podcast: https://anchor.fm/now-haber

Kartalkaya'da bir kayak merkezinde bulunan otelde çıkan korkunç yangında 36'sı çocuk 78 kişi hayatını yitirdi. Türkiye günlerdir kurbanlar için yas tutuyor. Altı savcı, yangının çıkma sebebini ve olası ihmalleri ortaya çıkarmak için soruşturma başlattı. Otelin sahibi tutuklandı. Ailelerin yok olduğu bu felaket neden yaşandı? Türkiye'de yangına karşı bina güvenliği nasıl düzenleniyor ve denetleniyor? 19 Mayıs Üniversitesi Öğretim Üyesi ve Afet Yönetimi Uzmanı Prof. Afşin Ahmet Kaya ile konuştuk. Mikrofonda Gökçe Göksu ve Elmas Topcu var. Von Gökce Göksu.

Günün en sıcak ve çarpıcı gelişmelerini bulabileceğiniz; güvenilir, tarafsız ve kaliteli haberin adresi NOW Ana Haber; deneyimli gazeteci Selçuk Tepeli'nin sunumuyla izleyicileriyle buluşuyor. Sıradanlaşmış bültenlerden çok daha farklı, interaktif bir sunum ile izleyiciye aktarılan NOW Ana Haber, her gün 19.00'da NOW'da! Bizi sosyal medyadan takip edin: X: https://twitter.com/nowhaber Facebook: https://www.facebook.com/nowhaber.tr Instagram: https://www.instagram.com/nowhaber.tr/ Podcast: https://anchor.fm/now-haber

Bolu'da her yıl on binlerce kişiyi ağırlayan Kartalkaya Kayak Merkezi'ndeki Grand Kartal Otel yangınında 76 kişi hayatını kaybetti, onlarca kişi yaralandı. Belki de yüzlerce ailenin evine ateş düştü. Bu, Türkiye tarihinde kayıtlara geçen en ölümcül otel yangınlarından biri oldu. Yangının üzerinden en az 30 saat geçti, cevapsız pek çok soru var. Senem Görür Yücel canlı yayında uzman konuklarıyla değerlendirecek. Göksel Göksu, Bolu-Kartalkaya'dan izlenimlerini aktaracak. Learn more about your ad choices. Visit megaphone.fm/adchoices

For the past 10 years Anton has been working at Booking.com - one of the leading digital travel companies based out of Amsterdam. The journey that started as System Administrator has led Anton to be an Engineering Manager for Site Reliability where over the past 3 years he led the rollout and adoption of OpenTelemetry as the standard for getting observability into new cloud native deployments.Tune in and learn how Anton saw R&D grow from 300 to 2000, why they replaced their home-grown Perl-based Observability Framework with OpenTelemetry, how they tackle adoption challenges and how they extend and contribute back to the open source communityLinks we discussed:Anton's LinkedIn Profile: https://www.linkedin.com/in/antontimofieiev/Observability & SRE Summit: https://www.iqpc.com/events-observability-sre-summit/speakers/anton-timofieievOpenTelemetry: https://opentelemetry.io/

Adıyaman'daki İsias Otel'inde 6 Şubat depreminde hayatını kaybeden KKTC'li 35 çocuğun ailelerinin kurduğu Şampiyon Melekleri Yaşatma Derneği'nin başkanı Ruşen Yücesoylu Karakaya ile bir araya geliyoruz.

AWS Morning Brief for the week of December 2, with Corey Quinn. Links:Amazon CloudWatch adds context to observability data in service consoles, accelerating analysisAmazon Cognito introduces Managed Login to support rich branding for end user journeysAmazon Cognito now supports passwordless authentication for low-friction and secure loginsAmazon Connect Email is now generally availableAmazon EBS announces Time-based Copy for EBS SnapshotsAmazon EC2 Auto Scaling introduces highly responsive scaling policiesAmazon EC2 Capacity Blocks now supports instant start times and extensionsAmazon ECR announces 10x increase in repository limit to 100,000Amazon EFS now supports up to 2.5 million IOPS per file systemAmazon S3 now supports enforcement of conditional write operations for S3 general purpose bucketsApplication Signals provides OTEL support via X-Ray OTLP endpoint for tracesAWS delivers enhanced root cause insights to help explain cost anomaliesEnhanced Pricing Calculator now supports discounts and purchase commitments (in preview)AWS PrivateLink now supports cross-region connectivityAnnouncing the new AWS User Notifications SDKAnnouncing new feature tiers: Essentials and Plus for Amazon CognitoAnnouncing Savings Plans Purchase AnalyzerData Exports for FOCUS 1.0 is now in general availabilityIntroducing a new experience for AWS Systems ManagerIntroducing generative AI troubleshooting for Apache Spark in AWS Glue (preview)Understanding how certain database parameters impact scaling in Amazon Aurora Serverless v2Analyzing your AWS Cost Explorer data with Amazon Q Developer: Now Generally AvailableYour guide to AWS for Advertising & Marketing at re:Invent 2024AWS IoT Services alignment with US Cyber Trust MarkStreamlining AWS Organizations Cleanup StrategiesSponsorWiz: wiz.io/lastweek

Hans Kristian is a Platform Engineer for NAV's Kubernetes Platform Nais hosting Norway's wellfare services. With 10 years on Kubernetes, 2000 apps and 1000 developers across more than 100 teams there was a need to make OpenTelemetry adoption as easy as possible.Tune in as we hear from Hans Kristian who is also a CNCF Ambassador and hosts Cloud Native Day Bergen why OpenTelemetry is chosen by the public sector, why it took much longer to adopt, which challenges they had to scale the observability backend and how they are tackling the "noisy data problem"Links we discussed in the episodeFollow Hans Kristian on LinkedIn: https://www.linkedin.com/in/hansflaatten/From 0 to 100 OTel Blog: https://nais.io/blog/posts/otel-from-0-to-100/?foo=barCloud Native Day Bergen: https://2024.cloudnativebergen.dev/Public Money, Public Code. How we open source everything we do! (https://m.youtube.com/watch?v=4v05Huy2mlw&pp=ygUkT3BlbiBzb3VyY2Ugb3BlbiBnb3Zlcm5tZW50IGZsYWF0dGVu)State of Platform Engineering in Norway (https://m.youtube.com/watch?v=3WFZhETlS9s&pp=ygUYc3RhdGUgb2YgcGxhdGZvcm0gbm9yd2F5)

OTEL Universe and OTEL Videos join us as we kick off Florida. Meet four of their video guests through their music.Bill Ricci with The Dutchman's CurveHighway Jones with Rock and Roll DressJinxx with Come AwayVibe- It Don't Matter

We dropping H's like it's the 20'S! Wanna go stay in a potato Otel? Ow bout we go to Ave a nice Wine Ike trough te Trail? Best trails to go to on vacation!

Requesting more CPU for your database used to take 6 months of planning 20 years ago. Now it takes the execution of a Terraform script. What has stayed the same all those years is Almudena Vivanco's passion for performance engineering to keep systems optimized. Ensuring that systems are available, scalable and resilient even during spike events such as the upcoming Euro Cup or any holiday specials.Tune in and hear from Almudena, who is currently working for SCRM Lidl, on how moving to the cloud gave new justification to performance engineering. She explains the importance of connecting business with service level objectives and gives insights on how Lidl makes sure to sell 50000 pieces of pork without breaking the cloud bankHere the additional links we discussedSlides from Barcelona Meetup: https://docs.google.com/presentation/d/1h83V4gUyqAmIWeAAtKb4BcRvuJV-XirLk-9Xq077nbwVideo from TestCon: https://www.youtube.com/watch?v=rIP_G-YBy04LinkedIn: https://www.linkedin.com/in/almudenavivanco/

In this compelling episode, we sit down with Ben Reinhart who shares his journey of transitioning from the JavaScript ecosystem, specifically migrating off of Next.js and Vercel, to Elixir and Phoenix, with Fly.io as the new host. Ben discusses his frustrations with the complexity and performance issues he faced, and how the switch to Elixir helped streamline operations and improve the efficiency of his AI-focused product at Axflow. He delves into his strategic choice for leveraging the operational simplicity and real-time features of Phoenix, while also acknowledging trade-offs such as rebuilding front-end components. Join us to explore Ben's story, learn about the features of Elixir that helped him, and discover how the move has influenced Axflow's path towards finding product-market fit, and more! Show Notes online - http://podcast.thinkingelixir.com/195 (http://podcast.thinkingelixir.com/195) Elixir Community News - Update on the phoenixlivereload package to v1.5 containing useful tips. - https://www.elixirstreams.com/tips/streamserverlogstoconsole (https://www.elixirstreams.com/tips/stream_server_logs_to_console?utm_source=thinkingelixir&utm_medium=shownotes) – Tips on how to stream Elixir server logs to the browser console. - https://github.com/phoenixframework/phoenixlivereload?tab=readme-ov-file#streaming-serving-logs-to-the-web-console (https://github.com/phoenixframework/phoenix_live_reload?tab=readme-ov-file#streaming-serving-logs-to-the-web-console?utm_source=thinkingelixir&utm_medium=shownotes) – Documentation on streaming Elixir server logs to the web console using phoenixlivereload v1.5. - Advise to change Appearance theme to "Dark" in the browser console for better readability of debug-level messages. - https://github.com/phoenixframework/phoenixlivereload?tab=readme-ov-file#jumping-to-heex-function-definitions (https://github.com/phoenixframework/phoenix_live_reload?tab=readme-ov-file#jumping-to-heex-function-definitions?utm_source=thinkingelixir&utm_medium=shownotes) – Information on the new feature "Jumping to HEEx function definitions" in phoenixlivereload v1.5. - https://blog.appsignal.com/2024/03/19/direct-file-uploads-to-amazon-s3-with-phoenix-liveview.html (https://blog.appsignal.com/2024/03/19/direct-file-uploads-to-amazon-s3-with-phoenix-liveview.html?utm_source=thinkingelixir&utm_medium=shownotes) – A new blog post by Joshua Plique about uploading files directly to S3 using Phoenix LiveView. - https://hexdocs.pm/phoenixliveview/uploads-external.html (https://hexdocs.pm/phoenix_live_view/uploads-external.html?utm_source=thinkingelixir&utm_medium=shownotes) – Official Phoenix documentation on direct file uploads to external services like S3. - https://x.com/whatyouhide/status/1768345597369532660 (https://x.com/whatyouhide/status/1768345597369532660?utm_source=thinkingelixir&utm_medium=shownotes) – Andrea Leopardi working on integrating Open Telemetry (OTel) with Sentry for the Elixir SDK. - https://github.com/getsentry/sentry-elixir/issues/538 (https://github.com/getsentry/sentry-elixir/issues/538?utm_source=thinkingelixir&utm_medium=shownotes) – A Github issue discussing the integration of OTel with Sentry's Elixir SDK. - https://twitter.com/TylerAYoung/status/1769741350126149857 (https://twitter.com/TylerAYoung/status/1769741350126149857?utm_source=thinkingelixir&utm_medium=shownotes) – Tyler Young's tip for keeping Elixir tests running faster and asynchronously by using the Process dictionary instead of Application environment. - https://saltycrackers.dev/posts/bye-bye-async-false/ (https://saltycrackers.dev/posts/bye-bye-async-false/?utm_source=thinkingelixir&utm_medium=shownotes) – An article discussing how to avoid async false in tests by using the Process dictionary. - https://github.com/jbsf2/process-tree (https://github.com/jbsf2/process-tree?utm_source=thinkingelixir&utm_medium=shownotes) – Introduction of a new Elixir library, ProcessTree, to navigate the process ancestry hierarchy and aid in better test configuration. - Advice on using the process dictionary check only in MIX_ENV=test to prevent runtime overhead in production. Do you have some Elixir news to share? Tell us at @ThinkingElixir (https://twitter.com/ThinkingElixir) or email at show@thinkingelixir.com (mailto:show@thinkingelixir.com) Discussion Resources - https://axflow.dev/ (https://axflow.dev/?utm_source=thinkingelixir&utm_medium=shownotes) - https://twitter.com/benjreinhart/status/1758616465589014531 (https://twitter.com/benjreinhart/status/1758616465589014531?utm_source=thinkingelixir&utm_medium=shownotes) - https://exercism.org/tracks/elixir (https://exercism.org/tracks/elixir?utm_source=thinkingelixir&utm_medium=shownotes) - https://www.youtube.com/watch?v=JvBT4XBdoUE (https://www.youtube.com/watch?v=JvBT4XBdoUE?utm_source=thinkingelixir&utm_medium=shownotes) - https://www.typescriptlang.org/ (https://www.typescriptlang.org/?utm_source=thinkingelixir&utm_medium=shownotes) - https://nextjs.org/ (https://nextjs.org/?utm_source=thinkingelixir&utm_medium=shownotes) - https://vercel.com/ (https://vercel.com/?utm_source=thinkingelixir&utm_medium=shownotes) - https://supabase.com/ (https://supabase.com/?utm_source=thinkingelixir&utm_medium=shownotes) - https://remix.run/ (https://remix.run/?utm_source=thinkingelixir&utm_medium=shownotes) - https://inertiajs.com/ (https://inertiajs.com/?utm_source=thinkingelixir&utm_medium=shownotes) - https://vitejs.dev/ (https://vitejs.dev/?utm_source=thinkingelixir&utm_medium=shownotes) - https://github.com/fidr/phoenixlivereact (https://github.com/fidr/phoenix_live_react?utm_source=thinkingelixir&utm_medium=shownotes) - https://github.com/geolessel/react-phoenix (https://github.com/geolessel/react-phoenix?utm_source=thinkingelixir&utm_medium=shownotes) - https://www.pinterest.com/ (https://www.pinterest.com/?utm_source=thinkingelixir&utm_medium=shownotes) - https://fly.io/docs/gpus/ (https://fly.io/docs/gpus/?utm_source=thinkingelixir&utm_medium=shownotes) Guest Information - https://twitter.com/benjreinhart (https://twitter.com/benjreinhart?utm_source=thinkingelixir&utm_medium=shownotes) – Ben on Twitter - https://twitter.com/axflow_dev (https://twitter.com/axflow_dev?utm_source=thinkingelixir&utm_medium=shownotes) – AxFlow on Twitter - https://github.com/benjreinhart/ (https://github.com/benjreinhart/?utm_source=thinkingelixir&utm_medium=shownotes) – on Github - https://benreinhart.com/ (https://benreinhart.com/?utm_source=thinkingelixir&utm_medium=shownotes) – Blog - https://axflow.dev/ (https://axflow.dev/?utm_source=thinkingelixir&utm_medium=shownotes) – AxFlow Website Find us online - Message the show - @ThinkingElixir (https://twitter.com/ThinkingElixir) - Message the show on Fediverse - @ThinkingElixir@genserver.social (https://genserver.social/ThinkingElixir) - Email the show - show@thinkingelixir.com (mailto:show@thinkingelixir.com) - Mark Ericksen - @brainlid (https://twitter.com/brainlid) - Mark Ericksen on Fediverse - @brainlid@genserver.social (https://genserver.social/brainlid) - David Bernheisel - @bernheisel (https://twitter.com/bernheisel) - David Bernheisel on Fediverse - @dbern@genserver.social (https://genserver.social/dbern) - Cade Ward - @cadebward (https://twitter.com/cadebward) - Cade Ward on Fediverse - @cadebward@genserver.social (https://genserver.social/cadebward)