S\u00e3o nove da manh\u00e3 de segunda-feira. Antes de escrever a primeira linha de c\u00f3digo \u00fatil do dia, voc\u00ea j\u00e1 renomeou doze arquivos de log seguindo um padr\u00e3o que ningu\u00e9m documentou, copiou a vers\u00e3o de um pacote de um projeto para outro \u00e0 m\u00e3o, rodou tr\u00eas comandos de build em sequ\u00eancia porque o pipeline ainda n\u00e3o cobre esse cen\u00e1rio, e revisou um changelog gerado por outra pessoa para corrigir a formata\u00e7\u00e3o. Nada disso est\u00e1 no seu cargo. Nada disso exige a sua experi\u00eancia. E, ainda assim, consome a parte do seu dia em que sua cabe\u00e7a est\u00e1 mais alerta \u2014 porque \u00e9 logo cedo, antes das reuni\u00f5es, antes dos interrompimentos.<\/p>\n
O problema n\u00e3o \u00e9 a automa\u00e7\u00e3o em si \u2014 a maioria dos times j\u00e1 automatiza o \u00f3bvio: build, deploy, testes de CI. O problema \u00e9 a categoria intermedi\u00e1ria de tarefas: pequenas demais para justificar um projeto de automa\u00e7\u00e3o formal, grandes demais para continuarem manuais para sempre. \u00c9 exatamente nesse espa\u00e7o que a IA generativa, usada com crit\u00e9rio, muda o c\u00e1lculo de custo-benef\u00edcio. Segundo um levantamento sobre o ciclo de vida de desenvolvimento de software com assist\u00eancia de IA<\/a>, o maior impacto da IA generativa est\u00e1 concentrado justamente nas fases de implementa\u00e7\u00e3o, teste e documenta\u00e7\u00e3o \u2014 exatamente onde moram essas tarefas de fric\u00e7\u00e3o baixa e volume alto.<\/p>\n Neste artigo vou tratar a automa\u00e7\u00e3o com IA n\u00e3o como m\u00e1gica, mas como engenharia: como mapear o que vale a pena automatizar, como estruturar esses scripts para que n\u00e3o virem uma nova fonte de d\u00edvida t\u00e9cnica, e como usar agentes de IA para gerar e manter essas automa\u00e7\u00f5es sem perder o controle sobre o que elas fazem.<\/p>\n A tenta\u00e7\u00e3o, ao descobrir que um agente de IA consegue escrever um script em segundos, \u00e9 sair automatizando tudo que incomoda. O resultado costuma ser uma pasta cheia de scripts soltos, sem padr\u00e3o, sem testes, sem dono \u2014 que depois de seis meses ningu\u00e9m sabe se ainda funciona ou se j\u00e1 quebrou silenciosamente.<\/p>\n Antes de qualquer linha de c\u00f3digo, vale aplicar um filtro simples. Uma tarefa repetitiva s\u00f3 merece automa\u00e7\u00e3o s\u00e9ria se atender a pelo menos dois destes tr\u00eas crit\u00e9rios:<\/p>\n \ud83d\udca1 Dica do Mestre:<\/strong> segundo um artigo da IBM sobre experi\u00eancia do desenvolvedor<\/a>, o valor real da IA generativa n\u00e3o est\u00e1 apenas em acelerar fluxos de trabalho automatizando tarefas repetitivas, mas em ampliar a capacidade humana de focar no que exige julgamento. Isso significa que automa\u00e7\u00e3o mal escolhida \u2014 que tira do dev justamente as decis\u00f5es que exigem contexto \u2014 \u00e9 t\u00e3o prejudicial quanto n\u00e3o automatizar nada.<\/p><\/blockquote>\n Uma pr\u00e1tica que funciona bem em times reais \u00e9 manter, por uma semana, um registro simples das interrup\u00e7\u00f5es repetitivas. N\u00e3o precisa de ferramenta sofisticada \u2014 um arquivo de texto ou uma issue no board j\u00e1 resolve:<\/p>\n No fim da semana, esse registro vira o seu backlog de automa\u00e7\u00e3o. E aqui entra a diferen\u00e7a pr\u00e1tica entre “ter IA dispon\u00edvel” e “usar IA com crit\u00e9rio”: voc\u00ea n\u00e3o pede para o agente automatizar tudo de uma vez \u2014 voc\u00ea prioriza pelo filtro acima e ataca um item por vez, validando cada automa\u00e7\u00e3o antes de passar para a pr\u00f3xima.<\/p>\n A IA generativa \u00e9 particularmente boa em gerar o primeiro rascunho de um script. O risco est\u00e1 em parar por a\u00ed. Um script gerado por IA em trinta segundos e colocado em produ\u00e7\u00e3o sem revis\u00e3o \u00e9 um risco disfar\u00e7ado de ganho de produtividade. O fluxo que funciona na pr\u00e1tica tem quatro etapas: especificar, gerar, validar, versionar.<\/p>\n Em vez de pedir “crie um script para renomear logs”, escreva a especifica\u00e7\u00e3o como se fosse delegar para um estagi\u00e1rio s\u00eanior que nunca viu o projeto:<\/p>\n Note que a especifica\u00e7\u00e3o j\u00e1 embute duas decis\u00f5es de engenharia importantes: idempot\u00eancia e modo dry-run. Essas n\u00e3o s\u00e3o “extras” \u2014 s\u00e3o o que separa um script de automa\u00e7\u00e3o confi\u00e1vel de uma bomba-rel\u00f3gio.<\/p>\n Com a especifica\u00e7\u00e3o pronta, o papel do agente de IA (seja via Claude Code, Cursor ou outro assistente integrado ao editor) \u00e9 gerar a implementa\u00e7\u00e3o. O seu papel passa a ser o de revisor, n\u00e3o de digitador:<\/p>\n Os pontos de aten\u00e7\u00e3o que voc\u00ea deve checar nessa revis\u00e3o \u2014 exatamente os que um revisor humano confere em qualquer PR \u2014 s\u00e3o: o script falha de forma segura se a pasta n\u00e3o existir? Ele sobrescreve arquivos de destino que j\u00e1 existam? O log de execu\u00e7\u00e3o \u00e9 suficiente para auditoria depois? Nenhum desses pontos \u00e9 coberto automaticamente s\u00f3 porque a IA gerou o c\u00f3digo.<\/p>\n Testar manualmente um script de automa\u00e7\u00e3o, rodando-o algumas vezes e olhando a sa\u00edda, \u00e9 a forma mais lenta e menos confi\u00e1vel de valida\u00e7\u00e3o. O ganho real aparece quando voc\u00ea escreve um teste automatizado mesmo para scripts pequenos:<\/p>\n Esse teste custa poucos minutos a mais e garante que, quando voc\u00ea (ou a IA, em uma sess\u00e3o futura) alterar o script, uma regress\u00e3o silenciosa n\u00e3o passe despercebida. Scripts de automa\u00e7\u00e3o sem teste s\u00e3o o tipo de d\u00edvida t\u00e9cnica que s\u00f3 aparece quando j\u00e1 causou dano.<\/p>\n Scripts de automa\u00e7\u00e3o gerados por IA tendem a ficar espalhados em pastas tempor\u00e1rias, fora do controle de vers\u00e3o, sem revis\u00e3o de ningu\u00e9m al\u00e9m de quem os escreveu. Trate-os como qualquer outro m\u00f3dulo do reposit\u00f3rio: pasta pr\u00f3pria, README curto explicando o prop\u00f3sito, e um PR normal para merge \u2014 mesmo que o PR tenha sido aberto por voc\u00ea sozinho.<\/p>\n At\u00e9 aqui, tratamos de tarefas pontuais que viram scripts isolados. Mas existe uma segunda camada: tarefas que n\u00e3o s\u00e3o um script \u00fanico, mas um fluxo de decis\u00f5es \u2014 por exemplo, revisar se um PR s\u00f3 cont\u00e9m mudan\u00e7as de formata\u00e7\u00e3o antes de aprovar automaticamente, ou gerar um resumo de changelog a partir de commits, cruzando com as issues referenciadas.<\/p>\n Essa categoria se beneficia de agentes de IA configurados com acesso a ferramentas espec\u00edficas, n\u00e3o apenas de scripts determin\u00edsticos. Um exemplo pr\u00e1tico: um agente que l\u00ea o diff de um PR, classifica se a mudan\u00e7a \u00e9 puramente cosm\u00e9tica (formata\u00e7\u00e3o, imports, espa\u00e7amento) e, nesse caso, adiciona um coment\u00e1rio autom\u00e1tico sugerindo aprova\u00e7\u00e3o r\u00e1pida \u2014 mas nunca aprova sozinho.<\/p>\n Note o detalhe de arquitetura: o agente classifica e sugere, mas a aprova\u00e7\u00e3o continua sendo uma a\u00e7\u00e3o humana. Essa \u00e9 a linha divis\u00f3ria entre automa\u00e7\u00e3o respons\u00e1vel e automa\u00e7\u00e3o que delega decis\u00f5es demais para um sistema probabil\u00edstico. Um relat\u00f3rio sobre casos reais de agentes de IA em empresas<\/a> refor\u00e7a esse padr\u00e3o: o ganho de produtividade mais consistente vem de agentes que liberam o colaborador humano de tarefas repetitivas e demoradas, n\u00e3o de agentes que substituem o julgamento final sobre decis\u00f5es relevantes.<\/p>\n Vale nomear as armadilhas mais comuns antes que voc\u00ea as encontre em produ\u00e7\u00e3o:<\/p>\n Esses pontos n\u00e3o s\u00e3o exclusivos de automa\u00e7\u00e3o feita com IA \u2014 s\u00e3o princ\u00edpios de engenharia de automa\u00e7\u00e3o que j\u00e1 existiam antes. A diferen\u00e7a \u00e9 que, como a IA reduz o custo de gerar o primeiro rascunho, fica mais f\u00e1cil pular direto para a execu\u00e7\u00e3o sem passar por essas etapas de disciplina. Segundo uma an\u00e1lise sobre o impacto da IA no desenvolvimento de software<\/a>, o objetivo de ferramentas de IA e low-code \u00e9 agilizar o processo automatizando tarefas repetitivas \u2014 n\u00e3o eliminar as pr\u00e1ticas de engenharia que garantem que essa automa\u00e7\u00e3o seja confi\u00e1vel.<\/p>\n Um padr\u00e3o que vale adotar, \u00e0 medida que o n\u00famero de scripts cresce, \u00e9 manter um cat\u00e1logo simples \u2014 um arquivo Esse cat\u00e1logo resolve um problema invis\u00edvel: automa\u00e7\u00f5es esquecidas s\u00e3o t\u00e3o arriscadas quanto c\u00f3digo morto, com a diferen\u00e7a de que elas continuam rodando. Revis\u00e1-las periodicamente \u2014 perguntando se ainda s\u00e3o necess\u00e1rias, se o padr\u00e3o que elas tratam ainda existe \u2014 evita que a pasta de scripts vire um cemit\u00e9rio de decis\u00f5es antigas.<\/p>\nO erro mais comum: automatizar antes de medir<\/h2>\n
\n
Fazendo o invent\u00e1rio antes do script<\/h3>\n
## Registro de tarefas repetitivas - semana 03\n\n- [seg] Renomear arquivos de log do ambiente de staging (5x)\n- [seg] Atualizar vers\u00e3o de depend\u00eancia em 3 reposit\u00f3rios (1x, mas 20min cada)\n- [ter] Gerar changelog a partir dos commits da sprint (1x)\n- [qua] Rodar checklist de smoke test manual antes do deploy (1x)\n- [qui] Converter JSON de configura\u00e7\u00e3o entre dois formatos (3x)\n- [sex] Revisar PRs que s\u00f3 mudam formata\u00e7\u00e3o (4x)\n<\/code><\/pre>\nDo script ad-hoc ao pipeline confi\u00e1vel<\/h2>\n
1. Especificar a tarefa como se fosse para outra pessoa<\/h3>\n
Preciso de um script Python que:\n1. Percorra a pasta .\/logs\/staging\n2. Renomeie arquivos no padr\u00e3o \"app_YYYYMMDD.log\" para\n \"staging-app-YYYY-MM-DD.log\"\n3. Ignore arquivos que j\u00e1 estejam no novo padr\u00e3o (idempotente)\n4. Rode em modo --dry-run por padr\u00e3o, mostrando o que seria\n renomeado sem executar\n5. S\u00f3 execute de verdade com a flag --apply\n6. Registre um log de execu\u00e7\u00e3o em .\/logs\/rename-history.log\n<\/code><\/pre>\n2. Gerar com o agente e revisar como revis\u00e3o de PR<\/h3>\n
import re\nimport shutil\nimport argparse\nfrom pathlib import Path\nfrom datetime import datetime\n\nPADRAO_ANTIGO = re.compile(r\"app_(\\d{4})(\\d{2})(\\d{2})\\.log\")\n\ndef mapear_renomeacoes(pasta: Path):\n renomeacoes = []\n for arquivo in pasta.glob(\"app_*.log\"):\n m = PADRAO_ANTIGO.match(arquivo.name)\n if not m:\n continue\n ano, mes, dia = m.groups()\n novo_nome = f\"staging-app-{ano}-{mes}-{dia}.log\"\n renomeacoes.append((arquivo, pasta \/ novo_nome))\n return renomeacoes\n\ndef executar(renomeacoes, aplicar: bool, log_path: Path):\n with open(log_path, \"a\", encoding=\"utf-8\") as log:\n for origem, destino in renomeacoes:\n linha = f\"{datetime.now().isoformat()} {origem.name} -> {destino.name}\"\n print(linha)\n log.write(linha + \"\\n\")\n if aplicar:\n shutil.move(str(origem), str(destino))\n\nif __name__ == \"__main__\":\n parser = argparse.ArgumentParser()\n parser.add_argument(\"--apply\", action=\"store_true\")\n parser.add_argument(\"--pasta\", default=\".\/logs\/staging\")\n args = parser.parse_args()\n\n pasta = Path(args.pasta)\n renomeacoes = mapear_renomeacoes(pasta)\n\n if not renomeacoes:\n print(\"Nenhum arquivo para renomear.\")\n else:\n executar(renomeacoes, aplicar=args.apply,\n log_path=pasta \/ \"rename-history.log\")\n<\/code><\/pre>\n3. Validar com um teste m\u00ednimo, n\u00e3o com execu\u00e7\u00e3o manual repetida<\/h3>\n
import tempfile\nfrom pathlib import Path\nfrom rename_logs import mapear_renomeacoes\n\ndef test_mapeia_arquivos_no_padrao_antigo():\n with tempfile.TemporaryDirectory() as tmp:\n pasta = Path(tmp)\n (pasta \/ \"app_20260115.log\").touch()\n (pasta \/ \"staging-app-2025-12-01.log\").touch() # j\u00e1 migrado\n\n resultado = mapear_renomeacoes(pasta)\n\n assert len(resultado) == 1\n origem, destino = resultado[0]\n assert destino.name == \"staging-app-2026-01-15.log\"\n<\/code><\/pre>\n4. Versionar como c\u00f3digo de verdade<\/h3>\n
\/scripts\n \/rename-logs\n rename_logs.py\n test_rename_logs.py\n README.md\n \/sync-dependencies\n sync_deps.py\n test_sync_deps.py\n README.md\n<\/code><\/pre>\nAgentes para automa\u00e7\u00e3o recorrente: indo al\u00e9m do script \u00fanico<\/h2>\n
def classificar_pr(diff: str, cliente_ia) -> dict:\n prompt = f\"\"\"\n Analise o diff abaixo e responda em JSON com os campos:\n - \"tipo\": \"cosmetico\" ou \"funcional\"\n - \"justificativa\": uma frase curta explicando a classifica\u00e7\u00e3o\n\n Regras:\n - \"cosmetico\" significa SOMENTE mudan\u00e7as de formata\u00e7\u00e3o,\n espa\u00e7amento, ordena\u00e7\u00e3o de imports ou coment\u00e1rios.\n - Qualquer altera\u00e7\u00e3o de l\u00f3gica, nome de fun\u00e7\u00e3o, assinatura\n ou comportamento deve ser classificada como \"funcional\".\n\n Diff:\n {diff}\n \"\"\"\n resposta = cliente_ia.gerar(prompt, formato_json=True)\n return resposta\n<\/code><\/pre>\nOnde isso costuma dar errado<\/h2>\n
\n
--dry-run<\/code>, tendem a causar o primeiro incidente real de automa\u00e7\u00e3o \u2014 geralmente um arquivo apagado ou um dado sobrescrito que ningu\u00e9m pediu.<\/li>\nConstruindo um cat\u00e1logo pessoal de automa\u00e7\u00f5es<\/h2>\n
README.md<\/code> na raiz da pasta \/scripts<\/code> listando cada automa\u00e7\u00e3o, quando foi criada, qual problema resolve e quando foi revisada pela \u00faltima vez:<\/p>\n# Cat\u00e1logo de automa\u00e7\u00f5es\n\n| Nome | Problema que resolve | \u00daltima revis\u00e3o |\n|-------------------|------------------------------------|----------------|\n| rename-logs | Padroniza nomes de log de staging | 2026-01 |\n| sync-dependencies | Sincroniza vers\u00e3o entre 3 repos | 2025-11 |\n| pr-classifier | Classifica PRs cosm\u00e9ticos vs func. | 2026-02 |\n<\/code><\/pre>\nLeve essa discuss\u00e3o para quem j\u00e1 est\u00e1 testando na pr\u00e1tica<\/h2>\n