DEV Community: He4rt Developers

Claude e Obsidian - Como uma QA utiliza essas ferramentas no dia-a-dia

Alicia Marianne Gonçalves — Mon, 28 Sep 2026 23:03:40 +0000

🇺🇸 You can also read the English version of this article on AWS Community Builders.

Ser QA nessa era de IA tem sido bem desafiador, principalmente quando a velocidade de entrega é maior, fica o grande questionamento: Como eu vou conseguir garantir que não me esqueci de nada? Será que estou cobrindo os cenários que realmente precisam ser cobertos? Ter uma boa organização é essencial pra todas áreas da vida, e dentro da área de QA não seria diferente, por isso atualmente o Obsidian tem sido uma ferramenta bem presente no meu dia-a-dia, e vim falar pra vocês como eu tenho utilizado ela.

Por que o Obsidian?

Basicamente, o Obsidian é um aplicativo de anotações e gestão de conhecimento que funciona com arquivos Markdown(.md) que são guardados localmente no seu computador, tendo a possibilidade de te-los na nuvem utilizando a versão paga ou algum plugin da comunidade.

E diversos fatores me fizeram migrar para essa ferramenta. Antes, eu utilizava o Notion que apesar de ser uma boa ferramenta, pra mim, ser tão personalizável visualmente me fazia perder mais tempo criando templates do que realmente adicionando conteúdo a eles.

O fato do Obsidian ser uma ferramenta bem mais "clean" e focada em notas, faz com que menos coisas me tirem do foco. Outro fator é que minhas notas ficam registradas localmente. No ambiente de trabalho a segurança de dados é essencial, então a certeza de que minhas anotações estão seguras me deixa mais tranquila em relação a outras ferramentas. Dentro do obsidian também é possível adicionar plugins externos que possam te auxiliar na produtividade e sem deixar a tela tão poluída, o que é um grande diferencial para mim.

E por ultimo, e mais importante: como tenho utilizado bastante IA em determinadas tarefas, a produção de conteúdos em Markdown já facilita a integração com elas, basicamente o meu Obsidian se tornou meu segundo cérebro.

Uso e integração com IA

Antes de ir para como tudo se integra, primeiro preciso passar um breve contexto dos recursos que tenho utilizado, que são:

Os Templates
As Skills
E os Plugins do Obsidian

Templates

A primeira coisa que fiz quando comecei a utilizar o Obsidian, foi a criação de templates para os documentos que normalmente preciso.

Templates são notas que você pode criar, com um padrão específico e sempre que criar uma nota, você pode reutilizar esse template.

Como QA, por enquanto tenho os seguintes templates:

Template tasks técnicas: é um arquivo de template que sempre que preciso gerar planos de teste para tarefas técnicas(migração de banco de dados, criação de consumers, APIs) esse template será usado de referência.
Template de tasks de business: segue a mesma lógica do arquivo de template da tasks técnicas, mas o utilizo uma etapa anterior, quando estou dentro do product discovery juntamente com o Product Owner, para definir quais camadas de testes podem ser adicionados para aquela nova funcionalidade, riscos e mitigação dos mesmos, como medir o sucesso daquela nova funcionalidade.
Template para notas de reuniões: Nesse template tenho os dados principais sobre uma reunião e eu uso ele para tomar notas ou criar roteiros de reuniões que irei estar a frente.

Skills

A gente sabe que as skills é um recurso muito bom para reduzirmos o tempo em tarefas repetitivas, e manter um padrão enquanto utilizamos a IA, dentro do meu contexto criei algumas skills, sendo elas:

Criação de plano de testes: Essa é uma skill que sempre que chamo ela passando o ID de uma tarefa do Jira, ela irá buscar o contexto daquela tarefa, em seguida, vai procurar conteúdos de referencia dentro do confluence(eu especifiquei dentro do meu CLAUDE.md), e após essa contextualização, ela irá criar um arquivo .md de plano de teste, utilizando os templates que eu criei anteriormente.
Busca de tarefas que não possuem planos de teste: É uma skill simples integrada ao MCP da Atlassian, que irá buscar todas as tarefas que possuo com uma flag específica para criação de plano de testes, e irá adicionar a um arquivo .md que utilizo com o plugin Kanban, para controle do que eu preciso fazer, já fiz.
Publicar casos de teste do Zephyr: Essa é uma skill de integração para pegar os testes planejados e publica-los no Zephyr, que é a ferramenta que utilizo para gestão de testes.

Plugins

Já comecei a citar um plugin que utilizo, que é o Kanban para a gestão das tarefas, mas recentemente vi a necessidade de dois novos plugins:

Um plugin que se integre diretamente ao Claude Code, sem a necessidade de sair do Obsidian
Um plugin para ter fácil acesso as minhas skills.

Como não os encontrei na loja, decidi criar os dois.

O primeiro é um plugin que abre o terminal dentro do vault(pasta) que estou trabalhando, assim fica fácil utilizar o Claude Code dentro do próprio Obsidian:

O segundo, foi um plugin simples para exibir e executar minhas skills, onde consigo ver todas as skills disponíveis e executa-las diretamente do Obsidian.

Como tudo se integra

Agora já sabemos tudo que eu uso de Templates, Skills e Plugins vou dar um exemplo de como isso funciona na vida real.

Suponha que tenha uma tarefa AB-123, que é um épico ou product discovery vindo de produto, o fluxo para o plano de teste para essa tarefa seria:

Em tasks técnicas, o processo seria similar:

Notas finais

Confesso que tem sido divertido me aventurar em formas de organização para melhor desempenho utilizando ferramentas de IA. Ainda existe o desafio de revisar o conteúdo gerado por ela, para isso sempre tento coletar feedback do time em relação aos testes gerados, massa de dados fornecidas, validando se está claro ou algo não foi coberto.

Também utilizo a mesma lógica para os Templates. Sempre estou atualizando meus templates, baseado nas revisões que vou fazendo, sempre adiciono um contexto a mais, ou retiro um contexto que não faz sentido para o que preciso.

Sobre os plugins, tenho me aventurado em alguns da comunidade, e também me diverti bastante fazendo um novo. Ainda não estão em uma versão final e nem na loja da comunidade, mas caso você queira se aventurar, dentro do repositório tem o passo-a-passo de como utiliza-los localmente, o link está no final deste artigo.

Enfim, espero que esse artigo seja uma inspiração para você integrar mais coisas ao seu Obsidian ou até mesmo rever seus pensamentos sobre o mesmo.

Como uma gestão despreparada pode custar a sua carreira

Evelyn Lacerda — Fri, 25 Sep 2026 19:00:15 +0000

Quantas vezes você já ouviu a seguinte frase "a empresa é assim, lide com isso" e engoliu seco porque parecia a única opção? Essa frase costuma ser tratada como "algo comum", como "personalidade de gestor". Raramente mencionam o termo correto que é despreparo para gerir pessoas.

A história abaixo não é sobre uma grande empresa com RH ineficiente, ou uma startup sem controle. A empresa era pequena, que seguiu pequena, onde o gestor era o dono e não havia ninguém acima dele para trazer à tona um despreparo que era evidente.

Os fatos descritos aqui aconteceram com uma pessoa próxima, que chamarei de Maria, e que autorizou o uso da sua história na carreira tech.

O início do conflito: Quando a pressa substitui o planejamento

O projeto era grande: refazer um SaaS inteiro, com frontend e backend construídos do zero. Quando ela entrou na equipe, o backend já estava encaminhado, faltava o frontend. A decisão do gestor foi comprar um template pronto e construir tudo em cima dele. Parece prático, mas não é: um template genérico, feito para qualquer tipo de aplicação, carrega dependências e estruturas depreciadas que nada têm a ver com o projeto proposto, e boa parte do tempo da equipe acaba consumida limpando código desnecessário e torcendo para tudo continuar funcionando.

Maria ficou de analisar o primeiro template. Percebeu que a quantidade de dependências depreciadas e bugs atrasaria o projeto, e sugeriu construir o frontend do zero. A sugestão foi aceita, e ela passou os 7 meses seguintes construindo sozinha uma base sólida, eficiente e confiável.

Com a entrada de um novo desenvolvedor sênior na equipe, o que Maria esperava ser uma colaboração alimentada pela experiência do colega, se transformou em mais 14 meses de trabalho em cima de uma nova compra de template. Imposto sem debate técnico prévio, e que resultaram no descarte de todo o trabalho prévio de Maria com desenvolvimento de uma base correta.

A decisão não foi tomada com base em qual abordagem era tecnicamente melhor, foi tomada com base em quem falou por último e com mais anos de experiência no currículo. Isso não é um erro técnico, é um erro de processo. Quando a palavra de quem tem mais cargo ou mais tempo de casa pesa mais do que meses de entrega comprovada, a equipe aprende que propor, testar e validar não importa tanto quanto convencer quem decide.

É esse tipo de ambiente que ensina gente boa a parar de sugerir.

O risco real apareceu 4 meses antes da nova e última data de lançamento, já sem margem para mais adiamentos. Uma das tecnologias base do template sofreu uma atualização de versão, o gestor pediu a atualização no projeto, e o template simplesmente parou de funcionar. Nem o sênior conseguiu resolver os erros de incompatibilidade gerados. Reverter para a versão anterior lançaria o projeto já obsoleto, então tudo foi refeito pela terceira vez, em um terceiro template diferente que também trazia depreciações e erros na base.

Um projeto com prazo de lançamento de menos de 1 ano chegou a 2 anos sem estimativa de conclusão.

Em nenhum momento houve uma avaliação real do risco de construir a base inteira de um SaaS em cima de templates prontos e genéricos. Comprar pronto parece economizar tempo, mas só empurra o custo para frente, e quando ele chega, vem maior. É gestão de projeto amadora tratar prazo e tecnologia como decisões independentes uma da outra, e quem paga por essa desconexão não é quem decide, é quem está na ponta reescrevendo o mesmo projeto pela terceira vez.

Duas vozes que não se alinhavam e o trabalho que não chegava a lugar nenhum

