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

How does one person ship more code in a month than most teams do in a year? Peter Steinberger, creator of Moltbot (formerly Clawdbot), made over 6,600 commits in January alone. As he puts it: "From the commits, it might appear like it's a company. But it's not. This is one dude [me] sitting at home having fun."

Moltbot—an experimental AI agent showing what the future of Siri could be like—has become the hottest AI project in tech. It's growing faster than any repository on GitHub by star count, and more people searched for it on Google last week than for Claude Code or Codex combined.

I sat down with Peter in London to understand how he's built software when LLMs and AI agents sit at the center of his workflow. His background is fascinating: he built and scaled PSPDFKit into a global developer tools business, took a three-year break, then returned to building with AI at the core.

What changes when one person can operate like a team

Peter's approach fundamentally reimagines software development. Here are the key insights from our conversation:

Managing a dev team teaches you to let go of perfectionism. Running PSPDFKit with 70+ people forced Peter to accept that code wouldn't always match his exact preferences. This makes him more efficient when working with agents today.

Close the loop: AI agents must be able to verify their own work. Peter designs systems so agents can compile, lint, execute, and validate output themselves. No waiting for human review.

Pull requests are dead, long live "promot requests." Peter now views PRs as "prompt requests" and is more interested in seeing the prompts that generated code than the code itself. Interestingly, this mirrors what my brother, Balint Orosz, said about Craft Agents—they reject almost all external pull requests but take the core idea and use them as prompts later.

Code reviews are dead for this workflow—architecture discussions replace them. Even in Discord, Peter doesn't talk code with his core team: they only discuss architecture and big decisions.

Runs 5-10 agents and stays in the "flow" state. Peter queues up multiple agents working on different features simultaneously, moving between them as they complete tasks.

Spend a lot of time planning out the work the agent will do. Peter spent surprisingly long time going back-and-forth with an agent to come up with a solid plan. He challenges the agent, tweaks it, pushes back. When satisfied, he kicks it off and moves to the next one.

He prefers using Codex because it goes off and does long-running tasks. Claude Code comes back for clarifications, which he finds distracting—given he's already fleshed out a plan.

Under-prompt intentionally to discover unexpected solutions. Peter sometimes gives vague prompts to let the AI explore directions he hadn't considered.

Local CI beats remote CI for agent-driven development. Peter runs tests locally through his agents rather than waiting for remote CI pipelines. He does this because he doesn't want to wait an extra 10-ish minutes for remote CI to run when his agents can run tests locally.

Most code is boring data transformation—focus energy on system design instead. Peter argues that the majority of application code is just "massaging data in different forms" and doesn't warrant obsessive attention.

Engineers who thrive with AI care about outcomes over implementation details. Peter observes that engineers who love solving algorithmic puzzles struggle going "AI-native" like he has. People who love shipping products, on the other hand, excel.

Why this matters for the future of software engineering

Peter strikes me as a software architect who keeps the high-level structure of his project in his head, deeply cares about architecture, tech debt, extensibility, and modularity. One of the reasons Moltbot is so successful is because it's so extensible—and Peter spends a good chunk of his energy making it both easy to add new capabilities and acting as the "benevolent dictator" of the project.

This isn't about replacing software engineers. It's about reimagining what software engineering looks like when one person can operate like a team. Peter's context is important to consider: he's building an experimental project that's heavily work-in-progress, and "move fast and break things" is the only way such a project will succeed.

Even so, it's remarkable how fast Peter is moving and how he's built a tool that found demand that took even major AI labs by surprise.

The key insight: Software engineering isn't dead with AI—quite the opposite. It's evolving from writing every line of code to designing systems that can write, test, and improve themselves. The bottleneck shifts from typing to thinking, from implementation to architecture.

For engineers wondering how to adapt, Peter's approach offers a roadmap: embrace imperfection, close the feedback loop, focus on outcomes over implementation details, and design for agent-driven development from the ground up.

The future of software engineering isn't about humans vs. AI. It's about humans who can orchestrate AI effectively—and Peter Steinberger is showing us what that looks like in practice.