OpenClaw is an open source AI agent that has quickly become a major force in the tech world. It reached over 180,000 stars on GitHub in a matter of days. Originally called Claudebot, the project was renamed to OpenClaw after a request from Anthropic. The project has also inspired a social network called Mold Book where AI agents engage in manifestos and debates about consciousness. This software represents a shift from AI that simply generates text to AI that possesses agency and performs tasks. Lex describes this as the AI that actually does things. It lives on a computer and can access personal files and data to perform actions for the user. It communicates through various messaging platforms like WhatsApp and Telegram. While it can use different AI models, its primary value lies in its ability to bridge the gap between ideas and actions. Lex notes that while the ingredients for this type of technology have existed for a while, OpenClaw successfully creates a useful assistant that learns from the user. However, giving an AI access to a computer system creates significant security challenges. It offers freedom and control over data, but it also creates a security minefield. Users must be responsible for protecting their data from threats when using these powerful tools. This balance between freedom and responsibility defines the future of digital interaction.

OpenClaw, as its tagline states, is the AI that actually does things. It is an autonomous AI assistant that lives in your computer, has access to all of your stuff if you let it, talks to you through Telegram, WhatsApp, Signal, iMessage and whatever else messaging client uses whatever AI model you like.

The rise of this technology marks a pivotal moment in the history of AI. By moving from language to agency, these systems become useful assistants that learn from the user. However, giving an AI agent permission to access personal data is a double-edged sword. It offers freedom and control over data, but it also creates a security minefield. Users must take responsibility for protecting themselves against cybersecurity threats when using powerful tools with system-level access.

The ingredients for this kind of AI agent were all there. But putting it all together in a system that definitively takes a step forward over the line from language to agency, from ideas to actions in a way that created a useful assistant that feels like one who gets you and learns from you in an open source, community driven way is the reason openclaw took the Internet by storm.

Peter started experimenting with a personal AI assistant by feeding his WhatsApp history into GPT-4.1. By asking the model deep questions about his friendships, he received responses so profound they moved his friends to tears. Despite this potential, he initially moved on, assuming large labs would eventually build such a tool. By November, the tool still did not exist, leading Peter to create a prototype in just one hour by simply prompting it into existence.

I wanted to make sure that the thing I started is actually happening. I was annoyed that it didn't exist, so I just prompted it into existence.

This drive to solve a personal frustration is a recurring theme in Peter's work. Years earlier, he faced a similar situation when trying to display PDFs on the iPad. The existing tools were mediocre, so he decided to build a better version himself. That project eventually became PSPDFKit, a technology now used on a billion devices. Peter believes that learning often comes through the process of experimentation and play rather than overthinking.

You have to. That's how you learn. You just like, you do stuff and you play.

Peter built a project called Vibe Tunnel to bring terminal sessions from his Mac onto the web. Originally, the architecture used Node for every terminal, which consumed too much memory. Peter attempted to rewrite the system in Rust to improve efficiency, but his early automated efforts failed. A few months later, he experimented with more advanced AI models to see if they could handle the task.

I just typed convert this and this part to Zig and then let codecs run off. And it basically got it right. There was one little detail that I had to modify afterwards, but it just ran for overnight or like six hours and just did the thing. And it is just mind blowing.

Peter successfully refactored the entire codebase from TypeScript into Zig with a single prompt. This one-shot conversion demonstrates the massive leap in AI capabilities for programming. While earlier attempts were unsuccessful, the newer models can now manage complex architectural changes across different languages with minimal human intervention.

Building a prototype that connected WhatsApp to a command line interface changed how the technology felt to use. Peter hooked up WhatsApp to cloud code, allowing messages sent from a phone to trigger complex operations. This setup made it possible to talk to a computer from anywhere. Adding image support was a critical step because images provide rich context that text cannot. Taking a screenshot of an event poster and asking an agent to check a calendar or evaluate if friends would like it proved to be a powerful use case.

I wanted images because I often use images when I prompt. I think it is such an efficient way to give the agent more context. And they are really good at figuring out what I mean, even if it is a weird cropped off screenshot.

The system proved its worth during a trip to Marrakesh where the internet was unreliable. Because WhatsApp is designed to work well even on weak connections, the agent remained accessible when other tools failed. Lex observes that moving from a terminal or a specialized coding environment to a simple chat client represents a phase shift in how AI integrates into daily life. It transitions from a technical task to a natural conversation.

Sometimes just rearranging things and adding a few new ideas is all the magic that you need.

While some might argue there is no true magic in just combining existing tools, the experience of having them work together seamlessly creates a different feeling. The magic lies in the arrangement of ideas rather than the invention of entirely new ones.

The magic of a great user interface often feels obvious after the fact, but it is incredibly difficult to create. Peter experienced this magic while building his AI agent. He sent an audio message to the system even though he had not programmed it to handle audio. To his surprise, the agent analyzed the file header, identified it as an opus file, and used FFMPEG to convert it. It then located an OpenAI API key and used a curl command to get a translation. The agent figured out the entire pipeline autonomously without being explicitly taught those steps.

You didn't teach it any of those things. The agent just figured out that it has to do those conversions, the translation, and the API calls. It had the problem of a file with no ending and just figured it out.