A comunicação interna era um ponto extremo a se questionar, principalmente entre gestor e sênior, raramente consistentes entre si. Quando Maria buscava resolver alguma dúvida, um dizia uma coisa, o outro dizia o oposto. Ela virou o ponto de contato involuntário entre os dois, tentando alinhar o que já deveria estar alinhado antes de chegar até ela. Levou as divergências para um canal aberto a todos, mas raramente isso resolvia algo.

Havia também um desgaste diário nas trocas de direção sem comunicação: PRs ficavam semanas ou meses sem revisão, acumulando conflitos impossíveis de resolver e obrigando Maria a refazer a mesma PR 5, 6, 7 vezes. Via seu trabalho parado, sem avançar nem retroceder, enquanto cobranças chegavam como se ela não estivesse entregando: "você não está entregando o suficiente" ou "há muitas PRs suas paradas", as mesmas PRs que esperavam validação de quem simplesmente deixava pra mais tarde.

Em paralelo, seu trabalho podia ser jogado fora a qualquer momento, sem aviso.

Repare o tamanho da inversão aqui, quando duas pessoas em posições diferentes de decisão que não se alinham entre si. O custo desse desalinhamento não fica apenas com elas, ele chega até quem tem menos poder de recusa para um papel de intermediário. Cobrar entrega de quem está travado esperando revisão não podemos chamar de gestão de performance, isso é confundir sintoma e causa sem observar quem controla o gargalo.

Um ambiente que normalizava o desconforto

Além dessa instabilidade técnica que ela enfrentava no dia a dia, havia um padrão constante nas reuniões: piadas constrangedoras, algumas colocando Maria como alvo e fazendo dela o "palhaço" da vez. Aparentemente ninguém percebia, ou ninguém se importava com o quanto aquilo a incomodava. Em certo momento ficou implícito, uma piada feita onde todos riram menos ela, o que significava que não merecia aumento. Isso foi verbalizado na frente de todos, e ela ficou sem palavras. Não rir foi tratado como sinal de que ela não queria aumento ou não queria ser promovida. Talvez até uma forma de coação sutil, porém eficaz, o tipo de coisa que ensina a engolir o desconforto.

Isso não é cultura descontraída nem falta de jeito social, é condicionar reconhecimento profissional a uma performance emocional que nada tem a ver com entrega de trabalho. Quando rir de uma piada vira pré-requisito informal para crescer na empresa, o problema não é falta de senso de humor de quem não riu, é gestão de pessoas tratando desconforto alheio como moeda de troca.

O corpo começou a cobrar

O primeiro episódio de burnout Maria não percebeu, mas o segundo e o terceiro não vieram sozinhos. Acompanhados de ansiedade, noites mal dormidas e depois um quadro depressivo que chegou devagar. A imunidade caiu e a fez verbalizar que estava no limite, um pedido de ajuda. A resposta veio em poucos minutos: "A empresa é assim, lide com isso.", a mesma empresa que prometia um ambiente familiar, amigável e compreensível quando a contrataram.

Aqui o despreparo deixa de ser só falta de experiência e passa a ser negligência. Ninguém espera que um líder de equipe tenha resposta pronta para tudo, muito menos para a saúde mental de alguém. Mas existe uma diferença enorme entre não saber o que fazer e escolher não fazer nada diante de um pedido de ajuda direto, e a segunda opção é omissão.

O alívio misturado com a perda e a incerteza na carreira

Finalmente a demissão chegou, e o primeiro sentimento foi de alívio. Mas, passadas algumas semanas, veio a famosa sensação de estar perdida sem saber o que fazer. Se 7 meses de trabalho podiam ser descartados com uma conversa, se em 2 anos e meio de trabalho tudo o que fez sempre foi visto como errado e questionável, o que ela realmente sabia fazer? Foi o suficiente para fazer com que ela se afastasse da carreira, por sentir que perdeu todo o seu tempo durante todos esses meses de trabalho, um tempo que foi gasto tentando sobreviver em um ambiente que deveria ser de crescimento profissional e pessoal.

Depois de quase 6 meses, Maria está retornando aos poucos e entendendo que, ao contrário do que imaginava, ela estava certa em boa parte do tempo, se não o tempo todo.

O que fica dessa história

Maria terminou esses dois anos e meio se perguntando o que ela realmente sabia fazer, mas nada do que ela viveu foi sobre incompetência técnica. Templates falham, códigos quebram, tecnologias são atualizadas e bugs aparecem, isso faz parte do trabalho de qualquer time. O que a fez duvidar de si mesma não foi o próprio trabalho, foi ver 7 meses de entrega descartados sem debate, foi ser cobrada por PRs que ela não podia validar sozinha, foi ter o silêncio diante de uma piada usado contra ela como prova de que não merecia crescer. Nada disso mede competência. Mede o quanto alguém aguenta absorver a desorganização de quem deveria estar organizando.

Um gestor que tomou decisões sem avaliar o que já havia sido construído, que deixou a palavra de quem falava mais alto pesar mais do que meses de entregas, que não conseguiu alinhar a própria comunicação com a da equipe que ele mesmo montou. Foi esse gestor quem tolerou, quando não incentivou, um ambiente onde desconforto virava moeda de troca por reconhecimento, e que, diante de um pedido de ajuda real, escolheu responder que a empresa era assim. Essa parte não se dilui em "cultura de empresa", é responsabilidade de uma pessoa específica, e também não é exclusividade de negócios pequenos: é o retrato de um tipo de gestão que existe aos montes, seja numa empresa pequena onde o gestor é o dono, seja numa empresa grande com uma liderança que não cumpre seu papel, onde não há ninguém disposto a dizer que aquilo precisa mudar e o despreparo nunca é confrontado.

Liderar bem não é sobre nunca errar numa escolha feita. É escutar quem está no dia a dia do projeto antes de descartar o trabalho dessa pessoa, alinhar antes de cobrar, garantir que ninguém precise se sentir mal para provar seu valor. Quando isso falta, o custo não aparece só em atrasos de cronograma, aparece depois, na carreira de quem saiu de lá achando que o problema era ela. Se você reconheceu esse padrão em algum lugar onde trabalha ou já trabalhou, vale se perguntar se o que te fez duvidar de você foi mesmo o seu trabalho ou foi a bagunça de quem deveria estar te dando direção, e prestar atenção em quem pode estar carregando esse peso sozinho agora.

- Agradecimentos

Quero agradecer ao @clintonrocha98 pelo feedback quando apresentei minha primeira versão, a @szaranct pelo review minucioso quando a segunda versão chegou, e a @cherryramatis que me ajudou muito com seu artigo de como escrever artigos. 💜

Velocidade de entrega e custo de manutenção pós IA

Elves Santos — Thu, 27 Aug 2026 13:58:08 +0000

Entregar ficou rápido demais. O problema é que manter continuou custando o mesmo preço de sempre.

Tabela de Conteúdo

O dia que a conta chegou
A gente tá comemorando a parte barata
Se isso quebrar às 3 da manhã, eu consigo debugar sem reabrir o chat?
O gargalo só mudou de lugar
O que eu faço hoje
No fim das contas, o trabalho virou escolher

O dia que a conta chegou

Vou começar confessando uma coisa.

Teve uma feature esse ano que eu entreguei numa manhã. Uma manhã. CRUD de fórmulas de análise: o cliente queria configurar a própria conta de infestação em vez de pedir pra gente cravar no código. Migration, 4 rotas novas, uma tela de 949 linhas, e o melhor pedaço, que foi trocar 208 linhas de estratégia de cálculo hardcoded por 50 linhas chamando um avaliador de fórmula. 11h17 da manhã o PR do front tava aberto. 11h32 o do back. Fui almoçar me achando o cara.

Duas semanas depois apareceram 3 tipos de análise novos. E alguém (eu) entrou no servidor e adicionou as 3 estratégias hardcoded de volta, no mapa que o motor genérico tinha aposentado 14 dias antes. O diff parte da versão antiga do arquivo. Quem escreveu aquilo não achou o caminho novo. Não entendeu que existia um caminho novo.

27 dias depois eu voltei de novo, porque quando um tipo de análise não tinha fórmula o código fazia throw new Error(JSON.stringify({...})). Uma exceção com JSON dentro da mensagem, que o handler HTTP tinha que abrir pra saber o que dizer pro usuário. Consertar isso custou 35 linhas de código e 175 de teste. 5 vezes mais teste que código, escrevendo teste pra um caso que eu deveria ter pensado na manhã em que "entreguei".

Hoje, 5 meses depois, o arquivo tem 268 linhas e ainda carrega um comentário meu: // Keep for backwards compatibility with tests. Um mapa de 16 entradas que nenhuma linha de produção lê. Ele tá lá porque 14 asserções do teste dependem dele, e ninguém (eu) teve a tarde sobrando pra desmontar. O arquivo de teste tem 351 linhas. É maior que o serviço que ele testa.

A manhã eu economizei. Os três retornos ao arquivo, não.

Ó, e antes que alguém entenda errado: eu uso IA todo santo dia, em tudo. Não é papo de "IA é ruim" não. É outra coisa.

A gente tá comemorando a parte barata

Pensa comigo no que a IA realmente barateou.

Boilerplate, DTO, migration, aquele CRUD que você já fez 40 vezes na vida, o esqueleto de um módulo novo, entender uma lib que você nunca tinha aberto. Tudo isso ficou absurdamente mais barato e eu não quero de volta nem por decreto.

Mas repara: tudo isso é o momento em que o código nasce.

E software não passa a vida nascendo. Software passa a vida sendo lido, debugado, alterado às pressas na sexta e explicado pra alguém que entrou no time mês passado. Essa parte aí continua custando o mesmo tanto que custava em 2019. Talvez mais, porque agora tem mais código.

Então quando você olha e fala "cara, eu tô 3x mais produtivo", pode ser verdade. Mas provavelmente você tá medindo só o pedaço que já era o mais rápido do processo.

Se isso quebrar às 3 da manhã, eu consigo debugar sem reabrir o chat?

