Executivos de big tech prometem que IA vai reduzir nossa carga horária. Funcionários contam que estão trabalhando até 90 horas por semana. Essa contradição não é acaso — é a lógica do資本ismo de atenção aplicada ao código. E eu, como dev há mais de uma década, vejo isso acontecer todo dia.
Segundo o BBC News, a OpenAI incentivou empresas a testar a semana de quatro dias enquanto ex-funcionários descrevem uma cultura de “reuniões de crise” aos sábados e avaliações “extremamente rigorosas”. O Google, em 2021, disse que teríamos quatro dias úteis até 2025. Estamos em 2026. Ninguém ganhou a sexta-feira de volta. Então, o que realmente mudou com IA? Não foi a quantidade de trabalho. Foi a velocidade esperada.
O Paradoxo da Produtividade Acelerada: Você Faz o Mesmo em Menos Tempo, Mas Faz Muito Mais
Na minha experiência, quando uma ferramenta me torna mais rápido, o que acontece não é que eu trabalho menos. É que eu entrego mais no mesmo período. É o que Jevons observou em 1865 com carvão: eficiência não reduz consumo, expande demanda. Com IA, é idêntico.
Trabalhei em times que adotaram Copilot, Cursor e Claude Code. Em todos, a métrica de “story points por sprint” subiu. Mas ninguém saiu mais cedo. O que aconteceu foi que o roadmap cresceu junto com a capacidade. O PM descobriu que dava para entregar o trimestre em dois meses, então adicionou mais features. Em IA, chamamos isso de Jevons paradox no desenvolvimento de software.
A promessa de “menos horas” assume que a demanda é fixa. Não é. Em software, demanda é praticamente infinita. Sempre tem mais feature, mais bug, mais otimização, mais integração. IA remove o gargalo técnico e expõe o gargalo humano — que é o nosso próprio limite.
O que a Reportagem do BBC Não Conta: A Cultura de “Crisis Mode”
O ex-funcionário da OpenAI descreveu “reuniões de crise” aos fins de semana. Isso não é exclusivo da OpenAI. É endêmico em empresas que vendem IA. E tem uma razão técnica bem específica.
Modelos de IA em produção não são software tradicional. São sistemas estocásticos. Um LLM pode funcionar perfeitamente em 99,9% das requests e falhar de formas imprevisíveis no 0,1% restante. Isso gera uma classe de bugs que devs tradicionais não estão acostumados a tratar: alucinações sutis, drift de comportamento, custo de inference que explode sem aviso.
Resultado: plantão. Muito plantão. Quando o modelo começa a retornar respostas ruins em escala, alguém precisa acordar às 3h da manhã para ajustar prompt, fazer rollback ou mudar de provedor. Esse é o trabalho real que ninguém mostra nos keynotes.
Comparação Honesta: Expectativa vs. Realidade por Ferramenta
| Ferramenta | Promessa de Marketing | Impacto Real no Dia a Dia |
|---|---|---|
| GitHub Copilot | “Code 55% faster” | Reduz boilerplate, mas adiciona tempo de revisão de código gerado (porque ele erra silenciosamente) |
| Cursor | “Pair programming com IA” | Acelera refactor, mas devs gastam mais tempo validando outputs do que escrevendo |
| Claude Code / Aider | “Autonomia total” | Funciona bem para tasks pequenas. Em sistemas complexos, ainda exige supervisão constante |
| Devin / Auto-dev agents | “Substitui dev júnior” | Quebra menos que antes, mas debuga menos também. Ainda exige humano no loop |
Na Prática: Como Eu Automatizo Minha Semana sem Cair na Armadilha
Eu uso IA no dia a dia. Muito. Mas com regras claras para não virar refém da promesa de “trabalho infinito”. Isso aqui é o que funciona pra mim, testado em produção real:
- Defina um horário de hard stop. 19h, desligo Slack, Discord, email. Sem exceção. IA não muda isso.
- Use IA para tasks com escopo fechado. “Escreva função que valida CPF” sim. “Refatore esse microserviço inteiro” não — você vai gastar mais debugando a IA do que fazendo.
- Não aceite mais tickets só porque “agora dá pra entregar”. O roadmap precisa ser negociado com stakeholders, não ditado pela velocidade do seu tools.
- Time-box a experimentação. 30 minutos testando um novo agent. Se não produtividade concreta, descarta.
- Documente o que a IA fez por você. No final da sprint, liste o que foi gerado por IA e revisado por você. Se for mais de 70% gerado, revise com mais cuidado. LLMs alucinam silenciosamente.
Um Script que Eu Uso Para Auditar Onde IA Está Realmente me Ajudando
Criei um script Python simples que roda no fim do dia e mede quanto do meu commit foi assistido por IA vs. escrito do zero. Não é ciência exata, mas mostra tendência:
import subprocess
import json
from datetime import datetime, timedelta
def analizar_commits_dia(repo_path: str, autor: str) -> dict:
"""Analisa commits do dia e separa 'assistido por IA' vs 'manual'."""
ontem = (datetime.now() - timedelta(days=1)).strftime("%Y-%m-%d")
cmd = [
"git", "-C", repo_path, "log",
f"--since={ontem}",
f"--author={autor}",
"--pretty=format:%H|%s|%b",
"--numstat"
]
resultado = subprocess.run(cmd, capture_output=True, text=True)
commits = []
total_linhas = 0
linhas_ia = 0
commit_atual = None
for linha in resultado.stdout.split("\n"):
if "|" in linha and not linha[0].isdigit():
commit_atual = linha
elif linha.strip():
try:
adicionadas, removidas, _ = linha.split("\t")
adicionadas = int(adicionadas)
total_linhas += adicionadas
# Heurística: commits com prefixo "ai:" ou "copilot:"
# foram assistidos por IA no meu fluxo
if commit_atual and any(
tag in commit_atual.lower()
for tag in ["ai:", "copilot:", "claude:", "cursor:"]
):
linhas_ia += adicionadas
commits.append({
"hash": commit_atual.split("|")[0][:7] if commit_atual else "",
"msg": commit_atual.split("|")[1] if commit_atual else "",
"linhas": adicionadas
})
except ValueError:
continue
percentual = (linhas_ia / total_linhas * 100) if total_linhas > 0 else 0
return {
"data": ontem,
"total_commits": len(commits),
"linhas_totais": total_linhas,
"linhas_assistidas_ia": linhas_ia,
"percentual_ia": round(percentual, 1),
"alerta": (
"⚠️ Acima de 70% — revise com mais cuidado, "
"risco alto de alucinação não detectada"
if percentual > 70 else "✅ Faixa saudável"
)
}
if __name__ == "__main__":
relatorio = analizar_commits_dia(
repo_path="~/code/meu-projeto",
autor="seu-email@exemplo.com"
)
print(json.dumps(relatorio, indent=2, ensure_ascii=False))
Eu rodo isso todo fim de dia. Quando vejo que passei de 70% de commits assistidos por IA, eu sei que preciso fazer code review mais rigoroso. LLM é probabilístico — em volume, alucinações aparecem. Já peguei bug crítico que passou despercebido porque o código “parecia certo”.
Erros Comuns que Eu Vejo Devs cometendo com a Promessa de IA
1. Aceitar prazo menor sem renegociar escopo
Esse é o erro clássico. Gerente te dá uma semana pra fazer o que antes levaria três. Você aceita porque “agora tem IA”. Mas o escopo era baseado na velocidade antiga. Se você entregar em uma semana, o gerente entende que o escopo era pequeno e adiciona mais. Na próxima sprint, são cinco features em uma semana. Três sprints depois, você está no burnout.
Como evitar: quando aceitar prazo menor, formalize o que está sendo cortado. “Vou entregar X em uma semana, mas Y ficou para a próxima sprint”. Em Jira, Linear, seja lá o que você usa — registre.
2. Confiar cegamente em output de LLM em código de produção
Vi PR ser aprovado em produção porque “o teste passou”. Mas o teste também foi gerado pela IA. Garbage in, garbage out. O dev revisou pouco porque “a IA nunca erra isso”. Spoiler: erra sim, principalmente em edge cases, timezone handling, e concorrência.
Como evitar: trate todo código gerado por IA como código de estagiário talentoso mas inexperiente. Revisão obrigatória. Pelo menos um humano que não seja o autor original precisa ler antes de mergear.
3. Não medir o impacto real
“Estou 50% mais produtivo” é frase de vendedor. Sem métrica, é achismo. Você sente que está mais rápido, mas talvez esteja apenas percepcionando velocidade enquanto entrega a mesma coisa. Ou pior: está mais rápido em tasks triviais mas mais lento em tasks complexas porque passa tempo revisando IA.
Como evitar: meça. Use o script acima, ou similar. Compare sprint atual com sprint anterior em throughput entregue (não linhas de código). Se não subiu, a IA não está te ajudando tanto quanto você pensa.
4. Ignorar o custo de inference
Cada chamada de LLM tem custo. Em escala, é o que mata startup. Mas também é o que mata a sanidade de dev solo que fica iterando prompts 50 vezes para “achar o output perfeito”. Gastei US$ 40 em um fim de semana testando agent que não funcionou. Tempo e dinheiro jogados fora.
5. Pular o aprendizado fundamental
Esse é o pior. Dev júnior que aprende a usar Copilot antes de aprender a programar direito. Quando o prompt engineering falha (e falha), ele não tem base para resolver. Vira dependente da ferramenta. E quando a ferramenta muda de API, de modelo, de provider — ele fica perdido.
Como evitar: aprenda o fundamento primeiro. IA é amplificador, não substituto. Quem não sabe programar, não vai virar programador com IA. Vai virar digitador de prompt.
O que a Semana de 4 Dias Realmente Exige (e Por que IA Não Garante)
A semana de quatro dias que a OpenAI propôs é uma ideia antiga, anterior à IA generativa. Países como Islândia, Nova Zelândia e Reino Unido já testaram. Os resultados são positivos, mas dependem de algo que IA não entrega: decisão de gestão de reduzir horas.
IA entrega capacidade. Política empresarial decide o que fazer com ela. Se a cultura é “mais vale mais”, IA vira acelerador de burnout. Se a cultura é “qualidade sobre quantidade”, IA vira aliada de uma semana de 4 dias. A ferramenta é neutra. A cultura que define o resultado.
Eu já trabalhei em empresas onde a ferramenta era mesma (GitHub Copilot, lançado em 2021) e o resultado foi completamente diferente. Em uma, o time saiu às 17h. Em outra, dev dormia no escritório. Mesma IA. Cultura oposta.
FAQ — Perguntas que Todo Dev Faz Sobre IA e Carga Horária
IA realmente torna o dev mais produtivo ou é só hype?
Depende do tipo de task. Para boilerplate, testes repetitivos, refactor mecânico — sim, IA entrega ganho real de 30-50%. Para arquitetura de sistema, design de API, debug de produção complexo — o ganho é marginal. Onde IA mais brilha é no trabalho que você já sabe fazer bem. Onde você é júnior, IA pode até atrapalhar porque você não sabe validar o output.
Vale a pena pagar Copilot/Cursor sozinho se a empresa não oferece?
Na minha experiência, sim, se você já tem disciplina para usar direito. Custa US$ 10-20/mês. Em uma hora que ele economiza, já pagou o mês. Mas se você é do tipo que fica horas testando prompt sem objetivo, é dinheiro jogado fora. Compre se você vai usar com constância, não por curiosidade.
Devs vão ser substituídos por IA?
Devs que só sabem escrever código repetitivo, sim. Mas isso já estava acontecendo antes de LLM — com frameworks, com low-code, com outsourcing. O que IA acelera é o mesmo processo. Devs que resolvem problemas de negócio, que entendem arquitetura, que conseguem traduzir需求 de produto em código — esses estão valorizados. A IA ainda não sabe conversar com stakeholder para entender o que precisa ser construído.
Como evitar burnout em time que usa IA intensamente?
Três regras que funcionam: (1) limite de 4 horas de trabalho síncrono por dia, o resto é deep work; (2) nenhuma reunião de status — texto assíncrono; (3) sexta-feira é sagrada, sem deploy, sem on-call se possível. IA ajuda mas não substitui fronteira de tempo. Você precisa impor.
Qual a melhor forma de começar a usar IA no trabalho sem virar refém?
Comece pequeno. Pegue uma task mecânica e tediosa que você faz toda sprint. Use IA para ela. Meça o tempo. Se for mais rápido, repita. Se não for, descarte. Em duas semanas você vai ter uma lista pessoal de onde IA ajuda e onde atrapalha. Essa lista vale ouro.
Minha Conclusão Honesta
IA não vai te dar uma semana de quatro dias. Se alguém te prometeu isso, mentiu ou não entendeu o próprio negócio. O que IA dá é mais output por hora. O que você faz com esse output é decisão sua — e do seu time, e da sua empresa.
Na minha carreira, vi três ciclos de hype: cloud, mobile, agora IA. Todos prometeram “menos trabalho, mais resultado”. A realidade foi: mais trabalho, mais resultado, mais pressão. Mas também: novas oportunidades para quem soube aproveitar. IA vai criar devs melhores e devs obsoletos. A diferença não é quem usa a ferramenta — é quem pensa criticamente sobre o que ela entrega.
Se você chegou até aqui, é porque se importa em fazer isso direito. E isso, por si só, já te coloca à frente de 90% do mercado.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.