Como usar o ChatGPT para escrever e revisar código Go no dia a dia (com prompts que funcionam)

Fala aí, beleza? O ChatGPT escreve Go rápido pra caramba, mas se tu pede sem contexto ele devolve código genérico e, às vezes, desatualizado 😛

Aquele if err == algumaCoisa que ninguém mais deveria escrever, struct com tag JSON chutada e teste que só cobre o caminho feliz

Neste tutorial eu te mostro como dar contexto de versão no prompt e pedir structs, tratamento de erro idiomático, testes e revisão de código ao ChatGPT, com exemplos de prompt que fogem da resposta genérica

E também onde a revisão humana continua obrigatória antes do commit, porque é aí que o código zoado feito no modo 100% vibe coder costuma escapar…

O que você precisa antes de colar código Go no ChatGPT

Antes de abrir o chat, vale arrumar três coisas

Parece burocracia, mas é o que separa uma resposta útil de uma resposta genérica 🙂

Um projeto Go com go test funcionando:

Todo código que o ChatGPT gerar vai passar pelo go test antes de ir pro commit

Se o teu projeto ainda não roda os testes limpo, resolve isso primeiro, senão tu não sabe se o erro veio da IA ou já estava lá

Qual versão do Go o seu projeto usa?

Olha a linha go do teu go.mod e anota a versão

Na data desta pesquisa, a versão estável mais recente é o Go 1.27, lançado em 19 de agosto de 2026, com as release notes do Go 1.27 publicadas no site oficial

Isso importa porque o modelo pode não conhecer as novidades mais recentes, e aí ele escreve Go como se fosse de alguns anos atrás

Cuidado com código da empresa:

Antes de colar código de trabalho, confere se a conversa pode ser usada pra treinar modelos

No ChatGPT, o caminho é: menu da conta > Settings > Data controls > Improve the model for everyone > desligar > Done

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Se liga num detalhe: com essa opção desligada, são as conversas novas que deixam de ser usadas pra treinar os modelos da OpenAI (a explicação completa está no FAQ de Data Controls da OpenAI)

Se a tua empresa usa ChatGPT Business, Enterprise, Edu ou a API Platform, por padrão as entradas e saídas já não são usadas pra treinar os modelos

Mesmo assim, vale conferir a política interna antes de colar qualquer coisa sensível, beleza?

Passo a passo: prompts de ChatGPT para Go que evitam resposta genérica

A lógica é simples: quanto mais específico o pedido, menos genérica a resposta

É como passar uma tarefa pra um dev novo no time, se tu fala só "faz aí", ele entrega qualquer coisa haha

1. Dê contexto de versão no prompt

Por que começar por aqui? Porque o modelo não sabe qual Go tu usa, e ele pode não conhecer o que saiu recentemente

No Go 1.27, por exemplo, chegaram os métodos genéricos (métodos agora podem declarar seus próprios parâmetros de tipo) e o pacote encoding/json/v2, com padrões mais rígidos: ele rejeita UTF-8 inválido e chaves duplicadas

E desde o Go 1.26 existe o errors.AsType, uma versão genérica do errors.As, type-safe, mais rápida e, na maioria dos casos, mais fácil de usar

Então abre a conversa com um bloco de contexto assim:

Contexto do projeto:
- Go 1.27 (versão do go.mod)
- Existem métodos genéricos (métodos podem ter parâmetros de tipo próprios)
- Existe encoding/json/v2, que rejeita UTF-8 inválido e chaves duplicadas
- errors.AsType existe desde o Go 1.26 (versão genérica de errors.As)

Se você não tiver certeza sobre alguma API dessas versões, diga que não tem certeza em vez de inventar

O erro comum deste passo: não informar a versão e receber padrão antigo, tipo erro comparado com == ou nenhum aproveitamento do que a tua versão já oferece

2. Peça structs descrevendo campos, tags e restrições

"Cria uma struct de pedido" gera uma struct de pedido… de algum lugar da internet 😀

O certo é descrever o payload real, as tags JSON e as regras de cada campo, e pedir explicitamente qual pacote JSON vai ser usado:

Crie uma struct Go chamada Pedido para este payload JSON real:

{"id": "p_123", "cliente_id": "c_9", "total_centavos": 15990, "criado_em": "2026-09-01T10:00:00Z", "cupom": null}

Regras:
- total em centavos, inteiro, nunca float
- cupom é opcional e pode vir null
- as tags JSON devem bater exatamente com as chaves do payload
- diga qual pacote JSON você está assumindo (encoding/json ou encoding/json/v2) e por quê

Uma resposta boa pra esse prompt fica mais ou menos assim:

type Pedido struct {
	ID        string    `json:"id"`
	ClienteID string    `json:"cliente_id"`
	Total     int64     `json:"total_centavos"`
	CriadoEm  time.Time `json:"criado_em"`
	Cupom     *string   `json:"cupom,omitempty"`
}

