Software Development on KnightLi Blog

How OpenClaw Creator Peter Steinberger Sees AI Software Development: From OpenClaw to Closed-Loop Coding

Sun, 17 May 2026 20:02:26 +0800

Peter Steinberger’s career is a useful lens for understanding what is changing in AI software development.

He is not a newcomer who suddenly became visible because of AI. Before OpenClaw, he was already the founder of PSPDFKit, a company focused on PDF rendering, document processing, and developer tools. Products like that are hard to win with concept packaging alone. They have to deal with performance, compatibility, API design, enterprise customers, and long-term maintenance.

So when Steinberger later built OpenClaw with AI tools and shared views around AI agents, personal automation, and AI coding, the point was not simply that “one person wrote a lot of code.” The more interesting part is how he combined years of software engineering experience with a new generation of AI coding agents and rethought the development process.

AI coding is not a magic button

Discussions about AI coding often fall into two extremes.

One side says AI can already write code, so programmers are almost obsolete.

The other side says AI-generated code is unreliable, so real engineering still has to be hand-written by people.

Steinberger’s experience points to a third view: AI changes the unit of operation in software development, but it does not remove engineering judgment.

In the past, developers mainly worked around editing code. Requirements breakdown, architecture decisions, implementation, testing, and bug fixing all revolved around manual code changes.

Once AI coding agents enter the workflow, developers increasingly manage an execution system:

Explain the goal.
Provide context.
Set boundaries.
Let the agent modify code.
Run tests and checks.
Iterate based on results.

This is not simply handing the keyboard to a model. It is moving humans from “typing every line” toward “defining direction, designing feedback, and judging results.”

Why he is skeptical of calling it vibe coding

One phrase that often appears around Steinberger is vibe coding.

The term originally described a new style of development: developers describe ideas in natural language, let AI generate large amounts of code, then keep adjusting based on runtime results and feedback.

But Steinberger is not entirely sold on the phrase. Public coverage has noted that he sees vibe coding as potentially dismissive, implying that AI-assisted development is just “generating by feel” while ignoring the skill, judgment, and experience behind it.

That criticism makes sense.

Effective AI coding is not about typing a casual sentence and trusting the model’s output. It requires:

Breaking vague requirements into executable tasks.
Detecting when the model misunderstands the goal.
Designing tests and acceptance criteria.
Judging whether the code structure will remain maintainable.
Knowing when to stop generating and switch to human review.

In other words, AI reduces the friction of writing code, but it does not reduce the responsibility of understanding the system.

The loop is the key

One idea often associated with Steinberger’s interviews and writing is the importance of the loop.

Letting AI generate code is open-loop.

Letting AI generate code, run it, read errors, fix problems, and run tests again is closer to closed-loop development.

That difference matters.

Open-loop generation easily creates software that looks usable on the surface. The page opens, features appear to exist, and there is plenty of code. But once it enters a real environment, problems with state management, permissions, exception handling, edge cases, and deployment quickly appear.

Closed-loop development means output must be constrained by feedback. The simplest loop is:

Write down the goal clearly.
Let AI modify the code.
Automatically run tests, type checks, lint, or a build.
Feed errors back to AI.
Repeat until it passes.
Let a human review the critical path.

This is where AI software development can truly improve efficiency. Not because the model gets everything right the first time, but because it can participate quickly in a cycle of generation, validation, and repair.

More experience makes AI more useful

One of the easiest misconceptions about AI coding is that experience no longer matters.

Steinberger’s case suggests the opposite: experience becomes more important, but its role changes.

An experienced engineer is better at deciding:

Which tasks are suitable for an agent.
Which modules need tests first.
Which changes are too risky for broad AI refactoring.
Which generated code merely looks plausible.
Which problems should be solved through architecture rather than more patches.

AI can generate many candidate solutions. The more candidates you have, the more judgment you need. An inexperienced person may be impressed by “it runs.” An experienced engineer asks: can it be maintained? Can it scale? Does it break a security boundary? Can we debug it when something goes wrong?

That is why AI coding agents do not turn software engineering into pure chat. They outsource part of the execution work while amplifying planning, review, validation, and trade-off decisions.

OpenClaw matters beyond the project itself

OpenClaw drew attention not only because it is an open-source AI agent, and not only because it grew quickly.

It is also a signal: developers increasingly want AI to do more than answer questions. They want it to connect to real tools and perform real actions.

Traditional chatbots stay inside the chat box. They can explain code, write drafts, and give advice, but people still need to copy, paste, open software, and run commands.

The agent direction connects models to tools:

File systems.
Browsers.
Terminals.
Email.
Calendars.
Third-party services.
Project repositories.

Once models can use those tools, the boundaries of software development shift. AI is no longer just code completion. It can participate in project reading, task decomposition, file editing, test execution, PR preparation, and workflow automation.

That is also why Steinberger’s move to OpenAI drew attention. He represents not just a single developer story, but a product direction: personal agents moving from demos into everyday work.

What this means for ordinary developers

For ordinary developers, Steinberger’s experience is not something everyone can copy directly.

Not everyone can manage multiple agents at once. Not every project is suited to heavy AI generation. Not every team accepts a workflow of “generate first, iterate quickly.”

But several lessons are useful.

First, write tasks clearly.

AI is sensitive to vague goals. If you say “optimize this,” it may change style, structure, features, and logic. If you say “change the login failure message from English to Chinese without altering the authentication flow,” the result is usually more controllable.

Second, standardize validation commands.

If a project has no tests, no build command, and no lint, AI has trouble forming a loop. Even basic commands like npm test, go test ./..., pytest, or hugo are better than relying only on visual inspection.

Third, control the scope of changes.

Having AI handle one module, one bug, or one page at a time is usually more reliable than asking it to “refactor the whole project.”

Fourth, keep human review.

For authentication, payments, permissions, data deletion, deployment scripts, database migrations, and security configuration, do not lower the review bar just because the code was generated by AI.

Fifth, review prompts and failure patterns.

If AI often misunderstands a certain type of task, write those constraints into project rules, agent instructions, or skill files. AI coding capability comes not only from the model, but also from the work environment you build around it.

Where AI software development is going

Steinberger’s story suggests that AI software development is moving from “helping write code” toward “organizing software production workflows.”

Early AI coding tools were mainly useful for function completion, error explanation, and template generation. The shift now is that agents can work across files, call tools, run checks, and continue fixing based on feedback.

This points to several trends.

First, the productivity ceiling for individual developers will rise.

One person can push more prototypes, scripts, internal tools, and small products. But higher output does not automatically mean higher quality. The faster code is generated, the more validation matters.

Second, project structure becomes more important.

The clearer the code, tests, and documentation, the easier it is for AI to make correct changes. Messy projects are hard for humans and hard for AI.

Third, software engineers will look more like workflow designers.

In the future, what matters will not only be whether someone knows a programming language, but whether they can organize requirements, context, tools, tests, deployment, and permissions into a controlled loop.

Fourth, security boundaries become more sensitive.

If an agent can do things, it can also do the wrong things. If it can read files, run commands, and access services, then permissions, audit, and rollback become infrastructure for AI development environments.

Summary

The most valuable part of Peter Steinberger’s view of AI software development is not how much code AI generated. It is the development posture he demonstrates.

Humans are no longer only typing line by line inside an editor. They are designing goals, managing agents, building feedback loops, reviewing results, and adjusting the system. Code remains important, but it is no longer the only center of labor.

If traditional software development emphasized “writing the code correctly,” AI software development increasingly emphasizes “making the system continuously produce verifiably correct results.”

This is not just about lowering the engineering barrier. It changes the shape of engineering ability: from manual implementation toward task decomposition, context management, tool orchestration, automated validation, and final judgment.

References

Karpathy's 65-Line CLAUDE.md: Helping AI Coding Avoid Three Common Mistakes

Sun, 19 Apr 2026 18:27:23 +0800

A GitHub project about AI coding has been getting a lot of attention recently. Its core is not a complex codebase, but a roughly 65-line CLAUDE.md file. The reason it attracted so many stars is not technical complexity. It is that it captures problems many people repeatedly run into when using AI to write code.

The background starts with Andrej Karpathy’s observations on AI coding. Karpathy is an influential educator and engineer in AI: a Stanford PhD, an early OpenAI contributor, and a former Tesla AI leader responsible for Autopilot’s vision system. He has continued to share his views on large models, education, and AI tools, so his comments on changes in programming workflows tend to draw a lot of attention from developers.

He once said that after using Claude Code for a few weeks, his programming style changed noticeably. Previously it was roughly 80% handwritten code and 20% AI assistance. Now it is closer to 80% code written by AI and 20% edits by himself. He described it as “programming in English”, telling an LLM what to write through natural language.

But he also pointed out several recurring problems in AI coding.

01 Wrong Assumptions

The first problem is that models easily make assumptions on behalf of the user, then keep writing along that path. They do not always manage their own confusion, and they do not always stop to ask questions when the requirement is ambiguous.

