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

00:29:40
https://www.youtube.com/watch?v=oDXDYjksMds

Resumo

TLDRA engenharia de software enfrenta uma crise sem precedentes, com programadores perdendo habilidades essenciais devido à dependência excessiva de inteligência artificial. A promessa de produtividade da IA trouxe problemas como superficialidade no raciocínio e falta de responsabilidade no desenvolvimento. O texto traça a evolução da engenharia de software desde a década de 60, passando por crises e inovações, até o presente, onde a cultura do 'vibe coding' e a pressão por entregas rápidas comprometem a qualidade do código e a integridade dos sistemas. A solução proposta é resgatar a responsabilidade técnica e valorizar a qualidade do código.

Conclusões

  • ⚠️ A engenharia de software está em crise.
  • 🤖 A dependência de IA está prejudicando habilidades essenciais.
  • 📉 A cultura do 'vibe coding' promove superficialidade.
  • 📚 A responsabilidade técnica deve ser resgatada.
  • 🔍 A qualidade do código é crucial para sistemas críticos.
  • ⏳ A pressão por entregas rápidas compromete a integridade do software.
  • 🛠️ A evolução da programação passou por várias crises e inovações.
  • 💡 A formalização da programação começou nos anos 70.
  • 📖 O manifesto ágil surgiu como uma alternativa às metodologias rígidas.
  • 🚀 A inteligência artificial pode gerar código, mas não substitui o raciocínio humano.

Linha do tempo

  • 00:00:00 - 00:05:00

    A engenharia de software enfrenta uma crise sem precedentes, com programadores perdendo a capacidade de raciocinar e projetar soluções sólidas. A era das inteligências artificiais trouxe produtividade, mas também uma regressão na qualidade do desenvolvimento, onde a entrega se tornou a única prioridade, resultando em códigos frágeis e vulneráveis.

  • 00:05:00 - 00:10:00

    A história da engenharia de software remonta ao final da década de 60, quando a programação era manual e propensa a erros. A crise do software surgiu em 1968, revelando que, apesar do avanço do hardware, o desenvolvimento de software estava fora de controle, com projetos atrasados e sistemas falhando sem explicação. A necessidade de métodos e estruturas formais para lidar com a complexidade se tornou evidente.

  • 00:10:00 - 00:15:00

    Nos anos 70, a programação começou a ser tratada como uma disciplina estruturada, com o surgimento da programação estruturada e conceitos como encapsulamento de decisões. Embora a indústria ainda estivesse presa a linguagens antigas, as sementes para uma nova abordagem na engenharia de software estavam sendo plantadas, preparando o terreno para a evolução que viria na década seguinte.

  • 00:15:00 - 00:20:00

    A década de 80 trouxe a popularização da programação orientada a objetos, que dividiu o software em partes menores e reutilizáveis. Essa mudança de mentalidade transformou programadores em arquitetos de soluções, levando ao desenvolvimento de boas práticas e à documentação de design de código. A sustentabilidade dos sistemas tornou-se uma preocupação central, preparando o caminho para a era de ouro da engenharia de software nos anos 90.

  • 00:20:00 - 00:29:40

    Nos anos 90, a orientação a objetos se consolidou como padrão, mas a falta de padronização gerou problemas. O livro 'Design Patterns' ajudou a formalizar boas práticas, enquanto a linguagem Java popularizou a orientação a objetos. No entanto, a crise do software parecia superada, mas novos desafios surgiram com a necessidade de adaptação a um mercado em rápida evolução, levando a uma nova era de metodologias ágeis e à busca por eficiência.

Mostrar mais

Mapa mental

Vídeo de perguntas e respostas

  • Qual é a principal preocupação atual na engenharia de software?

    A principal preocupação é a perda de habilidades fundamentais de raciocínio e design entre programadores, exacerbada pela dependência de inteligência artificial.

  • O que é 'vibe coding'?

    'Vibe coding' é uma filosofia que desvaloriza o pensamento crítico e a arquitetura de software, promovendo a ideia de que pensar demais é perda de tempo.

  • Como a inteligência artificial impactou a programação?

    A IA facilitou a geração de código, mas também introduziu vulnerabilidades e soluções de baixa qualidade, levando a uma cultura de superficialidade.

  • Quais foram os marcos importantes na evolução da engenharia de software?

    Marcos incluem a crise do software nos anos 60, a formalização da programação nos anos 70, a popularização da orientação a objetos nos anos 80 e a criação do manifesto ágil em 2001.

  • O que causou a crise na engenharia de software?

    A crise é resultado da falta de responsabilidade técnica, superficialidade no desenvolvimento e a pressão por entregas rápidas, exacerbada pela dependência de IA.

  • Qual é a solução proposta para a crise na engenharia de software?

    A solução envolve resgatar a responsabilidade técnica, estudar fundamentos e valorizar a qualidade do código.

Ver mais resumos de vídeos

