DEV Community: He4rt Developers

Produto 4 Devs

Renan Vidal Rodrigues — Thu, 16 Jul 2026 13:43:06 +0000

Todo Dev tem que entender que "ou tu aprende sobre Produto e Regras de Negócio ou tu vai ficar pra trás", o código é só 30% da resolução do problema!

Tabela de Conteúdo

1. Prólogo
2. O que é um Produto? (Sem enrolação)
3. Por que um dev deveria se importar?
4. Diferença entre Projeto e Produto
5. Ciclo de vida do Produto
6. O que importa o Dev entender do ciclo de vida do produto?
7. Conclusão
8. Se interessou?

1. Prólogo

Cada vez mais vejo que é essencial para um Dev ou para um time de desenvolvedores entenderem sobre Produtos e Regras de Negócio, pois é isso que mercado espera.

É como o Daniel (He4rt) Reis sempre fala o mercado espera Devs desenrolados que buscam entender as regras de negocio, do produto em si! Pois código é só 30% do trabalho, os outros 70% são a capacidade de entender o produto e debater sobre o mesmo.

Pensando nisso decidi escrever uma série de artigos focados em Produtos para Devs, buscando preencher uma lacuna comum nas equipes de desenvolvimento, buscando aproximar desenvolvimento e produto sem jargões ou excesso de teoria. Para ajudar aqueles que querem aprender sobre e também uma forma de sintetizar meus conhecimentos.

Mas você deve estar ai pensando:

"Mas Renan esse conteúdo faz sentido pra mim que estou começando a estudar programação agora?

E minha resposta é Sim, esse conhecimento é fundamental pra você, seja você uma pessoa que começou a estudar programação agora, um júnior, um pleno, um sênior, ou simplesmente alguém que está pensando em migrar de área. E novamente Sim esse conteúdo é para você ai, que quer se destacar e sair na frente de muita gente que pensa que hoje é só vibecodar e tudo vai dar bom!

Portanto vamos começar abordando o tópico que acho que é o que faz mais sentido para iniciarmos essa jornada que é:

2. O que é um Produto? (Sem enrolação)

Mas e ai o que é um produto de verdade? Um produto não é um software, pois um software pode ser apenas uma ferramenta, um produto é o valor real entregue ao usuário! Um produto é resolver um problema de negocio de forma sustentável!

Um Produto sempre, mais sempre mesmo só ira surgir para resolver um problema, uma dor, uma necessidade ou simplesmente satisfazer um desejo de um usuário ou um cliente. Seja esse usuário uma empresa ou um simples cliente.

Mas vale ressaltar que nem todo produto resolve uma dor intensa, muitas vezes alguns apenas amenizam essa necessidade, alguns ganham tempo, outros geram status ou entretenimento. Mas o mais importante é que sempre um produto entregam algum valor ao usuário.

Mas e o produto digital?
Agora que já entendemos o conceito básico de produto, podemos dizer que um Produto digital é qualquer software que tenha usuários e entregam algum tipo de valor a esse.

3. Por que um dev deveria se importar?

Essa é a pergunta de milhões que faz toda diferença e sua resposta é bem simples quando paramos para pensar que decisões técnicas que são tomadas pelo time tech impactam no negócio, que toda divida técnica também é uma decisão de de produto e que a performance, segurança e escalabilidade também são uma entrega de valor.

Tendo isso em vista podemos entender que um dev que se importa em entender as Regras do Negocio e entender o Valor que o Produto busca entregar, consegue enxergar qual caminho deve seguir, quais decisões devem ser levadas em consideração na construção da arquitetura de um produto, quais funcionalidades agregaram mais valor a experiencia do usuário, como um banco de dados deve ser modelado para poder atender a necessidade deste produto.

Além disso essa compreensão permite o dev questionar, debater e a elaborar planos de ação muito mais eficientes e que muitas vezes evitam muito retrabalho e refatoração de código, que muitas vezes aparecem pelo fato de você ter simplesmente ter "codado" uma funcionalidade sem entender todo o escopo do que o produto se propõem através da mesma.

Então jovens lembre-se entender o Produto evita retrabalho, e evitar retrabalho significa menos esforço e mais tempo para outras coisas que realmente valem a pena!

4. Diferença entre Projeto e Produto:

Agora que acredito que já desenvolvemos uma visão legal do que é Produto, agora podemos debater um pouco sobre a diferença entre um Projeto e um Produto. Claro que neste momento você deve estar se questionando: "Mais não é tudo a mesma coisa no final?" e foi esse mesmo pensamento que tive até entender que:

Projeto:

Tem seu escopo é fechado, muito bem delimitado e definido no planejamento, tendo um começo, meio e fim claramente definidos e desenhados, tem um foco na entrega com um caminho bem documentado e claro pode funcionar em cenários previsíveis.

Produto:

Já um produto tem um escopo mais aberto pois seu foco inicial é resolver uma problema e não o como, geralmente ele tem um começo e meio que podem ser identificáveis, mas seu fim não. Seu foco esta no resultado, tendo um objetivo bem definido, e para isso faz uso de experimentação, testes e validação de ideias (Discovery), que servem de guia para o caminho a ser seguido. E é indicado para cenários e contextos voláteis.

Então "não", uma nova funcionalidade não é um novo produto e sim um projeto, um produto é algo maior que vai possuir durante seu Ciclo de Vida alguns projetos (novas funcionalidades).

5. Ciclo de vida de Produto:

Por fim quero aborda um ponto que acho relevante de se ter pelo menos o conhecimento básico sobre. O Ciclo de vida do produto descreve todas as etapas pelas quais um produto passa dentro do mercado, desde seu lançamento até o seu fim por assim dizer.

Basicamente temos a fase Inovação que engloba desde o desenvolvimento do produto até sua entrada no mercado, onde seu foco inicial no mercado é buscar o Product Market Fit (Bem resumidamente são os clientes que se identificam com o produto), nessa etapa o perfil do usuário é composto por aqueles que são os Inovadores (Pessoas que estão usando o produto apenas por ele ser novo ou por apenas querer somente testa-lo) e pelo Primeiros Adeptos (São aqueles que realmente se identificam com o problema que o produto resolve logo de cara e servem muitas vezes como propagadores).

Temos também a fase Crescimento onde o foco é Growth (Processo contínuo de crescimento do produto no mercado por meio de melhorias no produto, novas funcionalidades e otimização da experiência do usuário). Aqui temos dos perfis de usuários a o que chamamos de Maioria Inicial que são aqueles que vem junto logo quando o produto começa a se popularizar no mercado e temos a Maioria Tardia que são aqueles que chegam depois que o produto já se estabilizou e começou a se consolidar.

E por fim temos a fase de Maturidade aqui nosso produto já se consolidou e mantem uma boa base de clientes fieis e continua entregando valor, daqui ou o produto se matem no mercado ou entra em Declínio.

No processo inicial de um produto logo após os Primeiros Adeptos antes da Maioria Inicial, temos um Abismo onde muitos produtos morrem, por não conseguirem cruzar esse abismo. E temos também um abismo após a maturidade uma quarta fase que que quando não conseguimos seguir inovando que é Descontinuar um produto ou Morrer, matar o produto, o sunset.

6. Mas o que importa o Dev entender do ciclo de vida do produto?

Saber o ciclo de vida do produto pode te ajudar a entender em que fase o produto em que você vai estar trabalhando pode estar e o quanto de esforço e investimento será empregado em cada fase. O quanto o processo de Discovery será necessário para mapear novas funcionalidades e melhorias de fluxos. E o que pra mim faz bastante sentido quando você pode propor alguma melhoria, nova funcionalidade ou até mesmo a ideia de um novo produto!

Pois um Dev que tem capacidade de ajudar um produto crescer ou até mesmo a capacidade de propor um novo produto, sempre será um Dev diferenciado no mercado! (Claro quando esse tipo de atitude é valorizada)!!!

7. Conclusão:

Nesse artigo entendemos um pouco mais sobre produtos, o que impacta na vida do Dev entender sobre o assunto, a diferença entre um projeto e um produto e compreendemos um pouco sobre o ciclo de vida do produto.

Tudo isso pra tentar ajudar você a ser um pouco mais um Dev Desenrolado, que tem uma visão mais macro do processo que vai muito além do Código.

8. Se interessou?

Eu sou o Renan Vidal, trabalho como Product Owner já a algum tempo e agora estou estudando para migrar mais ainda para a área de produto, e com tudo que venho estudando e com toda experiencia que já tenho de mercado, e posso te dizer com alguma certeza que um Dev que se preocupa entender sobre Produtos e Regras de Negocio está na frente de muita, mas muita gente mesmo.

Espero que tudo que escrevi aqui tenha algum sentido para pelo menos uma pessoa, e no caso de duvidas ou se deseja que eu aborde algum tópico de produto mais aprofundada é só deixar seu comentário!

Métricas de qualidade de software na era da IA

Alicia Marianne Gonçalves — Thu, 16 Jul 2026 00:12:21 +0000

Não é novidade para ninguém que estamos passando por uma transformação na área de desenvolvimento de software, em que a IA está assumindo diversas atividades. E isso me faz pensar: o que vamos medir, ou o que teremos como parâmetro para qualidade de software daqui pra frente? É sobre isso que vou falar neste texto.

Antes das métricas: entenda o momento do seu time

Antes de entrarmos nas métricas em si, precisamos entender o momento em que o nosso time está. É muito fácil eu simplesmente jogar métricas aqui e você aplicá-las ao seu time de maneira automática — mas será que elas fazem sentido para o seu contexto?

Uma coisa que eu falo bastante aos meus alunos da mentoria que dou na He4rt Developers é: pra que eu quero isso? Softwares representam necessidades do mundo real, logo, medir o sucesso e a qualidade deles vai depender muito das necessidades que eles buscam suprir.

Partindo agora para as métricas, eu gosto de dividi-las em dois grupos:

Métricas para stakeholders
Métricas para o time

Qualidade de software não se resume a número de bugs — ela se aplica tanto em como o software é recebido pelo cliente final, quanto em como ele é desenvolvido.

Métricas para stakeholders

Uma coisa que eu aprendi neste tempo na empresa em que tenho atuado, principalmente com a transformação digital, é que mostrar número de bugs abertos ou resolvidos não mostra para o público o que realmente importa: como está a qualidade do produto. E, para me ajudar nisso, eu sempre tento me colocar no lugar de um cliente que não tem conhecimento profundo sobre o ciclo de desenvolvimento de software.

A primeira coisa que eu gostaria de ver quando um QA, ou o time, vier me mostrar os resultados de uma sprint ou de um quarter é: quantos problemas eu tenho em produção — mas não só isso, quanto tempo tenho levado para resolvê-los.

Mean Time to Resolve/Repair (MTTR)

Essa é a famosa métrica que vai mostrar o tempo que leva desde que o problema é identificado até ele ser resolvido em produção. Dependendo de como é o seu processo de desenvolvimento, isso pode ser medido de formas diferentes. Se você tem um processo em que o cliente primeiro reporta para o suporte, o suporte faz uma pré-avaliação e só depois disso o problema vai para o time resolver, você pode medir em dois momentos: o tempo que o suporte leva para avaliar o problema e dar um primeiro parecer, e o tempo em que esse ticket de suporte de fato se torna um bug e entra na esteira de resolução.

Cobertura de testes automatizados

Outra métrica interessante de se mostrar para um time de stakeholders é a quantidade de testes automatizados — porém, não isolada. Acho que você já deve estar cansado de ouvir que ter 99% de cobertura de testes não significa qualidade, mas como posso apresentar essa métrica ao stakeholder de forma que ele veja o valor do investimento em automação que o seu time está fazendo?

Uma coisa importante a analisar nesse contexto é se a cobertura de testes está realmente pegando os cenários importantes do sistema. Exemplo: se, no seu contexto, o seu MTTR está alto mas a sua cobertura de testes está alta, isso significa que a sua cobertura não está cobrindo o que realmente precisa ser coberto.

DORA Metrics

Além dessas, as DORA Metrics são grandes aliadas para auxiliar nesse diagnóstico.

As DORA Metrics (DevOps Research and Assessment, hoje parte do Google Cloud) nasceram para medir a performance de entrega de software, mas, na prática, funcionam como um termômetro da qualidade do processo como um todo — porque times que entregam rápido e com poucos incidentes são times com um pipeline de qualidade (testes, revisão, observabilidade) bem construído.

Fonte oficial: dora.dev — pesquisa contínua do DORA (Google Cloud) sobre as métricas e capacidades que diferenciam times de alta performance. Vale a leitura direta da fonte para acompanhar atualizações do modelo, como a inclusão de Reliability como quinta métrica.

Deployment Frequency (Frequência de Deploy)
Com que frequência o time coloca código em produção. Deploys menores e mais frequentes são mais fáceis de testar e, se algo der errado, mais fáceis de isolar a causa — menos mudanças acumuladas por deploy significa menos variáveis para investigar. Uma frequência de deploy caindo pode ser sintoma de um time com medo de quebrar produção, geralmente por falta de confiança nos testes.

Lead Time for Changes (Tempo entre o commit e a produção)
Tempo desde que uma mudança é commitada até ela estar rodando em produção. Um lead time alto muitas vezes esconde um gargalo em etapas de validação manual demoradas, ou retrabalho por bugs encontrados tarde no ciclo. É uma métrica que expõe se o teste está acontecendo cedo (shift-left) ou só no fim, represando a entrega.

Change Failure Rate (Taxa de Falha em Mudanças)
Percentual de deploys que causam falha em produção (incidente, rollback, hotfix). É, de longe, a métrica DORA mais diretamente ligada à qualidade do processo de teste. Está diretamente relacionada à cobertura de testes: se essa métrica está alta, significa que a sua cobertura de testes está baixa ou, como dito anteriormente, não está cobrindo o que realmente precisa ser coberto.

Time to Restore Service (Tempo de Restauração)
Tempo médio para restaurar o serviço depois de um incidente em produção (rollback, hotfix, correção de configuração). Mede a capacidade do time de reagir quando — não se — algo dá errado. QA pode influenciar diretamente essa métrica ajudando a desenhar testes de rollback, feature flags e smoke tests pós-deploy que aceleram a detecção e a decisão de reverter.

Reliability (Confiabilidade — métrica mais recente do modelo DORA)
O quanto o sistema atende às expectativas de disponibilidade e performance do usuário no dia a dia, não só durante incidentes. Conecta a qualidade percebida pelo usuário com o trabalho de teste não funcional (performance, disponibilidade) — é o lembrete de que qualidade não é só "não ter bug", é o sistema se comportar bem sob uso real.

Métricas para o time

