Pedi para um agente de IA fazer uma reforma grande em um software.
Achei que ia terminar em alguns minutos, mas no GitHub os commits foram se acumulando, os testes também, o código de integração também, e horas depois ele ainda estava atualizando código de verdade.
Nesse meio-tempo, eu resolvi outras coisas e até terminei a mudança de casa.
Um evento da vida humana acabou antes, e a IA ainda está refatorando (reorganizando o código por dentro).
Só pela cena, já parece bem futurista.
E o aparelho que usei para dar as ordens é um celular. Eu mesmo não entendo direito de TypeScript, de CI/CD (a esteira automática que testa e publica o código) nem de otimização de links internos. Mesmo assim, bastou passar em português o objetivo, as regras a respeitar, as mudanças permitidas, as proibidas e a condição de checagem final. A IA leu o GitHub, projetou a solução, escreveu o código, acrescentou testes, abriu o pull request (PR, o pedido de revisão de uma mudança) e levou tudo até a integração.
Então isso significa que "virei engenheiro sênior com um celular só"?
Em parte, não. Em parte, e bastante, sim.
1. O celular não está fazendo cálculo de nível sênior
Primeiro, vamos organizar as ideias.
Não é o aparelho que está cuspindo 900 linhas de código. O celular é um controle remoto do centro de comando.
Nos bastidores estão conectados o modelo de IA, o GitHub, o CI, a nuvem, o ambiente de produção, buscadores e várias ferramentas. O celular é só a interface em que eu digo "o que precisa ser alcançado".
Então, para ser exato, não é que eu desenvolva com um celular só. É que eu junto, a partir de um celular, recursos remotos de inteligência, computação e desenvolvimento.
O celular de antigamente era telefone e navegador. O de hoje, bem usado, é uma "pequena sala de reunião da diretoria mais uma sala de comando de desenvolvimento".
Não colocaram um data center no meu bolso.
Agora eu consigo acionar um data center e agentes de dentro do bolso.
2. Por que este trabalho foi "mais para sênior"
A dificuldade não se mede só pelo número de linhas de código.
Numa reforma como esta, não basta acrescentar uma função.
- Ler a arquitetura que já existe
- Não implementar duas vezes um mecanismo parecido
- Não quebrar o caminho de produção em funcionamento
- Entender os limites entre agendador de tarefas, GitHub, CI e publicação
- Conectar a nova lógica de decisão ao laço central já existente
- Proteger dados pessoais e privacidade
- Não confundir amostra pequena ou dado faltando com "zero"
- Acrescentar testes
- Separar se a falha vem do código ou da infraestrutura de CI
- Decidir até "o que não se deve tocar"
Isso está mais para um trabalho de ler o sistema existente e controlar até onde cada mudança se espalha do que para um júnior implementando um único ticket.
Em termos humanos, é um misto de engenheiro back-end sênior, Platform Engineer (quem cuida da base técnica que os outros times usam) e, se a pessoa também responde pelo sistema inteiro, algo entre o quase-Staff e o nível Staff Engineer.
O importante não é só "saber escrever código difícil".
O difícil é distinguir onde se pode mexer e onde mexer causa acidente.
3. Qual foi o tamanho real do trabalho
Num exemplo anonimizado de implementação, só o PR principal já tinha:
- 11 arquivos alterados
- 13 commits
- cerca de 895 linhas adicionadas
- um runtime de decisão de "germinação" (a lógica que decide quando um artigo novo começa a render visitas)
- proteção do "Article DNA" (os atributos essenciais de cada artigo)
- aprendizado a partir de logs de comportamento dos leitores
- aplicação limitada na otimização de links internos
- testes
- uma definição de CI exclusiva
E não parou aí.
Depois da integração do PR, vieram mais ajustes: uma trava (gate) para que o aprendizado de comportamento não reescrevesse o grafo de links por conta própria antes da validação em produção, e uma correção para tratar telemetria ausente como UNKNOWN (desconhecido).
Ou seja, isso não é um projeto de "895 linhas escritas".
É um projeto em que primeiro se entende o sistema existente antes de escrever as 895 linhas, e depois se constrói uma jaula para que essas 895 linhas não saiam por aí causando estrago.
Quem olha só o número e diz "menos de 1000 linhas, é pequeno" cai numa armadilha clássica do mundo do software.
Dá para apagar todas as contas de um banco com 100 linhas, e dá para fazer uma calculadora com 10000 linhas.
4. Quantos dias levaria para uma pessoa
Imagine entregar a mesma responsabilidade a uma pessoa competente que está mexendo no repositório pela primeira vez.
Para uma tarefa dessa classe, não é absurdo estimar, grosso modo, de 5 a 15 pessoas-dia.
O detalhamento seria:
- Ler o código existente e as regras de operação
- Projetar a mudança
- Implementar
- Testar
- CI e identificação da causa das falhas
- Responder à revisão do PR
- Conferir o impacto em produção
"Só escrever" seria bem mais rápido.
Mas, em sistemas de produção, às vezes provar que não quebrei nada pesa mais do que o tempo de escrever.
O IPA (a Agência de Promoção da Tecnologia da Informação do Japão) publica uma explicação de que, na conversão de esforço de software, se nada for especificado, 1 pessoa-mês equivale a 160 horas, ou seja, 8 horas × 20 dias.
Por essa régua, 5 a 15 pessoas-dia dão cerca de 0.25 a 0.75 pessoa-mês.
5. Quanto custaria pedir isso a uma pessoa
Aqui não existe "preço certo". Muda muito conforme o contrato, a responsabilidade, o conhecimento prévio do sistema, a revisão e a garantia em produção.
Mesmo assim, os preços públicos dão a ordem de grandeza.
A Levtech indica, com dados de julho de 2025, que contratar um consultor de TI freelancer em tempo integral, 5 dias por semana, custa em torno de 100 a 110 man ienes (1 man = 10000 ienes) por mês.
Dividindo por 20 dias úteis, dá cerca de 5 a 5.5 man ienes por dia.
Aplicando 5 a 15 pessoas-dia, só com o trabalho direto, a conta bruta fica em cerca de 25 a 83 man ienes.
Claro que, numa contratação real, entram gerente de projeto, revisão, risco de retrabalho, gestão do contrato, garantia e lucro, então o valor pode subir ainda mais.
Por isso, achar que um trabalho assim é
"uma tarefinha de alguns milhares de ienes para uma pessoa"
não se sustenta.
Por outro lado, dizer sem mais que "a IA ganhou 80 man ienes" também é grosseiro. A velocidade de processamento, o paralelismo, a taxa de falhas, o custo de supervisão e o preço das ferramentas da IA são diferentes dos de uma pessoa.
A leitura certa é mais ou menos esta: um trabalho que, para uma pessoa, consumiria de alguns dias a algumas semanas de um profissional muito qualificado agora pode ser disparado por um indivíduo, a partir de um aparelho pequeno.
6. Se a IA trabalhou 6 horas, isso vale 6 horas de uma pessoa?
Não.
Mesmo que o agente de IA fique 6 horas seguidas em atividade, isso não equivale a 6 horas de um engenheiro sênior.
A IA
- não faz pausa
- não é chamada para reunião
- não fica presa no Slack
- não olha para o teto pensando "quem decidiu essa especificação?"
- consegue ir e voltar entre várias ferramentas em alta velocidade
Em compensação,
- pode avançar rápido com uma premissa errada
- pode interpretar mal o estado da produção
- pode confundir falha da infraestrutura de CI com falha do código
- corre o risco de ampliar por conta própria uma permissão que era vaga
- pode confundir "escrevi o teste" com "o teste realmente passou"
Por isso, o que se deve olhar não é o tempo, e sim a qualidade da mudança concluída, da verificação e da conferência em produção.
"Rodou 6 horas, que esforço" tudo bem.
"Rodou 6 horas, então são 6 horas de trabalho correto" é perigoso.
7. Quem não sabe programar perde valor?
Pelo contrário: o papel muda.
Até agora, para criar um software, mesmo sabendo o que se queria, era preciso antes aprender Git, uma linguagem, frameworks, deploy (colocar no ar) e testes.
O agente de IA reduz bastante esse atrito de implementação.
Então as tarefas realmente importantes para a pessoa passam a ser:
- o que construir
- por que construir
- o que nunca pode ser quebrado
- até onde as mudanças automáticas são permitidas
- o que conta como sucesso
- não tratar o que não foi verificado como PASS (aprovado)
- não presumir "0" quando um número está faltando
- em caso de falha, parar tudo ou isolar só a parte afetada
Em outras palavras,
"saber escrever tudo sozinho" está deixando de ser a única porta de entrada.
Isso não quer dizer que não precise entender nada.
Mesmo sem escrever o código linha por linha, quanto mais você entende o objetivo do sistema, os riscos, as dependências e o significado da verificação, melhor fica a qualidade das suas instruções à IA.
É como a carteira de motorista.
Dá para dirigir sem saber fundir um motor.
Mas não dá para dispensar saber o que significa o sinal vermelho.
8. Por que "deixar tudo com a IA" é perigoso
O pior erro no desenvolvimento com IA não é a tela de erro.
É estar errado com cara de sucesso.
Por exemplo:
- o PR foi integrado, mas não chegou à produção
- o arquivo de CI foi criado, mas o runner (a máquina que executa a esteira) nunca iniciou nenhum passo
- os dados não puderam ser obtidos, mas o sistema aprendeu como se fossem 0 registros
- a lógica nova foi adicionada, mas a antiga continuou lá e rodou em dobro
- "por segurança", a automação total foi desligada
- ou, ao contrário, em nome da "autonomia", as permissões foram ampliadas demais
E por aí vai.
Por isso, uma boa automação não é simplesmente "avançar sozinha".
É, mesmo avançando sozinha, separar o que é fato do que não foi verificado.
É aí que está a diferença entre um desenho de operação de nível sênior e uma automação feita só no impulso.
9. Como delegar pelo celular com menos risco de acidente
Mais forte do que decorar termos técnicos longos é seguir esta ordem.
Fixe o objetivo primeiro
Em vez de "edite este arquivo", entregue "o que precisa funcionar no fim para eu considerar um sucesso".
Escreva as invariantes (o que não pode mudar)
Deixe explícito o que não pode ser quebrado: funções existentes, dados pessoais, uso de imagens, o caminho de produção, SEO, condições de publicação.
Deixe as permissões claras
Detalhe coisas como: pode sobrescrever, pode abrir PR, pode fazer o merge (integrar à versão principal), não pode alterar a produção.
Faça ler o estado atual antes
Dê prioridade ao main atual (a versão principal do código), ao runtime real e ao estado público real, e não a conversas antigas.
Inclua a verificação na entrega
A condição de conclusão não deve ser "escrevi o código", e sim "conferi testes, CI e a leitura de volta da produção".
Permita o UNKNOWN
Não force à base da pancada em PASS ou FAIL aquilo que não se sabe.
Só isso já aproxima uma instrução dada pelo celular de um "contrato de operação", e não de um simples "por favor".
A tela do celular é pequena.
Mas a responsabilidade pela especificação não encolhe junto.
10. Conclusão: o que está quebrado talvez não seja o celular, e sim a barreira de entrada
Uma pessoa que não consegue escrever código avançado roda, do celular, um agente de IA por várias horas e integra ao GitHub uma reforma que inclui decisões de design de nível sênior.
Alguns anos atrás, essa frase soaria bem estranha.
Hoje, se as condições estiverem certas, isso de fato acontece.
Mas daí concluir que "não precisa mais de engenheiro" é precipitado.
O mais exato é ver que parte da engenharia está migrando da capacidade de implementar à mão para o desenho, as restrições, a verificação e a divisão de responsabilidades.
A IA não faz o valor desaparecer.
O valor muda de lugar.
E talvez a maior mudança seja que quem antes parava no "tecnicamente eu não consigo"
agora pode participar já a partir de "então, o que devemos construir?"
Num mundo em que a mudança de casa já acabou e a IA ainda está escrevendo código, desenvolver software, pelo menos, deixou de ser só "sentar na frente do computador e digitar tudo sozinho".
O celular é só uma tábua.
Mas essa tábua virou um controle remoto que chama recursos de desenvolvimento de nível sênior.
Convenhamos, isso é um pouco absurdo.
- Levtech, "Quanto custa contratar um consultor de TI? Como escolher e como reduzir custos" (última atualização em 2026-08-18). Indica, como referência para consultor de TI freelancer, cerca de 100 a 110 man ienes (1 man = 10000 ienes) por mês com dados de julho de 2025. https://levtech.jp/partner/guide/article/detail/390/
- IPA, "Perguntas e respostas frequentes sobre a série Livro Branco de Dados de Desenvolvimento de Software". Explica que, na conversão de esforço, se nada for especificado, 1 pessoa-mês = 160 pessoas-hora (8 horas × 20 dias). https://www.ipa.go.jp/archive/publish/wp-sd/qa.html
