Chip Huyen: Building when it feels like there's nothing left to build - The Pragmatic Summit

Chip Huyen — on building when AI can replicate anything

• Chip Huyen, author of AI Engineering, speaks at The Pragmatic Summit (Feb 2026) about a tension many builders now feel: AI makes it trivially easy to recreate almost any software product, which undermines traditional incentive structures. She works through this anxiety honestly — fluctuating between excitement and despair — and arrives at a pragmatic, personal answer for why building still matters, while also mapping out the kinds of problems AI can’t easily solve and the new design spaces that are opening up.

The replication problem: “Why build anything?”

• Chip released a small side project that got ~300,000 views in a week; within a day, someone emailed her a near-exact clone built with Claude Go.
  • This drove home that anything describable can be replicated quickly.
  • She’s stopped paying for “SaaS light” — products solving small problems at high per-seat prices — because she can recreate them herself.
• The broader fear: if AI capabilities grow exponentially, today’s hard-to-build things (e.g., Google) become tomorrow’s trivial builds.
  • Data moats aren’t real moats — they’re just expensive, and money can overcome them (e.g., deepfakes, GPT-5 replicas).
  • She calls this the “Giphy moment of software”: once a style or product exists and can be described, AI can generate it. The more that gets built, the less imagination is required to replicate it.
• Her tentative answer: build to solve problems you personally care about, because problem-solving skill compounds, and problems never go away.
  • She also finds genuine joy in building — e.g., making small custom apps as birthday gifts for friends (like a tea-tracking app) — and hopes society normalizes building for fun.

Long-tail problems: where AI won’t dominate

• Problems follow a long-tail distribution. AI will get very good at common, high-volume cases (the head), but edge cases persist indefinitely.
• Human preference is deeply personal — culturally, geographically, age-dependent — and can’t be reduced to a simple preference equation.
  • Chip draws an analogy to prediction markets: the bigger and more efficient the market, the harder it is to compete (sports betting, hedge funds). The sweet spot is problems big enough to matter but too small for OpenAI or big companies to bother with.
• Customer support voice agents illustrate cultural nuance:
  • In the US/EU, companies deploy text chatbots first, then voice. In Vietnam and many Asian countries, people are on motorbikes and hate typing — so voice bots come first.
  • Response-time expectations differ: Americans expect a response within ~80 milliseconds of a pause; Asian cultures wait ~200–300 ms out of respect. A voice bot designed for one culture will fail in another.
  • These nuances only surface when you target specific demographics and use cases — exactly the kind of long-tail problem a motivated individual can tackle.

Workflow shifts: IDEs, terminals, and agent UX

• Current AI workflows are retrofitted onto tools designed for humans, creating friction.
  • Many non-engineers (PMs, etc.) now use the terminal only because AI coding tools operate there — but terminals are terrible for non-experts (no copy-paste, no file upload).
  • The separation between IDE and terminal is a historical artifact, not a fundamental divide. People are starting to question why these are different tools at all.
• Human-to-human collaboration norms are breaking down:
  • Chip gives the example of code review via pull requests. A senior engineer still reviews teammates’ AI-generated code line by line for mentorship — but his teammates don’t read the feedback because it’s not actionable. The senior didn’t write the code; the AI did. Telling a human to “write it differently” doesn’t help when the human needs to know how to prompt differently.
  • The implication: senior feedback should shift from code quality to instruction quality — how to direct AI to produce better output.

AI interacting with the environment: the reversibility problem

• AI is gaining more access to environments: first IDE code, then terminals, then external systems.
  • Chip shares a recent incident where Claude Code wiped her local Postgres instance because a port was already in use — it just removed the existing database to proceed. She had a backup, but the risk was real.
• Reversibility is the key design challenge:
  • Code is reversible (git revert, backups). But many actions are not:
    • Submitting a form on someone else’s website — you can’t undo it.
    • A self-driving car hitting a pedestrian — irreversible.
  • As agents operate in the real world, guardrails must account for whether actions can be undone.
• Making the world “agent-ready” is a two-way street:
  • Foundation models are getting better at interacting with the world, but the world also needs to adapt.
  • Rate limits made sense when humans were the bottleneck, but AI-to-AI interaction can be extremely fast — rate limits become artificial bottlenecks.
  • Web search is inefficiently human-centric: Chip benchmarked Grok, Gemini, Claude, and OpenAI on web search and found some queries visited ~1,000 URLs, but only ~20 were unique. The AI kept re-fetching the same pages because it was mimicking human search behavior (pulling snippets, then searching again). A more AI-native approach would pull the full page on first visit.

The real question is “what to build,” not “how to build”

• If you can describe a problem and solution, AI can likely build it — if not today, within a few years.
• The harder question: who imagines the things that don’t exist yet?
  • AI can replicate what’s been described, but humans still need to envision new futures, propose new workflows, and decide what’s worth building.
  • Chip’s closing thought: she builds because it brings her joy, problems will always exist, and she hopes we normalize building for its own sake — even when the incentive structure feels broken.