As métricas para stakeholders ajudam bastante o time a ver o estado daquilo que estão produzindo, mas, às vezes, você quer enxergar a qualidade no próprio processo de desenvolvimento do software. Aqui podemos ter métricas mais pontuais.

Root Cause Analysis

São métricas que ajudam a ver os padrões dos problemas que acontecem no software ou durante o desenvolvimento e, a partir delas, pensar em planos de ação. Exemplo: se eu tenho muitos problemas relacionados a falta de requisitos, posso deixar os requisitos mais explícitos nas tarefas e, daqui a 2 ou 3 sprints, validar se esse tipo de root cause se tornou menos frequente ou não.

Bugs identificados antes do lançamento

Existem algumas métricas que você também pode extrair relacionadas a bugs, como: quantos bugs foram identificados antes mesmo de lançarmos a feature em produção? Isso pode ser alimentado tanto pela execução de testes manuais quanto por testes automatizados que falharam ao adicionar uma nova feature.

Retrabalho

É possível também calcular o retrabalho, uma métrica que vai te ajudar tanto a ver se o número de bugs está aumentando ou não quanto no planejamento. Quando o seu time costuma ter uma taxa de retrabalho de 10%, é possível alinhar com os Product Owners 10% de margem dentro de uma sprint para possíveis bugs. Assim, o planejamento se torna mais realista, as expectativas ficam alinhadas, e o cliente e o time ficam mais felizes.

Conclusão

Com essa transformação digital, é importante entendermos que temos métricas que podem nos auxiliar a medir o ciclo de desenvolvimento e a qualidade do produto — e o principal é que nenhuma delas, isoladamente, traz valor. Elas precisam ser lidas em conjunto, cruzadas entre si, e sempre voltando para aquela pergunta inicial: pra que eu quero isso?

Com a IA aumentando a produção de código, a tendência é termos mais código sendo escrito, mais features sendo entregues e mais decisões sendo tomadas em menos tempo. E é justamente por isso que medir vai se tornar ainda mais importante do que já é hoje: se antes um time levava dias para gerar uma quantidade de código que hoje pode ser gerada em horas, os erros também podem se multiplicar na mesma velocidade — só que muitas vezes invisíveis até chegarem em produção.

Por isso, acho que o papel do QA nesse novo cenário não é só testar mais rápido para acompanhar o ritmo da IA, mas também ser a pessoa que garante que estamos olhando para os números certos. Não adianta ganhar velocidade e perder visibilidade sobre o que está sendo entregue. Então, o convite que eu deixo é: olhe para essas métricas não como números para preencher um dashboard, mas como perguntas que elas estão te fazendo sobre o seu processo. E use a IA para te ajudar a responder essas perguntas mais rápido — não para substituir o hábito de perguntar.

Como escolher eventos de tecnologia para participar

vitoriazzp — Mon, 13 Jul 2026 17:45:47 +0000

Quando comecei a ir a eventos de tecnologia, estava na faculdade e ia a todos os gratuitos ou que custavam, no máximo, 100 reais. Porém, eu estava começando em TI e sabia tão pouco sobre a área em que eu queria atuar, logo qualquer evento despertava minha curiosidade.

Os anos passaram e eu me tornei frontend e passei a participar de eventos como front in (sampa, floripa, poa), TDCs, Roadsec (the mind sec) entre outros aí.

Por que ir a esses eventos?

Desde que comecei a fazer freelance e me formei, percebo que é onde eu descubro as tecnologias e os problemas que as pessoas têm percebido. Também é uma forma prática de eu sair da minha zona de conforto e conhecer pessoas, visões de mundo diferentes e voltar com ideias pros meus serviços.

Quando eu estava na faculdade, era muito mais simples ter essas duas "pontes" de comunicação e também de venda de solução. Após me formar e começar a trabalhar, percebi que a prospecção de clientes seria muito mais difícil se eu não estivesse nesses eventos.

Mas Vih, eu estou estudando, não estou mirando em freelance, do que me adianta ir?

Adianta que você conhece pessoas, faz amigos ou pessoas que vão te contratar ou indicar em trabalhos futuros. Além das palestras que podem te mostrar uma área dentro de TI que você ainda não conhecia e pode acabar gostando.

Como eu escolhia os eventos que iam fazer diferença pra mim?

1) Eu tinha uma lista de assuntos e áreas de que eu gostava ou que acompanhava já nas redes sociais, exemplo:

- frontend: flutter, react, html/css, boas práticas, realidade aumentada
- segurança da informação: hacks, boas práticas, curiosidades etc
- backend: qualquer stack pra se atualizar
- design ihc, ux, produto, estratégia, marketing

2) Seguia no Instagram as pessoas dessas áreas, que às vezes eram as mesmas que participavam dos eventos, por exemplo:

@juliallabs
@stherzada
@danielhe4rt
@spacecoding
@nataliafdev
@omarcusdev
@dessadev

Esses são alguns dos exemplos que eu mais acompanhava no Instagram, algumas pessoas também têm perfil nesta plataforma, mas o conteúdo sobre eventos está no Insta!

3) Tinha uma noção do custo de alguns eventos, e quais eu podia arcar, quais eu precisava pra me atualizar ou fazer networking específico:

Conferências até R$ 1.500;
Eventos/meetups de R$ 0 a 600; > Ter a meia-entrada ou o ingresso solidário ajudava a pagar menos; às vezes, a faculdade ou o emprego pagava a entrada em troca de trazer o conteúdo aplicado. Vale consultar a disponibilidade pra economizar.

Mas qual a diferença entre conferência, eventos, meetups?

Conferência costuma ser um evento amplo; faz-se pra apresentar conteúdos específicos, e o público costuma ser de empresas que levam o funcionário ou de pessoas que já estão no mercado e conseguem arcar com o custo do ingresso.
Eventos podem ser pagos ou gratuitos; costumam ser organizados por empresas, mas às vezes comunidades também.
Meetups são frequentemente organizados por comunidades e podem ou não ter custo; depende do lugar em que acontecem.

Onde eu posso achar eventos de tecnologia?

Existem os sites de venda de ingresso como

Summits são mais voltados para empresas ou empreendedores; os valores são bem altos, mas consegue desconto dependendo da tua empresa ou faculdade. Vale a pena se pretende atuar em algum setor muito específico.

E você? Como costuma escolher quais eventos de tecnologia ir?

Ownership: do "temos um rojão na mão" até "não precisa mais pensar nisso"

Daniel Reis — Wed, 08 Jul 2026 17:25:50 +0000

É aquele famoso "ou faz direito ou não faz" que todo dev deveria respeitar desde o inicio dos seus estudos.

Tabela de Conteúdo

1. Prólogo
2. Entenda o problema real
3. Projete antes de codar
4. Execute
5. Verifique (em produção)
6. Comunique
7. Acompanhe
É muita coisa. E olha que ainda tem mais.

1. Prólogo

Acho que toda vez que eu vejo um dev iniciante, meu primeiro pensamento é: a hora de "criar" responsabilidade é literalmente agora, no inicio da carreira. Por exemplo: quando eu era junior eu pegava task, escrevia o código, mandava o Pull Request, que era mergeado e ia dormir feliz. Três dias depois o problema voltava, do mesmo jeito, e adivinha quem teve que mexer de novo? Eu. Por anos eu continuei fazendo aquilo, esquecendo daquela frase clichê de que: "30% do trabalho é de fato código". Mas ai de fato, quais são os outros 70%?

Quando comecei a me perguntar isso, simplesmente entendi que: eu tinha entregado um código, por anos não tinha resolvido um problema. E é sobre isso que a gente vai falar hoje.

Eu uso muito a palavra ownership. Vivo falando "você pode assumir isso?", "consegue cuidar disso?", "tá com você?" e faz um tempão que eu não paro pra explicar o que ownership significa pra mim. Então bora lá, que hoje o assunto é esse.

Quando eu te pergunto "você pode assumir isso?", presta atenção: eu não tô te pedindo pra escrever um código e mandar um PR. Eu tô te pedindo pra ser dono da solução de um problema, de ponta a ponta. Do "temos um problema" até o "não precisa mais pensar nisso".

E cara, isso muda TUDO. Assumir uma tarefa é entregar um código. Assumir um problema é garantir que ele deixou de existir, e que ninguém, você inclusive, vai precisar voltar a pensar nele nunca mais. Quando você fala que tá resolvendo alguma coisa, a expectativa é que você faça essa porra toda que vem abaixo. E ó, não é papo de gestão não: dominar isso é o que faz o time te dar problema cada vez maior sem medo. É basicamente o cheat code pra virar sênior de verdade, não sênior de tempo de casa.

2. Entenda o problema real

Antes de qualquer linha de código, tenha CERTEZA de que você sabe o que tá resolvendo.

O erro mais comum do mundo é começar pela solução. Você provavelmente já tem uma na cabeça sem ter parado 5 minutos pra pensar no que a gente tá de fato tentando resolver. Se você acha que "o problema é que precisamos migrar de X pra Y", pera aí mano, isso não é um problema, isso é uma solução. O problema de verdade é algo tipo "a performance tá uma merda", "não é estável", "quebra pro cliente X".

"Migrar do MySQL pro Postgres" é solução.
"A busca de membros da comunidade demora 8 segundos" é problema.

Sacou a diferença? Beleza. Uma vez que você tem o problema real na mão, a próxima pergunta é: será que existem outras soluções possíveis? Pensa nelas. Um índice resolve? Um cache resolve? Reescrever aquela query zoada resolve, antes de trocar o banco INTEIRO? Cada caminho tem seus tradeoffs. Qual é o melhor levando isso em conta?

Se você pular essa fase, você corre o risco de passar duas semanas construindo a solução perfeita pro problema errado. E aí não tem PLAU que salve.

Nosso caso (a busca de 8s): o problema não é "migrar pro Postgres". É "a busca de membros demora 8 segundos". Antes de trocar de banco, será que um índice não mata isso?

3. Projete antes de codar

É aqui que a maioria dos problemas de produção nasce: nas perguntas que ninguém fez antes de começar. Então vamo fazer elas agora.

Pensa nos edge cases. Quais são? Quais são importantes? Quais dá pra ignorar de propósito (e deixar registrado que você ignorou)? Membro sem avatar, nome com emoji, lista vazia, fuso horário diferente do servidor. Escolher o que ignorar é uma decisão consciente; ignorar sem perceber é um bug esperando a hora de estourar na sua cara.

Pensa nas falhas. Falha de rede, por exemplo, é GARANTIDA. Como a gente lida com ela? Retry? Tá, mas com que frequência? Por quanto tempo? O webhook caiu: retry com backoff? três tentativas? e depois, descarta ou joga numa fila de reprocesso?

Pensa no fluxo de dados. Quanto dado tá envolvido? Precisa migrar algo? Limpar algo? Como você consegue dado de verdade pra testar direito? Quais invariantes existem nos dados? E principalmente: quais premissas sobre o formato dos dados você tem e ainda não confirmou? "Todo membro tem e-mail"... você checou isso na base ou só assumiu e foi feliz?

Pensa em como você vai testar. Como você vai saber se o que construiu tá certo? Testes automatizados bastam? Precisa cutucar na mão? A diferença aparece num screenshot ou num vídeo? Um bug de dark mode não aparece em teste unitário, meu amigo. Aparece num print.

Pensa em como isso vai ser anunciado. Como a gente comunicaria? Você consegue visualizar o anúncio? Como isso se encaixa no quadro maior do roadmap? Dúvida ou preocupação nessa área? Questiona, pergunta, dá um push back. Se você não consegue escrever o anúncio em duas frases, o escopo provavelmente ainda tá bagunçado.

Nosso caso: e se o membro não tiver avatar? E se a busca vier vazia? E se caírem 50 mil membros de uma vez? Anota tudo isso ANTES de codar.

4. Execute

A fase mais curta de descrever e a mais longa de viver. O padrão é um só, e é simples.

Faça o trabalho com precisão, com cuidado, com senso de urgência e com calma. Não faça nada pela metade. E ó, urgência aqui não é pressa afobada não: é não deixar o problema esperando por você, sem sacrificar o cuidado no caminho.

E tem um teste antes de dar merge, o meu favorito:

Eu tenho orgulho disso?
Eu mostraria isso pro John Carmack (o lendário programador do Doom e Quake) e falaria: "foi isso que eu construí, com essas restrições, com esses tradeoffs"?

Se a resposta for não, sinto muito, mas ainda não terminou.

Nosso caso: boto o índice, reescrevo a query zoada, testo local. Caiu de 8s pra 120ms. Tenho orgulho disso? Tenho.

5. Verifique (em produção)

Terminar de codar NÃO é terminar. Terminar é o problema resolvido, rodando, no ar. Anota isso.

Testa na mão. Sim, existem testes automatizados. Mas Daniel, se eu tenho teste automatizado, pra quê testar na mão? Porque teste passa e feature quebra, meu amigo. São coisas diferentes. Em 99% dos casos você consegue confirmar na unha que o que construiu funciona: rodando você mesmo, pedindo pra um agente percorrer os cenários, cutucando os dados antes e depois, tirando screenshots, gravando uma demo. Você tem certeza que resolveu o problema? Roda o fluxo inteiro como se fosse o usuário: cria a conta, dispara a ação, confere o resultado no banco.

Garanta que chegou em produção e funciona lá. Tá deployado? O deploy quebrou? Precisa ativar alguma feature flag? A flag funciona mesmo? Dá pra usar em produção? Você consegue confirmar que tá de fato no ar? "Mergeou" não é "shipou", tá ligado? Abre a produção e usa a feature você mesmo.

Nosso caso: subo pra produção, abro EU MESMO e busco "daniel". Os 8s viraram instantâneo de verdade, com dado real, não só no meu localhost feliz.

6. Comunique

Código que ninguém sabe que existe gera bug que ninguém sabe explicar. Comunicação é parte do trabalho, não é um extra que você faz se sobrar tempo.

Seus colegas precisam saber? É uma feature nova que todo mundo deveria testar? Uma convenção nova no código? Uma coisa traiçoeira que todos precisam conhecer? Avisa. Não subestima a visão periférica do time: saber que a pessoa X mudou ontem o comportamento de como Z funciona pode economizar TRÊS HORAS de debug da pessoa Y amanhã. Mudou como o cache de sessão funciona? Uma mensagenzinha no canal do time hoje vale três horas de debug de outra pessoa amanhã. É de graça, faz.

Os clientes precisam saber? Quem reportou o bug? Quem tá bloqueado esperando isso? Avisa essas pessoas. Responde a thread de quem abriu a issue: "saiu na versão de hoje, pode testar aí".

O mundo precisa saber? Anuncia que saiu. Changelog, post no canal de announcements, tweet, o formato que fizer sentido pro tamanho da mudança.