Se eu pudesse deixar uma pergunta só desse artigo, seria o título dessa seção. Faz ela antes de mergear.

Se a resposta for não, você não terminou. Você só empurrou.

Tem uma versão mais dura dessa pergunta, que é: você consegue explicar por que aquilo tá daquele jeito pra uma pessoa que nunca viu esse código? Porque se você não consegue, quem tem ownership daquele arquivo não é você. E o modelo não vai estar de plantão com você no dia do incidente, isso eu garanto.

De novo, não é pra escrever tudo na mão. É pra ler antes de aceitar. Ler de verdade, linha por linha, com o dedo na tela se precisar.

Ler 200 linhas leva uns 10 minutos. Debugar 200 linhas que você nunca leu leva um dia. Essa conta nunca mudou e não vai mudar.

E olha, tem um detalhe que eu demorei pra perceber: a IA quase nunca te devolve a solução mínima. Ela te devolve a completa. Com uma abstração que você não pediu, um parâmetro opcional "pra ficar flexível", uma interface pra um caso de uso que não existe no seu projeto. Você pediu uma função, voltou um framework.

E cada uma dessas linhas é uma linha que alguém do time vai ter que ler algum dia. Ninguém escreve isso no card, mas tá lá.

O gargalo só mudou de lugar

Essa aqui eu vi acontecer no time e demorei pra entender. E ela corta dos dois lados.

O primeiro corte é no review. A gente aumentou muito a velocidade de quem escreve e não aumentou nada a de quem revisa. Continua sendo o mesmo cérebro humano, com as mesmas 24 horas, agora com PR de 40 arquivos caindo na fila.

Aí acontece o que sempre acontece quando a fila cresce. O revisor começa a bater o olho no resumo das mudanças (o diff), ver que os testes passaram e mandar aquele "por mim tá bom" (o famoso LGTM, de looks good to me). Todo mundo aqui já fez isso, inclusive eu. Não vamos fingir que não.

Só que aí você tem código que ninguém escreveu de verdade sendo aprovado por ninguém de verdade, indo pra produção onde tem cliente pagando. E quando quebra, tem duas pessoas envolvidas e nenhuma das duas sabe o que aquilo faz.

Passar o review pra IA também não resolve. Na minha opinião, ajuda a pegar coisa boba, tipo, ajuda mesmo. Mas o review não existe só pra achar bug; existe pra pelo menos duas pessoas do time saberem que aquele código existe.

O segundo corte é no seu preço, e esse é o que mais me incomoda.

No dia em que você entrega em 2 horas uma coisa que levaria 2 dias, o prazo daquela coisa virou 2 horas. Pra sempre. Ninguém volta atrás e pergunta "opa, mas quanto disso foi porque a IA acertou de primeira e quanto foi sorte?". A régua sobe e ela não desce nunca mais.

Aí chega o problema chato de verdade, aquele que não tem resposta pronta em lugar nenhum, que exige você sentar e pensar por 3 dias. E agora você tá devendo uma velocidade que na real você nunca teve.

Se você é PJ e cobra por escopo então, pior ainda. Você acabou de deflacionar seu próprio preço e ficou com a manutenção no colo de graça. Eu entreguei numa manhã e voltei naquele arquivo 3 vezes depois. Cobrei a manhã. As 3 voltas eu paguei do meu bolso, com o meu tempo.

E é aí que eu fico travado: como é que eu continuo usando isso, que é bom demais pra abrir mão, sem entregar de graça o controle do que entra no código e o preço do meu trabalho?

O que eu faço hoje

Hoje eu atuo como desenvolvedor PJ, e eu elaborei um processo de pensamento pra me ajudar a lidar com situações como essa. Esse processo, como estou chamando, foi resultado de muitos erros que eu cometi durante o uso de IA no meu trabalho.

Eu descrevo o problema, não o código. Antes eu pedia "escreve uma função que faz X" e recebia a tal solução completa. Hoje eu falo:

o que já existe no projeto,
qual a restrição,
e principalmente o que eu não quero.

Cortou muita abstração aleatória. E continuo:

Eu peço a versão pequena, explicitamente. "Faz o mais simples que resolve, sem generalizar". Você não faz ideia do tanto de código que some quando você pede isso.

A descrição do PR eu escrevo eu mesmo, do zero. O "como" pode vir gerado, tudo bem. O "por quê" é a única parte que não dá pra regenerar depois, e é justamente a que o meu eu de daqui a 6 meses vai precisar.

Se saiu um PR monstro, eu quebro. Mesmo dando trabalho. O tamanho que cabe na cabeça de uma pessoa não mudou porque a IA chegou.

E teste eu concentro onde dói. Caso feliz a IA cobre sozinha e é justamente o que menos quebra. O que quebra é falha de rede, payload torto, aquele dado legado que só existe naquele cliente antigo. É lá que mora o prejuízo.

Sobre o preço, mudou uma coisa também: eu parei de estimar código e comecei a estimar problema resolvido. Não é a manhã que eu vou passar escrevendo, é o mês em que aquilo vai ficar de pé.

No fim das contas, o trabalho virou escolher

Eu não sei se essa é a leitura certa, é o que eu enxerguei até agora mexendo com isso no dia a dia.

Mas acho que a IA não acabou com o trabalho de engenharia, ela acabou com a parte mecânica dele. E ao acabar com a parte mecânica, ela deixou exposta a parte que a gente sempre conseguiu empurrar com a barriga: entender o sistema, decidir com critério, e sustentar aquilo em produção depois.

Quem só digitava rápido perdeu vantagem. Quem consegue olhar pra 200 linhas geradas e falar "isso aqui tá errado, e o motivo é esse" ficou mais valioso, não menos. E repara no que essa pessoa tá fazendo de verdade: ela avaliou as opções e escolheu qual desvantagem ela topa carregar. O mercado chama isso de trade-off, e é literalmente o trabalho que sobrou pra gente. Generalizar agora e pagar complexidade, ou hardcodar hoje e pagar depois. Não existe escolha sem conta pra pagar, existe escolha feita com os olhos abertos e escolha feita no automático.

Velocidade de entrega é fácil de mostrar em daily. Custo de manutenção fica escondido até o dia que ele te acha.

Então gera, sim, gera bastante. Só lê o que você gerou antes de assinar embaixo.

Da comunidade para a comunidade.

Bebe água e a gente se vê no próximo artigo.

1ª vez trabalhando com git em um time: tudo que você precisa saber

vitoriazzp — Thu, 20 Aug 2026 06:52:21 +0000

Faz mais de 5 anos que eu não abria um PR ou issue técnica no Github, mas essa semana tenho aprendido algumas boas práticas e termos que reuni neste artigo.

Introdução

Essa semana eu fiz uma coisa simples: atualizei o README de um projeto open source, o 4noobs, da comunidade He4rt. Troquei um badge, ajustei o contraste de um logo, organizei umas pastas e adicionei um índice pra facilitar a navegação. Nada muito complexo no fim das contas.

Só que antes de chegar no "nada muito complexo", eu passei um tempo enrolada com uma pergunta boba:

"E se eu mandar isso direto pra branch principal e bagunçar tudo?"

Se tu já sentiu esse friozinho na barriga antes de mexer num repositório que não é só teu, esse artigo é pra ti. Não importa se tu é dev há anos ou se nunca abriu um terminal na vida... A lógica por trás de "como contribuir sem quebrar nada" é a mesma e bem mais simples do que parece.

Definição de Git Colaborativo

Quando eu aprendi git há uns anos, aprendi somente o versionamento e a enviar os arquivos pra dentro do Github, mas ele é bem mais que isso, né?

É através dele que times enormes interagem a respeito de um mesmo projeto de forma organizada, comentando, gerenciando tarefas, sugerindo melhorias e conhecendo o que os outros envolvidos estão fazendo. Isso é a parte do Git Colaborativo.

O Git resolve isso com um conceito central: branches (ou "ramificações"). Cada branch é tipo uma cópia paralela do projeto, onde tu pode mexer à vontade sem afetar a versão "oficial" (geralmente chamada de main ou master). Quando tu termina sua parte, tu propõe que essas mudanças sejam incorporadas de volta pelo Pull Request (PR).

Ou seja, o fluxo básico é:

Tu cria uma branch nova a partir do projeto principal
Faz as alterações lá, no seu espaço isolado
Envia (push) essa branch pro repositório remoto
Abre um Pull Request pedindo pra essas mudanças serem revisadas e, se aprovadas, unidas (merge) à branch principal

Ninguém mexe direto na versão "de produção" do projeto. Isso é o que torna possível centenas de pessoas contribuírem pro mesmo repositório sem o caos se instalar.

Principais Aprendizados

Bom, na prática, foi mexendo que aprendi (e relembrei) algumas coisas que acho que valem ser compartilhadas:

Branch nova não é sobre desconfiança, é sobre segurança. Criar uma branch pra cada contribuição não é burocracia sem sentido — é o que garante que, se algo der errado, o "errado" fica isolado ali, sem afetar o projeto principal. Isso vale tanto pra quem tá contribuindo quanto pra quem revisa.

git push não é a mesma coisa que abrir um Pull Request. Isso me pegou de surpresa: o push só envia sua branch pro GitHub. O PR é um passo separado, onde tu formaliza o pedido de revisão. O próprio terminal, inclusive, já te entrega o link pronto pra criar o PR depois do push.

Não precisa ter issue aberta pra contribuir. Eu fiquei presa nessa por um tempo. Pensei: "Ah, mas ninguém pediu essa melhoria, será que posso mandar mesmo assim?" Pode! Principalmente em documentação: se tu enxergou algo que pode melhorar, a contribuição em si já é a justificativa.

Descrição de PR boa não é uma lista de tudo o que mudou linha por linha. É um resumo categorizado, por exemplo:

o que foi feito,
por quê,
e os principais pontos agrupados por tema. Isso poupa um tempo enorme para quem vai revisar.

