A IA escreve o código. O sistema continua sendo seu.

Hoje um modelo escreve a maior parte do código que eu escrevia à mão. Uso todos os dias e não pretendo voltar atrás. Mas tem algo no jeito como as pessoas falam disso que me incomoda: elas tratam o código como se fosse o produto. Nunca foi. O produto é o sistema, e o sistema é um conjunto de decisões sobre fronteiras, falha, dados, custo e responsabilidade. O modelo não é dono de nenhuma delas. Você é.

O código nunca foi a parte difícil

Nos projetos que auditei, as falhas que doeram raramente estavam numa função mal escrita. Estavam numa função escrita corretamente para a premissa errada. Um retry que era seguro numa leitura e catastrófico num pagamento. Um cache que funcionava bem até dois tenants compartilharem uma chave. Um consumer de fila que assumia uma ordenação que ninguém garantia. Nenhum desses é problema de digitação. Um modelo que escreve TypeScript impecável vai reproduzir cada um deles com prazer, porque a premissa mora fora do código, na cabeça de quem especificou a tarefa.

O que significa ser dono

Ser dono de um sistema é conseguir responder quatro perguntas sem abrir o editor. O que acontece quando essa dependência fica lenta? O que acontece quando isso roda duas vezes? Quem pode ver esse dado, e onde isso é garantido? Quanto custa cada unidade de trabalho com dez vezes a carga? Se você responde isso, o modelo escreve o código e você revisa contra as respostas. Se não responde, o modelo decide por você, em silêncio, e a decisão vai ser a média do que ele viu no treinamento, não a certa para o seu produto.

Onde o modelo ajuda e onde não ajuda

O modelo é excelente nas partes que já foram decididas. Dado um schema, ele escreve o repositório. Dado um contrato, escreve o client. Dada uma máquina de estados, escreve as transições e os testes. Ele é fraco, de um jeito perigoso porque parece confiante, nas partes que ainda não foram decididas: qual máquina de estados, qual contrato, quais invariantes importam, como a falha deve aparecer para o usuário. Essas partes eu ainda coloco no quadro branco antes de abrir um prompt.

Minhas regras de trabalho

• Escrevo os invariantes antes de pedir código. Se não consigo dizer o que nunca pode acontecer, não estou pronto para gerar nada.
• Todo módulo gerado passa pela revisão que o código de um júnior passaria, com atenção extra em tratamento de erro e fronteiras, porque é ali que o modelo chuta.
• Teste gerado não conta como cobertura até eu ler e tentar quebrar.
• O modelo nunca escolhe o modelo de dados, o modelo de consistência ou o modelo de auth. Ele implementa.
• Se eu não conseguiria escrever aquilo sozinho, mais devagar, não coloco em produção. Posso usar para aprender, mas não para entregar.

O teste da auditoria

Este é o teste que aplico em qualquer time que me diz que a IA escreve a maior parte do código. Escolho um módulo e peço para o engenheiro que fez o merge explicar o que ele faz sob falha parcial. Não o que o código diz, o que o sistema faz. Quando ele consegue, a IA é um multiplicador e a base de código costuma estar saudável. Quando não consegue, encontrei a falha que ninguém tinha encontrado, e ela nunca está no código. Está na posse. O modelo deu velocidade e o time gastou essa velocidade em não entender. Essa troca está disponível para todo mundo agora, e é a pior do cardápio.

Use o modelo. Use muito. Depois fique na frente do quadro branco e seja capaz de desenhar o que ele construiu, porque quando quebrar às 3 da manhã, o modelo não está de plantão. Você está.