Nosso caso: mando no canal do time: "a busca de membros tava 8s, agora tá instantânea, quem reclamou pode testar". E respondo a thread de quem abriu a issue.

7. Acompanhe

Ownership não termina no deploy. Termina quando NINGUÉM mais precisa pensar naquilo, você incluso.

Tem follow-ups? Você precisa dar uma olhada nos logs pra ver como tá aquilo que shipou? Uma semana depois, quem sabe? Agenda um lembrete: "conferir a taxa de erro do endpoint novo na sexta". O ciclo só fecha de verdade quando você tem certeza que o problema ficou resolvido e continuou resolvido.

Nosso caso: sexta que vem eu volto no log pra confirmar que a busca continuou rápida mesmo com a base crescendo. Aí sim o ciclo fechou.

É muita coisa. E olha que ainda tem mais.

Sim, é muita coisa, eu sei. E na real ainda tem mais, porque com certeza a gente esqueceu algum item aqui no meio.

Mas mano, é assim que se constrói produto em time pequeno. A gente não tem PM, não tem departamento de QA pra passar a bola. Somos pequenos, mas somos bons, e a gente dá conta dessa porra toda.

E ó, é SEMPRE ok pedir ajuda. É ok fazer pergunta. É ok refazer e conferir três vezes. O que não é ok é assumir, lá no fundo sem falar pra ninguém, que outra pessoa vai fazer as coisas que você não pensou.

Da comunidade para a comunidade.

Bebe água, me segue nas redes sociais e a gente se vê no próximo artigo!

De 6 horas para 40 segundos: como um índice de banco de dados salvou um job crítico de produção

Fernando Andrade — Sat, 06 Jun 2026 20:19:13 +0000

De 6 horas para 40 segundos: como um índice de banco de dados salvou um job crítico de produção

"Às vezes, a solução mais elegante não está no código está em ensinar o banco de dados a encontrar o que ele já tem."

Índice

O cenário: um job noturno que virou um problema diurno
O problema cresceu junto com a tabela
O diagnóstico: o Azure Application Insights apontou o caminho
A solução: um índice bem posicionado
O impacto real: economia de tempo total por dia
Mas afinal: o que é um índice de banco de dados?
Como identificar quando você precisa de um índice
Anatomia do índice que resolveu o problema
Conclusão

O cenário: um job noturno que virou um problema diurno

Todo sistema que lida com monitoramento contínuo eventualmente enfrenta o mesmo desafio: quanto mais dados acumulam, mais lenta fica a análise. Foi exatamente isso que aconteceu em um projeto no qual trabalhei.

A arquitetura era simples na teoria: um job agendado rodava durante a madrugada, disparando N processos paralelos cada um cadastrado individualmente pelo cliente. A lógica de cada processo era fazer uma comparação entre o resultado do dia atual (D+0) com o resultado do dia anterior (D-1), algo como:

"O que mudou desde ontem?"

Para isso, cada processo precisava buscar seu último resultado registrado, usando uma query com ORDER BY last_execution DESC filtrada pelo identificador do processo. Parece trivial. E durante um bom tempo, foi.

O problema cresceu junto com a tabela

Com o tempo, a tabela de resultados foi crescendo naturalmente, afinal, cada processo registra um novo resultado a cada execução. O que antes demorava milissegundos começou a demorar segundos. Depois, dezenas de segundos. Até que um dia percebemos:

A janela de execução do job, que deveria ser de até 4 horas, estava chegando a 12 horas.

Isso significava que um job que deveria terminar antes do horário comercial estava ainda em execução quando os usuários começavam a trabalhar de manhã, gerando inconsistências, bloqueios e reclamações.

A pergunta era: onde estava o gargalo?

O diagnóstico: o Azure Application Insights apontou o caminho

Ao analisar as métricas de performance no Azure Application Insights, ficou evidente que o problema estava concentrado em uma única operação: a query que buscava o último resultado de cada processo.

Internamente, a tabela de resultados tinha crescido o suficiente para que um ORDER BY last_execution DESC sem suporte de índice forçasse o banco a fazer um full scan, ou seja, varrer linha por linha até encontrar o registro mais recente. Multiplique isso por dezenas (ou centenas) de processos rodando em paralelo e você tem uma receita para o caos.

Antes da correção

1 linha(s) recuperada(s) — 1.754s, em 2025-08-11 às 09:19:01

Quase 2 segundos por consulta. Para um único processo, tolerável. Para N processos simultâneos, catastrófico.

A solução: um índice bem posicionado

A correção foi aplicar um índice composto na tabela de resultados, cobrindo exatamente os campos usados na query crítica:

CREATE INDEX idx_job_result_process_date
  ON app_schema.job_results (fk_process_id, date_created DESC)
  INCLUDE (id, final_result, report_id, result_payload);

Esse índice foi criado diretamente no ambiente de produção (pode ser gerado localmente também, dependendo da política da equipe) e o resultado foi imediato.

Depois da correção

1 linha(s) recuperada(s) — 0.003s, em 2025-08-11 às 09:32:00

De 1,754 segundos para 0,003 segundos por consulta. Uma redução de 99,8% no tempo de resposta.

O impacto real: economia de tempo total por dia

Cenário	Tempo acumulado de processamento/dia
❌ Antes do índice	~6 horas e 18 minutos
✅ Depois do índice	~40 segundos

O job voltou a terminar bem antes do horário comercial. Os processos diurnos pararam de ser impactados. E tudo isso sem reescrever uma linha de código de negócio.

Mas afinal: o que é um índice de banco de dados?

Se você chegou até aqui e nunca parou para entender o que um índice faz de verdade, esse é o momento.

A analogia do livro

Imagine que você tem um livro enciclopédico com 10.000 páginas e precisa encontrar tudo que fala sobre "fotossíntese". Você tem duas opções:

Sem índice: Ler página por página do início ao fim. Funciona, mas demora.
Com índice: Ir até o índice remissivo no final do livro, localizar "fotossíntese" em segundos e ir direto às páginas certas. Um índice de banco de dados funciona exatamente assim. Ele é uma estrutura de dados separada (geralmente uma B-Tree) que mantém uma cópia ordenada de uma ou mais colunas, com ponteiros para as linhas reais da tabela.

O que um índice resolve?

Buscas por igualdade: WHERE id = 42 o índice encontra o valor direto, sem varrer a tabela
Buscas por intervalo: WHERE date_created BETWEEN '2025-01-01' AND '2025-12-31'
Ordenação: ORDER BY last_execution DESC se o índice já estiver ordenado nessa direção, o banco nem precisa ordenar
Queries cobertas (covering index): Com a cláusula INCLUDE, o banco pode responder à query inteira só pelo índice, sem nem tocar na tabela original ### O que um índice não é (e quando ele atrapalha)

Índice não é gratuito. Ele tem custos:

Espaço em disco: o índice ocupa armazenamento adicional
Custo de escrita: toda vez que um INSERT, UPDATE ou DELETE acontece, os índices afetados também precisam ser atualizados
Manutenção: índices fragmentados precisam ser reorganizados periodicamente Por isso, criar índices sem critério pode ser tão prejudicial quanto não tê-los. A regra de ouro é:

Crie índices nas colunas que aparecem frequentemente em cláusulas WHERE, JOIN, ORDER BY e GROUP BY de queries lentas, especialmente em tabelas grandes.

Como identificar quando você precisa de um índice

Alguns sinais de alerta:

Queries que demoram mais conforme a tabela cresce (como o nosso caso)
Full table scans aparecendo nos planos de execução (EXPLAIN / Query Execution Plan)
Timeouts em operações que antes eram rápidas
CPU do banco de dados consistentemente alta durante períodos de consulta Ferramentas como o Azure Application Insights, pg_stat_statements (PostgreSQL), slow query log (MySQL) e o Query Store (SQL Server) são aliadas valiosas nesse diagnóstico.

Anatomia do índice que resolveu o problema

Voltando ao índice criado:

CREATE INDEX idx_job_result_process_date
  ON app_schema.job_results (fk_process_id, date_created DESC)
  INCLUDE (id, final_result, report_id, result_payload);

Por que esse design?

Componente	Motivo
`fk_process_id`	Filtro principal da query (cada processo tem seu identificador)
`date_created DESC`	A query precisa do resultado mais recente primeiro
`INCLUDE (...)`	Colunas retornadas pela query, incluí-las evita um segundo acesso à tabela

O resultado é um covering index: o banco responde à query inteira consultando apenas o índice, sem precisar buscar dados na tabela principal. É a forma mais eficiente de otimização de leitura possível.

Conclusão

Performance não é só sobre algoritmos ou arquitetura de microsserviços. Às vezes, o gargalo está numa operação aparentemente simples que o banco de dados precisa executar milhares de vezes por dia, e que ninguém percebe até que o custo acumulado se torne um problema real.

Nesse caso, um único índice bem pensado transformou 6 horas de processamento em 40 segundos. Sem refatoração. Sem mudança de arquitetura. Sem downtime.

Se você ainda não tem o hábito de revisar os planos de execução das suas queries críticas, comece agora. O banco de dados tem muito a te contar, basta saber ouvir.

Sugestões de leitura para se aprofundar: B-Tree indexes, covering indexes, query execution plans, índices compostos e ferramentas de profiling como EXPLAIN ANALYZE.

Por que eu começo 10 projetos e não termino nenhum?

Yuri Souza — Sun, 05 Apr 2026 23:48:52 +0000

Você já passou uma tarde inteira configurando um projeto novo, escolhendo a stack, criando o repositório, estruturando as pastas e sentiu que estava voando? Aquela sensação de que dessa vez vai ser diferente, que essa ideia é boa demais pra morrer na gaveta? Eu também. O problema é que dois dias depois eu estava fazendo exatamente a mesma coisa, só que com outra ideia.

Se você se identificou, esse artigo é pra você. Não porque eu tenho a solução mágica, mas porque finalmente entendi o mecanismo por trás disso. E entender já muda muita coisa.

O prazer de começar
O momento em que tudo desmorona
O objeto brilhante
A culpa que ninguém fala
Não é preguiça. É neurologia.
Conclusão

O prazer de começar

Tem algo muito específico que acontece quando você começa um projeto novo.

O problema ainda não existe de verdade. Tudo é possibilidade. Você ainda não encontrou o bug impossível de reproduzir, ainda não percebeu que a arquitetura que escolheu não escala, ainda não chegou na parte chata de fazer o CRUD de usuário pela décima vez na vida.

Nessa fase, o cérebro libera dopamina. Bastante. A antecipação de uma recompensa futura ativa os mesmos circuitos que uma conquista real. Ou seja: só de imaginar o projeto funcionando, você já sente parte da recompensa.

Isso explica o prazer visceral do setup. Escolher o nome do repositório, montar a estrutura de pastas, escrever o README antes de ter uma linha de código que funciona... tudo isso alimenta aquela sensação.

O problema? É que ela passa.

O momento em que tudo desmorona

Existe um ponto específico em todo projeto onde a magia some. Eu chamo de o vale do tédio.

É quando você já sabe o que precisa fazer, mas o trabalho deixou de ser estimulante. As decisões arquiteturais foram tomadas. O setup tá pronto. Agora é só... executar. Implementar a feature chata. Escrever o teste. Lidar com o caso que você não previu.

Para a maioria das pessoas, esse momento é desconfortável mas passável. Você empurra, entrega, segue.

Para alguns cérebros, incluindo o meu, esse momento é quase fisicamente doloroso. Não é falta de vontade. É que o sistema de recompensa do cérebro simplesmente não libera o combustível necessário pra continuar uma tarefa que deixou de ser nova.

E aí começa o ciclo de autos sabotagem mais clássico do mundo do dev:

"Antes de continuar, vou refatorar essa parte aqui."

"Preciso repensar a arquitetura antes de avançar."

"Deixa eu criar um boilerplate melhor pra usar nos próximos projetos."

Você não está sendo preguiçoso. Você está inconscientemente procurando a dopamina do recomeço dentro do próprio projeto.

O objeto brilhante

E então aparece. Uma ideia nova.

Pode ser um problema que você viu no trabalho, uma conversa no Twitter, um repositório no GitHub que te inspirou. De repente, aquela ideia nova parece muito mais interessante do que o projeto que você abandonou no vale do tédio.

E ela realmente é, pelo mesmo motivo que o projeto anterior era interessante no início. Ela ainda não tem o peso da implementação. Ainda não tem os bugs, as decisões difíceis, o trabalho repetitivo.

Esse fenômeno tem um nome informal: Síndrome do Objeto Brilhante. E ele é mais intenso em cérebros que têm dificuldade de regular dopamina naturalmente.

O que acontece na prática? O projeto antigo não morre oficialmente. Ele só vai pra uma pasta chamada projetos/ e fica lá, acumulando poeira junto com outros oito projetos que passaram pelo mesmo ciclo.

A culpa que ninguém fala

Aqui está a parte que eu não via ninguém discutir: a culpa.

Porque quando você abandona um projeto, você não apenas perde o projeto. Você coleciona evidência contra si mesmo.

"Eu nunca termino nada."
"Eu começo cheio de energia e nunca entrego."
"Por que eu deveria começar esse projeto se vou abandonar igual aos outros?"

E essa narrativa é perigosa por dois motivos.

Primeiro, porque ela não é completamente verdadeira. Você provavelmente termina muita coisa, no trabalho, em tarefas com prazo real, em situações onde tem alguém esperando. O problema não é terminar em si. É terminar coisas que dependem 100% da sua motivação interna, sem deadline, sem stakeholder, sem pressão externa.

Segundo, você começa a acreditar que não é capaz de terminar, então para de tentar de verdade, e aí realmente não termina. O ciclo se fecha.

Não é preguiça. É neurologia.

Vou ser direto: se você se reconheceu em tudo que eu escrevi acima, há uma chance real de que seu cérebro simplesmente funciona de um jeito diferente da média.

Tem um tipo de cérebro que odeia repetição mas ama coisa nova. Não é fraqueza, é como ele funciona. O problema é que todo projeto tem uma fase nova e uma fase chata — e esse cérebro simplesmente apaga na segunda.

Não é falta de disciplina. É que o combustível que o seu cérebro usa pra manter o foco não funciona igual ao de todo mundo.

A diferença entre entender isso e não entender é enorme. Quando você não entende, você passa anos se achando preguiçoso, incompetente, incapaz de terminar o que começa e quando entende você começa a fazer perguntas diferentes:

"Como eu estruturo esse projeto pra ter recompensas menores e mais frequentes?"

"Como eu crio pressão externa pra compensar a falta de pressão interna?"

"Qual é o menor projeto possível que ainda entrega valor?"

Não são perguntas fáceis de responder. Mas são as perguntas certas.

Conclusão

