Meu gráfico de contribuições do GitHub em 2025 parece pertencer a dois desenvolvedores diferentes. A primeira metade do ano está quase vazia. Na segunda há mais de 4.000 commits.
Não foi porque eu de repente passei a ter mais tempo livre. Eu continuava conciliando um trabalho em tempo integral com side projects. O que mudou foi a quantidade de atrito entre uma ideia e uma versão funcionando: comecei a usar ferramentas de coding com AI de forma muito mais séria.
É importante ser preciso com esse número. Quantidade de commits, sozinha, não é uma métrica de produtividade. Quatro mil commits não provam quatro mil melhorias úteis nem que o código era bom. O gráfico mostra outra coisa: houve uma mudança real no meu ritmo de trabalho. Eu estava construindo, iterando e chegando a versões funcionais com muito mais consistência do que antes.
O verdadeiro gargalo era a energia para começar um experimento
Nos side projects eu encontrava o mesmo problema repetidamente: a primeira versão útil costuma estar atrás de muito trabalho rotineiro. Routing, validação, scripts, testes, configuração e cleanup podem consumir o embalo antes mesmo de eu descobrir se a ideia vale a pena.
Antes eu adiava experimentos quando o primeiro resultado parecia exigir várias noites de setup. As ferramentas de coding com AI não eliminaram esse trabalho, mas reduziram o custo do first pass e encurtaram o caminho até uma versão testável.
Por isso o maior ganho não foi digitar mais rápido. Foi reduzir a activation energy: mais ideias realmente chegavam ao ponto em que eu podia obter evidência real.
Como meu workflow com Node.js mudou
Eu não substituí meu processo de desenvolvimento por uma janela de chat. Em side projects Node.js usei DeepSeek como um segundo par de mãos para tarefas bem delimitadas: criar uma primeira implementação, ler código desconhecido, sugerir testes, analisar stack trace, dividir um refactor grande e revisar suposições de deployment.
- Scaffolding: criar a primeira versão entediante de handlers, validação, scripts ou testes.
- Code reading: seguir o caminho de um request ou valor antes de editar.
- Refactoring: quebrar mudanças mecânicas em diffs pequenos e fáceis de revisar.
- Debugging: gerar várias hipóteses a partir de logs.
- Verification: buscar edge cases e regressões depois do happy path.
Quanto mais claros eram inputs, outputs, constraints e convenções existentes, mais fácil era verificar o resultado. Tarefas vagas produziam com mais frequência uma abstração plausível, porém errada.
Por isso eu tratava o output da AI como candidate patch, não como resposta final. Type checking, testes, build e o fluxo real eram evidência; uma explicação confiante não era.
Onde DeepSeek mais ajudou — e onde não
DeepSeek foi útil para mim principalmente porque eu podia usá-lo repetidamente em tarefas concretas de programação. Eu pedia um first pass, descartava parte, devolvia o erro real, reduzia o scope e iterava rápido.
Não apresento isso como benchmark. Não fiz um estudo controlado contra todos os modelos concorrentes e as linhas de modelos mudam rapidamente. A afirmação defensável é menor: DeepSeek se encaixou bem o suficiente no meu workflow para eu passar a usar AI assistance com muito mais frequência.
Funcionava melhor quando o feedback era barato: função, testes e erro real. Era mais fraco quando dependia de contexto de produto não escrito ou de trade-offs arquiteturais sutis. Nesses casos, uma resposta fluente podia fazer uma suposição ruim parecer concluída.
A AI mudou o custo de experimentar
A maior melhoria não foi “a AI escreve código, então o desenvolvimento ficou automático”. Muitas pequenas partes simplesmente ficaram baratas o bastante para valer a tentativa. Uma feature de side project que antes parecia exigir setup demais podia virar um protótipo enquanto eu ainda estava interessado na ideia.
Essa distinção importa. A AI reduziu o custo de chegar a uma versão testável. Ela não eliminou arquitetura, julgamento de produto, deployment ou correção. Uma implementação gerada ainda pode estar errada; um build bem-sucedido pode falhar em runtime; um protótipo deployado ainda pode ser um produto ruim.
Para mim, o ganho prático foi o embalo. Depois que eu conseguia ver o sistema inteiro funcionando, ficava muito mais disposto a continuar refinando-o.
O que um benchmark mais forte exigiria
Para um benchmark reproduzível eu registraria versões exatas dos modelos, tarefas de programação fixas, snapshots do repositório, prompts, outputs brutos, tempo, patches aceitos e rejeitados, review time, resultados de testes e rework.
Também mediria mais do que commits: tempo da ideia até uma versão verificada, defeitos, rollbacks e trabalho reescrito. Sem esse contexto, 4.000 commits são evidência de atividade e mudança de comportamento, não de qualidade de software.
O que mudou para mim
2025 foi o ano em que parei de tratar cada side project como uma montanha de setup que eu precisava escalar manualmente. A AI tornou a primeira versão funcional barata o suficiente para que eu chegasse com mais frequência ao ponto em que as decisões de produto realmente importavam.
É por isso que a segunda metade do meu gráfico do GitHub parece tão diferente. Não porque a AI tenha me dado mais horas no dia e não porque cada linha gerada fosse boa. Ela reduziu o atrito que havia matado ideias anteriores antes que elas se tornassem reais.
Em 2026, quero me concentrar na metade menos chamativa da equação: refinar o workflow, medir qualidade com mais seriedade e garantir que desenvolver mais rápido produza software melhor, e não apenas mais commits.