Automatizando o que não deveria exigir esforço: o currículo como exercício de engenharia
Como transformei a atualização de currículo de uma tarefa repetitiva em um sistema automatizado com validação de dados, contratos e pipelines de CI/CD
Also in English
Atualizar currículo nunca foi difícil. Sempre foi apenas chato. Durante muito tempo, esse foi um daqueles processos que eu aceitava como parte natural da vida profissional: abrir um documento, atualizar experiências, ajustar datas, exportar um PDF e seguir em frente. Não exigia esforço intelectual, não trazia aprendizado novo e, ainda assim, precisava ser feito repetidamente. Só depois de alguns anos percebi que isso tinha nome: toil.
O que é Toil?
Toil é trabalho operacional repetitivo, manual, automatizável e sem valor duradouro. É o tipo de tarefa que não escala, não ensina nada novo e tende a crescer linearmente com o sistema. O termo é amplamente usado em SRE (Site Reliability Engineering) para identificar trabalho que deve ser eliminado através de automação.
O problema nunca foi o currículo em si. Não era o formato, o editor ou o layout. O problema era repetir o mesmo processo, sempre da mesma maneira, sem nenhum ganho cognitivo. Esse tipo de trabalho é traiçoeiro porque parece pequeno, quase irrelevante, mas se acumula. Ele ocupa tempo, energia mental e, principalmente, normaliza a ideia de que certas coisas “são assim mesmo”. Toil não vive apenas em ambientes de produção ou em tarefas operacionais; ele se infiltra silenciosamente no nosso dia a dia.
A armadilha da automação superficial
Minha primeira reação foi técnica, como costuma acontecer. Troquei o ODT por Markdown, depois Markdown por AsciiDoc, adicionei scripts, criei templates, automatizei partes do processo. Funcionava melhor do que antes, mas algo ainda estava errado. Eu havia automatizado a ferramenta, não o problema.
Evolução das tentativas
Documento tradicional
ODT/DOCX editado manualmente. Cada atualização exigia abrir o editor, formatar e exportar.
Markdown + Scripts
Migração para texto puro. Melhorou versionamento, mas ainda era duplicação manual para cada idioma.
AsciiDoc + Templates
Mais poder de formatação, mas o problema fundamental persistia: dados e apresentação misturados.
Dados estruturados + Schema
O currículo deixa de ser documento e vira dados validados. Templates são apenas renderizadores.
Cuidado com a automação superficial
Trocar de tecnologia sem mudar o modelo mental é uma armadilha comum quando falamos de automação. Você pode ter o pipeline mais sofisticado do mundo, mas se o problema fundamental não foi endereçado, você apenas automatizou a ineficiência.
O ponto de virada: dados, não documentos
O ponto de virada aconteceu quando deixei de tratar o currículo como um documento e passei a tratá-lo como dados. Ao adotar uma especificação formal de currículo, baseada em um schema, ficou claro que a informação precisava ter um contrato. A partir do momento em que os dados passaram a ser validados, versionados e estruturados, o formato final deixou de importar. HTML, PDF ou qualquer outra saída passaram a ser apenas representações diferentes do mesmo conjunto de informações.
- 1
Separação de dados e apresentação
Informações do currículo vivem em arquivos de dados estruturados, seguindo um schema definido. Templates apenas transformam esses dados em formatos legíveis.
Dados comuns vs. específicos
Nome, e-mail, links e experiências compartilhadas existem em um único lugar. Dados específicos de cada idioma (descrições, resumos) ficam isolados em arquivos separados.
Merge e validação automática
Um processo simples combina dados comuns com dados específicos do idioma, validando contra o schema antes de qualquer renderização.
Múltiplas saídas, mesma fonte
HTML, PDF completo, PDF de uma página — todos gerados automaticamente a partir da mesma fonte de verdade.
Essa mudança de perspectiva resolveu problemas que antes pareciam “naturais”. Ter versões em português e inglês deixou de significar duplicação de conteúdo.
Arquitetura do sistema
O diagrama abaixo mostra o fluxo de dados desde os arquivos YAML até os artefatos finais — três formatos de saída para cada idioma, todos gerados a partir da mesma fonte de verdade:
O fluxo é direto:
- Dados YAML são a fonte de verdade —
common.yamlcontém dados compartilhados (nome, contatos, experiências), enquanto arquivos por idioma (resume.en.yaml,resume.ptbr.yaml) contêm apenas traduções - Validação contra o JSON Resume Schema garante que os dados estão corretos antes de qualquer processamento
- Typst mescla os dados e aplica os templates, gerando 3 formatos para cada idioma: PDF completo, PDF de uma página, e HTML
O currículo como aplicação
Em algum momento desse processo, o currículo deixou de ser um arquivo e virou uma aplicação. Hoje, ele passa por um pipeline de build como qualquer outro projeto: os dados são validados, os artefatos são gerados e tudo é publicado automaticamente. O resultado é sempre previsível e reproduzível.
O site em HTML e os PDFs — tanto a versão completa quanto a versão condensada em uma única página — são gerados a partir da mesma fonte de verdade. Se algo quebra, o pipeline acusa. Se algo muda, a atualização é trivial.
Pipeline como documentação viva
Quando o processo de build está codificado em um pipeline, ele serve como documentação executável. Qualquer pessoa pode entender como o sistema funciona simplesmente lendo os workflows — e pode confiar que essa documentação está sempre atualizada, porque ela é o processo.
Overengineering ou investimento?
É fácil olhar para esse processo e chamá-lo de overengineering. E, de certa forma, talvez seja mesmo. Mas essa crítica ignora o ponto central.
O objetivo nunca foi o currículo. Ele foi apenas um meio. Um terreno controlado para experimentar automação, contratos de dados, validação e publicação contínua sem risco real. Tudo o que foi aprendido ali se transfere diretamente para problemas muito maiores e mais críticos.
Schemas não são burocracia — são garantias. Quando dados passam por validação antes de serem usados, erros são detectados na origem, não na produção.
Dados, lógica de transformação e apresentação são camadas distintas. Mudar uma não deveria exigir mudanças nas outras.
Se algo pode ser automatizado e não agrega valor humano na execução manual, automatize. O tempo recuperado é real.
Projetos pessoais são laboratórios perfeitos para testar ideias antes de aplicá-las em contextos de maior risco.
A lição real
No fim das contas, a lição não tem nada a ver com carreira, documentos ou tecnologia específica. Ela é sobre aprender a identificar processos morosos, previsíveis e repetitivos e decidir conscientemente não aceitá-los como inevitáveis.
Sempre que uma tarefa deixa de ensinar algo novo, ela se torna candidata à automação.
Não para mostrar sofisticação técnica, mas para devolver tempo e energia para aquilo que realmente importa.
O princípio fundamental
Automação, no fundo, não é sobre ferramentas modernas ou stacks elegantes. É sobre respeito ao próprio tempo. Se algo não exige mais pensamento, talvez seja exatamente o tipo de coisa que você não deveria fazer manualmente nunca mais.
Apêndice: implementação prática
Como complemento prático a tudo isso, vale mostrar como essa ideia se materializa. Todo o resultado descrito acima está publicado e pode ser inspecionado tanto do ponto de vista de uso quanto de implementação.
Versões publicadas
As versões em HTML do currículo são o ponto de entrada mais visível. Elas são geradas automaticamente a partir da mesma base de dados e publicadas como site estático:
Além do HTML, o mesmo pipeline gera PDFs. Para cada idioma, existem duas variações: uma versão completa e uma versão condensada em uma única página:
PDFs em Inglês
PDFs em Português
Código-fonte
Toda a implementação que viabiliza esse processo está em um repositório público:
fabioluciano/resume.fabioluciano.com
Código-fonte completo: dados, templates, validação e pipeline de CI/CD
github.com
A estrutura do repositório separa claramente as responsabilidades:
Os templates não conhecem idioma, versão ou contexto; eles apenas recebem dados válidos e sabem como transformá-los em HTML ou PDF. Essa separação clara entre dados e apresentação é o que torna o sistema extensível e sustentável ao longo do tempo.
Por fim, todo o processo de validação, geração e publicação acontece de forma automatizada via workflows. O pipeline garante que os dados estejam em conformidade com o schema antes de qualquer artefato ser publicado. Se algo estiver inconsistente, o build falha. Se algo mudar, tudo é regenerado de forma previsível.
O valor não está no currículo em si, mas no processo. O currículo é apenas a evidência concreta de uma ideia mais ampla — identificar toil, criar contratos claros e automatizar aquilo que não deveria exigir esforço humano repetidamente.