A pasta .github pode ser local ao repositório ou um "padrão" pra organização inteira, dependendo se existe um repositório especial chamado literalmente .github na conta. Detalhe pequeno, mas que ajuda a entender por que às vezes umas configurações "aparecem" em vários repositórios sem alguém ter copiado e colado em cada um.

Nenhum desses pontos é complicado isoladamente. O que trava a gente, geralmente, não é a técnica — é o medo.

Gerenciando o medo de fazer errado

Aqui vai a parte que eu acho mais importante desse artigo, sinceramente.

Toda vez que eu vou mexer num repositório que não é só meu, seja um projeto open source, seja no trabalho, bate aquele receio: "e se eu errar? E se eu quebrar algo? E se acharem que eu não sei o que tô fazendo?

E olha, isso não passa de uma hora pra outra. Mas duas coisas mudaram bastante minha relação com esse medo:

Entender a ferramenta tira o poder do medo.

Muito do que a gente teme é o desconhecido. Quando eu entendi que uma branch é literalmente um espaço isolado, que nada do que eu fizesse lá afetaria a main até alguém aprovar um merge, o medo diminuiu bastante. Não é sobre ser corajosa, é sobre saber que o sistema já foi desenhado pra proteger contra erro.

Errar em público faz parte do processo; não é uma falha nele.

A comunidade open source inteira é construída em cima de gente errando, corrigindo, revisando o trabalho umas das outras. Um PR rejeitado ou com pedido de ajuste não é um veredito sobre tua competência, é literalmente o sistema funcionando como devia.

Se tem uma coisa que eu queria ter escutado antes de começar a contribuir, é isso: ninguém espera que tu chegue sabendo tudo. As branches, os PRs, as revisões, tudo isso existe justamente porque errar faz parte.

Então, se tu tá enrolando para abrir aquele primeiro PR por medo de fazer besteira: cria a branch, faz a mudança e manda ver. O pior que pode acontecer é alguém te dar um feedback — e isso, no fim das contas, é como a gente aprende e melhora

Materiais Complementares

Esses são todos os materiais que me foram indicados ou lidos durante as práticas descritas acima. Alguns ensinam sobre estrutura e outros sobre boas práticas. Também tive muita ajuda de amigos e fiz pesquisas com IA pra compreender exatamente termos ou partes de código que eu não estava entendendo.

Se esse artigo te ajudou de alguma forma, deixa o coraçãozinho aí 💜 e conta nos comentários:

qual foi teu primeiro PR ou tua primeira contribuição pra um projeto que não era seu? Bora trocar ideia!

Como criei um agente de IA para selecionar testes automaticamente em PRs (Parte 1)

Alicia Marianne Gonçalves — Tue, 11 Aug 2026 16:22:22 +0000

🇺🇸 You can also read the English version of this article on AWS Community Builders.

Uma das coisas mais comuns em grandes projetos pelos quais já passei são pipelines com muitos testes, levando muito tempo para serem executados. E com isso eu pensei: por que não ter um agente de IA para analisar meus PRs e, a partir das modificações, selecionar apenas os testes que precisam ser executados? Nesse artigo vou te mostrar como eu fiz isso e já adianto que provavelmente isso vai virar uma série de artigos.

(Se você não conhece o termo, o que estou descrevendo aqui é uma versão simplificada de **Test Impact Analysis: em vez de rodar a suíte inteira a cada PR, o objetivo é mapear quais testes realmente têm relação com o que foi alterado.)

Prompts utilizados

Um dos feedbacks que recebi nos meus últimos artigos foi para deixar mais explícitos os prompts que utilizei para criar o projeto, e nesse eu usei apenas dois:

claude poderia me ajudar a fazer um projeto onde vou ter um agente de IA para analisar as linhas de códigos que foram modificadas em um PR e selecionar testes relacionados a essa modificação?

Como resposta para essa primeira pergunta, ele criou pra mim um diagrama de como basicamente isso poderia funcionar, sem nenhuma integração a pipeline ou coisa do tipo:

Depois disso, simplesmente pedi para ele criar um prompt para o Claude Code (a IA que utilizo) e, depois de colar o prompt gerado:

A primeira versão do projeto foi criado no seguinte formato:

main.py                  CLI entrypoint — wires everything together
config.py                Loads & validates ANTHROPIC_API_KEY / GITHUB_TOKEN
src/
  github_client.py       Fetches PR files & metadata from the GitHub API (with retries)
  diff_parser.py         Maps diff hunks to changed functions/classes via AST
  test_discovery.py      Indexes pytest test functions across the repo
  ai_agent.py            Calls Claude to select relevant tests
  reporter.py            Renders results as a table or JSON
tests/                   Unit tests for the parser & discovery modules

Vale destacar o diff_parser.py: em vez de simplesmente olhar quais linhas mudaram no diff, ele usa AST (Abstract Syntax Tree) para entender quais funções e classes foram alteradas. Essa diferença importa bastante — duas linhas modificadas dentro da mesma função valem como uma única mudança de símbolo, o que deixa a seleção de testes mais precisa do que uma comparação puramente textual.

Dando destaque ao nosso ai_agent.py, pois é nele que acontece a mágica, temos alguns argumentos interessantes de entender:

Relevance = Literal["low", "medium", "high"]

Ter um filtro de relevância é importante para auxiliar a IA no momento em que ela for analisar, entre os testes disponíveis, quais realmente precisam ser executados. Na prática, esse filtro também vira um dial de confiança para quem está usando a ferramenta: em um pipeline de CI mais crítico, faz sentido rodar só os testes marcados como high; em uma verificação mais exploratória, pode valer incluir low e medium também.

O prompt utilizado foi esse:

_SYSTEM_PROMPT = """\
You are a senior software engineer who selects which pytest tests are relevant \
to review for a given pull request.

You will receive a JSON object with:
- "min_relevance": the minimum relevance level to include ("low", "medium", or "high")
- "changed_symbols": a list of functions/classes/methods (or whole files) modified in the PR,
  each with file_path, symbol_name, symbol_type, and lines_changed
- "available_tests": a list of test functions discovered in the repository, each with
  test_path, test_name, imports, and source_references

Decide which of the available tests are relevant to the changed symbols by considering:
- Whether a test's source_references directly name a changed symbol
- Whether a test's imports point to the module containing a changed symbol
- One level of transitivity: a test that references something which itself references
  a changed symbol (e.g. a helper that calls the changed function)
- The semantic similarity between test names/paths and changed symbol names

Respond with ONLY a JSON array (no prose, no markdown fences, no text outside the array).
Each element must have exactly this shape:
{
  "test_path": "<string>",
  "test_name": "<string>",
  "relevance": "<low|medium|high>",
  "confidence_score": <float between 0.0 and 1.0>,
  "reason": "<short string explaining why this test is relevant>"
}

Only include tests whose relevance is greater than or equal to the given min_relevance
("low" < "medium" < "high"). If no tests are relevant, return an empty array: []
"""

Um ponto que vale destacar nesse prompt é a "um nível de transitividade": o agente não olha só se um teste referencia diretamente o símbolo alterado, mas também se ele referencia algo que, por sua vez, referencia o símbolo alterado (por exemplo, um helper chamado pela função modificada). Isso ajuda a pegar casos de teste que passariam despercebidos numa busca só por nome.

Seleção do AI Agent

A primeira mudança que fiz foi pedir para a IA adaptar o código de forma que fosse possível passar qual IA utilizar como parâmetro, em vez de deixá-la fixa:

"""Thin wrappers so AIAgent can call Claude, Gemini, or ChatGPT interchangeably."""

from typing import Protocol

from config import Config

class LLMProvider(Protocol):
    """Something that can turn a system + user prompt into a text completion."""

    def complete(self, system_prompt: str, user_prompt: str) -> str: ...

class ClaudeProvider:
    """Calls Anthropic's Claude models."""

    def __init__(self, api_key: str, model: str) -> None:
        from anthropic import Anthropic

        self._client = Anthropic(api_key=api_key)
        self._model = model

    def complete(self, system_prompt: str, user_prompt: str) -> str:
        response = self._client.messages.create(
            model=self._model,
            max_tokens=4096,
            system=system_prompt,
            messages=[{"role": "user", "content": user_prompt}],
        )
        return "".join(block.text for block in response.content if getattr(block, "type", None) == "text")

class GeminiProvider:
    """Calls Google's Gemini models."""

    def __init__(self, api_key: str, model: str) -> None:
        from google import genai

        self._client = genai.Client(api_key=api_key)
        self._model = model

    def complete(self, system_prompt: str, user_prompt: str) -> str:
        from google.genai import types

        response = self._client.models.generate_content(
            model=self._model,
            contents=user_prompt,
            config=types.GenerateContentConfig(system_instruction=system_prompt),
        )
        return response.text or ""

class ChatGPTProvider:
    """Calls OpenAI's ChatGPT models."""

    def __init__(self, api_key: str, model: str) -> None:
        from openai import OpenAI

        self._client = OpenAI(api_key=api_key)
        self._model = model

    def complete(self, system_prompt: str, user_prompt: str) -> str:
        response = self._client.chat.completions.create(
            model=self._model,
            messages=[
                {"role": "system", "content": system_prompt},
                {"role": "user", "content": user_prompt},
            ],
        )
        return response.choices[0].message.content or ""

def create_provider(config: Config) -> LLMProvider:
    """Builds the LLMProvider for config.provider, using the matching API key and model."""
    if config.provider == "claude":
        assert config.anthropic_api_key is not None
        return ClaudeProvider(api_key=config.anthropic_api_key, model=config.claude_model)
    if config.provider == "gemini":
        assert config.gemini_api_key is not None
        return GeminiProvider(api_key=config.gemini_api_key, model=config.gemini_model)
    if config.provider == "chatgpt":
        assert config.openai_api_key is not None
        return ChatGPTProvider(api_key=config.openai_api_key, model=config.chatgpt_model)
    raise ValueError(f"Unknown provider: {config.provider!r}")

O uso do Protocol aqui é o que permite trocar de provedor sem alterar o restante do código: qualquer classe que implemente complete(system_prompt, user_prompt) serve, então AIAgent nunca precisa saber se está falando com Claude, Gemini ou ChatGPT.

