Episode Summary
Executive Summary: The episode centers on the rise of the “AI engineer” as a distinct software role, the practical skills and tools needed to succeed, and how the upcoming AI Engineer Summit aims to become the builder-focused counterpart to ICML. The discussion also covers hiring, build-vs-buy decisions, the limits and promise of AI agents, multimodal models, and how OpenAI’s expanding platform may reshape the ecosystem.
Main Topics: Defining the AI Engineer role: SWIX argues AI engineering is a distinct, emerging software specialization focused on applying models in production, not training them. He contrasts it with prompt engineering, ML research, and general full-stack work. Core skills and learning path: He outlines a practical curriculum for aspiring AI engineers: using APIs, prompt tooling, code generation, image and speech models, fine-tuning, open-source models, and agents. Tooling, build-vs-buy, and LLM ops: The conversation compares HumanLoop, Guardrails, LangChain, and related tools, emphasizing that most teams should buy first, learn the domain, then selectively build. Hiring AI engineers: SWIX explains where to find AI engineers, how to evaluate them, and why entrepreneurial, proactive builders are more valuable than people who merely rebrand themselves as AI engineers. AI agents: useful today, but limited: They debate agent maturity, with SWIX distinguishing narrow, useful agents from overhyped autonomous systems. He sees current value in constrained workflows, not broad issue-to-PR automation. Multimodality and OpenAI platform expansion: The discussion anticipates voice, vision, fine-tuning, and retrieval becoming more integrated into OpenAI’s API, potentially simplifying AI product development while pressuring startups. AI Engineer Summit and ecosystem building: SWIX frames the summit as a long-term effort to create a premier conference for AI builders, with a speaker lineup spanning foundation models, tooling, production systems, and agents.
Key Arguments: AI engineering is a real, durable job category because demand for people who can apply models in production is rising faster than supply. Most AI engineers will come from software engineering backgrounds moving leftward into AI, not from ML research moving outward into products. A practical AI engineer should understand APIs, prompting, memory, code generation, image and speech models, fine-tuning, open-source models, and basic agents. Buy-first is the right default for AI tooling; teams should adopt existing frameworks, learn the domain, then replace components only when necessary. AI agents are useful in narrow, well-scoped workflows today, but broad autonomous coding or issue-to-PR systems remain overhyped and likely harder than many expect. OpenAI’s platform will likely absorb many adjacent capabilities, which is good for developers but creates competitive pressure for startups in the ecosystem. The best AI engineers are entrepreneurial: they proactively identify opportunities, ship quickly, and adapt as the model landscape changes. Multimodal interfaces, especially voice, will make AI products much more useful and natural, even if text remains the central interface for now.
Data Points: AI Engineer Summit attendance: over 10,000 - The summit is described as gathering former and upcoming guests plus more than 10,000 attendees in San Francisco and on YouTube. Latent Space University course length: 7 days - SWIX describes a seven-day free email course covering baseline AI engineering competencies. Daily time commitment for course: about an hour a day - He says the course is meant to be lightweight rather than intensive. Estimated number of good LLM engineers: about 5,000 - SWIX uses this estimate to explain why companies cannot easily hire foundation-model experts in-house. Conference speaker count: 28 - The host notes the summit website shows 28 accounted speakers. Waymark free-trial hard cost: 15 cents per user - Used as an example of why AI app developers may want bundle economics or better cost-sharing. OpenAI company size: 600 people - SWIX references OpenAI’s growth when discussing why it may compete more directly with developers. Compute growth projection: 6 orders of magnitude - He cites Nat Friedman’s estimate of roughly a million-fold more compute by the end of the decade. Anthropic funding valuation reference: about $10 billion - SWIX speculates on Anthropic’s worth in the context of Google and Amazon bidding dynamics. AI engineer survey target: 1,000 respondents - Mentioned in the intro as a goal for the State of AI Engineering Survey. HumanLoop / LangChain / Guardrails: 3 named frameworks - These are cited as table-stakes tools that AI engineers should understand. P(doom) range: 5% to 95% - SWIX gives a deliberately wide range to emphasize uncertainty while still taking risk seriously.
Pivotal Quotes: "The AI Engineer is a software engineer specializing in AI and the emerging AI stack." — SWIX: His definition of the role and why it deserves its own job title. "Buy first. And then the moment you understand your domain well enough, be in a position to be able to build yourself." — SWIX: His framework for build-vs-buy decisions in AI tooling. "I think the engineers are going to be the people who put Shogov in a box." — SWIX: His argument that builders will shape AI safely by constraining and productizing it.
Implications: The episode suggests AI engineering is becoming a mainstream specialization, with practical tooling, multimodal APIs, and agents lowering barriers while increasing competition. Startups and developers should expect platform consolidation, faster iteration, and a premium on entrepreneurial builders.
From the Episode
As observing that this is a trend that's happening and putting all my chips on red, as they say. So, the AI engineer is a software engineer specializing in AI and the emerging AI stack. And ML engineer is not an ML researcher, both of which are much more established roles and much more on the sort of research-oriented and MLOps side of the fence. It is everything to do with what happens after you have a model in production and maybe with a little bit of fine-tuning, which is, as everybody knows, just extra trade. On top of the vast amount of pre-training that's already been done. And I think it's basically an emerging category for a few reasons. It's more or less just demand and supply. And I started life as a finance and economics guy. I was a trader and hedge fund guy for quite a few years before I was a developer. And I just think it's just pure demand and supply. There's maybe like 5,000 good LLM engineers in the world, LLM researchers in the world, and you cannot hire them as the average company.
Person for five years. But also, I'm very sympathetic to the choose boring technology, try to limit your dependencies as much as possible mindset. And so, basically, typically, what I often say is: buy first, and then the moment you understand your domain well enough, be in a position to be able to build yourself. And this way, you get the benefits of people setting you on the right path with best practices that they've learned from everyone else. But you're ready at this point to understand that this field is so immature, you may have to rewrite, you may have to rip out something that you started not liking. So, this was the topic of a lot of discussion this summer with Langchain, where a lot of people had this exact journey, right? Like they started out building your ass with Langchain, then they ran into a lot of problems that maybe Langchain wasn't well designed for, and then they ripped out Langchain, and they started.
So, I think there's definitely a trade-off between what people actually use at work versus what people just like to talk about on Twitter and star on GitHub and promise AGI without actually doing anything. So, maybe that might be a hot take there. In my course, so we have a seven-day free sort of email course type of thing. And that's meant to be, like, I'm never going to make money from that. That's just meant to be like, start here if you want to learn AI engineering. You're a software engineer. I never dealt with any of these APIs. So, day one would be just try the GPT API. For the first time. And just a lot of software engineers just haven't bothered. And I think you'll be surprised at how much controls, how much, how many options there are available, thinking about running into the context limit for the first time, which ChatGPT and Copilot kind of hide away for you. And just get familiar with all those basics. I think it's very important. Day two will be prompts, tooling, and memory. And that's where you get into the vector databases and the lang chains and all that. And those are just kind of frameworks that will hopefully help with the developments. And I do encourage people to kind of build.
About Latent Space: The AI Engineer Podcast
The podcast by and for AI Engineers! In 2025, over 10 million readers and listeners came to Latent Space to hear about news, papers and interviews in Software 3.0. We cover Foundation Models changing every domain in Code Generation, Multimodality, AI Agents, GPU Infra and more, directly from the founders, builders, and thinkers involved in pushing the cutting edge. Striving to give you both the definitive take on the Current Thing down to the first introduction to the tech you'll be using in the next 3 months! We break news and exclusive interviews from OpenAI, Anthropic, Gemini, Meta (Soumith Chintala), Sierra (Bret Taylor), tiny (George Hotz), Databricks/MosaicML (Jon Frankle), Modular (Chris Lattner), Answer.ai (Jeremy Howard), et al. Full show notes always on https://latent.space
View all episodes from Latent Space: The AI Engineer Podcast