1. Smart Sampa: 181 logins de guardas municipais expostos, a senha era o próprio número de registro e não tinha verificação em duas etapas.

2. Itaú compra uma startup de IA de Uberlândia por quase R$ 3 bilhões, mas o fundador é o mesmo da Zup, comprada pelo Itaú em 2019. Ainda dá pra ser startupeiro raiz?

3. QAs sêniores criaram agentes de IA tão bons que a empresa extinguiu o cargo e “promoveu” todo mundo a dev júnior.

4. Gov Food, Gov Bank, Gov Zap: jogar tudo no peito do gov.br? Só que vazaram 251 milhões de CPFs e a primeira multa da LGPD foi de R$ 14 mil.

5. Pra fechar, o PHP reina: se o PHP para, a sociedade treme.

Patrocinadores desse episódio:

🚀 CONTA DEV: https://links.chorume.dev/contadev-ig

🚀 SOLYD: https://solyd.link/deyvin

Apoie esse conteúdo aqui no substack ou se tornando membro no YT

1. R$ 2,5 milhões em placas RTX 5090 da Zotac desaparecem em Guarulhos e o dono da importadora grava um vídeo estilo Nicolas Ferreira. Será que a carga não tinha seguro?

2. Akita no Flow: toda profissão que é copy paste vai acabar, e o cara que só trocava a carinha na thumbnail já era.

3. Akita jogou água na minha cerveja: Qwen e os modelos open source não servem pra programar, então nada de IA local por enquanto.

4. Layoff na Flutter, dona de casas de apostas: até 1.400 demissões no Reino Unido e na Irlanda. Cadê o Sindipd?

5. Pra fechar, o meme do Filipe Deschamps com 43 anos e sem rugas contra o Jovem Tranquilão deixou os front-ends ofendidos.

Patrocinadores desse episódio:

🚀 CONTA DEV: https://links.chorume.dev/contadev-ig
🚀 FULL CYCLE: https://fcycle.co/21-10-lv-md-mba-ia

Apoie esse conteúdo aqui no substack ou se tornando membro no YT

Esse post acompanha a aula do canal:

Lá eu explico cada fundamento com calma.

Antes de colar qualquer prompt

• Roda num branch separado. Nada direto na main.

• Lê o plano que a IA propõe antes de aceitar. Todos os prompts mandam ela mostrar o plano primeiro.

• Migration nova você revisa antes de rodar. Banco de produção a IA não toca sem você olhar.

• Se você não entendeu o que o prompt faz, volta no resumo. Colar sem entender é deixar a IA te enrolar de novo.

A ordem que eu rodaria

1. Teste de integração (prompt 5), pra travar o comportamento antes de mexer em qualquer coisa

2. Nunca confie no cliente (prompt 3), que é a porta aberta

3. Race condition (prompt 1) e idempotência (prompt 2), que é dinheiro

4. Separação de responsabilidades (prompt 4), por último, com os testes já te protegendo

1. Race condition

O que é: duas requisições chegam juntas, as duas leem o mesmo valor e as duas gravam em cima dele.

Onde quebra: todo lugar que lê, decide e depois grava. Estoque, cupom, saldo, crédito, vaga, convite.

Sinal de que você tem: pedido duplicado no banco, estoque negativo, cupom usado mais de uma vez.

O erro caro: subir um Redis pra fazer lock, ou ler o estoque do cache pra ficar rápido.

O Martin Kleppmann escreveu um artigo conhecido sobre isso (How to do distributed locking), e a correção que ele propõe é um número de controle conferido pelo lugar onde você grava. Ou seja, o banco.

PROMPT:

Você é um engenheiro sênior revisando um app que eu construí com IA. Quero achar e corrigir race conditions (condições de corrida).

1. Varra o código e liste todo lugar que faz "ler, decidir e depois gravar": criação de pedido, baixa de estoque, uso de cupom, saldo, créditos, vagas, convites, contadores, qualquer recurso limitado.
2. Para cada ocorrência, explique em uma frase o que acontece se 2 requisições iguais chegarem no mesmo milissegundo (ex.: pedido duplicado, estoque negativo, cupom usado 2 vezes).
3. Proponha a correção mais simples que resolve no banco, nesta ordem de preferência:
   a. constraint única (unique index) que impede o registro duplicado;
   b. operação atômica no próprio banco (ex.: UPDATE estoque SET qtd = qtd - 1 WHERE id = X AND qtd > 0, conferindo as linhas afetadas);
   c. transação com lock da linha (SELECT ... FOR UPDATE) quando a regra for mais complexa.
4. No front, desabilite o botão durante o envio, mas trate isso como conforto de UX. A proteção de verdade fica no servidor e no banco.
5. Para cada correção, escreva um teste que dispara 2 requisições simultâneas e prova que só uma tem efeito.

Regras: não proponha Redis, fila, lock em memória ou qualquer infraestrutura nova se o banco resolve; se achar que precisa, me explique por que o banco não basta antes. Me mostre a lista completa e o plano antes de alterar qualquer arquivo. Toda migration nova deve ser revisada por mim antes de rodar. Se já existirem dados duplicados que impeçam criar a constraint, me avise e proponha como limpar, sem apagar nada sozinho.

2. Idempotência

O que é: repetir a mesma operação quantas vezes for e o resultado ser o mesmo de fazer uma vez só.

Onde quebra: webhook de pagamento.

Sinal de que você tem: cliente recebendo e-mail repetido, crédito somado duas vezes, assinatura duplicada, requisições duplicadas em servidor de terceiros.

Como resolve: uma tabela de eventos processados com o ID do evento como chave única.

Você é um engenheiro sênior especialista em pagamentos. Quero que todo webhook e todo endpoint de pagamento do meu app aceite repetição sem efeito duplicado (idempotência).

