Não faz sentido, se uma IA for gerar a maior parte do código que fizermos, ainda usar IDEs e ferramentas pra ler linha por linha. Precisamos de formas melhores de entender código "na escala da IA".

Eu acredito bastante que IA vai seguir melhorando, e que no geral vai mudar o que a gente entende por programar. E justamente por isso eu acho que a gente precisa de ferramentas melhores.

Por isso eu acredito muito que a gente precisa de ferramental melhor pra *entender* o que a IA tá fazendo.

Acho que a maior parte dos receios que eu tenho com uso de IA atualmente são relacionados a isso. O pessoal frequentemente usa IA pra "não se importar" com o que tá fazendo. Saiu, pareceu que funciona, foda-se, é isso aí.

Eu realmente não me sinto bem de só entregar um negócio que eu sei que tá cagado. Às vezes é necessário? É, mas eu vou ficar em cima pra resolver.

Nos EUA a gente vê ainda mais vagas presenciais mas também mais vagas remotas, com menos híbridas: 12% remotas e em torno de 64% presenciais.

Mas justamente por ser tão complexo, é importante ter mapeado tudo que pode ser afetado por uma alteração no sistema - e tornar alterações processos dinâmicos, com gatilhos pra reversão automática.

No geral, sistemas hoje são grandes e complexos. Especialmente num caso como a Cloudflare, que processa volumes absurdos. Não estou falando que é fácil lidar - certeza que isso nunca tinha dado problemas antes.

Como a Cloudflare poderia ter resolvido isso:

Quando uma nova config fosse gerada, ela poderia ser distribuída pra só uma fração pequena das máquinas - e essa fração aumentar mediante monitoramento reportando saúde dessas máquinas. Isso se chama "canary release".

Então no final a sequência é:

1. Mudança de configurações no banco
2. Distribuição de arquivo inválido pra máquinas da rede
3. Máquinas começam a quebrar em massa

Então cada vez que uma máquina inicializava ela podia pegar o arquivo com uma instância "ok" ou com uma instância "quebrada" do banco de dados. Isso fez com que a indisponibilidade tivesse um padrão inicial de intermitência que tornou mais difícil identificar a causa.

O arquivo de configuração é gerado pelo sistema da Cloudflare a cada 5 minutos pra permitir atualizações rápidas pra lidar com novos tipos de tráfego.

O problema é: O deploy quebrado estava gradualmente sendo propagado.

Isso, por sua vez, colocou o tamanho do arquivo acima do limite máximo que as máquinas estavam configuradas pra ler (em geral é uma boa prática ter um tamanho máximo pra arquivos de configuração!), fazendo elas falharem em inicializar.

Esse arquivo, por sua vez, é gerado a partir de configurações armazenadas em um banco de dados distribuído.

O problema foi ao configurar esse banco. Uma configuração errada fez com que o arquivo contivesse várias cópias das regras.

A causa raiz da Cloudflare sair do ar foi um arquivo que é gerado e colocado no sistema de arquivos da máquina toda vez que uma máquina da Cloudflare é deployada. Esse arquivo contém configurações pro modelo de detecção de bots da Cloudflare.

Não, implementando uns protocolos de criptografia