A HISTÓRIA NÃO CONTADA DO COLAPSO DA ENGENHARIA DE SOFTWARE

estamos diante de uma crise sem precedentes na engenharia de software uma geração inteira de programadores está perdendo a capacidade fundamental de raciocinar projetar e implementar soluções sólidas a era das inteligências artificiais que chegou prometendo revolucionar a produtividade acabou trazendo também alguns efeitos colaterais e o que a gente tá vivendo hoje não é só uma nova fase da tecnologia uma regressão disfarçada de produtividade e com isso surge uma nova era de programadores que acredita que pensar demais é desperdício que entender o que tá fazendo é coisa de séor arrogante e que projetar software com responsabilidade virou

frescura e perda de tempo para somar nessa equação e piorar ainda mais o cenário temos as metodologias ágeis que vieram para dar leveza ao desenvolvimento de software e que foram completamente corrompidas dentro das empresas corrompidas ao ponto de que viraram ferramenta de microgerenciamento a daily virou interrogatória a Sprint virou corrida maluca e o programador virou entregador de tickets hoje a cultura dominante é entrega só entrega se rodou tá certo e para que aprendesse a IA já faz o pior de tudo isso é que já começaram a surgir as primeiras rachaduras mostrando que o código produzido

hoje em dia tá cada vez mais porco e os sistemas estão mais frágeis e vulneráveis a engenharia de software que a gente conhece tá doente o mais assustador é que essa doença não é nova a gente tá desenterrando um monstro que a comunidade técnica passou décadas tentando vencer um monstro que já tinha sido nomeado diagnosticado e combatido no passado só que para entender que monstro é esse como que a gente chegou nesse ponto de caos que estamos vivendo agora a gente vai precisar dar uns passos para trás e voltar no tempo voltar pro início da

queda voltar pra época exata onde a engenharia de software perdeu o controle onde tudo começou a desandar vamos voltar para uma época que ficou conhecida como a origem do caos sejam bem-vindos à história não contada do colapso da engenharia de software voltamos então pro fim da década de 60 computadores ainda ocupavam salas inteiras e eram acessíveis apenas a governos exércitos e grandes corporações a programação ainda era feita em cartões perfurados e tudo era muito manual e artesanal e absurdamente propenso a erro nessa época não existia a engenharia de software que a gente conhece como disciplina

formal que existia era um bando de programadores escrevendo código direto no metal muita das vezes em linguagens de máquina ou linguagens mais próximas dela como assembly e eram esses mesmos programadores que lutavam insanamente para tentar manter sistemas maiores mais complexos e mais difíceis de entender e foi exatamente nessa época que surgiu o que ficou conhecido como a crise do software esse termo surgiu pela primeira vez em 1968 durante uma conferência da Otana Alemanha onde os maiores especialistas da época chegaram à conclusão de que apesar do avanço significativo do hardware o desenvolvimento de software estava totalmente

fora de controle os projetos da época atrasavam meses ou até anos os orçamentos sempre estouravam e os sistemas quase sempre falhavam no ar e quando falhavam ninguém sabia exatamente o porquê além disso era extremamente comum grandes corporações perderem milhões de dólares por bugs que ninguém conseguia rastrear o código era uma verdadeira bagunça sem organização sem padrão sem separação de responsabilidade era basicamente um amontoado de instruções costurada no improviso e o pensamento dominante da época era: "Se funcionou deixa assim" porque a manutenção era um verdadeiro pesadelo e qualquer alteração por menor que fosse podia quebrar o

sistema inteiro nessa época não existia ainda teste automatizado não existia versionamento de código não existia controle sobre absolutamente nada cada software era uma caixa preta escrita por um programador que muit das vezes era o único que conseguia entender toda aquela bagunça e da manutenção e foi em cima desse cenário caótico da crise do software que nasceu um consenso importante entre a comunidade técnica se a gente queria continuar evoluindo com o software ia ser preciso criar método criar princípio criar estruturas formais para lidar com a complexidade então já era mais do que na hora da gente

