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.