Não escrevo estas linhas como desenvolvedor em atividade.

Trabalhei muitos anos no mundo do código e depois passei para o outro lado do balcão, o do Product Management. Continuo trabalhando com desenvolvedores, vejo as restrições deles, as ferramentas, as decisões difíceis e também o cansaço. E mesmo que desenvolver já não seja a minha profissão principal, não consigo deixar de me perguntar como as profissões do software vão evoluir com a IA.

Este texto não é, portanto, uma verdade definitiva. É o ponto de vista de um observador curioso, um pouco preocupado, que conheceu o código o bastante para sentir alguns sinais fracos e que hoje olha a produção de software a partir do produto. No fim das contas, um Product Manager que deixa de ser curioso sobre a forma como os produtos são fabricados provavelmente deixa de fazer bem o próprio trabalho.

Faz um tempo que venho brincando com os assistentes de desenvolvimento. Gerei scripts, fiz pequenos projetos andarem e depois trabalhei mais a sério em uma aplicação. E a constatação é impressionante e incômoda ao mesmo tempo: a IA consegue produzir muita coisa, muito rápido. Em alguns dias, dá para chegar a algo que se parece com uma aplicação de verdade.

Mas, durante todo esse tempo, também gastei uma energia enorme corrigindo essa aplicação.

Não só em detalhes. Em fundamentos. Arquivos que crescem demais. Testes ausentes. Regra de negócio colocada dentro das APIs. 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. Ela sabe escrever testes. Ela sabe separar o domínio da camada operacional. Ela sabe propor uma solução mais simples. Ela sabe reconhecer que existe uma opção melhor.

Ela sabe. Mas nem sempre faz isso por conta própria.

E é aí que o assunto fica interessante.

A IA não inventa os vícios do software

É preciso começar sendo justo: a IA não inventou a dívida técnica. Não inventou a sobre-engenharia. Não inventou as arquiteturas contraditórias, os testes esquecidos, as decisões implícitas, os produtos mal definidos nem as reconstruções que a gente adia por tempo demais.

Tudo isso já existia.

Alguns desenvolvedores já sabiam construir uma catedral para pendurar uma prateleira. Algumas equipes já sabiam caminhar devagar rumo ao precipício. Algumas empresas já sabiam confundir velocidade de entrega com valor real. O problema do software nunca foi só escrever código. Sempre foi produzir algo que se sustenta, que dá para entender, que dá para manter, que evolui, que serve a um uso real.

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

Ela acelera o que já ia rápido demais. Ela deixa menos visível o que já era mal entendido. Ela permite empilhar mais rápido decisões que ninguém tomou de verdade. Ela faz parecer maduros sistemas que ainda não passaram pelas etapas normais de amadurecimento.

O perigo não é a IA escrever código. O perigo é que ela permita produzir sistemas mantidos como protótipos, por pessoas que nem sempre adquiriram 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 inebriante: você pede, o código aparece, a aplicação avança. Onde antes eram vários dias, às vezes várias semanas, agora bastam algumas horas. O efeito psicológico é muito forte. Você vê telas. Você clica. Responde. Existe um banco de dados. Uma API rodando. Funcionalidades aparecem.

O produto parece amadurecer.

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

Uma aplicação pode funcionar sem ser realmente entendida. Ela pode passar por alguns cenários felizes sem ser robusta. Pode dar conta de uma demo sem estar pronta para produção. Pode conter centenas de escolhas 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 costumava ter um limite natural: a lentidão. Produzir código custava tempo. Essa lentidão às vezes impunha conversas, decisões, revisões, momentos em que era preciso entender o que estávamos fazendo antes de seguir adiante.

Com a IA, esse limite cai.

Dá para ir muito mais rápido do que a própria compreensão. Isso é útil para explorar. É perigoso quando começamos a confundir exploração e produção.

Quando o erro chega tarde demais, ele não ensina mais

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

Não em 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 depois guarda alguma coisa dessa correção.