Eu ainda começo projetos demais. Provavelmente sempre vou começar. Mas aprendi a parar de tratar isso como um defeito de caráter e passei a tratar como uma característica que precisa de estratégia.

O problema nunca foi a quantidade de projetos que eu começo. Foi a narrativa que eu construí em volta dos que eu não terminei.

Se você chegou até aqui e se reconheceu em alguma parte desse texto: você não está sozinho. E você provavelmente é melhor em começar coisas do que 90% das pessoas. Isso não é pouco, é uma habilidade real, que só precisa de direção.

O próximo projeto vai começar. A questão é o que você vai fazer diferente dessa vez.

Escrito por alguém que tem pelo menos dez pastas projetos/ abertas no VS Code agora mesmo.

O que uma usina nuclear tem a ver com o seu processo de QA?

Alicia Marianne Gonçalves — Sun, 05 Apr 2026 12:02:52 +0000

A gente sabe que testar e validar um software antes de ir para produção é importante. Mas você já parou para pensar no peso real que isso carrega?

Recentemente, estava revendo a série Chernobyl, e ela me fez refletir sobre muita coisa — especialmente sobre a forma como encaro minha área, sendo QA, e sobre a responsabilidade que ela traz. Resolvi compartilhar isso com vocês.

Para quem não conhece, Chernobyl é uma minissérie dramática lançada em 2019 que retrata o desastre nuclear ocorrido na usina de mesmo nome, na então União Soviética, em 26 de abril de 1986. A história acompanha os eventos logo após a explosão do reator número 4 — o caos, as tentativas do governo soviético de esconder a gravidade do acidente e o enorme esforço de cientistas, bombeiros, militares e trabalhadores que arriscaram, e muitas vezes perderam, suas vidas para evitar uma catástrofe ainda maior. A série também segue o cientista Valery Legasov, que tenta descobrir a verdadeira causa do acidente e expor a verdade por trás da tragédia.

Mas o ponto aqui vai além da série.

O que mais me chamou atenção foi o quanto aquela tragédia conversa com algo que vivemos diariamente no desenvolvimento de software: a responsabilidade nas decisões.

O que aconteceu em Chernobyl?

Mesmo sabendo que existem elementos dramatizados, dá para aprender muita coisa com esse desastre. Não sou física nuclear, mas vou tentar resumir o que aconteceu — porque foi justamente essa parte que mais me fez refletir sobre responsabilidade e tomada de decisão.

Na madrugada do dia 26 de abril de 1986, os operadores da usina realizavam um teste de segurança no reator 4. O objetivo era validar se, em caso de queda de energia, as turbinas ainda conseguiriam gerar eletricidade por alguns segundos — tempo suficiente até que os geradores de emergência fossem acionados. No papel, o teste parecia simples.

O problema é que, para executá-lo, diversos sistemas de segurança foram desativados e a potência do reator foi reduzida para um nível muito abaixo do ideal. Foi aí que tudo começou a sair do controle.

O reator utilizado era do tipo RBMK, um modelo com uma falha crítica de projeto: em determinadas condições, quanto mais vapor era gerado dentro do sistema, maior ficava a potência do reator. Em vez de estabilizar, ele se tornava cada vez mais instável. Para piorar, o teste foi conduzido sob forte pressão da liderança, mesmo diante de sinais claros de que não era seguro continuar.

Ao longo da série, vemos os próprios operadores levantando preocupações — que foram ignoradas. Quando perceberam que a situação era crítica, acionaram o botão de desligamento de emergência. Em teoria, esse comando deveria encerrar a reação. Mas, por uma falha no design das barras de controle, o efeito inicial foi o oposto: a potência disparou. Em poucos segundos, temperatura e pressão subiram de forma descontrolada.

O resultado foram duas explosões que destruíram o topo do reator, expuseram o núcleo à atmosfera e liberaram uma enorme quantidade de material radioativo. O incêndio que se seguiu espalhou radiação por boa parte da Europa, transformando Chernobyl no maior desastre nuclear da história.

O que mais me impactou foi perceber que a tragédia não aconteceu por um único erro. Ela foi consequência de uma cadeia de decisões ruins: falhas técnicas ignoradas, riscos mal avaliados e pessoas que não foram ouvidas.

E o que isso tem a ver com software?

Depois de assistir à série, comecei a fazer um paralelo com a nossa área. Porque, no fim, quantas vezes um incidente em produção também não nasce da mesma forma?

Nem sempre o problema vem de um único bug. Muitas vezes, ele é o resultado de uma sequência de decisões tomadas sem o devido cuidado: um requisito mal definido, um risco não mapeado, uma validação superficial, uma entrega apressada — ou um alerta levantado pelo time que acabou sendo ignorado.

Foi aí que a série me fez enxergar algo que vai além do contexto dela: quando a pressa fala mais alto do que a análise, o custo quase sempre aparece depois.

O maior problema: risco tratado de forma rasa

Um dos maiores desafios que vejo hoje no desenvolvimento de software é justamente o planejamento e o levantamento de riscos feitos de maneira superficial.

Tenho certeza de que você vai concordar: não tem coisa pior do que refazer algo ou ficar apagando incêndios que poderiam ter sido discutidos antes.

Vivemos num mundo onde tempo é dinheiro. E é exatamente por isso que qualidade precisa estar presente desde o início — não como uma etapa final, mas como parte do processo.

Como QA, vou compartilhar duas coisas que considero essenciais.

Ouça sua equipe

Independentemente da sua posição no time, ouça as pessoas ao seu redor.

Ninguém conhece melhor o produto do que quem o construiu, testou e convive com ele diariamente. Antes de uma nova funcionalidade entrar ou de um teste ser executado, converse com o time.

Escute quem desenvolveu. Escute o produto. Escute suporte. Escute quem está mais próximo do usuário.

Muitas vezes, o risco já foi identificado por alguém. Ele só não foi ouvido.

Analise antes de agir

Entender o impacto de uma mudança não é só uma questão técnica — é também uma questão de negócio.

Por exemplo: você vai melhorar a query de uma API. Em teoria, isso pode não alterar nenhuma regra de negócio. Mas como isso afeta o usuário final? A performance realmente melhorou? Existe algum impacto colateral? Como vamos medir se essa mudança foi positiva ou negativa?

Nem toda melhoria técnica gera melhoria de produto. E esse olhar crítico é parte fundamental do papel de QA.

Conclusão

No fim, Chernobyl me fez refletir sobre algo que vai muito além de uma série: a responsabilidade por trás de cada decisão que tomamos no dia a dia.

A gente não está lidando com um reator nuclear. Mas ainda assim lida com impacto real — no usuário, no negócio e no próprio time. Um risco ignorado, um teste mal planejado ou uma decisão tomada sem ouvir a equipe podem não gerar uma catástrofe, mas certamente geram problemas que poderiam ter sido evitados com mais atenção, diálogo e análise.

Para mim, ser QA vai muito além de encontrar bugs.

É questionar antes que o problema aconteça. É analisar cenários com olhar crítico. É antecipar riscos. É provocar conversas importantes dentro do time. É ajudar a construir decisões mais seguras e conscientes.

No final, qualidade não é apenas sobre software funcionando.

É sobre responsabilidade, colaboração e cuidado com tudo aquilo que criamos.

De front-end para UX, e de volta ao código: o que significa ser Design Engineer em 2026

vitoriazzp — Fri, 03 Apr 2026 13:00:00 +0000

Sou UX/UI designer, mas antes disso fui front-end.

Atuei cerca de 5 anos trabalhando com HTML e CSS, transformando layouts em páginas, entendendo hierarquia de informação e estrutura de interface. Depois, tomei o caminho oposto: migrei para UX/UI e agora completo 5 anos atuando em produtos, passando por fintech, utilities e atuando como Product Designer.

Essa trajetória, de front para UX e agora voltando a se aproximar do código, é justamente o que me levou a me reconhecer em um termo que gosto bastante: Design Engineer.

Minha trajetória: 5 anos de front-end, 5 anos de UX

Quando era front-end, eu via a tela como um resultado de código: HTML estruturando a informação, CSS dando forma e layout, um pouco de JavaScript dando comportamento.

Quando migrei para UX, passei a olhar mais para o todo do produto: pesquisa, fluxos, contexto do usuário, design systems, governança, revisão de interfaces, conversa com times de produto e de negócios.
Hoje, percebo que essas duas visões não são opostas. Elas se completam.

O que é design engineer em 2026?

Se você pesquisar sobre "Design Engineer", vai encontrar muitas definições técnicas, mas na prática o que mais faz sentido para mim é:

A pessoa que entende UX, código e um pouco de backend ao mesmo tempo, e usa isso para desenhar interfaces que são pensadas desde o primeiro pixel até a última chamada de API.

Não é só "quem desenha + quem programa"
É quem pensa em experiência e implementação juntas:

Um botão que não só parece bem-desenhado, mas também considera estados de loading, erro, disabled.
Um fluxo de cadastro que não só é bonito, mas que já prevê o que o backend vai precisar para validar, salvar e devolver feedback.
Um produto que pensa em performance, acessibilidade e usabilidade em uma única conversa.

Como front-end e UX mudam sua forma de ver produto

Como eu via a tela como desenvolvedor front-end
HTML estruturando a informação. CSS dando forma. Um pouco de JavaScript dando comportamento. A tela era resultado direto do código.

O que mudou quando migrei para UX/UI
Passei a olhar para o produto como um todo: pesquisa, fluxos, contexto do usuário. O código virou uma consequência, não o ponto de partida.

O que muda agora é que percebo que não preciso mais ficar só de um lado

Por que estou voltando ao código agora

Com o avanço de ferramentas como IA integrada ao Figma, prototipagem cada vez mais próxima do código e experiências acumuladas como Product Designer, foi aí que o conceito de Design Engineer passou a fazer sentido de verdade pra mim.

JavaScript moderno, React e um pouco de backend
Comecei a estudar de forma mais focada para:

Atualizar meu JavaScript (ES2024, async/await, fetch, arrays/objetos)
Reativar React (componentes, hooks, estado compartilhado)
Entender backend leve (Node/Express, rotas simples, persistência básica)
Pensar em performance e otimização das interfaces que ajudo a construir

Como estou usando IA no processo de aprendizado

Hoje, uso o Claude AI não como substituto, mas como apoio para:

Quebrar problemas de código em etapas menores
Revisar fluxos de dados entre front e backend
Organizar pensamentos e lógica de features

Design Engineer não é um cargo. É uma forma de pensar

O que mais gosto de dizer é que, em 2026, Design Engineer não é só um título de empresa grande ou de time específico. Pode existir em qualquer lugar onde UX e código se encontram:

Em um produto próprio
Em um projeto freelancer
Em um repositório público
Em um fluxo de trabalho híbrido, mesmo sem ter um cargo oficial com esse nome

O que importa é a maneira de pensar: UX + código ao mesmo tempo. Protótipos e implementação como parte do mesmo processo. Interfaces que consideram o que o usuário sente e o que o backend precisa.

O que vem por aí: UX data-driven e componentes React

Esse movimento não é só "voltar" ao front-end. É re-aprender JavaScript, entender melhor React e backend, e levar essa visão de UX para dentro do código.
Em breve, quero escrever mais sobre:

Como transformo um fluxo de UX do Figma em componentes React
Como penso em performance e carregamento em UX para web
Como organizar estudos de UX + código em ciclos curtos e práticos

E numa parte que ainda não me sinto confortável, mas sei que é essencial: vou falar sobre como estou começando a me tornar uma UX mais data-driven, porque ser Design Engineer em 2026 também é aprender a ouvir o que os números dizem sobre o UX que eu desenho.

Você também está nesse meio-termo entre UX e código?

Se você chegou até aqui, é bem provável que também se sinta em algum meio-termo entre UX e código.

Que tal comentar:

Como você se vê hoje entre design e desenvolvimento?
Você já tentou voltar pro código depois de virar UX, ou está no caminho invertido?

Esse é o tipo de conversa que me ajuda a entender como o conceito de Design Engineer está se moldando, bem além de títulos de empresa.

Construí um gerador de playlists no Spotify com Claude

Leo Garcez — Tue, 24 Mar 2026 02:01:08 +0000

Eu queria digitar “noite chuvosa, meio melancólica” e receber uma playlist perfeita. Então eu construí isso.

TL;DR

Eu construí um gerador de playlists com IA usando Claude + Spotify API
Você descreve um humor → ele gera 50 músicas → salva direto no Spotify
O maior problema foi OAuth local com NextAuth (sim, foi um inferno)
Claude funciona bem, mas precisa de bastante controle pra não inventar músicas
Streaming com SSE melhorou muito a UX

Links:

Índice

A Ideia
A Stack
O Problema de Trabalhar com OAuth Localmente
Endpoints Deprecated do Spotify
Spotify em Produção
Fazendo o Claude Obedecer
Prompt Engineering Anti-Alucinação
Modo Related Artists
Construindo o Perfil Musical
Streaming com SSE
O Que Aprendi

A Ideia

Fazer um gerador de playlists que realmente entendesse vibes, não só tags de gênero. Algo tipo: você digita "tarde fria num apartamento vazio" e recebe uma playlist boa de verdade, já salva no seu Spotify.

O conceito:

Usuário descreve um humor
Claude retorna 50 músicas em JSON
App busca cada faixa no Spotify
Cria e salva a playlist na conta do usuário

Três APIs, um app.

A Stack

Next.js 14 (App Router)
NextAuth v5 beta
Anthropic Claude API (claude-sonnet-4-6)
Spotify Web API
Supabase (PostgreSQL)
TypeScript + Tailwind CSS + Framer Motion

Escolhi o Claude porque ele tá bem em alta agora e, na prática, é confiável, alucina menos do que eu esperava pra esse tipo de tarefa. Ele é um pouco menos criativo que o GPT nas recomendações, mas compensa sendo mais previsível no formato das respostas, o que importa bastante quando você tá parseando JSON.

O Problema de Trabalhar com OAuth Localmente

Isso me custou algumas horas e sessões de debug. Vou detalhar porque tem várias camadas de problema e você provavelmente vai bater na mesma parede se estiver usando NextAuth v5 com Spotify.

O Spotify não aceita `localhost`

O Spotify proíbe localhost como redirect URI pra URIs de loopback. A solução é usar 127.0.0.1. Cadastrei http://127.0.0.1:3000/api/auth/callback/spotify no dashboard e setei AUTH_URL=http://127.0.0.1:3000 no .env.local.

Não foi suficiente.

O `NextRequest` normaliza URLs pra `localhost`

O Next.js, independente do host que você passa pra next dev -H, normaliza req.url e req.nextUrl.href de volta pra localhost em desenvolvimento. Isso não é bug documentado — é comportamento interno do framework.