parar de escrever código no improviso e começar a projetar software de verdade e é exatamente isso que nos leva pro nosso próximo marco temporal se a década de 60 terminou com um software totalmente fora de controle a década de 70 começou com sentimento geral de urgência técnica era preciso a gente parar e organizar a bagunça a programação que até então era vista como algo quase artesanal começou a ser tratada como uma disciplina estruturada com estudos métodos e debates sérios sobre como escrever um software que não desmoronasse com o tempo e é nessa década que surgem

os primeiros esforços reais para formalizar o desenvolvimento de software a ideia aqui era simples não dava mais pra gente depender só da boa vontade do programador era preciso a gente criar regra definir estrutura estabelecer boas práticas e foi exatamente isso que começou a acontecer em 1970 o cientista da computação Edger Dixtra publica o artigo que viraria uma das pedras fundamentais da engenharia de software da Apple época e nesse artigo ele denunciava o uso desenfriado do Goutu como um dos principais responsáveis por códigos ilegíveis caóticos e quase impossíveis de manter a proposta dele era chamada programação

estruturada baseada em três pilares: sequência condição que a gente conhece como if else e repetição que a gente conhece como loop a ideia era dar ao fluxo do programa uma estrutura previsível legível e segura e ele não estava sozinho nesse barco porque em 1972 David Parnas traz à tona outro conceito revolucionário chamado encapsulamento de decisões segundo ele um módulo de software não deve expor o seu funcionamento interno mas sim oferecer uma interface limpa clara e protegida de alterações futuras foi a primeira vez que se falou abertamente em esconder complexidade através do design de código e

isso virou a base para tudo que viria anos depois com a explosão da orientação ao objetos enquanto isso as linguagens de programação também estavam evoluindo e aos poucos programadores começavam a deixar de lado o assemble puro e ganhavam ferramentas mais sofisticadas para trabalhar linguagens como Pascal ganharam um meio acadêmico justamente por incentivarem a clareza a modularização e a legibilidade do código e outras linguagens como algol modula e mais tardeada também foram importantes nesse período porque elas introduziram alguns recursos mais organizados e isso permitia que o código começasse a ser pensado com intenção de longo prazo

só que tudo isso ainda estava no meio acadêmico porque na indústria de fato a realidade era outra e seguia dominada por linguagens como Cobol Fortran e assemble onde os vícios da década anterior ainda estava profundamente enraizado só que o cenário estava mudando e aos poucos os fundamentos estavam sendo propagados e embora a década de 70 não tivesse trago uma revolução imediata foi ela quem plantou as sementes que transformariam completamente a engenharia de software na década seguinte e é com esse novo olhar técnico esse novo compromisso com a qualidade que a gente entra no nosso próximo

marco temporal entramos então na década de 80 enquanto o mundo respirava os primeiros sinais da revolução digital com o avanço dos computadores pessoais um novo pensamento começava a se formar entre programadores do mundo todo a ideia era simples mas poderosa vamos tratar software como algo que precisa de arquitetura e engenharia então é nesse período que começa a ganhar mais força o que a gente chama hoje de engenharia de software foi nessa época também que começou o início da disseminação de um novo paradigma que ganharia o mundo nas décadas seguintes a programação orientada a objetos que

surgiu ainda nos anos 60 com Símula 67 e foi refinada nos anos 70 com Smalt Talkalk mas foi no início dos anos 80 que ela começou a ser popularizada com linguagens como C++ e Objective C que começaram a disseminar a ideia de objetos como unidades de organização e a proposta da orientação objetos era muito clara vamos quebrar o software em partes menores reutilizáveis e isoladas cada uma com uma única responsabilidade era como se o software agora fosse feito de pequenas peças de Lego cada uma com seu papel muito bem definido e isso tudo não era

só uma mudança técnica na forma de programar e de escrever o código era uma mudança de mentalidade então o programador deixava de ser um executor de instruções e passava a ser agora um arquiteto de soluções alguém com capacidade e autonomia de raciocinar sobre o problema e a solução e é nessa mesma época que nascem os primeiros embriões do pensamento que anos depois daria origem aos princípios atualmente conhecido como Sólid foi durante esse período também que ganharam destaques as primeiras tentativas de documentar boas práticas de design de código e a comunidade começa a perceber que existem

