A filosofia da tecnologia tediosa, criada antes da era da IA, ganha uma nova e ainda mais crucial relevância com o surgimento dos assistentes de codificação baseados em Inteligência Artificial. Aaron Brethorst, em "Choose Boring Technology, Revisited", argumenta que, embora os princípios fundamentais de McKinley continuem válidos, ferramentas como Copilot e Claude adicionam uma dimensão nova e perigosa à equação. A IA não anula a necessidade da tecnologia tediosa; pelo contrário, acentua os riscos de ignorá-la.
Assistentes de Codificação de IA: O Novo Obstáculo
A mudança mais significativa na indústria, desde o ensaio original de McKinley, é a proliferação de assistentes de codificação baseados em Modelos de Linguagem Grandes (LLMs). Embora essas ferramentas sejam extraordinariamente proficientes em gerar código plausível e profissional para uma vasta gama de tecnologias, incluindo implementações complexas como microsserviços com Kubernetes ou federação GraphQL, essa capacidade introduz um novo perigo: gerar código para uma tecnologia com a qual não está familiarizado.
O problema reside no fato de que os LLMs podem "alucinar" detalhes técnicos, produzindo código que, à primeira vista, parece correto, mas é fundamentalmente defeituoso de maneiras sutis. Brethorst relata ter observado engenheiros aceitando código gerado por IA que continha APIs obsoletas, antipadrões de segurança ou problemas de desempenho que só se manifestariam sob carga de produção. A natureza enganosa desse código é que ele "parecia certo" — seguia as convenções de nomenclatura, incluía tratamento de erros adequado e parecia profissional. Apenas alguém com um conhecimento profundo da tecnologia subjacente seria capaz de detectar as falhas.
"Efeito Multiplicador de Desconhecidos"
A combinação de uma tecnologia desconhecida com código gerado por IA cria um cenário de incerteza exponencial. O engenheiro se vê em uma situação precária onde:
- Não consegue determinar se a framework escolhida é adequada para o problema.
- Não tem certeza se a implementação da IA segue as melhores práticas.
- Não consegue distinguir entre o código boilerplate e a lógica de negócio essencial gerada pela IA.
- Desconhece quais modos de falha precisa antecipar.
Brethorst compara essa situação a um "cargo-culting vezes 2.356", destacando o risco significativamente amplificado. O engenheiro deposita confiança cega em dois sistemas que não compreende: a nova tecnologia e o LLM. A confiança enganosa que o código de IA, com sua aparência profissional, proporciona, mascara uma profunda falta de entendimento, transformando a depuração futura em um verdadeiro pesadelo.
IA: "Multiplicador de Força"
A utilização de um assistente de IA em conjunto com uma tecnologia que o engenheiro domina — uma parte "tediosa" e familiar do seu stack — transforma a IA de um risco em um "multiplicador de força" potente. É aqui que a "Ignorância Produtiva" se manifesta com maior eficácia: o engenheiro aceita a IA para gerar a sintaxe exata de código repetitivo, confiando no seu conhecimento aprofundado para auditar o resultado.
Brethorst exemplifica esta ideia: ele confia no Claude para gerar código Rails devido à sua familiaridade com a framework, o que lhe permite identificar rapidamente sugestões problemáticas. Da mesma forma, usa o Copilot para JavaScript, pois compreende as nuances da linguagem e pode verificar a exatidão do que é gerado. Neste cenário, a IA assume o trabalho pesado do código
boilerplate, libertando o engenheiro para se concentrar na arquitetura e na lógica de negócio. A experiência do engenheiro serve como uma salvaguarda essencial, permitindo-lhe usufruir da produtividade da IA enquanto minimiza os riscos.
Esta dualidade revela uma nova realidade na era da IA: aumentou a importância da experiência profunda em um stack tecnológico. A IA alterou a natureza do risco no desenvolvimento. Antes da IA, um engenheiro a trabalhar com uma framework desconhecida provavelmente produziria código visivelmente confuso ou não funcional. Agora, as ferramentas de IA podem gerar código sintaticamente correto e bem formatado que, no entanto, esconde falhas sutis.
Assim, a competência crucial desloca-se da simples escrita de código para a capacidade de auditoria, exigindo um conhecimento profundo do domínio. A aptidão de analisar um bloco de código gerado por IA e identificar "Isto parece correto, mas está errado devido a X, Y e Z" tornou-se a nova habilidade de alto valor. Esta capacidade de auditoria só pode ser desenvolvida através de experiência prática e profunda com um stack tecnológico — a essência de dominar uma tecnologia "tediosa".
As decisões tecnológicas em uma era dominada pela IA requerem ainda mais cautela e deliberação. No próximo artigo, exploraremos como avaliar e selecionar tecnologias de forma sistemática, considerando não apenas suas capacidades técnicas, mas também seu impacto a longo prazo na manutenibilidade e segurança do sistema.
Top comments (0)