O sonho de substituir desenvolvedores que se repete a cada 10 anos

• Ao longo dos últimos mais de 50 anos, repetiram-se as tentativas de simplificar o desenvolvimento de software para reduzir a dependência de desenvolvedores
• Do COBOL nos anos 1960 às ferramentas CASE, Visual Basic, low-code/no-code e, mais recentemente, aos assistentes de código com IA, o mesmo padrão se repete
• Cada tecnologia aumentou a produtividade, mas o processo de pensamento necessário para lidar com a complexidade continua sendo responsabilidade humana
• A IA amplia a capacidade dos desenvolvedores, mas não substitui a compreensão dos problemas de negócio nem o julgamento
• Essas tentativas recorrentes revelam não o limite das ferramentas, mas a complexidade dos problemas e, no fim, o essencial é investir na capacidade humana de pensar

---

O início de um padrão recorrente

• A cada 10 anos surge a promessa de que “desta vez o desenvolvimento vai ficar mais fácil”
  • Após o programa Apollo, em 1969, o software passou a ser visto como uma tecnologia central
  • Mas ficou claro que desenvolver exige conhecimento especializado, concentração e investimento de tempo
• Foi aí que começou o sonho persistente de “simplificar o desenvolvimento para reduzir a necessidade de pessoal”

COBOL: a crença de que profissionais de negócios poderiam programar diretamente

• O COBOL, como indica o nome Common Business-Oriented Language, foi projetado para que profissionais de negócios escrevessem código como se fossem frases em inglês
• Porém, na prática, a complexidade da lógica, das estruturas de dados e do design de sistemas permaneceu, e acabou surgindo uma nova camada de desenvolvedores especialistas em COBOL
• A visão de que “qualquer pessoa pode programar” não se concretizou

Anos 1980: a promessa de geração automática com ferramentas CASE

• As ferramentas CASE (Computer-Aided Software Engineering) surgiram com a promessa de gerar código automaticamente a partir de diagramas
• Empresas fizeram grandes investimentos esperando um aumento de produtividade de 10 vezes
• Porém, o código gerado fracassou por causa de problemas de desempenho, dificuldade de manutenção e incompatibilidade entre modelos
• Como ainda era necessário entender a complexidade lógica, o problema não foi resolvido

Anos 1990: a abordagem de Visual Basic e Delphi

• O modelo de arrastar e soltar reduziu a barreira de entrada ao facilitar a criação de interfaces
• Aplicações simples eram viáveis, mas sistemas complexos que exigiam integração, segurança, desempenho e manutenção continuavam dependendo de desenvolvedores experientes
• Como resultado, a demanda por desenvolvedores não caiu; ela até aumentou

Desde os anos 2000: frameworks web, low-code e no-code

• O Ruby on Rails defendia “convenção em vez de configuração”, enquanto plataformas low-code/no-code promoviam o “desenvolvimento sem código”
• Em áreas específicas, conseguiram aumentar a velocidade e ampliar a participação, mas a necessidade de desenvolvedores profissionais continuou crescendo
• A pergunta recorrente: “por que esse padrão continua se repetindo?”

A natureza da complexidade

• O software pode parecer simples à primeira vista, mas na prática a complexidade explode nos detalhes e no tratamento de exceções
  • Ex.: conflito na reserva de estoque, falha no pagamento, indisponibilidade do serviço de e-mail
• Esse tipo de decisão detalhada é justamente a essência do ato de desenvolver, e nenhuma ferramenta consegue eliminá-lo

Um novo capítulo na era da IA

• Os assistentes de codificação com IA geram código em linguagem natural e ajudam com explicações, depuração e sugestões de melhoria
• Isso representa um avanço real, mas ainda assim definição do problema, segurança, integração e decisões de manutenção continuam sendo papel humano
• A IA amplia a produtividade dos desenvolvedores, mas não substitui o julgamento nem a compreensão de contexto

A capacidade de desenvolvimento ainda é insuficiente

• A tecnologia avançou enormemente, mas a demanda por software supera a oferta
• Empresas seguem buscando “formas de construir mais, mais rápido” e depositam esperança em ferramentas para simplificar o desenvolvimento
• Porém, o gargalo não está na velocidade de digitação nem na sintaxe, mas na capacidade de pensar sobre a complexidade

As perguntas que líderes devem fazer

