A qualidade do código ainda importa? Depende disto — Max Kanat-Alexander, Capital One

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Does Code Quality Still Matter? It Depends on This — Max Kanat-Alexander, Capital One · Canal: AI Engineer · 16:05 · Assistir no YouTube

Tópicos: Engenharia de software com IA

Resumo

Max Kanat-Alexander propõe avaliar a qualidade do código pelo quanto ela ajuda a entender o comportamento de um sistema e a modificá-lo com segurança. Sistemas duráveis, com muitas dependências, alto custo de falha e manutenção contínua, exigem rigor de engenharia; para software descartável, esse rigor pode não compensar. A IA torna mais comum criar software descartável, mas não elimina a importância dos sistemas duráveis. O palestrante também apresenta práticas para reduzir o custo do rigor, como padronização, ferramentas automáticas e testes fáceis de executar.

Pontos-chave

O sucesso do software depende de entender o sistema e conseguir executar mudanças com base nesse entendimento.
A estrutura compreensível do código facilita entender o comportamento dos componentes e modificá-los.
Mudanças podem causar problemas imediatos e tornar alterações futuras mais arriscadas.
Software descartável pode exigir pouco rigor quando é barato de substituir, tem poucas dependências e apresenta baixo custo de falha e manutenção.
Software durável continuará sendo importante e exige maior rigor de engenharia.
A escolha do nível de rigor deve considerar consequências de falha, custo de substituição, dependências e custo de manutenção.
Ambientes isolados, independência entre sistemas, redundância e escopo limitado podem tornar o software mais descartável.
Padronização, ferramentas automáticas confiáveis, testes fáceis e regras estritas podem reduzir o custo do rigor.

Capítulos

Início	Capítulo	Resumo
00:01	Por que a qualidade do código importa	O palestrante propõe um modelo baseado em entender o comportamento do sistema e conseguir modificá-lo corretamente.
02:05	Compreender a estrutura do sistema	A estrutura do código ajuda a entender componentes de sistemas complexos e a fazer alterações com segurança.
04:42	Riscos das mudanças e complexidade acumulada	Mudanças podem causar problemas e dificultar futuras alterações, ampliando os riscos conforme o sistema se torna mais difícil de entender.
06:44	Software descartável e software durável	O nível de rigor necessário varia conforme as consequências de falha, o custo de substituição, as dependências e o custo de manutenção.
09:54	Como tornar o software mais descartável	Ambientes isolados, independência, redundância e escopo limitado podem permitir que certos sistemas sejam substituídos com facilidade.
12:59	Reduzir o custo do rigor de engenharia	Padronização, ferramentas automáticas, infraestrutura de testes acessível e regras estritas tornam o rigor menos custoso.
15:34	A resposta: depende da durabilidade	A qualidade do código importa para software durável, mas pode não importar para software descartável, e o rigor não precisa ser caro.

Citações

O sucesso de todo software é determinado por esses dois fatores. — 01:04

Nesse mundo, a qualidade do código não importa. — 07:15

Software descartável e durável não são categorias preto no branco. Existe um espectro. — 11:28

Para software descartável, não. Para software durável, sim. — 15:34

Isso precisa ser caro? Não. — 16:05

Conceitos e entidades

code quality (conceito): Qualidade do código entendida como algo que favorece a compreensão do sistema e a realização segura de mudanças.
disposable software (conceito): Software de baixo custo de substituição e manutenção, com poucas dependências e consequências limitadas em caso de falha.
durable software (conceito): Software de longa duração, amplamente utilizado ou integrado a outros sistemas, cuja manutenção e falhas podem ter consequências significativas.
engineering rigor (conceito): Conjunto de práticas de engenharia aplicado na medida adequada aos riscos e à durabilidade do software.
inward flow tooling (conceito): Ferramentas que são executadas automaticamente, sem exigir que o programador escolha iniciá-las ou entenda seu funcionamento.
Chromium (repo): Projeto open source que está por trás do Chrome e cujo mapa de código é usado como exemplo da complexidade de um sistema real.
Max Kanat-Alexander (pessoa): Palestrante que apresenta um modelo para decidir quando a qualidade do código e o rigor de engenharia importam.
Capital One (empresa): Empresa mencionada junto ao nome do palestrante no título do vídeo.

Tradução completa (pt-BR)

