Não escrevo estas linhas como desenvolvedor em atividade.

Trabalhei muito tempo no universo do código, depois passei para o outro lado, para o Product Management. Continuo trabalhando com desenvolvedores, vejo suas restrições, suas ferramentas, seus dilemas e também o cansaço. E mesmo que o desenvolvimento já não seja minha atividade principal, não consigo deixar de me perguntar como as profissões de software vão mudar com a IA.

Este texto não é, portanto, uma verdade definitiva. É o olhar de alguém curioso, um pouco preocupado, que conheceu o código o bastante para perceber alguns sinais fracos, e que agora olha para a produção de software a partir do produto. Afinal, um Product Manager que deixa de ser curioso sobre como os produtos são fabricados provavelmente deixa de fazer bem o seu trabalho.

Há algum tempo venho testando assistentes de desenvolvimento. Gerei scripts, fiz pequenos projetos avançarem, depois trabalhei de forma mais séria em uma aplicação. E a constatação é ao mesmo tempo impressionante e inquietante: a IA consegue produzir muito, muito rápido. Em poucos dias, dá para chegar a algo parecido com uma aplicação de verdade.

Mas, durante todo esse tempo, também gastei uma energia considerável corrigindo o que ela produziu.

Não só em detalhes. Em fundamentos. Arquivos que crescem demais. Testes ausentes. Regra de negócio dentro da API. Escolhas de arquitetura complicadas demais para o problema. Soluções que funcionam agora, mas que podem ficar frágeis amanhã. O mais estranho é que, quando peço explicitamente para ela fazer diferente, ela sabe fazer. Sabe escrever testes. Sabe separar o domínio da camada operacional. Sabe propor uma solução mais simples. Sabe reconhecer que existe uma opção melhor.

Ela sabe. Mas não faz isso por conta própria.

E é aí que o assunto fica interessante.

A IA não inventou os velhos vícios do software

Vale começar sendo justo: a IA não inventou a dívida técnica. Não inventou a sobre-engenharia. Não inventou arquiteturas contraditórias, testes esquecidos, decisões implícitas, produtos mal definidos ou reformulações adiadas por tempo demais.

Tudo isso já existia.

Alguns desenvolvedores já sabiam construir uma catedral para sustentar uma prateleira. Algumas equipes já sabiam caminhar devagar direto para o buraco. Algumas empresas já confundiam velocidade de entrega com valor real. O problema do software nunca foi só escrever código. Sempre foi produzir algo que se sustenta, que se entende, que se mantém, que evolui, que atende a um uso real.

A IA, portanto, não cria um problema totalmente novo. Ela muda a escala do problema.

Ela acelera o que já ia rápido demais. Torna menos visível o que já era mal compreendido. Permite empilhar decisões mais rápido do que qualquer pessoa realmente as tomou. Dá uma aparência de maturidade a sistemas que ainda não passaram pelas etapas normais de amadurecimento.

O perigo não é a IA escrever código. O perigo é ela permitir produzir sistemas mantidos como protótipos, por pessoas que ainda não têm a experiência necessária para saber onde esses sistemas vão quebrar.

A ilusão de maturidade

O vibe coding dá uma sensação embriagante: você pede, o código aparece, a aplicação avança. Onde antes eram necessários vários dias, às vezes semanas, agora bastam algumas horas. O efeito psicológico é muito forte. Você vê telas. Clica. O sistema responde. Um banco de dados existe. Uma API roda. Funcionalidades aparecem.

O produto parece estar amadurecendo.

Mas o que realmente amadurece, às vezes, é sobretudo a superfície.

Uma aplicação pode funcionar sem ser realmente compreendida. Pode passar por alguns cenários de sucesso sem ser robusta. Pode responder bem a uma demo sem estar pronta para produção. Pode conter centenas de decisões técnicas que ninguém sabe explicar, porque foram geradas, aceitas, remendadas e depois esquecidas.

Antes da IA, parte dessa fragilidade já existia. Mas ela tinha um limite natural: a lentidão. Produzir código custava tempo. Essa lentidão às vezes forçava conversas, decisões em conjunto, revisões — momentos em que era preciso entender o que se estava fazendo antes de seguir em frente.

Com a IA, esse limite desaparece.

Dá para avançar muito mais rápido do que a própria compreensão consegue acompanhar. Isso é útil para explorar. É perigoso quando você começa a confundir exploração com produção.

Quando o erro chega tarde demais, ele para de ensinar