Às vezes você trava meia hora. Às vezes um dia inteiro. Às vezes não resolve no mesmo dia, volta no dia seguinte, e é justamente esse desvio que cria experiência. Você aprende a reconhecer os sinais fracos no código. Aprende que uma solução fácil demais quase sempre esconde 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, dá para dizer a ela: se vira, me acha uma solução. Ela vai achar alguma coisa. Talvez uma boa solução. Talvez uma solução horrível, mas que funciona. Nos dois casos, se não paramos para entender, avançamos sem aprender.

O risco não é só o erro ser adiado. É ele chegar em uma escala em que não dá mais para analisá-lo. O sistema cresceu. As camadas se empilharam. As decisões são implícitas. Os testes, quando existem, talvez validem um entendimento errado da necessidade. E quando tudo desaba, ninguém sabe mais direito por quê.

Aí a gente remenda.

Não entendemos melhor. Só colocamos mais um remendo em uma arquitetura que nunca habitamos de verdade.

O coração do problema: o sumiço do primeiro degrau

É provavelmente o ponto que mais me preocupa.

A questão não é só saber se a IA vai substituir desenvolvedores juniores. Essa pergunta é importante, mas esconde outra, mais profunda: o que acontece se a IA substituir as tarefas que fabricavam 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 logo de cara a um júnior a arquitetura completa de um produto crítico. Davam a ele tarefas pequenas. Um bug limitado. Um endpoint simples. Um script. Uma correção. Um teste. Uma refatoração modesta.

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

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

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

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

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

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

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

Se um sênior turbinado por 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 contorna em alguns minutos? Quantas vão preservar a lentidão necessária à formação, num mercado que empurra para entregar cada vez mais rápido?

O risco é quebrar o ciclo de reprodução da 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 do simples ato de pilotar um assistente. Elas se constroem com anos de prática, de erros, de revisões, de decisões difíceis e de retornos da realidade.

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

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

Falamos muito das boas práticas como se elas formassem um estoque estável. Bastaria documentá-las, colocá-las em arquivos de diretrizes para a IA e depois pedir aos assistentes que as apliquem.

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 a nuvem, os sistemas distribuídos, o assíncrono, os microsserviços, as arquiteturas orientadas a eventos fizeram surgir outros problemas. Foi preciso inventar novas maneiras de pensar: idempotência, retries, circuit breakers, sagas, observabilidade, resiliência distribuída.

Essas práticas não apareceram porque alguém simplesmente pediu a uma ferramenta. Elas nasceram de sistemas reais, de quedas, de incidentes, de migrações difíceis, de restrições de operação, de concessões dolorosas.

A IA provavelmente vai ajudar a formular os próximos patterns. Vai conseguir comparar soluções, identificar recorrências, documentar práticas emergentes. Mas será que vai conseguir inventá-las sozinha, antes que o terreno as tenha 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 não bastam mais. É preciso ter sido exposto à resistência da realidade. É preciso saber quando um pattern é uma resposta elegante e quando ele é só complexidade inútil.

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

Uma IA pode propor uma solução complexa demais e depois reconhecer na hora que uma solução mais simples é melhor, se alguém apontar isso. Mas ainda é preciso alguém para enxergar. Ainda é preciso alguém para dizer: este problema não merece essa arquitetura. Ainda é preciso alguém para preferir uma solução menos brilhante, porém mais adequada.

Produzir mais, para quê?

A velocidade de geração não é a velocidade de entrega.

Uma equipe pode acordar com dezenas de pull requests criados durante a noite pela IA. Mas quem revisa? Quem verifica os impactos? Quem entende as escolhas? Quem testa os cenários malucos? 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 evidente. 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 a 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 fica ilegível rápido, tanto para os usuários quanto para as equipes, se adicionamos funcionalidades mais rápido do que entendemos para que elas servem. A complexidade não se mede só no código. Ela se mede também na adoção, no suporte, na documentação, na coerência da experiência, na capacidade da organização de explicar o que está fabricando.

A IA desloca, portanto, 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é fiquem 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 de interface entre as APIs. Pressionei a IA a produzir os conjuntos de testes, e 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 fazer um DDD completo, porque o projeto não justificava, mas me recusei a deixar a regra de negócio simplesmente espalhada pelos endpoints.

