Voc\u00ea j\u00e1 abriu um README de um projeto com seis meses de vida e encontrou instru\u00e7\u00f5es para uma vers\u00e3o da API que n\u00e3o existe mais? Ou pior: encontrou um diagrama de arquitetura bonito, feito com capricho num sprint de onboarding, descrevendo um fluxo que foi refatorado tr\u00eas releases atr\u00e1s e ningu\u00e9m atualizou o desenho. A documenta\u00e7\u00e3o n\u00e3o estava errada quando nasceu. Ela apodreceu \u2014 e continuou l\u00e1, quieta, enganando o pr\u00f3ximo desenvolvedor que confiou nela.<\/p>\n
Esse \u00e9 o problema real: documenta\u00e7\u00e3o n\u00e3o falha por falta de esfor\u00e7o inicial, falha por falta de manuten\u00e7\u00e3o cont\u00ednua. E \u00e9 exatamente a\u00ed que a IA generativa entra como candidata a solu\u00e7\u00e3o \u2014 n\u00e3o porque escreve texto bonito, mas porque pode ser colocada dentro de um pipeline que roda a cada mudan\u00e7a de c\u00f3digo, mantendo a documenta\u00e7\u00e3o sincronizada com a realidade. O risco, claro, \u00e9 trocar um problema por outro: documenta\u00e7\u00e3o desatualizada por documenta\u00e7\u00e3o plaus\u00edvel, bem escrita e igualmente falsa. Neste artigo vamos construir o meio-termo \u2014 um fluxo de gera\u00e7\u00e3o autom\u00e1tica de docs com IA que \u00e9 audit\u00e1vel, versionado e verificado contra o pr\u00f3prio c\u00f3digo-fonte.<\/p>\n
Documenta\u00e7\u00e3o manual tem uma caracter\u00edstica estrutural que a condena: ela vive fora do ciclo de commit. O desenvolvedor altera a assinatura de uma fun\u00e7\u00e3o, o comportamento de um endpoint, a estrutura de um payload \u2014 e a atualiza\u00e7\u00e3o do texto correspondente depende de lembran\u00e7a, disciplina e tempo dispon\u00edvel, tr\u00eas recursos que costumam faltar exatamente quando o prazo aperta.<\/p>\n
O resultado \u00e9 previs\u00edvel: a documenta\u00e7\u00e3o vira um artefato de arqueologia, \u00fatil para entender como o sistema era, n\u00e3o como ele \u00e9. Isso gera um custo silencioso \u2014 cada nova pessoa no time perde tempo desconfiando de tudo que l\u00ea, ou pior, confia e \u00e9 levada a erro.<\/p>\n
\ud83d\udca1 Dica do Mestre:<\/strong> vale a leitura de este artigo da Coddy sobre o futuro da programa\u00e7\u00e3o assistida por IA<\/a>, que discute como a gera\u00e7\u00e3o autom\u00e1tica de artefatos \u2014 c\u00f3digo e documenta\u00e7\u00e3o \u2014 est\u00e1 deixando de ser exce\u00e7\u00e3o para virar parte padr\u00e3o do fluxo de desenvolvimento.<\/p><\/blockquote>\n
A ilus\u00e3o de que “gerar com IA” j\u00e1 resolve o problema<\/h3>\n
\u00c9 tentador achar que basta apontar uma IA para o reposit\u00f3rio, pedir “documente este projeto” e publicar o resultado. O problema \u00e9 que modelos de linguagem, por padr\u00e3o, tendem a preencher lacunas com generaliza\u00e7\u00f5es plaus\u00edveis quando n\u00e3o t\u00eam contexto suficiente \u2014 o efeito comumente chamado de alucina\u00e7\u00e3o. Uma fun\u00e7\u00e3o mal nomeada pode receber uma descri\u00e7\u00e3o correta na forma, mas errada no conte\u00fado, porque o modelo inferiu a inten\u00e7\u00e3o a partir do nome, n\u00e3o do comportamento real.<\/p>\n
Documenta\u00e7\u00e3o gerada sem verifica\u00e7\u00e3o tem o mesmo problema da documenta\u00e7\u00e3o manual desatualizada, com um agravante: ela \u00e9 escrita com uma confian\u00e7a textual que engana ainda mais r\u00e1pido. Por isso a solu\u00e7\u00e3o n\u00e3o \u00e9 “gerar documenta\u00e7\u00e3o com IA”, \u00e9 “gerar documenta\u00e7\u00e3o com IA dentro de um processo que valida o que foi gerado contra o c\u00f3digo real”.<\/p>\n
Arquitetura do pipeline: as tr\u00eas camadas de uma documenta\u00e7\u00e3o confi\u00e1vel<\/h2>\n
Um pipeline de documenta\u00e7\u00e3o autom\u00e1tica que funciona na pr\u00e1tica tem tr\u00eas camadas distintas. Misturar essas camadas \u00e9 o erro mais comum de quem tenta resolver isso de forma improvisada.<\/p>\n
\n
- Extra\u00e7\u00e3o:<\/strong> coletar fatos do c\u00f3digo \u2014 assinaturas, tipos, coment\u00e1rios existentes, testes, exemplos de uso, mensagens de commit relevantes.<\/li>\n
- Gera\u00e7\u00e3o:<\/strong> transformar esses fatos em texto leg\u00edvel, com a IA atuando como redatora, n\u00e3o como fonte de verdade.<\/li>\n
- Verifica\u00e7\u00e3o:<\/strong> checar se o texto gerado corresponde ao que foi extra\u00eddo, antes de publicar.<\/li>\n<\/ul>\n
A camada que costuma faltar \u00e9 a terceira. A maioria dos tutoriais para at\u00e9 a segunda etapa e trata o texto gerado como produto final. \u00c9 a\u00ed que o “documento plaus\u00edvel, por\u00e9m errado” se instala.<\/p>\n
Camada 1 \u2014 Extra\u00e7\u00e3o: dando \u00e0 IA s\u00f3 o que ela precisa saber<\/h3>\n
O primeiro erro t\u00e9cnico \u00e9 jogar o reposit\u00f3rio inteiro no contexto do modelo e pedir para ele “entender tudo”. Al\u00e9m do custo de tokens, isso dilui a aten\u00e7\u00e3o do modelo e aumenta a chance de erro. O caminho mais robusto \u00e9 extrair estruturadamente antes de gerar.<\/p>\n
Em Python, por exemplo, voc\u00ea pode usar o m\u00f3dulo
ast<\/code> para extrair assinaturas de fun\u00e7\u00e3o, docstrings existentes e anota\u00e7\u00f5es de tipo antes de qualquer chamada de IA:<\/p>\nimport ast\nimport json\n\ndef extrair_funcoes(caminho_arquivo):\n with open(caminho_arquivo, \"r\", encoding=\"utf-8\") as f:\n arvore = ast.parse(f.read())\n\n funcoes = []\n for node in ast.walk(arvore):\n if isinstance(node, ast.FunctionDef):\n funcoes.append({\n \"nome\": node.name,\n \"argumentos\": [arg.arg for arg in node.args.args],\n \"docstring_atual\": ast.get_docstring(node),\n \"linha\": node.lineno,\n \"retorna_algo\": any(\n isinstance(n, ast.Return) and n.value is not None\n for n in ast.walk(node)\n ),\n })\n return funcoes\n\nif __name__ == \"__main__\":\n dados = extrair_funcoes(\"servicos\/pagamento.py\")\n print(json.dumps(dados, ensure_ascii=False, indent=2))\n<\/code><\/pre>\nEsse JSON estruturado \u2014 n\u00e3o o arquivo bruto \u2014 \u00e9 o que voc\u00ea envia para o modelo gerar a documenta\u00e7\u00e3o. Voc\u00ea est\u00e1 entregando fatos verific\u00e1veis, n\u00e3o pedindo para ele adivinhar a partir de um bloco de texto gen\u00e9rico.<\/p>\n
Para projetos em Node.js ou TypeScript, o equivalente \u00e9 trabalhar com a AST via
typescript<\/code> compiler API, ou, de forma mais simples, extrair a assinatura das fun\u00e7\u00f5es exportadas com uma ferramenta de an\u00e1lise est\u00e1tica antes de montar o prompt.<\/p>\nCamada 2 \u2014 Gera\u00e7\u00e3o: o prompt que evita o texto gen\u00e9rico<\/h3>\n
Com os fatos extra\u00eddos, o prompt de gera\u00e7\u00e3o precisa ser expl\u00edcito sobre duas coisas: a estrutura de sa\u00edda esperada e a proibi\u00e7\u00e3o de inventar comportamento n\u00e3o presente nos dados fornecidos.<\/p>\n
Voc\u00ea \u00e9 um redator t\u00e9cnico documentando uma API interna.\n\nRegras obrigat\u00f3rias:\n1. Use APENAS as informa\u00e7\u00f5es fornecidas no JSON abaixo.\n2. Se um comportamento n\u00e3o estiver expl\u00edcito no c\u00f3digo ou nos testes\n fornecidos, escreva \"comportamento n\u00e3o verificado\" em vez de inferir.\n3. Gere no formato: descri\u00e7\u00e3o curta, par\u00e2metros, retorno, exemplo de uso\n baseado no teste fornecido (se existir).\n\nDados extra\u00eddos:\n{{ dados_json }}\n\nTestes relacionados (se houver):\n{{ testes_relacionados }}\n<\/code><\/pre>\nA instru\u00e7\u00e3o “escreva comportamento n\u00e3o verificado em vez de inferir” \u00e9 o detalhe que separa um pipeline profissional de um script de brinquedo. Ela d\u00e1 ao modelo uma sa\u00edda de emerg\u00eancia expl\u00edcita, reduzindo a press\u00e3o para preencher lacunas com inven\u00e7\u00e3o \u2014 um padr\u00e3o de mitiga\u00e7\u00e3o discutido em diversas an\u00e1lises de ferramentas de IA aplicadas a c\u00f3digo, como aponta este panorama sobre ferramentas de IA para desenvolvimento seguro<\/a>, que trata justamente da necessidade de restringir o espa\u00e7o de sa\u00edda do modelo para reduzir riscos em fluxos automatizados.<\/p>\n
Camada 3 \u2014 Verifica\u00e7\u00e3o: o passo que a maioria pula<\/h3>\n
Depois de gerado, o texto precisa ser confrontado com os fatos extra\u00eddos na camada 1. Isso pode ser feito com um segundo passe de IA atuando como revisor, ou com checagens determin\u00edsticas mais simples \u2014 muitas vezes mais confi\u00e1veis, porque n\u00e3o dependem de outra infer\u00eancia de modelo.<\/p>\n
Um exemplo de verifica\u00e7\u00e3o determin\u00edstica: garantir que todo par\u00e2metro extra\u00eddo da assinatura da fun\u00e7\u00e3o aparece descrito no texto gerado.<\/p>\n
def verificar_cobertura(dados_funcao, texto_gerado):\n faltando = []\n for arg in dados_funcao[\"argumentos\"]:\n if arg not in texto_gerado:\n faltando.append(arg)\n\n if faltando:\n raise ValueError(\n f\"Documenta\u00e7\u00e3o da fun\u00e7\u00e3o '{dados_funcao['nome']}' \"\n f\"n\u00e3o menciona os par\u00e2metros: {faltando}\"\n )\n return True\n<\/code><\/pre>\nEsse tipo de checagem simples pega um erro cl\u00e1ssico: a IA descreve tr\u00eas dos quatro par\u00e2metros de uma fun\u00e7\u00e3o e omite o quarto porque ele tinha um nome pouco expressivo. Um revisor humano lendo o texto isolado dificilmente notaria; um script comparando contra a assinatura real detecta na hora.<\/p>\n
\ud83d\udca1 Dica do Mestre:<\/strong> ferramentas de revis\u00e3o de c\u00f3digo com IA seguem essa mesma l\u00f3gica de compara\u00e7\u00e3o estruturada entre o que foi gerado e o que existe de fato no c\u00f3digo. Vale conferir este panorama de ferramentas de IA para revis\u00e3o de c\u00f3digo<\/a> para entender como esse princ\u00edpio de verifica\u00e7\u00e3o cruzada \u00e9 aplicado em outros contextos al\u00e9m da documenta\u00e7\u00e3o.<\/p><\/blockquote>\n
Integrando o pipeline ao fluxo real de desenvolvimento<\/h2>\n
Documenta\u00e7\u00e3o gerada manualmente, uma vez, n\u00e3o resolve o problema estrutural \u2014 ela s\u00f3 adia. O ganho real aparece quando a gera\u00e7\u00e3o roda automaticamente a cada mudan\u00e7a relevante, dentro do pipeline de CI, como um passo que falha o build se a documenta\u00e7\u00e3o ficar fora de sincronia.<\/p>\n
Gatilho por mudan\u00e7a de arquivo, n\u00e3o por agenda<\/h3>\n
Rodar a gera\u00e7\u00e3o de documenta\u00e7\u00e3o uma vez por semana, num cron job, \u00e9 melhor que nada, mas ainda deixa uma janela de defasagem. O ideal \u00e9 acoplar o processo ao pr\u00f3prio commit ou pull request que altera o c\u00f3digo-fonte relevante.<\/p>\n
name: docs-check\n\non:\n pull_request:\n paths:\n - \"src\/**\/*.py\"\n - \"docs\/**\/*.md\"\n\njobs:\n gerar-e-validar-docs:\n runs-on: ubuntu-latest\n steps:\n - uses: actions\/checkout@v4\n\n - name: Instalar depend\u00eancias\n run: pip install -r requirements-docs.txt\n\n - name: Extrair estrutura do c\u00f3digo\n run: python scripts\/extrair_funcoes.py > extraido.json\n\n - name: Gerar documenta\u00e7\u00e3o com IA\n run: python scripts\/gerar_docs.py --entrada extraido.json --saida docs\/api-gerada.md\n\n - name: Validar cobertura de par\u00e2metros\n run: python scripts\/verificar_cobertura.py --docs docs\/api-gerada.md --dados extraido.json\n\n - name: Falhar se houver diverg\u00eancia n\u00e3o resolvida\n run: |\n if grep -q \"comportamento n\u00e3o verificado\" docs\/api-gerada.md; then\n echo \"::warning::Existem trechos de documenta\u00e7\u00e3o marcados como n\u00e3o verificados. Revis\u00e3o humana necess\u00e1ria.\"\n fi\n<\/code><\/pre>\nNote que o pipeline n\u00e3o bloqueia automaticamente o merge quando h\u00e1 trechos marcados como “n\u00e3o verificado” \u2014 ele avisa. Bloquear tudo geraria atrito desnecess\u00e1rio; o objetivo \u00e9 dar visibilidade, n\u00e3o travar o time. Cabe ao revisor humano decidir se aquele trecho precisa de aten\u00e7\u00e3o antes do merge.<\/p>\n
Versionando a documenta\u00e7\u00e3o junto com o c\u00f3digo, n\u00e3o ao lado dele<\/h3>\n
Um erro recorrente \u00e9 manter a documenta\u00e7\u00e3o gerada num sistema separado \u2014 um wiki, um Confluence, um Notion \u2014 desconectado do reposit\u00f3rio. Isso reintroduz o mesmo problema de sincroniza\u00e7\u00e3o que a automa\u00e7\u00e3o deveria resolver. A regra pr\u00e1tica \u00e9 simples: se o c\u00f3digo est\u00e1 no Git, a documenta\u00e7\u00e3o derivada dele tamb\u00e9m precisa estar, versionada no mesmo commit ou no mesmo pull request.<\/p>\n
Isso tamb\u00e9m tem uma vantagem indireta: o hist\u00f3rico de mudan\u00e7as na documenta\u00e7\u00e3o passa a contar a hist\u00f3ria da evolu\u00e7\u00e3o da API, o que ajuda em auditorias e em investiga\u00e7\u00f5es de “por que isso mudou de comportamento”.<\/p>\n
Armadilhas comuns e como depur\u00e1-las<\/h2>\n
Armadilha 1: confiar em exemplos de c\u00f3digo gerados sem execu\u00e7\u00e3o<\/h3>\n
Um dos erros mais frequentes \u00e9 a IA gerar um exemplo de uso da fun\u00e7\u00e3o que parece correto, mas n\u00e3o compila ou n\u00e3o roda \u2014 porque o modelo inferiu a assinatura errada, ou usou um import que n\u00e3o existe no projeto. A solu\u00e7\u00e3o \u00e9 tratar todo exemplo gerado como c\u00f3digo a ser testado, n\u00e3o como texto.<\/p>\n
import subprocess\nimport re\n\ndef extrair_e_testar_exemplos(caminho_markdown):\n with open(caminho_markdown, \"r\", encoding=\"utf-8\") as f:\n conteudo = f.read()\n\n blocos = re.findall(r\"```python\\n(.*?)```\", conteudo, re.DOTALL)\n\n for i, bloco in enumerate(blocos):\n caminho_temp = f\"\/tmp\/exemplo_{i}.py\"\n with open(caminho_temp, \"w\", encoding=\"utf-8\") as f:\n f.write(bloco)\n\n resultado = subprocess.run(\n [\"python\", caminho_temp], capture_output=True, text=True\n )\n if resultado.returncode != 0:\n print(f\"Exemplo {i} falhou:\\n{resultado.stderr}\")\n raise SystemExit(1)\n\n print(f\"{len(blocos)} exemplos validados com sucesso.\")\n<\/code><\/pre>\nEsse script extrai todo bloco de c\u00f3digo Python da documenta\u00e7\u00e3o gerada e efetivamente o executa. Se um exemplo n\u00e3o roda, o pipeline falha antes de publicar \u2014 assim como um teste de integra\u00e7\u00e3o falharia se o comportamento real do sistema mudasse.<\/p>\n
Armadilha 2: documentar comportamento em vez de inten\u00e7\u00e3o<\/h3>\n
IA generativa \u00e9 boa em descrever “o que o c\u00f3digo faz linha a linha”, mas isso n\u00e3o \u00e9 documenta\u00e7\u00e3o \u00fatil \u2014 \u00e9 uma par\u00e1frase do pr\u00f3prio c\u00f3digo. Documenta\u00e7\u00e3o de valor explica a inten\u00e7\u00e3o e as decis\u00f5es de design, algo que s\u00f3 existe fora do c\u00f3digo-fonte: em issues, discuss\u00f5es de arquitetura, mensagens de commit detalhadas.<\/p>\n
Por isso, enriquecer o contexto da gera\u00e7\u00e3o com mensagens de commit e descri\u00e7\u00f5es de pull request costuma produzir resultado muito melhor do que alimentar o modelo apenas com o c\u00f3digo puro.<\/p>\n
git log --pretty=format:\"%s%n%b\" -- src\/servicos\/pagamento.py | head -n 50 > contexto_historico.txt\n<\/code><\/pre>\nEsse hist\u00f3rico, inclu\u00eddo no prompt junto com a extra\u00e7\u00e3o estrutural, d\u00e1 ao modelo pistas sobre o “porqu\u00ea” \u2014 por exemplo, se uma valida\u00e7\u00e3o estranha existe por causa de um bug hist\u00f3rico espec\u00edfico, o commit que a introduziu geralmente carrega essa explica\u00e7\u00e3o.<\/p>\n
Armadilha 3: gerar documenta\u00e7\u00e3o para c\u00f3digo que ainda vai mudar<\/h3>\n
Rodar gera\u00e7\u00e3o de docs em cada commit de uma branch de feature em desenvolvimento ativo \u00e9 desperd\u00edcio de tempo e de tokens \u2014 o c\u00f3digo ainda est\u00e1 inst\u00e1vel. O gatilho certo \u00e9 a mudan\u00e7a de interface p\u00fablica: assinaturas exportadas, endpoints de API, contratos de mensageria. Mudan\u00e7as internas de implementa\u00e7\u00e3o n\u00e3o deveriam disparar regenera\u00e7\u00e3o de documenta\u00e7\u00e3o voltada ao consumidor da API.<\/p>\n
\ud83d\udca1 Dica do Mestre:<\/strong> um bom recorte para inspirar essa separa\u00e7\u00e3o entre “documenta\u00e7\u00e3o de superf\u00edcie p\u00fablica” e “detalhe interno” est\u00e1 discutido no v\u00eddeo Como eu uso IA pra programar em 2026<\/a>, que aborda decis\u00f5es pr\u00e1ticas de onde a IA agrega valor real no ciclo de desenvolvimento e onde ela s\u00f3 gera ru\u00eddo.<\/p><\/blockquote>\n
Um exemplo completo: documentando uma API REST em Node.js<\/h2>\n
Para fechar o racioc\u00ednio com um caso mais pr\u00f3ximo do dia a dia, veja como as tr\u00eas camadas se aplicam a uma rota Express t\u00edpica.<\/p>\n
\/\/ src\/routes\/pedidos.js\nrouter.post(\"\/pedidos\", async (req, res) => {\n const { clienteId, itens, cupomDesconto } = req.body;\n\n if (!clienteId || !itens || itens.length === 0) {\n return res.status(400).json({ erro: \"clienteId e itens s\u00e3o obrigat\u00f3rios\" });\n }\n\n const pedido = await criarPedido({ clienteId, itens, cupomDesconto });\n return res.status(201).json(pedido);\n});\n<\/code><\/pre>\nA camada de extra\u00e7\u00e3o, aqui, pode ser feita com uma an\u00e1lise simples do arquivo de rotas combinada com os testes de integra\u00e7\u00e3o existentes:<\/p>\n
\/\/ scripts\/extrairRota.js\nconst fs = require(\"fs\");\n\nfunction extrairCorpoValidacao(codigoFonte) {\n const regexCampos = \/const\\s*{\\s*([^}]+)\\s*}\\s*=\\s*req\\.body\/;\n const match = codigoFonte.match(regexCampos);\n return match ? match[1].split(\",\").map(s => s.trim()) : [];\n}\n\nconst codigo = fs.readFileSync(\"src\/routes\/pedidos.js\", \"utf-8\");\nconsole.log(extrairCorpoValidacao(codigo));\n\/\/ -> [\"clienteId\", \"itens\", \"cupomDesconto\"]\n<\/code><\/pre>\nCom esses campos extra\u00eddos de forma determin\u00edstica \u2014 n\u00e3o adivinhados pela IA \u2014, o prompt de gera\u00e7\u00e3o recebe uma lista fechada de par\u00e2metros esperados, e a verifica\u00e7\u00e3o posterior confirma que todos aparecem descritos, com o status de obrigatoriedade correto (a valida\u00e7\u00e3o do c\u00f3digo j\u00e1 revela que
clienteId<\/code> eitens<\/code> s\u00e3o obrigat\u00f3rios, enquantocupomDesconto<\/code> \u00e9 opcional). O texto final \u00e9 gerado pela IA, mas os fatos v\u00eam do c\u00f3digo, n\u00e3o da imagina\u00e7\u00e3o do modelo.<\/p>\nQuando vale a pena investir nesse pipeline<\/h2>\n
Nem todo projeto justifica esse n\u00edvel de estrutura. Um script pessoal ou um prot\u00f3tipo de fim de semana n\u00e3o precisa de tr\u00eas camadas com verifica\u00e7\u00e3o automatizada \u2014 um coment\u00e1rio bem escrito resolve. O investimento faz sentido quando existe mais de uma pessoa consumindo a documenta\u00e7\u00e3o, quando a API \u00e9 usada por times ou servi\u00e7os externos, ou quando o custo de uma informa\u00e7\u00e3o errada \u00e9 alto \u2014 integra\u00e7\u00f5es de pagamento, contratos de mensageria entre microsservi\u00e7os, SDKs publicados para terceiros.<\/p>\n
Nesses cen\u00e1rios, o custo de montar o pipeline se paga r\u00e1pido: cada hora investida em automa\u00e7\u00e3o de verifica\u00e7\u00e3o evita horas de debugging causadas por algu\u00e9m confiando em documenta\u00e7\u00e3o desatualizada.<\/p>\n
Leve essa discuss\u00e3o para quem j\u00e1 est\u00e1 aplicando na pr\u00e1tica<\/h2>\n
Pipelines de documenta\u00e7\u00e3o autom\u00e1tica t\u00eam nuances que s\u00f3 aparecem quando voc\u00ea testa em projetos reais \u2014 formatos de prompt que funcionam melhor para APIs REST versus bibliotecas internas, estrat\u00e9gias diferentes para linguagens tipadas versus din\u00e2micas, e como lidar com bases de c\u00f3digo legadas sem testes suficientes para servir de contexto confi\u00e1vel. Essas discuss\u00f5es acontecem todos os dias na Comunidade Dev’s AI<\/a>, onde desenvolvedores compartilham pipelines reais, prompts testados e os erros que cometeram no caminho \u2014 economizando para voc\u00ea o tempo de descobrir tudo sozinho.<\/p>\n
Conclus\u00e3o<\/h2>\n
Documenta\u00e7\u00e3o gerada por IA sem verifica\u00e7\u00e3o \u00e9 apenas uma nova forma de mentir mais r\u00e1pido. O valor real da automa\u00e7\u00e3o n\u00e3o est\u00e1 em substituir o esfor\u00e7o de escrever, mas em substituir o esfor\u00e7o de manter \u2014 e isso s\u00f3 funciona quando existe uma camada de verifica\u00e7\u00e3o separada da camada de gera\u00e7\u00e3o, quando o gatilho \u00e9 a mudan\u00e7a de c\u00f3digo e n\u00e3o uma agenda arbitr\u00e1ria, e quando exemplos de uso s\u00e3o executados, n\u00e3o apenas lidos.<\/p>\n
O objetivo n\u00e3o \u00e9 ter documenta\u00e7\u00e3o bonita. \u00c9 ter documenta\u00e7\u00e3o em que voc\u00ea confiaria o suficiente para tomar uma decis\u00e3o de arquitetura \u00e0s tr\u00eas da tarde de uma sexta-feira, sem precisar abrir o c\u00f3digo-fonte para conferir se aquilo ainda \u00e9 verdade. Construir esse n\u00edvel de confian\u00e7a exige disciplina de engenharia \u2014 a IA acelera a reda\u00e7\u00e3o, mas n\u00e3o substitui o processo que garante que o texto gerado corresponde ao sistema real.<\/p>\n","protected":false},"excerpt":{"rendered":"
Voc\u00ea j\u00e1 abriu um README de um projeto com seis meses de vida e encontrou instru\u00e7\u00f5es para uma vers\u00e3o da API que n\u00e3o existe mais? Ou pior: encontrou um diagrama de arquitetura bonito, feito com capricho num sprint de onboarding, descrevendo um fluxo que foi refatorado tr\u00eas releases atr\u00e1s e ningu\u00e9m atualizou o desenho. A […]<\/p>\n","protected":false},"author":127,"featured_media":1237,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1236","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog"],"_links":{"self":[{"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/posts\/1236","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/users\/127"}],"replies":[{"embeddable":true,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/comments?post=1236"}],"version-history":[{"count":1,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/posts\/1236\/revisions"}],"predecessor-version":[{"id":1238,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/posts\/1236\/revisions\/1238"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/media\/1237"}],"wp:attachment":[{"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/media?parent=1236"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/categories?post=1236"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/adrianosantostreina.com.br\/blog\/wp-json\/wp\/v2\/tags?post=1236"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}