Podcasts about ci cd

SUMMARY: As tools like Mythos create new AI-cybersecurity concerns, CIOs and CISOs need to be prepared for two challenges: Security Remediation and Patch to Production. SHOW: 1037SHOW TRANSCRIPT: The Enterprise AI Show #1037 TranscriptSHOW VIDEO: https://youtu.be/H5KxoiEIfUoSHOW SPONSORS:Nasuni - Activate your data for AI and request a demoOutShift by Cisco - “Scaling Out Superintelligence”  The Internet of Cognition architectureShareGate - ShareGate Protect. Microsoft 365 Governance, we got this!SHOW NOTES:Project Lightwell (Red Hat and IBM)Athena (Chainguard)Anthropic Project GlasswingOpenAI GPT 5.5-CyberTHESIS: Major initiatives are forming to help enterprise organizations combat security vulnerability threats found or created using new AI-cyber tools such as Anthropic Mythos. What are the key considerations, and what additional steps do organizations need to take to be advantaged by these capabilities? Part 1The Breaking Point and the Mythos MomentThe scope of open source security and supportPatches, disclosures and upstream open sourceClearinghouses, EOs, Laws and CommunitiesRemediation - Build vs. BuyPart 2How fast can you get from Patch to Production?Mitigation before patchingFast path and stable patch pipelines?Automation in patching vs. automation in deploymentFEEDBACK?Email: show @ the enterprise ai show dot comeBluesky: @TheEntAIShow.bsky.socialTwitter/X: @TheEntAIShowInstagram: @TheEntAIShow

Sam Newman is the author of "Building Microservices" and "Monolith to Microservices", two of the most influential books on distributed systems design. He is an independent consultant and former ThoughtWorks technologist, he has spent decades helping organizations worldwide decompose monoliths, adopt cloud and CI/CD practices, and reason clearly about service boundaries. He is one of the most recognized voices on microservices and software architecture in the industry. So is AI really replacing software architects? Find out what Dave Farley and Sam Newman think about that in this episode of " The Engineering Room".-------------------------------------------------------------------------------Only Patreon supporters get to see the full length video episodes of "The Engineering Room” Sign up here: https://www.patreon.com/c/continuousdeliverySam Newman on "X" (formerly "Twitter"): https://x.com/samnewman?lang=en

OpenChoreo is an opinionated, “batteries included”, AI-native Kubernetes platform stack for Platform Engineers that combines GitOps, Observability, AI Agents, and Workflows into a custom K8s distribution “super pack” that is managed via Backstage, CLI, API, or MCP. Now a CNCF project.Check out the video podcast version here: 

In this sponsored episode, James Wilson chats with SpecterOps CTO Jared Atkinson about the central role that GitHub has played in recent supply chain compromises. GitHub is where code gets built, tested, and shipped to devices, cloud, and on-prem environments. Understanding the paths an attacker can use to get into GitHub, and where they can pivot to from there, is essential to securing your GitHub repos and CI/CD pipelines. Show notes

As AI becomes increasingly capable of generating code, many developers are asking the wrong question. Instead of asking whether AI will replace developers, a better question is: What skills become more valuable when code generation becomes easier? The answer may be AI Deployment Ownership. About Jason Sherman Jason Sherman is a serial entrepreneur, filmmaker, author, and technology founder best known for building practical solutions that bridge the gap between emerging technology and real-world business problems. He is the founder and CEO of Vengo AI and has launched multiple technology platforms throughout his entrepreneurial career. Jason is known for his direct, hands-on approach to innovation, focusing on execution, product development, AI implementation, and helping businesses leverage technology without losing sight of operational realities. His perspective combines startup experience, software development expertise, product strategy, and a strong belief that technology should solve actual business problems rather than chase trends. Links: Facebook, Twitter / X, YouTube, LinkedIn, Website AI Deployment Ownership Changes the Developer Role Historically, many developers focused on implementation. Their value came from translating requirements into working code. Today, AI can assist with much of that work. That shifts responsibility upward. Developers are increasingly expected to understand: Architecture Infrastructure Security Deployment Automation The ability to oversee an entire system becomes more important than writing every line manually. Insight: AI raises the importance of systems thinking. Why Building Is No Longer Enough Many AI-created applications work perfectly in development environments. Production introduces a different reality. Organizations need: Monitoring Logging Security controls CI/CD pipelines Recovery procedures These are areas where experience matters significantly. An application that functions correctly in a demo environment may fail quickly when exposed to real-world usage patterns. AI Deployment Ownership Requires Infrastructure Knowledge One of the strongest themes from the conversation was ownership. Developers who understand deployment gain an advantage by moving beyond simple application development. Key capabilities include: Server management API security Automated deployments Version control workflows Environment management These responsibilities cannot be delegated entirely to AI. Action: Learn how applications move from development into production. The Rise of the Technical Operator The next generation of developers may resemble technical operators rather than pure coders. Their responsibilities include: Reviewing AI output Managing architecture Protecting infrastructure Maintaining reliability This shift mirrors previous technology transitions. Tools become easier. Responsibility becomes greater. AI Deployment Ownership Creates Career Protection Developers concerned about long-term career relevance should focus on areas where judgment matters. AI can generate code. It cannot reliably assume accountability. Organizations still need professionals who can: Evaluate tradeoffs Assess risks Make deployment decisions Own outcomes That ownership creates value. Conclusion The future belongs to developers who understand entire systems rather than individual code files. AI Deployment Ownership represents a practical path forward for developers looking to remain relevant in an increasingly automated environment. Stay Connected: Join the Developreneur Community

Josh welcomes back François Proulx to talk about the absolute madness in the CI/CD universe right now. We also learn about François' new project SmokedMeat which is a tool to help you hack your own CI/CD. When Josh spoke to François a year ago, the world was a very different place than it is today. François has a ton of knowledge about how we got here and what we can do moving forward. Boost Security has a bunch of amazing open source tools François built that can help keep CI/CD systems understood and locked down. The show notes and blog post for this episode can be found at https://opensourcesecurity.io/2026/2026-06-françois-smoked-meat/

Send us Fan MailYour software is only as trustworthy as the dependencies you quietly inherit and attackers know it. Today I break down the NCSC warning on software supply chain security and why open source package ecosystems have become a high-value target for real-world compromises that spread fast through CI/CD pipelines.I walk through the attack patterns that keep showing up in incidents: maintainer account compromise, expired domain takeover, typosquatting, and credential chaining. We connect each technique to the CISSP mindset so you can spot it in scenario questions and, more importantly, recognise it in your own environment. Along the way, I explain why Node.js, Python, and Rust projects are especially exposed, how automation can turn “latest version” convenience into an enterprise incident, and why developer environments often become an overlooked attack surface.Then we get practical with controls you can actually implement: pausing automatic dependency updates when compromise is suspected, adding human approval for critical packages, rotating credentials immediately, enforcing MFA on developer and registry accounts, and using private or trusted registries to mirror and vet dependencies. I also zoom out to show how to build supply chain security into the secure SDLC with software composition analysis (SCA), code signing, checksum verification, audit logging, continuous monitoring, and an SBOM so you can respond fast when a package turns toxic.If this helps you tighten your dependency management and level up your CISSP prep, subscribe, share this with a teammate, and leave a quick review so more security pros can find the show.Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox!  Don't miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success. Join now and start your journey toward CISSP mastery today!

Mike & Tommy dive into CI/CD automation with agents in Microsoft Fabric, exploring how agentic workflows are reshaping deployment pipelines, whether AI-driven deployments introduce more speed or more risk, and what guardrails teams need before letting agents touch production workspaces.https://github.com/microsoft/fabric-task-flowshttps://learn.microsoft.com/en-us/fabric/cicd/deployment-pipelines/get-started-with-deployment-pipelines?tabs=from-fabric%2Cnew-uihttps://learn.microsoft.com/en-us/fabric/cicd/variable-library/get-started-variable-libraries?tabs=home-pagehttps://github.com/mattpocock/skills/blob/main/skills/productivity/handoff/SKILL.mdGet in touch:Send in your questions or topics you want us to discuss by tweeting to @PowerBITips with the hashtag #empMailbag or submit on the PowerBI.tips Podcast Page.Visit PowerBI.tips: https://powerbi.tips/Watch the episodes live every Tuesday and Thursday morning at 730am CST on YouTube: https://www.youtube.com/powerbitipsSubscribe on Spotify: https://open.spotify.com/show/230fp78XmHHRXTiYICRLVvSubscribe on Apple: https://podcasts.apple.com/us/podcast/explicit-measures-podcast/id1568944083‎Check Out Community Jam: https://jam.powerbi.tipsFollow Mike: https://www.linkedin.com/in/michaelcarlo/Follow Tommy: https://www.linkedin.com/in/tommypuglia/

For twenty years the security playbook started in the same place, find a vulnerability, prioritize it, and patch it. Doug Merritt, CEO of Aviatrix and former CEO of Splunk, thinks that playbook is quietly breaking, and his explanation has nothing to do with anyone being careless. The economics of offense changed underneath us, and most security programs are still funded as if they did not.Why this conversation mattersDoug has sat in two seats that give this argument weight. At Splunk he evangelized detect and respond, and now at Aviatrix he is arguing that detect and respond, while still important, is no longer enough on its own. That is not a vendor pivot so much as an honest reading of the incentives, and it lands differently coming from someone who built a business on the previous era. If you are a practitioner watching AI rewrite the attacker's cost curve, or a leader trying to defend a prevention-heavy budget to a board, this conversation reframes where the money should actually go.Key takeawaysOffense became a compute problem, and that is permanent. Finding and exploiting a vulnerability is a search task, and the cost per token has been deflating faster than Moore's Law. That is why this is a structural shift rather than a few headline demos, and why throwing compute at offense keeps getting cheaper and faster.Patching has a ceiling that offense does not. Every patch carries the risk of breaking something, so testing, deployment, and organizational friction cap how fast defenders can move. When vulnerability discovery scales freely and patching cannot, "find more and patch faster" turns into a race you are structurally set up to lose.The interesting question is not how they got in, it is where they went. Attackers increasingly arrive with valid credentials and move through the trust graph that runs across cloud services and CI/CD pipelines, including malware injected into trusted repositories. Once they look legitimate inside the environment, lateral movement and egress are where the real damage happens.Cloud rewarded velocity, and security paid the bill. Cloud providers made identity default-deny because someone has to own and pay for a workload, but they left networking wide open because their economic engine is developer velocity and security reads as friction. New agentic frameworks inherit that same wide-open default, connected to the internet with little oversight.A strong identity stance is necessary and not sufficient. Identity answers whether someone is allowed to act, not whether the action is an attack, which is why attackers log in rather than hack in. Human, agent, and workload identities are genuinely different, and workload identity in particular has been underserved.Containment is about blast radius, not about keeping everyone out. The mindset shift is to accept that breaches will occur and to govern every path a workload can take, so an incident stays local and recoverable. Done well, containment holds firm whether or not anyone has detected the attack yet.Blast radius has to become a boardroom metric. Doug's argument is that CISOs, CIOs, CEOs, and boards should be able to answer how reachable anything is from anything else, and treat that number as something to drive down deliberately rather than discover after an incident.AI is the reason containment is finally workable. The historic blocker to micro-segmentation was cognitive load across tens or hundreds of thousands of workloads. AI is strong at synthesis and pattern matching, which makes a staged path of observe, discover, monitor, and then enforce realistic, ideally starting with the internet-exposed workloads that have no filtering at all.

Are you ready to adapt to the rapidly evolving rules of software development? In this deep dive, Logan Kilpatrick, Director and Engineer at Google DeepMind, breaks down how AI agents, advanced model-product symbiosis, and tools like Gemini 3.5 Flash are fundamentally shifting the engineering bottleneck. Learn how to maintain your competitive advantage by moving beyond the keyboard to focus on problem-solving, architectural taste, and system understanding.In this video, we cover:The changing role of the IDE and the rise of agent managers in code generation.Overcoming team bottlenecks in code review and CI/CD test execution execution loops.Why "agent coverage" and context integration are the next big tech stack metrics.Building a bulletproof software portfolio through permissionless open-source contributions.The critical difference between outsourcing intelligence versus outsourcing understanding.This episode is for software engineers, tech leads, and computer science students looking to future-proof their careers and reset their ambitions in the era of autonomous engineering agents.Timestamps:#SoftwareEngineering #AIAgents #GoogleDeepMind

I'm excited to work with Microsoft once again as the presenting sponsors of the AI Engineer World's Fair! We'll streaming live from MS Build today for a special crossover pod with our friends at No Priors and the one and only Satya Nadella. However we did not hold back with this interview - we asked all the burning questions about uptime and Copilot that we know you have in your minds. Lets go!For almost two decades, GitHub has been the home of software, where both open source and closed flow, through commits, pull requests, reviews, actions, etc.This ecosystem flourished as open-source maintainers and contributors would continue shipping code for the benefit of the community. However as coding agents began to ship mass quantities of code - growing 1400% in 2026, it marked a new era that was both extremely exciting and challenging for GitHub.While these agents help more people ship more projects, they also significantly increase the floor of how much code is shipped, how often it is shipped, how many people commit code, and basically orders of magnitude multiples in every dimension of GitHub infrastructure:Now GitHub inevitably experiences more pressure on their infrastructure which was originally designed around human developers moving at human speed. This has resulted in a very publicly notable uptime story:So it begs the question of whether current systems around code can absorb what AI produces. Can CI/CD keep up when every idea becomes a build? Can open source maintainers survive floods of AI-generated slop contributions? Can GitHub preserve the human social contract of software while becoming the operating layer for agents?Which brings us to the perfect person to answer these questions: GitHub COO Kyle Daigle. In this episode, he joins swyx to unpack what happens when AI doesn't just autocomplete code, but starts changing how companies operate, how open source works, how pull requests get reviewed, and how GitHub itself has to scale. We go deep on GitHub's internal AI workflows: micro-skills, WorkIQ, MCP, Slack, Teams, email, Copilot workflows, the new Copilot desktop app, CLI, cloud agents, and how Kyle uses agents to look backwards across company context before deciding what to do next. Kyle also reflects on GitHub's history building webhooks, APIs, Actions, npm, Dependabot, and Semmle, why the AI era is breaking GitHub in new ways, how Actions became a general-purpose compute layer, and what Copilot becomes after code completion.Full Video PodWe discuss:* Kyle's expanded role across GitHub* How AI got Kyle coding again after years in leadership* Why GitHub rolls out AI through existing workflows instead of forcing new tools* WorkIQ, MCP, Slack, Teams, email, and GitHub as company context* Why massive “mega-skills” are giving way to small, atomic micro-skills* How AI changes summarization, communications, marketing, and analyst work* Why former developers in leadership may have a unique advantage in the AI era* Kyle's “15 agents on Saturday” workflow* How Kyle built an AI-generated executive presentation for CRO/CFO teams* Why AI changes the chief of staff role without removing the human work* GitHub Actions, webhooks, arbitrary code execution, and secure agent compute* The npm acquisition, supply-chain security, 2FA, and token invalidation* Slop forks, vendoring, and whether AI agents change dependency management* What pull requests become when most PRs come from agents* Prompt requests, vouching, AI review, and trust in open source* What counts as a “developer” when AI lowers the barrier to building* GitHub Spark, low-code, and why GitHub refuses to hide the code* 14x commit growth, Actions load, databases, monorepos, and availability* Copilot's evolution from completion to CLI, desktop app, cloud agents, and SDK* Context, memory, rules, and making GitHub “act like Kyle wants it to act”* Ambient AI, OpenClaw, enterprise security, and the new operating system for agents* What swyx should ask Satya Nadella about Microsoft's AI futureKyle Daigle* LinkedIn: https://www.linkedin.com/in/kyledaigle* X: https://x.com/kdaigleTimestamps00:00:00 Introduction00:03:36 Why AI Got Kyle Coding Again00:07:04 Running GitHub with AI: WorkIQ, MCP, Slack, Teams, and Skills00:15:39 The Golden Age for Former Developers in Leadership00:17:31 15 Agents on Saturday and AI-Generated Executive Work00:20:20 How AI Changes the Chief of Staff Role00:21:45 GitHub's History: Actions, npm, Webhooks, and Open Source00:28:45 Slop Forks, Vendoring, and AI Dependency Management00:33:57 Pull Requests, Prompt Requests, and Trust in Agent-Generated Code00:41:21 GitHub Stars, 200M+ Developers, and the New AI Builder Wave00:45:15 GitHub Spark, Low-Code, and Why GitHub Still Shows the Code00:47:38 GitHub's Hardest Era: 14x Growth, Reliability, and Scale00:59:21 Actions as the Compute Layer for CI/CD and Automation01:02:04 The State and Future of GitHub Copilot01:08:24 Ambient AI, Background Agents, and the Future of the SDLC01:13:09 OpenClaw, Enterprise Security, and the New OS for Agents01:18:03 Build Announcements, WorkIQ, FoundryIQ, and Microsoft Context01:21:41 What Should swyx Ask Satya?TranscriptIntroduction: Kyle Daigle's Expanded Role at GitHub and MicrosoftSwyx [00:00:00]: We're here with Kyle Daigle, COO of GitHub. Welcome.Kyle [00:00:07]: Hey, thanks for having me.Swyx [00:00:08]: You're not just CEO of GitHub. People know you as that. You have a new role.Kyle [00:00:11]: So I have an expanded role now. I've been working at GitHub for thirteen years and doing all things developer. Joined as a developer myself. And now, I'm also responsible as the CMO of Developer for Microsoft. And so all the kind of learnings and passion for developers and how we work with them and how we communicate and how we bring our products to market, we're also bringing that expertise to the broader Microsoft ecosystem and helping every developer that uses a Microsoft product or would like to have a sort of similar experience that they've had with GitHub over the years. So it's a different role in some ways, but it's also just building on the experience that I've had at GitHub of just sort of tell the truth, be authentic, show people how to use it and then let the products speak for themselves. Now just doing that with, all of Microsoft.Swyx [00:01:09]: We'll be releasing this in conjunction with Build. You got lots of stuff planned, and we can sort of touch on that whenever it's appropriate. I think one of the interesting things is I rarely meet a COO who's also a CMO. I think you're a very outward facing and you're very confident publicly. That's rare. Do you actually view yourself as COO? What's What is your thing?From GitHub Developer to COO/CMO: Building the Platform and Operating GitHubKyle [00:01:33]: I think for me, it's been funny. The titles have always been, a— have always felt a little strange to me. I joined GitHub as a developer? I wrote so much of theSwyx [00:01:46]: Let's bring that up. You wrote the back ends?Kyle [00:01:48]: I was going through, I was going through, some old photos, when folks were talking about how things were being built or how there was a build GitHub. I built, webhooks and worked with teams building the API, built the platform layer. Anything that integrated with GitHub, up until really twenty eighteen, I built or ran the engineering teams. And that's kind of where my the beginning of my passion always was helping people build things, deliver them to, their customers. And so being a developer, building for developers was always super unique. In a— I think as my role expanded, it became my ability to talk to not just developers, but also enterprise customers or business leaders and have this translation layer. And then through all those years, GitHub has always operated pretty uniquely. Post-pandemic, working remotely was not as novel as it was when GitHub started in two thousand and eight. But all that expertise of running remote teams, doing it well, became this sort of bigger role, ultimately turning into the COO role of how do we operate GitHub in the way that GitHub's always operated after the Microsoft acquisition. And kind of so on from there. So like for me, I think the— I've, I still code. I love coding but the problem has always been, people. It's a much harder problem to both support our own employees, a harder problem to communicate to developers and enterprise buyers what we're building why it matters, ‘cause those are two very different messages. And so getting to work in the mix of COO, CMO, also just being a dev, I think is what's kept me at GitHub for so long.AI Workflows for Leadership: Commits, Retrospectives, and ContextSwyx [00:03:40]: Apparently, you have— your commits have gone up. What's this? What's going on?Kyle [00:03:45]: Rui's called me out pretty aggressively. So I think— as you can imagine, right, you can see my normal era of being a dev In the twenty thirteen, twenty fourteen era, and then moving into management, and then ultimately the COO role. I think what you see there is me, really getting back to coding thanks to AI. I— similar to, attaching problems between how to market and how to operate a business and how to code, I find, building agents and workflows that are connecting very disparate problems to be what's driving this. So that's, some of it's writing software. A lot of it is, connecting a ton of a different data sources to, help me out. But that is completely me really diving in on the AI side in trying out our tools, trying out everyone's tools, But building for me, building for the non-technical leader, though I'm technical and how we're, able to use these tools more than just the simple, call and response that I think a lot of the non-technical, your employers, you have to get— you have to use AI, and so everyone uses, ChatGPT or Copilot or Claude or whatever. To really get into, how is this going to help me out, it— I find that it's not the I need to write a blog post, I need to those simple examples. Helping people find the workflows of, “Okay, I need you to go through all the PRs today. I need you to go through everything that we've posted online. I need you to go through what we did the last three months. Go through all of my Obsidian notes for any mentions of this then go through my transcripts at work.” We use, Teams, so, using WorkIQ, go call that MCP server, grab all the transcripts, go through all the Slack, and then build me out the plan of, what this week's messaging actually was. That's something that was, impossible because for me, I find AI in a what most of this launch here is actually, less building forward. It's actually, a recursive loop backwards. I'm always looking at what had happened first. Go back through the week and tell me what we did, what worked, what didn't work? And then tell me in the next three or four days-What would you tweak based on this sort of like looking backwards and then looking ahead a little bit? I find that to be so much more valuable, especially for like non-technical, because that retrospection is actually LLMs are very good at that. Like finding all the patterns, pulling them out, and then applying that retrospection to just a couple of days or just like a short period of time. Is all a bunch of apps that I've built and launched a bunch of, internal tools. I use the new, GitHub Copilot app, the desktop app with workflows. Every time I crack open my laptop, it's running workflows for me. It's just a ton of different stuff and of course, it all ends up on, it all ends up on GitHub.Swyx [00:06:47]: Of course. That's where, that's where, stuff is hosted. Man, there's so much to ask you. I was going to leave the how do you run a company with AI thing at the end. I have to ask one— double click one thing. You said, you are looking back at the week. You're, you're understanding what happens. When you say we That's three thousand people. How?Rolling Out AI Internally: Skills, CLIs, and Company ContextKyle [00:07:09]: I think when we started rolling out AI internally beyond engineering, right? One of the things that I was really, passionate about is like we have to do this in a way where no one has to change how they work. I don't want to have to teach you a tool. I don't want to have to teach you something new. And so for us, we tried out a few tools. Most of them don't work because I got to get you on board? I got to teach you how to use it. What we've actually ended up doing is we've built like a set of skills internally. We have we each have our set of skills, and we've just been distributing even to the non-technical folks, the CLI. And then effectively, we're just giving it access to like read about everything that we're writing. So that's for us, that's usually GitHub, Teams, Email, and Slack. So Teams for, video chat, generally speaking.Swyx [00:08:03]: Teams and Slack?Kyle [00:08:04]: so we use Teams for video communication, but we don't use it for chat. W-we— GitHub for a long history, right? We're alwaysSwyx [00:08:13]: Also SlackKyle [00:08:14]: Talking about ChatOps and like everything is built into Slack. Like every command, every flow.Swyx [00:08:18]: So even though you have been acquired for I don't know, eight years nowKyle [00:08:22]: we stillSwyx [00:08:23]: You still use Slack?Kyle [00:08:23]: it's a purpose-built tool for us, and I think the reality is that moving off of it would be so bluntly expensive? Simply because all the tooling is, baked in with that paradigm. And they both have their pros and cons but they don't work the same way at all. We still use a bunch of different tools Because it's the purpose-built tools that We need. And thenSwyx [00:08:47]: Well, the same doesn't go for the rest of Microsoft, presumably.Kyle [00:08:50]: like the like various teams like operateSwyx [00:08:53]: They make their own decisionsKyle [00:08:54]: Various ways. I think it just matters what you're trying to what you're trying to do. But we do we do work across kind of every tool that we use, and then by giving everyone access to all of that context and the new WorkIQ MCP server, which is quite cool if you do live in the M365 like world. I can ask it all these backwards-facing questions, and it's incredibly important for our teams that are working remotely. There's a lot of stuff you miss when you're not in an office, and we are spread out all over the world. So most of that is looking back. And then we post, we post either auto-automatically into GitHub issues or discussions, these sorts of like findings or like our industry reports. Like what's happening this morning, today, yesterday. A little automation gets run. We'll use the app. We might use GitHub Actions like with, our agentic workflows just to go do that run, and then we push it into GitHub, and w-we keep having a conversation. So usually for us, it's about that sort of like looking back, looking forward on the non-technical side. And then of course for a lot of those folks, it's also building an app, pushing it to GitHub pages or pushing it somewhere to host it et cetera. But it's just like enabling everyone with that power of it's going to take me a week to figure this out. Instead, we're going “Okay I built a skill. Let's put it into a repo. We'll all share that skill together, and then we'll use the CLI or now the app-” “just to run it.”Micro Skills vs. Mega Skills: How GitHub Uses AI at WorkSwyx [00:10:26]: All right. I think, I think we're going straight into like the team management and productivity thing. I think a lot of people are getting various levels of LLM psychosis. How do you manage the bloat of skills? Like everyone Has their thing, and they're Like trying to promote it to the rest of their peers in their org, right? And obviously, whoever becomes a skill influencer internally becomes like an AI leader, right? Of sorts. I assume you have those.Kyle [00:10:50]: like I think we haveSwyx [00:10:52]: And I assume it's a mess a Yeah.Kyle [00:10:54]: there's like I— like I think the reality is there's two pieces. Like first is I think that we're ending the era of these like massive, beautiful, perfect skills that are just like not any of those things. ‘cause for a while, right every tweet every day is like go download the skills, the perfectly managed thing to do this entire workflow. And I think that like what we've found and what— I was just with my team, this week, and we were talking about the skill side, and we're really talking about these like incredibly micro skills that are just doing one thing for us very well Versus a skill that's going to do I said, that full report. That doesn't really exist on our side anymore. It's usually how do— like a single skill that's going to identify the most important marketing information given any MCP server. Like this is the most important thing. Less about stitch a bunch of tools together and have it produce this mega output because then weeks go by, months go by, things change, and you want to tweakSwyx [00:11:58]: It's brittleKyle [00:11:58]: Your mega skill and you're screwed? You can't do that. And so now we're really just talking about the Legos we're using and just letting the instruction book be something we're all putting together. Whereas I think a lot of AI skills for a while have been that mega instruction book style.Swyx [00:12:15]: I've, thought a lot about Postel's law. I don't know if that's a term that is, means things to folks. It's the idea that you should be liberal in what you accept and strict in what you output, right? And I think that's like a good framing principle for skills. This is my skills, obviously on GitHub. I feel like everyone should have like how like some repos In GitHub are special repos? I feel like we should sort of reify the slash skills and everyone like give it some kind of special presentation. Anyway, so, yeah, this is one of those like download Download anything, transcribe anything, and then you can string together the atomic skills that do one thing well Into like some kind of orchestration skill that calls other skills. I assume, does that match?Kyle [00:12:56]: I like I think so. I think that theSwyx [00:13:00]: Summarize anything.Kyle [00:13:01]: Like I think the- For me, summarizing something for I do communications and PR and analyst relations and marketing and customer activities, and so my summarize everything is very different for each one of those like Contexts. What ‘Cause if I'm summarizing something for an analyst, that's a very different thing than, probably how I'm going to summarize something for like a customer meeting or an engagement. So that's I think like the difference when we're talking about the like the tools I might use on Saturday or the skills I might use on a Saturday when it's just for Kyle. Yeah, those are kind of like they have an atomic actual tool underneath or maybe skill, and then Kyle cares about X. But I think when we're talking about work and enabling the the marketers, communicators there, it's the atomic, this is what good summarization is, and then this is what I care about as for marketing for communications For whatever. And that I think is like the interesting matrix problem when we go from like a developer set of concerns to all kinds of different professions, is that what that word means to me is different than it means to you is different than it means to the analyst or the salesperson, and that's where I think the matrix mess is that we're starting to like still starting to find. It's about these mega skills but they're all just slight permutations, but those permutations are really important. It's the difference between someone reading this and going “Did AI make this?” what Or “This makes total sense, and I would expect this when I'm giving a briefing to Gartner,” or like whatever else.Swyx [00:14:37]: I think the beauty of it maybe is that you don't have to be that careful about what goes in there. It doesn't have to exactly fit as long as it like roughly is contained in there. I used to complain about plugin hell, basically. Like when you have a framework and then you have a hundred things that you need to integrate, everyone does like the GitHub used to be bloated full of these things. And now we don't need them anymore ‘cause now you just use skills.Former Developers in Leadership: AI as a Creation MultiplierKyle [00:15:00]: And like I think the most magical thing is the just that like I can just also crack it open. Like Like yes, I could go like change the how the plugin is coded, or like I could go do that now with AI, but I think there's just something more magical about getting a response back and being “That's not right,” and then you just crack the skill open, you just type English words and it's different. That building block is just, I think very unique. Once I get everyone to kind of understand how to best how to best make those changes to get the most power out of them.Swyx [00:15:36]: Is there a— you have a your peer group that Of people like you. Is there a common framing for Something I'm feeling is, which is true, is that is this a golden age for former developers who are now in leadership? Because you can wield the tools, you would know the right words, you're maybe not too close to the details. Doesn't matter. But like you're more effective than someone who doesn't come from that background.Kyle [00:15:59]: I think that like the secret has always been your ability to identify patterns and solve problems, and I think that for folks that like myself that don't code day to day anymore, that has made me successful as a developer, made me successful as a COO and now CMO. And so now that I have access to get and write code, I'm now applying that sort of like pattern finding and problem solving, and I know enough still about how to then go and say, “Oh, I want to make an app, but I don't want to break into jail or create something that's not going to be able to work or to be deployed scale or whatever.” that ability to apply all that additional business knowledge and still code I think is what makes that so interesting to me. Slightly different than I think some of the other like technical leaders that became business leaders and now are going back to their apps and updating them. Good for them? But I think the more, much more interesting thing is, well, now I have this whole new set of expertise over ten plus years. Why not take that and use that as a developer with these AI tools? So I definitely think that makes me more powerful, but I think that's true for like every dev as well. Most of the dev friends I still have also have some other underlying skill and passion. There's really talented, very kind of linear computer science software devs, absolutely. I just find that the folks that came from a different career, went to school for something else, went off and did this random thing, and then became a software dev, or were a dev, did a random thing, came back. Learning that extra set of information, learning those extra skills, and now having the power of an AI where I can crank up fifteen agents on Saturday while my kids are doing lacrosse, That's like really powerful. And I think it gets me back to that feeling of like creation, and it's very hard to replicate that in most other senses? That first time you build an app and you click it and you show someone that's magical. And so being able to do that not just in code, but across all kinds of different assets that's, that's huge. We were doing we're doing our every year we do our revenue planning. We talk about okay, what is it going to look like for next year? And of course as you imagine, there's, slideshows everywhere talking about what are we going to talk about, what's the narrative, et cetera. And so as you said I'm “Okay, well, I could probably just like build something to build this and then that way I don't have to go build the whole spreadsheet or I have to pass it to my team.” So we went through this process, and I got all the information and used the skills I mentioned. I built like a little app just to make it so I could look at some of the information in a SQLite database, more easily. And I ultimately built this entire presentation without touching any of it and I was “Okay, I'm just going to present this to our CRO, the CFO, their teams,” without mentioning I'd built it with AI. I like built a skill to make it look very much not AI driven. Just not pretty.AI-Generated Presentations, Human Taste, and the Changing Chief of Staff RoleSwyx [00:19:03]: Like a design. Yeah.Kyle [00:19:03]: Not pretty. But just like very clearly not AI. Kind of like don't do anything interesting.Swyx [00:19:08]: That's, yeah, that is valuable.Kyle [00:19:08]: Just go Exactly. We did the whole thing through. It used my notes from Obsidian, it used all the context I mentioned before, the plans, and Never came up once that it was AI generated.Swyx [00:19:20]: It didn't matter.Kyle [00:19:20]: Never once. D It didn't matter. And so now I takeSwyx [00:19:23]: This is a toolKyle [00:19:23]: I can take that tool and go, “Look, I don't want you to go build slideshows.” They're just helping us share information with each other. If this thing can do it With a little bit of crafting from you and then we can look at it together, awesome. There's no value in all that extra work. I think that the ability to, make it look humanly bad and and build a little app to, manipulate the data I think is part of, that upside for devs that are now in leadership roles. Because, the thing that I feel like I said before, this that's all a people, that's all a people problem. I know if you've used a coworker or not to build a slide deck, unless you spent a bunch of time to not do it.Swyx [00:20:07]: I know, but like it was so, I think there's a certain charm to just being blatantly AI. ‘Cause I think that you're well, you're just honest about There may be mistakes here that I cannot vouch for. So how much value is there? But anyway I think, actually the real question I want to ask is, there's a— You were a chief of staff To Thomas. And in the pre-AI world, the that job would've been a chief of staff job of like Can you prep me these slides and all that? And now you do it yourself.Kyle [00:20:35]: I still, I still have a chief of staff. Because, the difference is it's sort of the discussion every time we have some sort of technology evolution is it's not that the jobs the roles don't all go away, they just change? And so yeah, I don't have someone spending all their time building out slides for me and presentations ‘cause I don't need that anymore. But now I need that person that is able to go and find all the different connections between humans in those discussions to help me find out, okay, I should be meeting with this group and this team, and they have an opportunity, and I'm going to be in San Francisco today, I'm going to be in Seattle tomorrow. Those sorts of human connection aspects are still incredibly valuable and has always been a big part of that chief of staff role. But now just like chiefs of staff are not opening up, letters to process, they're doing emails. What It's the same thing. And now they're, they're not building out as many of these presentations because they have the the ability to have a AI take it on for, and share that with me and great. Let's keep moving ‘cause it's allowing us to go faster and make better decisions more quickly.Swyx [00:21:45]: Awesome. Well, so we can dive into more sort of, Productivity insights as you go. I did want to do a little bit of a brief history of colleague and hub. Because, we started here. And then you also involved the NPM acquisition. I did, I do want to touch upon that. And then more recently, I just want to bring up to present day where we're having uptime issues Which transparently we've already Addressed publicly, but we'll, we'll discuss in the pod. Did I miss anything? Like what, any other major highlights? Obviously, it's, it's a lot of years to cover.A Brief History of GitHub: Webhooks, Actions, Acquisitions, and Platform EvolutionKyle [00:22:15]: No the I think one of one highlight was right before the acquisition closed in twenty eighteen, I got to launch the first version of ActionsSwyx [00:22:27]: OhKyle [00:22:27]: At GitHub Universe. So it was OSwyx [00:22:29]: They're that young?Kyle [00:22:30]: It was October of twenty eighteen, I think. Yeah. Yeah.Swyx [00:22:33]: Gee, Jesus.Kyle [00:22:34]: I got to I was the engineering leader on that project and got to launch that. And then, yeah, we did acquisitions of NPM you said, Semmle, Dependabot Pul Panda a whole bunch of things. That was a bigSwyx [00:22:47]: Pul Panda.Kyle [00:22:48]: Abi is doing well.Swyx [00:22:51]: DX. Holy crap.Kyle [00:22:52]: Did well on DX. I and like that was a that was the big shift, after the acquisition. I had to join the sort of business side.Swyx [00:23:00]: So I need to hit you on some of these things ‘cause you were there. Right? And how often do I get to talk to someone who was there? But yeah, Actions. Is that the number one source of security issues on GitHub?Kyle [00:23:11]: Oh, sh I think that the number one source of, security issues is probably like all, the literal code in everyone's like underlying repositories. I would say back further than that is, if you remember I had to show in this graph was this is, I'm, didn't say this before, this is ultimately webhooks.Swyx [00:23:30]: You yeah.Kyle [00:23:31]: Like circa whatever it was.Swyx [00:23:32]: It says Hookshot in there.Kyle [00:23:32]: I forget. Yeah. Yeah, Hookshot's in there. And so like back then, it says GitHub Services. Do you see, it says Hookshot FE for front end, and then it says GitHub Services. GitHub Services back in the old days, right? You we had a repository that was Ruby code, and you could write any Ruby code in there, and then we would execute that On your behalf As a service, and then that way if an if you were trying to integrate with something, it didn't we would run it for you.Swyx [00:23:57]: And of course no containers ‘causeKyle [00:23:58]: No, ‘cause it wasSwyx [00:23:59]: Well, no containersKyle [00:24:00]: Twenty fourteen. And so there was some isolation obviously, but it was mostly the separations on the server level. That's like an example as long as the very old version of Pages, which ran on its own containerization infrastructure, not on Actions.Swyx [00:24:15]: Which like all-time great product.Kyle [00:24:16]: Pages powers the internet at this point to some degree. Those were places where like clearly there were no like issues like to my knowledge. But it was those things where I'm looking at and going “Okay, well we can't be running arbitrary Ruby code,” like on everyone's behalf. Then containerizing all of that up intoUh into actions now where yeah the containerization, is r-really good. The pinning most folks aren't pinning it the like to a particularSwyx [00:24:48]: ImagesKyle [00:24:48]: Sha, et cetera like their workflows, and so that's a big that's a big place Of pain for folks if they're just doing similar to any dependency management, just V1 or newest or latest, I think. But, that journey from that day to “Okay, we're just going to run all this arbitrary code, and, it'll basically be okay,” to now, no, we have, really good containerization. We have a new, underlying, ag-agent, containerization, service. It's like we're using it under the hood. It's through Azure. They recently announced it. The Azure, Dev Compute, but it's, very fast, very fast compute to be able to, spin up your own cloud agents, or whatnot. We're using it under the hood for some parts of the new,Swyx [00:25:36]: Microsoft Dev Box?Kyle [00:25:37]: No. Dev Compute, yeah.Swyx [00:25:41]: Hmm. Not finding it just yet.Kyle [00:25:44]: Oh, it's, it's in there somewhere.Swyx [00:25:46]: All right. Well, we'll cut that out.Kyle [00:25:47]: Sorry. But with, Dev Compute, you can, run, really fast, spin up really, small VMs really quickly, so you're doing a tool callSwyx [00:25:58]: Same conceptKyle [00:25:58]: Just do it containerize exact-exactly. So we're using that so definitely moving that direction to protect us from every every piece of code that we're ultimately running.Swyx [00:26:07]: look, that grows into the full SDLC? Code hosting was just the start and and then it's grown beyond that. Let's talk about NPM may-maybe ‘cause I think that's also, a very major point in the industry. I do think, it was looking for a home. It was, kind of struggling as a business, right? I don't know, I don't know how you would characterize that whole acquisition and how itNPM, Package Security, and Keeping the Internet RunningKyle [00:26:33]: like when we were talking to the team, I think the big thing for the both of us was to find a way to keep NPM, which was basically powering the internet then and way more so now to some degree running. Keep it going keep continuing to scale. It was having scaling problems, if I recall, back at that time. They were doing some rewrites. ItSwyx [00:27:00]: that's cute compared to now.Kyle [00:27:01]: Well, that's the thing is like when I'm talking to folks now, there's there's so many more underlying uses of NPM than there were back when we had them join in with GitHub. But that was ultimately the goal. It was really okay, we used to have pages. We have, the world's code. Let's make sure that we can keep NPM running well for the world. And we put a bunch of time and investment into fixing some of the underlying backend, changes, some of which we talked about some of the manifest work, et cetera. And then now, really trying to bring the the security posture of NPM up to speed. But, it is a unique challenge in that every move that we make to make it more secure will break a lot of people. And security is paramount. And also, we take it very seriously. We're, the any time that we have a problem with GitHub or we make a change that makes us more secure but hurts, there's, a snow day for developers or a really bad fire that they have to go put out. And so we've, have changed the 2FA policies. We've changed the way the tokens work. When we find tokens that have been exposed or potentially, exposed, we invalidate them, andSwyx [00:28:22]: I love that feature in GitHub. Yeah, it's greatKyle [00:28:23]: That creates issues, but, the but that's the thing is we're trying to push the community, forward without necessarily, doing something that is going to break the contract that's been for 15 years or close to it or some amount of years on NPM.Slop Forks, Vendoring, and the Future of Open Source Supply ChainsSwyx [00:28:43]: I think the— So now we're talking about, open source and publishing. And I think there's something here with what people are calling slop forks, which, I think Malta from Vercel is doing. And, part of me thinks, well, the way to get past any vulnerabilities, we just, let's just get rid of the concept of NPM. And we only publish source code. And anytime you want to import it you have your coding agent look at it and then adapt whatever subset you're going to use into your vendor it. But, the AI vendor it. Is that realistic? I don't know. Is it— Will that solve all our security issues? I don't know.Kyle [00:29:24]: I don't think it'll solve I so Mitchell was just talking Mitchell Hashimoto Was just talking about this today, and I think that I-in some ways, it's all all things, old or new again? Yeah, absolutely vendoring everything. Like I do I do remember twenty thirteen, twenty fourteen.Swyx [00:29:42]: This is Yeah. Let's, we must return toKyle [00:29:43]: That's what is We were vendoring everything. We were having actual discussions around, or at least I remember we were “Should we take this full thing?” “Why is this so big? We only need this one file.” And so I do think there's something true there where having either taking only what you need or the dependencies just getting incredibly small over time, I think will help to some degree, but it's not going to solve the fundamental problem, I don't think, because the vulnerabilities in an agent looking at them, there's time and time again, there's a million different ways in which we can convince an agent that this thing is, secure or not and pull it in. Or we can do static code analysis or runtime testing to say whether the code works or not. That is, I think, the step that needs to continue to be, invested in. The question is just on, how much scope. Should it be this enormous project that I'm pulling down, or should it be this piece? Either most companies are running some amount of security checking on the on the packages that they're bringing in or vendoring. That I think won't change. That's like what advanced security does to some degree, Socket does some degree. Like everyone is doing a piece of that. How we each do that like especially when we're talking to enterprise customers, is just like very different. No there's no one wants one single way to do it. And I think that's always been GitHub's, unique position in the world. I talk a lot to maintainers, I talk a lot to folks about this. It's we're— we rarely start like a process and a practice and like push it onto the community. We usually wait for the sort of like RFC process socially or literally, everyone agreeing, and then we'll cement something in. Because otherwise we'reMaintainers, RFCs, Vouching, and the Social Layer of TrustSwyx [00:31:35]: That fits your role in the ecosystem, yeahKyle [00:31:36]: We're GitHub. Yeah, we don't want to shape the whole thing. We want it to be figured out. But like how do you balance that like sort of Role in the industry to keep everything as secure as is possible and make sure that you're you're not going to be compromised as a human, ‘cause that's usually how it all happens. And Not not create a process or lock us into a flow that you're not going to or like Mitchell's not going to or other open source projects aren't going to like. That's always been a tricky balance for us, and I think that's something that we haven't talked about enough is we're not going to be able to fix everything for everyone in a way that everyone is going to like. So tell, help us, tell us what is working. When Mitchell was talking about, the Upvote, the upSwyx [00:32:22]: I was going to bring up his thing. Yeah.Kyle [00:32:23]: I forget what it Yeah. When he's talking to us, I was chatting with him and talking to him about this and I put it on Twitter and we talked to, also over DM, was “We're going to keep working.” but I think the important thing is I do actually want to hear what isn't working for you. And as, be as specific and clear for your project as is possible. And to every piece of credit over the many years that we've known each other through the industry, he's always done that and I appreciate that ‘cause there are places that we need to fix up, and we hear from him, and we'll fix up just like we do all other kinds of maintainers. But that that process between making those types of improvements and being more secure and like creating, I forget what he calls it's not the proof process, not the claims process. Do what I'm talking about? He has that he his projects have a way for you to kind of like,Swyx [00:33:13]: VouchKyle [00:33:13]: Vouch. Thank you. Yeah. He has like the vouch system for saying, “Hey, you should accept my PRs.” That's beenSwyx [00:33:20]: I just built this into GitHub. I don't know.Kyle [00:33:22]: Well, see, but that's the thing is that you say that and like he and his community really likes this and then I'll go talk to other maintainers and other maintainers, globally, and they're “No, this doesn't work for me.” And that is the tension, but also the kind of beauty of GitHub, depending on which way you look at it is we want to help maintainers, so we create all these tools to let you have more control over how much you take in from AI and PRs. But you can also use this. What You can go use this project, and if it takes off and becomes the kind of mostly standard, then yeah, we probably wouldn't enforce it but we would add it in because that's the flow that we tend to do?Swyx [00:34:02]: I hear a lot of people don't know the history of the pull request. And like like that's how, that's something that GitHub standardized basically.Kyle [00:34:08]: Yeah. It was a very messy process Like beforehand, and now the we have the benefit of it being the process? And now we have to go and Figure out the next best process or what adaptations change, or what does a pull request look like when eighty percent of your PRs are just coming from your agents and not From other devs?Swyx [00:34:31]: Do you like the prompt request idea from Peter?Kyle [00:34:34]: like I think that for each like each idea I think has its merits. I'm not, I'm not avoiding saying anything good or bad, but I feel like I've seen a version of we have that we have entire Thomas' store. Take all the assets of what you've built and put that in. I think that's got great ideas. There's all these various permutations of the PR flow, but I think the reason why there's not a single answer is ultimately we're trying to codify trust. We're trying to say “Okay, if Sean reviews this I'm going to trust it because you're Sean or you're the senior dev or you're the whatever.” And right now, when we are working in a flow where an agent writes code and another agent reviews code and then Kyle goes and looks at it the trust is kind of diffuse. And most of the tools that we're talking about are talking more about verification flows. We have more assets to look at, so I can probably say whether this is a good PR or not. But that still doesn't solve, I think, the human problem of I'm looking at a PR and I want to know if I can trust it. And we're still, we still tend to use human signals for that? Mitchell approving it or Kyle approving it or whatever. And so I think that's, I think that's why most of these options haven't really solved it is because, it's a social problem ultimately. It's a it's a human problem to review it and agree. Or you fully trust the tool and you're imbuing that tool with full trust Which I think in some cases that absolutely exists.AI-Generated PRs, Trust, and the Waymo AnalogySwyx [00:36:08]: And so like in the same way that there will be a tipping point in society when we don't allow humans to drive anymore Because machines are measurably better than Than humans. I'm looking for that tipping point, right? Like Mythos is ridiculously expensive. Someday we'll have Mythos on a desktop. I don't know. Will, does that change the equation?Kyle [00:36:30]: I think it's more I took a Waymo here, and I was on my phone and not looking around at all. There are other, self-driving, vehicles that I would not trust while, staring at the road. And I think that trust is something that isSwyx [00:36:48]: Is this a Zoox thing? What is itKyle [00:36:50]: I think that is both. I think that is both. LikeSwyx [00:36:53]: There's Zoox in this robo taxi. That's it. It'sKyle [00:36:56]: Well, depending on what level Of self-driving. But, my point is sort of that I think part of that is I strongly believe that's, a mixture of verifiable proof. Like how many accidents, how much data, and so on, and the human aspect of how I feel when I'm in this car, what it tells me, et cetera. And so that's why I think some of the like Some of these some of our AI tools tend to, imbue me with more of that feeling of trust, even if the data says this is 100% accurate. I feel like it takes more time for us to go, “Should I trust this or not?” And that's in the soft sense of, startups with high agency, weekend projects, and open source. And then there's enterprises and regulated industries and everything else, and that is an even harder problem to go solve because even when it is fully verified, not only do you have to have trust from the humans on the team, you probably have to have trust from multinational,Swyx [00:37:55]: Oh my GodKyle [00:37:55]: Multi governments around the world and regulating agencies. And so that's where I feel like until we tip over to your point on the sort of like human EQ side of it. I feel okay this feels okay I've been proven enough. Then the ball will start to roll a lot faster, where we'll end up getting to the “Okay, we can trust this,” and feel good about it in the Most difficult of cases.Reputation, Sponsors, Stars, and Bot Activity on GitHubSwyx [00:38:18]: If human trust is the thing that matters, I feel like GitHub as the developer social network could maybe do more there. Like vouchers are one system But, we have star counts, and then we have Contributor rights, and that's it. And I feel like there should be more in that space. I don't know if there's any other design decisions there.Kyle [00:38:37]: I think that one of the places that we don't really expose right now in this sort of way is, some degree of like hard trust and support, which would like for me is like sponsors is a good example of that.Swyx [00:38:49]: Ah.Kyle [00:38:49]: It like costs you something. To prove that I believe in your project and I trust you To some degree or I want to support you at the very least.Swyx [00:38:56]: Solve payments for open source. Why not?Kyle [00:38:58]: I think that I think that like as we keep moving forward, right, there's more and more projects where I'm, adding more and more dollars into sponsors personally because I want to like support them, but I also like know of I've probably never met them in person, but, I know of enough of their work that I want to support them. I think the thing that I don't love about stars or commit counts or anything else is ultimately, even with all of the various, abuse and de-spamming and deduplication work that we do or anti-abuse work that we do, these are all, not active social signals. They're passive ones that are ultimately gamifiable. And you may trust me, but another open source maintainer may not. And on what heuristic should you be, trusting me? That I think, is kind of where some of our thinking is right now. What signal from me is most important to you? You— If you can define that potentially, honestly in an agentic workflow that's what we see some of these open source projects do, where you have GitHub actions, and then you have like an agentic workflow that's calling AI, and you're setting these rules. Like if Kyle has submitted and gotten accepted PRs across any given project and has a social handle tied to his account in GitHub, and that social account's older than a certain amount. Really complex measures that matter to you ‘cause most open source projects have that heuristic built into their heads, if not written down in the contributing guidelines. You could take that and then go apply that and then just say, “Oh, we're not going to accept this PR.” Building something that is, I think, malleable to everyone's needs, is a little bit better, rather than going “Hmm, this account's too young.” Because what happens? The attackers just go and go and create a multitude of accounts, and they wait Until it ages up. Needs to have a certain amount of stars. That's how star inflation happens. Need to have a certain amount of reposSwyx [00:40:46]: Oh my God. YeahKyle [00:40:47]: With PRs. They all just create repos and submit PRs to each other, and then they come in and do something nefarious. And so, it's hard. It's hard to find the measure. So I think we're, we're looking more at how can we provide you tools so you can kind of choose what's best for you. And of course, we'll give you some standards. But the trust vector, gets down to I don't know, some version of like human digital ID like everyone's been talking about. Like how do I prove that it's meSwyx [00:41:13]: Give me your eyeballsKyle [00:41:14]: On the internet. Give me your eyeballs. Exactly.Swyx [00:41:18]: The I got to keep moving on Topics, but obviously I can go all day on this stuff because, I've been involved in GitHub and open source My entire professional career. Stars. Very superficial. Everyone knows it. But I think time to one hundred thousand stars is the fastest I've ever seen. Like people just reached that in I don't know, months. And then like at the same time I don't trust it right? Like how many of these are real or bot or like whatever. I don't know how to ask this but like what can we do about it? LikeKyle [00:41:49]: JustSwyx [00:41:49]: Is stars broken? Is stars fine?Kyle [00:41:51]: I think that there's kind of two, there's like two pieces. Obviously we're constantly like trying to find ways in which like your users are producing spam, which would, I would include like be like only doing star gamification. When we find them, we pluck ‘em out and we,Swyx [00:42:08]: But it's like a Whac-A-MoleKyle [00:42:10]: It's a hundred percent like a Whac-A-MoleSwyx [00:42:11]: There's no wayKyle [00:42:11]: Now, powered by AI to be helpful. But I think more so what I'm seeing is, a lot of the like fastest time to X tends to be because we're now inviting so many more people into like software development on GitHub That like the zeitgeist is just swarming? And it'sSwyx [00:42:32]: It's not just developers anymoreKyle [00:42:33]: And it's not you and I. Like like however you want to say like what a developer is it's not just folks who have been coding for a very long time. It's folks that have maybe started coding or only joined in since the AI era. And nowSwyx [00:42:44]: what's the latest Octoverse number? I know eighty million was my lastRem- member that a number of developers on GitHubKyle [00:42:50]: Oh, we're over 200 million now.Swyx [00:42:53]: Okay. Well, so you see?Kyle [00:42:55]: Like over 200 million developers now.Swyx [00:42:56]: But it's not developers, right? It's, it's people with a GitHub account.What Counts as a Developer in the AI Era?Kyle [00:43:00]: So, so this is, this is the biggest debate that I would say, everyone loves to have at GitHub at this point. From my perspective, right, I think that there's, there's clearly a difference between, professional enterprise developer and then developers. But I think that I think that the idea that we should be I don't know, splitting hairs or segmenting developers in the early era of software development is, not worth our not worth the time. SoSwyx [00:43:29]: When you get into gatekeepingKyle [00:43:31]: 100%Swyx [00:43:31]: What is a developer?Kyle [00:43:31]: 100%. ‘Cause I wasn't a developer when I started writing code? I was going toSwyx [00:43:36]: Oh, no. I made— I cloned a thing, seven years before I learned to code. And then I and then I wrote about my learning to code journey, and people Just called me a fraud ‘cause I had a GitHub account. And I'm “Well, no, I just use GitHub, but I don't know-” “I didn't know what I was doing.”Kyle [00:43:49]: I I remember that. I remember those sets of posts, and like that's, that's b******t. So I fight very clearly on the line of, if you create code, if you have an idea and you create it into some way of, I'm, I'm going to run it and use the app right now, you may still use AI in that moment, but that's okay. At some point you're going to do the next thing. You're going to create a big— You're going to have to learn about this database. You're going to fix a bug, whatever. We're all on some same journey, and those people are also hearing about the great new agent skill package or a new CLI tool or a new whatever. And those projects are going up because you want to be a part of this moment, just like I wanted to be a part of the Ruby community when Ruby was popping off when I started becoming a developer, and now I can just click the star button. And so I think that yes, there's clearly some amount of like spamming and game gamification that we're working against, but I really think we're just seeing this whole new cohort of folks that are moving from technology to technology because they're not working on a 20-year-old software application. They're working on a side app that they built on the weekend for their friends or for their new idea or whatever. And that's how you see these enormous charts going up and to the right with With stars.Swyx [00:44:59]: I think something that's remarkable is the persistence or, that GitHub extends to those folks. Usually when I see platforms go into a new audience, they usually have to, have like a second platform with a different name that wraps the main platform. But somehow GitHub has been able to sort of persist and extend, and it's friendly and whatever? So it's, it's nice.Spark, Low-Code, and Always Showing the CodeKyle [00:45:19]: I that's partially why I think as we've tried to move into I don't know, more like low-code-y things. We so we started working on Spark as like a way to, build an app and run it. I think that the reality is that we anytime we try to, kind of put even a veneer on top of it without when we put a veneer on top of something, we still always show you the code. That's kind of like a tenant. We're never going to, hide the code from you ever, because whatSwyx [00:45:52]: Why would you?Kyle [00:45:52]: That's, yeah, that's the whole point? However, I think that what we learned with things like Spark is that really the value of Spark for most devs is, easy runtime. And you may have a runtime or a host that you're going to use for that or you just build something and run it but, the package of making that even more simple isn't really needed for folks that are trying to build software and not just trying to build, an app, which is, slightly different, a slightly different goal. So I want to get you in, I want to get you comfortable. I think the best thing for me as, someone that did not traditionally come into software dev way back, I want anyone to be able to breach that chasm and not be in the I don't know, I feel like we're, we're still in an era of, STEM. I've got a 12-year-old and an eight-year-old, and it's “We got to get ‘em into STEM,”? Over and over. And I like I do, I do the things that good parents do. I was “Oh, you want to do coding?” “Yes, I want to do coding.” Do coding classes. But now they're just not afraid of doing software. And that's, I think, the thing that's honestly kept me at GitHub for so long. Anyone should be able to go and build a thing, just like I can go change a light switch in my house. I'm not going to go into the breaker box ‘cause I'll probably kill myself? But, I can go change that light switch. Everyone should be able to go and say, “This fricking app doesn't do what I want. I want it to work like this.” And that I think, is what's kind of kept us all connected with GitHub through the years and some and during the easiest of times or in the hard times because of that opportunity of, we're the home for all developers, and we want everyone to be able to have that feeling that we've had of, had an idea, I created it and holy s**t here it is.Swyx [00:47:37]: Here it is. All right, I'm going to try to do more spicy questions.GitHub's Hardest Scaling Moment: Growth, Agents, and UptimeKyle [00:47:42]: Great.Swyx [00:47:42]: Is it an easy time now or a hard time?Kyle [00:47:45]: Oh at GitHub? It's a hard time. Like, it's a hard time and also, I was just with my team and I said, “This is also, the best and most exciting time that I think I can remember at GitHub.” BecauseSwyx [00:47:57]: Best of times, worst of times. It's never oneKyle [00:47:59]: ‘cause we've we were talking about Octoverse reports and, usually we do an Octoverse report once a year, and we look at the numbers, and we say, “Oh my goodness.” I was at Universe in October saying, “This was the fastest year of growth that we've ever had,” right? And now we're doing more in a month than we did in a year last year.Swyx [00:48:20]: You're talking about PRs.Kyle [00:48:21]: Commits.Swyx [00:48:21]: Commits, yeah.Kyle [00:48:22]: PRs. Kind of like you name it by roughly every measure that we're looking at, there's some amount of sort of growth that is much bigger, and that is breaking our system in new ways, not old ways. Like webhooks were always notoriously, unreliable over the years?Swyx [00:48:38]: Whose fault is that?Kyle [00:48:39]: not anymore mine, but for a period of time, I'm sure you could pull up a tweet that was “It was me. I'm sorry.” but, now, that got rewritten at a scale level that is still working and is not having problems today. Now what we're finding isn't just the isn't the-The simple stuff that folks are on the sometimes on Twitter or on the internet are “Hey, why is this like this?” Sure. There's absolutely silly problems that we shouldn't exist. But now we're talking about, unique, novel permission problems that happen only at a scale across all different objects or whatever, that now we have to go rewrite this underlying system. And so it's, there are problems that yeah, caught us off guard, which I think I said. Like the growth is astronomical, but also we're making such material progress in that I'm excited once we're once we've kind of like reimagined the underlying foundation layer, or pieces of it at least, what's going to be possible when it's not just all of us and all the new people that are being developers and all of their agents and all the tools like working together. Because that'll still happen in that in that GitHub tool, that GitHub community. But it's a it's a hard day anytime we can't give you what you're looking for. We have the same problem internally. We operate through github. Com. Of course, we have backups when things go down and whatnot for our own operations but we feel it too. If it's not working it's not working for us, and that's kind of like the promise of dogfooding for GitHub. It's always been true. We're using the same tool you're using. We're not using a super secret version. We and so we also need it to be great for us for our customers of course for open source. And now an exponential growth of agents, Doing it too.Swyx [00:50:32]: I wanted to load for audio listeners who maybe haven't seen your tweets, whatever. So one billion commits in twenty-five. Now it's two hundred and seventy-five million per week on pace for fourteen billion this year, if growth remains linear. Is that still the pace? I don't know. It's been aKyle [00:50:48]: it's, it's speedingSwyx [00:50:50]: Roughly.Kyle [00:50:50]: It's still speeding up.Swyx [00:50:51]: It's, it's April, so yeah.Kyle [00:50:51]: Exactly. This was in April.Swyx [00:50:53]: All right. So basically you have fourteen x growth, right? Year on year on year. And I think that's a scaling issue. I think, I'm going to like try to really steel man this thing. People have experienced fourteen x growth. They haven't had your downtime. And that's like— C-can we go dig into that? Why? Like what's the— what broke? What are we doing to fix it? Like just anything for the community to reassure them.Why GitHub Reliability Is Breaking in New WaysKyle [00:51:18]: so there's a Like I was saying, there's a couple different places that we've seen the growth issues. Some of the growth issues, which is why we're t— I was talking about pushing hard on more CPUs is in actions in particular. More tools, more agents, more PRs mean more builds, more builds mean more CPUs. And so we are expanding through not just our data center, but obviously we were talking about moving to Azure and moving to, adding an additional cloud compute because we simply need more CPUs. Not as much GPUs. We definitely need GPUs too, but now CPUs are becoming a factor.Swyx [00:51:53]: It's very CPU heavy.Kyle [00:51:54]: Underneath the hood when it comes to some of the underlying services, we've been breaking up over the years our database infrastructure, so that way we have, more cognitive separation between our the various services. The place that we continue to have pain is in, permissioning. And so right now m-many of our permissioning layers sit into a database that we like internally call MySQL One, and old Hubbers will know what I'm talking about. And so we've been pulling things out of MySQL One for many years, because like and we use we use Vitess and we use other technologies to shard and we do it as one bigSwyx [00:52:31]: Famous thing, PlanetScale was born from this andKyle [00:52:32]: A hundred percent. Sam Old Hubber and friend. And so finding these opportunities to like break this out and then do that globally. The other thing that I think is interesting and both a unique opportunity and tricky is we also run everything I just talked about in a black box container with GitHub Enterprise Server for people that work on-prem. So we take everything I just said, and we also do it on-prem, and we also do all of that and we do it in a data residence setup for customers that need to have their data in a single location. Each of these has the unique characteristic around how we're sort of storing that data in MySQL or in a permissioning setup. That's where some of these outages have oc-occurred, where you're seeing it more like across the board rather than just like the one pieceSwyx [00:53:17]: Filling the databaseKyle [00:53:17]: Isn't quite working. Exactly. And so part of it is that. I think there's been some other places where agents are much more or more projects appear to be moving towards monorepo versus we were going the other direction for many years in the industry. Repos were smaller, but there were more of them, and now we're seeing the opposite. Repos are bigger, and there's, not fewer of them per se ‘cause there's new growth, but, we're just seeing many more big repos. Big repos, big monorepos have always had, a unique performance problem. Because each one, is slightly different if, particularly if the underlying blobs are incredibly big Inside the repos. And so we've done a ton of work that you pro— like most people haven't probably experienced, unless you're in this case of the monorepo. But that Git, infrastructure layer improvement does help the overall, system because, many of the improvements that make monorepos work better make all repo infrastructure work better. And so, I could kind of keep going down the line where it's another thing where we're moving out of, We're changing how we do j I'll just say job queuing for lack of a better, explanation changing the underlying technologies there.Swyx [00:54:32]: I spent two years being a job queuing guy, so.Kyle [00:54:34]: And so it's kind of a little bit of a little bit of piece by piece, and it's mostly because as we were— as it was built, we built everything in a way that assumed, I guess in some ways that the size of the pipe of work was going to remain the same. There's just going to be more people coming through each of those pipes. But instead now in places whereA git push was, generally a certain size for example, is now, no longer true.Swyx [00:55:03]: Oh, yeah.Kyle [00:55:03]: OrSwyx [00:55:05]: I push a thousandKyle [00:55:06]: On the average. 100%Swyx [00:55:06]: A thousand line commits like dailyKyle [00:55:07]: Same thing with PRs. Like PRs same thing. And like we've talked about optimizing that and making changes where, and there were technology choices that did not work there? And it got slow, and it didn't It was not fast. It did not do what the users wanted. And so we've been reeling that all out and going “Okay, that's just not right. Let's stop putting good money after bad and do it the do it the right way or the right way now.” So there's It's a it's a lot of things, not quite when I've experienced scale at GitHub historically, it's almost always two options that we've used. We go vertical scaling, particularly with databases, right? And we go horizontal scaling. Oh, we just have more people using this service. Great. We're going to add more servers, and we rack them in our data center, or we use it in a cloud. And now we're sort of in a like diagonal, where like vertical doesn't really work anymore. Horizontal isn't work either because we're all We all have some CPU or GPU constraints in the world now, and now we have to go in and like crack open services that have been running for 10 or 15 years and go, “Okay, the rules of this service have legitimately changed, and now we have to rewrite them.” None of this is an excuse. This is like we're We have to do the work. We have to make it better.Swyx [00:56:22]: actually as an infra guy, I'm “This is like one of the most fascinating scaling challenges I've ever seen.”Kyle [00:56:26]: That's that's, that's the thing that's the thing that it's hard for Like when we weren't talking about it publicly, and I was like I came out, and I was “Hey, I just want to explain what's going on.” Part of it comes from a very old GitHub ethos, which is it's our it's our uptime. It's down. W What I know you're a developer, so you're, you're inclined to want to understand more what's going on. But at the same time us going “Hey, this service didn't, perform the way we expected, and now we have to go change it,” we weren't We're not trying to hide anything from you i

Состояние DevOps в 2026: Platform Engineering, AI-агенты и что стало с junior-инженерами. Собрались на кухне с тимлидом системного юнита из большой компании - поговорить что и как сейча. О ЧЁМ ВЫПУСК • DevOps vs SRE в 2026: где проходит граница и почему «you build it, you run it» иногда создаёт больше проблем, чем решает. • War story: упавший Kubernetes во время корпоратива с пивом - классика первых K8s-внедрений. • Момент, когда DevOps ломается: 600 сервисов, 3600 пайплайнов и почему каждый новый инженер пишет 3601-й. • Platform Engineering: зачем нужна платформа, что такое метаплатформы и как устроены слои внутри крупной компании. • Junior + AI = middle: что изменилось с приходом AI-ассистентов и сколько теперь занимает обучение DevOps. • AI в работе DevOps прямо сейчас: мультиагентные помощники для расследования инцидентов, внутренние vs внешние модели. • Реальные AI-катастрофы 2025-2026: Replit дропнул базу и бэкапы, сервис аренды машин ушатал прод. • Multi-agent flow: refiner + архитектор + автономный бот, PR за час вместо недели. • Тимлидам: не носи инженерам PR, которые ты навайпкодил за вечер. • Что реально учить в 2026: Linux, сеть, Kubernetes, один язык программирования и AI-грамотность. • Знать базу vs спрашивать AI: почему без фундамента ты не поймёшь, куда тебя модель направляет. ГОСТЬ В гостях - Андрей Волхонский, руководитель юнита System в Центре разработки инфраструктуры Авито. 13+ лет опыта: от Windows-DevOps в TravelLine и Kaspersky до платформенной инженерии в большой продуктовой компании. ССЫЛКИ

In this episode of the Liquid Weekly Podcast, hosts Karl Meisterheim and Taylor Page are joined by Sandesh Kulai, founder of STOQ by Artos Software.Sandesh shares his journey from building early Shopify apps to working at Shopify, then returning to app development full-time with Artos Software. The conversation dives into the real complexity behind preorders, back-in-stock alerts, selling plans, deferred payments, storefront integrations, and supporting apps across a wide range of Shopify themes.Sandesh also gives a behind-the-scenes look at Engine Room, Artos Software's internal AI-powered operations dashboard, and shares practical advice for app developers on treating the business itself like a product.STAY CONNECTEDSubscribe to Liquid Weekly for more expert insights:https://liquidweekly.com/EPISODE HIGHLIGHTSSandesh's Shopify Origin StoryBuilt for Shopify RecognitionFrom Back-in-Stock to PreordersSelling Plans Beyond SubscriptionsWhy Preorders Are More Than a Button ChangeStorefront and Theme Support24/7 Human SupportEngine Room and AI OperationsBuilding the Business Like a ProductFIND SANDESH ONLINE & RESOURCESLinkedIn: https://www.linkedin.com/in/sandeshkini/Twitter/X: https://x.com/heysandy801STOQ: https://www.stoqapp.com/STOQ on the Shopify App Store: https://apps.shopify.com/back-in-stock-restock-alertsTIMESTAMPS00:00 - Cold Open: Fighting Operational Slowdowns with Engine Room00:52 - Introduction & Sandesh's Birthday03:02 - Built for Shopify Recognition at Editions.dev07:50 - Rails, React, and the STOQ Tech Stack08:52 - Sandesh's Origin Story: Apps, Shopify, and Product Management12:10 - From Restock Rocket to STOQ13:36 - Why Preorders Are More Complicated Than a Button Change15:16 - Selling Plans, Purchase Options, and Deferred Payments18:38 - Deposits, Partial Payments, and Charging Customers Later20:45 - Using Preorders and Waitlists for Better Inventory Decisions21:36 - Conversion Analytics for Preorder Campaigns24:32 - Listening to Merchant Feedback and Expanding Product Direction28:12 - Supporting Storefronts, Themes, App Embeds, and Selectors30:50 - Building 24/7 Human Support33:01 - Scaling Support from Founders to a Team39:58 - Engine Room: Artos Software's Internal AI Dashboard41:12 - Tracking Merchant Sentiment, Reviews, Web Vitals, and Escalations44:15 - Using AI to Keep the Team Focused on What Matters46:02 - Co-Founder Dynamics and Long-Term Partnership52:47 - Advice for App Developers: Treat the Business Like a Product54:13 - Shopify Dev Changelog Highlights01:01:49 - Picks of the WeekDEV CHANGELOGMore admin intents now support Settings: https://shopify.dev/changelog/more-admin-intents-now-support-settings[action required] Ship and pickup in one order now available in feature preview: https://shopify.dev/changelog/ship-and-pickup-in-one-order-feature-preview[action required] App deployment in CI/CD is now available for all apps: https://shopify.dev/changelog/app-deployment-in-cicd-is-now-available-for-all-appsPublish and unpublish product variants independently from product: https://shopify.dev/changelog/publish-and-unpublish-product-variants-independently-from-product[action required] Bots and agents should identify themselves via Web Bot Auth: https://shopify.dev/changelog/bots-and-agents-should-identify-themselves-via-web-bot-authTarget discounts to specific markets: https://shopify.dev/changelog/target-discounts-to-specific-marketsShopify App Pricing: charge for usage, recurring subscriptions, or both: https://shopify.dev/changelog/shopify-app-pricing-charge-for-usage-recurring-subscriptions-or-bothPICKS OF THE WEEKKarl: A retro Radio Shack 1680 chess computer from 1996.Sandesh: Setting up a Mac Mini to experiment with Hermes and personal AI agent workflows.Taylor: The SDA Toronto guide built with Trudy MacNabb for people heading to Shopify.dev, including events, restaurants, work spots, and local recommendations.

Dwayne McDaniel, developer advocate at GitGuardian.com, joins host Priyanka Raghavan to talk about the engineering challenges of secrets management. They explore what "secrets" really are in modern systems—far beyond passwords—including API keys, tokens, certificates, and machine identities, and how "secret sprawl" emerges across the SDLC. Drawing on reports from GitGuardian and Verizon, they discuss the growing scale of secret leaks and why credential abuse and phishing remain dominant attack vectors. They examine common leak points—from code repos and logs to CI/CD pipelines, containers, and SaaS integrations—and how cloud, DevOps, and AI tooling are amplifying risks. Priyanka quizzes Dwayne about recent supply chain attacks from pyPi and trivy ecosystems, highlighting recurring root causes like poor access control, long-lived credentials, and weak security hygiene. Finally, they consider detection, response, and modern solutions—short-lived credentials, secret scanning, and identity-based approaches like OWASP NHIR and SPIFFE/SPIRE—ending with practical advice for engineers to reduce blast radius and design for secure secret lifecycle management.

We've been talking a lot recently about AI-native developer workflows and where CICD is heading. This week, we shared one of our most exciting demos yet: a look at how SEMai is changing the way developers interact with CICD systems.In the demo, Marcos starts with a completely clean repository: no CI configuration, no GitHub Actions workflows, nothing.Then, inside Claude Code, he runs a single command:/sem-ai initFrom there, sem-ai analyzes the repository, detects the tech stack, and generates a tailored CICD pipeline automatically.It recommends:* Linting* Security scanning* Matrix testing* Pipeline topology improvementsBut the most interesting part comes afterward.Marcos tells the agent:“Work until the pipeline is green.”The system monitors the pipeline, analyzes failures, applies fixes, reruns workflows, and eventually gets the build passing successfully while summarizing everything it changed along the way.Nick also shares lessons learned while building the onboarding experience itself, including why slash commands became critical for reliable agent workflows and how improving contextual skills dramatically increased success rates.This is what we mean when we talk about AI-native CICD:not AI bolted onto existing tooling, but a fundamentally different developer experience built around collaboration between developers and agents.In the full demo, Marko, Marcos, and Nick walk through:* AI-assisted CICD onboarding* Slash command workflows* Self-healing pipelines* Pipeline optimization* The evolution of SEMai skills and agent contextWe're excited about where this is heading and look forward to sharing more soon.Pete Miloravachttps://semaphore.io This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit semaphoreio.substack.com

In episode 322, the co-hosts examine critical vulnerabilities, changing security standards, and adaptive defense mechanisms. They deep dive into the recent "Megalodon" breach, identifying it as a direct poisoned pipeline execution attack. Rather than exposing a flaw inside GitHub itself , researchers at Hudson Rock traced the root cause to credentials stolen from developer desktops via infostealer malware, which allowed attackers to push base64-encoded payloads into GitHub Actions workflow YAML files. To counter these types of automated supply chain threats, the hosts praise NPM's newly released "staged publishing" pipeline, which mandates two-factor authentication from human maintainers before releasing packages pushed by automated CI/CD workflows. Shifting to framework flaws, they highlight a catastrophic, vanilla SQL injection flaw discovered in GoCMS during active exploitation. Finally, the duo reviews the emergence of AI-powered honeypots highlighted Talos Intelligence. They conclude that turning the tables on attackers by utilizing LLM-driven "hall of mirrors" environments to impersonate real systems represents an innovative, under-explored AppSec strategy designed to drain attacker resources and trigger high token costs.

At Data Makers Fest, a recurring theme was the tension between GenAI hype and production reality. Speakers stressed that classical ML, MLOps, evaluation, data quality, and governance remain essential—especially in regulated sectors like fintech and healthcare. Another strong theme was inclusivity: building AI that serves smaller languages, diverse communities, and practitioners beyond the English-centric ecosystem.Ryan Chaves. Head of ML at a Dutch fintech, Ryan focused on the gap between AI demos and production systems. He argued that classical ML remains critical for fraud detection and risk scoring, while GenAI works best as an accelerator on top of existing systems. He also emphasized storytelling, stakeholder communication, and mentorship as core engineering skills.Alp Öktem. Computational linguist and researcher Alp explored the imbalance between AI progress in English and low-resource languages. Through Mozilla Data Collective, he highlighted how open datasets, speech corpora, and synthetic data can expand AI access to underrepresented communities. His broader warning: fluent AI can still fail culturally, linguistically, and ethically.Agnieszka Kamińska. Working in pharmaceutical ML engineering, Agnieszka discussed extracting scientific knowledge from research documents into knowledge graphs. Her focus was reliability: LLMs help with entity extraction and relationship discovery, but trustworthy systems still require ontologies, validation layers, and production-minded engineering. She advocated a pragmatic middle ground between AI hype and skepticism.Nemanja Radojković. An MLOps engineer in finance, Nemanja reflected on how GenAI is changing software engineering itself. He argued that coding assistants improve productivity but risk weakening engineers' understanding if overused. His central point: governance, reproducibility, and platform engineering will become even more important as organizations deploy AI agents at scale.Filipa Castro. Leading AI initiatives at Euronext, Filipa described how GenAI is integrated into regulated financial workflows. Her team uses LLMs to automate document-heavy operational processes while preserving human validation. Her broader message: successful enterprise AI depends less on flashy models and more on infrastructure foundations like CI/CD, monitoring, governance, and operational rigor.Beatriz Silva. As a student volunteer pursuing a master's in data science, Beatriz represented the conference's educational and community dimension. For her, the event was about access—networking with companies, exploring thesis opportunities, and connecting academic learning with industry practice. Her perspective highlighted how conferences like Data Makers Fest help shape the next generation of AI practitioners.Connect with speakers: Ryan Chaves. Head of Machine Learning at a Dutch fintech focused on fraud detection, risk systems, and production ML. LinkedInAlp Öktem. Computational linguist and researcher focused on low-resource languages, inclusive AI, and open language datasets. LinkedInAgnieszka Kamińska. Machine Learning Engineer working on scientific knowledge extraction, knowledge graphs, and AI systems in pharma. LinkedInNemanja Radojković. Senior MLOps Engineer specializing in regulated financial systems, AI governance, and platform engineering. LinkedInFilipa Castro. AI Lead at Euronext focused on enterprise GenAI systems, operational AI strategy, and financial services automation. LinkedInBeatriz Silva. Data science master's student and conference volunteer exploring opportunities in ML and computer vision. LinkedIn

This month's panel digs into the SpaceX Cursor acquisition rumor and what a $60 billion valuation means for AI coding tools. They debate Bun's million-line Rust rewrite generated entirely by AI, the tradeoffs of agentic coding at scale, and a sophisticated CI/CD cache poisoning attack targeting TanStack. Plus: practical takes on Claude token optimization, session forensics, local AI models, and why most Claude Code skills work best when tailored, not pulled off the shelf. Resources SpaceX/Cursor deal, CNBC: https://www.cnbc.com/2026/04/21/spacex-says-it-can-buy-cursor-later-this-year-for-60-billion-or-pay-10-billion-for-our-work-together.html Fortune, Cursor's uncertain future: https://fortune.com/2026/03/21/cursor-ceo-michael-truell-ai-coding-claude-anthropic-venture-capital/ GitHub Copilot usage-based billing announcement: https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/ Developer backlash, Visual Studio Magazine: https://visualstudiomagazine.com/articles/2026/04/27/devs-sound-off-on-usage-based-copilot-pricing-change-you-will-get-less-but-pay-the-same-price.aspx "The IDE Is Dead, Long Live the ADE", Indie Hackers: https://www.indiehackers.com/post/the-ide-is-dead-long-live-the-ade-0d81e9da3d Companies spending crazy money on AI coding tools, Medium: https://medium.com/@Reiki32/companies-are-spending-crazy-money-on-ai-coding-tools-while-developers-burn-out-efe5908f3dda The PR: https://github.com/oven-sh/bun/pull/30412 The Register writeup: https://www.theregister.com/devops/2026/05/14/anthropics-bun-rust-rewrite-merged-at-speed-of-ai/5240381 The 13,000 unsafe blocks piece: https://byteiota.com/bun-rust-rewrite-merged-the-13000-unsafe-block-problem/ TanStack postmortem: https://tanstack.com/blog/npm-supply-chain-compromise-postmortem TanStack hardening follow-up: https://tanstack.com/blog/incident-followup StepSecurity writeup (the researcher who caught it): https://www.stepsecurity.io/blog/mini-shai-hulud-is-back-a-self-spreading-supply-chain-attack-hits-the-npm-ecosystem SOC Prime writeup: https://socprime.com/active-threats/active-supply-chain-attack-compromises-node-ipc-package We want to hear from you! How did you find us? Did you see us on Twitter? In a newsletter? Or maybe we were recommended by a friend? Fill out our listener survey! https://t.co/oKVAEXipxu Let us know by sending an email to our producer, Elizabeth, at elizabeth.becz@logrocket.com, or tweet at us at PodRocketPod. Check out our newsletter! https://blog.logrocket.com/the-replay-newsletter/ Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form, and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket provides AI-first session replay and analytics that surfaces the UX and technical issues impacting user experiences. Start understanding where your users are struggling by trying it for free at LogRocket.com. Try LogRocket for free today. Chapters 00:00 Introduction 01:00 The $60B SpaceX Cursor deal 08:00 Token costs rising — the rug pull is real 09:30 Local models and sub-agent routing 12:00 Session forensics — cutting Claude token waste 15:00 Bun's AI-generated Rust rewrite 18:00 Should AI rewrite core infrastructure? 23:00 Does runtime choice even matter anymore? 29:00 The TanStack supply chain attack explained 33:00 How the GitHub Actions cache poisoning worked 36:00 Is GitHub Actions too flexible? 39:30 Ad break 40:00 Hot take — you'll be okay (local models and hardware) 42:30 Hot take — "They Will Kill You" (Jack's movie rec) 43:30 Hot take — stop hoarding Claude Code skills 46:00 Wrap-upSpecial Guest: Jack Herrington.

Take the 2026 AI Engineering Survey and get >$2k in credits and AIE WF tickets!On the product side, everyone is getting Computer - Perplexity, Manus, Cursor, and so on. Meanwhile on the research side, agentic evals like TerminalBench and GDPVal are also assuming computer (Harbor). On both ends, the consolidating LLM OS stack has become a standard toolkit, and Daytona is one of a small set of AI Infra companies that are booming because of it.“The end of localhost” has been Ivan Burazin's obsession for more than a decade.Something that is all too familiar…Long before agents became the default way people talked about software development, Ivan was already chasing the idea that development should not depend on a fragile local machine. CodeAnywhere, one of the first browser-based IDEs, was an early attempt at that future: move the development environment into the cloud, make setup reproducible, and free developers from the endless “works on my machine” tax.The thesis was directionally right, but the market wasn't ready yet.However, agents changed that. They do not care about a laptop, desk setup, or favorite editor. They need a computer they can access through an API: something stateful enough to keep working, fast enough to spin up instantly, flexible enough to resize, isolated enough to be safe, and composable enough to run the messy real-world workflows that real software engineering actually requires.Daytona isn't just selling “sandboxes” in the narrow code-execution sense. It is the latest version of Ivan's original localhost thesis.In this episode, Daytona's CEO joins swyx to explain why AI agents need more than code execution boxes: they need composable computers, stateful sandboxes, instant startup, dynamic resources, and infrastructure that can survive workloads going from zero to 100,000 CPUs.We go deep on the new agent compute market: Daytona's hard pivot from human dev environments to AI sandboxes, the New Year's Eve MVP that customers begged for, why Daytona runs on bare metal with its own scheduler, how one customer runs almost 850,000 sandboxes a day, and why RL/eval workloads went from 0% to roughly 50% of usage in just months. Ivan also explains why agents need Windows and macOS machines, why CLI may matter more than MCP, why Kubernetes is painful for this workload, and why the future AI cloud may look more like Stripe than AWS.We discuss:* How Daytona grew out of CodeAnywhere, Shift, and the “end of localhost” thesis* Why Daytona pivoted from human dev environments to AI sandboxes* Why agents need composable computers instead of disposable code execution boxes* The New Year's Eve MVP that customers chased API keys for* Why Daytona chose bare metal, stateful snapshots, and its own scheduler* How Daytona spins up one sandbox in ~60ms and 50,000 sandboxes in ~75 seconds* Why Daytona's biggest customer runs ~850,000 sandboxes a day* How RL/eval workloads create zero-to-100,000 CPU spikes* Why RL workloads went from 0% to roughly 50% of Daytona usage* Why customers compare Daytona against EKS/GKS and say they're “never going back”* Why every AI agent may need a computer, including Windows and macOS environments* The Apple licensing constraints that make macOS sandboxes hard* Why CLI gives agents more power than MCP* How open source helps agents integrate Daytona* Why agent-generated PRs may break today's CI/CD assumptions* Why AI SaaS companies reselling tokens may face a cold shower* Why the AI cloud may look more like Stripe than AWSIvan Burazin* LinkedIn: https://www.linkedin.com/in/ivanburazin* X: https://x.com/ivanburazinDaytona* Website: https://www.daytona.io* X: https://x.com/daytonaioTimestamps* 00:00:00 Hook* 00:01:12 Introduction* 00:03:15 CodeAnywhere, Shift, and the end of localhost* 00:05:58 What Daytona is: composable computers for AI agents* 00:08:07 The pivot from dev environments to AI sandboxes* 00:10:17 The New Year's Eve MVP and customers begging for API keys* 00:12:56 Bare metal, stateful sandboxes, and Daytona's scheduler* 00:17:28 60ms startup, 50,000 sandboxes, and 850K daily runs* 00:21:53 Spiky RL/eval workloads and the new agent infra problem* 00:28:12 RL workloads, Kubernetes pain, and dynamic resizing* 00:33:31 Why every AI agent needs a computer* 00:38:48 macOS sandboxes and Apple's licensing problem* 00:44:28 Why CLI may matter more than MCP* 00:48:11 Open source, GitHub stars, and agent integration* 00:53:11 Git, CI/CD, and agent collaboration bottlenecks* 00:58:15 Founder life and building a 25-person infra company* 01:02:44 AI SaaS, token resale, and API-first business models* 01:06:10 GPU sandboxes, data centers, and compute growth* 01:09:48 Why the AI cloud may look more like Stripe than AWS* 01:11:26 Closing thoughtsTranscriptIntroduction: Daytona, CodeAnywhere, and the End of LocalhostSwyx [00:00:02]: Okay, we're in the studio with Ivan Burazin, CEO of Daytona. Welcome.Ivan [00:00:07]: Thanks for having me, man.Swyx [00:00:08]: Ivan, you and I go back.Ivan [00:00:10]: Way back.Swyx [00:00:11]: How I don't even know how, you found, did you reach out or, for Shift.Ivan [00:00:17]: I reached out to you. The reason was you - we were just - we were thinking about I was one of the co-founders of CodeAnywhere, the first browser-based IDE, and so we were thinking a long time of, localhost should die. And you had this article.Swyx [00:00:29]: End of localhost.Ivan [00:00:30]: Then I reached out to you because of that, and then we talked, and I was actually at a different job and learning about I was the head of, developer experience, and you were quite well-versed in that, and I actually reached out to you, among other people, how do we go about that? What are the key things and whatnot at this point in time? And you were nice enough to take the call, and I remember I was late on your call with you.Swyx [00:00:51]: I don't remember.Ivan [00:00:52]: I remember because I was with my then I'm thinking of a girlfriend or wife at that point in time, I'm not sure. It's the same person, so that's great, and I was late ‘cause we were, in, Italy on, vacation, and then I was late for something. I felt so bad, and you were so nice to be, good about.Swyx [00:01:10]: The reason I'm nice is because I'm also late to other people, so it's like, who's, who's without sin here, yeah, so I have to, for those who don't know, InfoBip Shift, there's this whole thing that, you did in the past, and, and that was basically one of the inspirations for me starting AI Engineer, which is like, I have to thank you for giving me that push to be like, “Oh, you can, you can build and sell conferences?”Ivan [00:01:34]: I remember you asked you asked me at the beginning to give me advisory shares, and I was so focused on what we were doing, I said no, and I should've took the advisory shares. So I'm sorry, dude. But anyway.Swyx [00:01:43]: We're not, we're not venture backed.Ivan [00:01:44]: No, it doesn't matter.Swyx [00:01:45]: It's Yeah, anyway, so I think what's impressive about you is that CodeAnywhere is the thing that you've been trying to build, and, you kind of put it on hold and then came back after InfoBip. Just give us the story, do you - the story and the origin story, going into Daytona.From CodeAnywhere and Shift to DaytonaIvan [00:02:05]: Sure. Like, really way back, me and my co-founder have been together. I say this, I've said this multiple times, it's like we were married and divorced and married. Some people actually ask me is my co-founder my partner. they thought it literally. It's not literally, but we have done multiple companies together, and to your point, we had this shift where we went from the CodeAnywhere to the conference called Shift, and then back to, Daytona. We originally started stacking servers, doing like virtualization in the early 2000s and, routers and doing basically all these things, at a foundational level, and that was a services company which we sold to focus on what my co-founder actually invented, which was the very first browser-based IDE, right, I say the first. Before us was actually Heroku. They did it for a very short time until they became Heroku. But outside of them, we were the only one, and it was called.Swyx [00:02:55]: There was Cloud9.Ivan [00:02:57]: Cloud9 came out slightly after us. There was Replit, which came out when we stopped doing it, Replit came out, and they have been successful since then, which is great. There was Nitrous.io. There was quite a few that existed at the time, but it was like too early. But the interesting part is that we, at that point in time, because there was no VS Code, there was no Kubernetes, and Docker had just started when we Or I'm not sure if it was even public at that point in time. And so we had to build everything to the whole stack ourselves and that was the key learning that we brought into and that we've been using in Daytona today. So it was super early. There's about 3 million people used CodeAnywhere. It was slightly, it was angel-backed more than venture-backed. We ended up paying everyone back because it didn't have that sort of scale. But, three years ago, we started something similar with Daytona, which is not what we are today, but it was automating dev environments for human engineers, the basically the underlying stack of CodeAnywhere. And then we did a hard pivot last January to sandboxes. And so here we are.Swyx [00:04:01]: Historic pivot, yeah, and, it's one of those things where, I had independently invested in CodeAnywhere, but also in E2B, and then both of you pivoted into the same thing, and I'm like, “F**k.”Ivan [00:04:12]: You invested, you invested in Daytona. You invested in Daytona. But you were the first If we had not got your check, we wouldn't have done it.Swyx [00:04:18]: No way.Ivan [00:04:19]: No, it was like, “We have to get him on board first,” and you were that kicker that we, that got us off the ground.Swyx [00:04:23]: No, because you were putting me on your pitch deck, man. I was like, “Man, this is like a good trip if I don't invest.”Ivan [00:04:29]: That's because it was your quote. It's like we.Swyx [00:04:30]: Yeah. It's the end of localhost.Ivan [00:04:31]: Did a bunch of research about end of localhost and who was interested in that,.Swyx [00:04:34]: No, that's like, I put, I wrote that blog post, and every single company in that field reached out to me, and then every VC who was receiving those pitches then also had to call me and, talk it, talk through it with me.Ivan [00:04:47]: It's finally happening though.Swyx [00:04:48]: It was really super interesting.Ivan [00:04:48]: It's finally happening.Swyx [00:04:49]: It's finally happening.Ivan [00:04:49]: Yeah, it's finally.Swyx [00:04:49]: It's finally happening, with maybe sort of non-human users. Yeah, so what is Daytona today? Let's get like a quick description. I'm wearing the shirt.What Daytona Is Today: Composable Computers for AI AgentsIvan [00:04:58]: You're wearing the shirt. Yes,.Swyx [00:04:59]: It says, I think your branding is very good. Like, it's very consistent. It runs AI code. Like, it cannot be simpler.Ivan [00:05:05]: Exactly, but we're gonna probably have to change that.Swyx [00:05:07]: Oh, s**t.Ivan [00:05:07]: It's also a subset of what we do. Unfortunately, we really love this, Run AI Code is super simple. People interpret it different ways. I think we've given out 5,000, 6,000 of these shirts. People wear them with pride because it doesn't really market about us.Swyx [00:05:21]: Yeah, Daytona's on the back.Ivan [00:05:22]: It markets the back. It markets to the person itself, so I think we did a really good job on that one. But it is also a subset of what we do, because people, when they think about Run AI Code, they just think about these small, let's call it isolates, code execution boxes that, you send some code, you get an output. Whereas what Daytona is today is essentially composable computers for AI agents. It is, the market calls them sandboxes which can be misleading.Swyx [00:05:44]: All these things. All these things on.Ivan [00:05:45]: Yeah, exactly, ‘cause it can be misleading ‘cause people usually think about sandboxes as a demo or a test environment versus a production-grade environment. But what Daytona does, if you think of the laptop that you have in front of you or the computer that's over there, or, my wife is an architect, so she has like a Windows with a 3D graphics card inside to do 3D rendering. Like, as humans, we have different computers or different compositions of computers. And our belief is strongly that agents today and going forward will need all these different compositions of computers to do different types of tasks. And so we offer that basically through an API.Swyx [00:06:19]: Yeah, to give people - I'm trying to sort of front-load all the aha moments or the wow moments so that people can, stay engaged and click like and subscribe. the market is exploding, right? Like, you have been reporting 74% month-on-month growth, and it also, it's just been growing for a while. Like, it's been going like this. And every single - It's not just you guys. It's every single.Ivan [00:06:41]: Everyone, yeah.Swyx [00:06:42]: Sort of, compute provider. I don't know if you agree with me saying compute provider or not.Ivan [00:06:48]: It's fine.Swyx [00:06:48]: Yeah. So like organically PLG-driven growth, but also enterprise is doing super well, I think I wanna rewind to January of last year when you did the pivot. Like, so you obviously called this market early, and you were positioned for it, and you are now one of the market leaders. But what was the insight that made you do the pivot?The Pivot: From Human Dev Environments to Agent SandboxesIvan [00:07:06]: The insight that made us do this pivot is the quarter before that, so end of 2024, when we had - Basically, we did a demo with - I don't I think we discussed this as well, Devin was not public. You actually gave me access to Devin at that time. So Devin.Swyx [00:07:25]: I did?Ivan [00:07:26]: Yeah, you gave me access.Swyx [00:07:26]: I don't think I was supposed.Ivan [00:07:27]: Yeah, exactly.Swyx [00:07:28]: Yeah, I.Ivan [00:07:28]: So it doesn't matter. You.Swyx [00:07:29]: Yeah. I gave like three friends access.Ivan [00:07:31]: Yeah, or it was a call and you showed it to me. It doesn't matter. but OpenDevin was available, which is now called OpenHands. And so we're like, “Oh, this seems to be a thing. This is not public. Let's take our for human automation of dev environments and take, OpenDevin and launch that as a SaaS.” And we did that. Not very many people signed up and used it, but a lot of people reached out that were building agents, and they were like, “Hey, my agent needs a compute sandbox runtime,” whatever you wanna call it. I forgot what it was called at that point. And then we were like, “Oh, amazing. This is a new market. Here is our infrastructure. Here's our product, and go.” And what we found really fast, soon, was that people did not like what we had built. It didn't work. And I remember talking to people at the beginning when we're doing this, the sandbox we're building for agents. People were like, “Oh, why is it different? It's the same thing. We have like EC2, we have VMs, we have all these things.” But we saw that everyone we gave it to, it was like 20, 30 people, they all said, “No.” Like, “This is not what we need. This sort of breaks.” And basically, me and my co-founder not knowing a lot about - ‘cause we're infra people. We're not AI people. So I basically took it upon myself to like watch every single podcast that exists, including all of, all of these and all that, and sort of get up to date, read all the blogs, like get, understand what's going on.Swyx [00:08:45]: Do you wanna shout out who else was useful, just in case people are also looking.Ivan [00:08:49]: Generally we -, I looked at There's a few of podcast, different segments and different types. So there's you guys, No Priors, Bill Gurley's was great while.Swyx [00:09:04]: VG2, yeah.Ivan [00:09:05]: Yeah, while it was around. So there's a few. 20VC is interesting from a different dynamic, and some are different dynamic. But there was, also Red Points.Swyx [00:09:14]: We're not really about the compute market.Ivan [00:09:15]: It was also already - Sorry?Swyx [00:09:16]: You're, you want - You're looking at the agent infra market.Ivan [00:09:19]: I was looking at the agent market and the AI market in general and sort of understanding who are the players, what the perception, and how that goes. And like obviously you complement this with like going to conferences, going to events, going to meetups, reading white papers, like doing all the things that you have to do to understand what's happening. And so when we figured, when we sort of had an idea of what we had to build, literally over the New Year's Eve, literally on New Year's Eve, I half vibe coded the first MVP, first minimal viable product of what Daytona is today. And I went to sleep at like 3:00 AM or something like that. I was doing - I just put my like baby daughter and wife to sleep and, Happy New Year's, and go back to just, doing this. And I sent it to my co-founder, my CTO, and he saw it in the morning. He's like, “This is absolute garbage.” “Do not show this to anybody at all, but the idea is good.” And so he took two weeks, and he rebuilt it.Swyx [00:10:09]: Did it like look like that? Listen, I - It was rough idea.Ivan [00:10:12]: Oh, not even, not even close. Like it was it was way worse. But it was like a very - It was a simplistic view of what it should be. Like, it worked, but it was not ideal. And so he went, we went down the whole, which is his job as CTO, to go, and he came back with this version. We then called all the people that had said like, “This is garbage,” a quarter ago. And we set up these calls, and we gave it to - We just demoed it to everyone. And all the calls went long, every single one. They were 15-minute calls, and they all went to like 25, 30 minutes or whatnot. And everyone said, “We need, we want access.” There was no login, just an API key, ‘cause it was just a beta or an alpha. And they said, “Oh, we want access.” And we're like, “Sure, yeah. Okay, thank you very much.” But after like the next day, if we'd not send it, every single one, like every call that we did, everyone came back, “Where is my API key?” Like everyone wanted it. We're like, “S**t.” Like this is it. Like I've never felt So one, the understanding to your point was like most people thought it was the same infrastructure for humans and agents. We understood a quarter ago it's not. We just didn't know what was the right primitive. And then when we came, and we can talk about what that is, and we gave it to these people, I've never seen, I've never experienced - I've done multiple companies in my life. I've never experienced this, that people literally call you if you do not give them access. Like they want access right now. And so it's like, okay, they don't want this. the thing that they want doesn't seem to exist, or they have not found it, and they really want what we want. And then when we understood that we're onto something, and then when you think about the size of the market, like the market for human engineers and enterprise is a very large market, so think GitLab or whatnot. But the market for every single agent that will exist ever in the future is just like, what is that market? How big is that? And we're like, “We are all in on this.” And so that is where we made sort of the cut between the old product and the new one.Bare Metal, Stateful Sandboxes, and the Lambda + EC2 ModelSwyx [00:12:02]: Yeah. But it wasn't composable at the time?Ivan [00:12:05]: It was very - It was basically just a Linux box that you could change, that you could define number of CPUs, disk, and RAM. Like that is what you could do, but you couldn't have multiple operating systems, you couldn't resize it on the fly, you couldn't add a GPU, you couldn't do like all the things. It was just the, just the first sort of variation of that, yeah.Swyx [00:12:22]: Was it bare metal from the start?Ivan [00:12:24]: It was bare metal from the start. And so the interesting thing that we thought about right away, so our.Swyx [00:12:29]: Which, give people the background, what is the normal path?Ivan [00:12:32]: Yeah, so, basically most providers run this on top of VMs. And also.Swyx [00:12:37]: Firecracker.Ivan [00:12:38]: Yeah, they run on Firecracker and VM. And so we also fire - We can get - We have multiple isolation layers and we can do that. But the common way to do it is that they, one, that the state of the machine, or the hard disk is not part of the sandbox itself. And the other thing is they're not meant to last forever. So most of them are preemptible, like they can There's a time that they can live. And so our thought was when we were going into this is, agents will be like humans in the sense of you don't want your laptop to be shut down until you're done with work. Like, and you want to close the lid and open the lid, it's the same state. So you - Agents would want that, like the pause and come back. They want those two things. But also agents really want speed, right? Can they get it? So when we thought about it's like we need something insanely fast, how to make it fast, how to make it long-running, and stateful. And so those two things, it's like combining a Lambda and an EC2, right? Those two things together. And so we didn't have an idea how others did it, ‘cause we didn't know too that there was a market around this. It was more like, okay, this is what we need, what they need. And we looked at Kubernetes, it wasn't wasn't good enough for that. We looked at Nomad, it didn't enable that. And so our history in rewriting our own scheduler at CodeAnywhere is basically what my CTO came up with. Like, he's like, “Oh, the learnings from there,” and he brought it. And the funny thing is, our third co-founder, when he saw it, he's like, “Dude, what is this? This is like 2008.” Like, we went back in time, and he's like, “Exactly.” And so the reason why Daytona is like super fast, and you see this on benchmarks, is we essentially, we run on bare metal. We have our own scheduler, we use the underlying, disk, CPU, and RAM of the underlying machine, which means your IOPS are insanely fast because there's no, there's no network between an EBS or something like that. But also the snapshot, the point in time, the templates, are also preloaded on the bare metal machines. So when you fire off a sandbox from a template or a snapshot, you're essentially directed to the bare metal machine where that snapshot is based on that NVMe drive, and then it literally just turns on that machine, and it's local. There's no network latency, anything on there. And so that is sort of the specificities that we, when we're thinking from first principles, what a computer would look like for an agent, that is what we came up with, and that's what we created.Benchmarks, 60ms Startup, and 50,000 SandboxesSwyx [00:15:02]: Yeah. I should maybe, I don't know if you endorse this, but there's someone that does compute SDK, you guys do very well on there, with like the TTI, right? I. is this a, is this a is this a relevant benchmark for you guys? I don't know.Ivan [00:15:16]: I don't know, and it changes every day. So today RKL is.Swyx [00:15:18]: I don't know what RKL is. Never heard of it.Ivan [00:15:20]: Yeah. RK, yeah, so it is there.Swyx [00:15:22]: You are, at least a third of the next tier of performance, and then, there's a lot of other better-known names that are very slow to start.Ivan [00:15:31]: Yeah. We've been the number one by far for a long time, and now there's different, there's different definitions also of sandboxes, different isolation patterns, different other things. So RKL runs it literally on the S3, the data, so it's very different, and they spin up a sandbox, spin up a container for that, so it's a different type of thing. So the definition of a sandbox is something that we can all, we all need to get along with. But yeah, we're insanely fast on getting these things, up and running. And so you can see even there that it's a zero point 0.10 to 0.11, so.Swyx [00:16:03]: Close enough. Yeah. what else do you need, right?Ivan [00:16:05]: Yeah. So the benchmarks itself, so, in this, in I don't think the benchmarks equate to market ownership or revenue or anything like that. and I've seen this with multiple benchmarks, not just in sandboxes, but in general benchmarks around.Swyx [00:16:20]: It's table stakes. It's just like.Ivan [00:16:21]: Exactly. But it doesn't hurt.Swyx [00:16:22]: Just roughly check.Ivan [00:16:22]: Like you definitely have to be up there and you have to be competing so that people know that, oh, this is definitely one of the top. Because this is only one dimension of what customers look for. There's other things like how many can you spin up consecutively? There's a feature set, there's support, there's like all different things that people look at, but you definitely have to be there, on the benchmarks.Swyx [00:16:40]: How many people do people spin up consecutively?Ivan [00:16:43]: So we have.Swyx [00:16:43]: Or concurrently, is the Concurrency, right?Ivan [00:16:45]: There's three metrics that we look at. And so one is like time to spin up one, and so our time to spin up one is 60 milliseconds with network latency. So request, spin up, reply, 60, the whole thing, 60 milliseconds. That is one. But if you wanna spin up 50,000 at once, we are now at about 75 seconds. So it takes about 75 seconds to spin up concurrently 50,000. Some others, there's public data around this, like take 2,000 seconds, which is 30 minutes. Like there's different variations of that. And then there is the so it is speed of one, speed of like multiple, and then how many can you consistently have up and running. And so we basically have right now no limit to how much we can add because we basically own our own metal. But the biggest customer of ours does like about 850,000 every single day is sort of where they're, where they're just shy of a million every single day that they're running, we do have a request for half a million concurrent, which is literally half a million CPUs somewhere running. So that's an interesting.Swyx [00:17:44]: They pay by like vCPU seconds.Ivan [00:17:47]: By seconds, yeah.Swyx [00:17:47]: Or whatever. Yeah. Okay, and so and then, and the other thing is, the sleeping and the resuming, ‘cause it's all the stateful resumption of all these things, how, what kind of workload are people putting through this, right? Like how is it Do we measure by gigabytes in memory, gigabytes in storage? I don't In like network attached storage. I, what are the costly ones of, out of all these features?Workload Economics: CPU, RAM, Network, and StorageIvan [00:18:15]: The most expensive thing are CPU.Swyx [00:18:18]: Okay. Yeah, of course.Ivan [00:18:18]: The second one, yeah Then it's RAM, then it's disk. We actually don't charge.Swyx [00:18:22]: Which is snapshotting, right?Ivan [00:18:23]: No, it's actually the, snapshotting's part of it, but basically the size of your hard disk, of your machine. So do you have 10 gigabytes, do you have 20, do you have 50, do you have whatever? And then the transference of that. Right now, currently we don't charge for, network at all at Polychron.Swyx [00:18:37]: Oh, you gotta, yeah, you gotta fix.Ivan [00:18:38]: Yeah. It is very much a it's a larger and larger part of our bill, so we're working around, that part there. Obviously, that is the least, expensive, so the hard disk is the least expensive, so it's basically CPU, RAM, for us network, ‘cause we don't charge the customer, and then hard disk, is how it's split up. But there's also different types of workloads, so we basically split it up into two types of workloads in Daytona. One is what we call background agents or long-running agents. and the other is, basically RLs and evals, which I put sort of together. And so they have very different patterns of usage, and if you look at the usage of a background And I'll just name names of companies, not specifically.Background Agents vs. RL/Evals: Two Usage ShapesSwyx [00:19:21]: Yeah, open, all hands.Ivan [00:19:23]: Yeah. So like a background agent's a Cognition, a Lovable, a like all these things are Harvey. These are all long-running, background agents. And so if you look at their usage patterns, their usage patterns are similar to human, which is like follow the sun. Basically, the usage patterns of that is like noon is probably the highest, and the midnight is the lowest, and then weekends are lower. weekday is higher.Swyx [00:19:42]: Yeah, that's a fun question. How global is it? Is it very US-centric or?Ivan [00:19:46]: The US is a large part, but we have currently, we have Asia, Europe, and the US regions.Swyx [00:19:52]: So it's quite global.Ivan [00:19:53]: Yeah, it's quite global. We have it all over. It's interesting that our I talked to you a bit about this. Our number one city by user.Swyx [00:20:01]: Hmm.Ivan [00:20:02]: Is Singapore.Swyx [00:20:04]: Oh, wow. Amazing.Ivan [00:20:05]: Which is an interesting one, right? Not by revenue, just by just like by individual head count.Swyx [00:20:09]: Really?Ivan [00:20:09]: Just like an interesting thing.Swyx [00:20:10]: Singapore is, Singapore is weirdly high in the adoption charts of AI for the population. It's like an, seven, eight million population. And it's like keeps showing up.Ivan [00:20:20]: No, it's quite interesting. We were quite shocked, and I was like, “Oh, this is interesting.” And also one that's up there.Swyx [00:20:24]: There's a reason I'm doing AI using Singapore. it's because I'm from there.Ivan [00:20:27]: We're there. We're gonna, we're gonna be there as well. and it's interesting that Japan is in the top or like Tokyo's in the top, which is in all the tech cycles it has never been. It has never been, so it's quite interesting that they're.Swyx [00:20:39]: I think the Japanese just love AI. Yeah. It's that, and then it's Brazil. That's it.Ivan [00:20:44]: Brazil has always been in.Swyx [00:20:45]: I think.Ivan [00:20:46]: Even when I look, if you look at like GitHub's data and ask historically with CodeAnywhere, it was always like US, Western Europe, and then you'd have like India, Brazil, China, like that would be there. But like Singapore was not in, specifically Japan was never in sort of that top, that top.Swyx [00:21:01]: Yeah. Weird pockets.Ivan [00:21:01]: Weird. Yeah, so it's very global.Swyx [00:21:02]: Okay, so actually that, but that's helps you to distribute your load through, all time?Ivan [00:21:08]: The interesting thing is like we have those kind of loads, but if you look at the researcher loads, they're quite different. So what they are is like if you give them concurrency of 10,000 or 50,000 or 100,000 CPUs at ARMb, when they fire off a run, it's just 100%. And then it just runs, and then it stops. So it's very, the usage pattern is squares basically, right? And it's also not follow the sun, because people will fire it off at midnight before they go to sleep but then wake up and so it's very unpredictable, so you don't know where that is. So the shapes of the usage are quite different than we have had before. And also what's interesting is when it's sort of a follow the sun, even if you have a high growth company, you can sort of predict your usage patterns and have enough capacity for that, because it's sort of, it grows in a, in a way you can project. When you have companies doing sort of like evals and RL, they're super spiky. So they're gonna come in, it's like, “We're gonna use nothing, then can we have 100,000?” Right? And then go back down. And then 100,000, go back down. So it's very different, right? And.Swyx [00:22:09]: Do you want to lock them into commits so.Ivan [00:22:11]: Yeah, we do.Swyx [00:22:12]: Yeah, okay.Ivan [00:22:12]: We so we have to lock them into some sort of commits to have that capacity, because we have to have, basically we have to have the capacity for peak. Right? And so right now, Daytona's mean utilization is 15%, 1-5.Swyx [00:22:25]: Oh my God.Ivan [00:22:26]: So it's very low.Swyx [00:22:27]: Because it's very spiky.Ivan [00:22:27]: It's very spiky, but we get up to 90%. so we have these things. And so what we're, what we're looking at right now as a company is similar to Cloudflare where you can like geo move things around, but that works really well for basically the background agent where it's follow the sun. But this, it's not. Like it's a very different shape. Obviously with scale you figure these things out, but that's an interesting new problem that we have, as a compute provider in the agent space. And when we were doing the conference recently, and so we talked to like Nikita from Neon and.Swyx [00:22:57]: I should bring it up.Ivan [00:22:58]: Parag from Parallel and whatnot, everyone has the same problem. Whereas the usage is super spiky, and this is something that has not happened before, that you have these types of like it was always, it the amplitudes were not this high, right? So it's quite interesting use case and problem solve.Compute Conference and Spiky Agent InfrastructureSwyx [00:23:12]: Yeah, I don't know if we're gonna bring this up again, but let's just talk about the conference, you had like 1,000 something people at the Warriors game, at the Sorry, where is it? What's.Ivan [00:23:22]: Chase Center.Swyx [00:23:23]: Chase Center.Ivan [00:23:23]: Chase Center.Swyx [00:23:24]: I went. It was, it was very impressive. Obviously, you can, how to throw a conference, what did you learn? you put, you pulled together all these impressive names.Ivan [00:23:33]: What I.Swyx [00:23:34]: What were you looking for?Ivan [00:23:35]: My thesis behind the Compute Conference was let's bring together people that are building infrastructure for AI agents. Because when I think of what we're building, it is the agent is the primary user, what are the ergonomics and usage patterns of agents, and so we can do that. And what I found, this was a theory, it wasn't proven, is that we all have these problems, as I touched onto. And I was, as I was talking on stage, it was like we all have the same underlying infra problems, which is this spiky workloads, unpredictable workloads that we've never had before, in human, compute or human infrastructure. And it's, again, it's the same when I was talking to Parag or when I was talking.Swyx [00:24:20]: Lynn. Nikita.Ivan [00:24:21]: Lynn, Nikita. Lynn especially, I was talking to her the other day as well. Like the It is a very interesting type of problem to solve because I can touch on Cloudflare because there's a lot of like talk about that recently as to how they solve that, which is they have a bunch of geos, and basically, as users work in different places, and depending on your tier, they can move you around the geos. And so that how, that's how they get the higher utilization. But you can sort of predict these, and it's If it's something in You'll rarely get a spike that is 10 orders of magnitude. Like you'll get a like let's say one of your customers has some like an exponential curve. What is that to I'm using Cloudflare as an example. 10%, 20%, whatever it is. I don't, I don't have this data, I'm just assessing. It's surely not 10x, right? It's surely not something there. And so how do you go out and solve this problem? And we're all solving this in different ways. So we have.Swyx [00:25:11]: She also has the same thing.Ivan [00:25:12]: Yeah, I know specifically that like Neon had that issue as well. Like how are we solving these spiky loads and things like that ‘cause we talked about it. And so the interesting thing for me to actually internalize was, yes, everyone that's building for agents first is going through this, and we're all solving similar problems, which is quite.Swyx [00:25:28]: Let me let me double-click on this. Okay. So for example, Neon, I happen to know that they're very sort of S3 oriented, right? so they're just like fully bet on S3. And you get to benefit from S3's distribution and infrastructure. So I would imagine that Neon doesn't have to care, whereas Lynn maybe has to care a bit more because obviously she's doing GPU inference. And, for listeners, we did an episode with her, one and a half years ago. And you have to care. But like, right?Ivan [00:25:54]: Parag cares for sure, and Nikita.Swyx [00:25:58]: And Parag is C of, Parallel.Ivan [00:25:59]: Parallel, yeah.Swyx [00:26:00]: Former CTO of Twitter.Ivan [00:26:01]: Twitter, yeah.Swyx [00:26:02]: They are the search.Ivan [00:26:03]: Yeah, they're search, yeah.Swyx [00:26:03]: I You and I know but the listeners don't know.Ivan [00:26:08]: Yeah, we can put it down in the screen, and so ‘cause we, when we were talking.Swyx [00:26:11]: I'll put it up on the, on the screen.Ivan [00:26:12]: Yeah, right.Swyx [00:26:12]: People can look it up if they need.Ivan [00:26:14]: Look it up. And, yes, but they still have CPU and RAM, allocation that you have to have up and running. And so CPU and RAM, you have to allocate that and have that ready. And so there's basically two ways to do it. One is you either over-provision and you can handle the bursts, or two, you basically have, I don't know if this is a term, just-in-time compute, which is like as your load becomes, as your usage comes in, you can fire off requests for VMs or bare metals at other cloud providers and then get them up and running.Swyx [00:26:43]: This is if you go above 100%, right?Ivan [00:26:45]: Yeah, this is.Swyx [00:26:46]: Like your overflow.Ivan [00:26:46]: If your overflow, like spillage or whatever you do.Swyx [00:26:48]: You probably lose money on it, but it doesn't matter, right?Ivan [00:26:50]: It, not Well, you might, you might not That is a more cost-effective way to do it but it's a slower way to do it. Because basically what you have to do is you have to like queue your requests, spin up these just-in-time compute, get it all ready, provision it, and then get your workload there. And so if the time isn't important that much, that's fine, and you can do that. But if your customer, and especially for, let's say, the RL training runs, the reason why a lot of people come to us is because GPUs are more expensive than CPUs, right? So you want your GPU running at, what, 100% the entire time. And so when you're running runs on CPUs, when the when the CPU cycle is like down and spinning up the next one, you want that to be instantaneous so that your GPU doesn't go down, right? And if you then have to like go out and provision machines, you're essentially telling the GPU that it has to wait, and that's incurring our cost. So there's things that you have to try to solve for there.RL Workloads, Declarative Images, and Kubernetes ReplacementSwyx [00:27:43]: Yeah, let's talk about the different workload, right? You said that, what was it? A few months ago, you had zero RL workload and now it's 50%.Ivan [00:27:52]: It will be this one, 50%, yeah.Swyx [00:27:54]: Let's talk about how different it is, right? Like I imagine, for example, a lot less dynamic code generation of like arbitrary code. Like here, it's probably all the same code. You're just doing parallel runs or something, I don't know.Ivan [00:28:05]: Yeah. So you'll have multiple Depends on the like for each run, you'll have a snapshot. And they, for the most part, they actually do use our declarative image builder, which is like, “Oh, we, the agent wants these dependencies, these env vars.”Swyx [00:28:17]: These ones, yeah.Ivan [00:28:18]: Yeah, the declarative image builder, it.Swyx [00:28:20]: Which is a very modal like thing that they.Ivan [00:28:22]: Yeah. And so we build it on the fly and then we propagate that snapshot, and you can spin up as many sandboxes as you want against that snapshot. And then if you have to do changes, the model can, or like it could be also be automated. It's like, “Oh, now for the next run, we need to install these things or remove these things or whatever to get, a task done,” and then it goes off and runs that. So yes, that is something that it seems that they prefer. The number one reason I found, or should I say, let's take a step back. What we are competing against in that environment is essentially managed Kubernetes. So EKS, GKE, whatever. That is what the vast majority run on. And anyone that has tried Daytona versus GKE, EKS is like, “I'm never going back.” That has always been. There's a few reasons. One is the ergonomics. So if you have, if you're using Kubernetes to spin that up, you have to essentially manage the interface interactions with that. Daytona, although as a compute provider, it's more akin to a Twilio and Stripe from a consumption perspective than it is an AWS. Like you have an API, an SDK, it's quite like easy and seamless to get these things up and running, that's one. The other is the speed to which we spin up, which we mentioned earlier, which is much faster, and the scale to which we can go to. We haven't got into features, but an interesting feature is that it's very hard to OOM, or out of memory, our sandboxes, because we can dynamically on the fly.Swyx [00:29:48]: Resize.Ivan [00:29:49]: Resize, which is like impossible on almost any other thing. There are some technologies that enable you to do that, but it's like a very hard thing. And so we actually saw this when, the Terminal Revenge team is, brought us actually. So thank you, Alex and the team, that brought us into this whole space.Swyx [00:30:05]: It's just very rare that, a framework would just say, “Guys, just use Daytona.”Ivan [00:30:11]: Yeah, I think it says it somewhere. Yeah.Swyx [00:30:13]: Yeah. I was like, “What is this?”Ivan [00:30:15]: There's all, there's multiple there, but they also mention a few other places. and so Daytona specifically-We have, the, just jumping on themes here We, I don't know where it says Data Center.Swyx [00:30:27]: I, there.Ivan [00:30:27]: Doesn't matter.Swyx [00:30:28]: There's a very strong recommendation, which is, very unusual. Which is, it's.Ivan [00:30:33]: We do not pay them for this, just.Swyx [00:30:34]: I know, yeah. They just like you.Ivan [00:30:35]: Yeah, they like us. yeah, and also a thing, so, Data Center has multiple isolation sets underneath. The customer doesn't have to know what they are. But basically we have Docker, which is a container, that's hardened with Sysbox. So it's Docker's, isolation that is a security equivalent to a VM, but it's still a container. And that is the default, and they, especially in these training workloads, really like that as an interface to be able to use just a basic Docker container, and we enable Docker and Docker. Which for these RL runs, if you need to do a Docker compose or Kubernetes, you can spin up a K3S inside of these things, which unlocks a huge amount of workloads that you can do that you cannot do on other providers. So just on that part is much more interesting. And so we went that, through that. We showed them that we could do that, and they enjoyed that quite a bit. They being the general venture people.Swyx [00:31:28]: Those people, yeah.Ivan [00:31:29]: And Harbor people.Swyx [00:31:29]: Harbor people, do are they, are they a company yet?Ivan [00:31:33]: As far, I do not know.Customer Pull, Slack Connect, and the Computer Use BetSwyx [00:31:35]: Okay. All right. Yeah. It's like super obvious that like, there's a lot of excitement and success around these things, okay, so yeah, tell us more, right? Like, this is an exploding workload, Harbor adopted you, which helped speed things along. But what are you learning as this new workload comes online?Ivan [00:31:53]: There's a couple things that we learned, which we chat about in the beginning. We, and this has led our story, as we mentioned, we like talked to a lot of customers along the way, and we add more features and more tool sets as we talk to customers. And it's interesting that And I think it's that the ecosystem is so small and/or the models get smarter, where when we see one user come with a request, we know it goes on a roadmap if like three to five customers come with the same request in that week. It's like very bizarre. It happens so many times, which is.Swyx [00:32:27]: Because they're all friends.Ivan [00:32:28]: Sorry?Swyx [00:32:28]: They all, they're all friends. They're all in the same group chat.Ivan [00:32:30]: Yeah, probably, yeah. ‘Cause and they're like, “Oh, can you do this?” And I'm like, “Okay, this is interesting. We'll put it on a feature request.” And then the next one's like, “Oh, can you do this?” “Okay.” It's all the same, right? It's always the same. And so what we try to do, and I personally try to do, I try to be on as many call, quote-unquote “sales calls” I can. I'm in every Slack channel. We literally have about 1,000 Slack Connect channels, something like that. It's an interesting, there's so many interesting things you find out when you have all the Slack channels. You can also see where people, transfer between companies. You see leave Slack channel, enter Slack channel. It's an interesting thing. Also, just I digress, I feel that Slack Connect is literally LinkedIn what it should be. You have a list.Swyx [00:33:08]: LinkedIn charges you to, use your own connections, but Slack doesn't, right? Slack is like, do it for free. It's more lock-in. It's great.Ivan [00:33:15]: Yeah. It's amazing. Yeah. It's one of the reasons.Swyx [00:33:17]: You're gonna pay Slack for life.Ivan [00:33:18]: Exactly. You're there for life. So that's interesting. And so one of the things, the newer things we were talking about earlier is we made a big bet and put a lot of investment on computer use. that is not seen publicly the light of day. We haven't GA'd that yet, but we have.Swyx [00:33:32]: Is there a thing I can pull up?Ivan [00:33:33]: There is computer use there. It's right up a bit.Swyx [00:33:36]: Oh, yeah. Okay.Ivan [00:33:38]: What we have, what we talked about and what we've seen publicly is there's this theme now about, the human emulator where And Elon from XAI has talked about this publicly, and if you think about the models today, they're actually quite sophisticated and they can do a lot of work, but they still don't have access to all the tools. Like, I'm a strong believer that the most efficient way for an agent to work is essentially headless or through, terminal or whatnot. But if we, if we look at knowledge work in general, there's about 100 million knowledge workers in the US, about a billion in the world, and knowledge workers, and the salaries of them aggregate to 10 trillion in the US 50 trillion worldwide.Swyx [00:34:24]: Wow.Ivan [00:34:25]: Something like that. And if we look at, the five most important sectors of that, so like healthcare and government and financial services and whatnot, that's about 56% of that. So let's say it's about half of that. So in the US it's about 25 trillion, and most of them, most of that work is actually still locked into legacy apps inside of Windows, which is not going anywhere for a very long time. Like, people just won't invest in that. How much of it? our assumption is the following: if, in the RPA market, which is similar market, well, not the same 25% of, these white collar, workers', work is automated. If an agent is more sophisticated, can go through more runs, figure stuff out, let's say it's, 40%, right? And so if you take 40% of that, you get to essentially, $10 trillion a year.Swyx [00:35:17]: That's a TAM.Ivan [00:35:18]: That is a that is a TAM. So that's the TAM of the models, right? That's not our, essentially ours. But you get to that size, and to be able to do that, you essentially have to give agents these computers with the legacy. So computer use, either Mac or Windows or Linux. Linux we also obviously have and others have. But Windows specifically is something very new, and the only option right now is an EC2 with, Windows or on Azure. Both of them take anywhere from three to five minutes to spin up. We've created an actual sandbox, so it's a second instead of milliseconds, but you have, point in time snapshots, you have, forking, you have all the things that you have from a sandbox, but essentially enables you to hopefully unlock all this value. And so that's been our big push and bet, but we've sort of, kept our ear to the ground. What is sort of the next things in the market?RPA Returns: Why Agents Still Need ComputersSwyx [00:36:06]: Yeah, knowledge work, and building, and sort of RPA, the next wave of RPA. I got very excited about RPA kind of during COVID times. The UI path was IPO-ing. And it was, a very hot Isn't it, Eastern European?Ivan [00:36:20]: It is, Romanian.Swyx [00:36:21]: Romanian?Yeah, it might be the only Romanian, big unicorn okay, yeah. This I don't I don't, I don't have like a I think there's, I think there's a stage being set for the resurgence of RPA, ‘cause everyone understands that, yeah, no one wants to deal with these shitty apps and no one's gonna rewrite them. Like, you just have to do, a remote operation and programmatic operation of them.Ivan [00:36:45]: If you wanna unlock it, my own setup was basically the following. So I was doing a board deck recently, last month, whatever, and I'm like, “Okay, let's just, let's just do automated.” So, all our data's in, ClickHouse and PostHog and QuickBooks, where everyone else's is, and I'm basically, connected that all to, my Cloud code, like go off and go Cloud code whatever. Go off and, here's the integrations, go do that. It pulled out the first report, which was great. It connected to Brex and all these things, pulled it, which was great, and then I say, “Okay, now pull out this, and this,” and I kept getting, really well McKinsey-style design reports, but the data said partial data. all the missing data, partial data. Like, it can't access all the things, and I got so frustrated, and so I got, I got, my Mac Mini virtual sandbox with OpenClaw. I gave it its own account in our company, and then I went to all these services and created a read-only account, so literally like an intern in your company. And so I would say, “Now go and do this report,” and it would get the same, or like, “I can't via the MCP or the API or whatever. I can't get all the information.” I'm like, “Go log in.” And it will log into the website, then go in, export the data. It'll export the data and do the thing end to end. So even for things that have today APIs, not all of it is exposed, and I to get value, I get immense value right now, but it has to be a computer usage, unfortunately, and so I spend a bunch of tokens just on that, but I get the job done. And so if even a startup like ours, and using all the hottest tools, still needs a computer agent what hope does, Goldman have to have a headless, right?Swyx [00:38:22]: Yeah, what a - Why isn't Microsoft doing this?Ivan [00:38:27]: I'm pretty sure, Satya had a post yesterday.Swyx [00:38:29]: Oh, okay. I see.Ivan [00:38:29]: Which was like, “Every agent needs a computer.”Swyx [00:38:31]: I see, I see.Ivan [00:38:32]: So they have launched something recently.Swyx [00:38:34]: Yeah, they have Microsoft Power Automate, I'm sure, I'm sure, they're gonna have their version.macOS Sandboxes, Apple Constraints, and the Windows OpportunityIvan [00:38:39]: Version of that, yeah.Swyx [00:38:39]: You're gonna try to do yours, and it - I always know there's always demand for Mac, but I know it's, tricky to host, macOS sandboxes.Ivan [00:38:49]: We will have macOS sandboxes fairly soon. The problem with macOS, OS sandboxes is, I'm deep in this, I don't know how much interesting is.Swyx [00:38:55]: No, it's.Ivan [00:38:56]: MacOS has this problem.Swyx [00:38:57]: It's a licensing thing, right?Ivan [00:38:58]: Licensing thing. So one, you're allowed to run only two parallel VMs per machine, so that's one. Two, you can only license to a different user every 24 hours. So if you come in and theoretically, if I wanna charge you per second and I charge you one second, I have to have it idle for the rest of the day. I can't have anyone else doing that. So the pricing will be different in the sense that I will have to - we would have to charge for 24 hours, and that's not even, that's not even the most difficult thing. But the, thing above that is, from a security perspective, they enable you to do memory snapshot, pause, resume, but only on the same physical drive, physical machine. And so what you can do in, Windows world or Linux world is that I can move in the background, your snapshot from one to the other and manage load, right? Here, if you wanna do that, you essentially have to have your.Swyx [00:39:49]: Yeah, snapshots. Yeah.Ivan [00:39:50]: Your.Swyx [00:39:51]: It's like.Ivan [00:39:51]: Physical machine.Swyx [00:39:52]: You can't break it up.Ivan [00:39:53]: You can't, you can't move things around that, and all of that is, that part is, from a security standpoint, if it is written. Like, I understand the security aspect of that, but it disables you from doing these agentic, like really scalable agentic workloads.Swyx [00:40:08]: You need to do a vibe-coded, clean room implementation on macOS that you can then - That's like Clean OS or something. I don't know.Ivan [00:40:17]: So. We have.Swyx [00:40:18]: ‘cause like Linux was originally like a clean room rewrite of Unix.Ivan [00:40:21]: Okay. Yeah.Swyx [00:40:21]: Or something like that, right? Like same thing to macOS. Someone needs to do it.Ivan [00:40:25]: Someone will do that, and someone will have some long-running agents for a few days to figure this stuff out. But yeah. So definitely we - we're really close to offering something ‘cause people do want it, but the pricing will be different, and the feature set will be sort of stringent.Swyx [00:40:38]: Yeah, nobody's gonna use this. like, the labs, the labs will because they want to automate macOS.Ivan [00:40:42]: They have to do RL. They have to do RL again. But even if you The - So the point is with the RL part, if you, if you do RL on macOS, then the next iteration of the model comes out, it will be able to use these tools significantly. Then you actually need to run those, that somewhere. So you're gonna have to have that, later on. And from, if anyone at Apple is listening, I very much feel that they are shooting themselves in the foot of the scale of the revenue of compute or licensing they could get if they would just enable a concurrency model similar to what you can get on a Windows and a, and Linux.Swyx [00:41:17]: Yeah. Yeah. And I'm sure they've heard this before. They just don't care. Yeah, it's And maybe they will change their mind with the new CEO.Ivan [00:41:24]: Yeah. We'll see.Swyx [00:41:25]: We'll see.Ivan [00:41:25]: High hopes.Swyx [00:41:26]: High hopes.Ivan [00:41:26]: High hopes.Swyx [00:41:27]: Okay. But I, it's very clear the market opportunity is huge in Windows, and you can go for a long time on just Windows, but your customers are gonna want both. and I think, it is interesting to me that, this is the sort of God application of agents, right? Like, I don't It was - How big was OpenClaw for you guys? Like, was it, was there, a significant bump.OpenClaw, Agent Labs, and the B2B2C Sandbox MarketIvan [00:41:54]: Not for us because we.Swyx [00:41:54]: Because you already.Ivan [00:41:55]: We're kind of positioned differently. Whereas although it's completely PLG and we have individual developers that use it, most of the users that use Daytona are sort of a B2B2C. Sort of it's either B2B or B2B2C. So, in the researcher world, it's B2B, so you're selling to, labs and neo labs and things like that. But on the long-running agents, it's mostly, from a scale revenue perspective, it's mostly B2B2C, where you have a app layer agent that uses you at a big scale.Swyx [00:42:26]: Like a Manus. Yeah.Ivan [00:42:28]: Like a Manus Lovable type of thing.Swyx [00:42:31]: Yeah. I think that's the question of, well how, um-Uh, yeah, B2B to C is basically to me what I've been calling an agent lab, which is kind of like you're not in a model lab, but you're making a very good wrapper that is a platform that other people can sign up so they don't have to code those things. Yeah, it sound, it sounds like a much better market than the direct OpenClaw market.Ivan [00:42:56]: I've like - We I've done multiple things. So the CodeAnywhere's part of our career path R in the calendar, was very much an end user developer product. And so that is great. It You can get a lot of developer love, and I feel that we do as a company have a bunch of developer love. But it's a different type, where it's people building these things. Again, it's more akin to a Twilio because you don't really run - As a person, you wouldn't run Twilio. I don't know how many people remember. It was like ask your developer billboard and whatnot. And people really love Twilio, but they only used it inside of like, “Oh, I'm building this app or service for thing.” And so we're very much directly to that. And you also know that I used to work for a competitor for Twilio, so it's kind of ingrained, in my DNA.Swyx [00:43:35]: People don't know InfoBip is that big.Ivan [00:43:38]: Yeah, it's.Swyx [00:43:39]: Because.Ivan [00:43:40]: It's a billion euro.Swyx [00:43:40]: They're all American. They're like, “Whatever's in Europe doesn't matter to me.” But like it's the, it's the same size or bigger? Same size?Ivan [00:43:46]: It's about half the size.Swyx [00:43:47]: Half the size?Ivan [00:43:48]: Yeah, about half the size.Swyx [00:43:48]: It's like, yeah.Ivan [00:43:48]: Still huge. Multiple billions a year. Yes.Swyx [00:43:51]: That's crazy.Ivan [00:43:51]: Exactly, and so that - These are like really interesting and large revenue-generating, very sticky businesses. Whereas when you're selling to the - When your focus is the end developer, it is a very hard sell because they're very price sensitive, very price conscious, very around that. And there's very It's very hard to scale. Your cap is the number of people that are willing to spin up - First of all, wanna spin that up, and then spin up multiple of these. Whereas if you're in the enterprise one, like we know everyone's talking about like how many tokens they're spending, I'm spending. Like a lot of companies today are like, “If this is our company, spend as much as you can.” Like basically that is where we're going. And so if you think about that paradigm, where you're selling to companies that say, “Spend as much as you can to generate, productivity,” versus, “Oh, I'm a single person. I have this much budget, and I'm doing this thing because it's fun or it's helping me out or whatever.” Like it is a different, it's a different go-to-market, I think, strategy.MCP, CLIs, and Sandboxes as the Agent RuntimeSwyx [00:44:50]: Yeah, there's a lot of discussion. I'm just kind of going through like the mental list of things that are in your favor, which is, for example, MCP versus CLI. Like obviously you want CLI. It's been very good for you. I feel like it's maybe a drop in the bucket or maybe it's huge. I'm just checking whether it's like these are big trends.Ivan [00:45:10]: Those things you - work well in our favor, to your point just because every.Swyx [00:45:13]: They're kind of drop in the bucket, right?Ivan [00:45:15]: I think it's like sort of all the things come together. And so there's so many things that impact that. To your point, like OpenClaw wasn't huge for us, but like having the agent SDK, from Anthropic, so or Cloud Claude Code was very interesting. The reason why it was interesting is that a lot of, let's call them app I don't know what to call them, app layer agent companies, essentially they are like, “Oh, I can create this new app, this new agent. All I need, I just use Claude Code, and I throw it into a sandbox, and then I have my interface to the human to that.” And so that enabled so many more companies to actually offer this, and then they would pull on sandbox. So that was, that was interesting. And to your point, like MCP, versus the CLI, the MCP is an interface against an API, whereas the CLI is like you can actually go do things. Like this is it. The difference between integrations and actually running scripts or data or analysis against a thing. So being able to use a CLI very well enables the agent to do more things, and it's because that people will invoke a sandbox, they'll run it in the CLI, and but it'll do anal-analysis on that data and then give you an actual result versus just, pulling data from an API source.Swyx [00:46:29]: Yeah, it's a layer of indirection basically, it's the same thing as agentic search versus RAG, which where you're.Ivan [00:46:34]: Exactly, yeah.Swyx [00:46:34]: Just like you just win whenever people put more agents into their workflow. And so like it doesn't really matter, but I'm just kinda teasing out like what else have people heard about that like it's sort of, “Oh yeah, this is another sandbox use case. Oh yeah, that's another one.” Am I, am I missing any big ones?Ivan [00:46:51]: The thing, the thing that people, which is the computer use stuff, which I think is probably the most interesting one, is, and to your point, we've talked to so many people over the last year. It's like, “Oh, like why do you need a sandbox? Why do you need this? Why this?” And to your point, it's like, “Oh, I need sandbox for this. I need sandbox for that. I need sandbox-” It's like, “Oh, I need it for every single thing.” And so basically what I, what I - and it sounds like a broken record, it's like you use a laptop every single day, right? And you are n of one. It's just you. But now imagine how And by the way, the laptop, the computer PC market, the PC market is about equal to the cloud market in total. So it's about 150, 180 billion a year. Something like that. It's about roughly the three cloud hyperscalers is about equal to like Apple, HP, Lenovo, whatever, It's a little bit less, but it's sort of like that. And now imagine And that's just like, so how big is the addressable market? What, how many people are there in the world now? What's the last data?Swyx [00:47:45]: Let's call it eight billion.Ivan [00:47:46]: Eight billion. And so let's say you can have two computer, like you have one personal and one business, whatever. Like so it's double that, right? and so that's 16 billion, right? How many agents are gonna be running in two years, in 10 years, in 100 years? Like And for every single task, they will need one of these. And so how big is that? That market is essentially quote unquote “infinite”. You will get to the point, and Dylan Patel was at the conference talking about, from SemiAnalysis, that talks usually about GPUs, was also talking about how CPUs will now be a bottleneck because it will be the constraint. You won't be able to grow, or we won't be able to have enough of these because there won't be enough CPUs to basically do.Swyx [00:48:23]: Yeah. Well, I actually had a really good podcast with Doug Oliphant, who, which was his president at SemiAnalysis, where they've basically been like, yeah, it's been a GPU shortage first, but then it's cascaded down to memory and now to CPUs.Ivan [00:48:35]: CPU, yeah.Swyx [00:48:35]: It-What's next? So networking. So, networking actually has been in shortage for a while if you're looking at, just GPU networking. But, yeah, it's really crazy the amount of computer use that's going on, yeah, cool. I, other questions are, just the one very big part is the open sourceness which you didn't have to do, your competitors don't do, like it's not, a lot of people are worried about keeping their projects open source because some competitor can just slot fork it. I don't know if there's any reflections on just being an open source company.Open Source, Trust, and Enterprise ProcurementIvan [00:49:15]: Yeah. There's a bunch. So we the original product that we did was open source.Swyx [00:49:19]: Yeah. CodeAnywhere.Ivan [00:49:20]: So doing that was actually very good for us. There's basically a saying of, What's the saying? Like, companies that are, that are doing really well, measure themselves against, free cashflow, that are kinda okay, it's EBITDA, then, it's, it goes all the way down.Swyx [00:49:36]: The worst is like GitHub stars.Ivan [00:49:37]: GitHub stars. GitHub stars are the worst, yeah. So you go all the way down to GitHub stars. And so our original one was GitHub stars. That's what we talked about, we're at the point we're talking about revenue, so we're we've gone up the stack on that. And so we started.Swyx [00:49:47]: No, profit.Ivan [00:49:48]: Yeah. We haven't, we're, we'll get there. We'll get there. But basically at that point we did stars and GitHub and it was useful, and the original variation that we did, it we split the core into its own repo and it was Apache 2.0, so very, permissive. And then we basically would bundl

Jack sits down with Tapan Patel, Gearset DevOps Leader for 2026 and DevOps Lead for the Salesforce practice at Braze, a publicly traded omnichannel platform where every change management decision is subject to SOX audit scrutiny. Tapan brings a rare blend of project delivery experience, release management rigour, and genuine passion for building DevOps not just as a set of processes, but as a culture.The episode is a masterclass in phased, people-first DevOps rollout. Tapan walks through exactly how he's taken Braze from change sets and manual deployments to a governed, audit-ready CI/CD pipeline over the past year and a half — breaking it down into four distinct phases and sharing what actually worked, what took longer than expected, and where he's headed next. Tapan shares his rounded take on AI, including where it's already adding value in the pipeline today, why agentic autonomy in prod is still a way off, and how Claude, Jira and Gearset's reporting API are becoming a powerful combination for DevOps KPI tracking.00:01 – Intro & Meet Tapan Patel00:40 – Tapan's Journey: From Data & Analytics to Salesforce DevOps02:12 – What DevOps Actually Means as an Organisational Culture04:10 – DevOps in a SOX-Audited, Publicly Traded Company05:10 – The State of DevOps at Braze When Tapan Joined08:14 – Shifting Mindsets From Change Sets to a DevOps Tool10:32 – Precision Deployments: Why Page Layouts Break Everything11:49 – Stakeholder Visibility & the Value of Issue Tracking Integration13:36 – What Tapan Values Most About Gearset15:53 – The Four Phases of CI/CD Rollout at Braze19:16 – Phase Two: Stabilisation & SOX Integration20:30 – Phase Three: Automation Layers & QA Integration21:18 – Phase Four: Maturity & Minimal Intervention22:55 – The Admin Learning Curve for DevOps Adoption25:25 – Continuous Improvement as a Practice, Not a Project28:34 – Where AI Fits Into the DevOps Pipeline Right Now31:07 – Supplementary vs. Agentic AI: Why Tapan Is Taking It Slow33:14 – Using Claude + Gearset Data for Sprint Analysis & KPI Tracking36:00 – The DevOps KPIs That Matter at Braze37:24 – Closing Advice for Anyone Starting Their DevOps Journey

Take the 2026 AI Engineering Survey and get >$2k in credits and AIE WF tickets!This was recorded before Railway suffered a major GCP outage on May 19, despite being a multi-AZ, multi-zone mesh ring, with HA fiber interconnects between their Metal GCP AWS, because workload discoverability was unintentionally still tied to GCP. All has been resolved with a post-mortem.Railway did not start as an AI infrastructure company.It was founded in 2020 years before agents became the default way people thought about deploying software. Jake Cooper, formerly at Bloomberg and Uber, started Railway with a simple obsession: the activation energy to ship something to production should be near zero. Push code, get a URL, iterate. No Docker files, no Kubernetes manifests, no Ansible scripts stacked on Ansible scripts.For years, this was a slow grind. Railway spent its first 18 months hand-acquiring its first 100 users with Jake personally greeting every Discord signup on a second monitor.Today, Railway has raised $124m and is growing very fast. A 35-person team supports 3 million users, adding roughly 100,000 signups a week. Their bare metal data centers have a 3-month payback period vs. renting in the cloud, with 70% margins funding aggressive cloud bursting when needed. The servers they own have actually appreciated in value as RAM prices have climbed basically meaning the value of their hardware now exceeds the capital they've raised.From rebuilding Railway's network overlay over a weekend to moving the vast majority of workloads onto its own bare metal data centers, Jake Cooper is trying to build a new cloud for an agent-native world. In this episode, Railway's founder and “conductor” joins swyx and Alessio to unpack why the next era of software infrastructure is not just “Heroku but newer,” what agents need that humans did not, and why the old deployment loop of Git, PRs, CI/CD, and static cloud resources may be heading for a rewrite.We go deep on Railway's infrastructure stack: own-metal data centers, three-month cloud payback periods, cloud bursting, data center debt, Railpack, Nixpacks, Temporal, feature flags, Central Station, content-addressable filesystems, agent-safe production forks, and why the CLI may become more important than the canvas in an agent world. Jake also shares the founder journey behind Railway, how the company survived losing $500K/month, why it now serves millions of users with only 35 people, and why he believes the pull request is dying.We discuss:* How Railway went from a slow six-year grind to adding 100,000 users a week* How Railway thinks about agents as the next dominant software species* Why agents need version control, observability, compute, storage, and orchestration at 1000x scale* The economics of Railway's own-metal data centers and three-month payback* How Railway uses cloud bursting while scaling its own infrastructure* Why data center debt can be a better tool than venture debt for infra startups* Central Station, Railway's internal system for clustering customer feedback and incidents* Why responsible disclosure and over-communication matter for platforms* Why feature flags, progressive rollouts, and shadow traffic are essential for agents* Temporal's strengths, pain points, and why workflows matter for agents* Railpack, Nixpacks, Nix, and lazy-loaded content-addressable filesystems* Why “cattle, not pets” may change if you can clone the pets* Why Railway is building a new cloud from scratch instead of copying hyperscalers* The solo founder path, focus, writing, and how Jake thinks about company buildingRailway:* Website: https://railway.com/* X: https://x.com/RailwayJake Cooper:* LinkedIn: https://www.linkedin.com/in/thejakecooper/* X: https://x.com/JustJakeTimestamps00:00:00 Introduction: What Is Railway?00:02:07 Jake's Path to Railway00:06:13 Railway's Six-Year Growth Story00:08:52 Rebuilding the Business After the Free Tier00:11:17 Agents as the Next Software Platform00:13:29 Railway's Infrastructure Philosophy00:15:42 Bare Metal, Cloud Economics, and the Compute Crunch00:17:22 Cloud Bursting and Five-Cloud Networking00:20:20 Data Center Debt and Infra Financing00:23:31 Data Centers in Space00:25:24 What Agents Need From Infrastructure00:28:24 CLIs, Canvas, and Agent-Native UX00:35:15 Central Station, Incidents, and Responsible Disclosure00:40:30 Safe Rollouts, SRE Agents, and Production Forks00:45:00 AI SRE, Specs, Code, and Tests00:48:24 Self-Replicating Infrastructure and the New Serverless00:53:18 Heroku, Temporal, and Workflow Engines01:04:07 Railpack, Nixpacks, and Lazy-Loaded Filesystems01:06:01 Coding Agents, Token Spend, and Roadmap Acceleration01:10:56 The Pull Request Is Dying01:12:28 Feature Flags and the Agent-Era SDLC01:16:15 Cattle, Pets, and Cloning Machines01:19:29 Solo Founder Lessons01:24:12 Focus, GPUs, and Building a New Cloud01:28:20 Closing ThoughtsTranscriptAlessio [00:00:00]: Hey, everyone. Welcome to the Latent Space Podcast. This is Alessio, founder of Kernel Labs, and I'm joined by Swyx, editor of Latent Space.Swyx [00:00:10]: Hey, hey, hey. Today we're in the studio with Jake Cooper of Railway.Alessio [00:00:14]: Conductor of Railway.Swyx [00:00:15]: Conductor at Railway. Yeah.Alessio [00:00:16]: Choo-choo.Swyx [00:00:17]: Do you actually have that anywhere, like on your business card?Jake [00:00:20]: We call some of our volunteer moderators conductors. I don't have a business card. We're not that big yet. At some point I will. I got handed a nice business card from the Supermicro folks, and I was like, “Damn, this is pretty official.”Swyx [00:00:30]: Business cards are coming back.Jake [00:00:32]: They're cool. They're hip. The conductor thing is good. We're trying to figure out what we want to call each other internally. Some people think it's super cringe and say, “You don't need a name for people internally.” Some people want to call each other something. We still don't have a really good one.Jake [00:00:55]: We've got New Railcrews, Trainiacs. Nothing has stuck yet.Swyx [00:01:00]: I like Trainiac. Trainiac sounds good. Railwayians. For those who don't know, what is Railway? Let's give people a crisp definition up front.Jake [00:01:09]: Railway is the easiest way to ship anything. You go to the canvas, or you talk with Claude, and you say, “Deploy a Postgres instance, deploy my GitHub repository, run this code,” and you're off to the races.Swyx [00:01:22]: You've got a nice animation on the landing page.Jake [00:01:24]: Thank you. None of my work, by the way. They don't let me touch the design stuff anymore.Jake [00:01:25]: We want to make it trivially easy not just to deploy things, but to evolve applications over time. Most tooling right now stacks entropy on top of entropy: Docker, Kubernetes, Ansible scripts, and all these other things. If we can version all of your software and keep track of all the changes, then we can make it trivial to clone environments, fork into a parallel universe, get copies of production data, get copies of any services, make changes, validate them, and collapse them back in without reproducing everything across a staging environment.The Railway Origin Story: From Uber Systems to a New CloudSwyx [00:02:07]: I was looking at your background: Bloomberg, Uber. Nothing immediately stands out as, “This guy is going to found the next great platform as a service.” What prepared you for Railway?Jake [00:02:21]: It was curiosity to keep going deeper. I started out on front-end stuff, working on Wolfram Mathematica and porting it over. Then I briefly moved to Bloomberg, then toward Uber and distributed systems, taking the Jump Bikes systems and moving them to a distributed system built on top of Cadence, the pre-Temporal Temporal.Swyx [00:02:44]: Which, by the way, I'm happy to talk about, pros and cons.Jake [00:02:48]: Totally.Swyx [00:02:51]: But let's do the Railway story.Jake [00:02:52]: It has been a continual step of wanting an experience. Whether it's walking up to a bike, unlocking it, and having it work frictionlessly, or something else, the depth required to make that happen follows from the experience. A lot of the work I do, and a lot of the team does, is in service of that experience. We fundamentally don't care how deep we have to go. We will swim to the bottom of the swimming pool to get the experience.Jake [00:03:17]: I don't have a physics PhD. I did an EECS degree. It has always been about figuring out the next step: how do we get there? That's what led to starting Railway for that experience and then moving all the way to bare metal data centers. I was adding patches to the kernel this week to get the experience there because I can see how much better it can be.Swyx [00:03:49]: Other patches to the Linux kernel this week?Jake [00:03:51]: Yeah. Not upstream. Our fork.Swyx [00:03:52]: That's a flex. Railpack? No, this is different. This is the OS on top of Railpack?Jake [00:03:57]: No, this is an actual kernel patch. It's always literally: what do we have to do to get that experience? Then figure it out. Anything is figureoutable.Swyx [00:04:10]: Would you send the patch upstream, or does it not fit other use cases?Jake [00:04:13]: Maybe. We have to work out the experience internally. It has to do with the storage layer we're building for some of the agentic stuff. Maybe it'll be useful upstream, but it's deeply useful for us internally.Open Source, Forks, and Non-Deterministic VersioningSwyx [00:04:29]: You mentioned open source before. How do you think about starting from open source, and then coding agents letting you do a lot more from forks of it?Jake [00:04:38]: GitHub's original sin is that it's almost a series of broken pointers. You have this thing, then you clone it, and now you've lost the whole upstream. How do we make it trivial for people to modify really small pieces of it?Jake [00:04:51]: We think of Git in a discrete sense: I've either made a change and merged upstream, or I haven't. What would it look like if it were percentage-based, a little more non-deterministic, or a stream of changes that users traverse as a percentage rolled out in general and then rolled all the way up?Jake [00:05:13]: We have the open-source kickback program and let you deploy templates because we want to make it trivial for people to version these shards over time. It solves a large problem around authentication, authorization, and security. NPM has a way to define, “Don't take any new packages.” The ideal end state is that you roll out progressively to users with the minimum impact zone and continue rolling up. JPMorgan should probably be the last one on the patch line, for all our sakes, because our money and livelihoods are there.Jake [00:05:53]: It's okay if Johnny Vibe Coder gets a broken patch because there's so much entropy in the system that the rubber has to meet the road at some point. You have to test at varying levels.The Long Grind: First Users, Free Tier, and Making the Business WorkSwyx [00:06:13]: I wanted to pull up this glorious chart, which is your usage or number of daily signups?Jake [00:06:22]: Daily signups, I think.Swyx [00:06:24]: You started six years ago. It was a slow grind, and now you're on a rocket ship. You say, “Don't doubt your fight and don't quit.” Maybe pick out certain points that were key inflections for the company.Jake [00:06:40]: At the start, it's about getting your first 100 users, hell or high water. We had a website and a support link. The support link was the Discord channel. I had notifications on with two monitors: the monitor I was working on and the other monitor with Discord. If anybody came in, I was immediately like, “Hey, how's it going?” It was rare, so getting those first 100 users to come back was the start.Jake [00:07:14]: Then you build a consultancy factory because users want all these things. You have to go back to the board and ask, “What is the actual product offering I want to build on top of this?”Jake [00:07:28]: VCs want charts that always go up and to the right, but in reality you don't necessarily want charts that look like that. For us, there have been periods of expansion where we add features to test use cases, and periods of compaction where we ask, “If the experience we have is good, how do we make it significantly better?” Maybe we strip out features that don't fit our ICP anymore.Jake [00:07:57]: The boom from 2022 to 2023 came from the free tier. Everybody under the sun was using it.Swyx [00:08:09]: A lot of Reddit bots and Discord bots.Jake [00:08:12]: And crypto miners. When you build an open product on the internet where anybody can sign up, the internet is a horrible place with so many things. You go through periods of asking, “How do I reach as many people as possible?” Then, “How do I fit the exact use case for the people who really matter and are really excited about this specific thing?”Jake [00:08:39]: Then there was a two-year period of making the actual business work. During the free-tier era, we were losing about half a million dollars a month.Swyx [00:08:59]: On a $20 million bank account.Jake [00:09:02]: On a $20 million bank account with maybe $50,000 a month in revenue. That's a horrible business. I don't know how anybody invested. But you have to go through it and say, “We have an experience people love, but the business has to work.”Jake [00:09:17]: There are two schools of thought. You can run the horrible business all the way up with bad margins, or you can go back and make it work. We've always wanted a super lean team. We're 35 people right now. It's very small.Swyx [00:09:36]: Supporting three million already?Jake [00:09:38]: Yeah. We're adding 100,000 users a week right now, so it's growing fast. We don't want to add headcount for the sake of headcount or throw bodies at problems. We want to build systems. It's hard to build systems during expansion because you're adding things to the system because people are asking for them or things are breaking.Jake [00:10:00]: We had to cut off the free users for a little while, rebuild the business, and make sure it worked. We want to reach as many people as possible because software is important. It's become difficult to create things in the physical world, so it's important to make it easy for people to build in the virtual world and have access to creation. But there are legs to that journey.Jake [00:10:30]: You can see divots in the charts. If you follow between 2025 and 2026, it's either summer or winter. People go on holiday with family.Swyx [00:10:50]: It affects that much?Jake [00:10:51]: Yeah. It's kind of B2C and kind of B2B. People are shipping constantly, then they stop. Our activation curve now shows more people activating on weekdays because we have more business users, so it smooths out over time.Agents as the New Interface to DeploymentSwyx [00:11:17]: Was there a point where you started prioritizing AI development or agent development?Jake [00:11:24]: We've prioritized agentic as a top-of-funnel thing. Over the last six months, we've deeply prioritized agentic as a mechanism to build and deploy things because we believe the curve is so steep and that is how people will build and deploy software.Jake [00:11:42]: It almost fundamentally doesn't matter whether this is dot-com or not because we're all on the internet anyway. If agents are going to deploy a bunch of things and we hit an inference wall at some point, we'll fix those problems. The dominant species over the next 10 years is that we've moved from assembly to C to C++ to JavaScript to words. You're going to need to close that loop.Swyx [00:12:13]: When you say this is dot-com, did you mean buying the domain, or the general case?Jake [00:12:17]: I mean the dot-com era, when companies had a huge run-up because people understood the internet was important. Then they hit bottlenecks, fundamental laws of physics, math didn't work, and everybody came back down to earth. But it didn't matter because the internet became so impactful. If you operate on a long enough time horizon, you should build these things anyway because you can see where it's going.Jake [00:12:45]: That's where I think a lot of agent stuff is. You get to a point where you're running thousands of agents in parallel. What is the inference cost? What is the compute cost? How do you make that efficient? How do you coordinate all this? We have issues coordinating humans; we don't even have good tooling for that. Now we have to figure out how to get agents to coordinate, safely version changes, and know when to raise their hand for someone to intervene. Otherwise it becomes an interrupt factory.Railway's Infrastructure Thesis: Network, Compute, Storage, and MetalSwyx [00:13:19]: Let's go right into the technical side. What are the core infrastructure or architectural beliefs of Railway that allow you to do what you do?Jake [00:13:29]: The primitives matter a lot for us. We need network, compute, storage, and orchestration around it. You need control over a lot of those things. We've talked a lot about how we don't really use Kubernetes because we want higher-order control to place workloads in very specific places.Jake [00:13:48]: The reason is that you have to be very efficient with agents: memory reuse and all these other things, or you're going to massively blow up your cost structure. Being able to rack and stack your own servers and build your own metal unlocks performance and cost. Experiences where you're running 1,000 agents in parallel are not massively cost prohibitive.Jake [00:14:13]: Token use and compute use are blowing up. Over time, those things have to get a lot more efficient. You can get a lot of margin to make those experiences solid by building your own metal. That's all in service of offering a differentiated experience to as many people as humanly possible.Swyx [00:14:51]: You have a data center in Singapore.Jake [00:14:53]: Yeah. We have two in every other region now. In Singapore, we're adding a second one in Q3.Swyx [00:14:58]: What's it like? I've never built a data center. Do you go to Equinix and say, “I want some slots?”Jake [00:15:05]: Yeah. Equinix. You basically go and say, “I want power and I want a cage.” They say, “Great, here's what it's going to be.” You rent the cage for a period of time, fill it with racks and servers, and hook up internet to it. That's all the pieces.Swyx [00:15:36]: Then you handle everything else.Jake [00:15:37]: You handle everything else.Swyx [00:15:39]: What's the math versus clouds doing it for you?Jake [00:15:43]: If we rented in the cloud, our payback period when we go to metal is about three months.Swyx [00:15:50]: Which is crazy.Jake [00:15:51]: It's nuts. That's four years of depreciated hardware. You're going to see a lot of this compute crunch because hyperscalers are buying up a lot of stuff. We're working directly with OEMs, resellers, and people building these machines: Supermicro, Dell, and others.Jake [00:16:11]: Upstream, there's a bunch of supply pressure. When we raised our last round, between deploying capital for servers and now, the amount of money we've raised is less than the amount of money we have in the bank plus the value of the servers because the servers have appreciated as RAM has gone up. It's nuts how valuable hardware has become.Jake [00:16:50]: If you look at hyperscalers, they deployed around $80 billion of capital expenditures this year, and next year will be more. That's a massive infrastructure build-out. You look at that and think it's crazy that they're spending way more than the Manhattan Project. But if every person is going to run dozens or hundreds of agents in parallel, you have no conceptual idea how much compute is required to make that experience happen, even if you're deeply efficient and sharing resources. And that doesn't even count inference.Swyx [00:17:22]: How do you plan the build-out? The growth chart is so vertical. Are you usually at 100% utilization as soon as racks are live? How far ahead are you planning?Jake [00:17:33]: We still maintain cloud presence for bursting. We work with AWS, GCP, and a few other clouds. We can rent, and then the moment we get space or power, we compact those workloads off the cloud. We started on the clouds, then built a system to migrate to our own metal. There's nothing that says you can't continually do that again, and that's exactly what we do. We never want to be compute constrained.Jake [00:18:09]: At the start of the year, we actually became compute constrained because one upstream provider wasn't able to give us quota at the rate we needed, and the hardware was slower. I spent a weekend rebuilding our entire network overlay so we could straddle five clouds: Oracle, AWS, ourselves, GCP, and one other one. We can do more than that now.Jake [00:18:38]: We got into a spot where we were trying to pack instances tight because we couldn't get enough compute. That led to a few reliability issues, which are now past us. I made a tweet pointing out that it's becoming harder and harder to acquire compute at the rate these models need to acquire compute. We got bit by it.Swyx [00:19:15]: How do you think about pricing knowing you might not have your own metal available at all times? Are you pricing assuming you need extra margin if you end up going into the cloud?Jake [00:19:26]: Because we've built out our metal data centers, our margins on metal are around 70%. We can deeply subsidize the cloud business if we want to scale at a reasonable rate. We have a few levers: metal, which makes the margins; cloud burst; debt to buy servers; and venture capital. It's an interesting operational problem: how much cash do we have, how much should we raise, how quickly can we deploy it, and can we scale revenue as quickly as we scale compute?Jake [00:20:05]: If we continue making it trivially easy for people to build and deploy, then the faster we close that loop and the more operationally excellent we are with capital, the faster the business can scale. It's almost a straight linear deployment rate.Financing Infrastructure: Hardware Debt, VC, and Operational LeverageSwyx [00:20:20]: I think infra startups raising debt is a tool people don't utilize enough or know enough about. What can you tell us about that? Is it secured against your CPUs?Jake [00:20:32]: It's secured against our hardware.Swyx [00:20:37]: What rates do you get? Who are the lenders?Jake [00:20:39]: We pay prime plus a spread, and we can refinance any of the debt as rates go down. The terms are pretty good. The unfortunate thing is that Twitter has no nuance, so people say, “Venture debt bad.” But as with all things, there are specific tools and areas where you can be deliberate instead of using one tool as a hammer. Venture capital is not the hammer for everything. You have to explore and figure out what works.Swyx [00:21:12]: VC is usually the most expensive financing you can get.Jake [00:21:15]: Yeah. I also think people think about VC incorrectly from a capital-raising perspective. Most people think, “How do I raise as much money as possible from whoever is probably the best I can get at that time?” That's close to right, but what we've tried to do is figure out what unfair advantage we can buy with that equity.Jake [00:21:34]: It's the most expensive equity you're going to give away at that point in time, assuming the company keeps getting better. How do you use it to work with someone stellar who complements you? In the seed stage, I had never started a company. Ray Tonsing had good advice, and I could text him all the time. He was really fast. Awesome.Jake [00:22:01]: Then with John and Erica at Unusual, they said, “You roughly know what you're doing building a product. We'll mostly leave you alone and be available for advice.” Amazing. Then we got to Series A and the business was an operational tire fire because we didn't know how to scale a business. Work with Erica, and Jordan is over at Redpoint, so bonus.Jake [00:22:28]: Now we've raised from TQ and FPV as we're moving into enterprises. Every step of the way, we've asked: who can we partner with at this specific time to unlock the next section of the journey? I don't know enterprise sales. As an engineer, I can eyeball what features we might need, and we have wonderful people internally who can help. But you want boardroom dynamics where everyone is aligned and asking, “How do we win this?” instead of bickering about strategy.Data Centers in Space and the Physics of ComputeSwyx [00:23:31]: You had a tweet about data centers in space. Why no data centers in space?Jake [00:23:37]: It's not “no data centers in space.” My hot take is that I think it is solvable. I've just never seen anybody solve it.Swyx [00:23:49]: You said, “How are you going to dissipate that much heat in a vacuum?” You're making a physics claim.Jake [00:23:55]: I haven't seen anybody prove how you're going to dissipate that much heat in a vacuum. It doesn't mean it's not possible. It just means nobody has brought it up yet.Swyx [00:24:05]: Astrophage.Jake [00:24:06]: I don't know what that is.Swyx [00:24:07]: The Martian thing. Okay, you're very logical.Jake [00:24:09]: It could work. A lot of people are putting the cart before the horse. They say, “We're going to put data centers in space.” Okay, but how? “We have time to figure it out.” It's like in The Martian where they ask how they're going to intercept something and say, “We'll figure it out.”Swyx [00:24:36]: Making a bet on human invention is weird because you blind trust that it can be solved. But with physics, there are first-principles bounds you can put on it. Maybe not. Maybe you're asking to travel time or break a fundamental thermodynamic law.Jake [00:24:57]: I don't know how VCs do this either. How do you know what's not possible and a grift versus what's possible but sounds completely insane? “We're going to put data centers in space.” Coin flip as to which it is, and I guess you'll know in 10 years. That's one cycle.What Agents Need: Versioning, Observability, and 1,000x ScaleSwyx [00:25:23]: Moving back to agents. The branching, fast spin-up, and orchestration you do feels like pre-work that happened to be exactly what agents want. What do agents want differently than humans?Jake [00:25:37]: They want the ability to version things. It's not that different; it materializes slightly differently. Agents want a way to test changes incrementally. Engineers have feature flags. Is there a reason agents can't use feature flags? I don't think so.Jake [00:25:54]: They want version control. Can we use Git or not Git? That one is up in the air. I think something outside Git will emerge for how we version these things over time. They need observability. You need to query what happened, when it happened, which steps failed, traces, logs, metrics, and all the rest. They need network, compute, and storage. They need to write files, save files, iterate on files, and snapshot file systems.Jake [00:26:25]: A lot of what humans needed is in line with what agents need. Branching and forking are not different; we're just moving 1,000 times quicker. It can look like you need something massively different, but what you need is something massively better than what existed. You need orchestration massively better than Kubernetes. You need networking probably better than Envoy. It goes all the way down the stack.Jake [00:26:55]: If the workload profile doesn't change so much as it gets massively compressed because you need thousands of these things, what assumptions change? etcd is going to melt. You need to replace it with something. You can go all the way down the stack and say, “That part has to change, that part has to change, and that part has to change.”Jake [00:27:19]: The interesting thing about the super-exponential curve is that you have to build systems where you can rip out those parts at any time because a new bottleneck might emerge. You get good at parallel agents, and a different part of the system breaks. So it's similar to what humans needed, but at 1,000x scale.Jake [00:27:55]: How do you do code review in the age of agents?Swyx [00:28:00]: You throw more agents at it.Jake [00:28:01]: You don't. But then who reviews for CVEs and all these other things?Swyx [00:28:07]: More agents.Jake [00:28:08]: And that's how we hit the inference wall. You can continually throw agents at the problem, but I think there's a limit to the number of agents you can throw at a problem.CLI, Agent Handles, and Closing the LoopSwyx [00:28:24]: You already had a CLI before it was cool. How is the shape of what you're exposing changing, if at all?Jake [00:28:28]: CLIs have always been cool. The CLI changes because we think about how to give Claude, Codex, ChatGPT, or any model a handhold.Jake [00:28:50]: A CLI is a single command: deploy, get logs, and so on. Things that were prohibitively annoying to humans are not annoying to agents. They're nice. If I handed you a CLI with 40 arguments and 600 flags, you'd think, “I'm never going to use all of this.” But if you hand it to an agent, it says, “This is excellent. I have so many handles to work with.”Jake [00:29:24]: If you're going to expose things to agents that way, you want as many handles as possible where they can get information, query dynamic information, and close the loop quickly. Most problems right now are about how to close the loop as quickly as possible. Where does the agent get stuck, and how can you remove that?Jake [00:29:49]: Telemetry is important. If you can tell where the agent gets stuck from the CLI and say, “12% of people deviate from the happy path because of this, and now I add this argument and drive it down to 2%,” you massively increase the rate of loop closure.Jake [00:30:03]: That's how we think about not just the CLI, but every point in the dashboard. It's a user journey: I hear about Railway. I get something deployed. I get my first green build or aha moment. I see an endpoint, logs, whatever. Then I iterate. The iteration loop is indefinite. The user wants to deploy a new thing, a Postgres instance, change code, and keep iterating.Jake [00:30:36]: If you focus on the iteration loops and what's blocking them from closing quickly, one thing we say internally is: you never want to be waiting on compute anymore. You always want to be waiting on intelligence. If you're waiting on compute, there's a bottleneck that needs to be destroyed because eventually that bottleneck becomes so large that another workflow emerges to change it.Jake [00:31:04]: We've built a product where you push code, build it, and so on. But I fundamentally believe the push-pull loop is going away. We'll get to a point where you make a small change in production, that change is versioned across your infrastructure, you're working alongside copy-on-write versions of your database and infrastructure, and then you merge it in and it's instantaneously live. That's the holy grail of loops. The push-pull-rebuild thing is a point of friction that we're removing entirely.Canvas as Output: Dashboards, Context Anchors, and HyperstructuresSwyx [00:31:43]: It's incredibly fast. If anyone hasn't tried it, that fast feedback is great. My hot take is that Railway was famous for its canvas, which visualizes your infrastructure and lets you manipulate it visually. But that was for humans. For the next phase of growth, Railway CLI is more important than canvas.Jake [00:32:05]: The canvas is funny because it's a mechanism to show changes over time. You're right that previously we used it a lot as an input. Moving forward, its goal is more like an output. You would go to the canvas, make changes, see them, and watch your infrastructure evolve. Now agents have access to the CLI and can make those changes. So the canvas becomes an output: what information does the human need at this moment to make suitable decisions about control requests? Do I approve this or not?Jake [00:32:57]: It also has to be an anchor for your context, a port in the storm. Think of it like layers in a file system. You start with a project, then drill down into services, then into a function or code, because you want to represent the entire thing not just in your head, but in the canvas. Other people can share that representation, think on the same wavelength, and move quickly.Jake [00:33:33]: A lot of organizations get in trouble as they scale because all the context lives in someone's head. “How does this microservice work?” “I have no idea; go ask this person.” Then you have whole categories of products built around context discovery. A lot of that melts away if you have a solid hierarchy and can infinitely nest services, code, context, and everything else all the way down. That's what lets you build these structures over time.Jake [00:34:18]: It's also what lets us build what I've called hyperstructures: things that are way bigger. You look at the Golden Gate Bridge and ask, “How did we build that?” There's a meme that we lost the technology. To some extent, yes, because the coordination that built those things evolved and changed. We lost some of the art of building structure as we jammed everything into Slack.Swyx [00:34:52]: But you jam everything in Discord.Jake [00:34:53]: Same point. It doesn't matter. It's message passing and interrupts, message passing and interrupts.Swyx [00:35:00]: So you're arguing there should be something better and more structured than Slack?Jake [00:35:04]: Yeah. For sure. I think Slack is awful, and Discord is awful too.Central Station: Context Routing, Support, and Incident ClustersSwyx [00:35:09]: This is the equivalent of my mom test. What have you done that has your solution to this?Jake [00:35:15]: Internally, we've built a tool called Central Station that aggregates all the context from our users. Every piece of feedback, every customer support item, everything gets aggregated into clusters. If an incident is brewing, we can determine how many users are affected and break off a discussion based on that.Jake [00:35:40]: That is more helpful than long-running channels where you're trying to decide which channel to put something in. If you can dynamically aggregate information and dynamically route it to the right person based on context, it works better. We know internally that these four people are close to networking. If we see a networking thing, we can drill it down to those four people. If it's with this part, we can look at the commits. This is no longer a manual process internally.Jake [00:36:13]: If you go to station or help.railway.com, that's why we built it. We wanted to scale with a massive amount of leverage by aggregating feedback.Swyx [00:36:27]: This is built in-house?Jake [00:36:28]: Yep.Swyx [00:36:29]: I remember helping out on this one with Angelo in 2023. You scale a lot with a very small team.Jake [00:36:38]: Yeah. We're about 10 times bigger now.Swyx [00:36:40]: You have your full developer code here? Very cool.Jake [00:36:44]: If you go to railway.com/stats, we expose this as a pub-sub-able thing. It's all real-time metrics. There's a way to get it as JSON somewhere if you care.Jake [00:37:01]: We're big on trying to build everything in public and talk about what we're working on. We've had issues in the past, and we'll say, “Here's how we're fixing these things.” We've gotten compliments and flak for incident reports. We're always trying to make them better and talk with people.Incidents, Disclosure, and Progressive RolloutsSwyx [00:37:20]: You had a big one recently. I liked that it was scoped to 3,000. You presumably used Central Station. Talk through what happened and how you address it internally as a team.Jake [00:37:38]: Internally, this one really sucked. It had to do with an upstream provider that didn't do the behavior it said it documented, which is unfortunate given they wrote the RFC for how the behavior should work. We rolled those things out, and Central Station caught it initially when a couple users said caches weren't invalidating. We turned it off immediately.Jake [00:38:03]: When you roll out to a large user base of three million people, you get a lot of disparate behaviors. We tested in staging and had tests, but we hit an edge case. We've hardened those systems, and now we can make that better. But it was a tough one.Swyx [00:38:39]: I always wonder how private disclosure is supposed to work if people find an issue. Are they supposed to contact you first? When you run a platform, these things will happen. What channels should people pursue to quietly resolve it before it becomes a bigger incident?Jake [00:38:59]: There's responsible disclosure. We err on the side of over-disclosing and letting you know something is wrong versus having your provider gaslight you. We've erred on sharing those things more publicly, even if they impact a small subset of users. That's a decision we've made internally. We have four values. One is honor. The honorable thing is to notify people to the widest degree at which they may have been affected or there was an issue, and then confront it head-on: why did it happen, what can we do better?Swyx [00:39:45]: Not the whole user base. That's because of incremental rollouts and other things?Jake [00:39:50]: Yeah. Progressive rollouts.Swyx [00:39:54]: That should be the norm at all large platforms.Jake [00:39:58]: It should. A variety of companies do this. There's the quote that Meta runs 10,000 different versions of Meta. To our earlier point about agents, they need the same thing. They need shadow traffic and all these other things. We've built so much ceremony around production being sacred that we need to make it trivially easy to test different behaviors in a safe environment. Then you can make mistakes in a safe environment.Safe AI SRE: Customer Agents, Forked Environments, and Production ParityAlessio [00:40:30]: Do you see a world where these things get automatically caught, not necessarily by your agent, but by your customer's agent? The cache invalidation issue seems easy to check if you know to look for it.Jake [00:40:44]: It's hard because to determine it, we almost need to hook into your observability infrastructure. That's why we have the template loop on the platform: so you can roll things out progressively. You can roll out to Johnny Vibe Coder initially, or push a shard that someone consumes at their own leisure. Or you can roll it out over weeks: 0.1% of people, 1% of people, early adopters, then all the way up. That's the non-deterministic version control we talked about earlier.Jake [00:41:30]: I believe that's where most things should go, because most companies end up building staged rollout systems in-house. It's the same thing built again and again at every company. There's a massive opportunity to consolidate developer debt.Alessio [00:41:45]: You should have a free tier. Model providers give free tokens if you let them use the data. You could give free compute if someone is the number-one shard that goes out and lets you plug into their observability.Jake [00:41:55]: We do that. That's why we talked about the impact on 3,000 people. We start with lower-impact people. Larger companies on the platform are last to receive those rollouts so they have a version of the platform that's deeply stable.Alessio [00:42:16]: I have three services, so I'm sure I get the first rollout. You can nuke my thing at any time. There are all these SRE agent companies. Observability people also want agents that fix upstream problems. You have your own agent in the canvas now. How do you see that playing out?Jake [00:42:39]: It's the stacking entropy problem. If you don't have primitives to make iteration in production safe, it becomes difficult. If you're an observability provider saying, “Here's the fix to this error,” assume 80% are good and make sense. But in the last 20% long tail of complex issues, if you let somebody stamp it, you create an opportunity for an incident.Jake [00:43:08]: That's why forked environments are important. People have staging, but it always drifts from production. You need primitives, workflows, and experience built first-party on the platform so you can fork any service at any point in time.Jake [00:43:33]: I think of the canvas as a sheet of transparency paper. The agent is a little guy you push up into the canvas. It should say, “I need to copy that service and that service so I can test these two things.” It gets a read-only copy of production. Anything that's PII gets marked as a transform when we clone the database, create a copy-on-write version, or read from it. Then the agent makes changes and asks, “Does this actually work?” as close to production as possible.Jake [00:44:22]: That's how close you have to be, or you get massive drift. The system becomes unstable. You see this with massive systems built on Docker for local, Kubernetes for production, and a specific thing for something else. That complexity slows developers and becomes unstable at scale, making it hard to iterate. We want to compress that way down and say, “As close to prod as possible is where we want to be.”From AISRE Skeptic to Agent BelieverSwyx [00:45:00]: I was texting Erica for questions, and she says you were originally not a believer in AISRE. Have you come around on it?Jake [00:45:10]: I flipped, but I'm still not a believer in AISRE if you don't have the primitives to make it safe. If you unleash AISRE on production infrastructure without safe primitives for copying volumes and making sure things are fine, it's going to nuke your production database. It's not a matter of if, but when. I'm a big believer in making those loops safe.Jake [00:45:33]: I was a deep AI skeptic until 2023. In 2024, I thought, “Maybe I can roughly make this thing do it.” In 2025, I thought, “Now I can hold this.” Over winter break, everybody came back saying, “It's almost impossible to hold this.”Swyx [00:46:01]: Did you see this on the Claude docs? CloudBot? OpenCloud?Jake [00:46:06]: It's gotten to a point where it's harder to hold it wrong than to hold it right. There's a scene in Avengers where Vision picks up Thor's hammer and says it's terribly well-balanced. It self-balances and works well. I'm a deep believer at this point that this will be the dominant species: assembly, C, C++, JavaScript, words.Swyx [00:46:35]: It feels like a big jump.Jake [00:46:37]: It is. But it's not like you abandon CPU-based discrete logic and move straight to fuzzy logic. You need both. Your skills should call code or applications or some static structure. You can use skills to distill what the procedure should be or how the code should act.Jake [00:47:02]: I'm coming to a thesis: you need three points. You need a clear spec defining the system, the code, and the tests. When you say it out loud, if you've been in engineering long enough, you're like, “Of course. That's an RFC, tests, and code.” But they all matter. Having them together lets them reinforce each other: the spec and tests match, but the code doesn't, so reconcile it. Or the tests and code match but the spec doesn't, so reconcile that. That's the iteration loop.Jake [00:47:41]: That's why you're seeing people talk about software factories, docs, and reconciliation. Some of that is architectural astronomy if you don't implement it, but that loop is where most things will end up.Swyx [00:48:07]: For listeners, we've been talking about this on the pod for three years: the holy trinity of specs and tests. Itamar Friedman from Qodo is the reference if people want to look it up.Self-Modifying Infrastructure and the End of Push-Pull-RebuildSwyx [00:48:18]: One thing I want to mention on the OpenCloud idea is self-modification. I don't know how Railway would support it, but I have my OpenClaw, and I just tell it it has the Railway CLI and can do whatever. In theory, whatever capabilities or new infra it needs, it can call the Railway CLI, provision it, and add it to itself. The agent can modify its own infra.Jake [00:48:45]: It's nuts. I have a loop set up where you put the Railway CLI on top of something that runs on Railway. You're authenticated as whatever the current box is, and you can make any changes to it. Then you call Railway deploy, and it deploys itself.Jake [00:49:04]: It's like: “I need to spin up this instance of this environment. I already exist in this environment. Excellent, I have access to a Postgres instance now.” That's where we want to go with agentic, self-replicating infrastructure. That's your loop: iterate in production. You continue making changes. If it works, merge it upstream. If it doesn't, throw it away.Jake [00:49:37]: How do you make throwaway copies trivial to spin up and super cheap? The era of “I have an AWS instance with four vCPU and 16 gigs of RAM” is going to get destroyed. If you do that for agents, you need a thousand of those machines. It's prohibitively expensive compared with what we've spent a ton of time figuring out: the atomic unit of deploy, whether you call it isolates, sandboxes, or something else. Only pay for what you use, spin up instantaneously, and close the loop as quickly as possible.Jake [00:50:15]: If the system can self-replicate safely and say, “This is my environment, I'm making these changes,” it can come back with, “Does this look good? This is a new state of infrastructure given this prompt. I think I've solved it.” Then you go back and say, “Actually, it looks different.” It does the loop again. Then you say, “Cool. Apply.”Swyx [00:50:38]: That's retroactively obvious, which is the most useful kind. Any other comments on agent deployment on Railway?Jake [00:50:51]: It's getting better every day. I'm on X or Twitter. You can always yell at me about the parts not working as well as they should, because plenty of things should work way better.The New Serverless: Stateful, Long-Running, Pay-for-What-You-Use LinuxSwyx [00:51:04]: At this stage, when people want massively or embarrassingly parallel compute, they usually talk serverless. I feel like there's a new serverless compared to the previous five years of serverless. You're in that new bucket. Do you have comparisons or philosophical differences you want to call out?Jake [00:51:31]: It's somewhere in between. It's the ability to run stateful, long-running workflows or executions.Swyx [00:51:42]: Vercel has Fluid Compute, Cloudflare has some container thing, Google has App Runner and others.Jake [00:51:55]: That's where everything is roughly going, and it's why we've been working on this for six years. We believe users need access to a computer: a box that speaks Linux. They need to deploy what they want. Other systems change the surface area of what you can build. For us, users need a computer and need to deploy anything they truly want. That's why we've focused on the primitives: network, compute, storage. If we give you those and expose them so you can run things indefinitely, that's where we believe it's going.Jake [00:52:43]: Twitter has no nuance, so everyone says “servers” or “serverless.” It's always somewhere in the middle: I want to run it for a long time, but I don't want to provision the resource statically or pay for things I'm not using. That's been our thesis from day one: pay only for what you use, run it indefinitely, and it is full Linux.Swyx [00:53:12]: That's why I like the naming of Fluid. It's fluid. Flexible.Heroku, Focus, and Carrying the Torch Without Becoming the PastSwyx [00:53:18]: Another milestone is the Heroku official deprecation. You're one of the presumptive new Herokus. “New Heroku” has been a category for as long as I've been in developer tooling. It's finally happening. What was that like? Any behind-the-scenes of, “This is the moment”?Jake [00:53:42]: You have people where you're like, “You were running stuff on here? You, as this company?” It's crazy that names you would know are running on it and now coming to us saying, “We want to move a lot of this off.”Swyx [00:54:00]: Any behind-the-scenes on why Salesforce let Heroku stagnate?Jake [00:54:05]: I can only guess. It's hard when it's not your business. Salesforce's business is to build a great CRM. That's their focus. Then you acquire a compute business as an offshoot. A lot of early Meta people talk about focus. Boz has a write-up about how in the early days of Meta they had no money, so they were forced to focus. Then they turned on the money tree and had no reason not to split their focus.Jake [00:54:52]: But that dilutes your product. You get offshoots where you ask, “Is this the focus of the business?” If it's not core, it languishes. A lot of companies get in trouble when they split focus because they're fighting a multi-front war, not just externally but internally for alignment. Where are we going? What are we doing? What is our purpose?Jake [00:55:24]: If you're Salesforce-built and mission-driven, you want to work on Salesforce. Heroku is off to the side. It's not core to the business. Getting resources, budget, focus, and alignment internally becomes hard. It was a matter of time.Swyx [00:56:06]: Kudos for them to call it out instead of leaving it unknown.Jake [00:56:12]: Their release was a little odd. They called it out, but they didn't say they were shutting it down. Behind the scenes, I think they issued messages to people saying they should close accounts and that they were going to deprecate and remove things over time.Jake [00:56:30]: It's crazy because some of my first deployment experiences were on Heroku. You start with dragging things into an FTP server, then you try to get a deploy working, and then it's Heroku. It was the on-ramp for us. But the wheel turns. New things emerge. We're happy to carry the torch for a lot of that. But we don't want to be the new Heroku. We want to be the way people build and deploy software, and ultimately the way people monetize software over time.Swyx [00:57:19]: It's still a big crown to be the new Heroku. There are 50 companies that fought for that.Jake [00:57:23]: Everybody is holding some portion of it. We're happy to support people and companies. The platform works differently. The game loop is similar, but we've been dogmatic about where these things are going: primitives, agents, fan-out. Some things fit; some workflows need to change. We have an approximation of Heroku pipelines with the environment system. It's exciting. We've got a ton of people we can support, and it's growing a lot.Temporal, Workflow Engines, and State MachinesSwyx [00:58:12]: I have one more technical question about Temporal. I've sold my shares. You're a power user and one of our earliest customers. I met you through Temporal. You built on Temporal. You have complaints. This may be the most neutral and informed conversation anyone will hear about Temporal without someone working at the company.Jake [00:58:39]: That's fair. I've used Temporal for almost 10 years because of Cadence at Uber.Swyx [00:58:52]: Give people a sense of what Cadence was at Uber.Jake [00:58:57]: Cadence was the precursor to Temporal. It powers trip actions, rides, when you rent a Jump bike or scooter or car. You're running workflows for a period of time and saying, “This ride will run indefinitely until it finishes.” You attach information: you paused in this zone, so add this charge to the bill. When you end the trip, the workflow is done. That experience was powered by Cadence at the time.Swyx [00:59:34]: I used to say it's like programming the entire user journey top-down as one function.Jake [00:59:39]: It's a powerful idea and important. It's also important for the next phase of the agentic journey. You want an agent to do a specific task, be complete or incomplete on that task, and move on to the next thing. You need a way to manage workflows dynamically.Jake [00:59:59]: Temporal was always great in theory, and great when you got it working the way you wanted in production. But it required you to model the entire journey in your head. If you didn't, you could cause issues where replaying the state of the workflow causes non-determinism.Swyx [01:00:25]: Because it works on deterministic workflow history.Jake [01:00:28]: Exactly. I describe it as a jet engine. If you know how to operate it and run it, it's great. But you can't hand it to people trying to build complicated things if they don't have the whole state in their head.Jake [01:00:48]: We run our whole deployment pipeline on top of it. That's a reasonably complicated workflow: pre-commit hooks, signaling, queuing, and all the rest. We ran into the same thing at Uber. As you express a large workflow, it gets more complicated, with more states in the state machine that you have to map back to the workflow.Swyx [01:01:15]: It's a lot of ifs.Jake [01:01:16]: Exactly. At Uber, we built a system for doing the state machine and testing it. We've started to build some of those things here because it's grown heavily. It's not quite love-hate. When it works well, it works super well. But if someone who doesn't have full context puts something into the system that invalidates state or causes non-determinism, or spins off a ton of activities, you have to keep track of underlying SRE knobs like activity slots. Those should scale with memory, vCPU, and so on. It becomes a bear to scale.Swyx [01:02:10]: You need a capable sysadmin running things behind the scenes. If you moved off, what would you do?Jake [01:02:19]: We'd build our own workflow engine. We have a few internally that we've worked on.Swyx [01:02:27]: This is one of those classes of things you typically wouldn't vibe code, but I'm wondering if you can.Jake [01:02:33]: I still don't think you should vibe code it. You still want to run decent tests to make sure it works.Swyx [01:02:39]: Timo didn't invent that from scratch either. There are libraries you can run. On top of that, it's just a state machine that you have to map out. Ultimately, you define the instructions you want and run them through a state machine.Jake [01:03:00]: It's very doable. Workflow stuff is interesting. Restate is doing neat stuff here.Swyx [01:03:10]: You're tied into JavaScript. Are you a JavaScript maxi?Jake [01:03:13]: Internally, we have TypeScript, Rust, and Go. We don't add more languages. Actually, we have a little C because we write BPF code and hooks. But those are the languages.Swyx [01:03:28]: Is this for sidecars?Jake [01:03:32]: No. It's for the networking stack, volumes, and things like that. We use TypeScript a lot because it powers the dashboard, but we're moving a lot of workflow stuff off the dashboard stack and into the infrastructure stack.Railpack, Nixpacks, and Content-Addressable FilesystemsSwyx [01:04:00]: Cool. Any other technical infrastructure stuff? Railpacks?Jake [01:04:07]: We built an engine for determining dependencies based on source code. It's called Railpack. We built the first version, Nixpacks, on top of Nix, and then we moved.Swyx [01:04:17]: People have been trying to get me to adopt Nix and NixOS for four years. Is it ever going to be a thing?Jake [01:04:23]: I don't know. We're excited about it, but it has pain points. Think of it as a stack of versioned binaries at specific slices in time. If you want version X and version Y, you bloat the package space, which blows up image size and makes real-world workloads difficult.Swyx [01:04:53]: But you content-address it and cache it. In theory, there are optimizations.Jake [01:05:00]: In theory, yes. But with a large enough user base and disparate enough machines, you run into a problem Meta described in the XFAAS paper, their internal serverless system. It becomes difficult at scale unless you break out specific runtimes.Jake [01:05:24]: We didn't want to do that because we wanted to truly allow you to deploy anything. That was our initial thing with Nix. But we've moved toward interesting work around content-addressable file systems that can lazy-load anything from any point and page it into memory.Swyx [01:05:48]: Amazing.Jake [01:05:49]: The future is very bright. It's crazy, and it's going to be nuts.Coding Agent Spend, Roadmaps, and Token ROISwyx [01:05:54]: Founder journey stuff?Alessio [01:05:56]: Your cloud usage: you tweeted you're going to spend $300K this month?Jake [01:06:01]: I think we got to $200K.Alessio [01:06:02]: Coding agents?Jake [01:06:03]: Yeah.Swyx [01:06:04]: Across the company?Alessio [01:06:05]: You only have 35 people, so I'm sure they're not all spending $10K a month. What's the distribution?Jake [01:06:10]: I think I'm at about $25K. We have power users all the way down. We came back from winter break, and I basically said, “If you're writing code by hand, you're doing this wrong.” The tools are good enough now that you can move extremely quickly. There are issues and pain points, but you should be reviewing the code you are writing instead of writing it by hand.Jake [01:06:40]: Architectural patterns matter more now than ever, but you shouldn't spend your time generating code you would write. If you know how to write it, ask the agent to write it and reconcile it until it looks like you would have written it yourself.Jake [01:06:58]: People misconstrue my propensity to push people toward agents as connected to our growth and some reliability bumps. They're not necessarily related. The tools are good enough to move extremely quickly and build things way larger than you could before.Jake [01:07:19]: To the earlier point about cooling data centers in space: I don't know. But with software, you can ask, “How would I build block storage from scratch? How would I do these things?” I have ideas because I have history and have read papers. Let me work them out and build massive test benches with thousands of tests, because those are now free to author. If you're not using AI systems to speed-run your roadmap and reconcile your existing system onto the future, you're missing a large point of what's happening.Alessio [01:08:12]: What's the path to spending $3 million a month? Is it bound by ideas and things customers can absorb?Jake [01:08:19]: For most companies, it's bound by deployment at this point. That's why we've seen a massive boom in users and companies, from Fortune 50s down, asking how to get developers to move faster. You'll probably hit your CFO before any technical limits because they'll look at the eye-watering amount of money spent on tokens. Inference costs have to come down, but we're inference constrained now. There will be price discovery around what makes sense for an org to adopt.Jake [01:09:06]: I think you'll end up with the F1 driver concept. If someone is really adept at these things, it makes sense to put them in a $3 million car. If they're not, it probably doesn't make sense. You'll take a few people and say, “You can drive the F1 car. We need to go in this direction. Figure out if it works and prototype it.”Jake [01:09:33]: We've done some of that and vastly accelerated our roadmap. We thought we'd ship something in a few years; now we can probably ship it in a few months because we validated it and don't have to build it incrementally. We can skip steps and move toward our vision.Alessio [01:09:58]: A lot of people are realizing the roadmap doesn't always have a business impact, so they say tokens are too expensive. But if your roadmap were built to make more money by the time you built it, you'd have token pricing for it, the same way you do with sales. You'd spend a billion dollars on sales if you knew you would get $2 billion of revenue.Jake [01:10:19]: Exactly. A naive way to measure this is the percentage of tokens that end up in production. If you can measure impact because those tokens end up in production, that's awesome. But the burden of proof will rise. Internally, we have a growing number of pull requests that haven't merged. The question becomes: how do you get this into production? It's about how quickly you can build and deploy software, which is exciting because that's our whole thing.The SDLC Shift: Prompt Requests, Feature Flags, and Safe RolloutsSwyx [01:10:56]: The SDLC is changing. One thesis is that the pull request is dying. It's going to be the prompt request. Beyond that, code review is also kind of dying if you have all the other systems in place. What else is changing about the SDLC?Jake [01:11:19]: The AISRE and the tools to make it happen. AISRE is pie-in-the-sky aspirational. What does it take to get an AISRE? What tools do you need to build?Swyx [01:11:32]: You should expose your tooling to customers at some point. The Central Station command center.Jake [01:11:39]: We have it for template maintainers. Template maintainers can deploy and maintain templates, and they get feedback. We're going to expose those things incrementally.Swyx [01:11:51]: Clustering around incidents. Everyone has a version of that, but I don't think anyone has solved it.Jake [01:11:56]: I won't say we've solved it internally, but it's gotten so good that we can see incidents forming pretty quickly. At some point, those will be things either someone else builds or we build. We've always built things purpose-built for us. If it makes sense to make it useful for users, monetize it, or turn that loop into a profit center instead of a cost center, we want to do that.Jake [01:12:28]: Pull request is definitely dying.Swyx [01:12:29]: Do you do first-party feature flagging and incremental rollout stuff?Jake [01:12:34]: We have a feature-flagging engine we built internally and will eventually roll out.Swyx [01:12:38]: I don't see it as a user. How come you didn't give us what you have?Jake [01:12:43]: We have to beta test it. We care a lot about the quality of the things. There's plenty we've used internally that doesn't make it all the way through the journey because it fails. It works for one service but not multiple services. We'd have to build it for multiple services and know that if we released it, we'd rebuild it again and again. Some things are worth that, but many inform the roadmap.Jake [01:13:18]: We don't want to dilute the experience by saying, “This works, but only for this service,” unless it's a core initiative. Over the next few months, we'll roll out things that work for a single service, then multiple services, then multiple services across the environment. You have to be deliberate. Otherwise you create broken disparate experiences and support load because people ask how to use the feature.Jake [01:13:52]: It's the earlier expansion and compaction pattern. You expand the company to get features, then compact and smooth them out so the experience is stellar. You told me in the hallway, “It's gotten so much better.” Internally we're saying, “This part really sucks. We need to make it significantly better.”Swyx [01:14:11]: I can attest to that over the last three years watching you build Railway. For listeners, feature flagging is a huge part of Uber culture. So much so that they have too many feature flags and another thing to remove feature flags. Facebook has Gatekeeper. Agents are going to need this. It's fundamental to incremental rollouts. OpenAI acquired Statsig. GPT-5 is routing and flagging through different models.Jake [01:14:56]: It's super important. If the software development lifecycle is going to change because we're doing things 1,000 times faster and 1,000 times more concurrently, what becomes important at scale?Jake [01:15:16]: Before I started Railway, I built a feature-flagging product and tried to sell it. It was an easier version of LaunchDarkly. I ran into a problem: anyone small enough to adopt your technology doesn't care about feature flags, and anyone large enough to need feature flags needs so much scale that you have to build out all the infrastructure. I scrapped it.Jake [01:15:42]: But what is old is new again. Companies are trying to move quickly, but you can't YOLO a vibe-coded thing straight into production. You need to say, “Here's my blast radius, my impact, and I want to shadow it for these users.” Feature flags. You're going to need the tools larger companies built to maintain their structures. Everything gets compressed by 1,000x so everybody can build those structures quickly.Jake [01:16:07]: That's exactly where we are: compressing the software development lifecycle, then expanding it and adding more new things.Cattle, Pets, and Clonable InfrastructureSwyx [01:16:15]: Another term that comes to mind for newer developers is “cattle, not pets.” People treat production like a pet. It has a name. You baby it and keep it alive. With cattle, you can mass farm, roll out, portion parts out, and kill them.Jake [01:16:37]: I think that might change. You can move toward having pets as long as you have a cloning machine for your pets.Swyx [01:16:52]: Yeah.Jake [01:16:52]: If you can snapshot every single thing at every frame, it doesn't matter if something gets obliterated because you have a snapshot of it. The things we've built right now are designed to block changes from the hermetically sealed DevOps line. You have to write a Dockerfile because you nee

In this episode, Geddes Munson (SVP of Engineering @ Affirm) joins us to discuss operational / engineering excellence, scaling, and AI-native transformation! We explore Affirm's approach to operational and engineering excellence and how a 2024 outage became a turning point in refining that focus. We deconstruct “AI retooling week”, the internal tools it inspired (including an incident tracing system), how the AI-native transition is impacting operational / engineering excellence, and how to connect these projects to business goals. Plus, we take a look at their early work building in agentic commerce, infrastructure decisions they made years ago setting them up for success now, how they're thinking about designing for agent-first experiences.   ABOUT GEDDES MUNSON Geddes Munson serves as Affirm's SVP, Engineering. Previously, Geddes held several engineering leadership roles at Affirm, including oversight of the merchant engineering group, where he was responsible for the development of Affirm's solutions for key partners including Amazon, Shopify and Walmart. Prior to Affirm, Geddes held various technical leadership roles at rapidly growing startups including Mixpanel, SingleStore and EasyPost. He received his B.A. from Haverford College, where he started the Linux club on campus. Geddes lives in New Jersey with his wife and three children.   Unblocked: The context engine your coding agents are missing. Give your coding agents the context your best engineers have. Your agents can read code, but they don't know how your team works. Rules and MCPs give access to information but not understanding. That's why you still have to tell them where to look and what to look for. Unblocked gives your agents the history, conventions, and decisions behind your code so they generate mergeable output without the back and forth. It automatically surfaces the right context for every task, so agents stay on track without the set up tax or the correction loops. getunblocked.com/elc   SHOW NOTES: Defining operational excellence & what it looks like @ Affirm (4:36) Understand why your company / product matters to your customers (8:11) Key pivot points around engineering excellence @ Affirm (11:10) Creating a genuine culture change of operational / engineering excellence (14:27) Adopting agentic models @ Affirm (16:30) Navigating the balance between transformation, safety & reliability (18:30) Affirm's AI retooling week & hackathon setup (20:57) How the hackathon helped quickly change the company culture (23:15) Ensuring your practices serve your overall organizational vision & goals (26:11) Insights on scaling & increasing CICD investment @ Affirm (28:28) Approaches to building agentic commerce products (30:11) Strategies for building an agent-first experience (33:33) Bridging the gap between engineering & business goals / outcomes (35:44) Rapid fire questions (38:46)   LINKS AND RESOURCES 1929: Inside the Greatest Crash in History – and How It Shattered a Nation - New York Times bestselling author Andrew Ross Sorkin takes readers inside the chaos of the crash, behind the scenes of a raging battle between Wall Street and Washington and the larger-than-life characters whose ambition and naivete in an endless boom led to disaster. The dizzying highs and brutal lows of this era eerily mirror today's world—where markets soar, political tensions mount, and the fight over financial influence plays out once again. Delivering Happiness: A Path to Profits, Passion, and Purpose - a best-selling 2010 memoir by former Zappos CEO Tony Hsieh detailing his entrepreneurial journey and outlines his core philosophy: building a phenomenal corporate culture and focusing on the happiness of employees and customers ultimately drives long-term profits and business success.   This episode wouldn't have been possible without the help of our incredible production team: Patrick Gallagher - Producer & Co-Host Jerry Li - Co-Host Noah Olberding - Associate Producer, Audio & Video Editor https://www.linkedin.com/in/noah-olberding/ Dan Overheim - Audio Engineer, Dan's also an avid 3D printer - https://www.bnd3d.com/ Ellie Coggins Angus - Copywriter, Check out her other work at https://elliecoggins.com/about/ Hosted by Simplecast, an AdsWizz company. See pcm.adswizz.com for information about our collection and use of personal data for advertising.

You still need DBAs (that know how to back up systems and test restores). If you think you don't, or if you manager does, then perhaps they ought to read this piece on how an AI agent deleted a production database. This wasn't the case of an agent just running around with sysadmin access to all resources, or a lack of tests that allowed bad code to flow through a CI/CD process. This was a system design that had a hole in it. An API call to change infrastructure that could change both staging and production. Not something an AI set up, but humans did. A hole from both PocketOS and the API vendor that allowed the AI agent to make the same type of mistake we've seen humans make. A mistake of not double checking, not verifying, not following the rules of getting a second set of eyes, even a second set of virtual eyes, on the code that could drop resources. Read the rest of Limit the Blast Radius

In this week's Security Sprint, Dave and Andy are joined by Anna Mentzer-Hernandez to talk about the following topics:Opening:• AI Governance: Aligning Corporate Structures with Emerging Tech - Gate 15 o CISA & G7 Partners Release Joint Guidance on the Minimum Elements of a Software Bill of Materials for Artificial Intelligence o Thinking carefully before adopting agentic AI - NCSC • Non-Human Identities (NHIs) Are Growing Faster Than Most Security Programs - RSAC Conference - 13 May 2026 Gate 15's Sadie-Anne Jones wrote that non-human identities are expanding rapidly across cloud, automation, AI, API, SaaS, and CI/CD environments, often outpacing the governance programs meant to control them.• PERSPECTIVE: Stabilizing the Cybersecurity and Infrastructure Security Agency Starts With These Critical Steps - HSToday - 13 May 2026 Scott Algeier, Executive Director of the Information Technology Information Sharing and Analysis Center and Executive Director of the Food and Agriculture Information Sharing and Analysis Center, argues that stabilizing CISA requires renewed public-private partnership, legal protections for information sharing, and practical reforms that strengthen trust with industry. Main Topics:Hurricane Season & (TLP:GREEN) GATE 15 TARGET Hurricane Preparedness, 18 May 2026San Diego shooting: 5 dead in mosque attack; anti-Islam writings found - Los Angeles Times - 18 May 2026 The Los Angeles Times reported live updates on the San Diego mosque attack, including that five people were dead and anti-Islam writings were found as investigators examined motive. The reporting described a large law enforcement response and continued investigation into whether the attack was driven by bias or extremist intent. The incident has elevated concern around religiously motivated targeted violence and the protection of schools or community spaces co-located with houses of worship. Target is faith-based organizations, Muslim communities, school administrators, and emergency managers with Dig highlighting the intersection of hate-driven violence, mass casualty response, and community security preparedness.Iranian hackers target gas stations and internet-connected systems amid regional tensions – CNN – 15 May 2026 Iranian-linked cyber actors are reportedly targeting internet-connected systems and fuel distribution infrastructure amid heightened geopolitical tensions involving Iran and Western governments. Analysts assess the activity as part of a broader pattern of retaliatory cyber signaling intended to demonstrate disruptive capability without crossing into full-scale destructive cyber conflict. The incidents reinforce ongoing concerns regarding the exposure of operational technology and public-facing infrastructure systems vulnerable to politically motivated cyber operations. Target is fuel distribution systems and internet-connected infrastructure environments with Dig highlighting how geopolitical escalation continues to increase cyber risk to civilian operational systems. • ISACs! ONE-ISAC, Tribal-ISAC, RH-ISAC• Iraqi National Arrested and Charged with Providing Material Support to Iranian-Backed Terrorist Organizations and Directing Attacks Targeting U.S. Citizens and Interests Quick Hits:• Fine of nearly £1m issued against South Staffordshire Plc and South Staffordshire Water Plc • UK water company allowed hackers to lurk undetected for nearly two years, regulator finds • W.H.O. Declares Ebola Outbreak a Global Health Emergency

A poisoned software package compromised OpenAI employee devices before security teams could stop it. The company behind critical Ozempic injection components has been offline for weeks after a ransomware attack. And Change Healthcare is now facing another major lawsuit tied to the 2024 breach that crippled healthcare payments nationwide. Three stories. One message: Your business is now exposed to companies you don't control. On this episode of Security Squawk, Bryan Hornung, Randy Bryan, and Reginald Andre break down three cyber incidents that reveal how third-party trust has become one of the biggest operational risks in business today. This Week's Cybersecurity Breakdown 1. OpenAI, TanStack & the npm Supply Chain Worm A software supply chain attack spread through trusted developer ecosystems at massive speed: 42 npm packages poisoned in six minutes Malware stole GitHub tokens, AWS credentials, and CI/CD secrets OpenAI confirmed two employee devices were compromised ChatGPT Desktop, Codex App, Codex CLI, and Atlas certificates rotated Demonstrates how modern attacks now spread through trusted development infrastructure 2. West Pharmaceutical Ransomware Attack A cyberattack against a company most people have never heard of — but nearly everyone depends on: West Pharmaceutical components are used in roughly 43 billion injectable drug deliveries annually Includes Ozempic, Wegovy, insulin pens, vaccines, and hospital injectables Systems taken offline globally after ransomware deployment Manufacturing disruptions continue weeks later 3. Allied World v. Change Healthcare — The Financial Fallout Begins The legal consequences of the Change Healthcare breach are escalating: Cyber insurer Allied World filed suit seeking more than $1 million in damages Avesis operations were disrupted for roughly 90 days Root cause traced to a low-level Citrix account with no MFA Credentials were reportedly circulating on Telegram prior to the breach The Bottom Line The modern business attack surface is no longer just your company. It's: your software vendors your healthcare clearinghouses your package repositories your pharmaceutical suppliers Every trusted relationship is now a potential point of failure. And when those companies get breached, your business absorbs the consequences. Support the show: buymeacoffee.com/securitysquawk Subscribe for weekly breakdowns of ransomware, supply chain attacks, AI threats, and executive-level cybersecurity strategy.

Mock-интервью с Николаем Лебедевым - DevOps/SRE-инженер, 17 лет в Linux, 4 года AWS EKS. Stack: Terraform, Flux, Cassandra, Kafka, Vault, SOPS. Два часа - много практики, много каверзных вопросов. ЧТО СПРАШИВАЛИ ☁️ AWS: EKS и IRSA, VPC с нуля (CIDR, multi-AZ, multi-region), managed K8s vs self-hosted, Elasticache, Golden Signals и метрики SRE.

This show has been flagged as Clean by the host. NLUUG Spring Conference 2026 "NLUUG is the association of (professional) Open Source and Open Standards users in the Netherlands" You can follow them on @nluug@nluug.social on Mastodon. I was particularly interested to attend their 2026 Spring Conference 2026 as our own Jeroen Baten was giving a talk on "Getting started with CI/CD using Forgejo Actions and why this is important AF" He assures me he will post it as a show. cough owes me a show cough . While there the urge to record came upon me, so I was able to snag a few interviews. Ronny Lam representing NLUUG NLUUG is the association for (professional) developers, administrators and users of UNIX/Linux, Open Source, Open Source, Open Systems and Open Standards in the Netherlands. The NLUUG community includes, system administrators, programmers and network specialists. If you are working as an open professional, then NLUUG is the excellent association where you can keep track of your technical knowledge, for example during our six-monthly conferences. The aim of NLUUG is to disseminate the application and knowledge of open standards and UNIX/Linux. NLUUG maintains close ties with many organizations and individuals who pursue the open mind. https://nluug.nl/organisatie/personen/ronny-lam/ https://nl.wikipedia.org/wiki/NLUUG https://nluug.nl/ Nico Rikken representing the FSFE The Free Software Foundation Europe is a charity that empowers users to control technology. Software is deeply involved in all aspects of our lives. Free Software gives everybody the rights to use, understand, adapt, and share software. These rights help support other fundamental rights like freedom of speech, freedom of press, and privacy. Learn more While we are no strangers to chatting with the Free Software Foundation Europe ( hpr857 , hpr1957 , hpr2223 , hpr2945 , hpr2946 , hpr3388 , hpr3407 , hpr3833 ), this was the first time we had a chance to interview Nico Rikken . We chat about freedom and Ada and Zangemann - A Tale of Software, Skateboards, and Raspberry Ice Cream by Matthias Kirschner and Sandra Brandstätter . Geert-Jan Meewisse representing Coalition for Fair Digital Education The Coalition for Fair Digital Education (CEDO) is a group of concerned parents, IT professionals, teachers, and privacy advocates committed to enabling fair and sovereign digital education. The coalition operates as a working group within Internet Society Netherlands (ISOC). We have drafted a manifesto calling for improvements in digital education. Today, children in education receive an online account from a foreign Big Tech company at an early age. Through this account, data can be collected, profiles can be built, and personal information can be used and exploited by these companies. This profiling leads to children being categorized and receiving tailored content that companies deem relevant—before they even discover things for themselves. And that's not the only issue. Since schools exclusively use “standard” Big Tech solutions, children do not learn about alternative programs or tools. As a result, real digital skills and critical thinking are not developed, making children dependent on a company that profits from their data. The privacy and sovereignty of digital education are under severe pressure, affecting not only students but also teachers and parents, who are forced to use the same systems. Other countries are already ahead in this regard: in Denmark, Google products have been banned in schools in Helsingør municipality, and the German state of Baden-Württemberg has prohibited Microsoft 365. We advocate for the development of an open-source digital infrastructure for learning and educational tools, based on public values such as autonomy, equality, sovereignty, democracy, transparency, accessibility, academic freedom, and privacy-by-design. To achieve this, raising awareness among students, parents, teachers, and school boards is crucial. Additionally, we aim to involve policymakers by presenting our manifesto. https://eerlijkdigitaalonderwijs.nl/english/ A working group of the Internet Society , Geert-Jan was here to tell us of their work to build a FLOSS alternative for Education. You can get in touch with him at gj -at- eerlijkdigitaalonderwijs .nl , or @geert-jan:matrix.org Conclusion I had great conversations with the sponsors who were a little shy about doing an interview. They do have a range of jobs available for those of us with Dutch nationality, and have lived in the Netherlands for the last 10 years. The event was fantastic, professional, held in a great venue, and the closest thing to real life xkcd: Shibboleet as you are likely to get. I would like to thank the NLUUG team, volunteers, venue staff and of course the attendees for a wonderful day. With any luck this will not be the last time you hear about this team on HPR. The recordings will be available on the NLUUG FTP Server Provide feedback on this episode.

Developers are increasingly working inside AI-powered coding tools like Claude Code, Cursor, and Codex.The workflow is changing.Instead of constantly switching between dashboards, logs, terminals, and configuration files, developers are starting to collaborate directly with coding agents using natural language.We think CI/CD should evolve alongside that shift.Today, we're introducing Semaphore for AI Agents — a new open-source CLI and agentic interface designed to make Semaphore fully accessible from AI coding agents.This is the first step toward what we call the AI-native Semaphore experience.What is Semaphore for AI Agents?Semaphore for AI Agents gives coding assistants a structured way to interact with Semaphore.Instead of manually navigating CI/CD systems, developers can simply ask:* “Why is my CI failing?”* “What tests are flaky?”* “Show me the critical path in this pipeline.”* “Summarize the health of this project.”And their coding agent can retrieve, analyze, and act on that information directly through Semaphore.The first release includes:* Pipeline diagnostics* Flaky test detection* Critical path analysis* Organization-wide CI/CD insights* MCP support* Claude Code integrations* Remote execution workflows on Semaphore infrastructureWe also demonstrate how developers can provision ephemeral machines for agent-driven workflows, remote testing, and scalable execution.Built for Agentic WorkflowsSemaphore for AI Agents was designed specifically for AI-native development workflows.The project ships with:* Agent-oriented commands* Structured JSON outputs* Claude Code skills* Generic agent skills* A local MCP serverThis allows coding assistants to interact directly with Semaphore while developers stay inside their coding environment.Fully Open SourceSemaphore for AI Agents is fully open source.Developers can inspect how it works, extend workflows, contribute new commands, and build their own automations.We believe AI-powered developer tooling should remain transparent, inspectable, and developer-controlled.This Is Just the BeginningSemaphore for AI Agents is the foundation for a broader direction we're building toward at Semaphore:* Developers define intent* Agents handle repetitive execution* Semaphore provides the infrastructure and orchestration layerOver the coming weeks, we'll continue shipping new workflows, MCP capabilities, testing automation, and scalable agent execution features.Watch the DemoWe recorded a full walkthrough showing:* CI/CD debugging workflows* MCP integrations* Claude Code usage* Organization-wide insights* Remote execution on Semaphore infrastructure→ [Read the full blog post]Thanks for following along.Till the next product update.Pete Miloravachttps://semaphore.io This is a public episode. If you would like to discuss this with other subscribers or get access to bonus episodes, visit semaphoreio.substack.com

Java 26 est là, GraalVM cartonne chez Trivago (43 à 12 réplicas !), OpenJDK interdit le code généré par LLM, Spring et Quarkus enchaînent les releases. Côté IA : ADK 1.0, A2A, Lyria 3 chante (mal ?), Yann LeCun lance Ami Labs et ses World Models. Mythos d'Anthropic fait trembler la sécu, Claude Code a leaké son source, et les git worktrees envahissent vos terminaux. Bonus : la mort annoncée de l'IDE, vagues de licenciement chez Oracle et Block, et nos voix toutes clonées. Bon week-ends de mai ! Enregistré le 7 mai 2026 Téléchargement de l'épisode LesCastCodeurs-Episode-340.mp3 ou en vidéo sur YouTube. News Langages Retour d'expérience d'une migration vers graalVM chez Trivago https://medium.com/graalvm/inside-trivagos-graalvm-migration-native-image-for-graphql-at-scale-912bca9df841 La passerelle GraphQL de Trivago (point d'entrée de tout le trafic vers 48 microservices) souffrait de pics de timeout au démarrage JVM Résultats spectaculaires après migration vers GraalVM Native Image : réduction des réplicas de 43 à 12, CPU de 15 à 5 cœurs, images Docker plus légères Obstacles techniques : incompatibilité Log4j → migration vers Logback, remplacement de Mockk par Testcontainers, compilation CI/CD très gourmande Netflix DGS et d'autres librairies manquaient de support GraalVM → l'équipe a contribué des correctifs upstream en open source Approche recommandée : commencer par les services les moins complexes, investir massivement dans les tests automatisés À la 14e migration, le processus était si rodé qu'il allait plus vite que la toute première tentative OpenJDK Interim Policy on Generative AI - https://openjdk.org/legal/ai OpenJDK adopte une politique intérimaire interdisant toute contribution incluant du contenu généré par des LLMs, modèles de diffusion ou systèmes deep-learning Le périmètre est large : code source, texte, images dans les dépôts Git, pull requests GitHub, emails, pages wiki et issues JBS Les contributeurs peuvent utiliser les outils d'IA de manière privée pour comprendre, déboguer et relire le code OpenJDK, mais ne peuvent pas contribuer le contenu généré Trois risques justifient cette politique : surcharge des relecteurs face au code plausible mais incorrect, risques de sûreté/sécurité pour une plateforme critique, et risques de propriété intellectuelle (l'OCA exige que les contributeurs possèdent les droits IP de leurs contributions) Même éditer partiellement du code AI-généré ne le rend pas acceptable à la contribution Oracle, sponsor corporatif d'OpenJDK, travaille sur une politique complète à soumettre au Governing Board GraalVM Native Image et la Closed-World Assumption en Java https://pvs-studio.com/en/blog/posts/java/1357/ Un bon article de rappel du contexte de closed world en Java GraalVM Native Image compile les applications Java en exécutables natifs statiques, sans JVM au runtime. La JVM fonctionne en monde ouvert : les classes sont chargées à la demande, les appels sont des références symboliques résolues dynamiquement. Native Image impose la "closed-world assumption" : tous les chemins d'exécution doivent être connus à la compilation. Les fonctionnalités dynamiques Java (réflexion, proxies, chargement de classes) créent des chemins cachés invisibles à l'analyse statique. C'est pourquoi Native Image exige des fichiers de configuration explicites pour la réflexion, les proxies, les ressources et la FFM API. L'article illustre le problème avec la Foreign Function & Memory API pour appeler printf natif : fonctionne sur JVM, échoue en Native Image sans config. Inclure tout le bytecode accessible serait inutilisable : binaire géant, compilation très lente, et la réflexion nécessite des métadonnées précises. La configuration n'est pas un défaut de conception mais une conséquence logique du passage du dynamique au statique. Java 26 : les nouveautés https://foojay.io/today/java-26-whats-new/ Java est le langage de la JVM, publié tous les 6 mois depuis Java 9 ; Java 26 est une version non-LTS avec 10 JEPs. JEP 500 : protection des champs final modifiés par réflexion profonde, avec des avertissements configurables. JEP 504 : suppression définitive de l'API Applet, plus supportée par les navigateurs. JEP 516 : le cache AOT (Project Leyden) fonctionne désormais avec n'importe quel garbage collector. JEP 517 : support HTTP/3 dans le client HTTP, HTTP/2 reste le défaut mais HTTP/3 est accessible à la demande. JEP 522 : amélioration du débit du GC G1 en réduisant la synchronisation entre threads applicatifs et threads GC. Nouveau support des UUIDv7 via UUID.ofEpochMillis(), naturellement triables et adaptés aux identifiants de bases de données. Process devient AutoCloseable, utilisable dans un try-with-resources. Aucune fonctionnalité en preview n'est graduée en standard ; Structured Concurrency en est à sa 6e preview. Librairies Guillaume a créé une petite librairie Java sans dépendance pour extraire le JSON d'une réponse d'un LLM un peu verbeux https://glaforge.dev/posts/2026/03/22/extracting-json-from-llm-chatter-with-jsonspotter/ Les LLM génèrent souvent du JSON, mais il est parfois entouré de bla-bla et/ou contient des erreurs (ex: commentaires, virgules finales) qui bloquent les parseurs JSON standards. Guillaume a créé une petite librairie légère sans dépendance pour localiser et extraire la structure la plus longue ressemblant à du JSON (même malformé) On peut ensuite passé cette chaîne à un parseur "lénient" (plus tolérant) comme Jackson pour ensuite avoir de bons vieux objets Java fortement typés Librairie dispo sur Maven Central ADK Java sort sa version 1.0 (Agent Development Kit par Google) https://developers.googleblog.com/announcing-adk-for-java-100-building-the-future-of-ai-agents-in-java/ ADK est un framework open source de Google pour créer des agents IA, initialement en Python, maintenant multi-langages (Python, Java, Go, Typescript). Nouvelles fonctionnalités majeures : Outils puissants : GoogleMapsTool, UrlContextTool, ContainerCodeExecutor, VertexAiCodeExecutor, abstraction ComputerUseTool. Architecture de plugins centralisée : Nouveau conteneur App pour gérer les Plugins à l'échelle de l'application (ex: LoggingPlugin, GlobalInstructionPlugin). Context engineering amélioré : Compaction d'événements pour gérer la taille des fenêtres de contexte (résumé et rétention). Human-in-the-Loop (HITL) : Supporte les workflows ToolConfirmation pour approbation humaine des actions d'agent. Services de session et de mémoire : Contrats clairs pour la gestion de l'état (InMemory, VertexAI, Firestore) et la mémoire à long terme. Support Agent2Agent (A2A) : Collaboration native entre agents distants de différents frameworks via le protocole A2A. Dans cet autre article, Guillaume partage comment il a développé l'application Comic Trip montrée dans la vidéo YouTube et qui utilise ADK 1.0 https://glaforge.dev/posts/2026/03/30/building-my-comic-trip-agent-with-adk-java-1-0/ Nouvelle version du SDK Java pour Agent2Agent Protocol, avec le support de la version 1.0 de la spécification https://medium.com/google-cloud/a2a-java-sdk-1-0-0-beta1-released-e83c414b34cc Alignement avec la version 1.0 de la spécification Nouveau groupId org.a2aproject.sdk et package org.a2aproject.sdk Protocoles de transport : support complet et équivalent pour JSON-RPC, gRPC et HTTP+JSON/REST. Gestion des erreurs : introduction de codes d'erreur et détails structurés pour une meilleure observabilité. Optimisation HTTP : ajout d'en-têtes de cache pour les métadonnées des agents (Agent Card). Flexibilité du client HTTP : support par défaut du JDK HttpClient, avec option Vert.x pour les environnements Quarkus. Nouvelles fonctionnalités techniques : méthode DataPart.fromJson() pour la création simplifiée d'objets depuis du JSON brut. Prochaines étapes (v1.0.0.GA) : support simultané des versions 1.0.0 et 0.3.0 du protocole pour assurer l'interopérabilité. JPA 4.0 Milestone 2 : nouvelles fonctionnalités pour Jakarta Persistence https://in.relation.to/2026/04/23/JPA-4-M2/ Jakarta Persistence (JPA) est la spécification standard Java pour le mapping objet-relationnel (ORM), implémentée notamment par Hibernate. JPA 4.0 M2 est la deuxième milestone de la prochaine version majeure de la spécification, annoncée par Gavin King. Construction de requêtes Criteria à partir de chaînes JPQL, offrant plus de flexibilité dans la composition dynamique des requêtes. Nouveaux types d'expressions spécialisés (TextExpression, NumericExpression) pour simplifier l'écriture des requêtes Criteria. Nouvelle interface FetchOption pour contrôler explicitement la stratégie de chargement des associations, dont un BatchSize intégré. Nouvelle annotation @EntityListener qui découple les classes entités de leurs listeners, supprimant les dépendances à la compilation. Les listeners peuvent cibler plusieurs types de callbacks et s'appliquer globalement à toute l'unité de persistance. Introduction de FlushModeType.EXPLICIT et QueryFlushMode pour un contrôle plus fin de la synchronisation avec la base de données. La méta-annotation @Discoverable permet de placer des annotations comme @NamedQuery sur n'importe quelle classe ou interface. Améliorations du DDL via @Index amélioré et clarifications de la spécification via la javadoc. Quarkus 3.35 : tree-shaking, PGO et AOT Semeru https://quarkus.io/blog/quarkus-3-35-released/ Quarkus est un framework Java cloud-natif optimisé pour GraalVM et HotSpot, conçu pour les microservices et les environnements conteneurisés. Nouveau JAR tree-shaking expérimental : analyse des dépendances à la compilation pour supprimer les classes inutilisées. Sur le CLI Quarkus, cela supprime plus de 6 000 classes et économise environ 18 Mo (39,5 %). Support du Profile-Guided Optimization (PGO) pour les builds natifs via quarkus.native.pgo.enabled=true. Le PGO est une fonctionnalité Oracle GraalVM, non disponible dans la Community Edition. Support de l'AOT IBM Semeru : le démarrage passe de ~380 ms à ~190 ms dans les premiers tests. Nouvelle extension quarkus-reactive-transactions : support de @Transactional pour les méthodes Hibernate Reactive retournant Uni. Configuration CORS dédiée pour l'interface de management, indépendante de l'interface HTTP principale. Les tests n'utilisent plus les System Properties pour la propagation de configuration, facilitant la parallélisation future. Le serializer jackson sans reflection n'est pas le default du aux retours de cas limites, encore du travail This Week in Spring - 21 avril 2026 https://spring.io/blog/2026/04/21/this-week-in-spring-april-21-2026 Spring Framework 6.2.18 et 7.0.7 corrigent trois failles de sécurité : DoS via fichiers multipart WebFlux, empoisonnement de cache de ressources statiques, et DoS sur Windows. Le support open source de Spring Framework 5.3.x et 6.1.x est terminé, la migration est recommandée. Spring Data 2026.0.0-RC1 introduit l'upsert (MERGE/INSERT ON CONFLICT) dans l'API Template de Spring Data Relational. Spring Data ajoute un RedisMessageSendingTemplate pour la cohérence avec les listeners Redis, et une optimisation de réinitialisation de caches en un seul appel. Spring AI introduit une Session API (série Agentic Patterns, partie 7) : architecture event-sourcée pour la mémoire des agents IA. La Session API supporte la compaction turn-safe, l'isolation de sous-agents en parallèle, et la persistence JDBC (PostgreSQL, MySQL, MariaDB, H2). Elle vise Spring AI 2.1 (novembre 2026) et remplacera à terme l'API ChatMemory. Spring Vault 4.1.0-RC1 et 4.0.2 sont disponibles. Netflix a présenté son usage de Java, Spring Boot et Spring AI dans une vidéo. This Week in Spring - 28 avril 2026 https://spring.io/blog/2026/04/28/this-week-in-spring-april-28-2026 Cette série hebdomadaire de Josh Long compile les nouveautés de l'écosystème Spring : articles, outils, podcasts et annonces de la communauté. Spring Boot 4 introduit un package natif de résilience org.springframework.resilience avec une nouvelle API de retry qui remplace les approches fragiles via Spring Retry ou Resilience4j. L'API retry native de Spring Boot 4 a des noms d'attributs et sémantiques différents des anciennes bibliothèques, rendant les tutoriels pré-2025 obsolètes et sources de bugs silencieux. Le SDK Spring AI pour Amazon Bedrock AgentCore est disponible en GA : il intègre les capacités AgentCore dans Spring AI via annotations et auto-configuration. Le SDK AgentCore gère automatiquement le contrat runtime AgentCore : endpoint /invocations, health check /ping, SSE avec backpressure. Il offre mémoire court terme (sliding window) et long terme (sémantique, préférences, résumé, épisodique), ainsi que des outils pour navigateur et exécution de code en sandbox. Un plugin Maven (Nullability Maven Plugin) simplifie l'intégration de JSpecify et NullAway pour enforcer la null-safety à la compilation dans les projets Java. Le plugin génère automatiquement les fichiers package-info.java par package et configure le compilateur pour traiter les violations de nullabilité comme des erreurs. Josh Long et Dr. Venkat Subramaniam ont co-présenté à Voxxed Days Amsterdam sur "Intelligent Kotlin", avec un épisode de podcast associé. Cloud Amazon S3 Files https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-s3-files/ Amazon S3 Files est un nouveau service donnant un accès système de fichiers direct aux données stockées dans les buckets S3 Basé sur la technologie Amazon EFS, il supprime la barrière entre stockage objet et interface système de fichiers sans dupliquer les données Débit en lecture pouvant atteindre plusieurs téraoctets par seconde ; des milliers de ressources de calcul peuvent y accéder simultanément Les données restent accessibles via les deux interfaces : S3 API classique et système de fichiers standard, sans migration nécessaire Cas d'usage : agents IA pour la persistance de mémoire entre pipelines, équipes ML sans staging, simplification des data lakes Disponible dans 34 régions AWS Data et Intelligence Artificielle Comment générer de la musique et des clips audio en Java avec le modèle Lyria 3 https://glaforge.dev/posts/2026/03/25/generating-music-with-lyria-3-and-the-gemini-interactions-java-sdk/ Génération musicale avec Lyria 3 (DeepMind) et le SDK Java Gemini Interactions. Lyria 3 : modèle d'IA générative pour créer musique avec paroles ou pistes instrumentales. Utilisation via le SDK Java de l'API Gemini, nécessite une clé API Gemini. Deux versions de modèle Lyria 3 : lyria-3-clip-preview : Clips courts (30s), extraits. lyria-3-pro-preview : Chansons complètes (jusqu'à 3 min), structurées. Personnalisation via les prompts : Fournir ses propres paroles ou les faire générer. Contrôler la structure de la chanson ([Intro], [Verse], [Chorus], [Outro]). Générer des morceaux instrumentaux uniquement. Utiliser des images comme source d'inspiration (modèle multimodal). Sortie : Audio (MP3) et texte (paroles/structure) directement, sans décodage complexe. Facilite l'intégration de la génération musicale dans les applications Java. Les world model, la prochaine étape pour les IA https://www.lepoint.fr/sciences-nature/comment-le-commando-de-yann-le-cun-se-prepare-a-ringardiser-les-geants-mondiaux-de-lia-depuis-paris-OZVUWTDYBNE25C6WF44265ZQKE/ Yann LeCun a quitté Meta FAIR pour créer AMI Labs (Advanced Machine Intelligence) basée à Paris Sa thèse : les LLMs ne mèneront pas à l'intelligence générale, la vraie IA doit partir de la compréhension du monde physique AMI Labs a levé 1,03 milliard de dollars en seed (le plus grand seed round de l'histoire européenne) à 3,5 milliards de valorisation Les world models apprennent à prédire et comprendre la réalité physique plutôt qu'à prédire le prochain token d'une séquence Slogan d'AMI : "Real intelligence does not start in language. It starts in the world." Paris comme base stratégique pour challenger la Silicon Valley dans la prochaine rupture de l'IA Debezium 2026 : résultats du sondage communautaire https://debezium.io/blog/2026/04/27/debezium-2026-survey-results/ Debezium est un outil de Change Data Capture (CDC) open source qui capture les modifications de bases de données en temps réel pour les diffuser vers des systèmes comme Kafka. 98,6% des répondants utilisent Debezium activement ou prévoient de le faire dans l'année, avec 91,3% déjà en production. 63,8% des déploiements tournent sur Kubernetes, 60,9% utilisent Kafka Connect auto-géré, et 17,4% restent sur des VMs ou bare metal. Helm charts est l'approche dominante pour la gestion de configuration, souvent combiné avec GitOps, CI/CD, Ansible ou Terraform. PostgreSQL domine les connecteurs utilisés à 69,6%, suivi de MySQL (33,3%), SQL Server (29%) et Oracle (27,5%). Les volumes de changements capturés vont de 1-25 modifications par minute jusqu'à 1-2 millions par minute selon les environnements. Infinispan rejoint l'écosystème OGX comme fournisseur de stockage vectoriel https://infinispan.org/blog/2026/04/17/infinispan-joins-ogx-ecosystem OGX (anciennement Llama Stack) est un serveur API agentique open source pour construire des applications d'IA complètes. OGX compose des fournisseurs d'inférence, des stores vectoriels, des backends de sécurité, des runtimes d'outils et du stockage de fichiers en un seul serveur déployable. OGX se positionne comme une alternative à l'API OpenAI, déployable sur diverses infrastructures et modèles. OGX cible les workflows RAG (Retrieval-Augmented Generation) et les applications agentiques. Infinispan s'y intègre comme fournisseur de vector IO, apportant recherche vectorielle, par mots-clés et hybride. Je n'ai pas entendu parlé de ce renommage, vous le voyez dans vos deploiements ? Outillage cmux un nouveau terminal basé sur Ghostty spécialisé pour les coding agents https://cmux.com/ Application macOS native construite sur le moteur de rendu Ghostty (libghostty), offrant une accélération GPU pour une fluidité maximale Conçu spécifiquement pour le multitâche et les workflows assistés par IA, avec des onglets verticaux affichant la branche Git, le répertoire et les ports actifs Intègre des notifications qui illuminent les panneaux lorsqu'un agent IA (Claude Code, Codex, etc.) nécessite l'attention de l'utilisateur Propose un navigateur web intégré et scriptable qui peut être affiché en écran scindé à côté du terminal via une API Alternative moderne à tmux, ne nécessitant pas de fichiers de configuration complexes ou de préfixes de touches pour la gestion des vitres et des sessions Supporte nativement tous les agents de codage en ligne de commande et permet l'automatisation via une API socket et une interface CLI dédiée Git Worktree comme un chef https://www.metal3d.org/blog/2026/git-worktree-comme-un-chef/ Article par Patrice Ferlet Git Worktree: Travailler sur plusieurs branches simultanément via des répertoires distincts. Évite git stash ou clones multiples pour le changement de contexte rapide. Méthode "bare" (recommandée): Cloner le dépôt en mode bare (ex: .bare). Lier le dossier racine au dépôt bare via un fichier .git. Configurer le remote tracking pour voir toutes les branches distantes. Ajouter des worktrees pour chaque branche (git worktree add ). Avantages: Économie d'espace, source de vérité unique (un git fetch met tout à jour), hooks/configs partagés, sécurité. Conseils: Ne jamais faire de git checkout à l'intérieur d'un worktree. git fetch --all depuis n'importe quel worktree pour tout mettre à jour. git worktree add --detach pour tester des merges temporaires sans créer de branche. Supprimer: git worktree remove puis git worktree prune. Un script wtree est fourni pour automatiser l'initialisation du setup "bare". Améliore considérablement le workflow. L'IDE meurt et vite https://x.com/jdegoes/status/2036931874057314390?s=46&t=C18cckWlfukmsB_Fx0FfxQ Des leaders techniques prédisent la fin rapide de l'IDE traditionnel, remplacé par des interfaces conversationnelles agentiques Le changement de paradigme : le développeur n'écrit plus des lignes de code mais exprime son intention et supervise des agents autonomes Des outils comme Claude Code, Copilot et Cursor transforment déjà radicalement les workflows de développement quotidiens L'IDE centré sur l'éditeur de code perd sa raison d'être quand l'agent lit, modifie et structure le code de manière autonome La transition est comparable au passage du desktop au mobile : les pratiques établies depuis 30 ans remises en question en quelques mois Le source de Claude Code a leaké via probablement le codemap et un site decrit sont fonctionnement https://ccunpacked.dev/ Le 31 mars 2026, Anthropic a accidentellement inclus les sourcemaps dans un package npm de Claude Code, exposant ~512 000 lignes de TypeScript La fuite n'était pas un piratage mais une erreur humaine : un "*.map" oublié dans .npmignore Le site ccunpacked.dev a été lancé pour analyser et visualiser le code source décompressé Le code révèle un agent background permanent nommé "KAIROS", un mode furtif pour cacher les contributions des employés Anthropic à l'open source, et 44 feature flags cachés Une fonctionnalité inédite "Buddy" (animal de compagnie électronique dans le terminal) et un mode "dream" pour l'idéation continue ont été découverts Anthropic a confirmé : "Aucune donnée client sensible n'était impliquée. Erreur humaine dans le packaging de la release." Gemini CLI passe aux agents https://x.com/srithreepo/status/2039794081925382307?s=46&t=GLj1NFxZoCFCjw2oYpiJpw Gemini CLI, l'agent IA open source de Google pour le terminal, introduit des hooks dans sa boucle agentique Les hooks permettent d'exécuter des scripts automatiquement (scanners de sécurité, vérifications de conformité, logging) à chaque étape de l'agent Lancement de Gemini CLI GitHub Actions : un agent autonome pour les repositories qui peut exécuter des tâches de codage de routine Support des MCP servers pour étendre les capacités et des "Agent Skills" pour des workflows spécialisés Mode agent disponible dans VS Code et IntelliJ avec accès aux outils du système de fichiers et terminal Wispr, le speech to text en local sur macOS http://wispr.stormacq.com/ Wispr est une application macOS de dictée vocale entièrement locale, propulsée par Whisper (OpenAI) sur appareil, sans cloud ni tracking Sébastien Stormacq a développé Wispr en un jour et demi sans écrire une seule ligne de code, grâce à Kiro CLI (agent IA Amazon) Disponible en open source sur GitHub et via Homebrew Détection automatique de la langue, insertion du texte au curseur dans n'importe quelle application via un raccourci global En un mois : 19 releases incluant mode mains-libres, suppression des mots de remplissage, auto-envoi pour les chats, et un outil CLI Exemple concret de développement vibe coding produisant un outil de qualité production sans expertise Swift préalable Comment, Gordon, l'assistant spécialisé en Docker est né https://n9o.xyz/posts/202603-building-gordon/ Nuno Coração (n9o.xyz) détaille comment Gordon, l'assistant spécialisé Docker, a été construit sur docker-agent, le runtime d'agents IA open source de Docker écrit en Go Les agents sont définis en YAML déclaratif et distribués comme des artefacts OCI, sans mise à jour binaire nécessaire L'architecture initiale en essaim de 9 agents spécialisés a été abandonnée au profit d'un agent racine unique avec un prompt soigneusement conçu Le modèle utilisé est Claude Haiku 4.5, suffisant après optimisation des prompts Principe clé "show, then do" : toute action de l'agent nécessite une approbation explicite de l'utilisateur La description des outils impacte fortement la précision du LLM : ajouter des outils peut paradoxalement dégrader les performances existantes Le prompt est une spécification détaillée (identité, patterns d'accès fichiers, règles de sécurité) plutôt qu'une simple instruction IBM Bob https://bob.ibm.com/blog/announcing-ibm-bob-launch IBM Bob assistant IA d'IBM pour coder sur de vraies codebases (lancé avril 2026) 5 modes : Ask, Plan, Code, Advanced (MCP), Orchestrator Détecte la complexité du code en temps réel et propose des refactos Fait des revues de code automatiques sur tes branches/issues GitHub Permet d'écrire en langage naturel directement dans l'éditeur Fonctionne aussi en terminal/CLI et dans les pipelines CI/CD Sécurité : approbation manuelle, .bobignore, checkpoints, pas de training sur tes prompts How I use Claude - 50 tips pratiques https://www.youtube.com/watch?v=mZzhfPle9QU Staff Engineer Meta partage 50 tips après 6 mois d'utilisation intensive de Claude Code Basé sur ~12h/jour d'usage perso et professionnel Couvre tout : bases, workflows avancés, parallélisation Objectif : partager ce qu'il aurait voulu savoir dès le départ Méthodologies Quelqu'un rale sur la non soutenabilité des bases de code écritent avec des agents https://mariozechner.at/posts/2026-03-25-thoughts-on-slowing-the-fuck-down/ Mario Zechner estime que les agents IA font les mêmes erreurs répétitivement sans apprendre, accumulant la complexité à grande vitesse faute de bottlenecks humains Sans vision globale, les agents créent du cargo-cult : les "best practices" de l'industrie appliquées localement sans cohérence architecturale La croissance de la base de code dégrade la capacité des agents à retrouver le code existant → duplication et incohérences croissantes Il cite des pannes AWS et des initiatives qualité Microsoft comme signes préoccupants liés au code généré par IA Solution : réserver les agents aux tâches délimitées et évaluables, garder l'architecture, les APIs et les systèmes critiques écrits à la main Maintenir une revue de code rigoureuse et traiter les humains comme les gardiens finaux de la qualité On m'oblige à utiliser l'IA https://n.survol.fr/n/on-moblige-a-utiliser-lia Éric D. défend l'adoption obligatoire de l'IA comme décision stratégique légitime, comparable au choix du full remote ou de la stack technique Il distingue la décision stratégique (adoption IA) de la méthode d'accompagnement (qui reste collaborative et bienveillante) La compétence IA devient un critère de recrutement : chercher des candidats déjà curieux et explorateurs de ces outils L'alignement culturel sur les pratiques et outils est un prérequis à la cohésion d'équipe Le refus d'adopter certains outils stratégiques peut justifier de ne pas recruter un candidat autrement compétent Encore une metodo SPDD https://martinfowler.com/articles/structured-prompt-driven/ Problème : l'IA accélère le dev individuel mais amplifie ambiguïtés et incohérences à l'échelle d'une équipe. martinfowler SPDD : traiter les prompts comme des artefacts versionnés, révisables et réutilisables plutôt que des échanges jetables. martinfowler Canvas REASONS : 7 dimensions (Requirements, Entities, Approach, Structure, Operations, Norms, Safeguards) pour guider le LLM de l'intention à l'exécution. martinfowler Workflow en 6 étapes : exigences → analyse → contexte → prompt structuré → code → tests unitaires, chaque étape s'appuyant sur la précédente. martinfowler 3 compétences clés : abstraction d'abord, alignement de l'intention, revue itérative. martinfowler Limites : fort ROI sur du code métier complexe, peu adapté aux hotfixes urgents, scripts jetables ou travail créatif/visuel. m Sécurité Le projet Glasswing pour sécuriser les logiciels https://www.anthropic.com/glasswing Anthropic lance Glasswing, une initiative de cybersécurité utilisant Claude Mythos Preview pour identifier des vulnérabilités zero-day 12 partenaires fondateurs dont AWS, Apple, Cisco, CrowdStrike, Google, JPMorganChase, Linux Foundation, Microsoft et NVIDIA Anthropic investit 100 millions de dollars en crédits de modèle et 4 millions en dons aux organisations de sécurité open source Le modèle opère avec une autonomie substantielle, identifiant des milliers de vulnérabilités dans les OS, navigateurs et infrastructures critiques Plus de 40 organisations supplémentaires ont accès pour scanner et sécuriser leurs systèmes Objectif : donner l'avantage aux défenseurs avant que les techniques de hacking assistées par IA ne se généralisent chez les attaquants LinkedIn vous espionne https://frenchbreaches.com/blog/linkedin-est-accuse-de-fouiller-dans-votre-ordinateur-illegalement Scandale "BrowserGate" : LinkedIn injecte du JavaScript qui tente de détecter les extensions Chrome installées sur votre navigateur Le script analysé contient une liste codée en dur de 6 222 extensions Chrome avec identifiants et chemins de fichiers internes Croissance alarmante de la liste ciblée : 38 extensions en 2017 → 461 en 2024 → ~1 000 en mai 2025 → 6 222 début 2026 Les données collectées incluent aussi CPU, RAM, résolution d'écran, timezone et état batterie pour du fingerprinting Certaines extensions ciblées sont liées à la neurodivergence, aux pratiques religieuses ou aux opinions politiques → violation grave du RGPD LinkedIn défend que le scan vise uniquement à détecter les extensions qui pratiquent le scraping de données Post mortem de la supply chain attack sur la librairie NPM axios https://github.com/axios/axios/issues/10636 Le 31 mars 2026, deux versions malveillantes d'axios (1.14.1 et 0.30.4) ont été publiées via un compte mainteneur compromis Vecteur d'attaque : RAT installé via ingénierie sociale ciblée sur la machine personnelle du mainteneur principal La 2FA ne protège pas si la machine de l'utilisateur est compromise : l'attaquant contrôle tout et peut agir comme l'utilisateur Les packages malveillants injectaient plain-crypto-js@4.2.1, un cheval de Troie multi-plateforme (macOS, Windows, Linux) Détection communautaire en ~3 heures, suppression par npm, mesures correctives : rotation complète des credentials Changements préventifs : publication via OIDC, releases immuables, amélioration des pratiques GitHub Actions Passbolt un gestionnaire de mots de passe open source https://lesjoiesducode.fr/passbolt-gestionnaire-de-mots-de-passe-gratuit-open-source-que-votre-equipe-merite-vraiment Gestionnaire de mots de passe open source conçu pour le partage d'identifiants en équipe, utilisé par plus de 50 000 organisations Chiffrement individuel par utilisateur et par version de credential, pas de coffre-fort partagé — architecture zero-knowledge "Forward secrecy" : quand un membre quitte l'équipe, ses copies chiffrées sont automatiquement révoquées sans reset manuel Supporte TOTP, clés SSH, tokens API et champs personnalisés avec piste d'audit complète de tous les accès Édition communautaire entièrement gratuite avec utilisateurs illimités, auto-hébergeable ou cloud Chiffrement OpenPGP nécessitant passphrase + clé privée, avec tokens visuels anti-phishing Loi, société et organisation Anthropic fait un don d'1,5 millions de dollars à la fondation Apache https://news.apache.org/foundation/entry/the-apache-software-foundation-announces-1-5m-donation-from-anthropic Anthropic donne 1,5 million de dollars à l'ASF pour soutenir l'infrastructure, la sécurité et la communauté open source Vitaly Gudanets (CISO d'Anthropic) : "Soutenir l'ASF est un investissement direct dans la résilience et l'intégrité des systèmes dont dépend l'IA moderne" Les fonds financeront les systèmes de build, les processus de sécurité et les services aux projets Apache Ce don est le déclencheur de l'initiative IA responsable à 10 millions de dollars de l'ASF L'infrastructure Apache est invisible mais critique : des systèmes financiers aux plateformes de santé, elle sous-tend l'écosystème logiciel mondial L'ASF lance l'initiative IA responsable https://news.apache.org/foundation/entry/the-apache-software-foundation-launches-10m-responsible-ai-initiative-with-initial-1-75m-donation L'ASF lance une initiative pour une IA responsable dotée d'un budget de 10 millions de dollars sur 3 ans minimum Anthropic est le premier donateur avec 1,5 million de dollars ; Alpha-Omega contribue 250 000 dollars L'initiative fournit aux projets Apache un accès à des modèles IA pour l'expérimentation et la sécurité Elle soutient l'ensemble de la chaîne IA/ML : pipelines de données, infrastructure, frameworks de deep learning Des tracks de conférences, hackathons et bourses de voyage sont prévus pour élargir la communauté Les principes directeurs incluent la supervision humaine, l'intégrité des licences et la sécurité open source Oracle vire 30000 personnes https://rollingout.com/2026/03/31/oracle-slashes-30000-jobs-with-a-cold-6/ Oracle licencie 20 000 à 30 000 employés, 18% de ses effectifs mondiaux. Les salariés ont appris leur licenciement par un simple email à 6h du matin, sans aucun préavis. L'accès à tous les systèmes (Slack, Zoom, badges) a été coupé immédiatement après. But : libérer 8 à 10 milliards de dollars pour construire des centres de données IA. Oracle a déjà contracté 50 milliards de dettes en 2026 pour financer ses projets IA. Paradoxe : l'entreprise affiche un bénéfice record de 6,13 milliards, mais ses liquidités sont dans le rouge. L'action Oracle a perdu plus de la moitié de sa valeur depuis septembre 2025. Et si l'IA n'était qu'un prétexte pour licencier https://eventuallycoding.com/p/ia-licenciements-et-si-l-intelligence-artificielle-n-etait-qu-une-excuse Hugo Lassiège (eventuallycoding) estime que les entreprises utilisent l'IA comme narratif commode pour masquer des erreurs de gestion passées (Block a triplé ses effectifs post-COVID sans croissance des revenus correspondante) Moins de 1% des licenciements technologiques seraient réellement dus à des gains de productivité IA selon les analyses citées Mesurer la productivité des développeurs reste un problème non résolu, mais les entreprises affirment des gains d'efficacité sans preuves Des pressions économiques réelles (inflation, guerres commerciales, coûts énergétiques) sont masquées derrière le discours IA Les restructurations nécessaires sont présentées comme des transformations AI-driven positives pour rassurer les investisseurs Il y voit une fenêtre d'opportunité pour l'Europe pendant que les géants américains se restructurent GitHub Copilot va utiliser les interacitons pour entrainer ses modèles sauf si vous vous délistez https://github.blog/news-insights/company-news/updates-to-github-copilot-interaction-data-usage-policy/ À partir du 24 avril 2026, GitHub utilise par défaut les interactions des utilisateurs Copilot Free, Pro et Pro+ pour entraîner ses modèles Les données collectées incluent le code accepté ou modifié, les snippets envoyés, les noms de fichiers et structures de dépôts, et les retours utilisateurs Les utilisateurs Copilot Business, Enterprise et les dépôts d'entreprise sont exclus de cette collecte de données d'entraînement Opt-out disponible dans les paramètres GitHub > "Privacy" ; les préférences de désactivation préalables sont conservées automatiquement Objectif déclaré : améliorer la précision des modèles sur les langages et cas d'usage du monde réel Grosse percée de Claude Code dans les commits sur GitHub https://aifoc.us/damn-claude-thats-a-lot-of-commits/ Explosion de Claude Code : En six mois, Claude Code est passé de 0,7 % à 4,5 % de tous les commits publics sur GitHub, surpassant tous les autres outils d'IA combinés. Adoption massive des agents IA : Environ 5 % des commits publics sur GitHub sont désormais générés par des agents IA, un chiffre en croissance rapide depuis fin 2025. Domination des bots sur GitHub : Au-delà des commits, les outils d'IA sont omniprésents dans la gestion des pull requests et des problèmes (Copilot et CodeRabbit notamment). Limites méthodologiques : Les données ne concernent que les dépôts publics (les entreprises utilisent massivement des dépôts privés, invisibles ici). Le comptage dépend fortement de la visibilité des signatures (certains outils comme Claude marquent systématiquement leurs commits, d'autres non) L'API de recherche GitHub présente une fiabilité variable à cette échelle. Changement de paradigme : Le développement logiciel vit une transition majeure, comparable au passage du desktop au mobile. L'intégration des agents IA dans le cycle de production n'est plus une expérimentation, mais une réalité opérationnelle à grande échelle. Dysmaths une application pour aider à apprendre les mathématiques et la géométrie lorsque l'on souffre de dyspraxie, dysgraphie https://dysmaths.com/ Application web pour aider les élèves de collège et lycée souffrant de dysgraphie et dyspraxie à faire des maths et de la géométrie Outils de dessin à main levée, géométrie précise (compas, rapporteur, règle) et opérations structurées (fractions, racines, puissances, symboles mathématiques) Export PDF et PNG avec conservation fidèle de l'échelle pour l'impression et la soumission des exercices Options d'accessibilité : police OpenDyslexic, personnalisations d'interface, import d'images et de PDFs Répond à un besoin réel : les outils standards ne sont pas adaptés aux difficultés de coordination et d'organisation spatiale en mathématiques IA ou réalité ? Par Amistory https://www.youtube.com/watch?v=PPYdAhBBF2I L'IA génère des contenus (images, voix, vidéos) de plus en plus indétectables Les arnaques au clonage de voix et deepfakes sont en forte hausse Les faux contenus viraux manipulent l'opinion à grande échelle Le faux n'est plus un accident, c'est devenu un système organisé La société entre dans une ère de doute généralisé sur le réel Comment s'informer quand le réel lui-même peut être simulé ? Conférences La liste des conférences provenant de Developers Conferences Agenda/List par Aurélie Vache et contributeurs : 6-7 mai 2026 : Devoxx UK 2026 - London (UK) 12 mai 2026 : Lead Innovation Day - Leadership Edition - Paris (France) 12-13 mai 2026 : Lyon Craft - Lyon (France) 19 mai 2026 : La Product Conf Paris 2026 - Paris (France) 19-20 mai 2026 : Green Code Challenge - Paris (France) 21-22 mai 2026 : Flupa UX Days 2026 - Paris (France) 22 mai 2026 : AFUP Day 2026 Lille - Lille (France) 22 mai 2026 : AFUP Day 2026 Paris - Paris (France) 22 mai 2026 : AFUP Day 2026 Bordeaux - Bordeaux (France) 22 mai 2026 : AFUP Day 2026 Lyon - Lyon (France) 27 mai 2026 : aMP Day Strasbourg 2026 - Strasbourg (France) 28 mai 2026 : DevCon 27 : I.A. & Vibe Coding - Paris (France) 28 mai 2026 : Cloud Toulouse 2026 - Toulouse (France) 29 mai 2026 : NG Baguette Conf 2026 - Paris (France) 29 mai 2026 : Agile Tour Strasbourg 2026 - Strasbourg (France) 2-3 juin 2026 : Agile Tour Rennes 2026 - Rennes (France) 2-3 juin 2026 : OW2Con - Paris-Châtillon (France) 3 juin 2026 : IA–NA - La Rochelle (France) 4 juin 2026 : Workplace Intelligence Days - 1ère édition - Lyon (France) 5 juin 2026 : TechReady - Nantes (France) 5 juin 2026 : Fork it! - Rouen - Rouen (France) 6 juin 2026 : Polycloud - Montpellier (France) 9 juin 2026 : JFTL - Montrouge (France) 9 juin 2026 : C: - Caen (France) 9 juin 2026 : France API 2026 - Paris (France) 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) 25-26 juin 2026 : Agile Tour Toulouse 2026 - Toulouse (France) 27 juin 2026 : Asynconf - Paris (France) 2 juillet 2026 : Azur Tech Summer 2026 - Valbonne (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 : 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) 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) 12 octobre 2026 : Dev With AI - Paris (France) 27-29 octobre 2026 : Directions EMEA 2026 - Paris (France) 29-30 octobre 2026 : BDX I/O 2026 - Bordeaux (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) 27 novembre 2026 : DevFest Paris 2026 - Paris (France) 1-3 décembre 2026 : Apidays Paris - 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) 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/

Friday Deployments. Alle reden darüber, viele haben eine starke Meinung dazu und erstaunlich viele Teams haben vor allem eins: Angst. Nicht nur vor Technik, sondern vor kaputten Prozessen, endlosen Freigaben, Rufbereitschaft am Wochenende und der berühmten Frage, wer schuld ist, wenn Production brennt. Aber ist das Problem wirklich der Freitag oder zeigt der Freitag nur schonungslos, wie gut oder wie fragil unsere Software Delivery wirklich ist?In dieser Episode sprechen wir mit Sujeevan, ehemaliger Solutions Architect bei GitLab und Grafana, Podcaster beim Tilpod, DevOps-Autor und Gründer der Friday Deployments GmbH. Gemeinsam schauen wir auf den Mythos Friday Deployment und zerlegen ihn in seine Einzelteile: CI/CD, Staging, Monitoring, Feature Flags, Blue Green und Canary Deployments, Delivery versus Deployment, Blameless Post Mortems, On Call, DevOps-Kultur, Compliance, Banken, Mittelstand und die Frage, warum viele Teams technisch mehr könnten, es kulturell aber trotzdem nicht tun.Dabei wird schnell klar: Wer freitags nicht deployen kann, hat oft kein Freitagsproblem, sondern ein Delivery-Problem, ein Kulturproblem oder ein Vertrauensproblem. Wenn du wissen willst, wie Teams deploybarer, stressfreier und am Ende auch produktiver werden, ist diese Folge für dich.Bonus: Eine Waschmaschine erklärt den Unterschied zwischen Continuous Delivery und Continuous Deployment erstaunlich gut.Unsere aktuellen Werbepartner findest du auf https://engineeringkiosk.dev/partnersDas schnelle Feedback zur Episode:

Keep the Raccoons Out: Service Mesh, MCP, and Securing Agentic Workloads With William Morgan, CEO of Buoyant and creator of Linkerd Linkerd just turned 10, so we brought on the person who built it and coined the term “service mesh” in the first place. William Morgan joins Jonathan and Justin to talk about where service mesh came from, where it’s going, and the very specific kind of chaos that agentic AI is about to unleash on anyone who owns a Kubernetes cluster. The short version: lock your doors, because the raccoons are coming. “Our job is basically to make Linkerd as boring as possible.” William traces Linkerd’s origins back to Twitter’s infrastructure work between 2010 and 2014, when a Ruby on Rails monolith turned into a sprawling distributed system — the same problems we have today, just a different decade. As the fifth project ever to join the CNCF, Linkerd has had a front-row seat to the ecosystem’s evolution, and William explains why his actual goal these days is to make it as boring as humanly possible: the kind of dependable infrastructure layer you can trust to still be around in another 90 years. That’s also why he’s not adding AI to Linkerd — an infrastructure layer has to be fast, lightweight, and predictable, and generative AI is the opposite of all three. “At some point your agentic workload is going to figure out how to delete the production database. And it’s going to try it.” The heart of the conversation is what the AI wave means for the platform teams who own the clusters. Developers just got an army of AI assistants, and that has real consequences for CI/CD, code quality, and blast radius. William digs into the boundary problem — agentic workloads are untrusted but need access to your most important systems — and why zero trust has suddenly stopped being optional now that the code hitting your database no longer clears peer review and a security committee. Along the way they get into cache-aware routing that can take a 13-second inference call down to one, the still-unsolved mess of agentic identity, and why we keep anthropomorphizing these tools and letting our guard down. “If you don’t use Linkerd, your data system will be overrun by raccoons.” Finally, they turn to MCP — building a catalog of MCP servers, detecting tool calls, and adding DLP-style protection in front of the services an agent never sees. But William’s real point is that MCP is something of a red herring for a much older problem: uncontrolled access to your APIs. Whatever protocol you use, once an unconstrained workload is loose in your environment, you need an immune system to keep it in check. Links and resources: Linkerd:

A recent attack shone a light on some of the problems with GitHub Actions, and CI/CD more generally. As tempting as it might be, going back to shell scripts probably isn’t the answer. 1K+ cloud environments infected following Trivy supply chain attack 2.5 Admins 292: Trivyally Infected Support us on patreon and get an ad-free RSS feed with early episodes sometimes Subscribe to the RSS feed.

A recent attack shone a light on some of the problems with GitHub Actions, and CI/CD more generally. As tempting as it might be, going back to shell scripts probably isn’t the answer. 1K+ cloud environments infected following Trivy supply chain attack 2.5 Admins 292: Trivyally Infected Support us on patreon and get an ad-free RSS feed with early episodes sometimes Subscribe to the RSS feed.

Send us Fan MailKen and Mike are back in the AI trenches, this time unpacking the hype, fear, and practical security implications surrounding Anthropic's Mythos preview. As the industry reacts to claims around AI-driven vulnerability discovery and exploit generation, the hosts ask a more important question: are we actually ready to fix what we already know is broken?The conversation cuts through the zero-day panic and focuses on the fundamentals that still matter: patching, hardening, reducing attack surface, validating AI-generated code, and keeping deterministic security checks in place. From supply chain attacks and GitHub Actions misconfigurations to agentic development workflows and the future of CI/CD, Ken and Mike explore where AI may genuinely change the threat landscape and where security teams are still fighting the same old battles.If your organization is rushing to build faster with AI, this episode is a reminder to also use it to build better.

From building Applied Intuition from YC-era autonomy tooling into a $15B physical AI company, Qasar Younis and Peter Ludwig have spent the last decade living through the full arc of autonomy: from simulation and data infrastructure for robotaxi companies, to operating systems for safety-critical machines, to deploying AI onto cars, trucks, mining equipment, construction vehicles, agriculture, defense systems, and driverless L4 trucks running in Japan today. They join us to explain why “physical AI” is not just LLMs on wheels, why the real bottleneck is no longer model intelligence but deployment onto constrained hardware, and why the future of autonomy may look less like one-off demos and more like Android for every moving machine.We discuss:* Applied Intuition's mission: building physical AI for a safer, more prosperous world, powering cars, trucks, construction and mining equipment, agriculture, defense, and other moving machines* Why physical AI is different from screen-based AI: learned systems can make mistakes in chat or coding, but safety-critical machines like driverless trucks, autonomous vehicles, and robots need much higher reliability* The evolution from autonomy tooling to a broad physical AI platform: starting with simulation and data infrastructure for robotaxi companies, then expanding into 30+ products across simulation, operating systems, autonomy, and AI models* Why tooling companies came back into fashion: Qasar on why developer tooling looked unfashionable in 2016, why Applied Intuition still bet on it, and how the AI boom made workflows and tools central again* The three core buckets of Applied Intuition's technology: simulation and RL infrastructure, true operating systems for vehicles and machines, and fundamental AI models for autonomy and world understanding* Why vehicles need a real AI operating system: real-time control, sensor streaming, latency, memory management, fail-safes, reliable updates, and why “bricking a car” is much worse than bricking an iPad* Physical machines as “phones before Android and iOS”: Peter explains why today's vehicle and machine software stack is fragmented across many operating systems, and why Applied Intuition wants to consolidate the platform layer* Coding agents inside Applied Intuition: Cursor, Claude Code, internal adoption leaderboards, and how AI tools are changing engineering workflows even in embedded systems and safety-critical software* Verification and validation for physical AI: why evals get harder as models improve, how end-to-end autonomy changes simulation requirements, and why neural simulation has to be fast and cheap enough to make RL practical* From deterministic tests to statistical safety: why autonomy validation is shifting from binary pass/fail requirements toward “how many nines” of reliability and mean time between failures* Cruise, Waymo, and public trust: Qasar and Peter discuss why autonomy failures are not just technical issues, how companies interact with regulators, and why Waymo is setting a high bar for the industry* Simulation vs. reality: why no simulator perfectly represents the real world, how sim-to-real validation works, and why real-world testing will never disappear* World models for physical AI: hydroplaning, construction equipment, visual cues, cause-and-effect learning, and where world models help versus where they are not enough* Onboard vs. offboard AI: why data-center models can be huge and slow, but onboard vehicle models need millisecond-level latency, low power, small size, and distillation-like efficiency* Why physical AI is not constrained by model intelligence alone: the hard part is deploying models onto real hardware, under safety, latency, power, cost, and reliability constraints* Legacy autonomy vs. intelligent autonomy: RTK GPS in mining and agriculture, why hand-coded path-following worked for decades, and why modern systems need perception and dynamic intelligence* Planning for physical systems: how “plan mode” applies to robotaxis, mining, defense, and multi-step physical tasks where actions change the state of the world* Why robotics demos are not production: the brittle last 1%, humanoid reliability, DARPA Grand Challenge-style prize policy, and the advanced engineering gap between research and deployment* Applied Intuition's hard-earned lessons: after nearly a decade, Peter says they can look at a robotics demo and predict the next 20 problems the company will hit* Qasar's advice to founders: constrain the commercial problem, avoid copying mature-company strategies too early, and remember that compounding technology only matters if you survive long enough to see it compound* Why 2014 YC advice may not apply in 2026: capital markets, AI company dynamics, and the difference between building in stealth with a deep network versus building as a new founder today* What Applied is hiring for: operating systems, autonomy, dev tooling, model performance, evals, safety-critical systems, hardware/software boundaries, and engineers with deep curiosity about how things workApplied Intuition:* YouTube: https://www.youtube.com/@AppliedIntuitionInc* X: https://x.com/AppliedInt* LinkedIn: https://www.linkedin.com/company/applied-intuition-incQasar Younis:* X: https://x.com/qasar* LinkedIn: https://www.linkedin.com/in/qasar/Peter Ludwig:* LinkedIn: https://www.linkedin.com/in/peterwludwig/Timestamps00:00:00 Introduction: Applied Intuition, Physical AI, and 10 Years of Building00:01:37 Physical AI vs. Screen AI: Why Safety-Critical Changes Everything00:02:51 The Origin Story: Tooling, YC, and the Scale AI Comparison00:05:41 The Three Buckets: Simulation, Operating Systems, and Autonomy Models00:11:10 Hardware, Sensors, and the LiDAR Question00:14:26 The Operating System Layer: Why Vehicles Are Like Pre-Android Phones00:19:13 Customers, Licensing, and the Better-Together Stack00:21:19 AI Coding Adoption: Cursor, Claude Code, and the Bimodal Engineer00:26:41 Verifiable Rewards, Evals, and Neural Simulation00:31:04 Statistical Validation, Regulators, and the Cruise Lesson00:40:25 World Models, Hydroplaning, and Cause-Effect Learning00:43:34 Onboard vs. Offboard: Latency, Embedded ML, and Distillation00:50:57 Plan Mode for Physical Systems and Next-Token Prediction Universally00:53:04 Productionization: The 20 Problems Every Robotics Demo Will Hit00:58:00 Founder Advice: Constraints, Compounding Tech, and Mature-Company Mimicry01:05:41 Hiring Philosophy: Hardware/Software Boundary and Engineering Mindset01:08:50 General Motors Institute, Education, and the Curiosity MindsetTranscriptIntroduction: Applied Intuition, Physical AI, and 10 Years of BuildingAlessio [00:00:00]: Hey everyone, welcome to the Latent Space Podcast. This is Alessio, founder of Kernel Labs, and I'm joined by Swyx, editor of Latent Space.Swyx [00:00:10]: And today we're very honored to have the founders of Applied Intuition, Qasar and Peter. Welcome.Qasar [00:00:17]: You guys really know how to turn it on to podcast mode. That was, you guys are real pros at this.Qasar [00:00:23]: They were just joking around right before this, and then they flipped it pretty quick.Alessio [00:00:29]: Oh, yeah, it's good to have you guys. Maybe you just wanna introduce yourself so people know the voice on the mic and they'll know what they're hearing.Peter [00:00:33]: Oh, sure. Yeah, I'm Peter Ludwig. I'm the co-founder and CTO of Applied Intuition.Qasar [00:00:38]: And my name is Qasar Younis. I am the CEO and co-founder with Peter.Alessio [00:00:42]: Nice. Can you guys give the high-level overview of what Applied Intuition is? And I was reading through some of the Congress files, when you went out there, Peter, and eighteen of the top twenty global non-Chinese automakers, you two guys, you have customers in agriculture, defense, construction. I think most people have heard of Applied Intuition tied to YC when it was first started, and then you were kinda in stealth for a long time, so maybe just give people the high-level overview of what it is today, and then we'll dive into the different pieces.Peter [00:01:10]: Yeah. So at Applied Intuition, our mission is to build physical AI for a safer, more prosperous world. And so we work on physical AI for all different types of moving systems, everything from cars to trucks to construction and mining equipment, to defense technologies. And we're a true technology company, so we build and sell the technology, and we sell it to the companies that make the machines. We sell it to the government, really anyone that wants to buy a technology to make machines smart.Physical AI vs. Screen AI: Why Safety-Critical Changes EverythingQasar [00:01:38]: Yeah. And I think in the broader AI landscape, a lot of the focus, rightfully so in the last, three years has been on large language models, and so everything fits in a screen. Like, whether it's code complete products or things like that. And what's different about us is we're deploying intelligence onto a lot of things that don't have screens. they're physical machines. There are sometimes screens within the cabin or for example of a car or a truck or something like that, but most of the value we provide is putting intelligence that is in safety critical environments. So that those two words are really important because learn systems can make mistakes if you're asking for, like, some, so something like, “Tell me about these podcast hostsQasar [00:02:28]: that I'm about to go meet.” But you can't do that obviously when you run, like, as an example, we run driverless trucks in Japan right now, as we speak. We can't have errors. Those are L4 trucks. Yeah.Alessio [00:02:40]: Yeah. Was that always the mission? I remember initially, I think people put you and Scale AI very similarly for some things about being kinda like on the data infrastructure side of things. What was the evolution of the company?The Origin Story: Tooling, YC, and the Scale AI ComparisonPeter [00:02:51]: Well, from the very beginning, we always wanted to, really be a technology company that helped generally push forward the industrial sector. And so we started off working in autonomy. Our very first customers were robotaxi companies. And we started off doing a lot of work in simulation and data infrastructure. And then over the years, we've expanded our portfolios. Now we have, over thirty products, and it's a pretty broad technology play within the landscape of physical AI.Qasar [00:03:19]: Yeah, I think the Scale reason is because we're all YC Universe companies. But it was a very different company. Scale, was, is more of a services company, data labeling company fundamentally. We started and still are, do a lot of tooling. So like, you think developer tooling is now in vogue again, thanks to the AI boom. But honestly, ten years ago, it was out of vogue. It w Like, doing a tooling company in 2016, 2017 was not, like, the thing to do because, I don't know if you remember, the VCs generally, their views was that toolings are They're just workflows, and workflows ultimately are not really interesting. And we've gone and come, full circle with that. But when we started the company, our kind of it's kinda like in the periphery of what the company wants to be. It was like, from our earliest days, like, we wanna deploy software on physical machines, like on cars and on trucks and things like that. And obviously, we didn't know that the transformer boom was gonna happen. We didn't know that autonomy systems would become end-to-end. Those things we didn't know. And why that's important when autonomy systems become end-to-end, it is just now those models can be generalized to, multiple form factors. And so back nine, ten years ago, tooling was a great way, and still is a great way to, build the technology and sell technology to our end customers, a lot of them who wanna build this stuff themselves. And so we just offer like a spectrum of solutions from you can just use like one part of a development suite of tools all the way to buying the full thing. The way to think about the company, or at least the way we think about the company is, as Peter said, a technology provider. It's kinda like, what NVIDIA does or what an AMD, but we just don't do chips.Qasar [00:05:06]: We don't do silicon. But we're a technology provider fundamentally. And I think even, we used to joke when we started the company, like, we're not the guys to build, like, Instagram. Like that was just towards That's not our That's just not us in a most fundamental way. IAlessio [00:05:20]: You have thoughts.Qasar [00:05:21]: Yes.Qasar [00:05:22]: Well, it's, it's I mean, I think it's just like what And I mean, we worked on Maps and stuff, Google Maps. Consumer products are extremely difficult for a lot of different reasons. It just, I think doesn't scratch the itch. I think we're like Michigan guys who are kind of more of that traditional engineering kind of a realm, or lineage. we used to jokeThe Three Buckets: Simulation, Operating Systems, and Autonomy ModelsPeter [00:05:41]: I gotta say, though, what was clear ten years ago was that there was so much more that was possible with software and AI in vehiclesPeter [00:05:47]: and that was generally the space that we started in ten years ago.Peter [00:05:51]: And the precise path that we've taken over the years, I think we've been strategic, and we've adjusted to make sure that we're actually building stuff that's valuable to the market. And like, the technology has changed so much. Like our own technology stack has completely changed, I would say, roughly every two years. And so now we've probably done, let's say, four complete evolutions of our own technology stack. And I sort of see that cadence roughly keeping up.Peter [00:06:13]: And so the way even we think about engineering is almost on this two-year horizon, we're preparing ourselves that, hey, like, we wanna invest the appropriate amount, but then also be very dynamic as the research gets published and as our research team figures out new advancements and adapting to that.Qasar [00:06:27]: Yeah. One thing that has been consistent is the type of people we've, we've recruited. It's engineers who are fall into the sometimes very traditional, like, GoogleQasar [00:06:38]: -gen suite, but way different from, other companies. We are hiring folks who really know the intersection of hardware and software, who know really low-level systems. Obviously, traditional ML researchers and folks who've, actually, put ML systems into production. That's been pretty consistent. I think that, like, you look at the mix of our engineering, eighty-three percent of the company is engineering, so it's, like, a giant list.Qasar [00:07:05]: A lot of engineers.Alessio [00:07:06]: Which, by the way, a thousand engineersQasar [00:07:07]: Yeah. A thousand engineers.Alessio [00:07:08]: that's on your website, so I imagine it's up to date.Qasar [00:07:11]: It is, it is up to date, yes. Yes.Alessio [00:07:12]: okay. And then forty-plus founders.Qasar [00:07:15]: Yeah. We would tend to also, This was more luck than strategy. But we've recruited a lot of ex-founders. It's been a great place for founders, YC and non, ‘cause obviously I know a lot of the YC folks. It's kind of like we recruit a lot of Google people.Qasar [00:07:33]: For them to exercise both their technical and non-technical skills because, we're, we're, we're on the applied side. We have a research team that we do fundamental research, we publish, and we've, we've had great traction there. But fundamentally, the business wants to take this intelligence and deploy it into production and there's, like, a certain type of person that's more interested in that.Alessio [00:07:54]: Yeah. You mentioned the tech stack, Peter, so I just wanted to give you some rein to just go into it. I'm interested in where Wayve Nutrition, starts and ends in some sense, what won't you do? What, do you do that's common among all the verticals that you cover?Peter [00:08:10]: There's a few buckets of work that we do, and we've been at this for almost ten years now, so the technology's pretty broad. But we got startedQasar [00:08:17]: Yeah, with a thousand engineers, like, you could work on lots of things.Peter [00:08:19]: There's lots of stuff, yeah, espe-especially with AI tools to help.Peter [00:08:22]: So we got our start in simulation and simulation tooling and infrastructure. And so generally, if you're trying to build a very complex software system that involves moving machines, you need to test that, and the best way to test it is it's a combination of virtual developments, a simulation, and then also obviously real world testing.Peter [00:08:39]: And then there's a very careful process of that correlation between the simulation results and the real world results and ensuring that the simulator is in fact accurate to that. Simulation's a very deep topic.Peter [00:08:49]: We have a whole suite of products in that, and we could talk for many hours about that specifically. But that is one part of what we do as a company. Reinforcement learning as a subpart of that is also super critical. I think a lot of the a lot of the best advancements happening in a lot of these AI systems right now in some way relate to reinforcement learning, and with now we have lots of compute, and you can do tons of interesting things for reinforcement learning. The second bucket of work that we do is on operating systems technology. true operating systems. Like, think about, schedulers and memory management and middleware and message passing and highly reliable networking and data links. Like, the reality is, if you want to deploy AI onto vehicles, you need a really good operating system. And when we were getting deeper into that space, there wasn't really anything that we were happy with.Peter [00:09:39]: Like, things existed, absolutely, and we were using what was available in the market, and as an engineering organization, we roughly realized these things aren't great. We think we can do this better, and so let's, let's build something. And that was then the that was the moment of inspiration that started our operating systems business, which is now a very real business for us. And in order to write and run great AI, you need a great operating system, and so that-that's what got us into that. And then the third bucket that we work on, it's, it's true fundamental AI technology. Models, we do a lot of work in, as mentioned, the foundational research, but then the also the world models and the actual autonomy models that are running on these physical machines, and that's across cars, trucks, mining, construction, agriculture, and defense, and so that's both land, air, and sea.Qasar [00:10:31]: And also, a smaller subsector of that third bucket is the interaction of humans with those machines.Qasar [00:10:38]: So that's a multimodal, experience. Historically, if you're moving a dirt mover or any of these machines, there are, like, buttons you press, whether they're actual physical tactile buttons or something like a touch screen. That's just That fundamentally is changing to where you're just talking to the machine and the machine and you're teaming with the machine.Alessio [00:10:58]: Voice?Qasar [00:10:59]: Yeah, voice, absolutely, yeah.Alessio [00:11:00]: Oh.Qasar [00:11:00]: And also the machine just being aware of who is in the cabin, what their state is. you can think from a safety systems perspective, the most simple version of this is, like, the driver is tired, right? They're, they're if you get those alerts when you're driving your car and saysHardware, Sensors, and the LiDAR QuestionQasar [00:11:15]: -maybe take a coffee break, that take that times, a couple of order of magnitudes up. But this concept of teaming man and machine is important. When you think about running agents or just running, different instances of, Claude and doing work for you in the background, you can take that analogy out, almost copy and paste and put it into, like, a farm, where you have a farmer who's running a number of machines. So where they interact with the machine is where there's maybe a critical decision or a disengagement or something like that, but generally speaking, the agent on the physical machine is running and making decisions on the behalf of the farmer until there's something maybe critical. And that's also what we work on. So that's not pure autonomy. It's a little bit of a mix, but it falls under, autonomy. In the automotive sense, that's typically defined in SAE levels as an L2++ systemQasar [00:12:05]: -with a human in the loop. But just take that idea, to other verticals.Alessio [00:12:09]: Yeah. You've not mentioned hardware at all, like sensors or obviously we you mentioned you don't do chips. I think even in AV there's, like, a big, cameras versus lidars. Like, what are, like, in your space maybe some of those design decisions that you made, and are they driven by the OEM's ability to put things on the machinery? And like, how much influence do you guys have on co-designing those?Peter [00:12:32]: Yeah. So we don't make sensors. Like, we're, we're not a manufacturer. Obviously, we use a lot of sensors in our autonomy products. in terms of what actually goes on the vehicles, we have a preferred set of sensors that we, let's say fully support, and then our customers, they can sort of choose from those. And obviously if there's a very strong opinion on supporting something else, we'll add that to the platform as well. And the lidar question is at this point sort of the age-old,Peter [00:12:59]: topic in autonomy, and the state of the industry right now is lidar is hands down a useful sensor, specifically for data collection and the R&D phase of autonomy development. if you see, for example, a Tesla R&D vehicle, it actually has lidar on itPeter [00:13:17]: to this day, right? In the Bay Area we see these. you'll see, like, Model Ys or Cybercab that have lidars on them just driving around. So it's, it's useful because it gives you per pixel depth information. So if you can pair a lidar with a camerand you can say that, well, this camera's looking this direction, this lidar's looking this direction, and now for each pixel of the camera I can see how far away is that pixel. you can actually then use that as a part of your model training, and then the that depth information then becomes a learned, a learned state of the camera data. And then when you're doing the production system, you can now remove the lidarPeter [00:13:52]: and now you can actually get depth with just the camera. And so that difference between, like, a highly sensored R&D vehicle and then the down-costed production vehicle, we use that across our whole portfolio of products. And of course the end goal is you want super low cost and super reliable.Peter [00:14:08]: And then in certain use cases you have some more, bespoke things. Like in defense as an example, you do things at night oftentimes, and so you care about sensors like infrared, more so than And you don't, you don't wanna be putting energy out, so you don't wanna use lidar or radar.Peter [00:14:23]: but you still need to be able to see at nighttime. So yeah, we work the whole gamut.The Operating System Layer: Why Vehicles Are Like Pre-Android PhonesAlessio [00:14:27]: Cool. So that's kinda like on the hardware level. Then on the OS level, how does that look like? What is, like, unique? my drive- I drive a Tesla. Whenever I drive some other car that has a screen, it always sucks.Alessio [00:14:38]: It's on, like, cheap Android tablet. It's like, it's laggy and all of that. What does the OS of, like, the autonomy future look like?Peter [00:14:46]: When most people, it's really what you just described. When you think about operating system in a vehicle, you're thinking about the HMI, right? The human machine interface, and absolutely that's a an important part of it, but that's actually only one thin layer on top. So when we talk about operating systems for, like, AI in vehicles, there's many layers that go deep into the CPU critical realm and embedded systems, and you're talking about the real time control ofPeter [00:15:13]: let's say the electric motors or the engine and the actuators, and you have different redundancies for different, let's say, the steering actuation in the vehicle. And all of these things, need very core support in the in the operating system. And then of course for autonomy you have real time sensor data that's streaming in, and the latencies there are really important, right? If you try to Imagine you try to run Microsoft WindowsPeter [00:15:35]: like streaming your sensor data in or controlling the vehicle. Like, the latencies are gonna be absurd. Like, you can never do that. And so what's special about what we do is we really have this system level thinking, right? So we're looking at, we care about every performance characteristics of the entire system, and then we also, because we're doing a lot of the software or all of that software, we can fine-tune and control all of those things. So we can very carefully tune in the latencies for every aspect of the system. We can carefully tune in the memory management. We can have the right, fail-safes and fallbacks, for different things. ‘Cause you have to account for what if, what if there is a critical failure? What if there's a cosmic ray that flipsPeter [00:16:14]: a bit in the middle of the processor that causes some, malfunction? And you have to have a fail-safe to all of that, and so the core operating system is a part of that. And then the one last thing, which is a lot less exciting but is, actually a very big topic, is reliability of updates.Peter [00:16:30]: so the I have a Tesla and you get updates fairly frequently, right?Peter [00:16:36]: Once a month. Most companies that are making vehiclesPeter [00:16:40]: are basically never doing updates, and they're And even if they are doing updates, they're usually only updating maybe one module. Maybe they're updating the HMI module. But they're not able to update, let's say, the CPU critical parts of the system.Peter [00:16:51]: You have to go into the dealer for that. And so with our operating system now we can actually enable highly reliable updates of any system in the vehicle, and that's way easier said than done. Like, there's lots of technical, technically deep stuff, in the tech stack to do that in a way that you're not going to accidentally brick a vehicle.Peter [00:17:08]: And right? If, imagine yourAlessio [00:17:10]: That would be bad.Alessio [00:17:11]: Bad.Peter [00:17:11]: Bricking a car is a very expensivePeter [00:17:13]: and honestly, like across the industry maybe one of the most just pure impactful things that we've done is we've just, we're, we're now enabling the industry to actually do software updates.Alessio [00:17:22]: Just to clarify as well, who is the customer for this? Like, I assume a lot of hardware manufacturers have their own firmware, and I'm sure some of them would just have you write it for them because you're experts. And others would have their own. Like, who pays for this? Who invites you into the house? Is it, is it the end user, or is it, is it the manufacturer?Peter [00:17:41]: Yeah. So let me make an analogy firstly on the on the fragmentation of software. So physical machines today are more akin to the state of the phone market before Android and iOS existed, right? So I worked on Android at Google by the way many years ago, and part of the reason that Larry at Google decided to get into Android was they wanted to run Google products on a bunch of phones, and they bought all of these phones from the industry, and it turned out they had like 50 different operating systems on these phones. And it was virtually impossiblePeter [00:18:17]: for Google to make their app run on all 50 devices equally well. And so the solution was, well, actually what if, what if they created-A really great operating system and made it attractive to all of these phone makers, and that was sort of the genesis for what Android was and why Android existed. It was a way for Google to get their products onto really wide diversity of devices. The state of the physical, industry right now, it's a little bit like that. Like, there's yes, these companies have firmware, but they have so many different operating systems, it's so fragmented, and to actually get a modern AI application to run on these vehicles, you actually, you first have to consolidate the operating system, and so that's, that's why we've done that. And then, your specific question was who are our customers? It's, it's, generally it's the companies that are making these machines.Peter [00:19:06]: And we're, we're, we're selling our technology to them to really simplify the architecture and then enable these AI applications to run on them.Customers, Licensing, and the Better-Together StackSwyx [00:19:13]: How much is reusable across? Like, do you have, like, one OS that is just configured for everything, or is there some more customization that is needed?Peter [00:19:22]: Yeah, highly reusable. So the fundamental technology is quite universal, right? So things that we do have to think about though are, like, chipset support. And so if you're, if you're coding, let's say, an LLM and you have start with an assumption that, “Hey, oh, I'm gonna, I'm gonna use CUDA, and I'm gonna run this, on an NVIDIA chip,” then you don't really have to think about the hardware in that sense. Like, you're just, “Okay, I'm just I'm in the CUDA/NVIDIA ecosystem, and I'm, I'm going to use that.” But the hardware, especially in safety critical systems, it's a lot more diverse. There's not one or one or two players. There's a bunch of different chipsets that we have to support. And so our operating system doesn't just run on, like, the equivalent of X86. It has to, it has to run on a number of different architectures from chips from a bunch of different companies. But again, we've been working on this for a long time now, so we have, we have support for all of those chipsets. And then when you want to then run the AI applications, we can then do that reliably across now a variety of providers.Qasar [00:20:19]: And I think that is, like, heavily inspired by Android, right? Android has a huge suite of testing and it's a reliable operating system that runs on thousands of devices. And we think we can, we can do the same in all these physical moving machines, with the difference that we're really in a safety critical realm. Android isn't.Alessio [00:20:40]: So on Android, I don't need to use Gmail, I can use Superhuman. Like, what about your machinery? Like, can people bring somebody else's automation to it, or is it kinda like all-in-one?Qasar [00:20:50]: You have to use us. No. Yeah. we're If, Yeah. Yeah, it's totally open. Yeah.Peter [00:20:56]: Yeah. our philosophy is that we are a technology company, and so we license our technology to customers to use how they want. And so if a customer wants to If they wanna license our autonomy tech and our operating system, then great, we'll license those. If they just wanna license the operating system and then use different autonomy tech, that's fine also, and we have great documentation andSwyx [00:21:17]: Or if they wanna use developer tooling.Peter [00:21:18]: Yeah, exactly.AI Coding Adoption: Cursor, Claude Code, and the Bimodal EngineerSwyx [00:21:19]: It's, like, a better together if, obviously, if you, if they work together. Is it all C++ I assume is with different compile targets?Peter [00:21:27]: We use a lot of C++.Peter [00:21:28]: Rust is sort of a hot, the new hot kid on the blockPeter [00:21:32]: for a bunch of things as well. But yeah, the lower level you get, especially when you get to real-time constraints, you hit C++ at some point, and at some point maybe you work your way into assembly when needed.Swyx [00:21:44]: Oh, damn.Alessio [00:21:46]: I'm curious about the coding agent adoption, just, like, since you're mentioning more esoteric languages. Like, what's the adoption internally? What have you learned?Peter [00:21:55]: Yeah. We use everything. So Cursor was, I think the hottest tool in the company for a good while. Now Claude Code, I think has taken the reign on that. We have a internal leader, leaderboard that we use just to sort of encourage adoptionPeter [00:22:09]: with-within the company. And yeah, it's, they're phenomenally useful. it's, Honestly, we take inspiration from some of those tools also in how we're adapting some of that mindset of thinking to the physical realm. Like if it's so easy to build an app for this or that thing that lives just on a screen, we can We're taking now a lot of the same ideas and applying that to, “Okay, well, if you wanted a physical machine to do something, how easy can we make that, using our own tooling and platform as well?”Alessio [00:22:40]: Are you changing any of, like, the OS architecture, kinda like the way you expose services to, like, be more AI friendly or?Peter [00:22:48]: Yeah, absolutely. The in the early days of our tools infrastructure work, it was a lot about, You had engineers that were experts in certain topics, but the things that you're dealing with, they're oftentimes more mathematical or more abstract, where actually GUI tools are very useful for certain things. Like as an example, we have a product we call Sensor Studio, which is, it helps you design the sensor suite for your autonomous vehicle, whether, again, it could be a car, it could be a drone, could be a mining equipment, could be a robot. And you place sensors in different places. You There's different, There's a library. You can understand what are the trade-offs that you're making in the design of that system, and that was, like, a very, a very GUI intensive, thing ‘cause it's a little more like a CAD tool in that senseSwyx [00:23:37]: YepPeter [00:23:37]: if you've seen CAD tools. Nowadays, though, right, we expose all of the underlying APIs for that and now using, AI agents, you can actually configure a sensor suite with just text and likely reach a better result than you could've through the GUI in the past, and we're taking that thinking now through the whole product portfolio.Swyx [00:23:57]: Another thing I was thinking about is just in terms of, like, AI, adoption, does it change your hiring at least a little bit, or how do you, how do you sort of manage engineers, differently?Peter [00:24:08]: Yeah. absolutely, it does. we, I think like every company in the Valley right now, are evolving our hiring practicesPeter [00:24:16]: because the skills required to be effective are changing so fast, right? you used to really select for just rote implementation ability and now it is more the AI engineer skill set, right? Where it's like, yeah, how to implement, but actually-Just banging out code is no longer the core job, right? It's, it's actually knowing what questions to ask, knowing how to tie, how to tie together these different AI tools. And so the interviews that we give now I think are way harder than they've ever been.Peter [00:24:46]: But we also allow, right, selective use of AI tools to solve the problems. And I think in that you start to see more of a bimodal distribution of engineers, right? You start to see like wow, there's, there's this subset of people that they really get it. Like they're, they're all in and they've, they've clearly invested the hours needed to learn these tools and how to be effective.Peter [00:25:09]: And then there's sort of the group of people that haven't done that, and that the productivity gap is just enormous. And so we're, we're trying to obviously select for the people that are really into this.Qasar [00:25:20]: I first wrote the my AI engineer piece three years ago, and when I first wrote about it, I was like, “Actually, not everyone should be an AI engineer,” ‘cause I think there's a there's an extremist stance where well, every software is an engineer is an AI engineer. And my actual example of people who should not be adopting AI was embedded systems and operating systems, and database people. Are they adopting AI?Peter [00:25:41]: I think it's the classic bitter lesson, topic, which is the Six months ago I would've said the same thing, but it's, it's becoming super useful for every domain.Qasar [00:25:53]: I'm sure.Peter [00:25:54]: Right? Like,Peter [00:25:56]: there was, I think six months ago, or maybe a year ago, if you tried to use, let's say the latest Claude model for writing shaders, GPU shaders, the results were probably underwhelming. And if you use the latest model now to do that kind of task, you're a little bit blown away, like, “Wow, that actually worked. That's amazing.” And we see the same thing in the embedded realm. No question though, especially when you get into safety critical systems, the human validation isPeter [00:26:25]: is 100% key. Like I You're not gonna trust your life to a an AI written software that's, that's not been very carefully, checked by humans. And so I think now the really the challenge is about that appropriate level of human validation for these safety critical systems.Verifiable Rewards, Evals, and Neural SimulationAlessio [00:26:41]: How do you think about, yeah, touching on the simulation side, I think verifiable reward and reinforcement learning is, like, the hottest thing. What have you done internally to build around that? And like, what gives you What makes you sleep at night? Like, if somebody's like, just web coding something or likeAlessio [00:26:57]: wants to try something new, you have like a good enough system. Because I think the opposite is also true, is like if it's super easy to write anythingAlessio [00:27:04]: then it puts a lot of work on like the verifiableAlessio [00:27:07]: side of it. Like, what does that look like for people?Peter [00:27:10]: Yeah. So verifiability, a broader bucket of like evaluations, right? Like how do you evaluate the results that you're, you're getting? I think this is probably the hardest problem right now, because the As the models get better, it can be harder and harder to find the faults on the system.Peter [00:27:29]: And so like the problem of doing proper eval to find those faults, like that problem also keeps getting harder as the models get better. But it's no less important than it's ever been, right? You still there are still going to be edge cases that are not met and whatnot. And so it's, it's a big area of investment for us. On the reinforcement learning topic, the key thing is there's all these new requirements that come to be in the latest generation of these technologies. So for example, end-to-end is the big thing right now in autonomy and physical AI, which is you can now train these models that can effectively take sensor data in and then put control signals out, and get really good results out of that. But the way that you train and improve those models is really different from the previous generations. And so to do reinforcement learning on an end-to-end model, you now need to actually simulate all the sensor data, right? So then this becomes a we call our, work in this neural simulation, but it'sPeter [00:28:26]: think of it like a hybrid of Gaussian, splatting and diffusion methods, and where you really care about performance. Like performance is everything. If you can't do enough simulation fast enough and cheap enough, you actually can't get results that are worthwhile, in the end. It also gets to a lot of our work in embedded systems, which is like performance critical work, and that performance optimization, performance criticality, it carries over to a lot of the model training work. because, like, the only way to make it affordable is it has to be really fast.Qasar [00:28:58]: I think it's worth a few minutes talking about our own, evolving thoughts on verification and validation withinQasar [00:29:05]: kind of, traditional simulators, which are, you can think of like vehicle dynamics or something like that, which you're just taking textbooks and taking those formulasQasar [00:29:13]: and putting them into software, to like now this neural sim/world model universe. I think that's an interesting topic.Peter [00:29:20]: Yeah. So in more traditional development, right, you oftentimes would have, more black-and-white answers to questions.Peter [00:29:28]: And so the in Europe as an example, there's, a regulatory, system, it's called Euro NCAP. It's the European New Car Assessment Program, and as part of that, the vehicles have to pass a bunch of tests, and those tests actually, include, safety systems. So automatic emergency braking for a child that runs in front of a carPeter [00:29:51]: or let's say an occluded child that runs out and you hit it. And so you have You end up with sort of these binary answers of like, well, did the car under test pass this specific test? And there's a very well-known set of test casesPeter [00:30:05]: that the vehicle has to pass. And that was how the industry worked, let's say, until 10-ish years ago. But what's changed now is with these models, everything is statistics, right? Like you no longer have a black-and-white answer, but it's like, well, how many orders of magnitude or how many nines of reliability can I get in the system, and how can I, how can I prove that to be true? And the big unlock honestly for physical AI as an industry is that these models are just becoming much more reliable. Right? Things like things actually work a lot better. It's like the number of nines you can get out of these systems are now good enough that it actually becomes cost effective to really deploy these things. And so the big shift in, so verification and validation has been from a little bit more of a Again the past it was strictly requirements, and are you meeting or not? And now it's more of a statistical, verification and validation case where it's all about how many nines of reliability and meantime between failures, that sort of thing.Statistical Validation, Regulators, and the Cruise LessonSwyx [00:31:04]: And is the target audience regulators or even the customers are yeah, if you I imagine the customers are bought in, and it's mostly regulators that need to be satisfied.Peter [00:31:15]: We do work with the US government, we do work of course with the European governments and the government of Japan, and the government is not like an AI lab by any means.Peter [00:31:25]: So Swyx [00:31:26]: They just care about the outcome.Peter [00:31:27]: They care about the outcome.Peter [00:31:28]: And so we do education, in that regard, and like so sort of teaching about, “Hey, this is how we think validation should be done, and this is an approach that we think is reasonable,” and how to think about like when is a driverless system actually safe enough to go on the roads and that sort of thing. But I wouldn't say that the government is asking for it. It's like we're more teaching the government in that, in that sense. It's honestly, it's more so for our own, our own comfort, right? Like, we want to build very safe systems, and then of course our customers care deeply about that as well. But in that context we're also typically educating our customers.Qasar [00:32:01]: Yeah. Our first, our first core value is on round safety. So I think we can't underline enough that, us also verifying and validating that the systems that we're deploying are safe to us is probably as important as, like, some regulator or a customer saying,Swyx [00:32:19]: Of course. Okay. Yeah.Swyx [00:32:20]: You have to satisfy yourselves.Peter [00:32:22]: As I say, as a whole across the world, regulation oftentimes it's like a almost lowest common denominator. But like, you really have to substantially exceed what the regulators are expecting to make good products.Swyx [00:32:33]: Yeah. One thing I often talk about, I think and I try to make this relatable to the audience also, is Cruise, where they had an accident that basically ended the company. I wonder if people overreact to single incidents, because incidents are going to happen regardless, right? ‘Cause it's a statistical thing, but as long I don't know if regulators understand that, you cannot extrapolate from a single incident, but we do because that's all we have to go on. And your sample sizes are necessarily gonna be lower than, I don't knowSwyx [00:33:00]: consumer driving.Qasar [00:33:01]: Yeah. I think the Cruise example wasn't a technology failure. there was The real, compounding issue there was just how did the company talk to the regulators and what was their kind of behavior, and I think that became more of the issue. If you look,Peter [00:33:19]: It isn't It definitely was a technology failure, but it was made much worse by theSwyx [00:33:23]: Put the car back on the woman.Qasar [00:33:25]: Yeah. And let me put it another way. There is a version where Cruise still exists.Swyx [00:33:29]: right. Right.Qasar [00:33:30]: Right. It'sSwyx [00:33:30]: It was like the last strawQasar [00:33:31]: ItSwyx [00:33:31]: in like a long chain ofSwyx [00:33:33]: like issues.Qasar [00:33:33]: So do you feel like ATG had that horrific accident or someone actually dying, because, that was a homeless person crossing the street? So yeah, I think we can't understate enough that ultimately, like, statistical validation of something, that's one part of it, but it's not the only part of it. Like, consumer and let's say, mainstream adoption of these technologies is also gonna be part of that conversation. I think companies like Waymo are doing a lot of service positively to the industry in the sense of they're, they're setting a high benchmark and they're showing, kind of in a very responsible way how to, how to deal with these. There have been Waymo incidences as well. They've just not been as significant as the Cruise one that you mentioned. But yeah, so I think you'll just continue to see that. I think probably the long term question is really gonna be, again, around Like it is very clear humans are way worse drivers statistically.Qasar [00:34:29]: Like, there's no, there's no debate. And so at what point But we're emotional animals.Swyx [00:34:34]: Yeah. So my thing is, like, we have to get to a point as a society where we accept horrific accidents that would never happen by a human because statistically we understand that it is safer overall. In the same way that planes, they're safer, than I think they're the safest mode of transport that we have.Qasar [00:34:50]: Yeah. it's more dangerous to drive to the airport than it is to get on a flight.Qasar [00:34:53]: So if you're everQasar [00:34:54]: if you're ever getting nervous about getting on a plane, just think “I just gotta get to the airport.”Swyx [00:34:58]: Yes, we're flying.Qasar [00:34:59]: If I get to the airportQasar [00:35:00]: I'll be good.Swyx [00:35:00]: But then it's, planes also concentrate the tail risk if planesQasar [00:35:03]: Yeah. AndPeter [00:35:04]: And I was, I don't think we honestly have to worry about there ever being, accidents from these systems that are like much worse than what humans would cause, ‘cause humans do terrible things.Peter [00:35:14]: Like, people fall asleep at the wheel all the time.Swyx [00:35:16]: I have.Swyx [00:35:17]: Like, I'll call, I've been a drowsy driver.Peter [00:35:19]: Kinda drunk drivers, and that'sPeter [00:35:20]: that's the extreme end of the example. But these AI systems, you have redundancies, you have fallbacks. Like, there's many things have to go wrong for there to actually be a something catastrophic because there's, there's so many, fallbacks that these systems have.Alessio [00:35:36]: your simulation is like so vast because there's so many use cases. What are, like, maybe things that worked in a simulation and then you put it out and it's like, “F**k, this isAlessio [00:35:45]: this just did not work at all?”Peter [00:35:47]: Yes.Alessio [00:35:47]: IsPeter [00:35:47]: That's maybe a bit of a misconception, about simulation there. So let me go a little bit, more technical on this. So at first go, no simulation is going to represent the real world. There's always a process of this, sim to real matchingPeter [00:36:02]: where you actually, you need the real world feedback to basically feed into the parameters that are being used in the simulator, and you have to do that, it's like this validation flow, a number of times until you can get some confidence that, like I think the simulator is now accurately representingPeter [00:36:19]: what's gonna happen in the real world. Now, if you have a situation where you've done that full validation and you thought that it was accurate and then there's something different, those are much trickier cases, and that's, that absolutely can happen, but really I think the validation process is a really important part. You can never skip the simulation validation process, like where you're actually ensuring that, hey, the actual, my sim to real gap here is small enough that I can trust these simulation results. And there's, there's so many fun things that you can do when you get into it. Like, I'll, I'll give one fun example that came up recently is like in these humanoid robotics, systemsOverheating actuators is a real problem, right? So obviously phenomenal demos. IPeter [00:37:01]: The most amazingAlessio [00:37:02]: For 10 minutes.Peter [00:37:03]: The most amazing I can get. I love, I love watching robots do acrobatics like everybody but the these systems actually overheat, right? If, like, And one of the ways you can use simulation though is you can actually have that, the temperature of those actuators be one of the parameters that's representedPeter [00:37:18]: in the simulation. And if you're doing reinforcement learning over a certain task, then the robot can actually adjust its motions in the simulation to account for the fact that, oh, it knows that as it's moving, it's actually beginning to overheat this motor. But if you didn't have that parameter of, let's say, the heat of that motor represented in the simulation initially, then your RL policy might It will disregard that. And now you run that on the robot and the robot will overheat and fail.Alessio [00:37:43]: I guess the question is, like, how do you have all of these parameters taken care of while also understanding the deployment environment? Like, temperature is like a great example, right? WellAlessio [00:37:53]: why did you make my robot worse when it runs in like a freezer?Alessio [00:37:57]: So it actually shouldn't worry about that. it's like, yeah, how do you design these simulations?Peter [00:38:02]: This is honestly the This is what makes simulation so hard, right? it's because you Simulation is fundamentally about you're trying to optimize the development of a system, right? Like, how can I build this system faster and better and cheaper and what are all the levers that I have to actually accomplish that? And because simulation's just a software program, you can, you can change it a lot more easily than you can hardware systems. And then what's particularly awesome about the let's say, world models and using that as a part of simulation is now the simulation doesn't just scale with, let's say, adding new math equations inPeter [00:38:36]: but we can actually scale the simulation environment now with additional real world data and that also unlocks a whole new field of robotics.Qasar [00:38:46]: There is a meniscus line where you cross where still doing real world testing is better. there's, in this, sim-to-real gap, you can reproduce reality at exceedingly expensive costs and this So nothing is free. So really you have to you're finding that line where you're getting great performance, you're getting great feedback, whether it's on the training side or on the eval side, but it's way cheaper than doing it in the real world. At some point it, that doesn't make sense. And so even, from our earliest days in autonomy, our view was you're still gonna do real world testing. You There's, there's not, there's not this, magical land where you're not gonna do that. And maybe even like a more nuanced version of this in like traditional software development is, most of your testing for software in a vehicle, 95% of that can be like traditional CI/CD kind of, flows that you would have in traditional web development. But once you have Now you, let's say you have a truck. Well, you can do like 4% of those in like a rig which has all the components, the electrical and electronics of a truck, but doesn't have, it doesn't have the tires and it doesn't have the And then you have the 1%, which is actually the vehicle. There's something There's a similar analogy in terms of using simulation for intelligent systems. You can do a lot in a simulator, but in using world models, but ultimately it's, it's physical AI. So you're gonna deploy it on physical machines andQasar [00:40:17]: the freezer example comes to, comes to light.Alessio [00:40:20]: The world model thing has been to me the hardest thing toAlessio [00:40:22]: wrap my head around. Like we have Faith Eliyon on the podcast.World Models, Hydroplaning, and Cause-Effect LearningQasar [00:40:25]: We've been doing a small series with like another Intuition company, General Intuition as well.Qasar [00:40:31]: yeah, and I mean, lots of, lots of coverage on NeRFs and yes.Alessio [00:40:34]: Yeah. It feels like we talk with about, the heliocentric system, right? It's like in a world model, if you just feed visual data, the model might learn that the sun spins around the Earth. It makes sense, right? And it's like, well, not really. And I think what are like some of these other things that like hydroplaning is one thing I think about, is like can a world model understand hydroplaning and like what amount of water like causes it to happen? And it's like, yeah, to me it's like I don't understand how you guys do it. I guess it's like the real thing is like when you're doing both cars and the highway in Japan versus the excavator in a mine in,Qasar [00:41:13]: ArizonaAlessio [00:41:13]: wherever you're Arizona, wherever you're deploying them.Alessio [00:41:15]: How much of it are you relying on the world models to like generate the simulations for you and then try and close the gap after versus like giving the world models as a tool to your engineers to like curate the simulations if that makes sense?Peter [00:41:28]: Yeah, totally. So yeah, I can say at a pure engineering level, I think if you're hoping to do real world deploys and you're purely relying on a world model approach, you probably won't get to something that works, before you go bankrupt. So there is just a very practical mindset of like, world models are amazing and they're extremely useful for a lot of use cases, but there are a lot of other things that you need to do to actually get something started and something deployed and working. most fundamentally, world models are all about It's understanding the world, but also understanding what's going to happen. It's like the cause-effect relationship.Peter [00:42:01]: Right? And so like it, right, if you have a take some sort of construction tool, and that construction tool is gonna be doing some work on the Earth in some way, it's gonna be moving earth, the world model needs to understand that cause-effect relationship. Like, okay, when I, when I take this material from here and put it over there and now I have things that are over here and not over there anymore and that cause-effect, relationship. data obviously is a is a big problem. The hydroplaningPeter [00:42:26]: one is actually a really great example because it's actually quite non-obvious sometimes. Right? It's like, well, it's, it's raining and well this road, has, let's say the appropriate curvature to it so the water is running off the road and cars are driving faster here and then you approach a road that's very flat and water is now puddling on that road and all of a sudden cars are driving slower because when they were driving faster they were starting to lose control. And there are a lot of visual nuance, very nuanced visual cues in the scene and so I do think in the world model concept there's a good chance that the model actually would learn that you should just drive slower when these visual cues exist, and that's obviously the beautiful-The beauty of, these kinds of models where they just, they learn these non-obvious things.Swyx [00:43:14]: It doesn't need to know about hydroplaning to know that it needs to drive slower.Peter [00:43:17]: Yes.Swyx [00:43:17]: I guess it's Yeah. I wanna ask questions about, also deploying models. I presume, like, you use a lot of these world models for training data and simulation, but what about deploying it onto the systems in production? Presumably you have you have, like, GPUs on deviceOnboard vs. Offboard: Latency, Embedded ML, and DistillationSwyx [00:43:36]: but they're I keep saying on device. What's the what's the right term for that?Peter [00:43:40]: On machine.Swyx [00:43:41]: On machine.Peter [00:43:41]: Or embedded, yeah.Swyx [00:43:42]: Yeah. What is the embedded world like? because for people who are not used to that world, this is very alien.Peter [00:43:49]: Yeah. So it's actually We call it onboard and off board.Peter [00:43:52]: So like, onboard software and off board software.Peter [00:43:54]: And the great thing about off board software is you don't have to care about time, and you can run really large models, right? So you can, you can say, “Well, this model, I don't care if it takes one second for it to give me a result or 10 seconds for it to give me a result, because we have time.” And the models can be really big, and they can run, in a data center or on a on a huge GPU and you can obviously have distribute to compute, et cetera. But onboard you don't have any of those benefits. You're like, “Well, I need I have this many milliseconds where I need an answer from this model.” And so a lot more of the energy then is about, think of it more like distillation and it's like truly efficiency and like, literally every fraction of a millisecond counts. And you can't have a situation where the model takes too long because then the vehicle can't actually function.Peter [00:44:42]: And so you can, you can still use a lot of the same techniques, and the models themselves you can think of as like a derivative of larger models that you can run offline, and then you're, you're trying to just get a model that is still performs really well but it's, it's a it's smaller, small enough version that you can then run on this embedded system where you care about latency and power.Qasar [00:45:03]: Yeah. And I think like, the broader point I think which, maybe is not obvious but it's worth saying is in physical AI world, we're not really constrained right now by, like, the intelligence of the models. It's actually what Peter's talking about, it's actually deploying them inSwyx [00:45:19]: The hardware they give you.Qasar [00:45:21]: Yeah. On the hardware you give you.Qasar [00:45:22]: And so And there's just a reality is of safety critical systems. So those end up being the your limiting factorsQasar [00:45:29]: rather than, let's say, a limiting factor for, a foundation model companyQasar [00:45:34]: is gonna be just capital maybe or researchers.Qasar [00:45:38]: So we're, we're in that way dealing with, for us as people who kind of come in that realm with like a very interesting Those constraints force creativity.Swyx [00:45:47]: And I imagine, nobody was deploying or giving you the hardware for transformers back in 2018, whatever, but now they are. What's the evolution like? just peel back the curtains a little bit.Peter [00:45:59]: Yeah. Transformers first off, I think the paper was originally published in 2017.Swyx [00:46:02]: 2017.Swyx [00:46:02]: So there's no time.Peter [00:46:04]: And ISwyx [00:46:05]: But I'm just saying I guess I'm saying, like, embedded ML systems usually, like, a lot less parameters, a lot less compute, and now, like, orders of magnitude more.Peter [00:46:14]: Yeah. absolutely. what I was gonna say though was I think in the in the original paper in 2017, maybe it's in the last paragraph, somewhere in the paper they talk about, like, “Oh, by the way, this technique might be useful for, like, images and videos as well.”Peter [00:46:30]: These last subjects.Peter [00:46:31]: And it took a few years for that impact to really hit. But like, now, we're seeing transformers are everywhere.Swyx [00:46:39]: Yeah. Vision transformers.Peter [00:46:40]: And then then the compute just keeps getting better and better. But you do have this fundamental trade-off, right? It's like you have power, you have cost, and performance and like, getting the right, getting the right mix of those things in an embedded package that can also be, like, shaken and baked in all thePeter [00:47:00]: conditions that these things have to have to operate in. But yeah, I think that they're only going to keep getting better and so we also try to plan our strategy understanding that, we know the rate of improvements of these systems.Swyx [00:47:11]: Yeah. So like, Google just released the Gemma 2B modelSwyx [00:47:15]: that effective 2B model. Is that useful to you guys or is that too big?Peter [00:47:18]: You can run that model on an embedded system, definitely.Peter [00:47:21]: the So yes, it's, it's useful in that regard. The bigger question is, like, what do you use it for in an embedded system? Like, you actually need to customize it quite a bit to make it useful for something. But yeah, you could run a two billion parameter model, definitely.Swyx [00:47:35]: It also interesting, like, what percent is a custom ML model that only does that thing versus a generalist LLMSwyx [00:47:41]: which probably is not that useful actually for your context.Peter [00:47:46]: Like, you, like, you can imagine different use cases, right?Peter [00:47:48]: So theSwyx [00:47:49]: The voice stuff, yes.Peter [00:47:49]: Yeah, the voice test. Totally, yes.Peter [00:47:51]: So for the actual, autonomy elements, that's 100% in-house. We do every bit of that, the data simulation, the model, everything. But when you get into the more generic use cases like voice or voice assistant kind of thing, that's where these more generalist models like Gemma actually can be quite, can be quite useful.Swyx [00:48:09]: Yeah. And then there's also obviously a trade-off between, like, what percent must you do on machine, versus just call home.Peter [00:48:16]: Yeah. It's all about latency.Swyx [00:48:17]: Latency.Peter [00:48:17]: It's all about latency. Yeah.Swyx [00:48:18]: Yeah. Well, like, I think actually in a lot of contexts, especially in the US, you can just have a connection to the web.Qasar [00:48:26]: Yeah. I think though most of our universe is everything has to be fairly, embedded and local because just the nature of Even in the US there's a lot of likeSwyx [00:48:39]: PatchinessQasar [00:48:40]: don't haveQasar [00:48:41]: have coverage, right? And if you look at, like, the old world of autonomy within mining, which is, like, long before transformers and kind of, neural networks, in the like CNN and kind of a universe, they were really just hand-coded, systems. They were just like, this machine is gonna run to that place with thisPeter [00:49:03]: That was our GPS, like very accurate GPS.Qasar [00:49:05]: Yeah. And so that worked, and that worked for 20 years, so why would we actually need to use transformers or kind of more modern end-to-end systems? Mainly because you can only really run a path and run backwards. That provided a lot of value, but m-Not as much as you get when the machine is actually intelligent. It's, it's seeing, it's perceiving, it's acting in a dynamic world.Alessio [00:49:28]: I looked up RTK, real-time kinematic, one to two-centimeter accuracy.Qasar [00:49:32]: Yeah. Fantastic. But the and fantastic in faraway lands where there's not gonna be cell phone coverage.Peter [00:49:39]: Yeah, so it's widely used on the legacy mining and agricultural autonomy systems today. So like, for example, a combine that can be precise within one or two centimeters as it's driving down the field, they use RTK.Qasar [00:49:53]: Yes.Peter [00:49:53]: But it's, it's expensive.Qasar [00:49:54]: Yeah. And it's, it's, it's autonomy, but it's not intelligent in the way that I think all of usQasar [00:49:58]: if in twenty-six we'd be talking about intelligence.Alessio [00:50:00]: In one of your blog posts, you mentioned research on large scale transformers that are similar to those doing modern generative AI. What are, like, the big differences other than, “You're absolutely right. I should steer the car, so you probably wanna remove that?”Peter [00:50:14]: We have a diversified bet strategy internally, and the reason we've done that is because we operate in now a bunch of industries, a bunch of geographies, and each of the approaches has, obviously a different risk to them.Peter [00:50:27]: And so like, we're not going to put all of our eggs in a single basket for a single approach because that approach may no

Early bird discounts for the San Francisco World's Fair, the biggest AIE gathering of the year, end today - prices will go up by ~$500 tonight so do please lock in ASAP!From near-universal AI tool adoption inside Shopify to internal systems for ML experimentation, auto-research, customer simulation, and ultra-low-latency search, Mikhail Parakhin joins us for a deep dive into what it actually looks like when a 20-year-old, $200B software company goes all-in on AI. We cover why Shopify has become much more vocal about its internal stack, what changed after the December model-quality inflection, and why the real bottleneck in AI coding is no longer generation, but review, CI/CD, and deployment stability.We also go inside Tangle, Tangent, SimGym, which are three major AI initiatives that Shopify is doing to make experimentation reproducible, optimization automatic, customer behavior simulatable, and search and catalog intelligence faster and cheaper at scale. Along the way, Mikhail explains UCP, Liquid AI, and why token budgets are directionally right but often measured badly, why AI-written code can still increase bugs in production, what makes Shopify's customer simulation defensible, and what he learned from the Sydney era at Bing.We discuss:* Mikhail's path from running a major Microsoft business unit spanning Windows, Edge, Bing, and ads to becoming CTO of Shopify* Why Shopify is talking more publicly about AI now, and why staying at the frontier has become necessary for the company* Shopify's internal AI adoption curve, the December inflection, and why CLI-style tools are rising faster than traditional IDE-based tools* Why Jensen Huang is directionally right on token budgets, but raw token count is still the wrong way to evaluate engineering output* Why the real unlock is not more agents in parallel, but better critique loops, stronger models, and spending more on review than generation* Why AI coding can still lead to more bugs in production even if models write cleaner code on average than humans* Why Shopify built its own PR review flow, and why Mikhail thinks most off-the-shelf review tools miss the point* How PR volume, test failures, and deployment rollback are becoming the real bottlenecks in the agent era* Why Git, pull requests, and CI/CD may need a new metaphor once code is written at machine speed* What Tangle is, and how Shopify uses it to make ML and data workflows reproducible, collaborative, and production-ready from the start* Why Tangle is different from Airflow, and why content-addressed caching creates network effects across teams* What Tangent is, and how Shopify is using auto-research loops to optimize search, themes, prompt compression, storage, and more* Why Tangent is becoming a democratizing tool for PMs and domain experts, not just ML engineers* Why AutoML finally feels real in the LLM era, and where auto-research still falls short today* Why Tangle, Tangent, and SimGym become much more powerful when combined into one system* What SimGym is, why simulated customers only work if you have real historical behavior, and why Shopify's data gives it a moat* How SimGym evolved from comparing A/B variants to telling merchants what to change on a single live storefront to raise conversions* Why customer simulation is so expensive, from multimodal models to browser farms to serving and distillation costs* How Shopify models merchant and buyer trajectories, runs counterfactuals, and thinks about interventions like discounts, campaigns, and notifications* Why category-level behavior is so different across commerce, and why ideas like Chinese Restaurant Processes are showing up again in practice* Shopify's new UCP and catalog work, including runtime product search, bulk lookups, and identity linking* Why Shopify is using Liquid AI, and why Mikhail sees it as the first genuinely competitive non-transformer architecture he has used in practice* Where Liquid already works inside Shopify today, from low-latency query understanding to large-scale catalog and Sidekick Pulse workloads* Whether Liquid could become frontier-scale with enough compute, and why Shopify remains pragmatic and merit-based about model choice* Who Shopify is hiring right now across ML, data science, and distributed databases* The Sydney story at Bing, why its personality was not an accident, and what Mikhail learned from deliberately shaping AI character early onMikhail Parakhin* LinkedIn: https://www.linkedin.com/in/mikhail-parakhin/* X: https://x.com/MParakhinTimestamps00:00:00 Introduction: Mikhail Parakhin, Microsoft, and Shopify00:01:16 Why Shopify Is Talking More About AI00:02:29 Internal AI Adoption at Shopify and the December Inflection00:06:54 Token Budgets, Jensen Huang, and Why Usage Metrics Can Mislead00:10:55 Why Shopify Built Its Own AI PR Review System00:12:38 AI Coding, More Bugs, and the Real Deployment Bottleneck00:14:11 Why Git, PRs, and CI/CD May Need to Change for Agents00:18:24 Tangle: Shopify's Reproducible ML and Data Workflow Engine00:21:19 Why Tangle Is Different from Airflow00:26:14 Tangent: Auto Research for Optimization and Experimentation00:30:07 How Tangent Democratizes Experimentation Beyond ML Engineers00:33:06 The Limits of Auto Research00:36:36 Why Tangle, Tangent, and SimGym Compound Together00:37:20 SimGym: Simulating Customers with Shopify's Historical Data00:42:47 The Infra Behind SimGym00:46:00 Why SimGym Gets Better with Real Customer History00:47:30 Counterfactuals, HSTU, and Modeling Merchant Trajectories00:51:55 CRPs, Clustering, and Category-Level Customer Behavior00:53:30 UCP, Shopify Catalog, and Identity Linking00:55:07 Liquid AI: Why Shopify Uses Non-Transformer Models00:59:13 Real Shopify Use Cases for Liquid01:03:00 Can Liquid Scale into a Frontier Model?01:09:49 Hiring at Shopify: ML, Data Science, and Databases01:10:43 Sydney at Bing: Personality Shaping and AI Character01:13:32 Closing ThoughtsTranscript[00:00:00] swyx: Okay. We're here in the studio, a remote studio, with Mikhail Parakhin, CTO of Shopify. Welcome.[00:00:08] Mikhail Parakhin: Thank you. Welcome.[00:00:10] swyx: I don't even know if I should introduce you as CTO of Shopify. I feel like you have many identities. Uh, you led sort of the, the Bing ML team, I guess, uh, uh, or ads team. I, I don't know, I don't know, uh, you know, it's, uh, people va-variously refer you as like CEO or, or, uh, I don't know what that, that, that said previous role at Microsoft was.[00:00:29] Mikhail Parakhin: Uh, that was... Yeah, my previous role w- at Microsoft was the-- I actually was the CEO of one of Microsoft's business units, which included, as I, you know, as we discussed, all the things that people like to laugh about, uh, including Windows and Edge and Bing and ads and everything.[00:00:47] swyx: Yeah, yeah. What a, what a, what a wild time.You've obviously, uh, done a lot since you landed at Shopify. Uh, one of the reasons I reached out was because you started promoting more sort of internal tooling, uh, primarily Tangle, but also a lot of people have seen and adopted Tobi's QMD, uh, and obviously, I think, uh, Shopify has always been sort of leading in terms of, uh, engineering.I think more-- it's just more recent that you guys have been more vocal about your sort of AI adoption. Is that, is that true?[00:01:16] Mikhail Parakhin: Well, I think AI tools in general are fairly recent development, uh, and we've-- Shopify, you know, at this stage of its development, we're developing AI in-in-house and other, uh, building tools that use AI and, you know, interfacing with the wider AI community, uh, you know, are on the sort of the, uh, runaway trajectory.So it just did by sort of natural byproduct. We, we talk about it more also. We just, uh, just even yesterday, Andrej Karpathy was famous in tweeting about, oh, are there some, uh, ways, uh, that, that you can organize your agents to store the data and then, uh, look up the data so that you don't have to research or, or lose context every- Yestime. And a little bit tongue in cheek, I tweeted that, “Hey, we've, we've done it much earlier, and we even have different approaches, Tobi and I.” Tobi, of course, is a big fan of QMD, and I'm more of a SQL, SQLite fan. But, uh, yeah, very similar things that we've already done here. The point is, yeah, we're very dynamic, you know, explosively growing company, and we have to be at the forefront of AI adoption, obviously.[00:02:29] swyx: Yeah. Yeah. Um, you, your team kindly prepared some slides actually that we were gonna bring up on to, uh, the screen. I think I can, I can screen share, and then we can kind of go through some of the shocking stats that maybe, maybe put some numbers to what exactly is going on. So here we have, uh- An internal AI tool adoption chart.What are we looking at here? What ?[00:02:54] Mikhail Parakhin: Yeah, this is very interesting statistics. Uh, this is number of daily active workers, you know, think of, uh, DAO, basically the active users of-[00:03:05] swyx: Yeah ...[00:03:05] Mikhail Parakhin: AI tool as a percentage of all the people in the company, right? And then- Yeah ... different AI tools. And, uh, you could see two things here is that one is the green is total.Uh, green is just total. So you could see that it approaches really % by now. It's hard not to do your job now without interacting deeply, at least with one tool. You could see another interesting thing is just as many people commented in December was the phase transition when suddenly models gotten good enough that, that everything took off and started growing.Uh, it, it was many people noticed that the thing is that small improvements accumulated into this big change in Sep- December roughly timeframe.[00:03:52] swyx: Yeah.[00:03:52] Mikhail Parakhin: The other thing I would claim you could see is that, uh, CLI-based tools and tools that don't require you to look at the code becoming more popular, and you could see, yeah, various versions of, uh, Cloud Code and Codex and Pi and internal development tools taking off.Uh, exactly, yeah, uh, and blue is our River, just internal agent for coding, where tools, uh, that require IDEs such as, uh, GitHub, Copilot or Cursor, they're not exactly shrinking, but they're not growing as fast. Like, uh, red, red line is, is the IDE kind of tools. So you could see that they're, they're not experiencing as, as fast of a growth.[00:04:37] swyx: As I understand it, basically, every employee has their choice, right? Of choose whatever tool you use, and then you're just kind of doing a, a daily sur-survey or something.[00:04:47] Mikhail Parakhin: Exactly. And, uh, we- Yeah ... the, the push is to get your job done, you can use any tool, and we effectively fund unlimited tokens for everybody.Uh, we, we do, we do try to control the models that, uh, people use, but from the bottom, not from top. Like we basically say, “Hey, please don't use anything less than Opus four point six.”[00:05:09] swyx: Oh .[00:05:10] Mikhail Parakhin: Some people, some people end up using GPT five point four extra high. Some people use Opus four point six. Um, uh, you know, uh, there are some, uh, there are plus and minuses in going for full one million context window versus not.But, uh, we try to discourage people from using anything less than that.[00:05:28] swyx: Yeah, yeah. Got it, got it. Uh, I mean, uh, that's, you know... The, the next chart here, it really kind of shows the expansion and the sort of December twenty twenty-five inflection, right? That, uh, people are using a lot of tokens. I think it's also really interesting that no one was kind of abusing it in twenty twenty-five.Like it was- Had comparatively, uh, to this year, there was almost no growth. I mean, it's still like, you know, probably, probably gave fifty percent.[00:05:56] Mikhail Parakhin: Yeah. This is just a different scale. It's still exponential- Yeah, yeah ...growth at just a different- ...rate of expansion. Uh, there was inflection point, and Sean, I would claim the, the super interesting part here is that you could see that the distribution becoming more and more skewed.Yes. The top percentiles grow faster. So that means- Yeah ...the people in the top ten percentile, they, their consumption grows faster than seventy-five and so forth. So, uh, the distribution skews more and more towards the highest users, which is... I don't know what it tells me. It's like it feels not ideal, to be honest.Or maybe it's okay. We'll see.[00:06:36] swyx: Why does it feel not ideal? Is, is it because of, um, quantity over quality, or what's the concern?[00:06:42] Mikhail Parakhin: Because take it to the limit. That means, you know, if, if this rate of separation continued- Ah, yes ...a year, there will be one person consuming all the tokens. So it's just, it's kinda strange.[00:06:54] swyx: Yeah, I mean, um, uh, I, I think internal like teaching and all that, uh, will, will help sort of distribute things more widely. But in, in the early days, of course, the people who are sort of more AI-pilled will obviously find more ways to use it than the people who are less AI-pilled. Maybe let's, let's call it that.I'll just, I'll just kinda quickly, uh, pause from the, the... You know, we will go back to the rest of the slides, but I just wanna, um, review, you know, there are a lot of CTOs of, of large companies like yourself where they're all considering some kind of token budget, right? Like I think it's something, something that Jensen Huang has been talking about, where like if your 200K engineer is not using 100K of tokens every year, like they're, they're underutilizing coding agents.Of course, Jensen Huang would say that, but like it seems a very quantity over quality approach and like some, some people are basically saying like, well, is this comparable to judging engineer quality by lines of code, right? Which we also know is like kind of flawed, but better than nothing. So I, I don't know if you have like a sort of management take here on, on how to view this kind of, uh, metrics.[00:08:02] Mikhail Parakhin: Well, I mean, you're, you're baiting me. I, I like... This is my favorite topic. Uh, if you let me, I'll probably talk for two hours on just this. I have a lot of things to say. Like I do think Jensen gotten a lot of bad press saying, “Oh, of course you're, you know, this, uh, the- ...the cake seller says you don't need enough cakes.”You know? Like, of course. Uh, but, uh, I actually, uh, think that's undeserved. I think he, he's actually right. Uh, I do think- He,[00:08:33] swyx: he's directionally correct.[00:08:35] Mikhail Parakhin: Yeah. Yeah. He's directionally correct for sure. Uh-[00:08:37] swyx: Who knows what the right number is? Yeah.[00:08:39] Mikhail Parakhin: The thing that I do Uh, want to say, and this is something that we learned through trial and error and very important is like two things.One is that it's not about just consuming tokens. Uh, you can consume tokens and, and in fact, the anti-pattern is running multiple agents, too many agents in parallel that don't communicate with each other. That's almost useless, uh, compared to just fewer agents and burns tokens very efficiently. Uh, setting up the right critique loop, especially with the high quality models, where one agent does something, the other one, ideally with a different model, critiques it, uh, suggests ways to improve it, the agent redoes it with this critique and, and so it takes much longer.So people don't like it because latency goes up. You know, they, they have to wait until this debate is happening. But, uh, the quality of the code is much higher. And another thing, just since you mentioned like, look, uh, uh, yeah, the overall budget is just like, uh, lines of codes. Lines of codes are exploding for everybody right now, or partially because AI is really mover balls, but partially just because AI can write a lot more code, you know, doesn't get tired.And so you have to have to have a very strong narrow waist during PR review. Otherwise, just the number of bugs will go through the roof. It's, uh, it's this unexpected consequence of the just volume trumping everything. I would claim by now good model writes code on average with fewer bugs than, than the average human.But since they write so much more of it, like more of it will make it into production. So you have to- You still[00:10:26] swyx: have[00:10:26] Mikhail Parakhin: more bugs. Yeah. Have to have a very rigorous PR reviews, also automated of course. But, uh, yeah, that to spend a lot budget there. Like this, this for me, for me, actually, the important metric is the ratio of budget spent during code generation versus, uh, spent, uh, expensive tokens like GPT, uh, five point four Pro or, uh, uh, Deep Think from Gemini, you know, checking on PR reviews.[00:10:55] swyx: Yeah, totally. Uh, I noticed in your chart you didn't have any review tools. Do you just use like, like let's say a Claude code to review tools? Or do you have another set of review tools like the Greptiles, the Code Rabbits, uh, Devin Reviews has a review tool. I don't know if you've had those specialist review tools.[00:11:13] Mikhail Parakhin: You are a little bit jumping on my store tool right now because the graphs I was only showing public tools. Uh, uh, the-- I haven't found a good PR review tool that, that does what I think should be done. And, uh, partially my, my thinking is because it's so... It just goes against both what people feel like emotionally they prefer and, uh, some of the, uh, you know, frankly Even business models that, that the companies run.At peer review tool, uh, time, you want to run the largest models. That means, I don't know, Codex or, or, uh, Cloud Code is not gonna cut it. You need to have pro-level models if you really want to, uh, stand the tide of bots from going into production. And you need us to spend a lot of time, the models taking turns, but you don't want, like, a big swarm of, uh, of, uh, agents.So in fact, you end up in a different dual-dualistic world where you generate not that many tokens. You, in fact, generate few tokens, but it takes f-a long time because these are expensive models taking turns rather than many, many agents trying to do many things in parallel. So that's, that's why I feel like I haven't found good tools, so we are using our own for peer review for now.[00:12:33] swyx: Yeah. Yeah. I mean, uh, I think a lot of companies are building their own, uh, especially to their needs, right?[00:12:38] Mikhail Parakhin: Mm-hmm.[00:12:38] swyx: Um, I, uh, you also have a chart here going back to the slides on, uh, PR merge growth, where we're now at thirty percent, uh, month on month rather than ten percent. Uh, and also the, the estimated complexity is going up.You know, this is productivity, right? ‘Cause y- presumably there's more stuff going into the code base and more, more features getting worked on. I'm curious about the backlog, right? Like the, the, the-- I actually don't mind a pro-level model taking an hour or two hours to review my PR, because I've dealt with humans who take a week to review my PR, right?And I keep pinging them on Slack, “Hey, hey, review my PR.” So, you know, I think there's some trade-off here where, like, it still doesn't make sense.[00:13:18] Mikhail Parakhin: Exactly. That, that's exactly m-my point. Uh, that on one hand, you can tolerate longer latencies at, uh, PR. On the other hand, like right now, the real problem is not in spending time waiting for PR.It's real problem is since there's so much more code than- Yeah ... uh, probability of at least some tests failing going up, and then you, like, keep de-failing, then you have to find the offending PR, evict it, retest it without that PR, and so deployment cycle becomes much longer. Uh, so it actually, in terms of the overall time to deploy, it's total time savings if you spend more time on a longer model, like thinking for an hour, because then, then you, you don't have to spend all that time during testing and rolling, you know, rolling back the deployment.[00:14:03] swyx: Yeah, totally. That's still worth it. You know, you don't look at the individual, look at the aggregate, and look at the, the, the change in the aggregate system.[00:14:11] Mikhail Parakhin: Exactly.[00:14:11] swyx: I'm kind of curious if, like, there's this PR mentality and, like, c-- the, the, the CICD paradigm will be changed eventually. Some people are like, obviously a lot of people want new GitHub, but I even wonder if, like, Git is the problem, right?Like, is that the bottleneck? Is the concept of a PR a bottleneck? Do you guys use stack diffs? I don't know if, uh, that's a, like, a merge queue stack diff type of thing.[00:14:34] Mikhail Parakhin: We, we use, we use Stacks, we u- we use Graphite. We worked with, uh, Graphite a lot. Uh, so we use Stack, uh, PRs. I think, uh, like that's clearly the overall CICD in general, and the interaction with the code repository right now is the, clearly the sort of the, the main issue and the bottleneck for us, uh, and highest top of mind.I would say we probably need a different metaphor or different whole design of how to process it in new agentic world. I haven't seen anything dramatically better yet. I, I think everybody right now is just trying to keep their head above the water ‘cause, ‘cause there, there's so many PRs and then everybody's CICD pipelines start creaking, the, the times are increasing, the number of bugs slipping by increasing, and you have to, have to clap on down.And so we are a little bit in this situation when we need to first stabilize that story and then start thinking, hey, what, what it could be a completely different and new world, which I haven't... I know some people working on it. I haven't seen something, like anything super compelling yet, but clearly the old thing were designed for humans will need to be morphed into something new.[00:15:53] swyx: One of the thing that I, I think about is kind of like the merge conflict is basically a global mutex on the whole system, right? And in, in hu- in human organizations, we do have something like that. It's the company standup. But like, other than that, it's like it's actually fitting for us to be somewhat decentralized, somewhat plugged into one stream of information source, but somewhat lossy.Like it's okay, you know, that, that not every delivery is like atomic consistency. Like we're not dealing with a database sometimes.[00:16:27] Mikhail Parakhin: This is a very good point, uh, because since humans don't write code too fast, you know that global mutex is not too bad. Once you-[00:16:36] swyx: Yes ...[00:16:37] Mikhail Parakhin: start writing code at the speed of machine, it becomes the, you know, the bottleneck.Then what do you do? Maybe, and I can't believe I'm saying this because I, I'm long-- lifelong opponent of, uh, microservices, and I always thought that was, like, a really bad idea. And now that you're saying it, like, maybe in new guys like microservices will make a comeback, you know, because then you, you can ship things independently in tiny things and, and the managing all that complexity automatically will be much easier.I don't know. Like, we'll s-- we'll have to see.[00:17:10] swyx: Yeah. I mean, I don't know what the Microsoft or, or Shopify thing is, but I, I read this paper from Google where they have a monorepo that deploys into microservices, right? And then, uh, the other concept that I think about a lot is the Chaos Monkey concept from, from Netflix.Being able to create, like, this robust system where, um, uh, you know, you, you have the service discovery, you have the, uh, the independent, independent microservices discovery and, and, uh, you know, probably going to be a fair amount of duplication. That's how an organic system sort of scales, uh, that, that you have that...I don't know how you call it. Slack? Robustness? Depend-- uh, d-duplication. I, I, I forget the-- I, I'm-- And this-- those-- these are not exactly the terms- Hmm ... I'm looking for, but I c-can't really think of the words. Okay. I was gonna go into Tangent and Tangle. Uh, so, uh, we, we sort of discussed the overall stats that, uh, Shopify has.Uh, but, you know, I, I think some, some pretty cool stuff that you guys are working on is your ML experimentation, uh, and your, your sort of auto tr-research training pipeline. Presumably you're much closer to this one because it's, it's a sort of personal hobby of yours. How, how would you explain them in, together?I thought we have a slide that, like, uh, has the s- the system diagram.[00:18:24] Mikhail Parakhin: Yeah. Tangle first and then Tangent as a-[00:18:27] swyx: Yeah ...[00:18:28] Mikhail Parakhin: as a thing on top of Tangle. And, uh, Tangle is the third generation, I claim, of, uh, systems of, uh, running any data processing, but a bit with a skew for ML experiments, but not necessarily. Any sort of data processing tasks where you need to iterate, share, and you have scale so that you want maximum efficiency.You know how, like, normally you would work, you would-- Imagine you're a data scientist or an ML practitioner, you would get Jupiter notebooks or, or maybe you would get, uh, you know, Pyth- your Python scripts, and you would manage the data, and you produce those TSV files, and you put them in some JFS or something.Then you would notice that, oh, it has this, uh, weird missing values. You go and write another script that, uh, goes and replaces them with, uh-[00:19:20] swyx: Ah ...[00:19:21] Mikhail Parakhin: dash S. And then, then you, then you run some, some, uh, “Oh, I need to filter bots.” And so you run some light GBM model that, uh, removes the bots. And then, then you like-- And then you, you kind of like get into shape, and then you start experimenting, and you run multiple experiments, and then you're like, “Oh my God,” like, “this experiment is worse.”You undo, and you cannot get to previous result. And like, “Ah, what did I do?” Like that. Again, then, then you finally like get everything working. Then you like start throwing it over the fence to production. You, you replicate it, those things don't work, and then sometimes you like don't notice that you forgot some feature naming and the, the features don't match.But then, like imagine you, you did everything, and then six months later you're like, have to repeat it because now there's more data, or you wanted to do another pass, and you're like, “What, what did I do?” Or like, or like, “This script crashes now,” or the, “the path has changed.” And then, then you're trying to, like you spend another month just doing ar- digital archeology on your own, you know, history, right?Now multiply that by many, many teams. Now imagine you got an intern that you wanna ramp up. Now you have to show that intern, “Oh, you know, look, here's the folder, there's the scripts, you know, ask your cloud agent to do, and then, uh, to, to figure it out.” And then cloud agent does something, and then you're, “Ah, yeah, right, right, it was the wrong folder.I forgot to tell you, I actually have this other thing I forgot myself.” And, and that's, that's the, like, the daily life we all, uh, all know it, uh, if, if you're a data scientist, machine practitioner, ma- machine learning practitioner or, uh, or even like any data managing, uh, person.[00:21:00] swyx: Yeah. So I, I used to do this, uh, f- uh, on the quant finance side, uh, in, in my hedge fund.So we did this before Airflow, and then, uh, obviously Airflow came along and, uh, then more recently Dagster, uh, I would say is like, in my mind, what I would use for that shape of problem, uh, where you had to materialize assets and create a pipeline.[00:21:19] Mikhail Parakhin: And that's, that's very good segue because... So Airflow is great, but Airflow is more about you, you have something and you wanna repeatedly run it in production on schedule.It's less about you as a team developing things and being able to share, and you grabbing the standard pipeline and saying, “Hey, I wanna change this tiny little component in the huge sea of data processing, and I don't wanna-- I wanna run ten experiments on this, and I wanna do hyperparameter optimization.”All that is very hard to do with Airflow. It's very easy to do with Tango. Tango is m- more about, it's everything about group of people Running experiments, it might be agents too nowadays. Uh, running experiments cheaply, collaborating, sharing results. Uh, you don't need to understand fully. You, you grab-- you clone somebody else's experiment or somebody else's pipeline, uh, run, uh, change small piece, run it, be, like, get it to production state, and then ship in one click.So then the... You don't have to port it into any other system to, to run in production. You can just run the same experiment. It's, it's fully production ready. And, and it's, uh, it has lots of... Again, as I said, it's third generation system. The original one was, I would claim there was Ether and then, uh, at least in my career, Ether was the first, first, uh, that pioneered this type of approach.And then there was, uh, Nirvana, which, uh, uh, at Yandex, which did kind of sec-second take on this. And now this one aggregates the, the learnings from all of those and, and Airflow as well to, to get to the state where you try it, it, it feels kind of magical. Uh, ‘cause now everything is based on content, uh, hashes.So even if the version changed, but if the output didn't change, nothing is being rerun. It's very efficient. If you... Multiple people start experiment that needs the same sort of data preprocessing, it's not repeated multiple times. It's automatically done only once. If you start ten experiments that all require, you know, some, some data preparation first as the first step, and you don't have to coordinate for that.Like, you don't have to know that other people are starting it. You now, it's very easy compos-, uh, composability, any language you can u- uh, you wanna use, and it's very visual. So you can see immediately, you can edit it easily, you can assemble small things with just even mouse clicks if you want to, and, uh, share, clone.And everybody knows also it's fully kind of static in the sense that we rerun it second time, it will exactly have the same results. Like, you will never have to do digital archeology. So full versioning and everything is also there.[00:24:06] swyx: Uh, so, so people can, uh... It's open source. Go to the GitHub repo and, and, uh, check it out.Uh, and it is also a really good, uh, blog post about it. I think all these is, like, really appealing. The, the, the, the thing that I think sells me the most about it is that, um, sort of development to production transition, right? Which I think, um, a lot of people haven't really solved that, uh, strictly, right?Like, we develop really, really well in, in Python notebooks, but then, you know, that's obviously not a sort of production ready process. I think that, like, any way in which that is solved, I think is, is very appealing. Then the other thing that you mentioned, which also raised my eyebrows, was content-based caching, which you mentioned is, is, um, you know, is ve-very much, uh, um, a sort of efficiency measure about, uh, you know, just like recalculation only on, on sort of content addressing Which I think makes sense.Uh, it surprised me that the savings could be this much, but maybe I just haven't worked at your scale where there's so much duplication, uh, that people just rerun because they change a single ID upstream.[00:25:10] Mikhail Parakhin: It does, yeah. But it's not only you rerun. The, the main savings are coming from the fact that you ran it, you got your job done, and you moved on.Then- Yeah ... somebody else in some department you don't know existed runs the same task, but on a newer version.[00:25:27] swyx: Yeah.[00:25:27] Mikhail Parakhin: Like right now, you can't, in, in most of the organizations, you can't even find out about it so that you can't even measure that you're spending that time twice, right? Here- Yeah ... if everybody's on Tango, that's detected automatically and detected that the output is the same.And then for that person, all it looks like is like experiment just suddenly moved, jumped forward, right? Uh, uh- Yeah ... so that's because, because the, there's network effect of multiple people helping each other.[00:25:51] swyx: Yeah. This is one of those things where it's designed to be a platform from the beginning rather than an individual developer's tool from the beginning, right?And, and everything's gonna streams down from there. That is the sort of Tango, uh, orchestrator, and it's, it manages jobs. We've seen a few versions of this, and this is obviously, uh, uh, the sort of, uh, unique approaches that you guys have, have, uh, figured out. And then there's Tangent.[00:26:14] Mikhail Parakhin: Yeah. And Tangent is basically an automatic auto research loop that can help and kind of do your work for you.Uh- ... you know, uh, effectively, effectively, Andrej Karpathy recently popularized it with auto research. Yes. Remember he said like he was, uh, speed running this, uh... Yeah, uh, you know the story. The, here we're basically bringing the same capability into Tango so that, uh, the, uh, Tangent can analyze it. It's just an agent that can run multiple experiments, figure out what can be changed, and keep on rerunning it, keep on modifying until, uh, maximizing some goal, some loss function, whatever you need to, to achieve.And in general, I would say if you're not using auto research-like approach in whatever you do, like literally whatever you do, then you're missing out. We saw at Shopify that taking like a wildfire, anything where you can put measurements can be done dramatically better. Our-[00:27:19] swyx: Mm-hmm ...[00:27:20] Mikhail Parakhin: uh, speed of, uh, templatization HTML, uh, completely new UX tem- uh, templatization of, uh, reducing latency for liquid themes.Uh, we-- Our, uh, search, uh, recently we moved from It's hard even, uh, quote from eight hundred QPS to forty-two hundred QPS with the same quality just by pure optimizations and not a research loop that kept running and changing code in our index serve on the same number of machines, just increasing the throughput.We, we managed to improve the quality of gisting and machine learning process. Uh, you know, gisting is the prompt compression technique that[00:27:59] swyx: allows for[00:28:00] Mikhail Parakhin: lower latency and, and lower and, uh, actually higher quality slightly. So like literally whatever different walks of life, and it doesn't have to be AI related.Uh, we, we had a reduction in, uh, storage because the agents would go and find data sets that clearly are derivative, uh, and then you don't need to store things twice. You know, we, we, we found somewhat embarrassingly that it was one of the largest tables was hashing random IDs into another random ID, and we literally- Oofput only one. So it was translating, yeah, two random IDs hashed[00:28:36] swyx: into[00:28:37] Mikhail Parakhin: each. So, so[00:28:37] swyx: it has access to the code as well, so it can, it can check the, like what, what the hell is it doing?[00:28:42] Mikhail Parakhin: So there, there cou- it could be run in two levels. You, uh, you know, at the superficial level, it could just use ex-existing components and, uh, reshuffle them.Uh, you know, like you can grab- Yeah ... uh, XGBoost, and you can grab some, some Py- PyTorch module, and then can grab some, you know, grab another tools and, and combine them. At a deeper level, since Tangle is all sort of CLI based underneath you, every, every component is a wrapped really CLI, uh, call and a YAML file, it can analyze code and create new components and, and, uh, keep on iterating as well.So, so you can, you can both have quick modifications of existing t- uh, pipelines with the, with components that are already there pre-baked, or you can create new components, uh, and-[00:29:29] swyx: Yeah ...[00:29:29] Mikhail Parakhin: keep iterating on those. So auto research is, again, this is probably the, the thing I was excited the most in the last two months happening, and we see it taking like, like totally like a wildfire.Just, uh, everybody, every day, every... well, every day, every minute, I would, uh, have somebody Slack message saying, “Oh, look how much better I made it.” And, uh, it's all throughout the research.[00:29:53] swyx: Is this democratized in some way in, in the sense that like is it your ML, uh, engineers and researchers doing this, or is it your regular PMs and software engineers also have the ability to auto-- to use Tangent?[00:30:07] Mikhail Parakhin: This is an awesome question. Like, Tango in general and Tangent in particular are extremely democratizing. Like they- Yeah ... they are the main tools for- ‘Cause I don't[00:30:15] swyx: need the details.[00:30:16] Mikhail Parakhin: Yeah. Exactly. Initially used by ML and AI engineers, but then literally, as you said, PMs are like the highest user right now is one of PMs on our org, uh, Sartak and he was, he was number one by, by usage of, of this ‘cause they're just, uh, energetic and knowledgeable, and now it, it unlocks a lot of capability where you don't have to co-change code manually.[00:30:39] swyx: I mean, I mean, because it kind of cuts out the ML, ML engineer from the process because the, the, the PMs have the domain knowledge and the ability to think about, uh, from first principles about, okay, what, what results do I want? And they can-- they even have the access to the data that, that needs to go in.So it's like in some ways, like this is the magic black box that we've always wanted for, for training and, and for, uh, I guess, uh, uh, hill climbing, whatever.[00:31:04] Mikhail Parakhin: It's basically cloud code for your AI development- ... uh, situation, right? Like now, now you don't have to know exactly how algorithms work. You can just, uh, bring your domain knowledge and expertise and product knowledge and iterate within Tangent until you've gotten the results that you need.[00:31:21] swyx: In my previous roles, every time that someone has pitched AutoML, you know, I've always been like, “Uh, this is not, this is not gonna work. It's, you know, it's, it's always gonna be a flop.” Somehow it's working now. I mean, presumably the answer is now we have LLMs and it's good enough, right? It's, it's an emergent property that we can do auto research, but like, it doesn't feel that satisfying that how come we didn't do this before, right?Like we just did like parameter search and like, I don't know. That's maybe that's it.[00:31:48] Mikhail Parakhin: Yeah. Bayesian optimization and hyperparameter optimization was, was the one that, or facet of AutoML that was used very actively, which incidentally also built into, uh, Tango. But, you know, I know Patrice Simard very well, and, uh, he was such a, uh, such a proponent of AutoML, and he put, like literally spent careers trying to democratize it.Without LLMs, it just turned out to be very hard. Like it, you, you would have flexibility within certain narrow domain, but it was hard to wider scale, and now with LLMs suddenly it's like magic wand, and so suddenly everybody- ... is an AutoML expert.[00:32:28] swyx: Yeah, I, I think it's multiple things, right? Like I'm, I'm just gonna bring up the, the, the chart again, right?Like LLMs can do the monitoring very well. That is the very potentially unbounded, super unstructured. It can do the analysis very well, it can do the... Uh, and basically it is much more intelligence poured into every single step. Uh, there's maybe nothing structurally changed about AutoML, but this is just m-more intelligent and more unstructured.[00:32:53] Mikhail Parakhin: Exactly.[00:32:54] swyx: Any flaws that you've run into? Like everyone is like drinking the Kool-Aid, oh my God, time savings, uh, you know, performance improvements. Like what, what, uh, issues have you have, uh, come up?[00:33:06] Mikhail Parakhin: This is really cool. It's not a solution to all the world's problems for sure. The limitations are usually the ones I-- And this is where we get into a bit of a subjective territory.Uh, I can only share what I've, I've seen so far, and I'm sure the situation, uh, is changing, and, you know, maybe after I say it, like many people will reach out and say, “Hey, what about this?” And you don't know that, and then, then we'll be probably right. But what I've seen is auto research is very good at doing kind of obvious things that you don't have bandwidth to do or you didn't notice or maybe you're not aware of like the-- some standard practices.It is not good at doing something completely out of distribution, something that, you know, you have to think for, for multiple days, uh, and, and do something like none of this. So, so it's, uh, I, uh, set an experiment once, uh, on, on my sort of, uh, hobby thing, and I let it run for, uh, ended up, uh, several weeks run, uh, you know, it's like full production kind of scale, so it, you know, slow runs and, and it ex-- it performed in the end, uh, over four hundred experiments, and only one was successful.I'm like, “Okay, that's, that's good.” But-[00:34:18] swyx: But it saved time.[00:34:19] Mikhail Parakhin: Yeah, I saved time. Like it, it was the, that thing. Yeah, if I, if I were doing four hundred experiments myself, my betting average, as I said, would have been much higher, I'm sure. But also, first of all, it would take me like three years to do four hundred experiments.And, uh, I didn't have to do them. Like the machines were just, uh, the price of electricity did that. So, and I got one improvement, uh, that in, uh, my, my-- Honestly, when I was starting that experiment, my thinking was to go and show that, “Hey, Andre, maybe you just don't know how to optimize.” And I was super smart because in, in my pro-problem, it was optimized for many years, and it was like fully improved.Uh, and I didn't expect it, you know, auto research to find anything at all. Yet it did. So instead of making fun of Andre, I ended up, uh, a big, big supporter. Yeah, that's exactly the tweet. Yes.[00:35:10] swyx: You and Toby really, really go back and forth on-online a lot, which is really funny. Uh, think of it as, as an eval for the optimalness of the code it's running on.Uh, it's almost like it reminds me of like a Kolmogorov complexity thing, but, uh, I guess it's-- there's some optimal thing that you're trying to sort of reduce down to, I guess. Um, and so, so you, you, you know, you should congratulate yourself that you had, uh, you know, uh, ninety-nine percent, uh, optimality.[00:35:36] Mikhail Parakhin: Exactly, yeah. I think Andre really deserves a lot of credit for popularizing this approach. This is, uh, this is incredibly, I think, powerful and cool and You know, the, uh, even him, him just mentioning it led to a lot of gains in a lot of places in the industry, so we should be thankful.[00:35:56] swyx: Yeah. I think he also has a just...I don't know what it is. Like, um, you know, it, it is a simple self-contained project that people can take and apply to other things, which is, is, is one thing, but also just the name. Just like somehow no one, no one managed to call their thing auto research. It's just naming things is very important. I think that that is mostly, uh, our coverage of Tango and, and, uh, Tangents.I think obviously, you know, there's a lot of, uh, ML infra at, at Shopify that people can, uh, dive into. We're about to go into SimGym, but before I do that, any, any other sort of broader comments around this whole effort? Like where is it, where is it leading to?[00:36:36] Mikhail Parakhin: As a segue to SimGym, like all those things start composing strongly.And, uh, you could see a huge unlock when you can look at each one of the tools and, and you see, oh, they're extremely useful. Uh, Tango is useful by itself. Auto Research is useful by itself. SimGym is useful by itself. If you combine all three, you create like synergetic effect. I think that's why we wanted to even, uh, cover them today is because this is something that if you go back even, you know, five years ago, would've been unthinkable.Uh, replicating that, uh, would, would be either incredibly costly or impossible, right? With probably thousands of people are required.[00:37:20] swyx: Well, we have serverless human, uh, serverless intelligence, right? Like, uh, so yes, you do have thousands of hu-- of, of intelligences, not just, not humans. And that's, that's close enough, right?Even if they're not AGI, they're, they're close enough to do the, the task that you need them to do. And, and, you know, that's, there's plenty for, for a lot of routine work, knowledge work. Okay, let's get into SimGym. Um, this is one of those things I, I was surprised to see actually it's apparently your, uh, one of your most popular launches, and I think something that, uh, I think Sim AI, I think Yunjun Park, who did the Smallville thing, there's a very small cottage industry of people trying to do like the simulate customer thing.I think a lot of people maybe don't super trust this yet because they're like, well, obviously they would just do what you prompt them to do, right? But maybe just think, uh, tell us about the sort of inspiration or origin story.[00:38:10] Mikhail Parakhin: That's exactly actually the thing I wanted to cover, because if you don't have the historical data, all you can do is prompt a-agents in a vacuum, and they will do exactly what you prompt them to do.In fact, when I first proposed it, and this is a bit of, um, my brainchild initially, if I, I can boast, even Toby said like, “But wouldn't they, they just repeat what, what you tell them?” And, uh, but I'm like, “Yes, except Shopify has decades of history of how people made changes and what there is, uh, there, what it resulted in terms of sales.”So now what we can do is we can-- we have this... It's not, it's a noisy data. There's a small, usually websites, uh, you know, like things, things are never in isolation. It's almost never AB experiment. It's always AA experiment when there's has two meanings, but basically, you know, in different time you run two different things.But if you aggregate in general, uh, like everything together, and you apply, uh, denoising and collaborative filtering like approach, you can extract a very clear signal. And then you can optimize your agents. And that's why it took so long. It took almost a year of that optimization of just us sitting and fiddling, and, and we had this internal goals of correlation of hitting-- internal goal was to hit zero point seven correlation with, uh, add to cart events, for example.Like that, that if we run real AB test experiment, that it should, it should go and, and rep-uh, replicate, uh, same sort of success that, that humans had or lack thereof. And it, it took forever, and I don't think that's easily replicatable because, uh, like who else would have that data? You have to have this historic, you know, decades, uh, worth of data.And now, now the, like the other thing you need is in-infrastructure and the scale, right? Because, uh, w- again, what we found, uh, stat sig results, you need to run a lot of simulations, a lot of agents, and, and it's-- Those are expensive things. Like you're, you're making actions in the browser because you want a real friction.You want to, to be able to get the image like of what humans will see because you wanna, uh, detect effects like, “Hey, if I make my images larger, will I have more sales or l- uh, fewer sales?” And like usually people's intuition here, by the way, is that I increase my images, I will have more because they look nicer.You know, designers all look sparse and big images. Like usually your sales tank, right? But, but, uh, you know, from HTML, all the characters look the same only the, the size tag looks different, right? So it's very hard. So you have to take visual information, you have to run this in simulated browser environment on the big farm and, and of course, you have to have, uh, like very, very expensive model, good model with multi-model model.So all this it's-- is what's taken so long and, uh, to share my personal fail a little bit there, Sean, is like, you know, we always had this bias to-- for like large company bias. You know, we always, uh, whenever you-- we do, we're like, “Hey, we'll run an experiment,” right? We make, make a change, and we will run an experiment and then, uh, see, uh, see which one's better or like, “No, this is worse,” and most of them are worse, so you discard it and keep iterating, hill climbing.And we're like, “Oh, like smaller merchants, they cannot get stat sig results. They cannot really run experiments simply because, you know, in a week there would be not enough data for them.” So we thought from this perspective. What we didn't realize is that most people don't have A and B, they just have one thing, and they need suggestions of What A and B should be.So, uh, we first build this, hey, we run simulation on two separate teams and, and, uh, say, “Hey, which one is better?” We then morphed it into, and very recently just released it, when you have just your site, your theme, we run over it and we say, “Hey, here's what predicted values of, of, uh, uh, conversions are, and here's how we think you should modify it to increase your conversions.”And then circling back to what you started with, the proof is in the pudding. Like, if we are not correlating with reality, like, people will not be using it. And, uh, thankfully, we see literally every day more users than the previous day. So, so right now, uh, right now- It's working. Yeah. I'm-- Right now my problem is how to pay for it all because the so our major thing is how to optimize the LLMs, do distillation, how to run the headless browsers, uh, and handful browsers, uh, uh, cheaper so that we can accommodate the increase in traffic.[00:42:47] swyx: Yeah. I, I understand that you, uh, you published a lot of technical detail at GTC, so I was just gonna bring it up a little bit. I think s- was this in, in con-conjunction with some kind of GTC presentation? Or something like that, right?[00:42:59] Mikhail Parakhin: Well, we, yeah, we, we did it in several place, but yeah, we had the engineering- Yeahblog, uh, as well. Yeah.[00:43:05] swyx: Yeah. So you're running, uh, GPT OSS. Uh,[00:43:08] Mikhail Parakhin: the, this is an older version. You know, now we run multimodal model. But yeah- Yeah ... GPT OSS, we still run GPT OSS as well for[00:43:15] swyx: And then you have the VMs, and you also have browser-based. I really like this one where it you said, “It violates almost every assumption that standard LLM serving is designed for.”And then you had like, basically orders of magnitude differences between everything.[00:43:29] Mikhail Parakhin: Exactly. Which is, which, uh, which was, you know, a bit of a challenge to implement, like when, like even simple things. Uh, be- since it violates all the assumptions, for example, multi-instance GPUs, like MIGs don't work as well.But we needed, uh, to get MIG to work because, ‘cause otherwise it's way too expensive. And so we had to deal with the, yeah, with, uh, lots of infrastructure and, and, uh, work with, uh, uh, Fireworks and CentML, uh, you know, to help with optimizations and browser-based, as you mentioned. Yeah, like, takes a village.[00:44:04] swyx: Okay. So there's a lot of like, I guess, experimentation in the infrastructure so far, and you've published more or less what you have here. I guess I'm, I'm less familiar with CentML. I, I don't do, uh, that much work in this, this part of the stack. But why was it the sort of preferred instance platform?[00:44:22] Mikhail Parakhin: There are really three probably top companies. There used to be, uh, uh- Three top companies, uh, at least I was aware of that did, uh, LM optimization. You know, together Fireworks and Santa ML, not necessarily in that order. Santa ML recently got acquired by NVIDIA. Uh, what they did is if you have a model and you want to optimize it to a specific prof-- uh, profile of usage, uh, they would go and do it.And, uh, we work with, with those companies, uh, this was work particularly in with Santa ML and NVIDIA to get them the best possible results out of it. And, and sometimes you, you have to retune depending on, like sometimes you want the maximum throughput, sometimes you want minimal latency, sometimes you want like the cheapest, right?And, yeah, or some combination. And so yeah, these are people who would come and help you.[00:45:14] swyx: I see. I see. Yeah, yeah. I'm familiar with these people for the LLM, you know, autoregressive stack. But the other interesting category of these optimizers is also the diffusion people, whereas like Fel and, you know, uh, Pruna recently has come up a lot as well, which I think is like really underappreciated, uh, at least by myself, because I, I thought, oh, all the workload would be LLMs, but actually there's a lot of diffusion as well.[00:45:38] Mikhail Parakhin: Exactly.[00:45:38] swyx: There's a lot here, so I, I, I... it's, it's, uh, it's, it's, it's hard to cover. But I, I do think like people underappreciate the importance of customer simulation, basically. I think this is something that I'm candidly still getting to terms with. Uh, you know, uh, you also-- your team also like prepared this, like, really nice diagram.Uh, I, I assume this is AI generated.[00:46:00] Mikhail Parakhin: Yeah, it looks-[00:46:01] swyx: Maybe it's not.[00:46:01] Mikhail Parakhin: Yeah, it looks, uh, Gemini-ish. Yeah, but, uh, uh, honestly, I, I don't know where, where the hell they generated. It looks, look, uh, looks like it's, uh, Google. But the interesting part, John, that, that, uh, we haven't covered, but I, I wanted to mention is if your store had previous customers, rather than it's a new store, you're like new merchant just launching things, it helps tremendously in just correlation and forecast.Yeah, we take your previous, uh, customer's behavior, and we create agents that replicate those specific distribution of, of customers that you get, and then we a- we apply those to your changes, and then that, that raised raw, you know, the re-- uh, just correlation with the add to cart events or to-- with conversion or whatever it, it, it may be, uh, quite dramatically.So, uh, replicating humans in general seems like an interesting, cool challenge.[00:46:58] swyx: As a shareholder, I think this is the-- like if people are Shopify shareholders, they should really deeply understand this because this is basically the moat. The, the more you use Shopify, the more it will just automatically improve, right?Like you're, you're doing the job for them.[00:47:13] Mikhail Parakhin: Yeah, that's what we started with. Like, uh- ... uh, otherwise, if you're just a startup, I wouldn't do it if, uh, you know, if it was my startup because Without the data, it, yeah, as, as you said, it's, it's exactly the case that, uh, whatever you say in prompt, that's, that's what the agents will be doing.[00:47:30] swyx: The statistician in me wants to like really satisfy the sort of, um, statistical intuition, I guess. Um, to me it's kind of, uh, the, the word that comes to mind is, um, ergodicity. Uh, so let's say a, a customer takes this path, customer takes this path, customer takes this path, right? Um, the... In my mind, the way I explain it is like, okay, here, here's the ninety-five percentile, here's the five percentile, and here's the median, right?Um, but to me, what SimGym is potentially doing is that it can, uh, modify... It can sort of model the sort of in-between sort of journeys as well, that, that maybe are dependent on the previous states. This may be like a very RL-type conclusion where like basically the summary statistics, if you only did naive AB testing, you only have the, the statistics at, at, at a certain point, and you only judge based on the sort of overall summary statistics.But here you can actually model trajectories. Does that make sense? Or-[00:48:31] Mikhail Parakhin: That makes total sense because like, well, that, that makes even more sense that maybe even you realize bec- because-[00:48:38] swyx: Okay. Please,[00:48:38] Mikhail Parakhin: please. Yes ... we do-- Yeah. The, so internally, uh, we have this system, we talked about it briefly once at NeurIPS.We have a huge HSTU-based system that models the whole companies, uh, and their possible paths. And like- Yeah ... what you are, what you are showing, like actually at any point of time, you can either model the user's behavior or you mo- can also think about, uh, the whole merchant as a company, as the entity that acts in the world.You can model that as well. And then you can do, can do counterfactuals. In your graph, like in your blue graph, uh, if you're... Imagine in the center there, uh, somewhere in the middle, you would have an intervention. I give that person a coupon, or I don't know, I send a personal thank you card, or give a discount in some- somewhere.And then you can, uh, then you can do forward rollouts from that counterfactual. So what would have happened with that intervention or without the intervention? And you can even ch- change where that intervention, uh, in time can happen, right? Like some- where, where in this journey. So we, we do this at the Shopify scale for our merchants, and then if we notice that something that they can be fixing, like there's a strong counterfactual, like we have Shopify policy, they basically get a notification like, “Hey, we think your...something is wrong with your-” I don't know, Canadian sales. Like, uh, it looks like it's misconfigured. Here's what you need to do. Or do you think like, uh, you have to set up this campaign with these parameters? And we do that at the buyer level to literally offer discounts or cashback or, or things to buyers.So this is-- I'm getting very excited. Like this is my sort of area of, uh, interest, I guess, and, and hobby. But being able to m-model something complex as human beings or companies and model counterfactuals on it, where you can have interventions in the future and optimize when to make intervention, what kind inter-- uh, what kind of intervention to make.It's such an unlock that previously was completely impossible. Like the-- it was, it was always dreamed of, but never... Like how would you even simulate it without LLMs or HTUs? I think very, very exciting times.[00:50:59] swyx: I just wanted to, uh, to maybe illustrate this. I, I'm not the best illustrator, but I, I am a conceptual statistics guy.And y-you know, you cannot just do this. Like this is a dimensionality AB test doesn't do, right? Like, uh, because it doesn't have the, the, the change over time, uh, stochastic nature, uh, and it doesn't have the sort of contextual like... Here's all the context to this point. Um, okay, cool. Um, that's SimGym.You're, you're gonna burn a lot of tokens on this thing. But you're, you're one of the, the only scale platforms in the world that can, uh, that can do this across a huge variety of workloads, right? I'm even curious on a sort of human, uh, research level of like, well, do, does retail behave d-differently from like clothing sales?D-does that behave differently from electronic sales? I, I don't know. I don't know what else you guys... The Kardashian shoppers, do they differ from like people who buy, uh, I don't know, cars and, uh, whatever.[00:51:55] Mikhail Parakhin: Well, very different, and different sensitivities and different modes of, uh, shopping and, and different levels of what's important.Now, to-totally, you can do aggregations at, uh, at a store level. You can do aggregations at a different, uh, category level. I don't know if, uh, you know, for our statisticians among us, I couldn't believe, but we-- recently we're looking at it, and we had to bring back, uh, CRPs, you know, Chinese restaurant process.It's a, like, way of aggregating and, like, naturally grow clustering. So across... Specifically to answer questions that, uh, like you were just posing on how, how if, if buyers behave different categories. And I'm like, “I haven't seen CRP since two thousand and one.” It's[00:52:37] swyx: so What? It's so- What is... No, I haven't, I haven't seen this.No. This is not in my training. Uh,[00:52:44] Mikhail Parakhin: but, but yeah, it, uh, uh, it actually, like the, the-- there was a very popular kind of theory, popular neurips HTML circles in early two thousands, uh, kind of nice. And now, now it has practical applications, uh- Yeah ... that we were resurrecting.[00:53:03] swyx: Yeah, amazing. Uh, I, I can see, I can see how this is like a, uh, a fun job for you where you get to apply all these things.Um, yeah, yeah, so super cool. Super cool. So, okay, so, so anyone who, who knows what CRPs are and has always wanted to use them at work, uh, they should, they should definitely join Shopify. Okay, so w-we have a lot and but I, I'm, I'm being mindful of the time. I, I do wanted to, to sort of cover some other things.Um, I-I'll give you a choice, UCP or Liquid?[00:53:30] Mikhail Parakhin: Liquid. I think, I think on UCP, you know, like UCP is very important for us and, and it just we are-- UCP, we have a structured, uh, discussions, and you can read about them, and we have, uh, blog posts, and we have a big release this week, in fact, like with our catalog.Oh,[00:53:46] swyx: okay.[00:53:46] Mikhail Parakhin: Uh, yeah,[00:53:46] swyx: but- Le-I mean, we, we can, we can discuss the, the, the release briefly because we'll release this after the-- after it's already announced so whatever. There's a catalog that you guys are doing?[00:53:55] Mikhail Parakhin: Yeah. So we are, we are- Okay ... we are bringing in capabilities of a whole, uh, Shopify catalog.Basically, you now you can search for products, you can do lookups by specific ID, you can do bulk lookups when you need to bring m-multiple products. You don't need to know in ad-in advance what you're trying to show or to sell or check out. Like, you can now, you can now have this decided at, at runtime, and this big area for investment for us for both non-personalized and personalized searches, trying to provide basically a win-window into whole universe of products that are being sold everywhere in the world.And Shopify is really not exactly, but almost like a super set of any-anything being sold. Now we are bringing it into UCP and, uh, and, uh, identity linking is another big thing for us, uh, so that you, you can use, uh, like Google or whatever, whatever identity you have, uh, they're minimizing friction.[00:54:56] swyx: Yeah. So[00:54:57] Mikhail Parakhin: yeah, big release for us.But Liquid AI of course we never talk about, and the problem might be more, more aligned with what we d-discussed previously on this chat.[00:55:07] swyx: Sure. The main thing that everyone understands about Liquid is that it is inspired by Worm, and I still don't know why. I'm curious on your explanation. I think you, you, uh, you can make things very approachable.And also I think like what is the potential of like the, the level of efficiency that you get out of Liquid?[00:55:23] Mikhail Parakhin: You- we all familiar with transformer architectures. And, uh, for the longest time, there was a competing architecture, it's called the state space models. So, so Sams, uh, you know, Chris, Chris Reyes, one of the pioneers and, and lots of startups, uh, trying to make those realities.They have, uh, significant benefits being main being, uh, being much faster and, uh, lower footprint and not quadratic in length, you know, sort of, uh, linear in, in, uh, in your context length. But with state space models- They never quite made it. Like they're used-- They have, uh, certain niches when they thrive, their hybrid architectures are useful, but they never quite made it.And liquid neural networks are, you can think of them as a next step, like, uh, sort of, uh, state-space model square. It's non-transformer architecture that's more complicated than sta-state space and really difficult to code if you-- if I'm being honest. But it's, um, very efficient. It's, uh, subline-- sub, uh, quadratic in, in length of your context.Uh, it's very compact way to represent things, and that's a liquid AI company. They... Their goal is to productize it, and very often you have this need, uh, when you need to have long context and small model, and you want to have low latency. Like in general, it's basically on par with transformers, and if you do hybrids with transformers, it's, it's even better.That's why we at Shopify, when we tried multiple and we constantly try multiple models, multiple companies, we found that for small, particularly with low latency applications, when you have low latency and/or if you need longer context lengths, liquid was the best. And so we still use the whole zoo and always like obviously test and use everything, uh, every open source model and, you know, it feels l

On this week's Security Sprint, Dave and Andy covered the following topics:Opening:• TribalHub Regional Tribal Technology Forums• WaterISAC H2OSecCon 2026. Virtual Event: 02 Jun, 11am-5pm ET Overview, Registration, Agenda, Speakers• Offensive AI: What Red Teams and Attackers are Doing Now - Gate 15Main Topics:Vercel April 2026 security incident Vercel 20 Apr 2026. Vercel said it identified unauthorized access to certain internal systems and initially found a limited subset of customers whose credentials were compromised. The company said the incident originated with a compromise of Context.ai, a third-party AI tool used by a Vercel employee, which then enabled takeover of that employee's Google Workspace account and access to some Vercel environments and non-sensitive-marked environment variables. Vercel said services remain operational, law enforcement has been notified, and customers who were not contacted are not currently believed to have had credentials or personal data compromised. Vercel is a cloud platform used for frontend hosting, serverless functions, and deploying websites, particularly those built with React or Next.js. It enables developers to easily build high-performance, edge-optimized applications. Key features include automatic Git integrations (CI/CD) for instant deployments, preview environments, and edge storage. • Vercel confirms breach as hackers claim to be selling stolen data • Breaking: Vercel Breach Linked to Infostealer Infection at Context.ai • Vercel's security breach started with malware disguised as Roblox cheatsWiz: 80% of cloud breaches are caused by basic mistakes - IT Pro - 13 Apr 2026 IT Pro reports that Wiz Threat Research found most cloud breaches in 2025 were driven by familiar security mistakes rather than entirely new vulnerability classes, with AI expanding the places where known risks can appear. The article frames the problem around scale, shared trust, and increasingly complex cloud and AI environments rather than exotic attack novelty. Target is cloud security teams, platform engineers, and enterprise risk leaders with Dig highlighting that basic exposure management, identity control, and configuration discipline remain the decisive factors in many modern cloud compromises. Fire As An Act Of Sabotage Guidance UK National Protective Security Authority 25 Sep 2024. The NPSA guidance outlines how to mitigate the risk of deliberate fire-setting used as sabotage against premises and infrastructure that may be attractive targets. Although not new, it remains operationally useful because it provides protective security and risk management guidance for owners and operators responsible for physical sites and critical functions. The relevance is heightened in an environment where sabotage, arson, and hybrid disruption are increasingly discussed alongside state and extremist threat models. From tabletop reality 10 gaps executive cyber exercises consistently reveal - SANS Institute - 2026 This analysis identifies recurring gaps observed during executive cyber exercises, including communication breakdowns and decision-making delays. It highlights the importance of realistic training scenarios to improve organizational readiness. The findings provide actionable insights for strengthening incident response at the leadership level. • Critical infrastructure resilience escalated threat navigation initiative - Canadian Centre for Cyber Security • Preparing for severe cyber threat why leaders must act now - NCSC UK • CISO Survey 2026: The State of Incident Response Readiness Quick Hits:• The State of Ransomware in Q1 2026 - Emsisoft • Safeguarding Our Data, Intellectual Property, and Technology from Non-traditional Collectors

AI coding tools are helping teams move faster than ever, but there's a hidden cost. In this episode, we break down new insights from a DevOps industry report revealing a growing "velocity paradox": teams are shipping more code, but experiencing more failures, rollbacks, and burnout. You'll discover why AI adoption is heavily skewed toward coding, but not testing, pipelines, or observability, and how that imbalance is creating fragile systems that break under pressure. More importantly, you'll learn what high-performing teams are doing differently to maintain quality while scaling speed. What You'll Discover: ✔️ Why AI is increasing deployment failures (and how to stop it) ✔️ The "velocity vs quality" trap hurting modern DevOps teams ✔️ How to reduce flaky tests and pipeline instability ✔️ Why observability and feature flags are now critical, not optional ✔️ Practical ways to improve your CI/CD pipeline for AI-driven development ✔️ The role of QA engineers in the age of AI (and why it's growing, not shrinking) If you're a tester, automation engineer, or DevOps leader trying to keep up  

This is episode 322, recorded on April 8th, 2026, where John and Jason dig into the keynote announcements from FabCon Atlanta — including SharePoint list mirroring into OneLake, Excel-to-Delta table shortcuts, major CI/CD improvements like selective branching and the Fabric CLI, the new Database Hub giving you a single pane of glass across your entire database estate, and a brand new Planning workload built right into Fabric. For show notes please visit www.bifocal.show

Is it time to replace GitHub in our workflow? We git into it. Plus, our favorite features in the new Linux 7.0 release.Sponsored By:Jupiter Party Annual Membership: Put your support on automatic with our annual plan, and get one month of membership for free!Managed Nebula: Meet Managed Nebula from Defined Networking. A decentralized VPN built on the open-source Nebula platform that we love.Support LINUX UnpluggedLinks:

Nate Amidon: Why Scrum Master Success Means Owning the Entire Idea-to-Deployed Pipeline Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Success for a Scrum Master is maximizing value of the product through the organization. That's a full stop statement." - Nate Amidon   Running a company of contract Scrum Masters gives Nate a unique perspective on what success actually looks like. For him, it comes down to one thing: are you increasing the value of the product through the system? Everything else is either a leading or lagging indicator. Practically, this means starting with the most fundamental question: why does your team exist? Nate suggests asking three team members separately what the team does and who they do it for — and checking whether the answers match. Once you have clarity on purpose, you can work with product and the organization to figure out how to measure whether you're getting closer. But here's where Nate pushes boundaries: he believes a Scrum Master's scope isn't limited to the Scrum team. If success is measured by value flowing through the system, then you have to take ownership of the entire idea-to-deployed pipeline — product prioritization, cross-team dependencies, QA processes, CI/CD, release schedules. You happen to work as a Scrum Master on a team, but your responsibility extends to anywhere value gets stuck.   In this episode, we refer to Vasco's OTOG (One Team, One Goal) principle and Nate's previous episode about the brief-execute-debrief cycle.   Self-reflection Question: If someone asked three different members of your team what the team exists to do and who they do it for, would the answers match — and have you checked recently? Featured Retrospective Format for the Week: Meme Retro Nate's favorite retrospective format might surprise you: the Meme Retro. Give everyone 5-10 minutes to find a meme on the internet that describes the last sprint. Then go around the room, share the meme, and explain why you chose it. It sounds lighthearted — and it is — but that's exactly the point. As Vasco notes, "laughs per minute" is a great metric for retros, because when people are laughing, they can talk about serious issues without defensiveness. The memes give a different angle on what happened during the sprint, surfacing deeper feelings and patterns that traditional formats might miss. It's especially useful when teams are getting fatigued from running the same retro format over and over.   [The Scrum Master Toolbox Podcast Recommends]

Security problems aren't changing very much even though security teams are. We catch up on the implications of the Claude Code source leak, the very human lessons from the axios NPM compromise, and what secure design looks like when it involves agents, humans, or both. AppSec has always celebrated interesting and impactful vulns. And LLMs are now a favored tool for finding flaws. We shouldn't forget the success and effectiveness of fuzzers like OSS-Fuzz, which has improved security for over 1,000 projects and found over 50,000 bugs. But we can't ignore the ease of prompting an agent to go find -- and exploit -- a vuln when the UX and overhead of doing so is hardly more than writing some markdown. The SDLC Blind Spot: Why Breaches Start with Identity, Not Code Developers have access to source code, CI/CD pipelines, and cloud infrastructure — and attackers know it. Target lost 860GB of source code through a single compromised credential. Recruitment fraud campaigns have pivoted from a compromised developer to cloud admin in under 10 minutes. As agents join human developers, contractors, and service accounts in the SDLC, the attack surface is expanding faster than static security tools can track. Security teams need real-time visibility beyond code and into who has access and what they're actually doing. This segment is sponsored by Apiiro. To lean more, visit https://securityweekly.com/apiirorsac. How AI-Driven Development is Reshaping the Application Risk Landscape Agent coding assistants are accelerating software development, generating more code and more change than security teams were built to handle. In this interview, Idan Plotnik discusses how AI-driven development is reshaping the application risk landscape and why traditional vulnerability management models can't keep up. Make sure to schedule a free SDLC Risk Assessment with BlueFlag Security - 30 minutes to deploy. 48 hours to results. Please visit https://securityweekly.com/blueflagrsac. Visit https://www.securityweekly.com/asw for all the latest episodes! Show Notes: https://securityweekly.com/asw-377

Michael Irwin of Docker joins me to run through Gordon AI improvements, Docker Hardened Images and what's now free, Docker Sandboxes for running agents in proper isolation, Model Runner updates including MLX support on Mac, MCP Toolkit dynamic discovery, and the newly renamed Docker Agent with its GitHub Action for automating PR reviews and docs checks.Check out the video podcast version here: https://youtu.be/dTF3b36Bq6w

Security problems aren't changing very much even though security teams are. We catch up on the implications of the Claude Code source leak, the very human lessons from the axios NPM compromise, and what secure design looks like when it involves agents, humans, or both. AppSec has always celebrated interesting and impactful vulns. And LLMs are now a favored tool for finding flaws. We shouldn't forget the success and effectiveness of fuzzers like OSS-Fuzz, which has improved security for over 1,000 projects and found over 50,000 bugs. But we can't ignore the ease of prompting an agent to go find -- and exploit -- a vuln when the UX and overhead of doing so is hardly more than writing some markdown. The SDLC Blind Spot: Why Breaches Start with Identity, Not Code Developers have access to source code, CI/CD pipelines, and cloud infrastructure — and attackers know it. Target lost 860GB of source code through a single compromised credential. Recruitment fraud campaigns have pivoted from a compromised developer to cloud admin in under 10 minutes. As agents join human developers, contractors, and service accounts in the SDLC, the attack surface is expanding faster than static security tools can track. Security teams need real-time visibility beyond code and into who has access and what they're actually doing. This segment is sponsored by Apiiro. To lean more, visit https://securityweekly.com/apiirorsac. How AI-Driven Development is Reshaping the Application Risk Landscape Agent coding assistants are accelerating software development, generating more code and more change than security teams were built to handle. In this interview, Idan Plotnik discusses how AI-driven development is reshaping the application risk landscape and why traditional vulnerability management models can't keep up. Make sure to schedule a free SDLC Risk Assessment with BlueFlag Security - 30 minutes to deploy. 48 hours to results. Please visit https://securityweekly.com/blueflagrsac. Show Notes: https://securityweekly.com/asw-377

Security problems aren't changing very much even though security teams are. We catch up on the implications of the Claude Code source leak, the very human lessons from the axios NPM compromise, and what secure design looks like when it involves agents, humans, or both. AppSec has always celebrated interesting and impactful vulns. And LLMs are now a favored tool for finding flaws. We shouldn't forget the success and effectiveness of fuzzers like OSS-Fuzz, which has improved security for over 1,000 projects and found over 50,000 bugs. But we can't ignore the ease of prompting an agent to go find -- and exploit -- a vuln when the UX and overhead of doing so is hardly more than writing some markdown. The SDLC Blind Spot: Why Breaches Start with Identity, Not Code Developers have access to source code, CI/CD pipelines, and cloud infrastructure — and attackers know it. Target lost 860GB of source code through a single compromised credential. Recruitment fraud campaigns have pivoted from a compromised developer to cloud admin in under 10 minutes. As agents join human developers, contractors, and service accounts in the SDLC, the attack surface is expanding faster than static security tools can track. Security teams need real-time visibility beyond code and into who has access and what they're actually doing. This segment is sponsored by Apiiro. To lean more, visit https://securityweekly.com/apiirorsac. How AI-Driven Development is Reshaping the Application Risk Landscape Agent coding assistants are accelerating software development, generating more code and more change than security teams were built to handle. In this interview, Idan Plotnik discusses how AI-driven development is reshaping the application risk landscape and why traditional vulnerability management models can't keep up. Make sure to schedule a free SDLC Risk Assessment with BlueFlag Security - 30 minutes to deploy. 48 hours to results. Please visit https://securityweekly.com/blueflagrsac. Visit https://www.securityweekly.com/asw for all the latest episodes! Show Notes: https://securityweekly.com/asw-377

Andrew welcomes back Dual MVP and Intune aficionado Hailey Phillips for a wide-ranging conversation covering her project IntuneStack, the value of DevOps principles in endpoint management, and the mindset behind consistent skill-building. The two dig into conference culture, the importance of community, mentorship, and why showing up every day — even for just ten minutes — matters more than waiting for inspiration to strike. Key Takeaways: IntuneStack in action: Hailey's CI/CD-influenced PowerShell project manages Intune policy deployment across dev, test, and prod groups using promotion gates rather than expensive separate tenants — a more resilient, consistent, and auditable approach to endpoint management. Consistency over inspiration: Whether it's PowerShell, the gym, or mentoring, Hailey's philosophy is the same: stop waiting to feel motivated and just start small. Ten minutes a day compounds over time, and momentum is something you build, not something you wait for. Community is a career asset: Conferences like PowerShell Summit and PSConfEU aren't just about the sessions — they're about building a support system. Having people who can sanity-check your thinking is one of the most underrated advantages in a tech career. Guest Bio: Hailey Phillips is a Systems Engineer, Microsoft MVP, and Professional Pokémon Trainer. She specializes in automation, endpoint management, and modern workplace strategy, bridging the gap between traditional IT and DevOps. Hailey's work focuses on building pragmatic, scalable solutions using tools like PowerShell, Microsoft Graph, Intune, and Azure Arc. When she's not deep in tech, you'll probably find her skiing in the Cascades, lifting heavy things, or at a metalcore show with a strong cup of coffee in hand. Resource Links: Intune Stack on GitHub - https://github.com/AllwaysHyPe/IntuneStack Practical Automation with PowerShell by Matthew Dost - https://www.manning.com/books/practical-automation-with-powershell GliderUI Cross-platform GUIs - https://github.com/mdgrs-mei/GliderUI PDQ Discord - https://discord.gg/pdq Hailey Phillips Website - https://www.allwayshype.com/ Connect with Andrew - https://andrewpla.tech/links The PowerShell Podcast on YouTube: https://youtu.be/L97ePN7UtGY

Guest: Dan Lorenc, Founder / CEO, Chainguard Topics: We just saw a security tool (Trivy) get used to pop an AI infrastructure tool (LiteLLM) to eventually pop end users. Have we reached the point where our security tooling is actually our largest unmanaged attack surface?  Why now? Software supply chain security had the perennial vibe of "not top concern" for most organizations, right? TeamPCP pushed malicious code to existing GitHub tags. We've been screaming about pinning versions to SHAs for years, but clearly, nobody is listening. Is it time to admit that 'convenience' is the primary enemy of supply chain security? The Axios incident showed a victim compromised in under two minutes. In a world of auto-updating dependencies, is the concept of a human-in-the-loop for software updates officially dead, or do we need to look very hard at version pinning and such? With XZ Utils case, we saw a long-game social engineering attack. Beyond just 'watching npm closely,' what are the realistic architectural safeguards for an org that knows they can't audit every line of an update? We've spent the last three years talking about SBOMs (Software Bill of Materials) like they were a pill for supply chain health. But if the scanner producing the SBOM is the one that's compromised, isn't the SBOM just a signed receipt for your own house being on fire?  What is the one practical thing they can do to ensure their CI/CD isn't a credential-exfiltration-as-a-service platform? Resources: Video version North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack EP100 2022 Accelerate State of DevOps Report and Software Supply Chain Security EP116 SBOMs: A Step Towards a More Secure Software Supply Chain EP226 AI Supply Chain Security: Old Lessons, New Poisons, and Agentic Dreams EP24 Linking Up The Pieces: Software Supply Chain Security at Google and Beyond Matt Levine blog

Cisco Source Code Stolen in Trivy Fallout, Axios Supply Chain Attack, and Active Exploitation of Fortinet and Citrix Flaws David Shipley reports multiple major security incidents: attackers used credentials stolen in the Trivy supply-chain attack via a malicious GitHub action to breach Cisco's internal development environment, clone 300+ GitHub repos, steal source code (including AI products) and AWS keys, and impact customer-related code; Cisco contained the breach, re-imaged systems, and rotated credentials. A separate supply-chain attack hit the widely used JavaScript library Axios after its maintainer account was compromised, pushing poisoned NPM versions that installed a dropper/RAT via a fake dependency; users are told to downgrade affected versions, remove the dependency, rotate credentials, and review CI/CD logs. Active exploitation is confirmed for a Fortinet FortiClient EMS SQL injection (CVE-2026-21643) and for critical Citrix NetScaler flaws (CVE-2026-3055, possibly alongside CVE-2026-4368). Anthropic accidentally exposed details of a new model, "Code Mythos," described as highly capable in reasoning, coding, and cybersecurity. Finally, TechCrunch reports escalating allegations that compliance startup Delve helped fabricate audit evidence and worked with weak auditors. The episode also marks show episode 1,500. 00:00 Headlines and Sponsor 00:54 Cisco Trivy Breach 02:28 Axios NPM Attack 04:12 Fortinet SQLi Exploited 06:24 Citrix Bleed Returns 08:05 Anthropic Model Leak 10:24 Fake Compliance Scandal 12:30 Episode 1500 Milestone 14:03 Sponsor Closing Message

Mobile test automation is still one of the biggest bottlenecks in modern software delivery. In this interview, QApilot's Co-founder Aditya Challa explains why most AI testing approaches fail and how to fix them. Learn more about QApilot: https://links.testguild.com/flutterqa If your mobile tests are flaky, slow, or hard to trust, you're not alone. Most teams are trying to apply LLM-based AI to problems that actually require deterministic reliability—and that's where things break down. In this video, you'll learn: Why mobile test automation breaks at scale The real issue with "99% accurate" AI in testing LLMs vs deterministic AI (and why it matters for mobile apps) How flaky tests destroy confidence in your pipeline How QApilot approaches mobile testing differently What reliable, scalable mobile automation should look like What this means for you: Fewer false positives, faster releases, and mobile tests you can actually trust. 00:00 Why Mobile Test Automation Is Still Broken 01:10 QApilot Overview 01:51 Why Mobile Testing Tools Fail 03:13 Why Appium Isn't Enough 05:09 QApilot's Approach to Mobile Testing 07:10 Scaling Mobile Testing Across Devices 08:02 Autonomous Testing + Human in the Loop 10:55 How QApilot Works (Architecture + Agents) 13:45 Real Example: Mobile App Crawling in Action 16:31 Finding Bugs Automatically (Performance + Accessibility) 18:52 Device Farms & Real Device Testing 21:50 Future of Mobile Testing (SRE + AI + Quality Layer) 27:06 Real Customer Results & Case Study 31:02 Why QApilot Focuses Only on Mobile 34:04 Where QApilot Fits in CI/CD 36:00 How to Try QApilot + Final Advice

Yuval Avrahami from Wiz joins to share their work on "CodeBreach: Infiltrating the AWS Console Supply Chain and Hijacking AWS GitHub Repositories via CodeBuild." Wiz Research uncovered “CodeBreach,” a critical supply chain vulnerability caused by a subtle misconfiguration in AWS CodeBuild pipelines that allowed attackers to take over key GitHub repositories, including the widely used AWS JavaScript SDK that powers the AWS Console. By exploiting an unanchored regex filter, unauthenticated attackers could trigger privileged builds, steal credentials, and potentially inject malicious code into software used across a majority of cloud environments. AWS has since remediated the issue and introduced stronger safeguards, but the incident highlights a growing trend of attackers targeting CI/CD pipelines where small misconfigurations can lead to massive downstream impact. The research can be found here: CodeBreach: Infiltrating the AWS Console Supply Chain and Hijacking AWS GitHub Repositories via CodeBuild Learn more about your ad choices. Visit megaphone.fm/adchoices