Debugging with Evaluation Abstractions

Do programmers put everything they know about a problem domain into the code they write to solve that problem? Or do they instead select a relatively parsimonious subset of that knowledge to define formally and translate into code? If the latter is true, it may be that they bring their original, richer perspective to bear in checking their program\´s behavior against their expectations. I will refer to these richer abstractions as "evaluation abstractions", in contrast to the formal "programming abstractions" embodied in the code.