Host Intro (Gene Kim)

Gene introduces Shawn "swyx" Wang as someone many people interested in GenAI may already know. He notes that Swyx has spent time at organizations including AWS and Netlify, helped create large front-end developer communities, and is now especially known as one of the two co-hosts of the Latent Space podcast, which Gene recommends as one of the best places to learn about AI.

Gene says what caught his attention was the AI Engineering Summit that Swyx ran and a talk arguing that the next major shift for developers may be comparable to the DevOps shift from 10 to 15 years ago: the rise of the AI engineer. Gene hands the session to Shawn Wang, also known as swyx.

Shawn "swyx" Wang

Swyx thanks Gene and checks whether he should share his screen. Gene confirms and asks whether the introduction missed anything. Swyx says Gene covered it, and adds that people can find more about him and Alessio on the Latent Space about page. He mentions that he is at Modular's ModCon that day and is effectively speaking at two conferences. He says Gene's work covering the DevOps movement is a major inspiration for the AI engineer movement, and he is curious how the two overlap.

Swyx says he has slides and a GeneCon-specific adaptation of the solidify, simplify, amplify approach near the end. He frames the bottom line: a new role is emerging, with intellectual similarities to DevOps.

He begins with data points for people less close to the AI story. He views AI as the Moore's Law of our time: month to month or year to year progress may not feel impressive, but over a five-to-ten-year view, progress in image generation, speech recognition, speech generation, natural language understanding, and reasoning is overwhelming. He says people experience life day by day while the pot is being cooked slowly around them, so it is useful to step back and project how much change is coming.

Swyx says he is not a hype person and sees a large disparity between AI hype and adoption. That gap is a warning sign and means there is a bubble, but he argues for caution without throwing away the substance. He gives AutoGPT as an example: it was more popular than PyTorch, Bitcoin, Kubernetes, and Django despite having no actual production users. He also describes the AI conversation as manic-depressive: people keep saying it is over and then it is back, including around OpenAI. As a former financial analyst and options trader, he sees this as volatility. In the long arc, he says the volatility matters less than the fundamentals.

He then describes a long-term march toward AI replacing human brain work. He references an AI Engineer Summit presentation estimating that GPT-4 took about 100 person-years of compute to train, and says that projecting GPT-2 to GPT-3 to GPT-4 scaling suggests GPT-9 would have the same amount of compute as all living humans, while GPT-10 would have the same compute as all humans ever. He says Sam Altman thinks this could happen by 2030. Swyx asks what would change in an organization if it could deploy the collective intelligence of all living humans, or all humans ever, through a single API call. He says people are not prepared to think about that, but should start talking about it now.

He also says people over-attribute blame and credit to AI: when things go badly, it is AI's fault; when they go well, it is all AI. He says it is never as good or as bad as people say. Finally, he notes it is impossible to keep up, which is why the solidify/simplify approach makes sense.

Swyx says his baseline advice is not to follow GitHub stars or Twitter likes, but to follow the money, which he calls the least-worst system for determining value in a capitalist economy. He names four killer use cases, meaning categories that reached roughly $100 million ARR quickly in the last two years: generative text, generative images, coding assistants, and chatbots. He says each has at least nine-figure revenue for a single company, and often multiple companies. At the individual level, people are making seven figures building AI apps by themselves. This money changing hands is the accountability factor showing people value the services.

He then turns to the rise of the AI engineer and why he focuses on AI rather than only LLMs. His central thesis is that the AI landscape is shifting right. He references an XKCD comic from 2013 about computer vision: what once required difficult image segmentation or classification work is now an API call. He says progress in AI now can look like prompt engineering, citing a paper where changing a few words produced roughly 60 percentage points of improvement from baseline to state of the art. That illustrates a major shift in skills, background, and applications as the field moves from traditional machine learning models to foundation models with prompting.

Swyx says the starting point for AI engineering has moved. He cites a Hacker News post on breaking into AI engineering where the top answers were the traditional machine learning path and traditional data engineering path. He says he has done both, and neither prepared him for the age of foundation models. It is humbling to know more fundamentals than someone else while that person makes more money, because it suggests you learned the wrong thing or focused your skills at the wrong value level.

