-7
romulosardinha
2 min de leitura ·

E se tirássemos o humano do código?

O que acontece quando o humano sai da equação? Boas práticas de software para compensar limitações humanas ainda fazem sentido?

Uma hipótese que venho testando e queria compartilhar.

A maior parte das práticas que consideramos "boas" em engenharia de software, clean code, design patterns, camadas de abstração, frameworks, ORMs, convenções de nomenclatura, existe por uma razão específica: o cérebro humano tem limites.

Limites de memória de trabalho. De contexto simultâneo. De capacidade de rastrear efeitos colaterais em um sistema grande.

Nem todas essas práticas são apenas "conforto humano", interfaces permitem trocar implementações, separação facilita testes, encapsulamento protege invariantes. Isso tem valor técnico real. Mas uma parte significativa dessas camadas existe para organizar o código na cabeça de quem mantém, não para a máquina que executa.

E essa parte tem custo. Cada camada adiciona latência. Cada framework carrega dependências. Cada indireção consome memória. Cada ORM traduz o que o banco já faz nativamente. Cada serialização entre camadas conceituais custa CPU.

Um request que atravessa 7 camadas de abstração, passa por um ORM, serializa e desserializa 3 vezes, e resolve dependências em runtime não é lento porque precisa.

A hipótese é simples:

Se quem escreve, lê, refatora e dá manutenção no código for uma IA, então grande parte dessas abstrações perde a razão de existir.

  • Se a IA escreve Rust tão rápido quanto TypeScript, por que escolher a linguagem mais lenta?
  • Se a IA opera com menos necessidade de abstrações organizacionais, por que adicionar camadas que existem para a cabeça humana?
  • Se a IA gera só o necessário, por que carregar um framework inteiro?

Fiz um exercício, 2 cenários estimados, olhando apenas para o impacto de escolher a linguagem certa para cada componente:

  • Monolito em Node.js (padrão "confortável para humanos")
    Custo AWS: ~R$ 1.900/mês | Latência p95: ~80ms

  • Linguagem ótima por componente (Rust no hot path, Go no CRUD, TS nas integrações)
    Custo AWS: ~R$ 950/mês | Latência p95: ~25ms

Isso só com a troca de linguagem. Ainda sem considerar a remoção de camadas de abstração, frameworks desnecessários, ORMs e indireções que existem para conforto humano. O ganho real provavelmente seria maior.

O que não estou dizendo: que arquitetura deixa de importar. Abstrações com valor técnico real,contratos, isolamento, testabilidade, continuam fazendo sentido.

Microsserviços, por exemplo, continuariam fazendo sentido, não pelo argumento de "times separados" (humano), mas por permitir a linguagem ótima para cada workload (máquina).

O papel do engenheiro nesse cenário muda. O diferencial deixa de ser escrever código bonito e passa a ser entender de performance, custos de infraestrutura, tradeoffs entre linguagens, e como orquestrar uma IA que opera em múltiplas linguagens ao mesmo tempo.

Não sei se esse futuro chega em 2 anos ou em 10. Mas vai ser interessante.

Carregando publicação patrocinada...
1

Cara, discordo q dá pra tirar humano do código, pq o código só existe para q a gente entenda o q está acontecendo dentro da máquina. Pq se olhar, todas esssas estruturas por baixo dos panos são 0 e 1s. Então se quer tirar o "humano" do código, só fazer tudo em 0 e 1s.

1

Concordo, se tirar o ser humano, não vai usar linguagem, vai ser tudo em binário diretamente.

A questão é que eu não sei se a IA já consegue fazer isso tão bem e sozinha.

1

Ahahah, vdd. Mas se ela nem gera códigos bons pra gente, acha msm q será perfeito em binário? O problema da IA não é o gerador e sim os dados de treino. Claro q se manipular algumas configurações ela pode ficar melhor, msm assim não é isso o problema.

Por exemplo: eu uso um plugin com a versão X+1 no meu projeto, q foi recém atualizado com bte breaking changes. ai uso a IA para gerar o código pra mim q foi treinado com a versão X. ela pode até conseguir gerar da versão X+1 se pedir, mas se deixar ela entender, ela continuará usando com base no q ela aprendeu, q é X.

Outro problema, hj qual é um dos maiores problemas q o pessoal está tendo pra criar uma IA? Simples, falta de dados pra treinar ela. Então olha o github. Acha msm q todos códigos abertos de lá são códigos bons? Pelo menos no meu, 90% do código são treinos q fiz e a maioria estão desatualizadas. Só 1 deles foi um projeto q foi pra produção, de resto é código antigo. Eu não me importo se usarem esse código, o problema é q nele tem mtas coisas q não são bons, pois usei exatamente para treinar a mim msm. Imagina só se só usasse meus códigos para treinar uma IA, ia sair um lixo de IA.

Agora vamos pra linguagem de máquina 0 e 1s, consegue perceber q vai continuar sendo a msm coisa? As IAs de hj tem uma limitação enorme, pq ela não é uma IA real, é apenas um software de probabilidades. Ela sim consegue resolver um monte de problemas, mas enquanto ela não executar de forma parecida como pensamos (q é a limitação de como ela existe) ela sempre terá problemas, independente do q for gerar, pq o problema é os dados.

1

Acredito que a mensagem principal foi, não escolhermos mais a stack pela facilidade ou afinidade com o time, e sim pela performance do codigo. Com bons testes, o código está virando uma caixa preta nas empresas. A questão é continuar a ter testes! E bons testes.