632 Commits em 84 Dias: O Que Aprendemos ao Enviar Todos os Dias

O número que conta a história

632 commits. 84 dias. Zero dias sem um commit.

De 21 de novembro de 2025 a 13 de fevereiro de 2026, enviamos código todos os dias. Dias de semana. Finais de semana. Feriados. Natal. Ano Novo. Todos os dias.

Isso não é sobre cultura de hustle ou trabalho árduo. É sobre o que acontece quando você mantém o ritmo em um produto que está crescendo mais rápido do que você planejou.

O ritmo diário de envio

Aqui está como 7,5 commits por dia realmente se parece:

Manhã: Revise o que foi enviado durante a noite (lembre-se, a IA resolve problemas às 3 da manhã). Verifique o staging. Identifique o que vem a seguir.

Meio-dia: Envie a principal funcionalidade do dia. Isso geralmente é um PR com 3-5 commits: a funcionalidade, uma correção descoberta durante o desenvolvimento e um aumento de versão.

Noite: Polir, corrigir casos extremos, atualizar dependências. Os commits que não são glamourosos, mas mantêm o produto funcionando sem problemas.

Alguns dias tiveram um commit. Outros dias tiveram vinte. 22 de novembro — dia dois — teve doze commits. O dia em que integramos os sandboxes do E2B teve mais de uma dúzia. O padrão varia, mas a sequência nunca quebrou.

Como é o envio composto

A coisa mais interessante sobre enviar todos os dias não é nenhum commit individual. É o efeito composto.

Semana 1: Interface de chat + sistema de arquivos + espaços de trabalho. Um produto funcional.

Semana 2: Faturamento + internacionalização + bibliotecas de UI. Um produto sustentável.

Semana 4: Agendamento + integração + execução de código. Um produto útil.

Semana 8: Geração de imagens + habilidades + seleção de modelos. Uma plataforma.

Semana 12: Execução em sandbox + agentes em segundo plano + CI autônomo. Uma plataforma autônoma.

Cada semana se baseia na anterior. As funcionalidades não existem isoladamente — elas se combinam. Agendamento + sandboxes = execução de tarefas em segundo plano. Faturamento + geração de imagens = ferramentas criativas sustentáveis. Habilidades + sandboxes = mercado de automação seguro.

O efeito composto significa que a produção da semana 12 é qualitativamente diferente da da semana 1, não apenas quantitativamente maior. Não estamos apenas construindo mais funcionalidades. Estamos construindo combinações de funcionalidades mais capazes.

Os commits que mais importam

Se você rolar pela nossa história do git, encontrará três tipos de commits:

Os construtores. “feat: adicionar módulo de agentes em sandbox,” “feat: adicionar painel de configurações de espaço de trabalho,” “feat: adicionar sistema de habilidades com importação do ClawHub.” Essas são as grandes funcionalidades. Elas geram os posts no blog. Elas aparecem nos changelogs.

Os solucionadores. “fix: evitar loop de polling de mensagens infinito,” “fix: excluir eventos em cascata na exclusão de sessão,” “fix: incorporar URLs de imagens em markdown para evitar corrupção de URL do LLM.” Esses são menos glamourosos, mas provavelmente mais importantes. Cada um representa um usuário real enfrentando um problema real.

As atualizações invisíveis. “chore: aumentar @fulldiveVR/chat-ui para 2.0.12,” “refactor: direcionar todas as chamadas de juiz através do OpenRouter,” “perf: adicionar logs de rastreamento de PERF.” Essas não mudam o que os usuários veem, mas mudam como bem funciona. Melhorias de desempenho. Correções de segurança. Atualizações de dependências.

A proporção é de aproximadamente 30% construtores, 40% solucionadores, 30% invisíveis. Essa proporção parece saudável. Muitos construtores e poucos solucionadores significam bugs crescentes. Muitos solucionadores e poucos construtores significam estagnação. Poucos commits invisíveis significam acumulação de dívidas.

Os feriados

28 de novembro (Ação de Graças): 14 commits. Melhorias de template, correções de biblioteca de UI, modernização de agentes.

25 de dezembro (Natal): 6 commits. Resolvedor automático de problemas, proteção de assinatura, automação de fluxo de trabalho.

1 de janeiro (Ano Novo): 8 commits. Correções de favicon, melhorias de sessão, compartilhamento de arquivos.

Não estamos nos gabando de trabalhar em feriados. Alguns desses foram merges agendados. Alguns foram a IA corrigindo coisas de forma autônoma. Alguns foram de um fundador que não conseguia parar de pensar em um bug.

O ponto não é “trabalhamos no Natal.” O ponto é “o produto melhorou no Natal.” Se essa melhoria veio de um humano ou de uma IA, os usuários não se importam. Eles apenas veem um produto melhor quando o abrem na próxima vez.

O que aprendemos

Envie a menor unidade significativa. Não a funcionalidade inteira. A menor coisa que torna o produto melhor. Um botão que funciona. Um erro que é tratado. Um rótulo que é mais claro. Commits pequenos são fáceis de revisar, fáceis de reverter e fáceis de entender.

Corrija bugs no dia em que são encontrados. Nosso tempo médio do relatório de bug até a correção é medido em horas, não em dias. Isso só é possível porque enviamos todos os dias. Uma equipe que envia semanalmente segura bugs por uma semana. Uma equipe que envia diariamente os corrige hoje.

Deixe a sequência te motivar. Há algo psicológico em uma sequência diária. Uma vez que você enviou por 30 dias seguidos, você não quer quebrá-la no dia 31. A sequência se torna sua própria motivação. Não é sustentável para sempre — e faremos pausas — mas, para uma fase de lançamento, é poderosa.

O acúmulo é real. O commit do dia 84 é qualitativamente diferente do commit do dia 1. Não porque somos mais inteligentes. Porque estamos construindo sobre 83 dias de fundação. Cada dia torna o próximo dia mais produtivo. Esse é o verdadeiro poder do envio diário.

632 commits. 84 dias. Um produto que passou de nada a uma plataforma de agente de IA autônoma.

Os próximos 84 dias serão ainda melhores.