Por quê?

Porque um sistema realmente entendido é um sistema que saberíamos reconstruir.

Se amanhã eu precisar levar 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. Nem tudo está perfeito, mas o sistema não é só um amontoado 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 assistido por IA: não perguntar só "isso funciona?", mas "eu saberia reconstruir isso?".

Se a resposta for não, então está faltando alguma coisa.

Reintroduzir deliberadamente a dificuldade

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 sofre para merecer a profissão. Mas porque uma competência que nunca encontra dificuldade fica frágil.

A gente aceita muito bem essa ideia em outras áreas. Na matemática, a calculadora é útil, mas aprender sem nunca fazer uma conta na mão cria dependência. No esporte, adicionamos deliberadamente restrições, peso, resistência, porque é essa resistência que desenvolve os músculos.

O desenvolvimento vai precisar da mesma lógica.

Dojos sem IA. Exercícios com IA limitada. Revisões em que é preciso explicar o código sem pedir para o assistente fazer isso no seu lugar. Momentos em que deliberadamente tomamos o tempo de ler, de entender, de simplificar.

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

Talvez as equipes de amanhã tenham que assumir um ritmo híbrido: produzir muito rápido parte do tempo, mas blindar um tempo longo para entender o que foi produzido. Um dia de melhoria contínua. Momentos sozinho diante do código. Revisões de arquitetura. ADRs. Refatorações lentas. Post-mortems de geração malsucedida.

Antes da IA, esse tempo longo já faltava com frequência demais. Muitos desenvolvedores ficavam com a cabeça enfiada no trabalho, produzindo sem tomar distância suficiente para evoluir. A IA pode agravar esse problema se servir só para preencher todo o espaço ganho com ainda mais produção. Mas ela também pode virar uma chance, se nos obrigar a separar melhor o tempo de fazer e o tempo de entender.

Algumas regras simples para manter o controle

Se as equipes quiserem usar a IA sem perder profundidade, provavelmente vai ser preciso inventar uma disciplina explícita. Não uma burocracia. Uma higiene de compreensão.

Algumas regras já me parecem úteis.

Primeiro, não dar merge em código que ninguém consegue explicar. É simples, quase brutal, mas essencial. Se uma equipe aceita código que não entende, ela contrai 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. O suficiente para que o raciocínio continue transmissível entre pessoas.

Também é preciso ligar os testes à necessidade real. Um teste gerado pode ser muito limpo e validar um entendimento errado da necessidade. O ciclo deveria ser: necessidade, testes, código, volta à necessidade. Quanto mais os testes expressarem de fato o uso esperado, mais chance o código tem de continuar perto do valor.

É preciso manter um mapa dos patterns autorizados pela equipe. Como fazemos uma API? Como tratamos os erros? Como escrevemos um job assíncrono? Como testamos uma chamada externa? Sem isso, cada feature gerada corre o risco de inventar a própria maneira de fazer, e a equipe vai manter várias arquiteturas sem motivo.

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 deveríamos apenas corrigir. Deveríamos entender o sinal que passou batido, 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, por outro lado, que algumas equipes vão se afogar em um código que não entendem o suficiente. Terão produzido rápido. Terão entregue coisas visíveis. Talvez tenham até impressionado o mercado por um tempo. Depois vão descobrir que velocidade não substitui arquitetura, que os testes só valem se expressarem a necessidade certa, que a segurança vive nos casos-limite, que o legado exige uma compreensão histórica, e que os seniores não se fabricam eliminando as tarefas que formavam os juniores.

O verdadeiro desafio, portanto, não é recusar a IA. Seria absurdo. Ela é útil demais, poderosa demais, presente demais já.

O verdadeiro desafio é não entregar a ela os mecanismos que produzem a competência.

Se a IA nos permite produzir dez vezes mais rápido, então ela também deveria nos obrigar a reservar tempo para entender dez vezes melhor o que produzimos. Senão, não teremos apenas acelerado o desenvolvimento de software. Teremos acelerado o esquecimento do que permite desenvolver bem.