Repara no ponteiro em Cupom: é ele que deixa tu diferenciar "não veio cupom" de "veio string vazia"

O erro comum deste passo: aceitar tags e tipos sem conferir com o payload real

Uma chave com nome levemente diferente faz o campo ficar vazio sem erro nenhum, e tu só descobre em produção… Tome cuidado!

3. Exija tratamento de erro idiomático

Aqui é onde o ChatGPT mais escorrega quando ninguém pede nada específico

E o que é "idiomático" em Go? São basicamente quatro regras que vêm da documentação oficial:

• Embrulhar o erro com fmt.Errorf e o verbo %w (existe desde o Go 1.13), que deixa o erro original acessível pra errors.Is e errors.As
• Usar errors.Is(err, alvo) em vez de err == alvo, porque o primeiro também funciona quando o erro vem embrulhado (é o que diz a documentação do pacote errors)
• Usar errors.AsType (Go 1.26 ou superior) ou errors.As pra extrair um tipo de erro específico
• Mensagens de erro em minúscula e sem pontuação no final, como manda o Go Code Review Comments, porque normalmente elas são impressas depois de outro contexto

Coloca isso tudo no prompt, sem medo de ser chato:

Reescreva esta função seguindo estas regras de erro:
- embrulhe erros com fmt.Errorf e %w, adicionando contexto
- nunca compare erro com ==, use errors.Is
- para extrair tipo de erro, use errors.AsType (projeto está em Go 1.27) ou errors.As
- mensagens de erro em minúscula e sem pontuação no final
- não descarte o erro original em nenhum caminho

Função (cole logo abaixo desta linha):

O resultado esperado segue esse padrão:

var ErrPedidoNaoEncontrado = errors.New("pedido não encontrado")

func (r *Repo) Buscar(ctx context.Context, id string) (*Pedido, error) {
	p, err := r.db.BuscarPedido(ctx, id)
	if err != nil {
		return nil, fmt.Errorf("buscar pedido %s: %w", id, err)
	}
	return p, nil
}

// quem chama:
if errors.Is(err, ErrPedidoNaoEncontrado) {
	// responde 404, por exemplo
}

O erro comum deste passo: resposta que compara erro com == ou que perde o erro original

O clássico é trocar %w por %v na mensagem: o texto fica igualzinho no log, mas o errors.Is para de encontrar o erro lá embaixo, e aí o teu 404 vira 500 sem ninguém entender por quê

4. Peça testes table-driven com os casos de borda listados

Os testes orientados por tabela são o padrão documentado no Go Wiki sobre table-driven tests pra cobrir vários casos sem ficar copiando e colando código de teste

Mas se tu pede só "cria os testes", o ChatGPT tende a testar o caminho feliz e ir embora

Então tu mesmo lista os casos de borda:

Escreva um teste table-driven para a função ValidarCupom(cupom string) error

Casos que DEVEM estar na tabela:
- cupom válido
- string vazia
- cupom com espaços antes ou depois
- cupom em minúsculas
- cupom com caracteres especiais

Use t.Run com o nome de cada caso
Não invente regras de validação: se não souber a regra, deixe um comentário TODO

O esqueleto que sai disso é mais ou menos este:

func TestValidarCupom(t *testing.T) {
	tests := []struct {
		name    string
		cupom   string
		wantErr bool
	}{
		{"cupom valido", "PROMO10", false},
		{"cupom vazio", "", true},
		{"cupom com espacos", "  PROMO10 ", true},
	}

	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			err := ValidarCupom(tt.cupom)
			if (err != nil) != tt.wantErr {
				t.Errorf("ValidarCupom(%q) erro = %v, wantErr %v", tt.cupom, err, tt.wantErr)
			}
		})
	}
}

Repara no "não invente regras" do prompt: sem isso o modelo pode chutar o comportamento esperado e escrever um teste que confirma o bug em vez de pegar ele

O erro comum deste passo: teste que só cobre o caminho feliz

Passa verde, dá sensação de segurança e não protege nada 🙂

5. Peça revisão com checklist, não "revise isso"

"Revise esse código" é o prompt mais genérico que existe, e a resposta costuma ser genérica na mesma medida

O que funciona melhor é colar um diff pequeno (só o que mudou) e dar um checklist do que tu quer que ele olhe:

Revise este diff de um projeto em Go 1.27

Verifique especificamente:
1. tratamento de erro: algum erro ignorado, comparado com == ou sem %w?
2. concorrência: goroutines sem controle de término, acesso a mapa ou variável compartilhada sem sincronização
3. nomes: algo fora das convenções do Go Code Review Comments?
4. testes: quais casos este diff criou que não estão testados?

Para cada problema, cite a linha e explique o risco
Se não encontrar problema num item, diga "nada encontrado" em vez de elogiar o código

Diff (cole logo abaixo desta linha):

Essa última linha é ouro: ela corta aquele parágrafo de elogio que não serve pra nada haha