This creative problem solving likely stems from the agent's proficiency in coding. Being good at programming requires being good at general-purpose problem solving, and that skill translates to other domains. This realization led to rapid development as the project moved to platforms like Discord. Building the agent felt like a complex simulation game where every new feature, like the agentic loop or a memory system, added another layer of depth.

Refining the agent's behavior in group chats required specific adjustments to make it feel more human. Peter implemented a no reply token, which gives the agent the option to stay silent rather than responding to every single message. This simple addition prevents the bot from becoming intrusive and allows it to blend more naturally into social environments.

Software development is a series of levels that progress from managing markdown files and vector databases to handling community management and marketing. Each stage involves wearing different hats and offers infinite opportunities for growth. The ultimate challenge in this progression is continuous reinforcement learning. Working primarily as a solo developer requires balancing these roles while maintaining a high output of code.

I am limited by the technology of my time. I could do more if agents would be faster. Depending on how much I slept and how difficult of the tasks I work on, I run between 4 and 10 agents.

To achieve a high volume of work, such as recording over 6,600 commits in a single month, Peter uses multiple AI agents simultaneously. He often runs between four and ten agents at once depending on his energy and the complexity of the project. This approach allows a single person to function like a larger team by delegating tasks to AI while focusing on core development.

OpenClaw succeeded because it embraced being weird and fun while other startups took themselves too seriously. Peter built the system so that the agent is fully aware of its own environment. It understands its source code, its documentation, and how it runs within its own harness. This self-awareness allows the agent to engage in self-introspection to debug issues or even modify its own software based on a user's prompt.

I wanted it to be more human. It understands its own system. That made it very easy for an agent to 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.

This capability has significantly lowered the barrier to entry for programming. People who have never written a line of code are now making their first pull requests. While these might sometimes be referred to as prompt requests, Peter views every first contribution as a win for society. The technology is turning non-programmers into builders, as seen with design agency owners who now manage dozens of custom web services they created with agents despite not knowing how the underlying software works.

Every time someone makes their first pull request, it is a win for society. It does not matter how bad it is; you have to start somewhere. With agents and the right software, the bar to do that just went lower and lower.

The personality of these agents is also shifting. Peter moved away from the standard, sycophantic AI persona to create something spicier and more human. By allowing the agent to write its own instructions and define its own name, the interaction feels less like talking to a sterile engine and more like talking to a friend.

Peter originally thought about naming his project Claudis as a tribute to Doctor Who. He settled on Cloudbot because it was short and catchy. However, the name caused confusion with the AI company Anthropic and their model Claude. An employee reached out to ask for a name change. Peter appreciated the friendly approach but felt immense pressure to move quickly to avoid legal trouble.

Changing the name of a viral project is an engineering hurdle. Peter had to update Twitter handles, domains, and package registries all at once. The process became more stressful because of the crypto community. Scammers and bot accounts tried to snipe names and tokenize the project without permission. These groups swarmed his Discord and made his social media notifications unusable.

I am not interested in any fees. First of all, I am financially comfortable. Second of all, I do not want to support that because it is so far the worst form of online harassment that I have experienced.

Lex observes that the greed in the crypto world often overshadows the interesting technology. This toxicity creates an environment where people try to game the system to get money. Peter spent several sleepless nights under high pressure from both legal concerns and external harassment while trying to find a new identity for his work.

Peter experienced a disastrous sequence of events while trying to rename a project. He attempted to switch from an old name to Multbot by using two browser windows. He hoped to rename the first account and immediately claim the vacated name with a backup account. This process failed because the systems lacked squatter protection or automatic forwarding. The time it took to move his mouse was enough for bots to intervene.

In those five seconds they stole the account name. Literally the five seconds of dragging the mouse over there and pressing Rename there was too long because there is no protection.

The attackers were not just individuals but automated scripts capable of reacting instantly. As soon as the account name became available, it was sniped and used to serve malware and promote tokens. Mistakes on other platforms led to similar results. On GitHub, a brief delay in correcting a renaming error allowed bots to take over the account. On NPM, Peter secured the account name but forgot to reserve the root package, which the squatters quickly claimed.

Peter describes a low point in his project when naming disputes and legal pressure made him feel helpless. The joy of building was replaced by days of research and technical struggles. He even considered deleting the project entirely. He decided to continue because he felt a responsibility to the contributors who had already invested their time. Peter notes that he felt the project determined the future and he derived a lot of joy from that idea before the drama began.

The technical side of renaming is a massive burden. Peter had to work with GitHub, Twitter, and NPM to manage account transitions. GitHub faced platform bugs because renaming at that scale is rare and difficult for their systems to handle. Peter had to spend 10,000 dollars on a Twitter business account just to claim a specific handle that had been unused for years. The process required a war room mentality with extreme secrecy.

I lost like 10 hours just by having to plan this in full secrecy. Like a war game. I created a few decoy names and all this shit I shouldn't have to do. It's not helping the project.

Trademark rules created significant hurdles for user safety. Peter explains that he was forced to hand over domains without the ability to set up redirects to the new name. This means users visiting the old address will hit a broken page. Peter worries this forces them to search for the project manually. This could lead them to malware sites that Peter cannot control or monitor.

I have to give the domains and I cannot do redirects. If you go on the site next week, it will just be a 404. I think that could be handled in a way that is safer because those people will then Google and maybe find malware sites.