Boa parte da experiência técnica se constrói no erro.

Não qualquer erro, claro. Dá para sofrer muito tempo sem aprender nada. A dor sozinha não ensina. Mas, no desenvolvimento, o aprendizado profundo costuma vir de um ciclo bem concreto: você tenta, erra, procura, entende, corrige, e guarda alguma coisa dessa correção.

Às vezes você fica travado meia hora. Às vezes um dia inteiro. Às vezes não encontra a resposta no mesmo dia, volta a ela no dia seguinte, e é justamente esse desvio que cria experiência. Você aprende a reconhecer sinais fracos no código. Aprende que uma solução fácil demais costuma esconder um custo. Aprende que um bug não é só um obstáculo, mas um pedaço do sistema que resiste e pede para ser entendido.

A IA pode quebrar esse ciclo.

Quando um problema aparece, você pode simplesmente dizer: se vira, me dá uma solução. Ela vai encontrar alguma coisa. Talvez uma boa solução. Talvez uma solução horrível, mas que funciona. Nos dois casos, se você não parar para entender, avança sem aprender.

O risco não é só o erro chegar mais tarde. É ele chegar em uma escala em que já não dá mais para analisar. O sistema cresceu. As camadas se empilharam. As decisões ficaram implícitas. Os testes, quando existem, talvez validem uma compreensão errada da necessidade. E quando tudo desmorona, ninguém sabe mais dizer o porquê.

Então você remenda.

Você não entende melhor. Só coloca mais um remendo em cima de uma arquitetura que nunca chegou a habitar de verdade.

O centro do problema: o desaparecimento do primeiro degrau

Esse é provavelmente o ponto que mais me preocupa.

A questão não é só saber se a IA vai substituir desenvolvedores juniores. Essa pergunta importa, mas esconde outra, mais profunda: o que acontece se a IA substituir as tarefas que formavam os juniores?

Em muitas equipes, o aprendizado acontecia por gradação. Havia um lead, desenvolvedores experientes, perfis intermediários, e depois os juniores. Ninguém entregava de cara a um júnior a arquitetura completa de um produto crítico. Dava-se a ele tarefas pequenas. Um bug limitado. Um endpoint simples. Um script. Uma correção. Um teste. Um refactor modesto.

Essas tarefas não eram só trabalho a fazer. Eram os primeiros degraus da escada.

Elas permitiam errar sem colocar todo o sistema em risco. Permitiam aprender a ler um código já existente, entender um ticket, pedir ajuda, receber uma revisão, descobrir que uma mudança local pode ter efeitos em outro lugar. Permitiam entrar aos poucos na profissão.

E são justamente essas tarefas que a IA automatiza melhor.

Boilerplate, scripts pequenos, correções simples, testes padrão, integrações óbvias: tudo isso pode ser gerado bem rápido. Do ponto de vista da produtividade imediata, é uma ótima notícia. Do ponto de vista da formação, é bem mais ambíguo.

Se os primeiros degraus desaparecem, como alguém se torna sênior?

Dá para responder que os juniores vão aprender de outro jeito, com a IA como uma espécie de tutor socrático. É possível. Um bom uso da IA pode ajudar a explicar, comparar, fazer a pessoa verbalizar o raciocínio, gerar exercícios, simular uma revisão de código. Mas essa possibilidade exige disciplina, curiosidade e um método. Também exige que a empresa aceite pagar pelo tempo de aprendizado.

E é aí que a questão econômica fica dura.

Se um sênior potencializado pela IA produz dez vezes mais, quantas empresas ainda vão aceitar que um júnior vá dez vezes mais devagar porque precisa aprender? Quantas vão aceitar que alguém passe um dia inteiro em um problema que a IA resolveria em poucos minutos? Quantas vão preservar a lentidão necessária para a formação, quando o mercado empurra para entregar cada vez mais rápido?

O risco é quebrar o ciclo que reproduz a profissão.

As empresas de software não precisam só de código. Precisam de pessoas capazes de diagnosticar, simplificar, manter, proteger, decidir e inventar. E essas pessoas não nascem só de pilotar um assistente. Elas se constroem ao longo de anos de prática, erros, revisões, decisões difíceis e retornos da realidade.

Se a IA potencializa os seniores que já existem, mas enfraquece a formação dos juniores, ela não ameaça só algumas vagas de entrada. Ameaça a capacidade futura das empresas de software de produzir software de qualidade.

Quem vai inventar as próximas boas práticas?