O erro comum deste passo: colar o arquivo inteiro e receber elogios genéricos

Arquivo grande dilui a atenção da revisão, e tu recebe um "o código está bem estruturado" que não te ajuda em nada

Revisão humana antes do commit: o que o ChatGPT não substitui

O ChatGPT faz uma primeira passada, mas quem assina o commit é você

E isso fica ainda mais sério quando o código está numa linguagem que tu ainda está aprendendo (tem um post aqui sobre revisar código numa linguagem nova que vale ler junto)

Este é o checklist obrigatório, na ordem:

1. Rode o go test (que já roda o go vet)

go test

Se liga nisso: ao compilar o binário de teste, o go test já roda o go vet no pacote e nos arquivos de teste

Se o vet encontra problemas significativos, o go test reporta e nem executa o binário, então tu ganha uma análise estática de brinde 😀

O erro comum deste item: achar que o código "compila, então está certo" e pular os testes porque o ChatGPT disse que estava tudo ok

2. Rode o detector de data race no código concorrente

Se o código mexe com goroutines, adiciona a flag -race:

go test -race mypkg

(troca mypkg pelo teu pacote; a mesma flag funciona em go run -race e go build -race)

O detector de race do Go não gera falsos positivos, então se ele reclamou, tem problema de verdade

Mas ele só é tão bom quanto os teus testes: se nenhum teste exercita o trecho concorrente, ele não vê nada

E tem custo: a execução fica de 2 a 20 vezes mais lenta e o consumo de memória aumenta de 5 a 10 vezes, então nada de PC da Nasa, mas também não é pra deixar ligado em produção sem pensar

O erro comum deste item: rodar o -race, ver tudo verde e concluir que não existe race, quando na real os testes nem passaram pelo código concorrente

3. Rode o govulncheck nas dependências

Primeiro instala:

go install golang.org/x/vuln/cmd/govulncheck@latest

Depois roda no diretório do projeto:

govulncheck ./...

O legal do govulncheck é que ele só aponta vulnerabilidades que realmente afetam o teu código, com base nas funções vulneráveis que tu chama direta ou indiretamente

Ou seja, menos ruído e mais alerta que importa

O erro comum deste item: aceitar a dependência que o ChatGPT sugeriu (ou a versão dela) sem checar nada, só porque "parecia conhecida"

4. Leia o diff com os seus olhos

Nenhuma ferramenta acima pega tudo, então a leitura humana continua obrigatória

Foca em três coisas:

• Lógica de negócio: o código faz o que a regra do produto pede, ou só o que o prompt descreveu?
• APIs inventadas: função, método ou pacote que não existe (ou existe com outra assinatura)
• Versão errada: uso de recurso de uma versão do Go diferente da que está no teu go.mod

Dá até pra revisar com outro modelo como segunda opinião, mas isso não substitui a tua leitura

O erro comum deste item: ler só o resumo que o ChatGPT escreveu sobre o código em vez de ler o código

Quando o ChatGPT ajuda mais (e quando atrapalha) no código Go do dia a dia

Não existe fórmula mágica aqui, mas dá pra separar bem onde ele rende e onde ele pede cuidado dobrado

Onde ele costuma ajudar:

• Boilerplate de structs: com o payload real no prompt (passo 2), ele poupa a digitação chata, e tu só confere as tags
• Esqueleto de testes de tabela: tu lista os casos (passo 4) e ele monta a estrutura, economizando o copia e cola
• Migração de padrões de erro: trocar == por errors.Is, adicionar %w, padronizar mensagens (passo 3) é trabalho repetitivo e bem definido, o tipo de coisa que ele faz bem
• Primeira passada de revisão: com checklist e diff pequeno (passo 5), ele levanta pontos pra tu investigar

Onde ele pode atrapalhar:

• Concorrência: código com goroutines parece certo e quebra só às vezes, então aqui o go test -race e os testes bem escritos são obrigatórios
• Segurança: dependência sugerida, validação de entrada e manipulação de dados sensíveis pedem govulncheck e leitura atenta
• APIs novas: métodos genéricos, encoding/json/v2 e errors.AsType são exatamente o tipo de coisa que o modelo pode não conhecer, e aí ele inventa ou volta pro padrão antigo

Resumindo: quanto mais repetitivo e bem definido o trabalho, mais ele ajuda

Quanto mais sutil e recente, mais tu precisa conferir

Próximo passo: monte seu prompt base para Go

A receita inteira cabe em três pedaços: contexto de versão, pedido específico e verificação com go test, -race e govulncheck

O ChatGPT acelera a escrita, mas quem garante que o código está certo é o teu checklist antes do commit

Então o próximo passo é bem concreto: salva um prompt base com a versão do Go do teu go.mod e as regras de erro do passo 3

No próximo PR, cola ele no início da conversa e vê a diferença na resposta, faça o teste! 🙂

Até o próximo post!