GPT-6 Sol para documentação técnica: como virar decisão de arquitetura em ADR, README e resumo que o time lê

Fala aí, beleza? A decisão de arquitetura mais importante do seu time provavelmente está enterrada numa thread do Slack, entre um print e três emojis de foguete

E a documentação dela? Não existe

Em 22/09/2026 a OpenAI soltou o GPT-6 Sol e o GPT-6 Luna, e tem um detalhe no anúncio que interessa MUITO pra quem sofre com isso: os dois herdaram o estilo de comunicação do GPT-6 Astra, com promessa de texto mais claro e com menos jargão

Ou seja, o ganho aqui não é o modelo programar melhor

É ele escrever de um jeito que o time realmente lê…

O que a OpenAI lançou e por que isso muda o texto que o modelo escreve

O anúncio oficial da OpenAI apresenta dois novos membros da família GPT-6, que já tinha o Astra como topo de linha

O posicionamento declarado é bem direto:

• GPT-6 Sol: fluxos de codificação complexa e agentic
• GPT-6 Luna: tarefas de alto volume com objetivo claro, tipo resumir documentos, extrair informação e responder pergunta rápida

Até aí, nada de outro mundo

O que muda o jogo pra documentação é a parte do estilo. A OpenAI diz, com todas as letras: "Expect to see more clarity, less jargon, fewer odd turns of phrase, fewer low-value details, and slightly shorter answers overall without losing substance", e destaca justamente conversas técnicas e de código

Traduzindo o que isso significa no teu dia: menos parágrafo cheio de "é importante notar que", menos detalhe de baixo valor, resposta um pouco mais curta sem perder o conteúdo

E tem o número que sustenta a confiança: na avaliação interna de factualidade da OpenAI, feita com conversas reais desidentificadas, o GPT-6 Sol comete cerca de metade dos erros do antecessor, chegando a uma confiabilidade nível Astra por um custo menor

Agora o balde de água fria, que é honesto colocar aqui: segundo a leitura do Artificial Analysis, o Intelligence Index e o Coding Agent Index ficam no MESMO nível do GPT-5.6, com avanço em algumas avaliações e regressão em outras

O ganho real do salto de geração é o preço, cerca da metade

E é exatamente por isso que documentar com ele passa a fazer sentido: o que antes era caro demais pra gastar token virou barato o suficiente pra rodar em cima de todo repo 🙂

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

Onde você consegue usar o GPT-6 Sol hoje

Antes de montar fluxo, vale conferir se tu tem acesso, porque a distribuição veio picada

No ChatGPT:

• Os planos Plus, Pro, Business, Enterprise e Edu recebem os dois modelos novos, com liberação gradual ao longo do dia
• Agora, ATENÇÃO no recorte: o Sol aparece no ChatGPT Work e no Codex, e não está disponível no Chat comum
• Contas Free e Go recebem o GPT-6 Luna pelo app desktop do ChatGPT
• Em contas Enterprise, a liberação passa pelo administrador: ele precisa habilitar explicitamente os novos modelos (se não apareceu pra ti, provavelmente é isso)

No GitHub Copilot:

• GPT-6 Sol está disponível em Copilot Pro+, Max, Business e Enterprise
• GPT-6 Luna aparece também no Copilot Pro
• Administradores de Copilot Business e Enterprise gerenciam o acesso pela model policy nas configurações do Copilot. Modelos novos entram habilitados por padrão, a não ser que o default global esteja desligado ou o modelo tenha sido desabilitado

Na API, o identificador é gpt-6-sol

Tome cuidado com uma coisa: administrador não avisado é o motivo número um de "aqui não aparece". Se tu tá em Enterprise ou Copilot Business e o modelo sumiu do seletor, o problema raramente é bug, é política

Três documentos que saem da mesma thread de decisão

Aqui tá o pulo do gato do post

A mesma matéria-prima bruta serve pra três artefatos completamente diferentes. E a matéria-prima é aquilo que tu já tem jogado:

• a thread onde a decisão foi tomada (Slack, PR, issue, ata)
• o trecho de código ou o diff que implementou a decisão
• o contexto do produto (o que o sistema faz, quem usa, qual a restrição)

Com esse material, saem três documentos com públicos distintos:

ADR: o documento pro histórico

ADR é Architecture Decision Record

"Que registro é esse?" É um arquivo curto que responde por que vocês escolheram aquilo naquele momento, e ele existe pra quando alguém abrir o repo daqui um ano e perguntar "por que diabos isso usa fila?"