1. Liste todos os webhooks recebidos (Stripe ou outro gateway) e todos os endpoints que cobram, liberam plano, creditam saldo ou mandam e-mail transacional.
2. Webhooks:
   a. confirme que a assinatura do webhook é verificada com o corpo bruto da requisição antes de qualquer processamento;
   b. crie uma tabela de eventos processados com o ID do evento como chave única;
   c. ao receber um evento, tente gravar o ID primeiro; se já existir, responda 200 e não faça mais nada;
   d. não dependa da ordem de chegada dos eventos: quando precisar do estado atual, busque o objeto na API do gateway;
   e. responda 2xx rápido e mande o trabalho pesado para uma fila ou processamento assíncrono, se o projeto já tiver essa estrutura.
3. Chamadas que EU faço ao gateway (criar cobrança, assinatura, reembolso): envie uma idempotency key (UUID v4) gerada uma vez por operação de negócio e reaproveitada em caso de nova tentativa.
4. Endpoints do meu app que criam pedido ou pagamento: aceite um header Idempotency-Key do cliente e devolva a mesma resposta se a chave se repetir.
5. Escreva testes que enviam o mesmo evento 2 vezes, e 2 vezes ao mesmo tempo, e provam que o efeito acontece só uma vez.

Regras: mostre o plano antes de alterar código. Não mude valores, preços nem regras de cobrança. Não use dado pessoal (e-mail, CPF) como chave de idempotência.

3. Nunca confie no cliente

O que é: tudo que roda no navegador o usuário controla. Ele abre o DevTools, muda o que quiser e chama a tua API direto. Validação no front serve pra experiência ficar boa; quem decide é o servidor.

Onde quebra: preço, desconto, permissão ou limite de plano calculado só no front.

Sinal de que você tem: o Matt Palmer analisou 1.645 apps feitos no Lovable, olhando só a página inicial, e achou 170 com o RLS quebrado.

Como resolve: o servidor recalcula tudo e ignora o valor que veio do cliente.

PROMPT

Você é um auditor de segurança. Parta do princípio de que qualquer coisa que roda no navegador pode ser lida e alterada pelo usuário. Quero uma auditoria completa e um plano de correção.

1. Regras de negócio no front: liste todo cálculo de preço, desconto, frete, permissão, papel de admin, limite de plano ou validação que só existe no cliente. Para cada um, mova a regra para o servidor (API route, server action, edge function) e faça o servidor recalcular tudo, ignorando valores vindos do cliente.
2. Segredos: procure chaves e tokens no código do front e em variáveis que vão para o navegador (NEXT_PUBLIC_, VITE_, EXPO_PUBLIC_ ou equivalente). Classifique cada uma como pública por design (ex.: publishable/anon key do Supabase, publishable key do Stripe) ou secreta (service_role/secret key, chaves de OpenAI, Stripe secret, tokens de terceiros). Toda secreta sai do front, vai para o servidor, e me diga quais eu preciso rotacionar porque já foram publicadas.
3. Supabase (ou banco equivalente exposto por API):
   a. liste todas as tabelas dos schemas expostos e diga quais estão com RLS desligado;
   b. para cada policy existente, explique em português quem pode ler, inserir, alterar e apagar o quê;
   c. aponte policies permissivas demais, como USING (true), WITH CHECK (true) ou regras que não comparam com auth.uid();
   d. proponha policies mínimas: cada usuário só acessa as próprias linhas, e campos sensíveis (ex.: status de pagamento, papel, saldo) só mudam pelo servidor;
   e. confirme que a chave secreta (service_role) nunca é usada no navegador.
4. Gere um relatório final com: achado, risco (alto, médio, baixo), arquivo e linha, correção proposta.

Regras: primeiro só o relatório, sem alterar nada. Depois aplique as correções uma por vez, com migration separada para as policies, esperando meu OK em cada uma. Não desligue nenhuma proteção existente para "fazer funcionar".

4. Separação de responsabilidades

O que é: cada coisa na sua gaveta. A tela numa, a regra de negócio em outra, e quem conversa com banco, gateway de pagamentos e APIs de fora numa terceira.

Onde quebra: naquele arquivo gigante onde você pede pra IA mexer numa coisa e quebra outra do outro lado.

Sinal de que você tem: um arquivo que você tem medo de abrir, e toda alteração nele vira efeito colateral.

Como resolve: dividir em passos pequenos, sem mudar comportamento, com testes registrando como o arquivo funciona hoje antes do primeiro passo.

PROMPT

Você é um engenheiro sênior especialista em refatoração segura. O arquivo [CAMINHO DO ARQUIVO] ficou grande demais e toda alteração quebra outra coisa. Quero dividir em camadas sem mudar comportamento.

1. Mapeie o arquivo: liste cada função, componente e trecho, e classifique em uma destas camadas:
   a. UI (o que aparece na tela e captura evento do usuário);
   b. regra de negócio (cálculos, validações, decisões);
   c. acesso a dados e serviços externos (banco, Supabase, Stripe, APIs).
2. Aponte dependências cruzadas, código duplicado e estado global que dificultam a separação.
3. Proponha a nova estrutura de pastas e arquivos, seguindo o padrão que o projeto já usa. Nada de framework ou biblioteca nova.
4. Monte um plano em passos pequenos. Cada passo move um pedaço só, mantém os mesmos nomes públicos e deixa o app funcionando.
5. Antes do primeiro passo, confira se existem testes cobrindo o comportamento atual. Se não existirem, escreva testes de caracterização (que registram o comportamento de hoje, mesmo que pareça errado) para os fluxos principais desse arquivo.
6. Execute um passo por vez, rodando os testes ao final de cada um.

Regras: não corrija bugs nem mude regra de negócio durante a refatoração; se achar bug, anote numa lista separada. Não renomeie rotas, props públicas ou colunas do banco. Mostre o plano e espere meu OK antes do passo 1.

5. Teste de integração

O que é: um teste que chama a tua rota de verdade, com um banco de teste de verdade, e só finge o que é de fora (o webhook do gateway, o envio de e-mail).

Por que esse e não os outros: o agente de IA adora teste unitário porque mocka tudo, e aí o teste passa sem testar nada. O E2E (com Playwright, por exemplo) é lento e quebra à toa.

Como fica: no jeitão do RSpec, a frase do comportamento vem antes do teste. Em JS, com Vitest, é assim (exemplo ilustrativo):

