I like the pragmatism here: use the thing already built to run hostile code, which is the browser. The layered approach feels sensible enough and the co-do demo proves you can do useful work without a bespoke VM. But the safety story still leans on CSP nuance and vendor trust, which is a brittle combo. The double-iframe trick is clever and annoying in equal measure. Until local models are good enough or browsers ship friendlier sandboxes, this is “Chrome with caveats”. For many workflows, that’s still good enough today.

I've wrote about it already, from a security stand point, but here're some more thoughts... you’re stitching together Anthropic, Telegram, ElevenLabs, and assorted APIs; every integration is another failure mode, privacy surface, and invoice. Token economics matter: heavy experimentation implies variable, potentially high opex. Governance is user-assembled cron jobs, key storage, permissions... so auditability and rollback are weak compared to managed SaaS. Then the rebrands (Clawdbot -> Moltbot -> OpenClaw) hint at ecosystem flux that will ripple through docs and support. Is it good? Yes! Is it something you should try? Absolutely! Is is safe? Double No!

What stuck with me is how the “how” beats the “whether”. If you simply offload, your quiz score tanks; if you ask for explanations or probe concepts, you keep speed without binning comprehension. This implies product and policy levers: enable “learning modes” by default, bias prompt UX toward “explain then do”, instrument assistants to report explanation coverage, and reward review effort, not just throughput. Expect heterogeneous ROI: substantial productivity on familiar work, ambiguous gains during acquisition phases. Treat copilots like power tools with training requirements, not magic interns. Roadmap asks for longitudinal studies, senior cohorts, and tasks beyond Python; until then, pair AI with structured practice and explicit comprehension checks to preserve oversight capacity.

This is essentially an operating model update! AI widens the span of control by converting scarce expert time into supervisory attention over abundant agent labour. The mechanism is managerial: raise Probability of Success with better specs; compress AI Process Time with faster evaluation; reserve human time for judgement. That implies concrete org moves, like standardising delegation artefacts as prompt templates, codifying “definition of done”, and instrumenting review steps. Incentives also matter: reward specification quality and evaluation rigour, not just throughput. Still, the direction should be treating AI like a team of junior analysts, which clear briefs, staged deliverables, checklisted acceptance, and rapid retries. Organisations that professionalise this will bank compounding productivity while preserving accountability.

This weeks #RBM has been a lot about AI, so maybe next one I can bring some nostalgia posts :) Yet, I’m sympathetic to this core warning of the article: not everything should be delegated, and voice really does matter. The bit on repetition building intuition rings true; shortcuts often short-circuit craft. Still, I think he overstates how inevitably tools erase meaning; good editors, human or machine, can sharpen without puppeteering. Where he absolutely lands is on disclosure and intent: be honest about assistance, and decide what you refuse to automate. My rule of thumb? Automate drudgery, not identity. Keep the chores that shape who you are.