Olá pessoal! Quero compartilhar um projeto pessoal: o Beezu.

Ele começou como um projetinho de cobaia apenas para eu experimentar coisas novas (tecnologias, produtos, processos, etc). Quando os agentes de codificação se popularizaram,
o desenvolvimento acelerou muito, e o projeto chegou a um ponto em que já é um produto utilizável. Agora quero descobrir se ele faz sentido para mais alguém além de mim.

O problema

Imagine que você está planejando férias em família e manda em alguns grupos do WhatsApp:

"Dicas de hotéis/pousadas no litoral de Alagoas para as férias de junho?"

O que costuma acontecer:

1. As respostas não respondem o que você precisa saber. Algumas vêm só com o nome da pousada. Outras vêm com um relato que pode ou não ter algo útil. E quase toda resposta puxa novas
perguntas: "quanto era a diária?", "e o café da manhã?", "tinha atividade para crianças?", "o quarto era espaçoso?". Toda recomendação esconde um monte de detalhes, e se quem
pergunta não diz o que importa para si, ninguém garante que as respostas vão cobrir isso.

2. Outras pessoas precisam garimpar tudo de novo, e cada uma pode estar procurando uma coisa levemente diferente. Quem mais se interessar pelo assunto precisa ler a conversa inteira,
ignorar os assuntos paralelos e organizar as informações compartilhadas (seja de cabeça, numa planilha, num bloco de notas, ...). Como cada pessoa está fazendo a mesma pesquisa mas com
objetivos um pouco diferentes:

uma quer a melhor pousada pelo menor preço;
outra quer um café da manhã excelente;
outra não liga para preço, desde que seja pé na areia.

3. Opiniões envelhecem. Uma pousada muito bem avaliada há 5 anos pode estar mediana ou até decadente hoje, e nesse meio tempo surgiram outras opções. Quem está planejando uma viagem
quer opiniões recentes (digamos, dos últimos 12 meses, talvez menos...). E às vezes interessa justamente o passado: o dono de uma pousada que perdeu clientes pode querer descobrir
quando e por que a satisfação começou a cair.

4. O contexto se perde. Um esclarecimento que alguém mandou três dias depois fica perdido no meio da conversa. E quando a pergunta surge de novo meses depois, você já não lembra quem
respondeu, nem onde leu aquela dica.

5. Todo esse esforço morre ali. Se um amigo seu, que não estava no grupo, também for para Alagoas, ele vai ter que começar do zero: fazer a pergunta, espalhar entre os contatos,
organizar as respostas, pedir detalhes e só então decidir o que é melhor para ele.

A solução: Beezu

O Beezu é uma mistura de plataforma de avaliações, fórum e rede social. Cada tópico funciona como uma pequena comunidade de pessoas com interesses e experiências em comum.

Voltando ao exemplo das férias, no Beezu aquela pergunta viraria um tópico assim:

Tópico: Pousadas e hotéis no litoral de Alagoas
Alternativas: Pousada A, Pousada B, Hotel C, ...
Critérios: Custo-benefício da diária · Café da manhã · Atividades para crianças · Conforto do quarto · Pé na areia

E é assim que ele resolve cada um daqueles problemas:

Problema	Como o Beezu resolve
Respostas incompletas	Quem cria o tópico define os critérios, e quem opina avalia cada critério separadamente (só os que conhecer, não precisa ser todos)
Cada pessoa procura uma coisa	Cada visitante ajusta os pesos dos critérios e vê um ranking personalizado. Quem liga para preço vê um ranking, quem liga para café da manhã vê outro
Opiniões envelhecem	Dá para filtrar as opiniões por período: só os últimos 12 meses, ou um intervalo específico do passado
O contexto se perde	Todo o histórico fica no tópico, aberto para consulta. Qualquer pessoa pode "acordar" um tópico antigo com uma opinião atualizada
O esforço morre ali	O tópico é público e fica lá para o próximo que tiver a mesma dúvida

E mais:

A comunidade pode sugerir novas alternativas e critérios. O Beezu avisa todo mundo que já participou do tópico, para que possam opinar sobre a novidade.
Também existem tópicos sem alternativas, para avaliar uma coisa só (ex.: "O que você achou do novo plano de mobilidade da sua cidade?", com critérios como impacto no trânsito, custo e prazo de implantação).
Ao criar a conta, você escolhe postar com nome e foto reais ou de forma anônima, com nome e avatar aleatórios (no estilo do Reddit).