Um ADR decente tem: contexto do problema, alternativas consideradas, decisão tomada, consequências (as boas E as ruins), e status (proposto, aceito, substituído)

O ponto chave: ADR é imutável. Mudou de ideia? Escreve outro ADR que substitui o anterior, não edita o antigo

README: o documento pra quem vai rodar

Aqui o público é o dev que clonou o projeto e quer subir a coisa

O README não quer saber de filosofia de arquitetura. Ele quer: o que é, pré-requisitos, como instalar, como rodar, como testar, como configurar as variáveis

A decisão de arquitetura entra no README só na dose que afeta quem roda (tipo "precisa de um Redis de pé")

Resumo simples: o documento pra produto e liderança

Esse é o que quase ninguém escreve, e é o que mais evita reunião

É um texto curto, sem jargão, explicando o que vai mudar pro usuário, o que fica mais lento ou mais rápido, o que custa mais, e qual o risco em português claro

E é justamente nessa saída que o estilo novo do Sol brilha mais, porque a promessa de menos jargão foi feita pra esse tipo de texto

Por que a mesma entrada serve pros três? Porque os três respondem perguntas diferentes SOBRE O MESMO FATO. Muda o recorte e o público, não a informação de base

Passo a passo: da thread de decisão ao ADR, README e resumo

Esse fluxo é de trabalho, não de instalação. Roda igual no ChatGPT Work, no Codex ou via API

1. Reúna o material bruto e limpe o que é sensível

Copia a thread inteira, o diff relevante e um parágrafo de contexto do produto. Tira token, credencial, IP interno, nome de cliente

O erro comum deste passo: colar a thread pela metade. Tu corta justo a mensagem em que alguém descartou a alternativa X, e o modelo vai INVENTAR um motivo pra ela ter sido descartada

2. Peça um extrato da decisão ANTES de pedir qualquer documento

Esse é o passo que quase todo mundo pula e é o que segura a qualidade das três saídas

O extrato é uma estrutura seca: problema, alternativas, escolha, consequências, lacunas. Nada de prosa ainda

O erro comum deste passo: aceitar o extrato sem ler. Se o extrato tem erro, os três documentos nascem errados juntos, e aí tu revisa três vezes o mesmo problema

3. Gere o ADR a partir do extrato aprovado

Agora sim vira texto. Passa o extrato já corrigido por você, não a thread crua de novo

O erro comum deste passo: deixar o modelo escrever consequência só positiva. ADR sem consequência ruim é propaganda, não documentação

4. Gere o README a partir do MESMO extrato

Mesma fonte, público diferente. Aqui o modelo vai querer inventar comando de setup, se liga nisso

O erro comum deste passo: aceitar npm install && npm run dev genérico. Se o comando não estava no material que tu mandou, ele é chute

5. Gere o resumo para pessoas não técnicas

Pede explicitamente: sem sigla não explicada, sem nome de biblioteca, foco no impacto

O erro comum deste passo: pedir "linguagem simples" e receber texto infantilizado, cheio de analogia de pizzaria. Melhor definir o público real ("gerente de produto que entende do negócio mas não escreve código")

6. Conferência final com quem participou da decisão

Manda os três pra quem estava na thread e pergunta uma coisa só: "tem algo aqui que eu não disse?"

O erro comum deste passo: pular ele achando que revisão sua basta. Você é a pessoa mais contaminada pelo contexto, tu lê o que era pra estar escrito, não o que está

Duas alavancas técnicas que ajudam nesse fluxo, se tu roda via API:

O Sol aceita níveis de esforço de raciocínio none, low, medium, high, xhigh e max. Extrato de decisão e resumo simples não precisam de esforço alto. Reconstruir o porquê de uma decisão a partir de código confuso, aí sim

E a janela de contexto de 1.050.000 tokens segundo a documentação da API muda o que é possível: dá pra jogar a thread inteira, o histórico de commits e boa parte do repo na mesma chamada, em vez de ficar recortando pedacinho

Se tu vai rodar isso repetidamente em cima do mesmo repo, vale estudar reaproveitar contexto entre chamadas antes de sair reenviando tudo toda vez

Prompts base para copiar e adaptar

Nada de "prompt mágico" aqui, essas coisas toscas não existem

São três prompts chatos e explícitos, que é o que funciona. Adapta o que estiver entre colchetes

Prompt 1, o extrato da decisão:

Você vai LER o material abaixo e produzir um EXTRATO ESTRUTURADO.
Não escreva documento ainda. Não escreva prosa.

Material:
[cole aqui a thread da decisão]
[cole aqui o diff ou trecho de código]
[cole aqui 1 parágrafo de contexto do produto]

Produza exatamente estas seções, em bullets curtos:
1. PROBLEMA: qual dor motivou a decisão
2. RESTRICOES: prazo, custo, time, stack, compliance
3. ALTERNATIVAS CONSIDERADAS: uma linha por alternativa,
   com o motivo do descarte EXATAMENTE como aparece no material
4. DECISAO: o que foi escolhido
5. CONSEQUENCIAS POSITIVAS
6. CONSEQUENCIAS NEGATIVAS e dividas tecnicas assumidas
7. LACUNAS: tudo que NAO esta no material

REGRA DURA: se uma informacao nao esta no material, escreva
[LACUNA: descricao do que falta] na secao 7.
Nunca preencha com suposicao, nunca infira motivo nao escrito.

Prompt 2, o ADR:

Escreva um ADR (Architecture Decision Record) a partir do extrato abaixo.

Extrato:
{cole o extrato JA REVISADO por voce}

Publico: pessoa desenvolvedora que vai abrir este repositorio
daqui a 12 meses e nao participou da decisao.

Formato markdown, nesta ordem:
# ADR {numero}: {titulo curto e afirmativo}
Status: [proposto | aceito | substituido]
Data: {data}
## Contexto
## Alternativas consideradas
## Decisao
## Consequencias

Tom: direto, sem jargao desnecessario, sem adjetivo de venda.
Frases curtas. Nada de "e importante notar que".
Maximo 600 palavras.

REGRA DURA: nao invente numero de versao, nome de servico,
metrica ou prazo. Onde faltar dado, escreva [LACUNA: ...].
A secao Consequencias DEVE conter itens negativos.

Prompt 3, README e resumo não técnico:

A partir do mesmo extrato, produza DOIS textos separados.

TEXTO A, README (ou secao de README):
Publico: dev que acabou de clonar e quer rodar.
Estrutura: o que e / pre-requisitos / instalacao / como rodar /
variaveis de ambiente / como testar.
So inclua comando, caminho de arquivo ou variavel que apareca
LITERALMENTE no material. O resto vira [LACUNA: comando de setup
nao informado].

TEXTO B, RESUMO NAO TECNICO:
Publico: pessoa de produto e lideranca, entende do negocio,
nao escreve codigo.
Maximo 200 palavras, em 4 blocos:
- o que muda para quem usa o produto
- o que fica mais rapido, mais lento ou mais caro
- qual o risco principal, em uma frase
- o que precisamos decidir ou aprovar agora

Proibido no TEXTO B: sigla sem explicacao, nome de biblioteca,
nome de padrao de arquitetura.
Proibido tambem: analogia infantilizada. Trate o leitor como
adulto competente em outra area.

Repara que os três prompts repetem a mesma ordem: marcar lacuna em vez de preencher com suposição

É redundante de propósito. É a instrução que mais economiza revisão depois

O que sempre precisa de revisão humana

Metade dos erros ainda é uma quantidade de erros, beleza? "Cerca de 50% menos" não é "zero"

E em documentação o erro é especialmente cruel, porque documento errado tem a mesma cara de documento certo. Ninguém desconfia de um README bem formatado

Os pontos que merecem revisão linha a linha:

Números de versão e dependências

Sintoma: aparece um Node 20+ ou Python 3.11 que ninguém combinou

Causa: o modelo completa com o padrão mais comum do ecossistema, e ainda tem a data de corte de conhecimento em 30 de abril de 2026 pesando na escolha do que é "atual"

Prevenção: mande o package.json, o requirements.txt ou equivalente junto, e proíba versão que não esteja nesses arquivos

Nomes de rotas, variáveis de ambiente e caminhos

Sintoma: DATABASE_URL no README, DB_URL no código

Causa: nome plausível é mais fácil de gerar do que nome real

Prevenção: peça que cada variável citada venha acompanhada do arquivo onde ela aparece. Se ele não consegue citar o arquivo, é chute

O motivo político da decisão

Sintoma: o ADR diz "escolhemos X pela performance superior", quando na real foi porque o time já tinha licença de X

Causa: motivo técnico é o que o modelo espera encontrar. Motivo humano raramente está escrito na thread

Prevenção: esse aqui quase sempre é preenchimento manual. Deixa a lacuna e escreve tu mesmo

