The future of code is exciting and terrifying

Summary of The future of code is exciting and terrifying

by The Verge

1h 6mMarch 17, 2026

Overview of The VergeCast — "The future of code is exciting and terrifying"

This episode of The VergeCast (host David Pierce) centers on a long conversation with writer/entrepreneur Paul Ford about "vibe coding": using large language models (LLMs) and tools like Claude Code to write, transform, and deploy software. The episode examines why recent advances feel different, what they enable (from resurrecting personal websites to domain-specific hardware tooling), and why they also feel ethically and economically fraught. A secondary segment answers a listener hotline question about whether U.S. phone buyers are missing out on notable features shown at Mobile World Congress (Dom Preston, on phones and camera hardware, joins that discussion).

Key takeaways

  • Recent change ≠ single technical leap: the November shift Paul highlights combined modest model improvements (e.g., Opus/LLM updates) with a product layer that manages prompts, context, and code — creating the first true LLM-based products for coding.
  • Practical upside: LLM tools let non-specialists finish complex projects quickly — e.g., building bespoke CMSs, data migrations, or resurrecting old personal sites — which re-opens creative, personal, and small-scale software possibilities.
  • Real worries: possible job displacement for many roles (data migration, junior engineering work), social and economic mismatch, and concentrated corporate power plus rushed productization.
  • Historical analogy: compilers radically expanded who could program; LLMs may similarly broaden access, but could also reduce demand for specialists — both outcomes may happen simultaneously.
  • No going back: these capabilities are spreading (and can run on phones); containment is unlikely. The focus shifts to regulation, broader cultural dialogue, and building humane workflows/tools.

Interview with Paul Ford — main topics & insights

What changed and why it matters

  • Two accelerations aligned: better LLMs (incremental model improvements) + product engineering that tightly couples the model to tooling (prompt management, code/context awareness).
  • That combination produced LLM-based products that actually solve previously stubborn engineering problems, enabling people to complete projects they couldn’t before.

Concrete examples Paul gives

  • Resurrecting his 25-year-old personal site: Claude Code helped him build a CMS, run imports, add taxonomy/entity extraction, deploy, and instrument the site — tasks that would have cost much more time/money previously.
  • Polyend Endless guitar pedal: a domain-specific runtime that accepts natural-language effect descriptions, compiles them, and runs them on a physical device — a model for how LLMs can enable creative, hardware-plus-software products.
  • Personal projects he’s building or resurrecting: AnySynth (a synth/DAW), unscroll.com (timeline extraction from Wikipedia/archive.org), and a piano-practice app (To-Do List Liszt).

Ethical/personal tension

  • Paul feels responsibility to call out change but also discomfort: the tools are empowering but risk destabilizing careers and livelihoods (e.g., people who trained for well-paying tech jobs).
  • He compares his unease to how GLP-1 drugs changed society: huge benefits, but real cultural and structural disruption that leaders weren’t prepared for.
  • Calls for broader, humane debate — not only technologists and libertarians, but artists, poets, and people from affected communities.

Product vs. apocalypse framing

  • Paul argues it’s more helpful to think in domain-specific product terms (e.g., guitar pedal runtimes, CMS builders) than universal doomsday scenarios. Many valuable uses are small, localized, and creative.
  • Still, large systemic implications (SaaS disruption, job changes, concentration of control) must be addressed.

Notable quotes (paraphrased)

  • “Nothing dramatic changed. They just made something on top of it.”
  • “We invented computers to take busy, boring work that no one should have to do — and now they can do it.”
  • “There is no going back from here.”

Hotline segment — Are U.S. buyers missing out? (Dom Preston on MWC & phones)

Short answer

  • You’re not missing mainstream essentials: the phones most Americans rely on (iPhone, Samsung flagships) cover the mainstream feature set.
  • But if you want bleeding-edge camera hardware, foldable experiments, or quirky form factors, many innovations are appearing first (or only) outside the U.S.

What’s actually different abroad

  • Camera hardware is the most meaningful divergence:
    • Larger sensors (one-inch type and big megapixel sensors, e.g., 200MP) are being used in China/Asia flagship “Ultra” models.
    • Bigger sensors yield camera-like depth, better low-light performance, and more natural bokeh — a qualitative step beyond purely software-based improvements.
    • Telephoto quality improvements (useful 3–10x optical or hybrid zoom) are becoming practical and often outperform US-market flagships in real-world shots.
  • Other innovations: modular concepts, advanced foldable designs (creaseless screens), and features that interoperate with Apple ecosystems in surprising ways (e.g., Honor/Oppo offering AirDrop-like pairing or Mac remote-control integration).

Why these aren’t standard in US phones

  • Market and aesthetic priorities: US-centric brands (especially Apple) prioritize design/aesthetics and the US market’s expectations over packing the largest possible camera sensors.
  • Competitive dynamics: Chinese OEMs are aggressively pursuing camera tech and will accept bulkier devices; US mainstream vendors often feel less pressure to match that niche.
  • Supply/strategy quirks: Samsung makes many of the sensors but does not always use the absolute best ones in its own consumer models — others take advantage of that.

Practical advice for listeners

  • If you care about photography and want the best mobile camera experience now, look at non-US “Ultra” flagships (Xiaomi, Vivo, Oppo, Honor, Huawei) or wait for those ideas to percolate.
  • If you want a mainstream, polished device with broad app/ecosystem support, U.S. models remain a safe bet.
  • For adventurous buyers: importing or buying region-specific models offers options but comes with trade-offs (warranty, software updates, band support).

Actionable recommendations & takeaways

  • For creators/individuals:

    • Experiment with LLM coding tools for small, personal projects (CMS, data migration, automation) — they can unlock long-stalled ideas.
    • Archive and control your own content when possible (personal domain, exports): LLMs will consume the web, so owning clean data is valuable.
    • Consider reskilling in higher-level problem design, tooling, and domain expertise that complements LLMs.
  • For technologists and product teams:

    • Build domain-specific runtimes and UX that couple models with structure and constraints to deliver reliable outcomes.
    • Focus on companion products that let people “use” outputs (e.g., physical devices, editing workflows) so users still practice craft and gain agency.
  • For policymakers and the public:

    • Broaden the conversation: include artists, labor groups, and non-tech communities in debates about regulation and social safety nets.
    • Expect that containment is unlikely; plan for mitigation (retraining, social policy) and governance rather than attempting total prohibition.

Final thought

The episode frames the current moment as both exhilarating and unsettling. Practical, creative uses of LLM code tools are already changing what individuals and small teams can build — while simultaneously forcing hard questions about labor, power, and culture. The useful mental model: think in domain-specific product terms (what small, useful tools can LLMs enable?) while also engaging with the larger societal consequences.

If you want to dig into the full conversation: Paul Ford’s New York Times Op-Ed and his F-Train site (ftrain.com) were central references in the episode.