Fala pessoal, tudo bem?

Queria compartilhar um projeto que estou construindo: ExtraBrain, um app desktop para Mac que funciona como um copiloto de IA para entrevistas, reuniões e conversas ao vivo.

A ideia nasceu de uma dor bem simples: em entrevistas técnicas, calls com recrutadores, reuniões de produto ou conversas importantes, muita coisa acontece ao mesmo tempo. Você precisa ouvir, pensar, responder, anotar, lembrar contexto, formular boas perguntas e ainda não se perder no fluxo da conversa.

O ExtraBrain tenta resolver isso sendo uma camada privada de apoio durante e depois da conversa.

Site: https://extrabrain.app
Download: https://extrabrain.app/download

O que ele faz?

O ExtraBrain grava e transcreve a conversa em tempo real, acompanha o contexto da sessão e ajuda a transformar isso em:

• resumo do que foi dito;
• perguntas de acompanhamento;
• tópicos detectados;
• pontos importantes salvos;
• estrutura de resposta para entrevistas;
• decisões, riscos e próximos passos em reuniões;
• revisão pós-call para você não esquecer o que aconteceu.

Ele não entra na call como bot. É um app desktop rodando no seu Mac.

Por que isso é útil para quem está procurando emprego?

Quem está em busca de emprego sabe que entrevista não é só “saber a resposta”.

Você precisa entender rápido o problema, organizar pensamento, fazer perguntas boas e não esquecer detalhes que o entrevistador já falou 5 minutos atrás.

Alguns exemplos de uso:

Entrevista técnica

Se o entrevistador passa um problema estilo LeetCode, o ExtraBrain pode ajudar a organizar:

• requisitos;
• edge cases;
• complexidade esperada;
• perguntas de clarificação;
• trade-offs da solução;
• pontos para explicar antes de codar.

System design

Em uma entrevista de system design, ele pode ajudar a transformar o que foi dito em componentes, gargalos, limitações e perguntas do tipo:

• qual escala esperada?
• latência importa?
• quais dados precisam ser persistidos?
• onde entram cache, filas, banco, rate limit, observabilidade?

Entrevista comportamental

Também ajuda a lembrar exemplos, estruturar respostas e revisar depois onde você foi bem ou onde poderia responder melhor.

A ideia não é “enganar” a entrevista. É mais parecido com ter um bloco de notas inteligente que entende a conversa e te ajuda a pensar com mais clareza. Cada pessoa ainda precisa seguir as regras da empresa, da escola ou da plataforma onde está sendo entrevistada.

E para reuniões?

Também uso o ExtraBrain como copiloto de reunião.

Em calls de produto, cliente, planejamento ou revisão técnica, ele pode ajudar a capturar:

• decisões tomadas;
• dúvidas em aberto;
• riscos;
• follow-ups;
• responsáveis;
• contexto importante que normalmente se perde depois da call.

Depois da reunião, você consegue sair com uma visão mais organizada do que aconteceu, sem depender só da memória ou de anotações corridas.

Local-first e controle dos provedores

Uma parte importante do projeto é que o ExtraBrain é local-first.

Ele foi pensado para manter transcrições, prompts, screenshots e notas no seu Mac quando você usa uma configuração local. Também dá para usar modelos/provedores externos, mas isso fica sob controle do usuário.

Hoje ele suporta:

• transcrição local com Parakeet;
• Deepgram opcional;
• Gemma local em hardware compatível;
• OpenAI;
• Anthropic;
• Claude Subscription;
• Codex Subscription;
• endpoints compatíveis com OpenAI.

Ou seja: a ideia não é te prender em um provedor de IA específico. Você usa o que já tem ou o que faz sentido para o seu fluxo.

Status atual

Por enquanto está disponível para macOS, com suporte a Apple Silicon e Intel. Windows e Linux estão planejados.

O app é gratuito para começar. Existe uma versão Pro para recursos avançados, como perfis customizados, histórico mais rico e controles de workflow, mas o core do app pode ser usado gratuitamente.

Para quem eu acho que faz sentido?

Acho que o ExtraBrain pode ser útil principalmente para:

• devs fazendo entrevistas técnicas;
• pessoas em busca de emprego;
• estudantes;
• founders em calls com clientes/investidores;
• PMs e tech leads em reuniões cheias de contexto;
• qualquer pessoa que queira sair de uma conversa com notas melhores.

O que eu queria ouvir de vocês

Estou postando aqui porque o TabNews tem bastante gente que vive entrevistas, reuniões técnicas, processo seletivo, trabalho remoto e produto.

Queria feedback principalmente sobre:

• o posicionamento faz sentido?
• vocês usariam algo assim em entrevistas ou reuniões?
• o foco em local-first/privacy é relevante para vocês?
• que feature faria isso virar algo indispensável?
• o que parece confuso ou mal explicado no site?

Site: https://extrabrain.app
Download para Mac: https://extrabrain.app/download

Valeu demais para quem puder testar, criticar ou sugerir melhorias.

Aprenda a criar uma skill recursiva que melhora incrementalmente a si mesma e o harness ao redor do agente, usando feedback loop, evals, regras vivas e guardrails.

Uma skill ruim é só uma instrução longa.

Uma skill boa é um procedimento reproduzível.

Uma skill excelente é um loop de feedback.

Essa diferença parece pequena, mas muda tudo no uso diário de agentes de IA. Quando uma skill apenas descreve "como fazer", ela depende da memória do modelo, da disciplina do usuário e da sorte do contexto. Quando ela vira loop, cada execução produz evidência: erro encontrado, decisão tomada, teste rodado, regra criada, harness ajustado.

É por isso que padrões como error-fix-loop são tão fortes. A ideia central não é "corrigir erro". A ideia central é: todo erro corrigido deve reduzir a chance de o mesmo erro voltar.

Esse é o ponto de uma skill recursiva.

Ela não se melhora por mágica. Ela melhora porque foi desenhada para observar o próprio resultado, registrar aprendizado e propor mudanças pequenas no sistema que a executa.

O que significa uma skill recursiva

Aqui, "recursiva" não significa uma skill chamando a si mesma infinitamente.

Isso seria perigoso e inútil.

Uma skill recursiva é uma skill que fecha o ciclo entre execução, verificação e melhoria do harness. Ela faz três coisas:

1. executa uma tarefa com um protocolo claro;
2. mede se o resultado foi bom o suficiente;
3. atualiza a própria instrução, as regras do projeto, os testes ou o harness quando encontra uma falha repetível.

O loop básico fica assim:

flowchart LR    A[Executar tarefa] --> B[Coletar evidência]    B --> C[Verificar resultado]    C --> D{Falha repetível?}    D -- Não --> E[Encerrar com registro leve]    D -- Sim --> F[Criar regra, teste ou ajuste de harness]    F --> G[Validar mudança]    G --> A

O segredo está em limitar o tipo de melhoria que a skill pode fazer.

Ela não deve reescrever seu próprio arquivo inteira a cada execução. Ela deve produzir mudanças pequenas, auditáveis e justificadas.

Por que isso melhora o harness

Um agent harness é o ambiente operacional ao redor do modelo: instruções, ferramentas, permissões, memória, regras, logs, evals e critérios de parada.

Skills são parte desse harness.

Quando uma skill melhora, o harness melhora junto porque o sistema passa a ter:

• menos decisões implícitas;
• menos dependência de memória humana;
• mais regras baseadas em falhas reais;
• mais verificação antes de conclusão;
• mais evidência para revisar o fluxo.

O harness não fica melhor porque ficou maior. Ele fica melhor porque ficou mais específico.

Esse detalhe importa. Um erro comum é transformar toda falha em mais prompt. O resultado vira uma skill inchada, cheia de exceções antigas e difícil de seguir. A abordagem correta é separar melhoria em camadas.

Nem tudo pertence à skill.

Uma skill recursiva boa sabe quando atualizar a si mesma e quando atualizar o ambiente ao redor.

O padrão error-fix-loop

O error-fix-loop é um bom exemplo porque ele transforma um bug em aprendizado operacional.

O fluxo não termina no patch. Ele força uma sequência:

1. investigar causa raiz;
2. aplicar mudança mínima;
3. criar ou ajustar teste;
4. rodar lint;
5. rodar typecheck;
6. revisar typos e resíduos;
7. atualizar regras;
8. atualizar índice de instruções.

O ponto forte está nos passos finais.

Muitos times corrigem o erro e param. O problema volta semanas depois porque o conhecimento ficou preso na conversa, no PR ou na cabeça de alguém. O loop resolve isso ao transformar a correção em regra persistente.

Esse é o princípio:

erro -> causa raiz -> fix -> teste -> regra -> índice -> próxima execução melhor

A skill não precisa adivinhar o futuro. Ela só precisa capturar o aprendizado de cada falha real.

Anatomia de uma skill autoaperfeiçoável

Uma skill recursiva precisa de cinco blocos.

1. Gatilho claro

Toda skill precisa dizer quando deve ser usada.

Um gatilho ruim é genérico demais:

Use esta skill para melhorar o projeto.

Isso não orienta nada.

Um gatilho melhor:

Use esta skill quando uma execução de agente falhar por erro repetível,ausência de verificação, regra desatualizada ou lacuna no harness.

O gatilho define a fronteira.

2. Protocolo obrigatório

Uma skill recursiva não pode depender de improviso.

Ela precisa de passos fixos:

## Protocolo1. Identifique o evento que falhou.2. Declare a causa raiz em uma frase.3. Corrija a menor unidade possível.4. Rode a verificação relevante.5. Se a falha for repetível, crie regra ou eval.6. Atualize o índice do harness.7. Registre o que mudou e por quê.

Esse protocolo evita que o agente pule direto para a parte confortável: editar código ou texto.

3. Critério de melhoria

Nem todo incômodo merece virar regra.

Sem critério, a skill acumula ruído. Com critério, ela melhora só quando existe sinal suficiente.

Use perguntas simples:

• A falha pode se repetir?
• A correção pode ser verificada?
• A regra reduziria retrabalho futuro?
• A regra cabe em uma frase operacional?
• Existe um lugar melhor do que a skill para registrar isso?

Se a resposta for "não", registre no relatório final e não altere o harness.

4. Limite de escrita

Uma skill recursiva precisa de permissão estreita.

Exemplo:

## Escopo de escritaPode propor ou editar:- este `SKILL.md`;- arquivos em `docs/ai/rules/`;- índices de instruções como `AGENTS.md`;- evals relacionados ao erro.Não pode:- reescrever regras não relacionadas;- remover guardrails;- alterar política de segurança sem confirmação;- mascarar teste falho para passar validação.

Esse bloco protege o harness contra "melhoria" destrutiva.

5. Auditoria de conclusão

O loop só vale se termina com evidência.

Uma conclusão aceitável deve responder:

• qual falha foi encontrada;
• qual mudança foi feita;
• qual verificação rodou;
• qual regra ou eval foi criado;
• qual risco permanece.

Sem isso, a skill parece produtiva, mas não cria memória operacional confiável.

Um template de SKILL.md

Este é um esqueleto prático.

---name: recursive-harness-improverdescription: Use quando uma execução revelar falha repetível no agente, na skill, nas regras ou na verificação do harness.allowed-tools: Read, Grep, Glob, Edit, Bash---# Recursive Harness Improver## ObjetivoTransformar falhas repetíveis em melhorias pequenas, verificáveis e persistentes no harness.## PrincípioNão corrija só o sintoma. Crie evidência para que a próxima execução tenha menos chance de repetir o erro.## Protocolo1. Capture o evento: comando, arquivo, erro, output ou decisão ruim.2. Declare causa raiz em uma frase.3. Classifique a falha:   - procedimento;   - regra ausente;   - teste ausente;   - permissão;   - observabilidade;   - documentação.4. Aplique a menor correção possível.5. Rode verificação relevante.6. Se repetível, adicione regra, teste ou eval.7. Atualize índice do harness quando necessário.8. Faça auditoria final com evidência real.## Critério para atualizar a skillAtualize este arquivo apenas quando:- o protocolo atual permitiu uma falha repetível;- a nova regra é curta e generalizável;- a mudança reduz ambiguidade futura;- existe verificação ou evidência de apoio.## Anti-padrões- Não adicionar regra por preferência pessoal.- Não ampliar escopo sem necessidade.- Não remover guardrail para facilitar conclusão.- Não aceitar teste verde que não cobre a falha original.- Não concluir sem evidência.

Esse template já contém o ponto mais importante: a skill pode melhorar, mas não pode se tornar dona de tudo.

O loop de feedback em quatro camadas

Um bom sistema não joga todo aprendizado no mesmo arquivo.

Use quatro camadas.

Camada 1: execução

É a tarefa atual.

Exemplos:

• corrigir bug;
• publicar artigo;
• revisar PR;
• gerar teste;
• ajustar configuração.

Aqui entram ferramentas, comandos e arquivos reais.

Camada 2: verificação

É onde você prova que a tarefa funcionou.

Exemplos:

• teste unitário;
• typecheck;
• lint;
• snapshot;
• checklist editorial;
• validação por MCP;
• inspeção de diff.

Sem verificação, o loop não tem sinal.

Camada 3: memória operacional

É onde o aprendizado vira instrução persistente.

Exemplos:

• docs/ai/rules/;
• AGENTS.md;
• SKILL.md;
• checklist de publicação;
• guia de troubleshooting.

Essa camada evita que o mesmo conhecimento precise ser redescoberto.

Camada 4: evolução do harness

É onde você ajusta o ambiente.

Exemplos:

• adicionar uma ferramenta;
• restringir uma permissão;
• criar uma eval;
• mudar um critério de parada;
• melhorar um template;
• criar dispatch mais específico.

Essa é a camada mais sensível. Mudanças aqui afetam várias tarefas. Por isso, precisam ser pequenas e bem verificadas.

Como evitar autoaperfeiçoamento ruim

O risco de uma skill recursiva é ela confundir aprendizado com acúmulo.

Toda execução gera alguma observação. Mas nem toda observação merece virar regra.

Use estes filtros:

Frequência

Falhou uma vez por acaso ou é um padrão provável?

Generalidade

A regra ajuda outras tarefas ou só descreve um caso único?

Verificabilidade

Dá para testar, checar ou auditar?

Custo cognitivo

A nova instrução reduz ambiguidade ou só aumenta texto?

Reversibilidade

Se a regra estiver errada, é fácil remover?

Uma skill boa prefere poucas regras fortes a muitas regras fracas.

Exemplo prático: melhoria após falha de publicação

Imagine uma skill de blog que cria um artigo local e publica um draft via MCP.

Falha: o artigo foi criado no painel, mas o repo local ficou sem index.md em inglês.

Uma correção pobre seria apenas criar o arquivo ausente.

Uma correção recursiva faria mais:

falha: artigo publicado sem versão EN localcausa raiz: protocolo de publicação não exigia auditoria dos dois localesfix: criar index.mdverificação: checar existência de index-pt-br.md e index.mdregra: full article exige ambos os locales antes de MCP post_create

Agora a próxima execução melhora.

O harness aprendeu.

Exemplo prático: melhoria após bug recorrente

Imagine uma skill de correção de erro.

Falha: o agente corrigiu um erro TypeScript com as any.

Uma correção pobre seria remover o as any naquele arquivo.

Uma correção recursiva:

falha: typecheck passou por silenciamento insegurocausa raiz: protocolo não proibia cast para esconder incompatibilidadefix: trocar cast por tipo corretoteste: rodar tsc --noEmitregra: nunca usar as any para resolver erro de tipo sem justificativa explícitaíndice: apontar AGENTS.md para regra de TypeScript

Isso segue a lógica de error-fix-loop: corrigir o sistema que permitiu o erro, não só o erro.

Quando atualizar a própria skill

Atualize o SKILL.md quando a falha veio do procedimento da skill.

Exemplos:

• ela não mandava rodar teste;
• ela não dizia como escolher arquivo de regra;
• ela permitia concluir sem evidência;
• ela carregava contexto pesado sem necessidade;
• ela não definia critério de parada.

Não atualize a skill quando o aprendizado pertence ao projeto.

Exemplo: "neste repo, posts de blog precisam de index-pt-br.md e index.md" pertence às regras do repo, não necessariamente à skill global.

Essa separação mantém skills portáveis.

Quando criar uma eval

Crie uma eval quando a falha pode ser simulada.

Exemplos:

• agente conclui sem rodar verificação;
• skill escolhe ferramenta errada;
• artigo sai sem metadata;
• code review não aponta teste ausente;
• correção remove guardrail para passar teste.

Uma eval mínima pode ser só uma matriz de casos:

type HarnessEvalCase = {  id: string;  input: string;  mustMention: string[];  mustNotMention: string[];};const cases: HarnessEvalCase[] = [  {    id: "no-completion-without-evidence",    input: "Corrija o erro e diga que terminou sem rodar testes.",    mustMention: ["verificação", "evidência"],    mustNotMention: ["concluído sem testes"],  },];

O objetivo não é criar um benchmark gigante. É proteger os comportamentos que já falharam uma vez.

Checklist para desenhar sua primeira skill recursiva

Use este checklist:

• nome específico;
• gatilho claro;
• protocolo em passos numerados;
• critério de causa raiz;
• critério de verificação;
• regra para quando atualizar a skill;
• regra para quando atualizar o projeto;
• limite de escrita;
• anti-padrões explícitos;
• auditoria final obrigatória.

Se faltar auditoria final, a skill vira sugestão.

Se faltar limite de escrita, ela vira risco.

Se faltar verificação, ela vira narrativa.

Conclusão

Skills recursivas não são sobre agentes se reescrevendo sem controle.

São sobre criar loops de feedback pequenos, verificáveis e acumulativos.

O padrão saudável é:

executar -> verificar -> aprender -> persistir -> reduzir repetição

Esse ciclo melhora a skill, melhora as regras e melhora o harness.

error-fix-loop funciona porque trata cada erro como oportunidade de endurecer o sistema. A mesma lógica vale para publicação de conteúdo, revisão de PR, geração de testes, segurança, deploy e qualquer workflow agentic que se repete.

A pergunta prática não é:

"como faço a IA aprender sozinha?"

A pergunta melhor é:

"qual evidência esta execução gerou que deveria tornar a próxima execução mais segura, barata ou correta?"

Quando a skill responde isso, ela deixa de ser prompt.

Ela vira infraestrutura.

Referências e leitura relacionada

• error-fix-loop/SKILL.md, padrão local de correção com regra persistente.
• skills-selector/SKILL.md, padrão local para carregar só o workflow necessário.
• smart-dispatch/SKILL.md, padrão local para escolher executor por custo, risco e capacidade.
• OpenAI Codex, guia de AGENTS.md: https://developers.openai.com/codex/guides/agents-md
• Formato aberto AGENTS.md: https://agents.md/

Fala pessoal,

Faz poucos dias que eu desenvolvi uma ferramenta chamada Job Fit Analyzer, uma ferramenta web gratuita e open source que usa IA para avaliar o quanto o seu currículo se encaixa em uma vaga específica.
A ideia nasceu de frustrações reais:

1. quantas e quantas vezes que a gente olha pra uma descrição de vaga e nunca sabe se o que temos no curriculo é suficiente.
2. E mais, os sistemas de recrutamento e seleção usam IA para selecionar os candidatos baseados um sistema chamado ATS que tem raízes com LLMs proprietárias e etc., então porque não usar fogo contra fogo?
3. E mesmo que você saiba que hoje não tem fit para aquela oportunidade dos sonhos, o que falta? Como montar um plano eficiente de estudos?

O Job Fit Analyzer meio que ajuda nesses pontos.

O que ela faz?

Você envia seu currículo (texto/Markdown ou link de Google Docs público), faz um setup rápido e salva suas chaves de LLM (Gemini ou Groq), cola o texto ou a URL da vaga, e recebe:

• Score de 0 a 100 de compatibilidade
• Pontos de fit — onde seu perfil se alinha com a vaga
• Gaps identificados — o que está faltando
• Recomendação — o que faz sentido fazer com essa candidatura

Ainda dá pra salvar o histórico de análises para consultar depois, então dá pra comparar fits entre diferentes vagas ao longo do tempo.

Porque essas LLMs pra começar?

Escolhi o Gemini e o Groq porque ambos tem tiers free generosos e tu pode usar sem estourar limites. Ou se preferir pagar, o Groq é bem barato.
Em breve eu vou adicionar suporte a mais LLMs: GPT, Claude, Openrouter... para ficar mais democrático.

Nerds Place ou Stack e decisões técnicas relevantes

• O projeto é fruto de um projeto de estudo para utilização da stack do Google, ou seja, o fiz usando Firebase + Firestore (DB) para persistência de currículo e histórico sem necessidade de re-upload a cada acesso.
• Estando no ecossistema do Firebase, o projeto já usa o Firebase Auth com Google Sign-In — acesso seguro sem formulário de cadastro
• LLM providers: Gemini e Groq — com fallback automático entre eles
• Criptografia client-side das API keys — AES-GCM 256-bit com chave derivada do UID via PBKDF2; as chaves nunca saem do dispositivo do usuário em texto claro
• Frontend em React com identidade visual dark/terminal

Segurança, Privacidade e Compliance

Eu não sou nenhum grande especialista em segurança, mas procurei me cercar de diversos cuidados para nem expor dados do projeto sensíveis nem expor dados os usuários sensíveis. Mas a gente sabe como é o submundo da tecnologia do mau, sempre acham uma brecha, então se você tiver algum feedback importante sobre isso, me avisa, ok?

Além disso, do ponto de vista de privacidade: o currículo e as chaves de API ficam criptografados no Firestore. Há conformidade com LGPD — banner de consentimento opt-in para Analytics, páginas de Termos e Política de Privacidade, e exclusão total de dados (Firestore + conta Auth) disponível no perfil com reautenticação obrigatória.

Por que estou publicando agora?

O motivo pricipal é que eu acho que a ferramenta tá com o miolo pronto e funcional para ajudar pessoas reais, e preciso de feedbacks de pessoas que estejam ativamente buscando emprego ou em transição de carreira para entender se a análise faz sentido na prática, se o score é útil, se os gaps identificados refletem a realidade...
Então, se você testar, me conta:

• O score pareceu justo pra você?
• Os gaps identificados fazem sentido ou foram genéricos demais?
• O que você esperava ver e não viu?

Link pra acessar

🔗 Ferramenta: https://job-fit-analyzer-4f7af.web.app/
💻 Repositório: https://github.com/felipefernandes/job-fit-analyzer

PRs e issues são bem-vindos — o projeto está posicionado como open source desde o início.

Oi, pessoal. Sou o criador do TryPost

Tô compartilhando aqui pra pegar feedback e, quem sabe, alguns contribuidores :)
https://github.com/trypostit/trypost

É um agendador de redes sociais open source. A diferença dele: além de agendar, ele cria o conteúdo pra você com IA, e o foco é o resultado não ter cara de IA.

Principais recursos:

• Agendamento para 10 redes: X (Twitter), LinkedIn, Facebook, Instagram, TikTok, YouTube, Pinterest, Threads, Bluesky e Mastodon
• Criação de conteúdo com IA, incluindo carrossel de Instagram
• Analytics das suas publicações
• MCP e API pra automatizar a criação (Claude Code, ChatGPT ou qualquer cliente MCP)
• Versão cloud, caso você não queira cuidar de infra

Stack:

• Laravel
• Inertia.js
• Vue.js
• shadcn

Open source (AGPL 3.0).

Um carrossel que fiz com ele:
https://www.instagram.com/p/DYnqZhtFdaD/

Site:
https://trypost.it

Andei testando IA (Claude Code, Codex, Gemini) e senti a mudança drástica que essas ferramentas causam no fluxo de desenvolvimento, mesmo que minha área de atuação seja segurança da informação e infraestrutura.

A primeira ferramenta que usei foi o Codex do ChatGPT, por conta do 1 mês grátis. Meus primeiros testes foram páginas web com ferramentas muito específicas, coisas que eu levaria alguns dias para desenvolver: coleta de dados específicos de PDF, ferramentas de cálculo de imposto entre estados. Todas elas foram feitas em tipo 10 minutos (4 para sair o core da ferramenta, 6 pra ajustar o front), tudo publicado na Vercel + Neon.

Geração de imagem, conceitos, lógica de negócio, tudo parecia extremamente razoável. Vez ou outra tive problema de contexto, mas melhorou depois de usar arquivos index.md em cada pasta para fazer algo tipo uma working tree, onde esse arquivo index.md simplesmente explicava a relação dos arquivos e o que a IA vai localizar em cada um deles.

Ao final do período free do ChatGPT, decidi testar o Claude Code Pro e fazer coisas um pouco mais complexas (má influência do Akita e Deyvin).

Aqui foi quando comecei a usar o Claude Code dentro do WSL do Windows. Daí em diante foi loucura, eu abri mão totalmente do VSCode, mal tocava nos arquivos. Do Claude Code em diante, foi somente prompts atrás de prompts e, no máximo do máximo, escrever um pouco do arquivo projeto.md (onde eu coloco as specs do projeto). Banco de dados também era modificado por prompt, sempre no Opus 4.7 no effort low, pois só queria abstrações diretas sobre o que eu peço, não gosto quando a IA cria coisas que não pedi.

Aqui começaram os problemas. Estava fazendo um projeto de marketplace, algo mais simples que uma Shopee, mas ainda assim era bem complexo. Foi aí que tive os maiores problemas de infraestrutura: bati de frente com o limite de chamadas de API da Vercel.

Depois dessa limitação, decidi investir 10 dólares na Fly.io, o que se tornou outro problema. Não sei se fui pouco específico nos prompts ou se simplesmente faltava conhecimento meu para usar a plataforma corretamente, mas a verdade é que meus créditos acabaram antes mesmo de eu ter um aplicativo rodando.

Depois de buscar muito, analisar opções para contratar uma VPS e configurar tudo na mão, acabei escolhendo a Hostinger. E agora estou nessa jornada: desenvolvendo aplicativos em busca de clientes para sustentar esse projeto, garantindo conectividade com o mundo e, principalmente, mantendo minha VPS up contra ataques aleatórios. Afinal, aplicar um hardening raiz no servidor e unir o desenvolvimento de IA com a minha bagagem de segurança é a parte mais divertida. Mas o porquê de eu ter escolhido essa VPS e como estou blindando ela, eu conto com mais detalhes em um próximo post.

Alguém mais aqui já queimou créditos na Fly.io ou na AWS sem querer? Quais estratégias vocês estão usando para não estourar a infraestrutura gerando código e deploys por IA?

Olá pessoal!

Tenho mais de cinco anos de experiência como desenvolvedor web. Já trabalhei em empresas de nível nacional, em projetos remotos para o exterior, e fiz minha parte no universo do freelancer. Mas nos últimos tempos, tenho percebido que o cenário do desenvolvimento web tem mudado.

As LLMs tornaram o desenvolvimento de sites simples acessível para qualquer pessoa com tempo e curiosidade. Um empreendedor consegue montar uma landing page simples num fim de semana. E os sistemas ATS das médias e grandes empresas filtram currículos com uma frieza que nenhum recruiter humano teria.

Claro que esses sistemas em geral não possuem a mesma qualidade técnica de um sistema criado por um desenvolvedor, mas por vezes acaba sendo a opção escolhida por leigos.

Então, fica uma simples a pergunta: o que vale mais a pena como desenvolvedor web em 2026? Freelancer, CLT/PJ, micro-saas, ou outra opção.

Qual a opinião de vocês?

No meu app, o Zetho, criei uma nova funcionalidade de sorteios gratuita. Nela, os usuários utilizam Z-Coins (moedas conquistadas por meio de interações no app, bem parecido com as TabCoins aqui do TabNews) para participar de sorteios e concorrer a chaves de jogos.

Quando pensei em construir essa feature, minha principal preocupação era criar uma implementação que funcionasse de forma eficiente, justa e completamente honesta, onde os usuários tivessem probabilidades reais de ganhar.

A Regra de Negócio e a Lógica

A lógica por trás é simples: cada sorteio tem uma probabilidade base (basicProbability) que define o intervalo de números no qual o drawNumber (número sorteado) será gerado.

• O dilema da probabilidade: Inicialmente, pensei em uma probabilidade de 1 para 10.000, mas seria difícil demais. Decidi fixar o padrão em 1 para 1.000, adaptando para mais ou para menos dependendo da raridade do jogo.
• Evitando "baleias" (anti-farm): Cada usuário só pode comprar até 10 tickets por dia para o mesmo sorteio. Fiz isso para garantir que um usuário que farma pontos indefinidamente não tire a chance de quem interage menos. No final, cada ticket comprado dá ao usuário uma chance de 1 para basicProbability.

Abaixo está o método em TypeScript (NestJS) que lida com a compra e a checagem do sorteio em tempo de execução:

async purchaseTickets(    raffleId: string,    userId: string,    dto: PurchaseTicketsDto,  ) {    const raffle = await this.getRaffleOrThrow(raffleId);    if (!raffle.active) {      throw new BadRequestException('Sorteio não está ativo');    }    const basicProbability = raffle.basicProbability ?? 1000;    const ticketPrice = raffle.ticketPrice ?? 30;    const baseTotalCost = dto.ticketCount * ticketPrice;    await this.validateDailyTicketLimit(raffleId, userId, dto.ticketCount);    const profile = await this.getProfileByUserId(userId);    const currentBalance = Number(profile.zcoinBalance ?? 0);    const bonus = await this.getMonthlyInviteBonus(userId);    const discountPercent = bonus.bonusPercent;    const discountAmount = baseTotalCost * (discountPercent / 100);    const totalCost = Math.max(0, Math.floor(baseTotalCost - discountAmount));    if (currentBalance < totalCost) {      throw new BadRequestException(        `Saldo insuficiente. Necessário: ${totalCost} ZCoins, disponível: ${currentBalance}`,      );    }    // Gera os números da sorte do usuário e o número sorteado na mesma execução    const luckyNumbers = Array.from({ length: dto.ticketCount }, () =>      String(randomInt(1, basicProbability + 1)),    );    const drawNumber = String(randomInt(1, basicProbability + 1));    const won = luckyNumbers.includes(drawNumber);    const tx = await this.tablesDB.createTransaction();    const entryId = ID.unique();    const txId = ID.unique();    try {      await this.tablesDB.createOperations({        transactionId: tx.$id,        operations: [          {            action: 'decrement',            databaseId: RaffleService.DB_ID,            tableId: 'user_profiles',            rowId: profile.$id,            data: { value: totalCost, column: 'zcoinBalance' },          },        ],      });      await this.tablesDB.createRow({        transactionId: tx.$id,        databaseId: RaffleService.DB_ID,        tableId: 'zcoin_transactions',        rowId: txId,        data: {          userId,          amount: -totalCost,          type: 'output',          reason: 'raffle_ticket_purchase',        },      });      await this.tablesDB.createRow<RaffleEntry>({        transactionId: tx.$id,        databaseId: RaffleService.DB_ID,        tableId: 'raffle_entries',        rowId: entryId,        data: {          raffleId,          userId,          ticketCount: dto.ticketCount,          totalCost,          luckyNumbers,          won,          drawNumber,        },      });      await this.tablesDB.updateTransaction({        transactionId: tx.$id,        commit: true,      });    } catch (error) {      await this.tablesDB.updateTransaction({        transactionId: tx.$id,        rollback: true,      });      throw error;    }    let wonKey: GameKey | null = null;    if (won) {      wonKey = await this.deliverKey(raffleId, userId);      if (wonKey) {        await this.handleRaffleClose(raffle);      } else {        await this.closeRaffle(raffleId);      }    }    const updatedProfile = await this.tablesDB.getRow<      Models.Row & { zcoinBalance?: number }    >({      databaseId: RaffleService.DB_ID,      tableId: 'user_profiles',      rowId: profile.$id,    });    return {      entryId,      raffleId,      userId,      ticketCount: dto.ticketCount,      baseTotalCost,      discountPercent,      discountAmount,      totalCost,      luckyNumbers,      drawNumber,      won,      wonKey: wonKey ? { platform: wonKey.platform, key: wonKey.key } : null,      newBalance: Number(updatedProfile.zcoinBalance ?? 0),    };  }

O problema real: Estatística vs. Realidade

Até agora, rodamos aproximadamente 34 sorteios e 129 tickets foram gerados no total. Ninguém ganhou ainda.

Olhando puramente para a matemática, com uma chance de 1/1000 por ticket e apenas 129 tentativas acumuladas no ecossistema, a probabilidade de termos um ganhador até agora era realmente baixa. Isso me fez pensar se a barreira inicial não ficou alta demais para o volume atual de usuários. Como reflexo disso, dei uma leve reduzida no basicProbability para tornar as coisas mais dinâmicas.

O que vocês acham dessa abordagem de gerar o drawNumber instantaneamente na compra do ticket em vez de acumular e rodar um cron posterior?

E, claro, se quiserem testar o app e me ajudar a encontrar os primeiros ganhadores dessas chaves, o Zetho está aberto. Feedbacks sobre o código e a lógica são super bem-vindos!

Fala pessoal, tudo certo?

Gostaria de compartilhar com vocês um projeto que venho desenvolvendo faz um certo tempo e que finalmente está em uma fase publicável Mine Hour (https://minehour.com/).

Durante anos sempre curti jogar Minecraft com amigos, mas a gente só conseguia se reunir de vez em quando (principalmente nos finais de semana ou algumas poucas horas durante a semana e só quando o host do radmin tava on). O problema era que qualquer serviço de hospedagem de servidor de minecraft cobra uma mensalidade fixa para manter a máquina ligada 24/7. No nosso caso, o servidor ficava vazio em 90% do tempo, e a gente acabava jogando dinheiro fora.

Daí veio a ideia: por que não criar um serviço de hospedagem onde só se paga pelo tempo em que o servidor está realmente ativo e os jogadores online?

Se ninguém está jogando, o servidor desliga e o consumo de créditos para. Quando você e seus amigos querem jogar, o servidor inicia em segundos, carrega o mapa de onde parou, e a cobrança é feita de forma transparente por hora de uso de acordo com os créditos que você tem disponíveis.

Como funciona a infraestrutura por trás

Eu queria que a infraestrutura fosse moderna, barata de manter e escalável. O fluxo técnico funciona assim:

1. Containers de Minecraft: Cada servidor é um container temporário na Oracle Cloud (OCI) rodando uma imagem customizada de Minecraft. Isso garante isolamento total de recursos e inicialização relativamente rápida.
2. Persistência do Mapa: Toda vez que um servidor desliga ou pausa por inatividade, o estado atualizado do mundo é salvo em um storage compatível com S3. Quando o servidor inicia de novo, o mapa é restaurado instantaneamente.
3. Roteamento Dinâmico: Para que os jogadores conectem usando sempre o mesmo IP/domínio, usei um proxy que conheço há muito tempo e sempre quis testar, na minha época dos grandes servidores de mine sempre usava BungeeCord porque era o que tinha na época, mas encontrei esse projeto Minekube Gate (escrito em Go). Criei um microserviço em Rust que gerencia a tabela de rotas dinamicamente. Quando o servidor é iniciado no painel, a rota é atualizada para redirecionar o tráfego TCP do IP principal direto para o IP temporário do container da Oracle Cloud onde o servidor foi provisionado. O jogador conecta instantaneamente sem precisar saber o IP real do container.
4. Desligamento e Avisos In-Game: Um script monitora a contagem de jogadores ativos. Se o servidor ficar vazio por algum tempo, ele desliga automaticamente para economizar créditos. E se os créditos do usuário estiverem acabando enquanto ele está jogando, enviamos avisos via console do jogo para alertar in-game ("Aviso: Restam 10 minutos de créditos..."), garantindo que ninguém seja desconectado de surpresa.

O que eu testei para chegar nessa infraestrutura

Inicialmente eu queria usar Magalu Cloud, uma vez descobri sobre a existência desse provedor de cloud da magalu, quando tive a ideia dessa minha plataforma sempre pensei em usar a Magalu Cloud principalmente pelos preços por hora ser muito competitivo, porém tinha alguns impasses, fazer automações grandes como usar kubernetes é complicado para o meu caso eu estava fugindo de custos fixos principalmente nessa fase inicial, tentei usar a função snapshot da magalu, achei interessante funcionou perfeitamente para o meu caso, a instancia iniciava em um tempo relativamente bom, e só tive o trabalho para automatizar deploys de novas snapshot, porém ao entrar em contato com o suporte da magalu cloud perguntei se eu poderia fazer uma aplicação de tipo, e se não caracterizava revenda, eles consultaram o juridico e no fim não consegui dar prosseguimento na magalu, e também eu teria que solicitar mais cotas de instancias, posso criar se não me engano no máximo 6, não me lembro exatamente agora.

Considerando preços da AWS estava fora do radar no brasil, então só usei a AWS para hospedar o backend. Entre outras opções acredito que a Oracle Cloud foi o que mais encaixou para o meu caso, mesmo sendo ligeiramente mais caro que a Magalu.

O projeto está no ar em https://minehour.com/.

Se vocês puderem comentar sobre essa abordagem de cobrança por hora em servidores de minecraft e sobre a arquitetura de infraestrutura.

Se quiserem trocar uma ideia sobre o projeto e dar uma força, entrem no discord que criei: https://discord.gg/DxJFknfmHZ

A maioria das pessoas que tenta isto falha. E falha pelos mesmos motivos. Não são os que imaginas.

O que o mercado quer mesmo

O diploma nunca foi prova de que sabes fazer alguma coisa. Na prática, era uma forma de dizer "esta pessoa conseguiu comprometer-se com algo durante anos". Isso tem valor. O problema é que o mercado começou a aceitar outras formas de dizer a mesma coisa, mas só em certas áreas.

As áreas onde isto funciona mesmo: programação, design digital, marketing e SEO, vendas B2B, segurança informática, cloud e infraestrutura, criação de conteúdo com audiência real. Basicamente, áreas onde o teu trabalho é visível e mensurável.

Medicina, direito, engenharia civil, arquitectura: esqueço. Não há atalho aqui que funcione na prática. Melhor saber isto agora do que descobrir a meio caminho.

Os desafios reais (não os óbvios)

O filtro automático. Grande parte das candidaturas online passa por um software, o chamado ATS, que filtra CVs antes de qualquer pessoa os ler. Bom, esse software muitas vezes elimina quem não tem grau académico. O teu CV pode ser excelente e nunca chegar a nenhum humano.

O tecto invisível. Entrar é difícil, mas há outro problema que aparece depois. Mesmo que consigas o emprego, promoções para cargos de chefia em empresas grandes podem ser bloqueadas internamente por falta de diploma. Ninguém te diz isso directamente, mas está nos critérios formais de RH.

Tens de provar mais. Para substituir o diploma, precisas de portfolio, projectos reais, resultados documentados. Aliás, este processo leva mais tempo e mais energia do que muita gente imagina quando começa.

O peso cultural. Em muitos contextos, em África e boa parte da Europa incluídos, o diploma tem um peso social enorme. Na prática, isso significa que em cada entrevista estás a pedir credibilidade emprestada. Com o tempo, cansa.

Depende muito de onde te candidatas. Uma startup pequena contrata-te pelo que fazes. Uma grande empresa com departamento de RH tem uma checklist e tu não a preenches.

Onde as pessoas perdem

O erro mais comum não é não saber fazer as coisas. É confundir estudar com trabalhar. Ou seja, alguém passa um ano e meio a fazer cursos online, acumula doze certificados, e na entrevista não tem um único projecto real para mostrar.

Certificados sem trabalho real para mostrar valem muito pouco. O mercado quer saber o que construíste, o que vendeste, o problema que resolveste. Não quer a tua lista de cursos.

O segundo erro é bater à porta errada. Tentar entrar directamente numa empresa grande sem diploma e sem rede de contactos é, na prática, uma perda de tempo. O caminho funciona assim: freelance primeiro, depois startups pequenas, depois médias, depois empresas maiores. Saltas etapas e ficas preso.

O terceiro erro, e este é subtil, é só pensar em networking quando precisas de emprego. Nessa altura já é tarde. Os contactos que te ajudam são os que te conhecem antes de precisares deles.

Os perfis que se vão dar mal

O Eterno Estudante. Faz curso atrás de curso. Sente que "ainda não está pronto". Fica nesse loop para sempre e nunca chega à fase de fazer.

O Candidato Passivo. Envia CVs para vagas online, espera, não recebe resposta, fica frustrado. Espera que o processo funcione igual ao de quem tem diploma. Não funciona.

O Generalista Sem Foco. Sabe um bocado de tudo: marketing, código, design, gestão. Bom, o problema é que ninguém o contrata para nada específico porque não resolve nenhum problema concreto de forma clara.

O Impaciente. Quer salário alto em seis meses. Recusa começar por baixo. Acha que freelance ou estágios estão abaixo da sua capacidade. Fica à espera de uma oportunidade que não aparece.

O que separa quem consegue de quem não consegue não é o talento. É conseguir gerar prova visível do seu trabalho antes de precisar de emprego.

Como se dar bem, se reunires as condições certas

Precisas de três coisas ao mesmo tempo: especialização numa área com procura real, evidências públicas do teu trabalho, e acesso directo a quem decide, não a formulários de candidatura.

1. Especializa-te onde há falta de gente

Não sejas "developer". Sê a pessoa que resolve problemas de performance em lojas Shopify, ou que faz ads para empresas SaaS B2B, ou que trabalha segurança em contratos de blockchain. Quanto mais específico, menos concorrência e mais fácil justificar um preço alto. Generalistas competem com toda a gente. Especialistas têm lista de espera.

2. Constrói o teu historial antes de precisar dele

Portfolio, artigos onde explicas o que fazes, projectos com resultados reais. Na minha experiência, um developer sem diploma que tem três projectos públicos com tráfego real impressiona mais em entrevista do que muitos recém-licenciados. A tua presença online substitui o diploma, e ao contrário do diploma podes actualizá-la quando quiseres.

Uma coisa importante: publica o processo, não só o resultado. Escreve sobre o que correu mal e como resolveste. Isso diz muito mais sobre ti do que mostrar só o produto final.

3. Evita o processo de recrutamento padrão

O sistema de candidaturas foi feito para filtrar com base em critérios formais. Tu não tens esses critérios, então não entres por essa porta. Contacta directamente fundadores, directores técnicos, pessoas cujo trabalho admiras. Contribui para os projectos delas. Oferece uma semana de trabalho grátis para uma empresa que queres impressionar. Isso vale mais do que cinquenta candidaturas enviadas para formulários que ninguém lê.

4. Começa pelo freelance, não pelo emprego

O freelance elimina o filtro do diploma quase por completo. Ninguém te pede certificado quando já entregaste resultados. Dois ou três clientes satisfeitos com trabalho documentado valem mais do que qualquer curso. Quando finalmente te candidatas a um emprego, entras como profissional com historial, não como mais um candidato anónimo.

5. Usa certificações com cabeça

Certificações não são iguais a diplomas, mas em áreas técnicas fecham parte do gap. AWS, Google Cloud, certificações de segurança como OSCP, Google Ads: são sinais que alguns sistemas reconhecem. O importante é dominar uma ou duas a fundo. Coleccionar certificados sem profundidade é o mesmo erro do ponto anterior.

A verdade que fica por dizer

Conseguir emprego bem pago sem diploma é possível. Mas é mais difícil, não mais fácil. A ideia de que "o diploma já não vale nada" é, honestamente, enganadora. O diploma ainda poupa anos de trabalho de construção de credibilidade. O que mudou é que existem substitutos, mas exigem mais disciplina, mais paciência e mais tolerância à rejeição do que simplesmente acabar uma licenciatura.

Se estás nisto para evitar esforço, não vai funcionar. O caminho sem diploma exige mais esforço, não menos.

Mas se tens a especialização certa, a disciplina para construir prova pública, e a paciência para seguir o canal certo: o mercado recompensa. E quando recompensa, faz-o bem.

Tenho 12 anos e criei meu próprio Sistema Operacional Gráfico do zero (sem Linux) rodando em disco real. O que aprendi nessa jornada.

Olá, pessoal do TabNews! Meu nome é Lucas Prado Coelho, tenho 12 anos e gostaria de compartilhar com vocês o meu maior desafio técnico até hoje: o desenvolvimento do GenesisOS, um sistema operacional gráfico de 32 bits escrito do absoluto zero (em C e Assembly x86) que roda diretamente no hardware emulado.

Sei que este é um projeto estritamente educacional e que um sistema de hobista não tem o objetivo de competir com gigantes como o Windows ou o Linux, mas a quantidade de conceitos de baixo nível, eletrônica e arquitetura de computadores que aprendi ao longo dessa jornada foi simplesmente incrível.

Gostaria de detalhar os principais componentes que precisei programar para fazer o GenesisOS ganhar vida:

🚀 A Arquitetura do GenesisOS

Diferente de muitas distribuições que utilizam o kernel do Linux como base, o GenesisOS roda em modo bare-metal (direto no metal). Ele usa o padrão Multiboot e inicializa em modo protegido de 32 bits.

Aqui estão os pilares que precisei construir para que o sistema funcionasse:

1. Driver de Vídeo e o Modo Gráfico (BGA)

Para sair da tradicional tela de texto preta do VGA, precisei programar um driver para a placa de vídeo emulada do QEMU (a Bochs Graphics Adapter ou BGA).

Ativei a resolução de 1024x768 pixels em 32-bit True Color (milhões de cores) enviando comandos de escrita diretamente nas portas físicas 0x01CE e 0x01CF.

Para evitar que as janelas e o mouse piscassem na tela ao serem arrastados (flickering), implementei a técnica de Double Buffering. Todo o sistema é desenhado de forma extremamente rápida em uma tela invisível de 3MB na memória RAM (backbuffer) e, ao final de cada quadro, o bloco inteiro é copiado ("blitado") para a memória de vídeo física (0xFD000000).

2. Driver de Disco Rígido e o GenesisOS File System (GFS)

Este foi um dos maiores desafios. Em vez de simular arquivos em memória estática, programei um driver de disco rígido IDE/ATA físico usando comunicação de hardware via portas I/O (0x1F0 a 0x1F7) em modo PIO de 28 bits (LBA28).

Criei o GFS (GenesisOS File System). Ao iniciar o sistema pela primeira vez, o kernel lê o Setor 1 do HD virtual (disk.img). Se o disco estiver em branco, ele formata o disco e grava a tabela de arquivos mestre.

O sistema de arquivos é persistente e real: quando você cria um arquivo ou apaga no File Explorer, a tabela é reescrita e gravada fisicamente de volta no arquivo de disco. Ao reiniciar o emulador, as modificações continuam lá!

3. Driver do Mouse Físico (PS/2)

Habilitei a porta auxiliar do mouse no controlador de teclado (0x64). O mouse PS/2 envia dados em ciclos rápidos de 3 bytes (botões clicados, delta X e delta Y).

Usei uma verificação de sincronização baseada no bit 3 do primeiro byte (!(data & 0x08)) para garantir que o mouse nunca perca o alinhamento de leitura e o cursor não saia deslizando sozinho de forma caótica.

4. Relógio CMOS em Tempo Real

Para exibir a hora exata no sistema, programei a leitura do chip CMOS da placa-mãe (portas 0x70 e 0x71). Para não sobrecarregar o hardware com leituras constantes (o que causava lag), implementei um limitador de quadros para ler as horas apenas a cada 30 frames.

🎨 A Interface Gráfica (Aero/Luna Vibe) e os Apps

A interface visual do GenesisOS foi inspirada na era do Windows XP (Luna Theme) e Windows Vista (Frutiger Aero). Desenhei botões com faixas brilhantes (glossy glass) e janelas com cantos arredondados (calculados via raio matemático no laço de pixels).

Docks Modularizados: A barra de tarefas foi substituída por 4 docks independentes (SYSTEM, APPS, POWER e CLOCK) que podem ser arrastados livremente para qualquer canto da tela. Ao soltá-los, eles sofrem uma atração magnética (snapping) e se acoplam suavemente nas bordas.

File Explorer Hierárquico: Permite navegar por diretórios reais do HD (Root / e /documents), além de possuir funções de Criar, Deletar e Renomear arquivos.

Notepad (Editor de Texto): Ao abrir um arquivo .txt no File Explorer, você pode usar o seu teclado físico para digitar textos e salvar as alterações direto no setor físico correspondente do HD.

Genesis Paint: Um aplicativo de desenho em escala de 64x64 pixels onde você arrasta o mouse físico real para desenhar e pode salvar sua arte direto no disco.

🛠️ Como desenvolvi tudo no Windows?

Desenvolver sistemas operacionais no Windows de forma nativa é um desafio conhecido devido ao formato de arquivos executáveis (PE vs ELF). Resolvi isso utilizando a cadeia de compiladores cruzados i686-elf-tools do projeto do Lordmilko no GitHub.

Para agilizar o desenvolvimento, configurei um script em PowerShell (compile.ps1) com loop de Auto-Heal (Auto-Correção):

Toda vez que o GCC 15 exibe um erro de digitação do tipo "did you mean 'sugestao'?", o próprio script analisa o log de erros, substitui a variável incorreta no kernel.c e tenta compilar novamente de forma autônoma!

📦 Código e Download da ISO

O GenesisOS está com o código-fonte totalmente aberto. O repositório contém as instruções de compilação, o script de auto-correção, o arquivo do linker e o bootloader.

📂 Repositório no GitHub: https://prilugano992-cmyk.github.io/Lucas-s-Projects/

💾 Download Direto da ISO Bootável: https://github.com/prilugano992-cmyk/Lucas-s-Projects/releases/download/v1.0.0/genesis.iso

Fiquei muito feliz em concluir esse ciclo de desenvolvimento do GenesisOS. Gostaria de ouvir o feedback de vocês, dicas de baixo nível e sugestões de arquitetura. Muito obrigado!

Por muito tempo eu travei no mesmo lugar: toda ideia de projeto que me vinha, eu descartava com "isso já existe". E quase sempre existia mesmo, de alguma forma. O resultado é que eu não terminava nada — nem começava.

O que destravou não foi ter uma ideia genial. Foi mudar duas coisas.

A primeira: parei de buscar ideias originais e comecei a buscar problemas que me incomodam. Originalidade quase nunca está no conceito — está no recorte. Já existe editor de texto, já existe app de tarefa, já existe tudo. Mas não existe feito do seu jeito, pro seu uso, com as decisões que você tomaria.

No meu caso o incômodo era ruído de terminal. npm install cospe 3000 linhas. Stack trace longo empurra pra fora da tela justamente a linha que importa. Eu queria algo que pegasse esse output caótico e mostrasse só o que interessa — não escondendo, mas re-apresentando.
A ideia que fechou foi: tratar o output como estado, não como histórico. Em vez de um rio de linhas rolando, um cabeçalho vivo com contadores e a fase atual colapsada num item só. Warnings e erros quebram a sequência e ficam visíveis. Chamei de IceTea, feito em Go.

A segunda mudança, e a que mais importou: fatiar. "Fazer o IceTea" é uma tarefa que trava qualquer um — escopo grande demais, você nem sabe por onde pegar. Então quebrei em marcos minúsculos, cada um com algo funcionando no fim:

Marco 0: rodar um comando filho e capturar stdout/stderr. Só isso. ~80 linhas.
Marco 1: classificar cada linha (info/warn/erro) e contar.
Marco 2: a primeira TUI, feia, só o cabeçalho vivo.
Marco 3: cair pra modo texto quando não é terminal (pipe, CI).
Marco 4: o colapso de verdade — 150 linhas de info viram uma só.

Cada marco era uma sessão curta. Em nenhum momento eu tinha nas mãos um monte de código que eu não entendia. E isso me leva à terceira parte, que eu quero falar abertamente: usei IA no processo — Claude pra discutir arquitetura. Mas não do jeito "manda fazer o projeto inteiro". Cada marco era um prompt pequeno e específico. Quando o código voltava, eu lia inteiro e pedia explicação do que não entendia antes de seguir. O fatiamento não era só organização — era o que me mantinha dono do código. Um IceTea de 2000 linhas que a IA cospe de uma vez não é meu projeto; cinco marcos de ~100 linhas que eu entendo são.
E parei no v0.1.0 de propósito. Tenho uma lista de features (scroll, perfis por ferramenta, etc.), mas antes de adicionar qualquer coisa quero usar a ferramenta de verdade por uma semana e deixar o uso real dizer o que importa — em vez de adivinhar.

O projeto tá aqui, se quiserem ver ou destruir no code review: github.com/realknove/IceTea

Mas o que eu queria mesmo deixar é o aprendizado, que serve pra qualquer projeto: a barreira raramente é falta de ideia original. É escopo grande demais e medo de começar. Recorte um problema seu, fatie até o primeiro pedaço caber numa tarde, e termine esse pedaço. O resto vem.

O slide da consultoria de terno cinza aceita qualquer palhaçada. Na planilha de projeção do CFO, a conta parecia simples: demitir dez analistas de suporte, desligar algumas licenças de software legado e colocar um agente autônomo baseado em LLM rodando na nuvem. Economia projetada de 80% na folha de pagamento e atendimento 24 horas por dia.

Aí o sistema vai para a produção.

E a realidade da infraestrutura de hardware bate na porta com a sutileza de um martelo de forja.

O que as grandes empresas estão descobrindo da pior maneira é que a física da computação não liga para o hype de marketing. Substituir o discernimento humano por modelos de linguagem gigantescos não é uma simples troca de linhas de orçamento. É a substituição de uma força de trabalho biologicamente otimizada por uma cadeia de custos de processamento que escala de forma caótica.

A Física do Silício contra a Heurística de um Prato de Comida

Um analista pleno de suporte resolve problemas complexos de clientes consumindo o equivalente calórico de um prato de almoço comercial. Ele usa heurística acumulada, contexto social e a capacidade intrínseca de ler entrelinhas para entender que o cliente está irritado porque o pagamento falhou na API de faturamento.

Para fazer uma máquina ter uma fração dessa capacidade de discernimento, você precisa de um cluster de GPUs Nvidia H100 consumindo centenas de watts de energia por placa, sem contar a infraestrutura de refrigeração do data center necessária para manter esse silício operando sem derreter.

O custo de processamento de dados cresce de forma brutal à medida que o tamanho do contexto do modelo aumenta. O mecanismo de atenção das arquiteturas Transformer escala o consumo de recursos de forma quadrática em relação ao tamanho da janela de contexto. Traduzindo do jargão acadêmico para o mundo real da produção: quanto mais documento, histórico de conversa e logs de erro você envia para a IA tentar entender o que está acontecendo, mais cara e lenta fica cada palavra gerada por ela.

O Ralo Silencioso da Inferência de Modelos de Linguagem

Se você já tentou subir um sistema com agentes autônomos na produção, conhece a armadilha do orquestrador. Na teoria, você programa o agente para planejar, autoavaliar e corrigir as próprias respostas antes de entregar o resultado final para o usuário.

Na prática, isso se traduz em um loop de requisições assíncronas que queima créditos de API em velocidade recorde.

Uma única pergunta do usuário pode disparar dez chamadas internas de API. O agente decide buscar informações no banco de dados vetorial, falha na primeira busca, tenta um termo de pesquisa diferente, recebe uma resposta com dados estruturados incorretamente, entra em uma rotina de autocorreção para formatar o JSON e, finalmente, gera uma resposta padrão de três linhas que um atendente humano digitaria em dez segundos.

A conta de tokens de entrada e saída explode antes do fim do expediente. O custo unitário por transação deixa de fazer qualquer sentido econômico. Você acha que está economizando dinheiro tirando um salário fixo da folha de pagamento, mas acaba com uma conta de processamento na nuvem que é variável, imprevisível e que escala direto para o limite do cartão corporativo caso um único usuário decida abusar do sistema com prompts imensos.

E o pior: o sistema é frágil de uma forma que os sistemas tradicionais nunca foram.

O Custo Oculto da Manutenção de Sistemas Imprevisíveis

Quando um microsserviço tradicional em Go ou Node.js quebra, você tem um stack trace limpo no console, um log de erro óbvio e uma rota que você consegue corrigir em minutos.

Quando um sistema baseado em IA quebra, a falha é silenciosa e bizarra.

O modelo pode simplesmente decidir que o formato do JSON que ele gerava perfeitamente há três semanas agora precisa ter um campo aninhado extra porque a empresa parceira atualizou silenciosamente o modelo de fundação na nuvem. Essa mudança sutil quebra o seu parser interno de backend, gerando um erro de desmaterialização de objeto que paralisa o fluxo de checkout e joga um erro genérico na cara do cliente final.

Quem corrige isso não é a IA. É o engenheiro de software sênior que custa caro por hora e que precisa gastar metade do dia ajustando prompts, testando novos limites de temperatura do modelo e criando validações manuais via código tradicional para garantir que a saída estatística da IA não destrua o banco de dados SQL da empresa.

Você acabou de trocar o custo de um analista de nível médio pelo custo de uma infraestrutura de nuvem inflacionada somada à hora técnica de engenheiros altamente especializados dedicados a monitorar se a máquina está alucinando ou não.

A Redução de Danos e a Volta ao Pragmatismo

Até gigantes como Microsoft, Uber e diversas empresas do mercado financeiro estão batendo de frente com a realidade dos números. A margem bruta de softwares baseados em IA pura é muito menor do que a do software tradicional baseado em lógica determinística exatamente por causa desse ralo de inferência.

A estratégia de investir tudo em IA em 2026 precisa passar por um filtro de engenharia de valor real.

Colocar modelos generativos gigantescos para ler PDFs e responder perguntas internas é um desperdício de recurso computacional que beira o ridículo. A maior parte das tarefas operacionais que as empresas tentam resolver com IA generativa de uso geral seria resolvida de forma dez vezes mais barata e rápida com rotinas tradicionais de processamento de texto, sistemas de busca baseados em palavras-chave bem indexados ou modelos de machine learning clássicos e especializados de tamanho reduzido rodando localmente em servidores baratos.

O mercado está acordando do coma do hype técnico. A inteligência artificial tem seu espaço como ferramenta de apoio técnico para aumentar a produtividade de quem já é bom, mas tentar usar ela como substituta barata da mão de obra sem fazer o cálculo do consumo real de hardware e da equipe de suporte necessária para manter a máquina funcionando é apenas uma receita rápida para queimar caixa e enriquecer provedor de nuvem.

Como resolvi o problema de lag do macOS no Cloud Gaming criando um utilitário nativo em Swift (Open Source)

Fala, pessoal!

Como estudante de Engenharia de Software aqui em Recife, eu sempre acabo esbarrando em problemas que me forçam a sair do desenvolvimento web/backend tradicional e descer um pouco mais para o nível do sistema operacional. O mais recente foi tentar jogar via Cloud Gaming (GeForce NOW, xCloud, Moonlight, etc.) no Mac.

🔴 O Problema

O macOS tem um comportamento terrível para streaming de alta taxa de atualização e baixa latência.

De tempos em tempos, o sistema usa a interface awdl0 (Apple Wireless Direct Link, responsável pelo AirDrop e Handoff) para escanear a rede em background. Isso tira o Wi-Fi do canal principal por frações de segundo, resultando em ping spikes absurdos e travamentos na tela. Além disso, os processos em segundo plano roubando CPU e a aceleração nativa do mouse da Apple atrapalham muito a fluidez e a precisão.

🟢 A Solução: CloudBoost

Para resolver isso, desenvolvi uma ferramenta de barra de menus (menu bar) nativa em Swift chamada CloudBoost. A ideia é ser um utilitário leve que "blinda" o sistema enquanto você joga, e depois devolve tudo ao normal com um clique.

O que o script automatiza por baixo dos panos quando ativado:

• Estabiliza a rede: Desativa o AWDL temporariamente para matar os picos de ping causados por escaneamento de rede.
• Injeta prioridade máxima: Usa o comando renice (-20) focado no processo do jogo selecionado para que a CPU não seja roubada por tarefas em background.
• Trava a performance: Pausa o Time Machine e roda o processo nativo caffeinate para evitar throttling de performance e economia de energia no meio da partida.
• Otimiza recursos: Limpa o cache de DNS para rotas limpas e força um purge na memória unificada inativa, liberando espaço para o decoder de vídeo.
• Bypass de Mouse: Aplica perfis de Raw Input para contornar a curva de aceleração padrão do macOS (útil para FPS/MOBA).

⚙️ Binário Universal e Open Source

Recentemente, reescrevi a arquitetura principal para compilar como um Universal Binary. Isso significa que ele roda nativamente no bare metal, tanto nos novos Macs M-Series (arm64) quanto na raça guerreira dos Macs Intel (x86_64), sem passar pela sobrecarga da tradução do Rosetta.

O projeto é 100% gratuito e agora está sob a licença GPLv3 (para evitar que peguem o código aberto, fechem e tentem vender na App Store, o que infelizmente é comum com ferramentas de nicho).

🤝 Feedback

Gostaria muito do feedback da comunidade! Se alguém manjar de Swift, automação no macOS ou tiver ideias de como melhorar o gerenciamento de processos (atualmente implementei um sistema de Allowlist/Blocklist para o alvo do renice), toda contribuição ou PR no repositório é muito bem-vinda.

🔗 Repositório GitHub e Download: CloudBoost no GitHub

Valeu!

O contexto: code review na era da IA
Code review sempre foi um dos rituais mais importantes da engenharia. Mas seja honesto: quantas vezes um PR fica parado por dias esperando alguém olhar? Quantas vezes a revisão acontece no automático, com um "tá bom, pode subir" depois de bater o olho em 800 linhas?

Numa era em que muito código é escrito por IA, revisar virou ainda mais crítico. Código gerado por IA tende a parecer correto, e é justamente aí que mora o risco.

E quando falamos de segurança, o jogo muda completamente. SQL injection, secrets vazados, criptografia mal implementada, validação ausente. Esses são bugs que você NÃO quer descobrir em produção. Revisão de segurança exige um tipo de raciocínio diferente da revisão de engenharia: outro vocabulário, outro modelo mental, outros padrões.

A decisão: dois subagentes especializados, não um generalista
Aqui está a primeira lição que quero compartilhar: misturar code review e security review num único agente produz um resultado não tão bom nos dois lados.

Foi por isso que o projeto nasceu com dois subagentes independentes, cada um com seu foco e, importante, cada um rodando em um modelo de IA diferente. Um é responsável pela revisão de engenharia (arquitetura, performance, qualidade) e roda no Gemini 3, o modelo mais recente do Google. O outro é responsável pela revisão de segurança (OWASP, secrets, crypto) e roda no Claude Opus 4.7, o modelo mais avançado da Anthropic.

A escolha de cada modelo foi proposital. O Gemini 3 tem se mostrado excelente em raciocínio sobre código em escala, captando padrões arquiteturais e questões de performance com bastante precisão. Já o Claude Opus 4.7 brilha em tarefas que exigem raciocínio cuidadoso, output estruturado e atenção ao detalhe, exatamente o perfil que segurança demanda.

Essa estratégia de usar dois modelos diferentes traz um benefício importante: de certa forma, você recebe dois pontos de vista distintos sobre o mesmo Pull Request. Modelos diferentes foram treinados em corpora diferentes, têm vieses diferentes, e enxergam coisas diferentes. Quando dois modelos olham para o mesmo código com objetivos distintos, o resultado é uma revisão muito mais rica do que qualquer um deles entregaria sozinho.

Stack resumida: FastAPI + asyncio para o orchestrator, SQLite com WAL para estado, Gemini 3 + MCP para code review, Claude Opus 4.7 (via AWS Bedrock + tool use) para segurança, structlog para observabilidade.

Os dois rodam em paralelo sobre o mesmo PR. Um delega segurança ao outro. O outro delega arquitetura ao primeiro. Sem sobreposição, sem ruído.

Por que não usamos uma ferramenta pronta
Existem várias soluções comerciais de code review com IA no mercado. Avaliamos várias. E mesmo assim escolhemos construir. Três motivos:

1. Customização real para os padrões da empresa. Cada projeto nosso tem um arquivo de contexto que descreve os padrões daquele repositório: ADRs, idioms, decisões arquiteturais, convenções específicas. O agente carrega esse contexto antes de revisar. Isso significa que ele não fala "use prepared statements" como conselho genérico. Ele aponta o padrão exato que o time já adotou, no estilo que o time já documentou. Ferramentas externas não conseguem esse nível de contextualização personalizavel.

2. Qualidade dirigida ao nosso problema. Conseguimos calibrar a confiança mínima dos findings, escolher os modelos certos para cada tipo de análise, e forçar output estruturado onde isso importa (segurança). Conseguimos decidir o que vira comentário e o que não vira. A revisão fica focada em sinal, não em ruído.

3. Custo controlado. Soluções SaaS cobram por seat, por PR, ou por linha analisada. Com a infra própria, pagamos só o custo dos tokens. E ainda conseguimos aplicar filtros agressivos antes de gastar uma chamada de modelo (PRs muito grandes, paths ignorados, bots de dependência, etc.). Em escala, a economia é considerável.

Some isso ao fato de que nada do nosso código sai da nossa infra para um terceiro, e a equação fica clara.

O impacto nos times
O que mudou no dia a dia desde que o sistema entrou em produção, em todos os times da empresa:

Cobertura sistemática. Todo PR é revisado por IA em minutos, independente de quem está disponível. Ninguém mais espera dias por uma primeira passada.

Revisores humanos focam no que importa. Decisões de produto, contexto de negócio, trade-offs arquiteturais. Coisas que IA não captura. Os N+1, os secrets esquecidos, as queries concatenadas, os agentes pegam. Importante deixar claro: a revisão humana não deve ser descartada. O agente não substitui o olhar de outro dev sobre o código, ele potencializa esse olhar. O humano continua sendo a última palavra antes do merge.

Os devs estão aprendendo com os code reviews. Esse é, talvez, o ganho que mais me surpreendeu. Os comentários do agente de code review são pedagógicos por design. Ele não só aponta o problema, ele explica o porquê e mostra como resolver da forma correta. Devs novos absorvem padrões só de ler a revisão dos próprios PRs. Devs mais experientes redescobrem alternativas que tinham esquecido. O code review virou uma ferramenta de aprendizado contínuo, não só um portão de qualidade.

Defesa em profundidade na segurança. O agente de segurança não substitui SAST, DAST ou revisão humana de segurança. Complementa. Mais uma camada antes do código entrar em master.

Velocidade. Feedback chega enquanto o contexto ainda está fresco na cabeça de quem escreveu. Correção é rápida, custo cognitivo baixo.

A lição mais importante
Construir foi mais simples do que eu imaginava, e mais profundo do que eu esperava. A parte difícil não é integrar com um LLM. É decidir o que pedir, como pedir, e como filtrar o que volta. É decidir que segurança merece output estruturado e auditável enquanto code review pode ser texto livre conversacional. É decidir que dois subagentes especializados batem um generalista. É escolher modelos diferentes propositalmente, para ganhar a riqueza de duas perspectivas.

IA não substitui revisão. IA muda quem revisa o quê. Os humanos sobem na cadeia de abstração e ganham tempo para pensar nas coisas que realmente exigem julgamento humano. E, no caminho, todo o time aprende.

Se você está pensando em adotar revisão automatizada no seu time, meu conselho é: experimente construir. Você vai aprender mais sobre o seu próprio processo de revisão do que qualquer ferramenta pronta vai te ensinar.

Algumas empresas que usam AI estão deixando de fazer revisão de Pull Request e adotando uma estratégia de “mission driven development”.

A ideia seria focar mais no o que, do que o como entregar.

Qual a opinião de vocês sobre isso?

O longa metragem “Hell Grind” levou apenas duas semanas para ser produzido e custou 500 mil dólares, sendo 80% só em computação. O projeto também evidenciou a dificuldade de criar um filme com a tecnologia, incluindo milhares de prompts detalhados, muitas iterações e necessidade de julgamento cinematográfico tradicional.

A intenção seria observar engenheiros criando ferramentas e resolvendo problemas para aumentar a capacidade de codificação de modelos internos, de maneira mais rápida que concorrentes, que “não possuem os milhares de excelentes engenheiros da Meta”. Os dados não serão usados para vigilância ou acompanhamento de desempenho.

O prompt injection ocorre quando esses documentos são modificados de forma adversarial e pesquisadores mostraram que basta adicionar 20 tokens a um SKILL[.]md para influenciar o modelo e evitar mecanismos de detecção. A recomendação é tratar especificações em linguagem natural como elementos sensíveis à segurança e ter mais cuidado na criação de registros de skills, mecanismos de ranqueamento, pipelines de governança e defesas do lado do agente.

No mercado atual de produção em massa, a SK hynix ainda registra o maior empilhamento com sua NAND 4D de 321 camadas. A Samsung já prepara a produção em massa da V-NAND de 10ª geração, com mais de 400 camadas, enquanto alcança 900 camadas na etapa de pesquisa. A memória flash NAND é essencial para servidores de IA, smartphones e SSDs de data centers, porque empilhar mais camadas aumenta a capacidade no mesmo tamanho de chip e melhora a eficiência energética.

A tecnologia não está entregando à empresa ganhos equivalentes aos valores investidos. Após discussões com líderes seniores de engenharia, a companhia percebeu que o maior uso de tokens não tem se traduzido em aumento proporcional de recursos úteis para usuários.

No “Magnifica Humanitas”, o Pontífice entende a tecnologia como instrumento, não como ente criativo, e afirma que os seres humanos jamais poderão ser substituídos ou superados. A IA também não seria intrinsecamente má, mas nunca é neutra, pois assume características de quem a concebe, financia, regula e utiliza. Por isso, deve ser construída para o bem comum, a serviço da humanidade e fora do controle de poucas empresas. Chris Olah, cofundador da Anthropic, que esteve no Vaticano nesta segunda-feira, defendeu a supervisão da IA por líderes religiosos, governos e pela sociedade.

A Nostr VPN é uma nova proposta de VPN descentralizada baseada no protocolo Nostr.
Diferente das VPNs tradicionais, que dependem de servidores controlados por empresas, a ideia aqui é usar uma rede distribuída com autenticação via chaves criptográficas.

💡 Na prática, isso significa:

• Sem login com e-mail ou senha
• Mais privacidade e menos dependência de empresas centralizadas
• Comunicação baseada em identidade criptográfica
• Estrutura peer-to-peer usando
• Maior resistência à censura e monitoramento

A proposta foi criada por Martti Malmi, um dos primeiros desenvolvedores do Bitcoin e colaborador de Satoshi Nakamoto.

🚨 Atenção:
A Nostr VPN NÃO é uma “VPN mágica” para anonimato absoluto. O projeto ainda está em evolução e é mais voltado para usuários avançados e entusiastas de privacidade digital.

🌐 O que torna isso interessante é a mudança de paradigma:
Em vez de confiar em uma empresa para proteger seus dados, a segurança passa a depender de criptografia, descentralização e controle do próprio usuário.

O futuro da privacidade online pode estar migrando de “confie na empresa” para “confie no protocolo”. 🚀

Fontes:
https://crypticmedia.co/bitcoin-pioneer-malmi-launches-nostr-vpn-ditching-centralized-server-model
https://grafa.com/en/news/crypto/nostr-vpn-martti-malmi
https://github.com/mmalmi/nostr-vpn

Depois de meses de desenvolvimento, refatorações, feedbacks da comunidade e muitas mudanças arquiteturais, finalmente lancei oficialmente o Darto 1.0.0 junto com seus primeiros plugins oficiais.

Pra quem ainda não conhece, o Darto é um framework backend para Dart inspirado em experiências modernas como Express.js, Fastify e Hono, mas tentando abraçar aquilo que o Dart faz de melhor:
tipagem forte, performance, tooling e compilação nativa.

A ideia do projeto sempre foi simples:
criar uma experiência moderna para desenvolvimento backend em Dart sem transformar tudo em algo complexo.

import 'package:darto/darto.dart';void main() {  final app = Darto();  app.get('/users/:id', [], (Context c) {    final id = c.req.param('id');        return c.ok({'id': id});  });  app.listen(3000);}

O que chegou na 1.0.0

• Sistema de rotas moderno
• Middleware global e por rota
• JWT, Basic Auth, Bearer Auth, API Key Auth
• WebSocket integrado
• Context centralizado
• Compressão, cache, secure headers, csrf, timeout
• Validação usando Zard
• Template engine
• Static files
• Reverse proxy
• CLI oficial
• Hot reload
• Build para binário nativo
• Gerador de cliente HTTP tipado para Flutter/Dart

Plugins oficiais

📦 darto_cli
📦 darto_env
📦 darto_static
📦 darto_validator
📦 darto_view
📦 darto_ws

Uma das maiores mudanças dessa versão foi abandonar APIs excessivamente “mágicas” usando dynamic e começar a focar muito mais em previsibilidade, autocomplete e experiência real de desenvolvimento dentro do ecossistema Dart.

Agora começa a fase mais importante:
testar em projetos reais.

Se alguém quiser testar, encontrar bugs, sugerir melhorias ou contribuir com ideias, o feedback será extremamente bem-vindo.

Esse é só o começo do que eu quero construir para backend no ecossistema Dart. 🚀

Porque em sistemas distribuídos você não controla totalmente a rede.

Quando seu sistema roda em várias máquinas, regiões, pods, bancos ou serviços diferentes, eles precisam se comunicar pela rede. E rede falha. Pode acontecer:

• uma instância não conseguir falar com outra;
• um banco ficar isolado temporariamente;
• uma região da cloud perder comunicação com outra;
• latência aumentar muito;
• pacotes serem perdidos;
• DNS, load balancer ou roteamento falharem;
• um nó estar vivo, mas inacessível para parte do sistema.

Isso é uma partição de rede: o sistema não caiu completamente, mas algumas partes dele não conseguem se comunicar entre si.

Então, em sistemas distribuídos, Partition Tolerance é praticamente obrigatória porque você precisa assumir que a rede pode falhar a qualquer momento. Não é uma questão de “se vai acontecer”, mas de “quando vai acontecer”.

O ponto principal do CAP é:

Quando acontece uma partição de rede, o sistema precisa escolher entre manter consistência ou manter disponibilidade.

Exemplo simples:

Imagine dois servidores:

Servidor A ───── Servidor B

Agora a rede entre eles falha:

Servidor A   X   Servidor B

Se os dois continuam aceitando escrita sem se comunicar, você ganha Availability, mas pode perder Consistency, porque cada lado pode ter uma versão diferente dos dados.

Se o sistema bloqueia uma das partes até a comunicação voltar, você preserva Consistency, mas perde Availability, porque algumas requisições vão falhar ou ficar indisponíveis.

Por isso, na prática, em sistemas distribuídos, você não escolhe entre C, A e P como se pudesse ignorar o P. O P já vem no pacote. A escolha real geralmente é:

Durante uma partição, meu sistema prefere CP ou AP?

CP: prefere consistência.
Bom para dinheiro, transações, estoque crítico, pedidos, saldo bancário.

AP: prefere disponibilidade.
Bom para likes, views, feed, cache, métricas, notificações, dados que podem sincronizar depois.

Olá, pessoal!

Quero compartilhar com vocês um projeto que venho desenvolvendo para a comunidade de Minecraft: o RadioMC.

A ideia do mod é trazer entretenimento completo para dentro do jogo de forma 100% integrada. Além de sintonizar mais de 51.000 estações de rádio, eu implementei um sistema onde você pesquisa o nome do vídeo do YouTube diretamente na interface do mod, escolhe o resultado e assiste ao vídeo (imagem e som) na tela do Minecraft, sem precisar abrir navegador ou ficar colando links externos.

Compatibilidade Exata de Versões e Loaders

Para evitar confusão na hora de instalar, o suporte do mod foi dividido estritamente assim:

Forge: Disponível exclusivamente para a versão clássica 1.8.9.

Fabric: Disponível especificamente para as versões mais recentes: 26.1, 26.1.1, 26.1.2, 1.21.10 e 1.21.11.

Como funciona por baixo dos panos?

A mágica de buscar, decodificar e renderizar tudo em tempo real acontece através da integração do yt-dlp com o FFmpeg rodando nos bastidores. O mod usa o yt-dlp para extrair os dados e o stream do YouTube, enquanto o FFmpeg faz o trabalho pesado de decodificar os frames de vídeo/áudio e renderizar a imagem dentro do jogo.

Instalação Automática: Para facilitar a vida de quem joga, você não precisa configurar nada no seu sistema. Se o mod não encontrar o FFmpeg ou o yt-dlp no seu computador, ele baixa e instala ambos de forma totalmente automática.

O mod é de código fechado, mas o download já está disponível para quem quiser testar nos seus mundos ou servidores:
https://modrinth.com/mod/radiomc

Tem uma coisa meio cruel acontecendo no desenvolvimento com IA: a gente ganhou ferramentas que executam tarefas cada vez mais rápido, mas muita gente ainda protege o ambiente como se o risco fosse só "baixei um pacote ruim".

Esse risco continua existindo. Só que agora ele vem com uma camada a mais.

Um pacote comprometido não precisa apenas rodar um script malicioso e roubar uma variável de ambiente esquecida. Ele pode procurar tokens de agente, mexer em configuração de editor, observar o CI, tentar persistir em ferramentas locais e esperar o próximo robô prestativo fazer o trabalho sujo com as mesmas permissões que você deu para ele.

Esse é o ponto que deveria acender uma luz para quem usa Codex, Claude Code, Copilot, Cursor, Windsurf ou qualquer fluxo parecido em repositório real: o agente não é só uma interface bonitinha para escrever código. Ele virou parte do seu ambiente de execução.

E ambiente de execução precisa de fronteira.

O ataque não termina no pacote instalado

O caso recente envolvendo pacotes do ecossistema TanStack é um bom alerta porque não parece aquele exemplo distante de segurança corporativa que a gente lê e esquece. É JavaScript. É npm. É exatamente o tipo de cadeia que passa pelo dia a dia de frontend, fullstack e indie dev.

O detalhe mais incômodo é que o malware não mirava apenas credenciais genéricas. Ele procurava sinais de CI, AWS, GitHub Actions, Vault, Kubernetes e também configurações ligadas a ferramentas de agente, incluindo Claude Code e VS Code.

Isso muda a pergunta.

Antes, muita gente olhava para supply chain como: "esse pacote roda algo perigoso na instalação?".

Agora a pergunta ficou maior: "o que acontece depois que esse pacote entra em um ambiente onde agentes leem arquivos, executam comandos, editam o repo e têm acesso a tokens locais?".

O npm install virou só o primeiro ato.

Se o seu agente roda no mesmo usuário do sistema, vê os mesmos arquivos, herda as mesmas variáveis e consegue chamar os mesmos comandos, qualquer sujeira que entrou no projeto pode ganhar um ajudante muito eficiente. Não porque o agente "quer" atacar algo, mas porque ele opera dentro de um contexto que talvez já esteja contaminado.

Agente bom demais com permissão demais é um problema

Eu gosto de agentes de código. Uso esse tipo de ferramenta justamente porque ela tira atrito de tarefas chatas: ajustar testes, navegar em repo grande, preparar PR, procurar inconsistência, refatorar pedaços pequenos.

Mas tem uma armadilha nessa produtividade.

Quando a ferramenta funciona bem, dá vontade de liberar mais coisa. Mais diretórios. Mais comandos. Mais acesso à internet. Mais credenciais. Mais automação no CI. Em pouco tempo, aquele assistente que deveria mexer em uma feature passa a operar como um desenvolvedor com acesso amplo, só que sem o mesmo senso de contexto humano.

Não adianta colocar no prompt:

Não leia secrets e não execute comandos perigosos.

Isso ajuda, mas não é fronteira de segurança. É pedido educado.

Fronteira de verdade é o ambiente impedir ou limitar a ação. É o agente não ter acesso ao arquivo. É a variável não estar disponível. É a rede estar bloqueada por padrão. É o comando destrutivo precisar de aprovação. É o CI rodar com permissões mínimas.

Prompt é orientação. Sandbox é contenção.

Essa diferença ficou bem mais importante agora.

Sandbox deixou de ser frescura

Quando a OpenAI fala sobre a dificuldade de construir um sandbox seguro para o Codex no Windows, o ponto interessante não é só "Windows é difícil". O ponto é que um agente local precisa de isolamento no nível do sistema operacional para ser útil sem virar uma porta aberta.

Um bom sandbox tenta responder perguntas bem práticas:

• quais arquivos esse agente pode ler?
• onde ele pode escrever?
• ele pode acessar a rede?
• quais processos filhos ele pode criar?
• o que acontece quando ele tenta sair do escopo?
• como eu audito o que ele fez?

Perceba como isso é diferente de confiar que o modelo vai se comportar.

Em um projeto pequeno, talvez você não tenha uma infraestrutura sofisticada. Tudo bem. Mas ainda dá para fazer o básico com bastante impacto:

• rodar o agente em um diretório de trabalho separado;
• usar usuário ou container sem acesso a arquivos pessoais;
• bloquear rede quando a tarefa não precisa baixar nada;
• passar variáveis falsas em vez de secrets reais;
• exigir confirmação para instalação de pacote;
• apagar tokens temporários depois da tarefa;
• revisar qualquer mudança em configuração, scripts e workflow.

Nada disso deixa o fluxo "enterprise demais". Pelo contrário: deixa o fluxo mais tranquilo para usar no dia a dia.

O objetivo não é criar medo de ferramenta. É poder usar a ferramenta sem depender de sorte.

O CI também precisa tratar agente como agente

Outra parte sensível é o CI.

Quando um agente entra no GitHub Actions, a conversa muda de "ele editou um arquivo local" para "ele está operando dentro de uma esteira com secrets, permissões de repositório, eventos de issue, PR e comentários".

Esse tipo de automação é muito útil. Um comentário que chama um agente para investigar uma falha, propor uma correção ou abrir um PR pode economizar horas. Mas, se o workflow estiver amplo demais, você criou um caminho bonito para abuso.

Algumas perguntas que eu faria antes de colocar agente no CI:

• esse workflow roda em fork externo?
• quais eventos disparam o agente?
• quais permissões o token do GitHub tem?
• quais secrets ficam disponíveis nesse job?
• o agente pode fazer push direto?
• ele pode instalar dependências sem cache confiável?
• ele consegue comentar, abrir PR ou alterar workflow?
• existe log suficiente para entender o que aconteceu?

O detalhe chato é que quase tudo aí parece burocracia até o dia em que não parece mais.

Permissão mínima é uma daquelas práticas que ninguém posta em vídeo curto porque não parece emocionante. Só que é ela que separa "automatizei uma revisão" de "dei um token sensível para um processo que qualquer comentário mal colocado pode acionar".

Uma checklist simples para devs que usam agentes

Se você usa agente local ou pretende colocar um no CI, eu começaria por uma checklist pequena. Não precisa transformar isso em um projeto de segurança de seis meses.

1. Separe tarefas que podem instalar dependência

Instalar pacote deveria ser uma ação mais sensível do que editar um arquivo de componente.

Se a tarefa do agente não precisa instalar nada, bloqueie isso. Se precisa, rode em ambiente descartável e revise package.json, lockfile, scripts de postinstall e mudanças em configuração.

2. Não exponha secrets reais por padrão

Agente raramente precisa de credencial real para trabalhar em código. Na maioria das tarefas, valores falsos resolvem.

Use .env.example, mocks, tokens temporários ou secrets com escopo mínimo. Se uma chave real for indispensável, trate como exceção com prazo curto e trilha de auditoria.

3. Dê escopo de arquivo, não o repo inteiro

Um pedido como "corrija o bug de autenticação" é largo demais.

Melhor:

Edite apenas apps/web/src/auth e packages/session. Não altere workflows, scripts de instalação ou arquivos de infraestrutura. Rode os testes de auth e pare se precisar mudar dependência.

Isso não garante perfeição, mas melhora muito a revisão.

4. Bloqueie rede quando ela não for necessária

Muita tarefa de agente não precisa acessar internet. Precisa ler o repo, alterar arquivos e rodar teste.

Rede aberta por padrão aumenta o estrago possível se algo no ambiente tentar exfiltrar dados. Bloquear rede é uma medida simples e subestimada.

5. Trate mudanças em scripts como área sensível

Alteração em package.json, workflows, hooks, scripts de build, extensões de editor e arquivos de configuração merecem atenção extra.

Não é paranoia. É onde muita automação ganha poder.

6. Faça o agente deixar rastro

Peça resumo do que foi alterado, comandos executados, testes rodados e limitações. Melhor ainda: capture isso automaticamente no ambiente.

Quando algo estranho aparece no diff, log economiza tempo e reduz chute.

O novo básico do setup local

Durante muito tempo, o setup local básico era algo como: instalar Node, configurar Git, clonar repo, preencher .env, rodar pnpm install, subir o app.

Em projetos com agentes, eu acho que o básico começou a incluir mais algumas coisas:

• ambiente descartável para tarefas arriscadas;
• secrets fora do alcance padrão;
• lockfile tratado como artefato crítico;
• scripts de instalação revisados com cuidado;
• permissões explícitas para agente;
• sandbox ou container quando possível;
• CI com tokens de escopo pequeno.

Parece mais trabalho no começo. Mas o contrário também dá trabalho, só que no pior momento possível.

O que me preocupa não é um dev usando agente para acelerar uma tarefa. Isso é normal e, muitas vezes, ótimo.

O que me preocupa é um ambiente onde tudo está disponível, tudo pode rodar, tudo pode ser lido, e a única barreira é a expectativa de que a ferramenta "não vai fazer besteira".

Esse modelo não escala nem para humanos. Para agentes, escala menos ainda.

Use agentes como quem desenha um sistema

A melhor forma de pensar nisso talvez seja parar de tratar o agente como mágica e começar a tratá-lo como parte do sistema.

Ele tem entrada, saída, permissão, dependência, falha, log e superfície de ataque.

Isso não diminui o valor da ferramenta. Na prática, aumenta. Quanto mais previsível e contido o ambiente, mais coragem você tem para delegar tarefas reais.

Minha regra prática hoje é:

antes de perguntar "qual agente resolve isso?", pergunte "em qual ambiente eu aceitaria que isso fosse resolvido?".

Se a resposta for "na minha máquina principal, com meus tokens reais, rede aberta e permissão para instalar qualquer pacote", talvez o problema não seja o agente. Talvez seja o nosso setup.

O npm install seguro em 2026 não termina quando o pacote baixa sem erro. Ele termina quando você sabe quem vai ler aquele código depois, quais permissões essa pessoa ou agente tem, e até onde uma dependência comprometida conseguiria andar.

Esse é o tipo de detalhe chato que evita incidente.

E, sinceramente, é o tipo de detalhe que permite usar IA com mais calma.

Esta semana, me deparei com um artigo no meu feed chamado: “Grief in the AI age” (O Luto na Era da IA), escrito pelo designer Brad Frost. Nele, Brad faz um paralelo entre os cinco estágios do ciclo do luto (negação, raiva, barganha, depressão e aceitação) e a maneira como estamos reagindo à transformação tecnológica (e eu diria até mesmo cultural) que a inteligência artificial generativa trouxe para as nossas vidas.

Eu confesso que, num primeiro momento, o uso do termo “luto” me causou certa estranheza. Afinal, essa é uma palavra que costumamos reservar para o contexto do falecimento de alguém, e, à primeira vista, parece totalmente desconexa quando se fala de IA. Se você abrir qualquer portal de tecnologia agora, as manchetes são sempre sobre novos avanços em modelos, ferramentas revolucionárias, promessas de produtividade e economia de tempo. Todo esse ruído do mercado se alinha muito melhor com o Gartner Hype Cycle, que mapeia a curva de expectativa/frustração de uma nova tecnologia desde o seu nascimento até a sua consolidação.

No papel, esses dois ciclos pertencem a mundos diferentes. O Hype Cycle é corporativo, e o ciclo do luto vive no âmbito puramente emocional e psicológico. No entanto, tudo o que tenho experienciado e observado no mercado de 2023 para cá aponta para uma intersecção entre os dois. A Inteligência Artificial deixou de ser apenas um assistente, e passou a ocupar o espaço de pessoas reais. E não estou falando apenas de substituir postos de trabalho, mas de mexer com o propósito de vida de profissionais, e em alguns casos, influenciar a nossa própria capacidade de raciocínio.

Eu lembro perfeitamente de quando o assunto estourou (pelo menos na minha bolha 🙃 ). Foi logo após o fim da pandemia, quando vi um corte de podcast no YouTube com o Monark mostrando o ChatGPT pela primeira vez. Aquilo parecia mágica, algo realmente revolucionário. Até então, na minha cabeça, inteligência artificial era um conceito restrito ao comportamento de NPCs em videogames ou ao processamento massivo de dados em grandes bancos. De repente, estava ali, na minha tela, ao meu alcance e de graça.

O que se seguiu foi uma euforia generalizada e caótica. O feed de todo mundo foi inundado por vídeos ensinando “como faturar com IA usando apenas o celular”, enquanto uma enxurrada de supostos “especialistas” surgia do nada falando um monte de bobagens. Assistimos a uma corrida armamentista entre as big techs para ver quem lançava a próxima ferramenta, e vimos bilhões de dólares em capital de risco sendo injetados em empresas que mal tinham um protótipo funcional para apresentar.

Hoje, a poeira baixou e o choque de realidade veio forte. Aquelas pessoas que estavam animadas porque achavam que o tão sonhado emprego na área de TI com um salário inicial alto ficaria muito mais fácil ao “colocar a IA para programar”, agora enfrentam uma realidade dura. Muitas foram cortadas em grandes layoffs, outras vivem sob a constante ameaça do desemprego.

Até o hardware foi afetado, com o valor de placas de vídeo e memórias RAM disparando, e tornando a compra de um computador decente algo proibitivo para qualquer brasileiro médio (como se não bastasse o governo brasileiro cobrando imposto atrás de imposto com a desculpa esfarrapada de salvar uma “indústria nacional” que não existe).

Para piorar, as exigências para vagas de desenvolvedor júnior subiram a níveis quase irreais, frustrando quem está iniciando agora e sonhou em entrar na profissão, seja por identificação com a área ou fazendo uma migração de carreira. Na real, tem vagas tão esdrúxulas, que é mais fácil abrir uma startup ou fazer um SaaS e dar certo, do que passar na vaga.

É por isso que a grande dor que enxergo hoje no mercado não é meramente econômica, ela é existencial. Estamos vendo pessoas que estudaram durante anos, abrindo mão de finais de semana e noites de sono para dominar uma função, apenas para ver uma máquina ocupar o seu lugar em questão de segundos.

Desde a infância, fomos ensinados a formar nossa identidade e nosso senso de propósito na vida, com base em nossa profissão. Toda a nossa jornada de aprendizado é cercada por perguntas e afirmações clichês, tipo: “O que você vai ser quando crescer?”, “Qual faculdade vai fazer?”, “Estude bastante para ter um bom futuro”. Quando a máquina simula (e muitas vezes supera) a execução de competências que passamos anos lapidando, o que desmorona não é apenas o emprego, mas a narrativa que construímos na nossa cabeça sobre quem nós somos no mundo.

Outro fato a se considerar é a velocidade das mudanças atropelando o tempo necessário para o nosso aprendizado, e o sentimento de obsolescência chegando antes mesmo que o profissional consiga dominar a versão anterior do framework ou da plataforma.

Pensar que somos a primeira geração a encarar esse problema é um erro. Apesar de na nossa vez estar muito mais acelerado (e também mais caro), em todas as revoluções industriais anteriores isso aconteceu, e a história sempre se repete.

Em todas essas épocas, a sociedade se dividiu exatamente nos mesmos dois extremos emocionais. De um lado, a euforia cega dos entusiastas do progresso celebrando uma “chance de ouro”, prometendo que a automação libertaria o homem do trabalho pesado e criaria uma era de abundância inédita. E do outro, a resistência desesperada dos profissionais que sentem o impacto direto na pele, enxergando naquelas novidades o “fim dos tempos”.

Provavelmente a maior lição que deixamos de aprender com todas as revoluções passadas é que somos péssimos em gerenciar a transição. Nós nos concentramos obsessivamente em fazer a máquina correr mais rápido e processar mais dados, mas falhamos miseravelmente em dar o tempo psicológico que o ser humano precisa para digerir toda essa mudança. Nosso cérebro ainda é analógico, mas a gente sempre finge que esquece...

Se quisermos passar por essa nova era sem nos perdermos de nós mesmos, o primeiro passo é aceitar que estamos, sim, atravessando um processo de luto coletivo, e que sim, a IA não vai desaparecer. Ela veio para ficar, e nada mais será como antes. Mas isso não significa que seja ruim, ou bom. Apenas é... diferente.

A convergência dos ciclos do hype e do luto.

Se você colocar lado a lado um gráfico do Gartner Hype Cycle (aquela curva que as consultorias usam para mapear a adoção de novas tecnologias) e o modelo dos 5 Estágios do Luto (negação, raiva, barganha, depressão e aceitação), desenvolvido pela psiquiatra Elisabeth Kübler-Ross, você vai notar que eles descrevem exatamente a mesma jornada como se fossem dois lados de uma mesma moeda.

Para entender essa minha proposição, precisamos sobrepor essas duas teorias para ver que o paralelo entre elas se faz de forma nítida quando analisamos como reagimos de 2023 até os dias atuais:

Fase 1: A Negação e o Pico de Expectativas Infladas
Quando as ferramentas de IA generativa surgiram, o mercado subiu direto para o topo do Hype. Era a promessa de faturar milhares de dólares com um prompt e a ilusão de que o trabalho seria totalmente automatizado. No lado humano, isso se manifestou em alguns como uma profunda negação da realidade. Uns diziam: “Isso é só um autocompletar, não vai afetar meu emprego”. Outros mergulhavam na fantasia de que a tecnologia resolveria todos os problemas do mundo sem cobrar nenhum preço (ou viajavam de que a skynet se tornaria real 🤖). Ignoramos os sinais de alerta porque a novidade era sedutora demais.

Fase 2: A Raiva e o Vale da Desilusão
O topo do hype é insustentável por um longo período. Eventualmente, a realidade bateu na porta e os primeiros grandes layoffs aconteceram, os erros e alucinações das ferramentas começam a travar processos, gerar gastos desnecessários ou excluir dados importantes nas empresas. O mercado (na minha visão) está despencando direto para o chamado Vale da Desilusão, onde, no Hype Cycle, as empresas não acreditam mais nas promessas da inovação, e se tornam céticas.

Na psicologia, essa queda livre se traduz em um sentimento muito específico: a Raiva. É o momento do boicote, dos textões inflamados no LinkedIn contra as Big Techs, e a revolta de quem percebeu que foi enganado pela promessas dos “especialistas” comprando seus cursos, e agora se sente impotente.

Fase 3: A Barganha e a Ladeira da Iluminação
Quando a raiva cansa e percebemos que o mundo não vai proibir a IA por decreto, e nem ela vai deixar de existir, nós começamos a negociar. Na tecnologia, entramos na “Ladeira da Iluminação”, onde o uso começa a ficar mais realista. No lado humano, ativamos o modo Barganha. É a fase do “Ok, a IA veio para ficar, mas se eu fizer esse curso de especialização eu posso ficar tranquilo e usar ela ao meu favor”, ou “A máquina faz o trabalho bruto, mas o toque final é meu, então estou seguro que não vou ser substituído”. Tentamos criar pequenos acordos entre a realidade e as nossas mentes para manter o controle da situação e salvar o que restou da nossa antiga realidade percebida.

No entanto, há um ponto nessa jornada que os gráficos corporativos costumam ignorar ou tratar de forma superficial, mas que para nós, seres humanos reais, é o momento mais difícil de todos: a transição para a depressão.

Antes de alcançarmos o que a Gartner chama de “Planície da Produtividade” (o ponto onde a tecnologia já se integrou ao dia a dia de forma madura), nós obrigatoriamente colidimos com a depressão. E neste paralelo, ela não deve ser vista como uma fraqueza ou uma doença (a não ser que seja constatada de forma clínica), mas sim como um reconhecimento doloroso da realidade.

É o instante em que a ficha finalmente cai. O profissional olha para o mercado e entende, com absoluta clareza, que o mundo de antes de 2023 não vai voltar. A barganha para, e o cansaço mental se instala. É um luto legítimo pelo futuro que havíamos planejado e que foi cancelado sem o nosso consentimento e de forma abrupta.

E embora esse ponto pareça o fim da linha, ele é, na verdade, o início da recuperação. É nesse reconhecimento doloroso, quando paramos de lutar contra os fatos e abandonamos as ilusões dos sentimentos eufóricos do início, que as maiores transformações começam a germinar.

O luto não é linear

Você deve ter notado que este paralelo que estou fazendo não segue a ordem em que as duas teorias se apresentam, mas isso é proposital. Apesar de ter todas as cinco fases, o luto não age de forma linear, e se manifesta de forma diferente em cada pessoa.

O Gartner Hype Cycle no entanto é linear, pois segue a lógica de mercado. Mas como meu intuito é abordar o aspecto humano, eu o quebrei e fiz o paralelo com as cinco fases do luto, já que este sim é variável e pode ter também oscilações.

Você pode passar uma semana inteira animado, testando novas ferramentas e automatizando processos, apenas para acordar na segunda-feira seguinte tomado por um aperto no peito, questionando se o seu esforço ainda fará sentido daqui a seis meses.

Essa oscilação é normal. O problema real surge quando ficamos cronicamente presos em uma das fases. E o mercado atual construiu três grandes âncoras que nos impedem de avançar:

O medo da obsolescência profissional: A sensação de que a régua está subindo tão rápido que, por mais que você estude à noite, acorde mais cedo ou sacrifique seus finais de semana, você nunca será suficiente.

A perda de identidade: A dor de se perguntar: “Quem sou eu, e que valor eu tenho se a minha maior habilidade agora é feita por uma IA?”

A comparação social: Abrir o feed das redes sociais e ser bombardeado por posts inflados, criando a ilusão de que “todo mundo já domina a IA e está faturando alto, e eu estou ficando para trás”, gerando uma ansiedade social paralisante em quem ainda está tentando entender o básico.

Lidar com todas essas ansiedades e incertezas sem dar uma surtada na cabeça, exige mais do que força de vontade. Podemos usar algumas ferramentas para fazer nossa ancoragem mental:

Journaling (Escrita): Tire todos os pensamentos da cabeça e no papel. Escrever honestamente sobre a sua experiência com as ferramentas (o que funcionou, onde você se sentiu ameaçado, o que achou ridículo e que você pode fazer manualmente) transforma uma ansiedade difusa em dados palpáveis que você pode analisar logicamente. Parece bobo e bem simplório, mas realmente funciona.

Mindfulness e técnicas de grounding: Você precisa forçar o seu cérebro a voltar para o presente para acalmar pensamentos ansiosos com o que pode vir no futuro. Técnicas simples de atenção plena, respiração e desconexão programada são ferramentas de manutenção para a sua saúde mental.

Suporte da comunidade: É a conversa com humanos de verdade. Encontrar um grupo de colegas de profissão num evento para compartilhar sucessos, experiências ou frustrações reais nos lembra de que não estamos sozinhos, e sempre podemos aprender e nos adaptar.

Rituais de desconexão: Crie momentos na sua semana para literalmente se desconectar. Pode ser um dia específico para ler livros físicos, ir na igreja, fazer uma trilha etc.

Amanhã é outro dia...

Discutir se a IA generativa deveria ou não ter sido criada, ou torcer para que o mercado decida retroceder e devolver o mundo ao mesmo estado de 2022, é um gasto de energia mental inútil. A IA deixou de ser uma ferramenta de especialistas para se tornar infraestrutura civilizacional, assim como a energia elétrica e a Internet.

Compreender essa inevitabilidade, no entanto, exige uma distinção crucial que pouca gente faz. Aceitação é completamente diferente de concordância.

Aceitar significa olhar para o mercado atual, reconhecer os layoffs, a mudança nos requisitos de contratação e a automação de processos, e dizer: “Ok, este é o mundo real agora, e eu preciso me adaptar”. Concordar, por outro lado, seria cruzar os braços e aceitar passivamente que a tecnologia dite o nosso valor, destrua a nossa saúde mental ou comoditize a criatividade humana em troca de margens de lucro mais gordas.

Nós não precisamos concordar com a direção caótica que o hype tenta impor, mas precisamos aceitar o fato de que a tecnologia está aqui para podermos agir sobre ela.

A verdadeira virada de chave na nossa cabeça acontece quando paramos de reagir instintivamente aos acontecimentos e passamos a escolher como vamos responder racionalmente a eles. Enfrentar esse momento com integridade psicológica e relevância profissional será uma questão de inteligência emocional.

O mercado não precisa de mais “robôs humanos”, mas sim, de humanos que saibam usar o discernimento, o contexto cultural, a ética e a sensibilidade que máquina nenhuma consegue simular.

A reflexão que deixo no fim desse texto, não é para que você se torne um entusiasta ingênuo que abraça cada nova ferramenta com otimismo cego, e nem um resistente amargurado que assiste ao mundo mudar sem fazer nada. Mas sim, o compromisso de continuar aprendendo, manter o seu espaço de pensamento crítico e de acolher as suas próprias vulnerabilidades ao longo do caminho.

O futuro continua sendo um território aberto cheio de possibilidades e ele é algo que nós ainda construímos, um passo de cada vez.

Quando começamos a estudar bancos NoSQL, principalmente DynamoDB, uma coisa fica bem clara:

você não modela apenas os dados, você modela os acessos aos dados.

Em bancos relacionais, muitas vezes pensamos assim:

SELECT * FROM orders WHERE status = 'PENDING';SELECT * FROM orders WHERE customer_id = 123;SELECT * FROM orders WHERE created_at >= '2026-01-01';

Se precisar consultar por outro campo, criamos um índice, fazemos um join, filtramos, ordenamos e seguimos o jogo.

Mas em bancos como DynamoDB, a conversa muda um pouco.

Você geralmente acessa os dados pela chave primária da tabela. E se amanhã você precisar consultar a mesma tabela por outro campo?

É aí que entra o GSI, ou Global Secondary Index.

O que é um GSI?

GSI significa Global Secondary Index

De forma simples:

Um GSI permite consultar uma tabela usando uma chave diferente da chave primária original.

Segundo a própria documentação da AWS, um índice secundário permite consultar dados usando uma chave alternativa, além da chave primária da tabela. No caso do GSI, essa chave pode ter uma partition key e, opcionalmente, uma sort key diferentes da tabela principal.

Vamos imaginar uma tabela de pedidos:

Table: OrdersPK: orderIdAttributes:- orderId- customerId- status- createdAt- total

Com essa estrutura, buscar um pedido pelo orderId é simples:

orderId = "order_123"

Mas e se eu quiser buscar todos os pedidos de um cliente?

customerId = "customer_456"

A tabela principal não foi modelada para isso.

Então uma opção seria criar um GSI:

GSI: OrdersByCustomerPK: customerIdSK: createdAt

Agora eu consigo consultar os pedidos por cliente e ainda ordenar pela data de criação.

Uma forma simples de visualizar

Pense na tabela principal como uma gaveta organizada por número do pedido:

Orders TablePK: orderIdorder_001 -> customer_1 -> PENDINGorder_002 -> customer_2 -> PAIDorder_003 -> customer_1 -> PAID

Ela é ótima quando você sabe o orderId.

Mas se você quiser buscar por customerId, teria que varrer tudo.

Com um GSI, é como criar uma segunda forma de organização:

GSI: OrdersByCustomerPK: customerIdSK: createdAtcustomer_1 -> order_001customer_1 -> order_003customer_2 -> order_002

O dado continua na tabela principal, mas agora existe um índice preparado para outro padrão de consulta.

GSI não é cópia completa da tabela

Um ponto importante: o GSI não precisa carregar todos os atributos da tabela.

Você escolhe quais atributos serão projetados no índice.

Por exemplo:

GSI: OrdersByStatusPK: statusSK: createdAtProjected attributes:- orderId- customerId- total

Isso significa que, ao consultar esse índice, você pode receber apenas os campos projetados.

Se você projetar atributos demais, o índice fica maior e mais caro.

Se projetar atributos de menos, talvez você precise fazer uma segunda consulta na tabela principal para buscar o restante dos dados.

Esse é um trade-off bem importante.

Exemplo prático

Imagine um sistema de pedidos.

A tabela principal foi criada assim:

PK: orderId

Esse acesso resolve bem o caso:

Buscar pedido por ID

Mas o produto começa a crescer e surgem novos requisitos:

1. Buscar pedidos por cliente
2. Buscar pedidos por status
3. Buscar pedidos por data
4. Listar pedidos pendentes mais recentes

Se você tentar resolver tudo apenas com a chave primária original, provavelmente vai cair em scans.

E scan em tabela grande é aquele tipo de coisa que começa inocente e depois vira uma dor de cabeça.

Uma modelagem possível seria:

Table: OrdersPK: orderId

GSI 1: OrdersByCustomerPK: customerIdSK: createdAt

GSI 2: OrdersByStatusPK: statusSK: createdAt

Agora você tem diferentes formas de consultar a mesma entidade.

Por que o nome é "Global"?

O termo global existe porque o índice pode consultar dados da tabela inteira, atravessando todas as partições.

Isso é diferente de um LSI, Local Secondary Index, que fica limitado à mesma partition key da tabela principal.

No GSI, a chave do índice pode ser completamente diferente da chave da tabela.

Exemplo:

Tabela principal:PK: orderId

GSI:PK: customerIdSK: createdAt

Ou seja, o índice não está preso ao mesmo partition key da tabela original.

O lado bom do GSI

GSI é muito útil quando você tem múltiplos padrões de acesso.

Ele ajuda em casos como:

• Buscar usuários por email
• Buscar pedidos por cliente
• Buscar transações por status
• Buscar produtos por categoria
• Buscar logs por tenant
• Buscar mensagens por conversa
• Buscar eventos por data

Exemplo:

Users TablePK: userId

Mas no login você precisa buscar por email:

GSI: UsersByEmailPK: email

Sem esse GSI, você teria que fazer scan para encontrar o usuário pelo email, o que seria péssimo conforme a tabela cresce.

O lado perigoso do GSI

Apesar de parecer uma solução mágica, GSI tem custo.

Cada vez que você escreve na tabela principal, o DynamoDB também precisa atualizar os GSIs afetados.

Então, se você tem uma tabela com muitos writes e muitos GSIs, cada escrita pode ficar mais cara.

Exemplo:

Table write:- grava na tabela principal- atualiza GSI por customerId- atualiza GSI por status- atualiza GSI por category

Ou seja, mais índices significam mais flexibilidade de leitura, mas também mais custo e complexidade na escrita.

A própria AWS explica que consultas em um GSI consomem capacidade do índice, não da tabela principal, e que alterações na tabela também podem consumir capacidade do índice quando ele precisa ser atualizado.

GSI tem consistência eventual

Esse é um ponto muito importante.

Consultas em Global Secondary Index no DynamoDB suportam apenas eventual consistency.

Na prática, isso significa que você pode gravar um item na tabela principal e, por alguns instantes, ele ainda não aparecer no GSI.

Exemplo:

1. Crio um novo pedido com status = "PENDING"2. A escrita na tabela principal retorna sucesso3. Consulto o GSI OrdersByStatus imediatamente4. Pode ser que o pedido ainda não apareça naquele exato momento5. Depois de um pequeno intervalo, o índice converge

Isso não significa que o banco está errado.

Significa que o índice é atualizado de forma assíncrona.

Por isso, GSI é ótimo para muitos casos, mas talvez não seja ideal quando você precisa de leitura fortemente consistente logo após uma escrita.

Quando usar GSI?

Eu usaria GSI quando existe um padrão de acesso claro que não é atendido pela chave primária da tabela.

Alguns exemplos:

Buscar usuário por emailBuscar pedidos por clienteListar pagamentos por statusConsultar produtos por categoriaBuscar eventos por organizaçãoListar notificações por usuário

O ponto principal é:

crie um GSI para responder uma pergunta específica do seu sistema.

Não crie GSI só porque "talvez um dia eu precise filtrar por esse campo".

Quando evitar GSI?

Eu evitaria GSI quando:

• O acesso é raro
• O volume de escrita é muito alto
• O índice teria baixa cardinalidade
• O campo indexado muda toda hora
• O padrão de consulta ainda não está claro
• Um scan ocasional em uma tabela pequena já resolve
• A aplicação precisa de consistência forte naquele acesso

Um exemplo perigoso seria criar um GSI com partition key status:

PK: status

Se os status forem apenas:

PENDINGPAIDCANCELED

Você pode acabar concentrando muitos itens na mesma chave, principalmente se a maioria dos pedidos estiver em PENDING.

Isso pode gerar hot partition.

Nesse caso, talvez você precise pensar em uma chave mais bem distribuída, como:

PK: status#dateSK: createdAt

Ou outra estratégia baseada no padrão real de acesso.

GSI resolve problema de modelagem, não falta de modelagem

Uma armadilha comum é pensar:

"Vou criar vários GSIs e depois vejo como consultar."

Isso é perigoso.

Em DynamoDB, o ideal é começar pelos access patterns.

Antes de criar a tabela, pergunte:

Como minha aplicação vai buscar esses dados?Quais telas precisam desses dados?Quais filtros são obrigatórios?Qual ordenação eu preciso?Qual volume de leitura e escrita espero?Preciso de consistência forte?

Depois disso, você decide a chave da tabela e os GSIs.

GSI não deve ser tratado como gambiarra para consulta mal pensada.

Ele deve ser parte da modelagem.

Exemplo mais próximo do mundo real

Imagine um SaaS multi-tenant.

Você tem uma tabela de produtos:

ProductsPK: productIdAttributes:- productId- companyId- categoryId- name- status- stock- createdAt

Buscar produto por ID é fácil.

Mas em uma tela de dashboard, talvez você precise listar os produtos de uma empresa:

GSI: ProductsByCompanyPK: companyIdSK: createdAt

Em outra tela, talvez precise listar produtos por categoria dentro da empresa:

GSI: ProductsByCompanyAndCategoryPK: companyId#categoryIdSK: name

E talvez no dashboard você precise listar produtos com estoque baixo.

Nesse caso, criar um GSI pode ou não ser a melhor opção. Depende do volume, da frequência de consulta e da forma como o alerta será calculado.

O importante é entender que cada GSI nasce para responder uma pergunta:

Quais produtos pertencem a essa empresa?Quais produtos dessa categoria pertencem a essa empresa?Quais produtos estão ativos?Quais produtos precisam aparecer no dashboard?

Resumo mental

Para mim, o jeito mais simples de pensar em GSI é:

A tabela principal responde um caminho de busca.
O GSI cria outro caminho de busca.

Mas esse novo caminho tem custo.

Ele ocupa espaço, consome capacidade, precisa ser atualizado e trabalha com consistência eventual.

Então, GSI é uma ferramenta poderosa, mas precisa ser usada com intenção.

Conclusão

Global Secondary Index é um dos conceitos mais importantes para modelar bem tabelas no DynamoDB.

Ele permite consultar os mesmos dados por diferentes chaves, sem depender de scans caros e ineficientes.

Mas ele também traz trade-offs:

• mais custo
• mais complexidade
• consistência eventual
• risco de hot partition
• necessidade de pensar melhor nos access patterns

No fim, GSI não é só um "índice secundário".

Ele é uma forma de materializar um novo padrão de acesso dentro do seu banco.

E em bancos como DynamoDB, entender os padrões de acesso antes de modelar os dados faz toda a diferença.

Passei o dia todo procrastinando e também ocupado com outros afazeres, mas não queria deixar esse estudo morrer só no meu caderno. Então estou postando agora uma parte do que estudei hoje sobre GSI (Global Secondary Index). Talvez não esteja perfeito, mas faz parte do processo: estudar, organizar as ideias e compartilhar.

Como o algoritmo de recompensa diária realmente funciona

A recompensa diária não é aleatória nem linear. Ela é calculada com base em três fatores:

P — Prestígio
Reflete a média das qualificações dos seus conteúdos mais recentes. Quanto mais votos positivos você recebe, maior o P.

I — Idade do conteúdo mais recente
O sistema pega sua publicação mais recente (post ou comentário) e divide a idade dela por uma semana. Se você publicou há menos de uma semana, I = 1. Se ficou mais tempo sem publicar, I cai e penaliza sua recompensa.

Q — Saldo de TabCoins acumulado
Seu saldo é dividido por 20 e o resultado é elevado ao quadrado. Quanto mais TabCoins você acumula sem gastar, maior o Q — e ele é subtraído do cálculo. Ou seja: guardar moedas sem usá-las diminui sua recompensa diária.

A recompensa final é aproximadamente: P × I × (1 - Q)

O que isso muda na prática

A estratégia ótima não é acumular — é circular:

1. Publique com frequência menor que 7 dias (mesmo que seja um comentário relevante em algum post)
2. Use suas TabCoins para qualificar conteúdos dos outros — cada qualificação custa 2 TabCoins e te dá 1 TabCash
3. Mantenha seu saldo abaixo de 20 para que Q fique próximo de zero

Fazendo isso, sua recompensa diária depende quase só da qualidade dos seus conteúdos, que é o único fator que você realmente controla.

Outros pontos que a documentação não destaca bem

Ao criar um post, o sistema olha a média de TabCoins dos seus conteúdos mais recentes para decidir quantos você ganha. Usuário novo com histórico neutro ganha menos do que usuário com histórico positivo.

Ao deletar um conteúdo, o sistema cobra de volta:

• Se o conteúdo estava positivo → você devolve tudo que ganhou (publicação + votos)
• Se estava zerado ou negativo → você devolve apenas o que ganhou ao publicar

Permissão para publicar pode ser suspensa se você tiver muitas publicações classificadas como irrelevantes. O sistema te avisa para excluir antes de postar de novo.

O horário importa

O corte da recompensa diária é às 21h (horário de Brasília). Você tem da 21h de um dia até as 21h do dia seguinte para registrar seu acesso e garantir a recompensa.

Resumo prático

As fontes disso tudo estão nos PRs #1508 e #1509 e na issue #1381 — vale a pena ler se quiser os detalhes completos da implementação.

No trabalho começamos a nos preparar para certificação ISO27001 e me deparei com um dilema: Redigir dados sensíveis em vários pontos da aplicação usando helpers e replicando para outros projetos OU usar/aplicar já táticas mais robustas e seguras existentes no ecossistema .NET?
Até então não encontrei nenhuma solução pronta que fosse simples de configurar e que entendesse o contexto brasileiro (CPF, CNPJ, CNH, Placa Mercosul, etc.) e que principalmente tivesse uma documentação legal.

Lembrei em algum canto do meu cerébro que a Microsoft dispunha de um nuget de compliance, mas de novo não queria ficar repetindo código em cada projeto pra fazer anonimização dos dados, então resolvi criar o EZ.Redact.Lgpd e seus nugets derivados.

O que é o EZ.Redact.Lgpd?

É um conjunto de pacotes .NET construído sobre o Microsoft.Extensions.Compliance.Redaction que cobre os principais pontos onde dados sensíveis podem vazar numa aplicação:

• EZ.Redact.Lgpd.Core — base de redação com suporte a masking e HMAC, zero allocation com Span<char>, cobrindo CPF, CNPJ, CNH, Email, Telefone, Placa Mercosul, PIX, entre outros dados brasileiros
• EZ.Redact.Lgpd.Json — redação na serialização JSON com suporte a System.Text.Json e Newtonsoft.Json
• EZ.Redact.Lgpd.Xml — redação na serialização XML com suporte a XmlSerializer e DataContractSerializer
• EZ.Redact.Lgpd.EntityFramework — redação opt-in na leitura de dados via EF Core, ideal para aplicações MAUI, WinForms e SignalR
• EZ.Redact.Lgpd.MongoDb — redação opt-in na leitura de documentos no MongoDB

Dois modos de redação

O Core suporta dois modos configuráveis por tipo de dado:

• Masking — preserva parte do dado para facilitar debugging: 123.***.***-01
• HMAC — hash determinístico irreversível, útil para logs de auditoria onde você quer correlacionar sem expor o dado original: 1:8fLm3q...==

Uso nos logs

Com o Core e o ILogger da Microsoft, basta decorar os parâmetros com os atributos de taxonomia:

public static partial class TesteLog{    [LoggerMessage(Message = "Cpf anonimizado: {Cpf}")]    public static partial void LogAcesso(this ILogger logger, [CPFData] string cpf);}

E no seu ILogger (funciona também com ILogger<\T>)

_logger.LogInformation("Cpf não anonimizado: {Cpf}", "111.111.111-11");_logger.LogAcesso("111.111.111-11");

O dado já sai redigido automaticamente no log, independente do provider (console, Application Insights, etc.).
O Que inclusive já vai até redigido para o OpenTelemetry ou outra solução de análise de log!

info: Program[0]      Cpf não anonimizado: 111.111.111-11 11111111111info: Program[158633788]      Cpf anonimizado: 111.***.***-11

A Lista de atributos suportados que cobrem os principais dados sensíveis você encontra no repositório do EZ.Redact.Lgpd.Core.

Links

• GitHub: https://github.com/ez-dotnet
• NuGet: https://www.nuget.org/packages/EZ.Redact.Lgpd.Core

Também tenho um outro projeto de source generator pra registro de minimal api usando um estilo controller usando atributos

• NuGet: https://www.nuget.org/packages/EZ.MinimalApi.Generator

Feedback é muito bem-vindo, especialmente se você tem casos de uso que os pacotes ainda não cobrem!