Como usar modelos de pesos abertos como agente de codificação com Amazon Bedrock

A AWS publicou um guia técnico mostrando como usar modelos de pesos abertos no Amazon Bedrock para rodar um agente de codificação por IA sem enviar seu código para APIs de terceiros. O caminho passa pelo OpenCode, um agente de codificação open source escrito em Go que roda no terminal, e por modelos como Kimi K3 (Moonshot AI), GPT-OSS 120B (OpenAI) e Nemotron 3 Super 120B (NVIDIA).

Por que modelos de pesos abertos para programar

Agentes de codificação se tornaram parte central do fluxo de quem escreve, depura e refatora software. Mas as opções tradicionais costumam cobrar por assento, travar você num único provedor ou exigir que dados proprietários trafeguem por uma API externa. Para empresas com requisitos de residência de dados, cargas sensíveis a custo ou necessidade de flexibilidade de modelo, esses são atritos reais.

O movimento do setor é claro: segundo o relatório da McKinsey, 76% das organizações esperam aumentar o uso de IA open source, e os adotantes líderes são 40% mais propensos a usar modelos de pesos abertos. Para codificação, cinco fatores impulsionam a troca: paridade de desempenho (a CrowdStrike reportou 96% de acurácia em consultas válidas com um Nemotron ajustado), eficiência de custo (fluxos agenticos multiplicam o consumo de tokens de 5 a 30 vezes), customização, flexibilidade de modelo e transparência para governança.

Por que o Bedrock como backend

O Bedrock oferece acesso serverless e gerenciado a modelos de pesos abertos — sem provisionar GPU nem gerenciar infraestrutura. Para fluxos corporativos, as vantagens são concretas: residência de dados (código, prompts e respostas ficam na sua conta AWS), controles de segurança que herdam IAM, CloudTrail, PrivateLink e criptografia, e conformidade com HIPAA, SOC 2, ISO 27001, FedRAMP e GDPR. Há três faixas de preço — Priority (latência sensível), Standard (pagamento por token) e Flex (50% mais barato para cargas de latência variável) — e o Bedrock não usa seus dados para treinar modelos.

Escolhendo o modelo certo para cada tarefa

Nem toda tarefa de código pede o mesmo modelo. O guia recomenda uma abordagem multi-modelo:

• Kimi K3 para depuração complexa e raciocínio profundo — ele “pensa antes de responder”, com nível de raciocínio configurável (low, high, max) e contexto de 1 milhão de tokens, o suficiente para carregar um repositório inteiro.
• Nemotron 3 Super 120B para completar código e pair programming interativo — sua arquitetura Mixture-of-Experts ativa só 12B dos 120B parâmetros por token, entregando até 7× mais throughput.
• Modelos menores e ajustados para substituir opções generalistas caras, mantendo a qualidade.

Para comparar, o guia aponta o Artificial Analysis Coding Index (benchmark composto de SWE-Bench, Terminal-Bench e SWE-Atlas) e o Amazon Bedrock Evaluations para rodar comparações lado a lado com pontuação automática ou LLM-as-a-judge.

Como começar

O OpenCode lê e edita arquivos, executa comandos de shell e entende a estrutura do projeto via diagnósticos do Language Server Protocol (LSP), conectando-se a mais de 75 provedores de LLM — incluindo o Bedrock. A configuração é essencialmente apontar o OpenCode para o endpoint do Bedrock com o modelo escolhido:

# Instale o OpenCode (agente open source em Go)
# Configure o provider apontando para o Amazon Bedrock
# e escolha o modelo de pesos abertos desejado
opencode --provider bedrock --model global.moonshotai.kimi-k3

Para cargas com restrição regional, o Bedrock oferece perfis geográficos — o us.moonshotai.kimi-k3 mantém o processamento nos EUA, enquanto o perfil global (global.moonshotai.kimi-k3) roteia para qualquer região comercial e custa cerca de 10% menos. O caso de produção citado no guia é o da Ethara.AI, que usa essa arquitetura com orquestração multi-agente para escalar fluxos de engenharia e pesquisa com IA.

O que considerar antes de adotar

A troca para pesos abertos não é automática: exige avaliar profundidade de raciocínio, latência, custo por token, janela de contexto e disponibilidade regional de cada modelo no seu destino. O ganho é real, mas depende de escolher o modelo certo por tarefa — e de ter a governança de dados já resolvida pela sua conta AWS.