Dev Crítico 🦀

👨‍💻 Product Engineer | Dev com 17+ anos de exp 🧠 Visão crítica sobre Desenvolvimento de Software e Produtos escaláveis.

[Dev Crítico 🦀 @DevCritico]

Vou começar a criar conteúdo lá, em breve.

Começo a postar agora em Maio, não vai ser apenas sobre tech, vai ter meu dia a dia:

Tech, games, treinos, outfits, cartinha de Pokémon, role eletrônico, etc.

Quem quiser colar, prometo opinião polêmica semanalmente.

[Dev Crítico 🦀 @DevCritico]

@ramosbueno9150 Só imbecil está reclamando

[Dev Crítico 🦀 @DevCritico]

Pra galera que defende o GRANDE ROLLBACK:

Vocês estão se vendo codando sem agente, é isso mesmo? KKKKK

[Dev Crítico 🦀 @DevCritico]

O Atreus é um inútil, na moral, até aquela “caixa” que apareceu no gameplay parece mais importante que ele.

[Elyel 🎮Ω @elyelgow]

Opinião:

Eu prefiro mil vezes um God of War com a Faye do que com o Atreus.

A Faye tem uma história incrível e é uma guerreira foda. Já o Atreus é insuportável e chato.

Um God Of War com o Atreus seria uma tragédia.

[Augusto Galego @RealGalego]

lancei o curso de system design.
1 ano de trabalho, 17 módulos, +80 aulas.
é o material mais completo que já fiz.
se vc é pleno, sênior ou junior com xp, provavelmente vai gostar.
link nas replies.

[Dev Crítico 🦀 @DevCritico]

Se você acha que um jogo está querendo lacrar só porque tem uma mulher como personagem principal, você só é um imbecil mesmo.

Isso daí eu vou jogar muito.

[Otavio @otavioopc]

Achei maneiro, mas vão reclamar de lacre, certeza kkkk

[Dev Crítico 🦀 @DevCritico]

Agora tudo faz sentido kkkkk

[Programmer Humor @PR0GRAMMERHUM0R]

aiCompaniesRightNow

[Dev Crítico 🦀 @DevCritico]

Vai lançar com o PS6, não vai ter jeito né?

😌

[Chef Dan Galhardo @chefdangalhardo]

IRMÃO.

OLHA O GOD OF WAR PRO PS5.

PUTA QUE PARIU!!!!!

[Dev Crítico 🦀 @DevCritico]

Declaração de voto em dinossauros.

[el hombre pulpo @coproduto]

O que, se uma pessoa faz, faz você imediatamente concluir que essa pessoa é burra?

[Dev Crítico 🦀 @DevCritico]

E o Claudinho, gerando lucro pra sua empresa aí?

[Sibelius Seraphini @sseraphini]

A bad software engineer used to get stuck to solve a problem

Now it just generate a bad solution with AI

[Dev Crítico 🦀 @DevCritico]

@_feltrix KKKKKKKKKKKKK

[Dev Crítico 🦀 @DevCritico]

82% do custo em tokens nunca impacta o produto de fato, isso é, não alça o usuário final.

Por enquanto, o que eu analiso é que vivemos uma fase de adaptação e evolução, é só o começo, não tem rollback.

[Product Guru’s @product_gurus]

Os dados do gráfico (18% do gasto chega a features estáveis em produção e 44% vai para correção de bugs) são de uma análise interna da @EntelligenceAI em mais de 2.400 empresas que usam a plataforma.

[Dev Crítico 🦀 @DevCritico]

Isso aqui vai ser absurdo kkkkk

[Margaret Meloni🇦🇷🇧🇷🌷 @margaretmelonii]

🚨 VOCÊS TÊM NOÇÃO DO QUE A CD PROJEKT RED ACABOU DE FAZER COM THE WITCHER 3?

> Quase 11 anos depois, o medalhão voltou a vibrar.