melhores e piores formas de escrever um código e isso começa a se espalhar pelo mundo inteiro e é claro que como toda repercussão e toda nova forma de pensar vem acompanhada de resistência muita gente da época achava tudo isso frescura complicação desnecessária e coisa de acadêmico mas o que tava em jogo aqui era muito maior do que o estilo de código ou a forma que você programava era a sustentabilidade dos sistemas porque sistemas mal projetados não escalam não evoluem e não sobrevivem e é exatamente isso que nos leva diretamente pro próximo marco temporal que foi

o grande boom da engenharia de software no mundo todo a década de 90 começa com um ar de confiança técnica a base já tinha sido construída a orientação objeto já tinha ganhado bastante espaço no mercado e a ideia de separar responsabilidades encapsular decisões e projetar sistema já não era mais novidade foi nesse momento que temas como encapsulamento herança polimorfismo e abstração entraram de vez pro Rai só que como nem tudo são flores começaram a surgir os primeiros problemas dessa abordagem orientada a objetos e que dessa vez não era por falta de estrutura era por falta

de padronização cada equipe na época desenvolvia sistemas do seu próprio jeito cada empresa tinha o seu próprio padrão interno e cada novo programador reinventava a roda 300 vezes então é nesse contexto que nascia o primeiro movimento que buscava formalizar as boas práticas de orientação a objetos então em 1994 foi publicado um dos livros mais importantes da história da programação chamado Design Patters ou melhor Padrões de Projeto essa obra catalogou 23 padrões de projeto como Decorator Factory Strategy Observer que viraram referência obrigatória e o impacto foi imediato pela primeira vez na história a comunidade falava a

mesma língua era como se a gente tivesse criado um vocabulário universal para descrever estruturas de software que resolviam problemas mais comuns quando o assunto era desenvolver software orientado a objetos só que a coisa não parou por aí e fica melhor ainda porque em 1995 nascia o lendário Java uma linguagem criada com base em C++ só que com foco em portabilidade e orientação a objetos e legibilidade a promessa do Java era revolucionar escreva uma vez e rode em qualquer lugar e foi assim que o Java se espalhou como fogo no mundo corporativo e com ele veio

a popularização definitiva da orientação a objetos então nesse momento as empresas começaram a migrar as faculdades começaram a ensinar e os frameworks começaram a surgir a partir daí então a orientação a objetos deixava de ser tendência e se tornava o padrão obrigatório do mercado chegando então em 1999 a sensação era de que a gente havia conseguido encontrar o caminho certo de que a crise do software era coisa do passado porque agora a gente tinha a orientação a objetos do nosso lado a gente tinha o nosso próprio catálogo de padrões de projeto e várias novas linguagens

já tinham surgido no mercado como Python PHP Ruby a coisa não parava de melhorar então quando a gente entra nos anos 2000 nascia mais uma lenda o C#ARP da Microsoft para responder à altura à revolução do Java foi nesse mesmo período que começaram a surgir também os primeiros indícios dos famosos princípios Sólid criado por Robert Martin que na verdade juntou o conhecimento de outros grandes nomes da época e sintetizou tudo no acrônimo Solid e que em teoria servia para evitar código frágil acoplado e bagunçado e que ajudou a criar uma geração de programadores muito mais

conscientes do impacto do design de código nas decisões de software só que a evolução na engenharia de software não parou por aí então em 11 de fevereiro de 2001 nas montanhas de Utá nascia o manifesto AG o manifesto que foi descrito por 17 desenvolvedores que estavam cansados da rigidez corporativa e da burocracia nas metodologias de desenvolvimento de software da época essas metodologias priorizavam planejamento e documentação em excesso antes mesmo do software est funcionando em produção além disso elas também tinham longos ciclos de entrega então o manifesto ágil nasce como uma alternativa mais flexível colaborativa e

