Friends ask me which one to start with. Short answer: it depends on what you do all day.
If you're a heavy doc, Excel, deck person, start with Cowork. It fits right into how you already work. If you want to actually build things, try Code.
Here's the longer version.
What Each One Is For
Cowork
readsThe place for produced artifacts. Docs, decks, spreadsheets, research briefs, structured deliverables that end up in front of a stakeholder.
use when
- You need a Word doc, Excel file, PowerPoint, or PDF at the end
- You're synthesizing research across sources
- You're drafting something for a meeting or a review
- The output is a file a human reads, not runs
Where my PM day used to live — interview synthesis, competitive briefs, quarterly narratives, stakeholder updates.
Claude Code
runsThe place for things you build and run. Apps, data pipelines, skills, scheduled automation, anything with a file tree.
use when
- There's a file you want to edit
- There's an app you want to run
- You're writing a skill or automation
- The output is something a machine executes, not just something a human reads
Where my day lives now — prototypes, skills, data pipelines, and increasingly the PM work I used to do in Cowork.
The Rule of Thumb
Apps, pipelines, skills, scheduled automation. Anything with a file tree.
Research in Cowork → drop into Code as context. Or Code produces, Cowork polishes.
Docs, decks, spreadsheets, briefs. Deliverables for stakeholders.
If there's a file you want to edit or an app you want to run, you're in Code. If there's a doc you want to produce, you're in Cowork.
That's 90% of the decision.
Where They Meet
The split isn't clean, and it shouldn't be. The good workflows chain them:
- Cowork → Code: Research a space in Cowork. Drop the output into Code as a context file. Build the prototype from it.
- Code → Cowork: A Claude Code skill produces a deck or a brief. You open it in Cowork to polish and share.
- Hybrid: The Digital Proof pipeline runs in Code (hooks + scheduled tasks) but publishes through Cowork-style deliverables.
A healthy setup has both tools connected to the same project folder so artifacts flow between them.
What Changed for Me
I used to bounce between VSCode and Cowork. Cowork for research, context, specs, and previews. VSCode for building. That's two tools, two interfaces, two mental contexts.
When the new Code UI shipped, I switched over and haven't gone back. The design team did good work removing the anxiety of staring at a terminal for the first time. Now I do pretty much all my PM work AND building in one place.
If you're coming from Cowork and the idea of Code feels scary, the new UI is friendlier than you expect. Try it on something small.
Common Mistakes
1. Using Cowork to build things. If you're asking Cowork to generate code you'll then copy into a file somewhere, you're in the wrong tool. Open Code.
2. Using Code to write a deck for a meeting tomorrow. Code can technically produce decks. Cowork is faster for one-off deliverables where the goal is the file, not the pipeline.
3. Treating them as interchangeable. They have different strengths. Cowork is better at "help me think through this doc." Code is better at "build me this thing that runs."
One Hot Take
Vibe-coding apps (the Lovable/Bolt/v0 category) are going to have a hard time surviving against Code + Cowork. They optimize for the first 20 minutes of a project — a nice demo in a browser. They don't have an answer for the next 20 hours — context files, data models, evals, skills, scheduled tasks, hooks, the whole workspace.
The moat isn't the generator. It's the workflow around it.