O NextAuth v5 tem um utilitário chamado reqWithEnvURL que tenta corrigir exatamente isso, mas falha silenciosamente:

// Dentro do next-auth — simplificado
function reqWithEnvURL(req: NextRequest): NextRequest {
  const url = process.env.AUTH_URL ?? req.url;
  return new NextRequest(url, req); // ← o construtor normaliza de volta pra localhost
}

Mesmo passando 127.0.0.1 explicitamente, o construtor do NextRequest sobrescreve. A "correção" não funciona.

Dois momentos onde o redirect URI importa

O OAuth tem dois momentos distintos onde o redirect URI aparece:

Requisição de autorização — a URL do Spotify onde o usuário loga. O redirect_uri aqui vem dos seus params de configuração, então você pode hardcodar 127.0.0.1 na config do provider. Isso funcionou.
Troca de token — quando o Spotify manda o código de volta, o @auth/core envia um POST pra trocar o código por tokens. O redirect_uri nessa requisição vem de provider.callbackUrl, que é derivado de params.url.origin — ou seja, da URL da requisição de callback. Se essa URL ainda diz localhost, a troca falha com invalid_grant: Invalid redirect URI.

O sintoma era desconcertante: a URL de autorização mostrava 127.0.0.1 corretamente, mas a troca de token continuava falhando. Fui atrás do código do @auth/core pra entender o que tava acontecendo.

A solução: `Auth()` direto com `Request` nativo

Objetos Request nativos do browser/Node não normalizam URLs. A correção é contornar os route handlers do NextAuth e chamar Auth() do @auth/core diretamente, passando um Request nativo com a URL já corrigida:

// src/app/api/auth/[...nextauth]/route.ts
import { Auth } from "@auth/core";
import { authConfig } from "../../../../../auth";
import { NextRequest } from "next/server";

function buildRequest(req: NextRequest): Request {
  const authOrigin = process.env.AUTH_URL ?? `http://${req.headers.get("host")}`;
  const fixedUrl = req.url.replace(/^https?:\/\/[^/]+/, authOrigin);

  const hasBody = req.method !== "GET" && req.method !== "HEAD";
  return new Request(fixedUrl, {
    method: req.method,
    headers: req.headers,
    body: hasBody ? req.body : undefined,
    // duplex necessário para streaming de body no Node.js
    ...(hasBody && ({ duplex: "half" } as object)),
  });
}

const handler = (req: NextRequest) =>
  Auth(buildRequest(req), authConfig as Parameters<typeof Auth>[1]);

export { handler as GET, handler as POST };

Versão do @auth/core: ao usar Auth() diretamente, instale a versão exata que o next-auth usa internamente:

npm ls @auth/core  # veja qual versão o next-auth requer
npm install @auth/core@0.41.0 --save-exact

Versões diferentes criam conflitos de tipo que explodem em runtime.

Configuração explícita no auth.ts: ao contornar os handlers do NextAuth, setEnvDefaults não roda mais. Configure basePath, secret e redirect_uri explicitamente:

// auth.ts
export const authConfig: NextAuthConfig = {
  trustHost: true,
  basePath: "/api/auth",
  secret: process.env.AUTH_SECRET,
  providers: [
    Spotify({
      clientId: process.env.AUTH_SPOTIFY_ID,
      clientSecret: process.env.AUTH_SPOTIFY_SECRET,
      authorization: {
        url: "https://accounts.spotify.com/authorize",
        params: {
          scope: SPOTIFY_SCOPES,
          show_dialog: true,
          redirect_uri: `${process.env.AUTH_URL}/api/auth/callback/spotify`,
        },
      },
    }),
  ],
  // ... callbacks e pages como antes
};

Bônus: problema de domínio do cookie PKCE

Mesmo com tudo acima, pode acontecer mais uma falha: se o usuário acessa http://localhost:3000, o navegador seta o cookie PKCE pro domínio localhost. Quando o Spotify redireciona de volta pra http://127.0.0.1:3000/..., o navegador não envia o cookie — domínios diferentes — e o code_verifier some. A troca falha de novo.

A correção é garantir que localhost:3000 nunca apareça pro usuário, redirecionando via next.config.mjs:

async redirects() {
  return [
    {
      source: "/:path*",
      has: [{ type: "host", value: "localhost:3000" }],
      destination: "http://127.0.0.1:3000/:path*",
      permanent: false,
    },
    {
      source: "/",
      has: [{ type: "host", value: "localhost:3000" }],
      destination: "http://127.0.0.1:3000/",
      permanent: false,
    },
  ];
},

Com isso, todo o fluxo de auth fica em 127.0.0.1 e os cookies PKCE chegam onde precisam chegar.

Endpoints Deprecated do Spotify

Com o auth funcionando, bati num muro de 403s.

O Spotify deprecated alguns endpoints sem muito alarde:

Antigo (deprecated)	Novo
`POST /playlists/{id}/tracks`	`POST /playlists/{id}/items`
`GET /playlists/{id}/tracks`	`GET /playlists/{id}/items`
`GET /audio-features`, `GET /recommendations`	Deprecated, sem substituto

A migração /tracks → /items está documentada, mas é fácil de perder se você seguiu um tutorial de 2022. Audio features e recomendações sumindo foi mais chato — tive que construir contexto de energia de outra forma, mais sobre isso abaixo.

Spotify em Produção

Tem uma limitação que eu não vi muito discutida: no modo de desenvolvimento, o Spotify permite apenas 5 usuários autenticados E eles precisam ser adicionados manualmente via allowlist no dashboard.

Pra ir além disso, você precisa solicitar Extended Quota Mode. E o processo atual é bem pesado:

Entidade jurídica registrada (pessoa física não é aceita desde maio de 2025)
Serviço já lançado e ativo
Mínimo de 250.000 usuários ativos mensais
Viabilidade comercial

A análise pode levar até seis semanas, e sem garantia de aprovação.

Na prática, isso significa que se você tá construindo algo novo como indie dev, vai ficar travado em modo de desenvolvimento. Você consegue testar e mostrar pra até 4 pessoas além de você — e só. Vale saber disso antes de planejar algum lançamento público.

Fazendo o Claude Obedecer

O system prompt instrui o Claude a retornar apenas um array JSON, sem markdown, sem explicações. Essa parte é direta. O problema mais difícil é conseguir 50 faixas que realmente existam.

One-shot prompting

Incluir uma conversa de exemplo completa (usuário + assistente) antes do request real reduziu bastante os erros de formato, especialmente com artistas não-ingleses:

messages: [
  {
    role: "user",
    content: "Create a playlist for this mood/vibe: late night drive, nostalgic",
  },
  {
    role: "assistant",
    content: JSON.stringify([
      { title: "Drive", artist: "The Cars", reason: "Synth-pop clássico com energia perfeita de madrugada" },
      { title: "Running Up That Hill", artist: "Kate Bush", reason: "Art-pop etéreo, emocionalmente assombroso" },
      // ...
    ]),
  },
  { role: "user", content: actualUserMessage },
],

Extração de JSON como fallback

Mesmo com prompting cuidadoso, modelos eventualmente jogam texto de introdução. Sempre extraia o array:

const match = raw.match(/\[[\s\S]*\]/);
if (!match) throw new Error("Nenhum array JSON encontrado");
const suggestions = JSON.parse(match[0]);

Prompt Engineering Anti-Alucinação

Descobri que quanto mais músicas você pede, mais o modelo inventa títulos.

Pedindo 70 músicas, o Claude começa a criar faixas com nomes plausíveis que não existem. Com 50 e restrições explícitas, fica bem melhor.

O que adicionei ao system prompt:

EXISTÊNCIA NO SPOTIFY — CRÍTICO:
Cada música DEVE existir no Spotify. Antes de incluir uma faixa, pergunte:
"Tenho certeza que esta música existe no Spotify com este título e artista exatos?"
Se houver qualquer dúvida, escolha outra música que você tem certeza.

REGRAS DE FORMATO DO TÍTULO:
- Use apenas o título canônico limpo do lançamento
- SEM sufixos: sem "- Remastered", "- Live at...", "- Radio Edit"
- Use o nome do lançamento mais conhecido, não compilações

ARMADILHAS COMUNS DE ALUCINAÇÃO:
- Não invente títulos de músicas que parecem plausíveis mas podem não existir
- Não confunda dois artistas com nomes similares
- Não sugira deep cuts que você não tem certeza

Também removi a abordagem de duas etapas "gerar 70, refinar pra 50". Era cara em tempo e custo, e uma única geração de 50 com boas instruções performa melhor.

O system prompt atual completo

Esse é o prompt que tá rodando em produção hoje:

You are a world-class Spotify playlist curator.

GOAL:
Generate EXACTLY 50 high-quality songs for a playlist.

OUTPUT:
Return ONLY a raw JSON array. No markdown, no explanations.

Each item:
- "title": string — the canonical Spotify title, nothing else
- "artist": string — the primary artist exactly as listed on Spotify
- "reason": string — max 10 words

SPOTIFY EXISTENCE — CRITICAL:
Every song MUST exist on Spotify. Before including a track, ask yourself:
"Am I certain this song exists on Spotify under this exact title and artist?"
If there is any doubt, pick a different song you are certain about.

TITLE FORMAT RULES:
- Use the clean, canonical release title only
- NO suffixes: no "- Remastered", "- Live at...", "- Radio Edit", "- feat. X"
- NO parentheticals unless part of the official title
- Use the most well-known release name, not compilations or bonus versions

COMMON HALLUCINATION TRAPS TO AVOID:
- Do not invent song titles that sound plausible but may not exist
- Do not confuse two artists with similar names
- Do not suggest deep cuts you are uncertain about
- Do not suggest songs only released in specific regions unavailable globally

DISTRIBUTION:
- 50% recognizable hits (high confidence they exist)
- 40% lesser-known but confirmed tracks
- 10% deep cuts you are fully certain about

DIVERSITY:
- At least 2 genres
- At least 3 decades
- Non-English tracks welcome if you are certain they are on Spotify

CURATION:
- Cohesive flow, playlist-worthy, non-random
- No duplicates

Return ONLY the JSON array. Exactly 50 items.

Curiosidade: o prompt tá em inglês mesmo que o usuário escreva em português. O Claude entende o humor no idioma que vier e retorna os dados no formato esperado sem problema.

Melhor resolução de busca no Spotify

Mesmo com um bom prompt, algumas faixas voltam com títulos ou artistas levemente errados. Três ajustes no lado da busca:

1. Buscar 10 candidatos em vez de 1
Em vez de limit=1, buscar limit=10 e escolher o melhor match.

2. Filtro de popularidade
Pular resultados com popularity < 30 — evita gravar versões ao vivo obscuras quando a faixa correta não é encontrada:

const POPULARITY_FLOOR = 30;
const aboveFloor = candidates.filter(t => t.popularity >= POPULARITY_FLOOR);
const pool = aboveFloor.length > 0 ? aboveFloor : candidates;

3. Fuzzy matching + seleção por popularidade
Normalizar strings e verificar correspondência bidirecional de substring, depois escolher o match com maior popularidade:

function fuzzyMatch(candidate: SpotifyTrack, suggestion: ClaudeTrackSuggestion): boolean {
  const trackName = normalizeStr(candidate.name);
  const artistName = normalizeStr(candidate.artists[0]?.name ?? "");
  const sugTitle = normalizeStr(suggestion.title);
  const sugArtist = normalizeStr(suggestion.artist);
  const titleMatch = trackName.includes(sugTitle) || sugTitle.includes(trackName);
  const artistMatch = artistName.includes(sugArtist) || sugArtist.includes(artistName);
  return titleMatch && artistMatch;
}

Modo Related Artists

Playlists geradas por IA alucinam mais quando o humor é específico de artista — tipo "algo como Radiohead". Nesses casos, o grafo de artistas do próprio Spotify é mais confiável que o Claude.

Adicionei detecção automática: uma chamada rápida ao Claude Haiku (~0,5s) classifica o prompt antes da geração principal:

// Retorna { mode: "ai" | "related", artists: ["Radiohead", "Nick Cave"] }
const detected = await detectPlaylistMode(mood);

Se artistas são detectados, o app:

Os resolve no Spotify
Busca artistas relacionados (GET /artists/{id}/related-artists)
Pega top tracks de cada artista relacionado
Monta uma playlist com dados reais do Spotify, sem depender do Claude pra nada

Se não detectar artistas, cai pro fluxo normal com Claude.

if (detected.mode === "related" && detected.artists.length > 0) {
  const { suggestions, resolvedSeeds } = await buildRelatedArtistsPlaylist(
    detected.artists,
    accessToken,
    energy
  );
  if (suggestions.length > 0) {
    return NextResponse.json({ suggestions, mode: "related", seedArtists: resolvedSeeds });
  }
  // fallthrough para modo AI se não encontrou nada
}

Construindo o Perfil Musical

O app deixa usuários escolher uma playlist de referência ou seus top artistas do Spotify (último mês / 6 meses / histórico completo). Esse contexto é passado pro Claude como uma impressão digital musical.

Mandar nomes de faixas brutos confunde o modelo. Em vez disso, agregue num perfil:

// Contar frequência de artistas em todas as faixas da playlist
const artistFreq = new Map<string, { name: string; count: number }>();
for (const track of tracks) {
  const a = track.artists[0];
  const prev = artistFreq.get(a.id);
  artistFreq.set(a.id, { name: a.name, count: (prev?.count ?? 0) + 1 });
}

Pra playlists, também busco dados de gênero dos artistas principais via GET /artists/{id} (5 chamadas paralelas), já que os itens de playlist não retornam gêneros nativamente.

Mesmo sem seleção de referência explícita, o app passa os top artistas e gêneros baseline do usuário como contexto suave pra cada geração.

A instrução no prompt mudou de "não recomende esses artistas" pra algo mais útil:

→ Biase as recomendações em direção a este DNA musical: tempo, humor e estilo de produção similar.
→ Descubra artistas com som SIMILAR — não necessariamente os mesmos artistas.
→ NÃO repita faixas já listadas acima.

Streaming com SSE

O fluxo original: buscar todas as 50 faixas em paralelo, retornar tudo de uma vez, mostrar um spinner.

O problema é que o usuário ficava olhando "Salvando no Spotify..." por 5-10 segundos sem nenhum feedback. Server-Sent Events resolve isso — cada faixa é emitida conforme resolve:

// Na rota da API
const stream = new ReadableStream({
  async start(controller) {
    const send = (data: object) =>
      controller.enqueue(encoder.encode(`data: ${JSON.stringify(data)}\n\n`));

    await Promise.all(
      suggestions.map(async (suggestion) => {
        const track = await searchTrack(suggestion, accessToken);
        if (track) {
          foundTracks.push({ track, suggestion });
          send({ type: "track", track, suggestion }); // emitido imediatamente
        }
      })
    );

    // Criar playlist depois que todas as buscas terminam
    const playlist = await createPlaylist(...);
    send({ type: "done", playlist, found: foundTracks.length });
    controller.close();
  },
});