00:01 [música] >> Então, hoje pensei em escolher um tema agradável e nada controverso, sobre o qual ninguém tem opinião. Certo? Ninguém, ninguém falou nada sobre isso nas redes sociais, sabe? E, claro, toda opinião sobre isso nas redes sociais é muito, muito ponderada, sabe? As pessoas têm muita profundidade e, sabe, ideias realmente grandiosas. Sabe,

00:33 talvez haja um pouco mais nisso do que apenas sim ou não. E, claro, se você fizer uma pergunta a um engenheiro sênior, sempre teremos a mesma resposta para todas as perguntas, a resposta favorita de todo engenheiro sênior: depende. Mas, francamente, essa não é uma resposta muito útil, porque de que depende? Então, vamos começar por isto: por que a qualidade do código importava, afinal? Vejo muita gente dizendo: “Bem, isso me fazia sentir bem.” Isso não é uma justificativa

01:04 suficiente. Então, vamos ver se conseguimos acrescentar um pouco de nuance a esta conversa e ajudar todo mundo, pelo menos, a ter uma base para raciocinar sobre o assunto enquanto o discutimos. Vamos ver se conseguimos criar um framework; é isso que vamos tentar fazer nesta palestra. Certo. Vamos começar com o fato de que tudo o que você quer realizar com um software depende de dois fatores, e somente dois fatores: entender e executar com base nesse entendimento, seja alinhar um modelo, escalar um sistema, impulsionar a adoção ou qualquer outra coisa. Todo sucesso de software é determinado por esses

01:35 dois fatores. É por isso que temos coisas como debuggers, observabilidade, evals e até testes. Todas essas coisas existem, na verdade, para melhorar seu entendimento ou sua capacidade de executar com base nesse entendimento. As pessoas acham que elas existem por outros motivos, mas, no fundo, esse é o motivo. Tudo o que já fizemos na área de qualidade de código serve exclusivamente para essas duas coisas. Não serve para mais nada. Não tem a ver com correção ou outra coisa. Tem a ver somente com essas duas coisas. Agora, há dois entendimentos que são os mais importantes para

02:05 quem vai ser engenheiro de software. Há outros entendimentos sobre software importantes para quem trabalha com produto ou vendas, mas, se você é engenheiro de software, estes dois são os mais importantes. O primeiro é: qual é o comportamento do sistema? Quer dizer, concretamente — não o que a documentação diz que é o comportamento do sistema, mas qual é o comportamento real do sistema. E o segundo é: como faço para modificar esse comportamento de forma correta e segura? Certo? Em um sistema muito pequeno, se você quiser entender o que o sistema faz, eu simplesmente digo o que ele faz. Ele imprime

02:37 “Hello World”. Você diz: “Quero que ele diga ‘Hi World’.” Eu digo: “Certo, vou fazer com que diga ‘Hi World’ agora.” Há muito pouco a entender além do que ele faz, pura e simplesmente. Esse é todo o entendimento de que você precisa. No entanto, qualquer sistema de software real é enormemente complexo. Este é um mapa real da base de código do Chromium, que é o projeto open source por trás do Chrome. E, se você pensar em todas as diferentes maneiras como esses componentes podem interagir, eles têm, essencialmente, infinitos comportamentos possíveis.

03:09 Não consigo descrever em palavras o comportamento do Chromium como um sistema inteiro. No entanto, o que consigo descrever — e todos nós sabemos disso, todos já somos engenheiros de software há algum tempo — são componentes do sistema. Consigo descrever com sucesso como um componente do sistema se comporta. Este é o parser de URL: as funções e outras coisas do parser de URL do Chromium. Ele identifica todas as diferentes partes da URL. E isso

03:40 é o motivo de todo o código existir. O motivo de termos código, antes de mais nada, é a estrutura. Porque… O que quero dizer com isso? Certo. Ambos, o da esquerda e o da direita, vão imprimir “Hello World” se forem executados em uma máquina Linux. No entanto, à esquerda, dá para ver que é “Hello World”. Ele tem a identidade e a estrutura de “Hello World”. À direita, você vê apenas uma série de

04:11 instruções sem uma identidade específica, reconhecível ou compreensível. Não é um componente, é apenas um monte de instruções. Embora isso seja compreensível aqui, se fossem milhões ou bilhões de linhas disso, seria muito mais difícil de entender. No passado, falávamos de coisas como legibilidade, testabilidade ou outros conceitos que pareciam relacionados a pessoas e ao código, mas o que sempre importou mais, na verdade, era que o sistema tivesse algum tipo de estrutura compreensível. Portanto, o que realmente importa é a estrutura.