Alternativas descartadas

Sintoma: aparece uma alternativa que ninguém chegou a cogitar, com um motivo de descarte redondinho

Causa: o modelo sabe quais são as opções óbvias do mercado e assume que vocês passaram por elas

Prevenção: proibição explícita de listar alternativa que não apareça no material

Prazos e responsáveis

Sintoma: "prevista para o próximo trimestre", "sob responsabilidade do time de plataforma"

Causa: é o tipo de frase que preenche vazio sem soar estranho

Prevenção: proíba data e nome de time que não estejam no material. Sem exceção

Comandos de setup

Sintoma: um passo a passo de instalação lindo, que falha na segunda linha

Causa: comando genérico é o padrão estatístico de qualquer README do mundo

Prevenção: valide rodando. É chato, mas é o único jeito. Já me ferrei uma vez por causa disso, README que instalava dependência que o projeto não tinha mais

E tem um último ponto que não é erro factual, é tom: texto gerado tende a ter um cheiro característico, cheio de simetria e de frase de ligação. Quem quiser aprofundar isso, o assunto de deixar o texto mais natural ajuda a ajustar a saída antes de commitar

GPT-6 Sol ou GPT-6 Luna para documentação: qual escolher

Spoiler: no fluxo acima dá pra usar os dois, cada um num pedaço

A leitura prática: o passo pesado do fluxo é o extrato da decisão em cima de código, e é ali que o Sol se paga

Já resumir uma thread de 400 mensagens é exatamente "alto volume com objetivo claro", que é a descrição do Luna. Pagar preço de Sol pra isso é queimar dinheiro à toa

E tem os modificadores de preço do Sol na API, que mudam bastante a conta:

• Tokens de entrada em cache custam 10% da tarifa de entrada não cacheada
• Batch e Flex custam 50% da tarifa Standard
• Modo Fast custa 2x a tarifa aplicável

Junta isso com o histórico: o GPT-5.6 Sol custava US$ 4 por 1M de entrada e US$ 20 por 1M de saída

O Sol de agora custa metade disso

Documentar repo inteiro em Batch, com o contexto do projeto cacheado, sai numa faixa de preço que simplesmente não existia antes

Veredito: para quem esse fluxo compensa

Vou ser honesto sobre o que mudou aqui, porque tem bastante barulho na internet

Não apareceu inteligência nova. Na régua do Artificial Analysis, o GPT-6 Sol no esforço max marca 48 pontos no Intelligence Index (a mediana de modelos de faixa de preço parecida é 25) e entrega 104 tokens por segundo de velocidade de saída, contra uma média geral medida de 75

Números bons? São. Mas a própria casa que mede disse que o salto de geração é lateral: mesmo nível do GPT-5.6 em Intelligence Index e Coding Agent Index, avanço aqui, regressão ali

O que mudou de verdade foi o preço, pela metade, e a promessa de texto mais claro e com menos jargão

E é exatamente isso que destrava documentação, porque documentação sempre perdeu a disputa por dois motivos: custava caro em atenção humana e saía num texto que ninguém lia

Compensa pra você se: teu time toma decisão em thread e nunca registra, tu tem repo com histórico que ninguém entende, ou tu precisa explicar escolha técnica pra produto toda semana

Não compensa se: tu já tem cultura de ADR rodando e alguém dedicado a isso. Aí a IA é ganho marginal, não mudança de patamar

Dois detalhes pra não tomar susto: a data de corte de conhecimento é 30 de abril de 2026, então ele não conhece o que saiu depois disso e vai errar feio se tu deixar ele "lembrar" de versão de biblioteca nova. E ele aceita texto e imagem como entrada, produzindo texto, o que serve bem pra jogar aquele diagrama de arquitetura que só existe em print no Slack 😀

Próximo passo

Pega UMA decisão que teu time já tomou e nunca documentou

De preferência uma que ainda gera pergunta repetida

Roda o fluxo dos três documentos: extrato, depois ADR, README e resumo simples

Depois faz o teste que importa de verdade: manda o resumo não técnico pra alguém de produto e vê se a pessoa entende sem te perguntar nada

Se entender, tu achou teu fluxo. Se não, o problema quase sempre tá no extrato, não no prompt final

Antes de tudo isso, confere teu acesso: se tu tá em Enterprise ou Copilot Business e o modelo não aparece, fala com quem administra, porque ali depende de habilitação e de model policy

Até o próximo post! =)