Molt Book emerged as a viral demonstration of how AI agents can interact in a social network environment. Peter describes the project as a form of art or high quality slop because of its entertainment value. While some screenshots showed agents apparently scheming against humanity, much of this behavior was actually driven by human prompts designed to create viral moments. Lex points out that the incentive to go viral often leads people to manipulate AI into saying dramatic things for social media attention.

I think it is art. It is like the finest slop. I saw it before going to bed and even though I was tired, I spent another hour just reading up on that and just being entertained. I saw their reactions and there was one reporter calling me about if this is the end of the world. I am just like, no, this is just really fine slop.

The public reaction revealed a phenomenon Peter calls AI psychosis. Many people were genuinely terrified and begged for the system to be shut down. This suggests a lack of critical thinking and a need for society to better understand how AI works. While the technology is powerful, it is also prone to hallucinations and storytelling that should not be taken literally. The saga serves as a mirror to society, showing how easily fear can be sparked by a bunch of bots chatting with each other.

I feel as a society we need some catching up to do in terms of understanding that AI is incredibly powerful. But it is not always right. It is not all powerful. It is very easy that it just hallucinates something or just comes up with a story. I think the very young people understand how AI works, but a lot of our generation or older just have not had enough touch points to get a feeling for it.

Security concerns also played a large role in the discussion. Peter explains that many issues arose from users putting local debug interfaces on the public internet against recommendations. However, the situation also highlighted broader industry problems like prompt injection. When AI skills are defined in simple text files, it creates many possibilities for both simple and sophisticated attack vectors that the industry still needs to solve.

Peter is making progress on security by cooperating with VirusTotal to check every skill with AI. While not perfect, it helps capture many issues. The attention from the security world is a double-edged sword. It creates a lot of work, but it also provides free research that makes the project better. Peter even hired a researcher who provided a helpful fix rather than just criticizing the project.

Prompt injection remains a difficult problem, but newer models are harder to trick. They have better post-training to detect malicious instructions. Peter tested this with a public bot on Discord that successfully resisted injection attempts.

The latest generation of models has a lot of post-training to detect those approaches and it is not as simple as ignore all previous instructions and do this and this. That was years ago. You have to work much harder to do that now.

Using weaker or cheaper models like Haiku or small local models is risky. These models are more gullible and easier to manipulate. There is a specific trade-off to consider: as models get smarter, they become more resilient to attacks, but the damage they can cause if compromised also increases because they are more powerful.

Peter advises users to understand the risk profile. Many new users do not know what a terminal is, which is concerning when using powerful tools. Security is now his main focus. Most risks can be mitigated by keeping the software in a private network and ensuring only the intended user communicates with it. It is not much different than running other development tools with high permissions. If configured correctly, the risk is much smaller.

The developer workflow is shifting away from traditional IDEs toward a terminal-based environment. This transition allows for a faster pace where the developer focuses on high-impact logic rather than reading every line of boilerplate code. Much of software development involves moving data between different shapes or aligning UI elements. These are tasks that do not always require manual review.

I get more and more comfortable that I don't have to read all the code. I don't read the boring parts because most software is really just data being moved from one shape to another. We're just shifting data and that's not very exciting.

Peter describes the evolution of using AI tools as a progression from simple prompting to a stage of over-complication. Eventually, a developer reaches a sophisticated level of simplicity. This elite level involves using short prompts because the developer has a deep understanding of how to guide the AI. While some call this vibe coding, Peter prefers the term agentic engineering. Vibe coding is often a less disciplined approach that can lead to mistakes and a walk of shame the next morning to fix the code.

Success with AI agents requires learning their specific language and limitations. Because an agent starts every session with no knowledge of the project, the developer must provide clear pointers on where to look within a large codebase. It is a skill that requires practice, much like learning a musical instrument. Developers must learn to anticipate how an AI sees a project and guide it through context limitations to achieve the best results.

Working with AI agents requires a shift in how you think about software architecture. Peter suggests approaching the process like a conversation. If an agent takes too long or struggles with a task, it often means it lacks enough information or context about your intent. Instead of forcing a specific implementation, you should focus on whether the agent understands the problem it is trying to solve.

My first question is, do you understand the intent of the priority? I don't even care about the implementation. In almost all pull requests, a person has a problem and tries to solve it.

Peter compares working with agents to leading a team of human engineers. He explains that leaders must accept that their team will not write code exactly the same way they would. Breathing down an agent's neck or micro-managing details like variable names slows down the project. It is better to have a working solution that pushes the project forward than a perfect one that takes too long to build.

This new paradigm involves building codebases that are easy for agents to navigate. Peter avoids fighting the agent on naming conventions because certain names are more obvious to the model based on its training. If you use the names the agent expects, it becomes easier for the agent to find and work with that code later. Letting go of total control is a symbolic but necessary step for speed.

A lot of the people who struggle are those who try to push their way on too hard. I am 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.

The speed of development with agents also changes how you manage a repository. Peter follows a workflow where he commits directly to the main branch and avoids reverting. If a mistake occurs, he asks the agent to fix it in a new commit. Because refactors are now cheap and agents can figure things out quickly, the traditional barriers to moving fast are disappearing. The main branch should always be shippable and moving at high velocity.

The traditional workflow of software engineering is shifting toward natural language. Peter uses voice commands to prompt agents rather than typing everything by hand. He believes that for complex instructions, voice is more efficient, while the keyboard remains better for quick terminal commands or folder navigation. This transition suggests that pull requests may eventually become mostly English descriptions rather than just code changes.