focada na entrega de valor pro cliente e entre os criadores desse manifesto tínhamos grandes nomes como o próprio Robert Martin Kent Pack Martin Faller e por aí vai e como não é à toa que essas décadas foram conhecidas como a era de ouro da engenharia de software em 2003 temos um novo divisor de águas main driven design de Eric Evvans que trazia uma nova forma da gente desenvolver e pensar sobre software só que agora não era só olhando pro código a ideia agora era a gente modelar software olhando pro domínio do negócio e fazer com

que desenvolvedores e especialistas falassem a mesma língua e criassem sistemas que refletissem a realidade da empresa então foi nessa época que termos como linguagem ubicua entidades agregados repositores começaram a ganhar muita força nas conversas técnicas e como tudo isso era só a ponta do iceberg na nossa evolução técnica da engenharia de software em 2008 vem o tiro de canhão final a publicação do livro Clean Code de Robert Martin que virou quase uma bíblia moderna da programação e se espalhou como fogo no mato seco pelo mundo inteiro código limpo com bons nomes com funções pequenas responsabilidades

bem definidas testes automatizados arquitetura clara simples elegante esse era o grito de guerra da excelência técnica e se você pensa que acabou tá muito enganado logo em seguida vinham os Objectistenics de Jeff Bay com nove regras de ouro para forçar um código coeso desacoplado e orientado a objetos de verdade nada de classe gigante nada de EL nada de Getter e setter espalhado por aí a gente vivia um verdadeiro renascimento técnico design patterns bombando sólid se espalhando clean code nas instantes TDD ganhando espaço Domain Driven Design entrando nas mesas de reunião Kys Dry e Agne virando

tatuagem de programador parecia que a gente finalmente tinha dominado a arte de programar era como se a engenharia de software tivesse alcançado a maturidade suprema porque tudo tinha nome tudo tinha método tinha propósito parecia perfeito só que não era porque quanto mais a gente tentava fazer tudo certo mais a gente começava a errar feio a gente começou a transformar princípios em dogmas em leis padrões em obrigação e cada novo problema simples ganhava uma arquitetura de guerra a simplicidade foi sendo sufocada pelo medo de fazer errado e isso fez com que muitos programadores travassem afinal qual

que era o padrão certo para cada situação a gente acabou criando uma cultura onde o certo era fazer complexo onde uma tela de login simples tinha que ter 18 camadas cinco interfaces sete factories e um command e com isso muita gente começou a confundir complexidade com senioridade as boas práticas deixaram de ser uma ferramenta e viraram muleta de vaidade e foi assim que no auge da excelência técnica a gente pariu o nosso novo vilão o over Engineering traduzindo seria o excesso de engenharia e complexidade desnecessária só que a gente não teve tempo de olhar para

ele porque antes que a comunidade tivesse a chance de refletir sobre o assunto o mundo foi atingido por um novo colapso só que agora financeiro e entre 2007 e 2008 estourou a grande recessão global o colapso no setor imobiliário dos Estados Unidos derrubou bolsas faliu empresas destruiu empregos e colocou o planeta inteiro em estado de alerta empresas de tecnologia começaram a cortar custos projetos foram congelados investimentos sumiram e de repente a última preocupação das empresas era saber se o código do sistema tinha uma arquitetura decente o foco agora era sobreviver e o debate técnico foi

silenciado por uma necessidade muito maior que era manter as luzes acesas então o overineering ficou ali quieto parado escondido esperando a próxima chance de voltar para atormentar a gente e cobrar juros e correção monetária por isso então é diante desse novo caos financeiro que a gente finaliza esse período e vamos entrar no nosso próximo marco temporal entramos então em 2010 e a reessão global já havia finalizado e os primeiros indícios de paz e tranquilidade no mundo começaram a surgir as empresas começaram a se recuperar novas rodadas de investimento voltaram a aparecer e o mercado agora

