A pior parte da avaliação anual não é a avaliação. É tentar lembrar tudo que você fez.

No ano passado, durante minha avaliação anual de performance, percebi que tinha um problema.

Eu queria sustentar tudo o que tinha conquistado com dados concretos, números reais, impacto de verdade, mas eu não tinha mantido nenhum tipo de registro ao longo do ano.

Então passei dias revisando pull requests um por um, procurando tickets, conversando com colegas para reconstruir o que eu tinha desenvolvido e qual diferença aquilo gerou, tudo isso em paralelo com minha carga de trabalho normal da época. Foi exaustivo, e a pior parte era saber que o retrato que eu estava montando ainda estava incompleto.

Memória é falha, contexto se perde, e quanto mais distante você está do trabalho, mais difícil fica explicar por que aquilo importou.

Prometi para mim mesmo que faria diferente este ano. Aí abril chegou e eu não tinha anotado absolutamente nada.

A diferença desta vez é que eu já sabia o que estava procurando. Eu tinha descoberto o conceito de “brag docs”, que basicamente é um registro contínuo das suas conquistas, contribuições e impacto no trabalho. Features entregues, projetos bem-sucedidos, feedbacks positivos, melhorias de métricas, momentos de liderança, tudo centralizado em um único lugar para que, quando chegar a época das avaliações, você não precise reconstruir o ano inteiro pela memória. O formato fez sentido imediatamente para mim, mas eu queria algo que funcionasse sem exigir que eu alimentasse manualmente toda semana.

Já que eu teria que fazer tudo retroativamente de qualquer forma, decidi construir algo que resolvesse isso para mim em vez de continuar lutando contra o problema.

Criei um agente CLI em Python que se integra com a API do Bitbucket e usa Claude por baixo dos panos para gerar os documentos. O fluxo funciona em duas etapas. Primeiro, existe uma camada de coleta de dados que autentica via Bitbucket App Password com permissões apenas de leitura, passa por todos os pull requests mergeados em que eu fui autora ou reviewer dentro de um intervalo de datas específico e salva esses dados brutos localmente organizados por mês. Para PRs com descrições muito curtas ou inexistentes, o agente faz uma requisição adicional para buscar o diff real e usa isso como contexto, porque título e descrição nem sempre carregam informação suficiente para reconstruir o raciocínio e o impacto por trás de uma mudança. Depois, na segunda etapa, esses dados estruturados são enviados para o Claude com um prompt adaptado ao meu nível de senioridade e área de atuação, e o modelo gera um brag doc completo por mês além de um resumo consolidado do ano até o momento.

O resultado foi que, em poucos minutos, eu tinha tudo aquilo que vinha adiando desde janeiro: organizado, legível e baseado no trabalho real. Não em percepção, não em memória, mas em pull requests, diffs, atividade de review, tudo transformado em narrativa com substância técnica. O próximo passo agora é adicionar um fluxo para alimentar discussões de arquitetura e decisões técnicas na mesma pipeline, porque impacto além do código também merece ser documentado.