04:42 E isso importa mais quando você quer modificar o sistema, o segundo entendimento de que falamos. Toda modificação em um sistema envolve duas categorias de risco. A primeira é você introduzir algum tipo de problema. E problema não significa apenas bug; é qualquer coisa ruim que possa acontecer. Por exemplo, seu projeto pode levar muito mais tempo do que você espera. Ele pode não se comportar da maneira que você queria para os usuários. O projeto pode fracassar porque os custos excederam o orçamento. Qualquer tipo de problema pode acontecer simplesmente por você

05:12 tentar passar pelo processo de fazer essa mudança. E a segunda é que você pode dificultar a realização de mudanças futuras. Em particular, isso significa que você pode tornar mais prováveis os problemas futuros. Você pode aumentar o risco futuro do sistema. Essas duas coisas são causadas por problemas de entendimento. A primeira tem a ver com a dificuldade de entender o sistema desde o início; a segunda acontece quando você torna o sistema mais difícil de entender. Posso reduzir toda análise pós-incidente que já li

05:43 sobre qualquer incidente a esses dois fatores, de uma forma ou de outra. A configuração de produção era difícil demais de entender, alguém fez algo impossível de entender, havia propriedades emergentes do sistema que eram impossíveis de entender, e assim por diante. O ponto dois alimenta o ponto um em um ciclo vicioso que se acumula de forma não linear. Portanto, a dificuldade de entendimento não cresce linearmente; ela se acumula com o tempo. Você acabará chegando a um ponto — e

06:13 todos os sistemas tendem a chegar a esse ponto, mais cedo ou mais tarde — em que toda modificação envolve algum tipo de problema. E, sabe, alguns sistemas chegam ao ponto em que não dá para modificá-los, como algumas dessas bases de código gigantescas de mainframe, com 100 milhões, 500 milhões de linhas, em que toda mudança é algum tipo de problema. Você vai ver isso em problemas organizacionais, vai ver isso em toda parte, vai ver isso nos cronogramas, enfim. E olha, há muitos argumentos de que talvez os modelos futuros resolvam isso. Olha, talvez

06:44 resolvam. Talvez os modelos futuros consigam lidar com a complexidade de forma ilimitada, de algum jeito. Mas não precisamos discutir isso hoje, porque acho que os modelos estão fazendo algo diferente e muito interessante agora. Eles estão criando um novo tipo de software, uma nova categoria de software. Essa categoria sempre existiu, mas está prestes a se tornar cem mil vezes mais comum do que qualquer outra forma de software. E essa categoria é o software descartável.

07:15 Então, o que é isso? Certo. Imagine um mundo em que as consequências de uma falha do seu sistema sejam muito pequenas ou inexistentes. Imagine que poucas pessoas dependam dele e que quase nenhum outro sistema dependa desse software. O gerenciamento de mudanças é mínimo ou inexistente. Imagine que o custo de substituição caia para quase zero. Você poderia substituir tudo em horas ou dias. E o custo de manutenção fosse basicamente nulo. Nesse mundo, a qualidade do código não

07:49 importa. Porque todas aquelas coisas que tentávamos evitar — os riscos que se acumulam com o tempo — não existem. Tradicionalmente, sempre criamos software durável. Sabe, ele dura anos. Milhões ou milhares de pessoas dependem dele. As consequências de uma falha são enormes, podendo até ser catastróficas para os negócios. E ele exige uma manutenção enorme. A maioria dos engenheiros de software do mundo passa a maior parte do tempo mantendo esses grandes sistemas duráveis.

08:21 Espero que isso continue existindo. Então, esta é uma das áreas em que acho que, às vezes, a conversa acaba se desviando um pouco, certo? Sistemas duráveis provavelmente continuarão sendo os sistemas mais importantes do mundo. E provavelmente haverá mais deles. Mas os sistemas mais numerosos serão os softwares descartáveis. Eles poderão ser substituídos em questão de horas. Poucas pessoas dependerão deles, ou o gerenciamento de mudanças simplesmente não será importante. E veja, se não funcionar, você vai