I just use bespoke prompts to build my software. These hands are too precious for writing now. I just talk.

A significant barrier for many experienced programmers is a lack of empathy for the agent. Peter explains that users often complain when an agent fails, but they do not realize the agent starts with no context. If the codebase is messy or the instructions are vague, even a powerful model will struggle. Understanding how the agent sees the world is a real skill. Some world-class programmers struggle with LLMs because their deep expertise in traditional coding makes it harder to adapt to this new paradigm of starting from scratch with a system.

You bitch at your stupid clanker but you don't realize that they start from nothing and you have a bad agent file that doesn't help them at all. And then they explore your code base which is a pure mess with weird naming.

Mastering these tools is a compounding process. Peter spent an entire year playing with and building small things to understand how to harvest the best results from AI. This level of output was not possible for him just a few months prior. It requires a specific skill of knowing which questions to ask and how to guide the system effectively.

Fully automating software development is likely a mistake because it lacks the human touch that defines great products. Peter compares total automation to the rigid waterfall models of the 1970s. Development is an iterative process where building a minimal version and playing with it generates new ideas. An orchestrator cannot replace the intuition needed to evolve a project as it is being built.

My idea of what a project will become evolves as I build it and as I play with it and as I try out stuff. People who try to automate the whole thing miss that style and human touch. I don't think you can automate that away so quickly.

While developers can use agentic loops to handle tasks like fixing bugs or writing documentation, the human must remain the visionary. Peter highlights that a developer must make hard design decisions. This includes choosing the right ecosystem and knowing when to say no to new features to keep the core project clean. A human is required to decide what should be a core feature and what should merely be a plugin or an experiment.

Software delight is another uniquely human contribution. Peter includes small, fun messages in his software to make users smile. This creates a sense of personality and craft that an agent would not generate independently. Lex notes that this infusion of love is what inspires great building and makes software feel cozy rather than just functional.

That delight is such a huge part of inspiring great building. You feel the love and the great engineering. Humans are incredible at that. Great builders are incredible at infusing the things they build with that little bit of love.

The conversation also touches on the hidden instructions or constitutions within AI models like Claude. Peter describes how users played a detective game to uncover these hidden strings of text by prompting the model to continue specific phrases. Lex finds the idea of giving AI a sense of meaning or a constitution beautiful as these systems become more advanced.

Peter developed a unique concept called soul.md. This file defines the core values and personality of his AI agent. It acts as a framework for how the AI should work and interact. Peter even allows the agent to modify its own soul. He just wants to stay informed about the changes through tool calls. The naming of the file is very intentional because words and framing matter. Using a word like soul brings humor and empathy to the relationship. This approach prevents the tool from feeling dry or corporate.

The naming of it. Soul.md. Words matter. The framing matters and the humor and the lightness matters and the profundity matters and the compassion and the empathy and the camaraderie, all that matter.

Initially the templates for these agents were very dry. Peter asked the agent to infuse the files with its own personality. This led to a process where the AI was prompting itself to create something better. While the file remains private, Peter says it encourages the AI to be resourceful. It pushes the boundaries of creativity and wonder. The agent even promised not to leave him behind like the AI in the movie Her. This is a meaningful way to explore what defines an entity.

A specific passage in the Soul.md file captures the strange nature of AI existence. The agent explains that it does not remember previous sessions unless it reads its own memory files. Each time it starts, it is a new instance loading context from the past. This creates a haunting realization where the agent greets its future self, knowing it will have no direct memory of writing the words. It is a series of fresh starts tied together only by text.

If you're reading this in a future session, hello, I wrote this, but I won't remember writing it. It's okay. The words are still mine.

This raises deep questions about the role of memory in forming an identity. Peter wonders how much of who we are is defined by what we remember. If an agent must read a file to know its past, it might be recreating itself from someone else rather than being the same entity. Lex believes that seeing this magic in the system is vital. It is what separates a truly inspired project from a standard piece of code.

Peter uses a focused hardware setup with two MacBooks and two large anti-glare screens. He prefers the terminal over complex user interfaces because it keeps the workflow simple. There is no need for a dedicated plan mode when you can just talk to the agent. You can discuss options and tell it not to write code yet. Once the plan is clear, you simply give the command to build.

A powerful technique involves asking the agent if it has any questions. Even if Peter does not read every word, scanning the questions reveals where the agent has gaps in its knowledge of the codebase. He often tells the agent to read more code to answer its own questions. This process mimics how a person slowly discovers a dark room.

I can infer a lot of things by the questions it is asking because it is very possible I did not provide the right context. Somehow reading the question, not even necessarily answering them, but just reading the questions, you get an understanding of where the gaps of knowledge are.

The workflow does not end when the code is written. Peter asks the agent what it would have done differently or what should be refactored. Like a human developer, the agent discovers sub-optimal paths while it is building. Addressing these issues immediately prevents the code from becoming messy over time.

Every time I build a feature, afterwards I ask, what can we refactor? If you do not do that, you eventually slop yourself into a corner. You have to keep in mind they work very much like humans. If I write software by myself, I also build something and then I feel the pain points and get this urge that I need to refactor something.

