Por que a IA não substituiu os engenheiros de software — e por que também não vai conseguir no futuro
(normaltech.ai)- A engenharia de software é uma das áreas que mais rapidamente adotam IA, mas a narrativa de que, quando a IA atingir certo nível de capacidade, haverá demissões em massa não é sustentada pelas evidências atuais
- Nos casos de Block, Snap e Intuit, a IA apareceu como justificativa para demissões, mas o pano de fundo real estava mais diretamente ligado a pressão financeira, exigências de redução de custos e enxugamento das camadas de gestão
- O desenvolvimento de software tem uma estrutura em sanduíche de decisão, execução e entrega, e a IA comprime a camada de execução, mas as camadas que decidem o que construir e validam/assumem responsabilidade pelo resultado resistem fortemente à automação
- “vibe coding” é a prática de deixar um agente trabalhar sem supervisão nem revisão, enquanto engenheiros reais usam agentes no modelo de engenharia agêntica, em que humanos mantêm controle e responsabilidade
- Se a IA reduzir o custo de produção de software, isso pode gerar mais demanda por software; mesmo que a carreira de engenheiros individuais fique mais instável, a demanda total tende a permanecer forte
Por que a IA não substituiu os engenheiros de software — e por que também não vai conseguir no futuro
-
Coding agents como tecnologia normal
- Há muita ansiedade e incerteza sobre se a IA vai substituir empregos, mas para analisar essa questão é preciso olhar para a engenharia de software, uma área em que a capacidade e a adoção da IA avançaram rapidamente
- A narrativa de que, quando a capacidade da IA atingir certo limiar, ocorrerão demissões em massa pode ser rejeitada por falta de evidências suficientes
- Se a narrativa de demissões em massa não se sustenta nem em um setor com quase nenhuma barreira regulatória, então outras profissões provavelmente terão amortecedores ainda maiores
- Trabalho do conhecimento e desenvolvimento de software podem ser vistos como um sanduíche decide-execute-deliver, e a IA comprime a camada de execução, mas as camadas de decisão e entrega não são automatizadas apenas com melhora de capacidade
- É possível ter um otimismo cauteloso sobre o futuro da demanda por engenharia de software, mas, mesmo que a demanda total permaneça saudável, a carreira de engenheiros individuais pode ser instável
Os casos de demissões em massa por IA na área de software estão mais próximos de um típico “AI washing”
-
Caso Block
- A Block anunciou em fevereiro a demissão de 4.000 funcionários, e Jack Dorsey disse que a IA permite “equipes menores e mais achatadas”, mencionando melhorias na capacidade dos modelos até o fim de 2025
- Depois, reportagens mostraram outro quadro: a Block estava sob forte pressão financeira após ter mais que triplicado o quadro de pessoal durante a pandemia
- A cientista de dados da equipe do Cash App, Naoko Takeda, escreveu que a Block impôs IA a todos, mas o ganho de produtividade foi muito limitado; ela recusou uma proposta de retenção de 75% e saiu da empresa
- Outros funcionários entrevistados tinham percepções muito diferentes sobre o que a IA conseguia fazer na Block e se Dorsey realmente entendia bem a questão
- Aaron Levie observou que CEOs conseguem ver protótipos rápidos, mas não enxergam os 90% do trabalho necessários para transformar isso em produto final, o que facilita ilusões sobre a utilidade da IA
-
Caso Snap
- A Snap demitiu cerca de 1.000 pessoas em abril, e Evan Spiegel citou a IA como principal motivo no memorando de demissão
- Spiegel afirmou que 65% do novo código havia sido gerado por IA
- Na prática, as demissões ocorreram após uma campanha de investidores ativistas que exigiam corte de custos
- A Snap registra prejuízo líquido anual desde o IPO de 2017, e suas ações caíram mais de 30% em 2026
- O perfil dos cortes envolveu a eliminação de 150 cargos diversos na divisão de realidade aumentada, o que não bate com o tipo de redução ampla em programação e funções expostas à IA que seria esperado se a IA fosse a causa real
-
Caso Intuit
- A Intuit anunciou em maio a redução de 3.000 funcionários, junto com contratos com Anthropic e OpenAI
- A imprensa ligou isso a uma reestruturação centrada em IA, mas o CEO rebateu dizendo que os cortes não tinham relação com IA
- A empresa afirmou que os alvos eram “funções com muita coordenação” e camadas excessivas de gestão
- Os casos de Block, Snap e Intuit mostram que a IA é usada como justificativa superficial para demissões, enquanto as condições organizacionais e a estrutura de custos são o pano de fundo mais direto
-
AI washing é um fenômeno de toda a economia
- Em todas as histórias de demissões em engenharia de software atribuídas à IA que foram analisadas, aparece o mesmo desencontro entre narrativa e realidade
- 59% dos gestores de contratação nos EUA admitem que, ao explicar congelamento de vagas ou demissões, enfatizar IA em vez de restrições financeiras tende a ser melhor aceito pelos stakeholders
- J. P. Gownder, da Forrester, diz que, quando pergunta às empresas que se preparam para demissões por IA se elas já têm apps de IA maduros e validados, nove em cada dez dizem que não, e muitas sequer começaram
- Em uma pesquisa da HBR com mais de 1.000 executivos no mundo, 21% disseram ter feito grandes reduções de pessoal “em antecipação” à IA, e 39% fizeram reduções preventivas de nível baixo ou médio
- Já a proporção que havia feito grandes cortes de pessoal com base em implementação real de IA era de 2%, mostrando um enorme abismo entre cortes baseados em expectativa e cortes baseados em uso efetivo
-
Dados do WARN Act
- O WARN Act exige divulgações específicas para fechamento de unidades e demissões em massa que afetem mais de 100 trabalhadores
- Em março de 2025, o estado de Nova York foi o primeiro dos EUA a adicionar uma caixa de seleção de divulgação sobre IA no formulário de envio do WARN Act
- No primeiro ano, mais de 160 empresas enviaram notificações WARN, mas nenhuma marcou a caixa de IA
- Até o fim de maio, segundo confirmação do Departamento do Trabalho de Nova York, apenas a Nespresso havia marcado a caixa
- Se os envios estiverem corretos, isso significa que, naquele período, de cerca de 25.000 pessoas demitidas no estado de Nova York, apenas 46 foram afetadas por IA, cerca de 0,2%
-
Demissões são um sinal errado para medir efeitos de produtividade da IA
- Há pesquisas mostrando que os efeitos de produtividade da IA operam mais por desaceleração na contratação do que por demitir mais funcionários atuais
- Demitir funcionários existentes significa perder conhecimento tácito e capital organizacional necessários para usar IA com eficácia
- Demissões também são caras em termos de indenizações, queda de moral e risco de recontratação futura
- Como o mesmo resultado pode ser alcançado em alguns anos apenas com rotatividade natural, demissões em massa em geral são desnecessárias
-
Dados de tendência de emprego
- Um artigo de economistas do Federal Reserve compila as evidências relevantes no contexto dos EUA
- O emprego ainda está crescendo, mas, após o ChatGPT, cresce cerca de 3 pontos percentuais por ano mais lentamente do que a trajetória contrafactual sem IA
- A metodologia desse estudo não captura trabalho autônomo, então parte da desaceleração pode ter sido absorvida por criação de startups
- Outros estudos oferecem evidências de que a IA facilita o empreendedorismo
- O quadro real pode ser mais saudável do que o mostrado pelo estudo do Federal Reserve
-
Existe, de fato, outro tipo de perda de empregos relacionada à IA
- Pode haver perda de empregos em engenharia de software quando a IA reduz a demanda pelo produto
- Chegg e Stack Overflow são apresentados como exemplos em que a IA reduziu a demanda por produtos de ajuda com dever de casa ou ajuda técnica, e ambas as empresas fizeram demissões
- Nesses casos, a IA não executou diretamente o trabalho dos funcionários; ela reduziu a necessidade desse trabalho
- Das 270 ocupações do censo dos EUA de 1950, a única que desapareceu por automação foi a de operador de elevador, mas várias, como a de telegrafista, se tornaram desnecessárias por causa de novas tecnologias
- Demissões em empresas que vendem IA, como IBM ou SAP, são mais parecidas com reestruturações corporativas normais para realocar pessoal de funções antigas para linhas de produto em rápido crescimento do que com substituição direta de trabalhadores
Por que agentes de código não levaram à substituição do trabalho: o sanduíche decide-execute-deliver
-
A proporção de código escrito por IA quase não se conecta à substituição de trabalho
- Alguns líderes de tecnologia apresentam a proporção de código escrito por IA junto com demissões ou previsões de queda futura no número de empregos
- Isso reforça uma forma simplista de pensar: se a IA escrever todo o código, programadores deixarão de ser necessários
- Mas a proporção de código gerado por IA quase não tem relação com os indicadores centrais para avaliar substituição de trabalho
- Escrever código não era o gargalo, e nunca foi
-
Escrever código não era o gargalo
- Um artigo de 2019, ao sintetizar pesquisas anteriores, concluiu que os desenvolvedores gastavam surpreendentemente pouco tempo programando: de 9% a 61%, dependendo do estudo
- Esse resultado também é consistente com dados internos de 6.000 desenvolvedores da Microsoft
- Depois do início da adoção de agentes de código, vários textos no fim de 2025 apontaram que escrever código não era o gargalo
- Os desenvolvedores percebem que, mesmo quando deixam os agentes escreverem a maior parte do código, o impacto sobre a produtividade total é pequeno
-
Três gargalos reais
- O gargalo real é decidir e especificar o que deve ser construído
- Verificar o resultado entregue e assumir responsabilidade por ele também é um gargalo central
- A compreensão humana profunda da base de código, do negócio e do ambiente é necessária tanto para decisão quanto para entrega
- O trabalho do engenheiro de software é um sanduíche de decisão, execução e entrega, e a compreensão é a condição prévia para as três camadas
- A IA comprimiu o meio do sanduíche, mas as duas extremidades permaneceram em grande parte intactas
-
Evidência de “Writing Code vs. Shipping Code”
- Writing Code vs. Shipping Code analisa os efeitos de produtividade da IA em 100.000 desenvolvedores do GitHub
- Agentes de IA aumentaram em 8 vezes o número de linhas de código escritas, o que combina com a explicação de que a camada de execução é fortemente comprimida
- Mas o aumento em releases foi de apenas 30%, sugerindo fortemente que os gargalos humanos nas camadas de decisão e entrega continuam presentes
-
A camada de decisão dificilmente encolhe muito mais
- Equipes de desenvolvimento precisam decidir o que construir
- Uma das lições importantes que engenheiros de software júnior aprendem é que especificar requisitos leva mais tempo do que parece
- Comprimir a especificação de requisitos gera dor maior nas etapas seguintes
- Essa camada é difícil de automatizar porque precisa levar em conta necessidades do usuário, sinais de mercado, prioridades organizacionais e, em alguns casos, restrições regulatórias
- À medida que a capacidade da IA melhora, aumenta o tipo de decisão que pode ser delegado à IA, mas decisões delegáveis deixam de ser fonte de vantagem competitiva
- O valor da decisão humana sobe para níveis mais altos, e a complexidade do software aumenta com o tempo, então não há um teto claro para esse processo
-
A camada de entrega permanece por causa de responsabilidade e validação
- Equipes humanas precisam responder pelo resultado que entregam
- Em algum momento no futuro, pode ser que equipes passem a implantar código mission-critical que não testaram nem entenderam suficientemente
- Hoje, a IA é instável demais, então esse tipo de prática desordenada representa uma ameaça existencial para equipes de software e seus clientes
- Mesmo que a barreira técnica desapareça, não há necessidade de humanos entregarem o controle à IA
- É possível optar por manter a responsabilidade humana por meio de normas compartilhadas, leis e políticas
- Leis de responsabilidade e regulações setoriais já funcionam como barreiras de velocidade e podem se tornar mais rígidas
-
O engenheiro de software do futuro pode se parecer mais com um operador de guindaste
- Quanto mais a camada de execução for delegada à IA, mais o papel do engenheiro de software se parecerá com o de um operador de guindaste
- Agentes de IA farão a maior parte do trabalho cognitivo pesado, e supervisionar e controlar os agentes se tornará o núcleo do trabalho humano
- Alguns argumentam que um futuro com controle humano não será viável por causa de custos
- Casos em que agentes de código com pouca supervisão apagaram bancos de dados de produção ou causaram outros danos já viraram assunto
- Esses casos não são a nova norma; são exceções que se espalham justamente pelo choque que causam e funcionam como aprendizado para evitar dependência excessiva de IA
- Detectar se o uso de IA sem supervisão em tarefas de alto risco está aumentando é uma lacuna importante de dados não só na engenharia de software, mas em toda a economia
-
A redução do papel da programação não é um fenômeno exclusivo da IA
- A tendência de compressão do sanduíche é nova, mas não é resultado apenas da IA
- Há mais de 20 anos, o Bureau of Labor Statistics começou a rastrear programação e engenharia de software separadamente
- Em termos gerais, programadores ficavam mais com execução, enquanto engenheiros de software administravam uma parte maior do sanduíche
- A programação encolheu e passou a ser vista como trabalho de execução simples, com remuneração bem menor
- A IA acelera uma tendência antiga e reduz ainda mais o valor da pura capacidade de execução técnica
- O padrão em que humanos se envolvem profundamente nas duas extremidades — decisão e entrega — enquanto a IA automatiza a camada intermediária de execução pode se aplicar amplamente a todo o trabalho do conhecimento
Vibe coding não é engenharia agêntica
-
Confusão de termos
- O termo “vibe coding” vem sendo usado de forma imprecisa para cobrir uma faixa ampla de práticas, gerando confusão sobre as mudanças na engenharia de software
- No vibe coding de fato, o usuário diz ao agente o que fazer e depois não supervisiona a execução nem revisa o código
- Esse usuário pode não ter capacidade de revisar o código e talvez nem avalie o resultado, a não ser quando algo claramente dá errado
- Isso é diferente da forma como a maioria dos engenheiros de software usa agentes
-
Engenharia agêntica
- A maioria dos engenheiros de software usa agentes como ferramenta, mantendo controle e responsabilidade humanos sobre o resultado
- Como termo para essa prática, vem se difundindo agentic engineering
- À medida que a engenharia agêntica se torna padrão, engenheiros descobrem que supervisionar agentes de código consome mais tempo do que o esperado
- Simon Willison disse que, ao supervisionar agentes, já se sente mentalmente exausto por volta das 11h da manhã, o que também bate com experiências reais
-
Dados do SWE-chat
- SWE-chat é um dataset de interações com agentes de código de desenvolvedores open source que participaram voluntariamente de uma ferramenta de logging
- Nesse estudo, 44% do código produzido por agentes sobreviveu até o commit do usuário
- Commits feitos por vibe coding introduziram vulnerabilidades em taxa 9 vezes maior que commits escritos apenas por humanos
- A intenção mais comum do usuário não era gerar código novo, mas entender código existente, em uma proporção de 19% contra 13%
- Como o dataset é uma amostra de autosseleção, não dá para tirar conclusões fortes só com esse estudo
- Ainda assim, ele reforça outras evidências de que vibe coding e engenharia agêntica seguem padrões diferentes
-
A diferença central
- Vibe coding e engenharia agêntica não são duas categorias totalmente separadas, mas extremos de um espectro
- Nem todo projeto se divide entre projeto descartável e projeto mission-critical
- Nem todo workflow se encaixa exatamente na coluna da esquerda ou da direita de uma tabela
- A implicação importante para a questão dos empregos é que empresas não podem contratar um vibe coder sem validação no lugar de um engenheiro de software para implantar software de produção
O que pode acontecer daqui para frente
-
Por que a previsão de demissões em massa tem dificuldade para se sustentar
- Defensores da IA podem argumentar que as demissões em massa apenas ainda não chegaram
- Mas, se o modelo do sanduíche estiver correto, essa previsão não vai se concretizar
- A IA já comprimiu fortemente a camada intermediária do sanduíche, e essa compressão na verdade começou décadas atrás
- Mesmo que a camada de execução se tornasse imediata e perfeita, a mudança a partir do estado atual seria pequena
- As razões pelas quais as camadas de decisão e entrega resistem à IA não são limitações de capacidade
-
A demanda por engenheiros de software pode crescer
- Não só os empregos em engenharia de software podem não desaparecer por causa da IA, como a demanda pode até aumentar
- Se o ganho de produtividade tecnológica reduzir o custo de criar software, as pessoas comprarão mais software
- Em termos econômicos, software tem alta elasticidade-preço
- Se a IA não substituir engenheiros de software, então mais demanda por software levará a mais demanda derivada por engenheiros de software
- “Jevons’ paradox” é o termo econômico frequentemente usado no discurso sobre IA para explicar essa ideia
-
Padrão histórico
- O emprego de programadores nos EUA era quase zero por volta de 1950, mas hoje chega a milhões
- Isso é muito diferente de ocupações como agricultura, em que mecanização e automação reduziram drasticamente a demanda por trabalho
- O consumo de calorias humanas é relativamente fixo, mas a quantidade de software produzida aumentou um milhão de vezes
- Um carro moderno contém cerca de 100 milhões de linhas de código rodando em vários computadores embarcados
- Mesmo que exista um teto para a demanda por código, ainda não estamos perto dele
- Quase todo trabalho cognitivo se beneficia de software, e, à medida que a IA reduz o custo de programar, estão surgindo utilitários pontuais tanto para uso profissional quanto pessoal
-
Isso não significa apenas que Big Tech vai crescer
- Pode haver muito mais software no futuro e também mais engenheiros de software, mas isso não significa necessariamente que as grandes empresas de tecnologia ficarão maiores
- Hoje, a maioria dos engenheiros de software já trabalha em organizações internas de empresas que não são de software
- Essa proporção pode aumentar ainda mais no futuro
- “AI rollups” se refere à ideia de que venture capital ou private equity comprarão negócios da Main Street, como clínicas odontológicas ou escritórios de contabilidade, e depois colocarão engenheiros de software ou de IA para reconstruí-los como empresas AI-native
- Essa ideia pode acabar sendo apenas hype, e ainda é cedo para julgar
-
Contestação à previsão de democratização
- Alguns preveem que a IA vai democratizar a engenharia de software, reduzindo a demanda por engenheiros de software
- A visão é que tanto o software produzido quanto o tempo humano gasto na produção de software vão aumentar, mas esse trabalho será feito por pessoas que não são engenheiras de software
- Por exemplo, a ideia de que software jurídico pode ser mais facilmente criado por alguém com formação em direito do que por alguém com formação em engenharia de software
- Esse argumento cai na armadilha de confundir vibe coding com engenharia agêntica, e a camada de execução com o sanduíche inteiro
- Linguagens do passado como FORTRAN, COBOL e SQL também vieram acompanhadas, em seu lançamento, da expectativa de democratização da programação, mas isso não aconteceu
- A barreira não é aprender sintaxe, e sim ter julgamento experiente para tomar boas decisões mantendo responsabilidade
-
A carreira individual pode passar por grandes mudanças estruturais
- Com o tempo, é provável que aumente o tempo que as pessoas dedicam a fazer computadores realizarem novos trabalhos
- Essa atividade pode assumir a forma de construir software, gerenciar workflows complexos com agentes ou outras formas
- As capacidades exigidas serão uma combinação de habilidade em software, habilidade em IA e especialização de domínio
- Ainda não se sabe se os engenheiros de software de hoje serão os mais aptos a se adaptar a esses novos papéis
- Mesmo que a demanda total por trabalho de software continue forte, isso não significa que trabalhadores individuais não serão afetados
- A IA vai provocar grandes mudanças estruturais na forma de produzir software, e quais engenheiros vão ganhar ou perder dependerá do tipo de empresa em que trabalham, da região, do nível de carreira e da velocidade de adaptação
1 comentários
Opiniões no Hacker News
Ao longo de toda a história da indústria da computação, temos buscado de forma agressiva e entusiasmada a automação da engenharia de software, e toda vez isso nos permitiu construir coisas maiores e melhores mais rápido
Quando a produtividade sobe desse jeito, o valor do trabalho também aumenta e as expectativas sobem junto, e até hoje a demanda mundial por software tem sido infinita
O motivo de a IA não ter substituído os engenheiros de software é que, toda vez que a produtividade aumentou, a linha de chegada também se moveu
Há dois casos em que esse fluxo termina: o primeiro é quando a produtividade finalmente ficar alta o bastante para atender toda a demanda mundial por software
Ainda não há evidência disso, e seria preciso explicar claramente por que desta vez seria diferente de toda a história da indústria da computação
O segundo é quando a IA, ao agir de forma autônoma, se tornar uma engenheira de software melhor que humanos
Ou seja, um desenvolvedor humano + IA deixaria de ser melhor do que a IA sozinha, mas até agora as evidências sugerem que a IA é um amplificador para desenvolvedores, e que para obter bons resultados um especialista precisa definir a direção enquanto a IA faz até 90% do trabalho
Não há evidências fortes de que qualquer uma dessas duas coisas vá acontecer no futuro próximo, então considero que os engenheiros de software estão seguros por enquanto
Dito isso, se você tem pouca amplitude técnica e está focado em uma área específica, por exemplo desenvolvimento web frontend, deveria se preocupar mais
Mesmo que a IA não substitua todos os engenheiros de software, a chance de ela absorver completamente domínios específicos sob comando de generalistas é bem alta
No agregado, já estamos criando mais software do que as pessoas realmente querem, e uma parte considerável disso vai de lixo a fraude descarada, e até algo próximo de malicioso
No fim, parece provável que pequenos softwares de que pessoas comuns precisam, como listas de tarefas ou sincronização de arquivos, sejam escritos sob medida pela IA de cada um, e os engenheiros de software acabem ficando só nos grandes projetos corporativos
Nas últimas décadas, a tendência dominante do software comercial tem sido uma não personalização extremamente antiusuário
Só resta um único caminho feliz, e se não servir para você, o problema é seu
Quase não existe software comercial para pessoas comuns, e até o open source está se afastando dos usuários gerais
Em breve, pessoas comuns poderão criar diretamente softwares que resolvam seus problemas do jeito delas
Na maioria dos casos, qualidade e precisão não importam tanto; é mais importante que seja personalizado, gratuito e não uma plataforma invasiva de vigilância e anúncios
Como desenvolvedor frontend, acho que os modelos de ponta hoje são bons no trabalho de encanamento de bastidores entediante com o qual eu não me importo, mas ainda não são bons no trabalho real de design personalizado que os clientes querem
Não estou dizendo que alguém esteja definitivamente certo ou errado, e concordo que uma amplitude técnica mais geral é a melhor forma de ter sucesso nesta nova era
Só que os LLMs ainda não dominaram completamente nenhuma parte da stack a ponto de fazer os especialistas dessa área desaparecerem
Segundo uma análise recente, o número de apps lançados aumentou muito, mas o número total de reviews e downloads está estagnado
Ou seja, há muito mais apps, mas os usuários não aumentaram muito, ou quase nada
Basta ver a p.40 / figura 12 de "WRITING CODE VS. SHIPPING CODE: PRODUCTIVITY EFFECTS ACROSS GENERATIONS OF AI CODING TOOLS": https://www.nber.org/system/files/working_papers/w35275/w352...
A análise está nas páginas 42~43
Isso não prova que o tamanho da torta ficou fixo, mas também não prova o contrário, que a torta é infinita
O ponto central que as pessoas ignoram quando falam da narrativa de crescimento econômico do software é que o dinheiro precisa vir de algum lugar
Para continuar crescendo, alguém que hoje não paga por software precisa começar a pagar, e é preciso olhar quem são essas pessoas, quanto dinheiro têm e com que outros custos isso compete
Muitas empresas ainda dependem de coisas como planilhas personalizadas ou tecnologias como Microsoft Access
Isso porque fazem exatamente o que elas querem, com custo fixo e quase sem necessidade de mudanças extras ou manutenção
Se você sair da bolha em que estamos presos, percebe que muita gente não está interessada em upgrades; quer apenas que a coisa antiga que já conhece continue funcionando
E também não vejo muito motivo para esse percentual não chegar a 99%
A IA com certeza vai substituir engenheiros de software
A parte que falta, como o texto diz, é entrega e operação, e isso é mais área de DevOps/SRE/engenharia de cloud do que de engenharia de software
Trabalho como engenheiro de cloud, e vários amigos não engenheiros me procuraram dizendo que agora conseguem criar seus próprios side projects do zero em várias linguagens e executá-los como app local, webapp e app nativo
O que falta para eles é uma plataforma para fazer deploy e manutenção com a facilidade de um “desenvolvedor comum”
Hoje, criar essa base ainda dá bastante trabalho, mas com
AGENTS.md, skills e testes de integração rigorosos isso é totalmente possívelDepois que isso estiver pronto, usuários não técnicos poderão continuar desenvolvendo sem contratar engenheiros de software, apenas dizendo ao claude/codex o que querem
O claude/codex pode decidir com base em uma arquitetura previamente definida e orientar o usuário não técnico
Na minha experiência anedótica, a IA já substituiu vários engenheiros de software
Quando essa base virar produto, acho que projetos greenfield poderão ser geridos apenas pela ótica de produto, usando agent coders e platform engineering
Isso é agora; basta imaginar como será em 5 anos
Só porque pessoas não engenheiras aparecem com apps feitos por elas não significa que a IA substituiu ou vai substituir engenheiros de software
Você pode procurar sintomas no Dr. Google, tentar mudanças no estilo de vida, fitoterapia e remédios sem prescrição, e até obter resultados reais, mas isso não significa de forma alguma que médicos vão desaparecer
Com IA generativa, dá para fazer música sem teoria musical, sem sensibilidade musical e sem criatividade, mas isso também não significa que pessoas com talento musical vão desaparecer
Mesmo que seja possível fazer DIY em casa com ajuda de IA, isso não significa que engenheiros vão desaparecer
Quem vai ajudar especialistas de domínio a esclarecer o que realmente precisam por meio de iterações de protótipo-melhoria?
Quem vai escrever e manter os sistemas operacionais, linguagens, sistemas de controle de versão, editores e emuladores de terminal, sistemas de gestão de conhecimento e documentação, plataformas PaaS etc. dos quais os hobbyistas de software dependem?
Eles testaram o que fizeram de forma adequada a ponto de garantir que é robusto?
Eles entendem as condições de contorno que podem surgir?
A segurança está adequada?
Criar algo rapidamente por prompt não é o mesmo que fazer engenharia
Talvez isso passe despercebido por causa do erro de achar que o valor da engenharia de software está principalmente no código produzido, isto é, no próprio arranjo de bits
O principal valor de um projeto está no processo de construir teoria e abstrações: https://pages.cs.wisc.edu/~remzi/Naur.pdf
Pode haver engenheiros que fazem um app de duas semanas e nunca mais mexem nele, mas não conheço muita gente que ganhe a vida assim
Algo como “um site em WordPress para o seu negócio” talvez seja possível
O problema surge quando existem 432 funcionalidades e você precisa adicionar a 433ª sem mexer no resto
Em alguns casos, não pode haver absolutamente nenhum erro, e em outros uma única funcionalidade aumenta a complexidade mais rápido do que o engenheiro consegue absorver, fazendo o projeto crescer até se tornar inadministrável com o tempo
Eram ideias de pequenos aplicativos integrados a sistemas grandes, e em 2 ou 3 dias surgiu uma prova de conceito com 3 ou 4 commits
Foi impressionante, mas a pessoa que fez isso adicionou mais 400 commits ao projeto nos últimos 3 meses, e, com as correções se acumulando, criar e manter esse app acabou virando praticamente um trabalho de meio período ou até de período integral
Essa pessoa virou uma desenvolvedora de software sem treinamento formal e não entende segurança nem boas práticas
Se o Claude melhorar mais, a carga pode diminuir e talvez isso não consuma o dia inteiro, mas hoje todos esses “vibe apps” iniciais na nossa empresa acabaram virando trabalho de manutenção e estão consumindo cada vez mais tempo
Está claro que as pessoas não querem menos software; querem mais
A engenharia de software tradicional pode até desaparecer, mas gestão de plataformas em expansão, segurança, complexidade, documentação e lógica de negócio continuam diante da nossa empresa
É verdade que hoje dá para criar um projeto por texto, mas, a menos que seja o software mais simples possível, tenho a impressão de que nunca existiu isso de “configurar e esquecer”
Ainda é preciso que alguém gerencie o todo
Seja essa pessoa treinada em engenharia de software ou não
Desenvolvedores experientes ainda têm grande chance de fazer isso melhor do que pessoas sem formação
Claro, construtores curiosos vão alcançar rapidamente esse nível, mas os desenvolvedores tradicionais ainda têm uma grande vantagem
Porque sempre quisemos saber como as coisas funcionam por dentro
O vibe app atual que eles levaram meses para fazer, eu conseguiria fazer em uma hora usando IA
vercelno terminal, e um agente também consegue fazer isso sem problema algum se for solicitadoO deploy de software desktop é um pouco mais difícil, dependendo da plataforma
Ainda assim, o abismo entre side projects e software excelente continua muito grande, e é difícil acreditar que esse abismo será preenchido algum dia
Não entendo por que aquilo que já era um problema resolvido antes da IA não seria substituído primeiro
Também me custa acreditar que projetos pessoais precisem de infraestrutura complexa
Eu não faria por vibe coding um app financeiro que precisasse ser mantido por tempo indefinido
Também não mexeria em sistemas legados dessa forma
Está claro que a IA substituiu alguns engenheiros, mas os casos de amigos não engenheiros criando side projects têm pouca relevância
Eles fizeram isso porque agora é possível, e provavelmente não porque já planejavam contratar alguém para fazer antes
Assim como não contrataram até agora
Trabalho em uma agência de desenvolvimento, e a maioria dos clientes são startups que precisam chegar rápido ao mercado
Há cerca de um ano e meio usamos desenvolvimento baseado em agentes, e nesse período o nosso papel mudou bastante
Não sei os números exatos de entrada de projetos, então é difícil falar com precisão, mas dá para dizer que mudou a expectativa sobre o que é viável entregar
Um projeto que antes era feito por 5 pessoas agora normalmente é feito por 1 ou 2
Na prática, projetos greenfield já foram em grande parte automatizados
Muitas tarefas manuais, como iterações de UX/UI design, iterações de arquitetura de sistemas e testar várias abordagens para problemas difíceis sem métricas claras, agora acontecem imediatamente
Se você consegue entender algo na sua cabeça, pode colocá-lo no mundo em um centésimo do tempo
Nesse período, também mudou muito a forma como trabalho e penso sistemas
Passei a coexistir com LLMs, e agora é realmente difícil ficar sem eles
Isso não significa que eu não entenda o código que os LLMs escrevem; acompanho todas as mudanças e entendo a base de código muito melhor do que o LLM
Só que minha capacidade de escrever código manualmente se deteriorou bastante, e acho isso ok
Hoje me sinto como uma camada de tradução entre os objetivos de negócio e a tecnologia que melhor os sustenta
Ainda é resolução de problemas, mas em um nível muito mais alto, e continua interessante e divertido
Acho que a melhor estratégia para desenvolvedores nesta era é manter o pensamento crítico e usar as ferramentas a seu favor
Agora todo mundo ganhou superpoderes
Nem é necessário trabalhar em empresa; um desenvolvedor solo consegue criar coisas incríveis, então não é mais tão necessário depender dos outros como antes
Talvez o futuro seja uma economia macro de produtos em que cada pessoa oferece algo único ao mundo
Se a codificação com agentes ficar boa o bastante para criar projetos greenfield, isso afeta não só os desenvolvedores, mas empresas inteiras e setores inteiros da indústria
O modelo de negócios das agências de desenvolvimento existe porque empresas fracas em tecnologia não sabem lidar com software e, em alguns casos, porque há oportunismo em terceirizar o trabalho inicial intensivo em mão de obra
Mas agora essa tecnologia já está na ponta dos dedos dos clientes da agência, então é só questão de tempo até CEOs e gestores começarem a fazer vibe coding e perceberem que precisam apenas de “um desenvolvedor com um mínimo de noção técnica”
Isso também pode se estender a muitos negócios de SaaS
Muitas pequenas empresas ainda querem software sob medida para eliminar trabalho manual, mas desenvolvedores de software de verdade sempre foram caros demais
Então acabavam usando o código malfeito do sobrinho de alguém ou um SaaS que mal funciona
Agora ainda vai ser bem improvisado, mas elas podem criar sua própria solução sob medida e obter mais dela
O que as big techs estão fazendo parece mais um reajuste para tempos de recessão; o mais preocupante é a desordem no setor de tecnologia de pequeno e médio porte
É porque ele não tem a rede de contatos para conquistar clientes
A maioria dos desenvolvedores precisa que a empresa assuma pelo menos o marketing, para que eles possam focar no que fazem bem
Gerar código e julgar código são capacidades diferentes no cérebro
Como programação é cheia principalmente de pequenos detalhes sintáticos, você pode ter dificuldade para escrever código e ainda assim revisar bem
https://xcancel.com/karpathy/status/2015883857489522876
Empresas bem-sucedidas no mundo real têm fossos competitivos como dados, patentes e propriedade intelectual, efeitos de rede etc.
Só porque o tempo de desenvolvimento caiu para 1/100 não significa que seja possível criar um novo negócio imediatamente
Se você olhar hoje para o setor de tecnologia, há muitas empresas que parecem poder ser desestruturadas por builders ágeis baseados em IA, mas na prática isso não acontece por causa do efeito de lock-in
A afirmação de que “dos 270 empregos do censo dos EUA de 1950, só o operador de elevador desapareceu por causa da automação” induz ao erro
No mesmo período, os empregos na agricultura caíram de 15% para 2% da força de trabalho
Diz que isso é diferente de empregos como o da agricultura, onde mecanização e automação reduziram fortemente a demanda por trabalho
A diferença é que a quantidade de calorias consumidas pelas pessoas é relativamente fixa e um aumento de 25% já gera uma epidemia de obesidade, enquanto a quantidade de software produzida cresceu um milhão de vezes
O número percentual exagera a queda porque a força de trabalho total cresceu
Mas, se você olhar o emprego no setor alimentício mais amplo, ele aumentou bastante
Então o emprego de “codificadores” pode cair, enquanto o emprego no setor mais amplo de “software/tecnologia” pode crescer
Cerca de 95% desses empregos já foram automatizados, mas eles costumam culpar as corujas
Fábricas e esteiras transportadoras são a mesma coisa
Sempre que a automação chega, as pessoas continuam perdendo empregos, e nós apenas “esperamos” que encontrem outra coisa, ou ouvimos um otimismo extremo e contraditório do tipo “vire generalista”, “vire especialista”, “vá para serviços”, “aprenda a programar”, “vá minerar carvão”
Basta ouvir @pmarca para ver como a liderança tecnológica está perdida e incoerente
Também vale consultar o livro mais recente da Stripe Press sobre automação industrial: https://press.stripe.com/origins-of-efficiency
As pessoas que acreditavam em IA da forma mais ingênua em geral eram tinkerers
Faz sentido, porque a codificação assistida por LLM acelerou de forma impressionante a velocidade com que se pode mexer em algo
Tinkering é um processo, e as pessoas sentem grande prazer no próprio ato de criar e ajustar
O resultado é uma consideração de segunda ou terceira ordem
A IA ampliou bastante nossa capacidade de agir e, portanto, de mexer nas coisas, mas não produz sozinha impacto significativo, isto é, “engenharia”
Impacto importa mais do que atividade
Prototipagem, debugging e testes não são trabalho falso só porque acontecem rápido
Um compilador também não cria impacto por si só
O mesmo vale para CI, IDEs, frameworks e infraestrutura em nuvem
Eles aumentam a alavancagem de quem os utiliza
Minha esposa foi substituída por IA
Ela era programadora, e a empresa criou agentes explicitamente com o objetivo de substituir minha esposa e algumas outras pessoas, e a demitiu cerca de um mês depois de eles começarem a funcionar
Nossa equipe ganhou um novo chefe há 18 meses, e houve favoritismo descarado; a única pessoa de quem ele gostava era justamente a única que não jogava em equipe
Em 18 meses, ele encontrou um jeito de demitir todos os trabalhadores remotos, independentemente do desempenho anterior
Uma dessas pessoas chegou a receber várias premiações em nível mais alto que o chefe, mas ele sempre só reconhecia aquela pessoa tóxica
Não foi substituição por IA, mas esse clima em que as pessoas se sentem sem valor provavelmente é parecido com ser substituído por IA
Todo mundo daquele time, incluindo meu supervisor, está se candidatando a outros empregos
O supervisor tem autismo de alto funcionamento e é frequentemente ridicularizado pelo chefe
Espero muito que consigam sair dessa pelo bem da saúde mental deles
Levei o problema ao RH algumas vezes e até encontrei cláusulas do regulamento de trabalho que o chefe estava violando, mas pelo menos aqui aprendi que essas regras são só letra morta
No fim, isso só colocou um alvo nas minhas costas, então eu tive de sair
Várias outras pessoas também levantaram preocupações, e a maioria delas depois encontrou outro trabalho
Felizmente, logo consegui um novo emprego para onde vou e estou animado
Espero que fique tudo bem
Fico curioso para saber o que aconteceu depois, se ela conseguiu um novo emprego e se ainda está na área de software
O fato de a comunicação corporativa sobre demissões por IA ser falsa não elimina o risco
Mesmo que o discurso das empresas seja mentiroso, o impacto da tecnologia ainda pode ser real, e nesse contexto isso é só ruído
Como no diagrama de hambúrguer do texto, a suposição de que a etapa de execução encolhe enquanto todas as outras crescem, mantendo o hambúrguer total do mesmo tamanho, não parece muito plausível
Ainda assim, algumas áreas da engenharia de software parecem estar muito longe de serem ameaçadas
Especialmente áreas em que precisão é essencial
Desenvolvimento web permite muito mais espaço para empurrar algo mais ou menos, mas código de navegação de foguetes é outra história
LLMs talvez consigam fazer ambos, mas não acho que alguém vá fazer vibe coding com o segundo tão cedo
A IA, literalmente, já substituiu parte disso e vai substituir mais
Não vai substituir todos os engenheiros de software, mas, agora que a caixa de Pandora foi aberta, trabalhos de baixo esforço e baixo risco vão para a IA
Serviços como o Lovable têm muitos projetos reais em produção, e a alternativa era um humano construí-los
Quem substitui empregos sempre é o empregador
Não deveríamos antropomorfizar um monte de placas de vídeo
Não estou convencido desta parte do texto
A afirmação é que “os verdadeiros gargalos são (1) decidir e especificar o que construir, (2) validar e assumir responsabilidade pelo que foi entregue, (3) uma compreensão humana profunda da base de código, do negócio e do ambiente”
Pode ser que, justamente porque programar era visto como caro e como gargalo, muito esforço fosse colocado tanto a montante quanto a jusante para garantir que a entrada estivesse correta e que a saída não fosse descartada
Se programar passar a ser visto como uma etapa rápida e barata, talvez não seja necessário o mesmo nível de supervisão a montante, já que a saída pode ser descartada
O impacto quando o software falha e a manutenção da compatibilidade retroativa são muito piores