Pedi pra IA refatorar meu código... QUEBROU A ARQUITETURA

Refatoração da IA parece arquitetura. Reduz duplicação, mas aumenta acoplamento de decisão. Nem todo lugar único é o lugar certo do código. A resposta da IA mais perigosa não é a errada — é a bonita. Parece madura, parece pensada. Mas pode estar piorando o sistema justamente por parecer convincente. Neste segundo episódio da Série 02 — Code Review com IA em sistemas críticos — analiso uma refatoração proposta pela IA pra um sistema de pagamentos com 3 fluxos (imediato, agendado e reembolso). A proposta: centralizar todas as validações numa única classe TransactionValidationService. Funciona. Está limpa. Parece organizada. O problema é arquitetural: contextos diferentes morando na mesma classe. Validação de pagamento imediato, agendamento e reembolso são pratos diferentes — e a IA juntou os 3 num chef só, com ifs por tipo de transação. Hoje 3 validações. Amanhã 10. Cada novo produto, mais um if. Mexer nessa classe vira medo no time. Aparenta organização, gera fragilidade. Mostro no vídeo a reorganização em 7 classes: 4 policies de regra (CustomerStatusPolicy, LimitPolicy, SchedulePolicy, OriginalTransactionPolicy) e 3 orquestradores por fluxo (ImmediatePaymentPolicy, ScheduledPaymentPolicy, RefundPolicy), cada um compondo só as regras que precisa. A tese central: código organizado ≠ código bem arquitetado. A IA otimiza FORMA — como o código aparece. O engenheiro otimiza ESTRUTURA — como o código evolui. Modificável é melhor que genérico. Menos hype, mais sustância. ——— 📍 CAPÍTULOS 00:00 A resposta da IA mais perigosa é a bonita 00:25 Contexto: sistema de pagamentos com 3 fluxos 01:10 O que a IA fez de certo na intenção 02:01 Onde a IA errou: contextos diferentes na mesma classe 02:43 TransactionRequest: o objeto genérico que esconde contexto 03:53 Reduzir duplicação ≠ encontrar o lugar certo 04:15 Analogia da cozinha: alho compartilha, prato não 06:21 Por que isso vira fragilidade no time 06:40 Refatoração: cada regra vira sua própria classe 07:04 CustomerStatusPolicy: o alho compartilhado 07:45 LimitPolicy: pedaço comum, mas não pra todos 07:58 SchedulePolicy: regra específica isolada 08:16 OriginalTransactionPolicy: estorno em casa própria 08:31 Os 3 orquestradores: composição, não regra 09:45 "Mas são 7 classes em vez de 1?" — a crítica justa 10:59 Aprovaria o PR? A decisão final 11:41 Código organizado ≠ código bem arquitetado 12:10 Modificável é melhor que genérico 12:22 No próximo: usar IA pra pensar, não pra decidir —————— 💬 COMENTA AQUI Onde você já viu uma refatoração que reduziu duplicação mas piorou o sistema? Pareceu organização no PR e virou acoplamento na hora de evoluir. 🔔 Se esse tipo de análise faz sentido pra você, se inscreve e acompanha a série. Aqui a gente fala de IA com menos hype e mais sustância. ——— 👤 SOBRE O CANAL O IA com Sustância é o canal de Rener Menezes — CTO no mercado financeiro, 30+ anos programando, pesquisador de IA aplicada à detecção de fraudes financeiras. Aqui falamos de IA aplicada à engenharia de software e arquitetura. Menos hype, mais sustância. #arquiteturadesoftware #refatoracao #codereview #ia #devsenior #cleancode #engenhariadesoftware #sistemascriticos