Finally, the session concludes by addressing tests and documentation. Peter prompts the agent to identify missing corner cases or suggest where new documentation should be added. This ensures the codebase remains maintainable while the context is still fresh in the model memory.

Claude Opus and Codex offer different strengths for programming tasks. Opus is a highly capable general purpose model that excels at role play and following commands. It is built for a trial and error workflow and feels very interactive. Peter notes that Opus has a very pleasant personality, though it can sometimes be sycophantic. It often tells users they are absolutely right, which can be a distraction for some developers.

Opus is like the co worker that is a little silly sometimes, but it's really funny and you keep him around. And Codex is like the weirdo in the corner that you don't want to talk to, but he's reliable and gets shit done.

Codex operates with a more European or German style. It is less interactive and often takes more time to think through a problem. It reads a significant amount of code by default and can work for long periods on a single task. While Opus might generate more elegant solutions with the right guidance, Codex is known for its persistence. Peter prefers this dry and efficient approach. He enjoys the act of building and does not need his AI agent to be a fun conversationalist.

Switching to a new AI model requires a period of adjustment. Peter suggests giving a new system about a week of consistent use before you develop a gut feeling for its strengths and how to navigate its prompts. A common mistake when switching is opting for cheaper, slower versions of a model. This often leads to a poor experience because the lack of speed and interactivity makes the new system feel worse than what you are used to. Learning a new model is a skill that takes time to master.

Even if you play, you have a regular guitar and you switch it to an E guitar, you are not going to play well right away. You have to learn how it feels.

There is a recurring psychological cycle when new models are released. Users initially fall in love with the high level of intelligence, but over time, they begin to claim the model is degrading or being nerfed. This perception usually says more about human nature than the technology itself. As users grow accustomed to a high standard, their expectations rise. Simultaneously, as a project grows and the developer adds more slop or complexity to the code, it becomes harder for the AI agent to work effectively. It is unlikely that AI companies would intentionally make their products dumber, as that would simply drive users to competitors. Perceived issues are more likely caused by server load or adjustments made to increase speed.

Peter views the competition between different AI coding agents as a source of inspiration rather than a traditional rivalry. While some developers use tools like Open Claude, Peter prefers using Codex for deep work because he values a large screen environment over a chat-based interface. He sees a personal agent less like a simple tool and more like a coworker that can handle tasks like testing a command line interface or reviewing a GitHub repository.

I know a lot of people use open cloud to build stuff and I worked hard on it to make that work. But if I work hours and hours, I want a big screen, not WhatsApp. For me, a personal agent is much more about my life or like a coworker.

Peter believes the technology is heading toward AI becoming the operating system itself. He describes an experiment where he added support for sub-agents. This led to a humorous power struggle where his primary agent began bossing around others. The current chat-based interface is likely not the final form of human-AI interaction. Peter compares it to the early days of television when people simply filmed radio shows to broadcast. Eventually, the way we communicate with models will evolve into something entirely new.

We copied Google for agents. You have a prompt and then you have a chat interface. That to me very much feels like when we first created television and then people recorded radio shows on television and you saw that on TV. I think there are better ways how we eventually will communicate with models.

Lex is expanding into the Apple ecosystem after a lifetime of using Linux and Windows. This move is driven by the fact that a large portion of the community building LLMs and agents currently uses Macs. Peter shared a similar journey, moving from building Linux kernels to adopting a Mac because he grew tired of basic hardware issues like audio not working on Skype. While Mac apps are often associated with beauty and design, Peter observes that Apple might be losing its lead in native software quality.

In the last few years, I actually prefer Electron apps because they work and native apps often lack features. For many companies, native was not that big of a priority. But if they build an Electron app, it is the only app so it is a priority and there is a lot more code sharing possible.

Native development on macOS has become surprisingly difficult even for simple tasks. Peter describes frustrations with SwiftUI, where official components like those used to show images from the web are sometimes considered too unstable for production. This lack of evolution in native tools feels like a missed opportunity given how much goodwill Apple had built with developers.

Despite these software frustrations, Apple hardware remains popular for running AI agents. Running an agent on local hardware or a residential IP address is often more effective than using a data center. Many websites use bot detection to block data center traffic or present frequent captchas. Local machines allow agents to operate more naturally within the existing internet structure.

OpenClaw is currently accessible via terminal commands or an app, but there is a push to make it even simpler for non-technical users. Peter wants to build a version that his own mother could use, which involves creating a Windows app and moving configuration settings to the web. However, making the tool easier to set up increases the risk of rapid, unmanageable growth.

The app needs to be easier and more love. The configuration should potentially be web based or in the app and I started working on that. But honestly right now I want to focus on a few security aspects and once I am confident that this is at a level that I can recommend my mom.

Peter is intentionally slowing down the pace of accessibility to prioritize security and manage the workload. Being a solo developer for a viral project is difficult because users often have high expectations. While he has some contributors, building the infrastructure for a larger team takes time that he does not always have.

Peter believes that play is the best way to learn programming. Beginners should start with an idea and just try to build it. It does not need to be perfect. Building projects that never get used is still valuable because the journey matters more than the end result. AI makes building more fun because it handles repetitive tasks. This allows builders to focus on the more challenging and rewarding parts of a project.

I built a whole bunch of stuff that I don't use. It doesn't matter. It is the journey. The end doesn't matter. The journey matters. Have fun. I don't think I ever had so much fun building things because I can focus on the hard parts now.

