Entregar ficou rápido demais. O problema é que manter continuou custando o mesmo preço de sempre.
Tabela de Conteúdo
- O dia que a conta chegou
- A gente tá comemorando a parte barata
- Se isso quebrar às 3 da manhã, eu consigo debugar sem reabrir o chat?
- O gargalo só mudou de lugar
- O que eu faço hoje
- No fim das contas, o trabalho virou escolher
O dia que a conta chegou
Vou começar confessando uma coisa.
Teve uma feature esse ano que eu entreguei numa manhã. Uma manhã. CRUD de fórmulas de análise: o cliente queria configurar a própria conta de infestação em vez de pedir pra gente cravar no código. Migration, 4 rotas novas, uma tela de 949 linhas, e o melhor pedaço, que foi trocar 208 linhas de estratégia de cálculo hardcoded por 50 linhas chamando um avaliador de fórmula. 11h17 da manhã o PR do front tava aberto. 11h32 o do back. Fui almoçar me achando o cara.
Duas semanas depois apareceram 3 tipos de análise novos. E alguém (eu) entrou no servidor e adicionou as 3 estratégias hardcoded de volta, no mapa que o motor genérico tinha aposentado 14 dias antes. O diff parte da versão antiga do arquivo. Quem escreveu aquilo não achou o caminho novo. Não entendeu que existia um caminho novo.
27 dias depois eu voltei de novo, porque quando um tipo de análise não tinha fórmula o código fazia throw new Error(JSON.stringify({...})). Uma exceção com JSON dentro da mensagem, que o handler HTTP tinha que abrir pra saber o que dizer pro usuário. Consertar isso custou 35 linhas de código e 175 de teste. 5 vezes mais teste que código, escrevendo teste pra um caso que eu deveria ter pensado na manhã em que "entreguei".
Hoje, 5 meses depois, o arquivo tem 268 linhas e ainda carrega um comentário meu: // Keep for backwards compatibility with tests. Um mapa de 16 entradas que nenhuma linha de produção lê. Ele tá lá porque 14 asserções do teste dependem dele, e ninguém (eu) teve a tarde sobrando pra desmontar. O arquivo de teste tem 351 linhas. É maior que o serviço que ele testa.
A manhã eu economizei. Os três retornos ao arquivo, não.
Ó, e antes que alguém entenda errado: eu uso IA todo santo dia, em tudo. Não é papo de "IA é ruim" não. É outra coisa.
A gente tá comemorando a parte barata
Pensa comigo no que a IA realmente barateou.
Boilerplate, DTO, migration, aquele CRUD que você já fez 40 vezes na vida, o esqueleto de um módulo novo, entender uma lib que você nunca tinha aberto. Tudo isso ficou absurdamente mais barato e eu não quero de volta nem por decreto.
Mas repara: tudo isso é o momento em que o código nasce.
E software não passa a vida nascendo. Software passa a vida sendo lido, debugado, alterado às pressas na sexta e explicado pra alguém que entrou no time mês passado. Essa parte aí continua custando o mesmo tanto que custava em 2019. Talvez mais, porque agora tem mais código.
Então quando você olha e fala "cara, eu tô 3x mais produtivo", pode ser verdade. Mas provavelmente você tá medindo só o pedaço que já era o mais rápido do processo.
Se isso quebrar às 3 da manhã, eu consigo debugar sem reabrir o chat?
Se eu pudesse deixar uma pergunta só desse artigo, seria o título dessa seção. Faz ela antes de mergear.
Se a resposta for não, você não terminou. Você só empurrou.
Tem uma versão mais dura dessa pergunta, que é: você consegue explicar por que aquilo tá daquele jeito pra uma pessoa que nunca viu esse código? Porque se você não consegue, quem tem ownership daquele arquivo não é você. E o modelo não vai estar de plantão com você no dia do incidente, isso eu garanto.
De novo, não é pra escrever tudo na mão. É pra ler antes de aceitar. Ler de verdade, linha por linha, com o dedo na tela se precisar.
Ler 200 linhas leva uns 10 minutos. Debugar 200 linhas que você nunca leu leva um dia. Essa conta nunca mudou e não vai mudar.
E olha, tem um detalhe que eu demorei pra perceber: a IA quase nunca te devolve a solução mínima. Ela te devolve a completa. Com uma abstração que você não pediu, um parâmetro opcional "pra ficar flexível", uma interface pra um caso de uso que não existe no seu projeto. Você pediu uma função, voltou um framework.
E cada uma dessas linhas é uma linha que alguém do time vai ter que ler algum dia. Ninguém escreve isso no card, mas tá lá.
O gargalo só mudou de lugar
Essa aqui eu vi acontecer no time e demorei pra entender. E ela corta dos dois lados.
O primeiro corte é no review. A gente aumentou muito a velocidade de quem escreve e não aumentou nada a de quem revisa. Continua sendo o mesmo cérebro humano, com as mesmas 24 horas, agora com PR de 40 arquivos caindo na fila.
Aí acontece o que sempre acontece quando a fila cresce. O revisor começa a bater o olho no resumo das mudanças (o diff), ver que os testes passaram e mandar aquele "por mim tá bom" (o famoso LGTM, de looks good to me). Todo mundo aqui já fez isso, inclusive eu. Não vamos fingir que não.
Só que aí você tem código que ninguém escreveu de verdade sendo aprovado por ninguém de verdade, indo pra produção onde tem cliente pagando. E quando quebra, tem duas pessoas envolvidas e nenhuma das duas sabe o que aquilo faz.
Passar o review pra IA também não resolve. Na minha opinião, ajuda a pegar coisa boba, tipo, ajuda mesmo. Mas o review não existe só pra achar bug; existe pra pelo menos duas pessoas do time saberem que aquele código existe.
O segundo corte é no seu preço, e esse é o que mais me incomoda.
No dia em que você entrega em 2 horas uma coisa que levaria 2 dias, o prazo daquela coisa virou 2 horas. Pra sempre. Ninguém volta atrás e pergunta "opa, mas quanto disso foi porque a IA acertou de primeira e quanto foi sorte?". A régua sobe e ela não desce nunca mais.
Aí chega o problema chato de verdade, aquele que não tem resposta pronta em lugar nenhum, que exige você sentar e pensar por 3 dias. E agora você tá devendo uma velocidade que na real você nunca teve.
Se você é PJ e cobra por escopo então, pior ainda. Você acabou de deflacionar seu próprio preço e ficou com a manutenção no colo de graça. Eu entreguei numa manhã e voltei naquele arquivo 3 vezes depois. Cobrei a manhã. As 3 voltas eu paguei do meu bolso, com o meu tempo.
E é aí que eu fico travado: como é que eu continuo usando isso, que é bom demais pra abrir mão, sem entregar de graça o controle do que entra no código e o preço do meu trabalho?
O que eu faço hoje
Hoje eu atuo como desenvolvedor PJ, e eu elaborei um processo de pensamento pra me ajudar a lidar com situações como essa. Esse processo, como estou chamando, foi resultado de muitos erros que eu cometi durante o uso de IA no meu trabalho.
Eu descrevo o problema, não o código. Antes eu pedia "escreve uma função que faz X" e recebia a tal solução completa. Hoje eu falo:
- o que já existe no projeto,
- qual a restrição,
- e principalmente o que eu não quero.
Cortou muita abstração aleatória. E continuo:
Eu peço a versão pequena, explicitamente. "Faz o mais simples que resolve, sem generalizar". Você não faz ideia do tanto de código que some quando você pede isso.
A descrição do PR eu escrevo eu mesmo, do zero. O "como" pode vir gerado, tudo bem. O "por quê" é a única parte que não dá pra regenerar depois, e é justamente a que o meu eu de daqui a 6 meses vai precisar.
Se saiu um PR monstro, eu quebro. Mesmo dando trabalho. O tamanho que cabe na cabeça de uma pessoa não mudou porque a IA chegou.
E teste eu concentro onde dói. Caso feliz a IA cobre sozinha e é justamente o que menos quebra. O que quebra é falha de rede, payload torto, aquele dado legado que só existe naquele cliente antigo. É lá que mora o prejuízo.
Sobre o preço, mudou uma coisa também: eu parei de estimar código e comecei a estimar problema resolvido. Não é a manhã que eu vou passar escrevendo, é o mês em que aquilo vai ficar de pé.
No fim das contas, o trabalho virou escolher
Eu não sei se essa é a leitura certa, é o que eu enxerguei até agora mexendo com isso no dia a dia.
Mas acho que a IA não acabou com o trabalho de engenharia, ela acabou com a parte mecânica dele. E ao acabar com a parte mecânica, ela deixou exposta a parte que a gente sempre conseguiu empurrar com a barriga: entender o sistema, decidir com critério, e sustentar aquilo em produção depois.
Quem só digitava rápido perdeu vantagem. Quem consegue olhar pra 200 linhas geradas e falar "isso aqui tá errado, e o motivo é esse" ficou mais valioso, não menos. E repara no que essa pessoa tá fazendo de verdade: ela avaliou as opções e escolheu qual desvantagem ela topa carregar. O mercado chama isso de trade-off, e é literalmente o trabalho que sobrou pra gente. Generalizar agora e pagar complexidade, ou hardcodar hoje e pagar depois. Não existe escolha sem conta pra pagar, existe escolha feita com os olhos abertos e escolha feita no automático.
Velocidade de entrega é fácil de mostrar em daily. Custo de manutenção fica escondido até o dia que ele te acha.
Então gera, sim, gera bastante. Só lê o que você gerou antes de assinar embaixo.
Da comunidade para a comunidade.
Bebe água e a gente se vê no próximo artigo.
Top comments (1)
"Velocidade de entrega é fácil de mostrar em daily. Custo de manutenção fica escondido até o dia que ele te acha " - Elvis Sir