Eu publiquei código que não entendo — e aposto que você também

AAI Engineer
Computing/SoftwareManagementInternet Technology

Transcript

00:00:00[MÚSICA]
00:00:21>> Olá a todos, boa tarde.
00:00:22Vou começar minha palestra com uma confissão.
00:00:26Enviei códigos que eu não entendia direito.
00:00:29Eu os gerava, testava, implantava, mas não sabia explicar como funcionavam.
00:00:33E quer saber? Aposto que todos vocês também já fizeram isso.
00:00:37>> [RISOS]
00:00:40>> Agora que todos admitimos que enviamos
00:00:41códigos que não entendemos mais, quero fazer uma jornada,
00:00:44para ver como chegamos a esse ponto.
00:00:46Primeiro, olharemos para o passado; a história tende a se repetir.
00:00:50Segundo, caímos em uma armadilha.
00:00:52Confundimos o que é "fácil" com o que é "simples".
00:00:55Por fim, há uma solução, mas ela exige que não terceirizemos nosso raciocínio.
00:01:00Passei os últimos anos na Netflix ajudando a impulsionar a adoção de ferramentas de IA.
00:01:05E devo dizer que a aceleração é absolutamente real.
00:01:07Itens do backlog que levavam dias agora levam horas.
00:01:10E grandes refatorações que estavam paradas há anos finalmente estão saindo do papel.
00:01:15Mas o problema é o seguinte.
00:01:16Grandes sistemas de produção sempre falham de formas inesperadas.
00:01:19Vejam o que aconteceu com a Cloudflare recentemente.
00:01:21Quando isso ocorre, é bom você entender o código que está depurando.
00:01:23E o problema agora é que geramos código em tal velocidade e volume,
00:01:28que nossa compreensão está tendo dificuldade para acompanhar.
00:01:29Eu sei bem, eu mesmo já fiz isso.
00:01:34Gerei um monte de código, olhei para ele e pensei: "Não faço ideia do que isso faz".
00:01:39Mas os testes passaram, funcionou, então eu enviei.
00:01:41A questão é que isso não é exatamente novo.
00:01:44Cada geração de engenheiros de software acaba batendo em um muro onde a
00:01:48complexidade do software excede a capacidade de gerenciá-la.
00:01:50Não somos os primeiros a enfrentar uma crise de software,
00:01:52mas somos os primeiros a enfrentá-la nesta escala infinita de geração.
00:01:56Então, vamos dar um passo atrás para ver onde tudo começou.
00:01:58No final dos anos 60 e início dos 70, cientistas da computação brilhantes
00:02:03se reuniram e disseram: "Ei, estamos em uma crise de software".
00:02:06"Temos uma demanda enorme por software, mas não conseguimos dar conta".
00:02:11"Os projetos estão demorando muito e tudo está muito lento".
00:02:15"Não estamos fazendo um bom trabalho".
00:02:16Então, Dijkstra soltou uma frase excelente.
00:02:20Ele disse — parafraseando uma citação mais longa — que quando
00:02:23tínhamos poucos computadores fracos, a programação era um problema leve.
00:02:26Agora que temos computadores gigantescos, a programação se tornou um problema gigante.
00:02:31Ele explicou que, conforme a potência do hardware crescia por um fator de 1.000,
00:02:34o desejo da sociedade por software crescia na mesma proporção.
00:02:37E assim sobrou para nós, programadores, descobrir entre os meios e os fins,
00:02:41como suportar esse volume muito maior de software.
00:02:43Isso continua acontecendo em ciclos.
00:02:47Nos anos 70, surgiu a linguagem C, para podermos escrever sistemas maiores.
00:02:50Nos anos 80, surgiram os computadores pessoais; agora todos podiam escrever software.
00:02:53Nos anos 90, veio a programação orientada a objetos.
00:02:56Hierarquias de herança infernais — obrigado por isso, Java.
00:03:00Nos anos 2000, tivemos o Agile, com sprints e
00:03:03Scrum Masters nos dizendo o que fazer; o modelo cascata acabou.
00:03:06Nos anos 2010, tivemos a nuvem, o mobile, o DevOps... tudo.
00:03:09O software realmente dominou o mundo.
00:03:10E hoje temos IA: Co-Pilot, Cursor, Claude, Codex, Gemini e por aí vai.
00:03:17Podemos gerar código na mesma velocidade com que o descrevemos.
00:03:19O padrão continua, mas a escala mudou radicalmente; agora é infinita.
00:03:23Fred Brooks — vocês devem conhecê-lo pelo livro "O Mítico Homem-Mês".
00:03:29Ele também escreveu um artigo em 1986 chamado "No Silver Bullet" ("Sem Bala de Prata").
00:03:32Nele, ele argumentou que não haveria uma única inovação que nos daria
00:03:36uma ordem de magnitude de melhoria na produtividade de software.
00:03:38Por quê?
00:03:40Porque ele dizia que a parte difícil não era a mecânica da codificação,
00:03:44a sintaxe, a digitação ou o código repetitivo.
00:03:45Era sobre entender o problema real e projetar a solução.
00:03:49Nenhuma ferramenta pode eliminar essa dificuldade fundamental.
00:03:52Toda ferramenta e técnica criada até aqui facilita a mecânica.
00:03:55Mas o desafio central —
00:03:57entender o que construir e como deve funcionar — continua tão difícil quanto antes.
00:04:00Se o problema não está na mecânica, por que continuamos otimizando para ela?
00:04:06Como engenheiros experientes acabam com códigos que não entendem agora?
00:04:09A resposta, creio eu, reside em duas palavras que costumamos confundir: simples e fácil.
00:04:14Tendemos a usá-las como sinônimos, mas
00:04:16elas significam coisas completamente diferentes.
00:04:18Fui "descoberto" no jantar dos palestrantes como um entusiasta de Clojure,
00:04:21então isso fica bem claro aqui.
00:04:23Rich Hickey, o criador da linguagem de programação Clojure,
00:04:25explicou isso em sua palestra de 2011 chamada "Simple Made Easy".
00:04:29Ele definiu "simples" como tendo uma única dobra, um único fio, sem emaranhamento.
00:04:33Cada peça faz uma coisa e não se entrelaça com as outras.
00:04:36Ele define "fácil" como o que é adjacente, o que está ao alcance.
00:04:39O que você consegue acessar sem esforço?
00:04:41Copiar, colar, enviar.
00:04:43Simples é sobre estrutura.
00:04:45Fácil é sobre proximidade.
00:04:48O fato é que não podemos tornar algo simples apenas desejando.
00:04:51A simplicidade exige pensamento, design e desentrelaçamento.
00:04:54Mas sempre podemos tornar algo mais fácil.
00:04:56Basta colocar mais perto.
00:04:57Instalar um pacote, gerar com IA, copiar uma solução do Stack Overflow.
00:05:03É da natureza humana seguir o caminho mais fácil.
00:05:06Fomos programados para isso.
00:05:07Como eu disse, copiar algo do Stack Overflow está logo ali.
00:05:10Um framework que resolve tudo com "mágica": é só instalar e usar.
00:05:14Mas fácil não significa simples.
00:05:15Fácil significa que você pode adicionar algo ao seu sistema rapidamente.
00:05:18Simples significa que você consegue entender o trabalho que realizou.
00:05:20Toda vez que escolhemos o fácil, escolhemos velocidade agora e complexidade depois.
00:05:24E, honestamente, essa troca costumava funcionar.
00:05:27A complexidade se acumulava na base de código devagar o suficiente para que
00:05:31pudéssemos refatorar, repensar e reconstruir quando necessário.
00:05:34Eu acho que a IA destruiu esse equilíbrio.
00:05:36Porque ela é o botão de facilidade definitivo.
00:05:37Ela torna o caminho fácil tão
00:05:38sem atrito que nem sequer consideramos mais o caminho simples.
00:05:41Por que pensar em arquitetura quando o código aparece instantaneamente?
00:05:44Vou mostrar a vocês como isso acontece.
00:05:47Como uma tarefa simples evolui para uma bagunça complexa
00:05:50através de uma interface de chat que todos passamos a amar.
00:05:52Este é um exemplo hipotético, mas digamos que temos nosso app
00:05:55e queremos adicionar autenticação a ele.
00:05:57Pedimos para adicionar "auth", e recebemos um arquivo auth.js limpinho.
00:06:01Iteramos algumas vezes e chegamos à quinta mensagem.
00:06:02Você pensa: "Beleza, agora vamos adicionar OAuth também",
00:06:04e agora temos um auth.js e um OAuth.js.
00:06:07Continuamos iterando e descobrimos que as sessões pararam de funcionar.
00:06:11E surgiram vários conflitos.
00:06:12Lá pela vigésima interação, você não está mais em uma conversa.
00:06:15Você está gerenciando contextos que ficaram tão complexos que nem você
00:06:18se lembra de todas as restrições que adicionou.
00:06:20Código morto de abordagens abandonadas.
00:06:22Testes que foram corrigidos apenas para "fazer funcionar".
00:06:25Fragmentos de três soluções diferentes porque você acabou dizendo: "Espera, na verdade..."
00:06:28Cada nova instrução está sobrescrevendo padrões arquiteturais.
00:06:31Dissemos para fazer a autenticação funcionar, e ela funcionou.
00:06:33Quando dissemos para corrigir este erro, ela corrigiu.
00:06:35Não há resistência a decisões arquiteturais ruins.
00:06:38O código apenas se transforma para satisfazer seu último pedido.
00:06:40Cada interação é uma escolha pelo fácil em vez do simples.
00:06:43E o fácil sempre significa mais complexidade.
00:06:46Nós sabemos disso, mas quando o caminho fácil é tão acessível, nós o seguimos.
00:06:50E a complexidade vai se acumulando até que seja tarde demais.
00:06:52A IA realmente leva o conceito de "fácil" ao seu extremo lógico.
00:06:58Você decide o que quer e recebe o código instantaneamente.
00:07:00Mas há um perigo nisso.
00:07:02O código gerado trata todos os padrões da sua base de código da mesma forma.
00:07:06Quando um agente analisa seu código, cada linha vira um padrão a ser preservado.
00:07:10A verificação de autenticação na linha 47? É um padrão.
00:07:13Aquele código gRPC estranho que finge ser GraphQL que eu adicionei em 2019?
00:07:18Também é um padrão.
00:07:19A dívida técnica não é reconhecida como dívida; é apenas mais código.
00:07:22O problema real aqui é a complexidade.
00:07:25Eu sei que usei muito essa palavra nesta palestra sem realmente defini-la.
00:07:29Mas a melhor forma de pensar nela é como o oposto da simplicidade.
00:07:31Significa apenas algo entrelaçado.
00:07:33E quando as coisas são complexas, tudo toca em tudo.
00:07:36Você não consegue mudar uma coisa sem afetar outras dez.
00:07:41Voltando ao artigo de Fred Brooks, "No Silver Bullet".
00:07:43Nele, ele identificou que há dois tipos principais de complexidade em cada sistema.
00:07:47Existe a complexidade essencial, que é a dificuldade fundamental
00:07:51do problema real que você está tentando resolver.
00:07:53Usuários precisam pagar por coisas, pedidos precisam ser atendidos.
00:07:56Esta é a complexidade do porquê o seu sistema de software existe para começo de conversa.
00:08:00E, em segundo lugar, há a ideia de complexidade acidental.
00:08:03Tudo o mais que adicionamos pelo caminho: gambiarras, código defensivo,
00:08:06frameworks, abstrações que faziam sentido há algum tempo.
00:08:09É tudo o que juntamos para fazer o código em si funcionar.
00:08:11Em uma base de código real, esses dois tipos de complexidade estão em toda parte.
00:08:16E ficam tão emaranhados que separá-los exige contexto,
00:08:19histórico e experiência.
00:08:20O que a IA gera não faz essa distinção.
00:08:24E assim, cada padrão continua sendo preservado.
00:08:26Vejam um exemplo real de um trabalho que estamos fazendo na Netflix.
00:08:32Eu tenho um sistema com uma camada de abstração entre nosso código antigo
00:08:35de autorização, escrito há uns cinco anos, e um novo sistema centralizado.
00:08:41Não tivemos tempo de reconstruir o app inteiro, então
00:08:42apenas colocamos um adaptador, um "shim", no meio.
00:08:44Com a IA, pensamos ser uma ótima oportunidade para refatorar e usar
00:08:47o novo sistema diretamente. Parece um pedido simples, certo?
00:08:50Pois não. O código antigo estava tão acoplado aos seus padrões
00:08:56de autorização — tínhamos permissões misturadas à lógica de negócio,
00:08:59funções embutidas nos modelos de dados e chamadas de auth em centenas de arquivos.
00:09:03O agente começava a refatorar, avançava em alguns arquivos, encontrava uma
00:09:07dependência impossível de desatar, perdia o controle e desistia.
00:09:10Ou pior: tentava preservar a lógica do sistema antigo
00:09:16recriando-a no sistema novo, o que também não é bom.
00:09:19O fato é que ela não conseguia ver as divisões.
00:09:23Não conseguia identificar onde terminava a lógica de negócio e começava a de auth.
00:09:26Estava tudo tão emaranhado que, mesmo com informação perfeita,
00:09:30a IA não conseguia encontrar um caminho limpo.
00:09:33Quando sua complexidade acidental chega a esse nível de emaranhamento,
00:09:35a IA não é a melhor ajuda para melhorar as coisas.
00:09:38Descobri que ela apenas adiciona mais camadas por cima.
00:09:40Nós conseguimos notar a diferença, ou pelo menos conseguimos quando paramos para pensar.
00:09:45Sabemos quais padrões são essenciais e
00:09:47quais são apenas o jeito que alguém resolveu há alguns anos.
00:09:50Nós temos o contexto que a IA não consegue inferir, mas
00:09:53só se tirarmos um tempo para fazer essas distinções antes de começar.
00:09:56Então, como se faz isso na prática?
00:10:01Como separar a complexidade acidental da essencial quando
00:10:04você está diante de uma base de código imensa?
00:10:07A base de código em que trabalho na Netflix tem cerca de um milhão de linhas de Java,
00:10:10e o serviço principal tem cerca de cinco milhões de tokens, pela última contagem.
00:10:13Nenhuma janela de contexto que eu conheça consegue suportar isso.
00:10:17Quando quis trabalhar com isso, primeiro pensei: "Ei,
00:10:19talvez eu possa copiar grandes partes desse código para o contexto
00:10:23e ver se os padrões aparecem",
00:10:24para ver se ela conseguiria entender o que estava acontecendo.
00:10:26E, tal como na refatoração de autorização anterior,
00:10:29o resultado acabou se perdendo em sua própria complexidade.
00:10:31Com isso, fui forçado a tentar algo diferente.
00:10:34Tive que selecionar o que incluir: documentos de design, arquitetura, diagramas,
00:10:37interfaces principais, o que você imaginar.
00:10:39E dediquei tempo descrevendo os requisitos de como os componentes deveriam interagir
00:10:42e quais padrões seguir.
00:10:43Vejam, eu estava escrevendo uma especificação.
00:10:45Cinco milhões de tokens se tornaram 2.000 palavras de especificação.
00:10:49E para ir além, peguei essa especificação e
00:10:52criei um conjunto exato de etapas de código para execução.
00:10:55Sem instruções vagas, apenas uma sequência precisa de operações.
00:10:58Descobri que isso produzia um código muito mais limpo, focado e compreensível.
00:11:02Então, eu o defini primeiro e planejei sua própria execução.
00:11:05Isso se tornou a abordagem que chamei de compressão de contexto há algum tempo.
00:11:11Mas vocês podem chamar de engenharia de contexto, espectro de desenvolvimento,
00:11:13o que quiserem.
00:11:15O nome não importa.
00:11:16O que importa aqui é que o pensamento e o planejamento se tornam a maior parte do trabalho.
00:11:20Vou mostrar como isso funciona na prática.
00:11:22Temos o passo um, fase um: pesquisa.
00:11:26Eu começo alimentando tudo para a IA logo de cara.
00:11:28Diagramas de arquitetura, documentação, tópicos do Slack.
00:11:31Já falamos sobre isso várias vezes.
00:11:32Mas, sério, tragam o máximo de contexto relevante que puderem
00:11:35para as mudanças que vocês farão.
00:11:36Depois, usem o agente para analisar a base de código e
00:11:39mapear os componentes e dependências.
00:11:42Isso não deve ser um processo de tentativa única.
00:11:43Gosto de sondar, perguntando: "E quanto ao cache?"
00:11:46"Como isso lida com falhas?"
00:11:47E quando a análise dela estiver errada, eu a corrijo.
00:11:49Se faltar contexto, eu o forneço.
00:11:51Cada iteração refina a análise.
00:11:55O resultado aqui é um único documento de pesquisa.
00:11:57Aqui está o que existe, o que se conecta ao quê,
00:11:59e aqui está o que sua mudança afetará.
00:12:01Horas de exploração são comprimidas em minutos de leitura.
00:12:03Sei que o Dex mencionou isso hoje cedo, mas a verificação humana aqui é crítica.
00:12:09É aqui que você valida a análise contra a realidade,
00:12:12o momento de maior impacto em todo o processo.
00:12:15Detecte erros aqui e evite desastres depois.
00:12:17Seguindo para a fase dois.
00:12:20Agora que você tem uma pesquisa válida em mãos,
00:12:22criamos um plano de implementação detalhado: estrutura real de código,
00:12:25assinaturas de função, definições de tipo, fluxo de dados.
00:12:28Você quer que isso seja algo que qualquer desenvolvedor possa seguir.
00:12:30Eu comparo isso a um livro de colorir numerado.
00:12:32Você deveria poder entregar isso ao seu engenheiro mais júnior e dizer: "Faça isso".
00:12:35E se ele copiar linha por linha, deve simplesmente funcionar.
00:12:38Este passo é onde tomamos muitas das decisões arquiteturais importantes.
00:12:43Garantir que a lógica complexa esteja correta.
00:12:45Garantir que os requisitos de negócio sigam as boas práticas.
00:12:50Garantir bons limites de serviço, separação limpa e
00:12:52prevenir qualquer acoplamento desnecessário.
00:12:54Nós identificamos os problemas antes que aconteçam porque já os vivemos.
00:12:57A IA não tem essa opção.
00:12:59Ela trata cada padrão como um requisito.
00:13:01A verdadeira mágica neste passo é a velocidade de revisão.
00:13:05Podemos validar este plano em minutos e saber exatamente o que será construído.
00:13:10E para acompanhar a velocidade com que queremos gerar código,
00:13:13precisamos ser capazes de compreender o que estamos fazendo com a mesma rapidez.
00:13:18Por último, temos a implementação. Agora que temos um plano claro e
00:13:22embasado em pesquisa sólida, esta fase deve ser bem simples.
00:13:26E esse é o objetivo.
00:13:28Quando a IA tem uma especificação clara a seguir, o contexto permanece limpo e
00:13:31focado.
00:13:32Evitamos a espiral de complexidade das conversas longas.
00:13:36E em vez de 50 mensagens de código evolutivo,
00:13:38temos três resultados focados, cada um validado antes de prosseguir.
00:13:41Sem abordagens abandonadas, sem padrões conflitantes,
00:13:44sem aqueles momentos de "espera, na verdade..." que deixam código morto em todo lugar.
00:13:48Para mim, o real benefício disso é que você pode usar um agente em segundo plano
00:13:52para fazer muito desse trabalho, pois você já fez todo o raciocínio difícil antes.
00:13:56Ele pode apenas iniciar a implementação enquanto você trabalha em outra coisa
00:13:59e volta apenas para revisar.
00:14:01E você pode revisar rapidamente porque está apenas verificando se está de acordo
00:14:04com o seu plano, não tentando entender se algo foi inventado do nada.
00:14:07A questão aqui é que não estamos usando a IA para pensar por nós.
00:14:12Estamos usando-a para acelerar as partes mecânicas,
00:14:15mantendo nossa capacidade de entender o processo.
00:14:17A pesquisa é mais rápida, o planejamento é mais minucioso e a implementação é mais limpa.
00:14:21O pensamento, a síntese e o julgamento, porém, permanecem conosco.
00:14:26Lembram daquela refatoração de autorização que eu disse que a IA não conseguiu lidar?
00:14:34O fato é que estamos trabalhando nela agora e
00:14:37começando a fazer um bom progresso.
00:14:39Mas não é porque encontramos prompts melhores.
00:14:42Vimos que não podíamos nem pular para a pesquisa, planejamento e
00:14:45implementação.
00:14:46Tivemos que fazer essa mudança nós mesmos, manualmente.
00:14:49Sem IA, apenas lendo o código, entendendo as dependências e
00:14:52fazendo alterações para ver o que quebrava.
00:14:53Essa migração manual foi, sinceramente, um sofrimento, mas foi crucial.
00:14:59Ela revelou todas as restrições ocultas, quais invariantes deveriam ser mantidas e
00:15:02quais serviços quebrariam se a autenticação mudasse.
00:15:05Coisas que nenhuma análise de código teria revelado para nós.
00:15:09Então, alimentamos o pull request dessa migração manual em nosso processo de pesquisa
00:15:14e o usamos como semente para qualquer pesquisa futura.
00:15:19A IA pôde então ver como é uma migração limpa.
00:15:23A questão é que cada uma dessas entidades é um pouco diferente, então temos que
00:15:27interrogá-la e dizer: "Ei, o que fazemos sobre isso?"
00:15:29Algumas coisas são criptografadas, outras não.
00:15:32Tivemos que fornecer esse contexto extra a cada iteração.
00:15:35Então, e só então, conseguimos gerar um plano que poderia funcionar de primeira.
00:15:41E a palavra-chave aqui é "poderia", pois ainda estamos validando,
00:15:45ajustando e descobrindo casos isolados.
00:15:47A abordagem de três fases não é mágica.
00:15:55Ela só funciona porque fizemos aquela migração manualmente.
00:15:57Tivemos que conquistar o entendimento antes de codificá-lo em nosso processo.
00:16:01Ainda acho que não existe uma solução definitiva.
00:16:02Não acho que existam prompts melhores, modelos melhores ou até especificações melhores.
00:16:06Apenas o trabalho de entender seu sistema profundamente o suficiente para
00:16:09fazer mudanças nele com segurança.
00:16:11Então, por que passar por tudo isso?
00:16:15Por que não apenas iterar com a IA até funcionar?
00:16:18Eventualmente, os modelos ficam fortes o suficiente e simplesmente funciona.
00:16:21Para mim, o "funciona" não é o suficiente.
00:16:24Há uma diferença entre código que passa nos testes e código que sobrevive
00:16:27em produção.
00:16:28Entre sistemas que funcionam hoje e
00:16:31sistemas que podem ser alterados por outra pessoa no futuro.
00:16:34O problema real aqui é uma lacuna de conhecimento.
00:16:38Quando a IA pode gerar milhares de linhas de código em segundos,
00:16:41entendê-lo pode levar horas, talvez dias se for complexo.
00:16:45Quem sabe, talvez nunca, se estiver realmente emaranhado.
00:16:48Aqui está algo sobre o qual não acho que muitas pessoas estejam falando agora.
00:16:52Cada vez que deixamos de pensar para acompanhar a velocidade de geração,
00:16:56não estamos apenas adicionando código que não entendemos.
00:16:58Estamos perdendo nossa capacidade de reconhecer problemas.
00:17:00Aquele instinto que diz: "Ei, isso está ficando complexo",
00:17:03ele atrofia quando você não entende o seu próprio sistema.
00:17:09O reconhecimento de padrões vem da experiência.
00:17:11Quando percebo uma arquitetura perigosa,
00:17:12é porque eu fui quem ficou acordado às três da manhã lidando com ela.
00:17:16Quando defendo soluções mais simples,
00:17:17é porque tive que manter a alternativa deixada por outra pessoa.
00:17:21A IA gera o que você pede a ela.
00:17:23Ela não codifica lições de falhas passadas.
00:17:25A abordagem de três fases preenche essa lacuna.
00:17:29Ela comprime o entendimento em artefatos que podemos revisar na velocidade da geração.
00:17:33Sem isso, estamos apenas acumulando complexidade mais rápido do que podemos
00:17:37compreendê-la.
00:17:39A IA muda tudo sobre como escrevemos código, mas, honestamente,
00:17:44não acho que mude nada sobre por que o software em si falha.
00:17:47Cada geração enfrentou sua própria crise de software.
00:17:50A geração de Dijkstra a enfrentou criando a disciplina de engenharia de software e,
00:17:54agora, enfrentamos a nossa com a geração infinita de código.
00:17:56Não acho que a solução seja outra ferramenta ou metodologia.
00:18:01É lembrar o que sempre soubemos: que o software é um esforço humano.
00:18:05A parte difícil nunca foi digitar o código.
00:18:06Era saber o que digitar em primeiro lugar.
00:18:09Os desenvolvedores que prosperarão não serão apenas os que gerarem mais código.
00:18:13Serão os que entendem o que estão construindo,
00:18:15que ainda conseguem ver as junções, que conseguem reconhecer quando estão
00:18:18resolvendo o problema errado.
00:18:19Isso ainda depende de nós.
00:18:20Isso só dependerá de nós.
00:18:21Quero terminar com uma pergunta, e não acho que a questão seja se
00:18:25vamos usar a IA ou não.
00:18:26Isso é uma conclusão óbvia.
00:18:28Esse navio já zarpou.
00:18:30Para mim, a questão será se ainda entenderemos nossos próprios sistemas
00:18:33quando a IA estiver escrevendo a maior parte do nosso código.
00:18:35Obrigado.
00:18:37>> [APLAUSOS]
00:18:39[MÚSICA]