Onde ele é mais útil

Quando você quer coletar opiniões de forma estruturada e a escolha da "melhor" opção depende de quem está escolhendo. Alguns exemplos:

Modelos de IA para o dia a dia: Claude, Gemini, ChatGPT, Grok... avaliando qualidade das respostas, velocidade, custo e privacidade dos dados.
Melhores cidades para morar: João Pessoa, Salvador, Belo Horizonte, Curitiba... avaliando custo de vida, segurança, transporte público e saúde.
Linguagens para o primeiro emprego: Java, Python, JavaScript, Go... avaliando vagas disponíveis, curva de aprendizado e salário inicial.
Carros elétricos e híbridos à venda no Brasil: BYD, GWM, Geely... avaliando preço, rede de assistência, disponibilidade de peças e valor do seguro.

Como foi feito

O primeiro commit é de julho de 2024. Hoje são mais de 3.500 commits, e cerca de 60% deles saíram de março de 2026 para cá, quando passei a trabalhar com agentes
de codificação (o Claude Code, no meu caso) como parte do dia a dia.

A arquitetura

flowchart LR
    U([Navegador]) --> CF

    subgraph CF[Cloudflare]
        PAGES[Frontend React<br/>Cloudflare Pages]
        R2[(R2<br/>selfies cifradas)]
    end

    U --> ING

    subgraph K8S[Cluster k3s na Hetzner · mTLS entre serviços com Linkerd]
        ING[ingress-nginx] --> APP[beezu-server<br/>Java 25 + Spring Boot]
        APP --> PG[(PostgreSQL<br/>CloudNativePG)]
        APP -. assíncrono .-> LR[language-resolver<br/>Java · Lingua]
        APP -. assíncrono .-> LLM[llm-gateway<br/>Java · Spring Boot 4]
        APP -. assíncrono .-> AGE[age-assesser<br/>Python · FastAPI · DeepFace]
        VAULT[Vault + External Secrets] -.-> APP
    end

    LLM --> OR[OpenRouter]
    AGE --> R2

Backend: Java 25 + Spring Boot 3.5, Spring Security com login via Google e GitHub (OAuth2) e JWT, PostgreSQL com Flyway, notificações em tempo real via
WebSocket (STOMP) e Web Push.
Frontend: React 19 + Vite + TypeScript + Tailwind, publicado no Cloudflare Pages. O design nasceu como protótipo no Figma, que virou o ponto de partida do
código.
Infra: um cluster k3s pequeno na Hetzner provisionado com Terraform e orquestrado com Helmfile. Postgres gerenciado pelo
CloudNativePG, segredos no Vault, certificados com cert-manager, mTLS entre os serviços com Linkerd e observabilidade no New Relic.

Microsserviços

O Beezu começou (e em boa parte continua) como um monólito. Só saiu dele o que tinha um motivo concreto para sair:

language-resolver: detecta o idioma dos tópicos. Os modelos de n-gramas da biblioteca Lingua consomem bastante memória, e isso seria multiplicado por cada
réplica do servidor principal. Assim, a escolha natural foi mover essa funcionalidade para um serviço dedicado.
llm-gateway: sugere tags para os tópicos usando LLMs via OpenRouter, com uma cadeia de modelos de fallback e validação da resposta (inclusive contra prompt
injection pelo texto do tópico).
age-assesser: estima se quem cria um tópico +18 é maior de idade, a partir de selfies. É o único serviço em Python, porque as bibliotecas de estimativa
de idade (DeepFace) não têm equivalente maduro na JVM. As selfies são cifradas ainda no navegador e só esse serviço tem a chave para abri-las. Depois de
processadas, ele mesmo as apaga. Essa funcionalidade foi criada devido o recente ECA Digital.

Os três seguem o mesmo padrão: o servidor principal registra o pedido numa tabela (outbox), e um agendador envia e reenvia até dar certo. Cada serviço se
protege com um limitador adaptativo (AIMD): quando a latência sobe, ele responde 429 com Retry-After, e para o servidor isso não é erro, é só um "tenta de
novo daqui a pouco". Assim, se um serviço estiver lento ou fora do ar, o usuário não percebe: o tópico é criado do mesmo jeito, e o idioma e as tags chegam
alguns segundos depois.