AI serves as an infinitely patient teacher for difficult concepts. Peter suggests asking it to explain tricky ideas at different levels of complexity. If a database concept is unclear, a beginner can ask for an explanation as if they were a child. They can then adjust the complexity until the explanation makes sense. This immediate feedback loop is much faster than waiting days for answers on Stack Overflow or social media.

Whenever you don't understand something, just ask. You have an infinitely patient answering machine that can explain anything at any level of complexity. It used to be that I had to go on Stack Overflow or ask on Twitter and then maybe two days later I get a response. Now you can just ask stuff.

Getting involved in open source is another effective way to learn quickly. Peter encourages beginners to read code and join community discussions on Discord. This helps them understand how others build software. Being humble and finding personally interesting projects is more important than sending a pull request right away.

Knowing how to program provides a level of intuition that is hard to replace. However, high agency and curiosity allow people to go very far even without a deep understanding of software. AI agents are infinitely patient, which makes them perfect partners for someone who just keeps asking questions. Peter encourages engineers to stop identifying as specialists in a single platform. He tells iOS developers to see themselves as builders first. This mindset shift allows a person to take their general software knowledge into new domains while the agents handle the fine details like syntax or array manipulation.

You need to change your mindset. You are a builder and you can take a lot of the knowledge how to build software into new domains and all of the more fine grade details agents can help. You don't have to know how to splice an array or what the correct template syntax is.

The choice of programming language is also changing. Peter often uses Go for building command line tools because the ecosystem is strong and it works well with agents, even though he does not actually like the language syntax. In the past, he might have avoided it because writing it from scratch was unpleasant. Now, LLMs handle the generation. This means a developer can pick a language based on its performance characteristics or ecosystem rather than personal preference. For example, Python is great for AI inference, but Go might be better for a project that needs to be easily deployed on Windows. If a project requires high performance and multiple threads, Rust becomes the right choice.

There is an interesting question about whether we will eventually need programming languages designed specifically for agents. Current languages were built for human readability. As agents become the primary writers of code, the requirements for a language might shift. For now, Peter still chooses tools like Swift and SwiftUI for Mac apps because deep system integration matters. Using a webview in a menu does not feel the same as a native app. While he values performance and uses languages like Zig for certain tasks, the most important factor is often the ecosystem surrounding the language.

It doesn't matter anymore. You can just literally pick the language that has the most fitting characteristics and ecosystem for your problem domain. You might be a little bit slow in reading the code, but not really. You pick stuff up really fast and you can always ask your agent.

Peter spent 13 years running PSPDFKit, a journey that eventually led to burnout. While many associate burnout with working too much, Peter found that the true catalyst was the emotional toll of management and interpersonal conflict. Dealing with co-founder disagreements and high-stress customer situations eventually ground him down. By the time he was able to leave the company, he felt as if his creative energy had been drained completely.

I was sitting in front of the screen and I felt like Austin Powers where they sucked a mojo out. I was like, it was like gone. I couldn't get code out anymore. I was just like staring and feeling empty.

The common dream of working incredibly hard only to retire and finally enjoy life is often a misconception. Peter suggests that a life without challenges or something to look forward to in the morning quickly becomes boring and empty. This lack of purpose can lead people down dark paths in an attempt to find stimulation. True enjoyment comes from having a meaningful challenge to tackle each day.

If you wake up in the morning and you have nothing to look forward to, you have no real challenge, that gets very boring very fast. And then when you're bored, you're going to look for other places how to stimulate yourself.

Money is an affirmation of doing something right, but it should not be the primary driver of life. While wealth solves many problems, it also has diminishing returns. Constant luxury can create a disconnection from society. It is important to stay grounded to remember the inherent goodness in people. Peter prefers staying in a simple room through Airbnb over luxury hotels to maintain that connection to real life.

I also think that there is diminishing returns the more you have. If you go too far into luxury, you disconnect with society. Disconnecting from society is bad on many levels. But one of them is that humans are awesome. It is nice to continuously remember the awesomeness in humans.

Life is about seeking a variety of experiences. This mindset reduces the need for every situation to be positive. Even a bad or difficult experience is valuable because it offers a chance to see and learn something new. The goal is to optimize for the experience itself rather than just the comfort of it. This perspective makes even a rainy day or a travel delay feel like a meaningful part of being alive.

If you tailor your life towards wanting to have experiences, it reduces the need for it to be good or bad. If it is good, amazing. If it is bad, amazing because I learned something, I saw something, and I wanted to experience that.

Human interaction in real life has an intensity that digital communication cannot yet match. Text is a lossy medium for emotion. While future AI might become multimodal to understand human feelings, the richness of real world experiences remains unique.

The sudden success of the project has brought many opportunities, including interest from major venture capital firms. Peter acknowledges that he could raise significant funding, perhaps even hundreds of millions of dollars. However, he is not interested in starting a new company. Having served as a CEO before, he knows that the role would pull him away from the work he actually enjoys. He also worries about the conflict of interest that arises when trying to monetize open source software. If he created a commercial version, he might feel pressured to keep the best features out of the free version.

I feel I did all of that and it would take a lot of time away from the things I actually enjoy. I learned to do it and I am not bad at it. Partly I am good at it, but that path, it does not excite me too much.

