Imagine um repositório de desenvolvimento pessoal cujo número sequencial de Issues e Pull Requests no GitHub está chegando a quatro dígitos.
A reação imediata costuma ser:
“Uma pessoa fez quase mil trabalhos de desenvolvimento?”
Quase, mas essa conversão não é correta. No sistema de numeração do GitHub, todo Pull Request é tratado como um tipo de Issue, e os números de Issues e Pull Requests não se sobrepõem dentro do mesmo repositório. Portanto, estar perto do número 1000 não significa ter concluído 1000 Pull Requests.[1]
A pergunta realmente interessante continua valendo:
Se uma pessoa tivesse de fazer quase manualmente, sem IA, esse volume de alterações, verificações, correções, publicação e operação, quanto custaria? E a conta fecharia?
Essa é uma pergunta central para entender a economia do desenvolvimento solo assistido por IA.
1. O número do GitHub não é um contador de repetições da academia
O número do repositório não mede carga de trabalho.
Um desenvolvedor pode colocar 2000 linhas modificadas em um único Pull Request. Outro pode abrir um Pull Request para uma alteração de uma linha em CSS. E os Issues também entram na mesma numeração: bugs, notas de arquitetura, pedidos de funcionalidade, investigações e tarefas operacionais.
Portanto:
quase 1000 na sequência não significa trabalho equivalente ao de 1000 pessoas.
Também não significa:
quase 1000 funcionalidades completas.
O número se parece mais com o contador de uma catraca do que com uma balança.
Ainda assim, se muitos pequenos ajustes foram acumulados em pouco tempo, o histórico mostra algo relevante: o ciclo projeto → implementação → verificação → correção foi executado repetidamente.
Para estimar custo humano, o importante não é o número em si, mas o tempo médio consumido por cada ciclo substantivo.
2. O custo humano é fácil de subestimar quando cada tarefa parece minúscula
Um relatório publicado em setembro de 2026, baseado em anúncios de projetos para engenheiros freelancers no Japão, apontou uma média mensal de 789 mil ienes para agosto de 2026.[2]
Isso não é o salário de todo desenvolvedor nem a taxa horária de uma pessoa específica. É uma média do mercado de projetos listados.
Mesmo assim, serve como uma referência de custo de substituição: quanto poderia custar comprar capacidade profissional semelhante externamente?
Dividindo por 160 horas mensais, dá cerca de 4930 ienes por hora.
Agora suponha 1000 unidades de mudança substantiva. É apenas um cenário hipotético e não equivale ao #1000 do GitHub.
| Tempo médio por mudança | Tempo total | Pessoa-mês a 160 h/mês | Custo a 789 mil ienes/mês |
|---|---|---|---|
| 15 min | 250 h | 1,56 | aprox. ¥1,23 mi |
| 30 min | 500 h | 3,13 | aprox. ¥2,47 mi |
| 45 min | 750 h | 4,69 | aprox. ¥3,70 mi |
| 1 h | 1000 h | 6,25 | aprox. ¥4,93 mi |
| 2 h | 2000 h | 12,5 | aprox. ¥9,86 mi |
| 3 h | 3000 h | 18,75 | aprox. ¥14,79 mi |
| 4 h | 4000 h | 25 | aprox. ¥19,73 mi |
Mesmo 1000 mudanças de apenas 15 minutos somam 250 horas.
“Cada tarefa é pequena” não significa que “o total é pequeno”.
Tarefas pequenas também carregam custos fixos: investigar, criar branch, revisar, testar, fazer merge, conferir o deploy e pensar em rollback.
Se uma única pessoa fizer tudo manualmente, o cartão de visitas acaba virando um folheto dobrável: redator, tradutor, frontend, backend, QA, infraestrutura e editor-chefe.
3. “Eu mesmo fiz, então o custo de mão de obra é zero” pode ser verdade no caixa e falso na comparação econômica
Um site pessoal pode gastar 1000 ienes por mês com hospedagem e ganhar 5000 em anúncios.
Em caixa, há um excedente de 4000 ienes.
Mas, se o dono trabalha 50 horas por mês no projeto, a comparação como negócio exige outra visão.
Separe pelo menos duas contas:
Lucro de caixa = receita − despesas em dinheiro
Lucro ajustado por trabalho = receita − despesas em dinheiro − horas do dono × valor horário de substituição escolhido
Se é hobby, atribuir valor zero ao próprio tempo pode ser totalmente razoável. Ninguém costuma dizer que jogar videogame por 50 horas gerou um prejuízo trabalhista.
O problema aparece quando a contabilidade do hobby vira prova de rentabilidade empresarial.
Aprendizado, diversão, reputação e satisfação de criar são retornos reais. Só não são a mesma coisa que lucro do negócio.
Na comparação econômica, o tempo não desaparece só porque ninguém emitiu uma nota.
4. O modelo de publicidade pode precisar de um denominador enorme
Uma fórmula simplificada é:
Receita de anúncios = visualizações de página ÷ 1000 × RPM efetivo
O RPM muda bastante com país, dispositivo, formato, estação do ano, tema, público e configuração de anúncios.
Por isso, em vez de fingir que existe um RPM universal, use valores hipotéticos apenas para visualizar a escala.
Se fosse necessário recuperar 789 mil ienes por mês somente com anúncios:
| RPM efetivo hipotético | PV necessários para ¥789 mil/mês |
|---|---|
| ¥100 | aprox. 7,89 milhões |
| ¥300 | aprox. 2,63 milhões |
| ¥500 | aprox. 1,58 milhão |
| ¥800 | aprox. 0,99 milhão |
Isso não é previsão de receita para nenhum site específico.
A tabela mostra que quando o trabalho manual é avaliado pelo custo profissional de substituição, recuperar tudo apenas com anúncios pode exigir muito tráfego.
Por isso, sites manuais muitas vezes combinam anúncios com afiliados, venda de produtos, aquisição de clientes, assinaturas, doações, valor de marca ou simplesmente valor de hobby.
5. A IA muda muito mais do que a velocidade de escrever
Reduzir a IA a “ela escreve um artigo em 30 segundos” perde boa parte da economia.
Operar uma publicação web exige trabalho ao redor:
- encontrar pautas,
- pesquisar,
- redigir,
- checar fatos,
- alterar código,
- testar,
- localizar para outros idiomas,
- publicar,
- verificar o resultado real em produção,
- corrigir incidentes,
- distribuir em redes sociais e newsletter,
- medir e melhorar.
Em operação manual, cada etapa adicional tende a aumentar o custo variável de trabalho.
Com IA e automação, o custo inicial para construir o sistema pode ser maior, mas o custo marginal do segundo, décimo e centésimo item pode cair.
Não é apenas “o redator ficou mais rápido”.
É mais parecido com:
uma pessoa consegue possuir o sistema operacional de uma pequena redação e de uma pequena equipe de engenharia.
A pessoa não desaparece.
O papel humano se desloca para entradas, decisões, especificações, critérios de qualidade, exceções e governança.
Em vez de fabricar cada artefato, passa a projetar a fábrica e editar sua produção.
6. IA não é nitro mágico que sempre deixa o desenvolvimento mais rápido
Os resultados de pesquisa são interessantes justamente porque não apontam numa única direção.
Um estudo controlado publicado em 2023 encontrou que participantes com GitHub Copilot concluíram uma tarefa específica de servidor HTTP em JavaScript 55,8% mais rápido do que o grupo de controle.[3]
Já um ensaio aleatorizado da METR em 2025 encontrou o oposto: 16 desenvolvedores experientes de código aberto, trabalhando em repositórios maduros que conheciam havia anos, demoraram em média 19% mais quando podiam usar ferramentas de IA do início de 2025.[4]
Em fevereiro de 2026, a METR explicou que o experimento posterior ficou difícil de interpretar. Mais desenvolvedores passaram a evitar participar se precisassem trabalhar sem IA, e medir tempo também ficou mais difícil para quem rodava vários agentes em paralelo. É plausível que ferramentas mais novas acelerem mais do que as de início de 2025, mas os dados novos não permitem afirmar com confiança um percentual exato por causa de seleção e problemas de medição.[5]
Portanto, a conclusão não é:
IA sempre deixa tudo 55% mais rápido.
Nem:
IA deixa especialistas 19% mais lentos.
O efeito depende da tarefa, familiaridade com o código, fluxo de agentes, carga de revisão, paralelismo e ambiente de testes.
A IA pode produzir acertos rapidamente. Um sistema mal desenhado também pode produzir bugs rapidamente.
A medida relevante é aquela observada no fluxo real do projeto.
7. Um site manual não perde automaticamente
Um sistema altamente automatizado com IA não garante mais lucro do que um site artesanal.
Produção manual pode fazer sentido quando:
- são publicados poucos textos por mês,
- a escrita pessoal do especialista é o próprio produto,
- um artigo vende um serviço ou produto de alto valor,
- não há necessidade de vários idiomas ou grande distribuição,
- as atualizações são raras,
- o dono gosta da produção como hobby,
- ou construir automação custaria mais do que o trabalho economizado.
A automação tende a ser mais atraente quando:
- o mesmo processo se repete,
- vários idiomas são mantidos,
- o estoque de conteúdo cresce,
- toda publicação exige QA e verificação real,
- os canais de distribuição aumentam,
- e humanos repetem as mesmas checagens continuamente.
No fundo, é uma disputa entre custo fixo e custo variável.
A fábrica com IA pode ser cara no começo. A oficina manual pode ser cara por unidade.
E vale o aviso: uma fábrica automatizada espetacular sem leitores não é o futuro da mídia. É um armazém extremamente sofisticado.
8. Para entender a economia de um site manual sem IA, pergunte por estes números
Não é necessário julgar a pessoa.
Para comparar sistemas, alguns números operacionais bastam:
- Horas do dono por mês
- PV ou usuários únicos mensais
- Receita e despesas em dinheiro por mês
- Número de artigos e novos artigos mensais
- Número de idiomas
- Anos de operação e horas aproximadas da construção inicial
A partir deles, dá para calcular:
Lucro de caixa = receita − despesas em dinheiro
Retorno de caixa por hora do dono = lucro de caixa ÷ horas
Lucro ajustado por trabalho = lucro de caixa − horas × valor horário de comparação
Custo marginal por artigo = trabalho e despesas adicionais de redação + tradução + QA + publicação + distribuição
O último indicador é especialmente importante.
Ter gasto 1000 horas no passado diz menos sobre o futuro do que quantas horas são necessárias para publicar o próximo artigo agora.
9. A verdadeira força da IA no desenvolvimento solo não é volume; é repetibilidade
Gerar uma pilha enorme de arquivos durante a noite já não é a parte mais difícil.
O difícil é construir um sistema em que:
- os mesmos critérios de qualidade funcionem da próxima vez,
- apenas o escopo que falhou precise ser repetido,
- publicação duplicada seja evitada,
- a revisão atual seja identificável,
- o resultado real em produção seja verificado,
- um canal bloqueado não congele trabalhos independentes,
- autenticação que realmente exige uma pessoa volte para uma pessoa,
- e o histórico continue auditável.
Isso não é apenas volume de geração.
É um ativo operacional.
Um site manual pode construir o mesmo tipo de ativo com procedimentos, modelos, CMS, backups e checklists.
A diferença na era da IA é que uma única pessoa consegue construir essas camadas operacionais com profundidade muito maior.
10. Conclusão: mais importante do que “chegou a 1000?” é “quanto custa a próxima unidade?”
Um número sequencial de Issues e Pull Requests perto de quatro dígitos impressiona.
Mas não deve ser usado como nota de produtividade.
Os números mais úteis são:
horas humanas, custo por mudança, custo marginal por artigo, retrabalho antes da publicação, produção por hora do dono, e lucro ajustado por trabalho em relação à receita.
Um site manual pode ser rentável.
Um site com IA pode dar prejuízo.
Mas as curvas de custo são muito diferentes entre um modelo em que humanos repetem manualmente escrita, tradução, desenvolvimento, QA, publicação, monitoramento e distribuição e outro que investe primeiro em sistematizar essas etapas para reduzir o custo marginal depois.
A aproximação do número 1000 é interessante não porque seja uma medalha.
A pergunta importante é:
quantas dessas rodadas de tentativa e correção viraram mecanismos que evitam repetir o mesmo trabalho humano da próxima vez?
É aí que a economia do desenvolvimento solo assistido por IA realmente muda.
- GitHub Docs — Issue event types / REST API. GitHub states that every pull request is an issue, but not every issue is a pull request, and that issue and pull-request numbers do not overlap within a repository docs.github.com
- En Japan / Freelance Start, 2026-09-03. August 2026 freelance-engineer listings averaged ¥789,000 per month; 445,327 listings were included at month end. This is a marketplace listing statistic, not a universal salary or an observed cost for any person discussed in this article prtimes.jp
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.” In a controlled JavaScript HTTP-server task, the treatment group completed the task 55.8% faster arxiv.org
- Becker, J., Rush, N., Barnes, B., & Rein, D. / METR (2025-07-10). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” Sixteen experienced developers completed 246 tasks in mature repositories; allowing early-2025 AI tools increased completion time by 19% on average in this study metr.org
- METR (2026-02-24). “We are Changing our Developer Productivity Experiment Design.” METR reports that later productivity experiments suffered from participant-selection and time-measurement problems, especially as developers became reluctant to work without AI and used multiple agents in parallel; the newer data are weak evidence for the size of current speedup metr.org