He says the new value level is taking trained models and productionizing them in end-user contexts. The roles of machine learning researcher, machine learning engineer, and full-stack engineer are established. What is emerging is AI-specific technology that is not the ML engineer's domain because the ML engineer's job stops when they serve inference, while the AI engineer's job begins with inference. He says the boundary is dotted, not hard; the roles can bleed into each other.

Swyx gives five reasons AI engineering is rising now and may become more popular than ML engineering, perhaps a movement on the scale of DevOps or bigger if AI remains as hyped as it is. First is economics. Many points are non-technical contingent facts about the world. Organizations cannot pay for enough GPUs unless they have raised hundreds of millions of dollars, and the GPU race was kicked off by companies such as Stability, Inflection, and Mistral, alongside Google and Facebook already hoarding GPUs. If an organization lacks the budget and in-house talent, it is not in the running to build its own models or research lab. The traditional pattern was to build an ML team, but many new companies are effectively becoming ML teams as a service. He connects this to Andrej Karpathy's comment that there will be significantly more AI engineers than ML engineers because people can be successful without training anything.

Second is sociology. People in organizations are gradually moving into AI. Swyx tracks growing AI interest over time in the communities he manages, including an informal AI discussion channel at a prior employer. His thesis is that informal Slack groups eventually become formal teams: what people do for fun on nights and weekends, when it has enough activity, eventually appears in the org chart. The growth is inevitable because people organically want to do it and see potential to change the organization.

Third is technology. Foundation models can do transfer learning or in-context learning. He recommends the GPT-3 paper and other foundation-model papers showing zero-shot transfer capabilities: models can do things they were not specifically trained to do; they generalize correctly. He uses image generation demos of an avocado chair as an example: the object did not exist in the training world as such, but the model can produce it in the correct fashion. He says this difference is clearest if you understand the former paradigm of training a model for one specific thing versus applying foundation models off the shelf to many use cases.

Fourth is product. Foundation models enable a shift from a waterfall ML approach, where data engineers and ML engineers first collect data, then train a model, then ship it into product. The AI engineer approach takes a foundation model, builds an MVP, accepts that it may be janky and not super reliable, collects usage data if it succeeds, and only then scales and trains a custom model. Swyx calls this a shift from ready-aim-fire to fire-ready-aim, which he says DevOps people will understand.

Fifth is language and TAM expansion. AI and machine learning used to be generically Python, but APIs make it callable from any language, especially JavaScript. The total number of developers who can play in the space has at least doubled and probably increased much more. He summarizes the five reasons as GPUs and people, intrinsic desire, zero-gradient or in-context learning, fire-ready-aim product development, and language/TAM expansion.

Swyx then asks why AI engineers specifically, rather than prompt engineers. He points to Andrej Karpathy's Software 2.0 essay, which described the move from deterministic programming to learned programming from data. Karpathy argued that traditional programming's addressable space is a dot compared to learned systems because there is more data than people can code. Swyx says the new assertion is Software 3.0: instead of designing the dataset, people design the prompt and build on foundation models. But he fundamentally disagrees that prompting is the whole point. The missing piece is orchestrating AI with code and having AI generate code. There is a two-way dependency between AI and code. His assertion is that Software 3.0 includes Software 1.0 and 2.0: the 1+2=3 thesis.

He says that once LLMs are enabled with code, and the AI engineer is best placed to do that, LLMs can do math and create visualizations, as seen in Code Interpreter. He also sees code-augmented inference as a path toward GPT-5, with longer inference and search times augmented and verified by code. He says much recent research and many OpenAI hires have moved in this direction.

Swyx skips some material and says the main message is that the central problems of the AI engineer remain while the solutions are still being figured out. He recommends studying problems deeply because problems are durable, while a solution's fit depends on context. He names AI UX; AI engineering tooling including prompt engineering, structured responses, vector databases, and evals; productivity developer tools such as Copilot; hosting and infrastructure; fine-tuning and post-training, which are closest to ML research and ML engineering jobs; and AI agents, the most speculative version because they imply full autonomy.