08:52 dar agents a todo mundo. Eles mesmos farão uma versão. Sabe, a manutenção será irrelevante ou quase gratuita. Não gosta da calculadora do seu sistema operacional? Faça a sua. Quer planejar uma festa para seus filhos? Escreva um software para planejar festas só para aquela festa. Jogue-o fora. A qualidade do código não importa. Ninguém se importa. No futuro, aplicaremos rigor de engenharia na medida da descartabilidade do software. À esquerda, nada. Nenhuma das nossas práticas de rigor de engenharia importa nem um pouco. À direita, todas as práticas de engenharia que desenvolvemos ao longo de muitas décadas importam muito. Podemos determinar onde você está nessa escala com base naqueles quatro fatores de que falei: consequências, custo de substituição, dependências e custo de manutenção. Se todos forem baixos, é software descartável. Se todos forem altos, é software durável. E veja, qualquer pessoa que escreve software há muito tempo sabe que é melhor pecar pelo excesso de durabilidade. É melhor supor que esses fatores serão mais altos do que você espera.

09:24 Mas também há algo novo que você pode fazer no mundo. Você pode tornar o software mais descartável. Então, tipo, o que isso envolve? Bem, criar ambientes mais bem isolados, certo? Assim, você só pode fazer deploy nesse ambiente, que tem acesso apenas aos seus dados. Sem dados de clientes, sem informações de identificação pessoal, seja o que for. Você pode garantir a independência. Pode dizer: “Certo, não são permitidas chamadas de API de entrada de outros sistemas de produção para este sistema neste ambiente, certo?”

09:54 E, assim, tudo que for colocado nesse ambiente será descartável. Redundância. Você pode ter um sistema de backup antigo, desajeitado e difícil de usar. E aí, veja, se as pessoas quiserem fazer vibe coding de seus próprios frontends mais eficientes, deixe que façam vibe coding de frontends próprios, mais eficientes, porque existe um sistema de backup antigo, durável e desajeitado que podem usar se aquela coisinha ruim feita com vibe coding falhar. O que vai acontecer, certo? Tudo bem. Mas não importa se ela falhar. E você pode limitar o escopo, como acabei de dizer, certo? É só uma calculadora para uma pessoa. Só planeja uma festa.

10:26 Há muito mais que poderíamos fazer aqui e discutir sobre maneiras de aumentar a descartabilidade. Na verdade, acho que isso é uma nova disciplina inteira da engenharia de software: não pensar em como aumentar o rigor dos sistemas duráveis, mas em como pegar nossos sistemas e incentivar a descartabilidade, ou permitir mais descartabilidade, permitir que as pessoas joguem essas coisas fora. Uma ideia interessante. Agora, quero enfatizar novamente que a engenharia de software durável não vai desaparecer

10:58 porque essa é a maior confusão que vejo hoje nas redes sociais. Na verdade, acredito que a quantidade absoluta de software durável no mundo vai aumentar, porque as ferramentas de programação com IA tornam cada vez mais fácil criar mais software durável. E outra coisa importante a entender é que descartável e durável não são categorias preto no branco. Há um espectro, como mostrei antes, mas o que muda ao longo desse espectro é o quanto de esforço você vai investir em rigor de engenharia.

11:28 Certo? E isso inclui tanto o esforço imediato quanto o esforço ao longo do tempo, como sempre falamos em relação a software. No entanto, o que você deve fazer, e acho que o que mais deve importar para você, é reduzir o custo do esforço, reduzir o custo do rigor. Se o rigor for mais barato, se for cada vez mais fácil agir com rigor, você terá menos com que se preocupar em relação a onde está nessa escala. Então, essa é outra abordagem que você pode adotar. Se mudar de ideia, fica muito

11:59 mais fácil dizer: “Ah, achei que isso seria descartável, mas agora precisa ser durável.” Quanto mais barato for torná-lo durável, mais fácil será mudar de ideia ou estar errado, porque você nunca vai acertar essa estimativa 100% das vezes. Isso envolve um conjunto diferente de práticas, que não são o rigor de engenharia em si, mas dizem respeito a como diminuir o custo do rigor de engenharia. Eu poderia falar sobre isso por horas. Passei uma parte enorme da minha carreira fazendo isso. Não tenho 10 horas. Tenho uns 5 minutos restantes naquele cronômetro. Então, vou falar do que puder, certo? Vamos falar de padronização. Por que padronizamos? As pessoas dizem: “Bem, não sei, porque o chefe mandou.” Bem, hoje padronizamos porque isso elimina possibilidades. Se você não tem PHP no seu sistema, não precisa descobrir quais são todos os linters para PHP, quais são todas as práticas, quais são todas as falhas de segurança que precisa corrigir. Você simplesmente elimina possibilidades por meio da padronização, e isso reduz o custo do rigor.

