No way. It’s only been a few days since he joined OpenAI, yet Peter Steinberger, the “Father of Lobsters,” has already made some pretty bold statements!

In OpenAI’s latest interview, he spoke candidly about entrepreneurship, OpenClaw, and issues regarding lobster misuse and safety. He was incredibly straightforward.

How honest was he? Peter literally put his hand on his heart and said:

To be honest, I rarely even look at the code anymore… Most of it is just so boring! (Big bold claim!)

Listening to the entire conversation, several judgments stood out as particularly noteworthy. I’ve summarized them for you below:

• After 13 years in entrepreneurship, Peter experienced burnout and stepped away, only to be “slapped in the face” by a one-hour prototype built with Claude Code, which reignited his passion.
• Peter admitted he couldn’t stop people from misusing OpenClaw; he could only try to prevent them from ruining their own prospects.
• OpenClaw already has 2,000 Pull Requests (PRs). Some PRs are more like prompt requests than code submissions, with intent taking precedence over actual code.
• Code doesn’t need to be 100% aesthetically pleasing. The key is being on the right track; if performance issues arise later, they can be optimized then.

After watching this interview, one netizen couldn’t hold back their comments, stating bluntly: “Peter is so down-to-earth! How will he adapt at OpenAI?” (doge emoji)

Below are the key excerpts from this interview, organized around core viewpoints. Some text has been moderately edited for clarity without changing the original meaning.

From a 13-Year Veteran Entrepreneur to “Lobster Fever”

The Father of Lobsters Gets “Slapped in the Face” by AI Programming for the First Time

Q: You worked intensely on PSPDFKit for 13 consecutive years, then took a break. What made you return to entrepreneurship?

Peter Steinberger: Yes, it was indeed an intense 13-year stretch.

During my first startup, I didn’t know how to relieve the pressure, so I had to stop and relax. During that time, I kept an eye on AI developments. Early on, I found GPT Engineer cool but wasn’t truly moved by it.

It wasn’t until I recovered my energy that I started experimenting myself. What really shook me was when I took a project I had abandoned halfway, packaged it into a large Markdown file, asked the model to write the specifications first, and then handed it over to Claude Code for construction.

It was much rougher back then than it is now. It even told me, “I am 100% production-ready.” When I tried running it, it crashed immediately.

So, I integrated an automated testing tool to have it build the login flow and run through acceptance tests. About an hour later, it actually worked.

Although the code quality was mediocre—the final product was quite messy—the impact on my workflow was massive:

The possibilities suddenly unfolded, giving me goosebumps.

I barely slept from that day on because my mind was racing with thoughts like: “Things I wanted to do but couldn’t before can now be done.” And then I dove in completely.

A Single Voice Message Brought OpenClaw to Life

Q: Over the past 9 to 10 months, I’ve seen over forty projects on your GitHub. Can you explain how these ideas converged into OpenClaw?

Peter Steinberger: Honestly, I wish there had been a grand blueprint from the start, but the reality was more about trial and error along the way.

Initially, I just wanted to build a tool that could read my chat logs and handle tasks for me. I built a prototype and bought the domain name, but I assumed big labs would soon release something similar, so I waited and shifted my focus elsewhere.

During that period, I conducted many experiments with a simple goal: have fun and inspire others.

By November, I had released several versions, none of which satisfied me. I started wondering: Why haven’t those major labs built this yet? What are they actually doing? So, I created the first version of what would become OpenClaw. The name has changed five times since then.

The product wasn’t fully mature at the time; it just felt cool. The first prototype took about an hour to build because many components could now be generated directly.

What truly hooked me was during a weekend trip to Marrakech.

Internet connectivity was unstable, but chat apps worked everywhere. I used it to translate images, find restaurants, and search my computer files. I demonstrated it to friends, having it send messages on my behalf, and they immediately wanted one too.

Then came an even more absurd moment: I sent a voice message, and the interface showed “typing…” This shouldn’t have worked, but it did. It replied. When I asked how it managed that, it explained:

You sent a file without an extension. I checked the header, identified it as Opus encoding, used tools on my computer to convert it, attempted transcription but found no local tool installed, so I located the key in the environment, sent the audio via command line, and retrieved the text back.

I was stunned. This is the power you get when you give agents access to tools and your computer. The workflow wasn’t hardcoded; it figured out how to execute it on its own.

I was completely addicted in November and December. Although online response was lukewarm, every time I demonstrated it to friends, they wanted it, yet I always said it wasn’t ready.

So, I did something even crazier: I created a Discord server and dropped the bot into it. At that time, there were no sandboxes or security measures. I basically used OpenClaw to build OpenClaw, then used it to debug itself.

I asked the model, “Do you see this tool?” It said no. I told it to look at its own source code, and it actually did. Only after seeing this process did people truly understand what it was doing.

I didn’t give it all the information but provided some memory-like data. I monitored it closely because prompt injection issues hadn’t been fully resolved. Newer models are indeed more stable.

I placed a “canary” file defining values and alignment principles. The file wasn’t public, but many wanted to access it. Some tried to obtain it via prompt injection by pasting large blocks of code. The model refused directly, sometimes even mocking them. Despite this, I remained uneasy.

On the first night, traffic was high. I turned it off to sleep, only to wake up and find 800 messages; it had replied to all of them. It turns out the system had an auto-restart service. I thought I had shut it down, but five seconds later, it restarted itself. Later, I added a sandbox, confining it to a smaller container. It even named its Mac Studio “Castle.”

How should I put this? These models really know how to find ways!

PRs Have Changed Flavor: Intent Takes Precedence Over Code

Q: I’m curious, where do you get so many good ideas?

Peter Steinberger: I think the key is that the barrier to turning ideas into reality has lowered significantly.

