Voidr

🎯 14 módulos cobertos em 3 semanas Com mais uma BU estratégica nascendo, o desafio da Valid era escalar qualidade sem aumentar headcount na mesma proporção, além de cobrir múltiplos produtos de missão crítica demonstrando maturidade desde o início para os stakeholders. A solução foi contar com um apoio especializado da Voidr para: ✅ Garantir o funcionamento dos fluxos críticos ✅ Interceptar defeitos antes de irem para produção ✅ Aperfeiçoar a cultura de qualidade no time de desenvolvimento Confira mais detalhes no nosso case com a maior especialista em identidade digital do Brasil. https://lnkd.in/dih_4n3J

Agentes de IA multiplicaram o volume de código que chega em produção mas validação de tudo isso ainda escala por headcount. É justamente nessa distância que o incidente crítico aparece. A partir de hoje a Voidr é membro do Oracle PartnerNetwork e está publicada no Oracle Cloud Marketplace. O que isso muda para quem opera em Oracle Cloud: • A Voidr pode rodar dentro da sua própria tenancy OCI (BYOC): código, telemetria e sessões de usuário não saem da sua infra. Em conta regulada, essa costuma ser a primeira pergunta do infosec, agora a resposta vem validada no ecossistema Oracle. • A avaliação começa por um canal que sua empresa já conhece: a listagem no marketplace, com demo técnica e proposta desenhada para o seu contexto. IA para software de missão crítica, agora dentro do ecossistema Oracle.

A separação entre bug e incidente está com os dias contados. Não porque sejam a mesma coisa. Não são. Mas porque está ficando caro tratar um sem o contexto do outro. Hoje a divisão é familiar. O bug entra no backlog da engenharia. O incidente mobiliza operações. Só que o cliente não sabe em qual fila o problema caiu. Ele só sabe que o sistema está no ar e, mesmo assim, não consegue concluir o que precisava. No primeiro episódio do Bug In Prod Podcast, recebemos o Albert Martins Vieira, IT Lead na Serasa Experian. Ele trabalha em uma operação com dezenas de produtos críticos, que precisam funcionar 24 horas por dia. Em um momento da conversa, ele disse: “A qualidade realmente começa no pós-deploy.” Fiquei pensando nisso. Às vezes, o código funciona e a regra de negócio não. Às vezes, uma jornada degrada sem derrubar nenhum serviço. O time resolve o incidente, fecha a sala e segue. A causa pode até virar uma tarefa, mas nem sempre isso protege o próximo deploy. Com IA ajudando a escrever e revisar código, mais mudanças vão chegar à produção. Se bugs ficam de um lado e incidentes do outro, perdemos justamente o contexto que ajudaria o próximo humano ou agente a não repetir o problema. Essa desconexão já aparece nos dados. No AI Accountability Report da GitLab, 34% das organizações que tiveram incidentes no último ano não conseguiram determinar se código gerado por IA contribuiu. Só 28% disseram ter ferramentas do ciclo de desenvolvimento plenamente integradas, com dados e fluxos compartilhados. É uma fronteira que a gente vê cada vez menos com nossos clientes e parceiros na Voidr. Os casos que importam atravessam código, operação e a jornada do cliente. Separar as filas não separa o problema. Tenho uma aposta: incidentes vão começar a gerar testes, regras e evidências que acompanham os próximos PRs. Não como documentação para consultar depois, mas como parte do critério para publicar uma mudança. Produção mostra o que realmente importou. O próximo PR precisa saber. Hoje, quando um incidente termina na sua empresa, o aprendizado volta para o código ou fica no postmortem? Se quiser ouvir o raciocínio completo do Albert Martins Vieira, vale assistir ao episódio do Bug In Prod Podcast. #EngenhariaDeSoftware #QualidadeDeSoftware #IA #BugInProd

