Aider

Most coding assistants live inside an editor and suggest the next few lines. Aider takes a different position: it runs in the terminal, works directly on a git repository, and treats each change as a commit rather than a suggestion waiting to be accepted.

How it works
You start Aider in a project directory and describe what you want in plain language. It edits files on disk, runs your tests or linter if you have wired them in, feeds any failures back to the model, and commits the result with a generated message. Two design choices do most of the work:

• A repository map — a condensed index of the project's files, classes and function signatures — so the model can navigate a large codebase without the whole thing being pasted into the context window.
• Explicit file scoping: you add the handful of files a change concerns, which keeps the prompt small and the edits contained.

Changes come back as search-and-replace blocks or whole-file rewrites depending on the model, and Aider is model-agnostic — you choose which provider to point it at.

Why git is the safety layer
An agent editing your source is precisely the case where an irreversible action is a live risk. Committing every change converts that risk into a one-command undo, and leaves the agent's trajectory readable afterwards as commit history. Aider sits at the lighter end of the coding-agent spectrum — closer to a fast pair programmer than to SWE-agent or Devin, which attempt whole issues unattended — and that modest scope is a large part of why it stays practical on real codebases.