Como estruturar código Go para agentes de IA em produção

A agenda oficial da GopherCon 2026 traz um workshop de dia inteiro conduzido por Florin Pățan, engenheiro sênior da Ardan Labs, intitulado "Full-Day Workshop: Ultimate Practical AI". Não estive na sala, então este texto não trata do que foi apresentado, e sim do problema que a ementa se propõe a atacar: como um desenvolvedor Go põe agentes de IA para trabalhar em uma base de código de produção sem transformar isso em fé cega.

O recorte é interessante porque foge do exemplo de brinquedo. Segundo a descrição, o workshop usa o ArdanLabs Service example como aplicação real, um codebase em estilo de produção que dá ao agente "arquitetura de verdade para navegar". Essa escolha carrega uma tese que vale destacar: a qualidade da estrutura do projeto é o que faz ou quebra o trabalho com agentes.

Estrutura primeiro, agente depois

A ementa é direta ao afirmar que "structure is what makes or breaks a project in a world of agents". Faz sentido do ponto de vista de quem já testou: um agente que precisa navegar por um projeto sem fronteiras claras entre pacotes, sem convenções de nomes e sem separação de camadas produz sugestões piores, porque o contexto que ele consegue montar é ruim.

O exercício proposto de pegar um projeto deliberadamente bagunçado e reestruturá-lo junto com o agente, até que ele trabalhe visivelmente melhor do que no início, é o tipo de prática que rende mais do que qualquer prompt mágico. É também um bom teste de sanidade: se reorganizar a árvore de pacotes melhora as respostas, o problema nunca foi o modelo.

Engenharia de contexto e os arquivos de instrução

Outro eixo é a engenharia de contexto: colocar a informação certa na frente do agente. A ementa cita o trabalho com AGENTS.md e CLAUDE.md, arquivos que viraram convenção para dar ao agente regras do projeto, comandos de build e teste, e restrições de estilo. Na prática, esses arquivos funcionam como um README voltado à máquina, e mantê-los enxutos costuma render mais do que enchê-los de tudo.

Há ainda a menção às "skills" de desenvolvimento Go da Ardan Labs e ao critério para decidir quais vale a pena construir para o próprio fluxo. Esse é o ponto que separa hype de engenharia: nem toda automação compensa o custo de manutenção.

RAG, tool calling e MCP como blocos reutilizáveis

Para os temas que não dependem do codebase de exemplo, a ementa promete exemplos autocontidos, pedaços de código que dá para recortar e reaproveitar:

• RAG: conectar o serviço a um modelo e alimentá-lo com dados próprios via recuperação.
• Tool calling e execução de funções: deixar o modelo chamar funções Go reais para bater em APIs, consultar bancos e disparar workflows.
• MCP: expor essas ferramentas do jeito padronizado, com um servidor MCP simples escrito em Go.
• Otimizações: speculative decoding, cache semântico e roteamento de modelos, descritos como "as coisas que deixam rápido o suficiente para ir a produção".
• Segurança: raciocinar sobre vetores de ataque, de prompt injection a exfiltração de dados.

Para o público brasileiro que constrói serviços, o ponto prático é que todo o código é descrito como OpenAI-compatible. Ou seja, roda contra Kronk, AWS Bedrock, Vertex AI ou o que estiver disponível. Isso reduz o lock-in e permite trocar de provedor sem reescrever a camada de integração, algo relevante quando custo e latência variam bastante por região.

Pré-requisitos e o recado de fundo

Os pré-requisitos listados são objetivos: alguns meses de Go, ambiente com Go 1.26 ou superior, Docker ou runtime equivalente, e acesso a um modelo de fronteira (Anthropic, OpenAI ou outro), com opção de rodar localmente via Kronk usando o Qwen 3.6 35B A3B.

O enquadramento que o próprio Pățan dá na ementa merece registro. Ele conta que começou cético, achando que os modelos eram "apenas autocomplete glorificado", e mudou de ideia ao tratar o modelo como um par de programação: um engenheiro que escreve Go rápido, mas sem nenhum senso de negócio ou contexto. É aí que entra o humano no loop.

Essa é a moral que sobrevive fora do workshop: o valor não está em delegar tudo ao agente, e sim em ter o julgamento de saber quando confiar, quando corrigir e como estruturar o projeto para que a ferramenta faça o melhor trabalho possível. Para quem quer se aprofundar, a descrição completa está na agenda oficial do evento.

Fonte: Agenda oficial — Meeting Room 432, Level 4, SCC | Summit