Peter Steinberger on building in the agent era

Have strong feelings about the future of work? Share your opinions on all things work (996 culture, AI in interviews, etc.). Take the a16z speedrun talent survey here.

The Austrian programmer and entrepreneur Peter Steinberger spent 13 years building PSPDFKit before selling it and swearing off ever doing another company. Then agents got good.

Peter’s now known throughout the world as the creator of OpenClaw, the open source AI assistant that runs locally on your machine and talks to you through chat apps. Peter now runs the OpenClaw foundation and works at OpenAI, where he’s shaping the future of personal AI agents.

Last week Peter sat down with a16z speedrun’s Andrew Chen in front of a room full of speedrun founders to talk about what building looks like when the agents write the code.

Watch our full conversation with Peter above, or check out the highlights below:

Andrew’s first question to Peter was about how his own usage of agents has been evolving over the last year. His response:

“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?

“Ultimately you design a pipeline from ‘this is what I want’ to ‘this is the outcome,’ and the better you do that, the better your outcome will be. So this is now part of the role of software engineering: engineering how my agents can do their best job.”

Peter says one of the big mysteries he’s been struggling with is why some people seem to get so much more out of working with agents compared to others:

“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.

“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.”

Andrew prodded for more details on Peter’s own workflow: “Maybe you can say a little bit concretely about how you set up projects for yourself now,” he asked. “What’s a good loop that you’ve engineered?”

“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.

“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.

“Think of it like interacting with a different team, or a company: usually you interact with the manager, but sometimes something’s important and you pair directly with one of the engineers. That’s how I see my army of agents.”

Of course, there are still some hard limits when working with AI, and one Peter says he’s become extremely annoyed by is the inability of AI to write in his own voice. In fact, he’s irritated when others send him AI-written messages as well:

“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.

“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.”

Ultimately, Peter advises, if you want attention, be human. Be different. Show proof of effort, even if that means leaving the typos in.

Filtering messages isn’t the only problem Peter has to deal with when running an open source project like OpenClaw. Andrew asked how he handles the influx of ideas from users who want to help make the software better as well. “Do you have the same kind of filtering process for what to take seriously or not,” he asked, “given that there’s an infinite amount of code being generated these days?”

Peter’s response:

“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.

“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.”

As with any tech product, OpenClaw has drawn its share of criticism and controversy. Peter said the sheer scale of the reaction to OpenClaw at one point led him to learn a lesson about the importance of building for yourself instead of the critics:

“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.

“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.”

That’s it for this week! Huge thanks to Peter for his candor. For more weekly dives into the world of early-stage startups, subscribe below.

You are receiving this newsletter since you opted in earlier; if you would like to opt out of future newsletters, you can unsubscribe immediately.

This newsletter is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. This newsletter may link to other websites and certain information contained herein has been obtained from third-party sources. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation.

References to any companies, securities, or digital assets are for illustrative purposes only and do not constitute an investment recommendation or offer to provide investment advisory services. Any references to companies are for illustrative purposes only; please see a16z.com/investments. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund which should be read in their entirety.) Past performance is not indicative of future results.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Content in this newsletter speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see a16z.com/disclosures for additional important details.