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

casos de uso do OpenCode no dia a dia de quem programa
Resposta rápida

Os casos de uso do OpenCode que mais economizam tempo no dia a dia são cinco: entender um repositório novo, refatorar um módulo antigo, caçar bug, escrever teste e documentar. O OpenCode é um agente de codificação open source, com licença MIT, que roda no terminal, no editor e no desktop, com repositório na organização Anomaly no GitHub. Dois detalhes mudam o resultado: o LSP vem desabilitado por padrão e só liga com "lsp": true na configuração, e o V2 em beta (binário opencode2) não tem runtime de LSP. A revisão do que entra no código continua humana

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
  1. Se preferir o caminho do npm, dá na mesma:
Formação Vibe Coding
Formação Recomendada

Formação Vibe Coding

Do Prompt ao Produto: Crie Software Real com IA

  • 474 aulas
  • 20 projetos
  • 39h 27min
npm install -g opencode-ai
  1. 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

  1. 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

  1. 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

Item Versão 1 V2 (beta)
Binário opencode opencode2
Config lsp liga os servidores embutidos aceita e preserva, mas não inicia nem baixa servidores
Servidores LSP embutidos sim não há
Diagnósticos nas ferramentas de arquivo sim, como feedback do agente não adiciona
Ferramenta de LSP exposta sim não expõe

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!

Perguntas frequentes

O OpenCode é gratuito ou precisa de assinatura paga?

O OpenCode em si é open source, licença MIT, e funciona com mais de 75 provedores de LLM, incluindo modelos locais. Quem quiser um caminho de assinatura tem o OpenCode Go, que custa US$ 5 no primeiro mês e US$ 10 por mês depois, com cancelamento a qualquer momento.

Como instalar o OpenCode no terminal?

A instalação recomendada é pelo script oficial: curl -fsSL https://opencode.ai/install | bash. Quem preferir npm também pode rodar npm install -g opencode-ai, o resultado é o mesmo.

Como habilitar o LSP no OpenCode?

O suporte a LSP não vem ligado por padrão: se a chave lsp for omitida na configuração, todos os servidores ficam desabilitados. Basta definir "lsp": true pra ligar todos os servidores embutidos, ou usar um objeto pra configurar servidores customizados; "lsp": false desabilita de vez.

Qual a diferença entre os agentes Build e Plan no OpenCode?

O Build é o agente padrão, com todas as ferramentas habilitadas pra mexer no código. Já o Plan é restrito, pensado pra análise e planejamento sem alterar nada, e a troca entre os dois durante a sessão é feita pela tecla Tab.

Como compartilhar uma sessão do OpenCode com outra pessoa?

O compartilhamento é manual por padrão, as sessões não saem compartilhando sozinhas. O comando /share gera uma URL única de qualquer sessão e já copia pra área de transferência.

O OpenCode V2 substitui a versão 1?

Não. O V2 está em beta, instala e roda como opencode2, e dá pra manter as duas versões instaladas lado a lado. Vale reparar que no V2 a configuração lsp é aceita e preservada, mas não inicia nem baixa servidores, então quem depende do LSP como feedback do agente ainda fica na v1.



Subscribe
Notify of
guest

0 Comentários
Oldest
Newest Most Voted

Formações

Formação SAAS com IA

Formação SAAS com IA

Tire usas ideias do papel criando softwares com IA, integre pagamentos e lance seu projeto!

  • 291 aulas
  • 18 projetos
  • 24h 17min

Blog | Mais populares