Comment by athrowaway3z
19 days ago
That was very vague, but I kinda get where they're coming from.
I'm now using pi (the thing openclaw is built on) and within a few days i build a tmux plugin and semaphore plugin^1, and it has automated the way _I_ used to use Claude.
The things I disagree with OP is: The usefulness of persistent memory beyond a single line in AGENTS.md "If the user says 'next time' update your AGENTS.md", the use of long-running loops, or the idea that everything can be resolved via chat - might be true for simple projects, but any original work needs me to design the 'right' approach ~5% of the time.
That's not a lot, but AI lets you create load-bearing tech-debt within hours, at which point you're stuck with a lot of shit and you dont know how far it got smeared.
They're not coming from anywhere. It's an LLM-written article, and given how non-specific it is, I imagine the prompt wasn't much more than "write an article about how OpenClaw is changing my life".
And the fact this post has 300+ comments, just like countless LLM-generated articles we get here pretty much daily... I guess proves the point in a way?
That’s another reason there just isn't any point in looking at these articles anymore unless they take you on a trip deep in the weeds of some specific problem or example. We need deep case studies (pro and con), not bulleted lists and talking points.
Would you describe your Claude workflow?
My agents get auto-injected with the core spec via pi-extention.
I have an idea, agent turns it into a draft, depending on idea vagueness/complexity combination of: Looking for alternative, plan the change, look for alternative, split up into smaller drafts to drive separately, execute change (spec, code, tests), review change.
Usually its just: Draft, plan, exec, commit. The steps are flexible enough. Usually each step is a different agent, sometimes not. On complex builds or big changes, a planning agent itself might spawn subagents to avoid bloating its own context.
The progress is stored in: ./dev/{draft/<n>.md , wip/<n>/, fin/<n>/ }.
My `lead` pi has a separate AGENTS.md with how to organize the above sequence, and some notes on how to prompt, keep things small, etc. Note that its skill `tmux-coding-agrents` calls other pi instances (optionally set to codex). I've moved off the claude cli entirely.
I used to spend time telling claude not to forget updating the specs or building its tests because context bloat made them forget AGENTS.md, or to read certain files before it should execute a plan. The lead agent does this just fine now, and every time i see it make a mistake i say: "Next time do X" and it automatically updates its own or the worker agents AGENTS.md.
Because my lead agent context is all about managing this process it doesn't forget steps while its off chasing some bug.
Also, I build (but did not publish) a pi plugin that attempts to use other accounts on usage limits.
Most surprising moment I had, was my lead spawning a subagent, spawning a subagent, which spawned a tmux-bash build with very little prompting, and it was the right thing to do to prevent each agent from context bloat.
Thanks for the write up. I'm starting to consider enhancing my setup and building on pi sounds interesting. I have a similar core workflow, but I'm still tied to CC's interface and I can see how it might be nice to have something a bit more custom.
1 reply →
See, whatever one may think or conclude about the substance, it’s this kind of thing that might actually help advance the conversation.