12:29 O mesmo vale para frameworks. Por que não ter todos os frameworks de frontend ou todos os frameworks de backend existentes? Porque isso torna o rigor mais caro. Sim, ainda é possível ter rigor. Sim, você ainda poderia fazer o agent escrever todas as suas ferramentas, mas teria que fazer isso toda vez. Protocolos, sabe? Por que usar protocolos RPC padronizados? É tudo pela mesma razão. Os padrões existem por esse motivo. Certo? O que chamo de ferramentas de fluxo interno. Ferramentas de fluxo interno são ferramentas que simplesmente entram em ação. O programador não precisa escolher executá-las. Não precisa entender como elas funcionam. Simplesmente acontecem.

12:59 Se estiver lá, parece gratuito e é confiável. Confiabilidade é muito, muito importante. Por exemplo, não gera um monte de falsos positivos. É rápido. Simplesmente acontece. E quanto mais isso for verdade, mais você também pode aplicar essas ferramentas ao seu software descartável. Se é gratuito e rápido, quem se importa? Facilitar os testes. Isso não é apenas uma questão de: “Como fazemos testes melhores?” Veja, como fazer com que ninguém precise pensar em como melhorar os testes? Como fazer com que todo teste seja rápido e determinístico sem que ninguém

13:30 precise ser especialista em testes? É preciso muito trabalho na infraestrutura de testes para tornar isso possível. Por exemplo, um dos grandes sonhos que sempre tive como responsável pelos testes é que todos fornecessem versões falsas, em memória, dos seus serviços, e eu pudesse simplesmente executar essas versões falsas, em memória, dos serviços. Adivinhe só: o coding agent consegue fazer isso. Então, agora você pode simplesmente fazer isso, certo? Mas precisa escolher fazê-lo e disponibilizá-lo para todo mundo. Outra coisa: rigor máximo. Basta aumentar o rigor em todos os lugares. Defina todas as suas

14:02 regras de lint no máximo. Nunca faça concessões e isso elimina… É muito parecido com a padronização. Elimina muitas conversas. Às vezes, o lint está errado. Se a taxa de falsos positivos for relativamente baixa e isso não tiver consequências catastróficas, não importa, porque, de repente, você evita uma série de erros futuros de lint ou problemas futuros com os quais não precisará lidar. Pergunte a qualquer pessoa que já tenha pensado: “Ah, quero ativar meu linter de repente nesta base de código com um milhão de linhas.” E a pessoa diz: “Nossa. Agora tenho uma alteração de 100 mil linhas para fazer, certo?” É muito mais fácil fazer isso logo de início e deixar ativado para

14:33 todo mundo. Agora, veja. Como eu disse, poderia ficar aqui falando com vocês sobre isso por 10 horas seguidas. Há muito, muito mais que se pode fazer nessa área. Essas são apenas algumas áreas, mas também fazem parte de um campo inteiro da engenharia de software que você pode aplicar no outro eixo. Então, agora isso nos permite responder à nossa pergunta não apenas com “depende”, mas com “sim” ou “não”. Então, a qualidade do código ainda importa? Para software descartável, não. Para software durável,

15:04 regras de lint no máximo. Você nunca faz concessões em nada, e isso simplesmente elimina… É muito parecido com a padronização. Elimina muitas conversas. Às vezes, o lint está errado. Mas, desde que a taxa de falsos positivos seja relativamente baixa e isso não tenha consequências catastróficas, não importa, porque, de repente, há vários erros futuros do linter ou problemas futuros com os quais você não precisa lidar. Pergunte a qualquer pessoa que já tenha pensado: “Ah, de repente quero ativar meu linter nesta base de código com um milhão de linhas.” E a pessoa diz: “Nossa. Agora tenho uma alteração de 100 mil linhas que preciso fazer, certo?” É muito mais fácil simplesmente fazer isso logo de início e deixar ativado para todo mundo.

