When Programmers Stop Writing Code: Reflections on Peter Steinberger’s Interview

“I always thought I loved programming. Turns out, what I really loved was creating.”

Who Is This Guy?

A couple of days ago, I came across episode 491 of the Lex Fridman Podcast, featuring Peter Steinberger. If you work in mobile development, you have probably heard of PSPDFKit: a PDF SDK with installations in the billions, at the top of its field. Peter spent 13 years growing it, sold the company, retired, and disappeared for three years.

For most people, that would be the end of the story. Money, free time, travel, perhaps a memoir—a perfect ending. Peter is not most people. After three years of retirement, he said he was desperately bored: waking up without anything to look forward to or a real challenge was extremely dull. So he created OpenClaw, an open-source AI agent project that became one of the fastest-growing projects in GitHub history. At the time of this article, it had 251,000 stars, ranked first, and was being discussed worldwide.

This episode is worth hearing for more than his remarkable story. His understanding of software development in the AI era differs from most people’s. He is not theorizing from the sidelines; he uses agents to write production code for real users.

Let the Agent Debug Itself

One point that fascinated me was how Peter debugs agents.

Before the vibe-coding era, we would inspect logs, set breakpoints, read stack traces, and add print statements, narrowing down the problem layer by layer. Now we might ask an agent directly: “What error did you see? Read the source and find the problem.” Peter takes it further: “Can you call that tool yourself?”

This is counterintuitive. We are used to treating an agent as a tool that executes instructions; Peter asks it to understand its own operating mechanism. One statement stayed with me: “I made the agent very aware—it knows what its source code is. It understands how it sits and runs in its own harness.” He has the agent read its source, understand how it is assembled, and use that knowledge to locate problems.

That is essentially an early form of self-modifying software. As Peter puts it: “People talk about self-modifying software, I just built it.”

He also mentioned a deeper principle I consider important: empathize with the agent—see things from its perspective. Think about how it sees your repository. Each new session begins without knowledge of your project, so you have to help it build context. This sounds simple, but doing it requires a change in mindset. We usually organize code around our own understanding. If your collaborator starts from zero each time, you need to reconsider the code structure, documentation, and even file names. Peter says he is building a repository that an agent can navigate easily, rather than one optimized only for himself. Two years ago, people might have called that madness. Today, it makes sense.

Agentic Engineering Is Different from Vibe Coding

Peter uses a distinction I like. He says he does agentic engineering, then perhaps switches to vibe coding after 3 a.m. and regrets it the next day. Ha! Who has not regretted a decision made at that hour?

Jokes aside, the difference is substantive. With vibe coding, you provide a broad direction, let the agent improvise, and decide intuitively whether you like the result. Agentic engineering means understanding context-window limitations, building the scaffolding agents need, and dividing work so several agents can operate efficiently in parallel.

Peter’s workflow involves running four to ten agents at once, managed in a three-by-three terminal grid. Most work in the same folder. He dictates many instructions through Wispr Flow and says at least half of his prompts contain a screenshot. This is closer to directing than typing code.

He also describes a complexity curve. At first, your AI coding prompts are simple: “Fix this bug.” Then you introduce complicated orchestration, multiple agents, tool use, and workflow control. Eventually, once you really understand the process, you return to short prompts—because the repository, documentation, and toolchain are arranged so the agent immediately understands. That progression from simplicity through complexity back to simplicity is interesting.

His approach to code review differs too. Instead of reviewing every line personally, he asks the agent whether it understands what the pull request is intended to do. Once intent is clear, he asks whether there is a better solution. The agent then responds to CI bot comments, and the PR merges automatically after passing. He has custom commands such as /automerge and /massageprs for handling PRs in batches. The efficiency is honestly a little intimidating.

Skills and CLIs over MCP

Peter is blunt about MCP: “Almost all MCPs really should be CLIs. I say that as someone who wrote 5 MCPs myself.” Coming from someone who has built them, that carries weight.

He identifies several core problems. The first is context pollution: MCP responses pour large amounts of data into the context window. He gives GitHub’s MCP as an example, consuming 23,000 tokens, and initially nearly 50,000. In a context window where space is precious, that is disastrous. The second is poor composability: you cannot process and chain several MCP outputs as naturally as with Unix pipes. The third is that it introduces another syntax for models to learn, whereas models already understand command-line tools.

The advantages of a CLI plus jq are clear by comparison. You can filter precisely and let only relevant results enter the context. Models already have a deep familiarity with Unix commands; you do not need extra prompts to explain them.

As Peter describes them, skills begin with a one-sentence capability description. Once loaded, the model knows which CLI commands to use. Simple, efficient, and economical with context.

He does acknowledge an important MCP use case: services that must retain state. Browser automation with Playwright, for example, needs a persistent browser instance. Outside cases like that, his first response to a new MCP is to spend a minute turning it into a CLI.

This gave me a sense of clarity. The Unix philosophy of “Do One Thing and Do It Well” has not become obsolete in the AI era. It has become relevant again. Pipes, filters, and composition—ideas that are decades old—fit collaboration with agents remarkably well.

When Programming Becomes Knitting

This was the most emotionally difficult part of the interview.

Peter offers an analogy: programming as a craft will continue to exist, but it may become like knitting—something people do for enjoyment rather than practical necessity.

My first reaction was complicated. We programmers have spent thousands of hours inside editors. There is the moment a difficult algorithm finally works and every test passes; the satisfaction of solving a strange bug at 3 a.m. and collapsing into your chair; the flow state where the world shrinks to you and the screen. It is hard to accept that these experiences could be replaced by something “without a soul.”

Peter observes that many developers are “mourning the loss of the flow state.” He compares this to workers smashing machines during the Industrial Revolution. Textile workers felt that machines were taking their craft, dignity, and identity. The story is repeating in technology, except that this time the threatened group is people who consider themselves knowledge workers.

But Peter is also honest about finding a similar state while working with agents. He says he has never had as much fun as building this project. The feeling is different: once, flow meant swimming through details of code; now it means designing, deciding, and creating at a higher level of abstraction.

He thought he loved programming, then realized he loved creating. It sounds simple, but many programmers have never fully answered that question for themselves. Do we enjoy the act of writing code, or the process of making an idea real through code? If it is the latter, an agent is another way to make that happen.

Another thought I remember is not to bind your identity to the label “programmer”: fundamentally, you are a creator. I know that is right. Yet as a developer living through this transformation, putting it into practice is much harder than saying it. My résumé says “software engineer.” My skills are concentrated in code. My social circle talks about frameworks and languages. If someone suddenly says those things matter less, how can I casually reply, “That is fine; I am a creator”?

Still, Peter is living this change. He went from writing Objective-C every day as an iOS developer to directing ten agents with his voice. What he builds is more ambitious and influential than before. Perhaps the answer is to grow into a new role rather than feel that everything has been lost.

Final Thoughts

After more than two hours of the podcast, my thoughts were still tangled. Rationally, I agree with much of what Peter says; emotionally, I need more time to process it. One thing is clear: this industry is changing so quickly that if we do not actively understand the new way of working, we may already be behind the next time we look up.

Will programming really become knitting? I do not know. But those nights fixing bugs at 3 a.m., those days wrestling with code, will not have been wasted. They formed our basic intuition about computation. That intuition is precisely what good agentic engineering builds on.

Podcast: Lex Fridman Podcast #491 — Peter Steinberger Peter’s blog: steipete.me