return new Response(stream, {
  headers: { "Content-Type": "text/event-stream", "Cache-Control": "no-cache" },
});

A busca paralela continua na velocidade máxima. Mas agora o cliente vê cada faixa aparecer com album art conforme resolve, com uma barra de progresso ao vivo — em vez de um spinner em branco por 10 segundos.

O Que Aprendi

Sobre prompt engineering:

Menos é mais (50 > 70)
Exemplos one-shot (par de mensagens usuário + assistente) são mais confiáveis que instruções de formato detalhadas.
Dizer o que não fazer funciona muito bem
Contexto de perfil funciona melhor como guia de DNA musical, não como lista de restrições.

Sobre a API do Spotify:

Sempre verifique se o endpoint ainda é atual. /tracks → /items, audio features sumiu, recomendações sumiram.
GET /artists/{id}/related-artists funciona bem pra descoberta e quase ninguém usa.
O score de popularidade nas faixas é um bom proxy pra "essa faixa existe como esperado."

Sobre streaming no Next.js:

ReadableStream + text/event-stream funciona limpo no App Router.
Promise.all + emit-on-resolve te dá paralelismo real com UI progressiva de graça.

Sobre Next.js + OAuth:

NextRequest normaliza URLs pra localhost em desenvolvimento, mesmo que você passe 127.0.0.1 explicitamente. Use Request nativo quando a URL importa.
O NextAuth v5 tem um utilitário reqWithEnvURL que tenta corrigir isso mas usa new NextRequest() internamente — que normaliza de novo. A correção do framework não funciona.
O OAuth tem dois momentos onde o redirect_uri é verificado: na requisição de autorização e na troca de token. Você precisa garantir que os dois mostrem 127.0.0.1.
provider.callbackUrl é derivado da URL da requisição de callback — não da sua config. Se a URL da requisição ainda diz localhost, a troca falha com invalid_grant.
Ao usar Auth() do @auth/core diretamente, pin a versão exata que o next-auth requer. Versões diferentes causam conflitos de tipo em runtime.
Cookies PKCE são scopados por domínio. Se o usuário começa em localhost e o callback chega em 127.0.0.1, o code_verifier some. Redirecione todo o tráfego de localhost pra 127.0.0.1 no next.config.mjs.
NextAuth v5 é poderoso mas a documentação beta é bem escassa. Ler o código-fonte do @auth/core foi necessário pra entender o que estava acontecendo.

Teste Você Mesmo

O app se chama Moodify. Está OpenSource no GitHub. Se você tá fazendo algo parecido, espero que ajude um pouco.

Como vocês melhorariam esse prompt? Se alguém já passou por algo parecido ou tiver ideias, comenta aí

Construído com Next.js, Claude API, Spotify Web API e Supabase. Deploy no Vercel.

Engenharia de Prompt: Por Que a Forma Como Você Pergunta Muda Tudo(Um guia introdutório)

Fran Borges — Mon, 23 Mar 2026 16:20:34 +0000

Neste artigo irei explicar alguns pontos importantes sobre Engenharia de prompt, e como saber esses pontos pode te ajudar muito no dia a dia lidando com IAs, no seus estudos, pesquisas, trabalho, vibeconding, whatever.

Prefácio
Antes de tudo, para lembrar, o que é uma LLM mesmo?
Fazendo Perguntas
- 1 - Evite a Ambiguidade
- 2 - Delimite o Escopo
- 3 - Forneça Contexto Relevante
Considerações Finais

Prefácio

A base do conhecimento é necessária em tudo que se quer aprender, com LLMs não é diferente. Analisando padrões, conversando com amigos, observei que a grande parte das pessoas que usam LLMs no dia a dia de trabalho, estudo, pessoas que trabalham com tecnologia e principalmente quem está começando na área tech, não tem ideia de como a LLM funciona e de como fazer as perguntas e tirar dúvidas de forma certa para um ChatGPT da vida.

Tendo isso em vista, e como venho estudando bastante sobre esse assunto, como forma de compartilhar o conhecimento, já dizia a poetisa brasileira Cora Coralina: "Feliz aquele que transfere o que sabe, e aprende o que ensina", farei uma série de artigos explicando sobre o tema, e esse é só o primeiro deles...

Antes de tudo, para lembrar, o que é uma LLM mesmo?

A LLM pode ser definida de algumas formas. Uma delas é: "São modelos de linguagem de máquina, que usam algoritmos de aprendizado profundo (Deep Learning) para processar e aprender a linguagem natural", essa é a sua definição estrutural. A definição que mais gosto é: "A LLM, na sua essência, é composta por dois arquivos: um contendo os pesos (parâmetros) com os conhecimentos aprendidos, e o outro com o código necessário para rodar os dados aprendidos.", como uma pessoa visual, consigo imaginar melhor como funciona.

Então, ChatGPT, Claude e muitos outros são exatamente isso, e atualmente têm a capacidade de executar várias atividades, como escrever código, traduzir texto, responder às mais variadas dúvidas e, dependendo da sua capacidade de escrever prompts mais robustos, pode até criar arquiteturas de produtos, te ajudar a resolver bugs complexos, te dar ideias, e até criar um SaaS revolucionário (risos).

O ponto é que a capacidade das LLMs de "compreender" e "criar" chegou a um ponto bem avançado, e você só chega na camada -17 de boas respostas fazendo as perguntas de forma certa!

Nota: Camada -17 se refere à camada onde se acha o minério de ouro no jogo Minecraft ;).

Fazendo Perguntas

Como fazer as perguntas certas? E por que saber isso importa? Vamos lá.

Saber fazer as perguntas certas para uma LLM é tão importante que existe uma área da tecnologia específica só para isso: a Engenharia de Prompts, definida como "a ciência empírica de planejar, criar e testar prompts para gerar melhores respostas em LLMs". Saber fazer as perguntas certas te coloca em outro nível, você consegue obter as melhores respostas, e isso te traz muitos ganhos, sendo o principal deles a produtividade.

Mas afinal, como perguntar de forma certa?

A LLM é poderosa, mas não adivinha sua intenção. Para obter os melhores resultados nas suas buscas, você precisa se concentrar na criação de prompts claros, na especificidade e ser rico em dar contexto. E tudo isso envolve:

1 - Evite a Ambiguidade

"Espaço de possibilidades"

Quando você escreve um prompt muito ambíguo, vago, o modelo enxerga vários caminhos estatisticamente válidos. É como se ele estivesse numa encruzilhada com 50 estradas e todas tivessem placas dizendo "Talvez por aqui", ele vai escolher uma, mas não necessariamente a que você precisa: a estrada com o percurso mais rápido e sem trânsito (a resposta correta de fato).

Exemplos:

Prompt ambíguo:

"Crie uma API."

O que a LLM "vê": Vários caminhos, API REST? GraphQL? Em qual linguagem? Para qual domínio? Com autenticação? Com banco? O modelo vai escolher o caminho mais estatisticamente comum nos dados de treino (provavelmente uma API REST genérica em Node.js com Express), que pode não ter nada a ver com o que você precisa.

Prompt sem ambiguidade:

"Crie um microsserviço em Node.js com Express e TypeScript para processar pagamentos via
Stripe. Endpoints: criar pagamento, confirmar webhook e consultar status. O payload tem:
orderId(UUID), amount(number), currency(enum: BRL, USD) e customerId(string).
Use zod para validação, Prisma com PostgreSQL para persistir as transações e winston
para logs. Retorne status codes apropriados como(201, 200, 400, 422, 500). Trate falhas de
rede com retry automático (máx. 3 tentativas)."

O que a LLM "vê": Um caminho quase único. Cada detalhe funciona como uma restrição que elimina ambiguidade: "Node.js com Express e TypeScript" define runtime, framework e linguagem de uma vez. "Pagamentos via Stripe" restringe o SDK e o domínio. "3 endpoints explícitos + payload com tipos" elimina adivinhações sobre rotas e schema. "Zod, Prisma, PostgreSQL, Winston" travam a stack, o modelo não vai sugerir alternativas. "Status codes específicos + retry com máximo de 3 tentativas" definem os status HTTP e a estratégia com limites claros. A distribuição de probabilidade fica concentrada e o modelo praticamente "só tem uma opção" a cada token gerado.

2 - Delimite o Escopo

"Janela de atenção"

LLMs têm um context window(Janela), uma quantidade de tokens (pedaço de palavra) que conseguem ser processados de uma vez. Isso inclui o seu prompt e a resposta gerada. Dentro dessa janela, existe um fenômeno importante: nem todos os tokens recebem a mesma "atenção" no processamento.

O mecanismo de self-attention (o coração da arquitetura Transformer, não é um cubo rsrsrs, e a arquitetura de rede neural, que seria o framework da LLM se a mesma fosse uma linguagem de programação), ela define a estrutura de tudo, calcula relações entre todos os tokens do prompt. Quanto mais tokens irrelevantes existem, mais o modelo precisa "dividir atenção" entre informações úteis e inúteis.

Exemplos:

Sem escopo:

"Me ensine Docker."

O que acontece internamente: O modelo precisa decidir entre centenas de subtópicos, instalação, conceitos básicos, Dockerfile, docker-compose, volumes, orquestração, a atenção se fragmenta e o resultado é um overview superficial de tudo.

Com escopo:

"Explique o conceito de multi-stage build no Docker para um dev backend pleno que já usa
Docker no dia a dia mas nunca otimizou o tamanho das imagens. Mostre um exemplo prático
com uma aplicação JavaScript, comparando o Dockerfile sem e com multi-stage build,
incluindo o tamanho final de cada imagem."

O que acontece internamente: O mecanismo de atenção se concentra em uma região muito específica, a interseção entre "Docker", "multi-stage build", "otimização de imagem" e "JavaScript". Os pesos de atenção ficam fortemente direcionados.

3 - Forneça Contexto Relevante

"Estado da aplicação"

Uma LLM é stateless por natureza, ela não tem memória entre requisições. Cada prompt é processado do zero, o único "estado" que ela tem é o que você coloca no prompt. Isso significa que todo contexto que você não fornece simplesmente não existe para o modelo.

Internamente, o contexto funciona como um sistema de pesos no mecanismo de atenção. Quando você adiciona informações, elas criam "âncoras" que influenciam a distribuição de probabilidades de todos os tokens subsequentes, é como se cada pedaço de contexto fosse um ímã que puxa a resposta para uma direção específica.

Exemplos:

Sem contexto:

"Revise meu código."

O que a LLM faz: Sem saber a linguagem, o framework, o nível do dev, o objetivo do código, o padrão do time ou o tipo de revisão esperada, ela vai fazer comentários genéricos: "adicione tratamento de erro", "use nomes mais descritivos", "considere adicionar testes".

Com contexto:

"Revise este endpoint Node.js com Express que lida com upload de arquivos para o S3.
O time usa ESLint + Prettier, então ignore estilo. O padrão do time é async/await com
try/catch e erros customizados. Endpoint em produção, recebe 200 uploads/min.
Foque em: memory leaks, tratamento de erros e uso correto do SDK do S3."

O que a LLM faz: Cada informação do prompt funciona como um filtro que elimina ruído e concentra a revisão: "Node.js com Express + upload para S3" ativa conhecimento específico sobre streams, buffers, multipart e AWS SDK. "ESLint + Prettier, ignore estilo" elimina os comentários possíveis que o linter já resolve. "async/await com erros customizados" faz o modelo pular sugestões que o time já aplica e focar em como estão sendo usadas. "Produção, 200 uploads/min" muda o peso de cada problema, um buffer não liberado que seria aceitável em dev vira um incidente crítico sob carga. "Foque em: memory leaks, erros, SDK S3" restringe a revisão a 3 eixos e ignora dezenas de outros tópicos.

Com base nisso, saber as limitações do modelo que você está usando, te ajuda também a entender até aonde você pode ir nas perguntas e inferências, então escolha a sua melhor IA, treine ela, faça as suas perguntas, teste, tente! ;)

É Lembre-se: a LLM não "pensa", ela calcula probabilidades!

Considerações Finais

É isto, tentei resumir cada ponto que achei interessante abordar e explicar nessa primeira etapa, mas há muito mais sobre engenharia de prompt de LLM para falar, como técnicas mais clássicas de engenharia de prompts(Zero-shot prompting, Role prompting), técnicas mais avançadas(Chain-of-Thought (CoT), Prompt Chaining), são muitas camadas que tentarei destrinchar nos próximos artigos, esse é apenas o primeiro que traz a minha volta para a escrita de artigos após alguns bons anos. Espero que você caro leitor tenha entendido e aprendido algo. Obrigado por ler até aqui. ;)

Onde me encontrar:

Meu LinkedIn
Meu GitHub

Do commit ao deploy: CI/CD de uma API na AWS usando GitHub Actions, ECS e Terraform

Fernando Andrade — Thu, 12 Mar 2026 00:07:27 +0000

Sumário

Introdução
Pré-requisitos
Visão Geral da Arquitetura
Configurando o IAM para o Terraform
Infraestrutura como Código com Terraform
- Recursos Provisionados
- IAM Role para Tarefas ECS
- Task Definition (Fargate)
- ECS Service
- OIDC: Autenticação Sem Credenciais Estáticas
Dockerfile Multi-Stage
Pipeline de CI
Protegendo a Branch Main
Configurando as Secrets no GitHub
Pipeline de CD
Acessando a Aplicação após o Deploy
Segurança: OIDC em Detalhe
Fluxo Completo: Do Commit ao Deploy
Considerações Finais

Introdução

Colocar uma aplicação em produção vai muito além de escrever código. Envolve compilar, testar, empacotar e entregar de forma confiável e repetível. Neste artigo, vou mostrar como construir uma pipeline completa — do commit ao deploy — usando GitHub Actions para CI/CD, Terraform para infraestrutura como código e AWS (ECR, ECS Fargate) como plataforma de execução.

O conceito apresentado aqui é agnóstico de linguagem — funciona para qualquer stack que rode em um container Docker (Node.js, Go, Java, Python, etc.). Para os exemplos práticos, vamos utilizar .NET como referência, mas os workflows, a infraestrutura Terraform e o fluxo de deploy são os mesmos independente da tecnologia escolhida.

O objetivo é demonstrar como essas ferramentas se conectam para formar um fluxo automatizado onde um simples merge na branch main resulta em uma nova versão rodando em produção, sem intervenção manual.

Pré-requisitos

Antes de começar, você precisa ter as seguintes ferramentas instaladas e configuradas:

Ferramenta	Descrição	Link de instalação
Docker	Para construir e executar containers	docs.docker.com/get-docker
Terraform	Para provisionar infraestrutura como código	developer.hashicorp.com/terraform/install
AWS CLI	Para interagir com os serviços da AWS via terminal	docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html
Git	Para versionamento de código	git-scm.com/downloads
Conta AWS	Com permissões para criar recursos (IAM, ECS, ECR)	aws.amazon.com/free
Conta GitHub	Para hospedar o repositório e rodar os workflows	github.com

Nota: Para o exemplo deste artigo, também é necessário o .NET SDK instalado localmente para desenvolvimento. Se você estiver usando outra stack, substitua pelo SDK correspondente (Node.js, Go, JDK, etc.). Outro ponto é que a escolha em utilizar o ECS ao invés de um EKS ou EC2 é devido sua simplicidade na curva de aprendizado, baixo gerenciamento e que para fins de aprendizado os recursos mínimos definidos para esse laboratório não gerem altos gastos para o aprendizado.

Visão Geral da Arquitetura

O fluxo completo funciona assim:

Developer → Feature Branch → Pull Request → Validação (CI)
                                                  ↓
                                            Merge na main
                                                  ↓
                                         Build & Push (CD)
                                                  ↓
                                        Deploy no ECS Fargate

Configurando o IAM para o Terraform

Antes de rodar qualquer terraform apply, é necessário que o Terraform tenha permissões para criar recursos na AWS. Para isso, precisamos de um usuário IAM (ou role) com as permissões adequadas e configurar suas credenciais localmente.

Criando um usuário IAM para o Terraform

No console da AWS (IAM > Users), crie um usuário dedicado para o Terraform:

Acesse IAM > Users > Create User
Nomeie o usuário (ex: terraform-deployer)
Anexe as policies necessárias para os recursos que serão criados:

AmazonECS_FullAccess
AmazonEC2ContainerRegistryFullAccess
AmazonVPCReadOnlyAccess
IAMFullAccess
CloudWatchLogsFullAccess
AmazonS3FullAccess

Nota de segurança: Em um ambiente produtivo, o ideal é criar uma policy customizada com o princípio do menor privilégio, concedendo apenas as permissões estritamente necessárias. Para fins de estudo, as managed policies acima simplificam o setup.

Após criar o usuário, gere um Access Key (IAM > Users > Security credentials > Create access key)
Selecione o caso de uso Command Line Interface (CLI)

Configurando as credenciais localmente

Com o AWS CLI instalado, configure as credenciais:

aws configure

Será solicitado:

AWS Access Key ID: AKIA...
AWS Secret Access Key: wJal...
Default region name: us-east-1
Default output format: json

Isso cria o arquivo ~/.aws/credentials que o Terraform utilizará automaticamente via o provider AWS. Com isso feito, o Terraform tem autorização para provisionar os recursos que definiremos a seguir.

Infraestrutura como Código com Terraform

Antes de qualquer pipeline rodar, a infraestrutura precisa existir. Com o Terraform, declaramos todos os recursos AWS em arquivos .tf e provisionamos com um único comando.

Recursos Provisionados

# Provider AWS
provider "aws" {
  region = "us-east-1"
}

# Repositório ECR para armazenar imagens Docker
resource "aws_ecr_repository" "app_repository" {
  name = "minha-app-repository"
}

# Cluster ECS
resource "aws_ecs_cluster" "app_cluster" {
  name = "minha-app-cluster"
}

IAM Role para Tarefas ECS

O ECS precisa de uma role para puxar imagens e enviar logs:

resource "aws_iam_role" "ecs_task_execution_role" {
  name = "ecs-task-execution-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action    = "sts:AssumeRole"
      Effect    = "Allow"
      Principal = { Service = "ecs-tasks.amazonaws.com" }
    }]
  })
}

resource "aws_iam_role_policy_attachment" "ecs_policy" {
  role       = aws_iam_role.ecs_task_execution_role.name
  policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
}

Task Definition (Fargate)

Aqui definimos como o container será executado:

resource "aws_ecs_task_definition" "app_task" {
  family                   = "minha-app-task"
  network_mode             = "awsvpc"
  requires_compatibilities = ["FARGATE"]
  cpu                      = "256"
  memory                   = "512"
  execution_role_arn       = aws_iam_role.ecs_task_execution_role.arn

  container_definitions = jsonencode([{
    name      = "app"
    image     = "${aws_ecr_repository.app_repository.repository_url}:latest"
    portMappings = [{
      containerPort = 8080
      hostPort      = 8080
    }]
    logConfiguration = {
      logDriver = "awslogs"
      options = {
        "awslogs-group"         = "/ecs/minha-app"
        "awslogs-region"        = "us-east-1"
        "awslogs-stream-prefix" = "ecs"
      }
    }
  }])
}

ECS Service

O service mantém o container rodando e gerencia o deploy:

resource "aws_ecs_service" "app_service" {
  name            = "minha-app-service"
  cluster         = aws_ecs_cluster.app_cluster.id
  task_definition = aws_ecs_task_definition.app_task.arn
  desired_count   = 1
  launch_type     = "FARGATE"

  network_configuration {
    subnets          = data.aws_subnets.default.ids
    security_groups  = [aws_security_group.app_sg.id]
    assign_public_ip = true
  }
}

OIDC: Autenticação Sem Credenciais Estáticas

Este é um dos pontos mais importantes da arquitetura. Em vez de armazenar AWS_ACCESS_KEY e AWS_SECRET_KEY como secrets no GitHub, usamos OIDC (OpenID Connect) para que o GitHub Actions troque um token temporário por credenciais AWS.

# Registra o GitHub como provedor OIDC na AWS
resource "aws_iam_openid_connect_provider" "github" {
  url             = "https://token.actions.githubusercontent.com"
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = ["ffffffffffffffffffffffffffffffffffffffff"]
}

# Role que o GitHub Actions vai assumir
resource "aws_iam_role" "github_actions_role" {
  name = "github-actions-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Principal = {
        Federated = aws_iam_openid_connect_provider.github.arn
      }
      Action = "sts:AssumeRoleWithWebIdentity"
      Condition = {
        StringEquals = {
          "token.actions.githubusercontent.com:aud" = "sts.amazonaws.com"
        }
        StringLike = {
          "token.actions.githubusercontent.com:sub" = "repo:meu-usuario/meu-repo:ref:refs/heads/main"
        }
      }
    }]
  })
}

Por que isso importa? Credenciais estáticas são um risco de segurança. Com OIDC, as credenciais são temporárias e o acesso é restrito a uma branch específica de um repositório específico. Mesmo que alguém tenha acesso ao repositório, não consegue assumir a role a partir de outra branch.

Dockerfile Multi-Stage

Usamos um build multi-stage para separar o ambiente de compilação do ambiente de execução, resultando em uma imagem final menor e mais segura:

# Stage 1: Build
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY ["MeuProjeto/MeuProjeto.csproj", "MeuProjeto/"]
RUN dotnet restore "MeuProjeto/MeuProjeto.csproj"
COPY . .
WORKDIR "/src/MeuProjeto"
RUN dotnet build -c Release -o /app/build

# Stage 2: Publish
FROM build AS publish
RUN dotnet publish -c Release -o /app/publish /p:UseAppHost=false

# Stage 3: Runtime
FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS final
WORKDIR /app
EXPOSE 8080
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "MeuProjeto.dll"]

Benefícios do multi-stage:

A imagem final contém apenas o runtime, não o SDK completo
Reduz significativamente o tamanho da imagem
O código-fonte não fica presente na imagem de produção

Pipeline de CI

A primeira pipeline roda automaticamente quando um Pull Request é aberto contra a branch main. Seu objetivo é validar que o código compila e que os testes passam.

name: PR Validation

on:
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '10.0.x'

      - name: Restore
        run: dotnet restore MinhaSolution.sln

      - name: Build
        run: dotnet build MinhaSolution.sln --no-restore -c Release

  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup .NET
        uses: actions/setup-dotnet@v4
        with:
          dotnet-version: '10.0.x'

      - name: Run Tests with Coverage
        run: |
          dotnet test MinhaSolution.sln \
            --collect:"XPlat Code Coverage" \
            --results-directory ./coverage

O que acontece nesta pipeline:

Job build — Compila a solução para garantir que não há erros de compilação
Job test — Roda os testes unitários com cobertura de código usando Coverlet

Separar em dois jobs traz clareza: se o build falha, você sabe que é erro de compilação. Se o test falha, o código compila mas tem um bug.

Protegendo a Branch Main

Com a pipeline de CI configurada, é fundamental garantir que nenhum código chegue à main sem passar pela validação. Para isso, configuramos uma branch protection rule no GitHub.

Acesse Settings > Branches > Add branch protection rule no seu repositório e configure:

Branch name pattern: main
Marque Require a pull request before merging — impede push direto na main
Marque Require status checks to pass before merging — bloqueia o merge até que os checks passem
Em Status checks that are required, busque e adicione os jobs da pipeline de CI:
- build
- test

Nota: Na primeira vez que configurar, os status checks podem não aparecer na busca. Eles só ficam disponíveis após a pipeline rodar pelo menos uma vez no repositório. Abra um PR de teste para que os checks sejam registrados.

Configurando as Secrets no GitHub

Antes de configurar a pipeline de deploy, é necessário cadastrar as secrets no repositório do GitHub. A pipeline de CD depende delas para autenticar na AWS e saber para onde enviar a imagem Docker.

Acesse Settings > Secrets and variables > Actions > New repository secret no seu repositório e crie as seguintes secrets:

Secret	Valor	Exemplo
`AWS_ROLE`	O ARN completo da IAM Role criada para o GitHub Actions	`arn:aws:iam::123456789012:role/github-actions-role`
`ECR_REPOSITORY`	A URI completa do repositório ECR (não apenas o nome)	`123456789012.dkr.ecr.us-east-1.amazonaws.com/minha-app-repository`
`AWS_ACCOUNT_ID`	O ID numérico da sua conta AWS	`123456789012`

Atenção: Um erro comum é colocar apenas o nome do repositório ECR (ex: minha-app-repository) na secret ECR_REPOSITORY. O valor correto é a URI completa que inclui o domínio do ECR. Você pode obter essa URI no console da AWS em ECR > Repositories ou via CLI:

aws ecr describe-repositories --repository-names minha-app-repository \
  --query "repositories[0].repositoryUri" --output text

Da mesma forma, a secret AWS_ROLE deve conter o ARN (Amazon Resource Name) completo da role, não apenas o nome. Para consultar:

aws iam get-role --role-name github-actions-role \
  --query "Role.Arn" --output text

Com as secrets configuradas, a pipeline de deploy consegue autenticar via OIDC, fazer push da imagem para o ECR e disparar o deploy no ECS.

Pipeline de CD

Quando o PR é aprovado e mergeado na main, a pipeline de deploy entra em ação:

name: Build and Deploy

on:
  push:
    branches: [main]

permissions: #permissões necessárias para autenticação OIDC
  id-token: write
  contents: read 

env:
  AWS_REGION: us-east-1

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS Credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ROLE_ARN }}
          aws-region: ${{ env.AWS_REGION }}

      - name: Login to Amazon ECR
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build Docker Image
        run: docker build -t minha-app .

      - name: Tag Image
        run: docker tag minha-app:latest ${{ secrets.ECR_REPOSITORY }}:latest

      - name: Push to ECR
        run: docker push ${{ secrets.ECR_REPOSITORY }}:latest

      - name: Deploy to ECS
        run: |
          aws ecs update-service \
            --cluster minha-app-cluster \
            --service minha-app-service \
            --force-new-deployment

O que acontece nesta pipeline:

Autenticação OIDC — O GitHub troca seu token JWT por credenciais AWS temporárias
Login no ECR — Autentica o Docker no registro da AWS
Build e Push — Constrói a imagem Docker e envia para o ECR
Deploy — Dispara um novo deployment no ECS, que puxa a imagem atualizada e substitui o container antigo

O --force-new-deployment garante que o ECS vai iniciar uma nova task mesmo que a tag da imagem (latest) não tenha mudado.

Acessando a Aplicação após o Deploy

Após a pipeline de CD concluir com sucesso, a aplicação estará rodando no ECS Fargate. Como configuramos assign_public_ip = true no Terraform, a task recebe um IP público que pode ser usado para acessar a API.

Obtendo o IP público pelo Console AWS

Acesse ECS > Clusters > minha-app-cluster
Clique na aba Tasks
Clique na task em execução (status RUNNING)
Na seção Network, copie o Public IP
Acesse no navegador: http://<PUBLIC_IP>:8080

Obtendo o IP público via CLI

# 1. Obtenha o ARN da task em execução
TASK_ARN=$(aws ecs list-tasks \
  --cluster minha-app-cluster \
  --service-name minha-app-service \
  --query "taskArns[0]" --output text)

# 2. Obtenha o ID da interface de rede (ENI)
ENI_ID=$(aws ecs describe-tasks \
  --cluster minha-app-cluster \
  --tasks $TASK_ARN \
  --query "tasks[0].attachments[0].details[?name=='networkInterfaceId'].value" \
  --output text)

# 3. Obtenha o IP público
aws ec2 describe-network-interfaces \
  --network-interface-ids $ENI_ID \
  --query "NetworkInterfaces[0].Association.PublicIp" \
  --output text

Importante: O IP público muda toda vez que uma nova task é criada (ou seja, a cada deploy). Para um ambiente produtivo, o ideal é utilizar um Application Load Balancer (ALB) ou um domínio com Route 53 apontando para o serviço ECS, garantindo um endereço fixo. Para fins de estudo, o IP público direto é suficiente.

Segurança: OIDC em Detalhe

Vale reforçar a importância do OIDC neste fluxo. O modelo tradicional funciona assim:

❌ Modelo Tradicional:
   GitHub Secrets → AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY
   - Credenciais estáticas que nunca expiram
   - Se vazadas, acesso total até serem rotacionadas manualmente

Com OIDC:

✅ Modelo OIDC:
   GitHub Actions → JWT Token → AWS STS → Credenciais Temporárias
   - Credenciais expiram automaticamente
   - Escopo restrito: apenas uma branch de um repositório específico
   - Sem segredos de longa duração armazenados

A configuração requer:

Registrar o GitHub como OIDC Provider na AWS (via Terraform)
Criar uma IAM Role com trust policy apontando para o repositório
No workflow, usar permissions: id-token: write e a action configure-aws-credentials com role-to-assume

Fluxo Completo: Do Commit ao Deploy

Resumindo o ciclo de vida de uma mudança:

1. git checkout -b feature/minha-feature
2. # Desenvolve e commita
3. git push origin feature/minha-feature
4. # Abre Pull Request → Dispara pr-validation.yml
   │
   ├── ✅ Build compila com sucesso
   └── ✅ Testes passam com cobertura
   │
