Existe algum framework pra não ficar burro?

Toda essa preocupação com arquitetura, software design e principalmente código tende a reduzir cada vez que os modelos se aprimoram. Em alguns anos, ou meses, estaremos criando e "orientando" agentes para prestarem serviços, e serão estes agentes que criarão o software necessário para executarem o serviço. A orientação dos agentes será a nova programação, mas em linguagem natural, e sem preocupação com infra, arquitetura ou design.

Desapega porque o bagulho vai ficar ainda mais sério.

Esse problema já foi resolvido décadas antes disso de desenvolvimento com IA começar. Mas antes de falar da solução, deixe-me fazer algumas correções que são muito importantes:

Comparar LLM com compilador é uma opinião que infelizmente está virando majoritária nas comunidades de desenvolvimento e influencers da área. Para começo de conversa, a premissa está errada: bons desenvolvedores se preocupam sim em estudar a saída gerada pelo compilador. É por isso que temos disassemblers, depuradores nativos (como GDB), ferramentas como objdump, readelf, ldd etc.

Então, não sei de onde tiraram essa mentira de que desenvolvedores não revizam e/ou não entendem o assembly gerado pelo compilador. Existem inúmeros motivos do porque essa atividade não apenas é útil, como muitas vezes é necessária. Não vou me dar ao trabalho de tentar simplificar a explicação para desenvolvedores web que não estão acostumados com C, low level e programação de sistemas, mas só pare para pensar: se os desenvolvedores realmente não estudassem a saída do compilador, não existiriam centenas de ferramentas que foram feitas especificamente para essa atividade. Veja o Compiler Explorer, mais um exemplo além dos já mencionados.

E um aviso importante: compilador ser determinístico não significa que é 100% preciso. Só significa que se dada a mesma entrada ele gera sempre a mesma saída, e essa saída pode estar errada. Quem nunca teve que depurar código errado gerado pelo GCC não sabe o que é diversão... E sim, esses erros acontecem em frequência significativa. Não é algo que acontece uma vez na vida.

Outra correção: camada de abstração não foi feita para que o desenvolvedor não precise entender como as coisas funcionam por debaixo da camada de abstração. Mesmo que você considere LLM como camada de abstração (o que está errado, mas deixa quieto), isso não te isenta da necessidade de entender como funciona o código gerado pelo LLM. Assim como programar em C não te isenta da necessidade de entender o assembly gerado pelo GCC.

Camada de abstração foi feita para tornar desenvolvimento de sistemas complexos humanamente possível. Vou dar um exemplo: imagine que você precise fazer uma pixel art com 1 trilhão de pixels. É humanamente impossível, são pixels demais. Então você abstrai os pixels em blocos, os blocos em setores, os setores em zonas e as zonas em segmentos. Pronto: agora você não precisa pensar em pixels sempre, só em segmentos, eventualmente em zonas, as vezes em setores, muito pouco frequente em blocos e raramente em pixels.

Camada de abstração é ferramenta para construção de sistemas complexos, não é desculpa esfarrapada para não entender como as coisas funcionam. Você precisa entender como as coisas funcionam para fazer sistemas complexos corretamente. Se você não entende pixels ao construir sua pixel art, você vai fazer segmentos imprecisos.

O problema é que a "imprecisão" está sendo excessivamente tolerada na área de desenvolvimento nas últimas décadas, e as consequências estão aí: IA achando CVE em tudo quanto é projeto.

---

Dito isso. Você não precisa conhecer toda a base de código para ser capaz de entender como um software funciona. Você abstrai o software em módulos e subsistemas e estuda uma parte por vez.

Primeiro você entende como os subsistemas funcionam para compor o software como um todo. Depois escolhe um subsistema para estudar: daí você estuda como os módulos do subsistema funcionam para compor o subsistema como um todo. Depois escolhe um módulo do subsistema para estudar: aí sim você estuda o código... E repete o processo para outro módulo e/ou outro subsistema. É simples assim.

E para estudar o código você pode replicar a estratégia: estuda como as funções funcionam para compor o código daquele módulo como um todo. Depois escolhe uma função para estudar o código.

Entendeu a estratégia? É só dividir o que você quer estudar em partes menores, entender a relação entre essas partes menores e estudar cada parte de uma vez, repetindo a divisão se for necessário. "Dividir para conquistar".

Pessoal tem feito esse tipo de estratégia de análise desde o século passado para depuração de sistemas complexos e para engenharia reversa. Então não exagerei quando eu falei que a solução existe há décadas, existe mesmo.

Pesquise sobre taint analysis que pode te ajudar também ao precisar analisar bases de código desconhecidas.

Basicamente a solução é aprender a analisar software como gente grande. Estude sobre técnicas de depuração e engenharia reversa, mesmo que só o básico. :)

Eu uso regras, critérios e skills. Peço para a IA gerar memória, análise, dividir a tarefa em etapas pequenas e registrar as decisões e testo muito. Faço uma revisão geral também do que ela está fazendo e muita das vezes questiono as decisões e ao final da tarefa eu rodo uma skill de verificação.

Para projetos pessoais eu codo na mão para não perder a prática e ter um entendimento mais profundo e controle.

Vou dar uma resposta meio provocativa, mas a única coisa que funciona é desistir de entender.

Se você tá cagando pro assembly que o GCC gera, por que conhecer cada linha do código de alto nível que o modelo gera seria uma obrigação? Você já aceita trabalhar sobre implementações que não entende. A questão é quais garantias permitem fazer isso.

O problema é que um modelo não tem as mesmas garantias de um compilador.

Justamente por isso, “pedi, ele fez e parece funcionar” é um critério péssimo. Você precisa definir o comportamento esperado e ter meios de verificar se ele foi respeitado. Testes de aceitação, propriedades, invariantes, análise estática, observabilidade. Conforme o problema, métodos formais também.

Comportamento observável inclui o que acontece quando dá errado. Acesso indevido, concorrência, falhas parciais, consumo de memória, latência.

Isso não significa ficar burro. Especificar com precisão o que um sistema deve fazer, identificar o que pode dar errado e construir uma validação capaz de pegar esses erros exige bastante entendimento. Pedir pra mesma IA inventar a solução e o critério de sucesso, sem questionar nenhum dos dois, não resolve.

Eu trocaria a meta de "entender o codebase" por "entender o sistema". Quando precisar investigar uma decisão de arquitetura, você desce à implementação. Assim como eventualmente se desce ao assembly.