What Agentic Engineers Can Learn from the OpenClaw Creator

Peter Steinberger built OpenClaw in eight months. It went viral, got acquisition offers from OpenAI and Meta, and now has hundreds of thousands of users. On Lex Fridman Podcast #491, he talked through what he actually learned building and shipping an agent at that scale.

These are the parts worth stealing.

Give Your Agent a Map of Itself

Steinberger made OpenClaw aware of its own internals — where its source code lives, what model it runs, what tools it has, what mode it’s in:

“I made the agent very aware. It knows what its source code is. It understands how it sits and runs in its own harness. It knows where documentation is. It knows which model it runs. It knows if you turn on verbose or reasoning mode. I wanted it to be more humanlike. So it understands its own system.”

That decision had a side effect he didn’t plan for. Once the agent could see its own code, users started asking it to change itself:

“That made it very easy for an agent to — oh, you don’t like anything? You just prompted into existence and then the agent would just modify its own software. You know, we have people talk about self-modifying software. I just built it and didn’t even plan it so much. It just happened.”

The practical lesson: if your agent knows its own config, its own tool inventory, and its own documentation, it can troubleshoot itself. If it can’t answer “what tools do you have?” — that’s a gap.

Debug Through the Agent, Not Around It

When something breaks in OpenClaw, Steinberger doesn’t just read the stack trace. He talks to the agent:

“Hey, what tools do you see? Can you call the tool yourself? Oh, what error do you see? Read the source code. Figure out what’s the problem. I just found it an incredibly fun way — the very agent and software that you use is used to debug itself.”

This is self-introspection as a debugging method. The agent reads its own source, examines its own runtime state, and proposes fixes. Before you reach for traditional debugging, try asking the agent what it sees.

Flow State Still Exists — It’s Just Different

Steinberger acknowledged the loss directly. He used to get deep into flow writing code. That specific feeling is going away:

“I spent a lot of time tinkering, just being really deep in the flow and just cranking out code and finding really beautiful solutions. And yes, in a way it’s sad because that will go away.”

But then:

“You can get the same state of flow. I get a similar state of flow by working with agents and building and thinking really hard about problems. It is different. And it’s okay to mourn it. But that’s not something we can fight.”

And Lex, on what that shift actually feels like from the inside:

“While I don’t write the code, I very much feel like I’m in the driver’s seat and I am writing the code, you know?”

Steinberger’s response: “You’ll still be a programmer. It’s just the activity of a programmer is different.”

Programming Becomes Like Knitting

Steinberger’s analogy for what happens to traditional hand-written code:

“Programming is just a part of building products. Maybe AI does replace programmers eventually, but there’s so much more to that art. What do you actually want to build? How should it feel? How’s the architecture? I don’t think AI will replace all of that.”

“The actual art of programming — it will stay there, but it’s going to be like knitting. People do that because they like it, not because it makes any sense.”

The reframe: you’re not losing your job, you’re gaining new dimensions. Architecture, product feel, agent orchestration. Lex put it well:

“Programmers are generally best equipped at this moment in history to learn the language, to empathize with agents, to learn the language of agents, to feel the CLI.”

Steinberger agreed: “At some point it’s just going to be called coding again and it’s just going to be the new normal.”

Review PRs Like a Conversation

Steinberger gets a lot of pull requests. His review process is an agent conversation, not a line-by-line read:

“When I review a pull request, I first just — review this PR. My first question is, ‘Do you understand the intent of the PR?’ I don’t even care about the implementation. In almost all PRs, a person has a problem, person tries to solve the problem, person sends PR. They either want to fix a bug, add a feature. Usually one of those two.”

Once the agent understands the intent, he escalates:

“And then Codex will be like, ‘Yeah, it’s quite clear person tried this and this.’ Is this the most optimal way to do it? ‘Not really.’ And then I start like, ‘Okay. What would be a better way? Have you looked into this part, this part, this part?’ And then most likely, Codex didn’t yet, because its context size is empty, right? So you point them into parts where you have the system understanding that it didn’t see yet.”

Then it becomes a design discussion:

“We have a discussion of how would the optimal way to solve this look like? And then you can still go farther and say, ‘Could we make that even better if we did a larger refactor?’ And then I consider, okay, is this worth the refactor, or should we keep that for later? Many times I just do the refactor because refactors are cheap now.”

The key insight is treating the agent like a capable engineer who sometimes needs steering, not a tool that produces output:

“You have to approach it like a discussion with a very capable engineer who generally comes up with good solutions. Sometimes needs a little help.”

Build for Agents, Not for Yourself

Steinberger made a deliberate choice to optimize his codebase for agent navigation rather than his own preferences:

“I’m not building the code base to be perfect for me, but I want to build a code base that is very easy for an agent to navigate.”

That means letting go of naming conventions you’d personally choose:

“Don’t fight the name they pick, because it’s most likely, like, in the weights, the name that’s most obvious. Next time they do a search, they’ll look for that name. If I decide, oh, no, I don’t like the name, I’ll just make it harder for them.”

Lex compared this to leading a team of engineers — you have to accept that the code won’t be written exactly how you’d write it:

“Some level of acceptance that, yes, maybe the code will not be as perfect. Yes, I would have done it differently. But also, yes, this is a working solution, and in the future, if it actually turns out to be too slow or problematic, we can always redo it.”

Accept Prompt Requests

When OpenClaw’s self-modifying capability attracted non-programmers, they started submitting pull requests that were really just natural language instructions. Steinberger didn’t gatekeep:

“I call them prompt requests in the end. But I don’t want to pull that down, because every time someone made the first pull request is a win for our society. Doesn’t matter how shitty it is — you got to start somewhere.”

“I found it very meaningful that I built something that people love to think of so much that they actually start to learn how open source works.”

There’s something here for teams too. Not every contribution needs to be code. Some people describe what should change in plain language, and the agent translates. That’s a valid workflow.

The full conversation is worth the three hours. But if you only have five minutes, these are the parts that change how you work.

🪨