A IA não simplificou a engenharia de software: apenas tornou mais fácil fazer engenharia ruim

• LLM acelerou a escrita de código, mas não reduziu a complexidade essencial da engenharia de software
• À medida que gerar código ficou mais fácil, se espalhou a ilusão de que a necessidade de especialização desapareceu, e algumas organizações estão usando isso como justificativa para cortar engenheiros
• A dificuldade real não está em escrever código, mas em projetar sistemas, definir especificações, validar e manter consistência, e a IA acaba acelerando esse peso
• A incompatibilidade entre especificação (specification), testes e implementação (spec drift) está se agravando rapidamente, aumentando o risco de colapso da confiabilidade dos sistemas
• Trata-se de um padrão observado repetidamente ao longo de mais de 40 anos de carreira; na era do Visual Basic nos anos 1990, surgiu a mesma alegação de que especialização não era necessária, e no fim a necessidade de disciplina de engenharia foi reafirmada
• LLMs são excelentes ferramentas para explorar design e acelerar implementações iniciais, mas devem ser usados para reforçar, e não substituir, a disciplina de engenharia

---

O equívoco perigoso da indústria

• Agora que LLMs conseguem gerar código, o clima na indústria de software caminha para a conclusão de que a própria engenharia de software não é mais necessária
• Disciplinas como arquitetura, especificação e validação cuidadosa estão sendo tratadas como se fossem relíquias de outra era
• Em algumas organizações, essa ideia já foi incorporada à política, resultando em demissões em massa de engenheiros sob a justificativa do avanço da IA
• A IA não passa da mais nova desculpa para evitar decisões ruins de negócio ou pressões de mercado
• Inserir prompts em IA está sendo cada vez mais vendido como substituto das disciplinas que definiam a engenharia de software

Um padrão histórico que se repete

• Ao longo de mais de 40 anos de carreira, o mesmo padrão foi observado repetidamente: surge uma nova ferramenta → declara-se que os problemas difíceis foram resolvidos → a produtividade dispara e aparecem demos impressionantes → redução de equipes → aumento da complexidade dos sistemas → e, por fim, resultados muito diferentes do esperado
• As ferramentas e os discursos mudam, mas o padrão em si quase não muda

A analogia com manutenção de aeronaves

• A área de manutenção de aeronaves avançou muito em ferramentas, diagnóstico computadorizado, manuais digitais e interpretação de telemetria com IA, mas a necessidade de mecânicos qualificados continua a mesma
• Uma aeronave comercial é um sistema extremamente complexo, com milhões de peças e milhares de subsistemas interconectados
• Diagnosticar problemas não é apenas usar a ferramenta certa ou seguir um checklist, mas exige experiência e julgamento sobre como o sistema se comporta em condições reais de operação
• Nenhuma companhia aérea proporia eliminar mecânicos treinados porque as ferramentas melhoraram e entregar os reparos a atendentes de portão
• Ainda assim, a indústria de software está fazendo uma afirmação muito parecida sobre si mesma

DIY vs sistemas profissionais

• Projetos de hobby, apps pequenos de uso pessoal e experimentos com novas ideias não são problema algum; algumas das ideias mais interessantes da história da computação nasceram justamente desses experimentos
• Mas o desenvolvimento profissional de software é uma categoria completamente diferente: processar pagamentos, armazenar dados sensíveis, gerenciar infraestrutura e operar sistemas dos quais as pessoas dependem todos os dias
• Clientes naturalmente esperam que o sistema funcione corretamente, continue correto à medida que evolui e que quem o constrói entenda como ele funciona
• Essas expectativas são condições básicas da engenharia profissional, o ponto em que disciplina e especialização se tornam inevitáveis

Código nunca foi a parte difícil

• A ideia de que a parte difícil do desenvolvimento de software é escrever código é um equívoco antigo
• Digitar sintaxe sempre foi a parte menos interessante de construir sistemas; o trabalho realmente difícil é decidir o comportamento do sistema, projetar a interação entre componentes e manter a compreensibilidade à medida que a complexidade cresce
• Isso não é um problema de programação, mas um problema de engenharia
• Reduzir o esforço de produzir código não elimina esses problemas; apenas torna possível criar sistemas maiores e mais complexos mais rapidamente
• Chamar isso de ganho de produtividade é uma ilusão: o peso apenas foi deslocado para outro lugar
  • A carga cognitiva necessária para revisar código e lidar com código gerado pode ser um fator de queda de produtividade maior do que escrever código
  • Se a velocidade aumenta sem que o comportamento subjacente seja suficientemente compreendido, isso apenas acelera o momento em que a complexidade se torna inadministrável, e o resultado continua errado

