Já há algum tempo quero escrever sobre esse tema, porém evitei, porque é um assunto delicado e pode demonstrar que algumas carreiras estão próximas ao fim. Por isso, quero ser delicado, porém sem deixar de mostrar a realidade que já se apresenta bem próxima de todos nós.
Mudanças na construção de software devido à Inteligência Artificial.
Com a Inteligência Artificial, tudo o que tínhamos no passado: métricas, Acordo de Nível de Serviço (SLAs), gráficos e até mesmo os profissionais foram profundamente impactados. Eu escrevi em novembro de 2025, o texto: “Criando um Modelo de Precificação de Software com IA e Vibe Coding” no qual eu descrevi como em um trabalho solitário (ou em dupla com as IAs) levou apenas quatro dias de uma pessoa sem dedicação exclusiva para criar um modelo e um software que implementava o modelo utilizando as bases de dados da organização. Se você já teve experiência na criação de modelos e depois na implementação de sistemas, sabe que esse é um trabalho que levaria, no mínimo, alguns meses para ser construído.
Em dezembro desse mesmo ano, menos de um mês depois, escrevi o artigo: “Vibe coding acaba com o terror de integrar sua aplicação com IA”. Qual foi o pulo em menos de um mês? Em novembro, integrar uma aplicação para que as funcionalidades dela utilizassem algum modelo de IA era um “parto”. Cheio de APIs, bibliotecas e alguma burocracia. Menos de um mês depois, bastava escrever: “Integre IA à funcionalidade X para obter o resultado Y” e pronto. Sua aplicação já utilizava um modelo de IA.
A mesma coisa passou a ser aplicada ao envio de e-mail, à integração com meios de pagamento e a vários outros casos. Você digita: “Quero X” e, como se fosse mágica, seu produto passa a possuir X.
O que isso muda no desenvolvimento de software?
São praticamente três mudanças que acontecem quando você passa a utilizar a IA para o desenvolvimento de software:
- métricas,
- profissionais e
- gargalo
O que muda nas métricas?
A primeira coisa são todas as nossas métricas e os nossos gráficos. Durante anos, ensinei as pessoas a lerem gráficos de CFD, calcularem métricas como Customer Lead Time. No geral, os times que performavam muito bem levavam semanas para apresentar alguma variação, e as métricas eram medidas, no melhor dos casos, em semanas. Por exemplo: com 85% de probabilidade de entregar uma nova funcionalidade no software, era de 2 semanas.
Com IA e Vibe Coding isso não é mais verdade. Uma nova funcionalidade poderá ser desenvolvida em horas ou até mesmo em minutos.
O que muda nos profissionais? ← Ponto mais delicado do artigo
Temos que tratar o bode que já está na sala devorando o sofá. Sou desenvolvedor de software e tenho isso como paixão. É algo que eu gosto de fazer e que me faz feliz. Entretanto, as coisas estão mudando e a mudança é inevitável. Aqui é uma coisa muito minha e não tenho nenhum respaldo acadêmico para isso. Vamos a um brevíssimo histórico.
Primeiros software para suporte de Rapid Application Development (RAD)
Até há algum tempo, o que havia de mais elevado no marketing de “programação para não programadores” era o Rapid Application Development (RAD), em tradução livre, desenvolvimento rápido de aplicações. Basicamente eram aplicações em que você arrastava componentes (campo de texto, caixa de seleção, área de texto), fazia as ligações com o banco de dados e criava o software em poucos dias.
Resolvia a demanda e, rapidamente, você entregava uma solução. De fato, o low-code não era novidade; eu mesmo tentei criar páginas com o Microsoft FrontPage, cheguei a testar o também já falecido Visual Kit 5 e trabalhar com o também falecido JCompany. Além de, obviamente, entregar alguns bancos de dados MS Access.
Nessas ferramentas, você precisava saber um pouco de programação, e as ligações com as bases de dados não eram tão simples quanto pareciam. Principalmente quando você precisava de funções mais elaboradas e de infraestrutura escalável. Além disso, o código que essas ferramentas geravam era tenebroso. Se você entregasse exatamente o que elas ofereciam, seria um passeio no céu. Se você precisasse modificar algum comportamento, seria uma escalada de cabeça para baixo no inferno.
Tanto é que todas essas ferramentas morreram e não chegaram sequer em 2020.
Low-code (Baixo Código)
Low-code (Baixo código) não é uma nova técnica. Na verdade, foi repaginada no RAD. Oracle APEX, Microsoft Power Apps, Salesforce Lightning, Power BI, Metabase, entre outras. As configurações, as conexões e a grande quantidade de componentes facilitaram horrores.
Aqui ocorreu o grande ponto de alerta para todo programador. As RADs ficaram muito mais simples. Você precisa de pouquíssimo tempo para entregar soluções robustas. Precisava de alguma programação, mas já não precisava ser um especialista para resolver problemas corporativos complexos.
O que nós, desenvolvedores, fizemos?
Fingimos que o low-code não existia. Desmerecemos dele e falamos que ele não era capaz de resolver grandes problemas. Como qualquer sistema imunológico, trabalhamos para expurgar o “vírus” do low-code. Muitas vezes contrariando a lógica e a realidade.
Um usuário entregava um relatório bacana no Power BI ou uma página bem elaborada no Google Sites; nós procurávamos, pelo em ovo, para dizer que havia algo errado: “Ah! A cor do rodapé da identidade visual da empresa é #fefefe e o low-code colocou #fefeff”.
Entretanto, o carro já estava em segunda marcha.
IAs generativas, o segundo alerta para os programadores: a queda do Stack Overflow
Inicialmente, nós perguntamos às inteligências artificiais generativas (IA Gens), como ChatGpt, Gemini e, mais tarde, Claude, como resolver um problema ou implementar um trecho de código. Nesse momento, o primeiro a sentir o baque foi o lendário Stack Overflow. A comunidade era utilizada por 10 em 10 desenvolvedores. Lá, nós levávamos as dúvidas e as respondíamos. Era um local feito por desenvolvedores de software para desenvolvedores de software.
Porém, com as IAs Gens cada vez mais diretas, menos burocráticas e capazes de ler dezenas de arquivos para gerar a melhor resposta, o Stack Overflow foi perdendo relevância.
Esse foi o segundo alerta de que as coisas estavam mudando. O que nós fizemos? Mais uma vez, o sistema imunológico tenta expurgar o corpo estranho. Veja essa conversa aqui: https://meta.stackoverflow.com/questions/433615/how-can-we-stop-this-ai-decline-and-make-stack-overflow-a-popular-reliable-and-i
A pergunta é: Como podemos parar essa queda da IA e fazer do Stack Overflow uma ferramenta popular, relevante e importante para desenvolvedores novamente? Acredito que a pessoa errou a preposição. O melhor seria: Como nós podemos parar essa queda por IA… ou, melhor ainda: Como nós podemos parar essa queda por causa da IA…
Veja esse comentário:
Vou colocar a tradução aqui:
Como indivíduo, não. É necessário um esforço coletivo. Mas você certamente pode fazer parte desse esforço simplesmente estando aqui e participando.
Por que você acha que não é importante? Os LLMs consumiram (roubaram) grande parte do conteúdo do site e continuam a fazê-lo para crescer… Sem o Stack Overflow, esses LLMs estariam vomitando ainda mais alucinações do que já vomitam. Se você quer uma resposta de um especialista, o Stack Overflow e outros sites da comunidade ainda são os lugares certos; isso não mudou.
Certo ou errado, alegações verdadeiras ou falsas, o fato é que a terceira marcha já havia sido engatada. O carro está mais rápido. Veja que Thom A e user400654 estão tentando frear o carro com os próprios pés.
A primeira geração de Vibe Coding
O nome é horrível; a tradução seria algo como ‘codificar na vibração’ ou ‘codificar na vibe’ (carioquês arcaico). Se precisa de explicação para a pessoa entender a expressão, não é uma boa expressão. Fora isso, com a popularização das inteligências artificiais generativas em 2022, chegou o vibe coding.
Aqui começaram a surgir ferramentas que facilitam a codificação. O modo de autocompletar de ferramentas como o Github Copilot. Era uma maravilha: você criava a propriedade cpf na classe Pessoa, e ela já oferecia getCPF, setCPF, validarCPF e outros métodos de que você precisaria. Além de sugerir códigos internos de estruturas de decisão (if-then-else) e de repetição (do, while, for, for each…).
Esse foi um momento em que os desenvolvedores perceberam que as ferramentas de IA ajudavam no trabalho e não eram destinadas a usuários finais. Até que…
A segunda geração de Vibe Coding
Apareceram as primeiras ferramentas completas de vibe coding. Agora, você realmente não precisa saber programar. Em ferramentas Idea-to-app como Lovable, Skip, Base 44, você escreve: “Eu quero um site para gestão de entradas e saídas do botequim do Senhor Manoel.” Elas criarão um sistema completo com entradas, saídas, gestão de estoque e relatórios. O Senhor Manoel poderia criar o sistema, integrá-lo ao banco de dados, modificar seus relatórios e tudo isso sem precisar de ninguém além da própria criatividade dele.
Aí você pensa: “Mas minha empresa é uma megacorporação com escritórios espalhados por 25 países, não é o boteco do Manuel”. Para isso, você tem ferramentas de vibe coding, IDE-AI. Por exemplo, o Trae, o Cursor e, agora, o próprio Github Copilot. Como você faz: “Preciso criar um sistema de gestão de estoque na América do Sul. As tabelas no banco de dados são essas, a conexão com o banco da empresa é essa e essa aqui são as normas da identidade visual.” Assim como o Senhor Manuel recebeu a sua aplicação, você também receberá a sua conectando na base de dados da empresa com tudo que tem direito.
Particularmente, já utilizei o Trae algumas vezes e ele gera código muito, muito limpo. Inclusive ele resolveu uma luta inglória que eu sempre tive com os meus times: “Crie testes unitários para todas as classes do pacote X, Y, Z. Ignore métodos get e set. E ele cria, e a robustez da aplicação que gerou aumenta.
Engrenamos a 5ª marcha e, agora, o carro está correndo a 200 km/h.
O que muda no gargalo?
A principal consequência de tudo isso é o deslocamento do gargalo no desenvolvimento de software. Afinal, tradicionalmente, o gargalo sempre esteve no lado do desenvolvedor. back-end, front-end, baixa plataforma, alta plataforma, barramento, integração… Seja lá qual for a subdivisão, o gargalo sempre esteve nele. Após essa etapa, a segunda, mais lenta, era de testes e seus diversos nomes (validação, quality assurance (qa), qualidade, entre outros). No geral, a terceira etapa mais trabalhosa no desenvolvimento de software era o design (User eXperience (UX), design, web designers, visual, etc.).
Agora, o gargalo se desloca para a concepção do produto. A imaginação do Produteiro/Produteira (Product Owner, Product Manager, Gerente de Projetos), sua capacidade de avaliar métricas, formular novas hipóteses e pivotar o produto quando necessário passam a ser o determinante da vazão do time. O novo gargalo, afinal, as outras áreas são feitas em minutos.
Outro ponto que cria um novo tipo de gagalo é a capacidade financeira que esse Produteiro/Produteira possui. Hoje, essas ferramentas trabalham com um sistema de créditos, no qual você pode consumi-los. Se você paga bem, tem muitos créditos no mês e pode evoluir bastante o seu software. Caso contrário, vai ter que esperar pelas viradas do mês para que seu produto evolua. Mesmo assim, será um tempo muito menor do que o do desenvolvimento manual.
E agora, desenvolvedor?
Eu não faço nenhuma previsão de futuro para dizer que o trabalho de desenvolvedor acabará. Não sou mãe Diná e não estou aqui para atrapalhar a vida de ninguém.
Até o momento, percebo vantagens para os desenvolvedores de software em ferramentas de low-code ou de vibe coding. Se você sabe criar um banco de dados e conhece a estrutura de código e as bibliotecas de estilo, você pode tirar mais proveito do que alguém que não sabe. Além disso, você poderá fazer alterações pontuais e sugestões na codificação do software para deixá-lo mais limpo e mais fácil de manter manualmente.
Entretanto, seria muito irresponsável da minha parte não dar um aviso e em letras garrafais, vermelhas e, se possível, piscante igual a um site de 1995:
Ou você se adapta ou alguém adaptado vai tomar o seu lugar.
A ideia não é nova; foi popularizada por Herbert Spencer (1820-1903) na máxima:”A sobrevivência do mais apto” (survival of the fittest).
Fazendo uma retrospectiva da minha história como desenvolvedor, quando comecei na programação, consultava os manuais apostilados em papel do banco de dados Ingres (que mais tarde serviu de base para o PostgreSQL). Assim como, para codificar, você tinha que comprar livros como A Bíblia do Java, A Bíblia do Javascript, Dominando ASP NET 3 – A Bíblia (acho que a galera não sabia que a Bíblia é uma coleção de vários livros e não um livrão com um único assunto).
Depois, quando a evolução das ferramentas de desenvolvimento já não podia ser feita em papel, livros e manuais ficavam desatualizados com uma velocidade absurda. Aí vieram os sites de apoio como o Devshed (site ativo, porém vazio), DZone, mkyong (tinha até uma máxima: se o MKyong não sabe, ninguém sabe), Rose India, CodeProject, o lendário JavaRanch e seu mascote Big Moose, além do já citado Stack Overflow.
Eu conheci uma galera que não se adaptou aos sites; algumas tentaram programar em baixa plataforma e perdiam horas e horas tentando ler a documentação do JavaDocs ou da .NET documentation. Particularmente, sempre achei um trabalho pouco frutífero, uma vez que, nessas linguagens de programação, você precisa atualizar várias classes simultaneamente para que algo funcione. Consultar a documentação, classe a classe, é tedioso e pouco eficaz.
Eventualmente essas pessoas foram descartadas pelo mercado.
Daqui pra frente
As coisas evoluíram e já deixamos de usar as IAs generativas para codificar e passamos para o vibe coding.
Aqui você tem duas opções:
- Brigar para dizer que essas IAs não sabem nada, ficam alucinando e não servem para códigos sérios
- Se adaptar e passar a tirar proveito delas.
Lembrando que não optar é tomar uma opção. Não existe meio-termo nem como ficar em cima do muro.
Desenvolvedor, para onde você irá?
