Lessons from building Vercel v0 and the d0 agent - The Pragmatic Summit

The Pragmatic Engineer 34min 3 min #71
Lessons from building Vercel v0 and the d0 agent - The Pragmatic Summit
Watch on YouTube

Summary

  • Malte Ubl, CTO of Vercel, discusses how his team builds and ships AI-powered products—specifically D0 (an internal data agent) and V0 (a public-facing app builder)—while the underlying technology shifts beneath them. He shares hard-won lessons about agent architecture, organizational design, and the future of software engineering in an era where coding agents are rapidly improving.

D0: Vercel’s Internal Data Agent

  • D0 is a text-to-SQL agent deployed in Slack that answers business questions by querying Snowflake, subject to user access controls.
    • Example query: “Which S&P 500 CTOs and VPs of engineering have private Vercel accounts and deployed over Christmas?”—a question requiring cross-referencing LinkedIn data with internal deployment logs.
  • The original version used a traditional agent-in-a-loop architecture with many tools—it worked but wasn’t magical.
  • The team scrapped it entirely and rebuilt around a radically simpler model inspired by coding agents:
    • They documented every Snowflake column in plain English, exported to YAML files.
    • The agent uses essentially two tools: bash (to grep/tail through YAML files and discover business semantics) and SQL execute.
    • Total agent code: ~50 lines.
    • The key insight: models are trained on coding tasks, so making non-coding tasks look like coding tasks (file system exploration + bash) unlocks emergent reasoning behavior.
    • This approach is described in a Vercel blog post titled roughly “All You Need Is the File System and Bash.”
  • The rebuild was driven by humility—best practices from summer 2025 were already obsolete, and model improvements made it viable to rely on emergent behavior rather than hardcoded rules.

V0: Evolution Through Model Breakthroughs

  • Launched in 2023 with the pitch that anyone (including non-engineers) could build applications.
  • Initial assumption: it would serve front-end engineers. Reality: early product-market fit was with back-end engineers, who could fix the tool’s mistakes (models weren’t reliable enough for non-engineers in the GPT-3.5/4 era).
  • Key inflection points (“oh moments”):
    • Summer 2023: A team member discovered that prompting the model to use Tailwind CSS dramatically improved output quality. Tailwind was old enough to be in GPT-3.5’s training data but new enough to be gaining traction. The breakthrough was that inline styles (Tailwind) matched how models reason—putting everything in one place—whereas separating CSS and HTML files exceeded the model’s capacity at the time.
    • Sonnet 3.5 era: A model leap made full-stack app generation viable from the same prompts, enabling non-engineers to succeed and opening enterprise use cases.
    • Enterprise and “shadow IT” use case: Business users (PMs, designers, product owners) building internal apps for themselves—a growing source of demand and a new category of shadow IT that Vercel is positioned to serve.
  • Vercel’s core business model remains infrastructure: customers push code (from any agent—Cursor, Codex, etc.) to a Git repo, and Vercel runs it. This positions Vercel as the deployment layer regardless of how code is produced.

Organizational Philosophy and Shipping Culture

  • Vercel uses an “optimistic locking” model for shipping:
    • No approvals required to ship anything.
    • Engineers must notify the organization, which retains veto power.
    • This is faster than requiring sign-offs (no waiting for legal on vacation) while still giving guardrail teams agency.
  • Reliability architecture:
    • Vercel operates 20 core regions designed to be autonomous—no global config push mechanism exists, preventing single-config-change global outages (contrasted with Cloudflare’s outage caused by bad data in a global key-value store).
    • Serving stack ships once a day; control plane ships on every push to main.
    • Feature flags and config changes are rolled out to one region first for feedback before wider deployment.
  • Token policy: unlimited tokens for developers. Abuse is rare and usually traceable (e.g., one engineer’s custom harness bypassed prompt caching, inflating costs 10x—detected and addressed).
  • Malte’s personal stack: Claude with Opus 4.6 for fast iteration, Codex 5.3 for code reviews. He codes ~12 hours a day, describing the experience as a “dopamine hit” akin to a slot machine.

The Future of Engineering Organizations

  • The role of engineers is shifting to look more like management than individual contribution:
    • Senior ICs benefit most—they already operated this way and now have more “minions.”
    • Junior engineers adapt quickly, having grown up with these tools.
    • Mid-level engineers face the steepest transition, needing to learn a new role.
  • Vercel is investing heavily in interns and junior engineers.
  • Company headcount is informally capped at 1,024 (currently ~750), with the hypothesis that revenue growth can continue without proportional headcount growth.
    • Evidence: 87% of support intake is now automated by an agent (support staff were not laid off—they handle harder, more interesting problems); sales lead qualification is automated via an open-sourced agent.
  • The big open question: is the software market becoming “software light” or “software heavy”?
    • Software is becoming cheaper to create (like video after YouTube), which could mean more total software and more software engineers—or fewer, depending on the maintenance burden.
    • Malte draws an analogy to the 1960s mainframe transition: painful for some, but society-wide enrichment in the long run.
  • Malte’s current obsession: agents for software maintenance. Engineers are building things (like custom file systems) that would have taken months before. The challenge is figuring out whether and how to ship and maintain them automatically in production.
Back to The Pragmatic Engineer