Um padrão já visto: a era do Visual Basic

• Nos anos 1990, o Visual Basic também veio com promessas semelhantes: a programação teria sido democratizada e o conhecimento especializado já não seria necessário
• Na prática, o Visual Basic realmente permitiu criar muitas aplicações que de outra forma nunca teriam sido feitas
• Mas, à medida que os sistemas cresciam e se interconectavam, redescobriu-se que produzir artefatos de software e fazer engenharia de sistemas confiáveis não são a mesma coisa
• O momento atual é uma versão amplificada do mesmo padrão: a barreira reduzida não é apenas para construir aplicações, mas para produzir código em si
• É daí que nasce a crença sedutora de que especialização não é mais necessária

O problema de alinhamento

• Software confiável depende de algo quase nunca discutido fora da engenharia: alinhamento (alignment)
• Um sistema começa com uma ideia sobre seu comportamento → isso é documentado em uma especificação (specification) → engenheiros transformam a especificação em testes e código de produção
• Para a confiabilidade de longo prazo do sistema, especificação, testes e implementação precisam permanecer sempre alinhados
• Quando os três começam a se desalinhar, o sistema perde sua integridade aos poucos
  • A especificação passa a descrever comportamentos que já não são implementados
  • Os testes verificam apenas parte do comportamento e deixam o restante de fora
  • Engenheiros que entram depois tentam adivinhar o comportamento do sistema lendo código que pode ou não refletir o design original
• Com o tempo, esses palpites se acumulam e o resultado acaba sendo um sistema que ninguém realmente entende
• Esse fenômeno é chamado de "spec drift": a descrição do sistema e o sistema em si vão se separando gradualmente
  • O código mudou, mas a especificação ficou como estava
  • A especificação evoluiu, mas os testes permaneceram congelados
  • O comportamento foi mudando aos poucos até que ninguém mais consegue afirmar com segurança qual era a intenção original
• Quando o alinhamento se rompe, a confiabilidade não dura muito

A IA acelera o drift

• LLMs aceleram dramaticamente a produção de código, e isso é ao mesmo tempo sua maior força e o ponto em que o risco aparece
• Quando o código é produzido mais rápido do que a disciplina de engenharia ao redor dele consegue acompanhar, a força que cria o spec drift também acelera
• Mudanças que antes exigiam reflexão cuidadosa e implementação manual agora podem acontecer em segundos
• Seções inteiras do sistema podem ser reescritas antes que alguém verifique se o comportamento ainda corresponde à especificação
• O código em geral parece razoável, compila, é legível e pode até passar nos testes existentes, mas o alinhamento que governava o sistema talvez já tenha desaparecido
• O que parece produtividade é, na verdade, a capacidade de avançar em direção ao desalinhamento (misalignment) mais rápido do que antes

Onde a IA realmente ajuda

• LLMs não são um erro e, quando usados com critério, podem melhorar drasticamente a forma como engenheiros exploram e projetam sistemas
• Áreas em que se destacam: raciocinar sobre problemas, explorar alternativas de design, resumir sistemas complexos e gerar rascunhos que aceleram os primeiros estágios da implementação
• Áreas difíceis: tudo que exige disciplina rigorosa e consistência ao longo do tempo
• Manter o alinhamento entre especificação, testes e implementação continua sendo uma responsabilidade de engenharia, e nenhuma ferramenta pode substituir isso (embora possa ajudar)
• A verdadeira oportunidade está em usar LLMs não para substituir silenciosamente o processo de engenharia, mas para fortalecê-lo

Engenharia de software conversacional

