The conversation is the work

About a month ago I wrote that despite the Claude Code hype I'm still using Cursor. Well, now I use Claude Code as my daily driver. I made this switch because it helped me realize an emerging truth about creating software in the age of LLMs: the conversation is the work.

The people I'm working with on a new project strongly encouraged me to use Claude Code for it (more on that project soon). I set up a new Max plan ($200/mo), installed Ghostty, and ran claude code --dangerously-skip-permissions.

The early results were fine, kind of the same using Opus 4.5 in Cursor. I write some minimal requirements, enter plan mode, review the plan, then the agent executes it. I write the commit message, push, then trigger a Claude code review. So far so good.

I continued using Claude Code as my daily driver for the project. I started customizing my setup further and eventually realized it's not just a coding agent but a full-blown coworker. Here are the things I set up that led me to this realization.

Github integration. I installed the gh cli and set up a basic roadmap project in Github. I wrote a readme with goals, strategy, audience, and milestones; I added a few issues for what's next. Then Claude Code basically became the intermediary through which I did product management.

As I worked on features, I would come up with other ideas or todos for later, ask Claude Code to create issues for them and sort them into Now/Next/Later as it saw fit, referencing the roadmap to inform that.
When I was ready for the next feature, I'd ask it, "What's the most important thing to work on next?" It would look at all the issues, focusing on the ones in the "Now" column, and list a few that were most likely to move the needle on our roadmap goals.

The "pulse" command. I set up MCP connections to Logfire, Posthog, and Stripe. This meant I could ask Claude any metrics-related question like "Show me the onboarding funnel over the past 7 days" or "How many paying customers have set up X integration?"

As I asked these questions it would reveal instrumentation blindspots, which Claude could then rectify with a new PR in less than a minute.
I collated the most common questions I'd ask about into a single command /pulse which pulls data from various sources and reports on core product metrics; it has a default one hour lookback period but it takes a number argument which is the number of hours it can look back. If a user experienced a disruptive error, it drills down into that session and presents a diagnosis and suggested next step.
I typically now start my workday by running /pulse 12 to get a sense of what happened with the product overnight and if there's anything that needs fixing.

Production evals. Previously we'd been using raindrop.ai for evals of the product's agent responses in production. I was considering whether to continue using it or use another evals-as-a-service product like Braintrust. Then I realized Claude itself can do this evaluation.

I gave Claude read-only access to the production db (using a new postgres role) so that it can scan the text of real agent conversations. Then I gave it a prompt to rate each conversation in the lookback period on a scale of 1 to 5 and flag any conversations in which the user expressed either frustration or delight.
This has become the main usage metric I monitor, which in turn is reflected in the product roadmap doc that Claude uses to prioritize tickets. I'm planning to cancel our raindrop.ai subscription as a result. This also helps me prevent human scanning of chat conversations for privacy, taking a page out of Anthropic's playbook.

Support ticket resolution. I'm handling customer support for this project, so I get inbounds from users about issues they're running into.

My workflow is opening the customer email, copying its contents, and pasting it into Claude. Claude pulls the data it needs to understand the situation, inspects the code to understand the relevant part of the application, and reviews recent changes to the code in the git history.
In less than a minute it comes back with a resolution, either in the form of instructions back to the user, a SQL query to run on the prod db (it doesn't have write access), or a proposal for a code change to fix the issue. It also usually includes a draft message back to the user.
I take whatever steps I need to take and get to the user relatively quickly. When a user gets a support resolution (including a product update) within minutes, their view of the product and company behind it switches from negative to positive.

Product research. The product I'm working on aims to improve LLM output along a certain dimension (again, more soon). There's a lot of academic research about LLMs, so I wanted to consult that research in designing a new feature related to LLM output.

I searched arxiv for research on the topic, downloaded several PDFs, fed them into Claude, and asked it to search the web for any related research. It came back with summaries of ten papers and how they could be applied to the design of this specific feature. It then kicked off work on the feature with the research-backed direction. I highly recommend doing this for the more innovative / differentiating features of your own product.

Worktrees. I used to only work on one feature at a time, since only one branch can be checked out locally at a time. I'd heard about worktrees but never used them. Claude Code recently announced native support for worktrees, which I took as a sign I should try them out.

I asked Claude to remember to always create a new worktree when starting work on a code change. It did this flawlessly, so I could start running multiple tabs of Claude Code and work on multiple pull requests simultaneously.
This was great because sometimes Claude takes 5-10 minutes on something, so across several worktrees there's always something for me to give input on.

Could I have done all of this in Cursor? Mostly, I think, though Cursor might've struggled with versioned commands and heavy MCP use (Cursor shows a warning when you have 100 MCP tools available and the Supabase one has flaked on me recently).

The main thing, though, is that the interface of Claude Code helped me recognize additional parts of work that could be handled by the agent. Using an agent without reference to a specific folder or files made me view all my work through the lens of a conversation. The conversation became the work. I started to instinctively converse about more and more parts of the job. Of the time I spend working, I now spend about 90% in Claude Code.

Overnight, the work of creating software changed from many functional specialists logging into multiple apps and manually tinkering with code and data, to a single person chatting with an agent. There will be many implications of this, and we're just starting to see them play out.