A Hacker News thread from this week asks a question that cuts at the center of how AI is reshaping developer tooling: if AI writes the code and git tracks the changes, what exactly is the code editor for?
The workflow shift
The original poster describes a workflow that will sound familiar to many developers who have adopted AI coding assistants. Claude Code handles the actual writing in the terminal. JetBrains stays open, but primarily for git integration: browsing commits, reviewing uncommitted changes, previewing what will land in a PR. The diff view with a file tree beside it is the last remaining feature that keeps an IDE in the loop. The coding features themselves have become secondary.
This is not an isolated experience. Tools like Cursor, Windsurf, and the Codex and Claude desktop apps have been converging on the same shape: an AI that writes code, paired with a git interface to review and ship it. The traditional editor, with its syntax highlighting, autocomplete, and refactoring tools, has been hollowed out from the middle. What remains is the input mechanism (now a chat prompt) and the output mechanism (now a diff viewer).
What the editor still does well
Code editors are not useless, but the value proposition has narrowed. Refactoring across multiple files, navigating large codebases by symbol, running and debugging tests in an integrated terminal, and understanding type errors through inline annotations still benefit from a tool that holds the full project state in memory. These are tasks where context matters and where an LLM, asked to make a change, might miss a dependency three files away.
The question is whether those tasks are frequent enough to justify keeping a full IDE open, or whether they are occasional enough to handle with a lighter tool and a quick trip to the terminal.
The git client gap
The poster asks whether anyone knows of a good git client built for this new workflow. The honest answer is that the market has not produced one yet. Most standalone git clients, like GitHub Desktop, SourceTree, or Fork, assume a developer who writes code in a separate editor and wants a visual interface for branching and committing. None of them are designed around the loop of: prompt the AI, review the diff, accept or reject, commit, repeat.
JetBrains, through its Commit tool window and upcoming AI integration, is probably closest to what the poster describes. But it carries the weight of a full IDE. A purpose-built tool for the AI-plus-git workflow would need to be lightweight, fast to open, and centered on diff review and commit history rather than on editing text.
What this means for tool builders
The implication for developers building tools is clear. The demand is not for another code editor with an AI bolted on. The demand is for a thin layer that connects an AI coding agent to a git repository, with good diff visualization, branch management, and the ability to inspect what the AI did before it ships. The editor, as a place where humans type code character by character, is becoming a niche tool for the moments when the AI gets it wrong and you need to fix something by hand.
This is a reversal of the last decade of IDE development, where the play was to add more features, more language support, more integrations. The winning product in this next phase might be the one that removes the most.