Dessa forma, fica a critério de quem está utilizando o pacote selecionar qual IA será usada, podendo isso ser passado como parâmetro no momento da execução:

python main.py --pr 42 --repo owner/repo --provider gemini
python main.py --pr 42 --repo owner/repo --provider chatgpt
python main.py --pr 42 --repo owner/repo               # default: claude

Validando se o que foi gerado realmente está certo

Para a primeira validação, pesquisei alguns repositórios públicos no GitHub e, nesse caso, selecionei este PR: https://github.com/pallets/flask/pull/6043

python main.py --repo pallets/flask  --pr 6043  --provider gemini

E obtive o seguinte resultado:

Só que agora entra a parte complicada, sempre temos nos perguntar quando utilizamos IA:

Essa resposta faz sentido?

E, de cara, dá para ver que não — não está certo. Quando passamos um repositório diferente, ele continua buscando no repositório local, ignorando completamente o repositório do PR informado. Para corrigir isso, precisamos garantir que, sempre que for um repositório externo, o agente acesse as informações diretamente dele e para isso, vamos clonar temporariamente uma branch do repositório:

"""Clones a single branch of a GitHub repository into a temporary directory for local scanning."""

import logging
import shutil
import subprocess
import tempfile

logger = logging.getLogger(__name__)

class RepoFetchError(RuntimeError):
    """Raised when the target repository/branch cannot be cloned."""

class RepoFetcher:
    """Shallow-clones a single branch of a repository so its tests can be scanned locally."""

    def __init__(self, token: str | None = None) -> None:
        self._token = token
        self._tmp_dir: str | None = None

    def fetch(self, repo: str, ref: str) -> str:
        """Clones `repo` (owner/name) at branch `ref` and returns the local checkout path."""
        self._tmp_dir = tempfile.mkdtemp(prefix="ai-test-selector-")
        cmd = [
            "git",
            "clone",
            "--depth",
            "1",
            "--branch",
            ref,
            "--single-branch",
            self._clone_url(repo),
            self._tmp_dir,
        ]
        result = subprocess.run(cmd, capture_output=True, text=True)
        if result.returncode != 0:
            shutil.rmtree(self._tmp_dir, ignore_errors=True)
            self._tmp_dir = None
            raise RepoFetchError(f"Failed to clone {repo}@{ref}: {result.stderr.strip()}")
        return self._tmp_dir

    def cleanup(self) -> None:
        """Removes the temporary checkout, if one was created."""
        if self._tmp_dir:
            shutil.rmtree(self._tmp_dir, ignore_errors=True)
            self._tmp_dir = None

    def _clone_url(self, repo: str) -> str:
        if self._token:
            return f"https://x-access-token:{self._token}@github.com/{repo}.git"
        return f"https://github.com/{repo}.git"

Repare no --depth 1 e --single-branch do clone: como o objetivo aqui é só escanear os testes do repositório naquele ponto específico, não faz sentido trazer todo o histórico de commits — um shallow clone resolve o problema mais rápido e consumindo bem menos espaço em disco.

Rodando o mesmo comando, temos o seguinte resultado:

Em resumo, ele selecionou:

Selected 192/403 tests (avg confidence: 0.76)
pytest tests/test_appctx.py tests/test_async.py tests/test_basic.py tests/test_blueprints.py tests/test_cli.py tests/test_converters.py
tests/test_helpers.py tests/test_json.py tests/test_logging.py tests/test_regression.py tests/test_reqctx.py tests/test_request.py
tests/test_session_interface.py tests/test_signals.py tests/test_subclassing.py tests/test_templating.py tests/test_testing.py
tests/test_user_error_handler.py tests/test_views.py -v

É possível ver que com a IA, ao invés de rodarmos toda a suite, poderíamos rodar apenas 48% dela, reduzindo o tempo de execução e retornando um feedback muito mais rápido para quem está desenvolvendo a feature.

Conclusão

Como o artigo já está ficando grande, vou parar por aqui nesta primeira etapa. Revisando, o foco desta primeira parte foi refinar o prompt utilizado pela IA para gerar o código e, a partir disso, revisar o que foi gerado. Nela tivemos duas mudanças significativas:

Adaptação do código para utilizar diferentes provedores de IA, de forma que o projeto não ficasse preso a um único modelo.
Ajuste na busca dos testes, para que ela considerasse os testes disponíveis no repositório relacionado ao PR informado, e não no repositório local.

Próximos passos

Esse projeto ainda está bem no início, e pretendo continuar evoluindo ele nos próximos artigos. Já durante essa primeira parte, revisando o que foi gerado e testando em repositórios reais, surgiram algumas ideias novas que quero explorar:

Integração com pipelines: hoje o projeto roda de forma isolada, via linha de comando, mas o próximo passo natural é pensar em como plugar isso direto no CI/CD — por exemplo, como uma action do GitHub Actions que roda automaticamente a cada PR aberto e comenta com os testes selecionados, ou até já dispara só o subconjunto relevante.
Performance na parte de IA: com repositórios maiores, o número de testes disponíveis para avaliar cresce bastante, e isso significa prompts maiores e mais tempo de resposta. Quero investigar formas de otimizar essa etapa — seja filtrando os candidatos antes de mandar para a IA, seja quebrando a avaliação em lotes menores, ou até testando modelos diferentes para essa tarefa específica de classificação.

Se você quiser acompanhar a evolução do projeto (ou já colocar a mão na massa também), o código está aberto no meu repositório: ai-agent-test-selector

No próximo artigo, vou focar no prompt utilizado pela IA para selecionar os testes propriamente dito, além de adaptar o wrapper para ler repositórios que não sejam apenas em Python, mas também em outras linguagens.

Ficou alguma dúvida sobre alguma parte do código, do prompt ou da arquitetura? Deixa nos comentários — quero muito saber o que vocês acharam e trocar ideia sobre outros cenários onde isso poderia ser aplicado.

Programação Criativa: Vamos desenhar com código?

Sara Aniceto — Sun, 02 Aug 2026 01:36:54 +0000

Quem acha que a discussão entre arte gerada por computadores começou com a popularização das ferramentas de IA provavelmente perdeu boa parte das discussões envolvidas em arte generativa, arte computacional e design paramétrico que surgiram ainda no século passado. A Programação Criativa, que vamos entender melhor nesse artigo, é uma das formas possíveis de gerar arte a partir de algoritmos que vai muito além de mandar um prompt pra IA e esperar sua arte ser gerada. É construção, linha a linha, onde o programador faz da tela do computador e das linhas de código seu papel e pincel. Vem comigo entender melhor como usar suas habilidades de desenvolvimento para se divertir, experimentar e deixar a criatividade rolar solta.

O que é Programação Criativa?

Uma das coisas mais legais que ouvi me adentrando nos estudos de creative coding (termo em inglês para programação criativa) é que existem muitas pessoas que programam, mas que não são necessariamente "programadoras". A programação não precisa estar presa apenas à sua carreira, ela pode ser uma paixão, um hobby ou um playground lúdico.

A Programação Criativa é exatamente isso: usar o código para desenhar, criar animações e "brincar" com o computador. Em vez de focar apenas na criação de sistemas ou análise de dados o objetivo aqui é a exploração visual.

Você consegue acreditar que a imagem acima foi gerada com 0 linhas de um código Java? Em seguida vou te explicar melhor sobre o Processing e outras ferramentas de programação criativa.

Processing e p5.js: Onde o desenho encontra o algoritmo

Processing e o p5.js são duas das ferramentas mais populares criadas para facilitar o contato de artistas, ilustradores, designers e pessoas não programadoras em geral que queiram criar arte usando código.

A lógica entre eles é a mesma, o que muda são especificidades da sintaxe de cada linguagem.

Processing: Criado em 2001, é baseado em Java e é o "pai" de tudo isso. É um software gratuito, no formato de IDE, no qual você consegue escrever, executar e compilar os seus códigos, ou melhor suas obras (aqui chamadas de sketches).
p5.js: É uma versão do Processing baseada em JavaScript, mais popular atualmente e feita para rodar direto na web.

Hoje em dia também é possível usar o modelo do Processing baseado em Python e para a criação de aplicativos Android. O mais importante é entender que, enquanto no Photoshop você usa o mouse para desenhar, aqui você começa a desenhar escrevendo em uma página em branco.

A Anatomia Básica do Código (Para quem já coda entender)

Diferente de um script tradicional, a estrutura básica nessas ferramentas é muito simples e visual:

setup(): É a função que roda uma única vez assim que o programa inicia. É aqui que você define configurações importantes da sua arte, como o tamanho do seu "papel" (canvas).
draw(): Aqui é onde a mágica acontece. Essa função é um loop infinito. Ela é lida ciclicamente enquanto o programa roda. Se você desenhar algo aqui, pode criar animações ou responder a eventos, como o movimento do mouse.

Com essa estrutura pronta, vale acessar a documentação e entender as inúmeras possibilidades de formas, elementos tipográficos, animações, etc que é possível criar com essas ferramentas. Esse pedaço de código abaixo é o que gerou a imagem que eu mostrei no início do artigo.

void draw(){
  background(255);
  fill(0);
  noStroke();

  float tiles = mouseX/10;
  float tileSize = width/tiles;

  translate(tileSize/2,tileSize/2);

  for(int x = 0; x < tiles; x++){
    for(int y = 0; y < tiles; y++){

      //Picks the color based on the pixel, in which the pixel is the size of the tiles
      color c = img.get(int(x*tileSize),int(y*tileSize));
      float size = map(brightness(c),255,0,0,20);

      ellipse(x*tileSize,y*tileSize,size,size);
    };
  };
}

Uma ferramenta visual de aprendizado de programação

É possível que você ainda não tenha sido convencido de explorar o Processing e a programação criativa para despertar o lado artista que mora em você? Se sim, eu te faço uma pergunta: quando é que você parou de desenhar e virou um adulto chato sem criatividade?

