Peter Steinberger on designing workflows for AI agents that actually work

Austrian programmer Peter Steinberger spent 13 years building PSPDFKit before stepping back from entrepreneurship. That changed when AI agents matured. Today, he leads the OpenClaw foundation—an open source AI assistant that operates locally and integrates with chat applications—while working at OpenAI to advance personal AI agents.

Recently, Steinberger sat down with a16z speedrun's Andrew Chen in front of a gathering of speedrun founders to discuss what software development looks like when agents handle the coding.

The shift from skepticism to reliance

When asked how his approach to working with agents has transformed over the past year, Steinberger described a dramatic reversal in his expectations:

Agents changed so much. When I started last year, I got excited when they got something right. And now, if something doesn't go right, I question myself. I think we are very much at the point where you don't have to write code yourself anymore, but it's very important to think about: what can I do so my agent can do its best work? How can I design the – call it loop, or graph, or whatever – so that the agent not just writes the code, but then also can review the code until it's right, and also has all the tools so you can test everything end to end?

Peter Steinberger

He emphasized that success with agents requires rethinking the engineer's role entirely. Rather than writing code directly, the focus shifts to pipeline design—structuring the path from initial intent to final outcome. The quality of this design determines how well agents perform.

Why some people succeed with agents and others don't

Steinberger identified a persistent puzzle: certain individuals extract far more value from agent collaboration than others. His explanation traces back to his experience running a company:

Especially last year, there were still so many people AI wouldn't work for, and there were other people who were very successful. In my head, both existed, and it took me a while to understand why that's the case – and why I'm in this group and not that group. I think a big reason is because I ran a company before.

Peter Steinberger

Managing agents, he explained, parallels managing people. The critical mental shift involves accepting that outcomes won't match personal preferences—but that shouldn't matter if the goal gets achieved.

When it transitioned from 'I write the code' to 'I command a group of people who write the code for me,' I had to accept that the code will not be as perfect as I would write it. I could micromanage them, I could breathe down their necks, and then we would have a really bad time, and they would leave. My agents would not leave, but we'd still have a very bad time. So it's just accepting that: okay, maybe it's not exactly how I want it, but maybe that shouldn't matter anymore. Does it get me to my goal? Yes. Maybe the agent does it in a way I'm not a fan of… but again, my job is to optimize for the agents. I'm not going to read all the code.

Peter Steinberger

Orchestrating multiple agents at scale

When asked to describe his concrete workflow, Steinberger outlined a system that has evolved significantly in recent months:

Even six months ago, when you had a new task, you would clear the session, do the task, and then clear the session again, because the model would degrade, and so on. People already tried orchestrating their sessions, but it didn't work so well. Now that's just my default.

Peter Steinberger

He manages numerous open source projects through an orchestrator that automatically builds pull requests and runs tests whenever issues arrive. This allows him to operate as an executive rather than an individual contributor—reviewing decisions, providing direction, and stepping in directly only for critical features.

I have so many open source projects, I can't look at them one by one. There are some bigger ones where I do, because I want to try certain ideas, but the others are basically handled by my open source orchestrator: any time an issue comes in, it already builds a PR and tests it. So when I look at it and I need to make decisions, I'm kind of like the executive. I come in and ask my agent to walk me through decisions, it presents me ideas or problems, and then I give the direction and it goes off and works with the others. It automatically does the releases. That doesn't work great for everything, but it works great for a lot of the noise… a lot of the little things that don't really require my attention anymore. And then for important features, I just pair one-on-one with an agent.

Peter Steinberger

The authenticity problem

One limitation of AI that frustrates Steinberger is its inability to replicate individual voice and style. He's equally annoyed when others send him AI-generated communications:

No matter what you work on, invest in your personal brand. Because in this day and age, the hardest thing is actually getting eyeballs. You have no clue how many people every day try to send me their slop – half a page plus a link, 'please look at it.' I see those em-dashes, or all these telltale signs of AI-speak, and I'll just block you. Sometimes I reply 'this reads like slop,' but that's the only reply you'll ever get.

Peter Steinberger

He warned that using AI to amplify messaging backfires when audiences detect synthetic patterns. The solution, he argued, is demonstrating genuine effort and maintaining human distinctiveness.

So be very careful about trying to use AI to get your message out, because a lot of people will be triggered. And even more so: if you write something for your website and you want to use AI to make it more professional, it will add those telltale signs. And then people don't know if your blog post is actually very thoughtful and just a little bit rewritten, or if it's just a three-word prompt that generates two pages. How could they know, right? As soon as they smell it, people automatically, subconsciously or consciously, degrade the value of it.

Peter Steinberger

Managing scope in an age of infinite feature generation

Handling community contributions to OpenClaw presents its own challenge. When Chen asked how Steinberger filters which suggestions warrant serious consideration, he acknowledged a critical mistake:

I would say that's one of my mistakes on OpenClaw as well: saying yes to too many things. It's so easy to just prompt a new feature into existence. And the feature is never the problem. The problem is the 19 other features that have to interact with that feature, and thinking about how this all fits into your system. That's such a complex problem that your agent will not be able to help you with it. Agents go in every time knowing nothing about your codebase, and they find their way – they can navigate large codebases very well. But having this understanding of the system – does this really make sense? Would this contradict that thing over there? – that's a bit beyond what the agents are really good at.

Peter Steinberger

He also emphasized that contributors who demonstrate genuine effort stand out. In a world where agents can generate code from minimal prompts, proof of human investment becomes valuable currency.

And it also kind of sucks when people put a lot of time into a PR and then you just say no. But then again, you don't even know, right? Did people put a lot of time into their PR, or is it just a three-word prompt and the agent put a lot of time into the PR? So again: if you want attention, be human. Be different. For once, I would love a PR that has typos, that's handwritten. Or submit your logs, so I have proof of effort.

Peter Steinberger

Building for yourself, not your critics

OpenClaw faced security criticism and controversy that prompted Steinberger to redirect his efforts toward appeasing external concerns. This decision, he reflected, damaged the product:

The thing that had a really big emotional impact on me was all the security blog posts, and then the security reports. So many overblown, fabricated claims, with everybody optimizing for clicks… But I suddenly felt this urge of responsibility: oh, now so many people use it, so I need to work really hard to make it secure. And then I worked really hard to make it secure, for months. Basically, that was all I did. And it really damaged the product. At some point, I stopped making something for myself and I started making something for other people. I put things into place that I didn't really agree with, or I tried to change what it's for, to be for a different use case… even though I don't use it like [that]. And of course, then it breaks.

Peter Steinberger

The experience taught him that personal enjoyment and self-use are non-negotiable for sustainable product development. When he lost the joy, the product suffered.

A lot of the features that were added were making it slower, making it harder for people to use. Definitely safer. But I lost the fun. That's probably the key thing. If you build something: number one, you should use it yourself, otherwise you're building the wrong thing. Number two, you should have fun. I always do my best work if I enjoy what I do. And then I can work much harder, longer, and it takes me less energy. But this thing was incredibly draining. I was not enjoying it at all. ... I kind of lost the joy, and then that reflected in the product. Eventually, we got it right. Now there's a team; now we actually do things the right way.

Peter Steinberger