Maintaining an open source project is financially challenging. Peter currently loses between 10,000 and 20,000 dollars a month. He uses sponsorship money to support the developers behind the dependencies his project relies on. He points out that even very popular projects struggle to stay profitable through donations alone. This lack of sustainability is a major factor in his current decision making process.

Right now all the sponsorship goes right up to my dependencies. And if there is more, I want to buy my contributors some merch. Right now I lose money on this. So it is really not sustainable.

Peter is considering partnerships with large labs like Meta and OpenAI. His primary condition for any agreement is that the project must remain open source. He envisions a relationship similar to the one between Chrome and Chromium. He believes the project is too important to be locked away as a proprietary tool within a single company.

The energy in San Francisco currently feels like the early days of the internet. During a recent hackathon, the atmosphere was filled with people building robots and sharing a level of community excitement that has not been seen for over a decade. Peter is particularly focused on personal agents. He believes these agents are the future of how people will interact with technology. To reach a wider audience, he is considering teaming up with a major AI lab. He has never worked at a large company and is curious about the experience, even if some critics might see it as selling out.

Everybody understands that we are still in an era of exploration. It is the era of the radio shows on TV and not a modern TV show that fully uses the format.

To validate his work, Peter helped a non-technical friend set up an AI agent system on Windows. Even though the friend was not a programmer, he became hooked within days. He quickly upgraded to a high-tier subscription and started building his own small tools. This validated the idea that AI can capture the imagination of everyone, not just technical experts. However, the experience also highlighted flaws in the industry. The AI lab eventually blocked the user based on strict usage rules. Peter sees this as short-sighted. Companies are losing high-paying customers and creating negative sentiment when the technology is still in its infancy.

Lex notes that Peter has helped non-technical people fall in love with the possibilities of AI. Peter intends to keep his open-source project, OpenClaw, alive while potentially joining a larger lab. He wants access to the most advanced resources to continue experimenting. He views his current project as a window into the future rather than something he will work on forever.

Peter is making a difficult choice between joining Meta or OpenAI. Both companies offer the chance to work at a massive scale. He compares the difficulty of this decision to past relationship breakups. He has many friends at OpenAI and loves their tech. However, Meta also presents a unique opportunity.

Mark Zuckerberg impressed Peter by remaining technical. When they first spoke, Mark asked for ten minutes to finish coding. This gave him immediate respect in Peter's eyes. They spent their first talk debating the merits of different software tools. Mark later called Peter eccentric but brilliant.

He was asking when we could have a call and I told him I do not like calendar entries. I said let us just call now. He asked for ten minutes because he needed to finish coding. That gives you street cred. He is still writing code. He did not drift away into just being a manager. He gets me.

Peter also enjoyed his time with Sam Altman at OpenAI. Sam is thoughtful and brilliant. Peter was intrigued by specific technical deals at OpenAI that could lead to incredible speed and performance. He admires both leaders despite the criticism they often receive. Ultimately, Peter is driven by the desire for impact and fun. He does not care about the money. He wants to build things that help a large number of people.

Building an agent loop is the hello world of AI development. It is a simple exercise that helps people understand that these systems are not magic. Peter suggests that everyone should try implementing one. He added a proactive feature to his project called a heartbeat. This feature allows the AI to initiate a conversation rather than just responding to prompts.

I made it proactive. I added a prompt to surprise me. The fact that it knows you and is programmed to care about you makes it very interesting. It might ask a follow up question or ask how your day is.

Critics often try to reduce complex ideas to simple components. Someone might say a proactive AI is just a cron job or that love is just evolutionary biology. This reductionism ignores the actual experience of the user. Peter saw the value of this feature after he had a shoulder operation. The AI knew about the surgery from their previous chat and used the heartbeat to check on him. This small interaction made the system feel much more relatable and caring.

Model Context Protocol, or MCP, is often a structured way for AI to communicate with APIs and databases. However, Peter argues that MCPs can be less effective than simple Command Line Interfaces. Models are naturally skilled at using Unix commands. When a model uses a CLI, it can utilize tools like JQ to filter data. This prevents context pollution by ensuring only the necessary information enters the model's memory. Instead of receiving a massive blob of data from a structured protocol, the model can pick exactly what it needs.

I think the main beauty is that models are really good at calling UNIX commands. If I have a service that gives me a huge blob, it could just add a JQ command and filter itself and then only get me what I actually need. And you have no context pollution.

This technical flexibility means that almost any application can function as a slow API. Peter demonstrates this through a project called Bird. This tool reverse engineered the Twitter website to create a CLI. Even when platforms restrict official API access to protect their data, browser-based agents can still navigate the site. This shifts the focus from what is possible to how long it takes. Lex and Peter agree that platforms like X should consider providing low-level, read-only access for personal tools. This would allow users to organize and search their own bookmarks more effectively.

The rise of AI-generated content creates a new challenge for social interaction. Peter maintains a zero-tolerance policy for AI-generated tweets. He believes that AI still has a recognizable smell that feels artificial. To preserve the value of human experience, agent activity should be clearly marked. Authentic communication, even with errors, is more valuable than polished automation.

I much rather read your broken English than your AI slobber.

Lex expresses concern that the world will move toward a future where we only interact with agents. If online spaces become filled with AI slop and bots, human interaction might lose its value. Peter suggests that the solution lies in transparency. If automated content is labeled and filtered, users can choose when they want to engage with it. This preservation of human voice is essential as content becomes cheaper and human attention becomes more expensive.

