- Do NoCode à IA, tecnologias que prometem substituir desenvolvedores surgem repetidamente, mas na prática ocorre uma transformação dos papéis conforme a mudança tecnológica
- O NoCode não eliminou desenvolvedores; ele criou especialistas em NoCode e integradores, enquanto a nuvem criou o cargo avançado de engenheiro de DevOps
- As ferramentas atuais de desenvolvimento com IA estão seguindo um caminho parecido, e a capacidade de projetar a arquitetura de sistemas continua sendo central mesmo na era em que a IA escreve código
- A IA é boa em otimização local, mas fraca em projetar sistemas inteiros, e sua velocidade de geração pode fixar rapidamente erros estruturais
- A substituição de desenvolvedores, no fim, é apenas uma evolução e sofisticação decorrentes da mudança no stack tecnológico; o papel essencial continua sendo necessário
From NoCode to AI-Assisted
- A cada poucos anos, surge uma nova tecnologia que afirma que vai substituir desenvolvedores de software
- Títulos parecidos com expectativas exageradas se repetem: “o fim da programação”, “agora qualquer pessoa pode criar um app”, “até criança programa”
- Executivos e consultores passam a dar atenção a essa onda, e o orçamento começa a migrar
- Mas a realidade sempre foi “transformação”, não “substituição”
- Repetidamente, surgem novos papéis e profissões mais especializadas para lidar com tecnologias mais complexas, e os salários também tendem a subir
- O NoCode criou a expectativa de que seria possível criar apps sem especialistas, mas no fim continuaram existindo problemas complexos como modelagem de dados, integração e manutenção, e surgiram novas funções para resolvê-los
- A nuvem deu a impressão de que seria possível operar sem administradores de sistemas, mas na prática passou a exigir a especialização avançada de engenheiros de DevOps, com aumento salarial
- Com a IA acontece o mesmo: parece que “a IA vai escrever o código”, mas na prática a importância de desenvolvedores experientes capazes de gerenciar e orquestrar a IA fica ainda maior
O carrossel interminável das promessas de substituição (The Endless Carousel of Replacement Promises)
Inovação NoCode/LowCode
- Surgiu a inovação NoCode/LowCode, prometendo que qualquer usuário poderia criar aplicativos com interfaces intuitivas
- Mas, no mundo real, apareceram novos problemas como modelagem de dados, integração com sistemas e bancos de dados existentes, tratamento de exceções e manutenção
- Com isso, passou a haver necessidade não de um desenvolvedor genérico, mas de um especialista em NoCode que entenda ao mesmo tempo o domínio e os limites técnicos
- Esses profissionais recebem salários mais altos do que desenvolvedores tradicionais
Revolução da nuvem
- Havia grande expectativa de que, ao migrar para a nuvem, administradores de sistemas deixariam de ser necessários
- Mas a especialização em gestão de nuvem e a complexidade na verdade aumentaram
- Administradores de sistemas tradicionais se transformaram em engenheiros de DevOps, passaram a receber salários maiores e elevaram o nível do trabalho com automação de infraestrutura, pipelines de deploy e gestão de sistemas distribuídos
- O trabalho não desapareceu; ele evoluiu para uma nova forma
- Na transição para microsserviços, a complexidade também aumentou, e ficou claro que o papel de especialistas que gerenciam sistemas em profundidade é fundamental
O movimento do desenvolvimento offshore
- Surgiu a crença de que o outsourcing internacional reduziria custos, mas houve dificuldades por causa de problemas de comunicação, queda de qualidade e falta de conhecimento de domínio
- No fim, a estratégia mudou para estruturação de equipes distribuídas, ownership claro e arquitetura sólida, e o resultado foi um custo total maior do que o esperado inicialmente
A revolução dos assistentes de programação com IA
- Agora, a grande promessa é que a IA gera código automaticamente
- Na realidade inicial, o código produzido pela IA frequentemente contém erros sutis e problemas de consistência
- Engenheiros sêniores gastam muito tempo revisando e corrigindo os resultados da IA, e quanto mais experiente o desenvolvedor, mais valor ele gera
- Sistemas construídos apenas com auxílio de IA muitas vezes não têm uma arquitetura sistemática
- Em outras palavras, a tecnologia não substitui o especialista; ela eleva a especialização do especialista para uma camada de abstração mais alta
Por que este ciclo é especial
- O ponto central que muita gente ignora: código não é ativo, é passivo
- Quanto mais rápido e fácil se cria código, maior também é o peso de manutenção, segurança e refatoração
- A IA consegue otimização no nível de função, mas carece de capacidade para projetar o sistema como um todo
- Quanto mais rápida for a implementação, maior o risco de congelar erros estruturais rapidamente
- No fim, o verdadeiro ativo, mesmo na era da IA, é a capacidade de projetar a arquitetura de sistemas, e isso não é algo a ser substituído, mas fortalecido
- A afirmação de que “a IA vai substituir desenvolvedores” nasce dos seguintes mal-entendidos fundamentais
- o fato de que código não é ativo, é passivo
- código exige manutenção contínua, validação, gestão de segurança e substituição, e a dívida cresce na proporção do número de linhas
- O fato de a IA produzir código rapidamente significa apenas que ela gera dívida na mesma velocidade
- Ou seja, a IA é boa em otimização local (funções, partes do recurso), mas é fraca em projeto global e decisões de arquitetura
- Quanto mais rápida a implementação, maior o risco de um projeto errado “endurecer” em todo o sistema
- Isso pode não ser um problema em sites pontuais e de curto prazo, mas é fatal para sistemas que evoluem no longo prazo
- O padrão das inovações tecnológicas continua o mesmo
- Administradores de sistemas viram engenheiros de DevOps, e desenvolvedores backend viram arquitetos de nuvem
- Mas a IA acelera tudo. A habilidade que sobrevive e evolui não é escrever código
- É justamente projetar sistemas (Architecting systems). Essa é a única coisa que a IA não consegue fazer
19 comentários
Sou uma pessoa que trabalha de forma um pouco conservadora, então nunca cheguei a adotar ferramentas de IA em tarefas importantes; no máximo, troquei o hábito de pesquisar no Google ou no Stack Overflow por perguntar ao Gemini ou ao ChatGPT. Estou usando, sim, mas...
Quando peço para a IA criar alguma coisa, penso que talvez funcione bem usá-la em nível de função: pedir, por exemplo, uma função em que você passa um input e sai um determinado resultado, e depois eu mesmo escrever algo como a lógica para verificar se o valor de retorno da função criada pela IA saiu corretamente.
Sou cético em relação à pergunta se seria possível organizar todo o contexto em um formato que a IA consiga entender bem. As pessoas não têm apenas o contexto superficialmente necessário para o desenvolvimento que estão fazendo naquele momento, mas também carregam contextos latentes, e desenvolvem considerando essas partes; ainda não acho que seja possível para uma pessoa registrar esse contexto em uma forma de expressão bem refinada. Acho que isso não é tanto um problema da IA, mas sim uma limitação humana. Especialmente porque também considero que, hoje em dia, a capacidade de escrita das pessoas não é lá muito boa.
O assustador não é este momento agora, e sim a tendência, eu acho..
Agora é totalmente diferente.
O futuro em que todas as profissões serão substituídas está logo ali, e os desenvolvedores são apenas uma delas.
Isso nunca foi uma moda nem uma vez.
Provavelmente não haverá uma mudança exatamente igual.
Mas é uma transformação pela qual muitas profissões já passaram há muito tempo, na era moderna. Por exemplo, a mudança que artistas viveram com o surgimento da fotografia, ou que artesãos enfrentaram com fábricas automatizadas. Não me parece que com programação seja diferente.
Eu imagino que, quando a inovação se tornar algo cotidiano, no fim das contas vamos precisar de ainda mais engenheiros do que hoje. O nível de exigência dos usuários vai subir, e será preciso criar coisas maiores e mais complexas. Como diz a hipótese da Rainha Vermelha.
Claro, há uma grande chance de o tipo de trabalho mudar ou de certas tarefas desaparecerem. Como aconteceu quando os tipógrafos de composição manual sumiram sem que a gente percebesse. Nesse contexto, projetar sistemas provavelmente será uma metáfora ou um exemplo de uma abstração mais elevada.
Acho que é porque todo mundo quer substituir os desenvolvedores por alguma coisa.
Parece que bastante gente pensa que eles ganham muito dinheiro sem nem ter trabalho para fazer.
Acho que, independentemente de isso realmente substituir ou não, esse tipo de conteúdo continua circulando porque é algo chamativo.
Na maioria dos casos em que criam manchetes desse tipo de forma impactante, desde o início dificilmente isso é o resultado de uma reflexão profunda sobre como a realidade de fato é ou sobre como se pode definir o que seria “substituição”.
Um conteúdo produzido com reflexão de verdade acaba tratando mais de até onde a IA e outras ferramentas conseguem ir no momento e para onde estão evoluindo. E, claro, pessoas em geral não clicariam num título tão sem graça assim.
Tem muitas manchetes sensacionalistas..
"Zuckerberg, que demite 10% todos os anos: 'No próximo ano, a IA substituirá metade dos desenvolvedores' [Silicon Valley View, de Yoon Min-hyeok]"
https://m.sedaily.com/NewsView/2GRQ1RKIYC
"'Programar' é o que a IA faz melhor... o primeiro alvo da reestruturação da Microsoft são os 'desenvolvedores'"
https://n.news.naver.com/mnews/article/009/0005494133
"'Será que até os empregos vão sumir desse jeito?' A preocupação está virando 'realidade'?... setor apreensivo"
https://econmingle.com/economy/…
"[Escolha da Yumi] 'Não contratamos desenvolvedores de software júnior'... empresas que provaram a 'programação com IA' começam a 'otimizar' a organização"
https://v.daum.net/v/20250522162617091
"'A IA faz análise, design e programação sozinha'... LG CNS vai usar 'programador de IA' no lugar de desenvolvedores"
https://zdnet.co.kr/view/?no=20250528092405
Acho que faz sentido ver isso como uma substituição gradual.
É fato que o número de pessoas necessário para alcançar o mesmo resultado em uma tarefa está diminuindo.
Mesmo no caso de "projetar sistemas", se algo que antes era feito por 10 pessoas agora pode ser resolvido por 8 pessoas + suporte de IA,
isso já significa que 2 pessoas foram substituídas.
Do ponto de vista do design de sistemas
Talvez porque isso seja incluído nos prompts sem que normalmente seja levado em consideração
Parece que o problema é não conseguir lidar muito bem com as consequências do vibe coding
Concordo com essa opinião com base na minha experiência pessoal. No fim das contas, a IA também é uma ferramenta, então do 1 ao 99 ela é realmente rápida e boa, mas sempre dá a sensação de que falta aquele 1 restante.
Concordo, mas acho que o ponto central não é tanto o "design de sistemas", e sim a "resolução de problemas complexos por meio do design de sistemas".
Acredito que as tarefas fáceis ficam cada vez mais fáceis, e as difíceis continuam ficando cada vez mais difíceis.
kk kk
Opinião no Hacker News
Com base na experiência recente de revisar como freelancer trabalhos como uma “landing page de marketing descartável”, clientes muito controladores sempre acabam acrescentando exigências estranhas que a IA não consegue lidar direito, e no fim sobra para a pessoa resolver a bagunça; por mais inteligente que a IA fique, os problemas de software não são apenas técnicos, porque as próprias pessoas continuam criando “complexidade desnecessária”; no fim, a maior arma do desenvolvedor é dizer “não”, mas fica a preocupação de que, se forem IAs competindo entre si, sempre haverá uma que diga sim como um humano faria
Software pode ser implementado perfeitamente, mas se os requisitos em si não refletem a realidade técnica, no fim só surge confusão — o conceito clássico de “bug de requisitos”; a IA agora já consegue responder a limitações reais como formato ou suporte (ex.: gif não suporta transparência), mas a ideia é que seres humanos continuarão escrevendo exigências absurdas como “faça o logo como um quadrado em que cada ponto esteja à mesma distância do centro”; até o erro de digitação de jpg foi citado como piada
Pela experiência, entre “não” e “sim” existem 50 tons de cinza do tipo “é isso mesmo?”; alguém disse que queria uma página web “capaz de baixar o banco de dados”, mas na prática queria apenas uma exportação simples em csv, mostrando a importância de interpretar o contexto; há curiosidade sobre se o chatgpt realmente capta esse tipo de nuance
“Recusar” é de fato a parte mais difícil e desgastante do trabalho do desenvolvedor; muitos desenvolvedores na verdade não gostam desse papel ou acham que ele nem faz parte do trabalho deles; no fim, o sucesso real de um projeto é decidido não pela tecnologia, mas pela comunicação “humano com humano” com os stakeholders, daí a crença de que sempre será necessário um “desenvolvedor que na prática também faz papel de PM”
Tudo isso aparece muito bem no chamado livro ‘Peopleware’; gostam da saudação “que todos os seus problemas sejam técnicos”, porque, na prática, os problemas resolvidos com código quase nunca foram tão difíceis, exceto por alguns edge cases muito específicos
Opinião de que é um bom ponto, e que a IA pode se tornar cada vez melhor em estimar complexidade e emitir alertas; analogia com o xadrez, onde a IA já mostra capacidade de avaliação/julgamento muito superior à humana; aqui IA não está limitada a LLM, embora se reconheça o avanço também nessa categoria
Discordância da afirmação do artigo de que “a IA não consegue projetar sistemas (architecting)”; na prática, a IA já vem melhorando bastante nessa área, e há a observação de que muita gente muda continuamente o significado do que seria condição necessária para deslocar o debate; ainda assim, a IA não consegue decidir sozinha o que deveria querer, nem substituir a motivação do usuário (embora possa sugerir ideias); no futuro, a sociedade ainda precisará de alguém que aja e queira resolver problemas, então o papel do desenvolvedor muda, mas a resolução de problemas continua sendo responsabilidade humana
Foi dito que o significado de “desenvolvedor” está mudando, mas a visão aqui é que a essência sempre foi a mesma; programar é, no fundo, transformar requisitos ambíguos em código claro; os meios mudaram, de código de máquina e cartões perfurados para frameworks, GUI e até ferramentas visuais, mas escrever código continua sendo o método mais eficaz por causa da clareza e da capacidade de comunicação; LLMs são fortes em repetir padrões já existentes, mas quando se tenta algo realmente novo ou explicar tudo em linguagem natural, a frustração é grande; o mercado está no auge do hype, mas no fim só se repete o padrão de mudança parcial que acompanha cada nova tecnologia
Observação de que as empresas já estão reduzindo contratações de júnior por causa da IA; se a IA faz tudo menos architecting, o resultado é uma estrutura que exige menos engenheiros no total
Afirmação categórica de que a IA ainda não consegue fazer architecting; architecting e planning não são a mesma coisa: planning é a capacidade de alocar restrições, soluções e recursos, além de prever cenários, e a IA ainda estaria longe de fazer isso de forma eficaz; architecting de verdade envolve design cooperativo e competitivo em múltiplas camadas, e se a IA errar em uma camada, todo o sistema pode se desalinhar; por isso, enfatiza-se que apenas humanos conseguem projetar e supervisionar esses sistemas com segurança
Opinião de que, com contexto suficiente, a IA consegue entender bastante bem o que se quer; isso se conecta também a alertas sobre privacidade; se uma organização tiver sistemas poderosos com consciência de contexto, a parte mais assustadora é que a IA poderá prever “bem o suficiente” seus desejos e até seus próximos passos
Comentário franco de que a IA não está fazendo architecting, mas apenas simulação, e que muitas vezes nem consegue programar direito
Argumento de que a própria suposição de que negócios valorizam qualidade está errada; empresas só consideram rentabilidade e só entregam alta qualidade se o cliente quiser; francamente, os próprios clientes preferem produtos com “melhor custo-benefício” do que qualidade, comprando a ferramenta mais barata da Amazon e repetindo a produção de código mais ou menos capenga parecido (vibe code); no fim, o único grupo que realmente se importa com qualidade são os engenheiros, e previsões de futuro baseadas na visão do engenheiro sobre qualidade podem ser ignoradas sem medo
Opinião de que qualidade pode ser um diferencial; quando o iPhone surgiu, havia concorrentes cheios de recursos, mas o fato de a UI ser mais fluida e refinada acabou dominando o mercado
Apresentação da empresa favorita, focada em qualidade, Fractal Audio: uma pequena empresa que produz modeladores de hardware para guitarra (simuladores de amplificador e pedalboard), com atualizações inovadoras em sequência e um CEO obcecado pela qualidade da modelagem analógica; a qualidade supera de longe a de grandes empresas; sem comissão, assinatura ou marketing com celebridades, a empresa se posiciona com venda direta e atualizações gratuitas de algoritmo; é um exemplo vivo de conquista de market share pela qualidade e de que nem todo negócio vive apenas da competição de “baixo custo e baixa qualidade”
Reação contrária à visão de que clientes não ligam para qualidade: se qualidade não tivesse importância, todas as startups deveriam simplesmente lançar produtos incompletos e baratos e ainda assim alcançar enorme receita e sucesso
Lista de exemplos de que os produtos de software realmente bem-sucedidos eram, em sua maioria, de altíssima qualidade; Google, iPhone, Stripe, Notion e outros produtos duradouros no mercado não eram lentos nem cheios de bugs; ao contrário, a qualidade teria sido fator de sucesso, e surge a pergunta de quais seriam os contraexemplos
Preocupação de que, até certo ponto, a qualidade possa ficar diluída por componentização, assinaturas e dependência da internet, mas que um futuro de colapso generalizado também é possível; dispositivos podem virar tijolo, até sites simples podem levar 12 segundos para abrir, infraestrutura social e sistemas governamentais podem se tornar instáveis apesar de bilhões investidos, e há o risco de um mundo em que conversas cotidianas sejam com LLMs
Recordação de que a antiga revolução organizacional baseada em UML, em que “o arquiteto faz a especificação e o desenvolvedor só preenche as lacunas”, acabou criando sistemas excessivamente complexos e perdendo agilidade; depois, o “agile” também foi mal compreendido e virou microgerenciamento de desenvolvedores, falta de confiança e cultura organizacional sem criatividade; no fim, o traço comum dos times bem-sucedidos era que os não desenvolvedores realmente se interessavam pelo trabalho dos desenvolvedores e ajudavam a resolver o problema junto, enquanto tentativas de reduzir a complexidade quase sempre fracassavam
Sobre a tese de que “architecting é a habilidade mais valiosa e a parte que a IA não pode substituir”, há a visão de que, quando se pede explicitamente para a IA projetar a arquitetura de um sistema, ela frequentemente entrega resultados melhores do que pelo menos 30% dos projetistas encontrados no mundo real; a impressão é que usuários de IA simplesmente não fazem esse tipo de pedido com frequência
Como os LLMs atuais são treinados majoritariamente com respostas de nível intermediário (best practice), eles naturalmente produzem algo melhor que cerca de um terço dos projetistas humanos — um projeto de senso comum, “aceitável” — enquanto, em áreas totalmente novas ou indústrias que exigem alto desempenho, continua sendo mais necessário o raciocínio humano baseado em primeiros princípios; prevê-se também que um kernel de banco de dados projetado por LLM seria básico, não inovador
Crítica ao estilo característico de texto escrito com ChatGPT presente no próprio artigo — frases curtas, estruturas repetidas, excesso de recursos como “não X, mas X+1” e “não X, e sim o oposto de X” — e surpresa com o fato de esse tipo de texto receber tantos upvotes no HN
Interpretação de que o autor estaria sendo levado por um “pensamento desejoso”, achando (ou se arrogando) que sua própria habilidade, architecting, é imutável e insubstituível; comentário de que, se ele tivesse outra habilidade em destaque, provavelmente a veria como a insubstituível
Resumo de que a essência do arquiteto é a capacidade de entender corretamente requisitos e restrições e refletir isso no sistema; isto é, saber escrever bons prompts, ler corretamente as respostas e, quando necessário, contestá-las com firmeza
Observação de que muitos “arquitetos” encontrados no mundo real tinham pouca capacidade prática, achando que bastava mexer em ferramenta de diagramas ou Excel sem conhecimento real de infraestrutura de TI; parecem gerentes, mas na prática só uma minoria consegue executar o trabalho essencial
Opinião de que empresas que dependem “demais” de IA podem, na verdade, aumentar sua exposição a ondas de ruptura; na era da IA, mais importante do que produtividade na geração de código é o controle de qualidade desse código, mas o mercado está excessivamente focado na produção automática; citação da fala de Satya Nadella de que “30% do código da Microsoft é escrito por IA”, além da tendência de mais de 20 incidentes por mês no Github (link de referência: githubstatus.com/history); prevê-se que empresas que perseguirem apenas eficiência acabarão pagando a conta da queda de qualidade, especialmente pequenas e médias, e não gigantes como a Microsoft
Contra-argumento de que empresas que ignorarem a IA é que vão sofrer mais
Defesa da tese de que “empresas que usam IA em excesso acabam assumindo custos muito maiores no longo prazo”, com apresentação do artigo relacionado (AI: Accelerated Incompetence)
Concordância total com a frase “código não é ativo, é passivo”; o objetivo é atingir o resultado com o mínimo possível de código, e a preocupação é que a IA, por tornar tão fácil gerar código, amplie ainda mais a dívida de código
Compartilhamento do link da wiki sobre o paradoxo da produtividade no avanço tecnológico — quando a produtividade aumenta, mas os ganhos são anulados pela maior complexidade real dos sistemas (Productivity paradox)
Analogia de que a era atual de geração de código por IA lembra a época em que se criavam sites com MS FrontPage, quando o html ficava 90% cheio de código inútil, a “era da tralha”
Contraponto de que, se código se tornar facilmente substituível, talvez a própria visão de código como passivo perca sentido; no futuro, quando houver erro, o programador pode simplesmente pedir para a IA reescrever o código, reduzindo o peso desse passivo
Há também quem veja o código como expressão criativa e artística, compartilhando a experiência de sentir imediatamente a beleza ao ler um código elegante e bem escrito
Compartilhamento de um link lembrando que, já no início do FORTRAN (1954), existia o slogan de que “Fortran eliminaria o próprio ato de codificar e depurar” (BackusEtAl-Preliminary Report)
A premissa de fundo dessas discussões é a expectativa de que o progresso técnico logo chegue a um limite; mas, se isso estiver errado, nada impede que um dia a IA compreenda logs, infraestrutura, finanças e documentação como um todo e passe a entender e projetar até o próprio negócio; como os modelos de IA ainda continuam crescendo, ficando melhores e mais baratos, há quem veja mais peso na ideia de que, em algum momento, ela chegará à essência da substituição
Visão de que demissões de desenvolvedores não acontecem por progresso técnico, mas como medida posterior diante da incerteza, e que usar tecnologia/IA como justificativa seria só uma racionalização posterior; cita-se que, até cinco anos atrás, as empresas estavam dispostas a ampliar equipes de engenharia de software mesmo com custos altos, buscando aumentar a produtividade, então o custo não seria a raiz do problema
Estou procurando alguém para revisar o vibe coding com IA. Já está tudo feito, mas está dando erro; por favor, corrija só um pouquinho. Pedidos de freelas assim já estão aparecendo, mas fazer de novo do zero costuma ser mais rápido.
Isso aconteceu comigo também, e foi terrível...
Não sei se é porque essas pessoas não entendem ou porque simplesmente não se importam, mas enfim, tem muita gente assim...
Com tradução é a mesma coisa... IA até pode ser útil? Mas parece estar dificultando a vida de muita gente...
À primeira vista parece plausível, mas, para quem precisa corrigir, o trabalho acaba até aumentando, buá buá
Arrepiei kkkkk