I don't even read the code I delivered. Clawdbot aims for 100,000 stars, and the author reveals the development insider stories.

According to a report by Zhidx on January 30th, recently, the open-source personal AI assistant Moltbot (formerly known as Clawdbot) has become one of the hottest projects in the AI circle. As an independent project from an individual developer, the search popularity of Moltbot even exceeds that of similar products like Cowork from leading AI players. Its number of GitHub stars has already exceeded 100,000, approaching that of legendary open-source projects like Next.js.

▲ Changes in the number of GitHub stars for Moltbot (Source: X platform)

After the project became popular, Peter Steinberger, the developer behind Moltbot, has frequently participated in interviews. Just yesterday, in a nearly two-hour in-depth podcast, he delved into his thoughts on software development in the AI era.

Steinberger's technical career began when he was fourteen. A computer that appeared by chance started his self-study journey in programming. In his first job, he refactored the entire technology stack in the company without prior approval. It was also during this period that he began to form a key judgment: The feeling of use surpasses industry standards.

Later, Steinberger started his own business and finally sold his shares in the PDF technology company PSPDFKit for over 100 million euros. After achieving financial freedom, this former technology enthusiast chose to completely cut off his connection with code and entered a long "stress relief period." This state was not completely broken until he sat back in front of the computer and encountered a new generation of AI programming tools.

When Steinberger returned to the battlefield, he found that the programming world had undergone a generational leap. He keenly noticed that the logic of software construction has shifted from typing code line by line to a woven system construction.

When developing the new project Clawdbot, he simultaneously coordinated 5 - 10 AI Agents to collaborate. In his opinion, AI programming is "an amplifier of capabilities." In the past, programming work was as boring as that of a "plumber," but the new paradigm of AI programming allows him to no longer get entangled in specific details. Instead, he focuses his energy on modular design, automated testing, and the trade-offs of system architecture. He admitted: "I don't even read the code I deliver."

Facing the resistance of many senior engineers to AI, Steinberger believes that the real secret lies in establishing a feedback loop, that is, allowing the Agent to automatically compile, test, and correct errors on its own, rather than expecting it to write correctly at once.

He analogized: Those who think AI cannot handle complex logic are often "still trying to play the piano in the way they play the guitar." With the support of AI, the code quality has not declined. Instead, due to the model's need to "prove itself correct," it has forced out a better-quality and more modular architecture design.

Here is a summary of the key points from Steinberger's latest interview:

01. The value of software depends on the "feeling of use"

Steinberger was born in a rural area in Austria. What really connected him with technology was an accidental experience. When he was fourteen, a group of tourists came to the countryside, and one of them brought a computer.

This was the first time Steinberger had come into contact with a machine that could be controlled by commands and logic, and he was quickly attracted. He convinced his mother to buy him a computer, and since then, he has started years of self-study and practice.

There was no systematic training during this period. Steinberger said he was more like "messing around." He wrote scripts, built websites, played games, and modified games. He remembered that one of the first things he did was to steal an old DOS game from school, write a copy protection program for the floppy disk, and then resell it.

During his college years, due to limited family financial conditions, Steinberger had to pay for his tuition himself. The holidays didn't mean rest but full-time work. Compared with his peers, he entered a long-term, high-intensity work rhythm earlier.

His first official job was in Vienna. It was originally just a short transition between military service and college, but it lasted for nearly five years. On his first day at work, the company gave him a thick copy of the "Microsoft Foundation Classes," but he abandoned this technology stack and instead used .NET.

This also became his most distinctive early work style: Seemingly following organizational arrangements, but actually acting according to his own judgment. In this company, without prior notice, he migrated part of the system to the .NET technology stack. It was only a few months later that he informed the management that he had "made some modernizations," but by then, it was too late.

Although in the era of .NET 2.0, application startup was slow, compilation was lengthy, and there was frequent hard disk reading and writing, he still maintained an interest in the underlying mechanisms and was willing to invest time in refining the details. This attention to details was further magnified in a subsequent project.

