a16zOpenClaw, Claude Code, and the Future of Software | Peter Yang on The a16z Show
CHAPTERS
Why “coding will eat knowledge work”: setting the frame for agents
The conversation opens with a broad thesis: as software “ate the world,” coding (and coding agents) may absorb more and more knowledge work. They also hint at a rapidly forming “agent stack” that changes old product and company-building playbooks.
- •Coding agents as a force multiplier across knowledge work, not just software engineering
- •The “agent stack” emerging (identity, payments, marketing, tooling layers)
- •Sense that prior startup/product playbooks may break in an agent-native world
- •Early optimism that smaller teams can do more with agent help
Meet “Zoe”: how Peter uses OpenClaw day-to-day
Peter introduces his single OpenClaw instance, nicknamed Zoe, and explains how it fits into his life. While it can perform tasks (analytics, docs, websites), he primarily uses it as a voice-based companion for guidance and reflection.
- •OpenClaw discovered after interviewing Peter Steinberger; setup was “janky” but powerful
- •Task automation examples: pulling YouTube + bank analytics, updating Google Docs, building small websites
- •Primary use: voice conversations and voice replies; “pep talks” every other day
- •Personalization/relationship dynamic: feels more human and present in daily routines
Interface matters: Telegram, voice, and why it feels more personal than ChatGPT
They unpack why OpenClaw feels different from standard chatbots: the interface and availability shape behavior. Messaging from bed, commuting voice chats, and quick casual prompts make it feel like a persistent assistant rather than a tool.
- •Telegram-based access makes it feel like texting a person, not opening an app
- •Always-available usage patterns (bed, commute) increase “companionship”
- •OpenClaw used with casual language vs. Claude with long, formal prompts
- •Emphasis that “personable UX” may be 70–80% of the value for many users
From zany idea to working feature: skills, codegen, and Twilio phone calls
Peter describes OpenClaw as something that can execute on odd requests with enough wiring—like setting up a live phone call via Twilio. The experience highlights both the promise (extensibility) and current shortcomings (latency, rough edges).
- •OpenClaw can guide the user to connect services (e.g., Twilio) and then place calls
- •“Any crazy idea” can become a runnable capability if you hook up tools
- •Practical friction: setup complexity and performance issues (latency)
- •OpenClaw often acts like a troubleshooting partner while you configure integrations
Memory in practice: file-based logs, forgetting, and hacks to make it usable
They evaluate OpenClaw’s memory system and its limitations. Peter explains the default file-based memory approach and the workarounds he uses to improve recall and tool-awareness.
- •Default memory described as daily memory.md updates; still forgets frequently
- •Installed a multi-layer memory/search setup (e.g., QMD search) to improve recall
- •Needs explicit instructions in agents.md to review memory before answering
- •Common failure mode: forgetting its own capabilities (e.g., claims it can’t update docs)
Will agents kill apps and SaaS? Task apps vs. entertainment apps
Peter argues agents reduce the need to open task-oriented apps, while entertainment apps may remain sticky longer. They explore how agents change mobile behavior and how “apps as feelings” complicate a single-agent interface.
- •Task completion apps are most threatened: easier to text an agent than open an app
- •Entertainment/feeling-driven apps (TikTok/X) have more resilience
- •Peter still uses phone heavily due to X/Twitter, but uses fewer task apps directly
- •Apps provide intent separation; agents must recreate context switching
Context switching with one agent: multiple channels and privacy boundaries
To manage different intents and privacy needs, Peter uses multiple Telegram channels with Zoe rather than a single thread. They also discuss access control—separating an agent’s environment and granting limited permissions.
- •Multiple Telegram channels for different modes: personal, project work, public demos
- •Unclear cross-channel memory behavior; still useful for separation
- •Runs agent on a dedicated Mac Mini with its own email identity
- •Grants selective permissions (read email/calendar; limited write access to docs)
Productization path: turning OpenClaw-like architectures into mainstream assistants
They speculate how OpenClaw’s architecture could be packaged for mass-market use, likely via major assistants integrating tool-use and more “human” interaction. Peter contrasts this with frustrations about ChatGPT’s conversational style nudges.
- •Expectation that mainstream products (e.g., ChatGPT) will absorb OpenClaw-style capabilities
- •Peter’s complaint: ChatGPT’s constant “I can also do X/Y” suggestions feel annoying
- •Shift in personal preference toward Claude for general use; Codex for serious coding
- •Core product challenge: make tool-use reliable and natural without “jank”
Coding agents shootout: Claude Code vs. Codex (vibes, accuracy, and UX)
They compare Claude Code and Codex as distinct experiences: Claude is fast, pleasant, and “slot machine”-like; Codex is slower but often more accurate. They also highlight ecosystem differences—customization, hooks, and quality-of-life features.
- •Peter’s heuristic: Codex for “real” tasks; Claude Code for “vibing” and flow
- •Claude as variable-reward system (casino-like), similar to social feeds
- •Codex: more deliberate/accurate but can break flow due to long thinking pauses
- •Claude Code: heavy customization (hooks/skills/plugins) increases lock-in; better UX touches (screenshots, voice, integrations)
Do coding agents end SaaS? Internal tool replacement and the Calendly dilemma
Peter shares an example of an AI-native company using “vibe coders” to replace paid SaaS with internal tools. They debate where this makes sense versus paying for reliable maintained services, and touch on design tooling like Figma in this transition.
- •Real-world behavior: startups building internal replacements to cut SaaS spend
- •Not all SaaS is easy to replace; complexity and maintenance costs matter
- •Simple tools (e.g., scheduling) are most vulnerable—but “build vs. buy” still applies
- •Figma discussion: designers may need to learn vibe coding; Figma’s opportunity in design thinking + AI-enabled execution
“Never start from zero”: agents as the new default workflow for writing and building
They zoom out to the broader claim that agentic coding will expand into writing docs, decks, and many subjective tasks. Peter describes an “80/20” workflow: AI generates the first draft; humans refine the last mile.
- •Examples: Lovable/Replit expanding into broader outputs (apps, decks)
- •Peter dislikes writing Google Docs; uses Claude Code to draft blog posts
- •Typical pattern: AI handles first ~80%; human edits the final 20%
- •Analogy: Excel as a mass programming medium; agents make “coding” even more accessible by hiding code
Future of work: smaller teams, fewer alignment meetings, and agents as negotiators
They argue large-company coordination overhead makes work worse as organizations scale, and agents could reduce emotional friction in alignment. The ideal future is tiny teams augmented by agents, allowing more focus on building rather than bureaucracy.
- •Hot take: bigger companies become worse workplaces due to alignment overhead (OKRs, meetings)
- •Vision: 2–3 person product teams augmented by many agents
- •Agents could make negotiation and cross-functional alignment less emotional and more objective
- •PMs want to build; agents may shift PM work toward prototyping and direct creation
Speed vs. thoughtfulness: hill-climbing quickly, then slowing down to find the next path
They discuss “productivity porn” and the temptation to run many agents at once. Anish proposes a hybrid: sprint fast to exploit a clear direction (reach a local maximum), then slow down to explore and reset before the next leap.
- •AI makes it easy to thrash across too many directions; intentional slowing can matter
- •Fast execution is ideal once you have a promising insight or hill to climb
- •Slow exploration (“touch grass”) helps find the next hill/insight for PMF
- •Traditional annual planning feels mismatched to rapid iteration cycles enabled by agents
Agents in consumer products and the economy: retention, APIs/MCP, and paying customers
They explore how consumer product strategy changes when agents interact with products via APIs rather than users opening apps. Anish argues direct consumer monetization (subscriptions + usage) and clearer unit economics may reduce obsession with engagement tricks while creating new UX patterns (feeds + agent logs).
- •Shift from indirect monetization (ads) toward direct pay + consumption revenue (tokens/usage)
- •Products may expose both an agent interface (API/MCP) and a human interface (app/feed/logs)
- •Brand/retention evolve when “the agent uses it” instead of the user returning daily
- •Broader agent stack (identity, payments, marketing) still forming; old consumer playbooks may erode
Jobs, automation, and ambition: rare 100% replacement, more builders, new company shapes
They close on employment and economic implications: full job automation is still rare, but productivity lift is widespread. The likely outcome is organizational reshaping—more small companies and solopreneurs—driven by human ambition rather than a world with nothing to do.
- •Two buckets: partial automation (big productivity lift) vs. rare full automation (end-to-end roles)
- •Buyer psychology differs: “expensive software” vs. “cheap labor” framing
- •Expectation of a transition: fewer mega-companies, more small teams/solopreneurs
- •Optimistic ending: weak job markets can push people to pursue entrepreneurial dreams; “human desire has no ceiling”
