O código limpo ainda importa quando o leitor deixa de ser somente o ser humano?
Por que a obsessão por padrões de projeto pode estar cegando os devs pra o problema real
De forma geral a comunidade de desenvolvimento vive sob a regra de que “escrevemos código para humanos, não pra máquinas” isso é falado nas faculdades até hoje. Essa premissa fundamentou quase tudo o que se considera como boas práticas: clean code, SOLID e padrões de arquitetura complexos que visam facilitar a manutenção e a legibilidade. No entanto, Keith Casey do artigo “Developers are Solving The Wrong Problem” levanta uma provocação no mínimo desconfortável pra algumas pessoas: se estamos entrando em uma era onde a inteligência artificial gera e mantém o código, será que ainda estamos resolvendo o problema certo?
A mudança de paradigma na legibilidade
O argumento central é que essa fixação pela beleza e estrutura do código nasceu de uma limitação humana que é a de que ler o código de outra pessoa é extremamente difícil. É gerada uma energia monumental pelos devs que tentam criar abstrações para que o próximo dev consiga entender a lógica. Contudo, para uma IA, a profundidade de uma pilha de chamadas ou a falta de padrões estéticos são irrelevantes. O código está deixando de ser um artefato que precisa ser “bonito” e legível aos olhos humanos para se tornar algo funcional e até muitas vezes, descartável.
O surgimento do chamado vibe coding exemplifica essa transição. Nele, o foco sai da sintaxe e vai para a intenção, se o objetivo final é resolver uma dor do usuário, e uma ferramenta consegue traduzir essa intenção em uma solução funcional quase instantaneamente, o valor de um código artesanalmente estruturado começa a ser questionado. Citando diretamente Casey “instead of seeing vibe coding as a threat, we need to consider it another tool.”
Validar é o novo programar
Se o código em si está se tornando uma commodity gerada por máquinas, a responsabilidade profissional do desenvolvedor muda de lugar. O desafio deixa de ser a escrita da sintaxe e passa a ser em resolver problema, Casey sugere que o verdadeiro trabalho agora reside na validação, não importa a velocidade que o código é gerado se ele não resolve o problema correto ou se introduz falhas silenciosas.
O programador precisa atuar mais como um garantidor de resultados do que como um “digitador” de lógica. Isso exige uma compreensão muito mais profunda do domínio do problema do que da stack em si, o autor pontua “your goal is solving the problem, and your code is merely the byproduct or the tool to get to that solution”. Afinal, a IA pode escrever o código, mas ela ainda não consegue discernir se aquele código é, de fato, a solução que o negócio precisa pra prosperar.
O valor real além da ferramenta
No fim das contas, esse assunto força a encarar uma realidade pragmática: o usuário final não se importa se a API segue o padrão mais moderno do mercado ou se o código está perfeitamente desacoplado, ele se importa com a utilidade. Casey aponta que se continuarmos medindo o sucesso do código pela elegância enquanto outros entregam valor real em uma fração do tempo, o problema certo não está sendo resolvido.
A transição para esse novo cenário exige menos ego sobre a autoria do código e mais foco na eficácia da entrega. O código perfeito que demora semanas para ser entregue pode ser muito menos valioso do que um código “bom o suficiente”, mas que resolve uma dor imediata do negócio hoje.
Para se aprofundar mais nas ideias do autor, este artigo foi baseado no texto “Developers are Solving The Wrong Problem”, de Keith Casey.”
É uma discussão realmente polêmica. Eu mesmo, entrei na programação pela paixão pela lógica e a resolução de problemas. Não necessariamente por "resultados onde o código é só um meio para um fim, totalmente descartável".
"O desafio deixa de ser a escrita da sintaxe e passa a ser em resolver problema", eu concordo. Mas não foi sempre assim? O ponto é que resolver problemas em CÓDIGO já não é mais tão útil. Não importa quase nada o seu algoritmo ser exatamente do jeito que é.
Eu sinto que, ao invés de escrever relatórios do zero e evoluir nossas ideias com ela, estamos apenas imprimindo os papéis e revisando erros de pontuação e lógica. Até que ponto "programar" pode ser considerado o que já foi um dia quando há outra ferramenta "programando" por você? Fazendo código, de fato, como você fazia antes.
Vai - se já não está havendo - uma mudança total do paradigma de programação. Isso me assusta, mas também me traz a reflexão do vídeo "O fim da programação" do Filipe Deschamps na última análise do cenário que ele fez, onde ele cita as mudanças que ocorreram no mundo, na programação (que não foram pouca), e sempre nos adaptamos.
Aqui eu levo comigo a Esperança dita pela Angela Duckworth no livro "Garra: o poder da paixão e da perseverança", que não significa achar que vai ficar tudo bem e perfeito, mas que se tudo der "errado", basta tentar novamente, e se não der, tentar outra abordagem. Evoluir, de fato.
Sempre haverá espaço no mundo para pessoas com paixão em raciocínio lógico e resolver problemas. Nesse ponto, o "código" que faz isso pra nós hoje, em 10-20 anos será outra coisa. E tudo bem. Deveríamos aprender com a solução de problemas. Toda solução pronta exige desapego do problema, de se afastar para pensar melhor e avançar. Desapegar, mas ainda se importando, com o código, pode ser o caminho.
👏🏼👏🏼👏🏼