The Pragmatic Engineer

From Swift to Mojo and high-performance AI Engineering with Chris Lattner

The Pragmatic Engineer

Show Notes

Brought to You By: •⁠ Statsig ⁠ — ⁠ The unified platform for flags, analytics, experiments, and more. Companies like Graphite, Notion, and Brex rely on Statsig to measure the impact of the pace they ship. Get a 30-day enterprise trial here. •⁠ Linear – The system for modern product development. Linear is a heavy user of Swift: they just redesigned their native iOS app using their own take on Apple’s Liquid Glass design language. The new app is about speed and performance – just like Linear is. Check it out. — Chris Lattner is one of the most influential engineers of the past two decades. He created the LLVM compiler infrastructure and the Swift programming language – and Swift opened iOS development to a broader group of engineers. With Mojo, he’s now aiming to do the same for AI, by lowering the barrier to programming AI applications. I sat down with Chris in San Francisco, to talk language design, lessons on designing Swift and Mojo, and – of course! – compilers. It’s hard to find someone who is as enthusiastic and knowledgeable about compilers as Chris is! We also discussed why experts often resist change even when current tools slow them down, what he learned about AI and hardware from his time across both large and small engineering teams, and why compiler engineering remains one of the best ways to understand how software really works. — Timestamps (00:00) Intro (02:35) Compilers in the early 2000s (04:48) Why Chris built LLVM (08:24) GCC vs. LLVM (09:47) LLVM at Apple (19:25) How Chris got support to go open source at Apple (20:28) The story of Swift (24:32) The process for designing a language (31:00) Learnings from launching Swift (35:48) Swift Playgrounds: making coding accessible (40:23) What Swift solved and the technical debt it created (47:28) AI learnings from Google and Tesla (51:23) SiFive: learning about hardware engineering (52:24) Mojo’s origin story (57:15) Modular’s bet on a two-level stack (1:01:49) Compiler shortcomings (1:09:11) Getting started with Mojo (1:15:44) How big is Modular, as a company? (1:19:00) AI coding tools the Modular team uses (1:22:59) What kind of software engineers Modular hires (1:25:22) A programming language for LLMs? No thanks (1:29:06) Why you should study and understand compilers — The Pragmatic Engineer deepdives relevant for this episode: •⁠ AI Engineering in the real world • The AI Engineering stack • Uber's crazy YOLO app rewrite, from the front seat • Python, Go, Rust, TypeScript and AI with Armin Ronacher • Microsoft’s developer tools roots — Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [email protected].

Get full access to The Pragmatic Engineer at newsletter.pragmaticengineer.com/subscribe

More from The Pragmatic Engineer

Oct 21, 2026

Brought to You By: • turbopuffer – a vector and full-text search engine built on object storage. It’s fast, cheap, and extremely scalable. • Entire – Git hosting, rebuilt for the agentic era. Every agent session, prompt and tool calls: stored in your repo. • Antithesis – verify your system’s correctness without human review or traditional integration tests – and avoid bugs or outages. — What’s changed in “the unwritten rules” of engineering management since the 2010s, what drove the shift to today, and what has it done to the engineer-to-CTO career path? Today’s guest is one of the best people I know who can tackle these questions. Will Larson is CTO of Imprint, was an engineering executive for 10+ years, and is the author of several popular books on engineering leadership, including ‘The Engineering Executive's Primer,’ ‘Staff Engineer, An Elegant Puzzle,’ and ‘Crafting Engineering Strategy.’ Previously, he was also CTO at Carta and Calm, and an engineering leader at Stripe and Uber. In this episode, we explore how engineering leadership has evolved from management practices shaped in the long post-financial-crisis ZIRP era to the altered expectations of engineers and managers today. Is middle management an increasingly precarious career path, and might managers need to reskill and return to hands-on technical work – or even consider retirement? Will makes the case, and we hear why the traditional path to engineering executive roles is changing, as well as why taking one step backward might sometimes be the best way forward. We discuss Will's early career, and get his first-hand account of Digg's disastrous relaunch, his own path to CTO, and he tells us why career ladders still matter. We also explore how AI is changing engineering roles and bringing technical decision-making back to leadership. Timestamps 00:00 Intro 08:20 Stories from Yahoo! 12:47 Digg’s v4 rewrite: the insider story 26:02 Will’s path to eng leadership 30:03 Uber, Stripe, Carta, and Calm 35:11 What does a CTO do? 38:09 Will’s role at Imprint 42:48 How engineering management has evolved 51:08 ZIRP’s impact on tech 57:21 Career ladders 1:01:03 Eng 1 vs Eng 2 1:06:58 How software engineering roles are changing 1:16:25 Revised rules of engineering leadership 1:21:57 The risks of becoming a bureaucrat as an EM 1:25:57 How to become a CTO? 1:31:33 Middle management vs. line management 1:41:36 Will’s writing 1:52:13 Book recommendations — The Pragmatic Engineer deepdives relevant for this episode: • The end of ZIRP and what it means for startups and the tech industry • Getting an Engineering Executive Job – an excerpt from Will’s book, The Engineering Executive's Primer • What is a Staff+ Engineer? • Inside Stripe’s engineering culture • Engineering career paths at Big Tech and startups • Staying technical as an engineering manager • Performance calibrations at tech companies • Scaling Uber with Thuan Pham (Uber’s first CTO) • Hypergrowth startups: Uber and CloudKitchens — Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [email protected].