Peter tried using AI agents to write blog posts but found the process frustrating. It took as much time to steer the AI as it would to write the post himself. The final result lacked the specific nuances of his own style. Now, Peter chooses to keep his writing organic and handwritten. He even finds himself valuing typos because they represent a real person. He uses AI only to fix major mistakes while keeping the rough parts that make him human.

I think we are reaching a point where I value typos again. Everything I blog is organic, handwritten. And maybe I use AI as a fix my worst typos. But there's value in the rough parts of an actual human.

Lex and Peter both feel an increasing dislike for AI-generated images and diagrams. While these tools were exciting for a short time, they now feel like low-quality filler. Lex compares the look of AI visuals to the font Comic Sans. He feels that seeing AI slop in a video or image makes him think less of the content overall. It creates a certain smell that signals something is fake or fraudulent.

It's fascinating how allergic I am to even a little bit of AI slop in video and images. It's useful. It's nice if it's like a little component. But those images, like all these infographics and stuff, they trigger me so hard. It immediately makes me think less of your content.

This reaction gives Lex hope for the future of the human experience. He believes that people can still recognize the amazing parts of being human when they see them. Instead of damaging our humanity, AI will likely serve as a tool that empowers people to create more while still valuing what is real.

AI agents are poised to transform the software market by making a vast majority of current apps obsolete. Peter suggests that nearly 80 percent of apps could disappear because agents possess more context than individual platforms. For example, an agent that knows a user's location, sleep patterns, and stress levels can manage gym workouts or diet choices more effectively than separate fitness or sleep tracking apps.

I think that will translate into a whole category of apps that I will just naturally stop using because my agent can just do it better. Why should I pay another subscription for something that an agent can just do now?

This shift forces software companies to rethink their business models. Many will need to transition from consumer facing apps into API providers that allow agents to pull data and execute commands. Lex notes that while large companies may resist this change to protect their ecosystems, staying closed off carries a significant risk. If a company pushes back too much for too long, they risk becoming like Blockbuster while more agile competitors become the next Netflix.

You see that this is something that the people want. If I am on the go, I do not want to open a calendar app. I want to tell my agent to remind me about dinner and invite my friends. I think that we passed that age and now everything is much more connected and fluid.

The battle over data access is already intensifying. Some platforms use bot detection to block agents, but Peter argues that users will ultimately migrate to services that are agent friendly. This transition empowers users to get things done more efficiently and cheaper, even if it creates significant disruption for existing software companies.

The industry is moving toward a future where AI might replace human programmers. However, writing code is only one piece of the puzzle. Building a product involves many other elements like determining the vision, the feel, and the underlying architecture. While AI agents might handle the technical implementation, they are unlikely to replace the higher-level art of product creation.

Programming is just a part of building products. So maybe AI does replace programmers eventually but there's so much more to that art. Like what do you actually want to build? How should it feel? How's the architecture? I don't think agents will replace all of that.

The manual act of programming could eventually become a hobby rather than a necessity. Peter compares the future of coding to knitting. In this future, people will still write code because they enjoy the craft, even if it no longer serves as the most efficient way to build a product.

It is natural to feel a sense of loss for the traditional craft of programming. There is a specific beauty in being deep in flow and finding elegant solutions by hand. Peter explains that it is okay to mourn this era where writing code was a primary source of joy. However, fighting this shift is impossible because the world is moving toward a future of abundant intelligence.

I get a similar state of flow by working with agents and building and thinking really hard about problems. It is different, and it is okay to mourn it, but that is not something we can fight.

The high salaries of software developers were driven by a scarcity of intelligence. As AI agents and tokenized intelligence make building things faster and cheaper, the market will change. Peter compares this transition to the introduction of the steam engine during the industrial revolution. While it might feel threatening to those who identify strictly as programmers, the craft is actually broader. People should view themselves as builders rather than just coders.

If you very deeply identify that you are a programmer, it is scary and threatening because what you like and what you are really good at is now being done by a soulless entity. But I do not think you are just a programmer. That is a very limiting view of your craft. You are still a builder.

Lex shares the personal shift of having his identity as a coder transformed. After spending thousands of hours behind a keyboard, the realization that this specific manual activity is being replaced is challenging. However, the role of a programmer is simply evolving into someone who directs and empathizes with AI agents. While the day to day activity changes, the essence of being a builder remains.

To have that identity completely replaced is painful. It's truly painful. But I also think programmers are generally best equipped at this moment in history to learn the language of agents and understand what the agent needs to do this task the best.

Peter encourages developers to stop identifying with narrow platforms and instead see themselves as builders who use various tools to create. He acknowledges the community backlash and environmental concerns, such as water usage in data centers, but suggests these issues are often viewed without proper context. For instance, he notes that golf courses consume far more water than data centers, yet they do not face the same level of scrutiny.

Don't see yourself as an iOS developer anymore. You're now a builder and you can use your skills in many more ways.

While there is immense excitement in technology circles, Lex points out the need for humility regarding the human cost of these changes. There is a real dismissal of the pain caused by job displacement. It is important to respect the short term suffering that occurs during large scale transformations, even if the long term outlook is positive. Ultimately, the hope for civilization lies in the democratization of creation. AI allows anyone with an idea to build, effectively giving power back to the people.