• A pergunta não é “essa ferramenta vai substituir desenvolvedores?”, e sim:
  • “ela ajuda a resolver problemas complexos?”
  • “reduz trabalho repetitivo para permitir foco em problemas criativos?”
  • “exige aprender novas competências?”
• Essas perguntas ajudam a reconhecer os limites das ferramentas e a inevitabilidade do pensamento humano

A lição de 50 anos: o problema não é mecânico, é intelectual

• O COBOL simplificou a sintaxe, o CASE eliminou digitação, e a IA gera funções inteiras, mas a dificuldade essencial continua a mesma
• Desenvolvimento de software é o ato de concretizar pensamentos, e isso não pode ser substituído por ferramentas
• Como no projeto de arquitetura ou no diagnóstico médico, o próprio processo de pensamento é o valor central

O caminho daqui para frente

• Novas ferramentas continuarão surgindo, mas o mais importante é investir na capacidade humana de pensar
• Vale experimentar IA, low-code e novos frameworks, mas a capacidade de compreender a complexidade deve ser tratada como competência central da organização
• Como no programa Apollo, mais do que as ferramentas, a precisão do pensamento é o fator decisivo para o sucesso

Por que o sonho continua

• O “sonho de substituir desenvolvedores” não é um fracasso, mas um otimismo que impulsiona a inovação em ferramentas
• Cada tentativa falhou em substituir completamente, mas gerou uma nova geração de ferramentas úteis
  • O COBOL ampliou o desenvolvimento de sistemas de negócios
  • O CASE impulsionou a evolução da modelagem visual
  • O Visual Basic ampliou a acessibilidade ao desenvolvimento
  • A IA está acelerando a mudança na forma de desenvolver
• No fim, a limitação não está nas ferramentas, mas na complexidade dos problemas que tentamos resolver
• Não há necessidade de rejeitar novas ferramentas; é preciso reconhecer expectativas realistas e a importância do julgamento humano

[GN⁺]

Comentários do Hacker News

• Ao ver esta onda de inovação em IA, dá para perceber que grande parte da programação não é complexidade essencial, mas complexidade acidental
  É o fenômeno em que um trabalho conceitual para humanos se transforma em trabalho procedural para a IA
  Por exemplo, antes era preciso aprender vários conceitos para escrever public static void main(String[] args) em Java, mas para a IA basta um prompt como “escreva o método de entrada da classe” para gerar esse código de forma quase garantida
  Enquanto tarefas procedurais difíceis para humanos são fáceis para a IA, a sociedade está estruturada em torno desse tipo de trabalho procedural, então, quando a inovação se espalha, alguns sobem e outros sofrem

  • Acho que estão subestimando a experiência e a especialização necessárias para fazer as perguntas certas

• A ideia de que “no-code vai substituir os desenvolvedores” se repete sempre, mas na prática isso acabou criando ainda mais empregos para desenvolvedores
  COBOL, VB, Squarespace e agora IA — quando uma ferramenta reduz a barreira de entrada, mais gente tenta construir algo e, quando bate nos limites, passa a precisar de desenvolvedores de verdade
  Tarefas simples e repetitivas desaparecem, mas definir o que construir e depurar continua sendo necessário

  • Eu também espero que essa expansão continue, mas no fim isso depende de surgir nova demanda
    Se a IA conseguir programar sozinha projetos complexos, os humanos não precisarão se preocupar com os detalhes, e a demanda por desenvolvedores pode cair
    No passado houve grandes tendências como internet, nuvem, mobile e machine learning, mas não tenho certeza de que esses “grandes problemas” continuarão surgindo
  • Este é um caso clássico do Paradoxo de Jevons — quando algo fica barato, o mercado pode até crescer
  • Claro, desta vez pode ser diferente. Se a IA realmente entregar o que promete, o número de desenvolvedores pode diminuir
  • Máquinas agrícolas tornaram os fazendeiros mais eficientes, mas hoje existe ainda mais fazendeiros
  • A afirmação de que “o número de desenvolvedores não vai cair” é categórica demais. Se a IA também conseguir depurar e interpretar requisitos, a situação pode mudar

• Nos últimos 20 anos, vi o mesmo padrão também na área de administração de sistemas
  A promessa de que “abstrações mais altas democratizam o trabalho dos especialistas” se repete, mas na prática o que acontece é uma reinvenção cara
  Ferramentas como Kubernetes dizem esconder a complexidade, mas no fim os desenvolvedores voltam a aprender os mesmos problemas de forma mais cara, sem conhecer os conceitos básicos
  Excel é um exemplo representativo — produziu erros terríveis, mas teve sucesso por causa da acessibilidade
  No fim, queremos ao mesmo tempo “a acessibilidade do Excel e a confiabilidade da engenharia”, mas não dá para ter os dois

  • Então, ao usar software não determinístico, os prêmios de seguro ou políticas de compensação vão mudar?
  • Se Kubernetes não reduziu trabalho, então isso significaria que 95% das grandes empresas são burras
    Na realidade, conforme a escala cresceu, a complexidade do trabalho subiu de nível
  • Toda abstração é uma abstração com vazamento. Até em C o resultado muda conforme o compilador

• Esse padrão se repete por causa dos incentivos de mercado
  As empresas precisam vender a IA como solução universal para fazer a ação subir, então a estrutura acaba vendendo crença mais do que desempenho real
  Quando a realidade vier à tona, o mercado vai ficar confuso

  • O mercado não é uma força da natureza. Só existe mercado quando existe ordem política
  • Se o produto realmente funcionasse como prometido, estariam focados em desenvolver, e não em rebater “críticas de céticos”

• Na verdade, teria sido possível reduzir o número de desenvolvedores
  Se as empresas tivessem feito uma contratação mais seletiva e mais investimento em treinamento
  Mas a realidade foi o oposto, e frameworks web foram criados não para aumentar produtividade, mas para reduzir custo de treinamento e ampliar o pool de mão de obra

  • Não concordo. Bons frameworks aumentam manutenibilidade e produtividade

• Gerentes intermediários e executivos veem o departamento de tecnologia apenas como centro de custo
  Por isso, mencionam IA em todos os releases e falam em reduzir gasto com pessoal
  Na prática, estão reduzindo custos não por causa da IA, mas por meio da substituição por mão de obra offshore
  As equipes onshore que restam assumem mais trabalho e elevam a produtividade

  • Mas nas regiões offshore também estão ocorrendo demissões na mesma medida
    A causa não é redução de custo trabalhista, mas uma contração geral do investimento
    No fim, a IA acaba reduzindo empregos ao absorver capital em investimentos em data centers
  • Há muitos contraexemplos históricos para a afirmação de que “vendas não pode existir sem produto”

• O objetivo da IA não é substituir desenvolvedores, mas elevar o nível de abstração para lidar com problemas mais complexos
  Começando pela programação por cabeamento dos primeiros computadores e evoluindo para assembly, C, Python e frameworks, os desenvolvedores passaram a lidar com problemas de nível cada vez mais alto
  Só que as etapas anteriores eram todas transformações determinísticas e verificáveis, enquanto a IA generativa é não determinística — essa é a diferença
  Como leitura relacionada, vale ver The Story of Mel

  • Mas empresas, incluindo o CEO da Anthropic, estão mais interessadas em redução de custo e substituição do que nesse objetivo filosófico
  • Mesmo assim, as pessoas continuarão falando em “substituir desenvolvedores”
  • Em cada etapa de abstração, é preciso poder olhar por dentro
    Em LLMs, não dá para ver tokens, AST, IR etc. como num compilador, então tudo é opaco
  • O verdadeiro objetivo das empresas de IA é a automação de todo trabalho intelectual
  • Quanto mais alto o nível de abstração, menor a precisão e o controle
    Sistemas não determinísticos baseados em linguagem natural são diferentes das abstrações de gerações anteriores
    Por isso, a analogia com a “transição de assembly para C” não é apropriada

• Como dizia Dijkstra, a ciência é odiada porque é difícil, e os cientistas que têm esse poder também são odiados
  Link para o texto original EWD1041

• Por outro lado, os desenvolvedores sempre sonharam em automatizar funções não técnicas
  A IA é a versão mais recente desse sonho

  • Será que algum dia chegará um mundo ao estilo Star Trek em que todo trabalho será um bom trabalho?

• No começo dos anos 2000, Rational Rose UML era disciplina obrigatória na universidade
  Na época, o CEO de uma startup dizia: “agora basta desenhar diagramas e o código será gerado automaticamente, então não precisamos mais de desenvolvedores”
  Mas no fim essa profecia não se realizou

[kayws426]

As máquinas criam código para as máquinas.
O castelo de areia que os humanos construíram sobre a linguagem de máquina está fadado a desmoronar no fim.
...também dá para falar isso, né kkk