He says the slides include the full stack and where everything goes. For GeneCon specifically, he wants to try applying the solidify, simplify, amplify framework based on Gene's LinkedIn posts, even though he has not read the book. He frames the leadership problem: after being given too much information about AI engineering, the audience may be bought in, but it is too much to manage and too disruptive to tell everyone to drop everything.

He says leaders should solidify by covering fundamentals. His curation is Latent Space University, with seven things every AI engineer must know; without them, someone does not know AI at all. He says these are not speculative or untested, but proven baseline knowledge required for a productive conversation about AI.

Then leaders should simplify the progress of the last five years. The transformer revolution gives everyone a reset: people do not need to learn the last 50 years of AI; they need to learn the last five years because so much architectural change has made previous generations of architecture less relevant, though not irrelevant. He recommends covering the key papers, OpenAI developments, and the state of open and other foundation models to become broadly fluent.

Finally, leaders can amplify. Swyx says his amplification stage was the AI Engineer conference that Gene mentioned. The talks are now on YouTube, and he plans two more versions the next year, one online and one in person in San Francisco. He also points people to the Latent Space podcast for work-in-progress discussion. He closes the prepared portion by saying that is the rise of the AI engineer for Gene's audience.

Q&A

Gene thanks Swyx and says he has followed Swyx's work but felt he had only been exposed to about 30% of what Swyx presented. Gene asks what advice Swyx would give technology leaders who are bought into the why and now tasked with the how, especially leaders with thousands or tens of thousands of software engineers who need to bring AI capabilities to market.

Swyx says he has not led organizations with thousands or tens of thousands of people, so the question is tricky. He says it is disruptive to be a senior leader who understands the need to move quickly on AI without disrupting everything, because leaders still have responsibilities to customers, employees, and other stakeholders. It is tempting to split out an AI task force, treating six special people in a thousand-person company as the AI people while everyone else keeps their day jobs. He says that may be a mistake: everyone wants to join that team, others feel left out, and many up-and-comers in the AI wave come from complete left field. They may lack traditional credentials such as five years in data science or a machine learning PhD, but those credentials are not necessarily what produces the creative rapid prototyping the organization needs.

He says the mentality is fire-ready-aim: ship something that might transform the company today, not five years from now. Leaders should think about how to create change in every part of the organization, build a culture that supports experimentation, give people fundamental skills, and encourage everyone to experiment and enhance their processes with AI. A small group that does not influence the larger organization will not serve the company well; the work needs to be decentralized.

Gene connects this to John Rouser at Cisco presenting on creating a community of practice around AI, and to a CircleCI CTO podcast about getting educated enough to explore customer value. Gene then asks about the communities gravitating toward the AI engineer role: ML communities on one side and developers on the other, including ML engineers shifting into AI engineering.

Swyx says everyone is gravitating toward it, but many existing ML engineers were caught completely off guard. They were happily working on recommendation systems, fraud detection, anomaly detection, and the same MLOps conference topics every year, but were not prepared for the GenAI wave. He says there is an anthropological difference between the people who do that work and the people who do generative AI work. Some people can make the mindset shift and some cannot.

He says that, from what he sees, mostly full-stack engineers and software engineers are moving into the AI engineering space rather than ML engineers and data scientists, though it will take all sorts. He highlights the LLMs in Production community, run by Demetrios, as the ML engineer community doing best at embracing foundation models. But he notes that community focuses on reliability, safety, and security; absent are art, creativity, companionship, mentorship, or therapy. He frames traditional ML as one-to-n thinking, while foundation models enable zero-to-one work. The person who works on zero-to-one is different from the one-to-n person, which he says is not a value judgment but a difference in instinct and background.

Gene says he aspires to do a reaction video watching Swyx and a friend speed-run generating the first GPT assistant. Gene says it showed how many skills are required to ship capability in production: it takes a lot of people and expertise. He thanks Swyx for spending time with the community and says Swyx will be part of the Enterprise Technology Leadership Summit next year. Gene says they will find a way to get the slides to everyone and pass people's questions to Swyx. Asked how people should reach him, Swyx says swyx at swyx dot io or swyx at smol dot ai both reach his desk eventually, and people can also find him on Twitter at swyx. Gene thanks him and says, "to be continued."