AI coding agentを「1チャット」ではなく「1変更セッション」で運用するThis article proposes managing AI coding agent work in terms of git-scoped…

Developers who rely on AI coding agents are running into a familiar frustration: an agent reports that it "implemented the feature and the tests pass," yet by the next morning the state of the work has become a mystery. This blog post argues that the underlying cause is treating agent interactions as individual chat threads, and it proposes a shift toward managing that work as git-scoped "change sessions" instead. The distinction matters because as agents take on longer, more autonomous runs, the gap between what was discussed in a conversation and what actually landed in the repository grows harder to reconcile.

The problem the article describes will be recognizable to anyone who has delegated a task to a coding agent and then stepped away. When you come back, several questions are difficult to answer. Which commit did the agent start from? How far was it permitted to change? What happened partway through the run? A chat log faithfully preserves the conversation, but it does not map cleanly to the state of the codebase, and that mismatch is precisely where context is lost. The convenience of a single chat window, in other words, hides the fact that the real artifact being produced is a set of file changes, not a transcript.

The proposed remedy is to anchor each unit of work to git rather than to a conversation. In this framing, a session begins at an explicit starting commit, has a defined scope of what may be modified, and ends in a state that can be reconstructed from git history alone. Instead of asking "what did we talk about," the developer asks "what is the diff against the origin commit," which is a question git is designed to answer. This makes the starting point unambiguous, bounds the blast radius of changes, and lets someone returning the next day rebuild their sense of position from branches, commits, and diffs rather than from scrolling back through chat messages.

Technically, this approach leans on primitives that already exist in git and are increasingly surfaced by agent tooling. Feature branches isolate a session's work from the main line, frequent commits act as checkpoints that can be inspected or rolled back, and diffs provide a precise record of scope. Git worktrees are a natural fit for running multiple sessions in parallel without them interfering with one another, since each worktree gives an agent its own working directory tied to a distinct branch. The core idea is that the source of truth for "where am I" should live in version control, which is durable and reviewable, rather than in an ephemeral chat context that is easy to lose or misread.

This thinking aligns with directions already visible across the tooling landscape. Aider, for example, automatically commits each change it makes, effectively turning every edit into a git checkpoint. GitHub's Copilot coding agent operates against a repository and produces pull requests, framing agent output as reviewable branch-and-diff units rather than as raw chat replies. Tools such as Cursor and Claude Code similarly emphasize workspace and change management around an agent's edits. The article's proposal can be read as a discipline layered on top of these capabilities, encouraging developers to think in change sessions regardless of which agent they use.

There are prerequisites worth keeping in mind. The method assumes reasonable git fluency and a habit of committing at meaningful boundaries, and it works best when the scope of a session is deliberately kept small enough to review. It does not eliminate the need to actually read the diff before merging; rather, it makes that review tractable by ensuring there is always a clear origin and a bounded set of changes to examine. Teams that already practice trunk-based development or short-lived feature branches will likely find the transition straightforward.

The broader context is that AI coding agents are moving from interactive assistants toward more autonomous, longer-running collaborators, and the operational practices around them are still maturing. Framing work as git-scoped change sessions appears to be a pragmatic way to keep that autonomy accountable, giving developers a reliable way to answer where work began, how far it went, and how to pick it back up.