Escolha tecnologias entediantes, revisitado (2025)

• O princípio "Choose Boring Technology", de focar em uma stack tecnológica que possa ser validada, tornou-se ainda mais importante na era das ferramentas de programação com IA
• As empresas devem usar estrategicamente seus limitados "innovation tokens" em tecnologias com confiabilidade comprovada
• Ferramentas modernas de programação com IA geram código com aparência plausível para praticamente qualquer stack tecnológica, mas quando o usuário combina duas ou mais tecnologias que não conhece, torna-se impossível validar erros
• Em uma stack que você já conhece bem, as ferramentas de programação com IA funcionam como um force multiplier (multiplicador de capacidade), mas em tecnologias desconhecidas acabam virando apenas um meio de dependência
• Quanto maior a qualidade do código gerado por IA, mais difícil fica encontrar problemas, o que aumenta ainda mais o valor de uma compreensão profunda da tecnologia

---

Reafirmação do princípio Choose Boring Technology

• A concordância com o texto de Dan McKinley de 10 anos atrás, "Choose Boring Technology", continua a mesma mesmo depois de uma década
  • Ao iniciar um novo projeto, a primeira pergunta é: "isso é uma desculpa para aprender algo novo ou uma tentativa de resolver um problema?"
  • Se o objetivo é aprender algo novo, limitar os elementos desconhecidos a um só; se o objetivo é resolver o problema, manter as tecnologias que já conhece
• Com a chegada dos LLMs e das ferramentas de programação com IA agentic, esse princípio se tornou ainda mais critical

O argumento central de McKinley

• As empresas possuem "innovation tokens" limitados e devem usá-los estrategicamente em tecnologias estabelecidas e bem compreendidas, não em tecnologias interessantes, porém não comprovadas
• Tecnologias entediantes têm modos de falha (failure modes) conhecidos, funcionalidades bem compreendidas e confiabilidade operacional comprovada
  • Quando ocorre uma falha às 3 da manhã, é melhor depurar uma tecnologia para a qual exista resposta no Stack Overflow do que desbravar território desconhecido
• Esse princípio era verdadeiro em 2015 e continua verdadeiro hoje

Ferramentas de programação com IA como nova variável

• Ferramentas modernas de programação com IA geram código com aparência profissional para quase qualquer stack tecnológica imaginável
  • Se você pedir ao Claude ou ao Copilot uma implementação com microservices baseados em Kubernetes, GraphQL federation e um framework JavaScript recente, eles retornam código que segue as regras e até funciona
• Se você estiver usando duas ou mais tecnologias que não conhece, não haverá maneira de verificar se a IA está entregando um resultado errado
  • Apesar de suas capacidades impressionantes, LLMs alucinam (hallucinate) em detalhes técnicos
• Há casos observados de engenheiros aceitando sem questionar código problemático gerado por IA
  • uso de APIs deprecated, implementação de antipadrões de segurança, problemas sutis de desempenho que só aparecem sob carga de produção
  • O código parecia correto, seguia convenções de nomenclatura e tinha tratamento de erro adequado, mas estava errado de um jeito que só alguém familiarizado com aquela tecnologia conseguiria perceber

Tecnologia desconhecida + código de IA = multiplicação da incerteza

• Combinar uma tecnologia pouco familiar com código gerado por IA não soma incógnitas, e sim as multiplica
  • Não dá para saber se a escolha do framework é apropriada
  • Não dá para saber se a implementação da IA segue best practices
  • Não dá para saber o que no código gerado é boilerplate e o que é lógica de negócio central
  • Não dá para saber quais modos de falha precisam ser monitorados
• Isso vai além de simples cargo-culting: é um problema no nível de "cargo-culting vezes 2.356"

Onde tecnologias entediantes e IA geram sinergia

• Quando você entende a stack base, as ferramentas de programação com IA se tornam muito poderosas
  • Como conhece Rails suficientemente bem, é possível perceber quando o Claude faz uma sugestão suspeita (com ajuda do context7)
  • Como entende as características do JavaScript, é possível fazer fact-check nas sugestões do Copilot
• A IA vira um force multiplier em tecnologias que você já entende e se torna uma muleta de dependência em tecnologias que você não conhece

Diretrizes práticas para a era da IA

• Ao avaliar uma nova tecnologia, pergunte primeiro: "se a IA gerar o código de implementação dessa tecnologia, eu serei capaz de revisá-lo adequadamente?"
  • Se a resposta for "não", essa tecnologia não deve ser usada em algo mission-critical
• Se decidir aprender algo novo (e você só tem um innovation token), invista tempo real para compreendê-lo profundamente o bastante para fazer fact-check nas sugestões da IA
  • Não copie e cole torcendo para dar certo
• Resista à tentação de adotar várias tecnologias novas ao mesmo tempo só porque há ferramentas de IA
  • A IA faz parecer que é possível lidar de uma vez com uma nova linguagem, um novo framework e uma nova infraestrutura, mas você não consegue validar nenhum deles adequadamente

Riscos ampliados na era da IA e conclusão

• O argumento original de "choose boring technology" era reduzir a complexidade operacional e a carga cognitiva, e essa preocupação continua válida
• Na era da IA existe um risco adicional: a false confidence (falsa confiança) causada por uma IA que gera código com aparência profissional em qualquer stack
• A qualidade do código gerado por IA torna a descoberta de problemas ainda mais difícil
  • Antes, código ruim parecia ruim; agora, é preciso entender o domínio com profundidade para perceber problemas sutis
• Ao resolver problemas, use o que você já conhece; ao aprender algo novo, concentre-se em aprender; e não confunda código gerado por IA com compreensão real
• A tecnologia mais entediante da sua stack talvez seja justamente aquela que você entende bem o bastante para perceber quando a IA está errada
  • Em um mundo em que a IA gera com confiança milhares de linhas de código para tecnologias que você nunca usou, o valor dessa compreensão é maior do que nunca