Tudo como código: como operar uma empresa com um único monorepo

 (kasava.dev)
3 pontos por GN⁺ 2026-01-01 | 1 comentários | Compartilhar no WhatsApp
  • Kasava gerencia todo o processo de desenvolvimento do produto dentro de um único monorepo, integrando código, documentação, marketing e dados operacionais
  • Todas as mudanças são aplicadas em um único commit, em uma estrutura na qual backend, frontend, site e documentação são atualizados ao mesmo tempo
  • Ferramentas de IA consultam diretamente código, documentação e site para realizar verificação de consistência, atualização automática de documentação e revisão de conteúdo
  • CLAUDE.md, CI/CD seletivo e uma estrutura de projetos npm independentes minimizam a complexidade de um repositório de grande escala
  • Essa abordagem fortalece uma cultura de desenvolvimento AI-native e remove as fronteiras entre produto, conteúdo e operações, possibilitando implantações rápidas e colaboração eficiente

O significado do desenvolvimento AI-native e do monorepo

  • A Kasava integra todos os componentes da plataforma em um único repositório Git, incluindo não apenas código, mas também documentação, marketing, e-mails e até materiais para investidores
    • Ex.: frontend/, backend/, website/, docs/, marketing/, external/ e mais de 5.470 arquivos TypeScript
  • A IA acessa código e documentação ao mesmo tempo para realizar automação baseada em contexto
    • Edição de documentação, alteração de preços no site e validação de blogs podem ser resolvidas em uma única conversa com a IA
  • Todas as mudanças são implantadas pelo mesmo workflow do Git (git push)
    • Código, conteúdo, documentação e marketing passam pelos mesmos processos de revisão, CI/CD e auditoria
  • Esse modelo aumenta a velocidade e a consistência e consolida uma cultura de “gerenciar tudo como código”

Por que integrar tudo em um único repositório

  • Mudanças atômicas entre fronteiras (Atomic Changes)
    • Ao modificar a API do backend, as definições de tipo do frontend e a documentação são atualizadas no mesmo commit
    • Ex.: ao adicionar uma integração com Asana, backend, frontend, documentação e site são mesclados em um único PR
  • Fonte única da verdade (Single Source of Truth)
    • Um único billing-plans.json define os limites dos planos, e todos os serviços o consultam
    • A IA valida automaticamente a consistência entre backend, frontend e site
  • Refatoração entre projetos
    • No IDE, é possível buscar e modificar desde todo o código até documentação e exemplos de blog
  • Ferramentas e pipelines compartilhados
    • O gerenciamento é simplificado com CI/CD, dependências e ambiente de busca em comum

Estrutura do repositório e seus componentes

  • Core Application:
    • frontend/ é baseado em Next.js 16 + React 19, e backend/ usa Cloudflare Workers + Hono + Mastra
    • Em mudanças de API, há compartilhamento de segurança de tipos e utilitários de teste
  • Marketing:
    • Inclui website/, marketing/blogs/, investor-deck/ e email/
    • Blogs, e-mails e materiais para investidores são todos versionados como código, com possibilidade de rollback via git revert
  • Documentation:
    • docs/ é a documentação pública baseada em Mintlify, e docs-internal/ contém a documentação interna de arquitetura
    • Pode ser pesquisada junto com o código, mantendo informações sempre atualizadas em vez de depender de wiki
  • External Services:
    • Inclui serviços externos implantados, como extensão do Chrome, Google Docs Add-on e GCP Functions
    • Mudanças são refletidas simultaneamente por meio do compartilhamento de contratos de API
  • Development Infrastructure:
    • Inclui servidores simulados e ferramentas de teste para desenvolvimento local, como github-simulator/, infra-tester/ e scripts/

Modo de operação e cultura de desenvolvimento

  • Sem uso de workspaces
    • Cada diretório é mantido como um projeto npm independente, evitando conflitos de dependências
  • CI/CD seletivo (Selective CI/CD)
    • O GitHub Actions é acionado com base em caminhos, executando apenas os testes relevantes
  • Regras em CLAUDE.md
    • Em cada diretório principal, são documentados stack técnico, comandos e decisões de arquitetura
    • O assistente de IA lê isso para entender o contexto do projeto
  • Configuração consistente de ferramentas
    • Configurações comuns como .prettierrc, .eslintrc e tsconfig.json são mantidas de forma padronizada

