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

🚨🚨🚨🚨🚨 ALERTA Monest acabou de quebrar o seu record, fizemos *1 MILHÃO* de conversas com AI no mês de Janeiro Isso da uma média de mais de 32 mil conversas por dia Isso é só o começo, vamos fazer mais de 10 milhões por mês até o fim do ano 🚀🚀🚀🚀🚀

Monest