• Uma das possibilidades interessantes abertas pelos LLMs é que parte da engenharia de software pode se tornar mais conversacional (conversational)
• Durante décadas, as ferramentas de design de sistemas foram rígidas: especificações eram documentos, arquitetura era diagrama, e o raciocínio que levava a isso desaparecia em reuniões e conversas de corredor
• Com LLMs, engenheiros podem explorar ideias de forma interativa, testar suposições e trabalhar o design de um jeito mais próximo de uma conversa natural
• Mas conversa não é engenharia: conversa é uma forma de explorar ideias; engenharia começa quando essas ideias são capturadas em uma forma verificável, testável e passível de manutenção
• O desafio das ferramentas de engenharia da próxima geração é aprender a conectar esses dois mundos sem perder a disciplina exigida por sistemas complexos

Especialização ainda importa

• Software profissional ainda precisa de engenheiros que entendam como os sistemas que constroem realmente funcionam
• Ferramentas podem acelerar o desenvolvimento, mas não eliminam a especialização necessária para projetar, raciocinar sobre e manter sistemas complexos
• A indústria está perigosamente perto de esquecer esse fato
• LLMs podem tornar engenheiros experientes muito mais produtivos, mas não substituem a disciplina de engenharia necessária para construir sistemas confiáveis
• Devemos usar essas ferramentas com eficácia, não com veneração

[GN⁺]

Comentários do Hacker News

• Não concordo com a premissa do texto. Acho que a engenharia como um todo ficou mais fácil, tanto para o bem quanto para o mal. Antes também já via muita gente enchendo tudo de checagens de null em vez de entender o problema. Agora isso só escalou em massa. Por outro lado, a engenharia excelente também foi amplificada, e já vi casos em que funcionalidades que antes levavam semanas foram feitas em poucos dias

  • Acho que o texto exagera um pouco. A boa engenharia também pode se beneficiar de agentes baseados em LLM, mas a validação do resultado ainda continua sendo responsabilidade humana. A má engenharia pula essa etapa, então, pela ótica da lei de Amdahl, os LLMs aceleram bem mais a má engenharia
  • A má engenharia ficou muito mais fácil, e a boa engenharia ficou um pouco mais fácil. Então pessoas que antes faziam boa engenharia agora conseguem fazer três vezes mais má engenharia
  • Em desenvolvimento de apps corporativos, já vi testes com mock que só verificam se retornam o valor esperado. Fico pensando que sentido isso tem
  • É fácil esquecer que LLM não é um oráculo mágico. A forma como você lida com a saída determina a qualidade do resultado. Às vezes dá para usar como está, mas na maioria dos casos precisa de ajustes. É fácil cair na armadilha do “se o LLM disse, então deve estar certo”, e isso facilita a má engenharia
  • Mesmo concordando com o texto original, na prática existem muitas áreas de aplicação em que a qualidade do software, boa ou ruim, simplesmente não importa tanto. Em muitos casos, basta funcionar

• Há casos em que nem cem testes unitários conseguem provar a correção de um código. A maioria dos desenvolvedores não sabe o que é suficiente. Quem usa muito vibe coding deixa até os testes por conta da máquina. Quando se chega à etapa de design de sistemas, é necessário um projeto que consiga garantir a segurança e as invariantes temporais do conjunto. Mas a maioria só desenha caixas e setas enquanto cita “best practices”. Software é mais próximo das ciências naturais, como no efeito Sussman, então passamos mais tempo observando. Usar GenAI como ferramenta pode ser útil, mas parar de pensar e depender da ferramenta é perigoso

  • Eu nem sei o que são testes unitários, mas graças à IA consigo fazer programas que ajudam bastante no meu trabalho real. Os programadores de elite não respondem nem e-mail, mesmo se você pagar

• A cada poucos anos, sempre que surge uma ferramenta nova, vem o discurso de que “a parte difícil da engenharia de software foi resolvida”. A produtividade dispara, as demos impressionam e a indústria se parabeniza. Mas logo depois vêm as reduções de quadro. Seria ótimo se houvesse uma ruptura real, mas se o resultado for demissão, então isso perde o sentido. No fim, a pergunta continua a mesma — se o objetivo é reduzir empregos, qual é a visão das empresas quando as pessoas não conseguirem mais se sustentar?

  • O objetivo não é o emprego individual. O objetivo final é construir AGI, e nesse processo os salários e o emprego de desenvolvedores já passaram do auge. Só alguns superdesenvolvedores de IA seriam exceção
  • Acho impossível remover a complexidade. A realidade e as pessoas são complexas por natureza. A ideia de que software pode ser simples é irrealista. Num quadro mais amplo, o objetivo no fim parece ser o desaparecimento da classe média
  • Se não houver demanda, você precisa fazer outra coisa. Se se recusar, vai passar fome
  • O capitalismo depende da existência de uma classe inferior. Ela pressiona os outros trabalhadores a aceitarem salários mais baixos e condições piores. Os programadores só estiveram temporariamente protegidos dessa realidade. Essa estrutura também está ligada ao trabalho imigrante, que as empresas podem usar para impor tarefas perigosas e ameaçar com deportação em caso de desobediência. No fim, tudo isso é um sistema para reduzir o custo do trabalho