Desafios e respostas

  • Tamanho do repositório: atualmente, o tempo de clone é de cerca de 20 segundos, sem problemas de desempenho no Git
    • Ativos grandes devem ser separados para R2/S3 no futuro
  • Tempo de build: cada projeto tem build independente, com recompilação rápida via Turbopack, Wrangler e WXT
  • Limites de permissão: equipes pequenas podem ter acesso total; se necessário, é possível aplicar CODEOWNERS e proteção de branch
  • Troca de contexto: a alternância entre diferentes linguagens (TypeScript, Apps Script, MJML) é amenizada com CLAUDE.md e formatação padronizada

Conclusão

  • O monorepo da Kasava não é apenas uma tendência, mas uma ferramenta para maximizar a produtividade por meio da integração de contexto
  • Backend, frontend, documentação e marketing funcionam dentro de uma única mudança, com a IA validando tudo em tempo real
  • Como resultado, “o monorepo não é uma limitação, mas um acelerador (force multiplier)”

Leituras relacionadas

1 comentários

 
GN⁺ 2026-01-01
Comentários do Hacker News

  • Isso não parece administrar a empresa inteira, mas só um único produto (monorepo)
    Não há finanças, RH, contratos ou fotos da equipe; é mais uma estrutura de frontend + backend com uma pasta de marketing incluída de um jeito um pouco incomum

    • Pelo texto linkado, dá para ver que essa empresa é, na prática, uma empresa de uma pessoa só
      Então é possível colocar tudo em um único repo, mas isso levanta dúvidas sobre o valor dos “insights” que se pode tirar dessa situação
    • “IA! IA!”
    • O repo também não inclui código de infraestrutura (IaC)
    • Eu queria ver um caso de verdade em que literalmente tudo estivesse dentro de um repo no GitHub
      Por exemplo, incluindo até artefatos criptografados, com algo como “só o CEO guarda fisicamente a chave de criptografia”
      Seria bom se o GitHub adicionasse o conceito de pasta privada, mas isso entra na questão de ACL e talvez seja pedir demais

  • Eu apoio a filosofia de monorepo e sem branch de desenvolvimento
    Mas desenvolvimento e release precisam ser coisas separadas
    Tem que ser possível cortar releases estáveis e fazer cherry-pick, e a estabilidade da API entre frontend e backend precisa ser mantida

    • Também teve quem perguntasse o que significa “sem branch de desenvolvimento”
      Se o desenvolvimento é feito direto na main, a pessoa queria saber como trabalhos de tamanhos diferentes são gerenciados em paralelo
    • Também perguntaram por exemplos concretos em que cherry-pick seria necessário
      A pessoa disse que opera mais de 3 produtos em monorepo e que nunca teve problema fazendo deploy por unidade de release estável
    • Outra pessoa disse que controla o momento do deploy com feature flags
    • Outra disse que gosta de manter branches antigas
      Não gosta de git squash e afirma que o modelo de forking dá mais liberdade aos desenvolvedores

  • A ideia de que “uma única mudança atualiza tudo ao mesmo tempo” é uma ilusão perigosa
    Em sistemas com banco de dados ou API, sempre é preciso considerar retrocompatibilidade
    Em organizações com vários times, acontece de um time não conseguir validar a atualização e acabar travando todo o resto
    Por isso rollout gradual é essencial

    • Concordo totalmente. Em uma empresa pequena (Kasava) isso pode funcionar, mas em um SaaS global até alguns minutos de indisponibilidade são fatais
      O monorepo em si não é ruim, mas “uma mudança e tudo entra em produção imediatamente” é impossível
      Porque schema de banco e código não podem mudar ao mesmo tempo
      Esse tipo de texto parece um blog escrito por IA, e provavelmente nem deve ter clientes reais
    • Também houve a réplica de que o local onde o código é armazenado (repo) e a forma de deploy devem ser coisas separadas
      Em vez de confundir problema organizacional com problema técnico, isso deveria ser coordenado com políticas entre times e liderança
    • Uma pessoa disse que usa monorepo junto com geração automática de código (openapi-generator) para refletir imediatamente mudanças de API entre serviços
      Acrescentou que isso só é viável porque o time é pequeno
    • À afirmação de que “o ponto forte é concentrar o contexto da IA em um só lugar”, houve a resposta de que bastaria clonar vários repos em um workspace
    • Em contrapartida, também houve quem dissesse que pior é quando cada serviço mantém sua própria versão e não atualiza

  • Eu não gostava de monorepo antes, mas mudei de ideia depois de usar Claude Code
    Quando frontend e backend estão no mesmo repo, fica fácil manter tudo sincronizado

    • Disseram que também funciona bem abrir o Claude no diretório pai, mas que a vantagem é poder alterar os dois lados no mesmo commit
    • Também houve a reação de que “se o motivo para usar monorepo é só reduzir flags de comando, isso é meio engraçado”
    • Eu também refatorei para monorepo porque era difícil conectar várias ferramentas de LLM
    • Por causa de problemas de hoisting no React Native, evitam yarn workspace, mas colocar PRDs ou documentos de planejamento no repo ajudou a dar contexto para a IA
    • Na verdade, o Claude Code consegue lidar com vários diretórios ao mesmo tempo, então monorepo não é estritamente necessário

  • Esse texto parece ter sido escrito por IA
    É cansativo porque está difícil encontrar conteúdo escrito por humanos

    • Se passar no GPTZero, quase tudo parece ter sido gerado por IA
      Frases como “This isn’t just for…” e “The Challenges (And How We Handle Them)” são um tom bem típico de IA
    • Em contrapartida, também teve quem dissesse “reclamar que texto é de IA já cansou”
      Algo na linha de que, mesmo não sendo perfeito, não seria melhor do que texto escrito por humanos?

  • A parte de dizer “peça ao Claude para atualizar a página de preços” soa estranha
    Se a página de marketing é gerenciada no mesmo repo, fica difícil entender por que delegar isso a um LLM, se bastaria ler os dados de um arquivo de config

    • Houve quem apontasse que a IA está virando vício ou dependência
    • Também houve a resposta de que “code review ainda existe”
      Ou seja, ter IA não significa que humanos deixaram de revisar

  • Colocar “frontend, backend e site” no mesmo repo parece confuso
    Integrar tudo no nível de commit parece bom, mas 3 repos já seriam suficientes para administrar isso
    Para operar um monorepo direito, o custo de manutenção é considerável

  • O texto parece ter sido escrito por IA, mas a própria ideia de expandir IaC ao extremo é interessante
    Então o sentimento é misto

    • É curioso que a maioria dos comentários não percebeu os sinais de texto escrito por IA
      Quando esse estilo de LLM se tornar familiar para o público, textos como esse provavelmente vão parecer cafonas
    • Também houve quem dissesse que bastava trocar expressões como “Why This Matters”
    • Também disseram que usar IA sem declarar isso e publicar com nome humano parece desonestidade intelectual

  • Se o site da empresa estiver no mesmo repo, fica fácil encontrar materiais de branding e o tom da marca
    Assim, fica bom para gerar automaticamente slides para clientes ou vídeos de demonstração
    Além disso, também é interessante colocar documentação, bugs e issues tudo em um só lugar

  • Em uma startup antiga chamada Pangea, montaram uma estrutura parecida
    No geral foi bom, mas não era perfeito

    • Ao tentar gerenciar tudo pelo repo, mudanças de feature flags ficaram lentas, e era difícil lidar com a imutabilidade das branches
    • Quando os serviços chegaram a uns 20, o GitLab CI ficou lento e complexo
    • Os testes E2E eram lentos e instáveis, então o pipeline quebrava com frequência
      Mesmo assim, também houve resultados como a migração para ARM e redução de 70% nos custos de computação
      Link da Pangea
    • Em resposta, também houve quem perguntasse se usaram ferramentas de monorepo como turbo, buck, Bazel
      Disseram que, sem ferramentas assim, o CI bate no limite de escalabilidade