Key Takeaway

O verdadeiro desafio da engenharia de software na era da IA não é a mecânica da escrita do código, mas sim a manutenção da capacidade humana de compreender, projetar e simplificar sistemas complexos.

Highlights

A distinção fundamental entre o que é "fácil" (proximidade e conveniência) e o que é "simples" (design sem emaranhamento).

O risco de a IA atuar como o "botão de facilidade definitivo", acelerando a geração de código mas ignorando a arquitetura e a simplicidade.

A complexidade acidental versus a complexidade essencial, e como a IA tende a preservar erros do passado como se fossem padrões necessários.

A necessidade de realizar migrações manuais em sistemas críticos para conquistar o entendimento profundo antes de delegar a tarefa à automação.

A proposta da metodologia de três fases: Pesquisa, Planejamento (especificação) e Implementação assistida.

O alerta sobre a atrofia do instinto técnico do engenheiro quando ele deixa de entender o sistema que opera.

Timeline

Confissões e o Contexto da Aceleração na Netflix

O palestrante inicia com a confissão de que já enviou códigos para produção sem entendê-los completamente, sugerindo que essa é uma realidade comum entre desenvolvedores. Ele relata sua experiência na Netflix, onde ferramentas de IA reduziram tarefas de dias para horas, mas alerta para os perigos dessa velocidade em sistemas críticos que falham de forma inesperada. O problema central identificado é que o volume de geração de código está ultrapassando a nossa capacidade humana de compreensão. Ele estabelece que, embora a crise de software não seja nova, a escala atual de geração é sem precedentes. Este trecho serve para situar o espectador sobre o desequilíbrio entre produtividade mecânica e entendimento intelectual.