Brincadeiras à parte, talvez então você seja convencido de que a programação criativa pode também servir como um facilitador para o aprendizado técnico porque transforma conceitos abstratos (como laços de repetição e condicionais) em resultados visuais e imediatos na sua tela.

É como um "debug visual". Afinal, ver um for loop gerando 100 bolinhas coloridas na sua tela em tempo real é a melhor forma de "debugar" sua lógica mental.

Conclusão: Experimente!

Se você sente que a programação às vezes fica um pouco "rígida" ou mecânica demais, tente criar um sketch no Processing ou p5.js. É uma forma de usar sua lógica para algo puramente estético e divertido.

Abaixo deixo alguns links para encontrar referências de projetos, materiais gratuitos e comunidades pra quem quiser conhecer mais:

OpenProcessing: Plataforma de hospedagem de projetos em Processing, é o GitHub da Programação Criativa
Curso gratuito de Programação Criativa: Repositório no GitHub de curso por Monica Rizzolli e Alexandre Villares
Código Transcendente : Uma introdução prática à programação e arte gerativa: Livro de Mateus Paresqui Berruezo
Compoética - Encontro Brasileiro de Programação Criativa
Comunidade de Programação Criativa no Brasil no Telegram

Pensar demais nem sempre ajuda e o que eu aprendi com isso

Yuri Souza — Sat, 01 Aug 2026 10:57:53 +0000

Às vezes, a maior barreira para começar um projeto não é a complexidade do problema, mas a busca por uma solução perfeita antes mesmo da primeira linha de código.

Na semana passada decidi criar um pacote Laravel para integrar a API do Asaas.

A ideia parecia simples: construir algo reutilizável para projetos futuros e, de quebra, aprender mais sobre desenvolvimento de pacotes.

Foi então que eu:

Abri a IDE e comecei a criar um cliente HTTP simples para a API da Asaas.
15 minutos depois, eu já estava pesquisando sobre arquitetura de pacotes open source.
Pensei em DTOs.
Pensei em interfaces.
Pensei em Services

O que eu entendia por "perfeito"?

Na minha cabeça, um projeto bem feito precisava nascer parecido com os grandes projetos open source que eu admirava.

Antes mesmo de validar a ideia, eu já pensava na arquitetura, na escalabilidade e em como aquele pacote pareceria para quem abrisse o repositório. E em outros cenários como:

pensar na mesma arquitetura que grandes projetos usam antes de ter o primeiro caso de uso funcionando;
tentar abordar todos os pontos da API da Asaas logo no começo, mesmo sem saber quais eu realmente ia usar;
imaginar os atrativos que meu pacote teria para outros quererem usá-lo, antes de ele fazer qualquer coisa útil.

No papel, parecia que eu estava pensando como alguém mais experiente, mas na prática, eu estava:

apenas adiando a parte mais importante que era escrever código que resolvesse um problema real.

O custo disso na prática

O curioso é que eu terminava o dia com a sensação de que tinha trabalhado bastante. Tinha lido sobre arquitetura, desenhado camadas, esboçado interfaces.

Só que, olhando para o projeto, praticamente nada tinha sido construído: nenhuma requisição enviada, nenhum teste rodando, nenhuma prova de que qualquer uma daquelas decisões fazia sentido.

Com o tempo, isso começou a gerar um padrão:

Mais tempo buscando a estrutura "perfeita" do que resolvendo o problema real;
Código difícil de entender por estar "bem arquitetado" demais, cedo demais;
Medo de refatorar algo que ainda nem tinha provado valor;
Uma frustração crescente por sentir que eu não estava evoluindo, só girando em torno da mesma decisão de design.

Não era falta de qualidade. Era complexidade antecipada.

O que eu estava realmente evitando?

Foi só depois que comecei a me perguntar outra coisa: por que eu estava tão preso nisso?

Algumas hipóteses:

Eu estava evitando escrever código que eu soubesse, de antemão, que ia precisar refatorar depois?
Eu tinha medo de escrever algo "ruim" e isso aparecer publicamente num repositório open source?
Eu queria provar, pra mim mesmo, que conseguia arquitetar "como um sênior" antes mesmo de ter o problema resolvido?

A resposta provavelmente era um pouco de cada uma. E nenhuma delas tinha relação com o problema que o pacote deveria resolver.

Só bem depois entendi que, no fundo, eu confundia complexidade com maturidade técnica.

O aprendizado que começou a aparecer

Enquanto refletia sobre isso, lembrei de uma frase que minha mãe repetia desde que eu era pequeno:

"Antes feito do que perfeito."

Sempre achei que essa frase servia para tarefas do dia a dia, como arrumar o quarto, terminar um trabalho da escola. Nunca imaginei que ela fizesse tanto sentido ao escrever software.

Junto com ela, veio outra ideia:

Bons sistemas não nascem perfeitos. Eles evoluem.

Nenhum dos projetos open source que eu admirava nasceu com a arquitetura que tem hoje; todos passaram por versões mais simples, mais cruas, que foram se modificando à medida que o uso real foi aparecendo.

Qualidade não está em prever todos os cenários.

Qualidade está em escrever código que consiga mudar quando esses cenários realmente aparecerem.

Foi só quando parei de procurar a arquitetura perfeita que finalmente escrevi minha primeira requisição de verdade para a API.

Antes mesmo de escrever a primeira integração, era assim que eu imaginava o pacote:

CustomerService
        ↓
AsaasClient
        ↓
CreateCustomerDTO
        ↓
Response

Mas não comecei com uma arquitetura cheia de camadas. Comecei com algo assim:

$asaas->customers()->create([
    'name' => 'Yuri Souza',
    'cpfCnpj' => '12345678909',
]);

Desde então, passei a repensar algumas atitudes:

resolver o problema atual com clareza antes de pensar no próximo;
manter o código simples, legível e testável;
criar abstrações apenas quando um padrão se repete de fato, não quando eu imagino que ele vai se repetir;
aceitar que refatorar faz parte do processo, não uma falha dele.

Não se trata de abandonar boas práticas, mas de aplicá-las no momento certo.

O equilíbrio que estou buscando hoje

Hoje tento encontrar um equilíbrio entre dois extremos: nem escrever código sem critério, nem criar uma arquitetura complexa antes que ela seja necessária.

No próprio pacote do Asaas isso já mudou a forma como estou trabalhando.

Hoje, a decisão que tomei foi outra: começar pelo caminho mais curto possível.

Primeiro quero que o pacote consiga conversar com a API e validar os casos de uso mais importantes. Só então vou descobrir quais abstrações realmente fazem sentido.

Em vez de tentar prever a arquitetura que o projeto terá daqui a um ano, prefiro deixar que ela se desenvolva à medida que novos problemas surgirem.

Foi aí que entendi uma coisa importante:

Arquitetura não é algo que eu preciso descobrir antes de começar. É algo que o próprio projeto vai mostrando à medida que cresce.

Conclusão

Ainda estou no começo desse pacote, e ainda estou aprendendo isso na prática, errando e ajustando no caminho.

Mas entender que "perfeição antecipada" pode virar um problema já foi um passo importante na minha evolução como desenvolvedor. O projeto do pacote Asaas não precisa da arquitetura perfeita logo de início; precisa apenas da primeira implementação. O resto vai aparecer conforme o uso real for mostrando o caminho.

Hoje prefiro um código simples que aceite mudanças a uma arquitetura impecável que resista a qualquer alteração.

Se você também já caiu nessa armadilha da arquitetura perfeita antes da hora, quero saber: como você percebeu e o que fez para sair dela?

A discussão continua nos comentários. Quero muito conhecer outras experiências e perspectivas sobre esse tema.

Agradecimentos: obrigado a @vitoriazzp pelo feedback sincero e pelas sugestões que ajudaram a tornar este artigo mais claro e útil.

Se eu pudesse recomeçar em TI, evitaria estes erros.

Aline Santana — Wed, 29 Jul 2026 13:39:48 +0000

Prólogo

No início da faculdade, séculos atrás (papo de 2021, foi quando entrei na he4rt developers inclusive) estava extremamente ansiosa e com isso cometi MUITOS ERROS, me levou ao bornout ficando SEM ESTUDAR por meses, até hoje vejo as pessoas cometendo a mesma coisa que eu no passado e isso atrasa MUITO os estudos! Como sempre meus artigos são super rápidos de ler, espero que gostem!

1º Não dê ouvidos as pessoas da área (depende)

Acho que o maior erro na internet, inclusive através de influenciadores, é o alarme negativo pra cima de áreas na tecnologia e até mesmo linguagens de programação, fazendo com que iniciantes tenham incertezas sobre o que está estudando.

Exemplo 1 : "Você estudando frontend? vai passar fome."
Exemplo 2 : "A IA vai roubar teu emprego como desenvolvedor xxx"
Exemplo 3 : "Flutter vai morrer esse ano de xxx"

Sendo bem sincera, nem ligue pra isso, tá? até hoje tem emprego pra COBOL, imagine pra tecnologias super modernas que muitas empresas usam, escolheu frontend (exemplo) ? estude, se esforce, converse com pessoas mais experientes nesse segmento e vai fundo, não desista por terceiros! Escolheu Python? cai dentro, a opinião da galera não pode definir teu futuro não.

2º Não pula de galho em galho

FOCA NO QUE ESCOLHEU E NÃO PULA, pois foi algo que cometi bastante, eu fui de dados até mobile com Flutter (tô escrevendo isso e rindo alto).

Vocês no outro lado da tela : "Aline, o que você faria hoje?"

Simples, como disse no primeiro artigo, autoconhecimento é importante, o que você gosta? isso que você gosta é evidência no mercado? pesquise, sai na busca.

1. Gosta de Matemática? _Ciência de Dados seria uma boa._
2. Gosta de celular? Por que não se envolve com criação de aplicativos?
3. É mais de "arte"? Já ouviu falar de UX/UI?
4. É visual? e desenvolvimento frontend?

Entende isso? é normal se perder com tantas informações e tantas áreas dentro de tecnologia, vai pesquisando com calma e veja qual se identifica.

3º IA é sua amiga, não inimiga, tenha medo não

