Aider ou OpenCode: escolha um CLI para seu projeto Git
Compare Aider e OpenCode por contexto, commits e permissões. Teste os dois CLIs com a mesma pequena alteração em cópias limpas de uma única revisão Git.
Conteúdo

Comece pelo Aider se quiser escolher explicitamente arquivos editáveis e revisar pequenas mudanças no Git. Comece pelo OpenCode se preferir alternar planejamento e execução, controlando ferramentas e agentes. É uma escolha de workflow; a qualidade também depende do modelo, contexto e tarefa.
Use um projeto de teste ou duas cópias limpas da mesma revisão. Não compare no repositório principal com trabalho pendente. Deixe segredos, chaves de trabalho e dados desnecessários fora do contexto.
Compare os controles
| Necessidade | Aider | OpenCode |
|---|---|---|
| Definir arquivos editáveis e de referência | /add, /read-only, /drop, lista com /ls | Confira contexto e permissões de arquivos e ferramentas do agente |
| Discutir antes de editar | /ask, depois /code | Plan e Build |
| Controlar commits | Commits automáticos configuráveis | Defina quais comandos Git podem rodar |
| Restringir ferramentas | Comece discutindo e controle os arquivos adicionados | Regras allow, ask, deny |
A referência de comandos do Aider explica a seleção e o uso de arquivos no chat. O agente principal do OpenCode pode chamar subagents; examine as ferramentas realmente usadas, não apenas o nome do modo.
Configure os commits do Aider primeiro
Por padrão, o Aider faz commit das próprias alterações. Antes de editar arquivos dirty, também pode registrar mudanças preexistentes. Ajuste isso antes da primeira edição se quiser manter controle total do histórico.
Para testar com commits manuais, inicie o cliente instalado e configurado assim:
aider --no-auto-commits --no-dirty-commits
As opções desativam essas duas ações automáticas. Não impedem edições nem substituem backup. Consulte Git integration para o comportamento, /diff e as condições de /undo.
Adicione só o arquivo da tarefa para edição e o de referência como read-only. Confira /ls, entre em /ask e peça a explicação da alteração. Depois de concordar, use /code com uma tarefa restrita. Veja Chat modes.
Confira as permissões do agente OpenCode
OpenCode tem os agentes principais Build e Plan. A documentação atual descreve Plan pedindo aprovação para editar arquivos e executar Bash; Build executa trabalho. O nome Plan não representa um sandbox de arquivos separado. Compare suas configurações com Agents.
Para negar explicitamente edições e comandos no primeiro teste, um projeto novo pode usar:
{
"$schema": "https://opencode.ai/config.json",
"permission": {
"edit": "deny",
"bash": "deny"
}
}
Salve em opencode.json. Em projeto existente, mescle a seção sem substituir o arquivo inteiro. Regras do agente podem sobrescrever as globais; confira antes. A configuração restringe as ferramentas nomeadas, não promete isolar todas as ações externas.
Peça uma explicação do mesmo arquivo sem alterações. Antes de editar, ajuste apenas permissões necessárias e confira os comandos disponíveis. Não libere tudo só para concluir o teste. Veja sintaxe e prioridade em Permissions.
Teste a mesma tarefa pequena
Escolha algo verificável sem confiar na explicação do modelo. Por exemplo, uma função que produz um fragmento URL deve transformar " Release Notes " em "release-notes" e lançar ValueError para uma string vazia. Limite a mudança a um arquivo de função e um de teste.
Registre para cada cliente a mesma revisão inicial e o mesmo prompt, modelo e fonte de acesso, arquivos editáveis, comando de teste permitido e expectativa sobre commits automáticos.
Compare os planos, depois autorize uma edição limitada em cada cópia. Rode seu teste e examine:
git status --short
git diff --check
git diff --stat
git log -3 --oneline
Depois de um commit automático, git diff pode estar vazio. Compare o HEAD atual à revisão inicial registrada para ver toda a mudança. Confira arquivos untracked separadamente; o diff normal não os inclui.
Se forem necessários mais arquivos ou permissões, anote o motivo específico. Isso ajuda mais do que «pareceu mais rápido». Um teste bem-sucedido não prova vantagem em outras linguagens, modelos ou repositórios.
Decida pelo resultado
Escolha Aider se controlar contexto manualmente e revisar pequenas mudanças funciona bem para sua tarefa. Escolha OpenCode se precisar de agentes diferentes e controles de ferramentas, com permissões reais claras e verificáveis. Se algum editar um arquivo extra ou criar commit inesperado, ajuste a configuração e repita o teste.
Verifique conexão API separadamente da qualidade da edição: autorização bem-sucedida não prova código correto. Já existe uma instrução de instalação do OpenCode; aqui, o critério é um resultado controlado no projeto Git.