Costumamos falar das boas práticas como se fossem um estoque estável. Como se bastasse documentá-las, colocá-las em arquivos de diretrizes para a IA, e depois pedir para os assistentes aplicá-las.

Mas as boas práticas não são fixas.

Elas nascem quando o terreno muda. Os design patterns clássicos responderam a um certo mundo de software. Depois vieram a nuvem, os sistemas distribuídos, o assíncrono, os microsserviços, as arquiteturas orientadas a eventos, e novos problemas surgiram. Foi preciso inventar novas formas de pensar: idempotência, retries, circuit breakers, sagas, observabilidade, resiliência distribuída.

Essas práticas não surgiram porque alguém simplesmente pediu para uma ferramenta. Nasceram de sistemas reais, de falhas, de incidentes, de migrações difíceis, de restrições operacionais, de escolhas dolorosas.

A IA provavelmente vai ajudar a formular os próximos padrões. Vai conseguir comparar soluções, identificar recorrências, documentar práticas emergentes. Mas será que consegue inventá-las sozinha, antes de o terreno tê-las tornado necessárias e compreensíveis?

Não tenho certeza.

Para inventar uma boa prática, não basta conhecer as antigas. É preciso sentir por que elas deixaram de ser suficientes. É preciso ter enfrentado a resistência do mundo real. É preciso saber quando um padrão é uma resposta elegante e quando é só complexidade desnecessária.

A simplicidade em si é uma competência sênior.

Uma IA pode propor uma solução complexa demais e, logo depois, reconhecer que uma solução mais simples é melhor, se você apontar isso. Mas alguém precisa enxergar isso primeiro. Alguém precisa dizer: esse problema não merece essa arquitetura. Alguém precisa preferir uma solução menos brilhante, porém mais adequada.

Produzir mais, para quê?

Velocidade de geração não é velocidade de entrega.

Uma equipe pode se ver com dezenas de pull requests criados durante a noite pela IA. Mas quem revisa isso? Quem verifica os impactos? Quem entende as escolhas? Quem testa os cenários mais tortos? Quem decide o que realmente deve ir para produção? Quem garante que o usuário consegue absorver essa complexidade?

Produzir mais código não é necessariamente produzir mais valor.

Existe uma tentação competitiva óbvia. Se um concorrente lança uma feature em três dias, como aceitar que uma equipe leve três meses? Se um protótipo gerado pode virar rapidamente código de produção, quem vai ter coragem de dizer: vamos parar, isso ainda não está limpo o suficiente?

Mas o software não é só uma corrida por quantidade. Um produto rapidamente fica ilegível, tanto para seus usuários quanto para suas equipes, se novas funcionalidades são adicionadas mais rápido do que o uso delas é compreendido. A complexidade não se mede só no código. Ela também aparece na adoção, no suporte, na documentação, na coerência da experiência, na capacidade da organização de explicar o que está construindo.

A IA desloca os gargalos.

O código fica mais rápido. Mas a revisão, a segurança, a definição funcional, a integração, a compreensão e a absorção humana continuam limitadas. Talvez até se tornem mais críticas.

A reconstruibilidade como critério de qualidade

No meu próprio uso recente, o que me tranquilizou não foi só ter produzido uma aplicação. Foi ter imposto pontos de ancoragem.

Insisti nos contratos entre APIs. Fiz a IA produzir os conjuntos de testes, depois a pirâmide de testes, antes de desenvolver. Tentei manter uma separação clara entre o domínio de negócio e a camada operacional. Não cheguei a aplicar um DDD completo, porque o projeto não justificava, mas não deixei a regra de negócio se espalhar pelos endpoints.

Por quê?

Porque um sistema realmente compreendido é um sistema que você saberia reconstruir.

Se amanhã eu precisar migrar essa aplicação para outra tecnologia, sei onde estão os contratos, onde estão as regras de negócio, onde estão os testes que descrevem o comportamento esperado. Nada é perfeito, mas o sistema não é só uma pilha de código gerado. Ele tem pontos de apoio. Referências. Linhas de separação.

Talvez esse seja um critério central para o desenvolvimento com apoio de IA: não perguntar só "funciona?", mas "eu saberia reconstruir isso?".

Se a resposta for não, então falta alguma coisa.

Reintroduzir a dificuldade de propósito

Não basta aprender a desenvolver com a IA. Às vezes é preciso também aprender sem ela.