For example, if the user only says “add a user export feature”, the model might assume it should export all users, output JSON, write to a local file, and skip any confirmation around permissions or fields. Only after the code is done does the user discover that the model’s understanding does not match the real scenario.

A better approach is to list the uncertainties first: should it export all users or filtered results? Should it trigger a browser download or run as a background job? Which fields are needed? How large is the data set? Are there permission constraints? If these questions are not clarified, writing faster only means drifting farther.

02 Over-Complexity

The second problem is that models often turn simple problems into complex ones. A task that could be handled with one function might receive abstract classes, strategy patterns, factory patterns, configuration layers, and a pile of extension points that may never be needed.

This kind of code can look engineered, but in practice it increases maintenance cost. AI is especially good at quickly generating large structures, but it does not always judge whether those structures are necessary. The result is that a task solvable in 100 lines becomes inflated into 1,000 lines.

The test is straightforward: would a senior engineer look at the change and think it is over-designed? If the answer is yes, remove the extra layers and solve the current problem with the least code needed.

03 Collateral Damage

The third problem is that models sometimes modify or delete code they do not fully understand. While fixing a small bug, they may casually change comments, reformat nearby code, clean up imports that look unused, or even touch logic unrelated to the current task.

These “drive-by improvements” are risky because they expand the change scope and make review harder. The user may only want to fix a validator crash caused by an empty email, but the model may also enhance email validation, add username validation, and rewrite docstrings. In the end, it becomes hard to tell which line changed behavior.

A safer rule is: only change what must be changed, and only clean up issues caused by your own change. Existing dead code, formatting problems, or historical baggage should not be touched unless the task explicitly asks for it. At most, mention it.

04 Turning Complaints Into CLAUDE.md

After Karpathy’s comments spread widely, developer Forrest Cheung did something clever: he organized these complaints into executable behavior rules and put them into a CLAUDE.md file.

The project does not contain complicated code. Its key idea is to turn the most failure-prone parts of AI coding into clear working rules. They can be summarized as four principles.

The first is to think before writing. Do not silently assume. Do not hide confusion. If a requirement has multiple interpretations, list them. If there is a simpler approach, say so. Ask when clarification is needed, and push back when needed.

The second is to keep things simple. Do not add features that were not requested. Do not abstract one-off code. Do not add unnecessary configuration. Do not write large amounts of defensive code for extremely unlikely scenarios. If 50 lines can solve it, do not write 200.

The third is to make precise changes. Every changed line should trace directly back to the user’s request. Do not improve nearby code as a side quest. Do not refactor something that is not broken. Match the existing project style as much as possible.

The fourth is goal-driven execution. Do not give the model only a vague instruction. Give it a verifiable success criterion. For example, “fix the bug” can become “write a test that reproduces the bug, then make it pass”; “add validation” can become “write invalid-input tests and make them pass”. The clearer the success criterion, the easier it is for the model to loop toward completion.

05 Why It Took Off

This project became popular not because the content is mysterious, but because it is close to real development work.

Many people using AI for coding have seen similar scenes: the model confidently misunderstands the requirement, the code gets more complex as it goes, or it touches places it should not touch. The value of CLAUDE.md is that it turns those experiences into collaboration rules that can be placed inside a project.

The entry cost is also low: one file can start making a difference, with no complicated integration. Combined with Karpathy’s influence and the project’s practical comparison examples, it naturally spread through the Claude Code user base and the broader AI coding community.

More importantly, these rules are not only for Claude Code. No matter which AI coding tool you use, the underlying issues are similar: the model needs to know when to ask, when to simplify, when to stop, and how to decide that the task is complete.

06 What Developers Can Take Away

The lesson for ordinary developers is simple: AI coding is not about throwing one sentence at a model and waiting for a miracle. The effective approach is to give the model boundaries.

When the requirement is unclear, ask it to expose its assumptions first. When the implementation starts getting complicated, ask it to return to the smallest viable solution. When changing code, keep it focused on the task goal. When finishing work, use tests, commands, or explicit checkpoints to verify the result.

AI is already very capable at writing code, but it still needs good collaboration constraints. The fact that a short CLAUDE.md can attract so much attention shows that developers do not only need smarter models. They also need more reliable ways of working.

In short:

Think before writing to reduce wrong assumptions.
Keep things simple to avoid over-design.
Make precise changes to control change scope.
Work toward goals with verifiable success criteria.

These four rules are not complicated, but they are practical. The prerequisite for AI coding to truly improve efficiency is not making the model write more. It is making it write more accurately, with less code, and under better control.