Hey! 👋
Galera agora sim hein, calendário de meetups do mês de setembro publicado!
Tá tudo organizado aqui no site, esse mês vamos ter sete meetups em várias cidades do Brasil e também o online da Codecon Ladies, que aliás estão todos convidados pra participar! Só bora!
🫂 Meetups Codecon
Gabriel Nunes (@nunesgabriel)
O custo de não entender o código
Um PR de oitocentas linhas chega pra revisão. A descrição é impecável, os testes passam e tem até diagrama. Depois de vinte minutos lendo, você encontra um retry estranho e uma transação atravessando um serviço que não deveria. Pergunta pro autor o motivo e a resposta vem rápida: “Não sei, foi o Claude que colocou”. Quem levou vinte minutos pra gerar a mudança acabou de te passar duas horas de trabalho.
A IA barateou a geração de código, mas verificar continua caro. E o código quase certo é o mais caro de todos: compila, passa nos testes, tem nomes bons e formatação perfeita. Durante anos, código ruim tinha cara de código ruim, e isso ajudava na revisão. Com IA, essa pista sumiu. Uma função chamada verifyToken pode não checar assinatura nenhuma e ainda parecer exatamente o que você esperava ler.
A conta cai sempre no mesmo lugar. Quem gera o PR fecha o ticket e leva o crédito. O revisor fica com a verificação, e quem opera o sistema herda o incidente meses depois. Enquanto isso, a meta sobe: numa pesquisa da HackerRank, 84% dos líderes de engenharia disseram ter aumentado as expectativas de produtividade por causa da IA. O dev que revisa com cuidado evita um incidente que nunca chega a acontecer.
A saída não é separar código escrito por humano de código escrito por IA, porque essa fronteira já não existe. O que importa é se alguém assume cada linha. Quem abre o PR precisa ler, entender e conseguir explicar o que está mandando, pra que o revisor não seja a primeira pessoa a olhar de verdade. “Foi o Claude” deveria pesar tanto quanto “copiei do Stack Overflow e nem li”.
O problema não é mais produzir código, mas garantir que alguém realmente o entendeu.
Segurança também é uma decisão de arquitetura
Quando falamos em segurança, muita gente ainda pensa em testes no fim do desenvolvimento ou em corrigir vulnerabilidades depois que elas aparecem.
Na prática, os problemas mais difíceis costumam nascer muito antes. Uma decisão de arquitetura, um fluxo de dados mal definido ou uma regra de negócio pouco protegida podem abrir espaço para riscos que nenhum scanner vai encontrar sozinho.
É por isso que uma boa modelagem de ameaças começa antes da primeira linha de código. O objetivo não é imaginar todos os ataques possíveis, mas entender profundamente o sistema que está sendo construído: quais componentes existem, como eles se comunicam, quais dados circulam entre eles e onde estão os pontos mais sensíveis. Só depois disso faz sentido discutir controles, mitigações e prioridades.
Essa forma de pensar faz parte da Engenharia do Asaas. Segurança não entra apenas na validação final de uma entrega. Ela participa das decisões técnicas desde a concepção das soluções, aproximando engenharia, arquitetura e segurança para construir produtos mais resilientes desde o início.
Se você acredita que boas decisões de arquitetura também são decisões de segurança, conheça as oportunidades abertas no Asaas!
🐑 Todo mundo tem a mesma IA
Se 95,5% dos devs brasileiros já usam IA pra programar, a ferramenta deixou de ser diferencial. Pra piorar, um estudo da METR mostrou que devs experientes ficaram 19% mais lentos com IA, mesmo jurando que tinham ficado mais rápidos. O texto abre uma série sobre as seis capacidades que separam quem rende com IA de quem só gera código mais rápido: DDD, software design, pensamento sistêmico, revisão rigorosa, pragmatismo na entrega e engenharia de contexto. Se a ferramenta é igual pra todo mundo, o diferencial passa a estar no que você sabe fazer com ela.
🔁 Pare de escrever prompt, comece a desenhar o loop
Em vez de ficar dando instruções pra um agente a cada tarefa, a proposta é criar um loop que faça isso sozinho. O texto mostra como combinar tarefas agendadas, worktrees, skills e subagentes para deixar o processo mais autônomo. Um arquivo fora da conversa registra o que já foi feito, já que o agente esquece tudo entre uma execução e outra. O loop pode até rodar sozinho, mas revisar o que ele fez continua sendo trabalho seu.
⚡ Por que o Linear é tão rápido?
No Linear, atualizar uma issue leva poucos milissegundos. Num app CRUD tradicional, muito mais. A explicação é que o banco que a interface lê fica no próprio navegador: a mudança aparece na hora e o servidor é sincronizado em segundo plano. Tem ainda code splitting agressivo, um service worker que baixa o app inteiro enquanto você ainda está na tela de login e animações curtíssimas. Tudo isso com React, MobX e Postgres, sem nenhum framework da moda.
🔪 Ferramenta boa também exige prática
Um designer da Shopify começou usando IA para tarefas pequenas e, quando viu, estava abrindo PR em produção. Num ajuste de espaçamento que parecia simples, o Claude resolveu tudo rapidinho ignorando regras do sistema que nem ele nem o designer conheciam. Foi um engenheiro que mostrou que o problema estava nos componentes compartilhados. A ideia do texto é simples: IA funciona melhor quando entra depois que a solução já tem forma, não antes. E o autor aprendeu isso do jeito mais doloroso possível.
Eventos
Esse sábado é o Staff Experience, um evento 100% online, pensado pra quem quer sair na frente: nomes como Mauricio Aniche (CTO na Alura), Waldemar Neto (Tech Leads Club), Loiane Groner (BNY) e outros especialistas dividem experiências reais sobre arquitetura de software na era da IA, engenharia agêntica e os bastidores das falhas que ninguém te conta.
Só R$ 42, lote único. Vagas limitadas.
YouTube
Rinha de IA! Colocamos 4 IAs diferentes para recriarem o Among Us em apenas 4 horas.
🎬 RECRIANDO O AMONG US: Rinha de IA
Meetups
Mês de setembro cheio de eventos no site, vem ver:
