The creator of Clawd: "I ship code I don't read"

Summary of The creator of Clawd: "I ship code I don't read"

by Gergely Orosz

1h 54m•January 28, 2026
Listen to Episode

Overview of The creator of Clawd: "I ship code I don't read"

This episode of Gergely Orosz’s podcast features Peter Steinberger (founder of PSPDFKit and creator of CloudBot/“Clawd”), who describes how AI agents have changed the way he designs, builds and ships software. After selling PSPDFKit and taking three years off, Peter returned to build a massively popular personal assistant (CloudBot) using multiple LLMs and agent workflows. He explains why he often doesn’t read the code he ships, how he “closes the loop” so agents can verify their work, why pull requests become “prompt requests,” and what this means for how teams and engineers will work going forward.

Key topics covered

  • Peter’s background: building PSPDFKit (PDF framework), burnout, selling shares, hiatus, return to hacking.
  • How PSPDFKit succeeded (developer-first product, extreme polish, deep technical blogging).
  • The shift to agent-driven development: tools he uses (Cloud Code, Codex, Claude, Gemini, GPT-5.2, Opus), workflows, and parallel agents.
  • The “closing the loop” principle: build systems so agents can test/debug/verify themselves.
  • Why Peter often doesn’t read generated code line-by-line—focus on architecture, tests and automated validation.
  • New roles and skills required (builders/architects who can orchestrate agents, strong system understanding).
  • Practical trade-offs: token costs, privacy/security, maintainability and onboarding.
  • Hiring and career advice for experienced engineers and new grads.

Main takeaways

  • The most important shift is architectural thinking, not line-by-line coding. Peter spends more time on system design and how an agent will use/validate the code than on reading every new line.
  • “Close the loop”: make features verifiable (compile, run tests, end-to-end checks). Systems that can be validated automatically are where agents excel.
  • Agents multiply productivity but increase mental overhead: Peter runs 5–10 agents in parallel and juggles many concurrent “builds” mentally.
  • PR → prompt: Peter views many pull requests as “prompt requests.” He asks for explicit prompts with PRs because they explain intent and steering more effectively than raw diffs.
  • CLI-first and scriptability: Peter prefers CLIs over rigid MCP schemas because CLIs are easier for models to query, filter and script; he built tools (e.g., MacPorter) to bridge formats.
  • Documentation & tests are easier and better with agents: he often has agents generate tests and docs, producing higher-quality developer docs than he previously authored by hand.
  • This model favors small highly capable teams (and fewer people overall) but requires careful redesign of company processes and codebases to be agent-friendly.
  • Security, cost and privacy remain real concerns: giving agents read/write access to local machines and personal data needs careful controls.

Notable quotes / succinct insights

  • “I ship code I don't read.” — Peter’s provocative summary of trusting validated agent outputs instead of manual line-by-line review.
  • “Close the loop.” — Agents must be able to run and verify their output (compile/tests/execute) to be reliable.
  • “PR should be called prompt requests.” — Shift from code diffs to the prompt+context that generated them.
  • “I write better code now that I don't write code myself anymore.” — He credits agents for improving design choices because they force testability and validation.
  • “Enchanted engineering” (Peter’s preferred phrase) vs. “vibe coding.”

How Peter builds CloudBot — workflow & tooling

  • Agents & LLMs: Cloud Code, Codex (OpenAI), Claude, Gemini 2.5, GPT-5.2, Opus; also uses Whisper, FFmpeg for media processing.
  • Parallel agent strategy: spin multiple agents in parallel, let them build features while switching context between tasks; treat agents like many junior engineers you can orchestrate.
  • Design for agent validation: make code runnable via CLI, provide fast local execution loops (avoid slow browser loops), build automated end-to-end tests the agent can run.
  • CLI-first approach: expose functionality as CLIs so agents can filter/pipe JSON, script actions and chain calls easily (preferred over MCP for scriptability).
  • Bootstrap/identity docs: create data files (user.md, soul.md, identity) that the assistant persists and updates — an explicit memory/identity layer.
  • Prompt-centered reviews: require prompts in PRs; use agent to review and suggest integration strategies rather than reading every line.
  • Local CI / “full gate”: run fast local gates (lint/build/tests) often; if tests pass locally, merge quickly — CI becomes a final gate rather than the cognitive bottleneck.
  • Incremental plugin architecture: prefer plugin/CLI/modules so new large features don’t bloat the core.