Oct 14, 2026

Brought to You By: • turbopuffer – a vector and full-text search engine built on object storage. It’s fast, cheap, and extremely scalable • Linear – the product development system for teams and agents • WorkOS – everything you need to make your app enterprise-ready. — What do developer tools look like inside of Uber, today? They are very different from what you would see at most places. For example, can you guess what service a system called DevPods, Code Inbox, Slate or Wisdom would be providing to engineers? Today’s episode is a deepdive into the day-to-day tools of devs at Uber, our tour guide being on of Uber’s longest-tenured engineers: Uday Kiran Medisetty. Uday is one of the few Distinguished Engineers at the company, and leads much of the work on agentic AI, today. With Uday, we talk through how Uber’s developer infrastructure prepared it for AI agents. We look at the systems Uber built before generative AI and the new tools that connect agents to its code, internal services, and engineering knowledge. Uday explains how engineers use background agents, why tools like Slate make development (and bugfixing!) more efficient, and how code review is changing. We also cover Uber’s approach to token costs and how it measures productivity as the engineer’s role changes. Timestamps 00:00 Intro 02:48 Uday’s early days at Uber 05:40 Uber’s move to microservices 07:55 Uber’s engineering team, then and now 09:05 Developer tooling before AI 16:03 DevPods 19:28 Building for AI agents 29:27 MCP gateway 34:37 Agent Skills repo 38:46 The context graph and Cortana 47:54 PRD and ERD tool 50:45 Minion 54:46 Testing and code review with Bazel, Slate, and Capri 1:12:26 Edge Gateway, Shepherd, and Wisdom 1:21:33 The changing role of engineer and measuring productivity 1:30:40 Uday’s favorite new products — The Pragmatic Engineer deepdives relevant for this episode: • How Uber uses AI for development: inside look • Scaling Uber with Thuan Pham (Uber's first CTO) • Inside Uber's move to the Cloud • The Platform and Program Split at Uber • Hypergrowth startups: Uber and CloudKitchens with Charles-Axel Dein • How Uber Built its Observability Platform • How Uber is Measuring Engineering Productivity • Developer Experience at Uber with Gautam Korlam — Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [email protected].

Oct 7, 2026

Brought to You By: • turbopuffer – a vector and full-text search engine built on object storage. It’s fast, cheap, and extremely scalable. • Entire – Git hosting, rebuilt for the agentic era. Every agent session, prompt and tool calls: stored in your repo. • Antithesis – verify your system’s correctness without human review or traditional integration tests – and avoid bugs or outages. — Sam Newman wrote one of the most-read books about microservices (“Building Microservices”), but he calls them an architecture of “last resort.” In this episode of the Pragmatic Engineer podcast, Sam explains his thinking on this, and he’s certainly well placed to do so; he was in the room when the term “microservices” was coined. We discuss what teams get wrong when adopting microservices, why independent deployment matters, and how microservices can help teams work more autonomously. We also delve into his new book, ‘Building Resilient Distributed Systems’, and Sam explains his three rules for distributed systems, why observability is essential, and also why it’s vital to take business context into account when deciding whether to fail open or fail closed on errors. We also explore how AI is changing software development, from specs versus code as a source of truth to cognitive debt and cognitive surrender. Sam shares how modular architecture can help teams experiment with AI while maintaining understanding of the systems being built. Timestamps 00:00 Intro 03:16 Sam’s path into tech 09:32 Thoughtworks 20:55 The rise of microservices 33:37 Are specs becoming more important than code? 45:22 Building Resilient Distributed Systems (Sam’s new book) 52:35 Three rules of distributed systems 56:16 Observability 1:02:20 Resilience tradeoffs 1:07:54 Idempotency 1:15:58 Thundering herds 1:21:03 Business context and resilience decisions 1:25:51 Resilience engineering: four concepts 1:32:42 AI and resilience 1:36:26 AI’s limitations and where to use it 1:40:06 Cognitive debt and cognitive surrender 1:45:02 Modular architecture and AI software factories 1:51:53 Resources for learning software architecture 1:55:30 Where to find Sam — The Pragmatic Engineer deepdives relevant for this episode: • Scaling Uber with Thuan Pham (Uber’s first CTO) • What is good software architecture at Netflix? • The past and future of modern backend practices • What is reliability engineering, and the history of SRE • How to debug large, distributed systems: Antithesis • Designing Data-intensive Applications with Martin Kleppmann • Building Bluesky: a Distributed Social Network — Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [email protected].

Sep 30, 2026

Brought to You By: • turbopuffer – a vector and full-text search engine built on object storage. It’s fast, cheap, and extremely scalable • Linear – the product development system for teams and agents • WorkOS – everything you need to make your app enterprise ready. — How is it that a software veteran who regularly shipped ~100K of database-grade code to production each year, pre-AI, feels like he’s even more productive today, with no drop in quality? Peter Mattis is co-founder and CTO of Cockroach Labs, and an original creator of GIMP. He also worked on Gmail and distributed storage at Google. In this episode, Peter reflects on his journey from open source to Google to founding a database company, and we explore how to keep systems fast, reliable, and correct at scale, from Gmail’s early storage challenges to the tradeoffs in building distributed databases. Peter tells us how AI has brought him back to writing code after his work shifted toward management, and why he believes AI can improve quality and multiply the impact of domain experts. We also consider the future of code review, and Peter has some advice about how to level up our engineering skills. Timestamps 00:00 Intro 02:42 Peter’s path into tech 04:00 Building GIMP 09:30 Working on Gmail at Google 14:51 Google’s infra: google3, build files, Bazel, and Colossus 21:30 Distributed storage bottlenecks 23:59 Latency, throughput, and availability 30:04 Contributing to libraries 41:52 Google Spanner 46:10 CockroachDB 52:00 Manual vs. automatic sharding 55:28 Consistency models and strong consistency 1:00:03 Raft consensus 1:06:15 How AI brought Peter back to coding 1:19:12 Peter’s tools and agentic workflows 1:23:08 How AI can improve quality 1:26:39 Code reviews: are they done? 1:29:17 100x engineers 1:35:33 Peter’s advice for leveling up your engineering skills — The Pragmatic Engineer deepdives relevant for this episode: • Inside Google’s Engineering Culture • Resiliency in distributed systems • How to debug large, distributed systems: Antithesis • Pushing software engineering limits with “napkin math” • Designing Data-intensive Applications with Martin Kleppmann • Formal methods with Hillel Wayne — Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [email protected].

Sep 23, 2026

Brought to You By: • turbopuffer – a vector and full-text search engine built on object storage. It’s fast, cheap, and extremely scalable. • O'Reilly Early Release: Scaling AI Adoption in Engineering – a free book on how to adopt and scale AI in a pragmatic way inside of engineering orgs. Complimentary, thanks to Antithesis. • Entire – every agent prompt, tool call, stored in your repo, and mirrored. — What can everyone else learn from designers and design engineers? As it turns out, there’s plenty, as I discovered when one of the best design engineers in the industry, Maggie Appleton, came onto the Pragmatic Engineer Podcast. She’s a staff research engineer at GitHub Next, where she builds prototypes to explore how software engineers might collaborate with AI in new ways. Maggie is at the intersection of design, anthropology, and web development, and was the first designer hired by AI startup Elicit, and Lead Design engineer at AI startup, Normally. Today’s episode is more visual than usual because Maggie brought her notebook along, so there are peeks inside its pages of prototypes and more: We got into designers’ work and how their design processes are adapting to and changing with AI. We explore why Maggie starts projects with pens and notebooks, what distinguishes design engineers from other designers, and why understanding engineering constraints leads to better collaboration with engineers. We also discuss how Maggie uses jigs to gain more control over AI agents, why human judgment and style still matter when models can generate designs, and how inconsistent AI capabilities can mislead us. Timestamps 00:00 Intro 03:24 From anthropology to tech 10:18 What does a designer do? 18:23 How Maggie works 24:55 The case for planning with physical tools 31:53 Why Maggie is learning woodworking 33:13 Design engineers and engineering constraints 38:49 How Maggie uses Figma 40:30 Design at GitHub Next 45:12 How has AI changed design 50:37 When models design and why humans are still needed 53:30 UX and UI 58:29 Capability gaslighting 1:00:33 One Developer, Two Dozen Agents, Zero Alignment 1:07:21 Craft and AI tells 1:14:17 Visual gardens, home-cooked software, and barefoot developers 1:21:02 Advice for engineers and lessons from anthropology 1:25:34 Book recommendation — The Pragmatic Engineer deepdives relevant for this episode: • What is “loop engineering?” • Design-first software engineering: Craft, with Balint Orosz • Are AI agents actually slowing us down? • Vibe Coding as a software engineer • How Codex is built • How Claude Code is built • From Chrome DevTools to AI Engineering, with Addy Osmani — Production and marketing by ⁠⁠⁠⁠⁠⁠⁠⁠https://penname.co/⁠⁠⁠⁠⁠⁠⁠⁠. For inquiries about sponsoring the podcast, email [email protected].

See all episodes →