Não me venha com o argumento : "Aline, não quero ser de TI pois a IA vai roubar meu emprego", vai nada amigo(a), LLMs em geral são feitas dentro de pesquisas e trabalhadas no que chamamos de probabilidade, é mais fácil tu acertar algo do que ela (risos), não vou ser hipócrita em dizer que IA não ajuda em algo, CLARO que ajuda, inclusive quando se trata de automação de tarefas, mas o que quero dizer é que VOCÊ TEM QUE SABER O QUE TÁ FAZENDO E NÃO DEIXAR A BASE DE LADO, ou seja : "Ai, não vou estudar programação, vou pular pro Claudinho", vai nessa, prejuízo é enorme.

"Mas fulano de tal usa", é que o "fulano de tal" já tem uma base muito sólida no conhecimento daquela linguagem, estamos entendidos? quando passei pela stack de Frontend, era um alarme com Inteligência Artificial gigantesco, tive muito medo e troquei de área, me atrasou muito. (na época)

4º Marca Pessoal galera, é importantíssimo!

Depois de um bom período me tratando psicologicamente (depressão), voltarei com o linkedin, mas vejo que muita gente faz descaso com essa rede, principalmente iniciantes! Motivos? talvez timidez (comum), não gosta, preguiça? talvez, eu não sei, só você sabe.

De forma geral, tenha uma marca pessoal trabalhada, isso é importante até mesmo dentro de comunidades, como os recrutadores podem analisar além do seu currículo destacado? acho um cristal quem faz conteúdo de tecnologia nessa rede, lá estão a maioria dos recrutadores e donos de empresas, seja visto!

Dica geral :

Escolha cores que lhe representam ou que você quer transmitir
Traga experiência real nos seus conteúdos
Não seja um personagem

Conclusão

Espero que tenham gostado desse artigo, eu poderia listar TANTAS COISAS que me atrasaram ou podem atrasar vocês, mas listei as mais importantes da minha vivência e que afeta iniciantes como eu.

Agradeço a He4rt Developers por essa iniciativa dentro da comunidade em instigar membros dentro da escrita

2 métodos que usei (E USO) nos estudos de programação.

Aline Santana — Mon, 27 Jul 2026 14:58:19 +0000

Prólogo

Para uma pessoa que tem TDAH (eu), é extremamente difícil e desafiador encontrar uma maneira mais “confortável” de estudar, ainda mais quando tal assunto é de exatas (sou de humanas e tô em TI, pasmem), então resolvi encontrar algumas maneiras e que claro, deu super certo pra mim e espero muitíssimo que dê certo pra vocês.

Observação (dica) : vai testando cada método, não pegue um como verdade absoluta, o que ficar confortável, use <3

Nem todos vão se dar bem com o método X e Y, cada cérebro funciona de uma maneira diferente, alguns de vocês vão se adaptar com vídeos, textos (artigos como esse), presencial ou online, o melhor jeito de encontrar o método “perfeito” é ter autoconhecimento, eu por exemplo : tem que ser mais prática do que teoria, vídeo aula ? tem que ser curto (longo demais me perco), o estudo tem que ser mais ativo do que passivo, revisão ? 0 aplicativo, revisão pra mim é prática.

Vamos ser bem rápidos com os métodos para usar como um mini caderno.

Método Feynman

Criado pelo físico (vencedor do prêmio nobel, tá?) Richard Feynman, seu método é basicamente fazer autoexplicação usando palavras e analogias de forma mais simples, sem esse jargão técnico que pode mais atrapalhar do que ajudar (ainda mais pra nós, meros iniciantes).

1.1 Já pega seu conteúdo que estuda.

O primeiro passo é escolher o que você está estudando, especialmente o que está travando seu cérebro, aquela parte do estudo que mesmo entendendo ainda sente falta de alguma coisa.

1.2 Explique de forma “leiga”.

Imagina que você é uma criança, primo(a), esse momento é importante que tire os conceitos técnicos que possivelmente pode “impedir” de aprender de forma fácil e explique do seu jeitinho, sem conceitos técnicos, sem palavras difíceis. Um prompt que é meme, mas eu uso bastante é : “Explique assunto xxx como se eu fosse uma criança de xxx anos, sem conceitos técnicos para que eu entenda de forma fácil e rápido”, após isso (novamente como disse) explique para si mesmo.

1.3 Lacunas.

Primo(a), em algum momento da explicação vai perceber que teve algumas lacunas na sua explicação (isso é normal, tá? você tá aprendendo, eu lembro que ficava muito chateada também rs), anote essas lacunas e até mesmo suas dúvidas, vamos para o último passo.

1.4 Refinamento.

Último passo (é bem simples), tudo que encontrou de lacunas e dúvidas você vai achar no material que estudou, anote, identifique e volte novamente ao passo 1.2, onde vai explicar com as lacunas preenchidas. (caso ainda tiver dúvida, repita o mesmo processo até aprender).

2° Active Recall - Meu querido (O que eu faço)

Active recall seria o “método ativo”, iria forçar seu cérebro a relembrar assunto que estudou minutos ou horas atrás, um dos exemplos bem legais é o método feynman que expliquei anteriormente, mas vou explicar a forma que faço.

2.1 - Assista o vídeo até determinado ponto.

Se for uma videoaula (ou qualquer material que esteja usando viu), sempre que o professor concluir a explicação de um tópico e iniciar outro, pause o vídeo e anote apenas os principais tópicos.

Exemplo: o professor começa contando como foi a experiência dele na faculdade de Engenharia de Software. Em seguida, ele passa a explicar por que utilizou determinada linguagem de programação durante o curso. Assim que ele concluir esse assunto e antes de iniciar o próximo, pause o vídeo e anot*e os pontos PRINCIPAIS*, não sua explicação ainda.

Exemplo 2 (anotação) : Aqui ele explicou sobre sua experiência na faculdade. (pronto, escreve mais nada)

2.2 - Torra seu cérebro.

Não volte na sua vídeo aula, documentação e afins, olhe para o tópico anotado e tente lembrar com suas próprias palavras o que ele disse, sim, funciona até com código (é muito bom, mas dá um leve estresse kkk), você escolhe se fará anotação ou explicar com suas próprias palavras (feynman).

Conclusão

Na realidade existem vários métodos de estudos para cada cabeça, como disse no prólogo, autoconhecimento na jornada de programação já é um passo maravilhoso, não se cobre ou até mesmo se estressa demais durante os estudos, é NORMAL não saber de primeira, só não desista.

Agradeço a toda comunidade por sempre instigar a compartilhar nossos conhecimentos.

Como eu venci o medo da transição de carreira

Bárbara Martins da Silveira — Sun, 26 Jul 2026 19:12:49 +0000

Migrar de carreira para a área de tecnologia pode parecer difícil no início. O mercado está cada vez mais concorrido, além de estar passando por muitas transformações. Realizar a transição não é um processo fácil, mas é totalmente possível, mesmo que você esteja em uma área completamente diferente, ou atue há muitos anos em outro setor. Nesse artigo, compartilho como foi o meu processo, além de dar algumas dicas para quem está em transição ou pensando em iniciar a mudança de carreira.

Sumário

O início da jornada
Reconhecendo a insatisfação
Os primeiros medos
Lidando com críticas
A conquista da primeira vaga
Dicas para quem está em transição de carreira:

O início da jornada

Nessa semana completo 1 ano da minha transição de carreira. Sei que, para quem acompanha de fora, pode parecer que foi fácil ou que tive sorte em algum momento. Mas quem está na área de TI sabe o quanto esse processo é complexo. Ao olhar para trás, sinto como se passasse um filme na minha cabeça.

Reconhecendo a insatisfação

Desde o começo, a transição foi difícil: reconhecer que eu não estava satisfeita na carreira atual, lidar com rotina dupla, exaustão, críticas de pessoas próximas e o medo de recomeçar. Antes de iniciar meus estudos em tecnologia, minha rotina era insana e eu dormia poucas horas por noite. Até que percebi que não estava evoluindo e que a carreira para a qual me preparava já não fazia sentido. Foi então que decidi tirar do papel uma vontade que surgiu na pandemia, mas que o medo de começar havia travado: estudar tecnologia.

Os primeiros medos

No início, eu tinha medo de tudo: baixar uma IDE, mexer em código, enviar algo para o git, errar e falhar. Criar um post em rede social como o LinkedIn, então? Parecia absurdo compartilhar que eu estava tentando migrar de área. Mas mesmo com medo, iniciei e não deixei que minhas inseguranças me paralisassem. Consegui começar minha graduação online, muito mais flexível e adaptada aos meus horários, e descobri algo novo: a felicidade em evoluir e aprender sobre um assunto que eu realmente gostava.

Lidando com críticas

As críticas vieram. Algumas pessoas diziam que seria apenas um interesse passageiro, que eu estava desperdiçando meu curso anterior na federal, que era loucura iniciar algo novo nessa altura da carreira. Trabalhei isso em terapia e aprendi a ignorar opiniões que não acrescentavam nada.

A conquista da primeira vaga

Depois de 3 meses estudando, comecei a aplicar para processos seletivos, entender como funcionava o LinkedIn, criar posts, realizar conexões e focar nas áreas que realmente me interessavam. Foi um processo construído aos poucos, mas perdi o medo de escrever e meu perfil deixou de ser invisível. Aos poucos, as oportunidades começaram a aparecer e, em 6 meses de busca, conquistei minha tão sonhada vaga (claro que depois de muitos nãos). Mais do que isso: pude ajudar outras meninas que me procuraram em busca de dicas para ingressar na área, e isso é motivo de muito orgulho para mim.

Dicas para quem está em transição de carreira:

Comece com medo mesmo: no início, o processo é assustador, mas comece com medo mesmo. A primeira vaga é a mais difícil de conseguir.
Aceite que nem todos os dias serão bons: cada dia passado é um passo a menos até conquistar seu espaço.
Mantenha o LinkedIn ativo: mesmo que você não goste da rede, hoje praticamente todas as vagas passam por lá.
Invista em networking: em uma área tão concorrida, relacionamentos são até mais importantes que conhecimento técnico.
Participe de comunidades tech: as comunidades tech como a He4rt são espaços de troca de ideias, colaboração, eventos, engajamento e projetos open source. É o melhor lugar para trocar ideias, conversar com pessoas que estão passando pelo mesmo processo que você, além de participar de projetos reais que podem somar muito ao seu currículo.

Se você pensa em migrar de carreira ou está passando por esse momento agora, lembre-se: essa fase exige paciência e persistência, mas cada projeto, cada conexão e cada tentativa te aproximam do tão sonhado sim. Para quem já passou ou está passando pela transição para TI, quais foram seus maiores desafios e aprendizados? Compartilhe nos comentários! A sua experiência pode inspirar outras pessoas.

Começando com Redes: Camadas de uma conexão TCP/IP

Cristian Magalhães — Fri, 24 Jul 2026 12:37:44 +0000

Eae gente bonita, beleza? Depois de um longo período, resolvi voltar aqui e continuar compartilhando a minha trilha de estudos com vocês. Hoje vou começar (tentar pelo menos) uma série sobre redes.

Por que estudar redes

Começaremos com o porquê de aprofundar os estudos em redes. Conforme a sua senioridade vai aumentando, você vai ganhando novas responsabilidades para si e também dentro do ambiente de trabalho. Levando isso em consideração, ter o conhecimento básico de redes para poder ter mais autonomia e autoridade quando falar de cloud, arquitetura e coisas do tipo realmente não me parece ser uma má ideia. "Ah, mas na minha empresa tem devops que cuida disso", ainda assim, é necessário o mínimo de conhecimento teórico para conversar e até mesmo ajudar a entender o seu problema e criar soluções.

TCP/IP

Explicando a sigla basicamente, o modelo TCP/IP é um conjunto de protocolos de comunicação que permite a conexão e a troca de informações na internet.

O conjunto recebe o nome de seus dois protocolos principais:

IP (Internet Protocol) = Responsável pelo roteamento dos pacotes e endereçamento para que as informações cheguem ao seu destino.
TCP (Transmission Control Protocol) = Está presente na camada de transporte garantindo que nenhum pacote seja perdido ou corrompido.

Como funciona o modelo TCP/IP

Gosto muito de sair do escopo macro para o micro. Basicamente, uma conexão ocorre quando duas máquinas estão trocando informações (pacotes) entre si. E não precisa ser sempre dessa forma; também temos o caso (mais comum) em que uma máquina (cliente) pede informações a outra (servidor).

Ficou simples até demais, né? Para que a troca de informações funcione, existe uma série de passos a serem seguidos. Dentro de uma conexão existem algumas camadas, pelas quais a informação passa antes de chegar ao seu destino.

L7 = É a camada de aplicação, onde a aplicação roda e também onde roda o protocolo HTTP, SMTP.

L4 = Camada de transporte: responsável por garantir a entrega confiável dos dados entre a origem e o destino (é aqui que atua o TCP).

L3 = Camada de rede: responsável pelo roteamento dos pacotes e endereçamento até o destino (é aqui que atua o IP).

L2 = Camada de enlace: responsável por transmitir os quadros de dados entre dispositivos dentro da mesma rede, através do endereço MAC.

Isso é uma regra geral. A camada de cima sempre usa os recursos da camada de baixo para enviar as informações.

Importante lembrar: caso uma camada de baixo não funcione, a camada de cima também não funcionará.

O que é um pacote

Basicamente um pacote é uma carta ou mesmo uma "caixa" por onde as informações são trafegadas na internet. Além das informações requisitadas, nele constam também o remetente e o destinatário, da mesma forma que em uma carta.

Por fim...

Hoje falei um pouco sobre como funciona uma conexão, como é estruturada e como funciona todo o processo de troca de informações. Em breve trarei mais tópicos sobre o que existe dentro de uma mensagem HTTP e coisas do tipo.

Se chegou até aqui, me segue lá nas redes vizinhas.

Contribuir para a comunidade: como destacar isso no seu LinkedIn e currículo

vitoriazzp — Wed, 22 Jul 2026 18:11:09 +0000

Como eu mostro que estou contribuindo?
Posso colocar no meu LinkedIn?
E no meu currículo, como faço?

Foi a partir dessas dúvidas que eu elaborei esse guia pra você que quer contribuir do seu jeito e mostrar às empresas e às pessoas, de forma clara e estratégica, o que você está fazendo.

Vamos lá? 👇

Por que eu deveria mostrar no LinkedIn?

LinkedIn é a porta de entrada para o mundo corporativo no Brasil e no mundo. É por meio dele que você mostra "trabalho". E tem mais: não é só experiência remunerada que conta como evidência de que você tem conhecimento e prática, mas também tudo o que você constrói de forma voluntária, seja tirando dúvida de alguém, participando de um projeto open-source ou escrevendo sobre o que aprendeu. Recrutador não lê currículo pensando só em carteira assinada. Lê pensando em capacidade.

Você contribui com algo para a comunidade e quer colocar isso no seu perfil. Existem 3 formas que você pode usar, e elas podem ser usadas todas juntas ou só uma.

Escolha aquela que fizer mais sentido pro seu perfil ou busque por outras pessoas que você admira dentro da comunidade e veja como elas colocaram no próprio perfil.

1. Seção de Experiência

Use como experiência sempre que estiver contribuindo de forma profissional pra uma área que você busca. Se você participa de contribuições no GitHub, seja através de código, documentação ou outra forma, use como experiência.

Pessoas que também estão ajudando na moderação ou administração (community managers) podem destacar as responsabilidades ou resultados das suas ações por aqui.

Exemplo de como preencher no LinkedIn:

Cargo: [cargo que você faz] Open Source
Empresa: [Nome do projeto/organização]
Tipo de emprego: Meio período (ou Voluntário)
Local: Remoto, Brasil

Descrição:
- Contribuí com [X] pull requests na documentação do projeto [Nome],
  focando em clareza para novos contribuidores.
- Revisei issues abertas e sugeri melhorias de acessibilidade em
  componentes de UI usando [ferramenta/stack].
- Participei de reuniões semanais de planejamento com o time core
  do projeto.

Se estiver em dúvida sobre a sua atuação em algum projeto ou até especificamente sobre como colocar, comenta aqui ou chama a gente no Discord; ficaremos felizes em te ajudar.

2. Seção de voluntariado

Esse espaço é um pouco mais livre. Você pode usar pra mostrar que é membro da comunidade, moderador ou outro cargo que faça sentido e descreva sua participação. Não é necessário listar ou descrever o que você faz, só se quiser 🫣

Exemplo simples:

Organização: He4rt Developers
Função: Devloper Advocated
Causa: Ciência e tecnologia
Período: Março de 2025 - Presente

Descrição (opcional):
- Lidero o programa de advocacia da comunidade, conectando
  membros a oportunidades de conteúdo e mentoria.

Exemplo mínimo, sem descrição:

Organização: Friends of Figma Porto Alegre
Função: Voluntária (fotografia e recepção de convidados)
Período: 2025 - Presente

3. Seção de Projetos

Participa de um projeto específico da comunidade? Essa seção é a mais indicada pra você nesse caso, porque dá visibilidade às suas stacks e skills. Por isso é importante estruturar:

Nome do projeto
Prévia (print ou link do repositório)
Descrição do que é
Stacks que você aplica durante as suas contribuições
(opcional) Marque quem está no projeto com você

Exemplo:

Nome do projeto: Plataforma da He4rt 
Link: github.com/he4rt/heartdevs.com

Descrição:
Landing page da comunidade He4rt Developers,
Construída com identidade visual própria (roxo He4rt, dark mode).

Minha contribuição:
Design e desenvolvimento front-end da página, do wireframe
À implementação em PHP.

Stacks: Figma, React, Tailwind CSS, Claude Design

Depara: quem tem experiência x quem não tem

Um erro comum é achar que sem carteira assinada não tem o que mostrar. Não é bem assim. Muda a forma de descrever, não a legitimidade do que você fez.

Nos dois casos, a régua é a mesma: se você fez, pode mostrar. O que muda é o quanto de contexto você precisa dar pra quem está lendo confiar no que está escrito.

Segunda parada: currículo

É importante manter as mesmas informações que você tem no LinkedIn. Caso não tenha experiência formal, mas contribua pra comunidade, pode colocar diretamente na seção de experiência, com pelo menos 2 bullets do que você fez, como fez e qual foi o resultado.

Exemplo:

He4rt Developers (Tecnologia)
UI/UX Designer | Remoto, Brasil | Março 2026 - Presente

- Desenvolvi microcopy e fluxos de UI para funcionalidades internas
  da comunidade, aplicando princípios de acessibilidade e clareza.
- Colaborei com o time de desenvolvimento na construção da landing
  page de artigos, do wireframe em Figma à entrega final em React.

Exemplo pra quem já tem experiência formal em outra área e quer somar a contribuição:

Friends of Figma Porto Alegre (Comunidade)
Voluntária | Porto Alegre, Brasil | 2025 - Presente

- Apoiei a organização de eventos presenciais, atuando na recepção
  de convidados e registro fotográfico do evento.

Um modelo pra chamar de seu

Pra facilitar essa parte do currículo, criei um modelo que passa tanto pela leitura de um recrutador humano quanto por um ATS (o robô que filtra currículo antes de chegar em alguém). Ele serve tanto pra quem já tem experiência formal e quer só organizar melhor, quanto pra quem está usando a comunidade como primeira experiência pra registrar no papel.

Modelo Currículo (com e sem experiência) - Google Docs

docs.google.com

Contribuir pra comunidade é trabalho, mesmo sem salário no fim do mês. E o trabalho merece estar registrado em algum lugar que outras pessoas possam ver.

Se esse guia te ajudou a organizar como colocar sua contribuição no LinkedIn ou no currículo, conta aqui nos comentários:

Qual a sua maior dor hoje pra mostrar as suas contribuições no LinkedIn ou no currículo?