> A CDPR anunciou oficialmente The Witcher 3: Wild Hunt - Songs of the Past, a terceira expansão do jogo e a primeira desde Blood and Wine, lá em 2016.

> E o mais absurdo: o projeto está sendo desenvolvido junto da Fool's Theory, estúdio formado por veteranos da própria franquia.

- Lançamento previsto para 2027
- PC, PS5 e Xbox Series X|S
- Mais detalhes só no verão de 2026
- CDPR já começou a atualizar os requisitos do jogo base

> Os rumores apontam que Songs of the Past vai funcionar como ponte narrativa para The Witcher 4, com Ciri como protagonista.

> E o timing? Bem, não foi tão calculado assim.

> O anúncio veio antes do planejado porque os dados da expansão vazaram no próprio RED Launcher.

> A CDPR percebeu, e simplesmente adiantou o anúncio.

> Sem teaser misterioso.

> Sem contagem regressiva.

> Sem enrolação corporativa.

> Um jogo com mais de 60 milhões de cópias vendidas voltou a dominar a indústria mais uma vez.

> Geralt literalmente se recusando a morrer.

[Dev Crítico 🦀 @DevCritico]

Troubleshooting - MySQL

Problemas do meu dia a dia: a quantidade de registos scaneados em uma ÚNICA query pode ser a causa dos seus problemas de performance.

Uma única query que faz scan em milhões de registros nem sempre aparece como a “culpada óbvia”. Mesmo executando apenas uma vez e respondendo relativamente rápido, ela pode expulsar páginas frequentemente acessadas do buffer pool, aumentando leituras em disco para operações subsequentes e degradando a performance do banco como um todo. O problema nem sempre está apenas em queries travadas, múltiplas execuções ou consumo de CPU: volume de dados lidos também importa.

Ter monitoramento em quantidade de registos scaneados em uma única query é uma saída inteligente para entender que há algo errado.

[Augusto Galego @RealGalego]

Ninguém nasce bom em nada, o único caminho pra virar bom é sendo ruim e cringe por muito tempo.

Você precisa desprezar profundamente haters e ativamente apreciar quando eles ficam irritados.

[Dev Crítico 🦀 @DevCritico]

@z4nder212 Me refiro a escalabilidade técnica mesmo, mas você me deu uma ideia, poderia ter parcerias para dar uma consultoria mais completa 🤔

[Dev Crítico 🦀 @DevCritico]

Cogitando fortemente oferecer serviços para escalar ideias vibe coded.

Criou algo e agora precisa escalar e não sabe como? Eu posso te ajudar.

Kkkkkkk

[Dev Crítico 🦀 @DevCritico]

Consumir menos token NÃO deve ser O MOTIVO para adotar uma stack.

Eu não estou dizendo que isso não importa, mas que isso não é o único parâmetro pra você escolher qual lang usar em seu projeto.

Se seus requisitos principais são performance e segurança, Rust pode ser o mais indicado, mesmo consumindo 60% a mais de token quando comparado com Ruby + Rails.

[DHH @dhh]

Agents don't need types. They're perfectly capable of pulling off incredible refactorings without. Give them a linter and a test suite, and you have all you need. Token efficiency is where it's at.

[The Pragmatic Engineer @Pragmatic_Eng]

In Rust, error handling is opt-out, not opt-in. Alice Ryhl (Rust for Android at Google, Rust language advisor & Tokio maintainer) explains:

“The other thing I think is quite good is error handling. So on one hand, Rust doesn't really use exceptions, so it actually returns the error as a value.

So you return a value that's, using an enum, either the result or the error. And the way this is done is that there's an operator `?` - so you write: my_function and then a question mark at the end - which means if this function fails, return the error.

So it's really easy to handle errors but it's not serial characters like it is with exceptions, so it's explicit. On the other hand, if you forget to put the question mark, that's a compilation error.

So you have to check it, and of course you can also have it manually, but the point is it's this idea of there are these things where you write some code and there's some implicit error condition you didn't think of and now you just took down your server or something.”