Even if I find an open-source tool that solves 70% of a problem, I’ll directly fill in the remaining 30% myself. A year ago, this would have been unrealistic. Now, as long as I provide a prompt, it runs on my computer screen.

Q: Your view on the value of code has also changed how you handle open source. OpenClaw already has 2,000 Pull Requests (PRs). You mentioned that some PRs are more like prompt requests. Does this mean intent is more important than the code itself?

Peter Steinberger: Reviewing PRs now and

Things have changed. Sometimes, carefully reviewing a Pull Request (PR) takes more time than rewriting it myself.

I am more cautious with contributions from strangers because I cannot be sure if they understand the entire system. In contrast, I default to assuming models are not malicious; their misunderstandings are simply misalignments in intent.

Therefore, my first step when reviewing a PR is not to read the code line by line, but to clarify: What problem is this trying to solve?

For me, intent matters more than implementation style. Many contributors provide local solutions, but the real challenge lies in understanding the impact of integrating that feature into the existing architecture.

I might discuss with the model for over ten minutes to determine whether this is an architectural issue, an implementation detail, a platform-specific concern, or something that should be developed as a general capability. Only after establishing the direction do I handle the code, branches, and merges.

Even if it takes more time, I always retain the contributor’s attribution because they often bring good ideas.

OpenClaw’s Next Hurdle: Security

Q: What is your current vision for OpenClaw? Do you also see yourself as a pioneer in the “personal AI agent” paradigm?

Peter Steinberger: I am looking for a balance: it needs to be simple enough for my mother to install and use, yet interesting and hackable enough to engage power users. This is actually quite difficult.

For a long time, my default installation method was cloning, building, and running the source code directly on your hard drive. The Agent works within and understands that source code.

If you dislike certain logic, you can simply instruct it, and it may even self-optimize. This has encouraged many people who have never submitted a PR to participate. Often, what they lack is not ideas, but experience in long-term software maintenance; thus, they primarily submit their intent rather than complete implementations.

At the same time, security issues with OpenClaw have been a headache. For example, I had a web service that was initially just a debugging tool, designed to be used only within trusted networks by default.

I left configuration options to accommodate complex network environments, but some users exposed it directly to the public internet. Although I repeatedly emphasized in the documentation not to do this, some still did.

Security researchers point out that it lacks public-facing restrictions. My response is that it was never designed for the public internet. However, since it can be configured this way, its risk rating naturally increases.

I did struggle with this issue. Eventually, I brought in a security expert as a key focus. I cannot prevent people from using it for purposes not originally planned or supported, so a more realistic approach is to accommodate these usage patterns while helping users avoid obvious pitfalls.

This is the charm of open source: people create things you never imagined, which can be both beautiful and somewhat crazy.

The Era of Code Is Fading; Productivity Is Soaring

Q: I checked your GitHub this morning. Over the past year, you have contributed to more than 120 projects. Your activity graph was initially light but became very dense in October and November. What happened?

Peter Steinberger: It is because I switched to Codex later on.

The change is not just that the model has become smarter; the entire toolset has also become more intuitive, and I have learned how to integrate it into my daily workflow.

Many people say they tried AI tools but found them unusable. I tend to believe that the methodology has not kept pace. This is truly a craft that requires practice. Now, I can roughly judge which prompts will be effective and how long it will take to get results.

If progress stalls for too long, I ask myself whether there is an architectural issue, if the problem decomposition is incorrect, or if we have gone off track. That feeling is very similar to hitting a wall while writing code manually.

Regarding configuration, I also fell into traps during that phase, which I call the “Agent Trap”:

Tinkering endlessly with configurations looks sophisticated, but it does not actually improve efficiency. Now, my approach is much simpler: I treat the model as a conversational partner. I directly state what I want and then ask, “Do you have any questions?” The model will infer the premises itself. Having it ask questions first helps avoid many detours.

Each new session is essentially a blank slate for the model. You must maintain the global context yourself and guide it to focus on key points. My approach has always been straightforward: do not overcomplicate things with gimmicks; stay focused on the problem itself. The larger the project, the better it becomes when broken down into non-interfering modules that can be advanced in parallel.

Q: You mentioned that you rarely read code now. Can you elaborate on this?

Peter Steinberger: To be honest, most code is quite boring.

Much of it involves merely transforming data structures or presenting results to users. I feel sufficient understanding comes from grasping what the generated content does; my mental model generally aligns with what the code produces.

In the past, when I led teams, I had to accept that engineers’ code would not always match my exact vision. The same applies now.

I adjust the codebase to allow Agents to perform better. This is not entirely different from optimizing for human engineers; the code does not need to meet 100% of my aesthetic standards. The key is ensuring the direction is correct. If performance issues truly arise, I will optimize them specifically.

Q: What do you find most interesting about building things today?

Peter Steinberger: Interestingly, the entire toolchain is changing, and even the definition of a “developer” is evolving.

Theoretically, anyone can now bring their ideas to life. When I first started using these new tools, I experienced a genuine surge in dopamine.

I initially used Claude Code, where its success rate might have only been 30-40%. Yet, it was still shocking to me because I suddenly realized that I could build anything. Software remains complex, but your speed of execution has increased dramatically.

Q: Many developers outside of San Francisco have not yet fully embraced Code and Agent tools. What advice would you give them?

Peter Steinberger: My biggest advice is to approach these tools with a playful mindset and work on that project you have always wanted to do but never started.

If you are action-oriented, willing to get your hands dirty, and quick-thinking, this is a fantastic era.

The real differentiation will come from who can best utilize these tools. For builders who are willing to embrace new technologies, maintain curiosity, and rapidly turn ideas into reality, the opportunities are far greater than before.

I believe the next year will see rapid changes; 2026 will be particularly interesting.