15:34 Agora, veja. Como eu disse, eu poderia literalmente ficar aqui falando sobre isso sem parar por 10 horas. Há muito, muito mais que você pode fazer aqui. Estas são apenas algumas áreas, mas também há toda uma área de disciplina de engenharia de software que você pode aplicar no outro eixo. Então, isso nos permite agora responder à nossa pergunta, não apenas dizer “depende”, mas responder sim ou não. Então, qualidade de código sequer importa? Para software descartável, não. Para software durável,

16:05 Sim. E podemos responder a uma terceira pergunta, ainda mais interessante: precisa ser caro? Não. Muito obrigado. >> [aplausos] [música]

Transcrição original

[00:01] [music] >> So, today I figured I’d just pick a nice uncontroversial topic that nobody has any opinions about. Right? Nobody nobody said anything on about on this about social media, you know, and of course every take about this on social media is like really deeply nuanced, you know, like people have lots of like depth and like, you know, really big thoughts. You know,

[00:33] maybe there’s a little bit more to it than like yes or no. And you know, of course if you ever ask a senior engineer a question, we always have the same answer to every question, every senior engineer’s favorite answer to every question, which is it depends. Now, that’s not a very helpful answer though, frankly, because what does it depend on? So, let’s start with this. Why did code quality ever matter in the first place? Like I see a lot of people be like, well, it made me feel good. That’s not really a sufficient

[01:04] justification. So, let’s see if we can inject some nuance into this conversation and help everybody at least be able to have a basis for reasoning about it while we’re discussing it. So, let’s see if we can make a framework here and that’s what we’re going to try to do with this talk. Okay. So, we’re going to start off with everything you want to ever accomplish with a piece of software uh depends on two factors and two factors alone. And that is understanding and executing on that understanding, whether that’s aligning a model, scaling a system, driving adoption, anything. All software success is determined by these

[01:35] two factors. This is why we have things like debuggers and observability and evals and even tests. All those things actually are there to improve your understanding or ability to execute on that understanding. People think that they’re there for other reasons, but fundamentally they’re there for that reason. Everything we have ever done in the field of code quality is exclusively and only for these two things. It’s not for anything else. Not doesn’t have something to do with correctness or something else. It has to do only with these two things. Now, there’s two understandings that are the most important to have if you’re going

[02:05] to be a software engineer. There are other understandings to have about software if you’re going to be a product, if you’re going to be in sales, but if you’re a software engineer, there’s the two that are the most important. And the first is what is the behavior of the system? Like con- the concretely, not what does a doc say the behavior of the system is, but what is the actual behavior of the system? And the second one is how do I correctly and safely modify that behavior, okay? On a very small system, if you want to understand what the system does, I just tell you what it does. It prints

[02:37] hello world. You say, “I want it to say hi world.” I say, “Okay, I will make it say hi world now.” There’s very little to understand about it other than purely what it does. That’s all of the understanding that you need. However, any real software system is enormously complex. This is a real map of the code base of Chromium, which is the open-source project behind Chrome. And if you think about all of the different ways that these components can interact, they have essentially infinite possible behaviors.

[03:09] Like, I could not describe to you in words the behavior of Chromium as a whole as a system. However, what I can describe to you, and as we all know, everybody’s been a software engineer for a while, I can describe to you components of the system. I can successfully describe to you how a component of the system behaves. So, this is the URL parser, the actual functions and stuff for the URL parser of Chromium. It figures out all the different parts of the URL. And this

[03:40] is the whole reason that code exists. The whole reason that we have code at all in the first place is for structure. It Because it What do I mean by that? Okay. So, both of these two things on the left and on the right will print Hello World if run on a Linux machine. However, on the left, you can see that it is Hello World. It has the identity and structure of Hello World. On the right, you just see a series of

[04:11] instructions with no particular identity, recognizable or understandable identity. It’s not a component, it’s just a bunch of instructions. While that’s understandable there, if that was millions or billions of lines of that, it would be much harder to grok. In the past, we’ve talked about things like readability or testability or things that seemed like human concepts about code, but what actually mattered the most always was that the system had some sort of understandable structure. So, it’s the structure that actually matters.

[04:42] And when this modifies when this matters the most is when you want to modify the system, the second uh understanding that we talked about. All modifications to a system carry two categories of risk. The first is that you will introduce some sort of problem. And a problem isn’t just a bug, it’s anything bad that could happen. Like your project could take much longer than you expect. Uh it could not behave in the way that you wanted it to for your users. The project could fail because you have budget overruns. Any kind of problem could happen from just you