parecia revigorado e pronto para seguir adiante só que junto com isso nessa mesma época um novo fenômeno começava a se espalhar pelo mundo inteiro os smartphones de repente agora todo mundo tava com computador no bolso e toda empresa de qualquer setor tinha a obrigação de ir pra internet porque quem não estivesse lá estaria fora do mercado competitivo muito em breve e é aqui que começava uma nova corrida desenfreada por presença digital e para acompanhar esse ritmo frameworks robustos poderosos Enterprise como Spring começaram a ganhar muita força no mercado e a adoção deles cresceu quase que

de maneira exponencial e era ali bem ali naquela hora que a gente podia ter corrigido os nossos erros do passado e ter pago todos os nossos pecados a gente podia ter olhado pro excesso de abstrações pros padrões usados sem nenhum tipo de propósito e ter dito: "Chega vamos fazer simples vamos fazer direito" só que não a gente continuou cometendo os mesmos erros do passado nessa época qualquer projeto pequeno ganhava arquitetura de grandes corporações startup com três programadores enfiava domain driven design clean architecture e microsserviço num sistema simples de cadastro de usuário então é nesse momento

é bem aqui que o nosso algó sai da tumba para nos atormentar novamente o overending só que mais uma vez ele vai ter que esperar porque um novo inimigo acabou de aparecer seu irmão gêmeo lembra do manifesto ágil criado lá em 2001 aquele que apareceu para ser leve flexível e humano pois bem ele começou a ser distorcido e deturpado dentro de algumas empresas até perder completamente a essência a daily do scram virou interrogatório a Sprint virou corrida maluca o Camban virou planilha de microgerenciamento o papel do PIO virou gerente de prazo e o dev bom

o Dev virou aquele executor de tarefas bem parecido com aquele lá da década de 60 porque agora só o que importava era entrega era entrega entrega e entrega tudo isso porque as empresas precisavam ir rápido pro digital e quem não tivesse na internet estaria fora do jogo muito antes de conseguir perceber isso então agora já não importava mais a arquitetura não importava mais a coesão não importava mais a qualidade só a entrega importava e foi aí que a gente pariu um novo monstro se por um lado Overengine Engineering era um dos extremos que significava excesso

de engenharia e complexidade desnecessária agora a gente tinha que enfrentar o irmão gêmeo dele o Wonder Engineering que se antes o problema era o excesso agora o problema é a escassez de engenharia sistemas começaram a ser feitos sem estrutura nenhuma regra de negócio jogada dentro de controller classe chamada service que faz tudo manda e-mail consulta banco processa pagamento converte dado desenha tela o importante era funcionar era rodar rápido chegar no mercado antes do concorrente se der bug a gente resolve depois se quebrar a gente faz um Hotfix e esse era o novo cenário que criou

uma geração inteira de desenvolvedores que nunca aprendeu a projetar um sistema que não sabe o mínimo sobre como implementar uma camada de cash simples para aliviar as consultas do banco de dados que nunca pensou em domínio que nunca sequer escreveu um código que durasse mais do que três sprints porque agora tudo era velocidade então agora já tava mais do que na hora da gente voltar atrás e parar para refletir sobre os nossos problemas de engenharia só que quando essas discussões começaram a ganhar a comunidade técnica mais uma vez a gente foi forçado a deixar de

lado todos os nossos débitos técnicos e problemas de engenharia de software para assistir o próximo grande colapso que atingiu o mundo inteiro trazendo causa e destruição por onde passou e isso nos leva pro nosso próximo marco temporal que começa com uma nova crise global agora causada por um inimigo invisível um vírus um colapso de saúde pública sem precedente forçou países inteiros a trancarem suas portas empresas fecharam pessoas foram mandadas para casa e o planeta completamente devastado entrou num isolamento forçado só que o inesperado aconteceu porque logo em seguida no meio disso tudo o software acabou

virando infraestrutura essencial e tudo passou a depender de sistemas digitais reuniões de trabalho aulas consultas médicas pedido de comida relacionamento lazer vida tudo estava na internet quem não estava online foi sepultado e sumiu de vez do mapa e o mercado de tecnologia dessa vez explodiu empresas de software passaram a valer bilhões startups receberam investimentos recordes e as contratações remotas dispararam e de repente algo inédito acontece o programador virou o novo rei do mercado e agora era ele quem dava as cartas ele que decidia onde queria trabalhar ele que decidiu o salário que queria ganhar e