Around 2010, when the iPad was released, magazine apps became a hot area for startups. A team asked him to fix a magazine reader that crashed frequently. After examining the code, he found that the problem was not a local defect but an overall structural breakdown: the code was highly concentrated, severely coupled, and almost unmaintainable.

After abandoning the patching solution, he chose to rewrite the app, completing in two months what was originally expected to take six months. Instead of using Apple's PDF renderer, he developed his own to systematically handle PDF rendering issues. Finally, this app could load large-volume documents with extremely limited memory.

After the project was completed, he separated the PDF-related code modules. Initially, it was only for his friends to reuse, and then he tried to sell it as a component. The income already exceeded his full-time salary. A few months later, his original company asked him to choose between his work and his personal project.

Steinberger chose to fully invest in this project. He believes that PDF is an area that is "boring but extremely difficult." Precisely because of this, it has long-term value. This judgment ultimately became the starting point for his startup project, PSPDFKit. At the same time, he also realized that the value of software is more reflected in the final "feeling of use" rather than being determined by specifications, standards, or authorities.

02. After getting tired of being a "garbage can" from long-term personal involvement in technical support, he sold his shares

At the beginning of the company's establishment, Steinberger realized that it was difficult to find the engineering talents he needed in his hometown, Austria. Therefore, PSPDFKit was a remote-first company from the start and later gradually evolved into a hybrid model. As the team size grew from thirty to sixty or seventy, and then to nearly two hundred, the organizational complexity also increased.

Steinberger is not a typical CEO. He has never actively pursued a management position and has always focused his main energy on writing code, solving technical problems, and making product decisions. Sales, business, and operations are left to other partners and executives.

PDF is a relatively complex technical field. Steinberger gave an example: the links in a PDF document. The initial design assumption was that a document might contain hundreds of links. However, once, an important customer submitted a PDF file with 50,000 pages, with more than a hundred links on each page, totaling more than 500,000. The original data model completely failed at this scale.

This type of problem is exactly what Steinberger enjoys the most. He has been personally involved in technical support for a long time and intentionally processes work orders in reverse order, giving priority to answering the latest submitted questions.

His logic is simple: Getting a reply from the CEO within 5 minutes will generate a strong sense of trust among developers. This "direct support from the founder" method also invisibly limits the company's expansion speed but enhances the stickiness between the product and users.

However, as the company entered the growth stage, the work content gradually shifted from "solving difficult problems" to "maintaining the system," and the organizational friction caused by the expansion of the personnel scale began to appear. Steinberger found that he was spending more and more time on coordinating conflicts, taking on risks, and maintaining emotional stability.

He described that the CEO is like a "garbage can": all the things that others cannot handle will eventually end up here. Long-term high-intensity work, no rest on weekends, combined with the internal conflicts regarding the company's direction and management methods, ultimately led to obvious exhaustion.

After selling his shares in PSPDFKit for about 100 million euros, he almost completely left the technical world. For some time, he stopped writing blogs and rarely turned on his computer. It was a long stress relief process. He made up for it by attending parties and socializing. For several months, he didn't have any thoughts about "what I'm going to do next."

For him, the real difficulty was not quitting but finding motivation again after success.

03. "I don't read the code I deliver." Judgment and taste are more valuable

A few years later, Steinberger sat back in front of the computer. In this process, he systematically came into contact with the new generation of AI programming tool Claude Code for the first time. Since he missed the early stage, he directly experienced the version after the leap in capabilities. This experience had a strong impact on him.

He gradually realized that the resistance in software construction is rapidly decreasing. What really matters is no longer writing code but judgment and taste at the system level. Judging whether the structure is reasonable and the direction is correct is itself a core skill.

Steinberger believes that the real turning point in AI programming occurred this summer. AI has become so powerful that developers can build a complete software system without writing code themselves. What completely convinced him were GPT - 5.2 and Codex, which he believes are seriously underestimated.

He said bluntly that compared with Claude Code, which is still widely used, OpenAI's current product experience is excellent. Almost every prompt can directly yield usable results. In complex projects, he believes that Codex is significantly better than Claude Code, and the main difference between them lies in their working methods.