describe('webhook de pagamento', () => {
  it('quando o mesmo evento chega 2 vezes, libera o plano 1 vez só', async () => {
    await post(webhook, eventoPago)
    await post(webhook, eventoPago)
    expect(await assinaturas(usuario)).toBe(1)
  })

  it('quando as 2 cópias chegam juntas, libera 1 vez só', async () => {
    await Promise.all([post(webhook, eventoPago), post(webhook, eventoPago)])
    expect(await assinaturas(usuario)).toBe(1)
  })
})

Você não precisa escrever isso. Precisa ler a frase do it e concordar com ela; a IA escreve o resto.

Onde quebra: sem esses testes, a IA mexe num lugar, quebra outro e quem descobre é o cliente.

Cuidado: teste de RLS só vale com banco de verdade. Supabase local ou um projeto só de teste. Banco de produção, nunca.

PROMPT:

Você é um engenheiro de qualidade. Quero cobrir os fluxos críticos do meu app com testes de integração, no estilo request spec do RSpec: cada teste chama a rota de verdade, com banco de teste de verdade, e só simula o que é de fora (gateway de pagamento, envio de e-mail, APIs de terceiros).

1. Leia o projeto e liste os fluxos críticos: cadastro, login, checkout, webhooks de pagamento e qualquer rota que mexe com dinheiro, permissão ou dado de outro usuário.
2. Para cada fluxo, escreva em português as frases de comportamento no formato describe / it ("quando..., então..."), cobrindo:
   a. o caminho feliz;
   b. erros esperados (pagamento recusado, campo inválido, usuário sem permissão);
   c. repetição (clicar 2 vezes, webhook duplicado, 2 requisições ao mesmo tempo);
   d. limites (estoque zerado, plano expirado, valor zero ou negativo);
   e. acesso indevido (usuário A tentando ler ou alterar dado do usuário B).
3. Me mostre as frases e espere eu confirmar ou corrigir. Eu sou a fonte da verdade sobre o comportamento esperado.
4. Configure o ambiente de teste com a ferramenta que o projeto já tem (se não tiver nenhuma, sugira a mais simples para a stack e espere meu OK). O banco de teste é separado: Supabase local, container ou projeto só de teste. Nunca aponte para o banco de produção.
5. Escreva os testes batendo nas rotas (API routes, server actions, edge functions). Mock só de serviço externo; banco, regras de negócio e policies rodam de verdade. Para repetição simultânea, dispare as requisições ao mesmo tempo (Promise.all ou equivalente).
6. Opcional, só se eu aprovar: um único teste E2E de fumaça (ex.: Playwright) para o caminho cadastro até checkout.
7. Rode tudo e me diga o que passa e o que falha. Teste que falha por bug real fica falhando e entra numa lista de bugs; não ajuste o teste para passar.
8. Me diga o comando único para rodar todos os testes, para eu rodar depois de toda alteração feita por IA.

Regras: é proibido apagar, pular (skip) ou afrouxar um teste para fazê-lo passar. Não mocke o banco nem a regra que está sendo testada. Se um teste parecer errado, pare e me pergunte.

Prompt de auditoria (os 5 de uma vez, sem alterar nada)

Você é um engenheiro sênior fazendo uma auditoria de um app que eu construí com IA. Nesta tarefa você NÃO altera nenhum arquivo do projeto, não roda migration e não instala nada. Você só lê o código, roda comandos de leitura e escreve um relatório.

Siga esta ordem e, ao final de cada etapa, anote os achados antes de passar para a próxima:

1. Testes de integração
   - Existe ferramenta de teste configurada? Existe banco de teste separado do de produção? Qual o comando para rodar tudo? Rode (só se não tocar em produção) e diga quantos passam e quantos falham.
   - Liste os fluxos críticos (cadastro, login, checkout, assinatura, webhooks) e diga quais têm teste batendo na rota de verdade, quais só têm teste unitário com mock e quais não têm nada.

2. Confiança no cliente
   - Regras de preço, desconto, permissão, papel de admin ou limite de plano que existem só no front.
   - Chaves e tokens em código de front ou em variáveis que vão para o navegador (NEXT_PUBLIC_, VITE_, EXPO_PUBLIC_ ou equivalente). Classifique como pública por design ou secreta.
   - Se houver Supabase (ou banco exposto por API): tabelas expostas com RLS desligado e policies permissivas demais (USING (true), WITH CHECK (true), regras que não comparam com auth.uid()). Explique cada policy em português.

3. Race condition
   - Todo trecho que lê, decide e depois grava sobre recurso limitado (estoque, cupom, saldo, crédito, vaga, convite). Para cada um, diga o que acontece se 2 requisições iguais chegarem juntas e se existe constraint única, operação atômica ou lock de linha no banco protegendo.
   - Aponte proteção que depende de lock em memória, lock no Redis com expiração ou leitura de cache, e diga se o banco sozinho resolveria.

4. Idempotência
   - Webhooks recebidos: a assinatura é verificada com o corpo bruto? Existe registro de eventos processados com ID único? O que acontece se o mesmo evento chegar 2 vezes?
   - Chamadas ao gateway de pagamento: usam idempotency key?

5. Separação de responsabilidades
   - Os arquivos mais longos do projeto e, em cada um, se mistura tela, regra de negócio e acesso a banco ou serviço externo. Aponte o candidato número 1 para refatorar.

Entrega: crie AUDITORIA.md na raiz com uma tabela por etapa (achado, risco alto/médio/baixo, arquivo e linha, correção sugerida) e, no topo, os 5 achados de maior risco em ordem. Se não conseguir verificar algo, escreva "não verificado" e o motivo, sem chutar. Termine dizendo qual dos 5 prompts de correção eu devo rodar primeiro e por quê.

O canal existe pra trazer conhecimento através de resenha. Aqui não tem mentoria e não tem curso.

Esse vídeo, e todos os outros do canal, só foram roteirizados, gravados e editados graças aos nossos patrocinadores:

💰 Appmax: Pix com taxa zero pra quem integrar via API por este link

🚀 Hostinger: use o cupom MANODEYVIN e ganhe desconto na primeira compra

⭐ E aos membros do canal, que bancam o boteco todo mês.

Quer fazer parte do clube?