até a modalidade de trabalho e foi nesse mesmo período que análise e desenvolvimento de sistemas se tornava o curso mais procurado nas universidades tinha gente largando emprego para virar programador e as empresas por falta de deves buscava até na cracolândia os seus novos jovens talentos era tudo muito lindo tudo maravilhoso via importância que o setor de tecnologia ganhou no mundo inteiro só que esse crescimento veio com custo muito alto chamado pressão muita pressão pressão para entregar mais rápido pressão para lançar mais features pressão para crescer e pressão para manter as luzes acesas de bilhões de

usuários conectados 24x7 e nesse ritmo insano o pensamento técnico foi mais uma vez deixado de lado porque pensada a trabalho e o que as empresas queriam era código qualquer código desde que entregasse e foi nesse mesmo momento em 28 de maio de 2020 que a Openei apresentou ao mundo o GPT3 um modelo de linguagem poderoso capaz de gerar texto com um nível de coerência nunca antes visto na história logo depois em 2021 tivemos o GitHub Copilot o primeiro grande assistente de código gerado por IA e treinado com bilhões de linhas públicas do GitHub a promessa

era sedutora: digite um comentário e ganhe um bloco de código funcional e isso aí era só a ponta do iceberg porque logo depois vieram outros modelos mais poderosos e mais avançados como chat GPT o Gemini Cursor de PSIC Cloud e por aí vai então em pouco tempo as inteligências artificiais generativas estavam em todo lugar gerando código explicando o código refatorando o código e analisando por request só que o tempo foi passando e depois de toda essa explosão de tecnologia começaram a surgir os primeiros efeitos colaterais algumas empresas já começaram a perceber que a inteligência artificial

tá gerando o código duplicado introduzindo vulnerabilidade criando soluções de procedência duvidosa e montando sistemas que quebram fácil e aí o que ninguém parou para pensar finalmente veio à Tony e a pergunta que não queria calar era como que essas foram treinadas com que dados quem ensinou elas a programar até porque não precisa ser um gênio para saber que as inteligências artificiais generativas não são inteligentes de verdade elas não pensam e a resposta eu acredito que já tá mais do que óbvia e foi por isso que eu te trouxe nessa viagem do tempo enquanto a gente

passava por todas as nossas crises na engenharia de software reaprendendo paradigmas mudando a forma de pensar ou então enfrentando os nossos inimigos como o overgenering ou então o underengineering ou então quando a gente era obrigado a pausar as nossas discussões técnicas a respeito do futuro da engenharia de software por motivos de força maior ou colapsos globais e empurrava toda a sujeira para debaixo do tapete e deixava para depois a inteligência artificial estava lá aprendendo observando imitando ela foi alimentada com tudo que tinha por aí código público stack overflow repositório aleatório documentação incompleta post antigo de

fórum que nem existe mais só para você ter uma ideia os repositórios públicos do GitHub por exemplo estão repletos de código lixo sem teste sem padrão e cheio de gambiarra foi a gente mesmo que alimentou esses modelos de inteligência artificial a Ia aprendeu com a nossa mediocridade e hoje ela tá apenas regurgitando o lixo que a gente jogou lá atrás e não voltou para catar e o programador fascinado com a velocidade não questionou ele aceitou copiou o código colou e subiu em produção e que fique claro aqui que o problema não é usar inteligência artificial

até porque o programador que não usa IA ele tá fora do mercado já o problema é que agora surge uma nova era de programadores que idolatram a terceirização do raciocínio o programador que não resolve mais o problema ele descreve o problema e espera que a IA resolva por ele esse é o verdadeiro nascimento de uma geração de pedintes de código é uma cracolândia digital eles não entendem lógica não sabem o básico de arquitetura não sabem refaturar um código não entendem nada sobre escalabilidade performance paralelismo concorrência mas sabe escrever um prompt sabe pedir sabe copiar sabe