A Perspectiva Histórica e a 'Bala de Prata'

A palestra revisita as décadas de 60 e 70, citando Dijkstra para explicar que o aumento da potência do hardware sempre gera um desejo proporcional por softwares mais complexos. O palestrante percorre a evolução das linguagens e metodologias, do C ao Agile e à nuvem, culminando na atual era da IA generativa. Ele utiliza o famoso artigo "No Silver Bullet" de Fred Brooks para argumentar que nenhuma ferramenta elimina a dificuldade fundamental de projetar soluções. Brooks defendia que a parte difícil do software é a essência do problema, não a sintaxe ou a digitação. Portanto, otimizar apenas a mecânica com IA não resolve o núcleo do desafio da engenharia.

Simples vs. Fácil: A Armadilha da Conveniência

Baseando-se no trabalho de Rich Hickey, o palestrante define "simples" como algo desentrelaçado e "fácil" como aquilo que está ao alcance ou é familiar. Ele argumenta que a IA é a ferramenta de facilidade máxima, pois remove o atrito, o que frequentemente nos leva a ignorar o caminho da simplicidade arquitetural. Um exemplo hipotético de implementação de autenticação via chat ilustra como interações rápidas criam uma bagunça de código morto e padrões conflitantes. O código gerado pela IA não diferencia uma boa prática de uma dívida técnica antiga, tratando tudo como um padrão a ser replicado. Essa seção enfatiza que escolher o fácil agora geralmente resulta em uma complexidade insustentável no futuro próximo.