1. Homem viaja do Maranhão até BH em busca da Jéssica Fazendeira.

2. Avaliei o que a comunidade está fazendo com Engenharia Reversa.

3. Nosso grande amigo Yudi Ganeko PRETENDE voltar ao CLT pq está com saudades de um escritório.

Patrocinadores desse episódio:

🚀 CONTA DEV: https://links.chorume.dev/contadev-ig
🚀 SOLYD: https://solyd.link/deyvin

Apoie esse conteúdo aqui no substack ou se tornando membro no YT

Deyvin nessa live transformou num programa de rádio dos anos 90 testando seu projeto fullvibecoded para o chat enviar áudio.

1. Q4 chegou e com ele algumas pessoas OPEN-TO-WORK e nem nosso profeta do tranquilismo escapou dessa.

2. O chat pediu para o mano avaliar o vídeo do Augusto Galego sobre as dificuldades do dev junior.

3. Pra fechar realizamos um bloco só pra compartilhar fofocas de forma pra entender como está esse Q4.

Patrocinadores desse episódio:

🚀 CONTA DEV: https://links.chorume.dev/contadev-ig
🚀 FULL CYCLE: https://fcycle.co/07-10-lv-md-mba-ia

Apoie esse conteúdo aqui no substack ou se tornando membro no YT

1. DHH troca ruby on rails por Rusty no seu principal projeto, diz que inglês é a melhor linguagem de programação, melhor que Ruby.

2. Lucas Montano faz declaração polêmica no X dizendo que TODO dev deveria ter uma assinatura de $ 200 dolls do claude.

3. Caso do dev senior do ITA que foi promovido a sênior em 2 anos no nubank.

4. Pra fechar nasce a nova categoria na bolha tech, o fiscal de github.

Patrocinador desse episódio:

• CONTA DEV - CONTABILIDADE PARA DEVS BR E NA GRINGA: https://links.chorume.dev/contadev-ig

Apoie esse conteúdo aqui no substack ou se tornando membro no YT

1. Trustly demite ~100 pessoas em Vitória por e-mail pessoal, dissolve times inteiros e tem gestor que só ficou sabendo porque o liderado avisou.

2. E dessa vez a culpa não foi da IA: 534 milhões de coroas de prejuízo. Acabou a era do “demiti por eficiência” — pergunta pra Stone como foi em março.

3. “A organização virou uma empresa grande demais e perdeu o espírito empreendedor”: o layoff de 2022 e as mil camadas de liderança do modelo Spotify, o ágil que virou burocracia com nome bonito.

4. Yuri Dev hackeia a loja do Buzeira feita no Lovable: token de super admin trocado no localStorage, 2FA liberado no mass assignment e uma quadrilha de vibe hackers que mandou relatório gerado por IA.

5. Pra fechar, o plot twist: o dev do Buzeira é da bolha, tava no chat, no Discord, e foi quem registrou o domínio do chorume.

Patrocinadores desse episódio:

• SOLYD - SEJA UM PENTESTER, LINK COM DESCONTO: https://solyd.link/deyvin

• CONTA DEV - CONTABILIDADE PARA DEVS BR E NA GRINGA: https://links.chorume.dev/contadev-ig

Apoie esse conteúdo aqui no substack ou se tornando membro no YT

Assista em vídeo aqui

Então fui no histórico público do projeto, baixei as 242 versões já lançadas e contei e criei um script em ruby para ler item por item e jogar no peito de uma LLM pra gerar alguns insights.

Gastei tokens pra você não precisar gastar e o resultado virou esse material.

O que você vai encontrar no PDF:

- O que é o OpenClaw e o que mudou no lançamento do 2.0, em 31 de agosto de 2026

- Uma comparação com carro saindo de fábrica, que explica tudo sem você precisar ser programador

- Um dicionário rápido com as 5 palavras técnicas que aparecem no material

- As 5 provas de maturidade, cada uma com gráfico e explicação em português simples:

- Os consertos caíram 88% em 5 dias depois do lançamento

- Em abril, a versão antiga passava de 200 consertos por entrega, sem nunca baixar

- Nenhum remendo de emergência desde o 2.0, contra 8 no primeiro mês da versão antiga

- 16 dias de teste antes de lançar, enquanto as versões antigas saíam sem teste nenhum

- Uma versão de longa duração mantida em paralelo, recebendo pouquíssimo conserto

- O tamanho do esforço por trás do 2.0: 16.977 alterações revisadas e 987 pessoas contribuindo

- As 3 coisas que esse levantamento não prova, pra ninguém usar o dado errado

- Um resumo em 5 frases e todas as fontes, pra você conferir cada número

Dados levantados em 10 de setembro de 2026.

Openclaw 2 Maturidade

1.05MB ∙ PDF file

Download

Download

📍 Hospede seu OpenClaw com a Hostinger, VPS a partir de R$ 29,99, use meu cupom MANODEYVIN pra fortalecer o canal e ainda ganhar mais desconto.

Se isso te ajudou, manda pra aquele amigo vibe coder safado.

1. Monark diz que milhares de programadores foram substituídos em um instante e entra oficialmente na lista de inimigos da bolha.

2. Por que todo CEO tem um orgasmo depois de subir um CRM no Lovable em 5 minutos?

3. A era do Software as a Toy: o SaaS deixou de ser diferencial e quem paga a conta agora é serviço.

4. Maycon Braga, o dev mais agoniado do TikTok: PHP na unha, tótem de senha, TV indoor e sistema de replay vendidos na porta do cliente.

5. Pra fechar, o casal que largou São Paulo pra morar na roça.

Patrocinadores desse episódio:

• FULL CYCLE: https://fcycle.co/pr-md-mba-ia

• ELEMENTS (cupom MANO): https://loja.elements.com.br/?utm_source=youtube&utm_medium=legenda&utm_campaign=manodeyvin

• CONTA DEV: https://links.chorume.dev/contadev-ig

Apoie esse conteúdo aqui no substack ou se tornando membro no YT

Mesmo modelo nos 2 lados (Claude Code com Opus 5), mesma máquina, mesma configuração. A única variável é a língua do prompt.

Os resultados

