OpenCode: 5 casos de uso no dia a dia de quem programa

Fala aí, beleza? Agente de código que mora no terminal e enxerga o projeto inteiro é uma categoria bem diferente de "autocomplete espertinho"

O OpenCode é um agente de codificação open source, com licença MIT, que roda no terminal, no editor e no desktop

O código é público e vive na organização Anomaly no GitHub, em anomalyco/opencode (o antigo endereço sst/opencode redireciona pra lá)

A ideia aqui é a mesma de outras listas do blog, tipo os casos de uso do Claude Opus 5, só que agora com um agente que vive na sua TUI

São 5 situações reais, cada uma com o que esperar e o que ainda pede revisão humana, beleza? Bora 😀

O que você precisa antes de rodar os casos de uso

Nada de PC da Nasa aqui, o setup é curto

1. Instalar pelo script oficial:

curl -fsSL https://opencode.ai/install | bash

2. Se preferir o caminho do npm, dá na mesma:

Formação Recomendada

Formação Agentes de IA

Domine a criação de Agentes de IA e Venda para Empresas

• 402 aulas
• 32 projetos
• 38h 19min

Conhecer formação

npm install -g opencode-ai

3. Conectar um provedor de LLM com o comando /connect dentro da TUI

O erro comum deste passo é sair procurando um arquivo de config pra colar a chave na mão: as credenciais são gravadas em ~/.local/share/opencode/auth.json pelo próprio /connect

4. Escolher o modelo

O OpenCode usa a AI SDK e o Models.dev pra suportar mais de 75 provedores de LLM, incluindo modelos locais

Se você tá começando e não quer testar provedor por provedor, existe o OpenCode Zen, a lista curada de modelos testados e verificados pelo time do OpenCode

5. Ligar o LSP na configuração

O suporte a LSP NÃO vem ligado por padrão

Se a chave lsp for omitida, todos os servidores LSP ficam desabilitados

{
  "lsp": true
}

Um objeto no lugar do true permite configurar servidores customizados ou sobrescrever os embutidos, e "lsp": false desabilita de vez

E se o seu caminho de acesso a modelo for assinatura, o OpenCode Go custa US$ 5 no primeiro mês e US$ 10 por mês depois, com cancelamento a qualquer momento

5 casos de uso do OpenCode no dia a dia

Cada caso abaixo segue a mesma receita: a situação, como conduzir, o que esperar e o que ainda exige revisão humana

Caso 1: entender um repositório novo

A situação: você caiu num projeto que nunca viu, com pastas demais e nenhum README que sirva pra alguma coisa

Como conduzir: comece pelo agente Plan

O OpenCode traz dois agentes primários embutidos: o Build (padrão, com todas as ferramentas habilitadas) e o Plan (restrito, pra análise e planejamento sem alterar o código)

A troca entre eles durante a sessão é feita pela tecla Tab (ou pelo keybind switch_agent que você configurar)

Depois, rode o /init, que varre os arquivos importantes do repositório e cria ou atualiza o AGENTS.md com orientação específica do projeto: build, lint, test, estrutura e arquitetura não óbvias

O que esperar: um mapa inicial do projeto e um AGENTS.md que serve de ponto de partida pras próximas sessões

O que ainda exige revisão humana: o AGENTS.md gerado é rascunho

Confira os comandos de build e test linha por linha antes de tratar aquilo como verdade, porque o resto do time vai herdar esse arquivo

Caso 2: refatorar um módulo antigo

A situação: aquele módulo que ninguém toca há meses, cheio de função gigante e nome que mente

Como conduzir: aqui o LSP é o pulo do gato

Com o LSP habilitado, o OpenCode usa os diagnósticos do language server como feedback pro agente

Ao abrir um arquivo, ele confere a extensão contra os servidores habilitados e sobe o servidor apropriado se ainda não estiver rodando

Na prática: o agente mexe, o language server reclama, o agente vê a reclamação

E antes de soltar o Build em cima do módulo, ajuste as permissões por ferramenta, que aceitam três ações (allow, ask e deny) e podem ser configuradas por padrão de comando

{
  "permission": {
    "bash": {
      "*": "ask",
      "git *": "allow",
      "rm *": "deny"
    }
  }
}

Tome cuidado com a ordem: a última regra que casar é a que prevalece

O que esperar: refatoração que pelo menos não quebra o que o language server consegue enxergar

O que ainda exige revisão humana: diagnóstico limpo não é prova de comportamento igual

Código que compila e código que faz a mesma coisa são assuntos diferentes, então a suíte de testes e a leitura do diff continuam sendo suas

Caso 3: caçar bug

A situação: um bug com três suspeitos e você fica trocando de teoria no meio da mesma conversa, até o contexto virar sopa

Como conduzir: uma hipótese por sessão

O OpenCode permite iniciar múltiplos agentes em paralelo no mesmo projeto

O comando /new (alias /clear) abre uma linha de investigação limpa, e o /sessions (aliases /resume e /continue) lista e alterna entre as sessões

Assim a teoria A não contamina a teoria B, e você volta pra qualquer uma sem perder o que já foi levantado

O que esperar: varredura mais rápida do código suspeito e hipóteses organizadas em vez de um chat único e confuso

O que ainda exige revisão humana: a reprodução do bug

Enquanto você não vir o erro acontecer e sumir, o que existe é uma explicação plausível, não uma correção

Caso 4: escrever teste

A situação: módulo sem teste nenhum e você precisa de uma base pra começar hoje

Como conduzir: subagentes são assistentes especializados que os agentes primários podem invocar, e você também pode chamar manualmente mencionando com @ na mensagem

É tipo passar a bola pro especialista da casa em vez de pedir tudo pro mesmo agente generalista

Com o LSP ligado, o diagnóstico do language server já te diz se o arquivo de teste está de pé antes mesmo de rodar

O que esperar: rascunho de teste rápido, principalmente pro caminho feliz e pro esqueleto de arquivo

O que ainda exige revisão humana: cobertura é julgamento, não é sinal automático

O agente não sabe qual regra de negócio dói mais se quebrar, e teste que só confirma o que o código já faz é teste decorativo

Caso 5: documentar

A situação: o conhecimento do projeto tá na cabeça de duas pessoas e no histórico do Slack, sabe como é 🙂

Como conduzir: o AGENTS.md carrega instruções que entram no contexto do modelo

Existe a versão do projeto e existe a global, em ~/.config/opencode/AGENTS.md, aplicada a todas as sessões

Pra mostrar o raciocínio pro time, o /share gera uma URL única copiada pra área de transferência

E se documentação é o seu gargalo maior, tem uma lista aqui no blog sobre casos de uso do NotebookLM que caminha bem ao lado dessa

O que esperar: documentação viva que serve pra pessoa e pro agente ao mesmo tempo

O que ainda exige revisão humana: tudo que vira regra pro modelo

Instrução errada no AGENTS.md não é só documentação ruim, ela passa a guiar as próximas sessões

Três tropeços comuns (e como evitar)

1. O agente parece cego ao projeto

Sintoma: ele mexe no código e não percebe erro óbvio de tipo ou import

Causa: o LSP vem desabilitado por padrão, e omitir a chave lsp desliga todos os servidores

Solução: definir "lsp": true na configuração (ou um objeto, se você precisa de servidor customizado)

2. Comando destrutivo passando batido

Sintoma: aquele frio na barriga com os rm -rf da vida

Causa: a maioria das permissões vem como allow por padrão, e só doom_loop e external_directory vêm como ask

Solução: configurar as permissões por ferramenta antes de soltar o agente em repositório sério, lembrando que a última regra que casa é a que vale

3. A sessão não aparece pro time

Sintoma: você conta o que o agente fez e ninguém consegue ver

Causa: o compartilhamento é manual por padrão, as sessões não são compartilhadas automaticamente

Solução: rodar /share na sessão que interessa e colar a URL onde o time conversa

Prevenção prática dos três: deixe permissões e lsp resolvidos no config UMA vez, antes do primeiro caso de uso, e não no meio do incêndio

OpenCode V2 em beta: o que muda para esses casos de uso

Aqui vai o aviso honesto, com data de 2 de agosto de 2026

O OpenCode V2 está em beta, instala e roda como opencode2 e não substitui o binário opencode da versão 1, então dá pra manter as duas instaladas lado a lado

O ponto crítico pra essa lista é o LSP

Consequência prática: os casos que dependem de diagnóstico do language server, principalmente a refatoração e o teste, hoje pedem a versão 1

Dá pra usar o V2 pro resto e manter o opencode da versão 1 pro que precisa de LSP, sem escolher lado 😀

Por onde começar

Não tenta rodar os 5 casos de uma vez, escolhe um

1. Instale pelo script oficial (ou pelo npm, tanto faz)
2. Rode /connect e conecte um provedor
3. Ligue o LSP com "lsp": true na configuração
4. Rode /init no repositório em que você já trabalha hoje
5. Escolha UM caso da lista, de preferência o Caso 1, e vá até o fim nele

O limite honesto é esse: o agente acelera leitura, rascunho e varredura, e faz isso muito bem

Mas a revisão do que entra no código continua humana, porque diagnóstico limpo e teste verde não substituem alguém que entende a regra de negócio

Testa aí e me conta como foi, até o próximo post!