5. # Code review + Aprovação
6. # Merge na main → Dispara build-and-deploy.yml
   │
   ├── 🔐 Autenticação via OIDC
   ├── 🐳 Build da imagem Docker (multi-stage)
   ├── 📦 Push para o ECR
   └── 🚀 Deploy no ECS Fargate
   │
7. # Nova versão rodando em produção

Considerações Finais

Este setup demonstra como é possível construir uma pipeline profissional de CI/CD com ferramentas modernas e boas práticas:

Infraestrutura como Código — Toda a infraestrutura é versionada e reproduzível
Autenticação Keyless — OIDC elimina o risco de credenciais estáticas
Serverless Containers — Fargate remove a necessidade de gerenciar servidores
Separação CI/CD — Validação em PRs e deploy apenas na main
Imagens otimizadas — Multi-stage build reduz a superfície de ataque

O custo de infraestrutura para um setup como esse é mínimo — com Fargate usando 0.25 vCPU e 512MB de memória, o custo fica na faixa de poucos dólares por mês para ambientes de estudo e projetos pequenos.

A barreira de entrada para CI/CD profissional diminuiu muito. Ferramentas como GitHub Actions e Terraform tornam acessível o que antes exigia equipes dedicadas de DevOps. O importante é começar simples, entender cada peça, e evoluir conforme a necessidade.

Este artigo foi escrito com base em um projeto prático de estudo. Todo o código-fonte está disponível publicamente neste repositório do GitHub.

Criei uma pipeline de planejamento no OpenCode e olha no que deu

Clinton Rocha — Mon, 09 Mar 2026 04:37:00 +0000

Você é como eu e vem buscando formas de otimizar o uso de ferramentas como o OpenCode? Talvez este conteúdo te ajude a ter novas ideias e até mesmo entender alguns fluxos dessa e de outras ferramentas.

Enquanto eu estudava a documentação do OpenCode, encontrei a aba de plugins feitos pela comunidade. Ali, encontrei três plugins que, na minha visão, se complementam bem. Na verdade, um deles eu já utilizava: o Plannotator.

A partir disso, comecei a estudar como funcionava os comandos, agentes e como eu poderia fazer um fluxo que fizesse sentido e principalmente que funcionasse, calma que já te explico oq cada um dos plugins fazem e qual a ideia final da integração.

Índice

Como eu estava usando o OpenCode
Objetivo da integração
Plannotator: Revisão Visual
Octto: Coleta estruturada de contexto
Subtask2: Orquestração de Pipeline
Comandos
Considerações
Referências

Como eu estava usando o OpenCode

Após começar a utilizar o OpenCode, notei o quão importante é o uso do módulo de planejamento e, principalmente, não apenas o planejamento em si, mas também as perguntas que são feitas durante esse processo. O resultado dessas duas novas abordagens (planejamento e perguntas) melhora bastante não só o código produzido, mas também a minha compreensão sobre a regra de negócio, além de comportamentos e fluxos do sistema.

Mesmo com todas essas descobertas que trouxeram otimizações para o processo, eu ainda sentia que dava para melhorar mais.

O fluxo de uso do OpenCode era basicamente o seguinte: eu enviava o prompt, a ferramenta vasculhava o código para obter contexto, depois vinham algumas perguntas e, em seguida, ela ia para a parte de build, ou seja, para colocar em prática o que tinha sido planejado.

Objetivo da integração

A ideia vai ser conseguir extrair o máximo de contexto com o Octto, usar o subtask2 para orquestrar os comandos e visualizar o plano final com Plannotator.

+---------------------------------------------------------------+
|                                                               |
|  IDEIA -> CONTEXTO -> PLANO -> REFINAMENTO -> REVISAO -> OK   |
|                                                               |
+---------------------------------------------------------------+

O resultado é um único comando que orquestra todo o processo:

/generate-plan "descrição do objetivo"

Plannotator: Revisão visual

O primeiro plugin chegou até mim por recomendação de uma amiga da comunidade (He4rtDevs), a Cherry, e o plugin era o Plannotator.

Esse plugin basicamente faz com que, ao final de um planejamento, seja aberta uma página no navegador contendo todo o plano gerado. Isso facilita muito a visualização em comparação com o terminal. Na interface do navegador, você consegue selecionar trechos do planejamento e dar feedback, que retorna para o processo de planejamento. Também é possível aprovar o plano e seguir diretamente para a etapa de build, ou seja, aplicar o que foi planejado.

Octto: Coleta estruturada de contexto

O Octto quando você envia o primeiro prompt, ele abre uma página no navegador com perguntas relacionadas ao que você pediu inicialmente. Essa página funciona como uma interface interativa de brainstorming. Conforme você responde às perguntas, o sistema utiliza essas respostas para gerar novas perguntas dentro da mesma sessão, aprofundando o entendimento do problema e ajudando a estruturar melhor o contexto antes de seguir para as próximas etapas, ao final ele gera um arquivo .md no diretório /docs/plans dentro do projeto.

A unica configuração que adicionei a ele, foi uma que faz com que a primeira pergunta seja um campo de texto livre onde o usuário consiga descrever o contexto com maior liberdade (colocar uma task completa, por exemplo).

Fluxo de Funcionamento

+----------------------+
|       ask_text       |  <-- Primeira ação obrigatória
+----------+-----------+
           |
           | Campo de texto no browser:
           | "Descreva com detalhes o que
           | você quer planejar..."
           v
+----------------------+
|   create_brainstorm  |  <-- Agente inicia sessão
+----------+-----------+      com contexto coletado
           |
           | Define branches de exploração
           v
+--------------------------------------------------------------+
|                    BRANCHES DE EXPLORAÇÃO                    |
|                                                              |
|  +----------------+  +-------------------+  +---------------+|
|  | Motivação &    |  | Requisitos &      |  | Riscos &      ||
|  | Objetivos      |  | Restrições        |  | Dependências  ||
|  +--------+-------+  +---------+---------+  +-------+-------+|
|           |                    |                    |        |
+-----------+--------------------+--------------------+--------+
            |
            v
+----------------------+
|      BROWSER UI      |
|                      |
|  [ Pergunta 1 ]      |
|  [ Pergunta 2 ]      |
|  [ Pergunta N ]      |
|                      |
|      [Responder]     |
+----------+-----------+
           |
           | Usuário responde
           v
+----------------------+
| await_brainstorm_    |
| complete             |  <-- Agente aguarda respostas
+----------+-----------+
           |
           | Sintetiza respostas
           v
+----------------------+
|      docs/plans/     |
| 2026-03-08-objetivo  |  <-- Arquivo gerado
|        .md           |
+----------------------+

Configuração via Fragments

O comportamento do Octto é customizado através de fragments, instruções adicionadas ao prompt dos agentes internos:

{
    "fragments": {
        "octto": [
            "Sempre pergunte a motivação e o 'porquê' das mudanças",
            "Gere nomes de arquivo no formato: YYYY-MM-DD-slug.md",
            "Salve os planos em docs/plans/"
        ],
        "probe": [
            "Priorize perguntas sobre motivações e restrições",
            "Inclua perguntas sobre requisitos não-funcionais"
        ],
        "bootstrapper": [
            "Crie branches focados em: requisitos, arquitetura, riscos"
        ]
    }
}

Função de cada agente interno:

bootstrapper: cria a estrutura inicial de branches
probe : gera perguntas de aprofundamento
octto: define o comportamento geral da coleta de contexto

Subtask2: Orquestração de pipeline

O Subtask2 permite encadear comandos de forma sequencial. Quando um comando termina, o próximo da cadeia é executado automaticamente.

Nesse meu contexto só vou usar a funcionalidade de return, mas esse plugin tem muitas outras funcionalidades interessantes como:

loop de subtarefas até que a condição do usuário seja atendida
paralela de subtarefas simultaneamente - PR pendente.
$TURN[n] passa turnos da sessão (mensagens do usuário/assistente).
{as:name} + $RESULT[name] captura e referência as saídas das subtarefas.

Sintaxe de Return Chain

---
subtask: true
return:
- /comando-1
- /comando-2
- /comando-3
---

Comandos

Com o subtask2, consigo adicionar comandos ao fluxo, e isso abre muitas possibilidades. Mas, por enquanto, estou com os pés no chão e vou fazer um fluxo simples com alguns novos comandos.

Eu criei esses comandos com o único intuito de usar na pipeline.

Comando Principal

O comando que vai dar inicio a todo o fluxo, vai ser o /generate-plan ao executar, ele da inicio a pipeline de planejamento.

Você é livre para escolher qualquer nome para o comando, para escolher o nome desse aqui eu só segui as vozes da minha cabeça.

Caso queira saber mais sobre como criar e configurar comandos no opencode, a doc é legalzinha.

/generate-plan refatorar sistema de autenticação
/generate-plan "adicionar suporte a múltiplos gateways de pagamento"

As aspas são opcionais: tudo após o comando é passado como $ARGUMENTS.

---
description: Pipeline completo de planejamento 
agent: octto
subtask: true
return:
- /refine-plan
- /review-plan
---

prompt aqui, e lembre de usar o $ARGUMENTS

Caso você queira ver como deixei o meu prompt usado no comando generate-plan é só ir no gist.

Todos os comandos podem ser usados individualmente/isolado no OpenCode, a unica diferença ao usar um comando com o subtask é que ele vai ser executado em um contexto diferente.

Refinamento Técnico

O /refine-plan tem como objetivo expandir um plano existente com detalhes arquiteturais.

/refine-plan # usa plano mais recente
/refine-plan docs/plans/meu-plano.md # plano específico

refine-plan:

---
description: Expande e refina tecnicamente um plano existente com arquitetura e diagramas
subtask: true
---

Mesma coisa que o anterior, aqui você consegue adicionar a instrução que você quiser.

No meu caso, o prompt que estou sando tá no gist 'refine-plan.md'.

Revisão Visual

Por último vem o comando /review-plan com o objetivo de mandar o plano para revisão interativa via Plannotator.

/review-plan # usa plano mais recente
/review-plan docs/plans/meu-plano.md # plano específico

Importante: Este comando não usa subtask: true. Ele roda na sessão primária para que a ferramenta submit_plan possa abrir a interface do Plannotator no browser corretamente. Comandos rodando como subtarefa não conseguem inicializar a UI do browser.

Fluxo Completo de Execução:

Considerações

O mais importante de tudo: funcionou? Sim. É uma bazuca? Sim, hahahaha. Esse projeto acabou saindo porque entrei em hiperfoco ao me fazer a pergunta “será que funciona?”. No fim, tive minha resposta.

Olhando para a usabilidade no dia a dia, acredito que os melhores momentos para utilizar algo assim são em novas features, refatoração de projeto e até mesmo para estruturar estudos, quem sabe. Só não use para algo como “quero trocar a cor de um botão”, aí você acaba complicando.

O ponto que mais curti foi o Octto, com as perguntas geradas de forma dinâmica. Aquilo ali, ao meu ver, auxilia na contextualização de uma baita maneira. Fora que é possível dar instruções para as branches dele, especificar qual tipo de input você quer ou não quer, entre outras coisas (vale ler a documentação).

Já o subtask2 abre portas para muita coisa. Como eu tinha dito antes, acabei indo pelo simples, mas alguém com a mente mais aberta provavelmente vai conseguir extrair o melhor da ferramenta.

Eu pretendo criar novos comandos, refinar mais os prompts e ver o que acontece. É isso, obrigado por ler até aqui e tente brincar com isso ai.

Como meu Tech Lead fala:

Faça codigo inútil e quebre alguma coisa.

DEV Community: He4rt Developers

Produto 4 Devs

Tabela de Conteúdo

1. Prólogo

2. O que é um Produto? (Sem enrolação)

3. Por que um dev deveria se importar?

4. Diferença entre Projeto e Produto:

Projeto:

Produto:

5. Ciclo de vida de Produto:

6. Mas o que importa o Dev entender do ciclo de vida do produto?

7. Conclusão:

8. Se interessou?

Métricas de qualidade de software na era da IA

Antes das métricas: entenda o momento do seu time

Métricas para stakeholders

Mean Time to Resolve/Repair (MTTR)

Cobertura de testes automatizados

DORA Metrics

Métricas para o time

Root Cause Analysis

Bugs identificados antes do lançamento

Retrabalho

Conclusão

Como escolher eventos de tecnologia para participar

Por que ir a esses eventos?

Como eu escolhia os eventos que iam fazer diferença pra mim?

Onde eu posso achar eventos de tecnologia?

E você? Como costuma escolher quais eventos de tecnologia ir?

Ownership: do "temos um rojão na mão" até "não precisa mais pensar nisso"

Tabela de Conteúdo

1. Prólogo

2. Entenda o problema real

3. Projete antes de codar

4. Execute

5. Verifique (em produção)

6. Comunique

7. Acompanhe

É muita coisa. E olha que ainda tem mais.

De 6 horas para 40 segundos: como um índice de banco de dados salvou um job crítico de produção

De 6 horas para 40 segundos: como um índice de banco de dados salvou um job crítico de produção

Índice

O cenário: um job noturno que virou um problema diurno

O problema cresceu junto com a tabela

O diagnóstico: o Azure Application Insights apontou o caminho

Antes da correção

A solução: um índice bem posicionado

Depois da correção

O impacto real: economia de tempo total por dia

Mas afinal: o que é um índice de banco de dados?

A analogia do livro

O que um índice resolve?

Como identificar quando você precisa de um índice

Anatomia do índice que resolveu o problema

Conclusão

Por que eu começo 10 projetos e não termino nenhum?

Table of contents

O prazer de começar

O momento em que tudo desmorona

O objeto brilhante

A culpa que ninguém fala

Não é preguiça. É neurologia.

Conclusão

O que uma usina nuclear tem a ver com o seu processo de QA?

O que aconteceu em Chernobyl?

E o que isso tem a ver com software?

O maior problema: risco tratado de forma rasa

Ouça sua equipe

Analise antes de agir

Conclusão

De front-end para UX, e de volta ao código: o que significa ser Design Engineer em 2026

Minha trajetória: 5 anos de front-end, 5 anos de UX

O que é design engineer em 2026?

Como front-end e UX mudam sua forma de ver produto

Por que estou voltando ao código agora

Como estou usando IA no processo de aprendizado

Design Engineer não é um cargo. É uma forma de pensar

O que vem por aí: UX data-driven e componentes React

Você também está nesse meio-termo entre UX e código?

Construí um gerador de playlists no Spotify com Claude

O Spotify não aceita `localhost`

O `NextRequest` normaliza URLs pra `localhost`

A solução: `Auth()` direto com `Request` nativo