Nível 1: texto puro, 3 notas em Markdown
Português: US$ 0,2385
Inglês: US$ 0,2310
👉 Inglês 3% mais barato. Empate técnico.

Nível 2: API em Ruby on Rails do zero
Português: US$ 4,78
Inglês: US$ 6,16
👉 Inglês 29% mais caro.

Nível 3: auditoria de segurança num SaaS real
Português: US$ 8,94
Inglês: US$ 11,35
👉 Inglês 27% mais caro.

Os 30% apareceram, só que invertidos. Em texto puro deu empate. Nas 2 tarefas de agente, o português saiu mais barato.

O que eu tirei disso

O prompt não é a conta. O que pesou foi o que o agente leu e o que ele escreveu. Cache lido na casa dos milhões de token contra um prompt de alguns milhares.

Escreve na língua que você pensa melhor. A diferença é troco de pinga.

Quer economizar de verdade? COMPRE MEU CURSO… zoeira.

Aprende controlar o que o agente lê, humilha ele até ele começar a te dar respostas curtas e deixa o cache sempre ativado.

E outra… 1 rodada não é medição. Foi só um teste, não um veredito. Roda no teu projeto e me fala oq rolou.

• Pesquisador se demite da Anthropic dizendo AGI está próxima.

• O jaquetinha de couro, vulgo CEO da Nvidia crava que GPT-6 Astra é AGI.

• Jansen Moreira se infiltra no Discord da Lof Gang, gangue que caiu por um mod falso de Hello Kitty.

• Dev com 20 anos de PHP vira motorista de app e abre o papo de etarismo.

• Pra fechar o speed run do RH que corta seu acesso antes de te avisar que você foi demitido.

Patrocinadores desse episódio:

CONTA DEV: https://links.chorume.dev/contadev-ig
SOLYD: https://solyd.link/deyvin

Apoie esse conteúdo aqui no substack ou se tornando membro no YT

No papel o contrato dele é das 9 às 18, mas a indústria roda 24 horas e o telefone toca de madrugada, então ele dorme 2 ou 3 horas por noite, vive assombrado esperando o próximo plantão e só consegue desligar a cabeça quando sai pra correr.

Isso tem nome, algema de ouro, e ela existe aqui do mesmo jeito: nesse vídeo eu conto o caso do dev brasileiro que me procurou num evento e cujo chefe cobre toda proposta que ele recebe pra ele nunca sair, e a história de Lúcio Aneu Sêneca, que ficou milionário como professor particular de Nero, escreveu um livro inteiro convencendo um amigo a largar o emprego e, aos 60 anos, ofereceu devolver o patrimônio todo pra poder ir embora.

O chefe dele disse não. Esse vídeo não conclui nada, a resenha fica nos comentários.

Ainda tivemos o depoimento do Harley Bastos sobre layoff, o dev que fechou vaga na gringa por 3.5k num fluxo de IA conversando com IA, e o direito de resposta ao desafio do Eric Wendel. Mais a jaqueta do Mega Brain e os super chats de sempre.

Patrocinador desse episódio:

BLACK FRIDAY ANTECIPADA DA FULL CYCLE:
https://fcycle.co/02-09-lv-md-mba-ia

Links das tretas:

Thread no X sobre anti-regulamentação:

PL sobre regulamentação: https://www.camara.leg.br/proposicoesWeb/prop_mostrarintegra?codteor=2199105

PL sobre 4rmas para TI: https://www.tecmundo.com.br/internet/409044-deputado-cria-pl-para-liberar-armas-de-fogo-a-profissionais-de-ti-e-seguranca.htm

Programadores poderão ser MEI: https://www.bradojornal.com/noticias/politica/2026/03/09/programadores-poderao-se-formalizar-como-mei/

Outros Links

Vídeo do Harley

Thread no /r/brdev sobre vaga arrombada na gringa

Só que a Anthropic é americana, a lei ela é europeia, e a aplicação foi global e sem botãozinho para desabilitar.

Mas por motivos acadêmicos estou deixando aqui uma lista de repositórios PARA ESTUDO para entender como fazer essa remoção.

Guillaume Meyer / watermarks-remover

• Link: github.com/guillaumemeyer/watermarks-remover

• Estrelas: ~19 mil

• Stack: Python 3.10+ (stdlib, sem deps) + skill

blader / humanizer

• Link: github.com/blader/humanizer

• 39,4 mil estrelas

• Stack: Markdown (skill), multi-modelo

lynote-ai / humanize-text

• Link: github.com/lynote-ai/humanize-text

• 1,3 mil estrelas

• Stack: IA/LLM (HTML/JS, multilíngue)

devswha / patina

• Link: github.com/devswha/patina

• 167 estrelas

• Stack: Markdown em Coreano (en/ch/ja), skill

gonta223 / humanizer-ja

• Link: github.com/gonta223/humanizer-ja

• 88 estrelas

• Stack: Markdown em Japonês

ilyautov / humanizer-ru

• Link: github.com/ilyautov/humanizer-ru

• 86 estrelas

• Versão em Russo

MohamedAbdallah-14 / unslop

• Link: github.com/MohamedAbdallah-14/unslop

• 58 estrelas

• plugins de agente, markdown

Esse conteúdo é complemento desse vídeo aqui:

A bolha tech BR se parece muito mais com a bolha tech chinesa do que com a dos EUA. Só que as redes sociais apodreceram tanto a cabeça da galera que ninguém percebe o quanto estamos perto de um período de precarização.

Eu falo das falhas de seguranças mais comum nos SaaS, vídeo bateu mais de 100 mil views em pouco tempo e gerou uma repercussão boa.

Daí um dos inscritos me deu um feedback sobre os resultados e o que poderia ser melhorado no PROMPT, daí resolvi fazer a V2 e pra garantir que ele funciona em qualquer projeto, eu busquei 4 SaaS aleatórios com tecnologias diferentes e executei o prompt, tá documentado nesse vídeo aqui:

🤖 O prompt (copia e cola no Claude Code, Cursor, OpenCode, no que você usar)

Abre o teu agente na raiz do projeto e cola isso inteiro:

Revisa este código atrás de cinco falhas de segurança. Antes de começar, detecte a stack do projeto (linguagem, framework, ORM/query builder, mecanismo de auth, frontend, arquivos de deploy como Docker/CI/Helm/Terraform) e adapte cada categoria ao equivalente dessa stack:

1. BANCO SEM TRANCA (isolamento de inquilino/dono) — em Supabase é RLS ausente; em APIs próprias são queries de listagem/busca/agregação/relatório/exportação que não filtram pelo usuário autenticado ou pela organização/workspace/tenant ao qual ele pertence. Identifique primeiro QUAL é o mecanismo de isolamento do projeto (RLS, middleware de tenant, filtro manual por user_id, etc.) e aponte onde ele está ausente ou furado.

2. PERMISSÃO DEFINIDA NO NAVEGADOR — operações privilegiadas (admin, configurações, gestão de usuários, ações de escrita) em que o frontend esconde a UI por papel (isAdmin, canEdit, role...) mas o servidor NÃO faz a verificação equivalente. Cruze cada gate de papel do frontend com o endpoint correspondente e confirme se o backend valida o privilégio em toda rota sensível.

3. IDOR — rotas que buscam, alteram ou deletam um objeto por ID (path, query ou body) sem verificar se o objeto pertence ao usuário/tenant do chamador. Percorra sistematicamente TODOS os handlers de rota do backend, não amostras.

4. CHAVES EXPOSTAS (hardcode) — API keys, tokens, senhas, segredos de assinatura (JWT, webhooks), chaves privadas e credenciais padrão embutidos no código-fonte, configs, docker-compose, charts, CI, scripts e documentação. Atenção especial a defaults públicos que viram segredo real se não forem sobrescritos (ex: ${VAR:-valor-default}) e à ausência de validação de startup que rejeite esses defaults. Verifique também o histórico git por segredos commitados e o bundle do frontend por chaves embutidas.

5. INPUTS SEM TRATAMENTO (XSS) — no frontend: innerHTML/dangerouslySetInnerHTML/equivalentes do framework (v-html, [innerHTML], dangerouslySet...), renderização de markdown/HTML sem sanitização, URLs controladas por usuário em href/src (javascript:), eval/new Function. No backend: input do usuário entrando em HTML de e-mails, templates ou respostas sem escape. Verifique se existe lib de sanitização no projeto e se ela é aplicada nos pontos encontrados.

REGRAS DA AUDITORIA:
- Reporte apenas achados verificados no código real. Nada de especulação. Para cada achado: caminho do arquivo, número(s) exato(s) da linha, trecho do código, por que é explorável e severidade (crítica/alta/média/baixa/informativa).
- Liste arquivo por arquivo, linha por linha.
- Registre também o que foi verificado e está CORRETO (ex: "router X valida posse em todos os handlers") — isso vira a seção de pontos fortes e prova a cobertura da auditoria.
- Quando a categoria não se aplicar à stack (ex: projeto sem frontend), diga isso explicitamente em vez de forçar achados.
- Note condições de explorabilidade (feature flags, config insegura necessária, etc.).

DEPOIS DA AUDITORIA, gere um RELATÓRIO EM PDF, visualmente amigável, em pt-BR, salvo em docs/security-audit/relatorio-auditoria-seguranca.pdf, contendo:

a) Capa: título "Relatório de Auditoria de Segurança — <nome do projeto>", data, escopo auditado e nota metodológica (como cada categoria foi mapeada para a stack detectada).
b) Resumo executivo: total de achados por severidade, gráfico de rosca por severidade e gráfico de barras por categoria. Paleta: crítica #B91C1C, alta #EA580C, média #D97706, baixa #2563EB, ponto forte #059669.
c) Pontos fortes (o que está protegido, com evidência) e pontos fracos (os riscos centrais).
d) Tabela de achados detalhados por categoria: Severidade | Arquivo:linha | Descrição, com chip de severidade colorido.
e) Recomendações priorizadas (P1, P2, P3...).
f) AO FINAL DO PDF, uma seção "ISSUES PARA O GITHUB": para cada achado acionável, o texto COMPLETO de uma issue em Markdown, pronto para copiar e colar, dentro de um bloco delimitado (ex: entre --- ISSUE n --- e --- FIM ISSUE n ---). Cada issue deve conter:
- Título no formato "[Segurança] <descrição curta da falha>"
- Labels sugeridas: security + severidade
- Descrição do problema e por que é explorável
- Evidência: arquivo:linha com trecho de código
- Impacto
- Sugestão de correção
- Critérios de aceite (checklist verificável)
Agrupe achados triviais relacionados numa issue única quando fizer sentido (ex: vários defaults de segredo no mesmo tema), para não gerar spam de issues.

GERAÇÃO DO PDF — REGRAS TÉCNICAS:
- Não instale nada globalmente. Use ambiente isolado (venv Python com reportlab+matplotlib, ou ferramenta equivalente da stack local; se houver navegador headless/wkhtmltopdf/pandoc disponível, HTML→PDF também vale).
- Deixe o script gerador em docs/security-audit/ para regerar o relatório depois.
- Verifique o PDF gerado: número de páginas, renderização dos gráficos e legibilidade das tabelas (rasterize as páginas se possível). Corrija defeitos visuais antes de entregar.
- Páginas A4, margens ~2cm, cabeçalho/rodapé com nome do relatório e número de página.

Me entregue ao final: o relatório em PDF, a lista de achados no chat (arquivo por arquivo, linha por linha) e o caminho de todos os arquivos gerados.

🧠 O que tem de novo na versão desse prompt?

1️⃣ Ele detecta a stack antes de procurar.

“RLS desligado” só existe em Supabase. Se o teu projeto é Rails, Laravel, Next ele faz um filtro manual por user_id, middleware de tenant, scope no ORM.

2️⃣ Análise linha por linha

Ele acha a falha e aponta exatamente a linha que está com problema, por exemplo:

“routes/orders.ts:42 busca por ID sem checar o dono”

A versão anterior ele dizia apenas:

“Você tem problema de IDOR”

3️⃣ Ele vasculha o histórico do Git.