Claude Code is fast, but it often starts generating code after reading only a few files, requiring people to constantly correct it. Codex will "quietly read the code for 10 minutes" before starting, and has a higher success rate at once, making it more suitable for complex systems, in-depth refactoring, and long-term maintenance projects.

In his latest project, Clawdbot, he runs 5 - 10 programming Agents in parallel. The entire development process has shifted from writing code to having conversations with the model and co-planning.

Currently, Clawdbot uses the CLI solution instead of MCP. Steinberger said bluntly: In his opinion, MCP is just a crutch.

MCP requires preloading all tool functions and descriptions, resulting in redundant context. Data transmission relies on a fixed JSON format, lacking flexibility, and unable to perform data screening and chained calls, which limits the ability to handle complex tasks.

The natural advantage of CLI is that the model is naturally good at using Bash commands and can also achieve automated chained operations by writing scripts.

Steinberger said: "I don't read the code I deliver." But this doesn't mean he doesn't value code quality. On the contrary, he invests a lot of energy in refactoring and architecture design.

The essence of most applications is the boring data transfer and format conversion, from API to parsing, then to storage and presentation, just like the work of a plumber. Steinberger believes that the truly complex problems have often been solved by underlying technologies. Therefore, engineers should pay more attention to the overall structure and design of the system rather than getting entangled in the specific implementation details of each line.

In this new paradigm, Steinberger believes that the role of humans is no longer to implement logic line by line but is more like a system builder. Humans are responsible for system structure, product form, and architecture trade-offs, while the model is responsible for specific implementation, code generation, and debugging. The responsibility still lies entirely with humans, and the Agent is just an "amplifier of capabilities."

Due to the introduction of AI, Steinberger's work style has completely subverted the traditional development process. He no longer indulges in pull requests and code reviews. Instead, he "weaves" functions into the existing system, and sometimes even needs to modify the architecture to make new functions fit.

However, Steinberger doesn't like the term "Vibe Coding." He prefers to describe his work as Agent engineering. He also deliberately avoids the term "architect" and emphasizes that he is still the ultimate responsible person. Different from the "architects detached from code" in traditional enterprises, the premise of Agent engineering is that the code is your own, and you are responsible for any accidents.

Steinberger believes that the real secret of AI programming lies in achieving a feedback loop. The Agent must be able to verify its work, automatically compile, automatically test, replace the graphical interface with the command line, and have a reproducible execution path. Once the verification loop is established, it can discover race conditions, configuration errors, and tool call sequence problems on its own, and even complete in a few hours what would originally take weeks of human debugging work.

More interestingly, AI has actually forced out a better architecture. In order to let the model prove itself correct, the system design must be more modular and more testable. Testing and documentation have become part of the design process, and the importance of architecture decisions has been advanced and magnified.

Steinberger admitted that he has never liked writing tests or documentation, but in the AI era, these tasks can be completely handed over to the model, and the code quality has reached a new high in his career. Agent programming is enabling experienced developers to write "better-quality code" even if they no longer type every line themselves.

So, why do many senior engineers still resist AI? In Steinberger's view, opponents often make three mistakes: regarding AI as a "programmer who can write correctly at once," only sending one prompt without establishing a continuous dialogue and feedback loop, and not understanding the knowledge distribution and default assumptions of the model.

04. Conclusion: Is code depreciating while taste appreciating?

From a fourteen-year-old self-taught programming teenager to a successful entrepreneur, and now an independent developer "returning to the battlefield" in the AI wave, Steinberger's experience reveals a truth: in the AI era, code is becoming cheap, while the judgment of the system and the taste for product logic are becoming more valuable.

From this perspective, this transformation is more like a baptism of thinking than a replacement of tools. Steinberger vividly analogized that those who currently refuse AI programming are like guitar players who try the piano a few times and then say the instrument is no good.

Continuing this analogy, those who are willing to put down the "guitar" and try the "piano" may explore a new way of construction and thinking in the process of collaborating with AI.

This article is from the WeChat official account "Zhidx" (ID: zhidxcom), author: Chen Junda. Republished by 36Kr with permission.