[05:12] trying to go through the process of making this change. And the second is you could make it harder to make future changes. In particular, what that means is you can make it more likely to have future problems. You could increase future risk of the system. These two things are caused by under problems with understanding. So, the first has to do with the difficulty of understanding the system in the first place, and the second is you make the system harder to understand. I can reduce every postmortem I have ever read

[05:43] for any incident to these two factors in one way or The the production configuration was too hard to understand, somebody made something impossible to understand, there were emergent properties of the system that were impossible to understand, whatever. Point two feeds into point one in a vicious cycle that compounds in a non-linear fashion. So, the difficulty of understanding does not grow linearly, it compounds over time. You will eventually reach a point, and

[06:13] all systems eventually tend to reach this point, where every modification involves some sort of problem. Uh and you know, some some systems get to the point where like you can’t modify them at like if you think of like, you know, some of like your giant 100 million 500 million line mainframe code bases and that everything, every change is some sort of problem. You know, you’ll see it in organizational issues, you’ll see it all over the place, you’ll see it in timelines, whatever. And look, there’s a lot of arguments about maybe future models will fix this. Look, maybe

[06:44] they will. Maybe future models will have infinite ability to deal with complexity somehow. Uh but we don’t have to discuss that today because I think models are doing something else really interesting right now. They are creating a new kind of software, a new category of software. This category has always existed, but it’s about to become a hundred thousand times more common than any other form of software. And that is disposable software.

[07:15] So, what is that? Okay. So, imagine a world in which the consequences of failure for your system are very minimal or non-existent. Imagine that there’s very few people that depend on it or and almost no other systems depend on that piece of software. Change management, very minimal, non-existent. Imagine the cost of replacement went to near zero. You could replace the whole thing in hours or days. And it had basically no cost of maintenance. In that world, code quality does not

[07:49] matter. Because it all of those things we were trying to prevent about the compounding risks over time don’t exist. Traditionally, we’ve always built durable software. You know, it lives for years. It’s depended on by millions or thousands of people. There’s huge consequences of failure, potentially business catastrophic consequences of failure. And it requires enormous maintenance. Most of the software engineers in the world spend most of their time maintaining these giant durable systems.

[08:21] I expect this to continue to exist. So, this is one of the areas where I think sometimes the conversation goes a little astray, okay? Durable systems will continue to probably be the most important systems in the world. And there will be probably more of them. But the most numerous systems will be disposable software. They will be replaceable in hours. They will be depended on by a few or change management just won’t matter. And look, if it doesn’t work, you will

[08:52] give everybody agents. They’ll make a version of it themselves. You know, maintenance will be unimportant or nearly free. Don’t like the calculator on your OS? Make your own. Want to plan a party for your kids? Write a party planner software just for that one party. Throw it away. Code quality doesn’t matter. Nobody cares. In the future, we will apply engineering rigor to the degree of disposability of the software. On the left, nothing. None of our practices of engineering rigor matter at

[09:24] all. On the right, all the practices of engineering that we have built up over the last many decades matter greatly. We can determine where you are on this scale by those four factors that I have been talking about. Consequences, cost of replacement, dependencies, and cost of maintenance. If they’re all low, it’s disposable software. If they’re all high, it’s durable software. And look, any person who’s written software for a long time knows you should err on the side of it being durable. You should err on these all being higher than you expect them to be.

[09:54] But, there’s also a new thing you can do in the world. You can make software more disposable. So, like, what do What does that involve? Well, come up with better isolated environments, right? So, hey, you can only deploy to this environment that has access to only your data. No customer data, no personally identifiable information, whatever. You can enforce independence. You can say, “Okay, no inbound API calls from other production systems are allowed to this system in this environment, right?”

[10:26] And so, everything deployed to that environment is disposable. Redundancy. You can have an old clunky backup system that is like hard to use. And then, like, look, if people want to vibe code their own like more efficient front ends, you let them vibe code their more own more efficient front ends because there is an old durable clunky backup system that they can use if their, you know, crappy little vibe coded thing fails. Which Which it will fail, right? That’s fine. But, it doesn’t matter if it fails. Uh and you can limit scope, just like I talked about, right? It’s just a calculator for this one person. It just plans this one party.

[10:58] There’s so much more we could do here and talk about ways of increasing disposability. In fact, I think this is a whole new discipline of software engineering, not to think about how we improve the rigor of durable systems, but how do we take our systems and how do we encourage disposability or allow more disposability, allow people to throw these things away. Interesting thought. Now, I want to re-emphasize that durable software engineering is not going away

