I use AI in delivery work every day, and for most of the past year that meant a chat window. Ask a question, get an answer, paste the useful part somewhere else.
Recently I moved a specific kind of work out of chat entirely: producing project documentation, planning architecture, and working through system design against a real set of project files. That work now runs in Cowork, and the difference was large enough that I want to be precise about where it comes from, because "AI made me faster" is not a useful claim on its own.
What actually changed
The work I do at the start of a project has a shape. A client sends a proposal, a requirements document, an existing repository, sometimes all three. Before I can plan sprints or size anything, I have to hold all of it in my head at once and produce something specific out of it: a schema, a phased scope, a list of the assumptions nobody has checked.
In a chat window, that work is a series of round trips. I paste a section, ask about it, get an answer, paste the next section, and by the fourth exchange I am re-explaining context I already gave. The conversation is doing the work, so the conversation has to carry the state, and conversations are bad at carrying state.
Cowork changes the unit of work. Instead of asking questions about a document, I hand over the documents and describe the outcome I need. It reads across all of them, works through the steps, and produces the artifact. The state lives in the files, not in my ability to keep re-summarising.
For decision-making that difference matters more than the speed. When the reasoning across a large set of inputs is laid out in front of me in one place, I can see which parts I disagree with. In a chat thread the same reasoning arrives in fragments, spread across ten messages, and I lose the shape of it.
The distinction that decides which one to use
The clearest test I have found: do I want an answer, or do I want an artifact?
If the output is something I will read and then act on myself, chat is the right tool. If the output is something that will exist afterwards as a file, a document, a deliverable, that is Cowork.
Two more that follow from it:
How many inputs are there? One document, one question, chat. A repository plus a proposal plus a spreadsheet of requirements, Cowork. The overhead of setting up a workspace is not worth it for a single question, and it pays for itself immediately once there are several sources that have to be read against each other.
How many steps? If I can describe the whole task in one sentence and expect one response, chat. If the task is "read these, work out what is inconsistent, then produce a plan that resolves it," that is a sequence, and sequences fall apart in chat because each turn loses a little context.
Where I still use chat, deliberately
Cowork is not a replacement, and treating it as one produces worse work.
Thinking out loud. When I do not yet know what I am asking, chat is better. I want short exchanges, fast corrections, the ability to change direction mid-thought. Handing that to an agent produces a confident answer to the wrong question.
Quick factual checks. Vendor limits, syntax, a term I half remember. One question, one answer, no setup.
Anything where I am the one who needs to understand it. If the point of the exercise is that I come out the other side knowing something, doing it in conversation is the work. Getting a finished artifact skips exactly the part that was valuable.
Adversarial review of my own thinking. When I want the argument against a decision I have already made, I want that in short exchanges I can push back on, not as a document.
What I would tell someone starting out
Two things I got wrong at first.
I described the process instead of the outcome. Early on I wrote instructions the way I would brief a junior developer: do this, then this, then check that. That is the wrong register. Describing what the finished thing should be, and what it must not contain, produces better results than narrating the steps to get there.
I did not say what to leave out. The most useful line in any of my instructions is the one that says what not to do: do not invent numbers I have not given you, do not fill gaps with plausible detail, mark anything you cannot verify. Without that, gaps get filled, and filled gaps read exactly like verified facts.
That second one is not an AI-specific lesson. It is the same rule I apply to a project brief handed to a developer. The failure mode is identical: an unstated assumption gets resolved silently, in a way nobody notices until it is expensive.
The part that has not changed
The judgment is still mine. Cowork produces a schema faster than I would, but whether that schema fits the tenancy model the client needs is my call, and if I get it wrong the fact that an agent drafted it is not a defence.
What has changed is where my time goes. Less of it on assembling context and re-explaining it, more of it on the decisions that actually need a person. On a project where the planning phase used to consume most of a week, that reallocation is the whole benefit.
The tool did not make the decisions better. It made the decisions arrive sooner, with more of the reasoning visible when they did.