sequenceDiagram
    participant U as Usuário
    participant S as beezu-server
    participant DB as PostgreSQL
    participant M as microsserviço
    U->>S: cria tópico
    S->>DB: salva tópico + pedido na outbox
    S-->>U: 201 Created (sem esperar)
    loop agendador
        S->>M: processa pedido
        alt saturado
            M-->>S: 429 + Retry-After
            Note over S: reagenda, não é erro
        else ok
            M-->>S: resultado
            S->>DB: atualiza tópico, remove da outbox
        end
    end

Overengineering? Com certeza! Mas lembre-se que isso tudo começou (e ainda é, de certa forma) um projetinho para estudos e diversão. Jamais faria algo tão exagerado assim pensando em mercado, sem saber se teria usuários e sem noção de se o investimento se pagaria...

Como trabalho com os agentes

O que fez diferença não foi "pedir para a IA programar", mas montar um processo em volta dela:

flowchart LR
    I[Issue no GitHub] --> P[Plano em fases<br/>salvo no repositório]
    P --> F[Agente implementa<br/>UMA fase]
    F --> T[Testes unitários,<br/>integração e E2E]
    T -->|falhou| F
    T --> R{Eu reviso}
    R -->|ajustes| F
    R -->|ok| C[Commit + PR para dev]
    C --> CI[CI] --> D[Release e deploy]
    D -.próxima fase.-> F

Planos em fases pequenas. Toda tarefa maior vira um plano salvo no repositório, dividido em fases que produzem poucas mudanças cada. O agente implementa
uma fase por vez e atualiza o plano com o que foi feito. Isso deixa a revisão viável e permite retomar o trabalho em outra sessão sem perder o contexto.
Nada vai para commit sem eu ler. O agente nunca faz commit sozinho depois de implementar uma fase.
Regras escritas para cada erro repetido. Quando o agente erra a mesma coisa duas vezes, isso vira uma regra no repositório (convenções de teste,
de controllers, de i18n, do design system...).
Skills para tarefas recorrentes: rodar um teste específico, fazer o build completo corrigindo testes quebrados, rebalancear grupos de E2E e até criar
um microsserviço novo do zero.
Testes como rede de segurança. São mais de 2.000 casos de teste, incluindo testes E2E com Selenide no desktop e no mobile. Com código sendo
gerado nessa velocidade, são eles que me deixam dormir tranquilo.
Várias propostas visuais antes de mexer na interface. Para qualquer mudança de UI, o agente gera de 3 a 5 propostas diferentes e eu escolho uma antes
de implementar.

O que eu não esperava

O gargalo mudou de lugar. Com os agentes, escrever código deixou de ser a parte lenta. A parte lenta virou revisar o que foi feito e esperar o CI. A
conta do GitHub Actions mostrou isso bem: o consumo foi de cerca de 450 minutos em janeiro para mais de 6.400 em julho, bem acima da franquia gratuita. A
saída foi criar runners sob demanda na própria Hetzner: uma máquina sobe para rodar a suíte de testes e é destruída no fim.

A própria IA ajuda a auditar o que a IA escreveu. Rodei o Strix, uma ferramenta de pentest com agentes de IA, contra o Beezu. Ele encontrou problemas
reais, como uma conexão WebSocket que aceitava um tipo de token que não deveria. Para cada achado, primeiro escrevi um teste que reproduzia o problema, vi o
teste falhar e só depois corrigi.

Me ajuda?

A maioria dos tópicos que existem hoje fui eu que criei, para testes e demonstrações. O Beezu só fica útil com gente de verdade opinando, e é aí que entra você.

Se tiver uns minutos, eu adoraria se você:

Opinasse no tópico sobre o próprio Beezu: https://beezu.io/topics/01a15bca-4e2d-70cb-a0ab-59a136687481 (é a forma mais rápida de experimentar o produto e me dar feedback ao mesmo tempo)
Criasse um tópico sobre algo que você realmente queira comparar, e mandasse para alguns amigos
Me contasse nos comentários: o que te faria usar o Beezu? E o que te faz não querer usar?

Qualquer feedback serve, inclusive "não entendi para que serve". Obrigado!

3.500 commits, 4 serviços e um cluster k3s: meu projeto pessoal virou produto e agora preciso de usuários