Não por nostalgia. Não para defender uma visão heroica do desenvolvedor que precisa sofrer para merecer sua profissão. Mas porque uma competência que nunca encontra dificuldade fica frágil.

A gente aceita bem essa ideia em outros contextos. Na matemática, a calculadora é útil, mas aprender sem nunca fazer uma conta sozinho cria dependência. No esporte, adicionamos de propósito restrições, peso, resistência, porque é essa resistência que desenvolve o músculo.

O desenvolvimento vai precisar da mesma lógica.

Dojos sem IA. Exercícios com IA limitada de propósito. Revisões em que você precisa explicar o código sem pedir para o assistente fazer isso no seu lugar. Momentos em que você reserva um tempo, de propósito, para ler, entender, simplificar.

O objetivo não é desacelerar tudo. O objetivo é desacelerar no lugar certo.

Talvez as equipes do futuro precisem assumir um ritmo híbrido: produzir bem rápido em parte do tempo, mas reservar tempo longo para entender o que foi produzido. Um dia dedicado à melhoria contínua. Momentos sozinho com o código. Revisões de arquitetura. ADRs. Refactors lentos. Post-mortems de gerações malfeitas.

Antes da IA, esse tempo longo já faltava com frequência demais. Muitos desenvolvedores ficavam com a cabeça baixa, produzindo sem parar o suficiente para ganhar recuo e evoluir. A IA pode piorar esse problema se servir só para preencher todo o espaço ganho com ainda mais produção. Mas também pode virar uma oportunidade, se nos obrigar a separar melhor o tempo de fazer do tempo de entender.

Algumas regras simples para manter o controle

Se as equipes quiserem usar a IA sem perder profundidade, provavelmente vão precisar inventar uma disciplina explícita. Não uma burocracia. Um hábito de compreensão.

Algumas regras já parecem úteis.

Primeiro, nunca dar merge em código que ninguém consegue explicar. É simples, quase brutal, mas essencial. Se uma equipe aceita código incompreendido, ela aceita uma dívida de compreensão.

Depois, prever um pequeno orçamento de compreensão por feature: o contrato, os testes, a decisão de arquitetura, os limites conhecidos. Não uma documentação interminável. Só o suficiente para que o raciocínio continue transmissível entre pessoas.

Também é preciso ligar os testes ao comportamento real. Um teste gerado pode estar bem escrito e ainda assim validar uma compreensão errada da necessidade. O ciclo deveria ser: comportamento esperado, testes, código, retorno ao comportamento esperado. Quanto mais os testes expressam de verdade o uso esperado, mais o código tem chance de ficar próximo do valor real.

É necessário manter um mapa dos padrões aceitos pela equipe. Como se constrói uma API? Como se trata um erro? Como se escreve um job assíncrono? Como se testa uma chamada externa? Sem isso, cada feature gerada corre o risco de inventar sua própria forma de fazer as coisas, e a equipe acaba mantendo várias arquiteturas sem necessidade.

Por fim, é preciso analisar as falhas da IA. Quando ela produz uma solução complexa demais, quando esquece os testes, quando coloca regra de negócio no lugar errado, não basta só corrigir. É preciso entender o sinal que passou despercebido, ajustar as diretrizes, enriquecer as práticas.

A IA pode escrever código. Mas a equipe precisa continuar dona do raciocínio.

Entender dez vezes melhor

Não acho que o desenvolvimento de software vá afundar por causa da IA.

Acho, sim, que algumas equipes vão se afogar em código que não entendem o suficiente. Vão ter produzido rápido. Vão ter entregue coisas visíveis. Talvez até tenham impressionado o mercado por um tempo. Depois vão descobrir que velocidade não substitui arquitetura, que testes só valem se expressam a necessidade certa, que a segurança mora nos casos mais tortos, que o legado exige compreensão histórica, e que seniores não se formam removendo as tarefas que formavam os juniores.

A questão real, então, não é recusar a IA. Isso seria um absurdo. Ela já é útil demais, poderosa demais, presente demais.

A questão real é não entregar a ela os mecanismos que produzem competência.

Se a IA nos permite produzir dez vezes mais rápido, ela também deveria nos obrigar a reservar tempo para entender dez vezes melhor o que produzimos. Senão, não vamos ter só acelerado o desenvolvimento de software. Vamos ter acelerado o esquecimento do que é preciso para desenvolver bem.

Para saber mais

Code centric A qualidade pertence a quem entrega Zero bug: vamos parar de administrar estoques de defeitos