[madmorett, CTO da Monest @Morett_the_best]

opa!!!!!!!!

vou responder com calma nesse sabadão...

acho que ja é consenço que o gargalo não é shippar código, mas garantir qualidade no código gerado e que tudo gerado está indo de acordo com a visão de futuro da empresa

então como organizamos na Monest?

tudo começa no repositório `monest-docs`, nesse repositório, antes de começar qualquer projeto, fazemos uma RFC, essa RFC será feita pelo time responsável por fazer essa nova funcionalidade, e deverá ser aprovada por 2 TL's, existe um template base com as informações necessárias para começar o projeto

após a RFC aprovada, usamos github submodules para levar esse contexto da RFC da para o repositório de frontend/backend, e também usamos a RFC como base para os tickets criados no Linear

com o spread da RFC nas codebases e ela sendo usada como base para o Linear para criação das tarefas, vamos começar a codar, depois de garantir na planning que: todos estamos na msm página, se a gnt não tiver na msm pagina, parabéns, vamos gerar linhas pra krl de código apontando para uma direção que não é aonde a empresa quer ir, e tudo vai ser gerado mt rápido

durante o ciclo de desenvolvimento, nosso CLAUDE.md sabe que precisa buscar na RFC e na Issue no Linear informações sobre o projeto e a feature que deverá ser feita

além disso, temos uma arquivo de guidelines nas codebases, cada um com +- 1000 linhas com todas as régras do repositório: arquitetura, nomeclatura de arquivos, variávels, regras de arquitetura e sintaxes gerais

claude code lendo a issue, lendo a rfc, e lendo as guidelines, vai TACAR PAU e codar a feature e abrir uma PR

automaticamente com a PR aberta, o coderabbit, que possuí o mesmo contexto do Claude (guidelines, rfc, etc...) vai ler o código, colocar comentários

temos uma skill que fica em um feedback loop infinito pegando o que o coderabbit escreveu, e avaliando se é um comentário pertinente, e caso sim, aplicando o fix na PR (é engração, por mais q o comando para o rabbit seja o msm do claude, o rabbit é mt assertivo revisando, pq ele tem menos contexto de arquivos)

após isso, o trabalho do desenvolvedor é "testar o trabalho gerado pelo Claude" e direcionar o Claude caso algo tenha saído errado

tudo isso acontece com alguns guardrails, exemplo:

- toda PR pode ter no máximo 500 linhas
- toda PR precisa do approve do rabbit e de um outro dev
- temos ao todo 16 shards de testes automatizados e2e, cada um levando em média 10 minutos para rodar
- lint/tsc
- teste unitário p krl tb

"por que limitar linhas????"

porque fizemos um estudo interno onde PR's com + de 500 linhas tinham 4x menos comentários, e se o dev n ler o código, como q ele vai explicar pro key acoount como a feature funciona quando ele perguntar um edge case??? então sim, eu preciso garantir que as pessoas ainda LEIAM o que foi gerado

métricas side q eu olho:
- qtd de bug tickets por squad
- qtd de post mortem
- oscilação nas golden-metrics

hoje + de 80% do código da Monest é gerado via Claude e eu não vejo motivos para isso não ser 100%, mas sempre respeitando o LIMITE COGNITIVO DO SER HUMANO DE LER UM CÓDIGO E ENTENDER

não adianta gerar 39283218 features e nem saber comunicar seu cliente sobre o que de fato ela faz, quais as regras de negócio, o que da e o que não da pra fazer

depois que o ciclo de desenvolvimento da feature/projeto ta feita, a gnt faz uma ADR, cujo unico objetivo é DOCUMENTAR a feature, e dizer o ENTRY POINT

se vc n diz o entry point, vc vai perguntar pra IA "como funciona a feature X", e ela vai ficar igual a uma barata tonta na sua codebase tentando achar onde o código começa e talvez te responda com uma MENTIRA, documentando o entrypoint vc sabe exatamente ONDE COMEÇA a bagaça, e POR ONDE PASSA