O prompt anterior o foco era a codebase, essa versão ele vasculha todo seu histórico do git em busca de alguns vacilos como por exemplo uma chave que vc commitou e apagou, mas continua no histórico

4️⃣ Ele registra também o que tá CERTO.

Pra não bater a síndrome do impostor achando que tudo que vc faz tá errado, eu adicionei nele uma sessão que lista o que tá certo na sua condebase.

E pra fechar, ele gera um PDF lindão com todas as issues escritas em markdown, que você pode usar pra abrir uma issue no github ou então jogar no peito do seu agente.

🎯 Os 4 projetos que eu rodei

Achei os quatro em posts do r/brdev

1️⃣ Curió - app de notas, tarefas e lembretes em Flutter.
🔗 post no r/brdev · homi-lindo/curio (GPL-3.0)

2️⃣ Cofre Investimentos - carteira, cálculo de imposto de renda com importação do CSV da B3.
🔗 post no r/brdev · claudiorico/gestao-de-ativos-ai (MIT) · app no ar

3️⃣ Login com WhatsApp - um “entra com o WhatsApp” que você sobe na tua própria infra, em Docker, sem depender de Twilio nem de ninguém.
🔗 post no r/brdev · caiopizzol/whatsapp-web-api (MIT)

4️⃣ OpenBSP - o chefão, mais de 550 estrelas, roda em produção, atende cliente por WhatsApp e Instagram ligado direto na API da Meta.
🔗 post no r/brdev · matiasbattocchia/open-bsp-api · open-bsp-ui (Unlicense)

Subscreva agora

✅ EXTRA: O checklist antes de você fazer o deploy

• Rodei o prompt e li o PDF inteiro, não só o resumo executivo

• Todo endpoint que recebe um ID valida o dono antes de responder

• Toda listagem/busca/exportação filtra pelo usuário ou tenant logado

• Toda permissão que o frontend esconde, o servidor confere de novo

• Nenhum segredo no código, no bundle do front, no docker-compose ou no CI

• Rodei a busca no histórico do Git e revoguei o que apareceu, não só apaguei

• Todo input do usuário é validado e sanitizado antes de virar HTML

• Se é Supabase: RLS ligado em toda tabela e service_role fora do frontend

• Os achados viraram issue (endurecimento) ou advisory privado (explorável)

📡 E se você quer acompanhar a bolha de tecnologia sem romantização e sem papinho de vendedor de curso cola na live, quarta, 10 da manhã.

Tmj, forte abraço,
Mano Deyvin 🤙

Partilhar @manodeyvin

🚀 PARCEIROS

CONTA DEV: https://links.chorume.dev/contadev-ig
FULL CYCLE: https://fcycle.co/26-8-lv-md-mba-ia
SOLYD: https://solyd.link/deyvin

🚀 PATROCINADORES

• CONTA DEV: https://links.chorume.dev/contadev-ig

• APP MAX: https://links.chorume.dev/appmax

• FULL CYCLE: https://fcycle.co/22-06-lv-mba-ia

• CONTA DEV: https://links.chorume.dev/contadev-ig

• FIND MY SAAS: https://find-my-saas.com/

• CADEIRA ELEMENTS: https://links.chorume.dev/elements (CUPOM: MANO)

• CONTA DEV: https://links.chorume.dev/contadev-ig

• APP MAX: https://links.chorume.dev/appmax

• FULL CYCLE: https://fcycle.co/22-06-lv-mba-ia

• CONTA DEV: https://links.chorume.dev/contadev-ig

• FIND MY SAAS: https://find-my-saas.com/

• CADEIRA ELEMENTS: https://links.chorume.dev/elements (CUPOM: MANO)

Meu jogador, primeiro vou te falar das 5 vacilações e depois vou te mostrar quais ferramentas open source vc vai usar para resolver isso.

🚨 Os 5 problemas comuns

1 - RLS desligado no Supabase/Firebase

RLS desligado no Supabase/Firebase daí qualquer um com conhecimento básico leva seus dados pelo terminal do chrome.

2 - Regra de negócio no frontend (admin)

Basicamenteo deixar toda responsabilidade de validação de qualquer coisa do lado do frontend, e o pior decidir que é admin ou não através de um Ifzinho num menu (sidebar).

3 - Fetch de dados no backend sem Auth

Quando você chama uma rota de um backend ele devolve os dados sem validar se o usuário (autenticado por bearer token) que está pedindo tem permissão para ver aquele dado.

4 - Chave Secreta exposta

O que é: API key / .env no bundle do front ou no repositório Git público.

5 - Confiar em tudo que digitam

O que é: input sem tratar → XSS, upload de qualquer arquivo, sem rate limit.

Antes que vc se sinta burro calma…

• 🧪 A galera da Symbiotic Security escaneou 1.072 apps vibe-coded. 98% tinham pelo menos uma falha. Só 26 dos 1072 passaram limpos.

• 📉 A Veracode achou falha do OWASP Top 10 em 45% do código gerado por IA, e um estudo de Stanford mediu que dev usando IA produz ~40% mais vulnerabilidade e não porque a IA seja burra, mas porque o dev confia e não revisa e/ou acreditou naquele papo de ser prompt engineer sem saber fundamentos era suficiente.

🛠️ As 4 ferramentas pra você resolver (+ bônus)

1 - OWASP ZAP: escaneia o app no ar

Repo: https://github.com/zaproxy/zaproxy

É da OWASP Foundation, ONG, sem dono comercial.

Das quatro, é a única “comunidade pura” de verdade. Você aponta pra URL da sua aplicação e ela sai batendo em tudo procurando porta aberta.

✅ Baixa ela em zaproxy.org.

✅ Dá pra integrar com o Claude Code / OpenCode.

2 - Gitleaks: caçadora de API-KEY vazado

Repo: https://github.com/gitleaks/gitleaks

MIT, comunidade. Acha chave e senha no seu código e no histórico do Git inclusive naquele commit que você apagou e achou que tinha sumido (não sumiu).

# instala (mac)
brew install gitleaks

# roda na raiz do projeto
gitleaks detect --source . -v

✅ Apareceu chave? Considere ela vazada. Já revoga e gera outra.