[11:28] because this is the biggest confusion that I see on social media today. In fact, I believe the absolute amount of durable software in the world will increase because AI coding tools make it easier and easier to make more durable software. And another important thing to understand is that disposable and durable are not black and white. There’s a spectrum, like I showed before, but that spectrum what changes across the spectrum is how much effort you’re going to put into engineering rigor.

[11:59] Okay? And that’s both immediate effort and effort over time, just like we’ve always talked about for software. However, what you want to do, and I think what you want to care about the most, is reducing the cost of effort, reducing the cost of rigor. Like, if rigor is cheaper, if it’s the the easier and easier you make it to be rigor, the less you have to worry about where you are on the scale. So, this is another approach you can take. If you change your mind, it’s much

[12:29] easier to go like you’re like, “Oh, I thought this was going to be disposable and now it needs to be durable.” The cheaper you make it to make it durable, the easier it is to change your mind or to be wrong because you’re never going to be 100% right all the time on that estimate. So, that involves a different set of practices that are not engineering rigor themselves, but that are about how to decrease the cost of engineering rigor. Now, I could talk about this for hours. I have spent a tremendous amount of my career doing this. Uh I don’t have 10 hours. I have about 5

[12:59] minutes left on that timer. So, I’ll tell I’ll talk about what I can, okay? Let’s talk about standardization. Why do we do standardization? People are like, “Well, I don’t know because the boss said so.” Well, now, we do standardization because it removes possibilities. If you don’t have any PHP in your system, you don’t have to figure out what are all the linters for PHP, what are all the practices, what are all the security holes I have to fix. You just eliminate possibilities through standardization and it just reduces the

[13:30] cost of rigor. Uh same thing with like frameworks. Like why don’t you want to have every front-end framework or every back-end framework in the in existence? Because it makes rigor more expensive. Like yes, rigor is still possible. Yes, you could still have the agent code up all your tools, but you have to do it every single time. Uh you know, proto- uh protocols. Why do you want to have standardized RPC protocols? All the same thing. Standards are all for this reason. Okay? Uh what I call inward flow tooling. So, inward flow tooling is tooling that just occurs. The programmer doesn’t have to choose to run it. They don’t have to understand how it runs. It just happens.

[14:02] If it’s there, it it’s feels and seems free and it is reliable. Reliability is very, very important. Like it doesn’t have a ton of false positives. It’s fast. It just happens. And the more that’s true, like you can apply it to your disposable software, too. If it’s free and fast, who cares? Uh making testing easier. So, this is not just about like, “Hey, how do we do better testing?” Look, how do you make it so that nobody has to think about how to do better testing? How do you make it so that every test is fast and deterministic without anybody

[14:33] having to be a deep expert in testing? There’s a ton of work that you have to put into test infrastructure to make that possible. For example, you know, one of the great dreams that I’ve always had as a as a test owner is that everybody would provide in-memory fake versions of their services and I could just run those in-memory fake versions of their services. Guess what? The coding agent can do that. So, you can just do that now, right? But you have to choose to do it and make it available to everybody. And another thing is, look, maximum strictness. You just turn the strictness up everywhere. You turn You set all your

[15:04] lint rules to maximum. You You never compromise on anything and it just eliminates It’s very similar to standardization. It eliminates a ton of conversations. Sometimes the lint is wrong. Like as long as the false positive rate is relatively low and it doesn’t have catastrophic consequences, it doesn’t matter because all of a sudden there’s a bunch of future lint errors or future issues that you don’t have to deal with. Like, ask anybody who’s been like, “Oh, I suddenly want to turn on my linter in this million-line code base.” And they’re like, “Oh, wow. Now here’s my 100,000-line change that I need to make, right?” Much easier to just do that up front and have it on for

[15:34] everybody. Now, look. Like I said, I could literally stand here and talk to you about this straight for 10 hours. There is much, much more you can do here. This is just a few areas, but also a whole area of software engineering discipline that you can apply on the other axis. So, this lets us now answer our question, not just it depends, but yes or no. So, does code quality even matter? For disposable software, no. For durable software,

[16:05] yes. And we get to answer a third and even more interesting question, which is does it have to be expensive? No. Thank you very much. >> [applause] [music]