• Concordo com a ideia de que “programar nunca foi a parte difícil”. Os especialistas já sabiam o que queriam construir, só achavam o trabalho repetitivo cansativo

  • A manutenção de código continua sendo uma questão de pessoas e experiência. Ficou mais importante saber “que código não se deve escrever”. Agora que gerar código ficou fácil demais, vivemos numa era em que é muito fácil produzir código espaguete
  • O centro do debate sobre LLM está aqui. Algumas pessoas só querem o resultado final, enquanto outras querem manutenibilidade e estabilidade. As duas posições são necessárias, e os papéis de protótipo e produção devem se separar naturalmente
  • Gente realmente boa continua preferindo fazer por conta própria. Não é por causa dos LLMs, sempre foi assim. Na verdade, quem mais se beneficia são aqueles que sempre diziam que “digitar sintaxe não tem graça”. Para mim, o ato de digitar é a única parte interessante

• Desenvolvedores juniores que dependem demais de IA vão pagar o preço depois, por não dominarem os fundamentos. No fim, só quem tiver mais experiência vai ter estabilidade no emprego

• É difícil concordar com a afirmação de que “escrever código nunca foi a parte difícil”. Claro, nem sempre é difícil, mas quando há restrição de tempo, escrever código vira o gargalo. A IA torna possíveis tentativas que antes eram inviáveis e libera mais tempo de engenharia

  • Existe uma contradição em dizer “é difícil levar isso a sério” e ainda assim acabar concordando. O texto original traz um nível de nuance bem maior
  • Escrever código era a tarefa que mais consumia tempo, e a IA só deixou isso mais evidente. Qualquer um consegue digitar, mas a capacidade de ler código é a verdadeira habilidade. É como um lenhador que troca o machado por uma motosserra: a eficiência aumenta, mas o dano potencial também

• A IA também facilitou a boa engenharia. No fim, ela é um amplificador de comportamento

  • Bons engenheiros conseguem fazer ainda melhor, mas a maioria nem sabe o que é property testing. Fico em dúvida sobre o quanto a IA é útil para essas pessoas
  • A internet conectou o conhecimento do mundo inteiro, mas os seres humanos acabaram mergulhando em conversa fiada e conteúdo descartável. Considerando a natureza humana, a IA deve seguir um caminho parecido
  • Problemas criativos muitas vezes são resolvidos no processo de escrever código manualmente. Com IA, esse circuito mental é menos ativado
  • Dados como o relatório DORA também reforçam isso
  • A frase “a IA é um amplificador de comportamentos já existentes” é realmente perfeita. Vou usar exatamente assim

• Sou cético em relação à IA, mas não acho que ela vá tirar o emprego dos meus colegas. Em vez disso, ela me poupa tempo. Uso como uma ferramenta de pesquisa melhor que o Google, e ela é útil para explorar codebases, gerar funções auxiliares e revisar erros

  • Também concordo. Acho que esse é, no fim, o destino final do uso de IA

• Hoje em dia a distinção entre engenharia de software e pesquisa está ficando mais nítida. A IA é uma ferramenta incrível em pesquisa exploratória. Quando aparece alguma possibilidade, aí eu mudo para o modo SWE, passo a entender e ajustar o código e refino tudo com minha experiência. O papel da IA é limitado, mas ainda assim útil

  • Os LLMs conseguem explorar instantaneamente uma largura de conhecimento muito maior do que a humana. Mas o julgamento final ainda depende do gosto e da sensibilidade de qualidade das pessoas

• Quantos modelos mais vão precisar sair até esse tipo de gente (os pessimistas) desistir? Dois? Três?