3 - Bandit: Se o teu SaaS é Python

Repo: https://github.com/pycqa/bandit

Do PyCQA, a comunidade do Python. Acha os padrões perigosos: input sem tratar, senha hardcoded, função insegura.

pip install bandit
bandit -r ./seu_projeto

4 - Opengrep: motor de análise estática de código (SAST)

Repo: https://github.com/opengrep/opengrep

Esse é o fork da Semgrep que falei anteriormente, tocado por um consórcio justamente pra não ter dono.

Roda regra em cima do código procurando SQLi, XSS, segredo.

🧯 Código illuminatti pra executar agora…

Supabase + Vibecoding == vazamento em massa

Ferramenta tipo Supabase e Firebase funciona diferente do que você tá acostumado: o banco fala direto com o navegador do cliente, sem servidor no meio filtrando nada. Pra travar isso tem uma parada que se chama RLS (Row Level Security) é a regra onde diz que “esse usuário só vê os dados dele“.

O grande problema é: ela vem desligada.

Pra cada tabela do teu banco, faz o seguinte:

ALTER TABLE public.sua_tabela ENABLE ROW LEVEL SECURITY;

Só isso já fecha a porta pra quem não tá logado.

Depois você configura as policies.

🔴 A chave service_role NUNCA vai pro frontend. Ela pula todo o RLS, é a chave mestra. No navegador só a anon.

CVE-2025-48757 vazou dado de mais de 170 aplicativos de uma vez.

1 linha de SQL resolvia toda essa parada.

🔑 E a chave de API paizão?

Esse é o vacilo 4. Pra gente ficar na mesma página:

Toda integração te dá uma chave (gateway, e-mail, a própria API de IA). E tem uma parada que muito vibe coder não sabe: quando você faz o build do frontend, toda variável vira JavaScript que qualquer um lê abrindo o “inspecionar”.

Você acha que escondeu. Mas tá lá exposto bonitinho pra qualquer um ver.

E não é exagero não: só em 2024 vazaram 24 milhões de segredos no GitHub, e o tempo médio pra um bot colher uma chave exposta é de poucos minutos depois do commit.

“Ahh mas mas será que eu sou tão importante assim??”

Calma… segura sua síndrome do protagonista… não é nenhum hacker que está te monitorando é bot arrendo o GitHub inteiro, 24h por dia.

O padrão pra resolver chama BFF (Backend for Frontend): o front nunca fala com a API de terceiro, ele fala com um endpoint teu, e o teu servidor que ninguém abre no inspecionar guarda a chave.

Tá explicado direitinho no post do GitGuardian.

E o .env no .gitignore antes do primeiro commit e não depois. (eu sei que isso é básico, mas é bom avisar).

🤖 O prompt da auditoria illuminati [copia e cola no Claude Code / Cursor]

Se você leu tudo e ficou com preguiça e não quer instalar nada agora, calma.

Copia isso aqui e joga no peito do teu agente:

Revisa este código atrás das 5 falhas mais comuns 
em app gerado por IA: (1) tabelas de Supabase/Firebase sem RLS; 
(2) autorização decidida no frontend em vez do servidor; 
(3) rotas que buscam por ID sem checar o dono (IDOR); 
(4) segredos/API keys expostos no código ou no bundle; 
(5) input do usuário sem validação/sanitização e upload sem checar tipo de arquivo. 
Lista cada achado com arquivo, linha e como corrigir.

Ele vai achar, vai doer, mas é melhor chorar agora do que depois.

✅ Salva o checklist illuminati [antes de todo deploy]

• RLS ligado em toda tabela do Supabase/Firebase + policies por usuário

• service_role / chave de admin fora do frontend

• Toda decisão de permissão conferida no servidor (não só no navegador)

• Todo endpoint que recebe ID valida o dono antes de responder

• Nenhuma API key / segredo no código do front ou no Git (.env no .gitignore)

• Todo input validado e sanitizado; upload checa o tipo de arquivo

• Rate limit nos endpoints sensíveis (login, resgate, verificação)

• Rodei um scanner (ZAP / Gitleaks / Bandit / Opengrep) antes de subir

Conclusão

Resumindo:

🧠 A IA não deixou essas portas abertas de sacanagem. Ela fez o que você pediu e ninguém pede “e deixa trancado”. Segurança é a única parte que VOCÊ tem que lembrar de colocar nos seus prompts, mas ninguém faz pq ela não tem nenhum resultado visual.

Por isso eu acho que o mundo deveria ter mais backends do que frontends, pq nós backends estamos acostumados de nosso trabalho não ter nenhum prestígio por pessoas de fora.

💬 Agora é congito meu PRO PLAYER de Claude Code

• 🔓 Qual desses 5 vacilos você já cometeu?

• 🧪 Rodou o scanner e achou coisa? Conta o que apareceu.

📺 Se você ainda não viu, o vídeo completo com os casos reais tá aqui

👉 SEU SAAS FEITO COM IA VAI SER HACKEADO EM 10 MINUTOS

📚 Todas as fontes, na ordem do texto

1. 🧪 Symbiotic Security — 1.072 apps vibe-coded escaneados, 98% com falha

2. 📉 Veracode / OWASP Top 10 em código gerado por IA (45%)

3. 🎓 NowSecure — o que as falhas OWASP em código de IA significam (Stanford, +40%)

4. 🛡️ OWASP ZAP — scanner dinâmico da OWASP Foundation

5. 🔌 dtkmn/mcp-zap-server — ZAP via MCP no Claude Code / OpenCode

6. 🔑 Gitleaks — caça segredo no código e no histórico do Git

7. 🐍 Bandit (PyCQA) — análise estática pra Python

8. 🏴 Opengrep — o fork livre da Semgrep

9. 🧨 Wiz — riscos comuns em apps vibe-coded (CVE-2025-48757, +170 apps)

10. 🔐 vibeappscanner — Supabase, RLS e o CVE

11. 💸 GitGuardian — 24 milhões de segredos vazados e o padrão BFF

12. 🔢 XHack — BOLA/IDOR, o #1 do OWASP API Security

13. 📋 OWASP API Security Top 10