colar e tudo isso sem questionar a inteligência artificial não virou uma ferramenta ela virou uma muleta e junto com ela o pensamento crítico aquele que diferencia o programador de verdade de um papagaio de chat GPT começa a definhar e no meio disso tudo esse movimento ganhou até nome: camiseta bordão e influenciadores em cima disso nasce um novo tipo de programador o programador que não se sente ameaçado por não saber ele se sente confortável ele não quer entender o que tá fazendo ele quer copiar colar e fazer funcionar e é nesse cenário que surge o movimento

que sintetiza todo esse novo espírito vibe coding o que que é vibe coding é apenas um nome bonito para justificar a preguiça é a filosofia que diz que pensar demais atrasa que estudar boas práticas é perda de tempo que arquitetura é frescura e que Solid é coisa do passado para que usar padrão de projeto se o código tá rodando para que testar se o usuário não reclamou para que entender se a IA já fez o Vibe Coding transforma a superficialidade em virtude e o desleixo em estilo é um verdadeiro culto à ignorância enquanto isso o

código nos bastidores das empresas mundo afora vai virando coxa de retalho imprevisível impossível de dar manutenção e que ninguém se atreve a tocar porque foi a IA que fez os sistemas estão ficando cada vez mais frágeis difíceis de escalar lentos repetitivos cheio de código gerado sem sentido ninguém entende mais nada ninguém tem coragem de refaturar ninguém tem nem tempo mais para pensar e raciocinar sobre isso só que enquanto tudo isso está acontecendo neste exato momento a Ia tá lá aprendendo com os nossos novos códigos gerados por ela mesma e que os novos programadores nem sequer

dão o trabalho de conferir eles só copiam colam e botam para funcionar e tudo isso vira um ciclo de medíoccridade que se retroalimenta e bom quer saber de uma coisa a próxima grande crise do software não é mais uma possibilidade ela é só uma questão de tema a engenharia de software tá em colapso não é porque falta ferramenta não é porque falta linguagem não é porque falta mais nada ela tá em colapso porque essa geração parou de pensar e raciocinar e o pior de tudo isso é que agora a maioria tá sentindo orgulho de ser

burro mas se você chegou até aqui é porque você sabe que alguma coisa tá errada você sente que isso tá acontecendo e talvez você seja um dos poucos que ainda se importa se importa em entender o problema antes de escrever a solução se importa em modelar bem antes de abstrair mal se importa em refatorar não porque alguém mandou mas porque você não aceita escrever lixo se importa com a qualidade com a clareza com a engenharia como um todo com a responsabilidade de quem constrói sistemas que impactam o mundo real porque a verdade é dura a

profissão de programador ela não vai ser destruída pelo IA ela vai ser destruída pela preguiça e pela burrice porque a IA ela só reflete ela não decide ela não pensa ela não projeta sistemas ela não conhece o domínio ela não tem empatia pelo usuário ela não sabe o que é certo ou o que é errado no sistema crítico isso ainda é papel do engenheiro do programador do arquiteto de software que entende o impacto de cada linha escrita porque não é o Clean Code que atrasa o projeto é a ausência dele que mata a manutenção não

é o solid que te trava é não entender o que cada módulo deveria fazer não é o doméio do Ren Design que complica é jogar toda a regra de negócio dentro do controle e chamar isso de prático não é arquitetura que te atrás é a preguiça de aprender que causa alergia a conhecimento se a gente quiser salvar engenharia de software a gente vai ter que começar resgatando a responsabilidade técnica a gente vai ter que voltar a estudar os fundamentos você não precisa saber tudo você não precisa ser um Einstein um gênio da programação mas você

precisa querer aprender querer entender precisa ter critério e acima de tudo precisa ter vergonha na cara quando fori escrever um código porque código porco também mata software não roda só na web ele roda em hospitais ele roda em carros autônomos ele roda em aviões e principalmente em equipamentos que mantém pessoas vivas e pode ser um parente seu um filho um amigo dependendo de um sistema desses para continuar vivo e ele acabar falhando porque um animal copiou e colou um código que ele nem sequer teve a decência de questionar agora é contigo m