How are you gonna even understand how anything works?
Chris Lattner created some of the most influential programming languages and compiled technologies of the past 20 years. He is the creator of LLVM, used by languages like Swift, Rust, and C++, created the Swift programming language, worked on TensorFlow, and now works on the Mojo programming language. In this conversation, they cover the origin story of LLVM and how Chris managed to convince Apple to move all major Apple dev tools over to support this new technology, how Chris created Swift at Apple, including how they worked on this new language in secrecy for a year and a half, and why Mojo is a language Chris expects to help build efficient AI programs easier and faster, how Chris uses AI tools, and what productivity improvements he sees as a very experienced programmer, and many more. If you’d like to understand how a truly standout software engineer like Chris thinks and gets things done, and how he’s designing a language that could be a very important part of AI engineering, then this episode is for you.
Chris Lattner encourages his team to use AI coding tools like Claude Code and Cursor. For experienced programmers like himself, these tools provide about 10% productivity gains, mainly by handling mechanical rewrites and reducing tedious work, which increases both productivity and coding enjoyment.
However, the impact varies significantly by use case. For PMs and prototypers building wireframes, AI tools are transformative—enabling 10x productivity improvements on tasks that might not otherwise get done. But for production coding, results are mixed. Sometimes AI agents spend excessive time and tokens on problems a human could solve faster directly.
His key concern: programmers must keep their brains engaged. AI should be a “human assist, not a human replacement.” For production applications, developers need to review code, understand architecture, and maintain deep system knowledge. What he cares about most is keeping production architecture clean and well-curated—it doesn’t need to be perfect, but it needs human oversight. AI coding tools can go crazy, duplicating code in different places, which creates maintenance nightmares when you update two out of three instances and introduce bugs. “Vibe coding” (letting AI handle everything) is risky—not just for jobs, but because it makes future architectural changes nearly impossible when no one understands how the system works. As Chris puts it: “The tools are amazing, but they still need adult supervision.” Keeping humans in the loop is essential for security, performance, and long-term maintainability.
Chris Lattner’s team hires two types of people: super-specialized experts (compiler nerds, GPU programmers with 10+ years of experience) and people fresh out of school. He finds early-career hires particularly exciting because “they haven’t learned all the bad things yet.”
For early-career candidates, he looks for intellectual curiosity and hunger—people who haven’t given up to “AI will do everything for me.” He wants fearless individuals willing to tackle things that sound terrifying or “impossible and doomed to failure” with a “how hard can it be? Let’s figure it out” attitude. Hard work and persistence are essential in the rapidly changing AI space where many people freeze up instead of adapting.
He particularly values open source contributions, which he considers the best way to prove you can write code and work with a team—a huge part of real software engineering. Internships and hands-on experience also matter. During conversations, he can tell when candidates are genuinely excited about what they do versus just “performatively going through the motions.”
His interview philosophy emphasizes letting candidates use their native tools, including AI coding assistants for mechanical tasks. Making people code on whiteboards without their normal tools would be “very strange” today. He also recognizes that nervousness affects performance, so creating a comfortable environment matters.
Chris Lattner argues that with AI making code writing easier than ever, the focus should shift to code readability, not optimizing for LLMs. Code has always been read more often than it’s written, and that hasn’t changed.
... continue reading