#192 - As leis não escritas da engenharia de software

Aprenda com os erros que todo engenheiro já cometeu pelo menos uma vez

abr 08, 2026

Hey! 👋

Tá chegando o Codecon Universe 26! Um hackathon online de 29 a 31 de maio pra quem quer construir coisas inúteis, absurdas e completamente geniais. Soluções pra problemas que não existem, projetos que desafiam a lógica e prêmios pra quem sobreviver até o final.

🪐 Codecon Universe 26

Gabriel Nunes (@nunesgabriel)

As leis não escritas da engenharia de software

Todo dev tem uma lista mental de lições que aprendeu da pior forma possível. Aquelas verdades que ninguém colocou no README, ninguém ensinou no bootcamp e ninguém admite abertamente, até que a produção quebra às 23h de uma sexta-feira e a memória bate forte.

O autor do Manager.dev catalogou sete dessas leis, destiladas de anos quebrando coisas e prometendo nunca mais repetir o erro. A primeira e mais universal: “é sempre relacionado”. Quando a produção quebra logo depois de um deploy, o instinto humano grita “não tem nada a ver com o que eu mexi”. Quase sempre tem. Regra de ouro: primeiro faz rollback, depois debate a causa.

Vem junto uma lei que todo mundo ignora até precisa, o backup que nunca foi restaurado não é backup, é esperança. Se você nunca testou a restauração, não sabe se o backup funciona de verdade. Outra lei clássica: logs são o diário de bordo do sistema, mas você só percebe que os seus são inúteis quando está no meio de um incidente tentando decifrar mensagens que você mesmo escreveu. “Você sempre vai se odiar pela forma como escreve seus logs” e vai reescrever, e vai se odiar de novo daqui a seis meses.

Tem a lei do rollback planejado, que deveria ser requisito obrigatório antes de qualquer deploy significativo. Tem a lei dos quatro olhos, especialmente quando você tem acesso a produção, banco de dados ou qualquer coisa que possa causar estrago irreversível se você está com dúvida se é seguro fazer sozinho num domingo à noite, essa dúvida já é a resposta. E tem a lei do “a gente resolve isso depois”, que na prática significa “isso vai para o cemitério do backlog e nunca mais será visto”.

O que une todas essas leis é simples: elas não são sobre tecnologia. São sobre comportamento humano sob pressão. Frameworks mudam, linguagens mudam, stacks mudam. O ser humano que subestima o risco, que acha que a exceção não vai acontecer, que adia o que é chato, esse permanece constante. Conhecer as leis não garante que você não vai quebrá-las, mas aumenta bastante a chance de você reconhecer a tempo quando está prestes a fazê-lo.

Um recado do patrocinador 📣

Um novo momento, a mesma ambição de crescer junto

Crescer rápido é desafiador. Mas crescer com clareza sobre quem você é, o que entrega e onde quer chegar, é o que realmente sustenta o longo prazo.

O Asaas entrou exatamente nesse momento.

Depois de um ciclo importante de evolução do negócio, a empresa passou por um rebranding que vai além da estética. É uma atualização que traduz com mais precisão o que o Asaas já se tornou e o que está construindo para os próximos anos.

Na prática, isso se reflete em direcionamentos mais claros: uma missão ambiciosa, um propósito definido e um posicionamento que conecta tecnologia financeira e operacional à evolução de negócios em escala. Confira o manifesto da marca.

Mas o ponto mais interessante, olhando pela perspectiva de carreira, é outro.

Esse tipo de movimento geralmente acontece em empresas que estão amadurecendo rápido e que precisam que as pessoas cresçam junto com elas.

No Asaas, isso aparece no dia a dia. Times que lidam com decisões cada vez mais estratégicas, projetos que ganham escala e complexidade, e um ambiente que exige autonomia, colaboração e visão de negócio. A marca evolui porque o negócio evolui. E o negócio evolui porque as pessoas evoluem junto.

