OpenClaw Went Viral — So We Started Using It
OpenClaw landed in late 2025 and quickly became one of the tools everyone wanted to try. In January, I started putting it against real Sorren.ai work: useful for bounded coding tasks, dangerous without supervision, and a sign of where developer workflows are heading.
OpenClaw did not exist in the tooling stack back in 2024. It showed up later, near the end of 2025, and by January I had seen enough demos, threads, and breathless claims that I wanted to know whether it was actually useful on real work.
So I started testing it against Sorren.ai code.
That is the only test that matters. A coding agent can look incredible in a demo repository. Real repositories are different. They have old decisions, partial migrations, naming conventions that made sense once, tests that are helpful until they are not, and a human developer who remembers why a strange piece of code exists.
That human developer is me. OpenClaw is a tool I can hand a bounded task to. It is not the architect of the system.
What OpenClaw Actually Is
Under the hype, OpenClaw is an LLM-driven agent loop. You give it a task in natural language, and it iterates: reads files, proposes edits, executes them, runs tests, reads the output, adjusts. It stops when tests pass, when it thinks the task is complete, or when it gets itself into a corner and needs a human to rescue it.
The clever part is not that it can write code. Models could already write code. The clever part is the loop: repository context, tool access, edit application, test feedback, and another attempt.
It is closer to delegating a ticket to a junior developer who is extremely fast, occasionally confident in the wrong direction, and able to read half the repository in a few seconds.
That can be useful.
It can also be dangerous if you forget the word junior.
Setup
The practical setup was straightforward enough: install the tool, point it at a repository, give it a model, and define the commands that prove whether it did something useful.
# openclaw.yaml
project:
name: sorren-api
language: python
test_command: pytest tests/
lint_command: ruff check .
model:
provider: openai
name: gpt-4o
# or point it at another compatible endpoint when appropriate
The exact model matters less than the workflow around it. OpenClaw is only as good as the constraints it is given. A vague prompt produces vague work. A bounded prompt with tests, file references, and success criteria produces something worth reviewing.
That became the first lesson: agentic coding is not magic. It is delegation.
What It Was Good At
After using it in January, OpenClaw proved genuinely useful for certain categories of work.
Boilerplate generation. Give it an existing pattern and a specific target, and it can move quickly. "Create this endpoint following the structure in that file" is exactly the sort of task it handles well.
Test scaffolding. It can read a module, identify public behavior, and generate a first pass at tests. The tests still need review. Some will be shallow. Some will miss the point. But it gets the page unstuck.
Mechanical refactors. Renames, small interface updates, repetitive changes across files: this is where an agent loop beats manual search-and-replace because it can run the tests and respond to breakage.
Pre-review. I started using it as a rough first reviewer before pushing changes. It catches obvious omissions: missing error handling, untested branches, inconsistent naming, and code that compiles but looks suspicious.
That does not replace a real review. It makes the real review less cluttered.
What It Was Bad At
The limits were just as clear.
Architecture decisions. OpenClaw is good at executing a plan and much weaker at deciding what the plan should be. Ask it to implement a bounded design and it may help. Ask it to design the system from scratch and it will often produce something plausible that ignores local constraints.
Weird debugging. When a failure comes from timing, environment, DNS, permissions, stale state, or a dependency acting strangely, the agent can thrash. It changes something, runs tests, fails differently, changes something else, and eventually you are debugging the agent's debugging.
Taste. Naming, boundaries, product judgment, which abstraction should exist and which one should not: those are still human decisions. The model can offer suggestions. It cannot know why a choice fits Sorren.ai unless I give it that context.
The mistake would be treating OpenClaw like an autonomous engineer. It is better understood as a fast implementer inside a supervised workflow.
The Workflow That Worked
The pattern I settled into was simple:
- I decide what should be built.
- I give OpenClaw a narrow task with file references and success criteria.
- It makes the first pass.
- I review the diff like I would review code from someone moving too quickly.
- Tests decide whether the mechanical part works.
- I decide whether the result belongs in the system.
A good task sounds like this:
Add a
/healthendpoint that checks database connectivity and returns 200 or 503. Follow the pattern insrc/api/status.py. Include tests.
A bad task sounds like this:
Make the backend more reliable.
The second task is not delegation. It is abdication.
Why We Added It
By January 2026, Sorren.ai had enough moving parts that small engineering tasks were starting to pile up: service checks, scripts, cleanup, tests, small API changes, documentation fixes, configuration reviews. None of those individually justify a whole evening. Together, they create drag.
OpenClaw was useful because it reduced the drag.
Not because it replaced judgment. Not because it could be left alone indefinitely. Because it could take a bounded task, do the boring first pass, and hand me something concrete to review.
That is valuable.
The Bigger Picture
OpenClaw is one tool in a category that is arriving quickly: coding agents that operate directly on real repositories. Claude Code, Codex CLI, Hermes delegation, OpenClaw, and the next thing that will probably appear before I finish this paragraph are all variations on the same pressure: less manual typing, more steering, more reviewing, more deciding what should exist.
That is the work shift I care about.
The agents are not replacing engineers. They are changing the shape of engineering time. More of my job becomes describing the desired change precisely, setting constraints, reviewing the result, and knowing when not to trust the tool.
OpenClaw is now part of that toolkit. It arrived late in 2025, we started using it around January 2026, and the honest verdict is simple: useful, supervised, and not magic.
Which is fine. Most good tools are not magic. They just save enough time to earn their place.