Por muitos dias nesse último ano, assim como muitos devs, amigos e relatos que ouvi, eu estava desanimado. De repente não existia mais aquela felicidade em resolver um problema que estava te travando há dias. Ou o orgulho por apresentar uma solução elegante para um problema complexo. E nem mais aquele momento de flow que te fazia pular refeições. Bastava digitar o que você queria, e um software escrevia em minutos um código que você levaria dias para fazer, às vezes até melhor.
E então a profissão ficou chata.
Não que eu não esperasse esse dia. Eu até torcia por ele, principalmente quando o pulso doía de tanto digitar. Só não imaginei que ele chegaria tão rápido, nem que viria junto com essa sensação de que o meu trabalho tinha perdido a graça.
E tinha também o terror de ler e ouvir em todo canto da internet que a sua profissão ficou defasada. Ainda que eu não acredite nisso, e tenha bons argumentos contra essa tese, é impossível essa incerteza sobre o futuro não nos afetar de alguma maneira. Afinal, foram anos investindo tempo e esforço numa carreira.
Mas será mesmo que acabou? Ou vai acabar um dia?
Bom, eu sou o Maxsuel e sou apaixonado por programação desde 2006, quando fiz meu primeiro hello world em C. Criei este diário para documentar essa mudança de forma pública: os aprendizados, as ideias e os experimentos (os que dão certo e os que não dão). Por que agora? Porque é uma mudança grande demais para passar sem registro. E olha que eu já perdi o timing. Não sei se alguma alma vai ler isso, mas, se ler, fico lisonjeado.
A minha visão não é apocalíptica nem deslumbrada. Eu a considero bem pragmática. Alguns vão dizer que estou "em processo de negação". Outros vão ter que encarar a realidade que bate à porta: o desenvolvimento de software mudou.
Até aqui, nada diferente do que todo mundo diz. O papo da vez é que "desenvolvedores vão se tornar engenheiros de produto". Eu ainda prefiro dizer engenheiro de software mesmo, absorvendo muito do engenheiro de produto.
Eu sei que alguém vai dizer que engenharia de software existe há décadas. Existe, e aliás sempre foi um dos meus assuntos preferidos. Mas durante a maior parte da minha carreira ela dividiu o tempo com digitar código, e muitas vezes perdia. Agora que a IA escreve o código, a engenharia deixa de ser uma parte do trabalho e passa a ser o trabalho.
E é por isso que eu acredito que essa profissão vai continuar em alta, apoiada em três pilares técnicos: competência, responsabilidade e inovação.
Competência porque, sim, ainda exige muito conhecimento, horas de estudo e anos de experiência para desenvolver um software de qualidade. Por mais que um Claude Opus tenha sido treinado com muito conteúdo de engenharia de software, ele aprendeu com o que já foi feito. E engenharia de software é um assunto controverso, que muda o tempo todo. Sim, temos práticas consolidadas, como testes unitários e de integração, princípios SOLID e tudo mais. Mas e se o produto for voltado a um nicho atrelado a um hardware específico? Ou for um produto que usa agentes, que ninguém ainda sabe direito como testar? Essas e várias outras situações, até algumas que nem conhecemos hoje, vão precisar de uma nova engenharia. A IA pode muito bem aplicar SOLID, escrever testes e te ajudar no processo. Mas decidir qual arquitetura adotar e como o software deve ser construído ainda exige a cabeça do desenvolvedor.
E dá para perceber quando falta esse conhecimento. Assim como a gente bate o olho e reconhece um site "com cara de IA", um dev experiente percebe quando um software foi vibecodado. Por fora, telas bonitas à primeira vista, mas que esquecem os estados de erro e de loading e ignoram padrões que todo mundo já conhece. Por dentro, o mesmo problema resolvido de três jeitos diferentes, validação só no front-end, API keys expostas e rotas sem checagem de permissão. E mesmo quando funciona sem falhas óbvias, falta alguma coisa. Sendo sincero, nem sempre sei explicar o que é. É um feeling. Mas esse feeling tem nome: experiência.
Aqui entramos no segundo ponto, a responsabilidade. E, para explicar, começo pelo que não vai mais precisar de um engenheiro. Eu acredito fortemente que boa parte das features vai vir dos próprios usuários, e que os softwares vão se corrigir sozinhos. Imagine um ERP em que o time financeiro precisa de um campo de observação em cada transação. Num futuro próximo, vai bastar sugerir a mudança, os colegas aprovarem, e em poucas horas ela estará disponível.
Porém, mudanças críticas ainda vão precisar de um profissional. Você não contrata um engenheiro para trocar uma porta ou instalar ganchos de rede no quintal. Você segue as diretrizes dele. Com software vai ser igual: o engenheiro define as regras, e as mudanças pequenas acontecem dentro delas. Algo que eu repeti para mim mesmo e para outros nos últimos anos é que "os softwares vão se tornar muito mais complexos do que são hoje". Um sistema legado que ninguém mais entende, um portal que apresenta dados a clientes, uma integração, ou tipos de software que nem imaginamos que podem existir: é aí que vai estar o tempo dos engenheiros. São mudanças que trazem riscos. E risco é uma palavra que se relaciona direto com responsabilidade.
Não se paga um engenheiro civil só para construir um prédio. Paga-se também para que, se o prédio cair logo depois de pronto, alguém responda por isso. É para isso que existe a ART, a Anotação de Responsabilidade Técnica: o nome de quem assina embaixo. Na engenharia de software é igual (mesmo sem CREA nem ART para nós). Alguém precisa responder por dados vazados, por falhas de segurança ou por um sistema fora do ar que pode gerar milhões de prejuízo. Alguém precisa prever esses riscos antes que virem problema e, quando eles acontecem, estar lá às 3 da manhã subindo o banco de volta e escrevendo o post-mortem depois. A IA não faz isso. E acredite: o gerente de projetos e o CEO não vão querer assumir isso sozinhos. É muito melhor pagar por um engenheiro.
E, por fim, a inovação. Com a IA como serviço, os softwares estão mudando. A IA está se tornando tão essencial para algumas ferramentas quanto um banco de dados Postgres ou MySQL. Softwares que há pouco tempo achávamos impossíveis hoje existem.
E estamos só no começo. Fazendo uma analogia com a web, ainda estamos na época em que "fazíamos sites rudimentares em HTML e usávamos tabelas para o layout". A verdade é que ainda estamos longe de descobrir todo o potencial dessas ferramentas. Por isso, novos frameworks, tipos de software, ferramentas e arquiteturas vão surgir, e quem vai criá-los são os engenheiros.
Foi pensando nisso que decidi focar, nos próximos meses, não apenas em como usar LLMs para desenvolver software, mas em como usá-las para criar esses novos tipos de software. Softwares que se adaptam com facilidade, que se corrigem a cada alerta do New Relic ou do AppSignal, e que crescem e escalam bem. Na minha visão, saber integrar LLMs, criar um RAG e desenvolver agentes dentro de um sistema vai ser como saber desenvolver para a web foi nos últimos 20 anos. E pretendo contar aqui o que eu aprender (e errar) pelo caminho.
Também não é a primeira vez que a área muda desse jeito. Tenho 15 anos de experiência profissional, mas programo há 20, e já vi muitas mudanças assim. Vi cargos surgindo e sendo extintos, tecnologias adotadas em massa e logo depois abandonadas, e o mercado amadurecendo. Quem está na área há 30 ou 40 anos já viu muito mais.
E não acredito que isso vá acabar com a profissão. A demanda por software parece infinita, mesmo com a IA. Se um time passa a entregar o dobro, o software não fica pronto mais cedo: ele ganha mais features, mais integrações e passa a atender mais situações. Num mercado tão concorrido quanto o de software, quem sai na frente? Quem enxugou o time de engenheiros para um só, ou quem manteve o time e levou o produto a outro patamar? Nem toda empresa vai fazer essa escolha, e em alguns lugares os times vão encolher, sim. Também não nego que a régua para quem está começando subiu: vai exigir muito mais formação e conhecimento técnico do que exigia quando eu comecei. Mas eu penso que a complexidade do que construímos vai dar um salto, assim como nos anos 90 ninguém imaginava os sistemas que temos hoje. Para mim, a IA é uma revolução do mesmo tamanho que trocar o assembly por linguagens de alto nível e o surgimento da web, tudo ao mesmo tempo.
Essa é a realidade: a era de escrever código está acabando, e não adianta chorar por não "escovar bits" mais. E o que resolveu meu desânimo, no fim, foi justamente começar a usar IA nos meus projetos pessoais. Eram muitos projetos abandonados no meu GitHub, porque eu gastaria semanas só para fazer algumas telas. Nesses últimos dias, o que eu me vi fazendo foi pensar mais na engenharia: planejar o futuro do software e tomar decisões técnicas, em vez de digitar mais um bloco <div>.
E sinceramente? Eu achei isso maravilhoso.