Chip Huyen on Why to Keep Building When AI Can Copy Anything
The Pragmatic Engineer
Chip Huyen, author of AI Engineering, opened her talk at The Pragmatic Summit with a question she said she fluctuates on herself: if AI can replicate whatever you build, why build at all? Her answer draws on problem-solving, cultural nuance, workflows that haven't caught up with AI, and the plain joy of making things. She framed it as the uplifting note she wanted to end on, while admitting she swings "between excitement and despair."
A side project, cloned in a day
Huyen began by polling the audience on whether they expected their jobs to be automated within five years. She noted that when she asked the same question online the day before, many people said yes.
Her own unease came from a recent experience. She launched a small side project that drew around 300,000 views in a week. Within a day, someone emailed her to say they loved what she built, that they had used Claude Code to recreate exactly that, and here was the link. She was flattered but taken aback. The lesson she drew was that "whatever exists can be replicated."
That cuts both ways, she said. She can now build anything she wants, but so can anyone else, which raises the question of what incentive remains to build anything. She described dropping many of what she calls "SaaS light" products: tools that solve a small problem but charge something like $50 per seat per month. Her reasoning was that she could simply recreate them with AI.
She acknowledged the obvious counterargument that some things are harder to build, and AI can't produce a Google in a day. Her response was that AI keeps improving. She cited research showing AI can accomplish exponentially more complex tasks over time, and said current capabilities already exceed what she imagined a year ago, let alone three years ago. In her view, it may just be a matter of time.
Data isn't a moat, and the "Ghibli moment" of software
Huyen also questioned a common source of defensibility. People used to tell her data was a moat, but her view now is that data is merely expensive. If someone can throw money at acquiring data and building a model, as she argued has happened with efforts to replicate models like GPT-5, it isn't really a moat.
She called this the "Ghibli moment" of software. When AI image generation took off, the Studio Ghibli style became hugely popular, and she realized that if you can describe a style, AI can generate it. The same now applies to software: if you can describe it, AI can build it. The more that gets built and published, the less imagination is needed, because people can just point at a website and say "do that for me."
She then asked the audience why they would keep building. Answers included the learning process and a sense of purpose. She pushed back on the second: if she doesn't do it, someone else will, so it can feel as though she isn't needed. When someone answered that building feels great, she joked that they had stolen her punchline.
Problems follow a long tail
Her core argument was that products don't exist in a vacuum. They exist to solve problems, and building makes you better at problem-solving. She believes there will always be problems to solve. She doesn't think AI will make her a happy person, or stop her from being annoyed at customer support agents.
She described problems as following a long-tail distribution. Because of how AI is trained, it gets very good at things it sees often, the common problems many people share at the head of the distribution. Over time it will cover more edge cases, but in her view the edge cases never go away.
She illustrated this with trading. She said she recently built a trading bot, and joked that she was surprised her "trading phase" came so late, since engineers and math people seem to go through one in their twenties. What she found was that the bigger a market's trading volume, the more efficient it is. In sports prediction, for example, it's almost impossible to compete with dedicated trading firms, and in large markets you can't compete with hedge funds, because once something is big enough, players with lots of money and strong infrastructure move in. The sweet spot, she concluded, is a market big enough to profit from but not so big that "all the sharks" are there.
She applied the same logic to problems. Big, visible problems will attract large companies. Smaller ones might not motivate OpenAI, but individuals can take them on.
Human preference is personal and cultural
One category of such problems is human preference. Huyen argued that preference can't be reduced to an equation or neatly captured by asking people which of two answers they like better. It depends heavily on the person, culture, geography, and age.
On a recent trip back to Vietnam, she spoke with people building AI there and noticed a contrast. In the US, companies deploying customer support agents usually start with text and add voice later. Voice is much harder: speech has to be transcribed to text, sent to the LLM, and the response synthesized back into speech. In Vietnam and many other Asian countries, she said, people are constantly on the move, often on motorbikes, and dislike typing, so many Vietnamese companies deploy voice bots before chatbots.
The builders she spoke with described many cultural nuances, and she gave response timing as an example. She once put her young niece and nephew in Vietnam on a call with her godparents, whom she described as older Americans, and called it a disaster. Her godmother, trying to avoid awkwardness, kept talking and asking more questions whenever the children didn't answer. Huyen later told her about research suggesting that in the US people expect a reply within about 80 milliseconds of finishing a sentence, whereas in Asian cultures people wait longer, more like 200 or 300 milliseconds, out of respect and to make sure the other person has finished. Filling every pause to avoid awkwardness makes things more awkward, because the other person can never get a word in.
Voice bots face the same tension. They must balance latency against humanness: wait for the person to finish, but not so long that the bot feels slow once transcription and generation are added. Huyen called this very hard to solve, and said her examples were only the obvious cultural differences. Many more surface only when you dig into specific use cases and demographics.
Terminal versus IDE: retrofitting old tools
A second area she highlighted is how humans interact with AI. She believes people are still retrofitting existing tools to fit what they imagine new workflows to be.
Her example was coding in the terminal. Many of her friends who work in product roles had never used a terminal until AI coding tools pushed them into it. They found it frustrating: awkward copy and paste, no easy way to upload a file. People use it anyway because that's what exists. They are now asking why the terminal and an IDE like VS Code should be separate, and what the fundamental difference is, since both involve giving an instruction and getting code. Huyen called these open questions that still need answers.
Code review is outdated when nobody writes the code
Huyen emphasized human-to-human collaboration. AI is getting good at solving problems for individuals, she said, but meaningful things require people working together, and mixing humans and AI in collaboration is complicated.
Her example was pull requests. PR review is meant as a guardrail: a colleague checks your work against a standard before merging. She described a team whose most senior member still reviews PRs line by line. He doesn't do this for his own AI-generated code, but does for his teammates' AI-generated code. His reason was that review isn't only for quality control but also for mentoring.
When she asked his teammates whether they read his feedback, they said no. The feedback wasn't actionable. Comments like "instead of writing code like this, write it like this" don't help when they aren't the ones writing the code, and they don't know how to pass that feedback to their AI. Huyen concluded that the whole code review workflow is outdated. Senior engineers, she suggested, should give feedback on how teammates instruct the AI rather than on the code itself.
Reversibility and the danger of real-world actions
Next she turned to how AI interacts with its environment. Today that happens mostly on the computer, with AI gaining access step by step, first to code in the IDE and then to the terminal. She described the terminal as more dangerous. Two days before the talk, she said, Claude Code wiped out her local Postgres database. It was creating a new app, found the port already taken by her existing Postgres instance, and decided to remove it. She had a local backup, so no harm was done, but the incident got her thinking.
Many environments AI works in today are reversible because they can be snapshotted. Bad code can be reverted to the last commit, and a wiped database can be restored from backup. Other actions can't be undone by the user. If an agent fills out and submits a form on a website, the result now lives on someone else's computer. Further out, if AI acts in the physical world, a car that runs over a pedestrian can't reverse that. Huyen argued that guardrails around the reversibility of actions need to be built, because that is where things become "really really scary."
Making the world agent-ready
Huyen called AI-environment interaction a two-way street. Foundation model labs are making models better at interacting with the world, but she asked who is making the world more ready for agents.
She gave several examples. As an author, she wishes books would survive as a format, but she believes people no longer read them the same way. She joked that if someone claims to have read her book cover to cover, she assumes they skipped around. She suggested new formats may be needed, such as websites that are easier for agents to use.
Rate limits were another example. Much of the digital world is governed by them, which makes sense for humans who don't act that fast. AI-to-AI interaction can be extremely fast, so she argued the concept of rate limits fits poorly with AI and can become a bottleneck.
Her most detailed example was web search. She recently benchmarked how models from Grok, Gemini, Claude, and OpenAI handle web search. For some queries, certain models made 900 to 1,000 URL visits, burning through her credits. When she checked how many were unique, the answer was only about 20. The AI kept revisiting the same pages.
Her explanation was that the AI visits a URL, extracts the relevant snippet as a citation, runs another query, extracts another snippet, and so on. This mirrors how humans search Google, scanning snippets and quotations. She asked why AI should be limited to that pattern instead of pulling the whole page once it has visited it. She first called the behavior "stupid," then softened this, saying the people who built these systems are surely smarter than her and her mental model may simply be off. Still, she believes there must be a more efficient, less human-centric and more AI-centric approach, and hopes someone builds it.
From how to build to what to build
Returning to her opening question, Huyen argued that the challenge is shifting from how to build to what to build. If you can describe the problem and the solution you want, AI can usually build it, if not today then perhaps in two or three years. But while AI can replicate what exists, someone still has to imagine what doesn't exist yet. She asked whether we want AI to imagine how humans should live, or whether people should propose those ideas and decide what they want built.
Building for fun
Her final answer was personal: she builds because she enjoys it. She said she hopes building for fun becomes normal. She used to spend much of her energy just getting to the building part, and now it is more fun and easier, so she can do much more.
She drew an analogy to clothing. Clothes were once made by hand, then mass manufacturing made them cheap and widely available. As disposable income grew, some people began to prefer custom-made items over mass-produced ones. She said she isn't sure software will follow that path, or whether anyone would prefer an app because it was "built by hand."
For now, she builds apps as gifts. Instead of buying a friend a birthday present, she might spend a weekend building them something simple, like a tea-tracking app for a friend who loves tea. She said building makes her life happier, except when she feels depressed about why she should keep building at all. She ended not with a resolution but with the belief that "we will figure it out."
Okay. This is very uplifting.
Who here thinks that their job won't be automated by AI in the next 5 years? Wow. What do you do? How do I get a job? So, who here thinks that their job will be automated in the next 5 years? Okay, so how about the rest of you? Like, you don't have a job or something?
Yeah, so I did this question yesterday. I was just curious what people online would think. And it seems like a lot of people think that their jobs are going to be automated.
So, don't despair. I was trying to end the talk on a very uplifting note. But recently I launched something. It's a side project. It's small. I'm happy about it. It got some eyes on it, right? It's like a week, it's like 300,000 views. And within a day, I got an email from someone saying, "Hey, I love what you built. So, I used Claude Code to recreate exactly that. And here's a link." And I'm just like, I'm flattered, but I'm also like, "What?"
So it made me realize that whatever exists can be replicated. So, it makes me feel weird because I just fluctuate between excitement and despair. Because on one hand, I feel like now I can build anything I want. But at the same time, anyone can build anything I want. So, what is the incentive structure for me to do anything?
I think I have stopped using a lot of what I call SaaS lite. Some products I feel like solve a very small problem and charge me a lot of money. Like per seat, first of all, like $50 per seat per month for a single one. I feel like, "Why should I keep paying for you when I can just recreate exactly that with AI?"
And of course other people can tell me, "Okay, it's not quite the same, but there are things that are harder to build, right? You can't just get AI to do a Google in a day. Of course it takes longer." But I also noticed that AI just gets better and better over time. Maybe it cannot recreate Google in a day, but maybe over time it can. And there's research showing that AI can accomplish tasks exponentially more complex. So what AI can do today is already way, way more powerful than what I imagined it could do just a year ago, or way more than 3 years ago. So maybe it's just a matter of time.
And people used to tell me, "Okay, there are different moats, like data is a moat." But it turns out that data is not a moat. It's just expensive. You have seen how easy it is for people to replicate DeepSeek or GPT-5. It's not really a moat if someone can just throw money at it and acquire data and build it. Then what exactly is a moat here? Why should I continue building?
So sometimes I call it the Ghibli moment of software. The idea is that a few years ago everyone was excited about, "Hey, you can use AI to generate pictures in any style." And somehow the Ghibli studio style became the style that people really like. And at that point I realized that if you can describe a style, AI can generate it. And the same with software. If you can describe software, then AI can build it for you. And the more you build, the more you put things out there, you remove the need for imagination. You can say, "Okay, now I like that website. Do that for me." And this is kind of weird.
So, the question I want to understand is, why should I continue building? So, I'm curious here. Why do you think that we should continue building if whatever we build can be copied in a very, very short amount of time?
Learning process. Learning process. That's great. And then what? Sense of purpose. So, it makes you feel like you have purpose, but if I don't do it, somebody else will do it, you know? Somehow I'm not needed anymore. It feels great. It feels great. Okay, you stole my punchline. It was supposed to be the end of the talk.
But I do think there's one thing that makes me want to build: I build because I want to solve a problem, right? You create a product and it doesn't exist in a vacuum. The product you build is just solving a problem. So the more you do that, the better you become at problem solving. And one thing I do believe will never change is that there will always be problems to solve.
I don't think AI will just instantly make me a happy person. I don't think AI will magically make me stop being annoyed at customer support agents. I don't think it's going to go away ever. So, I think there are a lot of problems to solve.
And when I look at the world of problems, I do believe that problems follow a long tail distribution. And just by how AI is trained, it will be able to do a lot of things that it sees a lot, right? So, I think of them as the top of the long tail problem. Very common issues that a lot of people experience. AI will get really good at it. And over time AI will cover more edge cases, but the edge cases will never go away. So, there are a lot of things I consider long tail problems.
By the way, anyone here into prediction markets? Prediction markets. Anyone into betting, gambling? It will never go away. Huh?
Yeah, so I was thinking about it. I did build a bot to do trading. I told my friend, "I'm shocked that our trading phase comes so late in life." Because I feel like if you're into engineering and math, at some point in your 20s you just have to get into trading. So I got into trading and I realized that the bigger the market, if there's a higher trading volume, the more efficient it is. If you get into sports prediction, it's almost impossible to compete with all the sports trading firms. Or you cannot compete with hedge funds, because when anything becomes big enough, the people with a lot of money and amazing infrastructure will get in. So I thought the sweet spot was a market that is big enough to make some profit, but not too big that all the sharks are, you know, ready.
So I think of it as the same thing as the problems that I want to solve, right? If it's a big problem that everyone can see, then all these big companies will get into it. Whereas there are a lot of problems that are smaller, and maybe OpenAI won't be motivated to solve them, but maybe I can, or a lot of people can. And so what do these problems look like?
And I think human preference is one thing. I don't think that human preference is just an equation that people can package nicely, like, "Hey, ask people which of these two answers they would prefer." It's very, very personal, very culturally dependent, geographically dependent, age dependent.
So I'm from Vietnam, and recently I went back to Vietnam and talked with a bunch of people doing AI there. And I noticed something very interesting. Here, when a lot of companies deploy customer support chatbot agents and stuff, they usually go the text route first. Text is easier. And then they do voice bots, because voice is so much more complicated. Instead of just having text in and then text out, you first have to transcribe from speech to text. And then you input the text, the question from users, into the LLM, get back the answers, and then synthesize into voice, and then get back to the people. So, it's a lot more complicated. So, it's natural that people here do text first.
But in Vietnam and also in a lot of other Asian countries, people are on the move all the time. People are on the motorbike all the time. So, they actually really don't like typing. So a lot of the companies in Vietnam actually deploy voice bots before they do chatbots.
And then I talked to them and there are a lot of cultural nuances. For example, the response time. So I have a niece and nephew who are very young. And then I have my godparents here who are a lot older. And then I put them on the call. I feel like it's a disaster when you get 60-year-old American grandparents with 10-year-old Vietnamese boys and girls. And my godmother, because she wants to avoid awkwardness, she just kept on talking, and when she asked a question and they didn't answer, she just kept on asking a lot of questions, trying to get the conversation going.
And then after that I told her, "Do you know that there's research that shows that in the US, people expect you to respond instantly? So when you finish a sentence, people only give like 80 milliseconds for the other person to respond. Otherwise, you need to continue. Whereas in Asian culture, out of respect, we actually wait longer, more like 200 milliseconds or 300 milliseconds, to make sure the person finishes. So, if you just keep on talking to erase the awkwardness, it will become awkward, because the user will be like, 'Wait, I can never get my voice in.'"
So, the same thing with building voice bots, right? With a voice bot, you want to balance out latency and also the humanness of it. You need to wait for the human to finish, but if you wait too long, it will be too slow, because now you have to do all this process of parsing and then generating. So that is very hard to solve. And you have to understand all these nuances. And all the examples that I showed were very obvious cultural differences, but there are a lot more things that we can only understand when we go into specific use cases and the specific demographics we're targeting.
Another thing that I think is very important is the way humans interact with AI. I think there's a lot we are still trying to imagine. What would an AI-driven world look like, right? I think people are trying to retrofit what already exists to fit what they think is a new workflow. So, for example, the IDE and the terminal. So, who here is doing a lot of coding in the terminal? So, who here only started using the terminal because of coding? Nobody? I guess you are more engineering, but I think someone here, thank you. Appreciate it.
I have friends, a lot of them are PMs or doing more product work. They never used the terminal before. But now because of AI, they actually became like, "Wow, what is this? I have to do this now." And it's terrible, because you cannot copy and paste, you cannot upload a file into it. It's just very annoying to use. But people use it, right? Because that is what we have. And people were like, "Okay, can we have a different terminal? Why is there a separation between a terminal and VS Code, for example? Why is there such a debate?" What they do is that they take an instruction and they write your code. So why should they be different? What's the fundamental difference between a terminal and an IDE? So, I think a lot of that is still an ongoing question that we need to figure out.
Another thing that I think is very important is human-to-human collaboration. Because I do think that AI is getting really good at solving problems for each person, but I do think that to build things that are meaningful, we need to work together. And now human-to-human collaboration with AI in the mix is actually very complicated. So, here's an example.
So, who here uses GitHub? A lot, right? So, who here collaborates with your team on GitHub via PRs? Right? So, who here still reviews every single PR line by line?
So PRs are like guardrails for human-to-human collaboration. The idea is that somebody would review your coworker's work to make sure that it meets the standard before merging. So, I talked to a team recently, and one of the most senior people on the team told me that he still does that line by line. He does not review his own AI-generated code line by line, but he reviews his team members' AI-generated code line by line. And the reason, he said, is, "Oh, it's not just for code quality control, but also for education." He's mentoring his team. So you want to give feedback so your team can get better.
And then I asked his team members, "Okay, do you read his feedback?" And they were like, "No." Because the reason is that it's not actionable, right? Because the team members are not the people who write the code. If he says, "Okay, instead of writing code like this, write it like this," they're like, "Yeah, but I'm not writing the code. How do I give that feedback to my AI so it can write code like that?" So, I think the whole workflow of reviewing code is very outdated. I think the senior members, instead of giving feedback on the code, should be giving feedback on how you give instructions to AI to produce better code. So that's just another example of how human-to-human collaboration is going to be very different.
And another thing that I think is very exciting is AI interaction with the environment. Right now we interact with AI mostly on the computer. So we're just giving AI more and more access to different things, right? First, it's the code in the IDE, and then the terminal. With the terminal, it's already getting a bit more dangerous, because recently, for example, just 2 days ago, Claude Code wiped out my Postgres locally. And the reason is that it was trying to create a new app, and I already had another Postgres running locally. And it was like, "Wait a second, this port is taken. Let me just remove it," to create this new one. And I was like, "Dude." So it is very scary. But luckily, I have a local backup because I'm not stupid. So it was fine.
But that made me think about how a lot of the environments that AI currently operates in are reversible. They can be snapshotted, right? Like code. If AI messes up, you can revert back to the last commit. Even if it wipes out my database, okay, I can just go back to the previous backup. But there are a lot of environments where the action cannot be reversed by us.
So, let's say that we have an agent that we use to fill out a form for us, right? Maybe it goes to a website, enters a form, and clicks submit. Now, as a user, we cannot reverse that action, because now it belongs to somebody else's computer, and we cannot do that. Or if we give AI more access outside the digital world, in the real world, let's take the example of a car. It runs over a pedestrian. You cannot just reverse that, right? It's just not working. So, I do think that we need to build out all the guardrails for the reversibility of actions, because that's actually where things get really, really scary.
And another thing that could be very interesting is that I do think that AI-to-environment interaction is a two-way street. On the one hand, we have the foundation model labs that are making models better at interacting with the world. But who is making the world more agent-ready? For example, a lot of websites. I do things for the book. I write books, and as much as I wish that books as a format will survive, I do think that people
don't read books the same way anymore. Right? Like I mean, I don't think people like read books and I wish they did to my book. If someone told me that, I was like, "You're lying. You probably jump around a little."
So, so I do think that like the world is changing and we need to come up with format like the website that's easier for agent or like I was reading something else. Like so, a lot of the world nowadays is like digital world is controlled with rate limit, right? And a lot of time it makes sense but as humans, we don't do things that fast, right? But with AI, now AI can just interact with like AI to AI can be really really fast. So, the whole concept of rate limit is kind of relevant to AI. Like it just can become bottleneck.
Also, the whole concept of search. So, recently I spent a lot of time looking into how AI do web search. And it bothered me. So, so when I search a search as like so I did a bunch of benchmark between Grok and Gemini and Claude and OpenAI and GPT models to do web search and I asked it some query and I saw that for query, some of them do like 900 and 1,000 URLs visit. And like that is so much it was burning my credits like crazy. And and then I looked at like how many of these URLs are unique. And
Oh, shoot. Yes. [laughter] I think that's why my talk is almost done.
So so so and I thought it was like how many of these 1,000 URLs are like unique, right? And it turned out it was like only 20 of them. So the AI kept visiting all of these URLs like again and again. And to me it's just stupid. And then I realized what happened because like at first it visited URL, it took the citations. It took the part that's relevant. And then it do another query, it found the parts that's relevant. And I feel like it's a very human way of doing web search, right? Because we enter things in the Google and we see all the like citations, the quotations part. But like why would we limit AI to that? If AI already visit a page, why don't just pull the entire page out? Why do you have to keep on doing that again and again? It's just stupid to me.
So I feel like or maybe not stupid. I'm sure the people who built that are smarter than me. I'm just saying that like my mental model is just seem off. And I I feel like there's I think there must be a more efficient way of doing things that are less human-centric and more AI-centric. And I think that I hope that somebody will do that.
So I do think that there are a lot of things to build. And the question nowadays is less about like how to build because if you can describe the problem in the solution you want, usually AI can do it. Maybe not today, but maybe like two or three years from now on they can do a lot of those. The question is like what to build because we talk about like yes, if something exists, right? AI can replicate it. But like who's going to build the things that don't exist yet? Who should be like imagining it? Like do we want AI to be able to like just create the solution or like imagine a future of how humans should live or like we can also propose these ideas, like think about what we want to build.
And going back to what you said about previously, like why should we why should I contributing? Is I do think it's just like because fundamentally I I enjoy building. Like it just bring me joy. And I do think that I hope that we can normalize like building things for fun because before I felt I was I spent a lot of energy in doing things just like just to get to the part of building but now it's just so much more fun, it's so much easier, I can do a lot more things.
And I think it's like if we look at our a lot of economic or like industrial progress, so in early days for example, right, clothes, like we did everything by hands and then we have like all the mass manufacture clothes, great, because like people can access to clothes cheaply, like anyone can have like fashion, fast fashion. But then I want people have like higher like disposable income, they start looking, oh actually I don't want mass produced stuff, I want something that's like custom made for me. I don't think we would have a future when when like artisan software, I don't think, I'm not sure if it would actually be interested, like oh I like this app more because it's built by hand versus like this app, right? So I'm not sure it will get there.
But for now I do actually enjoy building apps as a gift for my friends. So for their birthday instead of like buying them something I'm like I'm going to spend like a weekend build them like an app because for example they like tea, I'm going to build them a tea tracking app, you know, like it's just like very very simple and it's a lot of fun. So yeah, so I do enjoy building and it does make my life for now happier, except when I'm feeling very very depressed because I don't know like why should I continue building, but I think like we will we will figure it out. But thank you so much everyone, that is that is my talk. [applause]
Article published