OpenCode: como eu uso IA direto no terminal para programar
Vinicius Fraga
Conheça o Rocketseat Para Empresas
Oferecemos soluções personalizadas para empresas de todos os portes.
Antes do OpenCode
Meu primeiro contato com IA no desenvolvimento foi como o de muitas pessoas: ChatGPT aberto no navegador, código no VS Code. Copiava a função, colava no chat, esperava a resposta, copiava de volta. Funcionava para funções isoladas. Mas o vai-e-vem entre janelas matava o ritmo. Além disso, tinha a dificuldade de ter que anexar tudo, pois o ChatGPT não tinha acesso aos meus arquivos, não conseguia fazer buscas no meu sistema, etc.
O passo seguinte foi o Copilot no VS Code. Melhor, porque a IA já estava dentro do editor. Mas na época era mais limitado, sem modo de planejamento, contexto raso do projeto. Resolvia o imediato, mas não entendia o todo.
Foi quando colegas do time me indicaram o OpenCode. E aí minha experiência com IA mudou muito (pra melhor).
O que é o OpenCode
OpenCode é um client open source que conecta você a agentes de IA direto no seu sistema operacional. Diferente de soluções proprietárias que te prendem no ecossistema delas, o OpenCode aceita dezenas de providers (e você escolhe o modelo que quiser).
Alguns pontos que me chamaram atenção de cara:
- Open source com comunidade ativa: milhares de stars no GitHub, releases frequentes, evolução constante.
- Baixa barreira de entrada: instala com um comando, roda opencode no terminal e já cai na interface pronta para usar.
- Flexibilidade de providers: GitHub Copilot, Anthropic, OpenAI, Google, e outros. Se você não tem chave de nenhum, o OpenCode Zen oferece modelos gratuitos para começar.
- Múltiplas interfaces: TUI (a interface no terminal, que é o padrão), Web (com diff de arquivos e visualização completa) e CLI (sem interface, resposta direto no terminal).
A ideia central é simples: a IA deixa de ser uma aba no navegador e passa a ter acesso real ao seu ambiente. Terminal, Git, arquivos, rede. Isso muda completamente o que ela consegue fazer.
.png?table=block&id=372395da-5770-8049-8880-cd662f7eb46b&cache=v2)
Configuração e primeiros passos
Providers e modelos
Depois de instalar, o comando /connect mostra os providers disponíveis. Aqui você pode escolher entre usar uma chave de API direto, testar modelos gratuitos, integrar com assinaturas (ex.: ChatGPT Plus) ou até usar a própria curadoria do OpenCode (Zen).
Uma coisa que aprendi foi que escolher o modelo certo faz diferença. Usando os modelos da Anthropic como exemplo:
- Haiku: rápido e leve. Ideal para tarefas pequenas. Validar uma função, checar um input, responder algo pontual.
- Sonnet: o intermediário. Dá conta de funcionalidades completas, bom contexto do projeto. É o famoso “pau para toda obra”.
- Opus: o mais capaz. Mais lento e caro, mas se recupera melhor de erros complexos. Excelente para analisar bases grandes, criar planejamentos e documentação. Se está disposto a pagar, é o melhor modelo.
.png?table=block&id=372395da-5770-800f-9bce-e419523a1664&cache=v2)
Modo Plan vs Modo Build
Uma das coisas mais úteis do OpenCode é a separação entre dois modos, alternados com
Tab (comando para o TUI):Plan: a IA conversa, propõe, analisa. Pode criar arquivos pontuais, mas o foco é planejar. Uso para entender o projeto, tirar dúvidas, pensar antes de agir. Aqui, ela dá preferência para conversar contigo, analisar o projeto e tirar dúvidas antes de agir.
Build: a IA age. Cria arquivos, roda comandos, mexe no código. Para quando já sei o que quero. Aqui, ela dá preferência para dar uma resposta curta e já tentar implementar algo logo para você validar.
Na prática, alterno entre os dois o tempo todo. Planejo no Plan, executo no Build, volto pro Plan se algo não ficou como esperado.
Arquivo AGENTS.md
O
AGENTS.md é o arquivo de regras e contexto que o OpenCode lê para entender como trabalhar no seu projeto. Funciona em camadas:- Global (na raiz do computador): regras que valem para todos os projetos.
- Raiz do projeto: escopo e contexto daquele repositório específico.
- Pastas internas: contexto local para partes específicas do código.
O OpenCode mergeia todos os níveis automaticamente. E o melhor: ele também lê arquivos de outros agents (
.claude.md, .cursor.md). Ao inicializar com /init, ele cria o AGENTS.md aproveitando o que já existia, não precisa começar do zero..png?table=block&id=372395da-5770-8090-bc03-c55881bf67da&cache=v2)
O ecossistema: Skills, MCP e mais
Skills
Skills são prompts especializados que você instala no projeto. Elas chamam a IA com instruções detalhadas para tarefas específicas: brainstorming (minha favorita), planejamento, code review, debugging.
Dois modos de instalar:
- Global: vale para todos os projetos.
- Por projeto: específica daquele contexto (por exemplo, uma skill para React Router Framework Mode).
Para descobrir skills, o skills.sh funciona como um catálogo. Pesquisa por tecnologia, vê o que cada skill faz, instala com um comando.
Destaque especial para o Superpowers: um conjunto de skills que cobre brainstorming, planejamento, review, debugging e outros fluxos completos.
.png?table=block&id=372395da-5770-8004-a54d-eccfbc09ef43&cache=v2)
MCP (Model Context Protocol)
MCP é um protocolo aberto para a IA se comunicar com ferramentas externas. Se no código usamos HTTP para buscar dados da web, a IA usa MCP para se conectar a serviços como Figma, bancos de dados e documentações.
Um exemplo que uso muito é o Context7: em vez de buscar documentação no Google e cair em páginas desatualizadas, ele serve docs atualizadas diretamente para a IA. Caso real: a IA não conseguia encontrar qual hook usar em uma lib de state machines. Com o Context7, no primeiro hit encontrou a resposta: um hook era simplesmente um alias do outro.
Diferente de skills (que são só arquivos), MCP roda como servidor local. O comando /mcp mostra o status de cada um (enabled/disabled, online/offline).
.png?table=block&id=372395da-5770-80f2-b382-d75de20c3367&cache=v2)
Sessões e compartilhamento
Sessões funcionam como chats do ChatGPT: cada conversa fica salva e você pode retomar depois. Isso é essencial para projetos que levam mais de uma manhã na frente do PC. Você fecha o terminal, volta no dia seguinte e continua de onde parou.
/sessions— lista sessões
/new— cria sessão nova
/fork— cria uma cópia da sessão atual como ponto de partida
Para compartilhar:
/copy— copia conteúdo para o clipboard
/export— gera um arquivo
/share— gera um link público em tempo real (/unshare tira do ar)
Interfaces e acesso remoto
Três formas de usar:
- TUI (padrão): a interface direto no terminal.
- Web (opencode web): client no navegador com diff de arquivos, sessões e navegação pelos arquivos do projeto. Melhor experiência em tela cheia.
- CLI: sem interface, resposta direto no terminal.
E uma coisa bem legal: com pouco esforço dá para acessar de qualquer lugar. Na mesma rede,
opencode web --mdns resolve. Para acesso remoto de verdade, uso Tailscale. Ele cria com muita facilidade uma VPN entre os dispositivos. Instala, conecta, e acessa pelo IP + porta de qualquer lugar.Casos de uso reais
Contribuindo em projeto Python sem dominar a linguagem
O problema: um colega mantinha um projeto inteiro em Python. Precisei contribuir com uma correção, mas não tenho domínio da linguagem.
O que fiz: rodei o OpenCode na raiz do projeto, deixei ler a base e gerar o AGENTS.md a partir das docs existentes. Expliquei o problema, a IA fez as alterações respeitando os padrões do projeto. Trocou chamadas síncronas por assíncronas onde fazia sentido. Usei um segundo modelo (GPT) para revisar o trabalho do primeiro. Cruzar modelos dá mais confiança quando não domino a linguagem. No final, revisei as alterações conferindo com a documentação oficial do Python e do Modal e estava tudo certinho. Pedi para montar o corpo da PR com commits atômicos e mensagens descritivas. PR aprovado e problema resolvido.
Automatizando publicação em massa em plataforma de cursos
O problema: centenas de vídeos precisavam ser publicados individualmente em uma plataforma de cursos. O upload em massa funcionava, mas a publicação era manual: abrir, clicar publish, fechar, repetir.
O que fiz: usei o Agent Browser. Pedi para o OpenCode abrir o Agent Browser no mode head (abrir uma janela do navegador). Loguei manualmente, guiei a IA passo a passo pelo fluxo de publicação, depois pedi para repetir enquanto inspecionava as requisições de rede. A IA identificou que o processo se resumia a duas requisições (token + publish via GraphQL) e gerou um script Node.js que automatiza tudo: publica em sequência com delay entre requisições. Saí de horas de trabalho manual para minutos.
.png?table=block&id=372395da-5770-80d2-8a29-d0381d86fb61&cache=v2)
Design de interface com brainstorming visual (Champions League)
O problema: queria tirar da cabeça uma ideia antiga (um sonho de criança na verdade): criar um simulador de sorteio da Champions League, começando pelo design sem abrir o Figma.
O que fiz: usei a skill de brainstorming junto com o Agent Browser. Passei a logo oficial como referência, a IA inspecionou o site oficial da UEFA e extraiu tokens de cor e tipografia. Primeira versão: cores erradas, fonte genérica. Refinei iterativamente. "o azul é mais ciano", "a fonte é Champions Bold". Depois de algumas rodadas, chegamos na identidade visual correta, com mockups gerados direto no navegador.
Veja o projeto no ar: champions-league-tau.vercel.app
.png?table=block&id=372395da-5770-8040-a78e-d05557d5b21d&cache=v2)
Planejamento e sessões em projeto complexo (Champions League)
O problema: Seguindo com o sonho de criança, decidi deixar a IA criar o projeto completo do zero: gerenciamento de times, dois formatos de sorteio, três modos de draw, validação de regras da UEFA. Complexo demais para uma sessão única.
O que fiz: o brainstorming gerou um spec com 9 fases. Dividi por sessão: uma para cada fase. Ao terminar uma fase, a IA gerava um resumo de contexto para a próxima. Copiava, abria /new, colava, continuava. Isso evita sessões enormes com compactações e facilita voltar a pontos específicos.
O resultado: uma aplicação completa com gerenciamento de times e potes, dois formatos de sorteio (clássico e liga), três modos de draw, e validação das regras oficiais da UEFA. Tudo nasceu desse fluxo de fases organizadas. Obviamente não está perfeito, mas está muito melhor do que eu imaginava quando era mais novo e muito melhor do que eu conseguiria fazer em tão poucas horas entre concepção → publicação.
.png?table=block&id=372395da-5770-807c-b9bb-fe9fe2091c97&cache=v2)
Code Review com IA na equipe
O problema: precisava extrair um padrão de autenticação duplicado em dezenas de server functions para middlewares reutilizáveis. A mudança era mecânica mas espalhada: tocava vários arquivos, com variações sutis (auth opcional, recovery de erro, observabilidade). Fazer tudo manualmente era tedioso, mas não podia deixar a IA fazer sem supervisão.
O que fiz:
- Spec primeiro: usei o OpenCode para analisar a base de código, identificar todos os padrões envolvidos e gerar uma spec detalhada com tasks, arquivos afetados e transformações esperadas. Essa spec virou o contrato entre mim, a IA e o time.
- PR aberta antes de código: criei a branch e abri a PR apenas com a spec. Isso permitiu que colegas revisassem a abordagem antes de qualquer código existir — economia de retrabalho.
- Review humano na spec: o time revisa a spec inteira na PR. Comentários e pedidos de ajuste são feitos direto no GitHub. De volta ao OpenCode, peço para a IA puxar esses comentários via GitHub CLI, aplicar os ajustes e commitar. Esse ciclo repete até a spec ser aprovada.
- Plano de implementação revisado: com a spec aprovada, a IA gera o plano de implementação — a sequência concreta de tasks e transformações. Esse plano também passa por review antes de qualquer linha de código ser escrita.
- Execução com revisão a cada passo: só agora a IA escreve código, task por task. Para cada uma, eu reviso o que foi gerado comparando com a spec — a IA às vezes acerta rápido, mas sem revisão passam bugs sutis. Numa iteração anterior a própria IA pulou a etapa de revisão entre tasks e dois bugs passaram despercebidos.
- Push e review final: com tudo implementado e o build passando, faço push. O time revisa o diff real na PR — não a spec teórica, mas o código concreto. Qualquer ajuste segue o mesmo ciclo: feedback na PR → correção com IA → push.
O resultado: Spec primeiro, código depois. Na minha experiência revisar 50 linhas de spec é mais barato e mais fácil que revisar um diff de 300. A IA executa, você revisa. Não dá para confiar cegamente no output dela, é pedir por bugs. Recomendo abrir o arquivo para ler o código leva, são minutos que podem evitar horas de
debugging e te ajudam a ainda estar por dentro do funcionamento da aplicação, já que quando deixamos de codar isso se torna mais difícil. A PR vira o ponto de encontro natural: o fluxo spec → review → implementação funciona porque a IA se adapta ao feedback humano sem atrito. Ajustar algo na spec é uma edição mais simples do que depois de implementado. E commits atômicos, um por task, permitem que o revisor avalie cada transformação isoladamente em vez de encarar os temidos PRs de um commit, mas descritos e com centenas ou milhares de linhas.Conclusão
Quando a IA tem acesso direto ao ambiente como terminal, Git, arquivos, rede, a fricção desaparece. O salto de produtividade não vem apenas do modelo ser mais inteligente, vem de ter (bom) contexto. Porém, é importante manter o ambiente sob seu controle, para evitar problemas de segurança.
OpenCode é open source, tem modelos gratuitos, e a barreira para experimentar é zero. Instala, conecta, e testa no próximo projeto (ou naquele projeto pessoal que nunca saiu do papel, mesma que seja um sonho bobo de quando você era criança).
Links úteis
Conheça o Rocketseat Para Empresas
Oferecemos soluções personalizadas para empresas de todos os portes.
Vinicius Fraga
Fundador da Plataforma RENDERIZE | Senior Developer Instructor na Rocketseat
Artigos_
Explore conteúdos relacionados
Descubra mais artigos que complementam seu aprendizado e expandem seu conhecimento.
NewsletterReceba conteúdos inéditos e novidades gratuitamente
.png&w=640&q=75)