Obtenha acesso instantâneo a resumos gratuitos de vídeos do YouTube com tecnologia de IA!
Legendas
pt
Rolagem automática:
  • 00:00:00
    Estamos diante de uma crise sem
  • 00:00:01
    precedentes na engenharia de software.
  • 00:00:03
    Uma geração inteira de programadores
  • 00:00:05
    está perdendo a capacidade fundamental
  • 00:00:07
    de raciocinar, projetar e implementar
  • 00:00:09
    soluções sólidas. A era das
  • 00:00:11
    inteligências artificiais, que chegou
  • 00:00:12
    prometendo revolucionar a produtividade,
  • 00:00:15
    acabou trazendo também alguns efeitos
  • 00:00:17
    colaterais. E o que a gente tá vivendo
  • 00:00:18
    hoje não é só uma nova fase da
  • 00:00:20
    tecnologia, uma regressão disfarçada de
  • 00:00:23
    produtividade. E com isso surge uma nova
  • 00:00:25
    era de programadores que acredita que
  • 00:00:27
    pensar demais é desperdício, que
  • 00:00:29
    entender o que tá fazendo é coisa de
  • 00:00:30
    séor arrogante e que projetar software
  • 00:00:33
    com responsabilidade virou frescura e
  • 00:00:35
    perda de tempo. Para somar nessa equação
  • 00:00:37
    e piorar ainda mais o cenário, temos as
  • 00:00:39
    metodologias ágeis que vieram para dar
  • 00:00:41
    leveza ao desenvolvimento de software e
  • 00:00:43
    que foram completamente corrompidas
  • 00:00:45
    dentro das empresas. corrompidas ao
  • 00:00:46
    ponto de que viraram ferramenta de
  • 00:00:49
    microgerenciamento. A daily virou
  • 00:00:50
    interrogatória, a Sprint virou corrida
  • 00:00:52
    maluca e o programador virou entregador
  • 00:00:54
    de tickets. Hoje a cultura dominante é
  • 00:00:56
    entrega, só entrega. Se rodou, tá certo.
  • 00:00:59
    E para que aprendesse, a IA já faz. O
  • 00:01:01
    pior de tudo isso é que já começaram a
  • 00:01:03
    surgir as primeiras rachaduras mostrando
  • 00:01:05
    que o código produzido hoje em dia tá
  • 00:01:07
    cada vez mais porco e os sistemas estão
  • 00:01:09
    mais frágeis e vulneráveis. A engenharia
  • 00:01:11
    de software que a gente conhece tá
  • 00:01:13
    doente. O mais assustador é que essa
  • 00:01:15
    doença não é nova. A gente tá
  • 00:01:17
    desenterrando um monstro que a
  • 00:01:18
    comunidade técnica passou décadas
  • 00:01:20
    tentando vencer. um monstro que já tinha
  • 00:01:22
    sido nomeado, diagnosticado e combatido
  • 00:01:25
    no passado. Só que para entender que
  • 00:01:26
    monstro é esse, como que a gente chegou
  • 00:01:28
    nesse ponto de caos que estamos vivendo
  • 00:01:30
    agora, a gente vai precisar dar uns
  • 00:01:32
    passos para trás e voltar no tempo,
  • 00:01:33
    voltar pro início da queda, voltar pra
  • 00:01:35
    época exata onde a engenharia de
  • 00:01:37
    software perdeu o controle, onde tudo
  • 00:01:39
    começou a desandar. Vamos voltar para
  • 00:01:41
    uma época que ficou conhecida como a
  • 00:01:44
    origem do caos. Sejam bem-vindos à
  • 00:01:47
    história não contada do colapso da
  • 00:01:49
    engenharia de
  • 00:01:53
    software. Voltamos então pro fim da
  • 00:01:56
    década de 60. Computadores ainda
  • 00:01:58
    ocupavam salas inteiras e eram
  • 00:02:00
    acessíveis apenas a governos, exércitos
  • 00:02:02
    e grandes corporações. A programação
  • 00:02:04
    ainda era feita em cartões perfurados e
  • 00:02:06
    tudo era muito manual e artesanal e
  • 00:02:08
    absurdamente propenso a erro. Nessa
  • 00:02:10
    época não existia a engenharia de
  • 00:02:12
    software que a gente conhece como
  • 00:02:13
    disciplina formal, que existia era um
  • 00:02:15
    bando de programadores escrevendo código
  • 00:02:17
    direto no metal, muita das vezes em
  • 00:02:20
    linguagens de máquina ou linguagens mais
  • 00:02:21
    próximas dela, como assembly. E eram
  • 00:02:23
    esses mesmos programadores que lutavam
  • 00:02:26
    insanamente para tentar manter sistemas
  • 00:02:28
    maiores, mais complexos e mais difíceis
  • 00:02:30
    de entender. E foi exatamente nessa
  • 00:02:33
    época que surgiu o que ficou conhecido
  • 00:02:35
    como a crise do software. Esse termo
  • 00:02:37
    surgiu pela primeira vez em 1968,
  • 00:02:40
    durante uma conferência da Otana,
  • 00:02:41
    Alemanha, onde os maiores especialistas
  • 00:02:43
    da época chegaram à conclusão de que,
  • 00:02:45
    apesar do avanço significativo do
  • 00:02:47
    hardware, o desenvolvimento de software
  • 00:02:49
    estava totalmente fora de controle. Os
  • 00:02:51
    projetos da época atrasavam meses ou até
  • 00:02:53
    anos. Os orçamentos sempre estouravam e
  • 00:02:56
    os sistemas quase sempre falhavam no ar.
  • 00:02:58
    E quando falhavam, ninguém sabia
  • 00:03:00
    exatamente o porquê. Além disso, era
  • 00:03:02
    extremamente comum grandes corporações
  • 00:03:04
    perderem milhões de dólares por bugs que
  • 00:03:06
    ninguém conseguia rastrear. O código era
  • 00:03:08
    uma verdadeira bagunça, sem organização,
  • 00:03:11
    sem padrão, sem separação de
  • 00:03:13
    responsabilidade. Era basicamente um
  • 00:03:15
    amontoado de instruções costurada no
  • 00:03:17
    improviso. E o pensamento dominante da
  • 00:03:19
    época era: "Se funcionou, deixa assim".
  • 00:03:21
    Porque a manutenção era um verdadeiro
  • 00:03:23
    pesadelo e qualquer alteração, por menor
  • 00:03:25
    que fosse, podia quebrar o sistema
  • 00:03:27
    inteiro. Nessa época não existia ainda
  • 00:03:29
    teste automatizado, não existia
  • 00:03:30
    versionamento de código, não existia
  • 00:03:32
    controle sobre absolutamente nada. Cada
  • 00:03:34
    software era uma caixa preta escrita por
  • 00:03:36
    um programador que muit das vezes era o
  • 00:03:38
    único que conseguia entender toda aquela
  • 00:03:40
    bagunça e da manutenção. E foi em cima
  • 00:03:42
    desse cenário caótico da crise do
  • 00:03:44
    software que nasceu um consenso
  • 00:03:46
    importante entre a comunidade técnica.
  • 00:03:48
    Se a gente queria continuar evoluindo
  • 00:03:50
    com o software, ia ser preciso criar
  • 00:03:51
    método, criar princípio, criar
  • 00:03:53
    estruturas formais para lidar com a
  • 00:03:55
    complexidade. Então já era mais do que
  • 00:03:57
    na hora da gente parar de escrever
  • 00:03:58
    código no improviso e começar a projetar
  • 00:04:01
    software de verdade. E é exatamente isso
  • 00:04:03
    que nos leva pro nosso próximo marco
  • 00:04:06
    temporal.
  • 00:04:11
    Se a década de 60 terminou com um
  • 00:04:13
    software totalmente fora de controle, a
  • 00:04:15
    década de 70 começou com sentimento
  • 00:04:17
    geral de urgência técnica. Era preciso a
  • 00:04:20
    gente parar e organizar a bagunça. A
  • 00:04:22
    programação, que até então era vista
  • 00:04:23
    como algo quase artesanal, começou a ser
  • 00:04:25
    tratada como uma disciplina estruturada,
  • 00:04:28
    com estudos, métodos e debates sérios
  • 00:04:30
    sobre como escrever um software que não
  • 00:04:32
    desmoronasse com o tempo. E é nessa
  • 00:04:34
    década que surgem os primeiros esforços
  • 00:04:36
    reais para formalizar o desenvolvimento
  • 00:04:38
    de software. A ideia aqui era simples,
  • 00:04:40
    não dava mais pra gente depender só da
  • 00:04:41
    boa vontade do programador. Era preciso
  • 00:04:43
    a gente criar regra, definir estrutura,
  • 00:04:45
    estabelecer boas práticas. E foi
  • 00:04:47
    exatamente isso que começou a acontecer.
  • 00:04:49
    Em 1970, o cientista da computação,
  • 00:04:52
    Edger Dixtra, publica o artigo que
  • 00:04:54
    viraria uma das pedras fundamentais da
  • 00:04:56
    engenharia de software da Apple época. E
  • 00:04:58
    nesse artigo ele denunciava o uso
  • 00:05:00
    desenfriado do Goutu como um dos
  • 00:05:02
    principais responsáveis por códigos
  • 00:05:04
    ilegíveis, caóticos e quase impossíveis
  • 00:05:06
    de manter. A proposta dele era chamada
  • 00:05:09
    programação estruturada, baseada em três
  • 00:05:11
    pilares: sequência, condição, que a
  • 00:05:13
    gente conhece como if else e repetição,
  • 00:05:16
    que a gente conhece como loop. A ideia
  • 00:05:18
    era dar ao fluxo do programa uma
  • 00:05:19
    estrutura previsível, legível e segura.
  • 00:05:22
    E ele não estava sozinho nesse barco,
  • 00:05:24
    porque em 1972, David Parnas traz à tona
  • 00:05:27
    outro conceito revolucionário chamado
  • 00:05:30
    encapsulamento de decisões. Segundo ele,
  • 00:05:32
    um módulo de software não deve expor o
  • 00:05:34
    seu funcionamento interno, mas sim
  • 00:05:36
    oferecer uma interface limpa, clara e
  • 00:05:39
    protegida de alterações futuras. Foi a
  • 00:05:41
    primeira vez que se falou abertamente em
  • 00:05:43
    esconder complexidade através do design
  • 00:05:45
    de código. E isso virou a base para tudo
  • 00:05:48
    que viria anos depois, com a explosão da
  • 00:05:50
    orientação ao objetos. Enquanto isso, as
  • 00:05:52
    linguagens de programação também estavam
  • 00:05:54
    evoluindo e aos poucos programadores
  • 00:05:56
    começavam a deixar de lado o assemble
  • 00:05:58
    puro e ganhavam ferramentas mais
  • 00:05:59
    sofisticadas para trabalhar. Linguagens
  • 00:06:01
    como Pascal ganharam um meio acadêmico
  • 00:06:03
    justamente por incentivarem a clareza, a
  • 00:06:05
    modularização e a legibilidade do
  • 00:06:07
    código. E outras linguagens como algol,
  • 00:06:09
    modula e mais tardeada também foram
  • 00:06:12
    importantes nesse período porque elas
  • 00:06:13
    introduziram alguns recursos mais
  • 00:06:15
    organizados e isso permitia que o código
  • 00:06:17
    começasse a ser pensado com intenção de
  • 00:06:20
    longo prazo. Só que tudo isso ainda
  • 00:06:22
    estava no meio acadêmico, porque na
  • 00:06:23
    indústria de fato a realidade era outra
  • 00:06:25
    e seguia dominada por linguagens como
  • 00:06:27
    Cobol, Fortran e assemble, onde os
  • 00:06:29
    vícios da década anterior ainda estava
  • 00:06:31
    profundamente enraizado. Só que o
  • 00:06:33
    cenário estava mudando e aos poucos os
  • 00:06:36
    fundamentos estavam sendo propagados. E
  • 00:06:38
    embora a década de 70 não tivesse trago
  • 00:06:40
    uma revolução imediata, foi ela quem
  • 00:06:42
    plantou as sementes que transformariam
  • 00:06:45
    completamente a engenharia de software
  • 00:06:46
    na década seguinte. E é com esse novo
  • 00:06:48
    olhar técnico, esse novo compromisso com
  • 00:06:51
    a qualidade que a gente entra no nosso
  • 00:06:53
    próximo marco
  • 00:06:56
    temporal.
  • 00:06:59
    Entramos então na década de 80, enquanto
  • 00:07:02
    o mundo respirava os primeiros sinais da
  • 00:07:05
    revolução digital com o avanço dos
  • 00:07:07
    computadores pessoais, um novo
  • 00:07:08
    pensamento começava a se formar entre
  • 00:07:10
    programadores do mundo todo. A ideia era
  • 00:07:12
    simples, mas poderosa. Vamos tratar
  • 00:07:15
    software como algo que precisa de
  • 00:07:17
    arquitetura e engenharia. Então é nesse
  • 00:07:19
    período que começa a ganhar mais força o
  • 00:07:21
    que a gente chama hoje de engenharia de
  • 00:07:23
    software. Foi nessa época também que
  • 00:07:25
    começou o início da disseminação de um
  • 00:07:27
    novo paradigma que ganharia o mundo nas
  • 00:07:29
    décadas seguintes, a programação
  • 00:07:31
    orientada a objetos, que surgiu ainda
  • 00:07:33
    nos anos 60 com Símula 67 e foi refinada
  • 00:07:36
    nos anos 70 com Smalt Talkalk, mas foi
  • 00:07:38
    no início dos anos 80 que ela começou a
  • 00:07:40
    ser popularizada com linguagens como C++
  • 00:07:43
    e Objective C, que começaram a
  • 00:07:44
    disseminar a ideia de objetos como
  • 00:07:47
    unidades de organização. E a proposta da
  • 00:07:49
    orientação objetos era muito clara.
  • 00:07:51
    Vamos quebrar o software em partes
  • 00:07:53
    menores, reutilizáveis e isoladas, cada
  • 00:07:56
    uma com uma única responsabilidade. Era
  • 00:07:58
    como se o software agora fosse feito de
  • 00:08:00
    pequenas peças de Lego, cada uma com seu
  • 00:08:02
    papel muito bem definido. E isso tudo
  • 00:08:04
    não era só uma mudança técnica na forma
  • 00:08:06
    de programar e de escrever o código, era
  • 00:08:08
    uma mudança de mentalidade. Então, o
  • 00:08:10
    programador deixava de ser um executor
  • 00:08:12
    de instruções e passava a ser agora um
  • 00:08:14
    arquiteto de soluções, alguém com
  • 00:08:15
    capacidade e autonomia de raciocinar
  • 00:08:18
    sobre o problema e a solução. E é nessa
  • 00:08:20
    mesma época que nascem os primeiros
  • 00:08:22
    embriões do pensamento que anos depois
  • 00:08:24
    daria origem aos princípios atualmente
  • 00:08:27
    conhecido como Sólid. Foi durante esse
  • 00:08:28
    período também que ganharam destaques as
  • 00:08:30
    primeiras tentativas de documentar boas
  • 00:08:32
    práticas de design de código e a
  • 00:08:34
    comunidade começa a perceber que existem
  • 00:08:35
    melhores e piores formas de escrever um
  • 00:08:37
    código e isso começa a se espalhar pelo
  • 00:08:39
    mundo inteiro. E é claro que como toda
  • 00:08:41
    repercussão e toda nova forma de pensar
  • 00:08:43
    vem acompanhada de resistência, muita
  • 00:08:46
    gente da época achava tudo isso
  • 00:08:47
    frescura, complicação desnecessária e
  • 00:08:49
    coisa de acadêmico. Mas o que tava em
  • 00:08:51
    jogo aqui era muito maior do que o
  • 00:08:53
    estilo de código ou a forma que você
  • 00:08:55
    programava, era a sustentabilidade dos
  • 00:08:57
    sistemas. Porque sistemas mal projetados
  • 00:08:59
    não escalam, não evoluem e não
  • 00:09:01
    sobrevivem. E é exatamente isso que nos
  • 00:09:03
    leva diretamente pro próximo marco
  • 00:09:05
    temporal, que foi o grande boom da
  • 00:09:08
    engenharia de software no mundo
  • 00:09:14
    todo. A década de 90 começa com um ar de
  • 00:09:17
    confiança técnica. A base já tinha sido
  • 00:09:20
    construída, a orientação objeto já tinha
  • 00:09:21
    ganhado bastante espaço no mercado e a
  • 00:09:23
    ideia de separar responsabilidades,
  • 00:09:25
    encapsular decisões e projetar sistema
  • 00:09:28
    já não era mais novidade. Foi nesse
  • 00:09:30
    momento que temas como encapsulamento,
  • 00:09:32
    herança, polimorfismo e abstração
  • 00:09:34
    entraram de vez pro Rai. Só que como nem
  • 00:09:36
    tudo são flores, começaram a surgir os
  • 00:09:38
    primeiros problemas dessa abordagem
  • 00:09:40
    orientada a objetos e que dessa vez não
  • 00:09:42
    era por falta de estrutura, era por
  • 00:09:43
    falta de padronização. Cada equipe na
  • 00:09:46
    época desenvolvia sistemas do seu
  • 00:09:47
    próprio jeito. Cada empresa tinha o seu
  • 00:09:49
    próprio padrão interno e cada novo
  • 00:09:51
    programador reinventava a roda 300
  • 00:09:54
    vezes. Então é nesse contexto que nascia
  • 00:09:56
    o primeiro movimento que buscava
  • 00:09:58
    formalizar as boas práticas de
  • 00:09:59
    orientação a objetos. Então, em
  • 00:10:02
    1994, foi publicado um dos livros mais
  • 00:10:05
    importantes da história da programação,
  • 00:10:06
    chamado Design Patters, ou melhor,
  • 00:10:09
    Padrões de Projeto. Essa obra catalogou
  • 00:10:12
    23 padrões de projeto, como Decorator,
  • 00:10:15
    Factory, Strategy, Observer, que viraram
  • 00:10:17
    referência obrigatória e o impacto foi
  • 00:10:19
    imediato. Pela primeira vez na história,
  • 00:10:21
    a comunidade falava a mesma língua. Era
  • 00:10:23
    como se a gente tivesse criado um
  • 00:10:25
    vocabulário universal para descrever
  • 00:10:27
    estruturas de software que resolviam
  • 00:10:29
    problemas mais comuns quando o assunto
  • 00:10:31
    era desenvolver software orientado a
  • 00:10:32
    objetos. Só que a coisa não parou por aí
  • 00:10:34
    e fica melhor ainda, porque em 1995
  • 00:10:38
    nascia o lendário Java, uma linguagem
  • 00:10:40
    criada com base em C++, só que com foco
  • 00:10:43
    em portabilidade e orientação a objetos
  • 00:10:45
    e legibilidade. A promessa do Java era
  • 00:10:48
    revolucionar, escreva uma vez e rode em
  • 00:10:50
    qualquer lugar. E foi assim que o Java
  • 00:10:52
    se espalhou como fogo no mundo
  • 00:10:54
    corporativo e com ele veio a
  • 00:10:55
    popularização definitiva da orientação a
  • 00:10:58
    objetos. Então, nesse momento, as
  • 00:11:00
    empresas começaram a migrar, as
  • 00:11:01
    faculdades começaram a ensinar e os
  • 00:11:03
    frameworks começaram a surgir. A partir
  • 00:11:05
    daí, então a orientação a objetos
  • 00:11:07
    deixava de ser tendência e se tornava o
  • 00:11:09
    padrão obrigatório do mercado. Chegando
  • 00:11:11
    então em 1999, a sensação era de que a
  • 00:11:15
    gente havia conseguido encontrar o
  • 00:11:16
    caminho certo, de que a crise do
  • 00:11:18
    software era coisa do passado, porque
  • 00:11:20
    agora a gente tinha a orientação a
  • 00:11:21
    objetos do nosso lado, a gente tinha o
  • 00:11:23
    nosso próprio catálogo de padrões de
  • 00:11:25
    projeto e várias novas linguagens já
  • 00:11:26
    tinham surgido no mercado como Python,
  • 00:11:28
    PHP, Ruby, a coisa não parava de
  • 00:11:31
    melhorar. Então, quando a gente entra
  • 00:11:32
    nos anos 2000, nascia mais uma lenda, o
  • 00:11:35
    C#ARP da Microsoft, para responder à
  • 00:11:38
    altura à revolução do Java. Foi nesse
  • 00:11:40
    mesmo período que começaram a surgir
  • 00:11:42
    também os primeiros indícios dos famosos
  • 00:11:44
    princípios Sólid criado por Robert
  • 00:11:46
    Martin, que na verdade juntou o
  • 00:11:47
    conhecimento de outros grandes nomes da
  • 00:11:49
    época e sintetizou tudo no acrônimo
  • 00:11:51
    Solid e que em teoria servia para evitar
  • 00:11:53
    código frágil, acoplado e bagunçado, e
  • 00:11:55
    que ajudou a criar uma geração de
  • 00:11:57
    programadores muito mais conscientes do
  • 00:11:59
    impacto do design de código nas decisões
  • 00:12:01
    de software. Só que a evolução na
  • 00:12:03
    engenharia de software não parou por aí.
  • 00:12:05
    Então, em 11 de fevereiro de 2001, nas
  • 00:12:08
    montanhas de Utá, nascia o manifesto AG,
  • 00:12:11
    o manifesto que foi descrito por 17
  • 00:12:13
    desenvolvedores que estavam cansados da
  • 00:12:15
    rigidez corporativa e da burocracia nas
  • 00:12:17
    metodologias de desenvolvimento de
  • 00:12:19
    software da época. Essas metodologias
  • 00:12:21
    priorizavam planejamento e documentação
  • 00:12:23
    em excesso antes mesmo do software est
  • 00:12:26
    funcionando em produção. Além disso,
  • 00:12:27
    elas também tinham longos ciclos de
  • 00:12:29
    entrega. Então, o manifesto ágil nasce
  • 00:12:31
    como uma alternativa mais flexível,
  • 00:12:33
    colaborativa e focada na entrega de
  • 00:12:35
    valor pro cliente. E entre os criadores
  • 00:12:37
    desse manifesto, tínhamos grandes nomes
  • 00:12:39
    como o próprio Robert Martin, Kent Pack,
  • 00:12:41
    Martin Faller e por aí vai. E como não é
  • 00:12:43
    à toa que essas décadas foram conhecidas
  • 00:12:45
    como a era de ouro da engenharia de
  • 00:12:47
    software, em 2003 temos um novo divisor
  • 00:12:50
    de águas, main driven design de Eric
  • 00:12:52
    Evvans, que trazia uma nova forma da
  • 00:12:54
    gente desenvolver e pensar sobre
  • 00:12:56
    software, só que agora não era só
  • 00:12:58
    olhando pro código, a ideia agora era a
  • 00:13:00
    gente modelar software olhando pro
  • 00:13:02
    domínio do negócio e fazer com que
  • 00:13:04
    desenvolvedores e especialistas falassem
  • 00:13:06
    a mesma língua e criassem sistemas que
  • 00:13:08
    refletissem a realidade da empresa.
  • 00:13:10
    Então foi nessa época que termos como
  • 00:13:12
    linguagem ubicua, entidades, agregados,
  • 00:13:15
    repositores começaram a ganhar muita
  • 00:13:16
    força nas conversas técnicas. E como
  • 00:13:18
    tudo isso era só a ponta do iceberg na
  • 00:13:21
    nossa evolução técnica da engenharia de
  • 00:13:23
    software, em 2008 vem o tiro de canhão
  • 00:13:26
    final, a publicação do livro Clean Code
  • 00:13:28
    de Robert Martin, que virou quase uma
  • 00:13:30
    bíblia moderna da programação e se
  • 00:13:32
    espalhou como fogo no mato seco pelo
  • 00:13:34
    mundo inteiro. Código limpo, com bons
  • 00:13:36
    nomes, com funções pequenas,
  • 00:13:38
    responsabilidades bem definidas, testes
  • 00:13:40
    automatizados, arquitetura clara,
  • 00:13:42
    simples, elegante. Esse era o grito de
  • 00:13:45
    guerra da excelência técnica. E se você
  • 00:13:47
    pensa que acabou, tá muito enganado.
  • 00:13:49
    Logo em seguida vinham os Objectistenics
  • 00:13:52
    de Jeff Bay com nove regras de ouro para
  • 00:13:54
    forçar um código coeso, desacoplado e
  • 00:13:56
    orientado a objetos de verdade. Nada de
  • 00:13:59
    classe gigante, nada de EL, nada de
  • 00:14:01
    Getter e setter espalhado por aí. A
  • 00:14:03
    gente vivia um verdadeiro renascimento
  • 00:14:05
    técnico. Design patterns bombando, sólid
  • 00:14:08
    se espalhando, clean code nas instantes,
  • 00:14:10
    TDD ganhando espaço, Domain Driven
  • 00:14:12
    Design entrando nas mesas de reunião,
  • 00:14:14
    Kys, Dry e Agne virando tatuagem de
  • 00:14:16
    programador. Parecia que a gente
  • 00:14:18
    finalmente tinha dominado a arte de
  • 00:14:20
    programar. Era como se a engenharia de
  • 00:14:22
    software tivesse alcançado a maturidade
  • 00:14:24
    suprema, porque tudo tinha nome, tudo
  • 00:14:26
    tinha método, tinha propósito, parecia
  • 00:14:29
    perfeito, só que não era, porque quanto
  • 00:14:32
    mais a gente tentava fazer tudo certo,
  • 00:14:35
    mais a gente começava a errar feio. A
  • 00:14:37
    gente começou a transformar princípios
  • 00:14:39
    em dogmas, em leis, padrões em obrigação
  • 00:14:42
    e cada novo problema simples ganhava uma
  • 00:14:44
    arquitetura de guerra. A simplicidade
  • 00:14:47
    foi sendo sufocada pelo medo de fazer
  • 00:14:50
    errado e isso fez com que muitos
  • 00:14:52
    programadores travassem. Afinal, qual
  • 00:14:54
    que era o padrão certo para cada
  • 00:14:56
    situação? A gente acabou criando uma
  • 00:14:57
    cultura onde o certo era fazer complexo,
  • 00:15:00
    onde uma tela de login simples tinha que
  • 00:15:01
    ter 18 camadas, cinco interfaces, sete
  • 00:15:04
    factories e um command. E com isso,
  • 00:15:06
    muita gente começou a confundir
  • 00:15:08
    complexidade com senioridade. As boas
  • 00:15:11
    práticas deixaram de ser uma ferramenta
  • 00:15:13
    e viraram muleta de vaidade. E foi assim
  • 00:15:15
    que no auge da excelência técnica a
  • 00:15:18
    gente pariu o nosso novo vilão, o over
  • 00:15:20
    Engineering, traduzindo, seria o excesso
  • 00:15:22
    de engenharia e complexidade
  • 00:15:24
    desnecessária. Só que a gente não teve
  • 00:15:26
    tempo de olhar para ele, porque antes
  • 00:15:28
    que a comunidade tivesse a chance de
  • 00:15:29
    refletir sobre o assunto, o mundo foi
  • 00:15:31
    atingido por um novo colapso, só que
  • 00:15:33
    agora financeiro. E entre 2007 e 2008,
  • 00:15:37
    estourou a grande recessão global. O
  • 00:15:38
    colapso no setor imobiliário dos Estados
  • 00:15:40
    Unidos derrubou bolsas, faliu empresas,
  • 00:15:42
    destruiu empregos e colocou o planeta
  • 00:15:44
    inteiro em estado de alerta. Empresas de
  • 00:15:47
    tecnologia começaram a cortar custos,
  • 00:15:49
    projetos foram congelados, investimentos
  • 00:15:51
    sumiram e de repente a última
  • 00:15:53
    preocupação das empresas era saber se o
  • 00:15:55
    código do sistema tinha uma arquitetura
  • 00:15:57
    decente. O foco agora era sobreviver e o
  • 00:15:59
    debate técnico foi silenciado por uma
  • 00:16:02
    necessidade muito maior que era manter
  • 00:16:04
    as luzes acesas. Então o overineering
  • 00:16:06
    ficou ali quieto, parado, escondido,
  • 00:16:09
    esperando a próxima chance de voltar
  • 00:16:11
    para atormentar a gente e cobrar juros e
  • 00:16:14
    correção monetária por isso. Então é
  • 00:16:15
    diante desse novo caos financeiro que a
  • 00:16:18
    gente finaliza esse período e vamos
  • 00:16:19
    entrar no nosso próximo marco
  • 00:16:24
    temporal.
  • 00:16:27
    Entramos então em 2010 e a reessão
  • 00:16:30
    global já havia finalizado e os
  • 00:16:32
    primeiros indícios de paz e
  • 00:16:34
    tranquilidade no mundo começaram a
  • 00:16:35
    surgir. As empresas começaram a se
  • 00:16:37
    recuperar, novas rodadas de investimento
  • 00:16:39
    voltaram a aparecer e o mercado agora
  • 00:16:41
    parecia revigorado e pronto para seguir
  • 00:16:43
    adiante. Só que junto com isso, nessa
  • 00:16:45
    mesma época, um novo fenômeno começava a
  • 00:16:47
    se espalhar pelo mundo inteiro, os
  • 00:16:49
    smartphones. De repente, agora todo
  • 00:16:52
    mundo tava com computador no bolso e
  • 00:16:54
    toda empresa de qualquer setor tinha a
  • 00:16:56
    obrigação de ir pra internet, porque
  • 00:16:58
    quem não estivesse lá estaria fora do
  • 00:17:00
    mercado competitivo muito em breve. E é
  • 00:17:02
    aqui que começava uma nova corrida
  • 00:17:05
    desenfreada por presença digital. E para
  • 00:17:07
    acompanhar esse ritmo, frameworks
  • 00:17:09
    robustos, poderosos, Enterprise como
  • 00:17:12
    Spring, começaram a ganhar muita força
  • 00:17:14
    no mercado e a adoção deles cresceu
  • 00:17:16
    quase que de maneira exponencial. E era
  • 00:17:18
    ali, bem ali, naquela hora, que a gente
  • 00:17:20
    podia ter corrigido os nossos erros do
  • 00:17:22
    passado e ter pago todos os nossos
  • 00:17:24
    pecados. A gente podia ter olhado pro
  • 00:17:26
    excesso de abstrações, pros padrões
  • 00:17:28
    usados sem nenhum tipo de propósito e
  • 00:17:30
    ter dito: "Chega, vamos fazer simples,
  • 00:17:32
    vamos fazer direito". Só que não. A
  • 00:17:34
    gente continuou cometendo os mesmos
  • 00:17:36
    erros do passado. Nessa época, qualquer
  • 00:17:38
    projeto pequeno ganhava arquitetura de
  • 00:17:40
    grandes corporações. Startup com três
  • 00:17:43
    programadores enfiava domain driven
  • 00:17:45
    design, clean architecture e
  • 00:17:46
    microsserviço num sistema simples de
  • 00:17:48
    cadastro de usuário. Então é nesse
  • 00:17:50
    momento, é bem aqui que o nosso algó sai
  • 00:17:52
    da tumba para nos atormentar novamente.
  • 00:17:54
    O overending. Só que mais uma vez ele
  • 00:17:57
    vai ter que esperar porque um novo
  • 00:17:59
    inimigo acabou de aparecer, seu irmão
  • 00:18:02
    gêmeo. Lembra do manifesto ágil criado
  • 00:18:05
    lá em 2001? Aquele que apareceu para ser
  • 00:18:07
    leve, flexível e humano? Pois bem, ele
  • 00:18:10
    começou a ser distorcido e deturpado
  • 00:18:12
    dentro de algumas empresas até perder
  • 00:18:14
    completamente a essência. A daily do
  • 00:18:16
    scram virou interrogatório, a Sprint
  • 00:18:18
    virou corrida maluca, o Camban virou
  • 00:18:20
    planilha de microgerenciamento, o papel
  • 00:18:22
    do PIO virou gerente de prazo. E o dev,
  • 00:18:24
    bom, o Dev virou aquele executor de
  • 00:18:27
    tarefas, bem parecido com aquele lá da
  • 00:18:29
    década de 60, porque agora só o que
  • 00:18:31
    importava era entrega, era entrega,
  • 00:18:34
    entrega e entrega. Tudo isso porque as
  • 00:18:36
    empresas precisavam ir rápido pro
  • 00:18:38
    digital e quem não tivesse na internet
  • 00:18:40
    estaria fora do jogo muito antes de
  • 00:18:42
    conseguir perceber isso. Então agora já
  • 00:18:43
    não importava mais a arquitetura, não
  • 00:18:45
    importava mais a coesão, não importava
  • 00:18:47
    mais a qualidade, só a entrega
  • 00:18:50
    importava. E foi aí que a gente pariu um
  • 00:18:53
    novo monstro. Se por um lado Overengine
  • 00:18:55
    Engineering era um dos extremos que
  • 00:18:56
    significava excesso de engenharia e
  • 00:18:58
    complexidade desnecessária, agora a
  • 00:19:00
    gente tinha que enfrentar o irmão gêmeo
  • 00:19:02
    dele, o Wonder Engineering, que se antes
  • 00:19:04
    o problema era o excesso, agora o
  • 00:19:06
    problema é a escassez de engenharia.
  • 00:19:08
    Sistemas começaram a ser feitos sem
  • 00:19:10
    estrutura nenhuma, regra de negócio
  • 00:19:12
    jogada dentro de controller, classe
  • 00:19:13
    chamada service que faz tudo, manda
  • 00:19:15
    e-mail, consulta banco, processa
  • 00:19:17
    pagamento, converte dado, desenha tela.
  • 00:19:19
    O importante era funcionar, era rodar
  • 00:19:22
    rápido, chegar no mercado antes do
  • 00:19:24
    concorrente. Se der bug, a gente resolve
  • 00:19:26
    depois, se quebrar, a gente faz um
  • 00:19:28
    Hotfix. E esse era o novo cenário que
  • 00:19:30
    criou uma geração inteira de
  • 00:19:32
    desenvolvedores que nunca aprendeu a
  • 00:19:35
    projetar um sistema, que não sabe o
  • 00:19:36
    mínimo sobre como implementar uma camada
  • 00:19:38
    de cash simples para aliviar as
  • 00:19:40
    consultas do banco de dados, que nunca
  • 00:19:41
    pensou em domínio, que nunca sequer
  • 00:19:43
    escreveu um código que durasse mais do
  • 00:19:45
    que três sprints, porque agora tudo era
  • 00:19:47
    velocidade. Então agora já tava mais do
  • 00:19:49
    que na hora da gente voltar atrás e
  • 00:19:51
    parar para refletir sobre os nossos
  • 00:19:53
    problemas de engenharia. Só que quando
  • 00:19:55
    essas discussões começaram a ganhar a
  • 00:19:57
    comunidade técnica, mais uma vez a gente
  • 00:19:59
    foi forçado a deixar de lado todos os
  • 00:20:02
    nossos débitos técnicos e problemas de
  • 00:20:04
    engenharia de software para assistir o
  • 00:20:06
    próximo grande colapso que atingiu o
  • 00:20:08
    mundo inteiro, trazendo causa e
  • 00:20:10
    destruição por onde passou. E isso nos
  • 00:20:12
    leva pro nosso próximo marco temporal,
  • 00:20:14
    que começa com uma nova crise global,
  • 00:20:16
    agora causada por um inimigo invisível,
  • 00:20:19
    um vírus.
  • 00:20:26
    Um colapso de saúde pública sem
  • 00:20:28
    precedente forçou países inteiros a
  • 00:20:30
    trancarem suas portas. Empresas
  • 00:20:32
    fecharam, pessoas foram mandadas para
  • 00:20:34
    casa e o planeta completamente devastado
  • 00:20:36
    entrou num isolamento forçado. Só que o
  • 00:20:39
    inesperado aconteceu porque logo em
  • 00:20:41
    seguida, no meio disso tudo, o software
  • 00:20:43
    acabou virando infraestrutura essencial.
  • 00:20:46
    E tudo passou a depender de sistemas
  • 00:20:48
    digitais, reuniões de trabalho, aulas,
  • 00:20:50
    consultas médicas, pedido de comida,
  • 00:20:52
    relacionamento, lazer, vida, tudo estava
  • 00:20:55
    na internet. Quem não estava online foi
  • 00:20:57
    sepultado e sumiu de vez do mapa e o
  • 00:20:59
    mercado de tecnologia dessa vez
  • 00:21:02
    explodiu. Empresas de software passaram
  • 00:21:04
    a valer bilhões, startups receberam
  • 00:21:06
    investimentos recordes e as contratações
  • 00:21:08
    remotas dispararam. E de repente algo
  • 00:21:11
    inédito acontece. O programador virou o
  • 00:21:14
    novo rei do mercado e agora era ele quem
  • 00:21:17
    dava as cartas, ele que decidia onde
  • 00:21:19
    queria trabalhar, ele que decidiu o
  • 00:21:21
    salário que queria ganhar e até a
  • 00:21:22
    modalidade de trabalho. E foi nesse
  • 00:21:24
    mesmo período que análise e
  • 00:21:26
    desenvolvimento de sistemas se tornava o
  • 00:21:28
    curso mais procurado nas universidades.
  • 00:21:30
    Tinha gente largando emprego para virar
  • 00:21:32
    programador e as empresas, por falta de
  • 00:21:34
    deves, buscava até na cracolândia os
  • 00:21:36
    seus novos jovens talentos. Era tudo
  • 00:21:39
    muito lindo, tudo maravilhoso, via
  • 00:21:40
    importância que o setor de tecnologia
  • 00:21:42
    ganhou no mundo inteiro. Só que esse
  • 00:21:44
    crescimento veio com custo muito alto,
  • 00:21:47
    chamado pressão, muita pressão. Pressão
  • 00:21:49
    para entregar mais rápido, pressão para
  • 00:21:51
    lançar mais features, pressão para
  • 00:21:52
    crescer e pressão para manter as luzes
  • 00:21:54
    acesas de bilhões de usuários conectados
  • 00:21:57
    24x7. E nesse ritmo insano, o pensamento
  • 00:22:00
    técnico foi mais uma vez deixado de
  • 00:22:03
    lado, porque pensada a trabalho e o que
  • 00:22:05
    as empresas queriam era código, qualquer
  • 00:22:07
    código, desde que entregasse. E foi
  • 00:22:10
    nesse mesmo momento, em 28 de maio de
  • 00:22:12
    2020, que a Openei apresentou ao mundo o
  • 00:22:15
    GPT3, um modelo de linguagem poderoso
  • 00:22:18
    capaz de gerar texto com um nível de
  • 00:22:19
    coerência nunca antes visto na história.
  • 00:22:22
    Logo depois, em 2021, tivemos o GitHub
  • 00:22:25
    Copilot, o primeiro grande assistente de
  • 00:22:27
    código gerado por IA e treinado com
  • 00:22:29
    bilhões de linhas públicas do GitHub. A
  • 00:22:31
    promessa era sedutora: digite um
  • 00:22:33
    comentário e ganhe um bloco de código
  • 00:22:35
    funcional. E isso aí era só a ponta do
  • 00:22:37
    iceberg, porque logo depois vieram
  • 00:22:39
    outros modelos mais poderosos e mais
  • 00:22:41
    avançados, como chat GPT, o Gemini,
  • 00:22:43
    Cursor, de PSIC, Cloud e por aí vai.
  • 00:22:45
    Então, em pouco tempo, as inteligências
  • 00:22:47
    artificiais generativas estavam em todo
  • 00:22:50
    lugar, gerando código, explicando o
  • 00:22:52
    código, refatorando o código e
  • 00:22:53
    analisando por request. Só que o tempo
  • 00:22:55
    foi passando e depois de toda essa
  • 00:22:57
    explosão de tecnologia começaram a
  • 00:22:59
    surgir os primeiros efeitos colaterais.
  • 00:23:02
    Algumas empresas já começaram a perceber
  • 00:23:03
    que a inteligência artificial tá gerando
  • 00:23:05
    o código duplicado, introduzindo
  • 00:23:07
    vulnerabilidade, criando soluções de
  • 00:23:08
    procedência duvidosa e montando sistemas
  • 00:23:11
    que quebram fácil. E aí, o que ninguém
  • 00:23:13
    parou para pensar, finalmente veio à
  • 00:23:15
    Tony. E a pergunta que não queria calar
  • 00:23:18
    era como que essas foram treinadas, com
  • 00:23:21
    que dados? Quem ensinou elas a
  • 00:23:23
    programar? Até porque não precisa ser um
  • 00:23:25
    gênio para saber que as inteligências
  • 00:23:27
    artificiais generativas não são
  • 00:23:29
    inteligentes de verdade, elas não
  • 00:23:31
    pensam. E a resposta, eu acredito que já
  • 00:23:33
    tá mais do que óbvia. E foi por isso que
  • 00:23:35
    eu te trouxe nessa viagem do tempo,
  • 00:23:37
    enquanto a gente passava por todas as
  • 00:23:39
    nossas crises na engenharia de software,
  • 00:23:41
    reaprendendo paradigmas, mudando a forma
  • 00:23:44
    de pensar, ou então enfrentando os
  • 00:23:45
    nossos inimigos como o overgenering, ou
  • 00:23:48
    então o underengineering, ou então
  • 00:23:49
    quando a gente era obrigado a pausar as
  • 00:23:51
    nossas discussões técnicas a respeito do
  • 00:23:53
    futuro da engenharia de software por
  • 00:23:55
    motivos de força maior ou colapsos
  • 00:23:57
    globais e empurrava toda a sujeira para
  • 00:23:59
    debaixo do tapete e deixava para depois,
  • 00:24:02
    a inteligência artificial estava lá.
  • 00:24:04
    aprendendo, observando, imitando. Ela
  • 00:24:06
    foi alimentada com tudo que tinha por
  • 00:24:08
    aí. Código público, stack overflow,
  • 00:24:11
    repositório aleatório, documentação
  • 00:24:13
    incompleta, post antigo de fórum que nem
  • 00:24:15
    existe mais. Só para você ter uma ideia,
  • 00:24:18
    os repositórios públicos do GitHub, por
  • 00:24:20
    exemplo, estão repletos de código lixo,
  • 00:24:22
    sem teste, sem padrão e cheio de
  • 00:24:25
    gambiarra. Foi a gente mesmo que
  • 00:24:26
    alimentou esses modelos de inteligência
  • 00:24:28
    artificial. A Ia aprendeu com a nossa
  • 00:24:30
    mediocridade e hoje ela tá apenas
  • 00:24:32
    regurgitando o lixo que a gente jogou lá
  • 00:24:35
    atrás e não voltou para catar. E o
  • 00:24:37
    programador fascinado com a velocidade
  • 00:24:39
    não questionou. Ele aceitou, copiou o
  • 00:24:42
    código, colou e subiu em produção. E que
  • 00:24:45
    fique claro aqui que o problema não é
  • 00:24:47
    usar inteligência artificial, até porque
  • 00:24:49
    o programador que não usa IA, ele tá
  • 00:24:51
    fora do mercado já. O problema é que
  • 00:24:53
    agora surge uma nova era de
  • 00:24:55
    programadores que idolatram a
  • 00:24:57
    terceirização do raciocínio. O
  • 00:24:58
    programador que não resolve mais o
  • 00:25:00
    problema, ele descreve o problema e
  • 00:25:02
    espera que a IA resolva por ele. Esse é
  • 00:25:05
    o verdadeiro nascimento de uma geração
  • 00:25:07
    de pedintes de código. É uma cracolândia
  • 00:25:10
    digital. Eles não entendem lógica, não
  • 00:25:12
    sabem o básico de arquitetura, não sabem
  • 00:25:14
    refaturar um código, não entendem nada
  • 00:25:16
    sobre escalabilidade, performance,
  • 00:25:18
    paralelismo, concorrência, mas sabe
  • 00:25:20
    escrever um prompt, sabe pedir, sabe
  • 00:25:22
    copiar, sabe colar e tudo isso sem
  • 00:25:25
    questionar. A inteligência artificial
  • 00:25:27
    não virou uma ferramenta, ela virou uma
  • 00:25:29
    muleta. E junto com ela o pensamento
  • 00:25:31
    crítico, aquele que diferencia o
  • 00:25:33
    programador de verdade de um papagaio de
  • 00:25:34
    chat GPT, começa a definhar e no meio
  • 00:25:37
    disso tudo, esse movimento ganhou até
  • 00:25:39
    nome: camiseta, bordão e
  • 00:25:41
    influenciadores. Em cima disso, nasce um
  • 00:25:44
    novo tipo de programador. O programador
  • 00:25:45
    que não se sente ameaçado por não saber,
  • 00:25:48
    ele se sente confortável, ele não quer
  • 00:25:50
    entender o que tá fazendo, ele quer
  • 00:25:51
    copiar, colar e fazer funcionar. E é
  • 00:25:54
    nesse cenário que surge o movimento que
  • 00:25:57
    sintetiza todo esse novo espírito, vibe
  • 00:26:00
    coding. O que que é vibe coding? É
  • 00:26:02
    apenas um nome bonito para justificar a
  • 00:26:03
    preguiça. É a filosofia que diz que
  • 00:26:05
    pensar demais atrasa, que estudar boas
  • 00:26:08
    práticas é perda de tempo, que
  • 00:26:09
    arquitetura é frescura e que Solid é
  • 00:26:12
    coisa do passado. Para que usar padrão
  • 00:26:14
    de projeto se o código tá rodando? Para
  • 00:26:16
    que testar se o usuário não reclamou?
  • 00:26:18
    Para que entender se a IA já fez? O Vibe
  • 00:26:20
    Coding transforma a superficialidade em
  • 00:26:22
    virtude e o desleixo em estilo é um
  • 00:26:25
    verdadeiro culto à ignorância. Enquanto
  • 00:26:28
    isso, o código nos bastidores das
  • 00:26:30
    empresas mundo afora, vai virando coxa
  • 00:26:32
    de retalho imprevisível, impossível de
  • 00:26:35
    dar manutenção e que ninguém se atreve a
  • 00:26:37
    tocar, porque foi a IA que fez. Os
  • 00:26:39
    sistemas estão ficando cada vez mais
  • 00:26:41
    frágeis, difíceis de escalar, lentos,
  • 00:26:43
    repetitivos, cheio de código gerado, sem
  • 00:26:45
    sentido. Ninguém entende mais nada,
  • 00:26:47
    ninguém tem coragem de refaturar,
  • 00:26:48
    ninguém tem nem tempo mais para pensar e
  • 00:26:50
    raciocinar sobre isso. Só que enquanto
  • 00:26:52
    tudo isso está acontecendo neste exato
  • 00:26:55
    momento, a Ia tá lá aprendendo com os
  • 00:26:58
    nossos novos códigos gerados por ela
  • 00:27:00
    mesma e que os novos programadores nem
  • 00:27:02
    sequer dão o trabalho de conferir. Eles
  • 00:27:04
    só copiam, colam e botam para funcionar.
  • 00:27:07
    E tudo isso vira um ciclo de
  • 00:27:09
    medíoccridade que se retroalimenta. E
  • 00:27:11
    bom, quer saber de uma coisa? A próxima
  • 00:27:14
    grande crise do software não é mais uma
  • 00:27:16
    possibilidade, ela é só uma questão de
  • 00:27:19
    tema. A engenharia de software tá em
  • 00:27:20
    colapso, não é porque falta ferramenta,
  • 00:27:22
    não é porque falta linguagem, não é
  • 00:27:24
    porque falta mais nada. Ela tá em
  • 00:27:26
    colapso porque essa geração parou de
  • 00:27:28
    pensar e raciocinar. E o pior de tudo
  • 00:27:31
    isso é que agora a maioria tá sentindo
  • 00:27:33
    orgulho de ser burro. Mas se você chegou
  • 00:27:36
    até aqui, é porque você sabe que alguma
  • 00:27:37
    coisa tá errada. Você sente que isso tá
  • 00:27:39
    acontecendo e talvez você seja um dos
  • 00:27:41
    poucos que ainda se importa. Se importa
  • 00:27:43
    em entender o problema antes de escrever
  • 00:27:45
    a solução? Se importa em modelar bem
  • 00:27:47
    antes de abstrair mal? Se importa em
  • 00:27:48
    refatorar? Não porque alguém mandou, mas
  • 00:27:51
    porque você não aceita escrever lixo. Se
  • 00:27:53
    importa com a qualidade, com a clareza,
  • 00:27:55
    com a engenharia como um todo, com a
  • 00:27:57
    responsabilidade de quem constrói
  • 00:27:59
    sistemas que impactam o mundo real.
  • 00:28:01
    Porque a verdade é dura. A profissão de
  • 00:28:03
    programador, ela não vai ser destruída
  • 00:28:05
    pelo IA, ela vai ser destruída pela
  • 00:28:07
    preguiça e pela burrice. Porque a IA ela
  • 00:28:09
    só reflete, ela não decide, ela não
  • 00:28:11
    pensa, ela não projeta sistemas, ela não
  • 00:28:13
    conhece o domínio, ela não tem empatia
  • 00:28:15
    pelo usuário, ela não sabe o que é certo
  • 00:28:17
    ou o que é errado no sistema crítico.
  • 00:28:19
    Isso ainda é papel do engenheiro, do
  • 00:28:21
    programador, do arquiteto de software
  • 00:28:23
    que entende o impacto de cada linha
  • 00:28:25
    escrita, porque não é o Clean Code que
  • 00:28:27
    atrasa o projeto, é a ausência dele que
  • 00:28:29
    mata a manutenção, não é o solid que te
  • 00:28:31
    trava, é não entender o que cada módulo
  • 00:28:33
    deveria fazer, não é o doméio do Ren
  • 00:28:35
    Design que complica, é jogar toda a
  • 00:28:37
    regra de negócio dentro do controle e
  • 00:28:39
    chamar isso de prático. Não é
  • 00:28:40
    arquitetura que te atrás, é a preguiça
  • 00:28:42
    de aprender que causa alergia a
  • 00:28:44
    conhecimento. Se a gente quiser salvar
  • 00:28:46
    engenharia de software, a gente vai ter
  • 00:28:48
    que começar resgatando a
  • 00:28:50
    responsabilidade técnica. A gente vai
  • 00:28:52
    ter que voltar a estudar os fundamentos.
  • 00:28:54
    Você não precisa saber tudo. Você não
  • 00:28:55
    precisa ser um Einstein, um gênio da
  • 00:28:57
    programação. Mas você precisa querer
  • 00:28:59
    aprender, querer entender, precisa ter
  • 00:29:01
    critério e, acima de tudo, precisa ter
  • 00:29:03
    vergonha na cara quando fori escrever um
  • 00:29:05
    código. Porque código porco também mata.
  • 00:29:07
    Software não roda só na web. Ele roda em
  • 00:29:10
    hospitais, ele roda em carros autônomos,
  • 00:29:12
    ele roda em aviões e principalmente em
  • 00:29:14
    equipamentos que mantém pessoas vivas. E
  • 00:29:17
    pode ser um parente seu, um filho, um
  • 00:29:19
    amigo, dependendo de um sistema desses,
  • 00:29:21
    para continuar vivo e ele acabar
  • 00:29:23
    falhando, porque um animal copiou e
  • 00:29:25
    colou um código que ele nem sequer teve
  • 00:29:27
    a decência de questionar.
  • 00:29:30
    Agora é contigo. M.
Etiquetas
  • engenharia de software
  • inteligência artificial
  • vibe coding
  • crise do software
  • programação
  • qualidade do código
  • responsabilidade técnica
  • evolução da programação
  • metodologias ágeis
  • design de software