Para quem quer fazer parte desse próximo capítulo, o Asaas segue com oportunidades abertas no time: https://go.codecon.dev/asaas-news-vagas

👩‍💻 O que sobra pro dev depois da IA?

A IA chegou, tomou as tarefas chatas e deixou as difíceis pra você. Para artistas, LLMs tiram a parte mais humana do trabalho e deixam a a difícil. Para devs, é o contrário: tiram o trabalho braçal e deixam a parte criativa. Mas não é tão simples quanto “a IA virou seu colega de trabalho”. Mais de 700 mil profissionais de tech foram demitidos desde o lançamento do ChatGPT, e quem ficou precisa decidir o que vai ser feito na era onde o código ficou barato e o julgamento ficou caro. Duas categorias de devs estão em apuros: os que encaram programação como emprego estável, e os que a encaram como arte. Os dois grupos vão precisar se reinventar, mas por razões completamente diferentes.

☠️ A internet morreu. Essa não é mais uma teoria.

Costumava ser especulação de fórum underground: a teoria da internet morta dizia que a maioria do conteúdo online já era gerada por bots, não por humanos. Hoje isso não é mais teoria. O HackerNews passou a restringir contas novas por excesso de submissões geradas por IA, o LinkedIn é 80% slop, e posts do Reddit estão sendo inundados por bots que escondem seus comentários. A web estranha, pessoal e idiossincrática dos anos 2000 não desapareceu, ela só ficou invisível debaixo de uma avalanche de conteúdo sintético. A pergunta não é mais “será que isso está acontecendo?”, é “como a gente vive aqui agora?”.

🔱 A engenharia de software se dividiu em três

O custo de transformar um requisito em código colapsou. O que mudou não foi a tecnologia em si, mas onde está o gargalo: saiu da implementação e foi parar no julgamento. O mercado está se estratificando em três camadas: grandes empresas de tech onde a IA multiplica engenheiros sênior, enterprises que precisam de guardrails e consultores fracionados, e um ecossistema emergente de devs locais servindo pequenos negócios que agora podem pagar por software customizado. O problema é que se as empresas pararam de contratar júnior, de onde vêm os futuros seniors? A conta simplesmente não fecha.

🧠 Dívida de compreensão: a conta que a IA vai cobrar

Dívida técnica você conhece. Você escolheu o atalho, sabe onde mora, dá pra agendar o pagamento. A dívida de compreensão é diferente: ela se acumula sem ninguém tomar uma decisão consciente. É a soma de centenas de code reviews onde o código parecia certo, os testes passaram e tinha mais um PR na fila. Velocity no verde, DORA estável, coverage impecável, e ninguém percebe que o time inteiro parou de entender o que o sistema faz de verdade. Um estudo da Anthropic mostrou que devs que usaram IA na tarefa tiraram 17% menos na prova de compreensão depois. Você vai pagar essa dívida mais cedo ou mais tarde, e ela tem juros.

🚀 Quando entregar rápido demais vira o problema

Entregar software dá uma sensação boa. Cria momentum, parece progresso, vicia. Com IA, a velocidade ficou tão alta que o produto começa a ser moldado pela capacidade de construir, não pelo problema que precisa ser resolvido. O Mozilla.ai olha pra esse fenômeno com preocupação: quando código não é mais o gargalo, o gargalo passa a ser clareza, julgamento de produto e a coragem de não entregar ainda. Ficamos muito bons em construir software. Não ficamos igualmente bons em decidir o que construir, ou se vale construir.

🔦 O guia que todo dev deveria ter lido antes

O stuffeverybodyknows.com não é tutorial, não tem sintaxe, não tem framework, não tem stack. É um mapa do que você precisa saber pra ser dev na web, independente do ano ou da tecnologia. Dunning-Kruger, acessibilidade, performance, segurança, debugging, arquitetura, soft skills, tudo o que ninguém ensina mas todo mundo assume que você já sabe. Foi dado mais de 30 vezes em bootcamps diferentes, e quase nada precisou ser atualizado. Porque o que é atemporal, é atemporal.