Implications for teams & orgs

  • Fewer people, different roles: many tasks can be automated, so companies may need fewer engineers, but those engineers must be higher-agency (architect/build+orchestrate).
  • Hiring: prioritize builders who publish open-source, are curious, game-like in experimentation, and comfortable delegating to agents; look for system thinkers rather than pure implementers.
  • Process change: pull requests become prompts; code review focuses on intent, prompts, and system impacts; tests and automated validation become more critical.
  • Onboarding and naming conventions: structure codebases and naming to be agent-friendly to make automated comprehension reliable.
  • Risk management: security model (agent auth, access controls like MCP/Auth) and cost (token usage) must be accounted for — especially for enterprise or privacy-sensitive apps.

Practical action items (for individuals and teams)

  • Start designing features to be verifiable: add testable CLI entry points, end-to-end tests, and deterministic checks agents can run.
  • Include prompts with PRs: require contributors to attach the prompt(s) and steering steps they used so reviewers can evaluate intent easily.
  • Build a quick feedback loop: keep iteration cycles short, automate run/build/test, and let agents run those loops.
  • Prefer modular/plugin designs and CLIs for external integrations so agents can invoke, filter, and chain actions reliably.
  • Teach/learn agent prompting as a core skill: practice conversational design with agents (architect + agent as collaborator).
  • Treat docs as first-class: use agents to draft and iterate docs, but curate them (prompts + review).
  • Manage privacy/security: limit agent permissions, use explicit auth (MCP/Auth patterns or scoped credentials), and audit agent actions.
  • For new grads: be intensely curious, learn system-level thinking, experiment with agents, and practice building things (open-source is good evidence).

Risks & limitations highlighted

  • Generated code can fail; never fully trust AI without verification — hence the need to “close the loop.”
  • Token costs and compute: persistent personal assistants are expensive; token usage can drive both cost and design trade-offs.
  • Privacy/security: running agents with broad access (files, cameras, calls) is powerful but risky if not controlled.
  • Organizational disruption: adopting this workflow requires rethinking hiring, processes, and culture; not a trivial lift for large companies.

Tools & tech mentioned (quick list)

  • LLMs/agents: Cloud Code (Anthropic), Codex (OpenAI), Claude, Gemini, Opus, GPT-5.2
  • Media & speech: Whisper, FFmpeg
  • Languages & platforms: TypeScript, CLIs, Node, WebAssembly (PDF renderer)
  • Custom tooling: MacPorter (MCP → CLI bridge), local CI gates, plugin architectures
  • Architectural patterns: CLI-first, plugin modules, persisted memory docs (user.md / soul.md)

Who benefits most from this approach

  • Senior builders and architect-type ICs who can design systems and orchestrate agents.
  • Small teams/products where speed + experimentation outweigh slow process overhead.
  • Developer tools, personal assistants, and automation-heavy products where loops can be closed and verified automatically.

Final executive summary

Peter Steinberger argues that AI agents change the fundamental unit of software work: from manual code edits to prompt-driven, test-validated features. The most important engineering skill becomes designing verifiable systems and orchestration, not line-by-line implementation. Teams should invest in fast feedback loops, agent-friendly architecture (CLIs, plugin modules, tests), and prompt hygiene (document prompts with PRs). Adopting this model brings dramatic productivity gains — but also demands new security practices, system thinking, and a willingness to rethink hiring and process.