Claude CoWork — Async AI Pair Programming in Practice

Most of what I’ve written about Claude Code so far has been about synchronous interaction: you type, it responds, you decide what to do with the output. That’s the dominant mode and it’s genuinely useful.

Claude CoWork is different. It’s designed around a different interaction model — one that maps better to how senior engineers actually spend their time, where work isn’t a continuous stream of focused coding sessions but a fragmented mix of tasks, reviews, context switches, and parallel concerns.

Let me explain what I mean by that and how I’ve integrated it into my workflow.

---

The Problem With Purely Synchronous AI Use

When you use Claude Code synchronously — read code, ask question, read answer, write code, repeat — you’re capped by your own attention. The AI is fast, but the loop speed is limited by your ability to process the output and form the next input.

For focused coding sessions this is fine. For the kind of multi-threaded work that fills a senior engineer’s day — three things in flight, each in a different stage, switching between them as blockers resolve — it’s not the right model.

Claude CoWork is designed for the second kind of work. The core idea is that you can hand off a task to Claude, go do something else, and come back to a detailed artifact — analysis, draft, refactored code, documentation — that you then review and steer.

It’s less like a conversation and more like working with a diligent colleague who takes the brief seriously and delivers without needing to be watched.

---

What It Actually Looks Like

Let me give you concrete examples from my own usage rather than describing it abstractly.

Example 1: Parallel code analysis while in a meeting

I have a two-hour architecture review coming up. There are four services involved, two of which I’m less familiar with. Before the meeting I open Claude CoWork, paste the key files from each service, and ask it to prepare: summarise each service’s responsibility, identify the integration points, and flag any patterns that look inconsistent or concerning.

I go into the meeting. By the time I need to reference the services in detail, I have a clear summary I’ve already reviewed. I’m more useful in the conversation because I’ve been able to prepare faster than I could manually.

Example 2: First-pass code review

A PR comes in from a team member. It’s substantial — three services touched, significant logic changes. I want to give it a thorough review but I’m in the middle of something else.

I hand it to Claude CoWork with context: here’s the PR, here’s what it’s supposed to do, here’s the area of the codebase it touches, flag anything that looks wrong or inconsistent. I get a structured analysis back — not a decision, but a detailed set of observations I can work through quickly when I have focused time.

The review I give after seeing that analysis is better than the review I’d give if I’d gone in cold.

Example 3: Documentation drafting for a module I just finished

I’ve just shipped a significant feature. I know I need to document it — the architecture decision, the API changes, the operational considerations. I don’t want to do it right now while the context is fresh because I have other things pending.

I give Claude CoWork everything it needs: the code, the PR description, the design notes I made during development, the test cases. Ask it to draft the documentation. Later I review, edit, and add the context it couldn’t know.

The documentation gets done. Without this, it probably wouldn’t — or it would happen weeks later when I’d have to reconstruct the context anyway.

---

What Makes It Work Well

High-quality briefs. The single biggest factor in the quality of Claude CoWork output is how well you brief the task. Async work fails when the brief is ambiguous and you’re not there to clarify. Before handing off, take sixty seconds to make the ask explicit: what you want, what context is relevant, what format the output should take, and what you don’t need.

Trust but verify. Claude CoWork output is a first draft and a thinking partner, not a final answer. Every analysis has gaps. Every code change has things that need human judgement. Build review into your workflow — don’t treat async output as done.

Right tasks, not all tasks. Async AI work is good for well-defined tasks with clear deliverables. It’s not good for exploratory work where you don’t know what you’re looking for, or for tasks where the right answer depends on context you can’t easily write down.

---

Where It Earns Its Keep vs. Where It Doesn’t

Where it earns its keep:

• Preparation for meetings or reviews where you need to understand code you haven’t worked with
• First-pass analysis of large PRs or codebases
• Documentation drafts for things you just built while context is fresh
• Research tasks: “here are five approaches to this problem, analyse the tradeoffs for our context”
• Generating options you’ll then evaluate, rather than making the decision directly

Where it doesn’t:

• Exploratory debugging — you need to interact to follow the thread
• Design decisions with significant ambiguity — the back-and-forth matters
• Anything where the right answer depends on knowledge Claude doesn’t have and you can’t brief
• Tasks where the effort of writing a good brief exceeds the effort of doing the task

---

The Workflow Integration

The way I think about it: Claude CoWork is for tasks where I’d otherwise either defer them (and lose the context) or do them synchronously at the cost of something more important.

It doesn’t replace synchronous Claude Code use. It handles the tasks that don’t fit neatly into focused sessions — the prep work, the first-pass reviews, the documentation debt. Those tasks are real, they accumulate, and they have a cost when they don’t happen.

If synchronous Claude Code is a faster conversation, CoWork is a reliable colleague who does the groundwork while you’re busy with something else.

---

Day 9 of the 30-Day AI Engineering series. Previous: Claude Code for Legacy Code Modernisation.