𝗔 𝗨𝗯𝗲𝗿 𝗰𝗼𝗻𝘀𝘂𝗺𝗶𝘂 𝗼 𝗼𝗿𝗰̧𝗮𝗺𝗲𝗻𝘁𝗼 𝗮𝗻𝘂𝗮𝗹 𝗱𝗲 𝗜𝗔 𝗽𝗮𝗿𝗮 𝗰𝗼́𝗱𝗶𝗴𝗼 𝗲𝗺 𝗮𝗽𝗲𝗻𝗮𝘀 𝟰 𝗺𝗲𝘀𝗲𝘀. O problema não foi gastar demais. 𝗙𝗼𝗶 𝗻𝗮̃𝗼 𝗰𝗼𝗻𝘀𝗲𝗴𝘂𝗶𝗿 𝗽𝗿𝗼𝘃𝗮𝗿 𝗼 𝗾𝘂𝗲 𝗲𝘀𝘀𝗲 𝗴𝗮𝘀𝘁𝗼 𝗽𝗿𝗼𝗱𝘂𝘇𝗶𝘂. A empresa incentivou a adoção com um ranking interno baseado no uso das ferramentas. → Agentes autônomos já produzem cerca de 10% do código commitado. → O consumo de Claude Code explodiu. → Mas ainda é difícil ligar esse aumento a mais funcionalidades úteis para os clientes. Isso resume boa parte da conversa sobre produtividade com IA: 𝗘𝘀𝘁𝗮𝗺𝗼𝘀 𝗺𝗲𝗱𝗶𝗻𝗱𝗼 𝘂𝘀𝗼, 𝗻𝗮̃𝗼 𝗶𝗺𝗽𝗮𝗰𝘁𝗼. Mais tokens ↓ Mais código ↓ Mais PRs ↳ 𝗡𝗮̃𝗼 𝗻𝗲𝗰𝗲𝘀𝘀𝗮𝗿𝗶𝗮𝗺𝗲𝗻𝘁𝗲 𝗺𝗮𝗶𝘀 𝘃𝗮𝗹𝗼𝗿. Tudo isso aparece no dashboard. O custo da mudança aparece meses depois. É quando alguém encontra quatro versões da mesma lógica e precisa descobrir qual delas pode ser alterada sem quebrar as outras. O relatório 𝘛𝘩𝘦 𝘔𝘢𝘪𝘯𝘵𝘢𝘪𝘯𝘢𝘣𝘪𝘭𝘪𝘵𝘺 𝘎𝘢𝘱, da GitClear, analisou 623 milhões de mudanças. 𝗘𝗺 𝟮𝟬𝟮𝟮: → Refatorar era 2x mais comum do que duplicar código. 𝗘𝗺 𝟮𝟬𝟮𝟲: → Duplicar se tornou quase 5x mais comum do que refatorar. → Copy/paste: 9,4% → 15,7% → Refatoração: 21% → 3,8% Isso não prova que “código humano é bom” e “código de IA é ruim”. 𝗣𝗿𝗼𝘃𝗮 𝗮𝗹𝗴𝗼 𝗺𝗮𝗶𝘀 𝗱𝗲𝘀𝗰𝗼𝗻𝗳𝗼𝗿𝘁𝗮́𝘃𝗲𝗹: Nossos incentivos premiam quem fecha o ticket e punem quem para para entender o sistema. Com IA, essa distorção ganhou escala. → O PR gerado em minutos aparece como produtividade. → Os dias de arqueologia necessários para modificá-lo depois aparecem como lentidão do time. 𝗖𝗼́𝗱𝗶𝗴𝗼 𝗳𝗶𝗰𝗼𝘂 𝗯𝗮𝗿𝗮𝘁𝗼. 𝗘𝗻𝘁𝗲𝗻𝗱𝗲𝗿 𝗺𝘂𝗱𝗮𝗻𝗰̧𝗮 𝗳𝗶𝗰𝗼𝘂 𝗰𝗮𝗿𝗼. Por isso, a nova régua de produtividade não pode ser quanto código entrou. Precisa ser: → Quanta mudança o sistema consegue absorver → Sem perder compreensão → Sem perder confiabilidade → Sem perder a capacidade de voltar atrás Se você não consegue ligar: 𝗧𝗼𝗸𝗲𝗻𝘀 → 𝗳𝗲𝗮𝘁𝘂𝗿𝗲𝘀 𝘂́𝘁𝗲𝗶𝘀 → 𝘀𝗶𝘀𝘁𝗲𝗺𝗮 𝗰𝗼𝗺𝗽𝗿𝗲𝗲𝗻𝘀𝗶́𝘃𝗲𝗹 Você não escalou engenharia. 𝗩𝗼𝗰𝗲̂ 𝘀𝗼́ 𝗲𝘀𝗰𝗮𝗹𝗼𝘂 𝗴𝗲𝗿𝗮𝗰̧𝗮̃𝗼 𝗱𝗲 𝗰𝗼́𝗱𝗶𝗴𝗼. Seu time está usando IA para aumentar a capacidade de mudança ou apenas a quantidade de código? #EngenhariaDeSoftware #BugInProd #DeveloperProductivity

uma falha crítica no cursor ficou meses sem resposta. no windows, um projeto podia trazer um git.exe malicioso na raiz. ao abrir o workspace, o cursor podia executá-lo sem alerta. a @mindgard confirmou o problema no cursor 3.2.16 em 30 de abril de 2026. o bug era grave, mas o que veio depois também importa. a mindgard diz que avisou o cursor em 15 de dezembro de 2025. semanas depois, o ciso reconheceu que uma automação não enviou o convite do hackerone. o aviso foi reenviado, fechado como “informative”, contestado, reaberto e reproduzido. depois vieram meses sem atualização. as fontes não deixam claro o estado atual da correção. esse não é só um caso de segurança. é um problema real que se perdeu antes de virar mudança de engenharia. um problema real precisa chegar a engenharia com versão, entrada, comportamento e impacto. depois da correção, essa evidência deveria virar teste de regressão. sem esse ciclo, o time pode fechar o ticket sem melhorar o sistema. a falha some da fila, mas o aprendizado também. o mínimo é preservar a evidência, reproduzir o problema, validar a correção e proteger o próximo pr. encontrar a falha é só o começo. o valor está em devolver esse aprendizado para a próxima mudança. quando um problema real chega ao seu time, ele vira contexto para o próximo pr ou morre no ticket? #qualidadedesoftware #resilienciadesoftware #buginprod

Código ficou barato. Confiança, não. A IA cospe em minutos o que um time levava um mês pra escrever. Mas o cliente não sente o código, sente o sistema em produção, com milhões de consultas rodando sob estresse. Foi sobre isso a conversa com o Albert Vieira, IT Lead na Serasa Experian, no último episódio do Bug in Prod. A conclusão dele bate com o que a gente vê todo dia na Voidr: A qualidade não se prova na homologação. Se prova em produção. Homologação é ensaio com roteiro. Produção é palco, com plateia. Por isso o jogo mudou: observabilidade que mostra o que o cliente sente na ponta, testes sintéticos validando as jornadas críticas em tempo real, e um time que sabe o que cada falha custa pro negócio. Ferramenta se compra. Isso não. Quem entender primeiro, escala. Quem não entender, descobre o bug pelo print do cliente. Episódio completo: https://lnkd.in/dTTyBgqA #IA #EngenhariaDeSoftware #Observabilidade #SRE #DevOps