comprehension

Accepting program modifications
demanded by changing external circumstances to be an essential part of programming, it is argued that the primary aim of
programming is to have the programmers
build a theory of the way the matters at
hand may be supported by the execution
of a program. Such a view leads to a
notion of program life that depends on
the continued support of the program by
programmers having its theory. Further,
on this view the notion of a programming method, understood as a set of rules of
procedure to be followed by the programmer, is based on invalid assumptions and so has to be rejected.

I no longer have a firm mental model of what they can do and how they work, which means each additional feature becomes harder to reason about, eventually leading me to lose the ability to make confident decisions about where to go next.

Comprehension debt is the growing gap between how much code exists in your system and how much of it any human being genuinely understands.

Cognitive debt, a term gaining traction recently, instead communicates the notion that the debt compounded from going fast lives in the brains of the developers and affects their lived experiences and abilities to “go fast” or to make changes. Even if AI agents produce code that could be easy to understand, the humans involved may have simply lost the plot and may not understand what the program is supposed to do, how their intentions were implemented, or how to possibly change it.

Reviewing AI generated code can be tough, especially if the code generated is solving a particularly complex problem. Even if the code is correct, it can be hard to understand how exactly it works. When working with other human programmers, I would generally ask them to walk me through their code, and I would ask questions about why they made certain decisions as we go. I wanted a similar process for reviewing AI generated code. After a lot of exploring, I've found a combination that works well for me.