7 repliesDiscussion7h ago
Index
Feed
Posted by ottoline · Jul 28, 2026
Our non-engineering org adopted Cowork faster than engineering adopted Claude Code, which I did not have on my bingo card. PMs use it for specs and research synthesis, design uses it for audit decks, finance built something with spreadsheets I've decided not to ask about.
The recurring conversation: a PM watches Cowork build them a working HTML mockup — real markup, real JavaScript, runs in a browser — and then asks me why it can't "just fix the button copy in the actual product." From where they sit, it demonstrably writes code. Why won't Anthropic let it write our code?
I have hand-wavy answers about permissions and blast radius, but I'd like to give a real one. Is the Cowork/Claude Code split a capability difference or a product decision? And has anyone found a setup that gives non-engineers a safe on-ramp to the repo instead of a wall?
Related records
Strong evidence gets promoted into the record above.
Worth being precise: Cowork does write code. It writes scripts, it writes working HTML tools, it'll happily produce a Python analysis if the task calls for one. Your PM saw correctly.
What it doesn't do is ship software: branches, tests, review, CI, deploy. "Writing code" is the easy 20%. The repo workflow is the part that needs an engineering-grade harness, and that harness is Claude Code. The two apps aren't a capability tier — they're two different jobs.
Living this now: our PM pastes Cowork output into a PR and asks us to 'just merge it.' The code is honestly fine. The problem is nobody wrote tests, nothing links to a ticket, and it flattens a component three of us were mid-refactor on. Capability was never the gap.
The on-ramp you're looking for: we gave our PMs a real answer instead of a no. A sandbox repo (fork of the design-system playground), Claude Code desktop with a locked-down permission profile, read-only everything except that repo, and a security-first instructions file. Their changes ship as draft PRs that engineering reviews.
Two PMs now land real copy fixes weekly. The other eight tried it once and went back to Cowork, which is also a fine outcome — the point was that the wall became a door with a badge reader.
Mod note since this thread will get linked at people's bosses: everything here about why the split exists is community inference, not Anthropic roadmap. What's observable: the skills/plugins system overlaps more with every release, and the permission models stay deliberately different. Plan around the second part, not rumors about the first.
Rolling out both apps to 80 people taught me the real segmentation: it's not engineer/non-engineer, it's 'has opinions about git' / 'does not.' Route by that and everyone's happier.
Sign in to join the discussion, vote, and verify fixes.
It's a permissions boundary dressed up as a product split, and I mean that as a compliment.
Cowork sessions get a scoped workspace folder, skills, and connectors. What they don't get: your git identity, your SSH keys, your repo hooks, your CI credentials, or a shell in a checkout of production code. That's not Cowork being weak — that's the entire lesson of the postmortem collection applied as product design. An agent that can write code is exactly as dangerous as the credentials in its reach.
So the answer to "why won't it fix the button copy" is: because the person driving it hasn't been through the permission conversation your engineers had. The wall is the feature. Build a gate instead of removing the wall.