Complexidade Essencial vs. Acidental

O palestrante aprofunda a discussão sobre os dois tipos de complexidade identificados por Fred Brooks: a essencial (o problema de negócio) e a acidental (escolhas técnicas e gambiarras). Ele compartilha um caso real da Netflix envolvendo uma refatoração de autorização onde a IA falhou miseravelmente por não conseguir desatar o emaranhado de lógicas misturadas. Como a IA não possui contexto histórico ou experiência, ela tenta recriar sistemas antigos falhos dentro de novas arquiteturas. A conclusão é que separar esses tipos de complexidade exige um julgamento humano que a máquina ainda não consegue inferir sozinha. Sem essa distinção, a automação apenas adiciona camadas de confusão sobre sistemas já frágeis.

A Metodologia de Três Fases: Pesquisa, Plano e Execução

Para lidar com bases de código imensas, o palestrante propõe uma estratégia de "compressão de contexto" dividida em três etapas rigorosas. A primeira fase é a Pesquisa, onde a IA mapeia dependências e o humano valida a análise; a segunda é o Planejamento, criando uma especificação detalhada que funciona como um "livro de colorir numerado". Somente após essas definições arquiteturais é que ocorre a Implementação, garantindo que a IA siga um caminho limpo e focado. Esta abordagem foca em manter o pensamento e o design com o desenvolvedor, enquanto delega apenas a parte repetitiva para o agente. O objetivo é evitar a espiral de complexidade que surge em conversas de chat longas e sem direção clara.

Conclusão: O Valor do Entendimento Humano

O palestrante revela que a refatoração bem-sucedida na Netflix só avançou quando a equipe realizou uma migração manual dolorosa para conquistar o entendimento necessário. Ele reforça que não existem prompts mágicos que substituam o trabalho de conhecer profundamente o próprio sistema. O grande risco da automação total é a atrofia do instinto técnico e da capacidade de reconhecer padrões perigosos que só a experiência de resolver falhas ensina. Ele finaliza afirmando que, embora a IA vá escrever a maior parte do código, a responsabilidade de saber o que construir e como simplificar permanece exclusivamente humana. A palestra encerra com uma reflexão provocativa sobre se seremos capazes de manter o controle de nossos sistemas no futuro.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video